IBM Cognos 最佳实践: PowerPlay Transformer 模型检查清单

文档性质:指南;产品:PowerPlay Transformer;关注领域:建模

准备和检查 Transformer 模型前期处理的检查指南。

Marc Reed, 首席顾问, IBM

Marc Reed 是 UK Cognos BI 团队的首席顾问。他从事 Cognos BI 软件开发工作已经 10 多年时间了。在这段时间里,他曾经为许多客户(各个行业)的众多项目提供帮助,范围涉及故障排除到大型企业应用部署。这么多年来,Marc 开发过许多最佳实践方法,并且将它们共享给了许多 BI 开发者和咨询师。



2011 年 7 月 22 日

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本指南给出一个关于有效检查 Transformer 模型的检查清单。这个检查清单是一个推荐的可靠实践。通过将模型与本检查清单的项目进行比较,您将能够证明您获得了一个符合许多可靠实践的良好 Transformer 模型。

这些规则并非一成不变的。用户完全有理由可以不使用这些规则。但是任何对此规则的不使用都应该记录下来,这样使用您模型的人才能够理解为什么您不采用标准的可靠实践。

本指南不会从业务角度下结论说明一个 Transformer 模型看是好还是坏,也不会给出一个结论说得到的 Powercube 是高效的。进行这样的判断需要一定的业务知识。在进行性能优化时,了解业务目标和设计一个更有利于实现目标的方法通常会带来更大的性能提升。

适用性

本指南适用于所有版本的 IBM Cognos PowerPlay Transformer。


Transformer 模型的一般检查

这些检查是与整个 Transformer 模型相关的。

  1. 使用 Tools > Check Model 菜单项,可以很容易确定错误或警告。
    这个工具经常被忽视,但是它能够很好地总结 Transformer 模型中发现的问题,并且您能够很容易确定这些错误或警告是否可以接受。
  2. 模型文件采用的是 MDL 格式
    PY 格式应该只有在模型加载时间占用了大部分分析构建时间的时候才使用。
    • MDL 格式的模型能够保证该模型不会过于臃肿或者随分类逐渐删除而变得零碎。
    • MDL 格式可以保证向前兼容性,保证模型应该能够加载到新版本的 Transformer。
    • 注意:对于需要密码的数据源,MDL 不负责存储。

数据源

这一节介绍 Transformer 中使用的数据源的处理。

图 1. Data Sources 窗口
Data Sources 窗口

一般数据源检查

  1. 验证查询按维度和事实查询划分。
    其中例外的是当维度来自事实查询时。对于这种情况,对这个事实表进行两次读取是很不明智的做法 —— 一次是获取维度,另一次是获取实际数据。然而,如果获取单独的维度清单的查询开销较低,那么就可以进行两次查询。
  2. 验证是否使用可以简单确定事实和维度查询的命名规则。
  3. 验证维度查询是否位于所有事实查询之前。
    在 Cognos 8 Transformer 中,帮助文档说明这是不必要的,无论 Transformer 使用哪一种方式来决定什么是没有记录的维度与事实。这个可靠实践方法仍然需要遵循。

各个数据源检查

  1. 使用 “Show Scope” 工具。
    您可以在所有数据源上使用这个工具来保证查询只会影响到预期的维度。这个工具可以通过右键单击数据源后选择 “Show Scope” 而打开。
  2. 保证没有使用未引用的字段。
    如果字段没有被模型使用,那么我们就不应该将该数据传递给 Transformer。右键单击这个数据源,然后选择 “Show Reference” 工具进行验证。
    图 2. Column References 对话窗口
    Column References 对话窗口
    如果数据源不是一个 Framework Manager 或 Cognos 8 报表,那么就要从底层的数据源本身删除不使用的字段,而不只是从 Transformer 查询删除。例如,如果使用一个 IQD,而它所包含的 10 个字段中只有 2 个被 Transformer 使用,那么要编辑这个 IQD,删除其中 8 个未使用的字段。
  3. 检查 Timing 属性。
    针对只使用 Generate Categories 或/和 PowerCube creation Generate Categories 的维度查询。
    图 3. Datasources Properties Timing 属性
    Datasources Properties Timing 属性
    对于 Fact 查询,它们是不需要维度的,所以要将这些属性设置为 Create the PowerCubes
  4. 如果您使用一个数据仓库,其中的代理键保证都是唯一的,那么要考虑设置为 Maximise data access speed
    图 4. Datasource Uniqueness verification 属性
    Datasource Uniqueness verification 属性
  5. Set the current period 属性只设置到对应的查询上。
    考虑使用一个只用来设置当前周期的查询。
  6. Auto Summarize 属性是选中/未选中的。
    这个设置取决于所读取的源数据。如果源数据与底层表作为相同粒度级别使用,那么这个选项应该是不选中的。如果源数据不全面,那么这个选项应该选中。要考虑这个设置对数据源所生成的 SQL 的影响。
    — 增加汇总函数。
    • 保证查询具有正确的标识符,而且这个设置的事实使用属性是有效的。这些需要在来源中设置 — Framework Manager 或报表。同样要检查 SQL 以保证分组正确并且应用了汇总函数。
  7. 事实数据是全面的。
    如果自动汇总选项不可用,那么要保证事实查询是全面的。即它在一个唯一键组合上只会产生一行数据。
    例如,如果使用了 IQD,那么您必须编辑这个 IQD,加入正确的分组和汇总函数。
  8. 比较原生 SQL 和 Cognos SQL。
    保证 Cognos SQL 被转换成有效的原生 SQL。例如,尽可能使用原生 SQL 函数。

维度

这一节将介绍 Transformer 中使用的维度。

  1. 分类码是唯一的。
    使用 Find Category 选项搜索包含 “~” 字符的分类码。保证这个测试在对所生成的模型执行。
    图 5. Find Category 对话窗口
    Find Category 对话窗口
    唯一可接受的分类码是空白码,其中空格会被抑制。使用不确定的分类码可能会影响 MUN 及与这相关的报表。
  2. 计算得到的分类/特殊分类不使用本身就使用代理键/不确定键作为分类码的那些分类。
    这里并不保证所有键在开发、测试和生产系统中都是相同的。如果这些键/代码会在各种环境中发生变化,或者会随时间变化,那么计算得到的分类和特殊分类都会失效。
  3. 具有替代操作路径的维度会被排除在自动分区之外。
    主操作路径的分区可能会影响其他层次的性能。
  4. 扁平维度也会被排除在自动分区之外,因为它们不能用于分区。
  5. 级别为 1:1 的维度。
    如果一个分类总是属于一个且只属于一个分类,那么这两个层次就应该合并。快速确认这一点的方法是生成这个模型,然后检查该层次维度的分类计数。
    当使用数据仓库作为源,为最低一级的维度创建一个层次,并为代理键级创建了另一个层次,那么这种情况就很常见。
    我们可以为事实数据加上该维度的键,或是合并这两个层次,两种方法都会将代理键变成源,同时相应的域变成名称,等等。了解它可能对前面操作造成的影响。
  6. 最低一级的维度是未使用的。
    如果最低一级的维度被抑制了,那么它是否真正必要呢?这是最后一个问题。
    如果它必须出现在模型中,但又被抑制了,那么要考虑在该级别上使用汇总函数。这将减小分析的规模。
  7. 场景维度具有一个默认的分类集。
    图 6. Dimension Properties 对话窗口
    Dimension Properties 对话窗口
  8. 替代的层次根分类指定了有意义的分类标签和代码。
    图 7. Category 视图
    Category 视图
  9. 具有相同或相似分类的维度可以按用户区分。假设有一个具有 Ordered Date 和 Shipped Date 维度的销售分析。这两个维度包含了相同的年份、月份和日期。如果用户将其中一个维度放到报表中,它们如何知道该使用哪一个月份?
  10. 所有维度级别都必须指定有意义的名称。在最新的报表工具上,用户将能够看见这些级别名称。
  11. 如果一个级别中的所有分类都应用了相同的分类操作。如果一个级别中的所有分类都应用了一个分类操作(例如,排除),那么要考虑将这个操作应用到维度级别上,而不是某个分类上。如果大多数分类都应用了这个操作,那么同样要考虑将它应用到维度级别上,然后在其他分类上解除这个操作。这个语句也可以应用到自定义视图上。
  12. 分类唯一性只适用于某些特定的级别 — 而不是所有级别。
  13. 刷新操作只有在使用已生成的模型时才有效。如果构建过程会生成模型的所有分类,那么通常不需要刷新标签等内容。

测量方法

这一节将介绍 Transformer 中使用的测量方法。

  1. 设置一个正确的测量存储类型。如果您在开发时使用了全部数据的一小部分,那么需要小心使用 32 位测量 — 有时这适合用在开发过程中,但是数据总容量可能会超出这个数据类型的最大限制。
    64 位测量则需要更多的存储空间,所以会产生更大的 powercube 文件。您必须在确定数据需要使用 64 位测量才使用它。当使用 64 位测量时,一定要设置正确的比例和精度值。
    这能够保证模型能够处理大量的数据。一定要设置正确的比例和精度值。
  2. 设置正确的缺失值。考虑到 “NA” 只能影响到使用了这种测量方法的计算测量。使用旧版本 Transformer 的客户可能更愿意将它设置为 0,而不是新默认值 NA。
  3. 设置非附加测量的时间状态累加。例如,Closing Balance 或 Stock Level 测量方法可能更适合使用 Current Period for actuals 进行累加,而不是 Last Period for budgets。
  4. 设置格式。
  5. 考虑使用一个内部模型名称作为测量名称和用户友好的 Measure Label 和 Short Name。这可以为模型和报表实现更好的可维护性,这个测量名称将来需要修改。
  6. 显示 Scope。在所有测量上使用 “Show Scope” 工具来确认范围是正确的。

PowerCubes

这一节将介绍 Transformer 中使用的 PowerCubes。

  1. PowerCube Partition 状态。
    确认汇总分区大小是小于预期分区大小,保证分区能够成功。
  2. Auto Partition。
    在现代服务器架构中,预期分区大小为 2.5m 是一个很好的起点设置。保证 Estimated number of records 能够反映 PowerCube 最终构建的环境。要增加 Maximum number of passes 值以创建更小的分区,这样构建才不会超过预期的分区大小限制。
  3. 从 PowerCube 文件名移除文件路径,并使用偏好选项设置在正确的位置进行构建。
  4. 启用 Crosstab Caching on the cube Processing 选项。

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=677716
ArticleTitle=IBM Cognos 最佳实践: PowerPlay Transformer 模型检查清单
publish-date=07222011