Файл: «Автоматизация продажи театральных билетов».pdf

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

Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности [8].

Атрибут сущности − это именованная характеристика, являющаяся некоторым свойством сущности. Например сущность «Билет» содержит следующие атрибуты: место, цена, дата продажи, продан (логическое да или нет), бронь (логическое да или нет).

Сущность «Театр» содержит другие атрибуты: название, адрес, директор, телефон, количество мест в партере, количество мест в амфитеатре, количество мест на балконе, вид театра.

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

К примеру, у сущности «Театр» ключом является idТеатра, сущность «Спектакль» имеет ключ idСпектакля, сущности «Билет» и «Жанр» − idБилет и idЖанр, и т.д.

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

Связь типа один-к-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две. В нашей ER-диаграмме данный тип связи отсутствует.

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

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

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

3. РАЗРАБОТКА ПРОЕКТА ИС С ПОМОЩЬЮ СТРУКТУРНОГО ПОДХОДА

3.1. Моделирование данных (с использованием IDEF0))

Рисунок 5. Диаграмма IDEF0

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

Потоки управления представлены законами РФ, нормативными документами. Механизмы: кассир. Входящие потоки: билеты на продажу, клиенты. Выходные потоки: Проданные билеты, не проданные билеты, сдача отчетности, прибыль [13].

Эту диаграмму можно декомпозировать. На рис. 5 представлена декомпозиция первого уровня методологии IDEF0. Представленная диаграмма содержит 4 блока.

3.2. Иерархия диаграмм

Рисунок 6. Иерархия диаграмм

Общей диаграммой является модель IDEF0. Остальные диаграммы уточняют и описывают предыдущие.

3.3. Спецификация процессов

Рисунок 7. Покупать/продавать билеты

Процесс начинается с получения в кассу билетов на продажу.

А0 (1) Процесс: получение билета на продажу.

Входной поток: билеты на продажу.

Выходной поток: готовые к продаже билеты.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

А0 (2) Процесс: работа с клиентами.

Входной поток: клиенты, готовые к продаже билеты.

Выходной поток: заключение сделки, уход клиента.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

А0 (3) Процесс: продажа билета.

Входной поток: заключение сделки.

Выходной поток: учет проданных билетов.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

А0 (4) Процесс: анализ деятельности.

Входной поток: учет проданных билетов.

Выходной поток: сдача отчетности.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

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

Все эти процессы можно декомпозировать.

Рисунок 8. Получение билетов на продажу

1.Процесс: оформление накладной на поступившие билеты.

Входной поток: билеты на продажу.

Выходной поток: подготовка ЭВМ к работе.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

2.Процесс: внесение билетов в базу данных.

Входной поток: подготовка ЭВМ к работе.

Выходной поток: учет билетов.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

3. Процесс: подготовка к продаже/вывешиванию афиш.

Входной поток: учет билетов.

Выходной билет: готовые к продаже билеты.

Механизмы: кассир.

Потоки управления представлены законами РФ, нормативными документами.

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

Рисунок 9. Процесс работы с клиентами

1. Процесс: Получение запроса от клиента.

Входной поток: билеты готовые к продаже и клиенты.

Выходной поток: обработка полученной информации.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

2. Процесс: обращение в БД.

Входной поток: обработка полученной информации.

Выходной поток: выдача информации.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

3. Процесс: информирование клиента.

Входной поток: выдача информации.

Выходной поток: срыв сделки, заключение сделки.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

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

Рисунок 10. Процесс продажи билетов

1. Процесс: получение информации от клиента.

Входной поток: клиенты и заключение сделки.

Выходной поток: покупка билета или требование брони.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

2. Процесс: бронирование.

Входной билет: требование брони.

Выходной поток: выкуп брони.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

3. Процесс: Продажа билетов.

Входной поток: покупка брони и выкуп брони.

Выходной поток: проданные билеты, не проданные билеты, прибыль.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

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

Потоки управления: БД, нормативные документы, законы РФ.

Рисунок 11. Процесс анализа деятельности

1.Процесс: обработка первичной информации.

Входной поток: проданные билеты, не проданные билеты и прибыль.

Выходной поток: систематизирование данных.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

2.Процесс: Подсчет прибыли.

Входной поток: систематизирование данных.

Выходной поток: сбор и анализ данных.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

3.Процесс: Составление отчетных документов.

Входной поток: сбор и анализ данных.

Выходной поток: сдача отчетности.

Механизм: кассир.

Потоки управления: БД, нормативные документы, законы РФ.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Абрамов Г.В. Проектирование информационных систем: учебное пособие. — Воронеж: Воронежский государственный университет инженерных технологий, 2017. — 172 c.
2. Абрамова Л.В. Инструментальные средства информационных систем: учебное пособие. - Архангельск: САФУ, 2013. - 118 с.
3. Акимова Е.В. Информационные системы и технологии в экономике и управлении. Проектирование информационных систем: учебное пособие. — Саратов: Вузовское образование, 2016. — 178 c.
4. Грекул В. И. Проектирование информационных систем. Курс лекций: учебное пособие. — Москва, Саратов: Интернет-Университет Информационных Технологий (ИНТУИТ), Вузовское образование, 2017. — 303 c.
5. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2013. - 331с.
6. Золотов С. Ю. Проектирование информационных систем: учебное пособие. — Томск: Томский государственный университет систем управления и радиоэлектроники, Эль Контент, 2016. — 88 c.
7. Крахоткина Е.В. Методы и средства проектирования информационных систем и технологий: учебное пособие. - Ставрополь: СКФУ, 2015. - 152 с.
8. Митина, О.А. Методы и средства проектирования информационных систем и технологий: курс лекций / О.А. Митина. - Москва: Альтаир: МГАВТ, 2016. - 76 с.
9. Платёнкин А.В. Проектирование информационных систем. Проектный практикум: учебное пособие. — Тамбов: Тамбовский государственный технический университет, 2018. — 80 c.