Модель сущность связь компоненты достоинства. Метод моделирования "сущность-связь". Понятие предметной области и архитектура данных

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

Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент несомненно является базовой для разработки сложных программных систем, поэтому многие понятия вам могут показаться знакомыми, и если это действительно так, то тем проще вам будет освоить технологию проектирования баз данных , основанную на 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. Мифологическая модель «Библиотека»

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

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

Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (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

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

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

2.1 Семантические модели и когнитивный аспект

2.1.1 Семантические модели данных

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

Но если в базе хранятся только данные, то, как же хранятся смыслы? Прежде всего, смыслы -это тоже данные, связанные с теми данными, смысл которых они представляют.

Выделим следующие виды смыслов:

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

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

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

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

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

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

Детально семантика данных будет рассмотрена в лекции "Семантика баз данных" учебника.

Самая известная семантическая модель "сущность-связь" ("entity-rela-tionship" - ER) была предложена Питером Пин Шен Ченом (Peter Chen) в 1976 году.

2.1.2 Когнитивный аспект

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

2.1.3 Уровни модели

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

1. Информация об объектах и связях предметной области (ПО), излагаемая в терминах ПО (концептуальная модель).
2. Структурированная информация о ПО, излагаемая в терминах информационных систем (логическая модель).
3. Структуры данных, не зависящие от способа доступа, то есть не связанные со структурами данных, поиском, индексацией и т. д. (физическая модель).
4. Структуры данных, зависящие от способа доступа (модель аппаратного уровня).

Забегая вперед, заметим, что реляционная модель относится к уровням 2 и 3. Сетевая и иерархическая модели, в том виде как они существовали 20 лет назад, работают в основном на уровне 3 и 4. UML -это уровни 1, 2 и 3, но UML далеко выходит за рамки описания данных. Модель "сущность-связь" работает на уровнях 1 и 2.

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

Цель лекции

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

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

и научитесь:

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

Введение

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

• Метод моделирования "сущность-связь" (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 ). Слабые сущности – это сущности, которые не могут присутствовать в базе данных, пока не существует связанного с ней экземпляра другой сущности . Примером такой сущности является заказ, который не может существовать без клиента. Слабые сущности имеют обязательный класс принадлежности , и степень связи такой сущности не может равняться нулю. Связь "заказ-клиент" является обязательной.

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

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

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

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

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

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

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

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

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

Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом, русский перевод его статьи "Модель "сущность-связь" - шаг к единому представлению данных" опубликован в журнале "СУБД" N 3 за 1995 г.

Многоуровневые представления данных

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

Информация, относящаяся к сущностям и связям, которые существуют в нашем воображении; - структура информации – организация информации, в которой сущности и связи представляются данными. - структура данных, независимая от путей доступа, – структуры данных, которые не связаны со схемами поиска, индексации и т.д. - структура данных, зависимая от путей доступа.

Рисунок 1. Анализ моделей данных с использованием нескольких уровней логических представлений

Информация о сущностях и связях

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

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

Сущность и множество сущностей

Пусть e обозначает некоторую сущность, которая существует в нашем воображении. Каждая сущность относится к некоторому отличному от других множеству сущностей (entity set), такому как EMPLOYEE, PROJECT или DEPARTMENT. С каждым множеством сущностей связывается предикат, позволяющий проверить, принадлежит ли данная сущность данному множеству. Например, если мы знаем, что сущность относится к множеству сущностей EMPLOYEE, то мы также знаем, что эта сущность обладает свойствами, общими с другими сущностями из множества сущностей EMPLOYEE. В число этих свойств входит упомянутый выше предикат. Пусть Ei обозначает множество сущностей. Заметим, что множества сущностей не обязаны быть непересекающимися. Например, сущность, принадлежащая множеству сущностей MALE-PERSON (МУЖЧИНЫ), принадлежит также и множеству сущностей PERSON (ЛЮДИ). В этом случае MALE-PERSON является подмножеством PERSON.

Связь, роль и множество связей.

Рассмотрим ассоциации сущностей. Множество связей (relationship set) Ri – это математическое отношение между n сущностями, каждая из которых относится к некоторому множеству сущностей:

{ | e1 ∈ E1, e2 ∈ E2, ..., en ∈ En}, и каждый кортеж сущностей, , является связью (relationship). Заметим,что в этом определении Ei не обязаны быть различными наборами. Например, marriage (брак) – это связь между двумя сущностями из набора сущностей PERSON (ЧЕЛОВЕК).

Роль (role) сущности в связи – это функция, которую сущность выполняет в данной связи. Husband (муж) и wife (жена) – это роли. Упорядочивание сущностей в определении связи (заметим, что использовались квадратные скобки) может отсутствовать, если в связи явно указаны роли сущностей: (r1/e1, r2/e2 ,..., rn/en), где ri – это роль сущности ei в данной связи.

Атрибут, значение и множество значений.

Информацию об сущности или связи получают путем наблюдения или измерения и выражают множеством пар атрибут-значение. 3, red, Peter и Johnson – это значения. Значения классифицируются в различные множества значений (value sets), такие как FEET, COLOR, FIRST-NAME и LAST-NAME. С каждым множеством значений связывается предикат для проверки того, принадлежит ли значение этому множеству. Значение из некоторого множества значений может быть эквивалентно другому значению из другого множества значений. Например, 12 из множества значений INCH (ДЮЙМЫ) эквивалентно 1 в множестве значений FEET (ФУТЫ).

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

f: Ei or Ri → Vi or Vi1 × Vi2 × ... × Vin На рис. 2 показано несколько атрибутов, определенных на множестве сущностей PERSON. Атрибут AGE (ВОЗРАСТ) производит отображение в множество значений NO-OF-YEARS (ЧИСЛО-ЛЕТ). Атрибут может задавать отображение в декартово произведение множеств значений. Например, атрибут NAME (ПОЛНОЕ-ИМЯ) задает отображение в множества значений FIRST-NAME (ИМЯ) и LAST-NAME (ФАМИЛИЯ). Заметим, что несколько атрибутов могут задавать отображение одного и того же множества сущностей в одно и то же множество значений (или одну и ту же группу множеств значений). Например, атрибуты NAME (ПОЛНОЕ-ИМЯ) и ALTERNATIVE-NAME (ДРУГОЕ-ПОЛНОЕ-ИМЯ) задают отображение из множества сущностей EMPLOYEE в множества значений FIRST-NAME и LAST-NAME. Тем самым, атрибут и множество значений являются разными понятиями, хотя в некоторых случаях они могут иметь одно и то же имя (например, атрибут EMPLOYEE-NO (НОМЕР-СЛУЖАЩЕГО) задает отображение из EMPLOYEE (СЛУЖАЩИЕ) в множество значений EMPLOYEE-NO (НОМЕР-СЛУЖАЩЕГО)). Это различие не является явным в сетевой модели и во многих существующих системах управления данными. Заметим также, что атрибут определяется как функция. Следовательно, он отображает данную сущность в одно значение (или один кортеж значений в случае декартова произведения множеств значений).

Рис. 2. Атрибуты, определенные на множестве сущностей PERSON

Заметим, что связи также имеют атрибуты. Рассмотрим множество связей PROJECT-WORKER (ИСПОЛНИТЕЛЬ-ПРОЕКТА) (рис. 3). Атрибут PERCENTAGE-OF-TIME (ПРОЦЕНТ-ВРЕМЕНИ), представляющий долю времени, выделенную конкретному служащему на конкретный проект,– это атрибут, определенный на множестве связей PROJECT-WORKER. Он не является ни атрибутом сущности EMPLOYEE, ни атрибутом сущности PROJECT, так как его смысл зависит и от служащего, и от проекта. Понятие атрибута связи важно для понимания семантики данных и определения функциональных зависимостей между данными.

Рис. 3. Атрибуты, определенные на множестве связей PROJECT-WORKER

Концептуальная структура информации.

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

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

Рис. 4. Информация о сущностях из множества сущностей (табличная форма)

Рис. 5. Информация о связях из множества связей (табличная форма)

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

Заметим, что на рис. 4 и 2 (а также на рис. 5 и 3) представлены различные формы одной и той же информации. Форма таблицы используется для упрощения связывания с реляционной моделью.

Структура информации

Сущности, связи и значения на уровне 1 (см. рис. 2-5) являются концептуальными объектами, существующими в нашем воображении (т.е. мы находились в концептуальной сфере). На уровне 2 мы рассматриваем представления концептуальных объектов. Мы предполагаем, что существуют непосредственные представления значений. Далее мы опишем, как можно представить сущности и связи.

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

На рис. 2 значения атрибута EMPLOYEE-NO могут использоваться для идентификации сущностей в множестве сущностей EMPLOYEE, если у каждого служащего имеется уникальный номер служащего. Возможно, для идентификации сущностей в множестве сущностей понадобится более одного атрибута. Возможно также, что для идентификации сущностей будут использоваться несколько групп атрибутов. По существу, ключ сущности (entity key) – это группа атрибутов, такая, что отображение из множества сущностей в соответствующую группу множеств значений является взаимнооднозначным отображением. Если не удается найти такое отображение на доступных данных, или если желательна простота в идентификации объектов, то можно искусственно определить атрибут и множество значений, чтобы добиться наличия взаимнооднозначного отображения. В случае существования нескольких ключей обычно выбирается семантически значимый ключ в качестве первичного ключа сущности (entity primary key – PK).

Рис. 6. Представление сущностей значениями (номерами служащих)

Рис. 6 получен слиянием множества сущностей EMPLOYEE с множеством значений EMPLOYEE-NO с рис. 2. Обратим внимание на некоторые семантические следствия рис. 6. Каждое значение в множестве значений EMPLOYEE-NO представляет сущность (служащего). Атрибуты задают отображение из множества значений EMPLOYEE-NO в другие множества значений. Заметим также, что атрибут EMPLOYEE-NO задает отображение множества значений EMPLOYEE-NO в само его.

Отношения сущность/связь.

Информация о сущностях в множестве сущностей теперь может быть организована в форме, показанной на рис. 7. Заметим, что рис. 7 похож на рис. 4, за исключением того, что сущности представлены значениями их первичных ключей. Вся таблица на рис. 7 представляет отношение сущностей (entity relation), а каждая строка представляет кортеж сущностей (entity tuple).

В некоторых случаях сущности в множестве сущностей нельзя уникально идентифицировать значениями их собственных атрибутов; следовательно, для их идентификации мы должны использовать связь(и). Например, рассмотрим сущности служащих-подчиненных (dependent) и служащих-начальников (supporter): подчиненные идентифицируются своими именами и значениями основного ключа служащих-начальников (т.е. своими связями с этими служащими). Заметим, что на рис. 9 EMPLOYEE-NO не является атрибутом сущностей в множестве DEPENDENT, а представляет собой первичный ключ служащих, которые имеют подчиненных. Каждая строка значений на рис. 9 – это кортеж сущностей с EMPLOYEE-NO и NAME в качестве первичных ключей. Вся таблица является отношением сущностей.

Теоретически, для идентификации сущностей может использоваться любой вид связи. Для простоты мы ограничимся только одним видом связи: бинарными связями с отображением 1:n, в которых существование n сущностей на одной стороне связи зависит от существования одной сущности на другой стороне связи. Например, один служащий может иметь n (n = 0, 1, 2,...) подчиненных, и существование подчиненных зависит от существования соответствующего служащего-начальника.

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

Следовательно, мы имеем две формы отношений сущностей. Если связи используются для идентификации сущностей, мы будем называть это слабым отношением сущностей (weak entity relation) (рис. 9). Если связи не используются для идентификации сущностей, мы будем называть это регулярным отношением сущностей (regular entity relation) (рис. 8). Если некоторые сущности в связи идентифицируются другими связями, мы будем называть это слабым отношением связей (weak relationship relation). Например, любые связи между сущностями DEPENDENT и другими сущностями приведут к образованию слабых отношений связи, так как сущность DEPENDENT идентифицируется своим именем и связью с сущностью EMPLOYEE. Проведение различия между регулярными и слабыми отношениями сущностей и связей будет полезно для поддержки целостности данных.