Нормализация отношений реляционной бд

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

Известно 5 нормальных форм (НФ) отношений. Нормализация выполняется поэтапно. Сначала отношение приводится к первой НФ (1НФ), затем - ко 2НФ и т.д. вплоть до 5НФ. Однако для устойчивой работы БД часто оказывается достаточным, если ее отношения находятся в 3НФ

.

Первая нормальная форма

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

Пусть в рассмотренной нами выше предметной области о поставках на предприятие изделий поставщик П1 поставляет в определенных количествах изделия И1, И2 и И3, поставщик П2 - изделия И1 и И2, а поставщик П3 - изделие П4. Эти данные можно представить в виде таблицы ПОСТАВКИ1. Такой вид таблицы типичен для многих документов. Так, например, в одну колонку таблицы часто помещают фамилию, имя и отчество человека или адрес, содержащий почтовый индекс, город, улицу, номер дома, номер квартиры.

Номера поставщиков П# уникальны, и этот атрибут можно принять в качестве первичного ключа отношения ПОСТАВКИ1.

Поставки1 поставки

	П#			ПК
				И#			Кол
	П1			И1 И2 И3			300 200 200
	П2			И1 И2			200 500
	П3			И4			80

П#	И#	Кол
П1 П1 П1 П2 П2 П3	И1 И2 И3 И1 И2 И4	300 200 200 200 500 80

Можно заметить, в таблице на пересечении, например, строки П1 и столбца И# содержится несколько значений номеров изделий. Другими словами, в отношении ПОСТАВКИ1 значения ключа П# идентифицирует сразу несколько значений не ключевых атрибутов И# и Кол, что недопустимо. Это отношение находится не в 1НФ.

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

Вторая нормальная форма

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

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

ПОСТАВКИ2

П#	И#	Кол	Имя поставщика	Город	Тариф
П1	И1	300	Восход	Тула	10
П1	И2	200	Восход	Тула	10
П1	И3	200	Восход	Тула	10
П2	И1	200	Заря	Самара	15
П2	И2	500	Заря	Самара	15
П3	И4	80	Салют	Тула	10

Отметим, что у этого отношения первичный ключ составной - П# И#.

Рассмотрим следующую ситуацию. Пусть ведутся переговоры о поставках с новым предприятием Победа, расположенном в городе Тамбове. Требуется включить в таблицу сведения об этом предприятии и сведения о тарифе по доставки грузов с этого предприятия. Мы не сможем этого сделать. Это предприятия еще ничего не поставляет и код поставляемых изделий неизвестен, т.е. И# =0, а у составного первичного ключа ни одна из компонент не может быть нулевой. В этом и состоит аномалия включения.

Если же какое-либо предприятие, например, Заря перестанет поставлять нам изделия, то для него И# =0. Из таблицы придется исключить все сведения об этом предприятии, в том числе и те, которые мы хотели бы сохранить. В этом состоит аномалия удаления.

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

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

Ключ отношения составной, но он, целиком, определяет лишь атрибут Кол. Атрибуты Имя поставщика, Город и Тариф зависят лишь от части первичного ключа, так как именно номер поставщика однозначно определяет имя предприятия, название города, а, следовательно, и тариф. Это отношение находится не во 2НФ. Для приведения его ко 2НФ надо выделить группы атрибутов, зависящие от частей составного ключа, в отдельные таблицы.

В таблицу ПОСТАВЩИК1 выделим атрибуты П#, Имя поставщика, Город, Тариф. Ключ этого отношения - П#. В таблицу ПОСТАВКИ выделим атрибуты П#, И#, Кол. Здесь первичный ключ составной - П #И#. Отношения связаны между собой через внешний ключ П#. Теперь полученные отношения находятся во 2НФ и в БД можно включать сведения о новых предприятиях даже в том случае, когда они не поставляют никаких изделий.

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