对数据仓库进行数据建模_IBM.docx

对数据仓库进行数据建模IBM2007-11-1615:00OLTP与数据仓库一有何差异？在日常生活中，我们要使用大量的应用程序来生成新的数据、变更数据、删除数据，当然在大多数的情况下我们还要查阅和分析数据。就来想象一个收发email的简单应用程序吧。我们已经存储了地址信息，可能还存储了一些文档。我们可以决定是否存储已经发送过的邮件，但是也可能隔一段时间后将其删除，或者删除已经发送过的所有邮件。那么我们该如何处理一段时间以前删除或者修改正的地址呢？我们再也不会看到它们了。Email程序大局部都属于不是很复杂的数据库，但是完全可以将其看作一个在单用户环境下的OLTP（在线事务处理系统）简单例如。它使用了所有的所谓访问数据的操作CRUD（创立、读取、更新、删除）。当数据存储到达一定量的时候，规模就会几乎保持不变，因为可以从存储中删除过期数据。数据仓库就完全是一种不同种类的应用程序。它并不是用来运行当前的操作，例如发送邮件。它是用来分析数据并且从现有数据中发现新的价值，主要是用来预测未来的情况。数据仓库并不是解决所有问题的通用结构。它必须集中于某一问题领域，例如航空效劳、顾客收益等。数据仓库也有有趣的一面，那就是数据库本身是稳定增长的。数据没有被删除，也不发生变更。我们不需要将冗余数据置于数据库之外（因为参加仓库中的数据经过了数据净化的过程，该过程检查了数据的正确性）来减少复杂性同时增强读取操作的性能。为了能够对数据仓库中的数据进行分析，数据存储于一个多维结构中，叫做星型模式。如果将星型模式扩展，就会得到雪花模式。本白皮书将会阐述如何使用IBMRatiOnalROSe进行星型模式建模和雪花模式建模。飞行效劳数据集市的例子为了更好地解释如何对数据仓库建模，本白皮书将使用一个简单数据集市的的例子（即一个数据仓库或者数据仓库的一局部），来分析旅客乘坐航班HaPPyFlyingandLanding（愉快飞行平安降落）的行为和满意程度。我们将存储乘客信息和每个航班的的相关数据、选择的菜单以及乘客对飞行的满意程度。数据仓库术语表数据仓库引入了新的术语，扩展了数据建模的术语表。为使本文的阐述能够完备，下面我介绍一下最常用的术语。数据仓库数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丧失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。它并不需要非常精确，因为它必须在特定的时间基础上从操作环境中提取出来。数据集市数据仓库只限于单个主题的区域，例如顾客、部门、地点等。数据集市在从数据仓库获取数据时可以依赖于数据仓库，或者当它们从操作系统中获取数据时就不依赖于数据仓库。事实事实是数据仓库中的信息单元，也是多维空间中的一个单元，受分析单元的限制。事实存储于一张表中（当使用关系数据库时）或者是多维数据库中的一个单元。每个事实包括关于事实（收入、价值、满意记录等）的根本信息，并且与维度相关。在某些情况下，当所有的必要信息都存储于维度中时，单纯的事实出现就是对于数据仓库足够的信息。我们稍后讨论有关缺无事实的情况。维度维度是绑定由坐标系定义的空间的坐标系的轴线。数据仓库中的坐标系定义了数据单元，其中包含事实。坐标系的一个例子就是带有X维度和y维度的Cartesian（笛卡尔）坐标系。在数据仓库中，时间总是维度之一。数据挖掘在数据仓库的数据中发现新信息的过程被称为数据挖掘，这些新信息不会从操作系统中获得。分析空间分析空间是数据仓库中一定量的数据，用于进行数据挖掘以发现新信息同时支持管理决策。切片一种用来在数据仓库中将一个维度中的分析空间限制为数据子集的技术。切块一种用来在数据仓库中将多个维度中的分析空间限制为数据子集的技术。星型模式一种使用关系数据库实现多维分析空间的模式，称为星型模式。星型模式将在本白皮书中稍后进行进一步讨论。雪花模式不管什么原因，当星型模式的维度需要进行标准化时，星型模式就演进为雪花模式。使用IBMRationalRose进行星型模式建模星型模式的根本形式必须实现多维空间（常常被称为方块），以使用关系数据库的根本功能。首先，我们需要理解多维空间。多维分析空间几何学中的方块是指一个三维空间，其中每个维度的尺寸都相同。想象一个立方体，每个维度都有三个单元，我们即得到相同结构的33=27个单元。图1一个具有X、y、Z维度的方块多维分析空间（或者数据仓库方块）与几何空间中的方块仅仅存在细节上的差异。 维度不仅限于3维。不过，处理很多维度的立方体也不是件轻松的事情，这会导致大多数的实现被限制于6或者7维。不要期盼使用图形可以很好地表示超过4的维度一如果您有幸能发现一种方法，别忘了告诉我一下。 维度并不具有相同的规模和单元。规模从几个单元到几百万个单元，差异巨大。单元可以是一天、一位顾客、部门等。 单元，相当于子方块（IXlXl等），包含事实。图2一个三维数据立方体Revenue数据立方体需要很大的内存以存储所有事实。无论是否包含事实，都必须要预留单元。这就是为什么使用关系数据库和星型模式的原因。使用它们能够优化存储并且保持数据结构的灵活性。星型模式星型模式的根本思想就是保持立方体的多维功能，同时也增加了小规模数据存储的灵活性。图3一个星型模式在图3中，星型模式使用事实Flight表示了一个4维方块（PaSSenger、Menu、FIightSChedUIet和Time）o根本上，事实必须指定一个维度，以将其放入立方体的单元中。我们的例子中的维度是： PaSSenger,描述了飞行航程中的每位乘客，由经常飞行号（frequentflyernumber）指定。不是经常乘坐飞机的乘客不是数据仓库的一局部。 FlightSchedule,是指所有常规飞行的日程。 Menu,是用于飞行的菜单。只有对菜单进行根本的分类才会对数据挖掘有重要意义。 Time,是指飞行的时间。事实Flight描述了乘客在唯一的Time的单程飞行上选择Menuo分析空间可以是完整的方块，或者我们可以根据维度将分析空间分割成小片。每个维度根据一个对象进行描述，对象可以用类表示，这些类就是有关业务主题的名称。这一点对于成功建立数据仓库来说是很重要的，因为仓库的用户（经理、分析员、市场）对于信息技术的术语并不是很熟悉。事实本身就是商业智能的另一个对象，仍然通过类进行表示。事实指每个维度。事实与维度的关联常常是一对任意，这也就意味着每个事实都与单个维度的一个单元准确对应，而维度的每个单元（每个Passenger,Time等）可以与任意数量的事实发生关联（包括。个事实）。使用RationalRose将对象模型转换为数据模型即完成了星型模式的实现。这里我们可以看到转换后的结果。图4使用RationalRose实现星型模式在图4中，没有显示自动创立的主键和外键约束。星型模式的维度是独立的表。当对象模型转换为数据模型时，RationalRose可以生成维度的主键。事实表指从维度表中使用键迁移的维度，当生成数据模型时RationalRose可以生成外键。在星型模式中切片和切块是对维度的限制（选择）。这是一个运行时问题，而不是建模问题，但是模型必须分辨其需要。雪花模式根本的星型模式并不能满足数据挖掘的所有需要。我们需要更复杂的维度，例如时间。分析员希望根据周、月、季度等识别模式。维度必须进行标准化。我们不需要冗余的维度表，这只会使数据切片变得更加复杂。这种过程中我们得到的模式被称为雪花模式。我们来看一个简单的雪花模式例子。我们将时间维度标准化为周、月和季度。图5标准化的Time维度我们希望能够使用附加的标准化维度将立方体切片：周、月和季度。在本例中，我们假定季度是月的平行层次，这也就意味着我们不能将季度假定为若干月的聚合。由于这个原因，我们将使用一张范化表（是对OLAP查询的一项简单附加）预先选择时间维度。最终雪花模式添加了标准化维度o图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进行切片。一致的维度随着数据仓库架构师不断地添加细节内容，雪花模式变得越来越复杂。因此设计过程必须在到达某种程度后停止以保持数据仓库运行良好。星型或者雪花模式仍然仅仅关注于一个事实一在本例中就是Flighto那么复杂关系又是什么情况呢？对于每个事实我们都必须设计其各自的模式。如果我们想要进行复杂查询的话，它们就必须具有共同的维度我们称其为一致的维度。让我们使用Pilot作为一个维度，PihtFlight作为一个事实来定义第二个星型模式。我们还要使用附加的FlightSchedule维度和Time维度。图12Pilot星型模式第二个模式可以单独使用或者与Passenger模式结合使用，从而根据使用一致维度的飞行员维度来查询Passenger的满意程度。图13一致维度Tinle和FlightSchedule即使在使用一致维度的数据仓库的简单结构中，Pilot与Passenger之间的关系也是简单的。在开发数据模型时，数据仓库将大量小型星型模式与雪花模式相结合形成了大型的数据仓库模式。事实与维度的数据我们想要评估乘客对于飞行的满意率。可以使用不满意到很满意几个级别进行评定。评定记录存放在事实表Flight中作为一个属性（列）。如果我们想要得出一个平均记录,那么就