Создание базы данных аэропорта в программной среде Microsoft Access

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

1. Инфологическое проектирование

1.1 Анализ предметной области

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

1.2 Анализ информационных задач и круга пользователей системы

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

Основной задачей стоящей перед проектируемой БД является составление расписания вылетов самолетов аэропорта под управлением соответствующих экипажей.

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

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

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

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

· Ввод данных.

· Хранение данных.

· Обновление данных.

· Выборка данных.

· Предоставление отчетов.

Для удобства ввода и управления данными необходимо создание в БД форм.

1.3 Инфологическое проектирование

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

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

Анализ ПО позволяет выделить сущности.

Стержневые сущности: Самолеты, Рейсы, Пилоты, Кассиры.

Обозначающие сущности: Должности.

Ассоциативные сущности: Вылеты, Продажа.

Характеризующие сущности: Экипажи.

Используя инфологический язык моделирования (ЯИМ) БД можно описать следующим образом:

Самолеты (Код самолета, Название самолета, Взлетная масса, Скорость, Высота, Бортовой номер, Тип самолета, Кол-во посадочных мест, Топливо, Длина разбега);

Рейсы (Номер рейса, Название рейса, Время вылета, Время прибытия);

Пилоты (Код пилота, Код должности, Номер экипажа, Фамилия, Имя, Отчество, Дата рождения, Адрес, Телефон);

Кассиры (Код кассира, Фамилия, Имя, Отчество);

Вылеты [Самолеты M, Рейсы N, Экипажи P] (Код вылета, Код экипажа, Номер рейса, Код самолета, День вылета);

Продажа [Рейсы M, Кассиры N] (Код продажи, Код кассира, Номер рейса, Дата продажи, Дата вылета, Фамилия, Имя, Отчество, Серия/№ паспорта, Цена билета, Место №);

Должности (Код должности, Название должности, Оклад, Премия, Итого) [Пилоты];

Экипажи (Код экипажа, Группа допуска) {Пилоты, Вылеты}.

2. Определение требований к операционной обстановке

2.1 Выбор ПО и ЭВМ

Примем во внимание, что данная база данных физически реализована в Microsoft Office 2003, поэтому, примем минимальные системные требования, которые устанавливает фирма производитель данного программного обеспечения фирма Microsoft. Данная информация содержится в справке к данному продукту:

· Процессор:

Pentium 233 MHz и выше. Рекомендуется Pentium III.

· Операционная система:

Microsoft Windows 2003 с пакетом обновления 3 или более поздняя версия. Рекомендуется Windows XP или более поздняя версия.

· Память:

64 MB RAM (минимум). Рекомендуется 128 MB RAM.

· Дисковое пространство:

245 MB для всего Microsoft Office 2003 и 63 МВ для Microsoft Office Access.

· Монитор:

Super VGA (800 x 600) или более высокое разрешение с 256 цветами.

· Дисковод:

Дисковод для компакт-дисков.

· Указывающее устройство:

Microsoft Mouse, Microsoft IntelliMouse или совместимое указывающее устройство.

Примечание. Ни одна из версий Microsoft Office в 2003 году не работает с операционными системами Microsoft Windows Me, Windows 98 или Windows NT, если на клиентских компьютерах установлена одна из этих операционных систем, перед установкой Microsoft Office ее необходимо обновить.

2.2 Объем внешней памяти занимаемый модулями СУБД

Объем внешней памяти занимаемый модулями СУБД определяется практически по созданной базе данных. Размер проектируемой базы данных «Аэропорт» составляет 1 748 992 байт.

2.3 Объем памяти, отводимый под данные

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

Рассмотрим отношение «Самолеты».

Число атрибутов отношения а=10. Число самолетов находящихся в БД аэропорта выбираем предположительно равным десяти единицам, то есть мощность отношения N=10. Данные сведены в таблицу 2.1.

Таблица 2.1 - Самолеты

Код самолета	Название самолета	Взлетная масса	Скорость	Высота	Бортовой номер	Тип самолета	Кол-во посадочных мест	Топливо	Длина разбега
1 байт	6 байт	8 байт	8 байт	11 байт	8 байт	25 байт	3 байта	7 байт	8 байт

Тогда размер под данные таблицы составляет:

Dсамолеты=(1+6+8+8+11+8+25+3+7+8)*10=850 байт.

Рассмотрим отношение «Вылеты».

Число атрибутов отношения а=5. Число вылетов в неделю принимаем равным 20, то есть мощность отношения N=20. Данные сведены в таблицу 2.2.

Таблица 2.2 - Вылеты

Код вылета	Код экипажа	Номер рейса	Код самолета	День вылета
1 байт	1 байт	1 байт	1 байт	11 байт

Тогда размер под данные таблицы составляет:

Dвылеты=(1+1+1+1+11)*20=300 байт.

Рассмотрим отношение «Должности».

Число атрибутов отношения а=5. Число должностей пилотов принимаем равным 5, то есть мощность отношения N=5. Данные сведены в таблицу 2.3.

Таблица 2.3 - Должности

Код должности	Название должности	Оклад	Премия	Итого
1 байт	14 байт	11 байт	11 байт	12 байт

Тогда размер под данные таблицы составляет:

Dдолжности=(1+14+11+11+12)*5=245 байт.

Рассмотрим отношение «Кассиры».

Число атрибутов отношения а=4. Число кассиров в аэропоту принимаем равным 10, то есть мощность отношения N=10. Данные сведены в таблицу 2.4.

Таблица 2.4 - Кассиры

Код кассира	Фамилия	Имя	Отчество
1 байт	15 байт	15 байт	20 байт

Тогда размер под данные таблицы составляет:

Dкассиры=(1+15+15+20)*10=510 байт.

Рассмотрим отношение «Пилоты».

Число атрибутов отношения а=9. Число пилотов в аэропоту принимаем равным 60, то есть мощность отношения N=60. Данные сведены в таблицу 2.5.

Таблица 2.5 - Пилоты

Код пилота	Код должности	Номер экипажа	Фамилия	Имя	Отчество	Дата рождения	Адрес	Телефон
1 байт	1 байт	1 байт	15 байт	15 байт	20 байт	12 байт	30 байт	15 байт

Тогда размер под данные таблицы составляет:

Dпилоты=(1+1+1+15+15+20+12+30+15)*60=6600 байт.

Рассмотрим отношение «Продажа».

Число атрибутов отношения а=11. Число пассажиров, купивших билеты за неделю принимаем равным 2000, то есть мощность отношения N=2000. Данные сведены в таблицу 2.6.

Таблица 2.6 - Продажа

Код продажи	Код кассира	Номер рейса	Дата продажи	Дата вылета	Фамилия	Имя	Отчество	Серия/№ паспорта	Цена билета	Место №
1 байт	1 байт	1 байт	12 байт	12 байт	15 байт	15 байт	20 байт	11 байт	12 байт	3 байта

Тогда размер под данные таблицы составляет:

Dпродажа=(1+1+1+12+12+15+15+20+11+12+3)*2000=206000 байт.

Рассмотрим отношение «Рейсы».

Число атрибутов отношения а=4. Число рейсов принимаем равным 10, то есть мощность отношения N=10. Данные сведены в таблицу 2.7.

Таблица 2.7 - Рейсы

Номер рейса	Название рейса	Время вылета	Время прибытия
1 байт	25 байт	5 байт	5 байт

Тогда размер под данные таблицы составляет:

Dрейсы=(1+25+5+5)*10=360 байт.

Рассмотрим отношение «Экипажи».

Число атрибутов отношения а=2. Число экипажей принимаем равным 12, то есть мощность отношения N=12. Данные сведены в таблицу 2.8.

Таблица 2.8 - Экипажи

Код экипажа	Группа допуска
1 байт	1 байт

Тогда размер под данные таблицы составляет:

Dэкипажи=(1+1)*12=24 байта.

Тогда объем памяти отводимый под данные будет равен:

D=2*(Dсамолеты+Dвылеты+Dдолжности+Dкассиры+Dпилоты+Dпродажа+Dрейсы+Dэкипажи)=2*(850+300+245+510+6600+206000+360+24)=429778 байт.

2.4 Представление о характере и интенсивности запросов

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

· для реализации операции по выборке экипажа и самолета для вылета создается запрос на выборку - «Выборка по экипажам»;

· с помощью запроса «Расписание» диспетчеры могут вносить поправки в существующее расписание вылетов самолетов, которое выводится на электронное табло в зале ожидания аэропорта;

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

3. Выбор системы управления базой данных (СУБД)

Система управления базами данных (СУБД) предназначена для централизованного управления базой данных в интересах всех работающих в этой системе. Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и безопасности работы с данными, что даёт возможность разработчикам гарантировать большую безопасность данных при меньших затратах сил на низкоуровневое программирование. Программные продукты, для БД функционирующие в среде Windows выгодно отличаются удобством пользовательского интерфейса и встроенными средствами повышения производительности. Сравним основные характеристики некоторых СУБД - лидеров на рынке программ для БД. К числу таких относятся: dBase, Microsoft Access, Microsoft FoxPro, Paradox.

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

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

Необходимость использования базы данных для относительно большого числа пользователей накладывает дополнительные требования на выбор СУБД и системно программного обеспечения, в частности выбираемая СУБД должна работать в многопользовательских средах. Лучшими возможностями для работы в многопользовательских средах обладают Paradox и Access. Указанные СУБД обладают, например следующими возможностями:

· блокировка БД, файла, записи;

· идентификация станции, установившей блокировку;

· обновление информации после блокировки;

· контроль за временем и повторением обращения;

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

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

· встроенные средства для назначения первичного ключа;

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

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

СУБД обладающие доступом данных посредством языка запросов SQL (Structured Query Language - язык структурированных запросов). Язык SQL в силу своего широкого применения является международным стандартом языков запросов. Язык предоставляет развитые возможности, как конечным пользователям, так и специалистам в обработке данных. Совместимость с SQL системами играет большую роль, когда предполагается проведение работ с корпоративными данными. СУБД имеют доступ к данным SQL, если базы данных совместимы с ODBC (Open Database Connectivity - открытое соединение баз данных). С помощью Access можно напрямую управлять базами данных с помощью SQL и передавать сквозные SQL-запросы совместными со спецификацией ODBC SQL-базами данных. Так что, Access способна служить средством разработки масштабируемых систем клиент-сервер.

Кроме того СУБД Access входит в пакет программ Microsoft Office, и имеет хорошо организованные связи с такими программами как Excel, Word. Данное взаимодействие обеспечивает потенциальную возможность увеличения функциональных способностей Access. Наличие в составе Access языка программирования высокого уровня Visual Basic позволяет создавать макрокоманды и процедуры для более гибкого обращения с данными.

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

Исходя из проведённого анализа, для реализации проектируемой реляционной БД аэропорта выбирается Microsoft Office Access.

4. Логическое проектирование

Логическое проектирование начинается с построения универсальной таблицы (реляционного отношения), которая удовлетворяет требованию первой нормальной формы (1НФ), т.е. в универсальной таблице имеется закономерность «один факт в одном месте». Построение универсальной таблицы ведётся исходя из проведённого анализа предметной области.

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

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

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

Номер экипажа уникален для группы допуска всего экипажа

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

Код вылета уникален для дня вылета.

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

Личные данные всех кассиров также хранятся в базе данных.

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

Выделим в отдельные таблицы сведения о самолетах, вылетах, экипажах, пилотах, рейсах, должностях, продажах и кассирах.

Таблица 4.1 - Самолеты (2НФ)

Код самолета	Название самолета	Взлетная масса	Скорость	Высота	Бортовой номер	Тип самолета	Кол-во посадочных мест	Топливо	Длина разбега
1	АН-2	5250кг	200км/ч	300-500м	РА964825	Поршневой биплан	12	Б91/115	180-240м
2	АН-24	21тонна	430км/ч	1200-5700м	57413	Турбовинтовой моноплан	52	ТС1	450-550м

Таблица 4.2 - Вылеты (2НФ)

Код вылета	Код экипажа	Номер рейса	Код самолета	День вылета
1	1	7	1	Пятница
2	3	6	1	Понедельник

Таблица 4.3 - Рейсы (2НФ)

Номер рейса	Название рейса	Время вылета	Время прибытия
1	Балаково-Москва	8:20	10:20
2	Балаково-Свердловск	10:30	12:05

Таблица 4.4 - Кассиры (2НФ)

Код кассира	Фамилия	Имя	Отчество
1	Жукова	Анастасия	Сергеевна
2	Сучкова	Надежда	Валерьевна

Таблица 4.5 - Экипажи (2НФ)

Код экипажа	Группа допуска
1	1
2	4

Атрибуты «Код должности», «Название должности», «Оклад», «Премия», «Итого» транзитивно зависят от составного ключа.

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

Преобразуем ER- диаграмму в схему базы данных.

Рис. 1

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

Физическое проектирование базы данных аэропорта проходит в СУБД Microsoft Access.

Создаются таблицы.

Таблица «Самолёты» содержит технические характеристики самолётов.

Рис. 2

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

Таблица «Пилоты» содержит личные данные всех пилотов аэропорта.

Рис. 4

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

Рис. 5

Рис. 6. Таблица «Вылеты»

Таблица «Кассиры» содержит сведения о кассирах, работающих в аэропорту.

Рис. 7.

Рис. 8. Таблица «Должности»

Рис. 9. Таблица «Продажа»

Создаются формы.

Рис. 10. Форма «Главная кнопочная форма»

Рис. 11. Форма «Вылеты»

Рис. 12. Форма «Продажа билетов»

Рис. 13. Форма «Маршруты на день»

Создаются запросы.

Рис. 14. Запрос «Выборка по экипажам»

Рис. 15. Запрос «Расписание»

Рис. 16. Запрос на выборку «Продажа билетов»

Создаются отчеты.

Рис. 17. «Отчет по зарплате»

Рис. 18. Отчет «Расписание»

Рис. 19. Отчет «Билеты»

Заключение

программный запрос кнопочный инфологический

В процессе проектирования реляционной БД аэропорта были изучены материалы, позволяющие описывать предметную информационную систему с помощью ЯИМ, ER-диаграмм, изучены принципы построения инфологической модели и реляционных отношений удовлетворяющие 1НФ, 2НФ, 3НФ, а также описание отношений и БД в целом с ограничением целостности.

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

1. Ильин В.Е., Беляев В.В. «Российская современная авиация» - М.: АСТ, «Астрель», 2001.

2. Карпов Б.В. Microsoft Access 2000 Справочник.-1-е изд. - М.: Питер, 2000. - 416с.

3. Синева Н.Ф. Создание реляционных баз данных в MS Access. -1-е изд. - Саратов: Копипринтер СГТУ, 1996. - 40с.

Размещено на Allbest.ru