Назначение диаграмм потоков данных

Построение DFD-диаграмм в основном ассоциируется с разработкой программного

обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В

частности, графическое изображение объектов

12.3

В DFD каждый номер функционального блока может включать в себя префикс, номер

родительской диаграммы и собственно номер объекта (рис. 3.9). Номер объекта

уникальным образом идентифицирует функциональный блок на диаграмме. Номер

родительской диаграммы и номер объекта в совокупности обеспечивают уникальную

идентификацию каждого блока модели.

Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней

сущности вне зависимости от расположения. Каждый номер хранилища содержит

префикс D (от английского Data Store) и уникальный номер хранилища в модели

(например, D3).

Основные элементы модели

Основные компоненты DFD

· внешние сущности;

· системы/подсистемы;

· процессы;

· накопители данных;

· потоки данных.

· Основные элементы DFD

· Основные элементы DFD

Внещние сущности

Обозначаются прямоугольником в обеих существующих нотациях (Йордона-ДеМарко и Гейна-Сарсона).

Внешняя сущность — это материальный объект, находящийся за пределами нашей систем.

Системы/подсистемы

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

Процесс

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

Накопитель данных

Накопитель данных служит для хранения и извлечения данных. Данные могут поступать в накопитель только через процесс и извлекаться тоже через процесс. Накопитель должен иметь как минимум один входной и один выходной поток.

Поток данных

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

14.1 по 19.1 Моделирование данных. Методология IDEF1X.

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

выполняемых системой, так и на описание объектов, составляющих систему.

Если в первом случае методология SADT предназначена для построения

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

действий и связей между этими действиями, то во втором случае методология SADT

предназначена для описания объектов, входящих в систему, их свойств и взаимосвязей

между ними. Фактически, во втором случае методология SADT служит для описания

модели данных на языке и в терминах реляционной модели данных. Методология SADT,

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

методология IDEF1X. CASE средства, в частности ERwin, поддерживающие эту

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

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

которая может быть трансформирована в любую реляционную СУБД и описана на языке

описания данных этой СУБД. CASE средство ERwin, например, поддерживает более 20

СУБД, на языке описания данных которых может быть сгенерирована физическая

модель данных.

14.2 и 15.2 Проектирование реляционной модели

Основные понятия реляционной модели.

Данные в реляционной модели хранятся в виде таблиц.

Таблица состоит из заголовка (столбцов или атрибутов) и строк или записей(кортежей).

Поле таблицы - это значение, лежащее на пересечении строки и столбца.

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

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

Реляционные таблицы называются отношениями. (Relation – отношение).

Число столбцов или атрибутов таблицы называется степенью отношения.

Число строк или записей таблицы называется мощностью отношения.