CN102483759B - 用于执行部分数据库的增量更新的方法、系统和装置 - Google Patents

用于执行部分数据库的增量更新的方法、系统和装置 Download PDF

Info

Publication number
CN102483759B
CN102483759B CN201080038075.9A CN201080038075A CN102483759B CN 102483759 B CN102483759 B CN 102483759B CN 201080038075 A CN201080038075 A CN 201080038075A CN 102483759 B CN102483759 B CN 102483759B
Authority
CN
China
Prior art keywords
record
database
time window
value
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN201080038075.9A
Other languages
English (en)
Other versions
CN102483759A (zh
Inventor
比约恩-哈拉尔德·舍格伦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Norsync Tech AS
Original Assignee
Norsync Tech AS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Norsync Tech AS filed Critical Norsync Tech AS
Publication of CN102483759A publication Critical patent/CN102483759A/zh
Application granted granted Critical
Publication of CN102483759B publication Critical patent/CN102483759B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24564—Applying rules; Deductive queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

用于从包含数据库(其中部分数据库是子集)的计算机系统对存储在客户机装置上的部分数据库进行增量更新的方法、系统和装置。识别作为数据库操作的结果已经插入到服务器数据库、从服务器数据库删除或者在服务器数据库中改变的第一数据库记录，以在客户机装置上进行相应的操作。另外，识别未插入、未删除或者未改变但是通过约束而相关于第一记录的第二记录。通过在客户机装置上进行的数据库操作将第二记录插入到部分数据库中或者从部分数据库删除，从而在部分数据库中满足约束。记录的识别基于数据库日志和记录类型之间的结构关系。

Description

用于执行部分数据库的增量更新的方法、系统和装置
技术领域
本发明涉及服务器计算机和客户机计算机之间的数据同步。更具体地，本发明涉及跟踪和收集服务器数据库和一个或更多客户数据库中的改变并且根据相关的改变进行同步。
背景技术
存储在中央计算机服务器系统中的数据库可以被部分地复制或者拷贝在不总是在线的客户机计算机中。因此出现数据库服务器系统和一个或更多客户机计算机之间的数据库同步的需要，并且同步可能涉及双方向上的改变，即可能对客户机计算机上以及服务器系统上的数据进行改变。除了因为已经在服务器上改变所以应传递到客户机的数据之外，作为数据库中的一些其它改变的结果，可能需要传递未改变的、但是在先前同步之后的一些时间与客户有关的数据。换句话说，除了用已经在服务器上改变的数据记录更新客户机之外，在服务器上未改变的一些记录可能也不得不被从客户机计算机删除或者添加到客户机计算机。
示例可以涉及移动装置，该移动装置包含表示商店的备货库存的部分数据库。该装置可以用于提取库存或者登记必要的购买以重新供应。可容易地理解的是：自从移动装置最后同步之后可能已经对在中央数据库中登记的可用产品的列表进行了改变。类似地，可能已经对表示由商店中的雇员登记的实际库存或者购买订单的移动装置进行了改变，以对特定商品进行补货。另外，可能已经进行了改变，其改变可从中央数据库中得到的数据的哪一个部分与客户机装置的部分数据库相关。
例如，客户机装置可以已经用于在商店的硬件部和体育部进行盘存，因此用包括硬件产品和体育产品的部分数据库更新。在随后的情形中同一装置可以被重新分配以登记同一商店的服装部中的必要购买，并且不再在硬件部中使用。客户机与数据库的同步应去除涉及硬件产品的一部分数据库，添加涉及体育产品的一部分数据库，并且进行中央数据库中服装产品的列表的改变所导致的全部必要更新。
同步客户机的问题的强力方案是首先将客户机上进行的全部更新导入到数据库，然后删除客户机上的全部数据库数据，最终将整个数据库或部分数据库再次导出到客户机。这确保客户机上的全部数据在同步时是当前的，但这要求很多的数据传递，并且在进行同步的同时还可能干扰系统处理与其它客户机交互的能力。请注意：相对于主(服务器)数据库使用术语导入(import)和导出(export)，除非相反说明。因而，导入或导入到是指将新数据从客户机引入数据库，而导出或从导出意味着将数据从服务器数据库引入或者更新到客户机数据库。
已经提出的替代方案是维持对主数据库中的全部记录的全部更新的数据库日志，并且将同步基于该日志。如果先前同步处的数据库的状态是已知的并且先前同步和正在进行的同步之间的全部数据库交换是已知的，则能够基于改变的日志在不干扰实际数据库的情况下更新客户机。基于该日志，可创建两个同步之间对数据库的全部改变的总结。可以认为该总结是数据库Δ，即在两个同步之间数据库的差别。
如果客户机包含主数据库的完整副本，则使用数据库Δ来更新客户机是很简明的。在利用整个数据库Δ更新客户机的情况下，应将全部改变发送给客户机。然而，如果客户机仅包含部分数据库，则需要识别数据库Δ中的与正被同步的特定客户机相关的记录，并且仅传递这些记录。另外，可能需要传递未改变的记录，即不是数据库Δ的一部分，但是由于其它原因对于客户机是必要的。
由于不同的原因，未改变记录可能变得与客户机相关。一般而言，可以识别两类原因，并且可以称为内因和外因。内因包括以下情况：一个记录(作为数据库Δ的一部分的记录)的改变使得需要将额外(未改变)记录导入客户机以完成限制并且确保相关数据实际存在于客户机上。外因包括以下情况：外置于数据库自身的一些事实使得导入记录到客户机是适当的，例如，特定时间点。后者的示例可以是甚至在先前同步时准备但是直至工作要进行之前的那一天不应传递给客户机的工作命令。
由于类似原因，在先前同步中与客户机中的部分数据库相关的记录可能变得不相关，即使该记录自身并未改变，并且随后可能需要去除未改变的记录。
因此，需要能够在满足限制的同时执行部分数据库的增量同步的方法和系统。
发明内容
本发明涉及用于从服务器计算机系统更新或者同步客户机装置的方法、计算机系统和计算机可读介质。服务器计算机系统包括数据库并且客户机装置保持服务器上的数据库的部分表示。数据库的部分表示包括服务器计算机系统中存在的数据库记录的子集，并且该子集可被称为在客户机被接受的记录。该方法允许在数据库约束被满足时客户机的增量同步。
服务器计算机根据本发明工作以从服务器计算机更新电子客户机装置，因此可以包括具有多个数据库记录的第一数据库，并且客户机装置包括第一数据库的部分表示。该部分数据库包括在客户机装置处被接受的数据库记录。在这种计算机系统上运行的方法可以包括识别先前更新所述客户机之后插入到第一数据库、从第一数据库删除或者在所述第一数据库中改变的第一记录；以及识别未添加到第一数据库、未从第一数据库删除或者未在第一数据库中改变但是通过约束而相关于第一记录的第二记录。基于这些识别的记录，该方法接着从服务器计算机发送第一数据，命令客户机装置在第一数据库的部分表示中进行相对应的插入到第一数据库、从第一数据库删除或者在第一数据库中改变第一记录；从服务器计算机发送第二数据，第二数据命令客户机装置插入第二记录到第一数据库的部分表示中或者从第一数据库的部分表示删除第二记录，使得在第一数据库的部分表示中满足约束。
应注意的是：约束可以是声明的数据库约束，诸如例如通过数据库管理系统(DBMS)实现的外键约束，但是还可以定义为自身的同步机制的规则的一部分。
根据本发明第一实施例，第一记录的识别可以基于时间窗口的起点和终点的确定，以及扫描由服务器计算机进行的数据库操作的日志的处理，起点表示与客户机装置的先前更新相关联的时间点，终点表示与客户机装置的当前更新相关联的时间点。然后，第一记录被识别作为在时间窗口期间进行了至少一个数据库操作的记录。
在向客户机装置发送第一数据之前，本发明的一个实施例包括进行以下操作的至少之一：扫描日志以确定表示第一记录在时间窗口的起点的状态的至少一个值，并且确定在时间窗口的起点处在部分数据库中该值是否被接受；以及扫描日志以确定表示第一记录在时间窗口的终点处的状态的对应值，并且确定在时间窗口的终点处在部分数据库中该值是否应该被接受。接受的确定可以基于以下至少之一：表示记录的状态的值，针对第一记录的记录类型的所声明规则，以及针对与第一记录不同但是通过子集约束与第一记录相关联的记录的对应确定。如果对服务器计算机中的第一记录进行的数据库操作表示插入第一记录到第一数据库，则如果确定表示第一记录在时间窗口的终点处的状态的值应该在时间窗口的终点处在部分数据库中被接受，则第一数据可被配置以表示将第一记录插入到第一数据库中的指令。类似地，如果数据库操作表示从第一数据库删除第一记录，则如果确定表示第一记录在时间窗口的起点处的状态的值在时间窗口的起点处在部分数据库中被接受，则数据可被配置以表示删除第一记录的指令。如果数据库操作表示在第一数据库中的第一记录的改变，则数据可被配置以表示执行以下之一的指令：即i)如果确定表示第一记录在时间窗口的起点处的状态的值在部分数据库中被接受，并且表示第一记录在时间窗口的终点处的状态的值应该在部分数据库中被接受，则改变部分数据库中的第一记录，ii)如果确定表示第一记录在时间窗口的起点处的状态的值在部分数据库中被接受，并且表示第一记录在时间窗口的终点处的状态的值应该在部分数据库中不被接受，则从部分数据库中删除第一记录，以及iii)如果确定表示第一记录在时间窗口的起点处的状态的值在部分数据库中不被接受，并且表示第一记录在时间窗口的终点处的状态的值应该在部分数据库中被接受，则将第一记录插入到部分数据库中。
对应的动作可以在向客户机装置发送第二数据之前进行，但是由于第二记录是未在服务器上改变的记录，通常不需要发送命令来改变部分数据库中的这种记录。然而，在本发明的一些实施例中，被配置以命令在客户机装置上进行数据库操作的数据可以通过相同方法或者计算机代码配置，无论是否命令涉及已经改变的记录或者尚未改变的记录。
根据本发明的一方面，重复针对不同记录扫描日志以确定表示值和确定在客户机上对该值的接受的步骤，执行接受的相应确定。例如可以按照对同一函数、方法和过程的递归调用的形式实现。
根据本发明的另一方面，针对记录类型的所声明规则是接受表示输入的记录类型的记录的状态的值，并且产生在客户机上针对该值的接受的相应确定的函数。由于该值表示记录的状态，确定通常是确定是否记录应在客户机数据库上被接受。
在本发明的一个实施例中，至少一个所声明规则被数据库的程序员或者用户声明。
虽然因为第二记录通过约束而与改变的第一记录的关系，第二记录是部分数据库中需要的未改变的记录，但是将第二记录添加到部分数据库或者从部分数据库中去除的事实可以要求额外地添加或者去除通过类似约束而相关第二记录的第三记录。因此，根据本发明的另一方面，方法可以包括识别未添加到第一数据库、未从第一数据库删除或者未在第一数据库中改变但是通过约束而相关第二记录并且类似地应添加到部分数据库或者从部分数据库去除以满足该约束的第三记录。该方法可以接着向客户机装置发送第三数据，第三数据命令装置插入第三记录到第一数据库的部分表示中或者从述第一数据库的部分表示删除第三记录，从而在第一数据库的部分表示中满足约束；以及重复识别记录和发送数据的步骤直至在部分数据库中满足全部约束为止。
根据本发明的一个实施例，第一记录的记录类型与用于确定表示记录类型的记录状态的值在客户机上的接受的所声明规则相关联，并且第二记录的记录类型是关于第一记录类型的子集成员记录类型。
根据另一个实施例，第一记录的记录类型是与用于确定表示在客户机上的记录类型的记录的状态的值的接受的所声明规则相关联的记录类型的子集成员记录类型，并且第二记录的记录类型是关于第一记录类型的子集成员记录类型。
根据又一个实施例，第一记录的记录类型是两个记录类型的子集成员，这两个记录类型即第二记录的记录类型和不同于第一记录和第二记录的记录类型的记录类型。在此实施例中，具有不同于第一记录并且不同于第二记录的记录类型的记录与用于确定表示该记录类型的记录的在客户机上的状态的值的接受的所声明规则相关联；并且如果要求满足将其相关到具有第一记录的记录类型的至少一个记录的约束，则第二记录具有与所声明规则相关联的记录类型，规则声称该第二记录类型的记录应仅在部分数据库中被接受。
根据另一实施例，如果要求满足将其相关到不同于第一记录和第二记录的记录类型的至少一个记录的约束，则第一记录具有与所声明规则相关联的记录类型，规则声称第一记录类型的记录应仅在部分数据库中被接受，以及第二记录的记录类型是关于第一记录类型的子集成员记录类型。
应注意的是：上述数据库操作的日志的各种扫描可以作为一个扫描执行，其中获取全部相关信息，或者可以重复执行扫描以每次扫描操作仅获取一个或者一些数据项目。
在一些实施例中，第一、第二和第三记录类型之间的关系明确定义为角色。明确或者暗示地取决于设计要求，本发明的实施例可实现角色的任意组合。
本发明的计算机系统可以包括一个或者更多服务器计算机，具有被编程的处理器以执行本发明的方法以更新电子客户机装置。本发明的计算机可读介质可包括指令，当执行该指令时使服务器计算机执行本发明的方法。计算机可读介质例如可以是磁或光学可读介质，诸如硬盘、CD-ROM或DVD-ROM、快擦写存储器、电可擦写可编程只读存储器(EEPROM)，或者本领域技术人员已知的任何其它方便类型的存储装置。
本发明的细节在所附的权利要求中限定，下面参照附图阐述示例的示例性实施例。
附图说明
根据下文中给出的详细描述和附图，本发明的示例性实施例将变得更完全理解。这些附图仅以例示方式给出，因而不限制本发明。在这些附图中，相同的附图标记表示相同元件，其中：
图1是例示根据本发明的包括可被同步的服务器和客户机的系统的图；
图2是例示根据本发明的数据库客户机的同步之前和之后的选择表的示例性值的图；
图3示出根据本发明的表的示例以及在数据库操作中它们如何彼此相关；
图4是例示数据库的不同部分如何由于不同原因而可以与客户机的同步相关的图；
图5是例示根据本发明的同步的方法的流程图；
图6是例示识别在同步期间作为用于更新客户机的候选的数据库条目的方法的流程图；
图7是例示确定是否所识别的数据库条目应更新客户机以及用于找到针对该更新的适当数据库命令的方法的流程图；
图8是例示确定第一类型的数据库记录在特定时间点是否在客户机中被或者曾经被接受的流程图；
图9是例示确定第二类型的数据库记录在特定时间点是否在客户机中被或者曾经被接受的流程图；
图10是例示确定第二类型的任何数据库记录在特定时间点是否在客户机中曾经被接受的方法的特定细节的流程图。
具体实施方式
下面将详细描述实施例，在附图中例示出了其示例。在以下详细描述中，提出各个具体细节以帮助对本发明的彻底理解。然而，本领域技术人员应理解的是本发明不限于此处提出的具体示例，并且本发明可以在不用这些具体细节的情况下实现。应理解未详细描述多个已知方法、过程、部件、电路和网络，以免不必要地混淆实施例的各方面。
本发明涉及数据库的同步，尤其涉及客户机计算机和服务器计算机之间的同步，其中服务器计算机主持整个数据库，并且客户机计算机至少包含存储在服务器计算机上的数据的子集。应注意的是当本说明书将中央数据库称为整个数据库或者完整数据时，完整性仅是关于其客户机而言的。完整数据库不须相对于例如处于更高层级并且该数据库从其接收数据的任何其它数据库是完整的。
客户机计算机可以是永久连接到诸如因特网的通信网络的个人计算机，但是客户机计算机还可以是膝上型计算机、PDA(个人数字助理，也称为掌上型计算机或者手持计算机)，甚至是移动电话、媒体播放器或电子游戏装置。客户机计算机因此可以设置有用户接口装置，诸如显示器(例如触摸屏)、实体或者虚拟键盘、定点装置(例如鼠标或者操纵杆、滚轮或者点击轮)和扬声器中的一个或更多个。为了简化，在以下的讨论中，使用包括触摸屏的便携式多功能装置作为示例性实施例。
现在参照图1，图1例示包括中央服务器和若干客户机装置的系统。装置全部被连接到网络110，网络110可以包括一个或更多数据通信网络，诸如因特网、无线或者固定局域网(WLAN、LAN)、移动电话网络(经常称为蜂窝网络)。中央服务器101通常永久连接到网络110，并且用于主持构成数据库的各个记录表。另外，服务器101将通常主持数据库管理系统(DBMS)和万维网(web)服务器方案，该万维网服务器方案能够提供数据库和客户机之间的基于万维网的接口。数据库管理系统可以例如是来自MicrosoftCorporation的MicrosoftSQLServer、来自OracleCorporation的ORACLE数据库或者来自MySQLAB的MYSQL。万维网服务器方案可以例如是来自ApacheSoftwareFoundation的APACHEHTTPServer、或者来自MicrosoftCorporation的InternetInformationServices(IIS)，可能与诸如PHP、Python、RubyonRails或者ServerSideJavaScript(SSJS)的服务器侧脚本语言组合。万维网服务器将能够使用HTTP和TCP/IP协议向客户机提供数据库内容，客户机可以使用本地地运行在客户机装置上的万维网浏览器型应用程序来访问数据库内容。或者，可以使用和适当协议并且客户机可以使用专用应用程序，代替万维网浏览器。
服务器101可以在若干计算机的系统上实现，并且在若干数据库中对数据进行复制或者镜像也与本发明的原理一致。为了清楚并且避免不必要的混淆，此处描述的示例性实施例将被描述为仅包括一个服务器计算机，但是本发明不限于此。
第一客户机装置102示出为具有触摸屏和触笔型输入装置的PDA或者平板计算机。第二客户机装置103可以例如是另一个PDA或者智能电话。第三客户机装置104例示为膝上型计算机。第四客户机装置105示出为个人计算机或者工作站。个人计算机105可以与服务器101永久在线。这表示传统在线客户机-服务器技术，其中可能不需要同步。相反，在个人计算机105上进行的全部改变可立即传递到服务器101并且存储在数据库中。按照图1例示配置的系统的现实示例可以是这样的：其中，中央数据库服务器101存储整个库存并且列出从商店连锁中可得的产品。可以由用一些类型的产品，例如服装，对若干商店补货的送货卡车的司机使用客户机计算机102。客户机计算机103可以用于对一个特定商店中的全部类型产品盘存，并且膝上型计算机104可以由访问若干商店并且登记订单的销售表示使用。个人计算机105可以在中央办公室中使用以管理数据库服务器101，输入新产品类型并从数据库中删除中断产品，改变价格等。
本领域技术人员将容易理解可以在不同的客户机装置上进行多个改变，包括相互不一致的改变、要求更新其它客户机装置的改变、以及具体地这样的改变：即要求未改变但是作为在不同装置处进行的改变的结果而变得对于特定客户机装置有关或者无关的数据被同步。后者的示例可以是使用膝上型计算机104的销售表示被分配到商店中的新部门。列出销售表示的各个分配的分配表中的条目可以反应该改变，并且当客户机下一次被同步时所述条目在销售表示的膝上型计算机104上应被更新。然而，销售表示也将需要在膝上型计算机中访问针对该部门的所述条目，以及表示该部门存储的产品的记录。这些记录未改变，但是在下一次同步时仍需要添加到表示的膝上型计算机104中。应注意的是：可在客户机自身或者在服务器上进行对分配值的实际改变。如果在客户机上进行改变，则其可被导入到服务器，接着在下面的同步期间被采取行动。
尽管图1例示的示例仅包括一个服务器和直接连接到该服务器的多个客户机，本发明可以在层级系统中实现，其中客户机自身相对于附图中未示出的额外的客户机作为服务器操作。
现在参照图2，图2例示以上概括的示例。在图2A中，称为“分配”的第一个表包括引用“表示”104和表示104被分配的“部门”1001的条目。条目可以是外键，即，引用不同表中的键的键。为了方便，用其客户机计算机的相同号码识别表示，该号码可以在对应的表(未示出)中找到，并且用可在部门表202中作为主键找到的号码识别该表示被分配的部门。第三个表203列出在哪些部门可以找到哪些产品。该表示出多个条目，在本具体示例中列出两个部门10001、10002之一，以及可在该部门找到的产品。随着产品添加到库存或者被去除，可以插入和删除条目，或者如果产品从一个部门传递到另一个部门则可改变条目。每个条目是引用不同的表的外键。最终的表204简单地通过产品号码和名称列出全部产品。表中应当在销售表示的客户机计算机上存在的全部记录用灰色图案指示。
在图2B中，从表201可见，销售表示现在被分配给部门10002。这是数据库中唯一改变的记录，但是销售表示现在需要访问表202中针对不同部门的数据库条目。这就意味着在针对部门10001的条目可被从客户机数据库中去除的同时，针对部门10002的条目应被导出到客户机数据库。
然而，仅导出被在分配表201中改变了的记录引用的记录是不充分的。还需要导出引用新导出的记录的全部记录。在本示例中，这就意味着表203中引用所导出的部门记录10002的全部条目也应被与表203中被新导出的记录引用的产品表204中的全部记录一起导出。这样，新部门中可得的全部产品将呈现在客户机装置上，如图2B中的表中的灰色图案所示。
为了帮助同步，可以在服务器101上维护日志。该日志可被DBMS创建和维护。可在全部客户机装置上维护类似的日志。该日志可以是这样的从数据库分隔的一个或更多列表，或者可以实现为数据库中的一个或更多表。
日志的一个目的是帮助收集任意时间间隔内的数据库改变。在下文中，这种时间间隔将被称为Δt，并且在Δt期间收集的改变将被称为数据库Δ。数据库Δ仅引用已经实际改变的记录，不引用作为其它改变的结果而需要添加到客户机的记录。在以上示例中，分配表中的条目将被包括在数据库Δ中，而不是针对部门和商品的受影响的条目。那些受影响的记录或者条目将被称为具有它们关于客户机改变的接受(acceptance)，并且，未改变的、但是它们的接受改变的全部记录的集合将被称为接受Δ。数据库Δ和接受Δ的总合将被称为触发的Δ。
适当时间窗口Δt的选择可基于客户机的先前的同步。例如，时间窗口可以在先前同步结束之后一个时间单位开始，并且在当前同步启动时的时间单位结束。时间单位可以是数据库中时钟的一增量步，并且可以被称为“滴答”。
日志的另一个目的是使得能够获得在任意时间t出现的任何存在或者不存在的记录值。这与配置客户机以保持跟踪其何时被最后同步相组合，变得能够在不在同步实际启动之前配置服务器以准备与任何客户机同步的情况下，在任何时间同步任何客户机。然而，应注意的是本发明的一些实施例可以实现从日志清除旧记录。如果，例如因为清除，针对当客户机请求同步时确定的时间窗口的日志不完整，则可能需要进行使之完整而不是增量的更新，因为要求的值可能从日志丢失。
日志可以包括日志条目，这些日志条目描述数据库随着时间转变的完整历史。每次插入新记录(INS)可以创建INS-entry类型的条目，并且每次删除已有记录(DEL)可以创建DEL-entry类型的条目。每次更新已有条目(UPD)可以创建跟着INS-entry的DEL-entry。
日志条目通常可以包括记录发生(occurrence)的RID，指示何时进行条目的时间戳，指示条目类型的日志状态，以及记录类型的全部列。
同步日志条目还可以识别哪个客户机发起了更新。这可以用于防止将更新发送回发起者作为更新，这通常被认为是不希望的行为。然而，这个规则可能存在例外，并且在此情况下日志条目可以指示这些。这种例外的示例是当作为在客户机的最后同步之后在服务器上进行的改变的结果，在导入处理期间来自客户机的导入被改变时。在导入期间进行的改变将需要返回客户机，在此情况下更新需要被发送回发起装置。这种改变的示例可以是在服务器上将产品类别“衣服”改变为“服装”。当从客户机导入的新条目包括位于一个记录列中的“衣服”值，并且该值在导入到服务器期间改变为“服装”时，整个记录应被发送回发起装置以在客户机上更新该值。
分割导出是指更新被划分为单独传递的若干部分的情形。为了有助于分割导出并且使得能够基于实际最后接收的发生进行恢复，限定Δt的时间窗口时钟以及最后记录(表类型和RID)被与同步日志一起保持在客户机数据库中。根据本发明的一些实施例存在针对数据库的一个时钟值的集合。替代实施例可以利用用户定义的接受方法针对每个外键层级包括一个Δt。不属于任何外键层级的表还可具有单独的Δt。这可以导致更灵活的方案。然而，同步原理将是同样的。
作为内置于客户机并且通常用户不可访问的存储器区域的系统区域可以用于保持关于时钟的信息以及由同步处理使用的处理信息。该数据库日志状态区域可用于确保全部必要信息自身在数据库中可访问，并且可有助于平滑的和可重启动的处理，例如如果由于失去客户机和服务器之间的连接使同步中断。因为用于同步的全部必要信息可从数据库日志得到，所以可以在没有因为在启动同步之后对数据库进行的改变导致的任何损坏的情况下从中断点恢复同步。
为了避免来自夏令时、时区或者任何种类的时钟调整带来的混乱，数据库时间戳可以包括进行同步的装置的实际系统时钟，或者人工时钟，或者这二者。系统时钟时间戳可以在全部装置上使用协调世界时(UTC)以使时间戳独立于时区。人工时钟实际上是针对每个数据库事件增加1的计数器。因此，即使系统时钟被调整，人工时钟也不受影响。然而，本发明不限于任何跟踪时间的特定方法。
同步日志在系统中包括的全部计算机和装置上维持。在表1中示出日志的简化示例：
同步日志
RID＝“1004”；时间＝“7354”；日志状态＝“1”；名称＝“男士夹克”；客户机＝“104”；#INS
RID＝“1002”；时间＝“7355”；日志状态＝“0”；名称＝“毛衣”；客户机＝“102”；#DEL
RID＝“2003”；时间＝“7356”；日志状态＝“0”；PDA＝“102”；商店＝“D”；客户机＝“101”；
RID＝“2003”；时间＝“7457”；日志状态＝“1”；PDA＝“102”；商店＝“F”；客户机＝“101”；#UPD
表1
该示例首先示出在产品表中插入了具有RID＝“1004”的新项目。该示例假定RID的第一数位识别表。时间戳是数据库事件的计数，已达到“7354”，并且日志状态＝“1”指示这是插入，如位于日志条目的末尾的注释#INS所指示的。在数据库记录的名称列中，插入了值“男士夹克”。日志条目还列出客户机，客户机＝“104”。后者识别从其插入记录的客户机。根据此示例，全部交易被记录在同一列表中。然而，在一些情况下，通过针对数据库中的每个表使用单独的日志可以增加效率。日志还可以包括索引，该索引有助于在触发处理期间在日志中搜索和查找。
日志中的第二行是指示从数据库删除了具有RID＝“1002”的条目的条目。时间戳增加了1，并且日志状态＝“0”指示这是删除。由于整个记录被删除，因此不需要列出针对该发生的任何列条目。然而，日志中包括删除值使得能够确定在删除之前哪些值被存储在记录中。因此，日志列出值“毛衣”以及启动删除的客户机，客户机＝“102”。应注意的是：原则上仅需要在数据库日志中输入接收新值的列或字段，因为先前的值可以在更早的日志条目中找到。然而，在日志条目中包括全部列，以及未改变或者删除的那些，可以有助于找到在过去的任意时间的表行的内容的能力，只要在该时间日志开启并且日志没有被清除。在另一方面，如果在日志中仅记载了部分条目，则可能变得不能够分辨在同步期间需要的值是否已经被清除，使得完整而不是部分同步变为必须。因此可能难以将记载仅改变的值以及从日志清除老的条目组合到一起。
最后已经更新具有RID＝“2003”的记录。RID的第一数位这次识别不同的表，即识别一个PDA对特定商店的分配或者关联的表。应注意的是：在类似这种情况下的更新包括日志中对应于两个数据库事件的两个条目。首先删除原始数据库条目，如由日志状态＝“0”所指示的。PDA＝“102”指示的该数据库条目被分配到商店＝“D”，假定这些商店被一个字母指定来识别。如上所述，指示在该记录的列中输入的值的字段不必被输入在数据库日志中，但是为了清楚在此包括在内。在删除之后，在表中插入具有相同RID的新记录。该新条目具有PDA列中的相同值，但是日志条目中的值指示该条目的商店列中的值应是“F”，识别不同的商店。
尽管以上将该日志描述为对数据库中的记录进行的数据库操作的一个或更多列表，但是还可以想到其它替换方式而不背离本发明的范围。例如，日志可以包括每次客户机被同步时或者甚至每次进行数据库操作时整个数据库的状态的大量的“快照”。基于当前对诸如存储器和处理能力的资源的限制，这种记载日志的方法可能不实际，但是应设计为满足必要的要求，也就是捕捉给定客户机的相继的同步之间对数据库的全部相关改变。
传统上，基于日志的增量同步是基于同步日志的简单检查以确定对数据库进行了哪些改变并且在同步期间将全部相关改变传递到客户机。使用了过滤器来确定对给定客户机哪些改变是相关的。然而，在被其它表中的外键引用的表上进行过滤的数据库中，必要的更新可能被排除并且外键约束可能不再被满足，如以下示例可例示的。
考虑在时间窗口Δti-1期间记录类型商店的新记录被添加到数据库的情形。存在记录类型商店和记录类型产品之间的外键约束，并且还添加十个记录类型产品的新记录。新产品是新商店的库存的一部分。
假定在时间窗口Δti-1的终点的特定客户机的同步期间，即基于对应于Δti-1的数据库Δ，与该客户机相关的过滤器防止新商店和产品插入到客户机上存在的部分数据库中。如果在Δti期间在服务器数据库进行了更新，将数据库改变为新商店和产品将通过相关客户机过滤器，但是没有对商店和产品记录中存储的值进行改变的状态，则针对间隔Δti的数据库Δ将没有条目指示对那些记录的任何改变，因此当在间隔Δti的终点处客户机与服务器同步时，它们将不被传递到客户机。
为了处理部分数据库的同步，其中在该部分数据库中，允许给定记录的接受独立于记录自身是否被改变而改变，本发明进行不仅基于通过日志确定的数据库Δ的更新，而且引入触发的Δ的概念，其中如果不是数据库Δ的一部分的记录被作为数据库Δ的一部分的记录触发，则不是数据库Δ的一部分的记录被包括在内。
在本发明的一些实施例中，作为外部变量的结果，可以使记录的接受改变。外部变量的示例可以是日期或者时间。例如，可能不期望使工作订单在客户机上可得直至应被处理的前一天为止。因此，可能需要浏览全部工作订单以识别在先前同步中被否决但是此次被接受的全部这种订单。由于外部变量而被改变了接受的记录可以接着触发附加记录。
最终，所触发的记录可以递归地触发附加记录。
将在以下更详细讨论触发这一概念，但是首先将注意力转向记录类型和记录类型相对于彼此可具有的各个角色之间的关系。尽管角色的明确定义在本实施例中不是本质的，但是角色的定义可以帮助适当在复杂表中包括触发的Δ中的表。因此，本发明的实现方式可以因此包括此处描述的角色的子集，描述的全部角色，或者甚至此处定义的角色的超集，因为作为设计判据和在具体实施例中需要的结果，附加角色的定义对于设计选择是开放的。
图3示出表的示例以及它们如何彼此相关。表、或者记录类型之间的关系将被本领域技术人员理解。当一个表中的项目(或者记录)涉及不同表中的一个或更多项目时使用关系。关系可以是一对一、一对多或者多对多。一对一关系的示例是“配偶”。结婚的男人仅有一个妻子，并且该妻子仅有一个丈夫。一对多关系的示例是性别的关系。术语男性和女性将应用于很多人，但是每个人仅是其中一个或者另一个。多对多关系可以例如是书和作者之间的关系。一本书可以具有超过一个作者，并且作者可能写了超过一本书。这些不同类型的关系根据本发明按照相同方式处理，并且不失去一般性，不规定描述的特定关系是一对一、一对多还是多对多。
图3的示例是基于关系数据库实现。在关系数据库中，记录类型表示为表并且记录是表的行。在以下描述的示例中，用语“表”可一般化为“记录类型”，并且“行”可一般化为“记录”，相反地“记录类型”可用“表”“示例化”，并且“记录”可用“行”“示例化”。不应从各个示例中使用哪个术语推出本发明的范围的限制。
在本发明的上下文中，可以使用用户定义的接受方法来确定表中的具体行是否应被传递到客户机。因为表之间的关系，传递已经改变的或者通过直接作用于特定表而改变其接受的记录通常是不充分的。另外可能需要传递或者更新来自与受关注的行有关系的其它表的行。例如，如果特定作者被添加到书店的选择因而添加到与该书店相关联的客户机计算机，则可能变得需要不仅将表示该作者的行而且将表示该作者的写的书的行传递到该客户机。类似地，如果因为要在下一天执行而改变了工作订单的接受，则还可能变得需要传递来自任务表的特定任务。为了描述接受规则如何将关系考虑在内而引入角色概念。
定义了反映不同表或记录类型之间的关系的各种角色，并且使得能够定义当客户机被同步时触发正确更新的触发方法和规则。各种角色可以取决于表彼此相关的方式、它们的接受是否取决于声明的接受方法以及其它表中发现的参数，以及明确的声明。图3例示了示例。
第一个表301将称为商店拥有者表。该表可以仅保持商店拥有者的列表，并且数据库中的每个商店将在拥有者表301中被称为拥有者。应注意的是：该表在本示例中没有角色。仅那些与接受方法直接或者间接相关联的表具有角色。在本示例中，没有与商店拥有者表301相关联的接受方法。
在本具体示例中第二个表是商店表302。商店表，如其名称所暗示的，是其中每个行表示特定商店的表。在本示例中，商店表302将是与接受方法相关联的表。这意味着当客户机与数据库相关联时，取决于给定商店是否被针对该客户机的过滤器接受或者停止，数据可以或者可以不发送到客户机。接受方法作用的表将被称为母表(mothertable)。因此母亲是接受方法直接工作的记录类型的角色。接受方法不在像商店拥有者301的较高级别的记录类型上工作。然而，接受方法间接地工作于其直接相关联的记录类型的子树中的记录类型上。
第三个表303是保持商店表302的接受所基于的参数的表。在本示例中，表303被称为PDA表303，保持PDA客户机计算机的列表并且存储每个列出的PDA被分配的商店。然而，接受方法也可间接工作于其操作的在该表中存储的参数。例如，商店表302可以保持表示哪个PDA被分配给商店的值，并且接受方法可被设计以当PDA被同步时接受该行(即，该商店)。
关于商店记录类型，表303的PDA记录类型是孩子，并且其也是参数保持器。与本发明的原理一致，参数保持器还可以不相关(即，它们不需要是它们用作参数的记录类型的孩子。)在这种情况下，参数保持器可以对表中的全部行具有相同效果。因而，参数保持器可以例如作用以对于接受而打开或者关闭表。当然，接受方法可以采取附加参数，因此对于表的全部行，接受不必须是相同的。
第四个表将被称为商店_产品表304。商店_产品表304可以例如包含关于在任意具体时间在商店表302中的各个商店中库存的产品的信息，以及每个商店保持每个产品的多少条目。
针对每个商店输入相同产品若干次当然将是不方便的。因此，每个产品在称为产品表305的单独的表中仅列出一次。这将数据库带入已知为第二范式。
类似于表303的PDA记录类型，表304的商店_产品记录类型对于表302的商店记录类型是孩子。此外，商店_产品记录类型对于表305的记录类型制品(article)是儿子，相反地表305的制品记录类型相对于商店_产品记录类型是父亲。应注意的是：产品表305可以被整体地发送到客户机。根据本示例性实施例中采用的术语，不被限制的表不是父亲。代替地，父亲必须被声明。被声明的父亲是被其儿子限制，而儿子被其母亲限制。根据本发明的第一实施例，如果没有与其相关联的接受方法并且不被相关的记录限制则默认记录被接受。在其它实施例中，默认可以是记录不被接受除非通过接受方法或者通过被相关记录触发而被明确接受。
还定义称为产品总数306的附加表。产品总数可以例如存储产品表305中存储的每个产品的总销售量。产品总数306是产品305的非限制子集成员，并且定义为具有姐妹的角色。由于在此情况下在商店_制品304中，儿子中的数据库发生改变影响姐妹，所以儿子也扮演兄弟对姐妹的角色。
此外，图3示出的是称为销售307和购买308的两个附加表。销售表307可以例如存储商店中进行的每个销售，并且购买表308可以存储为了向商店重供应产品而进行的每个购买。这些表的记录类型对表304的商店产品记录类型扮演孩子的角色。
通过检查日志中的相关值来确定接受。针对特定记录或者表行的条目将被称为该记录或者行的实例。当同步时，关注两组值，即在时段Δt的起点处或者刚好在起点之前记录中存储的值，以及在Δt的终点或者刚好某位之前处的对应值。在大多数情况下，这些值可被作为针对时段Δt的起点之前的记录的最新日志条目和针对时段Δt内的相同的记录的最新日志条目。这两个例子将称为对。
与本发明的原理一致，可以考虑两个不同问题。第一问题是确定对对中的实例的接受。另一个事项是基于两个实例的接受确定是否该对应该更新客户机。术语接受将指特定实例(即，与特定时间点相关联的记录值的特定集合)是否曾经或者应该在客户机上存在，确定对是否应该更新客户机将称为过滤。如果对通过过滤器，或者如果过滤器对于对返回“真”，则该对应该更新客户机。对通过过滤器可以意味着新记录被插入，用新值更新现有记录，或者现有记录被从客户机删除。通过确定是否实例被不被接受的任何其它记录类型实例限制来确定对实例的接受(例如，孩子是否是不被接受的母亲的孩子)，或者通过确定是否通过用户定义的接受方法确定接受来确定对实例的接受。通过用户定义的接受方法检查的值是作为接受方法的参数定义的实例的值。
当确定是否对通过过滤器时，可以确定两个实例的接受。与本发明的原理一致，过滤器进行的确定的结果可以是基于至少以下一个的确定：1)是在Δt的起点或者刚刚之前在客户机中被接受的记录，以及2)是在Δt的终点或者刚刚之前在客户机中被接受的记录。
上述两个问题可导致4个不同结果。如果两个问题都否定回答，则记录在先前同步不被接受，并且现在不应被接受。因此，该对不需要通过过滤器。如果对第一个问题的回答为是并且对第二个问题的回答为否，则记录曾被接受，并且假定已经在客户机上存在，但是应不再被接受。因此客户机上已存在的条目应被去除，并且接受改变意味着记录应被从客户机删除(DEL)。为了进行该任务，对必须被允许通过过滤器。相反地，如果对第一个问题的回答为否并且对第二个问题的回答为是，则记录可能需要被插入到客户机数据库(INS)中。再次，其将需要通过过滤器。最终，如果两个问题可被肯定回答，则服务器上的记录的值的任何改变也对客户机相关，并且该对应该通过过滤器。下面将更详细描述在本发明实施例中该处理确切应被如何处理。
在一些情况下，可基于在不同表的行中找到的参数确定针对母亲的接受。这种表将被称为参数保持器，在图3中用PDA表303例示。根据存储在其它表中的参数确定的接受将被称为母亲的基于参数的接受。
对于不具有相关联的接受方法的记录，可通过检查其它记录确定接受。例如，为了确定对于购买表308中的行的接受，必须确定针对商店产品表304中的所引用的行的接受。如果购买表中的行经历例如外键约束(即，如果购买行中存在引用商店_产品的外键引用)，则如果所引用的商店_产品行被接收，则购买可仅在客户机中被接收。否则，参考完整性将不满足。由于没有针对商店_产品表304定义的接受方法，必须通过检查被商店_产品表304中的行引用的商店表302中的行进行类似确定。因此可能需要在日志中进行递归查找。通过对日志加索引以及通过将日志分割为针对每个表的单独的日志片段，可以增加日志搜索的效率。
角色概念帮助定义关于未改变的发生如何和何时应被作为对数据库的其它改变的结果而触发的规则。为了在客户机上维持正确的部分数据库，应该或者不应该在客户机上的全部记录应被适当地同步，同时满足全部约束。因为对不与接受方法相关联的记录的接受取决于其与具有接受方法的表即母亲的关系，所以具有与其相关联的接受方法的记录、母亲记录，是组合起来定义客户机上的部分数据库的范围的记录。
如果针对具有接受方法的记录即母亲的接受改变，则这应该触发全部她的孩子，即，该母亲的子树的全部记录。应注意的是：日志不直接提供关于是否记录(诸如表行)在任何特定时间点曾被任何给定客户机接受的答案。如果记录具有接受方法，则可通过在表示该记录自身的行的值中，或者在参数保持器表中，检查日志记载的值或者对于方法是参数的值来确定。如果记录不具有接受方法，则必须确定针对该记录母亲的接受。
在图3例示的示例中，可以基于存储在PDA表303中的参数接受母亲表。如果在具有从PDA表303取得的参数的商店表302上操作的接受方法确定因为在PDA表303中的条目进行的改变，来自商店表302的特定记录发生应该现在在PDA中被接受，则变得不仅需要加入来自商店表302的相关商店，而且需要加入来自表的子树的全部相关行，从而在全部数据库约束可以被满足。通常这意味着在表304中作为引用不再被接受的商店的产品而输入的全部商店_产品也可以不再被接受，以维护引用完整性。类似地，引用现在在客户机中被接受的商店的商店_产品也应被接受。此外，在产品表305中找到的这些产品的全部描述也应被输入。根据本发明的一些实施例，被引用为父亲表的类似产品表305的表中的条目可以基于从引用儿子表(在此情况下商店_产品表304)进行的引用而被接受。应注意根据本说明书采用的术语，父亲表可以不具有与其相关联的接受方法。如果具有则其为母亲表。
此外，商店_产品表304的孩子，销售表307和购买表308，以及项目总数表306也应被添加到客户机(或者根据可能的情况被去除)。
在触发处理中，参数保持器发生触发母亲表商店的行，商店表中的被触发的行触发孩子表商店_产品中的行，并且商店_产品表中的被触发的行触发销售表和购买表中的自身的孩子。
应注意的是虽然本示例假设母亲表具有基于参数保持器表中的参数确定的其接受，但是还可以基于仅表本身中的内容来过滤该表。例如，商店表302可具有称为PDA的列，并且在该列中输入的特定PDA可确定记录是否应在客户机上被接受。
现在将关注触发的概念。如已经提到的，触发不需要取决于对记录进行的改变。因为接受的改变，记录还可以被包括在触发的Δ中。触发的发生是表示在时间段Δt期间未改变但是针对当前同步的客户机改变了其接受的记录的对。
现在参照图4，图4例示在根据本发明的增量同步期间数据库的不同的相关部分。在图4A中，数据库的整个范围例示为区域400。数据库400的第一个子集410表示两个相继的同步之间改变了的数据记录(例如，表行)。这称为数据库Δ。数据库400的第二个子集420表示作为外部变量的结果而改变了接受的记录。最后，数据库的第三个子集430表示被其它记录触发的记录，即作为其它记录的改变的结果而改变了接受的记录。
将认识到这些集合可以交叠。例如，当不被接受时工作订单可能在第一次同步之前输入，并且在以下的同步之前改变，因而属于子集410，并且还作为外部变量的结果变为对于客户机可接受。类似地，被母亲触发的孩子(因而属于子集430)可以也已经改变，使得其属于子集410。然而，把相同记录处理多次可能不方便。因此，如图4B所示，在本发明的一些实施例中，数据库Δ被定义为改变了的全部记录411，经过外部变量的记录收集在子集421中，仅如果它们不已经是数据库Δ的一部分，以及仅被其它记录触发并且如果不改变(即，不在子集411中)并且不经历来自外部变量的接受改变(即，不在子集421中)则包括在子集431中的记录。
现在参照图5，图5例示可以如何进行根据本发明的方法的流程图。处理开始于初始步骤500。然后，在下一步骤501中，可以接收在同步的客户机上进行的全部改变、插入或者删除。然后，这些可应用于数据库并且在同步开始之前包括在数据库日志中。如已经提到的，从客户机接收的改变通常在同步期间将不返回到客户机，但是此规则可以有例外。
处理接着移动到步骤502，其中，收集数据库中进行的全部改变。该处理创建图4B中示出为子集411的数据库Δ。在步骤503将所收集的改变添加到触发者的列表中。尽管本发明不限于该方面，可以在触发者的列表中成对输入改变，如以下更详细描述的。在一些实施例中，改变还可以输入仅一次，例如可被插入或者删除的记录仅被输入作为触发者的列表中的一个INS或者一个DEL条目。
接下来，在步骤504中，数据库被浏览以识别从外部变量改变了接受的记录。如上所讨论的，示例可以包括在特定时间点改变了接受的记录。作为在图4B中示出为子集421的接受Δ的一部分的这些改变被添加到触发者的列表中，如步骤505所示。
在步骤506中，触发者的列表中的条目将触发相关的对，并且它们将针对接受改变而被调查。与图4B的子集431相对应的被触发的对将被添加到触发者的列表，并且处理递归地继续直至触发者的列表中没有新的触发者为止。将在以下参照图6进一步描述该处理。
当触发的处理完成时，在步骤507中对全部触发者的列表中的对进行过滤，并且开始实际同步。该方法终止于步骤508。
应理解的是：虽然已经作为一系列离散步骤描述了以上参照图5讨论的方法，具体步骤序列仅是为了便于理解而选择的一个可能性。例如，步骤502中从数据库日志收集改变的步骤和将所收集的改变添加到触发者的列表的步骤描述为两个相继的步骤。然而，改变可以随着被收集而输入到列表中，使得每次在数据库日志中找到改变，该改变可以在方法继续以定位数据库日志中的下一个改变之前被记录在触发者的列表中。此外，不需在触发之前收集全部改变。可以例如期望以更小的块(chunk)将数据发送到客户机，并且为了实现这一点，可以使用来自数据库Δ的预定数量的改变对以触发它们的各个子树中的全部相关对，并且在继续到下一个预定数量的触发者之前同步这些对。因此，在一个极端情况，能够收集第一个改变对，以找到被第一改变对触发的全部对，进行过滤并且在进行到数据库Δ中的下一个改变对之前将相关的改变传递到客户机。在另一个极端情况，首先收集所有改变，接着基于所有收集的改变触发所有，接着针对所有收集和触发对进行过滤，最终将全部相关更新传递到客户机。
另外，识别由外部变量改变的记录的步骤504和将它们添加到触发者的列表的步骤可以在收集改变的记录之前进行。
现在更详细讨论图5的各个步骤。
当客户机已经从服务器断开时在服务器数据库接收在客户机处进行的全部改变的步骤使得能够处理在任意时间从任意客户机对数据库进行的全部改变。
在类似于用于收集改变的记录并且在服务器上建立数据库Δ的处理相类似的处理中，在客户机收集在步骤501从客户机接收的记录。然而，由于全部记录存在于服务器上并且全部改变应发送到服务器，所以不需要过滤这些记录，因此，也不需要识别被触发的发生。客户机仅发送其整个数据库Δ到服务器。
在从客户机接收记录之后，它们可以被插入在数据库中、或再数据库上删除或者更新。这些插入和更新被处理为与数据库的任何其它交互，并且输入在数据库的日志中。如已经提到的，从特定客户机接收的更新通常不被发送回客户机，但是在特定情形下可能要求例外。
在步骤502中，收集在时段Δt中对数据库进行的改变。这可以通过作为DBMS的一部分的方法或者子例程执行。该方法可以称为CollectRecords(收集记录)。CollectRecords方法检查针对时段Δt的日志以发现在t0和t1具有不同值的全部记录，其中t0是指针对此具体客户机的先前同步的时间点，并且t1是指针对此同步的时间点。换句话说，Δt表示从t0到t1的时间段。识别为在t0和t1具有不同值的全部记录被添加到触发者的列表中。应注意的是：如果在t1的全部值返回它们在t0处具有的值，则不需要添加在时段Δt期间改变了若干次的记录。与本发明的原理一致，记录被成对添加到触发者的列表中，对的一个实例表示在时间t0的记录并且另一个实例表示在时间t1的记录。在第一实施例中，记录的全部值包括在该对的两个实例中。在替代实施例中，包括在一个实例中的全部值，在其它记录中仅包括差异。在又一个替代实施例中，两个实例仅包括已经改变的值。原理上还能够在触发者的列表中仅包括时间t1的更新值，由于如果应该要求更早的值，则通过返回到日志可以定位它们。
在步骤502收集以及在步骤503输入在触发者的列表中的改变表示数据库Δ。根据第一实施例，通过方法CollectRecords将属于数据库Δ的全部记录添加到触发者的列表，是否它们与正被同步的具体客户机相关以及接受在触发的处理期间和/或仅在最终同步期间被确定。然而，与本发明的原理一致的是：确定数据库Δ中的每个对的实例的接受，并且如果其接受或者接受改变与客户机相关才将该对添加到触发者的列表。
浏览数据库以识别在Δt期间未改变任何值但是由于一些外部原因而改变了它们的接受的记录的步骤504，并且在步骤505可由方法或者子例程进行将这种识别的记录作为对输入到触发者的列表，该方法或者子例程可以是DBMS的一部分，并且将称为BrowseExternalAcceptanceChange(浏览外部接受改变)。该方法识别作为外置于数据库自身的一些确定因素的结果，例如作为随着时间过去的结果，相对于被同步的客户机(或者另选地对任何客户机)改变了接受的记录。为了识别自从先前同步以来接受改变的记录，需要知道在先前同步处外部变量的值的状态。将了解的是该值可能不从日志直接可得，由于通过定义的日志跟踪内部数据库值的改变。因此可能需要保持例如在单独的日志中跟踪这种外部值，并且这可以针对具有与外部接受方法相关联的类型的全部记录进行。
由于通过该方法识别的记录作为对添加到与数据库Δ的列表相同的触发者的列表，所以不需要识别已经添加到触发者的列表的记录，因为它们在Δt期间改变了值。因此，根据本发明的第一个方面，该方法仅识别在Δt期间未改变但是改变了接受的记录。或者，该方法识别由于外部原因改变了接受的全部记录，并且将它们作为对添加到触发者的列表。在此情况下可能需要从触发者的列表中去除重复，以避免相同记录上的多个触发。
应理解BrowseExternalAcceptanceChange方法还可以在CollectRecords方法之前进行，在该情况下CollectRecords方法可以被配置以仅包括具有至少一个值改变并且未改变其接受的记录，因为后者已经存在于触发者的列表中。
通过BrowseExternalAcceptanceChange识别的记录可被作为具有针对t0和t1输入的相同值的更新(UPD)添加到触发者的列表。然而，与本发明的原理一致的是：以仅针对t1的插入(INS)或者删除(DEL)仅输入一次记录(作为“半”对)。
处理现在移动到步骤506，其中应该被触发者的列表中列出的对触发的对，即，可能需要传递到客户机(或者从客户机删除)的对，作为触发者的列表中列出的对的间接结果。这种记录可以称为被触发对，或者被触发发生，并且用于识别它们的方法将称为TriggerOnRecords(记录上的触发)。
根据本发明的方面，被触发发生可以是在Δt期间未改变的对，如同通过BrowseExternalAcceptanceChange方法识别的记录的情况，但是作为对于其它记录的值或者接受的改变的结果，即作为触发者的列表中的条目的结果，针对一些客户机而改变接受。识别这种记录的处理将被称为触发，并且所识别的记录将被称为被触发对或者被触发发生。
在Δt期间未改变它们的值、但是因为外部变量或者因为被触发而被添加到触发者的列表的对可作为具有针对该对的两个实例的相同值的更新(UPD)被添加到触发者的列表中。本发明不限于该替代方式，因为可在任意时间从日志取得全部信息，但是作为更新添加未改变的记录可以在一些实施例中使得能够重复使用针对来自数据库Δ的对设计的方法。这将通过考虑以下因素实现。当针对来自数据库Δ的对在步骤507确定过滤器状态时，作为DEL的结果收集的任何对(即，在t0存在于服务器数据库但是在t1之前被删除的对)如果在t0被接受则应在t1的同步被从客户机删除，或者因为在t0不被接受所以首先不存在于客户机中，并且在t1的同步期间可被忽略。类似地，作为新INS被收集的任何对在t0不存在但是在t1存在，这意味着其应被插入在客户机中(如果在t1被接受)或者可被忽略(如果在t1不被接受)。
然而，如果来自数据库Δ的对被作为UPD列出，则意味着记录可能在t0已经存在(还可能在t0之后添加接着更新)，在t1仍存在，但是在Δt期间其值改变。在同步期间如何被对待取决于以下。如果在t0被接受并且在t1仍被接受，则应被对待为更新(UPD)。如果在t0不被接受并且在t1仍不被接受，则可被忽略。然而，如果在t0不被接受但是在Δt期间其接受改变因而在t1被接受，则必须被改变为插入(INS)，因为不是已经存在于客户机上。类似地，如果对于对中的实例的接受从对于第一实例的是到对于最后实例的否，则该记录不应在客户机上被更新而应被去除，这意味着应改变为DEL。由于仅在触发者的列表中作为UPD列出的对按照此方式改变，并且由于应该按照相同方式确定被触发的记录的接受，所以在触发者的列表中作为更新输入被触发的记录可以是方便的。
现在转向图6，将更详细描述步骤506中进行的触发的处理。该处理对应于图5中的步骤506，并且当举例各个角色时返回图3。应注意的是：用于引用各个角色的术语是为了方便而采用的，不旨在表示对本发明的任何限制。例如，与角色相关联的性别无关，并且记录类型可以具有不同性别的若干角色。例如，记录类型可以是母亲和儿子。可以容易地使用不同的术语以适当地描述本发明。
触发的处理可被方法或者子例程处理，该方法或者子例程可以是DMBS的一部分，并且被称为TriggerOnRecords。当在第一个步骤600开始时，TriggerOnRecords方法使用先前步骤中创建的触发者的列表作为输入。
在第一步骤601中，检查触发者的列表中的第一对。应记起来的是：虽然被检查的第一个对或者来自数据库Δ或者包括在列表中作为外部变量的结果(根据实现方式)，但是总体上作为参照图6概括的处理的一部分触发者可以自身被触发。
在下一个步骤602中，确定当前检查的触发者的列表中的对是否来自参数保持器的表，诸如例如图3的PDA表303。如果是这样，则处理进行到步骤603，其中母亲被触发。如参照图3说明的，与接受方法相关联的记录类型总是母亲，并且由于参数保持器是针对接受方法的输入参数，所以它们将总是触发被过滤的记录类型，即，母亲。
可以容易地从图3的示例理解为什么是这样。如果参数保持器是PDA和PDA被分配的商店之间的关联性的列表，则这种关联性的改变将明显地影响当与数据库同步时PDA应接收哪一个数据。触发母亲意味着来自母亲表302的至少一个识别的记录被作为对添加到被触发记录的列表。被触发对可被添加到触发者的列表，但是对于对中的两个实例，列值将是相同的，因为在Δt期间值未改变。(如果母亲在Δt期间实际被改变，则其将已经是触发者的列表的一部分，并且不需要将其添加到被触发发生的列表)。
应注意的是：可能需要将来自母亲表的超过一个记录添加到被触发列表。如果例如在t0处PDA被分配到了第一商店STORE01并且在时间t1处已经被重新分配到第二商店STORE02，如参数保持器中的改变指示的，可能需要从客户机删除STORE01并且添加STORE02。因此，STORE01和STORE02应均被触发并且作为UPD添加到触发者的列表中。在图5的步骤507期间，可确定分别地STORE01应被改变为DEL并且STORE02应被改变为INS。应注意的是：为了维持数据完整性，可能需要从给定客户机删除不再被该给定客户机接受的记录。然而，与本发明的特定实施例一致的是：如果数据库设计者可确保不以不可接受的方式损害数据的完整性或者客户机的存储容量，则允许该记录保留在客户机上。
添加母亲记录类型的处理可以被方法或者子例程处理，该方法或者子例程将被称为AddMaterFamilias(添加主妇)并且将来自参数保持器的对作为其输入参数。如上所述，AddMaterFamilias可以触发来自表的一个或者更多对。例如，因为参数保持器对中的第一个实例的值而被接受的一个记录因为参数保持器对中的最后实例的值而不再被接受，相反地针对第一实例不被接受的不同记录现在被接受。两者将被作为两个UPD对添加到触发者的列表，并且在更新被传递到客户机之前将分别被改变为DEL和INS。
在母亲对被作为一个或者更多被触发对添加到触发者的列表之后，处理进行到步骤604。类似地，如果在步骤602中确定触发对不是参数保持器，则处理在不触发母亲记录类型的情况下直接进行到步骤604。
在步骤604中，被考虑的对被进一步检查以确定是否该对应更新客户机，即，是否该对应通过更新过滤器。该确定可以基于对的实例关于被同步的客户机的接受的确定来进行。该确定可以使用与图5的步骤507中确定被触发对是否应更新客户机使用的相同的方法来进行。将在以下参照图7更详细描述该方法。
步骤604中进行的接受确定可以具有以下结果。如果对中的实例均不被接受，则该对将不更新客户机，因此不需要基于该对触发附加对，并且处理移动到步骤607。然而，如果实例的至少之一被接受，则该对可以要求客户机上的改变，并且该对应该进一步触发。这是因为对的过滤不确定是否记录应存在于客户机上，但是确定该对是否表示与客户机相关的改变。
如果在步骤604中确定记录不通过过滤器因而其应该更新客户机，则还应在以下的步骤605中确定该对是否是具有接受改变的触发者。如果确定针对该对的接受没有改变，则不需要进一步触发。该对可以仍更新客户机，但是不触发其它记录类型，并且处理进行到步骤607。原因是由于接受未改变，任何改变是对存储在记录自身中的值的改变，并且通过更新该记录中的任何改变的值客户机可以被正确地更新。这些改变不限制该记录子树中的任何记录。
然而，如果确定对于对的接受已经改变，则处理进行到步骤606，其中，基于记录的角色确定那些其它记录类型需要被触发并且添加到触发者的列表中。下面将更详细地描述基于角色的触发。在针对该触发者的基于角色的触发完成之后，处理进行到步骤607。
在步骤607中，确定刚刚被处理的对是否是触发者的列表中的最后的对。如果不是，则在步骤608中处理进行到下一个对，并且重复相同处理。这继续直至在步骤607中确定检查了全部触发者并且处理终止于步骤609。
在本发明的替代实施例中，步骤604和步骤605这两个步骤可以被不同地处理。例如，步骤605可以在步骤604之前执行。
再次返回图5，当在步骤506完成全部触发时，应该在步骤507中确定针对触发者的列表中的全部对的过滤器状态。当确定是否该对应该更新客户机时可以使用与图6的步骤604相同的过程，即下面参照图7更详细说明的过程。然而，在步骤604的触发期间进行的方法和在步骤507的同步期间进行的方法之间有一个不同。将回忆到只有对于对的两个实例记录的接受都为假，记录才与同步处理无关。还应回忆如果对被作为DEL或者INS添加到列表，即，对数据库中的记录的改变是删除或者插入，则记录应分别被从客户机删除或者插入到客户机。然而，如果该对作为UPD被添加到列表，则附加考虑变为需要。以上当说明为何被触发对可以作为UPD添加到列表时进行了简要讨论。这些附加考虑的结果是已经作为UPD添加的对可能需要改变为INS或者DEL。这可能不需要在步骤604中的触发期间进行，仅在步骤507的同步期间进行。
以下代码例示对的过滤，其中可以确定是否记录应在客户机上插入、删除或者更新。代码满足两个任务。第一任务是确定是否对应该更新客户机，通过如果应则返回“真”以及如果不应该则返回“假”来表示。其它任务是如果需要则将UPD改变为INS或者DEL。
图7例示通过以上列出的示例性代码进行的方法。方法开始于图7A中的启动步骤700，并且进展到步骤701，其中确定对中的第一和最后实例的接受。如果该对表示母亲或者孩子，则可通过以下参照图8描述的方法确定接受。如果该对表示父亲，则可通过以下参照图9描述的方法确定接受。根据本发明的一些实施例，不是首先确定对的记录类型的角色，而是进行两个方法，并且两者均应导致肯定接受使得实例具有肯定接受。
然后，方法进行到步骤702确定该对是否表示INS命令。如果情况为真，并且如果对中的最后实例不被接受，如在步骤703中确定的，则在步骤704中该方法对于该对的过滤返回假。如果最后实例被接受，则在步骤705方法对于过滤返回“真”。这意味着如果对被作为INS列出并且其在对中最后实例的接受为真，则其应通过过滤器并且被插入在客户机上。如果现在不被接受，则其不相关并且该方法返回“假”。为了方便，该对可以用两个相同实例表示。或者，插入可以表示为仅具有一个实例的“半”对，作为设计选项。
如果该对在步骤706确定为表示DEL，则方法进行到步骤707。如果在步骤707确定对中的第一个实例在客户机中不被接收，则在步骤708方法对于过滤返回“假”。否则，方法返回“真”。这意味着如果该对列出为DEL并且其对于该对的第一个实例的接受是真，则应该已经存在于客户机上，并且应被去除因为已经从服务器上的数据库中去除。因此，DEL保留为删除。该示例例示输入仅“半”对DEL和INS情况实施例如何是充分的，因为在这些情况下图7的方法仅需要考虑对的实例之一。
在该对作为UPD列出的情况下，如在步骤710中所确定的，应该按照图7B例示地处理更新，如在图7A和图7B两者中表示的步骤711指示。按照以下处理该更新。如果在步骤712确定该对的两个实例在客户机中被接受，则意味着该记录已经存在于客户机上并且应保留这样。因此，需要在客户机进行与服务器上进行了的相同的更新，并且UPD被保持。在步骤713中，方法对于过滤返回“真”；该对应该更新客户机。如果在步骤714确定该对的第一实例被接受但是最后实例不被接受，则意味着该记录存在于客户机上，但是其不应再这样。因此，在步骤715中该对被从UPDATE(更新)改变为DELETE(删除)，并且方法返回过滤器值“真”；该记录不再被接受并且该对应该通过过滤器以相应地更新客户机。如果在步骤717中确定该对中的第一实例不被接受但是最后实例被接受，则该记录不存在于客户机上并且应该被插入。因此，在步骤718中，该对从UPDATE改变为INSERT(插入)。如果实例都不被接受，则在步骤720步骤返回过滤器值“假”。
在本发明的一些实施例中，更新到删除或者插入的改变不在触发(图6的步骤604)期间进行，仅在同步期间进行(图7的步骤507)。然而，在替代实施例中，该对可以在触发期间改变并且在触发者的列表中改变，作为图6的步骤604中的处理的一部分。在后一种情况下，可能不需要在同步期间再次进行改变。
现在将参照图8更详细描述接受方法，其中例示用于确定针对记录类型的实例的接受的处理。接受方法是以上列出的示例性代码中的称为OnRT_Accept(实例)的方法。与本发明的原理一致，确定接受的基本原理是记录可以被接受除非是自身不被接受的子集拥有者的子集的一部分，或者如果明确不被用户定义的接受方法接受。前者确保维持数据完整性(如果包括对不被接受的另一个记录的引用则没有记录被接受)，后者可以向设计者提供减少传递到客户机的数据量的可能性。因此，参照图8描述的方法确定被检查的记录类型实例是否由于以上给出的原因之一而不被接受。如果确定，则实例的接受被确定为否定。否则，实例可以被接受。
可以稍微不同地确定对于具有父亲角色的记录类型的接受，如以下讨论的。
应回忆的是：记录类型的实例表示在特定时间点存储在特定记录类型的特定记录中的值，并且可从日志中找到这些值。当前通过接受方法检查的记录类型的实例将称为RecordTypeInstance(记录类型实例)或者RTInstance(RT实例)，并且其记录类型将称为RecordType(记录类型)或者RT。此外，被接受方法检查的实例，RTInstance，可以涉及一个或者更多子集拥有者。子集拥有者是不同的记录类型的实例，通过被考虑的记录类型引用。子集拥有者的记录类型将被称为OwnerRecordType(拥有者记录类型)或者ORT，并且拥有者记录类型的特定实例将被称为OwnerRecordTypeInstance(拥有者记录类型实例)或者ORTInstance(ORT实例)。ORTInstance可通过在RTInstance以及日志中的RTInstance的时间戳中引用来识别。
处理开始于启动步骤800并且进行到步骤801，其中识别针对该记录类型的第一子集拥有者。如果在步骤802确定没有识别ORT，则处理进行到步骤810，如以下讨论的。如果ORT被识别，则记录进行到步骤803，其中确定所识别的ORT是否可限制被考虑的记录类型。如果由于接受使ORT自身可不存在于客户机，则RT被ORT限制。如果ORT在客户机不被接受，则RT也不应被接收，因为这可能违反限制要求(RT可能涉及不存在于客户机的ORT，将危及数据完整性)。可通过考虑ORT的角色确定OwnerRecordType是否可限制RecordType。如果ORT是母亲或者孩子，则可限制RT。此外，如果ORT是父亲或者自身被父亲限制(即，姐妹)则RT还可以被ORT限制。在此情况下，ORT可以被称为间接母亲。将在下面更详细描述确定OwnerRecordType是否是间接母亲的处理。
如果在步骤803中确定ORT不能限制RT，则处理进行到步骤804，其中识别下一个ORT。然而，如果ORT可以限制RT，则在步骤805中建立被RT实例引用的特定ORT实例。通过从在RT实例中引用其的外键首先识别其主键，并接着扫描日志以找到在适当时间与该ORT实例相关联的值，来建立ORT实例。日志被向后扫描，从而如果RT实例是对中的第一实例则确定在时间窗口Δt的起点的适当实例值，并且如果RT实例是对中的最后实例，则确定时间窗口Δt的终点处的适当实例值。在步骤806中进行检查以确定是否适当地建立了ORT实例。如果否定，即例如RT实例是对中的第一实例，并且数据库中的对应的RT记录在Δt期间被插入从而其以前不存在，因而在时间窗口的起点没有ORT，则处理进行到步骤808，其中将对RT实例的接受设定为假。然而，如果适当地创建了ORT实例，则处理进行到步骤807，其中对于ORT实例确定接受。
如果ORT是母亲或者孩子，则可按照该RT实例相同的方式确定对于该ORT实例的接受。换句话说，当前描述的方法可被递归地调用以确定ORT实例的接受，其当然可以再次取决于其自身的ORT实例。
然而，如果ORT是父亲，则其可能被其儿子限制，即，被不是其拥有者而是其子集树的一部分的记录类型实例限制。如果是这样的话，则可能涉及不同的方法，如以下参照图9进一步描述的。
如果在步骤809中确定ORT实例不被接受，则RT实例不能够被接受，并且处理进行到步骤808。然而如果ORT实例被接受，则处理进行到步骤804以识别是否存在附加子集拥有者，RT实例的接受取决于该子集拥有者。如果是这样的话，如在步骤802中确定的，针对该ORT重复该处理。继续直至ORT实例在步骤806或者步骤809导致否定确定，在该情况下在步骤808将接受被设定为假之后处理在步骤813终止，或者直至在步骤802确定已经检查了全部ORT而没有任何接受的否定确定，在该情况下处理进行到步骤810以确定是否存在任何针对RT定义的用户定义的接受方法。如果未定义任何用户定义的接受方法，则RT实例不被任何ORT实例限制，并且也不被任何用户定义的接受方法限制，从而处理进行到步骤812，其中在方法在步骤813终止之前接受被设定为真。如果用户定义的接受方法被定义并且在步骤811根据用户定义的接受方法确定RT实例不被接收，则处理进行到步骤808，其中对于RT实例的接受被设定为假，并且方法在步骤813中终止。如果在步骤811通过用户定义的接受方法确定RT实例被接收，则在方法在步骤812终止之前处理进行到步骤812，其中对于RT实例的接受被设定为真。
以上参照图8讨论的方法可通过返回图3的示例来例示。例如考虑作为记录类型“购买”的对中的第一实例的实例是否应被保持涉及商店表302中的特定商店的全部数据的PDA接受。当方法到达步骤801时，第一ORT被确定为商店_产品表304，并且在步骤803将确定因为该记录类型是孩子，所以能够限制购买表308，从而处理进行到步骤805。在步骤805中，识别由购买实例引用的商店_产品表304中的特定行，即建立商店_产品实例并且从购买实例中的对应的外键引用取得构成其主键的一个或多个值。可以通过扫描日志找到填充(populate)所建立的商店_产品实例的剩余字段所需要的附加值。由于购买实例是对中的第一实例，所以关注的值是表示Δt的起点时的记录。然而，这些值可以在日志中在Δt的起点之后或者甚至在Δt的终点之后输入的DEL条目中找到。因此，需要从日志的结束开始扫描并且反向扫描，直至针对由主键识别的商店产品记录找到最好地表示Δt的起点处或起点之前的值的日志条目为止。如果当制作日志条目时日志存储记录的全部值，则找到这一个日志条目以便完整地填充ORT实例是充分的。如果仅在日志中输入了改变值，则将需要继续反向扫描日志，直至获得了全部值。
应注意的是：扫描日志期间对日志条目的选择可以取决于设计选项。例如，可以关于日志条目是否应被考虑来改变实施方案，如果它们表示时间窗口Δt的起点(或者终点)处或者之前的记录值，或者仅在时间窗口的起点(或者终点)之前的值。原因是可能不期望具有交叠的时间窗口从而日志条目属于一个时间窗口的终点和相继的时间窗口的起点两者。在一些情况下，日志将不包括将允许建立适当的记录实例的任何相关日志条目。可能是这样的情况：例如因为日志已经被清除或者因为从当创建数据库开始的初始值从未改变因此从未被载入日志。在这种情况下，可以总结数据库自身中找到的值比时间窗口更老，因此这些值可以用于对中的两个实例。在其它情况下，表示删除的日志条目可以在时间窗口Δt的内部找到，或者甚至在时间窗口Δt的终点之后找到，并且在时间窗口的起点或者终点仍然表示适当值，因为被删除的条目必然地表示该记录被删除之前的值。确切地哪些日志条目可以适当地作为用于找到适当值的候选因而可以取决于关于例如如何进行日志记载、在同步期间数据库如何行为以及更新窗口如何确定的实现方案细节。然而，原理是获得最佳地表示特定记录在当前或者先前同步开始时的时间点的状态的值。
在适当地建立了针对商店_产品的ORT实例之后，处理进行到步骤807，其中确定其接受。由于ORT实例对于RT实例是孩子，可通过相同方法确定其接受，并且处理对于ORT实例在步骤800重新开始。在步骤801中，可以确定针对商店_产品表304的第一ORT是产品表305。接着，在步骤803可以确定产品表305相对于商店_产品表304是父亲，因此不能够限制商店_产品表304。产品表305对项目总数表306是间接母亲，如以下将讨论的，因而能够限制表306，但是不能够限制商店_产品表304，并且处理直接进行到步骤804，其中针对商店_产品表304的下一个ORT。其将是商店表302，因此处理将进行通过步骤802到步骤803，其中将确定ORT商店302可以限制RT商店_产品304，并且处理进行到步骤805，其中建立针对在商店_产品实例中引用的商店条目ORT实例。该处理与以上描述的建立商店_产品实例的处理相同，并且假定在步骤805成功建立了商店实例，该处理进行到步骤807以确定所建立的商店实例的接受。
由于商店记录类型是母亲，所以可以再次使用相同处理，并且处理对于所建立的商店实例在步骤800重新开始。商店表302的唯一子集拥有者是商店拥有者表301。如以上说明的，商店拥有者表301不与任何接受方法直接或者间接关联，因此没有角色。因此不能够限制任何子集成员，并且在通过步骤801到步骤804一次之后，将在步骤802确定没找到附加ORT。处理接着进行到步骤810，其中确定存在针对商店表302定义的用户定义的接受方法。在步骤811中，确定取决于用户定义的接受方法的接受。在本具体示例中，用户定义的接受方法可以取决于可在参数保持器PDA表303中找到的参数。
如果接受被确定为否定(即，该具体商店条目不应存在于被同步的特定PDA)，则处理进行到步骤802，其中，将接受设定为假。当处理终止于步骤813时，处理用该结果返回针对商店_产品实例的步骤807。在步骤809，接着确定针对商店_产品实例的ORT实例不被接受，因而处理应进行到步骤808，其中，在处理在步骤813终止之前商店_产品实例的接受被设定为假。当该处理终止时，结果被报告回针对购买实例的步骤807。在步骤809可确定针对所检查的购买的ORT实例不被接受，从而处理应进行到步骤808，其中将接受设定为假。接着，处理在确定购买实例不被接受之后在步骤813终止。
相反地，如果在步骤811针对商店表定义的用户定义的接受方法的检查得到接受的肯定确定(即，该商店条目应存在于被同步的特定PDA上)，则处理进行到步骤812，其中将对所建立的商店实例的接受设定为真。当商店实例的处理终止时，结果被报告回步骤807中的商店_产品实例的处理。接着，在步骤809确定ORT实例被接受并且处理进行到步骤804，其中，确定不存在针对该记录类型(已经考虑的产品记录类型)的附加ORT。处理因此进行经过步骤802到步骤810，其中确定不存在针对商店产品表的用户定义的接受方法。处理接着进行到步骤812，其中，在处理在步骤813终止之前将接受设定为真。结果接着被报告回确定对于购买实例的接受的处理中的步骤807。该处理接着进行到步骤809，因而对于ORT实例接受为肯定，从步骤809到步骤804。在步骤804，没有附加ORT将被针对购买表308识别，因而处理将从步骤802进行到步骤810，其中将确定不存在针对购买表308的用户定义的接受方法。处理接着继续进行到步骤812，其中，在处理在步骤813终止之前将针对该购买实例的接受设定为真。
现在参照图9，其例示父亲记录类型的接受的确定。如已经提到的，父亲可被其儿子限制，即被不是拥有者记录类型但相对于父亲是子集记录类型的记录类型限制。除了图8的接受方法，可能因此需要确定记录类型实例是否被儿子限制。在以上列出的简化代码中，在以上列出的示例性代码中其作为称为OnRT_AcceptFather(实例)的方法示出。在图9例示了该方法。就类似于常规接受例程，该方法例如成对进行。
该方法开始于启动步骤900并且继续到步骤901，其中，确定是否针对被检查的记录类型或者RT已经声明了父亲事件。如果没有声明父亲事件，则将不识别儿子，在步骤902中，方法分支到步骤910，其中，在处理在步骤911终止之前将针对RT实例的接受设定为“真”。
如果在步骤902确定针对记录类型声明了父亲事件，则取得成员记录类型或者MRT的识别，并且在步骤903中检查第一成员记录类型(MemberRecordType)。在步骤904中，如果找到MRT，则处理进行到步骤905，其中，确定是否所检查的MRT是在步骤902识别的限制的儿子。如果不是，则处理在步骤906中检查下一个MRT。应注意的是：如果在步骤902中确定实际存在限制的儿子，则最终还应找到该记录类型。然而，由于父亲事件被用户声明，所以找到限制记录类型的方法应能够处理错误声明的父亲事件，该父亲事件返回不存在的记录类型的识别。如果是这种情况，则方法将最终在步骤904中确定没找到附加MRT，并且处理进行到步骤910，其中，在处理在步骤911终止之前将针对RT实例接受设定为“真”。
当在步骤905中确定经检查的MRT是RT的限制儿子时，处理进行到步骤907，其中，确定所识别的成员记录类型中的至少一个实例是否具有肯定接受。将在以下参照图10更详细描述该处理。
存在至少一个被接受的儿子意味着需要在客户机上存在父亲实例。如果在步骤908确定来自MRT表的至少一个被接受实例即一个被接受的儿子被找到，则处理进行到步骤910，其中，在处理在步骤911终止之前将针对RT实例的接受设定为“真”。否则，如果没有找到被接受的实例，则方法进行到步骤909，其中，在处理在步骤911终止之前将针对RT实例的接受设定为“假”。
现在参照图10，其中例示用于确定存在具有肯定接受的限制儿子的方法。方法开始于启动步骤1000，并且进行到步骤1001，其中，识别与RT实例匹配并且不具有任何日志条目的第一MRT实例。没有保证与RT实例匹配的全部MRT实例已经被载入日志。例如，MRT可以自从创建数据库以来被客户机接受，并且自此没有对记录进行任何改变，或者在去除比例如特定天数更老的日志条目的处理中日志可能已经被清除。可通过直接检查数据库找到这种实例，因为比已有日志更老的数据库条目必然在相关的时间窗口Δt期间存在而未改变。这意味着记载日志比时间窗口的起点老是充分的，从而即使从日志清除了比时间窗口的起点老的条目，或者即使在没有日志的情况下创建了数据库但是在同步时间窗口的起点之前打开了记载日志，该方法也能够操作。
如果在步骤1002中确定找到了没有日志条目的匹配的MRT实例，则处理进行到步骤1003，其中，确定针对MRT实例的接受。这可以使用与参照图8描述的方法相同的方法进行。如果在步骤1003中确定识别的实例在客户机被接受，则处理进行到步骤1008，其中，处理在步骤1009终止之前该方法返回“真”，指示找到被接受的MRT实例。否则，如果在步骤1003确定MRT实例不被接受，则方法返回步骤1001以找到匹配RT并且没有日志条目的下一个MRT实例。该处理继续直至在步骤1003中确定找到被接受的MRT实例为止，或者直至在步骤1002确定不可找到匹配所检查的记录类型的另外的成员记录类型实例为止(即，已经检查了全部的匹配MRT实例，并且都没有被接受)。在后一种情况下，处理进行到步骤1004。
在步骤1004中，从日志找到匹配RT的第一MRT实例。该日志被反向扫描，以在与图8中的步骤805进行的处理相类似的处理中从日志条目创建MRT实例。取决于是否RT实例是对中的第一或者最后一个，处理寻求建立在窗口Δt的起点或者终点处的适当的实例值。如上所述，比适当时间点更新的日志条目可能是相关的，例如DEL条目可以指示在比DEL条目的时间戳更早的时间点该值是什么。因此，可以从最后条目反向扫描日志直至找到最佳表示窗口的起点或者终点处的值的条目为止。
如果在步骤1004中确定在日志中找到匹配RT的MRT实例，则处理进行到步骤1006，其中，确定是否MRT实例被接受。如果在步骤1006中确定识别的实例在客户机处被接受，则处理进行到步骤1008，其中，处理在步骤1009终止之前该方法返回“真”，指示找到被接受的MRT实例。然而，如果在步骤1006中确定MRT实例不被接受，则方法返回步骤1004以从日志找到匹配RT的下一个MRT实例。该处理继续直至在步骤1006中确定找到被接受的MRT实例为止，或者直至在步骤1005中确定不可找到匹配被检查的记录类型的另外的成员记录类型实例为止(即，已经检查了可从日志导出的全部的匹配MRT实例，并且都没有被接受)。在后一种情况下，处理进行到步骤1007，其中，在处理在步骤1009终止之前方法返回“假”，指示没有找到被接受的MRT实例。
返回参考图3，给出图9和图10的处理的短的示例。图9的处理旨在确定来自产品表305的对的给定实例是否由正被同步的客户机接受。例如，该对可以包括PRODUCT01(产品01)。在步骤901中确定确实针对产品表305声明了父亲事件。在步骤902中，获得限制产品表305的成员记录类型的识别，并且该识别将识别商店_产品表304。在步骤903中，检查第一MRT，其可以是项目总数表306。因此，在步骤904中确定找到了MRT，但是在步骤905中将确定不是在步骤902中识别的限制表。因此，处理进行到步骤906，其中检查下一个MRT。其将是商店_产品表305，处理因此从步骤906进行到步骤904，并且继续到步骤905，其中，可建立被检查的MRT是被识别为限制表(儿子对父亲RT)的MRT。处理因此进行到步骤907以确定限制表即MRT商店_产品表304是否包括引用在来自当前检查的表的对的实例中识别的产品表305的条目，并且在客户机处被接受的任何条目。例如，商店_产品表304中是否存在引用产品表305中的PRODUCT01并且对于适当的时间点在客户机处被接受的条目。
参照图10描述的处理可用于回答此问题。在步骤1001、1002和1003中，商店_产品表304中的引用PRODUCT01并且不具有日志条目的条目被检查。当这种条目被找到并且确定具有肯定接受时，方法就向图9的步骤907返回值“真”，并且图9例示的方法进行到步骤908，其中，确定找到了被接受的MRT实例，并且该方法应进行到步骤910，其中，对PRODUCT01的实例的接受应在客户机处被接受。
如果在步骤1001、1002和1003中不可找到匹配PRODUCT01的MRT实例，则处理进行到步骤1004、1005和1006，以确定是否可从日志找到匹配PRODUCT01的被接受的MRT实例。如果是，则方法再次向步骤907返回值“真”，其中，方法再次进行到步骤908和步骤910，其中，对PRODUCT01的实例的接受应被在客户机处接受。
如果不能找到引用PRODUCT01的被接受的商店_产品实例，则图10的方法在于步骤1009终止之前进行到步骤1007。值“假”被返回到图9的步骤907，指示商店_产品表304中没有条目引用PRODUCT01并且在正被同步的客户机处被接受。这意味着PRODUCT01在客户机上不被需要，因为没有与客户机相关联的商店携带(carry)PRODUCT01。图9的处理在步骤908确定以确定没有找到相关的MRT实例，并且进行到步骤909，其中，在方法在步骤911终止之前将对PRODUCT01的接受设定为“假”。
现在将更详细描述图6的步骤606表示的基于角色的触发的处理。如上所述，称为CollectRecords(收集记录)的第一个方法收集数据库中在被考虑的Δti期间改变了的全部记录，并且产生数据库Δ。该处理对应于图5的步骤502。所收集的记录可以被作为对登记为触发者的列表，包括两个记录实例，一个包括位于Δti的起点处的时间ti-1的记录的值，且另一个包括时间ti之前的记录的值，对应于图5中的步骤503。称为BrowseExternalAcceptanceChange的第二方法浏览数据库以识别Δti期间未改变任何值但是由于外部变量而改变其接受的记录，如参照图5中的步骤504的所描述的。识别的记录作为对被添加到步骤505中的触发者的列表中。然后，这两种方法创建的列表可以用作对图5中的步骤506表示并且在图6中更详细描述的触发处理的输入。触发处理识别附加记录，并且按照此方式识别的记录在图6中的步骤603和606被作为对添加到触发者的列表。然后，利用CollectRecords方法和BrowseExternalAcceptanceChange方法按照与这些对被添加到列表的方式相同的方式检查这些被触发的对，直至检查了列表中的全部对为止。因而，触发者的列表和被触发的对被遍历直至检查了列表中的全部对为止。
应理解的是列表中表示的对原则上可以具有任意种类的角色，无论是否被作为收集处理、浏览处理的结果添加，或者是否被已经添加到列表的对触发。因此，为了确定它们应触发哪些附加对在图6的步骤606中被检查的全部对可以根据相同过程检查，无论它们被如何添加到列表。
应注意的是：因为针对被触发的记录重复触发处理，仅需要触发触发对的最接近的亲戚，而不是该对的整个子集约束层级。例如，如果母亲触发孩子，则不也需要触发该孩子的孩子，因为它们接着将被第一个孩子触发。然而，与本发明的原理一致的是定义在被触发的对的子树中进一步向下触发的其它触发方案。
将从图3的描述中回忆的是可以定义6个不同角色。在此角色称为母亲、孩子、儿子、父亲、姐妹和兄弟。然而，记录类型不需要仅具有一个角色。通过记录类型如何涉及另一个记录类型定义角色，由于记录类型可以涉及若干其它记录类型，可以具有若干的角色。当表示特定记录类型的实例的对用作触发者时，可能需要检查该记录类型的全部角色。
下面的情况可以被识别：
i)记录类型是母亲
ii)记录类型是孩子
iii)记录类型是母亲和孩子
iv)记录类型是母亲、孩子和儿子
v)记录类型是母亲、孩子、儿子和兄弟
vi)记录类型是孩子和儿子
vii)记录类型是孩子、儿子和兄弟
viii)记录类型是父亲
ix)记录类型是姐妹
另外，存在没有角色的记录类型。不具有角色的对将不触发任何东西。在图3的示例中，商店拥有者301不具有角色。
根据情况i)记录类型是母亲。这意味着记录仅涉及作为该记录类型的孩子的其它记录类型。在图3的示例中，商店记录类型302是这种记录，并且具有两个孩子，PDA记录类型303和商店_产品记录类型304。母亲的孩子是用于触发的候选，或者更精确地，包括引用被考虑的特定商店的外键的这两个记录类型的任何实例对应被添加到触发者的列表中。不需要触发任何附加的记录类型。如果任何这种记录类型应被添加到触发者的列表中，则当被触发的孩子被检查时这将适时地进行。在此情况下，当商店产品被检查时，任何产品、购买、出售或者项目总数对将被触发。可通过称为AddChildren(添加孩子)的方法处理该触发。
根据情况ii)记录是孩子。除了参数保持器，孩子记录类型不必触发它们作为其孩子的记录类型。可通过孩子记录类型保持关于它作为其孩子的记录类型的一些附加信息这个事实来实现，并且该附加信息不使父母记录类型相关。并且当考虑参数保持器时，在图6的步骤603中它们触发它们的母亲。根据此处描述的本发明的实施例，基于角色的触发是单独步骤606，因此在作为该母亲的孩子的能力下参数保持器不触发母亲。
在图3中存在4个具有孩子角色的记录类型示例：PDA记录类型303、商店_产品记录类型304、销售记录类型307和购买记录类型308。孩子记录类型仅触发它们的孩子，且因为记录类型PDA303、销售307和购买308不具有孩子，在该具体示例中它们不触发任何附加对。然而，商店产品记录类型304触发，但是由于该记录类型也是儿子和兄弟，其将在以下讨论。基于具有孩子角色的记录类型的对的触发可再次被AddChildren方法处理。
根据情况iii)记录类型是母亲(即，具有与其相关联的过滤器)，而且自身也是一些其它记录类型的孩子。在图3中没有具有这两个角色的记录类型。如上所述，对不触发它们的母亲。例如考虑不被特定商店存货的作者的书目存在改变的情况。如果保持商店的库存的客户机被同步，则书目的改变不需要触发表示该作者的作者记录类型的对。然而，作为母亲和作为孩子两者被考虑的记录类型将需要触发其自己的孩子，因为它们可以保持满足所有子集约束需要的信息。再次，可以使用AddChildren方法来处理触发。
根据情况iv)被考虑的对的记录类型不仅是母亲和孩子，而且还是儿子。再次，图3中没有任何这种组合的示例。如上所述，可使用AddChildren方法来添加被考虑的对的孩子。然而，由于记录类型还是儿子，可能需要添加其父亲。这可以通过称为AddFather(添加父亲)的方法进行，并且将在以下更详细地描述。
根据情况v)被考虑的对是作为母亲、孩子、儿子并且还是兄弟的记录类型。前三个角色具有如如上相同效果，并且兄弟的角色可以使得需要添加兄弟的姐妹。这可以通过方法AddSisterOfBrother(添加兄弟的姐妹)进行，并且将在以下更详细地描述。
根据情况vi)该对具有作为孩子和儿子的记录类型，并且可能需要添加其孩子以及其父亲。
根据情况vii)该对的记录类型是具有孩子、儿子和兄弟的角色。图3中的记录类型商店_产品304是这种角色的组合的示例。记录类型是商店记录类型302的孩子并且是产品记录类型305的儿子。另外是记录类型项目总数306的兄弟。当包括对父亲的引用时，记录类型是儿子。儿子角色用于限制父亲角色。在此情况下，用于确保仅来自实际被给定商店302库存的表305的产品被导入到保持该商店的库存的客户机PDA。另外，记录类型对304是项目总数记录类型306的兄弟。项目总数记录类型306是父亲记录类型产品305的是非限制性子集成员。这意味着兄弟记录类型中的改变影响姐妹记录类型。例子可以是将来自产品表305的新产品添加到商店表302中的商店的库存的商店_产品的改变将影响项目总数表306，影响在于：在该商店中新添加的产品(或项目)的销售应该被作为新记录添加到项目总数表306，相反地，为了使给定产品的总销量在客户机上可得，不需要仅添加来自父亲表305的产品，而且来自姐妹表306的产品的总数。可通过称为AddSisterOfBrother的方法处理。
总而言之，对于例示组合孩子、儿子和兄弟的角色的记录类型的对，需要添加相关的孩子，诸如记录类型销售307和购买308的那些，相关父亲，如由产品记录类型305示例的，以及姐妹，如由项目总数记录类型306示例的。可通过称为AddChildren、AddFather、和AddSisterOfBrother的方法处理。
下面转到情况viii)其中记录类型只具有父亲角色，附加考虑变得需要。可能需要添加姐妹，但是仅如果表示父亲的对是UPD。通过考虑图3的示例将得到理解，其中父亲记录类型305表示产品，而姐妹记录类型306表示该产品的总数。将理解的是如果表示父亲的对是新产品(INS)，则仅如果该产品也被添加到考虑的特定商店，才应触发姐妹，在该情况下将通过添加将商店302与产品305(即其兄弟)相关联的新的商店_产品304来触发。类似地，如果产品被从父亲去除(DEL)，则也需要从商店产品去除，否则将存在引用不存在的产品的商店_产品。再次，姐妹可以被商店_产品表304中的兄弟触发。然而，如果父亲表中的改变是不在兄弟表中反映的UPD，则相关联的姐妹对可能需要由父亲对触发。
应注意的是：对于父亲，姐妹是子集成员，类似于孩子，但是角色仍称为姐妹因为对该姐妹总存在兄弟。
最终情况ix)是触发对是姐妹的情况。姐妹可以被其它记录类型引用，该其它记录类型可以被认为是姐妹的孩子，但是因为姐妹的孩子仅通过其关系与父亲相关，姐妹的孩子也将被分类为姐妹，因而可以按照相同的触发方法处理。
以上参照图3讨论的示例仅包括具有声明的接受方法的一个表(即商店表302)。如果确定一些表在客户机中不需要，例如销售表307和购买表308在用于库存的客户机中不需要，则可针对这些表声明附加的接受方法，以确保不被触发和传递到该客户机。
以上讨论说明依据触发者的一个或多个角色触发哪些角色。保留确定表中的哪些条目应被作为对添加到触发者的列表。下面将对基于所确定的触发对的一个或多个角色处理将对添加到触发者的列表的方法进行描述。
每当对被触发并且添加到触发者的列表，被触发的对的两个实例应该接收它们的适当值。如以上描述的，当在确定接受期间创建ORT实例时，何时创建实例存在两个可能性。第一个可能性是从日志获取适当值。假定针对记录类型条目的日志条目实际存在，可能能够获取与时间戳相关联的值，并且可以创建针对同步窗口Δt的对应于适当时间戳的实例。如果不能找到日志条目，则可从数据库自身获取适当值，假定由于不存在日志条目，自从时间窗口的起点之前该值应该保留不改变。可针对以下讨论的全部触发方法进行填充对的实例的方法，并且在每个单独方法的讨论期间将不重复。还应注意的是为了避免在客户机上重复记录，在触发者的列表中对不应被输入超过一次。通过在以下描述的每个方法中包括检查，使得如果该对已经存在于列表中各方法都不在列表中输入对，可进行避免。另选地，列表可被扫描并且在触发处理完成之后去除重复。
首先，再次参照图6，如果在步骤602中确定触发对是参数保持器，则在步骤603使用称为AddMaterFamilias(对)的方法触发对应的母亲。该方法通过验证触发对的记录类型实际是参数保持器来开始。如果不是，则方法存在，因为没有更多的事情。如果是，则应该识别适当的拥有者记录类型。根据图3的示例，触发参数保持器将是来自PDA表303的对并且ORT将是商店表302。
应注意的是：参数保持器可以不同于其它对触发。首先，总体上引用其它记录类型的记录类型可能不具有空(零)值，因为这将违反子集约束。例如，表304中的商店_产品条目表示能够在特定商店中找到的特定产品，因此在商店表302中总应称为商店并且在产品表305中称为产品。类似地，购买表308中的条目表示实际在商店中购买产品，并且应因此在商店_产品表304中总应称为商店_产品条目。不应存在没有与商店和产品的关联性的购买条目。然而可以针对当前不被分配到任何特定商店的特定PDA存在参数保持器条目，具有当前为零值的外键引用。
另一个差异是参数值的改变可以实际触发两个母亲。例如，如果图3的示例中的PDA首先分配给一个商店并且这改变到不同的PDA，则将需要触发两个商店两者，因为应从PDA去除原始商店同时将新商店添加到PDA。
因此，该方法可以解决触发对中的两个实例之间子集链路值如何改变的问题。针对用对中的子集链路识别的每一个ORT条目，对可以被创建并且在触发者的列表中输入。存在以下的可能性。如果在Δt之前没有连接值(例如针对外键引用的零值)并且在Δt内没有这种值，即，对中两个实例都不实际引用ORT中的条目，则方法退出并且不向触发者的列表添加对。如果在Δt之前存在连接值，但是在Δt内没有这种值，则这意味着触发对的第一实例引用ORT条目(例如，商店表302中的商店)，但是第二实例不引用任何条目。表示被第一实例引用的ORT条目的对应该接着作为UPD输入到触发者的列表中。然而，由于识别的ORT条目不被触发对中的最后实例引用，所以该对将最可能在图5的步骤507和图7的步骤715期间改变为DEL。在本发明的替代实施方式中，这可以在触发期间验证并且该对可以直接作为DEL输入。
如果触发对在Δt之前没有连接子集值，但是在Δt期间具有连接值，则表示被连接值识别的ORT条目的对应添加到触发者的列表中。再一次，该对可作为UPD添加并且在图7的处理期间，在步骤718中改变为1NS。
最终，触发对可以包括引用一个ORT条目的第一实例和引用不同ORT条目的最后实例，就图3的示例而言，表示从一个商店到另一个商店的改变。在此情况下，可能必须将一个对添加到触发者的列表，表示被该触发对的第一实例的连接子集值引用的ORT条目的两个实例，并且第二个对可以被针对被触发对的最后实例的连接子集链路引用的ORT条目添加。两者都可以作为UPD添加到触发者的列表，并且在根据参照图7描述的方法的过滤和调整期间，第一对可以被改变为DEL，并且第二对可以被改变为INS。
当图6的处理进行到步骤606时进行其余触发方法。在此步骤中，依据触发记录的角色可以进行一个或者更多个方法。这些方法中要描述的第一个将被称为AddChildren(对)。如果触发对的记录类型具有母亲和孩子中的至之一，则进行该方法。仅如果在图6的步骤604中确定触发对应更新客户机并且在步骤605中确定该对具有接受改变，则执行该方法。在本发明的一些实施例中，进行这些确定的方法可以从AddChildren(对)内调用，在替代实施例中。在进行步骤607的触发方法之前执行步骤604和605。
该方法继续以检查触发记录类型的全部子集成员记录类型。子集成员记录类型将称为成员记录类型或者MRT。识别了相对于称为RT的触发对的记录类型为孩子的每个MRT。如果RT是母亲或者孩子，则MRT是孩子。如果针对RT存在用户定义的接受方法，则RT是母亲。如果是在母亲的子树中，则RT是孩子。
针对作为RT的孩子的每个MRT，扫描日志以识别引用RT条目的条目，即触发对。扫描处理类似于以上在确定接受期间当讨论创建ORT或者MRT实例时描述的处理。可以从日志的末端开始进行扫描，将针对引用该触发对的MRT表中的全部条目考虑在内。可在窗口Δt之后、之内或者之前发现适当的候选。针对发现的每个适当的日志条目，用日志中发现的适当值填充该对并且将该对添加到触发者的列表中，除非对应的对没有添加到触发者的列表中。该方法创建可从来自被确定为触发对的孩子的每个MRT的日志建立的全部对。
应意识到：触发对的孩子可以存在而不具有任何日志条目。因此需要在数据库中找到确实引用被触发对举例的记录并且不具有任何日志条目的条目。任何这种数据库条目作为具有直接从数据库取得的值的对被添加到触发者的列表，除非对应的对已经在触发者的列表中。针对全部MRT表重复，直至找到全部孩子并且将它们添加到触发者的列表中。
如果触发对被确定具有儿子的角色，则进行称为AddFather(对)的触发方法。再次，在此方法之前或作为此方法的一部分，可以进行参照604和605描述的步骤。如果确定触发者是INS或者DEL，或者如果是具有接受改变的UPD，则父亲应该被触发。通过检查儿子RT的全部ORT来触发父亲。如果针对该记录类型存在父亲事件，并且记录类型不是母亲，则记录类型是父亲。换句话说，对具有声明的父亲事件但是不具有声明的母亲事件的触发RT的全部ORT是父亲。对于被发现是父亲的全部子集拥有者，针对被儿子引用的每个条目创建对。每个所创建的对可以包括从日志填充(或者如果不存在日志条目则从数据库)的实例。在儿子已经更新从而引用的父亲从一个条目改变到另一个条目的情况下，可能需要触发被引用的父亲两者。
总体而言，如果在Δt中儿子被删除，则父亲应该在Δt起点之前存在，并且如果在Δt中儿子被插入，则父亲应该在Δt终点处存在。然而，由于父亲出现(occurrence)可以在客户机上存在表示很多儿子，当确定限制儿子被从服务器数据库删除并且服务器侧上的处理指示儿子以及其父亲应被从客户机删除时从客户机数据库删除父亲不总是适当的。原因是在先前同步期间，不同的儿子，例如与相对于父亲具有儿子角色的表不同的表行可能已经添加到客户机数据库，并且该其它儿子可能保留在客户机数据库中，因而要求客户机上存在父亲。这种儿子的存在从用于进行服务器侧的同步的信息不能容易地得到。代替地，可以通过以下来处理：向客户机传递针对父亲对的DEL指令，然后对客户机进行检查以确定是否可进行DEL，或者是否客户机上存在其它儿子要求客户机上连续存在父亲。类似地，当新儿子的插入触发父亲的插入并且服务器侧上的处理指示触发儿子和被触发的父亲两者应被传递到客户机时，作为客户机的先前同步的结果该父亲可以在客户机上存在。这也可以在客户机侧处理。根据本发明的一个实施例，对客户机的全部其它更新在更新父亲之前进行，并且更新父亲使得不必要的父亲被删除并且没有父亲被插入两次。
如果触发记录类型是兄弟，则可能需要触发姐妹。这种情况的示例在图3中找到，其中项目总数表306是商店_产品表304的姐妹。姐妹的触发可以通过称为AddSisterOfBrother(对)的方法执行。该方法按照上述AddFather方法(兄弟具有儿子对父亲的角色)相同方式寻找兄弟的父亲。该方法接着找到在父亲以下的子树中的作为姐妹的全部记录类型。因此，使用以上概括的方法，识别父亲以下的子树中的全部姐妹，并且针对从父亲开始的每个记录类型，进行类似于AddChildren的触发处理。这意味着：对于从日志或者从数据库取得的、来自该子树中的全部记录类型的所引用的被检验和相关条目作为对在触发者的列表中输入。
最终，如果触发对是父亲或者姐妹，则可以进行称为AddSister(对)的方法。AddSister(对)类似于方法AddSisterOfBrother(对)，除了不需识别间接母亲之外。代替地，针对每个姐妹(即，触发对的RT的每个MRT)引用该触发对的全部适当条目被识别，并且，以在类似于针对AddChildren(对)描述的处理中在日志或者数据库中找到的适当值，将对添加在触发者的列表中。
再次返回图5，在根据上述方法完成全部触发之后，处理进行到确定过滤和调整，如在步骤507中已经描述的并且进行实际同步。
当已经根据参照图7描述的方法处理了对时，为了确定是否应更新客户机，并且如果是，其适当更新状态是什么(是更新、插入还是删除)，可创建包括记录的全部值的XML消息并且发送到客户机，在该客户机接收并且按照可用于导入数据到客户机数据库的方法作用。根据一些实施例，服务器可以使用非同步SOAP调用。(SOAP1.2定义在来自W3C的推荐中，在此通过引用整体并入)。然而，其它通信协议和消息格式在本发明的范围内
如以上参照触发处理提到，能够逐个记录地、通过一次处理一批记录，或者通过进行全部记录来进行触发和更新。因此，发送到客户机的同步消息可以仅包括应插入、删除或者更新的一个记录、一批记录或者全部记录。

Claims (24)

1.一种在服务器计算机上用于从所述服务器计算机更新电子客户机装置时确保数据完整性被保持的方法，所述服务器计算机包含具有多个数据库记录和由所述服务器计算机执行的数据库操作的日志的第一数据库，且所述电子客户机装置包含所述第一数据库的、包括在所述客户机装置处被接受的数据库记录的部分表示，所述方法包括：
扫描所述数据库操作的日志以识别所述客户机装置的先前更新之后插入到所述第一数据库、从所述第一数据库删除或者在所述第一数据库中改变的或者其在所述客户机装置处的接受被所声明的接受规则改变的第一记录；
识别在所述先前更新之后未添加到所述第一数据库、未从所述第一数据库删除或者在所述第一数据库中未改变的并且其在所述客户机装置处的接受未被任何所声明的接受规则改变的第二记录，所述第二记录通过外键约束而相关于所述第一记录，所述外键约束要求在所述第一记录和所述第二记录中的一个记录中的键引用在所述第一记录和所述第二记录中的另一个记录中的键；
将第一数据从所述服务器计算机发送至所述客户机装置，所述第一数据表示以下指令：所述客户机装置在所述第一数据库的所述部分表示中执行相关联的所述第一记录的插入、所述第一记录的删除或者所述第一记录的改变，或者如果所述记录的接受已经改变，则在所述记录当前被接受的情形下执行至所述第一数据库的所述部分表示中的插入，并且在所述记录不再被接受的情形下执行从所述第一数据库的所述部分表示中的删除；以及
将第二数据从所述服务器计算机发送至所述客户机装置，所述第二数据表示以下指令：所述客户机装置将所述第二记录插入到所述第一数据库的所述部分表示中或者从所述第一数据库的所述部分表示中删除所述第二记录，使得在所述第一数据库的所述部分表示中满足所述外键约束。
2.根据权利要求1所述的方法，其中扫描所述数据库操作的日志包括：
确定时间窗口的起点和终点，所述起点表示与所述客户机装置的所述先前更新相关联的时间点，所述终点表示与所述客户机装置的当前更新相关联的时间点；以及
扫描由所述服务器计算机执行的数据库操作的所述日志以识别所述第一记录作为在所述时间窗口期间已执行至少一个数据库操作的记录。
3.根据权利要求2所述的方法，还包括：
在向所述客户机装置发送所述第一数据之前，进行下面操作的至少之一：
－扫描所述日志以确定表示所述第一记录在所述时间窗口的起点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中是否被接受：
――表示所述第一记录在所述时间窗口的起点处的状态的所述值，
――针对所述第一记录所属的记录类型的所声明规则，以及
――针对不同于所述第一记录、但是通过外键约束与所述第一记录相关联的记录的相应确定；以及
－扫描所述日志以确定表示所述第一记录在所述时间窗口的终点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受：
――表示所述第一记录在所述时间窗口的终点处的状态的所述值，
――针对所述第一记录所属的记录类型的所声明规则，以及
――针对不同于所述第一记录、但是通过外键约束与所述第一记录相关联的记录的相应确定；
如果所述数据库操作表示将所述第一记录插入到所述第一数据库，则如果确定表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则配置所述第一数据以表示插入所述第一记录的指令，
如果所述数据库操作表示从所述第一数据库删除所述第一记录，则如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，则配置所述第一数据以表示删除所述第一记录的指令，以及
如果所述数据库操作表示所述第一记录在所述第一数据库中的改变，则配置所述第一数据以表示用于下述操作的指令：
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则改变所述第一记录，
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值不应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则删除所述第一记录，或者
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中不被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则插入所述第一记录。
4.根据权利要求2所述的方法，还包括：
在向所述客户机装置发送所述第二数据之前：
－扫描所述日志以确定表示所述第二记录在所述时间窗口的起点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受：
――表示所述第二记录在所述时间窗口的起点处的状态的所述值，
――针对所述第二记录所属的记录类型的所声明规则，以及
――针对不同于所述第二记录、但是通过外键约束与所述第二记录相关联的记录的相应确定；
－扫描所述日志以确定表示所述第二记录在所述时间窗口的终点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受：
――表示所述第二记录在所述时间窗口的终点处的状态的所述值，
――针对所述第二记录所属的记录类型的所声明规则，以及
――针对不同于所述第二记录、但是通过外键约束与所述第二记录相关联的记录的相应确定；
配置所述第二数据以表示用于下述操作的指令：
－如果确定表示所述第二记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第二记录在所述时间窗口的终点处的状态的所述值不应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则删除所述第二记录，或者
－如果确定表示所述第二记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中不被接受，并且表示所述第二记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则插入所述第二记录。
5.根据权利要求3或4所述的方法，其中通过针对不同记录重复扫描日志以确定表示值和确定在所述客户机上对所述值的接受的步骤，执行针对所述不同记录的所述相应确定。
6.根据权利要求3或4所述的方法，其中针对记录类型的至少一个所声明规则是接受表示输入的记录类型的记录的状态的值，并且产生针对在所述客户机上对所述值的接受的相应确定的函数。
7.根据权利要求3或4所述的方法，其中至少一个所声明规则由数据库的程序员或者用户声明。
8.根据权利要求1所述的方法，还包括：
识别未添加到所述第一数据库、从所述第一数据库删除或者在所述第一数据库中改变但是通过外键约束而相关于所述第二记录的第三记录；
向所述客户机装置发送第三数据，所述第三数据命令所述装置将所述第三记录插入到所述第一数据库的所述部分表示中或者从所述第一数据库的所述部分表示中删除所述第三记录，使得在所述第一数据库的所述部分表示中满足所述外键约束；以及
重复识别记录和发送数据的步骤直至已在所述第一数据库所述部分表示中满足全部外键约束。
9.根据权利要求1所述的方法，其中所述第一记录的记录类型与用于确定表示该记录类型的记录状态的值在客户机上的接受的所声明规则相关联，并且所述第二记录的记录类型是关于所述第一记录类型的子集成员记录类型。
10.根据权利要求1所述的方法，其中所述第一记录的记录类型与用于确定表示该记录类型的记录的状态的值在客户机上的接受的所声明规则相关联的记录类型的子集成员记录类型，并且所述第二记录的记录类型关于所述第一记录类型的子集成员记录类型。
11.根据权利要求1所述的方法，其中所述第一记录的记录类型是所述第二记录的记录类型的子集成员，和不同于所述第一记录的记录类型和所述第二记录的记录类型的记录类型的子集成员；
具有不同于所述第一记录和所述第二记录的记录类型的所述记录与用于确定表示所述记录类型的记录的状态的值在客户机上的接受的所声明规则相关联；以及
如果要求满足将其相关到具有第一记录的记录类型的至少一个记录的外键约束，则所述第二记录具有与所声明规则相关联的记录类型，所述规则声称该记录类型的记录应仅在所述第一数据库的所述部分表示中被接受。
12.根据权利要求1所述的方法，其中如果要求满足将其相关到不同于所述第一记录和所述第二记录的记录类型的至少一个记录的外键约束，则所述第一记录具有与所声明规则相关联的记录类型，所述规则声称所述第一记录类型的记录应仅在所述第一数据库的所述部分表示中被接受，以及所述第二记录的记录类型是关于所述第一记录类型的子集成员记录类型。
13.一种用于从服务器计算机更新电子客户机装置时确保数据完整性被保持的服务器的更新装置，所述服务器计算机包含具有多个数据库记录和由所述服务器计算机执行的数据库操作的日志的第一数据库，且所述电子客户机装置包含所述第一数据库的、包括在所述客户机装置处被接受的数据库记录的部分表示，所述更新装置包括：
扫描模块，用于扫描所述数据库操作的日志以识别所述客户机装置的先前更新之后插入到所述第一数据库、从所述第一数据库删除或者在所述第一数据库中改变的或者其在所述客户机装置处的接受被所声明的接受规则改变的第一记录；
识别模块，用于识别在所述先前更新之后未添加到所述第一数据库、未从所述第一数据库删除或者在所述第一数据库中未改变的并且其在所述客户机装置处的接受未被任何所声明的接受规则改变的第二记录，所述第二记录通过外键约束而相关于所述第一记录，所述外键约束要求在所述第一记录和所述第二记录中的一个记录中的键引用在所述第一记录和所述第二记录中的另一个记录中的键；
用于将第一数据从所述服务器计算机发送至所述客户机装置的模块，所述第一数据表示以下指令：所述客户机装置在所述第一数据库的所述部分表示中执行相关联的所述第一记录的插入、所述第一记录的删除或者所述第一记录的改变，或者如果所述记录的接受已经改变，则在所述记录当前被接受的情形下执行至所述第一数据库的所述部分表示中的插入，并且在所述记录不再被接受的情形下执行从所述第一数据库的所述部分表示中的删除；以及
用于将第二数据从所述服务器计算机发送至所述客户机装置的模块，所述第二数据表示以下指令：所述客户机装置将所述第二记录插入到所述第一数据库的所述部分表示中或者从所述第一数据库的所述部分表示中删除所述第二记录，使得在所述第一数据库的所述部分表示中满足所述外键约束。
14.根据权利要求13所述的更新装置，其中所述扫描模块通过以下来扫描所述数据库操作的日志：
确定时间窗口的起点和终点，所述起点表示与所述客户机装置的所述先前更新相关联的时间点，所述终点表示与所述客户机装置的当前更新相关联的时间点；以及
扫描由所述服务器计算机执行的数据库操作的所述日志，以识别所述第一记录作为在所述时间窗口期间已执行至少一个数据库操作的记录。
15.根据权利要求14所述的更新装置，还包括：
用于在使服务器向所述客户机装置发送所述第一数据之前进行下面操作的至少之一的模块：
－扫描所述日志以确定表示所述第一记录在所述时间窗口的起点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中是否被接受：
――表示所述第一记录在所述时间窗口的起点处的状态的所述值，
――针对所述第一记录所属的记录类型的所声明规则，以及
――针对不同于所述第一记录、但是通过外键约束与所述第一记录相关联的记录的相应确定；以及
－扫描所述日志以确定表示所述第一记录在所述时间窗口的终点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受：
――表示所述第一记录在所述时间窗口的终点处的状态的所述值，
――针对所述第一记录所属的记录类型的所声明规则，以及
――针对不同于所述第一记录、但是通过外键约束与所述第一记录相关联的记录的相应确定；以及
配置模块，用于：
如果所述数据库操作表示将所述第一记录插入到所述第一数据库，则如果确定表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则配置所述第一数据以表示插入所述第一记录的指令，
如果所述数据库操作表示从所述第一数据库删除所述第一记录，则如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，则配置所述第一数据以表示删除所述第一记录的指令，以及
如果所述数据库操作表示所述第一记录在所述第一数据库中的改变，则配置所述第一数据以表示用于下述操作的指令：
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则改变所述第一记录，
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值不应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则删除所述第一记录，或者
－如果确定表示所述第一记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中不被接受，并且表示所述第一记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则插入所述第一记录。
16.根据权利要求14所述的更新装置，还包括：
用于在使所述服务器向所述客户机装置发送所述第二数据之前执行下述操作的模块：
－扫描所述日志以确定表示所述第二记录在所述时间窗口的起点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受：
――表示所述第二记录在所述时间窗口的起点处的状态的所述值，
――针对所述第二记录所属的记录类型的所声明规则，以及
――针对不同于所述第二记录、但是通过外键约束与所述第二记录相关联的记录的相应确定；
－扫描所述日志以确定表示所述第二记录在所述时间窗口的终点处的状态的至少一个值，并且根据下面因素的至少之一确定所述值是否应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受：
――表示所述第二记录在所述时间窗口的终点处的状态的所述值，
――针对所述第二记录所属的记录类型的所声明规则，以及
――针对不同于所述第二记录、但是通过外键约束与所述第二记录相关联的记录的相应确定；
用于配置所述第二数据以表示用于下述操作的指令的模块：
－如果确定表示所述第二记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中被接受，并且表示所述第二记录在所述时间窗口的终点处的状态的所述值不应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则删除所述第二记录，或者
－如果确定表示所述第二记录在所述时间窗口的起点处的状态的所述值在所述时间窗口的起点处在所述第一数据库的所述部分表示中不被接受，并且表示所述第二记录在所述时间窗口的终点处的状态的所述值应该在所述时间窗口的终点处在所述第一数据库的所述部分表示中被接受，则插入所述第二记录。
17.根据权利要求15或16所述的更新装置，其中通过针对不同记录重复扫描日志以确定表示值和确定在所述客户机上对所述值的接受的操作，执行针对所述不同记录的所述相应确定。
18.根据权利要求15或16所述的更新装置，其中针对记录类型的至少一个所声明规则是接受表示输入的记录类型的记录的状态的值，并且产生针对在所述客户机上对所述值的接受的相应确定的函数。
19.根据权利要求15或16所述的更新装置，其中至少一个所声明规则由数据库的程序员或者用户声明。
20.根据权利要求13所述的更新装置，还包括：
用于识别未添加到所述第一数据库、从所述第一数据库删除或者在所述第一数据库中改变但是通过外键约束而相关于所述第二记录的第三记录的模块；
用于使所述服务器向所述客户机装置发送第三数据的模块，所述第三数据命令所述装置将所述第三记录插入到所述第一数据库的所述部分表示中或者从所述第一数据库的所述部分表示中删除所述第三记录，使得在所述第一数据库的所述部分表示中满足所述外键约束；以及
用于重复所述识别记录和使所述服务器发送数据直至已在所述第一数据库的所述部分表示中满足全部外键约束的模块。
21.根据权利要求13所述的更新装置，其中所述第一记录的记录类型与用于确定表示该记录类型的记录状态的值在客户机上的接受的所声明规则相关联，并且所述第二记录的记录类型是关于所述第一记录类型的子集成员记录类型。
22.根据权利要求13所述的更新装置，其中所述第一记录的记录类型是与用于确定表示该记录类型的记录的状态的值在客户机上的接受的所声明规则相关联的记录类型的子集成员记录类型，并且所述第二记录的记录类型是关于所述第一记录类型的子集成员记录类型。
23.根据权利要求13所述的更新装置，其中所述第一记录的记录类型是所述第二记录的记录类型的子集成员，和不同于所述第一记录的记录类型和所述第二记录的记录类型的记录类型的子集成员；
具有不同于所述第一记录和所述第二记录的记录类型的所述记录与用于确定表示所述记录类型的记录的状态的值在客户机上的接受的所声明规则相关联；以及
如果要求满足将其相关到具有第一记录的记录类型的至少一个记录的外键约束，则所述第二记录具有与所声明规则相关联的记录类型，所述规则声称该记录类型的记录应仅在所述第一数据库的所述部分表示中被接受。
24.根据权利要求13所述的更新装置，其中如果要求满足将其相关到不同于所述第一记录和所述第二记录的记录类型的至少一个记录的外键约束，则所述第一记录具有与所声明规则相关联的记录类型，所述规则声称所述第一记录类型的记录应仅在所述第一数据库的所述部分表示中被接受，以及所述第二记录的记录类型是关于所述第一记录类型的子集成员记录类型。
CN201080038075.9A 2009-07-09 2010-07-02 用于执行部分数据库的增量更新的方法、系统和装置 Expired - Fee Related CN102483759B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/500,370 2009-07-09
US12/500,370 US8918380B2 (en) 2009-07-09 2009-07-09 Methods, systems and devices for performing incremental updates of partial databases
PCT/NO2010/000260 WO2011005106A1 (en) 2009-07-09 2010-07-02 Methods, systems and devices for performing incremental updates of partial databases

Publications (2)

Publication Number Publication Date
CN102483759A CN102483759A (zh) 2012-05-30
CN102483759B true CN102483759B (zh) 2015-12-09

Family

ID=42762577

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201080038075.9A Expired - Fee Related CN102483759B (zh) 2009-07-09 2010-07-02 用于执行部分数据库的增量更新的方法、系统和装置

Country Status (9)

Country Link
US (1) US8918380B2 (zh)
EP (1) EP2452277B1 (zh)
JP (1) JP5676598B2 (zh)
KR (1) KR101675409B1 (zh)
CN (1) CN102483759B (zh)
CA (1) CA2767533C (zh)
HU (1) HUE039928T2 (zh)
IL (1) IL217442A (zh)
WO (1) WO2011005106A1 (zh)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8533240B2 (en) * 2010-09-22 2013-09-10 International Business Machines Corporation Write behind cache with M-to-N referential integrity
US9158803B2 (en) * 2010-12-20 2015-10-13 Google Inc. Incremental schema consistency validation on geographic features
US20130097116A1 (en) * 2011-10-17 2013-04-18 Research In Motion Limited Synchronization method and associated apparatus
US8751549B2 (en) * 2012-01-06 2014-06-10 International Business Machines Corporation Persistent data management in multi-image code load systems
US20130339838A1 (en) * 2012-06-13 2013-12-19 Arun Kumar Venkata Swamy Ananda Methods for column deletion in sharepoint
US9910929B2 (en) * 2012-10-24 2018-03-06 International Business Machines Corporation Web browser-based content management system
US9430543B2 (en) 2013-03-15 2016-08-30 Wal-Mart Stores, Inc. Incrementally updating a large key-value store
US9367806B1 (en) 2013-08-08 2016-06-14 Jasmin Cosic Systems and methods of using an artificially intelligent database management system and interfaces for mobile, embedded, and other computing devices
CN105723365B (zh) 2013-11-19 2019-09-03 华为技术有限公司 用于优化索引、主数据库节点和订户数据库节点的方法
US9819768B2 (en) 2013-12-13 2017-11-14 Fuze, Inc. Systems and methods of address book management
JP6251388B2 (ja) * 2014-11-12 2017-12-20 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ＫｅｙＶａｌｕｅデータベースのデータテーブルを更新するための方法およびテーブルデータを更新するための装置
US10255302B1 (en) 2015-02-27 2019-04-09 Jasmin Cosic Systems, methods, apparatuses, and/or interfaces for associative management of data and inference of electronic resources
JP6727775B2 (ja) * 2015-08-31 2020-07-22 キヤノン株式会社 サーバ装置、制御システム、制御方法、及び、プログラム
CN106570036B (zh) * 2015-10-13 2019-11-12 北京国双科技有限公司 基于HBase数据库的数据添加方法和装置
US10922301B1 (en) * 2016-07-26 2021-02-16 Amdocs Development Limited Apparatus, computer program, and method for trigger-based tracking of database modifications
CN106802817A (zh) * 2016-12-29 2017-06-06 杭州迪普科技股份有限公司 SQLite数据库的升级方法及装置
KR101908556B1 (ko) * 2017-01-03 2018-10-17 (주)비아이매트릭스 갱신 레코드를 자동 추출하는 스프레드시트 기반 데이터베이스 자동 갱신 시스템
US10594560B2 (en) * 2017-03-27 2020-03-17 Cisco Technology, Inc. Intent driven network policy platform
KR102034679B1 (ko) 2018-01-17 2019-10-23 (주)비아이매트릭스 그리드 인터페이스 기반 데이터 입출력 시스템
CN110958287B (zh) * 2018-09-27 2022-06-24 阿里云计算有限公司 操作对象数据同步方法、装置及系统
CN109460288B (zh) * 2018-10-30 2022-04-12 腾讯科技(成都)有限公司 一种事务处理方法、管理服务器、事务处理系统和存储介质
US11243956B1 (en) * 2019-07-10 2022-02-08 Amazon Technologies, Inc. Enforcing foreign key constraints for efficient materialized view updates
CN112825069B (zh) * 2019-11-21 2024-05-24 阿里巴巴集团控股有限公司 数据库数据的分析方法、设备、系统及存储介质
CN111339058B (zh) * 2020-03-24 2023-05-16 中国人民解放军国防科技大学 一种集合同步方法及装置
CN111651519B (zh) * 2020-05-08 2023-04-25 携程计算机技术（上海）有限公司 数据同步方法、数据同步装置、电子设备及存储介质
US11687523B2 (en) * 2020-11-25 2023-06-27 Salesforce, Inc. System and method for efficiently transferring data for offline use
US11675800B2 (en) 2020-11-30 2023-06-13 Salesforce, Inc. Version control and execution on a mobile device
CN113608683B (zh) * 2021-06-30 2024-05-07 山东海量信息技术研究院 一种双活磁盘的清理方法、系统及相关装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758337A (en) * 1996-08-08 1998-05-26 Microsoft Corporation Database partial replica generation system
CN1459061A (zh) * 2001-03-13 2003-11-26 菲利浦电子北美公司 数据自动更新

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758355A (en) * 1996-08-07 1998-05-26 Aurum Software, Inc. Synchronization of server database with client database using distribution tables
WO1998038583A1 (en) * 1997-02-26 1998-09-03 Siebel Systems, Inc. Method of determining visibility to a remote database client of a plurality of database transactions having variable visibility strengths
WO1998038586A1 (en) 1997-02-26 1998-09-03 Siebel Systems, Inc. Method of determining the visibility to a remote databaseclient of a plurality of database transactions using simplified visibility rules
EP1015997A4 (en) * 1997-02-28 2006-03-29 Siebel Systems Inc PARTLY REPLICATED DISTRIBUTED DATABASE WITH MULTIPLE LEVELS FROM REMOTE CLIENTS
US6098075A (en) * 1997-12-16 2000-08-01 International Business Machines Corporation Deferred referential integrity checking based on determining whether row at-a-time referential integrity checking would yield the same results as deferred integrity checking
JP3810577B2 (ja) 1999-03-26 2006-08-16 株式会社日立製作所 ディレクトリ同期方法
US6651047B1 (en) * 1999-05-19 2003-11-18 Sun Microsystems, Inc. Automated referential integrity maintenance
JP2001117800A (ja) 1999-10-21 2001-04-27 Matsushita Electric Ind Co Ltd 共用機器と１つ以上の端末機器のデ−タ同期システムおよび共用機器および端末機器
JP4025475B2 (ja) 1999-11-10 2007-12-19 日本電気株式会社 データベース交換システム
US6643669B1 (en) 2000-03-14 2003-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Method for optimization of synchronization between a client's database and a server database
TW579463B (en) * 2001-06-30 2004-03-11 Ibm System and method for a caching mechanism for a central synchronization server
US6745209B2 (en) * 2001-08-15 2004-06-01 Iti, Inc. Synchronization of plural databases in a database replication system
CA2472887A1 (en) * 2003-06-30 2004-12-30 Gravic, Inc. Methods for ensuring referential integrity in multithreaded replication engines
US7526486B2 (en) * 2006-05-22 2009-04-28 Initiate Systems, Inc. Method and system for indexing information about entities with respect to hierarchies
US8195606B2 (en) * 2008-12-12 2012-06-05 Microsoft Corporation Batch data synchronization with foreign key constraints

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758337A (en) * 1996-08-08 1998-05-26 Microsoft Corporation Database partial replica generation system
CN1459061A (zh) * 2001-03-13 2003-11-26 菲利浦电子北美公司 数据自动更新

Also Published As

Publication number Publication date
WO2011005106A1 (en) 2011-01-13
KR101675409B1 (ko) 2016-11-11
HUE039928T2 (hu) 2019-02-28
KR20120052301A (ko) 2012-05-23
IL217442A0 (en) 2012-02-29
IL217442A (en) 2015-11-30
CN102483759A (zh) 2012-05-30
EP2452277A1 (en) 2012-05-16
US8918380B2 (en) 2014-12-23
JP5676598B2 (ja) 2015-02-25
JP2012533108A (ja) 2012-12-20
CA2767533C (en) 2018-02-13
CA2767533A1 (en) 2011-01-13
US20110010344A1 (en) 2011-01-13
EP2452277B1 (en) 2018-08-22

Similar Documents

Publication Publication Date Title
CN102483759B (zh) 用于执行部分数据库的增量更新的方法、系统和装置
KR101941200B1 (ko) 아이디어 거래가 가능한 블록체인 기반의 소셜 네트워크 시스템
US7958031B2 (en) Apparatus, system, and method for automated identity relationship maintenance
CN102239458A (zh) 可视化数据元素之间的关系
CN103605703A (zh) 一种多平台之间数据一致性检测的方法和系统
CN110543516A (zh) 智能合约处理方法、装置、计算机设备及存储介质
CN103455589B (zh) 产品工厂模式下的产品数据迁移方法、装置及系统
CN109559164B (zh) 优惠信息处理方法、装置、电子设备及计算机可读介质
CN107710203A (zh) 分布式键/值存储库之上的事务数据库层
CN110266805A (zh) 信息推送方法、装置、电子设备及可读介质
JP2022073420A (ja) 情報管理システム
JP6019187B1 (ja) 企業情報整合装置および企業情報整合用プログラム
CN103295053A (zh) 多密码预警式内存锁银行卡
US10432716B2 (en) Metadata synchronization system
WO2022251238A1 (en) Systems and methods for ensuring quality of search system data
JP5250394B2 (ja) Ｅｄｉ統合処理システム、ｅｄｉ統合処理方法、およびｅｄｉ統合処理プログラム
CN104246753A (zh) 便携终端管理服务器及便携终端管理程序
CN102193975B (zh) 图形数据库联机事务中事务提交机制的实现方法
JP2007279839A (ja) リレーショナルデータベースのデータベース管理システムおよびテーブルの関連付け方法
CN111522831B (zh) 一种联盟链账本平台的数据记录方法及系统
JP7466416B2 (ja) 資産管理装置及び資産管理プログラム
CN102193976B (zh) 图形数据库联机事务中事务回滚机制的实现方法
JP2005078503A (ja) マスタデータ反映手段を備えるクライアント／サーバシステムならびにマスタデータ反映方法およびプログラム
CN113553376A (zh) 基于分布式架构的财险产品发布与检索方法、装置及系统
JP2003208346A (ja) データベース更新情報の反映システムおよびそのためのプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20151209

Termination date: 20210702