第四课 设计和实现OLAP模型的实践步骤第二讲 逻辑模型定义OLAP世界中的逻辑模型和关系世界中的模型存在很大的差别。在关系世界中，逻辑数据模型不会派生出数据。在DDL和DML的商业实现中的SQL，不能够很好地支持一些需要在常规基础上执行的派生计算。在这个意义上来说，多维信息系统的逻辑模型都需要尽可能多地定义各种派生计算。给定对当前状况的理解、已知的问题、用户需求和对解决方案的约束，你如何定义一个在给定约束下满足用户需求并解决所有已知问题的多维模型呢？定义一个模型有特定的步骤吗？有必须明确的要素吗？从宏观上来看，你需要把模型定义为一个或更多个立方体，其中包含数据源（或指向数据源的链接）和派生的数据输出（或用户视图），并且所有的派生数据都能通过输入数据来定义。这将确保能够从数据源产生数据输出。图4.2.1是以前讲过的多维数据结构的一个版本，在此用来表示数据转换。竖线仍然表示维，但这里的分段表示的是粒度层次而不是个体成员。连接在一起的点表示了数据进入立方体的粒度层次。箭头表示计算方向。比如图的上半部分，我们可以看到销售数据是从立方体的基本层次进入并向上聚合。而图的下半部分，成本数据是从商店、商品的顶层、时间的最底层进入，并沿着商店和商品向下分配，但沿着时间向上聚合。那么你如何定义这些立方体呢？这方面有很多步骤及可供遵循的顺序。图4.2.2总结了需要定义的主要的项、每个项需要定义的频度和项的类型，以及应该遵循的顺序——通常这是设计环境的一项功能，另外还要为每种设计环境指定一个特定的起始点。每种设计环境都存在三种不同的起始点。图4.2.2中的顺序并不是绝对的。相反，通常在第一遍建立模型时会出现不同于这个顺序的例子。既然整个过程是一个交互的过程（需求理解、解决方案、设计、实现），不同起始点之间的差别可能在第一轮迭代之后逐步消失。尽管如此，我认为意识到为何会存在这些不同的起始点也是有意义的，更重要的是知道在基于任何特定工具的模型实现之前及实现过程中建立设计文档是可行的，并且是有价值的——遗憾的是这并不是人们通常的实践方式。由于在20世纪90年代早期就已经开始建立数据仓库，定义OLAP解决方案的最常见顺序是直接在OLAP软件内从关系数据库（RDB）内的星形结构的数据开始。典型的情况可能是把数据存放在一个或多个事实表及其关联的维表内。然后在OLAP环境内，数据仓库的数据被链接到OLAP模型，模型中建立了维表和OLAP立方体维定义之间的链接。这种链接通常也定义了大部分的维层次。在很多产品中，用户可以在此步骤处理维并建立产品相关的内部持久维和结构，再把维组合进立方体。立方体也通过此软件来展示。然后用适当默认的聚合函数定义变量。这里可以处理立方体中的数据，也就是说可以激活链接并把数据加入立方体并聚合。最后在OLAP环境内，可以定义和计算其他的派生数据。另一个最常见的顺序是在OLAP软件内从电子表格中的数据开始。这通常出现在财务应用中，其中当前状态是由努力为了同一个应用而共享电子表格的几个小组成员所定义的。当RDB星形结构开始和从电子表格开始主要的差别在于星形结构，因为它们已经规格化，能够非常容易地映射到OLAP立方体上。与之相反，电子表格可以有非常的不规则。因此，当从电子表格着手时，通常需要花时间分析电子表格，寻找可以作为OLAP维的行和列的名字。一旦找到，变量就可以从表格单元中拿到，与维集合（通常会，但并不一定都与单元值在一起）组合来构成变量立方体。然后，典型地在OLAP环境内定义聚合，建立到电子表格的链接，读入数据，定义进一步的派生数据。也可以在建立链接前定义派生数据，之后再建立聚合。模型先于数据的工作方式虽然在科学研究中存在，但在商业世界中并不常见，可能的例外是在建立演示时先建立模型，然后根据演示的需要虚构数据。当前，企业独立地为OLAP设计建立存储还并不普遍，一般都是将OLAP模型保存在实现设计的软件环境中。还有用类似电子表格的方式建立OLAP解决方案的。这很令人遗憾，因为任何具有合理复杂程度的已实现的模型通常都不是自我解释的。典型地，软件中甚至不会存在应用的完整描述。更恰当地说，关键设计决策只是通过互不相连的概要结构图、对话框、按钮及其他鼠标点击来体现。应用一旦建立，任何关于派生数据或其他功能的争论都是难以解决的，因为需求并未充分地说明。然后，几年过去了，最初建立模型的人都已经离开，任何接手修改模型的人都会陷入悲惨的软件考古中去。设计存储好的一面是建立和维护它们的基本技术是可以直接利用的，这些技术包括文字处理器、图表工具和简单数据库。考虑到开发及其后维护一个分析应用所投入的精力，我认为完整的模型设计文档对任何具有合理复杂程度的项目都是必需的——即使只是用来在开发者、用户和管理者之间保持清楚明了的沟通。在这个方面，有两种基本的途径方向：自顶向下或自底向上，以及用户向后或数据向前。当然，它们可以互相组合。一个设计可以自顶向下进行一点，然后用户向后再钻入更多一点，再结合源数据信息，再自底向上，等等。由于本部分的目的是确保你能够理解并处理OLAP解决方案相关的各个方面，而且我也公开阐述把设计文档作为解决方案过程的一部分，另外，自顶向下法通常是最容易理解的方法，所以，我就用它来组织本部分的内容。 【高层和低层的逻辑模型】逻辑的多维模型可能跨越许多抽象的层次，如果模型来自关系世界，那么它可能被当作许多不同的事情。高层的逻辑模型表达了用户能理解的主要元素。例如，一个典型的实体关系图表示了一个高层的逻辑模型，它描述了模型内基本的实体、属性和关系。图4.2.3给出了实体关系模型的示例。低层的逻辑模型包含了设计物理模型所需要的充分的细节。例如，图4.2.4所示的许多规范化的关系，包含了模型的所有逻辑元素。对低层逻辑模型而言，每一个键和非键的属性都被作为资料或数据点一样对待。鉴于实体关系模型和表格模式通常被认为是不同的模型，它们定义的高、低层模型都是某个逻辑多维模型的一部分。在多维世界里，立方体、维和层次构成了高层的、面向用户的模型形象。而且，典型的关系模式不管高层或低层都不描述发生的数据转换。与之相反，多维模型更明确地描绘了整个数据转换过程。
一共有 1 条评论