数据仓库模型的设计

1、2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计 151: .概念模型设计 ;.逻辑模型设计 ;.物理模型设计 ; 下面就从这三个层面分别介绍数据仓库模型的设计。2.5.1 概念模型设计 进行概念模型设计所要完成的工作是 :<1> 界定系统边界<2> 确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为 稳固的概念模型。 因为数据仓库是对原有数据库系统中的数据进行集成 和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原 有数据库系统加以分析理解， 看在原有的数据库系统中 “有什么” 、“怎 样组织的

2、”和“如何分布的”等，然后再来考虑应当如何建立数据仓库 系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字 典中的数据库关系模式， 可以对企业现有的数据库中的内容有一个完整 而清晰的认识 ;另一方面，数据仓库的概念模型是面向企业全局建立的， 它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型 时不用考虑具体技术条件的限制。1. 界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最 初就得到详细而明确的需求， 但是一些基本的方向性的需求还是摆在了 设计人员的面前 :. 要做的决策类型有哪些 ?.

3、 决策者感兴趣的是什么问题 ?. 这些问题需要什么样的信息 ?. 要得到这些信息需要包含原有数据库系统的哪些部分的数据 ? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最 需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可 以看作是数据仓库系统设计的需求分析， 因为它将决策者的数据分析的 需求用系统边界的定义形式反映出来。2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内 容进行较明确数据仓库建模技术在电信行业中的应用的描述， 描述的内 容包括 :. 主题域的公共码键 ;. 主题域之间的联系 :. 充分代表主题的属性组。2.5.2 逻辑模型

4、设计 逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务 部门的需求，同时对系统的物理实施有着重要的指导作用。在这一步里 进行的工作主要有 :. 分析主题域，确定当前要装载的主题 ;. 确定粒度层次划分 ;. 确定数据分割策略 ;. 关系模式定义 ;. 记录系统定义 逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行 定义，并将相关内容记录在数据仓库的元数据中，包括 :. 适当的粒度划分 ;. 合理的数据分割策略 ;. 适当的表划分 ;. 定义合适的数据来源等。I分析主题域在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓 库的设计方法是一个逐步求精的过程，在进行设计时

5、，一般是一次一个 主题或一次若干个主题地逐步完成的。所以，我们必须对概念模型设计 步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题 域。选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能 建设成为一个可应用的系统 ;它还要足够小，以便于开发和较快地实施。 如果所选择的主题域很大并且很复杂， 我们甚至可以针对它的一个有意 义的子集来进行开发。 在每一次的反馈过程中， 都要进行主题域的分析。乙粒度层次划分 数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒 度划分层次， 粒度层次划分适当与否直接影响到数据仓库中的数据量和 所适合的查询类型。确定数据仓库的粒度划分，可以使用

6、在粒度划分一 节中介绍的方法，通过估算数据行数和所需的数，来确定是采用单一粒 度还是多重粒度，以及粒度划分的层次。3.确定数据分割策略 在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方 面因素 :数据量而非记录行数 ）、数据分析处理的实际情况、简单易行 以及粒度划分策略等。 数据量的大小是决定是否进行数据分割和如何分 割的主要因素 ;数据分析处理的要求是选择数据分割标准的一个主要依 据，因为数据分割是跟数据分析处理的对象紧密联系的 ;我们还要考虑到 所选择的数据分割标准应是自然的、 易于实施的 :同时也要考虑数据分割 的标准与粒度划分层次是适应的。4.关系模式定义 数据仓库的每个主题

7、都是由多个表来实现的，这些表之间依靠主题 的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我 们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容 等做了描述在这一步里，我们将要对选定 _的当前实施的主题进行模式 划分，形成多个表，并确定各个表的关系模式。用关系型数据库来实现数据仓库信息模型时，目前较常用的两种建 模方法是所谓的第三范式 (3,即 )和星型模式司，我们将重点讨论两种 方法的特点和它们在数据仓库系统中的适用场合。4.1什么是第三范式 范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一 范式到第五范式进行无损分解，这个过程也称为规范化 ()。在数据仓库

8、 的模型设计中目前一般采用第三范式，它有非常严格的数学定义。如果 从其表达的含义来看， 一个符合第三范式的关系必须具有以下三个条件 :1. 每个属性的值唯一，不具有多义性 ;2. 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;3. 每个非主属性不能依赖于其他关系中的属性，团为这样的话，这 种属性应该归到其他关系中去。我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间 的关系而作出的。 如果只满足第一个条件， 则称为第一范式 ;如果满足前 面两个条件，则称为第二范式，依此类推。因此，各级范式是向下兼容 的。4.2什么是星型模式星型模式是一种多维的数据关系，它由一个事实表 ( )

9、和一组维表 ( ) 组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主 键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属 性称为事实 ()，它们一般都是数值或其他可以进行计算的数据 ;而维大都 是文字、时间等类型的数据。与星型模式类似还有一种业界提的比较多的设计方式是雪花模式， 它也是一种在关系数据库中实现多维数据关系的方式， 与星型模式相区 别的是它的维表结构与星型模式不同。 星型模式中同一维度的不同层次 位于一张维表中， 维表由唯一主键和事实表关连 ;雪花模式中同一维度中 的不同层次位于不同的层次表中，最低层次表与事实表关连，各个层次 再分别和比自己高一级的层次表

10、关连。因为星型模式查询效率要比雪花模式高的多，所以比较多的是采用 星型模式设计多维数据关系。4. 3第三范式和星型模式在数据仓库中的应用 大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设 计;而在进行物理实施时， 则由于数据库引擎的限制， 不得不对逻辑模型 进行不规范处理 ()，以提高系统的响应速度，这当然是以增加系统的复 杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率 )并降 低系统执行动态查询能力为代价的。根据数据仓库的测试标准规范，在 数据仓库系统中， 对数据库引擎最大的挑战主要是这样几种操作 :多表连 接、表的累计、数据排序、大量数据的扫描。下面列出了一些在实际

11、系 统中针对这些困难所采用的折衷处理办法 :1、如何避免多表连接 :在设计模型时对表进行合并，即所谓的预连 接()。当数据规模小时，也可以采用星型模式，这样能提高系统速度， 但增加了数据冗余量。2、如何避免表的累计 :在模型中增加有关小计数据 ( ) 的项。这样也 增加了数据冗余， 而且如果某项问题不在预建的累计项内， 需临时调整。3、如何避免数据排序 :对数据事先排序。但随着数据仓库系统的运 行，不断有新的数据加入，数据库管理员的工作将大大增加。大量的时间将用于对系统的整理，系统的可用性随之降低。4、如何避免大表扫描 :通过使用大量的索引，可以避免对大量数据 进行扫描。但这也将增加系统的复杂

12、程度，降低系统进行动态查询的能 力。这些措施大都属于不规范处理。根据上面的讨论，当把规范的系统 逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规 范处理。举例来说，当系统数据量很小，比如只有几个时，进行多表连 接之类复杂查询的响应时间是可以忍受的。 但是设想一下加果数据量扩 展到很大，到几百，甚至上 ,一个表中的记录往往有几百万、几千万，甚 至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受。 这时就有必要把几个表合并，尽量减少表的连接操作。当然，不规范处 理的程度取决于数据库引擎的并行处理能力。 数据仓库建设者在选择数 据库引擎时，除了参考一些相关的基准测试结果外，最

13、好是能根据自己 的实际情况设计测试方案， 从几个数据库系统中选择最适合自己企业决 策要求的一种。不规范化处理虽然是提高系统性能的一种有效手段，但是由于中央 数据仓库的数据模型反映了整个企业的业务运行规律， 在这里进行不规 范处理容易影响整个系统，不利于今后的扩展。而且不规范处理产生的 数据冗余将使整个系统的数据量迅速增加， 这将增加的工作量和系统投 资。因此，当系统性能下降而进行不规范处理时，比较好的办法是选择 问题较集中的部门数据集市实施这种措施。这样既能有效地改善系统性能汉不至于影响整个系统。在国外一些成功的大型企业级数据仓 库案例中，基本上都是采用这种方法。那么，在中央数据仓库中是否可以

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

15、不能满足 要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成， 这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点 是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适 合于预先定义好的问题加需要产生大量报表的场合 ;而不适合于动态查 询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式 在一些要求大量报表的部门数据集市中有较多的应用。4. 4 两种模式的比较上面讨论了数据仓库逻辑模型设计中常用的两种方法 .在数据仓库 的应用环境中，主要有两种负载 :一种是回答重复性的问题 ;另一种是回 答交互性的问题。动态查询具有较明显的交互性特征，即在一个问题答

16、案的基础上进行进一步的探索，这种交互过程常称为数据挖掘 ( ) 或者知 识探索( )。对于以第一种负载为主的部门数据集市，当数据量不大、报 表较固定时可以采用星型模式 ;对于中央数据仓库， 考虑到系统的可扩展 能力、投资成本和易于管理等多种因素，最好采用第三范式。或者说对 于数据仓库中当前详细级别的数据和轻度综合的数据可以采用第三范 式的方式设计，对于高度综合的数据可以采用星型模式设计。2.5.3 物理模型设计这一步所做的工作是确定数据的存储结构，确定索引策略，确定数据存放位置，确定存储分配。确定数据仓库实现的物理模型， 要求设计人员必须做到以下几方面 : 要全面了解所选用的数据库管理系统，特

17、别是存储结构和存取方 法。了解数据环境、数据的使用频度、使用方式、数据规模以及响应时 间要求等，这些是对时间和空间效率进行平衡和优化的重要依据。. 了解外部存储设备的特性，如分块原则，块大小的规定，设备的 特性等。1.确定数据的存储结构 一个数据库管理系统往往都提供多种存储结构供设计人员选用，不 同的存储结构有不同的实现方式，各有各的适用范围和优缺点，设计人 员在选择合适的存储结构时应该权衡三个方面的主要因素 :存取时间、存 储空间利用率和维护代价。2. 确定索引策略 数据仓库的数据量很大，因而需要对数据的存取路径进行仔细的设 计和选择。由于数据仓库的数据都是不常更新的，因而可以设计多种多 样的索引结构来提高数据存取效率。在数据仓库中，设计人员可以考虑对各个数据存储建立专用的、复 杂的索引，以获得最高的存取效率，因为在数据仓库中的数据是不常更 新的，也就是说每个数据存储是稳定的，因而虽然建立专用的、复杂的 索引有一定的代价，但一旦建立就几乎不需维护索引的代价。3. 确定数据存放位置 我们说过，同一个主题的数据并不要求存放在相同的介质上。在物 理设计时，我们常常要按数据的重要程度、使用频率以及对响应时间的 要求进行分类，并将不同类的数据分别存储在不同的存