Проверка таблиц с учетом требований нормализации

Содержание

Слайд 2

Однако это не должно быть аргументом для отказа от нормализации, поскольку:

Однако это не должно быть аргументом для отказа от нормализации, поскольку:

Особые

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

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

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

для каждой таблицы в составе логической модели БД.

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

Слайд 4

Основные этапы процесса нормализации

Основные этапы процесса нормализации

Слайд 5

Позднее были введены нормальные формы более высокого порядка — 4-я и

Позднее были введены нормальные формы более высокого порядка — 4-я и

5-я (4НФ и 5НФ).

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

Слайд 6

Взаимосвязи между отдельными НФ Как следует из этого рисунка, некоторые таблицы

Взаимосвязи между отдельными НФ

Как следует из этого рисунка, некоторые таблицы в

форме 1НФ могут одновременно находиться и в форме 2НФ.

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

Слайд 7

Избыточность и аномалии при изменении данных Основная цель проектирования реляционной БД

Избыточность и аномалии при изменении данных

Основная цель проектирования реляционной БД —

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

ПРЕПОДАВАТЕЛИ (Таб_номер, ФИО, Должность, Кафедра, Телефон, Комната) В этой таблице содержатся

ПРЕПОДАВАТЕЛИ (Таб_номер, ФИО, Должность, Кафедра, Телефон, Комната)

В этой таблице содержатся избыточные

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

1) Аномалии коррекции (обновления) При изменении телефона на какой-то кафедре потребуется

1) Аномалии коррекции (обновления)

При изменении телефона на какой-то кафедре потребуется обновлять

этот атрибут сразу для нескольких сотрудников.
Могут возникать противоречия в БД, если такая модификация затрагивает не все требуемые записи или допущены ошибки при вводе данных.
См. закон Мерфи: «Если какая-нибудь неприятность может произойти, то она обязательно случится».

2) Аномалии удаления
Если из таблицы удалить строку с данными о последнем сотруднике некоторой кафедры, то в БД не остается никаких сведений об этой кафедре.

Слайд 10

3) Аномалии вставки При добавлении сведений по новому сотруднику потребуется указать

3) Аномалии вставки

При добавлении сведений по новому сотруднику потребуется указать и

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

Функциональные зависимости между атрибутами Наиболее важное значение для процедуры нормализации имеют

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

Наиболее важное значение для процедуры нормализации имеют функциональные

зависимости (ФЗ), которые описывают существующие взаимосвязи между атрибутами.
Если в таблице R, содержащей атрибуты А и В, каждое значение атрибута А связано только с одним значением атрибута В, то атрибут В функционально зависит от атрибута А.
Эта ситуация обозначается как А→В.
В общем случае каждый из символов А или В может обозначать некоторую группу атрибутов.
Слайд 12

Для функциональной зависимости А→В атрибут или группа атрибутов А называется детерминантом

Для функциональной зависимости А→В атрибут или группа атрибутов А называется детерминантом

атрибута или группы В.

Например, в таблице ПРЕПОДАВАТЕЛИ по значению атрибута Таб_номер можно определить ФИО сотрудника и его должность.
Следовательно, атрибуты ФИО и Должность функционально зависят от атрибута Таб_номер:
Таб_номер → ФИО, Должность.
Можно также сказать, что атрибут Таб_номер является детерминантом для атрибутов ФИО и Должность.

Слайд 13

Функциональная зависимость А→В будет полной, если удаление какой-либо части из группы

Функциональная зависимость А→В будет полной, если удаление какой-либо части из группы

атрибутов А приводит к утрате этой зависимости.

Если в этом случае сохраняется некоторая ФЗ, то ее называют частичной.
Если в некоторой таблице R для атрибутов А, В и С существуют зависимости типа А→В и В→С, то говорят о транзитивной зависимости атрибута С от атрибута А через атрибут В.

Слайд 14

1-я нормальная форма (1НФ) Определение: Таблица находится в форме 1НФ, если

1-я нормальная форма (1НФ)

Определение: Таблица находится в форме 1НФ, если на

пересечении каждой строки и каждого столбца содержится одно и только одно атомарное значение соответствующего атрибута.
Если в таблице присутствуют элементы многоуровневой (иерархической) структуры, то от них нужно избавиться путем выравнивания таблицы, т.е. ее приведения к однородной структуре.
При выравнивании ненормализованной таблицы ячейки крупного размера разделяются на более мелкие части.
Слайд 15

сложная (неоднородная) структура простая (однородная) структура Значения, которые содержатся в крупных

сложная (неоднородная) структура

простая (однородная) структура

Значения, которые содержатся в крупных ячейках ненормализованной

таблицы, приходится повторять (дублировать).
Это порождает существенную избыточность в нормализованной таблице.
Слайд 16

Ненормализованная таблица «Аренда недвижимости»

Ненормализованная таблица «Аренда недвижимости»

Слайд 17

Ненормализованная таблица «Аренда недвижимости» содержит две полные строки – по клиентам

Ненормализованная таблица «Аренда недвижимости» содержит две полные строки – по клиентам

К76 и К56 (т.к. только в этих строках охватываются все столбцы таблицы).

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

Слайд 18

2-я нормальная форма (2НФ) Определение: 2-я нормальная форма (2НФ) соответствует таблице,

2-я нормальная форма (2НФ)

Определение: 2-я нормальная форма (2НФ) соответствует таблице, которая

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

С этой целью атрибуты, для которых существует частичная ФЗ, перемещаются в

С этой целью атрибуты, для которых существует частичная ФЗ, перемещаются в

новую таблицу вместе с копией их детерминанта.

Рассмотрим для примера таблицу «Аренда недвижимости» в форме 1НФ.
Для простоты предполагается, что каждый клиент не может повторно арендовать один и тот же объект.
Тогда первичный ключ будет состоять из атрибутов (Код_кл, Код_об).
Построим графическое представление всех ФЗ от атрибутов, входящих в первичный ключ.

Слайд 20

Видно, что здесь присутствуют две частичные ФЗ: Код_кл → ФИО_кл, Тел_кл

Видно, что здесь присутствуют две частичные ФЗ:
Код_кл → ФИО_кл, Тел_кл
Код_об →

Адрес, Плата, Код_вл, ФИО_вл, Тел_вл
Слайд 21

Вместо исходной таблицы «Аренда недвижимости» остается следующая таблица: АРЕНДА (Код_кл, Код_об,

Вместо исходной таблицы «Аренда недвижимости» остается следующая таблица:

АРЕНДА (Код_кл, Код_об, Н_аренды,

К_аренды)

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

Устранение этих ФЗ приведет к появлению двух новых таблиц:

КЛИЕНТЫ (Код_кл, ФИО_кл, Тел_кл);
ОБЪЕКТЫ (Код_об, Адрес, Плата, Код_вл, ФИО_вл, Тел_вл)

Слайд 22

К примеру, пусть одному владельцу принадлежит несколько объектов недвижимости. Тогда, если

К примеру, пусть одному владельцу принадлежит несколько объектов недвижимости.
Тогда, если у

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

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

Слайд 23

3-я нормальная форма (3НФ) Определение: 3-я нормальная форма (3НФ) соответствует таблице,

3-я нормальная форма (3НФ)

Определение: 3-я нормальная форма (3НФ) соответствует таблице, которая

находится в форме 2НФ, а также не имеет транзитивных зависимостей от первичного ключа для атрибутов, не входящих в этот ключ.
Чтобы привести таблицу к форме 3НФ, нужно атрибуты, для которых существует транзитивная ФЗ, переместить в новую таблицу вместе с копией их детерминанта.
Для таблицы ОБЪЕКТЫ можно записать следующие формулы:
Код_об → Код_вл; Код_вл → ФИО_вл, Тел_вл
Слайд 24

Это свидетельствует о том, что атрибуты ФИО_вл и Тел_вл имеют транзитивную

Это свидетельствует о том, что атрибуты ФИО_вл и Тел_вл имеют транзитивную

ФЗ от ключевого атрибута Код_об.

Для устранения этой ФЗ необходимо создать новую таблицу:
ВЛАДЕЛЬЦЫ (Код_вл, ФИО_вл, Тел_вл)
При этом таблица ОБЪЕКТЫ преобразуется к следующему виду:
ОБЪЕКТЫ_2 (Код_об, Адрес, Плата, Код_вл)
Таким образом, исходная таблица «Аренда недвижимости» преобразована в 4 таблицы.
Требования 3НФ удовлетворяются для каждой из этих таблиц.

Слайд 25

Процесс преобразования исходной таблицы в ходе ее нормализации можно представить в виде следующей схемы:

Процесс преобразования исходной таблицы в ходе ее нормализации можно представить в

виде следующей схемы:
Слайд 26

Исходную таблицу «Аренда недвижимости» можно восстановить путем соединения таблиц КЛИЕНТЫ, АРЕНДА,

Исходную таблицу «Аренда недвижимости» можно восстановить путем соединения таблиц КЛИЕНТЫ, АРЕНДА,

ОБЪЕКТЫ_2 и ВЛАДЕЛЬЦЫ за счет использования первичных и внешних ключей.

Следовательно, никаких потерь исходной информации не произошло и все взаимосвязи между элементами данных сохранены!

Слайд 27

Нормальная форма Бойса-Кодда (НФБК) При нормализации таблиц с учетом требований 2НФ

Нормальная форма Бойса-Кодда (НФБК)

При нормализации таблиц с учетом требований 2НФ и

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