разработка реляционных баз данных в среде MS Office Access

Введение
1. Организационно-экономическая сущность задачи
1.1. Возникновение задачи
1.2. Структура предприятия заказчика
1.3. Перечень задач, предлагаемых заказчиком для исполнения
2. Построение информационно-логической модели предметной области
2.1. ER-диаграмма
2.2. Реляционная модель
3. Физическое проектирование базы данных в среде МS Ассеss3.1. Создание таблиц
3.2. Ориентировочный расчет требуемой памяти
3.3. Загрузка таблиц
4. Разработка интерфейса пользователя
4.1. Создание главной кнопочной формы
4.2.Проект меню
4.3. Создание форм
4.4. Решение задач заказчика
4.5. Создание отчета
5. Тестирование информационной системы
Заключение
Литература

Введение
Для принятия обоснованных и эффективных решений в производственной деятельности, в управлении экономикой и в политике современный специалист должен уметь с помощью компьютеров и средств связи получать, накапливать, хранить и обрабатывать данные, представляя результат в виде наглядных документов. В современном обществе информационные технологии развиваются очень стремительно, они проникают во все сферы человеческой деятельности.
В разных областях экономики зачастую приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Для координации всех этих данных необходимы определенные знания и организационные навыки.
Гостиница — это предприятие, предоставляющее людям, находящимся вне дома, комплекс услуг, важнейшими среди которых (комплексообразующими) в равной степени являются услуга размещения.
Содержание услуги размещения состоит в том, что, во-первых, в пользование предоставляются специальные помещения (гостиничные номера), во-вторых, предоставляются услуги, выполняемые непосредственно персоналом гостиницы: портье по приему и оформлению гостей, горничными по уборке гостиничных номеров и т. д.
Гостиничные номера являются основным элементом услуги размещения.
Это многофункциональные помещения, предназначенные для отдыха, сна, работы проживающих гостей.
Вследствие того, что гостиничные номера используются гостями преимущественно в вечернее и ночное время, важнейшей их функцией является обеспечение возможности сна.
Значимость других функций гостиничных номеров прежде всего зависит от назначения гостиницы и потребностей гостей.
Например, в гостиницах делового назначения очень важной функцией номеров является обеспечение гостю возможности поработать, то есть здесь необходим письменный стол, телефон, факс, компьютер и т. д.
В гостиницах имеются различные категории номеров, отличающиеся площадью, меблировкой, оборудованием, оснащением и т. д.
В Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.

1. Организационно-экономическая сущность задачи
1.1. Возникновение задачи
Тема курсовой работы «Гостиница» выбрана, исходя из состояния современного мира. Многие страны с промышленного уровня перешли на информационный, или, как многие говорят уровень «сферы услуг». Гостиничное дело процветает на территории России и за рубежом.
Необходимо разработать проект прикладной системы, поддерживающей основную деятельность гостиницы по работе с клиентами и поставщиками. Разработка должна осуществляться в соответствии с основными стадиями жизненного цикла продукта с применением структурного подхода. В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными.
Цель базы данных Гостиница – автоматизация процесса учета и анализа данных гостиницы.
Для того, чтобы спроектировать базу данных, необходимо поставить перед собой задачи, которые помогут в реализации проекта:
- хранение и поиск информации о клиентах гостиницы;
- хранение и поиск информации о номерах;
- хранение данных о бронировании, заселении, выезде клиентов и вычисление оплаты за проживание
- вычисление и анализ информации о поступлении оплаты за проживание от клиентов компании;
- поиск информации по основным позициям: забронированные номера, заезд за период, выезд за период.
1.2. Структура предприятия заказчика
Организационная структура гостиница приведена на Рисунке 1.

Рисунок 1. Организационная структура гостиницы


1.3. Перечень задач, предлагаемых заказчиком для исполнения
Предполагаемая гостиница располагает номерами с разным уровнем сервиса, комфортности и, соответственно, оплаты. Одной из характеристик номера является его тип. Предположим, что существуют следующие типы номеров: люкс – многокомнатный номер с высоким уровнем сервиса, комфортности и обслуживания; полулюкс – номер меньшей, чем люкс, площади, но с достаточным уровнем сервиса и комфортности; одноместный или двухместный номер с минимальным уровнем сервиса; многоместный номер, также с некоторым уровнем сервиса. Стоимость для номеров типа люкс и полулюкс устанавливается как стоимость всего номера (в сутки), независимо от количества проживающих в номере. Стоимость проживания в одно-, двух- и многоместных номерах устанавливается для одного человека (в сутки). Номера и места в номерах могут бронироваться. При наличии телефона в номере пользование междугородным телефоном оплачивается отдельно по фактическим счетам.
Все прибывающие и размещаемые в гостинице граждане при вселении должны заполнить карточку регистрации. Кроме того, для расчетов с клиентами администрация гостиницы заводит расчетные карточки, которые содержат данные о размещении клиента, оказанных услугах и всех расчетах с ним. Для номеров типа люкс и полулюкс расчетная карточка может заводиться только для одного клиента, оплачивающего номер.
Любое помещение гостиницы имеет номер, по которому ведется учет проживающих в гостинице.
При выбытии клиента информация о номере, в котором он проживал, должна обновляться, а информация о клиенте должна удаляться из рабочих таблиц (карточки регистрации клиентов и карточки учета) и помещаться в архивную таблицу.
БД должна осуществлять:
ведение сведений о номерах типа люкс и полулюкс (номер комнаты, тип номера, занят/свободен, количество комнат, этаж, телефон, стоимость номера в сутки, сведения о бронировании, количество фактически проживающих);
сведения о прочих номерах (номер комнаты, тип номера, количество мест, этаж, телефон, стоимость проживания одного человека в сутки, количество свободных мест);
карточки регистрации (номер регистрации клиента, номер комнаты, дата прибытия, фамилия, имя, отчество, предъявленный документ, серия и номер документа, дата рождения, пол, домашний адрес, домашний телефон);
расчетные карточки (номер регистрации клиента, номер комнаты, дата и время прибытия, оплата брони, предполагаемая дата убытия, количество оплаченных дней, сумма оплаты, окончательный расчет);
учёт забронированных мест;
ведение архива выбывших постояльцев за последний год.
Необходимо предусмотреть:
получение списка свободных номеров (по количеству мест и классу);
получение списка номеров (мест), освобождающихся сегодня и завтра;
выдачу информации по конкретному номеру;
автоматизацию выдачи счетов на оплату номера и услуг;
получение списка забронированных номеров;
проверку наличия брони по имени клиента и/или названию организации;
поиск клиента по его параметрам

2. Построение информационно-логической модели предметной области
Создавая базу данных, нужно упорядочить данные по определенным правилам (структурировать данные), чтобы с максимальным комфортом работать с базой данных. Для начала структурирования данных следует выбрать информационно-логическую (инфологическую) модель данных, которая является ядром любой базы данных. Мифологическая модель БД представляет собой описание объектов (сущности), с набором атрибутов и связей между ними. Информационно-логическая модель является фундаментом, на котором будет создана база данных. Для этого рассматриваются входные и выходные документы, относящиеся к предметной области заказчика, и учитываются поставленные задачи.
Входные документы
Документ (Код документа, Документ)
Тип номера (Код типа, Наименование)
Номера (Код номера, Тип номера, Кол-во мест, Этаж, Телефон, Стоимость проживания одного человека, Стоимость брони)
Постояльцы (Код постояльца, Фамилия, Имя, Отчество, Дата рождения, Пол, Подтверждающий документ, Номер паспорта, Серия паспорта, Домашний адрес, Контактный телефон)
Выходные документы
Результаты решения задач заказчика зафиксированы в следующих документах:
Бронь (Код брони, Код номера, Предполагаемая дата въезда, Фамилия постояльца)
Журнал учета (Код записи, Код постояльца, Код номера, дата прибытия, время прибытия, Дата выезда, Стоимость за сутки, Сумма к оплате, Количество людей, Подтверждение оплаты, Предварительное бронирование, Код брони).
2.1. ER-диаграмма
Концептуальная модель базы данных – это высокоуровневая объектно-ориентированная модель предметной области, представляющая объектную область в виде набора объектов, обладающих определенными свойствами и находящимися в некоторых отношениях. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и не зависит от конкретной СУБД. Концептуальная модель создается на основе представлений о предметной области каждого типа пользователей, представляющих собой набор данных, необходимых пользователю для решения своих задач. Основные концепции модели включают такие понятия как сущность (объект), отношение (связь), типы сущностей, типы связей и атрибуты.
Er-диаграмма база данных "Гостиница" приведена на Рисунке 2.
Рисунок 2. ER - диаграмма "Гостиница"
2.2. Реляционная модель
реляционная модель - это способ рассмотрения данных, т.е. предписание для способа представления данных (посредством таблиц) и для способа работы с таким представлением (посредством операторов). Или, точнее, реляционная модель связана с тремя аспектами данных: структурой, целостностью и обработкой данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими характеристиками:
каждый элемент таблицы - один элемент данных;
все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковые характеристики (тип и длину);
каждый столбец имеет уникальное имя;
порядок столбцов не важен;
отсутствуют одинаковые записи;
порядок записей в таблице может быть произвольным.
Реляционные таблицы связываются между собой с помощью ключевых полей.
Реляционные модели (в МS Ассеss) не позволяют определять прямую связь «многие ко многим» между двумя таблицами. Поэтому нужно разделить связь «многие ко многим» на две связи «один ко многим», т.е. построить дополнительную таблицу связи.
Ключевое поле одной таблицы - первичный ключ - связывают с соответствующим ему полем второй таблицы, которое называют внешним ключом.
Связующая таблица обязательно содержит внешние ключи (часто имеющие то же имя, что и первичные ключи) и, как правило, поля, характеризующие рабочий процесс.
На основе спроектированной ER диаграммы видим следующие отношения:
Таблица "Документ" и "Постояльцы" имеет отношение 1:М в связи с этим выделен внешний ключ (Код документа) в таблице "Документ".
Таблица "Тип номера" и "Номера" имеет отношение 1:М. Внешний ключ "Код типа" в таблице "Тип номера".
Таблица "Номера" и "Бронь" имеют отношения 1:М. Внешний ключ "Номер комнаты".
Таблица "Журнал учета" и таблицы "Постояльцы"и "Номера" имеют отношения 1:М.
Соответственно таблица "Номера" имеет внешний ключ «Код номера» в таблице «Журнал учета». В свою очередь таблица «Постояльцы» имеет внешний ключ «Код постояльца» в таблице «Журнал учета».
Таблица «Бронь» и таблица «Журнал учета» имеет внешний ключ «Код брони».
Схема данных имеет вид (рис.3):

Рисунок 3. Схема данных «Гостиница»

3. Физическое проектирование базы данных в среде МS Ассеss3.1. Создание таблиц
С учетом типов данных и ограничений, принятых в MS Access, опишем требования к таблицам.
Таблица 1.1
Таблица Постояльцы
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код постояльца Счётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Фамилия Текстовый Размер поля 25
Обязательное поле Нет
Имя Текстовый Размер поля 10
Обязательное поле Нет
Отчество Текстовый Размер поля 15
Обязательное поле Нет
Пол Текстовый Размер поля 10
Обязательное поле Нет
Подтверждающий документ Числовой Размер поля Длинное целое
Индексированное поле Нет
Номер паспорта Числовой Размер поля Длинное целое
Индексированное поле Нет
Серия паспорта Числовой Размер поля Длинное целое
Индексированное поле Нет
Домашний адрес Текстовый Размер поля 255
Обязательное поле Нет
Контактный телефон Числовой Размер поля Длинное целое
Индексированное поле Нет
Таблица 1.2
Таблица Номера
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Номер комнаты Счётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Тип номера Числовой Размер поля Длинное целое
Индексированное поле Нет
Кол-во мест Числовой Размер поля Длинное целое
Индексированное поле Нет
Этаж Числовой Размер поля Длинное целое
Индексированное поле Нет
Телефон Числовой Размер поля Длинное целое
Индексированное поле Нет
Стоимость проживания одного человека Числовой Размер поля Длинное целое
Индексированное поле Нет
Стоимость брони Числовой Размер поля Длинное целое
Индексированное поле Нет
Таблица 1.3
Таблица Документ
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код документа Счётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Документ Текстовый Размер поля 50
Обязательное поле Нет
Таблица 1.4
Таблица Тип номера
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код типа Счётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Наименование Текстовый Размер поля 35
Обязательное поле Нет
Таблица 1.5
Таблица Бронь
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код брони Счётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Код номера Числовой Размер поля Длинное целое
Индексированное поле Нет
Предполагаемая дата въезда Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Фамилия постояльца Текстовый Размер поля 35
Обязательное поле Нет
Таблица 1.6
Таблица Журнал учета
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код_записиСчётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Код_постояльцаЧисловой Размер поля Длинное целое
Индексированное поле Нет
Код_номераТекстовый Размер поля 35
Обязательное поле Нет
Дата прибытия Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Время прибытия Дата/Время Формат поля Краткий формат времени
Индексированное поле Нет
Дата выезда Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Стоимость за сутки Числовой Размер поля Длинное целое
Индексированное поле Нет
Сумма к оплате Числовой Размер поля Длинное целое
Индексированное поле Нет
Количество_людейЧисловой Размер поля Длинное целое
Индексированное поле Нет
Подтверждение
оплаты Логический Формат поля Истина/Ложь
Обязательное поле Нет
Предварительное бронирование Логический Формат поля Истина/Ложь
Обязательное поле Нет
Код_брониЧисловой Размер поля Длинное целое
Индексированное поле Нет
Таблица 1.7
Таблица Архив брони
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код_брониСчётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Код_номераЧисловой Размер поля Длинное целое
Индексированное поле Нет
Предполагаемая дата въезда Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Фамилия Текстовый Размер поля 35
Обязательное поле Нет
Год
Числовой Размер поля Длинное целое
Индексированное поле Нет
Таблица 1.8
Таблица Архив_Журнал учета
Имя поля Тип данных Свойства полей
Свойство Значение
1 2 3 4
Код_записиСчётчик Размер поля Длинное целое
Индексированное поле Да (совпадения не допускаются)
Код_постояльцаЧисловой Размер поля Длинное целое
Индексированное поле Нет
Код_номераТекстовый Размер поля 35
Обязательное поле Нет
Дата прибытия Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Время прибытия Дата/Время Формат поля Краткий формат времени
Индексированное поле Нет
Дата выезда Дата/Время Формат поля Краткий формат даты
Индексированное поле Нет
Сумма к оплате Числовой Размер поля Длинное целое
Индексированное поле Нет
Год Числовой Размер поля Длинное целое
Индексированное поле Нет
3.2. Ориентировочный расчет требуемой памяти
Следует подсчитать память, необходимую для работы с базой данных для каждой таблицы.
Подсчитаем память, необходимую для работы с нашей базой данных.
Таблица 2.1
Расчет памяти для таблицы «Постояльцы»
Имя поля Тип данных Тип данных(байт)
Код постояльца
Счётчик 30
Фамилия Текстовый 50
Имя Текстовый 50
Отчество Текстовый 50
Пол Текстовый 10
Подтверждающий документ Числовой 50
Номер паспорта Числовой 30
Серия паспорта Числовой 30
Домашний адрес Текстовый 50
Контактный телефон Числовой 20
Итого: 370
Таблица 2.2
Расчет памяти для таблицы «Номера»
Имя поля Тип данных Тип данных(байт)
Номер комнаты Текстовый 30
Тип номера Числовой 30
Кол-во мест Числовой 10
Этаж Числовой 10
Телефон Числовой 40
Стоимость проживания 1 человека Числовой 30
Стоимость брони Числовой 30
Итого: 180
Таблица 2.3
Расчет памяти для таблицы "Документ"
Имя поля Тип данных Тип данных(байт)
Код документа Числовой 30
Документ Текстовый 50
Итого: 80
Таблица 2.4
Расчет памяти для таблицы "Тип номера"
Имя поля Тип данных Тип данных(байт)
Код типа Числовой 30
Наименование Текстовый 50
Итого: 80
Таблица 2.5
Расчет памяти для таблицы "Бронь"
Имя поля Тип данных Тип данных(байт)
Код брони Счетчик 30
Код номера Числовой 30
Предлагаемая дата въезда Дата 30
Фамилия Текстовый 50
Итого: 140
Таблица 2.6
Расчет памяти для таблицы «Журнал учета»
Имя поля Тип данных Тип данных(байт)
Код записи
Счётчик 30
Код постояльца Числовой 30
Код номера Числовой 30
Дата прибытия Дата/Время 30
Время прибытия Дата/Время 30
Дата выезда Дата/Время 30
Стоимость за сутки Числовой 50
Сумма к оплате Числовой 50
Количество людей Числовой 30
Подтверждение оплаты Логический 10
Предварительное бронирование Логический 10
Код брони Числовой 30
Итого: 360
Таблица 2.7
Расчет памяти для таблицы «Архив_Журнал учета»
Имя поля Тип данных Тип данных(байт)
Код записи
Счётчик 30
Код постояльца Числовой 30
Код номера Числовой 30
Тип номера Текстовый 30
Фамилия Текстовый 50
Имя Текстовый 50
Отчество Текстовый 50
Дата рождения Дата/Время 30
Дата прибытия Дата/Время 30
Дата выезда Дата/Время 30
Сумма к оплате Числовой 30
Год Числовой 10
Итого: 400
Таблица 2.8
Расчет памяти для таблицы "Архив брони"
Имя поля Тип данных Тип данных(байт)
Код брони Счетчик 30
Код номера Числовой 30
Предлагаемая дата въезда Дата 30
Фамилия постояльца Текстовый 50
Год Числовой 10
Итого: 150
Из разговора с заказчиком выясняли, на сколько записей рассчитана каждая таблица.
Исходя из имеющейся практики в среднем в день заезжает 1-3 постояльцев.
На основании этого в таблицы "Журнал учета" и "Постояльцы" ежедневно вносятся 1-3 записи соответственно.
Предварительно бронируют номера 1-2 человека в сутки.
Выезжает ежедневно 1-2 человека. В связи с тем, что имеется необходимость ежемесячно архивировать в среднем раз в месяц таблицы "Архив журнал учета" и "Архив бронь".
Общая память, необходимая для нашей базы данных, показана в таблице 3:
Таблица 1 запись Количество записей Память (байт)
Постояльцы 370 3 1110
Номера 180 1 180
Журнал учета 360 3 1080
Документ 80 1 80
Тип номера 80 1 80
Бронь 140 2 280
Архив_Журнал учета 400 3 1200
Архив_Бронь150 3 450
Итого: 4460 (байт)
Таблица 3
В итоге мы получаем минимальное количество требуемой памяти 4460 байт или 4,36 Кбайт.
3.3. Загрузка таблиц
Для примера мы рассмотрим таблицу «Постояльцы», в которой содержатся данные о постояльцах гостиницы.
Для перемещения по записям используем кнопки, расположенные на нижней границе окна таблицы. Также в нижней части окна таблицы расположено поле номера записи, в котором отображается номер текущей записи. Для перехода на запись с известным номером мы вводим номер в поле номера записи и нажимаем клавишу ENTER. Поиск конкретной записи осуществляется с помощью полос прокрутки. Так мы получаем таблицу «Постояльцы».
Для добавления данных товара мы используем режим формы. В формах, так же как и в таблицах, предусмотрена пустая запись, которая предназначена для добавления новых записей в таблицу. Эта пустая запись, как в таблице, отображается в форме после всех заполненных записей.
К этой записи можно перейти, пролистав в форме все записи с помощью кнопок перехода по записям или с помощью специальной кнопки перехода на новую запись. После ввода данных в эту запись и ее сохранения данные автоматически попадают в таблицу.
В нашей форме для добавления новой записи пользователь должен нажать кнопку Добавить запись, после – кнопку Сохранить.
В результате чего в таблицу добавляется новая запись. Для отмены изменений или добавления данных в таблицу пользователю необходимо нажать кнопку Отменить.
По выше указанному принципу заполняем данные в оставшиеся таблицы.

