Моделирование информационного обеспечения ИС

ER-модель данных

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. Впервые была анонсирована в марте 1976 г. когда ученый Питер Пин - Шань Чен (Peter Pin-Shan Chen ) опубликовал работу "The entity-relationship model. Toward a Unified View of Data" в научном журнале "Transactions on Database Systems (TODS)". Он предложил простой и эффективный способ представления сущностей, атрибутов и связей между ними в виде наглядных диаграмм.

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

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером ( Hammer ) и Мак-Леоном ( McLeon ) в 1981 году, функциональную модель данных Шипмана ( Shipman ), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом ( Chen ) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта.

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

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

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

Понятия ER-модель и ER-диаграмма часто ошибочно не различают.

Для визуализации ER-моделей существуют различные графические нотации:

• Питера Чена
• Bachman notation
• EXPRESS
• IDEF1x
• Martin notation
• (min, max)-Notation
• UML

Инструменты для создания ER-моделей представлены ниже в таблице 2.3.

Таблица 2.3 - Инструменты для создания ER-моделей

В столбце "Лицензия" указан тип программного обеспечения - проприетарное (собственническое) или свободная лицензия, под которой распространяется данное ПО.

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

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

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

Основные понятия ER-модели.

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

Рис. 2.15

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

Рис. 2.16

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

Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M).

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

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

Пример этих связей приведен на рис. 2.17.

Рис. 2.17. Пример моделирования связи "многие-ко-многим"

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

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

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

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

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

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

• Домен (domain) - множество значений (область определения) атрибута (столбец таблицы в реляционной БД).

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

Существует разные способы записи ER-диаграмм, примеры которых приводятся ниже:

Стиль Information Engineering

Стиль Chen

Стиль Bachman

Стиль Martin

Для разработки ER-диаграмм можно воспользоваться программными продуктами:

MySQL Workbench; PostgreSQL Database Modeler; DbSchema; Valentina Studio.

На основе ER-модели разрабатывается реляционная БД, которая представляет собой множество отношений, а ее схема содержит следующие компоненты:

S = < A, R, Dom, Rel, V(s) > ,

где A – множество имен атрибутов,

R – множество имен отношений (сущностей),

Dom – вхождение атрибутов в домены,

Rel – вхождение атрибутов в отношения (описание структуры отношений),

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

Отношения (сущности) представляются в виде таблиц. При этом столбцы таблицы соответствуют атрибутам. Каждый атрибут определен на некотором домене. Доменом называют множество атомарных значений объекта автоматизации.

Рассмотрим формирование ER - модели в стиле Чена на конкретном примере.

Пример.

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

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

Ниже рассмотрены основные атрибуты каждой сущности.

1. Пользователь

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

2. Тип пользователя

• наименование типа пользователя (физическое, юридическое лицо).

3. VIP статус пользователя

• наименование VIP статуса пользователя.

4. Регион

• наименование региона;
• домен региона;
• администратор региона (Ф.И.О.);
• контактный телефон администратора;
• пропускная способность канала.

5. Реквизиты физического лица

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

6. Реквизиты юридического лица

• индивидуальный номер налогоплательщика ИНН;
• расчетный счет;
• банк клиента;
• код БИК;
• корреспондентский счет;
• код ОКПО;
• код ОКОНХ;

7. Тип организации

- наименование типа организации.

8. Тарифные планы коммутируемого доступа с учетом времени соединения

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

9. Группа услуг

• наименование группы услуг.

10. Учетные имена пользователей для доступа в сеть Интернет

• учетное имя для доступа в сеть Интернет;
• пароль для учетного имени;
• регион откуда будет производиться доступ;
• какому пользователю принадлежит учетное имя;
• дата выделения учетного имени;
• дата отказа от услуги;
• группа услуг тарифного плана.

11. Ограничения бюджета пользователя по телефонным номерам

• учетное имя для доступа в сеть Интернет;
• телефонный номер.

12. Ограничения бюджета по времени доступа и дням недели

• учетное имя для доступа в сеть Интернет;
• разрешить доступ начиная с времени:
• разрешить доступ заканчивая с времени:
• день недели, в который доступ разрешен.

13. Почтовые ящики пользователя

• учетная запись почты;
• пароль для учетной записи;
• адрес электронной почты;
• дата выделения почтового ящика;
• дата отказа от почтового ящика.

14. Группа входных файлов

• имя файла, в котором содержится статистика по видам услуг.

15. Коды услуг входных файлов

• имя файла, в котором содержится статистика по видам услуг;
• номер поля входного файла;
• код услуги входного файла.

16. Импортированные данные входных файлов

• учетное имя пользователя;
• код услуги входного файла;
• количество услуги;
• дата услуги.

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

• Пользователь заключает договор в регионе. Каждый пользователь заключает договор в определенном регионе, но в любом конкретном регионе может работать несколько пользователей. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Пользователь имеет VIP статус. Каждый пользователь имеет только один VIP статус, в то время как один и тот же VIP статус могут иметь и другие пользователи. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

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

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

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

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

• Учетные имена входят в группу услуг. Каждое учетное имя входит в какую-то группу услуг: коммутируемый доступ с учетом времени соединения, без учета времени соединения, доступ по линии ISDN, по аналоговой линии. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Учетное имя имеет ограничения бюджета по телефонным номерам. Учетное имя может иметь несколько ограничений по доступу в сеть по телефонным номерам, степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Учетное имя имеет ограничения бюджета по времени доступа и дням недели. Учетное имя может иметь несколько ограничений по доступу в сеть по времени доступа и дням недели, степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Пользователь имеет почтовые ящики. Любой пользователь может иметь несколько почтовых ящиков, степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

· Тарифные планы коммутируемого доступа с учетом времени соединения относятся к группе услуг. Каждый тарифный план для коммутируемого доступа с учетом времени соединения относится к какой-то группе услуг. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Тип пользователя указывает принадлежность тарифа . Каждый тарифный план для коммутируемого доступа с учетом времени соединения относится к какому-то типу пользователя (физическое или юридическое лицо). Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Тарифные планы коммутируемого доступа с учетом времени соединения содержат коды услуг входных файлов. Каждый тарифный план для коммутируемого доступа с учетом времени соединения имеет код услуги входных файлов. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

• Учетное имя производит доступ из региона. Каждое учетное имя может производить доступ с одного региона без учета зонового продления. Степень связи между сущностями 1:N, проиллюстрируем связь с помощью диаграммы ER-типов.

Полная ER - диаграмма показана ниже на рис. 2.20.

Рис. 2.20. Пример ER - диаграммы