Денормализация
Денормализация – это процесс достижения компромиссов в нормализованных таблицах посредством намеренного введения избыточности в целях увеличения производительности.
В большинстве случаев необходимость денормализации становится очевидной лишь на этапе проектирования модуля, то есть нельзя принять решение о декомпозиции на основании одной только модели данных.
Основные типы денормализации:
Нисходящая денормализация
Предполагает перенос атрибута из родительской сущности в дочернюю.
До денормализации После денормализации
Рис. 11.
Единственный выигрыш заключается в том, что мы избежим, операции соединения, если захотим вместе с заказом увидеть фамилию клиента.
Устранение соединений посредством исходящей денормализации редко оправдывает затраты на введение денормализованного столбца в таблицу Order.
Такие соединения не являются, как правило, глобальной проблемой, а выполнение нисходящей денормализации может привести к возникновению дорогостоящих каскадных обновлений, дающих небольшую реальную выгоду.
Например, если клиент меняет фамилию, то нам придется обновлять все заказы, чтобы отразить эти изменения. Следует ли это делать? Следует ли обновлять старые заказы, если они закрыты? Без денормализации эта проблема не возникла бы.
Нисходящая денормализация оправдана лишь в приложениях хранилищ данных для устранения соединений. Это вызвано тем, что в хранилищах данные архивные, и поэтому каскадные обновления для них не характерны.
Восходящая денормализация.
Информация из дочерней сущности сохраняется в родительской в форме итога.
До денормализации После денормализации
Рис. 12
Событие в таблице Order_Item |
Действия в соответствующей таблице Order |
Добавлена новая строка |
Цена заказа (Order_Price) увеличена на цену (Item_Price) новой позиции заказа. |
Удалена строка |
Цена заказа (Order_Price) уменьшена на цену (Item_Price) старой позиции заказа. |
Изменена цена |
Цена заказа (Order_Price) откорректирована на разницу между старой и новой ценой (Item_Price) позиции заказа. |
Если в некоторых функциях системы обработки заказов требуется вычислить общую сумму заказа (сумма Item_Price в сущностях Order_Item), то мы можем повысить производительность этих функций, поместив сумму заказа в избыточном столбце таблицы Order (Order_Price).
Однако, это создает дополнительную нагрузку на процессы, выполняющие DML-операции в таблице Order_Item. Это и есть цена, которую мы вынуждены заплатить за повышение производительности запросов.
Внутритабличная денормализация.
Выполняется в пределах одной таблицы. Причина - необходимость запроса строки по произвольному значению.
Например, строка содержит два числовых столбца X и Y. Z=X*Y легко вычислить во время выполнения.
Но есть запросы, в которых необходимо осуществить поиск по Z. Сохранить избыточные значения Zв столбце, можно построить индекс по Z и запросы будет использовать этот индекс.
“Разделяй и властвуй”.
Разбиение нормализованной таблицы на 2 и более таблиц и создание между ними отношений 1:1 можно классифицировать как форму денормализации. Часто это делают по технической причине.
В Oracle есть ограничение: таблица не может иметь больше одного столбца типа LONG (исходный код) или LONG RAW (объектный код).
Метод сжатия таблиц.
Один из примеров обоснования метода – наличие повторяющейся группы, которая гарантированно состоит из фиксированного числа элементов (таблица со строкой для каждого года или каждого дня недели).