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