Что такое справочник в базе данных
Перейти к содержимому

Что такое справочник в базе данных

  • автор:

Справочники

Справочники — это прикладные объекты конфигурации. Они позволяют хранить в информационной базе данные, имеющие одинаковую структуру и списочный характер. Это может быть, например, список сотрудников, перечень товаров, список поставщиков или покупателей.

Структура справочника

Каждый элемент справочника характеризуется кодом и наименованием. Система поддерживает режим автоматической нумерации элементов, при котором она самостоятельно может генерировать код для нового элемента справочника. Кроме этого система позволяет осуществлять контроль уникальности кодов справочника, не разрешая создавать элементы с одинаковыми кодами:

Справочники

Помимо кода и наименования, каждый элемент справочника, как правило, содержит некоторую дополнительную информацию, которая подробно описывает этот элемент. Например, для товара это может быть информация об артикуле, упаковке и т. п. Набор такой информации является одинаковым для всех элементов конкретного справочника, и для ее хранения служат реквизиты справочника:

Справочники

Кроме этого, каждый элемент справочника может содержать некоторый набор информации, которая одинакова по своей структуре, но различна по количеству, для разных элементов справочника. Например, для каждого сотрудника в справочнике Физические лица это может быть контактная информация или информация о составе семьи, образовании. Для хранения подобных данных служат табличные части справочника:

Справочники

Справочники могут поддерживать иерархическое расположение элементов. Например, в справочнике Номенклатура могут быть созданы группы: Бытовая техника, Обувь, Продукты и т. д., в которых располагаются элементы, относящиеся к этим группам. Кроме того группы справочника могут включать в себя и другие группы, создавая тем самым многоуровневую иерархическую структуру.

Справочники

В справочниках возможен и другой вид иерархии, при котором элементы справочника будут относиться не к группам, а к другим элементам этого же справочника. Такой вид иерархии может использоваться, например, при создании справочника Задачи, где одна задача может включать в себя несколько других задач.

Справочники

Разные справочники могут находиться в состоянии подчинения, т. е. элементы одного справочника могут быть подчинены элементам или группам другого справочника. Например, справочник Кассы может быть подчинен справочнику Организации. Тогда при оформлении кассовых документов для некоторой организации можно будет выбрать кассу не среди всех имеющихся в программе касс, а среди касс, существующих только в этой организации:

Справочники

Справочники допускают также создание предопределенных элементов, которые существуют в справочнике всегда, вне зависимости от действий пользователя. Такие элементы справочника создаются разработчиком при разработке прикладного решения и не могут быть удалены или перемещены пользователем.

Например, если в основном прикладное решение будет внедряться на предприятиях одного государства, России, в справочник Страны мира сразу же можно добавить предопределенный элемент Россия, поскольку он понадобится подавляющему большинству пользователей.

Справочники

Формы справочника

Для того чтобы пользователь мог просматривать и изменять данные, содержащиеся в справочнике, система поддерживает несколько форм представления справочника. Система может автоматически генерировать все нужные формы справочника. Наряду с этим разработчик имеет возможность создать собственные формы, которые система будет использовать вместо форм по умолчанию:

Справочники

Форма списка

Для просмотра данных, содержащихся в справочнике, используется форма списка. Она позволяет выполнять навигацию по справочнику, добавлять, помечать на удаление и удалять элементы и группы справочника, перемещать элементы и группы. Форма списка может представлять данные в иерархическом и не иерархическом виде и позволяет выполнять сортировку и отбор отображаемой информации по нескольким критериям:

Справочники

Форма элемента

Для просмотра и изменения данных отдельных элементов справочника используется форма элемента. Как правило, она представляет данные в удобном для восприятия и редактирования виде:

Справочники

Форма группы

Система поддерживает отдельный вид формы для групп справочника. Это связано с тем, что, как правило, состав информации, относящейся к группе справочника, намного меньше, чем состав данных, имеющих отношение к отдельным элементам справочника:

Справочники

Форма выбора, форма выбора группы

