实事表的基本结构
每一个事实表通过表的粒度来定义。粒度必须按照现实的，物理的意义来定义，然后考虑纬度和事实表中的其他字段等因素。所有的事实表包含了一组关联到维表的外建，而这些维表提供了事实表度量的上下文。
如果设计的时候没有给与足够的注意，那么就有可能违反事实表上主见的假设，可能在同一时段两个同样的度量事件会发生，但是数据仓库团队没有意识到这一点，显然，每个事实表应该拥有一个主建，即使仅仅是出于管理的需要也应该在事实表上设立主见。如果没有主键完整性，那么事实表中有可能存在两个或者更多一样的记录，而且没有办法按照独立的量测事件来区分他们。
确保参照完整性
在维度模型中可能有两种情况会导致违反参照完整性：
1.加载包含了错误外键的事实表记录
2.删除了维表记录，而其主键在事实表中被使用。
从实践角度来讲，第一个选择更加可行。在数据加载到事实表中最后一步就是查找事实表记录中的自然外键，然后将他们替换成为维表中的代理键。这个过程将在下一节代理键环节中仔细地介绍。这个过程的核心是一个特殊的查找表，它包含了每一个外来的自然键所使用的代理键的值。如果这张表被正确的维护，那么事实表中的记录将满足参照完整性。同样在维表记录被删除的时候也需要尝试联结事实表和维表，只有在查询返回null 的时候才能够删除该记录。
代理建管道
我们理论上可以通过在每个维表中获取最新的记录来为自然键获得当前的代理键，这在逻辑上是正确的，但是很慢。替代方法是为每一个维度维护一个专门的代理键查找表。这张表在新的维度实体创建的时候或者记录在发生类型2 缓慢变化维度2 的更新的时候被更新。
维表在插入或者缓慢变化维度2 更新发生之后，在处理事实表之前，这个维表必须被完全的更新。在更新事实表之前的维表更新过程是维护维表和事实表参照一致性的一般过程。反向的过程在删除记录的时候发生，首先我们删除不需要的事实表记录，然后删除不再联结到事实表的维度记录。
基础粒度
事实表存储了企业中的数值度量，事实表可以归入三种基础类型，这三种事实表类型是：交易粒度，周期快照，聚合快照。交易粒度是在特定的时间，空间上的一次瞬间的测量。周期快照事实表表现的是一个时间段或者规律性的重复。聚合快照事实表用于描述那些有明确开始和结束的过程。
装载数据：单独处理数据插入，利用批量加载工具，并行的加载，最小化物理更新，在数据库外进行聚合
增量装载：增量加载用于周期性的加载，目的是同步数据仓库和相应的源系统。
优化更正
维度模型的一个最重要的特点是可以在不影响最终用户查询或者应用的前提下，对最终发布的框架进行一系列的大的修改，我们把这称之为优化更正。这是维度模型世界和规范化模型世界的最根本的区别，在后者这些修改将导致应用停止工作，因为物理框架被改变了。对维度框架的四种类型的优化更改：1 对已经存在的事实表中增加同一粒度的事实2 在已经存在的事实表中增加同一粒度的维度 3 在已经存在的维度中增加属性 4 增加已经存在的事实表和维度表的粒度的大小
事实表中的多个度量单位
例如，制造业主管希望按照车皮或者集装箱来考察整个生产流程，而店铺主管需要按照运输包装、零售包装、销售单位或者购买单位（弹片的口香糖）查看数据。类似的，相同数量的产品可能有几种不同的计价，可能需要按照供货价格、列表价格、初始报价、最终价格来显示。这种需求，最终会导致对于每一条事实记录可能有多个基础数量。
一种错误的做法是事实表中建立13 个数量事实，然后由用户或者应用开发者在维表中查找正确的转换因子，尤其是当用户利用事实表，不使用关联得到的不同时间点，然后用时间去查询产品维表的时候。另外将所有的事实组合按照不同的单位存储在主事实表中也是一种错误的做法，那样每条记录需要10*5+10*4=90 个事实列！正确的折衷办法是建立有10 个数量事实、4个单位转换因子和5 个作价因子的底层事实表。这里我们仅仅需要4 个转换因子，而不是5个，因为基础事实已经按照其中的一种单位表示了，其他更大或者更小的单位仅仅需要通过乘法或者除法就可以得到。
当需要增加一个新的产品记录来反映这些因子（尤其是成本和价格）的微小变化的时候，在事实表中如此的封装事实可以降低对产品维度的压力。从变化的角度来看，这些因子更像事实，而非维度实体。
迟到的事实
在客户购买情境中，假设我们收到一个几个月前的购买记录，在决大多数操作型数据仓库中，我们希望将这个迟到的记录插入正确的时间位置，包括改变前面月份的销售汇总。但是我们必须为这条购买记录仔细地选择当时的维表记录。如果我们已经在类型2 的缓慢变化维中为记录加了时间戳。处理过程中包括如下的步骤：1、在每个维度中，找出购买发生时的对应的维表记录2、使用上一步中的维表记录对应的代理键替换迟到的记录中的自然键3、将迟到的事实记录插入相应的数据库物理分区，该分区中包含了其他的同期的事实记录。
聚合
在大型数据仓库中建立聚合的目的不仅仅是为了提升性能，一个好的聚合应该：1、为尽可能多类型的用户查询提供较好的性能2、在仓库中仅仅增加合理数量的额外存储。所谓合理是从DBA 的观点出发，但是大多数的数据仓库DBA 按照小于等于2 的因子来控制增加的磁盘存储。3、除了明显的性能提升，性能对于最终用户和应用开发者是透明的。换句话说，没有任何最终用户应用的SQL 会直接引用聚合表！不管用户使用的是什么查询工具，都可以利用聚合的优势。4、尽可能降低数据抽取系统的成本。当每次数据加载的时候，多数聚合表不可避免地会被重建，但是应该做到尽可能的自动化5、尽可能的降低DBA 管理的责任。通常支持聚合的元数据应该数量有限且易于维护。大多数的元数据应该通过监控用户查询自动的创建，并给出创建新聚合表的建议。
设计需求1：聚合信息必须存储在他们自己的表中，和基础粒度的数据分离。每个不同的聚合级别必须使用他们自己独自的事实表。
设计需求2：无论什么情况，聚合表所使用的维表应该是基础事实表所使用维度的缩小版本。
设计需求3：基础的事实表以及所有相关的聚合表可以作为一个框架组（a family of schemas）关联在一起，以便聚合导航理解表之间的相互关系。
设计需求4：强制任何最终用户或者应用者的SQL 仅仅使用基础的事实表和关联的完全的维表。
总结：
在本章中，我们把事实表定义为含有企业数字度量的命脉。所有的事实表记录都包括两个主要部分：描述度量上下文的关键字以及我们叫做事实的度量本身。然后我们描述了事实表提供者的关键角色，它把事实表发布给出来供其它人使用。我们发现参考完整性对于维度结构是非常重要的要求，同时我们还建议了三个强制参考完整性的位置。然后我们描述了如何为数据仓库创建代理键通道pipeline，以便准确跟踪维度实体的历史变化。我们描述了三种类型的事实表结构：交易粒度、周期快照粒度和聚合快照粒度。按我们的经验，这三种粒度满足了所有可能的度量条件下的模型。永远不要把不同粒度的度量放到一个事实表中，以免可能把结果复杂化。坚持这一方法可以简化应用开发，另外也可以让最终用户更易理解数据的结构。我们还提供了一些用于处理问题的特殊技术的建议，包括灵活修改事实表和维表、度量的多单位、迟到事实数据以及创建聚合等。我们以装载OLAP 立方体这一特定部分作为本章的结尾，这是关系型维度结构的近亲。在本章中，我们描述了数据仓库ETL 系统的四个主要步骤：抽取、质量保证、规范化以及结构化数据，从而生成维度结构供最终用户使用。在接下来的第7 章和第 8 章中，我们会涉及在创建ETL 系统过程中最常用到的软件工具，以及如何调度运行这样复杂的系统。