Описание состава автоматизируемых бизнес-процессов. Бизнес-процессы компании, подлежащие автоматизации, приведены в следующей таблице:

CASE-средства. 1) ОРГ-МАСТЕР. ОРГ-МАСТЕР является исключительно гибким продуктом, способным построить архитектурную модель компании любой сложности. Такая гибкость обеспечивается уникальным способом хранения информации и особым таблично-графическим интерфейсом. Комплекс был неоднократно представлен на международных конференциях по бизнес-моделированию и защищен авторским свидетельством.

До начала моделирования отдельных бизнес-процессов ОРГ-МАСТЕР позволяет построить общую модель деятельности компании, правильно выделить "систему процессов" и определить их взаимодействие. Построение системы процессов выполняется с использованием "нормативных моделей", что позволяет в ходе такого описания повысить уровень зрелости управления компанией

В комплексе ОРГ-МАСТЕР реализуется процессная интерпретация системы сбалансированных показателей, которая в несколько этапов транслирует стратегические требования, что позволяет сконцентрироваться на ключевых процессах.

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

Для ключевых процессов может быть проведено их детальное описание (входы и выходы каждой операции, управляющие документы, условия перехода, потоки информации и т.п.). ОРГ-Мастер поддерживает нотации IDEF0, DFD и ЛФС (логико-функциональные схемы). [1]

2) BPwin Process Modeler. BPwin это программный продукт, разработанный компанией ltd. Logic Works. Он предназначен для поддержки процесса создания информационных систем. Относится к категории CASE средств верхнего уровня. BPwin является достаточно развитым средством моделирования, позволяющим проводить анализ, документирование и улучшение бизнес процессов. С его помощью можно моделировать действия в процессах, определять их порядок и необходимые ресурсы. Модели BPwin создают структуру, необходимую для понимания бизнес процессов, выявления управляющих событий и порядка взаимодействия элементов процесса между собой.

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

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

Преимущества BPWIN:

В сравнении с другими CASE средствами этого уровня BPwin обладает следующим преимуществами:

· Простой графический интерфейс. Интерфейс BPwin легко воспринимается, позволяет выполнять настройки под пользователя, что упрощает процесс моделирования;

· Представление дополнительной информации. За счет применения UDP свойств (настраиваемые пользователем свойства) есть возможность собирать дополнительную информацию по процессам, представлять ее в моделях и включать в отчеты. Отчеты могут представляться в общедоступных форматах Microsoft Word или Microsoft Excel; [3]

3) Rational Rose. Сегодня лидирующей в мире CASE-системой считается Rational Rose корпорации Rational Software. Система Rational Rose нацелена на создание моделей с использованием языка Unified Modeling Language (UML). Можно сказать, что Rational Rose является графическим редактором UML диаграмм. [4] Своеобразным признанием заслуг Rational Software стало включение усеченного варианта продукта Rational Rose в знаменитый пакет разработчика Microsoft Visual Studio.

В последнее время для целей анализа деятельности предприятий все большее распространение получает средство моделирования Rational Rose. UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов.

Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых "бизнес-моделей", содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. Некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему; этим диаграммам не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой - просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые результаты деятельности первого, а может быть, наоборот, для работы первого процесса необходима некая информация, которую подготавливает второй? Точно также непонятно, как интерпретировать связи "процесс-состояние", "состояние-состояние" и др.

Поэтому Rational Rose допускает построение синтаксически корректных Activity-диаграмм, но не имеющих смысла с точки зрения моделируемого объекта.

По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию. Например, чтобы имитировать три вида характерных для IDEF0 входящих в процесс стрелок - input, mechanism, control, - можно каждую из них подкрашивать своим цветом, а для того, чтобы отличить входящие документы от исходящих, можно использовать пунктирные и сплошные стрелки. Другими словами, пользователь Rational Rose вынужден разрабатывать свои формализмы для получения методики построения моделей и анализа бизнес-процессов. При этом, возможно, придется не только разрабатывать свою методику, но и отклоняться от стандартов UML. [5]

Из вышесказанного следует один вывод: CASE-средства, реализованные на основе методологии IDEF0 и поддерживающие ее соглашения, уже только благодаря этому имеют неоспоримые и решающие преимущества перед Rational Rose. Аналогичную оценку преимущества перед Rational Rose можно дать и системам, поддерживающим методолгии IDEF3 и DFD. Поэтому при необходимости анализа бизнес-процессов следует выбирать CASE-средства, основанные на методологии IDEF0 или аналогичной. Таким продуктом является BPwin.

4) AllFusion ERwin Data Modeler. CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

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

AllFusion ERwin Data Modeler (ERwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда системы упрощает разработку базы данных и автоматизирует множество трудоёмких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Продукт улучшает коммуникацию организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате. [6]

Стандарты. 1) IDEF0. IDEF0 - Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. [7]

Методология основывается на следующих основных понятиях.

Диаграммы:

· контекстная;

· декомпозиции;

· дерева узлов.

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

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

Функциональный блок (Activity Box). Функциональный блок графически изображается в виде прямоугольника и представляет собой некоторую конкретную функцию в моделируемой системы. Название каждого функционального блока должно быть сформулировано в глагольном наклонении.

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

1. верхняя сторона имеет значение "Управление" (Control);

2. левая сторона имеет значение "Вход" (Input);

3. правая сторона имеет значение "Выход" (Output);

4. нижняя сторона имеет значение "Механизм исполнения" (Mechanism).

В IDEF0 различают 5 видов стрелок:

1. Вход(Input) - сырье, материал или информация, потребляемая или преобразуемая функциональным блоком.

2. Выход(Output) - продукция или информация, получаемая в результате работы функционального блока.

3. Управление(Control) - правила, инструкции, законы, наборы необходимых процедур и стандартов.

4. Механизм исполнения(Mechanism) - ресурс, который непосредственно исполняет моделируемое действие.

5. Вызов(Call) - специальная стрелка, указывающая на другую модель работы.

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Интерфейсная стрелка - интерфейсная дуга, поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. [8]

2) IDEF3. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3. Он предназначен для описания бизнес-процессов нижнего уровня и содержит объекты, которые показывают альтернативы и места принятия решений и в бизнес-процессе, а также временную последовательность работ в бизнес-процессе. [9]

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

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

Диаграмма IDEF3 Process Flow Description может состоять из 4 основных описательных блоков:

1. работы (boxes, activities);

2. объекты ссылок.

3. стрелки или связи (arrows, links);

4. перекрёстки (junctions);

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

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

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

3) DFD. Диаграммы потоков данных (Data flow diagram, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

Главная цель DFD - показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами.

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

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

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

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

Стрелки (потоки данных). Стрелки описывают движение объектов из одной части системы в другую (отсюда следует, что диаграмма DFD не может иметь граничных стрелок). Поскольку все стороны работы в DFD равнозначны, стрелки могут начинаться и заканчиваться на любой стороне прямоугольника. Стрелки могут быть двунаправлены. [11]

СУБД. 1) Oracle. Oracle занимает лидирующие позиции на рынке СУБД и, что особенно важно, лидирует на платформах Unix и Windows. В России также обозначилось лидерство Oracle, особенно в области крупномасштабных информационных систем государственных структур. Фактически в нашей стране СУБД Oracle стала стандартом для государственных информационных систем.

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

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

Унификация систем управления базами данных - один из наиболее значимых шагов на пути достижения этой цели. Ядром СУБД Oracle является сервер базы данных, который поставляется в одном из четырех вариантов в зависимости от масштаба информационной системы, в рамках которой предполагается его применение.

Для систем масштаба крупной организации предлагается продукт Oracle Database Enterprise Edition (корпоративная редакция), для которого имеется целый набор опций, архитектурно и функционально расширяющих возможности сервера.

Единственным недостатком данной СУБД является сложность администрирования, однако все затраты на ее внедрение и освоение в последствии окупятся эффективной и надежной работой. [12]

Таблица №1. Краткая характеристика Oracle Database

2) MySQL. MySQL - это реляционная система управления базами данных. То есть данные в ее базах хранятся в виде логически связанных между собой таблиц, доступ к которым осуществляется с помощью языка запросов SQL. MySQL - свободно распространяемая система, т.е. платить за ее применение не нужно. Кроме того, это достаточно быстрая, надежная и, главное, простая в использовании СУБД, вполне подходящая для не слишком глобальных проектов. Работать с MySQL можно не только в текстовом режиме, но и в графическом. Существует очень популярный визуальный интерфейс (кстати, написанный на PHP) для работы с этой СУБД. Называется он PhpMyAdmin. Этот интерфейс позволяет значительно упростить работу с базами данных в MySQL.

