Информационная система гостиничного комплекса

ВВЕДЕНИЕ

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

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

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

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

автоматизированный гостиничный информационный программный

ПОСТАНОВКА ЗАДАЧИ

) Получить перечень и общее число фирм, забронировавших места в объеме, не менее указанного, за весь период сотрудничества, либо за некоторый период.

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

)Получить количество свободных номеров на данный момент.

)Получить сведения о количестве свободных номеров с указанными характеристиками.

)Получить сведения о конкретном свободном номере: в течение какого времени он будет пустовать и о его характеристиках.

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

)Получить данные об объеме бронирования номеров данной фирмой за указанный период, и каким номерам отдавались предпочтения.

)Получить список недовольных клиентов и их жалобы.

)Получить данные о рентабельности номеров с определенными характеристиками: соотношение об объеме продаж номеров к накладным расходам за указанный период.

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

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

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

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

)Получить сведения о конкретном человеке, сколько раз он посещал гостиницу, в каких номерах и в какой период останавливался, какие счета оплачивал.

)Получить сведения о конкретном номере: кем он был занят в определенный период.

)Получить процентное отношение всех номеров к номерам, бронируемым партнерами.

Для этого необходимо выполнить следующий комплекс работ:

Построить инфологическую концептуальную модель (ER - модель используя Erwin 4.0 или PowerDesigner 12.5), для чего:

а) проанализировав предметную область, при необходимости уточнив и дополнив ее, выявить необходимый набор сущностей;

б) определить требуемый набор атрибутов для каждой сущности, выделив идентифицирующие атрибуты;

в) классифицировать сущности (стержневые, ассоциативные и пр.);

г) определить связи между объектами;

д) формализовать связи между объектами (множественность, условность и т.д.);

. Получить реляционную схему из ER-модели, для чего:

а) построить набор необходимых отношений базы данных;

б) выделить первичные и внешние ключи определенных отношений;

в) привести полученные отношения к третьей нормальной форме;

г) определить ограничения целостности для внешних ключей отношений и для отношений в целом;

. Используя имеющуюся СУБД MS Access 2003 создать спроектированную базу данных.

. На языке SQL записать выражения для указанных в задании типов запросов. Проверить работоспособность написанных запросов в интерактивном режиме.

. Выбрав средства разработки приложений (Delphi 7.0), реализовать законченное приложение, работающее с созданной базой данных. Приложение должно:

а) заносить информацию в таблицы созданной базы данных;

б) выполнять необходимые действия по модификации и удалению данных в таблицах созданной базы данных;

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

г) выполнять запросы из задания.

1. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

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

Задачи проектирования базы данных.

При проектировании базы данных решаются три основные задачи:

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

. «Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было по возможности эффективным?» Эту проблему называют проблемой логического проектирования баз данных.

. «Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создать дополнительные структуры данных (например, индексы)?» Эту проблему называют проблемой физического проектирования баз данных.

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

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

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

.1 Концептуальное проектирование

«Информационная система гостиничного комплекса»

Гостиничный комплекс состоит из нескольких зданий-гостиниц (корпусов). Каждый корпус имеет ряд характеристик, таких, как класс отеля (двух-, пятизвездочные), количество этажей в здании, общее количество комнат, комнат на этаже, местность номеров (одно-, двух-, трехместные и т.д.), наличие служб быта: ежедневная уборка номера, прачечная, химчистка, питание (рестораны, бары) и развлечения (бассейн, сауна, бильярд и пр.). От типа корпуса и местности номера зависит сумма оплаты за него. Химчистка, стирка, дополнительное питание, все развлечения производятся за отдельную плату.

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

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

.2 Инфологическая модель

Название базы данных «Информационная система гостиничного комплекса»

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

Броня (Номера_комнат, Номер_корпуса, Класс_корпуса, Общее_кол_комнат, Кол_одном_номеров, Кол_двухм_номеров, Кол_трёхм_номеров, Кол_четырёхм_номеров);

Учёт номеров (Код_номера, Бро_Номера_комнат, Код_корпуса, Местность_номера, Бронирован);

Затраты постояльцев (Код_Затраты, Наименование_организации, ФИО_клиента, Код_клиента, Наименование_услуги, Весь_долг_гостинице);

Жалобы клиентов (Код_клиента, Номера_комнат, ФИО_клиента, Зат_Наименование_организа, Дата_жалобы, Жалоба);

