Предметная область базы данных и ее модели

Диаграммы "сущность-связь"

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

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

Документирование сущностей и атрибутов

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

Рис. 2.3. Представление сущности Person (персонал) на ER-диаграмме

Рис. 2.4. Представление сущности Person с атрибутами и уникальным идентификатором сущности

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

Документирование доменов

Домены назначаются аналитиками и фиксируются в специальном документе - словаре данных (Data Dictionary). На стадиях разработки логической и физической моделей реляционной базы данных домены уточняются в сущностях на ER-диаграмме.

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

• для реализации реляционной базы данных требуется использовать реляционную СУБД, например Oracle;
• в большинстве реляционных СУБД в качестве языка манипулирования и описания данных используется диалект SQL, поддерживающий определенные стандарты, например ANSI SQL-92.

Пример. Изначально домен атрибута Photo (Фотография) сущности Person (Персона) был определен как Image (Рисунок). Проектировщик базы данных должен изменить значение домена на LONG RAW (СУБД Oracle) или BLOB (двоичный большой объект) ( SQL-92 ).

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

Документирование отношений (связей)

Отношение (связь) сущностей на ER -диаграмме изображается линией, соединяющей эти сущности.

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

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

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

Рис. 2.6. Представление отношения между двумя сущностями на ER-диаграмме

Как правило, отношения на ER-диаграммах именуются с обеих сторон.

Рис. 2.7. Связанные сущности с названием сторон

Документирование супертипов и подтипов

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

Рис. 2.8. Изображение супертипа Person с двумя подтипами Head и Employee

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

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