Давайте перейдем к рассмотрению основных типов денормализации. Одни из них мы рекомендуем, а другие - нет (или рекомендуем, но только в исключительных случаях).

Нисходящая денормализация

Нисходящая денормализация предполагает перенос атрибута из родительской сущности в дочернюю. На рис. 4.2 видно, что в денормализо ванной логической модели мы переместили фамилию клиента из сущности Customer ( Клиент ) в сущность Order ( Заказ ). Вообще говоря, мы советуем не делать этого\ Однако почему же перенос атрибута сделан в данном случае? Единственный выигрыш заключается в том, что мы избежим операции соединения, если захотим вместе с заказом увидеть фамилию клиента.

До денормализации customed <

ADDRESS NAME

TELEPHONE

После денормализации customer

ADDRESS NAME

TELEPHONE

Order

ORDER# DATE TAKEN DATE DISPATCHED DATE INVOICED CUB ID

Order

ORDER# DATE TAKEN DATE DISPATCHED DATE INVOICED CUSJD CUB NAME

Puc. 4.2. Пример нисходящей денормализации

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

Из нашего опыта следует, что нисходящая денормализаця оправдана лишь в приложениях хранилищ данных для устранения соединений. Это вызвано тем, что данные в хранилищах - архивные, и поэтому каскадные

обновления для них не характерны. Без нисходящей денормализации в таких приложениях во многих запросах может понадобиться соединение таблицы, содержащей миллиард строк, еще с несколькими таблицами значительного размера, что является очень трудоемкой задачей, если не сказать больше. (Хранилища данных подробно рассматриваются в главе 13.)

Восходящая денормализация

В случае, показанном на рис. 4.3, мы сохраняем информацию из дочерней сущности в родительской - в форме итога.

До денормализации

ORDER

ORDER# DATE TAKEN DATE DISPATCHED DATE INVOICED CUSJD CUS NAME

После денормализации

окбея

ORDER

DATET DATE С DATE II CUSJC CUS NAmE ORDER PRICE

aCHED i CED !

ITElvifr ITEM f

NO ORDERED

ITEMfr

ITEMJ E

NO O! 4ED

Puc. 4.3. Пример восходящей денормализации

Рассмотрим простой, но классический пример, показанный в табл. 4.1. * Таблица 4 1. Функции по ведению денормализованных значений i

Собьпие в таблице ORDER ITEM

Действия в соответствующей таблице ORDER

Добавлена новая строка Удалена строка Изменена цена

Цена заказа (ORDER PRlCE) увеличена на цену (ITEM PRICE) новой позиции заказа

Цена заказа (ORDER PRlCE) уменьшена на цену (ITEM PRICE) старой позиции заказа

Цена заказа (ORDER PRICE) откорректирована на разницу между старой и новой ценой (1TEM PRICE) позиции заказа

Если в некоторых критичных функциях системы обработки заказов требуется вычислять общую сумму заказа (суммы ITEM PRICE в сущностях 0RDER ITEM), то мы можем повысить производительность этих функций, поместив сумму заказа в избыточном столбце таблицы ORDER (в нашем примере он называется ORDER PRICE, Цена заказа ). Дополнительные административные задачи, которые возникают при этом, перечислены в табл. 4.1. Однако это создает дополнительную нагрузку на процессы, выполняющие DML-операции в таблице ORDER ITEM. Это и есть цена, которую мы вынуждены заплатить за повышение производительности запросов. В нашем примере в избыточном столбце хранится сумма значений, но эти приемы применимы к максимальным, минимальным и средним значениям, а также к другим агрегатным показателям.

Методы реализации денормализации

в предыдущем примере мы описали некоторые задачи по управлению денормализованными данных. Однако как же конкретно выполнять эти задачи? В давние времена (Oracle версии 6 и раньше) каждое приложение, генерирующее DML-операции для таблицы ORDER ITEM, отвечало за обеспечение целостности всех денормализованных столбцов путем выполнения необходимого для этого действия (действий). Это неизбежно приводило к противоречиям в данных. Даже если вы тщательно протестировали приложение, кто-нибудь мог воспользоваться инструментом типа SQL*Plus и быстренько починить данные (например, удалить неверную позицию заказа), забыв при этом соответствующим образом откорректировать денор-мализованные или производные столбцы.

Это привело к необходимости создания специальных скриптов для баз данных Oracle версии 6, обеспечивающих проверку целостности денормализованных данных и выдачу сообщений о нарушениях. Эти скрипты должен был периодически прогонять администратор базы данных. Ниже приведен пример такого скрипта для таблиц, построенных от сущностей ORDER и ORDER ITEM (после денормализации):

SELECT ord.order# FROM orders ord WHERE ord.order price <> (SELECT SUM(oit.itera price)

FROM order iteras oit WHERE oit.ord order# = ord.order#);

Ho эти времена прошли, и авторы подобных скриптов могут отложить клавиатуры, выключить свет и идти домой - Oracle? позволяет поддерживать денормализацию при помощи триггеров базы данных. Правда, не следует торопиться отпускать последнего автора скриптов - поскольку триггеры можно выключать, нет способа проверки данных, проскользнувших в сис-ему, пока триггеры спали . По этой пр№1ине старые диагностические