データベース・アプリケーションには、次の 2 つの基本的なアーキテクチャがあります。

Mobile Link では随時接続スマート・クライアント・アプリケーションを作成できます。スマート・クライアント・アプリケーションにより、アプリケーションの利便性、効率性、スケーラビリティが大幅に向上します。しかし、アプリケーションの開発に関する新しい問題も発生します。このセクションでは、スマート・クライアント・アプリケーションの開発に関する主な問題について説明します。また、Mobile Link 同期環境でソリューションを実装する方法についても説明します。

必要な同期のみを実行

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

まず、各リモート・データベースには統合データベースのテーブルとカラムのサブセットのみが格納されるようにします。たとえば、地域 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 ではグローバル・オートインクリメント方式による解決方法もあります。あるカラムをグローバル・オートインクリメントとして宣言すると、ローの追加時に、これまでのプライマリ・キーの最後の値を増分することにより、プライマリ・キーが自動的に作成されます。この解決方法は、統合データベースが 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) にします。

詳細情報

• 同期の方法