Материал опубликован с разрешения компании
Автор оригинала: Bob Becker (все
статьи)
Перевод на русский язык: Егор
Демьянов
Оригинальный документ располагается здесь.
Достаточно часто мы встречаем несколько десятков различных дат,
представляющих важную информацию для бизнеса, и каждая из этих дат
должна быть включена в многомерную модель. Например, в финансовой
организации мы имеем дело с датой внесения вклада, датой снятия
со счета, датой выписки чека, датой обработки чека, датой открытия
счета, датой выпуска карты, датой представления продукта, датой
начала рекламной кампании, датой рождения клиента, датой начала
действия записи, датой загрузки записи, отчетным месяцем и т.д.
В первую очередь необходимо знать, что не все даты создаются и
обрабатываются одинаково. В основном даты хранятся в таблицах фактов
как внешние ключи на измерение «Дата». Большая часть оставшихся
дат становятся атрибутами прочих других измерений. Наконец, некоторые
даты добавляются в модель для поддержки ETL или возможностей аудита.
Представим, что в нашей финансовой организации проектируется таблица
фактов для транзакций по текущем счетам, таких как взносы на счет,
выписывание чеков, снятие денег в банкомате. Каждая строка в таблице
фактов соединена с измерениями «Тип транзакции» и «Дата транзакции».
Чем является дата с точки зрения бизнеса (датой выписки чека, внесения
средств на счет, или снятия средств в банкомате) определяется типом
транзакции. В этом примере мы не будем включать в таблицу фактов
три разных даты, так как только одна имеет смысл для каждой транзакции.
В других ситуациях одна строка таблицы фактов может определяться
двумя различными датами, такими как дата проведения транзакции и
дата вставки записи о транзакции. В этом случае обе даты будут сохранены
как уникальные внешние ключи на измерения. Мы должны создать одну
физическую таблицу с датами, и представления (views) для логических
ролей, в которых может выступать дата.
Предположим теперь, что наш клиент решил «обобщить» свою таблицу
фактов таким образом, чтобы она содержала транзакции разных бизнес-процессов.
В такой «обобщенной» модели увеличивается число внешних ключей на
таблицу дат, в которую также добавляется значение «Не применимо».
В нашем примере с финансовой компанией будем считать, что в таблицу
фактов сводятся транзакции по текущим счетам, депозитам, кредитным
картам и ипотечным кредитам.
Все записи в этой таблице фактов представляют транзакции в обобщенном
виде, но рождаются в результате разных процессов. Мы являемся сторонниками
проектирования на основе бизнес процессов и, как правило, на каждый
бизнес-процесс создаем отдельную таблицу фактов. Выписка чека весьма
отличается от погашения задолженности по кредиту. Эти два процесса
имеют различные показатели и размерности, что приводит к отдельным
таблицам фактов, каждая со своими уникально именованными датами.
Очевидно, что мы также включаем измерение дат в периодический снимок
для определения того, к какому периоду относится запись, например,
снимок за месяц. Это суженное подмножество измерения дат, согласованное
с нашим основным измерением.
Многие важные с точки зрения бизнеса даты включаются как атрибуты
в таблицы измерений. Дата открытия счета является атрибутом справочника
счетов. Аналогичным образом дата рождения клиента, дата выпуска
продукта в продажу и дата начала рекламной кампании принадлежат,
соответственно, измерениям «Клиент», «Продукт» и «Рекламная кампания».
Если даты являются атрибутами измерений, мы должны продумать, каким
образом они будут использоваться в анализе. Достаточно ли просто
знать дату открытия счета, или нужно дополнительно иметь атрибуты
с годом открытия счета, месяцем открытия счета и месяцем/годом?
Эти дополнительные атрибуты значительно расширяют возможности пользователя
по составлению интересных запросов путем группировки по году и/или
месяцу открытия счета.
Для наиболее широких возможностей анализа на базе атрибутов с датами
в этих измерениях вам следует использовать измерение «Дата». При
этом, вы включаете в атрибуты измерений не сами даты, а суррогатные
ключи из измерения «Дата», а затем создаете представление измерения
«Дата» с правильными бизнес-наименованиями всех атрибутов. Эта техника
открывает нам для анализа все богатство атрибутов основного измерения
«Дата». Следует иметь в виду, что слишком интенсивное использование
этой техники может пойти в ущерб простоте работы и производительности
системы. Следите также за тем, чтобы все даты в атрибутах ваших
измерений попадали в интервал дат, хранимый в измерении «Дата».
Существуют дополнительные даты, необходимые команде разработчиков
для управления ETL-процессом и поддержки аудита. Атрибуты с началом
срока действия записи, окончанием срока действия записи, датой вставки
и датой последнего обновления должны включаться в каждую таблицу
измерения. Хотя эти даты и не нужны для анализа конечным пользователям,
для разработчиков хранилища данных они являются бесценными.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS