商业智能

数据仓库是商业智能分析和决策支持应用的最基本环境。正如软件开发中的系统分析和系统设计在整个开发周期中占举足轻重的地位一样，数据仓库的分析与设计在开发相关项目中同样也是十分重要的。

业务数据库和数据仓库由于两者功能的不同，设计方法必然会有很大的差异。但尽管如此，它们都是在DBMS中管理的，运用类比思维，设计数据仓库的时候，也可以从比较成熟的数据库设计方法论中找寻灵感。

实际上，在SQL Server 2005安装的两个示例数据库中，AdventureWorks就是属于操作型的数据库；而AdventureWorksDW则是分析型数据库，也就是数据仓库，其主要数据都源于AdventureWorks。微软在给出这个设计得十分精巧的数据仓库时，并没有说明此数据仓库是如何得来的，因此下面在研究数据仓库设计方法的时候，就主要以从AdventureWorks数据库到AdventureWorksDW数据仓库的过程为例来解析设计数据仓库过程中的复杂理论。

3.2.1 数据库设计与数据仓库设计

1．业务数据和分析数据使用方式的不同

普通数据库直接用于业务处理，因而需要严格约束表与表之间的关系，使数据在完整性等方面得到有效的保证。在设计这一类型的数据库的时，一般是先通过实体关系模型确定数据库中需要存储数据的表，再通过数据规范化方法（如第1、2、3范式等）改变这些表的结构，确定表的主外键，并以主外键为依据，在表之间建立起一对一或一对多的关系。图3-6即为AdventureWorks业务数据库中购买订单、买入商品运输方法和商品提供商等数据表之间的关系。从图中可以看出，对于购买订单报头这个表（PurchaseOrderHeader）而言，与供货商（Vendor）表、购买订单详情表（PurchaseOrderDetail）及运输方法表（ShipMethod）之间的关系是根据实际业务操作中应该有的关系来确定的，这样的数据库系统结构设计用于业务操作的信息化是很合适的。

图3-6 业务数据库中的表间关系示例

通过3.1节对事务处理和分析处理的比较可以得知，商务分析需要的数据库与业务数据库有很多地方不同，用于OLAP的数据应该是多维的。图3-7即为从购买地区、购买时间和产品名称等3个视角来分析购买订单时需要的一种数据立方。数据立方又称多维数据集，是使用分析数据的典型方式。

图3-7 3个视角分析购买订单时需要的数据立方

2．理解仓库中的立方体

在第2章，我们从整体上掌握了商业智能的整个应用过程，相信在此过程中已经有了对数据立方的感性认识。为了理解数据仓库设计的方法，下面从使用的角度理解数据立方。

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

数据立方中多个维度的值是商务需求中需要观察的目标，这个目标的值一般叫度量值。度量值来源于构成商务观察目标的事实表中。例如在图3-7的立方体中，事实表中有全部产品的销售度量，那么，可以用立方体上的某一个点度量某产品在某一时间和某一城市的销售情况。

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

图3-8 不同视角的数据立方分析

认识事物一般是从此事物在实践中的应用开始的。以上对业务数据和分析数据使用方式的区别及对数据立方的具体使用方法的解析是认识数据仓库的基础。正是由于其作用的不同，所以设计时数据库和数据仓库的目标也不同。

3．数据仓库的设计目标

根据前面对2种数据处理方式的对比，可以得到设计数据库和数据仓库的目标之间的差异，其结果如图3-9所示。

图3-9 数据仓库和数据库目标的差异

现在的问题是这种多维分析的需求既然不能用业务数据库的方式满足，那又应该怎样解决。

实际上，为了在商务分析时能以多个视角对某个业务事实进行操作，构建分析用的数据仓库时引入了维度概念来表示分析视角，事实概念来表示分析对象，事实的量度来表示对象的分析结果。而这些概念在数据分析阶段（本书的第5章将要论述）会得到直接使用或进行一定的改动。因此，这些对象在数据仓库中的设计如何，将直接影响后续的分析工作，而它们之间的关系则构成了整个数据仓库的架构。

3.2.2 数据仓库的架构方式及其比较

传统的关系数据库一般采用二维数表的形式来表示数据，一个维是行，另一个维是列，行和列的交叉处就是数据元素。关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。

数据仓库是多维数据库，它扩展了关系数据库模型，以星形架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但不管是哪一

种架构，维度表、事实表和事实表中的量度都是必不可少的组成要素。下面解析由这些要素构成的数据仓库的架构方式。

1．星形架构

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

图3-10 星形架构示意图

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

在AdventureWorksDW数据仓库中，若以网络销售数据为事实表，把与网络销售相关的多个商业角度（如产品、时间、顾客、销售区域和促销手段等）作为维度来衡量销售状况，则这些表在数据仓库中的构成如图3-11所示，可见这几个表在数据仓库中是以星形模型来架构的。

星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中关系模式的基本区别。

使用星形模式主要有两方面的原因：提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中，所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高，同时由于维表一般都很小，甚至可以放在高速缓存中，与事实表进行连接时其速度较快，便于用户理解；对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。

图3-11 AdventureWorksDW数据仓库中部分表构成的星形架构

2．雪花形架构

雪花模型是对星形模型的扩展，每一个维度都可以向外连接多个详细类别表。在这种模式中，维度表除了具有星形模型中维度表的功能外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的，如图3-12所示。

雪花模型对星形模型的维度表进一步标准化，对星形模型中的维度表进行了规范化处理。雪花模型的维度表中存储了正规化的数据，这种结构通过把多个较小的标准化表（而不是星形模型中的大的非标准化表）联合在一起来改善查询性能。由于采取了标准化及维的低粒度，雪花模型提高了数据仓库应用的灵活性。

这些连接需要花费相当多的时间。一般来说，一个雪花形图表要比一个星形图表效率低。

在AdventureWorksDW数据仓库中，以图3-11的架构图为基础，可以扩展出雪花模型的架构，“DimProduct”表有一个详细类别表“DimProductSubcategory”，而“DimCustomer”表也有一个表示客户地区的表“DimGeograph”表作为其详细类别表，将它们加入数据仓库后，整个数据仓库就是雪花形架构，如图3-13所示。

图3-12 雪花模型架构示意图

图3-13 AdventureWorksDW数据仓库中部分表构成的雪花形架构

3．星形与雪花形架构的比较

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

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

和数据仓库的存储容量2方面进行权衡的结果。表3-3具体比较了2种类型的架构差异。只有明确了这些差异，才能在设计数据仓库时选择最合适的架构方式。 表3-3 雪花形与星形层次结构的差异 行数 可读性 表格数量 搜索维的时间 星 形 多 容易 少 快 雪 花 形 少 难 多 慢 4．星座模式 一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模式（galaxy schema）。 在AdventureWorksDW数据仓库中有多个事实，为了便于显示，取最重要的2个事实表“FactInternetSales”和“FactResellerSales”作为星座模式的例子。由于对网络销售和批发商销售的分析有很多观察视角都是相同的，因而这2个事实表共享的维度表较多，比如促销手段、时间和产品等。在数据库关系图中把它们的关系表现出来后，如图3-14所示。 图3-14 数据仓库的事实星座模式示例 5．数据集市 数据集市是在构建数据仓库的时候经常用到的一个词汇。如果说数据仓库是企业范围的，收集的是关于整个组织的主题，如顾客、商品、销售、资产和人员等方面的信息，那么数据集市则是包含企业范围数据的一个子集，例如只包含销售主题的信息，这样数据集市只对特定的用户是有用的，其范围限于选定的主题。 数据集市面向企业中的某个部门（或某个主题）是从数据仓库中划分出来的，这种划分可以是逻辑上的，也可以是物理上的。例如在AdventureWorksDW数据仓库中就是逻辑上划分的数据集市。

数据仓库中存放了企业的整体信息，而数据集市只存放了某个主题需要的信息，其目的是减少数据处理量，使信息的利用更加快捷和灵活。

数据仓库由于是企业范围的，能对多个相关的主题建模，所以在设计其数据构成时一般采用星系模式，AdventureWorksDW数据仓库就是这种情况。而数据集市是部门级的，具有选定的主题，可以采用星形或雪花模式。

图3-15是数据仓库、数据集市和数据立方之间的关系，通过此图可以更好地理解这3个概念。

图3-15 数据仓库、数据集市和数据立方之间的关系

3.2.3 宏观上的数据仓库设计

广义的数据仓库包括2部分，一是数据仓库数据库，用于存储数据仓库的数据；二是数据分析部分，用于对数据仓库数据库中的数据进行分析。广义的数据仓库设计应该包括数据仓库数据库的设计和数据仓库的应用设计2个方面，而数据仓

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

图3-16 宏观上数据仓库的开发阶段

这一个过程将软件工程思想应用在数据仓库的设计中，主要用在大型的数据仓库工程项目中，包含了构建完整应用的全过程，因此在本章不具体讨论此过程的使用细节，本书第10章“基于SSAS的商务智能分析”将会对这个过程中的有些重要步骤进行详细讲解。

3.2.4 微观上的数据仓库设计

微观上的数据仓库设计实际上指的是数据仓库数据库的设计，亦即宏观上设计仓库设计的第1个部分。在这个层面上主要任务是进行数据建模，确定数据仓库中数据的内容及其构成关系。

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

数据仓库的设计就是在概念模型、逻辑模型和物理模型的依次转换过程中实现的。作为数据仓库的灵魂——元数据模型则自始至终伴随着数据仓库的开发、实施与使用。数据粒度和聚合模型也在数据仓库的创建中发挥着指导的作用，指导着数据仓库的具体实现。图3-17表达了微观数据仓库设计中各种概念之间的关系。

图3-17 微观数据仓库设计中各种概念之间的关系

图3-18 数据仓库数据库设计的步骤

在图3-17的关系图中，元数据是在对企业商业智能需求分析和概念模型设计阶段就应该设计好并且一直贯穿于数据仓库应用全程的重要部分，而数据粒度和聚合的设计则是在逻辑模型的设计过程中完成的，物理模型则需要做一些存储优化方面的工作。具体而言，这3级数据模型设计的每1个阶段都有相应的详细设计步骤，图3-18即是对这些步骤的一个总结。

3.2.5 2种创建数据仓库的模式

创建数据仓库的方式，根据其出现的先后顺序，主要分为2种模式：自顶向下（Top-down），自底向上（Bottom-Up）。

1．自顶向下

这种模式首先把OLTP数据通过ETL汇集到数据仓库中，然后再把数据通过复制的方式推进各个数据集市中，其优点在于：

l 数据来源固定，可以确保数据的完整性。

l 数据格式与单位一致，可以确保跨越不同数据集市进行分析的正确性。 l 数据集市可以保证有共享的字段。因为都是从数据仓库中分离出来的。

2．自底向上

这种模式首先将OLTP数据通过ETL汇集到数据集市中，然后通过复制的方式提升到数据仓库中，其优点在于：

l 由于首先构建数据集市的工作相对简单，所以容易成功 l 这种模式也是实现快速数据传送的原型。

3.2.6 技术上需要关注的重点步骤

本章的主要任务就是完成数据仓库数据库的设计，在图3-18所给出的步骤是数据仓库设计的完整结构，在实践这一步骤的设计工作中，有5个重点步骤需要特别关注，它们是业务数据理解和需求分析、分析主题和元数据、事实及其量度和粒度、维度模式确定和数据仓库的物理存储方式。

这5个步骤贯穿了从分析到物理实现的全过程，而且一般的设计过程都是照此进行的，因此可以把它看做是设计数据仓库数据库的实践版本。这5个步骤及其与3级模型的关系可以用图3-19来表示。

图3-19 5步骤及其与3级模型的关系

从下面一节开始将分别阐述这5大步实现由业务事实到数据仓库的全过程。

3.3 理解历史数据和分析需求

历史数据也就是业务数据库，它是数据仓库的数据来源，是构建数据仓库的“物质基础”。需

求在每一个工程项目中都很重要，它是数据仓库的价值体现。因此理解历史数据和分析需求是5步中的第1步。下面先从理解“用户驱动＋数据驱动”的设计理念开始。

3.3.1 “数据驱动＋用户驱动”的设计理念

数据驱动是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库。 用户驱动也叫需求驱动，是根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。

数据仓库的用户一般是企业管理者，分析需求和业务需求有很大差异，因此不能把数据库设计阶段的用户需求直接用在数据仓库设计中。在设计仓库数据库之初把用户的分析需求纳入考虑范围是十分有必要的。同时，数据仓库的构建必需基于业务数据库，业务数据源的结构也是不得不考虑的问题。因此在设计数据仓库的时候，应该坚持用户驱动与数据驱动相结合的设计理念。图3-20所示的是这两种方法结合获取数据仓库设计真正需求的过程。

图3-20 用户驱动与数据驱动相结合来获取数据仓库设计真正需求

3.3.2 理解业务数据

由图3-20可知，通过对业务数据的分析，可以清楚的知道原有的数据库系统中已经有什么，对当前系统设计有什么影响等，也可以为利用已有的数据和代码提供方便。这样，在把业务数据转化为分析数据时，便于按照分析领域对数据（即数据之间的联系）重新考察，组织数据仓库的主题。

1．理解业务

需求是项目的动力，使用则是项目的根本。构建数据仓库归根到底是应用于企业数据分析，

辅助管理决策，这是设计人员应该在数据仓库的整个生命周期都牢记于心的。

理解业务数据的首要一步就是理解业务，也就是要熟悉企业生产经营流程，同时初步获取在这些流程中的分析需求，为最终确定用户需求做好意识上的准备。

例如在Adventure Works Cycles这个经营自行车及其相关配套产品的公司内部，原材料采购、生产和销售及相关的财务和管理等有既定的流程。下面以原材料采购和产品的销售两个业务领域为例进行分析。

1）原材料采购

在公司内部有采购部负责原材料采购，采购部门下设一个经理和多个采购员。一种原材料有多个供应商，一个供应商可以提供多种原材料。原材料和供应商之间是多对多的关系。每个采购员负责多种原材料的采购，一种原材料只能由一个采购员来采购。采购员和商品之间是一对多的关系。采购员只需了解原材料和供应商的联系，而采购部门经理需要管理员工，并且还需要了解原材料的仓储情况，以确定需要采购的商品并将任务分配给每个采购人员。 另外，公司为了防止产品过分依赖于原材料价格，还需要对原材料进行批量存储，因此设立仓库管理部门，专门负责原材料的存储管理，仓库管理部门管理多个仓库，下设一个经理和多个仓库管理员，每个仓库中拥有多个仓库管理员，每个管理员只能在一个仓库中进行工作。 仓库管理员需要知道他所管理的仓库中存储的原材料的种类、数量、存储的时间、原材料的保值期及原材料进入仓库和离开仓库的时间等信息。一种原材料可以保存在多个仓库中，一个仓库可以保存多种原材料。

仓库管理部门经理不但需要处理仓库管理员需要的数据，而且需要知道仓库管理员的基本信息（比如仓库管理员的家庭住址和电话等）。

2）产品销售

Adventure Works Cycles的自行车及其相关产品远销北美、欧洲和亚洲市场。公司有网络销售和通过批发商销售两种销售渠道，因此，对于客户也分为两类，其一是个人，即从在线商店购买产品的消费者，其二是商店，即从Adventure Works Cycles销售代表处购买产品后进行转售的零售店或批发店。

对于销售部门，销售员关心的是商品的信息，每种商品的价格、质量、颜色和规格等，以便向顾客推销相关的产品。因此，销售员最需要的数据就是商品的信息。销售部门经理不但需要了解商品的销售情况，以便在某种商品缺货的时候通知仓库存储部门运送存储的商品，或者通知采购部门采购相应的原材料。销售部门经理还需要了解每个销售员的工作业绩，对每个销售员进行考核。因此销售部门经理需要了解商品、顾客和部门员工的情况。

从上面的分析可以看出，商务数据确实是多维的。不同部门对数据的需求不同，同一部门人员对数据需求也存在差异。如果考虑数据需求的层次问题，管理人员和不同的业务人员对数据要求的程度也各不相同。管理人员可能需要综合度较高和较为整体的数据，而业务人员需要细节数据。

在前面分析仓库中的立方体的时候，曾经讲到过要对数据立方进行不同视角的分析（图3-8），在这里可以看到，这种分析是符合业务操作的实际情况的。

同时，可以用业务构成图来表达业务理解的分析成果。对于上述的分析，可以用图3-21来表达。需要注意的是，这只是对Adventure Works Cycles公司业务分析的一个简单示例，在实际项目中情况要复杂得多，为了获取这个业务构成图，可能需要借鉴企业信息化中的其他阶段的成果，如可以把ERP构建构成的业务流程重组成果用在这里。

有了这样一个清晰表达业务结构的图，就为后面建立分析主题打下了很好的基础。

图3-21 业务构成图

2．理解业务到数据的转化

实际上，对业务的理解是信息系统建设过程都需要的，只不过在设计数据仓库的时候理解业务需要着重从业务蕴含的数据的多维性方面来分析。而业务到数据的转化这一步则主要是在构建OLTP系统时使用的。数据仓库都是以历史数据为基础的，这一步本质上是理解这些历史数据的来历。

在构建OLTP系统的过程中，一般先把业务转化为E-R图，也称为OLTP的逻辑模型图，这在许多数据库系统设计的书籍里都有详细说明，这里就不再描述。图3-22是把企业业务模型和通过E-R图这种工具转化成数据后的数据表对应起来的一种关系图。它实际上表达了从业务到数据的过程。

3．理解OLTP数据

OLTP数据是数据仓库数据库的物质基础，只有对它的内容及其构成足够熟悉，在设计数据仓库和以后对数据进行ETL过程的时候才有可能得心应手。

首先是要明确数据的结构。比如AdventureWorks数据库为了能处理Adventure Works Cycles公司的业务数据，把这些数据分成了5个架构，分别是表示人力资源的“HumanResources”，表示人员信息的“Person”，表示产品信息的“Production”，表示采购信息的“Purchasing”和表示销售信息的“Sales”，从前面的分析可知，这些架构囊括了此公司的大部分业务。

图3-22 企业业务及其对应的数据表的关系 其次是要明确数据的内容。 数据内容包括某个业务领域的数据表构成及其主外键关系，还包括各个数据表的具体字段构成情况。下面理解AdventureWorks业务数据库中的数据内容，限于篇幅的影响，这里只对一部分在分析和数据挖掘过程中十分重要的数据内容进行分析。 l 个人客户相关的数据 个人客户是公司客户类型的一大类，即从Adventure Works Cycles在线商店购买产品的消费者。若“Sales.Customer”表的“CustomerType”列值为‘I’则表示客户类型为个人，若为‘S’则为批发商。与个人客户相关的表有5个分别是“Person.Contact”表示客户的联系方式、“Sales.Customer”表示客户的类型和“Sales.Individual”表示个人客户的具体信息，其中“Demographics”列还以XML格式对收客户的收入、爱好和车辆数目等进行了统计，而对于客户的订单信息则放在“Sales.SalesOrderHeader”和“Sales.SalesOrderDetail”两个表中。 l 产品相关的数据 Adventure Works Cycles公司提供4类产品。一是公司自己生产的自行车。一是自行车组件（替换零件），例如，车轮、踏板或刹车部件。还有就是从供应商购买来转售给客户的自行车装饰和自行车附件。 和产品相关的表比较多，结构也较为复杂，下面以表格的形式分析这方面的数据内容。 表3-4 产品相关的表及其数据理解 数 据 表 Production.BillOfMaterials Production.Culture Production.Location 数据表内容的理解 用于制造自行车和自行车子部件的所有组件的列表。ProductAssemblyID 列表示父级产品（即主产品），ComponentID 表示用来组成父级部件的子级零件（即独立零件） 列出使用了哪些语言来本地化产品说明 列出产品和零件的库存位置 （续表） 数 据 表 Production.Product Production.ProductCategory Production.ProductCostHistory Production.ProductDescription Production.ProductInventory 数据表内容的理解 由公司销售或用来制造自行车和自行车组件的各种产品的信息 产品最常规的分类。例如，自行车或附件 列出不同时间点的产品成本 列出各种语言的详细产品说明 按地点统计的产品库存量 Production.ProductListPriceHistory Production.ProductModel Production.ProductPhoto Production.ProductReview Production.ProductSubcategory 列出不同时间点的产品价格 与产品关联的产品型号 列出所售产品的图像 给出客户对产品的评价 产品类别的子类别 产品说明及其本地化后的语言之间的交叉引用 ProductModelProductDescriptionCulture 给出产品型号、l 原材料采购相关数据 此公司通过采购部门购买自行车生产中使用的原材料和零件，同时也购买一些产品以进行转售，例如，自行车装饰件和自行车附件，像水瓶和打气筒。和原材料采购相关的表也比较多，同样以表格的形式列出其数据内容如表3-5所示。 表3-5 原材料采购相关的表及其数据理解 数 据 表 Person.Address Person.Contact Production.ProductVendor 数据表内容的理解 所有客户的通信地址信息 供应商雇员的姓名，与“VendorContact”表相关联，将联系人映射到供应商。XML数据类型的列“AdditionalContactInfo”包含了联系人的其他联系方式（手机和传真等） 将供应商映射到其提供的产品 Purchasing.PurchaseOrderDetail 采购订单的详细信息，例如，订购的产品、数量和单价 采购订单的摘要信息，例如，应付款总计、订购日期和订单状态。Purchasing.PurchaseOrderHeader “PurchaseOrderHeader”表与“PurchaseOrderDetail”表共同构成主-从关系 Purchasing.ShipMethod Purchasing.Vendor Purchasing.VendorAddress Purchasing.VendorContact 用于维护产品标准发货方法的查找表。“ShipMethodID”列包含在 “Purchase OrderHeader”表中 供应商的详细信息，例如，供应商的名称和账号 将客户链接到“Address”表中的地址信息。按类型对地址进行分类，例如，开票地址、家庭住址和发货地址等。“AddressTypeID” 列映射到“AddressType”表中 这是一个关联表。连接“Contact”和“Vendor”两个表 以上只是对商务分析时特别重要的业务数据进行了分析，目的是提供一个可供项目参考的示例，若要完全理解业务数据，还要对数据库中的表及其关系进行更加深入的理解。 这里以原材料采购数据中的表“Purchasing.PurchaseOrderHeader”为例子分析表的具体构成。如表3-6所示。 在后面的ETL过程及商务分析和商务规则的挖掘等操作中会发现，这些分析是有相当大的好处的。因此在实际项目中，应该对每一个业务数据表进行类似的分析。 表3-6 Purchasing.PurchaseOrderHeader表的具体分析 列 PurchaseOrderID RevisionNumber Status EmployeeID VendorID ShipMethodID OrderDate ShipDate SubTotal TaxAmt Freight TotalDue ModifiedDate 数 据 类 型 int tinyint tinyint int int int datetime datetime money money money money datetime 说 明 主键 用于跟踪一段时间内采购订单变化的递增编号 订单的当前状态。1 = 等待批准，2 = 已批准，3 = 已拒绝，4 = 完成 创建采购订单的雇员。指向“Employee.EmployeeID”的外键。 采购订单所采购的产品的供应商。指向“Vendor.VendorID”的外键 发货方法。指向“ShipMethod.ShipMethodID”的外键 采购订单的创建日期 预计供应商的发货日期 采购订单小计 税额 运费 付给供应商的应付款总计。计算方式为 SubTotal + TaxAmt + Freight 行的上次更新日期和时间 3.3.3 确定用户对分析型数据的需求 在业务数据理解的任务中，明确了企业的具体业务映射到数据库系统的细节，数据仓库的设计者对现有数据库系统完成了企业数据需求中的哪些部分，还缺少哪些部分已经心中有数。这一节的任务是从企业的各个视点对企业数据分析需求加以挖掘，发现企业需要的（或可以构造的）主题，为需求到数据仓库的映射打下基础。 1．对用户需求分类 分类是认识事物的一种好方法。要真正清楚地理解用户的需求，根据一定的标准对需求划分类别是很有必要的。 实际上企业每个部门都有对企业业务观察的不同视角，这是需求多样性的一个方面。例如对于类似Adventure Works Cycles的一个商务企业来说销售部门、采购部门和仓库管理部门等都有相应的视角，尽管这些业务是相关的，而且是作为一个整体形成企业业务流程的。因此，对数据的需求，特别是对分析数据的需求必然有所不同，图3-23是对这种现象的示意。

图3-23 对企业流程中的不同视角

创建企业级数据仓库是一个应全面考虑的工程，但它的需求是相当模糊的，对需求按照其业务视角进行分类以后，可以对用户报表的需求、历史数据的保留、要包括的数据本质、要排除的数据本质、获取数据的地方、数据的迁移和数据的复制等方面的需求进行明确。 为完成分类的任务，一般在分类前要问2个问题： l 在公司中，用户所在部门承担的任务是什么？ l 用户在部门中承担的任务是什么？

在具体分类时，由于涉及到部门信息的使用方式，需要回答3个问题： l 为完成该任务，将使用什么样的报表？ l 目前从何处获取这些信息？ l 得到信息后，如何处理它？

分类结束后，为了能为下一步的工作做准备，需要关注3个问题： l 这些信息通常是应用户的需要产生的，还是在某些定期报表中找到的？ l 用户曾把这些信息输入工作表中，以便进一步分析吗？ l 怎样处理这些信息才算及时？

2．准备需求采集

数据仓库主要由用户操作，用户就是顾客。用户的需求不能想当然，所以为了确保操作成功，要保证与用户的充分交流，而作为正式交流，准备工作是很重要的。 其一是人员准备。

技术方面，一般来讲仓库设计组的主要成员都应该参加，还可以包括一个在决策支持或数据

仓库领域有专长的顾问。顾问应为设计组提供有价值的意见，从而帮助设计组更快地收集到设计要求。

用户方面，从组织机构的上层开始交流是非常有益的。上层行政官员可以提供许多令人惊奇的有关业务操作及其希望从该组织得到的内容。除此之外，还应该包括负责数据仓库项目或有关的商业领域的行政人员、来自相关商业领域的负责向高级行政官员汇报的主管经理和为高级行政人员和主管经理准备报告的业务分析员。 其二是内容准备。

对于参与收集需求的技术人员，需要给他们足够且有用的提示和建议，以确保每个人都能积极参与。在提示他们时，要强调他们参与的重要性，以及与用户会谈的目的。会谈的目的有：希望从用户得到的内容和希望用户带来的所有材料，比如，用户发现的有价值的报告样本等。 制定与所有参与需求分析的用户的日程也应该是需要准备的一项重要内容。

3．确定需求提问

根据不同的交谈对象，所提问题也应不同。很明显，针对高级行政人员和底层的雇员应该有不同的问题。但是这里面包含一些具有共性的问题域，比如： l 交谈对象在公司中的地位是什么？

l 他们的工作成绩是怎样得来的，即什么因素决定工作的成功与失败？ l 什么信息对完成指标有影响，什么信息数据对会谈者理解关键指标有帮助？

l 得到信息后，下一步利用这些信息干什么？怎样处理这些信息？这些信息是最终的，还是需要进一步输入和处理？这些信息是否与其他报告或其他信息进行了融合？ l 从这些数据衍生的信息或分析结果将提供给谁？

l 怎样分析过程需耗费多长时间？从这些分析中可做出什么决策？ l 信息分发的方式是什么？报告、论文或电子邮件？ l 怎样弥补信息的空缺？

l 分析这些数据需要哪一级的详细程度？

l 信息报表的来源是什么？谁对报告的制定、维护和分发负责？

l 如果他们在一个标准上可以得到多个商务问题的答案，他们将怎样优先处理这些信息？ 如果觉得这些问题还不够深入，对于需求分析的问题，可以按照商务目标、当前信息源、涉及的主题范围、关键性能指标和信息频率等5个方面进一步细化需求提问。

1）商务目标

l 企业部门的目标是什么？怎样将这些目标融进整个公司的目标之中？要达到这些目标有哪些需要？成功的关键因素是什么？集团公司实现这些目标的障碍有哪些？

l 商业策略是什么？商务活动的领域有哪些？这些领域是怎样联系在一起从而达到商务活动目的的

l 购买外部数据吗？从哪里购买？还有谁有公司没有购买的数据？数据提供商是怎样发布信息的？

l 所有的用户都需要相同的信息吗？特殊情况是什么？明确定义用户的类别。

2）当前信息源

l 在现有报表过程中，当前传递了哪些信息？

l 这些信息的详细程度怎样？是太详细了，还是太粗略了？ l 哪些操作地区产生了关于重要主题领域的数据和信息？ l 提供数据和信息的地区有计算机系统支持吗？

l 这些计算机系统中数据的质量、可靠性、一致性和完整性等商务评价指标指的是什么？

3）主题领域

有关这方面的问题可以帮助确定对商务活动来说什么主题是很重要的。随着用户地位的不同，在他们的数据领域中，各种不同的领域或维度被明确地提出，这就使得对信息打包变得容易多了。这些问题集中在数据仓库中的数据应怎样检索及用户怎样分析和筛选这些数据等，这些都是商务活动中重要的指标。

l 哪些维度或领域对数据的分析是非常有价值的？这些维度有固有的准备层次吗？ l 是否有用于制订决策的自然商务分区？ l 做出商务决策仅仅需要当地的有关信息吗？ l 某些产品是否仅仅在某一地区销售？

4）关键性能指标

关键性能指标同商务活动涉及的领域一样，不同的用户有不同的看法。通过解决这方面的问题，可以明确会谈者衡量商务活动的指标。这些招标对涉及的主题领域或绍度进行了参数化，从而完成用户提出的信息需求：

l 商业环境中机构的表现是怎样监控的？ l 要监控机构内部哪些关键的指标？

l 指标形成过程中，当它们被平均时，指标是否被分解？ l 所有的市场被平等地衡量吗？

5）信息频率

可以从用户处明确信息包的时间灵敏度，即获得信息频率。所有的信息包将以时间为基准，所以，每个用户都应该提供每个信息包频率要求的有价值的看法。 l 用户需要多长时间对数据更新一次？适当的时间结构是什么？ l 在数据仓库中，信息的实时性需求是什么， l 对数据进行分析时，如何进行比较？

在第10章以数据仓库为基础进行商务分析的时候将会看到，这些问题的答案在构建OLAP分析的时候将会直接得到使用。

4．交流需求分析结果

在与用户交流阶段，应该确定数据仓库需要访问的有关信息。用户应该清晰地确定所需的信息。例如，数据仓库的用户需要得到有关产品收入的详细统计信息，包括过去5年中的年龄、组别、性别、位置和经济状况等信息。那么根据用户的信息需求，可以抽取这些词语来表达信息包所要求的指标和维度，对于需要观察的产品收入，可以确定其指标和维度如下： l 指标：包括产品销售的实际收入、产品销售的预算收入及产品销售的估计收入。 l 维度：包括已经销售的产品的信息，如额度销售给顾客的地点（位置）。还有关于顾客的统计信息，如年龄组别、性别、位置和经济状况等。

总之，通过对历史数据和需求的分析，可以明确用户正在使用的数据现状、他们如何使用这些数据及将来他们利用这些数据干什么。充分的交流为数据仓库的总体设计打下了基础，下一步就可以确定数据仓库的主题和元数据了。

3.4 明确仓库的对象：主题和元数据

大多数商务数据都是多维的，所以采集和表示三维以上的数据不能完全借用业务数据库设计中的方法，必须有一种新的方法来表达多维数据。现阶段流行的有2种方法，一是面向对象方法，即把商务数据抽象为对象，再使用Rational Rose等对象建模工具来表达这些对象；另一种方法就是使用信息包图，这是一种简便且高效的方法，在项目中使用的普及率很高。

信息包图实际上是自上而下数据建模方法的一个很好的工具。自上而下的建模技术从用户的观点开始设计。用户的观点是通过与用户交流得到的，可以进一步明确用户的信息需求。自上而下的方法几乎考虑了所有的信息源，以及这些信息源影响商务活动的方式，它使得设计者可以围绕着一个通常的主题或商务领域进行信息包的开发。

下面就详述如何通过信息打包技术建立信息包图，从而确定数据仓库中的主题和元数据。

3.4.1 信息打包技术

1．信息打包技术的基本使用

信息打包法是一种自顶向下的设计方法，它从管理者的角度出发把焦点集中在企业的一个或几个主题上，着重分析主题所涉及数据的多维特性。此法具体分4个阶段：

（1）采用自顶向下的方法对商务数据的多维特性进行分析，用信息打包图表示维度和类别之间的传递和映射关系，建立概念模型。其中类别是按一定的标准对一个维度的分类划分，如产品可按颜色、质地、产地和销地等不同标准分类。 （2）对企业的大量的指标实体数据进行筛选，提取出可利用的中心指标。其中指标也称为关键性能指标和关键商务测量的值，是在维度空间衡量商务信息的一种方法。比如产品收入金额、原材料消耗、补充新雇员或设备运行时间等都可以叫做指标。

（3）在信息打包图的基础上构造星形图，对其中的详细类别实体进行分析，进一步扩展为雪花图，建立逻辑模型。

（4）在星形图和雪花图的基础上，根据所定义数据标准，通过对实体、键标、非键标、数据容量、更新频率和实体特征进行定义，完成物理数据模型的设计。 信息包图可以帮助用户完成以下工作：

l 定义某一商务中涉及的共同主题范围，例如：时间、顾客、地理位置和产品。 l 设计可以跟踪的、确定一个商务事件怎样被运行和完成的关键商务指标。 l 决定数据怎样被传递给数据仓库的用户。 l 确定用户怎样按层次聚合数据和移动数据。

l 决定在给定的用户分析或查询中实际包含了多少数据。

l 定义怎样访问数据，它的进入点是什么。用户想访问哪里，以及怎样引导进入信息包。 l 估计数据仓库大小。

l 确定一个数据仓库里数据的更新频率。 l 制定信息怎样被打包才能更好地提供给用户。

图3-24是一个空白的信息包图。注意信息包图上面的横线，这里要写上信息包的说明。可以有选择地填上概括说明和详细说明或者说明信息包图描述的是什么信息。而阴影部分就是代表在一定的维度和类别下的度量指标，这部分体现的就是数据分析的主要任务，在制作信息包图时需要和用户一起完成。

在以后对AdventureWorksDW数据仓库的分析中，主要是对Adventure Works Cycles公司的销售情况进行分析，根据前面对需求的分析，结合信息打包法的4个阶段，可以通过如下的方法建立信息包图。

图3-24 一个空白的信息包

（1）获取各个商务部门对商务数据的多维特性分析结果，确定影响销售的维度，这里可以提炼出日期、区域、产品、客户年龄和客户状况等5个维度。 （2）对每个维度进行分析，确定它与类别之间的传递和映射关系，如在AdventureWorks业务数据库中，日期有年、季度和月甚至更小的级别，而区域一般就分为国家、地区、城市和具体的商店。

（3）确定用户需要的指标体系，这里以销售情况作为事实依据确定相关的销售指标，如实际销售、计划销售、预测销售、计划偏差和预测偏差等。 有了以上的分析，就可以画出销售分析的信息包图，如图3-25所示，其他分析需求的信息包图可以用类似的方法表示。

图3-25 销售分析的信息包图

（4）这一步可以在信息打包图的基础上构造星形图，如图3-26所示。然后根据实际情况，把详细类别实体连接到星形图中就可以得到企业数据仓库的雪花模型。如在这里的AdventureWorks业务数据库中，已经通过表“ProductCategory”、“ProductSubcategory”和“Product”对产品进行了层次分类，把它们挂到图3-26的星形图中可以形成图3-27所示的雪花架构图。

图3-26 信息包图的基础上构造的星形图

图3-27 在星形图基础上构建的雪花架构图

注意，按照设计惯例，指标实体、维度实体和详细类别实体分别用矩形、菱形和六角形表示。

通过以上技术，实际上建立起了数据仓库的概念模型和逻辑模型。如图3-25所示的信息包图是在最终用户和技术人员共同完成的，通过它数据的构成便由客观

世界转换到了主观世界。而图3-26则属于逻辑模型，因为它在信息包图的基础上将信息转换成了关系模型。对比最终数据仓库的架构（在3.2.2节有叙述）可知，这时离构建完整的数据仓库数据库已经很近了。

2．信息动态打包

信息打包图中涉及的维度及其对应的类别是事先固定的。这种将维度和类别固定所带来的最直接的问题是，所设计的数据仓库不仅对一些特定的查询分析操作的适应能力差，而且当查询或分析的要求发生变化时根本无法适应。解决该问题的方法是允许维度和类别进行自由改变，这就是信息动态打包的方法。

信息动态打包包括2方面的内容：与该指标分析对应的维度的动态组合及与维度关联的类别的动态组合。参考南京大学李雪梅等人的《一种基于信息动态打包的数据仓库的设计方法》一文，可以得到信息动态打包方法的7步大法。 （1）采用自顶向下的方法，通过与企业的领导和管理人员交谈挖掘出尽可能多的主题，然后根据这些主题找出对应的指标实体，进一步对每个指标实体采用基本信息打包法分析出其中包含的最明显的维度实体。

图3-28和图3-29分别是对销售分析和顾客人口统计分析得到的两个星形图，其中前者包括时间、地区和产品3个维度实体，后者包括时间、地区和顾客3个维度实体。

（2）综合考虑所有的主题，采用指标实体矩阵对定义的信息包和维度实体进行统一和标准化处理。利用图3-30所示的统一实体矩阵来消除实体定义中的歧异和不一致，从而保证数据仓库中实体定义的一致性。矩阵中交叉点的‘X’表示相关。

（3）对于单个指标实体（信息包）找出所有的与该指标实体相关的但属于其他信息包的维度实体，再根据其与该信息包的相关程度进行排序，得到该指标实体的一个所有相关维度指标的一个有序集。需要特别指出的是，由于维度定义的相对性，当某些详细类别实体中的单个类别与指标实体的查询或分析密切相关时也可以将它作为单独的维度实体。如顾客细节实体中包括年龄组、性别、收入组、职业、教育和婚姻状况等，而其中年龄组、性别、收入组和职业与销售分析密切相关，故可以将它们分别作为销售的不同的维度实体。这样我们就可以得到与销

售分析相关的维度实体集Dim

销售

={时期,地区,产品,年龄组,性别,收入组,职业}。

这里我们定义前3者的相关度为1，其他维度实体的相关度为0.5。

（4）对于每个维度实体，进行类别划分，找出所有可行类别。然后对这些类别的划分条件根据其粒度从大到小进行排序，得到该维度实体的类别指标的一个有序集。

（5）创建指标实体的动态维。可以把维度实体分为2类，一类是指对该指标实体的分析必不可少的维度实体，称之为必需维；另一类则可以根据需要自由选择，称为可选维。如DIM销售集合中，时期、地区和产品是必需维，其余的则是可选维。

（6）创建与维度实体对应的动态类别实体。不同于维度实体，类别实体均设为可选的，类别实体可以根据具体情况自行确定。

（7）建立数据仓库中各个指标的概念模型（信息打包图）和逻辑模型（星形图或雪花图）。

信息动态打包的数据仓库设计方法采用了维度和类别动态重组技术，提供可以修改的数据存储方式，从而使所设计的数据仓库具有真正自适应的数据结构，较好地满足企业未来查询和分析的需要。

3.4.2 理解数据仓库中的主题

通过信息包图实际上确定了数据仓库的主题和大部分元数据。这一节先讲数据包图和主题的关系。

1．主题的概念

主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如在前面信息包图使用的例子中，“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。

所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。例如，一个生产企业的数据仓库所组织的主题可能有产品订货分析和货物发运分析等。而按应用来组织则可能为财务子系统、销售子系统、供应子系统、人力资源子系统和生产调度子系统。 主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供应是否及时，以及材料质量状况等。 数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、产品、订单和财务或是其他某项事务或活动。

2．主题域的获取

主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

比如，对于Adventure Works Cycle这种类型的公司管理层需要分析的主题一般包括供应商主题、商品主题、客户主题和仓库主题。其中商品主题的内容包括记录超市商品的采购情况、商品的销售情况和商品的存储情况；客户主题包括的内容可能有客户购买商品的情况；仓库主题包括仓库中商品的存储情况和仓库的管理情况等，如图3-31所示。

图3-31 根据业务情况确定的分析主题

确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。对于图3-31的4个主题及其在企业中的业务关系可以确定边界如图3-32所示。

图3-32 主题域的划分

3．确定主题的内容

主题虽然在信息包图中只占据标题的位置，但是却是信息打包方法中最重要的部分，当主题定义好之后，数据仓库中的逻辑模型也就基本成形了。此时，需要在主题的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据存储结构也需要在逻辑模型的设计阶段完成定义，需要向里面增加所需要的信息和能充分代表主题的属性组。以Adventure Works Cycle这类公司数据仓库为例，如表3-7所示可以分别在“商品”、“销售”和“客户”主题上增加能够进一步说明主题的属性组。 表3-7 主题的详细描述 主 题 名 公 共 码 键 属 性 组 商品固有信息：商品号，商品名，类型，颜色等 商品 商品号 商品采购信息：商品号，供应商号，供应价，供应日期，供应量等 商品库存信息：商品号，库房号，库存量，日期等 销售 销售单号 销售单固有信息：销售单号，销售地址等 销售信息：客户号，商品号，销售价，销售量、销售时间等 客户固有信息：客户号，客户名，性别，年龄，文化程度，住址，电话等 客户经济息：客户号，年收入，家庭总收入等 客户 客户号 4．主题的使用 由于数据仓库的设计是一个螺旋发展的过程，在刚开始，没有必要在数据仓库的数据库中体现所有的主题，选择最重要的主题作为数据仓库设计的试金石是很有必要的。因此使用主题首先是找到需要分析的主题域。 例如在AdventureWorksDW数据仓库的概念模型设计中，在对需求进行分析后，认识到“商品”主题既是一个销售型企业最基本的业务对象，又是进行决策分析的最主要领域，因而把“销售分析”主题域定义为要首先建立的主题。通过“商品”主题的建立，经营者就可以对整个企业的经营状况有较全面的了解。先实施“商品”主题可以尽快地满足企业管理人员建立数据仓库的最初要求，所以先选定“商品”主题进行实施。 通过将主题边界的划分应用到已经得到的关系模型上还能形成原始的概念模型。这一模型是把主题域的划分和事务处理数据库中的表结合起来的模型，例如在上面的例子中，商品主题可能涵盖的关系表有商品表、供应关系表、购买关系表和仓储关系表；仓库主题可能涵盖的关系表有仓库关系表、仓库表、仓库管理关系表和管理员表。把这些表的键和字段联系起来，就可以形成如图3-33所示的原始概念模型图。

图3-33 划分了主题域的原始概念模型

3.4.3 理解数据仓库中的元数据

信息包图同样也包含了数据仓库中的大部分元数据。元数据最普通的定义是“关于数据的数据”。正是有了元数据，才使得数据仓库的最终用户可以随心所欲地使用数据仓库，利用数据仓库进行各种管理决策模式的探讨。元数据是数据仓库的应用灵魂，可以说没有元数据就没有数据仓库。

1．元数据的类型

通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。

技术元数据是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库，它主要包含以下信息。

l 数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；

l 业务系统、数据仓库和数据集市的体系结构和模式；

l 汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚合、汇总和预定义的查询与报告；

l 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全（用户授权和存取控制）。

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法及公式和报表的信息。

在信息打包过程中，需要用包图表示维度和类别还有它们之间的传递和映射关系，实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有层次关系是属于典型的技术型元数据，而业务系统中与之对应的术语则属于业务元数据。比如前面的例子中提炼出的日期、区域、产品、客户年龄和客户状况等维度，实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在以后的分析中起到了极为重要的作用。下面将对这些作用进行归纳。

2．元数据的作用

从元数据的类型和作用来看，元数据实际上是要解决何人在何时、何地为了什么原因及怎样使用数据仓库的问题。再具体化一点，元数据在数据仓库管理员的眼中是数据仓库中的包含了所有内容和过程的完整知识库和文档，而在最终用户（即数据分析人员）眼中，元数据则是数据仓库的信息地图。

数据分析员为了能有效地使用数据仓库环境，往往需要元数据的帮助。尤其是在数据分析员进行信息分析处理时，他们首先需要去查看元数据。元数据还涉及到数据从操作型环境到数据仓库环境中的映射。当数据从操作型环境进入数据仓库环境时，数据要经历一系列重大的转变，包含了数据的转化、过滤、汇总和结构改变等过程。数据仓库的元数据要能够及时跟踪这些转变，当数据分析员需要就数据的变化从数据仓库环境追溯到操作型环境中时，就要利用元数据来追踪这种

转变。另外，由于数据仓库中的数据会存在很长一段时间，其间数据仓库往往可能会改变数据的结构。随着时间的流逝来跟踪数据结构的变化，是元数据另一个常见的使用功能。

元数据描述了数据的结构、内容、链和索引等项内容。在传统的数据库中，元数据是对数据库中各个对象的描述，数据库中的数据字典就是一种元数据。在关系数据库中，这种描述就是对数据库、表、列、观点和其他对象的定义；但在数据仓库中，元数据定义了数据仓库中的许多对象——表、列、查询、商业规则及数据仓库内部的数据转移。元数据是数据仓库的重要构件，是数据仓库的指示图。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程都有重要的作用，在图3-34中可以看到元数据在整个数据仓库开发和应用过程中的巨大影响。因此，设计一个描述能力强并且内容完善的元数据，对数据仓库进行有效地开发和管理具有决定性意义。

图3-34 元数据及其影响域

元数据拥有的巨大作用的发挥会在后面对数据仓库的分析中逐步体会到。这一节实际上通过信息打包技术建立起了数据仓库的概念模型，通过信息包图得到的星

形结构或雪花形结构实际上为数据仓库建立起了逻辑模型。可以说，通过对主题和元数据的分析，应该能够对从现实世界到主观世界的过程（即概念模型的构建）有深刻的认识，而对逻辑模型还需要从事实和维度的角度进一步研究。

3.5 确定分析内容的构成：事实及其粒度

事实表是数据库中最大的表，是星形模型结构的核心。事实表包含了基本商业事务的详细信息，是对商务活动进行客户关系、销售趋势和产品趋势等分析的素材。事实表的设计包括对事实的选择、量度的构造、粒度的设计和聚合的设计等。

3.5.1 事实、度量和事实表

事实是各个维度的交点，是对某个特定事件的度量。维度中的属性描述的是维本身的属性，比如客户的性别、年龄、姓名和地址，这些都是客户的固有属性。

度量是客户发生事件或动作的事实记录，比如客户打电话，可能选择的度量有通话时长、通话次数和通话费用等；客户购买商品，可能选择的度量有购买的次数、购买商品的金额和购买商品的数量等。度量变量的取值可以是离散的数值，也可以是连续的数值。比如，客户通话次数是离散的数值，而客户购买商品的金额是连续的数值。度量变量也可以在某个元素集合内取值。比如客户对公司服务质量的评定可以是很好（Excellent）、好（Good）、一般（Fair）和差（Poor）中的一个。

事实表则是位于星形架构或雪花形架构中间，用来记录商务事实和相应统计指标的表。同维表相比，事实表具有如下的特征。 l 记录数量很多。

l 事实表中除了度量变量外，其他字段都是同维表或者中间表（对于雪花形模型）的关键字。

l 如果事实相关的维度很多，则事实表的字段数也会比较多。

从事实表记录数多的特征中，我们可以得到事实表设计的一个感性认识，即事实表应当尽量减小一条记录的长度，只有这样才能避免事实表过大而难于管理。相对维表来说，事实表是“细长”的结构，如图3-35所示。

图3-35 事实表的特征

3.5.2 事实表的设计

由以上分析可知，事实表中一般要包含2部分：一是由主键和外键所组成的键部分，另一部分是用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。由于事实是一种度量，所以事实表中的这种指标往往需要具有数值化和可加性的特征。但是在事实表中，只有那些具有完全可加性的事实才能根据所有的维度进行累加而具有意义。而事实表有一些事实表示的是某种强度，这类事实就不具有完全加法性，而是一种半加法性。例如，账目余款反映的是某个时间点的数据，它可以按照地点和商品等大多数维度进行累加，但是对于时间维度则例外，将一年中每个月的账目余款进行累加是毫无意义的，而决策者则可能需要了解所有地区和所有商品账目余款的累加值。在事实表中还有一些事实是非加法性的，即这些事实具有对事实的描述特性，在这种情况下一般要将这些非加法性事实转移到维度表中。

以事实表中度量的可加性情况，可以把事实表及其包含的事实分为4种样式。

1．事务事实

事务事实以企业事件的单一情况为基础，因此通常只包含事实的次数这一种度量条件，应该尽可能以最低级别来表示。比如银行的ATM提款机的提款次数，使用某种服务的次数等。

2．快照事实

快照事实以企业在某一特定时间的特殊状态为基础。也就是只有在某一段时间内才出现的结果。它们也许没有包含所有维的条件，比如不是所有的产品每天都有销售量。

3．线性项目事实

这类事实通常用来储存关于企业经营项目的详细信息。包括表现与企业相关的个别线性项目的所有度量条件，比如销售数量、销售金额、成本和运费等数值数据，也就是关键性能指标。此类事实运用范围很广，比如采购、销售和库存等。

4．事件（状态事实）

这是类特殊的事实，通常只表示事件发生与否和一些非事实本身具备的细节。它所表现的是一个事件发生后的结果变化，并且没有度量数值表示。如哪些产品在促销期间内没有卖出，有还是没有，就是事件或状态事实所表现的结果。

在事实表模型的设计中还需要注意到派生事实。派生事实主要有2种，一种是可以用同一事实表中的其他事实计算得到，例如销售行为中的商品单价可以用商品的销售总金额和销售数量计算得到，对于这些派生事实一般不保留在事实表中；另一种是非加法性事实，例如各种商品的利润率等各种比率。

在事实表模型的设计中必须要考虑到事实表中的这些事实特性，通过多次反复来确定。首先，通过调查确定所有可能的基本事实和派生事实；然后，对所有的事实按照功能或某种方式进行排序，以删除重复的事实；接着，确认那些基于不同准则但是有相同性质的派生事实，例如公司门市销售总额与地区销售总额虽由于维度的不同而被定义为不同的事实，但实际计算方法是一样的；最后，再一次确定事实表模型，在确认中要检查所有的计算派生事实的基本事实是否已经包含在模型中，并且与用户取得—致。

在设计事实表时，一定要注意使事实表尽可能地小，因为过于庞大的事实表在表的处理、备份和恢复及用户的查询等方面需要较长的时间。在实际设计时，可以利用减少列的数量、降低每一列的大小和把历史数据归档到单独的事实表中等多种方法来降低事实表的大小。另外，在事实表中还要解决好数据的精度和粒度的问题，下面将阐释粒度的设计方法。

3.5.3 粒度的设计

在数据仓库中的数据分为4个级别：早期细节级、当前细节级、轻度综合级和高度综合级。如图3-36所示，源数据经过综合后，首先进入当前细节级，并根据具体需要进行进一步综合，从而进入轻度综合级乃至高度综合级，老化的数据将进入早期细节级。从中可以看出，数据仓库中存在着不同的综合级别，这就是 “粒度”的直观表现。

图3-36 数据仓库中的数据细节级别

粒度模型是数据仓库设计中需要解决的十分重要的问题之一。所谓粒度是指数据仓库中数据单元的详细程度和级别。数据越详细，粒度就越小，级别也就越低；数据综合度越高，粒度就越大，级别也就越高。

1．粒度对数据分析的影响

1）影响逻辑结构的设计

先举一个粒度设计的例子，Adventure Works Cycles公司的管理者想按照国家、区域、分区域和分区域内的销售员这样的层次关系来查看公司的销售情况，按照此需求可以得到如图3-37所示的设计结果。它是通过将地理层次国家、区域和分区域嵌入到销售员维度得到的。

图3-37 细化到销售员层次的设计结果

如果公司的决策者认为不需要了解具体到某个销售人员的情况，而只需要了解各个地理区域的销售情况，则没有必要把销售员维作为一个维度，把地域相关的表综合成为地理维度就可以了，设计结构如图3-38所示。

由以上实例可知，对事实粒度需求的不同，会直接导致数据仓库逻辑设计的差异。

图3-38 细化到分区域层次的设计结果

2）影响数据的存储

粒度对数据仓库最直接的影响就是存储容量。如图3-39所示的例子，按照每“月”统计的客户购买数据和按照每次消费记载的客户购买数据，两者的数据量相差极大。不妨假定每个字段为8个字节，每个客户一天有5次消费，则1个客户1个月的消费细节数据的数据量为8×6×30×5＝7200字节，而1个客户1个月的消费汇总数据的数据量为8×4＝32字节。

图3-39 不同粒度的储存容量示例

3）影响分析效果

不同的粒度设计对应不同的分析需求，若分析需求和粒度设计不匹配，则会直接影响分析效果。

因为数据的综合使得细节信息丢失，所以若分析需求的粒度小于设计的粒度，则需求不可能得到满足；反之，若分析需求的粒度大于设计的粒度，则查询会在更小的粒度上进行统计运算后才能回答，这将增加用户的等待时间。

例如在图3-40中，要回答“张某在2007年1月29号是否在北京买了一辆山地车”这样非常细致的问题，细节数据非常合适，而综合数据不可能回答。如果要回答“王某在2006年1月到2006年12月自行车配件的总消费是多少”这样综合程度较高的问题时，使用综合数据则可以迅速地回答这个问题。如图3-40综合数据和细节数据的用途和查询代价所示，很好地说明了这一点。

图3-40 综合数据和细节数据的用途和查询代价

由于数据仓库的主要作用是决策分析，因而大多数查询都基于一定程度的综合数据之上，而只有少数查询涉及到细节。因此在数据仓库中，设计多重粒度是必不可少的。下面具体讲解粒度的设计问题。

2．粒度的设计技巧

由以上的分析可知，数据仓库的性能和存储空间是一对矛盾。如果粒度设计得很小，则事实表将不得不记录所有的细节，储存数据所需要的空间将会急剧的膨胀；若设计的粒度很大，虽然由于事实表体积大而带来的诸多问题能够得到一定程度的缓解，但决策者不能观察细节数据。粒度的设计成了事实表设计中的重要一环。

1）设计步骤

（1）粗略估算

确定合适的粒度级的起点，可以粗略估算数据仓库中将来的数据行数和所需的直接存取存储空间，粗略估算可以按照以下步骤完成。

① 确定数据仓库中将要创建的所有表，然后估计每张表中行的大小（确切大小可能难以知道，估计一个下界和一个上界就可以了）。

② 估计一年内表中的最少行数和最多行数。这是设计者所要解决的最大问题。比方说一个顾客表，就应该估计在一定的商业环境和该公司的商业计划影响下的当前的顾客数；如果当前没有业务，就估计为总的市场业务量乘以市场份额；如果市场份额不可知的话，就用竞争对手的业务量来估计。总之，要从一方或多方收集顾客的合理估算信息开始。如果数据仓库是用来存放业务活动的话，就要估计顾客数量，以及估计每个时间单位内业务活动量。同样，可用相同的方法分析当前的业务量、竞争对手的业务量和经济学家的预测报告，等等。 一旦估计完一年内数据仓库中数据单位的数量（用上下限推测的方法），就用同样的方法对5年内的数据进行估计。粗略数据估计完后，就要计算一下索引数据所占的空间。对每张表（对表中的每个键码）确定键码的长度和原始表中每条数据是否存在键码。 ③ 将各表中行数可能的最大值和最小值分别乘以数据的最大长度和最小长度。另外，还要将索引项的数目与键码的长度的乘积累加到总的数据量中去。 （2）确定双重或单一的粒度 一旦估计完成后，下一步就要将数据仓库环境中总的行数和表3-8中所示的表格进行比较。根据数据仓库环境中将具有的总的行数的大小，设计和开发必须采取不同的方法。以1年期为例，如果总的行数小于10 000行，那么任何的设计和实现实际上都是可以的。如果1年期总行数是100 000行或更少，那么设计时就需小心谨慎。如果在头一年内总行数超过1 000 000行，那么就要请求采取双重粒度级。如果在数据仓库环境中总行数超过10 000 000行的话，必须强制采取双重粒度级，并且在设计和实现中应该小心谨慎。对于5年期数据，行的总数大致依据数量级改变，参见表3-8。 表3-8 存储空间与粒度设计层次的考虑 1年数据 数据量（行数） 10 000 000 1 000 000 100 000 10 000 粒度划分策略 双重粒度并仔细设计 双重粒度 仔细设计 不考虑 5年数据 数据量（行数） 20 000 000 10 000 000 1 000 000 100 000 粒度划分策略 双重粒度并仔细设计 双重粒度 仔细设计 不考虑 （3）确定粒度的级别 在数据仓库中确定粒度的级别时，需要考虑这样一些因素：要接受的分析类型、可接受的数据最低粒度和能存储的数据量。 计划在数据仓库中进行的分析类型将直接影响到数据仓库的粒度划分。将粒度的层次定义得越高，就越不能在该仓库中进行更细致的分析。例如，将粒度的层次定义为月份时，就不可能利用数据仓库进行按日汇总的信息分析。

数据仓库通常在同一模式中使用多重粒度。数据仓库中，可以有今年创建的数据粒度和以前创建的数据粒度。这是以数据仓库中所需的最低粒度级别为基础设置的。例如，可以用低粒度数据保存近期的财务数据和汇总数据，对时间较远的财务数据只保留粒度较大的汇总数据。这样既可以对财务近况进行细节分析，又可以利用汇总数据对财务趋势进行分析，这里的数据粒度划分策略就需要采用多重数据粒度。

定义数据仓库粒度的另外一个要素是数据仓库可以使用多种存储介质的空间量。如果存储资源有一定的限制，就只能采用较高粒度的数据粒度划分策略。这种粒度划分策略必须依据用户对数据需求的了解和信息占用数据仓库空间的大小来确定。

选择一个合适的粒度是数据仓库设计过程中所要解决的一个复杂的问题，因为粒度的确定实质上是业务决策分析、硬件、软件和数据仓库使用方法的一个折中。在确定数据仓库的粒度时，可以采用多种方法来达到既能满足用户决策分析的需要，又能减少数据仓库的数据量。如果主题分析的时间范围较小，可以保持较少时间的细节数据。例如，在分析销售趋势的主题中，分析人员只利用一年的数据进行比较，那么保存销售主题的数据只需要15个月的就足够解决问题了，不必保存大量的数据和时间过长的数据。

还有一种可以大幅降低数据仓库容量的方法．就是只采用概括数据。这样处理后，确实可以降低数据仓库的存储空间，但是有可能达不到用户管理决策分析中对数据粒度的要求。因此，数据粒度的划分策略一定要保证数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的—个准则。

2）设计实例

下面以类似Adventure Works Cycles公司的生产部门数据仓库设计为例，如图3-41所示。由于对不同的生产业务查询需求的差异，这里采用多重粒度来设计。左边是操作型数据，记录的是完成若干给定部件的生产线运转情况，每一天都会积累许多记录，是生产业务的详细数据，最近30天的活动数据都存储在操作型的联机环境中。

操作型数据的右边是轻度汇总级的数据，轻度汇总级包括两个表，一个汇总某一部件在3

个月中的生产情况，另一个汇总部件的组装情况，汇总周期为1年。真实档案级的数据包括每个生产活动的详细记录。

图3-41 生产环境的多重粒度

3）设计原则

粒度在数据仓库生命周期中是重要的考虑因素。它由业务问题所驱动，受技术的制约。如果粒度太大，就会丢失个别细节，就要花更多的处理时间来解开聚合；而若粒度太小，就会由于一叶障目而不见森林，许多宝贵的处理时间都浪费在建立聚合上。因此粒度设计主要是权衡粒度级别，对于业务量大，分析要求比较高的情况下，最佳解决办法则是采用多重粒度的形式。

而针对具体的某个事实的粒度而言，应当采用“最小粒度原则”，即将量度的粒度设置到最小。 假设目前的数据最小记录到秒，即数据库中记录了每秒的交易额。那么，如果可以确认，在

将来的分析需求中，时间只需要精确到天就可以的话，就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”；反过来，如果不能确认将来的分析需求在时间上是否需要精确到秒，那么，就需要遵循“最小粒度原则”，精确到“秒”以满足查询的可能需求。

3.5.4 聚合的设计

在事实表中存放的度量变量，根据其实际意义可分成可加性度量变量和非可加性度量变。可加性度量变量是指将变量相加后得到的结果仍然具有实际意义，可以把此结果计算后放在事实表中，以便在以后的查询中直接使用，这个相加的结果就是聚合。比如每个月的销售金额，通过将3个月的销售金额相加，就可以得到1个季度的销售金额；通过将 12 个月的销售金额相加，可以得到全年的销售总金额。

确定了数据仓库的粒度模型以后，为提高数据仓库的使用性能，还需要根据用户的要求设计聚合。数据仓库中各种各样的聚合数据主要是为了使用户获得更好的查询性能，因此聚合模型的好坏将在很大程度上影响到数据仓库的最终使用效果。

在设计聚合模型时，首先需要考虑用户的使用要求，其次要考虑数据仓库的粒度模型和数据的统计分布情况。

数据仓库的一般用户在其日常工作中己经有了按照地理位置、产品类型和时间范围的报告。在数据仓库的聚合设计中，应该对每个维进行审查，以确定哪些属性经常用于分组，这些属性的组合有多少。例如，如果考虑某一主题有4个维度，每个维度有3个可以作为聚合的属性，那么最多可以创建256个不同的聚合。当然．在实际工作中是没有必要创建这么多聚合的，只需考虑在数据仓库中经常使用的聚合。此时，可以审查数据仓库的需求分析文档，了解用户的需求情况。然后确定哪些内容会对聚合有影响，并通过对数据的审核获取每个维度中不同聚合的统计数据。

数据仓库的聚合模型的设计与数据仓库的粒度模型紧密相关，如果数据仓库的粒度模型只考虑了细节数据，那么就可能需要多设计一些聚合，如果粒度模型为多层数据则在聚合模型设计中可以少考虑一些聚合。

在建立聚合模型时还需要考虑作为聚合属性的数量因素。例如，在数据仓库中有1 000 000个值用于描述商品信息的最底层信息，如果用户在使用数据仓库时用500 000个值描述商品

最底层的上一层次的信息，此时进行聚合处理并不能明显提高数据仓库的使用性能。但是如果商品上一层次的信息用75 000个值描述，那么就应该使用聚合表提高数据仓库的使用性能。

3.5.5 数据分割

如果粒度和分割都做得很好的话，则数据仓库设计和实现的几乎所有其他问题都容易解决。但是，假如粒度处理不当并且分割也没有认真地设计与实现，这将使其他方面的设计难以真正实现。数据分割是指把数据分散到各自的物理单元中去，使它们能独立地处理。分割是数据仓库中继粒度问题之后的第2个主要的设计问题。

为什么分割如此重要呢？因为小的物理单元能为操作者和设计者在管理数据时提供比对大的物理单元更大的灵活性。数据仓库的本质之一就是灵活地访问数据。如果是大块的数据，就达不到这一要求。因而，对所有当前细节的数据仓库数据都要进行分割。分割的原理类似如图3-42所示，由于全部销售记录过于庞大，可以按照不同的年度把它分为5个小的物理单元。

图3-42 数据分割处理

例如，在第2章用到的foodmart 2000.mdb中，由于设计该数据库的时候考虑到了它将要作为数据仓库使用，因此，对于销售事实按照年份分割成了sales_fact_1997、sales_fact_1998和sales_fact_dec_1998 3个表，对库存事实则分割成了inventory_fact_1997和inventory_fact_1998两个表，如图3-43所示。

图3-43 Foodmart数据库中的数据分割

在工程实践中，除了时间以外，还可以有多种数据分割的标准。例如商务业务、地理位置和组织单位或者各种标准的综合。

3.6 规划分析的视角：维度

对客户、产品、服务、提供商、地点、渠道和事件发生的时间及对企业来说很重要的其他实体的观察是商业智能的基本驱动力。当它们在一个关系数据库中表示和抽象出来的时候，它们便叫做维。维是人们观察客观世界的角度，是一种高层次的类型划分。例如如果希望按照时间，或者按照地区或产品进行分析，那么这里的时间、地区和产品就是相应的维度。基于不同的维度，可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。

3.6.1 维度的构成

在图3-10的星形架构图中可以看到，处于星形结构中央的事实表不仅包含度量，而且也包含维表的外键和事实表的主键。维度表除了代表维之外，还具有字段，例如客户维度表包含一个主键“CustomerKey”和用来向客户提供信息的其他字段。维度由主键和维属性构成。维属性是维表里的列。维元素定义维表中的层次关系，属性则以用户熟悉的术语描述维元素。图3-44显示了维元素和相关属性的关系。

图3-44 维元素和相关属性的关系

在设计过程中，来自数据源的数值数据字段到底是一个已度量的事实还是一个维度的属性是比较容易混淆的一个问题。一般情况下，在每次抽样时，如果数值数据字段的度量都改变，那么它就是事实，如果它是某种东西的离散值描述，并几乎保持为常数，那么它就是维属性。

3.6.2 维度的特性

所有的维度都有一些共同特性，它们包括以下几个方面。

（1）维存在于关系式的表中，包含了键值和支持的属性，而且属性与所陈述的事实高度相关。对于属性一般使用简单易用的文字信息，不应该有代码或缩写，没有空值或NULL，没有无用或过时的数值。

（2）维度使用解析过的时间、名字或地址元素，这样可以使你的查询更灵活。比如时间可分为年、季度、月、周和日等；个人的名字可以分为姓氏和称谓（如先生或小姐）；组织名可以用部门来区分；地址则可以用地理区域来区分（如国家、州省和、城市）。

（3）不要使用业务数据库的键值，对每个维表另外增加一个额外的惟—值字段作为主键来识别维表实体，通常最常使用的字段类型是Identity类型或者16位格式的全局唯一标识符（Global Unique Identity，GUID）。这样，就不需要改变OLTP系统可能会发生的重复情形，也使得OLTP系统可以重复使用键值。这个在维表中新设定的键也叫代理键。

（4）维表至少包含一个决策因子，每个决策因子字段可以通过使用相关的主键，并结合事实表的KPI数据来响应用户的查询。

（5）维度表应该包含有随时间变化的数据记录字段，当数据集市或数据仓库的数据随时间变化而有额外增加或改变时，维表的数据行应该随着维属性的变化而变化。

3.6.3 维度的分类

维度主要有4种类型，包括结构维、信息维、分区维和分类维。结构维最为普通，它包含具有层次结构的成员；信息维包含需要计算的属性；分区维用于信息的比较，如计划销售情况和实际销售情况；分类维用于根据维的属性来分组。此外，还有一些结构上比较特殊的维，如退化维和垃圾维等。

1．结构维

结构维表示在层次结构组成中的信息量度。因此，年、月和日可以组成一个结构维。一个部门将总销售量用作一个度量，便是如何应用结构维的一个例子。与这个度量相关的是包含涉及产品的所有属性的产品信息表。可以通过产品信息表生成的维可能是“product_name”、“product_brand”、“product_category”、“product_department”和“product_family”。

在此会发现，这个产品维可以组成一个层次结构。增加一个时间信息表，就可以通过由年、月和日组成的时间信息对象建立一个时间维。通过这个度量和2个结构维，可以用SSAS确定一种特殊产品在某一特定时期的销售总量。 下面是一些普通的结构维：

l 客户地理位置维这个维可提供一个根据客户所在地进行归类的层次结构。客户维的典型例子是“customer_city”、“customer_state”和“custmer_country”。这个维通常用于查看不同的地理位置在销售、利润和其他客户度量方面的不同。

l 时间维可表明事件发生的时间。典型的时间维应该是年、月和日。

l 销售人员地理位置维这个维可提供一个根据销售人员所在地域进行归类的层次结构。这个维通常用来查看工作在不同地域的销售人员的销售情况和利润等。

l 产品维出售的产品。这个层次结构可能包括“product_name”、“product_brand”、“product_category”和“product_department”。这个维用来查看不同类别的产品的销售利润和其他指标。

所有这些结构维都包含他们所在层次结构的属性。在结构维中层次是非常重要的，所以要在下面分别进行讨论。首先来看另外3种维：信息维、分类维和分区维。

2．信息维

信息维是计算字段建立的。用户也许想通过销售利润了解所有产品的销售总额。也许希望通过增加销售来获得丰厚的利润。然而，如果某一款商品降价销售，可能会发现销售量虽然很大，而利润却很小或几乎没有利润。从另一方面看，用户可能希望通过提高某种产品的价格获得较大利润。这种产品可能具有较高的利润空间，但销量却可能很低。因此，就利润建立一个维，就销售总量建立一个度量可以提供有用的产品信息。

用户可以对利润进行2种计算。第1种是计算每种商品的平均利润，这一方法很简单，即用销售价格减去销售人员的开销。知道了每种商品的平均利润之后，还可以用它乘以每一天的销售量从而得到每种商品每一天的总利润。

真实世界在实际应用中，也许需要进行很多项这样的计算，因为每一天的销售价格和开销都有很大差异。因此，需要一个包含每天的销售价格和每天开销情况的表。在用户查看的时间段上，每一天的销售价格和每天的开销情况都是有区别的，需要进行合计并求平均。某一天每种商品的利润乘以这一天的销售量等于当天的总利润，选定时间段的利润总和为各天的利润之和。

创建了一个包括每种商品利润和全部利润的维，就有了一个信息维。

3．分区维生成信息表

以同一结构生成两个或多个维时，要用到分区维。例如，用户可能要创建用于预测销售额和实际销售额的两个维。这两个维的结构相同，只是数值不同。另一个例子是时间维，每一年有相同的季度，相同的月和相同的天（除了闰年以外，而它不影响维）。在OLAP Services中，将频繁使用时间分区维来分割数据仓库中的数据。

例如：为下列结构生成两个同样的维。

the_day the_month the_year

一个时间维中的数据是针对1998年的，而另一个时间维中的数据针对1999年的。建立事实表时，可以把度量分割为1998年的数据和1999年的数据，这将带来许多益处。

4．分类维

分类维是通过对一个维的属性值分组而创建的。如果客户表中有家庭收入属性，那么，可能希望查看客户根据收入的购物方式。为此，可以生成一个含有家庭收入的分类维。

例如：如果有以下家庭每年收入的数据分组：0~20 000元、20001~40 000元、40 001~

60 000元、60 001~100 000元和大于100 001元。现在就可以考虑如何度量，例如，从这些分类中的每一个所购买产品的数量上来看他们的收入水平怎样和购买量怎样。另外一个可能的分类是家庭成员的性别和数量。

5．特殊维类型

特殊的维主要是在结构上区别于常见的维度，主要有退化维、垃圾维和一致维3类。

（1）当维表中的主键在事实表中没有与外键关联时，这样的维称为退化维。退化维与事实表并无关系，但对于一般在企业事件中跨越维之间数据时，所用到的约束，也就是查询限制条件（比如订单号码、出货单编号等），这时就常用退化维。以销售分析而言，通常是把出货日期作为事实的时间，而把订单日期或需求日期等作为查询条件，这里，订单日期或需求日期就是退化维。

（2）垃圾维。针对某企业事件，通常提供了必要的查询值，但是却没有直接映射信息对象产生的维表，这样的字段就是垃圾维。一般来说，如果OLAP系统包含杂乱的标识和文字属性，而且与时间维以外的维表没有关系，就可以使用垃圾维。唯一要注意的是，垃圾维必须是对企业决策潜在限制值非常重要的属性，通常会创建一个维表来存储这些属性。

（3）一致维。当有好几个数据集市要合并成一个企业级的数据仓库时，可以使用一致维来集成数据集市以便确定所有的数据集市可以使用每个数据集市的事实。所以，一致维常用于属于企业级的综合性数据仓库，使得数据可以跨越不同的模式来查询。

3.6.4 维度的层次和级别

“维”一般包含着层次关系，这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维（dimension），使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。

这里首先要确定维度的层次和级别。如图3-45所示，在时间维度上，按照“年－季度－月”形成了一个层次，其中“年”、“季度”和“月”成为这个层次的3个级别。同理，当建立产品维度时，可以将“产品大类－产品子类－产品”划为一个层次，其中包含“产品大类”、“产品子类”和“产品”3个级别

图3-45 维度的层次和级别

分析中所用到的这些具有层次的维度，在数据仓库中的存在形式，一般说来，有合并维分层结构和雪花分层结构2种方式。

1．合并维分层结构

合并维分层结构的最显著的特点是将不同分层结构的信息对象完全合并到同一个维中。如产品维表可能就包含产品总类、产品类别、产品详细类别及产品名称等，如图3-46所示。

合并维分层结构是星形模式的标准分类法，它有2个特点。

（1）查询简单：由于所有的分层结构都合并在同一维表中，因此不需要知道每个分层结构的表名称，也不需要额外的表连接。

（2）需要较多的硬盘存储空间：因为没有做过正规化，所以存在数据重复。

2．雪花分层结构

这种分层结构类似正规化，所有类别用独立的表来存储数据。也就是将产品详细类别、产品类别及产品总类这3个分层结构分别独立成一个表，再用主键与外部键来维持彼此的关系。如图3-48所示。

雪花分层结构把星形模式进行正规化，也因此产生了两种OLAP标准模型，星形模式与雪花模式，它的特点是：

l 节省硬盘空间：因为做过正规化，所以没有冗余数据。

l 查询较复杂：由于所有的分层结构都在不同的表中，因此除了需要进行表连接以外，还需要知道每个分层结构所属的表名。

图3-48是产品维度分别保存产品大类、产品子类和产品3部分数据形成的雪花分层结构。

图3-48 产品维在数据仓库中的储存形式

3.6.5 维度的缓慢变化特性及其处理

维度可以根据变化剧烈程度主要分为无变化维度、缓慢变化维度和剧烈变化维度。例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变的部分，政治面貌和婚姻状态属于缓慢变化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。

对于剧烈变化维度，通常情况下都是一分为二进行处理的，把其中不常变动的部分单独抽出来作为一个维表，按照缓慢变化维方式进行处理；另外一部分也单独抽取出来，通常作为维度的属性进行处理。

大多数维度表随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度和使用维度的过程中，就要考虑到缓慢变化维度的处理。

维度的缓慢变化有3种不同情况，其对应的处理方法也有所不同。

1．历史数据需要修改

这种情况主要是发生在业务数据库中的数据出现错误，在分析过程中需要修改。 处理办法是用直接覆盖法，即使用UPDATE方法来修改维度表中的数据。例如商店维度中商店经理是张三，后来错了，需要改写成李四，那么，我们就在ETL处理时，直接修改维度表中原来的商店经理为李四，如图3-49所示。

2．新增数据维度成员改变了属性

若某维度成员新加入了1列，该列在历史数据中不能基于它浏览，而在当前数据和将来数据中可以按照它浏览。此时的解决方法是增加数据行来记录新成员。可以使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看，如图3-50所示。

3．历史数据保留，新增数据也要保留

在这种需求下的解决方法是创建额外字段来记录这些数据之间的关系，例如将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始匹配生成事实表时将按照时间段进行关联，这种方法其最大的优点在数据更改时，不需要创建额外的数据行，也不需要改变维表中的键值结构，因此可以在现有的数据行中查看所有历史纪录。而最大的缺点是由时间点来判断更新的数据很难查询，如果数据经常变化，则此方法并不适合，如图3-51所示。

图3-51 加上时间戳来处理维度

3.6.6 典型的维度设计

在数据仓库设计中，有一些维度是常用的，下面将列举几个常用的维度设计。

1．时间维度

时间维度是最常见的维度，数据仓库保留的是系统历史的数据，商务分析最基础的一个维度就是时间维度。图3-52展示了一个时间维度及其层次关系，在图中时间包含年、季度、月、星期和日等5个层次，实际应用可能还会在月和星期之间增加旬层次，对日可能还会进一步分类，如节假日和工作日，以及周末和非周末。进行这些分类的目的是为了适应业务分析的需要。比如电信公司为了促进用户在节假日和周末多打电话，便在节假日和周末对通话资费实行优惠。服务性公司在周末和工作日也采用不同的服务方式和收费方式。

另一类型常见的时间维度是按照财年定义的时间维度，如图3-53所示，这在财务方面的分析是必须使用的。其中定义了财年（Fiscal Year ID）、财季（Fiscal Qtr ID）、财月（Fiscal MonthID）、财周（Fiscal Week ID）和财日（Fiscal Day ID）还增加了一些标识，诸如季节标识（SeasonID）、周末标识（Weekend Flag）和节假日标识（Holiday Flag）。涉及财务问题的项目需要将普通的时间信息同财务时间进行非常细致地转化。

2．地理维度

地理维度在OLAP展现中也是常见的，如图3-54所示的国家、区域和分区域。通常地理维度的展示要同地理信息系统结合起来，使得最终用户能够得到更加直观的概念。

3．机构维度

机构维通常是指实施项目的公司的机构组织情况。有的公司可能需要将公司各个部门或者各个分公司之间进行对比，这时就需要建立机构维。

某些公司的机构维和地理维有部分的重叠，比如国内子公司的划分基本上是按照省市区域进行的。但是机构维同地理维在本质是不同的，地理维描述的是地理信息，而构维描述的是公司的机构组织情况，这两个维度不能混同。比如某公司在某些地方没有开设分公司，这些地区在分公司上没有体现，但是这些地区将在地理维度上体现。

图3-55示例了某公司的机构维度层次。总公司下设各省公司，在省公司下设各个城市分公司，在地市局下设业务部门，业务局是最小的单位。

4．客户维度

任何公司都是服务于客户的，因此客户维度是必不可少的。分析客户背景信息对客户消费行为的影响，通过客户背景信息对客户群体进行合理地分类能够对公司的市场策略等方面提供有效的指导。常用的客户背景包括客户年龄、性别、婚姻状况、爱好和教育程度等，客户维度分类如图3-56所示。

数据仓库主要用于商务分析和决策支持，维度自然要体现业务特色，比如保险、金融或服务行业均有不同的分类方法，通常这些方法要针对具体用户而有所不同。在对数据仓库进行分析时，维提供了路径，沿着路径会发生数据基本聚合的“上钻”或“下钻”。这条路径位于一个层次结构中，体现的是用户对分析查询的需求，因而是先于维内容而建立的。

以上3节完成了从主题到维度的设计，可以说，概念模型和逻辑模型都已经完成了，下面的任务就是要依照逻辑模型来设计物理模型。

3.7 数据仓库物理模型设计

数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。

为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。

3.7.1 设计存储结构

在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。另外，在设计时还要考虑数据在特定存储介质上的布局。在设计数据的布局时要注意遵循以下原则。

l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。

l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。

l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。

l 不要把表格和它们的索引放在同一设备上。一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。

在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。

3.7.2 设计索引策略

数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。由于数据仓库的数据一般很少更新，所以可以设计索引结构来提高数据存取效率。在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。

数据仓库中的表通常要比联机事务处理系统（OLTP）中的表建立更多的索引，表中应用的最大索引数应与表格的规模成正比。数据仓库是个只读的环境，建立索引可以取得灵活性，对性能极为有利。但是表若有很多索引，那么数据加载时间就会延长，因此索引的建立需要进行综合的考虑。在建立索引时，可以按照索引使用的频率由高到低逐步添加，直到某一索引加入后，使数据加载或重组表的时间过长时，就结束索引的添加。

最初，一般都是按主关键字和大多数外部关键字建立索引，通常不要添加很多的其他索引。在表建立大量的索引后，对表进行分析等具体使用时，可能需要许多索引，这会导致表的维护时间也随之增加。如果从主关键字和外部关键字着手建立索引，并按照需要添加其他索引，就会避免首先建立大量的索引带来的后果。如果表格过大，而且需要另外增加索引，那么可以将表进行分割处理。如果一个表中所有用到的列都在索引文件中，就不必访问事实表，只要访问索引就可以达到访问数据的目的，以此来减少I/O操作。如果表太大，并且经常要对它进行长时间的扫描，那么就要考虑添加一张概括表以减少数据的扫描任务。

3.7.3 设计存储策略

确定数据的存储结构和表的索引结构后，需要进一步确定数据的存储位置和存储策略，以提高系统的I/O效率。下面介绍几种常见的存储优化方法。

1．表的归并

当几个表的记录分散存放在几个物理块中时，多个表的存取和连接操作的代价会很大。这时可以将需要同时访问的表在物理上顺序存放，或者直接通过公共关键字将相互关联的记录放在一起。

在图3-57中商品表和商品存储关系表是2个经常需要同时访问的表，在对存储关系表进行查询后，需要通过商品ID到商品表中获取商品的其他基本属性，以比较直观的方式显示给最终用户。

图3-57 表归并的表现形式

对于这种情况，我们可以将2个表的记录通过公共关键字将相互关联的记录放在一起。如图3-57所示。设计时可以先存放商品ID为1的商品在商品表中的记录，然后将仓储关系表中同商品1相关的2条记录放在其后。这样，在进行数据访问时，就可以提高I/O的效率。

表的归并只有在访问序列经常出现或者表之间具有很强的访问相关性时才有较好的效果，对于很少出现的访问序列和没有强相关性的表，使用表的归并没有效果。

2．引入冗余

一些表的某些属性可能在许多地方都要用到，将这些属性复制到多个主题中，可以减少处理时存取表的个数。

例如，在图3-58所示的商品存储关系表中增加“商品名称”和“商品类型”等用户常用的字段。这样通过在逻辑设计中引入冗余数据来达到提高更新和访问速度的效果。

3．其他方法

除了以上2种主要的方法外，还有以下3种方法可以对存储分配进行优化。

l 建立数据序列。按照某一固定的顺序访问并处理一组数据记录。将数据按照处理顺序存放到连续的物理块中，形成数据序列。

l 表的物理分割。每个主题中的各个属性存取频率是不同的。将一张表按各属性被存取的频率分成2个或多个表，将具有相似访问频率的数据组织在一起。

l 生成派出数据。在原始数据的基础上进行总结或计算，生成派出数据，可以在应用中直接使用这些派出数据，减少I/O次数，免去计算或汇总步骤，在更高级别上建立了公用数据源，避免了不同用户重复计算可能产生的偏差。

以上完成了数据仓库从概念模型到物理模型的整个设计过程。下一步的工作就是创建数据仓库。由于数据仓库本身是由DBMS管理的，因此可以像创建普通的数据库一样创建设计好的数据仓库。这属于数据库管理的内容，具体创建过程参见《SQL Server 2005数据库管理与应用高手修炼指南》。

3.8 数据仓库设计示例

根据以上数据仓库的设计步骤，基本上可以完成大部分领域的数据仓库设计任务。这一节将给出2个数据仓库设计样板，一个是和企业产品销售相关的，一个是保险业务分析的。由于数据仓库的设计必须与具体用户的需求联系起来，这里没有必要再从需求分析开始，因此这2个示例只反映了业务需求的大致情况，而且只给出了最重要的逻辑模型，应用在实际项目中，会由于客户的需求不同而变得更加复杂。

3.8.1 销售数据仓库

在产品的销售业务中涉及到几个主要的业务指标（KPI），如销售量、销售额、库存量和库存数量等，它们日积月累，数量庞大。在设计的时候把这些指标作为事实表的度量。销售发生的时间、顾客、门店及销售的是何种商品等因素是分析销售业务的视角，把它们作为维度。在粒度划分上，时间维可以按日计，也可按周、按月、按季度和按年计，按照“最小粒度原则”，把时间维细化到了“日”的层次；对于商品维，由于分析的时候层次需求较为明显，可以分为商品单品、细分类、小分类、中分类和大分类等层次。其他维度都可以按照类似的方法来确定，最后可以得到销售数据仓库的逻辑模型，如图3-59所示。

这是一种雪花形结构的模型。按照此逻辑结构建立的数据仓库可以回答和销售相关的大部分商业问题。比如某时间段内商品销量的变化情况如何；哪些分类的商品销量最高或利润最大；哪些顾客购买力最强；哪个门店业绩最佳。构建这样一

个数据仓库需要从商品销售、顾客信息、商品采购和商品库存等业务数据库中获取数据。

3.8.2 保险业数据仓库

在保险行业决策者关注的关键指标有保额、保费、手续费和赔款金额等，可以把它们作为事实表的量度。保单的承保机构、险种、起保日期、经办人和代理人等则是观察这些量度的视角，把它们作为维度。建立的数据仓库逻辑模型如图3-60所示。

图3-60 保险业数据仓库逻辑模型（星形）

这是一个星形结构的模型。照此建立的数据仓库可以汇总各个层次的承保公司的保费收入情况和手续费情况等，也可以从险种、起保日期和经办人等角度按照各种层次进行分析汇总。

3.9 数据仓库数据库设计的心得总结

数据仓库是企业商业智能分析环境的核心，它是建立决策支持系统的基础。一个良好的数据仓库设计应该是构建商业智能和数据挖掘系统不懈的追求。下面把数据仓库数据库设计的心得做一小结。

3.9.1 透彻理解数据仓库设计过程

商业智能和数据挖掘归根到底是“从实践中来，到实践中去”。也就是说现实需求决定系统需求，业务数据决定系统构架，最终使用的时候又必须作用于现实需求，同时通过决策的行为影响业务。那么可以把数据仓库的设计看做是前一部分，

即“从实践中来”，数据仓库的应用可以看做是“到实践中去”。把“从实践中来”这个过程进行抽象，数据仓库的设计就是“客观世界→主观世界→关系世界”的过程。

在前面几节完成了6个任务：选择被建模主题的商业过程、确定事实表的粒度、区分每一个事实表的维和层、区分事实表的度量、确定每一个维表的属性、在DBMS中创建和管理数据仓库。实际上这些任务都可以归结到从客观世界到关系世界的过程。那么把这个过程再进行归纳，可以得到如图3-61所示的综合了模型、方法和过程的示意图。

图3-61 数据仓库设计过程的模型和方法示意图

3.9.2 把握设计的关键环节

如果将时间、精力、金钱和人事优先花在前面的20%，那么这20%会创造出80%的价值。这就是有名的2/8原则。下面将介绍在数据仓库设计中，哪些因素是属于这20%的范围。

1．需求

需求分析在任何如见项目中都是最为重要的因素之一。企业模型是从企业的各个视点对企业数据需求及数据间关系的抽象。通过将企业模型映射到数据库系统，可以很快地了解现有数据库系统完成了企业模型中的哪些部分，还缺少哪些部分。然后再将企业模型映射到数据仓库系统，发现企业需要的（或可以构造的）主题。通过这样的过程完成对企业数据需求和现有数据的了解，达到明了原有系统和需要建设的主题域间共性的目的。

2．关键性能指标（KPI）

一般而言，一个决策支持系统最重要的就是要呈现决策数据。而KPI就是决策过程中要显示的数据结果的部分，如销售数量、销售金额、毛利和运费等数值部分的数据。这些KPI是通过与相关的维表进行连接而映射出来的。在分析星形模式时，往往要首先确定KPI。

3．信息对象

信息对象是指在每个分析过程中那些会影响到决策的因素。以销售分析为例，时间、产品、员工与客户就是影响决策的大因子，而每个因子又可以分离出多个分层结构，如时间可分为年、季度、月、周和日等，员工可分为年龄层、年龄、年薪层、年薪和员工所在城市等，也就是影响决策的详细因子。这些都是信息对象。从这里我们可以看出，每个大因子如时间、产品、员工与客户等就可以构成如时间维表、产品维表、员工维表与客户维表等。而时间维表又可分为年、季度和日等字段。在分析和设计这些信息对象组成的维度时，需要注意维的唯一性和公用性，千万不要在不同的主题中定义多个表示同一内容的维，如果有可能，一个维表要尽量被多个主题共享。

4．数据粒度

在数据仓库的每个主题中，都必须考虑事实数据的粒度。粒度的具体划分将直接影响到数据仓库中的数据量及查询质量。在数据仓库开始进行分析时。就需要建立合适的数据粒度模型，指导数据仓库设计和其他问题的解决。如果数据粒度定义不当，将会影响数据仓库的使用效果，使数据仓库达不到设计数据仓库的目的。

5．数据之间的联系

在数据仓库中，不同主题的数据之间的物理约束或许不再存在，但无论这些数据如何变化，要知道必须有一些“键”在逻辑上保持着不同数据之间的联系，这样就可以保证有联系的主题数据之间可以进行汇总以支持未知的应用，否则数据仓库的数据便是一潭死水，不可能灵活支持各种应用。

3.9.3 分离非分析数据

为了提供OLAP分析的性能，应当让维表和事实表尽量“精练”，也就是只包含分析需要的数据，而对于分析不需要或者很少使用的数据，应当将它们从维表分离出去。如果维表占据的空间比较小，维表就可以存放在一个磁盘块中，在该磁盘块被读取后，维表能够始终放在高速缓存中，从而提高多维查询的速度。

对于数据是否是非分析性数据，必须具体问题具体分析。就拿姓名来说，很少问题会分析它，客户的姓名只是客户的一种标识，在维表和事实表中使用客户标识号比使用客户姓名要方便得多。但是如果是人口普查部门调查姓氏的构成情况和重名情况，此时姓名就成为非常关键的分析变量。因此，数据仓库设计时应当对维表和事实表中的各个字段都进行推敲，尽可能地将不必要的数据从维表中分离出去。

数据仓库的数据内容、结构、粒度、分割及其他物理设计需要根据用户所返回的信息不断地调整和完善，而且数据仓库需要通过不断地理解用户的分析需求，向用户提供更准确和更有用的决策信息，所以数据仓库对灵活性和扩展性有较高的要求，它的建立是一个动态、循环和反馈的过程，数据仓库的设计也必须遵循螺旋式发展的道路。