Файл: Образец КП.pdf

17

-сущность «Вид опасности» определяется следующими атрибутами: ID вида опасности, вид опасности;

-сущность «Категория опасности» определяется следующими атрибутами: ID категории опасности, степень опасности;

-сущность «Проведённый ремонт» определяется следующими атрибутами: код ремонта, ID вида ремонта, ID корпуса, ID помещения, дата начала, дата окончания;

-сущность «Вид ремонта» определяется следующими атрибутами: ID вида ремонта, вид ремонта;

-сущность «Работы по ремонту» определяется следующими атрибутами: ID работы, наименование работы, цена работы;

-сущность «Состав ремонта» определяется следующими атрибутами: ID вида ремонта, ID работы;

-сущность «Наличие мощных электроустановок» определяется следующими атрибутами: ID электроустановки, название электроустановки;

-сущность «Электроустановки» определяется следующими атрибутами: ID электроустановки, ID корпуса.

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

Сущность «Корпус» - первичный ключ «ID корпуса».

Сущность «Помещение» - составной первичный ключ «ID помещения, ID корпуса».

Сущность «Вид помещения» - первичный ключ «ID вида помещения». Сущность «Опасность» - составной первичный ключ «ID корпуса, ID вида

опасности, ID категории опасности».

Сущность «Вид опасности» - первичный ключ «ID вида опасности». Сущность «Категория опасности» - первичный ключ «ID категории

опасности».

Сущность «Проведённый ремонт» - первичный ключ «Код ремонта». Сущность «Вид ремонта» - первичный ключ «ID вида ремонта». Сущность «Работы по ремонту» - первичный ключ «ID работы».

18

Сущность «Состав ремонта» - составной первичный ключ «ID вида ремонта, ID работы».

Сущность «Наличие мощных электроустановок»- первичный ключ «ID электроустановки».

Сущность «Электроустановки» - составной первичный ключ «ID электроустановки, ID корпуса».

4.3 Разработка структуры связей

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

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

Сущности «Корпус» и «Опасность» связаны через внешний ключ по полю «ID корпуса». Так как для одного корпуса характерны различные опасности, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Корпус» – «ID корпуса» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

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

19

вида опасности» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

Сущности «Категория опасности» и «Опасность» связаны через внешний ключ по полю «ID категории опасности». Так как одна степень опасности может соответствовать разным категориям, а конкретная категория относится к конкретной степени опасности, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Категория опасности» – «ID категории опасности» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

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

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

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

Сущности «Проведенные работы» и «Состав ремонта» связаны через внешний ключ по полю «Код ремонта». Так как конкретной проведённой работе

20

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

Сущности «Работы по ремонту» и «Состав ремонта» связаны через внешний ключ по полю «ID работы». Так как конкретной работе по ремонту соответствует разный состав ремонта, а конкретный состав ремонта соответствуют одной проведённой работе по ремонту, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Работы по ремонту» – «ID работы» – является внешним ключом и частью составного первичного ключа для сущности «Состав ремонта».

Сущности «Корпус» и «Наличие электроустановок» связаны через внешний ключ по полю «ID корпуса». Так как в конкретном корпусе может находиться несколько электроустановок, а конкретное наличие электроустановок соответствует одному корпусу, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Корпус» – «ID корпуса» – является внешним ключом и частью составного первичного ключа для сущности «Наличие электроустановок».

Сущности «Электроустановка» и «Наличие электроустановок» связаны через внешний ключ по полю «ID электроустановки». Так как конкретноя электроустановка может относиться к конкретному наличию электроустановок, а конкретное наличие электроустановок соответствует одной электроустановке, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Электроустановка» – «ID электроустановки» – является внешним ключом и частью составного первичного ключа для сущности «Наличие электроустановок».

Логическая структура базы данных (ER – диаграмма) представлена на рисунке Б.1 в приложении Б.

21

4.4 Нормализация базы данных

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

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

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

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

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

Все атрибуты всех сущностей атомарны, у каждой сущности выделены первичные ключи, следовательно, отношения находятся в 1 НФ.

Сущность «Корпус» имеет первичный ключ «ID корпуса».

22

Сущность «Помещение» имеет первичный ключ «ID помещения». Сущность «Вид помещения» имеет первичный ключ «ID вида помещения. Сущность «Опасность» имеет составной первичный ключ «ID корпуса», «ID

вида опасности», «ID категории опасности».

Сущность «Категория опасности» имеет первичный ключ «ID категории опасности».

Сущность «Вид опасности» имеет первичный ключ «ID вида опасности». Сущность «Проведённые работы» имеет первичный ключ «Код ремонта». Сущность «Вид ремонта» имеет первичный ключ «ID вида ремонта».

Сущность «Работы по ремонту» имеет первичный ключ «ID работы». Сущность «Состав ремонта» имеет составной первичный ключ «Код

ремонта», «ID работы».

Сущность «Наличие мощных электроустановок» имеет составной первичный ключ «ID электроустановки», «ID корпуса».

Сущность «Электроустановки» имеет первичный ключ «ID электроустановки».

Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится в 2НФ.

2НФ требует, чтобы неключевые атрибуты функционально полно зависели от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Таким образом, для проверки соответствия 2НФ необходимо проверить сущности с составным первичным ключом, такими являются сущности «Опасность», «Наличие мощных электроустановок» и «Состав ремонта».

Рассмотрим сущность «Опасность», первичный ключ состоит из атрибутов «ID корпуса», «ID вида опасности» и «ID категории опасности». Неключевые атрибуты отсутствуют, поэтому можно сделать вывод, что данное отношение находится во 2НФ.

23

Рассмотрим сущность «Наличие мощных электроустановок», первичный ключ состоит из атрибутов «ID электроустановки» и «ID корпуса». Неключевые атрибуты отсутствуют, поэтому можно сделать вывод, что данное отношение находится во 2НФ.

Рассмотрим сущность «Состав ремонта», первичный ключ состоит из атрибутов «Код ремонта» и «ID работы». Неключевые атрибуты отсутствуют, поэтому можно сделать вывод, что данное отношение находится во 2НФ.

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

Нормализация 2НФ-отношения с образованием 3НФ-отношения осуществляется путем устранения транзитивных зависимостей - транзитивнозависимые атрибуты удаляются из отношения и помещаются в новое отношение вместе с их детерминантом.

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

На основе приведенной нормализации можно сделать вывод о том, что отношение находится в 4НФ.

4.5 Физическое проектирование системы

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

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

На основании логического проектирования были созданы следующие таблицы, описание которых приведено в таблицах 2-13.

24

Таблица 2 - Типы данных полей таблицы «Корпус»

Таблица 3 - Типы данных полей таблицы «Помещение»

Таблица 4 - Типы данных полей таблицы «Вид помещения»

Таблица 5 - Типы данных полей таблицы «Опасность»