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

Question

我有一個包含典型星型模式的數據倉庫，還有一大堆代碼可以做這樣的事情（顯然要大得多，但這是說明性的）：

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 ， 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必須包含唯一的列名，如果我繼續這樣做，我也會關注優化器的性能，因為我擔心WHERE子句中不同事實和維度的所有項都會得到優化，因為視圖將跨越整個星，並且視圖不能被參數化（男孩，不會那么酷！）

所以我的問題是 -

1. 這種方法是否正常，或者它只是一個會損害性能的抽象，並且不會給我任何東西，但語法更好？

2. 考慮到所有適當的PK和FK都已到位，對這些視圖進行代碼生成的最佳方法是什么，消除重復的列名稱（即使稍后需要手動調整視圖）？ 我應該只編寫一些SQL來將其從INFORMATION_SCHEMA拉出來，還是已經有一個很好的例子。

編輯：我已經對它進行了測試，性能似乎相同，即使是在更大的流程上 - 甚至連接多個使用這些視圖的星星。

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

如果有人想要代碼，我可以在這里發布。

Answer 1

1. 我在我照看的幾個數據倉庫上使用過這種技術。 在基於視圖和表直接方法運行報表時，我沒有注意到任何性能下降，但從未執行過詳細分析。

2. 我使用SQL Server管理工作室中的設計器創建了視圖，並沒有使用任何自動化方法。 我無法想象模式經常變化，無論如何自動化它都是值得的。 您可能會花費很長時間來調整結果，因為它首先將所有表拖到視圖上！

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

Answer 2

將視圖或視圖放入一個或多個摘要事實表中並實現它。 只有在刷新主事實表時才需要刷新這些內容。 物化視圖的查詢速度會更快，如果您有很多可以通過摘要滿足的查詢，這可能是一個勝利。

如果您有大量這些摘要或希望經常更改它們，則可以使用數據字典或信息模式視圖生成SQL以創建表。

但是，我猜你不太可能經常更改這些，因此自動生成視圖定義可能不值得。

Answer 3

如果您碰巧使用MS SQL Server，則可以嘗試使用內聯UDF，該內聯UDF盡可能接近參數化視圖 。