长文详解数仓开发与应用全生命周期

模型是实际系统的表示，它向用户展现了重要的系统特征。同时，模型通过消除与其目的无关紧要的特征来简化显示。模型是对现实世界进行抽象的工具。在信息管理中需要将现实世界的事物及其有关特征转换为信息世界的数据才能对信息进行处理与管理，这就需要依靠数据模型作为这种转换的桥梁。设计一个能够真正支持用户进行决策分析的数据仓库，并非一件轻而易举的事情。这需要经历一个从现实环境到抽象模型，从抽象模型到具体实现的过程。完成这个过程建立各种不同的数据模型是必不可少的。

数据仓库模型设计包括概念模型设计、逻辑模型设计、物理模型设计等内容。数据仓库的建模首先要将现实的决策分析环境抽象成一个概念数据模型。然后，将此概念模型逻辑化，建立逻辑数据模型。最后，还要将逻辑数据模型向数据仓库的物理模型转化。

数据仓库的开发应用像生物一样具有其特有的、完整的生命周期，Kimball在《数据仓库生命周期工具箱》中将数据仓库分为七个阶段，如图1所示。

图1 Kimball生命周期图

Kimball将BI和技术产品都包括在内，适用于一个数仓从头开始构建，本文主要针对基础设施已经建成的数据仓库，所以将数据仓库的开发应用周期简化分成：数据仓库规划阶段、数据仓库设计阶段以及数据仓库的使用维护三个阶段。

这三个阶段是一个不断循环、完善、提高的过程。在一般情况下数据仓库系统不可能在一个循环过程中完成，而是经过多次循环开发，每次循环都会为系统增加新的功能，使数据仓库的应用得到新的提高。

图2 数据仓库开发应用生命周期

一数据仓库的规划1.1选择数据仓库实现策略

开发策略主要有两种，一种是自顶向下，实际应用比较困难；另一种是个自底向上，用于一个数据集市或一个部门的数据仓库开发 ，容易获得成功 。

两种策略的联合使用，能够快速地完成数据仓库的开发与应用，而且还可以建立具有长远价值的数据仓库方案。在实际使用中难以操作 。

1.2确定数据仓库的开发目标和实现范围

首要目标是确定所需要信息的范围，确定数据仓库在为用户提供决策帮助时，在主题和指标领域需要哪些数据源。另一个重要目标是确定利用哪些方法和工具访问和导航数据？其它目标包括确定数据仓库内部数据的规模，使用范围确定。可以从用户的角度和从技术的角度两个方面分析。

1.3数据仓库建设规划及预算

实际使用方案是一个非常重要的需求原型，可以将最终用户的决策支持要求与数据仓库的技术要求联系起来。说明系统与企业战略目标的关系，系统与企业急需处理的、范围相对有限的开发机会。业务机会的说明以及任务概况说明、重点支持的职能部门和今后工作的建议。计划中需要阐明期望取得的有形和无形利益。业务价值计划最好由目标业务主管来完成。规划书中要确定数据仓库的开发目标实现范围、体系结构和使用方案及开发预算。

二数据仓库的概念模型设计

数据仓库概念模型设计的目的是对数据仓库所涉及现实世界的所有客观实体进行科学、全面地分析和抽象，制定构建数据仓库的“蓝图”。数据仓库的概念模型设计时需要确定数据仓库的主要主题及其相互关系。主题应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系，根据需求分析确定几个基本的主题域及其维度。概念模型设计主要完成以下工作：

1、界定系统边界

即进行任务和环境评估、需求收集和分析，了解用户迫切需要解决的问题及解决这些问题所需要的信息，需要对现有数据库中的数据有一个完整而清晰的认识。

2、确定主要的主题域

对每一个主题域的公共码键、主题域之间的联系、充分代表主题的属性进行较明确的描述。

3、确定分析的维度和分析的内容

一旦主题划分清楚了，接着就要细化分析的具体内容以及根据分析内容的性质确定分析维度。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，一般情况下，作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。

概念模型的设计可以分为以下几个阶段：用户需求调查、模型定义、模型分析和模型设计。

2.1企业模型的建立

进行数据仓库数据建模之前，对数据仓库的需求进行分析是必不可少的，数据仓库需求分析需要对来自多个领域的需求进行详细分析。需求分析的方式有两种：一是对原有固定报表进行分析；二是对业务人员进行访谈。原有固定报表能较好地反映出原业务对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但数据仓库建设中仅仅替代目前的手工报表还是不够的，因此还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分，数据仓库的主题划分实际上与分析内容的范围直接相关。

最终用户的需求体现在对工作流程的分析、决策的查询需求、报表需求、操作需求和数据需求等方面。

数据仓库的最终用户只能通过查询和报表工具以及数据仓库内部信息的某种映射关系来访问数据仓库内部数据，对他们而言，数据仓库是一个黑箱。

最终用户指定数据分析的类型，这些数据分析操作主要是对数据项进行揭示更多的细节的分片和细剖，寻找企业隐含行为的数据挖掘，在对数据进行分析时可从二维或多维的、电子表格的、关系的、报表的、图表的和运营样本的数据等方面进行分析。

决策分析问题	客户购买商品趋势分析
需求信息类	日期	地点	商品	客户年龄组	客户经济状况	客户信用
需求信息1层 需求信息2层 需求信息3层 需求信息4层 需求信息5层 ……	年(4) 季(16) 月(48) ……	国家(15) 省(60) 市(200) ……	商品种类(7) 商品小类(40) ……	年龄组（8） ……	经济类（10） ……	信用（10） ……

表1 数据仓库用户的决策分析工具

	Oracle	Sysbase	SQL Server	VFP	其它模式
销售单输入	√			√
销售单处理	√			√
商品管理		√
预算系统					√(Excel)
财务计算			√
库存控制			√
后勤				√
外部数据源
商品供应商				√
市场调查公司			√

表2 支持决策的数据需求分析工具

下面以A公司为背景，该公司是一家大型跨国生产公司，其产品主要包括生产金属和复合材料的自行车，公司总部设在中国的北京市，有500名雇员，该公司在世界各地均建立了区域性销售团队，产品远销北美、欧洲和亚洲市场。A公司目前的目标是专注于向高端用户提供产品，通过外部网站扩展其产品的销售渠道、通过降低生产成本来削减其销售成本。

下面将通过介绍该公司的原材料采购、生产和销售等环节的业务流程，提出该公司的数据仓库需求。

1、原材料采购业务流程

A公司内部由采购部负责原材料采购，采购部门下设一个经理和多个采购员。每个采购员需要了解原材料和供应商的联系，负责多种原材料的采购，一种原材料只能由一个采购员采购，采购员和商品之间是一对多关系；一种原材料有多个供应商，一个供应商可以提供多种原材料，原材料和供应商之间是多对多的关系；采购部门经理需要管理员工,并且还需要了解原材料的库存情况,以确定需要采购的商品并将任务分配给每个采购人员。

2、库存业务流程

A公司由仓库管理部门对原材料、产品等物料信息进行库存管理，仓库管理部门管理多个仓库，下设一个经理和多个仓库管理员，每个仓库有多个仓库管理员，每个管理员只能在一个仓库中进行工作。仓库管理员需要知道他所管理的仓库中存储的物料的种类、数量、存储的时间、原材料的保值期及原材料进入仓库和离开仓库的时间等信息。一个仓库可以保存多种物料。仓库管理部门经理不但需要处理仓库管理员需要的数据，而且需要知道仓库管理员的基本信息，如家庭地址、联系电话等。

3、产品销售业务流程

A公司的产品远销北美、欧洲和亚洲市场。公司目前有网络销售和批发商销售两种销售渠道。因此，客户也分为个人消费者和商店两类，个人消费者是从在线商店购买产品的消费者，商店是从A公司销售代表处购买产品后进行转售的零售店或批发店。销售人员关心产品的信息，包括：产品的价格、质量、颜色和规格等，以便向顾客推销相关的产品。销售部门经理需要了解产品销售情况， 以便在某种产品缺货时通知仓库管理部门运送商品；同时，他还需要了解每个销售员的工作业绩，对每个销售员进行考核，即销售部门经理需要了解商品、顾客和部门员工的情况。

在设计数据仓库数据模型时要从业务蕴涵的数据视角来理解业务，从业务分析中可以看出，不同部门对数据需求不同，同一部门人员对数据需求也存在差异。如管理人员和普通业务人员对数据要求的程度是不同的，管理人员可能需要综合度较高或较为概括的数据，而普通业务人员需要细节数据。因此，数据仓库项目需求的收集与分析需要从历史数据与用户需求两个方面同时着手，采用“数据驱动+用户驱动”的设计理念。

2.2规范的数据模型

关系模型是具有二维表格形式的数据模型，它建立在关系代数的基础上。是传统数据库中最常用的数据模型，其特点是把数据组织成二维表的形式，无论是实体还是实体间的联系都采用二维表，二维表的每一行叫作关系的一个元组，每一列叫作关系的一个属性。关系中的每一列的值总是取自一个集合，这个集合称为域。

关系模型可以用实体-联系 (Entity-Relationship简称E-R)图来表示。E-R图通过定义了数据间的关系，去除数据冗余，使操作型处理简单，还可保证数据一致性。因此，关系模型在传统的操作型数据库系统中获得了巨大的成功。

范式是关系数据库模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化(Normalize)。

A公司的业务数据分为5大部分，如表3所示。

表类名	含义
Human resources	人力资源相关信息
Person	客户或供应商联系人等人员信息
Production	产品信息
Purchasing	采购信息
Sales	销售信息

表3 A公司的数据架构列表

这5个架构相关的表信息如表4所示。

表4 A公司的数据表信息

表5 A公司Purchasing purchase orderheader的表结构

在实际设计中用于数据仓库设计的概念模型与业务数据处理系统的数据模型仍然具有一定的差距。

数据类型的差距：数据仓库的概念模型只包含用户所感兴趣的分析数据、描述数据和细节数据。

数据的历史变迁性：数据仓库的概念模型扩充了关键字结构，增加了时间属性并作为关键字的一部分。

数据的概括性：数据仓库的概念模型中还增加了一些基本数据所导出的衍生数据用于管理决策分析，这些在业务处理系统中是不存在的。

数据仓库项目需求的收集与分析需要从历史数据与用户需求两个方面同时着手,采用“数据驱动+用户驱动”的设计理念。

数据驱动是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库，用户驱动则是根据用户业务的方向性需求，从业务需求出发，确定系统范围的需求框架。如图3所示，常常用“两头挤法”找出数据仓库系统的真正需求。

图3 用户驱动与数据驱动相结合示意图

在企业模型建立过程中，与用户交流时，须确定数据仓库需要访问的有关信息。例如，A公司管理要在数据仓库中得到有关产品销售收入的详细统计信息，可以确定其度量指标如下：

度量指标：包括产品销售的实际收入、产品销售的预算收入及产品销售的估计收入。

维度指标：包括已经销售的产品信息、销售地点和顾客信息等。

根据分析，可建立A公司的企业数据模型如图4所示。

图4 A公司企业数据模型

2.3常见的概念模型

在概念模型设计中，常用E-R图作为描述工具。E-R图中，长方体表示实体，即数据仓库的主题域，框内写上主题域名称；用椭圆表示主题域的属性，用无向边把主题域与其属性连接起来；再将边表示主题域之间的联系，主要有一对一的关系、一对多的关系、多对多的关系。

主题，是指在较高层次上将业务数据进行综合、归类和分析的一个抽象概念，每个主题基本对应业务的一个分析领域。在主题分析中须对分析对象数据形成一个完整并且一致的描述，主题是根据分析需求确定的。主题域是对某个主题进行分析后确定的主题边界。主题域的确定通常由最终用户和数据仓库的设计人员共同完成。

例如，对于A公司的管理层可能需要分析的主题包括供应商、商品、客户和库存情况等主题。其中商品主题的内容包括记录各经销商商品的销售情况、公司商品库存情况、商品中各组成物料的采购情况等；客户主题包括的内容有客户购买商品情况；库存情况主题分析主要包括商品的存储情况和仓库的管理情况等。根据分析主题和主题域可得到A公司的主题及主题域结构如图5所示。

图5 A公司主题及主题域划分

接着可以用建立信息包图的方式进一步细化概念模型。信息包图是在某主题域中的一个主题分析的信息打包技术，它反映了在数据聚合条件下的多维数据在计算机内部的存储方式，可以体现各个不同平台的各个信息的聚合的概念性含义，主要包括定义指标、定义维度、和定义类别三个方面的内容。信息包图法也叫用户信息需求表法,就是在一张平面表格上描述元素的多维性,其中每一个维度用平面表格的一列表示,例如时间、地点、产品和顾客等。信息包图定义主题内容和主要性能指标之间的关系，其目标是在概念层满足用户需求。信息包图拥有三个重要对象：度量指标、维度、类别。利用信息包图设计概念模型就是要确定这三方面内容。

确定度量指标。度量指标表明在维度空间衡量业务信息的一种方法，是访问数据仓库的关键所在，是用户最关心的信息。成功的信息包可以保证用户从信息包中获取需要的各个性能指标参数。

确定维度。维度提供了用户访问数据仓库信息的途径，对应超立方体的每一面，位于信息包图第一行的每一个栏目中。

确定类别。类别是在一个维度内为了提供详细分类而定义的，其成员是为了辨别和区分特定数据而设，它说明一个维度包含的详细信息，一个维度内最底层的可用分类又称为详细类别。

例如：A公司销售分析主题的信息包图如表4所示。

注：度量指标包括实际销售额、计划销售额、计划完成率。

表6 A公司销售分析主题的信息包图

虽然数据仓库的基础是规范化的数据模型，规范化数据模型在数据仓库的实际应用中并不理想。关系模型在传统的操作型数据库系统中获得了巨大的成功，但以E-R图展示的关系模型不适用于以查询为主的数据仓库系统。在完全规范化的环境中，数据模型形成的数据表的数据量都是比较小的，为完成对这些“小”表的处理需要应用程序对这些表进行动态互联操作，这需要在不同表之间进行多个I/O操作，对于数据量十分庞大的数据仓库，这种多表连接操作的时间代价太大，对决策效率的提高非常不利。

因此在数据仓库中需要进行数据的非规范化的处理，以减少对表联接的需求，提高数据仓库性能，提高查询效率，同时也减少编写专门决策支持应用程序的必要性，可以让用户运用一些专门的查询工具，更容易地访问数据，用户还能以直观的易于理解的工具查看数据。因此，在数据仓库的模型构建中，有时为了提高数据仓库的运行效率，需要进行数据模型的反规范化处理。因为数据仓库属于分析型应用系统，系统的使用者是分析人员、决策人员，对他们而言，记住实体-关系及其属性是不可能的，因此系统的分析操作难以从具体的属性入手进行，而要基于集成或某种主题来组织数据。分析型应用需要的是快速、灵活、直观的数据检索也是关系模型无法支持的，这就要求寻找新的数据模型。

数据仓库数据模型设计的核心问题是多维数据的表示与存储的问题，因此多维数据模型成为当前数据仓库数据模型设计时的首选。多维数据建模以直观的方式组织数据，支持高性能的数据访问。多维数据模型较为普遍地采用星型模型、雪花模型的模式。

1、星型模型

星型模型是一种多维的数据关系，它由一个主题事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维主键，所有这些维主键组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据；而维主键大都是文字、时间等类型的数据。Adventure Works Cycles公司销售分析星型图如图6所示。

图6 A公司销售分析星型图

星型模型速度快是在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度很快。

由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合；而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。

2、雪花模型

雪花模型是对星型模型的扩展。设计星型模型时确定了概念模型中的指标实体和维度实体，当构成星型模型后，为了对相关维度进行更加深入的分析，经常要设计雪花模型，在星型模型的维度实体增加需要进行深入分析的详细类别实体。雪花模型对星型模型的维度表进一步标准化，对星型模型中的维表进行了规范化处理。雪花模型通过对维表的分类细化描述，对于主题的分类详细查询具有良好的响应能力。但由于雪花模型的构造在本质上是一种数据模型的规范化处理，会给数据仓库不同表的联接操作带来困难。A公司销售分析雪花模型如图7所示。

图7 A公司销售分析雪花模型图

完成概念模型设计以后，必须编制数据仓库开发的概念模型文档，并对概念模型进行评价。

（1）概念模型设计文档

数据仓库开发需求分析报告

概念模型分析报告

概念模型

概念模型的评审报告。

（2）概念模型的评审

确定概念模型是否完整地、准确地描述了用户的决策分析环境。确认用户是否已经和项目开发成员之间建立了稳定的联系。

（3）概念模型的评审人员

数据仓库项目负责人、数据仓库分析人员、数据仓库设计人员和数据仓库用户。

（4）概念模型的评审内容

数据仓库开发任务书；用户决策分析信息需求调查表；数据仓库主题；E-R图、星型模型和雪花模型。

三数据仓库的逻辑模型设计

逻辑建模是数据仓库建模中的重要一环，是概念模型到物理模型转换的桥梁。它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用，它通过实体和关系勾勒出整个企业的数据蓝图。

数据仓库的数据模型与传统数据库相比，主要区别如下：

数据仓库的数据模型不包含纯操作型的数据。

数据仓库的数据模型扩充了码结构，增加了时间属性作为码的一部分。

数据仓库的数据模型增加了一些导出数据。

数据仓库的逻辑模型与数据仓库物理实现时所使用的数据库有关，由于目前数据仓库一般都建立在关系数据库的基础上，因此数据仓库设计过程中所采用的逻辑模型主要是关系模型。关系模型概念简单、清晰，用户易懂、易用，有严格的数学基础和在此基础上的数据关系理论。

在进行数据仓库的逻辑模型设计时，一般需要完成主题分析、建立维度模型、确定粒度层次划分、确定数据分割策略等工作。

数据仓库是面向主题的，建立数据仓库要按照主题来建模，主题域的划分是数据仓库的基础和成败的关键。逻辑模型中主题分析是对概念模型设计阶段中确定的多个基本主题进行进一步分析，并建立某主题分析的维度模型。因此，在逻辑模型建模过程中进行的工作主要有：

事实表模型设计。分析丰富主题域，确定当前要装载的主题，进行事实表模型设计。

维度表模型设计。维度建模的目的是在为用户提供一组全局数据视图的基础上进行某一主题的业务分析。因为在数据仓库的维度建模技术中，主要从用户需求范围出发，考虑指标和维度及其各种主题下的分析参数。

关系模式定义。数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述。在这里，将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。

3.1事实表模型设计

数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。

选择一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统；还要考虑它足够小，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，可以针对它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。

下面以A公司为例，可以在“商品”、“销售”和“客户”等主题上增加能进一步说明主题的属性组，如表7所示。

表7 A公司部分主题的详细描述

度量是客户发生事件或动作的事实记录。例如客户购买商品，度量指标有购买次数、购买商品的金额、购买商品的数量等。度量变量的取值可以是离散的数值，也可以是连续的数值，还可以在某个元素集合内取值。例如：客户对公司服务质量评价可以是“优”、“良”、“中”、“差”集合中的一个；客户购买商品的金额是连续的数值；客户购买商品次数是离散的数值。

事实表是在星型模型或雪花模型中用来记录业务事实并作相应指标统计的表，事实表有如下特征：

记录数量多。因此事实表应当尽量减小一条记录的长度，避免因事实表过大而难于管理。

事实表中除了度量变量外，其余字段都是维表或者中间表（雪花模型）的关系。

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

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

事务事实。以组织事件的单一事务为基础，通常只包含事实的次数。

快照事实。以组织在某一特定时间和特殊状态为基础,即某一段时间内才出现的结果

线性项目事实。这类事实通常用来储存关于企业组织经营项目的详细信息。包括表现与企业相关的个别线性项目所有关键性能指标，如销售数量、销售金额、成本等。

事件事实。通常表示事件发生与否及一些非事实本身具备的细节。它所表现的是一个事件发生后的状态变化，如哪些产品在促销期间的销售状态（卖出还是没有卖出）。在事实表模型设计中还需要注意到派生事实。派生事实主要有两种。一种是可以用同一事实表中的其他事实计算得到，例如销售中的商品销售均价可以用商品的销售总金额和销售数量计算得到；另一种是非加性事实，例如各种商品的利润率等。

例如，可以设计A公司的销售事实表模型如表8所示。

表8 A公司销售事实表模型

3.2维度表模型设计

数据仓库是用于决策支持的。管理人员进行决策分析时，经常需要用一个对决策活动有重要影响的因素进行决策分析。这些决策分析的角度或决策分析的出发点就构成了数据仓库中的维，数据仓库中的数据就是靠这些维来组织，维就是数据仓库识别数据的索引。数据仓库中的维，一般具有层次性。其水平层次由维度层次中具有相同级别的字段值构成，垂直层次则由维度层次结构中具有不同级别的字段值构成。在数据仓库设计中根据需求获取数据仓库的维，构成数据仓库的模型。数据仓库中的多种维交点会构成数据仓库用户需要观察的事务。观察事务角度不同时，围绕该事务会产生多个观察角度，即产生了多维。数据仓库的立方体就是一个包含用户需要观察数据的集合体，立方体与星型模型可以相互转换。

维度建模的目的是在为用户提供一组全局数据视图的基础上进行某一主题的业务分析。因为在数据仓库的维度建模技术中，主要从用户需求范围出发，考虑指标和维度及其各种主题下的分析参数。

例如：根据A公司销售情况分析，其指标和维度及其各种主题下的分析参数可综合如下：

某些商品是否仅仅在某一地区销售?

每种类型商品各个时间段销售量及销售金额是多少?

各个客户购买商品次数?

客户及时付款了吗?

各类型商品预算收入是多少?

各销售员销售业绩如何?

……

根据以上问题的关联维度，形成A公司销售情况分析的维度模型,如表9所示。

表9 A公司销售情况分析的维度模型

在这个模型中，A公司有些决策管理者想要按照年、季、月、日的时间层次了解公司的销售情况；有些决策管理者想要按照产品名称、产品类别了解公司的销售情况；有些决策管理者想要按照销售员所在的区域层次了解公司的销售情况；有些决策管理者想要按照国家、省（州）、城市、销售点的区域层次了解公司的销售情况；有些决策管理者想要按照客户信用、客户收入等层次了解公司的销售情况。

这样，就可以建立销售情况分析的逻辑模型，如图8所示。

图8 A公司销售情况分析的逻辑模型

最后，对逻辑模型进行评审，并编写逻辑模型的文档，其内容包括：主题域分析报告，数据粒度划分模型，数据分割策略，指标实体、维实体与详细类别实体的关系模式和数据抽取模型。对逻辑模型评审主要集中在主题域是否可以正确地反映用户的决策分析需求，其内容包括：从用户对概括数据使用的要求，评审数据粒度的划分和数据分割策略是否可以满足用户决策分析的需要，为提高数据仓库的运行效率是否需要对关系模式进行反规范化处理，数据的抽取模型是否正确地建立了数据源与数据仓库的对应关系，数据的约束条件和业务规则是否在这些模型中得到了正确的反映等。

四数据仓库的物理模型设计4.1物理模型的设计要点

数据仓库的物理模型就是逻辑模型在数据仓库中的物理实现模式。物理模型就像大厦的基础架构,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计。物理模型包括逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置以及数据存储分配等。在进行物理模型设计时，要考虑I/O存取时间、空间利用率和维护代价。

根据数据仓库的数据量大及数据相对稳定的特点，可以设计索引结构来提高数据存取效率。数据仓库中的表通常比OLTP环境中的表建有更多的索引。通常表的最大索引数与表规模成正比。数据仓库是只读环境，建立索引对提高性能和灵活性都很有利。但是表索引如果太多，则会使数据加载时间加长。因此，一般按主关键字和大多数外部关键字建立索引。

确定数据仓库的物理模型，设计人员必须做这样几方面工作：

确定项目资源，定义数据标准；

确定软硬件配置；

全面了解所选用的数据库管理系统，特别是存储结构和存取方法；

根据具体使用的数据库管理系统，将实体和实体特征物理化；

了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求 ；

了解外部存储设备的特征 。

4.2数据仓库设计规范

数仓模型设计规范能够保证数据仓库的设计、实施和管理保持稳定，不产生混乱，需要对物理数据模型中的实体、表、列等进行规范化处理。使整个数据仓库的物理数据模型能够保持一致。规范化内容主要有：完整清晰的数据定义、合适的数据格式等。数据仓库中的每个组件或部件都确定相应的设计标准。

