使用 JOLAP 实现复杂分析查询

Shashank Tiwari 在本文中对 JOLAP 进行了简要介绍，它是一种标准规范，支持在 Java™ 企业平台上创建和操纵 On Line Analytical Processing (OLAP) 数据和元数据。

<!-- START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!-- END RESERVED FOR FUTURE USE INCLUDE FILES-->

在过去几 年，OLAP 逐渐成为处理数据仓库和商业智能使用的多维数据的流行方法。OLAP 服务器和应用程序随处可见，并且很多存储模式、查询机制和访问策略也已经被开发出来，以满足复杂分析查询的业务需求。JDBC API 一直被用作在 Java 平台上访问和操纵维度数据的一种代理机制，但是，使用 JDBC 会折损维度模式本身的优点。通常的做法是将 JDBC 与一个专用扩展结合使用，以弥补这一点。然而，这意味着只能局限于特定的实现。

本文的目的是向熟悉 OLAP 的 Java 开发人员介绍 Java OLAP (JOLAP) API。本文描述了它的核心组件和相关的包，并提供 JOLAP 查询和检索操作的一个例子。本文还简要地讨论 JOLAP 与 JDBC 之间的相似之处，以及 JOLAP 与用于多维数据的 XMLA 查询语言 mdXML 之间的关系。请从 参考资料 小节下载 JOLAP API 规范。

JSR 69 JOLAP 是一种健壮的 API，集合了很多重要理念，但还不是一个标准。 由于各种各样的原因，在 2004 年通过最终草案后，JSR 69 的规范制定就被搁浅。就目前而言， JOLAP 主要被用作其他工作的基础。Mondrian 几年来一直包含了 JOLAP API 的部分实现，而 Hyperion 的 XML for analysis (XMLA) 实现也使用基于 JOLAP 规范的 Java API。无论 JOLAP 自身最终是否能得以标准化， 它将继续推动标准化开发人员在 Java 环境中访问和操纵多维数据的方法

什么是 JOLAP？

Java Community Process JSR 69 计划为 OLAP 服务和应用程序创建了一种简化的同时又非常全面的统一 API。JOLAP 规范的目的是部署在 Java 企业平台中或者与之进行交互，它充分利用 Common Warehouse Metamodel (CWM)，CWM 是以独立于供应商的方式定义逻辑 OLAP 结构的一个 OMG 标准。它还利用 Meta Object Facility (MOF)、XML Metadata Interchange (XMI) 和 Java Metadata Interface (JSR 40)。（请参阅 参考资料 ，以了解关于支持 JOLAP 的这些技术和其它技术的更多信息。）

JOLAP API 从概念上分为 4 个部分：

• 元数据接口和 XML ：JOLAP 元数据接口是 CWM 的一个子集，包括针对特定于 JOLAP 需求的扩展。 JSR 40，即 Java Metadata Interface，简化了 OMG MOF 的 Java 语言映射，并被用于根据模型生成 JOLAP 接口。
  
  
• Reflective 服务 ：JMI Reflective 服务使 JOLAP 可以进行自身检查并发现可用的元数据。当实现模型驱动的架构时，这些功能是最密切相关的。
  
  
• 查询接口 ：查询接口由两个模型组成。JOLAP 的查询模型处理 OLAP 查询管理，它的源模型方便了特定于供应商的 OLAP 原语扩展的实现。按照规范的定义，源模型是 JOLAP 的一个可选功能。
  
  
• 游标接口 ：JOLAP 的游标接口定义用于管理 OLAP 查询返回的多维结果集的功能。

下面的小节将深入讨论这些组件。

JOLAP 与 JDBC JOLAP 和 JDBC 以类似的方式处理数据检索。在 JDBC 中，首先创建一个连接，然后使用该连接创建一条语句。接着用一个 SQL 查询填充该语句，再调用执行该语句的方法，最后返回一个结果集。在 JOLAP 中，首先是获得一个连接，然后创建并填充一个查询对象，接着调用一个 getter 方法填充游标。和 JDBC 一样，JOLAP 调用特定数据类型的 getter 方法。然而，与 JDBC 不同的是，JOLAP 可以处理 DimensionView 上的属性选择。

JOLAP 模型

