客户关系管理第五章v1

第5章CRM与数据仓库5.1.1数据仓库的产生•早期的数据库主要支持联机事务处理•决策支持对数据分析的需求•传统数据库系统不适宜DSS①事务处理和分析处理的性能特性不同②数据集成问题③数据动态集成问题④历史数据问题⑤数据的综合问题⑥操作繁简问题（1）事务处理和分析处理的性能特性不同。•所有联机事务处理强调的是数据更新处理性能和系统的可靠性，并不关心数据查询的方便与快捷。在事务处理环境中，用户的行为特点是数据的存取操作频率高而每次操作处理的时间短。•在分析处理环境中，用户的行为模式与此完全不同，强调的是数据处理和分析的能力。在传统数据库系统基础上的DSS应用程序可能需要连续几个小时，从而消耗大量的系统资源。•联机分析和事务处理对系统的要求不同，同一个数据库在理论上难以做到两全，将具有如此不同处理性能的两种应用放在同一个环境中运行显然是不适当的。（2）数据集成问题。•DSS需要集成的数据。全面而正确的数据是有效的分析和决策的首要前提，相关数据收集得越完整，得到的结果就越可靠。当前绝大多数企业内数据的真正状况是分散而非集成的。•造成这种分散的原因有多种，主要有事务处理应用分散、“蜘蛛网”问题、数据不一致问题、外部数据和非结构化数据。（3）数据动态集成问题。•静态集成的最大缺点在于，如果在数据集成后数据源中数据发生了变化，这些变化将不能反映给决策者，导致决策者使用的是过时的数据。集成数据必须以一定的周期（例如24小时）进行刷新，我们称其为动态集成。显然，事务处理系统不具备动态集成的能力。（4）历史数据问题。•事务处理一般只需要当前数据，在数据库中一般也是存储短期数据，切不同数据的保存期限也不一样，即使有一些历史数据保存下来了，也被束之高阁，未得到充分利用。但对于决策分析而言，历史数据是相当重要的，许多分析方法必须一大量的历史数据为依托。没有历史数据的详细分析，是难以把握企业的发展趋势的。DSS对数据在空间和时间的广度上都有了更高的要求，而事务处理环境难以满足这些要求。（5）数据的综合问题。•在事务处理系统中积累了大量的细节数据，一般而言，DSS并不对这些细节数据进行分析。在分析前，往往需要对细节数据进行不同程度的综合。而事务处理系统不具备这种综合能力，根据规范化理论，这种综合还往往因为是一种数据冗余而加以限制。（6）操作繁简问题。•业务数据的模式是针对事务处理系统而设计的，数据的格式和描述方式并不适合非计算机专业人员进行业务上的分析和统计。•有人感叹：20年前查询不到数据是因为数据太少了，而今天查询不到数据是因为数据太多了。•要提高分析和决策的效率和有效性，分析型处理及其数据必须与操作型处理及其数据相分离。必须把分析型数据从事务处理环境中提取出来，按照DSS处理的需要进行重新组织，建立单独的分析处理环境，数据仓库正是为了构建这种新的分析处理环境而出现的一种数据存储和组织技术。•数据仓库的数据从联机的事务处理系统、异构的外部数据源、脱机的历史业务数据中得到。它是一个联机的系统，专门为分析统计和决策支持应用服务，通过它可满足决策支持和联机分析应用所要求的一切。5.1.2数据仓库的概念和特征•目前，数据仓库一词尚没有一个统一的定义。•著名的数据仓库专家W.H.Inmon在其著作《BuildingtheDataWarehouse》一书中给予如下描述：•数据仓库（DataWarehouse）是一个面向主题的（SubjectOriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合，用于支持管理决策。数据仓库概念的两个层次•功能上：数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；•内容和特征上：数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。数据仓库关键特征一——面向主题•面向主题，是数据仓库显著区别于关系数据库系统的一个特征–围绕一些主题，如顾客、供应商、产品等–关注决策者的数据建模与分析，而不是集中于组织机构的日常操作和事务处理。–排除对于决策无用的数据，提供特定主题的简明视图。数据仓库关键特征二——数据集成•一个数据仓库是通过集成多个异种数据源来构造的。–关系数据库，一般文件，联机事务处理记录•使用数据清理和数据集成技术。–确保命名约定、编码结构、属性度量等的一致性。–当数据被移到数据仓库时，它们要经过转化。数据仓库关键特征三——随时间而变化•数据仓库是从历史的角度提供信息–数据仓库的时间范围比操作数据库系统要长的多。•操作数据库系统:主要保存当前数据。•数据仓库:从历史的角度提供信息（比如过去5-10年）–数据仓库中的每一个关键结构都隐式或显式地包含时间元素，而操作数据库中的关键结构可能就不包括时间元素。数据仓库关键特征四——数据不易丢失•尽管数据仓库中的数据来自于操作数据库，但他们却是在物理上分离保存的。–操作数据库的更新操作不会出现在数据仓库环境下。–不需要事务处理，恢复，和并发控制等机制–只需要两种数据访问:•数据的初始转载和数据访问（读操作）数据仓库与操作数据库系统•操作数据库系统的主要任务是联机事务处理OLTP–日常操作:购买，库存，银行，制造，工资，注册，记帐等•数据仓库的主要任务是联机分析处理OLAP–数据分析和决策支持，支持以不同的形式显示数据以满足不同的用户需要OLAPVS.OLTP(1)•用户和系统的面向性–面向顾客（事务）VS.面向市场（分析）•数据内容–当前的、详细的数据VS.历史的、汇总的数据•数据库设计–实体－联系模型(ER)和面向应用的数据库设计VS.星型/雪花模型和面向主题的数据库设计OLAPVS.OLTP(2)•数据视图–当前的、企业内部的数据VS.经过演化的、集成的数据•访问模式–事务操作VS.只读查询（但很多是复杂的查询）•任务单位–简短的事务VS.复杂的查询•访问数据量–数十个VS.数百万个为什么需要一个分离的数据仓库?•提高两个系统的性能–DBMS是为OLTP而设计的：存储方式,索引,并发控制,恢复–数据仓库是为OLAP而设计：复杂的OLAP查询,多维视图，汇总，•不同的功能和不同的数据:–历史数据:决策支持需要历史数据，而这些数据在操作数据库中一般不会去维护–数据汇总：决策支持需要将来自异种源的数据统一（如聚集和汇总）–数据质量:不同的源使用不一致的数据表示、编码和格式，对这些数据进行有效的分析需要将他们转化后进行集成多维数据模型(1)•数据仓库和OLAP工具基于多维数据模型•在多维数据模型中，数据以数据立方体(datacube)的形式存在–数据立方体允许以多维数据建模和观察。它由维和事实定义•维是关于一个组织想要记录的视角或观点。每个维都有一个表与之相关联，称为维表。–多维数据模型围绕中心主题组织，该主题用事实表表示•事实表包括事实的名称或度量以及每个相关维表的关键字•事实指的是一些数字度量多维数据模型(2)——示例time_keydayday_of_the_weekmonthquarteryeartime维表location_keystreetcitystate_or_provincecountrylocation事实表Sales事实表time_keyitem_keybranch_keylocation_keyunits_solddollars_soldavg_sales度量item_keyitem_namebrandtypesupplier_typeitem维表branch_keybranch_namebranch_typebranch维表多维数据模型(3)•在数据仓库中，数据立方体是n-D的(n维）–（关系表和电子表格是几维的？）•示例–AllElectronics的销售数据按维time,item的2-D视图AllElectronics的销售数据按维time,item和location的3-D视图–销售数据的4-D立方体表示–多维数据模型为不同角度上的数据建模和观察提供了一个良好的基础多维数据模型(4)•在数据仓库的研究文献中，一个n维的数据的立方体叫做基本方体。给定一个维的集合，我们可以构造一个方体的格，每个都在不同的汇总级或不同的数据子集显示数据，方体的格称为数据立方体。0维方体存放最高层的汇总，称作顶点方体；而存放最底层汇总的方体则称为基本方体。数据立方体——一个方体的格alltimeitemlocationsuppliertime,itemtime,locationtime,supplieritem,locationitem,supplierlocation,suppliertime,item,locationtime,item,suppliertime,location,supplieritem,location,suppliertime,item,location,supplier0-D(顶点)方体1-D方体2-D方体3-D方体4-D(基本)方体数据仓库的概念模型•最流行的数据仓库概念模型是多维数据模型。这种模型可以以星型模式、雪花模式、或事实星座模式的形式存在。–星型模式（Starschema）:事实表在中心，周围围绕地连接着维表（每维一个），事实表含有大量数据，没有冗余。–雪花模式（Snowflakeschema）:是星型模式的变种，其中某些维表是规范化的，因而把数据进一步分解到附加表中。结果，模式图形成类似于雪花的形状。–事实星座（Factconstellations）:多个事实表共享维表,这种模式可以看作星型模式集，因此称为星系模式（galaxyschema），或者事实星座（factconstellation）星型模式实例time_keydayday_of_the_weekmonthquarteryeartimelocation_keystreetcitystate_or_provincecountrylocationSalesFactTabletime_keyitem_keybranch_keylocation_keyunits_solddollars_soldavg_salesMeasuresitem_keyitem_namebrandtypesupplier_typeitembranch_keybranch_namebranch_typebranch雪花模式实例time_keydayday_of_the_weekmonthquarteryeartimelocation_keystreetcity_keylocationSalesFactTabletime_keyitem_keybranch_keylocation_keyunits_solddollars_soldavg_salesMeasuresitem_keyitem_namebrandtypesupplier_keyitembranch_keybranch_namebranch_typebranchsupplier_keysupplier_typesuppliercity_keycitystate_or_provincecountrycity事实星座模式实例time_keydayday_of_the_weekmonthquarteryeartimelocation_keystreetcityprovince_or_statecountrylocationSalesFactTabletime_keyitem_keybranch_keylocation_keyunits_solddollars_soldavg_salesMeasuresitem_keyitem_namebrandtypesupplier_typeitembranch_keybranch_namebranch_typebranchShippingFactTabletime_keyitem_keyshipper_keyfrom_locationto_loc