本章接第2章 Kimball维度模型技术概述（二）
多种货币事实
以多种货币单位记录财务事务的事实表行应该包含一对列。其中一列包含以真实币种表示的事实，另外一列包含同样的，但以整个事实表统一的单一标准币表示事实。标准币种在ETL过程中按照规则的货币转换规则建立。该事实表必须有一个货币维度用于区分事务的真正货币。
多种度量事实单位
某些业务过程需要同时以多种单位表示。（如：供应商可能需要对相同事实以平台、船运、零售以及单个扫描单元构建报表。）这种事实表可按照不同用户的观点部署，使用适当选择的转换系数。转换系数必须存储在事实表行中以确保计算简单正确，并尽量降低查询复杂性。
年-日事实
商业用户在事实表中通常需要年-日（year-to-date，YTD）值。一种更可靠、可扩展的处理这些请求的方法是在BI应用或OLAP多维数据库中计算YTD矩阵，而不是在事实表中查出YTD事实。
多遍SQL以避免事实表间的连接
BI应用绝不应该跨事实表的外键处理两个事实表的连接操作。在关系数据库中，控制此类连接操作的回答集的基数是不可能的，将会产生不正确的结果。
针对事实表的时间跟踪
存在三种基本事实表粒度：事务级别、周期快照和累积快照。个别情况下，在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的，与采用类型2缓慢变化维度，在事实行有效获取时间的方式类似。
迟到的事实
迟到事实是指如果用于新事实行的多数当前维度内容无法匹配输入行的情况。当迟到度量事件出现时，必须搜索相关维度以发现有效的维度键。
高级维度技术
维度表连接
维度表可以包含到其他维度表的引用。此类关系可以采用支架维度建模实现，如果通过将支架表中的外键放入事实表中而不是放置在基本维度表中，降低维度表之间的关联，则此类增长通常可被避免。
多值维度与桥接表
经典维度模式中，每个与事实表关联的维度都有一个与事实表粒度一致的单一值。（如：某个病人接受了一次健康体检可能同时出现多个诊断。在此情况下，多值维度必须通过一组维度键通过桥接表使一组中的每个诊断与事实表一行关联。）
随时间变化的多值桥接表
多值桥接表可能需要基于缓慢变化类型2维度。（如：实现银行账户与单独客户的多对多关系的桥接表，通常必须基于类型2的账号与客户维度。为防止账户与客户之间的不正确连接，桥接表必须包含有效期和截止日期/时间戳，请求的应用必须约束桥接表，使其满足特定时刻以产生一致的快照。）
标签的时间序列行为
数据仓库中几乎所有文本都是维度表中的描述性文本。数据挖掘客户聚类分析通常产生文本化的行为标签，通常可以用作区分周期。
行为研究分组
有时可以通过执行多次迭代分析，来发现复杂的客户行为。在此情况下，将行为分析嵌入到BI应用，以约束所有客户维度成员，获取复杂的行为，这样的做法是不实现的。复杂行为分析的结果，可以通过某些简单表获取，这些表称为研究分组，仅包含客户的持久键。
聚集事实作为维度属性
商业用户通常对基于聚集性能度量的客户维度感兴趣，(如,过滤去年或整个阶段所有花费超过一定数额的客户。)选择聚集事实可以放入作为约束和作为行标识报表的目标维度。度量通常表示为维度表中的带状范围。维度属性表示聚集性能度量将增加ELT处理负担，但是可以方便BI应用层的分析功能。、
动态值范围
动态值范围报表由一系列报表行头组成，这些报表行头为目标数字化事实定义了范围不断变化的集合。（如：从0到￥10的平账，从￥10.01到￥20的平账等等）
文本注释维度
与其将自由注释作为事实表的文本度量，不如将它们存储于事实表之外的不同的注释维度，使该注释维度对应事实表中的一个外键。
多时区
为在多时区应用中获得通用标准时间以及本地时间，应该在受影响的事实表中设置双外键，用以连接两个不同角色的日期(和可能的当天时间（time-of-day）)维度表。
度量类型维度
当事实表每行包含一长列稀疏存储的事实时，可以建立度量类型维度，通过度量类型维度将事实表行变成单一通用事实。
步骤维度
序列过程通常在事务事实表中用不同行表示过程中的每一步。
热交换维度
当同一个事实表与相同维度的不同拷贝交替搭配时，可使用热交换维度。
抽象通用维度
一些建模者喜欢使用抽象通用维度。（如：他们的模式包含单一通用位置维度而不是关于商店、仓库和客户维度的嵌入式的地理属性。）在维度建模时应尽量避免使用抽象通用维度。数据抽象可以适当运用于操作型源系统或ETL处理，但对查询性能有负面影响，并会对维度模型的易读性带来负面影响。
审计维度
当事实表是在ETL之后建立时，建立包含当时已知的ETL过程元数据的审计维度是很好的方法。简单的审计维度行可包含一个或多个数据质量的基本标识，也许来自对错误事件模式的检验，记录数据处理是发现数据质量问题。
最后产生的维度
有时来自操作型业务过程的事实在关联维度内容前，以分钟、小时、天或周产生。（如：在实时日期发布环境下，订单消耗行可能会到来，显示客户提交的购买特定商品的自然键。）在实时ETL系统中，该行必须提交到BI层，即使客户或产品还不能立即确定下来。此情况下，将建立特殊的维度行，包含作为属性的未分解的自然键。
特殊目的模式
异构产品的超类与子类模式
金融服务与其他商业通常提供不同业务类型的广泛的产品。（如：零售银行可以提供许多不同类型的账目，从支票账号到抵押贷款到商业贷款，所有这些都是账户实例。）不能建立单一的、固定的事实表，将所有可能的事实都包含在内，因为存在大量的不兼容事实和属性。解决方案是建立单一的超类事实表，该事实表遍历所有账户类型的事实表（以及包含公共属性的超类维度表），然后系统化地为不同子类建立不同的事实表（与维度表关联）。超类与子类事实表也被称为核心或自定义事实表。
实时事实表
实时事实表需要比传统的夜间批处理过程更频繁地被更新。有许多技术可用于支持这一需求。采用何种技术要考虑最后部署到BI报表层的DBMS或OLAP多维数据库的能力。（如：“热分区”可定义一个事实表占用专用物理内存。不用再在该分区上建立聚集和索引。其他DBMS或OLAP多维数据库可能支持延迟更新，允许已存在的运行完毕的查询，仍然可执行更新。）
错误事件模式
数据仓库中数据质量的管理需要一个综合性系统，管理数据质量通过屏幕或过滤器来实现，用于测试从源系统到BI平台的数据。当数据质量屏幕检测到错误时，该事件将被记录在特殊的维度模式中。该维度模式仅能被ETL后端处理系统处理。这一模式包含错误事件事实表，其粒度为单独错误事件和相关错误事件详细事实表，相关错误事件详细事实表粒度为参与错误事件的每个表中的列。
