Лекция №21Тема «Модели организации данных»

План лекции

1. Модели организации данных.

2. Иерархическая модель данных.

3. Сетевая модель данных.

4. Реляционная модель данных.

5. Операции над данными в реляционной модели

6. Нормализация отношений

Модели организации данных

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

• иерархическая;

• сетевая;

• реляционная.

Кроме того, в последние годы появились и стали более активно внедряться на практике следующие модели данных:

• постреляционная;

• многомерная;

• объектно-ориентированная.

Иерархическая модель данных

В иерархической модели связи между данными можно описать с помощью упорядоченного графа (или дерева). Упрощенно представление связей между данными можно показать в виде следующей схемы (см. рис. 50).

Рис.50Схема иерархической модели данных

Самая высокая вершина называется корень. Остальные вершины, находящиеся на нижних уровнях называются подчиненными.

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

Взаимосвязи между объектами напоминают генеалогическое дерево. Взаимосвязь между главным и подчиненными объектами устанавливается типом «один-ко-многим». Как видно из схемы иерархической модели данных, ее древовидная структура состоит из узлов и дуг. Узел – совокупность атрибутов, которые описывают объект. Например, объект «студент» может иметь такие атрибуты: фамилия, имя, отчество, номер группы.

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

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

1. Найти указанное дерево.

2. Перейти от одного дерева к другому.

3. Перейти от одной записи к другой.

4. Перейти от одной записи к другой в порядке обхода иерархии

5. Удалить текущую запись.

К достоинствам иерархической модели данных относятся:

• эффективное использование памяти ЭВМ;

• неплохие показатели времени выполнения основных операций над данными.

Недостатками иерархической модели являются:

• ее громоздкость для обработки информации с достаточно сложными логическими связями;

• сложность понимания для обычного пользователя.

На иерархической модели основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up, DataEdge; отечественные системы Ока, ИНЭС, МИРИС.

Сетевая модель данных

Сетевая модель позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа (рис. 51). В сетевой модели понятие главного и подчиненных объектов иное, чем в иерархической модели: любой объект здесь может быть и главным, и подчиненным; каждый объект может участвовать в любом количестве взаимосвязей.

Рис.51 Общая схема сетевой модели данных

В сетевой модели устанавливаются следующие операции над данными:

1. перейти от предка к первому потомку по некоторой связи;

2. создать новую запись;

3. уничтожить запись;

4. модифицировать запись;

5. исключить запись из связи;

6. переставить запись в другую связь.

Данные представляются при помощи записей и связей. Запись (объект) в сетевой модели (в отличие от иерархической) может иметь множество как подчиненных ей записей, так и записей, которым она сама подчинена.

Достоинство сетевой модели данных – возможность эффективной реализации по показателям затрат памяти и оперативности.

Недостатки сетевой модели данных:

• высокая сложность и жесткость схемы БД, построенной на ее основе;

• сложность для понимания и выполнения обработки информации в БД обычным пользователем.

Системы на основе сетевой модели данных не получили широкого распространения на практике. В 70-е годы 20 века крупными корпорациями для создания информационной системы использовались зарубежные СУБД IDMS, db_Vista; отечественные – СЕТЬ, СЕТОР, КОМПАС, БАНК.

Реляционная модель данных

Реляционная модель данных предполагает, что данные представляются одним способом, а именно в виде таблицы (см. рис.52). Каждая строка в таблице содержит информацию, относящуюся к конкретному экземпляру объекта. Эта информация представляет собой набор фактов, при этом в столбце (называемым также атрибутом или полем) содержится конкретный факт.

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

Рассмотрим смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

Рис.52 Общая схема реляционной модели данных

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

Домен. Допустимые значения атрибутов. Так домен для поля «Имя» определен на базовом типе строк символов, т.е. является множеством всех возможных имен (в частности, такие строки не могут начинаться с мягкого знака). Различные атрибуты могут быть определены на одном и том же домене – например, атрибуты «Год поступления» (в вуз) и «Год окончания» определены на одном и том же домене, являющемся перечнем дат определенного диапазона.

Атрибут. Столбцы таблицы, называемые полями БД, соответствуют атрибутам экземпляров объекта. Атрибут – столбец таблицы. Название столбца – имя атрибута.

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

Одна таблица представляет один объект и состоит из строк и столбцов. Каждая строка таблицы представляет собой одну запись, а каждый столбец – одно поле записи.

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

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

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

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

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

Рис.53 Пример связи в реляционных таблицах

В приведенных таблицах-отношениях связь осуществляется по ключевому полю таблицы Отделы (№ отдела) и внешнему полю таблицы Сотрудник (№ отдела).

