アプリケーション開発の手引き

DB2 アプリケーションの設計

DB2 には、アプリケーションの従来の機能を補足または拡張するためのさまざまなアプリケーション開発機能が備えられています。アプリケーション設計者が決定すべき事柄は、最も基礎的な設計です。つまり、 アプリケーションの設計にどの DB2 機能を使用すればよいのか? ということです。適切な選択を行うためには、アプリケーションのデータベース設計と目標環境の両方を考慮しなければなりません。たとえば、アプリケーションにロジックを組み込む代わりに、業務上の規則の一部をデータベース設計に組み込むことができます。

使用する機能とその範囲は、さまざまに変更できます。この節は、設計に大きな影響を及ぼす使用可能な機能についての概説であり、特定の目的に対してある機能が他の機能よりもふさわしい理由を示しています。この節に記載された機能の詳細については、より詳しい説明を載せた参照用資料が提供されています。

考慮すべき機能には、次のものがあります。

前述のリストには、トリガーなどのように、複数の項目で使用されている機能があります。これは、複数の設計基準に対応するという、これらの機能の柔軟性を反映しています。

最も重要かつ基礎的な決定は、アプリケーションに関連したデータ規則を適用するためのロジックを、データベースに移動させるかどうかです。

データに着目した、ロジックをアプリケーションからデータベースに移すことの重要な利点は、アプリケーションのデータからの独立性が一層高まるということです。データに関連するロジックは、1 箇所 (データベース) に集められます。つまり、データまたはデータ・ロジックの変更を一度に行うことができ、またそれがただちにすべてのアプリケーションに反映されます。

この後者の利点は非常に強力なものですが、データベース内に置かれるデータ・ロジックがデータのユーザーすべてに同じ影響を与えるということに気を付けてください。データに加えられる規則や制約が、そのデータの全ユーザーやアプリケーションのユーザーにも当てはまるかどうかを考慮しなければなりません。

アプリケーションの要件は、データ規則をデータベースで適用するか、アプリケーションで適用するかにも影響を与えます。たとえば、特定の順序でデータが入力されたときに妥当性検査エラーを処理しなければならないことがあります。一般に、これらのタイプのデータの妥当性検査は、アプリケーション・コードで行う必要があります。

アプリケーションを使用するコンピューティング環境も考慮してください。クライアント側のマシンでロジックを実行する場合と、ストアード・プロシージャー、UDF、またはその両方を組み合わせて使用して、通常のより強力なデータベース・サーバー側のマシンでロジックを実行する場合の差について考慮する必要があります。

場合によっては、アプリケーション (アプリケーション固有の理由のため) とデータベース (アプリケーション外の他の対話的な用途のため) の両方を考慮に入れて設計しなければならないということもあります。

データへのアクセス

リレーショナル・データベースでは、データへのアクセスには SQL を使用しなければなりませんが、 SQL をアプリケーションに組み込む方法はユーザーが任意で選択できます。以下のインターフェースおよびサポートされている言語の中から選択してください。

組み込み SQL
C/C++、COBOL、FORTRAN、Java (SQLJ)、REXX

DB2 CLI および ODBC
C/C++、Java (JDBC)

Microsoft 仕様 (ADO、RDO、OLE DB を含む)
Visual Basic、Visual C++

Perl DBI
Perl

照会製品
ロータス アプローチ、IBM 照会管理機能

組み込み SQL

組み込み SQL には、静的 SQL と動的 SQL のいずれも使用でき、この 2 つのタイプを組み合わせて使用することもできるという利点があります。アプリケーションの使用時に SQL ステートメントの内容や形式が柔軟性に乏しい と思われる場合には、アプリケーションで組み込み SQL を使用することを考えてみてください。静的 SQL を使用すると、アプリケーションの実行者は、アプリケーションをデータベースにバインドしたユーザーの特権を一時的に継承することができます。 DYNAMICRULES BIND オプションを指定してアプリケーションをバインドしていない場合は、動的 SQL がアプリケーションの実行者の特権を使用します。一般的には、組み込み動的 SQL を使用してください。これによって実行可能ステートメントは実行時に決定されます。組み込み動的 SQL を使用すると、より安全なアプリケーション・プログラムを作成して、さらに多様な入力を扱うことができます。
注:Java Embedded SQL (SQLJ) アプリケーションは、静的 SQL ステートメントしか組み込むことができません。ただし、JDBC を使用して、SQLJ アプリケーションで動的 SQL 呼び出しを行うことができます。

SQL ステートメントをホスト言語コマンドに変換するには、プログラム言語コンパイラーを使用する前に、組み込み SQL アプリケーションをプリコンパイルする必要があります。さらに、アプリケーションを実行するには、アプリケーション内の SQL をデータベースにバインドする必要もあります。

組み込み SQL の追加情報については、静的 SQL プログラムの作成を参照してください。

REXX に関する考慮事項

REXX アプリケーションは API を使用することにより、データベース・マネージャー API および SQL により提供される機能の大部分を使用できるようになります。コンパイル言語で作成されたアプリケーションとは異なり、 REXX アプリケーションはプリコンパイルされません。その代わりに、動的 SQL ハンドラーがすべての SQL ステートメントを処理します。 REXX と呼び出し可能な API を組み合わせることにより、データベース・マネージャー機能の大部分にアクセスできます。組み込み SQL を使用する API の中には REXX が直接サポートしていないものもありますが、 DB2 コマンド行プロセッサーを使用すれば、 REXX アプリケーションからこれらの API にアクセスできます。

REXX はインタープリター言語なので、コンパイル済みホスト言語に比べてアプリケーションのプロトタイプの開発やデバッグが容易です。 REXX でコーディングされた DB2 アプリケーションは、コンパイル言語を使用した DB2 アプリケーションほどの性能は持ちませんが、プリコンパイル、コンパイル、リンクを行わず、またはさらに別のソフトウェアを使用せずに DB2 アプリケーションを作成する機能を提供できることに注目してください。

REXX を使用した DB2 アプリケーションのコーディングと作成の詳細については、 REXX でのプログラミングを参照してください。

DB2 コール・レベル・インターフェース (DB2 CLI) およびオープン・データベース・コネクティビィティー (ODBC)

DB2 コール・レベル・インターフェース (DB2 CLI) は、データベース・サーバーの DB2 ファミリーに対する、 IBM の呼び出し可能 SQL インターフェースです。また、これはリレーショナル・データベースのアクセスを目的とした、 C および C++ のアプリケーション・プログラム・インターフェースで、関数呼び出しを使用して動的 SQL ステートメントを関数の引き数として受け渡しします。呼び出し可能 SQL インターフェースとは、データベースをアクセスするためのアプリケーション・プログラム・インターフェース (API) で、関数呼び出しを使用して動的 SQL ステートメントを呼び出します。これは組み込み動的 SQL の代替方法ですが、組み込み SQL とは異なり、プリコンパイルやバインドが必要ありません。

DB2 CLI は Microsoft(TM) のオープン・データベース・コネクティビティー (ODBC) 仕様と、 X/Open(R) 仕様に基づいています。業界標準に従うように、およびいずれかのデータベース・インターフェースに精通した DB2 アプリケーション・プログラマーがすぐに覚えられるように、これらの仕様が選択されました。

DB2 での ODBC サポートの詳細については、 コール・レベル・インターフェースの手引きおよび解説書 を参照してください。

JDBC

DB2 の Java サポートには JDBC が含まれます。これは標準化された Java メソッドによるデータ・アクセスをアプリケーションに提供する、ベンダーに依存しない動的 SQL インターフェースです。 JDBC は、JDBC プログラムをプリコンパイルしたりバインドしたりする必要がないという点で、 DB2 CLI に似ています。ベンダーに依存しない標準なので、JDBC アプリケーションは高い移植性を持っています。

JDBC を用いて作成されるアプリケーションは動的 SQL だけです。 JDBC インターフェースを使用すると、処理に余分なオーバーヘッドがかかります。

JDBC の追加情報については、JDBC プログラミングを参照してください。

Microsoft 仕様

ActiveX Data Object (ADO) に準拠したデータベース・アプリケーションは、 Microsoft Visual Basic(TM) または Visual C++(TM) で作成することができます。 ADO アプリケーションは OLE DB ブリッジを使用します。 Remote Data Object (RDO) 仕様に準拠したデータベース・アプリケーションは、 Visual Basic で作成することができます。また、OLE DB Provider からデータを戻す OLE DB 表関数を定義することもできます。 OLE DB 表関数の詳細については、OLE DB 表関数を参照してください。

本書では、ADO および RDO 仕様に準拠したアプリケーションを作成するためのチュートリアルは記載していません。 ADO および RDO 仕様を使用する DB2 アプリケーションの完全なサンプルについては、以下のディレクトリーを参照してください。

Perl DBI

DB2 は、DBD::DB2 ドライバーを介してデータ・アクセスを行うために、 Perl データベース・インターフェース (DBI) 仕様をサポートします。 Perl DBI を使用して DB2 データベースにアクセスするアプリケーションを作成することの詳細については、 Perl でのプログラミングを参照してください。にある

DB2 ユニバーサル・データベース Perl DBI Web サイト には、最新の DBD::DB2 ドライバーと、各プラットフォームで得られるサポートについての情報が記載されています。

