IBM Cognos 最佳实践: IBM Cognos BI — 使用多个关系数据源

文档性质:指南;产品:Framework Manager、Report Studio、Business Insight Advanced;领域:建模、报告

探索处理 Cognos BI 中的不同数据源(特别是 Report Studio 和 Framework Manager)的不同方法,弄清每种方法的优缺点。本文还包括一些关于如何减小性能影响的技巧。

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

简介

方法

本教程提供关于在 Framework Manager 中使用多个关系数据源的指南,并就如何在各种场景中改进性能提供建议。

适用性

本文针对 IBM Cognos 8.4.1 和 IBM Cognos 10.1 撰写并测试。

例外

本文不涵盖使用多个 OLAP 源。

假设

本文假定读者已有 IBM Cognos BI 经验,特别是 IBM Cognos Report Studio 和 IBM Cognos Framework Manager 经验。


概述

许多组织都面临合并多个完全不同的数据源的信息以进行报告和分析的任务。尽管您可能想将所有数据都合并到单个关系数据库中以便进行报告,但这可能不太可行,或者资金不允许,或者需要较多时间实现且需要一个临时 BI 解决方案。

IBM Cognos BI 提供一些设施将这些不同的数据源结合起来以实现报告目的,但在启动 BI 项目之前有几个注意事项需要考虑。

本文将检查处理不同数据源的几种不同方法,确认每种方法的优缺点。本文还包括一些关于如何减小性能影响的技巧。


数据访问策略

在开始访问您公司的数据以实现报告目的之前,您可能需要考虑以下关于数据及其使用方式的问题。

  • 数据需要多新?您需要每年、每季度、每月、每周、每天、每小时、甚至每秒报告数据吗?了解这些信息将有助于决定如何访问或存储报告数据。需要使用专用数据栈或数据仓库吗?可以使用多维数据集吗?必须实时报告数据吗?
  • 数据用户主要查看汇总数据还是需要一种交互式体验(向下和向上钻取数据)?如果这样,可能应该考虑 OLAP 包或维度模式关系(Dimensionally Modeled Relational,DMR)包。参见下面的 DRM 说明了解更多信息。
  • 可用数据能支持您的业务问题吗?例如,整个公司缺乏统一的产品数据可能会阻碍跨公司各分支机构查询产品指标。各分支机构中的产品数据应该一致并以相同的方式表示。这样,来自所有分支机构的指标才能通过统一的产品数据进行比较。

这些问题只是您试图实施一个 BI 项目时可能会面对的挑战的一些示例。尽管前面提到了 OLAP,但本文只关注访问多个关系数据源。

说明:Dimensionally modeled relational (DMR) 建模是 IBM Cognos Framework Manager 提供的一个功能,允许指定关系元数据的维度信息。这个功能支持 OLAP 式查询。如果可能,使用 OLAP 技术通常能提供更好的性能,但如果使用的数据集比较小(项目可以少实现一种技术)或需要对实时数据进行 OLAP 式查询,DMR 可能更适合。


真的需要在数据库间创建联接吗?

使用不同的数据源时首先需要问的一个问题可能是:“真的需要将这些数据源联接起来吗?” 您只是需要在同一个仪表板或报告中显示数据,但没有一个物理联接吗?每个数据库都可以在仪表板或仪表板式报告中拥有自己的查询并并排显示,而不必实际联接数据。换句话说,即并置数据。例如,执行官可能想查看天气统计数据和户外产品销售之间的周关系。每个数据都包含在一个不同的数据库中。如果执行官只想查看某个指定销售日的天气情况并迅速查看天气暖和的日子销量上升的可视趋势,则可能不需要这两个数据库之间的联接。每个查询都可以表示为一个列表或图形并在一个仪表板或仪表板式报告中并排显示。

在这些场景类型中,由于服务器上的数据的本地联接处理导致的性能问题被避免了。


联接或主/明细关系更好吗?

可能有一些情况您只需为某些报告关联来自不同数据源的数据。例如,一家公司的每个地区可能在一个数据库中管理自己的帐户信息,而交易性销售数据存储在一个中央系统中。每个地区都可能想使用它们的帐户数据来过滤销售记录。

IBM Cognos BI 支持在 Framework Manager 或 Report Studio 中关联不同的数据库。在我们的示例中,我们将在一个数据库中的地区性 Account 表和另一个数据库中的 Sales 表之间创建一个关系。但是,这样做的结果是在 IBM Cognos BI 服务器上生成本地数据处理。每个数据库都将被查询并可能生成大量数据,然后以本地方式联接以过滤不想要的记录。要查看性能是否还可以接受,您可能想对预期查询应用一些基本数学函数,当然,还要在您的环境中测试那些查询。表 X 中您想请求并联接到表 Y 中的某个数据量的数据有多大量?对于较小的数据或报告只是偶尔运行(在非高峰时段也许为每周一次)的情况,创建跨数据库联接可能是完全可以接受的简单解决方案。

但是,对于较大的数据源,报告输出可能需要更长的等待时间,因此不是最优解决方案。考虑另外一个例子:Sales 表有几百万条记录,但每个地区只对几十万条记录感兴趣,额外的处理可能不会产生可以接受的等待时间。在这种情况下,Report Studio 报告作者可以使用主/明细关系作为一种替代方法。主/明细关系将首先检索主数据,在本例中是从 Account 表检索,然后为每个帐户检索相关 Sales 记录。这种技术将生成更多针对细节表数据库的查询,但每个查询都会被过滤。

通过实现主/明细关系,可以通过减少明细端上的数据库返回的记录量来提高性能。但是,与任何技术一样,这种技术也有一些限制。如果主查询表拥有大量数据,比如数百万行,那么向明细端上的数据库表发出的查询量可能难以接受。


使用一个数据库供应商的单个实例

理解关系数据库供应商技术之间的区别

处理关系数据库和 IBM Cognos BI 时,您可能会遇到以下情况:您正在联接来自同一个数据库供应商实例的多个项,但通过 IBM Cognos Connection 中定义的多个不同 IBM Cognos BI 数据源连接。在这种情况下,BI 服务器将以本地方式联接来自各个已定义 BI 数据源连接的数据。这种行为可能理想,也可能不理想。如果不理想,您可以配置 Framework Manager,将处理工作推到数据库供应商。

下面将解释不同的数据库供应商技术是如何表现的,元数据在导入过程中如何出现,以及如何配置您的模型以便在必要时将处理工作推到数据库。

关于数据库供应商如何处理他们的对象的资格问题,有几个不同的场景。例如,有些供应商只有实例概念和一个对象集合,比如表和引用。本文只关注两个最常见的场景,本文称其为 Scenario A 和 Scenario B。

Scenario A — 实例和架构

在 Scenario A 中,供应商拥有实例概念(计算机上运行的数据库软件)和架构概念(有些供应商也将架构称为 “用户”)。图 1 展示了一个名为 A 的单一实例,它包含 4 个架构,分别命名为 A、B、C 和 D。这种场景的一个供应商示例是 Oracle。

图 1. Scenario A — 示例和架构
图 1. Scenario A — 示例和架构

在这种情况下,您在 IBM Cognos BI 中为数据库供应商实例创建一个 IBM Cognos BI 数据源,并拥有对其中的所有架构的访问权。图 2 展示了 Framework Manager Metadata Wizard 导入流程的 Select Objects 屏幕,其中,实例名称(Oracle)位于元数据树顶端,各个架构(比如 CM、GOSALES 等)是实例的直接子实例。

图 2. 显示实例和架构的 Oracle 示例的 Framework Manager Metadata Wizard
图 2. 显示实例和架构的 Oracle 示例的 Framework Manager Metadata Wizard

您可以根据需要从多个架构导入项目并从多个不同的架构导入联接表。在这个场景中,如果数据库供应商支持查询,那么 IBM Cognos BI 会将跨架构联接处理工作推到数据库供应商。

Scenario B — 实例、目录和架构

在 Scenario B 中,供应商拥有以下概念:实例(同样是计算机上运行的数据库软件)、目录(有些供应商也称为 “数据库”)和架构(同样被一些供应商称为 “用户”)。图 3 展示了一个名为 A 的实例和两个分别名为 A 和 B 的目录。目录 A 包含两个架构,分别名为 A 和 B。目录 B 也包含两个架构,分别名为 C 和 D。这个场景的一个供应商示例是 Microsoft SQL Server。

图 3. Scenario B — 实例、目录和架构
图 3. Scenario B — 实例、目录和架构

在这个场景中,必须在 IBM Cognos BI 中为想导入的每个目录创建一个 IBM Cognos BI 数据源。图 4 显示了 Framework Manager Metadata Wizard 导入向导的 Select Objects 屏幕,其中实例名称(GOSALES)位于元数据树顶端,下面是各个架构,比如 gosales、gosaleshr 等。

图 4. 显示实例、目录和架构的 Microsoft SQL Server 示例的 Framework Manager Metadata Wizard
图 4. 显示实例、目录和架构的 Microsoft SQL Server 示例的 Framework Manager Metadata Wizard

在 Scenario B 中,如果您想从其他目录导入其他元数据,则需要用到每个目录的另一个 IBM Cognos 数据源连接。从各个目录导入项目之后,您可以从一个目录到另一个目录联接项目。例如,图 5 显示了一个来自 C8-Bursting 目录(数据库)的表,该表联接到来自相同 SQL Server 实例的 GOSALESDW 目录(数据库)的另一个表。

图 5. 展示来自同一个实例的两个 SQL Server 数据库之间的联接的 Framework Manager 图表
图 5. 展示来自同一个实例的两个 SQL Server 数据库之间的联接的 Framework Manager 图表

但是,当您从每个目录查询来自已联接查询主题的项目时,IBM Cognos BI 将每个目录视为不同的数据源,因为没有足够的信息表明它们是相同的实例。事实上,即使您针对同一个实例和目录在 IBM Cognos BI 中创建两个数据源,IBM Cognos BI 仍然会将它们视为不同的实例。无论如何,这将阻止 IBM Cognos BI 将目录之间的联接推到数据库供应商。这一点可以通过查看这样一个查询的原生 SQL 看出。

例如,图 6 显示了一个从 Burst_Table 查询 Recipients 并从 SLS_SALES_TARGET_FACT 查询 SALES_TARGET 的查询生成的 SQL。图 6 中的 Cognos SQL 显示了表间的一个联接,但原生 SQL 没有这样的联接,它显示两个独立选择语句(如下突出显示部分所示)。这表明两个独立结果集将被检索并在 IBM Cognos BI 服务器上本地联接。

图 6. 显示带有两个独立选择语句的 Native SQL 的 Framework Manager 测试结果集
图 6. 显示带有两个独立选择语句的 Native SQL 的 Framework Manager 测试结果集

如果理想的方法是将联接推到数据库实例,则只需更改 Framework Manager 模型中的 Data Source 属性,将它们都指向一个 IBM Cognos BI 数据源连接。

本例涉及两个数据源,每个都有不同的属性设置,如图 7 和图 8 所示。great_outdoors_warehouse 数据源的 Content Manager Data Source 属性指向 great_outdoors_warehouse,而 C8-Bursting 数据源的相同属性则指向 C8-Bursting。

图 7. great_outdoors_warehouse 数据源的 Framework Manager - Data Source Properties 窗格
图 7. great_outdoors_warehouse 数据源的 Framework Manager - Data Source Properties 窗格
图 8. C8-Bursting 数据源的 Framework Manager - Data Source Properties 窗格
图 8. C8-Bursting 数据源的 Framework Manager - Data Source Properties 窗格

要将两个目录之间的联接向下推到数据库供应商,只需将这两个 Content Manager Data Source 属性指向同一个 IBM Cognos BI 数据源名称。这告知 IBM Cognos BI 使用同一个数据源实例但使用该实例中的两个不同的目录。在本例中,C8-Bursting 数据源实例应将它的 Content Manager Data Source 属性改为指向 great_outdoors_warehouse,如图 9 所示。

图 9. Content Manager Data Source 名称更改为匹配 great_outdoors_warehouse 数据源名称的 Framework Manager - Data Source Properties 窗格
图 9. Content Manager Data Source 名称更改为匹配 great_outdoors_warehouse 数据源名称的 Framework Manager - Data Source Properties 窗格

现在,当同一个查询运行时,生成的原生 SQL 是单个选择语句,在语句在数据库层联接来自不同目录的两个表,如图 10 所示。

图 10. 显示 Content Manager Data Source 属性更改后带有单个选择语句的 Native SQL 的 Framework Manager 测试结果
图 10. 显示 Content Manager Data Source 属性更改后带有单个选择语句的 Native SQL 的 Framework Manager 测试结果

单个选择语句生成,联接被推到数据库。


使用多个数据库实例或供应商

如本文前面所述,可以在 IBM Cognos Framework Manager 中联接完全不同的数据库,但如果这样做,数据库之间的联接的本地处理工作将在 IBM Cognos BI 服务器上发生。如果这不是您想要的效果,那么您可以考虑使用联合技术。

多数主要数据库供应商都提供某种形式的联合技术,该技术支持将来自其他数据库的表整合到供应商环境中。这种整合包括创建与这些表的关系以及各种形式的优化,比如通过提示或数据缓存命名一个耦合。本文不会详细介绍特定于供应商的联合技术,您需要参阅它们的文档了解详情。本节的重点是指出存在联合技术,您可以利用这种技术来优化完全不同的数据源,以便在 IBM Cognos BI 中制作报告。

还有一些第三方数据库联合工具也可能会派上用场。例如,IBM 提供 IBM Cognos Virtual View Manager (VVM),可用于跨多个文件、数据库和已打包应用程序创建一个安全管理的统一视图。当您对自己的 VVM 模型感到满意后,它就可以充当 IBM Cognos BI 的一个 ODBC 数据源。而且,它提供提示和数据缓存等优化方法。另外,它还提供对流式 XML 的访问,拥有针对 Siebel、SAP 和 Salesforce.com 的额外数据服务。


何时考虑静态 ETL

有可能存在这样的场景:您的报告需要的大部分数据都存在于一个数据库,但几个关键表除外。与新建一个数据仓库来将所有数据都合并到一个数据库相比,更合理的方法也许是只是将数据从其他数据库或系统提取、转换并加载(ETL)到主数据库中。市面上有几个 ETL 工具。例如,IBM 就提供 IBM InfoSphere DataStage 和 IBM Cognos Data Manager 工具。

图 11 显示了一个一般示例,其中,Database 1 拥有两个联接表 Table 1 和 Table 2,Database 2 拥有 3 个联接表 Table 3、Table 4 和 Table 5。

图 11. 两个完全不同的数据源
图 11. 两个完全不同的数据源

想像一下,Database 2 拥有报告所需的大部分数据,但需要 Database 1 中的 Table 1 的数据。您可以将需要的数据从 Table 1 ETL 到 Database 2 中(如图 12 所示),根据需要联接新表,以确保所有联接处理都在 Database 2 中完成。

图 12. 将 Table 1 从第一个数据源 ETL 到第二个数据源中
图 12. 将 Table 1 从第一个数据源 ETL 到第二个数据源中

使用星型架构专用数据栈或数据仓库

到目前为止,我们已经检查了不同数据库报告的各种方法,但专用数据栈和数据仓库除外。这是因为,将企业数据合并到专用数据栈或数据仓库之内并不总是可行。但是,如果时间、费用和资源都不成问题,理想的方法是使用 ETL 工具构建适用专用数据栈或数据仓库的星型架构设计并尽可能汇总数据。当企业数据根据行业标准星型架构设计进行合并和结构化时,基于数据进行报告更容易实现,性能通常也更好。另一个好处是,一旦数据采用这种类型的结构,更容易将数据扩展到多维数据集以便进行 OLAP 查询,因为大部分维度设计(度量值和相关维度)已经完成。

本文不会详细介绍星型架构设计。我们的意图是对合并多个数据源以进行 BI 报告的可用方法提供指导。


使用 IBM Cognos 10 中的 External Data Feature

IBM Cognos 10 中有一个名为 External Data 的新特性,可用于 Report Studio 和新的 Business Insight Advanced Studio。这个新特性允许作者连接到一些个人数据源,比如 Excel 电子表格、空格或逗号分隔的文件、或遵守 IBM Cognos XML 架构的 XML 文件,并将它们链接到现有 IBM Cognos BI 包中的数据项。图 13 显示链接到一个名为 GO Sales (query) 的现有表的 Retailers 查询主题中的一个查询项的外部文件。

图 13. 将外部数据链接到一个现有包
图 13. 将外部数据链接到一个现有包

与本文中的其他不同数据源场景一样,将外部数据联接到现有包将在 IBM Cognos BI 服务器上导致某种形式的本地处理。另外,与本文描述的其他场景一样,您也可以选择构建一个查询来联接两个数据源或使用主/明细关系。后者的性能可能更好。同样,对于联接,两个独立查询将被生成并针对每个数据源进行处理,结果集将在本地联接。对于主/明细关系,将基于主查询的结果为明细端上数据库生成更多查询,但每个查询都将被主查询过滤,从而生成更有效的细节查询。

因此,即使使用外部数据查询,重要的也是作者要知道他们的动作的后果,做出最适合他们的需求和性能要求的决策。

参考资料

学习

获得产品和技术

讨论

  • 参与 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=650494
ArticleTitle=IBM Cognos 最佳实践: IBM Cognos BI — 使用多个关系数据源
publish-date=04252011