Тема «Концептуальное моделирование»

КУРС «Базы данных» *** Тема «Концептуальное моделирование»

Схема процесса поэтапного проектирования БД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, одному объекту, соответствующему сущности «Заказчик», может соответствовать (быть связанными) ноль, один или более объектов сущности «Заявка», если мы допускаем возможность работы с потенциальными заказчиками и возможность неоднократного обращения одного заказчика.

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

Для представления типа связи в схемах Чена используется специальная разметка линий, соединяющих сущности и связи. На концах линий, присоединенных к сущностям, применяются четыре символа: || - означают обязательное участие в связи одного и только одного объекта, 0| - ноль и вертикальная линия, означают участие в связи не более одного объекта, >| - один или более объектов могут участвовать в связи, >0 – ноль или более, то есть любое число объектов может участвовать в связи.

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

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

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

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

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

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

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

·  Из схем принятых к автоматизации процессов следуют функции программного обеспечения, необходимые пользователям АС. Эти функции образуют пункты главного и контекстного меню и другие элементы управления в экранных формах пользовательских приложений. ·  Путем типизации входных и выходных объектов, выбранных для автоматизации функций, создаются сущности ПО, которые должны быть представлены в БД. Для сущностей устанавливаются необходимые атрибуты и выбираются ключи. ·  Анализируя взаимодействия объектов, образовавших сущности, выясняются связи между сущностями и создается концептуальная схема ПО, например, в виде диаграммы Чена. При необходимости сложные сущности декомпозируются на более простые посредством их детализации и конкретизации с соответствующей декомпозицией связей.

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

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

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

один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи n отображается "древообразной" линией, так это сделано на следующем рисунке. Данный рисунок дополнительно иллюстрирует тот факт, что между двумя сущностями может быть определено несколько наборов связей.

много к одному (n : 1 ). Эта связь аналогична отображению 1 : n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели "сущность-связь" с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ(НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень n : 1. В данном случае, по совершенно очевидным соображениям (каждый контракт заключен с конкретным заказчиком, а каждый заказчик имеет хотя бы один контракт, иначе он не был бы таковым), каждая сущность имеет обязательный класс принадлежности.