Теория и практика построения баз данных (1088289), страница 48
Текст из файла (страница 48)
Проблема с этой схемой состоит в том, что мы дублируем данные о предметах. тем самым порождая аномалии модификации. Если, например, изменится расписание занятий по предмету 10, потребуется изменить много строк. Рассмотрим также аномалии вставки и удаления: как мы можем добавить новый предмет, пока на него не записался ни один студент? И что произойдет, если студент с номером 300 откажется от предмета 40? Очевидно, что такая стратегия неработоспособна. НомерПредмета Часыэанятнй Прочие данные о продмаге НомерПредмета ПРЕДМЕТ Рис. 6.12. Неправильное представление связи Мьч Человвк Джонс Смит Пвркс 1. Миртл Пайпс П и лсп ю ихкли но 200, 400 600 100 ЗОО Отношение ЧЕЛОВЕК1 Человек финвнсирувмоеЛицо б00, 700 400 Отношение ЧЕЛОВЕК2 Человек Спонсор 220 Г аеа 6.
л 6. Проектирование баз данных в рамках модели «сущность — связь» Ограничение ссылочной целостности: Значение атрибута гринансируемоепицо должно существовать среди значений атрибута Человек б Ограничение ссылочной целостности; Значение атрибута Спонсор должно существовать среди значений атрибута Человек в Рис. 6.16. Пример рекурсивной связи 1:1: в — данные для рекурсивной связи 1:1; б — первый вариант представления рекурсивной связи 1:1; е — второй вариант представления рекурсивной связи 1:1 Рассмотрим теперь рекурсивные связи М;Х. Связь У-КОГО-ЛЕЧИТСЯ на рис. 6.15, в представляет ситуацгпо, в которой врачи лечат друг друга.
Данные для этого примера приведены на рис. 6.18, а. Как и для других связей М:Х, нам необходимо создать таблицу пересечения, в которой будут показаны связанные между собой пары строк. В первом столбце находится пмя того, кто лечит, а во втором — пмя того, кто лечится. Эта структура изображена на рпс. 6.18, б. Р екурспвные связи, таким образом, представляются точно так же, как и другие виды связей.
Однако строки таблиц могут при этом играть две различные роли. Одни являготся родительскими, другие — дочерними. Если некоторый ключ Преобразование моделей «сущность — связь» 221 предполагается сделать родительским, и строка не имеет роди~ела, ее значение будет пустым. Если некоторый ключ предполагается сделать дочерним, и строка не имеет потомка, ее значение также будет пустым. в НомерКлиентв ДвнныеКлиентв КемПриведвн Ограничение ссыпочной целостности: Значение атрибута КемПриведен должно существовать среди значений атрибута НомерКпиентв б Рис 617 Пример рекурсивнои связи1Н а данные д я связи КЕМ ПРИВЕДЕН б — представление рекурсивной связи 1ты с помощью отношений Представление тернарных связей и связей высших порядков тернарные связи (гегпагу ге)аггопзтг|р) представляются с применением подходов, описанных выше, но зачастую есть особые соображения, которые необходимо документировать в виде положений делового регламента.
Рассмотрим, например, сущности ЗАКАЗ, КЛИЕНТ и СЛУЖАЩИЙ. В большинстве случаев мы можем относиться к этой тернарной связи как к двум бинарным. Допустим, что заказ всегда делается одним покупателем, но один и тот же покупатель может делать много заказов. Следовательно, бинарная связь между сущностями ЗАКАЗ и КЛИЕНТ имеет вид Х:1. Аналогичным образом, предположим, что заказ может выполняться только одним служащим, но один и тот же служащий может выполнять много заказов.
Исходя из этого, бинарная связь между сущностями ЗАКАЗ и СЛУЖАЩИЙ также имеет вид Х:1. Обе эти связи могут быть представлены с использованием вышеописанных подходов. Первую связь мы представим, поместив ключ отношения КЛИЕНТ в от.— ношение ЗАКАЗ, а вторую — поместив в зто же отношение ключ отношения СЛУЖАЩИЙ. Таким образом, мы создали тернарную связь между сугцностями ЗАКАЗ, КЛИЕНТ и СЛУЖАЩИЙ в виде двух отдельных бинарных связей.
Лачяц1ий вдаа Пациент Смит Джонс Паркс Смит Абернати Франклин Абернати Джонс Франклин а Отношение ВРАЧ Имя Прочие атрибуты Таблица ПРОДАВЕЦ Отношение ЛЕЧЕНИЕ ПРСЧ Человек Спонсор Таблица КЛИЕНТ Таблица ЗАКАЗ 222 Гл ава 6. Проектирование баз данных в рамках модели «сущность — связь» Ограничения ссыпочной целостности: Значение атрибута Врач в отношении ЛЕЧЕНИЕ ПРСЧ должно существовать среди значений атрибута Имя в отношении ВРАЧ Значение атрибута Пациент в отношении ЛЕЧЕНИЕ ПРСЧ должно существовать среди значений атрибута Имя в отношении ВРАЧ б Рис. 6.18.
Пример рекурсивной связи М:М: а — данные для связи У-КОГО-ЛЕЧИТСЯ; б — представление рекурсивной связи МГМ с помощью отношений Предположим, однако, что деловой регламент содержит положение, согласно которому каждый покупатель может размещать заказы только у конкретного служащего. В этом случае тернарная связь ЗАКАЗ:КЛИЕНТ:СЛУЖАЩИЙ ограничивается дополнительной бинарной связью вида Х:1 между сущностями КЛИЕНТ и СЛУЖАЩИЙ. Чтобы представить данное ограничение, нам необходимо добавить ключ отношения СЛУ)КАЩИЙ в отношение КЛИЕНТ. Получившиеся три отношения будут выглядеть следующим образо»с Преобразование моделей «сущность — связь» 223 ЗАКАЗ (НомерЗаказа, неключевые атрибуты данных, НомерКлиента, НомерСлужащего) ПОКУПАТЕЛЬ (НомерКлиента, неключевые атрибуты данных, НомерСлужащего) КЛЕРК (НомерСлужащего, неключевые атрибуты данных) Ограничение, устанавливающее, что конкретному клиенту может звонить только конкретный служащий, означает, что только определенные значения атрибутов НомерКлиента и НомерСлужащего ьтогут совместно супгествовать в отношении ЗАКАЗ.
К сожалению, нет способа выразить это ограничение в терминах реляционной модели. Однако оно должно быть документировано в проекте, а реализация его должна обеспечиваться хранимыми процедурами или прикладными программами (рис. 6.19). Рис. 6.19. Бинарное ограничение «ДОЛЖНО БЫТЬ» Кроме того, существуют такие типы бинарных ограничений как «НЕ ДОЛЖНО !тЫТЬ» и «ДОЛЖНО ВКЛЮЧАТЬ». Ограничение «НЕ ДОЛЖНО БЫТܻ— это бинарная связь, указывающая комбинации, которые не допустимы в тернарпой связи. Например, на тернарную связь РЕЦЕПТ:ЛЕКАРСТВО:ПОКУПАТЕЛЬ может быть наложено ограничение в виде таблицы АЛЛЕРГИЯ, где указаны лекарства, которые покупателю не разрешается принимать (рис.
6.20). Таблица РЕМОНТ Таблица ЛЕКАРСТВО Таблица РАБОТА Таблица АЛЛЕРГИЯ Таблица АВТОМОБИЛЬ-РЕМОНТ Таблица РЕЦЕПТ 224 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» Рис. 6.20, бинарное ограничение «НЕ ДОЛЖНО БЫТЬ Ограничение «ДОЛЖНО ВКЛЮЧАТЬ» — зто бинарная связь, указывающая все комбинации, которые должны присутствовать в тернарной связи. Рассмотрим, например, связь АВТОМОБИЛЬ:РЕМОНТ:РАБОТА. Пускай ремонт включает в себя определенное количество работ, каждая из которых должна быть выполнена, чтобы ремонт был успешным. В зтом случае, если выполняется ремонт автомобиля, то все работы в рамках зтого ремонта должны появиться в качестве строк отношения АВТОМОБИЛЬ-РЕМОНТ (рис.
6.21). Преобразование моделей «сущность — связыь 225 Рис. 6.21. Бинарное ограничение «ДОЛЖНО ВКЛЮЧАТЬ» Ни один из трех типов бинарных ограничений, описанных здесь, не может быть представлен в терминах реляционной модели, Все связи должны представ:иться в виде комбинаций бинарных связей.
Однако ограничения должны быть локументированы в проекте базы данных. Представление связей типа «ЕСТЬ» (подтипов) Стратегия представления подтипов, или связей типа «ЕСТЬ», несколько отлича- ется от стратегии, используемой для связей типа «ИМЕЕТ». Рассмотрим в каче- стве примера сущность КЛИЕНТ с атрибутами НоиерКлиента, ИияКлнента и Сумма- 226 Глава 6. Проектирование баз данных в рамках модели сущность — связь» Пример проекта 227 КОплате.
Допустим, что сеть три подтипа сущности КЛИЕНТ: ФИЗИЧЕСКОЕ ЛИЦО, ТОВАРИЩЕСТВО н КОРПОРАЦИЯ, имеющие следующие атрибуты: ФИЗИЧЕСКОЕ ЛИЦО: Адрес, НомерСоциальнойСтрахоаки ТОВАРИЩЕСТВО: ИмяУпрааляющегоПартнера, Адрес, ИНН КОРПОРАЦИЯ: ДоаеренноеЛицо, Телефон, ИНН Чтобы представить эту структуру с помощью отношений, мы введем одно отношение для надтипа (КЛИЕНТ) и по одному отношениго для каждого подтипа. Затем мы поместим каждый из атрибутов падтипа в отношение, которое представляет надтип, а каждый из атрибутов подтипов — в отношения, представляющие подтипы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
