62
Рис. 2.16. Последовательность работы менеджера по работе с клиентами
2.3.2.Характеристика базы данных
Основной целью создания базы данных является автоматизация учета
посещаемости клиентов и формирования вторичной информации на его
основании. Процесс обработки и получения вторичной информации является
крайне важным, так как для ООО «Кенгуру Тур» важно не только посещение
клиентов, а и экономический эффект от этого (покупка тура, заинтересованность
в услугах туристической компании.
В процессе использования БД будут улучшены такие вторичные
процессы:
– Увеличение скорости получения информации о проданных турах;
– Возможность ведения справочных данных;
– Возможность просмотра данных по каждому туру или клиенту;
– Подсчет стоимости проживания за один день.
Рассмотрим и проанализируем диаграммы функциональных зависимостей
между сущностями (рисунок 2.17):
Формирование отчетной информации
Менеджер Руководитель
Выполнение фильтрации и оперативного отбора данных
Менеджер
Обработка данных с помощью запросов
Менеджер
Ввод личной информации о клиенте
Менеджер Клиент
Ввод данных в справочники
Менеджер
63
Страна
Клиенты Заносятся
Имеют Гостиницы
Учет
Туры
Отмечаются
Предоставля
ют услуги
Используется
Транспорт1 М 1
М
1 М М
1
М
1
Рис.2.17. Функциональные зависимости
Выделим первичные ключи для созданных сущностей.
1. Сущность «Страны» имеет первичный ключ Код страны;
2. Сущность «Гостиницы» имеет первичный ключ Код гостиницы;
3. Сущность «Учет» имеет первичный ключ №п/п, а также внешние
ключи Тур и Клиент;
4. Сущность «Туры» имеет первичный ключ № п/п, а также внешний
ключи Гостиница, Вид транспорта;
5. Сущность «Клиенты» имеет первичный ключ Код клиента;
6. Сущность «Транспорт» имеет первичный ключ Код Транспорта.
Выполним нормализацию БД до 3НФ.
Первая нормальная форма (1НФ). Отношение находится в первой
нормальной форме в том случае, если все атрибуты содержат атомарные
значения. Все созданные нами отношения находятся в 1НФ.
Вторая нормальная форма (2НФ). Отношение, которое находится в первой
нормальной форме и каждый атрибут которого, не входящий в состав
первичного ключа, характеризуется полной функциональной зависимостью от
этого первичного ключа. Вторая нормальная форма применяется к отношениям с
составными ключами, т.е. к таким отношениям, первичный ключ которых
состоит из двух или больше атрибутов. Отношениями с составным первичным
ключом у нас являются отношение Учет и Туры.
64
В этих отношениях существует единственная полная функциональная
зависимость от первичного ключа.[8, c.211]
Следовательно, отношение Туры, как и все остальные, находится во 2НФ.
Третья нормальная форма (3НФ). Отношение, которое находится в первой
и второй нормальных формах и не имеет не входящих в первичный ключ
атрибутов, которые находились бы в транзитивной функциональной
зависимости от этого первичного ключа. Нормализация 2НФ-отношений с
образованием ЗНФ-отношений включает устранение транзитивных
зависимостей.
Из рисунка 2.18 видно, что транзитивные функциональные зависимости
отсутствуют, значит, все отношения находятся в 3НФ.
Связи информационных объектов приведены в таблице 2.1.:
Таблица №2.1.
Связи информационных объектов
Главный ИО
Подчиненный ИО
Ключ связи
Тип отношения
Клиенты
Учет
Код клиента
1:М
Страны
Гостиницы
Код страны
1:М
Гостиницы
Туры
Код гостиницы
1:М
Туры
Учет
№ п/п
1:М
Транспорт
Туры
Код транспорта
1:М
Разработку ИС будет проводить в СУБД Access, поскольку она имеет
следующие положительные стороны:
простота в администрировании;
быстродействие, функциональные возможности механизмов сервера
СУБД;
возможность подключения к веб;
интуитивно понятный интерфейс.
Поскольку СУБД Access имеет встроенный редактор кода VBA и может
обеспечить полностью все требования к базе данных при проектировании ИС
будем использовать как раз эту СУБД.
Структура реляционной БД, построенная на основе информационного
анализа предметной области, приведена на рисунке 2.18:
65
Рис. 2.18. Схема данных
Разработанная структура реляционной БД реализована в СУБД Access.
Описание структуры таблиц приведено на рисунках 2.19-2.24
Рис. 2.19. Структура таблицы Гостиницы
Рис. 2.20. Структура таблицы Клиенты
66
Рис. 2.21. Структура таблицы Страны
Рис. 2.22. Структура таблицы Транспорт
Рис. 2.23. Структура таблицы Туры
Рис. 2.24. Структура таблицы Учет
2.3.3.Структурная схема пакета (дерево вызова программных модулей)
Разработанное программное обеспечение основано на применении БД с
формированием стандартного интерфейса инструментами Access.
Автоматизированная система использует в данном случае информацию из
базы и осуществляет все операции для обработки данных посредством запросов,
форм, макросов и отчетов.
67
Чтобы облегчить процесс работы менеджеров, разработано дерево
вызовов в автоматизации учета посещений клиентов (рис.2.25).
Рис. 2.25. Дерево вызовов
2.3.4.Описание программных модулей
Рассмотрим несколько запросов, созданные для имеющейся БД.
Создадим перекрестный запрос Стоимость тура по клиентам, который
отображает среднюю стоимость туров в разрезе по клиентам:
TRANSFORM Avg(Туры.[Стоимость тура]) AS [Avg-Стоимость тура]
SELECT Клиенты.ФИО
FROM Страны INNER JOIN (Клиенты INNER JOIN (Гостиницы INNER
JOIN (Туры INNER JOIN Учет ON Туры.[№ п/п] = Учет.Тур) ON
Гостиницы.[Код гостиницы] = Туры.Гостиница) ON Клиенты.[Код клиента] =
Учет.Клиент) ON Страны.[Код страны] = Гостиницы.Страна
GROUP BY Клиенты.ФИО
PIVOT Страны.Страна;
В режиме конструктора запрос имеет вид (рисунок 2.26):
ПО для
автоматизации учета
посещений клиентов
Ввод данных в
справочники
Формирование
главных таблиц
Использование форм Выборка данных
Применение
фильтров
Формирование
отчетной
документации
68
Рис. 2.26. Запрос Стоимость тура по клиентам в режиме конструктора
После запуска запроса получим (рисунок 2.27):
Рис. 2.27. Запрос Стоимость тура по клиентам в режиме просмотра
Создадим запрос Количество туров для отображения количество выездов
в каждую из стран.
SELECT Страны.Страна, Count(Учет.[№ п/п]) AS [Кол-во туров]
FROM Страны INNER JOIN ((Гостиницы INNER JOIN Туры ON
Гостиницы.[Код гостиницы] = Туры.Гостиница) INNER JOIN Учет ON Туры.[№
п/п] = Учет.Тур) ON Страны.[Код страны] = Гостиницы.Страна
GROUP BY Страны.Страна;
69
В режиме конструктора запрос имеет вид (рисунок 2.28):
Рис. 2.28. Запрос Количество туров в режиме конструктора
После запуска запроса получим (рисунок 2.29):
Рис. 2.29. Запрос Количество туров в режиме просмотра
Создадим запрос Продолжительность туров, для отображения количества
дней проживания в разрезе гостиниц по странам.
SELECT Туры.[№ п/п], Гостиницы.Название, Страны.Страна,
Туры.[Условия проживания], Туры.[Продолжительность (дней)]
70
FROM Страны INNER JOIN (Гостиницы INNER JOIN Туры ON
Гостиницы.[Код гостиницы] = Туры.Гостиница) ON Страны.[Код страны] =
Гостиницы.Страна;
В режиме конструктора запрос имеет вид (рисунок 2.30):
Рис. 2.30. Запрос Продолжительность туров в режиме конструктора
После запуска запроса получим (рисунок 2.31):
Рис. 2.31. Запрос Продолжительность туров в режиме просмотра
Создадим запрос Стоимость дня, для отображения стоимости дня отдыха
в разрезе гостиниц по странам и по видам транспорта.
SELECT Гостиницы.Страна, Туры.Гостиница, Туры.[Вид транспорта],
[Туры]![Стоимость тура]/[Туры]![Продолжительность (дней)] AS [Стоимость
дня]
FROM Гостиницы INNER JOIN Туры ON Гостиницы.[Код гостиницы] =
Туры.Гостиница;
71
В режиме конструктора запрос имеет вид (рисунок 2.32):
Рис. 2.32. Запрос Стоимость дня в режиме конструктора
После запуска запроса получим (рисунок 2.33):
Рис. 2.33. Запрос Стоимость дня в режиме просмотра
Рассмотрим иерархическую схему форм для разработанной БД (рисунок
2.34).