Московский государственный университет печати

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

Их можно разделить на две группы:

1) формальные (математические, скорее теоретические), предполагающие разработку БД только человеком;

2) математические представления, рассчитанные на автоматизацию процесса проектирования БД («компьютерное представление»).

Вторая группа будет рассмотрена в следующем параграфе, а первую обсудим здесь. Сразу отметим разницу двух понятий: «модель данных» - средство моделирования; «модель БД» - результат разработки БД. Модель (представление) БД - множество конкретных ограничений над объектами и операциями с ними.

Модель данных (точнее - модель представления данных) есть множество элементов (объектов, типов данных) и связей (отношений) между ними, ограничений (например, целостности, синхронизации многопользовательского доступа, авторизации) операций над типами данных и отношениями.

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

Описание часто проводят последовательно: структура, ограничения, операции. Начнем поэтому с описания структур данных.

Проще всего структуру (отношение) можно задать таблицей с «плоской» (табл. 1.1)

Таблица 1.1.

Таблица данных о вузе

№_студента	№_преподавателя	Кафедра	Факультет	Часовая нагрузка
1	2	3	4	5
Козлов ...	Строков ...	ИиУС ...	ПМТ ...	65 ...

или сложной (табл. 1.2)

Таблица 1.2.

Таблица поставок комплектующих

Шифр	Название	Кол-во в год	В том числе по кварталам
54 ...	Принтер ...	98 ...	40 ...	17 ...	20 ...	21 ...

структурой. Однако при таком задании хорошо видны элементы (столбцы, поля), но плохо просматриваются отношения, которые могут быть четырех типов: 1:1, 1:M, M:1, M:N.

Более наглядным (особенно для представления типа 1:1) является представление в виде ориентированного графа (рис. 3.1), восходящее к математике, теории автоматического управления и теории информации. Элементами n (n принадлежит N) графа Г(N, U) являются столбцы (поля), а связи между ними определяются дугами u (u принадлежит U). Такому графу соответствует матрица смежности (табл. 3.1)

Таблица 3.1.

Матрица смежности

	1	2	3	4	5
1	0	0	1	1	1
2	0	0	0	0	1
3	0	0	0	0	0
4	0	0	0	0	0
5	0	0	0	0	0

или двудольный граф. Разновидностью графов являются предложенные Д. Мартином овал-диаграммы (рис. 3.2).

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

1) связи в моделях представления данных относительно просты (рис. 3.1), матрицы смежности получаются разреженными, что снижает ценность их использования;

2) в графах отражается чаще всего один тип связи (например, 1:1): выходом здесь может быть использование овал-диаграмм;

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

Для преодоления третьего затруднения сформировались модели представления данных «сущность - связь» (Entity - Relationship), называемые также «ER-моделями (диаграммами)» или «моделями Чена». Базовыми структурами в ER-модели являются «типы сущностей» и «типы связей».

Отличие типа связи от типа сущности - в установлении зависимости существования реализации одного типа от существования реализации другого. (Например, ЛИЧНОСТЬ - тип сущности, тип СОСТОИТ В БРАКЕ - нет, поскольку реализация последнего типа не существует, если не существует двух личностей. Тип связи может рассматриваться поэтому как агрегат двух или более типов сущностей.)

ER-модель может быть представлена ER-диаграммой (ERD), состоящей из следующих элементов:

Выделяют три типа связи: связь «один к одному» (1:1), связь «один ко многим» (1:M), связь «многие ко многим» (M:N).

Примерами этих связей могут быть:

1:1 М:1 M:N

больной <–-> койка, больной <<–-> палата, больной <<–->> врач.

Следует отметить особенности отображения ER-модели:

а) рекурсивное множество связей

б) два множества связей между одними и теми же множествами сущностей

в) множество n-арных связей, например тернарных

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

Фрагмент концептуальной модели предметной области «Больница» представлен на рис. 3.3, а пример представления атрибутов для конкретного объекта показан на рис. 3.4. Выделяют многозначный атрибут, атрибут множества связей.

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

При построении ER-моделей в ряде случаев целесообразно выделять ряд ограничений:

а) ограничение целостности применительно к атрибутам (например, N койки - целое, положительное, число коек - диапазон от 1 до 100);

б) ограничение Е по существованию сущностей (рис. 3.3);

в) ID-зависимость (рис. 3.3): сущность не может быть идентифицирована в ряде случаев по значениям собственных атрибутов.

Покажем свойства этих моделей на примере БД «Учебный процесс» в институте (рис. 3.4). Укрупненно (и в несколько другом начертании, чем на рис. 3.3) он может быть представлен в виде отношений трех групп атрибутов (рис. 3.4, а) со связями M:N и 1:M. Поскольку группы 1 и 3 - множества, схему можно представить в виде рис. 3.4, б. Известно, что ни одна модель данных не может реализовать отношения M:N. В связи с этим схема связей - после преобразования - окончательно выглядит так, как показано на рис. 3.4, в.

Заметим, что перечисленные методы:

1) слабо ориентированы на использование компьютеров в проектировании БД;

