Материал опубликован с разрешения компании
Автор оригинала: Bob Becker (все
статьи)
Перевод на русский язык: Егор
Демьянов
Оригинальный документ располагается здесь.
В этом совете мы возвращаемся к рассмотрению фундаментального понятия,
которое ставит в тупик многих разработчиков многомерных моделей
– текстовых фактов (также называемых индикаторами, атрибутами фактов,
примечаниями).
Некоторые из вас могут справедливо заметить, что фраза «текстовый
факт» является оксюмороном. Тем не менее, мы часто получаем вопросы
от наших клиентов или студентов о полях с индикаторами или заметками,
которые вроде бы должны находиться в таблице фактов, но при этом
не являются показателями, ключами измерений или вырожденными измерениями
(см. Совет №46).
Обычно мы не рекомендуем моделировать эти так называемые текстовые
факты в таблице фактов, а советуем попытаться найти им подходящие
место в таблицах измерений. Вам не следует загромождать таблицу
фактов несколькими описательными атрибутами по 20-40 байт каждый.
С другой стороны, если вы вставляете в таблицу фактов короткие коды,
то не нужно забывать создать таблицу, в которой для каждого кода
приводится расшифровка (даже если вы абсолютно уверены, что ВСЕ
и так уже давно знают все коды).
Первый вопрос, который вы должны себе задать о потенциальном текстовом
факте – не следует ли поместить его в таблицу измерения? К примеру,
тип клиента наверняка имеет одно единственное значение для определенного
клиента, и поэтому его следует хранить как атрибут в таблице клиентов.
Если же мы не можем аккуратно встроить потенциальные текстовые
факты атрибутами в измерения, то их следует сделать отдельными измерениями
или отдельными атрибутами в «мусорном» измерении. Достаточно просто
создать небольшие таблицы измерений, присваивающие суррогатные ключи
типам платежей или транзакций, а затем использовать эти ключи в
таблице фактов. Если в результате получается слишком много небольших
измерений, то следует подумать об использовании «мусорного» измерения.
Мы обсуждали мусорные измерения в совете №48.
Есть несколько соображений, которые следует иметь в виду, принимая
решения использовать ли отдельные измерения или собрать их атрибуты
в мусорное измерение.
Количество внешних ключей в таблице фактов. Если у вас около
20 внешних ключей, то возможно неплохо было бы схлопнуть часть
из них.
Количество строк в мусорном измерении. Помните, что теоретически
возможное число уникальных комбинаций всех атрибутов может значительно
превышать число реально встречающихся комбинаций. Желательно иметь
не больше 100000 строк в мусорном измерении.
Уместность и логичность комбинирования атрибутов. Не собьем
ли мы с толку пользователя, если поместим практически никак не
связанные по смыслу атрибуты в одну таблицу?
Наконец, как нам поступить в том случае, когда предполагаемый «факт»
является текстовым полем свободной формы, таким как 240-байтный
комментарий? Профилирование этого поля, разбор и кодирование значений
сделало бы это поле наиболее полезным для аналитики. Но это всегда
проще сказать, чем сделать.
Наш опыт показывает, что если поле действительно является текстом
в свободной форме, то оно редко нужно для аналитики. Обычно эти
комментарии нужны только для проведения время от времени детального
исследования подозрительных транзакций. В такой ситуации лучше всего
поместить эти текстовые поля в отдельное измерение, чем нагружать
каждую строку в таблице фактов.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS