Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбал (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Критерий №18 списка критериев Dimensionally Friendly даёт определение
"измерения с горячей заменой" - измерения, имеющего две
или более альтернативных версий. Если измерение является измерением
с горячей заменой, для выполнения запроса можно выбрать любую альтернативную
версию измерения.
Существует ряд ситуаций, когда альтернативные версии измерений могут
оказаться очень полезными. Вот три интересные ситуации:
1) Инвестиционный банк предоставляет доступ своим клиентам к большой
таблице фактов, которая ежедневно в течение нескольких лет отслеживает
акции и облигации. Измерение "инвестиция" в этой таблице
фактов предоставляет информацию о каждой акции и облигации. Но это
измерение "инвестиция" настраивается персонально для каждого
клиента, получающего доступ к таблице фактов. Таким образом, каждый
клиент имеет возможность описывать и группировать инвестиции интересными
персональными способами. Различные версии измерения могут полностью
отличаться друг от друга, что может заключаться в несовместимых
названиях атрибутов и в наличии различных иерархических схем. Все
клиенты используют одну и ту же таблицу фактов (поэтому её нужно
хранить всего в одном месте), но каждый клиент использует свою таблицу
измерения "инвестиция" в качестве основы для анализа колебаний
котировок акций и облигаций. С точки зрения сервера баз данных,
клиенты постоянно выполняют горячую замену измерения "инвестиция"
с каждым очередным запросом.
2) Розничный банк создаёт одну большую таблицу фактов, которая
хранит остатки по счетам на конец месяца банковских счетов всех
типов, включая расчётные, сберегательные, пластиковые, заёмные,
депозитные сертификаты и другие. Это классический пример "гетерогенных
продуктов", поскольку детальные описания этих типов счетов
ужасно отличаются друг от друга. Нее существует единого шаблона
описания, который смог бы помочь управлять сложностями всех этих
типов счетов. Поэтому мы строим упрощённое измерение "счёт",
которое бы однообразно подходить ко всем счетам. Мы используем это
измерение, когда занимаемся анализом перекрёстных продаж и оцениваем
общий портфель клиента. Но когда мы заостряем своё внимание на определённом
типе счетов (например, на закладных), мы переключаемся на значительно
более широкое (больше полей) измерение, которое содержит атрибуты,
касающиеся исключительно закладных. Мы можем это делать, когда мы
уверены в том, что сузили область анализа до одного типа счетов.
Если у наc 0 продуктовых линеек, то у нас 21 измерение "счёт":
одно упрощённое измерение, описывающее все счета, и 20 расширенных
измерений, каждое из которых описывает совокупность похожих счетов.
3) Производственная компания желает предоставить доступ к таблице
фактов, описывающей отгрузки, своим торговым партнёрам, но нуждается
в разграничении доступа к информации о заказах партнёров между ними.
В данном случае каждый партнёр получает свою версию измерения "партнёр"
только с названием своей компании. Все остальные партнёры как "ДРУГОЙ".
В дополнение к этому обязательное поле с весовым коэффициентом в
таблице измерения устанавливается в 1 для данного партнёра и в 0
- для остальных. Этот весовой коэффициент умножается на все факты
в таблице фактов. Таким образом, одна таблица фактов отгрузок может
безопасно использоваться для поддержки конкурирующих торговых партнёров.
Горячая замена измерений прямолинейна в стандартных реляционных
базах данных, поскольку соединения между таблицами можно задавать
во время запроса. Однако если требуется контролировать ссылочную
целостность между таблицами измерений и таблицей фактов, то каждая
из таблиц измерений должна содержать полный набор ключей, а, следовательно,
и полный набор записей. В этом случае, если таблица измерения с
горячей заменой используется для разграничения доступа (как в примерах
2 и 3), то записи, доступ к которым должен быть ограничен, должны
содержать фиктивные или пустые значения.
Горячая замена измерений является вызовом для систем класса OLAP,
где индивидуальность измерения глубоко встроена в ткань куба данных
OLAP. Чтобы увидеть то, как Cognos (PowerPlay) и Microsoft (Analysis
Services) справляются с реализацией критерия измерений с горячей
заменой в своих продуктах класса OLAP, ознакомьтесь со статьями,
которые вы найдёте здесь.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS