第二章数据仓库开发模型.pptx
- 文档编号:15122904
- 上传时间:2023-07-01
- 格式:PPTX
- 页数:48
- 大小:592.95KB
第二章数据仓库开发模型.pptx
《第二章数据仓库开发模型.pptx》由会员分享,可在线阅读,更多相关《第二章数据仓库开发模型.pptx(48页珍藏版)》请在冰点文库上搜索。
DW的设计是一个复杂的过程:
现实环境抽象模型具体实现。
上述过程实现的期间,使用了诸多的数据模型,1引言2概念模型3逻辑模型4物理模型5元数据模型6粒度模型7聚集模型,第二章数据仓库开发模型,1引言创建DW时,需用各种数据模型对DW进行描述。
DW的开发者依据这些数据模型,才能开发出一个满足用户需求的DW。
为了使开发人员能够将注意力集中在数据仓库开发的主要部分,模型要有很好的适应性,更易于修改,且,当用户的需求改变时,仅对模型做出相应的变化就能反映这个改变。
CH2,模型是对现实世界进行抽象的工具。
信息管理中,需要将现实世界的事物及其有关特征转换为信息世界的数据才能对信息进行处理与管理,这就需要依靠数据模型作为这种转换的桥梁。
上述的转换一般需要经历从现实到概念模型,从概念模型到逻辑模型,从逻辑模型到物理模型的转换过程。
CH2,CH2,此外,数据仓库的开发过程中,还要使用下述很重要的几个数据模型元数据模型和数据粒度和聚集模型。
DW开发过程中,各个数据模型间的关系如下图所示。
DW的灵魂!
指导DW开发。
CH2,2概念模型概念模型是对真实世界中问题域内的事物的描述,包括:
记号、内涵、外延,其中记号和内涵(视图)最具实际意义。
和业务处理系统一样,数据仓库构建过程中,也可以用E-R图来表示概念模型这样做的直接好处是,数据仓库与业务处理系统能够得到很好的协调。
CH2,改进的E-R图与业务处理系统中的数据库概念设计一样,数据仓库也可以用三个层次的数据模型来描述高层模型(E-R图)、中层模型(逻辑层)和底层模型(物理层)。
但要注意两者之间的差异:
数据类型的差异DW中不包含操作型数据,只包含用户感兴趣的分析数据(如,商品的销量、企业的利润等)、描述数据(如,销售时间、地点),CH2,以及细节数据(如,所销售商品的详情、客户详情等)。
数据的历史变迁性业务处理系统中,一般只包含当前数据而不含历史数据;数据仓库中,为了反映出组织的历史变迁、业务的发展等,需要增加时间属性进行描述(即把时间作为关键字的一部分)。
数据的概括性为了提高使用的性能,往往在数据仓库中增加一些由基本数据导出的衍生数据,它们在业务处理系统中是不存在的。
为此,对传统的E-R图进行了一些改进:
把实体扩展成三类指标实体(事实实体)、维实体和详细类别实体。
CH2,其中:
指标实体指标实体处于概念模型的中心,是DW活动的中心;是现实世界中的某一业务处理或某一事件(销售、服务等)的逻辑表示;体现了现实世界中的事务处理的值(从业务处理系统获取的),每个值只与每个相关维的一个点对应,是管理人员衡量业务好坏及其处理难度的基础。
CH2,随着时间的推移,以及数据仓库需求的变化,指标实体中的数据量会日益膨胀,因此,指标实体是数据仓库管理的重点。
其主要特性如下:
是分析中心,提供基本数据;包含多个数据访问路径;包含标准数据;能扩充成很大的表以容纳日益增长的数据。
CH2,维实体主要用于对实体的过滤和重新组织,可将用户的查询结果按维指标进行筛选,可在指标实体之间以及指标实体与详细类别实体之间建立联系,使用户对DW的使用更轻松。
其主要特性:
访问并过滤指标实体;是非标准实体(含完整的维体系编码、关键词及相关运算);引导用户及进行查询分析等等。
CH2,详细类别实体与现实世界的某一实体(一个客户/一个产品/一个销售点)对应,为用户提供更为详细的分析数据。
其主要特性为:
含参考数据及有助于完成指标数据职能的支持信息;与事务结构有映射关系;是标准的数据结构;数据量比指标实体少,比维实体多。
CH2,反规范化处理业务处理系统中的数据库设计,是以规范化数据模型为目标的,如,RDBMS中的3NF等,规范化数据模型具有存储的高效性和灵活性的特点。
数据仓库中,若仍采用规范化数据模型的话,就会存在一系列“小”表,在进行大量的数据处理时,会频繁地与这些小表进行动态连接,从而产生大量的I/O操作。
CH2,反规范化处理,就是为了减少I/O次数而把上述的诸多“小”表合并在一起的处理方法。
可见,反规范化处理是以增加数据的冗余为代价来减少I/O次数的由于数据仓库中要进行海量的数据处理,因此,这种以“空间换时间”的尝试,在数据仓库应用中是值得的,也是易于被用户所接受的。
CH2,星形模型,仅从概念设计的角度来看,右图给出了一个简单的ER图,其中的,五个实体相互间是平等关系。
然而,从管理决策的角度看,这五个实体绝对不会是“平等关系”,例如,决策者真正关心的是“订单”,其他实体(供应商、产品、客户等)只是针对“订单”的诸多说明。
CH2,进而,实际应用中,会有大量数据载入订单实体,其他实体只有少量数据载入因此需要一种有别于传统ER图的数据模型来描述某个实体需载入大量数据的结,构星形模型就是这样的模型之一。
CH2,一个星形模型包含一个对应于某个主题的事实表和若干个非正规化描述事实的维表。
星形模型具有以下特性:
事实表的数据描述特定的商务事件,一般可以添加不许修改;维表存放事实表中数据的特征值,利用维关键字通过事实表的外键约束于事实表的某一行,因此,事实表的外键不许为空(一般DB则可)优点?
;每个维表通过一个主键与事实表链接;通过事实表可以关联各个维表。
CH2,雪花模型雪花模型是对星形模型的扩展每个维表均可向外链接多个详细类别表,以对事实表进行详细描述减小了事实表。
CH2,注:
雪花模型中,维表被标准化、正规化了改善了查询的性能;由于采用了标准化以及低粒度,所以雪花模型提高了数据仓库应用的灵活性。
CH2,3逻辑模型逻辑模型是三层模型中的中层模型,它是对高层模型(概念模型)的细化,如下图。
CH2,逻辑模型的基本结构逻辑模型有四种基本结构:
基本数据组、二级数据组、连接数据组和类型数据组。
CH2,基本数据组其中存在着唯一的主要主题域。
基本数据组在每个主题域中只出现一次,包含属性和键码。
二级数据组基本数据组中,有一组链接指向二级数据组,表示主要主题域所具有的属性,有多少个属性就有多少个二级数据组。
CH2,连接数据组用于本组主要主题域与其他主要主题域间的关联,体现了概念模型中实体间的联系。
一般,它是一个主题的公共码主键。
类型数据组用于指明数据的类型,主要有超类型和子类型两种。
除了连接数据组外,其他三类数据组的数据具有不同的稳定性,由高到低依次为基本数据组、二级数据组、类型数据组。
CH2,逻辑模型实例,CH2,可见:
中层(逻辑)模型向用户提供了更为详细的设计结果,用户能够借此了解数据仓库可以给他提供一些什么信息;逻辑模型设计中,DW开发者关心的是DW结构的完整性数据仓库中的所有数据元素都应该包含在逻辑模型中至于如何获取数据,在此并不感兴趣。
CH2,事实表模型设计A.事实表的设计确定了中层模型之后,就要设计事实表模型了。
例如,根据上例,可以设计出以下事实模型:
客户事实表客户基本情况表(账号int9,姓名ch12,客户类型ch20,初次交易时间date8,)客户变动情况表(账号int9,住址ch50,文化程度ch10,电话int11,邮政编码ch6,),CH2,客户交易事实表商品交易情况表(账号int9,商品编号ch10,交易量r10.2,交易时间date8,)服务交易情况表(账号int9,服务时间date8,服务编号int10,服务费用,)客户反馈记录表客户反馈记录表(账号int9,反馈类型ch5,反馈内容memo,记录人ch8,)客户信用状况表客户信用状况表(账号int9,最大信用额r15.2,最近信用发生时间date8,),CH2,B.事实表中的事实特性事实指标的可加性;完全可加性,半可加性,非可加性派生事实可加性的派生事实,不可加性的派生事实总之,事实表是DW中的最大表,要尽可能设计得小(思考:
哪些方法?
),同时还要考虑数据的精度和粒度。
CH2,维模型设计维,是人们观察某个数据集合的特定角度,是以对数据某个共性的提取为前提的。
例如,前例中,可设计出客户主题的维表模型如下:
时间维表(年date,月date,日date);地点维表(省ch20,市ch20,县ch20,街道ch20);交易维表(现金交易ch20,信用交易ch20)关于维的讨论,将在OLAP一章进行。
CH2,4物理模型所谓物理模型,就是中层(逻辑)模型(包括事实表和维表)的物理实现。
具体包括以下内容:
确定存储结构(一般用RAID);确定索引类型(位图/广义索引);物理模型的优化(表合并,建立数据序列,引入冗余,表的物理分割,生成衍生数据等)。
RAID是“RedundantArrayofIndependentDisk”的缩写,中文意思是独立冗余磁盘阵列。
CH2,实际应用中,DW设计者不必直接设计物理模型,只需借助于现成的工具(如,某个DBMS)设计即可。
此时,需考虑的问题有:
全面了解所选用的DBMS,特别是其存储结构和存取方法;了解数据环境、数据的使用频度、使用方式、数据规模以及响应时间要求等平衡、优化时间和空间效率的重要依据;了解外部存储设备的特性,如分块原则,块大小的规定,设备的IO特性等。
CH2,5元数据模型DW中元数据定义了许多对象表、列、查询、商业规则以及DW内部的数据转移等。
元数据是DW的重要构件,是DW的指示图。
一般,元数据的来源有:
数据源的元数据;数据模型的元数据;数据源与数据仓库映射的元数据;数据仓库应用的元数据。
CH2,元数据的类型与组成元数据通常分为静态元数据和动态元数据两类,其组成如下表所示:
CH2,元数据的作用A.元数据的重要性导航(DW的使用);描述并记录数据从业务系统的操作型环境到DW的转换,以便利用其(灵活地、可变地)管理数据的转换以及进行数据回溯等。
管理数据,包括:
粒度划分、数据分割、索引;不同时期的数据内容及形式;主题的增加及删除这些管理工作均需在元数据中有相应的描述。
CH2,B.元数据在DW开发期间的作用DW的应用管理,比如,捕获数据转化、净化、概括、聚集的规则(商业规则与处理规则)等;向用户提供大量的数据关系;从历史数据抽取数据的规则;存储抽取、求精、重构过程中数据源到DW的映射关系(以便确认数据质量、实现同步化及刷新、建立数据与商业规则间的映射关系)。
CH2,C.元数据在数据抽取中的作用确定数据源每个主题源于哪些数据源;跟踪历史数据的数据结构的变化保证各个时期的历史数据可以正确地转换到DW中;实现属性到属性的映射元数据的属性信息可以保证多个数据源的相同数据映射到一起;属性的转换。
CH2,D.元数据在求精与重构中的作用数据的分割以元数据形式(下同)保存分割方案;数据的概括保存概括中的数据关系;预算与推导保存预算与推导的算法;转换与再映射保存(从关系模型到星形或雪花型模型的)转换与再映射的方案。
CH2,元数据的收集A.数据源元数据可以通过程序自动扫描(数据源物理结构以及表结构)或手工方式获得。
一般,手工获得的量较少,可容易地编辑成文档。
B.数据模型元数据元数据库中保存DW数据模型;保存企业数据模型及元数据与DW数据模型的映射关系;把数据源元数据移入DW元数据库。
CH2,从数据模型收集元数据,可借助于CASE工具自动实现,但重要的数据模型与元数据的对应关系的确认,最好通过手工方式完成。
C.数据源与数据仓库映射的元数据该映射包括抽取、转换、加载等过程。
若手工完成,则需以数据库或电子表格方式定义上述映射并存于元数据库中;若由DW开发工具完成,则,除了把映射存于元数据库之外,还要提供访问该映射的方式与工具。
CH2,D.数据仓库应用的元数据元数据模型构造中最后、最困难、最重要的内容。
其主要工作是:
确定DW中各个使用对象被使用的频率高频率者,可建立数据集市或增加概括数据;低频率者,可释放相应的概括、聚集数据,回收它们占据的磁盘空间。
上述工作一般通过手工方式完成。
CH2,6粒度模型所谓粒度,可定义成DW记录数据/对数据进行综合时使用的时间段参数该参数越小,粒度级别越低,数据越详细;反之,粒度级别越高,数据也越综合(细节损失得也越多)。
根据粒度的划分标准,可以将数据划分为:
详细数据、轻度总结、高度总结三级或更多级粒度。
粒度的具体划分将直接影响到数据仓库中的数据量以及查询质量。
CH2,数据粒度的划分最低级别的粒度可定义成数据仓库中数据细节的最低层次,如事务层次。
这种数据层次是高度细节化的,能使用户按所需的任何层次进行汇总,但它受外存空间以及响应时间的制约。
涉及到时间和空间,自然与各个表的“体积”以及索引文件的大小密切相关所以划分粒度的最终依据是表的总行数而非字段数的多寡。
(思考:
为什么?
),CH2,粒度划分的步骤确定DW中数据行数和存储设备数;估算DW中表的数目以及每个表的大致行数(通常需给出上下限);估算每个表一年的存储空间以及最长保留年数(假设为5年)所需存储空间;估算DW一年的存储空间以及最长保留年数所需存储空间。
最后,参照下面的对照表给出数据粒度的划分策略:
CH2,CH2,确定粒度的级别进行数据粒度的划分,要确定粒度的级别,具体考虑的因素包括:
要接受的分析类型、可接受的数据最低粒度和能存储的数据量;粒度的层次定义越高,就越不能在该仓库中进行更细致的分析;在同一模式中使用多重粒度;如果存储资源有一定的限制,就只能采用较高粒度的数据粒度划分策略。
CH2,7聚集模型聚集数据主要是为了使用户获得更好的查询性能。
聚集模型设计时应该注意将聚集数据存储在其事实表中,并与其底层数据相区别。
一般,参照以下几点进行设计:
首先,需要考虑用户的使用要求(比如,按照地理位置/产品类型/时间范围形成的各种报告)。
CH2,其次,要考虑DW的粒度模型如果数据仓库中只包含细节数据,则可多设计一些聚集;如果粒度模型为多重数据。
则可以少考虑一些聚集。
此外,还应该考虑聚集属性的数量因素假设底层有1000000个值,若次底层有500000个值,则聚集效果不明显;若次底层只有75000个值,则聚集效果更佳。
CH2,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第二 数据仓库 开发 模型