Как составить модель сущность связь

Время на прочтение
6 мин

Количество просмотров 83K

Здравствуйте. Данная статья посвящена одной из самых популярных, а также и многим знакомой, модели проектирования — ER(Entity Relationship), которая была предложена учёным, в области информатики — Питером Ченом, в 1976 году.

По ходу статьи простым языком на простых примерах из жизни — мы с Вами разработаем разные варианты диаграммы, которые будут зависеть от их типа связи. Начнём!

Объектно Ориентированное Проектирование

В первую очередь, хотелось бы сказать пару слов об ООП(Объектно Ориентированном Программировании/Проектировании), чтобы не было проблем с пониманием парадигмы самой диаграммы. Мне удобнее абстрагировать эту модель с принципом ООП, где сущность — объект, атрибуты — его характеристики, а связи — что-то вроде посредника(в некоторых случаях — как метод).

Быстрый старт

Главный плюс модели проектирования Entity Relationship — это то, что она универсальна. Вы можете проектировать БД(Базы данных), работу какой-либо программы, принципы взаимодействия и др.

Что нужно знать на старте изучения?

— Нужно знать на старте то, что основная работа проводится над взаимоотношением сущности и связи. Для более легкого восприятия, стоит запомнить, что сущность — существительное, которое находится в прямоугольнике, а связь — глагол, который находится в ромбе. Приведём пример:

Думаю, Вы поняли, что к чему. Наш Программист учит Python. Вроде, всё логично. Но вот, только, что это за единички в примере?

— Это показатель типа связи! В данном примере используется вид связи — Один к одному:

К видам связи мы ещё вернёмся, но чуть позже, а сейчас нужно разобрать ещё одно НО:
— Диаграмма должна читаться в обе стороны. Если прочесть слева на право, то всё логично, как было сказано ранее, но если наоборот… то мы ещё несколько раз задумаемся о том, что такое логика. Действительно, так записано и это правильно! Это лишь одна из некоторых особенностей данной модели, что иногда может запутать. Однако, ничто не мешает Вам, как и многим, со стороны единицы, добавить стрелочку, как на примере ниже:

P.S. Надеюсь, Вы заинтересованы. Такие диаграммы Вы можете создавать в редакторе диаграмм — Dia.

Атрибуты

Так, у нас есть программист, но мы ничего о нём не знаем… Без чего программист не программист?
— Без каких-то атрибутов!

Дополним наш пример:

Да, атрибуты не особо отличают нашего программиста от обычного человека… но в будущем мы это исправим новыми атрибутами! В моём представлении, атрибут — это COLUMN(столбец) в таблице Базы Данных.

Атрибуты бывают и пустыми

Если в таблице Вашей БД необязательно указывать фамилию(то атрибут будет необязательным), тогда атрибут должен состоять из двух овалов: внешнего и внутреннего(внутри которого название атрибута).

Индентифицирующие атрибуты

Вы можете встретить подчеркивание названия атрибута в диаграмме — это нормально. Пугаться этого не стоит, тк это просто индентифицирующий атрибут. То-есть, это атрибут, который должен быть заполнен всегда, который является обязательным(первичным ключом). Как пример — всем известный id.

Хорошо, а теперь нам нужно дать программисту знания(то, какие языки, технологии он знает).
— Но мы же не будем сразу перечислять каждым отдельным атрибутом составляющие его знаний?
Верно, мы воспользуемся составным атрибутом(атрибут, который состоит из атрибутов-составляющих)! Хочу отметить то, что атрибуты-составляющие — тоже могут быть составными. Вопрос лишь в том, как Вы будете это реализовывать.

Типы связи

Отлично. С этим мы смогли разобраться. Теперь рассмотрим оставшиеся типы связи!

Продолжим с типа связи — Один ко многому:

Покажу на примере:

Теперь наш программист изучает ещё и Perl. Неплохо.
Однако, хочу отметить, что пример, указанный выше — лишь исключение, для того, чтобы показать наглядно, к чему идёт отношение, потому что ответвлений может быть тысяча, что глупо будет чертить. В будущем, мы вернёмся к сокращенной и правильной записи, а этот хиленький паттерн стоит просто запомнить, чтобы было общее представление, что к чему. Надеюсь, что у меня получилось объяснить Вам, что представляет тип связи «Один ко многому».
*Отношение одной сущности к нескольким и наоборот*

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

Остался последний тип связи — Многое ко многому:

Как обычно, покажу Вам на примере, но уже не с Программистом, а на примере взаимосвязи Зрителя с Фильмом, на каком-либо сервисе по просмотру Фильмов:

Тут два спорных момента. Начнём разбираться.

Первое:
— Почему связь больше смахивает на сущность?

Для упрощения связи типа «Многое ко многому» используются промежуточные сущности.

— Почему здесь нет ответвлений?

— Зритель может подписаться на много Фильмов.
— У Фильмов может быть много зрителей, которые подписаны на них.

