Бюро по недвижимости

 

Далее определим связи, которые  существуют между отдельными сущностями в рамках каждой локальной КМ и представим их в табличной форме (таблица 2.2).

 

Таблица 2.2 - Описание связей между  сущностями по задачам

№ п/п	Имя сущности	Имя связи	Имя сущности	Кардинальность
КМ 1
1	Клиент	Составляет	Заявки	1:N
2	Услуга	Присутствует в	Заявке	1:1
КМ 2
3	Клиент	составляет	Заявки	1:N
4	Заявка	Присутствует в	Договоре	1:1
5	Недвижимость(Справочник)	Продается по	Договору	1:1
КМ 3
7	Клиент	Составляет	Заявки	1:N
8	Заявка	Присутствует в	Договоре	1:1
9	Услуга	Присутствует в	Заявке	1:1
11	Риелтор	Составляет	Договоры	1:N

 

Построим диаграмму «сущность-связь» для первой подзадачи (рис. 2.1):

 

Рисунок 2.1 –  Диаграмма «сущность связь» подзадачи 1

 

Построим диаграмму «сущность-связь» для второй подзадачи (рис. 2.2).

 

Рисунок 2.2 –  Диаграмма «сущность связь» подзадачи 2

Построим диаграмму «сущность-связь» для третьей задачи (рис. 2.3).

 

Рисунок 2.3 –  Диаграмма «сущность связь» подзадачи 3

Объединенная  концептуальная модель 1-ой и 2-ой задачи приведена на рисунке 2.4.

Рисунок 2.4 – Результат объединения КМ1 и КМ2 в КМ1_2

 

Объединив КМ1_1 и КМ3 получим результирующую концептуальную модель (рис. 2.5).

Таким образом, результатом объединения  локальных концептуальных моделей из предметной области является единая концептуальная модель структуры БД в виде единой диаграммы "сущность-связь". Эта модель содержит концептуальное отражение представлений пользователя о предметной области.

Рисунок 2.5- Концептуальная модель БД.

 

2.3. Построение логической модели БД

Определим атрибуты и представим их в табличной  форме (табл. 2.3).

Таблица 2.3 - Описание атрибутов

№ п/п	Имя сущности или связи	Атрибут	Тип данных
1	2	3	4
1	Недвижимость	Номер недвижимости	Числовой
		Тип недвижимости	Текстовый
		Адрес	Текстовый
		Стоимость	Денежный
		Площадь	Числовой
		ФИО владельца	Текстовый
2	Риелтор	Номер риелтора	Числовой
		ФИО риелтора	Текстовый
		Рабочий телефон	Числовой
3	Клиент	Номер клиента	Числовой
		ФИО клиента	Текстовый
		Телефон	Числовой
		Номер паспорта	Текстовый
4	Услуга	Номер услуги	Числовой
		Название	Текстовый
		Описание	Текстовый
		Стоимость	Денежный
5	Заявка	Номер заявки	Числовой
		Номер услуги	Числовой
		Номер клиента	Числовой
		Дата поступления	Дата
6	Договор	Номер договора	Числовой
		Номер недвижимости	Числовой
		Номер риелтора	Числовой
		Номер заявки	Числовой
		Дата сделки	Дата

 

Логическая  модель БД представлена на рис. 2.6.

 

 

Рисунок 2.6 – Логическая модель БД

2.4. Построение  реляционной модели БД

Преобразование логической модели в реляционную состоит в следующем:

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

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

 

 Рисунок 2.7 – Набор предварительных  таблиц

 

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

Детальные описания ключей и атрибутов  выносится в отдельные таблицы:

 

Таблица 2.4 - Описания ключей.

№ п/п	Имя сущности	Первичный ключ	Альтернативный ключ
1	Недвижимость	Номер недвижимости
2	Риелтор	Номер риелтора
3	Клиент	Номер клиента
4	Услуга	Номер услуги
5	Заявка	Номер заявки
6	Договор	Номер договора

 

 

Таблица 2.5 - Описание атрибутов

№ п/п	Имя сущности или связи	Имя атрибута	Назначение атрибута	Тип данных (длина)	Ограни- чения	Значение по умолчанию	Псевдоним	Допустимость NULL	Произ-водный
1	Недвижимость	Номер недвижимости	Уникальный идентификатор	Целый	Первичный ключ	Нет	Нет	Нет	Нет
		Тип недвижимости		Строковый		Нет	Нет	Нет	Нет
		Адрес		Строковый		Нет	Нет	Нет	Нет
		Стоимость		Денежный		Нет	Нет	Нет	Нет
		Площадь		Вещественный		Нет	Нет	Нет	Нет
		ФИО владельца		Строковый		Нет	Нет	Да	Нет
2	Риелтор	Номер риелтора	Уникальный идентификатор	Целый	Первичный ключ	Нет	Нет	Нет	Нет
		ФИО риелтора		Строковый		Нет	Нет	Нет	Нет
		Рабочий телефон		Целый		Нет	Нет	Нет	Нет
3	Клиент	Номер клиента	Уникальный идентификатор	Целый	Первичный ключ	Нет	Нет	Нет	Нет
		ФИО клиента		Строковый		Нет	Нет	Нет	Нет
		Телефон		Целый		Нет	Нет	Нет	Нет
		Номер паспорта		Строковый		Нет	Нет	Нет	Нет
4	Услуга	Номер услуги	Уникальный идентификатор	Целый	Первичный ключ	Нет	Нет	Нет	Нет
		Название		Строковый		Нет	Нет	Нет	Нет
		Описание		Строковый		Нет	Нет	Да	Нет
		Стоимость		Денежный		Нет	Нет	Нет	Нет
5	Заявка	Номер заявки		Целый		Нет	Нет	Нет	Нет
		Номер услуги		Целый		Нет	Нет	Нет	Нет
		Номер клиента		Целый		Нет	Нет	Нет	Нет
		Дата поступления		Дата		Нет	Нет	Нет	Нет
6	Договор	Номер договора	Уникальный идентификатор	Целый	Первичный ключ	Нет	Нет	Нет	Нет
		Номер недвижимости		Целый		Нет	Нет	Нет	Нет
		Номер риелтора		Целый		Нет	Нет	Нет	Нет
		Номер заявки		Целый		Нет	Нет	Нет	Нет
		Дата сделки		Дата		Нет	Нет	Нет	Нет

 

2.5. Нормализация полученных  таблиц

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

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

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

Основное назначение нормальной формы  – приведение структуры БД к виду, обеспечивающему минимальную избыточность.

Выделяют 5 нормальных форм:

● 1НФ - первая нормальная форма

● 2НФ - вторая нормальная форма

● 3НФ - третья нормальная форма

● НФБК - нормальная форма Бойса-Кодда

● 4НФ - четвертая нормальная форма

● 5НФ - пятая нормальная форма

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

Для реляционных баз данных необходимо, чтобы ее таблицы находились в 1НФ. Нормальные формы более высоких  уровней могут использоваться разработчиками по своему усмотрению. На практике обычно используют 3 нормальные формы.

Первая нормальная форма

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

Для того, чтобы принять решение о разбиении атрибута на части, следует ответить на вопрос: будут ли части атрибута использоваться по отдельности, если да – разделяем.

Проанализировав набор предварительных  таблиц, видим, что таблица Недвижимость имеет атрибуты ФИО_владельца и Адрес, которые в общем случае не являются атомарными. Атрибут ФИО_владельца можно разделить на 3: Фамилия, Имя, Отчество, - а атрибут Адрес можно разделить на: Город, Улица, Дом. Части атрибутов ФИО_владельца и Адрес не будут использоваться по отдельности, поэтому их будем считать атомарными, а таблицу Недвижимость – приведенной к первой нормальной форме.

Аналогично для таблиц Риелтор  и Клиент, имеющих атрибуты ФИО_риелтора и ФИО_клиента соответственно.

Все остальные таблицы приведены  к первой нормальной форме.

Вторая нормальная форма

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

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

Третья нормальная форма

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

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

Подведем итог. БД была составлена правильно и после нормализации не изменилась:

 

Рисунок 2.8 - Реляционная модель БД

Таким образом, логическая модель была преобразована в реляционную.

 

2.6 Физическая реализация  БД

Для реализации БД была выбрана СУБД Microsoft SQL Server 2005.

Microsoft SQL Server 2005 представляет новое поколение масштабируемых решений в области систем управления базами и хранилищ данных для задач, требующих быстрого получения и анализа информации.  

Преимущества Microsoft SQL Server 2005:

• Полная Web ориентированность. Осуществление запросов, анализ и управление данными через Web. Использование языка XML для обмена данными между удаленными системами. Простой и безопасный доступ к данным с помощью Web - браузеров, быстрый поиск необходимых документов. Анализ потоков данных и получение информации о пользователях, в том числе и через Web.
• Масштабируемость и надежность. SQL Server 2005 обеспечивает практически неограниченный рост объемов хранения данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. Это безопасная, надежная, масштабируемая платформа, защищающая информацию в приложениях и повышающая её доступность. Включенная в неё инновационная инфраструктура управления, основанная на политиках, позволяет определять политики для явного и автоматического администрирования серверных сущностей на одном или нескольких серверах. Кроме того, оптимизированная платформа SQL Server 2005 открывает путь к предсказуемой производительности обработки запросов. Инфраструктура SQL Server 2005 стала более масштабируемой. Она способна формировать отчеты и выполнять анализ любого объема и сложности, одновременно облегчая пользователям доступ к данным за счет более тесной интеграции с Microsoft Office. В результате ИТ-специалисты могут распространить использование бизнес-аналитики по всей организации. SQL Server 2005 позволяет пользователям консолидировать разнородные данные в корпоративном хранилище, выводя организацию хранилищ данных на новый уровень.
• Скорость создания решений. SQL Server 2005 в сочетании с .NET Framework уменьшает время разработки, внедрения и выхода на рынок современных приложений, ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях, предоставляет широкие возможности для создания Web-приложений. Среда ADO.NET Entity Framework повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами.