Е. П. Балакина Рекомендовано редакционно-издательским

Вид материала

Документы

Содержание Пример проектирования реляционной базы данных 1.2 Анализ информационных задач и круга пользователей системы 2.1 Преобразование ER–диаграммы в схему базы данных 2.2 Составление реляционных отношений Маршрут ключевым атрибутом является атрибут «маршрут», т.к. его значение является уникальным для авиакомпании. 2. Сущность Рейс Таблица 1. Схема отношения Маршрут Тип, длина Таблица 2. Схема отношения Рейс Тип, длина Таблица 3. Схема отношения Билет Тип, длина 2.3 Нормализация полученных отношений Таблица 4. Схема отношения Билет Тип, длина 2.4.3 Определение дополнительных ограничений целостности 2.5 Физическое проектирование БД SELECT Фамилия, ИО FROM Ticket.DB Список использованных источников Задание на курсововой проект 3 Список использованных источников 31 ... Полное содержание

Подобный материал:

• Учебно-методическое пособие Рекомендовано редакционно-издательским советом Академии, 3913.96kb.
• Общая и, 861.29kb.
• Методические указания к курсовой работе рекомендовано к изданию Редакционно-издательским, 380.48kb.
• Методические указания к курсовому и дипломному проектированию Москва 2007, 873.19kb.
• Л. С. Вечер «деловое общение в государственном аппарате» практикум, 3338.12kb.
• Методические указания к выполнению практических и лабораторных работ Москва 2010, 1520.41kb.
• А. С. Калмыкова Главный внештатный детский инфекционист, 1294.52kb.
• В. А. Журавлев профессор, доктор мед наук, член-корреспондент рамн, заведующий кафедрой, 540.06kb.
• 2: Становление основных современных концепций организационной культуры. Типология организационных, 919.38kb.
• Р. Н. Мищенко Рекомендовано к печати редакционно-издательским советом Стгма, 118.58kb.

ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

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

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

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

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

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

• По одному маршруту летает несколько рейсов.
  
• Билет пассажир может купить, если на рейс остались места.
  

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

• билет – номер, маршрут, рейс, дата и время отправления, дата продажи, паспорт и ФИО пассажира;
  
• пассажир – паспорт, ФИО и др.
  
• рейс – номер, маршрут, дата и время отлета, количество имеющихся билетов, максимальное количество билетов;
  
• маршрут – название маршрута.
  

ER–диаграмма компании приведена на рис. 1. На данной ER–диаграмме присутствуют связи один-ко-многим и один-к-одному. Такие связи легко реализуются средствами СУБД.

Если в полученной ER–диаграмме присутствует связь многие-ко-многим, то вводится специальная вспомогательная сущность, которая является соединением первичных ключей соответствующих сущностей. Таким образом разбиваются все связи типа n:m. Затем строится уточненная ER–диаграмма.




Рис.1. ER–диаграмма компании


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

Система создаётся для обслуживания следующих групп пользователей:

• администрация (дирекция);
  
• менеджеры;
  

Определим границы информационной поддержки пользователей:

1) Функциональные возможности:

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

2) Готовые запросы:

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

2 Логическое проектирование реляционной БД

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

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

Полученная схема реляционной базы данных (РБД) приведена на рис. 2. На схеме введены обозначения






Рис.2. Схема РБД, полученная из ER–диаграммы компании


На схеме (рис. 2) есть связь типа 1:1 –связь между БИЛЕТОМ и ПАССАЖИРОМ. Такие отношения следует объединять в одно.

Примечание: исключение для связи типа 1:1 составляют ситуации, когда для увеличения производительности системы в отдельную таблицу выделяются редко используемые данные большого объёма.

Связь типа 1:n (один-ко-многим) между отношениями реализуется через внешний ключ. Ключ вводится для того отношения, к которому осуществляется множественная связь [5].

Уточнённая схема РБД компании приведена на рис. 3.



Рис.3. Уточнённая схема РБД компании

2.2 Составление реляционных отношений

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

Примечание: суррогатный первичный ключ также может вводиться в тех случаях, когда потенциальный ключ имеет большой размер (например, длинная символьная строка) или является составным (не менее трёх атрибутов) [5].

1. Для сущности Маршрут ключевым атрибутом является атрибут «маршрут», т.к. его значение является уникальным для авиакомпании.

2. Сущность Рейс. Для нее уникальным атрибутом является «номер рейса» (его имя), поэтому в качестве уникального атрибута выбран именно он.

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

Отношения приведены в табл. 1-3. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной.

Таблица 1. Схема отношения Маршрут. (Way)


Таблица 2. Схема отношения Рейс (Race)


Таблица 3. Схема отношения Билет (Ticket)


2.3 Нормализация полученных отношений

1НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (один атрибут – один столбец) и разбить сложные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения.

Примечание. В реальных БД сложные атрибуты разбиваются на простые, если:

а) этого требует внешнее представление данных;

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

Разделим атрибуты Фамилия, имя, отчество на два атрибута Фамилия и Имя, отчество и Паспортные данные на атрибуты Номер паспорта (уникальный), Дата выдачи и Кем выдан.

2НФ. В отношении БИЛЕТ атрибуты Дата выдачи и Кем выдан не зависят от первичного ключа. Отношение не находится во 2НФ. Чтобы отношение находилось во 2 НФ нужно данное отношение разбить на два. Однако данное отношение было именно результатом слияния двух отношений (п.2.1).

В реальных базах данных после нормализации может проводиться денормализация. Она проводится с одной целью – повышение производительности БД.

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


Таблица 4. Схема отношения Билет (Ticket)

2.4.3 Определение дополнительных ограничений целостности

Перечислим ограничения целостности, которые не указаны в табл. 1–4.

«количество билетов» - не меньше нуля и не больше максимального количества билетов. Должен заполняться автоматически при покупке билета.

«максимальное количество билетов» не меньше нуля.

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

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

БД «Система продажи авиабилетов» разрабатывается в среде программирования Delphi и СУБД Paradox.

Отношение Маршрут. (Way)

Way.FieldDefs.Clear;

Way.FieldDefs.Add('Маршрут',ftString,30,true);

Way.IndexDefs.Clear;

Way.IndexDefs.Add('','Маршрут',[ixPrimary]);

Way.CreateTable;

Отношение Рейс (Race)

Race.FieldDefs.Clear;

Race.FieldDefs.Add('Рейс',ftInteger,0,true);

Race.FieldDefs.Add('Маршрут',ftString,30,true);

Race.FieldDefs.Add('Дата',ftDate,0,true);

Race.FieldDefs.Add('Время',ftTime,0,true);

Race.FieldDefs.Add('Кол-во билетов',ftInteger,0,true);

Race.FieldDefs.Add('Максим. билетов',ftInteger,0,true);

Race.IndexDefs.Clear;

Race.IndexDefs.Add('','Рейс',[ixPrimary]);

Race.IndexDefs.Add('indWay','Маршрут',[ixCaseInsensitive]);

Race.CreateTable;

Отношение Билет (Ticket)

Ticket.FieldDefs.Clear;

Ticket.FieldDefs.Add('Билет',ftAutoInc,0,true);

Ticket.FieldDefs.Add('Рейс',ftInteger,0,true);

Ticket.FieldDefs.Add('Фамилия',ftString,30,true);

Ticket.FieldDefs.Add('ИО',ftString,30,true);

Ticket.FieldDefs.Add('Паспорт',ftString,10,true);

Ticket.FieldDefs.Add(выдан',ftString,10,true);

Ticket.FieldDefs.Add('дата',ftString,10,true);

Ticket.IndexDefs.Clear;

Ticket.IndexDefs.Add('','Билет',[ixPrimary]);

Ticket.IndexDefs.Add('indRace','Рейс ',[ixCaseInsensitive]);

Ticket.CreateTable;

Приведём примеры нескольких готовых запросов:

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

SELECT Фамилия, ИО FROM Ticket.DB

WHERE РЕЙС= «ComboBox1.Text»¹

Показать маршрут и рейс, на который купил билет заданный пассажир:

SELECT Race.Маршрут, Ticket.Рейс, Ticket.Паспорт

FROM Race, Ticket

WHERE (Race.Рейс=Ticket.Рейс) and (Ticket.Фамилия= «ComboBox1.Text»)

Показать загруженность заданного рейса:

SELECT Race.Кол-во билетов, Race.DB.Максим. билетов

FROM Race

WHERE Рейс= «ComboBox1.Text»

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. И.П. Карпова Методические указания к курсовому проектированию по курсу "Базы данных". Московский государственный институт электроники и математики. (Технический университет). Кафедра вычислительных систем и сетей. 2004 г, 35 стр.
   

СОДЕРЖАНИЕ





Учебно-методическое издание


Васильева Марина Алексеевна

Балакина Екатерина Петровна


Методические указания к курсовому проектированию

по дисциплине

«Информационное обеспечение систем управления»


___________________________________________________________

Подписано к печ. Формат

Усл.- печ.л. Тираж

Заказ Изд. №68-07

___________________________________________________________


127994, Москва, ул. Образцова, 15. Типография МИИТа