Упрощенный подход к проектированию

Шаг 1

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

Шаг 2

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

Необязательные атрибуты становятся столбцами с разрешением пустого (null) значения. Обязательные атрибуты становятся столбцами типа not-null (ненулевыми).

Шаг 3

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

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

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

Шаг 4

Связи типа "многие к одному" (и "один к одному") становятся внешними ключами. При этом в качестве столбцов используются уникальные идентификаторы сущностей на конце "один".

Необязательные связи создают столбцы с разрешением пустого (null) значения. Обязательные связи создают столбцы типа not-null (ненулевые).

Рисунок F-1. Пример

Шаги 1-4 годятся для большинства несложных проектов. Прежде чем мы переходить к более сложным случаям, предполагающим использование исключающих дуг и подтипов, рассмотрим кратко, как создаются индексы.

Шаг 5. Проектирование индексов

Индексы создаются для:

первичного ключа (уникальный индекс)

внешних ключей и

индексы, предусмотренные матрицей функция/атрибут.

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

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

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

Последующее слежение за работой СУРБД позволит определить, какие индексы и при каких обстоятельствах используются.

Пример

Для трех вышеназванных таблиц можно выбрать следующие индексы:

Код в AIRPORTS	(Уникальный индекс)
Код в AIRLINES	(Уникальный индекс)
Код родительской авиалинии в AIRLINES	(Неуникальный индекс)
Номер рейса и Код авиалинии в AIRLINE ROUTES	(Составной уникальный индекс)
Код аэропорта вылета в AIRLINE ROUTES	(Неуникальный индекс)
Код аэропорта назначения в AIRLINE ROUTES	(Неуникальный индекс)

Шаг 6. Проектирование подтипов

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

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

Существует два основных варианта представления подтипов (каждая из которых имеет свои преимущества и недостатки):

все подтипы в одной таблице

таблица для каждого подтипа.

Все подтипы в одной таблице

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

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

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

Все это имеет отношение к каждому подтипу, к каждому подтипу данного подтипа и т.п. Разница в том, что все столбцы, создаваемые для подтипов, имеют тип null (необязательность). Обязательный атрибут (или связь) для одного подтипа не должен использоваться для другого - таким образом, все они должны быть необязательными, целостность же обеспечивается либо прикладными программными средствами, либо через обзор с опцией контроля (check option).

В таблицу должен быть добавлен по меньшей мере еще один ненулевой столбец, обозначающий тип (TYPE) и включаемый в первичный ключ.

Например:

TYPE

char

not null

с предписанным значением для каждого подтипа

Для каждого из подтипов можно создать реляционный обзор, открывающий доступ только к используемым данным; с функциональной точки зрения он отражает действия, производимые над сущностями, имеющими подтипы. Он должен включать в себя производные столбцы для данного подтипа, всех его подтипов и всех его супертипов. В обзор можно включить фразу WHERE, проверяющую правильность указания внешних ключей и обязательность столбцов в контексте столбца Type. В отдельных реализациях эти условия могут проверяться при помощи фразы WITH CHECK OPTION.

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

Рисунок F-2. Пример

Обратите внимание на то, что два столбца именуются "Номер...", при этом имя столбца содержит имя сущности, уточняющее его смысл. Кроме того, столбцы "Количество" и "Код_продукта" сделаны необязательными, поскольку ни один из них не связан с ПРОЧЕЙ СТРОКОЙ ЗАКАЗА.

Столбец "Тип" добавлен, чтобы иметь возможность различать подтипы сущности СТРОКА ЗАКАЗА.

При этом код "СОП" означает СТРОКУ, ОПИСЫВАЮЩУЮ ПРОДУКТ, а "ПС" - ПРОЧУЮ СТРОКУ.

Описание реляционных обзоров на языке SQL:

CREATE VIEW OTHER_ORDER_LINES AS /* обзор ПРОЧИЕ_СТРОКИ_ ЗАКАЗА */ SELECT LINE_NUMBER, /* номер строки */ ORDER_NUMBER, /* номер заказа */ DESCRIPTION, /* описание */ TAX_COMMENT, /* комментарии */ TYPE /* тип */ FROM ORDER_LINES /* таблица СТРОКИ_ЗАКАЗА */ WHERE TYPE='OOL' /* ТИП='ПС' */ WITH CHECK OPTION CREATE VIEW PRODUCT_ORDER_LINE AS /* обзор СТРОКА_ ОПИСЫВАЮЩАЯ_ПРОДУКТ */ SELECT LINE_NUMBER, /* номер строки */ ORDER_NUMBER, /* номер заказа */ DESCRIPTION, /* описание */ QUANTITY, /* количество */ PRODUCT_CODE, /* код продукта */ TYPE /* тип */ FROM ORDER_LINES /* таблица СТРОКИ_ЗАКАЗА */ WHERE TYPE='OOL' /* ТИП='СОП' */ AND QUANTITY NOT NULL AND EXISTS (SELECT NULL FROM PRODUCTS WHERE /* таблица ПРОДУКТЫ */ PRODUCTS.CODE=ORDER_LINES.PRODUCT_CODE) WITH CHECK OPTION

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

Таблица для одного подтипа

Таблицы, создаваемые для отдельных подтипов, должны учитывать все возможные вхождения.

Если мы имеем дело с иерархией подтипов, состоящей из нескольких уровней, таблицы создаются для подтипов верхнего уровня. (Для подтипов всех последующих уровней создаются обзоры.)

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

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

При работе с супертипом вам может также пригодиться обзор типа UNION.

Рисунок F-3. Пример

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

Рассмотрим обзор для подтипа E:

CREATE VIEW E AS SELECT e, b1, b2, a1, G_g, type, a2, parent_a1, parent_G_g, parent_type FROM B WHERE type='E' AND e not null AND EXISTS (SELECT NULL FROM B WHERE B.a1 = E.Parent_a1 AND B.G_g = E.Parent_G_g AND B.Type = E.Parent_Type) WITH CHECK OPTION И для полноты впечатления рассмотрим обзор типа UNION для A: CREATE VIEW A AS SELECT * FROM B UNION SELECT * FROM C Символ * в операторе SELECT означает выборку всех столбцов.

Преимущества и недостатки

Все подтипы в одной таблице	Таблица для одного подтипа
Преимущества	Преимущества
Все в одном месте	Совокупность условий более наглядно распределяется по подтипам
Простота доступа к супертипу и подтипам	Программы имеют дело только с теми таблицами, которые связаны с интересующими нас подтипами
Требуется меньше таблиц
Недостатки	Недостатки
Чересчур высокий уровень обобщения	Много дополнительных таблиц
Трудность объединения различных наборов столбцов с различной целостностью	Беспорядочное объединение столбцов в обзоре типа UNION
Возможны "узкие места", в частности при использовании механизмов блокировки	Проблемы с быстродействием при обработке обзора типа UNION
Столбцы для подтипов должны стать необязательными	Коррекция супертипа невозможна, что мешает выполнению функций
В некоторых СУРБД возникает опасность превышения допустимого количества столбцов или выхода за пределы отведенного пространства (за счет хранения пустых значений)

<

Шаг 7. Исключающая связь

Существует два основных средства обработки исключающих связей:

общий домен

заданные явно внешние ключи.

Общий домен

Если оставшиеся внешние ключи можно включить в один домен (идентичный формат), создайте два столбца:

Идентификатор связи

Идентификатор сущности.

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

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

Рисунок F-4. Пример

В таблице TIMESHEET_ENTRIES (СТРОКИ_ТАБЕЛЯ) связи "по ЭТАПУ ПРОЕКТИРОВАНИЯ" и "о ДЕЯТЕЛЬНОСТИ ВНЕ ПРОЕКТА" реализуются с помощью столбцов:

Строка_табеля_по (Timesheet_for)	char	3	not null	(значение 'ЭП' и 'ДВП')
Код_деятельности (Activity_code)	char	7	not null

Обратите внимание на развернутость имен, присвоенных столбцам. Значение "кода_деятельности" равно коду либо ЭТАПА ПРОЕКТИРОВАНИЯ, либо ДЕЯТЕЛЬНОСТИ ВНЕ ПРОЕКТА. Поскольку связи являются обязательными, столбцы имеют тип not null.

Явное задание внешних ключей

Если полученные внешние ключи не объединяются в домен, создайте соответствующие внешним ключам столбцы для каждой связи, покрытой исключающей дугой, и сделайте эти столбцы необязательными (null). В прикладной программе следует учесть, что только одно значение может быть введено (или должно быть введено, если связи обязательные).

Вернемся к нашему примеру, но на этот раз предположим, что код этапа проектирования является целым числом (integer).

Рисунок F-5. Снова предыдущий пример

В результате добавятся столбцы:

Код_этапа_проектирования (Project_units_code)	integer	5	null
Код_деятельности_вне_проекта Non-project_activities_code)	char	7	null

Преимущества и недостатки

Общий домен	Явное задание внешних ключей
Преимущества	Преимущества
Используются только два столбца Необязательность поддерживается средствами СУРБД	Видны условия соединения
Недостатки	Недостатки
Оба столбца должны использоваться во всех операциях соединения	Дополнительные столбцы Необязательность столбцов и их использование реализуются прикладными средствами

Содержание раздела