Проектирование базы данных на предприятии по оказанию услуг с недвижимостью
Построение концептуальной, реляционной и логической моделей базы данных (БД). Разработка онтологии в системе Protege. Выбор средств реализации БД. Проверка ее структуры и содержимого. Создание, загрузка и проверка БД в СУБД Microsoft SQL Server 2008.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 25.12.2012 |
Размер файла | 3,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
В магазинах процесс расчета прибыли и других отчетных документов является очень трудоемким процессом. Эта сложность объясняется тем, ежедневно в магазине обслуживают множество людей, а так же широким ассортиментом товара. В магазине есть администратор, который производит расчет на основании выполненного заказа о доставке или обслуживании клиентов. Все документы поступают в бухгалтерию, и потом производится расчет прибыли и формирование отчетных документов. Бухгалтерам приходится переписывать данные для расчетов.
Чтобы облегчить этот процесс можно разработать специальное приложение, которое позволит администратору вводить информацию для расчетов сразу в базу данных, бухгалтерам останется только проверить информацию и провести все необходимые расчеты. Это существенно облегчит работу бухгалтерии и а вычислительная техника автоматизирует процесс расчета прибыли и формирования отчетных документов.
1. Анализ предметной области
1.1 Описание исходных данных, ключевых сущностей и процессов, протекающих в предметной области
Наименование объекта: предприятие по продаже и доставке строительных материалов.
Объект автоматизации: комплекс задач по комплекс задач по организации и выполнению услуг по продаже и доставке строительных материалов для физических лиц.
Цель автоматизации: сокращение трудозатрат по ведению информации и отчетных документов при решении комплекса задач по организации и выполнению услуг по продаже и доставке строительных материалов
Организационная структура объекта: продавец, поставщик.
Внешняя среда: заказы на услуги физических лиц.
Функционирование объекта. Магазин строительных материалов А реализуют строительные материалы населению, а так же осуществляет возможность предварительного заказа определённых строительных материалов.
Магазин располагает большим ассортиментом строительных материалов от различных поставщиков.
Материалы можно приобрести непосредственно в магазине, с возможностью доставки в необходимое место. Если материалов нет в наличии можно сделать заказ.
При приобретении материалов покупатель указывает фамилию, имя, отчество, адрес и телефон. Оплата производится по наличному и без наличному расчёту.
Справочные услуги включают возможность расчёта необходимого количества строительного материала для отдельных видов строительных работ .
Примерный перечень сущностей: клиент; сотрудник; скидки; заказ; поставщик; товар; адрес и другие сущности.
Срок хранения информации: определяет разработчик (не менее 5 лет).
Входная информация:
1. Справочники: стоимость, ассортимент и поставщик строительных материалов, наличие на складе материалов.
2. Личные сведения о клиенте.
Выходная информация:
1. Строительные материалы.
2. Отчетные документы о деятельности магазина
§ отчет о имеющихся на складе материалов (их количество, марка, производитель);
§ отчет по заказе ( код заказа, код товара, количество, скидка, поставщик, клиент);
§ отчет о клиентах (ФИО, номер телефона, адрес, код заказа);
§ отчет о поставщиках (название поставщика, город адрес, товар);
§ отчет по возвращенным материалам (код заказа, код товара, количество, поставщик);
§ отчет о наличие на складе товаров (код товара, количество);
§ отчет о деятельности магазина (за день, за месяц) (проданные материалы (количество, общая стоимость).
1.2 Описание понятий и прецедентов
Выделим прецеденты для базы данных:
o Отчет о продаже строительных материалов.
o Отчет о клиентах магазина.
o Отчет о поставщике товара.
Выделим из предметной области понятия, необходимые для разработки базы знаний:
· Эффективность магазина {средняя, высокая, низкая};
· Классификация строительных материалов по популярности и перспективности продажи.
· Помощь клиенту в выборе строительных материалов;
· Определение самых хорошо продаваемых марок строительных материалов;
Выделим задачи (прецеденты), которые должна выполнять база знаний:
o Оценка эффективности работы магазина;
o Помощь клиенту в выборе строительных материалов для покупки (классификация по запросам клиента);
o Классификация строительных материалов по популярности и перспективности продажи;
o Определение самых популярных марок строительных материалов;
1.3 Создание семантической сети предметной области
Семантическая сеть - это концептуальная модель взаимосвязи понятий, где вершинами являются понятия, а ребрами - отношения между ними, позволяет получить целостную понятийную картину о предметной области.
Семантическая сеть нашей предметной области:
2. Проектирование структуры базы данных предметной области
2.1 Построение концептуальной модели БД
Определим перечень задач для построения КМ:
1. Отчет о продаже строительных материалов (КМ1).
2. Отчет о клиентах магазина(КМ2).
3. Отчет о поставщике товара(КМ3).
Определим основные информационные объекты, которые необходимы пользователю для решения задач из ПрО.
Таблица 2.1-- Описание сущностей по задачам
№ |
Имя сущности |
Описание сущности |
Особенности использования |
|
1 |
2 |
3 |
5 |
|
КМ 1 - Задача 1 - отчет о продаже строительных материалов |
||||
1 |
Сотрудник |
Сотрудник магазина |
Сотрудник за определенный срок может оформить несколько заказов |
|
2 |
Заказ |
Заказ на оказание услуги |
У клиента может быть несколько заказов |
|
3 |
Клиент |
Лицо, которому оказывает услуги бюро |
||
4 |
Сведения о заказе |
Описывает заказываемые товары |
||
КМ 2 - Задача 2 - отчет о клиентах магазина |
||||
5 |
Заказ |
Заказ на оказание услуги |
У клиента может быть несколько заказов |
|
6 |
Клиент |
Лицо, которому оказывает услуги бюро |
||
7 |
Товар |
Строительные материалы |
То что приобретает клиент |
|
КМ 3 - Задача 3 - отчет о поставщике товара |
||||
8 |
Поставщик |
Физическое или юридическое лицо поставляющие строительные материалы |
Один поставщик может поставлять несколько видов товара |
|
9 |
Товар |
Строительные материалы |
Далее определим связи, которые существуют между отдельными сущностями в рамках каждой локальной КМ и представим их в табличной форме.
Таблица 2.2-- Описание связей между сущностями по задачам
№ п/п |
Имя сущности |
Имя связи |
Имя сущности |
Кардинальность |
|
КМ 1 - Задача №1 |
|||||
1 |
Клиент |
Формирует |
Заказ |
1:N |
|
2 |
Сотрудник |
Оформляет |
Заказ |
1:N |
|
КМ 2 - Задача №2 |
|||||
4 |
Клиент |
Формирует |
Заказ |
1:N |
|
5 |
Заказ |
Включает |
Товар |
1:N |
|
КМ 3- Задача №3 |
|||||
6 |
Поставщик |
Поставляет |
Товар |
1:N |
Таблица 2.3-- Описание атрибутов
№ п/п |
Имя сущности или связи |
Атрибут |
Описание |
Тип данных длина |
Ограни-чения |
Допус-тимость NULL |
Про-изводный |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
1 |
Клиент |
Код клиента |
Уникальный идентификатор |
Числовой |
Первичный ключ |
Нет |
Нет |
|
Фамилия |
Текстовый |
Да |
Нет |
|||||
Имя |
Текстовый |
Да |
Нет |
|||||
Отчество |
Текстовый |
Да |
||||||
Адрес |
Текстовый |
Да |
Нет |
|||||
Номер телефона |
Числовой |
Да |
Нет |
|||||
2 |
Заказ |
Код заказа |
Уникальный идентификатор |
Числовой |
Первичный ключ |
Нет |
Нет |
|
Код клиента |
Уникальный идентификатор |
Числовой |
Нет |
Нет |
||||
Код сотрудника |
Уникальный идентификатор |
Числовой |
Нет |
Нет |
||||
Дата заказа |
Дата |
Да |
Нет |
|||||
Стоимость доставки |
Деньги |
Нет |
Нет |
|||||
Оплачено? |
Для определения оплаты(да/нет) |
Текстовый |
Нет |
Нет |
||||
Код товара |
Уникальный идентификатор |
Числовой |
Нет |
Нет |
||||
Количество |
Числовой |
Нет |
Нет |
|||||
Скидка |
Деньги |
Да |
Нет |
|||||
3 |
Поставщик |
Код поставщика |
Уникальный идентификатор |
Числовой |
Первичный ключ |
Нет |
Нет |
|
Название поставщика |
Текстовый |
Нет |
Нет |
|||||
Адрес |
Текстовый |
Да |
Нет |
|||||
4 |
Сотрудник |
Код сотрудника |
Уникальный идентификатор |
Числовой |
Первичный ключ |
Нет |
Нет |
|
Фамилия |
Текстовый |
Нет |
Нет |
|||||
Имя |
Текстовый |
Нет |
Нет |
|||||
Отчество |
Текстовый |
Нет |
Нет |
|||||
Должность |
Текстовый |
Нет |
Нет |
|||||
Номер телефона |
Текстовый |
Да |
Нет |
|||||
5 |
Товар |
Код товара |
Уникальный идентификатор |
Числовой |
Первичный ключ |
Нет |
Нет |
|
Наименование товара |
Текстовый |
Нет |
Нет |
|||||
Марка |
Текстовый |
Да |
Нет |
|||||
Единицы измерения |
Текстовый |
Нет |
Нет |
|||||
Код поставщика |
Уникальный идентификатор |
Числовой |
Нет |
Нет |
||||
На складе |
Числовой |
Нет |
Нет |
|||||
Цена |
Деньги |
Нет |
Нет |
Определим и опишем домены атрибутов Домен атрибута - это набор значений, который может быть присвоен атрибуту.
Таблица 2.4-- Описание доменов
№ п/п |
Имя домена |
Характеристики домена |
Примеры допустимых значений |
|
1 |
Код клиента |
Целое число |
От 1 до 100000 |
|
2 |
Фамилия |
Текст |
От 2 до 50 символов |
|
3 |
Имя |
Текст |
От 2 до 50 символов |
|
4 |
Отчество |
Текст |
От 5 до 50 символов |
|
5 |
Адрес |
Текст |
От 10 до 50 символов |
|
6 |
Номер телефона |
Целое число |
От 100000 до 9999999 |
|
7 |
Код заказа |
Целое число |
От 1 до 100000 |
|
8 |
Код клиента |
Целое число |
От 1 до 100000 |
|
9 |
Код сотрудника |
Целое число |
От 1 до 100000 |
|
10 |
Дата заказа |
В форме даты |
От 01.01.1000 до 01.01.3000 |
|
11 |
Стоимость доставки |
Денежное представление |
От 1$ до 100000$ |
|
12 |
Оплачено? |
Текст |
Да, нет |
|
13 |
Код поставщика |
Целое число |
От 1 до 100000 |
|
14 |
Название поставщика |
Текст |
От 2 до 50 символов |
|
15 |
Адрес |
Текст |
От 10 до 50 символов |
|
16 |
Код сотрудника |
Целое число |
От 1 до 100000 |
|
17 |
Фамилия |
Текст |
От 2 до 50 символов |
|
18 |
Имя |
Текст |
От 2 до 50 символов |
|
19 |
Отчество |
Текст |
От 5 до 50 символов |
|
20 |
Должность |
Текст |
От 5 до 50 символов |
|
21 |
Номер телефона |
Целое число |
От 100000 до 9999999 |
|
22 |
Код заказа |
Целое число |
От 1 до 100000 |
|
23 |
Код товара |
Целое число |
От 1 до 100000 |
|
24 |
Количество |
Целое число |
От 1 до 100000 |
|
25 |
Скидка |
Денежное представление |
От 1$ до 100000$ |
|
26 |
Код товара |
Целое число |
От 1 до 100000 |
|
27 |
Наименование товара |
Текст |
От 2 до 50 символов |
|
28 |
Марка |
Текст |
От 2 до 50 символов |
|
29 |
Единицы измерения |
Текст |
От 2 до 50 символов |
|
30 |
Код поставщика |
Целое число |
От 1 до 100000 |
|
31 |
На складе |
Целое число |
От 1 до 100000 |
|
32 |
Цена |
Денежное представление |
От 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 |
Прои-зводн-ный |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
Клиент |
|||||||||
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.
Microsoft 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 повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами. база данные онтология реляционный
2.7 Физическая реализация БД
2.7.1 Проектирование таблиц для выбранной СУБД
Таблица 2.6 - Заказ
Имя поля |
Тип поля |
Длина поля |
|
Код_заказа |
Int |
4 byte |
|
Код_клиента |
Int |
4 byte |
|
Код_сотрудника |
Int |
4 byte |
|
Дата_заказа |
Date |
8 byte |
|
Стоимость_доставки |
Money |
16 byte |
|
Оплачено |
varchar(20) |
20 символов |
|
Код_товара |
Int |
4 byte |
|
Количество |
Int |
4 byte |
|
Скидка |
Money |
16 byte |
Таблица 2.7 - Клиент
Имя поля |
Тип поля |
Длина поля |
|
Код_клиента |
varchar(20) |
20 символов |
|
Фамилия |
varchar(20) |
20 символов |
|
Имя |
varchar(20) |
20 символов |
|
Отчество |
varchar(20) |
20 символов |
|
Адрес |
varchar(50) |
50 символов |
|
Номер_телефона |
Int |
4 byte |
Таблица 2.8 - Сотрудник
Имя поля |
Тип поля |
Длина поля |
|
Код_сотрудника |
Int |
4 byte |
|
Фамилия |
varchar(20) |
20 символов |
|
Имя |
varchar(20) |
20 символов |
|
Отчество |
varchar(20) |
20 символов |
|
Должность |
varchar(20) |
20 символов |
|
Номер_телефона |
Int |
4 byte |
Таблица 2.9 - Поставщик
Имя поля |
Тип поля |
Длина поля |
|
Код_поставщика |
Int |
4 byte |
|
Название_поставщика |
varchar(50) |
50 символов |
|
Адрес |
varchar(50) |
50 символов |
Таблица 2.10 - Товар
Имя поля |
Тип поля |
Длина поля |
|
Код_товара |
Int |
4 byte |
|
Наименование_товара |
varchar(50) |
50 символов |
|
Марка |
varchar(50) |
50 символов |
|
Единицы_измерения |
varchar(20) |
20 символов |
|
Код_поставщика |
Int |
4 byte |
|
На_складе |
Int |
4 byte |
|
Цена |
Money |
16 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 - Формы приложения
Номер формы |
Название формы |
Назаначение формы |
|
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 |
Форма, отображающая отчёт о товаре |
Структуру ПО приложения представим в виде рисунка (рис. 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. Проектирование структуры БЗ
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 - Классификация марок строительных материалов.
Итак, разработанная система полностью покрывает запросы к базе знаний.
Оценим эффективность разработанной экспертной системы по следующим параметрам:
1. Полнота построения БЗ.
Система имеет все множество взаимосвязей между понятиями, позволяющих вывести и выразить большую часть знаний предметной области.
2. Непротиворечивость БЗ.
В системе отсутствуют явно взаимоисключающие правила, не являющиеся спецификой предметной области.
3. Лаконичность описания.
В системе отсутствует дублирование и выделены наиболее значащие продукции.
4. Целесообразность БЗ.
БЗ решает все поставленные перед ней задачи, а именно: задача классификации, прогнозирования и принятия решений.
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.
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
Подобные документы
Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Построение концептуальной модели, процесс моделирования смыслового наполнения базы данных. Основные компоненты концептуальной модели. Построение реляционной модели. Целостность данных в реляционной базе. Нормализация. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Автоматизация работы пользователя по поиску, просмотру и редактированию информации о работниках, соискателях, вакансиях. Построение информационно-логической и физической моделей данных. Создание базы данных в СУБД MS SQL Server. Описание SQL запросов.
курсовая работа [1,8 M], добавлен 07.08.2013Исследование логической структуры реляционной базы данных на основе инфологической модели и её реализации в программе Microsoft SQL Server 2000. Характеристика разработки вложенных запросов на выборку записей, процедур, триггеров, создания представлений.
реферат [1,2 M], добавлен 11.05.2012Построение инфологической (концептуальной) модели предметной области. Проектирование логической и физической структуры базы данных. Реализация проекта в среде конкретной СУБД. Организация корректировки и ввода данных в БД. Разработка интерфейса.
курсовая работа [1,4 M], добавлен 14.01.2018Программные продукты, используемые при проектировании базы данных. Разработка базы данных "Библиотека" с использование программного проекта Microsoft SQL Server. Создание таблиц, триггеров, пользователей, репликации, запросов, функций, процедур.
курсовая работа [897,6 K], добавлен 21.11.2011Сущность базы данных. Процесс построения концептуальной модели. Построение реляционной модели, создание ключевого поля. Процесс нормализации. Проектирование базы данных в ACCESS. Порядок создание базы данных. Создание SQL запросов и работа в базе данных.
курсовая работа [185,6 K], добавлен 08.11.2008Типы моделей данных: реляционная, иерархическая и сетевая. Описание концептуальной модели реляционной базы данных. Разработка базы данных в СУБД Microsoft Access, ее премущества и недостатки, составные компоненты, описание и обоснование полей таблиц.
курсовая работа [62,6 K], добавлен 09.03.2009Разработка базы данных средствами СУБД Microsoft SQL Server 2008. Исследование понятия первичного и внешнего ключа. Реляционные отношения между таблицами базы данных. Ссылочная целостность и каскадные воздействия. Проектирование запросов и триггеров.
курсовая работа [1,0 M], добавлен 27.05.2015Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.
курсовая работа [3,6 M], добавлен 18.06.2012