Само слово реляционная происходит от английского relation – отношение. В случае реляционных баз «отношение» выражает не взаимосвязь между таблицами, а определение самой таблицы как математического отношения доменов.

Фундаментальные свойства отношений

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

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

Исходное ненормализованное отношение (см. рис.54).

ОТДЕЛЫ

Номер_отдела	Отдел
	Сотр_номер	Сотр_имя	Сотр_зарп
310	2934	Иванов	144,00
	2935	Киреев	155,00
313	2936	Федотов	132,00
315	2937	Ильин	180,00

Рис.54 Ненормализованное отношение

Отношение в первой нормальной форме

СОТРУДНИКИ

Номер_отдела	Сотр_номер	Сотр_имя	Сотр_зарп
310	2934	Иванов	144,00
310	2935	Киреев	155,00
313	2936	Федотов	132,00
315	2937	Ильин	180,00

Рис.55 Пример приведения отношения к первой нормальной форме

На рисунке 54 приведен пример ненормализованной таблицы ОТДЕЛЫ, имеющей составное (делимое) поле «Отдел» с множественными значениями по полям «Сотр_номер», «Сотр_имя», «Сотр_зарп». Приведение таких таблиц к первой нормальной форме осуществляется путем образования составных ключей, при которых устраняются ситуации с множественными значениями полей (жирной рамкой выделены ключевые поля). Вторая таблица Сотрудники этого рисунка находится в первой нормальной форме (рис. 55).

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

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

Операции над данными в реляционной модели

Все операции над данными в реляционной модели можно разделить на две группы: операции обновления таблиц-отношений и операции обработки таблиц-отношений.

К операциям обновления относятся:

1.Операция Включить – добавляет новый кортеж в таблицу-отношение. Требует задания имени таблицы и обязательного значения ключей. Выполняется при условии уникальности значения ключа. Добавить новую строку со значением ключа, которое уже есть в таблице невозможно.

2.Операция Удалить – удаляет один или группу кортежей. Требует задания имени таблицы, имени поля и параметров значения полей, кортежи с которыми должны быть удалены.

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

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

К операциям обработки относятся:

1. Операция Объединения – выполняется над двумя односхемными таблицами-отношениями. Результатом объединения является построенная по той же схеме таблица-отношение, все кортежи первой таблицы и все кортежи второй таблицы. При этом кортежи-дубликаты в итоговой таблице устраняются (рис.56).

СКЛАД 1				СКЛАД 2
№	Код поставщика	Название материала		№	Код поставщика	Название материала
К11	2040	МЕЛ		К21	5010	МЕЛ
К12	4050	ТЕТРАДЬ		К22	2040	МЕЛ
К13	3070	КАРАНДАШ		К23	6020	РУЧКА

Таблица, полученная в результате операции объединения

СКЛАД
№	Код поставщика	Название материала
К11	2040	МЕЛ
К12	4050	ТЕТРАДЬ
К13	3070	КАРАНДАШ
К21	5010	МЕЛ
К23	6020	РУЧКА

Рис.56 Иллюстрация операции объединения

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

После выполнения операции пересечения над исходными таблицами-отношениями получим:

2040. МЕЛ

3. Операция Вычитания выполняется над двумя односхемными таблицами-отношениями. Результатом является таблица-отношение, построенная по той же схеме и содержащая только те кортежи первой таблицы, которых нет в составе кортежей второй таблицы.

После выполнения операции вычитания над исходными таблицами-отношениями получим:

4050. ТЕТРАДЬ

3070. КАРАНДАШ

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

Сотрудники первого отдела		Прохождение обследования			Прохождение обследования сотрудниками первого отдела
ФИО		Вид обследования	Дата		ФИО	Вид обследования	Дата
Иванов И.И.		Сердечно-сосудистая система	1.12		Иванов И.И.	Сердечно-сосудистая система	1.12
Петров П.П.		Желудочно-кишечный тракт	8.12		Иванов И.И.	Желудочно-кишечный тракт	8.12
					Петров П.П.	Сердечно-сосудистая система	1.12
					Петров П.П.	Желудочно-кишечный тракт	8.12

Рис.57 Иллюстрация операции декартова произведения

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

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

Служащие
Фамилия	Номер лаборатории	Должность
Иванов	01	инженер
Петров	02	инженер
Сидоров	01	инженер
Федоров	02	экономист

Берется проекция на поля «Номер лаборатории» и «Должность»

Номер лаборатории	Должность
01	инженер
02	инженер
02	экономист

Рис.58 Иллюстрация выполнения операции проекция

