对数据仓库进行数据建模IBM

对数据仓库进行数据建模IBM

2007-11-1615:00

OLTP与数据仓库一有何差异？

在日常生活中，我们要使用大量的应用程序来生成新的数据、变更数据、删除数

据，当然在大多数的情况下我们还要查阅与分析数据。就来想象一个收发email

的简单应用程序吧。我们已经存储了地址信息，可能还存储了一些文档。我们能

够决定是否存储已经发送过的邮件，但是也可能隔一段时间后将其删除，或者者

删除已经发送过的所有邮件。那么我们该如何处理一段时间往常删除或者者修改

过的地址呢？我们再也不可能看到它们了。

Email程序大部分都属于不是很复杂的数据库，但是完全能够将其看作一个在单

用户环境下的OLTP（在线事务处理系统）简单示例。它使用了所有的所谓访问

数据的操作CRUD（创建、读取、更新、删除）。当数据存储达到一定量的时候,

规模就会几乎保持不变，由于能够从存储中删除过期数据。

数据仓库就完全是一种不一致种类的应用程序。它并不是用来运行当前的操作，

比如发送邮件。它是用来分析数据同时从现有数据中发现新的价值，要紧是用来

预测未来的情况。数据仓库并不是解决所有问题的通用结构。它务必集中于某一

问题领域，比如航空服务、顾客收益等。

数据仓库也有有趣的一面，那就是数据库本身是稳固增长的。数据没有被删除，

也不发生变更。我们不需要将冗余数据置于数据库之外（由于加入仓库中的数据

通过了数据净化的过程，该过程检查了数据的正确性）来减少复杂性同时增强读

取操作的性能。

为了能够对数据仓库中的数据进行分析，数据存储于一个多维结构中，叫做星型

模式。假如将星型模式扩展，就会得到雪花模式。本白皮书将会阐述如何使用

IBMRationalRose进行星型模式建模与雪花模式建模。

飞行服务数据集市的例子

为了更好地解释如何对数据仓库建模，本白皮书将使用一个简单数据集市的为例

子（即一个数据仓库或者者数据仓库的一部分），来分析旅客乘坐航班Happy

FlyingandLanding（愉快飞行平安降落）的行为与满意程度。

我们将存储乘客信息与每个航班的的有关数据、选择的菜单与乘客对飞行的满意

程度。

数据仓库术语表

数据仓库引入了新的术语，扩展了数据建模的术语表。为使本文的阐述能够完备,

下面我介绍一下最常用的术语。

数据仓库

数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢

失的同时是时间变量。

数据仓库是所有操作环境与外部数据源的快照集合。它并不需要非常精确，由于

它务必在特定的时间基础上从操作环境中提取出来。

数据集市

数据仓库只限于单个主题的区域，比如顾客、部门、地点等。数据集市在从数据

仓库获取数据时能够依靠于数据仓库，或者者当它们从操作系统中获取数据时就

不依靠于数据仓库。

事实

事实是数据仓库中的信息单元，也是多维空间中的一个单元，受分析单元的限制。

事实存储于一张表中（当使用关系数据库时）或者者是多维数据库中的一个单元。

每个事实包含关于事实（收入、价值、满意记录等）的基本信息，同时与维度有

关。

在某些情况下，当所有的必要信息都存储于维度中时、单纯的事实出现就是关于

数据仓库足够的信息。我们稍后讨论有关缺无事实的情况。

维度

维度是绑定由坐标系定义的空间的坐标系的轴线。数据仓库中的坐标系定义了数

据单元，其中包含事实。

坐标系的一个例子就是带有X维度与y维度的Cartesian（笛卡尔）坐标系。

在数据仓库中，时间总是维度之一。

数据挖掘

在数据仓库的数据中发现新信息的过程被称之数据挖掘，这些新信息不可能从操

作系统中获得。

分析空间

分析空间是数据仓库中一定量的数据，用于进行数据挖掘以发现新信息同时支持

管理决策。

切片

一种用来在数据仓库中将一个维度中的分析空间限制为数据子集的技术。

切块

一种用来在数据仓库中将多个维度中的分析空间限制为数据子集的技术。

星型模式

一种使用关系数据库实现多维分析空间的模式，弥之星型模式。

星型模式将在本白皮书中稍后进行进一步讨论。

雪花模式

不管什么原因，当星型模式的维度需要进行规范化时，星型模式就演进为雪花模

式。

使用IBMRationalRose进行星型模式建模

星型模式的基本形式务必实现多维空间（常常被称之方块），以使用关系数据库

的基本功能。

首先，我们需要懂得多维空间。

多维分析空间

几何学中的方块是指一个三维空间，其中每个维度的尺寸都相同。想象一个立方

体，每个维度都有三个单元，我们即得到相同结阂的33=27个单元。

多维分析空间（或者者数据仓库方块）与几何空间中的方块仅仅存在细节上的差

异。

•维度不仅限于3维。只是，处理很多维度的立方体也不是件轻松的情况,

这会导致大多数的实现被限制于6或者者7维。不要期盼使用图形能够

很好地表示超过4的维度一假如您有幸能发现一种方法，别忘了告诉我

一下。

•维度并不具有相同的规模与单元。规模从几个单元到几百万个单元，差别

巨大。单元能够是一天、一位顾客、部门等。

•单元，相当于子方块（1X1X1等），包含事实。

图2一个三维数据立方体

数据立方体需要很大的内存以存储所有事实。不管是否包含事实，都务必要预留

单元。

这就是为什么使用关系数据库与星型模式的原因。使用它们能够优化存储同时保

持数据结构的灵活性。

星型模式

星型模式的基本思想就是保持立方体的多维功能，同时也增加了小规模数据存储

的灵活性。

图3一个星型模式

在图3中，星型模式使用事实Flight表示了一个4维方块（Passenger、MBnu、

FlightSchedulet与Time）。基本上，事实务必指定一个维度，以将其放入立

方体的单元中。

我们的例子中的维度是：

•Passenger,描述了飞行航程中的每位乘客，由经常飞行号（frequent

flyernumber）指定。不是经常乘坐飞机的乘客不是数据仓库的一部分。

•FlightSchedule,是指所有常规飞行的E程。

•Menu,是用于飞行的菜单。只有对菜单进行基本的分类才会对数据挖掘有

重要意义。

•Time,是指飞行的时间。

事实Flight描述了乘客在唯一的Time的单程飞行上选择Menu。

分析空间能够是完整的方块，或者者我们能够根据维度将分析空间分割成小片。

每个维度根据一个对象进行描述，对象能够用类表示，这些类就是有关业务主题

的名称。这一点关于成功建立数据仓库来说是很重要的，由于仓库的用户（经理、

分析员、市场）关于信息技术的术语并不是很熟悉。

事实本身就是商业智能的另一个对象，仍然通过类进行表示。

事实指每个维度。事实与维度的关联常常是一对任意，这也就意味着每个事实都

与单个维度的一个单元准确对应，而维度的每个单元（每个Passenger、Time

等）能够与任意数量的事实发生关联（包含0个事实）。

使用RationalRose将对象模型转换为数据模型即完成了星型模式的实现。这

里我们能够看到转换后的结果。

图4使用RationalRose实现星型模式

在图4中，没有显示自动创建的主键与外键约束。

星型模式的维度是独立的表。当对象模型转换为数据模型时;RationalRose能

够生成维度的主键。

事实表指从维度表中使用键迁移的维度，当生成数据模型时RationalRose能

够生成外键。

在星型模式中切片与切块是对维度的限制（选择）。这是一个运行时问题，而不

是建模问题，但是模型务必分辨其需要。

雪花模式

基本的星型模式并不能满足数据挖掘的所有需要。我们需要更复杂的维度，比如

时间。分析员希望根据周、月、季度等识别模式。

维度务必进行规范化。我们不需要冗余的维度表，这只会使数据切片变得更加复

杂。这种过程中我们程到的模式被称之雪花模式。

我们来看一个简单的雪花模式例子。我们将时间维度规范化为周、月与季度。

图5规范化的Time维度

我们希望能够使用附加的规范化维度将立方体切片：周、月与季度。在本例中，

我们假定季度是月的平行层次，这也就意味着我们不能将季度假定为若干月的聚

合。由于这个原因，我们将使用一张范化表（是对OLAP查询的一项简单附加）

预先选择时间维度。

最终雪花模式添加了规范化维度。

图6带有范化维度的Time与事实Flight的雪花模式

当然，所有的维度都能够像时间例子那样进行规范化，这就导致了比较复杂的数

据集市模式的出现。

由RationalRose从雪花模式中开发的实现模式（数据模型）是完善的。

图7带有范化Time维度的雪花模式的数据模型

创建的约束在图中也没有显示。

雪花模式中能够存在切片，不仅仅在基本的Time维度上，也能够在规范化的

Week、Month与Quarter维度上。

多对多关系

在一次飞行中，我们不仅仅只吃一顿饭。在长途飞行中可能要多次用餐。在这种

情况下，我们认为事实Flight与Menu维度不是一对多的关联。我们务必使用

多对多关联。只是，这种关联不可能在星型模式中实现。

雪花模式的一种特殊形式是使用一种必要的数据结构以满足这项要求。

首先，我们将模型变更为事实与维度间的多对多关联。使用RationalRose,这

只是关联基数的变更。

图8Menu的多对多维度的星型模式

我们无法在关系数据库中实现多对多关联。实现多对多关联需要使用另一种雪花

模式。

在下图中，我们关注一下已经开发的雪花模式的一部分，该部分处理多对多维度。

图9雪花模式解决了Menu的多维度

RationalRose生成了附加的维度表FlightMenu,它是指Menu维度与Flight

事实。

确定关系用于解决多龙多关联。

关于雪花模式的架构师来说，最重要的一点就是识别多对多关系。简单对象视图

可能会使设计员懂得概念，而生成的数据视图有助于进一步深入有关实现的问

题。

层次

数据挖掘能够从隐藏在操作系统表面下的数据中发现信息。我们想熟悉的一个问

题就是选定菜单与乘客统计资料之间的依靠关系。

乘客统计资料数据能够在Passenger维度的层次上构建。乘客能够根据邮政编

码分组，然后再按国家进行分组。

图10乘客的层次

层次通过使用聚合来指定。聚合定义了所包含的内容。Country包含了ZIP编

码,ZIP编码包含了多名Passpngpr信息八

最终通过使用外键实现了聚合。

图11雪花模式实现了Passenger维度的聚合

生成的约束仍然没有在图中表示出来。

使用聚合，维度能够在任何定义的级别上使用。分析空间能够通过Passenger.

ZIPCode或者者Country进行切片。

一致的维度

随着数据仓库架构师不断地添加细节内容，雪花模式变得越来越复杂。因此设计

过程务必在到达某种程度后停止以保持数据仓库运行良好。

星型或者者雪花模式仍然仅仅关注于一个事实一在本例中就是Flighto那么复

杂关系又是什么情况呢？

关于每个事实我们都务必设计其各自的模式。假如我们想要进行复杂查询的话，

它们就务必具有共同的维度一我们称其为一致的维度。

让我们使用Pilot作为一个维度，PilotFlight作为一个事实来定义第二个星

型模式。我们还要使用附加的FlightSchedule维度与Time维度。

图12Pilot星型模式

第二个模式能够单独使用或者者与Passenger模式结合使用，从而根据使用一

致维度的飞行员维度来查询Passenger的满意程度。

图13一致维度Time与FlightSchedule

即使在使用一致维度的数据仓库的简单结构中，Pilot与Passenger之间的关

系也是简单的。