数据仓库设计方法论

《数据仓库设计方法论》由会员分享，可在线阅读，更多相关《数据仓库设计方法论（15页珍藏版）》请在金锄头文库上搜索。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15、dventureWorksDW 数据仓库时并没有这样做，反而在“DimProductSubcategory”表和“DimProduct”表及“DimGeograph”表和“DimGeograph”表之间设计成满足一定范式要求的结构，下面将解释其原因。标准的关系数据表不能满足数据的分析能力，所以对表进行非标准化处理以形成数据仓库中特有的星形架构方式，但这样一来，如果所有的分析维度都作为事实表的一个直接维度，数据的冗余是相当大的，比如将“DimProductSubcategory”表合并到“DimProduct”表中，的确能形成一个关于产品所有属性的维度，但要在一张表中表达产品类别属性和产品的属性

16、，需要的存储空间是相当大的。由此可以看出，在星形架构的基础上扩展出雪花形架构，实质上是在分析查询的性能和数据仓库的存储容量 2 方面进行权衡的结果。表 3-3 具体比较了 2 种类型的架构差异。只有明确了这些差异，才能在设计数据仓库时选择最合适的架构方式。表 3-3 雪花形与星形层次结构的差异星 形 雪 花 形行数 多 少可读性 容易 难表格数量 少 多搜索维的时间 快 慢4星座模式一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模式（galaxy schema ）。在 AdventureWorksDW 数据仓库中有多个事实，为了便于显示，取最重要的 2 个事实表“FactInternetSales”和“FactResellerSales” 作为星座模式的例子。由于对网络销售和批发商销售的分析有很多观察视角都是相同的，因而这 2 个事实表共享的维度表较多，