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

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

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

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

Задача: разработать ER-модель для АИС некоторой оптовой торговой фирмы .

Основные этапы решения задачи

1. Изучение предметной области и процессов, происходящих в ней - как правило, осуществляется путем опроса сотрудников фирмы, чтения документации, изучения формы заказов, накладных и т.п.

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

· Хранить информацию о покупателях.

· Печатать накладные на отпущенные товары.

· Следить за наличием товаров на складе.

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

· Покупатель - кандидат на сущность.

· Накладная - кандидат на сущность.

· Товар - кандидат на сущность.

· (?) Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

· (?) Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

3. Определение связей между сущностями. Для рассматриваемого примера сразу возникает очевидная связь между сущностями: «Покупатели могут покупать много Товаров » и «Товары могут продаваться многим Покупателям ». Первый вариант диаграммы выглядит так:

Задав дополнительные вопросы менеджеру, были выявлены новые данные о том, что:

· фирма имеет несколько складов, а каждый товар может: храниться на нескольких складах; быть проданным с любого склада;

· покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара;

· каждый покупатель может получить несколько накладных;

· каждая накладная выписывается на одного покупателя;

· каждая накладная содержит хотя бы один товар (не бывает пустых накладных);

· каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных;

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

Учитывая новые сведения, диаграмма примет следующий вид:

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

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

· каждый товар имеет наименование, цену, а также характеризуется единицами измерения;

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

· каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

· Юридическое лицо – т.к. фирма работает только с юридическими лицами (не работает с физическими лицами), то такой атрибут выделять нет смысла.

· Наименование покупателя - характеристика покупателя.

· Адрес - характеристика покупателя.

· Банковские реквизиты - характеристика покупателя.

· Наименование товара - характеристика товара.

· (?) Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

· Единица измерения - характеристика товара.

· Номер накладной - уникальная характеристика накладной.

· Дата накладной - характеристика накладной.

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

· (?) - это характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".

· (?) Цена товара в накладной - характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

· Сумма накладной - характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

· Наименование склада - характеристика склада.

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

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

Атрибуты Количество товара в накладной и Цена товара в накладной являются атрибутами сущности Список товаров в накладной .

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

В результате ER-диаграмма примет вид:

Модели данных

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

Модель данных определяется тремя компонентами:

· допустимой организацией данных;

· ограничениями целостности (семантической);

· множеством операций, допустимых над объектами модели данных.

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

Ограничения целостности поддерживаются средствами, предусмотренными в модели данных для выражения ограничений на значения данных и ассоциации, которые (ограничения) характеризуют достоверные состояния БД.

Ряд ограничений целостности поддерживается моделью данных по умолчанию и распространяется на все типовые ситуации, возникновение которых возможно при внесении изменений в БД. Например, если между записями типа ГРУППА и СТУДЕНТ установлена иерархическая связь, то СУБД воспрепятствует удалению сведений о студенческой группе, если с ней связана хотя бы одна запись о студенте.

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

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

Поддерживаемые СУБД модели данных традиционно разбиваются на: сетевые , иерархические , реляционные (имеются также другие модели данных). Эта классификация условна, т.к. каждая СУБД поддерживает свою оригинальную модель данных. И даже если модель данных относится к одной из выделенных разновидностей, она может содержать достаточно много отличительных особенностей. Наиболее распространенными моделями являются реляционные модели данных (РМД).

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

Базовыми понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

Рис. 12. Пример связи между сущностями

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

Рис. 13. Пример рекурсивной связи

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

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

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

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

Рис. 14. Изображение сущности с ее атрибутами

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

Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем, Мы рассмотрим только очень краткие и неформальные определения трех первых нормальных форм.

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

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

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

Мы остановились только на самых важных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие:

Подтипы и супертипы сущностей. ER-модель позволяет задавать отношение IS-A между типами. При этом если Т, IS-A Т 2 (где Т 1 и Т 2 - типы сущностей), то Т, называется подтипом Т 2 , а Т 2 - супертипом Т.. Т. о., существует возможность наследования типа сущности, исходя из одного или нескольких супертипов.

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

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

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

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

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

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

5.1. Описание информационного представления предметной области. ER-диаграмма

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

Чаще всего концептуальная модель представляется в виде диаграммы сущностей – связей ( entity – relationship ) или ER-диаграммы . Процесс построения ER-диаграммы называется ER-моделированием .

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

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

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

Имя сущности при ER-моделировании, как правило, записывается заглавными буквами. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе. Так, например, в качестве свойств сущности ФАКУЛЬТЕТ можно указать номер факультета, название факультета, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов.

Для информационного описания сущности вводится понятие атрибута.

Атрибут – поименованное свойство (характеристика) сущности. Атрибут представляет собой информационное отображение свойства сущности и принимает конкретное значение из множества допустимых значений. Так, например, для сущности ФАКУЛЬТЕТ атрибут "название" у конкретного экземпляра сущности принимает конкретное значение "вычислительной математики и кибернетики". Таким образом, атрибут представляет информационное описание количественных или качественных свойств сущности, описывает состояние сущности, позволяет идентифицировать сущность . Информация о сущности представляется совокупностью атрибутов. Такую совокупность атрибутов часто называют записью об объекте .

Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ФАКУЛЬТЕТ составляет класс сущностей ФАКУЛЬТЕТ. Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс .

Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств) . Выше мы определили сущность как то, о чем будет накапливаться информация в информационной системе. Это только одна сторона. Информация должна не просто храниться сама по себе, а использоваться для удовлетворения информационных потребностей пользователя. Для реализации подавляющего числа запросов пользователю прежде всего необходимо найти интересующий его экземпляр сущности (с целью обработки, корректировки, удаления). Поэтому важнейшим свойством сущности является однозначная идентификация ее экземпляров по одному или группе атрибутов (уникальному идентификатору) . У сущности ФАКУЛЬТЕТ это, например, номер факультета, у сущности СТУДЕНТ это может быть атрибут "фамилия", если у всех студентов разные фамилии, группа атрибутов "фамилия", "имя", "отчество", или специально введенный уникальный идентификатор , например дополнительно введенный атрибут "код студента".

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

Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности показан на рис. 5.1

Рис. 5.1.

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

Класс связей может затрагивать несколько классов сущностей . Число классов сущностей , участвующих в связи, называется степенью связи n = 2, 3, ... Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ФАКУЛЬТЕТ связью "учится на факультете". Степень этой связи равна двум. При n =2 связь называется бинарной. Заметим, что связь нужно рассматривать как двустороннюю: "студент учится на факультете" и "на факультете учатся студенты". Рассмотрим классификацию бинарных связей . В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей :

Связь 1:1 . Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и УЧЕБНЫЙ ПЛАН ПО СПЕЦИАЛЬНОСТИ ДЛЯ ФАКУЛЬТЕТА (каждому факультету соответствует свой учебный план по специальности или направлению).
Связь 1:M . Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете учатся много студентов).
Связь M:N . Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ (на факультете может быть несколько специальностей и одна и та же специальность может быть на нескольких факультетах).

Числа, описывающие типы

ER-диаграмма

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

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

Сущности. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в рассматриваемой далее ER-диаграмме, приведенной на рис. 5.4, ПОДЧИНЕННЫЙ - сущность слабого типа.

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

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

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

Контур эллипса рисуется штриховой линией, если свойство производное, например, свойство «Кол-во» сущности ПОСТАВЩИК.

Эллипс соединяется пунктирной линией, если свойство условное, например, свойство «Иностранный язык» сущности СОТРУДНИК.

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

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

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

Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь «Подчинение» со стороны сущности ПОДЧИНЕННЫЙ.

Связь может быть модифицирована указанием роли. Например, для рекурсивной связи «Состав» указаны роли: «Деталь состоит из ...» и «Деталь входит в состав ...».

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

Физическая модель (Табличная) данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД.

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

В прошлой лекции мы познакомились с методологиями IDEF0 и DFD которые позволяют описать бизнес-процессы протекающие в информационной системе. В модели DFD мы рассмотрели элемент - хранилище данных, который показывает типы информации, которой оперирует система. Однако эта методология не предназначена для описания структуры хранимой информации. Для этого больше подходят различные Entity Relationship - диаграммы (сущностные диаграммы), целью которых является описание структуры хранимых данных и взаимосвязей между ними. Разработаны методики, которые позволяют преобразовать такие данные в набор команд, который создаст необходимые хранилища (таблицы) внутри базы данных информационной системы.

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

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

Основные преимущества ER-моделей:

Точный и понятный формат документирования структуры информации.
Позволяет указать требования к данным и связям между ними.
Позволяет наглядно показать структуру хранилища для облегчения проектирования базы данных.
Существуют методы отображения ER-моделей в таблицы БД и обратно.
Закладывают основу для интеграции с другими приложениями.

Основные типы объектов на ER-диаграмме:

Сущность (Entity) - тип объектов, информация о которых будет хранится в БД. Например: отделы, сотрудники, товары, накладные.
Атрибут (Attribute) - элементы из которых состоят сущности. Например, для сущности «товары» атрибутами могут быть «название», «описание», «количество», «цена» и другие, в зависимости от потребностей информационной системы. В зависимости от нотации ER-диаграммы рядом с атрибутом, кроме его имени указывают тип и обязательность заполнения. На слайде представлена ER-диаграмма в нотации «Information Engineering», согласно которой для атрибута указывается имя, тип, и является он внешним и/или первичным кличем.
Связь (Relationship) показывают связи между сущностями. Например сотрудник работает в отделе, где «отдел» и «отдел» - сущности.

Сущность - набор объектов реального мира, каждый из которых имеет следующие характеристики:

Уникален (может быть отделен от всех прочих каким-либо образом)
Играет определенную роль в моделируемой системе
Может быть описан одним или более элементом информации (Атрибутом)

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

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

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

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

Базовые термины

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

" Тип данных " (type, domean - домен) - множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
" Отношение " (relation) - множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
" Ключ " (key) - группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
" Внешний ключ " (foreign key) - группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
" Операции " (operation) - множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
" Реляционная база данных " (relational database) - набор отношений.

"Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

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

Приведенный взгляд на реляционную БД (набор отношений и операции) характерен для реляционной алгебры . Это не единственная точка зрения. Каждый набор величин в переменной отношения можно понимать как истинное высказывание ("предикат"): имеется такой-то сотрудник с такими-то свойствами; такой-то отдел и так далее. Тем самым реляционная база данных в каждый момент времени представляет собой набор истинных высказываний о предметной области, сформулированный через отношения. По сути, набор высказываний в переменных отношений и образует модель предметной области, представленную базой данных. Такой взгляд на реляционную БД характерен для реляционного исчисления . Оба взгляда на реляционную модель хорошо изучены и доказана их выразительная равносильность.

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

Отношение → Таблица
Кортеж → Строка, запись
Кардинальность → Количество строк
Атрибут → Столбец, поле
Степень → Количество столбцов
Первичный ключ → Идентификатор
Домен → Область допустимых значений

Ключевые поля

Часть из атрибутов отношения является ключевыми или ключами. Выделяют несколько типов ключей:

Простой ключ - состоит из одного атрибута, составной - из нескольких.
Потенциальный ключ - атрибут или набор атрибутов, которые могут идентифицировать каждый из кортежей отношения. Например в отношении паспортный стол («Номер паспорта») и («ФИО» и «Дата рождения») - потенциальные ключи, которые позволяют уникальным образом идентифицировать каждого человека.
В каждом отношении может быть только один первичный ключ - атрибут или набор атрибутов значения которого уникальным образом идентифицирую каждую запись. Если такими свойствами обладают несколько наборов атрибутов, то один из них выбирается первичным, а все остальные - альтернативными.
Внешний ключ - хранит значение первичного ключа другого отношения. Внешние ключи используются для связи между отношениями.

Первичный ключ

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

Внешний ключ

Внешний ключ используется для установления связей между отношениями. Например возьмем два отношения «Владельцы» (первичный ключ «номер паспорта») и «Недвижимость». Чтобы установить, кто владеет каждым из объектов недвижимости мы свяжем эти отношения по значению атрибута «номер паспорта». В отличии от первичного ключа значение внешнего ключа может быть неопределённо (строка 4 на слайде) - если мы не знаем владельца недвижимости мы его не указываем. В отличие от первичного ключа значение внешнего ключа может повторятся (стоки 1,3 на слайде) - у одного владельца может быть несколько объектов недвижимости. Однако то что атрибут «номер паспорта» в отношении «Недвижимость» является внешним ключом на первичный ключ отношения «Владелец» гарантирует что значением атрибута «номер пастора» могут быть только значения из первичного ключа. Мы не можем указать в качестве значения атрибута номер пастората человека, которого еще нет в отношении «Владелец» (строка 5).

Устанавливая внешний ключ можно явно задать поведение СУБД, если изменить значение первичного ключа или удалить кортеж. Однако при этом сохраняется правило «во внешнем ключе хранятся только значения, которые есть в первичном ключе или неопределённое значение (NULL)».

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

ЕR-модели: связи

На ER-моделях внешние ключи отображаются в виде связей.

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

Разберем эти характеристики.

Участие сущности в связи

Обозначается на связи поперечной линией или кружком.

Поперечная линия означает обязательное (mandatory ) участие сущности в связи, а кружок - необязательное (optional ).

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

В отделе может работать несколько сотрудников. Сотрудник должен работать в каком-то из отделов.

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

Наиболее распространены бинарные связи - они связываю две разные сущности («Отдел»- «Сотрудник», «Заказ»- «Товары», «Курс»- «Лекции», «Группа»- «Студенты»). Менее распространенными, но все-таки часто используемыми являются унарные связи. С их помощью обычно задают отношение вложенности на однотипных объектах (отношение «Детали» - можем указать составной частью какой детали является данная, отношение «Сотрудники» - можем указать, кто из сотрудников является начальником для данного).

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

Мощность может быть:

один-к-одному (1:1) - в группе студентов один староста;
один-ко-многим (1:N) - в одном отделе работает много сотрудников;
многие-ко-многим (M:N) - один покупатель купил много товаров, товаров покупали много покупателей.

Сила связи : сильная связь (Identifying Relationship)

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

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

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

Сила связи: Слабая связь (Nonidentifying Relationship)

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

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

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

Рекурсивная-связь (унарная связь)

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

Поставщик МОЖЕТ работать с НУЛЕМ или БОЛЕЕ заказчиков (id_Customer).

Заказчик ДОЛЖЕН работать с одним поставщиком (id_Sup).

Но поставщик и заказчик - это фирма ли организация - объекты одного типа и потому хранятся в одном отношении.

Связь многие-ко-многим.

Пример: поставщики могут поставлять много типов товаров. Разные поставщики могут поставлять одинаковые типы товаров.

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

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

ER-модели и реальность

При ближайшем рассмотрении связи типа "один к одному" почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Представим, что А - поставщик, B - товар.

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (Supplier) должен поставлять только один уникальный набор товаров (Invoice). С точки зрения теории тут все хорошо. На практике это не допустимо: ни кто не будет искать нового поставщика, если проверенный вами поставщик может предоставить несколько номенклатур товара. А теперь об эмоциях, кот будет испытывать оператор при попытке ввода данных о новом поставщике. Он не сможет ввести данные ни в одну из таблиц. Так что весь багаж неприличной лексики будет направлен в ваш адрес.

