数据仓库设计

数据仓库设计第1页/共91页提纲1.数据仓库的发展2.数据仓库的概念及特性3.数据仓库的结构4.数据仓库的开发过程5.数据仓库的典型应用第2页/共91页

数据仓库的发展

DevelopmentofDataWarehouse第3页/共91页数据仓库的发展（1）NCR公司为Wal-mart建立了第一个数据仓库。1996年，加拿大的IDC公司调查了62家实现了数据仓库的欧美企业，结果表明数据仓库为企业提供了巨大的收益。IBM的实验室在数据仓库方面已经进行了10多年的研究，并将研究成果发展成为商用产品。其他数据库厂商在数据仓库领域也纷纷提出了各自的解决方案。第4页/共91页数据仓库的发展（2）IBM:在其DB2UDB发布一年后的1998年9月发布5.2版，并于1998年12月推向中国市场，除了用于联机分析处理（OLAP）的后台服务器DB2OLAPServer外，IBM还提供了一系列相关的产品，包括前端工具，形成一整套解决方案。Informix公司:在其动态服务器IDS（InformixDynamicServer）中提供一系列相关选件，如高级决策支持选件（AdvancedDecisionSupportOption）、OLAP选件（MetaCubeROLAPOption）、扩展并行选件（ExtendedParallelOption）等，这种体系结构严谨、管理方便、索引机制完善，并行处理的效率更高，其中数据仓库和数据库查询的SQL语句的一致性使得用户开发更加简便。第5页/共91页数据仓库的发展（3）微软公司:在其SQLServer7.0以及SQLServer2000中集成了代号为Plato的OLAP服务器。Sybase:提供了专门的OLAP服务器SybaseIQ，并将其与数据仓库相关工具打包成WarehouseStudio。Oracle公司:则推出从数据仓库构建、OLAP到数据集市管理等一系列产品包（如OracleWarehouseBuilder、OracleExpress、DataMartSuit等）。

第6页/共91页为什么要建立数据仓库数据大量积累数据丰富、知识贫乏数据—>信息—>知识—>效益的转换需求(DSS)OLTP的局限性第7页/共91页OLTP的局限性

事务处理（操作型处理）和分析处理的性能特性不同

OLTP对数据的存取操作频率高而每次操作处理的时间短；在分析处理环境中，某个DSS应用程序可能需要连续几个小时，从而消耗大量的系统资源。数据保留最新，量少数据松散，集成度不高数据面向应用而非主题数据质量问题第8页/共91页数据库应用的规模和深度的发展—高级数据库从在线事务处理(OLTP)到在线分析处理(OLAP)、数据挖掘(DataMining)和决策支持(DS)第9页/共91页第10页/共91页突出的问题数据库适于存储高度结构化的日常事务细节数据，决策者可能并不关心具体的细节信息；存取操作频率高，操作处理的时间短；决策型数据多为历史性、汇总性或计算性数据，多表现为静态数据，周期性刷新；多维性，分析内容复杂；细节数据量太大严重影响分析效率，分散决策者的注意力；连续运行，消耗大量的系统资源；数据来自企业内部或企业外部，在分析时直接对这些数据操作会造成分析混乱。外部一些非结构化数据，数据库系统常无能为力。第11页/共91页多库系统的限制可用性：源站点或通信网络故障将导致系统瘫痪,源站点不能通过网络在线联入多库系统。响应速度：全局查询多级转换和通信传输,延迟和低层效率影响响应速度。系统性能：总体性能取决于源站点中性能最低的系统,影响系统性能的发挥;系统开销：每次查询要启动多个局部系统,通信和运行开销大。第12页/共91页实施数据仓库的条件数据积累已达到一定规模面临激烈的市场竞争在IT方面的资金能得到保障

第13页/共91页

数据仓库的概念

DataWarehouse第14页/共91页数据仓库的概念

数据仓库已被多种方式定义，使得很难提出一种严格的定义。按照W.H.Inmon这位数据仓库系统构造方面的领头设计师的说法：数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合，支持管理部门的决策过程。与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程——建立数据仓库看作构造和使用数据仓库的过程。第15页/共91页数据仓库特性

