CN104598622A - 一种数据修改日志的实现方法和系统及应用服务器 - Google Patents

Abstract

本发明提供一种数据修改日志的实现方法和系统及应用服务器。该方法包括：将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；定义能够调用实体类并采集数据修改信息的第一接口；还包括：在用户修改业务表中的数据后，调用所述第一接口，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。本发明能够提高所得到的数据修改日志的准确性。

Description

一种数据修改日志的实现方法和系统及应用服务器

技术领域

本发明涉及计算机技术领域，特别涉及一种数据修改日志的实现方法和系统及应用服务器。

背景技术

随着计算机行业的快速发展，信息管理系统中需要使用的数据越来越多。为了保存数据，通常是在数据库中保存各个数据表，并将数据保存到相应的数据表中。另外，随着各种业务应用的发展，经常需要对数据库中数据表里的数据进行修改。为了方便业务应用的使用，需要对数据修改进行记录，实现数据修改日志。

目前，实现数据修改日志的方式包括：在数据库侧，通过触发器的机制采集数据库的数据表中当前数据修改的信息，比如修改数据的时间信息和被修改的数据信息；在应用系统侧，采集当前修改数据的用户信息、当前修改数据的时间信息；将数据库侧采集的时间信息与应用系统侧用户的修改数据的时间信息进行时间点模糊匹配，修改数据的时间最接近的那个用户则为修改当前数据的用户，最后将用户信息、时间信息和数据变化信息封装成数据修改日志保存到数据库的数据修改日志表中。

可见，在现有技术中，数据修改信息的采集只在数据库层完成，因此只能根据数据库中数据被修改的时间信息与应用系统侧用户修改数据的时间信息进行匹配，来确定修改数据的用户，这样，如果系统并发量很大，数据修改信息根据时间点模糊匹配的用户信息往往不准确，导致数据修改日志不准确。

发明内容

本发明提供一种数据修改日志的实现方法和系统及应用服务器，能够提高数据修改日志的准确性。

本发明的技术方案包括：

本发明一个方面提出了一种数据修改日志的实现方法，将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；定义能够调用实体类并采集数据修改信息的第一接口；还包括：

在用户修改业务表中的数据后，调用所述第一接口，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；

利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

优选地，所述定义能够调用实体类并采集数据修改信息的第一接口包括：使用反射机制封装第一接口为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

优选地，所述第一接口中，参数类型为超类Object。

优选地，进一步包括：采用XML配置文件，配置所述数据库的业务表中需要记录数据修改日志的关键业务字段；

所述利用该属性值变化获取数据修改信息包括：从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述XML配置文件所配置的所述关键业务字段的属性值变化，得到数据修改信息。

可选地，

由应用服务器执行所述的调用和生成；

和/或，

在生成数据修改日志之后，进一步包括：由应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称；

和/或，

在生成数据修改日志之后，进一步包括：应用服务器将所述数据修改日志保存为应用服务器中的文件，或者保存到所述数据库中专用的数据修改日志表中。

本发明另一方面提出了一种应用服务器，包括：

映射单元，用于将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；

接口实现单元，用于定义能够调用实体类并采集数据修改信息的第一接口；在用户修改业务表中的数据后，调用所述第一接口，

修改信息获取单元，用于得到所述第一接口的调用返回值，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；

日志生成单元，用于利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

优选地，所述接口实现单元包括：

反射机制封装子单元，用于使用反射机制封装出第一接口为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

优选地，进一步包括：配置单元，用于采用XML配置文件，配置所述数据库的业务表中需要记录数据修改日志的关键业务字段；

所述修改信息获取单元，用于从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述配置单元配置的XML配置文件中所述关键业务字段的属性值变化，得到数据修改信息。

可选地，进一步包括：

第一日志处理单元，用于由应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称；和/或，

第二日志处理单元，用于将所述数据修改日志保存为应用服务器中的文件，或者保存到外部数据库中专用的数据修改日志表中。

本发明再一个方面提出了一种数据修改日志的实现系统，包括数据库以及上述任意一种应用服务器。

可见，本发明实施例至少具有如下的有益效果：

1、本发明实施例提供的数据修改日志的实现方法和系统及应用服务器采用了基于面向对象的数据修改日志实现方式，具体地，是将数据库中的每一个业务表映射为对应的实体类，也就是说用应用服务器的软件系统中的实体类来表示数据库中的业务表，之后，再定义能够调用实体类并采集数据修改信息的应用服务器中的第一接口，这样，通过调用第一接口，则可以得到数据的修改信息。可见，数据修改信息的采集不是在数据库层完成的，而是在应用服务器侧完成的，这样，应用服务器则可以准确地确定在该应用服务器上的哪个用户对数据进行了修改，生成的包括用户信息和数据修改信息的数据修改日志的准确性则大大提高。

2、进一步地，本发明实施例还提出了具体的使用反射机制封装的接口定义，public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；由于该接口可以针对任何实体类进行调用，且接口定义中的参数类型可以是超类Object，因此，此采集数据修改信息的接口具有通用性，大大增加了本发明实施例的实用性。

3、进一步地，在本发明实施例中，可以采用XML配置文件的方式，配置需要记录数据修改日志的关键业务字段范围，所以在实现数据修改日志时，无需对所有的数据判断其业务对象的属性值是否发生变化，从而提高了日志实现过程的效率，减少了数据修改日志的冗余数据。

附图说明

图1是在本发明一个实施例中实现数据修改日志的方法的流程图。

图2是在本发明另一个实施例中实现数据修改日志的方法的流程图。

图3是在本发明一个实施例中形成的实体类的示意图。

图4是在本发明一个实施例中采用XML配置文件的方式配置业务表中需要记录数据修改日志的关键业务字段范围的代码实现。

图5是在本发明一个实施例中数据修改日志表的示意图。

图6是在本发明一个实施例中的应用服务器的结构示意图。

图7是在本发明另一个实施例中的应用服务器的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明一个实施例提出了一种数据修改日志的实现方法，参见图1，该方法包括：

步骤101：将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；定义能够调用实体类并采集数据修改信息的第一接口；

步骤102：在用户修改业务表中的数据后，调用所述第一接口，得到实体类的业务对象在数据修改前后的属性值；

步骤103：利用属性值的变化获取数据修改信息；

步骤104：利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

可见，图1所示的本发明实施例采用了基于面向对象的数据修改日志实现方式，具体地，是将数据库中的每一个业务表映射为对应的实体类，也就是说用应用服务器的软件系统中的实体类来表示数据库中的业务表，之后，再定义能够调用实体类并采集数据修改信息的应用服务器中的第一接口，这样，通过调用第一接口，则可以得到数据的修改信息。可见，数据修改信息的采集不是在数据库层完成的，而是在应用服务器侧完成的，这样，应用服务器则可以准确地确定在该应用服务器上的哪个用户对数据进行了修改，生成的包括用户信息和数据修改信息的数据修改日志的准确性则大大提高。

在本发明的一个实施例中，为了增加采集数据修改信息的第一接口的通用性，可以使用反射机制将接口定义为public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)，其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

另外，在本发明的一个实施例中，为了提高日志实现过程的效率，减少了数据修改日志的冗余数据，可以采用XML配置文件的方式，配置需要记录数据修改日志的关键业务字段范围，所以在实现数据修改日志时，无需对所有的数据判断其业务对象的属性值是否发生变化。

在本发明的一个实施例中，各种数据修改信息的采集及日志生成都由应用服务器来完成，而不是数据库层完成，因此，便于对数据修改日志进行扩展应用，比如，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称；或者，应用服务器将所述数据修改日志保存为应用服务器中的文件，或者保存到所述数据库中专用的数据修改日志表中。

参见图2，本发明一个实施例提出了另一种数据修改日志的实现方法，该方法包括：

步骤201：在应用服务器中，将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据。

在本实施例中，是采用基于面向对象的开发方法。面向对象的开发方法核心思想是现实世界中的万事万物皆对象，既现实世界中的各种人、事物等都可以使用软件系统中的对象来表示，而类是对象的抽象，对象是类的实例。通过本步骤的处理，将数据库中的业务表都可以映射为应用服务器中的实体类，以便后续实现在应用服务器侧采集数据修改信息。

本步骤中形成的两个实体类可以参见图3所示。比如，其中一个实体类的名称是生产许可证基本信息，表示对应业务表的业务实体信息的名称，其属性包括企业名称，组织机构代码等。

步骤202：在应用服务器中，定义并使用反射机制封装采集数据修改信息的接口，记为接口1。

本步骤中，接口1可以定义为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)。

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

接口定义中的参数类型可以是超类Object。

步骤203：在应用服务器中，采用XML配置文件，配置数据库的业务表中需要记录数据修改日志的关键业务字段。

对于一个业务表中的数据，并不是所有字段的数据都会修改，比如数据主键，一旦数据存在之后，该字段就不会再被修改，所以在实现数据修改日志的时候，较佳地，可以明确哪些关键的业务字段会被修改，而不是后续盲目的检查所有以减少数据修改日志的冗余数据。比如，参见图3，生产许可证基本信息中的主键用于标识这个业务对象，该字段通常不会被修改；再如，其中的开办时间也不会被修改。因此，本步骤中，采用XML配置文件的方式，配置业务表中需要记录数据修改日志的关键业务字段范围。

本步骤的一种代码实现可以如图4所示。

步骤204：在用户修改业务表中的数据后，应用服务器检测到用户的保存操作，则触发后续的数据修改日志的实现过程。

这里，比如，用户对图3中所述的生产许可证基本信息对应的业务表中的数据进行修改，修改后进行保存，应用服务器检测到用户的保存操作。

步骤205：应用服务器调用接口1。

这里，可以在调用接口1时，提供两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象。

步骤206：应用服务器得到接口1调用的返回值。

这里，返回值可以为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

步骤207：应用服务器从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述XML配置文件所配置的所述关键业务字段的属性值变化，得到数据修改信息。

调用接口1可以得到所有数据在修改前后的属性值，为了进一步增加实现日志的效率，本步骤的一个实施例中，无需对每一个数据的属性值是否发生变化进行比对，可以只对XML配置文件中配置出的需要记录数据修改日志的关键业务字段的属性值是否发生变化进行比对。

步骤208：应用服务器利用得到的数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

步骤209：应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称。

步骤210：应用服务器将所述数据修改日志保存到数据库中专用的用于存储所有数据修改日志的数据修改日志表中。

本步骤中的数据修改日志表的一种示意图可以参见图5。

在本步骤中，也可以不将数据修改日志保存到数据库中，而是由应用服务器将其保存为应用服务器中的文件。

如果有某个实体类类型的两个业务对象，一个表示修改前的业务对象，另一个表示修改后的业务对象，调用接口1比对出实体对象在数据修改前后的属性值变化，就可以获取到业务信息在修改前后的变化信息。

本发明一个实施例还提出了一种应用服务器，参见图6，该应用服务器包括：

映射单元601，用于将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；

接口实现单元602，用于定义能够调用所述映射单元601形成的实体类并采集数据修改信息的第一接口；在用户修改业务表中的数据后，调用所述第一接口，

修改信息获取单元603，用于接收所述接口实现单元602对第一接口调用的返回值，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；

日志生成单元604，用于利用所述修改信息获取单元603获取的数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

在本发明的一个实施例中，所述接口实现单元602包括：

反射机制封装子单元，用于使用反射机制封装出第一接口为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

在本发明的一个实施例中，进一步包括：配置单元605，用于采用XML配置文件，配置所述数据库的业务表中需要记录数据修改日志的关键业务字段；

所述修改信息获取单元603，用于从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述配置单元605配置的XML配置文件中所述关键业务字段的属性值变化，得到数据修改信息。

在本发明的一个实施例中，应用服务器可以进一步包括：

第一日志处理单元，用于由应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称。

在本发明的一个实施例中，应用服务器还可以进一步包括：

第二日志处理单元，用于将所述数据修改日志保存为应用服务器中的文件，或者保存到外部数据库中专用的数据修改日志表中。

本发明的一个实施例还提出了一种数据修改日志的实现系统，包括数据库以及上述任意一种实施例提供的应用服务器。

需要说明的是，在本发明各个实施例中，对数据进行修改是广义含义，比如在数据库的业务表中增加数据、删除数据、修改数据值等，都属于上述各个实施例中提到的数据修改。

可见，本发明的各个实施例至少具有如下的有益效果：

1、本发明的实施例采用了基于面向对象的数据修改日志实现方式，具体地，是将数据库中的每一个业务表映射为对应的实体类，也就是说用应用服务器的软件系统中的实体类来表示数据库中的业务表，之后，再定义能够调用实体类并采集数据修改信息的应用服务器中的第一接口，这样，通过调用第一接口，则可以得到数据的修改信息。可见，数据修改信息的采集不是在数据库层完成的，而是在应用服务器侧完成的，这样，应用服务器则可以准确地确定在该应用服务器上的哪个用户对数据进行了修改，生成的包括用户信息和数据修改信息的数据修改日志的准确性则大大提高。

2、本发明的一些实施例还提出了具体的使用反射机制封装的接口定义，public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,ObjectnewObj)；由于该接口可以针对任何实体类进行调用，且接口定义中的参数类型可以是超类Object，因此，此采集数据修改信息的接口具有通用性，大大增加了本发明实施例的实用性。

3、在本发明的一些实施例中，可以采用XML配置文件的方式，配置需要记录数据修改日志的关键业务字段范围，所以在实现数据修改日志时，无需对所有的数据判断其业务对象的属性值是否发生变化，从而提高了日志实现过程的效率，减少了数据修改日志的冗余数据。

4、本发明的一些实施例还具有易理解的优点。具体地，由于是基于面向对象的开发方式，可以从用户视图、设计人员视图以及开发人员视图等多个角度描述业务需求，方便不同角色的项目参与者沟通交流。

5、本发明的一些实施例还具有可扩展的优点。具体地，由于操作是在应用服务器侧而不是在数据库侧执行，因此，可以在封装的数据修改日志中添加其他的扩展信息，比如登录用户的IP地址、业务模块名称等，整个数据修改日志信息采集过程完全由应用服务器的程序控制，可以提供良好的扩展机制。

6、本发明一些实施例还具有高复用的优点。具体地，如果需要对新的业务对象记录数据修改日志，添加相应的数据修改日志采集调用程序和XML配置文件即可，而无需对数据库进行任何修改。都是统一接口，不用每次调用都编写调用语言或接口。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种数据修改日志的实现方法，其特征在于，将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；定义能够调用实体类并采集数据修改信息的第一接口；还包括：

在用户修改业务表中的数据后，调用所述第一接口，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；

利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

2.根据权利要求1所述的方法，其特征在于，所述定义能够调用实体类并采集数据修改信息的第一接口包括：使用反射机制封装第一接口为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

3.根据权利要求2所述的方法，其特征在于，所述第一接口中，参数类型为超类Object。

4.根据权利要求1所述的方法，其特征在于，进一步包括：采用XML配置文件，配置所述数据库的业务表中需要记录数据修改日志的关键业务字段；

所述利用该属性值变化获取数据修改信息包括：从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述XML配置文件所配置的所述关键业务字段的属性值变化，得到数据修改信息。

5.根据权利要求1至4中任一所述的方法，其特征在于，

由应用服务器执行所述的调用和生成；

和/或，

在生成数据修改日志之后，进一步包括：由应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称；

和/或，

在生成数据修改日志之后，进一步包括：应用服务器将所述数据修改日志保存为应用服务器中的文件，或者保存到所述数据库中专用的数据修改日志表中。

6.一种应用服务器，其特征在于，包括：

映射单元，用于将数据库中的每一个业务表映射为对应的实体类，实体类的类名表示业务表的名称，实体类的业务对象的属性表示业务表中的字段数据；

接口实现单元，用于定义能够调用实体类并采集数据修改信息的第一接口；在用户修改业务表中的数据后，调用所述第一接口，

修改信息获取单元，用于得到所述第一接口的调用返回值，得到实体类的业务对象在数据修改前后的属性值，利用属性值的变化获取数据修改信息；

日志生成单元，用于利用所述数据修改信息、所述用户的信息和当前时间，生成数据修改日志。

7.根据权利要求6所述的应用服务器，其特征在于，所述接口实现单元包括：

反射机制封装子单元，用于使用反射机制封装出第一接口为：

public Map<String,Object[]>getBizObjectModifiedInfo(Object oldObj,Object newObj)；

其中，两个参数(Object oldObj,Object newObj)分别为修改前的业务对象和修改后的业务对象，返回值为Map集合，Key为业务对象的属性名称，Value为Object类型的数组，数组第一个元素表示业务对象修改前的属性值，数组第二个元素表示业务对象修改之后的属性值。

8.根据权利要求6所述的应用服务器，其特征在于，进一步包括：配置单元，用于采用XML配置文件，配置所述数据库的业务表中需要记录数据修改日志的关键业务字段；

所述修改信息获取单元，用于从所述实体类的业务对象在数据修改前后的属性值变化中，找出所述配置单元配置的XML配置文件中所述关键业务字段的属性值变化，得到数据修改信息。

9.根据权利要求6至8中任一所述的应用服务器，其特征在于，进一步包括：

第一日志处理单元，用于由应用服务器根据预先设置，在生成的数据修改日志中添加用户的IP地址和/或业务模块名称；和/或，

第二日志处理单元，用于将所述数据修改日志保存为应用服务器中的文件，或者保存到外部数据库中专用的数据修改日志表中。

10.一种数据修改日志的实现系统，包括数据库以及如权利要求6至9中任一所述的应用服务器。