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

Отношение находится в НФБК тогда и только когда, когда каждый его детерминант является потенциальным ключом [1].

Детерминантом называется атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут [1].

Потенциальный ключ – это атрибут или группа атрибутов однозначно определяющие экземпляр отношения, но не являющиеся первичным ключом [1].

Для приведения отношения в НФБК необходимо функциональные зависимости, которые нарушают НФБК данного отношения, выделить в новые отношения. В новые отношения детерминанты копируются, а функционально-зависимые от них атрибуты переносятся.

Цель нормализации

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

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

Пример анализа функциональных зависимостей (продолжение проектирования информационной системы для сети магазинов по продажам сумок)

1. Определяем набор отношений и описываем их структуру с помощью DBDL

Продавец (Код продавца, ФИО, Код магазина, Рейтинг)

Первичный ключ: Код продавца

Внешний ключ: Код магазина ссылается на Магазин (Код магазина)

Магазин (Код магазина, Название, Адрес, Торговая площадь)

Первичный ключ: Код магазина

Товар (Код товара, Модель, Описание, Цена поставки, Поставлено всего, Количество в наличии, Код заказа, Код магазина, Цена для покупателя)

Первичный ключ: Код товара

Внешний ключ: Код магазина ссылается на Магазин (Код магазина)

Внешний ключ: Код заказа ссылается на Заказ (Код заказа)

Продажа (Код продажи, Дата продажи, Код товара, Код продавца, Выручка за товар)

Первичный ключ: Код продажи

Внешний ключ: Код продавца ссылается на Продавец (Код продавца)

Внешний ключ: Код товара ссылается на Товар (Код товара)

Заказ (Код заказа, № заказа, Дата заказа, Код поставщика, Срок, Дата поставки, Ситуация)

Первичный ключ: Код заказа

Внешний ключ: Код поставщика ссылается на Поставщик (Код поставщика)

Альтернативный ключ: № заказа, Дата заказа

Поставщик (Код поставщика, Название, Адрес, Рейтинг, Примечание)

Первичный ключ: (Код поставщика)

2. Выявляем все значимые функциональные зависимости

Отношение «Продавец»

Код продавца -> ФИО, Код магазина, Рейтинг

Отношение «Магазин»

Код магазина ->Название, Адрес, Торговая площадь

Отношение «Товар»

Код товара ->Модель, Описание, Цена поставки, Поставлено всего, Количество в наличии, Код заказа, Код магазина, Цена для покупателя

Модель ->Описание

Отношение «Продажа»

Код продажи-> Дата продажи, Код товара, Код продавца, Выручка за товар

Отношение «Заказ»

Код заказа->№ заказа, Дата заказа, Код поставщика, Срок, Дата поставки, Ситуация

№ заказа, Дата заказа-> Код заказа, Код поставщика, Срок, Дата поставки, Ситуация

Дата заказа, Срок, Дата поставки -> Ситуация

Отношение «Поставщик»

Код поставщика -> Название, Адрес, Рейтинг, Примечание

3. Приводим все отношения проектируемой информационной системы к нфбк или аргументируем отказ от нормализации

Отношения «Продавец», «Магазин», «Поставщик», «Продажа» находятся в НФБК

Отношение «Товар» находится во второй нормальной форме, для того чтобы привести его к третьей нормальной форме нужно убрать транзитивную зависимость

Модель ->Описание

Получим два отношения

1. Товар (Код товара, Модель, Цена поставки, Поставлено всего,

Количество в наличии, Код заказа, Код магазина, Цена для покупателя) Первичный ключ: Код товара

Внешний ключ: Код магазина ссылается на Магазин (Код магазина)

Внешний ключ: Код заказа ссылается на Заказ (Код заказа)

2. Модель (Модель, Описание) Первичный ключ: Модель

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

Оба отношения находятся в НФБК

Отношение «Заказ» находится во второй нормальной форме. Для того, чтобы привести его к третьей нормальной форме, нужно убрать транзитивную зависимость

Дата заказа, Срок, Дата поставки -> Ситуация

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

Можно удалить атрибут «Ситуация» из отношения «Заказ» и ввести его позже на этапе создания представлений для пользователей. Отношение «Заказ» будет выглядеть таким образом:

Заказ (Код заказа, № заказа, Дата заказа, Код поставщика, Срок, Дата поставки)

Первичный ключ: Код заказа

Внешний ключ: Код поставщика ссылается на Поставщик (Код поставщика)

Альтернативный ключ: № заказа, Дата заказа

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

Задание

1. Определить набор отношений на основе информационной модели данных (см. лабораторную работу № 3), в соответствии с выделенными сущностями, связями и атрибутами.

2. Описать структуру отношений с помощью DBDL.

3. Изучить правила приведения отношений к НФБК.

4. Выявить все значимые (нетривиальные) функциональные зависимости во всех отношениях.

5. Привести все отношения информационной системы к НФБК.

6. Ответить на контрольные вопросы.

7. Оформить отчет (Титульный лист, задание, IDEF1X диаграмма, набор отношений в DBDL, функциональные зависимости, отношения в НФБК).

1. Что такое отношения?

2. Что такое атрибут отношения?

3. Что такое функциональная зависимость?

4. Что такое детерминант функциональной зависимости?

5. Что такое первичный ключ?

6. Что такое потенциальный (альтернативный) ключ?

7. Что такое замыкание отношения?

8. Что такое тривиальная функциональная зависимость?

9. Что такое нормализация отношений? 10.Для чего необходима нормализация отношений? 11.Какие нормальные формы вы знаете? 12.Как определяется 1 нормальная форма? 13.Как определяется 2 нормальная форма? 14.Что такое транзитивная функциональная зависимость? 15.Как определяется 3 нормальная форма? 16.Как определяется нормальная форма Бойса-Кодда? 17.Есть ли обязательные нормальные формы для отношений в

Литература

1. Конноли, Томас. Базы данных. Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ./Конноли Томас, Бегг Каролин. – М.: Издательский дом «Вильямс», 2003.-1440 с.

2. Федотова, Д.Э. CASE-технологии: Практикум/ Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик. - М.: Горячая линия – Телеком, 2005. - 160 с.: ил.

3. Ожегов С.И. Толковый словарь.

4. Туманов Владимир Евгеньевич. Основы проектирования реляционных баз данных. Нормальные формы отношений. Создание логической модели реляционной базы данных.­http://www.intuit.ru/department/database/rdbdev/6/

5. Верников Геннадий. Обзор стандарта IDEF1X. ­http://www.idefinfo.ru/content/view/17/54/