Теория и практика построения баз данных (1088289), страница 49
Текст из файла (страница 49)
На этом этапе отношения подтипов не имеют ключей. Чтобы создать ключ, мы добавим к каждому из подтипов ключ надтипа — НомерКлиента. Окончательный список отношений выглядит следующим образом: КЛИЕНТ (НомерКлиента, ИмяКлиента, СуммаКОплате) ФИЗИЧЕСКОЕ-ЛИЦО (НомерКлиента, Адрес, НомерСоциальнойСтрахоаки) ТОВАРИЩЕСТВО (НомерКлиента, ИмяупрааляющегоПартнера, Адрес, ИНН) КОРПОРАЦИЯ (НомерКлиента, ДоаеренноеЛицо, Телефон, ИНН) Обратите внимание, что при такой структуре снять между строкой отношения КЛИЕНТ и строкой одного из подтипов имеет вид 1:1. Ни один клиент не имеет более одной строки в отношении подтипа, и каждому подтипу однозначно соответствует одна из строк надтипа.
В зависимости от ограничений, накладываемых приложением, возможна ситуация, когда строке отношения КЛИЕНТ будет соответствовать несколько строк, каждая из которых будет принадлежать отдельному подтипу. Но ни одной строке отношения КЛИЕНТ не может соответствовать более одной строки в одном и Глом же отношении подтипа. Может случиться так, что у одного или нескольких подтипов будут собственныс ключи. Например, приложение может запрашивать атрибут НомерКорпоратианогоКлиента, который отличается от атрибута НомерКлиента.
В этом случае ключом отношения КОРПОРАЦИЯ является НомерКорпоратианогоКлиента. Поскольку связь между сущностями КЛИЕНТ и КОРПОРАЦИЯ имеет вид 1:1, ее можно установить, поместив ключ одного из отношений в другое. В большинстве случаев более удачным решением считается помещение ключа отношения надтипа в ключ отношения подтина. В этой ситуации отношение КОРПОРАЦИЯ будет иметь следующую структуру: КОРПОРАЦИЯ (НомерКорпоратианогоКлиента, НомерКлиента, ДоаеренноеЛицо, Телефон, ИНН) Пример проекта Рисунок 6.22 — это копия Ей-диаграммы, первоначально приведенной в главе 3 на рис.
3.9. Он содержит все основные элементы, используемые в Ейтдиаграьгмах. Чтобы представить эту диаграмму с помощью отношений, мы сначала для каждой сущности создадим соответствующее отношение. В приведенной ниже таблице указаны ключи всех созданных нами отношений. Отношение СОТРУДНИК ИНЖЕНЕР ГРУЗОВИК РАБОТА КЛИЕНТ КЛИЕНТ-РАБОТА ИНЖЕНЕР-СЕРТИФИКАТ СЕРТИФИКАТ Ключ НомерСотрудника НомерСотрудника НомерЛ ицензин НомерСчета НомерКлиента (НомерСчета, НомерКлиента) (НомерСотрудниха, НазааниеСертификата) НаэааниеСертификата На следующем шаге мы проверим каждое из этих отношений на соответствие критериям норлгализации.
Пример не говорит нам, какие атрибуты должны быть представлены, поэтому мы не можем определить ограничения. Мы предположим, что оти отношения находятся в ДКНг(з, хотя в реальности справедливость этого предположения нужно было бы проверить, исходя из перечня атрибутов и ограничений. На данный момент мы сконцентрируемся на представлении связей.
Отношения и их ключевые атрибуты (в том числе внешние ключи) перечислены на рис. 6.22, б. Связь между отношениями СОТРУДНИК и ИНЖЕНЕР уже представлена, так как эти отношения имеют один и тот же ключ, НомерСотрудн ика. ИНЖЕНЕР и ГРУЗОВИК имеют связь 1:1, поэтому представить эту связь можно, поместив ключ одного из этих отношений в другое.
Поскольку грузовик должен закрепляться за сотрудником, пустых значений нс возникнет, если мы поместим атрибут НамерСотрудника в отношение ГРУЗОВИК; именно так мы и поступим. Для представления связи между отношениями ИНЖЕНЕР и РАБОТА, имеющей пид 1;Х, мы поместим ключ отношения ИНЖЕНЕР (являющегося родителем) в отношение РАБОТА (являющееся потомком), Связь между отношениями РАБОТА и КЛИЕНТ имеет внд М:Х, поэтому мы должны создать отношение пересечения. Так как данная связь имеет атрибут (Плата), мы добавим этот атрибут в отношение пересечения КЛИЕНТ-РАБОТА.
Чтобы представить рекурсивную связь КЕМПРИВЕДЕН, имеющую вид 1:Х, мы добавим к отношению КЛИЕНТ атрибут КемПриведен. Как вы правильно догадались, имя КемПриаеден подразумевает, что и отношение помещается ключ родителя (клиента, приводящего других клиентов). Поскольку отношение ИНЖЕНЕР-СЕРТИФИКАТ является идентификационно-зависимым от отношения ИНЖЕНЕР, мы знаем, что атрибут НомерСотрудника должен быть частью ключа; таким образом, мы имеем композитный ключ (НомерСотрудника, НазааниеСертификата). Связь зависимости имеет впд 1:Х и будет обеспечиваться посредством атрибута НомерСотрудника.
Наконеп, связь между отношениями СЕРТИФИКАТ и ИНЖЕНЕР-СЕРТИФИКАТ имеет вид 1:Х, поэтому нормальным решением было бы поместить ключ отношения СЕРТИФИКАТ (родителя) в отношение ИНЖЕНЕР-СЕРТИФИКАТ. Но этот ключ уже является частью отношения, так что указанное действие выполнять не нужно. Изучите этот пример, чтобы убедиться, что вы понимаете различные типы связей и выражение их в терминах отношений. Все элементы модели «сущность — связь» присутствуют на рис. 6.20.
По поводу ограничений ссылочной целостности обратитесь к вопросу 6.40. СОТРУДНИК Деревья ТипСот рудника ИНЖЕНЕР ЗАКРЕПЛЕННЫЙ ГРУЗОВИК ИНЖЕНЕР-КВАЛИФИКАЦИЯ 0.,1 ИНЖЕНЕР- СЕРТИФИКАТ ГРУЗОВИК ИСПОЛНИТЕЛЬ РАБОТЫ РАБОТА О..' ВИД СЕРТИФИКАТА КЛИЕНТ- РАБОТА СЕРТИФИКАТ РАБОТА-КР О,.* КЛИЕНТ-КР 1..1 КЛИЕНТ 0..1 Рис. В.23. Пример дерева КЕМ ПРИВЕДЕН 228 Глава 6. Проектирование баз данных в рамках модели «сущность — связь» СОТРУДНИК (НямааСОточоникв, прочие неключееые атрибуты отношения СОТРУДНИК...) ИНЖЕНЕР (НооыарСатаудци(Ш, прочие неключееые атрибуты отношения ИНЖЕНЕР...) ГРУЗОВИК ())диевпнцевзин, прочие нЕКПЮЧЕВЫЕ ВтРибуты отношения ГРУЗОВИК, НомерСотруднике) РАБОТА (ВоыааСчетв, прочие неключевые атрибуты отношения РАБОТА, НомерСотруднока) КЛИЕНТ (ВОМВОКЗаента, прочие неключевые атрибуты отношения КЛИЕНТ, КемПриееден) КЛИЕНТ-РАБОТА (((рыедСЧата, Вомеер!0(ианттд, Плата) ( прочие неки ючевые атрибуты отношения ИНЖЕНЕР-СЕРТИФИКАТ) «~Н к~р~, »6 ~н б Рис.
В.22. Реляционное представление ЕЯ-диаграммы для данного примера: е — ЕЯ-дивгрвммв из главы 3; б — отношения, представляющие эту ЕЯ-диаграмму Деревья, сети и списки материалов Хотя ни модель «сущность — связь», ни семантическая объектная модель не делают никаких предположений относительно структурь1 связей между сущностями, некоторыс шаблоны возникают настолько часто, что им были присвоены специ- Деревья, сети и списки материалов 229 альные имена. К этим шаблонам относятся деревья, простые сети, сложные сети и списки материалов. Мы опишем суть этих шаблонов здесь, в контексте модели «сущность — связык /!ервво (ггее), или иерархия (МегагсЬу), как его иногда называют, — это структура данных, элементы которой имеют друг с другом связь «один ко многим». Каждый элемент имеет максимум одного родителя.
На рис. 6.23 изображен пример дерева. В соответствии с общепринятой терминологией, каждый элемент называется узлом (пос1е), а связи между элементами называются ветвями (ЬгапсЬез). Узел, располагатощийся на вершине дерева, называется караси (гоог), Между прочим, это ловольно своеобразная метафора: у настоящих деревьев корни обычно находятся внизу! На рис. 6.23 узел 1 является корнем дерева.
Каждый узел дерева, за исключением корня, имеет родителя (рагепс) — узел, расположенный непосредственно над данным узлом и связанный с ним. Так, узел 2 является родителем узла 5, узел 4 является ролителем узла 8 и т. д. Как уже говорилось выше, деренья отличаются от других структур данных тем, что каждый узел имеет Гааксимулт олного родителя. Мы говорим «максииум одного родителя», поскольку у корня родителей нет. Узлы, расположенные непосредственно под данным узлом и связанные с ннм, называются потолками (сЬ(18геп) этого узла, пли дочерними узлами. Вообще гоноря, не существует ограничений на количество потомков, которое может иметь узел.
Узел 2 имеет два пото»1ка — узлы 5 и 6; узел 3 не имеет потомков; узел 4 имеет три потомка — узлы 7, 8 и 9. Узлы, нмекицие одного родителя, называютгя близлеииии (гтч(пз), или братьями (з(Ы1пйз). Например, узлы 5 и 6 янляются близнецами, или братьями. На рис. 6.24 изображено дерево сущностей, в котором вы можете увидеть несколько связей «один ко многим» между сущностями в системс университета, Колледжи состоят из множества кафедр, на которых, в сво|о очередь, работают множество преподавателей и алминистративных работников. Наконсп, цреподанатели руководят множеством студентов, которые получают множество оценок.
В этой структуре имеется шесть типов сущностей, но все связи имеют вид Ь)ч'. Чтобы представить дерево сущностей, используя реляционную модель,мы ~цхюто применим понятия, описанные в предыдущих разделах этой главы. Сна- Простые сети РУКОВОДИТЕЛЬ СПЕЦИАЛЬНОСТЬ СТУДЕНТ Рис. 6.26. Пример посс«ой сети Сложные сети 230 Глава 6. Проектирование баз данных е рамках модели «сущность — связь» чала мы преобразуем каждую сущность в отношение.
Затем проанализируем созданные отношения согласно критериям нормализации и, если потребуется, разобьем исходные отношения на более мелкие. Связь 1:Х мы будем представлять, помещая ключ родительского отношения в дочернее. На рпс. 6.24, б изображена диаграмма структуры данных, соответствующая дереву па рис. 6.24, а.