Материал: Информационные системы в экономике. курсовое проектирование. Лубянская Э.Б., Лукаш Е.Н

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

Составление Таблицы предварительных отношений. В соответствии с вышеприведенными правилами, для проектируемой БДформируются Таблица предварительныхотношений (например, табл. 7.4). Таблица содержат пока только ключевые атрибуты (подчеркнуты) и атрибуты, вводимые по правилам построения (указаны курсивом). Втретьей колонке указывается номер правила, на основании которого было образовано данное отношение, либо когда в существующее отношение были внесены изменения (добавлено поле для связи).

Как показывает опыт, наиболее часто используются правила 4 и 6, значительно реже 7. Другие правила используются крайне редко, когда связи между объектами не удается свести к правилам 4 или 6.

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

 

 

Таблица 7.3

Таблица предварительных отношений

Название отно-

Ключевые поля и

Используемое пра-

шения

поля для связи

вило

 

 

 

1

2

3

Работники

(ТабНом, ...)

-

 

 

 

Работы

(НомРаботы,

4

 

ТабНом,

 

 

 

 

61

 

 

 

Продолжение табл. 7.3

1

 

2

3

Клиенты

 

(НомКлиента, ...)

-

 

 

 

 

Заказы

 

(НомЗаказа,

4, 4

 

 

ТабНом, НомК-

 

 

 

лиента, ...)

 

Поставщики

 

(НомПоставщика,

-

 

 

...)

 

 

 

 

 

Продукция

 

(Артикул, ...)

-

 

 

 

 

Поставляют

 

(Артикул, Ном-

6

 

 

Поставщика, ...)

 

 

 

 

 

 

7.3. Правила нормализаций отношений

 

 

Основные определения

Если отношение находится в нормальной форме, то снимаются многие проблемы хранения и обработки данных. Разрабатываемые методы проектирования применимы к определенным нормальным формам.

Известны три нормальные формы и формы высших порядков. Здесь будут рассмотрены первые три нормальных формы и нормальная форма Бойса-Кодда.

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

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

62

Первая нормальная форма - это обычное отношение. Согласно определению отношений, любое отношение автоматически уже находится в 1НФ. Иными словами, данные, представленные в виде двумерной таблицы, являются первой нормальной формой реляционной модели данных.

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

входящий в состав никакого потенциального ключа).

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

Замечание. Если потенциальный ключ отношения является простым, тоотношение автоматически находится в 2НФ.

Определение. Функциональная зависимость A -> B на-

зывается транзитивной (опосредованной), если существует набор атрибутов С такой, что:

-существует функциональная зависимость A -> C;

-существует функциональная зависимость C -> B.

Отношение находится в третьей нормальной форме

(3НФ) тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

То есть в таком отношении все неключевые атрибуты зависят от ключа напрямую.

Для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или несколько отношений, отображающих понятия

63

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

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

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

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

При приведении отношений при помощи нормализации к отношениям в 3НФ неявно предполагалось, что все отношения содержат один потенциальный ключ. Это не всегда верно.

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

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

64

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

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

Итак, для того, что бы проверить соответствие предварительных отношений требованиям нормальной формы Бой- са-Кодда необходимо выявить все функциональные зависимости и все потенциальные ключи в каждом из отношений. Результаты подобного анализа видны из табл. 3.6, где потенциальные ключи выделены жирным шрифтом. В приведенном примере выявлены потенциальные ключи в отношениях Работники (Должность) и Заказы (НомАвт).

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

Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

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

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

65

Источник: https://studfile.net/preview/16563512/