IBM Cognos 最佳实践: IBM Cognos BI – 提升交互关系数据访问的性能

文档性质:指南;产品:IBM Cognos 8 Framework Manager、IBM Cognos 8 Studios;关注领域:建模、报表设计

能提升设计人员和分析人员在使用 IBM Cognos BI 工具软件(Query Studio, Analysis Studio, Report Studio Express)交互处理关系型数据源时的效率的指导和技术。

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

简介

目的

本文档将会提供一些指导意见和技术,帮助设计人员和分析人员在 IBM Cognos BI 工具中交互处理关系型数据源时提升性能。

适用性

本文中的指导意见和技巧在使用以下工具时有效:

  • 8.4.x 和 10.1 版本的 IBM Cognos BI
  • GS_DB DB2 示例数据库

例外与除外责任

本文档不包括 OLAP 数据源。


概述

在 IBM Cognos BI 中,设计人员和分析人员会在使用 IBM Cognos BI Query Studio、IBM Cognos BI Analysis Studio、IBM Cognos BI Report Studio Express 和 IBM Cognos 10 的新 Business Insight Advanced studio(它在 IBM Cognos 10 中取代了 Report Studio Express )等工具时会与数据源进行交互。这些工具被称为交互工具,它们能让用户将查询项目拖放到报表上,一次拖放一个或多个,动态生成报表。 对于每个动作,IBM Cognos BI 都会再次向数据源提交查询。在处理关系数据源时,这可能会产生响应时间和数据源负载方面的问题。

例如,在 Query Studio 中,设计人员通过一次拖放一项的缓慢方式构造报表,这很常见。考虑一下以下模型。

简单星型模型的 Framework Manager 图

本图是简单星型模型设计图,中间是一张事实表,还有其相关维度,本例中是促销活动、产品、时间。

现在考虑一下 Query Studio 中出现的包的内容。

空白报表的 Query Studio UI

设计人员可能通过添加时间维度中的 Year 来缓慢地构建临时查询,这会生成对数据库的查询。

Query Studio Report 中添加了 Year 列

然后,设计人员可能从促销活动列添加促销活动名称。

Query Studio 报表中添加了额外的列

现在,已经向数据库发出两个查询,设计人员也许会注意到结果有延迟。两个维度通过销售事实表连接起来。因此,在查询中合并事实表从而生成结果所需的时间比预期要长。如果事实表数据量很大,有几百万甚至几十亿行,那么一个简单查询的等待时间也会比预期长。

设计人员可能继续通过一次一项的方式构建查询,每次添加都生成一条数据库查询。

本文档将讨论一些设计人员应该知道的,在交互处理这些数据源时会用到的技术,本文还会提供一些可由元数据建模器或报表管理器实现的解决方案,这些方案能加快潜在的速度较慢的查询。


先过滤

对设计人员和分析人员来说,提升交互查询时间的方法之一就是先过滤报表或分析。这可以通过用户自己创建过滤实现,或是由设计人员在模型中通过隐式过滤器实现。

Query Studio 中,可以在报表中添加查询项之前添加过滤器。只要在您想添加查询的项上右键单击,并选择 Filter for report

Query Studio 中数据树的右键单击菜单,显示 Filter for report 选项

首先将所有的过滤应用到报表中,然后将查询项添加到报表中。这可以在项目添加到报表后大大减少从数据库中检索出来的记录。

在其他工具软件中,可以在将项目添加到报表之前应用上下文过滤。这种方法只能用于维度数据源,如 OLAP 数据或维度建模关系型 (DMR) 数据源。DMR 是在 Framework Manager 模型中添加维度信息以便在底层关系型数据源中使用 OLAP-Style 查询的概念。由于本文档重点关注关系型数据源,以下技术可用于 DMR 包,也可用于 OLAP 数据源。

Analysis Studio 中,右键单击要过滤的项,并单击 Filter as Context (下方的屏幕截图左侧),或将项目拖放到分析的 Context filter 区域(下方的屏幕截图右侧)。

Analysis Studio 数据树的右键菜单显示 Filter as Context 选项,Analysis Studio Context UI 的过滤部分

Report Studio ExpressBusiness Insight Advanced 中,可以将项目拖放到 Context filter 区域以取得相同效果。以下是 Report Studio Express 的屏幕截图。

Report Studio 显示 UI 的上下文过滤部分

Report Studio Express 只支持维度数据源,而 Business Insight Advanced 支持维度和关系型数据源。因此,对于 Business Insight Advanced,此技术只用于与关系型数据源有关的 DMR 包。


一次选择多项

同时添加到报表或分析的项目越多,越能降低发送到数据源的查询数。

对于 Query Studio 中的列表报表,报表所需的项目都能同时多选并拖放到报表中。

Query Studio 显示多个项目同时拖放到报表中

如果不确定报表所需要的所有项目,那么建议您一开始多添加一些,然后再删除,因为查询会被缓存。缓存的结果会重用,这将在编辑结果时降低响应时间。但添加新项,将需要对数据源进行新的查询。

对于 Analysis StudioReport Studio Express,可以一次将多项添加到行或列,这会减少对数据源的查询。尽管如此,与列表报表不同, 不能一次添加所有报表项,因为行、列和度量有各自的拖放区域。

Analysis Studio 显示默认查询拖放区域

Business Insight Advanced 中,您可以选择创建列表、交叉表和图表。您所使用的报表对象的类型会决定您能一次添加到报表对象的项目范围。对于图表,只有在度量添加到报表后才能检索数据。


在无数据或限制数据下设计

在不同交互工具中,用户可以在无数据或限制数据下编写。Query Studio 中的限制数据是由元数据建模器实现的 Design Filters 产生的,它限制了基于过滤从数据源检索出的行数。Design Filters 将会在下一节介绍。

无数据设计报表能让设计人员在向数据源提交查询之前添加报表所需的所有项目。就像前一节中一次添加所有项目一样,这会大大降低对数据库的查询,同时让设计人员能够独立添加项目而不用担心每次添加的等待时间。一旦对报表设计满意,设计人员就能查看带有全部数据的报表。

Query Studio 中,Run Report 菜单有这些选项。

Query Studio UI 中 Preview with No Data 选项打开

报表可以在无数据或限制数据情况下预览。而且,限制数据将会是基于由元数据建模器在 Framework Manager 中的实现的 Design Filter 的数据。一旦报表设计满足需求,报表就可以在所有数据情况下运行。

当带限制数据预览时,设计人员会注意到有空白摘要。下方的屏幕截图演示了这种情况。

Query Studio 中 Preview with Limited Data 打开

这么做是为了让用户不会错误地将这些总数当成真实的业务数字。这些数字是基于一个缩减的数据集,而这些数据集是由模型过滤器所限制,超越了用户控制范围。

注意:与这些数据源交互的默认行为可在 Query Studio 中修改。按照以下步骤可以将无数据或限制数据预览设置为默认行为。

  1. 关闭 IBM Cognos BI 服务器。
  2. 在 IBM Cognos BI 服务器上,导航至 <IBM Cognos BI Install Directory>/templates/ps/async
  3. 将现有的 system.xml.sample 文件复制到 system.xml

    下一行定义了默认的行为:
    <param name="limitedDataMode">nodata</param>

    设置为 nodata 后,默认的行为就是无数据预览。如果设置为 partial,如下所示,默认行为就是使用 Design Filters。
    <param name="limitedDataMode">partial</param>
  4. 根据需要修改条目,保存文件并重启服务器。

要恢复到原来的行为,关闭服务器,移除或重命名 system.xml 文件,然后重启服务器。

Report Studio ExpressBusiness Insight Advanced 中,设计人员可以通过选择 Page Design 在设计模式下工作。

切换到 Page Preview 将能交互检索数据。

Analysis Studio 中,设计人员可以通过选择 Settings 菜单下的 Get Data Later 获取事实表数据。

Analysis Studio 显示 Get Data Later 选项

边上仍然显示的是维度成员,本例中是产品线和年份,但未检索事实表。要检索事实表,只要单击分析的事实表区域的 Get data 链接,或是取消 Settings 菜单项下 Get Data Later 选择。

但此选项,仍然会在边上通过连接到普通事实表来检索维度成员。如果使用 Get Data Later 特性的性能仍不可接受,那么考虑第 8 节中的技术,创建伪事实查询主题。


提示、设计过滤和通用计算

建模器可以实现多种类型提示过滤器来指导设计人员进行高效查询,也可以创建 Design Filters 来让设计人员在设计报表时使用更小的数据子集。 这两种类型在交互数据访问时都很有用。还可以将计算添加到模型中,减少交互工具中的动作。

提示

建模器可以通过实用简单的提示语法如 ?Prompt Name? 或使用提示宏来实现提示。提示宏能比提示提供更大限度的控制,但已经超出本文讨论范围。请参考 IBM Cognos BI Framework Manager User Guide 了解更多关于提示宏的详细信息。

以下就是在模型中实现提示的例子, 其中时间维度查询主题通过提示语法添加了一个过滤。

Framework Manager 中显示过滤表达式

需要用户根据一年或多年过滤报表。

要添加过滤:

  1. Project Viewer 中,双击查询主题,打开定义对话框。
  2. 单击 Filters 选项卡,然后单击底部右下角的 Add 链接。
  3. 输入需要的过滤表达式,单击 OK

过滤如下图所示。如果单击了 Usage 下的省略号(如下所示),有三个选项可供选择。默认是 Always,应用过滤。Optional 能让用户绕过提示,Design Mode Only 会影响 Framework Manager 中的测试,并影响在 Query Studio 中限制数据预览时返回的行。 如果被设置成带限制数据运行,它还会影响 Report Studio 中的报表运行,这些已经超出本文讨论范围,因为这关系到交互数据访问。

Framework Manager 中显示查询主题定义对话框的过滤选项卡的过滤 Usage 选项

例如在 Query Studio 中,在项目从时间维度添加到报表后,立刻出现提示。

Query Studio 显示 IBM Cognos BI 生成的 Year 提示

通过提供一年或几年的数据,而不是默认情况下的所有数据,设计人员会自动地将精力集中到报表上。

Design Filters

在 Framework Manager 中,建模器还可应用 Design Filters。例如,可以通过在 PROMOTION_KEY 字段上进行过滤将促销活动维度限制到少数维度。

Framework Manager 中显示 Promotion Key 的过滤表达式

过滤的 usage 属性被发送到 Design Mode Only

Framework Manager 显示过滤的 Usage 属性发送到 Design Mode Only

现在,如果 Query Studio 中启用了 Preview with Limited Data,如下所示, 设计人员就能够在添加项目到报表时具有更快的响应速度,因为数据被过滤了。

Query Studio 中 Preview with Limited Data 选项打开

报表中的促销活动被模型中的 Design Filter 过滤了。

Query Studio 报表显示基于 Design filters 的限制数据

如果启用了 Preview All Data,那么报表中会返回所有的促销活动类型。

Query Studio 中显示 Preview with Limited Data 选项关闭后,报表返回所有数据

应用 Design Filters 的提示

有些维度表可能非常大,而且是 Design Filters 的候选项。但是,通常事实表是最大的,而且会从 Design Filters 中受益。事实表可以根据一或多个外键过滤。

如果 Design Filters 应用到事实查询主题和任何相关的维度查询主题,要确保对事实和相关维度的过滤要一致。如果不这样,则在限制数据预览时,报表中不会返回数据。

回想一下之前演示的促销活动维度的 PROMOTION_KEY 例子。由于销售事实表非常大,因此使用了同样的过滤。

Framework Manager 显示实时查询主题上有一个过滤

必需使用同样的健,否则在过滤时,两个基础表之间没有匹配的记录,而且不会返回数据。

通用计算

建模者可以将常用计算添加到模型中,使得设计人员更有效率,同时减少发送到数据库的查询数量。将计算添加到模型中可以减少设计人员在交互工具中构造计算所需的动作。

例如,在 Query Studio 中,设计人员可能想要 A 列乘 B 列。要先将每一列添加到报表中,然后进行计算,这样将会发送三个单独的查询到数据库,一个是 A 列,一个是 B 列,还有一个是 A 列和 B 列相乘的结果。 而模型计算可以将这些减少到一个查询。


提供起点查询

报表管理器可能会采用为交互工具提供常用报表或分析的方法。这些起点报表/分析会被合理过滤以保证响应时间可接受。单独使用,或与提示和 Design Filters 联合使用,能在设计人员设计报表时大大改善等待时间。


创建伪事实查询主题

根据以上所述,某些情况下,设计人员可能在交互工具中通过一次拖放一个项目的方式构建报表。他们会从一个或多个维度中添加项目,然后从常见事实表将项目添加到维度中。

Framework Manager 图表显示一个简单星型模式

例如,他们可能从时间维度添加 Year,从促销活动维度添加 Promotion Name。 结果是两个维度将会在销售事实表中连接起来。如果事实表数据量很大,那么响应时间会比预期长。设计人员也许会觉得从大的表格中等待数据返回还可接受,但不理解为什么对两个维度表的简单查询不能立即返回。

此场景的另一个副作用是数据库中的任何形式的实体化(预计算聚合)可能会被忽略,因为查询中不包含任何事实。如果查询的创建是通过先添加维度再添加事实表然后又添加维度的方式构成,那么数据库优化则必须包含实体化。

除了本文档前面介绍的一些指导原则,元数据建模器还使用了一些技术,可以实现一张对大型事实表维度进行交叉连接的伪事实表。伪事实表将会用在连接中代替实际的事实表,从而提升单独从维度查询的响应时间。

伪事实查询主题的第二个作用是创建维度的笛卡尔积,它能缩短时间。尽管从数据角度看,可能没得到预期的结果,但这项技术能让设计人员快速得到某种形式的结果。一旦事实表中的项目加入报表中,结果就变得有意义了。如果这让用户可以接受,并且本文前面提到的其他技术不可行或需要扩充,那么就该考虑一下这项技术。

和其他所有技术和实现方法一样,必须要对它进行完全测试和调优,以满足需求。

要实现伪事实查询主题,就要在数据库中创建一个一行的表格,或者使用虚拟表,例如 SYSDUMMY1 在 DB2 中使用 SYSDUMMY1,或者在 Oracle 中使用 Dual。本例中使用 SYSDUMMY1。

  1. Framework Manager 中,创建一个数据源查询主题,并将它的名字设置为事实表的首字母,它是用来取代维度查询中的维度。这么做的原因是连接路径将会使用首字母的事实查询路径。本例中,“A Fake Sales Fact” 名称将会按以下表达式使用:
    Framework Manager 中显示伪销售事实数据源查询主题的 SQL

    Select 1 as Key from SYSIBM.SYSDUMMY1 返回一行,值是 1。

    Framework Manager 中显示查询主题定义对话框的 Test 选项卡查询结果为 1 行,值为 1

    Oracle 的语法示例是 Select 1 as key from dual。SQL Server 的语法示例是 Select 1 as 'Key'。每家供应商都有一点差异。

    对有些供应商,例如 Oracle 和 SQL Server,SQL Type 选项需要改成 Native。此选项通过选择查询主题定义的 Test 选项卡,单击右下角 Option,单击 SQL Settings 选项卡,然后选择 SQL Type 下拉菜单的 Native 找到。

    Framework Manager 中显示数据源查询主题的 Options 对话框的 SQL Setting 选项卡
  2. 下一步,创建伪事实查询主题与所需维度的连接。首先创建维度的主键到伪事实键的连接。
    Framework Manager 中显示 Relationship 定义对话框
  3. 单击关系表达式的省略号,并向关系定义中添加如下逻辑。
    1=1

    [DB2 GOSALESDW].[GO_TIME_DIM].[DAY_KEY]=[DB2GOSALESDW].[A Fake Sales Fact].[Key]
  4. 单击 OK

    注意关系对话框中的更改。

    Framework Manager 中显示编辑关系后的 Relationship Definition 对话框

    键之间的连接行已经没有了,因为现在关系已经是一个复杂的表达式,而不是在查询主题之间连接项目那么简单。

    表达式中的 1=1 逻辑确保连接一直为 true 并允许笛卡尔 Product 结果集。本例中连接键不会为 true,但却是必需的,因为 IBM Cognos BI 要求每个查询主题至少要有一项,以创建有效连接。

    在伪事实和每个所需维度之间创建连接。本例中,返回的结果如下所示。

    Framework Manager 图表中显示添加了伪事实表查询主题以及它与相关维度查询主题的关系

测试伪事实

在向 IBM Cognos BI 发布包以前,确保伪事实作为隐藏对象包含在包中。这样它就可以供连接使用,而用户看不到,这将避免混淆和混乱。

Framework Manager Package Definition 对话框显示包含伪查询主题作为隐藏项目

将包发布到 IBM Cognos BI 并在 Query Studio 中打开。本例中,将把时间维度和促销活动维度的项目添加到报表中。

Query Studio 中显示报表中添加了 Year 和 Promotion Name,以演示 Cartesion Product 结果

返回了一个笛卡尔 Product。直到事实度量加入后,此结果才有意义,因为这是每个项都在一个表中,而所有项在另一表中的连接。尽管如此,其响应时间却能让设计人员工作速度更快。

一旦加入了事实,数据就能提供想要的结果。

Query Studio 报表显示添加了一个事实

此刻数据好像消失了,因为事实表的连接似乎比笛卡尔 Product 结果更加稀少。这会让有些设计人员疑惑,需要详细说明。

伪事实考虑

如果 Framework Manager 模型没有在维度查询主题上应用过滤,可尝试大型笛卡尔积可能出现。那么这样会可能失败或在数据库级别或在 IBM Cognos BI 运行时造成巨大负载。

以下是可能发生的情况。

  • 大型维度表可能产生资源密集的 Cartesian 连接。 例如,一个维度中 10,000 行乘以另一个维度的 10,000 行会产生 100,000,000 行的 Cartesian 连接。
  • 在一个查询中不带事实数据连接三个或更多维度,也能产生大型笛卡尔连接。即使单个维度相对较小,随着每个维度的加入,笛卡尔连接也会成倍增长。例如,如果维度 1 有 500 行,维度 2 有 600 行,维度 3 有 1,000 行,笛卡尔 Product 将会有 300,000,000 行。
  • 某些情景下,IBM Cognos BI 构建动态多维数据集作为报表源。笛卡尔连接另一个潜在的副作用是它转换到动态多维数据集的数据量会让构建管理器抛出一个异常(使用内存太多)或超过多维数据集限制(成员数、每级成员,等),在使用伪数据时,一般不会发生这种情况,因为实际情况下,会更稀少。

在这两种情况下,考虑在伪事实表的连接表达式中添加额外的逻辑,这会缩小从维度表返回的连接键值的范围。

例如,在时间维度和伪事实的关系表达式中,可以使用过滤来将时间维度缩小到几天之内。

Framework Manager 中显示关系表达式定义,其中添加了额外的逻辑来进一步缩小记录集

可以任意设置过滤以最大限度满足业务需求。可以根据提升性能的需要将过滤用于所有相关维度关系。过滤可以是当年、当季、当月。

这种缩减的结果集可以与查看限制数据报表相对比。本例中的不同之处是先自动进行过滤,然后设计人员在报表中添加事实数据。

在本文的模型示例中,从所有三个维度向 Query Studio 添加项目,然后返回一个缩减了很多的数据集。

Query Studio 显示了一个报表中,基于额外关系逻辑的笛卡尔结果

由于伪事实的每个维度中的连接表达式的过滤,笛卡尔连接结果缩小了。

销售事实查询主题的事实数据一旦加入报表,连接关系就会对销售事实表而不是伪事实起作用,就会返回需要的数据。

Query Studio 中显示添加事实后的报表结果

CQEConfig.xml - 禁用对事实查询主题起作用

可以配置 IBM Cognos BI,在只有维度的查询中,不对事实查询主题起作用。在位于 <IBM Cognos BI install location>/configuration 文件夹下的 CQEConfig.xml 中进行此配置。默认情况下,此文件只是示例文件,名为 CQEConfig.xml.sample。在 IBM Cognos BI 启动后,文件被重名为 CQEConfig.xml 后,文件中的配置才会起作用。

要对 IBM Cognos BI 进行全局配置,在只有维度的查询中,不对事实查询主题起作用,对于环境中所有 IBM Cognos BI 报表服务器按以下步骤操作:

  1. 在 <IBM Cognos BI install location>/configuration 文件夹,将 CQEConfig.xml.sample 复制成 CQEConfig.xml。
  2. 在 <component name="CQE"> 元素下添加 Transformations 节点元素,如下所示。
    		<component name="CQE">		
    			<section name="Transformations">
    				<!--Default: "useAlphabeticalFirstFact"--> 
      			<entry name="dimOnlyQuery" value="useNoFacts" /> 
    			</section>

    注释节点(<!-- --> 标记之间) 提供了默认值设置,useAlphabeticalFirstFact 用于 dimOnlyQuery 条目。这项设置告诉 IBM Cognos BI 在只有维度的查询中,在维度之间使用字母顺序第一张通用事实表。useNoFacts 值告诉 IBM Cognos BI 在只有维度的查询中,不对通用事实查询主题起作用。
  3. 保存文件,重启 IBM Cognos BI 服务。

useNoFacts 示例

在将 CQEConfig.xml 文件配置为 useNoFacts 之前,选择 Time 维度查询主题的 Year 和 Order 方法查询主题的 Order 方法的只有维度查询的 SQL 如下所示。

Cognos SQL

select distinct 
       GO_TIME_DIM.CURRENT_YEAR  as  Year1,
       SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  as  Order_method
 from 
       great_outdoors_warehouse..GOSALESDW.GO_TIME_DIM GO_TIME_DIM,
       great_outdoors_warehouse..GOSALESDW.SLS_ORDER_METHOD_DIM SLS_ORDER_METHOD_DIM,
       great_outdoors_warehouse..GOSALESDW.SLS_SALES_FACT SLS_SALES_FACT
 where 
       (SLS_SALES_FACT.ORDER_DAY_KEY = GO_TIME_DIM.DAY_KEY) and 
       (SLS_SALES_FACT.ORDER_METHOD_KEY = SLS_ORDER_METHOD_DIM.ORDER_METHOD_KEY)

Native SQL

select distinct "GO_TIME_DIM"."CURRENT_YEAR" AS "Year1",
 "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_EN" AS 
"Order_method"
 from "GOSALESDW"."GO_TIME_DIM" "GO_TIME_DIM", "GOSALESDW"."SLS_ORDER_METHOD_DIM" 
"SLS_ORDER_METHOD_DIM", "GOSALESDW"."SLS_SALES_FACT" "SLS_SALES_FACT"
 where "SLS_SALES_FACT"."ORDER_DAY_KEY" = "GO_TIME_DIM"."DAY_KEY" and 
"SLS_SALES_FACT"."ORDER_METHOD_KEY" = "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_KEY"

在 Cognos SQL 和 Native SQL 中,Year 和 Order 方法通过 SLS_SALES_FACT 表连接。

在 CQEConfig.xml 文件中 Transformations 节点配置成 useNoFacts 后,SQL 如下所示。

Cognos SQL

select 
     D2.Year1  as  Year1,
     D3.Order_method  as  Order_method
 from 
     (select 
          GO_TIME_DIM.CURRENT_YEAR as Year1,
          RSUM(1 at GO_TIME_DIM.CURRENT_YEAR
          order by GO_TIME_DIM.CURRENT_YEAR asc local) as 
 sc
      from 
          (select 
               GO_TIME_DIM.CURRENT_YEAR  as  CURRENT_YEAR
           from 
               great_outdoors_warehouse..GOSALESDW.GO_TIME_DIM GO_TIME_DIM
           group by 
               GO_TIME_DIM.CURRENT_YEAR
          ) GO_TIME_DIM
      group by 
          GO_TIME_DIM.CURRENT_YEAR
      order by 
          Year1 asc
     ) D2
      full outer join 
     (select 
          SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  as  Order_method,
          RSUM(1  at SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  order by 
SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN asc  local)  as  sc
      from 
          great_outdoors_warehouse..GOSALESDW.SLS_ORDER_METHOD_DIM SLS_ORDER_METHOD_DIM
      group by 
          SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN
      order by 
          Order_method asc
     ) D3
      on (D2.sc = D3.sc)

Native SQL

select "GO_TIME_DIM"."CURRENT_YEAR" AS "CURRENT_YEAR"
 from "GOSALESDW"."GO_TIME_DIM" "GO_TIME_DIM"
 group by "GO_TIME_DIM"."CURRENT_YEAR"
 order by 1 asc 

select "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_EN" AS "C0"
 from "GOSALESDW"."SLS_ORDER_METHOD_DIM" "SLS_ORDER_METHOD_DIM"

您也注意到了,在 Cognos SQL 中有两个子查询,一个是 Year,另一个是 Order 方法。在基于名为 sc 的列上还有两个子查询的完全外连接。 sc 列是列的别名,它用于将两个子查询连接到一起。 换句话说,它是联合列(sc)。它可以让完整的记录集用 Year 和 Order 方法检索,然后联合到 sc 列上,它只是运行计数(1、 2、3、4,等等)。如果一个记录集比另一个多,此列中的数据将会继续增加,而另一个显示 null,如下所示。

列表报表显示完全外连接结果

本例中此连接在本地完成,可以通过检查 Native SQL 确定。Native SQL 只是两条简单的独立的 select 语句,一条是 Year(实际表中是 CURRENT_YEAR),另一条是 Order 方法(实际表中是 ORDER_METHOD_EN)。

很多情况下,这两项全局配置也许不会对相对较大的事实表起作用,并提升性能, 您也许会遇到维度表也很大的情景。这种情况下,请记住,完全外连接的本地化处理也会影响性能。还有,对维度表的某些形式的过滤(本文前面讨论的)能减轻性能方面问题。


结束语

对于在 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=677568
ArticleTitle=IBM Cognos 最佳实践: IBM Cognos BI – 提升交互关系数据访问的性能
publish-date=07222011