Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбал (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Один из вопросов, который мне часто задают, это вопрос "Как
можно представить связь между измерениями, не обращаясь к таблице
фактов?" Часто разработчик задаёт следующий вопрос: "Могу
ли я создать маленькую таблицу связи со всего двумя ключами измерений,
а затем соединить ЭТУ таблицу с таблицей фактов?"
Естественно, в классической многомерной модели у нас имеется всего
два варианта. Либо оба измерения моделируются независимо, а затем
ключи этих измерений сводятся вместе ТОЛЬКО в таблице фактов, либо
эти два измерения объединяются в одно единое супер-измерение с одним
ключом. Так, когда же разработчику выбрать отдельные измерения,
а когда их объединять?
Чтобы быть более конкретными давайте предположим, что два измерения
это "Продукт" и "Рынок" в системе для предприятия
розничной торговли. Предположим, представляющая для нас интерес
таблица фактов хранит записи о продажах "Продуктов" на
различных "Рынках" во времени. Наше стремление отразить
связь между измерениями "Продукт" и "Рынок"
основано на подозрении, что "Продукты очень сильно связаны
с Рынками в нашем бизнесе". Это предложение является ключом
всего вопрос проектирования.
Если продукты чрезвычайно сильно связаны с рынками, то между измерениями
"Продукт" и "Рынок" может быть связь один-к-одному
или многие-к-одному. В этом случае объединение двух измерений имеет
большой смысл. Размер результирующего измерения будет равен всего
лишь размеру большего из измерений. Навигация (просмотр комбинаций
значений) в пределах объединённого измерения была бы полезной и
быстрой. Обнаружились бы интересные закономерности.
Но очень редко между продуктами и рынками существует такая замечательная
связь. В дело вмешиваются как минимум три фактора, заставляющие
нас разделить эти измерения.
Отношения один-к-одному и многие-к-одному могут быть буквально
неверными. Мы можем быть вынуждены признать, что отношение на
самом деле является отношением многие-ко-многим. Когда большинство
продуктов продаётся на большинстве рынков, становится очевидным,
что нам нужно два измерения, поскольку в противном случае наше
объединённое измерение становится громадным и начинает быть похожим
на декартово произведение двух первоначальных измерений. Навигация
не позволяет найти ничего интересного.
Если отношение между продуктами и рынками изменяется с течением
времени или испытывает влияние со стороны четвёртого измерения,
такого как Продвижение, то мы должны признать, что объединённое
измерение представляет собой некоторое подобие таблицы фактов!
Между продуктами и рынками существуют другие отношения помимо
розничных продаж. Каждый бизнес-процесс, включающий продукты и
рынки будет иметь свою собственную таблицу фактов. Хорошими кандидатами
являются Продвижение, Реклама, Дистрибуция и Производство. Создание
объединённого измерения Продукт-Рынок исключительно вокруг розничных
продаж сделало бы невозможным выражение этих оставшихся процессов.
Смысл этого совета заключается в том, чтобы побудить вас визуализировать
отношения между сущностями, которые вы выбираете в качестве измерений.
Когда между сущностями существует фиксированная, не зависящая от
времени сильно коррелированная связь, их следует моделировать как
одно измерение. В большинстве оставшихся случаев ваш дизайн будет
проще и компактнее, если вы выделите эти сущности в отдельные измерения.
Не избегайте таблиц фактов! Таблицы фактов исключительно эффективны.
Они содержат только ключи измерений и фактические показатели и только
те комбинации измерений, которые имеют место в конкретном процессе.
Так что, когда вы соберётесь отразить связь между двумя измерениями,
помните о том, что таблица фактов была создана в точности для этой
цели.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS