Файл: Автоматизация продажи билетов в кинотеатре Радуга кино г. Москва.pdf

7) № пользователя – номер пользователя создавшего запись из таблицы

8) Права родителя – права создателя

9) Права группы – права группы

10) Права остальных – права всех остальных участников.

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

Макет экранной формы «Результат поиска» приведен на рисунке 12.

Рисунок 12 - Макет экранной формы «Заявка»

На форме предоставлено поле, где мы вводили требуемый запрос, кнопка поиска и результативная искомая информация представленная в виде таблице с столбцами: №, ФИО, Комментарий. Данные формы создаются на основе таблицы форумы.

Так же системой генерируются файлы договоров по шаблону. Пример созданного документа можно посмотреть в Приложении 1. Файл формируется на основе введенных данных в форме “Создание задачи и документа”. Основные реквизиты файла:

1) Лицо в виде исполнителя

2) Лицо в виде заказчика

3) Перечень услуг

4) Права и обязанности сторон

Главной формой является форма утверждения договора ( рисунок 13)

Рисунок 13 - Макет экранной формы «Утверждение договора»

Форма имеет следующие реквизиты:

1) Название договора

2) Комментарий договора

3) Комментарии пользователей

4) Права участников

5) Текст для добавление комментария.

2.4.Характеристика результатной информации

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

1. «Отчет по согласованным заявкам»

Формируется на основе след таблиц и полей:

• Дата создания заявки
• Пользователь (заявитель)
• Ответственная группа
• Назначенный на заявку сотрудник
• Статус
• Приложенное исходное письмо (тема и тело письма в оригинале)

2. Отчет ”заявки по местоположению заявителя”:

Содержит таблицу со следующими полями:

• Дата создания заявки
• Даты писем по согласованию
• Пользователь (заявитель)
• Месторасположение(город)
• Адрес (улица, дом, корпус, офис)
• Ответственная группа
• Текущий статус переписки и зарегистрирована ли заявка
• Приложенное окончательное письмо (тема и тело письма в оригинале)

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

3.Программное обеспечение задачи

3.1 Общие положения (дерево функций и сценарий диалога)

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

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

Рисунок 14 Дерево функций

Опишем процессы, представленные на данной диаграмме.

Расписание сеансов и стоимость билетов - Клиент получает информацию о сеансах:

- Наименование

- Дата и время начала сеанса

- Длительность

- Стоимость билетов класса A, B, C

- Зрительный зал, в котором проводится сеанс

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

Информация о сеансах – это информация которая позволяет Клиенту понять что за Сеансы проводятся в Кинотеатре и помогает выбрать на какой из них пойти

Возврат в выбор операций - решение пользователя вернуться к выбору операций

3.2 Характеристика базы данных.

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

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

К основным функциям СУБД относятся следующие:

· физическое размещение в памяти данных и их описаний;

· поддержка баз данных в актуальном состоянии;

· механизмы поиска запрашиваемых данных;

· доступ к данным при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

· способы обеспечения защиты данных от некорректных обновлений и/или несанкционированного доступа.

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры.

Тщательное проектирование базы данных – первый и очень важный шаг создания базы. Он позволяет избежать затрат, связанных с внесением исправлений в структуру хранящихся данных. Проектирование базы данных начинается с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). На этапе проектирования выявляются объекты информации и их характеристики, определяются виды данных, требующие регулярного обновления, и способы представления информации на экране и в отчетах, формулируются вопросы, на которые необходимо регулярно отвечать при поиске данных. Это помогает конкретизировать требования к хранимой информации. В любой момент можно изменить структуру хранящейся в базе информации, подкорректировав структуру таблиц и, соответственно, форм и отчетов. За проектирование и поддержку базы данных отвечает администратор базы данных (АБД).

СУБД использует следующие модели и описания:

· инфологическую;

· даталогическую;

· физическую.

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

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

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

В основе каждой СУБД лежит концепция модели данных, то есть некоторой абстракции представления данных. Изначально были успешными две конкурирующие модели – иерархическая и сетевая. Иерархическая БД состоит из упорядоченного набора деревьев. Корпорация IBM разработала и внедрила язык описания данных DL/I (Data Language One), который моделировал данные в иерархической форме (представление данных в форме деревьев). Эта модель была разработана совместно с промышленными предприятиями и предназначалась для хранения и поддержки данных, которые иерархически связаны между собой, например, сметы материалов и списки деталей. Типичным представителем иерархической СУБД является СУБД IMS (Information Management System) компании IBM, первая версия которой появилась в 1968 г.

Таблица 4 «Должности»

Таблица 5 «Жанры»

Таблица 6 «Репертуар»

Таблица 7 «Фильмы»

Рисунок 15 – Фрагмент сценария диалога в кинотеатре Радуга

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

Рисунок 16 – Фрагмент ER-модели кинотеатра «Радуга»

3.3 Структурная схема пакета (дерево вызова программных модулей)

Рисунок 17 – Дерево программных модулей

3.4 Описание программных модулей.

Объединение указанных программ с программами модулей алгоритмов допускается лишь в исключительных случаях. 
Стратегия настройки параметров сосредоточена в модуле алгоритма адаптации. Он имеет интеллект адаптивного регулятора в форме различных команд установки параметров в зависимости от значения текущего показателя качества.   
Программный модуль представляет программу, реализующую модуль алгоритма. Программа имеет стандартизованный вход и выход, обладает свойством параметрической настраиваемости.   
Каждое типовое проектное решение, построенное по модульному принципу, реализует определенные части задач. Модуль алгоритма представляет собой часть алгоритма решения задачи. Он характеризуется определенной степенью законченности и устойчивости к изменениям и обладает возможностью как многократного самостоятельного использования, Такие задачи относятся к классу задач, решаемых методами нелинейного или динамического программирования. Хотя существует достаточно много работ, посвященных рассмотрению подобных задач, универсальный алгоритм их решения не найден. Специфика каждой задачи ( тип функционала, экстремум которого ищется; характер ограничения) и ее умелое использование могут в каждом случае помочь выбрать наиболее удачный, для расчета алгоритм. В то же время, учитывая необходимость проведения расчетов на ЭЦВМ и сложность программирования такого рода алгоритмов, целесообразно максимально унифицировать такие расчеты. Целесообразно располагать некоторым набором модулей алгоритмов и реализующих их рабочих программ решения типовых задач оптимизации.