4. Разработка интерфейса пользователя
Access предоставляет возможность вводить данные как непосредственно в таблицу, так и с помощью форм. Форма в БД - это структурированное окно, которое можно представить так, чтобы оно повторяло форму бланка. Формы создаются из набора отдельных элементов управления.
Внешний вид формы выбирается в зависимости от того, с какой целью она создается. Формы Access позволяют выполнять задания, которые нельзя выполнить в режиме таблицы. Формы позволяют вычислять значения и выводить на экран результат. Источником данных для формы являются записи таблицы или запроса.
Форма предоставляет возможности для:
– ввода и просмотра информации базы данных;
– изменения данных;
– печати;
– создания сообщений.
4.1. Создание главной кнопочной формы
MS Ассеss позволяет организовывать удобный и интуитивно понятный интерфейс пользователя для работы с данными с помощью форм. Формами называются настаиваемые диалоговые окна, сохраняемые в базе данных в виде объектов специального типа. Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах. Элементами управления являются текстовые поля для ввода и правки данных, кнопки, флажки, переключатели, списки, надписи, а также рамки объектов для отображения графики. Создание форм, содержащих необходимые элементы управления, существенно упрощает процесс ввода данных и позволяет предотвратить ошибки. Формы позволяют выполнять проверку корректности данных при вводе, проводить вычисления, и обеспечивают доступ к данным в связанных таблицах с помощью подчиненных форм.
Главная кнопочная форма создается с целью навигации по базе данных, т.е. она может использоваться в качестве главного меню БД. Элементами главной кнопочной формы являются объекты форм и отчётов.
Для одной базы данных можно создать несколько кнопочных форм. Кнопки следует группировать на страницах кнопочной формы таким образом, чтобы пользователю было понятно, в каких кнопочных формах можно выполнять определенные команды (запросы, отчеты, ввода и редактирования данных). Необходимо отметить, что на подчиненных кнопочных формах должны быть помещены кнопки возврата в главную кнопочную форму.
Для удобства работы в базе данных мы создали кнопочную форму "Главная форма"

Рисунок 4. Главная форма.
По средствам "Главной формы" пользователь обращается к подчиненным формам "Справочные таблицы", "Учетные таблицы" и "Отчеты".
Также на данной форме имеются рабочие кнопки в правой верхней части формы.
В нашей главной форме предусмотрена кнопка "ВЫХОД" которая завершает работу с базой данных "Гостиница"
Форма "Справочные таблицы" представлены на рисунке 5

Рисунок 5. Форма "Справочные таблицы"
Данная форма позволяет обращаться в следующим формам :– Типы номеров;
– Номера гостиницы;
– Документы;
– Архив.
Форма "Ученые таблицы" представлены на рисунке 6.

Рисунок 6. Форма "Учетные таблицы"
Форма "Учетные таблицы" содержит в себе следующие формы:
– Бронирование;
– Список постояльцев;
– Журнал учета.
Форма "Отчеты" представлена на рисунке 7.

Рисунок 7. Форма "Отчеты"
В данной форме представлена возможность формировать отчеты на основании ранее созданных запросов:
– 01_Список номеров освобождающихся сегодня и завтра;
– 02_ Выдача информации по конкретному номеру;
– 03 Список забронированных номеров;
– 04_Проверка наличия брони по фамилии;
– 05_ Поиск клиента по параметру.
4.2.Проект меню
4.3. Создание форм
Записи базы данных (БД) можно просматривать и редактировать в виде таблицы или в виде формы. Представление БД в виде таблицы позволяет наблюдать сразу несколько записей одновременно, однако часто вид Таблица не позволяет полностью видеть всю информацию на экране. Формы позволяют забыть о неудобствах, возникающих при работе с таблицами, имеющими большое количество полей. В режиме Форма можно все внимание уделить одной записи, не пользуясь прокруткой для поиска нужного поля в длинной череде столбцов таблицы, а имея перед глазами всю информацию.
Также для удобства работы с формой на ней можно разместить Элементы управления (например, Кнопки).
Чтобы создать форму, необходимо в окне БД выбрать в списке Создание, необходимо выбрать режим создания формы, а также таблицу (в раскрывающемся списке), которая будет использоваться в качестве источника данных.
Основными режимами создания любой формы являются Конструктор и Мастер форм. Рассмотрим создание формы с помощью режима Мастер форм.
С помощью мастера можно создавать формы на основе одной таблицы и более сложные формы на основе нескольких таблиц и запросов. Намного проще и быстрее создавать формы с помощью мастера, а затем усовершенствовать их в режиме Конструктора. Чтобы лучше представить, как создавать формы с помощью Мастера форм, опишем процедуру создания формы. Эта форма предназначена для оформления товарного чека. Для создания этой формы:
Выбираем Другие формы Мастер форм.
Появилось первое диалоговое окно. В поле со списком Таблицы и запросы отображены имена всех таблиц и запросов базы данных, которые могут использоваться в качестве источника данных для форм. Раскрыв этот список, мы выбираем запрос «Расписка».
В списке Доступные поля этого диалогового окна отображаются все поля выбранной таблицы или запроса. Чтобы добавить в создаваемую форму нужные поля, мы нажимаем кнопку «>». Нажимаем кнопку Далее для отображения второго диалогового окна Мастера форм.
Во втором диалоговом окне мастера можно определить вид формы. После выбора подходящего режима отображения данных в форме мы нажимаем кнопку Далее для отображения следующего диалогового окна.
Третье диалоговое окно Мастера форм предназначено для выбора стиля оформления новой формы. Мастер предлагает несколько стилей оформления. Мы выбираем стиль и нажимаем кнопку Далее.
В последнем диалоговом окне Мастера форм требуется указать название формы. Чтобы отобразить созданную мастером форму в режиме Формы, выбираем переключатель Открыть форму для просмотра и ввода данных и нажимаем кнопку Готово.
В результате мастером будет создана форма в соответствии с выбранными параметрами и сохранена с указанным именем, затем эта форма будет открыта в заданном режиме. После редактируем форму в режиме Конструктора.
Форма "Типы номера"

Рисунок 8. Форма "Тип номера"
Форма "Номера гостиницы"

Рисунок 9. Форма "Номера"
Форма "Документы"

Рисунок 10. Форма "Документы"

Форма "Архив" содержит в себе две кнопки по средствам которых мы можем открыть архивные таблицы "Архив_бронь" и "Архив_Журнал учета"

Рисунок 11 Форма "Архив"
Форма "Бронирование"

Рисунок 12 Форма "Бронирование"
Форма "Список постояльцев"

Рисунок 13 Форма " Список постояльцев"

Форма "Журнал учета"

Рисунок 14 Форма " Журнал учета "
4.4. Решение задач заказчика
Любой запрос хранится в базе данных в формате (на английском - Structured Query Language) расшифровывается как «язык структурированных запросов».
В реляционных базах данных язык запросов служит:
для создания данных;
для модификации данных;
для управления данными.
Основное достоинство этого языка состоит в том, что он является стандартом для большинства реляционных СУБД.
Для решения задач поставленных Заказчиком были созданы следующие запросы:
1) Запрос на выборку "01_Список номеров освобождающихся сегодня и завтра".
SELECT Номера.[Номер комнаты], Номера.Тип_номера, Номера.[Кол-во мест], Номера.Этаж, Номера.Телефон, Номера.[Стоимость проживания одного человека], Номера.[Стоимость брони], [Журнал учета].[Дата прибытия], [Журнал учета].[Дата выезда]
FROM Тип_номера INNER JOIN (Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].Код_номера) ON Тип_номера.Код_типа = Номера.Тип_номераWHERE ((([Журнал учета].[Дата выезда])=Date() Or ([Журнал учета].[Дата выезда])=Date()+1));
2) Запрос на выборку "02_Выдча информации по конкретному номеру"
SELECT Номера.[Номер комнаты], Номера.Тип_номера, [Журнал учета].Код_записи, [Журнал учета].Код_постояльца, [Журнал учета].[Дата прибытия], [Журнал учета].[Дата выезда], [Журнал учета].[Сумма к оплате]
FROM Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].[Код_номера]
WHERE (((Номера.[Номер комнаты])=[Введите номер комнаты]));
3) Запрос на выборку "03_Список забронированных номеров"
SELECT Номера.[Номер комнаты], Номера.Тип_номера, Бронь.Код_брони, Постояльцы.Фамилия, Постояльцы.Имя, Постояльцы.Отчество, Постояльцы.[Дата рождения]
FROM Постояльцы INNER JOIN ((Номера INNER JOIN Бронь ON Номера.[Номер комнаты] = Бронь.Код_номера) INNER JOIN [Журнал учета] ON (Бронь.Код_брони = [Журнал учета].Код_брони) AND (Номера.[Номер комнаты] = [Журнал учета].Код_номера)) ON Постояльцы.[Код постояльца] = [Журнал учета].Код_постояльцаORDER BY Номера.[Номер комнаты];
4) Запрос на выборку "04_Проверка наличия брони по фамилии"
SELECT Бронь.Код_брони, Бронь.Код_номера, Бронь.[Предлагаемая дата вьезда], Бронь.[Фамилия постояльца]
FROM Бронь
WHERE (((Бронь.[Фамилия постояльца])=[Введите фамилию]));
5) Запрос на выборку "05_Поиск клиента по параметру"
SELECT Постояльцы.[Код постояльца], Постояльцы.Фамилия, Постояльцы.Имя, Постояльцы.Отчество, Постояльцы.[Дата рождения], Постояльцы.Пол, Постояльцы.[Подтверждающий документ], Постояльцы.[Номер паспорта], Постояльцы.[Серия паспорта], Постояльцы.[Домашний адрес], Постояльцы.[Контактный телефон]
FROM Постояльцы
WHERE (((Постояльцы.Фамилия)=[Введите Фамилию]));
6) Запрос на выборку "Расчетная карточка для отчета "
SELECT [Журнал учета].Код_записи, Постояльцы.[Код постояльца], Номера.[Номер комнаты], [Журнал учета].[Дата прибытия], [Журнал учета].[Время прибытия], [Журнал учета].[Предварительное бронирование], [Журнал учета].[Дата выезда], [Журнал учета].[Стоимость_за сутки], [Журнал учета].[Сумма к оплате], [Журнал учета].Количество_людей, [Дата выезда]-[Дата прибытия] AS Колво_днейFROM Постояльцы INNER JOIN (Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].Код_номера) ON Постояльцы.[Код постояльца] = [Журнал учета].Код_постояльцаWHERE ((([Журнал учета].Код_записи)=[Введите код записи]));
7) Запрос на выборку "Регистрационная карточка для отчета"
SELECT Постояльцы.[Код постояльца], [Журнал учета].Код_записи, [Журнал учета].Код_номера, Постояльцы.Фамилия, Постояльцы.Имя, Постояльцы.Отчество, Постояльцы.[Дата рождения], Постояльцы.Пол, Постояльцы.[Подтверждающий документ], Постояльцы.[Номер паспорта], Постояльцы.[Серия паспорта], Постояльцы.[Домашний адрес], Постояльцы.[Контактный телефон], [Журнал учета].Код_номера, [Журнал учета].[Дата прибытия]
FROM Постояльцы INNER JOIN [Журнал учета] ON Постояльцы.[Код постояльца] = [Журнал учета].[Код_постояльца]
WHERE (((Постояльцы.[Код постояльца])=[Введите номер постояльца]));
8) Запрос на обновление "01_Расчет стоимости_проживания_с_бронированием"
UPDATE Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].Код_номера SET [Журнал учета].[Сумма к оплате] = ([Журнал учета]![Дата выезда]-[Журнал учета]![Дата прибытия])*[Журнал учета]![Количество_людей]*[Номера]![Стоимость проживания одного человека]+[Номера]![Стоимость брони], [Журнал учета].[Стоимость_за сутки] = [Номера]![Стоимость проживания одного человека]
WHERE ((([Журнал учета].[Предварительное бронирование])=Yes));
9) Запрос на обновление "02_Расчет стоимости_проживания_без_бронирования"
UPDATE Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].Код_номера SET [Журнал учета].[Сумма к оплате] = ([Журнал учета]![Дата выезда]-[Журнал учета]![Дата прибытия])*[Журнал учета]![Количество_людей]*[Номера]![Стоимость проживания одного человека], [Журнал учета].[Стоимость_за сутки] = [Номера]![Стоимость проживания одного человека]
WHERE ((([Журнал учета].[Предварительное бронирование])=No));
10) Запрос на обновление "03_Расчет стоимости_проживания_без_бронирования_люкс"
UPDATE Тип_номера INNER JOIN (Номера INNER JOIN [Журнал учета] ON Номера.[Номер комнаты] = [Журнал учета].Код_номера) ON Тип_номера.Код_типа = Номера.Тип_номера SET [Журнал учета].[Сумма к оплате] = ([Журнал учета]![Дата выезда]-[Журнал учета]![Дата прибытия])*[Номера]![Стоимость проживания одного человека], [Журнал учета].[Стоимость_за сутки] = [Номера]![Стоимость проживания одного человека]
WHERE ((([Журнал учета].[Предварительное бронирование])=No) AND ((Тип_номера.Наименование)="Люкс")) OR (((Тип_номера.Наименование)="Полулюкс"));
11) Запрос на обновление "04_Расчет стоимости_проживания_с_бронированием_люкс"
UPDATE Тип_номера INNER JOIN (Номера INNER JOIN [Журнал уч