Dimensional和cube developme數據模型

Question

我創建了一個結構與AdventureworksDW環境中的財務報告設計類似的維度模型，其中每個帳戶的值在事實表中保存爲單個值列，維度爲數據提供其語義。

該模型中有超過一千個列，因此適用於添加或刪除其他列。這是一個非常好的設計博客：http://garrettedmondson.wordpress.com/2011/10/26/dimensional-modeling-financial-data-in-ssas/

雖然這個模型適用於查詢維度模型，並且有支持這個模型的維度分析的例子，但我擔心這個模型不是標準的多維數據集開發或數據挖掘，似乎喜歡更寬的表格。

問題： 此設計是否被歸類爲Entity-Attribute-Value（EAV）？

使用多個事實表的設計會更好嗎？如此多的寬事實表（最多10個），每個列最多200-300列，但行數更少。

我應該期望更寬泛的表更多的性能問題？

Answer 1

你說得對，特定的設計被認爲是EAV模型。

通過使用這樣的設計，您可以輕鬆地添加新的帳戶，層次結構等。您不需要更新您的模型。

我不會推薦每一項措施一列。大部分行中的大多數帳戶都爲空。也有這樣的設計，即使只需要檢索其中的一個，也需要閱讀所有措施。

我們在我們的立方體中大量使用帳戶維度。不幸的是像共享成員這樣的東西在EASbase中很難像SSAS那樣處理。

您需要創建一個父子維度的帳戶維度，並且您還需要像平常一樣在事實表中擁有此維度的維度。 通過使用帳戶維度，您可以很好地支持時間平衡功能。使用SSAS的時間平衡功能應該比自定義MDX代碼更快。

我們正在將一元運算符和父子關係轉換爲公式。 所以基本上我們有正常的公式，並且層次結構中的父母也可以用作公式。 最後，我們正在扁平化層次結構。所以不可能在帳戶維度中向下鑽取。我們僅將帳戶維度用作計算引擎。 也可能有適當的層次結構，但我們決定不同時混合自定義彙總成員和一元運算符。

共享成員以及作爲自定義彙總成員實現的所有公式。