店舗販売時点管理 (POS) アプリケーション
店舗販売時点管理 (POS) アプリケーションには、販売時に消費者が直接または間接的に接するアプリケーションが含まれます。たとえば、レジ係が使用する端末、ATM 機、店舗内キオスク端末などがこれに該当します。これらのアプリケーションは、リモート サイトのデータを収集し、本部やデータ センターなどの集中管理場所にデータを返送します。これらのアプリケーションでは、単一のリモート ユーザー (通常は顧客や販売員) が所定のデータを更新するため、データは主に販売時点で収集され、その後競合を起こさずに本部にアップロードされるのが一般的です。
次の図は、集中管理場所とリモートの場所との間で双方向にデータ フローが発生する一般的なシナリオを示しています。
.gif "店舗から本社へのデータのレプリケーション")
Adventure Works Cycles の例
Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。詳細については、「AdventureWorks サンプル データベース」を参照してください。
Adventure Works Cycles 製品を販売する多くの小売店では、中央サイトとの間でデータの送受信を行う POS システムを使用しています。一般的に、読み取り専用の製品価格データおよび在庫データが更新されると、必ずこれらのデータが小売店に送信されます。顧客の購買情報は各小売店から中央サイトに送信されます。
このシナリオの一般的な要件
POS アプリケーションには一般的に以下のような特性があり、適切なレプリケーション ソリューションで対処する必要があります。
ほとんどのデータはリモート サイトで入力および更新されます。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
リモート サイトで更新されたデータは、他のサイトでは更新されません。したがって、通常は競合は起こりません。
製品の説明テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
ユーザーはスケジュールされた時刻 (一日の営業時間の終わりなど) にデータを同期します。
アプリケーションは、リモート サイトが非同期の状態でいられる期間を制御します。
各店舗が 1 つ以上のテーブルに対して異なるデータを受信できるように、一部のテーブルではフィルタ選択が必要です。たとえば、各店舗は在庫製品の情報のみを受信します。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
専用接続ではなくインターネットを経由したデータの同期が必要になる場合があります。
次の図は、このシナリオに関連するフィルタ選択を示しています。
.gif "店舗販売時点管理 (POS) アプリケーションのフィルタ選択")
このシナリオで使用するレプリケーションのタイプ
MicrosoftSQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ (出版社)、サブスクライバ (購読者)、パブリケーション (出版物) とアーティクル (記事)、およびサブスクリプション (定期購読物) があります。上記の図では、中央サイトがパブリッシャです。中央サイトのデータはパブリケーションで、各データ テーブルはアーティクルです (アーティクルはストアド プロシージャなどの他のデータベース オブジェクトの場合もあります)。各 POS 端末はパブリケーションのサブスクライバで、サブスクリプションとしてスキーマとデータを受信します。システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。
SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオはマージ レプリケーションによる実装が最適で、前のセクションで概説した要件によく適合します。マージ レプリケーションの詳細については、「マージ レプリケーションの概要」および「マージ レプリケーションの動作方法」を参照してください。
このシナリオに関連するマージ レプリケーションのオプション
マージ レプリケーションでは、このトピックで先に説明した要件に対応するための、いくつかのオプションが用意されています。次に、各要件とそれに対応するマージ レプリケーション オプションの一覧を示します。
ほとんどのデータはリモート サイトで入力および更新されます。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
リモート サイトで更新されたデータは、他のサイトでは更新されません。したがって、通常は競合は起こりません。
POS アプリケーションでは、単一のユーザーが所定のデータを更新するため、多くの場合、競合は起こりません。ユーザー間でデータが重なることはないため、重複しないパーティションのオプションを指定してパフォーマンスを最適化することができます。詳細については、トピック「パラメータ化された行フィルタ」の「[パーティションのオプション] の設定」を参照してください。
マージ レプリケーションは、データの競合が予測される場合には競合の検出と解決策を提供します。詳細については、「マージ レプリケーションの競合の検出と解決」を参照してください。
製品の価格テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
マージ レプリケーションでは、パブリッシャでのみ更新されるテーブルのダウンロード専用アーティクルが提供されます。詳細については、「ダウンロード専用アーティクルを使用したマージ レプリケーションのパフォーマンス最適化」を参照してください。
ユーザーは、スケジュールされた時刻以外に、要求時にデータを同期する必要があります。
レプリケーションでは、プッシュ サブスクリプションとプル サブスクリプションの 2 種類のサブスクリプションを使用できます。要求時の同期処理には、プル サブスクリプションの方が適しています。サブスクリプションの種類および同期処理のスケジュールの詳細については、「パブリケーションのサブスクライブ」および「データの同期」を参照してください。
アプリケーションは、リモート サイトが非同期の状態でいられる期間を制御します。
マージ レプリケーションでは、すべてのサブスクライバが特定の期間内に同期されるように、サブスクリプションの有効期限を設定できます。詳細については、「サブスクリプションの有効期限と非アクティブ化」を参照してください。
各ユーザーが 1 つ以上のテーブルに対して異なるデータを受信できるように、ほとんどのテーブルではフィルタ選択が必要です。
マージ レプリケーションでは、列と行をフィルタ選択することができます。行フィルタには静的なものと、パラメータ化されたものがあります。静的フィルタは、パブリケーションの作成時にのみ適用されます。1 つのデータセットが生成されます。パラメータ化されたフィルタは、サブスクライバが同期されるたびに適用されます。各サブスクライバごとに別々のデータセットが生成されます。POS アプリケーションでは、多くの場合にパラメータ化されたフィルタが使用されますが、静的フィルタも使用できます。詳細については、「マージ レプリケーション用にパブリッシュされたデータのフィルタ選択」を参照してください。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
マージ レプリケーションでは、同期時に実行されるコードを指定することができます。このコードは多種多様なイベントに対応し、同期対象のデータにアクセスできます。詳細については、「マージ同期中のビジネス ロジックの実行」を参照してください。
専用接続ではなくインターネットを経由したデータの同期が必要になる場合があります。
SQL Server Compact 3.5 SP1 を使用する場合、データは HTTP 接続または HTTPS 接続を経由して同期されます。SQL Server の他のエディションでは、Web 同期が利用できます。この場合は HTTPS が必要です。詳細については、「マージ レプリケーションの Web 同期」を参照してください。
このシナリオの実装手順
このシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。各手順の詳細については、以下のリンクをクリックしてください。
サブスクリプションの初期化が終わり、パブリッシャとサブスクライバ間でデータ フローが発生したら、共通の管理および監視作業の詳細について以下のトピックを参照してください。