张靖笙
信息技术应用的卓越成效在经过20多年的信息化建设进程中已经初步显现，信息技术广泛应用的同时带来了信息的泛滥，正如John Naisbett所说，“我们已被信息所淹没，但是却正在忍受缺乏知识的煎熬”。如何从大量的数据中快速有效的提取出我们需要的信息和知识也显得越来越重要，让我们不至于被信息海洋所淹没；如何有效利用多年信息系统积累下来的大量数据，从被深埋的历史数据中挖出财富；如何解决信息化建设过程中，由于历史的认识水平和技术条件的限制所造成的信息化各子系统的脱节，而直接导致的信息孤岛问题。以上这些都是我们当今政府和企业的信息系统迫切需要解决的问题。
“工欲善其事，必先利其器”，商业智能（BI，BusinessIntelligence）正是为了解决上述问题而应运而生的，商业智能本身是一个庞大的技术体系，也是一个还在发展中的概念，如何理解商业智能的内涵，业界有不同的观点，而本章从工程实践的角度，把商业智能看成实现“数据－>信息－>知识－>行动－>智慧”过程所用到的技术和方法，所以本章内容在组织安排上，体现了两种对商业智能的观点：
ü 一种观点把商业智能看成是一个过程，这是DWReview的观点，商业智能是帮助企业实现“数据－>信息－>知识”的过程，这是本文1.1-1.3节所描述的内容，力求读者对商业智能有一个技术视野以外的认识；
ü 另外一种观点是把商业智能看成一系列的技术和方法，这是代表了最早由Gartner Group于1996年提出商业智能定义的观点：商业智能为一类由数据仓库（或数据集市）、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的技术及其应用，这是本文1.4和其他几节所要描述的内容，具体描述各个相关技术点的知识。
这一节将从时代发展需要和现实需求的角度，对应用商业智能的深层原因进行探讨。
企业与政府机构的信息化建设从零开始到现在，大致经历了三个阶段（如图6－1）：第一阶段是部门级与基础信息化阶段，在这一阶段，机构内往往是一些需求最迫切的部门首先采用了信息技术，如财务系统，计算机辅助设计系统，电子数据交换系统等等，以电子化和处理自动化来取代低效繁杂的手工处理；第二阶段是企业级信息化阶段，这一阶段政府机构与企业往往已经拥有了几个分别建设的业务处理系统，机构期望从总体角度建设高度集中的、或互相联接的综合业务管理系统，如MIS，ERP，OA等等；第三是企业或政府机构的战略与决策信息化阶段，这时企业或政府机构往往已经建成了比较完整的业务处理系统，而企业和政府机构在对业务系统里面数据的综合利用主要面临着三大问题，分别是不同业务数据的共享与综合处理问题、历史数据的利用问题以及数据角度的事务处理与决策差异性问题，这三大问题也是满足企业或机构的领导者和决策者通过数据来做出正确判断和决策的障碍，因此建立专门面向各级领导与决策层的信息系统，实现企业或政府机构战略和决策的信息化，可以说是这一阶段的核心任务，图1表示了这三个发展阶段。
图1 企业信息化建设的三个阶段
可见，随着企业的发展所带来的对信息需求分别从广度和深度两个层面不断扩展，第一期阶段的发展瓶颈在于信息的空间局限性，第二阶段的发展瓶颈在于信息的时间局限性，可以说，企业信息化进程经过这三个发展阶段，企业的管理水平也从“基于数据”，发展为“基于信息”，进而上升为“基于知识”。显然，在竞争日益激烈的环境下，错误的决策对企业的打击是颠覆性的，一个企业只有达到“基于知识”的学习型组织的管理境界，才能不断成长，在市场上生存。
把企业形象地比喻一个人的话，第一阶段是针对手指的自动化，第二阶段是针对眼睛和耳朵的自动化，第三阶段是针对大脑的自动化。从图1的纵坐标我们也可以看到，信息化的价值以及由此给企业带来的实力也是获得提升的。
而第三阶段正是商业智能走上历史舞台并且成为主角的时代，也是企业求生存求发展不得不走向学习型组织管理方式的历史选择，促成商业智能产生和发展的根源，笔者认为，不单纯是技术的进步，当然不可否认，技术的进步创造了物质上的条件，然而从因果关系的角度来说，企业选择商业智能的根本原因，是市场竞争下求生存谋发展的必然。
商业智能的概念最早是Gartner Group于1996年提出来的。其实，商业智能所涉及的技术与应用，在Gartner Group命名之前就有，起初被称为领导信息系统（EIS，Executive Information System），在羽化成商业智能之前也称为决策支持系统（DSS, Decision Support System）。
从技术层面上讲，商业智能或数据仓库并不是什么新技术，它只是数据库技术、OLAP技术、数据采集和迁移技术、网络技术、GUI技术、查询&报表技术、统计学、人工智能、知识发现技术等理论和技术的综合运用，从这个意义上，把商业智能看成是一种体系结构应该比较恰当。关于体系结构与具体技术的关系，W.H.Inmon形象地比喻成新墨西哥州的一个城市圣达菲和砖块的关系，圣达菲这个体系结构由砖块和裸露的横梁构成，没有这些砖块就没有圣达菲的各种建筑，而砖块本身并不能构成圣达菲这个体系。
商业智能的核心内容是从许多来自企业不同的业务处理系统的数据中，提取出有用的数据，进行清理以保证数据的正确性，然后经过抽取（Extraction）、转换（Transformation）和装载（Load），即ETL过程，整合到一个企业级的中心数据仓库(DW, Data Warehousing)里，从而得到企业信息的一个全局视图，在此基础上利用合适的查询和分析工具、数据挖掘工具等对数据仓库里的数据进行分析和处理，形成信息，更进一步把规律性的信息提炼成知识，并且把对决策有帮助的信息和知识呈现给管理者，为管理者的决策提供支持。商业智能的这个基本过程如图2所示。
图2 商业智能的基本过程
数据仓库是商业智能的基础，商业智能的应用必须基于数据仓库技术，所以数据仓库的设计工作占一个商业智能项目的核心位置，所以在很多项目命名时，往往是把数据仓库和商业智能相提并论，要么把它们等同起来，有时这会给人一种很混淆的感觉，觉得BI,DW,BIDW是相同的概念，造成了很多初学者在认识上的误区。一般来说，上面所描述的是一个广义上的商业智能概念，在这个概念层面上，数据仓库是其中非常重要的组成部分，数据仓库从概念上更多地侧重在对企业各类信息的整合和存储工作，包括了数据的迁移，数据的组织和存储，数据的管理与维护这些我们平常称之为后台的基础性的数据准备工作，与之对应，侠义的商业智能概念则侧重在数据查询和报告、多维/联机数据分析、数据挖掘和数据可视化工具这些平常称之为前台的数据分析应用方面，其中数据挖掘是商业智能中比较高层次的一种应用。下图6－3表达了商业智能过程中对应使用的技术和方法。
图3 商业智能过程及其对应的技术和方法
商业智能系统的服务对象包括了企业或组织机构的决策人员、数据分析专家、中下级别经理和一般业务人员。而不同层次的用户对商业智能应用的需求有明显的差异。
l 高层决策者需要了解业务的总体情况和总的发展态势，他们可能使用系统提供的分析工具自己发现问题，但更主要的是利用分析结果进行决策，高层决策者需要通晓业务的具体状态和发展趋势，包括业务的状态和构成（机构构成、时间构成、产品构成、客户构成等等）以及对业务的发展趋势做出预测；
l 数据分析专家需要更加深入地从数据仓库的数据中发现问题、市场机会和风险，需要及时把发现的结果报告给高层决策者；
l 中下级经理和业务人员通常仅仅关心与各自工作相关的内容，他们或许对报表和固定的数据查询更为习惯。
图4描述了商业智能系统中各种用户角色对系统数据深度、广度、分析复杂性、对目标软件易用性，对软件的控制能力和客户化程度要求以及对业务整体和局部信息需求程度的要求。
图4 商业智能用户类型分析图
分析用户类型是系统功能设定、分布的依据。图中以色谱形式表示对信息服务深度的需求，从最浅显的数据查询到深度数据挖掘。八条坐标线表示用户对不同系统特性的需求。这些系统性能是：数据深度和广度、分析的复杂性、软件的易用性、灵活性和客户化程度，对业务的全局性和局部性信息的需求（战略、战术需求）。
商业智能的用户类型、角色、需求、分析方法对照如表1
表1商业智能用户对照表
用户类型 | 角色 | 需求 | 分析方法 |
中下级经理和业务人员 | 固定报表读者 | 需要阅读数据仓库定时或按条件产生的固定报表； | 固定查询、产生报表；
|
信息浏览者 | 根据不同的业务需求，通过建立简单的查询，进行分析，产生动态报表；
| 自助查询、动态报表 | |
高层决策者 | 管理（或称领导）信息系统用户 | 了解宏观业务状况,并能迅速定位到反映问题原因的微观细节； | 了解反映业务状况的关键性能指标(KPI),多维分析，穿透和钻取； |
数据分析专家 | 数据分析用户 | 根据不同的业务要求，建立自己的数据模型进行 随机查询； 通过多维分析，进行各种高级查询和报表； | 多维分析、趋势分析、对比分析、排名分析、意外分析、原因影响分析、假设分析（What if）; |
数据挖掘用户 | 根据现有的数据情况，动态构建或修改模型，进行预测分析、数据挖掘等深层次操作； | 统计分析（预测、假设检验等等）； 数据挖掘(估计、预测、分类、聚类分析等等) |
把商业智能系统工作的过程进行技术上的抽象，可以把商业智能的体系结构进行分层，如图5所示，根据数据的不同形态，整个体系被划分为四个大的层面，并根据数据的处理和应用过程再细分成七个环节，这些环节通过密切的协助完成商业智能的功能。
数据从数据源经过抽取(Extra，E)、转换（Transform，T）、装载（Load，L）过程加载到中央数据仓库, 再从数据仓库经过分类加工放到数据集市(DM, Data Market), 或者将数据集市中的数据进一步存放到多维数据库(MDD, Multi-dimension Database)，这都属于数据组织的问题，从中间层到终端用户或从多维数据库到终端用户可将其划归为前端应用实现的问题。而贯穿整个体系数据处理环节的，是系统的流程调度控制和元数据管理。
图5 商业智能解决方案体系结构图
数据源可以是企业日常运作积累下来的各类的业务数据，也可以是外部的数据。这些数据在存放方式，存放格式，存放地点上可能是多种多样的，这就要求了数据仓库的体系结构必须能处理这种多样性带来的种种问题，如访问多种技术平台下，多种类型的DBMS内的数据，并解决由于数据远程迁移所带来的完整性和安全性的问题。
数据抽取、转换和装载完成如下任务：从源数据抽取数据、进行一定的变换、装载到数据仓库。在上述过程中，需要进行如下数据处理：
简单变换：是数据变换最简单的形式，一次只针对一个字段，而不是考虑相关字段的值。主要有数据类型的转换、日期/时间的格式转换、字段解码等。
清洁和刷洗：目的是为了保证前后一致地格式化和使用某一字段或相关的字段群。清洁和刷洗是两个可以互换的术语，指的是比简单变换更为复杂的一种变换。在这种变换中，要检查的是字段和字段组中的实际内容而不仅是存储格式。一种检查是检查数据字段值的有效值，它指的是检验一个字段的有效值以保证它落在预期的范围之内，通常是数字范围和日期范围。数据刷洗的另一主要类型是重新格式化某些类型的数据，这种方法适用于可以用许多不同方式存储在不同数据来源中的信息，必须在数据仓库中把这类信息转换成一种统一的表示方式。
集成：要把从全然不同来源的数据结合在一起，真正的困难在于将其集成一个紧密结合的数据模型。这些数据来源往往遵守的不是同一套业务规则，在生成新数据时，必须考虑到这一差异。
聚集和概括：大多数数据仓库都要用到数据的某种聚集和概括。这通常有助于将某一实例的数目减少到易于驾驭的水平，也有助于预先计算出广泛的概括数字，以使每个查询不必计算它们。概括是指按照一个和几个业务维将相近的数值加在一起，聚集是将不同业务元素加在一起或为一个公共总数，在数据仓库中它们是以相同的方式进行的。
操作型数据存储区(ODS, Operational Data Store)是为了弥补业务系统和数据仓库之间的数据同步差距而提出的，要解决的是这种问题：“对一个特定的业务流程来说，我怎么才能提供最新的、跨功能部门之间的信息”，例如对客户服务人员，他需要销售、库存、市场和研发等各部门的最新数据，而这些数据原来是分散在不同部门的不同应用系统的。如果通过数据仓库来实现数据集成，则实时性难以保证，或者建设成本很高。
ODS是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据，与数据仓库类似，ODS也是面向主题的、集成的，但是其最大特点是数据是可更新的，甚至由业务系统通过触发器直接更新。因此，ODS是业务系统和DW之间更偏向业务系统的数据存储区域。
一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：
1、在业务系统和数据仓库之间形成一个隔离层。
一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。这种运用有时被称为数据准备区（Data Staging Area）。
2、转移一部分业务系统细节查询的功能
在数据仓库建立之前，大量的报表、分析是由业务系统的数据库直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
3、完成数据仓库中不能完成的一些功能。
一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。
在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上数据的内容也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。ODS可以和DW形成互补的整体，构成完整的战术决策支持系统架构。利用ODS＋DW实现战术决策支持有其非常直观的优势：利用ODS实现实时或者准实时的数据抽取，而且ODS的数据量不大，可以比较高效地进行数据的修改和更新，并且可以提高查询的效率。而利用数据仓库的海量存储实现历史数据的查询，实现战略决策支持。
但是，这种也有很明显的劣势：由于ODS和DW的结构和模型是不同的，这需要进行不同的系统和数据模型设计，也需要不同的系统维护过程，相应增加系统的使用成本。
数据仓库的一个目的就是把企业的信息访问基础从一种非结构化的或发展中的环境改变成一种结构化或规划良好的环境。关于数据仓库的详细描述留到后面的章节。
简单地把数据集市(DM，Data Market)理解成数据仓库的一部分是不对的，因为两者虽然在数据上有非常密切的联系，而定位上却是不同的，关于数据集市的详细描述留到后面的章节。
商业智能的前端应用是建立数据仓库的目的，没有前端应用数据仓库就失去了意义。另一方面，由于最终用户的要求多种多样，不可能用同一个界面满足所有用户的信息查询要求，必须根据用户的特点提供不同的界面。最终用户对数据仓库的数据的访问方式包括：即席查询、报表、联机分析处理(OLAP)、数据挖掘(DM, Data Mining)以及领导信息系统(EIS)等,用户可以通过浏览器或其它前端工具访问数据仓库的数据。
即席查询和报表
即席查询(Adhoc Query)和报表是商业智能系统提供给业务人员最基本的信息访问能力，满足他们日常报表和随时获取业务信息的需要。不同的业务人员，如销售、市场、财务等人员有着自己独特的分析要求，且这种要求需根据业务的需要不断变化。在传统的技术条件下，由于种种理由业务人员实质上是不能直接接触到存在计算机内的数据，如果业务人员需要对一段时间的业务汇总数据，往往只能提出要求，由IT人员编写相应的程序把数据库中的数据读出来生成报表，再通过批处理打印的方法将结果交给业务人员，这种方法已经日益不能满足业务人员对动态、及时及个性化信息的要求。同时，这种对IT人员过多的依赖消耗太多的IT资源，增加了管理和运作的成本。因此必须在IT与业务用户之间正确地划分权限，既能方便用户自助查询，又能保证IT的统一管理的即席查询和报表功能是商业智能系统必须具备的功能。
用户界面的友好性是一直以来商业智能的前端工具的一个着力点，用户可通过简单的鼠标点击、拖拉等操作就可以完成复杂的查询功能，可以在一个文档中包含来自多个数据源的数据，可以完成各种统计、排序、分组、计算工作，可以通过限制字段的值对结果进行过滤，可以通过高亮度显示突出特殊的结果集。而用传统的方式下，构造复杂的SQL查询语句，各种复杂的统计和处理，结果的输出这些都需要编写大量程序代码来实现，而报表用户任何轻微的改动会给IT技术人员带来的繁复的编程工作。
可以说引入这些为最终用户设计的数据查询和报表工具，一方面让最终用户真正拥有了自由查询自己需要信息的能力，另一方面，把信息的查询直接还给最终用户，IT人员就可以把更多的精力放在为满足大的方面业务需求的数据后台整合工作上，对于IT人员和业务人员来说双重的解放。
图6 著名的即席查询和报表工具BrioQuery 的查询请求界面
即席查询和报表工具是集成查询和报表的解决方案，具有易于使用和二次开发的特点。
OLAP分析，又称多维分析，管理人员往往希望从不同的角度观察数据来审视业务情况，比如从时间、地域、产品、客户等来看收入、利润、支出等业务统计数字。每一个分析的角度可以叫做一个维，因此，我们把多角度分析方式称为多维分析。以前，每一个分析的角度需要制作一张报表。多维分析工具的主要功能，是根据用户常用的多种分析角度，事先做好汇总和计算，以便在查询时能尽快访问到所要的汇总数字，并快速地从一个维度转变到另一维度继续观察数据。
图7 信贷分析模型
图7直观地表示了一个贷款分析模型所能实现的可能的分析角度(维度)和数据层次（粒度）:
图8 贷款分析的角度和层次
很明显，这个简单的分析模型已经包含了8╳8╳4╳4 = 1024 种不同角度不同层次对授信金额和贷款金额的统计分析，下面让我们看看一些多维分析的操作。
在多维数据结构中，按二维进行切片，按三维进行切块，可得到所需要的数据。如在“贷款银行、贷款质量、时间”三维立方体中进行切块和切片，可得到各贷款银行、各种贷款的统计情况。每次都是沿其中一维进行分割称为分片，每次沿多维进行的分片称为分块。
图9 切片一 2004年4月份所有贷款情况
图10 切片二所有不良贷款情况
钻取包含向下钻取(Drill-down)和向上钻取(Drill-up)/上卷(Roll-up)操作， 钻取的深度与维所划分的层次相对应。
图11 钻取示意图
通过旋转可以得到不同视角的数据
图12 旋转示意图
从上面的多维操作，我们可以看到通过对数据观察角度的变换，可以更容易全面而深入地了解到一些关于为什么的信息。
领导信息系统(EIS，Executive Information System)
EIS（领导信息系统），是针对管理人员的需要，整合上述各种功能控制的前端应用。通过EIS，将管理人员所需的决策信息按需集成到统一的界面中，帮助他们能够快速、直接地访问信息。与其他信息查询方式相比，EIS更强调与用户的交互能力，除了以多种形式展示数据内容外，EIS还可以以下拉列表、按钮、选项、图标等多种屏幕控件响应用户的操作，并能通过对界面的美工增强对用户的亲和力。
图13 信贷分析的EIS示例
从上面一节的描述中我们已经知道，数据仓库的设计是商业智能应用中十分重要的一环，数据仓库是商业智能应用最基本的环境，OLAP分析，报表和查询，数据挖掘等商业智能应用都需要数据仓库作为共同的基础。
数据仓库来源于数据库，其本身也是由数据库管理系统来管理的，但是它的结构、功能和设计都和传统的数据库设计方法不同，本节将会对数据仓库技术的知识和设计方法进行深入学习，探究创建数据仓库的理论和方法。
传统的企业信息化实现的是用计算机信息处理代替人工信息处理，主要解决的是业务上的数据流问题。让我们来看一个简单的例子。在银行中, 一般都有存款、贷款、信用卡、代理业务等多种业务系统, 它们都是支持相关业务处理而设计的交易处理系统, 系统主要任务是完成日常业务交易过程中的数据处理，这种操作型系统的使用人员通常是企业的具体操作人员，处理的数据通常也是企业业务中的细节信息，譬如具体的一笔业务。
针对操作型数据处理的联机业务处理(OLTP)系统,我们总是按照业务应用来建立它的数据模型,换言之, 业务处理系统是面向操作应用来设计的，联机业务处理系统更是面向交易来设计，存储操作型数据的数据库在设计的时候主要是围绕性能和完整性方面，而每个交易涉及的数据往往只是记录的层面，数据库设计主要考虑对并行更新的支持比较多，并不需要考虑为全局查询做优化。另外，企业针对不同业务往往可能有多个操作型的系统，这些系统开发的时候都是独立进行的，相互之间没有什么数据联系,各系统之间对实际业务中相同的信息在数据上是冗余，而在不同的系统表达方式和数据内容上很可能不一致，甚至项目矛盾。比如每个系统中都会有存放客户部分信息的数据, 信息分布的零碎和冗余，使决策者很难从这些业务系统中直接地获取全面的信息。
分析型系统的使用人员通常是企业的中高层的管理者，或者是从事数据分析的分析师，他们关注的更多是企业宏观的信息而非具体的细节，其使用数据的目的是为企业的决策者做决策提供支持。分析型系统直接在操作型系统中提取数据会遇到下面很多问题。
其一是操作型数据之间往往需要复杂的关系来保持快捷性、一致性和实时性，要将其直接用于分析，需要创建很复杂的特殊查询语句，这项工作的技术复杂度明显不符合数据分析的用户群的需要；
其二是在事务处理系统中进行数据分析，由于短时间需要查询大量的数据，一方面会明显影响事务处理系统的处理速度和性能，另一方面也会由于响应时间过慢而影响分析的效率；
其三是在进行预测、决策时需要大量全面、正确的集成数据，所有这些集成数据不仅包括企业内部的数据，还包括企业外部的数据，如行业信息、竞争对手信息等。而操作型数据仅仅保存与本业务相关的信息，缺少与决策相关的集成数据尤其是企业外部数据。
其四是历史数据问题。供决策分析的数据一般是历史数据，而操作型数据库一般只保留当前或近期的数据信息。
以上诸多问题的存在，导致企业或其他组织机构无法直接使用现有的业务系统中存储操作型数据的传统数据库系统以满足预测、决策分析的需要。因此，预测、决策分析需要一个能够不受传统事务处理的约束，高效率处理决策分析数据的支持环境，数据仓库就是满足分析型系统要求的数据存储和数据组织环境。
功能决定结构，承接上一节的讨论，我们知道OLAP系统和OLTP系统从本质上是不同的，数据仓库虽然是从传统数据库系统发展而来，但是两者还是存在着诸多差异，如：从数据存储的内容看，数据库只存放当前值，而数据仓库则存放历史值；数据仓库数据的目标是面向业务操作人员的，为业务处理人员提供数据处理的支持，而数据仓库则是面向中高层管理人员的，为其提供决策支持。表6-2详细说明了数据仓库与传统数据库的区别。
表2 数据仓库与传统数据库的比较
比较项目 | 数据库 | 数据仓库 |
数据内容 | 当前值 | 历史的、归档的、归纳的、计算的数据（处理过的） |
数据目标 | 面向业务操作程序、重复操作 | 面向主体域，分析应用 |
数据特性 | 动态变化、更新 | 静态、不能直接更新，只能定时添加、更新 |
数据结构 | 高度结构化、复杂，适合操作计算 | 简单、适合分析 |
使用频率 | 高 | 低 |
数据访问量 | 每个事务一般只访问少量记录 | 每个事务一般访问大量记录 |
对响应时间的要求 | 计时单位小，如秒 | 计时单位相对较大，除了秒，还有分钟、小时 |
数据仓库的特点可以从数据仓库的定义来理解，目前，数据仓库一词尚没有一个统一的定义，著名的数据仓库专家W.H.Inmon在其著作《Building the Data Warehouse》一书中给予如下描述：“数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、非易失的（Non-Volatile）、且随时间变化的（Time Variant）的数据集合，用于支持管理决策。”他指出了数据仓库4个最重要的特征。
1） 面向主题的（Subject Oriented）：操作型数据库的数据组织面向事务处理任务（面向应用），各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型系统的数据相关。例如，一个银行的事务处理（应用问题）包括存款业务、信用卡业务、贷款业务和代理业务等，而银行的主要主题范围是客户、产品和渠道等。
图14 数据仓库面向主题的特性
2） 集成的（Integrated）：在数据仓库的所有特性中，这是最重要的。面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。下例说明当数据由面向事务处理的操作型数据向数据仓库传送时所进行的集成。有四个不同的应用系统，系统中对人的性别的标识分别为：
表3 示例
| 男性 | 女性 |
系统A | 男 | 女 |
系统B | M | f |
系统C | 1 | 0 |
系统D | M | F |
那么，在将四个系统的性别信息向数据仓库导入时就涉及到集成问题，例如，可以统一将性别信息表示为m，f。
3） 非易失的（Non-Volatile）：操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
图15 数据仓库的相对稳定性、非易失性
图15说明了操作型数据环境下，是正规地一次访问和处理一个记录，可以对数据进行修改和更新。但数据仓库中的数据却表现出不同的特性：数据通常是被一起载入和访问的，而且在数据仓库环境中并不进行一般意义上的数据更新操作。
4） 时变的（Time-Variant）：反映历史变化或者说是随着历史变化。操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库的反映历史变化的属性主要表现在：
1） 数据仓库中的数据时间期限要远远长于传统操作型数据系统中的数据时间期限，传统操作型数据系统中的数据时间期限可能未为数十天或数个月，数据仓库中的数据时间期限往往为数年甚至几十年；
2） 传统操作型数据系统中的数据含有“当前值”的数据，这些数据在访问时是有效的，当然数据的当前值也能被更新，但数据仓库中的数据仅仅是一系列某一时刻（可能是传统操作型数据系统）生成的复杂的快照；
3） 传统操作型数据系统中可能包含也可能不包含时间元素，如年、月、日、时、分、秒等，而数据仓库中一定会包含时间元素。
目前数据库技术中主流的关系数据库是采用二维表的形式来表示数据，在设计上使用关系模型理论来建模，建模方法是第三范式(3NF, 即 Third Normal Form)，3NF是关系数据库设计的基础理论，按3NF设计的数据库存放业务处理的数据是合适的，同时也体现了操作型数据的信息局部性，如果直接在上面做分析操作，必然需要由很多个表做连接操作才能得到需要的相对完整的信息。
而数据仓库的结构是要面向多维分析的，并且是按面向主题的方式来组织，星型模式体现的是多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。事实表的非主键属性称为度量值（Measure）或者事实 (Fact),它们一般都是数值或其他可以进行计算的数据; 而维大都是文字、时间等类型的数据，按这种方式组织好数据我们就可以按照不同的维(事实表的主键的部分或全部)来对这些度量值数据进行求和(summary)、求平均(average)、计数(count)、百分比(percent)的聚集计算，这样就可以从不同的角度观察反映所分析的业务状况的数据，下面给出一个针对银行贷款业务状况的分析模型的例子。
图16 例子:贷款分析星型模型
图16是银行贷款分析的模型设计，其中加边框的为主关键字(PK, Primary Key)，其中贷款分析表是一个事实表，其中的贷款授信金额，贷款金额（发生额）是需要从各角度观察的数据(度量值)，而对这两个数据的观察的角度可以有区域、银行、时间，质量这四个方面组合进行，通过这些分析角度的组合，可以对授信金额和贷款余额进行4 ╳ 8 ╳ 4 ╳ 8种不同角度的数据统计，以此可以对贷款情况的从多个角度(维)不次(数据不同的汇总程度)进行分析和观察，贷款分析人员既可以宏观地看到贷款业务的整体情况，又可以微观地观察到具体某一家银行某一天某一类贷款情况。进行多维分析的时候，维度选择越多数据越细节(划分得更细了)，维度选择越少数据越汇总越宏观。
这个模型中，一个中间一个细长的大表（事实表，记录数很多，字段数目却不多）形成主表，周围一组小表（维表，记录数很少）与主表相关联的结构，形态上如图17所示呈星星的形状，所以被命名为星型结构，星型模型是数据仓库的数据模型与传统关系数据库应用相区分的一个重要特征。
图17 数据仓库典型的逻辑模型形状
星型模型虽然也是一个关系模型，但是它不是一个规范化的模型，在星型模型中，维度表被故意非规范化了，使用星型模式主要有两方面原因：
提高查询效率：同一个主题的主要的数据都存放在庞大的事实表中，只要扫描事实表就可以进行查询，而不必把多个表联接起来；
便于用户理解：星型模式比较直观，通过星型模式，很容易组合出各种查询。
雪花模型是对星型模型的一个扩展，每一个维表还可以向外面连接多个详细类别表。例如上面的贷款银行维表可以再扩展一个银行级别类表，而形成一个雪花型的结构。而由于数据仓库不必要考虑满足第三范式，也不必要考虑避免冗余，可以考虑把详细类别表的字段合并入维表里面，由此可见，在星型模式的基础上拓展而成的雪花型模型，实际上是对分析查询性能和数据仓库容量两方面的平衡。
图18 雪花模型示意图
一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就出现多个事实表共享一个或者多个维表的情况，这就形成了星座模式，例如我们可以复用以上贷款分型模型的维表到存款分析模型中，如图19, 公共维表设计在数据仓库项目中有普遍意义。
图19 例子:存、贷款分析星座模型
2.5数据集市
简单地把数据集市(DM，Data Market)理解成数据仓库的一部分是不对的，因为两者虽然在数据上有非常密切的联系，而定位上却是不同的。数据仓库所对应的是整个企业的层面的整体信息视图，体现决策信息在企业的共性需求。而对于企业内同一个业务概念，由于业务观点的不同导致大家对数据的理解和运用有不同的视角，缺乏针对性的单一个模型并不能都满足这种不同观点的数据需求。例如客户是现在企业非常重要的一个信息主题，而从产品经理的角度，可能关心的是客户的消费喜好和消费行为，而从财务经理的角度，更多地可能是关心客户的成本和带来的收益，这些不同的数据的使用观点需要不同的数据模型来满足，一般而言，数据仓库可以理解为企业决策信息平台提供总数据支持的，数据集市可以理解为部门范围级别的决策支持应用而设计的，其数据模型设计和数据组织上更多地服务于一个部门的信息需求。
结合数据集市的数据来源，数据集市有两种，独立的数据集市（Independent Data Mart）和从属的数据集市（DependentData Mart）。如图20所示：
图20 数据集市类型
从属数据集市的数据直接来自于中央数据仓库，这样有利于保持数据的一致性，因为来自同一数据源并且已经经过一致性处理和检验。从属数据集市的作用在于，为一些部门建立数据集市，将需要的数据复制、加工到其中，这样不仅可以提高该部门的访问速度，同时也为能满足该部门的一些特殊的分析需求。
独立数据集市的数据直接来自于业务系统，由于为各个部门都建立了各自的数据集市，而当需要从整体上建立一个数据仓库时，不同数据集市中的数据表达由于各部门的不同特殊需要而有所不同，将这种不一致的数据整合到一个中心数据仓库时，可能会遇到一些困难，比如重新设计、各部门协调等。其优点是建立迅速、价格相对低廉。因此建立独立数据集市往往是由于投资方面的考虑或工期的紧迫，或解决某部门的迫切需要。然而需要注意的是，在设计其它部门的数据集市或中心数据仓库时，要充分考虑现有数据集市的设计，以避免设计的不一致性而造成后期整合的困难及昂贵的费用。
表4 从属数据集市与独立数据集市对比表
对比 | 优点 | 缺点 |
从属数据集市 | 保证数据一致性； 架构比较理想，可扩展能力强 | 依赖与中心数据仓库的实施； 实施周期长； 实施成本高； |
独立数据集市 | 实施周期短； 实施成本低； | 没有消除信息分割； 可扩展能力弱； 后期整合困难。 |
粒度
粒度是数据仓库的重要概念。粒度可以分为两种形式，第一种粒度是对数据仓库中的数据的汇总程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问信息的种类。在数据仓库中，多维粒度是必不可少的。由于数据仓库的主要作用是多维分析，因而绝大多数查询都基于一定程度的汇总数据之上的，只有极少数查询涉及到细节。
还有一种粒度形式，即样本数据库。它根据给定的采样率从细节数据库中抽取出一个子集。这样样本数据库中的粒度就不是根据汇总程度的不同来划分的，而是有采样率的高低来划分，采样粒度不同的样本数据库可以具有相同的数据汇总程度。
聚合
事实表中存放的度量值，根据其实际意义可以分成是可加性的度量值和非可加性的度量值。可加性的度量值指将同一个事实表里面的不同记录的该数值相加得到的结果还有具体意义，譬如上面例子中的贷款金额，将一个季度的3个月的数字相加可以得到季度的数据，1年12个月的数字相加可以得到年度的数据。
由于事实表一般记录数都非常多，而且会随着时间数据越积累越多，用户直接在上面做汇总计算来观察一些度量值的时候，可能需要等很长时间才能得到汇总计算的结果。所以在确定了数据的粒度后，为了提高数据仓库的使用性能，可以根据用户的要求，可以按照维度的不同组合来设计聚合模型，从而在事实表的基础上再设置一些聚合表，存储一些在事实表的基础上预先汇总好的聚合数据，让用户获得更好的查询性能。
分割
分割是数据仓库中的数据存储中的另外一个重要概念,它的目的在于提高效率。它是将数据分散到各自的物理单元中去, 以便能分别独立处理，以实现查询操作的并行。有许多数据分割的标准可供参考:如时间、地域、业务领域等等,也可以是其组合。一般而言,分割标准总应包括一些能让它十分自然而且分割均匀的项目，例如时间项。
往往一个数据仓库需要包容和整合成千上万的信息内容，内容的多样性使数据仓库的数据结构显得异常的庞大很复杂，因此，要简单地用一种不需要言传的方式来描述一个数据仓库的内容和结构是不可能的事情，因而在从开发到运行维护的整个数据仓库生命周期中，如何描述数据仓库里面有的东西成了一件非常重要的事情。
元数据(Meta-data)通常定义为“关于数据的数据”，是描述和管理数据仓库自身内容对象、用来表示数据项的意义及其在系统各组成部件之间的关系的数据。实际上，数据仓库所提供的“统一的企业级的信息视图”能力，主要就是靠元数据来体现，如果把建设数据仓库比喻成搭建房子，元数据就是房子的“图纸”。是从广义上来讲，用元数据来描述数据仓库对象的任何东西——无论是一个表、一个列、一个查询、一个商业规则，或者是数据仓库内部的数据转移。它在数据源的抽取、数据加工、访问与使用等过程中都会存在。实现元数据管理的主要目标就是使企业内部元数据的定义标准化。数据仓库的维护工具可以根据元数据的“指示”完成数据的抽取、清洗和转换，并做适度的汇总，数据仓库的元数据包括：
（1）数据资源：包括各个数据源的模型，描述源数据表字段属性及业务含义，源数据到数据仓库的映射关系；
（2）数据组织：数据仓库、数据集市表的结构、属性及业务含义，多维结构等等；
（3）数据应用：查询与报表输出格式描述、OLAP、数据挖掘等的数据模型的信息展现、商业术语；
（4）数据管理：这里包括数据仓库过程以及数据仓库操作结果的模型，包括描述数据抽取和清洗规则、数据加载控制、临时表结构、用途和使用情况、数据汇总控制。
元数据贯穿整个数据仓库项目，所有数据处理环节必须最大化的参照元数据，这样才能保证数据仓库项目不会因为不断增长的数据多样性而失去秩序，特别是现行应用的异构性与分布性越来越普遍的情况下，统一的元数据就愈发重要了。“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括，而合理的元数据则会有效的描绘出信息的关联性，从而大大降低了数据仓库后期的维护和运行成本。
按照元数据的使用情况和面向对象的不同，可以将元数据分为业务元数据、技术元数据、操作元数据。
业务元数据用业务名称、定义、描述和别名来表示数据仓库和业务系统中的各种属性，直接供最终用户使用。业务元数据使最终用户能够更好理解、使用数据仓库，成为最终用户在数据仓库中的业务信息地图。
业务元数据在系统的数据仓库中的体现是全方位的，例如，最终用户通过浏览元数据可以清晰地了解当前指标代表什么业务、如何计算得出的、以什么为单位等相关描述信息。
技术元数据描述了源系统、数据转换、抽取过程、工作流、加载策略以及目标数据库的定义等。技术元数据可供信息系统人员和一部分最终用户使用，用来进行影响分析、变化管理、数据库优化、任务调度和安全管理等。
OLTP业务系统和数据仓库OLAP分析系统之间存在复杂、多方面的区别，因此，数据在业务系统和分析系统之间的处理、加载也是复杂和涉及多方面的。技术元数据对数据在两个系统间处理、加载的规则、过程、相关策略进行了描述。
操作元数据描述了目标表中的信息，如粒度、创建目标表和索引的信息、刷新时间、记录数、按时执行任务的设置以及有权访问数据的用户。操作元数据用于数据仓库的维护和分布。
虽然元数据依据具体应用特点分为业务元数据、技术元数据和操作元数据，但是，在实际应用中以上三类元数据是相互参照和关联的。只有业务、技术、操作之间的协调和互补才能充分发挥数据仓库的潜能，提高数据仓库的利用效率。
4、元数据标准CWM
OMG于2001年颁布元数据标准CWM 1.0（CommonWarehouse Metamodel Version 1.0）。CWM定义一个描述数据源、数据目的、转换、分析的元数据框架，以及定义建立和管理数据仓库的过程和操作，提供使用信息的继承。
目前宣布支持CWM的厂商包括：IBM、Oracle、Hyperion、DimensionEDI、Genesis IONA、HP、NCR和Unisys等。
CWM基于3个工业标准：
（1）UML - Unified Modeling Language，OMG建模标准；
（2）MOF - Meta Object Facility，OMG建立元模型和模型库的标准，提供在异构环境下的数据交换的接口；
（3）XMI - XML Metadata Interchange，OMG元数据交换标准。
数据仓库是以商业智能应用为目的而设计的，所以从广义的数据仓库设计应该包括数据仓库中的数据模型设计和在其上面的数据分析应用设计2个方面，数据仓库的应用和数据仓库的设计一脉相承，共同构成整个数据仓库系统的生命周期，这个周期包括3个阶段：数据仓库规划阶段，数据仓库设计实施阶段，数据仓库使用维护阶段。
正如1.2节描述的商业智能是一个过程，这3个阶段也构成了一个不断循环、完善和提高的过程，一般情况下数据仓库不可能在一个循环过程中完成，而是需要多次循环开发，每次循环会为系统增加新的功能，使数据仓库的应用得到新的提高。
图21 数据仓库的生命周期
微观上的数据仓库设计实际上是指数据仓库的数据模型设计，这个层面的主要任务是数据建模，确定数据仓库中数据的内容及其构成关系。和数据库的设计一样，数据仓库的设计也是在概念模型、逻辑模型和物理模型的依次转换过程中实现，而作为建设数据仓库的“图纸”，元数据模型则自始至终伴随着数据仓库的开发、实施和使用。
图22 数据仓库数据模型设计的步骤
总体来说，创建数据仓库的方式，一般而言，有三种方式：
1. 自上而下。把数据仓库定义为一个大系统，“全局考虑，全面实施”，建立适合企业信息共性需求的完整的数据模型，然后从业务运营系统中提取数据，进行数据的清洗、合并、规范化和合理化，并加载到数据仓库中，形成企业统一的数据集成平台，最后可以根据部门个性需要将数据仓库的数据分发到面向主题的数据集市中。
自上而下开发方法的优点包括
◆ 企业统一的数据集成平台；
◆ 集中化的控制管理；
◆ 数据容易分发到各个数据集市中；
自上而下开发方法的缺点包括
◆ 开发过程复杂，费用高；
◆ 开发时间长，难以满足快速变化的业务需求；
◆ 需要进行大量的业务需求分析，需要大量的资源；
◆ 结构比较僵化，比较难以扩展；
2. 自下而上。大量的旧系统，要想在短时间内进行数据的合理性和完整性统一是相当困难的，而市场变化和企业决策规则变化不允许花大量的时间和精力去建立一个满足日后需求，但不满足现在变化的系统。自下而上的开发方法就是根据特定的业务主题，“分部门考虑，分部门实施”，可以在很短的时间内实现部门级的数据集市，多个数据集市组成企业联邦制的数据仓库。
自下而上开发方法的优点包括：
◆ 可以并行开发；
◆ 见效快；
◆ 分散化的资源和管理控制；
自下而上开发方法的缺点包括：
◆ 很难协调各个数据集市的建设；
◆ 可能存在着部门之间的政治斗争和数据集市归属问题；
◆ 如果采用不同的技术建立起来的数据集市，最终造成多个相互独立、互不兼容的“烟囱式”数据集市，给维护和数据共享带来很大的障碍；
◆ 多种数据源采集系统，可能造成对业务系统的冲击和数据的不一致；
3. 元数据驱动的实施方法。元数据驱动、螺旋上升的数据仓库建立的过程就是“建立元数据――构造数据仓库/集市”的不断循环、不断上升的过程，如图23所示。
图23 不断循环、螺旋上升的元数据驱动方法
元数据驱动的数据仓库开发过程可以细分为以下阶段：
1) 建立元数据
a. 根据业务数据源，外部数据源定义元数据；
b. 添加和更新维护元数据的内容和属性；
c. 定义元数据使用规则；
d. 声明元数据联合使用的规则；
2) 构造数据仓库/集市
e. 基于元数据进行数据抽取/清洗/转换/聚合/加载/分布；
f. 基于元数据进行前端应用界面定制。
从另外一个层面来说，第1)步中构造和维护元数据信息可以看作虚拟地构造商业智能平台的过程，能否在第2)步实现这种虚拟的构造过程和实际的构造过程的有机结合，是落实元数据驱动的关键。
图24 以元数据为中心的开发方法
这种开发方式优点是显而易见的，包括：
u 建立企业数据的统一视图；
u 有统一的元数据管理；
u 具有灵活可扩展的体系结构；
u 分步式开发，螺旋式上升，既能快速看到效果，又保证系统的连续性、一致性。
这种开发方式的主要缺点就是如何真正实现这种方式，提取和维护元数据并不是一件很难的事情，而在实际的实施过程中，如何真正地实现元数据的驱动则不是一件容易的事情，由于传统程序开发思想的影响，很多开发者对需求问题的解决更多地依赖于程序设计，这样使得很多控制逻辑很难被抽象出来，因此也难于把数据的处理过程标准化、规范化，这种以程序驱动的方式很容易把所谓的元数据驱动流于形式。
[1] 李艳. 商业智能是一种解决方案.中国计算机用户. 2003.11.03
[2] 九城信息智能平台白皮书. 九城集团BI事业部. 2002.11
[3] Gartner ArticleMRR-0798-17, 1 July 1998, Kevin Strange, “Data Warehouse Data Model: Neutralityis the Key”
[4] Eric Sperley著.企业数据仓库规划、建立与实现. 陈武, 袁国忠译.人民邮电出版社，2000年8月第1版
[5] OLAP技术应用研究，https://www.dwway.com/document.php?id=682
[6] 朱德利.SQL Server 2005数据挖掘与商业智能完全解决方案，电子工业出版社.2007.10
[7] IBM商业智能解决方案综述.IBM公司.2004
[8] （法/美）伯纳德·利奥陶德，（美）马克·哈蒙德著.商务智能:把知识转化为价值. 郑晓舟，胡睿译. 2002
[9] (美)W.H.Inmon著.建设数据仓库.王志海,林友芳译.机械工业出版社.2003年3月
[10] 本人.用需求来创造价值-----论数据仓库与商业智能需求与需求分析，2006中国软件工程大会暨系统分析员年会演讲稿，2006
浙公网安备 33010802003509号
