cognos10行业培训中文元数据建模指南

（/infocenter/cogic/v1r0m0/index.jsp）LicensedMaterials-Propertyof©CopyrightIBMCorp.2005, ernmentUsersRestrictedRights–Use,duplicationordisclosurerestrictedbyGSAADPScheduleContractwithIBMCorp.IBM、IBM徽标、 、ReportNet,和Cognos是InternationalBusinessMachinesCorp.,在全球许多司法区域的商标或 他产品和服务名称可能是IBM或其他公司的商标。Web站点 opytrade.shtml上包含了IBM商标的 简介第1章：元数据建模指南IBMCognos建模概念按关系建模的概念模型设计考虑因素维度建模概念建立关系模型定义按关系建模的基础定义模型的维度表达组织模型第2IBMCognosSQL了解维度查询单资料查询 1-n1-表示层级级别的查询索引IBM®Cognos®FrameworkManagerIBMCognosIBMCognos 文档在内的IBM®Cognos®产品文档，请众多IBMCognosInformationCenter（ jsp）之一。对版本说明的更新会直接发布到InformationCenter。IBMCognosPDF快速浏览是说明IBMCognos产品组件关键功能的简短联机。要查看快速浏览，请启动IBMCognosConnection，然后单击“欢迎”页面右下角的“快速浏览”。还可以从IBMCognosInformationCenter获取快速浏览。该文档介绍了该产品的当前功能。文档中可能包括对当前未提供的项目的。不应就此推断将来要提供任何此类项目。任何此类都不是一种要提供任何材料、代码或功能的义务、承诺或。这些功能的开发、发布及其时间都仍将由IBM自行决定。GreatOutdoorsGOGreatOutdoorsIBMIBM客户开发示样应用程序的示样数据。这些虚构的记录包括销售、产品分发、财务及人力资源的示样数据。若与实际名称、地址、或术或公共来源编译的资料数据，或经拥有者用作开发示样应用程序的示样数据。的产品名称可能是其各自所有者的商标。，不得擅自。易性功能可以帮助身有残疾（如行动有或视力受限）的用户使用产品。IBM®ManagerUserGuide》中的“易 第1IBM®Cognos®FrameworkManagerIBMCognosBI含一个或多个数据源的物理信息和业务信息的元数据集合。IBMCognosBI对标准化和非标准化关系数据源以及多种OLAP数据源启用了性能管理。IBMCognos（第7）论述了您需要了解的与业务报告和分析中使用的元数据建模相关的IBMCognos基本建模概念。（第21）要另一种语言的IBMCognos元数据建模指南文档，请转至installation_location\c10\ ation并打开所需语言的文件夹。然后打开ug_best.pdf。IBMCognos基数（第8决定因素（第10多资料、多粒度查询（第13）关系和决定因素（第15SQL（第16元数据缓存（第17查 与维度（第17页查 的快捷方式与副本（第17页文件夹与名称空间（第19操作顺序（第19模型大小影响（第20）常规维度（第20度量维度（第21范围关系（第21IBM®Cognos®FrameworkManagerIBMCognosysisStudio的要求，且经证实这也是用户组织数据的一种有效方法。IBMCognosIBMCognos（第13）在0:1中，0是最小基数，1是最大基数。1:n中，1是最小基数，n1:11:n1n01:10:n。这表示报表即使在没有任何销售数据时，也会显示请求的。所以，1n0:1到0:1到1:1到1:1到使用“RelationshipDefinition”框中的“Relationshipimpact”结算单来帮助您了解基数。例如，销售人员(1:1)联接至订单(0:n)。生成查询时，IBMCognos1nn1 使用“ModelAdvisor”来查看对模型中的基数所暗示行为的评估。第34）确生成查询，这会产生错误结果（第40页）。IBMCognos在此示例中，SalesBranchOrderHeaderOrderHeaderSalesSQL，SalesstaffOrderdetailsSalesstaffSalesbranchOrderdetailsOrderheader在此示例中，一个查询中仅包含三个查询。不使用Orderdetails。现在将OrderSalesstaff

