Совет №25
Разработка многомерных моделей для приложений родитель-потомок
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Отношение родитель-потомок является одной из основных фундаментальных
структур в мире бизнеса. Счёт (предок) может иметь строки (потомки).
Другие очевидные примеры помимо счетов включают заказы, накладные,
страховые полисы и чеки в розничных магазинах. Фактически, любой
документ бизнеса со встроенными повторяющимися группами подходит
под определение приложения родитель-потомок, особенно когда встроенные
строки содержат интересные числовые данные, такие как денежные суммы
или количество в штуках.
Приложения родитель-потомок представляют крайний интерес для хранилищ
данных, поскольку большинство управляющих документов на перевод
денег и товара (или услуг) из одного места в другое принимают форму
родитель-потомок.
Но источники данных вида родитель-потомок наподобие счетов представляют
классическую дилемму проектирования. Некоторые данные доступны только
на родительском уровне, а другие - только на уровне потомков. Нам
нужны две таблицы фактов в нашей многомерной модели, или можно обойтись
одной? И что делать с данными, доступными только на родительском
уровне, если мы хотим иметь возможность детализации до уровня потомка?
Давайте представим типичный счёт на продажу продуктов. Счёт создаётся
для нашей компании торговым агентом и направляется определённому
клиенту. Каждая строка счёта представляет отдельный продукт, продаваемый
клиенту.
Данные родительского уровня включают следующее:
дата счёта (измерение)
торговый агент (измерение)
клиент (измерение)
условия платежа (измерение)
номер счёта (вырожденное измерение, см. ниже)
чистая цена за позицию (аддитивный факт)
общая сумма скидки уровня счёта (аддитивный факт)
общая стоимость доставки (аддитивный факт)
общая сумма налогов (аддитивный факт)
общий итог (аддитивный факт)
Данные уровня потомка включают следующее:
Продукт (измерение)
Рекламная акция (измерение)
Количество единиц продукта (аддитивный факт)
Цена единицы продукта (см. ниже)
Цена позиции (количество умножить на цену) (аддитивный факт)
Скидка рекламной акции на этот определённый продукт (см. ниже)
Итоговая чистая цена (количество х(цена за единицу -скидка)) (аддитивный
факт), а также "контекст" всего счёта (четыре измерения
выше).
При заданных условиях на измерения и факты может показаться, что
мы всё сделали. У нас есть две красивых таблицы фактов. Родительская
таблица фактов счетов имеет 4 измерения и 5 фактов, а дочерня таблица
фактов строк счёта имеет 6 измерений и 3 факта.
Но наш дизайн неудачен. Мы не можем вычислить объём бизнеса в
разрезе продуктов! Если мы зададим фильтр на определённый продукт,
мы не будем знать что делать со скидками, ценой доставки и налогами
уровня счёта. Все верхнеуровневые точки зрения на наш бизнес в разрезе
клиентов, торговых агентов и рекламных акций будут вынуждены пропускать
продуктовое измерение.
В большинстве предприятий это недопустимо.
Существует единственный способ решения этой проблемы. Вы должны
взять данные уровня счёта и разнести их ниже на уровень строки счёта.
Да, в таком разнесении есть некоторые противоречия, и, да, вы должны
принять несколько произвольных решений, но альтернативой является
невозможность анализа бизнеса в разрезе продуктов.
Мы заменим две таблицы фактов одной таблицей фактов, у которой
уровнем детализации будет строка счёта. Другими словами, мы последовательно
опустимся на наиболее детальный уровень потомка в процессе разработки
многомерной модели предок-потомок.
Вспомните нашу дискуссию о выборе степени детализации (совет
№21), где говорилось, что мы можем "украсить" величину
всем, что мы о ней знаем в момент её измерения. Таким образом, наша
таблица уровня отдельной строки счёта имеет следующие измерения:
Дата выставления счёта (измерение)
Торговый агент (измерение)
Клиент (измерение)
Условия платежа (измерение)
Продукт (измерение)
Рекламная акция (измерение)
Что нам делать с номером счёта? Он, несомненно, представляет собой
одну величину, даже на уровне строки счёта, но мы уже "выставили"
всё, что мы знаем о счёте в наших четырёх первых измерениях. Мы
должны оставить номер счёта в модели, но нам не нужно делать из
него измерение, потому что это измерение будет пустым. Мы называем
это "вырожденным измерением".
Номер счёта (вырожденное измерение)
Теперь наши факты для этой таблицы фактов строк счёта будут включать:
Количество единиц продукта (аддитивный факт)
Цена позиции (количество единиц х цена) (аддитивный факт)
Итоговая чистая цена (количество х(цена за единицу -скидка))
(аддитивный факт)
Разнесённые с уровня счёта скидки (аддитивный факт)
Разнесённая стоимость доставки (аддитивный факт)
Разнесённая сумма налогов (аддитивный факт)
Мы не включаем цену продуктов или суммы скидок как физические
факты, поскольку мы всегда можем разделить итоговые суммы на количество
единиц товара в нашем генераторе отчётов для получения этих неаддитивных
величин.
Мы можем мгновенно восстановить точные цифры уровня счета, просто
складывая все строки с определённым номером счёта. Нам не нужна
отдельная родительская таблица фактов для счёта, потому что это
всего лишь проста агрегация нашей более детальной таблицы фактов.
Мы нисколько не скомпрометировали итоговые суммы уровня счёта, произведя
их разнесение до уровня строк счёта.
И, что самое лучшее, мы можем теперь легко посчитать объём бизнеса
на самых высоких уровнях, делая деление по продуктам и включая разнесённые
величины для получения полной картины наших чистых доходов.
Метод спуска на уровень строки счёта и построения единой детальной
таблицы фактов находится сердце моделирования хранилищ данных. Он
является хорошим методом выполнения наших обещаний "исследовать
предприятие во всех разрезах".
Если у вас есть ещё вопросы или комментарии о ситуациях моделирования
предок-потомок, пишите мне по адресу ralph@ralphkimball.com и я
обсужу их в будущем совете.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS