银行数据仓库系统高层架构工程设计书

1 银行数据仓库系统高层架构工程设计书 景 浙商银行是经中国银监会批准设立的全国第十二家股份制商业银行，全称为 “ 浙商银行股份有限公司 ” ，英文全称为 “O., ，英文简称 “。注册资本 150073 万元，总行设在杭州。 2004 年 8 月 18 日浙商银行正式开业。目前浙商银行有宁波、温州等 2 家分行，余杭 萧山 宁波鄞州等支行，业务正处于增长期。 浙商银行的成立，既是浙江经济实力的综合反映，也是浙江经济发展的客观要求。作为浙商的传人，作为一家以民营资本为主体的新兴股 份制商业银行，浙商银行将立足浙江，面向全国，恪守信用，合法经营，以安全为前提，以客户为中心，以发展为主线，以效益为准则，以回报社会、股东和员工为目标，树立规模、安全、效益三者有机统一，全面、协调、可持续的科学发展观，营造特色，培育优势，优质、高效地服务于经济，服务于企业，服务于公众，共同创造社会财富，逐步建设成为经营有方、富有特色、业绩优良、具有一定国际影响的国内一流商业银行。 企业数据仓库 系统是以业务支撑应用系统的数据以及其他相关数据作为基础数据源，采用科学的数据抽取、整理、存储等方法，建立企业级数据仓库 ；然后通过丰富的数据 分析和 挖掘方法找出这些数据内部蕴藏的大量有用信息，对客户、业务、市场、收益、服务、等各方面情况进行科学的分析，从而为市场决策管理者和市场经营工作提供及时、准确、科学的辅助决策依据。 目前 浙商银行 已经有许多 业务支撑应用系统 ，但是各个系统相对独立，信息共享困难， 无法从整个企业和单一视图的角度 对数据进行深入分析和挖掘，无法 为 高层管理和决策提供强有力的依据 ，无法满足快速变化的市场的需求 。 为了能准确把握市场运行规律和客户需求，以便在激烈竞争中做出正确及时的决策，本工程将建设 浙商银行企业数据仓库 系统 。 本工程的建设目的使 浙商银行 更加 充分利用 业务 支撑 应用 系统产生的大量宝贵信息资源， 对生产经营和业务发展趋势做出科学合理的预测 ， 从而帮助 浙商银行 及时掌握市场动态，准确地把握市场脉搏，及时制定高效合理的营销策略， 更好地适应日趋激烈的市场竞争环境 。 企业数据仓库 系统 不但可以为企业制定和调整经营策略提供重要依据，更可成为企业发展的驱动中心，确保 浙商银行 在日益激烈的市场竞争中确立主导地位。 的 本文件的目的在于简要阐释整个商业智能环境和它的组成部份。这些部份包括硬件，软件和将会被购买或开发的满足需求的知识产权。这份文 件提供详细设计和架构的框架，这份文件包括： 描述目标环境所有技术细节的概要设计和总体结构； 阐释用于建立系统所购买的厂商设备； 阐释或叁照在 本项目中 使用的标准和指导方针 ;； 阐释架构和设计原则； 定义将要用到的术语 ; 在它得到认同形成基础后，我们将继续对此文档进行扩充。为了使这份文档成为有效的资源，应该及时更新这份文档。 2 用 对象 这份文件适用对象是本项目团队成员或想对 决策分析 系统有全局掌握的业务人员、业务分析人员、架构师、 部门 经理 与领导 和其它需要使用这份文件了解 决策分析 商业智能环境提供功能的其他项目组人 员。 围 这份文件的重点在于描述所有对 浙商银行 决策分析 环境有用的系统和组成部分。在项目实施过程中，将提供一份关于需要客户化开发的组成部件的详细说明，和现有组成部件的总结性描述。 考文档 浙江商业银行 务工作说明书 3 概念性体系构架 念性应用体系架构叙述了将要用于此方案的应用程序及主要组成成分。 这个图表提供 考体系架构的概要版本，这是专为非科技业务人员所备的。它使用了许多业务人员所熟知的术语。 I B M 商业智能概念性体系架构外部因特网传代 载、转换数据集市O D 识分析主题域集成分析客户财务人力资源供应链 与 数 据 保 据源 数据来源层标识了公 司内外所有有效的数据源。 据仓库 本层被分为 数据集市三部分。这些数据仓库不是操作型数据库的替代品或复制品，而是这些源数据系统的补充，它被改造成一个用于决策和业务管理的数据库。 析 分析层提供了分析软件，支持各种各样的应用，从固定报表到平衡记分卡。为满足特定需要，分析层将由各种各样各种领域最好的软件和工具组成。 互参考功能 从逻辑层到支持具体的环境，我们需要额外的技术流程和交互。这些额外的组成部分使系统拥有动态性和可控性。这些额外因素有硬件，安全保密机制及其实施和系统管理。 4 参考体系架构 这是 来描述商业智能环境的主要参考体系架构。它是为科技人员或具有深厚科技背景的商业用户所准备的。 数据源数据集成访问输送 / 通讯硬 件 软 件 平 台合作数据挖掘建模查询、报表网 络 连 接 与 访 问管 理 与 监 督安 全 性 与 数 据 保 密数 据 转 换抽取转变装载同步信息完整性 数 据 质 量 平 衡 与 控 制记分卡可视化嵌入分析数据存储库操作数据库数据仓库元数据分级区域数据集市分析I B M 商业智能参考模型网络浏览器门户设备网络服务器企业非组织信息外部数据工作流程分了各层的差异并加入必要的细节，使得此参考体系结构成为概念性体系结构的拓展。 5 技术体系架构 I B M 软件服务部浙商银行 架构设计 | C o n f i d e n t i a l 2 0 0 6 I o rp o ra t i o 础设施 软硬件平台系统管理和维护 安全、备份、灾难恢复迭代开发 需求变更、功能增长、数据增加授信系统核心系统资金结算系统财务系统国际结算系统第 2 阶段第 1 阶段文件缓冲区/ i n b/ a r c/ l o g/w r （元数据存储）业务元数据、技术元数据Me t a S t a g e 存储节数据暂存）用来准备 （ 节数据）数据结构独立于各数据源汇总数据用来准备 L A A PC u b ( 最终用户层 )报表 / 存储元数据管理 交付件、建模工具、 M e ta g 0 4 报表其它应用源数据 应用转换操作型数据抽取、清理 多维数据数据仓库装载 数据集市装载 载现如上图所示，整个数据仓库在技术上大概可以分为 5 个主要的模块，它们分别是： 1. 源数据和数据接口 2. 数据架构 3. 理和控制 4. 应用架构 5. 软硬件架构 在接下来的小 节中我们将分别对这 5 个主要的模块进行详细的描述。 6 数据和数据接口 数据接口架构描述了数据从数据源到到数据仓库过程中所遵循的规范和架构，如下图所示： I B M 软件服务部浙商银行 架构设计 | C o n f i d e n t i a l 2 0 0 6 I o rp o ra t i o H o m e $ H o m e i n b$ H o m e w H o m e a H o m e l o g$ H o m e 间）结果数据备份地程序处理日志 / 拒绝文件导出数据存放地接口文件根目标$ H o m e $ H o m e a c m s. . m o n t h l 8 月 1 日数据月变化数据每个处理目录. d a i l y. . 2 0 0 6 0 8 0 1$ H o m e zs ru 据源 数据仓库系统将采用文本文件的方式从源系统获取数据。每个源系统会就与 间就传输数据接口文件（ 格式和方法制定标准，称之为接口规范。 每个数据源会首先通过各自的数据导出程序（ 成接口文件存储在各自的文件缓冲区内。 这个 责各自范围内导出数据 的完备性和一致性，包括： 1. 依照各自的业务规则确定增量数据的导出方法 2. 保证导出文件的格式符合接口规范的要求 3. 保证导出文件的传输时间的及时性 4. 保证接口文件的数据质量，不错数、不丢数、不多数 据源范围 在编写本文档的时候，总共有 5 个系统的数据 被确定在范围之内。以下表格概述了将要实施的每 7 一个数据源（用于数据初始加载、数据增量加载或两者均可）的阶段。 阶段 系统名称 数据源类型 第 1 阶段 核心业务系统 贷系统 金交易系统 2 阶段 财务系统 国际结算系统 在选择使用哪个数据源系统来满足数据要求上，数据很可能地来源于一个或多个数据源系统。介于此原因，必须为物理模型的所有数据表选择一个记录系统。当有多个可供选择的数据源时，在选择数据源上必须遵循以下设计原则： 1 如果有可能就使用最原始的数据来源，不要使用副本或复制本 2 源数据系统数据应该是完整的。 3 源数据系统数据应该是最新的。 4 源数据系统数据应该是高质量的。 件缓冲区 文件缓冲区是一块在数据仓库之外的存储区域，它是接口文件的暂存地，可以是在每个源系统上，也可是在独立的接口机上。接口文件先放到文件缓冲 区，然后在到数据仓库的接口文件区。 此区域不属于数据仓库范围，相应的其存储空间的分配和维护也不属于数据仓库项目范围。 口文件区 接口文件区是数据仓库架构内存放接口文件和对接口文件进行处理的地方。 数据仓库中的 序负责维护此区域。 为了合理的组织接口文件区的内容，我们把接口文件区按如下目录结构组织，假设 $表接口文件区根目录 （ ： 目录 内容 $有源系统传过来的接口文件 $程中的临时文件和 件处理结束后结果文件的存放地 $份文件 $理日志及 拒绝文件存放地 $据仓库导出文件 当前正在处理的接口文件 个 输到这里后，首先根据文件验证规则进行一致性检查，验证通过后，就表明这个文件是有效的，然后将此文件登记到数据仓库的调度系统内，然后针对这个文件可以进行进一步的处理。 8 工作目录。基于文本的 序 在此目录内把接口文件转换成可以装载数据仓库的本， 功后，此文件连通原始接口文件可以压缩后放到 录下做备份处理。如果 则将错误文件放到 录下。 行过程中的日志和发生错误的接口文件都存放在此目录。 要传给数据仓库以外系统的数据，全部安装目标系统分类放在此目录内。 放历史接口文件。接口文件处理完毕后，将按业务类型和日期移动到此目录。然后在此目录完成数据备份。 件以固定的时间间隔由数据仓库 从文件缓冲区 拉 到接口文件区，或者由 源数据系统把数据从文件缓冲区 推 到接口文件区。不管以何种方式，在源数据系统和数据仓库之间都应该有一个握手机制来保证文件传输的完备性，即因为在网络上传输数据文件需要时间，数据仓库系统如何知道文件是否已经传完了。在接口规范上，我们要求源数据系统在传输完每个数据文件后，立刻创建一个与数据文件同名并以“ 尾的文件，文件内容为空或包含一些简单的数据文件验证信息，来告诉数据仓库说我这个文件已经传完了。 对于 录，进一步按照数据源和数据类型划分目录： 目录 内容 $ 信系统数据 $ 信系统 日变化数据 $授信系统 月 变化 数据 $心系统数据 $金系统数据 参考详细目录结构： 9 目录结构 存放内容口文件缓冲区|- 口文件备份目录| |- 信系统| | |- 变化数据备份| | - 变化数据备份| |- 金交易系统| | |- 变化数据备份| | - 变化数据备份| - 心系统| |- 变化数据备份| - 变化数据备份|- 口文件接收目录| |- 信系统| | |- 始化数据| | |- 变化数据| | - 变化数据| |- 金交易系统| | |- 始化数据| | |- 变化数据| | - 变化数据| - 心系统| |- 始化数据| |- 变化数据| - 变化数据|- 志| |- |- |- 口文件中的拒绝数据| | |- 信系统| | |- 金交易系统| | - 心系统| - 度程序日志|- 据仓库导出目录- - 信系统|- 金交易系统- 心系统 10 据 架构和 存储 数据架构描述数据在数据仓库系统内如何组织和存储 。数据架构的主要模块如下图所示： I B M 软件服务部浙商银行 架构设计 | C o n f i d e n t i a l 2 0 0 6 I o rp o ra t i o b b o xW o r kA r c h iv O 3 N FS u m m a r e e d b a c Me t a S t a g e 、业务定义 / 描述，运行状态 / 日志M A I N T E N A N C O G R A I N T E N A N C O J E C T B U D G E I N T E N A N C O J E C I T H I S T O R C A N C R N C E L L A T I O R K C O M P L E T I O R K I N S P E C T I O R K O R D E T A I R K O R D E R K P R O G R E S R K R E J E C T I O R K R E Q U E S R K T A S K I T E M P L A I N U I P M E N N A N C M B E R Sf o rh a e a t e sf o rf o rh a sf o rh a sh a sf o rh a sf o rf o e a t e sf o e a t e sf o rh a sf o rh a sf o rh a sw i t h i nh a sh a sf o rf o rh a sf o e a t e a ke C O U N N A N C E F A C T M o o C O U N I E N A T I O Y B A C N C E L L A T I O N T R A C Y M E N T D E T A I Y M E N R K O R D E R P A Y M E N R K O R D E Rf o rh a sh a sf o rf o rw i t h i nf o rh a sf o rh a sh a sf o rh a sf o rw i t h i nf o 雪花型结构A C C O U N S E N T R A C C A T I O Y M E N M R K O R D E R F A C T R K O R D E Rf o o o o o o o 绩效考核 1104 报表数 据仓库和数据集市都存储在一个 据库内，各个不同的数据在 按不同的 区分。 数据集市 存储在 ，多维立方体存储在 。 每个应用（ 1104 和绩效考核）有自己独立的数据库。 接下来我们分别对每个数据区域做详细介绍。 口文件区 接口文件区 是存储和处理接口文件的区域，如前面章节所述， 接口文件区在 统下按照特定的目录结构组织起来。用 一些系统命令和工具来管理。 对每个目录按照其特定的用途设定对不同用户的访问权限，比如谁能读，谁能写，谁能改等。 接 口文件区数据的处理工具主要是 加以 本和一些自己开发的特定程序 。 据仓库 节数据暂存区 主要目的是支持把接口文件的装载到数据库，对其进行验证和处理，然后把数据整合到。验证的方法主要是将新转载的数据与 已有的数据进行查找和比较。 数据结构的设计原则是最大限度的利用接口文件的数据结构，尽量降低实体的个数，同时 11 很好的支持后续的 程。 当然在物理表的设计上一些 特性也要考虑，比如合理的选择表的分区键，以 最大限度的发挥 并行特性。 面的表的用途基本都是临时的，每次数据装载都会清空，因此对这些表的处理可以不记日志，以加快处理速度。 节数据 f 基于 发的一套符合 3式规范的表结构。 储了数据仓库内最细节层次的数据 ，按照不同的主题域进一步分分类组织。此模型是整个数据仓库数据模型的核心，其设计为具有足够的灵活性，以能够应对添加更多的数据源，支持更多分析需求，同时也能够支持 一步升级和更新。 为了能够在数据仓库内记录数据的变化以支持 历史趋势和变化分析， 一些关键的属性值上会跟踪变化（比如客户的 信用度 、状态等） 。 跟踪变化的常见方法就是利用渐变维的 方法来处理记录，在表内增加一条记录变化数据的新记录。 同时为了降低不必要的存储空间的浪费（相同数据的重复存储），我们可以把实体中动态变化的属性与静态不变或只需覆盖不需跟踪变化的属性分开 。比如对用户，我们可以用一张表存放不变化的用户 静态 属性，用另一张表存放经常变化的用户行为属性 ，当跟踪用户行为的变化时我们只需在用户行为表内添加记录就行了，没必要把没有发生变化的用户静态表内的数据也复 制一份。 然是整个数据仓库中数据量最大的部分，为了提高此部分数据处理的性能， 一些提供性能的特性必须在这里仔细考虑，比如创建索引，分区键的选择等。 但索引同时也会降低数据更新的性能并且占用存储空间，因此 索引一定要选择在经常用到的键值或属性上。同时不同索引的类型对性能也会有相当的影响，因此创建索引的时候也需要仔细考虑。 数据的分区策略体现在两个方面，一个是存储层面一个是处理层面，处理层面我们在接下来的 存储层面来说，一是通过分区键数据自然的按照 法均匀的分布到 据库的各个分区上，还有就是对于一些数据量特别大的表，我们需要手工的按照数据范围把表分区，比如帐单表之类的，就可以按照帐单时间分成不同的表。 手工把表拆开会增加 理过程的复杂性，但相应的也带来处理性能的提高。 另一个性能相关的是代理主键（ 生成。代理主键是 一个唯一的、单列的、数值类型的属性值，用来代替源数据中自然主键。一方面数值型主键会提高查询、关联和索引的性能，另一方面最关键的是隔离源数据系统数据变化对数据仓库的影响。代理键的生成可以基于 的序列对象，然后此键值在所 有引用同一对象的实体内共享。 在 辑模型的物理化时，不同的物理化方法得到的模型对数据库的性能也有较大的影响，为了提高数据装载和访问的性能，保持物理模型的简单性，在物理化 型时我们将 权衡 使用如下 3种方法： 1. 并到父实体 12 2. 子实体合并到父实体 3. 父实体合并到子实体 总数据区 总数据区是为了方便查询和后续多维数据的更新，创建一些常用的中间汇总表，以提高性能和降低后续 作的复杂性。 由于 高度规范化的数据，因此要完成一个查询需要大量的关联操作；同时数据集 市中的数据粒度往往要比 很多，对要成生数据集市所需数据也需要大量的汇总计算，因此如果我们把常用的数据预先关联和汇总好，并让其尽量多在多个数据集市的计算中共享，就能大幅度的提高整个 馈数据区（ 反馈数据区主要记录的是数据仓库自身生成的结果。比如 用户对营销活动的反馈 等。 数据仓库的特性决定了用户在原则上不能直接修改数据仓库中的数据，因此用户的修改数据和其它生成数据必须单独记录，以便于追踪历史和进行比较。 数据存储 元数据存储用来保存关于数据仓库中的过程、数据的信息（日志、数据词典、配置信息等）。由 13 于各个工具和系统都会生成自己的元数据，同时我们还利用元数据管理工具把这些元数据尽可能的集中存储到数据仓库中的 ，因此 的来说只是一个共享元数据供用户集中访问的地方，真正元数据的维护地还是在生成这些元数据的系统或工具内。 元数据的管理和存储将会用到文件系统、建模工具、数据库 等多种途径。 在 数据仓库内 ，元数据可以被分成 三 种类型：业务、技术 、和操作型 元数据。 I B M 软件服务部河北网通 构设计 | C o n f id e n t ia l 2 0 0 6 I B M C o r p o r a t io I N T N C G R I N T N C J G I N T N C J U N I T H I R N C R N C O R K C O M P L O R K I N I O R K O R D T W O R K O R D R K G R R K R C T I O R K R R K T T E M I N I N N M f o re a t e sf o rf o o o o rf o rc re a t e sf o rc re a t e sf o o o i t h o rf o o rc re a t e a k e I N T N C G R I N T N C J G I N T N C J U N I T H I R N C R N C O R K C O M P L O R K I N I O R K O R D T W O R K O R D R K G R R K R C T I O R K R R K T T E M I N I N N M f o re a t e sf o rf o o o o rf o rc re a t e sf o rc re a t e sf o o o i t h o rf o o rc re a t e a k e W i n 应用数据存储P D M ， e t a S t a g eR e p o si t o r 表定义 项目文档元数据存储 M D 辑、物理变更更新到元数据平台供用户访问数据模型的技术定义P D M 的技术定义 ，和 J o b 日志等操作型信息E T L 的技术定义 ，和 J o b 日志等操作型信息报表的业务定义数据仓库的业务定义和 技术规范1. 业务定义（业务元数据） 业务元数据在业务层面最终用户感兴趣的元数据，通常包括业务指标的含义、计算规则，数据概念分类，属性的业务含义等。 2. 技术规范（技术元数据） 技术元数据是指支持数据仓库运行的各种技术定义和规范。它通常是各种配置信息，较少直接被最终用户访问。比如表的定义， 配置，调度信息等。 3. 操作状态（操作型元数据） 操作元数据是指数据仓库运行中各个组成部分的实际状态和日志。 它记录了整个数据仓库运行的过程，方便对数据仓库进行跟踪和调试。这类元数据通常存储在用户定义的表 内。比如数据仓库的各种统计信息， 行日志等。 14 据集市和多维立方体 维数据存储 多维数据存储包含一系列多维数据模型（符合星型模式或雪花模式的关系表）。每个多维数据模型由一个数据表和几个外键表组成，一个称 为事实表 ， 英文称为 ”，其他的表 称 为维度表。每个维度表含有单一的主键，这个主键和事实表里一个键相对应。这个类似于星形的结构通常被称作星形连接。 一个 事实表 经常包含一个或多个数字指标，或“ 事实 ， 英文称为 定义每个记录的键值组合。在 事实表 最有用的东西是数字和可以相加的东西。 相加是很重要的，因为数据仓库的应用程序不会检索单 个的事实表 ，相反，他们会同时取回上百、上万、甚至上亿条记录，唯一有用的事情是把这些记录相加。 通过对比，维度表通常含有描述信息。维度属性被用于在数据仓库查询里大部分有用约束的来源，实际上他们是 询返回结果集的行表头。 维表相对事实表来说都很小 。这些小表一般都可以 内存内，从而在与大的事实表关联时具有比较好的性能。 维表的可以设计为完全反范式化的，这时与一个维相关的所有层次都合并到最底层的维表内，这时的多维模型就体现为一个事实表带很多维表的“星型” 结构；同样也可以选择维中不同的层次的数据在各自的表内，这时在结构上体现出来的就是，事实表与很多底层维表关联，然后维中层次结构上的各层维表有与其更高层次维表关联，展现 出 “雪花”结构。 为了保证对 概念。 基于一个查询（比如关联、汇总等）构造出来的表，表的内容就是这个查询得到的结果集，这个结果集物理的存储在数据库表内。 作用相当于一个 询优化器知道的一个中间表。当用户提交一个对底 层细节表的查询时，如果这个查询能等价的转换成对这个 会自动的从 取得数据返回给用户。由于一般从 取数的代价会比直接从细节数据取数小得多，尤其是对于含有汇总、关联等操作的查询，因此会带来整体性能上的极大提高。 设计中的一个重要考虑是 更新时由系统自动进行还是手工进行。自动更新的好处是降低了 护的复杂性，但由于自动更新 限制比较多，并且对数据仓库应用来说基础表数据的变化完全是可以预知的，因此总的来说，在数据仓库系统内我们一般使用人工维护的 当创建数据集市时，要遵守以下的设计原则： 1. 数据将会从企业数据仓库里进入数据集市里，为了具体的分析应用，数据将会被重新转化。 2. 用多维建模技术创建数据模型。 3. 事实表 里的键不能包含空值。 15 4. 数据库将会为查询进行优化。 5. 如果有可能，企业数据仓库里的关键值将会被重用。 6. 应用程序用来维护参照完整性。 7. 这个环境将提供最大的可用性。 多维立方体 可以是关系型（ 即 可以是多维的（ 即 过 的关系表实现，通常具有更高的灵活性和数据存储能力。数据存储在多维数组内，立方体中各个层次的数据都预先计算出来存储在文件内，通常具有更好的性能。 在 浙商银行 数据仓库的总体架构内， 们都会用到。其中 现，主要是用来建立数据量大结构负责的立方体； 现，用来建立结构相当简单、数据量也不是太大，但对查询性能和查询功能要求比较多的立方体。 具体在实现时我们可以考察每个立方体的数据和访问情况来觉得其用何种方式实现比 较好。 1. 用 星型结构，及一系列的表和 模拟出一个多维的立方体出来。每种维层次的查询组合， 能或实时计算或从 查询得到相应的结果， 如果 计的足够多和好，其性能也能于真正的多维立方体想媲美。 下图展示的是 何用表和 模拟对立方体的查询的。 B a s e F a c t T a b l eS u m m a r y T a b l e s , i m p l e m e n t e d a s M Q T sU s e r Q u e r y 1U s e r Q u e r y 2U s e r Q u e r y 1 i s l o g i c a l l y r e f e r r i n g d a t a a l r e a d y c o n t a i n e d i n a M Q T , s o t h e d a t a i s r e t u r n e d f r o m t h e M Q T , s i m i l a r t o a f u l l y l o a d e d M O L A P d a t a b a s eU s e r Q u e r y 2 i s l o g i c a l l y r e f e r r i n g d a t a t h a t h a s n o t b e e n c a l c u l a t e d b y a n y o f t h e M Q T s , s o t h e q u e r y i s r e - w r i t t e n t o a c c e s s t h e “ c l o s e s t ” M Q 16 据库使用更有效的格式来存储多维数据，通常是多维数组的某种形式，它能把对立方体各种可能的查询全部预先结算出结果存储下来，从而具有更高的查询性能。因为基本上每次查询只是对数据的取出，而 没有太多太耗时的计算。当然现今的很多 擎也都支持动态计算，也即不是把所有结果全部存储下来，而是保留一部分在查询的时候动态的计算出来，从而降低对存储的消耗。 据库的建立一般是一个从下到上的过程。立方体中最底层的数据从 据库中抽取出来装入数据库，然后在各个维的层次上，由底向上逐层开始计算，直到所有的单元的结果都计算出来。 计算过程如下图所示： 由于 安装多维的形式把大部分可能访问到的 的“数据单元”都事先计算并存储下来，因此如果维的个数太多、或维的成员数过多、或维 的层次太多都可能导致立方体的体积增大，不仅会极大的增大多维数据库的建立时间，也会占有过多的存储空间。 擎是一个基于内存的 会在内存中建立一个多维的数据模型，然后把 的数据存放进去。它的特点是访问很快，但也因一步限制了 大小。因此在具体的实现上，我们会基于这样的原则 ：访问频繁、需要性能较高、体积较小的 在 ，大的复杂的 接用 实现。 3. 的 说，它就是用 实 现的， 用户告诉 实表和维表，然后自动的创建相应的 提高 访问性能。 对 说，当向 更新数据时，也可以通过 极大的提高性能。下面这张图说明了 数据仓库的数据访问架构中的作用。 17 据仓库应用 1104 报表和绩效考核在整个数据仓库架构内做为独立的应用存在，它们会有自己独立的存储空间（数据库） ，其中所有内容由各个应用自己完全控制，对数据仓库内数据的访问通过 I 来完成。 现中的一些特别因素 照表 由于数据仓库中的每个主键都是不同于源数据系统的代理主键，因此在源数据自然主键和 理主键之间就应该有一个表来描述二者之间的关系 。但这些表又不是 对用户有意义的数据，不会出现在 设计中，只是为了 处理而创建和维护的。我们称这些表为参照表。 应用 一种基于代价的 询优化系统， 译器会自动分析用户提交的 后对其进行编译找到一种代价最低的访问路径，然后在计算出查询结果。在 有两个模块对 使用最相关： 查询重写模块： s to a of s ) 据用 织成星型结构，构成接从取得数据来提高性能 18 此模块 分析查询语句，如果可能的话，就将其重写为一种效率更高的形式。 这种能力是用户不必关心 法对性能的影响，只关心程序的逻辑就行了。此模块会检查是否有 以使用来对 行优化，当然这需要检查 状态，并看 否满足 匹配条件。 基于代价的优化模块： 此模块评估每种访问路径的查询代价，然后选择代价最优的访问路径。 1. 状态因素 要使用 要考虑下面几个条件： 建时必须带 数 存器必须打开。此寄存器可以设置为： 对于 型的 状态总是最新的，因此不论 何值都会被引用 对于动态何静态 级必须等于 2 或大于等于 5 缺省是 5，此缺省值可以通过 置参数 改 此寄存器可以通过如下命令修改 能出现在 O 句内 2. 匹配条件 匹配是评估用户的查询语句，判断其是否可以用 写的过程。在所有的状态条件都满足的情况下，查询重新模块会根据下面这些条件来决定是否使用 重写 在大多数情况下，用户提交的 句于创建 查询都不完全一致，这时候 要做一些额外的工作来利用 的数据生成用户需要的结果。这个这个额外的工作就是补偿。 允许匹配 在下列情况下会使用 进行优化： 超集谓词且完全匹配 这是最简单的情况，用户查询与 有相同的表，相同的表达式，请求的结果完全属于 据集。这里 的谓词必须是用户查询谓词的超集。 聚合函数和成组列 聚合是把相关的记录分组汇总，通常在具有更少的记录数。没必要为每种类型的 义一个 特定的情况 下，即时用户的 法与 的不同， 19 能使用 如，如果 的 Y 的粒度更细，则 以在 即补偿）。 多表 如果用户查询中存在 没有的表，并且其与基础表的关联谓词能够用 之关联来代替，那 能使用 少表 如果用户查询中的表比 的表少，并且引用完整性存在的话， 能匹配 达式 通常要匹配具有复杂表达式的查询要求这些表达式在 也要以相似的方式使用。通常的情况下， 能识别。比如，如果 的 Y 和 句，那么 能匹配具有相同 句的用户查询。 抑止匹配 下来情况会抑止查询优化器对 使用。 包含如下内容 包含如下内容的 会用 化 如，当存在触发器时，查询能从同时是 据 递规或其它复杂语句 物理属性函数比如 外连接 窗口聚合函数。也即带 句的聚合 查询中包含 没有的列 如 果 漏掉了基础表中的一些列，而在用户查询中恰好应用了它们，则不会使用 的谓词