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

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

ПРИМЕР. Для демонстрации средств описания и документирования процессов ПО, рассмотрим деятельность вымышленной компании по производству и установке пластиковых окон и дверей. Заказчиками компании могут быть физические и юридические лица. Целью деятельности является получение прибыли путем оказания своевременных и качественных услуг по основному профилю работы. Основной бизнес - процесс приема заявки и исполнения заказа описывается схемой, представленной на рис. 3.2.

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

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

В представленной на рис. 3.2 схеме процесс «Разработка конструкции и сметы» является достаточно сложным, реализуемым многоэтапным подпроцессом, который раскрывается отдельной диаграммой, приведенной на рис. 3.3.

Для изображения диаграмм (рис. 3.2 и рис. 3.3) была использована программа автоматизации построения функциональных моделей процессов BPWin 4.0, предназначенная для иерархической декомпозиции и изображения схем процессов в стандартах IDEF0 (BusinessProcess),IDEF3 (ProcessFlow) и DFD (Data Flow). При выполнении курсового проекта использование средств автоматизации процесса разработки BPWin, ERWin или других продуктов в рамках CASE (computer-aided software engineering) технологий и средств не является обязательным. А для документирования результатов анализа ПО и проектирования могут использоваться любые средстваизображения схем

Рис. 3.2. Схема процесса приема и исполнения заказа

Рис. 3.3. Схема процесса разработки конструкции и сметы заказа

Следующим шагом проектирования базы является создание и согласование со специалистами в ПО концептуальной схемы данных, используемых в автоматизируемых процессах. Концептуальная схема должна отражать состав и взаимодействие объектов будущей БД. Для этой цели разработано несколько систем соглашений о представлении информации, содержащейся в БД. Например, диаграммы потоков данных (Data Flow Diagrams), фиксирующих пути перемещения информации с указанием мест ее хранения и обработки, или универсальный язык моделирования (UML) - промышленный стандарт создания моделей процессов и данных для объектно-ориентированных разработок АС. Подобные системы предназначены для автоматизации всего процесса разработки АС и изучаются в курсе «Проектирование информационных систем».

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

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

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

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

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

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

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

>| - один или более объектов могут участвовать в связи,

>0 – ноль или более, то есть любое число объектов может участвовать в связи.

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

Рис.3.4. Представление связи «один ко многим» с обязательным участи-

ем в связи сущности «Заявка»

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

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

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

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

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

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

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

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

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

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

Например, перечисление атрибутов сущности «Заказчик» может иметь вид:

ЗАКАЗЧИК

Обязательные атрибуты:

Номер – целое (1 – 100000), первичный ключ,

Наименование - строка не более 60 символов,

ИНН – индивидуальный номер налогоплательщика, 12 десятичных цифр,

может служить дополнительным (вторичным) ключом,

Адрес - строка до 40 символов,

ФИО контактного лица – строка до 50 символов,

. . . . . . . .

Необязательные атрибуты:

Телефоны – строка до 20 символов

Реквизиты банка – строка до 28 символов

. . . . . . . .

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

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