Файл: Разработка сайта кинотеатра «Дружба».pdf

Введение

На сегодняшний день индустрия развлечений является одной из тех сфер деятельности, конкуренция в которой как никогда высока.

В связи с этим, для того, чтобы остаться на плаву в данном бизнесе все его элементы должны быть безупречны с точки зрения потенциального клиента, а требования у современных посетителей развлекательных мероприятий касаются не только качества самого зрелища, но и всех сопутствующих организации посещения мероприятия действий. Следовательно, для того, чтобы не упустить потенциальных клиентов, необходимо обеспечить их комфорт как на самом мероприятии, так и на всех этапах подготовки.

Очевидно, что большинство современных людей получает информацию о любых видах услуг из интернета, поэтому сайт организации, являющийся визитной карточкой компании в интернете, должен отвечать всем последним требованиям к представительству организации в интернете, то есть быть приятным для глаз, удобным для использования, своевременно обновляемым и информативным. Достичь этого можно только с использованием динамической структуры сайта, так как ежедневное обновление множества страниц статического сайта будет занимать слишком много времени у того, кто занимается рутинной поддержкой сайта и обновлением информации на нем.

Целью данной работы является разработка сайта кинотеатра.

Для достижения данной цели необходимо решить следующие задачи:

• провести анализ структуры организации, для которой разрабатывается сайт,
• определить основные бизнес-процессы, которые должны быть оптимизированы с помощью данного сайта,
• выбрать средства разработки всех частей сайта,
• разработать серверную часть приложения,
• разработать базу данных,
• разработать клиентскую часть приложения.

1. Техническое задание и выбор средств реализации

1.1. Техническое задание

Требуется разработать сайт для кинотеатра, который будет отвечать следующим требованиям.

Сайт должен состоять из трех основных частей [1]:

• серверная часть,
• база данных,
• клиентская часть.

База данных должна хранить всю информацию, которая необходима для полноценного представления организации во всемирной сети, освещения информации о технических возможностях кинотеатра, планируемых мероприятиях, бронирования билетов на мероприятия [2].

Клиентская часть должна предоставлять пользователю возможность удобного просмотра информации из базы данных в виде набора страниц с интуитивно понятной навигацией, а также быстрого бронирования билетов, а администратору – возможность обновления информации путем внесения изменений в базу данных [3].

Серверная часть должна обеспечивать взаимодействие базы данных и клиентской части [4].

В структуре сайта должны быть предусмотрены два вида зарегистрированных пользователей:

• обычный пользователь,
• администратор.

Администратору должен быть доступен следующий функционал:

• добавление информации в базу данных,
• редактирование информации в базе данных,
• удаление информации из базы данных.
• Обычному пользователю должно быть доступно бронирование билетов.

Основная информация должна быть доступна без регистрации.

1.2. Обоснование выбора модели данных

В связи с тем, что база данных играет ключевую роль в создании сайта, необходимо ответственно отнестись к используемой модели данных.

Модель данных – это способ изображения предметной области в структуре данных [5].

На данный момент существуют несколько даталогических моделей данных: иерархическая, сетевая

Иерархическая модель подходит для построения баз данных с древовидной структурой, которые относятся к старейшему поколению баз данных.

Достоинства:

• просто описывать иерархические структуры, существующие в реальном мире
• высокая скорость выполнения запросов, соответствующих структуре данных

Недостатки:

• часто содержат избыточные данные
• плохо приспособлены для представления взаимосвязей типа "многие ко многим"
• неудобный для поиска способ перемещения по базе данных, всегда начинающийся с корня.

В отличие от иерархической модели сетевая модель поддерживает тип связи «многие ко многим». Однако, так как переход от записи к записи осуществляется по ссылкам, вставленным в каждую запись, то базы данных на основе такой модели довольно сложны и требовательны к программному обеспечению [6].

Объектно-ориентированная модель состоит из объектов, их атрибутов, методов и классов [7].

Она рекомендована для таких применений, в которых необходима высокая производительность обработки данных, а сами данные имеют сложную структуру.

На нынешний момент наибольшее распространение получила реляционная модель, в которой данные представлены в виде двумерных таблиц, состоящих из строк и столбцов. Каждой таблице в базе данных присвоено уникальное имя [8].

Каждая таблица соответствует одной сущности, а каждая строка таблицы – одному экземпляру сущности. Каждому столбцу присваивается уникальное для данной таблицы имя.

Порядок следования столбцов такой же, как и порядок следования их имен при создании таблицы. Строки же не имеют имен и определенного порядка следования.

Для каждой таблицы назначен уникальный первичный ключ, который является один из столбцов или совокупностью нескольких столбцов, которые однозначно определяют каждую строку таблицы.

Достоинствами данной модели являются простота и гибкость.

Для реализации базы данных в данной работе была выбрана реляционная модель.

В качестве системы управления базами данных выбрана MySQL, так как она является одной из самых распространенных, надежных и удобных в обслуживании [9].

В качестве серверного языка был выбран PHP, так как он легко интегрируется с сервером MySQL [10].

Для клиентской части сайта выбраны стандартные средства разработки для таких объектов: язык разметки HTML, стили CSS и язык программирования JavaScript [11].

2. Описание модулей серверной части программы и их взаимодействие

Как было указано в предыдущем разделе, основной функцией серверной части является осуществление взаимодействия между клиентской частью и базой данных.

Следовательно, основными функциями, выполняемыми модулями серверной части будут следующие действия с базой данных:

• запрос информации из базы данных и формирование содержимого страниц на основе полученных ответов,
• добавление/редактирование/удаление информации в базе данных,
• проверка соответствия информации введенной пользователем информации, хранящейся в базе данных.

Для каждого из описанных действий разработан отдельный модуль.

Модуль управления данными отвечает за добавление/редактирование/удаление информации в/из базы данных. Использование данного модуля предполагается в основном в интерфейсе администратора и обычного пользователя. В интерфейсе администратора для работы с каждой таблицей предусмотрены три скрипта: один для добавления данных в таблицу, один для редактирования данных в таблице, один для удаления данных из таблицы. В интерфейсе обычного пользователя предусмотрен один скрипт для осуществления изменений в базе данных, связанных с бронированием билетов.

Модуль представления информации отвечает за запрос информации из базы данных и формирование динамического содержания страниц сайта. Данный модуль используется при любом посещении сайта. Он позволяет своевременно отображать изменения текущей информации на страницах сайта. Скрипты, содержащиеся в данном модуле, запрашивают информацию из базы данных, соответствующую определенным критериям, а затем выводят её на страницы сайта.

Модуль проверки информации отвечает за авторизацию пользователей. Для авторизации пользователей используются два скрипта, каждый из которых проверяет информацию на соответствие определенной группе пользователей, а затем при прохождении проверки переадресует пользователя на страницу соответствующего ему интерфейса.

Примеры скриптов представлены в Приложении 1 [12-15].

3. Описание структуры базы данных и ее функций

3.1 Разработка инфологической модели

Под разработкой инфологической модели подразумевается построение независимой от СУБД информационной структуры путем объединения информационных требований всех предполагаемых пользователей системы [16].

Для создания инфологической модели данных необходимо определить сущности, их атрибуты и связи между ними.

Сущности:

1. Пользователи
2. Фильмы
3. Сеансы
4. Залы
5. Бронирование
6. Отзывы
7. Клубные карты

Атрибуты сущностей представлены в таблице 1.

Таблица 1

Атрибуты сущностей

Связи между описанными сущностями представлены в таблице 2.

Таблица 2

Связи между сущностями

Связь «осуществляет» представляет собой связь типа «один ко многим», то есть, если пользователь осуществляет бронирование, то одному бронированию соответствует только один пользователь, в то же время, один пользователь может осуществлять несколько бронирований.

Связь «соответствует» также относится к типу «один ко многим»: одной клубной карте или одному сеансу может соответствовать несколько бронирований, но в одном бронировании всегда указан один сеанс и одна клубная карта, а одному сеансу всегда соответствует один фильм, в то время как один и тот же фильм демонстрируют во время многих сеансов.

К этому же типу относится и связь «получает», так как в один фильм получает много отзывов, но каждый отзыв посвящен только одному фильму.

Связь «проходит в» является последним представителем связи типа «один ко многим», что означает, что один сеанс проходит в одном зале, но в одном и том же зале может проходить не один сеанс.

На основе приведенных выше данных построена «ER - диаграмма» [17], которая представлена на рисунке 1.

3.2 Даталогическое проектирование

Даталогическое проектирование состоит в создании схемы базы данных на основе конкретной, в нашем случае, реляционной, модели данных. Для реляционной модели данных даталогическая модель – это набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.