Цель работы

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

Основные понятия модели «Сущность-связь». 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. Результаты работы по всем этапам отобразите в отчете.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

За последние несколько лет наблюдается тенденция к усложнению структур данных. Простые виды информации, представимой в форме чисел и текстовых строк, не утратив своей значимости, дополняются сегодня многочисленными мультимедийными документами, графическими образами, хронологическими рядами, процедурными, или активными, данными и мириадами прочих сложных информационных форм. В связи с этим появилась целая плеяда СУБД, поддерживающих новые коллекции данных и способных реализовать преимущества современных аппаратных средств. Одним из таких СУБД является MS Access 2003 (2007), входящая в пакет программ Microsoft Office, и являющаяся одной из популярных реляционных СУБД для локальных компьютеров.

Популярность СУБД Microsoft Access обусловлена следующими причинами:

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

полностью русифицирована;

возможность использования OLE технологии;

поддержка WWW-идеологии;

визуальная технология позволяет постоянно видеть результаты своих действий и корректировать их, кроме того, работа с конструктором форм может существенно облегчить дальнейшее изучение таких систем программирования, как Visual Basic или Delphi;

широко и наглядно представлена справочная система;

наличие большого набора "мастеров" по разработке объектов.

В настоящее время в различных крупных организациях широко применяются автоматизированные информационные системы (АИС).

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

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

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

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

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

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

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

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

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

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

Один к одному

Один ко многим

Много ко многим

Рис. 1 – Типы связей

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

Связь типа «один ко многим» означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») - дочерней.

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

Каждая связь может иметь одну из двух модальностей связи:

Может

Должен

Рис. 2 – Модальность связи

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

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

Преобразование ER-модели в реляционную модель данных

Рассмотрим преобразование ER-модели в реляционную модель данных на абстрактном примере. Предположим, что дана ER-модель. Необходимо получить набор таблиц (отношений) вида Таблица (Ключ, Атрибут1, Атрибут2, …, АтрибутN). Ключ может быть составным. Удобно имена атрибутов в масштабе ER-модели сделать уникальными, тогда при построении реляционной модели их (почти никогда) не придется переименовывать.

Преобразование множеств сущностей (для краткости - сущностей)

1. Преобразование обычной сущности

Рис. 3 – Преобразование обычной сущности

Обычная сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности: Сущность (Ключ, Атрибут1, Атрибут2)

1. Преобразование слабой сущности

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

Ключевые поля всех родительских таблиц войдут в ключ дочерней таблицы. Для дочерней таблицы они будут называться внешним ключом: Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2).

Ключ 1

Атрибут 1

Атрибут 2

Сущность 1

Сущность 2

Ключ 2

Рис. 4 – Преобразование слабой сущности

1. Преобразование подтипов сущностей

1 способ. Создается одна таблица, в которую помещают все атрибуты. Для того, чтобы указать, к какому подтипу относится объект, приходится вводить дополнительное поле-признак: Сущность1(Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак).

Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 - атрибуты 2 и 3 останутся пустыми.

2 способ. Создается отдельная таблица для каждого подтипа. В нее включаются все атрибуты этого подтипа и все атрибуты надтипа:

Подтип1(Ключ, Атрибут1, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут1, Атрибут4, Атрибут5)

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

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

Сущность1(Ключ, Атрибут1)

Подтип1(Ключ, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут4, Атрибут5)

Недостатком этого подхода является то, что информация о каждом объекте теперь раскидана по двум таблицам.

Рис. 5 – Преобразование подтипов сущностей

Преобразование связей

1. Связь М:М

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

Рис. 6 – Связь М:М

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

Сущность1Сущность2(Ключ1, Ключ2, Атрибут1).

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

1. Связь 1:М

Рис. 7 – Связь 1:М

1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ второй сущности.

Сущность1Сущность2(Ключ1, Ключ2).

2 способ. Новая таблица не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в ключ дочерней сущности они входить не будут). Ключевые поля родительской сущности представляют собой внешний ключ (foreign key) для дочерней сущности.

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

Таблица дочерней сущности: Сущность2(Ключ2, Атрибут1, Ключ1).

1. Связь 1:1

Рис. 8 – Связь 1:1

1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ любой сущности.

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

Сущность1Сущность2(Ключ1, Ключ2) или Сущность1Сущность2(Ключ1, Ключ2).

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

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

Таблица дочерней сущности: Сущность1(Ключ1, Атрибут1, Ключ2),

или Сущность2(Ключ2, Атрибут2, Ключ1).

3 способ. Две таблицы для сущностей, связанных 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь "ровно к одному", то ключ этой сущности можно считать ключом объединенной таблицы.

Таблицы: Сущность1(Ключ1, Атрибут1) и Сущность2(Ключ2, Атрибут2) заменяются на

Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2)

или, возможно, Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2),

или Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2).

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

Рассмотрим связь 1:M, способ 2. Переименован внешний ключ.

Рис. 9 – Связь 1:М, переименован внешний ключ

Сущность1(Ключ1, Атрибут1, ЕщеОдинКлюч1).

Для связей с арностью более 2 обычно применяется тот же способ, что и для бинарной связи M:M - создается новая таблица, содержащая ключевые поля всех связанных таблиц: Сущность1Сущность2Сущность3(Ключ1, Ключ2, Ключ3).

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

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

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

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

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

В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

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

Теория нормализации

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

Первая нормальная форма

Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности.

Будем называть исходное отношение основным, а значение неатомарного атрибута – подчинённым.

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

Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.

Код сотрудника

ФИО

Должность

Проекты

Иванов Иван Иванович

Программист

ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011
ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011
ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011

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

Рассмотрим алгоритм нормализации отношения до 1НФ.

Создать новое отношение, схема которого будет получена путём слияния основной и подчинённой схем исходного отношения в одну.

Для каждого кортежа исходного отношения включить в новое столько строк, сколько кортежей содержится в подчинённом отношении этого кортежа.

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

Применим этот алгоритм к приведённому выше отношению. Схема нового отношения будет состоять из 6 атрибутов: «Код сотрудника», «ФИО», «Должность», «Код проекта», «Название», «Дата сдачи». Для одного единственного кортежа заданного отношения, добавим в новое три строки, по одной для каждого проекта (по количеству кортежей в подчинённом отношении). Теперь можно заполнить значения разделенных атрибутов кортежами из подчинённого отношения. Затем перенесем в каждую из этих строк значения атомарных атрибутов: «Код сотрудника», «ФИО», «Должность» (все три строки будут содержать одинаковые значения этих атрибутов).

Результат будет выглядеть так:

Код сотрудника

ФИО

Должность

Код проекта

Название

Дата сдачи

Иванов Иван Иванович

Программист

123

Система управления паровым котлом

30.09.2011

Иванов Иван Иванович

Программист

231

ПС для контроля и оповещения о превышениях ПДК различных газов в помещении

30.11.2011

Иванов Иван Иванович

Программист

321

Модуль распознавания лиц для защитной системы

01.12.2011

Вторая нормальная форма

Отношение, находящееся в 1НФ, также может обладать избыточностью. Для её устранения предназначена вторая нормальная форма. Но прежде чем приступить к её описанию, сначала следует выявить недостатки первой.

Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.

Код поставщика

Город

Статус города

Код товара

Количество

Москва

300

Москва

400

Москва

100

Ярославль

200

Ставрополь

300

Ставрополь

400

Псков

100

Заранее известно, что в этом отношении содержатся следующие функциональные зависимости:

{ {Код поставщика, Код товара} -> { Количество},

{Код поставщика} -> {Город},

{Код поставщика} -> {Статус},

{Город} -> {Статус} }

Первичный ключ в отношении: {Код поставщика, Код товара}.

Очевидно, что отношение обладает избыточностью: оно описывает две сущности – поставку и поставщика. В связи с этим возникают следующие аномалии:

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

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

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

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

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

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

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

В итоге будут получены два отношения:

Код поставщика

Код товара

Количество

300

400

100

200

300

400

