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

Введение

Проектирование баз знаний –  одно из важнейших направлений искусственного интеллекта. Системы искусственного интеллекта отличаются от обычных программ тем, что они оперируют не данными, а знаниями.

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

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

В наше время очень популярными  становятся бюро по недвижимости, так как они быстро и качественно выполняют различные виды услуг связанных с недвижимостью: покупка, продажа, обмен, аренда и др. А недвижимость – это одна из самых необходимых составляющих жизни современного человека. У современного человека слишком мало времени и возможностей для самостоятельного поиска подходящей квартиры, поэтому люди все чаще прибегают к услугам бюро.

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

 

1. Анализ предметной  области

1.1 Описание исходных данных, ключевых  сущностей и процессов, протекающих в предметной области

 

Предметная область – Бюро по недвижимости.

Наименование объекта: предприятие  по оказанию услуг с недвижимостью.

Объект автоматизации: комплекс задач  по организации и выполнению услуг  по работе с недвижимостью для  физических лиц (ФЛ).

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

Организационная структура объекта: администратор; риелторы.

Внешняя среда: заказы на услуги с  недвижимостью от ФЛ.

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

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

Продажа, покупка. Специалист, которому поручено выполнять заявку  на этот вид услуг выезжает на осмотр недвижимости. На основе результатов осмотра проводит оценку стоимости недвижимости (при покупке или продаже). При оценке недвижимости специалист использует свои справочники экспертных коэффициентов для расчета стоимости недвижимости (зависит от района, от года постройки дома, типа дома, состояния квартиры, метража квартиры, этажности дома и размещения квартиры и т.д.). Оценка стоимости согласовывается с клиентом. Если клиент не согласен с предложенной оценкой стоимости недвижимости, то за окончательную стоимость принимается стоимость, предложенная клиенту. Далее заключается договор на оказание определенной услуги клиенту (продажа или покупка недвижимости). В договоре определяют стоимость услуги  и другие атрибуты договора. Все договоры регистрируются в документации бюро. Специалист реализует поиск удовлетворительных вариантов продажи или покупки недвижимости в каталоге бюро. Возможные варианты обсуждаются с клиентом. Если удовлетворительные варианты сделки отсутствуют, то специалист осуществляет поиск вариантов для реализации сделки. При нахождении удовлетворительного варианта клиент оплачивает стоимость услуги по покупке или продаже недвижимости, указанную в договоре, и договор считается выполненным.

Обмен квартир. Возможны следующие  варианты обмена квартир: равноценный обмен; объединение двух квартир в одну: размен одной квартиры на две и другие варианты. Специалист, которому поручено выполнять обмен, выезжает на осмотр квартир. На основе результатов осмотра он проводит оценку стоимости квартир (аналогично продаже или покупке). Далее заключается договор на оказание определенной услуги клиенту (поиск варианта для обмена квартиры). Специалист реализует поиск удовлетворительных вариантов для обмена квартиры в каталоге бюро. Возможные варианты обсуждаются с клиентом. Если удовлетворительные варианты сделки отсутствуют, то специалист осуществляет поиск вариантов для реализации сделки. При нахождении удовлетворительного варианта обмена, клиент оплачивает стоимость услуги, указанную в договоре, и договор считается выполненным (вопросы оформления документов в работе не рассматриваются).

Сдача в аренду квартир.  В бюро создан и применяется справочник квартир жилого фонда бюро. Отдельная квартира в этом справочнике описывается следующими атрибутами: адрес квартиры, количество мест для проживания, стоимость проживания за сутки одного клиента (все удобства, кроме оплаты телефона), количество свободных мест.  Все места в одной квартире однотипные. Сдача в аренду возможна как в виде отдельного места в квартире (если в квартире более одного места), так и в виде нескольких или всех мест квартиры одному клиенту. В последнем случае клиент платит за все арендованные места в данной квартире. Один клиент может арендовать места в разных квартирах. Сдача мест в аренду оформляется в виде договора аренды (дата заключения договора, ФИО клиента, паспортные данные клиента, пол клиента, дата заселения, срок аренды в днях, номер квартиры, количество арендованных мест). При аренде одним жильцом номеров в разных квартирах для каждой квартиры оформляется отдельный договор. Оплата аренды клиентом осуществляется по окончании срока проживания (если срок менее недели) или еженедельно, если срок проживания более недели. При длительных сроках проживания (свыше месяца) клиент может производить оплату помесячно. Оплата производится в бюро. Для просроченных платежей за аренду начисляется пеня.

Примерный перечень сущностей: риелтор; заявка; клиент; договор; недвижимость; аренда; услуга; квитанция и другие сущности.

Срок хранения информации: определяет разработчик (не менее 5 лет).

Входная информация:

1. Справочники: квартир, стоимости услуг бюро, работников, клиентов и другие.
2. Заказ клиента на услугу, договор на оказание услуг клиенту, квитанция на оплату аренды, квитанция на оплату услуги.
3. Другие документы.

Выходная информация:

1. Формирование отчетных документов о деятельности бюро:

• отчет о стоимости услуг бюро (список услуг (наименование, описание, стоимость, сроки выполнения));

• отчет об операциях по продажам/покупкам квартир (по месяцам, по кварталам) (номер заказа, ФИО клиента, адрес квартиры, стоимость квартиры, дата выполнения операции); 
• отчет об операциях  обмена квартир (по месяцам, по кварталам) (номер заказа, ФИО клиента1, адрес квартиры1, ФИО клиента 2, адрес квартиры 2, стоимость операции, дата выполнения операции);
• отчет по справочнику  квартир бюро (за месяц, за квартал) (номер квартиры в каталоге, адрес, ФИО владельца, метраж, кол. комнат, этаж, район, тип дома, и др. характеристики)
• отчет о жилом фонде бюро (список квартир (адрес квартиры, метраж, кол. комнат, общая стоимость аренды в месяц);
• отчет о заключенных договорах на аренду квартир (за месяц, за квартал) (номер заказа, номер квартиры из фонда, ФИО заказчика, начало аренды, срок аренды);
• отчет о клиентах бюро (самостоятельно), об издательствах и объявлениях;

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

 

1.2 Описание действующих лиц предметной области и их взаимосвязей

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

1. Директор.
2. Сотрудник (риелтор).
3. Секретарь.
4. Клиент

 

 

 

 

 

 

 

 

Рисунок 1.1 – Организационная структура

 

1.3 Описание понятий и прецедентов.

Выделим прецеденты для базы данных:

• Отчет о клиентах бюро;
• Отчет о риелторах, работающих в бюро;
• Отчет о справочнике недвижимости;
• Отчет об предоставляемых бюро услугах;
• Отчет о поданных заявках;
• Отчет о заключенных договорах

Выделим из предметной области понятия, необходимые для разработки базы знаний:

• Эффективность бюро {средняя, высокая, низкая};
• Классификация жилых районов по популярности и перспективности продажи квартиры (выбор района для постройки жилого дома).
• Популярность жилых районов {большая, малая, средняя};
• Степень соответствия квартиры запросам клиента {подходящая, неподходящая, альтернативная};
• Возможность клиента продажи квартиры {высокая, средняя, низкая}.

Выделим задачи (прецеденты), которые  должна выполнять база знаний:

• Оценка эффективности работы бюро;
• Оценка изменения уровня достатка населения;
• Помощь клиенту в выборе квартиры для покупки (классификация по запросам клиента);
• Помощь клиенту в продаже квартиры;

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

 

2. Проектирование структуры  базы данных предметной области

2.1. Построение концептуальной  модели БД

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

1. Учет клиентов бюро (КМ1).
2. Учет недвижимости бюро (КМ2).
3. Учет операций продажи/покупки недвижимости (КМ3).

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

Таблица 2.1— Описание сущностей  по задачам

№ п/п		Имя сущности	Описание сущности	Псевдо-нимы	Особенности использования
КМ 1 -  Учет клиентов бюро
1	Клиент		Лицо, которому оказывает услуги бюро
2	Заявка		Заказ на оказание услуги	Заказ	У клиента может быть несколько  заявок
3	Услуга		Виды предоставляемых услуг  бюро		В заявке может быть описан только один вид требуемой услуги
КМ 2 -  Учет недвижимости бюро
4	Справочник		Недвижимости, которые есть в справочнике бюро	Недвижимость	У клиента может быть несколько  недвижимостей
5	Заявка		Заказ на оказание услуги	Заказ	У клиента может быть несколько  заявок
6	Клиент		Лицо, которому оказывает услуги бюро
7	Договор		Выполненный договор, заключается если сделка полностью завершена		Не  для всех заявок заключается  договор, а если заключается то только один
КМ 3 -  Учет операций продажи/покупки недвижимости
8	Заявка		Заказ на оказание услуги	Заказ	У клиента может быть несколько  заявок
9	Клиент		Лицо, которому оказывает услуги бюро
10	Договор		Выполненный договор, заключается если сделка полностью завершена		Не  для всех заявок заключается  договор, а если заключается то только один
17	Услуга		Виды предоставляемых услуг  бюро		В заявке может быть описан только один вид требуемой услуги
18	Риелтор		Сотрудник бюро		Сотрудник за определенный срок может  заключить несколько договоров

 

Далее определим связи, которые  существуют между отдельными сущностями в рамках каждой локальной КМ и представим их в табличной форме (таблица 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 повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами.