Normalization
數據倉庫如何規範化以跟踪元數據變化？
我需要建構一個倉庫結構，該結構由定期提要填充，這些提要由抓取的數據、權威來源和主要來源組成。為了優先考慮哪些數據應該用於數據集市，我需要跟踪每個數據點的創建（我們什麼時候得到這些數據？）、更新（數據什麼時候改變？）和現有匹配（什麼時候上次顯示此數據的時間？）。從我的研究來看，5NF 是我應該使用的標準化水平。
例如，我可能會得到一個提要，其中提供學生姓名以及他們最喜歡的課程和排名順序的列表。另一個提要可能包含相同的數據，但可能有不完整的類列表，或者缺少排名順序。每個提要都帶有唯一且可靠的學生標識符
我會認為至少有三個表用於這些數據：
- 學生（s_id，姓名）
- Student_Class (s_id,class_id)
- Student_Class_Order (s_id,class_id,order_num)
其中每一個也將具有 isDeleted、created_time、created_feed_id、modified_time、modified_feed_id、matched_time、matched_feed_id 列。
什麼樣的結構最有意義？似乎應該插入任何新的數據點組合，並且我不應該有更新（軟刪除標誌除外）。有任何想法嗎？
簡短的回答是：定義您的最終結果（要求）並從那裡向後工作。
使用 DW 模式，規範化很快就消失了。
在我的例子中，我們的 ETL 有 3 個模式。
- 暫存：表被提取到我們的 DW 中，就像它們在源系統中出現的一樣，加上你描述的一些元數據列。關鍵是提取時間。
- 轉換：這些表與最終結果維度和事實表具有完全相同的架構。此時，我們正在將 OLTP 模式中的數據非規範化為 DW 星型模式。它再次具有 ETL 元數據的欄位。原始提取日期時間可以與記錄一起移動。
- 儲存：這是我們的最終結果，一個由我們的 OLAP 多維數據集讀取的 DW 星型模式。為了載入我們的數據，我們將轉換與最終的數據儲存表進行比較。新行被插入。如果一行發生了變化，我們將淘汰舊的並插入新的。為此，我們有 is_current、valid_from datetime 和 valid_to datetime 欄位。
從技術上講，我們不需要 3 個模式。這只是一個約定，它可以讓我們保持整潔。
閱讀有關Kimball 方法和漸變維度的資訊。鍵入 1 或 2 等。您將看到儲存所需元數據所需的欄位範例。
與您的企業討論他們想要或需要 DW 能夠做什麼。無論您是否需要 SCD，都會對您的架構、所需的元數據以及最終可能的規範化級別產生重大影響。