А теперь рассмотрим другой способ реализации связи «Многое ко многому», который будет чуть сложнее в записи, но возможно понятнее тем, кто не знает о промежуточных сущностях:

Как Вы могли заметить, в данном примере есть тип связи «Один ко многому», и даже несколько.
Это правда и такое легко объяснить. Дело в том, тип связи «Многое ко многому» равняется двум «Один ко многому».

Наверное, Вы заинтересованы в том, почему у нас, между связью и сущностью, два ребра.
Это уже чуть сложнее объяснить. Читайте внимательно.
Дело в том, что бывают опциональные и обязательные связи. Запомните тождество:

Опциональные связи создают частичное участие, в то время как обязательные — полное.

— Что такое частичное и полное участия?

Частичное участие — тоже одно из исключений, похожее чем-то на необязательный атрибут, вот только зависит от сущности. Представьте картину. Есть две сущности:
Покупатель и Продукты. Тип связи — Один ко многому.
У них общая связь — Покупает. Но нам нужно понять другое. Без чего покупатель — не покупатель?
— Без хотя бы одной покупки!
Данный случай — представитель частичной связи, тк мы даём выбор «Покупать и стать покупателем или отказаться». В таком случае, у нас, будет одно ребро между связью «Покупает» и сущностью «Продукты». Теперь рассмотрим полное участие.

Полное участие представляет из себя тот случай, когда выбора нет. Наш программист останется программистом, даже если ничего не выучит, благодаря тому, что мы фиксируем на диаграмме то, что он должен что-то учить, а исключений быть не может. Фиксируем мы это дело двумя рёбрами. Тип участия зависит от того, как вы проектируете, нужна ли выборка на этапе связи.
С этим закончили. Продолжаем.

Вспомните пример «Один ко многому», где после связи «Учит» были названия ЯП(Языков программирования), что приводило к большому количеству разветвлений, потому как было не правильно в плане записи. Только подумайте, ведь нам не обязательно делать ответвления к каждому ЯП. Мы можем просто создать сущность «Язык программирования», в которой мы разместим атрибуты, которые будут отвечать за его название, возраст, мощность и многое другое. Думаю, Вы поняли. Советую использовать сокращенную запись «Многое ко многому».

Слабые сущности

Рассмотрим заключительное понятие.

Представьте, что у Вас в существует таблица «Родитель» и «Ребенок», соответственно такие-же сущности в диаграмме. Может ли одно существовать без другого? Я думаю — нет. Как в биологическом, так и в целом логическом.

Слабая сущность: яблока без яблони быть не может

.

В этом примере сущность «Ребенок» — слабая сущность.

Слабые сущности — это те сущности, которые не могут существовать без другой сущности.

Мы создаём сущность «Ребёнок», в надежде на то, что у Родителя/Родителей нет детей с одинаковыми именами, тк иначе — нашу сущность, которая может являться таблицей в БД, будет сложно назвать Нормализованной(таблица, в которой соблюдаются правила Автомарности данных и существует Первичный ключ-идентификатор), ведь мы банально не сможем отличить детей.

Однако, такие случаи имеют место быть, но исправить это можно добавлением дополнительного атрибута. В таком случае, атрибут «Имя» — то, что и создает подобную ситуацию, а называется он компонентом ключа слабой сущности. Название подобных атрибутов, в овалах, подчеркиваются пунктиром, а сущность и связь помещаются в дополнительные фигуры, в которых они состоят.

Представлю вам это на примере:

Заключение

В заключение хочется сказать, что одна из основополагающих грамотной кооперативной работы — хорошее объяснение поставленных задач, хорошее представление продукта, который нужно разработать, в чём и помогают модели проектирования. Entity Relatioship — модель проектирования, которая пользуется популярностью не один десяток лет. Она позволяет строить изящные диаграммы, которые, при правильном подходе, можно в будущем дополнять и видоизменять. Не поленитесь изучить. Спасибо за внимание!

Источники

— Книга «Руководство по MySQL» Авторства:
Сейед М.М. «Saied» Тахагхогхи, Хью Е.Вильямс
— en.wikipedia.org/wiki/Entity–relationship_model

3.2. Модель «сущность – связь»

Перед тем, как приступить к созданию автоматизированной системы обработки информации, необходимо формирование понятий о событиях, фактах и предметах, которыми будет оперировать разрабатываемая система. Для того чтобы привести эти понятия к определенной модели данных, необходимо их заменить соответствующими информационными представлениями. Наиболее удобным инструментом такого представления данных, вне зависимости от реализующего его ПО, является модель «сущность-связь» (entity – relationship model, ER-model), основывающаяся на семантической информации о реальном мире и предназначающаяся для логического представления данных.

ER-модель определяет значения одних данных в зависимости от других данных. Важно, что из модели «сущность – связь» можно получить все существующие модели данных (иерархическую, сетевую, реляционную и объектную).

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

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

Далее будет использован некоторый гибрид нотаций Чена (сущности, связи и атрибуты) и Мартина (степени и кардинальности связей). В табл. 3.1 приведен перечень используемых в этом случае обозначений.

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

Сущность entity (класс объектов) – это совокупность объектов, обладающих одинаковым набором свойств.

Каждая сущность обладает следующими свойствами:

● сущность имеет уникальное имя, к одному имени применяется одна и та же интерпретация, которая не может применяться
к различным именам, кроме случаев, когда они являются псевдонимами/синонимами;

● сущность обладает атрибутами (одним или несколькими), которые или принадлежат сущности, или наследуются через связь;

● сущность обладает атрибутами (одним или несколькими), которые однозначно определяют каждый экземпляр сущности;

● сущность может обладать любым числом связей с другими сущностями модели.

Таблица 3.1

Графические обозначения

Обозначение	Значение
	Независимая сущность
	Зависимая сущность
	Атрибут
	Ключевой атрибут
	Связь

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

Атрибут – это любая, значимая для предметной области характеристика сущности, и предназначенная для идентификации, классификации и количественной характеристики либо выражения состояния сущности.

Пример. Если в качестве предметной области рассматривать вуз, то в ней можно выделить следующие сущности: обучаемые, преподаватели, сотрудники, аудитории, дисциплины и т.п. Для объекта класса ЛИЧНОСТЬ В ВУЗЕ таким набором свойств могут быть год рождения, образование, ученая степень, иностранный язык, адрес и т.п.

При построении ИМ можно использовать язык ER-диаграмм, но чаще применяется более содержательный язык инфологического моделирования (ЯИМ), который представляет сущности предложениями следующего вида:

СУЩНОСТЬ (атрибут 1, атрибут 2, …, атрибут n).

Пример:

ЛИЧНОСТЬ (табельный номер, фамилия, имя, отчество, возраст).

Атрибут может быть описательным (дескриптором сущности) или входить в состав первичного ключа (уникального идентификатора).

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

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

В рассмотренном выше примере атрибут табельный номер является ключом сущности ЛИЧНОСТЬ В ВУЗЕ (конечно если все табельные номера в вузе уникальны).

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

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

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

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

Диаграмма «Сущность – атрибут». Связь между объектом и его свойством может быть различной. Рассмотрим классификацию связей между объектом и его свойствами (между сущностью и атрибутами):

1) по количеству принимаемых свойством значений связь считается:

– единичной;

– множественной.

Объект может иметь только одно значение какого-то свойства. Например, для объекта класса ЛИЧНОСТЬ таким свойством является дата рождения.

Свойство у объекта одновременно может принимать несколько значений. Например, при описании ЛИЧНОСТИ фиксируется свойство иностранный язык. Сотрудник (личность) может знать несколько иностранных языков.

2) по оценке постоянства связи, между сущностью и атрибутом во времени связь считается:

– статической (свойство с течением времени не изменяется, например: дата рождения);

– динамической (свойство может измениться со временем, например: ученая степень).

3) по оценке ассоциаций между объектом и его свойством:

– простые (неделимые);

– условные (свойство присуще не всем экземплярам сущности, например, свойство ученая степень для ЛИЧНОСТИ в вузе);

– составные (например, свойство «адрес» состоит из города, улицы, дома, квартиры).

Для обозначения связи между объектом и его свойством введены графические обозначения, приведенные в табл. 3.2.

Таблица 3.2

Графические обозначения связи между объектом и его свойством

Обозначение связи	Характер связи
	единичная связь
	множественная связь
	статическая связь
D	динамическая связь
	условная связь

Пример. Рассмотрим диаграмму «сущность – атрибуты» для предметной области «ВУЗ» (рис. 3.1).

Рис. 3.1. Диаграмма «сущность – атрибуты»

Данная диаграмма дает словесную интерпретацию сущности ЛИЧНОСТЬ через ее свойства. Сущность обозначается именем существительным в единственном числе. Сущность обладает
статическими единичными свойствами: фамилия, пол; динамическими множественными свойствами: образование, иностранный язык; динамическими единичными свойствами: ученая степень, адрес. В свою очередь свойство ученая степень является условным, а свойство адрес – составным.

Связи между объектами предметной области. Связь (от англ. relationship) – характер взаимосвязи (ассоциация), установленный между несколькими сущностями.

Набор связей (от англ. relationship set) – отношение между n (причем n => 2) сущностями, относящимися к некоторому набору сущностей.

В случае, когда n = 2 связь называется бинарной, n-арный набор связей (n > 2) можно заменить совокупностью бинарных, но n-арные связи отображают точнее семантику предметной области.

Связь обладает именем, степенью и классом принадлежности.

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

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

Рассмотрим существующие связи между указанными сущностями:

● так как каждый отдельный сотрудник работает в каком-либо отделе, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь «работает в» или ОТДЕЛ – РАБОТНИК;

● поскольку один из работников является руководителем отдела, то между упомянутыми сущностями СОТРУДНИК и ОТДЕЛ существует связь «руководит» или ОТДЕЛ – РУКОВОДИТЕЛЬ.

Число ассоциированных сущностей через набор связей с другой сущностью, получило название степени связи.

Могут существовать следующие степени бинарных связей:

1. Связь «один к одному» (1:1) представляет тот тип связи, когда один экземпляр объекта, от которого направлена связь, идентифицирует один и только один экземпляр объекта, к которому направлена связь, и наоборот.

Данный тип связи представлен на рис. 3.2, где прямоугольники обозначают сущности, а ромб – связь в соответствии с обозначениями принятыми в табл. 3.1. Поскольку степени связи для каждой сущности равны 1, то они соединены одной линией.

Рис. 3.2. Связь 1:1

Другой характеристикой связи кроме ее степени является класс принадлежности сущностей входящих в нее или кардинальность связи.

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

Раз в каждом отделе должен быть руководитель, то сущности «ОТДЕЛ» обязательно должна соответствовать сущность «СОТРУДНИК». Но не каждый сотрудник руководитель отдела, поэтому в такой связи не каждая сущность «СОТРУДНИК» имеет ассоциированную с ней сущность «ОТДЕЛ», таким образом, не каждый экземпляр сущности принимает участие в этой связи.

Говорят, что сущность «СОТРУДНИК» обладает обязательным классом принадлежности (такой факт обозначается указанием интервала возможных вхождений сущности в связь, это в данном случае 1,1), а сущность «ОТДЕЛ» обладает необязательным классом принадлежности (0,1). Теперь данная связь описывается как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 обозначается, как показано на рис. 3.3.

Рис. 3.3. Обозначение принадлежности

2. Связь «один ко многим» (1:М) представляет тот тип связи, когда один экземпляр объекта, от которого направлена связь, идентифицирует некоторое число (0, 1, …) экземпляров объектов данных, к которым направлена связь. А в обратном направлении эта связь идентифицирует только один объект.

Такая связь характерна для связи ОТДЕЛ – СОТРУДНИК, поскольку в отделе может работать любое число сотрудников, но каждый сотрудник может работать только в одном отделе. При этом не каждый отдел (например, вновь образованный) должен иметь хотя бы одного сотрудника.

Степень связи M графически отображается «вороньей лапкой» («древообразной» линией), так это сделано на рис. 3.4. В таком случае необходимо также учитывать класс принадлежности сущностей.

Кардинальность бинарных связей степени M обозначается, как представлено на рис. 3.5.

Рис. 3.5. Обозначение кардинальности бинарных связей степени n

3. Связь М:1 («много к одному»).

Пример. Предположим, рассматриваемое ранее предприятие действует на основании системы контрактов, которые заключаются с заказчиками. Такой факт изображается в модели «сущность – связь» связью КОНТРАКТ – ЗАКАЗЧИК, который объединяет сущности КОНТРАКТ(НОМЕР, СРОК ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС).

С одним заказчиком может быть заключено любое число контрактов, поэтому связью КОНТРАКТ – ЗАКАЗЧИК будет степень M:1 (рис. 3.6). В таком случае, раз каждый контракт заключается с конкретным заказчиком, а каждый заказчик обладает хотя бы одним контрактом, то каждая сущность характеризуется обязательным классом принадлежности.

Рис. 3.6. Пример связи М:1

4. Связь М:М («много ко многим») представляет тот тип связи, когда один экземпляр объекта, от которого направлена связь, идентифицирует некоторое число объектов, которому направлена связь, и наоборот. То есть связь является неуникальной в обоих направлениях.

Пусть в предыдущем примере для выполнения каждого контракта создана рабочая группа, в которую включены сотрудники из разных отделов. Так как каждый сотрудник может включаться в любое число рабочих групп, и каждая группа должна иметь не меньше, чем одного сотрудника, тогда связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА характеризуется степенью М:М (рис. 3.7).

Рис. 3.7. Пример связи М:М

При условии зависимости существования сущности x от сущности y, сущность x называется зависимой (при этом сущность x называют «слабой», а сущность y – «сильной»). В качестве примера рассмотрена связь между описанными ранее сущностями РАБОЧАЯ ГРУППА и КОНТРАКТ. Рабочая группа создается после того, как подписывается контракт с заказчиком, и прекращает свое существование по выполнению контракта. Поэтому, сущность РАБОЧАЯ ГРУППА зависима от сущности КОНТРАКТ. Зависимая сущность обозначается двойным прямоугольником, а ее связь с сильной сущностью – линией со стрелкой (рис. 3.8):

Рис. 3.8. Пример обозначения «слабой» и «сильной» сущностей

Кардинальность связи для сильной сущности всегда будет (1,1). Для зависимой сущности классы принадлежности и степени связи могут быть любыми. Например, рассматриваемое предприятие использует несколько банковских кредитов, которые могут быть представлены набором сущностей КРЕДИТ (НОМЕР ДОГОВОРА, СУММА, СРОК ПОГАШЕНИЯ, БАНК). По каждому кредиту осуществляются платежи в счет его погашения и выплаты процентов. Такой факт характеризуется набором сущностей ПЛАТЕЖ (ДАТА, СУММА) и набором связей «осуществляется по». В случае, если поступление запланированного кредита срывается, информацию о нем необходимо удалить из БД. Соответственно, нужно удалить все сведения о плановых платежах по этому кредиту. Поэтому, сущность ПЛАТЕЖ зависима от сущности КРЕДИТ (рис. 3.9).

Рис. 3.9. Пример обозначения «слабой» и «сильной» сущностей

На языке инфологического моделирования связь (ассоциация) между информационными объектами представляется предложением вида:

АССОЦИАЦИЯ[СУЩНОСТЬ S1, СУЩНОСТЬ S2](атрибут 1, атрибут 2),

где S1, S2 – степени связи, а атрибут 1 или 2 – атрибуты, входящие в состав ключа сущности.

Пример представления описания связи между сущностями КРЕДИТ и ПЛАТЕЖ.

Осуществляется по [Кредит 1, Платеж M] (Номер кредита, Номер платежа).

Разновидности объектов. Выше были рассмотрены объекты, не вникая в их сложность. На самом деле различают несколько разновидностей объектов (рис. 3.10).

Рис. 3.10. Классификация объектов

Объект называется простым, если он является неделимым.

Сложный объект представляет собой объединение других объектов.

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

Выделяют несколько разновидностей сложных объектов: составной, обобщенный, агрегированный.

Составной объект представляет собой связь «целое – часть».

Для отображения составного объекта в инфологической модели не используются никакие специальные обозначения. Характер связи между элементами составного объекта может быть 1:М, М:М. Примеры:

УЗЛЫ – ДЕТАЛИ, ГРУППА – СТУДЕНТ.

Обобщенный объект выражает присутствие связи «род – вид» между некоторыми объектами данной предметной области.

Связь «род – вид» характеризует собой классификацию ряда объектов предметной области по неким признакам.
Объекты, которые входят в состав обобщенного объекта являются его категориями. Такой атрибут «категория» называется дискриминантом.

Пример. Предметная область – ВУЗ. В данной предметной области обобщенным объектом является сущность личность (рис. 3.11).

Рис. 3.11. Пример обобщенного объекта ЛИЧНОСТЬ В ВУЗЕ

Классификация внутри обобщенного объекта может быть многоуровневой. Для обозначения подкласса внутри обобщенного объекта используется специальное графическое средство – треугольник.

Родовой и видовые объекты обладают определенным набором свойств.

Агрегированные объекты соответствуют некоторому процессу, в который вовлечены другие объекты.

Агрегированный объект обозначается ромбом и именуется существительным отглагольной формы.

Для примера, агрегированный объект ПОСТАВКА (рис. 3.12) соединяет в себе объекты ПОТРЕБИТЕЛЬ, ПОСТАВЩИК, ТОВАР, ДАТА ПРОДАЖИ. Агрегированный объект может иметь и собственные свойства.

Рис. 3.12. Пример агрегированного объекта

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

В процессе построения диаграмм выделяются следующие этапы:

1) идентификация сущностей и связей рассматриваемой предметной области;

2) идентификация семантической информации в наборах связей. К примеру, является ли представленный набор связей отображением связи 1:М;

3) определение кардинальностей связей;

4) определение атрибутов и наборов их значений (доменов);

5) организация данных в виде отношений «сущность – связь».

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

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

Отдел (номер ОТДЕЛА, НАИМЕНОВАНИЕ отдела);

Сотрудник (табельный номер, ФИО сотрудника, адрес РЕГИСТРАЦИИ);

Должность (НАИМЕНОВАНИЕ должности, оклад),

а также набор связей РАБОТАЕТ_В и ЗАНИМАЕТ.

Считаем, что совместительство в организации не разрешено.

Обобщая вышеизложенное, получается диаграмма «сущность – связь», показанная на рис. 3.13.

Рис. 3.13. Фрагмент диаграммы учета персонала

ER-модель представляет специфику ограничения целостности данных. В модели предусматриваются следующие ограничения на:

1) допустимые значения – определяют типы данных (численные, символьные и др. значения);

2) допустимые значения для атрибута – диапазон возможных значений (к примеру, возраст сотрудника может быть от 18 до 60 лет);

3) значения данных (например, сумма отчислений не может превышать суммы зарплаты).

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

Основные понятия
ER-диаграммы – сущность, атрибут, связь.

Сущность
– это некоторый объект реального мира,
который может существовать независимо.
Сущность имеет экземпляры, отличающиеся
друг от друга значениями атрибутов и
допускающие однозначную идентификацию.

Атрибут –
это свойство сущности. Например, сущность
КНИГА характеризуется такими атрибутами,
как автор, наименование, цена, издательство,
тираж, количество страниц. Конкретные
книги являются экземплярами
сущности
КНИГА. Они отличаются значениями
указанных атрибутов и однозначно
идентифицируются атрибутом “наименование”.
Атрибут, который уникальным образом
идентифицирует экземпляры сущности,
называется ключом.
Может быть составной
ключ,
представляющий комбинацию нескольких
атрибутов.

Предположим, что
проектируется база данных, предназначенная
для хранения информации о деятельности
некоторого банка. Этот банк имеет
филиалы. Филиалы управляются менеджерами.
Клиенты имеют в филиалах счета разных
типов – текущие, срочные, до востребования,
депозитные, карточные. Филиалы обрабатывают
эти счета. Описываемую предметную
область назовем БАНК. В ней могут быть
выделены четыре сущности: филиал,
менеджер, счет, клиент.

В реальном мире
существуют связи между сущностями.
Связь
представляет взаимодействие между
сущностями. Она характеризуется
мощностью,
которая показывает, сколько сущностей
участвует в связи. Связь между двумя
сущностями называется бинарной,
а связь между более чем с двумя сущностями
– тернарной.

В рассматриваемой
предметной области БАНК можно выделить
три связи.

1. МЕНЕДЖЕР –
УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ –
ОБРАБАТЫВАЕТ – СЧЕТ

3. КЛИЕНТ – ИМЕЕТ
– СЧЕТ

На ER-диаграмме
связь изображается ромбом.

23. Типы связи, их представление на er-диаграмме.

Важной характеристикой
связи является тип связи (кардинальность).
Рассмотрим типы связей 1–3.

Так как менеджер
управляет только одним филиалом, то
каждый экземпляр сущности МЕНЕДЖЕР
может быть связан не более чем с одним
экземпляром сущности ФИЛИАЛ. В этом
случае связь 1 имеет тип “один-к-одному”
(1:1).

Так как филиал
обрабатывает несколько счетов, а счет
обрабатывается только одним филиалом,
то каждый экземпляр сущности ФИЛИАЛ
может быть связан более чем с одним
экземпляром сущности СЧЕТ, а каждый
экземпляр сущности СЧЕТ может быть
связан не более чем с одним экземпляром
сущности ФИЛИАЛ. В этом случае связь 2
имеет тип “один-ко-многим” (1:М).

Так как счет может
совместно использоваться несколькими
клиентами и клиент может иметь несколько
счетов, то каждый экземпляр сущности
СЧЕТ может быть связан с несколькими
экземплярами сущности КЛИЕНТ и каждый
экземпляр сущности КЛИЕНТ может быть
связан с несколькими экземплярами
сущности СЧЕТ. В этом случае связь 3
имеет тип “многие-ко-многим” (М:N).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #

  11.05.2015457.22 Кб5461.doc

• #

  11.05.2015451.58 Кб11761.doc

• #
• #
• #
• #
• #
• #
• #
• #

Диаграмма «сущность-связь»

Дмитрий Андреевич Бурлаков

Эксперт по предмету «Базы данных»

Задать вопрос автору статьи

Модель «сущность-связь» можно представлять в виде графической схемы, что позволяет значительно облегчить анализ предметной области.
Рассмотрим один из вариантов обозначений элементов диаграммы «сущность-связь»:

Между атрибутами и сущностями, а также сущностями и связями проводится прямая линия.

Построение диаграммы «сущность-связь»

При построении диаграммы выполняют несколько шагов:

1. Идентифицируются представляющие интерес сущности и связи.
2. Идентифицируется семантическая информация в наборах связей (к примеру, является ли какой-либо набор связей отображением n:1).
3. Определяются кардинальности связей.
4. Определяются атрибуты и наборы их значений (домены).
5. Организовываются данные в виде отношений «сущность-связь».

Сделаем домашку
с вашим ребенком за 380 ₽

Уделите время себе, а мы сделаем всю домашку с вашим ребенком в режиме online

Бесплатное пробное занятие

*количество мест ограничено

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

Пример построения диаграммы «сущность-связь»

Выделим сущности и связи:

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

   

   набор связей РАБОТАЕТ_В и атрибут СТАВКА между ними. Значением атрибута СТАВКА может быть значение из интервала (0,1], которое определяет часть должностного оклада, получаемую данным сотрудником.

   

   ДОЛЖНОСТЬ ассоциируют фактически не с сущностями ОТДЕЛ и СОТРУДНИК, а со связью между ними. Обозначим данный факт, как показано на диаграмме (рисунок 2):

   

   Сущности ОТДЕЛ, СОТРУДНИК и связь РАБОТАЕТ_В преобразуются в некоторую новую сущность, которая имеет связь n:1 с сущностью ДОЛЖНОСТЬ.

   Отобразим ассоциации должностей, отделов и сотрудников при помощи бинарных связей.

   

   Введем еще одну сущность ШТАТНАЯ_ЕДИНИЦА, которая фактически заменит связь РАБОТАЕТ_В в новой сущности и поэтому будет иметь атрибут ставка.

2. Перечислим объекты, которые полезны при моделировании данных организации, которым соответствуют сущности:

   

   Атрибутом ПРОЦЕНТ_ВОЗНАГРАЖДЕНИЯ отражается та доля стоимости контракта, предназначенная для оплаты труда членов данной рабочей группы.

   Пусть один сотрудник из рабочей группы будет руководителем, поэтому введем связь РУКОВОДИТ между сущностями РАБОЧАЯ_ГРУППА и СОТРУДНИК (сотрудник может быть руководителем в любом количестве рабочих групп, а каждая рабочая группа может иметь лишь одного руководителя).

3. Рассмотрим сущность ЗАКАЗЧИК. В практической деятельности зачастую необходимо указывать национальность юридического лица, с которым организация заключает договор. Это нужно, например, для сохранения сведений о валюте для расчетов, языке контракта и т.д. Для отечественных организаций нужно хранить сведения о форме собственности (государственная или частная), т.к. от этого, например, зависит порядок налогообложения средств, которые получены за работу по контракту.

   Таким образом, очевидна необходимость введения еще двух непересекающихся множеств ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ (ВАЛЮТА, ЯЗЫК) и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ (ФОРМА_СОБСТВЕННОСТИ), при объединении которых получаем полное множество ЗАКАЗЧИК.
   Для определения подмножества, к которому относится конкретная сущность из набора ЗАКАЗЧИК нужно ввести атрибут НАЦИОНАЛЬНАЯ_ПРИНАДЛЕЖНОСТЬ, который называют дискриминантом. Данный тип связи отображают на диаграмме следующим образом:

   

   Полученная диаграмма «сущность-связь» будет иметь следующий вид:

   

Находи статьи и создавай свой список литературы по ГОСТу

Поиск по теме

Дата написания статьи: 12.09.2016

Графическая нотация модели: диаграммы “сущность-связь”

Типичной формой документирования логической модели предметной области при ER-моделировании являются диаграммы “сущность-связь”, или ER-диаграммы (Entity Relationship Diagram). ER-диаграмма позволяет графически представить все элементы логической модели согласно простым, интуитивно понятным, но строго определенным правилам — нотациям.

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

• Integration DEFinition for Information Modeling (IDEF1X). Эта нотация была разработана для армии США и стала федеральным стандартом США. Кроме того, она является стандартом в ряде международных организаций (НАТО, Международный валютный фонд и др.).
• Information Engineering (IE). Нотация, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности.

Построение ER-диаграмм, как правило, ведется с использованием CASE-средств. В данной лекции во всех примерах, если это не оговорено особо, будет использоваться нотация MS Office Visio 2007.

Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части (
рис.
6.3).

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

Каждый экземпляр сущности должен быть уникальным и отличаться от других атрибутов. Одним из основных компьютерных способов распознавания сущностей в ИС является присвоение сущностям идентификаторов (entity identifier). Поскольку сущность определяется набором своих атрибутов, для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность. Часто идентификатор сущности называют первичным ключом (primary key).

Первичный ключ (primary key) – это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения – это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (
рис.
6.3).

Выбор первичного ключа может оказаться непростой задачей, решение которой в состоянии повлиять на эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).

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

Рассмотрим кандидатов на первичный ключ сущности “сотрудник” (
рис.
6.5).

Здесь можно выделить следующие потенциальные ключи.

1. Табельный номер.
2. Номер паспорта.
3. Фамилия + Имя + Отчество.

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

Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ ( Фамилия + Имя + Отчество ) является плохим кандидатом, поскольку в организации могут работать полные тезки.

Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа ( Фамилия + Имя + Отчество ) дополним его атрибутами Дата рождения и Цвет глаз. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет глаз оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет глаз не является компактным.

При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В примере ключи № 1 и № 2 предпочтительней ключа № 3.

Атрибуты ключа не должны содержать нулевых значений. Если допускается, что сотрудник может не иметь паспорта или вместо паспорта иметь какое-либо другое удостоверение личности, то ключ № 2 не подойдет на роль первичного ключа. Если для обеспечения уникальности необходимо дополнить потенциальный ключ дополнительными атрибутами, то они не должны содержать нулевых значений. При дополнении ключа № 3 атрибутом Дата рождения нужно убедиться в том, что даты рождения известны для всех сотрудников.

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

Каждая сущность должна иметь, по крайней мере, один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами. Альтернативный ключ (Alternate Key) – это потенциальный ключ, не ставший первичным.

Некоторые сущности имеют естественные (натуральные) ключи. Например, естественным идентификатором счета-фактуры является его номер. В противном случае проектировщик может создать суррогатный ключ (Surrogate Key) – атрибут, значение которого создается искусственно и не имеет отношения к предметной области. При моделировании структур данных для ХД суррогатные ключи во многих ситуациях являются более предпочтительными.

Домены назначаются аналитиками и фиксируются в специальном документе — словаре данных (Data Dictionary). При создании логической модели домены могут быть специфицированы в сущностях на ER-диаграмме.

Каждый атрибут имеет домен. Домен можно определить как абстрактный атрибут, на основе которого можно создавать обычные атрибуты, при этом создаваемые атрибуты будут иметь все свойства домена-прародителя. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить домен “Возраст” как положительное целое число и определить атрибут Возраст сотрудника как принадлежащий этому домену.

На уровне логического моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или “не определен”. В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.

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

• для реализации реляционного ХД требуется использовать реляционную или объектно-реляционную СУБД, например, MS SQL Server 2008;
• в большинстве реляционных СУБД в качестве языка манипулирования и описания данных используется SQL, поддерживающий определенные стандарты, например, ANSI SQL-92.

Отношение (связь) сущностей на ER-диаграмме изображается линией, соединяющей эти сущности. Отношение читается вдоль линии либо слева направо, либо справа налево. На
рис.
6.6 представлено следующее отношение: каждая специальность по образованию должна быть зарегистрирована за определенным физическим лицом (персоной), физическое лицо может иметь одну или более специальностей по образованию.

В MS Office Visio имя связи, степень связи (мощность) и класс принадлежности сущности к связи определяется на вкладке “Свойства базы данных”, как показано на
рис.
6.7. Стрелка на линии связи указывает на родительскую таблицу.

При выделении связей акцент делается на выявление их характеристик. Связь представляет собой взаимоотношение между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей, например, экземпляр сущности “Сотрудник” (
рис.
6.6) связан с экземпляром сущности “Образование” по одинаковым значениям атрибутов Табельный номер. Другими словами, при создании связи в одной из сущностей, называемой дочерней сущностью, создается новый атрибут, называемый внешним ключом (Foreign Key, FK) (на
рис.
6.6 это атрибут Табельный номер ). Иногда атрибуты внешнего ключа обозначаются символом (FK) после своего имени.

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. На
рис.
6.8 показано присвоение связи имени.

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

Различают два типа сущностей: зависимые (Dependent entity) и независимые (Independent entity). Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.

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

Если модель создается при помощи CASE-средств, то при генерации схемы БД атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу “Сотрудники” без информации о табельном номере сотрудника.

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

Экземпляр сущности “Сотрудник” может существовать безотносительно к какому-либо экземпляру сущности “Отдел”, т. е. сотрудник может работать в организации и не числиться в каком-либо отделе.

Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (см.
рис.
6.8), неидентифицирующая – пунктирной (см.
рис.
6.9).

Связь “многие ко многим” (many-to-many relationship) может быть создана только на уровне логической модели. На
рис.
6.10 показан пример определения связи “многие ко многим”. Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя стрелочками на концах.

Связь “многие ко многим” должна именоваться двумя фразами – в обе стороны (в примере “принимает/лечится”). Это облегчает чтение диаграммы. Связь на
рис.
6.10 следует читать так: Врач <принимает> Пациента, Пациент <лечится> у Врача.

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

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

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.

Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Категориальная – дочерняя сущность в иерархии наследования.

Иерархия наследования (subtype relationship), или иерархия категорий, представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (штатные служащие), и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) “Сотрудник” (см.
рис.
6.11), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) “Штатный сотрудник” и “Совместитель”.

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

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

Иерархии категорий делятся на 2 типа – полные и неполные. В полной иерархии категорий (Complete subtype relationship) одному экземпляру родового предка (сущность “Сотрудник”,
рис.
6.12) обязательно соответствует экземпляр в каком-либо потомке, т. е. в этом примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной (Incomplete subtype relationship). На
рис.
6.11 показана неполная категория – сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность “Консультант” еще не внесена в иерархию наследования.

На
рис.
6.12 показан пример полной категории.

Полная категория помечается символом, неполная –.

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

Рассмотрим возможные стадии построения иерархии наследования.

1. Определение сущностей с общими (по определению) атрибутами.

   Предположим, в процессе проектирования созданы сущности “Штатный сотрудник” и “Совместитель” (
   рис.
   6.13). Можно заметить, что часть атрибутов у этих сущностей ( Фамилия, Имя, Отчество, Дата рождения, Должность ) имеет одинаковый смысл.

   

   Рис.
   6.13.
   Сущности с общими по смыслу атрибутами

2. Перенос общих атрибутов в сущность – родовой предок. В случае обнаружения совпадающих по смыслу атрибутов следует создать новую сущность “Сотрудник” – родовой предок, и перенести в нее общие атрибуты ( Фамилия, Имя, Отчество, Дата рождения, Должность ).
3. Создание неполной структуры категорий. Создается категориальная связь от новой сущности – родового предка к старым сущностям-потомкам. Новая сущность дополняется атрибутом – дискриминатором категории ( Тип ) (см.
   рис.
   6.11).
4. Создание полной структуры категорий. Проводится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность “Консультант” (
   рис.
   6.14).

   

   Рис.
   6.14.
   Дополнительная сущность с общими по смыслу атрибутами

   Общие атрибуты переносятся в родового предка, и категория преобразуется в полную. Сущность “Консультант” не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущности-потомки “Штатный сотрудник” и “Совместитель”.

5. Комбинации полной и неполной структур категорий. При необходимости создание иерархии категорий можно продолжить. Для каждого потомка может найтись сущность с общими атрибутами, тогда сущность-потомок становится родовым предком для новых потомков и т. д.