
Курсова БД / Література / rybanov_bd
.pdfроваться либо двумя различными потоками, либо одним – двунаправленным.
Назначение Функции состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем функции. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ).
Кроме того, каждая функция должна иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса функции во всей модели.
Хранилище позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:
20
–функции преобразуют входящие потоки данных в выходящие;
–хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов;
–преобразования потоков данных во внешних сущностях игнорируют-
ся.
Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип данных и формат. Именно эта информация является исходной на следующем этапе проектирования – построении модели «сущность-связь». При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.
Пример 1. На рис. 1 представлена DFD-диаграмма для предприятия, строящего свою деятельность по принципу «изготовление на заказ».
На основании полученных заказов формируется план выпуска продукции на определенный период. В соответствии с этим планом определяются потребность в комплектующих изделиях и материалах, а также график загрузки производственного оборудования. После изготовления продукции и проведения платежей, готовая продукция отправляется заказчику. Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD- диаграмме следующего уровня. Так мы можем разбить функцию «определение потребностей и обеспечение материалами» на подфункции «определение потребностей», «поиск поставщиков», «заключение и анализ договоров на поставку», «контроль платежей», «контроль поставок», связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производиться до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы.
21

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

Пример 2. Рассмотрим процесс СДАТЬ ЭКЗАМЕН. У нас есть две сущности СТУДЕНТ и ПРЕПОДАВАТЕЛЬ. Опишем потоки данных, которыми обменивается наша проектируемая система с внешними объектами
(рис. 2).
Со стороны сущности СТУДЕНТ опишем информационные потоки. Для сдачи экзамена необходимо, чтобы у СТУДЕНТА была ЗАЧЕТКА, а также чтобы он имел ДОПУСК К ЭКЗАМЕНУ. Результатом сдачи экзамена, т.е. выходными потоками будут ОЦЕНКА ЗА ЭКЗАМЕН и ЗАЧЕТКА, в которую будет проставлена ОЦЕНКА.
Со стороны сущности ПРЕПОДАВАТЕЛЬ информационные потоки следующие: ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ, согласно которой будет известно, что СТУДЕНТ допущен до экзамена, а также официальная бумага, куда будет занесен результат экзамена, т.е. ОЦЕНКА ЗА ЭКЗА-
МЕН, проставленная в ЭКЗАМЕНАЦИОННУЮ ВЕДОМОСТЬ.
Рис. 2 DFD-диаграмма процесса «Сдать экзамен»
Теперь детализируем процесс СДАЧА ЭКЗАМЕНА. Этот процесс будет содержать следующие процессы (рис. 3): ВЫТЯНУТЬ БИЛЕТ {1.1},
23

ПОДГОТОВИТЬСЯ К ОТВЕТУ {1.2}, ОТВЕТИТЬ НА БИЛЕТ {1.3}, ПРОСТАВЛЕНИЕ ОЦЕНКИ {1.4}.
Рис. 3 Декомпозиция 1-го уровня DFD-диаграммы процесса «Сдать экзамен»
Рассмотренные методологии фокусируют внимание на потоках данных, их главное назначение – создание базированных на графике документов по функциональным требованиям. Методологии поддерживаются традиционными нисходящими методами проектирования спецификаций и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы.
2.2. Методология SADT (IDEF0)
Методология SADT (Structured Analisys and Design Technique) разрабо-
тана Дугласом Т. Россом в 1969–73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.
24

