Цель работы

Ознакомление с методами и алгоритмом создания модели «Сущность-связь».

Основные понятия модели «Сущность-связь». ER-модели.

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

Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД, которая слабо отражается в сетевых, иерархических моделях данных.

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

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

Рассмотрим базовые понятия, лежащие в основе ER-модели.

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

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

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

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

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

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

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

Пример создания ER-модели

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

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

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

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

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

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

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

ER-модель предметной области «Библиотека» представлена на рис. 10.4.

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

Нормализация ER-диаграмм

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

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

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

Правила преобразования ER-модели в реляционную БД

Рассмотрим правила преобразования ER-модели в реляционную БД.

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

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

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

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

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

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

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

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

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

Алгоритм приведения семантической модели к 3НФ

Алгоритм приведения семантической модели к 3-й нормальной форме может быть следующим:

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

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

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

Используя рассмотренные положения, нормализуем ER-схему. Результат нормализации приведен на рис. 5. При нормализации схемы в нее введено отношение «Связи Книги-каталог», содержащее атрибуты «ISBN» и «Код области знаний», служащие для реализации связи М:М «Книги – систематический каталог», а в отношение «Экземпляры» для его связи с отношениями «Книги» и «Читатели» введены атрибуты «№ читательского билета» и «ISBN». Стрелки указывают направление связей.

Можно показать, что схема рис. 10.5 удовлетворяет требованиям 3-й нормальной формы.

Порядок выполнения работы

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

Пример. Предметная область ИС: Отдел кадров.

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

Фамилия, имя, отчество, домашний адрес, телефон, дата рождения, должность, дата зачисления, стаж работы, образование;

фамилия, имя, отчество, и даты рождения членов семьи каждого сотрудника;

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

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

3. Используя рассмотренную выше методику нормализации ER-модели, приведите разработанную ER-модель к 3НФ.

4. Результаты работы по всем этапам отобразите в отчете.

What is ER Modeling?

Entity Relationship Modeling (ER Modeling) is a graphical approach to database design. It uses Entity/Relationship to represent real world objects.

An Entity is a thing or object in real world that is distinguishable from surrounding environment. For example each employee of an organization is a separate entity. Following are some of major characteristics of entities.

• An entity has a set of properties.
• Entity properties can have values.

In this tutorial, you will learn-

Let"s consider our first example again. An employee of an organization is an entity. If "Peter" is a programmer (an employee ) at Microsoft, he can have attributes (properties) like name, age, weight, height, etc. It is obvious that those do hold values relevant to him.

Each attribute can have Values . In most cases single attribute have one value. But it is possible for attributes have multiple values also. For example Peter"s age has a single value. But his "phone numbers" property can have multiple values.

Entities can have relationships with each other. Let"s consider a simplest example. Assume that each Microsoft Programmer is given a Computer. It is clear that that Peter"s Computer is also an entity. Peter is using that computer and the same computer is used by Peter. In other words there is a mutual relationship among Peter and his computer.

In Entity Relationship Modeling, we model entities, their attributes and relationships among entities.

Enhanced Entity Relationship (EER) Model

Enhanced Entity Relationship (EER) Model is a high level data model which provides extensions to original Entity Relationship (ER) model. EER Models supports more details design. EER Modeling emerged as a solution for modeling highly complex databases.

EER uses UML notation. UML is the acronym for Unified Modeling Language; it is a general purpose modeling language used when designing object oriented systems. Entities are represented as class diagrams. Relationships are represented as associations between entities. The diagram shown below illustrates an ER diagram using the UML notation.

Why use ER Model?

Now you may think why use ER modeling when we can simply create the database and all of its objects without ER modeling? One of the challenges faced when designing database is the fact that designers, developers and end-users tend to view data and its usage differently. If this situation is left unchecked, we can end up producing a database system that does not meet the requirements of the users.

Communication tools understood by all stakeholders(technical as well non-technical users) are critical in producing database systems that meet the requirements of the users. ER models are examples of such tools.

ER diagrams also increase user productivity as they can be easily translated into relational tables.

Case Study: ER diagram for "MyFlix" Video Library

