第2章 数据仓库与OLAP技术

第2章数据仓库与OLAP

本章学习目标：掌握数据仓库的定义，四个基本特征理解数据集市的概念，与数据仓库区分了解数据仓库的体系结构掌握数据仓库中数据组织方式掌握数据处理过程熟悉元数据的概念、元数据管理的原理掌握OLAP的定义和特点熟悉OLAP的数据模型掌握OALP的多维数据分析熟悉数据仓库的设计，包括数据模型的设计、粒度、维度设计1第2章数据仓库与OLAP2.1数据仓库定义2.2数据仓库体系结构2.3数据组织结构和形式2.4数据抽取E、转换T和装载L（ETL）2.5元数据管理2.6OLAP的定义和特点2.7OLAP的数据模型2.8OALP的多维数据分析2.9数据仓库与OLAP范例22.1数据仓库定义WilliamH.Inmon：数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用于支持管理人员的决策。数据仓库之父--BillInmon3四个基本特征数据仓库的数据是面向主题的数据仓库的数据是集成的数据仓库的数据是非易失的数据仓库的数据是随时间不断变化的4面向主题主题（Subject）：特定的数据分析领域与目标。面向主题：为特定的数据分析领域提供数据支持。主题是一个抽象的概念，是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它对应企业中某一宏观分析领域所涉及的分析对象。5面向主题为特定数据分析领域提供的数据与传统数据库中的数据是有不同的。传统数据库中的数据是原始的、基础的数据，而特定分析领域数据则是需要对它们作必要的抽取、加工与总结而形成。数据仓库是面向分析、决策人员的主观要求的，不同的用户有不同的要求，同一个用户的要求也会随时间而经常变化，因此，数据仓库中的主题有时会因用户主观要求的变化而变化的。6面向主题示例例：一个面向事务处理的“商场”数据库系统，其数据模式如下采购子系统：订单（订单号，供应商号，总金额，日期）订单细则（订单号，商品号，类别，单价，数量）供应商（供应商号，供应商名，地址，电话）销售子系统：顾客（顾客号，姓名，性别，年龄，文化程度，地址，电话）销售（员工号，顾客号，商品号，数量，单价，日期）7面向事务库存管理子系统：领料单（领料单号，领料人，商品号，数量，日期）进料单（进料单号，订单号，进料人，收料人，日期）库存（商品号，库房号，库存量，日期）库房（库房号，仓库管理员，地点，库存商品描述）人事管理子系统：员工（员工号，姓名，性别，年龄，文化程度，部门号）部门（部门号，部门名称，部门主管，电话）8面向主题示例上述数据模式基本上是按照企业内部的业务活动及其需要的相关数据来组织数据的存储的，没有实现真正的数据与应用分离，其抽象程度也不够高。如果按照面向主题的方式进行数据组织，首先应该抽取主题，即按照管理人员的分析要求来确定主题，而与每个主题相关的数据又与有关的事务处理所需的数据不尽相同。9主题一：商品商品固有信息：商品号，商品名，类别，颜色等商品采购信息：商品号，供应商号，供应价，供应日期，供应量等商品销售信息：商品号，顾客号，售价，销售日期，销售量等商品库存信息：商品号，库房号，库存量，日期等10主题二：供应商供应商固有信息：供应商号，供应商名，地址，电话等供应商品信息：供应商号，商品号，供应价，供应日期，供应量等11主题三：顾客顾客固有信息：顾客号，顾客名，性别，年龄，文化程度，住址，电话等顾客购物信息：顾客号，商品号，售价，购买日期，购买量等12面向主题在每个主题中，都包含了有关该主题的所有信息，同时又抛弃了与分析处理无关或不需要的数据，从而将原本分散在各个子系统中的有关信息集中在一个主题中，形成有关该主题的一个完整一致的描述。面向主题的数据组织方式所强调的就是要形成一个这样一致的信息集合。不同的主题之间也有重叠的内容，但这种重叠是逻辑上的，而不是物理存储上的重叠；是部分细节的重叠，而不是完全的重叠。13面向主题每个主题所需数据的物理存储：多维数据库（MDDB—Multi-DimensionalDataBase）用多维数组形式存储数据。关系数据库。用一组关系来组织数据的存储，同一主题的一组关系都有一个公共的关键字，存放的也不是细节性的业务数据，而是经过一定程度的综合形成的综合性数据。14集成的集成性是指数据仓库中数据必须是一致的。数据仓库的数据是从原有的分散的多个数据库、数据文件和数据段中抽取来的，数据来源可能既有内部数据又有外部数据。数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，因此数据仓库中的数据必须从多个数据源中获取，这些数据源包括多种类型数据库、文件系统以及Internet网上数据等，它们通过数据集成而形成数据仓库中的数据。15集成的集成的方法：统一：消除不一致的现象综合：对原有数据进行综合和计算需要考虑的问题：数据格式计量单位数据代码含义混乱数据名称混乱16非易失的数据仓库中的数据是经过抽取而形成的分析型数据，不具有原始性，主要供企业决策分析之用，执行的主要是‘查询’操作，一般情况下不执行‘更新’操作。同时，一个稳定的数据环境也有利于数据分析操作和决策的制订。面向应用的事务数据库需要对数据进行频繁的插入、更新操作，而对于数据仓库中数据的操作仅限于数据的初始导入和记录查询。17随时间不断变化数据仓库以维的形式对数据进行组织，时间维是数据仓库中很重要的一个维度。并且数据仓库中的数据时间跨度大，从几年甚至到几十年，称为历史数据。数据仓库中的数据必须以一定时间段为单位进行统一更新。不断增加新的数据内容不断删去旧的数据内容更新与时间有关的综合数据18数据集市（DataMart）建立数据集市的原因数据仓库是一种反映主题的全局性数据组织。但是,全局性数据仓库往往太大，在实际应用中将它们按部门或个人分别建立反映各个子主题的局部性数据组织,它们即是数据集市。因此，有时我们也称它为部门数据仓库。例：在有关商品销售的数据仓库中可以建立多个不同主题的数据集市：商品采购数据集市库房使用数据集市商品销售数据集市19数据集市类型按照数据获取来源：独立型：直接从操作型环境获取数据。从属型：从企业级数据仓库获取数据。20建设途径从全局数据仓库到数据集市从数据集市到全局数据仓库21数据仓库VS数据集市数据仓库与数据集市的关系类似于传统关系数据库系统中的基表与视图的关系。数据集市的数据来自数据仓库，它是数据仓库中数据的一个部分与局部，是一个数据的再抽取与组织的过程。222.2数据仓库体系结构数据仓库系统：对进入数据仓库的原始数据完成抽取、转换、过滤、清洗等处理，最终进入数据仓库，以及对数据仓库中存储的数据进行更新、管理、使用、表现等的相关软件/工具进行集合，用以支持数据仓库应用或管理决策。232.2数据仓库体系结构数据仓库系统由数据仓库（DW）、仓库管理和分析工具三部分组成ORACLESYBASESQLServer文件……数据集市数据集市数据集市数据建模数据仓库元数据管理抽取……数据仓库系统示意图分析工具（OLAP、数据挖掘）24过程模型数据仓库管理系统元数据多维关系数据库多维数据库外部操作型数据数据抽取数据清洁数据装载管理平台报表查询工具数据挖掘工具OLAP工具25数据仓库管理层数据仓库管理层的功能就是完成数据仓库的定义，数据抽取、转换、装载，数据归档、备份、维护、恢复及元数据管理等。数据仓库的管理部分由数据仓库定义部件、数据获取部件、数据管理部件和元数据管理部件四部分组成26仓库管理－数据建模数据建模是建立数据仓库的数据模型。数据仓库的数据模型不同于数据库的数据模型在于：数据仓库只为决策分析用，不包含事务处理的数据。数据仓库的增加了时间属性数据。数据仓库增加了一些综合数据。数据仓库的数据建模是适应决策用户使用的逻辑数据模型。27仓库管理－元数据管理最基本的元数据相当于数据库系统中的数据字典。元数据定义了数据仓库有什么，指明了数据仓库中数据的内容和位置，刻画了数据的抽取和转换规则，存储了与数据仓库主题有关的各种商业信息，而且整个数据仓库的运行都是基于元数据的。数据源的元数据数据模型的元数据数据仓库映射的元数据数据仓库使用的元数据28仓库管理－数据处理异构数据源：企业内部数据存档的历史数据企业的外部数据。软硬件平台不一致ETL过程抽取（Extraction）转换（Transform）装载（Load）29分析工具－查询工具数据仓库的查询不是指对记录级数据的查询，而是指对分析要求的查询。一般包含：

可视化工具：以图形化方式展示数据，可以帮助了解数据的结构，关系以及动态性。30分析工具－多维分析工具

通过对信息的多种可能的观察形式进行快速、一致和交互性的存取，这样便利用户对数据进行深入的分析和观察。多维数据的每一维代表对数据的一个特定的观察视角，如时间、地域、业务等。31分析工具－数据挖掘工具从大量数据中挖掘具有规律性知识，需要利用数据挖掘（DataMining）工具。32数据仓库的运行结构两层数据仓库结构数据仓库数据元数据数据仓库服务器数据逻辑数据服务元数据文件服务客户端图形用户接口/表示逻辑查询规范数据分析报表格式总结数据访问33数据仓库的运行结构多层数据仓库结构多维数据服务器数据仓库数据元数据数据逻辑数据服务元数据文件服务数据仓库服务器应用服务器图形用户接口查询规范数据分析报表格式数据访问客户端过滤总结元数据多维视图数据访问342.3数据组织结构和形式典型的数据仓库的数据组织结构高度综合级：数据十分精炼，是一种准决策数据轻度综合级：从当前基本数据中提取出来，通常以较小的时间段(粒度)统计而成的数据，其数据量较细节及数据少得多当前细节级：存储最近时期的业务数据，反映当前业务的情况，数据量大，是数据仓库用户最感兴趣的部分早期细节级：存储过去的详细数据，反映真实的历史情况，这类数据随着时间增加，数据量很大，使用频率低，一般存储在转换介质(如磁带)中352.3数据组织结构和形式36数据粒度粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。粒度影响存放在数据仓库中的数据量的大小，同时影响数据仓库所能回答查询问题的细节程度，是设计数据仓库的一个最重要方面。粒度可以分为两种形式：按时问段综合数据的粒度按采样率高低划分的样本数据库。37粒度的一个例子能回答，但需要一定量的检索不能回答，缺少细节信息38粒度权衡39数据分割分割是指将数据分散到各自的物理单元中去，以便能分别独立处理，以提高数据处理效率。数据分割后的数据单元称为分片。分割之后，小单元内的数据相对独立，处理起来更快、更容易。分割是数据仓库中数据的第二个主要的设计问题分割问题的焦点不是该不该分割而是如何去分割的问题。40数据分割一般在进行实际的分析处理时，对于存在某种相关性的数据集合的分析是最常见的，如对某时间或某时段的数据的分析，对某一地区的数据的分析；对特定业务领域的数据的分析等，将其有这种相关性的数据组织在一起，就会提高效率。41数据分割的好处对当前细节数据进行分割的总体目的就是把数据划分成小的物理单元，为操作者和设计者在管理数据时提供更大的灵活性。小物理单元具有容易重构、自由索引、顺序扫描、容易重组、容易恢复和容易监控等优点。数据仓库的本质之一就是灵活的访问数据，大块数据达不到这个目的。42分割的标准数据分割的标准可以根据实际情况来确定，通常可选择:按日期、地域、业务领域或组织单位等来进行分割，按多个分割标准的组合来进行，一般情况分割标准总应包括日期项。43数据分割例子处理集A处理集B44分割的层次分割的层次一般分为系统层和应用层两层。系统层的分割由数据库管理系统和操作系统完成；应用层的分割由应用系统完成，在应用层上分割更有意义。45数据组织形式(选学)数据仓库中有多种数据组织形式：简单堆积数据结构轮转综合数据结构简单直接文件连续文件46简单堆积数据结构每日从数据库中提取并加工数据逐天积累。最简单最常用的数据组织形式47轮转综合数据结构简单逐日堆积数据的一种变种。数据用与前面相同的处理方法从操作型环境输入到数据仓库环境中，只是在轮转综合文件中的数据才被输入到不同的结构形式中。每日事物处理每日综合天周月年123456712345。。。。。。48简单堆积VS轮转综合轮转综合数据结构与数据的简单堆积结构相比，仅处理非常少的数据单元。49简单直接文件数据仅仅是从操作型环境拖入数据仓库环境中，并没有任何累积。是间隔一定时间的操作型数据的一个快照。不是在每天的基础上组织的，而是以较长时间为单位的，比如一个星期或一个月。50连续文件通过两个连续的简单直接文件，可以生成另一个连续文件连续文件也可以通过把一个快照追加到一个以前生成的连续文件上来创建51连续文件连续文件也可以通过把一个快照追加到一个以前生成的连续文件上来创建52数据存储虚拟存储方式基于关系表的存储方式多维数据库组织53虚拟存储方式没有专门的数据仓库数据存储，数据仓库中的数据仍然在源数据库中。只是根据用户的多维需求及形成的多维视图临时在源数据库中找出所需要的数据，完成多维分析。优点：组织方式简单、花费少、使用灵活；缺点：只有当源数据库的数据组织比较规范、没有数据不完备及冗余，同时又比较接近多维数据模型时，虚拟数据仓库的多维语义才容易定义。而在一般的数据库应用中，这很难做到。54基于关系表的存储方式将数据仓库的数据存储在关系数据库的表结构中，在元数据的管理下完成数据仓库的功能。实体关系（ER）模型一般用于关系型数据库设计，而数据仓库采用星型雪花型事实星座55基于关系表的存储方式关系数据库一般采用二维数据表的形式来表示数据，一个维是行，另一个维是列，行和列的交叉处就是数据元素。关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。数据仓库是多维数据库，它扩展了关系数据库模型，以星形架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但不管是哪一种架构，维度表、事实表和事实表中的量度都是必不可少的组成要素。56星型模式数据仓库中包含（1）一个大的包含大批数据和不冗余的事实表（中心表）；（2）一组小的附属表，称为维表。每维一个。事实表中每条元组都含有指向各个维表的外键和一些相应的测量数据，事实表的记录数量很多，维表中记录的是有关这一维的属性。57星型模式星形模型可以采用关系型数据库结构，模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。维度表中的对象通过事实表与另一维度表中的对象相关联，这样就能建立各个维度表对象之间的联系。58星型模式事实表主要包含了描述特定商业事件的数据，即某些特定商业事件的度量值。一般情况下，事实表中的数据不允许修改，新的数据只是简单地添加进事实表中，维度表主要包含了存储在事实表中数据的特征数据。每一个维度表利用维度关键字通过事实表中的外键约束于事实表中的某一行，实现与事实表的关联，这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。这种结构使用户能够很容易地从维度表中的数据分析开始，获得维度关键字，以便连接到中心的事实表，进行查询。59星型模式示例时间键产品键地区键sales(事实表）销售量销售价time时间键年季度月星期天产品键产品类产品名型号itemlocation地区键国家省市维表60雪花模式雪花模型是对星形模型的扩展，每一个维度都可以向外连接多个详细类别表。在这种模式中，维度表除了具有星形模型中维度表的功能外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的。61雪花模式示例time时间键年季度月星期天产品键产品类产品名型号item时间键产品键地区键sales(事实表）销售量销售价location地区键国家省键省键省名市键市键市名provincecity62星型模式VS雪花模式雪花模式的维表可能是规范化的，以便减少冗余。这种表易于维护，并节省存储空间。实际上，与巨大的事实表相比，这种空间的节省可以忽略。由于执行查询需要更多的连接操作，雪花结构可能降低浏览的性能。在数据仓库设计中，雪花模式不如星型模式流行。63事实星座模式一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模型(galaxyschema)。64事实星座模式示例time时间键年季度月星期天产品键产品类产品名型号item时间键产品键地区键sales(事实表）销售量销售价location地区键国家省市ship（事实表）产品键时间键起运点终止点运价65数据仓库的数据追加（选学）时标法前后映像文件方法DELTA文件日志文件66时标法基本思想：为记录数据增加一个时间标记。如果数据含有时标，对新插入或更新的数据记录，在其上添加更新时的时标，那么只需根据时标判断即可。但并非所有数据库中的数据都含有时标。67前后映像文件方法在抽取数据前后对数据库各做一次快照，然后比较两幅快照从而确定新数据。它占用大量资源，对性能影响极大，因此无实际意义。68DELTA文件DELTA文件视图从能够感知数据变化的应用程序来生成追加文件利用DELTA文件效率很高，它避免扫描整个数据库。但因应用系统常由不同的软件开发商开发，生成DELTA文件的应用并不普遍。69日志文件日志是DMBS的固有机制系统日志能把数据库服务器所执行的所有操作详细记录下来，通过分析日志获取数据变化情况。它还具有DELTA文件的优越性质，提取数据只要局限日志文件即可，不用扫描整个数据库。固有机制，不影响OLTP性能。702.4数据抽取、转换和加载数据仓库需要将这些源数据经过抽取、转换和装载的过程，存储到数据仓库的数据模型中。ETL过程抽取（Extraction）转换（Transform）装载（Load）712.4.1数据抽取确认数据源数据抽取技术72确认数据源列出对事实表的每一个数据项和事实列出每一个维度属性对于每个目标数据项，找出源数据项一个数据元素有多个来源，选择最好的来源确认一个目标字段的多个源字段，建立合并规则确认一个目标字段的多个源字段，建立分离规则确定默认值检查缺失值的源数据73数据抽取技术当前值：源系统中存储的数据都代表了当前时刻的值。当商业交易时，这些数据是会发生变化的。周期性的状态：这类数据存储的是每次发生变化时的状态。例如，对于每一保险索赔，都经过索赔开始、确认、评估和解决等步骤，都要考虑有时间说明。742.4.2数据转换T数据转换的基本功能数据转换类型数据整合和合并如何实施转换75数据转换的基本功能选择：从源系统中选择整个记录或者部分记录。

分离/合并：对源系统中的数据进行分离操作或者合并操作。转化：对源系统进行标准化和可理解化。汇总：将最低粒度数据进行汇总。清晰：对单个字段数据进行重新分配和简化。76数据转换类型（1）格式修正（2）字段的解码（3）计算值和导出值（4）单个字段的分离（5）信息的合并（6）特征集合转化（7）度量单位的转化（8）关键字重新构造（9）汇总（10）日期/时间转化77数据整合和合并数据整合和合并是将相关的源数据组合成一致的数据结构，装入数据仓库。实体识别问题。数据来源于多个不同的客户系统，对相同客户可能分别有不同的键码，将它们组合成一条单独的记录。多数据源相同属性不同值的问题。不同系统中得到的值存在一些差别，需要给出合理的值。78如何实施转换自己编写程序实现数据转换使用转换工具792.4.3数据装载L数据装载方式数据装载类型80数据装载方式基本装载。按照装载的目标表，将转换过的数据输入到目标表中去。追加。如果目标表中已经存在数据，追加过程在保存已有数据的基础上增加输入数据。

破坏性合并。用新输入数据更新目标记录数据。

建设性合并。保留已有的记录，增加输入的记录，并标记为旧记录的替代。81数据装载类型初始装载。这是第一次对整个数据仓库进行装载。

增量装载。由于源系统的变化，数据仓库需要装载变化的数据。完全刷新。这种类型的数据装载用于周期性重写数据仓库。822.4.4数据处理的有关讨论数据库中的空缺值不一致的数据由于某种原因的不一致需统一（比如英制与公制）样本空间的大小与分析无关的数据不要装入数据仓库数据离散化在必要的情况下将连续的数据变换成离散值。比如年龄按10岁分段，收入按1000分段等数据规范化83数据库中的空缺值空缺的数据会影响数据挖掘的质量，所以应该处理忽略该元组问题：若缺少的数据的元组太多，则性能非常差人工填写空缺值问题：缺很多值时不可行使用一个全局常量填空问题：但由于该常量太多，数据挖掘程序可能会错误的认为是一个有趣的概念。使用属性的平均值填充空缺值使用与给定元组属同一类的所有样本的平均值使用最可能的值填充空缺值84样本空间的大小如抽取一部分数据进行分析同在整个数据集合上进行分析的结果是一样的，则取一部分数据进行分析时空效率就高得多。（采用随机抽样、等间隔抽样、聚类后在同一类中抽取等）85数据规范化最大-最小规范化:对原始数据进行线性变换。假定minA和maxA分别为属性A的最小和最大值，则:例：假定收入属性的最小与最大分别是12000和98000，现在想映射到区间[0.0，1]，则86数据规范化z-score规范化（零-均值规范化）例：假定收入属性的平均值和标准方差分别为54000和16000，使用z-score规范化。872.4.5ETL工具数据转换引擎代码生成器通过复制捕获数据882.5元数据管理元数据是关于数据的数据，是数据仓库环境中一个重要方面。元数据在数据仓库的上层，并且记录数据仓库中对象的位置。典型地，元数据记录：程序员所知的数据结构。DSS分析员所知的数据结构。数据仓库的源数据。数据加入数据仓库时的转换。数据模型。数据模型和数据仓库的关系。抽取数据的历史记录。89元数据分类数据源的元数据数据模型的元数据数据仓库映射的元数据数据仓库使用的元数据90数据源的元数据这类元数据是对不同平台上的数据源的物理结构和含义的描述。具体为：数据源中所有物理数据结构，包括所有的数据项及数据类型。所有数据项的业务定义。每个数据项更新的频率，以及由谁或那个过程更新的说明。每个数据项的有效值。91数据模型的元数据这组元数据描述了数据仓库中有什么数据以及数据之间的关系，它们是用户使用管理数据仓库的基础。这种的元数据可以支持用户从数据仓库中获取数据。92数据模型元数据示例例如，雇员与技能之间的关系93数据仓库映射的元数据这类元数据是数据源与数据仓库数据间的映射。当数据源中的一个数据项与数据仓库建立了映射关系，就应该记下这些数据项发生的任何变换或变动。即用元数据反映数据仓库中的数据项是从哪个特定的数据源填充的，经过那些转换，变换和加载过程。94数据仓库映射的元数据示例一个数据的抽取要经过许多步骤。如图所示：源数据与目标数据之间的映射（1）抽取工作（2）抽取工作步骤（3）抽取表映射（4）抽取属性映射（5）记录筛选规则95数据仓库使用的元数据这类元数据是数据仓库中信息的使用情况描述。数据仓库的用户最关心的是两类元数据：（1）元数据告诉数据仓库中有什么数据，它们从哪里来。即如何按主题查看数据仓库的内容。（2）元数据提供已有的可重复利用的查询语言信息。如果某个查询能够满足他们的需求，或者与他们的愿望相似，他们就可以再次使用那些查询而不必从头开始编程。关于数据仓库使用的元数据能帮助用户到数据仓库查询所需要的信息，用于解决企业问题962.6OLAP的定义和特点60年代，关系数据库之父E.F.Codd提出了关系模型，促进了联机事务处理(OLTP)的发展(数据以表格的形式而非文件方式存储)。1993年，E.F.Codd提出了多维数据库和多维分析的概念，即OLAP。97OLTPVS.OLAP面向操作人员，支持日常操作面向决策人员，支持管理需要面向应用，事务驱动面向分析，分析驱动一次处理的数据量小一次处理的数据量大可更新 不可更新，但周期性刷新当前值数据历史数据细节性数据 综合性和提炼性数据原始数据导出数据OLTP数据OLAP数据98OLAP基本思想联机分析处理（OnLineAnalysisProcessing，OLAP）在数据仓库系统中，联机分析处理是重要的数据分析工具。OLAP的基本思想是从多方面和多角度以多维的形式来观察企业的状态和了解企业的变化。OLAP是独立于数据仓库的一种技术概念当OLAP与数据仓库结合时，OLAP的数据源为数据仓库，数据仓库的大量数据是根据多维方式组织的。99OLAP特点OLAP在以数据仓库为数据源时，它有两个特点：在线性（OnLine）：由客户机/服务器这种体系结构来完成的；多维分析：这也是OLAP的核心所在。1002.6OLAP的定义和特点联机分析处理（OLAP）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。这些信息是从原始数据转换过来的，按照用户的理解，它反映了企业真实的方方面面。（OLAP理事会）101OLAP的简单定义联机分析处理是共享多维信息的快速分析。体现了四个特征：（1）快速性：用户对OLAP的快速反应能力有很高的要求。（2）可分析性：OLAP系统应能处理任何逻辑分析和统计分析。（3）多维性：系统必须提供对数据分析的多维视图和分析。（4）信息性：OLAP系统应能及时获得信息，并且管理大容量的信息。102OLAP目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。103OLAP准则

1993年，E.F.Codd提出OLAP的12条准则，其主要的准则有：多维数据分析；客户/服务器结构；多用户支持；一致的报表性能等。104多维数据分析企业的数据空间本身就是多维的。因此OLAP的概念模型也应是多维的。用户可以对多维数据模型进行切片、切块、旋转坐标或进行多维的联合（概括和聚集）分析。105客户/服务器体系结构OLAP是建立在客户/服务器体系结构上的。多维数据库服务器能够被不同的应用和工具所访问。

客户端负责应用逻辑及用户界面。106多用户支持当多个用户要在同一分析模式上并行工作，OLAP工具应能够提供并发访问等功能。107一致的报表性能报表必须充分反映数据分析模型的多维特征，并可按用户需要的方式来显示它报表操作不应随维数增加而削弱，即当数据维数和数据的综合层次增加时，提供的报表能力和响应速度不应该有明显的降低。108OLAP基本概念变量：从现实系统抽象出来的，用于描述数据的实际含义，即描述数据“是什么”维：是与某一事件相关的因素在关系模型的抽象，是人们观察数据的特定角度。如产品维、顾客维、时间维等。维的层次性：是由观察数据细致程度不同造成的。如日、月、季、年是时间维的层次。维的取值：即维的成员。如“某年某月某日”是时间维的一个成员。109OLAP基本概念维的分类：按照一定的划分标准对维的所有取值集合的一个分类划分，用于数据钻取和聚合。如上半年、下半年是对时间维的划分。事实：不同维度在某个取值下的交叉点，是对事件的度量。如（牙膏，上海，1998年12月，批发，销售额为100000）多维数据立方体：一个事物可以从不同的角度进行观察，多个角度也就产生了多个维，那么在空间上就构成了一个多维数据立方体。可以表示为（维1，维2，…，维n，度量变量）110维的例子一个电子公司的销售一般从三个方面分析销售额：时间：在某一段时间内的销售情况，其度量为（年、季度、月、旬、天）地区：在某个地区的销售情况，度量可分为（地区、国家、省、市）产品：某类或某型号产品的销售情况，度量可分为（类别、型号等）此处，（时间，地区，产品）就构成了三个维。维有层次结构，可以在某个层上察看数据。111维的例子地区的层次全国江苏北京上海苏州市扬州市宝应县112维的例子正好构成一个数据立方体，可以有更高阶的维，但仍然称为数据立方体。时间地区产品原点113OLAP数据立方体的计算（物化）数据立方体的个数有产品(type)、城市(city)、日期(date)三个维，则：alldatetypecitytypedatecitydatecitytypecitytypedate0-D（顶点）方体1-D方体2-D方体3-D（基本）方体114OLAP数据立方体的计算（物化）一般，若有n个维，则立方体个数是{(city,item,date),(city,item),(city,date),(item,date),(city),(item),(date),all}all表示不对任何维分组，这组形成了该数据立方体的方体格115OLAP数据立方体的计算（物化）实际维上有分层，如（年、季度、月、星期、日），所以实际的立方体个数是极大的。所以，实时计算的工作量极大，但全部事先计算，则存储量又极大。方体的选择计算：不物化：即不预先计算任何“非基本”方体全物化：预先计算所有的方体部分物化：在整个可能的方体集中，有选择地物化一个适当的子集在OLAP中一般采用部分物化，应考虑三个因素:(1)确定要物化的方体子集；(2)利用查询处理时物化的方体；(3)在装入和刷新时，有效地更新物化的方体。1162.7OLAP的数据模型2.7.1MOLAP数据模型2.7.2ROLAP数据模型2.7.3MOLAP与ROLAP的比较2.7.4HOLAP数据模型1172.7.1MOLAP的数据模型MOLAP是基于多维数据库存储方式建立的OLAP；表现为“超立方”结构，采用类似于多维数组的结构。例如，二维MDDB（数组，即矩阵）的数据组织见下表北京上海广州衣服600700500鞋800900700帽子100200801182.7.2ROLAP数据模型ROLAP是基于关系数据库的OLAP。它是一个平面结构，用关系数据库表示多维数据时，采用星型模型。产品名地区销售量衣服北京600衣服上海700衣服广州500鞋北京800鞋上海900鞋广州700帽子北京100帽子上海200帽子广州801192.7.3MOLAP与ROLAP的比较1.数据存取速度2.数据存储的容量3.多维计算的能力4.维度变化的适应性5.数据变化的适应性6.软硬件平台的适应性7.元数据管理1201.数据存取速度ROLAP服务器需要将SQL语句转化为多维存储语句，临时“拼合”出多维数据立方体。因此，ROLAP的响应时间较长。

MOLAP在数据存储速度上性能好，响应速度快。1212.数据存储的容量ROLAP使用的传统关系数据库的存储方法，在存储容量上基本没有限制。MOLAP通常采用多平面叠加成立体的方式存放数据。MOLAP受操作系统平台中文件大小的限制，当数据量超过操作系统最大文件长度时，需要进行数据分割。多维数据库的数据量级难以达到TB级(只能10~20G）1223.多维计算的能力MOLAP能够支持高性能的决策支持计算。ROLAP无法完成多行的计算和维之间的计算。1234.维度变化的适应性MOLAP增加新的维度，则多维数据库通常需要重新建立。ROLAP对于维表的变更有很好的适应性。1245.数据变化的适应性当数据频繁的变化时，MOLAP需要进行大量的重新计算，甚至重新建立索引乃至重构多维数据库。在ROLAP中灵活性较好，对于数据变化的适应性高。1256.软硬件平台的适应性ROLAP对软硬件平台的适应性很好MOLAP相对较差。1267.元数据管理目前在元数据的管理，MOLAP和ROLAP都没有成形的标准。127MOLAPVSROLAPMOLAPROLAP固定维可变维维交叉计算多维视图行级计算超大型数据库读-写应用维数据变化速度快数据集市数据仓库1282.7.4HOLAP数据模型HOLAP（HybridOLAP），即混和型OLAP介于MOLAP和ROLAP之间。在HOLAP中，对最常用的维度和维层次，使用多维数据表来存储，对于用户不常用的维度和数据，采用ROLAP星型结构来存储。HOLAP得宜于ROLAP的可伸缩性,和MOLAP的快速计算。（如MSSQLSERVER)在HOLAP的多维数据表中的数据维度少于MOLAP中的维度表，数据存储容量也少于MOLAP方式。HOLAP在数据存取速度上又低于MOLAP。1292.8OALP的多维数据分析2.8.1OLAP的基本操作2.8.2广义OLAP功能（选学）2.8.3多维数据分析实例1302.8.1OLAP的基本操作数据切片：多维数据是由多个维度组成的，如果在某个维度上选定一个取值，则多维数据从n维下降成n-1维数据切块：将完整的数据立方体切取一部分数据而得到的新的数据立方体。数据钻取(下钻)：从较高的维度层次下降到较低的维度层次上来观察多维数据数据聚合(上卷)：对数据进行高层次综合的操作数据旋转：改变维度的位置关系，使最终用户可从其他视角来观察多维数据。131基本操作示例

以“城市、产品、时间”三维数据为例，如下图13220294035504138372321393426273632时间产品地区一季度二季度三季度四季度北京上海南京广州VCD手机电脑空调69（北京，二季度，电脑的销售额）1331.切片对三维数据，通过“切片”，分别从产品和城市等不同的角度观察销售情况：广州上海电视机电冰箱134切片示例120294035504138372321393426273632时间产品地区一季度二季度三季度四季度北京上海南京广州VCD手机电脑空调切片(slice)：

地区=“北京”意义：北京地区四个季度空调、电脑、手机、VCD的销售金额135切片示例220294035504138372321393426273632时间产品地区一季度二季度三季度四季度北京上海南京广州VCD手机电脑空调切片：产品=“空调”意义：空调产品在四个季度中各地区的销售金额1362.切块（1）在多维数组的某一个维上选定某一区间的维成员的操作切块可以看成是在切片的基础上，确定某一个维成员的区间得到的片段，也即由多个切片叠合起来。（2）选定多维数组的一个三维子集的操作在多维数组（维1，维2，……，维n，变量）中选定3个维，维i、维j、维k，在这3个维上分别取一个区间，或任意维成员，而其它维都取定一个维成员。137切块示例2029403550413837时间产品地区一季度二季度三季度四季度南京广州手机空调分块(dice)：地区=“南京”

AND“广州”产品“空调”AND“手机”1383.钻取钻取有向下钻取（drilldown）和向上钻取（drillup）操作。向下钻取是使用户在多层数据中能通过导航信息而获得更多的细节性数据。向上钻取获取概括性的数据。1392029403550413837时间产品地区一季度二季度三季度四季度南京广州手机空调下钻（drill_down)：按时间分到月、甚至天为单位668817161413时间南京广州手机8131113141413121610101513111016空调123456789101112下钻140上卷（roll_up)：按时间上卷到半年为单位2029403550413837时间产品地区一季度二季度三季度四季度南京广州手机空调时间产品南京广州手机空调49759175上半年下半年上卷1414.旋转通过旋转可以得到不同视角的数据。旋转操作相当于平面数据将坐标轴旋转。例如，旋转可能包含了交换行和列，或是把某一个行维移到列维中去。或是把页面显示中的一个维和页面外的维进行交换（令其成为新的行或列中的一个）142旋转示意图时间维产品维产品维时间维行列交换旋转以改变显示布局时间维产品维地区维时间维地区维产品维143旋转示例旋转前的数据旋转后的数据1442.8.2广义OLAP功能（选学）基本代理操作数据分析模型商业分析模型145基本代理操作当系统处于某种特殊状态时“代理”提醒分析员。（1）示警报告定义一些条件，一但条件满足，系统会提醒分析员去做分析。如每日报告完成或月定货完成等通知分析员作分析。（2）时间报告按日历和时钟提醒分析员。（3）异常报告

当超出边界条件时提醒分析员。如销售情况已超出预定义阈值的上限或下限时提醒分析员。146数据分析模型（1）绝对模型通过比较历史数据值或行为来描述过去发生的事实。绝对模型只能对历史数据进行比较，并且利用回归分析等一些分析方法得出趋势信息。147数据分析模型（2）解释模型利用系统已有的多层次的综合路径层层细化，找出事实发生的原因。假设今年销售量下降，那么解释模型应当能找出原因，即下滑与时间、地区、商品及销售渠道四者中的何种因素有关。148数据分析模型（3）思考模型说明在一维或多维上引入一组具体变量或参数后将会发生什么。例如该公司决策者为了了解某商品的销售量是否与顾客的年龄有关，引入了行变量－年龄，即在当前的多维视图上增加了顾客的年龄维。149数据分析模型（4）公式模型该模型表示在多个维上，需要引入哪些变量或参数，以及引入后所产生的结果。公式模型自动完成上述变量引入工作，从而最终找出与销量有关的全部因素，并给出了引入后的结果。150商业分析模型（1）分销渠道的分析模型（2）客户利润贡献度模型（3）客户关系（信用）优化模型（4）风险评估模型151（1）分销渠道的分析模型通过客户、渠道、产品或服务三者之间的关系，了解客户的购买行为、客户和渠道对业务收入的贡献、哪些客户比较喜好由什么渠道在何时和银行打交道。为此，银行需要建立客户购买倾向模型和渠道喜好模型等。152（2）客户利润贡献度模型通过该模型能了解每一位客户对银行的总利润贡献度。知道哪些利润高的客户需要留住，采用什么方法留住客户，交叉销售改善客户的利润贡献度，哪些客户应该争取，完成个性化服务。153（3）客户关系（信用）优化模型银行对客户的每一笔交易中，知道客户需要什么产品或服务，例如，定期存款是希望退休养老使用，申请信用卡需要现金消费，询问放贷利息需要住房贷款等。通过模型计算，主动地对客户沟通并进行交叉销售，达到留住客户和增加利润的目标。154（4）风险评估模型模拟风险和利润间的关系，建立风险评估的数学模型，在满足高利润、低风险客户需求的前提下，达到银行收益的极大化。1552.9数据仓库与OLAP范例

设计一个数据仓库首先要面对的是哪些是事实数据，而哪些是维度数据。在一个大型的OLTP系统中字段众多，要在其中决定事实与维度数据并不容易。识别事实与维度设计事实表设计维度表156识别事实与维度1）在整个OLTP系统中搜索最基本的交易，它们极可能是事实数据2）决定搜索每一个事实数据的外键，它们极可能是维度数据3）检验每一个可能事实数据的字段，确定它不是嵌入在事实数据中的维度数据4）检验每一个可能维度数据的字段，确定它不是嵌入在维度数据中的事实数据157设计事实表一个事实表是由OLTP系统转入而生成出来的，数据仓库的数据并不包含OLTP系统中所有的数据。在设计一个事实表的时候，考虑下面的事项：1）为每一项功能决定数据仓库的时距（十年，五年还是其它？）2）为每一项功能决定其采用原则3）决定在事实表中应包含哪些字段4）尽量缩小事实表中字段的大小5）将时间因素加入事实表158设计维度表在设计之初要确定不会更新数据的主键，否则一旦修改，事实表要一起更新。维度表常是违反正规化的。时间一般都是一个事实表的维度159例子－Northwind数据库一个贸易公司商业所使用的数据库（SQLServer2000的范例）数据库架构（1）Categories表：存储产品所有类型的相关信息字段名功能描述CategoryID产品类型的识别码CategoryName产品名称Description产品类型描述Picture产品图片160数据库架构（2）CustomerDemo表：存储了顾客所属类别信息（3）CustomerDemographics表：存储了顾客类别的描述信息字段名功能描述CustomerID顾客识别码CustomerTypeID顾客类别识别码字段名功能描述CustomerTypeID顾客类别识别码CustomerDesc顾客类别的描述161数据库架构（4）Customers表：存储了顾客所有相关信息字段名功能描述CustomerID顾客识别码CustomerName顾客姓名Address地址City城市Region地区PostalCode邮政编码Country国家Phone电话Fax传真CompanyName顾客单位（公司）162数据库架构（5）Employees表：存储了员工所有相关信息Extension公司内部分机号Photo照片Notes员工信息描述字段名功能描述EmployeeID员工识别码EmployeeName员工姓名BirthDate出生年月HireDate雇佣日期Address地址City城市Region地区PostalCode邮政编码HomePhone家庭电话Title员工职务163数据库架构（6）EmployeesTerritories表：存储了员工所负责的区域（7）Territories表：存储了员工所负责的区域的基本数据字段名功能描述EmployeeID员工识别码TerritoryID员工负责区域识别码字段名功能描述TerritoryID区域识别码TerritoryDescription区域描述RegionID所属地区识别码164数据库架构（8）Region：存储了员工所负责的区域所属区的基本数据（9）OrderDetail：存储订单下的单项商品信息字段名功能描述RegionID地区识别码RegionDescription地区名称字段名功能描述OrderID订单识别号ProductID产品识别号UnitPrice产品单价Quantity订购数量Discount折扣165数据库架构（10）Orders：存储订单的全部信息Feight货运价格ShipName接受货品人姓名ShipAddress送货地址字段名功能描述OrderID订单识别号CustomerID顾客识别号EmployeeID承办员工识别号OrderDate订购日期RequiredDate订单的需要日期ShippedDate送货日期ShipVia送货公司识别码ShipCity送货城市ShipRegion送货地区ShipPostalCode送货区邮政编码166数据库架构（11）Shippers：存储了货运公司的相关信息字段名功能描述ShipperID货运公司识别号CompanyName货运公司名称Phone货运公司电话号码167数据库架构（12）Products：产品的相关信息UnitOnOrder一次订货量ReorderLevel重新订货最低库存量Discontinued是否停售字段名功能描述ProductID产品识别号ProductName产品名称SupplierID供货商识别号CategoryID产品分类识别号QuantityPerUnit每单位数量UnitPrice单价UnitInStock库存量168数据库架构（13）Suppliers：供货商的相关信息phone电话Fax传真HomePage公司网址字段名功能描述SupplierID供货商识别号CompanyName公司名称ContactName联络人姓名Address地址City城市Region地区PostalCode邮政编码169表间关系Employeer员工表EmployeerTerritoriesTerritories区域表Region地区表Customer顾客表CustomerCustomorDemo顾客类别CustomorDemographics顾客描述Orders订单表OrdersDetail订单详情表Shippers货运公司Products产品表Categories产品类别表Suppliers供货商表170需求分析经过调查后，假定得到了下面的需求：希望能够针对每一个员工做销售业绩分析希望能够针对每一产品做销售分析希望能够针对每一分类产品做销售分析希望能够针对每一供货商做销售分析希望能够针对每一顾客做销售分析希望能够针对每一地区的顾客做销售分析希望能够针对每一城市的顾客做销售分析希望能够针对年、季、月做销售分析171识别事实和维度经归纳发现，索引基准点为5类：顾客员工产品供货商时间172分析过程Employeer员工表EmployeerTerritoriesTerritories区域表Region地区表Customer顾客表CustomerCustomorDemo顾客类别CustomorDemographics顾客描述Orders订单表OrdersDetail订单详情表Shippers货运公司Products产品表Categories产品类别表Suppliers供货商表8个记录0个记录0个记录91个记录9个记录49个记录2155个记录830个记录4个记录53个记录29个记录3个记录77个记录货运在分析中不出现，可去掉173分析过程Employeer员工表EmployeerTerritoriesTerritories区域表Region地区表Customer顾客表CustomerCustomorDemo顾客类别CustomorDemographics顾客描述Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表8个记录0个记录0个记录91个记录9个记录49个记录2155个记录830个记录4个记录53个记录29个记录77个记录员工负责的区域及其区域所属地区与分析无关，去掉三个表174Employeer员工表Customer顾客表CustomerCustomorDemo顾客类别CustomorDemographics顾客描述Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表8个记录0个记录0个记录91个记录9个记录2155个记录830个记录29个记录77个记录顾客类别及描述在分析中不会感兴趣，而且为0个记录，所以也不考虑分析过程175Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表字段名功能描述CategoryID产品类型的识别码CategoryName产品名称Description产品类型描述Picture产品图片分析过程176Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表UnitOnOrder一次订货量ReorderLevel重新订货最低库存量Discontinued是否停售字段名功能描述ProductID产品识别号ProductName产品名称SupplierID供货商识别号CategoryID产品分类识别号QuantityPerUnit每单位数量UnitPrice单价UnitInStock库存量分析过程177Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表phone电话Fax传真HomePage公司网址字段名功能描述SupplierID供货商识别号CompanyName公司名称ContactName联络人姓名Address地址City城市Region地区PostalCode邮政编码分析过程178Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表HomePhone家庭电话Extension公司内部分机号Photo照片Notes员工信息描述字段名功能描述EmployeeID员工识别码EmployeeName员工姓名BirthDate出生年月HireDate雇佣日期Address地址City城市Region地区PostalCode邮政编码Title员工职务分析过程179Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表字段名功能描述CustomerID顾客识别码CustomerName顾客姓名Address地址City城市Region地区PostalCode邮政编码Country国家Phone电话Fax传真CompanyName顾客单位（公司）分析过程180Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表Feight货运价格ShipName接受货品人姓名ShipAddress送货地址字段名功能描述OrderID订单识别号CustomerID顾客识别号EmployeeID承办员工识别号OrderDate订购日期RequiredDate订单的需要日期ShippedDate送货日期ShipVia送货公司识别码ShipCity送货城市ShipRegion送货地区ShipPostalCode送货区邮政编码分析过程181Employeer员工表Customer顾客表Orders订单表OrdersDetail订单详情表Products产品表Categories产品类别表Suppliers供货商表字段名功能描述OrderID订单识别号ProductID产品识别号UnitPrice产品单价Quantity订购数量Discount折扣分析过程182识别事实与维度数据顾客维度员工维度供应商维度时间维度产品维度183产品维度Categories:产品类别描述Products:产品类别描述字段名功能描述CategoryID产品类型的识别码CategoryName产品名称CategoryID,CategoryName:维度数据，属于产品维度字段名ProductIDProductName产品名称SupplierID供货商识别号CategoryID产品分类识别号QuantityPerUnitUnitPrice功能描述产品识别号每单位数量单价每单位数量、单价是同公司运营有关的数据，不随时间改变，也不会以每单位数量和单价为基准来分析数据，所以是事实数据184顾客维度Customers:顾客描述字段名功能描述CustomerID顾客识别码CustomerName顾客姓名City城市Region地区Country国家CustomerID、CustomerName:属于顾客维度数据City、Region、Country:属于顾客维度数据，且具有层次关系185员工维度Employees:员工描述字段名功能描述EmployeeID员工识别码Name员工姓名Title员工职务都是维度数据，属于员工维度186事实数据Orders:订单描述字段名功能描述OrderID订单识别号CustomerID顾客识别号EmployeeID承办员工识别号OrderDate订购日期订单号是因公司经营而产生，不随时间变化，不会以订单号为基准分析，所以是事实数据CustomerID:顾客维度数据EmployeeID:员工维度数据OrderDate:时间维度数据187事实数据OrdersDetail:产品项描述字段名功能描述OrderID订单识别号ProductID产品识别号UnitPrice产品单价Quantity订购数量Discount折扣随公司运营产生的有订单号、产品单价、订购数量和折扣，它们不随时间变化。也不会以订单号、产品单价、订购数量和折扣为基准分析数据，所以是事实数据。ProductID是产品维度数据188设计事实表事实表名称：Sales数据源：Orders,OrderDtails,Employees,Products,Suppliers,Customers索引：EmployeeID,来自Employees表ProcutID,来自Products表CustomerID,来自Customers表OrderDate,来自Orders表事实表度量值字段：UnitPrice,来自OrderDetails表Total=Quantity*UnitPrice*(1.0-Discount)Quantity,来自OrderDetails表Dis