Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (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. Проведение различия между регулярными и слабыми отношениями сущностей и связей будет полезно для поддержки целостности данных.

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

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

Семантическую основу ER-модели составляют следующие предположения:

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

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

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

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

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

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

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

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

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

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

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

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

Сущность имеет имя, уникальное в пределах модели. Приэтом имя сущности - это имя типа, а не некоторого конкретного экземпляра.

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

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

Свойство может быть множественным или единичным - т. е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно. Например, сотрудник может иметь несколько специальностей, но единственное значение - «Табельный номер».

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

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

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

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

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

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

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

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

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

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

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

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

Отношение «часть - целое» используются для представления составных объектов. Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

Отношение «род - вид» - для представления обобщенных объектов . Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ - на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и в частности - «родо-видовые», обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование - объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав»: ПОДРАЗДЕЛЕНИЕсостоит из СОТРУДНИКОВ; «Поставка»: ПОСТАВЩИК поставляет ДЕТАЛИ.

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, ПРОЧИЕ.

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

Тип сущности, его подтипы, подтипы этих подтипов и т. д. образуют иерархию типов сущности, пример которой приведен на рис. 5,6.

Модель "Сущность - связь"

ФИО

Байрамов Александр Мавлеевич

Место работы

МБОУ Средняя школа №6 г. Вязьма Смоленской области

Должность

Предмет

информатика и ИКТ

Эта страничка описывает и иллюстрирует использование модели «Сущность-связь» (entity-relationship model), введенной Питером Ченом (Peter Chen) в 1976 г. В этой статье Чен заложил основу модели, которая с тех пор расширялась и модифицировалась самим Ченом и многими другими. Кроме того, модель «Сущность-связь» вошла в состав множества CASE-инструментов, которые также внесли свой вклад в ее эволюцию. На сегодняшний день не существует единого общепринятого стандарта для модели «Сущность-связь», зато есть набор общих конструкций, которые лежат в основе большинства вариантов этой модели. Описанию этих общих конструкций и демонстрации их применения и посвящена данная глава. Символы, применяемые для графического представления модели «Сущность-связь», весьма различны. Мы обсудим не только традиционные символы, но и символы языка UML (Unified Model Language, унифицированный язык моделирования) - средства проектирования, завоевывающего все большую популярность среди программистов ООП и включающего в себя модель «Сущность-связь».

Ключевыми элементами модели «Сущность-связь» являются:

сущности

атрибуты

идентификаторы

связи

Сущности

Сущность (entity) - это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Примерами сущностей могут служить СОТРУДНИК Мэри Доу, КЛИЕНТ 12345, ЗАКАЗ 1000, ПРОДАВЕЦ Джон Смит или ПРОДУКТ А4200. Сущности одного и того же типа группируются в классы сущностей (entity classes). Так, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК. В тексте книги классы сущностей обозначаются заглавными буквами.

Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей - это совокупность сущностей, и описывается он структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (entity instance) представляет конкретную сущность, такую как КЛИЕНТ 12345; он описывается значениями атрибутов данной сущности. Обычно класс сущностей содержит множество экземпляров сущности. Например, класс КЛИЕНТ содержит множество экземпляров - по одному на каждого клиента, для которого имеется запись в базе данных. Пример класса сущностей и двух экземпляров сущности показан на рис. 1.

Рис. 1. КЛИЕНТ: пример сущности

Атрибуты

У сущностей есть атрибуты (attributes), или, как их иногда называют, свойства (properties), которые описывают характеристики сущности. Примерами атрибутов могут служить ИмяСотрудника, ДатаНайма и КодКвалификации. В тексте этого сайта атрибуты обозначаются как прописными, так и строчными буквами. В модели «сущность-связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты.

Исходное определение модели «сущность-связь» включает в себя композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued attributes).

В качестве примера композитного атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером многозначного атрибута может служить атрибут ИмяДоверенногоЛица сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента.

Атрибут может быть одновременно и композитным, и многозначным - например композитный атрибут Телефон, состоящий из группы атрибутов {Код-Региона, МестныйНомер}, может быть многозначным, что позволит иметь в базе данных несколько телефонных номеров одного и того же лица. В большинстве реализаций модели «сущность-связь» однозначные композитные атрибуты игнорируются, и требуется, чтобы многозначные атрибуты (будь они составные или нет) преобразовывались в сущности, как будет показано ниже.

Идентификаторы

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

Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникалъным (nonunique).

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

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

Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers). Примерами могут служить совокупности вида (КодРегиона, МестныйНомер}, (НазваниеПроекта, НазваниеЗадачи} и (Имя, Фамилия, ДобавочныйНомерТелефона}.

Связи

Взаимоотношения сущностей выражаются связями (relationships). Модель «сущность-связь» включает в себя классы связей и экземпляры связей. Классы связей (relationship classes) - это взаимоотношения между классами сущностей, а экземпляры связи (relationship instances) - взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.

Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. 2, а связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей: ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ на рис. 2; б имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще бинарными связями (binary relationships).

Рис.2. Различные степени связей: а - связь степени 2; б - связь степени 3

Три типа бинарных связей

На рис. 3 показаны три типа бинарных связей. В связи 1:1 («один к одному») одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. На рис. 3, а связь СЛУЖЕБНЫЙ_АВТОМОБИЛЬ связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не закреплено более одного автомобиля, и ни один автомобиль не закреплен более чем за одним сотрудником.

Рис. 3. Три типа бинарных связей: а - бинарная связь 1:1; б - бинарная связь 1:N; в - бинарная связь N:М; г- представление связи с помощью разветвлений

