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

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Федеральное агентство связи

Сибирский государственный университет телекоммуникаций и информатики

Кафедра ПДСиМ

Курсовой проект

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

Выполнил: ст. гр. АЗ-58

Поселёнова А.И.

Проверил: преп.

Мейкшан Л.И.

Новосибирск

2010

Содержание

1. Цель работы

2. Задание к курсовому проекту

2.1 Этапы разработки базы данных

2.2 Концептуальное моделирование данных

— анализ предметной области, выделение объектов, информация о которых должна храниться в базе данных, определение их атрибутов, связей между объектами и характеристик этих связей;

— построение ER-диаграмм.

2.3 Логическое моделирование данных

— создание таблиц, определение типов данных в каждом поле, ограничений на установку диапазонов допустимых значений, первичных ключей;

— определение внешних ключей и связей между таблицами.

3. Создание запросов

4. Разработка форм

5. Разработка отчетов

6. Создание кнопочной формы

7. Список используемых источников

Цель работы

Целью выполнения курсового проекта по курсу «Банки и базы данных» является:

a. изучение этапов проектирования реляционных баз данных;

b. приобретение практических навыков в разработке и реализации информационных систем;

c. приобретение навыков работы с реляционными базами данных

d. используя средства Microsoft Access, реализовать базу данных в соответствии с индивидуальным заданием.

Задание к курсовому проекту

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

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

Гостиница

База данных должна содержать сведения о следующих объектах:

Распределение номеров по этажам, с указанием общего количества мест в номере, количества свободных мест и проживающих.

Гости — фамилия, имя, отчество, пол, адрес, дата рождения, номер паспорта, дата выдачи, учреждение, выдавшее паспорт, номер комнаты, дата въезда, дата выезда, список оказанных услуг (наименование услуги, количество, цена).

Адресные данные коридорных и горничных и расписание их дежурств.

Выходные документы:

1. Счет, предъявляемый при выписке гостя.

Бизнес-правила

Гости разного пола могут быть поселены в один номер, только будучи супругами.

Горничные обслуживают ряд номеров только одного этажа.

Коридорные обслуживают только один этаж.

Указанные категории персонала имеют скользящий график работы: коридорные — посуточно, горничные посменно.

Сведения о гостях сохраняются в течение года.

Этапы разработки базы данных

Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области.

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

· Сама предметная область

· Модель предметной области

· Концептуальная модель данных

· Логическая модель данных

· Физическая модель данных

· Собственно база данных и приложения

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

Модель предметной области. Модель предметной области — это наши знания о ней. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т. п. Опыт показывает, что текстовый способ представления модели предметной области неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических схем. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами.

Концептуальная модель данных. На следующем, более низком уровне находится концептуальная модель данных предметной области. Концептуальная модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Концептуальная модель данных является начальным прототипом будущей базы данных. Эта модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Основным средством разработки концептуальной модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).

Логическая модель данных — это данные, представленные на языке описания данных конкретной СУБД. Логическая модель данных включает в себя следующие составляющие:

— структура данных;

— ограничения, накладываемые на данные

— операции, производимые над данными.

Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную (объектно-ориентированную модель данных).

Наиболее распространённая модель данных, используемая большинством СУБД — реляционная модель. Поэтому можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

Физическая модель данных. На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает хранение данных средствами конкретной СУБД. Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД. При этом решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Качество физической модели во многом зависит от выбора СУБД.

Собственно база данных и приложения. И, наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы.

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

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

Концептуальное моделирование данных

Одна из наиболее распространённых концептуальных моделей данных — модель «Сущность-Связь» (ER-модель). На использовании разновидностей ER-модели основано большинство современных подходов к проектированию реляционных баз данных. Основными понятиями ER-модели являются сущность, связь и атрибут.

Сущность — это класс однотипных объектов, информация о котором должна сохраняться и быть доступна. Каждая сущность должна иметь имя, выраженное существительным в единственном числе. В ER-диаграммах сущность изображается в виде прямоугольника, содержащего имя сущности.

Экземпляр сущности — это конкретный представитель данной сущности. Экземпляры сущностей должны быть различимы, т. е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.

Атрибут сущности — это именованная независимая характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Атрибут изображается в виде эллипса, содержащего имя атрибута.

Рисунок 1. Изображение сущности и атрибутов сущности на ER-диаграмме

Связь — это ассоциация, поясняющая отношения между сущностями. Графически связь изображается линией, соединяющей две сущности. Каждая связь имеет два конца и одно или два наименования. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности. Каждая связь может иметь один из следующих типов связи по значности:

Связь один к одному означает, что одному экземпляру первой сущности соответствует один экземпляр второй сущности.

Связь один ко многим (1: m) означает, что одному экземпляру 1ой сущности соответствует несколько экземпляров 2ой сущности, но не наоборот.

Связь многие ко многим (m: m) означает, что одному экземпляру 1ой сущности соответствует несколько экземпляров 2ой сущности и наоборот.

Каждая связь может иметь один из следующих типов связи по членству:

Обязательная связь означает, что обе сущности зависят от наличия связи. Т. е, экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности, и наоборот;

Необязательная связь означает, что ни одна из сущностей не зависит от наличия связи. Т. е, экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.

Возможная связь означает, что одна из сущностей зависит от наличия связи. Т. е. один конец связи необязательный, а другой- обязательный.

При разработке ER-моделей необходимо получить следующую информацию о предметной области:

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

Рисунок 2. ER-диаграмма

Логическое моделирование данных

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

· Структуры данных (структурная часть);

· Ограничений, накладываемых на данные (целостная часть);

· Набора допустимых операций над данными (манипуляционная часть).

Структура реляционных данных

Единственной структурой данных, используемой в реляционной модели, является отношение (relation). Отношение представляет собой связь между элементами нескольких множеств атомарных однотипных значений, именуемых доменами. Говорят, что значения принадлежат к одному и тому же домену, если имеет смысл их сравнение. Атрибутом отношения называют набор значений, принадлежащих к одному и тому же домену.

Отношения реализуются в виде двумерных таблиц, обладающих следующими свойствами:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. В каждой позиции таблицы на пересечении строки и столбца может содержаться только одно значение.

3. Строки таблицы обязательно отличаются друг от друга хотя бы одним значением.

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных

5. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке, независимо от содержания.

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

Рисунок 3. Схема данных

Ограничения целостности

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

· Целостность сущностей.

· Целостность внешних ключей.

Определение 1. Пусть дано отношение. Подмножество атрибутов отношения будем называть потенциальным ключом, если обладает следующими свойствами:

1. Свойством уникальности — в отношении не может быть двух различных кортежей, с одинаковым значением.

2. Свойством минимальности — никакое подмножество в не обладает свойством уникальности.

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

Отношение может иметь несколько потенциальных ключей. Традиционно, один из потенциальных ключей объявляется первичным, а остальные — альтернативными. Т.к. потенциальные ключи служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов), то значения этих идентификаторов не могут содержать неизвестные значения. Это определяет следующее правило целостности сущностей: Атрибуты, входящие в состав некоторого потенциального ключа не могут принимать неопределённых (null)-значений.

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

Способы построения логической модели данных

Рассмотрим некоторые из критериев, которые являются безусловно важными с точки зрения получения качественной базы данных:

· Адекватность базы данных предметной области

· Легкость разработки и сопровождения базы данных

· Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей)

· Скорость выполнения операций выборки данных

При разработке схемы базы данных необходимо выполнить следующие условия:

1. Информация в таблицах не должна повторятся (не должно быть избыточности). Избыточность приводит к проблемам при поиске и обработке данных. Поэтому желательно, чтобы каждый факт хранился только в одном месте.

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

Процесс разделения таблиц с целью улучшения их свойств называется декомпозицией, или нормализацией, а полученные в результате таблицы — нормализованными. Заметим, что после завершения нормализации большинство таблиц содержит информацию только об одном объекте или явлении (сущности). Поэтому наиболее простым способом создания системы нормализованных таблиц является получение её из диаграммы «Сущность — связь». Перехода от ER-диаграммы к таблицам состоит из следующих шагов:

1. Преобразование сущностей.

Каждая простая сущность становится таблицей.

Каждый атрибут сущности становится атрибутом (столбцом) таблицы.

Уникальный идентификатор сущности становится ключом таблицы.

Если в ER-диаграмме присутствовали подтипы сущности, они выносятся в отдельные таблицы.

2. Преобразование связей

a) Сущности, связанные обязательной связью типа 1: 1, можно объединить в одну таблицу.

b) Связи типа 1:1 (возможные) и связи типа 1: m реализуются путем переноса ключевых атрибутов таблиц, соответствующих сущностям, стоящим со стороны «один» или с обязательного конца связи, в таблицы, соответствующие сущностям, стоящим со стороны «много» или с необязательного конца связи, в качестве внешних ключей.

