事實表有多個事實

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

我通常同意Damir對此的回答，但由於事實表在你的特定情況下非常狹窄，所以Aaron保留NULL的建議仍然有用。

我們在特定主題領域有幾個星型模式，其中多個事實表共享大多數（如果不是全部）維度（符合和內部）。 有限范圍的維度在整個企業中不被視為“符合”，但它們就是我們所謂的“共享內部”維度。

現在通常情況下，如果同時加載數據以便維度沒有更改，則可以在鍵上加入兩個事實表，但一般情況下，如果它們是代理項，則無法在維鍵上連接兩個不同的星型模式。在傳統的緩慢變化的維度。 一般情況下，您必須在維度中的自然鍵或“業務鍵”上加入單獨的星號，而不是在代理項目上（通常在日期維度的特殊情況下，它不變，只有自然鍵）。

請注意，當你加入這兩顆星時，你必須使用LEFT JOIN，在這種情況下你將產生NULL，你仍然可能需要考慮 - 所以你實際上回到你原來的模型空值！ ;-)

額外事實表的好處是更明顯的，當您的表格寬度較小且密鑰集較小時，數據的垂直分區可以節省空間以及更簡潔的邏輯模型 - 當密鑰只是真正共享時尤其如此一點 - 有一個虛擬鍵或NULL鍵絕對不是一個好主意 - 這通常指向一個維度建模問題。

然而，正如Aaron所說，如果你把它推到極端，你可以在每個事實表中使用共享密鑰來設置一個事實列，這意味着密鑰開銷使事實成本相形見絀，你真的最終會陷入偽裝的EAV模型。

我還想看看你是否處於Kimball的“太少維度”的情況。 好像你必須具有集中在SessionKey和SiteItemKey中的良好維度屬性 - 但是沒有看到你的整個模型和要求，很難說，但我認為你會有一些低基數甚至雪花維度的用戶人口統計數據，而不是完整的會話或網站維度。

Answer 2

實際上沒有一個優雅的解決方案，您可以使用可空列或使用EAV解決方案。 我之前發布了關於EAV的信息（並且產生了許多可能值得一讀的評論）：

• 無論如何，EAV有什么壞處？

在某些情況下，我是該模型的粉絲，但如果你的尺寸/屬性不經常變化，那么它可能會帶來很多額外的工作。 只要周圍的代碼可以適當地處理它們，列中的NULL值就不會真正浪費。

Answer 3

你可以擁有多個事實表：factperUserClicks，factperBroWserClicks，factEyeTime等...

其中每個都有DateKey，SessionKey，SiteItemKey。 這樣，只有“有意義”的維度鍵才會出現在每個事實中。

理想情況下，DW中不應該有NULLS - 如果將它們保存在同一個事實表中，則使用零可能更合適。

至於節省磁盤空間，我沒有看到理想的解決方案 - 但是，在DW中，無論如何都應該交換空間以提高速度和（查詢）簡單性。