再谈 Conformed Table

最近都在忙着看世界杯，今晚小日本的比赛没劲，不看了，写点东西。

当我们在构建一个数据仓库的架构时，我们一定要从整个企业的视角来进行构建，企业内所有的数据必须是一致的。这一点是不论是Inmon的追随者还是Kimball的追随者都认可的，否则就会建立成烟囱式的数据仓库或数据集市（有时我们开玩笑的称之为有中国特色的数据仓库，其实外国也很多）。

企业的最主要的数据分为两种，第一种就是描述企业的经营情况的"事实数据"。我们暂且不考虑用ER来建模还是用维度来建模，他们的差别主要是保存在一个表还是多个表。为了使用这些数据、对这些数据进行分析，就引出了第二种数据，也就是像客户、产品这类对前一种数据进行观察的入口点，我暂且将他成为"维度数据"。

建立企业数据仓库（EDW）的目的就是能把企业所有的这两类数据进行统一。在这个统一数据基础上建立数据集市数据就可以达成统一。对于中小企业直接建立这样的企业数据仓库是可行的策略，对于大型和超大型企业直接建立企业数据仓库一般会存在着资金和时间上的问题。如果资金和时间都不是问题的话，也可以直接建立。

说到这里，Inmon和Kimball发生了分歧，Inmon认为为了一致必须建立这样的企业数据仓库，即前面提到的企业范围的"事实数据"和企业范围的"维度数据"都需要一致的保留在EDW中，然后在其上建立数据集市或者其他应用。而Kimball则认为这样在实际中不可行，数据集市要分步建立，并提出只要把前面提到的企业范围的"维度数据"保留在"EDW"中（并继续简化，取消"EDW"，直接保存在MD架构的数据准备区Staging Area中），企业范围的"事实数据"可以逐步建立，分散在不同的数据集市中，同时提出企业范围的"事实数据"虽然直接保存在各个数据集市中，但是其中的计算方法和单位等要保持一致。Kimball把保留在数据准备区中的企业范围的"维度数据"称为一致性维度（Conformed Dimension），把为了保证"事实数据"能够一致的这些计算方法和单位等因素及由此生成的分散的不同数据集市的事实数据叫做一致性事实（Conformed Fact），两者合在一起就是 Conformed Table。

这里，我们并没有探讨数据的建模方式，而只是从架构上提出了Inmon和Kimball的分歧。而且我们采用的是"事实数据"和"维度数据"这两个颇为偏向Kimball的术语，只是因为我没有想到用其他的什么术语能准确表达这个意思，希望大家在拍砖时能关注表达的内容而不是表达的方式。

Innovate 20060613

其实之所以对Kimball的理论要熟悉些, 也和实际情况有关系, 多数客户要的是立即能看到的效果, 你就得尽快建设数据集市。

从另一个角度看, 数据仓库的核心是数据存储, Inmon和Kimball在数据集市方面都赞同要使用维度建模为最价, 不同的是"EDW" 这块的存储方式产生了分歧.数据仓库虽然面向主题的,但是数据集市包含的信息应该是数据仓库的子集,于是Inmon提出要包容所有信息, 应该在这层使用3NF建模,这样一方面很灵活, 不用担心一个表包含的信息太少,另一方面扩展性方便, 用户增加了分析需求,需要从其他系统加入的话, 可以加入关联关系中来, 如果Kimabll的conform table架构作为EDW的话, 表结构和ETL是需要经常修改变化的. 所以Inmon曾经指出Kimball的方案到底能将项目维持到多久?

然而Kimball指出,任何项目都是有周期生命的. 于是目前客户需要的5年规划的情况看, Kimabll方案的生命周期应该没问题. 不过我觉得项目没有定势, 根据客户的需求看, 如果客户有银子, 能有一定耐心等待, 那么给客户建设Inmon派的EDW也是没有问题的,何况很多大公司有成熟的模型, 建设可以更快. 但如果客户需要马上很快地看到结果, 那么毫不由于需要Kimball的方案, 并且拿出成熟的数据集市模型方案, 可以更快建设好.

从目前来看, 多数500强企业选择的还是Inmon派方式, 他们有钱, 需要的是系统规划, 而不是短期效应.

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友