Совет №13
Использование таблицы фактов в качестве таблицы измерения

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

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

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

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

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

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

Таким образом, чтобы укоротить всю эту историю, мы можем использовать суррогатный ключ счёта так, как будто это ключ типичного медленно изменяющегося измерения типа 2, и мы можем помещать этот ключ в любую ДРУГУЮ таблицу фактов, описывающую поведение счёта. Например, представим, что мы также собираем информацию об обычных транзакциях со счетами, таких как депозиты и снятие наличных. Будем называть их "балансовыми транзакциями" чтобы отличать их от транзакций с информацией о клиентах. Таблица фактов балансовых транзакций будет выглядеть следующим образом:

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

Надеюсь, это заставило вас подумать. Я написал статью в журнал DBMS о базах данных для подразделений по работе с персоналом, при проектировании которых используются подобные приёмы. Вы можете найти эту статью по адресу http://dbmsmag.com/9802d05.html. Обратитесь также к разделу "Time Stamping Changes in a Large Dimension" в книге The Data Warehouse Lifecycle Toolkit, страница 233. Присылайте свои вопросы и комментарии, и я посвящу следующий выпуск ответам на них.

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

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

• Совет №46. Еще один взгляд на вырожденные измерения
• Суррогатные ключи. Контролируйте идентификаторы строк формированием суррогатных ключей в хранилищах данных
• Суррогатные ключи. Конвейерная обработка суррогатных ключей

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

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