把握数据仓库中的“键”

申请免费试用、咨询电话：400-8352-114

目前，在数据仓库逻辑模型设计上主要有实体-关系建模和维度建模两种方法，其中维度建模，即星型模式设计在国内数据仓库项目工程实践中应用更为广泛。星型结构模型典型的形式是一个主题由中间的一个大表和围绕在其周围的一组小表组成。中间的大表称为“事实表”，存储数值型度量指标和连接到维度表的外键；外围的小表称为“维度表”，存储用于描述事物的文本属性信息及连接到事实表的主键。

这一结构体现了两种关系，一是维度表与事实表之间的一对多关系；二是通过事实表体现出的维度表之间相互的多对多关系。实践证明，这种简单而对称的结构能够表达各种复杂的业务逻辑，并有助于最终用户的访问。

主外键关系是维度建模的重要基础，那么怎样决定数据仓库中的主键呢？至少有三个方面因素必须考虑：第一，主键应该是稳定的；第二，主键应该能够标识出到相关源系统的映射；第三，主键实际是一种约束，必须考虑加载和查询的效率。

维度表中的键

维度表一般由主键、分类层次和属性描述组成。对于主键的选择一般存在两种观点：一种是采用自然键（Natural Key），即操作型系统使用的具有一定内置含义的标识符；另一种是采用代理键（Surrogate Key），即由装载程序或者数据库系统所赋予的一个数值，该数值按顺序分配，没有内置含义但可以作为一行维度信息的惟一标识。

根据笔者的项目经验，推荐采纳第二种观点，主要原因是代理键简化了事实表与维度表的主外键关系。维度表作为用户进入事实表的入口，承担着记录观察视角的历史变化轨迹的任务。如果以自然键、时间标签，或许还有机构代码联合起来也可以在逻辑上惟一标识出一个产品，但如果作为主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数是巨大的，在多个维度上重复这样的做法会使事实表由于列宽过于膨胀而迅速崩溃。

最好的办法是采用代理键，即选择一个只占用4个字节就可以处理20亿个正整数的列作为维度表的主键，这样既解决了事实表存储空间的浪费问题，又维持了自身的独立和稳定。

另一个好处是，代理键可以作为数据仓库系统与源系统之间的缓冲。随着企业的发展，生产系统中的产品名称、产品分类、组织机构几乎不可避免地会发生调整，有的时候甚至自然键本身也会发生变化。就像身份证号码都从15位变到18位一样，在历史的长河中一般认为不可能的事其实都有可能发生。如果采用了代理键，这些变化会被屏蔽在维度表内，需要记录历史轨迹的就贴上时间标签，不需要的就直接更新掉，变化的过程不会对事实表产生任何冲击。维持业务系统的自然键与维度表代理键的对照关系的目的也在于此，既保留了业务系统到数据仓库系统的映射，又提高了数据仓库系统的抗震性。

事实表中的键

事实表中包含度量指标和连接到相关维度表的一组外键，这组外键的联合惟一标识了一行事实数据。然而，事实表在维度建模过程中是如此重要，以致于我们必须进一步认识它。这里的关键是对逻辑主键和物理主键的认识。

逻辑主键是构成事实表的所有维度外键的联合。由于事实表存在多种类型，从粒度上看有原子级和汇总级；从度量的可加性上看有完全可加、半可加和不可加类型。在数据仓库逻辑模型设计阶段，使用逻辑主键是妥当的，这是一个具有很好包容性和概括性的定义。物理主键是在具体的项目场景中能够惟一标识事实表中一行数据的列的联合。在数据仓库物理模型设计阶段，一般会采用物理主键的概念。逻辑主键有时是和物理主键一致的，但并不总是这样。

物理模型中保单事实表的物理主键已经确定，那么是否意味着一定要在事实表上真正建立起联合主键？这个问题目前在业界存在着广泛的争议。笔者认为应该视情况而定，如果事实表很大，每天的增量信息很多，那么这个联合主键可以不做显式的声明，即不在保单事实表上建立主键，物理主键只用于ETL及数据核查过程。

因为，在OLTP系统环境中，数据的完整性通常靠两种方式来保证，一是应用程序的逻辑保证，另一个是数据库结构自身的约束机制。这两种方式相互补充，而数据仓库环境中的情况则完全不同，数据仓库中数据的完整性更依赖于应用程序，也就是ETL系统的保证。

首先，ETL系统运行时间虽然很长，但其结构是简单的，重复地抓取、清洗、转换、加载动作。与其相比，OLTP系统可能同时在一张表上执行大量并行业务操作；其次，事实表的惟一入口是维度表，按照维度建模的思路实现ETL程序，只可能产生不准确的维度信息，但不可能在事实表中产生重复记录；第三，与OLTP系统相比，数据仓库系统没有交互式人机录入界面，不存在“人为”错误。

因此，当装载时间窗是一个必须考虑的问题时，建议从数据仓库环境中删除一些不必要的约束，其中包括主键约束、外键约束和惟一索引约束。这些约束规则可以在外部得以实施。 (CCW)