分析和规划 Essbase 应用程序
为了确保 Essbase 应用程序能够有效地分析您的业务信息，请制定详细的计划来概括数据源、用户需求和预期数据库元素。注意这个设计阶段可以为您节省开发和实施时间。
计划和分析阶段涉及以下任务：
设计多维应用程序时，请考虑以下因素：
-
信息在公司内部如何流动 - 谁将哪些数据用于什么目的
-
公司的报告类型 - 必须在大纲中包含哪些类型的数据，以满足用户报告需求
注意：
每个应用仅定义一个数据库可以提高内存使用率并简化数据库管理。
分析源数据
评估要包括在 Essbase 数据库中的数据。考虑它的来源，以及所需的更新频率和大小。您应仅加载到 Essbase 中，这是透视报表和穿透钻取所需的内容。其余部分可以保留在关系源中，可通过分区访问或穿透钻取。
确定数据库的范围。如果组织有多个产品系列，其中包含大量产品，则您可能希望仅存储产品系列的数据值。面试每个用户部门的成员，了解他们处理的数据、他们今天如何计算和报告数据，以及他们将来如何处理数据。
仔细定义报告和分析需求。
-
用户希望如何查看和分析数据？
-
数据库应包含多少详细信息？
-
数据是否支持所需的分析和报告目标？
-
如果没有，您还需要哪些其他数据，可以在哪里找到？
确定当前数据的位置。
-
每个部门当前将数据存储在何处？
-
Essbase 是否可以使用表单中的数据？
-
部门是将数据存储在 Windows 或 UNIX 服务器上的关系数据库中，还是存储在 Excel 电子表格中？
-
谁更新数据库以及更新频率？
-
那些需要更新数据的人是否有权访问它？
确保数据已准备好加载到 Essbase 中。
-
数据是来自单个源还是多个源？
-
数据是否采用 Essbase 可以使用的格式？有关可以加载到 Essbase 中的有效数据源的列表，请参阅数据源。
-
您希望使用的所有数据是否都可用？
确定用户要求
在规划 Essbase 数据库时，请与数据的当前用户讨论信息需求，然后向他们请求示例报表。检查他们使用的信息以及他们必须生成的报告以供其他人检查。
确定以下要求：
-
用户需要哪些类型的分析？
-
用户是否需要即席（数据透视式）报告和结构化报告？
-
用户需要什么汇总和详细信息级别的信息？
-
某些用户是否需要访问其他用户不应看到的信息？
创建数据库模型
创建 Essbase 数据库的模型。要构建模型，您需要确定对您的业务非常重要的观点和观点。这些视图转换为数据库模型的维。
许多企业分析以下视图：
-
时间期
-
度量
-
场景
-
Products
-
客户
-
地理地区
-
业务单位
接下来，要帮助您收集信息并做出决策，您需要确定数据分析目标，确定数据库维和成员，并分析数据库设计。
确定分析目标
确定业务中的主要信息视图后，设计 Essbase 数据库的下一步是决定数据库如何启用数据分析。例如，您可能需要按时间段、地理位置或产品类型查看数据。
-
如果按时间分析，则需要哪些时间期？分析应该仅包括当前年份还是多个年份？该分析是否应包括季度和月度数据？是否应按季节包括数据？
-
如果按地理区域进行分析，如何定义区域？是否按销售地区定义区域？是否按地理边界定义区域，例如州/省和城市？
-
如果按产品线进行分析，您是否应查看每个产品的数据？您能否将数据汇总到产品分类中？
无论业务视图如何，都必须确定分析所需的视角和详细信息。您分析的每个业务区域都提供了不同的数据视图。
确定维和成员
您选择的 Essbase 维确定可以执行的分析类型。在每个维中，成员的层次结构代表业务的各个方面。例如，时间层次结构可以包括季度和月。产品层次结构对产品进行分类。区域层次结构基于地理市场。
可以将每个业务视图表示为数据库中的单独标准维。您可能会听到业务分析师提到其业务的“问题”，例如按产品、地理位置和时间段。如果需要按分类或属性（例如按产品的大小或颜色）分析业务视图，则可以使用属性维度或属性来表示分类视图。
您可以根据需要使用任意数量的维进行分析。当您大致了解所需的维和成员时，请开发一个暂定的数据库设计。
确定数据库模型的维之后，选择每个维中的元素或项。这些元素将成为其各自维度的层次结构和成员。例如，时间层次结构可能包括要分析的时间期间，例如季度，以及季度和月份。每个季度和月份将成为您为时间创建的维的成员。季度和月份表示成员及其子项的两级层次结构。一个季度内的月份可以合并为每个季度的总和。
维之间的关系
考虑维之间的关系。通过 Essbase 数据库的结构，用户可以轻松地从多个角度分析信息。例如，财务分析师可能会提出以下问题：
-
特定月份的销售额是多少？此数字与过去五年的同月销售额相比如何？
-
利润率增长百分比是多少？
-
实际值与预算值的距离有多近？
换句话说，分析师可能需要从三个维度（时间、客户和场景）中检查信息。下面的示例数据库表示这三个维，三个轴中的每个轴都有一个维：
-
时间维由“Jan（一月）”、“Feb（二月）”、“Mar（三月）”和“Qtr1（季度）”的总计组成，沿 X 轴显示。
-
由“销售”、“销货成本”、“毛利”和“毛利”等会计数字组成的账户维沿 Y 轴显示。
-
另一个维提供了不同的视点，如预算值的预算和实际值的实际值，显示在 Z 轴上。
图 1-1 代表三个数据库维的立方
多维数据集中的单元格，其中成员相交，包含与所有三个相交的成员相关的数据；例如，一月份的实际销售额。
维 - 成员结构示例
下表显示了 TBC 维的汇总。应用程序设计器创建了三列，其中维位于左侧列，成员位于两个右侧列。第 3 列中的成员是第 2 列中成员的子类别。在某些情况下，第 3 列中的成员被分成另一个子类别级别；例如，“度量”维的“利润”被分成“销售”和“销货成本”。
表 1-1 TBC 样品维
| 尺寸 | 成员 | 子成员 |
|---|---|---|
|
Year |
Qtr1 |
1 月、2 月、3 月 |
|
Year |
Qtr2 |
4 月、5 月、6 月 |
|
Year |
Qtr3 |
七月、八月、九月 |
|
Year |
Qtr4 |
“Oct（十月）”、“Nov（十月）”、“Dec（十二月）” |
|
度量 |
Profit |
利润：销售、销货成本 总费用：市场营销、工资单、杂项 |
|
度量 |
产品清单 |
期初库存、增加、期末库存 |
|
度量 |
比率 |
利润百分比、利润百分比、每盎司利润 |
|
Product |
科拉斯 (100) |
可乐 (100-10)，健怡可乐 (100-20)，无咖啡因可乐 (100-30) |
|
Product |
根啤酒 (200) |
老式（200 ‑ 10）、饮食根啤酒（200 ‑ 20）、Sarsaparilla（200 ‑ 30）、桦木啤酒（200 ‑ 40） |
|
Product |
奶油苏打 (300) |
深奶油 (300-10)，香草奶油 (300-20)，减肥奶油苏打 (300-30) |
|
Product |
水果苏打水 (400) |
葡萄 (400-10)，橙色 (400-20)，草莓 (400-30) |
|
Market |
East |
康涅狄格州，佛罗里达州，马萨诸塞州，新罕布什尔州，纽约 |
|
Market |
西部 |
加利福尼亚州，内华达州，俄勒冈州，犹他州，华盛顿州 |
|
Market |
南方 |
路易斯安那州，新墨西哥州，俄克拉荷马州，德克萨斯州 |
|
Market |
中央 |
科罗拉多州，伊利诺伊州，爱荷华州，密苏里州，俄亥俄州，威斯康星州 |
|
Scenario |
实际 |
不适用 |
|
Scenario |
预算 |
不适用 |
|
Scenario |
差异 |
不适用 |
|
Scenario |
差异百分比 |
不适用 |
此外，应用程序设计器还添加了以下属性维，以根据大小和打包启用产品分析：
表 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 30Cust A 仅在纽约，Cust B 仅在伊利诺伊州，Cust C 仅在加利福尼亚。公司可以定义一个标准维中的数据：
Market
New York
Cust A
Illinois
Cust B
California
Cust C但是，如果您查看较大的数据采样，可能会发现每个市场中都有许多客户。客户 A 和客户 E 在纽约；客户 B、客户 M 和客户 P 在伊利诺伊州；客户 C 和客户 F 在加利福尼亚州。在这种情况下，公司通常将大维（客户）定义为标准维，将小维（市场）定义为属性维。公司将“市场”维的成员关联为“客户”维的成员的属性。“市场”维的成员描述了客户的位置—每个客户只有一个市场。
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 30Cust A 在纽约和加利福尼亚。Cust B 在纽约和伊利诺伊州。客户 C 仅在加利福尼亚州。在这种情况下，使用属性维不起作用；客户成员不能有多个属性成员。因此，公司以两个标准维度设计数据：
Customer
Cust A
Cust B
Cust C
Market
New York
Illinois
California维组合
将两个维的每种组合划分为二维矩阵。例如，TBC 中的拟议维度包括以下组合：
-
跨度量的年度
-
跨产品的年度
-
跨市场的年度
-
跨方案的年度
-
跨产品的度量
-
跨市场的衡量标准
-
跨方案的度量
-
跨产品的市场
-
跨方案的市场
-
跨产品的方案
-
跨包类型的盎司
“盎司”和“包装类型”作为与“产品”维关联的属性维，可以与“产品”维一起考虑。
为了帮助可视化每个维度，绘制一个矩阵，并包含一些第一代成员。下图显示了三维的简化矩阵集。
图 1-2 分析维关系
对于每个维组合，请提出三个问题：
-
是否增加了分析值？
-
它是否为报告添加了实用程序？
-
是否可以避免过度使用未使用的组合？
对于每个组合，问题的答案有助于确定该组合对于数据库是否有效。理想情况下，每个问题的答案都是“是”。如果没有，请考虑将数据重新排列为更有意义的维度。在处理此过程时，与用户讨论信息需求。
大纲中的重复
大纲中元素的重复通常表示需要拆分维。以下示例说明如何避免重复。
在此示例中，标记为“重复”的左列显示“帐户”维中的“预算”和“实际”下重复的“利润”、“利润”、“销售”、“销货成本”和“费用”。右列标记为“无重复”，将“预算”和“实际”分隔到另一个维（方案），只剩下“帐户”维中的一组“利润”、“利润”、“销售”、“销货成本”和“费用”成员。此方法简化了大纲，并简化了数据库中其他维度的预算和实际数字的视图。
图 1-3 通过创建方案维来消除重复的示例
在此示例中，标记为“重复”的左列使用“饮食”维度中的共享成员来分析饮食饮料。成员 100-20,200-20 和 300-20 重复：一次在饮食下，一次在各自的父母下。右列标记为“无重复”，通过创建类型为布尔值的 Diet 属性维（True 或 False）来简化大纲。所有成员仅在其各自的父代下显示一次，并标记有相应属性（“Diet：True”或“Diet：False”）。
图 1-4 通过创建属性维来消除重复的示例
属性维还提供了其他分析功能。请参阅 Essbase 属性的优点。
间维不相关性
当维的许多成员在其他维之间不相关时，会发生维间不相关。Essbase 将不相关的数据定义为 Essbase 仅在汇总（维）级别存储的数据。在这种情况下，您可以从数据库中删除维并将其成员添加到其他维，或将模型拆分为单独的数据库。
例如，TBC 考虑将工资分析作为“度量”维的成员。但是，在公司数据库的背景下，工资信息往往不相关。大多数工资是保密的，适用于个人。个人和薪金通常代表一个单元格，没有理由与任何其他维相交。
TBC 考虑将员工分成一个单独的维度。下表显示了一个示例，说明 TBC 如何分析建议的“员工”维度以实现跨维无关。建议的员工维的成员（在表标题行中表示）与度量维的成员（在最左边的列中表示）进行比较。“度量”维成员（如收入）适用于所有员工；只有“薪金”度量与单个员工相关。
表 1-3：维间不相关性的示例
 |
Joe Smith | Mary Jones | Mike Garcia | 所有员工 |
|---|---|---|---|---|
|
收入 |
不相关 |
不相关 |
不相关 |
相关性 |
|
可变成本 |
不相关 |
不相关 |
不相关 |
相关性 |
|
COGS |
不相关 |
不相关 |
不相关 |
相关性 |
|
通告 |
不相关 |
不相关 |
不相关 |
相关性 |
|
薪金 |
相关性 |
相关性 |
相关性 |
相关性 |
|
固定成本 |
不相关 |
不相关 |
不相关 |
相关性 |
|
费用 |
不相关 |
不相关 |
不相关 |
相关性 |
|
Profit |
不相关 |
不相关 |
不相关 |
相关性 |
拆分数据库的原因
由于单个员工信息与数据库中的其他信息无关，而且由于添加“员工”维度会大幅增加数据库存储需求，因此 TBC 创建了一个单独的人力资源 (HR) 数据库。新的 HR 数据库包含一组相关维度，包括薪金、福利、保险和 401(k) 计划。
拆分数据库的原因有很多；例如，假设一家公司维护的组织数据库，该数据库包含多个时区的多个国际子公司。每个子公司都依赖于时间敏感的财务计算。您可以拆分同一时区的子公司组的数据库，以确保财务计算及时。您还可以使用分区的应用程序按子公司分隔信息。
用于分析数据库设计的核对清单
使用以下核对清单分析数据库设计：
-
是否已最小化维数？
-
对于每个维组合，您是否询问：
-
是否增加了分析值？
-
它是否为报告添加了实用程序？
-
是否可以避免过度使用未使用的组合？
-
-
是否避免在大纲中重复？
-
是否避免了跨维无关性？
-
是否根据需要拆分数据库？