数据仓库模型的设计.doc

2.5 数据仓库模型的设计大体上可以分为以下三个层面的设计151：.概念模型设计 ;.逻辑模型设计 ;.物理模型设计 ;下面就从这三个层面分别介绍数据仓库模型的设计2.5.1 概念模型设计进行概念模型设计所要完成的工作是：<1>界定系统边界 <2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中 “有什么 ”、“怎样组织的 ”和“如何分布的 ”等，然后再来考虑应当如何建立数据仓库系统的概念模型一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识 ;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前：.要做的决策类型有哪些 ?.决策者感兴趣的是什么问题 ?.这些问题需要什么样的信息 ?.要得到这些信息需要包含原有数据库系统的哪些部分的数据 ?这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。

因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来1 / 92，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括：.主题域的公共码键 ;.主题域之间的联系：.充分代表主题的属性组2.5.2 逻辑模型设计逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用在这一步里进行的工作主要有：.分析主题域，确定当前要装载的主题 ;.确定粒度层次划分 ;.确定数据分割策略;.关系模式定义 ;.记录系统定义逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括：.适当的粒度划分 ;.合理的数据分割策略 ;.适当的表划分 ;.定义合适的数据来源等I.分析主题域在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。

选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统 ;它还要足够小，以便于开发和较快地实施如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义的子集来进行开发在每一次的反馈过程中，都要进行主题域的分析2 / 9z.粒度层次划分数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型确定数据仓库的粒度划分，可以使用在粒度划分一节中介绍的方法，通过估算数据行数和所需的 DASD数，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次3.确定数据分割策略在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素：数据量 , 而非记录行数 )、数据分析处理的实际情况、简单易行以及粒度划分策略等数据量的大小是决定是否进行数据分割和如何分割的主要因素 ;数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的 ;我们还要考虑到所选择的数据分割标准应是自然的、易于实施的：同时也要考虑数据分割的标准与粒度划分层次是适应的4.关系模式定义数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。

在概念模型设计时，我们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定 _的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式用关系型数据库来实现数据仓库信息模型时，目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 Star-Schem司，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合4.1 什么是第三范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化 (Normalize)3 / 9在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件：1.每个属性的值唯一，不具有多义性 ;2.每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;3.每个非主属性不能依赖于其他关系中的属性，团为这样的话，这种属性应该归到其他关系中去我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的如果只满足第一个条件，则称为第一范式 ;如果满足前面两个条件，则称为第二范式，依此类推。

因此，各级范式是向下兼容的4.2 什么是星型模式是一种多维的数据关系，它由一个事实表 (Fact Table)和一组维表 (Dimension Table)组成每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据 ;而维大都是文字、时间等类型的数据与星型模式类似还有一种业界提的比较多的设计方式是雪花模式，它也是一种在关系数据库中实现多维数据关系的方式，与星型模式相区别的是它的维表结构与星型模式不同星型模式中同一维度的不同层次位于一张维表中，维表由唯一主键和事实表关连 ;雪花模式中同一维度中的不同层次位于不同的层次表中，最低层次表与事实表关连，各个层次再分别和比自己高一级的层次表关连4 / 9因为星型模式查询效率要比雪花模式高的多，所以比较多的是采用星型模式设计多维数据关系4. 3 第三范式和星型模式在数据仓库中的应用大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计 ;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)，以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率 )并降低系统执行动态查询能力为代价的。

根据数据仓库的测试标准 TPC-D规范，在数据仓库系统中，对数据库引擎最大的挑战主要是这样几种操作：多表连接、表的累计、数据排序、大量数据的扫描下面列出了一些 DBMS在实际系统中针对这些困难所采用的折衷处理办法：1、如何避免多表连接：在设计模型时对表进行合并，即所谓的预连接 (Pre-Join)当数据规模小时，也可以采用星型模式，这样能提高系统速度，但增加了数据冗余量2、如何避免表的累计：在模型中增加有关小计数据 (SummarizedData)的项这样也增加了数据冗余，而且如果某项问题不在预建的累计项内，需临时调整3、如何避免数据排序：对数据事先排序但随着数据仓库系统的运行，不断有新的数据加入，数据库管理员的工作将大大增加5 / 9大量的时间将用于对系统的整理，系统的可用性随之降低4、如何避免大表扫描：通过使用大量的索引，可以避免对大量数据进行扫描但这也将增加系统的复杂程度，降低系统进行动态查询的能力这些措施大都属于不规范处理根据上面的讨论，当把规范的系统逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规范处理举例来说，当系统数据量很小，比如只有几个 GB 时，进行多表连接之类复杂查询的响应时间是可以忍受的。

但是设想一下加果数据量扩展到很大，到几百 GB，甚至上 TB,一个表中的记录往往有几百万、几千万，甚至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受这时就有必要把几个表合并，尽量减少表的连接操作当然，不规范处理的程度取决于数据库引擎的并行处理能力数据仓库建设者在选择数据库引擎时，除了参考一些相关的基准测试结果外，最好是能根据自己的实际情况设计测试方案，从几个数据库系统中选择最适合自己企业决策要求的一种不规范化处理虽然是提高系统性能的一种有效手段，但是由于中央数据仓库的数据模型反映了整个企业的业务运行规律，在这里进行不规范处理容易影响整个系统，不利于今后的扩展而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加，这将增加 DBA的工作量和系统投资因此，当系统性能下降而进行不规范处理时，比较好的办法是选择问题较集中的部门数据集市实施这种措施6 / 9这样既能有效地改善系统性能汉不至于影响整个系统在国外一些成功的大型企业级数据仓库案例中，基本上都是采用这种方法那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢 ?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。

例如，一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素，这些因素就是维，而销售量就是事实这种多维模型能迅速给出基于各个维的报表，这些维必须事先确定星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等在上面的例子中，就是按照汽车的型号、颜色、代理商进行预先的销售量统计因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。