Содержание
Введение
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 ServiceRelease 1 (SR-1), требуется дополнительно 50 МБ для обновления системныхфайлов. Необходимыми являются также дисковод для компакт-дисков, мониторSuper VGA (800x600) или с более высоким разрешением с поддержкой 256 цветов, мышь Microsoft Mouse, MicrosoftIntelliMouse или совместимое указательное устройство. При работе с мультимедиаи звуком для улучшенного отображения графики требуется видеоплата,поддерживающая ускорение графики, или процессор, поддерживающий набор командMMX [1].
2.2 Объём внешней памяти занимаемый модулями СУБД
Объём внешней памяти занимаемый модулями СУБД определяетсяпрактически по созданной базе данных. Размер проектируемой базы данных«Автовокзал» составляет 1 478 656 байт.
2.3 Объём памяти, отводимой под данные
При рассмотрении вопроса ообъёме памяти отводимые под данные необходимо рассмотреть в отдельности каждуютаблицу. При рассмотрении необходимо учитывать предполагаемую мощностьотношения, число атрибутов, максимальный размер экземпляра сущности. Приподсчёте будем учитывать также что одному символу соответствует один байт.Подсчёт ведётся для одного месяца работы автовокзала. Для наглядности создаютсятаблицы с указанием атрибутов и размера соответствующих полей.
Рассмотрим отношение «Автокомпании».
Число атрибутов отношения а=4.Число автокомпаний находящихся в БД автовокзала выбираем предположительноравным десяти единицам, т.е мощность отношения m=10. Данные сведены в таблицу3.1
Таблица 3.1 — АвтокомпанииАвтокомпания Номер лицензии Адрес офиса Телефон главного менеджера 30 байт 4 байта 50 байт 20
Тогда размер под данные таблицысоставляет
DАвтокомпания=(30+4+50+20)*10=1040байт.
Рассмотрим отношение «Маршрутов».
Число атрибутов отношения а=7.Число маршрутов в месяц принимаем равным 600, т.е. мощность отношения m=600. Данныесведены в таблицу 3.2
Таблица 3.2 — МаршрутыКод маршрута № рейса Дата отправления Время отправления Регистрационный знак № экипажа Кол-во проданных билетов 4 байта 4 байта 8 байт 8 байт 4 байта 4 байта 4 байта
Тогда размер под данныетаблицы составляет
DМаршруты=(4+4+8+8+4+4+4)*600=21600байт
Рассмотрим отношение «Маркиавтобуса».
Число автобусов отношения а=6.Число марок автобусов выбирается равным 15, т.е. мощность отношения m=15. Данныесведены в таблицу 3.3
Таблица 3.3 – Марки автобусовМарка автобусов Код автобуса Кол-во мест Марка топлива Объём топливного бака Группа допуска 20 байт 4 байта 4 байта 10 байт 4 байта 4 байта
Тогда размер под данныетаблицы составляет
DМарки автобусов =(20+4+4+10+4+4)*15=690байт
Рассмотрим отношение «Рейсы».
Число атрибутов отношения а=6.Число рейсов принимаем равным 100, т.е. мощность отношения m=100. Данныесведены в таблицу 3.4
Таблица 3.4- Рейсы№ рейса Место отправления Место назначения Время в пути Расстояние Промежуточные остановки 4 байта 20 байт 20 байт 8 байт 4 байта 20 байт
Тогда размер под данныетаблицы составляет
DРейсы=(4+20+20+8+4+20)*100=7600байт
Рассмотрим отношение «Автобусы».
Число атрибутов отношения а=3.Число воздушных средств с присвоенным регистрационным знаком принимаем равным50, т.е. мощность отношения m=50. Данные сведены в таблицу 3.5
Таблица 3.5- АвтобусыРегистрационный знак Марка автобуса Автокомпания 4 байта 20 байт 30 байт
Тогда размер под данныетаблицы составляет
DАвтобусы=(4+20+30)*50=2700байт
Рассмотрим отношение «Составэкипажа».
Число атрибутов отношения а=6.Мощность отношения принимаем равным 70, т.е. m=70. Данные сведены в таблицу 3.6
Таблица 3.6– Состав экипажаКод состава экипажа Фамилия Имя Отчество № экипажа 4 байта 20 байт 20 байт 20 байт 4 байта
Тогда размер под данныетаблицы составляет
DСостав экипажа =(4+20+20+20+20+4)*70=6160байт
Рассмотрим отношение «Экипажи».
Число атрибутов отношения а=3.Мощность отношения принимаем равным 55, т.е. m=55. Данные сведены в таблицу 3.7
Таблица 3.7- Экипажи№ экипажа Группа допуска Медицинское заключение 4 байта 4 байта 10 байт
Тогда размер под данныетаблицы составляет
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 (OpenDatabase 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.
Создаются таблицы.
Таблица «Автокомпании» содержит сведения опоставщиках услуг предоставляемых по перевозки пассажиров.Автокомпания Номер лицензии Адрес офиса Телефон гл. менеджера Депо №1 1587456 Саратов Перн 23-5 (882)-45-564-45 Депо №2 1587455 Саратов Перн 23-5 (882)-45-564-45 Депо №3 1587454 Саратов Перн 23-5 (882)-45-564-45 Депо №4 1584444 Балаково ул. Новосельцева 256-45/Г (092)-8-78-78 … … … …
Таблица «Маршруты» содержит фактическиемаршруты по заданным рейсамКод маршрута № рейса Дата отправления Время отправления Регистрационный знак № экипажа Кол-во проданных билетов 1 1 26.03.99 14:53
Н775КУ64rus 1 89 2 2 1,04.00 16:22
Н776КУ64rus 2 144 3 3 25.05.02 1:30
Н777КУ64rus 3 44 4 4 10.12.03 21:40
Н74КУ64rus 4 38 5 4 10.11.03 21:40
Н77КУ64rus 4 38 5 4 10.10.03 21:40
Н75КУ64rus 4 38
Таблица «Марки автобусов» содержит технические характеристикиавтобусовМарка автобуса Код автобуса Кол-во мест Марка топлива Объём топливного бака ИКАРУС 1 150 ДТ 150 … … … … ЛИАЗ 2 50 АИ-80 100 ПАЗ 3 60 АИ-80 90 ПАЗ 4 70 АИ-80 90
Таблица «Рейсы» № рейса Место отправления Место назначения Время в пути Расстояние Промежуточные остановки 1 Саратов Москва 25 2000 2 Саратов Петербург 30 2500 Москва 3 Саратов Тамбов 22 1800 4 Саратов Уфа 12 1000 … … … … … …
Таблица «Автобусы» содержит сведения о номере регистрационногознака средства принадлежащего той или иной автокомпании.Регистрационный знак Марка автобуса Автокомпания
Н775КУ64rus ИКАРУС Депо №1
Н776КУ64rus ИКАРУС Депо №2
Н777КУ64rus ИКАРУС Депо №3
Н74КУ64rus ЛИАЗ Депо №4
Н77КУ64rus ПАЗ Депо №4
Н75КУ64rus ПАЗ Депо №4
Таблица «Состав экипажа» содержит сведения ошоферах входящих в тот или иной экипажКод состава экипажа Фамилия Имя Отчество № экипажа 1 Кучеров Владимир Петрович 4 2 Михаило Сергей Павлович 4 3 Кудрявцев Петр Ильич 4 4 Кудряшов Михаил Васильевич 3 5 Твордской Алексей Михайлович 2 6 Ларин Сергей Петрович 1
Таблица «Экипажи»№ экипажа Группа допуска Медицинское заключений 1 Е годен 2 Е годен 3 Е годен 4 Е годен 5 Е годен 6 Е годен
Создаются формы.
Форма «Автокомпании»
/>
Форма «Маршруты»
/>
Форма «Марки автобусов»
/>
Форма «Состав экипажей»
/>
Создаются запросы.
Запрос на выборку «Выбор автобуса-экипажа длямаршрута» по задаваемому рейсу.№ рейса Марка автобуса Дальность маршрута № Экипажа Количество мест 4 Икарус 1000 1 150 4 Икарус 1000 2 150 4 Икарус 1000 2 150 4 ЛИАЗ 1000 2 50 4 ПАЗ 1000 4 60 4 ПАЗ 1000 4 70
Запрос «На выборку по маршрутам».№ рейса Дата отправления Время отправления 1 26.09.99 14:53 2 01.04.00 16:22 3 25.05.02 1:30 4 10.12.03 21:40 4 10.11.03 21:40 4 10.10.03 21:40
Запрос «соответствие автобусы-Автокомпании».Регистрационный знак Марка автобуса Автокомпания Телефон гл. менеджера
Н775КУ64rus Икарус Депо №1 (882)-45-564-45
Н776КУ64rus Икарус Депо №2 (882)-45-564-45
Н777КУ64rus Икарус Депо №3 (882)-45-564-45
Н74КУ64rus ЛИАЗ Депо №4 (092)-8-78-78
Н77КУ64rus ПАЗ Депо №4 (092)-8-78-78
Н75КУ64rus ПАЗ Депо №4 (092)-8-78-78
Создаются отчёты.
Отчёт «Автокомпании» в приложении Д.
Отчёт «Маршруты» в приложение Е.
Отчёт «Существующие рейсы» в приложении Ж.
6. Заключение
В процессе проектирования реляционной БДавтовокзала были изучены материалы позволяющие описывать предметнуюинформационную систему с помощью ЯИМ, ER-диаграмм, изучены принципы построенияинфологической модели и реляционных отношений удовлетворяющие 1НФ, 2НФ, 3НФ,4НФ, а также описание отношений и БД в целом с ограничением целостности.
Список литературы
1 Макарова Н.В. Информатика. – 2-е изд. –М.: Финансы истатистика, 1998.- 768с.
2 Карпов Б.В Microsoft Access 2000 Справочник.-1-е изд.–М.: Питер, 2000.-416 с.
3 Синева Н.Ф. Создание реляционных баз данных в MS Access.-1-е изд. –Саратов: Копипринтер СГТУ, 1996.-40 с.