Концептуальное проектирование базы данных

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

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

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

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

Вершины второго типа – отношения в самом общем виде представляют собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.). Эти вершины изображаются ромбами.

Символы ERD, соответствующие сущностям и отношениям, приведены на рисунке 1.

Рисунок 1 – Символы ERD, соответствующие сущностям и отношениям

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

Зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она должна всегда иметь отношения с другими сущностями.

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

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

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

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

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

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретной сущности, но может быть одинаковым для различных сущностей (например, ЦВЕТ может быть определен для многих сущностей: окно, дверь и т.д.). Атрибуты используются для хранения набора данных об объектах ПрО, включаемых в БД. При этом любой атрибут может быть определен как ключевой. Для идентификации ключевого атрибута используется подчеркивание имени атрибута (см. рисунок 2).

Рисунок 2 – Описание сущности

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

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

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

Второй тип вершин в диаграммах Питера Чена, называемый «связи», предназначен для представления взаимодействий объектов, образовавших сущности. Связи, соединяя сущности, образуют концептуальную схему предметной области. Связи могут отражать взаимодействия любого числа сущностей. Например, взаимодействие «Заявка» и «Заказчик» связывает две сущности, а значит, образует бинарную связь. Связь сущностей «Студент», «Учебная дисциплина» и «Преподаватель» следует рассматривать как связь трех сущностей (тернарнyю). Связь, как и сущность, имеет имя и может иметь атрибуты, которые не могут быть отнесены ни к одной из связанных сущностей. Например, атрибут «Оценка» принадлежит связи «Успеваемость», соединяющей сущности «Студент». «Учебная дисциплина» и «Преподаватель».

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

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

- две вертикальные линии, означают обязательное участие в связи одного и только одного объекта;

- ноль и вертикальная линия, означают участие в связи не более одного объекта;

- знак больше и вертикальная черта означают, что один или более объектов могут участвовать в связи;

- знак больше и вертикальная черта означают, что любое число объектов может участвовать в связи.

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

Рисунок 3 – Представление связи «один ко многим»
с обязательным участием в связи сущности «Заявка»

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

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

Таким образом, связь между экземплярами этих сущностей является «один к одному» (1:1) с обязательным участием обоих объектов в связи (см. рисунок 4).

Рисунок 4 – Представление связи «один к одному»
с обязательным участием обеих сущностей в связи

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

Рисунок 5 – Представление необязательной связи «многие ко многим»

Приведенные примеры взаимодействий (связей) сущностей являются наиболее распространенными и поэтому именно они являются основой другого типа схем для представления информационной модели ПрО – ER диаграммы.

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

Для обозначения типа связи на ER диаграмме используются различные соглашения. Связь «один к одному» и «один ко многим» может обозначаться соответствующим символом (1, М, ∞, ●, , ) на линии, связывающей сущности. Использование этих соглашений показано на рисунке 6, представляющих связь типа «один ко многим».

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

Рисунок 6 – Различные способы представления
бинарной связи типа «один ко многим»

Для обозначения обязательности или необязательности участия в связи сущности, помеченной знаком (М, ∞ или ●), используется толщина соединяющей линии. Это показано на следующем рисунке 7.

Рисунок 7 – Способы представления бинарной связи «один ко многим» с обязательным участием сущности в связи

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

Программы автоматизации проектирования БД (например, ERWin, CaseStudio) не только имеют средства «рисования» ER диаграмм, но и позволяют для каждой связи выбрать в диалоговых окнах ее тип и вид, чтобы далее преобразовать полученную схему данных в структуру базы для конкретной СУБД или сформировать скрипт на языке SQL для последующей генерации базы. А многие СУБД (например, Access, MS SQL Server) позволяют построить графическое представление структуры данных, близкое к ER – диаграмме.

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

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

1. Выясняется круг специалистов – пользователей информационной системы.

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

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

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

5. Анализируя взаимодействия объектов, образовавших сущности, выясняются связи между сущностями и создается концептуальная схема ПрО, например, в виде диаграммы Питера Чена. При необходимости сложные сущности декомпозируются на более простые посредством их детализации и конкретизации с соответствующей декомпозицией связей. На рисунке 8 приведен пример частичной концептуальной схемы данных в виде диаграммы Питера Чена для рассмотренного ранее процесса приема и исполнения заказа (см. рисунок 8).

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

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

Рисунок 8 – Концептуальная схема (диаграмма Питера Чена) для процесса приема и исполнения заказа

3.2 Содержание раздела «Построение логической модели реляционной БД»

Дата добавления: 2015-07-08