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

Question

У меня есть размер (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 

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

Answer 1

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

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

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

Обратите внимание, что когда вы присоединяетесь к двум звездам, вы должны использовать LEFT JOIN, и в этом случае вы будете производить NULL, которые вам, вероятно, придется учитывать, - так что вы действительно возвращаетесь к оригиналу модель у вас была с NULL!;-)

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

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

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

Answer 2

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

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav-anyway.aspx

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

Answer 3

Вы можете иметь более одного таблицу фактов: factperUserClicks, factperBroWserClicks, factEyeTime и т.д ...

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

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

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