Проектирование базы данных на предприятии по оказанию услуг с недвижимостью

 

Введение

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

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

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

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

Наименование объекта: предприятие по продаже и доставке строительных материалов.

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

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

Организационная структура объекта: продавец, поставщик.

Внешняя среда: заказы на услуги физических лиц.

Функционирование объекта. Магазин строительных материалов А реализуют строительные материалы населению, а так же осуществляет возможность предварительного заказа определённых строительных материалов.

Магазин располагает большим ассортиментом строительных материалов от различных поставщиков.

Материалы можно приобрести непосредственно в магазине, с возможностью доставки в необходимое место. Если материалов нет в наличии можно сделать заказ.

При приобретении материалов покупатель указывает фамилию, имя, отчество, адрес и телефон. Оплата производится по наличному и без наличному расчёту.

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

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

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

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

1.Справочники: стоимость, ассортимент и поставщик строительных материалов, наличие на складе материалов.

2.Личные сведения о клиенте.

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

1.Строительные материалы.

2.Отчетные документы о деятельности магазина

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

§отчет по заказе ( код заказа, код товара, количество, скидка, поставщик, клиент);

§отчет о клиентах (ФИО, номер телефона, адрес, код заказа);

§отчет о поставщиках (название поставщика, город адрес, товар);

§отчет по возвращенным материалам (код заказа, код товара, количество, поставщик);

§отчет о наличие на складе товаров (код товара, количество);

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

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

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

oОтчет о продаже строительных материалов.

oОтчет о клиентах магазина.

oОтчет о поставщике товара.

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

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

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

·Помощь клиенту в выборе строительных материалов;

·Определение самых хорошо продаваемых марок строительных материалов;

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

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

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

oКлассификация строительных материалов по популярности и перспективности продажи;

oОпределение самых популярных марок строительных материалов;

1.3 Создание семантической сети предметной области

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

Семантическая сеть нашей предметной области:

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

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

Определим перечень задач для построения КМ:

.Отчет о продаже строительных материалов (КМ1).

.Отчет о клиентах магазина(КМ2).

.Отчет о поставщике товара(КМ3).

Определим основные информационные объекты, которые необходимы пользователю для решения задач из ПрО.

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

№ Имя сущностиОписание сущностиОсобенности использования1235КМ 1 - Задача 1 - отчет о продаже строительных материалов1СотрудникСотрудник магазинаСотрудник за определенный срок может оформить несколько заказов2ЗаказЗаказ на оказание услугиУ клиента может быть несколько заказов3КлиентЛицо, которому оказывает услуги бюро4Сведения о заказеОписывает заказываемые товарыКМ 2 - Задача 2 - отчет о клиентах магазина5ЗаказЗаказ на оказание услугиУ клиента может быть несколько заказов6КлиентЛицо, которому оказывает услуги бюро7ТоварСтроительные материалыТо что приобретает клиентКМ 3 - Задача 3 - отчет о поставщике товара8ПоставщикФизическое или юридическое лицо поставляющие строительные материалыОдин поставщик может поставлять несколько видов товара 9ТоварСтроительные материалы

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

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

№ п/пИмя сущностиИмя связиИмя сущностиКардинальностьКМ 1 - Задача №11КлиентФормируетЗаказ1:N2СотрудникОформляет Заказ1:NКМ 2 - Задача №24КлиентФормируетЗаказ1:N5ЗаказВключаетТовар1:NКМ 3- Задача №36ПоставщикПоставляетТовар1:N

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

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

Определим и опишем домены атрибутов Домен атрибута - это набор значений, который может быть присвоен атрибуту.

Таблица 2.4- Описание доменов

