Ю. А. Григорьев, Г. И. Ревунков - Банки данных

11. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

Рассмотрены особенности концептуального проектирования распре­ деленной системы, описывается последовательность действий при синтезе КС, даны способы описания спецификаций процессов.

11.1. Особенности концептуального проектирования

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

Давно установлено, что цена ошибки (стоимость исправления) быстро возрастает с увеличением интервала времени (технологического времени: числа выполненных операций между двумя событиями) между появлением погрешности и ее обнаружением. Бывший вице-президент Bell Labs по ком­ пьютерной технологии и системам военного назначения Е. Самнер считает, что на интервале от выработки требований на программы до сдачи про­ граммного продукта заказчику стоимость расходов на исправление ошибки возрастает в среднем в 80 раз. В 1983 г. приводились следующие данные о средней стоимости исправления ошибки в спецификациях в зависимости от этапа ЖЦ ИС, на котором эта ошибка «всплывала» (по данным исследова­ ний фирм TRW, GTE Corp. и IBM): на этапе составления спецификаций — 140 долл., кодирования — 1000 долл., комплексной отладки — 7000 долл., сопровождения (у заказчика) — от 14000 до 140000 долл. на каждую ошибку.

Важно также подчеркнуть, что концептуальный проект (КС БД и спе­ цификации задач) не зависит от архитектуры системы, т.е. от технических средств, ОС и СУБД.

191

//. Концептуальное проектирование систем распределенной обработки данных

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

11.2. Разработка концептуальной схемы базы данных

Синтез концептуальной схемы. Концептуальная схема реляционной БД, как правило, описывается диаграммой «сущность—связь» (ERD, ERдиаграмма), предназначенной для разработки модели данных и обеспечи­ вающей стандартный способ определения данных и отношений между ни­ ми. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности сис­ темы и способы их взаимодействия, включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и отношений с другими объектами (связей).

ER-диаграммы были введены Ченом (Chen) и получили дальнейшее развитие в работах Баркера (Barker). Рассмотрим нотацию ER-диаграммы, предложенную Баркером, так как в основном она используется при описа­ нии КС в современных СУБД (например, в Oracle).

