特許 5676598 部分データベースの増分更新を実行するための方法、システム、およびデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5676598

(24)【登録日】2015年1月9日

(45)【発行日】2015年2月25日

(54)【発明の名称】部分データベースの増分更新を実行するための方法、システム、およびデバイス

(51)【国際特許分類】

   G06F 12/00 20060101AFI20150205BHJP

【ＦＩ】

   G06F12/00 533J

   G06F12/00 545F

【請求項の数】36

【全頁数】56

(21)【出願番号】特願2012-519492(P2012-519492)

(86)(22)【出願日】2010年7月2日

(65)【公表番号】特表2012-533108(P2012-533108A)

(43)【公表日】2012年12月20日

(86)【国際出願番号】NO2010000260

(87)【国際公開番号】WO2011005106

(87)【国際公開日】20110113

【審査請求日】2013年6月21日

(31)【優先権主張番号】12/500,370

(32)【優先日】2009年7月9日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512007351

【氏名又は名称】ノルシンク・テクノロジー・アーエス

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ビヨルン−ハラルト・スヨクレン

【審査官】 加内 慎也

(56)【参考文献】

【文献】 特開２００１−１１７８００（ＪＰ，Ａ）

【文献】 特開２０００−２７６３９１（ＪＰ，Ａ）

【文献】 特表２００２−５１１１６４（ＪＰ，Ａ）

【文献】 特開２００１−１４２７６６（ＪＰ，Ａ）

【文献】 特表２００３−５２７６８８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００４／０２１５６７０（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０１５３４２３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

サーバコンピュータ内で前記サーバコンピュータからクライアントデバイスを更新するための方法であって、前記サーバコンピュータが、複数のデータベース記録と、前記サーバコンピュータによって実行されたデータベース動作のログとを備えた第1のデータベースを含み、前記クライアントデバイスが、前記クライアントデバイスにおいて受け入れられたデータベース記録を含む前記第1のデータベースの部分表現を含み、前記方法が、
前記クライアントデバイスの前の更新に続いて、前記第1のデータベース内に挿入されている、前記第1のデータベースから削除されている、または前記第1のデータベース内で変更されている第1の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させた第1の記録を識別するために、前記ログを走査するステップと、
前記前の更新に続いて、前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていない第2の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させていない第2の記録を識別するステップであって、前記第2の記録は外部キー制約を介して前記第1の記録に関係し、前記外部キー制約は、前記第1の記録および前記第2の記録のうちの１つで外部キーが、前記第1の記録および前記第2の記録のうちの他方を一意に識別するという要件である、識別するステップと、
第1のデータを前記サーバコンピュータから前記クライアントデバイスに送信するステップであって、前記第1のデータが、前記第1の記録の前記第1のデータベースの前記部分表現内への関連挿入、前記部分表現からの関連削除、または前記部分表現内の関連変更を実行するための前記クライアントへの命令、または、前記記録に関する受け入れが変更され、前記記録がそのとき受け入れられた場合、前記第1のデータベースの前記部分表現内への挿入を実行し、前記記録に関する受け入れが変更され、前記記録がもはや受け入れられない場合、前記第1のデータベースの前記部分表現からの削除を実行するための前記クライアントへの命令を表す、送信するステップと、
第2のデータを前記サーバコンピュータから前記クライアントデバイスに送信するステップであって、前記第2のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記第2の記録を前記第1のデータベースの前記部分表現内に挿入する、または前記部分表現から削除するための前記クライアントへの命令を表す、送信するステップとを含む方法。

【請求項2】

前記第1の記録を前記識別するステップが、
時間窓の開始と終了とを決定するステップであって、前記開始が前記クライアントデバイスの前記前の更新に関連する時点を表し、前記終了が前記クライアントデバイスの現在の更新に関連する時点を表す、決定するステップと、
少なくとも1つのデータベース動作が前記時間窓の間に実行されている記録として前記第1の記録を識別するために、前記サーバコンピュータによって実行されたデータベース動作の前記ログを走査するステップと
を含む、請求項1に記載の方法。

【請求項3】

前記第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の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第1の記録を挿入する命令を表すように
前記第1のデータを構成するステップと
をさらに含む、請求項2に記載の方法。

【請求項4】

前記第2のデータを前記クライアントデバイスに送信するのに先立って、
前記時間窓の前記開始時に前記第2の記録の状態を表す少なくとも1つの値を決定するために、前記ログを走査して、
前記時間窓の前記開始時に前記第2の記録の状態を表す前記値、
前記第2の記録が属する記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記開始時に部分データベース内に受け入れられたかどうかを決定するステップと、
前記時間窓の前記終了時に前記第2の記録の前記状態を表す少なくとも1つの値を決定するために、前記ログを走査して、
前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値、
前記第2の記録が属する前記記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきかどうかを決定するステップと、
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられたことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきでないこととが決定された場合、前記第2の記録を削除する命令を表すように、または
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられなかったことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第2の記録を挿入する命令を表すように
前記第2のデータを構成するステップと
をさらに備える、請求項2に記載の方法。

【請求項5】

異なる記録に関する前記対応する決定が、代表値を決定するために、前記ログを前記走査するステップと、前記異なる記録に関する前記値の前記クライアントデバイス上への受入れを前記決定するステップとを繰り返すことによって実行される、請求項3または4に記載の方法。

【請求項6】

記録タイプに関して、少なくとも1つの宣言された規則が、前記記録タイプの記録の状態を表す値を入力として受け入れて、前記値の前記クライアントデバイス上への受入れの対応する決定を生み出すための関数である、請求項3または4に記載の方法。

【請求項7】

少なくとも1つの宣言された規則が、前記部分データベースのプログラマまたはユーザによって宣言される、請求項3または4に記載の方法。

【請求項8】

前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていないが、外部キー制約を介して前記第2の記録に参照される第3の記録を識別するステップと、
第3のデータを前記クライアントデバイスに送信するステップであって、前記第3のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記クライアントデバイスに、前記第3の記録を前記第1のデータベースの前記部分表現内に挿入するように、または前記部分表現から削除するように命令する、送信するステップと、
すべての制約が部分データベース内で満たされるまで、記録を前記識別するステップと、データを前記送信するステップとを繰り返すステップと
を含む、請求項1に記載の方法。

【請求項9】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項1に記載の方法。

【請求項10】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのサブセットメンバー記録タイプである記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項1に記載の方法。

【請求項11】

前記第1の記録が、前記第2の記録の記録タイプと、前記第1の記録の前記記録タイプと前記第2の記録の前記記録タイプとは異なる記録タイプとのサブセットメンバーである記録タイプのものであり、
前記第1の記録と前記第2の記録とは異なる記録タイプを備えた記録が、前記記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連し、
前記第2の記録が、前記記録を前記第1の記録の前記記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、前記記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものである、請求項1に記載の方法。

【請求項12】

前記第1の記録が、前記記録を前記第1の記録と前記第2の記録とは異なる記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、第1の記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものであり、
前記第2の記録が、前記第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項1に記載の方法。

【請求項13】

クライアントデバイスを更新するように構成されたサーバであって、前記サーバが、複数のデータベース記録と、前記サーバによって実行されたデータベース動作のログとを備えた第1のデータベースを含み、前記クライアントデバイスが、前記クライアントデバイスにおいて受け入れられたデータベース記録を含む前記第1のデータベースの部分表現を含み、前記サーバが、
前記クライアントデバイスの前の更新に続いて、前記第1のデータベース内に挿入されている、前記第1のデータベースから削除されている、または前記第1のデータベース内で変更されている第1の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させた第1の記録を識別するために、前記ログを走査し、
前記前の更新に続いて、前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていない第2の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させていない第2の記録を識別し、
前記第2の記録は外部キー制約を介して前記第1の記録に関係し、前記外部キー制約は、前記第1の記録および前記第2の記録のうちの１つで外部キーが、前記第1の記録および前記第2の記録のうちの他方を一意に識別するという要件であり、
前記サーバに、
第1のデータを前記サーバから前記クライアントデバイスに送信させるステップであって、前記第1のデータが、前記第1の記録の前記第1のデータベースの前記部分表現内への関連挿入、前記部分表現からの関連削除、または前記部分表現内の関連変更を実行するための前記クライアントへの命令、または、前記記録に関する受け入れが変更され、前記記録がそのとき受け入れられた場合、前記第1のデータベースの前記部分表現内への挿入を実行し、前記記録に関する受け入れが変更され、前記記録がもはや受け入れられない場合、前記第1のデータベースの前記部分表現からの削除を実行するための前記クライアントへの命令を表す、送信させるステップと、
第2のデータを前記サーバから前記クライアントデバイスに送信させるステップであって、前記第2のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記第2の記録を前記第1のデータベースの前記部分表現内に挿入する、または前記部分表現から削除するための前記クライアントへの命令を表す、送信させるステップと
を行わせるようにプログラムされたプロセッサを備えるサーバ。

【請求項14】

前記プロセッサが、
時間窓の開始と終了とを決定するステップであって、前記開始が前記クライアントデバイスの前記前の更新に関連する時点を表し、前記終了が前記クライアントデバイスの現在の更新に関連する時点を表す、決定するステップと、
少なくとも1つのデータベース動作が前記時間窓の間に実行されている記録として前記第1の記録を識別するために、前記サーバによって実行されるデータベース動作の前記ログを走査するステップと
によって前記第1の記録を識別するようにプログラムされた、請求項13に記載のサーバ。

【請求項15】

前記プロセッサが、
前記サーバに前記第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の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第1の記録を挿入する命令を表すように
前記第1のデータを構成するステップと
を実行するようにさらにプログラムされた、請求項14に記載のサーバ。

【請求項16】

前記プロセッサが、
前記サーバに前記第2のデータを前記クライアントデバイスに送信させるのに先立って、
前記時間窓の前記開始時に前記第2の記録の状態を表す少なくとも1つの値を決定するために、前記ログを走査して、
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値、
前記第2の記録が属する記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記開始時に部分データベース内に受け入れられたかどうかを決定するステップと、
前記時間窓の前記終了時に前記第2の記録の前記状態を表す少なくとも1つの値を決定するために、前記ログを走査して、
前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値
前記第2の記録が属する前記記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきかどうかを決定するステップと、
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられたことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきでないこととが決定された場合、前記第2の記録を削除する命令を表すように、または
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられなかったことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第2の記録を挿入する命令を表すように
前記第2のデータを構成するステップと
を行うようにさらにプログラムされた、請求項14に記載のサーバ。

【請求項17】

異なる記録に関して前記対応する決定が、代表値を決定するために、前記ログを前記走査するステップと、前記異なる記録に関する前記値の前記クライアントデバイス上への受入れを前記決定するステップとを繰り返すことによって実行される、請求項15または16に記載のサーバ。

【請求項18】

記録タイプに関して、少なくとも1つの宣言された規則が、前記記録タイプの記録の状態を表す値を入力として受け入れて、前記値の前記クライアントデバイス上への受入れの対応する決定を生み出すための関数である、請求項15または16に記載のサーバ。

【請求項19】

少なくとも1つの宣言された規則が、前記部分データベースのプログラマまたはユーザによって宣言される、請求項15または16に記載のサーバ。

【請求項20】

前記プロセッサが、
前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていないが、外部キー制約を介して前記第2の記録に参照される第3の記録を識別するステップと、
前記サーバに、第3のデータを前記クライアントデバイスに送信させるステップであって、前記第3のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記クライアントデバイスに、前記第3の記録を前記第1のデータベースの前記部分表現内に挿入するように、または前記部分表現から削除するように命令する、送信させるステップと、
すべての制約が部分データベース内で満たされるまで、記録を前記識別するステップと、前記サーバにデータを前記送信させるステップとを繰り返すステップと
を行うようにさらにプログラムされる、請求項13に記載のサーバ。

【請求項21】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項13に記載のサーバ。

【請求項22】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのサブセットメンバー記録タイプである記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項13に記載のサーバ。

【請求項23】

前記第1の記録が、前記第2の記録の記録タイプと、前記第1の記録の前記記録タイプと前記第2の記録の前記記録タイプとは異なる記録タイプとのサブセットメンバーである記録タイプのものであり、
前記第1の記録と前記第2の記録とは異なる記録タイプを備えた記録が、前記記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連し、
前記第2の記録が、前記記録を前記第1の記録の前記記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、前記記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものである、請求項13に記載のサーバ。

【請求項24】

前記第1の記録が、前記記録を前記第1の記録と前記第2の記録とは異なる記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、第1の記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものであり、
前記第2の記録が、前記第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項13に記載のサーバ。

【請求項25】

サーバコンピュータがクライアントデバイスを更新することを可能にするために、その上でコンピュータプログラムが実施されるコンピュータ可読媒体であって、前記サーバコンピュータが、複数のデータベース記録と、前記サーバコンピュータによって実行されたデータベース動作のログとを備えた第1のデータベースを含み、前記クライアントデバイスが、前記クライアントデバイスにおいて受け入れられたデータベース記録を含む前記第1のデータベースの部分表現を含み、前記コンピュータプログラムが、実行されたとき、前記サーバコンピュータに、
前記クライアントデバイスの前の更新に続いて、前記第1のデータベース内に挿入されている、前記第1のデータベースから削除されている、または前記第1のデータベース内で変更されている第1の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させた第1の記録を識別するために、前記ログを走査するステップと、
前記前の更新に続いて、前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていない第2の記録、または、宣言された受け入れ規則によって前記クライアントデバイスでその受け入れを変更させていない第2の記録を識別するステップであって、前記第2の記録は外部キー制約を介して前記第1の記録に関係し、前記外部キー制約は、前記第1の記録および前記第2の記録のうちの１つで外部キーが、前記第1の記録および前記第2の記録のうちの他方を一意に識別するという要件である、識別するステップと、
第1のデータを前記サーバコンピュータから前記クライアントデバイスに送信するステップであって、前記第1のデータが、前記第1の記録の前記第1のデータベースの前記部分表現内への関連挿入、前記部分表現からの関連削除、または前記部分表現内の関連変更とを実行するための前記クライアントへの命令、または、前記記録に関する受け入れが変更され、前記記録がそのとき受け入れられた場合、前記第1のデータベースの前記部分表現内への挿入を実行し、前記記録に関する受け入れが変更され、前記記録がもはや受け入れられない場合、前記第1のデータベースの前記部分表現からの削除を実行するための前記クライアントへの命令を表す、送信するステップと、
第2のデータを前記サーバコンピュータから前記クライアントデバイスに送信するステップであって、前記第2のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記第2の記録を前記第1のデータベースの前記部分表現内に挿入する、または前記部分表現から削除するための前記クライアントへの命令を表す、送信するステップと
を実行させる命令を含むコンピュータ可読媒体。

【請求項26】

前記第1の記録を前記識別するステップが、
時間窓の開始と終了とを決定するステップであって、前記開始が前記クライアントデバイスの前記前の更新に関連する時点を表し、前記終了が前記クライアントデバイスの現在の更新に関連する時点を表す、決定するステップと、
少なくとも1つのデータベース動作が前記時間窓の間に実行されている記録として前記第1の記録を識別するために、前記サーバコンピュータによって実行されたデータベース動作の前記ログを走査するステップとを含む、請求項25に記載のコンピュータ可読媒体。

【請求項27】

実行されたとき、前記サーバコンピュータに、
前記第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の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第1の記録を挿入する命令を表すように
前記第1のデータを構成するステップと
を実行させる命令をさらに含む、請求項26に記載のコンピュータ可読媒体。

【請求項28】

実行されたとき、前記サーバコンピュータに、
前記第2のデータを前記クライアントデバイスに送信するのに先立って、
前記時間窓の前記開始時に前記第2の記録の状態を表す少なくとも1つの値を決定するために、前記ログを走査して、
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値、
前記第2の記録が属する記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記開始時に部分データベース内に受け入れられたかどうかを決定するステップと、
前記時間窓の前記終了時に前記第2の記録の前記状態を表す少なくとも1つの値を決定するために、前記ログを走査して
前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値、
前記第2の記録が属する前記記録タイプに関して宣言された規則、および
前記第2の記録とは異なるが、サブセット制約を介して前記第2の記録に関連する記録に関する対応する決定
のうちの少なくとも1つから、前記値が前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであるかどうかを決定するステップと、
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられたことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきでないこととが決定された場合、前記第2の記録を削除する命令を表すように、または
前記時間窓の前記開始時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記開始時に前記部分データベース内に受け入れられなかったことと、前記時間窓の前記終了時に前記第2の記録の前記状態を表す前記値が、前記時間窓の前記終了時に前記部分データベース内に受け入れられるべきであることとが決定された場合、前記第2の記録を挿入する命令を表すように
前記第2のデータを構成するステップと
を行わせる命令をさらに含む、請求項26に記載のコンピュータ可読媒体。

【請求項29】

異なる記録に関して前記対応する決定が、代表値を決定するために、前記ログを前記走査するステップと、前記異なる記録に関する前記値の前記クライアントデバイス上への受入れを前記決定するステップとを繰り返すことによって実行される、請求項27または28に記載のコンピュータ可読媒体。

【請求項30】

記録タイプに関して、少なくとも1つの宣言された規則が、前記記録タイプの記録の状態を表す値を入力として受け入れて、前記値の前記クライアントデバイス上への受入れの対応する決定を生み出すための関数である、請求項27または28に記載のコンピュータ可読媒体。

【請求項31】

少なくとも1つの宣言された規則が、前記部分データベースのプログラマまたはユーザによって宣言される、請求項27または28に記載のコンピュータ可読媒体。

【請求項32】

実行されたとき、前記サーバコンピュータに、
前記第1のデータベースに追加されていない、前記第1のデータベースから削除されていない、または前記第1のデータベース内で変更されていないが、外部キー制約を介して、前記第2の記録に参照される第3の記録を識別するステップと、
第3のデータを前記クライアントデバイスに送信するステップであって、前記第3のデータが、前記外部キー制約が前記第1のデータベースの前記部分表現内で満たされるように、前記クライアントデバイスに、前記第3の記録を前記第1のデータベースの前記部分表現内に挿入するように、または前記部分表現から削除するように命令する、送信するステップと、
すべての制約が部分データベース内で満たされるまで、記録を前記識別するステップと、データを前記送信するステップとを繰り返すステップとを行わせる命令をさらに含む、請求項25に記載のコンピュータ可読媒体。

【請求項33】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項25に記載のコンピュータ可読媒体。

【請求項34】

前記第1の記録が、記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連する記録タイプのサブセットメンバー記録タイプである記録タイプのものであり、
前記第2の記録が、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項25に記載のコンピュータ可読媒体。

【請求項35】

前記第1の記録が、前記第2の記録の記録タイプと、前記第1の記録の前記記録タイプと前記第2の記録の前記記録タイプとは異なる記録タイプとのサブセットメンバーである記録タイプのものであり、
前記第1の記録と前記第2の記録とは異なる記録タイプを備えた記録が、前記記録タイプの記録の状態を表す値のクライアントデバイス上への受入れを決定するための宣言された規則に関連し、
前記第2の記録が、前記記録を前記第1の記録の前記記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、前記記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものである、請求項25に記載のコンピュータ可読媒体。

【請求項36】

前記第1の記録が、前記記録を前記第1の記録と前記第2の記録とは異なる記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、第1の記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものであり、前記第2の記録が、前記第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである、請求項25に記載のコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバコンピュータとクライアントコンピュータとの間のデータ同期に関する。より詳細には、本発明は、サーバデータベース内および1つまたは複数のクライアントデータベース内の変更を追跡して、収集し、関連変更に従って、同期することに関する。

【背景技術】

【0002】

中央コンピュータサーバシステム内に格納されたデータベースは、常にオンライン上にない可能性があるクライアントコンピュータ内で部分的に複製または複写可能である。結果として、データベースサーバシステムと1つまたは複数のクライアントコンピュータとの間のデータベース同期の必要が生じ、この同期は、両方向の変更を必要とする可能性、すなわち、変更がクライアントコンピュータ上、ならびにサーバシステム上のデータに対して行われている可能性がある。そのデータがサーバ上で変更されたために、クライアントに転送されるべきであるデータに加えて、変更されていないが、データベース内のいくつかの他の変更の結果として、前の同期の後のいずれかの時点でクライアントに関連性を持つことになったデータを転送することも必要な場合がある。すなわち、サーバ上で変更されているデータ記録を用いてクライアントを更新することに加えて、サーバ上で変更されていない一部の記録は、それでもなお、クライアントコンピュータから削除されなければならないか、またはクライアントコンピュータに追加されなければならない可能性がある。

【0003】

一例は、店舗の在庫品を表す部分データベースを含むモバイルデバイスに関連しうる。これらのデバイスは、棚卸を行うか、または再供給するための必要購入を登録するために使用可能である。その場合、モバイルデバイスが最後に同期されてから中央データベース内に登録された利用可能な製品のリストに変更が行われている可能性があることを容易に理解されよう。同様に、店舗内の従業員によって登録された実際の在庫品または特定の商品を補充するために仕入れるための注文を表す変更がモバイルデバイスに行われている可能性がある。加えて、中央データベースから利用可能なデータのその部分がクライアントデバイス上の部分データベースに関連して変更されている場合がある。

【0004】

例えば、クライアントデバイスは、店舗のハードウェア部門およびスポーツ部門の棚卸をするために使用されている可能性があり、その結果として、ハードウェア製品とスポーツ製品とを含む部分データベースを用いて更新されている可能性がある。後の時点で、同じデバイスはハードウェア部門においてもはや使用されないものの、そのデバイスが同じ店舗の衣類部門で必要な購入を登録するために割り当てられる場合がある。クライアントをデータベースと同期させることは、この場合、ハードウェア製品に関係するデータベースの一部を除去して、スポーツ製品に関係するデータベースの一部を追加し、中央データベース内の衣類製品のリストに対する変更の結果として生じるすべての必要な更新を行うべきである。

【0005】

クライアントを同期する問題に対するブルートフォース(brute force)解決策は、クライアント上で行われてきたすべての更新をまずデータベースにインポートし、次いで、クライアント上のすべてのデータベースデータを削除し、最終的に、データベース全体または部分データベースをクライアントに再度エクスポートすることである。これは、クライアント上のすべてのデータが同期の時点で現在のものであることを確実にするが、多くのデータ転送を必要とし、同期が実行されている間に、他のクライアントとの相互作用を処理するシステムの能力に干渉する可能性もある。インポートするおよびエクスポートするという用語は、別段の注釈がない限り、メイン(サーバ)データベースに関して使用されることになる点に留意されたい。したがって、「インポートする」、または「にインポートする」は、新しいデータをクライアントからデータベースに導入することを指し、一方、「エクスポートする」、または「からエクスポートする」は、データをサーバデータベースからクライアントデータベースに導入することまたは当該データを更新することを意味する。

【0006】

提案される代替案は、メインデータベース内のすべての記録に対するすべての更新のデータベースログを維持して、同期をこのログに基づかせることである。前の同期におけるデータベースの状態が知られており、前の同期と進行中の同期との間のすべてのデータベーストランザクションが知られている場合、その変更ログに基づいて、実際のデータベースに干渉せずに、クライアントを更新することが可能である。このログに基づいて、2つの同期間のデータベースに対するすべての変更の概要を作成することが可能である。この概要は、2つの同期間のデータベース内の差異である、データベースΔと考えることができる。

【0007】

クライアントがメインデータベースの完全な複写を含む場合、クライアントを更新するためにデータベースΔを使用することは、かなり簡単である。その場合、クライアントはデータベースΔ全体を用いて更新されるべきであり、すべての変更はそのクライアントに送信されなければならない。しかし、クライアントが部分データベースだけを含む場合、同期されている特定のクライアントに関連するデータベースΔ内の記録を識別して、それらの記録だけを転送することが必要である。加えて、変更されていない記録、すなわち、データベースΔの一部ではないが、他の理由でクライアントに必要になった記録を転送することが必要な場合がある。

【0008】

変更されていない記録は、様々な理由でクライアントに関連することになる可能性がある。一般的には、2つのクラスの理由が識別可能であり、それらは内部理由と外部理由と呼ばれる場合がある。内部理由は、制約を満たして、関連データがクライアント上に実際に存在することを確実にするために、ある記録(データベースΔの一部である記録)内の変更が追加の(変更されていない)記録をクライアントにインポートすることを必要にする場合を含む。外部理由は、データベース自体に対して外的な何らかの事実が、例えば、特定の時点である記録をクライアントにインポートすることを妥当にする場合を含む。後者の例は、たとえ前の同期の時点に準備されていても、その作業が実行される予定の日までクライアントに転送されるべきでない作業指示書でありうる。

【0009】

類似の理由で、前の同期の時点でクライアント内の部分データベースに関連した記録は、その記録自体が変更されていない場合でも、無関係になる場合があり、その結果として、変更されていない記録を除去することが必要な場合がある。

【発明の概要】

【発明が解決しようとする課題】

【0010】

結果として、制約を満たすと同時に、部分データベースの増分同期を実行することが可能な方法およびシステムの必要が存在する。

【課題を解決するための手段】

【0011】

本発明は、サーバコンピュータシステムからクライアントデバイスを更新または同期するための方法、コンピュータシステム、およびコンピュータ可読媒体に関する。このサーバコンピュータシステムは、データベースを含み、クライアントデバイスは、サーバ上にそのデータベースの部分表現を保持する。データベースの部分表現は、サーバコンピュータシステム内に存在するデータベース記録のサブセットを含み、このサブセットは、クライアントにおいて受け入れられる記録と呼ばれる場合がある。この方法は、データベース制約が満たされると同時に、クライアントの増分同期を可能にする。

【0012】

サーバコンピュータから電子クライアントデバイスを更新するために、本発明に従って動作しているサーバコンピュータは、したがって、複数のデータベース記録を備えた第1のデータベースを含むことが可能であり、一方、クライアントデバイスは、第1のデータベースの部分表現を含む。部分データベースは、クライアントデバイスにおいて受け入れられたデータベース記録を含む。そのようなコンピュータシステム上で実行している方法は、次いで、クライアントの前の更新に続いて、第1のデータベース内に挿入されている、第1のデータベースから削除されている、または第1のデータベース内で変更されている第1の記録を識別するステップと、第1のデータベースに追加されていない、第1のデータベースから削除されていない、または第1のデータベース内で変更されていないが、制約を介して第1の記録に関係する第2の記録を識別するステップとを含むことが可能である。これらの識別された記録に基づいて、この方法は、次いで、クライアントデバイスに、第1の記録の第1のデータベースの部分表現内への対応する挿入、その部分表現からの対応する削除、またはその部分表現内の対応する変更を実行するように命令する第1のデータをサーバコンピュータから送信し、この方法は、第2のデータをサーバコンピュータから送信し、この第2のデータは、その制約が第1のデータベースの部分表現内で満たされるように、クライアントデバイスに、第2の記録を第1のデータベースの部分表現内に挿入すること、またはその部分表現から削除するように命令する。

【0013】

制約は、例えば、データベース管理システム(DBMS)によって実行される外部キー制約など、宣言されたデータベース制約であってよいが、同期機構自体の規則の一部として定義されてもよい点に留意されたい。

【0014】

第1の記録の識別は、本発明の第1の実施形態によれば、時間窓の開始と終了とを決定するステップであって、開始がクライアントデバイスの前の更新に関連する時点を表し、終了がクライアントデバイスの現在の更新に関連する時点を表す、決定するステップと、サーバコンピュータによって実行されたデータベース動作のログを走査するプロセスとに基づくことが可能である。第1の記録は、次いで、それに関して少なくとも1つのデータベース動作が時間窓の間に実行されている記録として識別可能である。

【0015】

第1のデータをクライアントデバイスに送信するのに先立って、本発明の一実施形態は、時間窓の開始時に第1の記録の状態を表す少なくとも1つの値を決定するために、ログを走査して、その値が時間窓の開始時に部分データベース内に受け入れられたかどうかを決定するステップと、時間窓の終了時に第1の記録の状態を表す対応する値を決定するために、ログを走査して、その値が時間窓の終了時に部分データベース内に受け入れられるべきであるかどうかを決定するステップとのうちの1つを含む。受け入れの決定は、その記録の状態を表す値、第1の記録の記録タイプに関して宣言された規則、および第1の記録とは異なるが、サブセット制約を介して第1の記録に関連する記録に関する対応する決定のうちの少なくとも1つに基づくことが可能である。サーバコンピュータ内の第1の記録に関して実行されたデータベース動作が第1の記録の第1のデータベース内への挿入を表した場合、そのデータは、次いで、時間窓の終了時に第1の記録の状態を表す値が時間窓の終了時に部分データベース内に受け入れられるべきであることが決定された場合に、第1の記録を部分データベース内に挿入する命令を表すように構成可能である。同様に、データベース動作が第1の記録の第1のデータベースからの削除を表した場合、時間窓の開始時に第1の記録の状態を表す値が時間窓の開始時に部分データベース内に受け入れられたことが決定された場合に、そのデータは、第1の記録を削除する命令を表すように構成可能である。そのデータベース動作が第1の記録の第1のデータベース内の変更を表した場合、そのデータは、以下のうちの1つを行うための命令を表すように構成可能である。すなわち、i)時間窓の開始時に第1の記録の状態を表す値が部分データベース内に受け入れられたことと、時間窓の終了時に第1の記録の状態を表す値が部分データベース内に受け入れられるべきであることとが決定された場合、第1の記録を部分データベース内で変更すること、ii)時間窓の開始時に第1の記録の状態を表す値が部分データベース内に受け入れられたことと、時間窓の終了時に第1の記録の状態を表す値が部分データベース内に受け入れられるべきでないこととが決定された場合、第1の記録を部分データベースから削除すること、およびiii)時間窓の開始時に第1の記録の状態を表す値が部分データベースに受け入れられなかったこと、時間窓の終了時に第1の記録の状態を表す値が部分データベース内に受け入れられるべきであることが決定された場合、第1の記録を部分データベース内に挿入すること、である。

【0016】

第2のデータをクライアントデバイスに送信するのに先立って、対応する動作を実行することが可能であるが、第2の記録がサーバ上で変更されていないという記録であるため、そのような記録を部分データベース内で変更する命令を送信することは、通常必要でない。しかし、本発明のいくつかの実施形態では、クライアントデバイス上でデータベース動作を実行させるように命令するように構成されたデータは、それらの命令が変更されている記録に関係するか、または変更されていない記録に関係するかにかかわらず、同じ方法、またはコンピュータコードによって構成可能である。

【0017】

本発明の一態様によれば、異なる記録に関する受入れの対応する決定は、代表値を決定するために、ログを走査するステップと、この値のクライアント上への受入れを決定するステップとを繰り返すことによって実行される。これは、例えば、同じ機能、方法、および手順に対する再帰呼出しの形で実施できる。

【0018】

本発明の別の態様によれば、記録タイプに関して宣言された規則は、その記録タイプの記録の状態を表す値を入力として受け入れて、この値のクライアント上への受入れの対応する決定を生み出すための関数である。この値は記録の状態を表すため、この決定は、通常、その記録がクライアントデータベース内に受け入れられるべきかどうかの決定である。

【0019】

本発明の一実施形態では、少なくとも1つの宣言された規則は、そのデータベースのプログラマまたはユーザによって宣言される。

【0020】

第2の記録は、部分データベース内で必要とされる変更されていない記録であるが、制約を介した、変更された第1の記録とのその関係により、その第2の記録が部分データベースに追加された、または部分データベースから除去されたという事実は、類似の制約を介して第2の記録に関係する第3の記録の追加的な追加または除去を必要とする場合がある。結果として、本発明の別の態様によれば、方法は、第1のデータベースに追加されていない、第1のデータベースから削除されていない、または第1のデータベース内で変更されていないが、制約を介して第2の記録に関係し、その制約を満たすために、同じように、その部分データベース追加されるべき、またはその部分データベースから除去されるべき第3の記録を識別するステップを含むことが可能である。この方法は、次いで、その制約が第1のデータベースの部分表現内で満たされるように、クライアントデバイスに、第3の記録を第1のデータベースの部分表現内に挿入するように、または第1のデータベースの部分表現から削除するように命令する第3のデータをそのデバイスに送信し、次いで、すべての制約が部分データベース内で満たされるまで、記録を識別するステップと、データを送信するステップとを繰り返すことが可能である。

【0021】

本発明の一実施形態によれば、第1の記録は、記録タイプの記録の状態を表す値のクライアント上への受入れを決定するための宣言された規則に関連する記録タイプのものであり、第2の記録は、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである。

【0022】

別の実施形態によれば、第1の記録は、記録タイプの記録の状態を表す値のクライアント上への受入れを決定するための宣言された規則に関連する記録タイプのサブセットメンバー記録タイプのものであり、第2の記録は、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである。

【0023】

さら別の実施形態によれば、第1の記録は、2つの記録タイプ、すなわち、第2の記録の記録タイプ、および第1の記録の記録タイプおよび第2の記録の記録タイプとは異なる記録タイプのサブセットメンバーである記録タイプのものである。この実施形態では、第1の記録と異なり、かつ第2の記録とは異なる記録タイプを備えた記録は、その記録タイプの記録の状態を表す値のクライアント上への受入れを決定するための宣言された規則に関連し、一方、第2の記録は、その記録を第1の記録の記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、第2の記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものである。

【0024】

さらに別の実施形態によれば、第1の記録は、第1の記録と第2の記録とは異なる記録タイプの少なくとも1つの記録に関係させる制約を満たすことが必要とされる場合だけ、第1の記録タイプの記録が部分データベース内に受け入れられるべきであることを記述する宣言された規則に関連する記録タイプのものであり、第2の記録は、第1の記録タイプに関するサブセットメンバー記録タイプである記録タイプのものである。

【0025】

すべての関連する情報が獲得される1つの走査として、上で説明されたデータベース動作のログの様々な走査を実行することが可能であり、またはそれぞれの走査動作に関して1つもしくは少数のデータ項目だけを獲得するために、走査を繰り返し実行することも可能である点に留意されたい。

【0026】

いくつかの実施形態では、第1の記録タイプと、第2の記録タイプと、第3の記録タイプとの間の関係は、役割として明示的に定義定義される。本発明の実施形態は、設計基準に応じて、役割の任意の組合せを明示的にまたは暗示的に実施することが可能である。

【0027】

本発明のコンピュータシステムは、電子クライアントデバイスを更新するために、本発明の方法を実行するようにプログラムされたプロセッサを備えた1つまたは複数のサーバコンピュータを含むことが可能である。本発明のコンピュータ可読媒体は、実行されたとき、サーバコンピュータに本発明の方法を実行させる命令を含むことが可能である。コンピュータ可読媒体は、例えば、ハードドライブ、CD-ROMもしくはDVD-ROM、フラッシュメモリ、電気消去可能プログラマブル読出し専用メモリ(EEPROM)、または当業者に知られている任意のその他の好都合なタイプの記憶装置など、磁気可読媒体または光可読媒体であってよい。

【0028】

本発明の詳細は、添付の特許請求の範囲において定義されるが、例示的な実施形態が、下で図面を参照して記載される。

【0029】

本発明の例示的な実施形態は、以下で提示される詳細な説明および添付の図面からより十分に理解されよう。これらの図面は、例示としてだけ提示され、したがって、本発明を限定しない。これらの図面において、類似の参照番号は類似の要素を表す。

【図面の簡単な説明】

【0030】

【図1】本発明による同期可能なサーバとクライアントとを含むシステムを例示する図である。

【図2】本発明によるデータベースクライアントの同期の前後の選択表の例示的な値を示す図である。

【図3】本発明による表の例と、動作しているデータベース内でそれらの表が互いにどのように関係するかを示す図である。

【図4】データベースの異なる部分が、異なる理由で、クライアントの同期にどのように関連しうるかを例示する図である。

【図5】本発明による同期の方法を例示する流れ図である。

【図6】同期の間にクライアントを更新するための候補であるデータベースエントリーを識別する方法を例示する流れ図である。

【図7】識別されたデータベースエントリーがクライアントを更新すべきかどうかを決定して、更新に関して適切なデータベースコマンドを見出す方法を例示する流れ図である。

【図8】第1のタイプのデータベース記録が、特定の時点でクライアント内に受け入れられるかどうか、または受け入れられたかどうかの決定を例示する流れ図である。

【図9】第2のタイプのデータベース記録が、特定の時点でクライアント内に受け入れられるかどうか、または受け入れられたかどうかの決定を例示する流れ図である。

【図10】第2のタイプの任意のデータベース記録が、特定の時点でクライアント内に受け入れられたかどうかを決定するための方法のいくつかの詳細を例示する流れ図である。

【発明を実施するための形態】

【0031】

次に、その例が添付の図面において示される実施形態が詳細に参照される。以下の詳細な説明では、本発明の完全な理解を促すために、様々な特定の詳細が提示される。しかし、本発明は、本明細書に提示される特定の例に限定されず、本発明は、これらの特定の詳細なしに実現可能である点を当業者は理解されよう。これらの実施形態の態様を不要にあいまいにしないように、いくつかのよく知られている方法、手順、構成要素、回路、およびネットワークは詳細に説明されていない点も理解されよう。

【0032】

本発明は、データベースの同期、詳細には、クライアントコンピュータとサーバコンピュータとの間の同期に関し、サーバコンピュータはデータベース全体をホストし、クライアントコンピュータは、サーバコンピュータ内に格納されたデータの少なくともサブセットを含む。この明細書が、データベース全体または完全なデータベースとして中央データベースを参照するとき、その完全性はそのクライアントだけに関するべきである点に留意されたい。完全なデータベースは、例えば、さらにより高い階層レベルで、かつそこからデータベースがデータを受信する任意のその他のデータベースに関してすら、完全でなくてもよい。

【0033】

クライアントコンピュータは、インターネットなど、通信ネットワークに永久的に接続されたパーソナルコンピュータであってよいが、クライアントコンピュータは、ラップトップコンピュータ、PDA(パームトップコンピュータもしくはハンドヘルドコンピュータとしても知られている携帯情報端末)、または、さらにはモバイル電話、メディアプレイヤもしくは電子ゲームデバイスであってもよい。したがって、ディスプレイ、例えば、タッチスクリーン、物理的キーボードまたは仮想キーボード、ポインティングデバイス、例えば、マウスまたはジョイスティック、スクロールまたはクリックホィール、およびラウドスピーカのうちの1つもしくは複数など、ユーザインターフェースデバイスをクライアントコンピュータに提供することが可能である。分かりやすいように、続く議論において、例示的な実施形態として、タッチスクリーンを含むポータルブルマルチファンクションデバイスが使用される。

【0034】

次に、中央サーバといくつかのクライアントデバイスとを含むシステム例示する図1を参照する。これらのデバイスはすべて、インターネット、無線ローカルエリアネットワークまたは固定ローカルエリアネットワーク(WLAN、LAN)、(多くの場合、セルラネットワークと呼ばれる)モバイル電話ネットワークなど、1つまたは複数のデータ通信ネットワークを含むことが可能なネットワーク110に接続される。中央サーバ101は、通常、ネットワーク110に永久的に接続されて、データベースを構成する記録の様々な表をホストするために使用される。加えて、サーバ101は、通常、データベース管理システム(DBMS)と、データベースとクライアントとの間にウェブベースのインターフェースを提供することができるウェブサーバ解決策とをホストすることになる。このデータベース管理システムは、例えば、Microsoft CorporationからのMicrosoft SQL Server、Oracle CorporationからのORACLEデータベース、またはMySQL ABからのMYSQLであってよい。このウェブサーバ解決策は、例えば、場合によっては、PHP、Python、Ruby on Rails、またはServer Side JavaScript(登録商標) (SSJS)など、サーバ側の記述言語と組み合わせて、Apache Software FoundationからのAPACHE HTTP Server、またはMicrosoft CorporationからのInternet Information Services(IIS)であってよい。このウェブサーバは、次いで、HTTPプロトコルとTCP/IPプロトコルとを使用して、データベースコンテンツをクライアントにサービス提供することが可能になり、クライアントは、クライアントデバイス上で局所的に実行しているウェブブラウザタイプのアプリケーションを使用して、データベースコンテンツにアクセスすることが可能である。あるいは、所有権を主張できるプロトコルを使用することが可能であり、ウェブブラウザの代わりに、クライアントによって、専用アプリケーションを使用することが可能である。

【0035】

サーバ101は、いくつかのコンピュータのシステム上で実施可能であり、いくつかのデータベース内のデータの複製またはミラーリングも本発明の原理と一致する。分かりやすくするために、かつ不要な混乱を避けるために、本明細書で説明される例示的な実施形態は、1つのサーバコンピュータだけを含むとして説明されるが、本発明はこの点で限定されない。

【0036】

第1のクライアントデバイス102は、タッチスクリーンと、スタイラスタイプの入力デバイスとを備えたPDAまたはタブレットコンピュータとして示されている。第2のクライアントデバイス103は、例えば、別のPDAまたはスマートフォンであってよい。第3のクライアントデバイス104は、ラップトップコンピュータとして例示されている。第4のクライアントデバイス105は、パーソナルコンピュータまたはワークステーションとして示されている。パーソナルコンピュータ105は、サーバ101と永久的にオンラインでつながっている。これは、同期の必要が存在せず、代わりに、パーソナルコンピュータ105上で行われるすべての変更は、サーバ101に転送されて、即時に、データベース内に格納されることが可能な伝統的なオンラインクライアントサーバ技術を表す。図1で例示されるように構成されたシステムの実施例は、中央データベースサーバ101が在庫品全体と、店舗のチェーンから利用可能な製品のリストとを格納する例であってよい。クライアントコンピュータ102は、いくつかの店舗に何らかのタイプの製品、例えば、衣類を補充する配達用トラックの運転手によって使用可能である。クライアントコンピュータ103は、1つの特定の店舗内のすべてのタイプの製品の棚卸のために使用可能であり、ラップトップ104は、いくつかの店舗を訪問して、注文を登録している販売代理人によって使用可能である。パーソナルコンピュータ105は、データベースサーバ101を管理して、新しいタイプの製品を入力し、製造が中止された製品をデータベースから削除し、価格を変更するためになど、本社で使用可能である。

【0037】

相互に矛盾する変更、他のクライアントデバイスの更新を必要とする変更、および、特に、変更されていないデータの同期を必要とするが、異なるデバイスにおいて行われた変更の結果として、特定のクライアントデバイスに関連するようになったまたは無関係になった変更を含めて、いくつかの変更を異なるクライアントデバイスにおいて行うことが可能である点を当業者は容易に理解されよう。後者の一例は、ラップトップ104を使用している販売代理人がある店舗内の新しい部門に配属されたことでありうる。販売代理人の様々な配属を列挙した配属表内のエントリーは、この変更を反映する可能性があり、このエントリーは、次回クライアントが同期されたときに販売代理人ラップトップ104上で更新されるべきである。しかし、販売代理人は、自らのラップトップ内のこの部門に関するエントリー、ならびに、この部門によって仕入れられた製品を表す記録にアクセスすることも必要になる。これらの記録は変更されていないが、これらの記録は、依然として、次の同期時に、その代理人のラップトップ104に追加されなければならない。配属値に対する実際の変更はクライアント自体の上でまたはサーバ上で行うことができる点に留意されたい。変更がクライアント上で行われた場合、その変更は、サーバ内にインポート可能であり、次いで、次の同期の間に実行可能である。

【0038】

図1に例示される例は、1つのサーバと、そのサーバに接続された複数のクライアントだけを含むが、本発明は、図面に示されない追加のクライアントに関して、クライアント自体がサーバとして動作する階層システム内で実施可能である。

【0039】

次に、上で要約が説明された例を示す図2を参照する。図2Aにおいて、「配属」と呼ばれる第1の表は、「代理人」104と、代理人104が配属された「部門」1001とを参照するエントリーを含む。これらのエントリーは、外部キー、すなわち、異なる表内のキーを参照するキーであってよい。便宜上、代理人は、対応する表(図示せず)内に見出すことができる、そのクライアントコンピュータと同じ数で識別され、一方、その代理人が配属された部門は、部門の表202内の主キーとして見出すことが可能な数によって識別される。第3の表203は、どの部門内でどの製品を見つけることが可能であるかを列挙する。この表は、この特定の例示では、2つの部門10001、10002のうちの1つと、その部門内で見出すことができる製品とを列挙する、いくつかのエントリーを示す。製品が在庫に追加されるにつれて、もしくは在庫から削除されるにつれてエントリーを挿入すること、もしくは削除すること、または製品がある部門から別の部門に転送される場合、変更することが可能である。それぞれのエントリーは、異なる表に対する外部キー参照である。最終表204は、製品番号および名称ごとにすべての製品を単に列挙する。販売代理人のクライアントコンピュータ上の表内に存在すべきすべての記録は、グレイのパターンによって示されている。

【0040】

図2Bでは、表201から、販売代理人は、このとき、部門10002に配属されていることが理解できる。これは、データベース内で変更された唯一の記録であるが、それでもなお、販売代理人は、このとき、表202内の異なる部門に関するデータベースエントリーにアクセスする必要がある。これは、部門10001に関するエントリーはクライアントデータベースから除去可能であるが、部門10002に関するエントリーは、クライアントデータベースにエクスポートされるべきであることを意味する。

【0041】

しかし、配属表201内で変更された記録によって参照される記録をエクスポートすることだけでは十分でない。新しくエクスポートされた記録を参照するすべての記録をエクスポートすることが必要な場合もある。この例では、それは、表203内で新しくエクスポートされた記録によって参照される、「製品」表204内のすべての記録と共に、エクスポートされた部門記録10002を参照する、表203内のすべてのエントリーもエクスポートされるべきであることを意味する。このようにして、新しい部門内で利用可能なすべての製品は、図2B内の表内でグレイのパターンによって示されるように、クライアントデバイス上に存在することになる。

【0042】

同期を円滑にするために、サーバ101上でログを維持することが可能である。このログは、DBMSによって作成して維持することが可能である。類似のログは、すべてのクライアントデバイス上で維持可能である。このログは、したがって、データベースとは別の1つもしくは複数のリストであってよく、またはデータベース内の1つもしくは複数の表としてこのログを実施することも可能である。

【0043】

このログの1つの目的は、任意の時間間隔で行われたデータベース変更の収集を促すためである。以下で、そのような時間間隔は、Δtと呼ばれることになり、一方、Δtの間に収集された変更は、データベースΔと呼ばれることになる。データベースΔは、他の変更の結果として、クライアントに追加されることが必要な記録ではなく、実際に変更されている記録だけを指す。上の例では、配属表内のエントリーは、データベースΔ内に含まれることになるが、部門および製品に関して影響を受けたエントリーは含まれない。それらの影響を受けた記録またはエントリーは、クライアントに関してその受入れを変更させたものとして呼ばれることになり、変更されていないが、その受入れを変更させたすべての記録の収集物は、受入れ(acceptance)Δと呼ばれることになる。データベースΔと受入れΔの合計は、トリガされたΔと呼ばれることになる。

【0044】

適切な時間窓Δtの選択は、クライアントの前の同期に基づくことが可能である。例えば、時間窓は、前の同期の終了の後のある時間単位に開始して、現在の同期が開始された時間単位に終了することが可能である。時間単位は、データベース内のクロックの1つの増分ステップであってよく、「ティック」と呼ばれる場合がある。

【0045】

このログのもう1つの目的は、任意時点tで、何らかの存在する記録発生または存在しない記録発生の値を取得することを可能にすることである。最後に同期されたときを記録するようにクライアントを構成することと組み合わせて、同期が実際に開始される前に、任意のクライアントとの同期を準備するようにサーバを構成せずに、任意の時点で任意のクライアントを同期することが可能になる。しかし、本発明のいくつかの実施形態は、ログから古い記録のパージを実施できる。例えば、パージのために、クライアントが同期を要求したとき、そのログが決定された時間窓に関して不完全である場合、要求された値はそのログから欠けている可能性があるため、増分更新ではなく完全更新を実行することが必要な場合がある。

【0046】

ログは、経時的にデータベース遷移の完全な履歴を記述するログエントリーを含む。新しい記録のすべての挿入(INS)は、タイプINSエントリーのエントリーを作成でき、一方、既存の記録のすべての削除(DEL)は、タイプDELエントリーのエントリーを作成できる。既存の記録のすべての更新(UPD)は、DELエントリーに続いてINSエントリーを作成できる。

【0047】

ログエントリーは、通常、記録発生のRIDと、そのエントリーがいつ行われたかを示すタイムスタンプと、エントリータイプを示すログ状態と、記録タイプのすべての列とを含むことが可能である。

【0048】

同期ログエントリーは、どのクライアントがその更新を発生させたかを識別することも可能である。これは、通常、不要な行動と見なされる、更新がその更新の発生側に更新として送信し戻されることを防ぐために使用可能である。しかし、この規則に例外が存在する場合があり、そのような場合、ログエントリーは、これを示すことが可能である。そのような例外の一例は、クライアントの最後の同期の後に、サーバ上で行われている変更の結果として、インポートプロセスの間に、クライアントからのインポートが変更されるときである。インポートの間に行われた変更は、次いで、クライアントに戻されなければならず、この場合、更新を発生デバイスに送信し戻されなければならないことになる。そのような変更の一例は、「衣類」の製品カテゴリーがサーバ上で「アパレル」に変更されていることでありうる。クライアントからインポートされた新しいエントリーが1つの記録列に「衣類」値を含み、この値がサーバへのインポートの間に「アパレル」に変更されるとき、この値をクライアント上で更新するために、記録全体を発生デバイスに送信し戻すべきである。

【0049】

区分化されたエクスポートは、その更新が、別個に転送されるいくつかの部分に分割されている状況を指す。区分化されたエクスポートを円滑にするために、また実際の最後に受信された発生に基づく回復を可能にするためにも、Δtを定義する時間窓クロック、ならびに最後の記録(表タイプおよびRID)が、同期ログと共に、クライアントデータベース内に維持される。本発明のいくつかの実施形態によれば、データベースに関してクロック値の1つのセットが存在する。代替の実施形態は、ユーザ定義された受入れ方法の場合による、外部キー階層ごとに1つのΔtを含むことが可能である。いずれの外部キー階層にも属していない表も別個のΔtを有することが可能である。これは、結果として、より柔軟な解決策をもたらす可能性がある。しかし、この同期原理は変わらないことになる。

【0050】

クライアントに対して内的であり、通常、ユーザがアクセス可能でないメモリ領域であるシステム領域は、同期プロセスによって使用される、クロックに関する情報と進展情報とを保持するために使用可能である。このデータベースログ状態領域は、すべての必要な情報がデータベース自体の中で利用可能であることを確実にするために使用可能であり、例えば、クライアントとサーバとの間の接続が失われたために同期が中断された場合、平滑で、再始動可能なプロセスを円滑にすることが可能である。同期に必要なすべての情報はデータベースログから利用可能であるため、同期が開始された後に、データベースに行われた変更の結果として生じる何の破壊も伴わずに、同期は干渉の時点から再開可能である。

【0051】

夏時間、時間帯、または任意のその他の種類のクロック調整の結果として生じる混乱を避けるために、データベースタイムスタンプは、同期を実行しているデバイスの実際のシステムクロック、もしくは人工クロック、またはそれら両方を含むことが可能である。システムクロックタイムスタンプは、タイムスタンプを時間帯と無関係にするために、すべてのデバイス上で協定世界時(UTC)を使用することが可能である。この人工クロックは、実際には、それぞれのデータベース事象ごとに1を増分するカウンタである。したがって、システムクロックが調整された場合ですら、人工クロックは影響を受けないことになる。しかし、本発明は、時間を記録する任意の特定の方法に限定されない。

【0052】

同期ログは、すべてのコンピュータ上、およびシステム内に含まれるすべてのデバイス上で維持される。ログの簡素化された例がTable1(表1)に示される。

【0053】

【表1】

【0054】

この例は、まず、RID="1004"を伴う新しい品目が「製品」表内に挿入されていることを示す。この例は、RIDの第1の桁が表を識別すると仮定する。タイムスタンプは、「7354」に達したデータベース事象のカウンタであり、Logstatus="1"は、これが、このログエントリーの最後のコメント#INSによっても示されるように、挿入であったことを示す。このデータベース記録の名称列に値「男性用ジャケット」が挿入されている。このログエントリーは、クライアント(Client="104")も列挙している。後者は、そこからその記録が挿入されたクライアントを識別する。この例によれば、すべてのトランザクションは、同じリスト内にログインされる。しかし、場合によっては、データベース内のそれぞれの表に別個のログを使用することによって、効率性を高めることが可能である。このログは、トリガプロセスの間に、ログ内での検索と探索とを円滑にする索引を含むことも可能である。

【0055】

ログ内の第2のラインは、RID="1002"を伴うエントリーがデータベースから削除されていることを示すエントリーである。タイムスタンプは1だけ増大されており、Logstatus="0"は、これが削除であることを示す。記録全体が削除されているため、この発生に関して何の列エントリーも列挙する必要はない。しかし、削除された値をログ内に含めることは、その削除に先立って、どの値がその記録内に記録されていたかを確定することを可能にする。その結果として、ログは、値「セーター」を列挙して、クライアントは削除を開始する(Client="102")。原則として、これまでの値は前のログエントリー内で見出すことができるため、データベースログ内に新しい値を受け入れる列またはフィールドだけを入力する必要がある点に留意されたい。しかし、変更されていないものまたは削除されたものも同様に、すべての列をログエントリー内に含めることは、その時点でロギングがオンにされ、ログがパージされていないことを条件に、過去の任意に時点で表の行の内容を見出す能力を円滑にすることが可能である。他方で、部分的なエントリーだけがログ内で行われた場合、同期の間に必要とされる値がパージされているかどうかを見分けるのは不可能になり、したがって、部分的な同期の代わりに完全な同期が必要になる。したがって、変更された値だけをロギングすることと、ログから古いエントリーをパージすることとを組み合わせるのは困難な場合がある。

【0056】

最終的に、RID="2003"を伴う記録が更新されている。RIDの第1の桁は、このとき、異なる表、すなわち、特定の店舗に対する1つのPDAの割当てまたは関連性を識別する表を識別する。このような場合、更新は、2つのデータベース事象に対応する2つのエントリーをログ内に含む点に留意されたい。Logstatus="0"によって示されるように、まず元のデータベースエントリーは削除される。店舗は1つの文字表示によって識別されると仮定すると、そのデータベースエントリーは、PDA="102"がStore="D"に割り当てられたことを示した。上述のように、この記録の列内に入力された値を示すフィールドはデータベースログ内に入力されなくてよいが、これらのフィールドは、ここでは、分かりやすくするために含まれている。削除に続いて、同じRIDを伴う新しい記録が表内に挿入される。この新しいエントリーはPDA列内に同じ値を有するが、ログエントリー内の値は、このエントリーの店舗列内の値は、異なる店舗を識別する「F」とすべきであることを示す。

【0057】

ログは、データベース内の記録に関して実行されるデータベース動作の1つまたは複数のリストとして上で説明されているが、本発明の範囲から逸脱せずに、その他の代替案を考案できる。例えば、ログは、クライアントが同期されるたびに、またはデータベース動作が実行されるたびにすら、データベース全体の状態の多数の「スナップショット」を含むことが可能である。そのようなロギング方法は、メモリおよび処理電力など、現在のリソース制約に基づいて、実用的でない場合があるが、所与のクライアントの連続的な同期の間にデータベースに対するすべての関連変更を捕捉するために必要な要件を満たす目的で、そのような方法を設計することが可能である。

【0058】

伝統的には、ログに基づく増分同期は、データベースにどの変更が行われているかを決定し、同期の間に、すべての関連変更をクライアントに転送するために、同期ログの簡単な審査に基づいてきた。所与のクライアントにどの変更が関連するかを決定するために、フィルタが使用されてきた。しかし、他の表内の外部キーによって参照される表に関してフィルタリングが実行されるデータベースの場合、以下の例で示すことができるように、必要な更新を除外することが可能であり、外部キー制約はもはや満たされなくてよい。

【0059】

時間窓Δt_i-1の間に、記録タイプ「店舗」の新しい記録がデータベースに追加される状況を考慮する。記録タイプ「店舗」と記録タイプ「製品」との間に外部キー制約が存在し、記録タイプ「製品」の10個の新しい記録も追加される。これらの新しい製品は、新しい店舗の在庫の一部である。

【0060】

時間窓Δt_i-1の終了時に、特定のクライアントの同期の間に、すなわち、Δt_i-1に対応するデータベースΔに基づいて、そのクライアントに関連するフィルタが新しい店舗と新しい製品とがクライアント上に存在する部分データベース内に挿入されることを妨げると仮定する。Δt_iの間に、そのデータベースを、新しい店舗と新しい製品とが関連するクライアントフィルタを通過することになるが、店舗記録および製品記録の中に格納された値には何の変更も行われていない、ある状態に変更する更新がサーバデータベースに行われた場合、時間間隔Δt_iの間、データベースΔ内には、それらの記録に対する何らかの変更を示すエントリーは存在しないことになり、その結果として、時間間隔Δt_iの終了時にクライアントがサーバと同期するとき、それらの変更はクライアントに転送されないことになる。

【0061】

記録自体が変更されているかどうかにかかわらず、変更のために所与の記録に関する受入れが可能にされる、部分データベースの同期を処理するために、本発明は、ログによって決定されるデータベースΔだけに基づいて更新を実行するのではなく、データベースΔの一部でない記録がデータベースΔの一部である記録によってトリガされる場合、それらの記録が含まれる、トリガされたΔの概念を取り入れる。

【0062】

本発明のいくつかの実施形態では、記録は、外部変数の結果として、その受入れを変更させる場合がある。外部変数の一例は、日付または時間でありうる。例えば、作業指示書が処理されるべき日付の前日まで、それらの作業指示書をクライアント上で利用可能にすることは望ましくない場合がある。結果として、前の同期において拒否されたが、今回は受け入れられたすべてのそのような指示書を識別するために、すべての作業指示書を閲覧することが必要な場合がある。外部変数により受入れを変更させた記録は、今度は、追加の記録をトリガする場合がある。

【0063】

最終的に、トリガされた記録は、追加の記録を再帰的にトリガする場合がある。

【0064】

トリガの概念はさらに詳細に議論されることになるが、記録タイプ同士の間の関係と、記録タイプが互いに対して有する可能性がある様々な役割とにまず注目する。役割の明示的な定義は本発明のすべての実施形態にとって必須ではないが、役割の定義は、複雑なデータベースにおいてトリガされたΔ内に表を適切に包括することを円滑にできる。したがって、設計基準および特定の実施形態における必要性の結果として、追加の役割を定義することは、設計選択に開放されているため、本発明の一実施形態は、したがって、本明細書で説明される役割のサブセット、説明されるすべての役割、または本明細書で説明される役割のスーパーセットすら含むことが可能である。

【0065】

図3は、表を用いた例、およびそれらの表が互いにどのように関係しうるかを示す。表同士の間の関係、または記録タイプ同士の間の関係は、当業者によってよく理解されている。1つの表内の項目(または、記録)が異なる表内の1つもしくは複数の項目に関係するとき、関係が使用される。関係は、1対1であってよく、1対多であってよく、または多対多であってもよい。1対1関係の一例は「配偶者」である。結婚している男性は妻を1人だけ持ち、その妻は夫を1人だけ持つ。1対多関係の一例は、性別の関係である。「男性」および「女性」と言う用語は、多くの人々に適用されることになるが、それぞれの人物は男性および女性のどちらか一方だけである。多対多関係は、例えば、書籍と著者との間の関係でありうる。1冊の書籍は2人以上の著者を有する場合があり、1人の著者は2冊以上の書籍を執筆した可能性がある。本発明によれば、これらの異なるタイプの関係は同じ形で処理され、一般性を失わずに、説明される特定の関係が、1対1であるか、1対多であるか、または多対多であるかは指定されない。

【0066】

図3の例は、リレーショナルデータベース実装に基づく。リレーショナルデータベースでは、記録タイプは表として表され、記録はそれらの表内の行である。下で説明される例では、「表」という句は「記録タイプ」と一般化でき、「行」は「記録」と一般化でき、逆に、「記録タイプ」は「表」によって「例示」でき、「記録」は「行」によって「例示」できる。様々な例において使用される用語から、本発明の範囲のいかなる限定も推論されるべきでない。

【0067】

本発明の関連で、表内の特定の行がクライアントに転送されるべきか否かを決定するために、ユーザ定義された受入れ方法を使用することが可能である。表同士の間の関係により、多くの場合、変更されている記録、またはその特定の表に関して直接的に実行している方法によってその受入れを変更させた記録を転送することは十分でないことになる。加えて、問題の行との関係を有する他の表からの行を転送または更新することが必要な場合がある。例えば、特定の著者が書店の選択に追加され、したがって、その書店に関連するクライアントコンピュータに追加された場合、その著者を表す行だけでなく、その著者によって執筆された書籍を表す行もクライアントに転送することが必要な場合がある。同様に、その作業指示書は次の日に実行される予定であるため、作業指示書がその受入れを変更させた場合、タスクの表からある種のタスクを転送することが必要になる場合もある。受入れ規則が関係をどのように考慮に入れるかを説明するために、役割の概念が導入される。

【0068】

定義されている様々な役割は、異なる表同士の間の関係または異なる記録タイプ同士の間の関係を反映し、クライアントが同期されたとき、規則を定義して、補正更新をトリガする方法をトリガすることを可能にする。様々な役割は、表が互いに関係する形、その受入れが宣言された受入れ方法によって決まるか、またはその他の表内に見出されるパラメータによって決まるか、および明示的な宣言に依存しうる。図3は、一例に関して、これを例示する。

【0069】

第1の表301は、「店舗オーナー」表と呼ばれることになる。この表は、店舗オーナーのリストを単に保持することができ、データベース内のそれぞれの店舗は、オーナー表301内のオーナーを指すことになる。この表は、現在の例において何の役割も有さない点に留意されたい。受入れ方法に直接的または間接的に関連する表だけが役割を有する。この例では、「店舗オーナー」表301に関連する受入れ方法は存在しない。

【0070】

この特定の例では、第2の表は「店舗」表302である。この「店舗」表は、その名称が暗示するように、それぞれの行が特定の店舗を表す表である。この例では、「店舗」表302は、関連する受入れ方法を伴う表になる。これは、クライアントがデータベースと同期されるとき、所与の店舗が、そのクライアントに関するフィルタによって受け入れられるかまたは阻止されるかに応じて、データをそのクライアントに送信できること、または送信できないことを意味する。それに基づいて、受入れ方法が実行する表は、「母」表と呼ばれることになる。したがって、「母」は、受入れ方法が直接的に取り組む記録タイプの役割である。この受入れ方法は、店舗オーナー301のように、より高いレベルの記録タイプに取り組まない。しかし、この受入れ方法は、その方法が直接的に関連する記録タイプのサブツリー内の記録タイプに間接的に取り組む。

【0071】

第3の表303は、「店舗」表302の受入れが基づくパラメータを保持する表である。この例では、表303は、PDAクライアントコンピュータのリスト、およびそれぞれの列挙されたPDAがどの店舗に割り当てられているかを保持するPDA表303と呼ばれる。しかし、受入れ方法は、その方法が作用する表内に格納されたパラメータに直接的に取り組むことも可能である。例えば、「店舗」表302は、どのPDAがその店舗に割り当てられているかを表す値を保持することが可能であり、PDAが同期されるとき、この受入れ方法は、その行(すなわち、その店舗)を受け入れるように設計可能である。

【0072】

表303のPDA記録タイプは、店舗記録タイプに関して「子」であり、パラメータホルダでもある。本発明の原理と一致して、パラメータホルダは、関係ない場合もある(すなわち、パラメータホルダは、それらのパラメータホルダがパラメータとして機能する記録タイプに対して「子」でなくてもよい)。そのような場合、パラメータホルダは、表内のすべての行に同じ影響を有する可能性がある。したがって、パラメータホルダは、例えば、受入れに関して表をオンまたはオフにするように作動することが可能である。当然、この受入れ方法は、追加のパラメータを利用することができ、したがって、受入れは、依然として、表のすべての行に関して同じでなくてよい。

【0073】

第4の表は、「店舗_製品(Store_Product)」表304と呼ばれることになる。「店舗_製品」表304は、例えば、任意の特定の時点において、「店舗」表302内の様々な店舗内にどの製品の在庫があるかに関し、かつそれぞれの店舗がそれぞれの製品の品目をどれだけ多く保持するかに関する情報を含むことも可能である。

【0074】

当然、それぞれの店舗に関して同じ製品を複数回も入力することは不都合であろう。その結果として、それぞれの製品は、「製品」表305と呼ばれる別個の表内に一度だけ列挙される。これは、データベースを「第2の標準型」として知られているものにする。

【0075】

表303のPDA記録タイプのように、表304の店舗_製品記録タイプは、表302の店舗記録タイプに関して「子」である。さらに、この店舗_製品記録タイプは、表305の記録タイプ品目に関して「息子」であり、逆に、表305の品目記録タイプは、この店舗_製品記録タイプに関して「父」である。「製品」表305全体をクライアントに送信することが可能である点に留意されたい。この例示的な実施形態で採用される専門用語によれば、制限されていない表は、「父」ではない。代わりに、「父」は宣言されなければならない。宣言された「父」は、その「息子」によって制限され、「息子」は、今度は、その「母」によって制限される。本発明の第1の実施形態によれば、記録がその記録に関連する受入れ方法を有さず、関係する記録によって制限されていない場合、その記録はデフォルトによって受け入れられる。その他の実施形態では、デフォルトは、それらの記録が受入れ方法によって明示的に受け入れられない限り、または関係する記録によってトリガされていない限り、記録は受け入れられないということでありうる。

【0076】

製品総額306と呼ばれる追加の表も定義される。製品総額は、例えば、「製品」表305内に格納されたそれぞれの製品に関する総売上高を格納することが可能である。製品総額306は、製品３０５の非制約的なサブセットメンバーであり、「姉妹」の役割を有するとして定義される。データベース発生は「息子」内、この場合、店舗_製品304内で変更するため、「姉妹」に影響を及ぼし、「息子」はこの「姉妹」に対して「兄弟」の役割も担う。

【0077】

やはり図3に示されるのは、販売307および購入308と呼ばれる2つの追加の表である。販売表307は、例えば、店舗内で行われたそれぞれの売り上げを記録することが可能であり、購入表308は、店舗に製品を再供給するために行ったそれぞれの購入を記録することが可能である。これらの表の記録タイプは、表304の店舗_製品記録タイプに対する「子」の役割を担う。

【0078】

受入れは、ログ内の関連値を検査することによって決定される。特定の記録、または特定の表行に関するエントリーは、その記録または行のインスタンスと呼ばれることになる。同期するとき、値の2つのセットが当該値、すなわち、期間Δtの開始時またはその直前に記録内に格納された値、およびΔtの終了時またはΔtの終了直前の対応する値である。これらの値は、ほとんどの場合、期間Δtの開始に先立つ記録に関する最新ログエントリー、および期間Δt内の同じ記録に関する最新ログエントリーとして見出すことができる。これらの2つのインスタンスは「対(pair)」と呼ばれることになる。

【0079】

本発明の原理と一致して、2つの異なる課題を考慮することができる。第1の課題は、対内のそれらのインスタンスに関する受入れを決定することである。もう1つの課題は、それら2つのインスタンスの受入れに基づいて。その対がクライアントを更新すべきかどうかを決定することである。受入れという用語は、特定のインスタンス(すなわち、特定の時点に関連する記録値の特定のセット)がクライアント上に存在したか、またはクライアント上に存在すべきかを指すことになり、一方、対がクライアントを更新すべきかどうかの決定は、フィルタリングと呼ばれることになる。対がフィルタを通過する場合、またはフィルタが対に関して「真」を戻す場合、その対はクライアントを更新すべきである。対がフィルタを通過するということは、新しい記録が挿入されたこと、既存の記録が新しい値で更新されたこと、または既存の記録がクライアントから削除されたことを意味する可能性がある。インスタンスに関する受入れは、そのインスタンスが受け入れられていない任意の他の記録タイプのインスタンスによって制限されるかどうか(例えば、「子」が受け入れられていない「母」の「子」であるかどうか)、または受入れがユーザ定義された受入れ方法によって決定されるかどうかによって決定される。ユーザ定義された受入れ方法によって検査された値は、その受入れ方法に関するパラメータとして定義されるインスタンスの値である。

【0080】

対がフィルタを通過するかどうかを決定するとき、2つのインスタンスに関する受入れを決定することが可能である。本発明の原理と一致して、フィルタによって行われた決定の結果は、以下のうちの少なくとも1つの決定に基づくことが可能である。すなわち、1)その記録が、Δtの開始時に、またはその直前にクライアント内に受け入れられたか、および2)その記録が、Δtの終了時またはその直前にクライアント内に受け入れられたか、である。

【0081】

上記の2つの問題は、結果として、4つの異なる結果をもたらす可能性がある。両方の問題が否定的に回答された場合、その記録は、前の同期時に受け入れられておらず、そのとき、受け入れられるべきではない。その結果として、その対は、そのフィルタを通過しなくてよい。第1の質問に対する回答が「はい」であり、第2の質問に対する回答が「いいえ」である場合、その記録は受け入れられており、クライアント上に既に存在することが推定されるが、もはや受け入れられるべきではない。したがって、クライアント上に既に存在するエントリーは除去されるべきであり、その受入れ変更は、その記録がクライアントから削除される(DEL)べきであることを意味する。このタスクを実行するために、この対はフィルタを通過することが許可されなければならない。逆に、第1の質問に対する回答が「いいえ」であり、第2の質問に対する回答が「はい」である場合、その記録は、クライアントデータベース内に挿入されなければならない(INS)可能性がある。この場合も、その対はフィルタを通過しなければならないことになる。最後に、両方の質問が肯定的に回答された場合、サーバ上の記録の値に対する任意の変更もそのクライアントに関連し、その対はフィルタを通過すべきである。本発明の実施形態において、このプロセスがまさにどのように処理されうるかは、下でさらに詳細に説明される。

【0082】

場合によっては、受入れは、異なる表の行内で見出されたパラメータに基づいて、「母」に関して決定可能である。そのような表は、図3でPDA表303によって例示される、パラメータホルダと呼ばれることになる。他の表内に格納されたパラメータから決定される受入れは、「母」の受入れに基づいて、パラメータと呼ばれることになる。

【0083】

関連する受入れ方法を有さない記録の場合、受入れは、他の記録を検査することによって決定可能である。例えば、購入表308内の行に関する受入れを決定するために、受入れは、店舗_製品表304内で参照される行に関して決定されなければならない。購入表内の行が、例えば、外部キー制約を受ける場合(すなわち、店舗_製品を参照する購入行内に外部キー基準が存在する場合)、参照された店舗_製品列が受け入れられる場合だけ、その購入はそのクライアント内で受入れ可能である。そうでない場合、参照整合性は満たされないことになる。店舗_製品表304に関して定義された受入れ方法が存在しないため、店舗_製品表304内の行によって参照される「店舗」表302内の行を検査することによって類似の決定を行わなければならない。その結果として、ログ内で再帰的な探索を行うことが必要な可能性がある。ログを索引付けすることによって、かつそのログをそれぞれの表に関する別個のログ区分に区分化することによって、ログを検索する効率性を高めることができる。

【0084】

役割の概念は、データベースに対する他の変更の結果として、変更されていない発生がどのように、かついつトリガされるべきかに関する規則の定義を円滑にする。クライアント上で正確な部分データベースを維持するために、クライアント上に存在すべきすべての記録またはクライアント上に存在すべきでないすべての記録は、すべての制約を満たすと同時に、適切に同期されるべきである。受入れ方法に関連しない記録に関する受入れは、表とのその関係と、受入れ方法、すなわち「母」とのその関係に依存するため、それらの記録に関連する受入れ方法を有する記録、すなわち、「母」記録は、組み合わせて、クライアント上の部分データベースの範囲を定義する記録である。

【0085】

受入れが受入れ方法を伴う記録、すなわち「母」に関して変更されている場合、これは、すべてのその「子」、すなわち、「母」のサブツリーのすべての記録をトリガすべきである。ログは表行などの記録が任意の特定の時点で任意の所与のクライアントによって受け入れられたかどうかに対する回答を直接的に提供しない点に留意されたい。記録が受入れ方法を有する場合、その記録は、この記録自体を表す行の値内、またはパラメータホルダ表内の、その方法に対するパラメータである、1つもしくは複数のログインされた値を検査することによって決定可能である。その記録が受入れ方法を有さない場合、この記録「母」に関して受入れを決定しなければならない。

【0086】

図3に示される例では、「母」表は、PDA表303内に格納されたパラメータに基づいて受入れ可能である。PDA表303からフェッチされたパラメータを伴う、「店舗」表302に関して作用している受入れ方法が、PDA表303内のエントリーに行われた変更のために、「店舗」表302からの特定の記録発生がこのとき特定のPDA内で受け入れられるべきであることを決定した場合、すべてのデータベース制約を満たすことができるように、「店舗」表302からの関連する店舗だけではなく、表のサブツリーからのすべての関連する行も追加する必要がある。通常、これは、参照整合性を維持するために、もはや受け入れられない店舗を参照する製品として表304内に入力されたすべての店舗_製品も、もはや受け入れられない可能性があることを意味する。同様に、クライアント内でこのとき受け入れられている店舗を参照する店舗_製品も受け入れられるべきである。さらに、「製品」表305内で見出されるこれらの製品のすべての記述も入力されるべきである。本発明のいくつかの実施形態によれば、「父」表と呼ばれる「製品」表305などの表内のエントリーは、参照している「息子」表、この場合、店舗_製品表304から行われた参照に基づいて、受け入れ可能である。本明細書で採用される専門用語によれば、「父」表は、その表に関連する受入れ方法を有することができない点に留意されたい。その表が当該受入れ方法を有する場合、その表は「母」表になる。

【0087】

さらに、店舗_製品表304、販売表307、および購入表308の「子」も、クライアントに、かつ「品目総額」表306にも追加されるべきである(または、場合によっては、除去されるべきである)。

【0088】

トリガプロセスにおいて、パラメータホルダ発生は、「母」表店舗の行をトリガし、「店舗」表内でトリガされた行は、「子」表店舗_製品内の行をトリガし、店舗_製品内でトリガされた行は、販売表および購入表内のその独自の「子」をトリガする。

【0089】

この例は、「母」表がパラメータホルダ表内のパラメータに基づいて決定されたその受入れを有することを仮定するが、その表自体の中の内容だけに基づいて、その表をフィルタリングすることも可能である点に留意されたい。例えば、「店舗」表302は、PDAと呼ばれる列を有することが可能であり、この列内に入力された特定のPDAは、記録がクライアント上で受け入れられるべきか否かを決定することが可能である。

【0090】

次に、トリガの概念に注目する。既に記述されているように、トリガは、記録に行われている変更に依存しなくてよい。受入れ内の変更により、記録はトリガされたΔ内に含まれることも可能である。トリガされた発生は、期間Δtの間に変更されていないが、現在同期されているクライアントに関してその受入れを変更させた記録を表す「対」である。

【0091】

次に、本発明による、増分同期の間のデータベースの異なる関連部分を例示する図4を参照する。図4Aでは、データベースの範囲全体が領域400として例示されている。データベース400の第1のサブセット410は、2つの連続的な同期の間に変更されているデータ記録(例えば、表行)を表す。これは、データベースΔと呼ばれているものである。データベース400の第2のサブセット420は、外部変数の結果として、その受入れを変更させた記録を表す。最終的に、データベース430の第3のサブセット430は、他の記録、すなわち、その他の記録内の変更の結果として、その受入れを変更させた記録によってトリガされた記録を表す。

【0092】

これらのセットは重複する場合がある点を理解されよう。例えば、作業指示書が受け入れられないとき、その作業指示書は第1の同期に先立って入力されている場合があり、その作業指示書は続く同期の前に変更され、したがって、サブセット410に属し、その作業指示書は、外部変数の結果として、クライアントに対して受入れ可能にもなる。同様に「母」によってトリガされ、したがって、サブセット430に属する「子」もやはり変更されている可能性があり、その結果、その「子」はサブセット410にも属する。しかし、同じ記録を複数回処理することは不都合な場合がある。したがって、図4Bに示されるように、本発明のいくつかの実施形態では、データベースΔは、変更されているすべての記録411と定義され、外部変数を受けるため収集される記録は、それらの記録が既にデータベースΔの一部でない場合だけ、サブセット421内に収集され、記録が変更されておらず(すなわち、サブセット411内になく)、外部変数からの受入れ変更を受けない(すなわち、サブセット421内にある)場合、それらの記録は、他の記録によってだけトリガされて、サブセット431内に含まれる。

【0093】

次に、本発明による方法をどのように進めることができるかを流れ図で例示する図5を参照する。このプロセスは、開始ステップ500から始まる。次いで、次のステップ501において、同期しているクライアントに関して行われたすべての変更、挿入、または削除を受信することが可能である。これらは、次いで、同期の開始に先立って、データベースに適用されて、データベースログ内に含まれることが可能である。既に記述されたように、クライアントから受信された変更は、通常、同期の間に、クライアントに戻されないことになるが、この規則に例外が存在する場合がある。

【0094】

このプロセスは、次いで、データベース内で行われたすべての変更が収集されるステップ502に進む。このプロセスは、図4Bにおいてサブセット411として示されるデータベースΔを作成する。これらの収集された変更は、ステップ503において、トリガのリストに追加される。本発明はこの点限定されないが、下でさらに詳細に説明されるように、これらの変更をトリガのリスト内に対として入力することが可能である。いくつかの実施形態では、これらの変更を一度だけ入力することも可能であり、例えば、挿入された記録または削除された記録は、1つのINSエントリーまたは1つのDELエントリーとしてだけトリガのリスト内に入力可能である。

【0095】

次に、ステップ504において、外部変数からその受入れを変更させた記録を識別するために、データベースが閲覧される。例は、上で議論されたように、ある時点でその受入れを変更させた記録を含むことが可能である。図4Bでサブセット421として示される受入れΔの一部である、これらの変更は、ステップ505に示されるように、トリガのリストに追加される。

【0096】

ステップ506において、トリガのリスト内のエントリーは、関係する対をトリガすることになり、それらの対は受入れ変更に関して調査されることになる。図4Bのサブセット431に対応する、トリガされた対は、トリガのリストに追加されることになり、このプロセスは、トリガのリスト内に新しいトリガが存在しなくなるまで、再帰的に続く。このプロセスは、下で図6を参照してさらに説明される。

【0097】

トリガのプロセスが完了するとき、トリガのリスト内のすべての対に関してフィルタリングが実行され、ステップ507において、実際の同期が始まる。この方法は、次いで、ステップ508で終了する。

【0098】

上で図5を参照して議論された方法は、一続きの別個のステップとして説明されているが、説明されるステップの特定の順序は、理解を容易にするために選択されている、単なる1つの可能性である点を理解されたい。例えば、ステップ502においてデータベースログから変更を収集するステップと、収集された変更をトリガのリストに追加するステップとは、2つの連続的なステップとして説明されている。しかし、データベースログ内にある変更が見出されるたびに、この方法がデータベースログ内の次の変更を突き止めるために先に進む前に、その変更をトリガのリスト内に記録できるように、変更が収集されるにつれて、これらの変更をリスト内に入力することが可能である。また、トリガの前にすべての変更を収集しなくてもよい。例えば、より少量でデータをクライアントに送信することが所望される場合があり、これを達成する目的で、そのそれぞれのサブツリーのすべての関連する対をトリガして、次の所定の数のトリガに進む前に、それらの対を同期させるために、データベースΔから所定の数の変更された対を使用することが可能である。したがって、極端な事例では、第1の変更された対を収集して、この第1の変更された対によってトリガされたすべての対を発見し、データベースΔ内の次に変更された対に進む前に、フィルタリングを実行して、関連する変更をクライアントに送信することが可能である。別の極端な事例では、すべての変更がまず収集され、次いで、すべての収集された変更に基づいて、すべてがトリガされ、次いで、収集されて、トリガされたすべての対に関して、フィルタリングが実行され、最終的に、すべての関連する更新がクライアントに転送される。

【0099】

やはり、変更された記録を収集する前に、外部変数によって変更された記録を識別するステップ504と、それらをトリガのリストに追加するステップ505とを実行することが可能である。

【0100】

次に、図5の様々なステップがさらに詳細に議論される。

【0101】

クライアントがサーバから切断されている間に、クライアントにおいて行われたすべての変更をサーバデータベースにおいて受信するステップは、任意の時点で任意のクライアントからデータベースに行われたすべての変更を処理することを可能にする。

【0102】

ステップ501においてクライアントから受信された記録は、変更された記録を収集するためのプロセスに類似したプロセスで、クライアントにおいて収集され、サーバ上でデータベースΔを構築する。しかし、すべての記録がサーバ上に存在し、すべての変更がサーバに送信されるべきであるため、それらの記録をフィルタリングする必要はなく、したがって、トリガされた発生を識別する必要もない。クライアントは、データベースΔ全体を単にサーバに送信する。

【0103】

クライアントからそれらの記録を受信した後で、それらの記録を、データベース内に挿入すること、データベースから削除すること、またはデータベース上で更新することが可能である。これらの挿入および更新は、データベースとの任意の他の相互作用として処理されて、データベースのログ内に入力される。既に記述されたように、特定のクライアントから受信された更新は、通常、そのクライアントに送信し戻されないが、ある状況において、例外が必要となる場合がある。

【0104】

ステップ502において、期間Δt内にデータベースに行われた変更が収集される。これは、ある方法、すなわちDBMSの一部であるサブルーチンによって実行可能である。この方法は、CollectRecordsと呼ばれることになる。このCollectRecords方法は、t₀およびt₁において異なる値を有するすべての記録を発見するために、期間Δtに関してログを検査し、この場合、t₀は、この特定のクライアントの前の同期に関する期間を指し、t₁は、この同期に関する期間を指す。すなわち、Δtは、t₀からt₁までの期間を表す。t₀およびt₁において異なる値を有するとして識別されたすべての記録は、トリガのリストに追加される。t₁におけるすべての値がそれらの値がt₀において有した値に戻された場合、期間Δtの間に複数回変更された記録を追加する必要はない点に留意されたい。本発明の原理と一致して、記録はトリガのリストに対、すなわち、時間t₀における記録を表す、対の1つのインスタンス、および時間t₁における記録を表すもう1つのインスタンスとして追加される。第1の実施形態では、記録のすべての値は、対の両方のインスタンス内に含まれる。1つの代替の実施形態では、すべての値はそれらのインスタンスのうちの1つの中に含まれ、一方、差異だけがもう1つの記録の中に含まれる。さらに別の代替案では、インスタンスは両方とも変更された値だけを含む。原則として、先の値が必要とされるべきである場合、それらの値はログに戻ることによって突き止めることができるため、時間t₁に関して更新された値だけをトリガのリスト内に含めることも可能である。

【0105】

ステップ502において収集されて、ステップ503においてトリガのリスト内に入力された変更は、データベースΔを表す。第1の実施形態によれば、データベースΔに属しているすべての記録は、それが同期されている特定のクライアントに関連するか否かにかかわらず、方法CollectRecordsによって、トリガのリストに追加されて、受入れは、トリガのプロセスの間におよび/または最終同期の間にだけ決定される。しかし、その受入れまたは受入れ変更がそのクライアントに関連する場合、データベースΔ内のそれぞれの対のインスタンスに関する受入れを決定して、その対だけをトリガのリストに追加することは、本発明の原理と一致する。

【0106】

Δtの間に任意の値を変更していないが、何らかの外部理由により、その受入れを変更させた記録を識別するために、データベースを閲覧するステップ504と、ステップ505において、対として識別されたそのような記録をトリガのリスト内に入力するステップとは、ある方法、すなわちDBMSの一部であってよく、かつBrowseExternalAcceptanceChangeと呼ばれることになるサブルーチンによって実行可能である、この方法は、データベース自体に対して外的な何らかの決定要因の結果として、例えば、時間の経過の結果として、同期されたクライアント(または、あるいは、任意のクライアント)に対してその受入れを変更させた記録を識別する。前の同期以来、その受入れが変更させた記録を識別するために、前の同期時の外部変数の値の状態を知る必要がある。定義上、ログは内部データベース値に対する変更を追跡するため、この値はログから直接的に利用可能でない可能性がある点を理解されよう。したがって、例えば、別個のログ内のそのような外部値を記録することが必要な可能性があり、外部の受入れ方法に関連するタイプを有するすべての記録に関してこれを行うことができる。

【0107】

この方法によって識別された記録は、データベースΔのトリガのリストと同じトリガのリストに対として追加されるため、そのトリガのリストに既に追加されている記録を識別する必要がないのは、それらの記録はΔtの間にその値を変更させているためである。その結果として、本発明の第1の態様によれば、この方法は、Δtの間に変更されていないが、その受入れを変更させた記録だけを識別する。あるいは、この方法は、外部理由により、その受入れを変更させたすべての記録を識別して、それらの記録を対としてトリガのリストに追加する。この場合、同じ記録に関する複数のトリガを避けるために、トリガのリストから複製を除去することが必要な場合がある。

【0108】

CollectRecords方法に先立って、BrowseExternalAcceptanceChange方法を実行することも可能であり、この場合、その受入れを変更させていない記録はトリガのリスト内に既に存在することになるため、CollectRecords方法は、少なくとも1つの値を変更し、その受入れを変更させていない記録だけを含むように構成可能である点を理解されたい。

【0109】

BrowseExternalAcceptanceChangeによって識別された記録は、t₀およびt₁に関して入力されたのと同じ値を伴う更新(UPD)として、トリガのリストに追加できる。しかし、t₁に関する挿入(INS)または削除(DEL)だけを伴う記録を一度だけ(「半対」として)入力することは、本発明の原理と一致する。

【0110】

次に、このプロセスは、ステップ506に進み、この場合、トリガのリスト内に列挙された対によってトリガされるべき対、すなわち、トリガのリスト内に列挙された対の間接的な結果として、クライアントに転送(またはクライアントから削除)されなければならない可能性がある対。そのような記録は、トリガされた対、またはトリガされた発生と呼ばれる場合があり、それらの記録を識別するために使用される方法は、TriggerOnRecordsと呼ばれることになる。

【0111】

本発明の態様によれば、トリガされた発生は、BrowseExternalAcceptanceChange方法によって識別された記録を伴う場合のように、Δtの間に変更されていないが、他の記録に関する値または受入れに対する変更の結果として、すなわち、トリガのリスト内のエントリーの結果として、一部のクライアントに関してその受入れを変更させた対でありうる。そのような記録を識別するプロセスは、トリガリングと呼ばれることになり、識別された記録は、トリガされた対またはトリガされた発生と呼ばれることになる。

【0112】

Δtの間にその値を変更させていないが、外部変数により、またはそれらの対がトリガされたことにより、トリガのリストに追加された対は、対の両方のインスタンスに関して同じ値を伴う更新(UPD)としてトリガのリストに追加できる。すべての情報は、任意の時点でログから取り出すことができるが、変更されていない記録を更新として追加することは、いくつかの実施形態では、データベースΔからの対に関して設定された方法を再使用することを可能にする場合があるため、本発明はこの代替案に限定されない。これは、以下を考慮することによって理解されよう。ステップ507において、データベースΔからの対に関するフィルタ状態を決定するとき、DELの結果として収集された任意の対(すなわち、t₀においてサーバデータベース内に存在したが、t₁の前に削除された記録)は、t₀において受け入れられた場合、t₁同期においてクライアントから削除されるべきであるか、または、その対は、t₀において受け入れられておらず、t₁において同期の間に無視されてよいため、そもそもクライアントにおいて存在しないはずである。同様に、新しいINSとして収集されたいずれの対も、t₀においてデータベース内に存在しなかったが、t₁においてデータベース内に存在し、これは、その対が(その対がt₁において受け入れられた場合)クライアント内に挿入されるべきであること、または(その対がt₁において受け入れられなかった場合)、その対は無視されてよいことを意味する。

【0113】

しかし、データベースΔからの対がUPDとして列挙されている場合、これは、その記録は、t₀において存在した可能性(その記録は、t₀の後で追加され、次いで、更新されている可能性)があり、その記録は、t₁において依然として存在するが、Δtの間にその値が変更されていることを意味する。同期の間にその記録がどのように処理されるべきかは、以下によって決まる。その記録がt₀において受け入れられて、t₁において依然として受け入れられる場合、その記録は、更新(UPD)として処理されるべきである。その記録がt₀において受け入れられておらず、t₁において依然として受け入れられない場合、その記録は無視されてよい。しかし、その記録はt₀において受け入れられなかったが、Δtの間にその受入れが変更し、したがって、その記録がt₁において受け入れられる場合、その記録は、既にクライアント上に存在していないため、挿入(INS)に変更されなければならない。同様に、対内のインスタンスに関する受入れが、第1のインスタンスに関して「はい」から最後のインスタンスに関して「いいえ」に変更した場合、その記録はクライアント上で更新されるべきではなく、その記録は除去されるべきであり、これは、その記録がDELに変更されるべきであることを意味する。トリガのリスト内でUPDとして列挙された対だけがこのように変更するため、かつ、トリガされた記録は、同じようにその受入れを決定させなければならないため、トリガされた記録をトリガのリスト内に更新として入力することは好都合な可能性がある。

【0114】

次に、図6を参照すると、ステップ506において実行されたトリガリングのプロセスがさらに詳細に説明される。このプロセスは、図5のステップ506に対応し、様々な役割が例示された図3も再び参照する。様々な役割を参照するために使用される用語は便宜上採用されており、本発明の何らかの限定を表すことが意図されない点に留意されたい。例えば、ある役割に関連する性別は関連性がなく、記録タイプは、異なる性別のいくつかの役割を有する場合がある。例えば、記録タイプは、「母」と「息子」の両方でありうる。本発明を適切に説明するために、異なる専門用語を容易に採用することが可能である。

【0115】

トリガリングのプロセスは、ある方法、すなわちDBMSの一部であってよく、TriggerOnRecordsと呼ばれることになるサブルーチンによって処理可能である。TriggerOnRecords方法は、第1のステップ600を開始するとき、前のステップにおいて作成されたトリガのリストを入力として利用する。

【0116】

第1のステップ601において、トリガのリスト内の第1の対が検査される。検査されたまさに第1の対は、(実装に応じて)データベースΔからであるか、または外部変数の結果としてそのリスト内に含まれるが、一般に、トリガはそれ自体が、図6を参照して、ここで要約されるプロセスの一部としてトリガされている可能性がある点に留意されたい。

【0117】

次のステップ602において、現在検査されているトリガのリスト内の対が、例えば、図3のPDA表303など、パラメータホルダの表からであるかどうかが決定される。その表からである場合、プロセスは、「母」がトリガされるステップ603に進む。図3を参照して説明されたように、関連する受入れ方法を有する記録タイプは常に「母」であり、パラメータホルダは、受入れ方法に関する入力パラメータであるため、それらのパラメータホルダは、フィルタリングされた記録タイプ、すなわち、「母」を常にトリガすることになる。

【0118】

そうである理由は、図3の例から容易に理解されよう。パラメータホルダが、PDAとそれらのPDAが割り当てられている店舗との間の関連性のリストである場合、そのPDAがデータベースと同期されるとき、そのような関連性の変更は、そのPDAがどのデータを受信すべきかに明らかに影響を及ぼすことになる。「母」をトリガすることは、「母」表302からの少なくとも1つの識別された記録がトリガされた記録のリストに対として追加されることを意味する。このトリガされた対は、トリガのリストに追加できるが、列値はΔtの間に変更されていないため、それらの値は、その対内の2つのインスタンスに関して同じになる。(「母」がΔtの間に実際に変更されている場合、それは、既にトリガのリストの一部であることになり、「母」をトリガされた発生のリストに追加する必要はない。)

【0119】

「母」表から2つ以上の記録をトリガされたリストに追加することが必要な場合がある点に留意されたい。例えば、PDAがt₀において第1の店舗STORE01に割り当てられ、パラメータホルダ内の変更によって示されるように、時間t₁において第2の店舗STORE02に再度割り当てられている場合、STORE01をクライアントから削除して、STORE02を追加する必要がありうる。その結果として、STORE01とSTORE02は両方とも、トリガされて、UPDとして、トリガのリストに追加されるべきである。図5のステップ507の間に、次いで、それぞれ、STORE01はDELに変更されるべきであり、STORE02はINSに変更されるべきであることを決定することが可能である。データ整合性を維持するために、所与のクライアントに関してもはや受け入れられない記録をそのクライアントから削除することが必要な場合がある点に留意されたい。しかし、データベース設計者が、それがデータの整合性、またはクライアントの記憶容量を容認できない形で損なわないことを確実にできる場合、記録がクライアント上に残ることを許可することは、本発明のいくつかの実施形態と一致する。

【0120】

「母」記録タイプを追加するプロセスは、ある方法、すなわち、ここで、AddMaterFamiliasと呼ばれることになり、入力パラメータとして、パラメータホルダリストからの対を利用するサブルーチンによって処理可能である。上述のように、AddMaterFamiliasは、表から1つまたは複数の対をトリガすることが可能である。例えば、パラメータホルダ対内の第1のインスタンスの値により受け入れられた1つの記録は、そのパラメータホルダ対内の最後のインスタンスの値により、もはや受け入れられず、逆に、第1のインスタンスに関する異なる記録は受け入れられていなかったが、このとき受け入れられる。両方とも2つのUPD対として、トリガのリストに追加されることになり、それらの更新がクライアントに転送される前に、それぞれ、DELおよびINSに変更される。

【0121】

1つまたは複数の「母」対が1つまたは複数のトリガされた対としてトリガのリストに追加された後で、このプロセスはステップ604に進む。同様に、ステップ602において、そのトリガ対がパラメータホルダでないことが決定された場合、このプロセスは、「母」記録タイプをトリガせずに、ステップ604に直接的に進む。

【0122】

ステップ604において、考慮中の対は、その対がクライアントを更新すべきかどうか、すなわち、その対が更新フィルタを通過すべきかどうかを決定するために、さらに検査される。この決定は、同期されているクライアントについて、その対のインスタンスに関する受入れの決定に基づいて行うことが可能である。この決定は、図5のステップ507において、トリガされた対がクライアントを更新すべきかどうかを決定するために使用された方法と同じ方法を使用して行うことが可能である。この方法は、図7を参照して、下でさらに詳細に説明される。

【0123】

ステップ604で行われた受入れの決定は、以下の結果を有する可能性がある。その対のインスタンスがいずれも受け入れらない場合、その対は、クライアントを更新しないことになり、したがって、この対に基づいて、追加の対をトリガする必要はなく、プロセスはステップ607に進む。しかし、それらのインスタンスのうち少なくとも1つが受け入れられる場合、その対は、クライアント上の変更を必要とする場合があり、その対はさらにトリガされるべきである。これは、その対のフィルタリングは、その記録がクライアント上に存在すべきであるかどうかではなく、その対がそのクライアントに関連する変更を表すかどうかを決定するためである。

【0124】

ステップ604において、その記録がフィルタを通過せず、したがって、その記録がクライアントを更新すべきであることが決定された場合、続くステップ605において、その対が受入れ変更によりトリガされるかどうかも決定されるべきである。その対に関する受入れに対する変更が存在しないことが決定された場合、さらなるトリガの必要は存在しない。この対は、依然としてクライアントを更新できるが、この対は他の記録タイプをトリガせず、プロセスはステップ607に進む。その理由は、受入れが変更されていないため、いずれの変更もその記録自体の中に格納された値に対するものであり、クライアントは、この記録内の何らかの変更された値を更新するによって正確に更新されうるためである。これらの変更は、この記録サブツリー内のいずれの記録も制約しない。

【0125】

しかし、その対に関する受入れが変更されたことが決定された場合、プロセスは、その記録の役割に基づいて、どの他の記録タイプをトリガして、トリガのリストに追加する必要があるかが決定されるステップ606に進む。役割に基づくトリガは、下でさらに詳細に説明される。このトリガに関して、役割に基づくトリガが完了した後で、プロセスはステップ607に進む。

【0126】

ステップ607において、処理されたばかりの対がトリガのリスト内の最後の対であったかどうかが決定される。最後の対でない場合、プロセスは、ステップ608内で次の対に進み、同じプロセスが繰り返される。これは、ステップ607において、すべてのトリガが検査されたことが決定されるまで続き、プロセスはステップ609で終了する。

【0127】

本発明の代替の実施形態では、2つのステップ604および605は異なるように処理可能である。例えば、ステップ605は、ステップ604の前に実行できる。

【0128】

ステップ506において、すべてのトリガが完了する図5に再び戻ると、ステップ507において、トリガのリスト内のすべての対に関するフィルタ状態が決定されなければならない。図7を参照して下でさらに詳細に説明される手順である、その対がクライアントを更新すべきであるかどうかが決定されたとき、図6のステップ604と同じ手順を使用することも可能である。しかし、ステップ604におけるトリガリングの間に実行される方法と、ステップ507における同期の間に実行される方法との間に1つの差異が存在する。それらの記録の受入れがその対の両方のインスタンスに関して「偽」である場合、それらの記録は同期プロセスだけに関連しない点を想起されよう。その対がDELまたはINSとしてリストに追加された場合、すなわち、データベース内の記録に対する変更が削除または挿入であった場合、その記録は、それぞれ、クライアントから削除されるべきであるか、またはクライアント内に挿入されるべきであることも想起されよう。しかし、その対がUPDとしてリストに追加されている場合、追加の考慮が必要になる。これは、トリガされた対がリスト内になぜUPDとして追加可能であるかが説明されたときに上で簡単に説明された。これらの追加的な考慮の結果は、UPDとして追加されている対は、INSまたはDELに変更されなければならない可能性があるというものである。これは、ステップ604のトリガリングの間に実行されなくてよいが、ステップ507の同期の間にだけ実行されなければならない可能性がある。

【0129】

以下のコードは、記録がクライアント上に挿入されるべきか、クライアントから削除されるべきか、またはクライアント上で更新されるべきかを決定可能である対のフィルタリングを例示する。このコードは、2つのタスクを満たす。第1のタスクは、対がクライアントを更新すべきか否かを決定するためであり、更新すべき場合、「真」を戻すことによって表され、すべきでない場合、「偽」を戻すことによって表される。他のタスクは、必要に応じて、UPDをINSまたはDELのいずれかに変更することである。

【0130】

【表2】

【0131】

図7は、上で列挙された例示的なコードによって実行される方法を例示する。この方法は、図7Aの開始ステップ700から始まり、対内の第1のインスタンスと最後のインスタンスとに関する受入れが決定されるステップ701に進む。その対が「母」または「子」を表す場合、受入れは、下で図8を参照して説明される方法によって決定可能である。その対が「父」を表す場合、受入れは、図9を参照して下で説明される方法によって決定可能である。本発明のいくつかの実施形態によれば、対の記録タイプの役割を初めに決定するのではなく、両方の方法が実行されて、両方とも、結果として、そのインスタンスが肯定的な受入れを有するために、肯定的な受入れをもたらすべきである。

【0132】

この方法は、次いで、その対がINSコマンドを表すかどうかを決定するステップ702に進む。その対がINSコマンドを表す場合、かつステップ703で決定されるように、その対内の最後のインスタンスが受け入れられない場合、この方法は、ステップ704において、その対のフィルタリングに関して「偽」を戻す。最後のインスタンスが受け入れられる場合、この方法は、ステップ705においてフィルタリングに関して「真」を戻す。これは、その対がINSとして列挙され、その対内の最後のインスタンスに関するその受入れが「真」である場合、その対はフィルタを通過して、クライアント内に挿入されるべきであることを意味する。このとき、その対が受け入れられない場合、その対は無関係であり、この方法は「偽」を戻す。便宜上、この対は、2つの同一インスタンスによって表すことが可能である。あるいは、設計選択として、挿入は、1つだけのインスタンスを伴う「半」対として表すことが可能である。

【0133】

ステップ706において、その対がDELを表すことが決定された場合、この方法は、ステップ707に進む。ステップ707において、その対内の第1のインスタンスがそのクライアント内で受け入れられなかったことが決定された場合、この方法は、ステップ708においてフィルタリングに関して「偽」を戻す。そうでない場合、この方法は「真」を戻す。これは、その対がDELとして列挙され、その対の第1のインスタンスに関するその受入れが真である場合、その対はクライアントに既に存在するはずであり、その対はサーバ上のデータベースから除去されているため、その対は除去されるべきであることを意味する。したがって、DELは引き続き削除である。図7の方法は、これらの事例において、その対のインスタンスのうちの1つだけを考慮する必要があるため、この例は、DEL事例およびINS事例に関して「半」対だけ入力する一実施形態がどの程度十分であるかを示す。

【0134】

ステップ710で決定されるように、その対がUPDとして列挙された場合、更新は、図7Aと図7Bの両方で表されるステップ711に示されるように、図7Bで例示されるように処理されなければならない。更新は以下のように処理される。ステップ712において、その対の両方のインスタンスがクライアント内で受け入れられたことが決定された場合、これは、その記録がクライアント上に既に存在しており、引き続きその状態に残るべきであることを意味する。したがって、サーバで行われたのと同じ更新をクライアントで行い、UPDが維持される必要がある。この方法は、ステップ713でフィルタリングに関して「真」を戻し、この対はクライアントを更新すべきである。ステップ714において、その対内の第1のインスタンスは受け入れられたが、最後のインスタンスは受け入れられないことが決定された場合、これは、その記録はクライアント上に存在するが、もはやそうではないことを意味する。その結果として、その対は、ステップ715において、「更新」から「削除」に変更され、この方法は、フィルタ値「真」を戻し、その記録は、もはや受入れられず、それに応じて、その対はクライアントを更新するために、フィルタを通過しなければならない。ステップ717において、その対内の第1のインスタンスが受け入れられておらず、最後のインスタンスが受け入れられることが決定された場合、その記録は、クライアント内に存在せず、挿入されなければならない。その結果として、ステップ718において、その対は「更新」から「挿入」に変更される。それらのインスタンスがいずれも受け入れられない場合、この方法は、ステップ720において、フィルタ値「偽」を戻す。

【0135】

本発明のいくつかの実施形態では、削除または挿入に対する更新の変更は、トリガ(図6のステップ604)の間実行されず、同期(図5のステップ507)の間にだけ実行される。代替の実施形態では、しかし、その対は、トリガの間に変更可能であり、図6のステップ604におけるプロセスの一環として、トリガのリスト内で変更可能である。後者の場合、同期の間に、変更を再度実行する必要がない場合がある。

【0136】

受入れ方法は、次に、記録タイプのインスタンスに関する受入れを決定するためのプロセスが例示される図8を参照してさらに詳細に説明される。この受入れ方法は、上で列挙された例示的なコードにおいて、OnRT_Accept(インスタンス)と呼ばれる方法である。本発明の原理と一致して、受入れを決定する基本的な原理は、その記録が、それ自身が受け入れられないサブセットオーナーのサブセットの一部でない限り、またはその記録がユーザ定義された受入れ方法によって明示的に受け入れられない場合、記録は受入れ可能であるというものである。前者は、データ整合性が維持されること(その記録が、受け入れられていない別の記録の参照を含む場合、記録は受け入れられないこと)を確実にし、後者は、クライアントに転送されるデータ量を削減する能力を設計者に提供できる。したがって、図8を参照して説明される方法は、検査される記録タイプインスタンスが、上で提示された理由のうちの1つにより、受け入れられないかどうかを決定する。受け入れられないことが決定された場合、そのインスタンスに関する受入れは、否定的に決定される。そうでない場合、そのインスタンスは受け入れ可能である。

【0137】

「父」役割を備えた記録タイプに関する受入れは、下で説明されるように、若干異なって決定可能である。

【0138】

記録タイプのインスタンスは、特定の時点で特定の記録タイプの特定の記録内に格納された値を表し、これらの値はログから見出すことができる点を想起されたい。現在、受入れ方法によって検査されている記録タイプのインスタンスは、「記録タイプインスタンス」または「RTインスタンス」と呼ばれることになり、その記録タイプは、「記録タイプ」またはRTと呼ばれることになる。さらに、受入れ方法によって検査されるインスタンス、すなわち、「RTインスタンス」は、1つまたは複数のサブセットオーナーに関係しうる。サブセットオーナーは、考慮中の記録タイプによって参照される、異なる記録タイプのインスタンスである。サブセットオーナーの記録タイプは、「オーナー記録タイプ」、またはORTと呼ばれることになり、オーナー記録タイプの特定のインスタンスは、「オーナー記録タイプインスタンス」、または「ORTインスタンス」と呼ばれることになる。「ORTインスタンス」は、「RTインスタンス」内のそのインスタンスと、ログ内の「RTインスタンス」のタイムスタンプとを参照することによって識別可能である。

【0139】

このプロセスは、開始ステップ800で始まり、記録タイプに関する第1のサブセットオーナーが識別されるステップ801に進む。ステップ802において、ORTが識別されていないことが決定された場合、プロセスは、下で議論されるステップ810に進む。ORTが識別されている場合、プロセスは、その識別されたORTが考慮中の記録タイプを制限できるかどうかが決定されるステップ803に進む。ORT自体が、受入れにより、クライアントに不在な可能性がある場合、RTはORTによって制限される。ORTがクライアントによって受け入れられない場合、RTの受入れは、制約要件に違反する(RTは、クライアントに不在のORTに関係する可能性があり、これは、データ整合性を損なうことになる)ため、RTも受け入れられるべきではない。「オーナー記録タイプ」が「記録タイプ」を制限できるかどうかは、ORTの役割を考慮することによって決定可能である。ORTが「母」または「子」である場合、そのORTはRTを制限できる。さらに、ORTが「父」である場合、またはORT自体が「父」によって制限される(すなわち、「姉妹」である)場合、RTはORTによって制限されうる。この場合、ORTは、間接的な「母」と呼ばれる場合がある。「オーナー記録タイプ」が間接的な「母」であるかどうかを決定するプロセスは、下でさらに詳細に説明される。

【0140】

ステップ803において、ORTがRTを制限できないことが決定された場合、プロセスは、次のORTが識別されるステップ804に進む。しかし、ORTがRTを制限できる場合、「RTインスタンス」によって参照される特定の「ORTインスタンス」がステップ805において確立される。「ORTインスタンス」は、「RTインスタンス」内でその主キーを参照している外部キーからその主キーをまず識別し、次いで、適時にこの「ORTインスタンス」に関連する値を見出すために、ログを走査することによって確立される。このログは、「RTインスタンス」がその対内の第1のインスタンスである場合、時間窓Δtの開始時に適切なインスタンス値を決定し、「RTインスタンス」がその対内の最後のインスタンスである場合、時間窓Δtの終了時に適切なインスタンス値を決定するために逆に走査される。ステップ806において、「ORTインスタンス」が適切に確立されたかどうかを決定するために点検が行われる。確立されなかった場合、すなわち、例えば、「RTインスタンス」がその対内の第1のインスタンスであり、データベース内の対応するRT記録がΔtの間に挿入され、したがって、そのRT記録は存在せず、したがって、その時間窓の開始時にORTを有さなかった場合、プロセスは、「RTインスタンス」に関する受入れが「偽」に設定されるステップ808に進む。しかし、「ORTインスタンス」が適切に作成された場合、プロセスは、「ORTインスタンス」に関する受入れが決定されるステップ807に進む。

【0141】

ORTが「母」または「子」である場合、「ORTインスタンス」に関する受入れは、「RTインスタンス」に関するのと同じように決定可能である。すなわち、「ORTインスタンス」の受入れを決定するために、現在説明されている方法を再帰的に呼び出すことができ、これは、当然、この場合も、その独自の「ORTインスタンス」に依存する場合がある。

【0142】

しかし、ORTが「父」である場合、そのORTはその「息子」によって、すなわち、そのオーナーでないが、そのサブセットツリーの一部である記録タイプインスタンスによって制限されうる。この場合、図9を参照して下でさらに説明されるように、異なる方法を起動することが可能である。

【0143】

ステップ809において、「ORTインスタンス」が受け入れられないことが決定された場合、「RTインスタンス」は受入れ可能ではなく、プロセスはステップ808に進む。しかし、「ORTインスタンス」が受け入れられる場合、プロセスは、その「RTインスタンス」の受入れが依存する追加のサブセットオーナーが存在するかどうかを識別するために、ステップ804に進む。この場合、ステップ802で決定されたように、プロセスはこのORTに関して繰り返される。「ORTインスタンス」が、結果として、ステップ806または809において否定的な結果をもたらし、ステップ808において受入れが「偽」に設定された後で、プロセスがステップ813で終了するまで、またはステップ802において、受入れのいかなる否定的な決定を伴わずに、すべてのORTが検査されていることが決定され、プロセスが、RTに関して定義された何らかのユーザ定義された受入れ方法が存在するかどうかを決定するために、ステップ810に進むまで、これは継続する。ユーザ定義された受入れ方法が定義されていない場合、「RTインスタンス」はいずれの「ORTインスタンス」によっても制限されず、いずれのユーザ定義された受入れ方法によっても制限されず、したがって、プロセスは、この方法がステップ813で終了する前に、受入れが「真」に設定されるステップ812に進む。ユーザ定義された受入れ方法が定義され、ステップ811において、ユーザ定義された受入れ方法に従って、「RTインスタンス」が受け入れられないことが決定された場合、プロセスは、「RTインスタンス」に関する受入れが「偽」に設定されるステップ808に進み、この方法はステップ813で終了する。ステップ811において、「RTインスタンス」がユーザ定義された受入れ方法によって受け入れられることが決定された場合、プロセスは、この方法がステップ812で終了する前に、「RTインスタンス」に関する受入れが「真」に設定されるステップ812に進む。

【0144】

図8を参照して上で議論された方法は、図3の例に戻ることによって例示できる。例えば、記録タイプ「購入」の対内の第1のインスタンスであるインスタンスは、「店舗」表302内の特定の店舗に関係するすべてのデータを保持しているPDAによって受け入れられるべきかどうかを考慮されたい。この方法がステップ801に達するとき、第1のORTは店舗_製品表304にあると決定され、ステップ803において、この記録タイプは「子」であるため、「購入」表308を参照できることが決定されることになり、したがって、プロセスはステップ805に進む。ステップ805において、「購入」インスタンスによって参照される店舗_製品表304内の特定の行が識別される、すなわち、店舗_製品インスタンスが確立されて、その主キーを作成する1つまたは複数の値が「購入」インスタンス内の対応する外部キー参照からフェッチされる。確立された店舗_製品インスタンスの残りのフィールドを埋めるために必要とされるこれらの追加の値は、ログを走査することによって見出すことが可能である。「製品」インスタンスは対内の第1のインスタンスであるため、当該値は、Δtの開始時の記録を表す値である。しかし、これらの値は、Δtの開始後に、場合によっては、Δtの終了後でさえ、ログ内に入力されたDELエントリー内に見出すことが可能である。結果として、ログの終わりから走査を開始することと、Δtの開始時またはそれに先立って、それらの値を最もよく表すログエントリーが主キーによって識別された店舗_製品記録に関して見出されるまで逆に走査することとが必要な可能性がある。ログエントリーが行われたとき、ログが記録のすべての値を格納する場合、この1つのログエントリーを見出すことは、「ORTインスタンス」を完全に埋めるために十分である。変更された値だけがログ内に入力される場合、すべての値が取得されるまで、ログを逆に走査し続けることが必要になる。

【0145】

ログの走査の間にログエントリーを選択することは、設計選択に依存しうる点に留意されたい。例えば、実装は、ログエントリーが考慮されるべきかどうか、ログエントリーが、時間窓Δtの開始(もしくは、終了)時またはその後の記録値を表すか、あるいは時間窓の開始(もしくは、終了)の前の記録値だけを表すかに関して異なる場合がある。その理由は、ログエントリーが1つの時間窓の終了と連続する時間窓の開始の両方に属するように、重複する時間窓を有することは望ましく可能性があるためである。場合によっては、ログは、適切な記録インスタンスの確立を可能にすることになるいかなる関連するログエントリーも含まないことになる。これは、例えば、ログがパージされているため、またはデータベースが作成されたときからの当初の値が一度も変更されておらず、したがって、一度もログされていない場合でありうる。そのような場合、データベース自体の中に見出された値は時間窓よりも古く、その結果として、これらの値はその対内の両方のインスタンスに関して使用できるという結論を下すことができる。その他の場合、削除を表すログエントリーは、時間窓Δt内に、または時間窓Δtの終了後にすら見出すことができ、依然として、その時間窓の開始時または終了時の適切な値を表すのは、必要性によって削除されたエントリーは、そのエントリーが削除される前のその記録に関する値を表すためである。まさにどのログエントリーが、それらの適切な値を見出すための適切な候補でありうるかは、したがって、例えば、ロギングがどのように実行されるか、および同期の間にデータベースがどのように行動するか、ならびに更新窓がどのように決定されるかに関する実装詳細に依存する可能性がある。しかし、この原理は、現在の同期または前の同期が開始した時点で、特定の記録の状態を最もよく表す値を取得することである。

【0146】

店舗_製品に関する「ORTインスタンス」が適切に確立された後で、プロセスは、その受入れが決定されるステップ807に進む。「ORTインスタンス」は「RTインスタンス」に関する「子」であるため、その受入れは、同じ方法によって決定でき、プロセスは、「ORTインスタンス」に関するステップ800で再開する。ステップ801において、店舗_製品表304に関する第1のORTは「製品」表305であることを決定することが可能である。次いで、ステップ803において、「製品」表305は店舗_製品表304に関して「父」であり、その結果として、店舗_製品表304を制限できないことを決定することが可能である。「製品」表305は、下で議論されるように、「品目総額」表306に対して間接的「母」であり、したがって、表306を制限することができるが、店舗_製品表304は制限できず、プロセスは、店舗_製品表304に関する次のORTが検査されるステップ804に直接進む。これは「店舗」表302になり、したがって、プロセスは、ステップ802から、ORT店舗302がRT 店舗_製品304を制限できることが決定されることになるステップ803に進み、プロセスは、店舗_製品インスタンス内で参照される「店舗」エントリーに関する「ORTインスタンス」が確立されるステップ805に進む。このプロセスは、店舗_製品インスタンスの確立に関して上で説明されたプロセスと同じであり、「店舗」インスタンスが、ステップ805において成功裏に確立されることを条件に、プロセスは、確立された「店舗」インスタンスに関する受入れを決定するためにステップ807に進む。

【0147】

「店舗」記録タイプは「母」であるため、この場合も同じプロセスを使用することが可能であり、プロセスは、確立された「店舗」インスタンスに関してステップ800で再開される。「店舗」表302のサブセットオーナーだけが「店舗オーナー」表301である。上で説明されたように、店舗オーナー表301は、任意の受入れ方法に直接的または間接的に関連せず、したがって、「店舗オーナー」表301は何の役割も有さない。したがって、「店舗オーナー」表301はいずれのサブセットメンバーも制限できず、ステップ801から804を一度通過した後で、ステップ802において、追加のORTは見出されないことが決定されることになる。プロセスは、次いで、「店舗」表302に関して定義された、ユーザ定義された受入れ方法が存在することが決定されるステップ810に進む。ステップ811において、ユーザ定義された受入れ方法に依存する受入れが決定される。この特定の例では、ユーザ定義された受入れ方法は、パラメータホルダPDA表303内に見出すことができるパラメータに依存しうる。

【0148】

受入れが否定的であると決定された場合(すなわち、この特定の「店舗」エントリーが同期されている特定のPDA上に存在すべきでない場合)、プロセスは、受入れが「偽」に設定されるステップ808に進む。プロセスがステップ813で終了するとき、処理は、店舗_製品インスタンスに関して、この結果を伴ってステップ807に戻る。ステップ809において、次いで、店舗_製品インスタンスに関する「ORTインスタンス」が受け入れられないことが決定されることになり、したがって、プロセスは、プロセスがステップ813で終了する前に、店舗_製品インスタンスに関する受入れが「偽」に設定されるステップ808に進むべきである。このプロセスの終了時に、「購入」インスタンスに関して、その結果がステップ807に報告し戻される。次いで、ステップ809において、検査されている「購入」に関する「ORTインスタンス」は受け入れられないことを決定することが可能であり、したがって、プロセスは、受入れが「偽」に設定されるステップ808に進むべきである。プロセスは、次いで、「購入」インスタンスが受け入れられないことが決定された後に、ステップ813で終了する。

【0149】

逆に、「店舗」表に関して定義された、ユーザ定義された受入れ方法の検査が、結果として、ステップ811において受入れの肯定的な決定をもたらす場合(すなわち、この「店舗」エントリーは、同期されている特定のPDA上に存在すべきである場合)、プロセスは、確立された「店舗」インスタンスに関する受入れが「真」に設定されるステップ812に進む。「店舗」インスタンスの処理が終了するとき、この結果は、ステップ807において、店舗_製品インスタンスの処理に報告し戻される。次いで、ステップ809において、「ORTインスタンス」は受け入れられることが決定されることになり、処理は、この記録タイプ(既に考慮されている「製品」記録タイプ)に関して追加のORTが存在しないことが決定されるステップ804に進む。したがって、プロセスは、ステップ802を経由して、店舗_製品表に関してユーザ定義された受入れ方法が存在しないことが決定されるステップ810に進む。次いで、プロセスは、プロセスがステップ813で終了する前に、受入れが「真」に設定されるステップ812に進む。この結果は、次いで、「購入」インスタンスに関する受入れを決定するプロセスにおいて、ステップ807に報告し戻される。このプロセスは、次いで、ステップ809に進み、「ORTインスタンス」に関して、受入れは肯定的であるため、そこからステップ804に進む。ステップ804において、購入表308に関して追加のORTは識別されないことになり、したがって、プロセスは、ステップ802から、購入表308に関してユーザ定義された受入れ方法が存在しないことが決定されることになるステップ810に進むことになる。プロセスは、次いで、プロセスがステップ813で終了する前に、この「購入」インスタンスに関して受入れが「真」に設定される、ステップ812に進む。

【0150】

次に、「父」記録タイプに関する受入れの決定を例示する図9を参照する。既に述べたように、「父」はその「息子」によって、すなわち、オーナー記録タイプでないが、その「父」に関するサブセット記録タイプである記録タイプによって制限されうる。したがって、図8の受入れ方法に加えて、記録タイプインスタンスが「息子」によって制限されるかどうかを決定することが必要な場合がある。上で列挙された簡素化されたコードにおいて、これは、OnRT_AcceptFather(インスタンス)と呼ばれる方法として示される。この方法は、図9に例示される。正規の受入れルーチン同様に、この方法は、対内のインスタンスに関して実行される。

【0151】

この方法は、開始ステップ900から始まり、検査されている記録タイプ、すなわちRTに関して「父」事象が宣言されているかどうかが決定されるステップ901に進む。「父」事象が宣言されていない場合、「息子」は識別されないことになり、この方法は、ステップ902において、プロセスがステップ911で終了する前に、「RTインスタンス」に関して受入れが「真」に設定される、ステップ910に分岐する。

【0152】

ステップ902において、記録タイプに関して「父」事象が宣言されていることが決定された場合、「メンバー記録タイプ」、すなわち、MRTの識別が取り出されて、ステップ903において、第1の「メンバー記録タイプ」が検査される。ステップ904において、MRTが見出された場合、このプロセスは、検査されたMRTがステップ902で識別された制限している「息子」であるかどうかが決定されるステップ905に進む。制約している「息子」でない場合、プロセスは、ステップ906において、次のMRTを検査する。ステップ902において、制限している「息子」が実際に存在することが決定された場合、この記録タイプも最終的に見出されるべきである点に留意されたい。しかし、ユーザによって「父」事象が宣言されているため、制限している記録タイプを見出すこの方法は、存在しない記録タイプの識別を戻す、誤って宣言された「父」事象を処理できるはずである。処理できる場合、この方法は、ステップ904において、追加のMRTは見出されないことを最終的に決定することになり、プロセスは、プロセスがステップ911で終了する前に、「RTインスタンス」に関して、受入れが「真」に設定されるステップ910に進む。

【0153】

ステップ905において、検査されたMRTがRTの制限している「息子」であることが決定されるとき、プロセスは、識別された「メンバー記録タイプ」内の少なくとも1つのインスタンスが肯定的な受入れを有するかどうかが決定されるステップ907に進む。このプロセスは、図10を参照して、下でさらに説明される。

【0154】

少なくとも1つの受け入れられた「息子」の存在は、「父」インスタンスがクライアント上に存在する必要があることを意味する。ステップ908において、MRT表からの少なくとも1つの受け入れられたインスタンス、すなわち、1つの受け入れられた「息子」が見出されたことが決定された場合、プロセスは、プロセスがステップ911で終了する前に、「RTインスタンス」に関して、受入れが「真」に設定されるステップ910に進む。それとも、受け入れられたインスタンスが見出されない場合、この方法は、プロセスがステップ911で終了する前に、「RTインスタンス」に関して、受入れが「偽」に設定されるステップ909に進む。

【0155】

次に、肯定的な受入れを伴って、制限している「息子」の存在を決定するための方法が例示される図10を参照する。この方法は、開始ステップ1000から始まり、「RTインスタンス」に一致し、いずれのログエントリーも有さない第1のMRTインスタンスが識別されるステップ1001に進む。「RTインスタンス」に一致するすべてのMRTインスタンスがロギングされているという保証は存在しない。例えば、MRTは、データベースが作成されて以来ずっとそのクライアントによって受け入れられている可能性があり、それ以来、この記録に何の変更も行われていない可能性があるか、または例えば、そのログが、ある日数よりもより古いログエントリーを除去するプロセスにおいてパージされている可能性がある。既存のログよりも当然古いデータベースエントリーは、関連する時間窓Δtの間、変更されずに存在していたに違いないため、データベースを直接的に検査することによって、そのようなインスタンスを見出すことが可能である。これは、時間窓の開始よりもより古いエントリーがそのログからパージされている場合ですら、またはデータベースは、ログなしで作成されたが、同期時間窓の開始前にロギングがオンにされている場合ですら、ロギングが時間窓の開始よりも古いことは、この方法が作動できるために十分であることを意味する。

【0156】

ステップ1002において、ログエントリーを伴わない、一致するMRTインスタンスが見出されたことが決定された場合、プロセスは、MRTインスタンスに関する受入れが決定されるステップ1003に進む。これは、図8を参照して上で説明された方法と同じ方法を使用して行うことが可能である。ステップ1003において、識別されたインスタンスがクライアントにおいて受け入れられたことが決定された場合、プロセスは、プロセスがステップ1009で終了する前に、この方法が、受け入れられたMRTインスタンスが見出されたことを示す「真」を戻すステップ1008に進む。それとも、ステップ1003において、MRTインスタンスが受け入れられないことが決定された場合、この方法は、RTに一致し、ログエントリーを伴わない次のMRTインスタンスを見出すために、ステップ1001に戻る。ステップ1003において、受け入れられたMRTインスタンスが見出されていることが決定されるまで、またはステップ1002において、検査されている「記録タイプ」に一致する追加の「メンバー記録タイプ」インスタンスを見出すことができないこと(すなわち、すべての一致するMRTインスタンスは検査されており、どれも受け入れられなかったこと)が決定されるまで、このプロセスは継続する。後者の場合、プロセスは、ステップ1004に進む。

【0157】

ステップ1004において、RTに一致する第1のMRTインスタンスがログから見出される。図8のステップ805に関して実行されたプロセスに類似したプロセスで、ログエントリーからMRTインスタンスを作成するために、ログは逆に走査される。このプロセスは、「RTインスタンス」が対内の第1のインスタンスであるか、または最後のインスタンスであるかに応じて、窓Δtの開始時または終了時に、適切なインスタンス値を確立することを追及する。上で述べたように、適切な時点よりも新しいログエントリーは関連する可能性があり、例えば、DELエントリーは、DELエントリーに関するタイムスタンプよりも前の時点の値が何であったかを示すことが可能である。このログは、したがって、窓の開始時または終了時の値を最もよく表すエントリーが見出されるまで、最新のエントリーから逆に走査可能である。

【0158】

ステップ1004において、RTに一致するMRTインスタンスがログ内に見出されることが決定された場合、プロセスは、MRTインスタンスが受け入れられるかどうかが決定されるステップ1006に進む。ステップ1006において、識別されたインスタンスがクライアントにおいて受け入れられることが決定された場合、プロセスは、プロセスがステップ1009で終了する前に、この方法が、受け入れられたMRTインスタンスが見出されたことを示す「真」を戻すステップ1008に進む。しかし、ステップ1006において、MRTインスタンスが受け入れられないことが決定された場合、この方法は、ログからRTに一致する次のMRTインスタンスを見出すために、ステップ1004に戻る。ステップ1006において、受け入れられたMRTインスタンスが見出されていることが決定されるまで、またはステップ1005において、検査されている「記録タイプ」に一致する追加の「メンバー記録タイプ」インスタンスを見出すことができないこと(すなわち、ログから導出可能なすべての一致するMRTインスタンスが検査されており、どれも受け入れなかったこと)が決定されるまで、このプロセスは継続する。後者の場合、プロセスは、プロセスがステップ1009で終了する前に、この方法が、受け入れられたMRTインスタンスが見出されなかったことを示す「偽」を戻すステップ1007に進む。

【0159】

図3を再び参照すると、図9および図10のプロセスの短い例を提示できる。図9のプロセスは、「製品」表305からの対の所与のインスタンスが同期されているクライアントによって受け入れられるか(または、受入れられたか)を決定することを目標とする。例えば、この対は、PRODUCT01に関係しうる。ステップ901において、「製品」表305に関して「父」事象が実際に宣言されていることが決定される。ステップ902において、「製品」表305を制限している「メンバー記録タイプ」の識別が取り出され、この識別は、店舗_製品表304を識別することになる。ステップ903において、「品目総額」表306でありうる第1のMRTが検査される。その結果として、ステップ904において、MRTが見出されたことが決定されるが、ステップ905において、そのMRTはステップ902内で識別された制約表でないことが決定されることになる。プロセスは、したがって、次のMRTが検査されるステップ906に進む。これは店舗_製品表305になり、プロセスは、したがって、ステップ906からステップ904に進み、このとき、検査されているMRTが制約表として識別される表、すなわち、「父」RTに対する「息子」であることを確立できるステップ905に進む。プロセスは、したがって、制約表、すなわち、MRT 店舗_製品304が、現在検査されているその表からその対のインスタンス内で識別された「製品」表305のエントリーを参照している任意のエントリーを含むかどうか、およびそれがクライアントにおいて受け入れられるかどうかを決定するために、ステップ907に進む。例えば、「製品」表305内のPRODUCT01を参照し、適時にクライアントにおいて受け入れられるエントリーが店舗_製品表304内に存在するか。

【0160】

この質問に回答するために、図10を参照して説明されたプロセスを使用することが可能である。ステップ1001、1002、および1003において、PRODUCT01を参照し、ログエントリーを有さない店舗_製品表304内のエントリーが検査される。そのようなエントリーが見出されて、肯定的な受入れを有することが決定されるとすぐに、この方法は、図9のステップ907に値「真」を戻し、図9に例示される方法は、受け入れられたMRTインスタンスが見出され、この方法が、PRODUCT01のインスタンスに関する受入れがクライアントにおいて受け入れられるべきであるステップ910に進むべきであることが決定されるステップ908に進む。

【0161】

ステップ1001、1002、および1003において、PRODUCT01に一致する、受け入れられたMRTインスタンスを見出すことができる場合、プロセスは、PRODUCT01に一致する、受け入れられたMRTインスタンスをログから見出すことができるかどうかを決定するために、ステップ1004、1005、および1006に進む。見出すことができる場合、方法は、ステップ907に値「真」を再度戻し、この場合、この方法は、ステップ908および910に再度進み、この場合、PRODUCT01のインスタンスに関する受入れはクライアントにおいて受け入れられるべきである。

【0162】

PRODUCT01を参照する、受け入れられた店舗_製品インスタンスを見出すことができない場合、図10のこの方法は、ステップ1009で終了する前に、ステップ1007に進む。店舗_製品表304内のエントリーはPRODUCT01を参照せず、同期されているクライアントにおいて受入れられないことを示す値「偽」が図9のステップ907に戻される。これは、そのクライアントに関連するどの店舗もPRODUCT01を扱っていないため、PRODUCT01がクライアント上に必要とされないことを意味する。図9のプロセスは、ステップ908において、関連するMRTインスタンスが見つからなかったことを決定して、この方法がステップ911で終了する前に、PRODUCT01に関する受入れが「偽」に設定されるステップ909に進む。

【0163】

次に、図6のステップ606によって表される役割に基づくトリガリングのプロセスが、下でさらに詳細に説明される。上で説明されたように、CollectRecordsと呼ばれる第1の方法は、考慮中の、Δt_iの間に変更されていない、データベース内のすべての記録を収集して、データベースΔを生み出す。このプロセスは、図5のステップ502に対応する。これらの収集された記録は、図5のステップ503に対応する、1つがΔt_iの開始時である時間t_i-1における記録の値を含み、1つが時間t_iに先立つ記録に関する値を含む、記録の2つのインスタンスを含む対としてトリガのリスト内に登録可能である。BrowseExternalAcceptanceChangeと呼ばれる第2の方法は、図5のステップ504を参照して説明されたように、Δt_iの間にいずれの値も変更していないが外部変数により、その受入れを変更させた記録を識別するためにデータベースを閲覧する。識別された記録は、ステップ505において、対として同じトリガのリストに追加された。これらの2つの方法によって作成されたリストは、次いで、図5のステップ506として表され、図6においてさらに詳細に説明されたトリガリングのプロセスに対する入力として使用可能である。トリガリングのプロセスは、追加の記録を識別し、このように識別された記録は、図6のステップ603および606において、対としてトリガのリストに追加される。これらのトリガされた対は、次いで、そのリスト内のすべての対が検査されるまで、CollectRecords方法とBrowseExternalAcceptanceChange方法とによってリストに追加された対と全く同じように検査される。したがって、そのリスト内のすべての対が検査されるまで、トリガおよびトリガされた対のリストは注意深く検討される。

【0164】

リスト内に表される対は、それが収集プロセスの結果として追加されたか、閲覧プロセスの結果として追加されたか、またはそのリストに既に追加されていた対によってトリガされたかどうかにかかわらず、原則として、任意の種類の役割を有することが可能である点を理解されよう。どの追加の対をトリガすべきかを決定するために、図6のステップ606において検査されるすべての対は、したがって、それらの対がどのようにリストに追加されたかにかかわらず、同じ手順に従って検査可能である。

【0165】

トリガのプロセスはトリガされた記録に関して繰り返されるため、その対のサブセット制約階層全体ではなく、トリガ対の最も近い関連性をトリガすることだけが必要である点に留意されたい。例えば、「母」が「子」をトリガする場合、その「子」の「子」は、今度は、第1の「子」によってトリガされることになるため、「母」が「子」をトリガすることは、その「子」の「子」もトリガする必要はない。しかし、トリガされた対のサブツリーをさらにトリガするトリガリングの他の方式を定義することは、本発明の原理と一致する。

【0166】

図3の説明から、6つの別個の役割を定義できることを想起されよう。これらの役割は、ここで、「母」、「子」、「息子」、「父」、「姉妹」、および「兄弟」と呼ばれる。しかし、記録タイプは、1つの役割だけを有するとは限らない。役割は、1つの記録タイプがどのように別の記録タイプと関係するかによって定義され、記録タイプはいくつかの他の記録タイプと関係する場合があるため、記録タイプは、いくつかの役割を有する場合がある。特定の記録タイプのインスタンスを表す対がトリガとして機能するとき、その記録タイプのすべての役割を検査することが必要な場合がある。

【0167】

以下の事例を識別できる。
i)記録タイプは「母」である
ii)記録タイプは「子」である
iii)記録タイプは「母」および「子」である
iv)記録タイプは「母」、「子」、および「息子」である
v)記録タイプは「母」、「子」、「息子」、および「兄弟」である
vi)記録タイプは「子」および「息子」である
vii)記録タイプは「子」、「息子」、および「兄弟」である
viii)記録タイプは「父」である
ix)記録タイプは「姉妹」である

【0168】

加えて、役割を持たない記録タイプが存在する。役割を有さない対は、何もトリガしないことになる。図3の例では、「店舗オーナー」301は役割を有さない。

【0169】

事例i)によれば、記録タイプは「母」である。これは、記録タイプは、この記録タイプの「子」である他の記録タイプにだけ関係することを意味する。図3の例では、「店舗」記録タイプ302はそのような記録であり、「店舗」記録タイプ302は2つの「子」、すなわち、PDA記録タイプ303と店舗_製品記録タイプ304とを有する。「母」の「子」は、トリガのための候補であり、すなわち、より詳細には、考慮中の特定の「店舗」に対する外部キー参照を含むこれらの2つの記録タイプのインスタンスの任意の対はトリガのリストに追加されるべきである。任意の追加の記録タイプをトリガする必要はない。任意のそのような記録タイプがトリガのリストに追加されるべきである場合、これは、トリガされた「子」が検査されるときに行われることになる。この場合、店舗_製品が検査されるとき、任意の「製品」、「購入」、「販売総額」または「品目総額」の対がトリガされることになる。トリガリングは、AddChildrenと呼ばれる場合がある方法によって処理可能である。

【0170】

事例ii)によれば、記録は「子」である。パラメータホルダとは別に、「子」記録タイプは、その記録タイプがその「子」である記録タイプをトリガしなくてよい。これは、「子」記録タイプが、その記録タイプがその「子」である記録タイプに関する何らかの追加の情報を保持し、この追加の情報が「親」記録タイプを関係させないことによって実現されることになる。パラメータホルダに関しては、パラメータホルダは、図6のステップ603でその「母」をトリガする。ここで説明される本発明の実施形態によれば、役割に基づくトリガリングは、別個のステップ606であり、したがって、パラメータホルダは、その「母」の「子」である立場で「母」をトリガしない。

【0171】

図3では、「子」の役割を有する記録タイプの4つの例、すなわち、PDA記録タイプ303と、店舗_製品記録タイプ304と、「店舗」記録タイプ307と、「購入」記録タイプ308とが存在する。「子」記録タイプは、その「子」だけをトリガし、記録タイプPDA303と、「販売」307と、「購入」308とは「子」を有さないため、この特定の例では、これらは任意の追加の対をトリガしない。しかし、店舗_製品記録タイプ304は、下で議論される「息子」および「兄弟」でもあるため、この記録タイプは、任意の追加の対をトリガする。「子」役割を有する記録タイプの対に基づくトリガリングは、この場合も、AddChildren方法によって処理可能である。

【0172】

事例iii)によれば、記録タイプは「母」である(すなわち、自身に関連するフィルタを有する)が、自身が何らかの他の記録タイプの「子」でもある。図3には、これらの2つの役割を有する記録タイプは存在しない。上述のように、対はその「母」をトリガしない。例えば、特定の店舗によって仕入れられていないある著者の著作目録に変更が存在する場合を考慮されたい。その店舗の在庫品を有するクライアントが同期される場合、その著作目録内の変更はその著者を表す「著者」記録タイプの対をトリガしなくてよい。しかし、考慮中の記録タイプの独自の「子」はすべてのサブセット制約を満たすために必要な情報を保持する可能性があるため、考慮中の記録タイプは、「母」および「子」の両方として、その独自の「子」をトリガする必要があることになる。この場合も、トリガリングを処理するために、AddChildren方法を使用することが可能である。

【0173】

事例iv)によれば、考慮中の対の記録タイプは、「母」および「子」であるだけでなく、「息子」でもある。この場合も、図3には、任意のそのような組合せの例は存在しない。上で説明されたように、AddChildren方法は、考慮中の対の「子」を追加するために使用可能である。しかし、この記録タイプは「息子」でもあるため、その「父」を追加することが必要な場合がある。これは、AddFatherと呼ばれ、下でさらに議論される方法によって行うことが可能である。

【0174】

事例v)によれば、考慮中の対は、「母」、「子」、「息子」、および「兄弟」でもある記録タイプである。初めの3つの役割は、上記と同じ効果を有し、「兄弟」の役割は、「兄弟」の「姉妹」を追加することを必要にする場合がある。これは、下でさらに詳細に説明されるAddSisterOfBrother方法によって行うことが可能である。

【0175】

事例vi)によれば、この対は、「子」および「息子」である記録タイプのものであり、その「子」ならびにその「父」を追加することが必要な場合がある。

【0176】

事例vii)によれば、この対は、「子」、「息子」、および「兄弟」の役割を有する記録タイプのものである。図3の記録タイプ店舗_製品304は、そのような役割の組合せの一例である。この記録タイプは、「店舗」記録タイプ302の「子」であり、「製品」記録タイプ305の「息子」である。加えて、この記録タイプは、記録タイプ「品目総額」306の「兄弟」である。記録タイプが「父」に対する参照を含むとき、その記録タイプは「息子」である。「息子」役割は、「父」役割を制限する役目を果たす。この場合、その記録タイプは、表305から、所与の店舗302によって実際に仕入れられた製品だけがその店舗の在庫品を保持するクライアントPDAにインポートされることを確実にするための役目を果たす。加えて、記録タイプ304の対は、「品目総額」記録タイプ306に対して「兄弟」である。「品目総額」記録タイプ306は、「父」記録タイプの製品305の非制約的なサブセットメンバーである。これは、「兄弟」記録タイプ内の変更は「姉妹」記録タイプに影響を及ぼすことを意味する。一例は、その店舗内に新しく追加された「製品」(すなわち、「品目」)の販売は「品目総額」表306に新しい記録として追加されるべきであり、逆に、クライアント上で利用可能な所与の「製品」の総売上高を作成するために、「父」表305からの製品だけではなく、「姉妹」表306からの製品に関する総数も追加する必要がないという点で、「製品」表305から新しい製品を「店舗」表302内の店舗の在庫品に追加する店舗_製品内の変更は、「品目総額」表306に影響を及ぼすことになるというものであろう。これは、AdSisterOfBrotherと呼ばれることになる方法によって処理可能である。

【0177】

要約すると、「子」、「息子」、および「兄弟」の役割を組み合わせる記録タイプのインスタンスを生成する対の場合、記録タイプ、すなわち、「販売」307および「購入」308など、関連する「子」と、「製品」記録タイプ305によって例示されるような、関連する「父」と、「品目総額」記録タイプ306によって例示されるような「姉妹」とを追加する必要がある。これは、ここでAddChildren、AddFather、およびAddSisterOfBrotherと呼ばれる方法によって処理可能である。

【0178】

次に、記録タイプが「父」役割だけを有する事例viii)を参照すると、追加の考慮事項が必要になる。「姉妹」を追加することが必要な場合があるが、それは、「父」を表す対がUPDである場合だけである。これは、「父」記録タイプ305が製品を表し、一方、「姉妹」記録タイプ306が、その製品に関する総額を表す図3の例を考慮することによって理解されよう。「父」を表す対が新しい製品(INS)である場合、その製品が問題の特定の店舗にも追加されている場合だけ、「姉妹」はトリガされるべきであり、その場合、それは「店舗」302と「製品」305、すなわち、その「兄弟」に関連する新しい店舗_製品304の追加によってトリガされることになる点を理解されよう。同様に、製品が「父」から除去(DEL)される場合、その製品は、やはり店舗_製品から除去されなければならないことになり、そうでなければ、存在しない「製品」を参照した店舗_製品が存在することになる。この場合も、「姉妹」は、店舗_製品表304内の「兄弟」によってトリガされうる。しかし、「父」表内の変更が、「兄弟」表内に反映されないUPDである場合、関連する「姉妹」対は、「父」対によってトリガされなければならない場合がある。

【0179】

「父」に関して、「姉妹」は、「子」に類似するサブセットメンバーであるが、その「姉妹」には常に「兄弟」が存在することになるため、その役割は依然として「姉妹」と呼ばれる点に留意されたい。

【0180】

最後の事例ix)は、トリガ対が「姉妹」である事例である。「姉妹」は、その「姉妹」の「子」と考えることができる、他の記録タイプによって参照可能であるが、「姉妹」の「子」は、「父」とのその関係を通じてだけ関連するため、「姉妹」の「子」は、やはり「姉妹」として分類されることになり、したがって、同じトリガリング方法によって処理可能である。

【0181】

図3を参照して上で議論された例は、宣言された受入れ方法を伴う1つの表、すなわち、「店舗」表302だけを含む。いくつかの表がクライアント内で必要でないこと、例えば、「販売」表307および「購入」表308は、在庫品に関して使用されるクライアントに関して不要であることが決定された場合、それらの表がトリガされて、そのクライアントに転送されないことを確実にするために、これらの表に関して、追加の受入れ方法を宣言することが可能である。

【0182】

上の議論は、トリガの1つまたは複数の役割に応じて、どの役割がトリガされるかを説明する。表内のまさにどのエントリーがトリガのリストに対として追加されるべきかを決定することが依然として存在する。これは、次に、トリガ対の1つまたは複数の決定された役割に応じて、トリガのリストに対を追加することを処理する方法の点から説明される。

【0183】

対がトリガされて、トリガのリストに追加されるときはいつでも、トリガされた対の2つのインスタンスは、その適切な値を受信しなければならない。受入れの決定の間に、「ORTインスタンス」を作成するときに上で説明されたように、インスタンスが作成されるとき、2つの可能性が存在する。第1の可能性は、ログから適切な値を取り出すことである。その記録タイプエントリーに関するログエントリーが実際に存在するとすれば、タイムスタンプに関連する値を取り出して、その同期窓Δtに関する適切なタイムスタンプに対応するインスタンスを作成することが可能でありうる。ログエントリーを見出すことができない場合、何のログエントリーも存在しないため、その時間窓の開始前に、それらの値は変更されずに残っているはずであるという仮定の下に、適切な値をデータベース自体から取り出すことが可能である。対のインスタンスを埋めるこの方法は、下で議論されるすべてのトリガリング方法に関して実行可能であり、それぞれの個々の方法の議論の間に繰り返されないことになる。クライアント上の記録の複製を回避するために、対はトリガのリスト内に1回だけ入力されるべきである点にも留意されたい。これは、その対がリスト内に既に存在する場合、そのいずれもリスト内に対を入力しないように、下で説明される方法のそれぞれにおいて点検を含むことによって回避できる。あるいは、リストを走査して、トリガのプロセスが完了した後に複製を除去することが可能である。

【0184】

まず、図6を再び参照すると、ステップ602において、トリガ対がパラメータホルダであることが決定された場合、ステップ603において、AddMaterFamilias(対)と呼ばれる方法を使用して、対応する「母」がトリガされる。この方法は、トリガ対の記録タイプが実際にパラメータホルダであることを検証することによって開始する。パラメータホルダでない場合、他に実行することが存在しないため、この方法は終了する。パラメータホルダである場合、適切なオーナー記録タイプを識別しなければならない。図3の例によれば、トリガするパラメータホルダは、PDA表303からの対になり、ORTは、「店舗」表302になる。

【0185】

パラメータホルダは、他の対とは異なってトリガできる点に留意されたい。まず、一般に、他の記録タイプを参照する記録タイプは空(ヌル)値を有することはできないが、これは、それがサブセット制約に違反することになるためである。例えば、表304内の店舗_製品エントリーは、特定の店舗内で見出すことができる特定の製品を表し、その結果として、そのエントリーは、「店舗」表302内の店舗と、「製品」表305内の製品とを常に参照するはずである。同様に、購入表308内のエントリーは、店舗内の製品の実際の購入を表し、そのエントリーは、したがって、店舗_製品表304内の店舗_製品エントリーを常に参照するはずである。店舗および製品とのこの関連性を伴わない購入エントリーは存在しないはずである。しかし、パラメータホルダエントリーは、現在、現在ヌル値である外部キー参照を伴う、いずれの特定の店舗にも割り当てられていない特定のPDAに関して存在する場合がある。

【0186】

もう1つの差異は、パラメータ値の変更は実際に2つの「母」をトリガできる点である。例えば、図3の例のPDAがまず1つの店舗に割り当てられ、これが異なるPDAに対して変更する場合、両方の店舗をトリガすることが必要になるのは、元の店舗はそのPDAから除去されるべきであり、一方、新しい店舗はそのPDAに追加されるべきであるためである。

【0187】

結果として、この方法は、トリガ対内の2つのインスタンスの間でサブセットリンク値がどのように変更したかに対処することが可能である。その対内のサブセットリンクによって識別されたそれぞれのORTエントリーに関して、対を作成して、トリガのリスト内に入力することが可能である。以下の可能性が存在する。Δtに先立って、何の接続値(例えば、外部キー参照を伴うナル値)も存在せず、Δt内のそのような値、すなわち、その対のいずれのインスタンスもORT内のエントリーを実際に参照しない場合、この方法は終了し、何の対もトリガのリストに追加されない。Δtに先立って、接続値が存在したが、Δt内にそのような値がない場合、これは、トリガ対の第1のインスタンスがORTエントリー(例えば、「店舗」表302内の店舗)を参照したが、第2のインスタンスは、いずれのそのようなエントリーも参照しなかったことを意味する。第1のインスタンスによって参照されるORTエントリーを表す対は、次いで、トリガのリスト内にUPDとして入力されるべきである。しかし、識別されたORTエントリーはトリガ対内の最後のインスタンスによって参照されないため、その対は、図5のステップ507と、図7のステップ715の間にDELに変更される可能性が高いことになる。本発明の代替の実施形態では、トリガの間にこれを検証することが可能であり、その対は、DELとして直接的に入力可能である。

【0188】

トリガ対が、Δtに先立って、接続サブセット値を有さなかったが、Δtの間に接続値を有した場合、その接続値によって識別されるORTエントリーを表す対は、トリガのリストに追加されるべきである。この場合も、この対をUPDとして追加して、図7のプロセスの間に、ステップ718において、INSに変更することが可能である。

【0189】

最後に、トリガ対は、1つのORTエントリーを参照する第1のインスタンスと、図3の例の点から、ある店舗から別の店舗への変更を表す、異なるORTエントリーを参照する最後のインスタンスとを含むことが可能である。この場合、トリガ対の第1のインスタンスの接続サブセット値によって参照されるORTエントリーの2つのインスタンスを表す1つの対をトリガのリストに追加し、トリガ対の最後のインスタンスの接続サブセットリンクによって参照されるORTエントリーに関する第2の対を追加しなければならない可能性がある。両方ともトリガのリストにUPDとして追加でき、図7を参照して上で説明された方法によるフィルタリングおよび調整の間に、第1の対をDELに変更することが可能であり、第2の対をINSに変更することが可能である。

【0190】

残りのトリガリング方法は、図6のプロセスがステップ606に進んだときに実行される。このステップでは、トリガする記録の役割に応じて、1つまたは複数の方法を実行することが可能である。説明されることになるこれらの方法の第1は、AddChildren(対)と呼ばれることになる。この方法は、トリガ対の記録タイプが「母」および「子」の役割のうちの少なくとも1つを有する場合、実行される。この方法は、図6のステップ604において、トリガ対がクライアントを更新すべきであることが決定され、ステップ605において、その対が受入れ変更を有することが決定された場合だけ実行される。本発明のいくつかの実施形態では、これらの決定を行う方法は、AddChildren(対)内から呼び出すことが可能であり、代替の実施形態では、ステップ604および605は、ステップ607のトリガリング方法が実行される前に実行される。

【0191】

この方法は、トリガ記録タイプのすべてのサブセットメンバー記録タイプの検査に進む。サブセットメンバー記録タイプは、「メンバー記録タイプ」、またはMRTと呼ばれることになる。RTと呼ばれる、トリガ対の記録タイプに関して「子」であるそれぞれのMRTが識別される。そのRTが「母」または「子」である場合、MRTは「子」である。そのRTに関してユーザ定義された受入れ方法が存在する場合、そのRTは「母」である。そのRTが「母」のサブツリー内にある場合、そのRTは「子」である。

【0192】

RTの「子」であるそれぞれのMRTの場合、そのRTエントリーを参照するエントリー、すなわち、トリガ対を識別するためにログが走査される。この走査プロセスは、受入れの決定の間の「ORTインスタンス」またはMRTインスタンスの作成を議論したときに上で説明されたプロセスに類似する。トリガ対を参照するMRT表内の記録に関するすべてのエントリーを考慮して、ログの端から走査を実行することが可能である。窓Δtの後、その中、またはそれに先立って、適切な候補を見出すことが可能である。見出されたそれぞれの適切なログエントリーに関して、対は、ログ内で見出された適切な値で埋められて、対応する対がトリガのリスト内に既に追加されていない限り、トリガのリストに追加される。この方法は、トリガ対の「子」であると決定されたそれぞれのMRTからのログから確立可能なすべての対を作成する。

【0193】

トリガ対の「子」は、何のログエントリーも有さずに存在できる点を理解されよう。したがって、トリガ対によってインスタンスが作成された記録を参照し、何のログエントリーも有さないエントリーをデータベース内に見出すことが必要である。対応する対がトリガのリスト内に既に存在しない限り、いずれのそのようなデータベースエントリーも、データベースから直接的にフェッチされた値を有する対としてトリガのリストに追加される。すべての「子」が見出されて、トリガのリストに追加されるまで、これはすべてのMRT表に関して繰り返される。

【0194】

トリガ対が「息子」の役割を有することが決定された場合、AddFather(対)と呼ばれるトリガリング方法が実行される。この場合も、この方法に先立って、またはこの方法の一部として、604および605を参照して説明されたステップを実行することが可能である。そのトリガがINSもしくはDELであることが決定された場合、またはそれが受入れ変更を伴うUPDである場合、(1つまたは複数の)「父」がトリガされなければならない。「父」は、「息子」RTのすべてのORTを検査することによってトリガされる。その記録タイプに関して「父」事象が存在する場合、記録タイプは「父」であり、その記録タイプは「母」ではない。すなわち、宣言された「父」事象を有するが、宣言された「母」事象を有さないトリガRTに対するすべてのORAは「父」である。「父」であることが見出される、すべてのサブセットオーナーに関して、「息子」によって参照されるエントリーに関する対が作成される。それぞれの作成された対は、ログから(または、ログエントリーが存在しない場合、データベースから)埋められたインスタンスを含むことが可能である。参照された「父」がある1つのエントリーから別のエントリーに変更されるように「息子」が更新されている場合、参照された「父」の両方をトリガすることが必要な場合がある。

【0195】

一般に、「息子」がΔt内で削除された場合、「父」はΔtの開始に先立って存在しなければならず、「息子」がΔt内に挿入された場合、「父」はΔtの終了時に存在しなければならない。しかし、「父」の発生は、多くの「息子」に代わってクライアントに存在する可能性があるため、制限している「息子」がサーバデータベースから削除されていることが決定され、サーバ側上の処理が、「息子」ならびにその「父」がクライアントから削除されるべきであることを示すとき、クライアントデータベースから「父」を削除することは常に適切であるとは限らない。その理由は、異なる「息子」、例えば、「父」に関して「息子」役割を有する表からの異なる表行は、前の同期の間にクライアントデータベースに追加されている可能性があり、この他の「息子」は、クライアントデータベース内に依然として残り、したがって、クライアント上に「父」の存在を必要とする可能性があるためである。そのような「息子」の存在は、サーバ側で同期を実行するために使用される情報から容易に利用可能ではない。これは、代わりに、「父」対に関するDEL命令をクライアントに転送し、次いで、そのDELが実行可能であるかどうか、またはクライアント上の「父」の継続的な存在を必要とする他の「息子」がクライアント上に存在するかどうかを決定するための点検をクライアント上で実行することによって処理可能である。同様に、新しい「息子」の挿入が「父」の挿入をトリガし、サーバ側の処理が、トリガする「息子」とトリガされた「父」の両方がそのクライアントに転送されるべきであることを示すとき、その「父」は、クライアントの前の同期の結果として、そのクライアント上に既に存在する可能性がある。これは、やはり、クライアント側で処理可能である。本発明の一実施形態によれば、クライアントに対するすべての他の更新は、「父」が更新される前に実行され、必要な「父」が削除されず、「父」が二度挿入されないように、「父」は更新される。

【0196】

トリガ記録タイプが「兄弟」である場合、「姉妹」をトリガすることが必要な場合がある。そのような状況の例は、「品目総額」表306が店舗_製品表304に対する「姉妹」である図3に見出される。「姉妹」のトリガは、AddSisterOfBrother(対)と呼ばれる方法によって実行可能である。この方法は、AddFather方法において上で説明されたのと同じように「兄弟」の「父」を見出す(「兄弟」は、「父」に対する「息子」の役割を有する)。この方法は、次いで、続いて「父」の下のサブツリー内で「姉妹」であるすべての記録タイプを見出す。したがって、上で要約された方法を使用して、「父」の下のサブツリー内のすべての「姉妹」が識別され、その「父」から始まるそれぞれの記録タイプに関して、AddChildrenのプロセスに類似した、トリガプロセスが実行される。これは、ログからまたはデータベースから取り出された、このサブツリー内のすべての記録タイプから参照されて、検査された関連するエントリーが対としてトリガのリスト内に入力されることを意味する。

【0197】

最後に、トリガ対が「父」または「姉妹」である場合、Addsister(対)と呼ばれる方法を実行することが可能である。このAddSister(対)は、間接的な「母」を識別する必要がない点を除いて、方法AddSisterOfBrother(対)に類似する。代わりに、それぞれの「姉妹」(すなわち、トリガ対のRTのそれぞれのMRT)に関して、トリガ対を参照するすべての適切なエントリーが識別されて、ログ内、またはAddChildren(対)に関して説明されたプロセスに類似したプロセス内のデータベース内のいずれかで見出される適切な値を有する対がトリガのリストに追加される。

【0198】

図5を再び参照すると、すべてのトリガが上で説明された方法に従って完了した後で、プロセスは、続いて、ステップ507において既に説明されたように、フィルタリングと調整とを決定して、実際の同期を実行する。

【0199】

その対がクライアントを更新すべきかどうかを決定し、更新すべきである場合、その適切な更新状態は何か、すなわち、更新か、挿入か、または削除かを決定するために、図7を参照して説明された方法に従って対が処理されるとき、記録のすべての値を含むXMLメッセージが作成されて、そのXMLメッセージを受信するクライアントに送信され、データをクライアントデータベース内にインポートするために動作可能な方法によって実行されることが可能である。いくつかの実施形態によれば、サーバは、非同期SOAP呼を使用することが可能である。(SOAP1.2は、その全体が参照により組み込まれているW3Cからの勧告において定義される)。しかし、他の通信プロトコルおよびメッセージング形式も本発明の範囲内である。

【0200】

トリガプロセスを参照して上で述べたように、記録のバッチを一度に処理することによって、または、すべての記録を同時に実行することによって、記録ごとにトリガと更新とを実行することが可能である。したがって、クライアントに送信される同期メッセージは、1つだけの記録を含むことが可能であり、記録のバッチを含むことが可能であり、または挿入、削除、もしくは更新されるべきすべての記録を含むことも可能である。

【符号の説明】

【0201】

101 中央サーバ、データベースサーバ
102 第1のクライアントデバイス、クライアントコンピュータ
103 第2のクライアントコンピュータ
104 第3のクライアントデバイス、ラップトップ、代理人
105 第4のクライアントデバイス、パーソナルコンピュータ
110 ネットワーク
201 配属表
202 表
203 第3の表
204 最終表、製品表
301 オーナー表、店舗オーナー表、店舗オーナー
302 店舗表
303 PDA表
304 店舗_製品表
305 製品表
306 製品総額
307 販売、販売表
308 購入、購入表
400 領域、データベース
410 第1のサブセット
411 変更されていないすべての記録、サブセット
420 第2のサブセット
421 第3のサブセット
430 データベース
431 サブセット
1001 部門
10001 部門
10002 部門

【図1】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図2A】

【図2B】