Совет №19
Корректная репликация измерений

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

Секрет построения распределённого хранилища данных кроется в использовании согласованных измерений. В распределённом хранилище данных многие различные источники показателей поддерживаются различными подразделениями. Эти показатели обычно представляются в "таблицах фактов". Одно подразделение может измерять результаты производства товаров, а другое может измерять остатки товаров на складе. Третье подразделение может измерять продажи отдельных товаров, а четвёртое - комментарии и жалобы о товарах. Очевидно, что все эти подразделения имеют общую заинтересованность в "товарах". Мы можем построить распределённое хранилище данных, если мы сможем заставить все эти четыре подразделения договориться об определении товаров.

На самом деле, нужно сказать об этом сильнее. Мы сможем построить распределённое хранилище данных, если все эти четыре подразделения будут использовать согласованные измерения. А в действительности эти подразделения должны согласовать все остальные измерения, которые они используют совместно, например, время и клиенты. Но в нашей дискуссии мы остановимся только на измерении товар.

Наиболее простой способ согласования измерения товар - это использование во всех четырёх подразделениях одну и ту же идентичную таблицу измерения. Одни и те же ключи, одни и те же атрибуты, всё одинаковое. Каждое из четырёх подразделений, конечно же, должны преобразовать внутренние ключи записей о товарах, в своих таблицах фактов в общедоступные суррогатные ключи, использующиеся в согласованной таблице измерения товар. Я описал этот канал суррогатных ключей в статье, которую можно найти по адресу http://www.dbmsmag.com/9806d05.html.

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

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

Операция drill across является концептуальным шагом в использовании распределённого хранилища данных и способом избежания его централизации.

Но администрирование согласованных измерений требует соблюдения специальной дисциплины. Организации требуется "орган власти над измерением", в данном случае, царь товаров. Орган власти над измерением отвечает за поддержку измерения товар и его успешную репликацию всем клиентам витрин данных, которые используют в своих таблицах фактов информацию о товарах. Нам нужно всерьёз принимать задачу репликации измерения и его согласованного использования.

Заголовки строк не означали бы одного и того же при попытке согласовать определения атрибутов. Например, если бы менеджер категорий изменил определение одной из категорий товаров, результаты отчётов, построенные на основе этих несинхронизированных заголовков строк, были бы неверными. И это в порядке вещей, что менеджеры категорий вправе изменять названия категорий и многие другие атрибуты измерения товар.

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

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

Мы можем суммировать две области ответственности для корректной репликации измерений:

1) Все клиентские витрины данных должны внедрить реплицируемое измерение одновременно с тем, чтобы при выполнении пользователями любой операции drill across использовался согласованный набор атрибутов измерения
и
2) Все клиентские витрины данных должны удалить агрегаты, на которые влияют изменения измерений, и предоставлять доступ конечным пользователям к этим агрегатам только после того, как они полностью согласованы с базовыми таблицами фактов и с новой логикой вычисления агрегированных показателей.

Тема репликации измерений является критерием №9 в моём списке критерием дружественности многомерным моделям. Как Microsoft, так и Cognos прислали детальные ответы на все двадцать критериев, которые делают их "системами, дружественным многомерным моделям". Проверьте, что они сделали для репликации измерений. Мы ожидаем, что другие производители оценят свои системы, используя эти двадцать критериев. Вы можете найти полный список критериев и ответы производителей по адресу http://www.ralphkimball.com/html/dimension.html.
Если вы являетесь конечным пользователем и хотите оценить всю вашу систему, которая может состоять из продуктов нескольких производителей, обратитесь, пожалуйста, ко мне. Мне будет интересно поместить такие оценки на сайт.

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

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

• Совет №24. Разрабатываем измерения в многонациональном хранилище данных
• Совет №26. Добавляем измерение аудита для отслеживания истории загрузки и степени достоверности

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

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