Спроектировать базу данных для предметной области Туристическая фирма.
Создать информационную систему для заданной предметной области. Она должна включать в себя связанные таблицы базы данных, а также набор входных форм для их заполнения, запросы различных типов, обеспечивающие поиск и обработку хранимых данных, типовые выходные формы-отчеты. Система должна обеспечивать возможность добавления, изменения и удаления данных в базе и иметь удобный интерфейс для работы пользователей, для доступа к базе данных должно быть использовано разграничение прав доступа.
Туристическая фирма имеет свой персонал, поставщиков и клиентов.
Таким образом, необходимо реализовать ввод, хранения и изменение информации в базе данных:
- Персональные и контактные данные клиентов (Фамилия, имя, Отчество, адрес, телефон);
- Персональные и контактные данные поставщиков (Название поставщика, представитель, телефон, адрес);
- Персональные и контактные данные сотрудников туристической фирмы (ФИО, адрес, дата рождения, зарплата, должность, адрес, телефон);
- Данные о заказе (сотрудник, клиент, дата оформления)
- Данные о странах, в которые проводятся туры(Название страны, город, визовое обслуживание, проживание, питание, экскурсии)
- Данные о транспорте (наименование, дата отправления, дата прибытия)
- Информация о турах (Дата, отправления, дата прибытия, стоимость, длительность пребывания, дата оформления, количество человек)
Входные формы:
- Информация о турфирме
- Добавление информации
- Запросы
- Добавление клиента
- Отчеты
- Добавление поставщика
- Добавление сотрудника
- Добавление тура
- Главная форма
Конечный продукт должен выполнять следующие функции:
- Ввод, изменение и удаление данных во всех таблицах;
- Печать списка сотрудников;
- Печать списка поставщиков;
- Печать списка туров;
- Печать списка туров на Мальдивы на 6 дней
- Печать списка услуг
Функция Печати, подразумевает наличие как экранных, так и печатных форм отображения результатов, которые могут различаться или совпадать по форме и содержанию.
Для реализации вышеперечисленных функций конечный продукт должен содержать формы:
- Главную (начальную) форму выбора действий, из которых должны запускаться остальные формы, реализующие все функции;
- Форма для добавления информации в базу данных, по выбранной категории
- Форма запросов
- Форма, содержащая информацию о туристической фирме
- Форма для редактирования и добавления Клиентов
- Форма для редактирования и добавления Поставщиков
- Форма для редактирования и добавления Сотрудников
- Форма для выбора нужно таблицы
- Форма для редактирования и добавления Туров
3.1 Информационные потребности пользователя (анализ запросов)
При разработке данного курсового проекта была выбрана следующая предметная область: «Туристическая фирма».
Программы для работы с архивами данных
... форме. Файл архива содержит оглавление, которое позволяет узнать, какие файлы содержатся в архиве. В оглавлении архива для каждого содержащегося в нем файла храниться следующая информация: имя файла; сведения о каталоге, в котором содержится файл; дата ...
В ней необходимо отразить:
- список обслуживающего персонала
- информацию о турах;
- информацию о заказах
- список клиентов и всей информации о них
- список поставщиков и информации о них
- информация о странах, в которые предоставляются туры
- информация о транспорте
- информация об услугах туристической фирмы
3.2 Определение сущностей и связей
Сущность — это объект, информация о котором должна быть представлена в базе данных. Экземпляр сущности — это информация о конкретном представителе объекта.
Связь — соединение между двумя и более сущностями. Экземпляр связи конкретная связь между конкретными представителями объектов.
Сущности, представленные в данном курсовом проекте:
Ш Сотрудники (содержит всю необходимую информацию о сотрудниках)
Ш Заказы (информация о заказах)
Ш Туры (информация о турах)
Ш Клиенты (информация о клиентах туристической фирмы)
Ш Услуги (информация о услугах, которые предоставляет туристическая фирма)
Ш Транспорт (информация о транспорте)
Ш Город (информация о городах, в которые проводятся туры)
Ш Страна (информация о странах, в которые проводятся туры)
3.3 Определение функций пользователя, атрибутов, ключей
Атрибут — свойство сущности или связи. , Ключ сущности — атрибут или набор атрибутов, используемый для однозначной идентификации экземпляра сущности.
3.4 Ключи и атрибуты, в данном курсовом проекте
Ш Сущность «Сотрудники». Содержит следующие атрибуты: Код сотрудника, Фамилия, Имя, Отчество, Дата рождения, Зарплата, Должность, Адрес, Телефон.
Ш Сущность «Заказы». Содержит следующие атрибуты: Код заказа, Код тура, Код сотрудника, Код клиента, Дата оформления.
Ш Сущность «Туры». Содержит следующие атрибуты: Код тура, Код услуги, Дата отправления, Дата прибытия, Стоимость тура, Код транспорта, Длительность пребывания, Количество человек.
Ш Сущность «Клиенты». Содержит следующие атрибуты: Код клиента, Фамилия, Имя, Отчество, Адрес, Телефон.
Ш Сущность «Услуги». Содержит следующие атрибуты: Код услуги, Код страны, Визовое обслуживание, Проживание, Питание, Экскурсии.
Ш Сущность «Транспорт». Содержит следующие атрибуты: Код транспорта, Наименование.
Ш Сущность «Страна». Содержит следующие атрибуты: Код страны, Название страны, Код города.
Сущность и специфика менеджмента в сфере туризма
... этого. А ведь особенности туристской отрасли вытекают из специфических свойств услуг, предоставляемых туристскими предприятиями и организациями. Основную задачу данной курсовой можно определить следующим образом: я хочу показать специфику туристских услуг и их воздействие на ...
Ш Сущность «Город». Содержит следующие атрибуты: Код страны, Код города, Город.
3.5 Выявление и описание ограничений целостности
Под целостностью данных понимаются ссылочные ограничения, т.е. те ограничения, которые нужно соблюдать для сохранения целостности связи между таблицами, в случае если в них будут изменяться или удаляться записи. Для обеспечения целостности данных в Access есть 4 варианта:
1. Если не указано каскадное обновление связей, то предотвращается изменение значений первичного ключа в главной таблице, если существуют связанные записи в подчиненной таблице.
2. Если указано каскадное обновление связей, то при изменении значений первичного ключа будут изменяться соответствующие значения в связанной таблице.
3. Если не указано каскадное удаление связанных записей, то предотвращается удаление связанных записей из главной таблицы, если имеются связанные с ней записи в подчиненной.
4. Если указано каскадное удаление, то связанные записи подчиненной таблицы удаляются автоматически.
В данном курсовом проекте у каждой связи установлены такие параметры как каскадное обновление и каскадное удаление связей. Свойства этих параметров описаны выше. Также к ограничениям целостности можно отнести ограничения на столбец и на таблицу, а точнее на значения данных в них. К таким ограничениям можно отнести следующие:
- Запрещение null значения: данные, заносимые в столбец или таблицу, не должны равняться нулю.
- Ограничения на допустимые значения полей: условие, которому должны удовлетворять данные, вносимые в таблицу.
- Ограничение первичного ключа: на практике рекомендуется для каждой таблицы создавать первичный ключ, особенностью которого является не допуск null значения.
- Ограничение уникальных ключей: необходимость ввода различных (уникальных) данных.
В данном курсовом проекте используются следующие ограничения данных в таблицах:
Таблица Заказы
В поле Дата заказа на данные накладывается ограничение от 01.01.1940 до 01.01.2015.
Таблица Сотрудники
В поле Дата рождения на данные накладывается ограничение от 01.01.1950 до 01.01.1997.
3.6 Разработка инфологической модели предметной области
Инфологическая модель описывает предметную область на содержательном уровне. Результатом этого анализа являются списки объектов предметной области, перечни свойств, или атрибутов, определение связей между объектами и описание структуры предметной области в виде диаграммы. Определим связи данной предметной области на этапе разработки инфологической модели. Связь между сущностями можно охарактеризовать степенью связи и классом принадлежности сущности к связи. Где степень связи показывает, сколько экземпляров одной сущности могут быть связано с каждым экземпляром другой сущности, и может иметь три значения:
- Один к одному (1:1)
- Один ко многим (1:М или М:1)
- Многие ко многим (М:N)
Класс принадлежности сущности к связи может быть обязательным (каждый экземпляр сущности обязательно должен быть связан с другой сущностью) и необязательным (каждый экземпляр сущности не требует связи с экземпляром другой сущности).
В данном курсовом проекте используются такие связи как:
1)
Код сотрудника код заказа
Класс принадлежности сотрудник, заказ необязательный.
2)
Код клиента код заказа
Класс принадлежности клиент, заказ обязательный.
3)
Код тура код заказа
Класс принадлежности тур, заказ обязательный.
4)
Код услуги Код тура
Класс принадлежности услуга, тур обязательный.
5)
Класс принадлежности тур, транспорт необязательный.
6)
Код страны код услуги
Класс принадлежности страна, услуги необязательный.
7)
Код страны код города
Класс принадлежности страна, город обязательный.
4.1 Выбор СУБД
СУБД представляет собой совокупность языковых и программных средств, с помощью которых база данных создается и поддерживается. На данный момент существует множество языков, с помощью которых можно создавать различные структуры и вводить в них необходимые элементы управления. При выборе модели данных мы остановились на реляционной модели из-за ее математической определенности и наличия большого количества СУБД, которые поддерживают реляционную модель данных. Из всего множества СУБД была выбрана Microsoft Access 2013 благодаря имеющимся средствам визуальной разработки графического интерфейса и наличию удобной среды разработки
4.2 Отображение инфологической модели на даталогическую модель
Даталогическая модель описывает объекты и связи предметной области на формальном уровне. Ее разработка основывается на инфологической модели. В процессе разработки осуществляется выбор модели данных, и определяются ее элементы.
Учитывая выбранную СУБД и разработанную инфологическую модель предметной области, была разработана следующая даталогическая модель:
- Клиенты (Код клиента, Фамилия, имя, отчество, адрес, телефон);
- Поставщики (Код услуги, Код поставщика, Название поставщика, представитель поставщика, обращаться, телефон, адрес);
- Сотрудники (Код сотрудника, Фамилия, Имя, Отчество, Дата рождения, зарплата, должность, Адрес, Телефон);
- Туры (Код тура, Код услуги, дата отправления, дата прибытия, стоимость тура, код транспорта, длительность пребывания, количество человек);
- Услуги (Код услуги, Код страны, Визовое обслуживание, проживание, питание, экскурсии);
- Город (Код страны, код города, город);
- Страна (Код страны, название страны, код города);
- Транспорт (Код транспорта, наименование);
- Заказы (Код заказа, код тура, Код сотрудника, код клиента, дата оформления).
Таблица Город
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код страны |
Числовой |
да |
нет |
|
Код города |
Числовой |
Да |
Да(Совпадения не допускаются) |
|
Город |
Короткий текст |
да |
нет |
|
Таблица Заказы
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код заказа |
Числовой |
да |
Да(Совпадения не допускаются) |
|
Код тура |
Числовой |
Да |
нет |
|
Код сотрудника |
Числовой |
да |
Нет |
|
Код клиента |
Числовой |
Да |
нет |
|
Таблица Клиенты
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код клиента |
Числовой |
да |
Да(Совпадения не допускаются) |
|
Фамилия |
Короткий текст |
да |
нет |
|
Имя |
Короткий текст |
нет |
Нет |
|
Отчество |
Короткий текст |
нет |
Нет |
|
Адрес |
Короткий текст |
нет |
Нет |
|
Телефон |
Короткий текст |
нет |
нет |
|
Таблица Поставщики
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код услуги |
Числовой |
Нет |
Нет |
|
Код поставщика |
Числовой |
Да |
Да (совпадения не допускаются) |
|
Название поставщика |
Короткий текст |
Нет |
Нет |
|
Представитель поставщика |
Короткий текст |
Нет |
Нет |
|
Обращаться |
Короткий текст |
Нет |
Нет |
|
Телефон |
Короткий текст |
Нет |
Нет |
|
Адрес |
Короткий текст |
Нет |
нет |
|
Таблица Сотрудники
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код сотрудника |
Числовой |
Да |
Да (совпадения не допускаются) |
|
Фамилия |
Короткий текст |
да |
Нет |
|
Имя |
Короткий текст |
Нет |
Нет |
|
Отчество |
Короткий текст |
Нет |
Нет |
|
Дата рождения |
Дата и время |
Нет |
Нет |
|
Зарплата |
Денежный |
Нет |
Нет |
|
Должность |
Короткий текст |
Нет |
Нет |
|
Адрес |
Короткий текст |
Нет |
Нет |
|
Телефон |
Короткий текст |
Нет |
Нет |
|
Таблица Страна
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код страны |
Числовой |
Да |
Да (совпадения не допускаются) |
|
Название страны |
Короткий текст |
Нет |
Нет |
|
Код города |
Числовой |
Нет |
Да (совпадения допускаются) |
|
Таблица Транспорт
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код транспорта |
Числовой |
Да |
Да (совпадения не допускаются) |
|
Наименование |
Короткий текст |
Нет |
Нет |
|
Таблица Туры
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код тура |
числовой |
Да |
Да (совпадения не допускаются) |
|
Код услуги |
Числовой |
Нет |
Нет |
|
Дата отправления |
Дата и время |
Нет |
Нет |
|
Дата прибытия |
Дата и время |
Нет |
Нет |
|
Стоимость тура |
Денежный |
Нет |
Нет |
|
Код транспорта |
Числовой |
Нет |
Нет |
|
Длительность пребывания |
Числовой |
Нет |
Нет |
|
Количество человек |
Числовой |
Нет |
нет |
|
Таблица Услуги
Имя поля |
Тип данных |
Обязательное поле |
Индексирование данных |
|
Код услуги |
Числовой |
Да |
Да (Совпадения не допускаются) |
|
Код страны |
Числовой |
нет |
Да (допускаются совпадения) |
|
Визовое обслуживание |
логический |
— |
Нет |
|
Проживание |
Короткий текст |
Нет |
Нет |
|
Питание |
Короткий текст |
Нет |
Нет |
|
Экскурсии |
Логический |
— |
нет |
|
Схема даталогической модели базы данных (схема данных).
Рисунок 1(Схема данных «Туристическая фирма»)
5.1 Разработка средств реализации ограничений целостности
В любой момент времени БД имеет некоторую определенную конфигурацию значений данных, которые отражают действительность, т.е. являются частью реального мира. Просто определить конфигурацию значений не имеет смысла без связи с внешним миром. Поэтому требуется уточнить определение БД, включив в него правила целостности, которые необходимы для информирования СУБД о различного рода ограничениях реального мира с целью не допустить “абсурдных ” значений данных.
Для любого отношения можно создать ряд правил — ограничений. Каждая конкретная БД должна иметь свои ограничения, связанные с предметной областью, которые накладываются на хранящиеся в ней данные. К таким ограничениям целостности относятся:
1. Ограничения на атрибуты (тип атрибута, диапазон допустимых значений).
2. Число кортежей отношения должно быть равно числу первичных ключей (наличие кортежей -дубликатов не допускается).
Первое ограничение накладывается на атрибуты всех отношений на этапе определения типа атрибута. Кроме этого некоторые поля таблиц имеют условие на значение, например, в отношении Сотрудники атрибут Дата Рождения должен быть в интервале от 01.01.1950 до 01.01.1997.
Второе ограничение накладывается на отношения на этапе заполнения таблиц данными о БД.
Существует также два общих правила целостности. Они касаются потенциальных и внешних ключей:
1. Первичный ключ является уникальным идентификатором отношения. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение. В отношении не может быть несколько кортежей с одинаковыми значениями первичного ключа.
Например, в отношении Заказы не может существовать несколько кортежей с одинаковыми значениями атрибута Код заказа.
2. Потенциальный ключ отношения не может иметь пустого значения (NULL).
Так как объект, не имеющий идентичности, не существует.
3. Если r2 — некоторое отношение с внешним ключом X , то должно существовать такое базовое отношение r1 с первичным ключом K , что каждое значение X в r2 совпадает со значением К в каком-либо кортеже отношения r1.
В процессе создания БД сначала осуществляется конструирование таблиц, далее создается схема данных, в которой фиксируются связи между таблицами. В этой схеме могут быть заданы параметры обеспечения целостности базы данных, если модель была разработана в соответствии с требованиями нормализации. Целостность данных означает, что в БД установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при их загрузке, добавлении и удалении в связанных таблицах, а также при изменении значений ключевых полей.
5.2 Разработка процедур ведения БД
Запрос по турам
SELECT Страна.[Название страны], Город.Город, Туры.[Дата отправления], Туры.[Длительность пребывания], Туры.[Стоимость тура], Транспорт.Наименование, Услуги.Проживание, Туры.[Количество человек]
FROM Город INNER JOIN ((Страна INNER JOIN Услуги ON Страна.Код_страны = Услуги.[Код страны]) INNER JOIN (Транспорт INNER JOIN Туры ON Транспорт.[Код транспорта] = Туры.[Код транспорта]) ON Услуги.[Код услуги] = Туры.[Код услуги]) ON Город.Код_города = Страна.Код_город;
Запрос по клиентам
SELECT Страна.[Название страны], Город.Город, Туры.[Дата отправления], Туры.[Длительность пребывания], Туры.[Стоимость тура], Транспорт.Наименование, Услуги.Проживание, Туры.[Количество человек]
FROM Город INNER JOIN ((Страна INNER JOIN Услуги ON Страна.Код_страны = Услуги.[Код страны]) INNER JOIN (Транспорт INNER JOIN Туры ON Транспорт.[Код транспорта] = Туры.[Код транспорта]) ON Услуги.[Код услуги] = Туры.[Код услуги]) ON Город.Код_города = Страна.Код_город;
Запрос по поставщикам
SELECT Поставщики.[Название Поставщика], Поставщики.[Представитель Поставщика], Поставщики.Обращаться, Поставщики.Телефон, Поставщики.Адрес
FROM Поставщики;
Запрос по сотрудникам
SELECT Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Сотрудники.[Дата рождения], Сотрудники.Зарплата, Сотрудники.Должность, Сотрудники.Адрес, Сотрудники.Телефон
FROM Сотрудники;
Запрос по турам
SELECT Страна.[Название страны], Город.Город, Туры.[Дата отправления], Туры.[Длительность пребывания], Туры.[Стоимость тура], Транспорт.Наименование, Услуги.Проживание, Туры.[Количество человек]
FROM Город INNER JOIN ((Страна INNER JOIN Услуги ON Страна.Код_страны = Услуги.[Код страны]) INNER JOIN (Транспорт INNER JOIN Туры ON Транспорт.[Код транспорта] = Туры.[Код транспорта]) ON Услуги.[Код услуги] = Туры.[Код услуги]) ON Город.Код_города = Страна.Код_город;
Запрос по странам
SELECT Страна.[Название страны], Город.Город
FROM Город INNER JOIN Страна ON Город.Код_города = Страна.Код_город;
Туры на Мальдивы на 6 дней
SELECT Туры.[Код тура], Страна.[Название страны], Город.Город, Туры.[Дата отправления], Туры.[Дата прибытия], Туры.[Длительность пребывания], Туры.[Стоимость тура]
FROM Туры, Город INNER JOIN Страна ON Город.Код_города=Страна.Код_город
WHERE (((Страна.[Название страны])=»Мальдивы») AND ((Туры.[Длительность пребывания])=6));
Запрос по услугам
SELECT Услуги.[Визовое обслуживание], Услуги.Проживание, Услуги.Питание, Услуги.Экскурсии
FROM Услуги;
— Для запуска данного проекта достаточно сделать двойной щелчок мышью по файлу “Турфирма.mdb”. Автоматически загружается Microsoft Access и открывается главная кнопочная форма. Из нее можно попасть, нажимая соответствующие кнопки, в формы просмотра данных о летчиках, самолетах, заказа билета, изменения данных базы, просмотра отчетов, а также кнопка Выход, нажав которую вы сможете выйти из программы.
- Главная форма
- Информация о туристической фирме
- Запросы
- Добавление информации
- Таблицы
- Отчеты
- Добавление информации: Клиенты
- Добавление информации: Поставщики
- Добавление информации: Сотрудники
- Добавление информации: Туры
Основной и единственный исполняемый модуль программы Турфирма.mdb. Этот модуль содержит таблицы данных, запросы к данным, формы ввода-вывода.
Раздел таблицы данных включает в себя данные предметной области, хранимые в виде отдельных таблиц:
Таблица: Город
Таблица: Заказы
Таблица: Клиенты
Таблица: Поставщики
Таблица: Сотрудники
Таблица: Туры
Таблица: Страны
Таблица: Транспорт
Таблица: Услуги
Microsoft Access позволяет автоматизировать обработку баз данных путем программирования на языке Visual Basic for Application.
В языке VBA реализована технология визуального, объектно-ориентированного программирования, основанная на событийном интерфейсе пользователя. Поэтому текст программы состоит из отдельных локальных процедур, обрабатывающих определенные события.
В данной программе используются следующие модули:
Модуль: Добавление информации
Модуль: Запросы
Модуль: Информация о турфирме
Модуль: Клиенты
Модуль: Отчеты
Модуль: Поставщики
Модуль: Сотрудники
Модуль: Таблицы
Модуль: Туристическая фирма ООО «ПЕГАС»
Модуль: Туры
Для ввода и вывода информации, хранящейся в таблицах базы данных, используются формы и отчеты, которые находятся в соответствующих разделах форм. Формы используют запросы для спецификации отражаемых данных.
Для доступа к определенным атрибутам отношений (полям таблицы) используются запросы, которые расположены в разделе запросов:
Запрос: Стоимость билета
Запрос: Проданные билеты
Запрос: Проданные места
В данном курсовом проекте была создана база данных по предметной области Туристическая фирма. При этом использовалась программа Microsoft Access 2013.
Данный курсовой проект может применяться как самостоятельная программа в малых туристических фирмах для составления и ведения отчетности по турам, хранения информации о сотрудниках, поставщиках и клиентах, а также для оформления заказов.