Система бронирования мест в отелях города
Разработка системы управления гостиничного портала компании "Петербургские Отели" с интеграцией комплекса модулей для управления его содержимым. Основные цели создания и требования, выдвигаемые при разработке системы бронирования мест в отелях города.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 15.06.2012 |
Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Если говорить о серверной составляющей, то тут положительным для приложения будет являться, если оно будет кроссплатформенным. Тем не менее, следует определить, на какую ОС установка будет оптимальной. Система Windows не очень хороша в качестве сервера услуг Интернет. На момент написания работы самым распространенным сервером для хранения Web-узлов на платформе Windows является IIS (Internet Information Service). Его последние версии существенно усовершенствованы, но он по-прежнему страдает от множества изъянов в области безопасности, а системные администраторы считают его ненадежным и неустойчивым. Кроме того, Windows - это слишком ресурсоемкая среда для обслуживания Internet. Из 2 Гбайт памяти 512 Мбайт может отводиться для работы операционной системы с ее различными службами и лишь 64 Мбайта могут реально использоваться для работы Web-сервера. Операционная система Unix является более экономичной и надежной. Ее не так просто настроить, но она работает несравнимо быстрее и устойчивее, требуя при этом гораздо меньше ресурсов. Итак, поскольку ОС Unix превосходит Windows и по скорости и по надежности, то окончательный выбор именно за ней. Конкретно выберем операционную систему ASPLinux 9.0. Данная ОС из семейства UNIX, является бесплатной, свободно распространяемой, имеет достаточно высокий уровень надежности, защищенности, хорошо поддерживается в нашей стране. Также в поставке с ней идет большое количество приложений обеспечивающих полноценную работу данной ОС в качестве Web-сервера, сервера баз данных, файлового сервера и т.п.
2.2 Выбор системы управления базами данных
Сервер базы данных может быть физически установлен на другой машине, и выбор таких серверов достаточно широк. Среди возможных вариантов: PostgreSQL, MySQL, Oracle, Informix, DB2, Microsoft SQL Server, SUP DB и многие другие. Все эти варианты достаточно хороши. Поскольку серверы баз данных не имеют выхода в Интернет, вопросы безопасности при их выборе не играют ключевой роли. Если брандмауэр настроен правильно, то все серверы баз данных являются одинаково безопасными. Все эти серверы являются достаточно надежными и быстрыми. Реальные различия в производительности зачастую определяются структурой базы данных, а не особенностями самого сервера.
Во-первых, этот сервер является, наверное, самым широко распространенным после MySQL.
В последнее время наибольшее распространение получили реляционные базы данных. В реляционных базах данных информация хранится в одной или нескольких таблицах. Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей. Каждая строка таблицы в реляционных базах данных уникальна. Для обеспечения уникальности строк используются ключи, которые содержат одно или несколько полей таблицы. Ключи хранятся в упорядоченном виде, что обеспечивает прямой доступ к записям таблицы во время поиска.
По легкости использования лучшей является реляционная модель, т.к. она оперирует только с одной структурой - таблицей. К тому же, подавляющее большинство современных СУБД являются реляционными.
Перед тем как приступить к окончательному выбору СУБД, необходимо выделить набор факторов, которые необходимо учитывать.
Приведем перечень наиболее часто используемых факторов оценки СУБД:
· требуемые объемы основной и дисковой памяти;
· трудоемкость разработки программных средств окружения СУБД;
· трудоемкость реализации приложений;
· затраты на обучение персонала;
· стоимость эксплуатации, информационной системы;
· возможность совмещения разработки БД с ранее выполненными программными реализациями;
· прогнозируемые сроки реализации информационной системы.
На основе анализа проведенного в предыдущем разделе, а также, учитывая вышеперечисленные факторы, наиболее подходящими в качестве сервера баз данных являются СУБД PostgreSQL и Mysql, так как они обладает высокой надежностью, защищенностью, хорошей производительностью, а также открытостью. Кроме того, они являются одними из наиболее распространенных.
В комплект поставки MySQL входят два тестовых пакета, а также пакет для замеров производительности. Тестовая система постоянно обновляется, в нее добавляется код для тестирования всех новых возможностей и почти всех воспроизводимых ошибок, которые попали в поле нашего зрения. Перед выпуском каждой новой версии используются эти пакеты для тестирования MySQL на нескольких платформах.
В MySQL предусмотрена возможность создания таблиц без транзакций, что необходимо приложениям, требующим максимально возможной скорости работы.
2.3 Выбор технологии реализации
Очень важно, при разработке серверной стороны грамотно выбрать базовую технологию, на которой будет основано приложение. На данный момент существуют и успешно применяются различные виды технологий построения Web приложений серверной стороны. Но все популярные на сегодняшний день приложения имеют общую цель - реализацию бизнес-логики на стороне сервера и генерацию кода для клиента. Также у всех этих приложений одинакова архитектура взаимодействия сервера и клиента и общий протокол взаимодействия - HTTP.
1) Запрос. Клиент, с помощью web-броузера инициирует запрос к серверу по протоколу HTTP.
2) Обработка запроса. После получения запроса web-сервер проводит обработку запрашиваемого ресурса. Если запрашиваем ресурс является статическим, таким как html страница, то процесс обработки фактически сводится к нулю. В противном случае, запрос отправляется соответствующему контейнеру web-приложений, где и происходит дальнейшая работа.
3) Взаимодействие с базой данных. В случае с динамической страницей приложению может понадобиться информация, хранящаяся в БД. Для этого приложение формирует запрос к БД, которая, в свою очередь, его обрабатывает и возвращает соответствующий результат.
4) Формирование результата. После того, как запрос обработан, информация, подготовленная для пользователя, форматируется для протокола HTTP.
5) Передача данных клиенту. После формирования, данные передаются клиенту в качестве ответа. Ответ содержит данные (обычно HTML код, либо двоичные данные), а также дополнительные параметры, передаваемые в заголовках HTTP ответа.
На сегодняшний день существует достаточно большое количество серверных технологий. К рассмотрению предлагаются только наиболее популярные и наиболее перспективные варианты, т.к. при выборе основной технологии реализации предпочтение, в большинстве случаев, отдается одной из них.
ISAPI - Internet Server Application Programming Interface. Интерфейс ISAPI используются для непосредственного управления поведением Web-сервера. Так, ISAPI позволяет осуществлять доступ к функциям и службам Web-сервера Internet Information Server (IIS) фирмы Microsoft. В каждом отдельном случае применения интерфейса пишется программный код, который вызывается Web-сервером как выходная пользовательская процедура (user exit routine) или "закладка" (user hook). Процедуры вызываются в некоторых заданных (опубликованных) точках программного кода Web-сервера и записываются не в виде отдельных программ, а в виде набора библиотечных функций, действующих в качестве расширения Web-сервера.
ASP (англ. Active Server Pages - "активные серверные страницы") - технология от Microsoft, позволяющая легко разрабатывать приложения для World Wide Web. ASP работает на платформе операционных систем линии Windows NT и на веб-сервере IIS. ASP не является языком программирования - это лишь технология предварительной обработки, позволяющая подключать программные модули во время процесса формирования Web-страницы. Относительная популярность ASP основана на простоте используемых языков сценариев (VBScript или JScript) и возможности использования внешних COM-компонент.
ASP.net является составной частью платформы Microsoft.net и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.net 2.0. Эта версия имеет серьезные отличия от своей предшественницы. Microsoft полностью перестроила ASP.net, основываясь на Common Language Runtime (CLR), который является основой всех приложений Microsoft.net. Программисты могут писать код для ASP.net, используя различные языки программирования, поддерживаемые в.net Framework, обычно (коммерческие) Visual Basic.net, JScript.net или C#, а также "открытые" языки, например, Perl и Python.
Сервлет - программа, которая расширяет функциональные возможности web-сервера, динамически генерируя содержание и взаимодействуя с web-клиентами при помощи принципа запрос-ответ. Web-клиентами могут быть не обязательно браузеры, это могут быть любые программы, использующие протокол HTTP.
JSP (JavaServer Pages) - технология, позволяющая веб-разработчикам динамически генерировать HTML, XML и другие веб-страницы. Является составной частью единой технологии создания бизнес-приложений J2EE. Технология позволяет внедрять Java-код, а также EL (expression language) в статичное содержимое страницы. Также могут использоваться библиотеки JSP тегов для внедрения их в JSP-cтраницы. Страницы компилируются JSP-компилятором в сервлеты, представляющие собой Java-классы, которые выполняются на сервере. Весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Сервлет-контейнеры (Tomcat), способные исполнять JSP страницы, написаны на платформонезависимом языке Java, который может работать под различными операционными системами и платформами. Сервлет-контейнеры могут работать как полноценные самостоятельные web-серверы, работать поставщиком страниц для другого web-сервера или интегрироваться в J2EE сервер приложений. Web-контейнер обеспечивает обмен данными между сервлетом и клиентами, берет на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.
Perl (Перл). Само слово Perl - аббревиатура, которая расшифровывается как Practical Extraction and Report Language (практический язык извлечений и отчётов, отчего сначала язык назывался PEARL, но затем буква "A" "потерялась"). Основной особенностью языка считаются его богатые возможности для работы с текстом, реализованные при помощи регулярных выражений.
PHP (англ. PHP: Hypertext Preprocessor - "PHP: Препроцессор Гипертекста") - скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. В настоящее время поддерживается подавляющим большинством представителей хостинга. Входит в LAMP - "стандартный" набор для создания вебсайтов (Linux, Apache, MySQL, PHP (Python или Perl)). PHP отличается наличием ядра и подключаемых модулей, "расширений": для работы с базами данных, сокетами, динамической графикой, криптографическими библиотеками, документами формата PDF и т.п. Любой желающий может разработать своё собственное расширение и подключить его. Существуют сотни расширений, однако в стандартную поставку входит лишь несколько десятков хорошо зарекомендовавших себя. Интерпретатор PHP подключается к веб-серверу либо через модуль, созданный специально для этого сервера (например, для Apache или IIS), либо в качестве CGI-приложения. Кроме этого, он может использоваться для решения административных задач в операционных системах UNIX, Linux, Windows и др. Однако в таком качестве он не получил распространение.
CGI (от англ.common Gateway Interface - "общий интерфейс шлюза") - стандарт интерфейса, служащего для связи внешней программы с веб-сервером. Программу, которая работает по такому интерфейсу совместно с веб-сервером, принято называть шлюзом, хотя многие предпочитают названия скрипт (сценарий) или CGI-программа. Сам интерфейс разработан таким образом, чтобы можно было использовать любой язык программирования, который может работать со стандартными устройствами ввода/вывода. Такими возможностями обладают даже скрипты для встроенных командных интерпретаторов операционных систем, поэтому в тех случаях, когда нет нужды в сложной функциональности, могут использоваться даже такие простые командные скрипты. Отличается от остальных рассматриваемых технологий тем, что является наиболее низкоуровневой и является стандартом интерфейса, который служит для связи внешней программы с web-сервером.
У ISAPI, как и у других расширений web-серверов имеется один существенный недостаток - это привязка к конкретному Web - серверу. Но для проекта требуется платформа пригодная для построения относительно сложных гетерогенных web-систем, поэтому технология ISAPI не является пригодной для реализации проекта.
Далее под ASP для краткости мы будем понимать ASP.net, как более позднюю версию, отличающуюся рядом преимуществ.
Для дальнейшего выбора технологии воспользуемся исследованиями, предоставленными в открытый доступ [6].
В тестировании принимали участие:
· Tomcat (internal web server);
· mod_php 4.0b2;
· mod_perl 1.21;
· JRun 2.3.3/Apache 1.3.9;
· ServletExec 2.2/Apache 1.3.9;
· CGI using Perl.
Для реализации тестов использовалось следующее аппаратное и программное обеспечение:
· сервер - 300 Mhz Pentium II, RedHat 6.0/64 Мб оперативной памяти;
· клиент - 300 Mhz Celeron, RedHat 6.0/32 Мб оперативной памяти.
Используемые тесты:
File. В данном тесте производилось чтение и передача небольшого (311 байт) статичного файла - т.е. тестирования СТ в качестве обычного web-сервера.
Servlet. Для измерения "накладных расходов" работы СТ использовалась тестовая программа "Hello, World". Другими словами, как бы эффективно ни была написана ваша серверная программа, вы никогда не получите более высокие показатели производительности, нежели в этом тесте.
Hello. Тест, практически во всем аналогичный тесту Servlet, с тем отличием, что применялся для тестирования PHP, Perl`a и ASP, тогда как Servlet относился лишь к Java СТ.
Loop. Тест выводящий "Hello, World" в цикле суммарным объемом около 64 кб. Этот тест, особенно в сравнении с тестом Big дает довольно грубое представление о производительности базовых функций.
Big. В данном тесте производилась отправка сравнительно большого (около 64 кб) массива статичной информации.
DB. Простейший запрос к базе данных (два запроса Select). Дает оценочное представление о производительности цепочки web-сервер - СТ - сервер базы данных (точнее драйвер базы данных - сервер базы данных, даже если драйвер встроенный). Для JAVA тестов во второй части, первое число в таблице означает результаты тестирования с использованием драйвера org. gjt.
MySql. Второе число - результат тестирования с применением драйвера Caucho. В общем случае данный метод двойного тестирования демонстрирует важность драйвера базы данных для быстродействия системы в целом.
Cache. Тот же тест что и DB, но в заголовке страницы указывался "срок давности" (Expires) плюс 15 секунд от времени исполнения.
Таблица 2.1 - производительность (операций в секунду). Более высокие показатели означают большую производительность. Тест для одного пользователя.
Технология |
File |
Servlet |
Hello |
Big |
DB |
Cache |
|
Mod_PHP/Apache |
561 |
291 |
52 |
117 |
117 |
||
Mod_Perl/Apache |
550 |
365 |
92 |
111 |
111 |
||
ServletExec/Apache/IBM |
536 |
98 |
103 |
59 |
59 |
||
Tomcat/IBM |
129 |
100 |
94 |
20 |
50 |
50 |
|
CGI Perl/Apache |
550 |
67 |
28 |
7 |
7 |
||
JRun/Apache/JDK1.2 |
531 |
69 |
37 |
25 |
25 |
||
Tomcat/JDK 1.2 |
37 |
62 |
37 |
12 |
24 |
24 |
Как видно из таблицы PHP и Perl в разы опережают своих конкурентов по всем тестам, кроме "File". Поэтому мы убираем из дальнейшего рассмотрения такие технологии как сервлеты, JSP и CGI. Следует отметить, что из рассмотрения были вычеркнуты технологии на базе Resin web Server, которая является значительно более скоростной, в силу наличия ряда уязвимостей. Так, злоумышленник, согласно журналу "Хакер", после некоторых манипуляций может просмотреть JSP исходный код и получить доступ к ограниченным директориям.
Далее была проведена еще одна серия тестов. Суть их осталась прежней. Единственное существенное отличие состояло в том, что была эмулирована одновременная работа нескольких пользователей - 4 клиента и один сервер. Число четыре было выбрано неслучайно. Учитывая малое время выполнения одного теста, одновременное выполнение четырех запросов представляется, по мнению автора, вполне достаточным и отражает загрузку среднепосещаемого по российским меркам, сервера. (Предположительно около 20000 запросов в течение суток, 50% которых приходится на обед) - получаем пиковую загрузку порядка 10000 запросов в час, или 2,8 запроса в секунду. Также в тестирование была добавлена технология ASP.
Таблица 2.2 - производительность (операций в секунду). Более высокие показатели означают большую производительность. Тест для четырех пользователей.
Технология |
File |
Hello |
Loop |
Big |
DB |
|
Mod_Perl/Apache |
801 |
385 |
11 |
97 |
93 |
|
ASP/IIS |
1654 |
385 |
1.4 |
80 |
- |
|
Mod_PHP/Apache |
869 |
342 |
13 |
44 |
141 |
Для начала сравним PHP и Perl. Исходя из тестов видно, что Perl более чем в 2 раза быстрее работает с большими блоками статической информации, а PHP более чем в полтора раза опережает Perl по скорости взаимодействия с базой данных. Но именно тест "BD" мне кажется более важным, поскольку каждое обращение пользователя к приложению будет инициировать обращение приложения к базе данных. Кроме того, программы, написанные на PHP достаточно легко читаемые в отличие от Perl-программ. Исходя из вышесказанного, я делаю выбор в пользу PHP среди этих двух технологий.
Теперь сделаем последний выбор: ASP - PHP. В пользу ASP говорит ее большая производительность, но на данный момент, ASP в полном объеме существует только для платформы Windows. Разработки по переносу на другие системы ведутся, но еще не завершены и их будущие результаты трудно оценить. Что касается разработки сайтов, то ASP сильно привязана к серверу IIS, и, хотя архитектура позволяет перенести приложения ASP на другую платформу, на данный момент реальная возможность отсутствует. Таким образом важнейшее - многоплатформенность пока еще не может быть удовлетворено платформой ASP.net, а значит ее использование для такой системы пока не оправдано. Однако необходимо отметить, что такая система должна иметь возможности интеграции с платформой.net (особенно Web - сервисы), поскольку ее будущее широкое использование не вызывает сомнений.
Итак, окончательный выбор сделан в пользу PHP.
2.3.1 О достоинствах и недостатках PHP
Достоинства:
· является си-подобным языком, поэтому многим программистам будет легко перейти на него;
· бесплатен;
· в связке с MySQL является кроссплатформенной технологией;
· постоянно совершенствуется;
· допускает работу с большинством СУБД;
· объектно ориентирован;
· поддерживает все популярные протоколы (HTTP, FTP, IMАР, NNTP, POPS, net sockets и другие);
· наиболее популярен в мире и в России в частности.
PHP используется такими компаниями как "Zend", "MySQL", "Бегун", "РДВ-Медия", "Хронопей", "RU-CENTER", "АВТОВАЗ", "Microsoft", а также разработчиками "Мамбы", "МойКруг", "RedTram", "РБК" и многими другими. И, главное, именно на php написаны самые дорогие и сильные, по мнению большинства web разработчиков, системы управления контентом UMI. CMS и Bitrix.
К недостаткам следует отнести то, что PHP является интерпретируемым языком, а значит, ему сложно по скорости сравниться с компилируемым С. Однако, при написании небольших программ, которые в основном и пишутся на PHP этот недостаток не столь существенен, т.к., когда весь проект состоит из многих небольших страниц с кодом, в силу вступают накладные расходы на загрузку в память и вызов CGI-программы, написанной на С.
До недавнего времени к недостаткам PHP относили невозможность написания корпоративных проектов в связи с его слабой объектной моделью, но с выходом пятой версии ситуация изменилась - PHP получил необходимую функциональность.
2.4 Выбор дополнительного программного обеспечения
Поскольку было принято решение использовать в виде клиентских приложений Web-интерфейс, то для его функционирования также необходимо дополнительное программное обеспечение - Web-сервер.
После выбора платформы мы оказываемся перед не столь широким ассортиментом Web-серверов. Для Unix остается несколько возможных вариантов: Apache, Zeus, AOL Server и Pi3Web.
С учетом того, что ранее мы уже остановили свой выбор на PHP, установленном как интегральная часть Web-сервера (SAPI), практически безальтернативным выбором является сервер Apache. Он используется на 70% Web-серверов во всем мире, и показал себя очень надежным и быстрым вариантом. Более того, мы существенно упростим себе жизнь при выборе провайдера, т.к. этот Web-сервер установлен практически у каждого отечественного провайдера.
Следует отметить, что тип используемого Web-сервера никак не влияет на синтаксис PHP, в отличие от операционной системы. Поэтому смена провайдера не повлияет на работоспособность приложения, даже при смене типа Web-сервера.
Apache - это свободно распространяемый Web-cepвep, разработанный по принципу открытой модели кода. В проекте по его разработке могли участвовать все желающие.
Сервер Apache во многом обязан своим появлением компании Netscape. В 1994 года в Netscape перешел Роб Мак-Кул (Rob McCool), который до этого работал в NCSA (National Center for Supercomputing Applications - Национальный центр суперкомпьютерных приложений) и создал Web-сервер NCSA. После его ухода из NCSA процесс разработки сервера приостановился, поэтому Web-мастера стали сами дорабатывать сервер и устранять ошибки. Несколько таких разработчиков объединили свои усилия и начали распространять свои наработки по всему миру (отсюда и название: "apatchy'' означает "защита").
Проект “Apache" - это совместные усилия по разработке программного обеспечения, нацеленное на создание оптимальной, коммерческой, многофункциональной, и свободно-распространяемой реализации HTTP сервера. Проект совместно управляется группой добровольцев, расположенных по всему миру. Коммуникация членов проекта происходит по средствам Интернет, с целью консолидирования усилий в развитии и планировании сервера и его документации. Эти добровольцы известны как Apache Group. Кроме того, сотни пользователей сети внесли свои идеи и труд в развитие и усовершенствование проекта.
На данный момент сервер apache установлен у большинства Хостинг-провайдеров и зарекомендовал себя как наиболее стабильный, функциональный и надежный.
2.5 Разработка структуры системы
В информационном обеспечении можно выделить несколько компонент.
Во-первых, системное программное обеспечение. Данный компонент представляет программное обеспечение, как на стороне клиента, так и на стороне сервера. К системному программному обеспечению относятся операционные системы, под управлением которых будет функционировать разрабатываемая CMS. В соответствии с разделом 2.1, в котором производился выбор операционных систем, были выбраны две операционный системы: Windows XP (ОС для рабочих станций), ASPLinux 9 (ОС для серверов).
Во-вторых, система управления базами данных Mysql. Данный компонент представляет программное обеспечение на стороне сервера. В соответствии с выводами, сделанными в разделе 2.2, данный продукт был выбран в качестве СУБД для проектируемой системы. Собственно, сама проектируемая база данных будет являться подкомпонентом СУБД MySQL.
В-третьих, web-интерфейс. Данный компонент представляет программное обеспечение, как на стороне клиента, так и на стороне сервера. Данный компонент необходим, так как нами было принято решение о создании Web-интерфейса для доступа к СУБД. Данный компонент включает в себя следующие составляющие:
1) Web-браузер. Программное обеспечение, находящееся на стороне клиента, и обеспечивающее доступ к СУБД посредством Web-интерфейса;
2) Web-сервер Apache. Дополнительное программное обеспечение, находящееся на стороне сервера. Web-сервер обеспечивает механизм связи удаленного клиента и СУБД, посредством протокола HTTP.
3) Интерпретатор PHP. Данное программное обеспечение находится на стороне сервера, и обеспечивает работу PHP-скриптов, реализующих интерфейс пользователя.
Рис.2.1 - Архитектура системы управления сайтом
Необходимо разработать и реализовать серверную часть системы, которая будет отвечать за хранение данных и обработку пользовательских запросов к СУБД, и клиентскую часть, которая реализует интерфейс общения клиента с системой.
Выделим основные составляющие серверной и клиентской частей системы, определим их назначение и взаимосвязь.
Очевидно, что серверная часть должна состоять как минимум из сервера баз данных.
Сервер баз данных должен включать в себя СУБД (в нашем случае это MySQL), и соответственно, базу данных, содержащую информацию.
Поскольку было принято решение об использовании Web-интерфейса, то и сервер должен быть настроен в соответствии с требованием обеспечения безопасности подключения. Все ненужные возможности соединения с сервером БД должны быть отключены.
При подключении пользователя к СУБД посредством web-интерфейса используется обычное TCP/IP соединение. Поэтому сервер тоже должен быть настроен соответствующим образом.
Для поддержки работы Web-интерфейса, также необходимо использование Web-сервера.
Основными составляющими Web-сервера являются:
· cобственно Web-сервер (в нашем случае это Apache);
· интерпретатор PHP. Он необходим для выполнения PHP-скриптов, реализующих интерфейс пользователя;
· библиотеки PHP, которые, помимо всего прочего, должны включать набор функций, обеспечивающих доступ к серверу СУБД;
· PHP-скрипты - реализуют интерфейс пользователя.
В общем случае, интерпретатор PHP может быть как отдельным модулем (исполняемой программой), так и входить в состав динамических библиотек Web-сервера.
Web-сервер Apache взаимодействует с интерпретатором PHP посредством специального модуля mod_php, который должен быть включен в конфигурации Web-сервера.
Рассмотрим теперь структуру программного обеспечения со стороны клиента. Клиенты могут работать посредством Web-интерфейса. Со стороны клиентов находится только Web-браузер. Им может быть Internet Explorer, Opera, Mozilla и т.п.
Рассмотрим основные механизмы взаимодействия описанных компонентов информационной системы.
Удаленный пользователь, работающий посредством Web-интерфейса, взаимодействует с Web-сервером через протокол HTTP.
При этом запрос к базе данных передается Web-серверу, тот в свою очередь, принимает его и обрабатывает в соответствии с кодом, написанным в PHP-скриптах, и соответственно генерирует SQL запрос к серверу СУБД.
Web-сервер взаимодействует с сервером СУБД через протоколу TCP/IP.
Сервер СУБД, приняв запрос, формирует ответ, и передает результат обратно Web-серверу. После этого в соответствии с кодом PHP-скрипта, выполнявшего данный запрос, и полученных данных, формируется ответ пользователю в виде html-страницы. Данная страница передается Web-серверу, и после этого сервер передает ее клиенту.
3. Разработка системы управления сайтом и заявками на бронирование номеров
Как показано в предыдущих разделах, функционал проектируемой программной системы можно разбить на 2 части:
· Основной функционал, затребованный заказчиком в самом начале;
· Дополнительный функционал, который может понадобиться заказчику впоследствии.
Особое внимание при проектировании необходимо уделить базе данных, т.к. именно в ней будет храниться вся информация и именно от нее будет зависеть структура классов разрабатываемой программы.
3.1 Разработка базового функционала системы управления сайтом и заявками на бронирование
К элементам, которые относятся к базовому функционалу, относятся система управления сайтом и заявками на бронирование номеров в отелях. Также согласно требованиям заказчика должна быть грамотно проработана система безопасности.
3.1.1 Разработка системы доступа к административной части
Доступ к административной части системы разработан на основе сеансов, т.е. последовательности HTTP-запросов, сделанных в течение определенного интервала времени одним и тем же пользователем с одного и того же компьютера к одному и тому же Web-приложению.
Методология поддержки сеансов базируется на следующем. При первом запросе пользователя генерируется новый сеанс, а все последующие запросы рассматриваются как часть этого сеанса, если они сгенерированы в рамках заданного интервала времени (пока не истекло время ожидания сеанса - session timeout).
Сеанс используется для определения пользователя, подключенного в данный момент к приложению. Если пользователь успешно зарегистрировался, в базу данных приложения добавляется запись с идентификатором сеанса для данного пользователя. Тогда все последующие запросы в рамках этого сеанса воспринимаются как запросы именно этого пользователя, а не какого-либо другого.
Основным элементом сеанса является его идентификатор (session identifier), который однозначно определяет сеанс. Сгенерированный и отправленный клиенту при первом запросе идентификатор сеанса должен быть уникальным и в то же время достаточно защищенным, чтобы злоумышленник не мог легко его подделать.
В разрабатываемой системе идентификаторы сеансов представляют собой 32-символьную строку, состоящую из цифр и символов алфавита. Подделка такого идентификатора достаточно сложна для подделки и требует особых усилий.
3.1.1.1 Обеспечение повышенной безопасности
С учетом требований заказчика о повышенном внимании к безопасности применяются следующие дополнительные средства защиты:
а) Использование временных интервалов истечения срока:
При работе с данными cookie практически всегда устанавливается время истечения срока их действия. Однако нельзя гарантировать, что пользователь не уйдет пить кофе и не забудет завершить сеанс. Использование временных интервалов ожидания предполагает регистрацию временной метки каждого запроса и оценивание времени между последующими запросами в течение сеанса. При истечении времени ожидания (в программе это 5 минут) прерывается сеанс и требуется повторная авторизация пользователя.
б) Задание максимального срока жизни сессии:
На тот случай, если злоумышленнику все-таки удалось получить доступ к некоторой сессии, необходимо снизить ущерб, который он может нанести. Для этого максимальная продолжительность сеанса ограничена часом работы. По истечение этого срока приложение повторно запросит регистрационные данные.
в) Проверка пользовательского агента:
При обращении к приложению оно, в свою очередь, считывает информацию о пользовательском агенте для данного сеанса работы в Web. Это строка, определяющая производителя Web-броузера, его имя, версию и платформу. При этом нельзя гарантировать уникальность подобной строки для каждого компьютера. Однако в мире существует так много различных броузеров и их версий, что с высокой вероятностью различные компьютеры сгенерируют различные строки агента пользователя. Проверяя при последующих запросах соответствие данных агента пользователя, обеспечивается дополнительная линия защиты против взломов сеансов. Интересно, что строка агента пользователя генерируемая броузером Internet Explorer, может быть модифицирована в реестре Windows. Системные администраторы могут воспользоваться этим фактом и создать характерные для рабочих станций их сети строки агентов пользователей. Это несколько усилит данный механизм обеспечения безопасности.
3.1.1.2 Разработка структуры пользовательских сеансов
ER-диаграмма устройства пользовательской сессии представлена на рисунке 3.1.
Рисунок 3.1 - ER-диаграмма пользовательской сессии
Основу структуры составляет таблица user_session (таблица 3.1). Она описывает непосредственно саму сессию, в том числе 32-символьный идентификатор, и именно через нее осуществляется доступ ко всей информации, связанной с сессией.
Таблица 3.1 - Описание таблицы user_session базы данных
Название |
Тип данных |
Описание |
|
id_session |
int |
Идентификатор сессии. Первичный ключ |
|
id_user |
int |
Идентификатор пользователя. Указывает непосредственно на зарегистрированного пользователя, к которому относится сессия |
|
ascii_session_id |
varchar (32) |
32-символьный идентификатор сессии |
|
logged_in |
bool |
Флаг, говорящий о том, авторизовался ли пользователь под этой сессией |
|
last_impression |
datetime |
Время и дата последнего запроса к странице в течение сеанса |
|
created |
datetime |
Время создания сессии |
|
user_agent |
varchar (255) |
Содержит информацию о пользовательском агенте (броузер и пр.) |
Зачастую может понадобиться хранение дополнительных данных в рамках некоторой сессии, например, о посещенных ранее страницах. Для описания и хранения любых подобных переменных используется таблица session_variable (таблица 3.2).
Таблица 3.2 - Описание таблицы session_variable базы данных
Название |
Тип данных |
Описание |
|
id_session |
int |
Идентификатор сессии. Указывает на сессию, к которой относится переменная |
|
id_variable |
int |
Идентификатор переменной. Первичный ключ |
|
variable_name |
varchar (70) |
Имя переменной |
|
variable_value |
text |
Значение переменной |
Регистрационная информация хранится в таблице user (таблица 3.3). Для обеспечения большей безопасности пароль хранится в базе данных в зашифрованном состоянии (используемый метод шифрования - md5), на тот случай, если злоумышленник получит доступ к этим данным.
Таблица 3.3 - Описание таблицы user базы данных
Название |
тип данных |
Описание |
|
id_user |
int |
Идентификатор пользователя. Первичный ключ. |
|
username |
varchar (32) |
Имя пользователя (логин). |
|
md5_pw |
varchar (32) |
Пароль |
Структура также предусматривает последующее расширение функциональности системы, а именно введение различных уровней доступа. Для этого дополнительно спроектированы таблицы access (таблица 3.4) и таблица to_access (таблица 3.5). Они описывают разделы, к которым можно настроить права доступа и определяют непосредственно сам уровень.
Таблица 3.4 - Описание таблицы to_access базы данных
Название |
тип данных |
Описание |
|
id_user |
int |
Идентификатор пользователя. Указывает на пользователя, к которому относятся права |
|
to_access |
int |
Идентификатор раздела, к которому осуществляется доступ. Указывает на раздел, к которому относятся права. |
|
access_level |
int |
Уровень доступа |
Таблица 3.5 - Описание таблицы user базы данных
Название |
тип данных |
Описание |
|
to_access |
int |
Идентификатор раздела, которому можно настроить права доступа. Первичный ключ |
|
name |
varchar (20) |
Имя раздела. |
На основе описанной структуры спроектирован класс UserSession (код можно посмотреть в приложении А). Он является модульным компонентом, удобным для повторного использования. Его легко можно включить практически в любой проект, связанный с поддержкой сеансов или аутентификацией зарегистрированных пользователей.
3.1.2 Разработка структуры представления гостиниц
Общую схему представления гостиниц в базе данных можно увидеть на соответствующей ER-диаграмме на рисунке 3.2.
Рисунок 3.2 - ER-диаграмма гостиницы
Центральным элементом в структуре гостиниц является таблица hotel (таблица 3.6).
Таблица 3.6 - Описание таблицы hotel базы данных
Название |
тип данных |
Описание |
|
id_hotel |
int |
Идентификатор гостинцы. Первичный ключ. |
|
id_adress |
int |
Идентификатор адреса. По нему находится адресная информация о гостинице. |
|
id_meta |
int |
Идентификатор мета-данных. По нему находится информация о мета-тегах гостиницы. |
|
id_created |
int |
Идентификатор создания. По нему находится информация о первом внесении информации о гостинице в базу данных. |
|
id_modify |
int |
Идентификатор изменений. По нему находится информация о последних изменениях данных о гостинице. |
|
id_hotel_type |
int |
Идентификатор типа гостиницы. По нему находится информация о типе гостиницы (гостиница/отель…). |
|
id_service |
int |
Идентификатор услуг. По нему находится информация об услугах, предоставляемых гостиницей. |
|
id_reserving |
int |
Идентификатор бронирования. По нему находится информация об условиях бронирования гостиницы. |
|
id_publish |
int |
Идентификатор публикования. По нему находится информация о необходимости размещения информации о гостинице в общий доступ. |
|
name |
varchar (70) |
Название гостиницы. |
|
stars |
int |
Категории гостиницы (уровень звездности). |
|
numbers |
int |
Общее количество номеров в гостинице. |
|
description |
text |
Описание гостиницы. |
|
sort_num |
int |
Номер списка. Используется для сортировки гостиниц. |
Важными не только для описания гостиниц являются таблицы publish (таблица 3.7), modify (таблица 3.8), created (таблица 3.9), metas (таблица 3.10). Ссылки на них будут встречаться и в дальнейшем.
Зачастую материал, размещаемый в базе данных с помощью системы управления является недоработанным, поэтому для того, чтобы он не выводился на сайте при проектировании предусмотрена соответствующая возможность.
Кроме того, некоторая информация является актуальной только в определенный период времени, поэтому большим преимуществом системы является то, что она способна сама следить за наступлением/истечением времени, когда информация должна быть представлена к общему пользованию. Все эти возможности обеспечиваются с помощью таблицы publish.
Таблица 3.7 - Описание таблицы publish базы данных
Название |
тип данных |
Описание |
|
id_publish |
int |
Идентификатор публикования. Первичный ключ. |
|
publish |
bool |
Флаг публикования. Ноль - не выводить на сайте. |
|
publish_start |
datetime |
Время с которого можно выводить информацию на сайте (если publish=1). |
|
publish_finish |
datetime |
Время до которого можно выводить информацию на сайте. |
Таблицы modify и created практически идентичны, в первой из них хранится информация об изменениях сущности, а во второй о ее создании. Тем не менее сознательно принято решение разграничить соответствующие им сущности для ускорения работы системы.
Таблица 3.8 - Описание таблицы modify базы данных
Название |
тип данных |
Описание |
|
id_modify |
int |
Идентификатор изменений. Первичный ключ. |
|
id_user |
bool |
Идентификатор пользователя. Указывает на пользователя, внесшего соответствующее изменение. |
|
modify_date |
datetime |
Время последнего изменения. |
Таблица 3.9 - Описание таблицы created базы данных
Название |
тип данных |
Описание |
|
id_created |
int |
Идентификатор создания. Первичный ключ. |
|
id_user |
bool |
Идентификатор пользователя. Указывает на пользователя, внесшего соответствующее изменение. |
|
create_date |
datetime |
Время создания. |
Согласно требованиям заказчика необходимо обеспечить возможность редактирования мета-тегов для страниц с описанием гостиниц. Соответствующая информация хранится в отдельно выделенной таблице metas.
Таблица 3.10 - Описание таблицы metas базы данных
Название |
тип данных |
Описание |
|
id_meta |
int |
Идентификатор мета-данных. |
|
title |
bool |
Заголовок Интернет-страницы. |
|
keywords |
datetime |
Ключевые слова Интернент-страницы. |
|
description |
Описание Интернет страницы. |
Дополнительная информация о гостинице хранится в отдельных таблицах. Так, для описания условий бронирования каждой из гостиниц служит таблица reserving (таблица 3.11), а для описания предоставляемых гостиницей услуг - service (таблица 3.12).
Таблица 3.11 - Описание таблицы reserving базы данных
Название |
тип данных |
Описание |
|
id_reserving |
int |
Идентификатор условий бронирования. Первичный ключ. |
|
conditions |
varchar (255) |
Условия бронирования |
|
annulation |
varchar (255) |
Условия аннуляции. |
|
arrival_time |
datetime |
Время и дата прибытия (заезда). |
|
departure_time |
datetime |
Время и дата выезда. |
Таблица 3.12 - Описание таблицы service базы данных
Название |
тип данных |
Описание |
|
id_service |
int |
Идентификатор списка услуг. Первичный ключ. |
|
excurtion |
bool |
Заказ экскурсий. |
|
24hour_service |
bool |
24ч обслуживание в номерах. |
|
car_parking |
bool |
Автостоянка. |
|
currency_exchange |
bool |
Обмен валюты. |
|
hairdressing |
bool |
Парикмахерская. |
|
safe |
bool |
Сейф у администратора. |
|
ticket_reservation |
bool |
Заказ авиа и ж/д билетов. |
|
baggage_room |
bool |
Камера хранения багажа. |
|
smoking |
bool |
Курение в номере. |
|
dry_cleaner |
bool |
Химчистка. |
|
shops |
bool |
Магазины. |
|
guard_station |
bool |
Пост охраны. |
|
transport_reservatuion |
bool |
Заказ транспорта. |
|
internet_access |
bool |
Доступ в Интернет. |
|
jacuzzi |
bool |
Джакузи. |
|
wash_house |
bool |
Прачечная. |
|
first_aid_post |
bool |
Медпункт. |
|
additional |
varchar (255) |
Дополнительные услуги, которые не входят в заранее определенный список. |
Помимо того, о чем уже упоминалось для полного описания гостиниц требуется еще несколько подструктур, о которых речь пойдет в следующих разделах. На основе этой структуры создан класс Hotel. Его код можно найти в приложении А. В нем уже реализован базовый функционал и структурой предусмотрено его дальнейшее расширение.
3.1.2.1 Разработка структуры представления адреса гостиниц
Структура адреса гостиниц (рисунок 3.3) является универсальной, она не привязана непосредственно к гостиницам и может использоваться где угодно.
Рисунок 3.3 - ER-диаграмма адреса гостиницы
Центральным элементом в структуре адреса выступает таблица address (таблица 3.13). Она включает в себя, на первый взгляд, избыточную связь с таблицей city (таблица 3.15), но это сделано специально, т.к. ряд городов просто не имеет районов.
Таблица 3.13 - Описание таблицы adress базы данных
Название |
тип данных |
Описание |
|
id_adress |
int |
Идентификатор адреса. Первичный ключ. |
|
Id_region |
int |
Идентификатор региона. |
|
Id_city |
int |
Идентификатор города. |
|
Id_street_type |
int |
Идентификатор типа улицы (улица/проспект/переулок…). |
|
Street_name |
varchar (70) |
Название улицы. |
|
House |
int |
Номер дома. |
|
Building |
int |
Корпус. |
|
Apartment |
int |
Номер квартиры. |
|
Post_index |
int |
Почтовый индекс. |
Таблицы country (таблица 3.14), city (таблица 3.15) и region (таблица 3.16) служат для описания страны, города и района соответственно.
Таблица 3.14 - Описание таблицы country базы данных
Название |
тип данных |
Описание |
|
id_country |
int |
Идентификатор страны. Первичный ключ. |
|
country |
varchar (70) |
Название страны. |
Таблица 3.15 - Описание таблицы city базы данных
Название |
тип данных |
Описание |
|
id_city |
int |
Идентификатор города. Первичный ключ. |
|
id_country |
int |
Идентификатор страны. Указывает на страну, к которой относится город. |
|
city |
varchar (70) |
Название города. |
Таблица 3.16 - Описание таблицы region базы данных
Название |
тип данных |
Описание |
|
id_region |
int |
Идентификатор раона. Первичный ключ. |
|
id_city |
int |
Идентификатор города. Указывает на город, к которому относится район. |
|
region |
varchar (70) |
Название района. |
В таблице street_type (таблица 3.17) хранится информация о типе улицы. Например: улица, проспект, переулок, шоссе и т.д.
Таблица 3.17 - Описание таблицы street_type базы данных
Название |
тип данных |
Описание |
|
id_street_type |
int |
Идентификатор типа улицы. Первичный ключ. |
|
name |
varchar (70) |
Название типа улицы. |
На основе описанной структуры созданы соответствующие классы, главным из которых является класс Adress. Его код представлен в приложении.
3.1.2.2 Разработка структуры представления телефонов гостиниц
Очередным универсальным элементом, который необходимым, в том числе и гостиницам, является телефон. Описывающая его ER-диаграмма представлена на рисунке 3.4.
Рисунок 3.4 - ER-диаграмма телефонов гостиницы
Основой структуры выступает таблица phone (таблица 3.18). Важно, что структура предусматривает различные типы телефонов, например: факс, обычный телефон, многоканальный телефон. Соответствующая информация хранится в таблице phone_type (таблица 3.19).
Таблица 3.18 - Описание таблицы street_type базы данных
Название |
тип данных |
Описание |
|
id_phone |
int |
Идентификатор телефона. Первичный ключ. |
|
id_phone_type |
int |
Идентификатор типа телефона. |
|
code |
int |
Код телефона. |
|
number |
int |
Номер телефона |
|
description |
varchar (255) |
Описание телефона |
Таблица 3.19 - Описание таблицы phone_type базы данных
Название |
тип данных |
Описание |
|
id_phone_type |
int |
Идентификатор типа телефона. Первичный ключ. |
|
name |
varchar (10) |
Название типа телефона. |
Многие гостиницы имеют несколько телефонов, поэтому для обеспечения связи "многие ко многим" используется дополнительная таблица hotel_phone (таблица 3.20), а для того, чтобы различать телефоны между собой можно хранить описание телефонов в таблице phone.
Таблица 3.20 - Описание таблицы hotel_phone базы данных
Название |
тип данных |
Описание |
|
id_hotel |
int |
Идентификатор гостиницы. |
|
id_phone |
int |
Идентификатор телефона. |
Основным классом, использующимся для описания этой структуры, является класс Phone. Его код можно найти в приложениях.
3.1.2.3 Разработка структуры представления номеров гостиниц
По желанию заказчика система предусматривает введение информации о различных номерах гостиницы. Соответствующую этому ER-диаграмму можно увидеть на рисунке 3.5.
Рисунок 3.5 - ER-диаграмма номеров гостиницы
Естественно, здесь главным элементом выступает таблица number (таблица 3.21). Именно в ней заложена связь номеров с соответствующими им гостиницами (поле id_hotel). В структуре присутствуют уже встречавшиеся ранее таблицы publish (таблица 3.7), modify (таблица 3.8) и created (таблица 3.9). Они предназначены для определения необходимости вывода информации о номере, хранения информации о последних изменениях и о создании соответственно.
Таблица 3.21 - Описание таблицы number базы данных
Название |
тип данных |
Описание |
|
id_number |
int |
Идентификатор номера. Первичный ключ. |
|
id_hotel |
int |
Идентификатор гостиницы. Указатель на гостиницу, к которой относится номер. |
|
id_publish |
int |
Идентификатор публикования. По нему находится информация о необходимости размещения информации о номере в общий доступ. |
|
id_created |
int |
Идентификатор создания. По нему находится информация о первом внесении информации о номере в базу данных. |
|
id_modify |
int |
Идентификатор изменений. По нему находится информация о последних изменениях данных о номере. |
|
name |
varchar (70) |
Название номера. |
|
num_of_numbers |
int |
Количество номеров соответствующего типа. |
|
description |
text |
Описание номера. |
|
list_num |
int |
Сортировочный номер. Требуется для сортировки номеров в списке между собой. |
Для хранения информации о стоимости каждого из номеров требуется 2 таблицы: period (таблица 3.22) и price (таблица 3.23). Дело в том, что в различные периоды спрос на гостиницы различен, а значит различны и цены, поэтому за счет таблицы period задается интервал, которому будет соответствовать цена, а за счет таблицы price уже непосредственно сама стоимость проживания.
Таблица 3.22 - Описание таблицы period базы данных
Название |
тип данных |
Описание |
|
id_period |
int |
Идентификатор периода. Первичный ключ. |
|
id_hotel |
int |
Идентификатор гостиницы. Указывает, к какой гостинице относится данный период. |
|
start_date |
date |
Дата с которой будут вступать в действие соответствующие периоду цены. |
|
finish_date |
date |
Дата до которой будут действительны соответствующие периоду цены. |
Таблица 3.23 - Описание таблицы price базы данных
Название |
тип данных |
Описание |
|
id_price |
int |
Идентификатор цен. Первичный ключ. |
|
id_number |
int |
Идентификатор номера. Указывает, к какому номеру относятся цены. |
|
id_period |
int |
Идентификатор периода. Указывает на период к которому относятся цены. |
|
price |
int |
Стоимость одноместного размещения. |
|
price2 |
int |
Стоимость двухместного размещения. |
Для обеспечения представленного в структуре функционала разработан ряд классов. Их код можно найти в приложениях. Основным классом среди них является класс Number.
3.1.3 Разработка структуры представления заявок
Важным элементом является система заявок на бронирование номеров в отелях города. Ее структура представлена на рисунке 3.6.
Рисунок 3.6 - ER-диаграмма номеров гостиницы
Центральным элементом в структуре выступает таблица demand (таблица 3.24). Она содержит в себе всю необходимую информацию или ссылки на нее. В частности в ней содержатся идентификаторы бронируемых гостиницы и номера в ней. Это не избыточные связи. Дело в том, что бывают случаи, когда клиент выбрал гостиницу, но не определился с номером в ней.
Таблица 3.24 - Описание таблицы demand базы данных
Название |
тип данных |
Описание |
|
id_demand |
int |
Идентификатор заявки. Первичный ключ. |
|
Id_person |
int |
Идентификатор личности. Указатель на информацию о человеке, сделавшем заказ. |
|
Id_phone |
int |
Идентификатор телефона. Указатель на информацию о телефоне для связи. |
|
Id_status |
int |
Идентификатор статуса заявки. Определяет степень обработки заявки (не рассмотрена, в обработке, выполнена и т.д.) |
|
id_price_type |
int |
Идентификатор типа оплаты. Определяет предпочитаемый клиентом способ оплаты. |
|
Id_transfer |
int |
Идентификатор трансфера. Определяет требуются ли клиенту трансферные услуги. |
|
Id_hotel |
int |
Идентификатор гостиницы. Указывает на гостиницу, в которой желает поселиться клиент. |
|
Id_number |
int |
Идентификатор номера. Указывает на номер, в котором желает поселиться клиент. |
|
Id _connection_type |
int |
Идентификатор типа связи. Определяет предпочитаемый клиентом способ связи (e-mail, телефон и прочие). |
|
Comments |
varchar (255) |
Комментарии, которые может оставить к заявке администратор. |
|
Min_price |
int |
Минимальная цена, которую готов платить клиент за проживание. |
|
Max_price |
int |
Максимальная цена, которую готов платить клиент за проживание. |
|
Wishes |
text |
Дополнительные пожелания клиента. |
В таблице demand содержится ряд указателей на таблицы, которые помимо идентификатора содержат лишь поле name: transfer (таблица 3.25), status (таблица 3.26), price_type (таблица 3.27), connection_type (таблица 3.28). Все эти таблицы содержат строго определенный заказчиком перечень значений, который представлены в соответствующих таблицах (список значений может быть расширен).
Таблица 3.25 - Описание таблицы demand базы данных
Название |
тип данных |
Описание |
|
id_transfer |
int |
Идентификатор трансфера. Первичный ключ. |
|
name |
varchar (40) |
Возможные значения: “Без трансфера”, “От аэропорта до гостиницы”, “От вокзала до гостиницы”. |
Таблица 3.26 - Описание таблицы status базы данных
Название |
тип данных |
Описание |
|
id_status |
int |
Идентификатор статуса заявки. Первичный ключ. |
|
name |
varchar (40) |
Возможные значения: “Не рассмотрена”, “Отклонена”, “В обработке”, “Выполнена”. |
Таблица 3.27 - Описание таблицы price_type базы данных
Название |
тип данных |
Описание |
|
id_price_type |
int |
Идентификатор типа оплаты. Первичный ключ. |
|
name |
varchar (70) |
Возможные значения: “Наличными”, “Перевод от физического лица”, “Перевод от юридического лица”. |
Таблица 3.28 - Описание таблицы connection_type базы данных
Название |
тип данных |
Описание |
|
id_connection_type |
int |
Идентификатор типа связи. Первичный ключ. |
|
name |
varchar (20) |
Возможные значения: “По телефону”, “По электронной почте”, “С помощью icq”. |
Также для полного описания заявки используется описанная ранее таблица phone (таблица 3.18) и таблица person (таблица 3.29), содержащая необходимую информацию непосредственно о клиетне.
Таблица 3.29 - Описание таблицы person базы данных
Название |
тип данных |
Описание |
|
id_person |
int |
Идентификатор личности. Первичный ключ. |
|
id_city |
int |
Идентификатор города. Указывает на город, из которого приезжает клиент. |
|
surname |
varchar (70) |
Фамилия клиента. |
|
name |
varchar (70) |
Имя клиента. |
|
|
varchar (150) |
Электронный адрес клиента. |
Основным классом, обеспечивающим в данной структуре заявленную функциональность выступает класс Demand.
3.2 Разработка дополнительного функционала системы управления сайтом
Помимо основного функционала, согласно требованиям заказчика необходимо предусмотреть расширение системы.
3.2.1 Разработка структуры фотогалереи
Подобные документы
Характеристика гостиничного комплекса и существующей системы управления. Структурная схема предприятия. Информационные потоки. Цели создания автоматизированной системы управления. Локальные сети. Описание информационной базы и интерфейса пользователя.
дипломная работа [4,9 M], добавлен 16.10.2012Основные понятия гостиничной индустрии и виды бронирования. Способы бронирования гостиничных номеров. Характеристика системы и ее особенности. Система формирования сводок и отчетов. Регистрация, размещение и выписка гостей. Управление работой горничных.
курсовая работа [27,0 K], добавлен 10.01.2014Описание предметной области и процессов обработки информации, требующих автоматизации. Обзор существующих программных продуктов. Описание структуры системы бронирования гостевого дома. Назначение и функции программы. Описание методов защиты данных в ИС.
дипломная работа [154,6 K], добавлен 08.02.2013Компания Amadeus как поставщик передовых решений в области информационных технологий, дистрибуции и электронной коммерции для индустрии туризма и авиаперевозок. Система бронирования Amadeus и история ее создания. Продукты и дополнительные спектр услуг.
реферат [35,2 K], добавлен 29.03.2012Разработка многопользовательской системы бронирования авиабилетов, описание и построение модели. Этапы концептуального и логического проектирования, реализация запросов, получение информации по рейсам, их поиск по определенным критериям, заказ билетов.
курсовая работа [1,2 M], добавлен 25.05.2010- Особенности применения компьютерных технологий бронирования на предприятиях индустрии гостеприимства
Деятельность службы бронирования отеля и её функции. Роль информационных технологий в автоматизации управления электронными каналами продаж. Применение систем интернет-бронирования и АСУ в ГУП "Санаторий Зеленая Роща РБ" и гостинице "Президент-Отель".
курсовая работа [51,3 K], добавлен 14.10.2014 Понятие, принципы бронирования билетов на железнодорожные рейсы, порядок автоматизации данного процесса. Методика и этапы формирования программного обеспечения для упрощения бронирования на основе входной и выходной информации. Модели организации данных.
контрольная работа [25,4 K], добавлен 21.02.2012Характеристики и оценка значения, а также роль и значение компьютерных систем бронирования и резервирования на современном рынке. Зарубежные и российские системы, используемые в данной сфере, их сравнительное описание, анализ преимуществ и недостатков.
презентация [2,0 M], добавлен 17.11.2015Описание процесса бронирования билетов. Концептуальное и физическое проектирование базы данных. Точность и корректность хранения и отображения данных в базе данных. Проектирование логики диалога с пользователем. Разработка и описание приложения.
курсовая работа [1,7 M], добавлен 11.02.2016Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.
курсовая работа [8,7 M], добавлен 14.05.2014