Каждыи экземпляр сущности ности «Произведение"

типа Y обязательно является

экземпляром сущности типа X

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

то же самое, что и атрибут реляционного уровня. Еще одним (важным!) примером может быть то, что концепция типа сущности, как она понимается в семантическом моделиро­вании, отличается от концепции типа, которая рассматривалась в главе 5. Точнее гово­ря, подобным типам сущностей в реляционном проекте соответствуют переменные-отношения, а потому они, очевидно, не соответствуют реляционными типам атрибута (доменам). Однако по перечисленным ниже причинам они не полностью соответствуют и типам отношений.

1. На семантическом уровне некоторые базовые типы отношений, вероятно, будут соответствовать типам связей, а не типам сущностей.

2. Говоря упрощенно, производные типы отношений могут вообще ничему не соот­ветствовать на семантическом уровне.

Путаница при определении этих уровней (в частности, вследствие несогласованности используемой терминологии) как в прошлом, так и в настоящем часто служит причиной дорогостоящих ошибок (см. раздел 25.2 главы 25).

В заключение следует заметить, что в главе 1 связи рассматривались как сущности особого рода, причем подчеркивалось, что подобным же образом они будут рассматри­ваться во всей книге. Кроме того, в главе 3 как одно из преимуществ реляционной моде­ли отмечалось единство представления всех типов сущностей, включая связи, посредст­вом переменных-отношений. Тем не менее концепция связей (так же, как и концепция сущностей) действительно интуитивно полезна при описании реального мира. Более то­го, представленный ниже, в разделах 13.3-13.5, подход к проектированию базы данных будет в значительной степени опираться на различия между сущностями и связями. По­этому в нескольких следующих разделах будет принята терминология, предусматри­вающая разделение понятий сущностей и связей, однако в разделе 13.6 по этому вопросу будут представлены некоторые дополнительные замечания.

13.3. Модель "сущность/связь"

Как уже упоминалось в разделе 13.1, одним из наиболее известных и получивших широкое распространение методов семантического моделирования является построение модели "сущность/связь" (или ER-модели). Этот подход строится на использовании модели "сущность/связь", предложенной Ченом в 1976 году [13.5] и с тех пор неодно­кратно усовершенствовавшейся как самим Ченом, так и многими другими исследовате­лями (об этом можно прочесть, например, в [13.13], [13.40]—[ 13.42]). Дальнейшее обсуж­дение в настоящей главе, в основном, посвящено именно данному подходу. (Следует подчеркнуть, что модель "сущность/связь" является далеко не единственной "расширенной" моделью— их было предложено достаточно много. В частности, в [13.5], [13.13], [13.25] и особенно в [13.19] приведены общие вводные сведения по неко­торым из них, а в [13.22], [13.31] — вводные обзоры по данной теме.)

ER-модель включает аналоги всех семантических объектов, представленных в табл. 13.1, каждый из которых подробно рассматривается далее в этой главе. Прежде всего отметим, что в [13.5] была предложена не только сама ER-модель как таковая, но и соответствующая ей технология построения диаграмм, получивших название "ER-диаграммы". Более подробно ER-диаграммы описываются в следующем разделе, а на рис. 13.1 показан простой пример подобной диаграммы, взятый из [13.5]. Это

пример представления структуры данных некоторой производственной компании (KnowWare, Inc.). Он будет полезен при изучении последующего материала этой главы и подробно описывается ниже. (Это расширенная версия ER-диаграммы, приведенной на рис. 1.5 в главе 1.)

Рис. 13.1. Диаграмма модели "сущность/связь" (сокращенная версия для рассматри­ваемого примера)

Замечание. Большинство рассматриваемых в следующих подразделах идей хорошо известно тем, кто знаком с реляционной моделью. Но, как будет показано, между ис­пользуемыми в этих двух моделях терминами существуют определенные различия.

Сущности

Работа [13.5] начинается с определения сущности (entity) как "предмета, который может быть четко идентифицирован". При этом сущности подразделяются на силь­ные и слабые. Слабой называется такая сущность, существование которой зависит от другой сущности, т.е. она не может существовать, если этой другой сущности не су­ществует. Например, на рис. 13.1 сущность DEPENDENT (подчиненный работник) явля­ется слабой, поскольку она не может существовать (в контексте данной базы данных), если не существует соответствующей сущности EMPLOYEE (работник). В частности, ес­ли сведения о некотором работнике (сущность EMPLOYEE) будут удалены, то и сведения обо всех зависящих от него работниках (сущности DEPENDENT) также будут удалены. Сильной называется сущность, которая не является слабой. В нашем примере сущ­ность EMPLOYEE — сильная.

Замечание. Некоторые авторы вместо термина "сильная сущность" используют тер­мин "нормальная (regular) сущность".

Свойства

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

• Простое или составное свойство. Например, свойство "имя работника" может быть составным, если его значение составляется из значений простых свойств "имя", "отчество" и "фамилия".

• Ключевое свойство (т.е. уникальное, возможно, в определенном контексте). На­пример, имя подчиненного работника для определенного сотрудника может быть уникальным только в контексте этого сотрудника.

• Однозначное или многозначное свойство (т.е. в этой модели допускаются повто­ряющиеся группы). Все свойства, представленные на рис. 13.1, являются одно­значными. Однако если некоторый поставщик (SUPPLIER) будет иметь несколько разных пунктов отгрузки, то свойство CITY (Город) для него будет многозначным.

• Опущенное свойство (т.е. "неизвестное" или "непредставленное"). Эта концепция не отражена на рис. 13.1, а ее более подробное описание приводится в главе 18.

• Базовое или производное свойство. Например, общее количество деталей опре­деленного вида может быть вычислено с помощью суммирования объема отдель­ных поставок данной детали. Эта концепция также не представлена на рис. 13.1.

Связи

В [13.5] связь (relationship) определяется как "ассоциация, объединяющая несколько сущностей". Например, между отделами и работниками существует связь с именем DEPT ЕМР. Она представляет тот факт, что в каждом отделе работает определенное коли­чество работников. Так же, как и в отношении сущностей (см. главу 1), необходимо по­нимать принципиальную разницу между типами и экземплярами связей, однако при не­формальном описании такими тонкостями можно пренебречь, что мы и будем неодно­кратно делать в будущем.

Сущности, включенные в связь, называются ее участниками, а количество участни­ков связи называется ее степенью. (Следует отметить, что в данном случае значение термина "степень" отличается от его значения в реляционной модели.)

Пусть R является типом связи, включающей тип сущности Е в качестве участника. Ес­ли каждый экземпляр сущности Е участвует по крайней мере в одном экземпляре связи R, то участие сущности Е в связи R называется полным, в противном случае — частич­ным. Например, если каждый работник обязательно должен относиться к определенно­му отделу, то участие сущности EMPLOYEE в связи между работниками и отделами (DEPT_EMP) является полным. В свою очередь, если допустима ситуация, когда в некото­ром отделе не будет ни одного работника, участие сущности DEPARTMENT в связи DEPT_EMP будет частичным.

Связи в модели "сущность/связь" могут иметь тип "один к одному", "один ко мно­гим" (иначе может называться "многие к одному") или "многие ко многим". (Для уп­рощения изложения далее предполагается, что все связи являются двойными, т.е. имеют степень "два", хотя, конечно, изложенные концепции и терминологию можно без труда расширить и на связи с более высокой степенью.) Здесь читатель, уже знакомый с осно­вами реляционной модели, мог бы заметить, что именно тип связи "многие ко многим" является единственным типом, представляющим истинную связь, поскольку это единст­венный тип связи, который требует для своего представления создания отдельной пере­менной-отношения. Связи типа "один к одному" и "один ко многим" всегда могут быть представлены с помощью механизма внешнего ключа, помещаемого в одну из перемен­ных-отношений, участвующих в данной связи. Однако существуют веские причины рас­смотрения связей типа "один к одному" и "один ко многим" таким же образом, как и свя­зи типа "многие ко многим", по крайней мере из-за того, что достаточно часто существу­ет возможность их эволюционирования до связи типа "многие ко многим" с течением времени. И только если такой возможности нет, их можно рассматривать как-то иначе. Безусловно, в некоторых случаях подобной возможности может не быть в принципе, например всегда будет верным утверждение, что окружность обладает только одной точ­кой, являющейся ее центром.

Подтипы и супертипы сущностей

Замечание. Представленные в этом разделе идеи не были включены в оригинальную версию ER-модели [13.5]; они были добавлены позднее. Подробнее об этом можно про­честь, например, в работе Тиори (Теогеу), Янга (Yang) и Фрая (Fry) [13.41].

Каждая сущность имеет по крайней мере один тип, однако у некоторой сущности может быть одновременно несколько типов. Например, если некоторые работники являются программистами (и все программисты являются работниками), то можно сказать, что тип сущности PROGRAMMER (программист) является подтипом типа сущ­ности EMPLOYEE (работник). (Или, что эквивалентно, тип сущности EMPLOYEE являет­ся супертипом типа сущности PROGRAMMER.) Программисты автоматически обладают всеми свойствами работников, однако обратное утверждение неверно (например, для программистов может быть задано свойство "изученный язык программирова­ния", которое в общем случае не применимо ко всем работникам). Аналогично сущ­ность PROGRAMMER автоматически участвует во всех связях, в которых участвует сущность EMPLOYEE, однако обратное утверждение также неверно (например, про­граммисты могут входить в профсоюз компьютерных специалистов, в который про­чие работники в общем случае не входят). Поэтому говорится, что подтип наследу­ет свойства и связи супертипа.

Обратите внимание, что одни программисты (сущность PROGRAMMER) могут быть при­кладными программистами (сущность APPLICATION_PROGRAMMER), а другие — системны­ми программистами (SYSTEM_PROGRAMMER). Исходя из этого, можно сказать, что типы APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER являются подтипами супертипа PROGRAMMER и т.д. Иначе говоря, сущность-подтип по-прежнему является типом сущно­сти и, следовательно, может иметь собственные подтипы. Некоторый тип сущности, его непосредственные подтипы, подтипы этих подтипов и т.д. все вместе образуют иерар­хию типов сущности, пример которой представлен на рис. 13.2.

Здесь стоит подробно рассмотреть следующие особенности.

1. Поскольку детальное обсуждение иерархии и наследования типов будет отложено до главы 19, следует предупредить читателя, что в данной главе термин тип имеет такое же значение, как и в главе 5 (т.е. он не означает "тип сущности").

2. Для читателей, знакомых с СУБД IMS (или какой-нибудь иной СУБД, в кото­рой используется иерархическая структура данных), необходимо отметить, что иерархии типов не следует путать с иерархиями данных. Например, на рис. 13.2 вовсе не подразумевается, что для одного работника (EMPLOYEE) име­ется несколько соответствующих программистов (PROGRAMMER). Наоборот, для одного экземпляра типа сущности EMPLOYEE существует не более одного соот­ветствующего экземпляра типа сущности PROGRAMMER, представляющего того же работника в роли программиста.

На этом краткое обсуждение основных структурных особенностей ER-модели завер­шено, и можно перейти к рассмотрению ER-диаграмм.

Рис. 13.2. Пример иерархии типов сущностей

13.4. ER-диаграммы

Как уже указывалось в предыдущем разделе, в [13.3] была не только введена сама модель "сущность/связь", но и представлена концепция ER-диаграмм. Такая диа­грамма является методом представления логической структуры базы данных в графи­ческом виде для более простого и наглядного отображения основных компонентов конкретного проекта базы данных (один рисунок порой стоит тысячи слов). Действи­тельно, популярность методов ER-моделирования как подхода для проектирования баз данных, скорее всего, объясняется именно наличием подобной диаграммной техноло­гии, а не чем-либо иным. Ниже правила создания ER-диаграмм поясняются на приме­рах, представленных на рис. 13.1 и 13.2.

