Денормализация отношений

Иногда после нормализации отношений проводят их денормализацию. Обоснованием денормализации может служить требование обеспечения определённой производительности для критических запросов. В нормализованной БД одна сущность ПО разбивается на несколько отношений, и для получения исходного отношения требуется выполнить операцию соединения. Эта операция занимает много времени, поэтому нормализация может привести к падению производительности БД. Денормализация бывает нескольких видов:

1. Восходящая

Подразумевает перенос некоторой информации из подчинённого отноше-ния в родительское. Например, для схемы ЗАКАЗЫ <–>> СТРОКИ ЗАКАЗОВ обычно нужно знать общую сумму заказа, которая является вычисляемой величиной. Если эти вычисления производятся часто, то для повышения эффективности можно добавить в отношение ЗАКАЗЫ поле Общая сумма. При этом возникает проблема обеспечения актуальности значения этого поля: пересчёт общей суммы при добавлении новой строки заказа, при удалении и при модификации позиций заказа. Обычно эта проблема решается программно (в приложении) или с помощью триггеров БД.

1. Нисходящая

В этом случае информация переносится из родительского отношения в подчинённое. Например, в схеме ДОЛЖНОСТИ <–>> СОТРУДНИКИ можно в качестве внешнего ключа использовать поле Название должности, а не идентификатор. Для этого название в отношении ДОЛЖНОСТИ должно быть определено как unique. Это позволяет избежать соединения отношений при запросе должности сотрудника.

1. 3. Разбиение одного отношения на два.

В одно отношение помещаются все атрибуты сущности, которые связаны с экземпляром сущности как 1:1. Но бывает так, что запись имеет большую длину за счёт наличия атрибутов большого объёма (графические данные, текстовые описания и проч.). Если данные этих атрибутов редко используются, то можно выделить в отдельное отношение атрибуты большого объёма. Для связи с исходным отношением вводится уникальный внешний ключ. А для получения исходного отношения создаётся представление (view), которое является соединением двух полученных отношений.

После нормализации/денормализации получается окончательная концептуальная схема БД, на основе которой проводится физическое про-ектирование. Пример проектирования БД с использованием метода "сущность-связь" и нормализации отношений приведён в [2].