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

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

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

поскольку:
Особые требования к производительности СУБД учитываются на следующем этапе физического

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

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

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

и 5-я (4НФ и 5НФ).
Однако на практике они используются крайне

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

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

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

— получение некоторого набора таблиц путем группирования атрибутов.
Это нужно сделать

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

избыточные данные, поскольку сведения по кафедре повторяются для каждого сотрудника

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

обновлять этот атрибут сразу для нескольких сотрудников.
Могут возникать противоречия в

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

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

и данные о кафедре, на которой будет работать этот сотрудник.
Ошибки

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

функциональные зависимости (ФЗ), которые описывают существующие взаимосвязи между атрибутами.
Если в

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

детерминантом атрибута или группы В.
Например, в таблице ПРЕПОДАВАТЕЛИ по значению

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

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

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

на пересечении каждой строки и каждого столбца содержится одно и

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

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

таблице.

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

все столбцы таблицы).

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

которая находится в форме 1НФ, а также характеризуется полной функциональной

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

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

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

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

Н_аренды, К_аренды)
Все полученные таблицы находятся в форме 2НФ, поскольку для

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

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

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

у этого владельца изменился телефон, то потребуется в таблице ОБЪЕКТЫ

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

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

которая находится в форме 2НФ, а также не имеет транзитивных

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

транзитивную ФЗ от ключевого атрибута Код_об.
Для устранения этой ФЗ необходимо

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

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

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

ключей.

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

и 3НФ рассматриваются только ФЗ от первичного ключа.
Следовательно, в таблицах

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

ключом.
Нарушения требований НФБК происходят крайне редко, поскольку это может случиться

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

Следовательно, для проверки требований НФБК необходимо: