Кубанский государственный университет
Опубликован: 24.12.2013 | Доступ: свободный | Студентов: 681 / 8 | Длительность: 24:28:00
Лекция 5:

Нормализация

5.8 Сущности с пересекающимися ключами. Нормальная форма Бойса-Кодда. Определение. Правило приведения

Рассмотрим последнюю нормальную форму, определенную через обычные функции и использующую теорему Хиса. Нормальную форму Бойса-Кодда (НФБК) в свое время называли исправленной третьей нормальной формой. Дело в том, что в классической работе Кодда от 1970 г. не было учтено, что первичных ключей может быть несколько, но это не беда. Проблемы возникают, когда первичные ключи пересекаются.

На рисунке 5.7 приведен пример сущности с несколькими непересекающимися ключами: "Табельный номер", "ИНН", "ФИО", "Дата_рождения", "Паспорт_данные". Как всегда, выбираем один из ключей в качестве первичного, а оставшиеся будут альтернативными ключами.

 Пример сущности с непересекающимися ключами

Рис. 5.7. Пример сущности с непересекающимися ключами

Сущности с пересекающимися ключами интереснее. Рассмотрим в качестве примера сущность "Поставка" (таблица 5.5).

Таблица 5.5. Сущность "Поставка"
КОДПОСТАВЩИКА НАИМПОСТАВЩИКА КОД_ТОВАРА ЕД_ИЗМЕРЕНИЯ кол
171 ООО "Зенит" 11 пара 70
171 ООО "Зенит" 02 кг. 250
171 ООО "Зенит" 90 ШТ. 1
030 ЗАО "Остов" 02 КГ. 100
030 ЗАО "Остов" 03 ШТ. 15

В нем имеется два пересекающихся ключа: РК1 = {Код_поставщика, Код_товара} и РК2 = {Наим_поставщика, Код_товара}. Поскольку неключевой атрибут "Ед_измерения" связан функционально с атрибутом "Код_то-вара", являющегося частью обоих ключей, то для приведения к 2НФ выделяем сущность "Товар" (таблица 5.6)

Таблица 5.6. Сущность "Товар"
КОД_ТОВАРА ЕД_ИЗМЕРЕНИЯ
11 пара
02 кг.
90 шт.
03 шт.

Атрибут "Ед_измерения" играет особую роль. Он раскрывает какой-то смысл атрибута "Код_товара". Если не учитывать семантику, то можно, например, посчитать осмысленным вопрос "Какое количество товара поставлено?" относящийся к сущности "Поставка". Но ведь товары в сущности "Поставка" имеют разные единицы измерения. Поэтому осмысленно только суммирование товаров с одной единицей измерения, да и то не всегда. Например, объединение пар носков и пар кроликов не всегда может быть оправданным. Подробнее смыслами мы будем заниматься в "Семантика баз данных" .

Заметим, что выделение сущности "Товар" не имеет никакого отношения к приведению в НФБК. Просто был повод еще раз вспомнить о смыслах данных.

Рассмотрим созданную сущность "Поставка_1" (таблица 5.7). Поскольку неключевой атрибут "Количество" единственный, то не существует зависимостей неключевых атрибутов от других неключевых атрибутов и сущность находится в третьей нормальной форме.

Таблица 5.7. Сущность "Поставка_1"
КОДПОСТАВЩИКА НАИМПОСТАВЩИКА КОД ТОВАРА КОЛ
171 ООО "Зенит" 11 70
171 ООО "Зенит" 02 250
171 ООО "Зенит" 90 1
030 ЗАО "Остов" 02 100
030 ЗАО "Остов" 03 15

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

Ключи у сущности "Поставка_1" те же, что у сущности "Поставка":

РК1 = {Код_поставщика, Код_товара}

РК2 = {Наим_поставщика, Код_товара} Выпишем сначала все оставшиеся функциональные зависимости:

РК1 \to Наим_по став шика, Количество

РК2 \to Код_поставщика, Количество

РК1 \to Наим_по став шика,

РК2 \to Код_поставщика

Код_по ставшика \to Наим_поставщика

Наим_поставщика \to Код_поставщика

Отмеченная аномалия устраняется выделением отношений "Поставщик" (таблица 5.8) и "Поставка_2" (таблица 5.9).

Таблица 5.8. Сущность "Поставщик"
КОД_ПОСТАВЩИКА НАИМ_ПОСТАВЩИКА
171 ООО "Зенит"
030 ЗАО "Остов"
Таблица 5.9. Сущность "Поставка_2"
КОД_ПОСТАВЩИКА КОД_ТОВАРА КОЛИЧЕСТВО
171 11 70
171 02 250
171 90 1
030 02 100
030 03 15

Перейдем к определениям, чтобы понять, как получать сущности в НФБК.

Любое расширение потенциального ключа есть ключ, но не минимальный ключ. Будем называть его суперключом.

Определение (Тривиальная функциональная зависимость). Функциональная зависимость f:A\to B тривиальна тогда и только тогда, когда правая часть функциональной зависимости является подмножеством, не обязательно собственным, левой части, то есть когда B \subseteq A.

Определение (НФБК). Отношение находится в НФБК тогда и только тогда, когда каждая нетривиальная функциональная зависимость имеет аргументом суперключ.

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

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

В нашем примере аргумент функции не является суперключом у функций

Код_поставщика \to Наим_поставщика

Наим_поставщика \to Код_поставщика

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

Можно с самого начала выписывать все ключи и получать НФБК или 3НФ, но в сложных случаях лучше идти по шагам, или же получить декомпозицию одним методом, а проверить результат другим.

Примем без доказательства простое утверждение: Любое отношение с двумя атрибутами находится в НФБК.

5.9 Нормальная форма схемы. Сходимость нормализации

Определение. Говорят, что схема базы данных находится в нормальной форме X, если каждая ее сущность находится в нормальной форме не ниже X.

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

Вспомним, как изучается любая структура в математике. Во-первых, стоит убедиться, что множество, на котором она определена, нетривиально. Я думаю, нам можно не доказывать нетривиальность области изучения. Известно, что базы данных широко используются, и что при этом употребляются реляционная модель и модель сущность-связь. Так что на эту тему можно не рассуждать.

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

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

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

То, что процесс нормализации по Хису в теории всегда сходится, не означает, что сходится любой процесс проектирования. Когда может случиться такая неприятность? При неточностях в задании (спецификации проекта), когда вы в процессе работы его уточняете. При выяснении подробностей еще раз уточняете, то есть, когда задание, как говорят, "плывет". Утверждение о сходимости нормализации относится только к такому случаю, когда исходное задание не меняется.

5.10 Простой способ получения отношений сразу в третьей нормальной форме и уточнения до НФБК

  1. Выделите простые сущности, не содержащие в себе другие сущности и не имеющие составных атрибутов, групп однородных атрибутов и множественных атрибутов. Если этот этап выполнен правильно, получена 1НФ. Может показаться странным, но при достаточном опыте первый этап почти всегда удается выполнить корректно. Хороший разработчик интуитивно понимает, что где-то что-то не так, и, после выполнения предварительного варианта схемы, он уточняет проблемные участки. Человек - существо ошибающееся, поэтому хорошо себя проверять почаще.
  2. Уточните ключевые атрибуты, выделив все альтернативные ключи. Чтобы окончательно убедиться в простоте сущностей проверьте наличие функциональных зависимостей кроме зависимостей от ключа. Лучше список зависимостей выписывать явно. Если они обнаружены, декомпозируйте такие сущности по Хису, руководствуясь правилами преобразования для 2НФ и 3НФ. Заметьте, эта перестраховка очень полезная штука. Преобразуя схему, вы многое увидите просто по-другому.
  3. Если есть пересекающиеся ключи, выявите зависимости, у которых аргумент не является суперключом, и, используя теорему Хиса, выделите новую сущность, используя все атрибуты этой зависимости. Хочу заметить, что очень часто можно останавливаться на 3НФ, но лучше этот алгоритм реализовать полностью - так безопасней. Все-таки НФБК в практике иногда встречается.