База данных «Учет рейса» для аэропортов

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ДАГЕСТАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра Информационных Систем КУРСОВАЯ РАБОТА По дисциплине

«База данных и знаний»

На тему

«Система Аэропорт»

Выполнил: ст-т 3 курса 3163 гр

Муртузалиев И. А Принял: Фоменко А. Д

Махачкала 2003 г.

Задание по курсовой работе Система ««

Предполагаемые поля БД:

- номер рейса;

— дата рейса;

— время вылета;

— пункт назначения;

— тип самолета;

— стоимость билета;

— наличие свободных мест;

— номер места;

— ФИО пассажира;

— тип.

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

Введение

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

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

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

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

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

Глава I. Теоретическая часть

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

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

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

ь на уровне внутреннего представления данных (с позиции системного программиста) или представления реализации.

Под представлением данных понимают правила организации и кодировании данных.

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

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

Рис. 1 Трехуровневое представление данных в концепции ANSI/SPARC.

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

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

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

Концептуальное представление основано на определенной модели данных. Этот термин впервые введенный в 70 — х годах основоположником теории баз данных Дж. Коддом, в современной трактовке отображает совокупность правил порождения структур данных в базах данных, последовательности их изменения. Различают три основные типа модели данных: иерархический, сетевой и реляционный.

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

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

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

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

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

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

Процесс построения концептуальной модели разделяется на следующие этапы:

1) сбор и содержательный анализ априорной информации о предметной области и прикладных задач пользователей;

2) концептуальный анализ данных и синтез концептуальной модели.

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

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

Результатом данного этапа являются:

1) список всех создаваемых и используемых элементов данных;

2) перечень прикладных задач, их характеристик и используемых в них данных;

3) список принимаемых решений в управлении организацией или процессами, а также условий и правил их принятия;

4) список возможных будущих изменений в деятельности и их влияний на принятие решений.

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

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

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

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

Декомпозиция должна:

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

· приводить к вычислению элементов, свойства которых могут быть описаны с помощью собранных на первом этапе элементов данных;

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

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

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

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

В качестве основных принципов системного подхода при построении моделей используются:

рассмотрения объекта с различных точек зрения, выявления аспектов изучаемого с учетом их взаимосвязи;

расчленения объекта на более простые подсистемы (основанием для введения подсистем является то, что связи между подсистемами много слабее, чем между элементами внутри подсистемы, а каждая подсистема много проще, чем вся система в целом);

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

Системный анализ — это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.

Их дополняют следующие специфические принципы:

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

· необходимо рассматривать лишь те цели, вероятность достижения которых p>p₀ за время t0, где p₀ и t₀ пороги осуществимости цели.

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

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

Прежде чем преступить к работе с «Fox Pro», познакомимся с некоторыми понятиями и принципами организации баз данных (БД). БД системы «Fox Pro» с определенной степенью строгости можно назвать реляционными. Не вдаваясь в тонкости точного определения реляционной модели организации данных, скажем лишь, что пользователем реляционная база данных воспринимается как таблица (или совокупность таблиц). Используя аналогии с двумерной таблицей, мы дадим определение таких понятий, как «запись», «поле», «файл данных». Строку в нашей таблице назовем «записью» (record), а столбец «полем» (Field). «Файл данных» объединяет собственно информацию, хранящуюся в таблице, и информацию о ее структуре.

Запись характеризуется своим номером, а поле имеет «имя поля» (fieldname). Именно указание номера записи и имени поля позволяет осуществить доступ к конкретной единице информации — значению поля данной записи, хранящемуся в ячейке нашей таблицы. Сразу укажем, что в «Fox Pro» имя поля может состоять наиболее, чем из десятки латинских букв или цифр, должно начинаться с буквы, из специальных знаков допустим лишь знак подчеркивания «__».

Помимо имени поле имеет еще две важные характеристики: ширину (width) и тип данных (field type). Ширина указывает, сколько позиций будет отводиться в базе данных для значений данного поля (данные большей длины будут усекаться).

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

«Fox Pro» поддерживает шесть различных типов данных

1. Символьные (Character) произвольная строка символов, как правило, заключаемая в двойные или одинарные кавычки.

Напомним, что пробел тоже является символом и влияет на длину символьной строки.

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

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

Для числовых полей типа Numeric и Float кроме ширины определяется число знаков после десятичной точки. В случае, когда содержимое поля является числом, но не участвует в вычислениях (например, почтовый индекс), следует определять тип поля как Character это ускорит и упростит манипулирование данными.

4. Логические (Logical) данные, которые могут принимать только два значения: «Да» (Yes) или «Правда» (True) и «Нет» (No) или «Ложь» (False). Примером такого типа данных может служить членство в профсоюзе: «Да» (член профсоюза) или «Нет» (не член профсоюза).

5. Дата (Date) тип данных, говорящий сам за себя. Выделен потому, что даты подчиняются собственной арифметике (прибавление дней к определенной дате, определение числа дней между двумя датами и т. д.). Ширина полей этого типа данных автоматически устанавливается равной 8. Дата может выводиться в следующих форматах:

американском (american ММ ДД ГГ);

британском (british ДД / ММ / ГГ);

французском (frensh ДД.ММ.ГГ);

итальянском (italian ДД ММ ГГ);

В стандарте Американского национального института стандартов (ANSI ГГ.ММ.ДД).

Символы ДД, ММ и ГГ обозначают соответственно день, месяц и год конкретной даты. Например, 23 сентября 1996 года в американском формате примет вид 09/23/96.

6. Текстовые (Memo) символьные данные, длина которых не определена заранее. Преимущество типа Memo и Character состоит в том, что размер текста, занесенного в такое поле, может быть довольно большим (до 4096 символов) и на него выделяется столько места, сколько занимает текст (или вообще ничего, если поле пусто). В основном файле данных для полей типа Memo выделяется 10 позиций, а сама информация хранится в отдельном файле с расширением *.dbt.

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

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

Еще до включения компьютера необходимо определить, в каких файлах данных и с какой структурой будут храниться связанные отношениями данные. Под структурой файла данных мы будем понимать число полей и их характеристики: имя, тип данных, ширина, число знаков после десятичной точки (для полей типа Numeric и Float).

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

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

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

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

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

Требования, предъявляемые к инфологической модели.

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

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

Желательно, чтобы язык спецификации ИЛМ был одинаково применим как при ручном, так и при автоматизированном проектировании информационных систем. Последнее предъявляет дополнительные требования к нему, а именно он должен:

· быть вычисляемым, т. е. восприниматься и обрабатываться ЭВМ;

· использовать «дружелюбные» пользователю интерфейсы, в частности графические;

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

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

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

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

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

Компоненты инфологической модели.

Инфологическая модель предметной области включает в себя ряд компонентов (рис.2). Центральной компонентной инфологической модели является описание объектов предметной области и связей между ними.

Рис. 2. Компоненты инфологической модели Описание предметной области всегда представлено в какой-то знаковой системе. Поэтому кроме отношений, присущих предметной области, возникают еще и отношения, обусловленные особенностями предметной области в языковой среде. Поэтому при построении ИЛМ должны учитываться такие лингвистические категории, как синонимия, омонимия, изоморфизм и др.

Кроме того, в инфологической модели должны быть отражены и алгоритмические зависимости между показателями. Обычно для этих используются графы взаимосвязи показателей, отражающие, какие показатели служат исходными для вычисления других. Расчетные формулы, а также алгоритмы вычислений также в каком-то виде должны быть представлены в ИЛМ. Следующим компонентом инфологической модели является описание потребностей пользователей. Для этих целей используются специальные языковые средства. Они должны отражать тип запроса, объемно — частные характеристики, режим использования данных и т. п. На рисунке 3 изображена инфологическая модель для системы «Аэропорт».

1.2 Общие сведения о даталогическом проектировании

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

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

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

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

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

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

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

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

Глава II. Проектная часть

Описание объекта «Аэропорт»

2.1 Учета рейсов в аэропортах.

В данном курсовом проекте рассматривается система «Аэропорт». Она представляет собой следующий процесс:

Оформление пассажиров на вылет.

Регистрация пассажиров, вылетающих тем или иным воздушным судном (ВС).

Регистрация пассажиров производится основным методом, при котором ведется ведомость регистрации отправок пассажиров «Пассажирский манифест» — «PASSENGER MANIFEST».

Также ведется регистрация билетов и оформление багажа, который делится на три этапа: подготовку, собственно регистрацию, подведение и передачу итогов регистрации диспетчеру.

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

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

Подготовить «Пассажирский манифест» в трех экземплярах и записать в него следующие данные:

«Owner or Operator» — авиакомпания, выполняющая рейс;

«Marks of nationality and registration» — тип и бортовой номер ВС;

«Flight» — номер рейса;

«Date» — дату вылета;

«Point of Embarkation» — аэропорт отправления;

«Point of disembarkation» — аэропорт назначения.

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

Сообщить диспетчеру перевозок о готовности к регистрации.

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

Регистрация билетов производится в следующем порядке:

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

б) Пассажиры в порядке очередности предъявляют билеты и документы, подтверждающие личность пассажира.

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

По окончанию регистрации агент перевозок:

Подводит итоги в пассажирском манифесте по каждому пункту посадки и в целом по рейсу.

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

Подсчитывает количество мест по каждому аэропорту разгрузки и сверяет с данными пассажирского манифеста.

Передает данные итогов регистрации диспетчеру перевозок.

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

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

2.2 Инфологическая модель по «Учет рейса»

Рис. 3. Инфологическая модель: «Учет рейса»

2.3 Даталогическая модель по «Учет рейса»

REIS.DBF

PUNKT.DBF

SAMOLET.DBF

PASSAG.DBF

KLAS.DBF

Глава III. Описание работы программы

О программе.

Программа предназначена для ведения учета рейса в аэропорту. Программа выполняет ввод нового пассажира через пункт меню 'Ввод'. Помимо ввода программа предусматривает вывод общего списка рейса с указанием типа самолета, даты и времени вылета и ФИО пассажира по возрастанию на экран. Также происходит поиск пассажира по фамилии и поиск по пункту назначения. Помимо поиска программа предусматривает фильтрацию, которая осуществляется по двум полям базы данных: по дате и номеру рейса. Если в программе указаны не та фамилия, не тот пункт назначения или еще чего-нибудь, или же они набраны неправильно, то появится сообщение об ошибке, т. е. 'Не найден'.

Выход может производиться в программу FохРго и вообще из программы.

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

Номер рейса.

Дата рейса.

Время вылета.

Пункт назначения.

Маршрут рейса.

Время прилета.

Тип самолета.

Класс.

Заводской номер самолета.

ФИО пассажира.

Серийный номер паспорта пассажира.

Кем выдан паспорт.

№ взлетной полосы.

Общее количество билетов.

Количество проданных билетов.

Стоимость билета.

Наличие свободных мест.

Номер места.

При запуске программы на экран выведется окно, на котором активировано пользовательское меню следующего вида:

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