Смысл операции проекции – переупорядочить столбцы в таблице-отношении и удалить одинаковые кортежи (кроме одного)

7) Операция Соединения – выполняется над таблицами-отношениями с различными схемами. В каждой таблице-отношении выделяется поле, по которому будет осуществляться соединение. При этом оба поля должны быть определены на одном и том же домене. Схема итоговой таблицы-отношения включает все поля первой таблицы-отношения и все поля второй таблицы-отношения (как в произведении). Кортежи итоговой таблицы-отношения образуются путем сцепления каждого кортежа из первой таблицы с теми же кортежами второй таблицы, значения которых по полю сцепления одинаковы (рис.59).

Документы с охраняемыми сведениями по ОКР				Журнал выдачи документов сотрудникам
Рег. №	Тематика		Рег. №		Дата	ФИО
13/1-С	Топливо		12345		1.11	Иванов И.И.
251-СС	Боезаряд		65432		1.11	Иванов И.И.
1455-С	Двигатель		251-СС		2.11	Петров П.П.
И-43С	Привод		И-43С		2.11	Сидоров С.С.
			123-4/С		3.11	Петров П.П.
			345		3.11	Егоров Е.Е.
			1455-С		4.11	Петров П.П.
			675-И/С		4.11	Сидоров С.С
			И-43С		3.11	Петров П.П.

Соединение по полю «Рег.№»

Сотрудники, работающие с документами, содержащими охранные сведения
Рег. №	Тематика	Дата	ФИО
251-СС	Боезаряд	2.11	Петров П.П.
1455-С	Двигатель	4.11	Петров П.П.
И-43С	Привод	2.11	Сидоров С.С.
И-43С	Привод	3.11	Петров П.П.

Рис.59 Иллюстрация выполнения операции соединения

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

Таблица-делимое Таблица делитель

Поездки граждан г. Урюпинска в Германию				Требуемое сочетание турфирм и городов Германии
ФИО	Турфирма	Город		Турфирма	Город
Иванов И.И.	«Евротур»	Берлин		«Евротур»	Берлин
Иванов И.И.	«Веси»	Гамбург		«Веси»	Гамбург
Петров П.П.	«Евротур»	Гамбург
Петров П.П.	«Веси»	Берлин
Сидоров С.С.	«Евротур»	Берлин
Сидоров С.С.	«Веси»	Гамбург

Рис.60 Иллюстрация выполнения операции деления

Гражданин с требуемым сочетанием турфирм и городов

ФИО

Иванов И.И.

Сидоров С.С.

Рассмотренные операции реализуются соответствующими средствами СУБД (язык SQL).

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

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

1. быстрый доступ к данным БД;

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

3. целостность данных: при изменении одних объектов автоматически соответствующим образом изменяются связанные с ними объекты.

Теорию нормализации отношений в реляционной модели разработал Э. Кодд. Сначала использовалось 3 нормальные формы, позже были выделены еще две, т.е. разработаны 5 нормальных форм таблиц. Каждая последующая (от 1 до 5) нормальная форма должна удовлетворять требованиям предыдущей и некоторым дополнительным условиям. 4 и 5 формы при практическом проектировании, как, правило, не применяются.

Рассмотрим, какие проблемы могут возникнуть из-за небрежного проектирования БД и как их избежать при помощи стандартных принципов, называемых нормализацией.

Таблица 10.

Пример ненормализованной БД

Работник
Код работника	ФИО	Тип специальности	Код здания
1235	Петров И.И.	электрик	312
1235	Петров И.И.	электрик	515
1412	Сидоров В.В.	штукатур	312
1412	Сидоров В.В.	штукатур	460
1412	Сидоров В.В.	штукатур	435
1412	Сидоров В.В.	штукатур	515
1311	Корнеев А.А.	электрик	435

Реляционная таблица10 спроектирована неудачно. В 4-х кортежах, соответствующих рабочему 1412, повторяется одно и то же имя и информация о типе специальности. Эта избыточность данных или повторение приводит не только к потере лишнего места; она может вызвать нарушение целостности данных в БД.

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

Аномалия обновления. Противоречивость данных, вызванная избыточностью и частичным обновлением.

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

Аномалия удаления. Непреднамеренная потеря данных, вызванная удалением других данных.

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

Аномалия ввода. Невозможность ввести данные в таблицу, вызванная отсутствием других данных.

Аномалии ввода, удаления и обновления нежелательны. Чтобы свести к минимуму эти проблемы нужно разделить реляционную таблицу Работник на две таблицы Работник и Назначение. Это решение интуитивное. Воспользуемся нормальными формами или правилами структурирования таблиц.

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

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

Таблица 11.

Таблица, нарушающая 1НФ

Работник
Код работника	ФИО	Тип специальности	Код здания
1235	Петров И.И.	электрик	312, 515
1311	Иванов И.В.	штукатур	312, 460,510
1412	Сидоров В.В.	штукатур	460

Данная таблица 11 не соответствует 1НФ, т.к. значения атрибута Код здания не являются атомарными. Для первого и второго кортежей значение Код здания может иметь несколько значений. Чтобы таблица 11удовлетворяла 1НФ, она должна выглядеть так:

Таблица 12

Таблица в 1НФ

Работник
Код работника	ФИО	Тип специальности	Код здания
1235	Петров И.И.	электрик	312
1235	Петров И.И.	электрик	515
1311	Иванов И.В.	штукатур	312
1311	Иванов И.В.	штукатур	460
1311	Иванов И.В.	штукатур	510
1412	Сидоров В.В.	штукатур	460

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

Функциональные зависимости

Функциональные зависимости (ФЗ) накладывают дополнительные ограничения на реляционную схему. Основная идея состоит в том, что значение одного атрибута в кортеже однозначно определяет значение другого атрибута. В таблице Работник Код работника однозначно определяет ФИО, Тип специальности. Эти функциональные зависимости записываются так:

ФЗ: Код работника → ФИО; Код работника → Тип специальности

Символ → читается «функционально определяет»

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

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

Вторая и третья нормальные формы касаются отношений между ключевыми и не ключевыми атрибутами.

Вторая нормальная форма. Никакие не ключевые атрибуты не являются функционально зависимыми лишь от части ключа. Т.о. 2НФ может оказаться нарушенной, если ключ составной.

Таблица 13.

Таблица, нарушающая 2НФ

Назначения
Код работника	Код здания	Дата начала	ФИО
1235	312	10.10	Иванов И.И.
1412	312	01.11	Петров П.П.
1235	510	17.10	Иванов И.И.
1412	460	08.12	Петров П.П.
1412	335	15.10	Петров П.П.

Ключ (табл. 13) состоит из двух атрибутов. ФИО определяется атрибутом Код работника и, следовательно, функционально зависит от части ключа. Для определения имени работника нужно знать Код работника. Таблица не удовлетворяет 2НФ, могут возникнуть проблемы:

1. Имя работника повторяется в каждой строке, относящейся к назначению этого работника;

2. при изменении имени требуется обновить все строки, содержащие записи о назначениях этого работника;

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

4. если в какой-то момент времени работник не имеет назначений, то может не оказаться строки, в которой можно хранить имя работника. Это аномалия ввода.

Для того чтобы решить эти проблемы, таблицу необходимо разбить на две реляционные таблицы, каждая из которых удовлетворяет 2НФ.

Работник (Код работника, ФИО)

Назначения (Код работника, Код здания, Дата начала).

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

Процесс разбиения состоит из следующих шагов:

1. создается новая таблица, атрибутами которой будут атрибуты исходной таблицы, входящую в противоречащую правилу ФЗ. Детерминант ФЗ становится ключом новой таблицы;

2. Атрибут, стоящий справа в ФЗ, исключается из исходной таблицы;

3. если более одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ;

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

Третья нормальная форма

Реляционная таблица имеет 3НФ, если для любой ФЗ: Х → Y детерминант Х является ключом. Из определения следует, что любая таблица, удовлетворяющая 3НФ, также удовлетворяет 2НФ. Однако обратное неверно.

Третья нормальная форма. Любой детерминант является ключом.

Таблица 14.

Таблица, нарушающая 3НФ

Работник
Код работника	Тип специальности	Премиальные
1235	электрик	3.5
1412	штукатур	3.0
1311	электрик	3.5

В табл. 14 имеются следующие функциональные зависимости:

ФЗ: Код работника →Тип специальности

Код работника → Премиальные

Однако имеется ФЗ: Тип специальности → Премиальные

Первые две ФЗ удовлетворяют 3НФ, а последняя - нет, т.к. Тип специальности не является ключом. Таблица Работник не удовлетворяет 3НФ, однако удовлетворяет 2НФ. Недостатки таблицы, не удовлетворяющей 3НФ:

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

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

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

К таблице, нарушающей 3НФ, нужно применить разбиение. Из реляционной таблицы Работник удалим все атрибуты, стоящие в правой части ФЗ, нарушающие 3НФ (это Премиальные). Создадим новую таблицу, состоящую из атрибутов как из левой, так и из правой частей ФЗ, нарушающей 3НФ. Детерминант Тип специальности будет ключом.

Работник (Код работника, Тип специальности)

Премиальные (Тип специальности, Премиальные)