База данных Расписание пассажирского транспорта

Оглавление

Оглавление 1

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

1.1 Деловой регламент 2

1.2 Функциональная структура 3

1.4 Выделение информационных объектов и их атрибутов 7

2 Концептуальная модель 9

3 Логическое моделирование 12

3.1 Построение логической модели 12

3.2 Целостность данных 14

3.2.1 Целостность объекта 14

3.2.2 Целостность приложения 14

4 Выбор СУБД 15

5  Физическая модель 17

5.1  Нормализация 19

6 Проектирование и реализация Sql-запросов 21

6.1 Описание средств, использованных при реализации 21

6.2 Тексты SQL-запросов и результаты их выполнения 21

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

Приложения 39

Приложение A Макетные данные 39

Приложение Б Листинг клиентского приложения. 42

 

 

 

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

1.1 Деловой регламент

Понятие “предметная область” (ПО) соответствует точке зрения потребителей информации на объекты, при которой выделяются только те свойства объектов и взаимосвязи между ними, которые представляют определенную прагматическую ценность и должны фиксироваться в базе данных. Таким образом, предметная область – это абстрактная картина реального мира, определенная часть которого фиксируется в качестве модели фрагмента действительности. В каждый момент времени ПО находится в одном из состояний, которое характеризуется совокупностью объектов и их взаимосвязей. Если объекты образуют объектное ядро, то совокупность взаимосвязей отражает структуру фрагмента действительности.

Конструирование базы данных «Расписание пассажирского транспорта» начинается с исследования и описания предметной области.

Главная цель создания базы данных «Расписание пассажирского транспорта» состоит в том, чтобы хранить и выдавать информацию о транспорте, о расписании движения этого транспорта и о водителях различных категорий транспорта.

С помощью базы данных «Расписание пассажирского транспорта» можно будет получать следующую информацию:

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

 

1.2 Функциональная структура

Кратко функции БД изображены на функциональной структуре (Рисунок 1.1)

Как видно  из рисунка 1.1, «Расписание пассажирского транспорта» имеет возможности:

- получение подробной информации о водителях;

- выдача зарплаты водителям;

- получение подробной информации о маршрутах и остановках;

- получение информации о нужном клиенту маршруте;

                      

                                   1.3 Диаграмма потоков данных

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

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

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

Хранилище данных - это пассивный объект в составе  ДПД, в котором данные сохраняются  для последующего доступа. Хранилище  данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам. Диаграмма ПД курсового проекта представлена на рисунке 1.2.

На функциональной диаграмме листовыми будут являться функции:

• Получения информации о маршрутах; 
• Получение информации о водителях;
• Получение информации о транспорте;
• Поучение информации о зарплате;
• Получение информации об остановках.

 

 

 

 

 

                          

 

 

 

 

 

 

 

 

Рисунок 1.1  Функциональная структура

 

 

 

 

 

 

 

 

Рисунок 2. Диаграмма потоков данных

 

1.4 Выделение информационных объектов и их атрибутов

В результате детального анализа предметной области, построения функциональной структуры и схемы потоков данных были выделены следующие объекты:

1   Drivers – водители, управляющие пассажирским транспортом;

• driver_id  (индикационный  номер);
• familia (фамилия водителя)
• ima (имя водителя);
• otchestvo  (отчество водителя);
• stag_raboty (количество лет работы водителя);
• adress (адрес, по которому проживает водитель);
• zarplata_id (зарплата водителя);
• cat_id (категория транспорта, которым управляет водитель);
• marshrut_id (маршрут, по которому ездит водитель).

                    

2   Marshryti – маршруты по городу;

• marshryt_id (номер маршрута);
• pynkt_otpravleniya (пункт отправления);
• pynkt_naznacheniya (пункт прибытия).

 

3   Транспорт – имеющийся транспорт;

• transport_id (уникальный индификатор модели);
• model (модель транспорта);
• cat_id (категория, к которой относится транспорт);
• kolvo (количество транспорта).

 

