分散リレーショナル・データベースの設計には、アプリケーション、ネットワークの考慮事項、およびデー タの考慮事項に関する選択が伴います。
ヒント: 分散リレーショナル・データベース・アプリケーションの設計:
分散リレーショナル・データベース・アプリケーションと、ローカル・データベースだけに使用するために 開発されたアプリケーションとは、要件に大きな違いがあります。
このような差異について適切に計画するためには、次の考慮事項を念頭に置いてアプリケーションを設計し てください。
v 使用できる場合には、分散作業単位 (DUW) 機能を利用してください。
v 共通インターフェースを使用してプログラムをコーディングしてください。
v 複雑なアプリケーションは、それを細かく部分に分割し、分割した各部分をそれぞれの処理に最も適し たロケーションに置くことを考慮します。処理するデータが入っているリモート・ロケーションで、ス トアード・プロシージャーを実行するために SQL CALL ステートメントを使用するのは、アプリケー ションで分散処理を行う 1 つのよい方法です。このストアード・プロシージャーは、DB2 for i アプリ ケーション・サーバーで実行するときは、 SQL 操作である必要はありません。統合データベース入出力 を使用してもよく、別のタイプの処理を実行することもできます。
v 初期のデータベース・アプリケーションの準備、テスト、および使用の方法を研究してください。
v 可能であれば、SQL セット処理機能を活用してください。これによって、アプリケーション・サーバー との通信が最小限になります。たとえば、この処理が可能な場合、1 つの SQL ステートメントによっ て、複数の行を更新することができます。
v プログラムの準備時にリモート作業単位 (RUW) 接続方式を使用している場合、または分散アプリケー ションの他のノードが DUW をサポートしていない場合は、 1 作業単位内のデータベース更新は、単一 の場所で行わなければならないことに注意してください。
v DUW 接続方式では、1 つのステートメントを複数のリレーショナル・データベースに送るのに制約があ ることを忘れてはなりません。
v 接続管理方式の選択によって、パフォーマンスは影響を受けます。異なるリモート・リレーショナル・
データベースを切り替えながら使用する必要がない場合は、 RUW 接続管理方式を使用するのがよいと 思われます。これは、DUW 接続管理で使用される 2 フェーズ・コミットでは、負担が大きくなるから です。
ただし、複数のリモート・データベース管理システム間を頻繁に切り換える必要がある場合は、 DUW 接続管理を使用してください。 DUW 接続管理を使用して実行しているときは、あるデータベース管理 システムとの通信会話は、もう 1 つのデータベース管理システムに接続を切り換えるときに、終了させ る必要がありません。同種環境では、これは異環境ほど大きな影響はありません。同種環境での会話 は、デフォルトの DDMCNV(*KEEP) ジョブ定義属性を使用することによって、活動状態のままにして おくことができるからです。ただし、同種環境でも、新しい接続を設定するために、カーソルをクロー ズし通信フローを送信するコストを除くために、 DUW を使用してパフォーマンスを上げることができ ます。
v 接続管理方式は、CONNECT ステートメントの働きを決定します。 RUW 接続管理方式では、
CONNECT ステートメントは、リレーショナル・データベースへの新しい接続を設定する前に、既存の
接続があればそれらを終了させます。DUW 接続管理方式では、CONNECT ステートメントは、既存の 接続を終了させません。
分散リレーショナル・データベースのネットワークの考慮事項:
ネットワークの設計は、分散リレーショナル・データベースのパフォーマンスに直接影響します。
特定のネットワークで十分に機能する分散リレーショナル・データベースを適切に設計するには、以下のこ とを行います。
v アプリケーションのパフォーマンスにとって回線速度が非常に重要になることがあるので、ネットワー ク内の適切な個所に十分な容量を用意して、主な分散リレーショナル・データベース・アプリケーショ ンに効率的なパフォーマンスが達成できるようにしてください。
v 使用可能な通信ハードウェアおよびソフトウェアを評価し、必要に応じて、上位移行能力も評価を行っ てください。
v 拡張プログラム間通信 (APPC) 接続の場合、ネットワークの定義時に指定するセッション限界および会 話限界を考慮してください。
v 必要とされる (テスト環境および実稼働環境の両方で) ハードウェア、ソフトウェア、および通信機器、
ならびに分散リレーショナル・データベース・ネットワークの機器の最も優れた構成を識別してくださ い。
v TCP/IP をサポートするために必要なスキルは、 APPC をサポートするために必要なスキルとは異なっ ていることを考慮してください。
v エンド・ユーザー・グループとの間の初期サービス・レベルに関する同意 (所定の分散リレーショナル・
データベース・アプリケーションの場合に予測される応答時間など)、ならびに提供される実際のサービ スの監視および調整についての方針を考慮に入れてください。
v 現在のスレッドで補助記憶域プール (ASP) グループに設定されているアプリケーション・リクエスター (AR) からデータベースにアクセスする際に、 APPC 保護 DUW 会話は使用できないことを理解してい なければなりません。
v 分散リレーショナル・データベースのデータベース・オブジェクト、および分散リレーショナル・デー タベースの各ロケーションでの命名についての方針を決めてください。 ロケーションとは、分散リレー ショナル・データベースに関与するリレーショナル・データベース管理システムの相互接続ネットワー クの中にある、特定のリレーショナル・データベース管理システムのことです。この意味でのロケーシ ョンは、独立 ASP グループで構成されたシステム内のユーザー・データベースを指すこともあります。
この方針を作成するにあたっては、次の項目を考慮してください。
– 分散データベースのオブジェクトの完全修飾名には 3 つ (2 つではなく) の部分があり、最上位の修 飾子でオブジェクトのロケーションを識別します。
– 分散リレーショナル・データベースの各ロケーションには、それぞれ固有の識別名を与えてくださ い。データベースの各オブジェクトにも、それぞれ固有の識別名が必要です。識別名が重複している と、重大な問題を生じることがあります。たとえば、ロケーション名およびオブジェクト名が重複し ていると、アプリケーションが意図したもの以外のリモート・データベースに接続される場合があ り、しかもいったん接続された場合には、意図したもの以外のオブジェクトにアクセスすることにな ります。ネットワークの結合時には、命名に特別の注意を払ってください。
– また、ユーザー・データベースでの各ロケーションには、固有の識別名を与えなければなりません。
PAYROLL という名前のユーザー・データベースが 2 つのそれぞれ別個のシステムにある場合、アプ
リケーションが同じシステムからそれらの両方にアクセスしなければならないときに、名前に関する 競合が発生します。独立 ASP 装置を構成するときに、ユーザーはその ASP 装置自体の名前とは異な る RDB 名をその装置に指定できます。これが、 ASP グループ内で基本装置に関連付けられている RDB 名であり、これによって、そのユーザー・データベースは認識されます。
関連概念:
通信管理 (PDF)
分散リレーショナル・データベースのデータの考慮事項:
データを必要とするアプリケーションとの関連におけるデータの配置は、分散リレーショナル・データベー スの設計時の重要な考慮事項になります。
配置に関する決定にあたっては、次の項目を考慮してください。
v アプリケーションで必要とするパフォーマンスのレベル。
v ロケーション間でのデータのセキュリティー、現行性、整合性、および可用性に関する要件。
v 必要とされるデータの量およびデータ・アクセスの予測パターン。
v 必要とされる分散リレーショナル・データベース機能が使用可能であるかどうか。
v システムをサポートするのに必要な技能と実際に使用可能な技能。
v 誰がデータを「所有」しているのか、つまり、誰がデータの正確度の維持管理を担当しているのか。
v システム間セキュリティー、会計、監視と調整、問題処理、データのバックアップと回復、および変更 制御に関する管理方針。
v データをネットワーク内のどこに置くか、維持管理するデータのコピーは 1 つにするか複数にするかな ど、分散データベース設計に関する決定事項。