Корпуса (Номер_корпуса, Класс_корпуса, Общее_кол_комнат, Кол_одном_номеров, Кол_двухм_номеров, Кол_трёхм_номеров, Кол_четырёхм_номеров);

ЕR - диаграмма инфологической модели базы данных «Информационная система гостиничного комплекса», приведена в приложении 1.

.3 Логическое проектирование базы данных

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

Фаза логического проектирования состоит из двух этапов.

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

• преобразование локальной концептуальной модели данных в локальную логическую модель (что предусматривает преобразование сложных связей и атрибутов (например, связей типа M:N, рекурсивных и связей с атрибутами), перепроверка связей типа 1:1, удаление избыточных связей);

• определение набора отношений исходя из структуры локальной логической модели;

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

• проверка модели в отношении транзакций пользователей (убедиться, что модель позволяет выполнять все действия пользователя с данными);

• определение требований поддержки целостности данных;

• создание графического представления локальных логических моделей;

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

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

• слияние локальных логических моделей данных в единую глобальную логическую модель данных (устранение противоречий объединения - анализ имен объектов, связей и атрибутов на пропуски и дубликаты, проверка корректности ссылок, соблюдения ограничений целостности, приведения в порядок бизнес-правил);

• проверка глобальной логической модели данных;

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

• создание графического представления глобальной логической модели;

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

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

.3.1 Выбор требуемой СУБД и программного обеспечения

В качестве средства проектирования базы данных выбрано СУБД MS ACCESS 2003 (мощная программа для управления базами данных, позволяет быстро работать с большими объемами данных и в ней предусмотрены все необходимые средства для работы с данными).

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

В качестве среды разработки приложений базы данных была выбрана среда визуального программирования DELPHI 7.0. Основной причиной выбора этого языка является: возможность работы с базой данных и лёгкость в организации доступа к баз.

Для проектирования инфологической модели было выбрано средство MS VISIO XP. Для проектирования логической и физической структуры базы данных использовали PowerDesigner12.5

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

Логическое проектирование применяется для перенесения концептуального проекта на внутреннюю модель выбранной СУБД. При этом все объекты концептуальной модели отображаются на модель, с определённой структурой, которая используется выбранным программным обеспечением. Для реляционной СУБД логическое проектирование заключается в проектировании таблиц. Логического проектирования базы данных “Информационная система гостиничного комплекса”. Выполнено с использованием CАSE- средства - PowerDesigner 12.5. Получена сущность-Связь (ER-модель), она предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных.модель сущность-связь представлено в приложении 2.

.4 Физическое проектирование базы данных

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

Различают два уровня физической модели:

• трансформационную модель;

• модель СУБД.

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

Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД.

Физический уровень представления модели зависит от выбранного сервера.win поддерживает более 20 реляционных и не реляционных баз данных. По умолчанию ER-win генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы в ручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели.

Физическое проектирование базы данных - процесс создания конкретной реализации БД, размещаемой во вторичной памяти (например, накопители типа винчестер) вычислительной машины. В процессе физического проектирования выполняется отображение созданной глобальной логической модели на особенности конкретной СУБД.

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

Этап 1. Перенос глобальной логической модели в среду целевой СУБД:

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

• реализация бизнес-правил (зависит от СУБД, лучший вариант - полное использование возможностей СУБД, не переносить бизнес-правила в приложения).

Этап 2. Проектирование физического представления БД:

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

• выбор файловой структуры (для оптимальной файловой организации);

• определение вторичных индексов (для ускорения выполнения транзакций по не ключевым атрибутам и ссылкам);

• анализ необходимости введения контролируемой избыточности данных (процесс обратный нормализации, применяется для повышения производительности системы, только если исчерпаны другие возможности, может привести к снижению гибкости и расширяемости БД, а также усложняет реализацию и обновление данных);

• определение требований к дисковой памяти (в том числе учет требований для обоснования приобретения нового оборудования).

Этап 3. Разработка механизмов защиты:

• разработка пользовательских представлений (видов);

• определение прав доступа.

Этап 4. Организация мониторинга и настройка функционирования системы (требуется для устранения ошибочных проектных решений и изменения требований к системе (например, отказ от более дорогого оборудования, улучшение психологического комфорта пользователей по работе с системой); настройка БД производится фактически постоянно, а не только при первом запуске системы, что позволяет оперативно реагировать на изменения в состоянии системы и требования пользователей; внесение любых изменений должно производиться обдуманно и осторожно, с учетом глобального влияния изменений, для оценки влияния изменений применяют дубликат системы).

Осуществляем проектирование основных объектов базы данных (сущностей) в среду СУБД MS ACCESS 2003 и проектируем схему данных.

ER - диаграмма физической структуры базы данных приведена в приложении 3. Вид и содержание сущностей приведена в приложении 3.

Схема данных приведена в приложении 4.

Вид и содержание сущности приведены в приложении 5.коды, программный модуль для создания сущности:

Сущность - «Броня»:

SQL-код:

create table Броня (

Номера_комнат VARCHAR(20) not null,

Код_корпуса CHAR(10),

Жал_ФИО_клиента VARCHAR(20),

Номер_корпуса VARCHAR(20),

Наименование_организации VARCHAR(20),

ФИО_клиента VARCHAR(20),

Дата_бронирования DATE,

Дата_заселения DATE,

Дата_выселения DATE,

Кол_людей VARCHAR(20),

Скидка VARCHAR(20),PK_БРОНЯ primary key (Номера_комнат));

Сущность - «Жалобы клиентов»:

SQL-код:table Жалобы_клиентов (

ФИО_клиента VARCHAR(20) not null,

Зат_Наименование_организации VARCHAR(20),

Наименование_организации VARCHAR(20),

Дата_жалобы DATE,

Жалоба VARCHAR(50),PK_ЖАЛОБЫ_КЛИЕНТОВ primary key (ФИО_клиента));

Сущность - «Затраты постояльцев» :

SQL-код:table Затраты_постояльцев (

Наименование_организации VARCHAR(20) not null,

ФИО_клиента VARCHAR(20),

Наименование_услуги VARCHAR(20),

Весь_долг_гостинице VARCHAR(20),PK_ЗАТРАТЫ_ПОСТОЯЛЬЦЕВ primary key (Наименование_организации));

Сущность - «Корпуса»:

SQL-код:table Корпуса (

Код_корпуса CHAR(10) not null,

Номер_корпуса VARCHAR(20) not null,

Класс_корпуса VARCHAR(20) not null,

Общее_кол_комнат VARCHAR(20),

Кол_одном_номеров VARCHAR(20),

Кол_двухм_номеров VARCHAR(20),

Кол_трёхм_номеров VARCHAR(20),

Кол_четырёхм_номеров VARCHAR(20),

constraint PK_КОРПУСА primary key (Код_корпуса));

Сущность - «Учёт номеров»:

SQL-код:

create table Учёт_номеров (

Код_номера CHAR(10) not null,

Бро_Номера_комнат VARCHAR(20),

Код_корпуса CHAR(10),

Номер_корпуса VARCHAR(20) not null,

Номера_комнат VARCHAR(20),

Местность_номера VARCHAR(20),

Бронирован VARCHAR(20),PK_УЧЁТ_НОМЕРОВ primary key (Код_номера),AK_IDENTIFIER_1_УЧЁТ_НОМ unique (Номер_корпуса));

SQL-коды, программный модуль для создания связей:

Связь - «Броня/Корпуса»:

SQL-код:

alter table Броняconstraint FK_БРОНЯ_RELATIONS_КОРПУСА foreign key (Код_корпуса)

references Корпуса (Код_корпуса);

Связь - «Броня/Жалобы клиентов»:

SQL-код:

alter table Броня

add constraint FK_БРОНЯ_RELATIONS_ЖАЛОБЫ_К foreign key (Жал_ФИО_клиента)Жалобы_клиентов (ФИО_клиента);

Связь - «Жалобы клиентов/Затраты постояльцев»:

SQL-код:table Жалобы_клиентовconstraint FK_ЖАЛОБЫ_К_RELATIONS_ЗАТРАТЫ_ foreign key (Зат_Наименование_организации)Затраты_постояльцев (Наименование_организации);

Связь - «Учёт номеров/Корпуса»:

SQL-код:

alter table Учёт_номеровconstraint FK_УЧЁТ_НОМ_RELATIONS_КОРПУСА foreign key (Код_корпуса)

references Корпуса (Код_корпуса);

Связь - «Учёт номеров/Броня»:

SQL-код:table Учёт_номеровconstraint FK_УЧЁТ_НОМ_RELATIONS_БРОНЯ foreign key (Бро_Номера_комнат)Броня (Номера_комнат);

2. РАЛИЗАЦИЯ БАЗЫ ДАННЫХ

