2.5.1.疑难解答
在开始DMR模型开发之前，我们先了解论坛会员经常关注和疑惑的三个问题：
Q1、什么是DMR模型？
英文全称为"Dimensional modeling of relational"，也就是基于关系型的维度化建模，属于ROLAP概念范畴。在Framework Manager中，引入关系型数据源后即可直接建立多个带层次结构和级别的维度及带多个度量指标的完整模型，然后通过范围关系(Scope relationship)为维度和度量建立关系。其常规和度量维度用于启用元数据的OLAP 演示、向上追溯和向下追溯以及多种OLAP 功能。
-->构建模型时建议基于已应用星形模式概念的关系模型创建模型常规维度和模型度量维度。
Q2、为什么要使用DMR？
在以下背景我们可以使用DMR：
A、没有特定的大型OLAP Server中心，如Essbase，SAPBW
B、避免Transformer所需的过多额外人工维护量
C、数据量适中，建议在1000W以下
因此使用DMR的目的只有一个：某些报表需要像多维模型一样在 Analysis Studio中切片、切块和旋转分析，和Query Studio、Report Studio 报表中启用向上和向下钻或访问多维函数。从而开发人员可以借助FM工具迅速开发仅限于Cognos内部使用的OLAP模型,虽然可以将数据源查询项目转换为维度型，若维度化模型功能对于满足你的报表功能受限，则此时建议不使用DMR。
Q3、DMR模型和普通关系型模型的查询效率对比又如何？
将关系型模式转换为DMR模型后，查询效率会相对降低。
Q3.1.查询效率为何会相对降低？
查询效率之所以降低，是因为DMR模型的查询语句复杂度相对增大。我们知道MOLAP是典型的用“存储空间换取时间”的提高效率模式，ROLAP则是运用“云计算”服务器提供高速处理功能从而提高查询效率。MDX中某些直接指定了维度成员，而这些全部都会被转换为原始的SQL语句，因此在同等条件下相比查询效率会降低(数据量小的情况下不明显)。如下图所示：
为了生成产品线成员[Camping Equipment]，Cognos为其单独生成了一个查询：
"Products" as (select "PRODUCT_LINE"."PRODUCT_LINE_CODE" "Product_line_code" ,
"PRODUCT_TYPE"."PRODUCT_TYPE_CODE" "Product_type_code" ,
min("PRODUCT_LINE"."PRODUCT_LINE_EN") "Product_line"
from "GOSALES"."PRODUCT_LINE" "PRODUCT_LINE", "GOSALES"."PRODUCT_TYPE" "PRODUCT_TYPE"
where "PRODUCT_LINE"."PRODUCT_LINE_CODE" = 991
and "PRODUCT_LINE"."PRODUCT_LINE_CODE" = "PRODUCT_TYPE"."PRODUCT_LINE_CODE"
group by "PRODUCT_LINE"."PRODUCT_LINE_CODE", "PRODUCT_TYPE"."PRODUCT_TYPE_CODE")
Q3.2.有什么办法改善DMR的性能？
在10版本后Cognos专门增加了DQM组件促进OLAP查询效率，同时还新增了一个service组件" Query Service"，它支持DQM并处理其请求与返回结果给正在处理请求的批处理报表服务(batch report service)或报表服务(report service)。Dynamic Query Mode可以指定基于其所支持的数据源包使用新的动态查询模式，这种增强基于JAVA-TM的查询执行模式提供了改进的查询性能和功能、 高安全意识的缓存和本机缓存数据接口，以充分利用 64 位技术。可支持的数据源驱动为：
→IBM DB2
→Microsoft SQL Server
→Netezza
→Oracle
→Teradata
为以上数据源建立连接时，Cognos默认开通了JDBC模型的设置，当然您可以unchecked它只使用兼容模式。
关系型模式采用DQM(动态查询模式)的使用条件：
A、必须使用64-bit安装程序执行Cognos安装
B、复制数据库驱动程序到 /webapps/p2pd/WEB-INF/lib 和 v5dataserver/lib目录中，如下图为DB2的JDBC包：
C、数据源连接时，启用JDBC连接,如下图
D、FM建模时可采用兼容模式，发布时采用DQM模型，如下图所示
E、指定将ReportService的模式：32-bit和64-bit。一般情况下，安装了64位组件后采用32-bit，因此reportservice可支持兼容模式查询和DQM查询。若采用64-bit report service模式，则报表服务不再支持兼容模式查询，而是通过JDBC所设置的连接信息从数据库获取信息，此时可以免于在reportservice服务器上安装了数据库客户端。
但话又得说回来一点，相对关系型数据源，启用DQM模式可不是“省油的灯”，尤其是非WIN环境的“动态模式”有很多细微的限制，非常敏感，稍不慎就会陷入胡同最后不得不又走回“兼容模式”。本人当初创建DMR模型时改用DQM模式也是深受苦恼，建议先了解DQM向导知识再开始工作。至于数据源来源于Essbase、TM1和OLAP Server，强烈建议启用“动态”模式。
F、若数据源是TM1/Essbase/DB2 OLAP/等，则直接启用DQM模式。
Q4、DMR和Transformer模型有什么区别？
DMR和Transformer均属于CognosBI内部的数据建模工具，所生成的模型不能被其它产品引用，但可在Cognos SDK使用。Framework Manager属于Cognos必须组件，而Transformer为可选组件。它们的区别主要可归为以下几点：
A、Transformer虽然是Cognos附属产品的可选组件，但其使用简便、开发模型迅捷的特征被国内用户广泛使用。
缺点：用过Transformer的人都知道它存在bug，维度个数不易过多、数据量大导致刷新模型时间长，尤其是增量刷新、跨平台刷新数据时。另外后期维护需要投入很大的工作量，甚至是每天都要检查模型的完整度。
B、DMR相对被国内外用户的使用频率相对少了很多，甚至是几乎无人使用。预期是刚接触Cognos产品的新人，首先能勾起其兴趣的就是Transformer，反之DMR难度相对较大同时处理大数据量远不如Transformer。于此同时，Transformer维度数不易过多、异常BUG和后期过多的维护量，恰好是DMR的优点，何况现在还有了个Dynamic Query Mode新功能。
本章内容主要给读者介绍了DMR的基本知识、特征和TM的对比，介绍了Dynamic Query Mode的使用方法，相信之前迷惑的您或许有所领悟。下个章节我们将着手DMR的实际操作工作，请看下一节“2.5.2.创建DMR模型”