i. Связи типа m: m и необязательные связи реализуются при помощи промежуточной таблицы, содержащей ключевые атрибуты связываемых таблиц в качестве внешних ключей.

Рисунок 4. таблица Гости

Рисунок 5. Таблица Номера

Рисунок 6. Таблицы Распределение номеров и Услуги

Рисунок 7. Таблицы Список оказанных услуг и Дни недели

Рисунок 8. Таблицы Сотрудники и Должность

Рисунок 9. Таблицы График дежурства и Обслуживание номеров

Запросы

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

Запрос на выборку

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

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

Рисунок 10. Создание запроса на выборку в режиме конструктора

Рисунок 11. Таблица результатов запроса на выборку

Вычисления в запросах

В запросах можно выполнять вычисления следующих типов:

— Встроенные «итоговые» вычисления для расчета по группам записей или по всем записям;

— Пользовательские вычисления для выполнения расчетов с числовыми и строковыми значениями или значениями дат для каждой записи с использованием данных из одного или нескольких полей.

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

Рисунок 12. Создание вычисления в запросах в режиме конструктора

Рисунок 13. Построитель выражений для вычисления в запросе

Рисунок 14. Таблица результатов вычислений в запросе

Запросы с параметром

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

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

Рисунок 15. Создание запроса с параметром в режиме конструктора

Рисунок 16. Диалоговое окно для ввода данных

Рисунок 17. Результат запроса с параметром

Перекрестные запросы

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

Выведем количество свободных мест в занятом гостями номере

Рисунок 18. Создание перекрестного запроса в режиме конструктора

Рисунок 19. Результаты перекрестного запроса

Создание запроса в режиме SQL

Выведем данные о заработной плате сотрудников по возрастанию кода сотрудника

Рисунок 20 Создание запроса в режиме SQL

Рисунок 21. Результаты запроса в режиме SQL

Разработка форм

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

Создание формы с помощью автоформы

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

Создадим автоформу на основе таблицы Гости.

Рисунок 22. Результат автоформы

Создание формы при помощи мастера

моделирование выборка запрос база данные

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

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

Рисунок 23. Создание формы Сотрудники при помощи мастера и связанная с ней форма График дежурства

Создадим форму с использованием такого элемента управления как подчиненная форма. Это форма, находящаяся внутри другой формы. Первичная форма называется главной формой, а форма внутри формы называется подчиненной. Подчиненная форма удобна для вывода данных из таблиц или запросов, связанных с отношением 1: m. Подчиненная форма может быть выведена в режиме таблицы или как простая или ленточная форма. Главная форма может быть выведена только как простая форма. Она может содержать любое число подчиненных форм, если каждая подчиненная форма помещается в главную форму.

Выведем данные о Гостях и об оказанных им услугах. Подчиненной формой будет являться форма с данными об услугах

Рисунок 24. Создание формы с помощью мастера (главная форма)

Рисунок 25. Подчиненная форма Список оказанных услуг

Создание формы без помощи мастера

В режиме конструктора выведем данные о номере

Рисунок 26. Создание формы без помощи мастера

Разработка многотабличных форм

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

1. Подчиненные формы;

2. Связные формы;

3. Многотабличные формы без подчиненных и связных форм;

4. Многотабличная форма на основе запроса.

Рисунок27. Многотабличная форма на основе запроса

Разработка отчетов

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

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

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

Рисунок 28. Создание отчета Счет, предъявляемый при выписке гостя

Создание кнопочной формы

Создание кнопочной формы с помощью диспетчера кнопочных форм.

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

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

Рисунок 29. Кнопочная форма

Рисунок 30. Приложение Гости

Рисунок 31. Приложение Счет, предъявляемый при выписке гостя

Список используемых источников

1. Е. В. Колмогорова, Л. И. Мейкшан, В. А. Астапчук. Создание баз данных в среде Microsoft Access. Методические указания к лабораторному практикуму. — Новосибирск, СибГУТИ, 2008.

2. В. А. Астапчук, Е. В. Колмогорова. Проектирование реляционных баз данных. Методические указания к выполнению курсовых работ и индивидуальных заданий. — Новосибирск, СибГУТИ, 2003.

3. Конспект лекций по курсу «Банки и базы данных». Мейкшан Л. И.

ПоказатьСвернуть
Заполнить форму текущей работой