程序空间建模的八大规则将向你呈现的是一些自然规律，那么我们如何掌握和运用好呢？首先我们来看他们各自的特点：
程序空间建模规则一：向空间结构中加载详细原数据
空间模型中应该加入原数据的细节以支持不可预测的过滤和商业用户查询时的分组要求。用户一般不需要一次看到单个记录，但是你不能预测他们希望显示的方式然后显示出细节信息。如果只能获取摘要数据，那么你已经对数据的使用模式作出了推测，而这些推测将在永固想深挖细节的时候导致他们碰壁。当然，原数据可以被简要的空间模型来补充，这些模型提供了汇总数据中共同查询的优势，但是商业用户不能仅仅依赖于这些简要数据，他们还需要数据细节来回答不断变化的问题。
程序空间建模规则二：机构化空间模型和业务流程
业务流程是你所在的机构所执行的活动;他们代表了测量活动，如采取命令。业务流程通常会捕获（如何处理SSIS 2008中的变更数据捕获）或生成与每个事件相关的独特数据。每个业务流程都由一个单独的原事实表格代表。除了单一处理事实表格，合并的事实表格有时候也会从多流程到某一事实表格的过程中产生。同样，合并的事实表格是对详细单一进程事实表格的补充，而不是要取代他们。
程序空间建模规则三：确保每个事实表格都具备相关数据维度表
规则二中介绍的测量事件通常拥有一个与其相关的变量日期标记。每个事实表格都至少应该具备一个与日期维度表相关的外关键字（三个关键字实现JAVA类的隐藏），其粒度是单独的一天，具有日历属性和测量事件日期的非标准特性，如财政月和企业假日指示等。有时候多个日期外关键字会在事实表中有所表现。
程序空间建模规则四：解决事实表中多对多的关系
由于事实表保存了业务进程活动的结果，那么其外关键字之间就固然会存在多对多的关系，如多个产品在若干日的时间里在多个商店出售。这些外关键字的域不应该为空值。有时候维度可以为单个测量事件获取多个值，如与卫生保健相关的多项诊断或是银行账号的多个用户。在这些举例中，要在事实表中直接解决有多值层面是不合理的，因为这样会违背测量事件的自然粒度。因此，我们要使用多对多，将双键桥表和事实表结合使用。
程序空间建模规则五：解决维度表中多对一的关系
属性之间层次化，固定深度的多对一关系通常是非正规化的维度表。如果你已经花了大量时间用于设计交易处理系统的实体关系模型，你就需要抵制本能的倾向，然后将多对一的关系转为更小的层级，层级非规格化是空间建模中的一个名词。
在单个维度表中存在多对一关系是常见现象。一对一的关系，如与某产品代码相关的产品描述，也可以在维度表中进行处理。偶尔，多对一关系会在事实表中解决，如当详细维度表中有上百万的行数时，由此而产生的属性会频繁发生改变。但是，使用事实表来解决多对一的关系应该有节制的使用。
程序空间建模规则六：在维度表中保存报告标签并过滤域值
代码，更重要的是用于标记和查询过滤的相关解码和描述符应该在维度表中被捕捉到。要避免在事实表中保存隐蔽代码域或冗繁的描述域，同样，不要只是在维度表中保存代码并假设用户不需要描述型解码或这些解码应该在BI应用中得到处理。如果是一个 行/列 标签或下拉菜单过滤器，那么它应该作为维度属性来处理。
虽然，我们在规则五中已经讲过事实表的外关键字不应该为空值，但是我们也建议大家可以用“NA”(not applicable)或另一默认值来替代“Null”以避免在维度表的属性域中出现空值。
程序空间建模规则七：弄清楚维度表使用的是代理键
按顺序分配的替代键带来了一系列的好处，包括更小的键，这意味着更小的事实表，更小的指示以及改进的性能。如果 你正追踪随着每个配置文件的更改而变化的维度属性，那么你肯定需要代理键。即便你的商业用户没有在最初发现追踪属性变更的价值，代理键的使用会使下游策略的改变更宽松。代理键还可以让你把多个操作键映射到公用参数文件中，再加上从意料之外的操作中进行缓冲等。
程序空间建模规则八：创建认可层级以便在企业中整合数据
认可层级(也称为通用，标准或参照层级)对于企业数据库很有必要。只需在ETL系统中管理一次，就可以在多个事实表中重复使用。认可层级在维度模型方面与描述型属性一致，可以支持多个业务流程中的数据整合。企业数据库总线矩阵(EDWBM)是代表了该企业核心业务路程和相关维度的关键架构蓝图。重复使用认可层级最终可以消除冗繁的设计和开发过程，从而缩短产品上市时间。但是认可层级要求在数据管理和治理上给予承诺和投资。
程序空间建模的八大规则向你介绍完了，是不是对程序空间建模有更深入的理解呢?赶紧动手实践吧。
【编辑推荐】
