摘 要：本文回顾了工程数据库这一概念的提出，分析了工程数据库系统的相关需求和研究现状，并在此基础上提出了以Web服务为基础的工程数据平台代替纯粹的工程数据库系统的方案，并对该方案的架构和方案实现的几个重点问题进行了详细分析与讨论。本方案在现有较为成熟的关系型数据库和文件系统的基础上，在程序逻辑的帮助下，实现了对工程数据库系统的特有需求、保证了数据的完整性和一致性，并通过Web服务访问层实现与工程系统的互联互通。
关键词：工程数据库; Web服务; 版本控制; 工程事务
1 概念提出
自二十世纪60年代数据库诞生以来，数据库技术不断发展，各种基于数据库的应用也层出不穷，现在可以说绝大部分的应用系统都离不开数据库的支持。
数据库技术的不断发展，已经成为现代信息技术的重要组成部分，渗透到人们生产活动的各个领域；而同时随着人们生产活动的信息化水平不断提高，又对数据库技术提出了更高的要求。
当代，数据库应用最成熟的领域是一般的信息管理，即面向事务管理的数据库应用，现有的商品化数据库管理系统基本都是为此目的而设计的，它们主要解决数据的完整性和一致性，支持海量的存储，大量用户并发访问等等。
然而在工程领域，常常有一些特有的数据存储需求，例如需要存储产品的设计方案，不同于一般意义上的数据，设计方案的自身结构本身需要经常改变，这使得擅长处理静态数据的常规数据库显得无能为力。在长时间的山寨作坊式存储，即使用文件系统或以文件为基础的专用数据库管理系统来进行数据存储之后，随着这类工程系统的规模越来越大，人们开始意识到这种以文件为基础的系统不论是系统开发、维护，还是系统的使用都带来一系列问题，不利于各种工程的集成与管理，因而人们很早就提出了工程数据库的概念。
2 系统需求
根据工程数据库所应用的背景并参考相关资料，我们可以列出工程数据库必须支持的一些特性，笔者对资料中相关特性的描述进行了全新修订，这些特性主要有：
a) 支持多应用访问
即工程数据库需支持多应用程序同时访问。
b) 支持数据结构的动态修改
数据库所存储的数据常常需要改变自身的数据结构，例如，产品的计算机辅助设计（CAD）是一个变化频繁的动态过程，不仅数据变化频繁，而且数据的结构也会有所改变，这就要求工程数据库具有动态修改和易于改变数据结构的能力。因此为CAD/CAM应用设计的数据模型必须支持各种工程数据类型和工程应用中复杂的物理模型的修改和管理。
c) 允许暂时的数据不一致
工程中解决问题需要反复修改，反复尝试，在这个过程中数据的不一致可能发生，此时工程数据库应该支持暂时允许这种不一致的数据存在，并加以管理，等设计完成时做最终的校验。
d) 支持存储和管理各种设计结果版本
在人工设计中，存在几种设计版本的情况是经常发生的，每一个设计版本尽管不同，但均满足设计所要求的全部功能，它们可供选择。一个支持工程设计的数据库管理系统应当具有一个设计任务多个版本管理的能力。
e) 支持复杂的抽象层次表示
设计过程常被看成自顶向下的工作方式，即将复杂的问题不断分解到子问题层中。例如，工程所涉及的工程图很少是仅由一张图来表示，通常采用分层表示法，即上层工程图中的一个符号表示下层某一张子工程图（即上层的一个抽象部件符号代表下层若干个部件的组合），这些子工程图中的一个符号又能表示更下一层的某一张子工程图等。所以数据库应支持自顶向下逐层表示的数据模型，直至最下层为止的基本原子数据对象。
f) 支持数据库与应用程序的接口
为了支持工程数据库的应用过程，数据库必须能与多种程序语言交互。
g) 支持工程事务处理
在工程应用中，解决一个工程问题需要花费很长时间，涉及的数据量也很多，所以工程数据库因对此类事务进行特别处理。
3 研究现状分析
从1975年美国洛克希德公司的Eastman首先描述一个用于CAD的数据库，1985年第四届国际工程软件会议上，正式提出工程数据库的概念，并详细讨论了工程数据库的特点、类型、术语以及在集成工程设计中的显著作用，到现在20多年过去，虽然各种研究仍然在继续进行，但始终没有一种真正可被商用的工程数据库产品投入市场。
那么，究竟是什么原因导致对工程数据库这一系统的研究徘徊不前？在笔者看来，最关键的因素是在研究过程中，研究者仍然怀着一种旧的观念、思想去试图创造一个纯净的数据库管理系统，使之能够满足工程数据库的各种应用需求。
在数据库系统的设计中，一般需要考虑数据库的应用层、语言处理层、数据存取层和数据存储层的设计与实现，在这其中特别重要的是数据模型的建立。根据“工程数据库设计与应用”课程电子教案中对传统层次、网状和关系模型的介绍，可以清晰的看出，工程数据库由于其本身的特殊性以及和工程结合的背景并不能直接使用这些传统模型。因而，传统意义上的研究，都希望通过创建全新的数据模型或改良传统模型，从而实现一个工程数据库系统。
从上一节提到的工程数据库相关需求可以看出，这一需求不同于一般数据库概括的数据存储需求，而是一个具有应用背景假设的系统需求。那么笔者不禁要问，这究竟是实现一个在工程领域可以通用的数据库，还是一个能满足这些需求的系统平台？
可想而知，在这样的需求之下，很难用数据库系统设计的方式去设计数据模型，从而实现一个满足要求的工程数据库；甚至降低标准到实现一个用于CAD/CAM系统的工程数据库，也常常会因为业务逻辑在数据库系统设计中的渗透，使得数据库层和系统层界限不清（此时又回到了最初无数据库的状态）。
4 基于Web服务的解决方案
4.1 解决方案的提出
回到“工程数据库”概念的提出，即人们希望创造一种面向工程领域的数据库系统，使之能被各种工程系统所用，从而改变这些系统数据存储各自为政的局面，改变“以文件为基础”的存储架构，从而摆脱这一个个孤岛系统所带来的系统开发、维护和使用的问题，并最终实现此类系统的集成互通和统一管理。
如果我们摈弃“数据库”这个概念，或者从广义的数据库（即存储数据的系统）出发来看待这个问题，在当代的信息技术背景之下，我们可以发现解决这个问题的其他可能性。我们完全可以利用已经比较成熟的关系数据库系统、文件系统，构建一
个开放的分布式的数据平台（即构建一个工程数据云），通过Web服务的方式使之能与各种工程系统相集成，从而达到统一的数据管理与共享。
4.2 数据平台的架构
实质上这一数据平台（系统架构图请见下页）是在关系数据库系统和文件系统的基础上建立了一层Web服务兼容层，在代码层面、数据库层面基础上共同保证数据的一致性、完整性以及存储的效率。
在数据平台内部，用代码逻辑和相应状态信息保证数据的一致性和完整性并满足更多工程数据库所需要达到的功能；根据来源数据的不同情况，使用关系数据库或者文件系统进行存储（对于图片等二进制数据通过文件系统直接存取，对于静态结构化数据通过数据库系统直接存取，对于动态结构化数据则通过XML文件进行存取）；在CVS等类似版本控制系统的基础上，实现文件的版本控制。
对于数据的访问和共享上，数据平台可以使用Web服务技术等远程访问技术达到对数据的统一存取和数据共享，为了存取的方便性以及与旧式系统集成，一方面可以在系统中枢基础上实现ODBC访问兼容层，另一方面可以在Web服务层面实现对SQL语句（以及扩展SQL语句用于工程数据库特定需求，系统中称之为D-SQL）的解析与执行。由于Web服务等本身已经成为国际标准，其可与各种系统进行开发和集成。因而实质上，该数据平台实现了一个基于Web的工程数据库系统。
根据以上设想，笔者对系统进行了简单设计。如系统架构图所示，笔者认为系统应该拥有三层结构，访问层、系统核心层和数据存储层。
访问层实现了Web和Web服务两种访问接口。Web访问接口主要提供给数据平台管理员管理的接口，既允许类似管理系统的管理方式，又支持D-SQL脚本的操作方式。Web服务访问接口则主要用于工程系统与工程数据平台的交互，也支持一般的服务访问方式和通过服务调用模拟的D-SQL交互。
系统核心层是系统的控制中枢，主要工作有(1) 实现ODBC访问方式的兼容层，(2) 完成D-SQL的解析与执行，(3) 控制数据的实际存储，(4) 管理内部关系型数据库和文件系统。
数据存储层是数据实际存储的区域，在关系型数据库和文件系统结合自身优势共同帮助下，既满足工程数据库对数据的存储要求，又保证数据的一致性、完整性和存储效率。
4.3 几个重要问题
a) D-SQL语言的设计和内部策略
D-SQL语言是SQL语言的超集，允许执行一般意义上的DDL、DML和DCL语句，在此基础上D-SQL(1) 扩充支持文件类型、可变结构类型的数据字段，(2) 支持面向对象方式的访问，(3) 实现含有语义背景的一些其他功能。此处主要讨论(1)和(2)的内部策略，(3)类似于管理系统的实现此处不再赘述。对于D-SQL的
对于问题(1)，系统中可变结构类型使用XML文件的方式存储（在XML数据处理模块的帮助下，可以方便的实现XML的数据修改和结构改变），然后通过和文件类型类似的方式进行操作。对于文件类型的操作方式，这里不妨讨论带有版本控制的文本文件的处理方式（其他类型类似）。若创建表Table_With_Version_Controlled
_Text_File，表中有一字段PROPERTY_NAME为TEXT_WITH_VERSION_CONTROL类型，则系统内部创建同名数据表，并将该文件类型的字段替换为字符类型的PROPERTY_NAME_FILE
_PATH字段和字符类型的PROPERTY_NAME
_FILE_TYPE字段，前者存储了文件存储的实际位置，后者内容为TEXT_WITH_VERSION
_CONTROL，表示存储的是带版本控制的TEXT文件。当对数据进行增删查改时，若涉及到文件字段，系统核心层直接操作对应的文件，在版本控制模块的支持下实现文件的操作（由于版本控制信息直接存储在文件系统中，因此这些信息不在关系型数据库中存储）。
对于问题(2)，这里主要指的是数据表映射为一个类，允许数据字段为另一个数据表类，允许类的方式操作新增的文件类型和可变结构类型字段。文件类型、可变结构类型与类的映射问题主要局限在对D-SQL语句的解析和调用XML数据处理模块上，本文不再赘述。对于数据表和类的映射以及数据表类的数据字段，笔者参照了Oracle数据库中的面向对象设计技术，算法为：若创建类CLASSA，则创建表TABLEA，使用CLASSA的各个字段填充TABLEA，若CLASSA拥有例如CLASSB等的复杂字段，在TABLEB没有创建的情况下，创建TABLEB，并在TABLEA中外键应用TABLEB的ID，如此迭代直至所有表全部建立。
b) 工程数据库与内部关系型数据库的关系处理
系统中，两者基本为一一对应关系。若管理员/应用程序创建DB1，则系统也在关系型数据库系统上创建DB1；但某些时候会在General Information这个数据库中记录有关信息。若查询中使用跨库表连接，主要通过系统内存镜像连接来完成，在合理的缓存与优化下，效率可和单表连接相媲美。
c) 工程事务的处理
由于系统对文件系统和多个数据库的同时使用，使之不能照搬数据库事务，由于工程数据事务的长效性，笔者使用了检入检出机制，即修改时自动检出数据，提交后方生效，若提交时远程版本与本地检出版本不一致则提交失败。
在具体实现上，数据库层面为每一个数据表创建副表，并增加UID、BASE_VERSION，作为用户的本地检出版本存储容器，并在原表中增加CURRENT_VERSION字段，一旦在事务中对原数据进行修改，则检出原数据到副表中，并进行修改，提交事务时检测副表中的BASE_VERSION和CURRENT_VERSION是否一致，在一致的情况下覆盖原表信息并删除副表信息，事务提交成功。文件层面上，对不带版本保护的文件进行整体版本控制，对已经带版本控制的文件新建一个分支，事务的提交反应为当前文件版本的修改和分支的合并。
4.4 系统的改进与提高
本设计方案尚未包含对分布式数据库和文件系统的支持，如果能结合云计算相关内容，则系统的可扩展性将大大提高。
5 结语
笔者认为IT系统主要在其有用性，而不是在其纯粹性，在Web服务的帮助下构建的数据平台事实上充当了工程数据库的角色，也就是在一定程度上实现了这一系统，而不需要拘泥与纯粹的数据库系统实现。通过更高层次的实现方式，提供更为先进的服务，反而更加受到人们亲睐。例如Amazon提供的Web数据库已经被许多系统使用，该系统即在内部建立了云计算数据中心，并提供了Web服务的数据访问方式和基于Web服务的类SQL的数据访问方式。本文的方案即源自于此。
参考文献：
[1]“工程数据库设计与应用”课程电子教案. http://comic.sjtu.e
du.cn/thucs/GD_jsj_029y/index.htm
[2]袁海斌,袁海文,张新.Oracle工程数据库中的面向对象设计技术[J].计算机应用研究,2003,20(8)
[3]廖国琼.基于C/S的工程数据库管理系统中事务管理子系统的设计[J].计算机工程,2001,27(10)
[4]Amazon Simple Storage Service (Amazon S3). http://aws.amazon.com/s3/
