數據倉庫建模問題

Question

我在數據倉庫中有一個典型的事實表 - 該表有一些代理鍵和度量。 在數據中，倉庫也是查找表——其中不維護歷史的小維度。 只需代理鍵、業務鍵和一兩個屬性。 在事實表加載期間，代理鍵是從查找表中獲取的（連接基於業務鍵）。 所以基本上在事實加載的某個階段，我們在事實中有業務鍵，用於從查找表中獲取代理鍵，在該操作之后，業務鍵消失了，稍后例如在數據集市（用於報告目的）我們可以加入查找事實上，僅對某些屬性使用代理鍵。 到目前為止，這個過程相當簡單，因為我們只使用一個業務鍵來設置屬性值。

但是現在有些情況下我們應該使用 3 個甚至更多。

例如，這些是條件：

COLUMN_1 = 'ABC' 
AND COLUMN_2 <> 'Z'
AND COLUMN_3 IN ('1', '2')

COLUMN_1 = 'ABC' 
AND COLUMN_2 <> 'Z'
AND  COLUMN_3 IN ('3', '4', '5')

COLUMN_1 <> 'ABC' OR COLUMN_2 = 'Z'

COLUMN_1、COLUMN_2、COLUMN_3 是事實表中顯示的業務鍵。 當然，上面的邏輯將應用於查找負載，所以假設我們將有 3 個代理鍵：1、2 和 3。

但主要問題是 - 哪種方法更適合事實表：

• 復制從查找加載到事實加載的邏輯？ 更好的性能，但這對維護來說更糟（如果將來需要更改，則需要在兩個地方應用更改），並且代理鍵也需要硬編碼。
• 把以上條件放在join條件中？ 顯然，維護會更好，但性能更差（事實表每天插入大約 10 000 000 行）。
• 或者也許有另一種解決方案？ 在源系統中組合上述條件也不是一種選擇。

歡迎提出所有建議。

Answer 1

過去，我曾多次模擬代理鍵和事實負載，根據我的經驗（15 年），最好的平衡是以下設計：

代理鍵表設計(dim_sgk) Dim_ID BR1_ID1 BR1_ID2 BR1_ID3 BRn_IDx... Record_Start_dttm

假設您有一個階段表 (stg_tbl)，您可以在其中使用業務鍵 src1.col1、src1.col2 和 src1.col3 加載源數據/文件

現在，當您從階段表加載代理鍵表時，您

Select *
from 
stg_tbl left outer join dim_sgk 
on stg_tbl.src1.col1 = dim_sgk.br1_id1
and stg_tbl.src1.col2 = dim_sgk.br1_id2
and stg_tbl.src1.col3 = dim_sgk.br1_id3
where dim sgk.dim_id is null

並為 3 個業務密鑰的所有唯一組合生成（或基於 rdbms 技術及其優缺點自動）代理密鑰。

一次，代理鍵表被刷新； 您可以通過將源交易表與代理鍵表連接並沿途獲取代理鍵（左外連接）來開始加載您的事實

我已經將事實表中的業務鍵作為非 pk 屬性保留，僅用於報告目的。 無需將代理鍵與事實連接起來，以便稍后僅選擇業務鍵。 您可以使用代理鍵來優化磁盤上數據的連接和分布。 但是，在將業務密鑰保留為非識別屬性的同時，實際上您可以兩全其美。

您應該牢記代理鍵的多項原則（錯誤處理、孤立處理等）。 根據您的 rdbms 技術，根據某個索引對表進行分區可能是有意義的，這有助於您檢索錯誤/-1 並將它們重新處理到事實表中，而不會影響任何性能。 如果您需要了解有關此技術的更多信息，請隨時與我聯系。 樂於幫助。

我為另一個關於 SGK 的問題整理了一個非常詳細的指南，您可以將其用作參考管理數據倉庫中的代理鍵

親切的問候，巴巴爾