-
Диаграмма потоков данных (dfd-диаграмма)
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов (далее в примерах используется нотация Гейна-Сэрсона).
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла.
Рис. 4 Диаграмма потоков данных
-
Концептуальное проектирование данных
Концептуальную модель часто называют ER–моделью. Ее предложил Петер Пин-Шен Чен в 1976 г. Построение концептуальной модели заключается в выделении объектов и установлении между ними связей. Список объектов для предметной области “ Автошкола ” будет выглядеть так:
Автошкола, договор, инструктор, транспорт, ученик, личная карточка, квитанция об оплате, картотека. На основе имеющихся документов для каждого объекта прописываем атрибуты:
-
автошкола (ИНН, лицензия, название, адрес, телефон, собственник);
-
договор (№ договора, дата заключения, цель заключения);
-
инструктор (№ инструктора, пол, ФИО, квалификация, телефон);
-
транспорт (№ транспорта, марка, пробег);
-
ученик (№ ученика, ФИО, паспортные данные, адрес, телефон);
-
личная анкета (№ анкеты, категория обучения, экзамен теория, экзамен практика, количество часов);
-
квитанция об оплате (№ квитанции, дата оплаты, сумма);
-
картотека (№ карточки, дата поступления);
После определения объектов и их атрибутов проставим мощности между объектами:
Между объектами автошкола и договор максимальная мощность связи 1:N, т.е. каждая автошкола может иметь несколько договоров, один договор может быть в автошколе в единственном экземпляре;
Между объектами автошкола и инструктор максимальная мощность связи 1:N, т.е. каждая автошкола может иметь несколько инструкторов, один инструктор может работать только в одной автошколе;
Между объектами картотека и анкета работодателя максимальная мощность связи 1:N, т.е. анкета хранится в одной картотеке;
Между объектами инструктор и транспорт максимальная мощность связи N:N, т.е. один инструктор может преподавать на разных машинах, а одна машина может быть использована несколькими инструкторами;
Между объектами ученик и инструктор максимальная мощность 1:N, т.е. у одного ученика может быть только один инструктор, а один инструктор может преподавать нескольким ученикам одновременно;
Между объектами ученик и квитанция об оплате максимальная мощность 1:N, т.е. у одного ученика может быть несколько квитанций, а одна квитанция принадлежит только одному ученику;
Между объектами ученик и личная анкета максимальная мощность 1:1, т.е. у одного ученика может быть одна анкета, а одна анкета принадлежит только одному ученику;
Между объектами личная анкета и картотека максимальная мощность 1:N, т.е. одна анкета хранится в одной картотеке, а одна картотека может хранить несколько анкет;
Рис.5 Концептуальная модель базы данных «Автошкола»