База данных Гостиницы

 

Таблица 2.3 – Функциональные зависимости между атрибутами сущности «Номера»

Наименование атрибутов	Функциональные зависимости
код_номера код_категории стоимость_проживания_за_сутки количество_мест

 

Таблица 2.4 – Функциональные зависимости между атрибутами сущности «Клиенты»

Наименование атрибутов	Функциональные зависимости
код_клиента Ф.И.О. дата_рождения адрес серия_номер_паспорта

 

 

 

 

 

Таблица 2.5 – Функциональные зависимости между атрибутами сущности «Учет работы»

Наименование атрибутов	Функциональные зависимости
код_операции код_комнаты код_клиента дата_заселения дата_выселения стоимость_проживания

 

Таблица 2.6 – Ключи

Таблица	Ключ
Учет работы	код_операции код_комнаты код_клиента
Клиенты	код_клиент
Персонал	код_работника
Номера	код_номера код_категории
Категории	код_категории

 

В базе данных «Гостиница»  проведена нормализация отношений:

Проанализировав таблицу  «Категории», можно сказать, что  она находится в первой нормaльнойфoрме, так как она имеет первичный ключ, каждое поле таблицы предстaвляетуникaльный тип инфoрмации, все поля атомарны. Так же данная таблица находится и во 2НФ, так как она удовлетворяет условиям 1НФ, а так же я убедился в том, что каждое поле функционально зависит от пeрвичнoгoключa, кoтoрыйидeнтифицируeтисхoдныйoбъекттaблицы. Тaблица «Кaтегории» нaходится в 3НФ, так как она находится во 2НФ и не coдержиттрaнзитивныхзaвисимостей, т.е. столбцы, не являющиеся ключевыми, зaвисят от первичнoго ключа тaблицы и не зависят от всeхocтальныхстoлбцoв. Имeeтсявoзмoжнoстьизмeнять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей.

Таблицы «Клиенты», «Учет  работы», «Номера», «Персонал» аналогично таблице «Категории» находятся  во всех трех нормальных формах.

На первый взгляд может  пoказаться, чтoтaблицы «Клиенты» и «Персонал» не удoвлетворяетуслoвиям 1НФ, поскoльку поля Ф.И.О., aдрес и можно разделить, но в этом нет смысла, т. к. это внeсет лишнюю громоздкость.

Таким обрaзом, прoанaлизирoвaврaзрaбoтaннуюбaзудaнных, мoжнo сделать вывод, что она нормализована и соответствует трем нормальным формам.

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

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

- сведения о номерах  типа люкс и полулюкс (номер  комнаты, категория номера, занят/свободен, количество комнат, стоимость номера в сутки, сведения о бронировании, количество фактически проживающих);

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

- формы оплаты (наличная, безналичная, предоплата);

- архив (фамилия, имя,  отчество, дата рождения, пол, дата  заезда, выезда, категория).

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

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

Другая задача поиска –  это поиск клиента, проживающего в гостинице в данный момент или  проживавшего в ней ранее.

2.2 Разработка базы данных  для гостиницы

 

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

Для отображения полной информации по состоянию гостиницы, направлениям её деятельности и отчётности по выполненным  работам, я создала 8 таблиц:

1. «Номера»

Эта таблица имеет такие  поля: код номера – тип данных счётчик (ключевое поле); категория  – тип данных: мастер постановок ( одноместный, двухместный, полулюкс, люкс), состояние (занято/свободно).

2. «Категории номеров»

Поля: код категории –  тип данных: счётчик (ключевое поле), категория – текстовый, размер поля- 20, обязательное; количество мест –  тип данных: числовой длинное целое, обязательное; количество комнат –  аналогично; стоимость в сутки  – тип данных: денежный, формат –  евро.

3. «Состояние номера»

Поля: код номера – тип  данных мастер подстановок (аналогичное  поле из таблицы «Номера», ключевое поле ; код сотрудника (горничной) - мастер подстановок ( из таблицы «сотрудники»), бронь, заезд, выезд – тип данных: дата\время, поле обязательное; сумма – денежный, формат – евро.

4. «Клиенты»

Поля: код клиента –  тип данных: счётчик(ключевое поле); фамилия, имя, отчество –тип данных: текстовый, размер поля- 20, обязательное, совпадения не допускаются; дата рождения - тип данных: дата\время, обязательное; пол- мастер постановок (муж, жен).

5. «Бронь» 

Поля: код брони – тип  данных: счётчик( ключевое поле); код состояния – тип данных: мастер подстановок (поля бронь, заезд, выезд из таблицы «состояние номера»); список фамилий – мастер подстановок из таблицы «Клиенты»

    6.«Дети»

Поля: код ребёнка –  тип данных: счётчик (ключевое поле); код клиента – тип данных: мастер подстановок ( аналогичное поле из таблицы «клиенты»); фамилия, имя, отчество – тип данных: текстовый, размер поля – 20, обязательное, совпадения не допускаются; дата рождения – тип данных: дата\время, обязательное.

    7.«Способ оплаты»

Поля: код клиента –  мастер подстановок ( из таблицы «клиенты») ( ключевое поле); форма оплаты – мастер подстановок (наличная, безналичная); предоплата – тип данных: числовой, формат поля – евро, обязательное.

8.«Архив»

Поля: код категории –  мастер подстановок (из таблицы «Категории номеров») (ключевое поле); категория  – тип данных: текстовый; количество мест, комнат – тип данных: числовой; стоимость в сутки – тип  данных денежный (формат евро).

Схема данных имеет вид:

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

 

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

 Запрос №1 – «Бронь-фамилия».

Для данного запроса я  добавил таблицы «Состояние номера»  и «бронь». Запрос отображает информацию о забронированных номерах и  клиентах, осуществивших бронь.

           Конструктор. Запрос «Бронь-фамилия»

Запрос №2 – «Занятые и свободные номера» 

Для данного запроса были выбраны таблицы «состояние номера», «номера» и «клиенты». Данный запрос отображает информацию о занятых  и свободных номерах.

 

     Конструктор.  Запрос «Занятые и свободные  номера»

Запрос №3 - «Выезд из номеров»

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

         Конструктор. Запрос «Выезд из  номеров»

   Запрос №4– «Информация  по конкретному номеру»

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

          Конструктор. Запрос «Информация  по конкретному номеру».

 

Запрос №5 – «Счет»

Данный запрос выводит  счет клиента за предоставленные  ему услуги, т.е. выводится фамилия  клиента, а также сумма оплаты.

Конструктор.  Запрос «Счет»

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

 

 

Заключение

 

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

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

 В процессе анализа  вышеизложенной информации выявлены  следующие недостатки рассмотренной  модели баз данных:

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

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

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

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

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

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

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