Optional-mandatory. Пример связи приведен на слайде. Как видим у оператора теперь все хорошо: данные вводить он может. У бизнеса опять проблема: он должен искать нового поставщика, даже если проверенный вами поставщик может предоставить несколько номенклатур товара. А бизнесу нужны проблемы? Нет. Он должен функционировать. Как удовлетворить бизнес? Ответ простой. При проектировании БД нужно думать о нормализации. Если Supplier - сущность, то используйте связи типа optional-mandatory (mandatory-optional) или optional-optional. Хотя чаще всего связи один-к-одному - это ошибка.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса опять проблема. Подведем итоги для связи один-к-одному. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь; - optional-mandatory (mandatory-optional) или optional-optional, то сопровождение бизнеса проблематично.

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

Связь один-ко-многим mandatory-optional - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

Связь один-ко-многим optional-optional - Как A, так и B могут существовать без связи между ними.

В терминах предыдущего слайда эти диаграммы можно проиллюстрировать на следующих примерах.

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

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (A) должен поставлять один или более наборов товаров (B). С точки зрения теории тут все хорошо. Однако на практике оператор не сможет ввести данные ни в одну из таблиц, поскольку записи необходимо одновременно вводить в обе таблицы.

Optional-mandatory. В этом случае у оператора теперь все хорошо: данные вводить он может, а у бизнеса могут возникнуть проблемы. Дело в том, что связь optional-mandatory предполагает, что поставщик (A) должен поставлять один или более наборов товаров (B), в то время как B может принадлежать поставщику. Другими словами, товары могут существовать без поставщика, в то время как у поставщика есть товары. Т.е. возможно неконтролируемое ведение бизнеса: кто поставил товар? С кого спрашивать? А бизнесу проблемы нужны? Нет. Он должен давать прибыль. В этом случае лучше использовать mandatory-optional: поставщик может поставлять один или более наборов товаров, в то время как товар должен принадлежать поставщику. Другими словами, у товара есть поставщик, а данные о поставщиках, которые когда-то поставляли товар будут сохранены. И овцы целы и волки сыты - оператор может вводить данные и бизнесмен в кусе дел.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса проблема - безконтрольность: Товар может существовать без поставщика и поставщик без товара.
Подведем итоги для связи один-ко-многим. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь, поскольку вводить записи одновременно в обе таблицы невозможно; - optional-optional, то сопровождение бизнеса проблематично.

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

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

Многие-ко-многим mandatory-optional - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

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

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

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

Optional-optional М:М Пример связи приведен на слайде 3. Это сетевая структура.

Контрольный список вопросов к сущностям

Отражает ли имя сущности суть данного объекта?
Нет ли пересечения с другими сущностями?
Имеются ли хотя бы два атрибута?
Всего атрибутов не более восьми?
Есть ли синонимы/омонимы данной сущности?
Сущность определена полностью?
Есть ли уникальный идентификатор?
Имеется ли хотя бы одна связь?
Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
Ведется ли история изменений?
Имеет ли место соответствие принципам нормализации данных?
Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
Не имеет ли сущность слишком общий смысл?
Достаточен ли уровень обобщения, воплощенный в ней?

Контрольный список вопросов к атрибутам:

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
Имеет ли атрибут только одно значение в каждый момент времени?
Отсутствуют ли повторяющиеся значения (или группы)?
Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
Не может ли он быть пропущенной связью?
Нет ли где-нибудь ссылки на атрибут как на "особенность проекта", которая при переходе на прикладной уровень должна исчезнуть?
Есть ли необходимость в истории изменений?
Зависит ли его значение только от данной сущности?
Если значение атрибута является обязательным, всегда ли оно известно?
Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
Зависит ли его значение только от какой-то части уникального идентификатора?
Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?