2010-03-08 52 views
5

我有一個尺寸(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)。但是......這似乎是一個常見問題,所以應該有一個共同的解決方案,對吧?

回答

4

通常我與達米爾對這個答案的協議,但由於事實表是你的具體情況很窄,還有值得亞倫崇尚保持的NULL。

我們在與多個事實表的特定學科領域的幾個星型架構共享尺寸(符合和內部)的大部分(如果不是全部)。範圍有限的維度在整個企業中並不被視爲「一致」,但它們就是我們所說的「共享內部」維度。

現在通常情況下,如果數據同時加載以便尺寸沒有改變,則可以將兩個事實表連接到鍵上,但是一般情況下,當然不能在尺寸鍵上連接兩個不同的星型模式如果他們是傳統緩慢變化的代理人。一般來說,您必須在維度中的自然鍵或「業務鍵」上加入單獨的星號,而不是代理號(除了通常在日期維度中不變且只有自然鍵的特殊情況下)。

請注意,當您連接兩顆星時,必須使用LEFT JOIN,在這種情況下,您將生成NULL,您仍然可能必須考慮這些NULL - 所以您實際上已回到原始狀態你有NULL的模型!;-)

當您的表格寬度較小並且數據的垂直分區產生節省空間以及更清晰的邏輯模型時,額外事實表的好處更加明顯 - 這是尤其真實的當密鑰只能真正共享到某一點時 - 擁有一個虛擬密鑰或NULL密鑰絕對不是一個好主意 - 這通常指向一個維度建模問題。然而,正如亞倫所說,如果你把它推向極端,你可以在每個事實表中有一個共享密鑰的事實列,這意味着密鑰開銷使實際成本變得相形見絀,而且你真的最終變相EAV模型。

我也看看你是否在Kimball的「太少維度」的情況。似乎您必須具有良好的維度屬性才能集中到SessionKey和SiteItemKey中 - 但是沒有看到您的整個模型和需求,這很難說,但我認爲您會在低基數或甚至沒有雪花維度的情況下擁有一些用戶統計信息完整的會話或網站維度。

+0

感謝您的討論!我認爲我確實有一個共同內部維度的情況。加入兩個事實表的比較說明了爲什麼我們保留NULL而不是零(零點會影響這裏的平均值,而且我們選擇了奇怪的NULL表示,我們不能透露關於模式的其他內容,但是你糾正一些用戶可能從更多更具體的維度中受益。 – 2010-03-09 03:25:04

3

真的沒有一個優雅的解決方案,你要麼有空列,要麼使用EAV解決方案。我張貼了關於EAV前(併產生了大量的註釋,這可能是值得閱讀):

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

我在一些場景模型的粉絲,但如果你的尺寸/屬性不會頻繁地改變,沒有任何事情可以做很多額外的工作。只要周圍的代碼可以適當地處理它們,列中的NULL值就不會真的浪費。

+0

感謝您的鏈接,並與EAV比較 - 我沒有這樣想過。 – 2010-03-08 22:46:41

1

你可以有一個以上的事實表:factperUserClicks,factperBroWserClicks,factEyeTime等..

每個這些將有DateKey,SessionKey,SiteItemKey。這種方式只有「有意義」的維度鍵出現在每個事實中。

理想情況下,應該在DW沒有NULLS - 如果你讓他們在同一個事實表,使用零可能更合適。

至於節省磁盤空間,我沒有看到一個理想的解決方案 - 但是,在DW都應該進行交易的速度和(查詢)的簡單空間反正。

+0

問題是我需要一起查詢SiteItem維度,並通過用戶定義的事實列表來檢索聚合。看來我可以將兩個事實表連接在一起,但需要執行LEFT JOIN才能正確聚合。 – 2010-03-09 03:21:40