面向主题典型的主题领域：客户；产品；交易；帐目集成的数据提取、净化、转换、装载非易失的数据仓库的数据通常是一起载入和访问的，但并不进行一般意义上的数据更新随时间的变化性数据仓库中的时间期限要远远长于操作型系统中的时间期限（5~10年）；数据仓库中的数据是一系列某一时刻生成的复杂的快照；数据仓库的键码结构总是包含某时间元素。第16页/共91页数据仓库OLTP数据库管理层使用一线工人使用战略性价值策略性价值支持战略定向支持日常操作

用于联机分析用于事务处理面向主题面向应用程序存储历史数据仅存储当前数据不可预测查询模型可预测查询模型数据仓库与OLTP数据库

第17页/共91页数据集市数据集市（datamart）是数据仓库的一个部门子集，它针对选定的主题，对于特定的用户是有用的。数据集市分为独立的和依赖的两类。独立的数据集市中，数据来自一个或多个操作的系统或外部信息提供者，或者来自在一个特定的部门或地域局部产生的数据。数据集市中的数据直接来自企业数据仓库。第18页/共91页操作型数据存储

很多情况下，DB-DW的两层体系结构并不能涵盖企业所有的数据处理要求。日常管理和控制决策的问题并不是联机事务处理，又算不上高层决策分析，需要企业全局一致的、细节的、当前或接近当前的数据，又需要面向主题、集成的数据环境。因此需要DB-DW之间存在着一个中间层次，即操作型数据存储ODS（OperationalDataStore）。第19页/共91页操作型数据库、ODS和DW的比较比较项目操作数据存储数据仓库数据内容当前和最近的值存档、归纳数据和经计算得出的数据数据组织根据主体域---数据集成面向主题数据性质动态（经常变化）静态（刷新时除外）数据结构和格式复杂到简单简单：适于商业分析访问概率高到中中到低数据更新无更新访问和生成：没有直接地更新数据访问每个事务访问几条记录每个事务访问多条记录用途高度结构化、重复处理和事务处理和交互式分析处理对响应时间的要求低于1秒到2~3秒几秒到几分，有时几小时对性能的要求中到高中ODS和DW的比较第20页/共91页数据仓库的结构Structureof

DataWarehouse第21页/共91页数据仓库结构

数据仓库

MRDB

MDDB

数据抽取数据净化数据载入信息发布系统操作型数据和外界数据

数据集市报表,查询,EIS工具OLAP工具数据挖掘工具管理平台元数据管理平台第22页/共91页

数据仓库

可视化用户接口OLAP工具查询/报表工具数据挖掘工具前端开发工具集成器集成器转换器转换器源数据源数据

元数据

及其管理工具

数据仓库体系结构第23页/共91页数据仓库组成数据源数据抽取（Extraction）、转换（Transformation）、集成、装载（Load）和刷新（Refresh）工具：格式、净化和汇总数据建模工具（ModelingTools）元数据仓储（MetadataRepository）数据仓库监控（Monitoring）和管理（Administration）工具：维护数据仓库中的数据，备份、恢复数据以及管理数据的安全权限问题。数据仓库及数据集市的目标数据库（TargetDataBase）OLAP服务器前端数据访问和分析工具

