数据仓库与数据挖掘技术-数据仓库开发模型PPT.ppt

,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第,2,章 数据仓库开发模型,主讲人：孙水华 副教授,信息科学与工程学院,数据仓库与数据挖掘技术,1,内 容,数据仓库开发模型概述,数据仓库的概念模型,数据仓库的逻辑模型,数据仓库的物理模型,数据仓库的元数据模型,数据的粒度和聚集模型,小结,2,2.1,数据仓库开发模型概述,模型是实际系统的表示，它向用户展现了重要的系统特征。同时，模型通过消除与其目的无关紧要的特征来简化显示。,模型是对现实世界进行抽象的工具。,在信息管理中需要将现实世界的事物及其有关特征转换为信息世界的数据才能对信息进行处理与管理,，这就需要依靠数据模型作为这种转换的桥梁。,设计一个能够真正支持用户进行决策分析的数据仓库，并非一件轻而易举的事情。这需要经历一个,从现实环境到抽象模型，从抽象模型到具体实现的过程,。完成这个过程建立各种不同的数据模型是必不可少的。,3,数据仓库模型设计包括,概念模型设计,、,逻辑模型设计、物理模型设计、元数据模型设计,等内容。数据仓库的建模首先要将现实的决策分析环境抽象成一个概念数据模型。然后，将此概念模型逻辑化，建立逻辑数据模型。最后，还要将逻辑数据模型向数据仓库的物理模型转化。作为数据仓库灵魂的元数据模型则自始至终伴随着数据仓库的开发、实施与使用。数据仓库的,数据抽取模型,则说明抽取什么数据，从哪些业务系统抽取，对抽取的数据进行哪些转换处理等。数据仓库的数据建模技术如图,2.1,所示。,4,现实世界,高层概念模型,中层逻辑模型,物理模型,数据仓库的实现,元 数 据 模 型,数据抽取模型,图,2.1,数据仓库的数据建模技术,5,现实世界,是存在于现实之中的各种客观事物。,概念世界,是现实情况在人们头脑中的反应。,逻辑世界,是人们为将存在于自己头脑中的概念模型转换到计算机中的实际的物理存储过程中的一个计算机逻辑表示模式。,计算机世界,则是指现实世界中的事物在计算机系统中的实际存储模式。现实世界与其他模型的变化联系如图,2.2,所示。,张三,客户,客户与产品,特性,个体,整体,整体间联系,属性,实体,同质实体,异质实体,列（字段）,记录,表文件,数据库,信用,现实世界,概念世界,逻辑世界,计算机世界,图,2.2,现实世界与其他模型的变化联系,6,数据仓库概念模型设计的目的是对数据仓库所涉及现实世界的所有客观实体进行科学、全面地分析和抽象，制定构建数据仓库的“蓝图”。数据仓库的概念模型设计时需要确定数据仓库的主要主题及其相互关系。主题应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系，根据需求分析确定几个基本的主题域及其维度。,概念模型设计主要完成以下工作：,1,界定系统边界。,2,确定主要的主题域。,3,确定分析的维度和分析的内容。,2.2,数据仓库的概念模型,7,1,界定系统边界。,即进行任务和环境评估、需求收集和分析，了解用户迫切需要解决的问题及解决这些问题所需要的信息，需要对现有数据库中的数据有一个完整而清晰的认识。,2,确定主要的主题域。,对每一个主题域的公共码键、主题域之间的联系、充分代表主题的属性进行较明确的描述。,8,3,确定分析的维度和分析的内容。,一旦主题划分清楚了，接着就要细化分析的具体内容以及根据分析内容的性质确定分析维度。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，,一般情况下，作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量是连续型数据，取值无限。,如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。,9,进行数据仓库数据建模之前，对,数据仓库的需求进行分析是必不可少的,，数据仓库需求分析需要对来自多个领域的需求进行详细分析。,需求分析的方式有两种：一是对原有固定报表进行分析；二是对业务人员进行访谈。,原有固定报表能较好地反映出原业务对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但数据仓库建设中仅仅替代目前的手工报表还是不够的，因此还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分，数据仓库的主题划分实际上与分析内容的范围直接相关。,最终用户的需求体现在对工作流程的分析、决策的查询需求、报表需求、操作需求和数据需求等方面。,2.2.1,企业模型的建立,10,数据仓库的最终用户只能通过查询和报表工具以及数据仓库内部信息的某种映射关系来访问数据仓库内部数据,，对他们而言，数据仓库是一个黑箱。,最终用户指定数据分析的类型,，这些数据分析操作主要是对数据项进行揭示更多的细节的分片和细剖，寻找企业隐含行为的数据挖掘，,在对数据进行分析时可从二维或多维的、电子表格的、关系的、报表的、图表的和运营样本的数据等方面进行分析。,11,我们以,SQL Server 2005,数据库引入的,Adventure Works,示例数据库为例介绍数据仓库数据建模过程。,SQL Server 2005,数据库的示例以名为,Adventure Works Cycles,的虚拟公司为背景，该公司是一家大型跨国生产公司，其产品主要包括生产金属和复合材料的自行车，公司总部设在华盛顿州的伯瑟尔市，有,500,名雇员，该公司在世界各地均建立了区域性销售团队，产品远销北美、欧洲和亚洲市场。,Adventure Works Cycles,目前的目标是专注于向高端用户提供产品，通过外部网站扩展其产品的销售渠道、通过降低生产成本来削减其销售成本。,下面将通过介绍该公司的原材料采购、生产和销售等环节的业务流程，提出该公司的数据仓库需求。,12,1.,原材料采购业务流程。,该公司内部由采购部负责原材料采购，采购部门下设一个经理和多个采购员。每个采购员需要了解原材料和供应商的联系，负责多种原材料的采购，一种原材料只能由一个采购员采购，,采购员和商品之间是一对多关系,；一种原材料有多个供应商，一个供应商可以提供多种原材料，,原材料和供应商之间是多对多的关系,；采购部门经理需要管理员工,并且还需要了解原材料的库存情况,以确定需要采购的商品并将任务分配给每个采购人员。,13,2.,库存业务流程,公司由仓库管理部门对原材料、产品等物料信息进行库存管理，仓库管理部门管理多个仓库，下设一个经理和多个仓库管理员，,每个仓库有多个仓库管理员，每个管理员只能在一个仓库中进行工作。,仓库管理员需要知道他所管理的仓库中存储的物料的种类、数量、存储的时间、原材料的保值期及原材料进入仓库和离开仓库的时间等信息。,一个仓库可以保存多种物料。,仓库管理部门经理不但需要处理仓库管理员需要的数据，而且需要知道仓库管理员的基本信息，如家庭地址、联系电话等。,14,3.,产品销售业务流程,Adventure Works Cycles,公司的产品远销北美、欧洲和亚洲市场。公司目前有网络销售和批发商销售两种销售渠道。因此，客户也分为个人消费者和商店两类，个人消费者是从在线商店购买产品的消费者，商店是从,Adventure Works Cycles,销售代表处购买产品后进行转售的零售店或批发店。销售人员关心产品的信息，包括：产品的价格、质量、颜色和规格等，以便向顾客推销相关的产品。销售部门经理需要了解产品销售情况，以便在某种产品缺货时通知仓库管理部门运送商品；同时，他还需要了解每个销售员的工作业绩，对每个销售员进行考核，即销售部门经理需要了解商品、顾客和部门员工的情况。,15,在设计数据仓库数据模型时要从业务蕴涵的数据视角来理解业务，,从业务分析中可以看出，不同部门对数据需求不同，同一部门人员对数据需求也存在差异,。如管理人员和普通业务人员对数据要求的程度是不同的，管理人员可能需要综合度较高或较为概括的数据，而普通业务人员需要细节数据。因此，,数据仓库项目需求的收集与分析需要从历史数据与用户需求两个方面同时着手，采用“数据驱动,+,用户驱动”的设计理念。,16,2.2.2,规范的数据模型,关系模型是具有二维表格形式的数据模型，它建立在关系代数的基础上。是传统数据库中最常用的数据模型，其特点是把数据组织成二维表的形式，无论是实体还是实体间的联系都采用二维表，二维表的每一行叫作关系的一个,元组,，每一列叫作关系的一个,属性,。关系中的每一列的值总是取自一个集合，这个集合称为,域,。,关系模型可以用实体,-,联系,(Entity-Relationship,简称,E-R),图来表示。,E-R,图通过定义了数据间的关系，去除数据冗余，使操作型处理简单，还可保证数据一致性。因此，关系模型在传统的操作型数据库系统中获得了巨大的成功。,范式,是关系数据库模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化,(Normalize),。,17,Adventure Works Cycles,公司的业务数据分为,5,大部分，如表,2-1,所示。,18,这,5,个架构相关的表信息如表,2-2,所示。,19,续表,续表其它部分见,p36,20,21,在实际设计中用于数据仓库设计的概念模型与业务数据处理系统的数据模型仍然具有一定的差距。,1.,数据类型的差距：数据仓库的概念模型只包含用户所感兴趣的分析数据、描述数据和细节数据。,2.,数据的历史变迁性：数据仓库的概念模型扩充了关键字结构，增加了时间属性并作为关键字的一部分。,3.,数据的概括性：数据仓库的概念模型中还增加了一些基本数据所导出的衍生数据用于管理决策分析，这些在业务处理系统中是不存在的。,22,数据仓库项目需求的收集与分析需要从历史数据与用户需求两个方面同时着手,采用“数据驱动,+,用户驱动”的设计理念。,数据驱动,是根据当前业务数据的基础和质量情况，以数据源的分析为出发点构建数据仓库，,用户驱动,则是根据用户业务的方向性需求，从业务需求出发，确定系统范围的需求框架。如图,2.3,所示，常常用“两头挤法”找出数据仓库系统的真正需求。,用户驱 动,数据驱 动,用户需求：,需要什么,系统条件：,有什么,真正需求,图,2.3,用户驱动与数据驱动相结合示意图,23,在企业模型建立过程中，与用户交流时，须确定数据仓库需要访问的有关信息。例如，,Adventure Works Cycles,公司管理要在数据仓库中得到有关产品销售收入的详细统计信息，可以确定其度量指标如下：,1,度量指标：包括产品销售的实际收入、产品销售的预算收入及产品销售的估计收入。,2,维度指标：包括已经销售的产品信息、销售地点和顾客信息等。,根据分析，可建立,Adventure Works Cycles,公司的企业数据模型如图,2.4,所示。,24,生产部门,销售部门,人事部门,采购部门,供应商,客户,企业雇员,销售部门：,销售计划,销售订单,销售统计分析,图,2.4,Adventure Works Cycles,公司企业数据模型,25,2.2.3,常见的概念模型,在概念模型设计中，常用,E-R,图作为描述工具,。,E-R,图中，长方体表示实体，即数据仓库的主题域，框内写上主题域名称；用椭圆表示主题域的属性，用无向边把主题域与其属性连接起来；再将边表示主题域之间的联系，主要有一对一的关系、一对多的关系、多对多的关系。,26,主题,，是指在较高层次上将业务数据进行综合、归类和分析的一个抽象概念，每个主题基本对应业务的一个分析领域。在主题分析中须对分析对象数据形成一个完整并且一致的描述，主题是根据分析需求确定的。,主题域,是对某个主题进行分析后确定的主题边界。主题域的确定通常由最终用户和数据仓库的设计人员共同完成。,例如，对于,Adventure Works Cycles,公司的管理层可能需要分析的主题包括供应商、商品、客户和库存情况等主题。其中,商品主题的内容包括,记录各经销商商品的销售情况、公司商品库存情况、商品中各组成物料的采购情况等；,客户主题包括,的内容有客户购买商品情况；,库存情况主题分析主要包括,商品的存储情况和仓库的管理情况等。根据分析主题和主题域可得到,Adventure Works Cycles,公司的主题及主题域结构如图,2.5,所示。,27,供应商主题,供应商,供应商,ID,有关信息,顾客主题,顾客,顾客,ID,有关信息,商品主题,商品,商品,ID,商品信息,仓库主题,仓库,仓库,ID,仓库信息,仓管员,储存,供应,购买,图,2.5,Adventure Works Cycles,公司主题及主题域划分,28,接着可以用建立信息包图的方式进一步细化概念模型。,信息包图,是在某主题域中的一个主题分析的信息打包技术，它反映了在数据聚合条件下的多维数据在计算机内部的存储方式，可以体现各个不同平台的各个信息的聚合的概念性含义，主要包括定义指标、定义维度、和定义类别三个方面的内容。,信息包图法,也叫用户信息需求表法,就是在一张平面表格上描述元素的多维性,其中每一个维度用平面表格的一列表示,例如时间、地点、产品和顾客等。信息包图定义主题内容和主要性能指标之间的关系，其目标是在概念层满足用户需求。信息包图拥有三个重要对象：度量指标、维度、类别。利用信息包图设计概念模型就是要确定这三方面内容。,1,确定度量指标。,度量指标表明在维度空间衡量业务信息的一种方法，是访问数据仓库的关键所在，是用户最关心的信息,。成功的信息包可以保证用户从信息包中获取需要的各个性能指标参数。,29,2,确定维度。维度提供了用户访问数据仓库信息的途径，对应超立方体的每一面，位于信息包图第一行的每一个栏目中。,3,确定类别。类别是在一个维度内为了提供详细分类而定义的，其成员是为了辨别和区分特定数据而设，它说明一个维度包含的详细信息，一个维度内最底层的可用分类又称为详细类别。,例如：,Adventure Works Cycles,公司销售分析主题的信息包图如表,2-4,所示。,30,注：度量指标包括实际销售额、计划销售额、计划完成率。,31,虽然数据仓库的基础是规范化的数据模型，规范化数据模型在数据仓库的实际应用中并不理想。关系模型在传统的操作型数据库系统中获得了巨大的成功，但,以,E-R,图展示的关系模型不适用于以查询为主的数据仓库系统,。在完全规范化的环境中，数据模型形成的数据表的数据量都是比较小的，为完成对这些“小”表的处理需要应用程序对这些表进行动态互联操作，这需要在不同表之间进行多个,I/O,操作，对于数据量十分庞大的数据仓库，这种多表连接操作的时间代价太大，对决策效率的提高非常不利。,32,因此,在数据仓库中需要进行数据的非规范化的处理，以减少对表联接的需求，提高数据仓库性能，提高查询效率，同时也减少编写专门决策支持应用程序的必要性，可以让用户运用一些专门的查询工具，更容易地访问数据，用户还能以直观的易于理解的工具查看数据。,因此，在数据仓库的模型构建中，有时为了提高数据仓库的运行效率，需要进行数据模型的反规范化处理。因为数据仓库属于分析型应用系统，系统的使用者是分析人员、决策人员，对他们而言，记住实体,-,关系及其属性是不可能的，因此系统的分析操作难以从具体的属性入手进行，而要基于集成或某种主题来组织数据。分析型应用需要的是快速、灵活、直观的数据检索也是关系模型无法支持的，这就要求寻找新的数据模型。,33,数据仓库数据模型设计的核心问题是多维数据的表示与存储的问题，因此,多维数据模型成为当前数据仓库数据模型设计时的首选,。多维数据建模以直观的方式组织数据，支持高性能的数据访问。,多维数据模型较为普遍地采用星型模型、雪花模型的模式。,34,1,星型模型,星型模型是一种多维的数据关系，它由一个主题事实表,(Fact Table),和一组维表,(Dimens ion Table),组成。每个维表都有一个维主键，所有这些维主键组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实,(Fact),，它们一般都是数值或其他可以进行计算的数据；而维主键大都是文字、时间等类型的数据。,Adventure Works Cycles,公司销售分析星型图如图,2.6,所示。,35,销售分析,时间,客户,产品,区域,广告,图,2.6,Adventure Works Cycles,公司销售分析星型图,36,星型模型特点分析：,星型模型速度快是在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度很快。,由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合；而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。,37,2,雪花模型,雪花模型是对星型模型的扩展。设计星型模型时确定了概念模型中的指标实体和维度实体，当构成星型模型后，为了对相关维度进行更加深入的分析，经常要设计雪花模型，在星型模型的维度实体增加需要进行深入分析的详细类别实体。雪花模型对星型模型的维度表进一步标准化，对星型模型中的维表进行了规范化处理。雪花模型通过对维表的分类细化描述，对于主题的分类详细查询具有良好的响应能力。但由于雪花模型的构造在本质上是一种数据模型的规范化处理，会给数据仓库不同表的联接操作带来困难。,Adventure Works Cycles,公司销售分析雪花模型如图,2.7,所示。,38,销售分析,时间,客户,产品,区域,广告,产品类别,图,2.7,Adventure Works Cycles,公司销售分析雪花模型图,39,完成概念模型设计以后，必须编制数据仓库开发的概念模型文档，并对概念模型进行评价。,1,概念模型设计文档,2,概念模型的评审,3,概念模型评审人员,4,概念模型的评审内容,40,2.3,数据仓库的逻辑模型,逻辑建模是数据仓库建模中的重要一环，是概念模型到物理模型转换的桥梁。它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用，它通过实体和关系勾勒出整个企业的数据蓝图。,数据仓库的数据模型与传统数据库相比，主要区别如下：,1,数据仓库的数据模型不包含纯操作型的数据。,2,数据仓库的数据模型扩充了码结构，增加了时间属性作为码的一部分。,3,数据仓库的数据模型增加了一些导出数据。,41,数据仓库的逻辑模型与数据仓库物理实现时所使用的数据库有关，由于目前数据仓库一般都建立在关系数据库的基础上，因此,数据仓库设计过程中所采用的逻辑模型主要是关系模型,。关系模型概念简单、清晰，用户易懂、易用，有严格的数学基础和在此基础上的数据关系理论。,在进行数据仓库的逻辑模型设计时，一般需要完成,主题分析、建立维度模型、确定粒度层次划分、确定数据分割策略,等工作。,42,数据仓库是面向主题的，建立数据仓库要按照主题来建模，主题域的划分是数据仓库的基础和成败的关键。逻辑模型中主题分析是对概念模型设计阶段中确定的多个基本主题进行进一步分析，并建立某主题分析的维度模型。因此，在,逻辑模型建模过程中进行的工作主要有,：,1,事实表模型设计。,分析丰富主题域，确定当前要装载的主题，进行事实表模型设计。,2,维度表模型设计。,维度建模的目的是在为用户提供一组全局数据视图的基础上进行某一主题的业务分析。因为在数据仓库的维度建模技术中，主要从用户需求范围出发，考虑指标和维度及其各种主题下的分析参数。,3,关系模式定义。,数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述。在这里，将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。,43,2.3.1,事实表模型设计,数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。,选择一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统；还要考虑它足够小，以便于开发和较快地实施。,如果所选择的主题域很大并且很复杂，可以针对它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。,下面以,Adventure Works Cycles,公司为例，可以在“商品”、“销售”和“客户”等主题上增加能进一步说明主题的属性组，如表,2-6,所示。,44,45,度量,是客户发生事件或动作的事实记录。例如客户购买商品，度量指标有购买次数、购买商品的金额、购买商品的数量等。度量变量的取值可以是离散的数值，也可以是连续的数值，还可以在某个元素集合内取值。例如：客户对公司服务质量评价可以是“优”、“良”、“中”、“差”集合中的一个；客户购买商品的金额是连续的数值；客户购买商品次数是离散的数值。,事实表是在星型模型或雪花模型中用来记录业务事实并作相应指标统计的表，事实表有如下特征：,1,记录数量多。因此事实表应当尽量减小一条记录的长度，避免因事实表过大而难于管理。,2,事实表中除了度量变量外，其余字段都是维表或者中间表（雪花模型）的关系。,3,如果事实相关的维度很多，则事实表中的字段会比较多。,46,按照事实表中度量的可加性情况，可以把事实表及其包含的,事实分为,4,种类型。,1,事务事实。以组织事件的单一事务为基础，通常只包含事实的次数。,2.,快照事实。以组织在某一特定时间和特殊状态为基础,即某一段时间内才出现的结果。,3,线性项目事实。这类事实通常用来储存关于企业组织经营项目的详细信息。包括表现与企业相关的个别线性项目所有关键性能指标，如销售数量、销售金额、成本等。,4,事件事实。通常表示事件发生与否及一些非事实本身具备的细节。它所表现的是一个事件发生后的状态变化，如哪些产品在促销期间的销售状态（卖出还是没有卖出）。,47,在事实表模型设计中还需要注意到派生事实。,派生事实主要有两种,。,一种是可以用同一事实表中的其他事实计算得到,，例如销售中的商品销售均价可以用商品的销售总金额和销售数量计算得到；,另一种是非加性事实,，例如各种商品的利润率等。,例如，可以设计,Adventure Works Cycles,公司的销售事实表模型如表,2-7,所示。,48,2.3.2,维度表模型设计,数据仓库是用于决策支持的。管理人员进行决策分析时，经常需要用一个对决策活动有重要影响的因素进行决策分析。,这些决策分析的角度或决策分析的出发点就构成了数据仓库中的维,，数据仓库中的数据就是靠这些维来组织，维就是数据仓库识别数据的索引。,数据仓库中的维，一般具有层次性,。其水平层次由维度层次中具有相同级别的字段值构成，垂直层次则由维度层次结构中具有不同级别的字段值构成。在数据仓库设计中根据需求获取数据仓库的维，构成数据仓库的模型。数据仓库中的多种维交点会构成数据仓库用户需要观察的事务。观察事务角度不同时，围绕该事务会产生多个观察角度，即产生了多维。数据仓库的立方体就是一个包含用户需要观察数据的集合体，立方体与星型模型可以相互转换。,49,维度建模的目的是在为用户提供一组全局数据视图的基础上进行某一主题的业务分析。因为在,数据仓库的维度建模技术中，主要从用户需求范围出发，考虑指标和维度及其各种主题下的分析参数。,例如：根据,Adventure Works Cycles,公司销售情况分析，其指标和维度及其各种主题下的分析参数可综合如下：,某些商品是否仅仅在某一地区销售,?,每种类型商品各个时间段销售量及销售金额是多少,?,各个客户购买商品次数,?,客户及时付款了吗,?,各类型商品预算收入是多少,?,各销售员销售业绩如何,?,50,根据以上问题的关联维度，形成,Adventure Works Cycles,公司销售情况分析的维度模型,如表,2-8,所示。,51,在这个模型中，,Adventure Works Cycles,公司有些决策管理者想要按照年、季、月、日的时间层次了解公司的销售情况；有些决策管理者想要按照产品名称、产品类别了解公司的销售情况；有些决策管理者想要按照销售员所在的区域层次了解公司的销售情况；有些决策管理者想要按照国家、省（州）、城市、销售点的区域层次了解公司的销售情况；有些决策管理者想要按照客户信用、客户收入等层次了解公司的销售情况。,52,这样，就可以建立销售情况分析的逻辑模型，如图,2.8,所示。,销售事实表,客户,ID,商品,ID,销售单,ID,时间,ID,区域,ID,销售数量,销售金额,商品利润率,产品维,产品,ID,产品类别,产品名称,时间维,时间,ID,年,季,月,日,客户维,客户,ID,区域,ID,收入,信用,区域维,区域,ID,国家,省州,城市,销售点,销售员维,雇员,ID,姓名,区域,ID,子区域,ID,图,2.8 Adventure Works Cycles,公司销售情况分析的逻辑模型,53,最后，对,逻辑模型进行评审，并编写逻辑模型的文档,，其内容包括：,主题域分析报告，数据粒度划分模型，数据分割策略，指标实体、维实体与详细类别实体的关系模式和数据抽取模型,。对逻辑模型评审主要集中在主题域是否可以正确地反映用户的决策分析需求，其内容包括：从用户对概括数据使用的要求，评审数据粒度的划分和数据分割策略是否可以满足用户决策分析的需要，为提高数据仓库的运行效率是否需要对关系模式进行反规范化处理，数据的抽取模型是否正确地建立了数据源与数据仓库的对应关系，数据的约束条件和业务规则是否在这些模型中得到了正确的反映等。,54,2.4,数据仓库的物理模型,2.4.1,物理模型的设计要点,数据仓库的物理模型就是逻辑模型在数据仓库中的物理实现模式,。物理模型就像大厦的基础架构,数据仓库的数据从几百,GB,到几十,TB,不等,即使支撑这些数据的,RDBMS,无论有多么强大,仍不可避免的要考虑到数据库的物理设计。,物理模型包括逻辑模型中各种实体表的具体化,，,例如表的数据结构类型、索引策略、数据存放位置以及数据存储分配等,。在进行物理模型设计时，要考虑,I/O,存取时间、空间利用率和维护代价。,根据数据仓库的数据量大及数据相对稳定的特点，可以设计索引结构来提高数据存取效率。,数据仓库中的表通常比,OLTP,环境中的表建有更多的索引。通常表的最大索引数与表规模成正比。数据仓库是只读环境，建立索引对提高性能和灵活性都很有利。但是表索引如果太多，则会使数据加载时间加长。因此，一般按主关键字和大多数外部关键字建立索引。,55,确定数据仓库的物理模型，设计人员必须做这样几方面工作：,1,确定项目资源，定义数据标准。,2,确定软硬件配置。,3,全面了解所选用的数据库管理系统，特别是存储结构和存取方法。,4,根据具体使用的数据库管理系统，将实体和实体特征物理化。,5,了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求。,6,了解外部存储设备的特征。,56,2.4.2,数据仓库物理模型的存储结构,在物理设计时，常常要按数据的重要性、使用频率及对响应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。,重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。另外，在设计时还要考虑数据在特定存储介质上的布局。在设计数据的布局时要注意遵循以下原则。,57,1,不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。,2,如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。,3,考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。,4,不要把表格和它们的索引放在同一设备上。一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。,5,在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用,RAID,（,Redundant Array of Inexpensive Disk,，廉价冗余磁盘阵列）。,58,Adventure Works Cycles,公司销售事件存储结构关系模型，如表,2-9,所示。,59,Adventure Works Cycles,公司商品关系存储结构关系模型，如表,2-10,所示。,60,2.4.3,数据仓库物理模型的索引构建,在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。,例如,Adventure Works Cycles,公司销售订单,按销售订单号做,B-TREE,索引,，如图,2.10,所示。,61,20020701001-20020701050,20020701051-20020701100,20020701001-20020701025,20020701026-20020701050,20020701051-20020701070,20020701071-20020701100,20020701001,20020701002,20020701026,20020701027,20020701051,20020701070,20020701071,20020701072,图,2.10 B-TREE,索引示例,20020701026,地址,20020701027,地址,地址,指向数据行的指针,62,2.4.4,数据仓库物理模型的优化问题,数据仓库物理模型进行优化时可以考虑以下解决方案：,1,合并表与簇文件（,clustering file,）：几个表的记录分散存放在几个物理块中时，多个表的存取和连接操作的代价会很大。,2,建立数据序列：按照某一固定的顺序访问并处理一组数据记录。将数据按照处理顺序存放到连续的物理块中，形成数据序列。,3,引入冗余，反规范化处理：一些表的某些属性可能在许多地方都要用到，将这些属性复制到多个主题中，可以减少处理时存取表的个数。,4,表的物理分割（分区）：每个主题中的各个属性存取频率是不同的。将一张表按各属性被存取的频率分成两个或多个表，将具有相似访问频率的数据组织在一起。,5,生成派生数据：在原始数据的基础上进行总结或计算，生成派生数据，可以在应用中直接使用这些派生数据，减少,I/O,次数，免去计算或汇总步骤，在更高级别上建立了公用数据源，避免了不同用户重复计算可能产生的偏差。,63,2.5,数据仓库的元数据模型,元数据（,metadata,）是“关于数据的数据”，如在传统数据库中的数据字典就是一种元数据。,元数据与指向数据仓库内容的索引相似，处于数据仓库的上层，并且记录数据仓库中对象的位置。,元数据存储,是对程序员所知的数据结构、,DSS,分析员所知的数据结构、数据仓库的源数据、数据模型、数据模型和数据仓库的关系、抽取数据的历史记录等内容进行记录。,64,典型的元数据包括：,1,数据仓库的表结构。,2,数据仓库的表属性。,3,数据仓库的源数据（记录系统）。,4,从记录系统到数据仓库的映射。,5,数据模型的说明。,6,抽取日志。,7,访问数据的公用例行程序。,8,数据的定义,/,描述。,9,数据单元之间的关系。,65,2.5.1,元数据的类型,根据元数据的状态，可将元数据分为静态元数据和动态元数据两类。,1,静态元数据：业务规则、域、类别、索引、来源、生成时间、关系、数据类型、格式、描述、名称等。,2,动态元数据：处理、引用处、存储大小、存储位置、状态、统计信息、数据质量、更新时间、入库时间等。,根据使用情况，主要有技术元数据和业务元数据两类元数据：,1,技术元数据（,Technical Metadata,）：为了从操作性环境向数据仓库转化而建立的元数据，包含了所有源数据项名、属性及其在数据仓库中的转化；这种元数据称为技术元数据。,2,业务元数据（,Business Metadata,）：用来和终端用户的多维商业模型,/,前端工具之间建立映射，此种元数据称之为业务元数据，常用来开发更先进的决策支持工具。,66,2.5.2,元数据的作用,在数据仓库中，,元数据主要作用于以下几个方面：,1,数据源抽取。,2,数据源转换。,3,数据源净化。,4,数据源概括与聚集。,5,数据刷新。,6,数据仓库中的数据库设计。,7,查询与报表设计。,67,图,2.12,所示，显示了元数据在整个数据仓库开发和应用过程中的巨大影响。,图,2.12,元数据在整个数据仓库开发和应用过程中的作用,68,2.5.3,元数据的收集与维护,在组织内部存在很多不同的元数据源。元数据可能来源于源系统、抽取的数据、转换或清理的数据、装载的数据、存储的数据及信息传递的过程。,1,从源系统收集元数据；,2,从抽取的数据中收集元数据；,3,从转换或清理的数据中收集元数据；,4,从数据装载中收集元数据；,5,从存储的数据中收集元数据；,6,从信息传递过程中收集元数据。,69,元数据维护时所面临的最大挑战是它存在于多个不同的来源，而每个来源都有自己的元数据仓储。元数据仓储（,meta data repository,）表示含有元数据的物理数据库表。,70,2.5.4,元数据的使用,数据仓库对元数据的使用主要体现在两个方面：第一,，因为元数据对数据仓库中数据的内容和出处进行了详细说明，用户可以根据主题利用元数据来查看数据仓库的内容；,第二,，因为元数据提供了可重复利用的查询语言信息，如果这些查询中的一个或几个能满足用户的需求，或与用户需求相近，用户就可以直接使用元数据中的查询，而不用重新编写程序。,元数据用户可以分为三类：业务用户、技术用户和高级用户,，这三类用户都需要通过元数据来确定和有效使用企业系统中的信息。,71,2.5.5,元数据管理模型,CWM,（,Common Warehouse Metamodel,，,公共仓库元模型,）是一个被,OMG,采纳为在数据仓库和业务分析环境中进行元数据交换的标准。,CWM,提供了一种经过长期研究的通用语言来描述元数据，是一个基于一般的但语义丰富的公共数据仓库和业务分析领域的元数据管理模型，它还提供了基于,XML,的元数据交换工具。,72,2.6,数据仓库的粒度和聚集模型,2.6.1,数据仓库粒度模型,粒度,是指数据仓库中数据单元的详细程度和级别。粒度可以分为两种形式：,第一种粒度是,对数据仓库中的数据的综合程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问的种类。,还有一种粒度形式，即样本数据库,，它根据给定的采样率从细节数据库中抽取出一个子集，这样样本数据库中的粒度就不是根据综合程度的不同来划分的，而是有采样率的高低来划分，采样粒度不同的样本数据库可以具有相同的数据综合程度。,73,确定粒度级别的步骤如下：,1,适当划分粒度的第一步是估算数据仓库中将来使用的数据行数和所需的直接存取存储设备数（,DASD,）。,2,在计算出数据仓库所需要占用的存储空间以后，需要根据所需要的存储空间大小确定是否划分粒度，如果需要划分，又应该怎样划分。可对每个表估算其一年所需要的存储空间，然后估算其最长的保留年数所需要的存储空间。每个表的存储空间，应该是每一个表的数据存储空间和索引存储空间之和。精确计算表的每年实际存储空间是很困难的，只能给出表的最大估算空间和最小估算空间。,3,在数据仓库中确定粒度时，需要考虑这样一些因素：要