2) оперируют со статическими (неизменными) данными, тогда как в реальных системах управления используются динамические данные (потоки данных);

3) отражают потоки данных не системно.

Перечисленным требованиям отвечает CASE-технология, система методов которой приведена на рис. 3.5.

С переходом в автоматизированных системах к задаче автоматизации управления возникла необходимость в системном описании процесса управления, включая и принятие решений. Одними из первых моделей в этом направлении были форрестеровские модели . Позднее появилась методология автоматизации (Structures Analysis Design Technique) SADT .

Модельными компонентами CASE-технологии (рис. 3.5) являются составляющие ERD, DFD, STD. Их место в системном описании процесса управления показано на рис. 3.6.

CASE-технология представляет собой систему методов описания (рис. 3.5), рассчитанную на использование компьютеров при создании БД. Computer-Aided Software/System (CASE-технология) - совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанная комплексом взаимосвязанных средств автоматизации. CASE - инструмент для системных аналитиков, разработчиков и программистов.

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

Они дополняются следующими принципами.

1. Принцип абстрагирования от несущественных деталей (с их «упрятыванием») с контролем на присутствие лишних элементов.

2. Принцип формализации.

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

4. Принцип непротиворечивости - обоснование и согласованность элементов.

5. Принцип логической и физической независимости данных.

6. Принцип непосредственного доступа (без программирования) конечного пользователя.

Эта технология положена в основу реализации программных CASE-средств.

Формальным инструментом описания является система диаграмм рис. 3.5: ER-диаграмм (ERD), диаграмм потоков данных (DFD), диаграмм переходов состояний (STD), спецификаций процесса, - которые обсудим отдельно.

В описании процессов возможны два случая.

1. Сложные процессы.

2. Процессы простые.

ER-диаграммы. Из рис. 3.5 видно, что фактически первой разновидностью методов системы CASE-моделей явились ER-модели Чена, подробно рассмотренные в предыдущем параграфе. Здесь укажем лишь на ее разновидность - модель Баркера (рис. 3.7). В ней указываются имя сущности, степень множественности (например, 1:М), обязательность (–––-) или необязательность (...........) связи.

DF-диаграммы. Диаграммы применяются для отображения процессов вход-выход. Первоначально использовалась методология SADT, о которой говорилось ранее, затем перешли на схемы DFD. Используются две основные разновидности нотаций: Иордана-Демарко и Гейна-Сарсона. Различия между ними невелики и потому используем нотацию Гейна-Сарсона. В нотации используются символы, снабженные именами.

Хранилище (та или иная часть БД) - данные, хранимые в памяти. Внешняя сущность - это источник или приемник данных.

DFD строится на основе декомпозиции, и модель верхнего уровня называют контекстной диаграммой. В любом конкретном проекте она одна. Такие модели описывают объект управления, а для отражения управляющей части (УЧ) системы применяют расширение реального времени: перечисленные обозначения рисуются пунктирными линиями или точками. Основными типами управляющих потоков являются Т-поток (триггер), А-поток (процесс непрерывен, пока поток не выключится), E/D-поток (аналог выключателя с двумя кнопками «включено» и «выключено»).

Для иллюстрации использования диаграмм приведем сначала словесное описание процесса.

Пример 3.1. Словесная модель процесса распределения товаров по заказам.

Полученные фирмой заказы сортируются и подвергаются входному контролю.

Если заказ не отвечает номенклатуре товаров фирмы или неверно оформлен, он аннулируется с уведомлением заказчика.

Если заказ принят, то определяется наличие товаров на складе.

Если товар есть, то выписывается предъявляемый заказчику счет к оплате, после которой товар отправляется заказчику.

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

Контекстная диаграмма Гейна-Сарсона представлена на рис. 3.8: она позволяет видеть входные и выходные потоки. Детализированная диаграмма рассматриваемого процесса может быть представлена в виде, показанном на рис. 3.9, при этом в общем случае каждый из процессов 1 - 3, в свою очередь, может быть детализирован. Расширенная диаграмма отображена на рис. 3.10. Алгоритм выработки решений показан в более знакомом виде на рис. 3.11, а соответствующая форрестеровская модель процесса - на рис. 3.12.

Рис. 3.8 - 3.11 позволяют заметить, что потоки имеют пояснения. Текстовые средства моделирования получили название словаря данных. В форме Бэкуса-Наура (БНФ) его фрагмент представлен на рис. 3.13.

ST-диаграмма. Она используется для отображения процесса выработки и результатов реализации решений. Вводится понятие «состояние». Схематика (схема переходов) может быть такой, как показано на рис. 3.14. Процесс изменения состояния может быть отражен с помощью таблицы

Текущее состояние	Условие	Действие	Следующее состояние
Начальное состояние	Активизируется каждый раз
ОЖИДАНИЕ	Заказ	Получить заказ	ОБРАБОТKА
ОБРАБОТKА	Заказ не отвечает номенклатуре	Аннулировать заказ	ОЖИДАНИЕ
ОБРАБОТKА	Заказ обеспечен складскими запасами	Реализация заказа	ОЖИДАНИЕ
ОБРАБОТKА	Заказ не обеспечен складскими запасами	Заявка на товар	ОЖИДАНИЕ

Условие Состояние		Заказ	Заказ не отвечает номенклатуре	Заказ обеспечен складскими запасами	Заказ не обеспечен складскими запасами
Начальное состояние	Активизируется каждый раз
ОЖИДАНИЕ		Получить заказ ОБРАБОТKА
ОБРАБОТKА			Аннулировать заказ ОЖИДАНИЕ
ОБРАБОТKА				Реализация заказа ОЖИДАНИЕ
ОБРАБОТKА					Заявка на товар ОЖИДАНИЕ

Рассмотренный аппарат используется для масштабных процессов. Для простых процессов он существенно упрощен (рис. 3.5).

В этом случае системной основой является спецификация процесса, содержащая номер, имя процесса, список входных и выходных данных и тело (описание, алгоритм) процесса. Тело можно описать (рис. 3.5) структурированным языком, визуальным языком, формальными компьютерными языками. Спецификация процесса (рис. 3.9) может иметь такой вид:

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

Таблицы решений чаще всего задаются по схеме ЕСЛИ ..., ТО... и могут быть отражены в виде деревьев решений (Сi - условие).

Продвинутой разновидностью Flow-форм является диаграмма Несси-Шнейдера.

Отдельными обозначениями выступают схемы программ, о которых поговорим в главе 10.

Далее речь пойдет о сложных процессах.

После освещения деталей CASE-технологии вернемся к системному аспекту.

CASE-технологии могут быть классифицированы по нескольким признакам.

1. По шкалам Software Engineerig (SE) и Information Engineerig (IE). Первая шкала предназначена для проектирования программного обеспечения и хорошо известна - фактически описана в данной работе, вторая - новая, с более широкой областью применения (для проектирования не только программного обеспечения).

2. По порядку построения модели:

   а) процедурно-ориентированный (современный подход);

   б) ориентированный на данные (традиционный подход).

3. По типу целевых систем - для систем реального времени (управление сложными структурами большого объема данных с интенсивным вводом-выводом) и информационных систем (управление событиями с малым количеством простых по структуре данных с интенсивными вычислениями).

CASE-технология поддерживается, как уже указывалось, CASE-средствами. Здесь опишем лишь их возможности, тогда как технологию их использования обсудим в главе 10.

Интегрированный пакет CASE-средств содержит 4 основных компонента.

1. Средства централизованного хранения информации о всем проекте (своеобразная база данных проекта).

2. Средства ввода данных для хранения.

3. Средства анализа, проектирования и разработки.

4. Средства вывода.

Для CASE-технологии (сокращенно - CASE) характерны четыре основных типа графических диаграмм:

1) функциональное проектирование (DFD);

2) моделирование данных (ERD);

3) моделирование поведения (STD);

4) структурные диаграммы (карты) - отношения между модулями и внутри- модульная структура.

CASE-средства (прежде всего фирмы Oracle и отдельных организаций) возможно классифицировать по категориям и по функциональному признаку.

1. По категориям. Выделяют уровень интеграции: вспомогательные программы (tools); пакеты(toolkit); инструментальные средства (workbench, АРМ).

2. По функциональному признаку.

Для анализа и проектирования возможно использовать CASE-аналитик (единственное отечественное средство первой генерации), Application Development Workbench, Easy CASE System Designer.

Проектирование БД существенно упрощается при применении ERWin (фирма Logic Works), Designer/2000 (Oracle), позволяющих проводить логическое моделирование данных, автоматическое преобразование данных в ЗНФ.

Программирование (кодогенерирование) - DECACE (DEC), Delphi (Borland).

Сопровождение (поддержка системной документации) и реинжиниринг (анализ, корректировка, реинжиниринг существующей системы) - SuperStructure (Computer Data System).

Управление проектом (планирование, контроль, взаимодействие) - Project Workbench (Applied Business Technology).

Рассмотрим одну из реальных систем автоматизации проектирования БД в рамках Oracle (Cooperative Development Environment - CDE), в которую входят CASE*Dictionary, CASE*Designer, CASE*Generator.

CASE*Dictionary - хранилище информации (БД проекта). CASE*Designer - средство моделирования процессов и данных в системе через внешний интерфейс с помощью средств графического моделирования. CASE*Designer полностью интегрирован с CASE*Dictionary. CASE*Generator - на основе информации CASE*Designer автоматически генерирует модули программного кода (меню, формы, отчеты). CASE*Generator может генерировать и DLL-сценарии (таблицы, представления, индексы, последовательности) в схеме приложения.

Oracle7 был спроектирован с открытой архитектурой и потому другие компании смогли создать дополняющие средства:

Application Development Workbench (разработка систем на многих платформах) - компания KnowledgeWare;

Easy CASE System Designer (графическое инструментальное средство проектирования, позволяющее генерировать схемы приложения для одной или нескольких СУБД, включая Oracle) - компания Evergreen CASE Tools;

ERWin/ERX (средство проектирования БД для MS Windows) - компания Logic Works;

ADW - интегрированный набор средств для анализа, планирования и моделирования процессов и данных и автоматической генерации приложений.