100

Первому отношению теперь соответствуют следующие функциональные зависимости: {Код поставщика, Код товара} -> {Количество}

Код поставщика

Город

Статус города

Москва

Ярославль

Ставрополь

Псков

Второму отношению соответствуют:

{ {Код поставщика} -> {Город},

{Код поставщика} -> {Статус},

{Город} -> {Статус} }

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

Определение второй нормальной формы: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.

Семантическое моделирование

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

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

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

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

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

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

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

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

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

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

Расширенная ER-модель (EER-модель)

Понятий обычной ER-модели достаточно для представления большинства схем баз данных, например, для большинства коммерческих систем БД. Однако такие области, как системы автоматизированного проектирования, системы автоматизированной подготовки производства и др. предъявляют более сложные требования к БД. Для их семантического моделирования ER-модель была дополнена новыми понятиями и трансформирована в EER-модель (Enhanced ER – model – расширенная модель «сущность–связь»). Такая модель содержит все элементы ER – модели плюс дополнительные понятия, а именно понятия генерализации, специализации, и агрегирования.

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

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

Агрегирование – это процесс объединения нескольких независимых сущностей (типов) в агрегированный (комплексный) тип.

Концептуальные ER-модели

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

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

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

Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.

С элементом данных неразрывно связано понятие «тип данных», который может принимать соответствующее поле. В разных СУБД могут использоваться разные типы данных, наиболее распространенными из которых, используемые во многих СУБД, являются следующие: числовой (numeric), символьный (char), дата (date) и т.д.

Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).

Экземпляр записи – запись с конкретными значениями полей.

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

Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.

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

Понятие «группа» является обобщающим понятием «файл» и «запись».

Группа – это поименованная совокупность элементов данных и других групп.

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

Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом.

Для представления группового отношения используется две формы:

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

По типу графов различают:

иерархическую модель (граф без циклов – дерево);

сетевую модель (ориентированный граф общего вида).

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

Примеры ER-моделей

Пример 1

ER-модель: ЖЭК

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

Рис. 10 – Пример ER-модели ЖЭКа

Пример 2

ER -модель конторы «Рога и копыта»

Описание задачи: Контора «Рога и копыта» занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг.

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

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

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

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

Рис. 11 – Пример ER-модели конторы «Рога и копыта»

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

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

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

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

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

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

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

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

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

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

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

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

Покупатель - явный кандидат на сущность.

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

Товар - явный кандидат на сущность

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

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

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

Рис. 12 – Первый вариант ER-диаграммы

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

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

Рис. 12 – Второй вариант ER-диаграммы

Теперь необходимо задуматься об атрибутах сущностей. Выясняется следующее:

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

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

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

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

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

Юридическое лицо – термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

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

Адрес – явная характеристика покупателя.

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

Наименование товара – явная характеристика товара.

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

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

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

Дата накладной – явная характеристика накладной.

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

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

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

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

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

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

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

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

Теперь можно внести все это в диаграмму:

Рис. 13 – Третий (итоговый) вариант ER-диаграммы

Список литературы:

Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В.Б. Уткин, К.В. Балдин. – М.: Издательский центр «Академия», 2004. – 288 с.

Разработка и эксплуатация автоматизированных информационных систем: учеб. пособие / Под ред. проф. Л.Г. Гагариной. – М.: ИД «ФОРУМ»: ИНФРА-М, 2007. – 384 с.: ил. – (Профессиональное образование).

Дейт К. Введение в системы баз данных. – М.: Диалектика, 2000.

Першиков В. И., Савинков В. М. Толковый словарь по информатике. – М.: Финансы и статистика, 2001.

Райордан Р. Основы реляционных баз данных. – М.: Русская редакция, 2001.

Саукап Р. Проектирование реляционных систем баз данных. – М.: Русская редакция, 2006.

Системы управления базами данных и знаниями / Под ред. А. Н. Наумова. – М.: Финансы и статистика, 2005.

Спортак М., Паппас Ф. Компьютерные сети и сетевые технологии. – Киев: ООО «ТИД «ДС», 2002.

