商务智能（第5版）课件第3章 数据仓库

事务型处理事务型处理：即操作型处理，是指对数据库的联机操作处理OLTP。事务型处理是用来协助企业对响应事件或事务的日常商务活动进行处理。它是事件驱动、面向应用的，通常是对一个或一组记录的增、删、改以及简单查询等（大量、简单、重复和例行性）。在事务型处理环境中，数据库要求能支持日常事务中的大量事务，用户对数据的存取操作频率高，但每次操作处理的时间短。分析型处理分析型处理：用于管理人员的决策分析，例如决策支持系统（DSS）、经理信息系统（EIS）和多维分析等。它帮助决策者分析数据以观察趋向、判断问题。分析型处理经常要访问大量的历史数据，支持复杂的查询。分析型处理过程中经常用到外部数据，这部分数据不是由事务型处理系统产生的，而是来自于其他外部数据源。分析型处理事务型处理和分析型处理具有不同的特征，主要体现在以下几个方面处理性能数据集成数据更新数据时限数据综合事务型处理数据和分析型处理数据的区别特性OLTPOLAP特征面向用户功能DB设计数据汇总视图工作单位存取关注操作访问记录数用户数DB规模优先度量操作处理事务办事员、DBA、数据库专业人员日常操作基于E-R，面向应用当前的；确保最新原始的，高度详细详细，一般关系短的、简单事务读/写数据进入主关键字上索引/散列数十个数千100MB到GB高性能，高可用性事务吞吐量信息处理分析知识工人（如经理、主管、分析员）长期信息需求，决策支持星形/雪花，面向主题历史的；跨时间维护汇总的，统一的汇总的，多维的复杂查询大多为读信息输出大量扫描数百万数百100GB到TB高灵活性，端点用户自治查询吞吐量，响应时间数据库系统的局限性数据库适于存储高度结构化的日常事务细节数据，而决策型数据多为历史性、汇总性或计算性的数据，多表现为静态数据，不需直接更新，但可周期性刷新。决策分析型数据是多维性，分析内容复杂。在事务处理环境中，决策者可能并不关心具体的细节信息，在决策分析环境中，如果这些细节数据量太大，一方面会严重影响分析效率，另一方面这些细节数据会分散决策者的注意力。DB2OracleSQLServerExcelspreadsheetXMLdocumentInternetSSLclientapplicationsBrowsersDatamanagementlayerApplicationlayerWebservers数据库系统的局限性（续）当事务型处理环境和分析型处理环境在同一个数据库系统中，事务型处理对数据的存取操作频率高，操作处理的时间短，而分析型处理可能需要连续运行几个小时，从而消耗大量的系统资源。决策型分析数据的数据量大，这些数据来自企业内部或外部。来自企业外部的数据又可能来自不同的数据库系统，在分析时直接对这些数据操作会造成分析的混乱。对于外部数据中的一些非结构化数据，传统数据库系统常常是无能为力。多库系统的限制可用性：源站点或通信网络故障将导致系统瘫痪,源站点不能通过网络在线连入多库系统。响应速度：全局查询多级转换和通信传输,延迟和低层效率影响响应速度。系统性能：总体性能取决于源站点中性能最低的系统,影响系统性能的发挥。系统开销：每次查询要启动多个局部系统,通信和运行开销大。实施数据仓库的条件数据积累已达到一定规模。面临激烈的市场竞争。在IT方面的资金能得到保障。数据仓库的发展WalMart建立了第一个数据仓库。早期的数据仓库大都采用当时流行的客户/服务器结构。近年来分布式对象技术飞速发展，整个数据仓库体系结构从功能上划分为若干个分布式对象，这些分布式对象不仅可以直接用于建立数据仓库，还可以在应用程序中向用户提供调用的接口。IBM的实验室在数据仓库方面已经进行了10多年的研究，并将研究成果发展成为商用产品。其他数据库厂商在数据仓库领域也纷纷提出了各自的解决方案。数据仓库（DataWarehouse）数据仓库用来保存从多个数据库或其它信息源选取的数据,并为上层应用提供统一用户接口，完成数据查询和分析。支持整个企业范围的决策支持，提供大量面向整个企业的综合信息。数据仓库是作为决策服务的分析型数据库，用来存放大容量的只读数据，为制定决策提供所需要的信息。数据仓库是与业务系统相分离的、基于标准企业模型集成的、带有时间属性的、面向主题及不可更新的数据集合。以1992年数据仓库之父Inmon出版《BuildingtheDataWarehouse》为标志，数据仓库发展速度很快。Inmon对数据仓库的认识：数据仓库是面向主题的、集成的、稳定的、随时间变化的数据集合，用以支持管理决策的过程。数据仓库的特性面向主题集成性数据的非易失性数据的时变性面向主题数据仓库中的数据是按照各种主题来组织的。主题在数据仓库中的物理实现是一系列的相关表。如保险公司的主题可能是汽车保险、生命保险、伤亡保险，而数据仓库是按照客户、政策、保险金和索赔来组织数据。面向主题的数据组织方式可在较高层次上对分析对象的数据给出完整、一致的描述，能完整、统一地刻画各个分析对象所涉及的各项数据以及数据之间的联系。一些主题相关的数据通常分布在多个业务系统中。集成性数据仓库中的数据是从原有分散的源数据库中提取出来，每一个主题所对应的源数据在原有的数据库中有许多冗余和不一致，且与不同的应用逻辑相关。为了创建一个有效的主题，必须将这些来自不同数据源的数据集成起来，使之遵循统一的编码规则。数据的非易失性数据仓库内的数据有很长的时间跨度，通常是5-10年。数据仓库中的数据反映了一段时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于撰写快照进行统计、综合和重组的导出数据。主要供企业高层决策分析之用，所涉及的数据操作主要是查询，一般情况下并不进行修改操作。数据仓库中的数据是不可实时更新的，仅当超过规定的存储期限，才将其从数据仓库中删除，提取新的数据经集成后输入数据仓库。经过加工和集成进入数据仓库的数据是极少更新的，通常只需要定期加载和更新。不同类型数据的更新频率是不同的。例如，产品属性的变化每个星期更新一次，地理位置的变化每个月更新一次，销售数据每天更新一次。数据的时变性许多商业分析要求对发展趋势做出预测，对发展趋势的分析需要访问历史数据。因此数据仓库必需要不断捕捉OLTP数据库中变化的数据，生成数据库的快照，经集成后导入到数据仓库；另外数据仓库还需要随时间的变化删去过期的、对分析没有价值的数据。数据仓库的数据随时间变化主要变现在以下几个方面：数据仓库的数据时限一般要远远长于业务系统的数据时限。业务系统存储的是当前数据，而数据仓库中的数据是历史数据。数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。支持管理决策数据仓库支持OLAP（联机分析处理）、数据挖掘，提供决策支持。OLAP从数据仓库中的综合数据出发，提供面向分析的多维模型，并使用多维分析的方法从多个角度、多个层次对多维数据进行分析。数据挖掘则以数据仓库和多维数据库中的数据为基础，发现数据中的潜在模式和进行预测。因此，数据仓库的功能是支持管理层进行科学决策，而不是事务处理。数据仓库的技术要求复杂分析的高性能体现：涉及大量数据的聚集、综合等，在进行复杂查询时经常会使用多表的联接、累计、分类、排序等操作。对提取出来的数据进行集成：数据仓库中的数据是从多个应用领域中提取出来的，在不同的应用领域和不同的数据库系统中都有不同的结构和形式，对数据进行集成也是构建数据仓库的一个重要方面。对进行高层决策的最终用户的界面支持：提供各种分析应用工具。数据仓库的结构数据仓库主要包括数据的提取、转换与装载（ETL）、元数据、数据集市和操作数据存储等部分，常用的数据仓库结构如下图。数据仓库系统体系结构数据仓库系统的组成源数据：数据仓库中的数据来源于多个数据源，它不仅可以是企业内部的关系型数据库，还包括非传统数据，如文件、HTML文档等。数据仓库管理系统：元数据库及元数据管理部件：元数据库用来存储由定义部件生成的关于源数据、目标数据、提取规则、转换规则以及源数据与数据仓库之间的映射信息等。数据转换部件：该部件把数据从源数据中提取出来，依定义部件的规则将不同数据格式的源数据转换成数据仓库的数据格式并装载进数据仓库。数据集成部件：该部件根据定义部件的规则、统一各源数据的编码规则，并净化数据，根据元数据中定义的数据组织形式对数据进行汇总、聚合计算。数据仓库管理部件：它主要用于维护数据仓库中的数据，备份、恢复数据以及管理数据的安全权限问题。 数据仓库系统的组成（续）数据仓库前端工具集查询/报表工具：以图形化方式和报表方式显示数据，帮助了解数据的结构、关系以及动态性。OLAP工具：通过对信息的多种可能的观察形式进行快速、一致和交互性的存取，便于用户对数据进行深入的分析。数据挖掘工具：从大量数据中挖掘出具有规律性的知识，以及数据之间的内在联系。前端开发工具：提供用户编程接口，便于在现有系统的基础上进行二次开发，增强系统的伸缩性。数据仓库:在数据仓库系统中，数据仓库是一个数据存储集合，它的存储形式通常有多维数据库、关系型数据库及其他存储方式。数据集市数据仓库是企业级的，能为整个企业各部门的运行提供决策支持手段。而数据集市（DataMart）是部门级别的，一般只能为某个局部范围内的管理人员服务，也称为部门级的数据仓库。数据集市有两种：独立的数据集市和从属的数据集市。数据集市是专门为某一部门或某个特定的商业需求定制的，而不是根据数据容量命名的。数据集市不是数据仓库，也并非小的数据仓库，多个数据集市集合并不简单构成数据仓库。元数据数据仓库中的元数据是关于数据仓库中数据的数据，作用类似于数据库管理系统的数据字典，用于保存逻辑数据结构、文件、地址和索引等信息。数据仓库的所有数据都要通过元数据来管理和控制。元数据是用来描述数据的数据，它描述关于源数据的说明，包括源数据的来源、源数据的名称、源数据的定义、源数据的创建时间等对源数据进行管理所需要的信息，也可反映数据仓库中的数据项是从哪个特定的数据源填充的，经过哪些转换、集成过程。用户在使用数据仓库时，通过元数据访问数据，明确数据项的含义以及定制报表。数据仓库的规模及其复杂性离不开正确的元数据管理，包括增加或移除外部数据源，改变数据清洗方法、控制出错的查询以及安排备份等。元数据（续）技术元数据与业务元数据元数据可分为技术元数据与业务元数据。技术元数据技术元数据为开发和管理数据仓库的IT人员使用，描述与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。业务元数据业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，使业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用它们。元数据的作用描述哪些数据在数据仓库中，帮助决策分析者对数据仓库中的数据定位。定义数据进入数据仓库的方式，作为数据汇总、映射和清洗的指南。记录业务事件的发生和随之进行的数据抽取的时间安排。记录并检测系统数据一致性的要求和执行情况。评估数据质量。粒度粒度：对数据仓库中的数据综合程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问的种类。粒度越小，数据越细，查询的范围就越广；粒度越高，细节程度越低，查询的范围就越小。在数据仓库中可将小粒度的数据存储在低速存储器上；大粒度的数据存储在高速存储器上。根据粒度的不同，可以把数据划分为早期细节级、当前细节级、轻度综合级和高度综合级等。数据仓库中数据的多粒度化为用户使用数据提供了一定的灵活性。高度综合级轻度综合级当前细节级早期细节级通用数据仓库元模型目前大部分商务智能产品都有不同的元数据模型，因而元数据模型的标准化管理是有必要的。通用数据仓库元模型（CWM）就是不同元数据的存储和管理标准，得到IBM、Oracle、NCR、Sun和HP等公司的支持。通过通用数据仓库元模型，元数据就可以在不同商务智能系统之间交换和共享，从而减少商务智能构建的费用。ETL数据仓库并非只是数据的简单累积，而是要经过一系列的抽取、转换和装载的过程，即ETL。ETL是构建数据仓库的重要环节，也是企业数据管理的核心，对数据仓库的后续环节影响大。ETL的主要功能分为数据抽取、数据转换、数据清洗以及数据装载。数据抽取确认数据源的数据及其含义。抽取。确定访问元数据库中的哪些文件或表，需要提取其中哪些字段。抽取频率。需要定期更新数据仓库的数据，因此对不同的数据源需要确定数据抽取的频率，如每天、每星期、每月或每季度等。输出。数据输出的目的地和输出的格式。异常处理。当需要的数据无法抽取时如何处理。数据转换不一致数据的转换数据不一致包括数据源内部的不一致和多个数据源之间的数据不一致等。不同业务系统的数量单位、编码、值域或语义等都需要统一。数据粒度的转换数据粒度的转换。业务系统一般存储细粒度的事务型数据，而数据仓库中的数据是用于查询、分析,因此需要多种不同粒度的数据。这些不同粒度的数据可以通过对细粒度的事务型数据进行聚合(aggregation)而产生。数据清洗数据源中数据的质量是非常重要的，低劣的“脏”数据容易导致低质量的决策甚至是错误的决策。此外，这些“脏”数据或不可用数据也可能造成报表的不一致等问题。因此有必要全面校验数据源的数据质量，此过程就是数据清洗(datacleaning)。主要的数据质量问题有以下几种：缺失(missing)数据，即数据值的缺失。错误数据。常见的错误数据包括字段的虚假值、异常取值等。这些错误数据产生的主要原因是由于业务系统在数据输入后不能进行正确性判断而被录入数据库。错误数据需要被及时找出并限期修正。数据重复。数据重复是反复录入同样的数据记录，这类数据会增加数据分析的开销。数据冲突。数据冲突包括同一数据源内部的数据冲突和多个数据源之间的数据冲突。冲突的数据也需要及时地修正。更新与刷新在初始装载完成后，为维护和保持数据的有效性，可以采用更新和刷新的方式。更新：对数据源的变化进行记录。刷新：对特定周期数据进行重新装载。操作数据存储数据仓库实现操作型数据与分析型数据的分离，建立了数据库-数据仓库（DB-DW）两层体系结构。然而DB-DW并不能完全满足企业所有的数据处理需求，有时企业需要全局一致的、细粒度、面向主题、集成的和时变的当前或接近当前的数据，因而需要在DB-DW之间增加一个新的层次——操作数据存储，构建DB-ODS-DW结构，满足实时或近实时的查询要求和报表需求。也有人将操作数据存储称为实时数据仓库。Businessdatawarehouse业务系统（Operationalsystems）数据集市（Datamarts）操作数据存储（Operationaldatastore）元数据（MetaData）操作型数据库、操作数据存储和数据仓库之间的比较数据仓库模型

星型图模型

物理数据模型概念模型逻辑模型物理模型面向用户的需求细化层次更详细的技术细节信息包图概念模型概念模型用来表达信息世界中的信息结构，关系数据库一般采用实体-关系（E-R）图来作为概念模型的表示方法。由于大多数商务数据是多维的，传统的数据模型表示三维以上的数据有一定困难。概念模型简化了这个过程并且允许用户与开发者和其他用户建立联系：确定系统边界：决策类型、需要的信息、原始信息确定主题域及其内容：主题域的公共键码、联系、属性组确定维度：如时间维、销售位置维、产品维、组别维等确定类别：相应维的详细类别确定指标和事实：用于进行分析的数值化信息实例〖例〗试画出销售分析的概念模型。首先根据销售分析的实际需求，确定信息包的维度、类别和指标与事实：（1）维度：包括日期维、销售地点维、销售产品维、年龄组别维、性别维等。（2）类别：确定各维的详细类别，如：日期维包括年（10）、季度（40）、月（120）等类别，括号中的数字分别指出各类别的数量；销售地点维包括国家（15）、区域（45）、城市（280）、区（880）、商店（2000）等类别，括号中的数字同样分别指出各类别的数量；类似地，可以确定销售产品、年龄组别维、性别维等的详细类别。（3）度量和事实：确定用于进行分析的数值化信息，包括预测销售量、实际销售量和预测偏差等。销售分析的概念模型日期销售地点销售产品年龄组别性别年(10)国家(15)产品类(6)年龄组(8)性别组(2)季度(40)区域(45)产品组(48)月(120)城市(280)产品(240)区(880)商店(2000)度量和事实:预测销售量、实际销售量、预测偏差信息包：销售分析 维度类别逻辑模型（1）星型模型数据仓库通常有两种基本的逻辑模型：星型模型和雪花模型。星型模型的核心是事实表，事实表把各种不同的维表连接起来。与传统的关系模型相比，星型模型简化了用户分析所需的关系，从支持决策的角度去定义数据实体，更适合大量复杂查询。星型图包括了三种逻辑实体：指标、维度和详细类别。维表的本质是多维分析空间在某个角度上的投影，多个维表共同建立一个多维分析空间。逻辑模型（2）雪花模型雪花模型是星型模型的扩展，某些维表中的数据可以进一步分解到附加的表中，以便减少冗余，节省存储空间。雪花模型对星型模型中的维表进行进一步标准化、规范化处理。物理模型数据仓库的物理模型是逻辑模型在数据仓库中的实现，主要包含数据仓库的软硬件配置、数据的存储结构与索引、数据存储位置和存储分配等。在物理设计时，常常要按数据的重要程度、使用频率以及对响应时间的要求进行分类，并将不同类的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间高的数据就存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上。同一个主题的数据并不一定要存储在相同的介质上。设计数据仓库的物理模型需要考虑的问题确定项目资源。需要对该项目的成本、周期和资源进行估算。确定软硬件配置。需要对数据容量进行估算，进而推算数据仓库的预计容量，在发挥软件的功能，满足实际的处理需求同时，又为将来的系统扩展预留出一定的空间。数据仓库存储设计。一般采用分层设计，即ODS层、数据仓库层、数据仓库聚合层和数据集市等。数据仓库ETL策略：数据抽取策略。数据抽取不仅需要满足业务处理和决策分析的要求，而且不能影响业务系统的性能。数据转换策略。数据转换是根据决策分析主题的要求，对业务系统中抽取的源数据进行转换、清洗等处理,保证来自不同数据源的数据的一致性和完整性。数据加载策略。数据加载是指从业务系统中抽取转换后的数据装载到数据仓库中。数据挖掘查询语言数据挖掘原语可以用来定义数据挖掘任务，如数据挖掘查询语言（DataMiningQueryLanguage，DMQL）。DMQL是一种具SQL的数据挖掘查询语言，包括定义数据仓库与数据集市、挖掘概念/类描述、关联和分类等数据挖掘原语。数据仓库和数据集市可以使用两种数据挖掘原语定义：一种是立方体定义；另一种是维定义。立方体定义和维定义的语法：定义雪花模型销售主题的雪花模型定义星系模型事实表共享维表的模式可以看作星型模型集，也称为星系模型或事实星座。度量度量包括分布度量和代数度量。分布度量：可以用分布聚集函数count()、sum()、min()和max()等计算。代数度量：可以用代数聚集函数average()和standard_deviation()来进行计算。医保数据仓库设计实例（1）医保的业务分析某市医保体系涵盖实时交易、个人账户管理、医保事务管理、医保服务点管理、审核结算管理和顾客服务系统等多项业务，但由于初期缺乏严格的整体规划，每个子系统都有局部的业务数据，数据缺乏标准化和完整性，数据杂乱、冗余和数据交换繁杂，造成了数据的综合分析、利用能力不足，影响了医保管理的时效性，使决策者难以及时获得医疗状况的宏观情况。从业务子系统中采集的各种基础数据量约有500GB，并且随着医保数据采集力度加大，数据量按每月50GB左右的速度急速增长。按此预测，未来数据中心存储的数据量将达到TB级或PB级，医保信息系统将负载庞大的数据。因而决定采用数据仓库建立集成的数据平台，以整合各分部系统源的数据，解决信息孤岛问题，提高医保管理的综合分析能力，及时、有效地反映医保基金的运作情况。医保数据仓库设计实例（2）医保数据仓库系统架构采用典型的数据仓库三层架构。从数据源到最终呈现给用户，中间经过数据获取、数据管理和信息传递等过程。数据获取：采用ETL工具从分布异构的数据源抽取相关的源数据，经过ETL过程装载到操作型数据存储（ODS）以及数据仓库中。数据管理：考虑现有业务系统核心数据库的加载速度和转换复杂度，医保系统选用Oracle数据仓库