Размещено на http://www.allbest.ru/

Содержание

• 1. Описание предметной области
• 2. Описание процесса бронирования билетов
• 3. Концептуальное и физическое проектирование базы данных
• 4. Целостность данных
• 5. Безопасность
• 6. Проектирование логики диалога с пользователем
• 7. Алгоритмы обработки данных, используемые в приложении для бронирования билетов в кинотеатр
• 8. Разработка и описание приложения
• Заключение
• Список литературы

1. Описание предметной области

Каждый кинотеатр имеет свою систему залов и расположения мест в них. Залы обладают следующими характеристиками:

· Количество рядов

· Количество мест в каждом из рядов

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

· Свободно

· Забронировано

· Куплено

· Не обслуживается

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

· Название фильма

· Дата сеанса

· Время сеанса

· Количество билетов

· Номер ряда (рядов)

· Номер мест (а)

· Фамилия (или иное кодовое слово)

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

приложение пользователь база бронирование

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

2. Описание процесса бронирования билетов

Семантическое описание данной предметной области произведено посредством построения IDEF0-модели в системе Ramus Educational. Основное назначение построенной модели состоит в представлении информации для обоснования выбора модели и структуры данных, используемых в созданной информационной системе. Методология IDEF0 предназначена для описания существующих бизнес-процессов или информационных потоков (в данном случае) с использованием, как естественного языка, так и графических изображений. Методология описания бизнес-процессов IDEF0 наиболее широко используемая. В ней рассматриваются логические отношения между работами.

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

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

Входными данными системы будет являться только желание человека сходить в кинотеатр. Все данные о билете будут появляться по ходу бронирования.

Результатом системы - выходом - будет служить сама бронь на фильм.

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

Рисунок 1 - Контекстная диаграмма "Бронирование билетов в кинотеатр"

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

Рисунок 2 - диаграмма декомпозиции А0

Данная диаграмма описывает следующие процессы:

· Ввод необходимой для бронирования информации

· Подтверждение бронирования

· Передача данных на сервер

· Получение пользователем брони на билет

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

Рассмотрим детализацию процесса А1 "Ввод необходимой для бронирования информации", представленную на рисунке 3.

Рисунок 3 - диаграмма декомпозиции А1

Данная диаграмма включает в себя следующие процессы:

· Выбор названия фильма. Фильм выбирается из предложенных и идущих в ближайший месяц в кинотеатре.

· Выбор даты сеанса. Дата сеанса зависит от выбора фильма - для каждого из них имеется информация о количестве дней в прокате.

· Выбор времени сеанса. На каждый из дней проката и на каждый фильм существует свое расписание сеансов.

· Выбор номера ряда и мест. Осуществляется проверка, не заняты ли выбранные места на конкретный сеанс.

· Ввод последних 4 цифр номера телефона. Эта информация нужна для подтверждения, что именно этот человек бронировал билет при оплате на кассе. Если данный пункт выполнен, клиенту подтверждается бронь на сеанс.

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

Таким образом, были рассмотрены основные бизнес-процессы, которые происходят при бронировании клиентом билета в кинотеатр, начиная от ввода информации, заканчивая подтверждением бронирования.

3. Концептуальное и физическое проектирование базы данных

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

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

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

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

Рисунок 4 - логический уровень концептуальной схемы

Данная предметная область представлена пятью сущностями:

"Клиент";

"Бронь";

"Зал";

"Фильм";

"Место";

"Сеанс";

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

Сущность "Клиент" содержит всю необходимую информацию о клиенте (организации), который бронирует билеты в кинотеатр. Является независимой от других сущностей, не содержит мигрирующих атрибутов. Включает в себя "ID_клиента" (первичный ключ и однозначно идентифицирует данную сущность), "ФИО" и "Номер телефона".

Сущность "Бронь" определяет характеристики конкретной брони. Она содержит два атрибута брони:

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

- "4 цифры номера телефона". Параметр, по которому кассир в кинотеатре может удостовериться, какой клиент забронировал конкретные места.

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

- "ID места" - суррогатный ключ сущности.

- "Номер зала"

- "Название фильма"

- "Время сеанса".

- "Дата сеанса".

Сущность "Место" связана с сущностью "Бронь", потому что для бронирования билета обязателен выбор хотя бы одного места в зале. Сущность "место" характеризуется такими атрибутами, как:

- "Состояние" (возможны состояния "выбрано", "занято", "свободно");

- "Номер ряда"

- "Номер места"

- "Номер зала".

В кинотеатре имеются несколько залов, и в каждом имеется разное количество рядов и мест в них.

Сущность "Зал" характеризует данные о зале, в котором происходят сеансы. Он включает в себя следующие атрибуты:

- "Номер зала". Является первичным ключом и однозначно идентифицирует данную сущность;

- "Количество рядов зале"

- "Количество мест в рядах"

Предполагается, что зал имеет прямоугольную форму.

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

- "Название фильма". Является первичным ключом и однозначно идентифицирует данную сущность;

- "Дата начала проката"

- "Дата окончания проката"

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

- Название фильма (внешний ключ из сущности "Фильм")

- Время сеанса

- Дата сеанса

Также имеется еще один внешний ключ - "Номер зала".

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

На один сеанс клиенты могут забронировать количество билетов, ограниченное только их количеством в зале, но одна бронь создается только для одного сеанса. Этим объясняется неидентифицирующая связь между сущностями "Бронь" и "Сеанс".

Аналогично связаны сущности "Зал" и "Сеанс". Так как в одном зале происходит много сеансов, но один сеанс сразу в нескольких залах происходить не может, между ними неидентифицирующая связь "один ко многим", где ключ из сущности "Зал" мигрирует в сущность "Сеанс".

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

Идентифицирующая связь "один ко многим" существует между сущностями "Фильм" и "Сеанс", так как название фильма является одной из частей первичного ключа сущности "Сеанс", а также между сущностями "Зал" и "Место", так как номер зала определяет количество мест в нем.

Рисунок 5 - физический уровень концептуальной модели

После выбора конкретной СУБД логическая схема БД переводится в физическую уже в терминах конкретной СУБД. Для данной курсовой работы была выбрана СУБД ibExpert

Физическая схема созданной в рамках курсовой работы базы данных представлена на Рисунке.

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

4. Целостность данных

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

В стандарте SQL есть специальные элементы для поддержания целостности БД (представления, хранимые процедуры, триггеры).

Также существуют ограничения целостности для базы данных - это правила, которые задаются для двух или более связанных таблиц. Чаще всего используется ограничение ссылочной целостности. Существует три стратегии поддержки ссылочной целостности: cascade, restrict, set null.

Для данной предметной области использование этих стратегий не является необходимым, для определенных связей и действий были использованы все три стратегии. Во всех случаях используется стратегия restrict. Использование set null не имеет смысла, так как все атрибуты сущностей не могут быть пустыми (not null).

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

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

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

5. Безопасность

В современных СУБД поддерживается один из двух широко распространенных подходов к вопросу обеспечения безопасности данных, а именно избирательный подход или обязательный подход.

В данной курсовой работе было выбрано избирательное управление. В общем случае система безопасности таких СУБД базируется на трех компонентах:

1. Пользователи. СУБД выполняет любое действия с БД от имени какого-то пользователя. Каждому пользователю присваивается идентификатор - порядковый номер, однозначно определяющий пользователя в СУБД. Он определяется с помощью триггера.

2. Объекты БД. По стандарту SQL2 защищаемыми объектами в БД являются таблицы, представления, домены и определенные пользователем наборы символов.

3. Привилегии.

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

Для обеспечения безопасной работы с данными в данной системе на уровне СУБД были созданы два пользователя системы:

Клиент (booker), который имеет право бронировать билет в кинотеатр

Администратор (admin), который контролирует данные в базе данных кинотеатра

Каждый из данных пользователей имеет права не на все таблицы базы данных, а только на выполнение определенных действий в конкретных таблицах. Так, пользователь "booker" имеет права на просмотр таблиц "Залы", "Сеансы" и "Фильмы", добавление и модификацию таблицы "Брони".

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

6. Проектирование логики диалога с пользователем

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

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

Размещено на http://www.allbest.ru/

Рисунок 6 - транзитивная сеть логики диалога с пользователем

S0 - начальное состояние, форма для входа в систему.

S1 - вход в систему под именем client. Доступно бронирование билетов и изменение имеющейся брони.

S2 - вход в систему под именем admin.

S3 - окно "Бронирование билетов".

S4 - окно "Изменение данных об имеющейся брони".

S5 - окно с номером брони.

S6 - проверка введенных данных о брони для изменения (номер и 4 цифры телефона) на корректность.

S7 - переход в состояние S3. Данные не могут быть модифицированы.

S8 - данные могут быть модифицированы.

S9 - просмотр поля из таблицы "Брони" с возможностью модификации.

1 - Подсеть добавления в базу новой брони

2 - Выбор вкладки "Забронировать места"

3 - Доступны для выбора из баз поля ввода данных о брони

4 - Нажатие кнопки "Добавить бронь"

5 - Выдача пользователю номера брони

6 - Выбор вкладки "Изменение данных о существующей брони"

7 - Ввод номера брони

8 - Номер брони имеется в базе и она не снята

9 - Номер брони не имеется в базе или она снята

10 - Вывод сообщения "Брони не существует"

11 - Показать данные из таблицы с возможностью изменения

12 - Нажатие кнопки "ОК", выполнение запроса на изменение данных о брони.

Размещено на http://www.allbest.ru/

Рисунок 7 - транзитивная подсеть добавления в базу новой брони

14 - Выбор фильма из имеющихся в прокате

15 - Выбор даты из предложенных

16 - Выбор времени по дате

17 - Выбор свободных мест на схеме зала

S10 - Показан выпадающий список фильмов, которые есть в прокате

S11 - Показан выпадающий список дат, в который идет этот фильм

S12 - Показан список времени начала сеансов в выбранный день

S13 - Показана схема зала на сеанс в выбранное время

S14 - Пользователем выбраны места в зале

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

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

При выборке общей информации о сеансах в базу данных отправляется запрос типа "Select * from <имя_таблицы>" к соответствующей таблице "Сеансы"

При добавлении новой записи о брони в базу данных отправляется запрос типа "Insert into <имя_таблицы> (список параметров)", на вставку новой строки в соответствующую таблицу, параметры для которого берутся из заполняемых полей соответствующей формы.

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

При изменении записи в базу данных отправляется запрос типа "Update <имя_таблицы> set <изменяемые параметры> where <условие>", где обязательно уточняется номер брони и 4 цифры номера телефона, а параметры изменяемые добавляются в запрос из полей для ввода данных или списков, из которых их можно выбрать.

8. Разработка и описание приложения

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

Приведем краткое описание разработанного приложения.

При запуске приложения осуществляется вход под стандартным пользователем выбранной СУБД - SYSDBA. Это позволяет производить все требуемые операции над базой данных. После запуска приложения клиент получает возможность начать процесс бронирования. Форма для выбора данных приведена на рисунке 9.

Рисунок 9 - форма для выбора данных

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

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

Заключение

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

Были выполнены все заданные этапы проектирования информационной системы. Значит, поставленная цель курсовой работы достигнута, задачи были выполнены.

Список литературы

1. Маркин, А.В. Построение запросов и программирование на SQL [Текст]: Учебное пособие / А.В. Маркин - Рязань: РГРТУ, 2008. - 312с. - ISBN 978-5-7722-0285-2.

2. Архангельский, А.Я. Delphi7 [Текст]: Справочное пособие / А.Я. Архангельский - М.: ООО "Бином-Пресс", 2003. - 1024с.: ил. - ISBN 5-9518-0027-7

3. Клайв К. SQL [Текст]: Справочник / К. Клайв, Д. Клайв, Б. Хант - М.: "Кудиц-Образ", 2006. - 832с. - ISBN 5-9579-0114-8, ISBN 5-596-00481-8.

4. Дейт К., Руководство по реляционной СУБД DB2 [Текст] / Когаловский М.Р. - М.: "Финансы и статистика", 1988 - 320c. - ISBN 5-279-0063-9 (в пер.).

5. Селко, Дж. Программирование на SQL для профессионалов [Текст] / Дж. Селко - М.: "Лори", 2004 - 442с. - ISBN 5-85829-219-2.

Размещено на Allbest.ru