如何使用自然鍵

我們已經有了一個數據倉庫的設計，四個維度表和一個事實表創建一個事實表：如何使用自然鍵

dimUser ID，電子郵件，名字，姓氏
dimAddress ID，城市
dimLanguage ID，語言
dimDate ID，的startDate，結束日期
factStatistic ID，dimUserId，dimAddressId，dimLanguageId，dimDate，loginCount，pageCalledCount

我們的問題是：我們想要構建事實表，其中包括計算統計信息（取決於userId，日期範圍）和填充外鍵。

但我們不知道如何，因爲我們不知道如何使用自然鍵（這似乎是根據我們閱讀的文獻解決我們的問題）。

我認爲一個自然的關鍵是userId，這在所有ETL作業中都是需要的，這些作業計算出尺寸數據。

但也有許多困難：

如果我們創建元數據（包括一組DIMENSION_NAME，surrogate_key，natural_key的），這不會因爲消除重複的工作

這個問題似乎是消除重複的策略。有更好的方法嗎？

我們正在使用MySQL 5.1，如果它有任何區別。

來源

2012-12-20 s.froehlich

什麼是您的事實表追蹤？按用戶/地址/語言/「日期範圍」登錄？在我看來，地址和語言是用戶的屬性？而你的日期表有範圍？爲什麼不只是在事實表中存儲單個日期並彙總？ –

這是真實設計的簡化模型。但它基本上是每個用戶（具有地址和語言）的登錄和頁面調用。 loginCount和pageCalledCount按日期範圍彙總。 –

我真的不明白你的問題，但如果你正在尋找一種方法來生成和填充代理鍵，那麼我提出了一個相當通用的方法，在[這個問題]中使用映射表（http：// stackoverflow。 COM /問題/ 12657674/SQL-datawarehousing-需要的幫助 - 填充 - 我維 - 使用 - TSQL - 選擇 - 或-A-定）。報告數據庫通常使用人造密鑰，所以我不確定爲什麼要使用自然密鑰;看起來你的問題主要是實現你的ETL過程，而不是你的設計，雖然我可能是錯的。 – Pondlife

如果事實表跟蹤登錄和每個用戶的頁面調用，那麼你應該有跟蹤這些事情的源表集合，這是您將從中加載事實表數據的位置。我可能會在每個用戶/登錄日期的一行中創建事實表 - 如果可能的話甚至更低以保持原子數據。

在這裏，你將有一個事實表與兩個維度 - 用戶和日期。你可以堅持地址和語言作爲事實的維度，但這些實際上只是用戶的屬性。

您的維度應該有代理鍵，但也應該有源「業務」或「自然」鍵可用 - 作爲維度本身的屬性，或者通過您的同事建議的映射表。使用映射表並非「錯誤」 - 當存在多個源時，它確實使事情變得更加簡單。

如果您將業務密鑰存儲在映射表中，或者將維存儲爲屬性，那麼對於事實中加載的每一行，這是對照暗淡或映射表的簡單查找（通常是通過連接），以獲取用戶的代理鍵（然後從用戶那裏獲得用戶的「當前」地址/語言以堅持事實）。日期維通常使用以YYYYMMDD或其他「自然」格式存儲的替代關鍵字 - 您可以根據要加載到事實中的源記錄上的日期信息生成此日期維。

來源

2012-12-22 02:38:29

不要勉強單查詢，嘗試加載分離查詢的數據和一些供應商的數據混合...

來源

2012-12-20 14:49:33 oxy

我不明白。我們已經實現了填充維度表的ETL作業。但是我們不知道如何在事實表中將維度條目彼此連接起來。 –

如何使用自然鍵

回答

相關問題