Уткин В. Б. Основы автоматизации профессиональной деятельности. – М.: РДЛ, 2001.

Уткин В. Б., Сазанович А.Н., Мдичарадзе В. Г. Информатика. – М.: РДЛ, 2007.

MegaPlus: Электроника, компьютеры, связь.2010. – № 5.

0

(Лекция 8)

Разработка концептуального уровня БД

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

Инфологическая модель предметной области

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

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

Методологии построения ER-диаграмм

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

1 Методология Питера Чена. В 1976 году Питером Ченом была предложена семантическая модель "сущность-связь" - ER-модель, которая в настоящее время стала самой распространенной.

Соглашения, используемые при изображении диаграммы:

Классы объектов отображаются прямоугольником, свойства эллипсами, связи ромбами;

Уникальный идентификатор (первичный ключ) отображается в виде эллипса, обведенного двойной линией;

Мощность связи «один» отображается линией, «много» - линией со стрелкой.

Особенности этой методологии:

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

Связь может иметь собственные атрибуты;

Нет возможности отображения взаимоисключающих связей и непереносимости связей;

Взаимоисключающие связи неявно реализуются в виде супертипов и подтипов;

Нельзя выразить опциональность атрибутов и связей.

На рисунке 6 приведен пример фрагмента ER-диаграммы в методологии Питера Чена.

Рисунок 6 - Пример фрагмента ER-диаграммы в методологии Питера Чена

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

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

2 Методология IDEF1. Используется в CASE-средствах ERwin, Design/IDEF. В методологии используются следующие соглашения:

Каждому классу объектов присваивается уникальное имя и номер;

Обязательная связь отображается сплошной линией, необязательная -пунктирной;

Мощность связи "один" отображается линией, "много" - точкой;

Связь может дополнительно определяться с помощью указания мощности (типа) связи. Мощность может принимать следующие значения: N - ноль, один или более (принимается по умолчанию); Z - ноль или один, P - один или более.

Свойства класса объектов отображаются в виде списка имен внутри блока, отображающего класс объектов;

Атрибуты первичного ключа изображаются вверху и отделяются от других.

Пример представления ER-диаграммы в методологии IDEF1 приведен на рисунке 7.

Рисунок 7 - Пример представления ER-диаграммы в методологии IDEF1.

На рисунке 7 отображена та же ситуация в предметной области, что и на рисунке 6.

3 Методология Ричарда Баркера. Используемые в методологии элементы: класс объектов, свойство класса объектов, уникальные идентификаторы, опциональность свойств, связи, мощность (тип), опциональность и переносимость связей, уникальность объекта из связи, супертипы, подтипы, арки.

Используются следующие соглашения:

Класс объектов отображается в виде четырехугольника с закругленными углами. Имя класса объектов указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;

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

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

Опциональность свойств помечается: обязательное свойство - звездочкой (*), необязательное - кружочком (о);

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

Обязательная связь помечается сплошной линией, необязательная -пунктирной;

Тип (мощность) связи «один» помечается линией, «много» - «вороньей лапой».

Более сложные элементы, используемые в ER-диаграмме, построенной по методологии Ричарда Баркера, рассмотрим далее в примерах.

Шаблоны моделирования

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

1 Моделирование семейного положения. Например, ситуацию предметной области, описанную следующими предложениями: «каждое ФИЗИЧЕСКОЕ ЛИЦО (мужского пола) может являться супругом другого ФИЗИЧЕСКОГО ЛИЦА (женского пола)» и, с обратной стороны, «каждое ФИЗИЧЕСКОЕ ЛИЦО (женского пола) может являться супругой другого ФИЗИЧЕСКОГО ЛИЦА (мужского пола», можно смоделировать, используя рекурсивную связь. Это связь между объектами одного класса объектов. Такая связь может обладать всеми свойствами, присущими любой другой связи. Пример приведен на рисунке 8. На рисунке 8 изображена рекурсивная связь, имеющая с обеих сторон одинаковый тип («один») и опциональность «необязательная». В методологии Ричарда Баркера на ER- диаграмме можно отображать и названия связей.

Рисунок - Пример рекурсивной связи - «необязательное свиное ухо»

2 Моделирование иерархии данных. Иерархия данных наблюдается, если в модели предметной области присутствует:

Произвольное число иерархий классов объектов;

Одинаковые свойства у классов объектов, входящих в иерархию;

Связи между такими классами объектов одинаковые.

На рисунке 9 представлен фрагмент ER-диаграммы, выполненный по методологии Ричарда Баркера и отображающий пример иерархии данных.

Рисунок - Пример иерархии данных

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

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

Замена иерархии данных рекурсивной связью осуществляется по следующему алгоритму:

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

Классу объектов присваивается общее имя (в иерархии подчинения подразделений предприятия это может быть, например, класс объектов с именем «СТРУКТУРНАЯ ЕДИНИЦА ПРЕДПРИЯТИЯ»;

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

Как вывод, необходимо сделать следующие замечания:

Шаблон имеет один недостаток: классы объектов, находящиеся на всех уровнях иерархии должны иметь одинаковые свойства;

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

Если при преобразовании модели предметной области происходит слияние частей диаграммы в одну, то необходимо найти в предметной области класс объектов «ТИП», который позволит отобразить уникальность каждой части

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

Рисунок - Пример использования шаблон для моделирования иерархии данных.

3 Разрыв связей M:M. Наличие связи M:M в ER - диаграмме допустимо, но необходимо помнить, что это не адекватное отображение предметной области, есть предметная область не дообследована. Необходимо найти класс объектов (сущность), который разорвет такую связь. Как правило, это какой-либо документ, или позиция документа. Например, связь «многие ко многим» между классами объектов «ПОСТАВЩИК» и «ТОВАР» («каждый ПОСТАВЩИК может поставлять много ТОВАРОВ» и «каждый ТОВАР может поставляться разными ПОСТАВЩИКАМИ») может быть разорвана с помощью таких классов объектов, как «ПОЗИЦИЯ НАКЛАДНОЙ», «ПОЗИЦИЯ ПРАЙС - ЛИСТА», «ПОЗИЦИЯ ДОГОВОРА» и другие. На рисунке 11 приведен пример разрыва связи М:М. В роли поставщика в примере выступает юридическое лицо.

Рисунок - Разрыв связи М:М

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

Разрыв рекурсивной связи М:М. (Моделирование сетевой структуры)

Такая структура очень распространена в предметной области на первых этапах поектировнаия. Пример 1

Каждый КОМПОНЕНТ может состоять из нескольких КОМПОНЕНТОВ Каждый КОМПОНЕНТ может входить в один или несколько КОМПОНЕНТОВ

Для моделирования использована необязательная рекурсивная связь типа М:М.

Каждое ЮРИДИЧЕСКОЕ ЛИЦО может пользоваться многими ЮРИДИЧЕСКИМИ ЛИЦАМИ для осуществления перевозок

Каждое ЮРИДИЧЕСКОЕ ЛИЦО может оказывать много услуг ЮРИДИЧЕСКИМ ЛИЦАМ по осуществлению перевозок.

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

Каждое ПРАВИЛО СБОРКИ применяется к одному

КОМПОНЕНТ для сборки

Каждое ПРАВИЛО СБОРКИ применяется к одному КОМПОНЕНТ, входящему в сборку другого

КОМПОНЕНТ.

Каждый КОМПОНЕНТ может включать много ПРАВИЛО СБОРКИ для входящих в него компонентов.

Каждый Компонент может входить во много

ПРАВИЛО СБОРКИ.

Пример 2

Каждая ПЕРЕВОЗКА должна осуществляться ЮРИДИЧЕСКИМ ЛИЦОМ

Каждая ПЕРЕВОЗКА должна осуществляться для ЮРИДИЧЕСКОГО ЛИЦА Каждое ЮРИДИЧЕСКОЕ ЛИЦО может осуществлять много ПЕРЕВОЗОК Каждое ЮРИДИЧЕСКОЕ ЛИЦО может участвовать во многих ПЕРЕВОЗКАХ как клиент.

Параллельные связи м.б. разной опциональности и типа.

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

Иерархии.

4 Моделирование ролей. Под ролями человека или организации в предметной области понимаются должности, обязанности, прозвища. В разных классах объектов, представляющих роли объекты могут перекрывать, дублировать друг друга. Например, класс объектов «ВРАЧ» и класс объектов «ПАЦИЕНТ» отображают разные роли человека - один лечит, другой лечится. Но в случае, если врач становится пациентом в той же предметной области, то информация о нем должна быть отображена в классе объектов «ПАЦИЕНТ», два объекта в двух классах объектов будут информационно дублировать, перекрывать друг друга. Роли должны моделироваться с помощью связей, необходимо чтобы объект одного и того же класса объектов мог выступать в нескольких ролях.

Пример неправильного и правильного моделирования ролей приведен на рисунках.

Рисунок - Неправильное моделирование ролей

Рисунок - Правильное моделирование ролей

На рисунке с неправильным моделированием ролей классы объектов «ПОСТАВЩИК» и «ПОТРЕБИТЕЛЬ» выделены отдельно. При возникновении ситуации, что какое-то юридическое лицо станет выступать как в роли поставщика, так и в роли потребителя, модель будет неадекватно отображать предметную область - информация будет продублирована. Правильным моделированием ситуации будет выделение одного класса объектов «ЮРИДИЧЕСКОЕ ЛИЦО», а роли «поставщик» и «потребитель» отобразить в виде соответствующих связей (рисунок с правильным моделированием ролей).

Примеры предметных областей, где необходимо моделировать роли, приведены в таблице 9.

Таблица 9 - Примеры моделирования ролей.

Предметная область	Неправильное моделирование	Правильное моделирование
Купля-продажа, поставка товара	Классы объектов: ПОКУПАТЕЛЬ, ПРОДАВЕЦ, ПОСТАВЩИК	Классы объектов: ЮРИДИЧЕСКОЕ ЛИЦО или ФИЗИЧЕСКОЕ ЛИЦО. Связи (роли): покупает, продает, поставляет
Образовательное учреждение, обучение	Классы объектов: АБИТУРИЕНТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, АСПИРАНТ	Классы объектов: ФИЗИЧЕСКОЕ ЛИЦО, РАБОТА ФИЗИЧЕСКОГО ЛИЦА, ОБУЧЕНИЕ ФИЗИЧЕСКОГО ЛИЦА, ТИП ОБУЧЕНИЯ ФИЗИЧЕСКОГО ЛИЦА, ТИП ПЕРЕМЕЩЕНИЯ ФИЗИЧЕСКОГО ЛИЦА. Связи (роли): сдает документы, работает, обучается.
Документооборот	Классы объектов: ВХОДЯЩИЙ ДОКУМЕНТ, ИСХОДЯЩИЙ ДОКУМЕНТ, ПРИКАЗ, РАСПОРЯЖЕНИЕ	Классы объектов: ДОКУМЕНТ, ПОЗИЦИЯ ДОКУМЕНТА, ТИП ДОКУМЕНТА, ТИП ПЕРЕМЕЩЕНИЯ ДОКУМЕНТА. Связи (роли): относится (к типу)

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

- «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся начальником отдела кадров, о чем есть соответствующая информация в классе объектов ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», начальник отдела кадров может подписывать много приказов»;

Рисунок - Пример моделирования ролей

- «каждый ПРИКАЗ О ПЕРЕМЕЩЕНИИ должен быть подписан одним сотрудником, являющимся руководителем предприятия, о чем есть соответствующая информация в классе объектов «ПОЗИЦИЯ ПРИКАЗА О ПЕРЕМЕЩЕНИИ», руководитель предприятия может подписывать много приказов».

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

Скачать лекцию: У вас нет доступа к скачиванию файлов с нашего сервера.

ER-диаграмма

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

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

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

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

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

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

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

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

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

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

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

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

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