论文部分内容阅读
摘要：针对现有的ORM组件不能实现运行时动态改变数据库结构的不足，文章提出了一种动态数据库的ORM解决方案，该方案从分析设计数据库的基本原则入手，给出了一种将索引表和动态数据表相结合的ORM模型，通过索引表间接实现了动态数据库的ORM，弥补了现有ORM组件的不足。同时分析比较了动态数据库ORM和传统JDBC直连的效率。
关键词：动态数据库；ORM；索引袁
0 引言
软件结构体系已由单层结构向多层结构发展，在Web应用软件中，这种体系结构表现为典型的三层结构：表述层、业务逻辑层、数据层。这种层次结构给应用软件带来了伸缩性、可维护性、可扩展性、可重用性和可管理性等诸多优点。
该层次结构中业务逻辑层不仅要处理业务逻辑，而且还负责访问数据库，操作和处理业务逻辑所需的数据。JDBC是所有数据库访问方式中效率最高的，但是由于JDBC的编码方式属于SQL语句嵌入式的硬编码结构，所以在代码里必然会带有大量的SQL语句，从而导致开发效率的降低和维护成本的升高。所以为了把数据访问和业务逻辑区分开来，部分应用在业务逻辑层和数据层之间增加了数据访问中间件——持久层，由这一层来负责具体的数据访问。持久层封装了访问细节并向业务逻辑层提供数据访问接口，使业务逻辑不必再纠缠于数据访问语句中，从而使业务代码更加简洁专一。
1 ORM模式简介
ORM(Object-Relation-Mapping)模式指在单个组件中实现所有实体的持久化，封装数据细节。目前最流行和最普及的数据层解决方案是关系数据库，而关系数据库是基于数学集合论原理的，这和被普遍接受的面向对象的业务逻辑实现存在一定的匹配问题。为了解决这种匹配问题，目前已经提出了多种解决方案，比如CMP、JDO、ORM等等。其中ORM作为目前比较流行的持久化解决方案，与CMP、JDO相比具有结构简单，移植性高，对环境依赖度低的优点，与POJO(Plan Old Java Object)相结合使用的方式已经成为一种越来越受欢迎且用于取代CMP和JDO的持久化方案。
2 动态数据库的ORM实现
与运行时物理表结构不改变的静态数据库相对，动态数据库是指由于数据结构不能在设计期间完全预知，物理表结构在运行时会随着业务逻辑的需求动态增加、删除或修改数据库。目前的ORM组件是通过对象一表和属性一列的映射配置文件实现对象关系映射的，所以可以与静态数据库结合使用并能很好地工作。但是这种ORM组件对于动态数据库而言却是不适用的，映射配置文件不可能在应用运行时动态修改，同样映射的对象文件也不可能在应用运行时动态修改。虽然业务逻辑可以避开ORM直接访问数据库，但是这样做是与增加持久层简化业务逻辑的初衷相背的。
所以，需要一种能与动态数据库结合使用的ORM实现。本文提出了一种通过改进数据库的表设计，增加索引表而实现动态数据库结构的抽象规范，继而在此基础之上实现动态数据库的ORM方案。
2．1 数据库设计准则
由于动态数据库数据表的动态特性，所以要实现ORM必须对其进行逻辑上的抽象，归纳出一个统一的逻辑结构，使ORM组件可以对数据表进行统一的管理和访问。本文按照如下几点对数据库进行改良并抽象出统一的数据表逻辑结构。
2．1．1 统一生成准则
对于不同应用来说，每个生成的动态数据表在结构上具有一定的相似性。所以应该在设计阶段根据可能的数据表的生成类型确定动态数据表的生成规则，让所有的数据表都按照规则生成，这样生成的数据表在结构上具有一致性，并能在逻辑上实现数据表的统一管理。
2．1．2 增加索引表
索引表是存放所有动态生成的数据表的参数的表，包括数据表的物理表名、逻辑表名、物理列名、逻辑列名等。索引表工作于持久层和数据层之间，逻辑上等同于ORM组件和数据表之间的代理，ORM组件通过索引表代理间接访问数据表：
ORM则建立在表结构固定的索引表上，这样，在逻辑上解决了动态数据表的ORM问题。本文引入了两张索引表：表索引表和列索引表，其结构如表1和表2所示，其中表索引表的map_name列的数值是惟一的，列索引表的map_name列在table_id值相等的情况下取值也是惟一的。在新建一张数据表的时候，向表索引表中写入一条记录，其中的字段值为该数据表的相关信息，比如逻辑表名，物理表名等等。同时根据该数据
关键词：动态数据库；ORM；索引袁
0 引言
软件结构体系已由单层结构向多层结构发展，在Web应用软件中，这种体系结构表现为典型的三层结构：表述层、业务逻辑层、数据层。这种层次结构给应用软件带来了伸缩性、可维护性、可扩展性、可重用性和可管理性等诸多优点。
该层次结构中业务逻辑层不仅要处理业务逻辑，而且还负责访问数据库，操作和处理业务逻辑所需的数据。JDBC是所有数据库访问方式中效率最高的，但是由于JDBC的编码方式属于SQL语句嵌入式的硬编码结构，所以在代码里必然会带有大量的SQL语句，从而导致开发效率的降低和维护成本的升高。所以为了把数据访问和业务逻辑区分开来，部分应用在业务逻辑层和数据层之间增加了数据访问中间件——持久层，由这一层来负责具体的数据访问。持久层封装了访问细节并向业务逻辑层提供数据访问接口，使业务逻辑不必再纠缠于数据访问语句中，从而使业务代码更加简洁专一。
1 ORM模式简介
ORM(Object-Relation-Mapping)模式指在单个组件中实现所有实体的持久化，封装数据细节。目前最流行和最普及的数据层解决方案是关系数据库，而关系数据库是基于数学集合论原理的，这和被普遍接受的面向对象的业务逻辑实现存在一定的匹配问题。为了解决这种匹配问题，目前已经提出了多种解决方案，比如CMP、JDO、ORM等等。其中ORM作为目前比较流行的持久化解决方案，与CMP、JDO相比具有结构简单，移植性高，对环境依赖度低的优点，与POJO(Plan Old Java Object)相结合使用的方式已经成为一种越来越受欢迎且用于取代CMP和JDO的持久化方案。
2 动态数据库的ORM实现
与运行时物理表结构不改变的静态数据库相对，动态数据库是指由于数据结构不能在设计期间完全预知，物理表结构在运行时会随着业务逻辑的需求动态增加、删除或修改数据库。目前的ORM组件是通过对象一表和属性一列的映射配置文件实现对象关系映射的，所以可以与静态数据库结合使用并能很好地工作。但是这种ORM组件对于动态数据库而言却是不适用的，映射配置文件不可能在应用运行时动态修改，同样映射的对象文件也不可能在应用运行时动态修改。虽然业务逻辑可以避开ORM直接访问数据库，但是这样做是与增加持久层简化业务逻辑的初衷相背的。
所以，需要一种能与动态数据库结合使用的ORM实现。本文提出了一种通过改进数据库的表设计，增加索引表而实现动态数据库结构的抽象规范，继而在此基础之上实现动态数据库的ORM方案。
2．1 数据库设计准则
由于动态数据库数据表的动态特性，所以要实现ORM必须对其进行逻辑上的抽象，归纳出一个统一的逻辑结构，使ORM组件可以对数据表进行统一的管理和访问。本文按照如下几点对数据库进行改良并抽象出统一的数据表逻辑结构。
2．1．1 统一生成准则
对于不同应用来说，每个生成的动态数据表在结构上具有一定的相似性。所以应该在设计阶段根据可能的数据表的生成类型确定动态数据表的生成规则，让所有的数据表都按照规则生成，这样生成的数据表在结构上具有一致性，并能在逻辑上实现数据表的统一管理。
2．1．2 增加索引表
索引表是存放所有动态生成的数据表的参数的表，包括数据表的物理表名、逻辑表名、物理列名、逻辑列名等。索引表工作于持久层和数据层之间，逻辑上等同于ORM组件和数据表之间的代理，ORM组件通过索引表代理间接访问数据表：
ORM则建立在表结构固定的索引表上，这样，在逻辑上解决了动态数据表的ORM问题。本文引入了两张索引表：表索引表和列索引表，其结构如表1和表2所示，其中表索引表的map_name列的数值是惟一的，列索引表的map_name列在table_id值相等的情况下取值也是惟一的。在新建一张数据表的时候，向表索引表中写入一条记录，其中的字段值为该数据表的相关信息，比如逻辑表名，物理表名等等。同时根据该数据