1.验证查询项目的属性
对象属性允许你添加额外的信息,诸如描述和屏幕提示,查询项目属性可以允许你编辑查询项目的行为,诸如配置数据的格式.在导入完模型后,需要检查以下两个属性:
(1)用途属性(Usage property)
Facts(资料):Numeric(数值),time-interval(时间间隔),非索引列 .
Identifiers(标识):Key(键),索引,日期,时间,任何索引列.
Attributes(属性):字符串,BLOBS.
Unkown（未知）：当模型设计开发者不能确定数据的角色时使用
(2)常规聚合属性(Regular Aggregate properties)
数值资料(numeric facts)的常规聚合属性描述了方法怎样被聚合,默认是SUM.
(3)还有一个需要充分利用的属性集是Prompt info(提示信息)
Prompt Type(提示类型): 我们可以在studios中制定我们想要产生的提示类型,或者用它默认的提示类型.默认是服务器基于数据类型来决定提示类型.
其余的属性在通过索引进行自动检索的时候用来改善性能,同时还可以以用户友好的方式来显示选择的值.
Cascade on Item Reference(关于项目引用的层叠):用于RS中的层叠提示。
Display Item Reference(显示项目引用):用于标识默认值，即一个人为创建的RS提示值用于显示一个特定查询项目。将当前列的值显示对应的其它列的值；
Use Item Reference(使用项目引用)：用于标识默认值，即在查询过滤器中人为创建的RS提示所使用的值。当前显示的值需要对应成其它的值，使用其对应的值来操作。
Filter Item Reference(过滤器项目引用)：用于标识默认值，即一个IBM Cognos产生的提示用此值来过滤一个查询。在QS中显示的值但在查询过滤器中却要使用其对应的其它列值。
2.检查关系
关系是在Object Diagram或者Context Explore中被维持的。 当验证关系的时候，你需要确保适当的关系存在以满足你的报表需要，并且你需要确定是否你需要可选或者强制性的基数。选择性的基数要求更多的过程但是很可能返回期望的结果。
Optional cardinality（选择性基数）：在sql中产生一个外连接，表现为0，0..n或者0..1。
Mandatory cardinality（强制性基数）：在sql中产生一个内连接，表现为1，1..n或者1..1。
Cardinality（基数）：在IBM Cognos BI中用来决定哪些查询对象是Facts（事实），哪些是在一个查询的上下文中的维度。这个决定是重要的,特别是,当通过共享维度来查询来自多个fact表的时候。通过识别哪些查询主题是facts,IBM Cognos BI能够适当地聚合这些facts并且不会丢失任意fact表的记录，所谓的基数就是表与表之间的记录对应关系。
按照星型模式来建模是很重要的，这是由于它可以保证一个查询主题的本质没有歧义。简单的说就是Fact查询主题只可以附加1..n或者0..n基数，而dimension(维度）查询主题只可以附加1..1或者0..1基数。
3.关于事实表和维度表，首先需要了解一下数据仓库中关系模型和维度模型之间的联系与区别。
关系模型主要应用于事务性数据库，在数据仓库领域的倡导者是Inmon ，是以遵循第三范式（3NF）为基础的关系模型，从ER图的“观感”上来说，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。在Inmon的理念中，DW（数据仓库）并不直接用于DSS/BI等应用，而是作为一个平台，其模型为3NF关系模型，对于更上层的应用，通过建立小的数据集市或其他方式（这时候可以用维度模型），来满足具体的应用要求——即数据仓库作为数据集市的数据源，数据集市来满足具体应用（如BI、DSS）的需求。
维度模型尽管底层本质在物理实现上还是表和关系，但模型概念上有了一定的抽象，表分为维度表和事实表两种，事实表中以数字型为主，包含了度量信息，而维度表常以文本类型为主，常常被作为事实表的“上下文”，为那些度量数值添加了业务意义。维度模型具有更强的业务意义，每个表囊括了某主题的（几乎）全部信息，符合同一个主题的维度（事实表）数据，往往被统一整合（Conform）到一个维表（事实表）中，表的数量较之关系模型要少些。在数据仓库领域的倡导者是Kimball。
验证查询项目的属性和关系