№ п/пИмя доменаХарактеристики доменаПримеры допустимых значений1Код клиентаЦелое числоОт 1 до 1000002ФамилияТекстОт 2 до 50 символов3ИмяТекстОт 2 до 50 символов4ОтчествоТекстОт 5 до 50 символов5Адрес ТекстОт 10 до 50 символов6Номер телефонаЦелое числоОт 100000 до 9999999 7Код заказаЦелое числоОт 1 до 1000008Код клиентаЦелое числоОт 1 до 1000009Код сотрудникаЦелое числоОт 1 до 10000010Дата заказаВ форме датыОт 01.01.1000 до 01.01.300011Стоимость доставкиДенежное представлениеОт 1$ до 100000$12Оплачено?ТекстДа, нет13Код поставщикаЦелое числоОт 1 до 10000014Название поставщикаТекстОт 2 до 50 символов15АдресТекстОт 10 до 50 символов16Код сотрудникаЦелое числоОт 1 до 10000017ФамилияТекстОт 2 до 50 символов18ИмяТекстОт 2 до 50 символов19ОтчествоТекстОт 5 до 50 символов20ДолжностьТекстОт 5 до 50 символов21Номер телефонаЦелое числоОт 100000 до 9999999 22Код заказаЦелое числоОт 1 до 10000023Код товараЦелое числоОт 1 до 100000 24КоличествоЦелое числоОт 1 до 10000025СкидкаДенежное представлениеОт 1$ до 100000$26Код товараЦелое числоОт 1 до 10000027Наименование товараТекстОт 2 до 50 символов28МаркаТекстОт 2 до 50 символов29Единицы измеренияТекстОт 2 до 50 символов30Код поставщикаЦелое числоОт 1 до 10000031На складеЦелое числоОт 1 до 10000032ЦенаДенежное представлениеОт 1$ до 100000$

Далее опишем каждый отчет и составим для него диаграмму «сущность-связь».

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

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

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

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

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

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

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

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

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

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

Опишем отношения логической модели базы данных. Каждое отдельное отношение представим в виде отдельного описания и представим это в табличном виде:

Таблица 2.5 - Описания отношений

№ п/пИмя атрибутаТип атрибута (ключевой, неключевой)ОписаниеТип данных и длинаОграни-ченияЗначение по умолчаниюДопус-тимостьNULLПрои-зводн-ный123456789 Клиент1Код клиентаПервичный ключУникальный идентификатор клиентаЧисловой,6Первичный ключнетнетнет2ФамилияПростойФамилия клиентаТекстовый, 50нетда нет3ИмяПростойИмя клиентаТекстовый, 50нетданет4ОтчествоПростойОтчество клиентаТекстовый, 50нетданет5Адрес ПростойАдрес клиентаТекстовый, 50нетданет6Номер телефонаПростойНомер телефона клиентаЧисловой, 12нетданетЗаказ7Код заказаПервичный ключУникальный идентификатор заказаЧисловой,6Первичный ключнетнетнет8Код клиентаВнешний ключУникальный идентификатор клиентаЧисловой,6нетнетнет9Код сотрудникаВнешний ключУникальный идентификатор сотрудникаЧисловой,6нетнетнет10Дата заказаПростойДата поступления заявкиДатанетданет11Стоимость доставкиПростойСтоимость за доставкуДенежныйнетнетнет12Оплачено?ПростойСведения об уплате за заказТекстовый, 10нетнетнет13Код товараВнешний ключУникальный идентификатор товараЧисловой,6нетДанет14КоличествоПростойКоличество заказанного товараЧисловой,6нетНетнет15СкидкаПростойСкидка предоставляемая на товарДенежныйнетДанетПоставщик16Код поставщикаПервичный ключУникальный идентификатор поставщикаЧисловой,6Первичный ключнетнетнет17Название поставщикаПростойНазвание организации, которая поставляет товарТекстовый, 50нетнетнет18АдресПростойАдрес организации, которая поставляет товар Текстовый, 50нетданетСотрудник19Код сотрудникаПервичный ключУникальный идентификатор сотрудникаЧисловой,6Первичный ключнетнетнет20ФамилияПростойФамилия сотрудникаТекстовый, 50нетнетнет21ИмяПростойИмя сотрудникаТекстовый, 50нетнетнет22ОтчествоПростойОтчество сотрудникаТекстовый, 50нетнетнет23ДолжностьПростойДолжность занимаемая сотрудникомТекстовый, 50нетнетнет24Номер телефонаПростойРабочий телефон сотрудникаЧисловой, 12нетданетТовар25Код товараПервичный ключУникальный идентификатор поставщикаЧисловой,6Первичный ключнетнетнет26Наименование товараПростойНазвание товараТекстовый, 50нетнетнет27МаркаПростойПроизводитель товараТекстовый, 50нетданет28Единицы измеренияПростойКаким образом измеряется товарТекстовый, 10нетнетнет29Код поставщикаВнешний ключУникальный идентификатор поставщикаЧисловой,6нетнетнет30На складеПростойКоличество товара на складеЧисловой, 12нетнетнет31ЦенаПростойСтоимость товараДенежныйнетнетнет

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

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

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

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

?Удалить из концептуальной модели нежелательные элементы.

?Уточнить отношения для логической модели базы данных.

?Построить набор предварительных таблиц и указать первичные ключи.

?Провести процесс нормализации.

?Выполнить проверку выполнимости задач пользователя.

?Выполнить проверку целостности данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогично для таблицы Поставщик, имеющей атрибут .

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

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

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

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

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

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

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

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

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

2.6 Выбор средств реализации БД

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

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

·Полная Web ориентированность. Осуществление запросов, анализ и управление данными через Web. Использование языка XML для обмена данными между удаленными системами. Простой и безопасный доступ к данным с помощью Web - браузеров, быстрый поиск необходимых документов. Анализ потоков данных и получение информации о пользователях, в том числе и через Web.

·Масштабируемость и надежность. SQL Server 2008 обеспечивает практически неограниченный рост объемов хранения данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. Это безопасная, надежная, масштабируемая платформа, защищающая информацию в приложениях и повышающая её доступность. Включенная в неё инновационная инфраструктура управления, основанная на политиках, позволяет определять политики для явного и автоматического администрирования серверных сущностей на одном или нескольких серверах. Кроме того, оптимизированная платформа SQL Server 2005 открывает путь к предсказуемой производительности обработки запросов. Инфраструктура SQL Server 2005 стала более масштабируемой. Она способна формировать отчеты и выполнять анализ любого объема и сложности, одновременно облегчая пользователям доступ к данным за счет более тесной интеграции с Microsoft Office. В результате ИТ-специалисты могут распространить использование бизнес-аналитики по всей организации. SQL Server 2005 позволяет пользователям консолидировать разнородные данные в корпоративном хранилище, выводя организацию хранилищ данных на новый уровень.

·Скорость создания решений. SQL Server 2008 в сочетании с .NET Framework уменьшает время разработки, внедрения и выхода на рынок современных приложений, ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях, предоставляет широкие возможности для создания Web-приложений. Среда ADO.NET Entity Framework повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами. база данные онтология реляционный

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

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

Таблица 2.6 - Заказ

Имя поляТип поляДлина поляКод_заказаInt4 byteКод_клиентаInt 4 byteКод_сотрудникаInt4 byteДата_заказаDate8 byteСтоимость_доставкиMoney16 byteОплаченоvarchar(20)20 символовКод_товараInt4 byteКоличествоInt4 byteСкидкаMoney16 byte

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

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

Таблица 2.8 - Сотрудник

Имя поляТип поляДлина поляКод_сотрудникаInt4 byteФамилияvarchar(20)20 символовИмяvarchar(20)20 символовОтчествоvarchar(20)20 символовДолжностьvarchar(20)20 символовНомер_телефонаInt 4 byte

Таблица 2.9 - Поставщик

Имя поляТип поляДлина поляКод_поставщикаInt4 byteНазвание_поставщикаvarchar(50)50 символовАдресvarchar(50)50 символов

Таблица 2.10 - Товар

Имя поляТип поляДлина поляКод_товараInt4 byteНаименование_товараvarchar(50)50 символовМаркаvarchar(50)50 символовЕдиницы_измеренияvarchar(20)20 символовКод_поставщикаInt4 byteНа_складеInt 4 byteЦенаMoney16 byte

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

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

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

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

Рисунок 2.9 - Таблица «Заказ»

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

Рисунок 2.11 - Таблица «Поставщик»

Рисунок 2.12 - Таблица «Сотрудник»

Рисунок 2.13 - Таблица «Товар»

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

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

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

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

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

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

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

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

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

Рисунок 2.16 - Интерфейс окна обработки таблицы Заказ.

Рисунок 2.17 - Интерфейс окна обработки таблицы Клиент.

Рисунок 2.18 - Интерфейс окна обработки таблицы Поставщик.

Рисунок 2.19 - Интерфейс окна обработки таблицы Сотрудник.

Рисунок 2.20 - Интерфейс окна обработки таблицы Товар.

Рисунок 2.21 - Интерфейс окна для сортировки, поиска и фильтрации данных в таблице Заказ.

Рисунок 2.22 - Интерфейс окна для сортировки, поиска и фильтрации данных в таблице Клиент.

