Таблица справочник
Имеется веб-приложение которое работает с БД. В базе есть несколько «константных» таблиц, содержимое которых остается относительно постоянным — то есть в них довольно редко меняются какие-либо данные. Иначе говоря, это некие таблицы-справочники содержащие набор ключей и значений. Примером может быть таблица содержащая список стран. В коде приложения часто происходит обращение к этим таблицам. Например содержимое такой таблицы часто является содержимым какого-нибудь выпадающего списка. Однако обращаться строкам в этой таблице из веб-приложения по первичному ключу — не очень удачная затея на мой взгляд, так как это во первых не наглядно (совершенно непонятно, что Id равный 1 соответствует, скажем России если речь идет о таблице стран) Во вторых пусть и редко но теоретически идентификаторы могут меняться в таблице а это уже ведет к проблемам. Был предложен вариант помимо полей Id и Name хранить в таблице поле KeyCharName и сопоставлять его в коде приложения со значениями некоего enum написав для этого соответствующие методы конвертирования. С одной стороны уже лучше и решает первые две проблемы. Но с другой появляется необходимость постоянно следить при изменениях таблицы что значения enum в коде соответствуют значениям в таблице и к тому же это куда медленнее чем вариант работы с полем Id. Может кто-то знает более хорошие способы решения проблемы?
Отслеживать
1,821 1 1 золотой знак 12 12 серебряных знаков 23 23 бронзовых знака
Справочники
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) модель данных выглядит следующим образом:
Прикладной разработчик может осуществлять запросы к метаданным и через представления (view) – виртуальные таблицы, полученные выборкой из базы данных всех объектов относящихся к одной версии конфигурации, идентификатор которой получен из текущей сессии. Таким образом, обращаясь к таблицам базы данных и внося в них изменения, разработчик получает доступ только к выбранной при входе в систему версии конфигурации. Для всех таблиц представлений к имени таблицы добавляется префикс «V».
Модель проекции текущей версии данных выглядит в этом случае гораздо проще:
Таблица PROP_TRANSLATIONS модели данных не имеет префикса «V», так как не является представлениям по причине того, что не версионируется.
В таблице DICTIONARIES хранятся атрибуты , которые описывают справочник и его таблицу в прикладной схеме базы данных:
• NAME – название справочника, определяет название генерируемого класса ;
• CAPTION – отображаемое в экранных формах название справочника, например, для справочника контрагентов Agents это может быть название «Контрагенты» или «Справочник контрагентов»;
• TABLE_NAME – название таблицы в прикладной схеме базы данных (вследствие ограничений, накладываемых СУБД Oracle, название может содержать только буквы латинского алфавита в верхнем регистре, цифры и знак «_», при этом название должно начинаться с буквы и быть не больше 30 символов);
• CACHED – флаг кэширования, если он установлен – справочник кэшируется на компьютерах конечных пользователей. При повторном обращении к нему данные берутся из локальной копии, а не с сервера базы данных, что можно использовать для справочников с редко меняющимися данными, например, списком офисов.
Для кэшируемого справочника всегда рассылаются уведомления об изменении, поэтому не следует делать кэшируемыми часто изменяющиеся справочники .
• NOTIFICATION_ENABLED – флаг уведомления, используется для оповещения о внесенных в данные справочника изменениях. Для кэшируемого справочника уведомления рассылаются всегда независимо от состояния флага;
• PARENT_REF_OBJ_ID (FK) – атрибут используется для создания справочника древовидного типа. В качестве его значения указывается ссылка на запись таблицы DICT_TOONEREFS , которая указывает, какое из свойств выбранного справочника (полей его таблицы) будет родительским ( PARENT_ID в примере):
• 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 , которая будет использоваться для хранения данных нового справочника.
Кроме того, для каждой таблицы справочника создается представление, через которое производятся все операции чтения/записи. Представление необходимо для:
• версионирования схемы СУБД;
• поддержки часовых поясов;
• прозрачной локализации мультиязычных свойств справочников.
Рассмотрим на примере создание справочника товаров.
Описываем атрибуты и свойства нового справочника «Товары». В результате в схеме ядра сохраняются следующие метаданные:
На их основании в прикладной схеме базы данных ядром создается таблица 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) .
Урок 10. Справочники базы данных
Данный урок продолжает тему девятого урока, связанную с организацией взаимодействия с сервером базе данных (БД). В качестве БД также будем использовать «Apache Derby». Подключение к серверу и просмотр табличных объектов БД описано в предыдущем уроке.
Цель данного урока показать, как можно без программирования из готовых модулей создать приложение, позволяющее управлять следующими справочниками базы данных :
- list-measures – справочник единиц измерения
- list-currencies – справочник валют
- list-exchange – справочник курсов валют
Необходимо отметить, что все используемые в данном уроке модули могут взаимодействовать с различными серверами БД. Все зависит от того, какой модуль Вы используете в конфигурации : util-db или один из его прототипов.
Представленные в списке модули при первом старте создадут в БД справочные таблицы. Модули list-measures и list-currencies запишут в справочник инициализационные записи. Отличительная особенность справочника курсов валют list-exchange связана с возможностью подключения к WEB-сервису ЦБ РФ и получения значений различных курсов валют как за текущий месяц, так и за прошлые месяцы.
Конфигурация
Конфигурация приложения включает набор бандлов в поддиректории «configuration/bundles», которые регистрируются в файле «configuration/bundles.ini». В конфигурацию к базовому набору платформы дополнительно включены модули :
- db-connection – модуль подключения к серверу БД;
- db-objects – модуль представления структуры и записей табличных объектов БД;
- util-db-derby – модуль взаимодействия с сервером БД «Apache Derby»;
- form-locale – модуль определения текущего языка локализации.
- org.apache.derby-10.10.1000001 – JDBC-драйвер сервера БД «Apache Derby».
Листинг configuration/bundles.ini
bundles=org.apache.felix.eventadmin-1.4.8.jar@start, \ org.apache.felix.log-1.0.1.jar@start, \ util-resources-1.0.0.jar@start, \ util-logger-1.0.0.jar@start, \ gui-widgets-1.0.1.jar, \ base-jframe-1.0.0.jar, \ base-jpanel-1.0.0.jar, \ base-jdialog-1.0.0.jar, \ gui-menu-1.0.0.jar, \ gui-toolbar-1.0.0.jar, \ org.apache.derby-10.10.1000001.jar, \ util-db-derby-1.0.0.jar, \ db-connection-1.0.0.jar@start, \ db-objects-1.0.0.jar, \ form-locale-1.0.0.jar, \ list-currencies-1.0.0.jar, \ list-exchange-1.0.0.jar, \ list-measures-1.0.0.jar, \ templ-jframe-1.0.0.jar@main
Листинг configuration/menu.xml
Листинг файла описания структуры меню «configuration/menu.xml» имеет следующий вид :
С форматом структуры главного меню можно познакомиться на странице описания. В примере главное меню включает один пункт меню слева и два пункта меню справа, разделенные в описании тегом . Атрибут пункта меню name используется для определения локализованного заголовка.
К пунктам главного меню подключены один или несколько подпунктов ; тег наименованием separator используется для разделения подпунктов меню. Описание главного меню включает интуитивно-понятные атрибуты :
- name – наименование пункта/подпункта меню, используется в локализации текстовой надписи;
- image – отображаемое в подпункте меню изображение, расположенное в директории «configuration/resources/images»;
- groupId, artifactId, version – связанный с подпунктом меню бандл.
Логирование сообщений
Конфигурация приложения данного урока была использована в качестве примера для описания логирования сообщений модуля util-logger.
Связанные страницы
Скачать урок
В таблице представлены архивные файлы конфигурации и база данных Apache Derby. Главный модуль приложения можно скачать в Уроке 1. Конфигурация приложения включает JDBC-драйвер Apache Derby и утилиту взаимодействия с СУБД util-db-derby. После скачивания архивных файлов необходимо создать структуру платформы JaBricks. В файле инициализации приложения jabricks.ini необходимо указать полный путь к директории, как это описано в утилите db-connection.
| Архив | Описание | Скачать |
|---|---|---|
| configuration.lesson09.zip | Конфигурация десятого урока | скачать (3.11 Мб) |
| db.zip | База данных Apache Derby | скачать (1.69 Мб) |
Классификация таблиц в реляционных базах данных по признакам целостности и избыточности данных
Обоснование статьи и некоторые ключевые понятия;
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 или же создание статично-динамичного справочника, где описывается ряд атрибутов одной семантики или один атрибут, а дублируется лишь внешний ключ с первичным ключом последовательности. Этот же метод может использоваться в традиционной схеме модификации данных с обновлением и удалением данных.
Заключение
Данная классификация была создана мной на основе наблюдений при проектировании баз данных, а также исходя из прочитанной теории по проектированию в реляционных СУБД. Моим друзьям и знакомым, изучающим дисциплину «базы данных» и занимающимся проектированием баз данных, и мне эта классификация достаточно серьёзно упростила «жизнь» и позволила во многих ситуациях заранее выбрать наиболее подходящий и, как оказывалось потом, правильный вид таблицы для хранения в ней тех или иных данных.
Классификация может быть расширена разделением существующих видов в ней на подвиды (возможно, даже, добавлением новых видов). Также эта классификация показала, что лучше в некоторых ситуациях не использовать тот или иной вид таблиц. Некоторые виды таблиц из данной классификации лучше использовать реже (динамичные справочники). А некоторые пытаться заменить на другие (справочники-связки на связки).
Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.
- разработка баз данных
- реляционные субд
- таблицы в реляционных СУБД