照会製品

IBM 照会管理機能 (QMF) およびロータス ノーツを含む照会製品では、照会の開発およびレポート作成をサポートしています。 SQL ステートメントを開発する方法や、導入できるロジックの程度は、製品ごとに異なります。ユーザーの要求によっては、この方法でデータをアクセスするための要件を満たすことができる場合もあります。本書では、照会製品の詳細については記載していません。

データ値の制御

データベースで許可する値を制御することによって妥当性検査とデータ保全性保護を行うことは、アプリケーション・ロジックの従来の機能の 1 つです。アプリケーションには、データが有効であるかどうかを確認するために、入力されたデータ値を特別にチェックするロジックがあります。 (たとえば、部門番号が有効な番号であるかどうかと、それが既存の部門の番号であるかをチェックします。) DB2 にはこれらの同一の機能をデータベース内から提供するための方法がいくつかあります。

データ・タイプ

データベース内の各データ要素は表の列に保管されており、各列はデータ・タイプを持つように定義されています。このデータ・タイプにより、列の値のタイプに制限が設けられます。たとえば、整数は、固定された範囲内の数値でなければなりません。 SQL ステートメント内で列を使用する際には、整数は文字ストリングと比較できないなどの、一定の動作に従わなければなりません。 DB2 には、特性および動作を定義した組み込みデータ・タイプのセットが含まれています。 DB2 は、ユーザー定義特殊タイプ と呼ばれる、ユーザー固有のデータ・タイプの定義もサポートしています。ユーザー定義特殊タイプは組み込みタイプに基づいていますが、組み込みタイプのすべての動作が自動的にサポートされるわけではありません。データ・タイプを 2 進ラージ・オブジェクト (BLOB) と同様に使用して、データ構造など関連する値の集合から成るデータを保管できます。

データ・タイプの追加情報については、 SQL 解説書 を参照してください。

固有制約

固有制約により、表の中の 1 つまたは複数の列で同じ値が重複するのを避けられます。固有制約では、固有キーと基本キーがサポートされています。たとえば、DEPARTMENT 表の DEPTNO 列に固有制約を定義することにより、同じ部門番号が 2 つの部門で指定されないようにすることができます。

表の中のデータを使用するすべてのアプリケーションに固有規則を設ける必要がある場合には、固有制約を使用してください。固有制約の追加情報については、SQL 解説書 を参照してください。

表検査の制約

表検査の制約は、表の列で使用できる値について、データ・タイプによる制限よりもさらに詳しい制限を定義するために使用します。表検査の制約は、範囲の検査という形式と、表の中の同じ列にある他の値の検査という形式で行うことができます。

データを使用するすべてのアプリケーションに対して規則を適用するには、表検査の制約を使用して、表中で使用できるデータを制限することができます。これにより、利用の幅が広がるとともに保守しやすくなります。

表検査の制約の追加情報については、SQL 解説書 を参照してください。

参照保全制約

参照保全 (RI) 制約は、データを使用するすべてのアプリケーションに対して、値ベースの関係を保持しなければならない場合に使用します。たとえば、RI 制約を使用して、 EMPLOYEE 表の DEPTNO 列の値を DEPARTMENT 表の値と一致させることができます。この制約は、挿入、更新、削除が行われないようにします。制約がない場合には DEPARTMENT に関する情報は失われる可能性があります。 RI 規則をデータベースで集中的に適用すると、一般に適用が確実になり保守しやすくなります。

RI 制約の詳しい使用法については、データの関連の制御を参照してください。

参照保全の追加情報に関しては、 SQL 解説書 を参照してください。

CHECK OPTION を使用した視点

アプリケーションの規則で表検査の制約として定義できないものがある場合や、使用するすべてのデータには当てはまらない規則がある場合には、アプリケーションのロジックへの規則の組み込みに代わる方法があります。データの条件を WHERE 文節または WITH CHECK OPTION 文節の一部として指定した、表の視点を作成することができます。この視点定義は、アプリケーションに有効なデータ・セットに対して、検索できるデータを制限します。さらに、視点が更新可能な場合は、 WITH CHECK OPTION 文節がアプリケーションに適用できる行の更新、挿入、および削除を制限します。

WITH CHECK OPTION の追加情報に関しては、 SQL 解説書 を参照してください。

アプリケーションのロジックとプログラム変数のタイプ

あるプログラミング言語でアプリケーションのロジックを作成する際には、変数も宣言すると、上記の説明と同じくデータに対して制限を課することができます。さらに、データベースではなくアプリケーションでの規則を適用させるコードの記述を選択できます。以下のような場合に、アプリケーション・サーバーにロジックを組み込んでください。

たとえば、データが入力される順序について入力データのエラーを処理する必要があり、データベース内の操作の順序では正しく検査できない、という場合があります。

データの関連の制御

アプリケーションのロジックのもう 1 つの主な機能は、システム内の異なる論理エンティティー間の関連の管理です。たとえば、新しい部門を追加する場合には、新しい顧客コードを追加する必要があります。 DB2 は、データベース内の異なるオブジェクト間の関連を管理するために、参照保全制約とトリガーという 2 つの方法を備えています。

参照保全制約

データの関連の制御という点から考えた場合、参照保全 (RI) 制約を使用すると、複数の表のデータ間の関連を制御できるようになります。関連付けられた基本キーに影響を与える操作の振る舞い (DELETE や UPDATE など) について定義するには、 CREATE TABLE または ALTER TABLE ステートメントを使用してください。

RI 制約は、1 つまたは複数の表に対してデータの規則を適用します。データを使用するアプリケーションすべてにその規則が当てはまる場合には、 RI 制約の使用により規則がデータベース内に集められます。これにより、利用の幅が広がるとともに保守しやすくなります。

参照保全の追加情報に関しては、 SQL 解説書 を参照してください。

トリガー

アプリケーションでも実行できるロジックをサポートするために、更新前または更新後にトリガーを使用することができます。トリガーがサポートする規則や操作が、データを使用するすべてのアプリケーションに当てはまる場合は、トリガーの使用により規則や操作がデータベースに集中し、データベースは利用の幅が広がるとともに保守しやすくなります。

トリガーの追加情報については、活動状態の DBMS でのトリガーの使用または SQL 解説書 を参照してください。

更新前のトリガーの使用

更新または挿入の前に実行されるトリガーを使用すると、修正中または挿入中の値を、データベースが実際に修正される前に修正することができます。これは、アプリケーションからの入力 (ユーザーから見たデータ) を希望の内部データベース形式に変換するために使用できます。また、ユーザー定義の関数を介して他の非データベース操作を活動化させる際にも、 事前トリガー を使用することができます。

更新後のトリガーの使用

更新、挿入、削除の後に実行されるトリガーには、いくつかの使用法があります。

アプリケーションのロジック

データベースではなくアプリケーションで規則を適用させたり、または関連操作を実行させるコードを作成することができます。これは、その規則がデータベースに一般的に適用されるものではない場合に行ってください。データベース内のデータ定義全体に対する制御ができない場合や、アプリケーションのロジックで規則や操作を取り扱うほうがより効果的であると思われる場合にも、ロジックをアプリケーション内に置くことができます。

サーバーにおけるアプリケーションのロジック

DB2 が追加機能を提供しているアプリケーション設計の最終段階は、アプリケーションのロジックの一部をデータベース・サーバーで実行するというものです。通常、この設計はパフォーマンスを向上させるために使用しますが、共通機能をサポートするためにサーバー側でアプリケーションのロジックを実行することもできます。

ストアード・プロシージャー

ストアード・プロシージャーはアプリケーションのルーチンで、クライアントのアプリケーションのロジックから呼び出されますが、データベース・サーバーで実行されます。ストアード・プロシージャーを使用する最も一般的な理由は、結果のデータが少量で済むデータベース集中処理を行うためです。これにより、ストアード・プロシージャーの実行中のネットワーク間の通信量を大幅に減らすことができます。また、複数のアプリケーションで共通の操作の集合に対して、ストアード・プロシージャーを使用することもできます。この方法では、すべてのアプリケーションが同じロジックを使用して操作を実行します。

ストアード・プロシージャーの追加情報については、 ストアード・プロシージャーを参照してください。

ユーザー定義関数

ユーザー定義関数 (UDF) は、以下のものを戻す SQL ステートメント内での操作に使用するために作成することができます。

UDF には SQL ステートメントを含めることはできません。 UDF は、データ値の変換、1 つまたは複数のデータ値に対する計算の実行、値の部分的な抽出 (ラージ・オブジェクトの部分的な抽出) などに役立ちます。

ユーザー定義関数の定義の追加情報については、 ユーザー定義関数 (UDF) とメソッドの作成を参照してください。

トリガー

トリガーでは、トリガーはユーザー定義関数の呼び出しに使用できると記載されています。これは、特定のステートメントが現れたとき、またはデータ値が変更されたときには必ず一定の非 SQL 操作が行われるようにしたいという場合に役立ちます。特定の状況において電子メールを出したり、ファイルにアラート・タイプの情報を書き込むなどの操作が例に示されています。

トリガーの追加情報については、 活動状態の DBMS でのトリガーの使用を参照してください。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]