第24页/共91页转换器转换器的功能：数据结构转换和数据类型转换非结构化数据的转换创建数据准备区N开始读源数据检查数据准备区?执行DTS包更改元数据（时间，数据状态）结束成功连接源数据库创建DTS包Y第25页/共91页数据准备区从源数据中提取数据，转换成数据仓库所要求的格式后存储在数据仓库的一个称为数据准备区的缓冲区中。在该区域中，可以暂时存储原始数据，然后由集成器对数据进行清理、集成后再装载到数据仓库中。源数据数据准备区数据仓库第26页/共91页集成器数据净化（有效值和范围检验）维表与事实表的引用完整性检验：当维表和事实数据表之间的引用完整性破坏时，这类查询可能会导致检索数据不准确或不同查询之间数据的不一致性错误。统一数据编码日期格式转换测量单位的转换第27页/共91页监控器捕捉数据变化的途径时标方法：在记录中插入新的时标或加上更新时的时标，然后根据时标判断哪些数据是变化的，并把变化的数据追加到数据仓库中去。DELTA文件：该文件是由应用产生的，并记录了应用所改变的所有内容。利用DELTA文件记录数据的变化，不需要扫描整个数据库，所以效率较高，但生成的DELTA文件的应用并不普遍。映象文件：在上次提取数据库数据到数据仓库之后及本次提取数据库数据之前，对数据库分别作一次快照，然后通过比较两幅快照的不同来确定要追加的数据。这种方法需要占用大量的系统资源，对系统的性能影响比较大。日志文件：由于日志文件是数据库的固有机制，所以它对系统性能的影响比较小，另外它还有DELTA文件的优点，提取数据只局限于日志文件而不用扫描整个数据库。日志文件是最可行的一种方法。第28页/共91页仓库数据库乎总是一个关系数据库系统；OLAP服务器用于多维分析；客户层，包括查询和报告工具、分析工具和/或数据挖掘工具。三层结构的数据仓库（1）第29页/共91页三层结构的数据仓库（2）客户端：可视化的用户界面客户端通信组件应用服务器端：服务器端通信组件调度组件安全组件元数据管理器转换器集成器数据库服务器端源数据元数据库数据准备区数据仓库第30页/共91页数据仓库中的数据组织高度综合级轻度综合级当前综合级早期细节级多级数据从事务型处理环境中提取的源数据经过综合后，首先进入当前细节级，并根据需要进行进一步的综合进入轻度综合级或高度综合级，老化的数据将进入早期细节级。第31页/共91页粒度粒度影响数据仓库中的数据量和查询的种类；聚合是构成维内不同层次的数据集，使用户能够在维度内的不同层次上观察数据。第32页/共91页元数据要有效的管理数据仓库，必须设计一个描述能力强、内容完善的元数据。元数据描述了数据仓库中源数据和目标数据本身的信息，定义了从源数据到目标数据的转换过程。元数据可用文件存在元数据库中。第33页/共91页元数据的种类转换元数据：为了从事务处理型环境向数据仓库中转换而建立的元数据，它包含了所有源数据的信息、事务描述、数据结构的定义、提取数据和传送数据的算法、综合数据和净化数据的规则、数据访问和传送的记录等。DSS元数据：在数据仓库中用来与终端用户的多维商业模型/前端工具之间建立映射，常用来开发更先进的决策支持工具。第34页/共91页元数据的内容与数据库的数据字典中相似的内容数据仓库的主题描述外部数据和非结构化数据的描述记录系统定义逻辑模型的定义数据进入数据仓库的转换规则数据的提取历史粒度的定义数据分割的定义广义索引有关存储路径和结构的描述关于源数据的元数据关于数据仓库映射的元数据关于系统安全的元数据。与设计时采用的具体技术以及具体应用环境有关的内容与传统数据库系统的数据字典中相似的内容。数据仓库的主题描述。外部数据和非结构化数据的描述。记录系统定义。逻辑模型的定义。数据进入数据仓库的转换规则。数据的提取历史。粒度的定义。数据分割的定义。广义索引。有关存储路径和结构的描述第35页/共91页数据仓库的虚拟存储方式数据仓库中的数据仍然存储在源数据库中，只是根据用户的多维分析需求而形成多维视图，临时在源数据库中找出并提取所需要的数据，完成多维分析。优点：比较简单、花费少、使用灵活缺点：要求源数据库的组织比较规范、数据完备并没有冗余，同时又比较接近多维数据模型时，而一般数据库难以满足这些要求，在实际应用中难以有效建立。第36页/共91页数据仓库的数据组织形式（1）简单堆积文件：每天从操作型数据库中提取加工后的数据逐日积累的存储起来。存储的数据细节化程度很高，可以应付多种细节查询，但分析时查询的效率较低。操作型数据每日事务处理每日综合2月1日2月2日2月3日。。。3月1日3月2日3月3日。。。1月1日1月2日1月3日。。。第37页/共91页轮转综合文件：数据存储单位被分为日、周、月、年等几个级别，逐级综合。

每日事务处理每日综合操作型数据第1天第2天第3天…第7天第1周第2周第3周…第5周第1月第2月第3月…第12月第1年第2年第3年…第n年数据仓库的数据组织形式（2）第38页/共91页简单直接文件：类似于简单堆积文件，但它是间隔一定时间的数据库快照，比如每隔一星期或一个月作一次。连续文件：通过两个比较简单直接文件的不同而生成的。

1月份彩电销售海尔68长虹100东芝20熊猫10……

……2月份彩电销售海尔150长虹90东芝40熊猫30……

……海尔1月份至今218长虹1月份至今190东芝1月份至今60熊猫1月份至今40……

…………数据仓库的数据组织形式（3）第39页/共91页数据仓库建模

DataWarehouseModeling第40页/共91页

星型图模型

物理数据模型概念模型逻辑模型物理模型面向用户的需求细化层次更详细的技术细节数据仓库的数据模型信息包图第41页/共91页信息包图（概念模型）信息包图：数据仓库的数据模型的最高层。由于大多数商务数据是多维的，但传统的数据模型表示三维以上的数据有一定困难。这种模型集中在用户对信息包的需要，信息包提供了分析人员思维模式的可视化表示。工作：确定系统边界：决策类型、需要的信息、原始信息确定主题域及其内容：主题域的公共键码、联系、属性组确定维度：如时间维、销售位置维、产品维、组别维等确定类别：相应维的详细类别确定指标和事实：用于进行分析的数值化信息第42页/共91页销售分析的信息包图日期销售地点销售产品年龄组别性别年(10)国家(15)产品类(6)年龄组(8)性别组(2)季度(40)区域(45)产品组(48)月(120)城市(280)产品(240)区(880)商店(2000)指标和事实:预测销售量、实际销售量、预测偏差信息包：销售分析 维度类别第43页/共91页多维数据模型数据仓库基于多维数据模型。该模型将数据看作数据立方体(datacube)形式，允许以多维对数据建模和观察。它由维和事实定义。维是关于一个组织想要记录的透视或实体。每一个维都有一个进一步描述维的表相关联，即维表。第44页/共91页以三维角度观察销售数据第45页/共91页数据立方体第46页/共91页以四维角度观察销售数据4-D立方体看成3-D立方体的序列，依此类推第47页/共91页数据模型（逻辑模型）最流行的数据仓库数据模型就是多维数据模型，这种模型可以以星型模式、雪花模式或事实星座模式存在。数据仓库通常使用事实星座模式，因为它能对多个相关的主题建模。对于数据集市，流行星型或雪花模式，因为它们都适合对单个主题建模。多维数据模型围绕中心主题组织。该主题用事实表表示。事实表：用来存储事实的度量值和各个维的码值，维表用来存放维的元数据（维的层次、成员类别等描述信息）。第48页/共91页Time_idSalesTableDiscount%DollarsUnits"FactTable"Market_idProduct_idScenarioProduct_idProductTableSizeBrandProduct_Desc"DimensionTable"Time_idYearQuarterPeriod_DescPeriodTable"DimensionTable"ScenarioTableActualProfitScenario"DimensionTable"Market_idMarketTableRegionDistrictMarket_Desc"DimensionTable"星型模型(StarSchema)Budget第49页/共91页雪花模式(snowflakeschema)雪花模式是星型模式的变种，其中某些维表是规范化的，因而把数据进一步分解到附加的表中。雪花模式和星型模式的主要不同在于雪花模式的维表可能是规范化形式，以便减少冗余。由于执行查询需要更多的连接操作，雪花模型可能降低浏览的性能。第50页/共91页第51页/共91页事实星座复杂的应用可能需要多个事实表共享维表，这种模式可以看作星型模式集，因此称为星系模式(galaxyschema)，或事实星座(factconstellation)

。第52页/共91页第53页/共91页第54页/共91页数据挖掘查询语言数据挖掘查询语言DMQL（dataminingquerylanguage）是一种基于SQL的数据挖掘查询语言。DMQL包括定义数据仓库、数据集市、挖掘概念/类描述、关联和分类的语言原语。第55页/共91页数据仓库和数据集市可以使用两种原语定义：一种是立方体定义，一种是维定义。立方体定义语句具有如下语法形式：

definecube<cube_name>[<dimension_list>]:<measure_list>维定义语句具有如下语法形式：

definedimension<dimension_name>as(<attribute_or_subdimension_list>)定义星型、雪花和事实星座模式第56页/共91页例1第57页/共91页

数据立方体sales的time,item和location维可以与数据立方体shipping共享在定义数据立方体shipping语句之下，用“definedimensiontimeastimeincubesales”

说明。例2第58页/共91页度量的计算数据立方体度量(measure)是一个数值函数，该函数可以对数据立方体的每一个点求值。大部分度量可以根据其所用的聚集函数分成分布的和代数的：一个度量是分布的，如果它可以用分布聚集函数count(),sum(),min()和max()得到。一个度量是代数的，如果它可以用代数聚集函数average()、min_N(),max_N()和standard_deviation()得到。第59页/共91页在图中，sales星型模式包含两个度量dollars_sold和units_sold。例3第60页/共91页其中DMQL说明被翻译成如下SQL查询，这些查询产生所需要的sales_star数据立方体。聚集函数sum用于计算dollars_sold和units_sold。

第61页/共91页概念分层概念分层(concepthierarchy)定义一个映射序列，将低层概念映射到更一般的高层概念。如每个城市可以映射到它所属的省或州。这些省和州依次可以映射到它所属的国家。国家可以映射到它所属的大洲。概念分层也可以通过将给定维或属性的值离散化或分组来定义，产生集合分组分层。在多维数据模型中，数据组织成多维，每维包含由概念分层定义的多个抽象层。这种组织为用户从不同角度观察数据提供了灵活性。第62页/共91页物理数据模型物理数据模型：星型模型等在数据仓库中的实现，如物理的存取方式、数据存储结构等。在物理设计时，常常要按数据的重要程度、使用频率以及对响应时间的要求进行分类，并将不同类的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间高的数据就存放在高速存储设备上，如硬盘；存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上。第63页/共91页数据建模注意问题必须回答紧迫的问题；必须有正确的事实表；将有正确的维表，描述必须按最终用户的业务术语表达；必须理解数据仓库所影响的公司过程或影响数据仓库的公司过程；对于事实表，应该有正确的“粒度”；根据需要存储正确长度的公司历史数据；以一种对于公司有意义的方式来集成所有必要的数据；创建必要的聚合表；创建必要的索引；能够加载数据仓库数据库并使它以一种适宜的方式可用。第64页/共91页

数据仓库开发过程

BuildingtheDataWarehouse第65页/共91页应用A应用B应用C收集应用需求分析应用需求构建数据库系统实施系统测试应用编程DBSDLC方法数据仓库建模数据获取与集成构建数据仓库理解需求系统测试DSS应用编程DWCLDS方法DB外部数据DB数据仓库的CLDS设计方法第66页/共91页数据仓库的设计思想为了提高系统的效率和性能，数据仓库的数据内容、结构、粒度、分割以及其他物理设计需要根据用户所返回的信息不断地调整和完善，而且数据仓库需要通过不断地理解用户的分析需求，向用户提供更准确、更有用的决策信息，所以数据仓库对灵活性和扩展性有较高的要求，它的建立是一个动态、循环和反馈的过程。“让我看看能得到什么，然后我才能告诉你我需要什么。”数据驱动的原型法第67页/共91页数据仓库设计的技术要求对大量数据的组织和管理。数据仓库中的数据是从数据库中提取得来的，不必关心它的数据安全性和数据完整性，它要求进行大量数据的组织与管理。支持高性能的复杂分析。复杂分析时通常涉及大量数据的聚集、综合等，在进行复杂查询时经常会使用多表的联接、累计、分类、排序等操作，这对数据仓库基于的数据库系统的性能特别是并行处理能力提出了挑战。对提取出来的数据进行集成。数据仓库中的数据是从多个应用领域中提取出来的，在不同的应用领域和不同的数据库系统中都有不同的结构和形式。如果直接对这些数据进行分析，会得到不同的结果，所以如何对数据进行集成也是构建数据仓库的一个重要方面。对高层决策的最终用户提供工具。数据仓库只是一个数据存储的集合，如果没有各种分析应用工具，一个庞大的数据仓库是毫无意义的。这些工具的设计对于开发一个完整的数据仓库及其应用体系是致关重要的。第68页/共91页数据仓库的设计步骤

任务和环境的评估：业务现状、数据源所在系统和其中的数据的状况、可行性、障碍、评定系统成功与否的基本原则，需要企业高层负责人参加，组成项目组、正规的文档记载

需求的收集和分析

数据模型设计：高层设计、中层设计低层设计

定义记录系统

数据仓库生成

数据仓库技术的培训第69页/共91页高层设计（概念模型设计）高层设计：主要考虑商业过程和商业需求的集成，将与目前商业过程有关的信息和数据仓库试图实现的目标合并在一起，创建信息包图。创建信息包图的过程：分析用户需求，收集信息将信息打包的过程。分析用户需求（确定系统边界）：确定用户要做的决策类型确定用户决策时需要的信息确定原始信息决定数据仓库所需要的信息的级别定义关键性能指标（确定主要的主题域）：主题域的公共键码主题域间的联系充分代表主题的属性第70页/共91页高层设计（概念模型设计）定义维度：每一个维代表一个统一的访问数据仓库中信息的途径。这些维也定义了一个完整的主题分类，而且这些分类将被用作支持主要指标的参考内容。在定义维度时，一般只涉及信息的主要途径，不是企图涉及所有可能的路径。定义类别：类别提供了一个指定维的详细信息，它们是一个集合层或一个维度体系。随着维度的定义，应该进一步确定用户将怎样对详细信息进行检索，或者怎样聚集数据。第71页/共91页高层设计（概念模型设计）创建信息包图确定涉及的主题域，例如：时间、顾客、地位置和产品。设计可以跟踪的确定一个事件怎样被完成和运行的关键指标。决定在给定的用户分析或查询中实际包含了多少数据。确定用户如何按层次聚合数据和移动数据。决定数据层次。估计数据仓库的大小。确定一个数据仓库里数据的更新频率。定义如何访问数据。决定数据如何被传递给仓库的用户。第72页/共91页技术准备工作技术评估管理大数据量数据的能力；进行灵活数据存取的能力；根据数据模型重组数据的能力；透明的数据发送和接收能力；周期性成批装载数据的能力；可设定完成时间的作业管理能力。技术环境准备预期在数据仓库上分析处理的数据量有多大?如何减少或减轻竞争性存取程序的冲突?数据仓库的数据量有多大?进出数据仓库的数据通信量有多大?确定软硬件的配备要求直接存取设备网络操作系统数据仓库管理软件与查询、分析工具第73页/共91页中层设计（逻辑模型设计）中层设计：建立数据仓库的逻辑模型，对前期收集的信息的细化，将信息包图转换成星形模型。主要工作：定义指标实体。将信息包图中的内容放到星形图中，每个信息包图代表一个完整的星和信息包。维度实体在指标实体中表示。定义维度实体。信息包图中的每一个维度实体位于星形图的星角上，它以维度表的形式存在。随着维度实体在星形图上的定位，进一步定义它与指标实体间的关系。定义详细类别实体。在一个简单的星形模型中，指标实体被用于访问的维度实体包围。但是在有的决策分析中仅仅知道指标值是不够的，需要定义详细类别实体，将星型模型转换为雪花图模型。设计成果：适当的粒度划分合理的数据分割策略适当的表划分定义适当的数据源第74页/共91页低层设计（物理数据模型设计）低层设计阶段的任务：建立数据仓库的物理模型，确定数据仓库的存储结构、数据的存储位置和索引策略。设计人员需要了解和考虑的问题：所选用的数据库系统，特别是存储结构和存取方法；数据环境、数据的使用频率、使用方式以及响应时间；存储设备的特性等。主要工作：确定数据的存储结构。不同的存储结构有不同的实现方式，应综合考虑存取时间、存取空间利用率和维护代价等因素，根据各种存储结构的优缺点和适用范围选择合适的存储结构。确定数据的存储位置。对数据按照其重要程度、使用频率和对响应时间的要求等进行分类，并将不同类别的数据存储在不同的存储设备中。设置存储分配参数，对块的大小、缓冲区的大小和个数等进行物理优化处理。确定索引策略。通过对数据存取路径的分析，为各个数据存储建立专用的索引，以获得存取的高效率。第75页/共91页数据仓库生成设计接口从面向应用和操作的环境生成完整的数据基于时间的数据转换数据的聚合对记录系统进行扫描，以便追加数据数据装入确定数据装入的顺序过滤无效或错误数据数据老化数据粒度管理数据刷新第76页/共91页接口设计数据仓库中的数据是从数据库系统中提取出来的，所以在需要在数据库系统和数据仓库之间建立一个接口。建立这种接口，并不是简单的编制一个提取程序。由于数据库中的数据与数据仓库中的数据有很大区别，所以在设计接口时，除了提取外还要完成数据的净化、集成等。接口应包括转换器、监控器和集成器等，以完成对数据的提取、净化和集成。第77页/共91页数据提取数据的提取是数据仓库成功的关键。在提取过程中，为了支持实际应用中的趋势分析，它还必须对数据基于时间进行转换。在大多数情况下，把数据库系统中的数据变化提取出来是通过访问数据库日志进行的。在数据提取时应考虑建立可靠的复制机制，使复制不受诸如系统失败之类问题的影响，保证传送符合数据完整性规则的一致数据，并优化传送过程，减少在捕获或修改数据和传送复制结果之间的等待时间。复制机制包括数据发布器和数据阅读器。数据发布器是原始的或控制的源,它控制了从企业内部来的数据的捕获和净化；数据阅读器是一种对数据访问的系统。第78页/共91页数据装入数据装入：即运行数据仓库的接口程序，将数据装入数据仓库中。主要工作：按顺序装入数据。最初只装入一部分数据来生成第一个主题域，这样能使设计人员轻易而迅速的对所做的工作进行调整，然后再依次装入全部数据。检查数据的有用性。数据仓库的设计过程是一个反馈、循环的过程，原先对决策分析起作用的数据随着时间的推移越来越陈旧无法再支持决策分析，通过与用户的交流，反复进行用户需求分析，从而确定用户真正需要的数据，清除老化、无效和错误数据，不断的适应用户的需求。第79页/共91页数据仓库的使用构建数据仓库的最终目的是为了使用，如果数据仓库中存放了大量的数据而没有开发相应的应用程序就失去了其存在的价值。数据仓库的目的是用于决策分析而不是事务管理。决策分析应用可分为两种类型：例行分析处理和启发式分析处理。例行分析处理是指一些要求比较明确、需要重复进行的分析处理，通常属于部门级的应用，如部门的销售分析、财务分析、报表分析等；启发式分析是指随机性较大的、即时进行的分析处理，通常属于企业高层决策者级的应用，这种决策分析并没有固定的模式，决策者受到某种信息的启发而进行一些随机的决策分析。对于例行分析处理，由于其分析模式固定，因此可以使用查询/报表工具、固定模式的验证工具或OLAP工具来实现。对于启发式分析处理则需要在验证工具、OLAP工具和数据挖掘工具中为用户提供一个灵活的、功能强大的交互式界面，使决策者能够方便地利用这些工具循环渐进地进行决策分析，最终获得分析结果。第80页/共91页数据仓库的维护系统维护：是在系统已经交付使用之后为了改正错误和为了满足新的需要而修改系统的过程。数据仓库中数据的日常管理工作：清除过时的、不再使用的数据；定期从源数据中提取数据，刷新数据仓库中的数据；管理元数据等。数据仓库系统的完善工作：改正性维护：在数据仓库设计与开发过程中，虽然已经进行了严格的测试，但对于一个大型的系统可能还潜藏着一些。适应性维护：数据仓库的构建是基于当时的技术条件的，由于计算机科学技术发展十分迅速，每隔一定的周期硬件设备和系统软件都会发生重大的变革，适应性维护就是为了与变化了的环境相配合而进行的对系统进行修改的活动。完善性维护：因为数据仓库系统一般是采用快速原型法开发的，需要在系统的运行过程中不断地听取用户对已有功能的修改建议和增加新功能的需求，使系统日趋完善。预防性维护：预防性维护则是指为了改进系统未来的性能和功能打下基础而进行的修改工作。第81页/共91页自顶向下的构造方法数据集市外部数据数据集市建造企业数据仓库建设中心数据模型一次性的完成数据的重构工作最小化数据冗余度和不一致性存储详细的历史数据从企业数据仓库中建造数据集市得到大部分的集成数据直接依赖于数据仓库的可用性操作数据问题投资效益的时间?建设中心数据模型的必要性和可能性?初始费用?企业数据仓库第82页/共91页自底向上的构造方法数据集市建立部门数据集市限制在一个主题区域快速投资收益区域自治–设计的可伸缩性强对相关部门的应用容易复制对每个数据集市需要数据重构存在一定的冗余及不一直性逐步扩展到企业数据仓库(EDW)把建造EDW作为一个长期的目标存在的问题:数