Разработка базы данных для автоматизации работы с данными с применением СУБД Access 2010

СОДЕРЖАНИЕ Введение

1. Описание предметной области

2. Проектирование базы данных

2.1 Инфологическое проектирование

2.2 Даталогическое проектирование

3. Программное обеспечение

3.1 Разработка функциональной структуры

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

3.3 Формирование запросов и отчетов Заключение Список используемых источников Приложение, А Приложение В

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

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

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

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

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

Объектом является туристическое агентство.

Целью курсового проекта является разработка базы данных для автоматизации работы с данными с применением СУБД Access 2010.

Для достижения данной цели необходимо решить ряд задач:

— изучить основные возможности Microsoft Access;

— получить и обработать необходимую информацию по разрабатываемой базе данных;

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

Для решения поставленных задач в данном курсовом проекте рассмотрены основные понятия баз данных: структура простейшей базы данных, компоненты базы данных Microsoft Access. Представлен электронный вариант базы данных «Туристическое агентство», в которой хранятся данные о клиентах, которые хотят поехать отдыхать.

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

1. Описание предметной области

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

— список гостиниц, в которых может остановиться клиент;

— список номеров разных категорий в этих гостиницах;

— список вариантов питания, предоставляемых в гостиницах;

— список дополнительных услуг (фитнес, катамараны и т. д.).

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

Достаточно часто клиенты обращались с просьбой подобрать «горящий» тур с минимальной оплатой или тур какого-то конкретного типа — автобусный, горнолыжный, лечебный и т. д. Выполнить такой поиск по бумажным документам было достаточно сложно.

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

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

Существующая технология выбора и расчета тура обладает рядом недостатков:

— низкая производительность труда;

— низкая оперативность;

— несовершенство организации сбора и регистрации информации;

— многократный ввод и дублирование данных;

— высокая трудоемкость составления итоговых и аналитических отчетов;

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

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

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

— вести оперативную обработку данных;

— проводить анализ по заказам и продажам туров;

— получать отчет на любой стадии ведения учета;

— организовать выдачу результатов в удобной форме.

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

2. Проектирование базы данных

2.1 Инфологическое проектирование

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

Сущность — любой различимый объект, информацию о котором необходимо хранить в базе данных. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром — Москва, Киев и т. д.

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

Сущность СТРАНА предназначена для хранения данных о странах, в которых располагаются отели или проводятся туры.

Сущность «ГОРОД» хранит данные о городах, в которых находятся отели.

Сущность «ОТЕЛЬ» предназначена для хранения данных об отеле.

Сущность «НОМЕРНОЙ ФОНД» хранит данные о номерном фонде отеля.

Сущность «ТИП НОМЕРА» предназначения для хранения информации о типах номеров в номерных фондах отелей.

Сущность «КАТЕГОРЯ ОТЕЛЯ» хранит данные данных о категории, к которой принадлежит отель.

Сущность «ПИТАНИЕ» хранит данные о категориях питания, которые предоставляет отель.

Сущность «ТИП ПИТАНИЯ» предназначения для хранения информации о типах питания в отелях.

Сущность «ТУР» предназначена для хранения данных о турах, предлагаемых агентством.

Сущность «СТАТУС ТУРА» предназначена для хранения данных о текущем статусе тура.

Сущность «ТИП ТУРА» предназначена для хранения данных о типе тура.

Сущность «СПИСОК ОТЕЛЕЙ ТУРА» предназначена для хранения информации о списке отелей для данного тура.

Сущность «СПИСОК СЕРВИСОВ» предназначена для хранения информации о списке сервисов, предоставляемых в туре.

Сущность «ВИД ДОП. УСЛУГ» предназначена для хранения информации о списке дополнительных услуг, предоставляемых в данном туре.

Сущность «КЛИЕНТ» предназначена для хранения данных о клиенте агентства.

Сущность «ЗАКАЗ» предназначена для хранения данных о заказе туров, которые сделал клиент.

Сущность «ЗАКАЗАННЫЕ СЕРВИСЫ» предназначена для хранения информации о списке сервисов, заказанных клиентом в туре.

Диаграмма уровня сущностей представлена на рисунке 2.1.

Связь — ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. Число сущностей, участвующих в связи, называют степенью связи. В основном распространены связи степени 2, их часто называют бинарными. Существует три вида бинарных связей: [2]

— 1:1 («один-к-одному») — одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа;

— 1: N («один-ко-многим») — одиночный экземпляр одной сущности связан с множество экземпляров сущности другого типа;

— N: M («многие-ко-многим») — множество экземпляров одной сущности связано с множество экземпляров сущности другого типа.

Рисунок 2.1 — ER-диаграмма уровня сущностей Рассмотрим связи между сущностями нашей модели (см. таблицу 2.1).

Таблица 2.1 — Описание связей

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

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

ER-диаграмма модели данных уровня полных атрибутов показана на рисунке 2.2

Рисунок 2.2 — ER-диаграмма уровня атрибутов

2.2 Даталогическое проектирование

Преобразуем полученную логическую модель БД в физическую. Для этого каждую сущность представим в виде таблицы. Имя сущности становится именем этой таблицы. Каждый атрибут сущности преобразуется в столбец с тем же именем. Атрибуты, входящие в состав уникального идентификатора сущности, преобразуются в первичный ключ таблицы. [3]

В результате преобразования получается 16 таблиц. Структуры основных из них приведены на рисунках 2.3 — 2. 19).

Рисунок 2.3 — Структура таблицы КЛИЕНТ Рисунок 2. 4- Структура таблицы ТУР Рисунок 2. 5 — Структура таблицы ЗАКАЗ Рисунок 2. 6- Структура таблицы ОТЕЛЬ Рисунок 2.7 — Структура таблицы ГОРОД Рисунок 2.8 — Структура таблицы ДОПСЕРВИС Рисунок 2.9 — Структура таблицы ТИП ТУРА Рисунок 2.10 — Структура таблицы ТИП ПИТАНИЯ Рисунок 2.11 — Структура таблицы ТИП НОМЕРА Рисунок 2.12 — Структура таблицы СТРАНА Рисунок 2.13 — Структура таблицы СТАТУС ТУРА Рисунок 2.14 — Структура таблицы СПИСОК СЕРВИСОВ Рисунок 2.15 — Структура таблицы СПИСОК ОТЕЛЕЙ ТУРА Рисунок 2.16 — Структура таблицы НОМЕРНОЙ ФОНД Рисунок 2.17 — Структура таблицы ЗАКАЗАННЫЕ СЕРВИСЫ Рисунок 2.18 — Структура таблицы КАТЕГОРИЯ ОТЕЛЯ Рисунок 2.19 — Структура таблицы ПИТАНИЕ Схема данных приведена в Приложении А

3. Программное обеспечение

3.1 Разработка функциональной структуры

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

— ввод информации по гостиницам (описание номеров и питания);

— ввод данных по турам;

— ввод данных по дополнительным сервисам;

— поиск тура по критериям клиента;

— расчет заказа клиента;

— работа с нормативно-справочной информацией.

Рисунок 3.1 -Главное меню приложения

Для организации навигации между режимами работы разработаем меню приложения. В нем будет определено 6 пунктов — в соответствии с основными направлениями работы, главная кнопочная форма представлена на рисунке 3.1:

1. Клиенты — для регистрации клиентов

2. Заказы — для регистрации клиентов и заказов

3. Туры — просмотр описания туров

4. Отели — просмотр описания отелей

5. Отчеты — для получения отчетов о деятельности компании

6. Справочники — для работы со справочной информацией

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

Формы — это средства для ввода и редактирования информации, а так же просмотра результатов запросов выборки, создания пользовательского меню и отображения диаграмм. Основное назначение формы — предоставить средства для заполнения только тех полей, которые ему требуется. Одновременно с этим в форме можно размещать специальные элементы управления (раскрывающиеся списки, переключатели, флажки) для автоматизации ввода. Формы разделяются на две основные группы: однотабличные и многотабличные формы. [4]

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

— в один столбец;

— ленточная;

— табличная;

— выровненная.

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

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

Рисунок 3.2 — Макет формы для ввода и редактирования типов туров Рисунок 3.3- Пример отображения справочников Примеры остальных форм отображения справочной информации приведены в Приложении В.

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

Рисунок 3.4 — Шаблон формы для отображения списка отелей Вторая форма предназначена непосредственно для заполнения полной информации об отеле. Она, в отличие от форм справочной информации, является многотабличной.

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

Рисунок 3.5- Вид шаблона формы отображения описания отеля Рисунок 3.6- Пример заполнения формы Для работы менеджера с описанием туров разработаем форму, которая будет совмещать в себе сразу и список туров и их характеристики, согласно рисунку 3.7.

Рисунок 3.7- Шаблон формы описания туров Так же нам понадобятся формы для ведения списка клиентов, представлены на рисунке 3.8, и списка заказов от клиентов смотреть рисунок 3.9.

Рисунок 3.8 — Форма картотеки клиентов Рисунок 3.9 — Форма списка заказов клиента

3.2 Формирование запросов и отчетов

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

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

2) По типу алгоритмов выборки. Различают следующие запросы:

— запрос на выборку: результат запроса может быть отображен в форме или отчете или быть использован для других запросов;

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

— запрос на создание таблицы: производит автоматическое формирование структуры записи новой таблицы;

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

— запрос на удаление выполняет удаление группы записей из таблицы.

3) По типу языка запросов.

4) По стабильности условий фильтрации записей в запросах различают:

— статические запросы с неизменными условиями;

— динамические запросы с изменяемыми условиями.

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

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

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

Between [Дата начала] And [Дата конца]

Рисунок 3.10 — Шаблон запроса

На рисунке 3.11 показан шаблон отчета по доходам.

Рисунок 3.11 — Макет отчета по сумме заказов Тест запроса по формированию списков заказов за период производит выборку из таблицы заказов без учета оплаты клиентов. Это сделано для того, что бы проанализировать, на какие заказы был спрос. Но нас еще интересует фактическое поступление средств.

Макет отчета представлен на рисунке 3.12

Рисунок 3.12 — Макет отчета Рисунок 3.13 — Отчет об оплате

Заключение

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

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

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

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

В результате проделанной работы были получены навыки по проектированию БД в терминах сущностей и атрибутов, созданию таблиц и определению отношений между ними, проектированию макетов форм и отчетов в среде Access 2010, формирования запросов с использованием SQL.

Список ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1 Федотова Д. Э., Семенов Ю. Д., Чижик К. Н. CASE-технологии: Практикум. — М.: Горячая линия-Телеком, 2005.-160 с.

2 Бойко В. В., Савинков В. М. Проектирование баз данных информационных систем. — М.: Финансы и статистика, 1989. — 351с.

3 Карпова Т. С. Базы данных: модели, разработка, реализация. — СПб.: Питер. 2001.

4 Одиночкина С. В. Разработка баз данных в McroSoft Access 2010 — Спб: НИУ ИТМО, 2012. — 83 с.

5 Автоматизированные информационные технологии в экономике / под ред. Г. А. Титоренко — М.: ЮНИТИ, 1999. — 400с.

6 Сеннов А. С. Access 2010. Учебный курс — Спб.: Питер, 2010. — 288 с.

ПРИЛОЖЕНИЕ, А Рисунок П А.1 — Схема данных

ПРИЛОЖЕНИЕ B

Рисунок П B.1 — Макет формы ГОРОДА Рисунок П B.2 — Макет формы СТРАНЫ Рисунок П B.3 — Макет формы ТИПЫ НОМЕРОВ