CN101794315A

CN101794315A - 一种数据库模式固定的对象关系映射模型

Info

Publication number: CN101794315A
Application number: CN201010136132A
Authority: CN
Inventors: 袁梅宇
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-03-31
Filing date: 2010-03-31
Publication date: 2010-08-04

Abstract

一种数据库模式固定的对象关系映射模型，能够存储面向对象的信息建模元素(如实体、属性、关系等)。适用于在软件开发完成、交付用户后，不能或不允许改变数据库表结构，但又必须允许用户存储各种用户自定义数据的特定编程环境中。该数据库模型采用数量有限的数据库表，当需要存储新格式的对象时，不需要新建数据库表，仅仅只需在固定的数据库表中插入新的记录，该模型支持面向对象的信息建模概念，如实体、关系、属性等，保证了反映现实世界的信息模型平滑地向固定的数据库模式映射。

Description

一种数据库模式固定的对象关系映射模型

技术领域

本发明是一种数据库模型，能够存储面向对象的信息建模元素(如实体、属性、关系等)。适用于在软件开发完成、交付用户后，不能或不允许改变数据库表结构，但又必须允许用户存储各种用户自定义数据的特定编程环境中。该数据库模型采用数量有限的数据库表，存放能满足大多数应用需求的持久化数据，特别适合在工作流应用中存放业务数据。

背景技术

在软件工程项目的实施中，常常需要将经数据建模后的信息模型及实例数据存储到关系数据库中，以便应用访问。由于关系模型与面向对象描述语言(设计对象模型)及程序设计语言(实现对象模型)的不匹配，常常需要在两者之间进行映射。关于面向对象的信息模型到关系模型的映射方法，已经有很多文献论述。这些文献中的方法可以归结为：将类(或实体)映射为数据库表，将类属性(或实体属性)映射为数据库表字段，将类(或实体)之间的关系映射为数据库表之间的“1对多”或“1对1”关系，此外，由于关系数据库本身的限制，只能增加一个数据库表来实现“多对多”关系。

上述方法已经经过多年实践的考验，证明在大多数情况都能满足需要。但它却存在一个致命的缺陷——要求数据库所存储的数据格式在设计时而不是在运行时就必须确定，也就是说，如果在软件运行时需要数据库存储新格式的对象，就必须创建新数据库表以容纳其数据。这就产生了以下问题：如果用户的业务数据模型经常变动，或者需要开发适用于不同领域的、需要用户自行定制业务数据模型的软件，由于事先不知道或不能确定用户到底需要存放什么样的数据及数据格式，没法在设计时确定数据库表结构，不得不为了存放一种新格式的数据而新建一张数据库表——引起数据库模式经常变化，这种变化必然要求客户端软件经常作相应修改，否则客户端由于不知道新的数据库模式而无法访问其数据。这些修改包括用户交互界面的重新设计、SQL语句的改写等等。由于经常变更需求，导致很大的维护工作量，经常变更的用户交互界面通常不能为客户所接受，软件开发人员也没有足够精力去应付频繁变更的需求。

为了克服这一缺陷，本发明采用固定的数据库表以容纳各种数据，当需要存储新格式的对象时，也不需要新建数据库表，仅仅只需在固定的数据库表中插入新的记录，就可以存储实体、属性、关系及实体实例，减少了维护工作量，特别适用于最终用户使用时还经常变动的业务数据的情形，如工作流应用场景。

在工作流应用中，业务数据是业务流程中所涉及到的流程数据，它又称为流程变量(Process Variables)，例如，请假流程中的请假原因和请假天数，还有公文审批流程中的审批意见，等等。不同的业务流程涉及到不同的流程数据，而且可能经常变动。一般来说，工作流引擎并不考虑业务数据，而把它留给工作流应用的实施者来考虑。少部分工作流引擎，如著名的开源jBPM，本身就支持业务数据，但其所支持的流程变量一般都是简单的数据类型，并且相互之间没有关联，不支持面向对象的信息建模概念，如实体、属性、关系等，因而和数据建模时产生的数据模型差异较大，难以支持对业务数据复杂的查询统计等应用要求。更为重要的是，如果不能很好解决这个问题，就很难实现流程任务表单的自动生成。任务表单用于获取用户输入的业务数据，即，在任务表单的“提交”按钮的响应函数中，应该实现将获取用户输入的业务数据并存储到数据库的功能。如果数据库表结构还没有确定，就没法编写该按钮的通用代码。

发明内容

本发明采用通用的关系数据库模式，与具体的关系数据库管理系统无关，适用于各种商业或免费的数据库管理系统。本发明数据库模式固定，可以存储能满足大多数应用的数据，按照后文所述步骤可以编制灵活的数据库访问代码，代码可以采用面向对象的编程语言编写，以实现用户业务数据的定制、数据输入和输出。

本发明的有益效果是，数据库模式固定，能够在交付用户使用后，存储用户自行定制的数据，支持面向对象的信息建模概念，如实体、属性、关系等，保证了反映现实世界的信息模型平滑地向固定的数据库模式映射。在工作流应用中，克服过程变量间无联系、孤立的缺点，使得业务数据在逻辑上以相互联系、自然、结构化的方式存放，减小数据建模时产生的数据模型与具体实现的业务数据的差异。另外，由于所存储的数据本身是结构化的，理论上可以支持查询统计功能。

附图说明

下面结合附图和实施对本发明进一步说明。

附图是本发明数据库模型的E-R图。

图中1.实体表 2.属性表 3.实体实例表 4.字符串型属性表 5.数字型属性表 6.实体联系表

实体表(1)中，列E_ID为关键字，列E_Name为实体类型名称；属性表(2)中，列A_ID为关键字，列E_ID为实体表(1)外键，列A_Name为属性名称，列A_Type为属性数据类型(现阶段只支持字符串型和数字型两种，将来也容易扩展到其它数据类型)；实体实例表(3)中，列EI_ID为关键字，列E_ID为实体表(1)外键；字符串型属性表(4)中，列SA_ID为关键字，列EI_ID为实体实例表(3)外键，列A_ID为属性表(2)外键，列SA_Value为属性值；数字型属性表(5)中，列NA_ID为关键字，列EI_ID为实体实例表(3)外键，列A_ID为属性表(2)外键，列NA_Value为属性值；实体联系表(6)中，列E1_ID和列E2_ID都是实体表(1)外键，同时又是复合关键字，列A1_ID和列A2_ID都是属性表(2)外键，列ER_Type是实体关系类型，表示两实体间关系类型究竟是1对1还是1对多。

具体实施方式

实体表(1)保存实体类型名称信息，属性表(2)保存实体属性名称和数据类型信息，它们共同存储实体的结构信息。实体实例表(3)、字符串型属性表(4)和数字型属性表(5)一起，存储实体实例信息。实体联系表(6)存储实体之间的联系。

为了对本发明有更清楚的了解，下面举例说明如何创建、删除实体，如何对实体实例进行增、删、改、查操作，以及如何创建、删除实体间的联系。在实际的使用中，容易将下述形式化描述的步骤采用面向对象的语言进行编程实现，从而提高通用性和存取效率。

创建、删除实体类型的传统方式是采用SQL语句——CREATE TABLE和DROP TABLE。由于数据库模式不改变，本发明创建实体类型采用INSERT语句。创建实体类型涉及到实体表(1)和属性表(2)，假如要创建实体E1(FIELD1，FIELD2)，其中，E1为实体类型名称，FIELD1和FIELD2为属性名称，假设FIELD1为字符串型，FIELD2为数字型。步骤是：1、在实体表(1)中插入一行，关键字E_ID可以自动生成，假设生成的E_ID值为1，列E_Name存放实体类型名称——“E1”；2、在属性表(2)中插入两行，表示实体E1有两个属性，列A_ID可以自动生成。假设第一行生成的A_ID为1，列E_ID值为1，表明这一行的属性隶属于实体E1，该行的列A_Name的值为“FIELD1”，列A_Type的值为“S”，表示该属性的属性名称和类型分别为“FIELD1”和“字符串型”；同样，第二行的列A_ID为2，列E_ID值为1，列A_Name的值为“FIELD2”，列A_Type的值为“N”，表示实体E1的第二个属性是数字型，名称是“FIELD2”。本发明删除实体类型采用SQL DELETE语句，级联删除实体表(1)、属性表(2)、实体实例表(3)、字符串型属性表(4)、数字型属性表(5)和实体联系表(6)中与欲删除实体关联的行。

增加实体实例分别对实体实例表(3)、字符串型属性表(4)和数字型属性表(5)采用SQL INSERT语句操作。例如，要对前述的实体E1增加实体实例，其ID为1，列FIELD1的值为“string1”，列FIELD2的值为123，步骤是：1、采用INSERT语句在实体实例表(3)中插入一行，关键字EI_ID值为1(可以自动生成)，外键E_ID的值为1，关联实体表(1)中的实体E1，表明该行是实体类型E1的实体实例；2、在字符串型属性表(4)中插入一行，关键字SA_ID可以自动生成，假设生成的SA_ID值为1，外键EI_ID值为1，外键A_ID值为1，表示其为实体E1的第一个属性FIELD1的实例，列SA_Value的值为“string1”；3、在数字型属性表(5)中插入一行，关键字NA_ID可以自动生成，假设生成的NA_ID值为1，外键EI_ID值为1，外键A_ID值为2，表示其为实体E1的第二个属性FIELD2的实例，列NA_Value的值为123。

删除实体实例较为简单。例如，欲删除前面所增加的EI_ID值为1的实体实例，只需要删除实体实例表(3)中列EI_ID值为1的行，并且级联删除字符串型属性表(4)和数字型属性表(5)中外键EI_ID值为1的所有行即可。

修改实体实例使用SQL UPDATE语句。例如，欲修改前面所增加的EI_ID值为1的实体实例，将列FIELD2的值修改为456。操作步骤是：1、在属性表(2)中查找列EI_ID值为1并且列A_Name的值为“FIELD2”的行，得到该行的列A_ID为2且列A_Type的值为“N”；2、根据上一步结果，列A_Type的值为“N”，得知欲修改的实体实例属性值在数字型属性表(5)中，在数字型属性表(5)中查找到列EI_ID值为1且列A_ID为2的行，得到其关键字NA_ID值为1；3、使用SQL UPDATE语句修改该行的列NA_Value的值为456。

查找实体实例使用SQL SELECT语句。例如，欲查找实体类型名称为E1的所有实体实例，步骤是：1、在实体表(1)中查找列E_Name值为“E1”的行，得到该行的关键字E_ID值为1；2、在属性表(2)中查找列E_ID值为1的所有行，得到两行，其关键字A_ID分别为1和2；3、在实体实例表(3)中查找列E_ID值为1的所有行，得到一行，其关键字EI_ID为1；4、在字符串型属性表(4)中查找列EI_ID为1且列A_ID为1的行，得到一行，读取列SA_Value的值，即实体E1的属性FIELD1的值，同样，在数字型属性表(5)中查找可得到实体E1的属性FIELD2的值。

创建、删除实体间的联系只对实体联系表(6)进行SQL INSERT或DELETE操作。例如，要对实体E1的属性ColOne和实体E2的属性ColMany建立一对多联系，步骤如下：1、在实体表(1)中查找列E_Name值为“E1”的行，得到该行的关键字E_ID值，假设为1。同样，可以得到E2的ID值，假设为2；2、在属性表(2)中查找列E_ID值为1并且列A_Name值为“ColOne”的行，得到关键字A_ID值，假设为11。同样，可以得到E2的属性ColMany的关键字A_ID值，假设为12；3、在实体联系表(6)插入一行，其列E1_ID、E2_ID、A1_ID、A2_ID、ER_Type分别为1、2、11、12、“M”。

Claims

1.一种采用有限数量数据库表的数据库模型，能够存放满足大多数应用需求的持久化数据，支持面向对象的信息建模概念，如实体、属性、关系等。由实体表、属性表、实体实例表、实体联系表、字符串属性表和数字型属性表(视不同应用要求，还可以加上其它数据类型的属性表)构成，这些数据库表一起，可以表示并存储由数据建模过程中产生的数据模型(如ER图、UML类图等)，其特征是：改变传统的创建一个数据库表以定义一个实体类型，在数据库表添加一行存储一个实体实例的常规方式，采用实体表和属性表分别存储实体名称和实体属性类型信息，采用实体实例表、字符串属性表和数字型属性表一起存储实体实例，采用实体联系表存储实体之间的联系。

2.根据权利要求1所述的数据库模型，其特征是：有且只有一个实体表和一个属性表，实体表存放实体名称信息，属性表存放实体属性名称、属性数据类型信息，这两个表之间的联系是1对多关系，它们一起存储任意实体的结构信息。

3.根据权利要求1所述的数据库模型，其特征是：有且只有一个实体实例表、一个字符串属性表和一个数字型属性表，实体表和实体实例表之间的联系是1对多关系，实体表中的每一行表示一个实体类型，实体实例表中的每一行表示相关联实体的一个实例。实体实例表和字符串属性表之间的联系是1对多关系，属性表和字符串属性表之间的联系是1对多关系，字符串属性表的每一行表示一个实体实例中的一个字符串属性的具体值，从该行的外键EI_ID中可以查出该属性值从属于哪一个实体实例，从该行的外键A_ID中可以查出该属性值是哪一个实体属性的具体值；数字型属性表与字符串属性表的情形类似，只是数据类型不同。

4.根据权利要求1所述的数据库模型，其特征是：有且只有一个实体联系表，实体联系表中的每一行表示两实体间关系，关系类型信息存放在一列中，其类型有两种：1对1和多对多。