Проектирование баз знаний "Бюро по недвижимости"

Размещено на http://www.allbest.ru/

Содержание

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Разработка онтологии

3.3 Проверка базы знаний

Заключение

Список сокращений

Список использованных источников

Введение

проектирование база данные предметный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Справочники: квартир, стоимости услуг бюро, работников, клиентов и другие.

2. Заказ клиента на услугу, договор на оказание услуг клиенту, квитанция на оплату аренды, квитанция на оплату услуги.

3. Другие документы.

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

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

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

§ отчет об операциях по продажам/покупкам квартир (по месяцам, по кварталам) (номер заказа, ФИО клиента, адрес квартиры, стоимость квартиры, дата выполнения операции);

§ отчет об операциях обмена квартир (по месяцам, по кварталам) (номер заказа, ФИО клиента1, адрес квартиры1, ФИО клиента 2, адрес квартиры 2, стоимость операции, дата выполнения операции);

§ отчет по справочнику квартир бюро (за месяц, за квартал) (номер квартиры в каталоге, адрес, ФИО владельца, метраж, кол. комнат, этаж, район, тип дома, и др. характеристики)$

§ отчет о жилом фонде бюро (список квартир (адрес квартиры, метраж, кол. комнат, общая стоимость аренды в месяц);

§ отчет о заключенных договорах на аренду квартир (за месяц, за квартал) (номер заказа, номер квартиры из фонда, ФИО заказчика, начало аренды, срок аренды);

§ отчет о клиентах бюро (самостоятельно), об издательствах и объявлениях;

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

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

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

1. Директор.

2. Сотрудник (риелтор).

3. Секретарь.

4. Клиент

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

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

o Отчет о клиентах бюро;

o Отчет о риелторах, работающих в бюро;

o Отчет о справочнике недвижимости;

o Отчет об предоставляемых бюро услугах;

o Отчет о поданных заявках;

o Отчет о заключенных договорах.

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

· Эффективность бюро {средняя, высокая, низкая};

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

· Популярность жилых районов {большая, малая, средняя};

· Степень соответствия квартиры запросам клиента {подходящая, неподходящая, альтернативная};

· Возможность клиента продажи квартиры {высокая, средняя, низкая}.

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

o Оценка эффективности работы бюро;

o Оценка изменения уровня достатка населения;

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

o Помощь клиенту в продаже квартиры;

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

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.2).

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

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

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

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

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

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

Таблица 2.3

Описание атрибутов

№ п/п	Имя сущности или связи	Атрибут	Тип данных
1	2	3	4
1	Недвижимость	Номер недвижимости	Числовой
		Тип недвижимости	Текстовый
		Адрес	Текстовый
		Стоимость	Денежный
		Площадь	Числовой
		ФИО владельца	Текстовый
2	Риелтор	Номер риелтора	Числовой
		ФИО риелтора	Текстовый
		Рабочий телефон	Числовой
3	Клиент	Номер клиента	Числовой
		ФИО клиента	Текстовый
		Телефон	Числовой
		Номер паспорта	Текстовый
4	Услуга	Номер услуги	Числовой
		Название	Текстовый
		Описание	Текстовый
		Стоимость	Денежный
5	Заявка	Номер заявки	Числовой
		Номер услуги	Числовой
		Номер клиента	Числовой
		Дата поступления	Дата
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 повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами.

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.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), на котором отобразим все компоненты приложения (формы) и связи между ними.

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

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

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

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

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

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

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

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

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

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

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

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

· Оценка эффективности работы бюро;

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

· Помощь клиенту в продаже квартиры;

· Оценка изменения уровня достатка населения;

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

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

o Эффективность бюро {средняя, высокая, низкая};

o Изменение уровня достатка населения {увеличение, уменьшение, стабильность};

o Популярность жилых районов {большая, малая, средняя};

o Степень соответствия квартиры запросам клиента {подходящая, неподходящая, альтернативная};

o Возможность клиента продажи квартиры {высокая, средняя, низкая}.

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

ь Если процент удовлетворенных заявок > 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.

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

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

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

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

Итак, разработанная система полностью покрывает запросы к базе знаний.

Оценим эффективность разработанной экспертной системы по следующим параметрам:

1. Полнота построения БЗ.

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

2. Непротиворечивость БЗ.

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

3. Лаконичность описания.

В системе отсутствует дублирование и выделены наиболее значащие продукции.

4. Целесообразность БЗ.

БЗ решает все поставленные перед ней задачи, а именно: задача классификации, прогнозирования и принятия решений.

3.2 Разработка онтологии

Для разработки онтологии воспользуемся системой Protйgй. Protйgй является платформо-независимой расширяемой средой для создания баз знаний на основе фреймовой модели. Она позволяет быстро и интуитивно создавать свои онтологии.

Создадим классы, необходимые для решения заданных задач БЗ. Разработанные классы представлены на рисунке 3.1.

Для каждого разработанного класса создадим свои слоты. Слоты для класса Квартиры->Купленные представлены на рисунке 3.2.

Слоты для класса Квартиры->Проданные представлены на рисунке 3.3.

Слоты для класса Квартиры->Заявки_на_покупку представлены на рисунке 3.4.

Слоты для класса Квартиры->Каталог_на_продажу представлены на рисунке 3.5.

Слоты для класса Заявки представлены на рисунке 3.6.

Перейдем от онтологии к базе знаний, заполнив классы соответствующими экземплярами. Экземпляры для класса Заявки представлены на рисунке 3.7.

Экземпляры класса Квартиры->Каталог_на_продажу представлены на рисунке 3.8.

Экземпляры класса Квартиры->Заявки_на_покупку представлены на рисунке 3.9.

Экземпляры класса Квартиры->Купленные представлены на рисунке 3.10.

Экземпляры класса Квартиры->Проданные представлены на рисунке 3.11.

3.3 Проверка базы знаний

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

Проверим выполнимость второго прецедента - Оценка изменения уровня достатка населения. На рисунках 3.13 - 3.14 представлены результаты запроса, характеризующего покупку квартир в 2010 и 2011 годах.

Проверим выполнимость третьего прецедента - Помощь клиенту в выборе квартиры для покупки (классификация по запросам клиента). На рисунках 3.15 представлены результаты запроса по предпочтениям клиента.

Проверим выполнимость четвертого прецедента - Помощь клиенту в продаже квартиры. На рисунках 3.16 представлены результаты запроса, который характеризует возможность клиента продать квартиру.

Из результатов запроса видно, что у клиента шанс продать квартиру невелик.

Проверим выполнимость пятого прецедента - Классификация жилых районов по популярности и перспективности продажи квартиры (выбор района для постройки жилого дома). На рисунках 3.17 представлены результаты запроса, который характеризует целесообразность постройки дома в районе «Восток».

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

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

Заключение

В результате выполнения курсового проекта был изучен объект автоматизации - предприятие по оказанию услуг с недвижимостью. Была спроектирована база данных для данного предприятия и приложение для работы с этой базой данных. База данных была реализована в программе Microsoft SQL Server, а приложения в среде программирования - C#.

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

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

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

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

Список сокращений

ФЛ - физические лица.

ФИО - фамилия, имя, отчество.

КМ - концептуальная модель.

НФ - нормальная форма.

БД - база данных.

СУБД - система управления базами данных.

БЗ - база знаний.

ПО - программное обеспечение.

Список использованных источников

1. "ПБД. Лабораторная работа №1. Проектирование баз данных". БрГТУ, ИИТ, 2011.

2. "ПБЗ. Лабораторная работа №3. Построение онтологии в системе Protйgй". БрГТУ, ИИТ, 2011.

3. Д.И. Муромцев. Онтологический инжиниринг знаний в системе Protйgй. Методическое пособие. - ИТМО, Санкт-Петербург, 2007.

4. http://www.allbest.ru/.

5. http://window.edu.ru/resource/225/65225/files/150.pdf.

Размещено на Allbest.ru

...