База данных гостиницы
Федеральное
агентство связи
Сибирский
государственный университет телекоммуникаций и информатики
Кафедра ПДСиМ
Курсовой
проект
База данных
гостиницы
Выполнил: ст.гр. АЗ-58
Поселёнова А.И.
Проверил: преп.
Мейкшан Л.И.
Новосибирск
10
Содержание
1. Цель работы
2. Задание к курсовому проекту
.1 Этапы разработки базы данных
.2 Концептуальное моделирование данных
анализ предметной области, выделение объектов, информация о
которых должна храниться в базе данных, определение их атрибутов, связей между
объектами и характеристик этих связей;
построение ER-диаграмм.
.3 Логическое моделирование данных
создание таблиц, определение типов данных в каждом поле,
ограничений на установку диапазонов допустимых значений, первичных ключей;
определение внешних ключей и связей между таблицами.
. Создание запросов
. Разработка форм
. Разработка отчетов
. Создание кнопочной формы
. Список используемых источников
Цель работы
Целью
выполнения курсового проекта по курсу «Банки и базы данных» является:
a. изучение
этапов проектирования реляционных баз данных;
b. приобретение
практических навыков в разработке и реализации информационных систем;
c. приобретение навыков работы с реляционными базами данных
d. используя средства Microsoft Access,
реализовать базу данных в соответствии с индивидуальным заданием.
Задание к курсовому проекту
По заданному в варианте описанию предметной области разработать и
реализовать проект реляционной базы данных.
Создать файл базы данных Microsoft Access. Пользуясь
разработанным проектом базы данных, создать таблицы базы данных в режиме ввода
данных в таблицу или в режиме конструктора. В каждой таблице создать ключевые
поля, выбрать типы данных и установить диапазоны допустимых значений. Создать
схему данных, в которой определить связи между таблицами базы данных. Ввести
данные в таблицы базы данных.
Гостиница
База данных должна содержать сведения о следующих объектах:
Распределение номеров по этажам, с указанием общего количества мест в
номере, количества свободных мест и проживающих.
Гости - фамилия, имя, отчество, пол, адрес, дата рождения, номер
паспорта, дата выдачи, учреждение, выдавшее паспорт, номер комнаты, дата
въезда, дата выезда, список оказанных услуг (наименование услуги, количество,
цена).
Адресные данные коридорных и горничных и расписание их дежурств.
Выходные документы:
. Счет, предъявляемый при выписке гостя.
Бизнес-правила
1. Гости разного пола могут быть
поселены в один номер, только будучи супругами.
2. Горничные обслуживают ряд номеров
только одного этажа.
3. Коридорные обслуживают только один
этаж.
4. Указанные категории персонала имеют
скользящий график работы: коридорные - посуточно, горничные посменно.
5. Сведения о гостях сохраняются в
течение года.
Этапы
разработки базы данных
Целью разработки любой базы данных является хранение и использование
информации о какой-либо предметной области.
При разработке базы данных обычно выделяется несколько уровней
моделирования, при помощи которых происходит переход от предметной области к
реализации базы данных средствами конкретной СУБД. Можно выделить следующие
уровни:
· Сама предметная область
· Модель предметной области
· Концептуальная модель данных
· Логическая модель данных
· Физическая модель данных
· Собственно база данных и приложения
Предметная область - это часть реального мира, данные о которой
необходимо отразить в базе данных. Например, в качестве предметной области
можно выбрать бухгалтерию какого-либо предприятия, отдел кадров, банк, магазин
и т.д. Предметная область бесконечна и содержит как существенно важные понятия
и данные, так и малозначащие или вообще не значащие данные. Так, если в
качестве предметной области выбрать учет товаров на складе, то понятия
"накладная" и "счет-фактура" являются существенно важными
понятиями, а то, что сотрудница, принимающая накладные, имеет двоих детей - это
для учета товаров неважно. Однако, с точки зрения отдела кадров данные о
наличии детей являются существенно важными. Таким образом, важность данных
зависит от выбора предметной области.
Модель предметной области. Модель предметной области - это наши знания о
ней. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и
выражены формально при помощи каких-либо средств. В качестве таких средств
могут выступать текстовые описания предметной области, наборы должностных
инструкций, правила ведения дел в компании и т.п. Опыт показывает, что
текстовый способ представления модели предметной области неэффективен. Гораздо
более информативными и полезными при разработке баз данных являются описания
предметной области, выполненные при помощи специализированных графических схем.
Модель предметной области описывает скорее процессы, происходящие в предметной
области и данные, используемые этими процессами.
Концептуальная модель данных. На следующем, более низком уровне находится
концептуальная модель данных предметной области. Концептуальная модель
описывает понятия предметной области, их взаимосвязь, а также ограничения на
данные, налагаемые предметной областью. Концептуальная модель данных является
начальным прототипом будущей базы данных. Эта модель строится в терминах
информационных единиц, но без привязки к конкретной СУБД. Основным средством
разработки концептуальной модели данных в настоящий момент являются различные
варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).
Логическая модель данных - это данные, представленные на языке описания
данных конкретной СУБД. Логическая модель данных включает в себя следующие
составляющие:
- структура данных;
- ограничения, накладываемые на данные
операции, производимые над данными.
Одну и ту же ER-модель можно преобразовать как в реляционную модель
данных, так и в модель данных для иерархических и сетевых СУБД, или в
постреляционную (объектно-ориентированную модель данных).
Наиболее распространённая модель данных, используемая большинством СУБД -
реляционная модель. Поэтому можно считать, что логическая модель данных для нас
формулируется в терминах реляционной модели данных.
Физическая модель данных. На еще более низком уровне находится физическая
модель данных. Физическая модель данных описывает хранение данных средствами
конкретной СУБД. Ограничения, имеющиеся в логической модели данных, реализуются
различными средствами СУБД. При этом решения, принятые на уровне логического
моделирования определяют некоторые границы, в пределах которых можно развивать
физическую модель данных. Качество физической модели во многом зависит от
выбора СУБД.
Собственно база данных и приложения. И, наконец, как результат предыдущих
этапов появляется собственно сама база данных. База данных реализована на
конкретной программно-аппаратной основе, и выбор этой основы позволяет
существенно повысить скорость работы.
Многоуровневая архитектура (концептуальный, логический и физический
уровни) позволяет обеспечить независимость хранимых данных от использующих их
программ. При необходимости можно переписать хранимые данные на другие носители
информации и (или) реорганизовать их физическую структуру, изменив лишь
физическую модель данных. Можно подключить к системе любое число новых
пользователей (новых приложений), дополнив, если надо, логическую модель.
Указанные изменения физической и логической моделей не будут замечены
существующими пользователями системы (окажутся "прозрачными" для
них), так же как не будут замечены и новые пользователи. Следовательно,
независимость данных обеспечивает возможность развития системы баз данных без
разрушения существующих приложений.
Решения, принятые на каждом этапе моделирования и разработки базы данных,
будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие
правильных решений на ранних этапах проектирования.
Концептуальное
моделирование данных
Одна из наиболее распространённых концептуальных моделей данных - модель
"Сущность-Связь" (ER-модель). На использовании разновидностей
ER-модели основано большинство современных подходов к проектированию
реляционных баз данных. Основными понятиями ER-модели являются сущность, связь
и атрибут.
Сущность - это класс однотипных объектов, информация о котором должна
сохраняться и быть доступна. Каждая сущность должна иметь имя, выраженное
существительным в единственном числе. В ER-диаграммах сущность изображается в
виде прямоугольника, содержащего имя сущности.
Экземпляр сущности - это конкретный представитель данной сущности.
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь
некоторые свойства, уникальные для каждого экземпляра этой сущности.
Атрибут сущности - это именованная независимая характеристика, являющаяся
некоторым свойством сущности. Наименование атрибута должно быть выражено
существительным в единственном числе (возможно, с характеризующими
прилагательными). Атрибут изображается в виде эллипса, содержащего имя
атрибута.
Рисунок 1. Изображение сущности и атрибутов сущности на ER-диаграмме
Связь один к одному означает, что одному экземпляру первой сущности
соответствует один экземпляр второй сущности.
Связь один ко многим (1:m)
означает, что одному экземпляру 1ой сущности соответствует несколько
экземпляров 2ой сущности, но не наоборот.
Связь многие ко многим (m:m)
означает, что одному экземпляру 1ой сущности соответствует несколько
экземпляров 2ой сущности и наоборот.
Каждая связь может иметь один из следующих типов связи по членству:
·
Обязательная
связь означает, что обе сущности зависят от наличия связи. Т.е, экземпляр одной
сущности обязан быть связан не менее чем с одним экземпляром другой сущности, и
наоборот;
·
Необязательная
связь означает, что ни одна из сущностей не зависит от наличия связи. Т.е,
экземпляр одной сущности может быть связан с одним или несколькими экземплярами
другой сущности, а может быть и не связан ни с одним экземпляром.
·
Возможная связь
означает, что одна из сущностей зависит от наличия связи. Т.е. один конец связи
необязательный, а другой- обязательный.
При разработке ER-моделей необходимо получить следующую информацию о
предметной области:
1. Список сущностей предметной области.
2. Список атрибутов сущностей.
. Описание взаимосвязей между сущностями.
Рисунок 2. ER-диаграмма
Логическое моделирование данных
Наиболее распространённой логической моделью на сегодняшний день является
реляционная модель. Согласно Дейту, реляционная модель состоит из трех частей:
· Структуры данных (структурная часть);
· Ограничений, накладываемых на данные (целостная часть);
· Набора допустимых операций над данными (манипуляционная
часть).
Структура реляционных данных
Единственной структурой данных, используемой в реляционной модели,
является отношение (relation).
Отношение представляет собой связь между элементами нескольких множеств
атомарных однотипных значений, именуемых доменами. Говорят, что значения
принадлежат к одному и тому же домену, если имеет смысл их сравнение. Атрибутом
отношения называют набор значений, принадлежащих к одному и тому же домену.
Отношения реализуются в виде двумерных таблиц, обладающих следующими
свойствами:
1. Каждая таблица состоит из однотипных строк и имеет уникальное
имя.
2. В каждой позиции таблицы на пересечении строки и столбца может
содержаться только одно значение.
. Строки таблицы обязательно отличаются друг от друга хотя бы
одним значением.
. Столбцам таблицы однозначно присваиваются имена, и в каждом из
них размещаются однородные значения данных
. При выполнении операций с таблицей ее строки и столбцы можно
обрабатывать в любом порядке, независимо от содержания.
Реляционная база данных представляет собой совокупность взаимосвязанных
таблиц, содержащий всю информацию, которую необходимо хранить и обрабатывать.
Схемой базы данных называют список, содержащий имена таблиц, имена атрибутов
таблиц, ключевые атрибуты и внешние ключи.
Рисунок 3. Схема данных
Ограничения
целостности
Во второй части реляционной модели данных определяются два ограничения,
которые должны выполняться в любой реляционной базе данных. Это:
· Целостность сущностей.
· Целостность внешних ключей.
Определение 1. Пусть дано отношение . Подмножество атрибутов отношения будем называть потенциальным ключом,
если обладает следующими свойствами:
1. Свойством уникальности - в отношении не может быть двух различных
кортежей, с одинаковым значением .
2. Свойством минимальности - никакое подмножество в не обладает свойством уникальности.
Любое отношение имеет, по крайней мере, один потенциальный ключ.
Потенциальный ключ, состоящий из одного атрибута, называется простым, а
состоящий из нескольких атрибутов - составным.
Отношение может иметь несколько потенциальных ключей. Традиционно, один
из потенциальных ключей объявляется первичным, а остальные - альтернативными.
Т.к. потенциальные ключи служат идентификаторами объектов предметной области
(т.е. предназначены для различения объектов), то значения этих идентификаторов
не могут содержать неизвестные значения. Это определяет следующее правило
целостности сущностей: Атрибуты, входящие в состав некоторого потенциального
ключа не могут принимать неопределённых (null)-значений.
Различные объекты предметной области, информация о которых хранится в
базе данных, всегда взаимосвязаны друг с другом. Такие взаимосвязи отражаются в
реляционных базах данных при помощи внешних ключей, связывающих несколько
отношений. Т.к. внешние ключи фактически служат ссылками на строки в другом
(или в том же самом) отношении, то эти ссылки не должны указывать на
несуществующие объекты. Это определяет следующее правило целостности внешних
ключей: Внешние ключи не должны быть несогласованными, т.е. для каждого
значения внешнего ключа таблицы должно существовать соответствующее значение
первичного ключа в связанной с ней таблице.
Способы построения логической модели данных
Рассмотрим некоторые из критериев, которые являются безусловно важными с
точки зрения получения качественной базы данных:
· Адекватность базы данных предметной области
· Легкость разработки и сопровождения базы данных
· Скорость выполнения операций обновления данных (вставка,
обновление, удаление кортежей)
· Скорость выполнения операций выборки данных
При разработке схемы базы данных необходимо выполнить следующие условия:
1. Информация в таблицах не должна повторятся (не должно быть
избыточности). Избыточность приводит к проблемам при поиске и обработке данных.
Поэтому желательно, чтобы каждый факт хранился только в одном месте.
2. Поля таблиц по возможности не должны принимать неопределённых
(пустых) значений. Неопределённые значения могут привести к ошибкам при
выполнении вычислений над теми полями таблиц, в которых они встречаются.
Процесс разделения таблиц с целью улучшения их свойств называется
декомпозицией, или нормализацией, а полученные в результате таблицы -
нормализованными. Заметим, что после завершения нормализации большинство таблиц
содержит информацию только об одном объекте или явлении (сущности). Поэтому
наиболее простым способом создания системы нормализованных таблиц является
получение её из диаграммы «Сущность - связь». Перехода от ER-диаграммы к
таблицам состоит из следующих шагов:
. Преобразование сущностей.
a) Каждая простая сущность становится
таблицей.
b) Каждый атрибут сущности становится
атрибутом (столбцом) таблицы.
c) Уникальный идентификатор сущности
становится ключом таблицы.
d) Если в ER-диаграмме присутствовали подтипы сущности, они выносятся в
отдельные таблицы.
2. Преобразование связей
a)
Сущности, связанные обязательной связью типа 1:1, можно объединить в одну
таблицу.
b)
Связи типа 1:1 (возможные) и связи типа 1:m реализуются путем переноса ключевых атрибутов таблиц,
соответствующих сущностям, стоящим со стороны «один» или с обязательного конца
связи, в таблицы, соответствующие сущностям, стоящим со стороны «много» или с
необязательного конца связи, в качестве внешних ключей.
i. Связи типа m:m и необязательные связи реализуются
при помощи промежуточной таблицы, содержащей ключевые атрибуты связываемых
таблиц в качестве внешних ключей.
Рисунок 4. таблица Гости
Рисунок 5. Таблица Номера
Рисунок 6. Таблицы Распределение номеров и Услуги
Рисунок 7. Таблицы Список оказанных услуг и Дни недели
Рисунок 8. Таблицы Сотрудники и Должность
Запросы
С помощью запросов можно просматривать, анализировать и изменять данные
из одной или нескольких таблиц. Они также используются в качестве источника
данных для форм и отчетов.
Запрос на выборку
Запрос на выборку возвращает данные из одной или нескольких таблиц, а
также результаты, которые при желании пользователь может изменить (с некоторыми
ограничениями). Также можно использовать запрос на выборку, чтобы сгруппировать
записи для вычисления сумм, средних значений, пересчета и других действий.
В данном запросе выбор задавался для сотрудников, работающих по
понедельникам и средам, результатом действия запроса является таблица.
Рисунок 10. Создание запроса на выборку в режиме конструктора
Рисунок 11. Таблица результатов запроса на выборку
Вычисления в запросах
В запросах можно выполнять вычисления следующих типов:
Встроенные «итоговые» вычисления для расчета по группам записей или по
всем записям;
Пользовательские вычисления для выполнения расчетов с числовыми и
строковыми значениями или значениями дат для каждой записи с использованием
данных из одного или нескольких полей.
В данном запросе вычислим оплату, произведенную клиентом за номер без
учета стоимости услуг в зависимости от срока пребывания в гостинице.
Рисунок 12. Создание вычисления в запросах в режиме конструктора
Рисунок 13. Построитель выражений для вычисления в запросе
Рисунок 14. Таблица результатов вычислений в запросе
Запросы с параметром
Запрос с параметром - это запрос, при выполнении которого в диалоговом
окне пользователю выдается приглашение ввести данные, например условие для
возращения записей или значений, которое должно содержаться в поле.
Введем код гостя и узнаем количество заказанных им услуг, цену каждой
услуги и стоимость заказанных услуг в общем.
Рисунок 15. Создание запроса с параметром в режиме конструктора
Рисунок 16. Диалоговое окно для ввода данных
Рисунок 17. Результат запроса с параметром
Перекрестные запросы
В перекрестном запросе отображаются данные и результаты статистических
расчетов (такие, как суммы, количество записей и среднее значение), выполненных
по данным из оного поля таблицы. Эти результаты группируются по двум наборам
данных, один из которых расположен в левом столбце таблицы, а второй - в
верхней строке.
Выведем количество свободных мест в занятом гостями номере
Рисунок 18. Создание перекрестного запроса в режиме конструктора
Рисунок 19. Результаты перекрестного запроса
Создание запроса в режиме SQL
Выведем данные о заработной плате сотрудников по возрастанию кода
сотрудника
Рисунок 20 Создание запроса в режиме SQL
Рисунок 21. Результаты запроса в режиме SQL
Разработка форм
Формы предназначены для ввода и просмотра взаимосвязанных данных базы
данных на экране в удобном виде, который может соответствовать привычному для
просмотра документу. Формы можно распечатывать, а также применять для создания
панелей управления в приложении. Любая форма для просмотра, редактирования,
ввода записей в таблицы должна быть предварительно сконструирована.
Создание формы с помощью автоформы
Автоформа создает форму, в которой отображается все поля и записи
выбранной таблицы или запроса. Каждое поле расположено на отдельной строке, с
левой стороны от которой отображается надписи к данному полю.
Создадим автоформу на основе таблицы Гости.
Рисунок 22. Результат автоформы
Создание формы при помощи мастера
моделирование выборка запрос база данные
Мастер форм может создавать форму для одной таблицы и для нескольких
взаимосвязанных таблиц.
Создадим форму из нескольких таблиц: сотрудники, должность, график
дежурства (многотабличная форма). Добавим элемент управления в главную форму
Сотрудники. Элементы управления - это объекты формы или отчета, которые служат
для вывода данных на экран, выполнения макрокоманд или оформления формы или
отчета. В данном случае мы использовали кнопку - для открытия другой связанной
формы, при этом содержимое связанной формы синхронизировано с текущей записью
главной формы.
Рисунок 23. Создание формы Сотрудники при помощи мастера и связанная с
ней форма График дежурства
Создадим форму с использованием такого элемента управления как
подчиненная форма. Это форма, находящаяся внутри другой формы. Первичная форма
называется главной формой, а форма внутри формы называется подчиненной.
Подчиненная форма удобна для вывода данных из таблиц или запросов, связанных с
отношением 1:m. Подчиненная форма может быть
выведена в режиме таблицы или как простая или ленточная форма. Главная форма
может быть выведена только как простая форма. Она может содержать любое число
подчиненных форм, если каждая подчиненная форма помещается в главную форму.
Выведем данные о Гостях и об оказанных им услугах. Подчиненной формой
будет являться форма с данными об услугах
Рисунок 24. Создание формы с помощью мастера (главная форма)
Рисунок 25. Подчиненная форма Список оказанных услуг
Создание формы без помощи мастера
В режиме конструктора выведем данные о номере
Рисунок 26. Создание формы без помощи мастера
Разработка многотабличных форм
Многотабличная форма создается на основе нескольких взаимосвязанных
таблиц и может состоять из одной формы или из основной одной или нескольких
подчиненных форм. Способы создания многотабличной формы с помощью мастера:
. Подчиненные формы;
. Связные формы;
. Многотабличная форма на основе запроса.
Рисунок27. Многотабличная форма на основе запроса
Разработка отчетов
Отчет - это гибкое и эффективное средство для организации данных при
вводе на печать. С помощью отчета имеется возможность вывести необходимые
сведения о том виде, в котором требуется.
В данной курсовой работе отчет создается на основе выходных документов, а
именно счет, предъявляемый при выписке гостя.
Используем мастер по разработке отчетов, он выполняет всю рутинную работу
и позволяет быстро разработать отчет.
Рисунок 28. Создание отчета Счет, предъявляемый при выписке гостя
Создание кнопочной формы
Создание кнопочной формы с помощью диспетчера кнопочных форм.
Кнопочная форма - это форма, элементами которой являются кнопки,
открывающие другие формы и отчеты. Кнопочная форма используется в базе данных в
качестве панели управления приложением, что позволяет легко и быстро
осуществлять доступ к различным данным. Кнопочная форма может состоять из
нескольких страниц, на которых расположены кнопки, открывающие формы, отчеты
или другие страницы кнопочной формы.