Реферат База данных справочной системы аэропорта
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ УЛЬЯНОВСКОЕ ВЫСШЕЕ АВИАЦИОННОЕ УЧИЛИЩЕ ГРАЖДАНСКОЙ АВИАЦИИ (ИНСТИТУТ)
КАФЕДРА ИНФОРМАТИКИ
КУРСОВАЯ РАБОТА
Дисциплина «Информационное обеспечение, база данных»
Тема: «База данных справочной системы аэропорта»
Выполнил
Руководитель:
Работа защищена _____________с оценкой____________________________
(дата)
__________________
(подпись)
Ульяновск 2010
Реферат
Пояснительная записка
Авиационные справочные системы являются предприятием, которое ежедневно работает с большим числом клиентов.
Основной целью курсового проектирования является создание базы данных, которая позволит структурировать те огромные объемы информации, которые накапливаются в организации, и тем самым существенно облегчит работу и доступ к данным практически всем звеньям, участвующим в работе авиационных справочных систем. Удобный интерфейс обеспечивает возможность использования данной базы не только специалистами, но и людьми, не имеющими практически никакого опыта работы с подобными приложениями. Создана база данных для использования пассажирами авиационных справочных систем.
Также можно выделить следующие цели, которые преследует созданная база данных:
1.Облегчение работы операторов за счет автоматического формирования билета с последующим занесением его в базу
2.Ведение постоянного учета количества свободных, занятых и забронированных мест
3.Выдачу информации по конкретному рейсу
Содержание
Введение
1. Анализ предметной области (ПО)………………………………………….
2. Описание документооборота в ПО…………….…………………………..
3. Информационные потребности пользователей……………………………
4. Описание основных объектов ПО………………………………………….
5. Разработка инфологической модели ПО…………………………………..
6. Нормализация базы данных…………………………………………………
7. Выбор и обоснование СУБД для реализации базы данных………………
8. Разработка даталогической модели данных………………………………..
9. Анализ ограничений целостности в БД и разработка методов их поддержания…………………………………………………………………….
10. Разработка структуры интерфейса пользователя…………………………
11. Алгоритм работы программного комплекса и его состав………………..
Заключение………………………………………………………………………
Список используемой литературы…………………………………………….
1.Анализ предметной области.
Поставлена задача спроектировать и разработать базу данных автоматизации учета пассажиров. Имеется авиакомпания (АК), в которой хранятся данные обо всех пассажирах и сотрудниках АК.
База данных должна удовлетворять следующим требованиям:
-БД должна отражать всю информацию о АК , в частности о сотрудниках и пассажирах;
- В БД должна быть справочная информация для пассажиров
-Должна быть возможность вносить изменения в данные и пополнения новыми данными;
- В разработанной БД должны присутствовать функции поиска, выполнение определенных запросов, печати отчетов.
Ограничения:
-Пассажиру запрещается давать конфиденциальную информации о сотрудниках АК и АК в целом.
Функциональная структура организации
| Должность | Функциональная область |
| Генеральный директор | Контроль работы авиакасс и всей компании в целом. |
| Зам. Генерального директора аэропорта | Выполнение обязанностей и поручений директора в его отсутствие. |
| Старший оператор | Проверка билетов, проверка соблюдения правил продажи билетов, контроль кассиров |
| Главный бухгалтер | Финансовое планирование деятельности авиакасс |
| Бухгалтерия | Подсчет кассы, учетные операции фин-хоз деятельности |
| Кассир | Продажа билетов |
2.Описание документооборота в предметной области.
-Сбор информации о пассажире
-Сбор нужной информации о необходимом билете
-Обработка собранной информации о пассажире
-Обработка собранной информации о пассажире
-Формирование выходной документации
Отчетность-это внутренняя информация на основе которой ведутся все расчеты и выводы в работе:
-Список пассажиров с указанием фамилии, имени ,отчества; даты рождения; адреса; контактного телефона; страны; места жительства; багажа (вес, кг)
-Список пассажиров за день с указанием заказанных билетов
2.1.Характеристика входной информации
Вся полученная информация:
-Данные о пассажире (фамилии, имени ,отчества, даты рождения, адреса, контактного телефона, страны, места жительства, багажа (вес, кг) )
-Документы(паспорт и другие документы(если нужны))
-Информация о выборе нужного билета
Характеристика выходной информации:
Один результирующий документ – выданный билет
В неё входит:
- Ф.И.О. пассажира
-№ билета
-Класс
-Цена
-Скидка
-Бронирование
-№ рейса
3. Информационные потребности пользователей
Как правило, пассажир не знает о наличии свободных мест в нужное время на рейс. Для решения этой задачи следует разработать систему запросов. Запросы бывают регламентированные и непредусмотренные.
К регламентированным в данном случае следует отнести:
- просмотр данных о конкретном рейсе для покупки авиабилета;
- поиск нужного рейса;
- просмотр всех зарегистрированных пассажиров на рейс.
К непредусмотренным:
- поиск свободных мест на рейсе по причине отказа лететь именно этим рейсом пассажиров
- Наиболее часто выполняются регламентированные запросы, такие как просмотр данных о конкретном рейсе.
Основные классы пользователей для разрабатываемой базы данных это регистраторы, администрация АК, пассажиры.
Информационные потребности регистратора включают в себя, поиск рейсов, на которые можно забронировать(купить) билет, для того чтобы лучше ориентироваться и отвечать на часто задаваемые вопросы, так же просмотр всех имеющихся рейсов и пассажиров АК, просмотр информации о конкретном рейсе или пассажире. Информационные потребности пассажира могут быть связаны с поиском информации о ранее забронированных рейсов.
4. Описание основных объектов предметной области
На основе анализа информационных потребностей пользователей произведем отбор основных объектов. Их описание представим в виде Таблицы 1
| № п.п | Наименование объекта | Краткое описание |
| 1 | Пассажир | Физическое или юридическое лицо, осуществляющее оплату деньгами и являющееся приобретателем товара или услуги |
| 2 | Билет | Специально оборудованное стационарное здание или его часть, предназначенное для продажи товаров покупателям. |
| 3 | Авиакомпания | Лицо или учреждение, занимающееся поставками каких-либо товаров |
Таблица 1. Список объектов предметной области
После описания основных объектов предметной области приведем отбор атрибутов для каждого объекта. Отберем только те атрибуты, которые необходимы для формирования ответов на регламентированные и непредусмотренные запросы. Для каждого объекта приведем таблицы списка его атрибутов соответственно: Таблица 2, Таблица 3, Таблица 4, Таблица 5, Таблица 6
Таблица 2. Список атрибутов
| Пассажир | ||
| №п.п. | Наименование атрибута | Краткое описание |
| 1. | IDПассажира | Идентификационный номер пассажира |
| 2. | Фамилия | Фамилия |
| 3. | Имя | Имя |
| 4. | Отчество | Отчество |
| 5. | Дата рождения | Дата рождения |
| | Контактный телефон | Телефон для связи |
| | Страна | Страна, в которой проживает пассажир |
| | Место жительства | Адрес |
| 6. | Багаж (вес, кг) | Багаж пассажира |
Таблица 3. Список атрибутов
| Билет | ||
| №п.п. | Наименование атрибута | Краткое описание |
| 1 | № билета | Номер билета |
| 2 | Класс | Класс, которым летит пассажир |
| 3 | Цена | Цена билета |
| 4 | Скидка | Скидки (если есть) |
| 5 | Бронирование | Бронирование билета на рейс (если есть) |
| 6 | IDПассажира | Идентификационный номер пассажира |
| 7 | № рейса | Идентификационный номер рейса |
Таблица 4. Список атрибутов
| Рейс | ||
| №п.п. | Наименование атрибута | Краткое описание |
| 1 | № рейса | Номер рейса |
| 2 | Дата вылета | Дата вылета ВС |
| 3 | Время вылета | Время вылета ВС |
| 4 | Аэропорт вылета | Аэропорт вылета |
| 5 | Пункт назначения | Маршрут |
| 6 | Бортовой номер ВС | Бортовой номер ВС |
Таблица 5. Список атрибутов
| ВС | ||
| №п.п. | Наименование атрибута | Краткое описание |
| 1 | Бортовой номер ВС | Бортовой номер ВС |
| 2 | Тип ВС | Модель ВС |
| 3 | Дата выпуска | Дата изготовления В |
| 4 | Пассажирских мест | Кол-во пассажирских мест в самолете |
| 5 | Мест экипажа | Кол-во мест экипажа |
| 6 | IDАК | Идентификационный номер АК |
Таблица 6. Список атрибутов
| АК | ||
| №п.п. | Наименование атрибута | Краткое описание |
| 1 | IDАК | Идентификационный номер АК |
| 2 | Наименование | Название АК |
| 3 | Начальник АК | Фамилия начальника АК |
| 4 | Ген Директор АК | Фамилия ген директора АК |
| 5 | Адрес АК | Место нахождения АК |
| 6 | Контактный телефон | Телефон для связи с АК |
На основе анализа информационных потребностей выявим связи между объектами. Для выявления связей данные представим в Таблице 7.
Таблица 7.Список связей предметной области
| № п.п. | Наименование | Объекты, участвующие в связи | Краткое описание |
| 1. | 1 ко многим | Пассажир, билет | Один пассажир может купить или забронировать несколько билетов |
| 2. | 1 ко многим | Рейс, билет | На один рейс может быть много билетов |
| 3. | 1 ко многим | ВС, рейс | Одно ВС может летать разными рейсами |
| 4. | 1 ко многим | АК, ВС | Одна АК может иметь несколько типов ВС |
6.Нормализация базы данных
Покажем зависимости для первой нормальной формы
Пассажир
IDПассажира в данной сущности является ключевым атрибутом.
Билет
IDПассажира и № рейса являются внешними ключами
Рейс
№ рейса
№ рейса в данной сущности является ключевым атрибутом
Бортовой номер ВС является внешним ключом.
ВС
Бортовой номер ВС в данной сущности является ключевым атрибутом
IDАК является внешним ключом.
АК
IDАК в данной сущности является ключевым атрибутом.
Вторая нормальная форма
Покажем зависимости для второй нормальной формы
Пассажир
IDПассажира в данной сущности является ключевым атрибутом.
Билет
IDПассажира и № рейса являются внешними ключами
Рейс
№ рейса в данной сущности является ключевым атрибутом
Бортовой номер ВС и ID Пункт назначения являются внешними ключами.
Пункт назначения
ID Пункт назначения в данной сущности является ключевым атрибутом.
ВС
Бортовой номер ВС в данной сущности является ключевым атрибутом
IDАК является внешним ключом.
АК
IDАК в данной сущности является ключевым атрибутом.
Третья нормальная форма
Покажем зависимости для третьей нормальной формы
Пассажир
IDПассажира в данной сущности является ключевым атрибутом.
Билет
IDПассажира и № рейса являются внешними ключами
Рейс
№ рейса в данной сущности является ключевым атрибутом
ID Пункт назначения является внешним ключом.
Элемент расписания
Бортовой номер ВС и № рейса являются внешними ключами.
Пункт назначения
ID Пункт назначения в данной сущности является ключевым атрибутом.
ВС
Бортовой номер ВС в данной сущности является ключевым атрибутом
IDАК является внешним ключом.
АК
IDАК в данной сущности является ключевым атрибутом.
7. Выбор и обоснование СУБД для реализации базы данных
В наш век информационных технологий программное обеспечение для создания и управления базами данных стало одним из базовых элементов IT-инфраструктуры. Действительно, базы данных сейчас используются практически повсеместно например информационные порталы (архивы музыки и фильмов).
Для создания баз данных и работы с ними используют различные СУБД. Базы данных различаются по своей структуре: дореляционные (на инвертированных списках, иерархические системы и сетевые СУБД), реляционные и постреляционные (например, объектные).
Локальные СУБД
Локальными или настольными называют СУБД такие как Access, Paradox. В них уже есть свой формат данных, который учитывает параллельное выполнение операций, возможность доступа к БД нескольких пользователей.
Недостатки становятся очевидными не сразу, а по мере увеличения количества данных и числа пользователей. К недостаткам можно отнести: снижение производительности и сбои, неэффективное расходование сетевого трафика и низкая эффективность при большом количестве пользователей. Существует решение этой проблемы при помощи распространенной технологии "клиент-сервер"[1].
Технология «клиент-сервер».
Принцип централизации хранения и обработки данных лежит в основе архитектуры "клиент-сервер". При использовании этой технологии вся работа по обработке данных полностью перекладывается на сервер. Машина-клиент посылает запросы, а сервер их выполняет и посылает ответы клиенту. При таком подходе разгружается сеть и пропадает необходимость использовать мощные рабочие станции. Серверные СУБД обладают расширенными возможностями управления привилегиями пользователей. Кроме того, современные серверные СУБД предоставляют много возможностей резервного копирования и оптимизации запросов. Поддерживают параллельную обработку запросов, а также предоставляют возможность параллельной обработки данных сразу несколькими процессорами (при использовании в качестве сервера БД многопроцессорной системы).
Рынок корпоративных серверных СУБД представлен Oracle, MS SQL, Sybase и InterBase
MS
SQL
Первая версия была разработана совместно с Sybase в 1988 году и предназначалась только для платформы OS/2. Следующие версии этого продукты были созданы для NT-based систем и тесно интегрированы с ОС.
Oracle
Oracle была первой коммерческой реляционной СУБД, поддерживающей язык SQL, который в последствии стал стандартом. Первая версия продукта появилась на свет в 1979 году. В наши дни компания является лидером рынка производителей коммерческих СУБД и, как написано на официальном сайте, крупнейшим в мире поставщиком корпоративного программного обеспечения.
InterBase
Продукт компании Borland Inc. Довольно компактная, устойчивая и производительная СУБД, способная работать на различных ОС. Положительная сторона системы достаточно проста при разработке БД. Так как в другие пакеты этой фирмы (например, Delphi) встроены весьма удобные средства для разработки приложений на базе Interbase. Продукт стал известным вследствие того, что долгое время распространялся бесплатно вместе со средствами разработки. В настоящее время продукт платный.
Sybase
Изначально компания разрабатывала серверную СУБД совместно с Microsoft. В 1994 году компании разошлись и стали разрабатывать свои программные продукты независимо друг от друга. В результате у Sybase получился продукт под названием Adaptive Server Enterprise. Продукт существует под разные операционные системы и предназначен для применения на крупных предприятиях. Существует еще одна линия серверных продуктов Sybase, которая ведет свое начало от СУБД Watcom SQL Anywhere. Этот продукт называется SQL Anywhere Studio, отличается своей компактностью и простотой администрирования. Предназначен в основном для обслуживания небольших групп пользователей. Также существуют версии для применения в мобильных устройствах.
Бесплатные СУБД
Бесплатных СУБД тоже существует немало, наиболее распространенными являются MySQL и PostgreSQL. Обе СУБД довольно динамично развиваются и повсеместно используются. Обе системы очень стабильны, гибки и производительны. У каждой есть свои плюсы и минусы.
MySQL – быстрая, но немного ограниченная СУБД. Хорошо подходит для проектов, не требующих сложных баз (например, для web-проектов).
PostgreSQL – мощная и тяжелая система, отвечающая всем современным стандартам СУБД. Больше подходит для серьезных проектов, требующих сложных баз данных. По скорости работы PostgreSQL уступает MySQL. PostgreSQL - это реляционно-объектная СУБД, в которой есть некоторые расширения для работы с таблицами, на которые можно легко отображать иерархии объектов.
Для реализации информационной системы в данном курсовом проекте будет использована СУБД Microsoft Access, так как выбранный программный продукт сможет полностью удовлетворять как текущие, так и будущие потребности пользователей. К тому же СУБД Microsoft Access рассчитана для хранения не очень больших объемов информации. Нецелесообразно, к примеру, использовать такую СУБД как Oracle для выполнения данного проекта, так как она рассчитана на крупные предприятия с большим количеством пользователей и крупными объемами информации.
8. Разработка даталогической модели базы данных
Для каждого объекта предметной области приведем схему отношений с указанием всех ее атрибутов и их характеристик, описание первичного и внешнего ключей. Данные занесем в Таблицу 8, 9, 10, 11, 12, 13, 14.
Таблица 8. Пассажир
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| IDПассажира | Числовой (10) | Является первичным ключом | |
| Фамилия | Текстовый (20) | | |
| Имя | Текстовый (20) | | |
| Отчество | Текстовый (20) | | |
| Дата рождения | Дата/время | | |
| Контактный телефон | Числовой (11) | | |
| Страна | Текстовый (20) | | |
| Место жительства | Текстовый (100) | | |
| Багаж (вес, кг) | Числовой (10) | | |
Таблица 9. Билет
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| № билета | Числовой (10) | Является первичным ключом | |
| Класс | Текстовый (20) | | |
| Цена | Денежный | | |
| Скидка | Числовой (3) | | |
| Бронирование | Текстовый (20) | | |
| IDПассажира | Числовой (10) | | Является внешним ключом |
| № рейса | Числовой (10) | | Является внешним ключом |
Таблица 10. Рейс
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| № рейса | Числовой (10) | Является первичным ключом | |
| Аэропорт вылета | Текстовый (200) | | |
| IDПункт назначения | Числовой (10) | | Является внешним ключом |
Таблица 11. Элемент расписания
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| Дата вылета | Дата/время (10) | | |
| Время вылета | Дата/время (10) | | |
| Бортовой номер ВС | Числовой (10) | | Является внешним ключом |
| № рейса | Числовой (10) | | Является внешним ключом |
Таблица 12. ВС
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| Бортовой номер ВС | Числовой (10) | Является первичным ключом | |
| Тип ВС | Числовой (10) | | |
| Дата выпуска | Дата/время (10) | | |
| Пассажирских мест | Числовой (5) | | |
| Мест экипажа | Числовой (2) | | |
| IDАК | Числовой (10) | | Является внешним ключом |
Таблица 13. Пункт назначения
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| IDПункт назначения | Числовой (10) | Является первичным ключом | |
| Аэропорт назначения | Текстовый (20) | | |
| Страна | Текстовый (100) | | |
| Город | Текстовый (20) | | |
| Расстояние (км) | Числовой (20) | | |
Таблица 14. АК
| Имя поля | Тип данных | Первичный ключ | Внешний ключ |
| IDАК | Числовой (10) | Является первичным ключом | |
| Наименование | Текстовый (30) | | |
| Начальник АК | Текстовый (20) | | |
| Ген Директор АК | Текстовый (20) | | |
| Контактный телефон | Числовой (6) | | |
| Адрес АК | Текстовый (200) | | |
9. Разработка структуры интерфейса пользователя
Для создания интерфейса пользователя можно воспользоваться одной из множества существующих сред разработки, в данном курсовом проекте будем использовать среду разработки MS Visual Basic, так как она считается хорошим средством для разработки приложений баз данных и вообще для компонентного способа создания программ, работающих под управлением операционных систем семейства Microsoft Windows. У данной среды существует ряд достоинств таких как:
· высокая скорость создания приложений с графическим интерфейсом для MS Windows;
· простой синтаксис, позволяющий очень быстро освоить язык;
· возможность как компиляции в машинный код, так и интерпретации во время отладки.
На рисунке приведена структура интерфейса пользователя
10
.
Анализ ограничений целостности в БД и разработка методов их поддержания
Понятие целостности
Одним из основополагающих понятий в технологии баз данных является понятие целостности. В реляционной модели объекты реального мира представлены в виде совокупности взаимосвязанных отношений. Под целостностью будем понимать соответствие информационной модели предметной области, хранимой в базе данных, объектам реального мира и их взаимосвязям в каждый момент времени. Любое изменение в предметной области, значимое для построенной модели, должно отражаться в базе данных, и при этом должна сохраняться однозначная интерпретация информационной модели в терминах предметной области.
Только существенные или значимые изменения предметной области должны отслеживаться в информационной модели. Действительно, модель всегда представляет собой некоторое упрощение реального объекта, в модели мы отражаем только то, что нам важно для решения конкретного набора задач. Именно поэтому в информационной системе "Справочная система аэропорта" мы, например, не отразили место хранения билетов, потому что мы не ставили задачу автоматической адресации места в хранилище. И в этом случае любое перемещение билета с одного места на другое не будет отражено в модели, это перемещение несущественно для наших задач. С другой стороны, процесс изменения расписания рейсов или процесс возврата билетов в аэропорт для нас важен, и мы должны его отслеживать в соответствии с изменениями в реальной предметной области. И с этой точки зрения наличие у конкретного билета указателя на его отсутствие в кассе аэропорта и одновременное отсутствие записи о конкретном пассажире купившем этот билет является противоречием, такого быть не должно. И в модели данных должны быть предусмотрены средства и методы, которые позволят нам обеспечивать динамическое отслеживание в базе данных согласованных действий, связанных с согласованным изменением информации.
Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 аспекта.
Во-первых, это поддержка структурной целостности, которая трактуется как то, что реляционная СУБД должна допускать работу только с однородными структурами данных типа "реляционное отношение". При этом понятие "реляционного отношения" должно удовлетворять всем ограничениям, накладываемым на него в классической теории реляционной БД - отсутствие дубликатов кортежей, соответственно обязательное наличие первичного ключа, отсутствие понятия упорядоченности кортежей.
Во-вторых, это поддержка языковой целостности, которая состоит в том, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту.
Именно поэтому доступ к информации, хранимой в базе данных, и любые изменения этой информации могут быть выполнены только с использованием операторов языка SQL.
В-третьих, это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:
1. кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ними.
2. кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ними, при этом на месте ключа родительского отношения ставится неопределенное Null значение.
Ссылочная целостность обеспечивает поддержку непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления или удаления.
Кроме указанных ограничений целостности, которые в общем виде не определяют семантику БД, вводится понятие семантической поддержки целостности.
Семантическая поддержка целостности
Структурная, языковая и ссылочная целостность определяют правила работы СУБД с реляционными структурами данных. Требования поддержки этих трех видов целостности говорят о том, что каждая СУБД должна уметь это делать, а разработчики должны это учитывать при построении баз данных с использованием реляционной модели. И эти требования поддержки целостности достаточно абстрактны, они определяют допустимую форму представления и обработки информации в реляционных базах данных. Но с другой стороны, эти аспекты никак не касаются содержания базы данных. Для определения некоторых ограничений, которые связаны с содержанием базы данных, требуются другие методы. Именно эти методы и сведены в поддержку семантической целостности.
· Рассмотрим конкретный пример. То, что мы можем построить схему базы данных или ее концептуальную модель только из совокупности нормализованных таблиц, определяет структурную целостность. И мы построили нашу схему справочной системы аэропорта из семи взаимосвязанных отношений
Принципы семантической поддержки целостности как раз и позволяют обеспечить автоматическое выполнение тех условий, которые перечислены ранее.
Семантическая поддержка может быть обеспечена двумя путями: декларативным и процедурным путем. Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего "бизнес правилами" (Business Rules) или декларативными ограничениями целостности.
Выделяются следующие виды декларативных ограничений целостности:
· Ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов.
· Ограничения целостности, задаваемые на уровне доменов, при поддержке доменной структуры.
· Ограничения целостности, задаваемые на уровне отношения.
· Ограничения целостности, задаваемые на уровне связи между отношениями.
Чтобы обеспечить целостность, работа с данными должна производиться с учетом ниже перечисленных правил:
· Невозможно ввести в связанное поле подчиненной таблицы значение, отсутствующее в связанном поле главной таблицы. Однако можно ввести пустое значение, показывающее, что для данной записи связь отсутствует.
· Не допускается удаление записи из главной таблицы, если существуют связанные с ней записи в подчиненной таблице.
· Невозможно изменить значение ключевого поля в главной таблице, если существуют записи, связанные с данной таблицей.
Чтобы эти правила контролировались для конкретной связи, при ее создании следует установить флажок - Обеспечение целостности данных (Enforce Referential Integrity). Тогда любая попытка выполнить действие, нарушающее одно из перечисленных выше правил, приведет к выводу на экран предупреждения, а само действие выполнено не будет.
В представленном курсовом проекте во всех связях схемы отношений присутствует только один флажок это - Обеспечение целостности данных, такого условия достаточно, для того чтобы база данных нормально функционировала.
11.
|
Заключение
Разработанная в ходе выполнения курсового проекта база данных "Справочная система аэропорта", а также программа для работы с базой данных является актуальной на сегодняшний день и имеет практическую значимость. Она помогает в работе сотрудников АК по сбору данных, необходимых при выдачи информации, а также по сбору данных о самих пассажирах.
В результате выполнения данного курсовой работы были решены задачи, поставленные в начале работы. Была разработана структура базы данных; разработан интерфейс программы; в программу были включены функции поиска, выполнения различных запросов и отчетов. При этом были учтены все требования, выдвинутые в начале выполнения данной работы.
Разработанная программа устойчиво выполняет все свои функции, но теперь стоит задача сделать ее более совершенной и более расширенной.
Список используемой литературы
1. Михеева В., Харитонова И. Наиболее полное руководство Microsoft Access 2000 – СПб.: БВХ – Санкт-Петербург, 2000. – 1088с.:ил.
2. Э.Феддема Эффективная работа: Microsoft Access 2002. – СПб.: Питер, 2003. –944 с.: ил.
3.Т. Карпова – Базы данных: модели, разработка, реализация. Уч. пособие – СПб: Питер, 2001.
