Лекция №5 Нормализация отношений
Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).
Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией.
Цель нормализации: исключить избыточное дублирование данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей(строк таблицы).
Аномалией называется такая ситуация в таблице БД, которая приводит к противоречию в БД либо существенно усложняет обработку БД. Причиной является излишнее дублирование данных в таблице, которое вызывается наличием функциональных зависимостей от не ключевых атрибутов.
Аномалии-модификациипроявляются в том, что изменение одних данных может повлечь просмотр всей таблицы и соответствующее изменение некоторых записей таблицы.
Аномалии-удаления — при удалении какого либо кортежа из таблицы может пропасть информация, которая не связана на прямую с удаляемой записью.
Аномалии-добавления возникают, когда информацию в таблицу нельзя поместить, пока она не полная, либо вставка записи требует дополнительного просмотра таблицы.
О любой таблице данных, если она удовлетворяет определению отношения говорят, что она находится в 1 нормальной форме. То есть Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Например, есть таблица «Автомобили»:
Фирма | Модели |
BMW | M5, X5M, M1 |
Nissan | GT-R |
Фирма | Модели |
BMW | M5 |
BMW | X5M |
BMW | M1 |
Nissan | GT-R |
Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут зависит от Первичного Ключа(ПК).
Например, дана таблица:
Модель | Фирма | Цена | Скидка |
M5 | BMW | 5% | |
X5M | BMW | 5% | |
M1 | BMW | 5% | |
GT-R | Nissan | 10% |
Таблица находится в первой нормальной форме, но не во второй. Цена машины зависит от модели и фирмы. Скидка зависит от фирмы, то есть зависимость от первичного ключа неполная. Исправляется это путем декомпозиции на два отношения, в которых не ключевые атрибуты зависят от ПК.
Модель | Фирма | Цена |
М5 | BMW | |
Х5М | BMW | |
М1 | BMW | |
GT-R | Nissan |
Фирма | Скидка |
BMW | 5% |
Nissan | 10% |
Рассмотрим таблицу:
Модель | Магазин | Телефон |
BMW | Риал-авто | 87-33-98 |
Audi | Риал-авто | 87-33-98 |
Nissan | Некст-Авто | 94-54-12 |
Модель – первичный ключ данного отношения. Здесь мы видим, что Магазин функционально зависит от Модели, а телефон от Магазина. Таким образом телефон зависит и от Модели тоже, хоть и косвенно. Поэтому можно считать, что отношение находится во 2НФ. Такого рода зависимости между атрибутами:
Модель->Магазин->Телефон
называются транзитивными.
Отношение находится в 3НФ, если оно находится во 2НФ и не имеет транзитивных зависимостей.
Магазин | Телефон |
Риал-Авто | 87-33-98 |
Некст-Авто | 95-54-12 |
Модель | Магазин |
BMW | Риал-авто |
Audi | Риал-авто |
Nissan | Некст-Авто |
Отношение находится в НФБК если каждый детерминант является потенциональным ключом.
Пусть требуется хранить данные о поставках деталей некоторыми поставщиками. Предположим, что наименования поставщиков являются уникальными. Кроме того, каждый поставщик имеет свой уникальный номер. Данные о поставках можно хранить в следующем отношении:
Номер поставщика PNUM | Наименование поставщика PNAME | Номер детали DNUM | Поставляемое количество VOLUME |
Фирма 1 | |||
Фирма 1 | |||
Фирма 1 | |||
Фирма 2 | |||
Фирма 2 | |||
Фирма 3 |
Таблица 1 Отношение "Поставки"
Данное отношение содержит два потенциальных ключа - {PNUM, DNUM} и {PNAME, DNUM} и находится в 3НФ.
Отношение "Поставки" не находится в НФБК, т.к. имеются зависимости (PNUM PNAME и PNAME PNUM), детерминанты которых не являются потенциальными ключами.
Исправляем с помощью декомпозиции:
Таким образом, описанный ранее алгоритм нормализации неприменим к данному отношению. Очевидно, однако, что аномалия данного отношения устраняется путем декомпозиции его на два следующих отношения:
Номер поставщика PNUM | Наименование поставщика PNAME |
Фирма 1 | |
Фирма 2 | |
Фирма 3 |
Номер поставщика PNUM | Номер детали DNUM | Поставляемое количество VOLUME |
Дата добавления: 2017-08-01; просмотров: 825;