数据仓库逻辑建模

数据仓库模型的特点

 

对于传统的OLTP系统，我们总是按照应用来建立它的模型，换言之，OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subjec

 

t)来建模，它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。在银行中，一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统，它们都是面向应用的，所支持的交易类型简单而且固定。由于实施的先后等原因，这些系统可能运行在不同的平台上，相互之间没有什么关系，各系统之间的数据存在冗余。比如每个系统中都会有客户的数据，当针对银行建立其数据仓库应用时，要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看，其数据模型不再面向个别应用，而是面向整个银行的主题，比如客户、产品、渠道等。因此，各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中，从而在整个银行的业务界面上提供一个一致的信息视图。

 

数据仓库的建模方法

 

逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF，即 Third Normal Form)和星型模式 (Star-Schema)，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。

 

什么是第三范式

 

范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化 (Normalize)。在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义。如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:

 

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

 

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

 

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

 

我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件，则称为第一范式;如果满足前面两个条件，则称为第二范式，依此类推。因此，各级范式是向下兼容的。

 

10秒注册会员 结交数据仓库朋友 分享你的精彩