Рыбанов А.А. Инструментальные средства автоматизированного проектирования баз данных

Подождите немного. Документ загружается.

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

ным.

Назначение Функции состоит в продуцировании выходных потоков из

входных в соответствии с действием, задаваемым именем функции. Это

имя должно содержать глагол в неопределенной форме с последующим

дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ).

Кроме того, каждая функция должна иметь уникальный номер для ссылок

на

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

номером диаграммы для получения уникального индекса функции во всей

модели.

Хранилище позволяет на определенных участках определять данные,

которые будут сохраняться в памяти между процессами. Фактически хра-

нилище представляет «срезы» потоков данных во времени. Информация,

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

время после ее оп-

ределения, при этом данные могут выбираться в любом порядке. Имя хра-

нилища должно идентифицировать его содержимое и быть существитель-

ным. В случае, когда поток данных входит или выходит в/из хранилища и

его структура соответствует структуре хранилища, он должен иметь то же

самое имя, которое нет необходимости

отражать на диаграмме.

Внешняя сущность представляет сущность вне контекста системы, яв-

ляющуюся источником или приемником системных данных. Ее имя долж-

но содержать существительное, например, СКЛАД ТОВАРОВ. Предпола-

гается, что объекты, представленные такими узлами, не должны участво-

вать ни в какой обработке.

Функции, хранилища и внешние сущности на DFD-диаграмме связыва-

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

или сливаться, что означает, соответственно, разделение потока данных на

части, либо слияние объектов. При интерпретации DFD-диаграммы ис-

пользуются следующие правила:

– функции преобразуют входящие потоки данных в выходящие;

– хранилища данных не изменяют потоки данных, а служат только для

хранения поступающих объектов;

– преобразования потоков данных во внешних сущностях игнорируют-

ся.

Помимо этого, для каждого информационного потока и хранилища оп-

ределяются связанные с ними элементы данных. Каждому элементу дан-

ных присваивается имя,

также для него может быть указан тип данных и

формат. Именно эта информация является исходной на следующем этапе

проектирования – построении модели «сущность-связь». При этом, как

правило, информационные хранилища преобразуются в сущности, проек-

тировщику остается только решить вопрос с использованием элементов

данных, не связанных с хранилищами.

Пример 1. На рис. 1 представлена

DFD-диаграмма для предприятия,

строящего свою деятельность по принципу «изготовление на заказ».

На основании полученных заказов формируется план выпуска продук-

ции на определенный период. В соответствии с этим планом определяются

потребность в комплектующих изделиях и материалах, а также график за-

грузки производственного оборудования. После изготовления продукции и

проведения платежей, готовая

продукция отправляется заказчику. Эта диа-

грамма представляет самый верхний уровень функциональной модели. Ес-

тественно, это весьма грубое описание предметной области. Уточнение

модели производится путем детализации необходимых функций на DFD-

диаграмме следующего уровня. Так мы можем разбить функцию «опреде-

ление потребностей и обеспечение материалами» на подфункции «опреде-

ление потребностей», «поиск поставщиков», «заключение

и анализ дого-

воров на поставку», «контроль платежей», «контроль поставок», связанные

собственными потоками данных, которые будут представлены на отдель-

ной диаграмме. Детализация модели должна производиться до тех пор, по-

ка она не будет содержать всю информацию, необходимую для построения

информационной системы.

Рис. 1. DFD-диаграмма предприятия

Пример 2. Рассмотрим процесс СДАТЬ ЭКЗАМЕН. У нас есть две сущ-

ности СТУДЕНТ и ПРЕПОДАВАТЕЛЬ. Опишем потоки данных, которы-

ми обменивается наша проектируемая система с внешними объектами

(рис. 2).

Со стороны сущности СТУДЕНТ опишем информационные потоки.

Для сдачи экзамена необходимо, чтобы у СТУДЕНТА была ЗАЧЕТКА, а

также чтобы он имел ДОПУСК

К ЭКЗАМЕНУ. Результатом сдачи экзаме-

на, т.е. выходными потоками будут ОЦЕНКА ЗА ЭКЗАМЕН и ЗАЧЕТКА,

в которую будет проставлена ОЦЕНКА.

Со стороны сущности ПРЕПОДАВАТЕЛЬ информационные потоки

следующие: ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ, согласно которой бу-

дет известно, что СТУДЕНТ допущен до экзамена, а также официальная

бумага, куда будет занесен результат экзамена, т.е

. ОЦЕНКА ЗА ЭКЗА-

МЕН, проставленная в ЭКЗАМЕНАЦИОННУЮ ВЕДОМОСТЬ.

Рис. 2 DFD-диаграмма процесса «Сдать экзамен»

Теперь детализируем процесс СДАЧА ЭКЗАМЕНА. Этот процесс будет

содержать следующие процессы (рис. 3): ВЫТЯНУТЬ БИЛЕТ {1.1},

ПОДГОТОВИТЬСЯ К ОТВЕТУ {1.2}, ОТВЕТИТЬ НА БИЛЕТ {1.3},

ПРОСТАВЛЕНИЕ ОЦЕНКИ {1.4}.

Рис. 3 Декомпозиция 1-го уровня DFD-диаграммы процесса «Сдать экзамен»

Рассмотренные методологии фокусируют внимание на потоках данных,

их главное назначение – создание базированных на графике документов по

функциональным требованиям. Методологии поддерживаются традицион-

ными нисходящими методами проектирования спецификаций и обеспечи-

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

и пользователями системы.

2.2. Методология SADT (IDEF0)

Методология SADT (Structured Analisys and Design Technique) разрабо-

тана Дугласом Т. Россом в

1969–73 годах. Она изначально создавалась для

проектирования систем более общего назначения по сравнению с другими

структурными методами, выросшими из проектирования программного

обеспечения. IDEF0 (подмножество SADT) используется для моделирова-

ния бизнес-процессов в организационных системах и имеет развитые про-

цедуры поддержки коллективной работы.

Рис. 4. IDEF0-модель предприятия

В терминах IDEF0 система представляется в виде комбинации блоков и

дуг. Блоки представляют функции системы, дуги представляют множество

объектов (физические объекты, информация или действия, которые обра-

зуют связи между функциональными блоками). Место соединения дуги с

блоком определяет тип интерфейса.

Правила интерпретации модели (рис. 4):

– функциональный блок (функция) преобразует входные объекты в

вы-

ходные;

– управление определяет, когда и как это преобразование может или

должно произойти;

– механизм (исполнитель) осуществляет это преобразование.

С дугами связываются метки на естественном языке, описывающие

данные, которые они представляют. Дуги показывают, как функции систе-

мы связаны между собой, как они обмениваются данными и осуществляют

управление друг другом. Выходы одной функции могут быть входами,

управлением или исполнителями другой.

Дуги могут разветвляться и соединяться. Разветвление означает множе-

ственность (идентичные копии одного объекта) или расщепление (различ-

ные части одного объекта). Соединение означает объединение или слияние

объектов.

Каждый блок IDEF0-диаграммы может быть представлен несколькими

блоками, соединенными интерфейсными дугами

, на диаграмме следующе-

го уровня. Эти блоки представляют подфункции (подмодули) исходной

функции. Каждый из подмодулей может быть декомпозирован аналогич-

ным образом. Число уровней не ограничивается, зато рекомендуется на

одной диаграмме использовать не менее 3 и не более 6 блоков.

Пример 3. На рис. 5 представлена IDEF0-модель деятельности предпри-

ятия, описанного в примере 1

Методология SADT может использоваться для моделирования широкого

круга систем и определения требований и функций, а затем для разработки

системы, которая удовлетворяет этим требованиям и реализует эти функ-

ции. Для уже существующих систем SADT может быть использована для

анализа функций, выполняемых системой, а также для указания механиз-

мов, посредством которых они

осуществляются.

Результатом применения методологии SADT является модель, которая

состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки

друг на друга.

Рис. 5. IDEF0-модель предприятия

3. МЕТОДОЛОГИИ ИНФОРМАЦИОННОГО МОДЕЛИРОВАНИЯ

Важнейшая цель информационной модели заключается в выработке

непротиворечивой интерпретации данных и взаимодействий между ними с

тем, что необходимо для интеграции, совместного использования и управ-

ления целостностью данных.

Появление понятий концептуальной схемы данных привело к методо-

логии семантического моделирования данных, т.е. к определению значе-

ний данных в

контексте их взаимосвязей с другими данными.

В 1983 году в рамках проекта военного ведомства США «Интегриро-

ванные системы информационной поддержки» (ICAM) была создана мето-

дология семантического моделирования данных IDEF1X (расширение ме-

тодологии IDEF1), позволяющая логически объединять в сеть неоднород-

ные вычислительные системы.

Методология IDEF1X – один из подходов к семантическому моделиро-

ванию данных

, основанный на концепции Сущность-связи (Entity-

Relationship), это инструмент для анализа информационной структуры сис-

тем различной природы.

Методология IDEF1X предназначена для построения концептуальной

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

граммной платформы её конечной реализации.

Эта информация является необходимым дополнением функциональной

IDEF0-модели, детализирует объекты, которыми манипулируют функции

системы.

Концептуально IDEF1X-модель можно рассматривать как проект логи-

ческой схемы базы данных для проектируемой системы.

IDEF1X использует понятия сущностей, атрибутов, отношений и клю-

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

тодологиями, также во многом схожи. Однако, IDEF1X не рассматривает

объекты реального мира, а лишь их информационное отображение, так

как

к моменту разработки базы данных все информационные ресурсы органи-

зации должны быть изучены, необходимый набор данных для отражения

её деятельности определен и проверен на полноту. Поскольку IDEF1X

предназначена для разработки реляционных баз данных, она дополнитель-

но оперирует рядом понятий, правил и ограничений, такими как домены,

представления, первичные, внешние и суррогатные ключи

и другими,

пришедшими из реляционной алгебры и в которых нет необходимости на

этапах изучения и описания деятельности организации.

Стандарт и методология IDEF1X является специализированным инст-

рументом, предназначенным для разработчиков реляционных баз данных.

Наибольшее распространение получили следующие нотации, исполь-

зуемые при построении ER-диаграмм: нотация Чена, нотация Мартина,

нотация IDEF1X, нотация

Баркера.

3.1. Нотация Чена

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

схемы базы данных в нотации Чена.

Таблица 4

Конструктивные элементы нотации Чена

№

Элемент диа-

граммы

Обозначает №

Элемент диа-

граммы

Обозначает

независимая сущ-

ность

атрибут

зависимая сущность 7

первичный

ключ

родительская сущ-

ность в иерархиче-

ской связи

внешний ключ

(понятие внеш-

него ключа вво-

дится в реляци-

онной модели

данных)