一、背景说明
在许多行业应用中，需要处理按照时间、空间或类别等产生并被管理与维护的数据。这些数据的分类方式基本维持不变，而数据本身字段则需要根据业务的变化而不断变化。这种情况就造成了：一方面，被管理的数据必须支持按照权限进行增删改查操作；另一方面，还需要能够进行所见即所得的图表分析，如不同地域之间数据的对比、时间维度数据变化规律的分析、不同类别数据的分类汇总、甚至包括关联数据之间的统计关系维持等。
本文所要描述的是：数据管理分析平台。它需要具备如下特点：
1. 这是一个用在产品中的功能，通用性和可维护性是第一位的。
2. 这是一个 B/S 应用，用户使用浏览器访问系统。
3. 用户在界面上可以对数据进行增删改查。
4. 不同数据之间的计算关系维持对用户透明。
5. 用户可以对查询到的数据进行作图分析。
6. 跨数据库平台。
二、分析与方案选型
由于期望这个数据管理分析平台能够在不同的产品中复用，因此本方案应针对数据存储在关系数据库中的共同特征进行抽象，而不是针对特定产品的业务逻辑进行抽象。换句话说，应该针对关系数据库的表和字段进行抽象，而不是根据特定产品的业务数据对象进行抽象。这允许最终实现能够通过简单配置来实现增加和减少被管理数据类别（被管理表的扩展），以及对特定数据类别的增加和减少被管理数据字段（被管理列的扩展）。
1、为何使用 JDBC
如果把被管理的数据，按照数据库表映射为 POJO，再针对 POJO 实现后续的展现和 Persistence 操作，即使 DIY 出一个像 Hibernate 一样完整的 Persistence 工具来，需要增加被管理的数据类别时，仍然需要根据这个数据类别对应的关系数据库表，映射出一个 POJO 类。这个过程产生了新的 Java 代码，意味着研发、测试、发布、实施等整个软件工程过程被启动了，把这个过程叫做配置是明显不合适的。
当然，B/S 架构应用中常用的通过表单提交方式实现 CRUD 的方案就更不可取了，以流行的 SSH（Struts、Spring、Hibernate）模式为例，增加新的被维护数据，意味着至少需要增加一个 JSP 页面用来生成用户界面，一个 ActionFormBean 用来接收表单的数据，一个 Hibernate 的表映射 POJO 对象，不仅同样意味着启动一个完整的软件工程工程，而且工作量是随着新增数据类别的数目线性增长的。
2、采用 Applet ＋ JSP
如果仅仅只需要满足一个展现数据的表格，那么表现层的选择没有任何约束，可以用在 Java EE 平台下的任何表现层技术都能满足。表格中的数据需要能够修改；如地区这样的列需支持下拉列表选择填写；表格中的数据可以支持复制、粘贴；必须允许用户根据表格中的数据制作图表；图表可以放大缩小；图表可以打印；图表可以导出成图片；……
随着要求的进一步增多，可选范围迅速减小，但是可以肯定的是，Java Swing ＋ JFreeChart 差不多可以满足所有要求。考虑到这个功能是用于 B/S 架构系统中的，选择嵌入 JSP 页面的 Applet作为表现层策略，是合适的。一旦表现层确定为 JSP ＋ Applet 的方式，意味着客户端获取到了最大的可交互性。在服务器端查询的结果集，进行简单封装，采用对象序列化方式，将其传送到 Applet 端，Applet 端使用 Java Swing 构造显示的图形界面，并处理用户的操作。
3、使用模板 SQL 实现查询
在用户界面中，像时间和地区这样的数据筛选条件，可能分别用下拉列表选择和树形结构实现，以增强直观度和易用性。换句话说，在SQL 语句中，需要根据用户在界面上的选择结果，生成适当的 where 子句以响应筛选条件。
4、记录用户的增删改操作
首先重复一下对关系数据库中的一行记录进行修改的两个必要条件：一是能获得数据表的名称，二是唯一定位数据行的条件，通常是主键值。通过上一节描述的模板 SQL 中查询列的约定，可以确保目标数据表的主键列都被查询到数据结果集中，并被封装后传送到客户端 Applet 以供显示。因此，对数据增删改支持的实现，其实就是需要实现记录用户的增删改操作，并由服务器端根据该记录生成系列 SQL 语句并执行。
修改操作，可以分为两种情况，一种情况是修改非主键数据列，另一种情况是修改主键数据列。前者是安全的，也是容易记录的；后者则会带来一些问题：一是主键重复问题，不过这个无法由程序替用户解决，二是主键被修改后，相当于数据行的唯一定位条件丢失，如果不能找回原来的主键值，则无法完成相应的 Update 操作，还可能更新错误的数据行。
删除操作，也有两种情况，一种情况是删除时，该行数据的主键列未被修改，另一种情况时，删除操作时，主键列已经被修改过了。结合修改情况考虑，也会出现类似的情况，由于主键列已经被修改而造成删除操作无效（主键对应的记录不存在）或者删除了错误的记录（主键修改后，与另一条已经存在的数据记录一致）。
对于增加，情况稍微复杂一点，一来是对于外键关联数据，要求用户记住描述字段来填写是不合理的，理应提供下拉列表供用户选择；二来数据表中可能有标识性的 ID 字段作为主键，例如自动增加的 ID 主键，可能由数据库维护，也可能由程序维护，需要特别处理。考虑到需要适应不同数据库平台的限制，保险起见，可以约定都使用程序维护。
5、维持关联数据的一致性
一旦涉及到数据修改，就有可能涉及到数据一致性问题。数据库触发器理论上是一种选择，但在本文的场景下，它至少有两方面缺点。首先，它是数据库平台相关的，编写的触发器和存储过程有移植代价；其次，数据之间的计算关系，属于业务逻辑，在当前分层而治的主流架构思想下，在数据库中处理部分业务逻辑，这属于业务逻辑的不合理蔓延。只要换种思路，事情就变得简单了。维持关联数据一致性的逻辑，在 Java 类中实现；当对应的数据被修改后，只要能够出发相应 Java 类的调用就行了。对一个被管理的数据类别，数据被修改后，可能出发的关联数据计算是既定的。在配置时，增加一个新的配置项，即数据修改后需要调用的统计实现 Java 类就可以了。配置项的内容可以直接使用 Java 的类名，约定提供默认无参数构造函数，实现统一接口，便于进行 reflect 调用就行了。
6、架构设计
根据前面的分析，确定使用 Applet 作为表现端，服务器端则采用 Servlet 与 Applet 进行通信，接收来自 Applet 的用户请求，并将处理后的结果返回给客户端。如下图所示：
图1. 架构简图
其中，Applet 和 Servlet 之间的通信使用 java.net.URLConnection 和对象序列化实现，Servlet 和 Database 当然是通过 JDBC 执行 SQL 语句来完成交互。
三、优势与局限性分析
本文所述的方案是应用于 Web Application 的，对于经常需要添加新的数据类别的应用，可以免去针对每种新增数据重复开发对应的前端页面和后台处理类等服务器端程序。通过简单配置即可对新增的数据表对应的数据类别完成增删改查系列操作，也同时获得了相关的图表分析功能，相关的分析功能越多，这个配置产生的收益就越大。
本方案也有局限性，由于本方案是基于 JDBC 的，因此当本方案和基于 O/R Mapping 实现 Persistence 层的 Web Application 共存时，与 O/R Mapping 的缓存机制恐无法兼容，因为本方案相当于不经 O/R Mapping 层直接修改了数据库表。另外，本方案的数据被查询出来后，处在离线状态，不同用户在同一时间对相同数据的修改动作，是相互覆盖的，至少在服务器端实现同步处理之前是这样的。如果使用系统的用户数量有限，且各自维护的数据没有重叠，基本上是安全的。如果使用系统的用户数量很大，彼此数据重叠，则需要考虑控制同步问题，很明显本方案是不适合用在并发访问数量非常大的匿名访问系统中的。
四、【参考文献】
[1] 王志梅 主编 《关系数据库基础与技术》 国防工业出版社 2005年01月；
[2] 王珊，萨师煊 著 《数据库系统概论（第4版)》 高等教育出版社 2006年05月；；
[3] 邵佩英 编著 《分布式数据库系统及其应用》 科学出版社 2005年03月；
[4] 魏祖宽 主编 《数据库系统及应用》 电子工业出版社 2008年08月；
|