4.3数据仓库物理模型的存储

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

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

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

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

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

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

A公司销售事件存储结构关系模型，如表10所示。

表10 A公司销售事件存储结构关系模型

A公司商品关系存储结构关系模型，如表11所示。

表11 A公司商品关系存储结构关系模型

4.4物理模型评审内容

物理模型评审时，可以采用量化打分的方式，具体指标如表12所示。

序号	分类	总分数	模型打分	建议及问题描述
1	模型是否正确地捕获了需求？
2	模型的完整性如何？
3	模型与其模式的匹配情况如何？
4	模型的结构是否合理？
5	模型是否很好的利用了通用的结构？
6	模型是否很好的利用了命名规范？
7	模型是否具有可读性？
8	定义是否做得足够好？
9	元数据与数据匹配得如何？

表12 模型评分表

4.5数据仓库物理模型的优化

数据仓库物理模型进行优化时可以考虑以下解决方案：

合并表与簇文件（clustering file）：几个表的记录分散存放在几个物理块中时，多个表的存取和连接操作的代价会很大。

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

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

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

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

五数据仓库的粒度和聚集模型5.1数据仓库粒度模型

粒度是指数据仓库中数据单元的详细程度和级别。粒度可以分为两种形式：

第一种粒度是对数据仓库中的数据的综合程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问的种类。

还有一种粒度形式，即样本数据库，它根据给定的采样率从细节数据库中抽取出一个子集，这样样本数据库中的粒度就不是根据综合程度的不同来划分的，而是有采样率的高低来划分，采样粒度不同的样本数据库可以具有相同的数据综合程度。

确定粒度级别的步骤如下：

适当划分粒度的第一步是估算数据仓库中将来使用的数据行数和所需的直接存取存储设备数（DASD）。

在计算出数据仓库所需要占用的存储空间以后，需要根据所需要的存储空间大小确定是否划分粒度，如果需要划分，又应该怎样划分。可对每个表估算其一年所需要的存储空间，然后估算其最长的保留年数所需要的存储空间。每个表的存储空间，应该是每一个表的数据存储空间和索引存储空间之和。精确计算表的每年实际存储空间是很困难的，只能给出表的最大估算空间和最小估算空间。

在数据仓库中确定粒度时，需要考虑这样一些因素：要接受的分析类型、可接受的数据最低粒度、能够存储的数据量。

计划在数据仓库中进行的分析类型将直接影响数据仓库的粒度划分。将粒度的层次定义太高，就无法在该数据仓库中进行更细致的分析操作。

数据仓库通常在同一模式中使用多重粒度。如果存储资源有一定的限制，就只能采用较高粒度的数据粒度划分策略。

定义数据仓库粒度的另外一个要素是数据仓库可以使用多种存储介质的空间量。

选择合适的粒度是数据仓库设计过程中所要解决的一个复杂的问题，因为粒度的确定实质上是对业务决策分析、硬件、软件和数据仓库使用方法的一个折衷。

还有一种可以大幅降低数据仓库容量的方法，就是只采用概括数据。

数据粒度划分策略一定要保证数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的一个准则。

表13 常用的粒度策略的选择

5.2数据仓库聚集模型与数据分割

聚集数据主要是为了使用户获得更好的查询性能，聚集模型设计时应该注意将聚集数据存储在其事实表中，并与其底层数据相区别。设计聚集模型时，首先需要考虑用户的使用要求，其次要考虑数据仓库的粒度模型和数据的统计分布情况。

数据仓库的聚集模型的设计与数据仓库的粒度模型紧密相关。建立聚集模型时还需要考虑作为聚集属性的数量因素，聚集事实表已经独立存在并且可以与基本事实表一同保存，通过将当前加载数据添加到系统中的累积“桶”中，将数据的聚集与数据仓库的加载过程组合为同一处理过程，在将数据仓库数据加载以后，再进行聚集处理。每次在加载数据仓库数据时，都需要对各种聚集进行计算和增加，及时保持聚集与基本数据的同步性。同时，要根据使用情况删除不经常使用的聚集，需要减少层次过于接近的聚集生成，注意将聚集独立存储在自己的事实表中。

分割是数据仓库逻辑设计中要解决的另一个重要问题，它的目的同样在于提高效率，能为数据仓库的物理实施提供设计依据。数据分割是指把逻辑上整体的数据分割成较小的、可独立管理的物理单元进行存储的方法。数据分割又跟数据处理的对象紧密联系，不同主题内数据分割标准不同。数据分割目的在于数据容易重构、方便建立更加高效的索引，实施顺序扫描，容易对于数据重组与恢复，容易对数据进行监控。

选择适当的数据分割的标准，一般要考虑以下几方面因素：数据量〔而非记录行数)、数据分析处理的实际情况、简单易行以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素，如果数据量较小，可以不进行数据分割或只用单一标准进行数据分割，如果数据量大就要考虑采用多重标准的组合较为细致地分割数据。数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的。还要考虑到所选择的数据分割标准应是自然的、易于实施的。同时也要考虑数据分割的标准与粒度划分层次是适应的。确定数据分割策略包括：关系模式定义；记录系统定义。

有许多数据分割的标准可供参考：如日期、地域、业务领域等等，也可以是其组合。一般而言，分割标准总应包括日期项，它十分自然而且分割均匀。使用数据分割能够便于数据的重构、重组和恢复，以提高创建索引和顺序扫描的效率，还可有效支持数据概括。

六ETL设计6.11ETL设计原则

架构合理可行。应以最切实际而合理的架构搭建系统，并实现系统应具备的各类功能。

性能满足需求。在系统设计与实施中应充分考虑到系统运行的性能压力以及ETL各技术需求的满足。

接口清晰规范。系统间接口应明确、稳定、保证接口双方的松耦合，同时便于故障的定位和及时处理。

易于管理和可扩展，ETL过程是数据仓库建设的重要步骤之一，整个ETL过程应该易于操作、管理和控制，同时系统在数据量增加的情况下应具有良好的扩展性。

6.2ETL开发规范

1、ETL工作流程

在开始工作之前定义工作流程，让开发者理解：在ETL处理过程中，他们开发的部分在哪个地方被调用、为什么这个组成部分是必须的、各个组成部分之间的独立性。一个完整的工作流程必须在数据仓库设计、数据集市设计交付之前设计完毕，最大可能地去重用前后地处理过程。

工作流程必须遵守以下工作流程：

在主要地处理过程中，每个处理过程着重于填充目标系统的一个数据表。

前后的处理过程应保持一致性，例如，预处理、清除、一般的存储在前后的处理中每个独立的处理步骤应该被创建，尽量在EDW和数据集市里重用这些步骤。

主处理过程应该尽可能地重用。

在开始构件所有的处理过程之前，设计师必需完成工作流程模型的设计工作。

每个处理过程可能包含一个或多个步骤，同时处理一个目标表。开发者应该在他们的处理过程内遵照每步的设计文档。

为了完成处理过程的开发，开发者将使用工作流程和源系统和目标系统的映射关系和目标数据模型进行关联。

开发者将测试自己的处理过程、检验完整性，直到处理过程非常完善。

2、脚本开发规范

在具体的脚本开发时，需要制定并执行相应的开发规范，以便于提高数据平台管理效率，降低后期脚本维护成本，实现脚本标准化开发。下面列举一些比较常见的开发规范，仅供参考。

脚本中的注释、说明信息务必详细、准确。如脚本对应任务名称、目标表名称、创建人、创建时间、修改人、修改时间、修改内容等。

脚本中时间变量请务使用诸如sysdate(-1)的常量。定义而且只定义一个外部日期参数, 其他需要用到的日期都用日期函数进行转化。

脚本中请记录目标表ddl。

子查询不要超过三层，多层子查询会使脚本变得冗长、难以理解及维护。

同一段脚本中，同一份数据如果关联两次以上(包含两次)，请使用with。

写入目标表时，如果裁剪字段名称(最终select所选择的字段)与目标表的字段名不一致，请使用别名使其一致, 方便其它同事阅读和维护。

临时表禁止跨域使用，其使用范围仅限于当前脚本. 脚本中尽量不要使用临时表, 其最大的问题是不能多实例运行、不方便维护。

缩进：请务必使用平台格式化工具对代码格式化，保持代码风格统一，方便自己也方便其它同学阅读。

每个脚本必须附带小文件合并参数: merge_type='mr'

一个脚本中只允许存在一个目标表。

常量赋值请放在最外层。

6.3ETL任务调度策略

ETL调度策略是指数据仓库ETL任务的运行指导方针。例如调度周期、调度时间、触发方式、优先级顺序等等。ETL调度策略的制订直接影响数据仓库数据的时效性、用户访问数据仓库的响应速度、工作复杂度以及数据质量。因此，设计ETL调度策略是ETL的重要工作。

1、业务日期翻牌策略

业务日期翻牌是指：一个日期的数据加工处理完成后，应该启动进行下一个日期的数据加工的动作。翻牌是ETL的一个重要术语。

由于数据仓库基于日期进行数据历史加工的特点，数据服务层中的数据加工必须要逐日进行，不能多个日期的数据同时加工或者数据日期先后顺序颠倒加工。因此数据仓库的业务日期的翻牌是按照日期逐日进行的，但是数据抽取和临时区加载可以独立翻牌，与数据服务层的其他区域的翻牌分离，这样可以保证数据抽取和加载的独立性和及时性，能降低数据依赖，增强系统稳定性。因此业务日期的翻牌策略可以分为以下两部分：

源系统抽取、数据加载到临时区：独立翻牌，不依赖其他条件，也可以多个数据日期混合处理。

数据服务层的其他区域，例如明细区、汇总区、集市区，必须整体翻牌，一个业务日期处理完成后，再继续下一个日期的处理，日期不能混合处理与颠倒处理。

2、初始加载与日常加载策略

ETL加载从种类上分为初始加载和日常加载。

初始加载是指数据第一次加载到数据仓库，初始加载的特点是数据量大，加工算法较简单。初始加载需要做多种数据质量检查。在常规的数据仓库建设过程中，初始脚本需要单独编写。初始加载过程需要对ETL服务器空间、临时区空间做计算，给出足够的余量。

日常加载是指正常加载的工作，日常加载不一定是每天运行，有固定的加载频率或者是不定期执行，都叫做日常加载。日常加载的特点是数据量不如初始加载大，但是加工算法比初始加载复杂。数据仓库的主要加载都是日常加载。

3、数据修复与重跑调度策略

数据仓库处理的数据量大，系统复杂，如果ETL加工脚本出错，可能会造成数据仓库的数据不准确，因此，除了加强系统开发和测试工作外，提高系统的数据稳定性，支持数据修复和重跑是ETL的重要调度策略，支持数据修复与任务重跑有三类方案。

1）当天数据错误的重跑

数据服务层的基础数据区，数据库的表在物理模型设计过程中需要增加几个物理字段，其中2个字段是：数据日期、ETL任务，通过这两个字段，ETL任务可以很容易的删除当天加载的错误数据，因此当天数据有错误，ETL任务可以直接重跑。

2）一周内数据错误的重跑

如果在一周之内发现有非当天的数据出现了加工错误，可以直接手工删除数据后，手工重新调度一周内的任务，因为一周内的数据都还保存在临时数据区内，因此一周内的重跑也是可以直接在数据库级别完成。

3）超过一周的数据修复

超过一周的数据修复比较复杂，由于此时临时数据区的数据已经备份到其他介质上了，因此需要先行恢复数据，再进行ETL重跑，重跑的任务无法通过自动调度，必须手工进行调度。

4、特殊日期调度策略

特殊处理日期指的是月末、旬末、年末等日期，在这些日期里，由于有大量的脚本在此期间运行，数据量也会比平时大，对系统会造成一定的影响，比如：可能无法做到T+1供数，白天的业务查询会受到延迟的ETL任务的影响而变慢等等。因此可能需要考虑特殊的加载策略。

5、实时调度策略

ETL加载能够实现基于准实时的调度要求，例如：源系统希望部分应用表能够每5分钟进行一次数据抽取，此部分数据主要为业务交易数据，对于其他类型数据需要做特殊处理。

七数据仓库的应用、支持和增强7.1数据仓库的用户培训及支持

1、用户的培训

向用户解释清楚数据仓库的作用与原理。

用各种案例向用户说明如何使用数据仓库。

2、对数据仓库用户的支持

对数据仓库应用成功案例的推广。

初始阶段的支持。

技术人员、商业分析人员与用户一起讨论。

7.2数据仓库运维

1、对数据仓库的运维包括：

负责数据仓库的日常管理工作；

监控数据仓库运行情况；

优化数据仓库性能，充分利用数据仓库的计算和存储资源，满足EDW的应用需求。

2、主要工作内容：

运行监控：系统运行的性能、存储资源利用率、数据倾斜度等重要指标，检查日志文件；

空间的管理：空间分配、文件管理、加载/卸载磁盘；

日常操作：创建/删除数据文件、创建/删除数据库索引、数据库示例的启动/停止、数据备份/恢复；

特殊操作：创建和删除数据库、修改数据库/数据表结构，如：修改字段定义或增减字段等。

7.3ETL监控

数据仓库系统的维护中最重要的就是随时监控ETL任务的运行情况，因此为了降低系统维护人员的劳动强度，提供友好的ETL监控功能是必要的。

ETL日常运行监控的内容主要包含两个方面：

1、ETL任务异常监控

源系统数据就绪接口状态监控。

ETL任务运行状态监控，包括任务Failed,任务运行时间过长，任务依赖关系不满足，需要运行的任务没有被触发等。

ETL服务异常监控，包括ETL服务没有启动，ETL服务连接异常等。

2、数据仓库管理异常监控

数据分布不均匀。

加载的目标表时间过长。

CPU资源和分区空间不足。

数据库异常等。

7.4数据仓库使用中的数据刷新

从已有数据资源中获取更多数据

从单位内部获取新的数据源

获取新的或更多的行业数据源

7.5数据仓库的增强

元数据库的局限性

缺乏外部数据源数据仓库数据加载性能不能满足要求

数据仓库应用范围的扩大

数据仓库整体性能的调整

数据仓库重新规划

总结

本文采用理论和实践相结合的方式主要介绍数据仓库开发应用的特点、规划、开发和应用整个生命周期。重点介绍了数据仓库概念模型、逻辑模型、物理模型、粒度模型、聚集模型、ETL的构建过程。数据仓库的建模，首先要将现实的决策分析环境抽象成一个概念数据模型。然后将此概念模型逻辑化，建立逻辑数据模型。最后，将逻辑数据模型向数据仓库的物理模型转化，通过ETL完成数据的抽取和转换，实现最终的数据入仓存储。