На рис. 3, б изображен второй тип связи, 1:N («один к N» или «один ко многим»). В этой связи, которая называется ОБЩЕЖИТИЕ-ЖИЛЕЦ, единичный экземпляр сущности класса ОБЩЕЖИТИЕ связан со многими экземплярами сущности класса СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает много студентов, но каждый студент живет только в одном общежитии.

Позиция, в которой стоят 1 и N, имеет значение. Единица стоит на той стороне связи, где располагается ОБЩЕЖИТИЕ, а N стоит на той стороне связи, где располагается СТУДЕНТ. Если бы 1 и N располагались наоборот, и связь записывалась бы как N:l, получилось бы, что в общежитии живет один студент, причем каждый студент живет в нескольких общежитиях. Это, разумеется, не так.

На рис. 3, в показан третий тип бинарной связи, N:M (читается «N к М» или «многие ко многим»). Эта связь называется СТУДЕНТ-КЛУБ, и она связывает экземпляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.

Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи. Например, о связи, изображенной на рис. 3, б, говорят, что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями БАСКЕТБОЛЬНАЯ_КОМАНДА и ИГРОК может иметь кардинальность 1:5, что говорит нам о том, что в баскетбольной команде может быть не более пяти игроков.

Связи трех типов, представленных на рис. 3, называются иногда связями типа «ИМЕЕТ», или связями обладания (HAS-A relationships). Такой термин используется потому, что одна сущность имеет (has) связь с другой сущностью. Например: сотрудник имеет автомобиль, студент имеет общежитие, клуб имеет студентов.

Схемы, изображенные на рис. 3, называются диаграммами «Сущность-связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Такие диаграммы стандартизированы, но не слишком жестко. В соответствии с этим стандартом, классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба. Имя сущности указывается внутри прямоугольника, а имя связи указывается рядом с ромбом Хотя в некоторых ER-диаграммах имя связи указывается внутри ромба, получающаяся при этом диаграмма может выглядеть ужасно, поскольку ромбы приходится делать большого размера и вне масштаба, чтобы в них поместилось имя связи. Чтобы избежать этого, имена связей иногда пишут над ромбом. Когда имя помещается внутрь или поверх ромба, кардинальность связи изображается с помощью разветвлений на линиях, соединяющих сущность (или сущности) с множественной стороной связи. На рис. 3, г показаны связи ОБЩЕЖИТИЕ-ЖИЛЕЦ и СТУДЕНТ-КЛУБ с такими разветвлениями.

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

Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрированный на рис. 4.

Рис. 4. Связь с указанной минимальной кардинальностью

Этот способ заключается в следующем: чтобы показать, что сущность обязана участвовать в связи, на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Соответственно, рис. 4 показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана иметь связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное число, равное единице, и максимальное кардинальное число, равное «многим» сущностям СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное нулю, и максимальное кардинальное число, равное одному экземпляру сущности ОБЩЕЖИТИЕ.

Может существовать связь между сущностями одного и того же класса. Например, для сущностей класса СТУДЕНТ может быть определена связь СОСЕД_ПО_КОМНАТЕ. Такая связь показана на рис. 5, а, а на рис. 5, б изображены экземпляры сущностей, охваченных этой связью. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships).

Рис.5 Рекурсивная связь

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

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

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

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

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

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

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

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

Элементы модели «сущность-связь» Сущность - Класс сущностей - Экземпляр сущности Атрибуты - Композитные атрибуты - Многозначные атрибуты Идентификаторы - Уникальные/неуникальные - Композитные Связи - Классы связей - Экземпляры связей - Рекурсивные связи

Элементы модели «сущность-связь» Класс сущностей (entity classes) – это совокупность сущностей, описывается структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (аn instance) представляет конкретную сущность Обычно класс сущностей держит множество экземпляров сущности.

Элементы модели «сущность-связь» Атрибуты Атрибуты (свойства) – описывают характеристики сущности. Пример композитного атрибута: Адрес, состоящий из группы атрибутов {Улица, Город, Индекс}. Пример многозначного атрибута: атрибут Имя студента сущности ПРЕПОДАВАТЕЛЬ, который может содержать имена нескольких обучаемых им студентов.

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

Элементы модели «сущность-связь» Связи Взаимоотношения сущностей выражаются связями. Классы связей (relationship classes) это взаимоотношения между классами сущностей. Экземпляры связи (relationship instances) взаимоотношения между экземпля­рами сущностей Степень связи (relationship degree) число классов сущностей, участвующих в связи. Обозначение средствами в UML-диаграммах: Связь обозначается

Элементы модели «сущность-связь» Три типа бинарных связей Обозначение средствами в UML- диаграммах: Связь 1:1(«один к одному») обозначается Связь 1:N («один к N» или «один ко многим») – Связь N:M (читается «N к М» или «многие ко многим») – Связь обладания в обобщенном виде, когда не указан конкретный тип связи - Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи.

Диаграммы «сущность-связь» Схемы бинарных связей, изображенных выше, называются диаграммами «сущность-связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрирован ниже. Связь с указанной минимальной кардинальностью

Слабые сущности Слабые сущности (weak entity) - сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity). Идентификационно-зависимые сущности (ID-dependent entities) - это такие сущности, идентификаторы которых содержат идентификатор другой сущности.

27

Диаграммы «сущность-связь» в стиле UML Конструкции ООП, введенные языком UML Классы всех сущностей, которые должны храниться в базе данных, помечаются стереотипом «Persistent» (устойчивый) UML допускает назначение атрибутов классам сущностей UML использует объектно-ориентированную нотацию для обозначения видимости атрибутов и методов «+» - открытые «#» - защищенными «-» - закрытыми

Диаграммы «сущность-связь» в стиле UML Открытым (public) называется такой атрибут, который может читаться и изменяться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только для методов данного класса и его подклассов. А термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только для методов данного класса. В UML задаются ограничения и методы.