Разработка веб-приложения на тему «Организация въездного туризма в Республике Беларусь»
Для обработки данных и связи клиентского приложения с веб-сервисами был использован AngularJS — JavaScript-фреймворк с открытым исходным кодом. Он предназначен для разработки одностраничных приложений. Его цель — расширение браузерных приложений на основе MVC шаблона, а также упрощение тестирования и разработки. Фреймворк работает с HTML, содержащим дополнительные пользовательские атрибуты… Читать ещё >
Разработка веб-приложения на тему «Организация въездного туризма в Республике Беларусь» (реферат, курсовая, диплом, контрольная)
О пользе туризма человечеству известно с древних времен. Именно благодаря удивительным способностям туризма просвещать, удивлять, лечить и дарить отдых эта услуга приобрела такую популярность в наши дни. Сегодня на земном шаре нет человека, который не мечтал бы о каком-нибудь путешествии.
Еще в древности люди поняли, что сидя дома многого о мире не узнаешь, а если и прочитаешь в книгах о загадочных дальних странах, но все равно ничто не сравниться с возможностью увидеть их своими глазами. Именно в образовательных целях путешествовали умнейшие люди древности, и именно с этими целями продолжают увлекаться туризмом наши современники. Возможность увидеть многогранный и удивительный мир, во всех оттенках его красок, со всеми его тайнами и удивительными обитателями, с осколками древних цивилизаций и лучшими творениями наших современников — все это делает туризм важнейшим занятием человечества.[1]
Поэтому туризм — это неотъемлемая часть нашей жизни. Каждая страна — это источник новых впечатлений и расширения кругозора, и важно не только самим путешествовать, а еще и помогать другим открывать новые места. Поэтому необходимо обратить внимание на развитие въездного туризма там, где он слаб. Ведь въездной туризм — одна из самых прибыльных отраслей в экономике любой страны. Если верить данным Всемирной туристской организации, прием иностранных гостей в шесть раз выгоднее экспорта мяса, в три раза — экспорта электроники. Поэтому каждая страна уделяет большое внимание развитию въездного туризма. А что же в этом отношении делается в Беларуси? Чем мы можем привлечь иностранных гостей?[2]
По статистике, более 80 процентов от общего количества туристических операторов Беларуси работают исключительно на выездной туризм. Въездной туризм пока развит слабо. Вот это как раз и вызывает недоумение. Ведь богатая в природном плане Беларусь может и должна привлекать огромное число любителей активного отдыха. Стоит только задействовать скрытые ресурсы.
Задача по развитию туристической деятельности в Беларуси возложена главным образом на Министерство спорта и туризма. Именно это ведомство призвано контролировать деятельность многочисленных туроператоров страны, решать вопросы выездного и въездного туризма. Министерством накоплен колоссальный организаторский опыт. Вот только, как говорится, теория без практики не имеет смысла: без помощи ведомств, которые могут и хотят предложить привлекательный для туристов продукт, в этом деле не обойтись. [3]
Люди, приезжая в нашу страну из дальних стран, ожидают увидеть страну, остановившуюся в развитии. Некоторые туристы даже не подозревают, как Беларусь богата на культурные наследия, достопримечательности. Есть люди, которые считают, что Советский союз вовсе не был причастен к событиям Второй Мировой войны и наша задача изменить представление иностранных граждан о нашей стране, дать им возможность оценить всё богатство нашей истории и богатство архитектурного наследия.
Для формирования положительного имиджа Беларуси нужно повышать качество туристического продукта. Необходимо продуманно, с учетом пожеланий туристов составлять программы туров. А экскурсии должны проводить хорошо подготовленные кадры. И рекламировать Беларусь нужно всеми возможными способами — лишь тогда о нас узнают и туризм сможет стать доходной отраслью и в нашей стране.
Поэтому необходимо создавать качественные веб-приложения, способные привлечь внимание и предоставить всю необходимую информацию и задействовать все ресурсы для продвижения их на зарубежный рынок.
Интересный факт, что туристы из соседних государств, а точнее, Литвы, Польши, которые были в составе Речи Посполитой, Великого княжества Литовского, ищут следы своих предков, посещают могилы, но не могут найти нужной информации, которая помогла бы им осуществить желаемое. А люди, работающие с иностранцами из Западной Европы, отмечают полнейшее отсутствие информации о Беларуси и говорят о том, что к нам едут те, у кого хватило терпения найти такую информацию. [4]
Таким образом, недостаток доступной информации — одно из главных препятствий для развития въездного туризма в Беларуси.
Необходимо создать такую систему, которая содержала бы полную информацию о Беларуси, о всех возможных турах и прочих туристических услугах.
Важно отметить, что многие из тех, кто решил путешествовать по Беларуси, позже отмечает не всегда высокий уровень сервиса в регионах, а также ограниченное количество предложений местных туров. Мир, Несвиж, Полоцк, Брест и, конечно, Минск — это все, конечно, хорошо, а что делать тем, кто хочет путешествовать не по строго определенным программам, а в индивидуальном порядке[5]
Поэтому в системе можно реализовать возможность составления индивидуальных маршрутов, учитывая тот факт, что с каждым годом становится все больше самостоятельных туристов.
Oдним из важных принципов влияния на развитие въездного туризма является необходимость управления национальным туристическим продуктом, к которому относят следующие основные составляющие:
— формирование стратегии развития въездных туристических потоков;
— управление номенклатурой въездных туров;
— контроль качества национального туристского продукта. 6]
Таким образом, целью данной курсовой работы является создание системы, которая помогла бы подчеркнуть уникальность белорусской природы и культуры, помочь развитию туристической инфраструктуры и поднять имидж страны в глазах иностранных туристов. Также возможно, что такая система даст дополнительный толчок для развития и организации въездного туризма.
Разрабатываемая система будет осуществлять следующие задачи:
1. возможность создания турпродуктов;
2. система взаимодействия туроператоров и туристов;
3. возможность поиска туристических услуг;
4. поддержка мультиязычности;
5. возможность управления номенклатурой въездных туров;
6. возможность создания индивидуальных маршрутов;
7. возможность оценки туров и возможность добавления комментариев;
8. возможность анализа информации о развитии въездного туризма.
Для достижения поставленной цели необходимо решить следующие задачи:
— изучить и проанализировать предметную область;
— выделить сущности для создания базы данных;
— создать расширяемую базу данных;
— спроектировать и реализовать серверный проект, реализующий взаимодействие с базой данных и бизнес-логику проекта;
— разработать удобный и понятный интерфейс.
1. ОРГАНИЗАЦИЯ ТУРИСТИЧЕСКОЙ ДЕЯТЕЛЬНОСТИ И ВЪЕЗДНОГО ТУРИЗМА В РЕСПУБЛИКЕ БЕЛАРУСЬ
Необходимо выделить основные понятия, которые помогут выделить сущности и процессы разрабатываемого приложения.
Туризм — временные выезды людей в другую страну или местность, отличную от места постоянного жительства на срок от 24 часов до 6 месяцев в течение одного календарного года или с совершением не менее одной ночевки в развлекательных, оздоровительных, спортивных, гостевых, познавательных, религиозных и иных целях без занятия деятельностью, оплачиваемой из местного источника. 7]
Данное определение помогает выделить категории целей, с которыми турист осуществляет путешествие и сроки совершения путешествия.
Так как основной задачей приложения является возможность создания и продвижения туров по Беларуси, нужно выделить само понятие — тур. Он также является объектом нашей системы.
Тур — сформированный туроператором для реализации комплекс туристических услуг, включающий не менее двух из следующих трех видов услуг: по перевозке, размещению, иные туристические услуги (по питанию, организации туристического путешествия, экскурсионные и другие услуги), не являющиеся сопутствующими услугам по перевозке или размещению, позволяющие совершить туристическое путешествие.
Есть также близкое к туру понятие — туристическое путешествие.
Туристическое путешествие — организованное путешествие (поездка, передвижение, пребывание) физических лиц за пределы их места жительства (места пребывания) с целью отдыха, познавательными и другими целями без занятия трудовой, предпринимательской, иной приносящей доход деятельностью, оплачиваемой и (или) приносящей прибыль (доход) из источника в посещаемой стране (месте). [8]
В соответствии с законом РБ «О туризме» формирование тура включает в себя составление программы туристического путешествия и формирование комплекса туристических услуг, позволяющих совершить туристическое путешествие. К формированию тура также относится приобретение права на реализацию тура либо комплекса туристических услуг, сформированных нерезидентом Республики Беларусь.
Программа туристического путешествия включает в себя информацию:
— о маршруте туристического путешествия, дате и времени начала и окончания туристического путешествия;
— о порядке встречи и проводов, сопровождения туриста, экскурсанта;
— о характеристике транспортных средств, осуществляющих перевозку туриста, экскурсанта, сроках стыковок (совмещений) рейсов;
— о характеристике объектов для размещения туристов, в том числе их местоположение, классификация по законодательству страны (места) временного пребывания, правила временного проживания, а также иная обязательная информация, установленная законодательством страны (места) временного пребывания;
— о порядке обеспечения питания туриста, экскурсанта во время осуществления туристического путешествия;
— о перечне и характеристике иных оказываемых туристических услуг.
Также можно выделить такое понятие как туристический продукт.
Туристский продукт — это реализуемая по единой цене, заранее подготовленная (предварительно разработанная) комплексная туристская услуга, в состав которой входят как минимум две из следующих услуг: а) перевозка; б) размещение; в) туристская услуга, не составляющая существенную часть туристского продукта, при условии, если обслуживание охватывается периодом от 24 часов до 6 месяцев подряд или размещением более одной ночевки. Отдельная оплата услуг, входящих в туристский продукт, а также формирование туристского продукта по конкретному заказу туриста, не освобождает туроператора или турагента от оказания всех услуг, входящих в туристский продукт, независимо от того, кем эти услуги оказываются.
На рисунке 1 выражена вся суть туристического продукта.
Рисунок 1.1 — Состав туристического продукта Реализация тура субъекту туристической деятельности осуществляется на основании договора комиссии или иных договоров, не запрещенных законодательством.
Реализация тура участнику (участникам) туристической деятельности осуществляется на основании договора оказания туристических услуг.
Договор оказания туристических услуг заключается в письменной форме и кроме существенных условий, определенных законодательством, должен содержать следующие существенные условия:
— стоимость туристических услуг, сроки и порядок их оплаты;
— сведения об исполнителе, его месте нахождения (месте жительства индивидуального предпринимателя) и банковские реквизиты;
— сведения о заказчике в объеме, необходимом для оказания туристических услуг;
— программу туристического путешествия;
— права, обязанности и ответственность сторон;
— условия изменения и расторжения договора оказания туристических услуг, порядок урегулирования возникших споров и возмещения причиненных убытков (вреда);
— иные условия, относительно которых по заявлению одной из сторон должно быть достигнуто соглашение. закон]
На рисунке 1 также представлена схема взаимодействия объектов и субъектов туристической деятельности в среде въездного туризма.
Необходимо выделить субъекты нашей системы: турагент, туроператор, пользователь туристических услуг.
Турагент — организация — посредник, занимающаяся продажей сформированных туроператором туров. Турагент приобретает туры у туроператора и реализует туристский продукт покупателю, либо выступает посредником между туристом и туроператором за комиссионное вознаграждение, предоставляемое туроператором.
Туроператор (туристический оператор) — организация, занимающаяся комплектацией туров и формированием комплекса услуг для туристов, продвижением и реализацией туров. Туроператор разрабатывает туристские пакеты, обеспечивает предоставление туристских услуг, рассчитывает цены на туры, передает туры турагентам для их последующей реализации туристам, обеспечивает информационную поддержку процесса реализации тура.
Некоторые турфирмы совмещают функции туроператора и турагента, выступая как туроператор (компания, формирующая туристский продукт) по одному или нескольким направлениям и как турагент (компания, реализующая продукт, созданный другими туроператорами) по многим другим направлениям, для ассортимента. 7]
Рисунок 1.2 — Структура тура и взаимодействие между субъектами туристической деятельности Также важно различать, что туроператором может быть только юридическое лицо, а турагентом — как индивидуальный предприниматель, так и юридическое лицо.
Для составления тура нам необходимо будет выбирать точки, которые можно назвать туристическими объектами. В свою очередь, туристические объекты можно разделить на три группы (рисунок 1.3) и выделить отдельную категорию — комплекс. Каждая категория отличается целенаправленностью туристического объекта и данными, которые предоставляются. Как видно из рисунка, к группе, А относятся природные объекты, к группе В — достопримечательности, а к группе С — достопримечательности и объекты со своей инфраструктурой.
Рисунок 1.3 — Разделение туристических объектов по группам На рисунке 1.4 представлено разделение туристических объектов по группам и определение данных, которые будут характеризовать каждую группу.
Рисунок 5 — Основные атрибуты по группам туристических объектов
2. ОПИСАНИЕ ПРОЦЕССА СОЗДАНИЯ И РЕАЛИЗАЦИИ ТУРА
Исходя из анализа предметной области, главным процессом предметной области является создание и реализация тура. Описание процесса реализуется с помощью методологии IDEF0.
Входными данными к данному процессу являются:
— данные о туре — необходимы данные для создания туристического продукта: время начала, время окончания, туристические объекты, предлагаемые услуги;
— данные о турфирме/туроператоре/турагенте — данные, необходимые для идентификации поставщика тур продуктов и составления договора: реквизиты, адрес и пр.;
— данные о клиенте — данные, необходимые для составления договора, а также пожелания и контактные данные;
— данные об исследовании рынка — данные, необходимые для создания туристического объекта, включающие в себя маркетинговые исследования и опросы о пожеланиях клиента.
Стрелка управления — это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. В построенной модели работа туроператора, турагента и клиента осуществляется в рамках закона Республики Беларусь «О туризме», правил разработки туристического продукта и правил использования системы, написанных разработчиком.
Механизмами нашего процесса являются туроператор, турагент и пользователь туристической услуги.
На выходе мы получим договор оказания туристических услуг и реализованный туристический продукт.
Функциональная модель процесса — «Создание и реализация тура» представлена на рисунке 2.1.
Главный процесс можно разделить на четыре подпроцесса:
1. проектирование туристического продукта — этап, на котором выделяются основные направления, выбираются необходимые данные и составляется проект тура;
2. создание туристического продукта — создание туристического продукта после его утверждения;
3. внедрение туристического продукта на рынок;
4. реализация тура и заключение договора — реализация тура здесь предполагает оплату туристического продукта и получение всех услуг клиентом.
Рисунок 2.1 — Контекстная диаграмма верхнего уровня Результат декомпозиции главного функционального блока можно увидеть на рисунке 2.2.
В свою очередь, разработка туристического продукта состоит из следующих этапов:
— первый этап: определение цели;
— второй этап: общие рамочные условия предложения (например, тема, название/наименование, продолжительность);
— третий этап: выбор соответствующей сервисной составляющей предложения;
— четвертый этап: расчет стоимости сервисной составляющей, оценка стоимости предложения на человека;
— пятый этап: описание туристического пакета с текстом и (значащими!) картинками, веб-сайт / интерактивная карта и т. д. ;
— шестой этап: анализ проекта.
Рисунок 2.2 — Декомпозиция главного функционального блока Результат декомпозиции блока «Проектирование туристического продукта «представлен на рисунке 2.3.
Рисунок 2.3 — Декомпозиция блока «Проектирование туристического продукта»
Следующий процесс, который необходимо разбить на подпроцессы — это реализация тура и заключение договора. Данный процесс необходимо разбить, т.к. в разрабатываемой системе будет предоставлена возможность автоматической печати договоров.
В первую очередь турагент должен обработать заявку, поступившую от клиента. Затем, взаимодействуя с клиентом, определяется тур, в который поедет клиент, сроки, условия оплаты и прочее. Далее составляется договор, в котором будут отражены все известные данные. После этого договор подписывают обе стороны и турагент дожидается оплаты туруслуги и самого тура. Только после этого на выходе мы получим реализованный туристический продукт.
Рисунок 2.4 — Декомпозиция блока «Реализация тура и заключение договора»
3. ПОСТАНОВКА ЗАДАЧИ И ОБЗОР МЕТОДОВ ЕЁ РЕШЕНИЯ
При разборе предметной области и описании основного процесса мы определили следующие задачи:
— разработать информационную систему и реализовать ее в виде клиент-серверного web-приложения;
— реализовать предусмотренные варианты использования;
— разработать клиентское приложения с простым и доступным интерфейсом.
Языком программирования для разработки серверной части информационной системы по организации въездного туризма в Республике Беларусь был выбран Java, что обусловлено рядом преимуществ данного языка:
1. Кросс — платформенность;
2. Объектная ориентированность;
3. Унифицированный доступ к базам данных;
4. Ориентация на Internet-задачи, сетевые распределенные приложения;
Для разработки сервисов на языке Java был выбран фреймфорк Jersey, который позволяет проектировать RESTful Web Services.
В качестве ORM была выбрана библиотека Hibernate. Данная библиотека предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных.
Для разработки сервисов и классов доступа к базе данных используется IDE Eclipse.
В качестве СУБД принята свободная объектно-реляционная система управления базами данных MySQL.
Клиентский интерфейс реализуется с использованием HTML5, CSS3, JavaScript, а также с помощью JavaScript-фреймворка AngularJs. AngularJs предназначен для разработки одностраничных приложений. Его цель — расширение браузерных приложений на основе MVC шаблона, а также упрощение тестирования и разработки. Фреймворк работает с HTML, содержащим дополнительные пользовательские атрибуты, которые описываются директивами, и связывает ввод или вывод области страницы с моделью, представляющей собой обычные переменные JavaScript. Значения этих переменных задаются вручную или извлекаются из статических или динамических JSON-данных[7].
4. СПЕЦИФИКАЦИЯ СИСТЕМЫ
В разрабатываемой системе я выделила два субъекта, которые будут пользователями.
Первый пользователь — пользователь туристической услуги. У данного пользователя будут следующие варианты использования:
— поиск туристических объектов — пользователь будет иметь доступ ко всей базе туристических объектов Беларуси и сможет выбрать критерии поиска;
— поиск туров — доступ ко всем предлагаемым турам;
— забронировать тур — возможность подачи заявки на соответствующий тур;
— управлять личным кабинетом — возможность создания своего личного кабинета для сохранения данных о понравившихся туристических объектах и турах;
— возможность составления договора с поставщиком туристических услуг;
— возможность отправки сообщения;
— добавить место — пользователь имеет право занести объект в базу туристических объектов Республики Беларусь;
— получить правовую информацию о туризме — возможность получения полной информации о правах и обязанностях участников туристической деятельности;
— сформировать личный маршрут — пользователь будет иметь возможность составить индивидуальный маршрут своего путешествия.
Второй пользователь — это турфирма/туроператор/турагент, т. е. то лицо, которое может создавать туры и предлагать пользователю. Данный пользователь будет иметь следующие возможности:
— поиск туристических объектов — то же что и у первого пользователя;
— добавить место;
— отправить сообщение;
— составить договор об оказании туруслуг;
— получить правовую информацию о туризме в РБ;
— управление заявками и документами — возможность обработки поступающих от клиентов заявок и добавлять, редактировать документы;
— управление тур программами, которое включает в себя: просмотр туров, создание туристических услуг, редактирование турпрограмм, удаление турпрограмм.
Рисунок 3 — Варианты использования системы
5. МОДЕЛИ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ И ИХ ОПИСАНИЕ
Для лучшего представления спроектированной системы необходимо было построить UML диаграммы: последовательности, состояний, компонентов, развертывания, классов.
Первая диаграмма — диаграмма последовательности. На ней можно увидеть последовательность действий программы при авторизации пользователя на сайте. В ней участвуют пользователь, страница index. html, обработчик и контроллер Controllers. js, класс веб-сервиса TourServices. java, класс логики ReciepeDao. java, класс сущности User. java и сама база данных TripStoreDB. Рисунок диаграммы представлен в приложении Б.
Вторая диаграмма — диаграмма классов. Диаграммы классов используются для разработки статического представления системы. Классы размещены в различных пакетах, поэтому диаграммы построены для каждого из них и представлены в приложении В.
В пакете by.piulskaya.entity находятся классы — сущности базы данных.
В пакете by.piulskaya.dao находятся классы доступа к данным.
В пакете by.piulskaya.services находятся классы бизнес-логики приложения, веб-сервисы.
В пакете by.piulskaya.util находятся вспомогательные классы приложения.
Следующая диаграмма — диаграмма состояний. Она отображает возможные состояния определенного объекта во время функционирования системы. В данном случае в качестве объекта были выбраны данные о туробъекте. Сама диаграмма представлена в приложении Г.
Четвертая по счету диаграмма — диаграмма компонентов, которая показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты.
Разработанный проект содержит такие компоненты как:
— драйвер для подключения com.mysql.jdbc.Driver;
— конфигурационные файлы: pom. xml — для подключения зависимостей, web. xml — для разворачивания приложения;
— пакеты приложения:
by.piulskaya.entity,
by.piulskaya.dao,
by.piulskaya.services,
by.piulskaya.util.
Построенная диаграмма находится в приложении Д.
И последняя диаграмма — диаграмма развертывания. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime).
При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними.
Наша система имеет клиент-серверную архитектуру.
Клиент в данном случае — это пользовательский интерфейс в браузере, запущенном на его компьютере.
Сервер — это веб-контейнер (в данном случае Apache Tomcat), развернутое в нем приложение и база данных, к которой можно подсоединиться с помощью драйвера com.mysql.jdbc5.1.5.jar.
Соединение клиента с сервером происходит по протоколу HTTP.
Полученная диаграмма развертывания представлена в приложении Е.
6. ИНФОРМАЦИОННАЯ МОДЕЛЬ СИСТЕМЫ И ЕЕ ОПИСАНИЕ
С помощью подробного анализа предметной области и выбора необходимых данных можно выделить следующие сущности:
— Страна;
— Регион;
— Населенный пункт;
— Адрес;
— Туристический объект;
— Категория туристического объекта;
— Тур;
— Тип тура;
— Точка тура;
— Комментарий к туру;
— Транспорт;
— Заявка;
— Цена тура;
— Пользователь;
— Турфирма/Туроператор/Турагент;
— Сообщение;
— Язык.
Чтобы построить физическую модель необходимо определить, какие атрибуты будут в каждой сущности и какой тип данных выбрать.
Для таблицы «Страна» можно выделить следующие атрибуты:
— КодСтраны — является первичным ключом данной сущности и представлен целым уникальным числом;
— НазваниеСтраны — название страны, представленное в виде строки ;
— КодЯзыка — язык описания сущности.
Следующая таблица — «Регион», которая содержит информацию о регионах определенной страны и включает атрибуты:
— КодРегиона — уникальный идентификатор сущности целочисленного типа;
— Название региона — название региона, области, штата страны;
— КодЯзыка — язык описания сущности.
Следующая сущность — «Населенный пункт», содержащая информацию о населенном пункте в определенном регионе конкретной страны и включающая следующие поля:
— КодНаселенногоПункта — уникальный идентификатор данной сущности;
— НазваниеНаселенногоПункта — название города, деревни и т. п., строковый формат;
— КодЯзыка — язык описания сущности.
Дальше следует сущность «Адрес», которая описывает почтовый адрес объекта и включает следующие атрибуты:
— КодАдреса — уникальный идентификатор;
— Улица — название улицы, строковый формат;
— Дом — номер дома, числовой формат;
— Корпус — корпус дома — необязательный атрибут;
— Офис — офис, квартира, помещение;
— Индекс — почтовый индекс;
— КоординатаX — координата широты места для определения расположения на карте;
— КоординатаУ — координата долготы места для определения расположения на карте;
— КодНаселенногоПункта — код населенного пункта, к которому относится данный адрес;
Следующая таблица — «Туристическое место», одна из ключевых таблиц, содержит всю информацию о туристических объектах и включает атрибуты:
— КодМеста — первичный ключ, представленный целым числом;
— НазваниеМеста — название туристического объекта;
— ОписаниеМеста — описание туристического объекта;
— ТипМеста — тип места, который определяет, какие поля сущности будут заполнены;
— ИсточникИнформации — человек или информационный ресурс, представленный в виде строки;
— СайтОбъекта — сайт туристического объекта, если он существует;
— ЭлектронныйАдрес — адрес электронной почты туристического объекта — необязательный параметр;
— РасписаниеОбъекта — расписание туристического объекта с указание рабочих дней и праздников;
— КодАдреса — почтовый адрес туристического объекта;
— КодАвтора — ссылка на пользователя, добавившего данный туристический объект.
Следующая сущность — «Катерогия», которая описывает категории туристических объектов и включает в себя 2 поля:
— КодКатегории — является первичным ключом данной сущности и представлен целым уникальным числом;
— НазваниеКатегории — название категории, выраженное строкой;
Дальше следует одна из самых значительных сущностей — «Тур», которая описывает туристическую программу и включает следующие атрибуты:
— КодТура — уникальный идентификатор;
— ПродолжительностьТура — продолжительность тура или экскурсии, которая выражается в часах или днях;
— НазваниеТура — название туристического путешествия;
— ОписаниеТура — краткое описание тура и его особенностей;
— ДатыНачалаПоездки — даты, в которые турист может отправиться в поездку;
— Категория — категория тура: история, спорт и пр.;
— МаршрутТура — населенные пункты, по которым будут следовать туристы;
— КодЦены — ссылка на цену тура с указанием валюты;
— ТипПеревозки — транспорт, на котором будет проводится экскурсия;
— ВключеноВСтоимость — описание услуг, которые включены в стоимость, текстовый формат.
" Точка тура" - следующая сущность, содержащая информацию о месте остановки, питании, ночевке и прочих услугах и включает в себя следующие поля:
— КодТочки — является первичным ключом данной сущности и представлен целым уникальным числом;
— НомерТочки — номер, который определяет порядок следования точек;
— КодТура — указатель на тур, в котором будет текущая точка остановки;
— ОписаниеТочки — описание услуги, приходящейся на данную точку;
— ВремяНачала — начальное время точки;
— ВремяОкончания — время, когда точка сменяется на другую;
— ТипУслуги — тип услуги, предоставляемый в конкретной точке.
Следующая сущность — «Заявка», которая необходима для отправки пользователем заявки на определенный тур и включающая следующие поля:
— КодЗаявки — код заявки, целочисленный идентификатор;
— Email — электронный адрес отправителя заявки;
— Телефон — контактный телефон отправителя заявки;
— ФИО — фамилия, имя, отчество отправителя;
— ТекстЗаявки — текст заявки с пожеланиями пользователя;
— ЖелаемыеДаты — желаемые дни отправления в тур или экскурсию;
— КоличествоВзрослых — количество взрослых, намеренных поехать в поездку;
— КоличествоДетей — количество детей, собирающихся поехать в поездку.
Сущностью, которая описывает цену тура является «Цена», которая включает атрибуты:
— КодЦены — уникальный идентификатор;
— ЦенаВзрослого — цена на взрослого;
— ЦенаРебенок — цена на ребенка;
— КоличествоЧел — количество человек на цену, если цена групповая;
— Заметки — информация к цене;
— КодВалюты — валюта, в которой указывается цена.
Следующая сущность — «Пользователь» идентифицирует пользователя и включает в себя такие поля, как:
— КодПользователя — первичный ключ, представленный целым числом;
— Логин — логин пользователя;
— Email — электронный адрес пользователя;
— Права пользователя — права пользователя: администратор, турист, поставщик услуг.
Следующая сущность — «Турпоставщик», содержащая информацию о поставщике услуг, которая содержит следующие поля:
— КодТурфирмы — первичный ключ, представленный целым числом;
— НазваниеТурфирмы — название юридического лица или имя индивидуального предпринимателя;
— ЮридическийАдрес — ссылка на юридический адрес зарегистрированного юридического лица иди индивидуального предпринимателя;
— ЭлектронныйАдрес — адрес электронной почты для связи с турфирмой.
Дальше следует сущность, тесно связанная с составлением договоров — «Реквизиты», которая включает такие атрибуты, как:
— КодРеквизита — уникальный идентификатор;
— ЮридическоеНазвание — название организации или имя индивидуального предпринимателя;
— УНП — единый уникальный номер, присваиваемый каждому плательщику при постановке на учёт в налоговом органе в Беларуси;
— ИНН — идентификационный номер налогоплательщика;
— КПП — код причины постановки на учет;
— Телефон — телефон организации;
— БИК — банковский идентификационный код;
— КС — корреспондентский счет;
— КодБанка — ссылка на банк, в котором открыт счет.
Также необходимо выделить главные связи между сущностями:
1. «Тур» — «ТочкаТура» — неидентифицирующая связь «один-комногим», т. е. у одного тура множество точек;
2. «ТочкаТура» — «ТуристическийОбъект» — идентифицирующая связь «многие-ко-многим», т. е. в точке тура может быть множество мест и наоборот;
3. «Тур» — «Заявка» — неидентифицирующая связь «один-комногим», т. е. у одного тура может быть множество заявок;
4. «Пользователь» — «Сообщение» — неидентифицирующая связь «один-комногим», т. е. пользователь может отправлять множество сообщений;
5. «Адрес» — «ТуристическийОбъект» — неидентифицирующая связь «один-ко-многим», т. е. по одному адресу может быть несколько туристических объектов;
6. «ТурФирма» — «Документ» — неидентифицирующая связь «один-комногим», т. е. у турфирмы может быть множество документов.
Разработанная физическая модель системы представлена в Приложении А.
7. ОПИСАНИЕ ОБОБЩЕННОГО АЛГОРИТМА И АЛГОРИТМОВ ПРОГРАММНЫХ МОДУЛЕЙ
Одним из самых сложных алгоритмов в разрабатываемой системе является алгоритм создания тура.
Сложность данного алгоритма состоит в том, что логика создания тура зависит от информации, вводимой пользователем, а также предусматривает добавление туробъектов на этапе создания тура. Данный алгоритм позволяет предусмотреть действия пользователя и разумно организовать взаимодействие пользователя с разрабатываемой системой.
На рисунке 7.1 можно увидеть, что в зависимости от введенной продолжительности тура действия пользователя будут различны. Также на рисунке показана цикличность процесса добавления дней и точек: пользователь в любой момент может изменить продолжительность тура, что изменит порядок выполнения действий пользователя.
Также необходимо описать алгоритм, относящийся конкретно к серверной части приложения. Для этого необходимо было проанализировать работу всего приложения. Необходимо учитывать создание различных объектов, вызов функций и в какой последовательности происходит выполнение задач, учитывая все возможные варианты.
Например, при обращении к веб — сервису должен создаваться объект, который будет отправлен через протокол HTTP, затем необходимо получить доступ к бизнес-логике, предоставляющей функции для работы с данными, а затем вызвать соответствующую функцию, которая отправит запрос к базе данных MySQL и вернет ответ об успешном совершении операции пользователю.
Данный алгоритм для добавления точки изображен на рисунке 7.1.
Рисунок 7.1 — Алгоритм создания тура
8. ОБОСНОВАНИЕ ОРИГИНАЛЬНЫХ РЕШЕНИЙ ПО ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАММНЫХ СРЕДСТВ, НЕ ВКЛЮЧЕННЫХ В ТРЕБОВАНИЯ
Для создания кросс-браузерного CSS и упрощения работы был использован CSS — препроцессор Stylus. Stylus — это препроцессор CSS, позволяющий писать ясный CSS с использованием программных конструкций вместо статических правил. Он имеет ряд преимуществ, таких как:
— Stylus — очень гибкий препроцессор.
— В Stylus есть такая вещь как прозрачные миксины — возможность вызвать функцию как обычное CSS-свойство. Прозрачные миксины очень сильно упрощают поддержку браузерных префиксов. Не нужно запоминать, какие префиксы имеет то или иное свойство, и заботиться о том, нужно ли для очередного свойства писать специальную конструкцию. Достаточно просто всегда писать без префиксов, а об их добавлении позаботится подключённая библиотека.
— Stylus написан на JS. Это значит, что его проще поддерживать и исправлять в нём ошибки.
Для обработки данных и связи клиентского приложения с веб-сервисами был использован AngularJS — JavaScript-фреймворк с открытым исходным кодом. Он предназначен для разработки одностраничных приложений. Его цель — расширение браузерных приложений на основе MVC шаблона, а также упрощение тестирования и разработки. Фреймворк работает с HTML, содержащим дополнительные пользовательские атрибуты, которые описываются директивами, и связывает ввод или вывод области страницы с моделью, представляющей собой обычные переменные JavaScript. Значения этих переменных задаются вручную или извлекаются из статических или динамических JSON-данных.
Преимущества данного фреймворка:
— Имеет двустороннюю привязку данных;
— Модели — это простые объекты JavaScript;
— Имеет внедрение зависимости;
— Имеет автоматическую фильтрацию просмотра;
— Обновляет DOM асинхронно.
Для работы с картой была использована библиотека Leaflet — JavaScript библиотека c открытым исходным кодом для создания интерактивных карт.
9. РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ РАЗРАБОТАННОЙ СИСТЕМЫ И ОЦЕНКА ВЫПОЛНЕНИЯ ЗАДАЧ
При разработке системы по организации въездного туризма в Беларуси было создано два модуля:
1. Модуль для туристов;
2. Модуль для турфирм и операторов.
Сперва проверим работу первого модуля. При открытии сайта перед нами появляется главная страница, где мы можем увидеть случайные туристические объекты, туры, а также можем сразу перейти к поиску туристических объектов, выбрав область в правой панели (рисунок 9.1).
Рисунок 9.1 — Главная страница пользователя Выбрав одну из областей, мы переходим на страницу с результатами поиска по данной области, а также небольшую информацию о самой области.
Список результатов, а также сопутствующую информацию можно увидеть на рисунке 9.2.
Рисунок 9.2 — Результаты поиска по области Нажав на кнопку «Подробнее» у выбранного объекта мы перейдём на страницу с описанием места. Снимок страницы изображен на рисунке 9.3.
Рисунок 9.3 — Страница описания туристического объекта При нажатии кнопки «В мой маршрут» появится форма входа/регистрации пользователя. Пользователь также имеет возможность войти в систему через социальную сеть. Форма изображена на рисунке 9.4.
Рисунок 9.4 — Форма регистрации/входа
Рассмотрим работу второго модуля. При входе турагента в систему загружается рабочая панель. Справа — статическая область навигации, по центру — динамический контент (рисунок 9.5).
Рисунок 9.5 — Рабочая панель турагента/туроператора Нажав на кнопку пользователя в левом верхнем углу перед нами открывается панель пользовательских настроек. Результат представлен на рисунке 9.6.
Рисунок 9.6 — Панель настроек пользователя При нажатии ссылки «Сообщения» перед нами открывается окно с сообщениями, где можно увидеть список всех входящих сообщений, а также создать новое сообщение и выбрать отправителя. Список сообщений отображен на рисунке 9.7.
Рисунок 9.7 — Панель сообщений Также у пользователя есть возможность создания туробъектов, где есть два варианта определения координат и адреса места: вводом вручную и перетаскиванием маркера на карте (рисунок 9.8).
Рисунок 9.8 — Панель сообщений
Тестирование системы показало, что основные задачи курсового проекта были выполнены.
туризм программный интерфейс алгоритм
ВЫВОДЫ И ЗАКЛЮЧЕНИЯ
Данный курсовой проект заключался в проектировании и разработке веб-приложения на тему «Организация въездного туризма в Республике Беларусь».
В начале проектирования были поставлены задачи, которые необходимо было реализовать, а также были определены варианты использования данной системы. Большая часть задач была выполнена, однако, некоторые варианты использования требуют доработки и оптимизации.
Была создана информационная модель, которая удовлетворяет всем требованиям к данной системе, что говорит о том, что предметная область была разобрана качественно.
И что немаловажно, был создан приятный и удобный интерфейс, который сможет привлечь иностранных посетителей, а также не заставит их каждый раз ждать перезагрузки страницы благодаря использованию Ajax.
В заключение можно отметить, что данное приложение практически не имеет аналогов на белорусском рынке и тем более за рубежом, поэтому его расширение действительно может помочь развитию как въездного туризма, так и внутреннего. Сайт можно улучшить добавлением возможностей обратной связи, добавлением возможности отправки сообщений на телефонные номера клиентов для оповещения их о процессе организации поездки, постепенным добавлением других иностранных языков, а также добавлением возможности оценки туров и поставщиков туристических услуг, для того, чтобы иностранные граждане не ошиблись в своем выборе. Также, пользовательская часть данного приложения будет удобна для пользователей мобильных устройств, поэтому разработка мобильного приложения на основе данного приложения также может помочь развитию туризма в нашей стране.
[1] [Электронный ресурс]. — Электронные данные. — Режим доступа: http://www.proektant.by/content/2279.html/http://blojek.info/preimushhestva-i-nedostatki-veb-prilozhenij/.
[2] [Электронный ресурс]. — Электронные данные. — Режим доступа: http://zn.sb.by/obshchestvo-5/article/chem-privlekatelna-dlya-turistov-belarus.html.
[3] [Электронный ресурс]. — Электронные данные. — Режим доступа: http://agrotour.biz/agronews/274-vezdnoy-turizm-kak-privlech-inostrancev-v-belarus.html.
[4] Знамя юности [Электронный ресурс]. — Электронные данные. — Режим доступа: http://zn.sb.by/obshchestvo-5/article/chem-privlekatelna-dlya-turistov-belarus.html.
[5] Беларус-МТЗ обозрение [Электронный ресурс]. — Электронные данные. — Режим доступа: http://www.belarus-mtz.by/?p=30 271.
[6] Туристический бизнес [Электронный ресурс]. — Электронные данные. — Режим доступа: http://tourfaq.net/travel-business/osnovnye-principy-organizacii-vezdnogo-turizma/.
[7] Википедия [Электронный ресурс]. — Электронные данные. — Режим доступа: http://ru.wikipedia.org/wiki.
[8]http://pravo.levonevsky.org/bazaby/zakon/zakb0739.htm — закон
[9] Основные понятия IDEF0 [Электронный ресурс]. — Электронные данные. — Режим доступа: http://www.kgau.ru/istiki/umk/mbp/ch08s05.html.
ПРИЛОЖЕНИЯ
Приложение А
Рисунок A.1 — Физическая модель базы данных
Приложение Б
Диаграмма последовательности процесса авторизации пользователя
Рисунок Б1 — Диаграмма последовательности
Приложение В
Диаграммы классов
Рисунок В.1 -Пакет by.piulskaya.entity
Приложение Г
Диаграмма состояний для туристического объекта
Рисунок Г.1 — Диаграмма состояний
Приложение Д
Диаграмма компонентов разработанного сервера
Рисунок Д.1 — Диаграмма компонентов
Приложение Е
Диаграмма развертывания
Рисунок Е.1 — Диаграмма развертывания
Приложение И
Листинг скрипта генерации базы данных «TripStoreDB»
CREATE SCHEMA IF NOT EXISTS `tripstoredb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
USE `tripstoredb` ;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`DateTime` (
`idDateTime` DATETIME NOT NULL,
`day` INT NULL,
`month` INT NULL,
`year` INT NULL,
`hour` INT NULL,
`minutes` INT NULL,
PRIMARY KEY (`idDateTime`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`lang` (
`idlang` INT NOT NULL AUTO_INCREMENT,
`langname` VARCHAR (45) NOT NULL,
PRIMARY KEY (`idlang`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Country` (
`idCountry` INT NOT NULL AUTO_INCREMENT,
`countryName` VARCHAR (100) NULL,
`lang` INT NOT NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idCountry`),
INDEX `fk_Country_lang1_idx` (`lang_idlang` ASC),
CONSTRAINT `fk_Country_lang1`
FOREIGN KEY (`lang_idlang`)
REFERENCES `tripstoredb`.`lang` (`idlang`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Region` (
`idRegion` INT NOT NULL AUTO_INCREMENT,
`country` INT NOT NULL,
`region_name` VARCHAR (255) NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idRegion`),
INDEX `fk_Region_Country1_idx` (`country` ASC),
INDEX `fk_Region_lang1_idx` (`lang_idlang` ASC),
CONSTRAINT `fk_Region_Country1`
FOREIGN KEY (`country`)
REFERENCES `tripstoredb`.`Country` (`idCountry`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Region_lang1`
FOREIGN KEY (`lang_idlang`)
REFERENCES `tripstoredb`.`lang` (`idlang`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`City` (
`idCity` INT NOT NULL AUTO_INCREMENT,
`cityName` VARCHAR (255) NULL,
`Region_idRegion` INT NOT NULL,
`Country_idCountry` INT NOT NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idCity`),
INDEX `fk_City_Region1_idx` (`Region_idRegion` ASC),
INDEX `fk_City_Country1_idx` (`Country_idCountry` ASC),
INDEX `fk_City_lang1_idx` (`lang_idlang` ASC),
CONSTRAINT `fk_City_Region1`
FOREIGN KEY (`Region_idRegion`)
REFERENCES `tripstoredb`.`Region` (`idRegion`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_City_Country1`
FOREIGN KEY (`Country_idCountry`)
REFERENCES `tripstoredb`.`Country` (`idCountry`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_City_lang1`
FOREIGN KEY (`lang_idlang`)
REFERENCES `tripstoredb`.`lang` (`idlang`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Address` (
`idAddress` INT NOT NULL AUTO_INCREMENT,
`street` VARCHAR (255) NOT NULL,
`house` INT NULL,
`locX` INT NULL,
`locY` INT NULL,
`floor` INT NULL,
`office` INT NULL,
`index` INT NULL,
`City_idCity` INT NOT NULL,
PRIMARY KEY (`idAddress`),
INDEX `fk_Address_City1_idx` (`City_idCity` ASC),
CONSTRAINT `fk_Address_City1`
FOREIGN KEY (`City_idCity`)
REFERENCES `tripstoredb`.`City` (`idCity`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Place` (
`idPlace` INT NOT NULL AUTO_INCREMENT,
`` VARCHAR (45) NULL,
`Address_idAddress` INT NOT NULL,
`description_iddescription` INT NOT NULL,
`title_idtitle` INT NOT NULL,
PRIMARY KEY (`idPlace`),
INDEX `fk_Place_Address1_idx` (`Address_idAddress` ASC),
CONSTRAINT `fk_Place_Address1`
FOREIGN KEY (`Address_idAddress`)
REFERENCES `tripstoredb`.`Address` (`idAddress`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Category` (
`idCategory` INT NOT NULL AUTO_INCREMENT,
`categoryName` VARCHAR (50) NOT NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idCategory`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Category_has_Place` (
`Category_idCategory` INT NOT NULL,
`Place_idPlace` INT NOT NULL,
PRIMARY KEY (`Category_idCategory`, `Place_idPlace`),
INDEX `fk_Category_has_Place_Place1_idx` (`Place_idPlace` ASC),
INDEX `fk_Category_has_Place_Category1_idx` (`Category_idCategory` ASC),
CONSTRAINT `fk_Category_has_Place_Category1`
FOREIGN KEY (`Category_idCategory`)
REFERENCES `tripstoredb`.`Category` (`idCategory`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Category_has_Place_Place1`
FOREIGN KEY (`Place_idPlace`)
REFERENCES `tripstoredb`.`Place` (`idPlace`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`currency` (
`idcurrency` INT NOT NULL AUTO_INCREMENT,
`currencyname` VARCHAR (45) NULL,
`convercion` DOUBLE NULL,
PRIMARY KEY (`idcurrency`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`price` (
`idprice` INT NOT NULL AUTO_INCREMENT,
`price_person` INT NOT NULL,
`price_child` INT NULL,
`notes` TINYTEXT NULL,
`currency_idcurrency` INT NOT NULL,
PRIMARY KEY (`idprice`),
INDEX `fk_price_currency1_idx` (`currency_idcurrency` ASC),
CONSTRAINT `fk_price_currency1`
FOREIGN KEY (`currency_idcurrency`)
REFERENCES `tripstoredb`.`currency` (`idcurrency`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`tour` (
`idtour` INT NOT NULL AUTO_INCREMENT,
`duration` INT NOT NULL,
`start_time` DATETIME NOT NULL,
`end_time` DATETIME NOT NULL,
`title_idtitle` INT NOT NULL,
`description_iddescription` INT NOT NULL,
`price_idprice` INT NOT NULL,
PRIMARY KEY (`idtour`),
INDEX `fk_tour_DateTime1_idx` (`start_time` ASC),
INDEX `fk_tour_DateTime2_idx` (`end_time` ASC),
INDEX `fk_tour_price1_idx` (`price_idprice` ASC),
CONSTRAINT `fk_tour_DateTime1`
FOREIGN KEY (`start_time`)
REFERENCES `tripstoredb`.`DateTime` (`idDateTime`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tour_DateTime2`
FOREIGN KEY (`end_time`)
REFERENCES `tripstoredb`.`DateTime` (`idDateTime`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tour_price1`
FOREIGN KEY (`price_idprice`)
REFERENCES `tripstoredb`.`price` (`idprice`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`CheckPoint` (
`idCheckPoint` INT NOT NULL AUTO_INCREMENT,
`CheckPointNum` INT NOT NULL,
`tour_idtour` INT NOT NULL,
PRIMARY KEY (`idCheckPoint`),
INDEX `fk_CheckPoint_tour1_idx` (`tour_idtour` ASC),
CONSTRAINT `fk_CheckPoint_tour1`
FOREIGN KEY (`tour_idtour`)
REFERENCES `tripstoredb`.`tour` (`idtour`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`TourFirm` (
`idTourOperator` INT NOT NULL,
`tourFirmName` VARCHAR (45) NOT NULL,
`email` VARCHAR (255) NULL,
PRIMARY KEY (`idTourOperator`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`user` (
`iduser` INT NOT NULL AUTO_INCREMENT,
`email` VARCHAR (255) NOT NULL,
`usercol` VARCHAR (45) NULL,
`fio` LONGTEXT NOT NULL,
PRIMARY KEY (`iduser`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`request` (
`idRequest` INT NOT NULL AUTO_INCREMENT,
`email` VARCHAR (255) NOT NULL,
`tour_idtour` INT NOT NULL,
`reqtime` DATETIME NOT NULL,
`user_iduser` INT NOT NULL,
PRIMARY KEY (`idRequest`),
INDEX `fk_Request_tour1_idx` (`tour_idtour` ASC),
INDEX `fk_request_DateTime1_idx` (`reqtime` ASC),
INDEX `fk_request_user1_idx` (`user_iduser` ASC),
CONSTRAINT `fk_Request_tour1`
FOREIGN KEY (`tour_idtour`)
REFERENCES `tripstoredb`.`tour` (`idtour`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_request_DateTime1`
FOREIGN KEY (`reqtime`)
REFERENCES `tripstoredb`.`DateTime` (`idDateTime`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_request_user1`
FOREIGN KEY (`user_iduser`)
REFERENCES `tripstoredb`.`user` (`iduser`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`tourType` (
`idtourType` INT NOT NULL AUTO_INCREMENT,
`typeName` VARCHAR (45) NOT NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idtourType`, `typeName`))
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`tour_has_tourType` (
`tour_idtour` INT NOT NULL,
`tourType_idtourType` INT NOT NULL,
`tourType_typeName` VARCHAR (45) NOT NULL,
PRIMARY KEY (`tour_idtour`, `tourType_idtourType`, `tourType_typeName`),
INDEX `fk_tour_has_tourType_tourType1_idx` (`tourType_idtourType` ASC, `tourType_typeName` ASC),
INDEX `fk_tour_has_tourType_tour1_idx` (`tour_idtour` ASC),
CONSTRAINT `fk_tour_has_tourType_tour1`
FOREIGN KEY (`tour_idtour`)
REFERENCES `tripstoredb`.`tour` (`idtour`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tour_has_tourType_tourType1`
FOREIGN KEY (`tourType_idtourType`, `tourType_typeName`)
REFERENCES `tripstoredb`.`tourType` (`idtourType`, `typeName`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`GroupPrice` (
`idGroupPrices` INT NOT NULL AUTO_INCREMENT,
`num1` INT NULL,
`num2` INT NULL,
`price_idprice` INT NOT NULL,
PRIMARY KEY (`idGroupPrices`),
INDEX `fk_GroupPrices_price1_idx` (`price_idprice` ASC),
CONSTRAINT `fk_GroupPrices_price1`
FOREIGN KEY (`price_idprice`)
REFERENCES `tripstoredb`.`price` (`idprice`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`InPrice` (
`idInPrice` INT NOT NULL AUTO_INCREMENT,
`includeText` TINYTEXT NULL,
`price_idprice` INT NOT NULL,
PRIMARY KEY (`idInPrice`),
INDEX `fk_InPrice_price1_idx` (`price_idprice` ASC),
CONSTRAINT `fk_InPrice_price1`
FOREIGN KEY (`price_idprice`)
REFERENCES `tripstoredb`.`price` (`idprice`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`touragent` (
`idtouragent` INT NOT NULL AUTO_INCREMENT,
`TourFirm_idTourOperator` INT NOT NULL,
PRIMARY KEY (`idtouragent`),
INDEX `fk_touragent_TourFirm1_idx` (`TourFirm_idTourOperator` ASC),
CONSTRAINT `fk_touragent_TourFirm1`
FOREIGN KEY (`TourFirm_idTourOperator`)
REFERENCES `tripstoredb`.`TourFirm` (`idTourOperator`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Document` (
`idDocument` INT NOT NULL AUTO_INCREMENT,
`docName` VARCHAR (45) NOT NULL,
`touragent_idtouragent` INT NOT NULL,
PRIMARY KEY (`idDocument`),
INDEX `fk_Document_touragent1_idx` (`touragent_idtouragent` ASC),
CONSTRAINT `fk_Document_touragent1`
FOREIGN KEY (`touragent_idtouragent`)
REFERENCES `tripstoredb`.`touragent` (`idtouragent`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`agreement` (
`idagreement` INT NOT NULL AUTO_INCREMENT,
`docnumber` INT NOT NULL,
`user_iduser` INT NOT NULL,
`touragent_idtouragent` INT NOT NULL,
PRIMARY KEY (`idagreement`),
INDEX `fk_agreement_user1_idx` (`user_iduser` ASC),
INDEX `fk_agreement_touragent1_idx` (`touragent_idtouragent` ASC),
CONSTRAINT `fk_agreement_user1`
FOREIGN KEY (`user_iduser`)
REFERENCES `tripstoredb`.`user` (`iduser`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_agreement_touragent1`
FOREIGN KEY (`touragent_idtouragent`)
REFERENCES `tripstoredb`.`touragent` (`idtouragent`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`message` (
`idmessage` INT NOT NULL AUTO_INCREMENT,
`messagetext` LONGTEXT NOT NULL,
`messagetheme` VARCHAR (45) NOT NULL,
`user_iduser` INT NOT NULL,
`touragent_idtouragent` INT NOT NULL,
PRIMARY KEY (`idmessage`),
INDEX `fk_message_user1_idx` (`user_iduser` ASC),
INDEX `fk_message_touragent1_idx` (`touragent_idtouragent` ASC),
CONSTRAINT `fk_message_user1`
FOREIGN KEY (`user_iduser`)
REFERENCES `tripstoredb`.`user` (`iduser`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_message_touragent1`
FOREIGN KEY (`touragent_idtouragent`)
REFERENCES `tripstoredb`.`touragent` (`idtouragent`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`requisites` (
`idrequisites` INT NOT NULL AUTO_INCREMENT,
`requisitescol` VARCHAR (45) NULL,
`touragent_idtouragent` INT NOT NULL,
PRIMARY KEY (`idrequisites`),
INDEX `fk_requisites_touragent1_idx` (`touragent_idtouragent` ASC),
CONSTRAINT `fk_requisites_touragent1`
FOREIGN KEY (`touragent_idtouragent`)
REFERENCES `tripstoredb`.`touragent` (`idtouragent`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`street` (
`idstreet` INT NOT NULL AUTO_INCREMENT,
`streetname` VARCHAR (45) NOT NULL,
`Address_idAddress` INT NOT NULL,
`lang_idlang` INT NOT NULL,
PRIMARY KEY (`idstreet`),
INDEX `fk_street_Address1_idx` (`Address_idAddress` ASC),
INDEX `fk_street_lang1_idx` (`lang_idlang` ASC),
CONSTRAINT `fk_street_Address1`
FOREIGN KEY (`Address_idAddress`)
REFERENCES `tripstoredb`.`Address` (`idAddress`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_street_lang1`
FOREIGN KEY (`lang_idlang`)
REFERENCES `tripstoredb`.`lang` (`idlang`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `tripstoredb`.`Place_has_CheckPoint` (
`Place_idPlace` INT NOT NULL,
`CheckPoint_idCheckPoint` INT NOT NULL,
PRIMARY KEY (`Place_idPlace`, `CheckPoint_idCheckPoint`),
INDEX `fk_Place_has_CheckPoint_CheckPoint1_idx` (`CheckPoint_idCheckPoint` ASC),
INDEX `fk_Place_has_CheckPoint_Place1_idx` (`Place_idPlace` ASC),
CONSTRAINT `fk_Place_has_CheckPoint_Place1`
FOREIGN KEY (`Place_idPlace`)
REFERENCES `tripstoredb`.`Place` (`idPlace`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Place_has_CheckPoint_CheckPoint1`
FOREIGN KEY (`CheckPoint_idCheckPoint`)
REFERENCES `tripstoredb`.`CheckPoint` (`idCheckPoint`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;