一、简介
数据仓库(Data Warehouse,DW)由两个主要部分构成:首先是一个整合的决策支持数据库,其次是用于收集、清洗、转换、存储来自于各种操作型数据源和外部数据源数据的相关软件程序。两者结合以支持历史的、分析的和商务智能(Business Intelligence,BI)的需求。一个数据仓库也可能包括若干相关的数据集市,它们都是数据仓库数据库的子集副本。从广义上说,用于为商务智能提供数据支持的任何数据抽取或者数据存储均可称为数据仓库。
企业数据仓库(Enterprise Data Warehouse,EDW)是服务于整个组织商务智能需要的集中式数据仓库。企业数据仓库遵循企业数据模型,使得整个企业范围内的决策支持活动可以保持一致。
术语数据仓库活动(Data Warehousing,DW)用于描述为维护数据仓库中的数据而进行抽取,清洗、转换和加载等操作性的处理过程及相关控制的过程。数据仓库活动专注于实现一个历史的业务上下文,做到这一点要对操作型数据应用业务规则并维护相应的业务数据关系。数据仓库活动也包括与元数据存储库交互的流程。
数据仓库活动提供技术解决方案以支持商务智能。“商务智能”是多种业务能力的集合。它包含了很多方面,具体包括:
(1)知识工作者执行查询、分析和报表的活动,用于监控和了解企业财务运营情况,支持决策制定。
(2)查询、分析和报表相关的流程和规程。
(3)商务智能环境的代名词。
(4)商务智能软件工具的细分市场。
(5)基于企业操作型数据的战略/运营分析和报表,从而支持业务决策、风险管理、合规管理。
(6)决策支持系统(Decision Support System, DSS)的同义词。
数据仓库和商务智能管理是以业务分析和决策制定为目的,为知识工作者收集、整合和展现数据的活动。DW-BIM由支撑决策支持生命周期各阶段活动组成,包括提供相关背景,把数据从源移动/转换到通用目标数据存储区,为知识工作者提供整合后多样的目标数据访问、操作、报表等。
图9.1概括了数据仓库和商务智能管理的关联环境。
数据仓库和商务智能管理的目标包括:
• 对所需的当前和历史数据提供整合后的数据存储,并按照主题域组织数据。
• 为所有合适的访问形式提供可信的、高质量的数据。
• 为数据获取、数据管理和数据访问提供稳定、高效、可靠的环境。
• 提供易于使用的、灵活的和全面的数据访问环境。
• 在内容和内容访问方面,与组织目标相适应,以增量方式交付。
• 要借助其他相关的数据管理职能,如参考数据和主数据管理、数据治理、数据质量管理和元数据管理等,而不重复建设这些职能。
• 交付数据时,关注如何支持数据治理所发起的决策、政策、流程、定义以及标准等。
• 定义、构建并维护所有数据存储、数据处理过程,数据基础设施和数据工具。在交易系统输出后经过整合和精细化处理的数据可以用于信息查看、分析或者满足数据请求。
• 整合商务智能处理过程所发现的新数据到数据仓库,使其为进一步分析和商务智能所用。
二、概念和活动
本节的目的是提供数据仓库和商务智能管理的基础概念和定义,以便于随后深入了解相关的活动细节。本节简要回顾了该职能的历史,概述了典型的构成;随后解释了常用的数据仓库和商务智能管理术语,并简要介绍和概述了维度建模及其相关术语,并由此引出图9.1所识别的活动。
2.1 数据仓库活动--简要的历史回顾
不论以多长的篇幅来讨论数据仓库活动,有两个人名都肯定会出现:Bill Inmon和Ralph Kimball。他们二人在推动数据仓库实践方面做出了巨大贡献。这里简单介绍他们的主要贡献,并对他们的方法进行一些比较和对照。
2.1.1 数据仓库典型特征--Inmon版本
早在20世纪90年代初期,Bill Inmon将数据仓库定义为“面向主题的、整合的、随时间变化的,相对稳定的历史数据的集合。该集合包括汇总的和详细的历史数据,以用于支持企业战略决策制定。”
这些关键特征明确地区分了数据仓库数据和典型的业务系统数据,如实地反映了数据仓库的特性。
• 面向主题的—-数据仓库的面向主题特性是指数据仓库中的数据按照公司的主要实体进行组织。数据仓库既不面向功能也不面向应用。设计数据仓库是为了满足整个公司的数据需要,而不是为了满足某个部门的特定分析需求。
• 整合的─一整合的特性是指数据仓库中存储的数据具有统一性和内聚性,且覆盖了很多方面,包括键的结构、结构的编码和解码,数据的定义、命名习惯等。整合还隐含着为数据仓库范围内所有的数据建立记录系统(System of Record)。建立数据仓库不仅仅是将操作型环境中的数据复制到数据仓库中。如果仅仅是简单地将多个数据源中的数据整合到单一的数据源中,只能形成一个堆放数据的仓库而不是一个数据仓库。
• 随时间变化的——数据仓库随时间变化的特性是指数据仓库中的每一条数据在某个时间点是准确的,并常常在其键结构中体现时间元素。如此,可以将数据仓库想象为数据快照的历史记录,而在每一个快照所对应的时间点上记录是准确的。
• 相对稳定的——数据仓库的相对稳定是指不会在正常的处理过程中对记录进行更新，如果确实需要更新,也仅仅是特例。现有的操作型数据与数据仓库中深层次的,详细的历史数据之间的融合挑战着数据仓库的相对稳定的特性。这种融合对于支持战术和战略决策制定的过程是必须。9.2.4.节第1部分将会谈及这个趋势和影响。
• 汇总和详细数据——数据仓库中的数据必须包括汇总数据和详细数据,而详细数据是指企业业务系统中的最细粒度的数据。注意:早些时候,数据汇总是出于成本和存储空间方面的考虑,而今天,则是出于性能方面的考虑。
• 历史的—相对于操作型系统关注于当前的数据,数据仓库的显著特征就是包含了大量的历史数据(典型的有5～10年的数据)。这些数据的一-个典型特点就是处于汇总级别,通常数据越旧,汇总级别越高。
2.1.2 数据仓库典型特征--Kimball版本
Ralph Kimball则使用了不同的方法,他将数据仓库简单地定义为“交易数据副本,其结构是专为查询和分析而设计的”。与操作型系统的数据不同的是,这个副本采用的结构(维度数据模型)可以使得业务用户更方便地理解和使用数据,而且也能解决数据仓库的查询效率问题。数据仓库业务常常包含交易数据之外的数据——为给出交易的上下文,参考数据是必需的。然而,交易数据是数据仓库中最主要的数据。
维度数据模型是关系型数据模型,它们不必遵循范式规则。与范式模型相比,维度数据模型更清楚地反映了业务处理过程。
2.2 数据仓库和商务智能架构和组件
Inmon和 Kimball 从全局角度,对大多数数据仓库及商务智能的环境都提供了总体的看法,本节将介绍其主要构成。首先是来自Inmon的企业信息工厂。其次是Kimball 的方法，他称之为“类似象棋的数据仓库游戏(DW Chess Pieces)”。下文对这两种看法及其构成进行了描述和对照。
2.2.1 Inmon的企业信息工厂
Inmon与 Claudia Imhoff和 Ryan Sousa一起,为数据仓库和商务智能管理职能标明并编写了企业数据架构的组成内容，并将其称为“企业信息工厂(Corporate InformationFactory,CIF)”。这些组成内容如图9.2所示。
表9.1列出并描述了从企业信息工厂角度看数据仓库和商务智能架构的基本组件。
表9.2给出每一个企业信息工厂组件的报表范围、目的及备注,形成上下文环境。
表9.3从业务和应用角度,在企业信息工厂的4个主要的组件之间进行比较和对照,即在应用系统(Application),操作型数据存储(ODS)、数据仓库(DW)和数据集市(DM)之间进行比较。
根据右侧的数据仓库和数据集市的信息与左侧的应用之间的比较,有一些总体的规律，特别如下:
• 组件用途从执行转向分析。
• 终端用户通常是决策者,而不是执行者(一线人员)。
• 系统更多的是即席操作,而不是固定的交易操作。
• 响应时间的需求更加宽松,因为战略决策相对于一般的日常操作而言能够容忍更长的响应时间。
表9.4中“数据保留历史”和“响应时延"两行所表示,这里描绘了一个经典的框架,框架中大多数数据仓库处理过程的时延更长,而且会出现通宵的批处理。持续的业务压力,对数据提出更多更快的需求,以及底层技术的改进,这些因素的结合模糊了不同结构设计方法的界限,并提出了更高的要求。这些将会在9.2.4节第1部分动态数据仓库中进行讨论。作为一个高级主题,它不会在这里作为一个架构选项被展示。
将右侧数据仓库和数据集市的信息与左侧的应用之间从数据的角度进行比较,可发现一些总体规律,特别如下:
• 数据是面向主题的而不是面向功能的。
• 整合的数据不是“烟囱式”(stove-piped)或“竖井式”(or siloed)的孤立数据。
• 随时间变化的数据历史不是只有当前数据。
• 数据时延更高。
• 更多的历史数据。
2.2.2 Kimbal的业务发展生命周期和数据仓库象棋游戏
Ralph Kimball称其方法为业务维度生命周期;然而,它仍然常常被称为Kimball方法。他的第49条设计技巧R提到,“我们选择业务维度生命周期标签代之,因为基于从20世纪80年代中期所收集的经验来看,业务维度生命周期强调了关于成功的数据仓库活动的核心原则。
业务维度生命周期的根据是如下3个原则。
·关注业务——-既要满足即时的业务需求,而且也要满足长期的广泛的数据整合和一致性。
·原子性维度数据模型-─―既要使业务用户易于理解,也要兼顾查询效率。
·迭代演进管理-─-用独立的并限定范围的单个项目来管理数据仓库的变革和优化，即使这样的项目可能会多的看不到终点。
业务维度生命周期提倡使用一致性维度和事实表设计。构建一致性的过程强化了企业分类和一致的业务规则,从而使数据仓库的某些已被整合的部分可以被重用。
图9.3展示了Kimball所提到的数据仓库象棋棋子(The Data Warehouse Toolkit ,第二版,Ralph Kimball和 Margy Ross,John Wiley父子合著,2002)。需要注意的是,Kimball所使用的术语“数据仓库”已经比 Inmon包含更多更广泛的内容。在图9.3中,Kimball使用术语“数据仓库”涵盖数据暂存区和数据展示层的所有内容。
表9.5描述了Kimball 的数据仓库象棋棋子视图中的基本组件,该视图描绘了数据仓库和商务智能的架构,并请注意这些组件如何与企业信息工厂的组件相互对应。
2.3 战术型、战略型和操作型商务智能
战术型商务智能是通过应用商务智能工具对同一度量进行月度或年度的比较分析业务趋势,或者分析历史数据以发现需要引起注意的趋势。使用战术型商务智能以支持短期的业务决策。
战略型商务智能是经典的商务智能应用,包括为高管提供度量指标,常常与一些正式的业务绩效管理方法结合共同帮助管理层确定目标是否达成。使用战略型商务智能以支持公司的长期目标和目的。
操作型商务智能是为业务一线提供商务智能,应用分析能力来指引经营性决策。操作型商务智能可用于管理和优化业务运营。操作型商务智能是以上这3个方法中最后一个在业界中出现的。操作型商务智能使商务智能应用和运营功能和流程相耦合,但其对响应时延要求很高(需要近乎实时的捕获数据和交付数据)。因此,必须使用更新的架构方法,比如面向服务架构(Service-Oriented Architecture,SOA),以完整地支持操作型商务智能。某些方法将在9.2.4节第1部分讨论。
2.4 数据仓库活动的不同类型
本节讨论数据仓库活动的3种主要类型。
2.4.1 动态数据仓库
服务于战术和战略商务智能的数据仓库已经存在多年,常常每日加载数据,并在夜间完成批处理任务。这些架构非常依赖于Inmon原来所提出的数据仓库的一个特性,即相对稳定的数据。
操作型商务智能（和其他业务的一般需求)的出现推动了对更低的时延以及实时或近乎实时地将数据整合到数据仓库的需求,新的架构方法涌现出来,以处理数据仓库所包含的不稳定的数据。操作型商务智能的常见应用是为自动柜员机(Automated Teller Machine,ATM)提供数据。每当执行一次银行交易,历史余额和本次交易发生后的余额,需要实时地展现给银行客户。这里不可能完整地介绍这些新方法是如何完成此类数据供应的,但是足以引入新方法所需的两个关键设计概念——变更的隔离以及数据ETL批处理的其他替代方法。
由新的不稳定数据所带来的变更必须与历史的、相对稳定的数据仓库数据进行隔离。为实现隔离,典型的架构方法将在必要时构建分区并对这些分区进行联合查询。
实现更短的响应时延以满足数据仓库数据可用性要求,许多数据ETL批处理的替代方法应运而生,其中包括持续少量数据更新(Trickle-feeds),管道(Pipeline),以及面向服务架构(Service-Oriented Architecture,SOA)中设计和维护的数据服务。
2.4.2 多维分析—联机分析处理
联机分析处理(Online Analytical Processing)是指为多维分析查询提供高效性能的方法。术语联机分析处理的起源,部分是为了与联机事务处理(Online TransactionalProcessing ,OLTP)进行清晰的区分。典型的联机分析处理查询的输出是矩阵格式。维度形成了矩阵的行和列;而因素(Factors)和度量(Measures)就是矩阵单元格的取值。从概念上讲,这就是立方体(Cube)的解释。当分析师试图查看汇总数据时,使用立方体进行多维分析是非常高效的方式。
一个常用的应用就是财务分析,分析师要反复遍历不同层次以分析数据;例如,日期(如年、季、月、周、日)、组织(如区域,国家、业务单元、部门)以及产品层次(如产品类别、产品线、产品)。
2.4.3 ROLAP.MOLAP.HOLAP和 DOLAP
有3种经典的实施方法支持联机分析处理,它们的名字分别与各自所依赖的数据库实施方法有关,比如关系型、多维型、混合型和数据库型。
• 关系型联机分析处理(Relational Online Analytical Processing,ROLAP)——关系型联机分析处理在关系型数据库管理系统(Relational Database ManagementsSystems,RDBMS)的二维表中实现多维关系以支持联机分析处理。星型连接是在关系型联机分析处理环境中常用的数据库设计技术。
• 多维联机分析处理(Multi-dimensional Online Analytical Processing,MOLAP)——多维联机分析处理使用外围的,特别的多维数据库技术来支持联机分析处理。
• 混合联机分析处理(Hybrid Online Analytical Processing, HOLAP)——是关系型联机分析处理和多维联机分析处理的简单组合。混合联机分析处理实现时将部分数据以多维联机分析处理形式存储,其余部分以关系型联机分析处理形式存储。实现时,设计者可以控制具体分区的构成。
• 数据库联机分析处理(Database Online Analytical Processing,DOLAP)一通过经典关系型数据库特殊的外围功能实现一个虚拟的联机分析处理立方体。
2.5 维度数据建模的概念和术语
维度数据建模是设计数据集市首选的建模技术。Ralph Kimball博士引领了许多维度数据模型的术语和技术。本节的目的是引入相关的概念和术语。
Kimball关注的焦点是为终端用户展现数据,而通常来说,维度数据模型正是关注于让终端用户理解和访问数据更加简单。这种设计技术的特征就是主动地以更多开发人员的工作量来换取易于最终用户理解和使用的结构。根据维度数据模型,大多数数据集市的设计工作以数据的ETL处理结束。
表9.6对交易应用系统和数据集市的典型差异进行了比较,交易应用系统建立在关系数据模型之上,而数据集市建立在维度数据模型之上。
维度数据模型是实体关系型数据模型的子集,也具有实体,属性和关系等基本组件。实体一般有两种基本类型:事实(Fact),提供度量;维度,提供上下文。在简单维度模型中的关系被包含并贯穿于事实表中,所有的维度到事实的关系是一对多(1:M)。
2.5.1 事实表
事实表包含重要的业务度量。术语“事实(fact)”承载了多重含义,如“事实表(fact table)”(实体)包含了一个或多个“事实”(代表度量的属性)。事实表的行包含特定的数值型度量，比如数量、数目计数。一些度量是计算的结果,因此正确理解和使用元数据就很重要。事实表占据了数据库中大多数空间(根据经验可合理推断大约占90%),而且倾向于使用有很多列的行来存储数据。
事实表用来表达和解析维度间的多对多关系。访问事实表也一般从维度表开始。.事实表通常有很多控制列,这些列用于表示行被加载的时候,是由哪些程序加载的,或者指示哪些是最新的记录,或者其他一些状态。这些字段有助于程序员、操作员和超级用户浏览和验证数据。
2.5.2 维度表
维度表,或缩写为维度,代表业务中的重要对象而且包含相关的文字描述。维度以“根据……查询”(query by)和“根据……报告"(report by)的形式作为限制条件。它们是访问或链接到事实表的人口,而且它们的内容可以作为报表分组和报表标签的依据。维度结构通常是高度去范式化,而且根据经验大约占所有数据的10%。维度详细设计的深度和质量决定了系统的分析用处。
所有的维度设计都可能包含日期维度、组织或当事人维度。其他的维度取决于如何支持对事实表中数据的分析。
典型的维度表只有少量的行数和很多列数。维度表的主要内容是:
• 代理键和非代理键。
• 主键用于与数据仓库中其他表关联。
• 描述性元素,包括编码、描述、名称、状态等。
• 任何层次信息,经常包括多个层次和类型的分解。
• 业务键,供业务用户确定特定的行。
• 源系统标识字段,用以追溯数据来源。
• 维度表的控制列与事实表的控制列类似,但是维度表的控制列主要涉及维度的历史信息如何保存,且往往设计成如下文所描述的类型1、类型2类型3类型4和类型6等不同的实现方法。
维度必须为每一行设置唯一的识别符,通常通过代理键和自然键等两种方法来实现。
1)代理键
在Kimball 的方法中,每个维度行都会被赋予一个与实际数据毫无关系的数字作为主键。该数字被称为“代理键”(surrogate key)或“匿名键”(anonymous key),而且既可以是一个顺序码,也可以是真正的随机码。使用代理键的好处体现在如下一些方面。
• 性能数值型字段往往比其他类型的字段有更好的搜索性能。
• 隔离——它是业务主键变化的缓冲区。代理键可以不受源系统字段数据类型或长度的变化的影响。
• 整合——使得来自不同的数据源的数据可以融合。通常不同源系统中的主键往往互不相同。
• 优化—诸如“未知”(Unkown)或者“不可用”(Not Applicable)等这样的取值,可以拥有其自己特有的键值,从而与其他存有有效值的行相区别。
• 互操作性——某些数据访问功能和图形用户界面可以更好地处理代理键,因为它们都不需要有所依赖的系统相关的额外知识就能正常工作。
• 版本化——同一维度值可以有不同的实例,这对于根据时间跟踪变化是非常有用的。
• 诊断——支持加载问题分析,并且具备重新运行的能力。
为了实现代理键的这些优点,必须需要有额外的数据ETL处理以将数值主键与源系统主键进行映射,并维护映射表。
2)自然键
对于某些系统,可能不希望额外创建主键字段,而是使用已经用于区分唯一数据行的数据。使用自然键的优点包括:
• 较低的代价——键值字段已经存在,无须额外的建模以创建或处理新的键。
• 易于变化一--在关系型数据库管理系统中,存在域的概念,它易于根据源系统的变化进行全局变化。
• 性能提高—-使用唯一键给你的值可以完全避免表的关联,从而提供性能。
• 数据血缘关系——更容易跨系统跟踪,特别是当数据在两个以上的系统间移动。
作为这些优势的代价,使用自然键,在每次联结查询时有可能需要使用多个复杂的非数值字段作为条件。而且在某些关系型数据库管理系统中,在联接查询中使用字符串进行联接查询的效率要低于使用数值字段。
2.5.3 维度属性类型
维度属性有3种不同的保留历史副本的类型。这3种类型被创造性地命名为类型1、类型2(以及2a)和类型3。还有另外两种不经常出现的类型,通常被创造性地命名为类型4和类型6(1＋2+3)。类型1~3能够在同一张表中共存,而如何进行更新则依赖于字段和类型的关系。
1)类型1覆盖
类型1维度属性不需保留任何历史记录。它仅仅保留最新取值,因此任何更新都完全覆盖此字段之前的取值。类型1的一个例子是“头发颜色”。更新时无须保留当前值。
2)类型2创建新行
类型⒉维度属性需要保留所有的历史记录。每一次当类型2字段变化,就会创建一行存储最新信息的记录,而之前有效的记录将会通过更新有效期字段被标志为过期记录。类型2的例子是账单地址。当账单地址发生变化,保留旧地址的行过期而记录新的账单地址的行会被增加到表中。
需要注意的是,采用类型2要求该表主键能够为相同的自然键保留多个实例,这既可以使用代理键实现,也可以为主键增加索引值,或者增加一个日期值(表示生效、过期、插入等)为主键。
3）类型3创建新列
类型3维度属性仅需有选择地保留已知的历史记录。在同一行中可能需要有多个字段保留不同的历史版本。当出现更新时,当前有效值将被移动到下一个合适的字段中,新的合适的字段将被用于存储,而最后一个无需保留的值将会被丢弃。类型3的例子是信用评分，仅需保留开户时的原始评分和最新评分,以及最近一次被更新的评分。更新操作会把当前评分设为上一次评分。
另外一个例子是月度账单总额。可以有12个字段,分别命名为Montho1, Month02等,或者“一月”、“二月”等。如果是前者,则当前月度的取值会更新字段Month01的取值,而其他字段都会顺序下移。如果是后者,当相应的月度数据被更新了,用户知道当前月份以后的字段值保留的是去年的数据。
类型3可用于属性值的迁移。例如,一个公司决定重新组织其产品层次,但是希望在本年度同时看到旧层次和新层次的销售数据图表,要实现这点要求所有数据都要恰当地记录下来。如果在某一时期,旧新数据都可用,就可以进行这种数据转换。
4)类型4新表
类型4维度属性将过期的行移动到“历史”表中,而“现有”表中的行会被当前信息更新。类型4的例子可以是供应商表,当过期的供应商记录在更新发生后被移至历史表中,则主维度表仅包含当前的供应商记录。后者有时也被称为类型2a维度。
在类型中,根据时间线来获取数据将会更加复杂,因为现有表和历史表需要被关联起来以便于再和事实表关联。因此,当用户访问主要是现有维度数据,而维护历史表主要是供审计所需,类型将会是一个好的选择。
5)类型6(1十2+3)
类型6以类型2的方式处理维度表,当任何值发生任何变化时创建一条新的记录,但是键值(代理键或自然键)不需要改变。实施类型6的一个方法是为每行增加3列-一生效日期、过期日期以及一个当前有效指示符。如果是查询根据特定时间点来查找数据,则检查所需查找的时间是否在生效日期和过期时间之间。如果查询仅仅需要查找当前数据,则可增加过滤器并以现有记录指示符为条件。增加过滤条件的缺点是要求用户具备额外的知识能够通过时间区间或指示符来获取所要的记录。
实施类型6的另外一个方法是增加索引列来取代现有记录指示符,而索引列的当前值为0。所有被更新的行获得索引值为0,而其他行则在其索引列上加1形成序列。则如果查询需要寻找当前取值则应将索引列的过滤条件设为0,而当查询需要寻找之前时间所对应的列则需要使用生效日期和过期时间。这一技术的主要缺点是所有事实表中的记录都会自动连接到索引列取值为0的维度(当前记录)。关联到事实表的查询不会找到任何此维度之前的取值,除非将维度的生效日期和过期时间包含在查询中。
2.5.4 星型模型
星型模式是如图9.4所示的维度数据模型,事实表位于中间,连接到周围的众多维度表。它也被称为星型关联模式,重点在于中间的事实表通过单一的主键联接到周围的维度表。居中的事实表有着来自于众多维度表的键构成的复合键。
2.5.5 雪花模型
雪花模型是将星型模型中平面的单表维度结构进行去范式化,并转换成相应的层次或网络结构。Kimball 的设计方法中,因为如下两种原因并不鼓励使用雪花模型:(一)它对星型模型的简单性和终端用户易于理解的特性造成负面影响;以及(二)空间的节省有限。共有3种公认的雪花模型:纯正雪花式(True Snowflakes)、划艇式(Outriggers)和船桥式(Bridges)。
• 雪花表(Snowflake Tables)一-一将层次结构解析到层次表中。例如:将一个日期维度表解构为一个详尽的日表,和一个与日表关联的月表或者年表。
• 划艇式表(Outrigger Tables)—将维度表中的属性连接到其他维度表中的行。例如,某一维度中的日期字段(比如员工的雇用日期)可以连接到时间区间维度表,以便于按照雇用日期所在的财年对员工进行排序。
• 船桥式表(Bridge Tables)—形成两种情况。其一是当两个维度之间存在多对多的关系,而且不可能通过事实表解析这种关系。例如一个银行账号有多个所有人。船桥式表用一个“所有人组(Owner Group)”表来定义所有人列表。其二是对深度不定的层次结构或不整齐的层次结构进行范式化。船桥式表可定义层次结构中的父子关系,使遍历更加有效。
2.5.6 粒度
Kimball 用术语“粒度”(Grain)表示事实表中的一行记录所代表的含义或描述。或者用另外一种方式来表述,粒度表示一笔交易所对应数据的原子级别。在一个事实表中定义粒度是Kimball的维度设计方法中的关键步骤。例如,如果事实表中存放某月的所有交易数据,则我们可以推断事实表中数据的粒度或限制不会包括去年的数据(即事实表粒度细到月,则我们可推断出该事实表中不可能包括去年的数据)。
2.5.7 一致性维度
一致性维度是在 Kimball设计方法中可供多个数据集市使用的公用或共享的维度。更加准确的是,Kimball 是对数据元素命名及相应的取值,或包含严格的子集等方面相匹配的维度来定义一致性维度的。实际意义在于是从一致性维度获得的任何结果集中的行头部(Row Header)都必须能完全匹配。
例如,设想一下多个数据集市或事实表,都直接联接到同一维度表或者该维度表的直接复制副本上。该维度表的更新将自动反映到这些数据集市的所有相关查询中。
在其他星型模型中重用一致性维度使得数据仓库的模块化开发成为可能。即使设计不断膨胀,星型模型也能通过一致性维度粘连在一起。在一个数据仓库中,起源于支付部门的事实表,能够与供应部门的供应商绩效事实表通过共享的产品维度粘连起来。最终,对若干主题域的查询将是对企业数据仓库中数据的访问。
2.5.8 一致性事实表
一致性事实表使用跨多个数据集市的标准化术语。不同的业务用户可能以不同的方式使用同一术语。“客户加成”(Customer Addition)与“毛利润加成”(Gross Addition),或“调整加成”(Adjusted Addition)是否-致?“处理订单"(Orders Processed)指的是整个订单，还是某条业务线上的产品汇总?
开发者需要敏锐地意识到很多事物称谓一样,但是在各个组织中的概念并不相同,或者相反,事物的称谓不一样却在各个组织中实际表达的是同一概念。
2.5.9 数据仓库总线(DW-Bus)架构和总线矩阵
术语总线(Bus)来自Kimball的电子工程背景,总线是同时为许多电子元件提供电力的组件。如此类推，一致性维度的数据仓库总线架构允许多个数据集市共存,并通过接入总线实现一致性维度的共享。
数据仓库总线的矩阵是以表格的形式展示数据集市/数据处理过程/主题域是否与共享的一致性维度相关。表9.7正是这样一个总线架构所代表的矩阵实例。一个数据集市在使用多个数据维度时可能会使用--致性维度(如行所示)。而数据仓库总线体现在多个数据集市使用同一维度(如列所示)。
数据仓库总线矩阵是非常有效的沟通和计划工具。对于数据仓库和商务智能管理实践而言,统一的概念是Kimball最有价值的贡献之一,也成为数据仓库和商务智能管理中的重要设计文件,需要检查现有的维度表和事实表,以及它们的源、更新逻辑、调度计划,从而确定是否可以重用。
三、数据仓库和商务智能管理活动
在数据仓库和商务智能管理生命周期中,数据仓库活动主要关注于把数据从数据源整合到可供各个部门使用的公共数据存储区中,也就是关注数据内容。而商务智能管理活动关注于从公共数据存储区到目标用户使用数据,也就是关注数据展示。
数据仓库和商务智能管理从来都是互相交织在一起的,如果没有某种方法提供对所收集数据的访问以及分析和报表支持,数据仓库则对组织毫无价值。反过来,商务智能管理是否可以产生效果则直接取决于数据仓库所提供的及时、相关、完整的数据,以及数据质量控制和相关的文档等。
数据仓库和商务智能管理职能活动与本指南涵盖的许多数据管理活动交叠。本节的目的是在实施实践的背景下清楚地说明数据仓库和商务智能所包含的活动。本节提供了该职能管理中的各种方法、工具和技术,提供了实用的见解,并包含了对其他数据管理职能的参照。
3.1 理解商务智能信息需求
数据仓库和商务智能管理成功的关键在于在整个生命周期中始终保持一致的业务重点。通过对企业价值链的观察,可以很好地理解业务背景。企业价值链中具体的业务流程提供了天然的面向业务的背景环境,从而可以构建了分析范围的框架。可从4.2.2节第3部分获取价值链的进一步信息,图4.4是一个相关的例子。
为数据仓库和商务智能项目收集需求与其他典型的IT项目有很多异同点。相比较而言,数据仓库和商务智能管理要求从更广泛的业务背景环境中理解目标业务领域,因为数据仓库和商务智能管理要处理的报表是用于归纳和探索的。这里的更广泛的业务环境与操作型系统中的业务背景全然不同,后者的开发流程已经提前定义了对操作和报表的精确具体细节和需求。
从本质上说,数据仓库和商务智能项目中的分析更加特别,包括提出问题,并引出新的或者不同的问题。当然,这些查询将受限于可用数据的性质和质量。尽管很难搞清楚所有报表的具体规格,但是却可以整理清楚问题的背景环境,即知识工作者对数据最可能进行的操作与查看角度。
首先识别业务领域并明确其范围,然后确认并访谈适当的业务人员。了解他们如何进行分析以及为什么这么做;收集他们提出的具体问题;记录他们是如何区分和分类信息的重要部分;了解业务人员如何成功地跟踪和定义。尽可能定义,获取关键绩效指标度量和计算公式。
获取实际的业务词汇和术语是成功的关键,商务智能需求收集活动是与元数据管理职能(参见第11章)非常好的交互的机会,因为从最初的数据源,经过所有的转换,到最终的展现,需求分析对于理解端到端数据的业务环境是非常关键的。总而言之,一个完整的数据仓库和商务智能管理项目需求文档,要制定出整个业务领域的流程框架。
记录下业务背景环境,接着探索实际源数据的细节。通常数据ETL活动可能占去整个数据仓库和商务智能项目67%的成本和时间。数据剖析是非常有用的,而且与数据质量职能的协作是必不可少的(参见第12章)。对源数据状态的评估可以使得预先估计项目的可行性和项目的工作范围更加准确。评估对于设定合适的项目预期也十分重要。
需要注意的是,数据仓库通常首当其冲地受到源系统和数据录入功能中质量低下数据的负面影响。对于必然出现在实际数据中的那些异常数据情况,如何处理它们是非常必要的,因此与数据治理职能(参见第3章)协同工作相当关键。
一个最佳实践做法是为已经被识别出的商务智能需求制定执行概要(ExecutiveSummary)。执行概要需要包括业务环境纵览,问题样例列表,对已有的数据质量和清洗、整合等不同层次活动的评注,对相关的组织和业务职能的描述。它也可能包括一张用于展示查询和报表途径的方案草图。要会同业务部门共同审阅执行概要,来确定数据仓库和商务职能项目在项目集中的优先级。
对数据仓库和商务智能项目集,可以通过对业务影响和技术可行性进行简单的评估,来决定从何处开始启动项目。技术可行性会考虑诸如复杂性、可用性和数据状态,以及领域专家的可用性等。业务影响大.技术可行性高的项目可优先启动。
最重要的是,要对来自业务部门支持力度进行评估,可考虑如下3个成功的关键因素。
• 业务支持—存在适当的来自于管理层的支持吗?例如，一个专门的推进委员会和相应的资金支持。数据仓库和商务智能项目需要强有力的管理层支持。
• 业务目标和范围——是否存在清晰明确的业务需求、目的和工作范围?
• 业务资源—-业务管理层是否承诺并保障有相关业务领域专家的加入?缺乏承诺是最常见的失败原因,并且也是一个充足的理由来暂停数据仓库和商务智能管理项目,直到有承诺确认再重新启动它。
3.2 定义并维护数据仓库和商务智能架构
第4章中已经阐述了通常的数据架构,以及数据仓库和商务智能架构中的众多组件,包括企业数据模型(主题域,概念模型、逻辑模型),数据技术架构以及数据整合架构等。9.2.2节中介绍了数据仓库和商务智能架构的关键组件。本节将增加一些在实践中与数据仓库和商务智能架构的设计和维护相关的考虑因素。
成功的数据仓库和商务智能架构要求确立许多关键的角色并将它们(甚至可能是来源于其他主要的数据管理职能)汇聚起来,包括:
• 技术架构师——硬件、操作系统、数据库和数据仓库和商务智能管理架构。
• 数据架构师——数据分析、记录系统、数据建模以及数据映射。
• ETL 架构师/设计组长——数据处理过程和数据转换、数据集市以及任务计划等。
• 元数据专家——元数据接口、元数据架构以及元数据内容。
• 商务智能应用架构师/设计组长——商务智能工具接口和报表设计、元数据交付,数据和报表的导航、交付(如推、拉、取消、即席)。
数据仓库和商务智能管理需要利用许多学科的知识,以及公司IT部门和业务部门等多个组件。因此，一些关键的初始活动包括评估和整合合适的业务流程、架构以及技术标准,包括:
• 服务器。
• 数据库。
• 数据库的黄金副本(记录系统)确认和业务确认。
• 安全。
• 数据保留。
• 数据提取、转换和加载工具。
• 数据质量工具。
• 元数据工具。
• 商务智能工具。
• 监控和管理工具以及报表。
• 任务调度工具和调度计划,包括标准的业务和日历相关的关键任务。
• 错误处理流程和程序。
从技术需求角度而言,效率,可用性和及时性方面的需求是开发数据仓库和商务智能管理架构的关键因素。数据仓库和商务智能架构需要回答关于数据何时去何地、因何而去,以及如何去等基本问题。其中“如何去"包括了硬件和软件的所有细节,这是将所有的活动组织起来的一个框架。
数据仓库将包含哪些详细的数据,是数据仓库和商务智能管理架构设计决策和原则中需要被优先考虑的关键活动。发布清晰的规则来说明什么数据只能来源于操作型报表(比如在非数据仓库中)是数据仓库和商务智能管理工作成功的关键。最佳的数据仓库和商务智能管理架构将设计一个机制可以把数据仓库中原子级别的数据回溯到交易级别和运营级别的报表。这种机制是好的数据仓库设计技巧的一部分。它可以避免数据仓库加载每一个交易数据的细节。
比如,给关键运营报表或表单提供基于交易主键(如发票号码)的查看机制。客户当然永远希望得到所有的细节,比如一个很长的描述字段,但是这些运营数据仅在原始报表的环境中才有价值,而无法提供分析价值。
数据仓库和商务智能管理架构与公司的整个报表相互整合是非常重要的。目前存在很多种设计技术方案,其中一个有效的技术就是关注并定义合适的业务服务水平协议(SLA)。通常,响应时间,数据保留期限以及可用性需求根据业务类别的不同和相应的支持系统的不同会存在巨大的差异,比如运营型报表、数据仓库和数据集市之间就存在巨大的差异。9.2.2节中的几张图表有助于理解数据仓库和商务智能管理架构不同设计组件的各个方面。
另外一个关键的成功因素是确定数据重用,共享和扩展的规划。9.2.5节第9部分引入的数据仓库总线矩阵提供了一个很好的组织模式。
最后,如果业务部门没有认可数据,数据仓库和商务智能管理工作是不可能成功的。业务确认包括数据是可理解,质量可校验,具有可以验证的数据血缘关系。来自业务部门对数据的签收同意,是用户验收测试的一部分。在商务智能管理工具中对源系统中的数据进行结构化的随机测试,执行初始化加载以及少量的更新加载操作以满足签收同意条件。满足这些需求,是每一个数据仓库和商务智能架构的至高点。通常在前期需要考虑如下一些非常重要的与架构有关的子组件以及相关支持活动。
• 数据质量反馈环—把变更整合到业务系统的难度如何?
• 端到端元数据——架构支持完整的端到端的元数据流吗?特别是在整个架构的含义和设计中能否实现透明性和可用性要求?当业务人员需要了解“这张报表、这个数据元素、这个度量等是什么意思”,架构和设计是否支持很方便地给出答案?
• 端到端可校验数据血缘关系——是否有证据保管链确保来随时核查数据仓库和商务智能的数据?是否有一个确认所有数据的记录系统?
3.3 实施数据仓库和数据集市
数据仓库和数据集市是数据仓库和商务智能管理中的两种主要的数据存储方式。
数据仓库的目的是将来自多个数据源的数据进行整合,整合后的数据为商务智能服务。数据仓库总数据使用者一般是通过数据集市或者其他系统(例如数据挖掘应用与平面文件)进行操作。数据仓库的设计是一个符合范式要求的关系型数据库。理想状态下，一个数据仓库会整合来自多个数据源的数据,并将这些数据服务于多个数据集市。
数据集市的主要目的是为知识工作者的分析工作提供数据。成功的数据集市必须提供简单,易于理解且性能良好的数据访问方法。如9.2.5节中所介绍,维度建模(使用去范式化技术)和设计,已成为面向用户数据集市设计技术的首选。创建一个数据集市以满足专门的业务分析需求。数据集市通常包含聚合和汇总的信息以支持更迅速的分析。Kimball提出的数据仓库只包含若干数据集市而不需要范式化的数据仓库层。
在第5章详细介绍了数据设计和数据库设计。而本章结束时的参考文献给出了许多关于数据仓库和商务智能实施方法的优秀书籍。
作为回顾,我们不妨将数据仓库和数据集市的使用看做是 Covey著名的7个习惯的应用,比如以终为始。首先,确认需要解决的业务问题,然后确认细节和需要使用的手段(最终的软件解决方案的片段以及相关数据集市)。从这里,逐步反溯到所需的整合数据(数据仓库),最终回到数据源。
3.4 实施商务智能的工具和用户界面
随着商务智能市场的成熟,大量现成可用的商务智能工具使企业很少构建自己的商务智能工具。本节通过介绍商务智能市场上不同类型的工具,概览它们的主要特点,以及一些相关信息,来帮助我们将这些工具与客户层面所要求的能力进行匹配。
实施合适的商务智能工具和用户界面(User Interface,UI)就是为正确的用户群选择合适的工具。几乎所有的商务智能工具都自带元数据存储库以管理内部数据映射和统计信息。某些供应商将其存储库向终端用户开放,某些供应商甚至允许用户将业务元数据存放到存储库中。企业的元数据存储库必须连接到这些存储库或者创建对应的副本,从而获取工具提供的报表和分析活动的全貌。第11章涵盖了元数据管理相关内容。
3.4.1 查询和报表工具
查询和报表是从数据源查询数据,然后将数据格式化以创建报表的过程,既可以是生产相关的报表如发票,也可以是一个管理报表。
业务运营报表中的需求常常与业务查询和报表中的需求不同。但有的时候,需求模糊且互相交叠。正如你可以使用锤子将钉子钉入墙中,你可以使用一个业务运营报表工具制作管理报表;但反过来却未必可以,很少情况下可以使用业务查询和报表工具来开发业务运营报表。一个业务查询工具通常不能提供完美的格式,范式化的数据源,或者IT开发者所需要的可编程能力。
业务查询和报表的数据源通常是数据仓库或者数据集市(尽管不是永远如此)。IT开发生产报表的同时,权限较大的用户和普通业务用户也会使用业务查询工具开发他们自己的报表。表9.8对商务智能工具类别与主要的用户类别之间的映射提供了很好的总结。它也对有助于区分业务运营风格报表和业务查询和报表风格报表的一些特点进行了比较。这些特点并不是绝对的,也没有必要去寻找能够完全满足的第三方工具。个人、部门或者整个企业都可以使用业务查询工具生成的报表。
近些年,报表工具的市场发生了巨大的变化。所有的主要的商务智能供应商开始提供以前主要用于应用报表领域的完美格式的报表能力。简单地从成本角度考虑,报表和信息的提供机制和基础架构与信息内容以及类型是没有关系的。换言之,公司利用公共的基础设施和提供机制是明智之举。这包括用于提供所有类型信息和报表的网页,邮件以及应用程序,数据仓库和商务智能管理只是其中的一部分。
业务运营报表可以越过数据仓库和商务智能管理的边界,经常去查询交易系统以生成运营项目报表,如发票或银行流水。生产报表的开发人员一般都是IT员工。
业务查询和报表工具使用户可以编辑他们自己的报表,或为其他用户创建报表。他们很少考虑页面的精确布局,因为他们并不准备生成发票或类似项目。然而,他们确实需要快速且直观地得到图表。一些工具关注于数据的创新型展现上,并将其作为使用数据图表展现数据意义的一种方法,将数据以时间为横轴进行变化。在这个领域,格式化功能有着明显的差异。在这个领域中的工具是指即席查询工具。由业务用户所创建的报表也常常成为标准报表,而不仅仅用于即席的业务问题。
定义目标用户分组时需要关联到商务智能需求。首先了解你的用户分组，然后为公司中的不同用户组匹配合适的工具。一方面,IT开发人员最关心的是数据抽取,并关注一些高级功能。而另一方面,信息使用者也许希望快速访问之前开发和执行的报表。这些使用者也许希望进行某种程度的互动,如钻取、过滤、排序,或者只是希望看到--张静态的报表。
钻取是在线分析处理提供的一项功能。那么这仅仅是分析师或权限较高的用户的需求吗?抑或是用户/供应商/一般用户都有可能提出的需求,而这种需求在过去是无法实现的?
你需要理解所有不同类型的用户希望如何使用商务智能工具,包括 Web用户。那么Web仅仅是一种交付机制吗?或者仅是报表授权环境?你会不会或如何提供Web环境下报表的离线访问?
用户也有可能根据自身技能的增长或执行不同的业务职能而改变其所属的用户组。例如一个供应链经理,他也许希望查看静态的财务报表,同时也希望在可以使用高度互动的报表来分析库存。一个财务分析师或者一个负责成本开销的生产线经理在分析总体成本时是一个权限较高的用户,但在查询自己的电话账单时仅仅是一个普通用户而已。
外部用户一般只查看静态报表,比如活动汇总。然而逐渐地,公司开始为优质的客户和主要供应商提供互动良好的企业外网报表。一线的工作者也许使用静态的、公开发布的报表,或者在一个应用中内嵌的信息。高管和中层经理会使用固定报表,仪表盘和记分卡的组合。中层经理和权限高的用户则倾向于对报表进行钻取y将数据分片分块,以发现问题的根本原因。
3.4.2 联机事务分析(OLAP)工具
联机分析处理以不同维度和不同层次的细节提供互动和多维的分析功能。9.2.4 节第3部分简要介绍了这个话题。本节则关注联机分析处理工具,这些工具将数据组织成OLAP立方体以供快速分析。
通常商务智能工具中的立方体是从星型(或雪花型)的数据库模式生成的。联机分析处理立方体包含了源自事实表的许多数字型的事实,也就是度量。这些立方体可以是根据需求虚拟而成或是通过批处理作业生成的。通过维度将这些事实归纳到相应的模式(参见9.2.2节)。
联机分析处理工具和立方体的价值在于通过根据分析师的思维模型将数据内容进行整理,从而减少了可能出现的混淆和错误。分析师可以在数据库中浏览数据,筛选出特定的数据子集,改变数据的定位以及定义分析计算公式。切片和切块是用户在浏览过程中,通过对立方体数据片的旋转以及向上向下钻取,所进行的交互式的分页显示。常见的联机分析处理操作包括切片(Slice),切块(Dice)、下钻(Drill Down)、上卷(Drill Up)、汇集(Roll Up)和旋转(Pivot）。
• 切片(Slice)—一-切片是多维矩阵的一个子集,并且对于不在这个集合内的维度,至少有一个维度的值被指定。
• 切块(Dice)--一切块操作是在一个数据立方体上从两个以上的维度进行切片,或者是进行两次以上的连续的切片。
• 下钻/上卷(Drill Down/Up)——下钻或者上卷是用户按层次浏览数据时所使用的特定的分析技术,可以从最高层级的汇总到最细层级的详细数据。
• 汇集(Roll-up)——包括在一-个或多个维度上计算所有的数据关系。为实现它,需要定义计算关系或公式。
• 旋转(Pivot)———在报表和分页显示中变换维的定位。
3.4.3 分析应用
IDC的Henry Morris最先在20世纪的90年代中期提出术语“分析型应用"(AnalyticApplication),以区分于联机分析处理和商务智能工具。分析型应用包括一些众所周知的源系统,比如供应商的ERP系统中抽取数据的逻辑和处理过程,以及数据集市的数据模型，预定义的报表和仪表盘。分析型应用为不同的业务提供预定义的解决方案以优化某业务职能领域(例如人力资源管理)或者行业垂直应用（例如零售分析)。不同类型的分析型应用包括客户、财务、供应链、制造以及人力资源应用。
购买或自建分析型应用,对相关系统的实施十分微妙。当你采购了一个分析型应用,你同时也采购了数据模型和预定义了业务度量的立方体和报表。这些采购来的应用工具会告诉你什么是重要的,什么是你必须监控的,并提供一些技术让你能更快地得到结果。例如，使用通用的商务智能工具,你可以决定是否需要以及如何计算某业务度量,并确定该度量出现在哪几张报表中,例如每家店铺的平均销售量。而预定义的分析型应用则直接提供了这些度量以供使用。某些预定义的分析型应用提供了创建应用的开发环境。
建设分析型应用的提倡快速启动,比如缩短交付时间。评估分析型应用的一些关键问题包括:
(1）我们是否有满足数据提取,转换和加载需求的标准源系统?如果有,我们需要对其进行多少修正?修正越少表示价值越高或更加适用。
(2)有多少其他源系统需要被整合?如果需要整合的源系统越少,则价值越高,适用程度更好。
(3)有多少封装好的符合行业标准的查询,报表和仪表盘适用于我们的业务?需要业务分析师和业务用户加入,并回答相关问题!
(4）分析型应用的基础架构在多大程度上与现有的基础设施相匹配?如果匹配程度越高,则价值越高或透用程度更好。
3.4.4 实施管理仪表盘和记分卡
仪表盘和记分卡都是有效展示绩效信息的手段。通常,仪表盘更多地用于动态展现运营信息﹐而记分卡则更多地用于静态展现长期的组织架构方面,战术层面和战略层面的目标。记分卡专注于一个给定的度量,并将其与目标进行对比,通常基于业务规则使用红、黄和绿等展现目标的简单状态;而仪表盘则以许多不同的方式来展现多个度量。通常,记分卡将组织分解到4个象限:财务、客户,环境和雇员,并且根据组织的优先级安排可具有一定的灵活性。在每一个象限,可能都对应有许多度量,而这些度量用于报告或者展示由高管层设定的目标的状态和趋势。与目标的差异将被显示出来,通常也对每一个度量给出根本原因或评注。报表往往设定好每一个度量的负责人和检查间隔,以此才能强化绩效提升的预期。
在Wayne Eckerson关于绩效仪表盘的书中,作者给出了对仪表盘类型和架构的深度分析。实际上,展现这些信息的目的在于给出通过组合不同的商务智能技术创建丰富完整的商务智能环境实例。图9.6即是采用相关 TDWI的出版物所给出的示意图。
3.4.5 绩效管理工具
绩效管理应用包括预算、计划和财务整合。在此细分市场上发生过许多大型并购,这是因为ERP厂商和商务智能厂商都看到了巨大的增长机会并相信商务智能和绩效管理会逐渐趋同。从客户购买的角度,客户从同一个供应商购买商务智能和绩效管理产品的机会取决于产品功能,同时也取决于CFO和CIO的合作程度。必须指出的是:预算和计划并不仅仅与财务指标相关,同时也与人力资源、资本等有关。
3.4.6 预测分析和数据挖掘工具
数据挖掘是一种特别的分析,使用不同的算法揭示数据中的模式。标准查询和报表工具要求用户提出具体问题,而数据挖掘工具则帮助用户以更加具有探索性的风格去发现数据之间的关系,展示数据的模式。预测分析(“如果-怎样”分析)允许用户创建一个模型,用真实的数据测试模型,并据此投影出将来的结果。可使用神经网络或推理作为分析引擎。
在预测分析、欺诈感知,根本原因分析(通过簇集)、客户细分和评分,以及购物篮分析方面都可以使用数据挖掘。尽管数据挖掘是商务智能市场的一个细分,它依然是供专业用户使用的应用。在过去v统计学家从源系统和数据仓库抽取大量数据并在商务智能环境之外进行分析。而近来,商务智能和数据库厂商通过合作把数据库常规能力和分析处理能力更加紧密地耦合和整合在一起。一般地,数据挖掘会使用抽取的平面文件来训练挖掘引擎,然后在源数据库执行完整的挖掘,生成统计报表和图表。
需要注意的是，一个好的数据挖掘工具数据接口策略是与业务分析师一起定义出需要分析的数据集,并周期性地抽取到平面文件中。这一策略比起数据挖掘工具直接访问数据仓库,可以降低数据仓库的负担,而许多数据挖掘工具也可以接受文件形式的输入。
3.4.7 高级可视化和探索工具
高级可视化和探索工具通常采用驻在内存的架构使用户能够以高度可视且互动的方式来访问数据。通过少量数据的展示很难在大数据集中识别出模式。当成千上万的数据点可以用非常精巧的方式显示在一页中,可视化有助于快速识别模式。
这些工具与大多数仪表盘产品的区别在于:
(1)在分析的精巧程度,可视化的不同类型上存在差异,高级可视化和探索工具可以提供如低倍图、火花线图、热力图、柱状图、瀑布表、靶心图等工具。
(2)高级可视化和探索工具坚持与可视化社区的最佳实践相一致。
(3）高级可视化和探索工具提升了互动性和可视化探索程度的程度﹐而仪表盘只是创建一些简单的表格展示。
3.5 处理商务智能所需数据
任何数据仓库和商务智能管理工作中最主要的一部分就是准备和处理数据。本节将介绍在为商务智能处理数据的过程中相关的架构组件和子活动。
3.5.1 暂存区(Staging Area)
暂存区是原始数据源和中心数据存储库之间的数据存储。所有对数据必需的清洗、转换、整合,以及关联都发生在此区域。
先进的架构以良好的定义和循序渐进的方式来实现这些处理过程。通过工作分解可以有效地降低总体复杂性,也使得排错更加简单。再从相应的源系统卸载完整数据时,采用不进行任何转换的初始数据暂存区是一个常见的简单策略。
而变更捕获机制可以有效降低数据的传输量。最近几个月到几年的数据可以存放在初始暂存区。此方法的好处包括:
• 在源系统保存有限的数据,从而改善源系统的性能。
• 主动捕获完整的数据集合,以满足未来可能的需要。
• 以单次抽取的方式最小化对源系统在时间和性能方面的影响。
• 主动地创建一个数据存储,使其不受限于交易系统限制。
应使用后续的设计组件根据业务优先级过滤出需要的数据,并以逐步迭代,渐进的方式进行数据的一致化(conforming)和范式化(normalization)。最好进一步将数据一致化(如一致的数据类型、值集合)与数据合并(merging)和范式化分离,这样的设计更易于维护。很多架构中,这种方式被称为数据整合和转换,以区分于在暂存区中进行简单的复制操作。
3.5.2 映射源和目标
源到目标的映射是一个文档创建活动,用于对所有需要的实体和数据元素定义详细的数据类型及转换规则等,并且为每一个目标都找到一个数据源。相对传统的数据迁移,数据仓库和商务智能管理为这个经典的源到目标的映射处理过程增加了额外的需求。相关工作的一个特别的目标是为商务智能环境中可用的每一个数据元素提供完整的血缘关系,以追溯各自的源头。
所有映射工作中最困难的部分是为数据元素在多个对等的系统中确定正确的链接。比如,把多个账务或者订单管理系统中的数据整合到一个企业数据仓库。有可能会遇到含有对等数据的表和字段,却没有相同的名字和结构。一个可靠的分类是必需的,它可以将不同系统中的数据元素进行匹配,并导入到企业数据仓库的统一结构中。黄金数据源或记录系统的数据源必须得到业务部门的签字确认。
3.5.3 数据清洗和转换(数据获取)
数据清洗专注于校正单个数据元素取值,并提高该数据元素的领域价值,包括标准的强制执行。由于在初始加载过程中涉及大量的历史数据,数据清洗特别重要。如果有可能,首选的策略是将数据回退到源系统进行数据清洗和校正活动。
必须有策略来处理加载了却又被发现是不正确的数据记录。直接删除旧记录的策略可能会给相关的表和代理键造成大的破坏,更好的选择是将旧的数据置为过期,并把新的数据以一条全新的记录加载到数据库中。
数据转换专注在数据元素、实体和主题域之间提供组织环境。组织环境包括交叉参照,参考数据和主数据管理(参见第8章),以及完成和纠正数据关系。数据转换是为了将数据从多个数据源进行整合的基本组件。数据转换的发展需要数据治理职能更加广泛地参与。
3.6 监控并调整数据仓库处理过程
透明性和可见性是驱动数据仓库和商务智能监控的关键原则。越是将相关活动的细节暴露无遗,越是可以让最终用户看见并理解正在进行的工作(也会对商务智能越有信心),而且对最终用户的直接支持也会越来越轻松。如果仪表盘可以展示数据交付活动的高层状态,并提供下钻功能,这将是一种最佳实践，使得支持人员和客户可以按需获取信息。另外数据质量的度量可以增加仪表盘的价值:绩效不仅仅是速度和时效。
需要监控整个系统的处理过程,以发现处理过程的瓶颈和处理过程间的依赖关系。数据调优的技术应用在当用之处和需用之时,包括分区及备份恢复策略的调优。归档是数据仓库中的难点。用户常常把数据仓库看做数据归档活动,因为这里有长久以来的历史数据;但不愿意把数据仓库本身也进行归档操作,特别是在需要从联机分析处理数据源删除记录时。
对此,异常管理是一个很重要的策略。成功的消息一般会被归结为可忽略的消息,但是把因失败发出的提醒消息发送到监控仪表盘上将是一个明智的选择。
3.6 监控并调整商务智能活动和性能
商务智能监控和调优的最佳做法是定义和显示-一套面向客户的满意度调查。比如,平均查询响应时间和每天/周/月的访问用户,就是很有用的度量。除了显示来自系统的统计度量之外,定期地收集数据仓库和商务智能的用户反馈也非常有效。
对使用情况的统计数据和使用模式进行定期回顾是至关重要的。对数据、查询,报表活动的频率和资源占用情况进行统计报表有助于对性能进行优化。对商务智能活动进行调优的原则类似于剖析应用的原则,是为了了解瓶颈在哪里,应该在哪里进行优化。基于使用模式和统计数据而创建索引和聚集是最有效的优化手段。简单的解决方案有可能带来巨大的性能收益,例如把一个每天都会被执行成百上千次的查询用预处理的日报表形式发布出来。
四、综述
在组织中实施数据仓库和商务智能管理的指导原则、每一个数据仓库和商务智能活动相关角色的总结表,以及在数据仓库和商务智能管理中可能出现的组织和文化问题,总结如下。
4.1 指导原则
在一个组织中实施数据仓库和商务智能管理职能需要遵从以下11个指导原则:
(1）得到管理层的承诺和支持。此类项目为人力密集型项目。
(2）领域专家的保障。领域专家的支持和高可用性是得到正确的数据以及可用的商务智能解决方案的必要条件。
(3）聚焦于业务,并由之驱动。确保数据仓库和商务智能工作服务于业务需求,解决业务上的燃眉之急。让业务部门决定活动的优先级。
(4）可验证的数据质量非常重要。数据质量和商务智能成功的关键在于是否可以回答诸如“为什么总和为X?”、“这是如何计算的?”以及“数据从哪里来?”这样的基本问题。
(5)逐步地提供更多的价值。比较理想的是以2～3个月为周期,分阶段进行交付。
(6）透明度和自助服务。提供更多的关联环境信息(各种元数据)，用户能够据此派生出更多的价值。明智地披露处理过程的信息可以减少服务电话并提高用户满意度。
(7)一处适用,不等于处处适用。确保为每一个具体的客户找到了合适的工具和产品。
(8)从全局考虑并设计架构,但要从本地(局部)开始行动和创建。让宏观蓝图和终极愿景指导架构设计,但是以增量的方式聚焦于短期和基于项目的目标,逐步创建和交付成果。
(9)与其他的数据职能协作,特别是数据治理、数据质量和元数据管理等。
(10）以终为始。在商务智能环境中由业务优先级和最终数据交付范围驱动数据仓库内容的创建。数据仓库存在的目的就是为最终业务用户以商务智能的方式提供数据。
(11)在最后,而不是在开始时,进行总结和优化活动。根据性能的需要在原子级别的数据上增加聚集或汇总数据,但不是替换详细数据。
4.2 过程总结
数据仓库和商务智能管理职能的过程总结如表9.9所示。表中列举了数据仓库和商务智能管理中每一项活动的交付物、负责角色,批准角色以及贡献角色等。此表也在附录A.9中体现。
4.3 组织和文化问题
Q1:我无法得到CEO/CIO的支持。我应如何做?
试着发现他们的燃眉之急,调整你的项目并为这些问题提出解决方案。
Q2:如何平衡完成单个项目交付与创建数据仓库和商务智能项目群中可重用的数据和基础架构的总体目标之间的存在的矛盾?
a:一次一件的形式创建可重用的基础设施。
b:使用数据仓库总线矩阵作为沟通和推广工具。在项目上以项目为依据,就“给和取”进行协调,比如“其他项目已经开发的可重用组件,现有项目可直接使用并获益”和“现在有一个可重用组件需要此项目创建,然后将来的项目都可以受益”。
c:不要在所有的数据源上应用同样严格的条件,并投入相同的成本。对于独立的或是项目专用的数据可以适当放松要求。使用业务优先级以决定在何处应该采用额外的严格约束。简而言之,使用经典的80/20规则:80%的取值来源于其中20%的数据,确定并专注于这20%的数据。
文末说明：参考书籍来自《DAMA数据管理知识体系指南》
