Базы данных: конспект лекций - Коллектив авторов - Страница 29

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

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

Для наглядного объяснения различий нормализованных и ненормализованных отношений рассмотрим пример.

Пусть, имеется ненормализованное отношение, со следующей схемой.

Итак, вариант 1 схемы отношения с заданным на ней простым первичным ключом:

Перечислим, какие в этой схеме отношения имеются ошибки, т. е. назовем те признаки, которые и делают собственно эту схему ненормализованной:

1) атрибут «Фамилия Имя Отчество» является составным, т. е. составленным из разнородных элементов;

2) атрибут «Телефоны» является многозначным, т. е. его значением является множество значений;

3) атрибут «Дата приема или увольнения» не имеет однозначной семантики, т. е. в последнем случае не понятно, какая именно дата внесена.

Если, например, ввести дополнительный атрибут, чтобы поточнее определить смысл даты, то для этого атрибута значение будет семантически понятно, но тем не менее остается возможность хранения только какой-то одной из указанных дат для каждого сотрудника.

Что же необходимо сделать для приведения этого отношения к нормальной форме?

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

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

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

Итак, вариант 2 отношения:

Итак, что мы видим? Составного атрибута «Фамилия Имя Отчество» больше в нашем отношении нет, вместо него присутствуют три простых атрибута «Фамилия», «Имя» и «Отчество», поэтому эта причина «ненормальности» отношения исключилась.

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

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

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

3. Вторая нормальная форма (2NF)

Более сильные требования накладывает на отношения вторая нормальная форма, или 2NF.

Это происходит потому, что определение второй нормальной формы отношений предполагает, в отличие от первой нормальной формы, наличие системы ограничений функциональных зависимостей.

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

В этом определении неключевой атрибут – это любой атрибут отношения, не содержащийся в каком-либо первичном или кандидатном ключе отношения.

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

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

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

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

Итак, вариант 1 схемы отношения:

Что мы видим? Все условия пребывания этого отношения «Аудитории» в первой нормальной форме выполнены, ведь все до единого атрибуты этого отношения однозначны и просты. Но то условие, что каждый неключевой элемент должен полностью функционально зависеть от ключа, не выполняется. Почему? Да потому, что атрибут «№ табельный коменданта корпуса» функционально зависит не от составного ключа «№ корпуса, № аудитории», а от части этого ключа, т. е. от атрибута «№ корпуса». Действительно, ведь именно номер корпуса полностью определяет, какой именно комендант к нему приписан, а, в свою очередь, ни от каких номеров аудиторий табельный номер коменданта корпуса зависеть никак не может.

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

Для того, чтобы этого добиться, придется снова, как и в предыдущем параграфе, применить декомпозицию отношения. Итак, следующая система отношений, представляющая собой вариант 2 отношения «Аудитории», как раз и получилась из исходного отношения путем его декомпозиции на несколько новых самостоятельных отношений: