本文将会阐述如何使用IBM Rational Rose进行星型模式建模和雪花模式的数据仓库应用的建模。 OLTP 与数据仓库--有何差异？ Email 程序大部分都属于不是很复杂的数据库，但是完全可以将其看作一个在单用户环境下的 OLTP（在线事务处理系统）简单示例。它使用了所有的所谓访问数据的操作 CRUD（创建、读取、更新、删除）。当数据存储达到一定量的时候，规模就会几乎保持不变，因为可以从存储中删除过期数据。 数据仓库就完全是一种不同种类的应用程序。它并不是用来运行当前的操作，例如发送邮件。它是用来分析数据并且从现有数据中发现新的价值，主要是用来预测未来的情况。数据仓库并不是解决所有问题的通用结构。它必须集中于某一问题领域，例如航空服务、顾客收益等。 数据仓库也有有趣的一面，那就是数据库本身是稳定增长的。数据没有被删除，也不发生变更。我们不需要将冗余数据置于数据库之外（因为加入仓库中的数据经过了数据净化的过程，该过程检查了数据的正确性）来减少复杂性同时增强读取操作的性能。 为了能够对数据仓库中的数据进行分析，数据存储于一个多维结构中，叫做星型模式。如果将星型模式扩展，就会得到雪花模式。本白皮书将会阐述如何使用IBM Rational Rose进行星型模式建模和雪花模式建模。 飞行服务数据集市的例子 我们将存储乘客信息和每个航班的的相关数据、选择的菜单以及乘客对飞行的满意程度。 数据仓库术语表 数据仓库 数据仓库是所有操作环境和外部数据源的快照集合。它并不需要非常精确，因为它必须在特定的时间基础上从操作环境中提取出来。 数据集市 事实 事实存储于一张表中（当使用关系数据库时）或者是多维数据库中的一个单元。 每个事实包括关于事实（收入、价值、满意记录等）的基本信息，并且与维度相关。 在某些情况下，当所有的必要信息都存储于维度中时，单纯的事实出现就是对于数据仓库足够的信息。我们稍后讨论有关缺无事实的情况。 维度 坐标系的一个例子就是带有 x 维度和 y 维度的 Cartesian（笛卡尔）坐标系。 在数据仓库中，时间总是维度之一。 数据挖掘 分析空间 切片 切块 星型模式 星型模式将在本白皮书中稍后进行进一步讨论。 雪花模式 使用 IBM Rational Rose 进行星型模式建模 首先，我们需要理解多维空间。 多维分析空间 多维分析空间（或者数据仓库方块）与几何空间中的方块仅仅存在细节上的差异。
数据立方体需要很大的内存以存储所有事实。无论是否包含事实，都必须要预留单元。 这就是为什么使用关系数据库和星型模式的原因。使用它们能够优化存储并且保持数据结构的灵活性。 星型模式 在图3中，星型模式使用事实 Flight 表示了一个 4 维方块（Passenger、Menu、Flight Schedulet 和 Time）。基本上，事实必须指定一个维度，以将其放入立方体的单元中。 我们的例子中的维度是：
事实 Flight 描述了乘客在唯一的 Time 的单程飞行上选择 Menu。 分析空间可以是完整的方块，或者我们可以根据维度将分析空间分割成小片。 每个维度根据一个对象进行描述，对象可以用类表示，这些类就是有关业务主题的名称。这一点对于成功建立数据仓库来说是很重要的，因为仓库的用户（经理、分析员、市场）对于信息技术的术语并不是很熟悉。 事实本身就是商业智能的另一个对象，仍然通过类进行表示。 事实指每个维度。事实与维度的关联常常是一对任意，这也就意味着每个事实都与单个维度的一个单元准确对应，而维度的每个单元（每个Passenger、Time等）可以与任意数量的事实发生关联（包括0个事实）。 使用 Rational Rose 将对象模型转换为数据模型即完成了星型模式的实现。这里我们可以看到转换后的结果。 在图4中，没有显示自动创建的主键和外键约束。 星型模式的维度是独立的表。当对象模型转换为数据模型时，Rational Rose 可以生成维度的主键。 事实表指从维度表中使用键迁移的维度，当生成数据模型时 Rational Rose 可以生成外键。 在星型模式中切片和切块是对维度的限制（选择）。这是一个运行时问题，而不是建模问题，但是模型必须分辨其需要。 雪花模式 维度必须进行规范化。我们不需要冗余的维度表，这只会使数据切片变得更加复杂。这种过程中我们得到的模式被称为雪花模式。 我们来看一个简单的雪花模式例子。我们将时间维度规范化为周、月和季度。 我们希望能够使用附加的规范化维度将立方体切片：周、月和季度。在本例中，我们假定季度是月的平行层次，这也就意味着我们不能将季度假定为若干月的聚合。由于这个原因，我们将使用一张范化表（是对 OLAP 查询的一项简单附加）预先选择时间维度。 最终雪花模式添加了规范化维度。 图6 带有范化维度的 Time 和事实 Flight 的雪花模式 当然，所有的维度都可以像时间例子那样进行规范化，这就导致了比较复杂的数据集市模式的出现。 由 Rational Rose 从雪花模式中开发的实现模式（数据模型）是完善的。 创建的约束在图中也没有显示。 雪花模式中可以存在切片，不仅仅在基本的 Time 维度上，也可以在规范化的 Week、Month 和 Quarter 维度上。 多对多关系 雪花模式的一种特殊形式是使用一种必要的数据结构以满足这项要求。 首先，我们将模型变更为事实和维度间的多对多关联。使用 Rational Rose，这只是关联基数的变更。 我们无法在关系数据库中实现多对多关联。实现多对多关联需要使用另一种雪花模式。 在下图中，我们关注一下已经开发的雪花模式的一部分，该部分处理多对多维度。 Rational Rose 生成了附加的维度表 FlightMenu，它是指 Menu 维度和 Flight 事实。 确定关系用于解决多对多关联。 对于雪花模式的架构师来说，最重要的一点就是识别多对多关系。简单对象视图可能会使设计员理解概念，而生成的数据视图有助于进一步深入有关实现的问题。 层次 乘客统计资料数据可以在 Passenger 维度的层次上构建。乘客可以根据邮政编码分组，然后再按国家进行分组。 层次通过使用聚合来指定。聚合定义了所包括的内容。Country 包含了 ZIP 编码，ZIP 编码包含了多名 Passenger 信息。 最终通过使用外键实现了聚合。 生成的约束仍然没有在图中表示出来。 使用聚合，维度可以在任何定义的级别上使用。分析空间可以通过 Passenger、ZIP Code或者 Country 进行切片。 一致的维度 星型或者雪花模式仍然仅仅关注于一个事实--在本例中就是Flight。那么复杂关系又是什么情况呢？ 对于每个事实我们都必须设计其各自的模式。如果我们想要进行复杂查询的话，它们就必须具有共同的维度--我们称其为一致的维度。 让我们使用 Pilot 作为一个维度，PilotFlight 作为一个事实来定义第二个星型模式。我们还要使用附加的 Flight Schedule 维度和 Time 维度。 第二个模式可以单独使用或者与 Passenger 模式结合使用，从而根据使用一致维度的飞行员维度来查询 Passenger 的满意程度。 图13 一致维度Time 和 Flight Schedule 即使在使用一致维度的数据仓库的简单结构中，Pilot 与 Passenger 之间的关系也是简单的。 在开发数据模型时，数据仓库将大量小型星型模式与雪花模式相结合形成了大型的数据仓库模式。 事实与维度的数据 如果我们想要得出一个平均记录，那么就必须为记录定义值以进行计算。我们可以将记录分为 0 到 10 级。这样就可以得到一个平均记录。平均值应该存储在维度表中，以用于简单的切片，其中我们只想进行一维切片。 Rational Rose 根据目标数据库的数据类型生成了实现属性。对象模型是用来定义数据库的数据源的。 结束语 对象模型定义了有关模式的全局结构的对象，和包括数据源的整体数据仓库。它代表了数据仓库中有关视图的对象，同时隐藏了实施细节。 数据模型是数据仓库的实现模型。数据模型可以从对象模型中生成，反之亦然。 Rational Rose 是设计星型模式和雪花模式的最理想工具。Rational Rose 是灵活可调整的，足以支持任何所需的数据仓库的概念，同时也提供了数据架构师和数据库管理员需要的功能以对数据仓库进行调整。 Rational Rose 为分析业务和开发用来实现数据仓库的需求提供了强大动力。 |
|
|
