交付有效且灵活的数据仓库解决方案:第2部分：仓库设计和数据建模

核心提示：此时，您要检查维度以确保：您具有需要用于回答问题的数据，交付有效且灵活的数据仓库解决方案:第2部分：仓库设计和数据建模(8)，在最细的级别定义了所有的测度，使用这些简化的分析问题来决定最终的星型模型中包含什么以及排除什么：余额和交易数基于交易量的聚集，模型的有效部分将通过设计阶段，并开始向用户提供好处，所以它们是派生的

此时，您要检查维度以确保：

您具有需要用于回答问题的数据。

在最细的级别定义了所有的测度。

使用这些简化的分析问题来决定最终的星型模型中包含什么以及排除什么：

余额和交易数基于交易量的聚集，所以它们是派生的测度。

所付利息的计算是将帐户利率乘以余额。这是基于帐户和基于月份的计算。因为利率是 Account 表的一个属性，所以需要添加 Account 维度表。正如您可以看到的，所付利息也是派生的测度。

假定净利润基于（投资收益）- （所付利息）的计算。因为投资收益是银行级的测度，而所付利息是派生的测度，所以净利润也是派生的测度。

从以上分析得出的结论有：

交易量是惟一需要的测度。

需要帐户维度来产生利率和投资收益信息。

模型元数据

在传统的开发周期中，完成一个模型之后，只有需要进行修改或其他项目需要数据时，才使用它。但是在该仓库中，要连续使用模型。仓库的用户不断访问该模型以决定他们需要用于分析组织的数据。仓库中数据结构的修改速度比操作性数据结构要快得多。因此，仓库的技术用户（管理员、建模师、设计师等等）也将定期使用您的模型。

这就是元数据所承担的任务。远远不只是一副漂亮的图画，该模型必须是所存储数据的完整表示，否则，它对于任何人都毫无用处。

为了正确理解模型，以及可以确认它满足了需求，用户必须访问按照容易理解的业务术语描述仓库的元数据。因此，您应在此时记录非技术的元数据。在设计阶段，您将向它添加技术元数据。

在仓库级上，您应提供仓库中可用东西的列表。该列表包含可用的模型、维度、事实和测度，因为当用户开始分析数据时，这些都将用作初始的进入点。

对于每个模型，提供名称、定义和目的。名称仅仅给用户提供一些搜索时关注的东西。它通常与事实相同。定义指定建模的内容，而目的描述模型用于什么。模型的元数据也应包含与之相关的维度、事实和测度列表，以及联系人员的姓名，以便用户在有关于模型的问题时，能够获得附加的信息。

模型验证

在投入大量时间和精力实现仓库数据库之前，与用户一起验证模型是一个很好的想法，特别是数据集市模型。进行该检查的目的是双重的。首先，它确认模型可以真正满足用户的需求。第二，检查应确认用户可以理解该模型。请记住，一旦实现了仓库，用户就会定期依靠模型访问仓库中的数据。无论模型多么好地满足了用户的需求，如果用户无法理解模型以访问数据，您的仓库都是失败的。

此时，验证是在高级别上完成的。与用户一起检查该模型以确认它是可以理解的。与用户一起，通过解决您将如何回答需求中指定的部分问题来测试模型。

模型不必满足用户的所有需求，这一点是好的。这不意味着您应停止并返回到开始。期望您模型的第一次切入满足约 50% 的需求。接受模型的这 50%（或者不管验证了多少），并开始进行物理设计。应将剩余的送回给需求的收集阶段。要么需要更好地理解需求，要么通常需要修改并重新定义它们。这常常会导致对已创建的模型进行添加和修改。同时，模型的有效部分将通过设计阶段，并开始向用户提供好处。

开发的重复和部分完整模型的继续创建是提供快速开发数据仓库能力的关键元素。

图 7. 仓库数据模型评估过程