建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分，那么，怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。

大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。

数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。

目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。

我们下面给大家详细介绍一下这些建模方法。

范式建模法(Third Normal Form，3NF)其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。 

目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。 

范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。 

在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 : 

每个属性值唯一，不具有多义性 ; 

每个非主属性必须完全依赖于整个主键，而非主键的一部分 ; 

每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。 

由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。 

根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。 

这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于： 

数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。 

数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。 

在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。 

以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。 

但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。

维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。

事实表是用来记录具体事件的，包含了每个事件的具体要素，以及具体发生的事情；维表则是对事实表中事件的要素的描述信息。

比如一个事件会包含时间、地点、人物、事件，事实表记录了整个事件的信息，但对时间、地点和人物等要素只记录了一些关键标记，比如事件的主角叫“Michael”，那么Michael到底“长什么样”，就需要到相应的维表里面去查询“Michael”的具体描述信息了。

基于事实表和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。

维度建模法最被人广泛知晓的名字就是星型模式(Star-schema)。

上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。 

通过这些预处理，能够极大的提升数据仓库的处理能力。 

特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。 

同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。 

不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。 

但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。 

而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。 

而在这些与处理过程中，往往会导致大量的数据冗余。 

另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。 

因此以笔者的观点看，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。 

维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。 

从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。 

那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。 

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。 

即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明。 

例如我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。 

从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3 个部分： 

实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。 

事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。 

说明，主要是针对实体和事件的特殊说明。 

由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。 

但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。 

因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。

维度建模法数据模型的区别

多维数据模型是最流行的数据仓库的数据模型，多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式，本文以实例方式展示三者的模式和区别。

星型模式的核心是一个大的中心表(事实表)，一组小的附属表(维表)。星型模式示例如下所示：

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

▼更多精彩推荐，请关注我们▼

数据仓库是一个面向主题的，集成的，非易失的且随时间变化的数据集合

一：数据仓库的四大特点：

• 主题（Subject） 是在较高层次上企业信息系统中的数据进行综合，归类和分析利用的一个抽象概念。
• 每一个主题基本对应一个宏观的分析领域
• 它是对应企业中某一宏观分析领域所涉及的分析对象

• 一个面向事务处理的商场数据库系统，其数据模式：

• 集成性是指数据仓库中数据必须是一致的
  • 数据仓库的数据是从原有的分散的多个数据库，数据文件和数据段中抽取来的
  • 数据来源可能既有内部数据又有外部数据
• 统一：消除不一致的现象
• 综合：对原有数据进行综合和计算

• 数据仓库中的数据是经过抽取而形成的分析型数据
• 主要供企业决策分析之用
• 执行的主要是查询操作，一般情况下不执行更新操作
• 一个稳定的数据环境也有利于数据分析操作和决策的制订

• 数据仓库以维的形式对数据进行组织，时间维是数据仓库很重要的一个维度
• 更新与时间有关的综合数据

二：数据仓库和数据库的区别

• OLTP是传统的关系型数据库的主要应用

四：有哪些数据仓库架构？

lnmon架构–范式建模：

从全企业的高度设计的一个3NF模型

Inmon模型将模型划分为三个层次：

ER模型的衍生，为了实现数据的整合

强调可审计的基础数据层

基于主题将企业数据结构化组织

• Hub：企业的核心业务实体
• Link：代表Hub之间的关系