典型的Kimball星型模式數據倉庫 - 模型視圖可行嗎？以及如何代碼生成

我有一個包含典型的星型架構數據倉庫，以及一大堆的代碼，做這樣的東西（顯然大了很多，但這是舉例）：典型的Kimball星型模式數據倉庫 - 模型視圖可行嗎？以及如何代碼生成

SELECT cdim.x 
    ,SUM(fact.y) AS y 
    ,dim.z 
FROM fact 
INNER JOIN conformed_dim AS cdim 
    ON cdim.cdim_dim_id = fact.cdim_dim_id 
INNER JOIN nonconformed_dim AS dim 
    ON dim.ncdim_dim_id = fact.ncdim_dim_id 
INNER JOIN date_dim AS ddim 
    ON ddim.date_id = fact.date_id 
WHERE fact.date_id = @date_id 
GROUP BY cdim.x 
    ,dim.z

我想以期替換它（MODEL_SYSTEM_1，說的），使之成爲：

SELECT m.x 
    ,SUM(m.y) AS y 
    ,m.z 
FROM MODEL_SYSTEM_1 AS m 
WHERE m.date_id = @date_id 
GROUP BY m.x 
    ,m.z

但有一種觀點MODEL_SYSTEM_1必須包含唯一的列名，我還擔心與優化，如果我表現繼續做吧，因爲我擔心WH中的所有項目在不同的事實和維度ERE條款得到優化，因爲認爲要橫跨整個明星，意見不能被參數（男孩，那不是很酷！）

所以我的問題是 -

這種方法行得通嗎？或者它只是一個抽象，會傷害性能，除了更好的語法之外，不會給我任何東西？
考慮到所有適當的PK和FK都存在，對這些視圖進行編碼的最佳方式是什麼？消除重複的列名稱（即使稍後需要手動調整視圖）？我是否應該寫一些SQL將其從INFORMATION_SCHEMA中提取出來，或者有一個很好的示例。

編輯：我已經測試過它，而且性能似乎是相同的，甚至更大的過程 - 甚至在加入多顆，每個使用這些視圖。

自動化主要是因爲數據倉庫中有許多這些星星，設計師已經正確地完成了FK/PK，但是我不想挑選所有的表或者文檔。我編寫了一個腳本來生成視圖（它也會生成表格的縮寫），並且它可以很好地從INFORMATION_SCHEMA自動生成框架，然後可以在提交視圖創建之前對其進行調整。

如果有人想要代碼，我可以在這裏發佈它。

來源

2008-09-24 Cade Roux

我在我看過的幾個數據倉庫上使用過這種技術。運行基於視圖的報告與表格直接方法相比，我沒有注意到任何性能下降，但從未執行過詳細的分析。
我創建使用設計器在SQL Server Management Studio中的意見，並沒有使用任何自動化的方法。我無法想象模式經常變化，無論如何自動化都是值得的。您可能需要花費很長時間調整結果，因爲它將首先將所有表拖放到視圖上！

要消除歧義，一個好方法是在列名前面加上它所屬的維度的名稱。這對報告編寫者和運行特別查詢的任何人都有幫助。

來源

2008-09-25 18:36:48

使視圖或視圖進入一個或多個摘要事實表並實現它。這些只需刷新主事實表時刷新。物化視圖的查詢速度會更快，如果您有大量可通過摘要滿足的查詢，則這可能是一個勝利。

如果您有大量摘要或希望對其進行頻繁更改，則可以使用數據字典或信息模式視圖來生成SQL以創建表。

但是，我猜想你不太可能經常改變它們，所以自動生成視圖定義可能不值得麻煩。

來源

2008-09-24 17:24:11 ConcernedOfTunbridgeWells

我沒有跟隨這 - 如果我壓扁全明星成有效的表索引的不同的方式，什麼是三維模型擺在首位的地步？ – 2008-09-24 17:55:59

不扁平化，捲起來。如果您要彙總數據，則應考慮實現視圖。這會更快。 – ConcernedOfTunbridgeWells 2008-09-24 18:55:21

如果你碰巧使用MS SQL Server中，你可以嘗試內聯UDF這是接近一個parameterized view，因爲它得到。

來源

2009-10-26 15:46:54

典型的Kimball星型模式數據倉庫 - 模型視圖可行嗎？以及如何代碼生成

回答

相關問題