Рисунок 2.23 - Интерфейс окна для сортировки, поиска и фильтрации данных в таблице Поставщик.

Рисунок 2.24 - Интерфейс окна для сортировки, поиска и фильтрации данных в таблице Сотрудник.

Рисунок 2.25 - Интерфейс окна для сортировки, поиска и фильтрации данных в таблице Товар.

Рисунок 2.26 - Интерфейс окна для вывода отчета таблицы Заказ.

Рисунок 2.27 - Интерфейс окна для вывода отчета таблицы Клиент.

Рисунок 2.28 - Интерфейс окна для вывода отчета таблицы Поставщик.

Рисунок 2.29 - Интерфейс окна для вывода отчета таблицы Сотрудник.

Рисунок 2.30 - Интерфейс окна для вывода отчета таблицы Товар.

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

3. Проектирование структуры БЗ

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

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

·Оценка эффективности работы магазина строительных материалов;

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

·Помощь клиенту в выборе строительных материалов;

·Определение самых хорошо продаваемых марок строительных материалов;

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

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

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

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

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

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

üЕсли процент удовлетворенных заказов > 80 и время удовлетворения заявки <1 дня, то магазин работает эффективно;

üЕсли процент удовлетворенных заказов > 50, но <=80, и время удовлетворения заявки <1 дня, или процент удовлетворенных заявок > 80 и среднее время удовлетворения заявки от 1 до 3 дней, то эффективность работы магазина средняя;

üЕсли процент удовлетворенных заказов < 80 и среднее время удовлетворения заявки > 3 дней, то магазин работает неэффективно;

üЕсли процент покупки строительного материала >40, то этот материал популярный;

üЕсли процент покупки строительного материала <40, но > 20, этот материал имеет среднюю популярность;

üЕсли процент покупки строительного материала <20, то этот материал непопулярный;

üЕсли материал подходит клиенту по качеству, фасону, производителю и цене, то материал подходящий;

üЕсли материал подходит клиенту по качеству, фасону, но не подходит производитель и отличается в цене не более чем на 5000, то квартира альтернативная;

üЕсли материал не подходит клиенту по качеству или фасону, или отличается в цене более чем на 5000, то материал неподходящий;

üЕсли процент покупки строительного материала данной марки >40, то эта марка популярная;

üЕсли процент покупки строительного материала данной марки <40, но > 20,то эта марка имеет среднюю популярность;

üЕсли процент покупки строительного материала данной марки <20, то эта марка непопулярная;

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

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

Рисунок 3.1 - Оценка эффективности работы магазина.

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

Рисунок 3.2 - Классификация строительных материалов.

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

Рисунок 3.3 - Классификация строительных материалов по степени соответствия запросам клиента.

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

Рисунок 3.2 - Классификация марок строительных материалов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3.1 - Основные классы БЗ.

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

Рисунок 3.2 - Слоты для класса Материалы->Проданные.

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

Рисунок 3.3 - Слоты для класса Материалы ->На_складе.

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

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

Слоты для класса Материалы->Заказанные_клиентами представлены на рисунке 3.5.

Рисунок 3.5 - Слоты для класса Материалы->Заказанные_клиентами.

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

Рисунок 3.6 - Слоты для класса Заказы.

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

Рисунок 3.7 - Экземпляры класса Заказы.

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

Рисунок 3.8 - Экземпляры класса Материалы->Заказанные_у_поставщика.

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

Рисунок 3.9 - Экземпляры класса Материалы->Проданные.

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

Рисунок 3.10 - Экземпляры класса Материалы->Заказанные_клиентами.

Экземпляры класса Материалы ->На_складе представлены на рисунке 3.11.

Рисунок 3.11 - Экземпляры класса Материалы ->На_складе.

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

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

Рисунок 3.12 -Оценка эффективности работы магазин.

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

Рисунок 3.14 - Классификация строительных материалов по популярности и перспективности продажи.

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

Рисунок 3.15 -Выбор материалов клиентом.

Проверим выполнимость четвертого прецедента - Определение самых хорошо продаваемых марок строительных материалов. На рисунках 3.13 представлены результаты запроса, который характеризует как самую продаваемую марку OOO «Берёзакерамик».

Рисунок 3.16 - Классификация марок строительных материалов по продажи.

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. http://www.allbest.ru/

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

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

Больше работ по теме: