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

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

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

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

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

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

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

В теории задачу нужно решать правильным выбором набора столбцов (композитный ключ), но практике обычно в таблице создается специальное поле (чаще всего - Integer со свойством Identity в SQL Server или столбец счетчика в Access), который уникально идентифицирует данную запись (суррогатный ключ). Такое решение обладает рядом преимуществ с точки зрения производительности и хранения данных.

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

Понятно, что от номера категории зависит, что будет стоять в столбце CategoryName и Description. Поэтому можно сказать, что атрибут CategoryID функционально определяет множество [CategoryName, Description]. Схема функциональной зависимости при этом может выглядеть так, как на рис. 4-2

Рис. 4-2.

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

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

Получить учебные материалы по этому курсу