Let"s now work with the MyFlix Video Library database system to help understand the concept of ER diagrams. We will using this database for all hand-on in the remainder of this tutorials

MyFlix is a business entity that rents out movies to its members. MyFlix has been storing its records manually. The management now wants to move to a DBMS

Let"s look at the steps to develop EER diagram for this database-

1. Identify the entities and determine the relationships that exist among them.
2. Each entity, attribute and relationship, should have appropriate names that can be easily understood by the non-technical people as well.
3. Relationships should not be connected directly to eachother. Relationships should connect entities.
4. Each attribute in a given entity should have a unique name.

Entities in the "MyFlix" library

The entities to be included in our ER diagram are;

• Members - this entity will hold member information.
• Movies - this entity will hold information regarding movies
• Categories - this entity will hold information that places movies into different categories such as "Drama", "Action", and "Epic" etc.
• Movie Rentals - this entity will hold information that about movies rented out to members.
• Payments - this entity will hold information about the payments made by members.

Defining the relationships among entities

Members and movies

The following holds true regarding the interactions between the two entities.

• A member can rent a more than movie in a given period.
• A movie can be rented by more than one member in a given period.

From the above scenario, we can see that the nature of the relationship is many-to-many. Relational databases do not support many-to-many relationships. We need to introduce a junction entity . This is the role that the MovieRentals entity plays. It has a one-to-many relationship with the members table and another one-to-many relationship with movies table.

Movies and categories entities

The following holds true about movies and categories.

• A movie can only belong to one category but a category can have more than one movie.

We can deduce from this that the nature of the relation between categories and movies table is one-to-many.

Members and payments entities

The following holds true about members and payments

• A member can only have one account but can make a number of payments.

We can deduce from this that the nature of the relationship between members and payments entities is one-to-many.

Now lets create EER model using MySQL Workbench

In the MySQL workbench , Click - "+" Button

Double click on Add Diagram button to open the workspace for ER diagrams.

Following window appears

Let"s look at the two objects that we will work with.

The members" entity will have the following attributes

• Membership number
• Full names
• Gender
• Date of birth
• Physical address
• Postal address

Let"s now create the members table

1.Drag the table object from the tools panel

2.Drop it in the workspace area. An entity named table 1 appears

3.Double click on it. The properties window shown below appears

1. Change table 1 to Members
2. Edit the default idtable1 to membership_number
3. Click on the next line to add the next field
4. Do the same for all the attributes identified in members" entity.

Your properties window should now look like this.

Repeat the above steps for all the identified entities.

Your diagram workspace should now look like the one shown below.

Lets create relationship between Members and Movie Rentals

1. Select the place relationship using existing columns too
2. Click on membership_number in the Members table
3. Click on reference_number in the MovieRentals table

Repeat above steps for other relationships. Your ER diagram should now look like this -

Summary

• ER Diagrams play a very important role in the database designing process. They serve as a non-technical communication tool for technical and non-technical people.
• Entities represent real world things; they can be conceptual as a sales order or physical such as a customer.
• All entities must be given unique names.
• ER models also allow the database designers to identify and define the relations that exist among entities.

The entire ER Model is attached below. You can simple import it in MySQL Workbench

Связь « Один – к одному » Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.

Связь « Один – ко многим » Один – ко многим (или в обратную сторону Многие – к одному). Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.

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

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

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

Пример ER- модели: Контора « Рога и копыта » Описание задачи Контора « Рога и копыта » занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг. Сотрудник организации имеет ФИО, табельный номер, должность. Сотрудники распределены по нескольким отделам. Каждый отдел имеет номер, название и руководителя. Сотрудник не может руководить более чем одним отделом. Организация работает с предприятиями - клиентами. Каждое предприятие имеет название и адрес. С предприятием может быть заключено несколько договоров. Договор характеризуется уникальным номером, датой и типом. Каждый договор курирует некоторый сотрудник. По мере реализации клиенту товаров и услуг по договору с некоторой периодичностью выставляются счета. Счет характеризуется уникальным номером, датой выставления, сроком оплаты и суммой, а также списком реализованных товаров и услуг с указанием их количества. По неоплаченным счетам начисляются пени. Счет может быть оплачен в несколько приемов, каждый платеж характеризуется номером, датой и суммой. Номер платежа уникален в пределах его счета. Цены на товары и услуги могут изменяться со временем.
Пример ER- модели: « Музыканты » Описание задачи Необходимо разработать базу данных для хранения информации о музыкантах, сочинениях и концертах. Музыкант характеризуется именем, датой рождения и страной рождения. Сочинение включает информацию о названии, композиторе и дате первого исполнения. Музыкант может играть на разных инструментах с разной степенью квалификации. Из музыкантов - исполнителей формируются ансамбли. Каждый ансамбль, кроме своих участников, содержит информацию о названии, стране и руководителе. Наконец, исполнения произведений характеризуются датой, страной, городом исполнения, а также ансамблем, дирижером и собственно исполняемым произведением.
17 Еще примеры В учебнике « Базы данных » на сайте

