按照以下的规则来保障颗粒数据，灵活性和适应未来的信息资源。如果违反这些规则，用户会感到迷惑。

    规则一：向空间结构中加载详细原数据

    空间模型中应该加入原数据的细节以支持不可预测的过滤和商业用户查询时的分组要求。用户一般不需要一次看到单个记录，但是你不能预测他们希望显示的方式然后显示出细节信息。如果只能获取摘要数据，那么你已经对数据的使用模式作出了推测，而这些推测将在永固想深挖细节的时候导致他们碰壁。当然，原数据可以被简要的空间模型来补充，这些模型提供了汇总数据中共同查询的优势，但是商业用户不能仅仅依赖于这些简要数据，他们还需要数据细节来回答不断变化的问题。

    规则二：机构化空间模型和业务流程

    业务流程是你所在的机构所执行的活动；他们代表了测量活动，如采取命令。业务流程通常会捕获（如何处理SSIS 2008中的变更数据捕获）或生成与每个事件相关的独特数据。每个业务流程都由一个单独的原事实表格代表。除了单一处理事实表格，合并的事实表格有时候也会从多流程到某一事实表格的过程中产生。同样，合并的事实表格是对详细单一进程事实表格的补充，而不是要取代他们。

    规则三：确保每个事实表格都具备相关数据维度表

    规则二中介绍的测量事件通常拥有一个与其相关的变量日期标记。每个事实表格都至少应该具备一个与日期维度表相关的外关键字（三个关键字实现JAVA类的隐藏），其粒度是单独的一天，具有日历属性和测量事件日期的非标准特性，如财政月和企业假日指示等。有时候多个日期外关键字会在事实表中有所表现。

    规则四：确保单一事实表中的事实都具备相同粒度或同样的细节

    有三个基本粒度可以对所有事实表格进行分类：交换性，周期性快照或积累快照。不论粒度的类型是什么，每种包含了事实表的测量都必须具备同一水平的细则。当你混合那些代表多层次粒度的事实时，你就会让业务用户感到迷惑不解，会使BI（SQL Server 2008 BI的核心元素）应用变得很容易出错。

    规则五：解决事实表中多对多的关系

    由于事实表保存了业务进程活动的结果，那么其外关键字之间就固然会存在多对多的关系，如多个产品在若干日的时间里在多个商店出售。这些外关键字的域不应该为空值。有时候维度可以为单个测量事件获取多个值，如与卫生保健相关的多项诊断或是银行账号的多个用户。在这些举例中，要在事实表中直接解决有多值层面是不合理的，因为这样会违背测量事件的自然粒度。因此，我们要使用多对多，将双键桥表和事实表结合使用。

    规则六：解决维度表中多对一的关系

    属性之间层次化，固定深度的多对一关系通常是非正规化的维度表。如果你已经花了大量时间用于设计交易处理系统的实体关系模型，你就需要抵制本能的倾向，然后将多对一的关系转为更小的层级，层级非规格化是空间建模中的一个名词。

    在单个维度表中存在多对一关系是常见现象。一对一的关系，如与某产品代码相关的产品描述，也可以在维度表中进行处理。偶尔，多对一关系会在事实表中解决，如当详细维度表中有上百万的行数时，由此而产生的属性会频繁发生改变。但是，使用事实表来解决多对一的关系应该有节制的使用。

    规则七：在维度表中保存报告标签并过滤域值

    代码，更重要的是用于标记和查询过滤的相关解码和描述符应该在维度表中被捕捉到。要避免在事实表中保存隐蔽代码域或冗繁的描述域，同样，不要只是在维度表中保存代码并假设用户不需要描述型解码或这些解码应该在BI应用中得到处理。如果是一个 行/列标签或下拉菜单过滤器，那么它应该作为维度属性来处理。

    虽然，我们在规则五中已经讲过事实表的外关键字不应该为空值，但是我们也建议大家可以用“NA”（not applicable）或另一默认值来替代“Null”以避免在维度表的属性域中出现空值。

    规则八：弄清楚维度表使用的是代理键

    按顺序分配的替代键带来了一系列的好处，包括更小的键，这意味着更小的事实表，更小的指示以及改进的性能。如果你正追踪随着每个配置文件的更改而变化的维度属性，那么你肯定需要代理键。即便你的商业用户没有在最初发现追踪属性变更的价值，代理键的使用会使下游策略的改变更宽松。代理键还可以让你把多个操作键映射到公用参数文件中，再加上从意料之外的操作中进行缓冲等。

    规则九：创建认可层级以便在企业中整合数据

    认可层级（也称为通用，标准或参照层级）对于企业数据库很有必要。只需在ETL系统中管理一次，就可以在多个事实表中重复使用。认可层级在维度模型方面与描述型属性一致，可以支持多个业务流程中的数据整合。企业数据库总线矩阵（EDWBM）是代表了该企业核心业务路程和相关维度的关键架构蓝图。重复使用认可层级最终可以消除冗繁的设计和开发过程，从而缩短产品上市时间。但是认可层级要求在数据管理和治理上给予承诺和投资。

    规则十：平衡请求与现实以给出DW/BI方案

    空间建模者必须不断在商业用户的请求以及与源数据相关的潜在现实之间进行跨越，以便设计出既能被执行又可以被接受的合理方案。无论你侧重的是空间模型，项目策略，技术型/ETL/BI架构 或 部署/维护计划，请求与现实之间的平衡都是DW/BI之间的生动演绎。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。