对数据仓库进行数据建模IBM

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