Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование моделей данных. Учебное пособие
.pdf
11
Рисунок 10 – Общая ER-диаграмма
4. Даталогическое проектирование
4.1. Формирование предварительных отношений
Предварительные отношения (что соответствует этапу 3
проектирования реляционной базы данных) формируются на основе
правил, описанных ниже [1].
В качестве примера рассмотрим вариации связи «Сотрудник
работает в Кабинете» из предметной области «Медицинский центр»,
что поможет продемонстрировать формирование предварительных
отношений по разным правилам.
Правило 1
Если степени бинарной связи — 1:1 и класс принадлежности
обеих сущностей к связи обязательный, то формируют одно
отношение, ключом этого отношения может быть ключ любой из двух
сущностей.
12
Например, для ER-сегмента, представленного на рисунке 11.
Рисунок 11 – Пример ER-сегмента для правила 1
Будет получено отношение по правилу 1 (рисунок 12).
Рисунок 12 – Предварительное отношение по правилу 1
Правило 2
Если степени бинарной связи — 1:1, а класс принадлежности
сущности к связи для одной — обязательный, а для другой —
необязательный, то формируется два отношения: по одному для
каждой сущности.
При этом ключом отношения является ключ соответствующей
сущности. Кроме этого, ключ сущности с необязательным классом
принадлежности добавляется в качестве атрибута в отношение для
сущности с обязательным классом принадлежности.
Например, для ER-сегмента, представленного на рисунке 13.
Рисунок 13 – Пример ER-сегмента для правила 2
Будет получено отношение по правилу 2 (рисунок 14).
13
Рисунок 14 – Предварительное отношение по правилу 2
Правило 3
Если степень бинарной связи — 1:1, а класс принадлежности
обеих сущностей к связи необязательный, то формируется три
отношения, по одному для каждой сущности и одно для связи.
При этом ключом в первых двух отношениях является ключ
соответствующей сущности, отношение для связи должно содержать
ключи обеих сущностей, в отношении для связи в качестве ключа
можно принять ключ любой из сущностей.
Например, для ER-сегмента, представленного на рисунке 15.
Рисунок 15 – Пример ER-сегмента для правила 3
Будет получено отношение по правилу 3 (рисунок 16).
Рисунок 16 – Предварительное отношение по правилу 3
14
Правило 4
Если степень бинарной связи 1:N и класс принадлежности
N-связной сущности обязательный, то формируют два отношения, по
одному для каждой сущности.
При этом ключом в каждом отношении является ключ
соответствующей сущности. Кроме этого, в отношение для N-связной
сущности добавляется в качестве неключевого атрибута ключ
односвязной сущности.
Например, для ER-сегмента, представленного на рисунке 17.
Рисунок 17 – Пример ER-сегмента для правила 4
Будет получено отношение по правилу 4 (рисунок 18).
Рисунок 18 – Предварительное отношение по правилу 4
Правило 5
Если степень бинарной связи 1:N и класс принадлежности
N-связной сущности необязательный, то формируют три отношения:
по одному для каждой сущности и одно для связи.
При этом ключом в двух первых отношениях является ключ
соответствующей сущности, отношение для связи должно содержать
ключи обеих сущностей, при этом ключом отношения для связи
является ключ N-связной сущности.
Например, для ER-сегмента, представленного на рисунке 19.
15
Рисунок 19 – Пример ER-сегмента для правила 5
Будет получено отношение по правилу 5 (рисунок 20).
Рисунок 20 – Предварительное отношение по правилу 5
Правило 6
Если степень бинарной связи N:N, то формируется три
отношения: по одному для каждой сущности и одно для связи.
При этом ключом в первых двух отношениях является ключ
соответствующей сущности, отношение для связи должно содержать
ключи обеих сущностей, которые совместно образуют ключ данного
отношения.
Например, для ER-сегмента, представленного на рисунке 21.
Рисунок 21 – Пример ER-сегмента для правила 6
Будет получено отношение по правилу 6 (рисунок 22).
16
Рисунок 22 – Предварительное отношение по правилу 6
Правило 7
При наличии тернарной связи необходимо использовать 4
отношения: по одному для каждой сущности, где ключом будет
являться ключ соответствующей сущности, и одно для связи, где ключ
отношения содержит ключи всех сущностей.
При наличии n-арной связи потребуется n+1 отношение.
Например, для ER-сегмента, представленного на рисунке 23.
Рисунок 23 – Пример ER-сегмента для правила 7
Будет получено отношение по правилу 7 (рисунок 24).
17
Рисунок 24 – Предварительное отношение по правилу 7
Возможны ситуации, когда экземпляры некоторой сущности
должны играть разные роли в деятельности организации.
Например, сотрудник может быть медсестрой, врачом и т.д.
Тогда обобщающая сущность называется супертипом, а ролевые
сущности – подтипом.
Правило 8
Супертипу сущности соответствует одно отношение, где
ключом является ключ сущности, общие для всех подтипов атрибуты
включают в это отношение. Каждому подтипу соответствует ровно
одно отношение, где первичный ключ —ключ обобщающей сущности.
Например, для ER-сегмента, представленного на рисунке 25.
Обычно подтипы имеют общие атрибуты, например ФИО, адрес,
18
телефон, и отличные друг от друга атрибуты. Например, у врача
существует узконаправленная специальность.
Рисунок 25 – Пример ER-сегмента для правила 8
Если между подтипами есть связи, то строят такое число
отношений, которое определяется ранее описанными правилами,
причем каждый подтип трактуется как обычная сущность. Медсестра
ассистирует Врачу.
Будет получено отношение по правилу 8 (рисунок 26).
Рисунок 26 – Предварительное отношение по правилу 8
Переход от ER-диаграмм к предварительным отношениям
для «Медицинского центра».
Переход к предварительным отношениям происходит согласно
правилам (пункт 4.1):
19
1. Сотрудник состоит на Должности.
По правилу 1 формируется 2 отношения:
• Должность(Должность);
• Сотрудник(№паспорта, Должность).
2. Сотрудник работает по времени в Кабинете.
По правилу 2 формируется 3 отношения:
• Сотрудник(№паспорта);
• Кабинет(№кабинета);
• ГрафикРаботы(№паспорта, №кабинета).
3. Пациент записывается к Сотруднику на Услугу.
По правилу 4 формируется 4 отношения:
• Пациент(№полиса);
• Сотрудник(№паспорта);
• Услуги(Услуги);
• Записи(№полиса, №паспорта, Услуги).
4. Сотрудник ставит Диагноз Пациенту.
По правилу 4 формируется 4 отношения:
• Сотрудник(№паспорта);
• Диагноз(Диагноз);
• Пациент(№полиса);
• ИсторияБолезни(№паспорта, Диагноз, №полиса).
5. Услуги назначаются в соответствии с Диагнозом.
По правилу 3 формируется 3 отношения:
• Услуги(Услуги);
• Диагноз(Диагноз);
• Назначения(Услуги, Диагноз).
6. Услуги имеют Тип.
По правилу 1 формируется 2 отношения:
• ТипУслуги(Тип);
• Услуги(Услуги, Тип).
7. Должность является частью Услуги.
По правилу 3 формируется 3 отношения:
• Должность(Должность);
• Услуги(Услуги);
• Часть(Должность, Услуги).
4.2. Заполнение предварительных отношений атрибутами
На данном этапе сформированные на предыдущем этапе
отношения дополняются неключевыми атрибутами. Причем каждый
неключевой атрибут может входить только в одно отношение.
Добавление неключевых атрибутов для отношений области
«Медицинский центр»:
20
1. Пациент (№полиса, Фамилия, Имя, Отчество, Дата рождения,
Пол, Адрес, Телефон, e-mail).
2. Сотрудник (№паспорта, Фамилия, Имя, Отчество, Дата
рождения, Пол, Адрес, Образование, №ТрудовойКнижки,
IDДолжность, Телефон, e-mail).
3. Должность (IDДолжность, Название, Тип, Описание).
4. Кабинет (№кабинета, Название, Тип).
5. Услуги (IDУслуги, Название, Описание, IDТип, Цена).
6. ТипУслуги (IDТип, Название, Описание).
7. Диагноз (IDДиагноз, Название, Симптомы).
8. ГрафикРаботы (№паспорта, Время, №кабинета).
9. Записи (IDЗаписи, №полиса, №паспорта, IDУслуги, Время,
Стоимость, Оплата, Примечание).
10. ИсторияБолезни (IDБолезни, №паспорта, IDДиагноз,
№полиса, Дата, Лечение).
11. Назначения (IDУслуги, IDДиагноз, Примечание).
12. Часть (IDДолжность, IDУслуги).
Так как Сотрудник может работать в одном кабинете в разное
время, первичный ключ в отношении «График работы» преобразован к
составному ключу, включающему атрибуты: №паспорта, Время.
4.3. Проверка отношений на соответствие нормальным
формам
4.3.1. Метод нормальных форм
Ранее метод нормальных форм являлся основным для
проектирования реляционных БД, когда БД состояли из небольшого
количества таблиц. В настоящее время этот метод используется только
для проверки правильности проектирования БД. Рассмотрим его более
подробно.
Основная цель, которую преследует разработчик при
проектировании реляционной БД, заключается в группировке
атрибутов в отношения таким образом, чтобы минимизировать
избыточность данных.
Чтобы продемонстрировать проблемные ситуации, связанные с
избыточностью данных, а также возможность проектирования
методом нормальных форм, рассмотрим пример, основанный на
предметной области «Медицинский центр».
Пример. Пусть требуется создать БД для хранения информации
о записи пациента к врачу. Причем в БД требуется хранить
следующую информацию:
1. ФИО пациента.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]