- •Федеральное агенство связи государственное образовательное учреждение
- •Задание на проектирование
- •1.1 Описание предметной области
- •2. Модели баз данных
- •2.1 Логическая модель базы данных
- •2.2 Доказательства решенности поставленных задач
- •2.3 Нормализация
- •2.4 Физическая модель базы данных
- •2.5 Отчет об ошибках в Validator
- •2.6 Процесс прямого проектирования
- •3. Тексты и результаты выполнения запросов
- •3.1 Проверка базы данных в Oracle
- •3.2 Sql Запросы
- •3.3 Обратное проектирование
- •Заключение
2.2 Доказательства решенности поставленных задач
В данной курсовой работе выполнены все поставленные задачи, а именно.
Одной из основных задач, решаемых в данной информационной системы являлось составления расписания движения автотранспорта.
Для этого были созданы следующие сущности: Транспортное средство, Обслуживающий персонал, Заказчики, Рейс, Заказ, Заказчик.
Расписание формируется на основание перечня заказов, работоспособности водителей и транспортных средств.
Для этого через ассоциативную сущность осуществляем связь между сущностями Тр_средство и Водители.
Далее через еще одну ассоциативную таблицу осуществляем связь между сущность Рейс и еще одной ассоциативную таблицу Тр_с_в, которая будет называться Тр_с_в_рейс.
Далее формируется расписание на основание перечня заказов и работоспособности водителей и транспортных средств.
2.3 Нормализация
Нормализация - процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам - формализованным требованиям к организации данных. Известны шесть нормальных форм:
первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса - Кодда (усиленная 3NF);
четвертая нормальная форма (4NF);
пятая нормальная форма (5NF).
Производим нормализацию имеющихся сущностей.
Данная модель информационной системы находится в 1НФ т.к все атрибуты содержат атомарные значения.
Сущность Обслуживающий персонал содержит информацию о персонале. Атрибутами этой сущности являются Таб_ном, ФИО, Должность, Категория.
Данная сущность находится во 2НФ, т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости не ключевых атрибутов от части сложного ключа.
Данная сущность находится в 3НФ, т. К нет не ключевых атрибутов зависящая от части сложного ключа (см. рис. 2.3.1).
.
Рисунок 2.3.1 Сущность Об_персонал.
Сущность Об_персонал находится в НФБК, т.к функциональная зависимость имеет в качестве своего детерминанта потенциальный ключ.
Сущности Диспетчеры, Менеджеры и Водители находятся во 2НФ т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости не ключевых атрибутов от части сложного ключа.
Атрибутом сущности Диспетчеры является Таб_ном.
Атрибутом сущности Менеджеры является Таб_нм.
Атрибутами сущности Водители являются Таб_ном, Состояние.
Сущности Диспетчеры, Менеджеры и Водители находятся в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис. 2.3.2, рис.2.3.3, рис 2.3.4).

Рисунок 2.3.2 Сущность Диспетчеры.

Рисунок 2.3.3 Сущность Водители

Рисунок 2.3.4 Сущность Менеджеры
Данные сущности находятся в НФБК, т.к функциональная зависимость имеет в качестве своего детерминанта потенциальный ключ.
Атрибутами сущности Тр_средство являются Гос_номер, Название, Тип и Состояние_тр.
Сущность Тр_средство находится в 2НФ т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости не ключевых атрибутов от части сложного ключа.
Сущность Тр_средство находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.5).

Рисунок 2.3.5 Сущность Тр_ср.
Сущность Тр_ср находится в НФБК, т.к функциональная зависимость имеет в качестве своего детерминанта потенциальный ключ.
Атрибутами сущности Рейс являются Ном_рейса, ад_назначения, ад_отправления.
Сущность Рейс находится в 2НФ т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости не ключевых атрибутов от части сложного ключа.
Сущность Рейс находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.6).

Рисунок 2.3.6 Сущность Рейс.
Сущность Рейс находится в НФБК, т.к функциональная зависимость имеет в качестве своего детерминанта потенциальный ключ.
Атрибутами сущности Заказ являются Ном_заказа, сроки, ад_назначения,
Ад_отправления.
Сущность Заказ находится в 2НФ т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части сложного ключа.
Сущность Заказ находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.7).

Рисунок 2.3.7 Сущность Заказ
Сущность Заказ находится в НФБК, т.к функциональная зависимость имеет в качестве своего детерминанта потенциальный ключ.
Атрибутами сущности Заказчик являются ИНН, Название, Телефон, Юр_адрес.
Сущность Заказчик находится в 2НФ т.к имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части сложного ключа.
Анализируем данную сущность на 3НФ, данная сущность не находится в т.к есть не ключевые атрибуты которые зависят от другого не ключевого атрибута.
После нормализации сущность будет выглядеть следующим образом (см. рис. 2.3.8).

Рисунок 2.3.8 Нормализованная сущность Заказчик.
Данная сущность находится в Нормальной Форме Бойса Кодда (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
Сущность расписание содержит следующие атрибуты: Таб_ном, Ном_рейса, Гос_ном, Ном_заказа и Маршрут.
Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа.
Анализируем данную сущность на 3НФ был получен вывод о том, что данная сущность не находится в 3НФ. Т.к есть не ключевые атрибуты которые зависят от другого не ключевого атрибута.
После нормализации получаем (см. рис. 2.3.9)

Рисунок 2.3.9 Нормализованная сущность Расписание.
Данная сущность находится в Нормальной Форме Бойса Кодда (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
Сущность Тр_ср_вод содержит следующие атрибуты: Гос_ном, Таб_но .
Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа.
Сущность Тр_ср_вод находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.10).

Рисунок 2.3.10 Сущность Тр_ср_вод
Данная сущность находится в Нормальной Форме Бойса Кодда (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
Сущность Тр_с_в_рейс содержит следующие атрибуты: Гос_ном, Таб_ном, Ном_рейса.
Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа.
Сущность Тр_ср_в_рейс находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.11).

Рисунок 2.3.11 Сущность Тр_ср_в_рейс
Данная сущность находится в Нормальной Форме Бойса Кода (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
Сущность Зак_Заказ (Заказчик Заказ) содержит следующие атрибуты: Ном_зак и ИНН.
Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа.
Сущность Зак_Заказ находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.12).

Рисунок 2.3.12 Сущность Зак_заказ
Данная сущность находится в Нормальной Форме Бойса Кода (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
Сущность Мен_Зак (Менеджер Заказ) содержит следующие атрибуты: Ном_рейса и Таб_ном.
Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа.
Сущность Мен_Зак находится в 3НФ т.к они находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (см. рис 2.3.13).

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

Рисунок 2.3.14 Сущность Рей_Зак
Данная сущность находится в Нормальной Форме Бойса Кода (НФБК) т.к функциональная зависимость качестве детерминанта имеет потенциальный ключ данного отношения.
После выполнения нормализации Модель базы данных выглядит следующим образом (см. рис. 2.3.15)

Рисунок 2.3.15 Нормализованная модель базы данных
