Совет №20
Разреженные факты и факты с коротким жизненным циклом

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбалл (все статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.

Таблицы фактов сроятся на основе числовых показателей. Когда выполняется измерение значения показателя, порождается запись в таблице фактов. Показатель может быть суммой продажи, суммой транзакции, нарастающим балансом в конце месяца, объёмом производства продукта, или даже классическим лабораторным измерением. Если мы одновременно снимаем значения нескольких показателей, мы можем поместить их все в одну и ту же запись таблицы фактов.

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

Мы упаковываем все вещи, о которых мы знаем, в записи таблицы измерений, сопровождаемые текстом, и соединяем факты с измерениями с помощью отношений внешний ключ / первичный ключ.

Это приводит к классической организации таблицы фактов (показанной здесь для N измерений и двух фактов с названиями Dollars и Units):

dimkey1 (FK)
dimkey2 (FK)
dimkey3 (FK)
...
dimkeyN (FK)
Dollars
Units

Поля Dollars и Units зарезервированы для соответствующих показателей. Этот дизайн содержит явные предположения о том, что
1) эти два показателя обычно оба присутствуют,
2) эти показатели являются единственными показателями данного процесса
3) существует большое количество событий с измерением величин показателей, другими словами, есть смысл посвятить эту таблицу с фиксированным форматом специально этим показателям.
Но что произойдёт, если все три этих предположения окажутся несправедливыми? Это часто случается при слежении за сложными финансовыми инвестициями, где каждый инструмент инвестирования имеет индивидуальные параметры. Это также случается в процессах промышленного производства где циклы загрузки коротки и каждый тип цикла имеет массу специальных показателей. Я, наконец, в клинических и медицинских лабораториях выполняются измерения сотен показателей, ни одно из которых не происходит часто. Все три этих примера можно охарактеризовать как "разреженные" факты.

Вы не можете просто расширить структуру классической таблицы фактов для обработки разреженных фактов. У вас получился бы неработоспособный список фактических полей, большинство из которых было бы не заполнено во отдельно взятой строке.

Решением является добавление специального "измерения фактов" и сокращение списка действительных числовых фактов до одного поля AMOUNT (количество):

dimkey1 (FK)
dimkey2 (FK)
dimkey3 (FK)
...
dimkeyN (FK)
factkey (FK) <== дополнительное измерение
Amount

"Измерение фактов" описывает значение поля Amount. Оно содержит то, что раньше было названием поля факта, а также единицу измерения и любые ограничения аддитивности. Например, если показатель похож на остаток (баланс), он может быть полностью аддитивным вдоль всех измерений кроме измерения ВРЕМЯ. Но если это полноценный факт класса интенсивности, например, температура, то он является полностью неаддитивным. Агрегирование неаддитивного показателя требует использования функции среднего, а не суммы.

Этот подход является элегантным, поскольку он очень гибок. Вы добавляете новые типы показателей путём простого добавления новых записей в измерение фактов, а не путём изменения структуры таблицы. Вы также избавляетесь ото всех значений NULL классического дизайна, поскольку записи существуют только в случае существования показателей.
Однако есть ряд существенных компромиссов. У вас может получиться ОЧЕНЬ БОЛЬШОЕ количество записей. Если какое-то из ваших измерений даёт 10 значений показателей, у вас получится 10 новых записей в отличие от одной в случае классического дизайна.
Для случаев с очень разреженными фактами это является отличным компромиссом. Но по мере роста плотности фактов в многомерном пространстве, которое вы сконструировали, вы начинаете наполнять вселенную записями. В какой-то момент вам придётся вернуться к классическому формату.

Этот подход также делает приложения более сложными. Совместное использование двух величин, полученных в результате одного измерения, более сложно, так как теперь вам требуется извлекать уже две записи. SQL делает это неудобным, поскольку SQL любит манипуляции ВНУТРИ строки, а не между строками. Вам также следует проявлять осторожность, чтобы не смешивать в расчётах несовместимые типы показателей, поскольку все числовые значения хранятся в единственном поле Amount.

Но все эти компромиссы оправданы, если вы живёте в мире финансовых инвестиций, промышленного производства или медицины.

Пишите мне о своих вариациях на эту тему, и я поговорю о них в своих следующих советах.
Ральф Кимбал (ralph@ralphkimball.com)

• Следующий совет
• Предыдущий совет
• Другие советы

По этой теме можно также почитать:

• Совет №30. Посадите ваши таблицы фактов на диету

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

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.