Спроектированная база данных "Информационная система гостиничного комплекса" создана в СУБД MS ACCESS 2003.

.1 Организация ввода данных в базу данных

Для ввода данных базы данных "Информационная система гостиничного комплекса" разработана экранная форма ввода данных в среде визуального программирования Delphi7.0 с компонентами доступа к БД MS ACCESS - на основе сущности "Броня".

Вид экранной формы "Броня" приведён в приложении 6

.2 Реализация запросов

Реализуем запросы описанные в разделе "Постановка задачи":

Запрос 1:

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

SQL код:Броня.Наименование_организации, Броня.Дата_бронированияБроня(((Броня.Дата_бронирования) Between [Введите первую дату периода] And [Введите вторую дату периода]));

Запрос 2:

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

SQL код:Броня.ФИО_клиента, Броня.Наименование_организации, Учёт_номеров.Код_номера, Учёт_номеров.Местность_номера, Броня.Дата_заселенияБроня INNER JOIN Учёт_номеров ON Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат(((Броня.Дата_заселения) Between [Введите первую дату периода] And [Введите вторую дату периода]));

Запрос 3:

Получить количество свободных номеров на данный момент.

SQL код:Броня.Номера_комнат, Учёт_номеров.Бронирован, Date() AS Выражение1Броня INNER JOIN Учёт_номеров ON Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат(((Учёт_номеров.Бронирован)="нет"));

Запрос 4:

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

SQL код:Броня.Номера_комнат, Броня.Броня, Корпуса.Номер_корпуса, Корпуса.Класс_корпуса, Учёт_номеров.Местность_номера(Корпуса INNER JOIN Броня ON Корпуса.Код_корпуса=Броня.Код_корпуса) INNER JOIN Учёт_номеров ON (Корпуса.Код_корпуса=Учёт_номеров.Код_корпуса) AND (Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат)(((Броня.Броня)="нет"));

Запрос 5:

Получить сведения о конкретном свободном номере: в течение какого времени он будет пустовать и о его характеристиках.

SQL код:Учёт_номеров.Бро_Номера_комнат, Учёт_номеров.Бронирован, Учёт_номеров.Местность_номера, Броня.Номер_корпуса, Корпуса.Класс_корпуса(Корпуса INNER JOIN Броня ON Корпуса.Код_корпуса = Броня.Код_корпуса) INNER JOIN Учёт_номеров ON (Корпуса.Код_корпуса = Учёт_номеров.Код_корпуса) AND (Броня.Номера_комнат = Учёт_номеров.Бро_Номера_комнат)BY Учёт_номеров.Бро_Номера_комнат, Учёт_номеров.Бронирован, Учёт_номеров.Местность_номера, Броня.Номер_корпуса, Корпуса.Класс_корпуса(((Учёт_номеров.Бро_Номера_комнат)=[Введите номер свободной коннаты]) AND ((Учёт_номеров.Бронирован)="Нет"));

Запрос 6:

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

SQL код:Броня.Номера_комнат, Броня.Броня, Броня.Дата_выселения(Корпуса INNER JOIN Броня ON Корпуса.Код_корпуса=Броня.Код_корпуса) INNER JOIN Учёт_номеров ON (Корпуса.Код_корпуса=Учёт_номеров.Код_корпуса) AND (Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат)(((Броня.Броня)="да") AND ((Броня.Дата_выселения)<=[Введите дату]));

Запрос 7:

Получить данные об объеме бронирования номеров данной фирмой за

SQL код:Броня.Наименование_организации, Броня.Дата_заселения, Броня.Номер_корпуса, Броня.Номера_комнатБроня INNER JOIN Учёт_номеров ON Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат(((Броня.Наименование_организации)=[Введите фирму]) AND ((Броня.Дата_заселения) Between [Введите первую дату] And [Введите вторую дату]));

Запрос 8:

Получить список недовольных клиентов и их жалобы.

SQL код:Жалобы_клиентов.ФИО_клиента, Жалобы_клиентов.Зат_Наименование_организации, Жалобы_клиентов.Жалоба, Жалобы_клиентов.Дата_жалобыЖалобы_клиентов;

Запрос 10:

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

