Таблица фактов с несколькими фактами

Question

У меня есть измерение (SiteItem), в котором есть два важных факта:

perUserClicks 
perBrowserClicks

однако в этом измерении у меня есть группы значений, основанные на столбце атрибутов (назовем группы UpperFoldItems, 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

Это кажется немного расточительным, поскольку только некоторые столбцы относятся к некоторым ключам измерений (нерелевантные факты остаются NULL).Но...Кажется, это обычная проблема, поэтому должно быть общее решение, верно?

Answer 1

В целом я согласен с ответом Дамира по этому поводу, но поскольку таблица фактов в вашем конкретном случае очень узкая, призыв Аарона к сохранению NULL все же имеет смысл.

У нас есть несколько звездообразных схем в определенных предметных областях с несколькими таблицами фактов, которые имеют общие (если не все) измерения (согласованные и внутренние).Измерения с ограниченной областью действия не считаются «согласованными» на предприятии, но мы бы назвали их «общими внутренними измерениями».

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

Обратите внимание, что когда вы соединяете две звезды, вам нужно использовать LEFT JOIN, и в этом случае вы БУДЕТ создавать NULL, которые вам, вероятно, все равно придется учитывать - так что вы фактически возвращаетесь к исходной модели, которую вы использовали с НУЛИ!;-)

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

Однако, как говорит Аарон, если вы доведете это до крайности, вы можете иметь один столбец фактов в каждой таблице фактов с общими ключами, а это означает, что накладные расходы на ключ затмевают стоимость фактов, и вы действительно окажетесь в замаскированной модели EAV.

Я также хотел бы посмотреть, находитесь ли вы в ситуации Кимбалла «слишком мало измерений».Похоже, у вас должны быть хорошие атрибуты измерений, объединенные в SessionKey и SiteItemKey, но, не видя всей вашей модели и требований, трудно сказать, но я думаю, что у вас будут некоторые демографические данные пользователей в измерении с низкой мощностью или даже в виде снежинки без полное измерение сеанса или сайта.

Answer 2

На самом деле не существует элегантного решения: у вас либо есть столбцы с нулевым значением, либо вы используете решение EAV.Я уже писал об EAV (и оставил много комментариев, которые, возможно, стоит прочитать):

• Что такого плохого в EAV?

В некоторых сценариях я сторонник этой модели, но если ваши измерения/атрибуты не меняются часто, это может потребовать много дополнительной работы напрасно.Значения NULL в столбце на самом деле не являются бесполезными, если окружающий код может обрабатывать их соответствующим образом.

Answer 3

У вас может быть более одной таблицы фактов:factperUserClicks, factperBroWserClicks, factEyeTime и т. д.

Каждый из них будет иметь DateKey, SessionKey, SiteItemKey.Таким образом, для каждого факта отображаются только те ключи измерения, которые «имеют смысл».

В идеале в хранилище данных не должно быть NULL-значений — если вы храните их в одной таблице фактов, использование нулей может быть более подходящим.

Что касается экономии дискового пространства, я не вижу идеального решения, но в хранилище данных в любом случае предполагается жертвовать пространством ради скорости и простоты (запросов).