Лекция 8. Развитой пример применения e-r проектирования.

Рассмотрим пример, приведенный в разделе «Пример проектирования БД». В том разделе мы строили модель данных, описывающую деятельность аптекоуправления, используя алгоритм нормализации. Теперь же покажем, что E-R методика приводит к тому же результату.

Опираясь на очевидные соображения и определение сущности как объекта, существующего в предметной области, выделим сущности из постановки задачи. Результатом станут три сущности : Аптека (первичный ключ - № аптеки), Лекарство (код лекарства) и Поставщик (ГНИ). Как следует из описания предметной области, все эти сущности связаны между собой. (см. диаграмму …).

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

Далее для построения информационной модели необходимо проанализировать связи между таблицами. В зависимости от степени связи и класса принадлежности принимается решение о механизмах реализации этих связей в модели.

Аптека

Поставщик

Лекарство

Рис. 35 . E-R диаграмма для задачи о деятельности аптекоуправления.

Связи «Лицензия» и «Наличие» являются бинарными. Если ввести предположение, что один поставщик может поставлять несколько лекарств и несколько поставщиков могут поставлять одно лекарство (те же соображения относятся и к аптекам), то степень этих связей - M:N. Классы принадлежности сущностей можно определить из следующих соображений. Каждая лицензия должна выдаваться конкретному поставщику для работы с определенным лекарственным препаратом. Можно представить себе ситуацию, в которой некоторые поставщики не имеют лицензий для работы с определенными препаратами, и на некоторые лекарства могут не быть выданы лицензии. Это позволяет говорить, что класс принадлежности сущностей «Поставщик» и «Лекарство» в связи «Лицензия» является необязательным.

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

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

Окончательный вид модели данных представлен на рис. 36.

Из диаграммы 2 видно, что полученные в результате процедуры E-R проектирования структуры баз данных совпадают с приведенными в таблицах 3-8. На этом этап построения концептуальной модели заканчивается.