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

На диаграммах обозначаются прямоугольником со скругленными углами и подписываются по названию работы (рис. 14).



Рисунок 14 – Отображение работы на DFD диаграмме
Потоки данных отображаются стрелками и обозначают движение данных. Стрелки с данными могут подходить к любой стороне блока и отходить от любой стороны блока. Могут быть двунаправленными – это обозначает запрос-ответ.

Накопители данных отображаются прямоугольниками (рисунок 3). Накопители данных описывают данные в покое, когда они дожидаются какой-либо обработки. Это пассивный объект в составе DFD, в котором данные сохраняются для последующего доступа.

Эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.


Рисунок 15 – Отображение накопителей данных на DFD диаграммах.

3. Инфологическая (концептуальная) модель предметной области
Концептуальная модель отображает предметную область в виде взаимосвязанных объектов без указания способов их физического хранения. Концептуальная модель представляет интегрированные концептуальные требования всех пользователей к базе данных данной предметной области.

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

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

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

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

Анализ определенных выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель на языке "Сущность-связь" (см. рисунок 1).

---

Рис.1. Инфологическая модель «Сущность-связь»

4. Логическая модель данных
4.1 Выбор системы управления базами данных
За последние несколько лет вырос уровень потребительских качеств систем управления базами данных (СУБД): разнообразие поддерживаемых функций, удобный для пользователя интерфейс, сопряжение с программными продуктами, в частности с другими СУБД, возможности для работы в сети и т.д. СУБД позволяет сводить воедино информацию из самых разных источников (электронные таблицы, другие базы данных) и помогает быстро найти необходимую информацию, донести ее до окружающих с помощью отчетов, графиков или таблиц.

СУБД Microsoft Access является системой управления реляционной базой данных, включающей все необходимые инструментальные средства для создания локальной базы данных, общей базы данных в локальной сети с файловым сервером или создания приложения пользователя, работающего с базой данных на SQL- сервере. Microsoft Access входит в состав MS Office, что делает его интерфейс знакомым и привычным, а, следовательно, облегчает работу.

Для Microsoft Access характерны следующие возможности:

наличие мощных команд обработки файлов;

удобные средства ввода-вывода;

управление дизайном экрана (окна, цвет, звук, рамки);

удобный вывод данных на экран, бумагу, текстовый файл;

развитый аппарат обработки символьных данных;

интеграция с другими приложениями; 

импорт-экспорт.

Access имеет характерный для всех приложений Microsoft Windows удобный графический интерфейс, ориентированный на комфортную работу пользователя. Для работы с таблицами базы данных и другими объектами Access предоставляет многочисленные команды меню и контекстно-зависимые панели инструментов. Поскольку интерфейс приложений Microsoft Office унифицирован, пользователю требуется меньше времени на освоение приложения.

Для разработки базы данных выбрана СУБД Microsoft Access.
4.2 Выявление сущностей базы данных
В результате обследования ПО были выявлены следующие сущности:

Квартира (информация о квартирах, сдаваемых в аренду);

Фотокаталог (дополнительная информация о квартирах и их фотографии);

Владелец (информация о владельцах квартир);

Наниматель (информация о арендаторах);

Договор (информация о заключенных договорах с арендаторами);

Договор с агентством (информация о заключенных договорах с владельцами квартир);

---

Тариф (информация о тарифах агентства);

Агент (информация об агентах);

Пользователь (информация о пользователях базы данных).

Определяем атрибуты для каждой сущности:

Квартира (Код квартиры, владелец, тип аренды, тип дома, район, адрес, количество комнат, жилая площадь, этаж, спальных комнат, ванных комнат, санузел, телефон, интернет/Wi-Fi, кабельное телевидение, стоимость аренды, предоплата %, документ, подтверждающий право собственности, сдана в найм);

Фотокаталог (код квартиры, фото №1, фото №2, фото №3, схема квартиры, этажность, балкон и лоджия, подсобные помещения, год постройки, мебель, бытовая техника, дополнительная информация, общая площадь, год капитального ремонта, номер стационарного телефона, пароль от Wi-Fi);

Владелец (код владельца, ФИО, адрес постоянной регистрации, серия паспорта, номер паспорта, дата выдачи паспорта, орган, выдавший паспорт, телефон);

Наниматель (Код нанимателя, ФИО, адрес постоянной регистрации, серия паспорта, номер паспорта, дата выдачи, орган выдачи паспорта, телефон);

Договор (номер договора, квартира, владелец, наниматель, сожители, дата заключения, срок действия (месяцев));

Договор с агентством (номер договора, владелец, квартира, агент, тариф, дата заключения);

Тариф (код тарифа, название, количество комнат, вознаграждение);

Агент (код агента, ФИО, дата рождения, адрес, телефон, % от вознаграждения);

Пользователь (код пользователя, имя пользователя, пароль, доступ, агент).

Связи сущностей:

Сущность «Квартира» связывается с сущностью «Фотокаталог» через соединение атрибута «Код квартиры» из сущности «Квартира» с атрибутом «Код квартиры» из сущности «Фотокаталог».

Сущность «Квартира» связывается с сущностью «Владелец» через соединение атрибута «Владелец» из сущности «Квартира» с атрибутом «Код владельца» из сущности «Владелец».

Сущность «Квартира» связывается с сущностью «Договор» через соединение атрибута «Код квартиры» из сущности «Квартира» с атрибутом «Квартира» из сущности «Договор».

Сущность «Квартира» связывается с сущностью «Договор с агентством» через соединение атрибута «Код квартиры» из сущности «Квартира» с атрибутом «Квартира» из сущности «Договор с агентством».

Сущность «Владелец» связывается с сущностью «Договор» через соединение атрибута «Код владельца» из сущности «Владелец» с атрибутом «Владелец» из сущности «Договор».

---

Сущность «Наниматель» связывается с сущностью «Договор» через соединение атрибута «Код нанимателя» из сущности «Наниматель» с атрибутом «Наниматель» из сущности «Договор».

Сущность «Агент» связывается с сущностью «Договор с агентством» через соединение атрибута «Код агента» из сущности «Агент» с атрибутом «Агент» из сущности «Договор с агентством».

Сущность «Тариф» связывается с сущностью «Договор с агентством» через соединение атрибута «Код тарифа» из сущности «Тариф» с атрибутом «Тариф» из сущности «Договор с агентством».

Сущность «Агент» связывается с сущностью «Пользователь» через соединение атрибута «Код агента» из сущности «Агент» с атрибутом «Агент» из сущности «Пользователь».

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


5. Физическая модель базы данных
5.1 Отображение концептуальной схемы на логическую схему
Цель этапа - создание базы данных в СУБД Access согласно разработанной реляционной модели данных.

Отобразим концептуальную схему, изображенную на рис.1, на реляционную модель. Каждая сущность этой схемы будет представлена в виде таблицы. Каждый столбец таблицы предназначен для записи одного атрибута и имеет свое уникальное имя.

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения.

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

Представим сущность Квартира (Код квартиры, владелец, тип аренды, тип дома, район, адрес, количество комнат, жилая площадь, этаж, спальных комнат, ванных комнат, санузел, телефон, интернет/Wi-Fi, кабельное телевидение, стоимость аренды, предоплата %, документ, подтверждающий право собственности, сдана в найм) в виде таблицы и определим ее структуру (см. таблицу 1).
Таб. 1. Структура таблицы «Квартира»

Признак ключа	Поле	Тип поля
ключ	Код квартиры	Счетчик
	Владелец	Числовой
	Тип аренды	Короткий текст
	Тип дома	Короткий текст
	Район	Короткий текст
	Адрес	Длинный текст
	Количество комнат	Числовой
	Жилая площадь	Числовой
	Этаж	Числовой
	Спальных комнат	Числовой
	Ванных комнат	Числовой
	Санузел	Короткий текст
	Телефон	Логический
	Интернет/Wi-Fi	Логический
	Кабельное телевидение	Логический
	Предоплата %	Числовой
	Документ, подтверждающий право собственности	Длинный текст
	Сдана в найм	Логический

---

Представим сущность Фотокаталог (код квартиры, фото №1, фото №2, фото №3, схема квартиры, этажность, балкон и лоджия, подсобные помещения, год постройки, мебель, бытовая техника, дополнительная информация, общая площадь, год капитального ремонта, номер стационарного телефона, пароль от Wi-Fi (см. таблицу 2).
Таб. 2. Структура таблицы «Фотокаталог»

Признак ключа	Поле	Тип поля
ключ	Код квартиры	Числовой
	Фото №1	Поле объекта OLE
	Фото №2	Поле объекта OLE
	Фото №3	Поле объекта OLE
	Схема квартиры	Поле объекта OLE
	Этажность	Числовой
	Балконы и лоджии	Короткий текст
	Подсобные помещения	Короткий текст
	Год постройки	Числовой
	Мебель	Длинный текст
	Бытовая техника	Длинный текст
	Дополнительная информация	Длинный текст
	Общая площадь	Числовой
	Год капитального ремонта	Числовой
	Номер стационарного телефона	Короткий текст
	Пароль от Wi-Fi	Короткий текст

Представим сущность Наниматель (Код нанимателя, ФИО, адрес постоянной регистрации, серия паспорта, номер паспорта, дата выдачи, орган выдачи паспорта, телефон (см. таблицу 3).
Таб. 3. Структура таблицы «Наниматель»

Признак ключа	Поле	Тип поля
ключ	Код нанимателя	Счетчик
	ФИО	Короткий текст
	Адрес постоянной регистрации	Длинный текст
	Серия паспорта	Числовой
	Номер паспорта	Числовой
	Дата выдачи	Дата и время
	Орган выдачи паспорта	Длинный текст
	Телефон	Короткий текст

---

Смотрите также файлы

• Процедуры и функции, определенные пользователем.docx

• Контрольные задания по теме.docx

• Соотнесите высказывание о конфликте с его.pdf

• Курсовая работа по дисциплине Организация инженерной защиты населения и территорий.docx

• УДк 299. 513Doi ив. Белая.pdf