Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

4.5. Нормальные формы

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

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

Из таблиц, рассмотренных в п. 4, не удовлетворяет этим требованиям (т.е. не находится в 1НФ) только таблица рис. 4.1.

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

Кроме таблицы рис. 4.1 не удовлетворяет этим требованиям только таблица 4.2.

Как обосновано ниже (пример 4.2) она имеет составной первичный ключ

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П

и содержит множество неключевых полей (Вид, Рецепт, Порций, Калорийность и т.д.), зависящих лишь от той или иной части первичного ключа. Так поля Вид и Рецепт зависят только от поля Блюдо, Калорийность – от поля Продукт и т.п. Следовательно, эти поля не связаны с первичным ключом полной функциональной зависимостью.

Ко второй нормальной форме приведены почти все таблицы рис. 4.3 кроме таблицы Поставщики, в которой Страна зависит только от поля Город, который является частью первичного ключа (Поставщик, Город). Последнее обстоятельство приводит к проблемам при:

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

Разбивая эту таблицу на две таблицы Поставщики и Города (рис. 3.2), можно исключить указанные аномалии.

Что же касается таблиц рис. 4.4, то ввод в них отсутствующих в предметной области цифровых первичных и внешних ключей формально затрудняет процедуру выявления функциональных связей между этими ключами и остальными полями. Действительно, легко установить связь между атрибутом Блюдо и Вид (блюда): Харчо – Суп, Лобио – Закуска и т.п., но нет прямой зависимости между полями БЛ и Вид (блюда), если не помнить, что значение БЛ соответствует номеру блюда.

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

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

При использовании этой рекомендации таблицы рис. 4.4 временно превращаются в таблицы рис. 4.3, а после выполнения нормализации и восстановления полей БЛ, ПР и ПОС – в нормализованные таблицы рис. 3.2.

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

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

Как ни странно, этого нельзя сказать об аналогичных таблицах рис 4.4. Если забыть рекомендацию о подмене на время нормализации ключей БЛ, ПР и ПОС на Блюдо, Продукт и (Поставщик, Город), то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ. Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевыми – появились несуществовавшие ранее функциональные зависимости между неключевыми полями:

Блюдо->Вид и Продукт->Калорийность.

Следовательно, для приведения таблиц Блюда и Продукты рис. 4.4 к 3НФ их надо разбить на

Блюда(БЛ, Блюдо),
Вид_блюда(БЛ, Вид);
Продукты(ПР, Продукт);
Калор_прод(ПР,Калорийносить),

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

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

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

В соответствие с этой формулировкой таблицы Блюда и Продукты рис. 4.4, имеющие по паре возможных ключей (БЛ и Блюдо) и (ПР и Продукт) находятся в НФБК или в 3НФ.

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

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

Например, естественным соединением (см. п. 3.3) таблиц рис. 4.3 можно образовать исходную таблицу, приведенную на рис. 4.2. Ту же таблицу можно получить композицией таблиц рис. 3.2. Следовательно, таблицы рис. 4.3, 4.4 и 3.2 являются полными декомпозициями таблицы Питание рис. 4.2.

Теперь можно дать определения высших нормальных форм. И сначала будет дано определение для последней из предложенных – 5НФ.

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

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

[Назад] [Содержание] [Вперед]

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...