Замечание. Так же, как и сама модель "сущность/связь", технология создания ER-диаграмм постоянно совершенствуется, поэтому в данном разделе будет описана та ее версия, которая отличается в некоторых важных аспектах от оригинальной методики, предложенной Ченом в [13.3].

Сущности

Каждый тип сущности на ER-диаграмме представляется в виде отдельного прямо­угольника с указанным внутри именем сущности, причем прямоугольники сущностей слабых типов рисуются двойной линией.

Примеры (см. рис. 13.1)

■ Сильные сущности:

DEPARTMENT (отдел) EMPLOYEE (работник) SUPPLIER (поставщик) PART (деталь) PROJECT (проект)

■ Слабая сущность: DEPENDENT(подчиненный)

Свойства

Свойства отображаются на ER-диаграмме в виде эллипсов, содержащих имена этих свойств. Эллипсы соединяются с соответствующей сущностью (или связью) сплошной линией. Контур эллипса рисуется штриховой линией, если свойство производное, и двойной линией, если свойство многозначное. Если свойство составное, то составляю­щие его свойства показаны в виде других эллипсов, соединенных с эллипсом составного свойства с помощью дополнительных линий. Имена ключевых свойств обычно подчер­киваются, а множества значений не отображаются вовсе.

Примеры (см. рис. 13.1)

■ Для сущности EMPLOYEE:

EMPt (личный номер работника — ключевое свойство)

ENAME (полное имя — составное, состоящее из свойств FIRST (имя), Ml (отчество) и LAST (фамилия)) SALARY (зарплата)

■ Для сущности SUPPLIER:

Si (номер поставщика— ключевое свойство)

SNAME (имя поставщика)

STATUS (статус поставщика)

CITY (город, в котором находится поставщик)

• Для связи SUPP_PART_PROJ: QTY (количество)

• Для связи PART_STRUCTURE: QTY (количество)

Для экономии места другие свойства, представленные на рис. 13.1, не показаны.

Связи

Каждый тип связи показан на ER-диаграмме в виде ромба с названием связи внутри. Ромб рисуется двойной линией, если это связь между слабым типом сущности и типом сущности, от существования которого она зависит. Участники каждой связи соединяют­ся с ромбом соответствующей связи сплошными линиями. Каждая такая линия содержит надпись "1" или "М" для обозначения типа связи ("один к одному", "один ко-многим" и т.д.). Двойная линия обозначает полное участие в связи данной стороны.

Примеры (см. рис. 13.1)

• DEPT_EMP (связь типа "один ко многим" между сущностями DEPARTMENT и EMPLOYEE)

• EMP_DEP (связь типа "один ко многим" между сущностью EMPLOYEE и сущностью слабого типа DEPENDENT)

• PR0J_W0RK и PROJ_MANAGER (обе связи установлены между сущностями EMPLOYEE и PROJECT, причем первая имеет тип "многие ко многим", а вторая — "один ко многим")

• SUPP_PART_PROJ (связь типа "многие ко многим" между сущностями SUPPLIER, PARTh PROJECT)

• SUPP_PART (связь типа "многие ко многим" между сущностями SUPPLIER и PART)

• PART_STRUCTURE (связь типа "многие ко многим" между сущностями PART и PART)

Обратите внимание, что в последнем случае две линии от PART к PART_STRUCTURE отличаются надписями с указанием различных выполняемых ролей (ЕХР и IMP, ко­торые обозначают соответственно "разложение детали на компоненты" и "сборку детали из компонентов"). Связь PART_STRUCTURE является типичным примером ре­курсивной связи.

Подтипы и супертипы сущностей

Пусть тип сущности Y является подтипом типа сущности X. Тогда от прямоугольника Y к прямоугольнику X можно провести сплошную линию со стрелкой на конце возле Y. Эта линия представляет то, что иногда называется связью принадлежности фа relationship) (поскольку множество всех сущностей типа Y "является" (is а) подмножест­вом множества всех сущностей типа X).

Примеры (см. рис. 13.2)

• Тип сущности PROGRAMMER является подтипом типа сущности EMPLOYEE

• Типы сущностей APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER являются подти­пами типа сущности PROGRAMMER