本文主要的主线就是回答下面三个问题:
什么是数据模型 为什么需要数据模型 如何建设数据模型 最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大家来了解整个数据建模的过程。
一、 什么是数据模型
数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间联系的形式,来表示现实世界中事务的相互关系的一种映射。在这里,数据模型表现的抽象的是实体和实体之间的关系,通过对实体和实体之间关系的定义和描述,来表达实际的业务中具体的业务关系。
数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型,一般的来说,我们数据仓库模型分为几下几个层次,如图 2 所示。
图 2. 数据仓库模型
通过上面的图形,我们能够很容易的看出在整个数据仓库得建模过程中,我们需要经历一般四个过程:
因此,在整个数据仓库的模型的设计和架构中,既涉及到业务知识,也涉及到了具体的技术,我们既需要了解丰富的行业经验,同时,也需要一定的信息技术来帮助我们实现我们的数据模型,最重要的是,我们还需要一个非常适用的方法论,来指导我们自己针对我们的业务进行抽象,处理,生成各个阶段的模型。
二、 为什么需要数据模型
在数据仓库的建设中,我们一再强调需要数据模型,那么数据模型究竟为什么这么重要呢?首先我们需要了解整个数据仓库的建设的发展史。
数据仓库的发展大致经历了这样的三个过程:
通过数据仓库建设的发展阶段,我们能够看出,数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此,数据模型的建设,对于我们数据仓库的建设,有着决定性的意义。
一般来说,数据模型的建设主要能够帮助我们解决以下的一些问题:
三、 如何建设数据模型
建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。
1) 数据仓库数据模型架构
数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的,我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到,整个数据模型的架构分成 5 大部分,每个部分其实都有其独特的功能。
图 3. 数据仓库数据模型架构
从上图我们可以看出,整个数据仓库的数据模型可以分为大概 5 大部分:
2) 数据仓库建模阶段划分
我们前面介绍了数据仓库模型的几个层次,下面我们讲一下,针对这几个层次的不同阶段的数据建模的工作的主要内容:
图 4. 数据仓库建模阶段划分
从上图我们可以清楚地看出,数据仓库的数据建模大致分为四个阶段:
1.业务建模,这部分建模工作,主要包含以下几个部分:
2.领域概念建模,这部分得建模工作,主要包含以下几个部分:
3.逻辑建模,这部分的建模工作,主要包含以下几个部分:
4.物理建模,这部分得建模工作,主要包含以下几个部分:
3) 数据仓库建模方法
大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。
1.范式建模法(Third Normal Form,3NF)
范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :
根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。
图 5. 范式建模法
从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
2.维度建模法
维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式(Star-schema)。
图 6. 维度建模法
上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的,虽然这种模型相比星型模型更规范一些,但是由于这种模型不太容易理解,维护成本比较高,而且性能方面需要关联多层维表,性能也比星型模型要低。所以一般不是很常用。雪花模型如下图
同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余。
另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
1.实体建模法
实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明,如下图所示:
图 7. 实体建模法
上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:
由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。
四、 数据仓库建模样例
上面介绍得是一些抽象得建模方法和理论,可能理解起来相对有些难度,因此,笔者在这里举一个例子,读者可以跟着我们的这个样例,来初步了解整个数据仓库建模的大概过程。
熟悉社保行业的读者可以知道,目前我们国家的社保主要分为养老,失业,工伤,生育,医疗保险和劳动力市场这 6 大块主要业务领域。在这 6 大业务领域中,目前的状况养老和事业的系统已经基本完善,已经有一部分数据开始联网检测。而,对于工伤,生育,医疗和劳动力市场这一块业务,有些地方发展的比较成熟,而有些地方还不够成熟。
1.业务建模阶段
基于以上的背景介绍,我们在业务建模阶段,就很容易来划分相应的业务。因此,在业务建模阶段,我们基本上确定我们本次数据仓库建设的目标,建设的方法,以及长远规划等。如下图:
图 8. 业务建模阶段
在这里,我们将整个业务很清楚地划分成了几个大的业务主线,例如:养老,失业,工伤,生育,医疗,劳动力等着几个大的部分,然后我们可以根据这些大的模块,在每个业务主线内,考虑具体的业务主线内需要分析的业务主题。
因此,业务建模阶段其实是一次和业务人员梳理业务的过程,在这个过程中,不仅能帮助我们技术人员更好的理解业务,另一方面,也能够发现业务流程中的一些不合理的环节,加以改善和改进。
同时,业务建模阶段的另一个重要工作就是确定我们数据建模的范围,例如:在某些数据准备不够充分的业务模块内,我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下,我们可以再来考虑数据建模的问题。
2.领域概念建模阶段
领域概念建模阶段是数据仓库数据建模的一个重要阶段,由于我们在业务建模阶段已经完全理清相应的业务范围和流程,因此,我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象,整个领域概念建模的工作层次如下图所示:
图 9. 领域概念建模阶段
从上图我们可以清楚地看到,领域概念建模就是运用了实体建模法,从纷繁的业务表象背后通过实体建模法,抽象出实体,事件,说明等抽象的实体,从而找出业务表象后抽象实体间的相互的关联性,保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。
从图上看,我们可以把整个抽象过程分为四个层次,分别为:
抽象方法层,整个数据模型的核心方法,领域概念建模的实体的划分通过这种抽象方法来实现。
领域概念层,这是我们整个数据模型的核心部分,因为不同程度的抽象方法,决定了我们领域概念的不同。例如:在这里,我们可以使用“参与方”这个概念,同时,你也可以把他分成三个概念:“个人”,“公司”,和“经办机构”这三个概念。而我们在构建自己的模型的时候,可以参考业务的状况以及我们自己模型的需要,选择抽象程度高的概念或者是抽象程度低的概念。相对来说,抽象程度高的概念,理解起来较为复杂,需要专业的建模专家才能理解,而抽象程度低的概念,较适合于一般业务人员的理解,使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体,以方便业务人员和技术人员之间的交流和沟通。
具体业务层,主要是解决具体的业务问题,从这张图我们可以看出,具体的业务层,其实只是领域概念模型中实体之间的一些不同组合而已。因此,完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求,而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。
业务主线层,这个层次主要划分大的业务领域,一般在业务建模阶段即已经完成这方面的划分。我们一般通过这种大的业务主线来划分整个业务模型大的框架。 通过领域概念建模,数据仓库的模型已经被抽象成一个个的实体,模型的框架已经搭建完毕,下面的工作就是给这些框架注入有效的肌体。
3.逻辑建模阶段
通过领域概念建模之后,虽然模型的框架已经完成,但是还有很多细致的工作需要完成。一般在这个阶段,我们还需要做非常多的工作,主要包括:
实例话每一个抽象的实体,例如:在上面的概念模型之后,我们需要对“人”和“公司”等这些抽象实体进行实例化。主要是,我们需要考虑“人”的属性包括那些,在业务模块中,用到的所有跟“人”相关的属性是哪些,我们都需要将这些属性附着在我们数据模型的“人”这个实体上,例如“人”得年龄,性别,受教育程度等等。同理,我们对其他属性同样需要做这个工作。
找出抽象实体间的联系,并将其实例话。这里,我们主要考虑是“事件”这个抽象概念的实例话,例如:对于养老金征缴这个“事件”的属性得考虑,对于失业劳动者培训这个“事件”的属性得考虑等等。
找出抽象事件的关系,并对其进行说明。在这里我们主要是要针对“事件”进行完善的“说明”。例如:对于“事件”中的地域,事件等因素的考量等等。 总而言之,在逻辑建模阶段,我们主要考虑得是抽象实体的一些细致的属性。通过逻辑建模阶段,我们才能够将整个概念模型完整串联成一个有机的实体,才能够完整的表达出业务之间的关联性。
在这个阶段,笔者建议大家可以参考 3NF 的建模方法,表达出实体的属性,以及实体与实体之间的联系。例如:在这个阶段,我们可以通过采用 ERWIN 等建模工具等作出符合 3NF 的关系型数据模型来。
4.物理建模阶段
物理建模阶段是整个数据建模的最后一个过程,这个过程其实是将前面的逻辑数据模型落地的一个过程。考虑到数据仓库平台的不同,因此,数据模型得物理建模过程可能会稍微有一些不同,在这个阶段我们主要的工作是:
这里,笔者通过一个数据建模的样例,希望能够给读者一个关于数据仓库建模的感性的认识。希望读者在利用这些数据仓库得建模方法创建自己的数据模型的时候,可以根据业务实际的需要和自己对抽象能力的把握来创建适合自己的数据模型。