База данных справочной системы аэропорта

Автор работы: Пользователь скрыл имя, 01 Февраля 2011 в 18:27, курсовая работа

Описание работы

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

Содержание работы

Введение
1. Анализ предметной области (ПО)
2. Описание документооборота в ПО
3. Информационные потребности пользователей
4. Описание основных объектов ПО
5. Разработка инфологической модели ПО
6. Нормализация базы данных
7. Выбор и обоснование СУБД для реализации базы данных
8. Разработка даталогической модели данных
9. Анализ ограничений целостности в БД и разработка методов их поддержания
10. Разработка структуры интерфейса пользователя
11. Алгоритм работы программного комплекса и его состав
Заключение
Список используемой литературы

Файлы: 1 файл

База данных справочной системы аэропорта.doc

— 277.50 Кб (Скачать файл)

     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 значение.

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

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

     Семантическая поддержка целостности

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

Информация о работе База данных справочной системы аэропорта