事实表代理键
代理键可用作所有维度表的主键。不与任何维度关联的事实表代理键，是在ETL加载过程中顺次分配的，可用于作为事实表的唯一主键列；在ETL中，用作事实表行的直接标识符，不必查询多个维度；允许将事实表更新操作分解为风险更小的插入和删除操作。
蜈蚣事实表
一些设计者为多对一层次的每层建立不同的规范化维度，例如，日期维度、月份维度、季度维度和年维度，并将所有外键包含在一个事实表中。这将产生蜈蚣事实表，包含维度相关的多个维度。应该避免使用蜈蚣事实表。所有这些固定深度的、多对一层次化关联的维度都应该回到它们最细节的粒度上，例如，上例中提到的日期。当设计者将多个外键嵌到单一低粒度维度表中，而不是建立杂项维度时，也会产生蜈蚣事实表。
属性或事实的数字值
典型的实例是产品的标准价格。如果该数字值主要用于计算目的，则可能属于事实表。如果该数字值主要用于确定分组或过滤，则应该将其定义为维度属性，离散数字值用值范围进行补充。某些情况下，将数字值既建模为维度又建模为属性值是非常有益的。
日志/持续时间事实
累积快照事实表获取多个过程里程碑，每个都包含日期外键并可能包含日期/时间戳。商业用户通常希望分析这些里程碑之间的滞后及延迟时间。有时这些延迟仅仅是日期上的差异，但某些情况下，延迟可能基于更复杂的业务规则。如果流水线包含大量的步骤，则可能存在上百个延迟。与其要求用户查询通过日期/时间戳或者日期维度外键计算每个可能存在的延迟，不如根据过程的开始时间点为每个度量步骤存储一个时间延迟。这样做可以方便的通过利用存储在事实表中的两个延迟，简单的用减法计算任何两个步骤间可能存在的延迟。
头/行事实表
操作性交易系统通常包括事务头指针行，头指针行与多个事务行关联。采用头/行模式（也称父/子模式），所有头指针级别维度外键与退化维度应该被包含在行级别事实表。
分配的事实
头指针/行事务数据与对应的事实具有不同粒度这样的情况经常发生，例如，头表示货运费用。应该尽量分配头指针事实，是其基于业务所提供的规则划分为行级别，分配的事实可以按照所有维度进行分片并上钻操作。多数情况下，可避免建立头指针级别的事实表。除非这样的聚集能够获得查询性能的改善。
利用分配建立利润与损失事实表
事实表揭示利润等价方程是企业DW/BI应用能够发布的最强大的结果。利润方程是：收入-开销=利润。理想的实现利润方程的事实表应为原子收入事务力度并包含许多开销项。因为这些表处于原子粒度，才能实现数字化的上卷，包括客户利润，产品利润，促销利润，渠道利润等。然而，建立这些事实表存在一定难度，因为开销项必须从其原始来源划分到事实表粒度。这一分配步骤通常由ETL子系统完成，这一过程是一个与业务相关的步骤，需要高层经理的支持。出于以上原因，利润与损失事实表通常在DW/BI程序的早期实现阶段不会被处理。
多种货币事实
以多种货币单位记录财务的事实表行应该包含一对列。其中一列包含以真实币种表示的事实，另外一列包含同样的，但以整个事实表统一的单一标准币种表示的事实。标准币种值在ETL过程中按照规定的货币转换规则建立。该事实表也必须有一个货币维度用于区分事务的真正货币。
多种度量事实单位
如果事实表包含大量事实，而每个事实必须以所有度量单位表示，此时比较好的方法是将事实以公认的标准度量单位存储，同样存储标准度量与其他度量的转换系数。这种事实表可按照不同用户的观点部署，使用适当选择的转换系数。转换系数必须存储在事实表行中以确保计算简单正确，并尽量降低查询复杂性。
多遍sql以避免事实表间的连接
BI应用绝不应该跨事实表的外键处理两个事实表的连接操作。在关系数据库中，控制此类连接操作的回答集的基数是不可能的，将会产生不正确的结果。例如，如果两个事实表包含客户产品出货和返回，则这两个表不能按照客户和产品外键直接连接。要采用跨钻方式使用两个事实表，并对结果按照公共行头指针属性值，进行排序-融合以产生正确的结果。
针对事实表的时间跟踪
存在三种基本事实表粒度：事务级别、周期快照、累积快照。个别情况下，在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的，与采用缓慢变化维度，在事实行有效时获取时间的方式类似。尽管不太常用，但是该模型能够解决诸如缓慢变化库存平衡的场景，其中频繁周期快照可以在每个快照上加载同一行。
迟到的事实
迟到事实是指如果用于新事实行的多数当前维度内容无法匹配输入行的情况，这通常发生在当事实行延迟产生时，在此情况下，当迟到度量事件出现时，必须搜索相关维度以发现有效的维度键。
