Welcome 微信登录

首页 / 软件开发 / JAVA / 一个轻量级数据管理与分析平台的实现

一个轻量级数据管理与分析平台的实现2011-05-25 IBM 孙重波应用背景简介

在许多典型行业应用中,需要处理按照地域、时间或类别等维度产生并被管理 与维护的数据。被管理的数据分类方式基本维持恒定,而数据本身的内容(字段 )则需要根据业务需要不断变化。一方面,被管理的数据必须支持按照权限进行 增删改查操作;另一方面,还需要能够进行所见即所得的图表分析,如不同地域 之间数据的对比、时间维度数据变化规律的分析、不同类别数据的分类汇总、甚 至包括关联数据之间的统计关系维持等。

例如在电力行业,电网公司按照地域进行划分,其以电量、负荷为代表的核心 业务数据按照时间发生并被计量。这些被管理的数据具有一定的共性:数据所属 地域、数据的时间划分、数据的统计口径等数据的维度基本维持不变,但数据的 类别却随着经济形势发展变化、不同地区产业结构、甚至是地方政策等经常发生 变化。以地区的月度用电量为例,虽然电力行业有用电分类标准用以统一各地区 的用电分类和类别名称,但是经济发展的不均衡和产业结构的差异,使得不同地 区实际需要关注的用电分类大同小异,这要求系统提供的数据管理分析功能能够 对后台关系数据库中数据表列的变化有较强的适应能力;另一方面,地区差异性 还导致了不同电网公司关注的数据集合本身就有差别,这又要求系统提供的数据 管理分析功能能够适应增减数据库表的个性化需求。

暂且把本文需要实现的目标功能称为数据管理分析平台,它需要具备如下特点 :

这是一个用在产品中的功能,通用性和可维护性是第一位的。

这是一个 B/S 应用,用户使用浏览器访问系统。

用户在界面上可以对数据进行增删改查。

不同数据之间的计算关系维持对用户透明。

用户可以对查询到的数据进行作图分析。

跨数据库平台。

分析与方案选型

由于期望这个数据管理分析平台能够在不同的产品中复用,因此本方案应针对 数据存储在关系数据库中的共同特征进行抽象,而不是针对特定产品的业务逻辑 进行抽象。换句话说,应该针对关系数据库的表和字段进行抽象,而不是根据特 定产品的业务数据对象进行抽象。这允许最终实现能够通过简单配置来实现增加 和减少被管理数据类别(被管理表的扩展),以及对特定数据类别的增加和减少 被管理数据字段(被管理列的扩展)。

为何使用 JDBC

如果把被管理的数据,按照数据库表映射为 POJO,再针对 POJO 实现后续的 展现和 Persistence 操作,即使 DIY 出一个像 Hibernate 一样完整的 Persistence 工具来,需要增加被管理的数据类别时,仍然需要根据这个数据类 别对应的关系数据库表,映射出一个 POJO 类。这个过程产生了新的Java 代码, 意味着研发、测试、发布、实施等整个软件工程过程被启动了,把这个过程叫做 配置是明显不合适的。

当然,B/S 架构应用中常用的通过表单提交方式实现 CRUD 的方案就更不可取 了,以流行的SSH(Struts、Spring、Hibernate)模式为例,增加新的被维护数 据,意味着至少需要增加一个 JSP 页面用来生成用户界面,一个 ActionFormBean 用来接收表单的数据,一个 Hibernate 的表映射 POJO 对象, 不仅同样意味着启动一个完整的软件工程工程,而且工作量是随着新增数据类别 的数目线性增长的。

说到这里,可能您已经想到了数据库客户端,没错,数据库客户端就是一个典 型的所见即所得满足用户对数据进行增删改查需求的实现。如果我们对一个数据 库客户端进行改造,让它将查询结果以用户的业务视角进行展现,同时让它在浏 览器中运行,提供对所显示数据进行作图分析的功能,并且能够维持关联数据的 计算关系,那就圆满了。

可惜的是,我们不能像数据库客户端那样,让最终用户直接面临存储业务数据 的物理表,在一个数据库表的直接查询结果上进行增删改查操作。因为在满足数 据库设计范式的前提下,数据表中有很多我们称之为 ID 的字段。例如,一个按 地区存储某种数据的表中,表示地区的字段中,一定是存储了一个代表地区的ID 和另一个存储地区信息的数据表做外键关联,在查询时,需要做多表连接才能获 得地区 ID 对应的可以让最终用户读懂的地区描述信息。

因此,我们的数据管理分析平台,至少应该有能力向用户提供一个可以修改的 多表连接查询结果集。如果你想到了视图,那很好,因为确实很多关系数据库都 支持视图的更新,而且自打 JDK1.4 以后,JDBC 的RowSet 扩展也正式成为了 JDK 标准 API 的一部分,允许通过 JDBC 对查询结果集进行数据更新操作。如果 我们的数据管理分析平台是绑定在特定数据库平台之上的,那么仔细研究一下对 应的数据库平台对视图更新的支持情况,仔细规约出一套可行性视图设计方案也 许理论上是可能的。但是,我们的数据管理分析平台是希望能够跨数据库平台的 ,由于不同的数据库在视图更新上各有特点,采用这个方案,将会大大降低解决 方案的数据库无关性。

既然如此,不妨抱住 JDBC 的大腿再好好想想。在 Java 世界里,我们使用 JDBC 来完成对一行数据的增删改查操作,有两个必要条件:一是能获得数据表的 名称,二是唯一定位数据行的条件,通常是主键值。因此,对于一个连接查询的 结果集,只要能够确认被修改数据列对应的表,以及该列所在行对应的主键值, 使用标准 SQL,借助 JDBC 就能实现数据的更新操作。