База данных аэропорта, Информационные технологии

Содержание

Введение3

1 Содержательная постановка и описание задачи4

2 Атрибуты объекта и предоставление данных в программе5

2.1 Описание базы данных5

2.2 Типы данных5

3 Описание программы создания набора данных6

4 Описание программы формирование выходного документа8

4.1 Вывод информации на экран8

4.2 Вывод информации в файл8

5 Технология обработки данных9

Заключение14

Список используемой литературы15

Приложение 116

Выдержка из текста работы

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

Под базой данных понимается некоторая унифицированная совокупность данных, совместно используемая персоналом/населением группы, предприятия, региона, страны, мира…[1]

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

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

1. Теоретические аспекты проектирования БД

1.1 Этапы проектирования БД

Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

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

Физическое проектирование

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

1.2 Описание модели данных

Реляционное представление (или модель) данных, описываемое в разд. 1, обладает некоторыми преимуществами по отношению к графовой, или сетевой модели [3,4], которая в настоящее время наиболее распространена среди систем, не основанных на логике. Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Соответственно, эта модель обеспечивает основу языка данных высокого уровня, который поддерживает максимальную независимость программ, с одной стороны, и машинного представления и организации данных с другой.

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

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

2. Инфологическое проектирование предметной области

Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных — модель «Сущность-Связи» (часто ее называют кратко ER-моделью).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

Ниже изображена сущность АЭРОПОРТ с примерными объектами Шереметьево и Хитроу:

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

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

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

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

В изображенном ниже примере связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем «для» позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем «имеет» означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Лаконичной устной трактовкой изображенной диаграммы является следующая:

· Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

· Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

На следующем примере изображена рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем «сын» определяет тот факт, что у одного отца может быть более чем один сын. Конец связи с именем «отец» означает, что не у каждого человека могут быть сыновья.

Лаконичной устной трактовкой изображенной диаграммы является следующая:

· Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

· Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ («ЧЕЛОВЕКОВ»).

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

Пример:

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

2.1 Определение сущностей

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

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

В нашем случае мы имеем такие сущности как Самолеты, Полеты и Клиенты (заказчики билетов).

Далее проведем идентификацию характеристик этих сущностей.

Сущность Самолёты включает в себя следующие характеристики:

Название самолета;

Класс мест;

Количество мест на каждый клас;

Сущность Полеты включает в себя следующие характеристики:

Самолет;

Аэропорт отправления;

Город аэропорта отправления;

Страна аэропорта отправления;

Аэропорт прибытия;

Город аэропорта прибытия;

Страна аэропорта прибытия;

Время отправления;

Время прибытия;

Сущность Клиенты включает в себя следующие характеристики:

Вся информация из сущьности Полеты;

Дата отправления;

Класс мест;

Количество заказанных мест;

Оплата (оплачен ли проезд (это нужно например для того чтобы узнать билетя куплены или заказаны)).

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

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

Для решения поставленной задачи необходимо использовать структуру представленную на рисунке 1.1.

Рисунок 1 — Структура ключевых абстракций

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

2.2 Описание атрибутов

Таблица 1 — Ключевая абстракция «Самолеты»

Характеристика	Тип
Название самолета	Строковый
Класс мест	Числовой целый
Количество мест на каждый клас	Числовой целый

Таблица 2- Ключевая абстракция «Полеты»

Характеристика	Тип
Самолет	Строковый
Аэропорт отправления	Строковый
Город аэропорта отправления	Строковый
Страна аэропорта отправления	Строковый
Аэропорт прибытия	Строковый
Город аэропорта прибытия	Строковый
Страна аэропорта прибытия	Строковый
Время отправления	Время
Время прибытия	Время

Таблица 3 — Ключевая абстракция «Заказы»

Характеристика	Тип
Самолет	Строковый
Аэропорт отправления	Строковый
Город аэропорта отправления	Строковый
Страна аэропорта отправления	Строковый
Аэропорт прибытия	Строковый
Город аэропорта прибытия	Строковый
Страна аэропорта прибытия	Строковый
Время отправления	Время
Время прибытия	Время
Дата отправления	Дата
Класс мест	Числовой целый
Количетво билетов(мест)	Числовой целый
Оплата	Булево значение

2.3 Установление связей между типами сущностей

При установлении связей между атрибутами можно выявить связи

— Один ко многим

— Многие ко многим

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

Связь же Многие ко многим наблюдается между сущностями Рейсы и самолеты и т. д.

2.4 Концепция функциональной зависимости

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

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

· первая нормальная форма (1NF);

· вторая нормальная форма (2NF);

· третья нормальная форма (3NF);

· нормальная форма Бойса-Кодда (BCNF);

· четвертая нормальная форма (4NF);

· пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

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

Определение 1. Функциональная зависимость

В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.

Определение 2. Полная функциональная зависимость

Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Определение 3. Транзитивная функциональная зависимость

Функциональная зависимость R.X (r) R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X (r) R.Z и R.Z (r) R.Y и отсутствует функциональная зависимость R.Z —> R.X. (При отсутствии последнего требования мы имели бы «неинтересные» транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

Определение 4. Неключевой атрибут

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

Определение 5. Взаимно независимые атрибуты

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

2.5 Нормализация БД

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ).

Этот процесс включает:

— устранение повторяющихся групп (приведение к 1НФ);

— удаление частично зависимых атрибутов (приведение к 2НФ);

— удаление транзитивно зависимых атрибутов (приведение к 3НФ).

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

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

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

Теперь база данных нормализована. Структура нормализованной БД приведена в приложении А. Таким образом, получаем базу данных приведенную к 3НФ и содержащую упорядоченную информацию, детально отображающую рассматриваемую предметную область. Теперь, когда мы провели нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, сделаем ряд замечаний по вопросам проектирования баз данных. Необходимо четко понять, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране [2]. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать, только тщательно проанализировав предметную область и класс поставленной задачи.

2.6 Спецификация всех объектов, входящих в модель

Таблица 4 — Спецификация сущности «Самолеты»

Характеристика	Тип	Характеристика
Название самолета	Строковый	10 символов
Класс мест	Числовой	целый
Количество мест на каждый клас	Числовой	целый

Таблица 5 — Спецификация сущности «Полеты»

Характеристика	Тип	Характеристика
Самолет	Строковый	20 символов
Аэропорт отправления	Строковый	20 символов
Город аэропорта отправления	Строковый	20 символов
Страна аэропорта отправления	Строковый	20 символов
Аэропорт прибытия	Строковый	20 символов
Город аэропорта прибытия	Строковый	20 символов
Страна аэропорта прибытия	Строковый	20 символов
Время отправления	Время
Время прибытия	Время

Таблица 6 — Спецификация сущности «Заказы»

Характеристика	Тип	Характеристика
Самолет	Строковый	30 символов
Аэропорт отправления	Строковый	20 символов
Город аэропорта отправления	Строковый	20 символов
Страна аэропорта отправления	Строковый	20 символов
Аэропорт прибытия	Строковый	20 символов
Город аэропорта прибытия	Строковый	20 символов
Страна аэропорта прибытия	Строковый	20 символов
Время отправления	Время
Время прибытия	Время
Дата отправления	Дата
Класс мест	Числовой	целый
Количетво билетов(мест)	Числовой	целый
Оплата	Булево значение	логический тип

3. Выбор СУБД

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

Microsoft Access -это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработке данных, а также управление ими при работе с большими объёмами информации.

Microsoft Access, обладая всеми чертами классической СУБД, предоставляет и дополнительные возможности. С помощью Access можно создать приложение, работающее в среде Windows и полностью соответствующее потребностям по управлению данными. База данных Access включает шесть типов объектов: таблицы, запросы, формы, отчеты, макросы, модули. Таблица — это объект для хранения данных. Используя запросы, можно выбирать и обрабатывать хранящуюся в таблицах информацию.

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

4. Описание средств обеспечения целостности данных

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

Что такое ограничения целостности

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

Вначале — немного теории.

Все ограничения целостности можно разделить на три большие категории:

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

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

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

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

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

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

5. Описание программного средства

5.1 Руководство пользователя

Таблицы в базе данных «Аэропорт»

Для реализации задачи были разработаны 4 таблицы, представленные ниже.

Таблица 7 «Пассажиры».

Поле	Тип данных	Применение
Код пассажира	Счетчик	Уникальный код пассажира, ключевое поле
ФИО	Текстовый	Фамилия, имя и отчество пассажира.
Паспортные данные	Текстовый	Паспортные данные пассажира

Таблица 8 «Билеты»

Поле	Тип данных	Применение
Номер билета	Счетчик	Номер билета, ключевое поле
Код рейса	Числовой	Код рейса, на который выписан билет
Код пассажира	Числовой	Код пассажира, купившего билет
Номер места	Текстовый	Номер места в самолете
Цена	Числовой	Цена билета
Дата вылета	Дата/время	Дата вылета самолета
Дата продажи	Дата/время	Дата продажи билета

Таблица 9 «Рейсы»

Поле	Тип данных	Применение
Код рейса	Счетчик	Уникальный номер, ключевое поле
Время вылета	Дата/Время	Информация о времени вылета
Код самолета	Числовой	Код самолета, осуществляющего перевозки по заданному рейсу
Место назначения	Текстовый	Информация о пункте назначения полета

Таблица 10 «Самолеты».

Поле	Тип данных	Применение
Код самолета	Счетчик	Уникальный код самолета, ключевое поле
Тип	Текстовый	Марка и тип самолета.
Количество мест	Числовой	Количество мест в самолете

Ниже приведены примеры заполненных таблиц.

информационный модель база данное

Рисунок 2 Пример заполнения таблицы «Билеты».

Рисунок 3 Пример заполнения таблицы «Пассажиры».

Запросы в базе данных «Аэропорт»

Для реализации задачи были разработаны 3 запроса:

Билет Печать.

Объем продаж.

Свободные места на рейсе.

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

Вводится номер билета из таблицы «Билеты». Причем отбирается тот билет, который просматривается в форме «Билеты». Используется условие «Like [Forms]![Билеты]![Номер билета]».

Вводятся соответствующие реквизиты билета

Из таблицы «Пассажиры» отбираются реквизиты «ФИО» и «Паспортные данные».

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

Запрос «Объем продаж» служит для вывода в наглядной форме информации о продажах за определенный период. Запрос вызывается из формы «Объем продаж», где задается период, за который следует выводить информацию. Схема работы запроса:

Данные берутся из таблицы «Билеты». Записи группируются по реквизиту «Дата продажи». При этом используется условие «>[Forms]![Объем продаж]![Дата1] And <[Forms]![Объем продаж]![Дата2]».

В поле Sum_Цена подсчитывается сумма реквизитов цена.

В поле Count _ Билеты используется функция «Count(*)», которая подсчитывает число билетов.

Пример работы запроса «Объем продаж» при непосредственном вызове.

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

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

Из таблицы «Билеты» извлекается код рейса при помощи условия «Like [Forms]![Билеты]![Рейс]».

Из таблицы «Самолеты», связанной с таблицей рейсы, берется реквизит «Количество мест».

Из таблицы «Билеты» отбирается «Дата вылета» по условию «Like [Forms]![Билеты]![Дата вылета]».

В поле «Count_Билеты» при помощи функции «Count(*)» вычисляется количество проданных на соответствующий рейс и дату билетов.

В поле «Осталось» при помощи выражения «[Количество мест]-[Count_Билеты]» вычисляется количество свободных мест на соответствующий рейс и дату.

Формы базы данных «Аэропорт».

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

Ниже рассматриваются следующие формы:

Форма «При запуске» открывается при открытии базы данных «Аэропорт». Содержит информацию о базе данных. Открытие этой формы одновременно с базой данных осуществлено путем помещения имени формы в строку «Форма» меню «Сервис/Параметры запуска». При нажатии кнопки запускается процедура обработки события Кнопка15_Click, которая закрывает эту форму. Форма «При запуске» предназначена для работы пользователя с базой данных. Щелчок мыши по каждой из кнопок вызывает соответствующее событие — открытие формы, так как все элементы базы данных «Аэропорт» вызываются для удобства из форм.

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

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

Форма «Билет» выглядит следующим образом.

Форма «Объем продаж» построена для вызова отчета по объему продаж.

Отчеты в базе данных «Аэропорт»

Отчеты в базе данных «Аэропорт» демонстрируют способ эффективного представления данных в печатной форме. Они созданы для предоставления выдаваемых базой данных сведений в удобном для восприятия виде.

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

Отчеты «Объем продаж» и «Свободные места на рейсе» служат для вывода данных одноименных запросов. При этом в отчете «Объем продаж» были использованы выражения «=Sum([Sum_Цена])» и «=Sum([Count_Билеты])» для подсчета итоговых сумм объемов продаж и количества проданных билетов соответственно.

Отчет «Объем продаж» вызывается из специальной формы «Объем продаж» и выглядит следующим образом:

Отчет «Свободные места на рейсе» вызывается из формы «Билеты» по мере необходимости и представляет информацию о количестве свободных мест в следующем виде:

Заключение

На примере базы данных «АЭРОПОРТ» мы познакомились с инструментом разработки баз данных Microsoft Access. С его помощью можно быстро создавать деловые приложения для различных сфер деятельности человека. В то же время СУБД Access имеет архитектурные ограничения (например, максимальный размер базы данных не более одного гигабайта), которые не позволяют использовать этот инструмент для управления большими промышленными распределенными базами данных. Для таких целей применяются клиент-серверные СУБД Oracle, IBM DB2, Microsoft SQL Server, Sybase и ряд других.

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

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

Список литературы

1. Евсюков В.В. Экономическая информатика: Учеб. пособ. — Тула: Издательство «Гриф и К», 2005. — 371с.: ил.

2. Партыка Т.Л., Попов И.И. Информационная безопасность. Учебное пособие для студентов учреждений среднего профессионального образования. ~М.: ФОРУМ: ИНФРА-М, 2004, — 368с.: ил. — (Серия «Профессиональное образование»)

3. Информатика: Базовый курс / Под редакцией С.В. Симоновича, Издательский дом «Питер», 2002, 640с.

4. Завгородний В.И. Комплексная защита информации в компьютерных системах: Учебное пособие. — М.: Логос; ПБОЮЛ Н.А.Егоров, 2001. — 264с.: ил.

5. Мельников В.В. Защита информации в компьютерных системах. -М.: Финансы и статистика; Электронинформ, 2006. — 368с.: ил.

Размещено на