JOLAP 模型是由一些相关子模型组成的一个 UML 模型。而包组成了模型的逻辑分组，从这一角度来讲，JOLAP 分为 6 个组：

• 核心元数据 由 CWM 元数据定义改编而来，后者以独立于供应商的方式定义 OLAP 元数据。
  
  
• 资源模型 定义连接和连接工厂，它们是基于 Java Connector Architecture Common Client Interface (JCA CCI) 的原则。资源模型不同于标准的 JCA 实现，因为它包括了 OLAP 风格的交互。
  
  
• 查询模型 定义维度选择、边界、立方体视图以及维度数据的聚合与操纵等概念。模型还包含了不对称和事务型特性。
  
  
• 游标模型 定义如何查看查询返回的维度结果集。
  
  
• 源模型和服务器端元数据模型 被定义为可选包。源模型提供对原语查询操作的支持；服务器端元数据模型定义面向部署的类使用的其他元数据。

 

回页首

连接到支持 JOLAP 的服务

根据 JOLAP API 规范，可以使用该 API resource 包中的类连接到支持 JOLAP 的服务，例如商业智能服务器和数据集市。这些类提供了 JCA CCI 的 InteractionSpec 架构以外的功能。

Connection 和 ConnectionFactory 是资源包中两个主要的类定义。ConnectionFactory 类用于获得一个 Connection 。创建连接时，可以传递参数，也可以不传递参数。对于容器管理的登录场景，可以创建一个不需传递参数的默认连接。对于组件管理的登录场景，则必需使用参数来创建连接，这种情况下可使用 ConnectionSpec 创建连接。

Connection 表示到支持 JOLAP 的资源的一个活动连接，它包括的帮助器方法可以简化 OLAP 风格的交互。可以使用 Connection 执行元数据查找和查询操作。下面给出了两组功能以及定义：

• 查询模式和相关对象 ：获得可用模式，设置默认模式，获得默认模式，以及访问与某个模式相关的维和立方体。
  
  
• 创建查询对象 ：创建 CubeView 、 EdgeView 和 DimensionView 对象。

Abortable 、ResourceAdapterMetadata 和 ConnectionMetadata 类也被包括在资源包中：

• Abortable 只有一个方法 abort() ，该方法可用于取消一个长时间运行的操作。这种中断机制不是强制性的，不是所有的 JOLAP 提供程序都支持。
  
  
• ResourceAdapterMetadata 提供用于获得与适配器名称、适配器供应商、适配器版本、规范名称、规范供应商、遵从性级别以及规范版本相关的数据的 getter 方法。JOLAP 规范定义了两种遵从性级别，它们的差别在于一个具有最基础的核心功能，另一个是具有可选功能的核心功能。
  
  
• ConnectionMetadata 定义用于获得 EIS 产品名称、EIS 供应商和 EIS 用户名的 getter 方法。

JOLAP 和 XMLA JOLAP 和 XMLA 都是为标准化 OLAP 和商业智能上下文环境中数据和元数据的管理和交换而做的工作。XMLA 是一种独立于编程语言的语言接口。它为多维数据定义了一种叫做 mdXML 的查询语言。mdXML 之于多维数据，相当于 SQL 之于关系数据。虽然 JOLAP 和 XMLA 有一些相互重叠的功能，但是它们可以一起使用，主要原因是因为 XMLA 被实现为 Web 服务，而 JOLAP 支持 Java 企业（具有 SOAP 功能）Web 服务架构。 JOLAP 不是实现 XMLA 所必需的。

独立于供应商的 OLAP 元数据

JOLAP 的核心元数据模型基于 OMG Common Warehouse Metamodel。 CWM 清楚地区分客户端元数据与服务器端元数据，客户机需要前者来查询 OLAP 资源，而 OLAP 服务器需要后者来处理客户机请求。JOLAP 规范采纳相同的区分方法，也提供了客户端元数据和服务器端元数据，客户机端元数据形成 OLAP 元数据的核心，而服务器端元数据为那些欲将实现建立在 CWM 模型基础上或者以 CWM 和 XMI 格式交换数据提供便利。现在，让我们将目光投向客户端元数据，这种元数据用一些附加扩展映射 CWM 客户端模型。本文在后面将简要地讨论服务器端元数据。

Schema 、 Dimension 、 和 Cube 是三个最重要的元数据定义：

• Schema 是 OLAP 模型的逻辑表示。它还被用作模型中所有元素的容器。
  
  
• Dimension 是多维结构的一个纵坐标。它表示具有相同意义的一组惟一的成员或值。
  
  
• Cube 是具有若干相同维的一组度量。一个立方体的每个数据点或单元是它的维成员的笛卡尔乘积。

核心元数据包中的其它类方便了维、立方体和模式之间的相互关联；帮助它们以结构化的方式组织起来；或者提供操纵这些对象所使用的 Member 等元素的机制。

可以使用各种帮助器类，以分层的方式组织维。LevelBasedHierarchy 用于仅根据级别或者同时根据级别和链接节点定义层次。ValueBasedHierarchy 用于根据拓扑结构定义层次。基于值的层次不考虑级别，因而可用于仅根据链接节点创建层次。

HierarchyLevelAssociation 用于建模 Dimension 的不同级别与它的 LevelBasedHierarchy 之间的交点。CubeDimensionAssociation 用于将一个立方体与它的维度相关联。

Member 、MemberValue 、MemberList 、CurrentMember 、MemberQuatifierType 和 MemberObjectFactories 用于存储、操纵、访问和创建存储在特定维中的惟一值的实例。其中像 Member 和 MemberValue 等既可以作为数据，又可以作为元数据，具有双重继承。

这些客户端元模型元素是从 CWM 元模型继承的。

 

回页首

多维查询

JOLAP 规范非常全面，它涵盖了查询模型、查询需求、格式良好性和查询事务模型。本文只对 JOLAP 查询模型作一个高度概括。请参阅 参考资料 ，了解完整的规范细节。

JOLAP 的查询需求和模型简化三种常见 OLAP 查询的创建和执行，即多维查询、边界查询和数据查询。

• 维度查询 是对单维度成员操作的成员选择。维度查询在 OLAP 的 Dimension 、Hierarchy 、HierarchyLevelAssociations 和 Level 属性级别上进行查询、过滤和排序。
  
  
• 边界查询 由一组单维度或多维度查询组成，从总体上描述结果集的坐标系统。
  
  
• 数据查询 表示立方体中的数据选择。

DimensionView 、EdgeView 和 CubeView 是 JOLAP 查询模型中最重要的三个定义。可以组合这些表示维、边界和数据查询的基本查询类型，以建模更复杂的情况。

查询模型中其他重要的子模型与过滤和排序、计算成员、派生属性以及不对称选择有关。

可以根据简单或复杂的过滤器选择维度成员的子集。基于过滤器的中间选择具有相关的 setAction 操作。Initial 将选择的集合看作成员的初始集合。Append 将成员添加到列表的尾端。 Prepend 将成员添加到列表的开头。 Insert 和 Difference 根据 dimensionInsetOffset 属性添加成员，或者添加前一个集合中存在而当前集合中不存在的成员。另外，DataBasedMemberFilter 可用于根据数据表示的条件过滤维度成员。

JOLAP 包括三种类型的排序定义：基于成员属性的排序、基于成员层次的排序以及基于立方体数据值的排序。

计算成员是派生成员，它不在某一个维度上，而是从已有数据派生而来。聚合、组合之类操作的操作符可以是以成员、属性或常量作为输入的操作符。类似地，派生属性是临时的用户定义属性，是根据其他值得到的。

清单 1 显示了一个简单的调用，可以连接到 JOLAP 资源、查询该资源并检索数据：

清单 1. 查询和检索数据

                
....
env.put( Context.INITIAL_CONTEXT_FACTORY,
    "com.company.javax.olap.resource.ConnectionFactoryImpl" );
....

//  Get the ConnectionFactory from JNDI
javax.olap.resource.ConnectionFactory connFactory = 
    (javax.olap.resource.ConnectionFactory)initCtx.lookup("MyJOLAPServer" );

//  Create a connection spec
javax.olap.resource.ConnectionSpec connSpec = 
    (javax.olap.resource.ConnectionSpec)connFactory.createConnectionSpec();
connSpec.setName( "some userId" );
connSpec.setPassword( "some password" );

//  Connect to the JOLAP resource

javax.olap.resource.Connection conn = 
    (javax.olap.resource.Connection)connFactory.getConnection(connSpec);

//  Get list of Dimensions
//  and do something ....

List dimensionList = conn.getDimensions()
Iterator dimensionIter = dimensionList.iterator();
while ( dimensionIter.hasNext() )
{
javax.olap.metadata.Dimension myDimension =
    (javax.olap.metadata.Dimension)dimensionIter.next();
....
....
}

//  Close the JOLAP connection
conn.close();
}
....

回页首

操纵结果集

游标模型 API 与 JDBC ResultSet API 非常类似。游标模型天生就具备专用于维度结构的概念，而在关系场景中意义不大。实际上，维游标类似于 SQL 结果集，只是多了一些附加功能。RowDataAccessor 和 RowDataNavigation 接口定义 CubeCursor 、DimensionCursor 和 EdgeCursor 类的大部分功能。

游标模型提供导航和管理 JOLAP 查询返回的结果集所需的类，例如清单 1 展示的类。它能提供对 OLAP 非常关键的多维透视图。 游标模型考虑了不对称和大型结果集的情况。对于大型结果集，考虑使用增量结果集访问。

 

回页首

可选包

面向部署的元数据

如前所述，服务器端元模型表示 CWM OLAP 元模型的面向部署部分。某些客户端定义也与部署相关。 Cube 、Schema 、HierarchyLevelAssociation 和 ValueBasedHierarchy 之类的客户端定义都被用于部署的服务器端类子类化。服务器端子类还引用与客户端类无关的实体。例如，服务器端子类 Schema 与 DeploymentGroup 之间存在关联，后者并不在客户端。 所有服务器端元模型定义都在 javax.olap.serversidemetadata 包中。

原语查询操作

源 模型是基于源对象 MetadataObject 的低级模型，具有根据 type 、inputs 和 outputs 定义的特定结构。输入和输出本身可以作为源。源元素是具有标识符（一个惟一值）的一条记录和一组输出记录。当元素表示关系表中的一行或多维立方体中的一个单元时，源元素的定义就变得更加复杂。

源模型中还包括一组健壮的方法和模板。 join 方法可能是所有可用方法中最为重要的。模板是高级模型与低级模型之间的桥梁，当模板本身管理源时，可以修改立方体、边界和维度选择等高级对象。模板是有状态的，可以在任何时候修改。因此，当使用原语方法创建源时，源可以是动态的，而不是静态的。

 

回页首

结束语

本文介绍了 JOLAP API 规范，并描述了它的核心组件。本文还介绍了它的相关包，并演示了一个简单的 JOLAP 查询和检索操作。请参阅 参考资料 ，了解关于 JOLAP API 和文中讨论的其它技术的更多信息。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• JSR 69: Java OLAP Interface (JOLAP) ：访问 JCP 主页，查看 JOLAP API 规范的最终草案和该计划的相关信息。
  
  
• The Data Warehousing, CWM, and MOF Resource Page ：这里有很多与 Common Warehouse Metamodel 和 Meta-Object Facility 相关的文档。
  
  
• OMG's MetaObject Facility 主页 ：了解关于 MOF 规范及其使用的更多信息。
  
  
• JMI 主页 ：了解关于 Java Metadata Interface 和 JMI Reflective Services 的更多信息。
  
  
• XMLA 主页 ：了解关于 XML for Analysis 标准的更多信息。
  
  
• developerWorks Java 技术专区 ：这里有数百篇关于 Java 编程方方面面的文章。
  
  

获得产品和技术

• 下载 JOLAP API ：Java 平台上处理维度数据的最终草案。
  
  

讨论

• 通过参与 developerWorks blogs 加入 developerWorks 社区 。

关于作者

		Shashank Tiwari 是 Saven Technologies 公司的首席架构师。多年以来，他参与了使用多种技术的高性能分布式应用程序的设计和开发。他的工作还包括为公司提供构建健壮测试、数据密集、可伸缩软件应 用程序方面的咨询。他定期为技术杂志撰写文章，出席研讨会，并指导其他开发人员和架构师。