История создания[править]

Нотации[править]

Нотация Питера Чена[править]

Простая ER-модель MMORPG с использованием нотации Питера Чена

Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.

Crow"s Foot[править]

Пример отношения между сущностями согласно нотации Crow"s Foot

Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest ) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow"s Foot («воронья лапка») или Fork («вилка»).

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности - это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

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

6.2.2. Основные понятия модели Entity-Relationship (Сущность-Связи)

Лаконичной устной трактовкой изображенной диаграммы является следующая:

Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕКОВ").

В реальном проектировании структуры базы данных применяется метод - так называемое, семантическое моделирование . Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship ).

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей. Данная глава является скорее иллюстрацией методов семантического моделирования, чем полноценным введением в эту область.

Основные понятия ER-диаграмм

Определение 1 : Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная". Каждая сущность в модели изображается в виде прямоугольника с наименованием:

Рис. 1

Определение 2 : Экземпляр сущности - это конкретный представитель данной сущности.
Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов". Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.

Определение 3 : Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п. Атрибуты изображаются в пределах прямоугольника, определяющего сущность:

Рис. 2

Определение 4 : Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность. Сущность может иметь несколько различных ключей. Ключевые атрибуты изображаются на диаграмме подчеркиванием:

Рис. 3

Определение 5 : Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.
Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ". Графически связь изображается линией, соединяющей две сущности:

Рис. 4

Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.

Каждая связь может иметь один из следующих типов связи :

Рис. 5

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской , правая (со стороны "много") - дочерней . Характерный пример такой связи приведен на Рис. 4.

Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.

Каждая связь может иметь одну из двух модальностей связи :

Рис. 6

Модальность "может " означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность "должен " означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на Рис. 4). Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:

Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

Пример разработки простой ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.

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

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

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

• Хранить информацию о покупателях.
• Печатать накладные на отпущенные товары.
• Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

• Покупатель - явный кандидат на сущность.
• Накладная - явный кандидат на сущность.
• Товар - явный кандидат на сущность
• (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
• (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

Рис. 7

Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.

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

Рис. 8

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

• Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
• Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
• Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
• Каждый склад имеет свое наименование.
• Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
• Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
• Наименование покупателя - явная характеристика покупателя.
• Адрес - явная характеристика покупателя.
• Банковские реквизиты - явная характеристика покупателя.
• Наименование товара - явная характеристика товара.
• (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
• Единица измерения - явная характеристика товара.
• Номер накладной - явная уникальная характеристика накладной.
• Дата накладной - явная характеристика накладной.
• (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
• (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
• (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
• Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
• Наименование склада - явная характеристика склада.

В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.

С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму:

Рис. 9

Концептуальные и физические ER-модели

Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы . Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму , которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом:

Рис. 10

На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.

Легко заметить, что полученные таблицы сразу находятся в 3НФ.

Выводы

Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование .

В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship ).

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

Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.

При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.

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

1.5 ER-моделирование

Моделирование данных – это первый шаг на пути проектирования БД, это переход от объектов реального мира к компьютерной модели БД.

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

1.5.1 Сущности

Поскольку сущность представляет собой объект реального мира, то слова «сущность» и «объект» часто обозначают одно и то же.

На уровне ER-моделирования под сущностью на самом деле подразумевается набор сущностей (entity set), а не единственная сущность. Иначе говоря, сущность в ER-моделировании соответствует таблице, а не строке в реляционной среде, отдельная строка в ER-модели называется экземпляром сущности (entity instance, entity occurrence). Сущность изображается прямоугольником, в котором записано имя сущности.

1.5.2 Атрибуты

Атрибуты описывают свойства сущности. Например, сущность STUDENT включает в себя атрибуты NSTBIL (№ студенческого билета), FIO (имя студента), KURS (курс) и т.д.

Рис. 1.24. Атрибуты сущности STUDENT в ER-модели.

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

Первичные ключи в ER-модели подчеркиваются. Если имеются несколько первичных ключей, то подчеркиваются все.

Атрибуты могут быть простые и составные. Составной атрибут – это атрибут, который может быть в дальнейшем разделен на несколько атрибутов. Например, атрибут ADRESS (адрес), может быть разделен на STREET (улица), CITY (город) и т.д.

Атрибуты могут быть однозначные и многозначные. Однозначный атрибут – это такой атрибут, который может принимать единственное значений. Например, ИНН может иметь единственное значение у каждого человека. Однозначные атрибуты не обязательно являются простыми. Например, серийный номер 78-03-06-137846 является однозначным атрибутом, но в то же время это составной атрибут, т.к. его можно разделить на регион, в котором изделие было выпущено (78), код города (03), выпускающую смену (06), номер изделия (137846).

Многозначный атрибут – это атрибут, который может принимать несколько значений. Например, человек может закончить несколько ВУЗов, иметь несколько телефонных номеров.

В реляционной СУБД многозначные атрибуты использовать нельзя. Если имеются многозначные атрибуты, то необходимо создать внутри данной сущности несколько новых атрибутов или создать новую сущность, состоящую из компонентов многозначного атрибута.

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

1.5.3. Связи

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

Связи между сущностями в количественном соотношении могут быть «один-к-одному», «один-ко-многим». Для обозначения типов связей используется термин «связность» (connectivity).

Мощность связи (cardinality) выражает определенное число экземпляров сущностей, связанных с одним экземпляром связанной сущности. На ER-диаграмме мощность связи не обозначается, но в прикладном программировании сведения о max и min количествах экземпляров сущности могут пригодиться. Например, группа не может начать занятия, если в ней меньше 10 студентов.

Связи устанавливаются между сущностями. Если сущность зависит от существования одной или более других сущностей, то она зависит от существования (existence – dependent). Например, если сотрудники имеют иждивенцев, то для исчисления налогов можно установить связь «сотрудник имеет иждивенцев». В этом случае сущность «иждивенец» зависит от сущности «сотрудник».

Если сущность может существовать вне других сущностей, то она независима от существования (existence –independent). Например, сущность «деталь» может существовать независимо от сущности «поставщик».

Если одна сущность независима от существования другой сущности, связь между ними называется слабой связью (weak relationship) или неидентифицируемой связью (non – identifying relationship). Слабые связи имеют место, если первичный ключ связанной сущности не содержит первичные компоненты порождающей сущности. Например, имеются две сущности COURSE (курс) и CLASS (группа), описанные как

COURSE (CRS-CODE , DEPT_CODE,…)

CLASS (CLASS-CODE , CRS_CODE,…)

Между этими сущностями существует слабая связь, т.к. атрибут CLASS_CODE является первичным ключом сущности CLASS, в то время как атрибут CRS_CODE сущности CLASS является внешним ключом. Первичный ключ сущности CLASS не наследует компонент первичного ключа из сущности COURSE. Слабая связь изображается на ER-диаграмме штриховой линией.

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

COURSE (CRS-CODE , DEPT_CODE,…)

CLASS (CRS_CODE , CLASS-SECTION ,…)

Имеют сильную связь, т.к. составной ключ сущности CLASS включает в себя первичный сущности COURSE. На ER-диаграмме сильные связи показываются сплошной линией.

Необходимо иметь в виду, что порядок, в котором таблицы создаются и загружаются, имеет существенное значение. Для данных, например невозможна ситуация, когда внешний ключ таблицы CLASS ссылается на еще не существующую таблицу COURSE. Проблема после последовательности создания таблиц в некоторых СУБД не возникает, пока не загружаются данные. Чтобы избежать нарушения целостности на уровне ссылки, в связи 1:М необходимо загружать сторону «1» независимо от того, является она сильной или слабой.

Участие сущности в связи может быть обязательным или необязательным. Участие сущности необязательно (optional participation), если один экземпляр сущности не требует наличия соответствующего экземпляра сущности в отдельной связи. Например, в связи на курсе (COURSE), создаются группы (CLASS) по крайней мере, на некоторых курсах могут и не создаваться группы. Т.е. экземпляр сущности (строка) в таблице COURSE не требует обязательного наличия соответствующего экземпляра сущности в таблице CLASS. Поэтому сущность CLASS рассматривается как необязательная по отношению к сущности COURSE. Необязательная связь на ER-диаграмме показывается небольшим кружком со стороны необязательной сущности. Существование необязательности указывает на то, что для необязательной сущности min значение мощности связи равно 0.

Участие сущности в связи обязательно (mandatory participation), если один экземпляр сущности обязательно требует соответствующего экземпляра сущности в отдельной связи. Если около сущности не изображен никакой дополнительный символ, то это означает, что данная сущность участвует в обязательной связи со связанной сущностью. Min мощность для обязательной сущности равна 1.

а) Сущность CLASS необязательна для сущности COURSE

б) Сущности COURE и CLASS в обязательной связи.

Рис.1.25. Изображение обязательной и необязательной связей в ER-модели.

В терминах проектирования БД существование сильной связи между порождающей сущностью и связанной с ней сущностью или сущностями ассоциируется со слабыми сущностями.

Слабой сущностью (weak entity) называется сущность, которая удовлетворяет двум условиям:

условию зависимости от существования, т.е. она не может существовать без сущности, с которой она связана;

ее первичный ключ частично или целиком произведен из порождающей сущности данной связи.

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

Рис. 1.26. Слабая сущность в ER-диаграммах.

Слабая сущность наследует все части первичного ключа своего сильного партнера по связи. Именно проектировщик БД решает, нужно или нет объявлять сущность слабой.

Степень связи (relationship degree) указывает на число ассоциированных сущностей. Унарная связь (unary relationship) существует тогда, когда ассоциация поддерживается внутри единственной сущности. Бинарная связь (binary relationship) существует тогда, когда ассоциируются две сущности. Тернарная связь (ternary relationship) имеет место тогда, когда связываются три сущности. Хотя существуют и более высокие степени связи, они довольно редки и не имеют особых названий.

Если сущность имеет связи с собой, то такая связь называется рекурсивной.

Рис. 1.27. ER-представление рекурсивной связи

Иерархия обобщенных представлений (generalization hierarchy), отображает связи «предок-потомок». В контексте реляционных БД иерархия обобщенных представлений отображает связи между супертипами сущности верхнего уровня и подтипами сущности нижнего уровня. Т.е. супертип содержит совместно используемые атрибуты, в то время как подтип содержит уникальные атрибуты.

Рис. 1.28. Иерархия обобщенных представлений.

Связи наследуются, т.е. подтип сущности наследует атрибуты и связи от супертипа сущности. Например, все пилоты, механики и бухгалтера имеют табельные номера, ФИО, домашний адрес и т.д., но они могут иметь атрибуты, уникальные для их специализации. Другими словами, супертип набора сущностей обычно связан с несколькими уникальными и непересекающимися подтипами набора сущностей. Такие непересекающиеся связи обозначаются буквой ‘G’.

Супертип и подтип(ы) поддерживают связь 1:1. Например, структуру таблицы EMPLOYEE можно заменить двумя таблицами, одна из которых представляет супертип EMPLOYEE, а другая – подтип PILOT.

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

Пересекающиеся связи отображаются символами ‘Gs’.

Рис. 1.29. Иерархия обобщенных представлений с пересекающимися подтипами.