SSAS - 自然層級中的屬性關係

Question

我發現很難正確理解用於實現SQL Server Analysis Services 2008 R2中的維度屬性之間的屬性關係的最佳用例方案。

從我讀，似乎「非自然層次結構」，這樣才能避免由於性能原因和「自然」層次結構是首選的用戶定義的層次結構。

參考：http://support.microsoft.com/kb/2131988

這是說，我想問一下在以下情況下您的想法：

我有一個具有以下屬性的維度：

---

維名稱： DimReserveData
Dimension會員：

程序線
覆蓋率代碼
覆蓋類型
覆蓋情況，

---

我想向層次結構中這些屬性以相同的順序如下圖所示：

ReserveDataHierarchy
........................................
程序線
覆蓋率代碼
覆蓋類型
覆蓋情況，
................................ ........

層次信息：

程序行表示正在提供的保險程序的代碼。 （例如：AA-23，BB-25，CC-78等）

覆蓋代碼屬性表示代表針對特定程序行提供的特定覆蓋的數字代碼。 （例如：123,456等）

覆蓋類型表示與特定覆蓋代碼綁定的覆蓋類型。 （例如：車輛或身體）。

覆蓋狀態表示給定覆蓋（開放或關閉）的狀態。

因此，我們可以說以下有關基數的層次結構中：

一個程序行可以包含多個覆蓋碼。
一個覆蓋代碼可以包含很多類型。
一種覆蓋類型可以包含許多狀態值。

因此，在瀏覽層次將產生以下屬性和相應的部件：

DimReserveData
...................... .................................................. ............................ * ..................... ............
程序行|覆蓋代碼|覆蓋類型|覆蓋狀態 .............................................. .................................................. ......................................
AA-12 ....... .......... 123 ....................車輛................打開
BB-14 ................. 456 ....................車載....... ..........關閉
CC-23 ................. 123 ................ ...車輛.................打開
DD-23 ................. 456 ..... ...............身體......................打開

我的問題是，如果它在一個模型中對這些屬性建模將是一個很好的實踐「自然」或「不自然」等級。我想使用「自然」層次來提高性能。

很明顯，將這個層次結構建模爲「自然」將需要使用屬性關係。

回到上面的示例層次結構中，如果給定Coverage Code屬性屬於多個Program Line以及包含相同Coverage Type的多個Coverage Codes，那麼是否可以使用「Natural」層次？

在這篇有用的文章中提到：在一個城市屬於多個州或省的場景中，可以修改屬性鍵列，以便層次結構中的每個屬性都是唯一定義的。

這個工作在我上面的例子中嗎？

，我想我可以模擬像這樣的屬性關係：（SSAS使用2008 R2）

[代理鍵屬性從維度] - >覆蓋狀態 - >覆蓋類型 - >覆蓋率代碼 - - >程序線

每個屬性上面將有它的鍵列設置像這樣：

.......................... ..........
覆蓋範圍：
...... ..............................
覆蓋情況，
覆蓋類型

....... .............................
覆蓋類型：
............ ........................
覆蓋類型
覆蓋率代碼

............. .......................
覆蓋率代碼：
....................................
覆蓋率代碼
計劃
線

....................................
程序線：
....................................
程序線

將這項工作？這種情況是否更適合「不自然」層次結構？

我非常感謝您閱讀我的文章！

謝謝！

Answer 1

如果你必須在層次結構中有這些，強制它是一個自然的。你會付出較不嚴格的性能損失，而不僅僅是使用不自然的層次結構。具有強制自然層次的懲罰主要與密鑰大小的增加有關（因爲您將使用組合鍵來自然化層次結構）。

但也許你應該考慮通過將這些屬性強制到用戶層次結構中來嘗試實現的目標是什麼？

是爲了簡化一些MDX查詢嗎？ 尺寸是否太寬（與鍵直接相關的屬性太多）並在處理過程中導致內存壓力？

如果答案只是將這些屬性分組爲用戶界面（例如Excel），那麼您可能需要考慮簡單地使用命名約定來允許這些屬性以您喜歡的順序出現...