KR101675409B1 - 부분 데이터베이스의 증분 업데이트를 수행하는 방법, 시스템 및 장치 - Google Patents

Abstract

부분 데이터베이스가 서브셋인 데이터베이스를 포함하는 컴퓨터 시스템으로부터 클라이언트 장치에 저장된 부분 데이터베이스의 증분 업데이트를 수행하기 위한 방법, 시스템 및 장치에 관한 것이다. 데이터베이스의 동작의 결과로서 서버 데이터베이스에 삽입되거나, 삭제되거나 또는 변경되는 제 1 데이터베이스 레코드가 클라이언트 장치에서 대응하는 동작을 수행하기 위해 식별된다. 또한, 삽입되지 않거나, 삭제되지 않고, 또는 변경되지 않았으나 제약을 통해 제 1 레코드에 관련된 제 2 레코드가 식별된다. 제 2 레코드는 클라이언트 장치에서 수행되는 데이터베이스 동작을 통해 부분 데이터베이스에 삽입되거나 삭제되어 해당 제약이 부분 데이터베이스에서 준수된다. 레코드의 식별은 데이터베이스 로그 및 레코드 타입 간의 구조화된 관계에 기초한다.

Description

부분 데이터베이스의 증분 업데이트를 수행하는 방법, 시스템 및 장치{METHODS, SYSTEMS AND DEVICES FOR PERFORMING INCREMENTAL UPDATES OF PARTIAL DATABASES}

본 발명은 서버 컴퓨터와 클라이언트 컴퓨터 사이의 데이터 동기화에 관한 것이다. 더욱 상세하게는, 본 발명은 서버 데이터베이스와 하나 또는 그 이상의 클라이언트 데이터베이스의 변경을 추적하고 수집하는 것 그리고 관련된 변경에 따라 동기화하는 것에 관한 것이다.

중앙 컴퓨터 서버 시스템에 저장된 데이터베이스는, 항상 온라인 상태에 있을 수 없는 클라이언트 컴퓨터에 부분적으로 복제되거나 복사될 수 있다. 그 결과, 데이터베이스 서버 시스템과 하나 또는 그 이상의 클라이언트 컴퓨터 사이에 데이터베이스 동기화의 필요성이 있으며, 그 동기화는 양 방향으로의 변경을 포함할 수 있는데, 즉 서버 시스템뿐만 아니라 클라이언트 컴퓨터의 데이터에도 변경이 만들어질 수 있다. 데이터가 서버에서 변경되었기 때문에 클라이언트로 전송되어야 하는 데이터에 더하여, 변경되지 않았지만 클라이언트에 관련성 있게 된 데이터를, 데이터베이스의 어떤 다른 변경의 결과로서 이전 동기화 이후 소정 시간에 클라이언트에 전송하는 것이 필요할 수 있다. 다시 말해, 서버에서 변경된 데이터 레코드(record)로 클라이언트를 업데이트하는 것에 더하여, 서버에서 변경되지 않은 어떤 레코드들이 클라이언트 컴퓨터로부터 삭제되거나 그에 추가되어야 할 수 있다.

일례는, 스토어(store)의 재고 목록(stock inventory)을 나타내는 부분 데이터베이스(partial database)를 보유하는 모바일 장치를 포함할 수 있다. 상기 장치는 재고 조사하거나 필요한 구매 물품을 다시 공급하기 위해 등록하는데 이용될 수 있다. 다음으로, 모바일 장치가 마지막에 동기화된 이후로 중앙 데이터베이스에 등록된 이용 가능 물품 리스트에 변경이 있을 수 있다는 점은 쉽게 이해될 것이다. 마찬가지로, 스토어의 종업원에 의해 등록된 실제 재고(inventory) 또는 특정 물품을 다시 보충하기 위한 구매 주문을 나타내는 변경이 모바일 장치에서 만들어질 수 있다. 더욱이, 중앙 데이터베이스로부터 이용 가능한 데이터의 부분이 클라이언트 장치의 부분 데이터베이스에 관련되는 변경이 만들어질 수 있다.

예를 들어, 클라이언트 장치는 스토어의 하드웨어 매장과 스포츠 매장에서 재고 조사하는데 이용될 수 있고, 그 결과 하드웨어 물품과 스포츠 물품을 포함하는 부분 데이터베이스가 업데이트될 수 있다. 이후에 동일한 장치가 동일한 스토어의 의류 매장에서 필요한 구매를 등록하기 위해 재지정될 수 있는데, 반면 하드웨어 매장에서는 더 이상 이용되지 않는다. 그러면 데이터베이스와 클라이언트의 동기화는 하드웨어 물품과 관련된 데이터베이스의 부분을 제거하고, 스포츠 물품과 관련된 데이터베이스의 부분을 추가해야 하며, 중앙 데이터베이스의 의류 물품의 리스트로 변경으로부터 야기되는 모든 필요한 업데이트를 한다.

클라이언트를 동기화하는 문제에 대한 강력한 해결책은, 우선 클라이언트에서 만들어진 모든 업데이트를 데이터베이스로 불러오고, 다음으로 클라이언트의 모든 데이터베이스 데이터를 삭제하며, 마지막으로 전체 데이터베이스 또는 부분 데이터베이스를 클라이언트로 다시 보내는 것이다. 이는, 클라이언트의 모든 데이터가 동기화의 시간 당시로 반드시 되도록 하나, 그것은 많은 데이터 전송을 필요로 하고, 또한 동기화가 수행되는 동안 다른 클라이언트와 상호 접속을 조작하는 시스템의 능력을 방해할 수 있다. 다르게 언급되지 않는다면, 불러온다(import)와 내보낸다(export)는 용어는 메인 (서버) 데이터베이스에 관련되어 이용되는 것이라는 점을 주의해야 한다. 그러므로, 불러온다, 또는 ~에 대해 불러온다는 것은 클라이언트로부터 데이터베이스로 새로운 데이터의 도입을 나타내며, 반면 내보낸다, 또는 ~로부터 내보낸다는 것은 서버 데이터베이스로부터 클라이언트 데이터베이스로 데이터를 도입하거나 업데이트하는 것을 의미한다.

제안된 하나의 대안은 메인 데이터베이스의 모든 레코드에 대한 모든 업데이트의 데이터베이스 로그(log)를 유지하는 것이고, 동기화를 이러한 로그에 기초하는 것이다. 이전 동기화에서 데이터베이스의 상태가 알려져 있고, 이전 동기화와 진행중인 동기화 사이의 모든 데이터베이스 트랜잭션이 알려져 있다면, 변경의 로그에 기초하여 그리고 실제 데이터베이스와 간섭 없이 클라이언트를 업데이트하는 것이 가능하다. 상기 로그에 기초하여 두 동기화 사이의 데이터베이스에 대한 모든 변경의 요약이 생성될 수 있다. 이 요약은, 두 동기화 사이에서 데이터베이스의 차이, 데이터베이스 Δ로서 생각될 수 있다.

클라이언트를 업데이트하기 위해 데이터베이스 Δ를 이용하는 것은, 클라이언트가 메인 데이터베이스의 완전한 복사본을 보유하고 있다면 상당히 간단하다. 그러한 경우에, 클라이언트는 전체 데이터베이스 Δ로 업데이트되어야 한다; 모든 경은 클라이언트로 보내져야 한다. 그러나, 클라이언트가 단지 부분 데이터베이스를 보유하고 있다면, 동기화되는 특정 클라이언트에 관련된 데이터베이스 Δ의 레코드들을 식별하고 단지 이들을 전송하는 것이 필요하다. 더욱이, 변경되지 않은, 즉 데이터베이스 Δ의 부분이 아니지만 다른 이유로 클라이언트에 필요하게 된 레코드들을 전송하는 것이 필요할 수 있다.

변경되지 않은 레코드는 다른 이유로 클라이언트와 관련될 수 있다. 일반적으로, 두 가지 분류의 이유가 식별될 수 있으며, 그들은 내부적 이유(internal reason)와 외부적 이유(external reason)로 언급될 수 있다. 내부적 이유는, 하나의 레코드(데이터베이스 Δ의 부분인 레코드)에서의 변경이 제약(constraint)을 준수(fulfill)하고 관련 데이터가 클라이언트에 실제 존재하는 것을 확실하게 하기 위해 추가적인 (변하지 않은) 레코드들을 클라이언트에 대해 불러올 필요가 있도록 하는 케이스들을 포함한다. 외부적 이유는, 데이터베이스 외부의 어떤 사실이, 예를 들면 특정 시간 지점에 클라이언트에 대해 레코드를 불러오는 것을 적절하게 하는 케이스들을 포함한다. 후자의 예는, 이전 동기화에서도 준비된, 그러나 작업이 수행되어야 하기 전의 날짜까지 클라이언트로 전송되지 않은 작업 주문일 수 있다.

유사한 이유로, 이전 동기화에서 클라이언트의 부분 데이터베이스에 관련된 레코드들은, 레코드 자체가 변경되지 않더라도 관련되지 않을 수 있고, 그 결과 변경되지 않은 레코드들은 제거되는 것이 필요할 수 있다.

따라서 제약(constraint)을 준수(fulfill)하는 동안 부분 데이터베이스의 증분 동기화(incremental synchronization)를 수행할 수 있는 방법 및 시스템에 대한 수요가 있다.

본 발명은, 서버 컴퓨터 시스템으로부터 클라이언트 장치를 업데이트하거나 동기화하는 방법, 컴퓨터 시스템 및 컴퓨터 기록 매체에 관한 것이다. 상기 서버 컴퓨터 시스템은 데이터베이스를 포함하고, 클라이언트 장치는 서버의 데이터베이스의 부분적 표시(partial representation)를 수용한다. 데이터베이스의 부분적 표시는 서버 컴퓨터 시스템에 존재하는 데이터베이스 레코드들의 서브셋(subset)을 포함하며, 이러한 서브셋은 클라이언트에서 받아들여지는 레코드로서 언급될 수 있다. 상기 방법은, 데이터베이스 제약이 준수되는 동안 클라이언트의 증분 동기화를 허용한다.

그러므로 전자 클라이언트 장치를 업데이트하기 위해 본 발명에 따라 작동하는 서버 컴퓨터는 복수의 데이터베이스 레코드들을 갖는 제1 데이터베이스를 포함할 수 있고, 상기 클라이언트 장치는 상기 제1 데이터베이스의 부분 리프리젠테이션를 포함할 수 있다. 상기 데이터베이스의 부분 리프리젠테이션은, 클라이언트 장치에서 수용되는 데이터베이스 레코드들을 포함한다. 다음으로 그러한 컴퓨터 시스템에서 구동하는 방법은, 클라이언트의 이전 업데이트 이후에 제 1 데이터베이스로 삽입되거나 그로부터 삭제되거나 또는 그에서 변경된 제 1 레코드를 식별하는 단계, 및 제 1 데이터베이스에 추가되거나 그로부터 삭제되거나 그에서 변경되지 않은, 하지만 제약을 통해 제 1 레코드와 관련된 제 2 레코드를 식별하는 단계를 포함한다. 이러한 식별 레코드들에 기초하여, 다음으로 상기 방법은, 클라이언트 장치가 제1 데이터베이스의 부분 리프리젠테이션의 제 1 레코드의 대응하는 삽입, 삭제 또는 변경을 수행하도록 지시하는 서버 컴퓨터로부터 제1 데이터를 전송하고, 그것은 상기 서버 컴퓨터로부터 제2 데이터를 전송하는데, 여기서 제2 데이터는 클라이언트 장치가 제1 데이터베이스의 부분 리프리젠테이션에 제2 레코드를 삽입하거나 그로부터 제2 레코드를 삭제하도록 지시하여 제약이 제1 데이터베이스의 부분 리프리젠테이션에서 준수되도록 한다.

제약은, 이를테면 데이터베이스 관리 시스템(database management system; DBMS)으로 구현되는 외래 키 제약(foreign key constraint)과 같은 선언된 데이터베이스 제약일 수 있지만, 그것은 또한 동기화 메카니즘 자체의 규칙의 부분으로서 정의될 수도 있다는 점의 주목되어야 한다

제1 레코드의 식별(identification)은, 본 발명의 제1 실시예에 따라, 시간 윈도우(time window)의 개시 및 종료, 클라이언트 장치의 이전 업데이트에 연계된 시간 지점을 나타내는 개시, 및 클라이언트 장치의 현재 업데이트에 연계된 시간 지점을 나타내는 종료, 및 서버 컴퓨터에 의해 수행된 데이터베이스 동작의 로그를 스캐닝하는 프로세스에 기초할 수 있다. 다음으로 상기 제1 레코드는, 적어도 하나의 데이터베이스 동작이 시간 윈도우 중에 수행되는 레코드로서 식별될 수 있다.

클라이언트 장치로 제1 데이터를 전송하는 단계에 앞서, 본 발명의 일 실시예는, 시간 윈도우의 시작에 제1 레코드의 상태를 대표하는 적어도 하나의 값(value)을 결정하도록 로그를 스캐닝하는 단계 및 시간 윈도우의 시작에 부분 데이터베이스에 상기 값이 수용되었는지를 결정하는 단계, 및 시간 윈도우의 종료에 제1 레코드의 상태를 대표하는 대응값을 결정하도록 로그를 스캐닝하는 단계 및 시간 윈도우의 종료에 부분 데이터베이스에 상기 값이 수용될지를 결정하는 단계 중 적어도 하나를 수행하는 단계를 포함한다. 수용되는 것의 결정은, 레코드의 상태를 대표하는 값, 제1 레코드의 레코드 타입을 위한 선언된 규칙(declared rule), 및 제1 레코드와 다르지만 서브셋 제약을 통해 그와 연계된 레코드를 위한 대응하는 결정 중 적어도 하나에 기초할 수 있다. 서버 컴퓨터의 제1 기록에 수행된 데이터베이스 동작이 제1 데이터베이스로의 제1 레코드의 삽입을 나타낸다면, 시간 윈도우의 종료에 제1 레코드의 상태를 대표하는 값이 시간 윈도우의 종료에 부분 데이터베이스에 수용되는 것이 결정되는 경우, 상기 데이터는 다음으로 부분 데이터베이스의 제1 기록을 삽입하라는 지시를 나타내도록 구성될 수 있다. 마찬가지로, 데이터베이스 동작이 제1 데이터베이스로부터의 제1 레코드의 삭제를 나타낸다면, 시간 윈도우의 시작에 제1 레코드의 상태를 대표하는 값이 시간 윈도우의 시작에 부분 데이터베이스에 수용되는 것이 결정되는 경우, 상기 데이터는 제1 레코드를 삭제하라는 지시를 나타내도록 구성될 수 있다. 만일 상기 데이터베이스 동작이 제1 데이터베이스의 제1 기록의 변경을 나타낸다면, 상기 데이터는 다음 중 어느 하나, 즉 ⅰ) 시간 윈도우의 시작에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되고 시간 윈도우의 종료에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되는 것이 결정된 경우, 부분 데이터베이스의 제1 레코드를 변경시키는 것, ⅱ) 시간 윈도우의 시작에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되고 시간 윈도우의 종료에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되지 않는 것이 결정된 경우, 부분 데이터베이스로부터 제1 레코드를 삭제하는 것, 및 ⅲ) 시간 윈도우의 시작에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되지 않고 시간 윈도우의 종료에 제1 레코드의 상태를 대표하는 값이 부분 데이터베이스에 수용되는 것이 결정된 경우, 부분 데이터베이스로 제1 레코드를 삽입하는 것 중 어느 하나를 수행하라는 지시를 나타내도록 구성될 수 있다.

클라이언트 장치로 제2 데이터를 전송하는 단계에 앞서 대응하는 액션이 수행될 수 있지만, 제2 레코드는 서버에서 변하지 않은 레코드이기 때문에, 부분 데이터의 그러한 레코드를 변경시키는 지시를 전송하는 것은 정상적으로 필요하지 않다. 그러나, 본 발명의 어떠한 실시예들에 의하면, 클라이언트 장치에서 수행되도록 데이터베이스 동작을 지시하도록 구성된 데이터가, 그러한 지시가 변화한 레코드 또는 변화하지 않은 레코드에 관한 것인지 관계없이, 동일한 방법, 또는 컴퓨터 코드에 의해 구성될 수 있다.

본 발명의 일 측면에 따르면, 다른 레코드를 수용하는 대응하는 결정은, 대표값을 결정하도록 로그를 스캐닝하고 클라이언트에 이 값의 수신을 결정하는 단계를 반복함으로써 수행된다. 이는, 예를 들어 동일한 함수, 방법 또는 절차에 대한 재귀적 호출(recursive call)의 형태로 구현될 수 있다.

본 발명의 다른 측면에 따르면, 레코드 타입을 위한 선언 규칙은, 그 레코드 타입의 레코드의 상태를 대표하는 값을 입력으로서 수용하고, 클라이언트에 이 값에 대한 수용의 대응하는 결정을 생산한다. 그 값은 레코드의 상태의 대표이기 때문에, 그 결정은 일반적으로 레코드가 클라이언트 데이터베이스에서 수용되어야 하는지의 결정이다.

본 발명의 일 실시예에 의하면, 적어도 하나의 선언 규칙이 데이터베이스의 프로그래머나 사용자에 의해 선언된다.

제2 레코드는 제약을 통해 변경된 제1 레코드에 대한 관계 때문에 부분 데이터베이스에 필요한 변하지 않은 레코드이긴 하지만, 제2 레코드가 부분 데이터베이스에 추가되거나 그로부터 삭제된다는 사실이 유사한 제약을 통해 제2 레코드와 관련된 제3 레코드의 부가적 추가나 제거를 필요로 할 수 있다. 따라서, 본 발명의 다른 측면에 따르면, 하나의 방법은, 제1 데이터베이스에 추가되지 않거나 그로부터 삭제되지 않거나 또는 그에서 변화하지 않은, 그러나 제약을 통해 제2 레코드에 관련된, 그리고 그러한 제약을 준수하도록 부분 데이터베이스에 유사하게 추가되거나 제거되어야 하는 제3 레코드를 식별하는 단계를 포함할 수 있다. 다음으로 상기 방법은, 상기 제약이 제1 데이터베이스의 부분적 표시에서 준수되도록 제1 데이터베이스의 부분적 표시에 제3 레코드를 삽입하거나 그로부터 제3 레코드를 삭제하도록 장치에 지시하는 제3 데이터를 클라이언트 장치로 전송할 수 있고, 다음으로 모든 제약이 부분 데이터베이스에서 준수될 때까지 레코드를 식별하고 데이터를 전송하는 단계를 반복할 수 있다.

본 발명의 일 실시예에 따르면, 제1 레코드는 클라이언트에서 그 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하는 선언 규칙에 연계된 레코드 타입이고, 제2 레코드는 제1 레코드 타입에 대하여 서브셋 멤버 레코드 타입(subset member record type)인 레코드 타입이다.

다른 실시예에 따르면, 제1 레코드는 클라이언트에서 그 레코드 타입의 레코드 레코드의 상태를 대표하는 값의 수용을 결정하는 선언 규칙에 연계된 레코드 타입의 서브셋 멤버 레코드 타입인 레코드 타입이고, 제2 레코드는 제1 레코드 타입에 대하여 서브셋 멤버 레코드 타입인 레코드 타입이다.

또 다른 실시예에 따르면, 제1 레코드는 두 레코드 타입, 제2 레코드의 레코드 타입 및 제1 레코드와 제2 레코드의 레코드 타입과 다른 레코드 타입의 서브셋 멤버인 레코드 타입이다. 이 실시예에 의하면, 제1 레코드와 다르고 제2 레코드와 다른 레코드 타입을 갖는 레코드가 클라이언트에서 그 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하는 선언 규칙과 연계되고, 반면 제2 레코드는 제1 레코드의 레코드 타입의 적어도 하나의 레코드에 관련시키는 제약을 준수하는 것이 요청된다면 제2 레코드 타입의 레코드가 부분 데이터베이스에서 단지 수용되어야 하는 것을 진술하는 선언 규칙과 연계된 레코드 타입이다.

또 다른 실시예에 따르면, 제1 레코드는 제1 레코드 타입의 레코드가 단지 부분 데이터베이스에서 수용되어 필요하다면 제1 레코드와 제2 레코드와 다른 레코드 타입의 적어도 하나의 레코드에 관련시키는 제약을 준수하는 것을 진술하는 선언 규칙과 연계된 레코드 타입이고, 제2 레코드는 제1 레코드 타입에 대하여 서브셋 멤버 레코드 타입인 레코드 타입이다.

상술한 데이터베이스 동작의 로그의 다양한 스캔이 모든 관련 정보가 획득되는 하나의 스캔으로서 수행될 수 있거나, 각각의 스캐닝 동작을 위한 단 하나 또는 약간의 데이터 아이템을 획득하기 위해 스캔이 반복적으로 수행될 수 있다.

어떤 실시예들에 의하면, 제1, 제2 및 제3 레코드 타입 사이의 관계가, 역할로서 명확하게 정의된다. 본 발명의 실시예들은 설계 기준에 의존하여, 명확하게 또는 암시적으로, 역할의 어떠한 조합을 구현할 수 있다.

본 발명의 컴퓨터 시스템은, 클라이언트 장치를 업데이트하기 위해 본 발명의 방법을 수행하도록 프로그래밍된 프로세서와 함께 하나 또는 그 이상의 서버 컴퓨터를 포함할 수 있다. 본 발명의 컴퓨터 판독가능 기록매체는, 실행될 때 서버 컴퓨터가 본 발명의 방법을 수행하도록 야기하는 지시를 포함할 수 있다. 컴퓨터 판독가능 매체는, 예를 들어 하드 드라이브, CD-ROM 또는 DVD-ROM, 플래시 메모리, 전기적 소거 프로그램 가능 읽기 전용 메모리(EEPROM), 또는 본 발명의 기술 분야의 당업자들에게 알려진 어떠한 다른 편리한 타입의 저장 장치와 같은 자기적으로 또는 광학적으로 판독가능한 매체일 수 있다.

본 발명의 상세는 첨부된 청구항으로 정의되는 반면, 대표적인 모범적 실시예가 도면을 참조하여 이하에서 제공된다.

본 발명의 대표적인 실시예는, 이하에서 주어지는 상세한 설명 및 첨부된 도면으로부터 보다 잘 이해될 것이다. 이 도면들은 단지 예시의 수단으로 주어지며, 그러므로 본 발명을 제한하는 것이 아니다. 이러한 도면들에서는 동일한 참조 번호는 동일한 구성요소를 나타낸다.
도 1은, 본 발명에 따라 동기화될 수 있는 서버와 클라이언트를 포함하는 시스템을 도시하는 다이어그램이다.
도 2는, 본 발명에 따라 데이터베이스 클라이언트의 동기화 전과 후의 선택 테이블의 예시적인 값을 도시하는 다이어그램이다.
도 3은, 본 발명에 따라 테이블의 예 및 그들이 데이터베이스 동작에서 서로 어떻게 관련되는지를 도시한다.
도 4는, 데이터베이스의 다른 부분들이 다른 이유를 위해 클라이언트의 동기화에 어떻게 관련될 수 있는지를 도시하는 다이어그램이다.
도 5는, 본 발명에 따른 동기화의 방법을 도시하는 플로우차트이다.
도 6은, 동기화 중에 클라이언트를 업데이트하는 후보들인 데이터베이스 엔트리를 확인하는 방법을 도시하는 플로우차트이다.
도 7은, 확인된 데이터베이스 엔트리가 클라이언트를 업데이트할 지를 결정하고 업데이트를 위한 적절한 데이터베이스 명령을 찾는 방법을 도시하는 플로우차트이다.
도 8은, 제 1 타입의 데이터베이스 레코드가 특정 시간 포인트에서 클라이언트에서 수용되거나 수용되었는지의 결정을 도시하는 플로우차트이다.
도 9는, 제 2 타입의 데이터베이스 레코드가 특정 시간 포인트에서 클라이언트에서 수용되거나 수용되었는지의 결정을 도시하는 플로우차트이다.
도 10은, 어떤 제2 타입의 데이터베이스 레코드가 특정 시간 포인트에서 클라이언트에서 수용되었는지의 결정에 대한 방법의 특정 상세를 도시하는 플로우차트이다.

이제 참조가 실시예들에 상세하게 만들어질 것인데, 그 예들은 첨부된 도면에 도시된다. 다음 상세한 설명에서, 다양한 특정 상세가 본 발명의 전반적인 이해를 용이하게 하기 위해 제시된다. 그러나, 본 발명이 여기에서 제시된 특정 예들로 한정되는 것은 아니고, 본 발명이 이러한 특정 상세 없이 실행될 수 있다는 점은, 본 발명의 기술 분야에 속하는 당업자들에게 이해될 것이다. 또한, 실시예들의 양상을 불필요하게 모호하게 하지 않도록, 공지된 수많은 방법, 절차, 구성요소, 회로, 및 네트워크는 상세하게 설명되지 않는다.

본 발명은 데이터베이스의 동기화, 보다 상세하게는 클라이언트 컴퓨터와 서버 컴퓨터 사이의 동기화에 관한 것인데, 여기서 상기 서버 컴퓨터는 전체 데이터베이스를 관리하고, 상기 클라이언트 컴퓨터는 서버 컴퓨터에 저장된 데이터의 적어도 하나의 서브셋을 보유한다. 본 명세서가 중앙 데이터베이스를 전체 데이터베이스(entire database) 또는 완전한 데이터베이스(complete database)로서 언급할 때, 완전성(completeness)은 단지 그것의 클라이언트에 대하여 그렇다는 것을 주의해야 한다. 완전한 데이터베이스는, 이를테면 보다 상위 계층 레벨에 있고 해당 데이터베이스가 데이터를 수신하는, 어떤 다른 데이터베이스에 대하여 완전할 필요는 없다.

클라이언트 컴퓨터는 인터넷과 같은 통신 네트워크에 지속적으로 접속된 퍼스널 컴퓨터일 수 있으나, 클라이언트 컴퓨터는 또한 랩탑 컴퓨터, PDA(Personal Digital Assistance, 또한 팜탑 컴퓨터나 핸드-헬드 컴퓨터로 알려진), 또는 심지어 모바일 전화, 미디어 플레이어나 전자 게임 장치일 수도 있다. 그러므로, 클라이언트 컴퓨터는, 하나 또는 그 이상의 디스플레이, 이를테면 터치스크린, 물리적이거나 가상의 키보드, 포인팅 장치, 이를테면 마우스나 조이스틱, 스크역할이나 클릭 휠, 및 스피커와 같은 유저 인터페이스 장치가 제공될 수 있다. 간결성을 위해, 이하의 설명에서는, 터치 스크린을 포함하는 휴대용 다기능 장치가 대표적인 실시예로서 이용된다.

이제 도 1을 참조하는데, 이는 하나의 중앙 서버 및 여러 클라이언트 장치를 포함하는 시스템을 도시한다. 상기 장치는, 모두 네트워크(110)에 접속되는데, 이는 인터넷, 무선 또는 고정 로컬 영역 네트워크(WLAN, LAN), (종종 셀룰러 네트워크로 언급되는) 모바일 전화 네트워크와 같은 하나 또는 그 이상의 데이터 통신 네트워크를 포함할 수 있다. 중앙 서버(101)는 일반적으로 네트워크(110)에 지속적으로 접속되고, 데이터베이스를 구성하는 레코드의 다양한 테이블을 관장하는데 이용된다. 더욱이, 서버(101)는 일반적으로 데이터베이스 관리 시스템(DataBase Management System; DBMS) 및 데이터베이스와 클라이언트 사이의 인터페이스에 기반한 웹을 제공할 수 있는 웹 서버 솔루션을 관장할 수 있다. 상기 데이터베이스 관리 시스템은, 이를테면 Microsoft Corporation의 Microsoft SQL Server, Oracle Corporation의 ORACLE 데이터베이스, 또는 MySQL AB의 MYSQL일 수 있다. 상기 웹 서버 솔루션은, 이를테면 Apache Software Foundation의 APACHE HTTP Server, 또는 Microsoft Corporation의 Internet Information Services(IIS)일 수 있으며, PHP, Python, Ruby on Rails 또는 Server Side JavaScript(SSJS)와 같은 서버 사이드 스크립팅 언어(server side scripting language)와 결합하는 것도 가능하다. 다음으로 상기 웹 서버는, 데이터베이스 컨텐트를 HTTP 및 TCP/IP 프로토콜을 이용하여 클라이언트로 제공할 수 있을 것이고, 상기 클라이언트는 클라이언트 장치에서 로컬로 구동되는 웹 브라우저 타입 어플리케이션을 이용하여 데이터베이스 컨텐트에 접근할 수 있다. 대안으로, 독점적 프로토콜이 이용될 수 있고, 전용 어플리케이션이 웹 브라우저 대신에 클라이언트에 의해 이용될 수 있다.

상기 서버(101)는 여러 컴퓨터의 시스템에서 구현될 수 있고, 또한 여러 데이터베이스의 데이터의 복제(replication)나 미러링(mirroring)이 본 발명의 원리와 일치한다. 명확성을 위해 그리고 불필요한 혼동을 피하기 위해, 여기에서 설명된 대표적인 실시예들은, 단 하나의 서버 컴퓨터를 포함하는 것으로 설명될 것이나, 본 발명이 이러한 측면으로 제한되는 것은 아니다.

제 1 클라이언트 장치(102)는, 터치 스크린 및 스타일러스 타입 입력 장치를 갖는 태블릿 컴퓨터나 PDA로서 도시된다. 제 2 클라이언트 장치(103)는, 이를테면 다른 PDA 또는 스마트폰일 수 있다. 제 3 클라이언트 장치(104)는, 랩탑 컴퓨터로서 도시된다. 제 4 클라이언트 장치(105)는, 퍼스널 컴퓨터 또는 워크스테이션으로서 도시된다. 퍼스널 컴퓨터(105)는, 서버(101)와 지속적으로 온라인 상태에 있을 수 있다. 이는 전형적인 온라인 클라이언트-서버 기술을 나타내는데, 여기에서는 동기화의 필요가 없을 수 있고 대신에 퍼스널 컴퓨터(105)에서 만들어진 모든 변화가 서버(101)로 전송되어 즉시 데이터베이스에 저장될 수 있다. 도 1에 도시된 바와 같이 구성된 시스템의 실례는, 중앙 데이터베이스 서버(101)가 일련의 스토어들로부터 이용 가능한 물품의 리스트 및 전체 재고(inventory)를 저장하는 것일 수 있다. 클라이언트 컴퓨터(102)는, 어떤 타입의 물품, 이를테면 의류를 여러 스토어에 다시 채우는 배달 트럭의 운전자에 의해 이용될 수 있다. 클라이언트 컴퓨터(103)는 하나의 특정 스토어에 있는 모든 타입의 물품을 재고 조사하는데 이용될 수 있고, 랩탑(104)은 여러 스토어를 방문하고 주문을 등록하는 판매 대리인에 의해 이용될 수 있다. 상기 퍼스널 컴퓨터(105)는, 데이터베이스 서버(101)를 관리하고, 새로운 타입의 물품을 도입하며, 중단된 물품을 데이터베이스로부터 삭제하고, 가격을 변화시키는 것 등을 위해, 중앙 오피스에서 이용될 수 있다.

본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는, 서로 다른 변경들, 다른 클라이언트 장치들의 업데이트를 필요로 하는 변경들, 그리고 특히 아직 바뀌지 않았으나 다른 장치에서 일어난 변경의 결과로 특정의 클라이언트 장치들에 대해서 관련이 있거나 또는 관련이 없게 된 데이터들의 동기화를 필요로 하는 변경들을 포함하는, 많은 수의 변경들이 다른 클라이언트 장치들에서 이루어질 수 있다는 것을 쉽게 이해할 수 있을 것이다. 상기 변경들 중 가장 후자의 변경은 예를 들어 판매 대리인이 사용하는 랩탑(104)이 스토어 내에서 새로운 매장으로 할당되는 것 일 수 있다. 판매 대리인들의 다양한 할당을 열거하는 할당(assignment) 테이블에서의 엔트리(entry)는 상기 변경을 반영할 수 있고, 상기 엔트리는 클라이언트가 동기화된 이후 판매 대리인 랩탑(104) 상에 업데이트 되어야 한다. 그러나 또한 판매 대리인은 그의 랩탑에서 해당 매장(department)을 위한 엔트리는 물론, 해당 매장에 의해서 저장된 물품들을 나타내는 레코드들에 접근할 필요가 있을 수 있다. 이러한 레코드들은 아직 바뀌지 않았지만, 다음 동기화에서 대리인의 랩탑(104)에 추가되어야 한다. 할당 값에 대한 실제 변경은 클라이언트 스스로에서 또는 서버에서 이루어질 수 있다는 것에 주목해야 한다. 만약 클라이언트에서 변경이 이루어지는 경우 서버로 불러오기 될 수 있고 이후 다음의 동기화 동안에 작용될 수 있다.

도 1에 나타나 예는 하나의 서버 및 상기 서버에 직접 연결된 복수 개의 클라이언트를 포함하는 반면에, 본 발명은 도시되지 않은 추가적인 클라이언트들에 대하여 클라이언트들 스스로가 서버로서 동작하는 계층적 시스템에서 구현될 수 있다.

도 2를 참조하면, 상술한 예가 도시되어 있다. 도 2A에서, 할당(assignment)으로 명명된 첫 번째 테이블은 대리인(representative)(104) 및 상기 대리인(104)이 속하는 매장(department)(1001)을 나타내는 엔트리를 포함한다. 상기 엔트리들은 외래 키들(foreign keys)들, 예를 들어 다른 테이블의 키를 참조하는 외래 키들일 수 있다. 편의를 위해 상기 대리인은 그의 클라이언트 컴퓨터와 동일한 번호로서 식별될 수 있고, 대응되는 테이블(미도시)에서 발견될 수 있다. 반면에 상기 대리인이 속하는 매장은 매장(department) 테이블(202)에서 주요 키로 나타난 숫자에 의해서 식별될 수 있다. 세 번째 테이블(203)은 어떤 물품(product)이 어떤 매장에서 찾을 수 있는지를 나타낸다. 상기 테이블은 많은 수의 엔트리들을 나타내는데 이번 예에서는 두 개의 매장 10001, 10002 중 하나와, 해당 매장에서 찾을 수 있는 물품을 나타낸다. 엔트리들은 물품들이 추가되거나 제거되면 입력되거나 삭제될 수 있고 또는 물품이 어느 매장에서 다른 매장으로 이동되면 엔트리들은 변경될 수 있다. 엔트리 각각은 다른 테이블을 참조하는 외래 키(foreign key)이다. 마지막 테이블(204)은 물품번호와 물품명(product name)으로 나타낸다. 판매 대리인의 클라이언트 컴퓨터에서 제공되어야 하는 모든 레코드들은 테이블들에서 그레이 패턴으로 표시된다.

도 2B를 참조하면 테이블(201)에는 판매 대리인에 매장 10002가 할당되어 있는 것이 나타나 있다. 이는 데이터베이스에서 변경된 유일한 레코드이지만 그럼에도 불구하고, 상기 판매 대리인은 지금 테이블(202)에서 다른 매장을 위한 데이터베이스 엔트리에 접근할 필요가 있다. 이는 매장 10001을 위한 엔트리는 클라이언트 데이터베이스에서 제거될 수 있는 반면에, 매장 10002를 위한 엔트리는 클라이언트 데이터베이스로 내보내져야 하는 것을 의미한다.

그러나 할당 테이블(201)에서 변경된 레코드에 의해서 참조되는 레코드를 내보내는 것만으로는 충분하지 않다. 새롭게 내보낸 레코드를 참조하는 레코드들 모두를 내보내는 것이 필수적이다. 이는 내보낸 매장 레코드 10002를 참조하는 테이블(203)의 모든 엔트리들이 내보내져야 하고, 테이블(203)에서 새롭게 내보내진 레코드에 의해서 참조되는 물품(product) 테이블(204)의 모든 레코드가 함께 내보내져야 하는 것을 의미한다. 이러한 방법으로, 도 2B에서 그레이 패턴으로 표시된 새로운 매장에서 사용 가능한 모든 물품들은 클라이언트 장치에 제공될 것이다.

동기화를 수행하기 위해서, 서버(101)에서 로그(log)가 유지될 수 있다. 상기 로그는 DBMS에 의해서 생성되고 유지될 수 있다. 유사한 로그는 모든 클라이언트 장치에서 유지될 수 있다. 로그는 데이터베이스와는 독립된 적어도 하나의 리스트일 수 있고 또는 로그는 데이터베이스에서 하나 또는 그 이상의 테이블로 구현될 수 있다.

로그의 목적 중 하나는 어떠한 시간 간격으로 이루어지는 데이터베이스의 변경을 수집하는 기능이다. 이하에서, 이러한 시간 간격은 △t로서 언급될 것이고, 반면에 △t 동안 수집되는 변경들은 데이터베이스 △로 언급될 것이다. 상기 데이터베이스 △는 실제로 변경된 레코드들만을 가리키는 것이며, 다른 변경들로 인해서 클라이언트에 추가되어야 하는 레코드들은 가리키지 않는다. 상술한 예에서, 할당(assignment) 테이블에서의 엔트리는 데이터베이스 △에 포함되지만, 매장과 물품에 대한 영향을 받은 엔트리는 그렇지 않다. 상기 영향을 받은 레코드 또는 엔트리는 그들의 수용(acceptance)을 클라이언트에 따라서 변하게 하는 것으로 언급될 것이고, 변하지 않은 레코드들로서 수용을 변하게 한 레코드들의 집합은 수용 △로서 언급될 것이다. 데이터베이스 △와 수용 △의 합은 트리거드 △(triggered △)로 언급될 것이다.

적절하게 시간 윈도우(time window) △t를 선택하는 것은 클라이언트의 이전(prior) 동기화에 기초할 수 있다. 예를 들어, 시간 윈도우는 이전의 동기화의 종료 이후 하나의 시간 단위(one time unit)에서 시작할 수 있고, 현재의 동기화가 초기화되는 시간 단위에서 종료할 수 있다. 시간 단위는 데이터베이스에서의 클럭의 상승일 수 있고 "틱(tick)"으로 언급될 것이다.

로그의 또 다른 목적은 어떠한 시간 t에서든지 존재하거나 존재하지 않는 레코드 발생의 값을 획득하는 것을 가능케 하기 위해서이다. 이것과 클라이언트를 마지막 동기화가 언제인지 기록하도록 설정하는 것의 조합으로, 어떠한 클라이언트를 어떠한 시간에서라도 서버가 동기화를 준비하도록 설정하지 않고서, 어떠한 클라이언트와도 동기화가 실제로 초기화되기 전에 동기화하는 것이 가능하게 된다. 그러나 본 발명의 어떠한 실시예는 로그에서 오래된 레코드들은 제거하도록 구현할 수 있다는 것에 주목해야 한다. 만약, 예를 들어 제거로 인해서 클라이언트가 동기화를 요구하는 때 결정된 시간 윈도우을 위한 로그가 미완성인 경우, 증가하는 업데이트 보다는 완성을 수행하는 것이 필수적일 수 있고, 이는 요구되는 값들이 로그로부터 삭제되었기 때문이다.

로그는 시간에 따른 데이터베이스 천이(transition)의 히스토리 전체를 표현하는 로그 엔트리를 포함할 수 있다. 새로운 레코드의 삽입(INS, insertion of a new record)은 INS-entry 타입의 엔트리를 생성할 수 있고, 반면에 현존하는 레코드의 삭제(DEL)은 DEL-entry 타입의 엔트리를 생성할 수 있다. 현존하는 레코드의 업데이트(UDP)는 INS-entry가 뒤따르는 DEL-entry를 생성할 수 있다.

로그 엔트리는 일반적으로 레코드 발생의 RID, 엔트리가 언제 만들어졌는지를 지시하는 타임스탬프, 엔트리 타입을 지시하는 로그 상태, 및 레코드 타입의 모든 칼럼들(all the columns of the record type)을 포함할 수 있다.

동기화 로그 엔트리는 또한 어느 클라이언트가 업데이트를 발생시켰는지를 확인할 수 있다. 이는, 불필요한 동작으로 인식되는, 업데이트 발생자에게 업데이트가 다시 되돌아 가는 것을 막을 수 있게 한다. 그러나, 이러한 규칙에는 예외가 있을 수 있는데 예를 들면 로그 엔트리가 이러한 예외를 지시하고 있는 경우가 있다. 이러한 예외의 예는 클라이언트로부터의 불러오기가, 클라이언트의 마지막 동기화 이후에 서버에서 이루어진 변경으로 인해, 불러오기 과정에서 변경되는 경우이다. 불러오기 과정에서 발생한 상기 변경은 해당 클라이언트로 다시 되돌아가야 할 것이고, 이 경우 업데이트는 업데이트 발생 장치로 다시 되돌아가야 할 것이다. 상기 변경의 일 예로 서버에서 물품 카테고리가 "clothing"에서 "apperal"로 변경되는 것을 들 수 있다. 클라이언트로부터 불러오기 된 새로운 엔트리가 레코드 칼럼에서 "clothing" 이라는 값을 포함하고 있는데 상기 값이 서버로 불러오기 되는 동안에 "apperal"로 변경되는 경우, 상기 값 변경이 클라이언트에서 업데이트되기 위해 전체 레코드는 업데이트 발생 장치로 되돌아가야 한다.

분할 내보내기(Partitioned export)는 상기 업데이트가 여러 부분으로 분할되어 따로 전송되는 상황을 의미한다. 분할 내보내기를 수행하고 또한 실제 가장 마지막에 수신한 발생에 기초한 복원을 가능하도록 하기 위해, △t 및 마지막 레코드(테이블 타입 및 RID)를 정의하는 시간 윈도우의 클럭들은, 동기화 로그와 함께 클라이언트의 데이테베이스에 저장된다. 본 발명의 몇몇 실시예에 따르면, 상기 데이터베이스를 위한 한 세트의 클럭 값들이 있다. 다른 실시예들은 사용자 정의 수용 방법에서, 외래 키 계층(foreign key hierarchy)마다 하나의 △t를 포함할 수 있다. 어떠한 외래 키 계층(foreign key hierarchy)에 속하지 않은 테이블은 분리 △t(separate △t)를 가질 수 있다. 이는 결과적으로 더 유연한 솔루션을 제공할 수 있다. 하지만, 동기화 원리(synchronization principle)는 동일하게 유지될 것이다.

클라이언트에 내장되고 사용자들은 일반적으로 접근할 수 없는 메모리 영역인 시스템 영역은, 동기화 과정에 사용되는 클럭 및 프로그레스 인포메이션(progress information)에 대한 정보를 홀드(hold)하기 위해 사용될 수 있다. 이러한 데이터베이스 로그 상태 영역은 필요한 모든 정보가 데이터베이스 자체에서 이용 가능하다는 것을 보장하는데 사용될 수 있고, 예를 들어 클라이언트 및 서버 간 연결 손실로 인해 동기화에 인터럽트가 발생하는 경우에, 매끄럽고 재시작 가능한 프로세스를 가능하게 할 수 있다. 동기화를 위해 필요한 모든 정보는 상기 데이터베이스 로그로부터 구할 수 있기 때문에, 동기화를 초기화한 이후 데이터베이스에 이루어진 변경으로 인해 발생한 오류 없이, 동기화는 인터럽트 시점에서 재개될 수 있다.

써머타임(daylight saving time), 시간 대역(time zones) 또는 다른 유형의 클럭 보정으로 인해 발생하는 혼동을 피하기 위해, 데이터베이스 타임 스탬프는 동기화를 수행하는 장치의 실제 시스템 클럭 또는 인공 클럭(artificial clock) 또는 양자 모두를 포함할 수 있다. 시스템 클럭 타임 스탬프는 시간 대역에 독립적인 타임 스탬프를 만들기 위해 모든 장치들에서 협정 세계 시간(UTC, Coordinated Universal Time)을 이용할 수 있다. 인공 클럭은 실제로는 데이터베이스 이벤트마다 1씩 증가하는 카운터(counter)이다. 따라서 인공 클럭은 시스템 클럭이 조절되어도 영향을 받지 않을 것이다. 그러나 본 발명은 시간을 트래킹하는 어떤 특수한 방법에 한정되지 않는다.

동기화 로그는 시스템에 포함된 모든 컴퓨터와 장치에서 유지된다. 로그의 단순 예제가 표 1에 나타나 있다.

먼저, 이 예제는 새로운 아이템이 물품 테이블에 "RID=1004"로 삽입된 것을 나타낸다. 본 예에서 RID의 첫 번째 숫자는 테이블을 구별한다. 시간 스탬프는 데이터베이스 이벤트의 카운터로서 "7354"이고, 로그 상태(Logstatus)="1"은 이것의 삽입을 나타내는 것이며 해당 로그 엔트리의 마지막에 #INS라는 코멘트도 동일한 의미이다. 본 데이터베이스의 이름 칼럼(Name)의 값에는 "Men's Jacket"이 삽입되어 있다. 로그 엔트리는 또한 클라이언트로, Client="104"를 나타낸다. 이는 상기 레코드가 삽입된 클라이언트를 식별한다. 본 예에 따르면, 모든 트랜잭션들이 동일한 리스트에 로그 된다. 그러나 다른 경우에서는 데이터베이스에서 테이블 각각에 대해 분리 로그를 사용하여 효율을 향상시킬 수 있다. 로그는 또한 트리거링(triggering) 과정에서 로그를 서치하고 검색(look up)하는 인덱스(index)를 포함할 수 있다.

상기 로그의 두 번째 줄은 엔트리로서 RID="1002"를 갖는 엔트리가 데이터베이스에서 삭제되었다는 것을 나타낸다. 타임 스탬프는 하나가 증가하였고, 로그 상태 Logstatus="0"은 삭제를 의미한다. 레코드 전부가 삭제되었기 때문에 이번 발생을 위한 다른 칼럼 엔트리들을 나열할 필요가 없다. 그러나 로그에서 삭제된 값도 포함하는 것은, 삭제 전에 어떤 값들이 레코드에 저장되었었는지를 평가하도록 할 수 있다. 그 결과 로그는 "Sweater"와 Client="102"를 표시한다. 이론적으로 데이터베이스 로그에서 새로운 값을 받는 칼럼 또는 필드를 삽입하는 것은 필요적일 뿐이라는 점에 주목할 필요가 있다. 이는 이전의 값들은 이전의 로그 엔트리들에서 찾을 수 있기 때문이다. 그러나, 모든 칼럼들을 로그 엔트리에 포함시키는 것과, 또한 변화가 없는 것 또는 삭제된 것을 로그 엔트리에 포함시키는 것은, 과거의 어떤 시점에서든 그 시점에 로그 작성(logging)이 이루어졌고 해당 로그가 삭제되지 않았다면, 그 시점에서의 테이블 행에 있는 컨텐츠를 찾을 수 있도록 할 수 있다. 반면에 엔트리가 부분적으로만 작성되었다면 동기화 동안에 필요한 값들이 삭제된 경우에 대비할 수 없을 것이다.

마지막으로 RID="2003"이라는 레코드는 업데이트된 것이다. RID의 첫 번째 숫자는 다른 테이블을 식별하는 것이다. 다시 말해 어느 PDA의 특정한 스토어(store)에 대한 관계 또는 할당을 구별하는 것이다. 이와 같은 경우에서 업데이트는 로그에서 두 개의 데이터베이스 이벤트에 따라서 두 개의 엔트리를 포함한다는 것에 주목할 수 있다. 먼저 원래의 데이터베이스 엔트리는, Logstatus="0"이 지시하는 바와 같이 삭제되었다. PDA="102"가 지시하는 데이터베이스 엔트리는 Store="D"에 할당된 것으로, 스토어들은 문자로 지정된 것을 알 수 있다. 상술한 바와 같이, 본 레코드의 칼럼(columns)에 입력된 값들을 나타내는 필드는 데이터베이스 로그에 삽입될 필요는 없지만, 본 예에서는 나타내었다. 상기 삭제 다음으로, 동일한 RID를 가지는 새로운 레코드가 테이블에 삽입되었다. 상기 새로운 엔트리는 PDA 칼럼에서 동일한 값을 가지지만, 로그 엔트리의 값은 스토어 칼럼에서 "F"이며 이는 곧 다른 스토어임을 확인하는 것이다.

앞에서는 로그가 하나 또는 그 이상의 데이터베이스 동작의 리스트로서 표현된 반면에, 이와 본 발명의 사상을 벗어나지 않는 범위에서 다른 실시예들이 있을 수 있다. 예를 들어 로그는, 클라이언트가 동기화되는 매 시간 또는 심지어 데이터베이스 동작이 수행되는 매 시간 데이터베이스 전체의 상태의 "스냅샷(snapshot)"을 다수 포함할 수 있다. 상기와 같은 로그 작성(logging) 방법은 메모리 또는 프로세싱 전력 등과 같은 자원이 현재 한계가 있다는 점에서 비실용적이지만, 연속적인 동기화 동안의 데이터베이스 변화를 모두 캡쳐하기 위하는 것과 같이 필요한 요구들을 만족시키기 위해서는 그와 같이 설계될 수도 있다.

전통적으로, 로그 기반의 증분 동기화(incremental synchronization)는, 동기화 로그들의 간단한 조사에 기초로 하여 온 것으로 데이터베이스에서 어떤 변경이 발생했는지를 결정하고 관련된 모든 변경들을 동기화 동안에 클라이언트에게 전송하기 위한 것이었다. 어떤 변화가, 특정 클라이언트에게 관련된 것인지를 결정하기 위해 필터(filters)들이 사용되어 왔다. 그러나 다른 테이블의 외래 키(foreign keys)들에 의해서 참조되는 테이블에서 필터링이 수행되는 데이터베이스에서는, 필요한 업데이트들이 제외될 수 있고 외래 키 제약(key constraint)은 더 이상 수행되지 않는데, 이에 대해서는 다음의 예에서 설명한다.

시간 윈도우 △t_{i -1} 동안 레코드 타입으로 store를 가지는 새로운 레코드가 데이터베이스에 추가되는 상황을 가정해보자. Store(스토어) 레코드 타입과 product(물품) 레코드 타입 사이에는 외래 키 제약이 있고, product 레코드 타입의 새로운 레코드로 10개가 추가된다. 새로운 물품들(products)은 새로운 스토어(store)의 물품들 중 일부이다.

시간 윈도우 △t_{i - 1} 의 종료시점에서 특정 클라이언트의 동기화 동안에(예를 들어 △t_{i -1} 에 대응하는 데이터베이스 △에 기초함), 상기 클라이언트와 관련있는 필터들은 새로운 스토어와 물품들을, 클라이언트에 존재하는 부분 데이터베이스에 입력되지 못하도록 한다고 가정하라. 만약 △t_i 동안에, 서버 데이터베이스에서, 새로운 스토어와 물품들이 관련있는 클라이언트 필터를 통과하는 상태로 데이터베이스가 변경되었지만 스토어 및 물품 레코드들에 저장된 값에는 아무런 변화가 없는 업데이트가 이루어진다면, 상기 레코드들에서의 변화를 나타내는 시간 간격 △t_i에 대한 데이터베이스 △에는 엔트리가 없을 것이고, 결과적으로 시간 간격 △t_i의 종료 시점에서 클라이언트가 서버와 동기화하는 때에 해당 클라이언트에게는 그것들이 전송되지 않을 것이다.

특정 레코드의 수용이 레코드 자체가 변경됐는지 여부와는 무관하게 변화하도록 허가된 부분 데이터베이스들의 동기화를 처리하기 위해서, 본 발명은 로그에 의해서 결정되는 데이터베이스 △에 기초한 업데이트를 수행할 뿐만 아니라, 트리거드 △(triggered △)의 개념을 도입하며, 여기에는 데이터베이스 △의 부분이 아닌 레코드들이 만약 데이터베이스 △의 부분인 레코드들에 의해서 트리거되는 경우, 상기 데이터베이스 △의 부분이 아닌 레코드들이 포함되어 있다.

본 발명의 몇몇 실시예에서, 레코드들은 외부 변수들로 인해서 그들의 수용을 변화시킬 수 있다. 외부 변수의 한 가지 예로 날짜 또는 시간이 있을 수 있다. 예를 들어 작업 주문이 처리되어야 하는 날의 전 날까지 상기 작업 주문을 클라이언트에서 이용할 수 있도록 하는 것은 바람직하지 않다. 결과적으로 작업 주문 모두를 살펴 이전의 동기화에서 거부되었으나 이번 동기화에서는 승인된 작업 주문들을 확인하는 것이 필요하다. 외부 변수들로 인해서 수용을 변하게 한 레코드들은 차례대로 추가적인 레코드들을 트리거할 수 있다.

마지막으로, 트리거된 레코드들은 재귀적으로 추가적인 레코드들을 트리거할 수 있다..

트리거링의 개념이 더 상세하게 논의될 것이지만, 먼저 레코드 타입과 상기 레코드들 상호간의 다양한 역할의 관계에 대해서 먼저 주목할 필요가 있다. 역할의 정확한 정의는 본 발명의 모든 실시예들에서 필수적인 것은 아니지만, 역할의 정의는 복잡한 데이터베이스에서 테이블들을 트리거드 △(triggered △)에 적절하게 포함시키는 역할을 할 것이다. 예를 들어, 본 발명의 실시는 여기에 서술된 역할들의 서브셋, 서술된 모든 역할들, 또는 여기서 서술된 역할들의 수퍼셋(superset)까지 포함하며, 디자인 표준과 특수한 실시예에서의 필요성으로 인한 추가적인 역할들의 정의는 디자인 선택에 대해서도 열려 있다.

도 3은 테이블들의 예와 테이블 상호간에 어떻게 관계를 맺을 수 있는지를 나타낸다. 테이블들, 또는 레코드 타입들 사이의 관계는 당업자에게 쉽게 이해될 것이다. 관계들은 하나의 테이블에서 어떤 아이템(또는 레코드)이 다른 테이블에서 하나 또는 이상의 아이템과 관련이 있을 때 사용된다. 관계들은 1 대 1, 1 대 다(多), 다(多) 대 다(多)일 수 있다. 일 대 일 관계의 일례는 "배우자(spouse)"이다. 남자는 결혼하면 부인 한 명을 가지게 되고, 해당 부인은 한 명의 남편을 가진다. 일 대 다(多) 관계의 일례는 성별(gender)이다. 남성과 여성이라는 용어는 많은 사람에 대해서 적용할 수 있지만, 개인 각각은 어느 하나 또는 다른 하나일 수밖에 없다. 다(多) 대 다(多)의 관계는 예를 들어 책과 저자이다. 책은 하나 이상의 저자가 있을 수 있고 저자는 한 권 이상의 책을 집필할 수 있다. 이러한 다른 종류의 관계들은 본 발명에 따라 동일한 방식으로 처리되고, 상술한 일 대 일, 일 대 다(多), 다(多) 대 다(多)의 관계로 한정되는 것이 아니다.

도 3의 예는 관계형 데이터베이스 구현에 기초한다. 관계형 데이터베이스에서, 레코드 타입은 테이블로 대표되고 레코드는 테이블에서 행으로 대표된다. 후술하는 예들에서, "테이블"은 "레코드 타입"으로 일반화되고 "행"은 "레코드"로 일반화되고, 역으로 "레코드 타입"은 "테이블"의 예가 되고 "레코드"는 "행"의 예가 될 수 있다. 본 발명의 사상 내라면 다양한 실시예들에서 사용되는 용어들에 의해서 한정되지 않는다.

본 발명에서, 사용자 정의 수용 방법(user defined acceptance methods)은 테이블에서 특정 행이 클라이언트에게 전송되어야 하는지 전송되지 말아야 하는 지를 결정하는데 이용될 수 있다. 테이블들 사이의 관계 때문에, 변화된 레코드 또는 해당 특정 테이블에서 직접 작용하는 방법에 의해서 수용을 변화시킨 레코드를, 전송하는 것이 충분하지 않을 수 있다. 또한 의문이 있는 행(row)과 관계를 가지는 다른 테이블로부터 행(rows)을 전송하거나 업데이트하는 것이 필요하다. 예를 들어 특정한 저자가 북스토어(bookstore)의 셀렉션에 추가되고 그에 따라 해당 북스토어와 연관된 클라이언트 컴퓨터에 추가되는 경우, 해당 클라이언트에게는 저자를 나타내는 행뿐만 아니라 해당 저자에 의해 집필된 책을 나타내는 행을 함께 전송할 필요가 있다. 마찬가지로, 어떤 작업 주문이 다음 날에 수행되어야 하는 이유로, 해당 작업 주문의 수용이 바뀌었다면, 작업 테이블에서 해당 작업을 전달하는 것이 필요할 것이다. 수용 규칙이 관계를 어떻게 고려하는지를 설명하기 위해서 역할의 개념이 소개되었다.

상기 정의된 다양한 역할들은 서로 다른 테이블들 또는 서로 다른 레코드 타입들 사이의 관계를 나타내고, 또한 규칙들을 정의할 수 있게 하고 클라이언트가 동기화되는 때에 정확한 업데이트를 트리거하는 트리거 방법들(trigger methods)을 정의할 수 있게 한다. 상기 다양한 역할들은 테이블들이 서로 각각 연관되는 방식에 따를 수 있고, 그들의 수용이 기 선언된 수용 방법에 의존하는지 여부에 따를 수 있고, 다른 테이블들에 있는 파라미터에 따를 수 있으며, 명백한 선언들에 따를 수 있다. 도 3을 참조하면 이러한 것이 예시되어 있다.

첫 번째 테이블(301)은 스토어 소유주 테이블(store owner table)이다. 이 테이블은 스토어 소유주들의 리스트를 보유할 수 있고, 데이터베이스의 스토어 각각은 소유주 테이블(301)에서 소유주를 참조한다. 본 예시에서는 소유주 테이블은 역할을 가지고 있지 않다는 점에 주목해야 한다. 직접 또는 간접적으로 수용 방법과 연관된 테이블들만이 역할을 가진다. 본 예시에서는 스토어 소유 테이블(301)과 연관된 수용 방법이 없다.

두 번째 테이블은 스토어 테이블(302)이다. 스토어 테이블은 그 이름에서 알 수 있듯이 테이블의 행(row) 각각이 특정의 스토어를 나타낸다. 본 예에서 스토어 테이블(302)는 연관된 수용 방법을 가지는 테이블이다. 이는 곧 클라이언트가 데이터베이스와 동기화되는 때, 해당 클라이언트에 대한 필터에 의해서 스토어가 승인되거나 또는 거부되는지 여부에 따라서, 데이터가 해당 클라이언트에게 전송되거나 전송되지 않을 수 있음을 의미한다. 수용 방법이 적용되는 테이블은 마더 테이블(mother table)로 나타낸다. 따라서 마더는 수용 방법이 직접적으로 작용하는 레코드 타입의 역할이다. 수용 방법은 스토어 소유주(301)와 같이 더 상위 계층의 레코드 타입에서는 적용되지 않는다. 그러나 수용 방법은 직접적으로 연관된 레코드 타입의 하위 트리(sub tree)에서 레코드 타입들에 간접적으로 적용된다.

세 번째 테이블(303)은 스토어 테이블(302)의 수용이 기초로 하는 파라미터들을 보유하는 테이블이다. 이번 예시에서 테이블(303)은 PDA 테이블(303)로 표현되고 PDA 클라이언트 컴퓨터의 리스트를 보유한다. 그러나, 수용 방법은 해당 수용 방법이 동작하는 테이블에 저장된 파라미터에 직접 적용될 수 있다. 예를 들어 스토어 테이블(302)은 어떤 PDA가 스토어에 할당되었는지를 나타내는 값을 보유할 수 있고, 해당 PDA가 동기화되는 때 수용 방법은 행(예를 들어 해당 스토어)을 수용하도록 설계될 수 있다.

테이블(303)의 PDA 레코드 타입은 스토어 레코드 타입과 비교하여 차일드(child)에 해당하고, 이는 또한 파라미터 보유자(parameter holder)이다. 본 발명의 이론과 일관되게, 파라미터 보유자는 미연관(unrelated)일 수 있다(예를 들어 파라미터 보유자는 그들이 파라미터로 작용하는 레코드 타입들에 대해서 차일드일 필요가 없다). 이러한 경우 파라미터 보유자는 테이블 내 모든 행들(rows)에서 동일한 효력이 있을 것이다. 따라서 파라미터 보유자는 예를 들어 수용에 대응하여 테이블을 on 또는 off하도록 작용할 수 있다. 물론, 수용 방법은 추가적인 파라미터들을 가질 수 있고, 그에 따라 수용은 테이블 내 모든 행들에서 동일한 효력이 있을 필요가 없다.

네 번째 테이블은 스토어_물품 테이블(304)이다. 스토어_물품 테이블(304)은 예를 들어 특정 시간에서 어떤 물품이 스토어 테이블(302)의 다양한 스토어들에 있는지에 관한 정보를 포함할 수 있고 또한 각 스토어가 얼마나 많은 물품의 아이템들을 보유하고 있는지에 관한 정보를 포함할 수 있다.

물론 동일한 물품을 스토어별로 여러 번 입력하는 것은 불편할 수 있다. 따라서 물품 각각은 별도의 테이블인 물품 테이블(305)에서 한 번만 나열된다. 이는 데이터베이스를 소위 제 2 정규 폼(Second Normal Form)으로 만든다.

테이블(304)의 스토어_물품 레코드 타입은, 테이블(303)의 PDA 레코드 타입과 마찬가지로, 테이블(302)의 스토어 레코드 타입에 대해서 차일드(child)이다. 더욱이, 스토어_물품 레코드 타입은 테이블(305)의 레코드 타입에 대해서 선(son)이고, 역으로 테이블(305)의 레코드 타입은 상기 스토어_물품 레코드 타입에 대해서 파더(father)이다. 물품 테이블(305)는 그 전부가 클라이언트로 전송될 수 있다는 점에 주목해야 한다. 본 실시예에서 채택된 용어에 따르면, 제한되지 않은 테이블은 파더(father)가 아니다. 대신에, 파더는 반드시 선언되어야 한다. 선언된 파더는 선(son)에 의해서 제한을 받고, 선은 마더(mother)에 의해서 제한을 받는다. 본 발명의 일 실시예에 따르면, 레코드와 연관된 수용 방법이 없고 연결된 레코드들에 의해서 제한되지 않으면 디폴트로 해당 레코드가 수용된다. 다른 실시예들에 따르면, 디폴트는 수용 방법에 의해서 또는 연결된 레코드에 의해서 트리거됨으로써 레코드들이 명백하게 수용되지 않는 경우 레코드들이 수용되지 않는 것이다.

또한, Product Total(306)으로 부르는 추가 테이블이 정의된다. 예를 들어 Product Total은 물품 테이블(305)에 저장된 각각의 물건에 대한 스토어 총 판매를 저장한다. 상기 Product Total(306)은 물품(305)의 비제한 하위 멤버(non-restrictive subset member)이고, 시스터(sister)의 역할을 가진 것으로 정의된다. 따라서 store_article(304)의 경우에서 상기 선(son) 내에서 데이터베이스 발생 변경(database occurrence changes)이 상기 시스터에게 영향을 미치고, 상기 선(son)은 상기 시스터에게 브러더(brother)의 역할을 한다.

또한 판매(Sale)(307) 및 구매(Purchase)(308)로 참조되는 두 개의 추가 테이블이 도 3에 나타나있다. 예를 들어, 상기 판매 테이블(307)은 스토어에서 만들어진 각각의 판매를 저장할 수 있고, 상기 구매 테이블(308)은 물품으로 스토어에 재공급된 각각의 구매로 저장될 수 있다. 이러한 테이블들의 레코드 타입은 테이블(304)의 스토어_물품 레코드 타입에 대해 차일드(chile) 역활을 한다.

수용(acceptance)은 로그 내 적절한 값 검사를 통해서 결정된다. 특정 레코드를 위한 입력 또는 테이블 행(table row)은 레코드 또는 행(record or row)의 인스턴스(instance)로 참조될 것이다. 동기화할 때, 두 개의 세트 값, 즉 주기 △t의 시작의 시점이나 그 바로 전에 저장된 레코드와 주기 △t의 종료의 시점이나 그 바로 전에서의 대응하는 값에 관심 있다. 이 값들은 대부분의 경우에 주기 △t의 시작 전의 레코드에 대한 가장 최근 로그 엔트리 및 주기 △t 내에 동일 레코드에 대한 최근 로그 엔트리로서 발견될 수 있다. 이 두 개의 인스턴스(instance)는 한 쌍으로 참조될 것이다.

일관된 본 발명의 사상에 일치하도록, 두 개의 다른 이슈가 고려될 수 있다. 첫번째 이슈는 한 쌍의 인스턴스(instance)에 대한 수용을 결정하는 것이다. 다른 이슈는 두 개의 인스턴스의 수용에 기초하여 상기 한 쌍이 클라이언트를 업데이트할 것인지 여부를 결정하는 것이다. 기간 수용(term acceptance)은 특정 수용(즉, 특정 레코드 값 세트는 특정 시간 포인트와 연관된다)이 클라이언트에 있는지 또는 제공되어야 하는지 여부를 참조할 동안, 한 쌍이 클라이언트를 업데이트해야 하는지 여부의 결정은 필터링으로서 참조될 것이다. 만약 한 쌍이 필터를 통과하거나, 또는 필터가 한 쌍에 대해 'true'를 리턴하면, 상기 한 쌍은 클라이언트를 업데이트한다. 한 쌍이 필터를 통과한 사실은 새로운 레코드가 삽입되거나, 현행 레코드가 새로운 값으로 업데이트 되거나 또는 현행 레코드가 클라이언트로부터 삭제됐다는 것을 의미한다. 인스턴스에 대한 수용은, 인스턴스가, 수용되지 않은 다른 레코드 타입 인스턴스에 의해 제한되는지(즉, 차일드(child)가 수용되지 않는 마더의 차일드인지 여부), 또는 수용이 사용자 정의 수용 방법에 의해 결정될 수 있는지 여부를 결정함으로써 결정된다. 사용자 정의 수용 방법에 의해 검사된 값은 해당 수용 방법을 위한 파라미터로 정의되는 인스턴스의 값이다.

한 쌍이 필터를 통과하였는지 여부를 결정할 때, 두 개의 인스턴스에 대한 수용이 결정될 수 있다. 본 발명의 사상에 일관되도록, 상기 필터에 의해 만들어진 결정의 결과는, 1) 레코드가 △t의 시작 시점 또는 시작 전에 클라이언트에서 수용되었는지, 그리고 2) 레코드가 △t의 종료 시점 또는 종료 직전에 클라이언트에서 수용되었는지 중 적어도 어느 하나의 결정에 근거할 수 있다.

상기 두 질문은 네 개의 다른 결과를 도출할 수 있다. 만약 두 질문 모두 부정으로 답이 되면, 상기 레코드는 앞선 동기화에서 수용되지 않았고 지금 수용되지 않는다. 결과적으로, 상기 한 쌍은 상기 필터를 통과할 수 없다. 만약 1번 질문에 대한 답이 yes이고 2번 질문의 답이 no이면, 레코드는 수용되었고 이미 클라이언트에게 제공된 것으로 추정되나, 더 이상 수용되지 않는다. 그래서, 클라이언트에게 이미 제공된 엔트리는 제거되고, 수용 변경은 레코드가 클라이언트로부터 삭제된 것을 의미한다. 이러한 과업을 수행하기 위해, 상기 한 쌍은 상기 필터를 통과하도록 허락되어야 한다. 역으로, 만약 1번 질문의 답이 no이고 2번 질문의 답이 yes이면, 상기 레코드는 클라이언트 데이터베이스에 삽입된다(INS). 다시 이것은 상기 필터를 통과해야 한다. 마지막으로, 만약 두 질문이 긍정으로 답이 되면, 서버에서 레코드의 값에 대한 어떠한 변경은 또한 클라이언트에 관련있고, 상기 한 쌍은 필터를 통과한다. 정확하게 어떻게 이러한 프로세스가 본 발명의 실시예에서 다루어질 것인지 차후 자세히 설명될 것이다.

어떤 경우에는, 수용는 다른 테이블의 행에서 발견되는 파라미터에 근거한 마더를 위해 결정될 수 있다. 이런 테이블은 도 3에 PDA 테이블(303)로 예시된 파라미터 보유자로서 참조될 것이다. 다른 테이블에 저장되어 있는 파라미터로부터 결정된 수용은 마더의 수용에 근거한 파라미터로 참조될 것이다.

연관된 수용 방법이 없는 레코드에 대해, 수용은 다른 레코드 검사에 의해 결정될 수 있다. 예를 들어, 구매 테이블(308)의 행에 대한 수용을 결정하기 위해, 수용은 반드시 스토어_물품 테이블(304)의 참조 행에 대해 결정되여야 한다. 만약 구매 테이블의 행이, 예를 들어 외래 키 제약에 국한되면(즉, 스토어_물품을 참조하는 구매 행에서 외래 키 참조가 있다면), 구매는 오직 참조된 스토어_구매 행이 수용될 경우 클라이언트에서 수용될 수 있다. 그렇지 않으면, 참조 무결성(referential integrity)은 준수되지 않는다. 스토어_물품 테이블(304)에 대해 정의된 수용 방법이 없으므로, 유사한 결정은 스토어_물품 테이블(304)의 행에 의해 참조된 스토어 테이블(302)의 행을 검사함으로써 만들어진다. 그 결과 로그에서 반복 룩업(recursive look ups)을 만드는 것이 필요할 수 있다. 로그 검색의 효율은 로그 인덱싱 및 각 테이블에 대해 로그를 분리 로그로 세그멘팅함으로써 증가될 수 있다.

역할 개념은 변경되지 않은 발생이 어떻게 그리고 언제 다른 데이터베이스에 다른 변화의 결과로서 트리거 되는지에 관한 규칙 정의를 가능하게 한다. 클라이언트에서 정확한 부분 데이터베이스를 유지하기 위해, 모든 제약을 준수하는 동안, 클라이언트에 있거나 있지 않은 모든 레코드는 적절히 동기화 된다. 연관된 수용 방법을 갖는 레코드, 즉 마더 레코드는 클라이언트에서 부분 데이터베이스의 스코프를 조합하여 정의하는 레코드이다. 왜냐하면, 수용 방법과 연관되지 않은 레코드에 대한 수용은 테이블 및 수용 방법, 즉 마더와의 관계에 의존하기 때문이다.

만약 수용이 수용 방법, 즉 마더을 갖는 레코드에 대해 변경되었다면, 수용은 모든 그의 차일드, 즉 그 마더의 하위 트리 내의 모든 레코드를 트리거한다. 로그는 직접적으로 테이블 행 같은 레코드가 특정 시간 포인트에서 어떤 클라이언트의해 허용되는지 여부 답을 제공하지 않는다. 만약 레코드가 수용 방법을 가지고 있으면, 로그된 값 또는 방법에 파라미터인 값, 이 레코드 자체를 나타내는 행의 값 이나 파라미터 보유자 테이블의 검사를 통해서 결정할 수 있다. 만약 레코드가 허용 방법을 가지고 있지 않다면, 허용은 레코더 마더를 위한 결정될 것이다.

도 3에 도시된 예시에서, 마더 테이블은 PDA 테이블(303)에 저장된 파라미터에 근거하여 수용될 수 있다. 만약 PDA 테이블(303)로부터 페치된 파라미터를 갖는 스토어 테이블(302)에서 동작하는 수용 방법이, PDA 테이블(303)에서의 엔트리에 만들어진 변화 때문인 것으로 결정하면, 스토어 테이블(302)로부터의 특정 레코드 발생은 지금 특정 PDA에 수용되고, 스토어 테이블(302)로부터 관련된 스토어 뿐만 아니라, 테이블의 하위 트리로부터의 모든 관련 행을 추가할 필요가 있다. 모든 데이터베이스 제약이 준수될 수 있다. 전형적으로 이것은, 더 이상 수용되지 않는 스토어를 참조하는 물품으로서 테이블(304)에 입력된 모든 스토어_물품이 더 이상 참조 완결성을 유지하기 위해 수용될 수 없다는 것을 의미한다. 유사하게, 클라이언트에서 지금 수용된 스토어를 참조하는 스토어_물품은 또한 수용될 것이다. 게다가, 물품 테이블(305)에서 발견되는 이러한 물품의 모든 설명이 또한 입력될 것이다. 본 발명의 어떤 실시예에 따르면, 파더 테이블로 참조되는 물품 테이블(305) 같은 테이블의 엔트리는, 참조 선(son) 테이블(이 경우 스토어_물품 테이블(304))로부터 만들어진 참조에 기초하여 수용될 수 있다. 본 명세서에서 채택된 용어에 따르면, 파더 테이블은 이것과 연관된 수용 방법을 가질 수 없다는 점을 주목해야 한다. 만약 그렇다면, 이것은 마더 테이블이 된다.

게다가, 스토어_물품 테이블(304), 판매 테이블(307) 및 구매 테이블(308)의 차일드(child)는 클라이언트에 추가되고(또는 삭제될 수도 있음) 또한 아이템 토탈 테이블(306)에 추가될 수 있다.

트리거 프로세스에서, 상기 파라미터 보유자 발생(parameter holder occurrences)은 마더 테이블 스토어의 행을 트리거하고, 스토어 테이블 트리거 내의 트리거된 행은 차일드 테이블 스토어_물품의 행을 트리거하며, 스토어_물품 테이블의 트리거된 행은 판매 및 구매 테이블의 그들 자신의 차일드를 트리거한다.

이 예제는 상기 마더 테이블이 파라미터 보유자 테이블 내 파라미터에 근거하여 결정된 그것의 수용을 가진 것으로 추정하는 동안, 그 테이블은 또한 테이블 자체 내의 컨텐츠에 기초하여 필터링될 수 있다. 예를 들어, 스토어 테이블(302)은 PDA로 불리는 컬럼을 가질 수 있고, 컬럼에 입력된 특정 PDA는 레코드가 클라이언트에게 수용되는지 아닌지 결정할 수 있다.

이제 트리거링의 개념으로 향할 것이다. 이미 언급되었듯이, 트리거링은 레코드에 만들어지는 변경에 의존할 필요가 없다. 레코드는 또한 수용에서의 변경 때문에 트리거드 △ 내에서 포함될 수 있다. 트리거된 발생은 시간 주기 △t동안 변경되지 않은 그러나 현재 동기화되는 클라이언트에 대해 변경된 수용을 갖는 레코드를 나타내는 한 쌍이다.

본 발명에 따른 증분 동기화 동안 데이터베이스의 다른 관련된 부분을 도시한 도 4를 참조한다. 도 4A에서, 데이터베이스의 전체 스코프는 영역 400으로 표시되어 있다. 데이터베이스(400)의 제 1 서브셋(410)은 두 개의 연속되는 동기화 사이에서 변경된 데이터 레코드(예; 테이블 행)를 나타낸다. 이것은 데이터베이스 △로 참조된 것이다. 데이터베이스(400)의 제 2 서브셋(420)은 외부 변수의 결과로 변경된 그들의 수용을 갖는 레코드를 나타낸다. 마지막으로, 데이터베이스(430)의 제 3 세브셋은 다른 레코드 즉, 다른 레코드 내 변경의 결과로서 변경된 그들의 수용을 갖는 레코드에 의해 트리거된 레코드를 나타낸다.

이러한 셋들은 오버랩될 수 있다고 것을 알 수 있다. 예를 들어, 작업 주문은, 수용되지 않을 때 제 1 동기화에 앞서 입력되고, 이어지는 동기화 전에 변경되어서 서브셋(410)에 속하고, 외부 변수의 결과로서 클라이언트에게 수용될 수 있게 된다. 유사하게, 마더에 의해 트리거된 그래서 서브셋(430)에 속한 차일드는 또한 변경될 수 있고, 그래서 서브셋(410)에 속한다. 그러나, 동일 레코드를 수차례 프로세스하는 불편함이 있을 수 있다. 그러므로, 도 4B에 나타나 있듯이, 본 발명의 어떤 실시예에는 데이터베이스 △는 변경된 411를 갖는 모든 레코드로 정의되고, 외부 변수에 대한 대상이기 때문에 수집된 레코드는 해당 레코드들이 이미 데이터베이스 △의 일부가 아니면 서브셋(421)에서 수집되고, 그리고 레코드들이 변경되지 않고(즉, 서브셋(411)에서 변경되지 않는 것) 외부 변수로부터의 수용 변경에 대한 대상이 아닌 경우(즉, 서브셋(411)에서) 해당 레코드들은 서브셋(431)에 포함되고 오직 다른 레코드들에 의해 트리거된다.

도 5를 참조하면, 본 발명에 따른 방법 흐름도가 도시되어 있다. 프로세스는 초기 단계(500)에서 시작한다. 그리고 다음 단계 501에서, 동기화하는 클라이언트에서 만들어진 모든 변경, 삽입 또는 삭제가 수신될 수 있다. 이 것들은 데이터베이스에 적용될 수 있고 동기화의 시작에 앞서 데이터베이스 로그에 포함된다. 이미 언급하였듯이, 클라이언트로부터 수신된 변경은 일반적으로 동기화 동안에 클라이언트에게 리턴되지 않을 것이나 이 규칙에 예외가 있을 수 있다.

그리고, 프로세서는 데이터베이스 내 모든 변경이 수집되는 단계 502로 이동한다. 이 절차는 도 4B에 서브셋(411)으로 도시된 데이터베이스 △를 생성한다. 수집된 변경은 단계 503에서 트리거 리스트에 추가된다. 본 발명이 이러한 측면에 한정되는 것은 아니며, 상기 변경은 이후 자세히 설명될 트리거 리스트에 쌍으로 입력될 수 있다. 일 실시예에서, 상기 변경은 오직 한 번 입력될 수 있다. 예를 들어, 삽입된 또는 삭제된 레코드는 트리거 리스트에서 오직 하나의 INS 또는 하나의 DEL로서 입력될 수 있다.

다음 단계 504에서, 상기 데이터베이스는 외부 변수로부터 변경된 그들의 수용을 가지는 레코드를 식별하기 위해 브라우징된다. 예시는 상술된 특정 시간 포인트에서 변경된 수용을 갖는 레코드를 포함할 수 있다. 도 4B에서 서브셋(421)로서 도시된 수용 △의 일부인 이런 변경은 단계 505에 도시된 바와 같이 트리거 리스트에 추가된다.

단계 506에서, 상기 트리거 리스트 내 엔트리는 관련된 쌍을 트리거할 것이고 수용 변경을 위해 연구될 것이다. 도 4B의 서브셋(431)에 대응하는 트리거된 쌍은 트리거 리스트에 추가될 것이며, 프로세스는 트리거 리스트에 새로운 트리거가 없을 때까지 반복하여 진행된다. 이러한 프로세스는 이하 도 6을 참조하여 설명한다.

트리거 프로세스가 완료될 때, 필터링은 트리거 리스트 내 모든 쌍에 대해서 수행되고 실제 동기화는 단계 507에서 시작된다. 그리고 본 방법은 단계 508에서 종료한다.

도 5를 참조하여 상술된 상기 방법이 독립된 단계의 순서로 설명된 반면, 설명된 특정 단계의 순서는 이해의 편의를 위해 선택된 오직 하나의 가능성인 것으로 이해되어야 한다. 예를 들어, 수집 단계는 단계 502에서 데이터베이스 로그로부터 변경하고 수집된 변경을 트리거 리스트에 추가하는 단계는 두 개의 연속되는 단계로 설명된다. 그러나, 변경은 그것들이 수집될 때 리스트에 입력될 수 있고 각 시간에서 변경은 상기 방법이 데이터베이스 로그 내 다음 변경에 위치하기 위해 이동하기 전에 트리거 리스트 내 기록될 수 있는 데이터베이스 로그로 발견된다. 또한, 트리거 전에 모든 변경을 수집할 필요는 없다. 예를 들어 더 작은 청크로 클라이언트에게 데이터를 전송하는 것이 요구될 수 있고, 데이터베이스 △로부터 이러한 소정의 수의 변경된 쌍을 얻기 위해 그들 각각의 하위 트리의 모든 관련된 쌍을 트리거하도록 사용될 수 있고, 다음의 소정의 개수의 트리거로 이동하기 전에 이러한 쌍을 동기화한다. 그러므로, 한 측면에서 제 1 변경된 쌍을 수집하고, 이러한 제 1 변경된 쌍에 의해 트리거된 모든 쌍을 찾으며, 필터링을 수행하고 데이터베이스 △ 내 다음 변경된 쌍으로 이동하기 전에 클라이언트에게 관련된 변경을 전송하는 것이 가능하다. 다른 측면에서, 모든 변경은 처음 수집되고, 그리고 모든 것은 모든 수집된 변경에 근거하여 트리거되며, 그리고나서 필터링은 모든 수집되고 트리거된 쌍에 대해서 수행되며, 마지막으로 모든 관련된 업데이트는 상기 클라이언트에게 전송된다.

또한, 외부 변수에 의해 변경된 레코드를 식별하는 단계 504와 그것들을 트리거 리스트에 추가하는 단계는 변경된 레코드의 수집 전에 수행될 수 있다.

도 5의 다양한 단계를 더 상세히 설명한다.

클라이언트가 서버로부터 연결되지 않은 동안 클라이언트에 만들어진 모든 변경을 서버 데이터베이스에서 수신하는 단계는, 어떠한 때라도 어느 클라이언트로부터 데이터베이스에 만들어진 모든 변경을 처리하는 것을 가능하게 한다.

단계 501에서 클라이언트로부터 수신된 레코드는 변경된 레코드를 수집하고 서버에 데이터베이스 △를 만드는 프로세스와 유사한 프로세스로 클라이언트에서 수집된다. 그러나, 모든 레코드는 서버에 존재하고 모든 변경은 서버로 보내지기 때문에, 레코드를 필터링할 필요는 없고, 그러므로 또한 트리거된 발생을 식별할 필요가 없다. 클라이언트는 단순히 상기 서버에 전체 데이터베이스 △를 보낸다.

클라이언트로부터 레코드를 수신한 후, 그것들은 데이터베이스에 삽입되거나, 데이터베이스로부터 삭제되거나, 데이터베이스에 업데이트될 수 있다. 이러한 삽입 및 업데이트는 데이터베이스와의 다른 상호작용으로 취급되고, 데이터베이스의 로그에 입력된다. 이미 언급하였듯이, 특정 클라이언트로부터 수신된 업데이트는 일반적으로 클라이언트에게 되돌려지지 않으나, 특정 상황에서 예외가 요구될 수 있다.

단계 502에서, 주기 △t에서 데이터베이스에 만들어진 변경은 수집된다. 이것은 방법 또는 DBMS의 일부인 서브루틴에 의해 수행될 수 있다. 이 방법은 CollectRecords로 참조될 것이다. 상기 CollectRecords 방법은 t₀ 및 t₁에서 다른 값을 갖는 모든 레코드를 발견하기 위해 주기 △t 동안 로그를 검사한다. 여기서 t₀는 특정 클라이언트의 이전 동기화를 위한 시간 포인트로서 참조되고, t₁은 이번 동기화를 위한 시간 포인트로 참조된다. 다른 말로, △t는 t₀부터 t₁까지의 시간 주기를 나타낸다. t₀ 및 t₁에서 다른 값을 갖는 것으로 식별된 모든 레코드들은 트리거 리스트에 추가된다. 만약 t_i에서 모든 값이 그들이 t₀에서 가지는 값으로 리턴된다면 주기 △t동안 수차례 변경된 레코드를 추가하는 것이 불필요하다는 점을 주목해야 한다. 본 발명의 일관된 사상에서, 레코드는 트리거 리스트에 쌍으로서 추가된다. 쌍의 하나의 예(instance)는 t₀ 시점에서의 레코드를 나타내고, 다른 예는 t_i 시점에서의 레코드를 나타낸다. 일 실시예에서, 레코드의 모든 값은 쌍의 두 예를 모두 포함한다. 다른 실시예에서, 모든 값은, 오직 차이점이 다른 레코드에 포함되는 동안, 상기 예의 하나에 포함된다. 또 다른 실시예에서, 두 예 모두 오직 변경된 값을 포함한다. 만약 선행 값이 요구되면 그것들은 로그로 돌아가 위치될 수 있기 때문에, 원칙적으로 트리거 리스트 내 시간 t_i 동안 업데이트된 값만 포함하는 것이 가능하다.

단계 502에서 수집되고 단계 503에서 트리거 리스트에 입력된 변경은 데이터베이스 △를 나타낸다. 일 실시예에 따르면, 데이터베이스 △에 속하는 모든 레코드들은, 그것들이 동기화되는 특정 클라이언트에 관련되어 있든 그렇지 않든 그리고 수용이 트리거 프로세스 동안 또한/및 최종 동기화 동안 결정되든 그렇지 않든, CollectRecords 방법에 의해 트리거 리스트에 추가된다. 그러나 일관된 본 발명의 사상은 데이터베이스△ 내 각 쌍의 예(인스턴스)에 대한 수용을 결정하고, 쌍의 수용 또는 수용 변경이 클라이언트에 관련되어 있다면 해당 쌍은 트리거 리스트 내에 오직 추가된다는 점이다.

△t 동안 어떠한 값도 변화되지 않고 그러나 일부 외부 요인 때문에 그들의 수용 변경을 갖는 레코드를 식별하기 위해 데이터베이스를 브라우징하는 단계 504와, 그리고 단계 505에서 트리거 리스트에 쌍으로서 식별된 레코드들의 엔트리는 DBMS의 일부인 방법 또는 서브루틴에 의해 수행될 수 있고, BrowseExternalAcceptanceChange로 참조 된다. 이 방법은 시간의 흐름의 결과와 같은 데이터베이스 자체에 대한 외적인 일부 결정 요인의 결과로서 동기화된(또는 대안으로 다른 클라이언트에게) 클라이언트에 연관되어 변경된 그들의 수용을 가지는 레코드를 식별한다. 선행 동기화 때문에 수용이 변경된 레코드를 식별하기 위해, 선행 동기화에 외부 변수 값의 상태를 알 필요가 있다. 정의 추적에 의한 로그는 내부 데이터 베이스 값을 변화시키기 때문에, 이 값은 로그로부터 직접적으로 이용 가능하지 않을 수 있다는 점을 알 수 있다. 그러므로 예를 들어 분리 로그에서 그러한 외부 값의 추적을 유지할 필요가 있을 수 있고, 이것은 외부 수용 방법에 연관된 타입을 가진 모든 레코드에 적용될 수 있다.

이 방법에 의해 식별된 레코드는, 같은 데이터베이스 △의 쌍으로서 동일한 트리거 리스트에 쌍으로 추가되기 때문에, 그리고 레코드들은 그들의 값이 △t 동안에 변경되게 하기 때문에 이미 트리거 리스트에 추가된 레코드를 식별할 필요가 없다. 결과적으로, 본 발명의 일 측면에 따르면 이 방법은 오직 △t 동안에 변경되지 않고 그들의 수용이 변경된 레코드들만 식별한다. 대안으로, 상기 방법은 외부 이유에 의해 수용이 변경된 모든 레코드를 식별하고, 트리거 리스트에 그것들을 쌍으로 추가한다. 이 경우 같은 레코드에 대한 중복 트리거를 피하기 위해 트리거 리스트에서 복사를 제거하는 것이 필요하다.

BrowseExternalAcceptanceChange 방법은 CollectRecords 방법 이전에 수행될 수 있고, 이 경우에 CollectRecords 방법은 적어도 하나의 값이 변경되고 그것의 수용이 변경되지 않은 레코드만을 포함하도록 구성될 수 있다. 이는 후자가 이미 트리거 리스트에 존재할 수 있기 때문이다.

BrowseExternalAcceptanceChange에 의해 식별된 레코드는 t₀ 및 t₁ 동안 입력된 동일 값을 갖는 업데이트로서(UPD) 트리거 리스트에 추가될 수 있다. 그러나 t_i동안 삽입(INS) 또는 삭제(DEL)로 오직 한 번만("half" 쌍으로서) 레코드를 입력하는 것이 일관된 본 발명의 사상이다.

프로세스는 이제 트리거 리스트에 리스트된 쌍, 즉 트리거 리스트에 리스트된 쌍의 직접적 결과로서 클라이언트에게 전송되어야할(또는 클라이언트로부터 삭제되는) 쌍에 의해 쌍이 트리거되는 단계 506으로 이동한다. 이런 레코드는 트리거된 쌍 또는 트리거된 발생으로 참조될 수 있고, 그들의 식별하는 데 사용되는 방법은 TriggerOnRecords로서 참조될 것이다.

본 발명의 일 측면면에 따르면, 트리거된 발생은, BrowseExternalAcceptanceChange 방법에 의해 식별되는 레코드가 있으나, 값에 대한 변경의 결과 또는 다른 레코드들에 대한 수용, 즉 트리거 리스트 내의 엔트리들의 결과인 수용으로서 어느 클라이언트에 대해 그것의 수용이 변경되는 케이스로서, △t 동안 변경되지 않은 쌍일 수 있다. 이런 레코드를 식별하는 프로세스는 트리거링으로 참조될 것이고, 식별된 레코드는 트리거된 쌍 또는 트리거된 발생으로 참조될 것이다.

△t 동안 그들의 값을 변경하지 않은 그러나 외부 변수 또는 그들이 트리거되어서 트리거 리스트에 추가된 쌍은, 두 개의 쌍의 인스턴스에 대해 동일한 값을 갖는 업데이트(UPS)로서 트리거 리스트에 추가될 수 있다. 모든 정보는 언제든 로그로부터 회복될 수 있기 때문에, 본 발명은 이러한 실시예에 제한되지 않고, 어떠한 실시예에서 업데이트로서 변경되지 않은 레코드를 추가하는 것은, 데이터베이스 △로부터 쌍을 대해 디자인된 방법을 재사용하는 것을 가능하게 한다. 이러한 것은 이하에서 이해될 것이다. 단계 507에서 데이터베이스 △로부터의 쌍에 대한 필터 상태를 결정할 때, DEL의 결과로서 수집된 어느 쌍은(즉, 서버 데이터베이스에 존재하는 그러나 t_i 전에 지워진 레코드), t_i 동기화 때 클라이언트로부터 삭제되거나, t₀ 때 수용되는 경우, 또는 t₀ 때 수용되지 않고 t_i에서 동기화하는 동안 무시될 수 있기 때문에 제 1 플레이스에서 클라이언트에 존재하지 않게 된다. 비슷하게, 새로운 INS로서 수집되는 어느 쌍은 t₀에는 데이터베이스에 존재하지 않았지만 t₁에는 존재하고, 이는 클라이언트에 삽입되거나(t_i 때 수용된다면) 또는 무시될 수 있다(t_i 때 수용되지 않으면)는 것을 의미한다.

그러나, 데이터베이스 △로부터의 쌍이 UPS로 리스트 되면, 이것은 레코드가 t₀에 존재하고(또한 t₀ 후에 추가되었고 그리고 나서 업데이트될 수 있음), t_i 때 여전히 존재하나 △t 동안에는 그 값이 변경하는 것을 의미한다. 동기화 동안 어떻게 다루어질 것인지 이하 설명된다. 만약 t₀ 때 수용되고 t_i 때도 여전히 수용되면, 업데이트(UPS)로 처리된다. 만약 t₀ 때 허용되지 않고 t_i 때도 여전히 수용되지 않으면, 무시된다. 그러나, t₀ 때 수용되지 않았으나 △t 동안 수용이 변경되어서 t_i때 수용되면, 클라이언트에게 현재 이미 없기 때문에 삽입(INS)로 변경되어야 한다. 비슷하게, 쌍에서의 인스턴스들에 대한 수용이 첫 번째 인스턴스(예)에 대한 yes에서 마지막 인스턴스(예)에 대한 no로 변경된다면, 레코드는 클라이언트에게 업데이트되지 않고 제거되는데 이것은 DEL로 변경을 의미한다. 트리거 리스트에 UPS로 리스트된 쌍만이 이 방법으로 변경하고, 트리거된 레코드는 같은 방법으로 결정된 그들의 수용을 가지고 있어야 하기 때문에, 트리거 리스트에 업데이트로서 트리거된 레코드를 입력하는데 편리하다.

도 6으로 되돌아오면, 단계 506에서 수행된 트리거 프로세스는 이하 더 상세히 설명될 것이다. 이 프로세스는 도 5의 단계 506에 대응하고, 참조는 예시된 다양한 역할이 예시되어 있는 도 3으로 돌아갈 것이다. 다양한 역할에 대한 참조를 위한 상기 용어는 편의를 위해 채택된 것이고, 본 발명을 제한하지 않는다는 것을 알 수 있다. 예를 들어, 역할과 관련된 성별은 상관없고, 레코드 타입은 다른 성별의 다양한 역할을 가질 수 있다. 예를 들어, 레코드 타입은 마더와 선(son) 둘 다 될 수 있다. 본 발명을 설명하기 위한 적절한 다른 용어가 채택될 수 있다.

트리거 프로세스는 DBMS의 일부가 되는 방법 또는 서브루틴에 의해 처리될 수 있고 TriggerOnRecords라고 말할 수 있다. TriggerOnRecords 방법은 첫번째 단계(600)가 개시될 때 입력에 따라 이전 단계에서 생성된 복수의 트리거 리스트를 가져올 수 있다.

첫번째 단계(601)에서, 트리거 리스트의 첫번째 쌍이 검사된다. 이 첫번째 쌍이 검사되는 동안 외부 변수(실시에 따라 종속됨)의 결과로서 리스트에 다른 것이 데이터베이스로부터 전달되거나 포함될 수 있고, 일반적으로, 각각의 트리거는 도 6에 도시된 프로세스의 일부로 트리거될 수 있다.

다음 단계(602)에서 현재 검사되는 트리거 리스트에 있는 쌍이 도 3에 예시된 PDA 테이블(303)과 같은 파라미터 보유자의 테이블로부터 왔는지 결정될 수 있다. 이런 경우, 프로세스가 단계(603)를 실행하여 마더가 트리거된다. 도 3을 참조하여 설명한 바와 같이 관련 수용 방법에 관한 레코드 타입은 항상 마더이고, 파라미터 보유자는 수용 방법에 대한 입력 파라미터들이기 때문에, 마더와 같은 필터링된 레코드 타입을 항상 트리거한다.

상기의 경우는 도 3의 예시로부터 충분히 이해될 수 있다. 파라미터 보유자가 복수의 PDA와 당해 PDA가 배정된 스토어들의 관계의 리스트라면, 상기 관계에서의 변경은 데이터베이스와 동기화될 때 PDA가 수신해야 하는 데이터에 명백하게 영향을 줄 것이다. 마더를 트리거하는 것은 마더 테이블(302)로부터 적어도 하나의 식별된 레코드가 트리거된 레코드의 리스트에 쌍으로 추가되는 것을 의미한다. 트리거된 쌍은 트리거 리스트에 추가될 수 있고, 컬럼 값들은 쌍의 두 개 인스턴스와 동일할 것이며, 따라서 상기 값들은 ㅿt 동안 변경되지 않는다.(만약 마더가 ㅿt 동안 실제로 변경되면 트리거 리스트의 일부가 이미 되었을 것이고, 트리거된 사건들의 리스트에 마더를 추가할 필요도 없다).

하나 이상의 레코드를 마더 테이블로부터 트리거 리스트에 추가하는 것이 필요할 수 있다는 것을 유의해야 한다. 예를 들면, PDA가 제1스토어 STORE01에 t₀ 시점에 배정되고 제2스토어 STORE02에 t₁에 재배정되면, 파라미터 보유자에서 변경에 따라 알 수 있듯이 클라이언트로부터 STORE01을 삭제하고 STORE02를 추가하는 것이 필요할 수 있다. 이어서 STORE01과 STORE02는 모두 트리거되어 트리거 리스트에 UPD로서 추가되어야만 한다. 도 5의 단계(507) 동안에 STORE01이 DEL로 변경되어야만 하고 STORE02가 INS로 각각 변경되어야만 하는 것이 결정될 수 있다. 데이터의 통일성을 유지하기 위해 클라이언트로부터 당해 클라이언트에 대해 더 이상 수용되지 않는 레코드들을 삭제하는 것이 필요할 수 있는 것을 유의해야 한다. 하지만, 데이터베이스 설계자가 수용 불가능한 방식으로 데이터의 통일성 또는 클라이언트의 기억 용량을 해결하지 못한다고 확신한다면 본 발명의 특정 실시예에 따라 클라이언트에 레코드들이 남도록 허용하는 것이 요구된다.

마더 레코드 타입을 추가하는 프로세스는 방법 또는 AddMaterFamilies로 표기되고 파라미터 보유자 리스트로부터 입력 파라미터로 쌍을 가져오는 서브루틴에 의해 처리될 수 있다. 상기에서와 같이, AddMaterFamilies는 테이블로부터 적어도 하나 이상의 쌍을 트리거할 수 있다. 예를 들면, 파라미터 보유자 쌍의 첫번째 인스턴스 값이라서 수용되었던 1개의 레코드가 파라미터 보유자 쌍의 마지막 인스턴스의 값이라서 더 이상 수용되지 않고, 반대로 상이한 레코드가 첫번째 인스턴스에서 수용되지 않았고, 지금 수용된다. 양자 모두 2개의 UPD 쌍으로 트리거 리스트에 추가될 것이고, 업데이트들이 클라이언트로 전송되기 전에 각각은 DEL과 INS로 변경될 것이다.

마더 쌍 또는 다른 쌍들이 트리거 리스트에 적어도 하나 이상의 트리거된 쌍으로 추가된 후, 프로세스는 단계(604)를 실행한다. 유사하게, 단계(602)에서 트리거 쌍이 파라미터 보유자가 아닌 것으로 판단되면, 프로세스는 마더 레코드 타입을 트리거하지 않고 단계(604)를 바로 실행한다.

단계(604)에서 판단되는 쌍이, 예들 들어 쌍이 업데이트 필터를 통과해야만 하는지 여부처럼 쌍이 클라이언트를 업데이트해야만 하는지 여부를 판단하기 위해 추가로 검사된다. 이러한 판단은 동기화되고 있는 각각의 클라이언트에 대한 쌍의 인스턴스들에 대한 수용의 판단에 기초하여 이루어질 수 있다. 이러한 판단은 트리거 쌍이 도 5의 단계(507)의 클라이언트를 업데이트 해야만 하는지 판단하기 위해 사용된 동일한 방법을 이용하여 이루어질 수 있다. 상기 방법은 도 7을 참조하여 이하에서 상세히 후술된다.

단계(604)에서 수행된 수용의 판단은 다음의 결과물들을 가질 수 있다. 쌍의 인스턴스들 어떤 것도 수용되지 않으면, 당해 쌍은 클라이언트를 업데이트하지 않을 것이고 이 쌍에 기초되는 추가 쌍들을 트리거할 필요가 없고, 프로세스는 단계(607)를 실행한다. 하지만, 만약, 적어도 하나의 인스턴스가 수용되면, 쌍은 클라이언트에 대해 변경을 요구할 수 있고, 상기 쌍은 추가로 트리거된다. 이것은 쌍의 필터링이 당해 레코드가 클라이언트에 존재해야만 하는지 여부를 판단하는 것이 아니라 쌍이 클라이언트에 관계되는 변경을 의미하는지 여부를 판단하기 때문이다.

단계(604)에서 레코드가 필터들을 통과하고 클라이언트를 업데이트해야 한다면, 연속되는 스텝(605)에서 쌍이 수용 변경을 갖는 트리거인지 판단되어야만 한다. 쌍에 수용의 변경이 없는 것으로 판단된다면, 더 이상 추가적으로 트리거를 할 필요가 없다. 쌍이 클라이언트를 업데이트하고 있지만, 다른 레코트 타입을 트리거하지 않고 프로세스는 단계(607)를 실행한다. 그 이유는 수용이 변경되지 않았기 때문에 어떠한 변경이라도 레코드에 저장된 값에 있을 수 있고 클라이언트는 상기 레코드의 변경된 값들을 업데이트하는 것에 의해 바르게 업데이트될 수 있다. 이러한 변경들은 레코드 서브 트리상의 어떠한 레코드들도 제한하지 못한다.

반면에, 쌍에 대한 수용이 변경되었다고 판단된다면, 프로세스는 단계(606)를 실행하여, 레코드의 역할에 기초하여, 어떤 다른 레코드 타입들이 트리거되야만 하고 트리거 리스트에 추가되는지 판단된다. 역할에 기초하는 트리거는 이하에서 추가로 설명될 것이다. 역할에 기초하는 트리거가 당해 트리거에 대해 완료된 후, 프로세스는 단계(607)를 실행한다.

단계(607)에서는 지금 처리되었던 쌍이 트리거 리스트의 마지막 쌍인지 여부가 판단된다. 마지막 쌍이 아닐 경우, 프로세스는 다음 단계(608)을 실행하고, 동일 처리가 반복된다. 이러한 처리는 모든 트리거들이 검사되는 단계(607)에서 판단될 때까지 계속되고 프로세스는 단계(609)에서 종료된다.

본 발명의 다른 실시예에 따르면, 2개의 단계(604, 605)는 변형되어 처리될 수 있다. 예를 들면, 단계(605)가 단계(604) 이전에 선행되어 실행된다.

도 5로 되돌아가 보면, 모든 트리거가 단계(506)에서 완료되면, 트리거 리스트상의 모든 쌍들에 대한 필터 상태는 단계(507)에서 결정되어야만 한다. 동일한 과정이 쌍이 클라이언트를 업데이트해야 할지가 결정되는 도 6에 도시된 단계(604)에서 사용될 수 있으며, 상기 과정은 도 7에 의해 이하에서 상세히 설명된다. 하지만, 단계(604)의 트리거 실행 동안에 수행된 방법과 단계(507)의 동기화 실행 동안에 수행된 방법에는 한 가지 차이점이 있다. 각각의 수용이 쌍의 양쪽 인스턴스들에 대해 거짓이면 레코드들이 동기화 프로세스와 무관하다는 것이 판명될 것이다. 쌍이 리스트에 DEL 또는 INS로 추가된다면, 예를 들어 데이터베이스의 레코드에 변경이 삭제 또는 삽입이라면, 상기 레코드는 클라이언트에 대해 삭제되거나 또는 삽입되어야만 하는 것으로 결정될 것이다. 그러나, 쌍이 리스트에 UPD로 추가된다면, 추가적 결정들이 필요하게 된다. 이것은 어떻게 트리거된 쌍들이 리스트에 UPD로 추가될 수 있는지 상기에서 간략히 설명되었다. 이러한 추가적 판단들의 결과는 UPD로 추가된 쌍들은 INS 또는 DEL로 변경되어야만 하는 것이다. 이것은 단계(604)의 트리거 과정 동안 실행될 것이 아니라 단계(507)의 동기화 과정 동안 실행되어야만 할 것이다.

아래의 코드는 쌍들의 필터링을 예시하며, 레코드가 클라이언트로 삽입, 삭제 또는 업데이트되어야 하는지 판단된다. 상기 코드는 2가지 작업을 충족시킨다. 첫번째 작업은 쌍이 클라이언트를 업데이트해야 하는지 여부가 판단되는 것으로서, 업데이트해야 한다면 'true'의 리턴값이 되고 업데이트하지 말아야 하면 'false'의 리턴값으로 된다. 나머지 다른 작업은 필요에 따라서 UPD를 INS 또는 DEL로 변경해야 하는지이다.

도 7은 상기 예시된 코드에 의해 실행되는 방법을 도시한다. 상기 방법은 도 7A의 개시 단계(700)에서 시작되어 쌍의 첫번째와 마지막 인스턴스에 대해 수용이 판단되는 단계(701)를 실행한다. 만약, 쌍이 마더 또는 차일드라면, 수용은 이하의 도 8을 참조하여 설명된 방법에 의해 판단될 수 있다. 쌍이 파더라면, 수용은 도 9를 참조하여 설명된 방법에 의해 판단될 수 있다. 본 발명의 또 다른 실시예에 따르면, 먼저 쌍의 레코드 타입의 역할을 판단하는 것보다 양쪽 방법들이 실행되고, 인스턴스가 포지티브 수용을 갖도록 양쪽에서 포지티브 수용의 결과를 내는 것이다.

상기 방법은 단계(702)에서 쌍이 INS 명령에 해당하는지 판단한다. INS 명령일 경우, 상기 쌍의 마지막 인스턴스가 수용되지 않으면, 단계(703)의 판단에 따라서, 상기 방법은 단계(704)의 필터링에 대해 'false' 값을 리턴한다. 마지막 인스턴스가 수용되면, 상기 방법은 단계(705)의 필터링에 대해 'true' 값을 리턴한다. 이것은 쌍이 INS로 등재되고 쌍에서 마지막 인스턴스에 대한 수용이 'true'이면, 필터를 통과해야만 하고 클라이언트로 삽입된다. 현재 수용되지 않으면, 무관한 것으로서, 상기 방법은 'false'를 리턴한다. 편의상 쌍은 두개의 동일한 인스턴스로 나타낼 수 있다. 대안적으로, 삽입은 설계상의 선택에 따라 1개의 인스턴스만 해당되는 "half" 쌍으로 나타낼 수 있다.

쌍이 단계(706)에서 판단되어 DEL이면, 상기 방법은 단계(707)를 실행한다. 단계(707)에서 쌍의 첫번째 인스턴스가 클라이언트에서 수용되지 않은 것으로 판단되면, 상기 방법은 단계(708)의 필터링에서 'false'를 리턴한다. 그렇지 않으면, 상기 방법은 'true'를 리턴한다. 이것은 쌍이 DEL로 등재되고 쌍의 첫번째 인스턴스에 대한 수용이 'true'이면, 이미 클라이언트에 존재하는 것이고, 삭제되어야만 하기에 서버의 데이터베이스로부터 삭제된다. 따라서, DEL은 삭제로 남는다. 이러한 예는 DEL과 INS 경우에 대한 "half" 쌍일 경우의 실시예가 어떻게 충분할 수 있는지를 나타내며, 도 7의 방법은 이들 경우의 쌍의 인스턴스들 중에 하나를 고려하기만 하면 된다.

상기 쌍이 UPD로 등재된 경우에 있어서, 단계(710)의 판단에 따라서, 상기 업데이트는 도 8B에 도시된 바와 같이 처리되어야 한다. 상기 업데이트는 다음과 같이 처리된다. 단계(712)에서 쌍의 양쪽 인스턴스들이 클라이언트에서 수용되었는지 판단되고, 이것은 레코드가 이미 클라이언트에 존재하고 남아있다는 것을 의미한다. 때문에, 서버에서 처리된 것처럼 클라이언트에서 동일한 업데이트를 하는 것이 필요하고, 상기 UPD가 유지된다. 상기 방법은 단계(713)에서 필터링에 대해 'true'를 리턴한다; 상기 쌍은 클라이언트를 업데이트해야 한다. 단계(714)에서 상기 쌍의 첫번째 인스턴스가 수용되는 것으로 판단되면, 마지막 인스턴스는 수용되지 않으며, 이것은 레코드는 클라이언트에 존재하지만, 더 이상 있지 않음을 의미한다. 결국, 상기 쌍은 단계(715)에서 UPDATE에서 DELETE로 변경되고 상기 방법은 필터값 'true'를 리턴한다; 상기 레코드는 더 이상 수용되지 않고 상기 쌍은 클라이언트를 업데이트하도록 필터를 통과해야만 한다. 단계(717)에서 쌍의 첫번째 인스턴스가 수용되지 않고 마지막 인스턴스가 수용되는 것으로 판단되면, 상기 레코드는 클라이언트에 존재하지 않고 삽입되어야만 한다. 결국, 단계(718)에서 상기 쌍은 UPDATE에서 INSERT로 변경된다. 만약 인스터스들의 어떤 것도 수용되지 않으면, 상기 방법은 단계(720)에서 'false' 필터값을 리턴한다.

본 발명의 다른 실시예에 따르면, 삭제 또는 삽입에 따른 업데이트들의 상기 변경은 트리거 과정(도 6의 단계(604)) 동안에 실행되지 않으며, 동기화 과정(도 7의 단계(507) 동안에 실행된다. 하지만, 대안적인 실시예에서는, 상기 쌍은 트리거 과정 동안에 변경될 수 있고 도 6의 단계(604)에서 프로세스의 일부로서 트리거 리스트에서 변경될 수 있다. 후자에서 동기화 과정 동안에 변경을 수행하는 것은 불필요할 수 있다.

수용 방법은 레코드 타입의 인스턴스에 대해 수용을 판단하는 프로세스가 도시되는 도 8을 참조하여 상세히 설명하고자 한다. 상기 수용 방법은 상기의 예시 코드의 OnRT_Accept(instance)로 표기된 방법이다. 본 발명의 기술 원칙에 따라서, 수용을 판단하는 기본 원칙은 레코드가 수용되는 것으로서, 서브세트 소유자 자체가 수용되지 않은 서브세트 소유자로서 상기 레코드가 서브세트의 일부가 아닐 경우 또는 사용자 정의 수용 방법에 의해 명백하게 수용되지 않는 경우이다. 전자는 데이터 통일성이 유지되는 것이고(수용되지 않은 다른 레코드에 대한 참조를 포함하는 경우 어떠한 레코드도 수용되지 않음), 후자는 클라이언트로 전송되는 데이터 량을 감소시킬 수 있는 가능성을 설계자에게 제공하는 것이다. 따라서, 도 8을 참조하여 설명된 상기 방법은 검사되는 레코드 타입의 인스턴스가 상기에 주어진 이유들 중 어느 하나에 따라서 수용되지 않았는지를 판단한다. 수용되지 않은 것으로 판단되는 경우, 인스턴스에 대한 수용은 네거티브로 판단된다. 한편, 상기 인스턴스는 수용될 수 있다.

파더 역할을 갖는 레코드 타입의 수용은 아래에서 설명되다시피 다소 상이하게 판단될 수 있다.

레코드 타입의 인스턴스는 시간의 특정 시점에서 특정 레코드 타입의 특정 레코드에 저장된 값들일 수 있고, 이들 값은 로그로부터 발견될 수 있음을 유의해야 한다. 상기 수용 방법에 의해 현재 검사 중인 레코드 타입의 인스턴스는 Record Type Instance 또는 RT 인스턴스로 표기될 수 있고, 레코드 타입은 Record Type 또는 RT로 표기될 수 있다. 나아가, 상기 수용 방법에 의해 검사되는 인스턴스 RT 인스턴스는 하나 이상의 서브세트 소유자들과 관계될 수 있다. 서브세트 소유자는 검사 중인 레코드 타입에 의해 참조되는 다른 레코드 타입의 인스턴스이다. 서브세트 소유자의 레코드 타입은 Owner Record Type 또는 ORT로 표기될 수 있고, 소유자 레코드 타입의 특정 인스턴스는 Owner Record Type Instance 또는 ORT 인스턴스로 표기될 수 있다. 상기 ORT 인스턴스는 RT 인스턴스에 있는 자신에 대한 참조 또는 RT 인스턴스의 타임 스탬프에 의해 식별될 수 있다.

프로세스는 개시 단계(800)에서 시작하여 레코드 타입에 대한 첫번째 서브세트 소유자가 식별되는 단계(801)를 실행한다. 단계(802)에서 어떤 ORT도 식별되지 않는 것으로 결정되면, 프로세스는 아래에서 후술되는 단계(810)를 실행한다. ORT가 식별되면 프로세스는 식별된 ORT가 검사 중인 레코드 타입을 제한할 수 있는지 판단되는 단계(803)을 실행한다. ORT 자체가 수용에 따라서 클라이언트에 없으면, RT는 ORT에 의해 제한된다. 만약 ORT가 클라이언트에서 수용되지 않으면, 제한 조건들(RT가 클라이언트에 있지 않는 ORT에 관계되면서, 데이터 통일성을 만족함)을 위배할 수 있기 때문에 RT 또한 수용되어서는 안 된다. Owner Record Type이 Recprd Type을 제한할 수 있는지 여부는 ORT의 역할을 검사하면서 판단될 수 있다. ORT가 마더 또는 차일드일 경우 RT를 제한할 수 있다. 나아가, ORT가 파더 또는 파더(예 : 시스터(sister))에 의해 제한되는 경우, RT는 ORT에 의해 제한될 수 있다. 이런 경우 ORT는 간접 마더로 표기될 수 있다. Owner Record Type이 간접 마더인지 판단하는 프로세스는 이하에서 상세히 설명된다.

단계(803)에서 ORT가 RT를 제한할 수 없다고 판단되면, 프로세스는 다음 ORT가 식별되는 단계(804)를 실행한다. 하지만, ORT가 RT를 제한할 수 있으면, RT 인스턴스에 의해 참조되는 특정 ORT 인스턴스는 단계(805)에서 완성될 수 있다. ORT 인스턴스는 RT 인스턴스에서 참조한 후 적절한 시점에서 ORT 인스턴스와 관련되는 값들을 찾기 위해 로그를 스캐닝하는 외래 키로부터 프라이머리 키를 첫번째 식별하는 것에 의해 완성될 수 있다. 상기 로그는 RT 인스턴스가 쌍의 첫번째 인스턴스이면 시간 윈도우 ㅿt의 시작에서, 그리고 RT 인스턴스가 쌍의 마지막 인스턴스이면 시간 윈도우 ㅿt의 마지막에서, 적절한 인스턴스 값을 판단하기 위해 백워드 방식으로 스캔될 수 있다. 단계(806)에서 ORT 인스턴스가 적절히 완성되었는지 판단하기 위해 검사가 실행될 수 있다. 완성되지 않는 것이면, 예제의 경우가 될 것으로서, RT 인스턴스가 쌍의 첫번째 인스턴스이고 대응하는 데이터베이스의 RT 레코드가 ㅿt 동안에 삽입됨에 따라 더 이상 존재하지 않고 시간 윈도우의 시작에서 ORT를 하나도 갖지 않는 경우라면, 프로세스는 RT 인스턴스에 대한 수용이 false로 설정되는 단계(808)를 실행한다. 하지만, ORT 인스턴스가 적절히 생성된다면, 프로세스는 수용이 ORT 인스턴스에 대해여 판단되는 단계(807)을 실행한다.

ORT가 마더 또는 자식일 경우, ORT 인스턴스에 대한 수용은 RT 인스턴스에 대해 판단된 동일한 방식으로 판단될 수 있다. 즉, 지금까지 설명된 상기 방법은 물론, 자신의 ORT 인스턴스에 다시 종속되는 ORT 인스턴스의 수용을 판단하기 위해 재귀적으로 호출될 수 있다.

하지만, ORT가 파더일 경우, 차일드, 예를 들면 소유자가 아니며, 서브세트 트리의 일부인 레코드 타입에 의해 제한될 수 있다. 이런 경우, 도 9를 참조하여 이하에서 설명되는 것처럼 어떤 다른 방법이 출현될 수 있다.

단계(809)에서 ORT 인스턴스가 수용되지 않는 것으로 판단되면, RT 인스턴스는 수용될 수 없고, 프로세스는 단계(808)을 실행한다. 하지만, ORT 인스턴스가 수용되면, RT 인스턴스의 수용이 종속되는 추가적 서브세트 소유자들이 존재하는지를 식별하기 위해 프로세스는 단계(804)를 실행한다. 이런 경우, 단계(802)에서 판단되듯이, 프로세스가 상기 ORT에 대해 반복된다. 이것은 ORT 인스턴스가 프로세스가 단계(808)에서 수용이 false로 설정된 후 단계(813)에서 프로세스가 종료되면서, 단계(806) 또는 단계(809)에서 네거티브 판단으로 결정될 때까지 또는 프로세스가 RT에 대해 정의된 사용자 정의 수용 방법들이 있는지를 판단하는 단계(810)를 실행하면서, 수용의 네거티브 판단없이 모든 ORT들이 검사되는 단계(802)에서 판단될 때까지 계속된다. 사용자 정의 수용 방법이 정의되지 않은 경우, RT 인스턴스는 ORT 인스턴스에 의해 제한되지 않고, 사용자 정의 수용 방법에 의해 제한되지 않으며, 프로세스는 상기 방법이 단계(813)에서 종료되기 전까지 수용이 true로 설정되는 단계(812)를 실행한다. 사용자 정의 수용 방법이 설정되고 사용자 정의 수용 방법에 따라서 RT 인스턴스가 수용되지 않는 것으로 단계(811)에서 판단된다면, 프로세스는 RT 인스턴스에 대해 수용이 false로 설정되는 단계(808)를 실행하고 상기 방법은 단계(813)에서 종료된다. 단계(811)에서 RT 인스턴스가 사용자 정의 수용 방법에 의해 수용되는 것으로 판단된다면, 프로세스는 방법이 단계(812)에서 종료되기 전에 RT 인스턴스에 대한 수용이 ture로 설정되는 단계(812)를 실행한다.

도 8을 참조하여 설명된 상기 방법은 도 3을 참조하는 것에 의해 설명될 수 있다. 레코드 타입 구매의 쌍에서 첫번째 인스턴스에 해당하는 인스턴스가 스토어 테이블(302)에서 특정 스토어에 관계되는 모든 데이터를 보유하는 PDA에 의해 수용될 수 있는 예제를 가정한다. 상기 방법이 단계(801)를 실행하며 첫번째 ORT가 스토어_물품 테이블(304)에 있는지 판단되고, 단계(803)에서 레코드 타입이 자식이기 때문에, 구매 테이블(308)을 제한할 수 있는지 판단될 것이고, 프로세스는 단계(805)를 실행한다. 단계(805)에서 구매 인스턴스에 의해 참조되는 스토어_물품 테이블(304)의 특정 행이 식별되고, 예를 들어, 스토어_물품 인스턴스가 완성되고 구매 인스턴스에서 참조되는 당해 외래 키로부터 프라임 키를 구성하는 값 또는 값들이 읽혀진다. 스토어_물품 인스턴스를 완성하는 나머지 필드들을 만드는데 필요한 추가적 값들은 로그를 스캐닝하는 것에 의해 발견될 수 있다. 구매 인스턴스가 쌍의 첫번째 인스턴스이므로, 이윤의 값들은 ㅿt의 시작에 있는 레코드에 해당한다. 하지만, 이들 값은 ㅿt 의 시작 다음에, 심지어 ㅿt 의 마지막 이후에 로그에 쓰여진 DEL 엔트리에서 발견될 수 있다. 따라서, ㅿt 의 시작 시점 또는 이전 시점의 값을 최적으로 나타내는 로그 엔트리가 프라이머리 키에 의해 식별된 스토어_물품 레코드로 발견될 때까지 로그의 끝에서부터 스캔을 시작하여 백워드로 스캐닝하는 것이 필요로 된다. 로그 엔트리가 생성될 때 로그가 레코드의 모든 값을 저장하는 경우, ORT 인스턴스를 전부 수집하기 위해 하나의 상기 로그 엔트리를 찾는 것은 충분하다. 변경된 값들만 로그에 기록된다면, 모든 값들이 얻어질 때까지 로그를 백워드 방식으로 계속 스캐닝하는 것이 필요로 될 것이다.

로그를 스캐닝하는 동안 로그 엔트리의 선택은 설계 방식의 선택에 따르는 것임을 유의해야 한다. 예를 들면, 실시예들은 시간 윈도우 ㅿt의 시작(또는 종료) 시점 또는 이전 시점, 또는 시간 윈도우의 시작(또는 종료) 종료 시점에 한하여 레코드 값들을 나타내야 한다면 로그 엔트리가 검사되어야만 하는지에 대해 다양해질 수 있다. 그 이유는 로그 엔트리가 하나의 타임 윈도우의 종료 및 후속되는 타임 윈도우의 시작의 양쪽 모두에 속하는 것으로, 타임 윈도가 오버래핑되는 것은 바람지하지 않기 때문이다. 일부 경우들에서 로그는 적절한 레코드 인스턴스의 완성을 허용하는 어떤 관련 로그 엔트리조차 포함하지 않을 수 있다. 예를 들면, 로그가 비워지거나 또는 데이터베이스가 생성된 후 초기값이 변경이 안 된 경우로서 로그가 기록된 적이 없는 경우이다. 이러한 경우, 데이터베이스에서 발견되는 값들은 타임 윈도우보다 오래된 것으로 결정될 수 있고, 이들 값은 쌍의 양쪽 인스턴스로 사용될 수 있다. 다른 경우에서 삭제를 나타내는 로그 엔트리가 내부 또는 시간 윈도우 ㅿt의 종료 이후에 발견될 수 있고, 필요에 의해 삭제된 엔트리가 삭제되기 전의 레코드에 대한 값을 나타낼 수 있기 때문에 시간 윈도우의 시작 또는 종료 시점에서 적절한 값들에 해당될 수 있다. 정확하게 어떤 로그 엔트리들이 적절한 값들을 찾는데 적합한 후보가 될 수 있는지는 실시예의 상세 구성에 따라 달라지며, 예를 들면, 어떻게 로그 기록이 수행되고 어떻게 데이터베이스가 동기화 동안에 동작하고, 어떻게 업데이트 윈도우가 판단되는지에 따라 각각 달라진다. 하지만, 원칙은 현재 또는 이전의 동기화가 시작되었을 때에 해당하는 시점에서 특정 레코드의 상태를 가장 잘 나타내는 값들을 얻는 것이다.

스토어_물품에 대한 ORT 인스턴스가 적절하게 완성된 후, 프로세스는 당해 수용이 판단되는 단계(807)를 실행한다. ORT 인스턴스는 RT 인스턴스에 따르는 차일드이기 때문에, 그 수용은 동일한 방법에 의해 판단될 수 있고, 프로세스는 ORT 인스턴스에 대한 단계(800)을 재개한다. 단계(801)에서 스토어_물품 테이블(304)에 대한 첫번째 ORT는 물품 테이블(305)이라고 판단될 수 있다. 그러면 단계(803)에서 물품 테이블(305)은 스토어_물품 테이블(304)에 대하여 파더라고 판단될 수 있고, 결국 스토어_물품 테이블(304)를 제한할 수 없다. 물품 테이블(305)은 아이템 전체 테이블(306)에 대해 간접 마더이고, 이하에서 후술되듯이, 테이블(606)을 제한할 수 있고, 스토어_물품 테이블(304)를 제한할 수 없으며, 프로세스는 스토어_물품 테이블(304)에 대한 다음 ORT에 해당되는 단계(804)를 바로 실행한다. 이것은 스토어 테이블(302)이 되며 프로세스는 단계(802)를 통해 ORT 스토어(302)가 RT 스토어_물품(304)를 제한할 수 있다고 판단될 수 있는 단계(803)를 실행하고, 프로세스는 스토어_물품 인스턴스에서 참조되는 스토어 엔트리에 대한 ORT 인스턴스가 완성되는 단계(805)를 실행한다. 상기 프로세스는 스토어_물품 인스턴스의 완성에 대해 상기에서 설명한 것과 동일하고, 스토어 인스턴스는 단계(805)에서 성공적으로 완성되도로 제공되어, 프로세스는 완성된 스토어 인스턴스에 대해 수용을 판단하기 위해 단계(807)을 진행한다.

스토어 레코드 타입이 마더일 경우, 상기 동일한 프로세스가 다시 이용될 수 있고, 상기 프로세스는 스토어 인스턴스를 형성하도록 단계 800에서 다시 시작된다. 상기 스토어 테이블(302)의 유일한 서브셋 소유자는 상기 스토어 소유자 테이블(301)이다. 상술한 바와 같이, 상기 스토어 소유자 테이블(301)은 직접적 또는 간접적으로 어떠한 수용 방법과도 관련되지 않으며, 따라서 역할이 없다. 따라서 어떠한 서브셋 멤버도 제한할 수 없고, 단계 801 내지 804를 거친 후에는, 단계 802에서 추가적인 ORT가 발견되지 않는다고 판단될 것이다. 이후 프로세스는 단계 810으로 이동하여, 스토어 테이블(302)에서 정의된 사용자 정의 수용 방법이 있는지 여부를 판단한다. 단계 811에서는 사용자 정의 수용 방법에 따르는 수용이 판단된다. 이번의 특정 예에서는 사용자 정의 수용 방법은 상기 파라미터 보유자 PDA 테이블(303)에서 발견될 수 있는 파라미터에 의존할 것이다.

만약 수용이 부정(예로, 이러한 스토어 엔트리가 특정한 PDA에 동기화되지 않은 상태일 경우)으로 판단되면, 상기 프로세스는 단계 808로 이동하여 수용은 실패(false)한 것으로 설정된다. 상기 프로세스가 단계 813에서 종료되면, 단계 807로 돌아가서 이 결과를 포함한 스토어_물품 인스턴스를 처리하도록 한다. 단계 809에서 상기 스토어_물품 인스턴스를 위한 상기 ORT 인스턴스가 수용되지 않으면, 상기 프로세스는 단계 808로 이동하여 단계 813에서 상기 프로세스가 종료되기 전에 상기 스토어_물품 인스턴스를 위한 수용을 실패로 설정한다. 프로세스가 종료되면, 상기 결과는 구매 인스턴스를 위해 단계 807에 보고된다. 단계 809에서 위에 설명된 구매를 위한 ORT 인스턴스가 수용되지 않은 것으로 결정되면, 상기 프로세스는 단계 808로 이동하여 수용은 실패로 설정된다. 상기 구매 인스턴스가 수용되지 않은 것으로 결정됨에 따라 상기 프로세스는 단계 813에서 종료된다.

반대로, 만약 상기 스토어 테이블을 위해 정의된 사용자 정의 수용 방법의 검토 결과가 단계 811에서 긍정적(예로, 이러한 스토어 엔트리가 특정한 PDA에 동기화된 상태일 경우)으로 수용이 결정되면, 상기 프로세스는 단계 812로 이동하여 설정된 스토어 인스턴스의 수용은 성공(true)으로 설정된다. 상기 스토어 인스턴스의 프로세스가 종료되면, 이 결과는 단계 807에서의 스토어_물품 인스턴스 처리 과정으로 되돌아가 보고된다. 단계 809에서 ORT 인스턴스가 수용된 것으로 판단되면, 상기 프로세스는 단계 804로 이동하여 이러한 레코드 타입(이미 고려된 상기 물품 레코드 타입)을 위한 추가적인 ORT가 더 이상 존재하는지 여부가 판단된다. 이에 따라 프로세스는 단계 802를 거쳐 단계 810으로 이동하여, 상기 스토어_물품 테이블을 위한 사용자 정의 수용 방법이 더 이상 존재하는지를 판단하게 된다. 이후 프로세스는 단계 812로 이동하여 단계 813에서 상기 프로세스가 종료하기 전에 수용을 성공으로 설정한다. 이 결과는 구매 인스턴스의 수용을 결정하는 프로세스의 단계 807로 되돌아가 보고된다. 이 프로세스는 다음으로 단계 809로 이동하고 상기 ORT 인스턴스의 수용이 긍적이기 때문에, 단계 804로 이동한다. 단계 804에서는 추가적인 ORT가 더 이상 구매 테이블(309)에서 식별되지 않을 것이고, 따라서 상기 프로세스는 단계 802에서 단계 810으로 이동하여, 상기 구매 테이블(308)에 더 이상 사용자 정의 수용 방법이 존재하지 않는 것으로 판단된다. 프로세스는 이후 단계 812로 이동하여 상기 단계 813에서 상기 프로세스가 종료되기 전에 이 구매 인스턴스의 수용을 성공으로 설정한다.

파더(father) 레코드 타입의 수용을 결정하는 것을 나타낸 도 9를 지금부터 참조한다. 이미 언급한 바와 같이, 파더는 그것의 선(son)에 의해 제한될 수 있다. 예를 들어 소유자 레코드 타입이 아닌 레코드 타입이지만 파더에 관련된 서브셋 레코드 타입에 의해. 도 8의 수용 방법에 더하여, 레코드 타입 인스턴스가 선(son)에 의해 제한되는지 여부를 결정할 필요가 있다. 위에 나열된 간단한 코드는 위에 나열된 예시 코드에서 OnRT_AcceptFather(instance)라고 불리는 방법을 나타낸 것이다. 도 9에 도시된 이 방법은 전형적인 수용 루틴이고, 이 방법은 한 쌍의 인스턴스를 위해 수행된다.

상기 방법은 개시 단계(900)에서 시작되고 단계 901로 진행되어, 시험 중인 파더 이벤트가 레코드 타입 또는 RT로 선언되었는지 여부가 판단된다. 만약 파더 이벤트가 선언되지 않았다면, 선(son)은 식별되지 않고 상기 방법은 단계 902에서 단계 910으로 분기 되어, 상기 프로세스가 단계 911에서 종료되기 전에 수용은 성공(true)으로 RT 인스턴스에 설정된다.

만약 단계 902에서 파더 이벤트가 레코드 타입으로 선언되었다고 판단되면, 멤버 레코드 타입의 식별자 또는 MRT는 회수되고 첫 번째 멤버 레코드 타입이 단계 903에서 검토된다. 단계 904에서 MRT가 발견되면, 상기 프로세스는 단계 905로 진행하여 검토되는 MRT가 단계 902에서 식별되는 제한하는 선(son)인지가 판단된다. 만약 이것이 위의 경우가 아니면, 상기 프로세스는 단계 906에서 다음 MRT를 검토한다. 이 때 단계 902에서 제한하는 선(son)이 실제로 존재하는 것으로 판단되면, 이 레코드 타입 역시 결국 발견되어야 한다는 점에 주의해야 한다. 그러나, 상기 파더 이벤트가 사용자에 의해 선언되는 경우, 상기 제한하는 레코드 타입을 발견하는 방법은, 잘못 선언된 파더 이벤트로서 실제 존재하지 않는 레코드 타입의 식별자를 리턴하는 상기 파더 이벤트를 처리할 수 있어야 한다. 만약 이것이 위의 경우라면, 상기 방법은 단계 904에서 추가적인 MRT가 발견되지 않는 것으로 결국 판단할 것이고, 상기 프로세스는 단계 910으로 진행하여 단계 911에서 상기 프로세스가 종료되기 전에, RT 인스턴스의 수용은 성공으로 설정된다.

단계 905에서 검토되는 MRT가 상기 RT의 제한하는 선(son)인 것으로 판단되면, 상기 프로세스는 단계 907로 진행하여 식별된 멤버 레코드 타입에서 적어도 하나의 인스턴스가 긍정적인 수용을 갖는지 여부가 판단된다. 이러한 프로세스는 아래에 첨부된 도 10을 참조하여 보다 상세하게 기술한다.

적어도 하나의 수용된 선(son)의 존재는 상기 파더 인스턴스가 클라이언트에 제공되어야 함을 의미한다. 만약 단계 908에서 MRT 테이블에서 적어도 하나의 수용된 인스턴스가 발견된 것으로 판단되는 경우(예로 하나의 수용된 선(son)), 상기 프로세스는 단계 910으로 진행하여, 단계 911에서 상기 프로세스가 종료되기 전에, RT 인스턴스의 수용은 성공으로 설정된다. 반면에 수용된 인스턴스가 발견되지 않을 경우 상기 방법은 단계 909로 진행하여 단계 911에서 상기 프로세스가 종료되기 전에, RT 인스턴스의 수용은 실패로 설정된다.

긍정적 수용으로 제한하는 선(son)의 존재를 판단하는 방법을 나타낸 도 10을 지금부터 참조한다. 상기 방법은 개시 단계(1000)에서 시작하고 단계 1001로 진행하여, RT 인스턴스를 매칭하는 첫 번째 MRT 인스턴스로서 어떠한 로그 엔트리도 가지지 않는 MRT 인스턴스가 식별된다. RT 인스턴스를 매칭하는 MRT 인스턴스들 모두가 로그되었다는 것은 보장되지 않는다. 예를 들어, MRT는 데이터베이스가 생성되기 전에 클라이언트에 의해 수용될 수 있고, 상기 레코드가 만들어지기 전까지 변경되지 않으며, 또한 로그는 오래된(예를 들어, 수일 동안) 로그 엔트리들을 삭제하는 프로세스에 의해 제거될 수 있다. 현재의 로그보다 더 오래된 데이터베이스 엔트리들은 반드시 시간 윈도우 Δt 동안 변하지 않고 존재해야하기 때문에, 상기 인스턴스들은 데이터베이스를 직접 검토하는 것에 의해 발견될 수 있다. 이것은 시간 윈도우의 시작보다 로그 작성(logging)이 더 오래되는 것이 충분함을 의미하며, 따라서 시간 창문의 시작보다 더 오래된 엔트리들이 로그에서 삭제되었거나, 데이터베이스가 로그 없이 생성되었으나 시간 창문과 동기화를 시작하기 전에 로그 작성이 이루어졌더라도, 본 방법은 동작할 수 있다.

만약 단계 1002에서 로그 엔트리가 없는 MRT 인스턴스가 발견된 것으로 판단되면, 상기 프로세스는 단계 1003으로 진행하여 MRT 인스턴스의 수용 여부를 결정한다. 이는 도 8을 참조로 상술한 것과 동일한 방법을 이용하여 이루어질 수 있다. 만약 단계 1003에서 식별된 인스턴스가 클라이언트에 수용되도록 결정되면, 상기 프로세스는 단계 1008로 진행하여 단계 1009에서 상기 프로세스가 종료되기 전에 수용된 MRT 인스턴스가 발견되었음을 나타내는 '성공(true)'을 리턴한다. 반면에 단계 1003에서 상기 MRT 인스턴스가 수용되지 않도록 결정되면, 상기 방법은 단계 1001로 돌아가 RT를 매칭하고 로그 엔트리들이 없는 다음 MRT 인스턴스를 찾는다. 이 프로세스는 단계 1003에서 수용된 MRT 인스턴스가 발견되거나 또는 단계 1002에서 레코드 타입(Record Type)을 매칭하는 멤버 레코드 타입(Member Record Type)이 더 이상 발견되지 않는다고 판단되는 때까지(예로, 매칭하는 MRT 인스턴스 모두가 검토되고 아무것도 수용되지 않았을 경우) 계속된다. 발견되지 않는 것으로 판단되는 경우, 상기 프로세스는 단계 1004로 진행한다.

단계 1004에서 RT에 매칭하는 첫 번째 MRT 인스턴스가 로그에서 발견된다. 상기 로그는 MRT 인스턴스를 생성하기 위해 로그 엔트리들로부터 반대 방향으로 도 8의 단계 805에서 수행된 것과 유사한 프로세스로 스캔된다. 이 프로세스는 윈도우 Δt의 시작 또는 종료에서 적절한 인스턴스 값을 형성하기 위해 탐색하는 것인데, RT 인스턴스가 첫 번째 또는 마지막 쌍인지 여부에 의존한다. 상술한 바와 같이, 적당한 포인트보다 시간적으로 새로운 로그 엔트리들이 적절할 것인데, 예를 들어 DEL 엔트리는 DEL 엔트리를 위한 타임 스탬프보다 값들이 시간적으로 앞선 포인트라는 것을 나타낼 것이다. 따라서 상기 로그는 윈도우의 시작 또는 끝이 발견되는 최선의 대표값이 될 때까지 마지막 엔트리로부터 반대방향으로 스캔된다.

단계 1004에서 MRT 인스턴스가 상기 로그에서 발견된 상기 RT에 매칭되는 것으로 결정되면, 상기 프로세스는 단계 1006으로 진행하여 MRT 인스턴스가 수용되는지를 결정한다. 만약 단계 1006에서 상기 식별된 인스턴스가 클라이언트에서 수용된 것으로 결정되면, 상기 프로세스는 단계 1008로 진행하여 상기 방법에 따라 단계 1009에서 상기 프로세스가 종료되기 전에 수용된 MRT 인스턴스가 발견되었음을 지시하는 성공(true)을 리턴한다. 반면에 만약 단계 1006에서 상기 MRT 인스턴스가 수용되지 못한 것으로 결정되면, 상기 방법에 따라 단계 1004에서 다음 MRT 인스턴스와 매칭하는 RT를 상기 로그로부터 찾도록 리턴한다. 이 프로세스는 단계 1006에서 수용된 MRT 인스턴스가 발견되거나 또는 단계 1005에서 추가적인 멤버 레코드 타입 인스턴스와 매칭되는 레코드 타입의 존재가 발견되지 않음(예로, 모든 매칭하는 MRT 인스턴스가 검토된 상기 로그로부터 파생될 수 있고 수용되지 않았을 경우)이 결정될 때까지 계속된다. 마지막 경우, 상기 프로세스는 단계 1007로 진행하여 상기 방법에 따라 단계 1009에서 상기 프로세스가 종료되기 전에 수용된 MRT 인스턴스가 발견되지 않았음을 지시하는 실패(false)와 함께 리턴한다.

다시 도 3을 참조하여, 도 9와 도 10의 프로세스의 짧은 예를 설명할 수 있다. 상기 도 9의 프로세스는 물품 테이블(305)에서 주어진 한 쌍의 인스턴스가 동기화된 상기 클라이언트에 의해 수용되었는지 여부를 결정하는 것을 목적으로 한다. 예를 들어, 상기 쌍은 물품01에 관련된다. 단계 901에서, 파더 이벤트 확실하게 상기 물품 테이블(305)에 선언됨이 결정된다. 단계 902에서 멤버 레코드 타입의 식별은 상기 물품 테이블(305)의 검색을 제한하고, 이 식별은 상기 스토어_물품 테이블(304)을 식별하도록 한다. 단계 903에서 상기 첫 번째 MRT는 아이템 합산 테이블(306)이 되도록 검토된다. 따라서, 단계 904에서 MRT가 발견된 것으로 결정되더라도, 단계 905에서는 단계 902에서 식별된 제한 테이블이 아닌 것으로 결정될 수 있다. 결과적으로 상기 프로세스는 단계 906으로 이동하여 다음 MRT가 검토된다. 이는 스토어_물품 테이블(305)과 상기 프로세스가 결국 단계 906으로부터 단계 904와 단계 905로 진행하여 검토된 MRT가 제한된 상기 선(son)에서 파더 RT 테이블에서와 같이 식별된 하나가 되도록 형성될 수 있다. 상기 프로세스는 결국 단계 907로 진행되어 제한 테이블을 결정하고, 상기 MRT 스토어_물품(304)은 어떠한 엔트리들을 포함하며, 현재 존재하는 테이블로부터 상기 한 쌍의 인스턴스로 식별된 물품 테이블(305)의 엔트리들이 참조되고, 클라이언트에서 수용된다. 예를 들면, 스토어_물품 테이블(304)에 어떤 엔트리가 있는지는 상기 물품 테이블(305)에 물품01을 참조하고 적절한 시점에 클라이언트로부터 수용된다.

도 10을 참조하여 설명한 상기 프로세스는 이러한 문제의 해답이 될 수 있다. 단계 1001, 1002 및 1003에서 상기 스토어_물품 테이블에 엔트리들은 물품01을 참조하고 검토된 로그 엔트리들을 갖지 않는다. 가능한 이런 엔트리들은 발견되어 지고 긍정적인 수용을 갖도록 결정되며, 상기 방법에 따라 도 9의 단계 907에서 성공 값과 함께 리턴되고, 도 9에 도시된 상기 방법은 단계 908로 진행하여 수용된 MRT 인스턴스가 발견되도록 결정되고, 상기 방법은 단계 910으로 진행되어 물품01의 인스턴스를 위한 수용이 클라이언트에서 수용될 수 있도록 한다.

만약 단계 1001, 1002 및 1003에서 수용되지 않은 MRT 인스턴스와 매칭하는 물품01이 발견되면, 상기 프로세스는 단계 1004, 1005 및 1006으로 진행하여 수용된 MRT 인스턴스와 매칭하는 물품01이 상기 로그로부터 발견되는지를 결정하게 된다. 만약 상기 방법이 다시 단계 907에 성공 값으로 리턴되면, 상기 방법은 다시 단계 908과 910으로 진행하여 물품01의 인스턴스를 위한 수용은 클라이언트에서 수용될 수 있도록 한다.

만약 수용된 스토어_물품 인스턴스가 없으면 레퍼런스 물품01은 발견될 수 있고, 상기 도 10의 방법에 따라 단계 1009에서 종료되기 전에 단계 1007로 진행한다. 상기 실패(false) 값이 도 9의 단계 907로 리턴되면, 물품01을 참조하는 스토어_물품 테이블(304)에 엔트리가 존재하지 않는 것이고 동기화된 클라이언트에 수용된다. 이것은 물품01이 상기 클라이언트에 필요하지 않음을 의미하며, 이는 클라이언트에 물품01을 운송할 적절한 스토어가 없기 때문이다. 도 9의 프로세스는 단계 908에서 결정하고 적절한 MRT 인스턴스가 발견되지 않았는지를 결정하고, 단계 909로 진행하여 물품01을 위한 수용이 단계 911에서 상기 방법이 종료되기 전에 실패(false)로 설정된다.

도 6의 단계 606에 의해 표현된 역할에 기초한 트리거링(triggering) 프로세스를 이하에서 보다 상세하게 설명하기로 한다. 상술한 바에 의하면, 제1 방법 수집레코드(CollectRecords)에 의해 연관된 데이터베이스의 모든 레코드를 수집하며, Δt_i 동안 고려되어 변경되어짐에 따라 데이터베이스 △를 생성한다. 이 프로세스는 도 5의 단계 502와 일치한다. 상기 수집된 레코드들은 상기 레코드의 두 인스턴스를 포함하는 한 쌍의 트리거 목록으로 등록되어 하나는 t_{i -1} 시간에 상기 레코드를 위한 값이 포함되어 Δt_i의 시작을 할 수 있도록 하고, 하나는 도 5의 단계 503에 유사한 종래 시간 t_i 의 레코드를 위한 값이 포함된다. BrowseExternalAcceptanceChange를 참조한 제2 방법은 데이터베이스를 브라우즈하여 레코드를 식별하고 Δt_i 동안 어떠한 값도 변하지 않도록 하나, 도 5의 단계 504를 참조하여 설명된 바와 같이, 연장 변수들을 위한 수용에서는 변경된다. 상기 식별된 레코드들은 단계 505에서 동일한 트리거 목록의 쌍으로 추가된다. 상기 목록은 도 5와 도 6에 상세하게 설명된 단계 506에 표현된 트리거링 프로세스에 입력으로 이용될 수 있는 두 가지 방법에 의해 생성된다. 상기 트리거링 프로세스는 추가적인 레코드를 식별하고 식별된 레코드는 이 경우 도 6에 603 및 606 단계에 트리거 목록에 쌍으로 추가된다. 이러한 트리거된 쌍들은 정확하게 상기 쌍과 같은 동일한 방식으로 검토되어, 모든 쌍이 목록으로 검토될 때까지 수집레코드(CollectRecords)와 BrowseExternalAcceptanceChange 방법에 의해 목록으로 추가된다. 따라서 상기 트리거 목록과 트리거된 쌍들은 모든 쌍들이 목록으로 검토될 동안 가로지른다.

상기 목록에 표현된 상기 쌍은 원칙적으로 어떠한 종류의 역할을 갖는 것으로 이해되며, 수집 프로세스, 브라우즈된 프로세스의 결과 추가 여부와 상관없이 또는 상기 목록에 이미 추가된 쌍에 의해 트리거된다. 도 6의 단계 606 에 검토된 모든 쌍들은 추가적인 쌍들이 트리거될 수 있도록 결정하기 위해 어떻게 상기 목록에 추가되었는지 여부와 상관없이 동일한 절차에 따라 검토될 수 있다.

트리거링 프로세스가 트리거된 레코드를 위해 반복됨으로 인해서, 트리거링 쌍의 긴밀한 관계를 트리거하기 위해 요구될 뿐, 상기 쌍의 계층이 상기 엔트리의 일 부분으로 제한되지는 않음을 인지해야 한다. 예를 들어, 마더(mother)가 칠드런(children)을 트리거하더라도 첫 번째 차일드(child)에 의해 차례로 트리거될 동안, 그 차일드(child)의 칠드런(children)을 트리거하지 않도록 한다. 반면에, 본 발명의 원칙에 따라 정의된 트리거된 쌍의 하위계층으로 더 내려가도록 트리거되는 트리거 계획은 유지된다.

도 3의 설명으로부터 여섯 개의 제한 역할이 정의가 상기된다. 상기 역할은 마더(mother), 차일드(child), 선(son), 파더(father), 시스터(sister) 및 브라더(brother)처럼 여기에 참조 된다. 레코드 타입은 오직 하나의 역할만을 요구하지 않는다. 역할은 레코드 타입에 다른 레코드 타입이 어떻게 관계되었는지에 따라 정의되고, 레코드 타입은 몇 가지 역할을 갖는 몇 가지 다른 레코드 타입에 관계될 수 있다. 특정 레코드 타입의 인스턴스로 표현된 쌍이 트리거처럼 행동을 취하면, 레코드 타입의 상기 모든 역할들에 대한 검토가 요구된다.

아래에는 식별될 수 있는 경우들을 나열하였다.

i) 레코드 타입이 마더이다.

ii) 레코드 타입이 차일드이다.

iii) 레코드 타입이 마더 및 차일드이다.

iv) 레코드 타입이 마더, 차일드 및 선(son)이다.

v) 레코드 타입이 마더, 차일드, 선 및 브라더이다.

vi) 레코드 타입이 차일드 및 선이다.

vii) 레코드 타입이 차일드, 선 및 브라더이다.

viii) 레코드 타입가 파더이다.

ix) 레코드 타입가 시스터이다.

추가로, 역할을 갖지 않는 레코드 타입들이다. 역할이 없는 쌍은 어떠한 트리거도 되지 않는다. 도 3의 예를 들면, 상기 스토어 소유자(301)는 어떠한 역할도 갖지 않는다.

위의 i) 경우에 따르면, 상기 레코드 타입은 마더이다. 이것은 상기 레코드 타입이 오직 이 레코드 타입의 자식들과 같은 다른 레코드 타입에만 관계됨을 의미한다. 도 3에서의 예를 살펴보면, 상기 스토어 레코드 타입(302)은 두 칠드런을 갖는 레코드와 상기 PDA 레코드 타입(303)과 상기 스토어_물품 레코드 타입(304)이다. 상기 마더의 자식들은 트리거 하기 위한 후보이거나, 또는 보다 정확하게 이러한 두 개의 레코드 타입의 어떠한 인스턴스 쌍은 특정한 스토어 아래의 고려사항을 참조하는 외부의 키를 포함하며, 트리거 목록에 추가되어야 한다. 어떤 추가적 레코드 타입을 트리거하는 것은 요구되지 않는다. 만약 어떠한 레코드 타입이 트리거 목록에 추가되면, 이 트리거된 칠드런이 검토되었을 때에, 제시간 내에 완료될 것이다. 이번 경우에서, 어떤 물품, 구매, 판매 또는 아이템 총합 쌍은 스토어_물품이 검토될 때에 트리거 된다. 상기 트리거링은 AddChildren 같은 것이 참조된 방법에 의해 조절될 수 있다.

위 ii) 경우를 참조하면, 상기 레코드 타입은 차일드이다. 파라미터 보유자들로부터 분리된 차일드 레코드 타입은 그들의 칠드런의 레코드 타입을 트리거하지 않는다. 이것은, 차일드 레코드 타입이 자기 차일드의 레코드 타입에 관한 추가적인 정보를 보유하고, 이 추가적인 정보는 부모(parent) 레코드 타입을 적절하게 하지 않는다는 사실에 의해 알 수 있게 된다. 그리고, 파라미터 보유자들에 이르게 되면 도 6의 단계 603에서 그들은 그들의 마더들을 트리거한다. 여기에 서술된 본 발명의 실시예에 따르면, 역할에 기초한 트리거링은 단계 606에서 분리되고, 따라서 파라미터 보유자들은 마더의 자식들이 될 가능성으로 마더들은 트리거하지 않는다.

도 3에는 차일드의 역할을 갖는 PDA 레코드 타입(303), 스토어_물품 레코드 타입(304), 판매 레코드 타입(307) 및 구매 레코드 타입(308)과 같은 4 가지의 레코드 타입의 예가 있다. 차일드 레코드 타입들은 오직 그들의 칠드런만 트리거하고, PDA(303), 판매(307) 및 구매(308) 같은 레코드 타입들은 칠드런을 갖지 않으며, 이 특정 예시에서 그들은 어떠한 추가 쌍을 트리거 하지 않는다. 상기 스토어_물품 레코드 타입(304)은 비록 이러한 레코드 타입이 선(son)과 브라더(brother)인 경우에 관해서는 아래에 논의될 것이다. 레코드 타입의 쌍에 기초한 트리거링은 AddChildren 방법에 의해 다시 조절될 수 있는 차일드 역할을 갖는다.

상기의 iii) 경우에 따르면, 레코드 타입은 마더(예로, 그에 관련된 필터를 갖는)와 조금 다른 레코드 타입의 차일드 스스로이다. 도 3에는 두 가지 역할을 갖는 레코드 타입이 존재하지 않는다. 상술한 바와 같이, 쌍은 그들의 마더를 트리거하지 않는다. 예를 들면, 저자의 참고목록이 변경된 경우에는 특정 스토어에 의해 저장되지 않는다. 만약 클라이언트가 가지고 있는 그 스토어의 품목이 동기화될 경우, 참고목록의 변경은 그 저자의 표현적인 저자 레코드 타입의 쌍을 트리거할 수 없도록 한다. 반면에, 마더와 차일드 둘다 상기 레코드 타입에 고려되었을 경우 그 소유 칠드런의 트리거가 요구될 것이고, 이는 그들이 완료 요구를 제한하는 일부의 제약 정보를 가지고 있기 때문일 것이다. 상기 AddChildren 방법은 트리거링 조절에 다시 이용될 수 있다.

위 iv) 경우를 살펴보면, 고려사항 하에 있는 쌍의 레코드 타입은 마더와 차일드뿐만 아니라 선(son)이다. 도 3에는 이러한 조합을 갖는 어떤 예시도 나타나 있지 않다. 이처럼, 상기 AddChildren 방법은 고려사항 하에 있는 쌍의 칠드런 추가에 이용될 수 있다. 그러나, 레코드 타입이 선일 경우에는 그의 파더를 추가하도록 요구될 수 있다. 이것은 AddFather라 불리는 방법에 의해 완료될 수 있고, 이하에서 보다 상세히 설명하기로 한다.

v) 경우를 참조하면, 고려사항 하에 있는 쌍은 마더, 차일드, 선 및 브라더인 레코드 타입이다. 첫 번째 3 개의 역할은 상기와 동일한 효과를 갖고, 상기 브라더의 역할은 상기 브라더의 시스터를 추가하도록 요구한다. 이것은 AddSisterOfBrother 방법에 의해 완료될 수 있고, 이하에서 상세히 설명하기로 한다.

vi) 경우를 살펴보면, 레코드 타입 쌍은 차일드과 선, 그리고 그것의 파더에 더하여 그의 칠드런을 추가하도록 요구된다.

vii) 경우를 보면, 레코드 타입 쌍은 차일드, 선, 그리고 브라더의 역할을 갖는다. 상기 레코드 타입인 도 3의 스토어_물품(304)은 이러한 역할의 조합을 나타낸 예이다. 상기 레코드 타입은 상기 스토어 레코드 타입(302)의 차일드이고, 물품 레코드 타입(305)의 선(son)이다. 추가로 레코드 타입의 브라더는 아이템 총합(306)이다. 레코드 타입인 선은 파더를 참조하여 포함한다. 상기 선 역할은 상기 파더의 역할을 제한하도록 하는 것이다. 이 경우, 테이블(305에서 주어진 스토어(302)에 의해 실질적으로 저장되어 그 스토어의 품목을 갖는 클라이언트 PDA에 불러낸 물품만이 보장되도록 서비스한다. 추가로 레코드 타입(304)의 쌍은 아이템 총합 레코드 타입(306)에 브라더이다. 상기 아이템 총합 레코드 타입(306)은 상기 파더 레코드 타입 물품(305)의 비제한적인 일부 멤버이다. 이는 브라더 레코드 타입이 시스터 레코드 타입에 영향을 주도록 변경되는 것을 의미한다. 물품 테이블(305)로부터 스토어의 품목으로 새로운 물품이 추가된 스토어_물품의 변경, 아이템 총합 테이블(306)에 효과를 가지는 스토어 테이블(302)의 변경, 새로 추가된 물품(또는 아이템)의 판매의 변경, 아이템 총합 테이블(306)에 새로운 레코드가 추가될 스토어의 변경 및 반대로 파더 테이블(305)로부터의 물품만이 추가되도록 요구될 뿐만 아니라 시스터 테이블(306)로부터의 물품들을 위한 총합이 클라이언트에 주어진 가용 물품들의 총 판매를 이루도록 하는 변경을 예로 들 수 있다. 이것은 AddSisterOfBrother 같은 것이 참조된 방법에 의해 조절될 수 있다.

요약하면, 예를 들어 설명한 바와 같이 쌍을 위한 레코드 타입은 차일드, 선(son) 및 브라더의 역할을 조합하며, 적절한 칠드런 예로, 판매(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(pair)와 관련된 방법이 사용되어 이와 관련된 마더가 트리거된다. 상기 방법은 상기 트리거한 쌍의 레코드 타입이 실질적으로 파라미터 보유자가 되는 것을 확인함으로써 시작한다. 파라미터 보유자가 존재하지 않다면, 상기 방법은 여기서 더 이상 할 일이 없기 때문에 종료된다. 파라미터 보유자가 존재하면, 적절한 소유자 레코드 타입(Owner Record Type : ORT)은 확인되어야 한다. 도 3에 따르면, 상기 트리거한 파라미터 보유자는 PDA 테이블(303)로부터 한 쌍이 될 것이고, 소유자 레코드 타입(ORT)은 스토어 테이블(302)이 될 것이다.

상기 파라미터 보유자는 다른 쌍으로부터 상이하게 트리거할 수 있음을 주목해야 된다. 첫째로, 일반적으로 다른 레코드 타입과 관련된 레코드 타임은 서브셋 제약을 위반할 수 있기 때문에 빈 값들을 가지지 않을 수 있다. 예를 들어, 테이블(304)에서 스토어_물품 엔트리는 특정 매장에서 발견될 수 있는 특정 물품을 대표하고, 이에 따라 상기 물품 테이블(304)에서 특정 물품과 매장 테이블(302)에서 매장은 항상 관련된다. 마찬가지로, 구매 테이블(308)에서 특정 엔트리는 해당 매장에서 물품의 실질적인 구매를 대표하고, 이에 따라 상기 엔트리는 상기 스토어_물품 테이블(304)에서 스토어_물품 엔트리와 항상 관련된다. 구매 엔트리는 해당 물품 및 매장과 관련성이 없이 존재하지 않는다. 그러나 파라미터 보유자 엔트리는 어느 특정 매장에서 현재 할당되지 않고 널(null) 값인 외래 키를 가지는 특정 PAD를 위하여 존재할 수 있다.

파라미터 값에서 변경이 실질적으로 두 마더로 트리거될 수 있는 또 다른 차이점이 존재한다. 도 3을 예를 들어 설명하면, PDA가 처음으로 특정 매장으로 할당되고 이것이 다른 PDA로 변경된 경우, 새로운 매장이 PDA로 추가되고 원래의 매장이 상기 PDA로부터 제거되야 하기 때문에 상기 매장 둘 다 트리거하는 것이 필요할 것이다.

따라서, 상기 방법은 상기 서브셋 링크 값들이 상기 트리거한 쌍에서 두 인스턴스 사이에서 변경되는 어드레스 방식을 고려할 수 있다. 각각의 ORT 엔트리는 상기 쌍에서 서브셋 링크에 의해 확인되고, 특정 쌍은 트리거의 리스트로 들어가거나 생생될 수 있다. 아래에 나오는 가능성들이 존재한다. △t 이전에 접속 값(예컨대, 외래 키 참조를 위한 널 값)이 없고 △t 이내에 값이 존재하지 않은 경우, 즉 실질적으로 상기 ORT에서 참조 엔트리가 존재하지 않고 상기 쌍에서 인스턴스가 존재하지 않으면, 상기 방법은 중단되고 쌍은 트리거의 리스트에 추가되지 않는다. △t 이전에 접속 값이 존재하나 △t 이내에 값이 존재하지 않으면, 이것은 트리거된 쌍의 첫 번째 인스턴스가 ORT 엔트리(예컨대, 매장 테이블(302)에서 스토어(store))를 참조하나, 두 번째 인스턴스가 어떠한 엔트리도 참조하지 않음을 의미한다. 상기 첫 번째 인스턴스에 의해 참조된 상기 ORT 엔트리를 대표하는 쌍은 UPD로서 트리거의 리스트로 들어간다. 그러나 상기 확인된 ORT 엔트리가 트리거된 쌍에서 마지막 인스턴스에 의해 참조되지 않은 이후부터, 상기 쌍은 아마도 도 5의 507 단계와 도 7의 715 단계 동안에 DEL로 변경될 것이다. 본 발명의 다른 실시예에서 이것은 트리거되는 동안에 확인될 수 있고, 상기 쌍은 DEL로서 즉시 들어갈 수 있다.

상기 트리거된 쌍이 △t 이전에 접속된 서브셋 값을 가지고 있지 않은 경우, 상기 접속된 값에 의해 확인되고 해당 쌍을 대표하는 상기 ORT 엔트리는 트리거의 리스트에 추가된다. 또한, 상기 쌍은 UPD로서 추가될 수 있고, 더불어 도 7의 단계 718의 절차 동안에 INS로 변경될 수 있다.

마지막으로, 상기 트러거링된 쌍은 도 3에 도시된 예시와 관련하여 특정 매장에서 다른 매장으로의 변경을 대표하는 특정 ORT 엔트리를 참조하는 첫 번째 인스턴스 및 다른 ORT 엔트리를 참조하는 마지막 인스턴스를 포함할 수 있다. 이 경우, 하나의 쌍은 상기 트러거링 쌍의 첫 번째 인스턴스의 접속중인 서브셋 값을 통해 참조되는 ORT 엔트리를 대표하는 트러거의 리스트에 추가될 수 있고, 두 번째 쌍은 상기 트리거된 쌍의 마지막 인스턴스의 접속중인 서브셋 링크를 통해 참조되는 ORT 엔트리를 위해 추가될 수 있다. 상기 두 개의 쌍은 트리거의 리스트에 UPD로서 추가될 수 있고, 도 7을 참조한 설명에 따른 방법에 부합되게 필터링되고 조정되고 동안에 상기 첫 번째 쌍은 DEL로 변경될 수 있고, 상기 두 번째 쌍은 INS로 변경될 수 있다.

남아있는 트리거 방법들은 도 6의 절차가 단계 606를 진행할 때 수행된다. 이 절차에서 하나 이상의 방법들은 트리거된 레코드의 역할에 따라 수행될 수 있다. 설명되는 방법들은 첫 번째는 AddChildern(pair)로서 참조될 것이다. 이 방법은 트리거된 쌍의 레코드 타입이 적어도 하나의 마더 및 차일드의 역할을 가진 경우에 수행된다. 상기 방법은 상기 트리거된 쌍이 도 6의 단계 604에서 상기 클라이언트를 업데이트하는 것을 결정시키고, 단계 605에서 상기 쌍이 수용 변경을 가지는 경우에만 수행된다. 본 발명의 실시예 중에서, 결정들을 생성하는 상기 방법들은 AddChildern(pair) 내로부터 호출될 수 있으며, 대안적인 실시예에서 단계 607의 트리거 방법이 수행된 전에 단계 604 및 605가 수행된다.

상기 방법은 진행되어, 트리거된 레코드 타입의 모든 서브셋 멤버 레코드 타입을 검사한다. 특정 서브셋 멤버 레코드 타입은 멤버 레코드 타입(Member Record Type) 또는 MRT로서 참조될 것이다. 각각의 MRT은 RT로서 참조되는 트리거된 쌍의 레코드 타입에 대한 차일드로서 확인된다. 상기 RT가 마더 또는 차일드라면 MRT는 차일드이다. 사용자 정의 수용 방법이 RT를 위하여 존재한다면, 상기 RT는 마더이다. 마더가 서브트리에 존재하면 상기 RT는 차일드이다.

RT의 차일드인 각각의 MRT에 대해, 로그는 RT 엔트리(예를 들어, 트리거된 쌍)를 참조하는 엔트리들을 확인하기 위하여 검색된다. 상기 검색 절차는 앞에서 설명한 수용을 결정하는 동안에 ORT 또는 MRT의 생성에 대해 논의과정과 유사하다. 검색 단계는 트리거된 쌍을 참조하는 MRT 테이블에서 레코드를 위한 모든 엔트리를 고려하면 상기 로그의 끝에서부터 수행될 수 있다. 적당한 후보자들은 윈도우 △t 전에, 내에 또는 후에 발견될 수 있다. 발견된 적당한 각 로그 엔트리를 위하여, 해당 쌍이 트리거의 리스트에 이미 추가되지 않은 한, 쌍은 로그에서 발견된 적당한 값을 가지며 트리거의 리스트에 추가된다. 상기 방법은 로그로부터 설정될 수 있는 모든 쌍을, 트리거된 쌍의 차일드가 되도록 결정시키는 각 MRT로부터 생성한다.

트리거된 쌍의 차일드들이 어떠한 로그 엔트리를 가지지 않고 존재할 수 있음을 인식할 것이다. 그러므로, 트러거링된 쌍에 의해 예시된 레코드를 참조하고 어떠한 로그 엔트리를 가지지 않은 엔트리를 데이터베이스에서 발견하는 것이 필요하다. 이러한 데이터베이스 엔트리는 해당 쌍이 이미 트리거의 리스트에 존재하지 않은 경우, 데이터베이스로부터 다이렉트로 인출되는 값을 가지는 쌍으로서 트리거의 리스트에 추가된다. 이것은 모든 차일드들이 발견되고 트리거의 목록에 추가될 때까지 모든 MRT 테이블을 위하여 반복된다.

트리거된 쌍이 선(son)의 역할을 가지는 것으로 결정된 경우, 트리거 방법은 AddFather(pair)로서 참조된다. 게다가, 604와 605를 참조하여 설명한 단계는 이 방법의 부분으로 수행되거나 이 방법 전의 수행될 것이다. 상기 트리거가 INS 또는 DEL로서 결정되거나, 트리거가 수용 변경을 가지는 UPD로서 결정된 경우, 파더는 트리거되어야 한다. 파더들은 상기 선(son) RT의 모든 ORT를 검사하는 것에 의해 트리거된다. 파더 이벤트가 상기 레코드 타입을 위하여 존재하고 상기 레코드 타입이 마더가 아닌 경우, 레코드 타입은 파더이다. 다시 말하면, 선언된 마더 이벤트를 가지지 않고 선언된 파더 이벤트를 가지는 트리거한 RT는 파더이다. 파더가 되어 발견되는 모든 서브셋 소유자를 위하여, 쌍은 선(son)을 통해 참조되는 목적으로 생성된다. 생성된 각각의 쌍은 로그로부터(또는 로그 엔트리가 존재하지 않으면 데이터베이스로부터) 덧붙여지는 인스턴스를 포함할 수 있다. 참조된 파더가 특정 엔트리로부터 다른 엔트리로 변경되도록 상기 선(son)이 업데이트된 경우, 참조된 두 파더를 트리거하는 것이 필요하다.

대개, 상기 선(son)이 △t에서 삭제되면, 상기 파더는 △t의 시작 전에 나타나야 되고, 상기 선(son)이 △t에서 삽입되면, 상기 파더는 △t의 끝에 나타나야 된다. 그러나 파더의 출현은 복수의 선(son)들을 대신하여 클라이언트 상에서 나타나게 되므로, 제한된 선(son)을 서버 데이터베이스에서 삭제하고 서버 단에서 선(son) 뿐만 아니라 파더를 클라이언트에서 삭제할 때, 서버 데이터베이스에서 파더를 삭제하는 것은 항상 적절하지는 않다. 그 이유는 다른 선(son), 예를 들어 상기 파더에 대해서 선(son) 역할을 가지는 테이블에서 다른 테이블 열이, 이전의 동기화 동안에 상기 클라이언트 데이터베이스에 추가될 수 있고, 더불어 이러한 다른 선(son)이 클라이언트 데이터베이스에 남아 있게 되어, 상기 클라이언트에 대한 파더의 존재가 필요하기 때문이다. 이러한 선(son)의 존재는 서버 단에서 동기화를 수행하는데 사용되는 정보로부터 손쉽게 이용되지는 않는다. 이것은 상기 클라이언트로 상기 파더 쌍에 대한 DEL 명령어를 전송한 후 클라이언트에서 상기 DEL이 수행될 수 있지는 여부를 검사하거나, 클라이언트에서 상기 파더의 존재가 계속적으로 필요한 다른 선(son)이 존재하는지 여부를 검사함으로써, 대신 처리할 수 있다. 마찬가지로, 새로운 선(son) 트리거의 삽입, 파더의 삽입 및 서버 단의 절차가 상기 트리거한 선(son)과 트리거된 파더 모두를 클라이언트로 전송하도록 지시한 경우, 파더는 이전의 클라이언트의 동기화 결과로서 상기 클라이언트에 이미 나타날 수 있다. 이것은 클라이언트 단에서 처리될 수도 있다. 본 발명의 일 실시예에 따르면, 클라이언트 단말로 업데이트된 모든 것은 파더가 업데이트되기 전에 수행되고, 파더는 필요한 파더가 삭제되지 않으며 파더가 두 번 삽입되지 않도록 업데이트된다.

상기 트리거한 레코드 타입이 브라더이면, 그것은 트리거 시스터가 필요할 수 있다. 도 3에서 발견된 상황을 예를 들면, 아이템 전체 테이블(306)은 스토어_물품 테이블(304)에 대한 시스터이다. 트리거한 시스터는 AddSisterOfBrother(pair)로서 참조된 방법에 의해 수행할 수 있다. 상기 방법은 상술한 AddFather 방법(파더에 대한 선(son) 역할을 가지는 브라더)과 동일한 방법을 통해, 상기 브라더의 파더를 발견한다. 그리고 상기 방법은 상기 파더 아래의 서브트리에서 시스터에 대한 모든 레코드 타입의 발견을 진행한다. 따라서, 앞에서 서술된 상기 방법을 사용하여 상기 파더 아래의 서브트리에서 있는 모든 시스터들이 확인되고, 상기 파더와 함께 시작하는 각 레코트 타입에 대한 트리거 절차는 AddChildren의 절차와 유사하게 수행된다. 이것은 참조되고 검사되고, 해당 서브트리에 있는 모든 레코드 타입에서 관련된 엔트리가 트리거의 목록에서 쌍으로 들어간 로그, 데이터베이스 중 어느 하나에서 회수되는 것을 의미한다.

마지막으로, 트리거한 쌍이 파더 또는 시스터인 경우, AddSister(pair)를 호출한 방법이 수행될 수 있다. 상기 AddSister(pair)는 간접적으로 마더를 확인할 필요성이 없는 경우를 제외하고, AddSisterOfBrother(pair) 방법과 유사하다. 대신에, 각각의 시스터(즉, 상기 트리거한 쌍의 RT의 각 MRT)를 위하여 트리거한 쌍을 참조하는 모든 적당한 엔트리는 확인되고, 쌍은 상술한 AddChildren(pair)와 유사한 절차를 통해 상기 로그 또는 상기 데이터베이스에서 발견되는 적당한 값을 가지는 트리거의 목록에 추가된다.

다시 도 5를 참조하면, 상술한 상기 방법에 따라서 모든 트리거 단계가 완료된 후에, 이미 설명한 바와 같이 단계 507에서 필터링과 조정을 결정하고, 실질적인 동기화를 수행하는 절차가 진행된다.

클라이언트를 업데이트하는지 여부와 업데이트할 경우 적당한 업데이트 상태가 업데이트, 삽입 또는 삭제인지 여부를 결정하기 위해서, 도 7을 참조하여 설명된 방법에 따라 쌍이 처리될 때, 상기 레코드의 모든 값을 포함하는 XML 메시지가 생성되고, 상기 클라이언트 데이터베이스로 데이터를 불러올 수 있는 방법을 통해 작동되고 데이터를 수신하는 클라이언트로 전송될 수 있다. 다른 실시예에 따르면, 상기 서버는 비동기 SOAP 호출을 사용할 수 있다.(SOAP 1.2는 레퍼런스를 통해 전체를 통합한 W3C의 권고서에 정의되어 있다). 그러나 다른 통신 프로토콜과 메시지 포맷이 본 발명의 범위 내에 속한다.

트리거 프로세스와 관련하여 상술한 내용에 따르면, 레코드, 한 번에 레코드를 배치(batch)하는 절차 또는 동시에 모든 레코드를 처리하는 절차에 의해서 트리거하고 업데이트한 레코드를 처리하는 것이 가능하다. 이에 따라, 클라이언트로 전송된 동기화 메시지는 단지 하나의 레코드, 레코드 배치 또는 삽입되거나 삭제되거나 업데이트되는 모든 레코드를 포함할 수 있다.

Claims (36)

1. 서버 컴퓨터(-상기 서버 컴퓨터는 복수의 데이터베이스 레코드와 상기 서버 컴퓨터에 의해 수행된 데이터베이스 동작에 대한 로그를 포함하는 제 1 데이터베이스를 포함함-)에서 클라이언트 장치(-상기 클라이언트 장치는 상기 클라이언트 장치에서 받아들인 데이터베이스 레코드를 포함하는 상기 제 1 데이터베이스의 부분 리프리젠테이션(partial representation)을 포함함-)를 업데이트하는 방법에 있어서,
   상기 로그를 스캔하여, 상기 클라이언트 장치의 이전 업데이트 이후에, 상기 제 1 데이터베이스에 삽입되거나 삭제되거나 변경된 제 1 레코드, 또는 선언된 수용 규칙에 의해 상기 클라이언트 장치에서 수용(acceptance)을 변경시킨 제 1 레코드를 확인하는 단계;
   상기 이전 업데이트 이후에, 상기 제 1 데이터베이스에 추가, 삭제 또는 변경되지 않은 제 2 레코드, 또는 선언된 규칙에 의해 상기 클라이언트 장치에서 수용을 변경시키지 않은 제 2 레코드를 확인하는 단계로서, 상기 제 2 레코드는 외래 키 제약(foreign key constraint)을 통하여 상기 제 1 레코드와 관련되어 있고, 상기 외래 키 제약은 상기 제 1 레코드 및 상기 제 2 레코드 중의 하나에서의 외래 키가 상기 제 1 레코드 및 상기 제 2 레코드 중의 다른 것을 유일하게 식별하는 요건인, 제 2 레코드를 확인하는 단계;
   제 1 데이터를 상기 서버 컴퓨터로부터 상기 클라이언트 장치로 전송하는 단계로서, 상기 제 1 데이터는, 상기 클라이언트 장치가 상기 제 1 레코드의 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내로의 관련 삽입, 상기 부분 리프리젠테이션으로부터의 관련 삭제, 또는 상기 부분 리프리젠테이션 내의 관련 변경을 실행하도록 하는 명령을 나타내거나, 또는 레코드에 대한 수용이 변경되고 레코드가 그때 받아들여진 경우 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내로의 삽입을 실행하고, 레코드에 대한 수용이 변경되고 레코드가 더 이상 받아들여지지 않는 경우 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터의 삭제를 실행하도록 하는 명령을 나타내는, 제 1 데이터를 상기 클라이언트 장치로 전송하는 단계; 및
   상기 제 2 데이터를 상기 서버 컴퓨터로부터 상기 클라이언트 장치로 전송하는 단계로서, 상기 제 2 데이터는, 상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내에서 준수되도록, 상기 클라이언트 장치가 상기 제 2 레코드를 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내로 삽입하거나 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 삭제하도록 하는 명령을 나타내는, 제 2 데이터를 상기 클라이언트 장치로 전송하는 단계;를 포함하는 업데이트 방법.
2. 제 1 항에 있어서,
   제 1 레코드를 확인하는 단계는,
   시간 윈도우의 시작과 종료를 결정하는 단계로서, 상기 시작은 상기 클라이언트 장치의 이전 업데이트와 관련된 시점을 나타내고 상기 종료는 상기 클라이언트 장치의 현재 업데이트와 관련된 시점을 나타내는, 결정하는 단계; 및
   상기 시간 윈도우 동안에 적어도 하나의 데이터베이스 동작에 대한 레코드로서 상기 제 1 레코드를 확인하기 위해 상기 서버 컴퓨터에 의해 수행된 데이터베이스 동작의 로그를 스캔하는 단계;를 포함하는 업데이트 방법.
3. 제 2 항에 있어서,
   상기 클라이언트 장치로 상기 제 1 데이터를 전송하기 이전에,
   - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
   -- 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
   -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
   -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
   중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
   - 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
   -- 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
   -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
   -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
   중 적어도 하나로부터, 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
   것 중 적어도 하나를 수행하고;
   
   상기 데이터베이스 동작이 상기 제 1 데이터베이스로의 상기 제 1 레코드의 삽입을 나타내고, 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하고;
   
   상기 데이터베이스 동작이 상기 제 1 데이터베이스로부터 상기 제 1 레코드의 삭제를 나타내고, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하고; 및
   
   상기 데이터베이스 동작이 상기 제 1 데이터베이스에서 상기 제 1 레코드의 변경을 나타내는 경우,
   - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 변경하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나,
   - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나, 또는
   - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않은 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하는,
   것을 특징으로 하는 업데이트 방법.
4. 제 2 항에 있어서,
   상기 제 2 데이터를 상기 클라이언트 장치로 전송하는 단계 이전에,
   - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
   -- 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
   -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
   -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
   중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
   - 상기 시간 윈도우의 끝에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
   -- 상기 시간 윈도우의 끝에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
   -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
   -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
   중 적어도 하나로부터, 상기 시간 윈도우의 끝에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
   것 중 적어도 하나를 수행하고;
   
   - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 2 레코드를 삭제하는 지시를 나타내도록 상기 제 2 데이터를 구성하거나, 또는
   - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않은 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 2 레코드를 삽입하는 지시를 나타내도록 상기 제 2 데이터를 구성하는;
   것을 특징으로 하는 업데이트 방법.
5. 제 3 항 또는 제 4 항에 있어서,
   다른 레코드에 대한 상기 대응하는 결정은,
   대표 값을 결정하기 위해 로그를 스캔하고 상기 다른 레코드에 대한 상기 클라이언트 장치에서의 상기 대표 값의 수용을 결정하는 단계를 반복함으로써 수행되는 것을 특징으로 하는 업데이트 방법.
6. 제 3 항 또는 제 4 항에 있어서,
   레코드 타입에 대한 적어도 하나의 선언된 규칙은,
   규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값을 입력으로서 수용하고, 상기 클라이언트 장치에서 상기 규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값에 대한 수용의 대응하는 결정을 생산하는 기능인 것을 특징으로 하는 업데이트 방법.
7. 제 3 항 또는 제 4 항에 있어서,
   적어도 하나의 선언된 규칙은 프로그래머 또는 상기 제 1 데이터베이스의 부분 리프리젠테이션의 사용자에 의해 선언되는 것을 특징으로 하는 업데이트 방법.
8. 제 1 항에 있어서,
   상기 제 1 데이터베이스에 추가되지 않거나, 상기 제 1 데이터베이스로부터 삭제되지 않거나, 또는 상기 제 1 데이터베이스에서 변경되지 않으며, 외래 키 제약을 통해 상기 제 2 레코드에 의해 참조되는, 제 3 레코드를 확인하는 단계;
   상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수되도록, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 상기 제 3 레코드를 삽입하도록 하거나 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 상기 제 3 레코드를 삭제하도록 지시하는 제 3 데이터를, 상기 클라이언트 장치로 전송하는 단계; 및
   모든 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수될 때까지 상기 레코드를 확인하는 단계와 상기 데이터를 전송하는 단계를 반복하는 단계;를 더 포함하는 업데이트 방법.
9. 제 1 항에 있어서,
   상기 제 1 레코드는,
   선언된 규칙과 연관된 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입이고,
   상기 제 2 레코드는,
   상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 업데이트 방법.
10. 제 1 항에 있어서,
    상기 제 1 레코드는,
    선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 업데이트 방법.
11. 제 1 항에 있어서,
    상기 제 1 레코드는, 상기 제 2 레코드의 레코드 타입의 서브셋 멤버인 레코드 타입이고, 레코드 타입의 서브셋 멤버는 상기 제 1 레코드의 레코드 타입 및 상기 제 2 레코드의 레코드 타입과 다르고;
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 레코드는, 클라이언트 장치에서의 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관되고;
    상기 제 2 레코드는, 제 1 레코드의 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 선언된 규칙과 연관된 레코드 타입의 레코드가 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입인 것을 특징으로 하는 업데이트 방법.
12. 제 1 항에 있어서,
    상기 제 1 레코드는,
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 제 1 레코드 타입의 레코드들은 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 업데이트 방법.
13. 클라이언트 장치를 업데이트하는 서버로서,
    상기 서버는, 복수의 데이터베이스 레코드 및 상기 서버에 의해 수행되는 데이터베이스 동작들의 로그를 갖는 제 1 데이터베이스를 포함하고,
    상기 클라이언트 장치는 상기 클라이언트 장치에서 수용된 데이터베이스 레코드를 포함하는 상기 제 1 데이터베이스의 부분 리프리젠테이션을 포함하며,
    상기 서버는, 프로세서 및, 기록매체에 기록된 프로그램을 포함하고,
    상기 프로그램은, 상기 프로세서가:
    상기 클라이언트 장치의 이전 업데이트 이후에 상기 제 1 데이터베이스에 삽입되거나, 상기 제 1 데이터베이스로부터 삭제되거나 또는 제 1 데이터베이스에서 변경된 제 1 레코드를 확인하고;
    상기 제 1 데이터베이스에 삽입되지 않거나, 상기 제 1 데이터베이스로부터 삭제되지 않거나 또는 제 1 데이터베이스에서 변경되지 않으면서, 외래 키 제약을 통해 상기 제 1 레코드에 의해 참조된, 제 2 레코드를 확인하며;
    상기 서버로부터 제 1 데이터를 전송하는 것으로서, 상기 제 1 데이터는, 상기 클라이언트 장치가 상기 제 1 레코드의 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내로의 관련 삽입을 수행하도록 하거나, 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 관련 삭제를 수행하도록 하거나, 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션 내의 관련 변경을 수행하도록 지시하고;
    상기 서버로부터 제 2 데이터를 전송하는 것으로서, 상기 제 2 데이터는, 상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수되도록, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 상기 제 2 레코드를 삽입하도록 하거나, 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 상기 제 2 레코드를 삭제하도록 지시하는;
    것을 수행할 수 있게 하는 명령들을 포함하는, 서버.
14. 제 13 항에 있어서,
    상기 프로그램은, 상기 프로세서가:
    시간 윈도우의 시작과 종료를 결정하고 -상기 시작은 상기 클라이언트 장치의 상기 이전 업데이트와 연관된 시간에서의 포인트를 나타내고, 상기 종료는 상기 클라이언트 장치의 현재 업데이트와 연관된 시간에서의 포인트를 나타냄-; 그리고
    상기 시간 윈도우 동안 적어도 하나의 데이터베이스 동작이 수행되는 시점에서의 레코드로서 상기 제 1 레코드를 확인하기 위해, 상기 서버에 의해 수행되는 데이터베이스 동작의 상기 로그를 스캔하여;
    상기 제 1 레코드를 확인하는 것을 수행할 수 있게 하는 명령들을 더 포함하는, 서버,
15. 제 14 항에 있어서,
    상기 프로그램은, 상기 프로세서가:
    상기 서버로 하여금 상기 제 1 데이터를 상기 클라이언트 장치로 전송하도록 하기 전에,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
    - 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
    것 중 적어도 하나를 수행하고;
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스로의 상기 제 1 레코드의 삽입을 나타내고, 상기 시간 윈도우의 끝에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하고;
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스로부터 상기 제 1 레코드의 삭제를 나타내고, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하고; 및
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스에서 상기 제 1 레코드의 변경을 나타내는 경우,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 변경하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나, 또는
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않는 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하는,
    
    것을 수행할 수 있게 하는 명령들을 더 포함하는, 서버.
16. 제 14 항에 있어서,
    상기 프로그램은, 상기 프로세서가:
    상기 서버로 하여금 상기 제 2 데이터를 상기 클라이언트 장치로 전송하도록 하기 전에,
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
    - 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
    것 중 적어도 하나를 수행하고;
    
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 2 레코드를 삭제하는 지시를 나타내도록 상기 제 2 데이터를 구성하거나, 또는
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않은 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 2 레코드를 삽입하는 지시를 나타내도록 상기 제 2 데이터를 구성하는;
    
    것을 수행할 수 있게 하는 명령들을 더 포함하는, 서버.
17. 제 15 항 또는 제 16 항에 있어서,
    다른 레코드에 대한 상기 대응하는 결정은,
    대표 값을 결정하기 위해 상기 로그를 스캔하고 상기 다른 레코드에 대한 상기 클라이언트 장치에서의 상기 대표 값의 수용을 결정하는 단계를 반복함으로써 수행되는 것을 특징으로 하는 서버.
18. 제 15 항 또는 제 16 항에 있어서,
    레코드 타입에 대한 적어도 하나의 선언된 규칙은,
    규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값을 입력으로서 수용하고, 상기 클라이언트 장치에서 상기 규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값에 대한 수용의 대응하는 결정을 생산하는 기능인 것을 특징으로 하는 서버.
19. 제 15 항 또는 제 16 항에 있어서,
    적어도 하나의 선언된 규칙은 프로그래머 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션의 사용자에 의해 선언되는 것을 특징으로 하는 서버.
20. 제 13 항에 있어서,
    상기 프로그램은, 상기 프로세서가:
    상기 제 1 데이터베이스에 추가되지 않거나, 상기 제 1 데이터베이스로부터 삭제되지 않거나, 또는 상기 제 1 데이터베이스에서 변경되지 않으며, 외래 키 제약을 통해 상기 제 2 레코드에 의해 참조되는, 제 3 레코드를 확인하고;
    상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수되도록, 서버로 하여금, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 상기 제 3 레코드를 삽입하도록 하거나 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 상기 제 3 레코드를 삭제하도록 지시하는 제 3 데이터를, 상기 클라이언트 장치로 전송하도록 하며; 및
    모든 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수될 때까지 상기 레코드를 확인하는 과정과 상기 서버로 하여금 데이터를 전송하게 하는 과정을 반복하도록;
    하는 것을 수행할 수 있게 하는 명령들을 더 포함하는, 서버.
21. 제 13 항에 있어서,
    상기 제 1 레코드는,
    선언된 규칙과 연관된 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 서버.
22. 제 13 항에 있어서,
    상기 제 1 레코드는,
    선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 서버.
23. 제 13 항에 있어서,
    상기 제 1 레코드는, 상기 제 2 레코드의 레코드 타입의 서브셋 멤버인 레코드 타입이고, 레코드 타입의 서브셋 멤버는 상기 제 1 레코드의 레코드 타입 및 상기 제 2 레코드의 레코드 타입과 다르고;
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 레코드는, 클라이언트 장치에서의 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관되고;
    상기 제 2 레코드는, 제 1 레코드의 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 상기 선언된 규칙과 연관된 레코드 타입의 레코드가 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입인 것을 특징으로 하는 서버.
24. 제 13 항에 있어서,
    상기 제 1 레코드는,
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 제 1 레코드 타입의 레코드들은 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는 서버.
25. 서버 컴퓨터가 클라이언트 장치를 업데이트할 수 있도록 하는 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체로서,
    상기 서버 컴퓨터는, 복수의 데이터베이스 레코드 및 상기 서버 컴퓨터에 의해 수행되는 데이터베이스 동작들의 로그를 갖는 제 1 데이터베이스를 포함하고,
    상기 클라이언트 장치는 상기 클라이언트 장치에서 승인된 데이터베이스 레코드를 포함하는 상기 제 1 데이터베이스의 부분 리프리젠테이션을 포함하며,
    
    상기 컴퓨터 프로그램은, 실행될 때, 서버 컴퓨터로 하여금,
    상기 클라이언트 장치의 이전 업데이트 이후에 상기 제 1 데이터베이스에 삽입되거나, 상기 제 1 데이터베이스로부터 삭제되거나 또는 제 1 데이터베이스에서 변경된 제 1 레코드를 확인하고;
    상기 제 1 데이터베이스에 추가되지 않거나, 상기 제 1 데이터베이스로부터 삭제되지 않거나 또는 제 1 데이터베이스에서 변경되지 않은, 외래 키 제약을 통해 상기 제 1 레코드에 의해 참조되는, 제 2 레코드를 확인하며;
    상기 서버 컴퓨터로부터 제 1 데이터를 전송하는 것으로서, 상기 제 1 데이터는, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 관련 삽입을 수행하도록 하거나, 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 삭제를 수행하도록 하거나, 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 상기 제 1 레코드의 변경을 수행하도록 지시하고;
    상기 서버 컴퓨터로부터 제 2 데이터를 전송하는 것으로서, 상기 제 2 데이터는, 상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수되도록, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 상기 제 2 레코드를 삽입하도록 하거나, 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 상기 제 2 레코드를 삭제하도록 지시하는;
    것을 수행하도록 하는 명령을 포함하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
26. 제 25 항에 있어서,
    상기 제 1 레코드를 확인하는 것은,
    시간 윈도우의 시작과 종료를 결정하고 -상기 시작은 상기 클라이언트 장치의 상기 이전 업데이트와 연관된 시간에서의 포인트를 나타내고, 상기 종료는 상기 클라이언트 장치의 현재 업데이트와 연관된 시간에서의 포인트를 나타냄-; 그리고
    상기 시간 윈도우 동안 적어도 하나의 데이터베이스 동작이 수행되는 시점에서의 레코드로서 상기 제 1 레코드를 확인하기 위해, 상기 서버 컴퓨터에 의해 수행되는 데이터베이스 동작의 상기 로그를 스캔하는;
    것을 포함하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
27. 제 26 항에 있어서,
    상기 컴퓨터 프로그램은, 실행될 때, 서버 컴퓨터로 하여금,
    상기 제 1 데이터를 상기 클라이언트 장치로 전송하도록 하기 전에,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
    - 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 1 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 1 레코드와 다르고 서브셋 제약을 통해 상기 제 1 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
    것 중 적어도 하나를 수행하고;
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스로의 상기 제 1 레코드의 삽입을 나타내고, 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하고;
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스로부터 상기 제 1 레코드의 삭제를 나타내고, 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하고; 및
    
    상기 데이터베이스 동작이 상기 제 1 데이터베이스에서 상기 제 1 레코드의 변경을 나타내는 경우,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 변경하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나,
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 1 레코드를 삭제하는 지시를 나타내도록 상기 제 1 데이터를 구성하거나, 또는
    - 상기 시간 윈도우의 시작에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않은 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 1 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되여야 하는 것으로 결정되는 경우, 상기 제 1 레코드를 삽입하는 지시를 나타내도록 상기 제 1 데이터를 구성하는,
    것을 수행하도록 하는 명령을 더 포함하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
28. 제 26 항에 있어서,
    상기 컴퓨터 프로그램은, 실행될 때, 서버 컴퓨터로 하여금,
    상기 제 2 데이터를 상기 클라이언트 장치로 전송하도록 하기 전에,
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되었는지 결정하며; 및
    - 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값을 결정하기 위해 상기 로그를 스캔하고, 그리고,
    -- 상기 시간 윈도우의 끝에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값,
    -- 상기 제 2 레코드가 속하는 레코드 타입에 대한 선언된 규칙(rule), 그리고
    -- 상기 제 2 레코드와 다르고 서브셋 제약을 통해 상기 제 2 레코드와 연관된 레코드에 대한 대응하는 결정
    중 적어도 하나로부터, 상기 시간 윈도우의 끝에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이, 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는지 결정하는;
    것 중 적어도 하나를 수행하고;
    
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용된 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어서는 안 되는 것으로 결정되는 경우, 상기 제 2 레코드를 삭제하는 지시를 나타내도록 상기 제 2 데이터를 구성하거나, 또는
    - 상기 시간 윈도우의 시작에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 시작에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되지 않은 것으로 결정되고, 그리고 상기 시간 윈도우의 종료에서 상기 제 2 레코드의 상태를 대표하는 적어도 하나의 값이 상기 시간 윈도우의 종료에서 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것으로 결정되는 경우, 상기 제 2 레코드를 삽입하는 지시를 나타내도록 상기 제 2 데이터를 구성하는;
    것을 수행하도록 하는 명령을 더 포함하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
29. 제 27 항 또는 제 28 항에 있어서,
    다른 레코드에 대한 상기 대응하는 결정은,
    대표 값을 결정하기 위해 상기 로그를 스캔하고 상기 다른 레코드에 대한 상기 클라이언트 장치에서의 상기 대표 값의 수용을 결정하는 단계를 반복함으로써 수행되는 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
30. 제 27 항 또는 제 28 항에 있어서,
    레코드 타입에 대한 적어도 하나의 선언된 규칙은,
    규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값을 입력으로서 수용하고, 상기 클라이언트 장치에서 상기 규칙이 선언된 레코드 타입의 레코드의 상태를 대표하는 값에 대한 수용의 대응하는 결정을 생산하는 기능인 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
31. 제 27 항 또는 제 28 항에 있어서,
    적어도 하나의 선언된 규칙은 프로그래머 또는 제 1 데이터베이스의 상기 부분 리프리젠테이션의 사용자에 의해 선언되는 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
32. 제 25 항에 있어서,
    상기 컴퓨터 프로그램은, 실행될 때, 서버 컴퓨터로 하여금,
    상기 제 1 데이터베이스에 추가되지 않거나, 상기 제 1 데이터베이스로부터 삭제되지 않거나, 또는 상기 제 1 데이터베이스에서 변경되지 않은, 외래 키 제약을 통해 상기 제 2 레코드에 의해 참조되는, 제 3 레코드를 확인하고;
    상기 클라이언트 장치로 제 3 데이터를 전송하는 것으로서, 상기 제 3 데이터는, 상기 외래 키 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수되도록, 상기 클라이언트 장치가 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에 상기 제 3 레코드를 삽입하도록 하거나 또는 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션으로부터 상기 제 3 레코드를 삭제하도록 지시하는; 및
    모든 제약이 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 준수될 때까지 상기 레코드를 확인하는 과정과 데이터를 전송하게 하는 과정을 반복하는;
    것을 수행하도록 하는 명령을 더 포함하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
33. 제 25 항에 있어서,
    상기 제 1 레코드는,
    선언된 규칙과 연관된 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
34. 제 25 항에 있어서,
    상기 제 1 레코드는,
    선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입인 레코드 타입으로서, 클라이언트 장치에서 상기 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관된 레코드 타입의 서브셋 멤버 레코드 타입의 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드의 레코드 타입에 관한 서브셋 멤버 레코드 타입의 레코드 타입인 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
35. 제 25 항에 있어서,
    상기 제 1 레코드는 상기 제 2 레코드의 레코드 타입의 서브셋 멤버인 레코드 타입이고, 레코드 타입의 서브셋 멤버는 상기 제 1 레코드의 레코드 타입 및 상기 제 2 레코드의 레코드 타입과 다르며;
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 레코드는, 클라이언트 장치에서의 선언된 규칙과 연관된 레코드 타입의 레코드의 상태를 대표하는 값의 수용을 결정하기 위한 선언된 규칙과 연관되고;
    상기 제 2 레코드는, 제 1 레코드의 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 선언된 규칙과 연관된 레코드 타입의 레코드가 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입인 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.
36. 제 25 항에 있어서,
    상기 제 1 레코드는,
    상기 제 1 레코드 및 상기 제 2 레코드와 다른 레코드 타입의 적어도 하나의 레코드에 관련된 제약을 준수하는 것이 요구되는 경우, 제 1 레코드 타입의 레코드들은 오직 상기 제 1 데이터베이스의 상기 부분 리프리젠테이션에서 수용되어야 하는 것을 명시하는 선언된 규칙과 연관된 레코드 타입이고,
    상기 제 2 레코드는,
    상기 제 1 레코드 타입에 관한 서브셋 멤버 레코드 타입인 레코드 타입인 것을 특징으로 하는, 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.

Images