2.Система или процесс изображается овалом. Имя системы – существительное.

3.Процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3.

Пример имени процесса:

•Ввести сведения о клиентах;

•Выдать информацию о расходах;

•Проверить данные клиента.

4.Накопитель данных является архивом, указывается буквой "D" и числом. Имя произвольное.

5.Поток данных определяет

информацию, передаваемую от источника к приемнику, изображается линией, показывающей направление потока.

Построение иерархии DFD

•Для простых ИС строится одна контекстная диаграмма со звездообразной топологией, в центре которой находится главный процесс, соединенный с приемниками и источниками информации. Для сложных ИС строится иерархия контекстных диаграмм.

•Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. При детализации должны выполняться следующие правила:

–правило балансировки - детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет связь детализируемая подсистема или процесс на родительской диаграмме;

–правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

•Мини-спецификация является конечной вершиной иерархии DFD.

•Решение о завершении детализации процесса и использовании мини-спецификации принимается аналитиком исходя из следующих критериев:

–наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

–возможности описания преобразования данных процессом в виде последовательного алгоритма;

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

–возможности описания логики процесса при помощи мини-спецификации небольшого объема (не более 20-30 строк).

Типы диаграмм в стандарте IDEF3

Диаграмма описания

последовательнос ти этапов процесса (Process Flow Description Diagrams,

PFDD)

Диаграмма состояний объекта и его трансформаций в процессе (Object State Transition Network, OSTN)

© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС

Нотации языка ER

В 1976 году Чен (Peter Chen), предложил модель "сущность-связь" (Entity- Relationship или ER-модель), которая в настоящее время стала основой методологии концептуального проектирования БД и методологии логического проектирования реляционных БД.

Известны также нотации Баркера (Barker) и IE (Information Engineering)

Нотация Баркера имеет отличительную особенность в виде оперения на одном из концов линии, связывающей объекты. Этот знак называют “воронья (гусиная) лапка” и он соответствует отношению “ко многим” между объектами

Обозначения, применяемые в диаграмме Баркера: “#” – первичный ключ или чисть первичного ключа, “*” – заполнение атрибута обязательно, “°” - атрибут дополнительный, т.е. заполнение атрибута не обязательно. Связь между таблицами-объектами может быть изображена в виде сложенной из двух отрезков линии. Если часть отрезка сплошная, то связь одной таблицы с другой (роль одного объекта по отношению к другому) - обязательная.

Значение знаков в нотации IE: “O” - заполнение атрибута не обязательно, например, отдел может не иметь на одного сотрудника, “|” – заполнение атрибута обязательно, “O|” – атрибут принимает самое большее одно значение (т.е. ни одного значения или одно значение), “||” - атрибут принимает только одно значение.

Язык ER был разработан для создания концептуальных моделей. Разработанная на его основе нотация relational используется для построения логической модели реляционной БД.

Обозначения применяемые в диаграммах на языке relational для типов значений в столбцах таблиц: PK (Primary Key) – первичный ключ, FK (Foreign Key) – внешний ключ, AK (Alternate Keys) – вторичный ключ, U (Unique) – уникальные значения, I (Index) - индекс.

Case-метод Баркера (ERD)

•Нотация ERD была впервые введена П. Ченом и получила развитие в работах Баркера. Основные шаги метода:

–выделение сущностей

–идентификация связей

–идентификация атрибутов

•Сущность (Entity) – объект предметной области, информация о котором подлежит хранению.

•Свойства сущности:

•должна иметь уникальное имя

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

•обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности

•может обладать любым количеством связей с другими сущностями модели

Моделирование данных

Пример модели в нотации Баркера - моделирование деятельности компании по торговле автомобилями. Исходная информация:

•цена и накладные расходы.

•кто из продавцов что продает и сколько машин продал каждый из них.

•год выпуска, марка, модель

•информация о покупателе, автомашине и продавце, поскольку именно контракты приносят продавцам вознаграждения за продажи

Первый шаг моделирования - выделение сущностей (Entity) - объектов, информация о которых накапливается.

Связь (Relationship) - поименованная ассоциация между двумя сущностями.

Связь продавца с контрактом :

•продавец может получить вознаграждение за 1 или более контрактов;

•контракт должен быть инициирован ровно одним продавцом.

Последним шагом моделирования является идентификация атрибутов.

Атрибут - характеристика сущности. Атрибут может быть либо обязательным (IS NOT NULL), либо необязательным.

Атрибут может быть либо описательным либо входить в состав уникального идентификатора (первичного ключа - "#" ).

Дополним построенную ранее диаграмму

Модель Чена		Модель Баркера: