草拟 Essbase 大纲

草拟 Essbase 数据库模型后，可以创建应用程序和数据库，并构建大纲的初稿。草稿定义了所有维、成员和合并。使用大纲设计合并要求，并确定需要公式和计算脚本的位置。

大纲是 Essbase 数据库（或多维数据集）的一部分，该数据库存在于 Essbase 应用程序中。

为了使用之前介绍的 Beverage Company 示例，TBC 应用程序设计者针对数据库大纲发布了以下草稿。在此计划中，“年”、“度量”、“产品”、“市场”、“方案”、“包类型”和“盎司”是维名称。观察 TBC 如何预测合并、计算和公式以及报告要求。应用程序设计者还使用产品代码而不是产品名称来描述产品。

  • 年份。 TBC 需要每月收集数据，并按季度和年度汇总每月数据。存储在 1 月、2 月和 3 月等成员中的每月数据合并到季度。季度数据存储在 Qtr1 和 Qtr2 等成员中，合并到 Year。

  • 度量。 “销售”、“销货成本”、“市场营销”、“薪资”、“杂项”、“期初库存”、“增加”和“期末库存”是标准度量。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 按大小和包装进行分析，因为每个产品都与“盎司”和“套餐类型”属性维的成员关联。

  • Market。 几个州组成了一个区域；四个地区组成了一个市场。这些州包括康涅狄格州、佛罗里达州、马萨诸塞州、新罕布什尔州、纽约州、加利福尼亚州、内华达州、俄勒冈州、犹他州、华盛顿州、路易斯安那州、新墨西哥州、俄克拉荷马州、德克萨斯州、科罗拉多州、伊利诺伊州、爱荷华州、密苏里州、俄亥俄州和威斯康星州。每个州都整合到其区域 - 东部，西部，南部或中部。每个区域都整合到市场中。

  • 场景。 TBC 推导和跟踪预算与实际数据。经理必须监控和跟踪预算和实际值，以及它们之间的差异和差异百分比。

  • 包装类型。 TBC 希望看到产品包装对销售和利润的影响。通过建立“套餐类型”属性维，用户可以根据产品是包装在瓶中还是包装在罐中来分析产品信息。

  • 盎司。 TBC 在不同的市场销售不同尺寸的盎司产品。建立 Ounces 属性维可帮助用户监视哪些尺寸在哪些市场中卖得更好。

下面的主题将介绍维和成员属性的基本知识，并讨论大纲设计如何影响性能。

维类型

维类型是 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 内置会计功能可用。只有一个维可以定义为“帐户”。

属性

包含可用于描述另一个称为基本维的成员的成员的成员。

例如，“包类型”属性维包含适用于“产品”维成员的每种包装类型的成员，例如瓶或罐。

国家（地区）（仅用于货币转换功能）

包含有关业务活动发生位置的数据。在国家（地区）维中，可以指定每个成员中使用的货币。

例如，加拿大有三个市场 - 温哥华，多伦多和蒙特利尔，它们使用相同的货币，加元。

Member Storage Properties

指定成员的数据存储属性，以定义合并的存储位置和时间。默认情况下，成员标记为已存储： Essbase 对其值求和，并将结果存储在父级别。可以通过更改数据存储属性标记来更改每个成员的默认逻辑。

下表介绍了 Essbase 数据存储属性对成员的影响。

表 1-5 Essbase 数据存储属性

数据存储特性 对成员的影响

存储数据

该成员的数据将存储在数据库中。存储数据是默认存储属性。Essbase 对值求和并将结果存储在父级别。

动态计算

与成员关联的数据在用户查询请求时计算。计算的数据不会被存储；它将在查询请求完成后被丢弃。

共享成员

与成员关联的数据来自具有相同名称的另一个成员。

从不共享

如果存在隐含的共享关系，则与父代及其子代关联的数据将重复。数据以大纲顺序与首次出现的成员一起存储。

仅标签

对于没有关联数据的成员，可以将存储的成员更改为仅标签。虽然标签仅成员没有数据，但它可以显示值。标签仅对成员进行标记，并简化导航和报告。通常，不计算仅标签成员。

例如，在“度量”维中，成员比率有三个子项：“毛利”、“利润”和“每盎司利润”。成员比率定义成员类别。合并时，利润率、利润率和每盎司利润率不会累计到一个有意义的比率数字。因此，比率仅标记为标签。

维和成员属性的核对清单

  • 是否可以标识时间维？

  • 是否可以标识帐户维？

  • 数据是否包括外币？如果是，您是否确定了货币分区维？

  • 是否可以确定应定义为单独属性维的维的特性或特性？

  • 哪些成员需要特殊的数据存储属性？

设计大纲以优化性能

在 Essbase 大纲末尾放置属性维、在稀疏之前放置密集维以及先对成员最少的稀疏维排序。维在大纲中的位置以及维的存储属性会影响到运行速度以及检索数据所花费的时间。

优化查询性能

要优化查询性能，请在设计大纲时使用以下准则：

  • 如果大纲包含属性维，请确保属性维是大纲中唯一的稀疏动态计算维。

  • 在大纲中，将较为查询的稀疏维放在较少查询的稀疏维之前。

下图所示的大纲旨在实现最佳的查询性能：

  • 由于大纲包含属性维，因此将标准维和所有标准维成员的存储属性设置为存储数据。

  • 作为最查询的稀疏维，产品维是稀疏维中的第一个。基本维通常比其他维查询更多。

图 1-5 设计优化查询时间的大纲


此图说明了为实现最佳查询性能而设计的大纲，如图像前面的文本中所述。

优化计算性能

要优化计算性能，请从包含最少的维开始，按大纲中稀疏维的成员数对维进行排序。

下图所示的大纲旨在实现最佳的计算性能：

  • 最小的标准维度是稀疏的，市场，是大纲中稀疏维度的第一个。

  • 最大的标准维（稀疏的 Product）紧邻第一个属性维。如果大纲不包含属性维，则产品维将位于大纲的末尾。

图 1-6 设计优化计算时间的大纲


此图说明了为实现最佳计算性能而设计的大纲，如图像前面的文本中所述。

满足计算和检索的需求

虽然它们包含相同的维度，但之前显示的示例大纲不同。要确定情况的最佳大纲序列，请根据在数据库上运行计算所需的时间确定用户的数据检索需求的优先级。您希望多久更新和重新计算一次数据库？用户查询的性质是什么？预期的用户查询量是多少？

可能的解决方法是将维最初放置在大纲中以优化计算。运行计算后，可以手动对维重新排序以优化检索。重新定位大纲维后保存大纲时，选择仅按索引重新构建数据库。在再次运行计算之前，请对大纲中的维重新排序以优化计算。