数据仓库的多维数据模型设计

在Inmon看来，数据仓库的多维数据模型中的构建方法和业务系统的企业的数据仓库的多维数据模型是相似的。商业系统中，企业数据模型决定着数据源，企业数据模型又分为主题域模型和逻辑模型两个层面。与此类似，主题域模型可以看作业务模型的概念模型，逻辑模型是领域模型在关系数据库上的实例。

将业务数据模型转换为数据仓库模型时，同样需要建立领域模型，也就是领域模型和领域模型的逻辑模型。

在此，业务模型中的数据模型与数据仓库的模型略有不同。其主要差别是：

在领域模型中，数据仓库的领域模型应该包含企业数据模型和各个主题领域的定义。

与业务系统的主题领域模型相比，数据仓库的领域模型应更广泛。

一个数据仓库的逻辑模型需要对业务系统的数据模型中的实体、实体的属性、实体的子类、实体之间的关系等等进行抽象。

在作者看来，Inmon的范式建模方法的最大优势在于从关系型数据库的角度，结合业务系统的数据模型，可以较方便地实现数据仓库的建模。

但是，它的缺点也很明显，因为建模方法局限于关系型数据库，在一定程度上限制了整个数据仓库模型的灵活性。在性能等等方面，尤其是当数据仓库基础数据汇总到数据集市中时，需要做一些改变，以满足相应的需求。

维度建模法

维模型方法，Kimball首先提出了这个概念。它最简单的描述是，根据事实表，维表来建立数据仓库，数据集市。

事实表用于记录特定事件，包含每一事件的特定元素和特定事件发生的情况；维表是事实表中事件元素的描述信息。

例如，一件事可能包含时间，地点，人物，事件，事实表记录整个事件的信息，但是像时间，地点，人物等等，只有一些关键标志，例如故事中的主角叫“Michael”，那么Michael到底长什么样子，就需要到相应的维表中查询“Michael”的具体描述信息。

在事实表和维表的基础上，可以构造多种多维度模型，包括星形模型、雪花模型、星座模型。

维模型法中，人们最广为人知的名称是星型模式(Star-schema)。

上面这一体系结构中的典型星型架构。星型模式被广泛应用，是指对每一维进行大量的预处理，如按维数进行统计、分类、排序等。

经过这些预处理，可以大大提高数据仓库的处理能力。

尤其对于3NF建模方法而言，星型模式在性能方面具有显著优势。

与此同时，维建模方法的另一优势是维建模非常直观，紧靠业务模型，能够在业务模型中直观地反映业务问题。

无需进行特殊的抽象处理，即可完成维度建模。这个方面对维度建模也有好处。

然而，维建模方法的缺点也十分明显，在构造星型模式之前，需要对数据进行大量的预处理，这就造成了大量的数据处理工作。

此外，当业务变更，需要重新定义维度时，常常需要对维度数据进行重新预处理。

而且在这些和处理过程中，常常会产生大量的数据冗余。

另一维建模方法的不足之处在于，仅依赖维建模，无法保证数据源的一致性和精确性，而在数据仓库的底层，对于维建模尤其不适合。

所以在笔者看来，维度建模的领域主要应用于数据集市层，其最大的作用实际上是解决数据仓库建模中的性能问题。

维建模难以为描述实际业务实体间的复杂关系提供一种抽象方法。

实体建模法

在数据仓库建模中，实体建模法并非一种常用的方法，它源于哲学流派。

在哲学意义上，客观世界应是可细分的，客观世界应可划分为由个体个体、实体与实体的关系构成。

这样，在数据仓库的建模过程中，完全可以将整个业务分割为单个的实体，而实体间的关系和描述则是我们数据建模所需完成的工作。

尽管实体法看上去有些抽象，但实际上理解起来很简单。

也就是把任何一个商业过程分成三部分：实体、事件和描述。

举例来说，我们描述了一个简单的事实：小明开车上学。就拿这一业务事实来说，我们可以把小明、学校看作是一个实体，上学描述的是一个业务过程，我们可以把它抽象成一个具体的事件，而开车去则可以看作是事件上学的一种说明。

从上面的例子可以知道，我们使用的抽象归纳方法其实很简单，任何业务都可以看作是三个部分:

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

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

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

因为实体建模法可以轻松实现业务模型的划分，所以实体建模法在业务建模阶段和领域概念建模阶段得到了广泛的应用。从作者的经验来看，没有现成的行业模型，我们可以采用物理建模的方法，与客户一起理清整个业务模型，划分领域概念模型，抽象出具体的业务概念，结合客户的使用特点，创建出符合自己需求的数据仓库模型。

然而，实体建模法也有其固有的缺陷。由于实体解释法只是一种抽象客观的世界方法，注定这种建模方法只能局限于业务建模和领域概念建模阶段。因此，在逻辑建模阶段和物理建模阶段，是范式建模和维度建模发挥优势的阶段。

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

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

数据仓库的多维数据模型是数据仓库中最受欢迎的数据模型。数据仓库的多维数据模型最典型的数据模型包括星形模型、雪花模型和事实星座模型。本文通过实例展示了它们的模式和区别。

星型模式(starschema)

星形模式的核心是大中心表(事实表)和小附属表(维表)。以下是星型模式示例：

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

A.维表只与事实表有关，维表没有关联；

B.每个维表的主码为单列，主码放置在事实表中，作为连接两侧的外码；

以事实表为核心，维表围绕核心呈星形分布；

雪花模式(snowflakeschema)

雪花模式是星形模式的扩展，其中一些维表是标准化的，进一步分解到附加表(维表)。如下图所示，雪花模式示例：

从图中可以看出，地址表进一步细分了城市维度。supplier_type表被进一步细分为supplier维。

与雪花模式相比，星形模式中的维表更大，不符合标准化设计。雪花模型相当于将星形大维表拆分成小维表，符合标准化设计。但是这种模式在实际应用中很少见，因为这样做会增加开发难度，而数据冗余问题在数据仓库中并不严重。

事实星座模式(FactConstellation)

一个数据仓库由许多主题组成，包含多个事实表，维表是公共的可共享的，这一模式可视为星型图象的集合，因此被称为星系图或事实星座图。下面的图表显示了该模式的示例：

如上所示，事实星座模式包含两个事实表：sales和shipping，它们共享一个维表。

在数据仓库中，特别是企业级数据仓库，特别是在EDW中，事实星座是最常用的数据模式。

上述两种维度建模方法均为多维表对应单实表，但多维空间中的实表不只有一个，维表也可由多个实表使用。商业开发后期，大部分维度建模都使用星座模型。

在数据仓库中，数据仓库与数据集市不同的一种典型特征，从根本上说，数据仓库的数据模型更多的是避免冗余和数据复用，而对数据仓库进行套用是最合理的选择。

三个模式对比。

把星型/雪花型/星座型之间的关系归纳如下：

实例

当你建立维度模型之前，你应该先理解用户的需求。作者在数据库系列的第一部分中提到，ER建模是目前收集和可视化需求的最好技术。所以，假设了一家零售公司多次PK需求，得出如下ER图：

您可以使用建模工具将ER图直接映射到图表中：

在完成需求收集之后，就可以进行维度建模了。这个例子建立了星形模型的维度。但是，不管采用什么模式，维度建模的关键是要清楚地理解以下四个问题：

1.哪些维度可以用于主题分析？

在这种情况下，根据产品(PRODUCT)，客户(CUSTOMER)、商店(STORE)、日期(DATE)来分析销售，都很有用；

2.维表是如何使用现有数据产生的？

a.维度PRODUCT可以通过关系PRODUCT、关系VENDOR、与CATEGORY连接获得关系；

b.CUSTOMER维度与关系CUSTOMER相同；

c.可以通过关系STROE和关系REGION连接维度STORE；

d.维度CALENDAR从关系SALESTRANSACTION中的TDate列分离得到；

3.使用什么衡量“衡量”主题？

这个例子以销售为主题，而销售与销售这两个指标最直观地反映了销售；

4.如何利用现有数据产生事实表？

销售和销售信息可通过关系SALESTRANSACTION和关系SOLDVIA,PRODUCT连接获得；

在清楚了四个问题之后，就可以轻松地完成维度建模：

仔细地阅读会发现三个问题：1.维表不符合标准化设计(不符合3NF);2.事实表也不符合标准化设计(1NF均不满足);3.维度建模中各个维度的主码由***ID变为***Key；

对前两个问题来说，由于目前的建模环境是数据仓库，没有更新操作，因此无需严格进行规范化设计，以避免异常更新。

这样，尽管可以在雪花模型中建立一个维度，如下所示：

但是这也会增加查询人员的负担：每一次查询涉及的表格太多。所以在实际应用中，雪花模型仅仅是一个理论模型。在“维维建模数据仓库”中会出现星座模型，稍后将介绍星座模型。

***Key之类的字段称为代理码(surrogatekey)，对于第三个问题来说，它是一种主代码，通过自动分配整数生成，不会有任何其他意义。主要用来能处理“慢变维”。

经典星座模型

前面已经讨论过，事实表存在多重维度模型，称为星座模型。星象模式的两个主要功能是：分享维度和设置细节/集合事实表。以下将分别分析这两种情况：

共享维度

假设在前面文章中提到的零售公司，该公司质量监督部门将以分析销售主题相同的方法来分析次品，则这次不必进行重维建模，只需向模型添加一份新的劣质产品事实表。后来对数据仓库维度进行了以下建模：

详细/汇总事实表。

在详细事实表(detailedfacttables)中，每条记录都代表一条单一的事实表(aggregatedfacttables)，其中的每条记录都会聚合多个事实。根据表格字段，详细事实表通常具有设置TID属性，而聚集事实表则不具有。

两者事实表各有优缺点，详细事实表查询方式灵活，但集中事实表的响应速度较慢，尽管提高了查询速度，但使查询功能受到一定的限制。通常的做法是使用星座模型同时设置两类事实表(可以包含多个聚集事实表)。该设计方法集中了事实表使用和细节事实表细节事实表的维度。下面的维度建模方法使用星座模型综合详细事实表和聚集事实表：