При различных действиях пользователя в прикладном решении возникает необходимость выбора конкретных элементов справочников. Это может потребоваться, например, при создании приходной накладной, в которой должны быть перечислены определенные товары. В этом случае система использует форму выбора справочника, которая, обычно, содержит минимальный набор информации, необходимой для выбора того, или иного элемента:

Справочники

Кроме всех перечисленных форм, система поддерживает еще форму выбора группы справочника, предназначенную для выбора только среди групп, содержащихся в справочнике.

Макеты

Справочнику могут быть сопоставлены несколько макетов, содержащих данные, необходимые для обеспечения работы справочника:

Справочники

Макеты могут использоваться для формирования печатных форм справочника или для отображения дополнительной информации, имеющей отношение к справочнику.

Справочники

No contents entries on this page

Contents

Система Ultima Businessware® предоставляет прикладному разработчику механизмы создания и редактирования справочников, описывающих бизнес-объекты предметной области.

Описание справочников хранится в схеме ядра базы данных в следующих таблицах:

• DICTIONARIES – атрибуты справочников;

• DICT_PROPERTIES – свойства справочников;

• PROP_TRANSLATIONS – локализованные значения полей справочника, переводимых на язык отличный от языка по умолчанию;

• DICT_TOONEREFS – взаимосвязи свойств справочников с другими справочниками;

• LINK_TABLES – атрибуты развязочных таблиц;

• LINK_PROPERTIES – свойства развязочных таблиц;

• LINK_TOONEREFS – взаимосвязи свойств развязочных таблиц со справочниками;

• DICT_LINKTABLES – взаимосвязи справочников с другими через развязочные таблицы.

Поля этих таблиц будут подробно описаны ниже при описании механизма создания новых объектов типа справочник.

С помощью таблиц OBJECTS и VERSIONS реализуется механизм версионирования конфигурации.

Каждая из таблиц, описывающих справочники, имеет по два ключевых поля, связанных с соответствующими таблицами:

• OBJECT_ID – идентификатор объекта;

• VERSION_ID – идентификатор версии конфигурации.

Физическая (ER) модель данных выглядит следующим образом:

Dict_Dict_Tables_ER

Прикладной разработчик может осуществлять запросы к метаданным и через представления (view) – виртуальные таблицы, полученные выборкой из базы данных всех объектов относящихся к одной версии конфигурации, идентификатор которой получен из текущей сессии. Таким образом, обращаясь к таблицам базы данных и внося в них изменения, разработчик получает доступ только к выбранной при входе в систему версии конфигурации. Для всех таблиц представлений к имени таблицы добавляется префикс «V».

Модель проекции текущей версии данных выглядит в этом случае гораздо проще:

Dict_Dict_Tables

Таблица PROP_TRANSLATIONS модели данных не имеет префикса «V», так как не является представлениям по причине того, что не версионируется.

В таблице DICTIONARIES хранятся атрибуты , которые описывают справочник и его таблицу в прикладной схеме базы данных:

• NAME – название справочника, определяет название генерируемого класса ;

• CAPTION – отображаемое в экранных формах название справочника, например, для справочника контрагентов Agents это может быть название «Контрагенты» или «Справочник контрагентов»;

• TABLE_NAME – название таблицы в прикладной схеме базы данных (вследствие ограничений, накладываемых СУБД Oracle, название может содержать только буквы латинского алфавита в верхнем регистре, цифры и знак «_», при этом название должно начинаться с буквы и быть не больше 30 символов);

• CACHED – флаг кэширования, если он установлен – справочник кэшируется на компьютерах конечных пользователей. При повторном обращении к нему данные берутся из локальной копии, а не с сервера базы данных, что можно использовать для справочников с редко меняющимися данными, например, списком офисов.

Для кэшируемого справочника всегда рассылаются уведомления об изменении, поэтому не следует делать кэшируемыми часто изменяющиеся справочники .

• NOTIFICATION_ENABLED – флаг уведомления, используется для оповещения о внесенных в данные справочника изменениях. Для кэшируемого справочника уведомления рассылаются всегда независимо от состояния флага;

• PARENT_REF_OBJ_ID (FK) – атрибут используется для создания справочника древовидного типа. В качестве его значения указывается ссылка на запись таблицы DICT_TOONEREFS , которая указывает, какое из свойств выбранного справочника (полей его таблицы) будет родительским ( PARENT_ID в примере):

Dict_Tree

• DISPLAY_FORMAT – формат строки, в котором отображаются элементы справочника в экранных формах, когда они выводятся не в табличном, а строковом виде;

• SCRIPT_OBJ_ID (FK) – обработчик событий справочника (перед созданием, перед сохранением, после сохранения, перед удалением, после удаления), создается при необходимости;

• IS_SMALL – флаг размера справочника, устанавливается в true для справочников с небольшим количеством строк. Флаг влияет на работу некоторых элементов управления (controls), ориентированных на работу со справочниками. Так, например, содержимое маленьких справочников выводится в элементах управления DictionaryLookupEdit и DictionaryMultiSelectEdit целиком, содержимое прочих фильтруется;

• TRANSP_LOCALIZATION – флаг прозрачности локализации ( true – справочник локализуется прозрачно, false – непрозрачно).

Локализация справочников подробно описана в следующем разделе .

В таблице DICT_PROPERTIES описываются свойства справочника – по сути, поля его таблицы :

• NAME – название свойства, определяет название свойства генерируемого класса ;

• CAPTION – отображаемое в экранных формах название свойства справочника, например, для свойства Name справочника контрагентов это может быть «Имя контрагента» или «Название контрагента»;

• DICT_OBJ_ID (FK) – ссылка на справочник, которому принадлежит свойство, заполняется автоматически при добавлении его в справочник;

• COLUMN_NAME – название поля таблицы в прикладной схеме базы данных (на название поля СУБД Oracle накладывает те же ограничения, что и на таблицу);

• TYPE_ID (FK) – тип свойства (подробнее см. раздел Типы данных );

• CONTROL_ID (FK) – элемент управления, который будет использоваться по умолчанию в экранных формах для ввода значений этого свойства, выбирается из предлагаемых системой. Например, для строкового свойства это может быть строка, поле или строка для ввода пароля, скрывающая введенные символы;

• STRING_SIZE – ограничивает длину строки, если в качестве типа свойства TYPE_ID выбран string или text ;

• IS_MULTILANGUAGE – флаг, указывающий требуется ли перевод для этого свойства;

• IS_REQUIRED – флаг, указывающий обязательно ли свойство для заполнения;

• DEFAULT_VALUE – значение свойства по умолчанию, которое подставляется автоматически при создании нового элемента справочника.

В таблице PROP_TRANSLATIONS хранятся локализованные значения полей справочника :

• OBJECT_ID (FK) – ссылка на локализуемое свойство справочника;

• VALUE_ID – запись справочника в прикладной схеме базе данных, свойство которой локализуется;

• LANG_ID (FK) – язык локализации;

• STRING_VALUE – поле, предназначенное для хранения локализованного значения длинной не больше 4’000 символов;

• CLOB_VALUE – поле, предназначенное для хранения локализованного значения длинной свыше 4’000 символов.

Свойство справочника может быть ссылкой на другой справочник, взаимосвязи такого рода хранятся в таблице DICT_TOONEREFS :

• NAME – название взаимосвязи, определяет название свойства генерируемого класса типа класса , на который оно ссылается;

• CAPTION – отображаемое в экранных формах название взаимосвязи;

• DICT_OBJ_ID (FK) – справочник, свойство которого является ссылкой на другой справочник;

• PROP_OBJ_ID (FK) – свойство, которое является ссылкой на другой справочник. В качестве значения типа этого свойства ( TYPE_ID ) должен быть выбран long ;

• REF_DICT_OBJ_ID (FK) – справочник, на который ссылается указанное свойство.

Кроме того, через таблицу DICT_TOONEREFS задается свойство-родитель для справочников древовидного типа. В этом случае значения DICT_OBJ_ID (FK) и REF_DICT_OBJ_ID (FK) совпадают.

В результате заполнения всех обязательных атрибутов и свойств в прикладной схеме базы данных будет создана новая таблица TABLE_NAME с первичным ключом ID и полями COLUMN_NAME , которая будет использоваться для хранения данных нового справочника.

