Файл: Автоматизация продажи авиабилетов в Аэропорте Emirates airline Dubai airport.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 28.03.2023

Просмотров: 198

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

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

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

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

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

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

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

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

Имя поля

Тип данных

Код должности

Числовой

Наименование должности

Текстовый

Оклад

Денежный

Обязанности

Текстовый

Требования

Текстовый


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

Имя поля

Тип данных

Код жанра

Числовой

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

Текстовый

Описание

Текстовый

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

Имя поля

Тип данных

Код сеанса

Числовой

Дата

Дата/время

Время начала

Дата/время

Время окончания

Дата/время

Цена билета

Денежный

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

Имя поля

Тип данных

Код фильма

Числовой

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

Текстовый

Код жанра

Текстовый

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

Числовой

Фирма производитель

Текстовый

Страна производитель

Текстовый

Актеры

Текстовый

Возрастные ограничения

Числовой

Рисунок 16 – Фрагмент сценария диалога аэропорт «Emirates airline Dubai airport»

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

Рисунок 17 – Фрагмент ER-модели аэропорт «Emirates airline Dubai airport»

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

Используется классическая система "Клиент-Сервер".

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

На стороне пользователя производится только ввод информации и получение отчетов в графическом режиме

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

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

Техническая сложность проекта (TCF - Technical Complexity Factor) вычисляется с учетом показателей технической сложности. Все показатели приведены в табл.4.


Каждому показателю присвоено значение в диапазоне от 0 до 5 (0 помечает отсутствие значимости показателя для данного проекта, 5 - высокую значимость) и значение с условием веса показателя.

Таблица 4

Описание функций модулей

№ п/п

Наименование модуля

Функции модуля

1.1

Модуль безопасности

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

22.

Модуль инициализации интерфейса программы

После успешного входа в систему, запускает программу, используя настройки прав доступа для учетной записи пользователя

3.3

Модуль управления деревом объектов

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

44.

Модуль взаимодействия с базой данных

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

5.5

Модуль справочной системы

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

66.

Модуль «Справочники»

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

77.

Модуль ввода данных «Заявки»

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

88.

Модуль «Отчеты»

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

99.

Модуль «Печать документов»

Обеспечивает предварительный просмотр, настройку параметров документов и печать на принтере

4. Контрольный пример реализации и его описание.

Спецификация требований к информационной системе «Автоматизация продажиавиабилетов в Аэропорте Emirates airline Dubai airport»


Цель

Цель этого документа – в том, чтобы сформулировать требования к разрабатываемой АИС Продажи билетов в кинотеатре. Данные требования описаны в форме прецедентов, кратких описаний функциональных требований и описаний нефункциональных требований.

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

Основное действующее лицо: Клиент.

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

.

\

Рисунок 19 – Форма отчёта

Рисунок 20 – Форма чека (рейсы)

Рисунок 21 – Форма покупка билетов

Рисунок 22 – Форма касса аэропорта

Рисунок 23 – Форма возврат билетов

.

Рисунок 24 – Форма ввод данных о пассажирах

Заключение

 Для увеличения объемов продаж авиакомпании как известно пользуются услугами туристических  фирм, и авиационных агенств. В  настоящее время происходит стремительный  подключения новых агентств к  глобальным компьютерным системам бронирования Amadeus, Galileo, Sabre, Worldspan, Fidelio. Только за прошедший год эти КСБ практически удвоили число своих пользователей. Во многом,  благодаря растущей популярности Интернета. И это не предел. Ведь в XXI веке - веке компьютерных технологий немаловажно автоматизировать свой офис. Не стоит забывать о том, что телефон и факс теперь уже уступают свои позиции компьютерному оборудованию, помогающему быстро и качественно совершить бронирование через интернет. В настоящее время выбор КСБ достаточно велик, но будущему пользователю необходимо владеть информацией о каждой из КСБ для того чтобы сделать правильный выбор. Здесь и спектр возможностей, предоставляемых КСБ, и сопоставление качества с ценой.
Исходя из этого, целью данной работы я ставлю объективное рассмотрение возможностей как отечественных, так и зарубежных КСБ на современном этапе развития.