Курсовая работа: Система управления базой данных

Содержание

Введение

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

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

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

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

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

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

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

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

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

3. Выбор СУБД

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

4.1 Ограничения целостности

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

6. Заключение

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

Введение

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

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

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

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

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

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

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

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

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

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

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

Для службы обеспечения важным является наличие следующих данных: количество посадочных мест, марка топлива, объём топливного бака, и марка автобуса.

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

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

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

Для услуг со стороны базы данных необходимо содержание в ней отношения – «Маршруты», обладающего следующими атрибутами: код маршрута, код рейса, дата отправления, время отправления, автобус, экипаж, количество проданных билетов.

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

— ввод данных;

— хранение данных;

— обновление данных;

— выборка данных;

— предоставление отчётов.

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

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

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

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

Анализ предметной области позволяет выделить сущности.

Стержневые сущности; Автобусы, Рейсы, Экипажи.

Обозначающие сущности: Автокомпании, Марка автобусов.

Ассоциативные сущности: Маршруты.

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

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

Рейсы (Номер рейса. Место отправления, Место назначения, Время в пути. Расстояние, Промежуточные посадки);

Автобусы (Регистрационный знак. Марка автобуса. Автокомпания);

Экипажи (№ экипажа. Группа допуска, Медицинское заключение);

Маршруты [Автобусы М, Рейсы N, Экипажи Р] (Код Маршрута, № рейса, Дата отправления, Время отправления, Регистрационный знак, № экипажа, Количество проданных билетов);

Состав экипажа (Код состава экипажа. Фамилия., Имя, Отчество, № экипажа) (Экипажи);

Автокомпании (Автокомпании, номер лицензии, Адрес офиса, Телефон главного менеджера) [Автобусы].

Марка автобусов (Марка автобуса , код автобусов, Количество мест, Марка топлива, Объём топливного бака) [Автобусы].

На основании анализа можно построить ER- диаграмму приложение А.

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

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

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

В связи с дальнейшим увеличением объёма обрабатываемой информации, в связи с быстрым развитием прикладных программных продуктов предоставляющих дополнительные услуги по обработке данных и их экспорта, импорта, целесообразно выбрать, несмотря на высокую цену данного программного продукта, Microsoft Access 2002, под управлением многопользовательской операционной системы Microsoft Windows 98.

От выбранного программного обеспечения выбираются параметры самой ЭВМ.

Процессор Pentium III или более быстрый, память 128 МБ ОЗУ. Требования к объему свободного места на жестком диске зависят от конфигурации. При выборочной установке может потребоваться больше или меньше места на диске. При стандартной установке требуется 170 МБ свободного места на жестком диске и дополнительно 115 МБ на диске, где установлена операционная система; пользователям, у которых не установлены продукты Windows 2000, Windows Me или Office 2000 Service Release 1 (SR-1), требуется дополнительно 50 МБ для обновления системных файлов. Необходимыми являются также дисковод для компакт-дисков,монитор Super VGA (800x600) или с более высоким разрешением с поддержкой 256 цветов, мышь Microsoft Mouse, Microsoft IntelliMouse или совместимое указательное устройство. При работе с мультимедиа и звуком для улучшенного отображения графики требуется видеоплата, поддерживающая ускорение графики, или процессор, поддерживающий набор команд MMX [1].

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

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

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

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

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

Число атрибутов отношения а=4. Число автокомпаний находящихся в БД автовокзала выбираем предположительно равным десяти единицам, т.е мощность отношения m=10. Данные сведены в таблицу 3.1

Таблица 3.1 - Автокомпании

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

D_{Автокомпания} =(30+4+50+20)*10=1040 байт.

Рассмотрим отношение «Маршрутов».

Число атрибутов отношения а=7. Число маршрутов в месяц принимаем равным 600, т.е. мощность отношения m=600. Данные сведены в таблицу 3.2

Таблица 3.2 - Маршруты

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

D_{Маршруты} =(4+4+8+8+4+4+4)*600=21600 байт

Рассмотрим отношение «Марки автобуса».

Число автобусов отношения а=6. Число марок автобусов выбирается равным 15, т.е. мощность отношения m=15. Данные сведены в таблицу 3.3

Таблица 3.3 – Марки автобусов

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

D_{Марки автобусов} =(20+4+4+10+4+4)*15=690 байт

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

Число атрибутов отношения а=6. Число рейсов принимаем равным 100, т.е. мощность отношения m=100. Данные сведены в таблицу 3.4

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

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

D_Рейсы =(4+20+20+8+4+20)*100=7600 байт

Рассмотрим отношение «Автобусы».

Число атрибутов отношения а=3. Число воздушных средств с присвоенным регистрационным знаком принимаем равным 50, т.е. мощность отношения m=50. Данные сведены в таблицу 3.5

Таблица 3.5- Автобусы

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

D_{Автобусы} =(4+20+30)*50=2700 байт

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

Число атрибутов отношения а=6. Мощность отношения принимаем равным 70, т.е. m=70. Данные сведены в таблицу 3.6

Таблица 3.6– Состав экипажа

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

D_{Состав экипажа} =(4+20+20+20+20+4)*70=6160 байт

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

Число атрибутов отношения а=3. Мощность отношения принимаем равным 55, т.е. m=55. Данные сведены в таблицу 3.7

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

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

D_{Экипажи} =(4+4+10)*55=990 байт

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

D=D_{Автокомпания} +D_{Маршруты} + D_{Марки автобусов} + D_Рейсы + D_{автобусы} + D_{Состав экипажа} + D_{Экипажи} =1040+21600+690+7600+2700+6160+990=40780 байт=40,78 Кбайт

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

Диспетчерская служба для каждого маршрута по определённому рейсу должна подобрать такую марку автобуса, которая удовлетворяет следующим требованиям:

— дальность маршрута автобуса должна быть больше или равна расстоянию между пунктами отправления и назначения соответствующего рейса;

— необходимо подобрать экипаж группа допуска, которого должна быть равна или выше соответствующей группе допуска самого автобуса,

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

Операция по выборке автобуса, экипажа для маршрута, по соответствующим условиям выполняется диспетчерами приблизительно от 20 раз за сутки. Для обеспечения операции по выборке реализован запрос на выборку - «Выборка автобуса—экипажа для маршрута».

Диспетчер из полученных результатов запроса анализирует ситуацию и в таблицу маршрутов заносит данные.

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

В связи с потенциальными проблемами и чрезвычайными ситуациями с автобусами существует необходимость оповещения соответствующих автокомпаний о внештатных ситуациях. Для такого рода информационной поддержки существует запрос на выборку – «соответствие Автобусы-Автокомпании».

3. Выбор СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автокомпании имеют уникальные названия. Автокомпания имеет единственный адрес, телефон главного менеджера и номер лицензии.

Марка автобуса однозначно описывает его технические характеристики код автобуса, такие как количество мест, дальность пути, марка топлива, объём топливного бака.

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

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

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

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

Код маршрута, № рейса, № экипажа, Код состава экипажа, Регистрационный знак, Марка автобуса, Название автокомпании.

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

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

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

Преобразуем ER- диаграмму в схему базы данных. Данное преобразование представлено в приложении Г.

4.1 Ограничения целостности

Опишем проектируемую базу данных на языке ЯИМ с указание ключей и других ограничений целостности.

ТАБЛИЦА Автокомпании (Обозначающая сущность, обозначает Автобусы)

ПЕРВИЧНЫЙ КЛЮЧ (Автокомпания)

ПОЛЯ (Автокомпания – Текст 50, Номер лицензии – Длинное целое, Адрес офиса – Текст 50, Тел. гл менеджера – Текст 50)

ОГРАНИЧЕНИЯ (Значения поля Автокомпания должны быть уникальны, при нарушении вывод сообщения «Такая автокомпания уже есть »)

ТАБЛИЦА Марки автобусов (Обозначающая сущность, обозначает автобусы)

ПЕРВИЧНЫЙ КЛЮЧ (Марка автобусов)

ПОЛЯ (Марка автобусов – Текст 50, Количество мест – Длинное целое, Дальность маршрута – Текст 50, Марка топлива – Текст 50, Объём топливного бака – Длинное целое, Группа допуска – Длинное целое)

ОГРАНИЧЕНИЯ (Значения поля Марка автобуса должны быть уникальны, при нарушении вывод сообщения «Такая марка автобуса уже есть»)

ТАБЛИЦА Автобусы (Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (Регистрационный знак)

ВНЕШНИЙ КЛЮЧ (Марка автобусов ИЗ Марки автобусов

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Марки автобусов КАСКАДИРУЮТСЯ

ОБНОВЛЕНИЯ Марки автобусов. Марка автобуса КАСКАДИРУЮТСЯ

ВНЕШНИЙ КЛЮЧ (Автокомпания ИЗ Автокомпании

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Автокомпании КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЯ Автокомпании. Автокомпания КАСКАДИРУЮТСЯ

ПОЛЯ (Регистрационный знак – Длинное целое, Марка автобуса – Текст 50, Автокомпания – Текст 50)

ОГРАНИЧЕНИЯ (1.Значения поля Регистрационного знака должны быть уникальны, при нарушении вывод сообщения «Такой регистрационный номер уже есть»

2. Значения полей Марка автобуса и Автокомпания должны принадлежать набору значений из соответствующих полей таблиц Марки автобусов и Автокомпании)

ТАБЛИЦА Экипажи (Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (№ экипажа)

ПОЛЯ (№ экипажа – Длинное целое, Группа допуска – Длинное целое, Медицинское заключение – Текст 50)

ОГРАНИЧЕНИЯ (Значения поля № экипажа должны быть уникальны, при нарушении вывод сообщения «Такой № экипажа уже есть»)

ТАБЛИЦА Состав экипажа(Характеризующая сущность, характеризует Экипажи)

ПЕРВИЧНЫЙ КЛЮЧ (Код состава экипажа)

ВНЕШНИЙ КЛЮЧ (№ экипажа ИЗ Экипажи

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Экипажи КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЯ Экипажи. № экипажа КАСКАДИРУЕТСЯ

ПОЛЯ (Код состава экипажа – Счётчик, Фамилия – Текст 50, Имя – Текст 50, Отчество - Текст 50, № экипажа – Длинное целое)

ОГРАНИЧЕНИЯ (Значения поля № экипажа должны принадлежать набору значений из соответствующего поля таблицы Экипажи)

ТАБЛИЦА Рейсы (Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (№ рейса)

ПОЛЯ (№ рейса – Длинное целое, Место отправления – Текст 50, Место назначения – Текст -50, Время в пути – Время, Расстояние – Длинное целое, Промежуточные остановки – Текст -50)

ОГРАНИЧЕНИЯ (Значения поля № рейса должны быть уникальны, при нарушении вывод сообщения «Такой № рейса уже есть»)

ТАБЛИЦА Вылеты (Ассоциативная сущность, связывает Рейсы, Автобусы, Экипажи)

ПЕРВИЧНЫЙ КЛЮЧ (Код Маршрута)

ВНЕШНИЙ КЛЮЧ (№ рейса ИЗ Рейсы

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Рейсы КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЯ Рейсы. № рейса КАСКАДИРУЕТСЯ

ВНЕШНИЙ КЛЮЧ (Регистрационный знак ИЗ Автобусы

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Автобусы КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЯ Автобусы. Регистрационный знак КАСКАДИРУЕТСЯ

ВНЕШНИЙ КЛЮЧ (№ экипажа ИЗ Экипажи

NULL – значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Экипажи КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЯ Экипажи. № экипажа КАСКАДИРУЕТСЯ

ПОЛЯ (Код вылета – Счётчик, № рейса – Длинное целое, Дата отправления – Дата, Время отправления – Время, № экипажа – Длинное целое, Количество проданных билетов – Длинное целое)

ОГРАНИЧЕНИЯ (Значения полей № рейса, Регистрационный номер, № экипажа должны принадлежать набору значений из соответствующих полей таблиц Рейсы, Автобусы, Экипажи).

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

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

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

Таблица «Автокомпании» содержит сведения о поставщиках услуг предоставляемых по перевозки пассажиров.

Таблица «Маршруты» содержит фактические маршруты по заданным рейсам

Таблица «Марки автобусов» содержит технические характеристики автобусов

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

Таблица «Автобусы» содержит сведения о номере регистрационного знака средства принадлежащего той или иной автокомпании.

Таблица «Состав экипажа» содержит сведения о шоферах входящих в тот или иной экипаж

Таблица «Экипажи»

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

Форма «Автокомпании»

Форма «Маршруты»

Форма «Марки автобусов»

Форма «Состав экипажей»

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

Запрос на выборку «Выбор автобуса-экипажа для маршрута» по задаваемому рейсу.

Запрос «На выборку по маршрутам».

Запрос «соответствие автобусы-Автокомпании».

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

Отчёт «Автокомпании» в приложении Д.

Отчёт «Маршруты» в приложение Е.

Отчёт «Существующие рейсы» в приложении Ж.

6. Заключение

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

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

1 Макарова Н.В. Информатика. – 2-е изд. –М.: Финансы и статистика, 1998.- 768с.

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

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