Сущность (Entity). Сущность на ER-диаграмме представляется пря­ моугольником любого размера, содержащим имя сущности, список имен атрибутов (возможно неполный) и указатели ключевых атрибутов (знак # перед именем атрибута).

Связь (Relationship). Связь в нотации Баркера является бинарной, т.е. представляет собой линию, соединяющую две сущности (А и В). Для связи должны быть определены:

имя связи со стороны сущности А и сущности В; обязательность связи. Если любой экземпляр сущности А обязательно

должен быть связан с каким-либо экземпляром сущности 5, то прилегаю­ щая к прямоугольнику А половина линии — сплошная, в противном случае она — пунктирная.

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

Из имени связи следует, что клиент владеет кредитной картой, а кре­ дитная карта принадлежит клиенту. При включении в БД записи «Клиент» клиент может и не иметь кредитную карту (связь является необязательной — может быть). При включении в БД записи «Кредитная карта» она должна быть связана с каким-либо клиентом (связь является обязательной — дол­ жен быть). При установлении связи многие CASE-средства автоматически добавят в сущность «Кредитная карта» ключ сущности «Клиент». Это обес­ печит при включении в БД записи «Кредитная карта» ее связь с записью «Клиент» по атрибуту «Код клиента». Каждый клиент может владеть одной

192

/7.2. Разработка концептуальной схемы базы данных

или более кредитной картой (связь 1 \М). При этом каждая кредитная карта должна принадлежать только одному клиенту (связь Ml) . В табл. 11.1 при­ ведены основные типы связей в нотации Баркера.

193

11. Концептуальное проектирование систем распределенной обработки данных

Супертип {Supertype) и подтип (SubType) сущности {категоризация).

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

Например, сущности «Физическое лицо» и «Юридическое лицо» имеют общие атрибуты «Адрес», «Телефон», «Факс». Поэтому эти атрибуты можно объединить в сущность-супертип «Клиент». Остальные атрибуты можно описать в сущностях-подтипах. В базе данных будут храниться три сущности: «Клиент», «Физическое лицо», «Юридическое лицо». Основное преимущество использования супертипов и подтипов заключается в том, что СУБД автоматически обеспечивает ссылочную целостность (с помощью триггеров):

после удаления записи-супертипа удаляются все связанные с ней за- писи-подтипов;

после обновления ключа записи-супертипа обновляются ключи всех связанных с ней записей-подтипов;

после включения записи-подтипа проверяется, есть ли записьсупертип с соответствующим ключом;

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

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

Ниже приведены примеры разработки ER-диаграмм.

Пример описания КС БД с помощью средства CASE"^Designer. В

CASE*Designer (Oracle) разработка ER-диаграммы ведется в нотации Баркера, рассмотренной выше. Рассмотрим пример разработки КС (ERдиаграммы) БД «БДЗ. Ценные бумаги», которая была введена при описании потоков данных (см. рис. 10.3).

194

195

11.Концептуальное проектирование систем распределенной обработки данны

1. Выберите пункт меню Techniques/Entity Diagrammer. На экране появится окно Entity Relationship Diagrammer.

Чтобы построить диаграмму, выберите пункт меню Diagram/New. CASE*Designer запросит имя новой ER-диаграммы и размеры страницы, которую вы должны позиционировать в окне Entity Relationship Diagrammer.

2.Инструментальным средством Entity можно добавить к ER-диа- грамме сущности, которые на рис. 11.1 обозначены прямоугольниками. При этом сущности «Эмитент» и «Торговая площадка» являются подтипами

супертипа «Организация». Затем инструментальными средствами M l , М:М

и1:1 описывают связи между сущностями.

3.Для ввода имен атрибутов выберите на диаграмме сущностей пункт меню Forms/Attribute Definition. После описания всех атрибутов ERдиаграмма будет иметь вид, представленный на рис. 11.1.

4.Чтобы сохранить ER-диаграмму и выйти из Entity Relationship Dia­ grammer выполните пункты меню Diagram/Save и Diagram/Quit.

Пример описания концептуальной схемы с помощью пакета Envin.

После запуска пакета Erwin на экране появляется основное окно пакета.

Вокне инструментов Erwin Toolbox отображаются следующие кнопки: выбор объекта или группы объектов на ER-диаграмме; перемещение объекта на ER-диаграмме;

определение независимой сущности; определение зависимой сущности;

построение связи, определяющей зависимую сущность как подтип

(совокупность подтипов является неполной); построение связи, определяющей зависимую сущность как подтип

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

Следует отметить, что нотация (изображение) ER-диаграммы в пакете Erwin несколько отличается от нотации Баркера. В табл. 11.2—11.4 пред­ ставлены отличия нотаций Баркера и пакета Erwin.

Таблица 11.2. Отличия в обозначении сущностей

196

БД «БДЗ. Ценные бумаги» на уровне сущностей и связей (рис. 11.2).

Чтобы определить атрибуты какой-либо сущности, следует отметить эту сущность на диаграмме, щелкнуть правой клавишей мыши и выбрать пункт Entity Attribute. После описания атрибутов всех сущностей на экране отображается ER-диаграмма со связями и атрибутами.

Чтобы сохранить ER-диаграмму и выйти из Erwin выберите пункты File/Save и File/Exit.

197

и. Концептуальное проектирование систем распределенной обработки данны

Таблица 11.4. Отличия в обозначениях супертипов и подтипов

атрибуты 3

жОрганизация

I"" Эмиссия ЦБ

I

Рис. 11.2. ER-диаграмма со связями, но без атрибутов

198

11.3.Способы описания спецификаций процессов

11.3.Способы описания спецификаций процессов

Спецификация процесса (СП) используется для описания процессов. Фактически СП представляют собой алгоритмы описания задач, выполняе­ мых процессами. Множество всех СП является полной спецификацией сис­ темы. Спецификации процесса содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спе­ цификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Существует много разнообразных методов, позволяю­ щих задать тело процесса. Соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков программирования (типа FLOW-форм и диаграмм Насси-Шней- дермана) и формальных компьютерных языков.

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

К логическим структурам относятся: а) последовательная конструкция:

ВЫПОЛНИТЬ функция, ВЫПОЛНИТЬ функция2 ВЫПОЛНИТЬ функцияз

б) конструкция выбора:

ЕСЛИ <условие> ТО ВЫПОЛНИТЬ функция]

ИНАЧЕ ВЫПОЛНИТЬ функция2

КОНЕЦ ЕСЛИ в) итерация:

ДЛЯ <условие> ВЫПОЛНИТЬ функция

КОНЕЦ ДЛЯ или

ПОКА <условие> ВЫПОЛНИТЬ функция

КОНЕЦ ПОКА

Пример. При разработке диаграммы потоков данных была включена функция «Анализ котировок ЦБ и принятие решений об их продаже». Ниже приведены спецификации этой задачи в терминах структурированного естест­ венного языка.

199