Рис. 4. IDEF0-модель предприятия
В терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки представляют функции системы, дуги представляют множество объектов (физические объекты, информация или действия, которые обра-
зуют связи между функциональными блоками). Место соединения дуги с блоком определяет тип интерфейса.
Правила интерпретации модели (рис. 4):
– функциональный блок (функция) преобразует входные объекты в вы-
ходные;
–управление определяет, когда и как это преобразование может или должно произойти;
–механизм (исполнитель) осуществляет это преобразование.
С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции систе-
мы связаны между собой, как они обмениваются данными и осуществляют
25
управление друг другом. Выходы одной функции могут быть входами,
управлением или исполнителями другой.
Дуги могут разветвляться и соединяться. Разветвление означает множе-
ственность (идентичные копии одного объекта) или расщепление (различ-
ные части одного объекта). Соединение означает объединение или слияние объектов.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующе-
го уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогич-
ным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.
Пример 3. На рис. 5 представлена IDEF0-модель деятельности предпри-
ятия, описанного в примере 1.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функ-
ции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механиз-
мов, посредством которых они осуществляются.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
26

27
Рис. 5. IDEF0-модель предприятия
3. МЕТОДОЛОГИИ ИНФОРМАЦИОННОГО МОДЕЛИРОВАНИЯ
Важнейшая цель информационной модели заключается в выработке непротиворечивой интерпретации данных и взаимодействий между ними с тем, что необходимо для интеграции, совместного использования и управления целостностью данных.
Появление понятий концептуальной схемы данных привело к методологии семантического моделирования данных, т.е. к определению значений данных в контексте их взаимосвязей с другими данными.
В 1983 году в рамках проекта военного ведомства США «Интегрированные системы информационной поддержки» (ICAM) была создана методология семантического моделирования данных IDEF1X (расширение методологии IDEF1), позволяющая логически объединять в сеть неоднородные вычислительные системы.
Методология IDEF1X – один из подходов к семантическому моделированию данных, основанный на концепции Сущность-связи (EntityRelationship), это инструмент для анализа информационной структуры систем различной природы.
Методология IDEF1X предназначена для построения концептуальной схемы реляционной базы данных, которая была бы независимой от программной платформы её конечной реализации.
Эта информация является необходимым дополнением функциональной IDEF0-модели, детализирует объекты, которыми манипулируют функции системы.
Концептуально IDEF1X-модель можно рассматривать как проект логической схемы базы данных для проектируемой системы.
IDEF1X использует понятия сущностей, атрибутов, отношений и ключей. Языки графического изображения моделей, используемые этими методологиями, также во многом схожи. Однако, IDEF1X не рассматривает объекты реального мира, а лишь их информационное отображение, так как
28

к моменту разработки базы данных все информационные ресурсы организации должны быть изучены, необходимый набор данных для отражения её деятельности определен и проверен на полноту. Поскольку IDEF1X предназначена для разработки реляционных баз данных, она дополнительно оперирует рядом понятий, правил и ограничений, такими как домены, представления, первичные, внешние и суррогатные ключи и другими, пришедшими из реляционной алгебры и в которых нет необходимости на этапах изучения и описания деятельности организации.
Стандарт и методология IDEF1X является специализированным инструментом, предназначенным для разработчиков реляционных баз данных.
Наибольшее распространение получили следующие нотации, используемые при построении ER-диаграмм: нотация Чена, нотация Мартина, нотация IDEF1X, нотация Баркера.
3.1. Нотация Чена
В таблице 4 приведены конструктивные элементы концептуальной схемы базы данных в нотации Чена.
|
|
|
|
|
Таблица 4 |
|
|
Конструктивные элементы нотации Чена |
|
|
|||
|
|
|
|
|
|
|
№ |
Элемент диа- |
Обозначает |
№ |
Элемент диа- |
Обозначает |
|
|
граммы |
|
|
граммы |
|
|
1 |
|
независимая сущ- |
6 |
|
атрибут |
|
|
ность |
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
зависимая сущность |
7 |
|
первичный |
|
|
|
ключ |
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
внешний ключ |
|
|
|
родительская сущ- |
|
|
(понятие внеш- |
|
|
|
|
|
него ключа вво- |
|
|
3 |
|
ность в иерархиче- |
8 |
|
|
|
|
|
дится в реляци- |
|
|||
|
|
ской связи |
|
|
|
|
|
|
|
|
онной модели |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
данных) |
|
29