决定因素通过表达查询中的子集或数据组来反映粒度，并用于确保此重复数据的正确聚合。IBMCognos200612006120061200612您可以如下定义此数据集的三个决定因素--两个“分组依据”决定因素（“Year”和键年无否是否是日是否各年2月的所有数据均会分在一组中，而不是仅2006年2月的所有数据分在一组中。洲洲洲无键无否是无否是无是否种方式，IBMCognos软件可以选择出匹配最好的决定因素。中的group和for子句。 联接至“Sales”。有关详细信息，请参阅"多资料、多粒度查询"（第13页）。例如，“Time”具有“MonthKey”和属性“Daysinthemonth”，每一天都重复该属性。如果您希望在报表中使用“Daysinthemonth”，则不会希望对该月的每一天使用“Days值。在SQL中，此值为XMIN(DaysinthemonthforMonth_Key)。CognosSQL中还有一个Groupby子句。BLOB检索BLOB数据。要进行此查询，您需要唯一标行的键，并且该键必须没有多段。 如果联接构建在列子集上，且这些列是关系的0..1方或1..1方唯一决定因素的键所的列，则会产生。解决此的办法是修改关系以与决定因素完全一致，或修改决定因素 请注意，在本小节中术语“维度”用于概念上的意义。基数为1:1或0:1的查询可用作维度。有关详细信息，请参阅"基数"（第8页）。询。维度查询通常具有包含重复键的属性数据的不同组或级别。IBMCognos自动聚合“Time”是本示例中粒度问题的焦点。“Sales”基于“Daykey”与“Time”联接，“Product“Product”查询至少可包含三个决定因素：“Productline”、“Producttype”和的“ty”、“Productforecast”的“Expectedvolume”、“Time”的“Month”和定因素。有关示例，请参阅"决定因素"（第10页）。年4月Aloe年4月CoursePro年月Aloe年2月CoursePro1年2月Aloe如果您未在“Time”查询中正确指定决定因素，则可能产生错误聚合。例如，“Productforecast”中的“Month”级别存在的“Expectedvolume”值对于“Time”查询中的每一天均重复。如果决定因素设置不正确，则“Expectedvolume”的值会与月中的天数相乘。20074Aloe年4月CoursePro年2月Aloe年2月CoursePro年2月Aloe是最小化SQL？"（第16页）。 SQLSQLIBM®Cognos®FrameworkManagerUserGuide》中“ModelAdvisor”。SQLSQL“ProductType”、“Product”和“ProductMultilingual”全部彼此联接。如果您将“Products”模型查询作为一个整体测试，则会发现在查询的from子句中了selectPRODUCT_LINE.PRODUCT_LINE_CODEasProduct_Line_Code,PRODUCT_LINE.PRODUCT_LINE_ENasProduct_Line,PRODUCT_TYPE.PRODUCT_TYPE_CODEasProduct_Type_Code,PRODUCT_TYPE.PRODUCT_TYPE_ENasProduct_Type,PRODUCT.PRODUCT_NUMBERasProduct_Number,PRODUCT_MULTILINGUAL.PRODUCT_NAMEasProduct_NamePRODUCT_MULTILINGUAL.DESCRIPTIONasProduct_Description,PRODUCT.INTRODUCTION_DATEasIntroduction_Date,PRODUCT.PRODUCT_IMAGEasProduct_Image,PRODUCT.PRODUCTION_COSTasProduction_Cost,PRODUCT.MARGINasMarginfromgosl_82..gosl.PRODUCT_LINEPRODUCT_LINE,gosl_82..gosl.PRODUCT_TYPEPRODUCT_TYPE,gosl_82..gosl.PRODUCTPRODUCT,gosl_82..gosl.PRODUCT_MULTILINGUALPRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE"-N’EN’)and(PRODUCT_LINE.PRODUCT_LINE_CODE=PRODUCT_TYPE.PRODUCT_LINE_CODE)and(PRODUCT_TYPE.PRODUCT_TYPE_CODE=PRODUCT.PRODUCT_TYPE_CODE)and(PRODUCT.PRODUCT_NUMBER=PRODUCT_这就是最小化SQL的影响。PRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE"-N’EN")SQL，因为它可以减少某些请求中使用的表的数量并能更好地运行。在这种情况下，最好是在数据源查询之间创建关系和决定因素，包括在组中的模型查询，然后使用“StarSchemaGrou”向导。也可以创建快捷方式接至资料的安全表可能就是一个示例。在“GreatOutdoorsSales”模型中，“OrderHeader”示例，请参阅"应该在何处创建关系和决定因素？"（第15页）。IBM®Cognos®FrameworkManager从数据源导入的元数据。但是，根据您在模型中采用的控portabilityatruntime”控制规则，则FrameworkManager将始终在准备查询前查询数据源 数据的信息。如果您没有启用该控制规则，则大多数情况下，FrameworkManager 中的SQL已修改。这包括宏的使用 查询和维度用途不同。查询于生成关系查询，可使用星形模式规则创建；而维用于关系仅当您希望使用IBMCognosysisStudio、在报表中启用向上追溯和向下追溯或OLAP如，您的应用程序主要用于不需要向上追溯和向下追溯的即席查询或报表。或者您正在IBMCognosReportNet模型。在这些情况下，您可以选择仅基于查询发布数据包。查询的决定因素不同于常规维度的级别和层级，但它们可以与单层级密切相关。如果您计划将查询作为维度的基础使用，则应该考虑期望创建的层级的结构，并确保已经创建将支持聚 通过确保数据源和显示的对象之间存在模型对象（查询或维度）层，可以更好地防止从演示角度来看，快捷方式不如模型对象灵活，但其需要的却少很多，因为在目标对象更新时快捷方式也自动更新。如果是主要考虑因素并且不需要自定义查询外观，可以使用快IBM®Cognos®FrameworkManager的多重。在下面的示例中，为“Products”和“OrderTime”创建的快捷方式可用作。如果编写的查询同时从“ProductForecast”和“SalesTarget”“Products”，则查询将要为“SalesBranch”创建别名，此别名可用作“SalesBranch”层级中的一个级别。而位于模型中其他位置的快捷方式可用作对原始对象的。要利用“视为”属性，我们建议您IBMCognosIDIBMCognosFrameworkManagerID模式组的部分是将快捷方式放置在单独的名称空间内，这将为名称空间内的每个对象自动创名称空间，请使用“yzePublishImpact”来确定受影响的报表。ID文件夹以按或功能区域组织对象。这使您能够更轻松地找到元数据，尤其在大型项目中。例如，下面的“Orderdetails”资料包含关于每个订单的信息：Margin=(Revenue-Productcost)/Product12Margin=sum((Revenue-Productcost)/Revenue要产生所需的“Margin”值，我们需要在数算之前聚合：Margin=(sum(Revenue)-sum(Productcost))/sum(Revenue)Product12“RegularAggregate”属性中的指定聚合。“Revenue”和“Productcost”的“RegularAggregate”属性设置为“Sum”，因此，当执行计算时，sum用于聚合这些项目。

Margin=sum(Revenue-Productcost)/如果“Margin”建立在度量“Productcost”和“Revenue”(Sales(Sales).Productcost,Margin=sum(Revenue-Productcost)/有关如何修改查询项目聚合方式的详细信息，请参阅《IBM®Cognos®FrameworkManagerUserFrameworkManager且在情况下还会导致内存不足的情况。诸如分析发布影响、查找报表关联、发布数据包以及运行ModelAdvisor之类的操作在小于50MB的模型上可得到最佳执行效果。OLAPOLAP您希望将IBMCognosysisStudio与关系数据源一起使用，则必须使用星形模式组（具有

一层级（称为“Product”）中的级别“ProductLine”、“ProductType”和“Product”。另和“Day”YQMD“Year”、“Quarter”、“Month”和“Day”，另一个层级YWD包含级别“Year”、“Week”和“Day”。

最简单的级别定义包含业务键和标题，其中任意一项都一个查询项目。级别的实例（或行）例如，[gosales].[Products].[ProductsOrg].[Product]->[AllProducts].[1].[1].[2]标识名称空间的标题是“TrailChefCanteen”，这是在元数据树中和报表上显示的名称。Sales”模型中，“Product”级别的成员不需要“Producttype”的定义，因为不向多个不同的高粒度级别的键（第11页）。如果父成员中的成员不是唯一的，但级别定义是唯一的，则非“London,England”和“London,Canada”的数据将合并。OLAP包含资料数据的对象。度量维度不同于资料查询，因为它们不包含用于将资料查询联接至维度查询的外键。这是因为度量维度并不用于联接，就像是一个关系数据对象。为了生成查询，度量维度通过基础查询将其关系导出至常规维度。相似地，与其他度量维度的关系将通过基于查询（构建为一致维度）的常规维度。要启用多资料、多粒度查询，您必须在构建Where子句。在范围关系中没有设置控制查询生成方式的条件或标准，仅指定了在此示例中，“SalesTarget”度量维度仅有一个达到“OrderTimeDimension”的“OrderIBM®Cognos®FrameworkManager稳定的关系模型。IBMCognosReportNet复计数。在IBMCognosReportNet之后，IBMCognos软件中具有了一些数据的维度表OLAPIBMCognosReportNet中的关系建模的概念保留了下来，相关改动记录在《FrameworkManagerUserGuide》中。FrameworkManager用的步骤来定义查询生成。当您希望在IBMCognosysisStudio中使用关系数据源、在报定义按关系建模的基础（第22）如果需要，定义模型的维度表达（第27）组织模型（第30）导入元数据。有关导入的信息，请参阅《IBM®Cognos®FrameworkManagerUserGuide验证导入的元数据（第22）解析不明确的关系（第22）关系模型（第15页）。然后，您可以根据需要定义模型的维度表达（27），并组织模型进行演示（第30）。查询项目的“RegularAggregateManagerUserGuide》。关系的基数定义了一个表基于特定的键集合（或联接）与其他表的行相关联的行数。IBMCognos软件使用基数推断哪些查询可作为资料或维度。结果是当您将多个资料表联接至维度表的通用集合时，IBMCognos软件可自动解析由星形模式数据导致的常见形式的循环联接。使用FrameworkManager中的“ModelAdvisor”功能来帮助您了解基数是如何解释的。（第8）角色扮演维度（第23循环联接（第24反身关系和递归关系（第25例如，基于键“OrderDay”、“ShipDay”和“CloseDay”，“Salesfact”具有到“Time”删除导入对象、资料查询和角色扮演维度查询的关系。为每个角色创建一个模型查询主题。考虑排除不需要的查询项目以减小显示给用户的元数据树的长度。确保每个模型查询与确定在其他资料不共享相同概念的情况下如何使用这些角色。例如，“Productforecast”资料用于“Productforecast”资料。 择“CloseDay”。您可以将“ShipDay”、“OrderDay”和“CloseDay”视为可与“Productforecast”资任何数据。例如，Month_key=ShipMonthKey(200401)和Monthkey=CloseMonthKey注：当基数明确标识资料和维度时，如果您将多个资料表联接至维度表的通用集合，IBM如果出现循环联接，则问题的主要标志是定义不明确的查询。当查询定义不明确并成为反身关系和递归关系暗示了两种或多种粒度级别。IBM®Cognos®FrameworkManager导入反身关为创建功能性反身关系，您可以创建别名快捷方式（数据源查询的副本）或模型查询。然后在原始查询和新的查询之间创建关系。使用模型查询是个较好的选择，因此您可以指定在查询中包含哪些查询项目，所以这种方法有灵活性。从角度来看，快捷方式是更好的解决方案。有关详细信息，请参阅"模型对象与快捷方式"（第17页）。例如，“销售人员”查询在“Sales_Staff_Code”和“Manager_Code”

能包括由1..n关系关联的四个表。每个“ProductLine”具有一个或多个“ProductType”。每个“ProductType”具有一个或多个“Product”。“Product”具有多种语言形式的名称和描述信息，所以存在于“ProductMultilingual”查询表中。简化模型的法是为每个描述性业务概念创建一个模型查询。您的用户可能不知道独立的查询之间的关系，所以将它们分组到一起是有益的，而且还必须付出努力来扩展每个数据源通常具有包含资料的主要-明细表。例如，当使用“Orderheader”和“Orderdetails”header”和“Orderdetails”的外键，并包含“Orderdetails”级别的所有度量。该查询数据源查询的原始关系（除了定义两者之间的联接的关系外）。有关创建到模型查询的关系的利弊的讨论，请参阅"什么是最小化SQL？"（第16页）中的示例。在下面的示例中，“Orderheader”和“Orderdetails”已经合并到名为“Sales”的新模型查询中。该查询已联接至“Product”、“Time”和“Ordermethod”。IBM®Cognos®FrameworkManager当您希望在IBMCognosysisStudio中使用关系数据源、在报表中启用向上追溯和向下追溯或中的成员函数时，必须对关系数据源按维度建模。我们建议您使用关系模型作为基础层（第22），然后在定义模型的维度表达时执行以下操创建常规维度（第28）构建包含多个层级的维度的模型（第28）创建度量维度（第29）创建范围关系（第30）

然后您可以组织模型进行演示（第30）常规维度包含描述性信息和业务键信息，并将信息组织在一个层级内（从粒度的别到最低模型常规维度建立在数据源或已在模型中定义的模型查询的基础之上。您必须为每个级别定勿将模型常规维度联接至度量维度，而是基于基础查询创建联接，并在常规维度和度量维度例如，可通过“manager”或“geography”查看“salesstaff”。在IBMCognos中，这下面是作为包含两个层级的单个维度的“salesFrameworkManagerFrameworkManager用作层级基础的任意查询必须将联接定义为提供资料数据的查询。

以不能创建到模型度量维度的联接。将模型度量维度联接至常规维度，而是在基础查询

Where子句。在范围关系中没有设置控制查询生成方式的条件或标准，仅指定了创建度量维度时，IBM®Cognos®FrameworkManager径。如果有多个可用的联接路径，则FrameworkManager创建的范围关系可能不是您想要的那在完成关系建模基础（第22）和创建维度表达（第27）后，我们建议您执行以下操作 要使用IBM®Cognos®ysisStudio，则模型中必须有表达包含维度对象的元数据的名称创建星形模式组（第30）有关此处未涉及的的信息，请参阅《FrameworkManagerUserGuide》使用“StarSchemaGrou”向导快速创建快捷方式组，这将为您的用户提供关于哪些对象属能或多资料报告。有关详细信息，请参阅"多资料、多粒度查询"（第13页）。不包含度量维度或资料查询的任何项目）进行报告时，联接不明确将是个问题。这称为无资例如，“Product”和“Time”维度与“Productforecast”和“Salesfacts项目的报表？业务问题可能有，在年预测销售哪些产品或在2005年实际销售了哪些产品。虽然该查询仅涉及“Product”和对象的。注：完全相同的规则适用于常规维度和度量维度。每个星形模式具有一个名称空间，这样您的用户将明确知道要使用哪些项目。要创建关于2005第2IBMCognosIBM®Cognos®SQLSQL要另一种语言的IBMCognos元数据建模指南文档，请转至installation_location\c10\ ation并打开所需语言的文件夹。然后打开ug_best.pdf。避免重复计数。在某些情况下，可能需要为基础查询创建决定因素。

数据更有意义。维度和资料之间的所有关系是1-n。LicensedMaterials–Propertyof©CopyrightIBMCorp.2005, 例如，“Sales”和“ProductForecast”20042，CourseProUmbrellas“Sales”和“ProductForecast”中的数据存在于不同的粒度级别。“Sales”中的数据位于“Day”级别，而“ProductForecast”位于“Month”级别。selectcoalesce(D2.MONTH_NAME,D3.MONTH_NAME)asMONTH_NAME, PRODUCT_NAME)asPRODUCT_NAME,D2.EXPECTED_VOLUMEasEXPECTED_VOLUME,D3.TYasTYfrom(selectTIME.MONTH_NAMEasMONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAMEasPRODUCT_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUMEforTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY)asEXPECTED_VOLUMEfrom (selectTIME.CURRENT_YEARasCURRENT_YEAR,TIME.QUARTER_KEYasQUARTER_KEY,TIME.MONTH_KEYasMONTH_KEY,XMIN(TIME.MONTH_NAMEforTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY)asMONTH_NAMEfromTIME_DIMENSIONTIMEgroupbyTIME.MONTH_KEY)TIMEjoinPRODUCT_FORECAST_FACTPRODUCT_FORECAST_FACTon(TIME.MONTH_KEY=PRODUCT_FORECAST_FACT.MONTH_KEY)joinPRODUCTPRODUCTon(PRODUCT.PRODUCT_KEY=KEY)where(PRODUCT.PRODUCT_NAMEin('AloeRelief','CourseProUmbrella'))and(TIME.MONTH_NAMEin('April2004','February2004','February2006'))groupbyTIME.MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME)D2fullouterjoin(selectTIME.MONTH_NAMEasMONTH_NAME,PRODUCT_LOOKUP. PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE, MONTH_ENasMONTH_NAME fromTIME_DIMENSIONTIME)TIMEjoinSALES_FACTSALES_FACTonFACT.PRODUCT_KEY)where PRODUCT.PRODUCT_NAMEin('AloeRelief','CourseProUmbrella'))and(TIME.MONTH_NAMEin('April2004','February2004','February2006'))groupbyTIME.MONTH_NAME,PRODUCT.PRODUCT_NAME)D3on((D2.MONTH_NAME=D3.MONTH_NAME)and (D2.PRODUCT_NAME=coalesce语句只是一种处理来自一致维度的查询项目的有效方式。它用于接受从任一查询返回的第一个非Null值。执行完整的外部联接时，该语句可产生不包含重复项的完整键列表。有销售额的所有产品。完整的外部联接是了解库存中有什么产品以及已售出什么产品的唯一1-n1-11-n1-1SQL为IBM®Cognos®软件提供的信息不够充分。1-n1-1如果已将基数修改为仅在查询或维度之间使用1-1关系，则使用“Time”或“Time”与“Product”对“ProductForecast”和“Sales”Select语句，该语句将删除一个联接以避免循环。的必要关系）。在此示例中，“Time”和“ProductForecast”之间的关系被删除。 TIME_.MONTH_NAMEasMONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAMEasPRODUCT_NAME,XSUM(SALES_FACT.TYforTIME_.CURRENT_YEAR,TIME_.QUARTER_KEY,TIME_.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY)asTY,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUMEforTIME_.CURRENT_YEAR, TIME_.QUARTER_KEY,TIME_.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY)asEXPECTED_VOLUME (selectTIME.DAY_KEY,TIME.MONTH_KEY,TIME.QUARTER_KEY,TIME.CURRENT_YEAR,TIME.MONTH_ENasMONTH_NAMEfromTIME_DIMENSIONTIME)TIMEjoin SALES_FACTon(TIME_.DAY_KEY=SALES_ PRODUCT_FORECAST_FACTon(TIME_.MONTH_KEY= PRODUCT(PRODUCT.PRODUCT_KEY=PRODUCT_FORECAST_FACT.PRODUCT_KEY)where(PRODUCT.PRODUCT_NAMEin('AloeRelief','CourseProUmbrella'))and(TIME_.MONTH_NAMEin('April2004','February2004','February2006'))groupbyTIME_.MONTH_NAME,PRODUCT.PRODUCT_现在，从“ProductForecast”返回的行与从“Sales”返回的行之间存在1-n关系。回了行，并且多个“OrderMethod”间有重复的“ExpectedVolume”结果。向查询添加1-n关系。不可能再将“ExpectedVolume”的单个值关联至“ty”中的一个值。为此示例生成的接合SQL与多资料、多粒度查询（第34页）中生成的SQL非常相似。主要 D2.TYasTY,D3.EXPECTED_VOLUMEasEXPECTED_VOLUME,coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME)as coalesce(D2.MONTH_NAME,D3.MONTH_NAME)asD2.ORDER_METHODasORDER_METHODfrom PRODUCT.PRODUCT_NAMEasPRODUCT_NAME,TIME.MONTH_NAMEasMONTH_NAME,ORDER_METHOD.ORDER_METHODasORDER_METHOD,XSUM(SALES_FACT.TYforTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY,ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY)asTYfrom PRODUCT_DIMENSIONPRODUCTjoinSALES_FACTSALES_FACTon(PRODUCT.PRODUCT_KEY=SALES_FACT.PRODUCT_KEY)join ORDER_METHOD_DIMENSIONORDER_METHODon(ORDER_METHOD.ORDER_METHOD_KEY=SALES_FACT.ORDER_METHOD_KEY)joinTIME_DIMENSIONTIMEon(TIME.DAY_KEY (TIME.MONTH_NAMEin('April2004','February2004','February2006'))groupbyPRODUCT. )D2 fullouterjoin(selectPRODUCT.PRODUCT_NAMEasPRODUCT_NAME,TIME.MONTH_NAMEasMONTH_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUMEforTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY)asEXPECTED_VOLUMEfromPRODUCT_DIMENSIONPRODUCTjoin PRODUCT_FORECAST_FACTPRODUCT_FORECAST_FACTon(PRODUCT.PRODUCT_KEY=PRODUCT_FORECAST_FACT.PRODUCT_KEY)join(select TIME.CURRENT_YEARasCURRENT_YEAR,TIME.QUARTER_KEYasQUARTER_KEY,TIME.MONTH_KEYasMONTH_KEY,XMIN(TIME.MONTH_NAMEforTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY)asMONTH_NAMEfromTIME_DIMENSIONTIMEgroupbyTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY)TIMEon=PRODUCT_FORECAST_FACT.MONTH_KEY)where(PRODUCT.PRODUCT_NAMEin('AloeRelief','CourseProUmbrella'))and(TIME.MONTH_NAMEin('April2004','February2004','February2006'))groupbyPRODUCT.PRODUCT_NAME,TIME.MONTH_NAME)D3on((D2.PRODUCT_NAME=D3.PRODUCT_NAME)and(D2.MONTH_NAME=D3.MONTH_NAME))如果某查询与其他查询间同时具有1:n和1:1关系，则认为该查询定义不明确。从查询生成角度来看，定义不明确的查询并不总是有害的。我们建议您使用以下实例评估查询。此评估的目标在于避免不必要的查询拆分，并确保发生的任何拆分是有意为之的并且是：“Productline”和“Product“Productline”、“Producttype”乘“Productline”、“Producttype”、“Product“Productline”和“Producttype”和“Product“Product所有关系中n方的查询均视为资料。我们可以发现，在以下示例中“OrderHeader”和“CountryMultilingual”用作资料。实际上，“CountryMultilingual”查询仅包含描述SQL询。包装查询必须在一致维度上包含coalesce语句。SQLcoalesceRSUMselectD3.COUNTRYasCOUNTRY,D2.CITYasCITY