数据仓库建设中的数据建模方法
?
可能很多人要问,为什么你们的模型是 9 个概念而不是 10 个,11 个呢?你们的数据仓库模型的依据又是什么?其实这是我们在给客户介绍我们的数据模型时,经常被问到的一个问题,我希望读者在读完本文时,能够找到自己的答案。
虽然每个行业有自己的模型,但是,我们发现,不同行业的数据模型,在数据建模的方法上,却都有着共通的基本特点。
本文的主要目的之一,就是希望读者能够通过对本文的阅读,同时,结合自己对数据仓库建设的经验,在建设数据仓库的时候能够总结出一套适合自己的建模方法,能够更好的帮助客户去发挥数据仓库的作用。
本文主要的主线就是回答下面三个问题:
最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大家来了解整个数据建模的过程。
?
通过上面的图形,我们能够很容易的看出在整个数据仓库得建模过程中,我们需要经历一般四个过程:
因此,在整个数据仓库的模型的设计和架构中,既涉及到业务知识,也涉及到了具体的技术,我们既需要了解丰富的行业经验,同时,也需要一定的信息技术来帮助我们实现我们的数据模型,最重要的是,我们还需要一个非常适用的方法论,来指导我们自己针对我们的业务进行抽象,处理,生成各个阶段的模型。
?从上图我们可以看出,整个数据仓库的数据模型可以分为大概 5 大部分:
通过对整个数据仓库模型的数据区域的划分,我们可以了解到,一个好的数据模型,不仅仅是对业务进行抽象划分,而且对实现技术也进行具体的指导,它应该涵盖了从业务到实现技术的各个部分。
?
从上图我们可以清楚地看出,数据仓库的数据建模大致分为四个阶段:
业务建模,这部分建模工作,主要包含以下几个部分:
领域概念建模,这部分得建模工作,主要包含以下几个部分:
逻辑建模,这部分的建模工作,主要包含以下几个部分:
物理建模,这部分得建模工作,主要包含以下几个部分:
从我们上面对数据仓库的数据建模阶段的各个阶段的划分,我们能够了解到整个数据仓库建模的主要工作和工作量,希望能够对我们在实际的项目建设能够有所帮助。
?
从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
以笔者的观点来看,Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。因此,笔者建议读者们在实际的使用中,参考使用这一建模方式。
2. 维度建模法
维度建模法,Kimball?
最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式(Star-schema
)。
图 6. 维度建模法
?
上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余。
另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
3. 实体建模法
实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明,如下图所示:
图 7. 实体建模法
?
上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:
由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。
?在这里,我们将整个业务很清楚地划分成了几个大的业务主线,例如:养老,失业,工伤,生育,医疗,劳动力等着几个大的部分,然后我们可以根据这些大的模块,在每个业务主线内,考虑具体的业务主线内需要分析的业务主题。
因此,业务建模阶段其实是一次和业务人员梳理业务的过程,在这个过程中,不仅能帮助我们技术人员更好的理解业务,另一方面,也能够发现业务流程中的一些不合理的环节,加以改善和改进。
同时,业务建模阶段的另一个重要工作就是确定我们数据建模的范围,例如:在某些数据准备不够充分的业务模块内,我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下,我们可以再来考虑数据建模的问题。
?
从上图我们可以清楚地看到,领域概念建模就是运用了实体建模法,从纷繁的业务表象背后通过实体建模法,抽象出实体,事件,说明等抽象的实体,从而找出业务表象后抽象实体间的相互的关联性,保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。
从图上看,我们可以把整个抽象过程分为四个层次,分别为:
通过领域概念建模,数据仓库的模型已经被抽象成一个个的实体,模型的框架已经搭建完毕,下面的工作就是给这些框架注入有效的肌体。
4.物理建模阶段
物理建模阶段是整个数据建模的最后一个过程,这个过程其实是将前面的逻辑数据模型落地的一个过程。考虑到数据仓库平台的不同,因此,数据模型得物理建模过程可能会稍微有一些不同,在这个阶段我们主要的工作是:
经过物理建模阶段,整个数据仓库的模型已经全部完成,我们可以按照自己的设计来针对当前的行业创建满足自己需要的数据模型来。
这里,笔者通过一个数据建模的样例,希望能够给读者一个关于数据仓库建模的感性的认识。希望读者在利用这些数据仓库得建模方法创建自己的数据模型的时候,可以根据业务实际的需要和自己对抽象能力的把握来创建适合自己的数据模型。
?
?