Могу ли я смешивать коды, не являющиеся мерами, с мерами в моей таблице фактов?

Question

Мы выполняем сложную операцию по накоплению данных.Наш клиент отправляет нам данные, которые включают в себя два измерения (время и бизнес-единицу).Время в основном год-месяц.Измерение бизнес-единицы имеет всего несколько атрибутов:имя и несколько категорий, к которым могут принадлежать BU для целей отчетности и анализа.

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

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

Должен ли я объединить эту качественную информацию в единую таблицу фактов с дополнительными фактами?Или мне следует отделить качественные данные (которые можно использовать только для подсчета) от количественных (которые можно использовать для суммирования)?

Answer 1

Добавляйте элементы в таблицу фактов только в том случае, если они вырождены (что вызывает проблемы с высокой мощностью/уникальностью в вашем измерении, когда оно приводит измерение к отношению 1-1 к таблице фактов).Кимбалл рекомендует избегать искушения приписывать к фактам что-либо, кроме вырожденных измерений (например, уникальный номер заказа).

Вы всегда можете поместить их в то, что Кимбалл называет «мусорным» измерением.Все эти коды можно просто свалить в мусорное измерение.Большинство дат будут входить в таблицу фактов в качестве ключей к вашему измерению дат в определенной роли (обычно с естественным целочисленным ключом в форме ГГГГММДД - один из немногих случаев, когда мы не используем неидентичный бессмысленный суррогатный ключ)

Мне нравится наивно рассматривать звезду как все факты, а затем просто из соображений удобства определить, какие столбцы входят в какие измерения.Не обязательно рассматривать их как соответствующие конкретному бизнес-объекту — помните, что звезда не является нормализованной базой данных OLTP в стиле ERD.

Answer 2

Если данные напрямую связаны с аддитивным фактом и не являются чем-то, что вы хотите группировать/сортировать/искать, то размещение их в таблице фактов — это нормально.

Однако имейте в виду, что неаддитивные данные в таблице фактов либо предотвратят свертывание, либо станут операцией с потерями.

Answer 3

Брэд Уилсон точно описывает риск добавления их в вашу таблицу фактов.Раньше я добавлял ненужные атрибуты в свою таблицу фактов только для того, чтобы позже требовался рефакторинг.

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

Какой деловой цели служат даты?Навскидку я бы порекомендовал сделать их своими размерами и точно описать.

Насколько нестабильны поступающие дополнительные коды?Если основой вашей таблицы фактов являются дата и BU, почему их нельзя включить в измерение BU и рассматривать как медленно меняющиеся атрибуты?

Без более подробной информации я не могу дать однозначную рекомендацию, но это будут первые вопросы, которые я задам себе.