结构良好的数据仓库设计.docx

《结构良好的数据仓库设计.docx》由会员分享，可在线阅读，更多相关《结构良好的数据仓库设计.docx（70页珍藏版）》请在三一办公上搜索。

1、结构良好的数据仓库设计3.1 数据的两种组织形式：操作数据和分析数据当同一数据使用不同组织形式的时候，其作用也有所不同。把企业中需要使用的这些数据形式进行分类，一般可以分成两类：操作数据和分析数据。这两种数据都可以存储在DBMS中进行管理。它们的组织形式实际上源于并作用于两种系统：操作型系统和分析型系统。3.1.1 操作型系统和分析型系统的分离传统的企业信息化实现的是用计算机信息处理代替人工信息处理，主要解决的是业务上的数据流问题。随着这类系统的逐渐增多，便针对这些系统产生了数据的多维信息查询需求，于是用于事务处理的数据环境和用于数据分析的数据环境的分离就成为了必然。操作型处理以传统的数据库为

2、中心进行企业的日常业务处理。比如连锁超市每一种商品的进货处理和每一笔销售业务的处理等。分析型处理以数据仓库为中心分析数据背后的关联和规律，为企业的决策提供可靠有效的依据。比如，通过对超市近期数据进行分析可以发现近期畅销的产品，从而为公司的采购部门提供指导信息。又如，对于一个大型的连锁超市，如果能够将各个营业点不同时期的营业情况以非常直观的方式展现给管理人员，则管理人员可以根据这些分析结果决定是否需要撤销营业情况极差的营业点，而在客户流量特别大的超市附近增设营业网点。操作型系统的使用人员通常是企业的具体操作人员，处理的数据通常是企业业务的细节信息，其目标是实现企业的业务运营；而分析型系统的使用人

3、员通常是企业的中高层的管理者，或者是从事数据分析的工程师。分析型系统包含的信息往往是企业的宏观信息而非具体的细节，其目的是为企业的决策者提供支持信息，操作型系统和分析型系统的划分如图3-1所示。图3-1 操作型系统和分析型系统的分离操作型处理和分析型处理的分离，划清了数据处理的分析型环境与操作型环境之间的界限，从而由原来以单一数据库为中心的数据环境发展为以数据库为中心的业务处理系统和以数据仓库为基础的分析系统。企业的生产环境，也由以数据库为中心的环境发展为以数据仓库为中心的环境。操作型系统根据其特点也称联机事务处理（OLTP），存储操作数据，称为数据库。分析型系统也称联机分析处理（OLAP），

4、一般把存储分析数据的数据库称为数据仓库。3.1.2 事务处理和分析处理的对比OLAP系统与OLTP系统从本质上来说是不同的。许多OLTP中的功能需求和OLAP的功能需求都不一致，有的甚至是相反的。表3-1是2种数据处理系统的功能特点比较。表3-1 OLAP与OLTP功能特点对比事务处理（OLTP）分析处理（OLAP）处理个别记录关注一般趋势高生产率（每天数百万事务处理记录）低生产率（每天只有少数操作）系统的操作改变数据系统的操作可以回答问题查询只涉及几条记录查询经常波及整个数据库许多操作更改源数据大多数操作是只读的需要完全实时更新经常批量更新（例如晚上或周末）能很快反应新数据最终反应新数据由表

5、3-1可见，OLAP与OLTP是2类不同的应用，OLTP面对的是操作人员和低层管理人员，OLAP面对的是决策人员和高层管理人员；OLTP是对基本数据的查询、增、删和改操作处理，它以数据库为基础，而OLAP更适合以数据仓库为基础的数据分析处理。OLAP中历史的、导出的及经综合提炼的数据均来自OLTP所依赖的底层数据库。OLAP数据较之OLTP数据要多一步数据多维化或预综合处理，建立不同级别的统计数据，从而满足快速统计分析和查询的要求。除了数据及处理上的不同外，OLAP前端产品的界面风格及数据访问方式也同OLTP有别，OLAP多采用便于非数据处理专业人员理解的方式（如多维报表和统计图形），查询提出

6、及数据输出直观灵活，用户可以方便地进行逐层细化、切块与切片和数据旋转等操作（详见第6章）；而OLTP多为操作人员经常用到的固定表格，查询及数据显示也比较固定和规范。例如，在第2章用Reporting Service和Excel 2007为福马特商店创建的多维分析报表实际上就是OLAP系统运行的结果。有了以上事务处理和分析处理的区别和联系，就可以相应地得出操作型数据和分析型数据的关系。3.1.3 操作型数据与分析型数据的对比由上面对业务操作和商务分析2种过程的比较可知，如果把用于OLTP系统的数据直接应用于商务数据分析和决策支持活动就会面临许多困难。主要表现在4个方面。其一是事务处理的数据之间往

7、往需要用复杂的关系来保证快捷性、一致性和实时性，要将其用于分析，则需要创建特殊查询语句，而此项工作只有数据库技术专家才能做好，这很明显不符合进行商务数据分析的用户群的需要；其二是在进行事务处理的系统中进行大量的数据分析，会影响在线事务的处理速度和性能；其三是在事务处理数据库中执行复杂的查询时，会由于速度过慢而影响分析的效率和决策的执行；最后，事务处理数据库中的数据会由于经常改变而影响数据分析的一致性。功能决定其结构。按照表3-1对OLTP和OLAP的功能对比，可以对应地得出其相应数据的区别，如表3-2所示。表3-2 操作型数据与分析型数据的区别操作型数据分析型数据表示业务处理的动态情况表示业务

8、处理的静态情况在存取的瞬间是正确的代表过去的数据可更新，由录入人员或经过专门培训的输入事务而更新不可更新，终端用户的访问权限常常是只读的处理细节问题受到更多关注的是结论性的数据，是综合的，或是提炼的操作需求事先可知，系统可按预计的工作量进行优化操作需求事先不知道，永远不知道下一步用户要做什么有许多事务，每个事务影响数据的一小部分有数目不多的一些查询，每个查询可访问大量数据面向应用，支持日常操作面向分析，支持管理需求用户不必理解数据库，只是输入数据用户需要理解数据库，以从数据中得出有意义的结论由上表可知，操作数据是处于不断变换和更新之中的，属于动态数据。比如通过订单输入程序输入的订单数据就属于操

9、作数据。分析数据是主要用于对经营业务进行分析，因而用的是历史数据，通常都不会随着时间的推移而发生变化，因此属于静态数据。只有在原始信息错误的情况下，分析数据才会有变动。比如某个时间点的销售额是最终数据，是不可逆的，它可以用于分析销售情况，属于分析数据。分析数据通常是从动态数据源迁移到静态数据源的，因而主要来源于操作数据。环境的变化可能为分析带来其他影响因素，因而来自外部的额外信息也可能是分析数据所需要的。下面就在对比这两类数据的基础上，明确数据仓库的特点。3.1.4 数据仓库的特点数据仓库的特点可以从数据仓库的定义来理解。目前数据仓库的定义是不统一的。公认的数据仓库之父W.Hinmon将其定义

10、为：“数据仓库是支持管理决策过程的、面向主题的、集成的、随时间而变的、持久的数据集合。”他指出了数据仓库面向主题、集成、稳定和随时间变化这4个最重要的特征。1面向主题业务系统是以优化事务处理的方式来构造数据结构的，对于某个主题的数据常常分布在不同的业务数据库中。这对于商务分析和决策支持来说是极为不利的，因为这意味着访问某个主题的数据实际上需要去访问多个分布在不同数据库中的数据集合。对于商务分析来说，典型的主题域有客户、产品、交易（销售）和收益等。例如在图3-2中示例了一个以零售业为主的企业情况。该企业在以前的企业信息化中已经构建了消费数据库、客户服务数据库和市场信息数据库。其中，消费数据库记录

11、了客户对不同产品的消费情况，客户服务数据库记录了客户的咨询和投诉情况。这2个数据都是客户主题的相关数据。如果直接使用业务系统进行决策支持，则需要分别访问这2个数据库才能获得客户各个侧面的信息，这样将极大的浪费系统处理的时间和效率，并且数据之间的不一致性和不同步问题，将极大影响决策的可靠性。基于以上的原因，数据仓库将这些数据集中于一个地方，在这种结构中，对应某个主题的全部数据被存放在同一数据表中，这样决策者可以非常方便地在数据仓库中的一个位置检索包含某个主题的所有数据。在图3-2中，有客户和市场两个分析主题，客户主题可以从消费数据库和客户服务数据库中获得客户消费和咨询等全方位的信息；市场主题可以

12、从市场信息数据库分析市场的发展趋势。这种按主题的数据组织方法，极大地方便了数据分析的过程。主题的具体分析过程将在下一节学习。图3-2 数据仓库面向主题的特性2集成的全面而正确的数据是有效地进行分析和决策的首要前提。在某一个主题的统帅下，需要将数据进行提取、净化、转换和装载等集成操作。比如在客户主题中，对于客户名称，业务数据库的设计中有的字段名为user_name，类型为char（10），有的字段名是name，类型是varchar（12），但在进入分析数据库时必须使用同一字段的命名和格式。这在SQL Server 2005中实际上是通过SSIS来完成的，但在数据库设计阶段也需要把数据的集成方案设

13、计出来，而具体的操作则主要体现在对SSIS的操作上。3稳定的业务系统一般只需要当前数据，在数据库中一般也存储短期数据，因此在数据库系统中数据是不稳定的，它记录的是系统中每一个变化的瞬态。但对于决策分析而言，历史数据是相当重要的，许多分析方法必须以大量的历史数据为依托。没有历史数据的详细分析是难以把握企业的发展趋势的，因此，数据仓库对数据在空间和时间的广度上都有了更高的要求。在数据仓库中，数据一旦被写入就不再变化了。数据仓库可以看成是一个虚拟的只读数据库系统。在数据集成性中已经说明了数据仓库在数据存储方面是分批进行的，定期执行提取过程为数据仓库增加记录，但是这些记录一旦加入，就不再从系统中删除。

14、正是由于数据仓库的这个显著特点，使得数据仓库不需要在并发读写控制上投入过多的精力，因为所有的用户只是以只读的方式访问数据仓库。图3-3演示了数据稳定性的一个简单的例子。在1月2日，99号客户的消费金额为200元，当时间推移到3月2日，99号客户的消费金额变成250元，这一信息在业务系统中被更新了。但是在数据仓库中（我们假定数据仓库每天进行一次数据提取），3月2日的数据提取结果是在数据仓库中增加了记录222，原先的记录111并没有发生任何的改变，说明99号客户在3月2日的消费金额为250元。可见，数据仓库实际上是为99号客户的消费行为进行了定期的拍照，并将快照存储起来供后续的分析工作使用。图3-

15、3 数据仓库的数据稳定性示例4随时间变化的由于在数据仓库中数据只增不减，这使得数据仓库中的数据总是拥有时间维度。数据仓库实际上就是记录系统的各个瞬态，并通过将各个瞬态连接起来形成动画，从而在数据分析的时候再现系统运动的全过程。数据提取的周期实际上决定了动画间隔的时间，数据提取的周期短，则动画的速度快，图3-4示意了这种特点。图3-4 数据仓库数据随时间变化的特点数据仓库同数据库相比，还具有其他的特点。如数据仓库中的数据不再像数据库中的数据具有严格规范化的特点，这也是由数据仓库的应用需求决定的。数据仓库为了能够在尽量短的时间内将数据呈现给使用人员，使用所谓的“空间换时间”的技术，牺牲了数据的规范

16、化，增加了数据的冗余度，从而减少系统的响应时间。再如，数据库系统和数据仓库系统在硬件的利用模式上具有很大的区别。在数据库环境下，硬件资源利用率总是保持在一个相对稳定的状态，这是由于不断地有事务需要处理。而在数据仓库环境下，系统的硬件资源常常在高利用率和低利用率之间切换。当系统进行数据分析应用时，硬件资源的利用率很高，而系统空闲（数据分析的工作在每天的某些时段进行，并不像事务处理工作那样一直进行）时，硬件资源的利用率就很低，如图3-5所示。图3-5 数据库系统和数据仓库系统的硬件利用率由于数据库系统和数据仓库系统在硬件利用率上的差异，我们难于在同一台服务器上既进行优化操作型处理，又进行优化分析型

17、处理，因此数据库系统和数据仓库系统在物理上应当由不同的服务器来运行。3.2 数据仓库设计方法论数据仓库是商业智能分析和决策支持应用的最基本环境。正如软件开发中的系统分析和系统设计在整个开发周期中占举足轻重的地位一样，数据仓库的分析与设计在开发相关项目中同样也是十分重要的。业务数据库和数据仓库由于两者功能的不同，设计方法必然会有很大的差异。但尽管如此，它们都是在DBMS中管理的，运用类比思维，设计数据仓库的时候，也可以从比较成熟的数据库设计方法论中找寻灵感。实际上，在SQL Server 2005安装的两个示例数据库中，AdventureWorks就是属于操作型的数据库；而AdventureWo

18、rksDW则是分析型数据库，也就是数据仓库，其主要数据都源于AdventureWorks。微软在给出这个设计得十分精巧的数据仓库时，并没有说明此数据仓库是如何得来的，因此下面在研究数据仓库设计方法的时候，就主要以从AdventureWorks数据库到AdventureWorksDW数据仓库的过程为例来解析设计数据仓库过程中的复杂理论。3.2.1 数据库设计与数据仓库设计1业务数据和分析数据使用方式的不同普通数据库直接用于业务处理，因而需要严格约束表与表之间的关系，使数据在完整性等方面得到有效的保证。在设计这一类型的数据库的时，一般是先通过实体关系模型确定数据库中需要存储数据的表，再通过数据规范

19、化方法（如第1、2、3范式等）改变这些表的结构，确定表的主外键，并以主外键为依据，在表之间建立起一对一或一对多的关系。图3-6即为AdventureWorks业务数据库中购买订单、买入商品运输方法和商品提供商等数据表之间的关系。从图中可以看出，对于购买订单报头这个表（PurchaseOrderHeader）而言，与供货商（Vendor）表、购买订单详情表（PurchaseOrderDetail）及运输方法表（ShipMethod）之间的关系是根据实际业务操作中应该有的关系来确定的，这样的数据库系统结构设计用于业务操作的信息化是很合适的。图3-6 业务数据库中的表间关系示例通过3.1节对事务处理

20、和分析处理的比较可以得知，商务分析需要的数据库与业务数据库有很多地方不同，用于OLAP的数据应该是多维的。图3-7即为从购买地区、购买时间和产品名称等3个视角来分析购买订单时需要的一种数据立方。数据立方又称多维数据集，是使用分析数据的典型方式。图3-7 3个视角分析购买订单时需要的数据立方2理解仓库中的立方体在第2章，我们从整体上掌握了商业智能的整个应用过程，相信在此过程中已经有了对数据立方的感性认识。为了理解数据仓库设计的方法，下面从使用的角度理解数据立方。正像在数学中用X、Y、Z坐标轴表示3个空间创建一个立方体一样，可以以不同的商业视角为维度建立一个商业智能分析用的立方体，这些维的属性是立

21、方体的坐标轴。例如可以从客户的视角去观察商业数据，这时应该建立客户维，而客户维中有客户所在的城市这一属性，因而在立方体中会出现城市坐标轴。同样，时间维中的日期属性可以作为坐标轴，产品维中的产品名称可以作为坐标轴出。这个立方体上的1个点包含3个值：用户所在的城市、特定的产品和特定的日期，图3-7的立方体就是这样建立的。通过不同的坐标轴的灵活组合，可以构成各种各样的数据立方体。使用时间仓库时的数据立方体也不都是三维的，由于商务视角的多样性，大多数情况下数据立方是以三维以上的方式组成的。数据立方中多个维度的值是商务需求中需要观察的目标，这个目标的值一般叫度量值。度量值来源于构成商务观察目标的事实表中

22、。例如在图3-7的立方体中，事实表中有全部产品的销售度量，那么，可以用立方体上的某一个点度量某产品在某一时间和某一城市的销售情况。由于商业数据在数据仓库中的这种多维特性，为分析数据提供了极大的方便。如果保持立方体的某些坐标轴的值不变而改变另外某一个轴，便可以看到度量在不同维上的变化情况。在上面的例子中，如果保持产品的名称和日期为常量，沿客户城市坐标轴移动，便可以得到在所有客户城市某一天某一产品的全部销售值。有这种分析需求的一般是地区经理。同样，可以根据财务经理、产品经理及总经理对商务分析的不同需求来对数据立方体进行不同角度的解析，如图3-8所示。图3-8 不同视角的数据立方分析认识事物一般是从

23、此事物在实践中的应用开始的。以上对业务数据和分析数据使用方式的区别及对数据立方的具体使用方法的解析是认识数据仓库的基础。正是由于其作用的不同，所以设计时数据库和数据仓库的目标也不同。3数据仓库的设计目标根据前面对2种数据处理方式的对比，可以得到设计数据库和数据仓库的目标之间的差异，其结果如图3-9所示。图3-9 数据仓库和数据库目标的差异现在的问题是这种多维分析的需求既然不能用业务数据库的方式满足，那又应该怎样解决。实际上，为了在商务分析时能以多个视角对某个业务事实进行操作，构建分析用的数据仓库时引入了维度概念来表示分析视角，事实概念来表示分析对象，事实的量度来表示对象的分析结果。而这些概念在

24、数据分析阶段（本书的第5章将要论述）会得到直接使用或进行一定的改动。因此，这些对象在数据仓库中的设计如何，将直接影响后续的分析工作，而它们之间的关系则构成了整个数据仓库的架构。3.2.2 数据仓库的架构方式及其比较传统的关系数据库一般采用二维数表的形式来表示数据，一个维是行，另一个维是列，行和列的交叉处就是数据元素。关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。数据仓库是多维数据库，它扩展了关系数据库模型，以星形架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但不管是哪一种架构，维度表、事实表和事实表中的量度都是必不可少的组成要素。下面解析由这些要

25、素构成的数据仓库的架构方式。1星形架构星形模型是最常用的数据仓库设计结构的实现模式，它使数据仓库形成了一个集成系统，为最终用户提供报表服务，为用户提供分析服务对象。星形模式通过使用一个包含主题的事实表和多个包含事实的非正规化描述的维度表来支持各种决策查询。星形模型可以采用关系型数据库结构，模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。维度表中的对象通过事实表与另一维度表中的对象相关联这样就能建立各个维度表对象之间的联系。每一个维度表通过一个主键与事实表进行连接，如图3-10所示。图3-10 星形架构示意图事实表主要包含了描述特定商

26、业事件的数据，即某些特定商业事件的度量值。一般情况下，事实表中的数据不允许修改，新的数据只是简单地添加进事实表中，维度表主要包含了存储在事实表中数据的特征数据。每一个维度表利用维度关键字通过事实表中的外键约束于事实表中的某一行，实现与事实表的关联，这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。这种结构使用户能够很容易地从维度表中的数据分析开始，获得维度关键字，以便连接到中心的事实表，进行查询，这样就可以减少在事实表中扫描的数据量，以提高查询性能。在AdventureWorksDW数据仓库中，若以网络销售数据为事实表，把与网络销售相关的多个商业角度（如产品、时间、顾客、销

27、售区域和促销手段等）作为维度来衡量销售状况，则这些表在数据仓库中的构成如图3-11所示，可见这几个表在数据仓库中是以星形模型来架构的。星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中关系模式的基本区别。 使用星形模式主要有两方面的原因：提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中，所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高，同时由于维表一般都很小，甚至可以放在高速缓存中，与事实表进行连接时其速度较快，便于用户理解；对于非计

28、算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。图3-11 AdventureWorksDW数据仓库中部分表构成的星形架构2雪花形架构雪花模型是对星形模型的扩展，每一个维度都可以向外连接多个详细类别表。在这种模式中，维度表除了具有星形模型中维度表的功能外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的，如图3-12所示。雪花模型对星形模型的维度表进一步标准化，对星形模型中的维度表进行了规范化处理。雪花模型的维度表中存储了正规化的数据，这种结构通过把多个较小的标准化表（而不是星形模型中的大的非标

29、准化表）联合在一起来改善查询性能。由于采取了标准化及维的低粒度，雪花模型提高了数据仓库应用的灵活性。这些连接需要花费相当多的时间。一般来说，一个雪花形图表要比一个星形图表效率低。在AdventureWorksDW数据仓库中，以图3-11的架构图为基础，可以扩展出雪花模型的架构，“DimProduct”表有一个详细类别表“DimProductSubcategory”，而“DimCustomer”表也有一个表示客户地区的表“DimGeograph”表作为其详细类别表，将它们加入数据仓库后，整个数据仓库就是雪花形架构，如图3-13所示。图3-12 雪花模型架构示意图图3-13 AdventureWo

30、rksDW数据仓库中部分表构成的雪花形架构3星形与雪花形架构的比较在3.1节的讨论中可以得知，在数据仓库中表与表之间是不必满足3个范式的，也不必考虑数据冗余，相反，为了在分析型查询中获得较好的性能，数据仓库中的表还应该尽量集中同类型的数据，同时把有些常见的统计数据进行合并。按照这种思想，图3-13中的“DimProductSubcategory”表和“DimGeograph”表可以并入“DimProduct”表和“DimGeograph”表中使整个数据仓库呈现星形架构，但是微软在设计AdventureWorksDW数据仓库时并没有这样做，反而在“DimProductSubcategory”表和

31、“DimProduct”表及“DimGeograph”表和“DimGeograph”表之间设计成满足一定范式要求的结构，下面将解释其原因。标准的关系数据表不能满足数据的分析能力，所以对表进行非标准化处理以形成数据仓库中特有的星形架构方式，但这样一来，如果所有的分析维度都作为事实表的一个直接维度，数据的冗余是相当大的，比如将“DimProductSubcategory”表合并到“DimProduct”表中，的确能形成一个关于产品所有属性的维度，但要在一张表中表达产品类别属性和产品的属性，需要的存储空间是相当大的。由此可以看出，在星形架构的基础上扩展出雪花形架构，实质上是在分析查询的性能和数据仓库

32、的存储容量2方面进行权衡的结果。表3-3具体比较了2种类型的架构差异。只有明确了这些差异，才能在设计数据仓库时选择最合适的架构方式。表3-3 雪花形与星形层次结构的差异星 形雪 花 形行数多少可读性容易难表格数量少多搜索维的时间快慢4星座模式一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模式（galaxy schema）。在AdventureWorksDW数据仓库中有多个事实，为了便于显示，取最重要的2个事实表“FactInternetSales”和“FactResellerSales”作为星座模式的例子。由

33、于对网络销售和批发商销售的分析有很多观察视角都是相同的，因而这2个事实表共享的维度表较多，比如促销手段、时间和产品等。在数据库关系图中把它们的关系表现出来后，如图3-14所示。图3-14 数据仓库的事实星座模式示例5数据集市数据集市是在构建数据仓库的时候经常用到的一个词汇。如果说数据仓库是企业范围的，收集的是关于整个组织的主题，如顾客、商品、销售、资产和人员等方面的信息，那么数据集市则是包含企业范围数据的一个子集，例如只包含销售主题的信息，这样数据集市只对特定的用户是有用的，其范围限于选定的主题。数据集市面向企业中的某个部门（或某个主题）是从数据仓库中划分出来的，这种划分可以是逻辑上的，也可以

34、是物理上的。例如在AdventureWorksDW数据仓库中就是逻辑上划分的数据集市。数据仓库中存放了企业的整体信息，而数据集市只存放了某个主题需要的信息，其目的是减少数据处理量，使信息的利用更加快捷和灵活。数据仓库由于是企业范围的，能对多个相关的主题建模，所以在设计其数据构成时一般采用星系模式，AdventureWorksDW数据仓库就是这种情况。而数据集市是部门级的，具有选定的主题，可以采用星形或雪花模式。图3-15是数据仓库、数据集市和数据立方之间的关系，通过此图可以更好地理解这3个概念。图3-15 数据仓库、数据集市和数据立方之间的关系3.2.3 宏观上的数据仓库设计广义的数据仓库包括

35、2部分，一是数据仓库数据库，用于存储数据仓库的数据；二是数据分析部分，用于对数据仓库数据库中的数据进行分析。广义的数据仓库设计应该包括数据仓库数据库的设计和数据仓库的应用设计2个方面，而数据仓库的应用与数据仓库的设计一脉相承，共同构成了数据仓库应用的整个生命周期，这个周期包括3个阶段：数据仓库规划分析阶段、数据仓库设计实施阶段及数据仓库的使用维护阶段。对这3个阶段的分别设计就是数据仓库宏观上的设计。3个阶段是一个不断循环、完善和提高的过程。在一般情况下数据仓库系统不可能在一个循环过程中完成，而是经过多次循环开发，每次循环都会为系统增加新的功能，使数据仓库的应用得到新的提高。图3-16表达了这个

36、循环的运动过程。图3-16 宏观上数据仓库的开发阶段这一个过程将软件工程思想应用在数据仓库的设计中，主要用在大型的数据仓库工程项目中，包含了构建完整应用的全过程，因此在本章不具体讨论此过程的使用细节，本书第10章“基于SSAS的商务智能分析”将会对这个过程中的有些重要步骤进行详细讲解。3.2.4 微观上的数据仓库设计微观上的数据仓库设计实际上指的是数据仓库数据库的设计，亦即宏观上设计仓库设计的第1个部分。在这个层面上主要任务是进行数据建模，确定数据仓库中数据的内容及其构成关系。在数据库的世界里面，数据建模任务通常基于3种不同的视角：概念模型、逻辑模型和物理模型。其中概念模型用来表示真实世界的情

37、况，逻辑模型是从真实世界到数据的物理存放细节的媒介，而物理模型即表示信息存放于硬件中的细节。数据仓库数据库的设计也不例外。在数据仓库的3级数据模型中，概念模型表示现实世界的“业务信息”构成关系，用业务数据库设计中的“实体关系”方法（E-R方法）来设计这一级的数据模型，但需要用分析主题代替传统E-R方法中的实体。在传统业务数据库设计中的逻辑模型一般采用范式规范的表及其关系，数据仓库设计中的逻辑模型也采用表来存储数据，因此也数据仓库中使用的也是关系模型，不过表与表之间不再通过3大范式的规范，而是以星形结构、雪花形结构和星座型结构等方式组成。物理模型则属于这些表的物理存储结构，比如表的索引设计等。数

38、据仓库的设计就是在概念模型、逻辑模型和物理模型的依次转换过程中实现的。作为数据仓库的灵魂元数据模型则自始至终伴随着数据仓库的开发、实施与使用。数据粒度和聚合模型也在数据仓库的创建中发挥着指导的作用，指导着数据仓库的具体实现。图3-17表达了微观数据仓库设计中各种概念之间的关系。图3-17 微观数据仓库设计中各种概念之间的关系图3-18 数据仓库数据库设计的步骤在图3-17的关系图中，元数据是在对企业商业智能需求分析和概念模型设计阶段就应该设计好并且一直贯穿于数据仓库应用全程的重要部分，而数据粒度和聚合的设计则是在逻辑模型的设计过程中完成的，物理模型则需要做一些存储优化方面的工作。具体而言，这3

39、级数据模型设计的每1个阶段都有相应的详细设计步骤，图3-18即是对这些步骤的一个总结。3.2.5 2种创建数据仓库的模式创建数据仓库的方式，根据其出现的先后顺序，主要分为2种模式：自顶向下（Top-down），自底向上（Bottom-Up）。1自顶向下这种模式首先把OLTP数据通过ETL汇集到数据仓库中，然后再把数据通过复制的方式推进各个数据集市中，其优点在于：l 数据来源固定，可以确保数据的完整性。l 数据格式与单位一致，可以确保跨越不同数据集市进行分析的正确性。l 数据集市可以保证有共享的字段。因为都是从数据仓库中分离出来的。2自底向上这种模式首先将OLTP数据通过ETL汇集到数据集市中，

40、然后通过复制的方式提升到数据仓库中，其优点在于：l 由于首先构建数据集市的工作相对简单，所以容易成功l 这种模式也是实现快速数据传送的原型。3.2.6 技术上需要关注的重点步骤本章的主要任务就是完成数据仓库数据库的设计，在图3-18所给出的步骤是数据仓库设计的完整结构，在实践这一步骤的设计工作中，有5个重点步骤需要特别关注，它们是业务数据理解和需求分析、分析主题和元数据、事实及其量度和粒度、维度模式确定和数据仓库的物理存储方式。这5个步骤贯穿了从分析到物理实现的全过程，而且一般的设计过程都是照此进行的，因此可以把它看做是设计数据仓库数据库的实践版本。这5个步骤及其与3级模型的关系可以用图3-1

41、9来表示。图3-19 5步骤及其与3级模型的关系从下面一节开始将分别阐述这5大步实现由业务事实到数据仓库的全过程。3.3 理解历史数据和分析需求历史数据也就是业务数据库，它是数据仓库的数据来源，是构建数据仓库的“物质基础”。需求在每一个工程项目中都很重要，它是数据仓库的价值体现。因此理解历史数据和分析需求是5步中的第1步。下面先从理解“用户驱动数据驱动”的设计理念开始。3.3.1 “数据驱动用户驱动”的设计理念数据驱动是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库。用户驱动也叫需求驱动，是根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。数据仓

42、库的用户一般是企业管理者，分析需求和业务需求有很大差异，因此不能把数据库设计阶段的用户需求直接用在数据仓库设计中。在设计仓库数据库之初把用户的分析需求纳入考虑范围是十分有必要的。同时，数据仓库的构建必需基于业务数据库，业务数据源的结构也是不得不考虑的问题。因此在设计数据仓库的时候，应该坚持用户驱动与数据驱动相结合的设计理念。图3-20所示的是这两种方法结合获取数据仓库设计真正需求的过程。图3-20 用户驱动与数据驱动相结合来获取数据仓库设计真正需求3.3.2 理解业务数据由图3-20可知，通过对业务数据的分析，可以清楚的知道原有的数据库系统中已经有什么，对当前系统设计有什么影响等，也可以为利用

43、已有的数据和代码提供方便。这样，在把业务数据转化为分析数据时，便于按照分析领域对数据（即数据之间的联系）重新考察，组织数据仓库的主题。1理解业务需求是项目的动力，使用则是项目的根本。构建数据仓库归根到底是应用于企业数据分析，辅助管理决策，这是设计人员应该在数据仓库的整个生命周期都牢记于心的。理解业务数据的首要一步就是理解业务，也就是要熟悉企业生产经营流程，同时初步获取在这些流程中的分析需求，为最终确定用户需求做好意识上的准备。例如在Adventure Works Cycles这个经营自行车及其相关配套产品的公司内部，原材料采购、生产和销售及相关的财务和管理等有既定的流程。下面以原材料采购和产品

44、的销售两个业务领域为例进行分析。1）原材料采购在公司内部有采购部负责原材料采购，采购部门下设一个经理和多个采购员。一种原材料有多个供应商，一个供应商可以提供多种原材料。原材料和供应商之间是多对多的关系。每个采购员负责多种原材料的采购，一种原材料只能由一个采购员来采购。采购员和商品之间是一对多的关系。采购员只需了解原材料和供应商的联系，而采购部门经理需要管理员工，并且还需要了解原材料的仓储情况，以确定需要采购的商品并将任务分配给每个采购人员。另外，公司为了防止产品过分依赖于原材料价格，还需要对原材料进行批量存储，因此设立仓库管理部门，专门负责原材料的存储管理，仓库管理部门管理多个仓库，下设一个经

45、理和多个仓库管理员，每个仓库中拥有多个仓库管理员，每个管理员只能在一个仓库中进行工作。仓库管理员需要知道他所管理的仓库中存储的原材料的种类、数量、存储的时间、原材料的保值期及原材料进入仓库和离开仓库的时间等信息。一种原材料可以保存在多个仓库中，一个仓库可以保存多种原材料。仓库管理部门经理不但需要处理仓库管理员需要的数据，而且需要知道仓库管理员的基本信息（比如仓库管理员的家庭住址和电话等）。2）产品销售Adventure Works Cycles的自行车及其相关产品远销北美、欧洲和亚洲市场。公司有网络销售和通过批发商销售两种销售渠道，因此，对于客户也分为两类，其一是个人，即从在线商店购买产品的消

46、费者，其二是商店，即从Adventure Works Cycles销售代表处购买产品后进行转售的零售店或批发店。对于销售部门，销售员关心的是商品的信息，每种商品的价格、质量、颜色和规格等，以便向顾客推销相关的产品。因此，销售员最需要的数据就是商品的信息。销售部门经理不但需要了解商品的销售情况，以便在某种商品缺货的时候通知仓库存储部门运送存储的商品，或者通知采购部门采购相应的原材料。销售部门经理还需要了解每个销售员的工作业绩，对每个销售员进行考核。因此销售部门经理需要了解商品、顾客和部门员工的情况。从上面的分析可以看出，商务数据确实是多维的。不同部门对数据的需求不同，同一部门人员对数据需求也存在

47、差异。如果考虑数据需求的层次问题，管理人员和不同的业务人员对数据要求的程度也各不相同。管理人员可能需要综合度较高和较为整体的数据，而业务人员需要细节数据。在前面分析仓库中的立方体的时候，曾经讲到过要对数据立方进行不同视角的分析（图3-8），在这里可以看到，这种分析是符合业务操作的实际情况的。同时，可以用业务构成图来表达业务理解的分析成果。对于上述的分析，可以用图3-21来表达。需要注意的是，这只是对Adventure Works Cycles公司业务分析的一个简单示例，在实际项目中情况要复杂得多，为了获取这个业务构成图，可能需要借鉴企业信息化中的其他阶段的成果，如可以把ERP构建构成的业务流程

48、重组成果用在这里。有了这样一个清晰表达业务结构的图，就为后面建立分析主题打下了很好的基础。图3-21 业务构成图2理解业务到数据的转化实际上，对业务的理解是信息系统建设过程都需要的，只不过在设计数据仓库的时候理解业务需要着重从业务蕴含的数据的多维性方面来分析。而业务到数据的转化这一步则主要是在构建OLTP系统时使用的。数据仓库都是以历史数据为基础的，这一步本质上是理解这些历史数据的来历。在构建OLTP系统的过程中，一般先把业务转化为E-R图，也称为OLTP的逻辑模型图，这在许多数据库系统设计的书籍里都有详细说明，这里就不再描述。图3-22是把企业业务模型和通过E-R图这种工具转化成数据后的数据表对应起来的一种关系图。它实际上表达了从业务到数据的过程。3理解OLTP数据OLTP数据是数据仓库数据库的物质基础，只有对它的内容及其构成足