Главная » SQL, Базы данных » МОДЕЛЬ "СУЩНОСТЬ-СВЯЗЬ"

0

Как уже упоминалось в разделе 14.1, одним из наиболее известных и получивших широкое распространение методов семантического моделирования является метод построения модели "сущность—связь" (или ER-модели). Этот подход основан на использовании модели "сущность—связь", предложенной Ченом в 1976 году [14.6] и с тех пор неоднократно дополнявшейся как самим Ченом, так и многими другими исследователями (об этом можно прочесть, например, в  [14.18], [14.45]—[14.47]). Дальнейшее обсуждение в настоящей главе в основном посвящено именно данному подходу. (Следует подчеркнуть, что модель  "сущность-связь" является далеко не единственной "расширенной" моделью, кроме нее, было предложено очень много других моделей. В частности, в [14.6], [14.18], [14.30], [14.37] и особенно в [14.24] приведены общие вводные сведения по некоторым из них, а в [14.27] и [14.36] даны вводные обзоры по рассматриваемой теме.)

ER-модель включает аналоги всех семантических объектов, представленных в табл. 14.1,

каждый из которых подробно рассматривается далее в этой главе. Прежде всего отметим, что в [14.6] была предложена не только сама ER-модель как таковая, но и соответствующая ей технология построения диаграмм, получивших название ER-диаграммы. Более подробно ER-диаграммы описываются в следующем разделе, а на рис. 14.1 показан простой пример подобной диаграммы, взятый из [14.6]. Это пример представления структуры данных некоторой вымышленной производственной компании (KnowWare, Inc.). Он будет полезен при изучении последующего материала данной главы и подробно описывается ниже. (Это — расширенная версия ER-диаграммы, приведенной на рис. 1.6 в главе 1.)

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

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

Сущности

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

Примечание.  Некоторые  авторы  вместо  термина  обычная  сущность   применяют термин сильная сущность.

Свойства

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

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

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

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

■    Отсутствующее свойство (т.е. свойство неизвестное или неприменимое). Эта кон цепция не отражена на рис. 14.1, а ее более подробное описание дано в главе 19.

■    Базовое или производное свойство. Например, общее количество деталей опреде ленного вида может быть вычислено с помощью суммирования объема отдельных поставок данной детали. Эта концепция также не представлена на рис. 14.1. Примечание. В контексте ER-модели некоторые авторы вместо термина свойство используют термин атрибут.

Связи

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

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

Пусть R является типом связи, включающей тип сущности Е в качестве участника.

Если каждый экземпляр сущности Е участвует по крайней мере в одном экземпляре связи R,

то участие сущности Е в связи R называется полным, в противном случае — частичным.

3 Определениеэтоготерминаприведеновподразделе"Атрибутысозначениямиввидеотношения"раздела 6.4.

Например, если каждый работник обязательно должен относиться к определенному отделу, то участие сущности EMPLOYEE В СВЯЗИ между работниками и отделами (DEPT_EMP) является полным. С другой стороны, если допустима ситуация, когда в некотором отделе (например,  вновь  созданном)   не   будет   ни   одного   работника,  участие   сущности

DEPARTMENT В СВЯЗИ DEPT_EMP будет ЧасТИЧНЫМ.

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

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

Примечание. Представленные в этом разделе понятия не были включены в  оригинальную версию ER-модели [14.6]; они были добавлены позднее. Подробнее об этом можно прочесть, например, в [14.46].

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

тип сущности PROGRAMMER (программист) представляет собой подтип типа  сущности

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

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

ЧТО ТИПЫ APPLICATION_PROGRAMMER И  SYSTEM_PROGRAMMER

являются  подтипами

супертипа PROGRAMMER и т.д. Иначе говоря, сущность-подтип по-прежнему  является типом сущности, поэтому может иметь собственные подтипы. Некоторый тип сущности, его непосредственные подтипы, подтипы этих подтипов и т.д. все вместе образуют иерархию типов сущности, пример которой представлен на рис. 14.2.

Здесь стоит подробно рассмотреть приведенные ниже особенности.

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии