В данном подразделе рассматривается вторая часть методики Йордона (см. подразд. 3.2.2), связанная с переходом от бизнес-модели к модели системы. Пример применения данной методики приведен в подразд. 4.2.
Согласно данной методике в процессе проектирования выполняется детальное описание функционирования системы, дальнейший анализ используемых данных и построение реляционной модели для последующего проектирования базы данных. Определяется также структура пользовательского интерфейса. Результатами проектирования являются:
· модель системных процессов;
· архитектура системы;
· модели данных приложений;
· модель пользовательского интерфейса.
Функциональные модели, используемые в процессе проектирования, предназначены для описания функциональной структуры проектируемой системы. Диаграммы потоков данных (DFD) используются для описания структуры проектируемой системы, при этом они могут уточняться, расширяться и дополняться новыми конструкциями. Аналогично, ERM преобразуется в схему базы данных. Данные модели могут дополняться диаграммами, отражающими системную архитектуру ПО, структурные схемы программ (структурные карты), иерархию экранных форм и меню и др. Состав диаграмм и степень их детализации определяются необходимой полнотой описания системы для непосредственного перехода к ее последующей реализации (программированию).
Например, для DFD переход от модели бизнес-процессов к модели системных процессов может происходить следующим образом:
· внешние сущности на контекстной диаграмме заменяются или дополняются техническими устройствами (например, рабочими станциями, принтерами и т.д.);
· для каждого потока данных определяется, посредством каких технических устройств информация передается или производится;
· процессы на диаграмме нулевого уровня заменяются соответствующими процессорами — обрабатывающими устройствами (процессорами могут быть как технические устройства — настольные компьютеры конечных пользователей, рабочие станции, серверы баз данных, так и программные средства);
· определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть);
· определяются задачи для каждого процессора (приложения, необходимые для работы системы), для них строятся соответствующие диаграммы. Определяется тип связи между задачами;
· устанавливаются ссылки между задачами и процессами диаграмм потоков данных следующих уровней.
Иерархия экранных форм Моделируется с помощью диаграмм последовательностей экранных форм. Совокупность таких диаграмм представляет собой абстрактную модель пользовательского интерфейса системы, отражающую последовательность появления экранных форм в приложении. Построение диаграмм последовательностей экранных форм выполняется следующим образом:
· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользовательском интерфейсе, поэтому можно определить экранную форму для каждого такого процесса;
· построение диаграммы последовательностей форм начинается с изображения формы в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;
· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же, как в модели процессов, либо другим способом — по функциональным признакам или в зависимости от принадлежности к определенным объектам);
· формы с меню изображаются над формами, соответствующими интерактивным процессам, и соединяются с ними переходами в виде стрелок, направленных от меню к формам.
· определяется верхняя форма (главная форма приложения), связывающая все формы с меню.
Техника структурных карт (схем) используется на стадии проектирования для описания структурных схем программ. При этом наиболее часто применяются две техники: структурные карты Константайна, предназначенные для описания отношений между модулями, и структурные карты Джексона, предназначенные для описания внутренней структуры модулей, являющихся базовыми строительными блоками программной системы. В настоящее время структурные карты применяются сравнительно редко.
В процессе проектирования базы данных концептуальная модель данных преобразуется в схему реляционной базы данных, основными элементами которой являются таблицы и столбцы. Для описания схемы базы данных может использоваться отдельная графическая нотация.
Для формирования схемы базы данных из ERM применяется ограниченный набор правил преобразования сущностей и связей между ними.
Правила преобразования сущностей:
Правило 1. Каждая простая сущность, не являющаяся подтипом и не имеющая подтипов, превращается в таблицу. Имя сущности становится именем таблицы.
Правило 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, — не могут.
Правило 3. Уникальный идентификатор сущности превращается в первичный ключ таблицы. Если имеется несколько альтернативных уникальных идентификаторов, выбирается наиболее используемый. Если уникальный идентификатор является относительным, то в качестве первичного ключа используется копия уникального идентификатора сущности, находящейся на дальнем конце связи, в которой данная сущность играет роль зависимой.
Правила преобразования связей:
Правило 1. Если тип бинарной связи — один-к-одному и класс принадлежности обеих сущностей является обязательным, то из двух связанных сущностей формируется одна таблица. Первичным ключом этой таблицы может быть идентификатор любой из двух сущностей.
Правило 2. Если тип бинарной связи — один-к-одному и класс принадлежности одной сущности является обязательным, а другой — необязательным, то формируются две таблицы (под каждую сущность), при этом идентификатор каждой сущности должен служить первичным ключом соответствующей таблицы. Кроме того, идентификатор сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности.
Правило 3. Если тип бинарной связи - один-к-одному и класс принадлежности ни одной сущности не является обязательным, то формируются три таблицы: по одной для каждой сущности (при этом идентификатор каждой сущности должен служить первичным ключом соответствующей таблицы) и одна для связи. Таблица связи включает в качестве атрибутов по одному идентификатору от каждой сущности.
Правило 4. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является обязательным, то формируются две таблицы (под каждую сущность), при этом идентификатор каждой сущности должен служить первичным ключом соответствующей таблицы. Кроме того, идентификатор сущности с мощностью «1» добавляется в качестве атрибута в таблицу, выделенную для сущности с мощностью «n».
Правило 5. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является необязательным, см. правило 3.
Правило 6. Если тип бинарной связи — многие-ко-многим, см. правило 3.
Правило 7. Для представления N-арной связи требуется N+1 таблица. Например, в случае тернарной связи формируются четыре таблицы, по одной для каждой сущности и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи от каждой сущности.
Правило 8. Для связи «супертип-подтип» возможны два способа преобразования:
а) все подтипы в одной таблице;
б) для каждого подтипа — отдельная таблица.
При применении способа (а) для супертипа создается таблица, а для подтипов могут создаваться представления (view). В таблицу добавляется по крайней мере один столбец, содержащий код типа; он становится частью первичного ключа.
При использовании способа (б) для каждого подтипа супертип воссоздается с помощью операции объединения (UNION) — из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа.
Преимущества способа (а): все данные хранятся вместе, обеспечивается легкий доступ к супертипу и подтипам, требуется меньше таблиц.
Недостатки способа (а): усложняется логика работы с разными наборами столбцов и ограничениями, возможно снижение производительности (в связи с блокировками общей таблицы), столбцы подтипов должны допускать неопределенные значения.
Преимущества способа (б): наглядное соответствие схемы БД и ERM, приложения работают только с нужными таблицами.
Недостатки способа (б): формируется слишком много таблиц, возможно снижение производительности при выполнении операции объединения, невозможны модификации супертипа.
4.2.
ПРИМЕР СТРУКТУРНОГО
ПРОЕКТИРОВАНИЯ ПО
Здесь продолжено рассмотрение примера из подразд. 3.2.5.
