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

 

2.6.1. Проектирование таблиц  для выбранной СУБД

Приведем описание структуры таблиц для выбранной СУБД.

 

Таблица 2.6 - Недвижимость

Имя поля	Тип поля	Длина поля
Номер_недвижимости	Int	4 byte
Тип_недвижимости	varchar(20)	20 символов
Адрес	varchar(50)	50 символов
Стоимость	Money	8 byte
Площадь	Float	8 byte
ФИО_владельца	varchar(50)	50 символов

Таблица 2.7 - Риелтор

Имя поля	Тип поля	Длина поля
Номер_риелтора	Int	4 byte
ФИО_риелтора	varchar(50)	50 символов
Рабочий телефон	Int	4 byte

Таблица 2.8 - Клиент

Имя поля	Тип поля	Длина поля
Номер_клиента	Int	4 byte
ФИО_клиента	varchar(50)	50 символов
Телефон	Int	4 byte
Номер_паспорта	varchar(10)	10 символов

Таблица 2.9 - Услуга

Имя поля	Тип поля	Длина поля
Номер_услуги	Int	4 byte
Название	varchar(20)	20 символов
Описание	varchar(80)	80 символов
Стоимость	Money	16 byte

Таблица 2.10 - Заявка

Имя поля	Тип поля	Длина поля
Номер_заявки	Int	4 byte
Номер_клиента	Int	4 byte
Номер_услуги	Int	4 byte
Дата_поступления	Date	8 byte

Таблица 2.11 - Договор

Имя поля	Тип поля	Длина поля
Номер_договора	Int	4 byte
Номер_недвижимости	Int	4 byte
Номер_риелтора	Int	4 byte
Номер_заявки	Int	4 byte
Дата_сделки	Date	8 byte

 

Физическая модель БД в SQL Server 2005 представлена ниже:

Рисунок 2.9 – Физическая модель БД в SQL Server 2005.

 

2.7. Создание, загрузка и проверка БД

Создали БД в СУБД Microsoft SQL Server 2005. После создания БД перешли к процессу создания таблиц. Все созданные нами таблицы представлены на рисунках, расположенных ниже.

 

Рисунок 2.10 – Таблица «Недвижимость»

Рисунок 2.11 – Таблица «Риелтор»

Рисунок 2.12 – Таблица «Клиент»

Рисунок 2.13 – Таблица «Услуга»

Рисунок 2.14 – Таблица «Заявка»

Рисунок 2.15 – Таблица «Договор»

 

Разработаем массив данных для загрузки в БД и представим его в табличном  виде (табл. 2.12-2.17).

 

Таблица 2.12 – Массив данных для загрузки в таблицу «Договор»

 

Таблица 2.13 – Массив данных для загрузки в таблицу «Клиент»

 

Таблица 2.14 – Массив данных для загрузки в таблицу «Риелтор»

 

Таблица 2.15 – Массив данных для  загрузки в таблицу «Недвижимость»

 

Таблица 2.16 –  Массив данных для загрузки в таблицу «Услуга»

 

Таблица 2.17 – Массив данных для загрузки в таблицу «Заявка»

 

Интерфейс (главное окно) приложения представлен на рисунке 2.16

Рисунок 2.16 – Интерфейс приложения.

 

Разработанные в приложении формы представлены в таблице 2.12.

 

Таблица 2.18 – Формы приложения

