- •Содержание
- •1 Выбор средств и методологии проектирования базы данных 5
- •2 Проектная разработка базы данных деятельности фирмы «недвижимость» г. Ливны 13
- •3 Создание базы данных деятельности в фирме «недвижимость» г. Ливны 24
- •Введение
- •1 Выбор средств и методологии проектирования базы данных
- •1.1 Основные понятия и определения баз данных и субд
- •1.2 Рынок недвижимости и его характеристики
- •1.3 Выбор средств разработки и создания базы данных
- •2 Проектная разработка базы данных деятельности фирмы «недвижимость» г. Ливны
- •2.1 Описание предметной области
- •2.2 Описание входной и выходной документации
- •3.3 Создание концептуальной модели предметной области
- •3.4 Создание физической модели базы данных
- •3 Создание базы данных деятельности в фирме «недвижимость» г. Ливны
- •Заключение
- •Список использованных источников
- •Приложения
3.3 Создание концептуальной модели предметной области
Исследование предметной области:
Для связи между объектами инфологической модели и для детализации предметной области необходимо ввести провести дальнейший анализ :
Выделение сущностей и их атрибутов
В данной предметной области можно выделить ряд объектов:
Сделка
Тип сделки
Сотрудник
Клиент
Владелец
Жилищный фонд
Город
Район
Тип дома
Сущность «Сделка» хранит данные об сделках агентства ( код, клиент, сотрудник, владелец, недвижимость, дата совершения, доп. инф, тип сделки)
Сущность «Тип сделки» хранит данные о типах сделки ( код, название, описание, комиссию)
Сущность «Сотрудник» хранит данные о сотрудниках( код, ФИО, дату приема, контактные данные )
Сущность «Клиент» хранит данные о клиентах ( код, ФИО, дату регистрации , контактные данные)
Сущность «Владелец» хранит данные о владельцах недвижимости ( код, ФИО, дату регистрации, контактные данные)
Сущность «Жилищный фонд» хранит данные об объектах недвижимости ( код, общую характеристику, цену, адрес, этажность , этаж, тип дома, район, фотографию)
Сущность «Город» хранит данные о городах( код, название, описание)
Сущность «Район» хранит данные о районах( код, название, находится в городе)
Сущность «Тип дома» хранит данные о типах домов в базе данных( код, название типа, описание)
Клиенты обращаются в Менеджер по продажам недвижимости и их конечной целью является заключение сделки. Каждая сделка может включать только одного клиента, каждый клиент может участвовать в нескольких сделках. Значит сущности «сделка» и «клиент» находятся в отношении многие-к-одному.
В сделках участвуют сотрудники агентства. Каждая сделка ведется только одним сотрудником агентства . Один и тот же менеджер агентства может вести несколько сделок. Сущности «сотрудник» относятся к сущности «сделка» как один-ко-многим.
Существуют различные типы сделок. Сделок каждого типа может быть несколько, но каждая сделка должна быть только одного типа. Значит сущности «сделка» и «тип сделки» находятся в отношении многие-к-одному.
В сделках участвуют объекты недвижимости. В каждой сделки участвует только одни объект. Один и тот же объект может быть участником многих сделок, а каждая сделка должна ссылаться только на один объект. Сущности «жилищный фонд» относятся к сущности «сделка» как один-ко-многим.
Каждый объект имеет адрес. Для предоставления удобства поиска разумно разбить адрес на составляющие. Каждый объект находится в микрорайоне ( отношение между сущностями «жилищный фонд» и «микрорайон» многие-к-одному) и каждый микрорайон находится в пределах одного города (отношение между сущностями «город» и «микрорайон» один-ко-многим).
На рисунке 6 приведена диаграмма «сущность-связь», демонстрирующая отношения между объектами системы.
Рисунок 6 ER-диаграмма системы в нотации Чена
После проведенного выделения объектов и их атрибутов можно обобщить все эти данные и провести связи между ними. Представление это можно сделать в более удобной для восприятия форме - в виде так называемой ER - диаграммы (диаграммы «сущность - связь»). Данная диаграмма построена с помощью программного CASE - средства ERWin 7.1.
Инфологическая модель данных по методологии проектирования IDEF1X изображена на рисунке 7.
Рисунок 7 - Схема данных
Контроль качества
Разработанная модель находится в 3-й нормальной форме, так как:
– атрибуты сущностей являются атомарными;
– каждый неключевой атрибут функционально полно зависит от первичного ключа;
– в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.
База была проверена в Erwin 7.1 validate.
