大部分のアプリケーションでは、リモートデバイスのデータを一部だけでも更新する場合に毎回統合データベース全体をダウンロードすると、大変なことになります。必要な時間と帯域が膨大なものとなり、システム全体の動作が停止してしまいます。各ユーザにとって必要なアップロードとダウンロードのみを行うようにするための方法は複数あります。

まず、各リモートデータベースには統合データベースのテーブルとカラムのサブセットのみが格納されるようにします。たとえば、地域 A の販売担当者が必要とするテーブルやカラムは地域 B の販売担当者や管理職とは異なる場合があります。

リモートデータベースで作成したテーブルやカラムのうち、同期が必要なものだけを同期対象として指定します。Mobile Link アプリケーションでは、データ型が一致していれば、名前が異なっていてもテーブルやカラムをマッピングすることができます。デフォルトではデータのアップロードとダウンロードの両方が可能ですが、Mobile Link では特定のカラムをアップロード専用またはダウンロード専用にすることもできます。

同期時には、各ユーザに関連するリモートデータベースにのみローをダウンロードするようにします。ダウンロードをリモートデータベース別、ユーザ別、またはその他の基準別に分割して行うこともできます。たとえば、地域 A の販売担当者が地域 A のデータのみを更新する必要がある場合を考えてみます。

更新する必要があるのは変更があるデータのみです。Mobile Link アプリケーションでは、アップロードはトランザクションログに基づいて行われるため、デフォルトではリモートデータベースで変更されているデータのみがアップロードされます。ダウンロードも同様に行うには、同期形式をタイムスタンプベースに指定して、データが正常にダウンロードされた日時をシステムが記録するようにします。これにより、データのダウンロードはその日時以降に変更があった場合に限られます。

また、高優先度同期方式の実装が必要になる場合もあります。緊急のデータは更新頻度が高くなるようスケジュールし、緊急でないデータは夜間やデバイスがクレードルにある間に更新するようスケジュールします。高優先度同期を実装するには、それぞれ異なる時刻に実行するようスケジュールされた複数のパブリケーションを作成します。

この他に、プッシュ同期により、必要に応じてデータを効果的にリモートデバイスにプッシュダウンすることもできます。たとえば、トラック運送会社の配送係が交通の混乱を知らされた場合に、該当地域に向かっているトラック運転手の更新情報をダウンロードできます。Mobile Link では、これをサーバ起動同期と呼んでいます。

倉庫を例にとって考えてみます。各従業員はモバイルデバイスを保有しており、箱の搬入出時に在庫情報を更新します。最初に 100 個の箱が搬入されています。そのため各従業員のリモートデータベースと統合データベースには 100 と登録されています。デービッドが 20 個の箱を搬出しました。彼は自分のデータベースを更新して同期します。これで彼のデータベースと統合データベースの両方に 80 と登録されます。次にスーザンが 10 個の箱を搬出します。ここでスーザンは自分のデータベースを更新して同期しようとしますが、スーザンのアプリケーションは統合データベースに登録されている箱の個数が 80 ではなく 100 であると想定しています。このため、アップロードの競合が発生します。

この倉庫アプリケーションの例では、この問題を解決するには、「デービッドによる更新値 - (最初の値 - スーザンによる更新値) = 正しい値」となるように、次のような競合解決論理を作成する必要があります。

80 - (100 - 90) = 70

この競合解決論理は倉庫などの在庫ベースのアプリケーションでは有効ですが、すべてのビジネスアプリケーションで適しているわけではありません。Mobile Link では、次の競合解決論理を定義できます。

場合によっては、アップロードの競合が発生しないようにシステムを設計することができます。重複を避けるためにデータがリモートで分割されている場合は、競合を回避できる可能性があります。それでも競合が発生する場合は、競合の検出と解決を行うためのプログラムを作成する必要があります。

データをアップロードし、アップロードの競合を検出して、削除されたローを統合データベースで同期するには、データベースシステム内で同期されているすべてのテーブルにユニークなプライマリキーが必要です。各ローには、データベース内だけでなく、データベースシステム全体でユニークなプライマリキーが必要です。プライマリキーは更新できないようにする必要があります。

Mobile Link では、ユニークなプライマリキーを設定するための方法が複数あります。方法の 1 つとして、プライマリキーのデータ型を GUID に設定することがあげられます。GUID (グローバルユニーク識別子) は 16 バイトの 16 進数です。Mobile Link の NEWID 関数を使用すると、新しいローに対して自動的に GUID を作成できます。

また、別の解決方法として、複合キーを使用することがあげられます。Mobile Link では各リモートデータベースにリモート ID と呼ばれるユニークな値が設定されています。リモート ID と通常のプライマリキー (順序数など) を組み合わせたものをプライマリキーとして使用することができます。

SQL Anywhere ではグローバルオートインクリメント方式による解決方法もあります。あるカラムを GLOBAL AUTOINCREMENT として宣言すると、ローの追加時に、これまでのプライマリキーの最後の値を増分することにより、プライマリキーが自動的に作成されます。この解決方法は、統合データベースが SQL Anywhere の場合に最適です。

最後に、リモートデータベースに配布されるプライマリキー値のプールを作成することもできます。

同期ソリューションの開発時における各種の決定と同様に、どのプライマリキー方式を選択するかは、統合データベースとリモートデータベースに対する制御のレベルによって異なります。多くの場合、リモートデータベースは管理なしで動作できる必要があります。また、統合データベースのスキーマを変更することが困難な場合もあります。さらに、統合データベースとして RDBMS を選択した場合、すべての RDBMS ですべての機能がサポートされているわけではないため、使用できるオプションが限られることがあります。

同期方式に関する別の問題として、統合データベースから削除されたローの処理があげられます。たとえば、統合データベースからあるローを削除したとします。次にデービッドが自分のリモートデータベースを同期すると、この削除データがダウンロードされ、デービッドのデータベースからローが削除されます。しかし統合データベースでこの後どうすればよいでしょうか。実際にはスーザンに対しても削除データのダウンロードが必要になるため、ローを削除できません。

ダウンロード削除を処理する方法は 2 通りあります。1 つ目の方法は、ローが削除されているかどうかを示すステータスカラムを各テーブルに追加することです。この場合、ローは実際には削除されず、削除するようマークが付けられるだけです。削除するようマーク付けされたローは、後ですべてのリモートデータベースが更新されていることを確認できた時点で消去できます。また、各テーブルのシャドウテーブルを作成することもできます。シャドウテーブルには、削除されたローのプライマリキーの値が格納されています。ローを削除すると、トリガによりシャドウテーブルに値が入力されます。シャドウテーブルの値により、リモートデータベースで削除するローが決定されます。

同期データベースシステムでは、コミットされたデータベーストランザクションのみが同期されます。さらに、同期するデータが関わっている、コミットされたすべてのトランザクションを同期する必要があります。この処理が正しく行われないと、エラーが発生します。これは Mobile Link でのデフォルトの動作です。

また、統合データベースへの接続の独立性レベルも考慮する必要があります。データの一貫性を確保できる範囲で最高のパフォーマンスを実現できる独立性レベルを使用する必要があります。通常、独立性レベル 0 (READ UNCOMMITTED) は同期には不適切で、データの不整合を引き起こす可能性があります。

デフォルトでは、Mobile Link はアップロードには独立性レベル SQL_TXN_READ_COMMITTED を使用し、可能な場合には、ダウンロードにはスナップショットアイソレーションを使用します (不可能な場合には、SQL_TXN_READ_COMMITTED を使用します)。スナップショットアイソレーションは、トランザクションが統合データベースで閉じられるまでダウンロードがブロックされる問題を解消します。ただし、すべての RDBMS がこの機能をサポートしているわけではありません。

毎年、夏時間から通常時間への移行時にデータベースの同期に関する問題が発生する可能性があります。秋に時刻が 1 時間戻ると、午前 2 時が午前 1 時になります。午前 1 時と午前 2 時の間に同期を実行しようとすると、同期のタイムスタンプが、たとえば移行前の午前 1 時 15 分なのか、移行後の午前 1 時 15 分なのかわからなくなります。

この問題を解決するには、秋になり時間が移行するときに、1 時間の間シャットダウンするか、統合データベースサーバを協定世界時 (UTC) にします。

• 同期の方法