4   Raspisanie – расписание прибытия транспорта на остановки.

• rasp_id (уникальный индификатор строки расписания);
• number_ost (номер остановки);
• marshryt_id (номер маршрута, по которому работает пассажирский транспорт).
• time (время прибытия транспорта на остановку)

 

5   Zarplata – зарплата выдаваемая водителям.

• zarplata_id – уникальный индификатор зарплаты;
• oklad – зарплата.

 

6   Ostanovki – остановки транспорта на маршруте.

• numder_ost (номер остановки);
• nazvanie_ost (название остановки).

 

7   Category – категории, имеющегося транспорта.

• cat_id (уникальный индификатор категории);
• catname (название категории).

 

 

 

 

 

2 Концептуальная модель

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

Концептуальная модель базы данных “Расписание пассажирского транспорта” иллюстрирует влияние объектов друг на друга и представлена на рисунке 2.1. Прямоугольникам соответствуют экземпляры объектов (сущностей), а стрелкам – связи, которые представлены основными элементами информации:

- тип связи;

- родительская и дочерняя (зависимая) сущности;

- мощность связи.

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности.

На рисунке 2.1 Буква «N»показывает максимальное количество экземпляров сущности, с которым может быть связан один экземпляр другой сущности.

Рисунок 2.1 Концептуальная модель

 

 

Между объектами drivers и category мощность связи N:1, то есть один водитель может управлять только одной категорией пассажирского транспорта, но к одной категории может принадлежать много водителей;

Между объектами drivers и zarplata мощность связи N:1, то есть один водитель может получать только одну зарплату, но одна зарплата может быть у разных водителей;

Между объектами drivers и marshruti мощность связи N:1, то есть один водитель может работать только на одном маршруте, но на маршруте могут работать много водителей;

Между объектами raspisanie и marshruti мощность связи N:1, то есть по одну расписанию ездит только один маршрут, но один маршрут может ездить по нескольким расписаниям (имеется введу расписание для каждой остановки);

Между объектами transport и category мощность связи N:1, то есть один маршрут может принадлежать только одной категории, но к одной категории будут относиться много транспортных средств;

Между объектами  raspisanie и ostanovki мощность связи N:1, то есть у одной остановки может быть много расписаний, но у одного расписания может быть только одна остановка.          

3 Логическое моделирование

3.1 Построение логической  модели

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

Первичные ключи: для таблиц drivers, category, transport, raspisanie, zarplata, ostanovki, marshryti первичными ключами являются соответственно: driver_id, cat_id, transport_id, rasp_id, zarplata_id, numder_ost, marshrut_id.

На рисунке 3.1 логическая модель базы данных «Расписание пассажирского транспорта»: 

 

Рисунок 3.1 Логическая модель

 

 

 

 

 

 

 

3.2 Целостность данных

 

3.2.1 Целостность объекта

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

Например, в базе данных в  отношение «Расписание» при вставке информации о новой остановки, необходимо сначала вставить значение в поле, являющееся первичным ключом («id»), а затем уже заносить информацию в остальные поля. Аналогично и с удалением при удалении картежа из таблицы, необходимо сначала удалить информацию из вторичных атрибутов, а затем уже удалять значение первичного ключа. Целостность объекта реализуется самой СУБД, и обычно пользователю нет необходимости об этом беспокоиться.

3.2.2 Целостность приложения

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

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

 

4 Выбор  СУБД

Для реализации базы данных «Расписание пассажирского транспорта» была выбрана СУБД  Oracle 11g . Это объясняется следующими возможностями данной СУБД:

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

- Real Application Cluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости;

- Automatic Storage Management (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO);

- Производительность. Oracle Database 11g позволяет автоматически управлять уровнями сервиса и тиражировать эталонные конфигурации в рамках всей сети;

- Простые средства разработки. Новый инструмент разработки приложений HTML DB позволяет простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки;

- Самоуправление. Специальные механизмы Oracle Database 11g позволяют самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогнозировать ошибки;