对数据仓库进行数据建模IBMWord文档下载推荐.docx
- 文档编号:17777899
- 上传时间:2022-12-10
- 格式:DOCX
- 页数:13
- 大小:260.92KB
对数据仓库进行数据建模IBMWord文档下载推荐.docx
《对数据仓库进行数据建模IBMWord文档下载推荐.docx》由会员分享,可在线阅读,更多相关《对数据仓库进行数据建模IBMWord文档下载推荐.docx(13页珍藏版)》请在冰豆网上搜索。
数据没有被删除,也不发生变更。
我们不需要将冗余数据置于数据库之外(因为加入仓库中的数据通过了数据净化的过程,该过程检查了数据的正确性)来减少复杂性同时增强读取操作的性能。
为了能够对数据仓库中的数据进行分析,数据储备于一个多维结构中,叫做星型模式。
假如将星型模式扩展,就会得到雪花模式。
本白皮书将会阐述如何使用IBMRationalRose进行星型模式建模和雪花模式建模。
飞行服务数据集市的例子
为了更好地说明如何对数据仓库建模,本白皮书将使用一个简单数据集市的的例子(即一个数据仓库或者数据仓库的一部分),来分析旅客乘坐航班HappyFlyingandLanding(愉快飞行平安降落)的行为和中意程度。
我们将储备乘客信息和每个航班的的相关数据、选择的菜单以及乘客对飞行的中意程度。
数据仓库术语表
数据仓库引入了新的术语,扩展了数据建模的术语表。
为使本文的阐述能够完备,下面我介绍一下最常用的术语。
数据仓库
数据仓库是一个支持治理决策的数据集合。
数据是面向主题的、集成的、不易丢失的同时是时刻变量。
数据仓库是所有操作环境和外部数据源的快照集合。
它并不需要专门精确,因为它必须在特定的时刻基础上从操作环境中提取出来。
数据集市
数据仓库只限于单个主题的区域,例如顾客、部门、地点等。
数据集市在从数据仓库猎取数据时能够依靠于数据仓库,或者当它们从操作系统中猎取数据时就不依靠于数据仓库。
事实
事实是数据仓库中的信息单元,也是多维空间中的一个单元,受分析单元的限制。
事实储备于一张表中(当使用关系数据库时)或者是多维数据库中的一个单元。
每个事实包括关于事实(收入、价值、中意记录等)的差不多信息,同时与维度相关。
在某些情形下,当所有的必要信息都储备于维度中时,单纯的事实显现确实是关于数据仓库足够的信息。
我们稍后讨论有关缺无事实的情形。
维度
维度是绑定由坐标系定义的空间的坐标系的轴线。
数据仓库中的坐标系定义了数据单元,其中包含事实。
坐标系的一个例子确实是带有x维度和y维度的Cartesian(笛卡尔)坐标系。
在数据仓库中,时刻总是维度之一。
数据挖掘
在数据仓库的数据中发觉新信息的过程被称为数据挖掘,这些新信息可不能从操作系统中获得。
分析空间
分析空间是数据仓库中一定量的数据,用于进行数据挖掘以发觉新信息同时支持治理决策。
切片
一种用来在数据仓库中将一个维度中的分析空间限制为数据子集的技术。
切块
一种用来在数据仓库中将多个维度中的分析空间限制为数据子集的技术。
星型模式
一种使用关系数据库实现多维分析空间的模式,称为星型模式。
星型模式将在本白皮书中稍后进行进一步讨论。
雪花模式
不管什么缘故,当星型模式的维度需要进行规范化时,星型模式就演进为雪花模式。
使用IBMRationalRose进行星型模式建模
星型模式的差不多形式必须实现多维空间(常常被称为方块),以使用关系数据库的差不多功能。
第一,我们需要明白得多维空间。
多维分析空间
几何学中的方块是指一个三维空间,其中每个维度的尺寸都相同。
想象一个立方体,每个维度都有三个单元,我们即得到相同结构的33=27个单元。
图1一个具有x、y、z维度的方块
多维分析空间(或者数据仓库方块)与几何空间中的方块仅仅存在细节上的差异。
∙维度不仅限于3维。
只是,处理专门多维度的立方体也不是件轻松的情况,这会导致大多数的实现被限制于6或者7维。
不要期盼使用图形能够专门好地表示超过4的维度--假如您有幸能发觉一种方法,别忘了告诉我一下。
∙维度并不具有相同的规模和单元。
规模从几个单元到几百万个单元,差别庞大。
单元能够是一天、一位顾客、部门等。
∙单元,相当于子方块(1×
1×
1等),包含事实。
图2一个三维数据立方体
数据立方体需要专门大的内存以储备所有事实。
不管是否包含事实,都必须要预留单元。
这确实是什么缘故使用关系数据库和星型模式的缘故。
使用它们能够优化储备同时保持数据结构的灵活性。
星型模式的差不多思想确实是保持立方体的多维功能,同时也增加了小规模数据储备的灵活性。
图3一个星型模式
在图3中,星型模式使用事实Flight表示了一个4维方块(Passenger、Menu、FlightSchedulet和Time)。
差不多上,事实必须指定一个维度,以将其放入立方体的单元中。
我们的例子中的维度是:
∙Passenger,描述了飞行航程中的每位乘客,由经常飞行号(frequentflyernumber)指定。
不是经常乘坐飞机的乘客不是数据仓库的一部分。
∙FlightSchedule,是指所有常规飞行的日程。
∙Menu,是用于飞行的菜单。
只有对菜单进行差不多的分类才会对数据挖掘有重要意义。
∙Time,是指飞行的时刻。
事实Flight描述了乘客在唯独的Time的单程飞行上选择Menu。
分析空间能够是完整的方块,或者我们能够依照维度将分析空间分割成小片。
每个维度依照一个对象进行描述,对象能够用类表示,这些类确实是有关业务主题的名称。
这一点关于成功建立数据仓库来说是专门重要的,因为仓库的用户(经理、分析员、市场)关于信息技术的术语并不是专门熟悉。
事实本身确实是商业智能的另一个对象,仍旧通过类进行表示。
事实指每个维度。
事实与维度的关联常常是一对任意,这也就意味着每个事实都与单个维度的一个单元准确对应,而维度的每个单元(每个Passenger、Time等)能够与任意数量的事实发生关联(包括0个事实)。
使用RationalRose将对象模型转换为数据模型即完成了星型模式的实现。
那个地点我们能够看到转换后的结果。
图4使用RationalRose实现星型模式
在图4中,没有显示自动创建的主键和外键约束。
星型模式的维度是独立的表。
当对象模型转换为数据模型时,RationalRose能够生成维度的主键。
事实表指从维度表中使用键迁移的维度,当生成数据模型时RationalRose能够生成外键。
在星型模式中切片和切块是对维度的限制(选择)。
这是一个运行时问题,而不是建模问题,然而模型必须辨论其需要。
差不多的星型模式并不能满足数据挖掘的所有需要。
我们需要更复杂的维度,例如时刻。
分析员期望依照周、月、季度等识别模式。
维度必须进行规范化。
我们不需要冗余的维度表,这只会使数据切片变得更加复杂。
这种过程中我们得到的模式被称为雪花模式。
我们来看一个简单的雪花模式例子。
我们将时刻维度规范化为周、月和季度。
图5规范化的Time维度
我们期望能够使用附加的规范化维度将立方体切片:
周、月和季度。
在本例中,我们假定季度是月的平行层次,这也就意味着我们不能将季度假定为若干月的聚合。
由于那个缘故,我们将使用一张范化表(是对OLAP查询的一项简单附加)预先选择时刻维度。
最终雪花模式添加了规范化维度。
图6带有范化维度的Time和事实Flight的雪花模式
因此,所有的维度都能够像时刻例子那样进行规范化,这就导致了比较复杂的数据集市模式的显现。
由RationalRose从雪花模式中开发的实现模式(数据模型)是完善的。
图7带有范化Time维度的雪花模式的数据模型
创建的约束在图中也没有显示。
雪花模式中能够存在切片,不仅仅在差不多的Time维度上,也能够在规范化的Week、Month和Quarter维度上。
多对多关系
在一次飞行中,我们不仅仅只吃一顿饭。
在长途飞行中可能要多次用餐。
在这种情形下,我们认为事实Flight和Menu维度不是一对多的关联。
我们必须使用多对多关联。
只是,这种关联不可能在星型模式中实现。
雪花模式的一种专门形式是使用一种必要的数据结构以满足这项要求。
第一,我们将模型变更为事实和维度间的多对多关联。
使用RationalRose,这只是关联基数的变更。
图8Menu的多对多维度的星型模式
我们无法在关系数据库中实现多对多关联。
实现多对多关联需要使用另一种雪花模式。
在下图中,我们关注一下差不多开发的雪花模式的一部分,该部分处理多对多维度。
图9雪花模式解决了Menu的多维度
RationalRose生成了附加的维度表FlightMenu,它是指Menu维度和Flight事实。
确定关系用于解决多对多关联。
关于雪花模式的架构师来说,最重要的一点确实是识别多对多关系。
简单对象视图可能会使设计员明白得概念,而生成的数据视图有助于进一步深入有关实现的问题。
层次
数据挖掘能够从隐藏在操作系统表面下的数据中发觉信息。
我们想了解的一个问题确实是选定菜单与乘客统计资料之间的依靠关系。
乘客统计资料数据能够在Passenger维度的层次上构建。
乘客能够依照邮政编码分组,然后再按国家进行分组。
图10乘客的层次
层次通过使用聚合来指定。
聚合定义了所包括的内容。
Country包含了ZIP编码,ZIP编码包含了多名Passenger信息。
最终通过使用外键实现了聚合。
图11雪花模式实现了Passenger维度的聚合
生成的约束仍旧没有在图中表示出来。
使用聚合,维度能够在任何定义的级别上使用。
分析空间能够通过Passenger、ZIPCode或者Country进行切片。
一致的维度
随着数据仓库架构师不断地添加细节内容,雪花模式变得越来越复杂。
因此设计过程必须在到达某种程度后停止以保持数据仓库运行良好。
星型或者雪花模式仍旧仅仅关注于一个事实--在本例中确实是Flight。
那么复杂关系又是什么情形呢?
关于每个事实我们都必须设计其各自的模式。
假如我们想要进行复杂查询的话,它们就必须具有共同的维度--我们称其为一致的维度。
让我们使用Pilot作为一个维度,PilotFlight作为一个事实来定义第二个星型模式。
我们还要使用附加的FlightSchedule维度和Time维度。
图12Pilot星型模式
第二个模式能够单独使用或者与Passenger模式结合使用,从而依照使用一致维度的飞行员维度来查询Passenger的中意程度。
图13一致维度Time和FlightSchedule
即使在使用一致维度的数据仓库的简单结构中,Pilot与Passenger之间的关系也是简单的。
在开发数据模型时,数据仓库将大量小型星型模式与雪花模式相结合形成了大型的数据仓库模式。
事实与维度的数据
我们想要评估乘客关于飞行的中意率。
能够使用不中意到专门中意几个级别进行评定。
评定记录存放在事实表Flight中作为一个属性(列)。
假如我们想要得出一个平均记录,那么就必须为记录定义值以进行运算。
我们能够将记录分为0到10级。
如此就能够得到一个平均记录。
平均值应该储备在维度表中,以用于简单的切片,其中我们只想进行一维切片。
RationalRose依照目标数据库的数据类型生成了实现属性。
对象模型是用来定义数据库的数据源的。
终止语
IBMRationalRose是设计数据仓库实现的最佳工具。
对象模型定义了有关模式的全局结构的对象,和包括数据源的整体数据仓库。
它代表了数据仓库中有关视图的对象,同时隐藏了实施细节。
数据模型是数据仓库的实现模型。
数据模型能够从对象模型中生成,反之亦然。
RationalRose是设计星型模式和雪花模式的最理想工具。
RationalRose是灵活可调整的,足以支持任何所需的数据仓库的概念,同时也提供了数据架构师和数据库治理员需要的功能以对数据仓库进行调整。
RationalRose为分析业务和开发用来实现数据仓库的需求提供了强大动力。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据仓库 进行 数据 建模 IBM
![提示](https://static.bdocx.com/images/bang_tan.gif)