SQL код:Броня.ФИО_клиента, Броня.Наименование_организации, Броня.Номера_комнат, Затраты_постояльцев.Весь_долг_гостинице, Жалобы_клиентов.Жалоба, Затраты_постояльцев.Наименование_услуги((Броня INNER JOIN Учёт_номеров ON Броня.Номера_комнат = Учёт_номеров.Бро_Номера_комнат) INNER JOIN Жалобы_клиентов ON Броня.Номера_комнат = Жалобы_клиентов.Номера_комнат) INNER JOIN Затраты_постояльцев ON Жалобы_клиентов.Код_клиента = Затраты_постояльцев.Код_клиента(((Броня.Номера_комнат)=[Введите номер]));

Запрос 11:

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

SQL код:Броня.Наименование_организации, Броня.Скидка, Броня.Дата_бронированияБроня INNER JOIN Учёт_номеров ON Броня.Номера_комнат=Учёт_номеров.Бро_Номера_комнат(((Броня.Дата_бронирования) Between [Введите первую дату] And [Введите вторую дату]));

Запрос 12:

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

SQL код:Броня.ФИО_клиента, Броня.Наименование_организации, Броня.Номер_корпуса, Броня.Номера_комнатБроняBY Броня.ФИО_клиента, Броня.Наименование_организации, Броня.Номер_корпуса, Броня.Номера_комнат(((Броня.Номер_корпуса)=[Введите номер корпуса]))BY Броня.ФИО_клиента;

Запрос 13:

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

SQL код:Броня.ФИО_клиента, Броня.Наименование_организации, Броня.Дата_бронирования, Броня.СкидкаБроня(((Броня.Дата_бронирования) Between [Введите первую дату периода] And [Введите вторую дату периода]));

Запрос 14:

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

SQL код:Броня.ФИО_клиента, Броня.Номера_комнат, Броня.Дата_бронирования, Броня.Дата_заселения, Броня.Дата_выселения, Затраты_постояльцев.Весь_долг_гостинице, Затраты_постояльцев.Наименование_услуги(Броня INNER JOIN Жалобы_клиентов ON Броня.Номера_комнат = Жалобы_клиентов.Номера_комнат) INNER JOIN Затраты_постояльцев ON Жалобы_клиентов.Код_клиента = Затраты_постояльцев.Код_клиента(((Броня.ФИО_клиента)=[Введите фамилию клиента]));

Запрос 14:

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

SQL код:Броня.Номера_комнат, Броня.ФИО_клиента, Броня.Наименование_организации, Броня.Дата_заселенияБроня(((Броня.Номера_комнат)=[Введите номер комнаты]) AND ((Броня.Дата_заселения) Between [Введите первую дату периода] And [Введите вторую дату периода]));

Результаты выполнения запросов приведены в приложении 7.

.3 Получение отчёта

Отчёт создан в среде визуального программирования Delphi7.0.

Отчёт получен на основании информации из сущностей: «Броня», «Учёт номеров». Отражает " Броня-учет номеров".

Форма отчёта приведена в приложении 8.

ЗАКЛЮЧЕНИЕ

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

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

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

ЛИТЕРАТУРА

Попов В.Б Delphi для школьников: учебно-методическое пособие/В.Б Попов. - М.: Финансы и статистика; ИНФРА-М, 2014.

Гришин Ю.М. Delphi для программистов - М.: Финансы и статистика; ИНФРА-М, 2011.

ПРИЛОЖЕНИЯ

Приложение 1

ЕR - диаграмма инфологической модели базы банных ”Информационная система гостиничного комплекса”

Приложение 2

”Информационная система гостиничного комплекса”

Приложение 3

Вид и содержание сущностей базы данных

“Информационная система гостиничного комплекса”

Сущность «Броня»:

Сущность «Жалобы клиентов»:

Сущность «Затраты постояльцев»:

Сущность «Корпуса»:

Сущность «Учёт номеров»:

Приложение 4

Экранная форма "Броня" базы данных

“Информационная система гостиничного комплекса”

Форма ввода данных на основе сущности «Броня»:

Приложение 5

Результаты выполнения запросов базы данных

“Информационная система гостиничного комплекса”

Запрос 1:

Запрос 2:

Запрос 3:

Запрос 4:

Запрос 5:

Запрос 6:

Запрос 7:

Запрос 8:

Запрос 10:

Запрос 11:

Запрос 12:

Запрос 13:

Запрос 14:

Запрос 15:

Приложение 6

Форма отчёта базы данных

“Информационная система гостиничного комплекса”

Форма отчёта ввода данных на основе сущностей «Броня», «Учёт номеров»: