Постановка задачи на разработку
Турфирма «Профит-центр» потенциально подготовлена для внедрения сетевой технологии оформления путевок.
Работу с клиентом от начала до конца проводит турагент. В его функции входит:
¾ прием клиента;
¾ запись данных о клиенте;
¾ запись пожеланий клиента относительно путевки (страна, курорт, тип отеля, питание, дата отправления, примерная стоимость, количество человек и т.д.);
¾ исследование предложений туроператоров по желаемым критериям в сети;
¾ предоставление клиенту всей найденной информации;
¾ оформление выбранной клиентом путевки;
¾ прием оплаты.
К недостаткам, существующим в реализации функций регистратора, можно отнести:
¾ Отсутствие необходимого уровня автоматизации при работе с клиентами, т.е. все записи о клиентах и их пожелания осуществляются в основном в бумажном виде.
¾ Для получения сведений о путевках приходится переходить от одного сайта к другому, тратя большое количество времени на сравнение вариантов.
¾ Отсутствие возможности клиентов самостоятельно исследовать выгодные предложения, используя услуги всемирной сети Интернет.
Для устранения данных недостатков необходимо разработать сетевую технологию оформления путевок, основными функциями которой являются:
¾ Самостоятельное изучение и выбор предложения, используя услуги всемирной сети Интернет, с последующим оформлением через турагента.
¾ Поднять качество обслуживания туристов на более высокий уровень.
В данной сетевой технологии предусмотрены следующие автоматизированные места:
¾ турагент;
¾ клиент.
Рассмотрим функции турагента:
¾ регистрация клиентов;
¾ поиск путевок по требованиям;
¾ оформление путевки;
¾ просмотр и редактирование информации о зарегистрированных клиентах.
Рассмотрим функции клиента:
¾ регистрация;
¾ предоставление требований к путевке;
¾ самостоятельный поиск с использованием базы данных компании;
¾ онлайн заказ.
Для успешного функционирования сетевой технологии должны быть выполнены следующие требования:
Требования к АРМ турагента:
¾ АРМ должны быть подключены к глобальной сети Интернет.
¾ Наличие устройства отображения информации (например, монитор с разрешением не ниже 640х480).
¾ Наличие средства для просмотра интернет-страниц – браузера.
Требования к АРМ клиента:
¾ АРМ должно быть подключено к глобальной сети Интернет.
¾ Наличие устройства отображения информации (например, монитор с разрешением не ниже 640х480).
¾ Наличие средства для просмотра интернет-страниц – браузера.
Также должны быть выполнены следующие требования, предъявляемые к входной информации:
¾ Вход в ИС должен быть авторизован.
Особое внимание следует уделить хранению и корректировке информации. Для этого информационная база системы должна удовлетворять следующим требованиям:
¾ Возможность накопления и хранения значительных объемов массивов данных с целью многократного их использования.
Кроме того, программный продукт должен:
¾ Обладать максимальной простотой интерфейса.
¾ Включать возможность просмотра списка клиентов, оформляющих заказ через турагента или самостоятельно через www-страницу.
Данная технология будет разработана на базе трехзвенной архитектуры, с использованием средства разработки Macromedia Dreamweaver 8 с использованием языка гипертекстовой разметки HTML с использованием PHP. База данных будет разработана с помощью MySQL. В качестве www-сервера будет использован Apache 2.0.59.
Разработка новой технологии помощи клиентам в оформлении путевок
Разработка модели БД
Для того чтобы определиться с информационной моделью, определимся с концептуальной моделью.
Концептуальная модель — это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.
На рисунке 11 показана концептуальная модель разрабатываемой БД:
|
Информационная модель - это спецификация структуры данных и бизнес правил (правил предметной области).
Процесс построения информационной модели состоит из следующих шагов:
1. Определение сущностей.
2. Определение зависимостей между сущностями.
3. Задание первичных и альтернативных ключей.
4. Определение атрибутов сущностей.
5. Приведение модели к требуемому уровню нормальной формы.
6. Переход к физическому описанию модели: назначение соответствий - имя сущности - имя таблицы, атрибут сущности - атрибут таблицы, задание триггеров, процедур и ограничений.
В рассматриваемой предметной области выделены следующие сущности:
¾ пользователь;
¾ тур;
¾ заявка;
¾ турист.
В таблице 6 показана первая нормальная форма, характеризующая эти сущности.
Таблица 6 - Первая нормальная форма модели БД
| Сущность | Атрибут | Тип данных | Примечание |
| Пользователи | Идентификационный номер пользователя | integer | NOT NULL |
| Логин | varchar | NOT NULL | |
| Пароль | hash | NOT NULL | |
| Фамилия | varchar | ||
| Имя | varchar | ||
| Отчество | varchar |
Таблица 7 – Продолжение
| Пользователи | Телефон домашний | varchar | |
| Телефон рабочий | varchar | ||
| Телефон сотовый | varchar | ||
| varchar | NOT NULL | ||
| Тур | Идентификационный номер тура | integer | NOT NULL |
| Страна | varchar | NOT NULL | |
| Курорт | varchar | NOT NULL | |
| Отель | varchar | NOT NULL | |
| Уровень обслуживания | integer | NOT NULL Диапазон 1-5 | |
| Кол-во человек | integer | NOT NULL | |
| Цена | real | NOT NULL | |
| Дата вылета | date | NOT NULL | |
| Дата прилета | date | NOT NULL | |
| Туроператор | varchar | ||
| Паспортные данные для путевки | Идентификационный номер туриста | integer | NOT NULL |
| Фамилия в паспорте РФ | varchar | ||
| Имя в паспорте РФ | varchar | ||
| Отчество паспорте РФ | varchar | ||
| Серия паспорта РФ | varchar | ||
| Номер паспорта РФ | integer | ||
| Дата выдачи паспорта РФ | date | ||
| Фамилия в загран. паспорте | varchar | ||
| Имя в загран. паспорте | varchar | ||
| Отчество в загран. паспорте | varchar | ||
| Серия загран. паспорта | integer | ||
| Номер загран. паспорта | integer | ||
| Дата выдачи загран. паспорта | date | ||
| Дата рождения | date | ||
| Ксерокопия 2-3 стр. паспорта РФ | memo | ||
| Ксерокопия прописки из паспорта РФ | memo | ||
| Ксерокопия 2-3 стр. загран. паспорта | memo | ||
| Заявка | Идентификационный номер заявки | integer | NOT NULL |
| Состояние | varchar | NOT NULL |
Приведем модель к второй нормальной форме, не должно быть частичной функциональной зависимости неключевых атрибутов от ключа (зависимость неключевых атрибутов от части ключа). На рисунке 12 показана первая нормальная форма модели БД.
Рисунок 12 - Вторая нормальная форма модели БД
Приведем все отношения к третьей нормальной форме, т. е. избавимся от транзитивных зависимостей. Для создания нормально функционирующей БД достаточно, чтобы отношения в ней находились в третьей нормальной форме.
Логическая модель разрабатываемой технологии представлена на рисунке 13.
Рисунок 13 – Логическая модель данных разрабатываемой технологии
При переходе к физической модели системы необходимо:
1. Обозначить имена атрибутов сущностей так, как названы столбцы
таблиц разрабатываемой базы данных.
2. Сменить тип атрибутов.
3. Ввести ограничения NotNull на необходимые атрибуты.
Построим таблицу с соответствием типов данных в логической модели сетевой технологии с используемыми типами данных в СУБД MySQL.
Таблица 6 – Соотношение типов данных
| Тип данных | Логическая модель | MySQL |
| Целочисленный | integer | int |
| Символьный | Varchar() | Varchar() |
| Дата и время | Date | Datetime |
Физическая модель сетевой технологии регистрации заявок представлена на рисунке 14.
Рисунок 14 - Физическая модель данных разрабатываемой технологии