所谓水无定势，兵无常法。不同的行业，有不同行业的特点，因此，从业务角度 看，其相应的数据模型是千差万别的。目前业界较为主流的是数据仓库厂商主要 是IBM和NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外，也 有各自的针对某个行业的数据模型。例如，在银行业，IBM 有自己的 BDWM(Banking data warehouse model)，而 NCR 有自己的 FS-LDM 模型。在电信业，IBM 有 TDWM(Telecom Data warehouse model)，而NCR有自己的TS-LDM模型。因此，我们看到，不同的公司有自己 针对某个行业的理解，因此会有不同的公司针对某个行业的模型。而对于不同的 行业，同一个公司也会有不同的模型，这主要取决于不同行业的不同业务特点。可能很多人要问，为什么你们的模型是9个概念而不是10个，11个呢？你们 的数据仓库模型的依据又是什么？其实这是我们在给客户介绍我们的数据模型 时，经常被问到的一个问题，我希望读者在读完本文时，能够找到自己的答案。虽然每个行业有自己的模型，但是，我们发现，不同行业的数据模型，在数据建 模的方法上，却都有着共通的基本特点。本文的主要目的之一，就是希望读者能够通过对本文的阅读，同时，结合自己对 数据仓库建设的经验，在建设数据仓库的时候能够总结出一套适合自己的建模方 法，能够更好的帮助客户去发挥数据仓库的作用。本文主要的主线就是回答下面三个问题：什么是数据模型为什么需要数据模型如何建设数据模型最后，我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例，帮助大 家来了解整个数据建模的过程。什么是数据模型数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间 联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型 表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描 述，来表达实际的业务中具体的业务关系。数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模 型，一般的来说，我们数据仓库模型分为几下几个层次，如图1所示。通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需 要经历一般四个过程：业务建模，生成业务模型，主要解决业务层面的分解和程序化。领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概 念模型。逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的 关系进行数据库层次的逻辑化。物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的 物理化以及性能等一些具体的技术问题。因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了 具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来 帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论, 来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。回页首 为什么需要数据模型 在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这 么重要呢？首先我们需要了解整个数据仓库的建设的发展史。数据仓库的发展大致经历了这样的三个过程：简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务 人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇 总数据。这个阶段的大部分表现形式为数据库和前端报表工具。数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的 数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提 供对特定业务指导的数据，并且能够提供特定的领导决策数据。数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数 据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的， 完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的 数据，同时，为领导决策提供全面的数据支持。通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建 设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓 库的建设，有着决定性的意义。一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助 我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模 型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行 情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我 们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。建立全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型 建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自 己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消 灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设， 能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有 效解决。解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的 分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过 数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整 个数据仓库系统的灵活性。帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业 务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从 而能够使整个项目组明确当前的任务，加快整个系统建设的速度。回页首如何建设数据模型建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分，那么，怎么 建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍 如何创建适合自己的数据模型。数据仓库数据模型架构数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的，我们首 先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很 清楚地看到，整个数据模型的架构分成5大部分，每个部分其实都有其独特的 功能。图3.数据仓库数据模型架构System of Record 系统记录域Summary of Area 汇玄域Analysis Area 分析域Feedback Are-a 反馈域Houseke&ping内部管理域数仓库数据摸型架构从上图我们可以看出，整个数据仓库的数据模型可以分为大概5大部分：系统记录域(System of Record):这部分是主要的数据仓库业务数据存 储区，数据模型在这里保证了数据的一致性。内部管理域(Housekeeping):这部分主要存储数据仓库用于内部管理的 元数据，数据模型在这里能够帮助进行统一的元数据的管理。汇总域(Summary of Area):这部分数据来自于系统记录域的汇总，数 据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。分析域(Analysis Area):这部分数据模型主要用于各个业务部分的具 体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。反馈域(Feedback Area):可选项，这部分数据模型主要用于相应前端 的反馈数据，数据仓库可以视业务的需要设置这一区域。通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模 型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该 涵盖了从业务到实现技术的各个部分。数据仓库建模阶段划分 我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的 不同阶段的数据建模的工作的主要内容：业务建模，这部分建模工作，主要包含以下几个部分:划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务 工作的界定，理清各业务部门之间的关系。深入了解各个业务部门的内具体业务流程并将其程序化。提出修改和改进业务部门工作流程的方法并程序化。数据建模的范围界定，整个数据仓库项目的目标和阶段划分。领域概念建模，这部分得建模工作，主要包含以下几个部分：抽取关键业务概念，并将之抽象化。将业务概念分组，按照业务主线聚合类似的分组概念。细化分组概念，理清分组概念内的业务流程并抽象化。理清分组概念之间的关联，形成完整的领域概念模型。逻辑建模，这部分的建模工作，主要包含以下几个部分：业务概念实体化，并考虑其具体的属性事件实体化，并考虑其属性内容说明实体化，并考虑其属性内容物理建模，这部分得建模工作，主要包含以下几个部分:针对特定物理化平台，做出相应的技术调整针对模型的性能考虑，对特定平台作出相应的调整针对管理的需要，结合特定的平台，做出相应的调整生成最后的执行脚本，并完善之。从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个 数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所 帮助。数据仓库建模方法大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。数据仓库得建 模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了 一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常 多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法 其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业 务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些 建模方法。1. 范式建模法(Third Normal Form，3NF)范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目 前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范 式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般 采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范 式的关系必须具有以下三个条件：每个属性值唯一，不具有多义性；每个非主属性必须完全依赖于整个主键，而非主键的一部分；每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应 该归到其他关系中去。由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这 里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。根据Inmon的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。 在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层 次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模 型，而逻辑模型则是域模型在关系型数据库上的实例话。图5.范式建模法从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念 模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库 的模型稍微有一些不同。主要区别在于：数据仓库的域模型应该包含企业数据模型得域模型之间的关系，以及各主 题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更 加广。在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象 实体，实体的属性，实体的子类，以及实体的关系等。以笔者的观点来看，Inmon的范式建模法的最大优点就是从关系型数据库的角度 出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其 缺点也是明显的，由于建模方法限定在关系型数据库之上，在