数据仓库逻辑建模（转载于《计世网》）

数据仓库逻辑建模   
    
  数据仓库模型的特点
对于传统的OLTP系统，我们总是按照应用来建立它的模型，换言之，OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subject)来建模，它是面向 
主题的。何谓应用?何谓主题?让我们来看一个简单的例子。在银行中，一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统，它们都是面向应用的，所支持的交易类型简单而且固定。由于实施的先后等原因，这些系统可能运行在不同的平台上，相互之间没有什么关系，各系统之间的数据存在冗余。比如每个系统中都会有客户的数据，当针对银行建立其数据仓库应用时，要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看，其数据模型不再面向个别应用，而是面向整个银行的主题，比如客户、产品、渠道等。因此，各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中，从而在整个银行的业务界面上提供一个一致的信息视图。
数据仓库的建模方法
逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF，即 Third Normal Form)和星型模式 (Star-Schema)，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。
什么是第三范式
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化 (Normalize)。在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义。如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:
1. 每个属性的值唯一，不具有多义性;
2. 每个非主属性必须完全依赖于整个主键，而非主键的一部分;
3. 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件，则称为第一范式;如果满足前面两个条件，则称为第二范式，依此类推。因此，各级范式是向下兼容的。
什么是星型模式
星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
第三范式和星型模式在数据仓库中的应用
一个数据仓库的基本结构可以分成四层:
也有一些企业由于这样那样的原因，没有建立全企业范围的数据仓库，而是建立基于部门应用的独立数据集市(有关数据集市与数据仓库的比较，请参阅本报今年第 27期上笔者编译自 Bill Inmon的文章)。
大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
根据数据仓库的测试标准 TPC-D规范，在数据仓库系统中，对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。下面列出了一些 DBMS在实际系统中针对这些困难所采用的折衷处理办法:
S如何避免多表连接:在设计模型时对表进行合并，即所谓的预连接 (Pre-Join)。当数据规模小时，也可以采用星型模式， 这样能提高系统速度，但增加了数据冗余量。
S如何避免表的累计:在模型中增加有关小计数据 (Summarized Data)的项。这样也增加了数据冗余，而且如果某项问题不在预建的累计项内，需临时调整。
S如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行，不断有新的数据加入，数据库管理员的工作将大大增加。大量的时间将用于对系统的整理，系统的可用性随之降低。
S如何避免大表扫描:通过使用大量的索引，可以避免对大量数据进行扫描。但这也将增加系统的复杂程度，降低系统进行动态查询的能力。
这些措施大都属于不规范处理。根据上面的讨论，当把规范的系统逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规范处理。举例来说，当系统数据量很小 ，比如只有几个 GB时，进行多表连接之类复杂查询的响应时间是可以忍受的。但是设想一下，如果数据量扩展到很大，到几百 GB，甚至上 TB，一个表中的记录往往有几百万、几千万，甚至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受。这时就有必要把几个表合并，尽量减少表的连接操作。当然，不规范处理的程度取决于数据库引擎的并行处理能力。用户在选择数据库引擎时，除了参考一些相关的基准测试结果外，最好是能根据自己的实际情况设计测试方案，从几个数据库系统中选择最适合自己企业决策要求的一种。
不规范处理的阶段
现在来讨论一下，当不得不选择不规范处理时，应在哪个阶段进行。
由于中央数据仓库的数据模型反映了整个企业的业务运行规律，在这里进行不规范处理容易影响整个系统，不利于今后的扩展。 而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加，这将增加 DBA的工作量和系统投资。因此，当系统性能下降而进行不规范处理时，比较好的办法是选择问题较集中的部门数据集市实施这种措施。这样既能有效地改善系统性能，又不至于影响整个系统。在国外一些成功的大型企业级数据仓库案例中，基本上都是采用这种方法。
那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。例如，一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素，这些因素就是维，而销售量就是事实。这种多维模型能迅速给出基于各个维的报表，这些维必须事先确定。
星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。在上面的例子中，就是按照汽车的型号、颜色、代理商进行预先的销售量统计。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
小结
上面讨论了数据仓库模型设计中常用的两种方法。在数据仓库的应用环境中，主要有两种负载:一种是回答重复性的问题;另一种是回答交互性的问题。动态查询具有较明显的交互性特征，即在一个问题答案的基础上进行进一步的探索，这种交互过程常称为数据挖掘 (Data Mining)或者知识探索 (Knowledge Discovery)。对于以第一种负载为主的部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于中央数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。