Таблица фактов с несколькими фактами
У меня есть размер (SiteItem), имеет два важных факта:
perUserClicks
perBrowserClicks
однако, в этом размере, у меня есть группы значений на основе столбца атрибутов (давайте назовем группы AboveFoldItems, LeftNavItems, OnTheFlyItems, и т.д.), у каждого есть больше фактов, которые характерны для той группы:
AboveFoldItems: eyeTime, loadTime
LeftNavItems: mouseOverTime
OnTheFlyItems: doesn't have any extra, but may in the future
Следующая схема таблицы фактов хорошо?
DateKey
SessionKey
SiteItemKey
perUserClicks
perBrowserClicks
eyeTime
loadTime
mouseOverTime
Это кажется немного расточительным, так как только некоторые столбцы принадлежат некоторым ключам измерения (несоответствующие факты оставляют ПУСТЫМИ). Но... это кажется, что была бы типичная проблема, таким образом, должно быть общее решение для этого, правильно?
3 ответа
Я в целом согласен с ответом Дамира по этому поводу, но поскольку таблица фактов в вашем конкретном случае очень узкая, аргументы Аарона все же заслуживают внимания для хранения NULL.
У нас есть несколько звездообразных схем в определенных предметных областях с несколькими таблицами фактов, которые разделяют большую часть (если не все) измерения (согласованные и внутренние). Измерения ограниченного объема не считаются «согласованными» в масштабе всего предприятия, но это то, что мы бы назвали «общими внутренними» измерениями.
Обычно, если данные загружаются одновременно, так что измерение не изменилось, вы можете объединить обе таблицы фактов по ключам, но в целом, конечно, вы не можете объединить две разные звездообразные схемы по ключам измерений, если они суррогаты в традиционных медленно меняющихся измерениях.В общем, вам нужно соединить отдельные звездочки на естественных ключах или «бизнес-ключах» в измерении, а не на суррогатах (за исключением, как правило, особого случая измерения даты, когда оно не изменяется и имеет только естественный ключ).
Обратите внимание, что когда вы соединяете две звезды, вы должны использовать LEFT JOIN, и в этом случае вы получите NULL, которые вам, вероятно, все равно придется учитывать - так что вы фактически возвращаетесь к исходной модели. у вас было с NULL! ; -)
Преимущество дополнительной таблицы фактов более очевидно, когда ваши таблицы широкие с меньшим набором ключей, а вертикальное разбиение данных дает экономию места, а также более чистую логическую модель - это особенно верно, когда ключи действительно используются совместно только до определенного момента - наличие одного фиктивного ключа или NULL-ключа определенно не является хорошей идеей - это обычно указывает на проблему размерного моделирования.
Однако, как говорит Аарон, если вы доведете его до крайности, у вас может быть один столбец фактов в каждой таблице фактов с общими ключами, что означает, что накладные расходы на ключи затмевают стоимость фактов, и вы действительно заканчиваете замаскированным EAV модель.
Я бы также посмотрел, не попадаете ли вы в ситуацию Кимбалла «слишком мало измерений». Похоже, что у вас должны быть хорошие размерные атрибуты, объединенные в SessionKey и SiteItemKey, но, не видя всей вашей модели и требований, трудно сказать, но я бы подумал, что у вас будут некоторые демографические данные пользователя с низкой мощностью или даже с размером снежинки без полное измерение сеанса или сайта.
У вас может быть несколько таблиц фактов: factperUserClicks, factperBroWserClicks, factEyeTime и т. Д.
Каждая из них будет иметь DateKey, SessionKey, SiteItemKey . Таким образом, с каждым фактом появляются только ключи измерений, которые «имеют смысл».
В идеале, в DW не должно быть NULL - если вы храните их в одной таблице фактов, использование нулей может быть более подходящим.
Что касается экономии дискового пространства, я не вижу идеального решения - но в DW все равно предполагается обмен места на скорость и (запрос) простоту.
На самом деле нет элегантного решения: либо у вас есть столбцы, допускающие значение NULL, либо вы используете решение EAV. Я уже писал о EAV раньше (и создал много комментариев, которые, возможно, стоит прочитать):
Я поклонник этой модели в некоторых сценариях, но если ваши размеры / атрибуты не меняются часто, это может быть большой лишней работой напрасно. Значения NULL в столбце на самом деле не являются бесполезными, если окружающий код может обрабатывать их соответствующим образом.