Кроме того, для каждой таблицы справочника создается представление, через которое производятся все операции чтения/записи. Представление необходимо для:

• версионирования схемы СУБД;

• поддержки часовых поясов;

• прозрачной локализации мультиязычных свойств справочников.

Рассмотрим на примере создание справочника товаров.

Описываем атрибуты и свойства нового справочника «Товары». В результате в схеме ядра сохраняются следующие метаданные:

Dict_Example1

На их основании в прикладной схеме базы данных ядром создается таблица GOODS.

В таблице LINK_TABLES хранятся атрибуты , которые описывают развязочную таблицу в прикладной схеме базы данных:

• NAME – название развязочной таблицы, определяет название генерируемого класса ;

• CAPTION – отображаемое в экранных формах название развязочной таблицы, значение этого атрибута подставляется по умолчанию в соответствующее поле при заполнении связи с ней справочника;

• TABLE_NAME – название таблицы в прикладной схеме базы данных.

В таблице LINK_PROPERTIES описываются свойства развязочной таблицы – по сути, поля ее таблицы в прикладной схеме базы данных.

• NAME – название свойства, определяет название свойства генерируемого класса ;

• CAPTION – отображаемое в экранных формах название свойства развязочной таблицы;

• LINK_OBJ_ID (FK) – ссылка на развязочную таблицу, которой принадлежит свойство, заполняется автоматически при добавлении его в развязочную таблицу;

• COLUMN_NAME – название поля таблицы в прикладной схеме базы данных;

• TYPE_ID (FK) – тип свойства (подробнее см. раздел Типы данных );

• CONTROL_ID (FK) – элемент управления, который будет использоваться по умолчанию в экранных формах для ввода значений этого свойства, выбирается из предлагаемых системой. Например, для строкового свойства это может быть строка, поле или строка для ввода пароля, скрывающая введенные символы;

• STRING_SIZE – ограничивает длину строки, если в качестве типа свойства TYPE_ID выбран string или text ;

• IS_MULTILANGUAGE – флаг, указывающий требуется ли перевод для этого свойства;

• IS_REQUIRED – флаг, указывающий обязательно ли свойство для заполнения;

• DEFAULT_VALUE – значение свойства по умолчанию, которое подставляется автоматически при создании нового элемента развязочной таблицы;

• IS_KEY – флаг, указывающий, что данное свойство является ключевым . Каждому набору ключевых свойств развязочной таблицы (помеченных флагом IS_KEY ) соответствует только один набор значений остальных ее свойств. У каждой развязочной таблицы должно быть как минимум два ключевых свойства.

Свойство развязочной таблицы может быть ссылкой на справочник, взаимосвязи такого рода хранятся в таблице LINK_TOONEREFS :

• NAME – название взаимосвязи, определяет название свойства генерируемого класса типа класса , на который оно ссылается;

• CAPTION – отображаемое в экранных формах название взаимосвязи;

• LINK_OBJ_ID (FK) – развязочная таблица , свойство которой является ссылкой на справочник;

• PROP_OBJ_ID (FK) – свойство развязочной таблицы, которое является ссылкой на справочник. В качестве значения типа этого свойства ( TYPE_ID ) должен быть выбран long ;

• REF_DICT_OBJ_ID (FK) – справочник, на который ссылается указанное свойство.

В результате заполнения всех обязательных атрибутов и свойств в прикладной схеме базы данных будет создана новая таблица TABLE_NAME с полями COLUMN_NAME , которая будет использоваться для хранения данных развязочной таблицы.

В таблице DICT_LINKTABLES хранятся взаимосвязи справочника с другими посредством развязочных таблиц :

• NAME – название развязочной таблицы, определяет название свойства-коллекции генерируемого класса ;

• CAPTION – отображаемое в экранных формах название развязочной таблицы, подставляется по умолчанию из соответствующего атрибута LINK_TABLES , может быть изменено;

• DICT_OBJ_ID (FK) – ссылка на редактируемый справочник, заполняется автоматически;

• LINK_OBJ_ID (FK) – развязочная таблица, с которой будет связан редактируемый справочник;

• PROP_OBJ_ID (FK) – поле развязочной таблицы, которому будет соответствовать идентификатор ( ID ) свойств редактируемого справочника.

Развязочные таблицы не имеют собственного интерфейса редактирования данных, как, например, элементы справочников. В экранной форме редактирования элементов справочника, который мы связываем с помощью развязочных таблиц с другим, автоматически создастся закладка с названием, заданным в атрибуте CAPTION , на которой будет возможно задавать отношения элементов текущего справочника с элементами, заданными в развязочной таблице LINK _OBJ_ID (FK), и редактировать связанные с ними переменные .

В таблице DICT_TOMANYREFS описываются взаимосвязи справочника с другими через отношения многие ко многим и соответствующая им таблица в прикладной схеме базы данных:

• NAME – название ссылки ко многим, определяет название свойства коллекции генерируемого класса ;

• CAPTION – отображаемое в экранных формах название ссылки ко многим;

• DICT_OBJ_ID (FK) – ссылка на создаваемый (редактируемый) справочник, заполняется автоматически;

• TABLE_NAME – название таблицы ссылок ко многим в прикладной схеме базы данных;

• COLUMN_NAME – свойство (поле) таблицы ссылок ко многим, по которому создаваемый (редактируемый) справочник будет связан с другим;

• REF_DICT_OBJ_ID (FK) – ссылка на другой справочник, с которым будет связан создаваемый (редактируемый);

• REF_COLUMN_NAME – свойство (поле) таблицы ссылок ко многим, с которым будет связан другой справочник.

В результате заполнения всех свойств в прикладной схеме базе данных будет создана новая таблица (ссылок ко многим) с именем TABLE_NAME и двумя полями COLUMN_NAME и REF_ COLUMN_NAME , ссылающимися на ключевые поля двух справочников DICT_OBJ_ID (FK) и REF_DICT_OBJ_ID (FK) .

Таблицы отношений многие ко многим так же, как и развязочные таблицы, не имеют собственного интерфейса редактирования данных. Связывая текущий справочник ссылками ко многим с другим, мы тем самым автоматически создаем в его экранной форме закладку с названием, заданным в атрибуте CAPTION , на которой будет возможно задавать отношения элементов текущего справочника с элементами справочника REF_DICT_OBJ_ID (FK) .

Таблицы-справочники

Таблица-справочник является простейшим элементом информационной базы, в ней могут храниться значения, относящиеся как к одному, так и к разным уровням измерения. Например, справочник « Субъекты РФ » содержит только территории, относящиеся к субъектам РФ, а города и районы каждого субъекта находятся на более низких уровнях и входят в отдельные справочники.

Физически, таблица-справочник состоит, как правило, из трех полей:

  • Поле 1 . Уникальный идентификатор каждого элемента данных (Код);
  • Поле 2 . Собственно содержание элемента списка (Наименование);
  • Поле 3 . Код владельца, то есть уникальный идентификатор элемента справочника уровня выше (Связь). При формировании иерархического измерения « Поле 3 » используется в выражении, которое определяет условие подчиненности элементов данного справочника элементам справочника более высокого уровня. При наличии « Поля 3 » в таблице-справочнике могут храниться значения атрибута, относящиеся к разным уровням измерения. Если « Поле 3 » отсутствует, то таблица-справочник будет содержать элементы только верхнего уровня;
  • Поле 4 . Порядковый номер на уровне иерархии (Порядок). При создании измерения можно будет задать порядок элементов на уровне. Если он отличается от обыкновенной сортировки элементов списка по возрастанию, то в структуру таблицы можно добавить данное поле.

Нашли ошибку? Выделите текст с ошибкой и нажмите кнопку «Сообщить об ошибке» или CTRL+ENTER.

Справочная система на версию 9.2 Update 4 от 11/10/2019, © ООО «ФОРСАЙТ»,

Классификация таблиц в реляционных базах данных по признакам целостности и избыточности данных

Обоснование статьи и некоторые ключевые понятия;
1. Справочники и связки;
1.1. Виды таблиц;
1.2. Виды справочников;
1.3. Виды связок;
2. Обобщение классификации;
2.1. Классификация в табличном виде;
2.2. Классификация в схематичном виде;
3. Некоторые комментарии по применению классификации;
3.1. Применение классификации при нормализации таблиц;
Заключение.

Обоснование статьи и некоторые ключевые понятия

Очень часто присутствовал на обучении дисциплине «Базы данных». Обучался когда-то сам… Как-то даже пришлось проводить целый курс для друзей и знакомых. Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться. Многие просто не могли и не могут разработать простейшие базы данных. После более детального рассмотрения такого понятия как таблицы и маленькой классификации, трудности восприятия таблиц в реляционных базах данных почти всегда исчезают. Итак!

В данной статье будет рассмотрена маленькая классификация таблиц по признакам целостности и избыточности. Что это значит? Это значит, что будут приведены примеры с описанием, какую структуру таблиц можно делать, чтобы предотвращать (пытаться предотвращать) избыточность и добиваться целостности в реляционных базах данных.

Для понимания дадим краткие определения целостности и избыточности данных:

Целостность данных – это свойство способности по одним данным восстанавливать другие, при этом не теряя семантическое единство этих данных и отношения между ними (между данными).

Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют лишние данные.

Целостность данных может быть нарушена в результате операций модификации данных. Если в базе данных запрещены операции удаления и обновления, то целостность может быть нарушена только в результате операции добавления, а также неправильно написанных скриптов по отображению данных.

1. Справочники и связки

1.1. Виды таблиц

Немного углубимся в маленькую классификацию таблиц по видам их структуры. Разделим таблицы на два общих вида. Первым видом будут таблицы-справочники, вторым таблицы-связки.

Справочники и связки

Рисунок 1. Справочники и связки

Информацию в таблицах можно разделить на два вида. На информацию, которая описывает объекты (субъекты), связи и информацию, которая описывает действия, процессы, события, иное.

В справочниках содержатся сведения об объектах и субъектах, связях. В связках содержатся сведения о действиях, процессах, событиях и так далее.

В связках хранятся данные, взятые из таблиц справочников. Поскольку невыгодно повторять одни и те же данные при описании объектов (субъектов) и при описании их взаимодействия, данные об объектах (субъектах) заносятся в справочники, а в таблицах-связках не хранятся данные объектов (субъектов) в чистом виде, а лишь ссылки на них (внешний ключ). Таким образом, в связках хранятся данные по взаимодействию объектов (субъектов) и ссылки на самих объектов (субъектов) (внешний ключ). Эти «ссылки» являются первичными ключами в таблицах справочниках. Но об этом потом…

Отличие справочника от связки выражается в том, что таблицы-справочники могут быть самостоятельными и независимыми (то есть, при чтении данных некоторых справочников можно в целом понять семантику), а таблицы-связки практически никогда.

1.2. Виды справочников

Справочники могут подразделяться на несколько видов. Это статичные, статично-динамичные и динамичные справочники. Разумеется, вряд ли можно назвать абсолютно статичный справочник, так как в этом мире может измениться всё. Или почти всё.

Статичный справочник – справочник, данные об объектах, субъектах, связях в котором либо никогда не подвергаются модификации после первичной модификации, либо настолько редко подвергаются модификации, что этим можно пренебречь.

Примером таких справочников могут служить список месяцев с названиями и номерами, список дней недели, список времён года, список океанов и так далее…

Номер Наименование
1 Январь
2 Февраль
3 Март
4 Апрель
5 Май
6 Июнь
7 Июль
8 Август
9 Сентябрь
10 Октябрь
11 Ноябрь
12 Декабрь

Таблица 1. Пример статичных справочников

Статично-динамичный справочник – справочник, в котором хранятся данные о связях, если связи носят справочный характер. В таком справочнике могут быть внешние ключи.

Наиболее удачным примером будет таблица с такими медицинскими данными, как вес. Список человек, вес которых измеряется, изменяется не так часто. А вот данные по их весу могут меняться каждый день. Статично-динамичные справочники являются единственными справочниками, где осознанно можно повторять любую информацию. Ещё одним примером может быть справочник окладов по должностям (по коду должности).

Код должности Оклад Дата обновления
1001 12 000 05.02.2015
1002 17 000 01.02.2015
1003 11 500 01.02.2015
1004 25 450 01.02.2015
1005 10 000 01.02.2015
1006 6 000 04.02.2015

Таблица 2. Пример статично-динамичных справочников

Динамичные справочники – это таблицы, данные об объектах, субъектах, связях в которых меняются часто и используются в других таблицах. От статичных справочников отличаются только частотой модификации в них данных.

Примером таких таблиц могут быть списки проектов. На самом деле, данные об открытии или закрытии проектов могут находиться в самом справочнике проектов, что в большинстве случаев неправильно и нарушает целостность. С другой стороны, если хранить историю изменений по открытию и закрытию (приостановке) проектов, то можно получить избыточность данных. Целостность и избыточность данных будут бороться с друг другом ещё долго, также как и зима с летом.

Код проекта Проект Нормативный срок выполнения Дата добавления Пользователь
PT102 Покраска окон 15 03.01.2014 1547
PT103 Установка дверей 10 04.01.2014 9874
PT587 Проверка пожарных кранов 2 04.01.2014 1456
PT588 Замена люков 3 02.01.2014 0147
PT133 Очистка каналов 11 09.02.2015 1547

Таблица 3. Пример динамичных справочников

Виды справочников

Рисунок 2. Виды справочников

1.3. Виды связок

Таблицы-связки можно разделить на два вида.

Это справочник-связка (сразу же уточним, что справочник-связка справочником не является, назван так, потому что в нём существуют поля, которые образуют справочник, но в справочник выделены быть не могут). Таблица, в которой хранятся внешние ключи, данные, которые не являются справочными и поля, содержащие данные, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник.

Примером справочника-связки будет являться таблица платёжных транзакций. Или таблица с данными о футбольном матче.

Код транзакции Плательщик Получатель Сумма Дата Комментарий
EEVS-doodi4 100045 57457 -10 000 25.07.2014 На сапоги
UDFD-ioeed9 455780 10024 -900 24.06.2014 NULL
PEDD-jdksl4 144770 56698 -6980 01.01.2015 NULL
FDFE-keiiii0 447757 1 120 08.07.2014 NULL

Таблица 4. Пример справочника-связки

И связка (да, просто связка). Это таблица в которой хранятся только внешние ключи и данные, которые нельзя отнести к справочным, например дата или значения логических полей.

Примером связки будет являться таблица автоматического логирования терминала обработки данных.
Кстати, легко догадаться, что связки почти нигде не используются, поскольку чаще всего находятся данные, которые могут быть записаны в базу, но не содержаться в справочниках, поэтому невозможно сопоставить им внешний ключ.

Код Код клиента Показания счётчика Месяц
2334 35643 50 01.01.2015
2335 235673 49 01.01.2015
2335 436345 56 01.01.2015
2335 574733 24 01.01.2015

Таблица 5. Пример связки

Необходимо пояснить, что это за поля, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник. Примером таких полей являются поля «комментарий», «жалоба», «описание», «предложение». Словом, если приводить популярный пример, то поле «сообщение» в таблице базы данных любой социальной сети…

Виды связок

Рисунок 3. Виды связок

2. Обобщение классификации

2.1. Классификация в табличном виде
Вид таблицы Описание Примеры Плюсы (+) Минусы(-)
Статичный справочник Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В статичном справочнике должна содержаться информация, которая либо вообще не изменяется, либо изменяется так редко, что этим можно принебречь. На статичный справочник ссылаются (внешний ключ), когда нужно получить названия, обозначения, нормы, количественные или качественные показатели. Иное. Справочник (наименований и номеров) месяцев.
Справочник складов и цехов предприятия.
Справочник правил игры.
Иногда заменяет системные функции СУБД, позволяет более гибко работать с некоторыми данными. В случае, если меняется редко изменяемая информация, предостерегает от серьёзных последствий. Использование таблицы с любой структурой может замедлять работу, в случае, если таблица заменяет системное хранилише.
Приходится писать дополнительные функции и обработки для данной таблицы, которые не всегда правильно оптимизированны. В некоторых случаях невозможно оптимизировать.
Статично-динамичный справочник Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах нельзя использовать внешний ключ этого справочника, однако можно использовать первичный ключ. Справочник окладов по должностям. Справочник (размеров обуви, веса, роста, размера головы) физиологических параметров. Справочник (менеджеров, компаний) содержащий компании и менеджеров, которые эти компании обслуживают и учитывают. Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник». Справочник, выделенный из справочника-связки, никуда не девается и не имеет никакой реляционной связи, которая позволила бы ему превратиться в статичный или динамичный справочник. А значит, всегда избыточен.
Динамичный справочник Таблица. Данные из неё берутся часто для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В динамичном справочнике должна содержаться информация, которая часто изменяется. Справочник клиентов. Справочник поставщиков. Справочник контрагентов. Справочник менеджеров компании. Справочник работников. Справочник студентов. Позволяет хранить динамичные данные, при этом давая возможность однозначно ссылаться на них. Чаще всего накопительного типа и не делим, что создаёт определённую избыточность.
Справочник-связка Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. Платёжные транзакции. Продажи. Межзаводские перемещения. График перевозок. Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник». Справочник-связка после нормализации превращается в связку и сводит избыточность данных к минимуму, не затрагивая целостность, однако не делим и при архивировании в текущей таблице не подлежит оптимизации.
Связка Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. Таблица не может содержать кортежей, значения атрибутов в которых являются неделимыми и не уникальными. Автоматический лог ошибок в программе. Лог запроса сервера. Результаты трассировок. Отчёты о выгрузке и загрузке компонентов. Автоматические отчёты системы безопасности. Связка сводит избыточность данных к минимуму, не затрагивая целостность. Накапливаясь, является неделимой таблицей. Сложно оптимизировать.

Таблица 6. Классификация

2.2. Классификация в схематичном виде

Общая схема

Рисунок 4. Схема классификации таблиц в реляционных базах данных по признакам целостности и избыточности данных

3. Некоторые комментарии по применению классификации

3.1. Применение классификации при нормализации таблиц

Процесс нормализации, если не учитывать некоторые этапы (Но учитывать результаты этих этапов!) — это обычное «дробление» таблиц на более мелкие таблицы с созданием реляционной связи между ними непосредственно или через промежуточные таблицы (связь «Многие ко многим»). Под реляционной связью может не всегда пониматься реляционное отношение!

Преобразование динамичного или статичного справочника в статично-динамичный справочник, а справочника-связки в связку, как и статично-динамичного справочника в справочник-связку — это ни что иное, как дробление таблиц. То есть, преобразование одного вида таблиц в другой через показанную выше классификацию в целях избежания избыточности данных — так можно определить нормализацию (один из вариантов определения).

Для примера. Пусть имеется база данных, в которой единственная операция по модификации данных — это добавление. В таком случае становится неэффективным каждый раз при изменении какого либо отдельного атрибута сущности, «копировать» остальные значения атрибутов уже в другой кортеж. В этом случае используются NULL или же создание статично-динамичного справочника, где описывается ряд атрибутов одной семантики или один атрибут, а дублируется лишь внешний ключ с первичным ключом последовательности. Этот же метод может использоваться в традиционной схеме модификации данных с обновлением и удалением данных.

Заключение

Данная классификация была создана мной на основе наблюдений при проектировании баз данных, а также исходя из прочитанной теории по проектированию в реляционных СУБД. Моим друзьям и знакомым, изучающим дисциплину «базы данных» и занимающимся проектированием баз данных, и мне эта классификация достаточно серьёзно упростила «жизнь» и позволила во многих ситуациях заранее выбрать наиболее подходящий и, как оказывалось потом, правильный вид таблицы для хранения в ней тех или иных данных.

Классификация может быть расширена разделением существующих видов в ней на подвиды (возможно, даже, добавлением новых видов). Также эта классификация показала, что лучше в некоторых ситуациях не использовать тот или иной вид таблиц. Некоторые виды таблиц из данной классификации лучше использовать реже (динамичные справочники). А некоторые пытаться заменить на другие (справочники-связки на связки).

Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.

  • разработка баз данных
  • реляционные субд
  • таблицы в реляционных СУБД

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *