3cognos framework manager元数据建模工具讲解

FrameworkManager

元数据建模工具Cognos10产品培训

数据库(Oracle、DB2、SYSBASE、SQLSERVER)CognosFrameworkManagerCognos商业智能平台数据模型ReportStudioBusinessInsightAdvancedCognosTransformerServercube3Cognos的元数据模型设计工具FrameworkManger可以连接企业的各种数据源（包括关系型数据库，多维数据库，文本，OLAP等），对数据结构进行描述，为Cognos的多维分析，即席查询，报表等各种应用提供统一一致的数据视图，降低对企业数据访问的复杂性，同时提供对各种应用使用的结构的统一的管理。FrameworkManger4Cognos工作流程设置和维护安全性管理服务器和报表FrameworkManagerProject发布包运行、察看、打印报表/分析计划管理模型制作使用实施计划制作报表/分析配置安装5了解元数据模型的角色元数据模型是对来自一个或多个数据源的信息的业务展现。BI用户使用模型对他们的数据源进行分析和报告。报表层元数据模型关系型立方体其它文件元数据模型能隐藏底层数据源的复杂结构可以更好地控制数据怎样展现给最终用户6认识通用的数据结构1.认识通用的数据结构2.FrameworkManager介绍3.在FrameworkManager中准备元数据4.在FrameworkManager中为可预期结果建模5.在FrameworkManager中创建业务视图6.在FrameworkManager管理包7.在FrameworkManager中设置安全性7区分业务型和报表型数据库业务数据库报表数据库OrderFactSalesRepCustomerProductDate0..n1..10..n1..10..n1..10..n1..1CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..n元数据模型中包括的关系型数据库通常是:业务型数据库报表型数据库8业务数据库是：用于跟踪每天业务的流程通常是标准化的或部分企业资源规划(ERP)提供的包了解业务型数据源一个标准化业务型数据库用来提高精确度并减少冗余。表关系CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..11..n1..n9了解业务型数据库的特点业务型数据库:用于减少冗余适合于数据的写入和更新而不是数据的读取10了解业务型数据库的问题因为标准化业务型数据库中的数据被细分为很多表(为了消除冗余)，因此大的查询执行起来比较慢。CustomerTypeCustomerOrderHeaderSalesAreaSalesRepOrderDetailProductLineProductTypeProduct1..11..n1..11..n1..11..n1..10..n1..10..n1..11..n1..11..n1..10..n显示来自一个产品系列的所有客户类型。在返回一个结果集之前，查询必须对七个表中的数据进行检查。11了解报表型数据源报表型数据源通常使用星型结构布局。所有事务型、大部分数值型数据存储在事实表中，所有的参考数据，例如产品信息等，存储在独立的维度表中。该数据库含有相同的信息，但是使用五个表而不是九个。OrderFactSalesRepCustomerProductDate0..n1..10..n1..10..n1..10..n1..1报表型数据库是：典型业务数据库的拷贝为快速和易于报告与业务数据库有不同的结构通常维度化，采用星型结构12认识星型结构布局的好处因为星型结构数据库比完全标准化数据库含有的表少，因此查询的性能会更快。OrderFactSalesRepCustomerProductDate1..10..n1..10..n0..n1..10..n1..1“显示来自一个产品系列的所有客户类型。”查询只需要检查三个表即可返回一个结果集。13FrameworkManager介绍1.认识通用的数据结构2.FrameworkManager介绍3.在FrameworkManager中准备元数据4.在FrameworkManager中为可预期结果建模5.在FrameworkManager中创建业务视图6.在FrameworkManager管理包7.在FrameworkManager中设置安全性14什么是FrameworkManager?FrameworkManager为Cognos提供元数据模型环境。FrameworkManager中的模型是对来自一个或多个数据源的数据结构的业务展现。根据业务需求创建一个模型:面向报表的关系型，或面向OLAP分析和报表的维度化建模关系型(DMR)。关系型模型维度化模型15了解FrameworkManager中的Project当在FrameworkManager中工作时，实际上是在一个Project中进行操作的。Project以一个文件夹的形式出现在文件系统中，它包含一个Project文件(.cpf)和XML文件。16定义一个Project在一个Project的最高层中包括的对象有：模型名字空间数据源参数映射包17定义FrameworkManager数据元素在一个Project中，采用以下元素进行定义和组织数据:文件夹查询主题查询项关系标准维度度量维度范围关系18了解查询主题类型数据源查询主题是底层数据源视图的SQL查询根据输入的对象创建缺省的数据源查询主题模型查询主题含有基于模型中现有对象创建的查询项存储过程查询主题含有基于数据库存储过程返回列表创建的查询项19对象的名称查询项查询主题名字空间属性被设为fact的查询项不含有任何属性是fact查询项的查询主题至少含有一个属性是fact查询项的查询主题属性被设为Identifier的查询项属性被设为Attribute的查询项20了解命名规范FrameworkManager中的对象:有一个标识符可以拥有相同的名字，但是必须使用一个名字空间进行唯一标识标识符可以由一个到五个部分组成，例如：查询项有一个三部分的标识符[namespace].[querysubject].[queryitem]标准维度有一个五部分的标识符[namespace].[dimension].[hierarchy].[level].[queryitem]21了解FrameworkManagerUIProject信息察看器、图示、维度图22FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布23FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布24创建Project分析与报表作者合作，了解业务报表需求。了解数据和数据源的结构。创建创建Project确定Project结构导入所需元数据创建Project25分析BI和数据需求确定要解决的与业务智能相关的问题。要了解的问题包括:多语言性能安全表达什么数据能有效的解决它们？需要了解的问题包括:元数据多数据源建模需求关系26创建Project设定Project的名称和文件地址27了解数据源从下面的数据源将元数据导入模型:关系型数据库SAPBW现有Cognos模型OLAP数据源Architect模型Impromptu信息目录DataManager目录第三方元数据源其它FrameworkManager模型28从多数据源导入从一个或多个数据源导入元数据要考虑下面几点:给每个导入单独创建一个名字空间.在数据源之间定义关系.29创建数据源连接为数据源指定连接和认证信息30导入源数据从关系型数据库导入元数据导入选择导入对象选择导入源选择数据源创建数据源选择导入对象选择生成关系的标准31指定关系标准选择一个创建关系(1)根据主键和外键创建关系(2)根据两个表的唯一索引创建关系(3)根据查询匹配名称和数据类型创建关系选择在关系生成过程中涉及的对象集

(1)检查所选表间的关系，忽略所有现有查询主题

(2)忽略所选中表的关系，只检查每个导入的查询主题和现有查询主题的关系

(3)执行上面两个选项当数据库中存在外链接接时，说明导入查询主题间的关系：选项(1)转成内链接

(1..n)。两边的数据关系必须都为1选项(2)创建外链接(0..n)。两边的数据关系中有一边必须为0选择生成关系的标准32了解关系类型:基数（Cardinality）员工安全号1..11..1员工分公司1..10..n零件供应商1..n1..n一对一:一个员工持有一个安全号。一对多:每个分公司可能有很多员工。

多对多:每个零件可以由很多供应商提供，每个供应商可能提供很多零件。33认识基数组合(0,1)..n对(0,1)..n(多对多，需要在模型/数据库中调整)0..(1,n)对1..(1,n)(可以引起性能的降低。产生外连接，成本高的查询)1..1对1..1(如同一张表。可以考虑在模型中合并)1..1对1..n(被认为是理想状态。理论上，所有的事情应该模拟成这种关系)UML符号中的第一个数字指示关系是可选(0)或必要(1)第二个数字定义在模型中两个查询主题之间数据关联的发生：可以是一个（1）或多个（n）34组织内部结构指明数据源查询主题产生的地方模型这部分中的定义项表示数据源和它们的原始结构为了维护清晰和方便，确定和创建一个project结构。创建数据源视图(DataSourceView)名字空间(namespace).对每个数据源应用包含数据源查询主题的名字空间。35关于建模的建议详细说明报表需求和数据访问策略只输入需要的报表对象，并且改变尽可能的少检验关系和查询项的属性定制运行的元数据手工确定查询的使用用模型查询主题控制查询的生成和使用定义determinants需求解决两个查询主题之间的多个不确定关系如果需要OLAP风格的查询模型化维度用星型结构的分组构筑业务视图36FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布37准备元数据准备检查、修改、创建关系添加多语言支持检查和修改对象属性编辑SQL添加计算创建和应用过滤添加提示准备元数据38导入之后，确定元数据准确表达数据源。检查和修改查询项或度量属性应该设成Identifier或Attribute修改查询项或度量属性，控制这些对象在报表中的展现。39确定查询项和度量的聚合方式当报表制作者创建一个使用聚合查询项的报表时，FrameworkManager会应用聚合规则40修改用途（Usage）和常规聚合属性通过设置用途属性，确定一个查询项所代表的数据的预期使用。通过确定数据的预期使用情况，可以确定需要何种聚合规则。通过设置常规聚合属性来设置一个查询项的聚合规则。使用属性有：Identifier：代表被用于分组或汇总与其相关的Fact数据的列。也代表一个索引列。还代表日期或时间列。Fact：代表一个包含数值数据可被分组或汇总的列，例如，产品成本。Attribute：代表一个既非标识也非事实的列，例如描述信息。Unkown：当模型设计开发者不能确定数据的角色时使用41确定FrameworkManager中的关系关系在对象图表或内容探察器中维护。它们定义查询主题间的连接和基数。基数定义查询主题之间关系的数量42认识FrameworkManager中的基数FrameworkManager中有四种类型的基数:0..n–

零记录到多记录1..n–一个记录到多记录0..1–零记录到一个记录1..1–必须有一个记录43认识基数组合(回顾)(0,1)..n对(0,1)..n(多对多，需要在模型/数据库中调整)0..(1,n)对1..(1,n)(可以引起性能的降低。产生外连接，成本高的查询)1..1对1..1(如同一张表。可以考虑在模型中合并)1..1对1..n(被认为是理想状态。理论上，所有的事情应该模拟成这种关系)441..11..nFrameworkManager在导入过程中为元数据创建关系。可以修改现有关系，也可以创建一个不存在的新关系。关系可以在任意两个查询主题之间创建。模型查询主题关系优先于数据源视图关系。创建和修改关系ProductProduct_Forecast1..10..n模型查询主题名字空间ProductProduct_Forecast数据源视图名字空间优先于45为运行定制元数据在查询主题中修改运行的SQL，动态控制返回的数据。例如，使用宏中的会话参数和参数映射处理多语言数据和安全性使用提示宏让用户对值进行选择添加查询结果集的用户定义函数、计算和过滤46创建计算（Calculations）创建计算，给报表作者提供他们经常使用的值计算可以使用:查询项参数函数有两种类型的计算:内置（Embedded）：只想给一个查询主题使用独立（stand–alone）：希望重复使用[gosales].[ORDER_DETAILS].[QUANTITY][gosales].[ORDER_DETAILS].[UNIT_SALE_PRICE]查询项算子计划收入计算*47了解过滤过滤被用来限制查询主题所检索的记录FrameworkManager有两种过滤:独立式(可重复使用)内嵌式(面向单个查询主题)独立过滤内嵌过滤48FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布49报表陷阱:引用两个没有维度背景的事实引用两个没有维度背景的事实被认为是笛卡尔基连接，是将来自两个数据集的数据放到一个查询中。可以通过从事实表中删除文本项(维度信息)来防止。所有查询都应该至少用一个公共维度属性来加以约束。50引用两个没有维度背景的事实(续)查询主题报表输出SALES_TARGETStaffcodeRetailernameSalestargetProductnumberOrderdetailcodeActualrevenueUnitcostProductnumber1..11..nPRODUCTProductnumberProductnameProductimage1..11..nORDER_DETAILS$171,576,387.88HinodeMegane$171,576,387.88CordagesDiscount$734,257$175,400$436,017$612,334SalestargetAnapurnaDieFitness-Experten$171,576,387.88AlloAllo$171,576,387.88HanagataGolfShopActualrevenueRetailername$50,882$958,122$171,576,387.88$171,576,387.88从事实表中引用维度信息容易产生笛卡尔基，应该将其删除，而从两表的共享维表中引用该项。51SALES_TARGETStaffcodeSalestargetRetailertnumberOrderdetailcodeActualrevenueUnitcostRetailertnumber引用两个没有维度背景的事实(续)查询主题报表输出1..11..nRETAILER_DIMENSIONRetailernumberRetailernameProductnumber1..11..n$76,387HinodeMegane$1,276,387CordagesDiscount$734,257$175,400$436,017$612,334SalestargetAnapurnaDieFitness-Experten$576,387AlloAllo$745,783HanagataGolfShopActualrevenueRetailername$50,882$958,122$171,576$876,387ORDER_DETAILS共享维表该项来自共享维表52报表陷阱:产生不需要的查询裂缝不需要的查询裂缝(完全外连接)会在下列情况下产生:模型允许创建含有盲点的查询查询主题被错误的当作事实53产生不需要的查询裂缝:示例ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODESALES_TARGETSALES_STAFF_CODE

SALES_YEAR

SALES_PERIOD

RETAILER_NAME

PRODUCT_NUMBER

SALES_TARGET

RETAILER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

FIRST_NAME_MB

LAST_NAME

LAST_NAME_MB

POSITION_EN

POSITION_FR

POSITION_DE

POSITION_NL

POSITION_JAPRODUCTPRODUCT_NUMBER

INTRODUCTION_DATE

PRODUCT_TYPE_CODE

PRODUCTION_COST

MARGIN

PRODUCT_IMAGEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

PRODUCT_NUMBER

ACTUAL_REVENUE

QUANTITY

UNIT_COST

UNIT_PRICE

UNIT_SALE_PRICE1..n1..11..11..n1..n1..11..n1..11..n1..1盲点查询主题54产生不需要的查询裂缝:示例用被选中的查询主题制作报表结果如下：

可以看到ActualRevenue膨胀了。这是因为ActualRevenue是针对产品的合计，而不是产品和销售的结合，即不管销售是否卖过的产品，都被计算在内。这是由于ORDER_DETAILS查询主题和SALES_STAFF查询主题之间没有直接的关系引起的。同两边有关系的ORDER_HEADER查询主题也没有包括在查询里。这就是一个盲点。由于一个查询主题在查询中被省略使一个需求的关系路径丢失时，就产生盲点。如果ORDER_HEADER查询主题被包括在查询里。就会得到正确的结果。解决这个问题的方法是将ORDER_HEADER和ORDER_DETAILS合并。55解决不需要的查询裂缝:示例ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODESALES_TARGETSALES_STAFF_CODE

SALES_YEAR

SALES_PERIOD

RETAILER_NAME

PRODUCT_NUMBER

SALES_TARGET

RETAILER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

FIRST_NAME_MB

LAST_NAME

LAST_NAME_MB

POSITION_EN

POSITION_FR

POSITION_DE

POSITION_NL

POSITION_JAPRODUCTPRODUCT_NUMBER

INTRODUCTION_DATE

PRODUCT_TYPE_CODE

PRODUCTION_COST

MARGIN

PRODUCT_IMAGEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

PRODUCT_NUMBER

ACTUAL_REVENUE

QUANTITY

UNIT_COST

UNIT_PRICE

UNIT_SALE_PRICE1..n1..11..11..n1..n1..11..n1..11..n1..1查询主题56SALES_TARGET解决不需要的查询裂缝:示例PRODUCTNAME:AloeRelief,BearEdgeANDLASTNAME:AllessoriPRODUCT_NAMELAST_NAMEACTUAL_REVENUEAloeReliefAllessori$69,346.28$1,190Summary$1,154,494.82$22,586BearEdgeAllessori$1,085,148.54$21,296合并前的报表输出SALES_TARGETPRODUCT_NAMELAST_NAMEACTUAL_REVENUEAloeReliefAllessori$2,129.16$1,190Summary$35,946.36$22,486BearEdgeAllessori$33,817.20$21,296合并后的报表输出57当一个查询对象和另一个查询主题具有多种关系时会产生模糊连接。使用哪个关系呢？报表陷阱:使用含有模糊连接的查询主题编写报表OrdersTimeOrderDate=DayKeyShipDate=DayKeyCloseDate=DayKeyCognoa8通常按字母顺序选择关系，在这种情况下将选择CloseDate。58解决多模糊连接的问题让查询主题扮演不同的角色解决多模糊连接的问题。OrdersTimeOrderDate=DayKeyCloseDate=DayKeyShipTimeCloseTimeShipDate=DayKey59用FrameworkManager进行星型模式建模无论是对业务型还是报表型数据源进行建模，将其模型化为一种虚拟的星型模式通常会产生最佳的结果。模型化不恰当的元数据会产生不可预料的结果和各种报表陷阱。60星型模式建模的优点主题域集市(星型模式分组)数据针对特定的业务区最终用户更加容易理解——表数量最少可编辑和扩展——可以轻松添加一个新的事实并重复使用现有维度共享维度可以防止数据陷阱——事实通过维度和其它事实建立关系61定义Cognos的基数使用Cognos使用基数:用于聚合目的告诉Cognos哪些查询主题是维度，哪些是事实（细节）ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1只带有0..n或1..n基数的查询主题定义为事实。基数是以查询主题在查询中的使用为基础。62认识查询的使用了解包括四个查询主题的查询。事实维度维度事实ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1ORDER_HEADER并不确定为事实，因为它并没有只带有“1对n”的基数。63认识查询的使用(续)了解包括SALES_STAFF、SALES_BRANCH和ORDER_HEADER的查询。不在查询中事实维度事实ORDER_HEADERSALES_STAFFSALES_BRANCH1..n1..11..n1..1ORDER_DETAILS1..11..nRETURNED_ITEM0..n1..1只使用SALES_STAFF、SALES_BRANCH和ORDER_HEADER时，ORDER_HEADER将起到一个事实的作用。64手工建模手工建模:打印模型的导入视图确定哪些查询主题可以作为事实或维度确定其中含有描述性数据的事实查询主题65作业1对象图表66作业1对象图表(解决方案)1..n1..n1..11..1OrderDetailsDimensionBranchHistoryDimension1..11..n①③②④⑤67①PRODUCT和PRODUCT_TYPE两个查询主题根据查询表现为事实或维度。它们是十分合适的合并对象，因为PRODUCT是一个雪花维度。可以合并PRODUCT、PRODUCT_TYPE、PRODUCT_LINE和PRODUCT_MULTILINGUAL。②

ORDER_HEADER和ORDER_DETAILS可以合并，因此ORDER_HEADER就不模糊了。这对于ORDER_HEADER不是最终的解决方案，但是一个开端。③

SALES_BRANCH和SALES_STAFF根据它们在查询中的使用，两者都是模糊查询主题。这两个查询主题连同COUNTRY和COUNTRY_MULTILINGUAL有着紧密的关系，并可以合并成一个模型查询主题。④这个新的查询主题将有两个潜在的连到ORDER_HEADER的关系，一个从SALES_STAFF，一个从SALES_BRANCH。为了确保新的查询主题之间的连接路径不模糊，可以建一个允许跟踪历史的拷贝，对于销售员转移到另一个部门发生的销售事件进行追踪。我们将为每个查询主题删除不必要的关系，保持合适的关系。⑤尽管ORDER_DETAILS和ORDER_ITEM之间没有报表问题，为了遵循星型结构的规则，要在两个查询主题之间放一个维表。这让我们在只有一个事实表的一个逻辑业务组中放置一个事实（星型模式）。我们还可以用共享维度查询两个事实。解决方案说明68定义模型查询主题模型查询主题可以重复使用来自数据源查询主题和其它模型查询主题的查询项。对解决报表陷阱问题和为报表作者创建有意义的元数据视图很有用。模型查询主题允许对元数据进行进一步的定制来满足特定的需求，不会对底层查询主题产生影响。用于创建模型查询主题的数据源查询主题模型查询主题ProductProductLineProductTypeProductDimension69对数据源视图建模尽可能的保持数据源视图为其原始状态。当数据源发生变化时可以减少维护工作。数据库ProductTimeCustomerFrameworkManager模型

(数据源视图)ProductLineProductTypeProductDimensionProductsTimeCustomerProductLineProductTypeOrdersOrders新建名字空间70为运行定制元数据通过添加模型和计算创建动态SQL，增强业务规则或解决报表问题71控制查询的生成和使用通过下列方式使用模型查询主题明确数据源查询主题的角色:用维度分开事实并用事实分开维度将雪花型表压缩为单一模型查询主题SALES_STAFFSALES_BRANCH1..11..nSALES_TARGET1..11..nCOUNTRY1..11..nSalesStaffDimension1..1SALES_TARGET1..n模型查询主题72解决多模糊连接的问题一些查询主题可能含有到另一个查询主题的多个模糊连接。OrdersFactSalesStaffDimensionSalesStaffCodeSalesBranchCodeOrdersFactSalesStaffCodeSalesStaffDimensionBranchHistoryDimensionSalesBranchCode73创建“纯”事实ORDER_HEADER含有应该在一个OrdersFact查询主题中使用的键。ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

SHIP_DATE

PRODUCT_NUMBER

Quantity

UnitCost

…….1..n1..1OrdersFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

ORDER_DATE

ORDER_CLOSE_DATE

SHIP_DATE

Quantity

UnitCost

UnitPrice

UnitSalePrice

ActualRevenue

PlannedRevenue

GrossProfit

ProductionCost

Margin合并ORDER_HEADER和ORDER_DETAILS创建一个可用的事实查询主题的基础。然而，不是所有的ORDER_HEADER查询项，都应该放进新的查询主题。删除任何代表维度信息的查询项(如：RETAILER_NAME),并隐藏那些报表制作者可见的事实的键。这使新的查询主题象在星型结构数据仓库中的一个“纯”的事实表。74OrdersFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

ORDER_DATE

ORDER_CLOSE_DATE

SHIP_DATE

Quantity

UnitCost

UnitPrice

UnitSalePrice

ActualRevenue

PlannedRevenue

GrossProfit

ProductionCost

MarginReturnsFactPRODUCT_NUMBER

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_METHOD_CODE

RETURN_CODE

RETURN_DATE

ORDER_DETAIL_CODE

RETURN_REASON_CODE

RETURN_QUANTITY创建“纯”事实(续)RETURNED_ITEM需要和OrdersFact相同的关系。RETURNED_ITEMRETURN_CODE

RETURN_DATE

ORDER_METHOD_CODE

RETURN_REASON_CODE

RETURN_QUANTITY因为退货和订单的关系紧密，所以它们需要与作为订货维度的关系同样。这样能够提供给有写逻辑报表能力的报表制作者，在没有包括订单信息的情况下得到退货的结果，如“哪些产品被退货？”。为了建立RETURNED_ITEM与所有需要的维度之间的关系，可以创建一个模型查询主题或改变数据源查询主题的SQL以包含所有需要的键。75ORDER_HEADERORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

RETAILER_SITE_CODE

RETAILER_CONTACT_CODE

SALES_STAFF_CODE

SALES_BRANCH_CODE

ORDER_DATE

ORDER_CLOSE_DATE

ORDER_METHOD_CODEORDER_DETAILSORDER_DETAIL_CODE

ORDER_NUMBER

SHIP_DATE

PRODUCT_NUMBER

Quantity

UnitCost

…….1..n1..1创建“纯”维度将来自ORDER_HEADER的维度查询项添加到OrderDetailsDimension。OrderDetailsDimensionORDER_NUMBER

RETAILER_NAME

RETAILER_NAME_MB

ORDER_DETAIL_CODE添加ORDER_NUMBER,RETAILER_NAME和RETAILER_NAME_MB到OrderDetailsDimension解决ORDER_HEADER作为一个模糊查询主题产生的问题。确定用于报表目的需要的ORDER_HEADER中的查询项，如ORDER_NUMBER和RETAILER_NAME。我们可以安置ORDER_HEADER中剩余的需求项到OrderDetailsDimension中。通过把查询项放置到一个逻辑位置，并确定这些维度查询项在最终的模型展示中没有丢失，来创建一个“纯”维度。报告也可能需要ORDER_DETAIL_CODE。我们可以选择把它放在OrdersFact模型查询主题中使它生效，或更适合它放在一个和它有同样描述信息的查询主题中。76建模为星型模式–考虑事项需要克服的一些障碍:复杂的数据源视图（业务系统数据源非为报表设计）大量连接的性能影响（为提高报表性能，参考数据仓库存储理念，无法避免大量表的连接）缺少时间维度表造成时间汇总很难处理（没有时间维度，用LevelsFact和OrdersFact作报表得不到预期的结果）实现一个时间维度添加一个时间维度可以让作者进行比较简单的基于时间的查询。77TimeDimension

MONTH_KEY

DAY_KEY

……OrdersFact

SHIP_DAY_KEY

Quantity

…….SalesTargetFact

MONTH_KEY

SALES_TARGET1..n1..1SalesTargetFact

SALES_YEAR

SALES_PERIOD

SALES_TARGET1..11..nOrdersFact

SHIP_DATE

Quantity

…….ProductDimension1..11..n1..11..n1..11..n1..n1..1ProductDimension78解决多模糊连接的问题实现一个时间维度后，我们可能需要使用不同角色扮演时间维度解决多模糊连接的问题。OrdersTimeOrderDate=DayKeyCloseDate=DayKeyShipTimeCloseTimeShipDate=DayKey79设定DeterminantDeterminant可以定义唯一标识一个数据集的数据库列(查询项)集合，或者可以指定一个能够标识数据中的非唯一集的列集合。下列情景，在很有限的情况下才需要设定determinants，其中包括：连接在一个查询主题上的多个粒度层BLOB数据类型在查询主题中Determinant是Cognos8的特性，它设计成提供控制所有粒度。在Determinant中指定的设置给Cognos8提供了充分的信息正确聚合有多粒度层查询中的事实数据。Determinant与数据库中的键和索引的概念的关系最密切。在Determinant中没有层次结构的概念，尽管它们被指定的顺序决定它们估算的顺序。设定Determinant(续)TimeDimension

MONTH_KEY

DAY_KEY

……OrdersFact

SHIP_DAY_KEY

Quantity

ActualRevenue

…….SalesTargetFact

MONTH_KEY

SALES_TARGET1..11..n1..11..n1..11..n1..n1..1ProductDimension在一个TimeDimension查询主题中，出现多粒度层的连接，MONTH_KEY和DAY_KEY

。这样当在两层进行多事实查询时，会出现问题，而你则需要防止重复计数。81多粒度的查询会出现重复计算查询结果82单粒度查询的正确结果83设定Determinant(续)数据集示例#1Monday,Jan2,200520050102Jan052005012005Sunday,Jan1,200520050101Jan052005012005DayNameDayKeyMonthNameMonthKeyYearKey数据Determinant设置NoYesDayNameMonthKeyMonthNameYearKeyDayKeyDayYesNoMonthNameMonthKeyMonthYesNoNoneYearKeyYearGroupByUniquelyIdentifiedAttributesKeyName84设定Determinant(续)在例中，能定义3个Determinant，两个非唯一Determinant(YearKey和MonthKey)，和一个唯一Determinant(DayKey)。DayKey是表的唯一键。因为它是唯一键，我们只选UniquelyIdentified设置，而不选GroupBy。MonthKey也是键，但不唯一。因此不能选UniquelyIdentified设置。然而，MonthKey是所有在数据中为一个特定年指定一个月值所需要的。如果要从这个时间表查询月，要通过MonthKey分组查询。这样做是因为值是重复的。这就是为什么我们在Determinant设置中选GroupBy。类似的逻辑应用于YearDeterminant。当用上表的一个列评估一个查询时，Cognos8查询引擎每次就要寻找一个Determinant列参照，当找到它时就停止。85设定Determinant(续)数据集示例#2Monday,Jan2,200520050102January012005Sunday,Jan1,200520050101January012005DayNameDayKeyMonthNameMonthKeyYearKey数据Determinant设置NoYesDayNameMonthKeyMonthNameYearKeyDayKeyDayYesNoMonthNameYearKey,MonthKeyMonthYesNoNoneYearKeyYearGroupByUniquelyIdentifiedAttributesKeyName86设定Determinant(续)在例中，能定义3个Determinant，两个非唯一Determinant(YearKey和MonthKey)，和一个唯一Determinant(DayKey)。与数据集示例#1不同，MonthKey不能满足在数据中为一个特定年指定一个特定月值。如果想要从这个时间表在给定的年查询月，我们要写一个使用selectminfunction的语法和通过YearKey和MonthKey分组。因此，当我们为这个特殊的数据集指定Determinant时，我们为月组合一个YearKey和MonthKey的Determinant键，并设置中选GroupBy。87月层Determinant的作用查询结果GroupBy的设置避免了重复计算88FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布89模型化元数据和准备业务视图要增强模型的业务视图，可以:模型化预知的结果（星型结构）模型化OLAP风格的查询（模型化维度）创建一个或多个业务视图添加计算创建和应用过滤添加提示模型化元数据&准备业务视图90创建一个业务视图基本的模型结构包括一个数据源视图和一个业务视图.业务视图为报表作者提供一个有意义的元数据视图。展现层物理层在FrameworkManager中可以用多种方式构造Project。在此推荐的构造FrameworkManagerProject的方案，主要考虑可以降低报表制作的复杂性，有利于模型的维护：推荐基本结构采用由包含数据源和存储过程查询主题的数据源视图(物理层)和包含快捷键和模型查询主题的业务视图(展现层)构成的双层模型。双层模型适用报表制作者和数据建模人员。展现层可以让报表制作者更加容易的查找和理解数据，物理层则是展现层的基础。91创建一个业务视图(续)创建一个代表星型模式的业务视图可以:为最终用户提供一个直观视图提供可预测的结果Customer数据源视图ProductLineProductTypeProductTimeCustomerOrdersProductOrdersBusinessViewOrdersProductsTime业务视图最终的业务视图可以是为解决报表陷阱而创建的数据源查询主题以及模型查询主题的捷径92使用星型模式分组构建业务视图可以使用星型模式分组快速构建业务视图。对象表项目查看器用StarSchemaGroupingWizard创建基于以事实为中心和其关联维度的模型的逻辑业务视图。这种类型的展现允许报表制作者容易用共享维度创建多事实查询93识别业务视图中的共享维度命名规范使得共享维度的识别变得很容易。项目查看器为了返回在查询中指定的每个事实都带有正确的聚合结果数据，共享维度允许Cognos创建一个拼接的查询。这些出现在每个名字空间中的维度的快捷键有相同的名称，表示它们是共享的和指向的是同一个原查询主题94认识FrameworkManager中递归关系当导入元数据时，FrameworkManager在表中显示自连接（self–join），但是不以查询来执行它们。递归关系

SALES_STAFF_CODE和MANAGER_CODESALES_STAFFSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

…….MANAGER_CODE95解决递归关系使用模型查询主题或快捷方式创建和修改递归关系。递归关系现在可以进行编辑1..n1..1SALES_STAFFSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

…….MANAGER_CODEManagersSALES_STAFF_CODE

FIRST_NAME

LAST_NAME

96定义维度建模关系(DMR)元数据在Cognos中，DMR指的是一个建模人员为关系型数据源提供的允许进行OLAP风格查询的维度信息。这种信息通过以下元素定义：标准维度度量维度范围关系（ScopeRelationship）97决定一种建模样式使用标准关系建模：用基本关系即席查询和报表使用维度建模关系建模:希望在AnalysisStudio里对关系型数据进行分析希望在报表和即席查询中进行向上/向下钻取希望在制作工具中访问成员函数98定义标准维度标准维度由一个或多个用户定义的层次结构组成，这些层次结构由层、键、标题和属性组成。层次结构层成员标题业务键属性层次结构面板项目查看器层的信息用于在执行查询和分析时正确地聚合度量99区分Determinant和标准维度Determinants为查询主题设置多事实/多粒度查询所需rollup聚合Blob需要不能提供OLAP功能标准维度设置的层次结构允许对关系型数据进行OLAP风格的分析给单粒度查询定义rollup聚合是AnalysisStudio所需的100定义度量维度度量维度是一个事实逻辑集合，可以实现对关系型数据源进行OLAP风格的查询。度量维度用于链接相关标准维度，可以:从数据库中的单一表创建从跨多个数据库的多个表创建度量维度用图标来标识101定义范围关系范围关系存在于度量维度和标准维度之间，定义可以用于报表的度量所在的层。范围可以被创建、修改或删除。在度量维度和标准维度之间的范围关系自动创建，它隐含在已经定义了有效的连接关系的查询主题中102FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布103创建和管理包要创建和管理包，可以:定义包的内容修改包指定语言设置和编辑包的内部启用版本控制创建和管理包104将要发布的模型对象包括在包里创建和修改包模型包105设置包函数列表（PackageFunctionList）包函数列表可以用来指定给报表作者提供哪些数据源函数。106发布包当发布一个包时，可以选择保存到ReportNetserver或一个网络地址在发布之前，应该对包进行检查CognosConnectionFileSystem107设置模型版本控制（ModelVersionControl）发布一个包时，可以选择在CognosBIserver上保留多少个模型版本。设定保留多少个版本108嵌套包创建一个嵌套包时，会建一个基于其它现有包的主包（masterpackage）。用嵌套包重复使用模型信息，可以节省时间，维护也更加方便。嵌套包的另一个优点是可以仅发布主包(masterpackage)就能够将所有被引用的包提供给报表作者109FrameworkManager工作流程导入ContentStore数据源ReportStudioQueryStudioAnalysisStudio创建Project准备元数据模型化元数据&准备业务视图创建和管理包管理Project设置安全性发布110设置安全性Cognos的安全性是通过用户认证和内容授权访问来实现的要在FrameworkManager中设置安全性，可以：定义包的访问权限创建安全性过滤定义对象的访问权限定义包管理权限设置安全性111配置认证提供者Cognos使用第三方认证，同时利用提供者现有的用户和组知识库。提供者保存认证信息，例如用户名、ID