草擬 Essbase 大綱

草擬 Essbase 資料庫模型之後，您可以建立應用程式與資料庫，並建立大綱的第一個草稿。草稿會定義所有維度、成員和整合。使用大綱來設計合併需求，並識別需要公式和計算命令檔的位置。

大綱是 Essbase 資料庫 (或立方體) 的一部分，存在於 Essbase 應用程式中。

若要使用先前引進的飲料公司範例，TBC 應用程式設計人員會針對資料庫大綱發出下列草稿。在此計劃中，Year、Measures、Product、Market、Scenario、Pkg Type 和 Ounces 均為維度名稱。觀察 TBC 預期合併、計算與公式以及報告需求的方式。應用程式設計者也會使用產品代碼，而非產品名稱來描述產品。

年度。 TBC 需要每月收集資料，並依季度和年度彙總每月資料。儲存在 1 月、2 月和 3 月等成員中的每月資料會合併至季。儲存在第 1 季和第 2 季等成員中的每季資料會合併至「年度」。
計量。銷售、銷貨成本、行銷、薪資、雜項、期初存貨、新增及期末存貨都是標準評量。Essbase 可以從這些計量計算「利潤」、「總支出」、「利潤」、「存貨總計」、「利潤百分比」、「利潤百分比」和「每一盎司的利潤」。TBC 需要計算每月、每季和每年的評量。
產品。產品代碼為 100-10、100-20、100-30、200-10、200-20、200-30、200-40、300-10、300-20、300-30、400-10、400-20 及 400-30。每項產品均整合至其各自的系列 (100、200、300 及 400)。每個整合都允許 TBC 依大小和套件進行分析，因為每個產品都與 Ounces 和 Pkg Type 屬性維度的成員相關聯。
Market。數個州組成一個區域；四個區域組成一個市場。這些州包括康乃狄克州、佛羅里達州、麻薩諸塞州、新罕布夏州、紐約州、加州、內華達州、奧勒岡州、猶他州、華盛頓州、路易斯安那州、新墨西哥州、奧克拉荷馬州、德克薩斯州、科羅拉多州、伊利諾州、愛荷華州、密蘇里州、俄亥俄州和威斯康辛州。每個州 / 省會合併至其區域 - 東部、西部、南部或中部。每個區域都整合到 Market。
案例。 TBC 衍生並追蹤預算與實際資料的比較。經理必須監控和追蹤預算和實際值，以及兩者之間的差異和差異百分比。
Pkg Type。 TBC 想要查看產品包裝對銷售與利潤的影響。建立「套裝軟體類型」屬性維度，可讓使用者根據產品是否包裝成瓶子或罐子來分析產品資訊。
盎司 TBC 在不同市場以不同規模的盎司銷售產品。建立「盎司」屬性維度可協助使用者監控哪些規模在哪些市場中銷售較佳。

下一個主題介紹維度和成員特性的基本概念，並探討大綱設計如何影響效能。

維度型態

維度類型是 Essbase 提供的特性，可將特殊功能新增至維度。專業且常用的維度類型為時間、帳戶和屬性。

本主題使用下列 TBC 資料庫維度來說明維度類型。

Database:Design
  Year (Type: time)
  Measures (Type: accounts)
  Product
  Market
  Scenario
  Pkg Type (Type: attribute)
  Ounces (Type: attribute)

下表定義每個 Essbase 維度類型。

表格 1-4 維度類型

維度型態	描述
無。	指定沒有特定的維度類型。
Time	定義您報告與更新資料的時間週期。您一次只能標記一個維度。時間維度可啟用多個帳戶維度函數，例如第一個與最後一個時間餘額。
帳戶	包含您要測量的項目，例如利潤和庫存，並且提供 Essbase 內建會計功能。只能將一個維度定義為帳戶。
屬性	包含可用來描述另一個所謂基本維度之成員的成員。例如，「Pkg 類型」屬性維度包含適用於 Product 維度成員之每種包裝類型的成員，例如瓶或罐。
國家 (僅用於貨幣轉換功能)	包含有關業務活動發生地點的資料。在國家維度中，您可以指定每個成員中使用的貨幣。例如，加拿大有三個市場 - 溫哥華、多倫多與蒙特婁，使用相同的貨幣，即加拿大元。

Member Storage Properties

指定成員的資料儲存特性，以定義儲存整合的位置與時機。依預設，成員會標記為已儲存： Essbase 會加總其值，並將結果儲存在父項層級。您可以變更資料儲存特性標記來變更每個成員的預設邏輯。

下表說明 Essbase 資料儲存特性對成員的影響。

表格 1-5 Essbase 資料儲存特性

資料儲存體特性	對會員的影響
儲存資料	成員的資料儲存於資料庫中。儲存資料是預設儲存特性。Essbase 會加總值並將結果儲存在父項層級。
動態計算	與成員關聯的資料會在使用者查詢要求時計算。計算的資料不會儲存；在查詢要求完成後便會捨棄。
共用成員	與成員關聯的資料來自另一個具有相同名稱的成員。
不共用	如果有隱含的共用關係存在，則與成員關聯的資料會與父項及其子項重複。資料會以大綱順序與成員第一次出現時一併儲存。
僅限標籤	對於沒有關聯資料的成員，您可以將已儲存的成員變更為僅標籤。雖然僅標籤成員沒有資料，但是可以顯示值。標籤僅用於標記群組成員，並簡化導覽和報告。通常不會計算僅標籤成員。例如，在 Measures 維度中，成員 Ratios 有三個子項：Margin%、Profit% 和 Profit per Ounce。成員比率定義成員的類別。合併時，「利潤」、「利潤」和「每盎司的利潤」不會累計至「比率」的有意義數字。因此，比率僅標記為標籤。

維度與成員特性的檢查清單

您可以識別時間維度嗎？
是否可以識別帳戶維度？
資料是否包含外幣？如果是，您是否識別幣別分割區維度？
是否可以識別應定義為個別屬性維度的維度品質或特性？
哪些成員需要特殊的資料儲存特性？

設計大綱以最佳化效能

將屬性維度放置在 Essbase 大綱的結尾、在稀疏之前放置密集維度，以及先排序具有最少成員的稀疏維度。維度在大綱中的位置，以及維度的儲存特性，會影響計算的執行速度，以及擷取資料所需的時間。

最佳化查詢效能

若要最佳化查詢效能，請在設計大綱時使用下列準則：

如果大綱包含屬性維度，請確定屬性維度是大綱中唯一的稀疏動態計算維度。
在大綱中，將較為查詢的稀疏維度放在較少查詢的稀疏維度之前。

下列大綱是針對最佳查詢效能所設計：

由於大綱包含屬性維度，因此標準維度和所有標準維度成員的儲存特性會設定為儲存資料。
作為最嚴格的稀疏維度，「產品」維度是稀疏維度的第一個。基本維度通常會查詢其他維度。

圖 1-5 設計最佳化查詢時間的大綱

最佳化計算效能

若要最佳化計算效能，請依成員數目排序大綱中的稀疏維度，從包含最少的維度開始。

下列大綱是專為最佳計算效能所設計：

稀疏的最小標準標註 Market 是大綱中的第一個稀疏標註。
稀疏 (Product) 的最大標準維度會緊接在第一個屬性維度上方。如果大綱未包含屬性維度，則 Product 維度會位於大綱的結尾。

圖 1-6 設計最佳化計算時間的大綱

滿足計算和擷取的需求

雖然它們包含相同的維度，但先前顯示的範例大綱不同。若要決定情況的最佳大綱順序，請依據在資料庫上執行計算所需的時間，排列使用者資料擷取需求的優先順序。您預期多久會更新及重新計算資料庫？使用者查詢的本質為何？預期的使用者查詢量為何？

可能的解決方法是將維度初始定位在大綱中，以最佳化計算。執行計算之後，您可以手動重新排序維度，以最佳化擷取。當您重新定位大綱的維度後儲存大綱時，請選擇只依索引重新建構資料庫。在您再次執行計算之前，請重新排序大綱中的維度以最佳化計算。