Cognos Framework Manager 元数据建模工具讲解.ppt

* 我们可以合并 ORDER_HEADER和ORDER_DETAILS创建一个可用的事实查询主题的基础。然而，不是所有的ORDER_HEADER查询项，都应该放进新的查询主题。 删除任何代表维度信息的查询项，并隐藏那些报表制作者可见的事实的键。这使新的查询主题象在星型结构数据仓库中一个“真”的事实表。 还可以组织ORDER_DETAILS和ORDER_HEADER 为 Order Details 维度和ORDER_METHOD在一个新的名字空间以保持相似的对象在一起而简单化输入视图。 * 因为RETURNED_ITEM 与 ORDER_DETAILS紧密相关，当依靠其它维度（如Product 维度）查询RETURNED_ITEM时，我们怎样确保预期的结果?当前RETURNED_ITEM和 Product 维度之间没有关系。 RETURNED_ITEM 不包括 PRODUCT_NUMBER. 我们可以改变查询主题的SQL包含所有需要的键，因此我们可以创建 RETURNED_ITEM 和所有需要维度之间的关系。 因为退货和订单的关系紧密，它们需要有同样的与作为订货维度的关系。 这样能够提供给有写逻辑报表能力的报表制作者，在没有包括订单信息的情况下得到退货的结果，如“哪些产品被退货？”。 为了建立RETURNED_ITEM与所有需要的维度之间的关系，可以创建一个模型查询主题或改变数据源查询主题的SQL以包含所有需要的键。 * 确定用于报表目的需求的ORDER_HEADER中的查询项，如ORDER_NUMBER和RETAILER_NAME 。 我们可以安置ORDER_HEADER中剩余的需求项到Order Details Dimension 中。通过把查询项放置到一个逻辑位置，并确定这些维度查询项在最终的模型展示中没有丢失，来创建一个“纯”维度。 报告也可能需要ORDER_DETAIL_CODE。我们可以选择把它放在Orders Fact 模型查询主题中使它生效，或更适合它放在一个和它有同样描述信息的查询主题中。 添加ORDER_NUMBER, RETAILER_NAME和RETAILER_NAME_MB到 Order Details Dimension解决ORDER_HEADER作为一个模糊查询主题产生的问题。所有的项除了RETAILER_NAME之外，现在已经成功地放在更适当的查询主题中。该信息在另一个数据库中 (GO Retailers)被发现，如果需要的话，现在可以连接 Orders Fact 和 RETURNED_ITEM 查询主题。 Also when a query is written using the Orders Fact and RETURNED_ITEM along with ORDER_NUMBER, a stitch query is forced and the correct results are returned. Adding the dates to the Order Details Dimension is not an ideal solution. Date and time data should be stored in a Time Dimension table to which all fact tables would join to through time keys. * It is possible to model a transactional database for predictable queries and results A combination of business and dimensional approach works to simplify the model for end users So, hopefully we have given you a good idea of the basics of building a reporting model on a transactional database. It is very important to understand that transactional systems are not designed for reporting. These structures are optimized for rapid insert and update, not reading. As such you will always have a very complex data view and many joins that must be