Номер формы	Название формы	Назаначение формы
1	Form1	На данной форме расположено  основное меню приложения
2	Form2	Форма, позволяющая редактировать, удалять, добавлять договоры
3	Form3	Форма, позволяющая редактировать, удалять, добавлять заявки
4	Form4	Форма, позволяющая редактировать, удалять, добавлять клиентов
5	Form5	Форма, позволяющая редактировать, удалять, добавлять недвижимость
6	Form6	Форма, позволяющая редактировать, удалять, добавлять риелторов
7	Form7	Форма, позволяющая редактировать, удалять, добавлять услуги
8	Form8	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в договорах
9	Form9	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в заявках
10	Form10	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в клиентах
11	Form11	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в недвижимости
12	Form12	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в риелторах
13	Form13	Форма, позволяющая сортировать, фильтровать, осуществлять поиск в услугах
14	Form14	Форма, отображающая отчёт о договорах
15	Form15	Форма, отображающая отчёт о заявках
16	Form16	Форма, отображающая отчёт о клиентах
17	Form17	Форма, отображающая отчёт о недвижимости
18	Form18	Форма, отображающая отчёт о риелторах
19	Form19	Форма, отображающая отчёт о услугах

Структуру ПО приложения представим в виде рисунка (рис. 2.17), на котором отобразим все компоненты приложения (формы) и связи между ними.

 

 Рисунок 2.17 – Структура ПО приложения

 

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

Результат работы программы представлен ниже.

Рисунок 2.18 – Интерфейс окна обработки таблицы “Недвижимость”.

 

Обработка таблиц “Договор”, “Заявка”, “Услуга”, “Клиент”, “Риелтор” производится аналогично таблице “Недвижимость”.

 

Рисунок 2.19 – Интерфейс окна для сортировки, поиска и фильтрации данных в таблице “Недвижимость”.

 

Сортировка, поиск и фильтрация данных таблиц “Договор”, “Заявка”, “Услуга”, “Клиент”, “Риелтор” производится аналогично таблице “Недвижимость”.

Рисунок 2.20 – Интерфейс окна для вывода отчета таблицы “Недвижимость”.

 

Вывод отчета таблиц “Договор”, “Заявка”, “Услуга”, “Клиент”, “Риелтор” производится аналогично таблице “Недвижимость”.

Как видно  из рисунков 2.18 - 2.20 полученные данные совпадают с эталонными, следовательно, работа базы данных осуществляется корректно.

 

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

3.1 Проектирование экспертной  системы по предметной области

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

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

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

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

Разработаем множество продукционных  правил «если…, то…»  функционирования нашей экспертной системы:

• Если процент удовлетворенных заявок > 80 и время удовлетворения заявки <6 месяцев, то бюро работает эффективно;
• Если процент удовлетворенных заявок > 50, но <=80, и время удовлетворения заявки <6 месяцев, или процент удовлетворенных заявок > 80 и среднее время удовлетворения заявки  от 6 до 10  месяцев, то эффективность работы  бюро средняя;
• Если процент удовлетворенных заявок < 80 и среднее время удовлетворения заявки > 10 месяцев, то бюро работает неэффективно;
• Если процент покупки квартир в данном районе >40, то район популярный;
• Если процент покупки квартир в данном районе <40, но > 20, то район имеет среднюю популярность;
• Если процент покупки квартир в данном районе <20, то район непопулярный;
• Если количество заявок на покупку квартиры в данном районе > 3, шанс продажи высокий;
• Если количество заявок на покупку квартиры в данном районе < 3, но >=1 шанс продажи средний;
• Если количество заявок на покупку квартиры в данном районе < 1, шанс продажи низкий;
• Если квартира подходит клиенту по количеству комнат, району, типу дома и цене, то квартира подходящая;
• Если квартира подходит клиенту по количеству комнат, району, но не подходит по типу дома и отличается в цене не более чем на 5000, то квартира альтернативная;
• Если квартира не подходит клиенту по количеству комнат или району, или отличается в цене более чем на 5000, то квартира неподходящая;
• Если количество купленных квартир за анализируемый год по сравнению с предшествующим возросло более чем на 20 процентов, уровень достатка населения увеличился;
• Если количество купленных квартир за анализируемый год по сравнению с предшествующим упало более чем на 20 процентов, уровень достатка населения снизился;
• Если увеличение/уменьшение покупки квартир по сравнению с предыдущим годом не превысило 20 процентов, уровень достатка населения стабилен.

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

Дерево решений для первого  прецедента представлено на рисунке 3.1.