48978 (Система управления базой данных), страница 2
Описание файла
Документ из архива "Система управления базой данных", который расположен в категории "". Всё это находится в предмете "информатика" из 1 семестр, которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "48978"
Текст 2 страницы из документа "48978"
Таблица 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 (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. Значения полей Марка автобуса и Автокомпания должны принадлежать набору значений из соответствующих полей таблиц Марки автобусов и Автокомпании)