分析和規劃 Essbase 應用程式

為了確保您的 Essbase 應用程式能有效率地分析您的商業資訊，請制定詳細計劃，概述資料來源、使用者需求和前瞻性資料庫元素。關注此設計階段可節省您的開發和導入時間。

計劃與分析階段包含下列任務：

設計多維應用程式時，請考量下列因素：

  • 資訊在公司內部的流動方式—使用哪些資料作為用途

  • 公司的報告類型—大綱中必須包含哪些類型的資料，以滿足使用者報告需求

    附註：

    每個應用程式只定義一個資料庫，可增強記憶體使用狀況並簡化資料庫管理。

分析來源資料

評估要包含在 Essbase 資料庫中的資料。請考慮更新來源，以及所需的頻率和大小。您應該只載入 Essbase 以進行樞紐分析報告和鑽研。其餘部分則可以保留在關聯式來源中，供分割區存取或鑽研使用。

決定資料庫的範圍。如果組織有許多包含大量產品的產品系列，您可能只想要儲存產品系列的資料值。每個使用者部門的面試成員，以瞭解他們處理的資料、今天的計算和報告資料的方式，以及他們未來要如何處理。

請仔細定義報告與分析需求。

  • 使用者要如何檢視和分析資料？

  • 資料庫應包含多少明細？

  • 資料是否支援所需的分析和報告目標？

  • 如果不是，您需要哪些額外資料，以及您可以在哪裡找到這些資料？

判斷目前資料的位置。

  • 每個部門目前在哪裡儲存資料？

  • 表單中的資料是否可供 Essbase 使用？

  • 部門是否會將資料儲存在 Windows 或 UNIX 伺服器或 Excel 試算表中的關聯式資料庫？

  • 誰會更新資料庫，以及更新的頻率？

  • 需要更新資料的人員是否有權存取該資料？

確定資料已準備好載入 Essbase 。

  • 資料來自單一來源或多個來源嗎？

  • Essbase 可以使用的格式資料嗎？如需您可以載入至 Essbase 的有效資料來源清單，請參閱資料來源。

  • 您想要使用的所有資料是否都可供使用？

識別使用者需求

當您規劃 Essbase 資料庫時，請與目前的資料使用者討論資訊需求，並向他們要求範例報表。複查他們使用的資訊，以及他們必須產生以供其他人複查的報表。

決定下列需求：

  • 使用者需要哪些類型的分析？

  • 使用者是否需要特設 (樞紐樣式) 報告和結構化報表？

  • 使用者需要哪些資訊摘要和詳細資料層級？

  • 某些使用者是否需要存取其他使用者不應該看到的資訊？

規劃多重使用者環境的安全性

在規劃如何設定 Essbase 安全性權限時，識別不同層級的使用者資訊需求。在分析結束時，您應該要有一份使用者清單及其所需的權限。

使用此核對清單規劃安全性：

  • 誰是使用者，以及他們在資料庫中讀取或寫入資料的權限？

  • 誰應該具備載入資料權限？

  • 誰應該有執行計算的權限？

  • 哪些使用者可以分組並指派相似的權限？

另請參閱管理使用者與角色。

建立資料庫模型

建立 Essbase 資料庫的模型。若要建立模型，您必須識別對您的業務至關重要的觀點與檢視。這些視觀表會轉譯成資料庫模型的維度。

許多企業分析下列觀點：

  • 期間

  • 測量

  • 分析藍本

  • Products

  • 客戶

  • 地理區

  • 業務單位

接下來，為了協助您收集資訊並做出決策，您需要識別資料分析目標、決定資料庫維度和成員，並分析資料庫設計。

識別分析目標

在您識別商業中資訊的主要檢視之後，設計 Essbase 資料庫的下一個步驟就是決定資料庫如何進行資料分析。例如，您可能需要依時段、地理位置或產品類型來檢視資料。

  • 如果依時間分析，需要哪些時間週期？分析是否應僅包含目前年度或多重年度？分析是否應包含每季和每月資料？是否應依季節包含資料？

  • 如果依地理區域分析，您如何定義區域？您是否依銷售區域定義區域？您是否依地理邊界定義區域，例如州 / 省和城市？

  • 如果依產品線分析，您是否應複查每項產品的資料？是否可以將資料彙總至產品類別？

不論業務檢視為何，您都必須決定分析中所需的觀點與詳細資料。您分析的每個業務區域都會提供不同的資料檢視。

決定維度與成員

您選擇的 Essbase 維度會決定您可以執行的分析類型。在每個維度內，成員階層代表業務層面。例如，時間階層可能包含季和月。產品階層會將產品分類。區域階層是以地理市場為基礎。

您可以將每個業務視圖在資料庫中以個別的標準維度表示。您可能聽過業務分析師的說法，例如按產品、地理位置和時間週期。如果您需要依分類或屬性來分析業務視圖，例如依產品的大小或顏色，您可以使用屬性維度或屬性來代表分類視圖。

您可以視需要使用多個維度進行分析。當您瞭解需要哪些維度和成員時，請開發暫訂的資料庫設計。

在您決定資料庫模型的維度後，請選擇每個維度中的元素或項目。這些元素會成為其個別維度的階層和成員。例如，時間階層可能包含您要分析的期間，例如季度，季度、月。每季與月份都會成為您為時間所建立之維度的成員。季和月代表成員及其子項的兩層階層。一季內的月數可以合併為每季的總計。

維度之間的關係

考量維度之間的關係。Essbase 資料庫的結構可讓使用者輕鬆分析來自許多觀點的資訊。例如，財務分析師可能會提出下列問題：

  • 特定月份的銷售額為何？此數字與過去五年同月的銷售額相比如何？

  • 利潤率的增加百分比為何？

  • 實際值與預算值的接近程度為何？

換句話說，分析師可能想要從三個維度 (時間、帳戶和案例) 檢查資訊。下圖的範例資料庫代表這三個維度，三個軸各代表一個維度：

  • 時間維度 (包括 Jan、Feb、Mar 以及 Qtr1 的總計) 會顯示在 X 軸上。

  • 會在 Y 軸上顯示由會計數字 (例如 Sales、COGS、Margin 和 Margin%) 所組成的科目維度。

  • 另一個維度，提供不同的檢視點，例如預算值的預算和實際值的實際值，都會顯示在 Z 軸上。

圖 1-1 代表三個資料庫維度的立方體


此圖像顯示代表三個維度的立方體，如影像前面的文字所述。

立方體內成員交集的儲存格包含與所有三個交集成員相關的資料；例如，一月的實際銷售。

範例維度 - 成員結構

下表顯示 TBC 維度的摘要。應用程式設計人員建立了三個欄，其中維度位於左欄，成員位於右兩欄。欄 3 中的成員是欄 2 中成員的子類別。在某些情況下，欄 3 中的成員會分成另一個層級的子類別；例如，「測量」維度的「邊界」會分成「銷售」和「銷貨成本」。

表格 1-1 TBC 範例維度

尺寸 成員 下階成員

Year

Qtr1

1 月、2 月、3 月

Year

Qtr2

四月、五月、六月

Year

Qtr3

7 月、8 月、9 月

Year

Qtr4

10 月、11 月、12 月

測量

利潤

毛利：銷售、銷貨成本

費用總計：行銷、給薪、雜項

測量

產品目錄

期初存貨、新增、期末存貨

測量

比率

毛利百分比、利潤百分比、每單位利潤

Product

科拉斯 (100)

Cola (100-10)、Diet Cola (100-20)、Caffeine Free Cola (100-30)

Product

根啤酒 (200)

舊時尚 (200-10)、飲食根啤酒 (200-20)、沙沙沙帕利亞 (200-30)、比爾奇啤酒 (200-40)

Product

保濕霜 (300)

暗霜 (300-10)，香草霜 (300-20)，香草霜 (300-30)

Product

水果蘇打 (400)

葡萄 (400-10)、橙色 (400-20)、草莓 (400-30)

Market

East

康乃狄克州、佛羅里達州、麻薩諸塞州、新罕布夏州

Market

西部

California，Nevada，Oregon，Utah，華盛頓州

Market

南部省

路易斯安那州、新墨西哥州、奧克拉荷馬州、德克薩斯州

Market

中央區

科羅拉多州，伊利諾州，愛荷華州，密蘇里州，俄亥俄州，威斯康辛州

案例

實際值

無

案例

Budget

無

案例

差異

無

案例

差異百分比

無

此外，應用程式設計人員新增了下列屬性維度，以根據大小與包裝啟用產品分析：

表格 1-2 TBC 範例屬性維度

尺寸 成員 下階成員

盎司

大型

小型

64, 32, 20

16, 12

攜帶包類型

瓶子

可以

無

決定維度與成員的核對清單

決定模型資料庫的維度與成員時，請使用下列核對清單：

  • 維度的候選項目為何？

  • 是否有任何維度分類或描述其他維度？這些維度是屬性維度的候選項目。

  • 使用者是否想要限定其維度檢視？符合維度資格的類別是屬性維度的候選項目。

  • 成員有哪些應徵者？

  • 資料需要多少個層次？

  • 資料如何合併？

分析資料庫設計

根據下列關於維度數、其合併分析值及避免重複的準則，複查初始 Essbase 維度設計。執行此前期分析可協助您達到符合資料整合與計算目標的高效率資料庫設計。

描述潛在資料點所需的成員數目應該決定維度數目。如果您不確定是否應該刪除維度，請保留維度並套用更多分析規則，直到您對刪除或保留維度有信心為止。

密集和稀疏維度

哪些維度是稀疏維度，哪些維度是密集維度會影響效能。請參閱：

標準與屬性維度

為了簡化，本主題中的範例顯示了最初設計為兩個維度的替代安排。您可以將相同的邏輯套用至所有維度組合。

考慮在多個市場中向多個客戶銷售產品的公司設計；每個客戶都有唯一的市場：

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

Cust A 只在紐約，Cust B 只在伊利諾州，Cust C 只在加州。公司可以在一個標準維度中定義資料：

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

不過，如果您查看較大的資料抽樣，您可能會看到每個市場都可以有很多客戶。Cust A 與 Cust E 位於紐約；Cust B、Cust M 與 Cust P 位於伊利諾州；Cust C 與 Cust F 位於加州。在此情況下，公司通常會將大型維度 Customer 定義為標準維度，而較小的維度 Market 則定義為屬性維度。公司將 Market 維度的成員關聯為 Customer 維度成員的屬性。Market 維度的成員描述客戶的位置 — 每個客戶只有一個市場。

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

請考慮其他情況。同樣，公司在多個市場中向多個客戶銷售產品，但公司可以銷售給在不同市場中具有地點的客戶：

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

客戶 A 位於紐約和加州。客戶 B 位於紐約和伊利諾州。客戶 C 只在加州。在此情況下，使用屬性維度無法運作；客戶成員不能有多個屬性成員。因此，公司將資料設計成兩個標準維度：

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

維度組合

將兩個維度的每個組合分成二維矩陣。例如，TBC 的建議維度包含下列組合：

  • 跨評量年度

  • 跨產品的年度

  • 跨市場的年度

  • 跨情境的年度

  • 跨產品的評量

  • 跨市場的評量

  • 跨情境的評量

  • 產品的市場

  • 整個情境的市場

  • 跨產品的案例

  • 跨套件類型的盎司

「盎司」和「Pkg 類型」(作為與 Product 維度關聯的屬性維度) 可以與 Product 維度一起考慮。

為了協助視覺化每個維度，請繪製矩陣並包含一些第一代成員。下圖為三個維度顯示一組簡化的矩陣。

圖 1-2 分析維度關係


此圖像顯示三個維度的簡化矩陣集，說明如何分析維度關係。

針對每個維度組合，請問三個問題：

  • 是否會新增分析值？

  • 是否新增報表的公用程式？

  • 它是否避免過多的未使用組合？

對於每個組合，問題的答覆可協助決定組合對資料庫是否有效。理想上，每個問題的答案為是。如果沒有，請考慮將資料重新排列成更有意義的維度。當您進行此處理程序時，請與使用者討論資訊需求。

大綱中的重複

大綱中的元素重複通常表示需要分割維度。下列範例顯示如何避免重複。

在此範例中，標示為「重複」的左欄顯示在 Accounts 維度中 Budget 和 Actual 下重複的 Profit、Margin、Sales、COGS 和 Expenses。右欄標示為「不重複」，將 Budget 和 Actual 分隔為另一個維度 (Scenario)，在 Accounts 維度中僅留下一組 Profit、Margin、Sales、COGS 和 Expenses 成員。此方法可簡化大綱，並更簡單地檢視資料庫中其他維度的預算與實際數據。

圖 1-3 建立案例維度以消除重複的範例


此影像提供重複問題的解決方法，如影像前面的文字所述。

在此範例中，標示為「重複」的左欄使用 Diet 維度中的共用成員來分析飲食飲料。100 – 20、200 – 20 和 300 – 20 成員重複：一次在飲食之下，一次在各自的父母之下。右欄標示為「不重複」，透過建立類型為布林 (True 或 False) 的 Diet 屬性維度來簡化大綱。所有成員都只會在其各自的父項下顯示一次，並以適當的屬性 (「Diet：True」或「Diet：False」) 標記。

圖 1-4 建立屬性維度以消除重複的範例


此影像提供重複問題的解決方法，如影像前面的文字所述。

屬性維度也提供其他分析功能。請參閱 Essbase 屬性的優點。

維度間不相關性

當維度的許多成員與其他維度不相關時，會發生維度間的不相關性。Essbase 會將不相關的資料定義為 Essbase 只儲存在摘要 (維度) 層級的資料。在這種情況下，您可以從資料庫移除維度，並將其成員新增至其他維度，或將模型分割至個別的資料庫。

例如，TBC 考慮將薪資分析為 Measures 維度的成員。但是薪資資訊在公司資料庫的環境定義中往往是不相關的。大部分的薪資都是機密的，且適用於個人。個人和薪資通常代表一個儲存格，沒有與任何其他維度相交的原因。

TBC 考慮將員工區分為個別維度。下表顯示 TBC 如何針對維度間不相關性分析建議之 Employee 維度的範例。提議的 Employee 維度成員 (在表格標頭資料列中表示) 會與 Measures 維度的成員進行比較 (在最左邊的資料欄中表示)。Measures 維度成員 (如 Revenue) 適用於「所有員工」；只有「薪資」評量與個別員工相關。

表格 1-3 維度間無關的範例

空格儲存格使用空間影像 Joe Smith Mary Jones Mike Garcia 所有員工

收益

不相關性

不相關性

不相關性

相關性

變動成本

不相關性

不相關性

不相關性

相關性

COGS

不相關性

不相關性

不相關性

相關性

宣告中

不相關性

不相關性

不相關性

相關性

薪資

相關性

相關性

相關性

相關性

固定成本

不相關性

不相關性

不相關性

相關性

支出

不相關性

不相關性

不相關性

相關性

利潤

不相關性

不相關性

不相關性

相關性

分割資料庫的原因

由於個別員工資訊與資料庫中的其他資訊無關，而且由於新增 Employee 維度會大幅增加資料庫儲存需求，因此 TBC 建立了個別的人力資源 (HR) 資料庫。新的 HR 資料庫包含一組相關維度，且包含薪資、福利、保險和 401 (k) 計畫。

分割資料庫的原因很多，例如，假設公司維護的組織資料庫包含數個時區中的數個國際子公司。每個子公司都依賴具時效性的財務計算。您可以將資料庫分割為時區相同的子公司群組，以確保及時進行財務計算。您也可以使用分割的應用程式，依子公司分隔資訊。

分析資料庫設計的檢查清單

使用下列核對清單來分析資料庫設計：

  • 您是否已將維度數目降到最低？

  • 對於每個維度組合，您是否詢問：

    • 是否會新增分析值？

    • 是否新增報表的公用程式？

    • 它是否避免過多的未使用組合？

  • 您是否避免在大綱中重複？

  • 您是否避免維度間的不相關性？

  • 您是否已視需要分割資料庫？