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

Пример 2.1.
Сущность – «персона»
Атрибуты:
Фамилия
Имя
Отчество
Дата рождения
Номер паспорта
Номер телефона
Экземпляр сущности «персона»
Значения атрибутов:
Иванов
Иван
Иванович
15.05.1967
40 03 012345
123-45-67, 987-65-43
Обратим внимание, что атрибут «номер телефона» может иметь более од-
ного значения.
Многозначные атрибуты. Может оказаться, что некоторый атрибут сущ-
ности способен принимать одновременно несколько значений. Реляционная
модель, в которую должна быть впоследствии преобразована данная инфологи-
ческая модель, не допускает многозначности атрибутов. Данное противоречие
должно быть разрешено. Возможное решение – образование новой сущности.
В приведенном ранее примере атрибут «номер телефона» становится кан-
дидатом на создание сущности «номер телефона».
Другое решение – заменить название атрибута «номер телефона» на «пе-
речень номеров телефонов» и позволить хранить несколько номеров, пере-
численных через запятую, в виде одной текстовой строки. Кроме того, некото-
рые СУБД позволяют размещать в ячейках таблиц массивы, содержащие не-
сколько элементов. Однако при сохранении многозначного атрибута могут воз-
никнуть сложности с извлечением данных. Например, будет затруднительно
составить запрос следующего вида: «извлечь из БД сведения о персонах,
имеющих заданный номер телефона».
Кроме того, возможное решение зависит от общего контекста разрабаты-
ваемой БД. Если речь идет о контактных номерах телефонов сторонних клиен-
тов, номер, скорее всего, является атрибутом и возможные повторы маловеро-
ятны и несущественны. Если же ставится задача построения телефонного спра-
вочника некоторой организации, в которой, с одной стороны, один сотрудник
может быть доступен по нескольким номерам, а с другой – по одному номеру
может быть доступно несколько сотрудников, номер телефона, очевидно, ста-
новится самостоятельной сущностью.
Домен атрибута – множество значений, которые атрибут может прини-
мать. Доменом может быть, например, множество допустимых значений даты,
диапазон целых чисел или множество текстовых строк. Также это может быть
множество цветов и оттенков или список компаний - поставщиков.
При реализации модели на языке конкретной СУБД домены приводятся в
соответствие с имеющимися типами данных.
Если в процессе разработки и анализа модели выявляются достаточно спе-
цифические домены (например - «множество сотовых операторов»), они могут
рассматриваться в качестве кандидатов на создание новых сущностей.
Идентификация сущностей. Для того чтобы экземпляры сущности можно
было отличить один от другого, следует описать способ их идентификации.
Роль идентификатора выполняет атрибут или группа атрибутов, совокуп-
ность значений которых уникальна для каждого экземпляра сущности. В реля-
ционной модели такой уникальный идентификатор называют первичным
ключом.
Во многих случаях для идентификации может быть использован специаль-
ный целочисленный атрибут (номер экземпляра сущности).
Связи между сущностями. После определения сущностей следует описать
связи (взаимоотношения) между ними.
Связь устанавливается между экземплярами сущностей, а не их типами.
Например, для сущностей «клиент» и «заказ» связь устанавливается между кон-
кретным клиентом и его заказами. Для связывания экземпляров сущностей ис-
пользуются их уникальные идентификаторы экземпляров сущности (первичные
ключи).
Виды связей:
Один-к-одному
Один-ко-многим
Многие-ко-многим
Вид связи определяется количеством экземпляров сущностей, участвующих
в связи с каждой из сторон.
При связи вида «один-к-одному», экземпляр каждой из сущностей может
быть связан не более чем с одним экземпляром другой сущности.
Возможное применение связи «один-к-одному» – хранить отдельно некото-
рый набор секретных атрибутов, для доступа к которым нужны более высокие
привилегии. Пример – связь между сущностями «клиент» и «кредитная карта».
При обнаружении связи вида «один-к-одному» следует проанализировать
причину ее возникновения. Часто такую связь лучше преобразовать в «один-ко-
многим» или уничтожить, объединив две сущности в одну (новая сущность бу-
дет содержать атрибуты обеих первоначальных сущностей).
Пример связи «один-ко-многим» – связь между клиентом и его заказами.
Клиент может сделать много заказов (или ни одного), но заказ может быть свя-
зан только с одним клиентом. Другой пример: в кошельке может одновременно
находиться много денежных банкнот, но каждая банкнота в определенный мо-
мент времени может находиться не более, чем в одном кошельке.
Между приведенными примерами есть отличие: заказ обязательно должен
быть связан с 1 клиентом (без клиента он не существует), а банкнота может
быть связана с 0 кошельков или с 1 кошельком (она способна существовать без
кошелька).
«Один-ко-многим» - самый распространенный вид связи в реляционных ба-
зах данных.

При связи между сущностями вида «многие-ко-многим» каждому экземп-
ляру первой сущности могут быть поставлены в соответствие несколько экзем-
пляров второй сущности (и наоборот).
Пример – связь между журналами и подписчиками. Подписчик может вы-
писать несколько журналов и каждому наименованию журнала могут соответ-
ствовать много подписчиков.
Реляционная модель баз данных не позволяет реализовать связь «многие-
ко-многим». Эта проблема может быть решена введением дополнительной
сущности (см. ниже).
ER-диаграммы. Наименование диаграмм происходит от английского «En-
tity-Relationship» («сущность-связь»).
Классическая форма представления сущностей и их атрибутов использует
прямоугольники для обозначения самих сущностей и овалы – для обозначения
их атрибутов. Иногда в диаграммах атрибуты отдельных сущностей опускают,
чтобы более очевидной была структура в целом. Также зачастую удобным ока-
зывается применение компактной формы описания сущностей.
Пример. 2.2. На рис. 2.1 представлена рассмотренная ранее сущность «Пер-
сона» в двух формах – классической и компактной. Символом «*» помечен ат-
рибут, являющийся идентификатором сущности (иногда вместо использования
звездочки, имя такого атрибута подчеркивают).
*Номер
Фамилия
Имя
Персона
Отчество
Дата рождения
Паспорт
Телефон
Персона
*Номер
Фамилия
Имя
Отчество
Дата рождения
Паспорт
Телефон
Рис. 2.1. Две формы представления сущности
В классической форме представления ER-диаграмм связи между сущностя-
ми принято обозначать ромбом.
Пример 2.3. На рис. 2.2 изображена диаграмма, описывающая две сущно-
сти и связь между ними. Пометки «1» и «N» на концах указывают на то, что тип
связи - «один ко многим».

Клиент
Клиент
оформил
N
Заказ
*Номер
Фамилия
Имя
Отчество
Кредитка
N
Заказ
*Номер
Клиент
Сумма
Дата
Рис. 2.2. Связи между сущностями
В приведенном примере экземпляр клиента может существовать независи-
мо от наличия заказов. Напротив, заказ обязательно должен быть связан с кли-
ентом.
Сущности, для которых связи являются обязательными, называют слабы-
ми. В случае если при проектировании необходимо отметить слабую сущность,
ее принято обозначать прямоугольником со сдвоенными границами (рис. 2.3).
Клиент
оформил
N
Заказ
Рис. 2.3. Обозначение слабой сущности
Преобразование связи «многие-ко-многим». Связь вида «многие-ко-
многим» (рис. 2.4) нереализуема в реляционной модели данных.
Сущность 1
N
связь
N
Сущность 2
Рис. 2.4. Связь «многие-ко многим»
Такую связь требуется преобразовать в две связи вида «один ко многим»
введением некоторой вспомогательной сущности.

Сущность
N
Составная
сущность
N
Сущность
Рис. 2.5. Преобразованная связь
Сущность, предназначенная для образования связи между другими сущно-
стями, называется составной.
Составная сущность иногда обозначается ромбом, вписанным в прямо-
угольник.
Составная
сущность
Уникальный идентификатор составной сущности образуется сочетанием
идентификаторов связанных с ней сущностей.
Кроме собственно образования множественной связи, составная сущность
может хранить дополнительные данные, относящиеся к этой связи (атрибуты
этой связи).
Пример 2.4. Есть сущность «Товар», описывающая имеющиеся товары и
сущность «Заказ», регистрирующая заказы, оформленные на эти товары.
Заказ
Товар
*Номер
Клиент
Дата
N
N
*Номер
Наименование
Цена
В каждый заказ может быть включено много видов товаров. Каждый вид
товара может входить во многие заказы. Также необходимо где-то хранить ин-
формацию о количестве позиций каждого товара, входящего в заказ.
Эта информация не может являться атрибутом заказа. В заказ может входить
много товаров и для каждого требуется хранить его количество. Как уже было
сказано, многозначность атрибутов не допускается. Количество также не может
быть атрибутом товара, поскольку товары существуют независимо от заказов.
Решение проблемы – введение составной сущности «Состав заказа».
Заказ
Состав заказа
Товар
*Номер
Клиент
Дата
1 N
*Заказ
*Товар
Количество
N
*Номер
Наименование
Цена
Каждый экземпляр сущности «Состав заказа» связан только с одним зака-
зом и только с одним видом товара и содержит сведения о количестве единиц
данного товара, входящих в данный заказ. Идентификатором экземпляра сущ-
ности «Состав заказа» является пара идентификаторов «Товар» и «Заказ».
Анализ предметной области и построение модели. Рассмотрим основные
шаги, которые нужно выполнить для построения инфологической модели
предметной области. Иногда выявленные на каком-то этапе противоречия мо-
гут потребовать повторения уже проделанных действий с учетом новых фактов.
1.
2.
3.
4.
5.