Бинарная связь в модели сущность связь. Моделирование данных Модель «сущность-связь». Рассматриваемые вопросы: Элементы модели «сущность-связь» Диаграммы «сущность-связь» Слабые сущности Подтипы. Семантические модели данных

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

Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (ERM). Она была впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERM являются сущность, связь и атрибут.

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

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов, как «Поставщик», «Сотрудник», «Заказ». Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис. 2.23).

Рис. 2.23. Графическое представление сущности

Основной (неформальный) способ идентификации сущностей - это поиск абстракций, описывающих физические или материальные объекты, процессы и события, роли людей, организации и другие понятия. Единственным формальным способом идентификации сущностей является анализ текстовых описаний предметной области, выделение из описаний имен существительных и выбор их в качестве «кандидатов» на роль абстракций.

Экземпляр сущности - это конкретный представитель данной сущности. Например, экземпляром сущности «Сотрудник» может быть «Сотрудник Иванов».

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

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

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

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

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

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

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

Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты, как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.

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

Рис. 2.24. Сущность с атрибутами

Виды атрибутов :

· простой - состоит из одного элемента данных;

· составной - состоит из нескольких элементов данных;

· однозначный - содержит одно значение для одной сущности;

· многозначный - содержит несколько значений для одной сущности;

· необязательный - может иметь пустое (неопределенное) значение;

· производный - представляет значение, производное от значения связанного с ним атрибута.

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

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

Рис. 2.25. Сущность с уникальным идентификатором

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

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

Рис. 2.26. Обозначение сущностей и связи

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

Мощностью связи называется максимальное число экземпляров сущности, которое может быть связано с одним экземпляром данной сущности. Мощность связи может быть равна 1, N (любое число) и может быть конкретным числом. Мощности связи на рис. 2.26 означают: каждый сотрудник может работать не более чем в одном отделе, а в каждом отделе может работать любое число сотрудников.

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

Связь может иметь один из следующих трех типов (в зависимости от значения мощности):

1. Один-к-одному (обозначается 1:1), показана на рис. 2.27.

Рис. 2.27. Связь типа 1:1

2. Один-ко-многим (обозначается 1:п), показана на рис. 2.26.

3. Многие-ко-многим (обозначается m:n), показана на рис. 2.28.

Рис. 2.28. Связь типа min

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

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

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

В прошлой лекции мы познакомились с методологиями 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. Это сетевая структура.

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

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

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

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

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

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

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

и научитесь:

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

Введение

Для логического проектирования реляционных ХД применяются следующие методики.

Метод моделирования "сущность-связь" (ER modeling) дает абстрактную модель предметной области сущности (entities), взаимосвязи (relationships) между сущностями и атрибуты (attributes) для представления свойств сущностей и взаимосвязей.
Метод многомерного моделирования ( Dimensional modeling) дает абстрактную модель предметной области , используя следующие основные понятия: показатели или метрики (measures), факты (facts) и измерения (dimensions).
Методы моделирования временных данных ( Temporal data modeling ) дают абстрактную модель фрагмента предметной области , представляющего временные ряды данных, и используют следующие основные понятия: временные метки (timestamps), временной ряд ( time series ), дата, диапазон дат, классы.
Метод моделирования "свод данных" (Data Vault) дает абстрактную модель фрагмента предметной области , основываясь на математических принципах нормализации отношений , и использует следующие основные понятия: сущности-концентраторы ( Hub Entities ), связывающие сущности ( Link Entities ), сущности-сателлиты ( Satellite Entities ),

В настоящей лекции мы рассмотрим метод моделирования " сущность-связь ".

Понятие предметной области и архитектура данных

Понятие предметной области

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

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

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

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

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

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

На рис. 6.1 представлен один из подходов к классификации объектов предметной области .

Рис. 6.1.

Примерами сущностей (с точки зрения логической модели предметной области ) или объектов (с точки зрения внешнего мира по отношению к ИС) являются: студент, группа студентов, аудитория для занятий, время занятий и. т. д.

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

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

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

Пример .

Рассмотрим высказывание: "Студент Иванов А.А, родился в 1992 году". Оно выражает следующие свойства объекта "Иванов А.А.":

в явном виде - год рождения;
в неявном виде – принадлежность к студентам.

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

РОДИЛСЯ (Иванов А.А., 1982)

ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.)

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

На рис. 6.2 представлен один из подходов к классификации ситуаций в рамках предметной области .

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

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

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

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

Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же, как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.

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

Архитектура данных предметной области

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

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

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

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

Грубо говоря, уровень структуризации данных определяет количество запросов, на которые можно получить ответы в системе складирования данных. Если в ХД поддерживается высокий уровень структуризации данных, то система поддерживает практически любой запрос в рамках предметной области ХД. В примере, приведенном выше, невозможно получить ответ на вопрос: сколько абонент Иванов А.А. заплатил за пять секунд разговора первого января 2009 года.

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

Структуризация данных предполагает разбиение всего набора данных на определенные классы с целью дальнейшей детализации внутри выделенного класса. Для ХД характерны три основных вида данных (класса).

Фактические данные (Real-time data) представляют собой текущее состояние количественных и качественных показателей деятельности организации. Источником таких данных являются обычно OLTP-системы. Таким данным присущ высокий уровень структуризации. Для того чтобы использовать такие данные в ХД, их нужно предварительно обработать с помощью процедур очистки.
Производные данные (Derived data) представляют собой данные, которые получены в результате суммирования, агрегации и усреднения фактических данных. В зависимости от задач анализа такие данные могут быть либо детальными, либо итоговыми.
Консолидированные данные (Reconciled data) - это фактические данные, которые были очищены и представляют собой интегрированный источник данных для решения задач анализа. Основное требование к таким данным - их согласованность (consistency).

Понятие предметной области и хранилища данных

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

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

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

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

Для выделения предметных областей в ХД часто используется так называемая методика "правило SW1", а именно ответы на вопросы: когда (when), где (where), кто (who), что (what), почему (why) и как (how) – по отношению к видам деятельности организации (интересы бизнеса). Например, при ответе на вопрос "кто" интересы бизнеса могут охватывать следующие объекты: "покупатели", "сотрудники", "поставщики", "менеджеры", "партнеры по бизнесу" и т. д.

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

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

Далее рассмотрим метод моделирования "сущность-связь". Этот метод используется для представления предметной области в виде ее логической модели. Применение метода создает модель предметной области , не зависимую от реализации. Метод применяется как при моделировании предметных областей OLTP-систем, так и при моделировании предметных областей BI-систем. Знание этого метода помогает проектировщику ХД быстрее установить логические связи между моделями БД OLTP-систем масштаба организации и моделями ХД BI-систем.

Моделирование методом "сущность-связь"

Основные понятия модели "сущность-связь"

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

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

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

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

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

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

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

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

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

Каждый атрибут имеет домен (domain). Домен - это выражение, которое определяет значения, разрешенные для данного атрибута . Иными словами, домен - это область значений атрибута. Для каждого атрибута сущности должен быть определен домен . На уровне логического моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае аналитик должен дать описание домена . На последующих стадиях тип домена конкретизируется, смысл понятия домена в физической модели ХД уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели домен реализуется посредством механизма ограничения домена , а СУБД не понимает неопределенных доменов .

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

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

Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи – это отношение числа сущностей, участвующих в образовании связи . Например, "один к одному", "один ко многим", "многие ко многим". На уровне логической модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности - это характер участия сущности в связи . Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности , когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности . Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.

Отношения , связывающие сущность саму с собой, называются рефлексивными . Типичным примером рефлексивных отношений является определение структуры подчиненности в отношении "Сотрудники". Рефлексивные отношения чаще всего отражают иерархические отношения внутри структуры данных. Они порождают ряд проблем проектирования, о которых речь пойдет позже

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

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

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

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

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

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

Для этого необходимо предпринять следующие действия:

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

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

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

В основе ER-модели лежат следующие базовые понятия:

Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности. Например, у сущности Сотрудник может быть следующий набор атрибутов: Табельный номер, Фамилия, Имя, Отчество, Дата рождения, Количество детей, Наличие родственников за границей. Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называют ключевым. Для сущности Сотрудник ключевым будет атрибут Табельный номер, поскольку для всех сотрудников данного предприятия табельные номера будут различны. Экземпляром сущности Сотрудник будет описание конкретного сотрудника предприятия. Одно из общепринятых графических обозначений сущности — прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются, например, подчеркиванием или специальным шрифтом (рис. 7.1):

Рис. 7.1. Пример определения сущности в модели ER

Между сущностями могут быть установлены связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. Например, если у нас есть связь между сущностью «Студент» и сущностью «Преподаватель» и эта связь — руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством.студентов-дипломников. Поэтому это будет связь «один-ко-многим» (1:М), один со стороны «Преподаватель» и многие со стороны «Студент» (см. рис. 7.2).

Рис. 7.2. Пример отношения «один-ко-многим» при связывании сущностей «Студент» и «Преподаватель»

В разных нотациях мощность связи изображается по-разному. В нашем примере мы используем нотацию CASE системы POWER DESIGNER, здесь множественность изображается путем разделения линии связи на 3. Связь имеет общее имя «Дипломное проектирование» и имеет имена ролей со стороны обеих сущностей. Со стороны студента эта роль называется «Пишет диплом под руководством», со стороны преподавателя эта связь называется «Руководит». Графическая интерпретация связи позволяет сразу прочитать смысл взаимосвязи между сущностями, она наглядна и легко интерпретируема. Связи делятся на три типа по множественности: один-к-одному (1:1), од и и-ко-многим (1:М), многие-ко-многим (М:М). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

Связь 1: М означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. Связь «один-к-одному» (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь «многие-ко-мно-гим» (М:М) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Например, если мы рассмотрим связь типа «Изучает» между сущностями «Студент» и «Дисциплина», то это связь типа «многие-ко-многим» (М:М), потому что каждый студент может изучать несколько дисциплин, но и каждая дисциплина изучается множеством студентов.ч Такая связь изображена на рис. 7.3.

Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Например, между двумя сущностями «Студент» и «Преподаватель» можно установить две смысловые связи, одна — рассмотренная уже ранее «Дипломное проектирование», а вторая может быть условно названа «Лекции», и она определяет, лекции каких преподавателей слушает данный студент и каким студентам данный преподаватель читает лекции. Ясно, что это связь типа многие-ко-многим. Пример этих связей приведен на рис. 7.3.

Рис. 7.3. Пример моделирования связи «многие-ко-многим»

Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWER DESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что по крайней мере один экземпляр сущности участвует в этой связи.

Рассмотрим для этого ранее приведенный пример связи «Дипломное проектирование». На нашем рисунке эта связь интерпретируется как необязательная с двух сторон. Но ведь на самом деле каждый студент, который пишет диплом, должен иметь своего руководителя дипломного проектирования, но, с другой стороны, не каждый преподаватель должен вести дипломное проектирование. Поэтому в данной смысловой постановке изображение этой связи изменится и будет выглядеть таким, как представлено на рис. 7.4.

Рис. 7.4. Пример обязательной и необязательной связи между сущностями

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то«есть сущность может быть представлена в виде двух или более своих подтипов — сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности па подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный Перечень подтипов, то вводится специальный подтип, называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацпю на двух-трех уровнях.

Сущность, на основе которой строятся подтипы, называется супертипом. Любой экземпляр супертипа должен относиться к конкретному подтипу. Для графического изображения принципа категоризации или типизации сущности вводится специальный графический элемент, называемый узел-дискриминатор, в нотации POWER DESIGNER он изображается в виде полукруга, выпуклой стороной обращенного к суперсущности. Эта сторона соединяется направленной стрелкой с суперсущностью, а к диаметру этого круга стрелками подсоединяются подтипы данной сущности (см. рис. 7.5).

Рис. 7.5. Диаграмма подтипов сущности ТЕСТ

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

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

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

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

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

Между сущностями «Книги» и «Экземпляры» существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь «один-ко-многим». При этом если в библиотеке нет ни одного экземпляра дайной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная.

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

Кроме того, в сущности «Читатели» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: «Фамилия Имя Отчество», «Адрес читателя», «Телефон домашний» и «Телефон рабочий». Почему мы ввели два отдельных атрибута под телефоны? Потому что надо в разное время звонить по этим телефонам, чтобы застать читателя, поэтому администрации библиотеки будет важно знать, к какому типу относится данный телефон. В описании нашей предметной области существует ограничение на возраст наших читателей, поэтому в сущности «Читатели» надо ввести обязательный атрибут «Дата рождения», который позволит нам контролировать возраст наших читателей.

Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями «Читатели» и «Экземпляры». А почему не между сущностями «Читатели» и «Книги»? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями «Экземпляры» и «Книги», и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями «Читатели» и «Экземпляры» установлена связь «один-ко-многим», и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

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

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

Мифологическая модель предметной области «Библиотека» представлена на рис. 7.6.

Рис. 7.6. Мифологическая модель «Библиотека»

Мифологическая модель «Библиотека» разработана нами под те задачи, которые были перечислены ранее. В этих задачах мы не ставили условие хранения истории чтения книги, например, с целью поиска того, кто раньше держал книгу и мог нанести ей вред или забыть в ней случайно большую сумму денег. Если бы мы ставили перед собой задачу хранения и этой информации, то наша инфо-логическая модель была бы другой. Я оставлю эту задачу для вашего самостоятельного творчества.

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

Рис. 2.1.

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

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

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

Концы бинарной связи в ER-модели характеризуются:

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

Обозначения и примеры связей в первоначальной нотации, предложенной П. Ченом, приведены на рисунке 2.2

Рис. 2.2.

Для представления некоторых тонкостей наряду с нотацией П. Чена воспользуемся модифицированной нотацией Р. Баркера (рисунок 2.3). Будем изображать связь ненаправленной линией, соединяющей две разных сущности или сущность с собой. Обязательный конец связи будем представлять сплошной линией, а необязательный конец - штриховой линией. Неразветвленный конец линии обозначает степень 1. "Воронья лапка" означает степень "ко многим". Степень конца связи может быть уточнена. Так, указание 2..4 означает, что степень этого конца связи от 2 до 4 включительно.

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

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

пассажир может иметь один или несколько билетов; но может не иметь ни одного билета;
билет предназначен для одного пассажира.

Справа пример рекурсивной связи, которую следует читать так:

работник может иметь начальника, а может не иметь;
работник может подчиняться другому работнику, но может не подчиняться никому.

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

Рис. 2.3.

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

Задание уточнений степени конца связи определим на примерах:

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

Рис. 2.4. Пара "атрибут" - значение

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