[править]

Материал из Википедии - свободной энциклопедии

У этого термина существуют и другие значения, см. ER .

Модель сущность-связь (ER-модель) (англ. entity-relationship model , ERM) - модель данных, позволяющая описыватьконцептуальные схемы предметной области.

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

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

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

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

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen ) , американским профессором компьютерных наук в университете штата Луизиана .

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

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

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

Ниже изображена сущность АЭРОПОРТ с примерными объектами Шереметьево и Хитроу:

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

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

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

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

В изображенном ниже примере связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем "имеет" означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

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

Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

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

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

В начале 1980-х гг. были предложены новые подходы к мифологическому проектированию БД, в большей степени ориентированные на БД реляционного типа. Среди работавших в этом направлении исследователей можно назвать Р. Баркера (Richard Barker) и авторов нотации Information Engineering (сокр. IE) Дж. Мартина (James Martin) и К. Финкелыитейна (Clive Finkelstein).

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

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

Рис. 6.2.

а – нотация Баркера; 6 – нотация Мартина (IE)

Нужно отмстить, что из-за особенностей изображения связей нотации Баркера и Мартина в литературе иногда называют "crow"s foot notation" (дословно – "нотация вороньей лапки").

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

• клиент может разместить один, несколько или ни одного заказа;
• заказ может быть размещен одним и только одним клиентом.

Рис. 6.3.

В настоящее время также широкое распространение получила нотация, определенная стандартом IDEF1X (полное название на англ. – Integration Definition for Information Modeling), речь о которой пойдет в следующем параграфе.

Задача проектирования БД для современной информационной системы корпоративного уровня может быть достаточно трудоемкой и требовать совместной работы большой группы специалистов – аналитиков, разработчиков БД, разработчиков прикладного ПО, специалистов в предметной области, для которой разрабатывается БД. Для автоматизации этого процесса широко используются CASE-средства – программные средства, поддерживающие одну или несколько технологий проектирования БД (также есть средства проектирования ПО и т.д.). В качестве примера можно назвать программные продукты ERwin Data Modeler (разработчик – компания СА Technologies), ER/Studio (разработчик – Embarcadero Technologies), PowerDesigner (разработчик – компания Sybase, в настоящее время приобретенная SAP). Отчасти подобная функциональность реализована и в популярном офисном программном продукте Microsoft Visio.

ERwin и подобные ему CASE-средства позволяют решать как задачи прямого проектирования (англ. forward-engineering), т.е. получения структуры БД на основе построенной ER-диаграммы, так и обратного проектирования (англ. reverse-engineering), когда ER-диаграмма создается на основе анализа структуры существующей БД.

Далее рассмотрена методология проектирования и нотация (правила изображения) диаграмм IDEF1X, а приводимые примеры будут иллюстрироваться с использованием программного продукта ERwin Data Modeler v. 9 в версии Community Edition. Данная версия продукта свободно распространяется, ее можно получить через веб-сайт erwin.com. Наиболее существенным ограничением версии ERwin Community Edition является небольшое количество объектов в модели – не более 25, но для учебных целей это не является критичным. Для разработки БД со сложной структурой рекомендуется использовать другие версии продукта.

Наряду с нотацией IDEF1X, ERwin поддерживает нотацию 1Е, особенности современной версии которой описаны далее.