Пример 39

Этап 1. Выберем предметную область ПОСТАВКА ДЕТАЛЕЙ.

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

ПОСТАВЩИКИ (PN,...)

ДЕТАЛИ (DN,...)

ГОРОДА (GOR,...)

СТАТУСЫ (ST,...)

Статусы можно было не определять, как сущность.

Многоточиями обозначены неключевые атрибуты сущности.

Этап 2. На основе здравого смысла опишем ER-диаграмму.

ПОСТАВЩИКИ (М, Н) поставляют (М, Н) ДЕТАЛИ (правило 6)

ПОСТАВЩИКИ (М, О) проживают_в (1, Н) городах (правило 4)

ПОСТАВЩИКАМ (М, О) присваиваются (1, Н) СТАТУСЫ (правило 4)

ГОРОДА (М, О) имеют (1, Н) СТАТУСЫ (правило 4)

Такое описание ER-диаграммы нужно понимать следующим образом:

Каждый поставщик может поставлять, а может не поставлять (“Н” у поставщика) несколько разных типов деталей (“М” у детали). Каждая деталь может поставляться, а может не поставляться (“Н” у детали) несколькими поставщиками (“М” у поставщика).

Каждый поставщик обязательно (“О” у поставщика) проживает только в одном городе (“1” у города). В конкретном городе может и не быть поставщика (“Н” у города), однако в одном городе могут проживать несколько поставщиков (“М” у поставщика).

Каждому поставщику обязательно (“О” у поставщика) присваивается только один статус (“1” у статуса). Каждое значение статуса (целое число), например 50, может быть не связано ни с каким поставщиком (“Н” у статуса). Нескольким поставщикам может быть присвоен одинаковый статус, например, если они проживают в одном городе (“М” у поставщика).

Каждый конкретный город имеет всегда один и тот же статус (“1” у статуса), причем город обязательно имеет статус (“О” у города). Каждому значению статуса может соответствовать несколько городов, например, областной город (Санкт-Петербург) и все города области (Кириши, Зеленогорск и пр.) (“М” у города). Причем, могут быть такие значения статуса, которые не связаны ни с каким городом (“Н” у статуса).

Этап 3. Формируем набор предварительных отношений в соответствии с описанием ER-диаграммы и перечисленными выше правилами.

· Для связи поставляют (правило 6):

Поставщики (PN,...)

Детали (DN,...)

Поставщики_Детали (PN, DN,...)

· Для связи проживают_в (правило 4):

Поставщики (PN, GOR,...). Здесь GOR добавлен по правилу 4 как простой атрибут.

Города (GOR,...)

· Для связи присваиваются (правило 4):

Поставщики (PN, GOR, ST,...). Здесь ST добавлен по правилу 4 как простой атрибут.

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

Поставщики (PN, GOR,...), а затем уже к нему добавляем по правилу 4 атрибут ST.

Статусы (ST,...)

· Для связи имеют (правило 4):

Города (GOR, ST,...). Здесь ST добавлен по правилу 4 как простой атрибут.

Статусы (ST,...)

Этап 4. Добавляем в полученные отношения неключевые атрибуты. В результате получаем следующий набор отношений (таблиц):

1. Поставщики (PN, PIM, GOR, ST), где PIM – имя поставщика (добавленный неключевой атрибут),

2. Детали (DN, DIM, CENA), где DIM – имя, а CENA – цена детали (добавленные неключевые атрибуты),

3. Поставщики_Детали (PN, DN, КOL), где КOL – количество поставляемых деталей (добавленный неключевой атрибут). По смыслу эта таблица будет содержать информацию о поставках. Поэтому ее можно назвать не “Поставщики_Детали”, а “Поставки”.

4. Города (GOR, ST),

5. Статусы (ST). Получили отношение с одним атрибутом (таблицу с одним столбцом), что бессмысленно. Атрибут ST присутствует в других отношениях. Поэтому полученное отношение можно отбросить.

Этап 5. Этот этап проектировщики базы данных часто не выполняют [6], а напрасно, так как полученные отношения могут не находится в «сильной» (хотя бы в третьей) нормальной форме, что и оказалось в рассматриваемом примере. Для этого надо на заданном множестве атрибутов построить множество функциональных зависимостей или рассмотреть каждое отношение и в нем найти функциональные зависимости.

Так, для отношения “Поставщики” справедливо множество зависимостей

F_{Поставщики} = {PN ® PIM, PN ® GOR, PN ® ST, GOR ® ST}.

Анализ этих зависимостей показывает, что зависимость PN ® ST (подчеркнута) транзитивно следует из зависимостей:

PN ® GOR и GOR ® ST

Поэтому отношение “Поставщики” не находится в третьей нормальной форме. Что делать?

В этом случае рекомендуется “разорввать” транзитивную зависимость, декомпозируя отношение на два отношения, например, таких:

Поставщики (PN, PIM, GOR) и Города (GOR, ST).

Выполнив декомпозицию, нужно проверить, обладает ли она свойством соединения без потерь информации и свойством сохранения функциональных зависимостей, как это было сделано в разделе 1.8.2.1. Предложенная декомпозиция обладает этими свойствами. Кроме того отношение Города (GOR, ST) уже было получено ранее.

Теперь оба отношения находятся в нормальной форме Бойса-Кодда.

Почему же такое случилось для отношения “Поставщики”?

Это произошло оттого, что здравый смысл иногда нас поводит. В описании ER-диаграммы мы перестарались и дали лишнюю связь, которая появилась из-за лишней сущности СТАТУСЫ:

ПОСТАВЩИКАМ (М, О) присваиваются (1, Н) СТАТУСЫ (правило 4)

Если этой связи не было бы, то все было бы хорошо.

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

Легко убедиться в том, что остальные отношения также находятся в нормальной форме Бойса-Кодда.

Таким образом, получаем окончательный набор отношений (таблиц), который совпадает с набором отношений, полученным по методу синтеза для этой же предметной области:

R1: Поставщики (PN, PIM, GOR),

R2: Детали (DN, DIM, CENA),

R3: Поставки (PN, DN, КOL),

R4: Города (GOR, ST)

Этап 6. Поскольку результат проектирования совпадает с результатом, полученным по методу синтеза, то свойство соединения без потерь информации выполняется.

Пример 40. Спроектируем методом ER-диаграмм базу данных для предметной области ВСТУПИТЕЛЬНЫЕ ЭКЗАМЕНЫ В ВУЗ. В примере 35 эта база данных была спроектирована методом синтеза.