Проектирование баз знаний "Гостиничная система"

 

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

 

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

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

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

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

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

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

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

Детальные описания ключей и атрибутов выносится в отдельные таблицы:

Таблица 2.4 - Описания ключей.

№ п/п	Имя сущности	Первичный ключ	Альтернативный  ключ
1	Номер	Код_номера
2	Портье	Код_портье
3	Клиент	Код_клиента
4	Услуга	Код_услуги
5	Заявка	Код_заявки
6	Договор	Код_договора

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проанализировав набор предварительных таблиц, видим, что таблица Клиент  имеет атрибут  ФИО_клиента который в общем случае не является атомарным. Атрибут ФИО_клиента можно разделить на 3: Фамилия, Имя, Отчество. Части атрибута ФИО_владельца не будут использоваться по отдельности, поэтому их будем считать атомарными, а таблицу Клиент– приведенной к первой нормальной форме.

Аналогично  для таблицы Портье имеющей атрибут  ФИО_портье.

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

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

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

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

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

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

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

 

Подведем итог. БД была составлена правильно и после нормализации не изменилась:

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

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

 

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

Для реализации БД была выбрана  СУБД Microsoft SQL Server 2005.

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

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

• Полная Web ориентированность. Осуществление запросов, анализ и управление данными через Web. Использование языка XML для обмена данными между удаленными системами. Простой и безопасный доступ к данным с помощью Web - браузеров, быстрый поиск необходимых документов. Анализ потоков данных и получение информации о пользователях, в том числе и через Web.
• Масштабируемость и надежность. SQL Server 2005 обеспечивает практически неограниченный рост объемов хранения данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. Это безопасная, надежная, масштабируемая платформа, защищающая информацию в приложениях и повышающая её доступность. Включенная в неё инновационная инфраструктура управления, основанная на политиках, позволяет определять политики для явного и автоматического администрирования серверных сущностей на одном или нескольких серверах. Кроме того, оптимизированная платформа SQL Server 2005 открывает путь к предсказуемой производительности обработки запросов. Инфраструктура SQL Server 2005 стала более масштабируемой. Она способна формировать отчеты и выполнять анализ любого объема и сложности, одновременно облегчая пользователям доступ к данным за счет более тесной интеграции с Microsoft Office. В результате ИТ-специалисты могут распространить использование бизнес-аналитики по всей организации. SQL Server 2005 позволяет пользователям консолидировать разнородные данные в корпоративном хранилище, выводя организацию хранилищ данных на новый уровень.
• Скорость создания решений. SQL Server 2005 в сочетании с .NET Framework уменьшает время разработки, внедрения и выхода на рынок современных приложений, ускоряет процесс поиска данных, упрощает управление, позволяет использовать создаваемые пользователем функции в других приложениях, предоставляет широкие возможности для создания Web-приложений. Среда ADO.NET Entity Framework повышает эффективность труда разработчиков, поскольку теперь они имеют дело не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные на собственные устройства, а позже синхронизовать их с центральными серверами.

 

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

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

Таблица 2.6 - Номера

Имя поля	Тип поля	Длина поля
Код_номера	Int	4 byte
Категория_номера	varchar(20)	20 символов
Количество_мест	Int	4 byte
Количество_комнат	Int	4 byte
Стоимость в  сутки	Money	8 byte

 

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

Имя поля	Тип поля	Длина поля
Код_портье	Int	4 byte
ФИО_портье	varchar(50)	50 символов
Дата_рождения	Date	8 byte
Образование	varchar(20)	20 символов
Телефон	Int	4 byte

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

Имя поля	Тип поля	Длина поля
Код_клиента	Int	4 byte
ФИО_клиента	varchar(50)	50 символов
Дата_рождения	Date	8 byte
Пол	varchar(20)	20 символов
Телефон	Int	4 byte
Вид_документа	varchar(20)	20 символов
Серия	varchar(5)	5 символов
Номер	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).