Проектирование реляционной базы данных

Министерство РФ по связи и информатизации Поволжский государственный университет телекоммуникаций и информатики КУРСОВАЯ РАБОТА ПО ДИСЦИПЛИНЕ БАЗЫ ДАННЫХ На тему

«Проектирование реляционной базы данных»

Студент группы 71Э Ильмукова О. П Самара 2010 г.

Задание с указанием номера варианта Вариант 25 — Агентство по продаже авиабилетов Агентство занимается продажей авиабилетов на различные рейсы, ведет учет проданных билетов и учет пассажиров, купивших билеты.

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

В системе должен осуществляться поиск следующей информации:

— номер рейсов (номер рейса, тип самолета, пункт отправления, пункт назначения, дата вылета, время вылета, время полета, цена билета);

— информация о свободных местах на рейс (номер рейса), дата вылета, общее количество мест, количество свободных мест);

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

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

Программные средства являются непосредственной производительной силой, так как от них в ряде случаев зависят эффективность промышленного производства и качество продукции, создаваемой в технологическом процессе с применением ЭВМ. Характеристики программ влияют на экономические показатели предприятий и отраслей, так как все больше изменяют технологический и технический уровни производств и средств автоматизации. Они определяют технические возможности роботов, АСУ, обеспечивают решение разнообразных функциональных задач обработки информации и управления объектами. Их качество и функциональные возможности интенсивно воздействуют на качественное преобразование промышленного производства и инженерного труда. В то же время они наиболее гибкая и модернизируемая часть систем, обеспечивающая относительно легкую адаптацию к изменяющимся условиям в процессе развития техники и к особенностям конкретного применения.

В настоящее время в различных крупных организациях широко применяются автоматизированные информационные системы (АИС).

Цель курсового проектирования — применение на практике знаний, полученных в процессе изучения курса «Базы данных», и приобретение практических навыков при проектировании и создания информационных систем (ИС), основанных на базах данных.

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

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

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

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

· один пассажир может летать на нескольких самолетах;

· один самолет может вмещать несколько пассажиров;

· по предварительной записи один пассажир может забронировать один билет;

· один самолет может летать по нескольким рейсам;

· один рейс имеет один пункт назначения;

· скидки могут иметь несколько билетов;

· один билет может иметь одну скидку.

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

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

· РЕЙС. Атрибуты — № рейса, пункт отправления, пункт назначения, пассажир, дата вылета, время вылета, дата прибытия, время прибытия, самолет, кол-во мест общих, кол-во мест свободных.

· ПАССАЖИР. Атрибуты — ФИО пассажира, документ, дата вылета, номер рейса.

· БИЛЕТЫ. Атрибуты — рейс, класс, место, стоимость билета, скидка, продан.

· СКИДКИ. Атрибуты — название, величина, информация.

· САМОЛЕТЫ. Атрибуты — тип, информация;

· ПУНКТ. Атрибуты — пункт отправления, пункт назначения.

Каждый пункт этого списка описывает отдельное свойство или атрибут рассматриваемой сущности и является потенциальным столбцом в БД.

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

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

· администрация;

· кассиры;

· пассажиры;

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

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

· ведение БД (запись, чтение, модификация, удаление в архив);

· обеспечение логической непротиворечивости БД;

· обеспечение защиты данных от несанкционированного или случайного доступа (определение прав доступа);

· реализация наиболее часто встречающихся запросов в готовом виде;

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

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

· расписание рейсов (номер рейса, тип самолета, пункт назначения, дата вылета, время вылета, цена билета);

· продажа билетов;

· информация о пассажирах;

· уменьшение количества мест;

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

В наших отношениях не хватает атрибутов, по которым можно однозначно определять записи, нет очевидных кандидатов в первичные ключи, поэтому введем в отношение РЕЙС атрибут ID рейса, в отношение ПАССАЖИР — атрибут ID пассажира, в отношение ПУНКТ — атрибут ID пункта, в отношение САМОЛЕТ — атрибут ID самолета, в отношение, БИЛЕТ атрибут № билета, в отношение СКИДКА — атрибут ID скидки. Такие атрибуты называются суррогатными ключами.

В итоге мы получили следующую схему отношений:

Пункты (ID, Название, Информация);

Самолеты (ID, Тип, Информация);

Пассажир (ID, Фамилия, Имя, Отчество, Вид документа, Серия, Номер, Номер рейса, Дата вылета);

Скидки (ID, Название, Величина, Информация);

Рейсы (ID, N рейса, Пункт отправления, Пункт назначения, Пассажир, Дата вылета, Время вылета, Дата прибытия, Время прибытия, Самолет, Кол-во мест общее, Кол-во мест свободных);

Билеты (N билета, Рейс, Класс, Место, Стоимость билета, Скидка, Продан).

Курсивом отмечены внешние ключи отношений.

Рис. 1. Диаграмма сущность-связь БД Аэропорт

Рис. 2. Уточненная диаграмма сущность-связь БД Аэропорт

После определения первичных ключей необходимо определить связи между сущностями. Пункт назначения может принимать несколько рейсов, в то же время один рейс следует в один пункт назначения, следовательно, между объектами ПУНКТ и РЕЙС связь М:1. Также один пассажир может лететь только одним рейсом, но он может быть упомянут во многих рейсах, следовательно между объектами ПАССАЖИР и РЕЙСЫ связь М:1. Один самолет может совершать полеты много раз, но в одном полете указывается только один рейс, следовательно, между объектами САМОЛЕТ и РЕЙС связь 1: М. Один билет может быть продан на несколько рейсов, но в одном билете может указываться только один рейс, следовательно между объектами РЕЙС и БИЛЕТ связь 1: М. Одна скидка может быть указана, но в одном билете может быть только одна скидка, следовательно между объектами БИЛЕТ и СКИДКИ связь 1: М. В таблице 1 приведено описание связей.

Таблица 1. Описание связей

Отношения приведены в табл. 2 — 6. В столбце «Динамичность» будем помечать буквой D изменяемые атрибуты (динамические), S — неизменяемые (статические). «Количество повторений» означает, сколько раз повторяется множественный атрибут. В столбце «Область возможных значений» указывается тип (C — символы, D — дата, N — число, L — логическое значение) и, возможно, диапазон изменения атрибута. В столбце «Вывод значений» указываются номера атрибутов, из которых можно получить данный атрибут. Выводимый атрибут можно не хранить. В столбце «Ограничение доступа» указано, кто имеет право изменять сведения.

Таблица 2. Описание атрибутов объекта РЕЙС

Таблица 3. Описание атрибутов объекта ПУНКТ

Таблица 4. Описание атрибутов объекта ПАССАЖИР

Таблица 5. Описание атрибутов объекта САМОЛЕТ

Таблица 6. Описание атрибутов объекта БИЛЕТ

Таблица 7. Описание атрибутов объекта СКИДКА

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

Для выполнения этого этапа необходимо знать (хотя бы ориентировочно) объем работы агентства по продаже авиабилетов, а также иметь представление о характере и интенсивности запросов.

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

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

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

· за день каждый кассир выдает примерно по двадцать билетов (по 0,3К);

· в аэропорту работает 50 специалистов (по 0,2К на каждого);

· аэропорт работает с 10 пилотами (по 0,2К);

· в день осуществляется порядка 10 полетов (по 0,1К);

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

М_Д=2*(50*0,2+250*(20*0,3)+10*0,2+250*10*0,1))=3524 К

где 250 — количество рабочих дней в году

Объем памяти будет увеличиваться на столько же при сохранении объема работы.

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

3. Выбор СУБД и других информационных средств

1. Выбор СУБД

Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (FoxPro, Clipper, MS Access и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными. Объём внешней и оперативной памяти, требующийся для функционирования СУБД, обычно указывается в сопроводительной документации.

Критерии, влияющие на выбор СУБД:

1. тип модели данных;

2. навыки и умения программиста;

3. наличие лицензионного ПО;

4. удобство и надежность СУБД в эксплуатации.

В курсовой работе выбрана СУБД MS Access.

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

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

4.1 Нормализация полученных отношений (до 4НФ)

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

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

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

Разработанная модель находится в третьей нормальной форме т.к.:

· атрибуты сущностей являются атомарными;

· каждый неключевой атрибут функционально полно зависит от первичного ключа;

· в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

Рис. 3. Окончательная ER-модель БД Аэропорт Таблица 8. Описание объектов предметной области

В таблице 9 приведено уточненное описание связей.

Таблица 9. Описание связей

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

Таблица 10. Описание атрибутов объекта РЕЙС

Таблица 11. Описание атрибутов объекта ПУНКТ

Таблица 12. Описание атрибутов объекта ПАССАЖИР

Таблица 13. Описание атрибутов объекта САМОЛЕТ

Таблица 14. Описание атрибутов объекта БИЛЕТ

Таблица 15. Описание атрибутов объекта СКИДКА

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

Ограничения целостности, которые не указаны в табл. 10 -15:

· значения всех числовых атрибутов — больше 0 (или null, если атрибут необязателен).

· значение атрибутов Дата вылета и Время вылета отношений ПАССАЖИР и РЕЙС должны находится во временном интервале, указанном в атрибутах.

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

4.3 Описание групп пользователей и прав доступа

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

1. Администратор БД: имеет доступ по записи ко всем данным, может изменять структуру базы данных и связи между отношениями. Устанавливает права доступа для всех остальных групп.

2. Представители администрации: имеют доступ по чтению ко всем данным и доступ по записи к отношению БИЛЕТЫ, ПАССАЖИР, РЕЙСЫ.

3. ПАССАЖИРЫ: имеет доступ по чтению к объекту РЕЙСЫ, БИЛЕТ.

4. Сотрудники, принимающие заявки на обслуживание: имеют доступ по записи к отношениям ПАССАЖИР и доступ по чтению к объекту РЕЙСЫ, БИЛЕТЫ.

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

На рисунке 4 представлена физическая модель базы данных.

Рис. 4. Физическая модель БД

6. Реализация проекта БД

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

Представим последовательность реализации в семь этапов.

1. Этап. Создание таблиц

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

Рис. 5. Таблица РЕЙСЫ в режиме Конструктора.

Аналогичным образом были созданы остальные таблицы Базы Данных.

2 Этап. Схема данных

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

Рис. 6. Схема данных реализуемого проекта

MS Access 2003 также позволяет просматривать сведения о зависимостях между объектами БД. Просмотр списка объектов, использующих указанный объект, помогает осуществлять поддержку БД и предотвращать ошибки, связанные с потерей источников записей. Реализована возможность просматривать объекты, зависящие от данного объекта, а также объекты, от которых зависит он. Также с помощью анализа зависимостей можно найти и локализовать возможные ошибки схемы данных.

Этап 3 Создание запросов

Необходимо реализовать запрос — список пассажиров с указанием номера рейса и датой вылета

Рис. 7. Запрос в режиме Конструктора.

Этап 4. Создание отчетов

Отчет является эффективным средством представления данных в печатном формате. Имея возможность управляя размером и внешним видом всех элементов отчета, пользователь может отобразить сведения желаемым образом.

Пример отчета для получения расписания полетов всех самолетов, основанный на таблице РЕЙСЫ предоставлен на Рис. 8. и 9.

база данные бронирование билет

Рис. 8. Отчет в режиме Конструктора

Рис. 9. Фрагмент отчета в режиме просмотра

Этап 5 Создание форм

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

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

Рис. 9. Пример экранной формы Рейсы.

Этап 6. Создание кнопочной формы

Принципы создания и редактирования кнопочных форм подробно описаны в справочной системе MS Access.

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

Пример кнопочной форм БД «Продажа Авиабилетов» представлено на Рис. 10.

Рис. 10 Кнопочная форма

Этап 7. Разграничение доступа

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

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

Все средства необходимые для работы с учетными записями, группами пользователей, их паролями и правами доступа находятся в меню «Сервис» — «Защита».

Заключение

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

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

Реализация системы проводилась с использованием СУБД MS Access 2003. При написании программы было уделено внимание удобству работы пользователя и построению дружественного интерфейса.

1. Вендров А. М. CASEтехнологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 2000

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2000. 350 с.

3. Гарнаев А. Ю. Excel, VBA в экономике и финансах. СПб.: БХВ-Петербург, 2002. 816с.

4. Леоненков А. В. Самоучитель UML. М.: «Метатехнология», 2001

5. Липаев В. В Управление разработкой программных средств. Методы, стандарты, технология. — М.: Финансы и статистика, 1993.

6. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: Финансы и статистика, 2000.

7. Липаев В. В. Документирование и управление конфигурацией программных средств (методы и стандарты). М.: СИНТЕГ, 1998.

8. Бугорский В. Н., Фомин В. И. Информационные системы в экономике: основы информационного бизнеса. Учебное пособие СПб.: СПБГИЭА, 1999.

9. Калянов Г. Н. Теория и практика реорганизации бизнес-процессов. М.: СИНТЕГ, 2000.

10. Каpатыгин С. Базы данных: простейшие средства обработки информации. Системы управления базами данных. М.: ABF, 1995.