5ый семестр / ТРПО_Богословская / Лекция 3

Лекция 3. Нормализация данных

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

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

Атрибут (группа атрибутов) является множественным, если для одного экземпляра сущности может быть несколько различных значений атрибута. В примере на рис. 1 таким атрибутом является «Оценка», так как студент имеет много оценок по различным предметам.

Рис.1. Пример множественного (повторяющегося) атрибута

Приведение к 1НФ осуществляется по следующим правилам (рис. 2):

• множественный атрибут или группа таких атрибутов выделяются в самостоятельную сущность;

• между исходной и новой сущностями устанавливается связь.

Рис.2. Правило приведения к 1НФ

Результат приведения к 1НФ для сущности «СТУДЕНТ» (см. рис. 1) показан на рис. 3.

Рис.3. Приведение к 1НФ сущности Студент

Первая нормальная форма, таким образом, является механизмом выявления упущенных сущностей и связей.

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

Атрибут А функционально зависит от атрибута В (ФЗ : В —› А), если каждому значению А соответствует не более одного значения В. Функциональная зависимость может иметь место не только от одного атрибута, но и от группы атрибутов – ФЗ : B, C, D —› А.

Функциональная зависимость является полной, если атрибут зависит от составного ключа и не зависит ни от какого подмножества данного ключа, т. е. имеет место зависимость ФЗ : K1, K2, ..., Kn —› А и не справедлива ни одна из следующих зависимостей: ФЗ : K1 —› А; ФЗ : K2 —› А; ... ФЗ : K1, K2 —› А и т. д.

Пример функционально неполной зависимости приведен на рис. 4. Здесь атрибуты «Факультет», «Курс» зависят от ключевого атрибута «Номер группы» и не зависят от других ключевых атрибутов: «Фамилия», «Имя», «Отчество».

Рис.4. Пример функционально неполной зависимости

Приведение к 2НФ осуществляется по следующим правилам (рис. 5):

• атрибуты, зависящие от части составного ключа, и сама эта часть выносятся в отдельную (новую) сущность и исключаются из исходной;

• ключом новой сущности становится часть ключа исходной, от которой имеет место функционально неполная зависимость;

• между исходной и новой сущностями устанавливается связь типа М : 1, ключевая со стороны «многие».

Рис.5. Правило приведения ко 2НФ

Результат приведения ко 2НФ сущности “СТУДЕНТ” (см. рис. 4) показан на рис. 6.

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

Рис.6. Приведение ко 2НФ

В примере, рассматриваемом на рис. 4, значение атрибутов «Факультет» и «Курс» повторялось бы для каждого экземпляра сущности «СТУДЕНТ», а, следовательно, неоправданно увеличивался бы объем памяти, занимаемой базой данных. Этот недостаток устранен в модели на рис. 6. Кроме того, изменение, например, номера курса (см. рис. 4), приводило бы к необходимости изменить значение атрибута для каждого экземпляра сущности «СТУДЕНТ», вместо того чтобы сделать это один раз для экземпляра сущности «ГРУППА» (аномалия изменения).

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

Атрибут А транзитивно зависит от С, если А зависит от В, а В зависит от С (ФЗ : С —›* А, если ФЗ : В —› А и ФЗ : С —› В).

Пример транзитивной зависимости приведен на рис. 7. Здесь значение атрибута «Должностной оклад» определяется неключевым атрибутом «Должность».

Рис.7. Пример транзитивной зависимости

Приведение к 3НФ осуществляется по следующим правилам (рис. 8):

• атрибуты, зависящие от неключевых атрибутов, и сами эти атрибуты выносятся в отдельную (новую) сущность и исключаются из исходной сущности;

• ключом новой сущности становятся те атрибуты исходной, от которых была обнаружена транзитивная зависимость;

• между исходной и новой сущностями устанавливается связь типа М : 1.

Результат приведения к 3НФ сущности «СОТРУДНИК» (см. рис. 7) показан на рис. 9.

Рис.8. Правила приведение к 3НФ

Приведение к 3НФ, так же как и приведение к 1НФ, 2НФ, позволяет выявить в модели упущенные сущности и связи и, кроме того, устранить избыточность данных и аномалии изменения.

Рис.9. Приведение к 3НФ

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

• создается новая (так называемая «межсекционная») сущность;

• между новой и исходными сущностями устанавливаются связи М : 1;

• из модели удаляется связь М : М.

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

Рис.10. Правило устранения связей «многие-ко-многим»

Проектирование структуры базы данных

На основе модели «сущность-связь» может быть автоматически синтезирована структура базы данных. Генерация осуществляется в соответствии со следующими правилами:

• каждая сущность преобразуется в таблицу, имя сущности становится именем таблицы;

• атрибуты сущности преобразуются в колонки таблицы, имена атрибутов становятся именами колонок;

• ключевые атрибуты становятся первичными ключами таблицы;

• если для сущности была определена ключевая связь, то первичный ключ таблицы для связанной сущности копируется и объединяется с ключом таблицы для рассматриваемой сущности;

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

Результат генерации таблиц для модели, изображенной на рис. 10, приведен на рис. 11, для сущностей «АВТОР» и «КНИГА» построены таблицы, колонками которых являются атрибуты сущностей, а первичными ключами – ключи сущностей. Для межсекционной сущности получена таблица, состоящая из скопированных ключей, образующих составной ключ таблицы «АВТОР КНИГИ».

	КНИГА
	Название	Место издания	Издательство	Год	Кол-во страниц

	АВТОР			АВТОР	КНИГИ
	ФИО	Тематика		ФИО	Название

Рис. 11. Структура базы данных для модели, приведенной на рис. 10

Правила генерации структуры базы данных иллюстрируются на рис. 12.

Е

А	B	C	D
key

а)

E1

A	B	C
key	key

E2

B	D
key

б)

E1

A	B	C
key

E2

B	D
key

в)

Рис.12. Правила генерации структуры базы данных: а – создание таблиц для сущностей, б - обработка ключевых связей, в – обработка связей М:1

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

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

Типовыми случаями, приводящими к конфликту имен, являются следующие:

• наличие в модели двух связанных сущностей с совпадающими именами атрибутов (рис. 13, а);

• наличие между двумя сущностями более чем одной связи (рис. 13, б);

• рекурсивные связи (сущность связана сама с собой) (рис. 13, в).

Для разрешения конфликта имен используются следующие стандартные приемы:

• добавление в качестве префикса к имени атрибута имени сущности;

• добавление к имени атрибута порядкового номера;

• использование имени (физического имени) связи.

Добавление к имени атрибута имени сущности позволило бы избежать конфликта имен в модели, изображенной на рис. 13, а, соответствующие колонки таблицы получили бы имена «ЭТАП_Номер» и «ДОГОВОР_Номер».

Этот прием не дал бы нужного эффекта для моделей, показанных на рис. 13 б, в. В данном случае потребовалось бы вводить порядковые номера, например «АЭРОПОРТ_Код_1», «АЭРОПОРТ_Код_2».

Использование имен (физических имен) связей позволяет избежать конфликта во всех рассмотренных случаях, например:

• для сущности «ЭТАП» – «Входить_в_Номер»;

• для сущности «АЭРОПОРТ» – «В_Код», «Из_Код»;

• для сущности «ПОДРАЗДЕЛЕНИЕ» – «Входит_в_Название».

В рассматриваемых далее примерах будем придерживаться следующих правил:

• для любого копируемого атрибута (в т. ч. при отсутствии конфликта имен) в качестве префикса добавляется имя сущности, из которой атрибут скопирован;

• при возникновении конфликта имен к именам атрибутов добавляются порядковые номера.

ДОГОВОР

Номер	Название	….
key

ЭТАП

Номер	Номер	Название	…
key	key

а)

АЭРОПОРТ

Код	Название
key

АВИАРЕЙС

Номер	Время	Код	Код
key

б)

ПОДРАЗДЕЛЕНИЕ

Название	Название	Руководитель
key

в)

Рис. 13. Случаи, приводящие к конфликту имен при генерации структуры базы данных

Пример цепочки ключевых связей и результат ее обработки приведен на рис. 14. Предполагается, что экземпляры сущности «СТУДЕНТ» не могут быть однозначно идентифицированы вне связи с экземпляром сущности «ГРУППА», это приводит к тому, что в таблицу «ПРЕДМЕТ» помимо ключа «Студент_ФИО» будет скопирован ключ «ГРУППА_Номер», которые в совокупности с собственным ключевым атрибутом сущности “ОЦЕНКА” образуют составной ключ таблицы.

СТУДЕНТ

Фамилия	Имя	Отчество	Адрес	Номер
key	key	key		key

ПРЕДМЕТ

Предмет	Оценка	Фамилия	Имя	Отчество	Номер
key		key	key	key	key

Рис.14. Пример цепочки ключевых связей