Большим достоинством MySQL является возможность работы с интерфейсом программного приложения API (Application Program Interface). API может обеспечить простой доступ из программы пользователя к СУБД. Пусть даже эти программы будут написаны на на Perl, C и т.д.

К основным плюсам MySQL можно отнести высокую скорость работы, быстроту обработки данных и оптимальную надежность. Немаловажно и то, что данная СУБД распространяется бесплатно и представляет собой программное обеспечение с открытым кодом. За счет этого Вы можете вносить свои изменения и модифицировать код, что весьма полезно для веб-мастеров. [13]

Таблица №2: Краткая характеристика MySQL

Embarcadero RAD Studio. RAD Studio^™ это самый быстрый способ для разработки нативных кросс-платформенных приложений с использованием облачных сервисов и широкого подключения IoT. Она предоставляет мощные компоненты VCL для Windows 10 и обеспечивает разработку на FMX для Windows, Mac и мобильных устройств. RAD Studio поддерживает Delphi или C++ с широким спектром услуг для корпоративно-ориентированного развития. Посмотрите на увеличенный объем памяти для крупных проектов, расширенную поддержку нескольких мониторов, улучшенный инспектор объектов и многое другое. RAD Studio обеспечивает 5-кратно увеличенную скорость разработки и развертывания на нескольких настольных, мобильных, облачных средах и платформах баз данных, включая 32-разрядные и 64-битные ОС Windows 10.

C++ Builder предоставляет C++ компилятор C для Windows 10 (32-разрядная и 64-разрядная версия) и мобильных платформ (IOS и Android) с расширениями RAD для самой быстрой Standard C++ Windows и кросс-платформенной разработки. Тесная интеграция с фрейморками VCL для Windows и кросс-платформенным FMX, поддержка языка С++11 и управления памятью для мобильных устройств на основе ARC (Автоматический подсчет ссылок), с обратной совместимостью. Это обновление необходимо для разработчиков C++Builder для Windows VCL или нового мобильного C++ и разработчиков настольных компьютеров, перешедших из других языков и наборов инструментов, таких как Java, Objective C, C #, XCode, Xamarin и Visual Studio.

Функциональные возможности существующих бизнес-приложений могут быть легко расширены для интеграции мобильных устройств, новых гаджеты IoT и различных фоновых служб, и баз данных. RAD Studio - это универсальная и самая полная IDE для IoT разработки. [14]

1.4 Разработка AS-IS бизнес-модели кинотеатра

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

Рисунок 1.2. Обобщенная схема организационного бизнес- моделирования

Миссия согласно [ISO-15704] - это:

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

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

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

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

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

Говоря об ООО "KAPO Vegas 22" стоит начать с рассмотрения в системе моделирования ОРГ-Мастер направления деятельности компании. Результаты представлены на рисунке 1.3.

Рисунок 1.6. Классификатор "Направление деятельности"

После создания классификатора "Направление деятельности" необходимо создать классификаторы "Организационно-ролевая структура", "Процессы", "Функции", "Виды подчиненности", "Документы и информация", "Хранилище данных", "Инфраструктура и ресурсы", "Сотрудники", Административно-штатная структура", "Хранилище ресурсов".

Классификатор "Организационно-ролевая структура" представлен ниже:

Рисунок 1.7. Классификатор "Организационно-ролевая структура"

Классификатор "Функции" представлен ниже:

Рисунок 1.8. Классификатор "Функции"

Так как мы имеем классификаторы "Организационно-ролевая структура" и "Функции", необходимо создать матрицу функциональной ответственности. Соответствующий шаблон представлен ниже:

Рисунок 1.9. Шаблон распределения функций по организационным звеньям

Результат создания матричной проекции представлен ниже:

Рисунок 1.10. Матричная проекция 3.1.2 "Организационно-ролевая структура - Функции"

Классификатор "Процессы" представлен ниже:

Рисунок 1.11. Классификатор "Процессы"

Полная диаграмма бизнес-модели кинотеатра ООО "KAPO Vegas 22" представлена на рисунке 1.9:

Рисунок 1.12. Полная диаграмма бизнес-модели Кинотеатра ООО "KAPO Vegas 22"

1.5 Описание требований к ИС

Функциональность системы кинотеатра ООО "KAPO Vegas 22":

1) Система кинотеатра ООО "KAPO Vegas 22" должна позволить централизовать управление всеми процессами, связанными с принятием и выполнением заказа, позволить руководителю своевременно получать достоверную информацию и, исходя из этого, строить правильную экономическую политику предприятия.

2) Система кинотеатра ООО "KAPO Vegas 22" должна обеспечивать хранение и обработку данных о совершенных заказах.

3) Система кинотеатра ООО "KAPO Vegas 22" должна обеспечивать учёт проданных и свободных мест.

В рассмотренной главе был проведен системный анализ кинотеатра ООО "KAPO Vegas 22".

В последствии нами были рассмотрены системы бизнес-моделирования ОРГ-МАСТЕР, BPwin, а также сделан обзор на популярные СУБД, такие как Oracle Database и MySQL. После чего был выбран инструментарий, который подходит для разработки бизнес-модели в данной системе.

В завершении мы разработали полную бизнес-модель Кинотеатра ООО "KAPO Vegas 22", созданы необходимые для реализации классификаторы и матричные модели. Это позволило нам построить схему организационной структуры компании.

Глава 2. Проектирование Информационной системы/подсистемы для кинотеатра ООО "KAPO Vegas 22"

2.1 Проектирование архитектуры ИС

В ходе изучения кинотеатра ООО "KAPO Vegas 22" как объекта автоматизации было разработано два варианта концепции АС:

· однопользовательская АС;

· многопользовательская АС (архитектура клиент-сервер).

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

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

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

Рисунок 2.0. Архитектура Клиент-Сервер кинотеатра ООО "KAPO Vegas 22"

Ввиду необходимости одновременной работы в системе множества пользователей (сюда можно включить несколько продавцов-кассиров, руководство кинотеатра, которое будет иметь больший контроль процесса продажи билетов, бухгалтерский отдел и другие) была выбрана концепция многопользовательской АС ("клиент-сервер").

2.2 Инфологическое и даталогическое моделирование БД

В инфологической модели будут использоваться 7 сущностей. Атрибуты сущностей инфологической модели приведены далее в таблицах 3-9:

Таблица №3. Фильм

Таблица №4. Зал

Таблица №5. Билет

Таблица №6. Сеансы

Таблица №7. Место

Таблица №8. Кассир

Таблица №9. Прокатчик

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

· сущность фильм - информация о фильмах;

· сущность зал - информация о залах;

· сущность место - информация о местах;

· сущность билет - информация о билетах;

· сущность кассир - информация о кассирах;

· сущность сеанс - информация о сеансах

· сущность прокатчик - информация о прокатчиках;

Выявлены следующие связи, представленные ниже:

· Кассир - Билет: Кассир может продавать 1 билет (1:1). Для обеих сущностей связь обязательная.

· Зал - Место: В зале имеется несколько мест. (1:M). Сущность "Зал" имеет обязательную связь, сущность "Место" - необязательную.

· Место - Билет: Одно место присваивается одному билету (1:1). Для обеих сущностей связь обязательная.

· Прокатчик - Фильм: Прокатчик продает лицензию (1:1). Для обеих сущностей связь обязательная.

· Фильм - Сеанс: Сеанс проводится строго по определенному фильму (1:1). Для обеих сущностей связь обязательная.

· Зал - Сеанс: любой под сеанс резервируется один зал (1:1). Для обеих сущностей связь обязательная.

· Сеанс - Билет: На один сеанс продают много билетов (1:М). Сущность "Сеанс" имеет обязательную связь, сущность "Билет" - необязательную.

Инфологическая модель БД кинотеатра ООО "KAPO Vegas 22" представлена на рисунке 2.1.

Рисунок 2.1. Инфологическая модель кинотеатра ООО "KAPO Vegas 22"

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

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

Таблица №10. FILMS

Таблица №11. ZAL

Таблица №12. TICKET

Таблица №13. SEANS

Таблица №14. PLACE

Таблица №15. KASSIR

Таблица №16. PROKAT

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

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

В таблице 17-23 приведены ключевые и индексируемые поля для даталогической модели "Кинотеатр OOO KAPO Vegas 22":

Таблица №17. FILMS

Таблица №18. ZAL