この章の内容は次のとおりです。
分散環境は、次のように様々なアプリケーションで使用されます。
地理的に様々な場所でデータが生成され、ほとんどの時間、そのデータがローカルで使用可能である必要があるアプリケーション。
特定のサイトまたはハードウェア障害による影響を低減するために、データおよびソフトウェアの処理が分散されるアプリケーション。
リレーショナル・データベース管理システム(RDBMS)によって、ユーザーには単一の論理的なデータ表示を提供しながら、データを分散できる場合、位置の透過性がサポートされます。位置の透過性によって、データの実際の物理的な位置を知る必要がなくなります。このため、アプリケーション開発が容易になります。データベース管理者(DBA)は、アプリケーションの必要性に応じて、関連データの位置を隠すことができます。
リモート・オブジェクトにアクセスするには、ローカル・サーバーが、そのリモート・サーバーとの接続を確立する必要があります。各サーバーには、そのリモート・サーバーに対して一意の名前が必要です。リモート・サーバーとの接続を確立するために使用されるメソッド、およびリモート・オブジェクトのネーミング規則は、データベースによって異なります。
Oracleでは、グローバル・オブジェクト名を使用することによって、分散データベース全体のリモート・オブジェクト(表、ビュー、プロシージャなど)をSQL文で参照できます。 Oracleでのグローバル・スキーマ・オブジェクト名には、オブジェクトを含むスキーマ名、次にオブジェクト名、アットマーク(@)が続き、その後にデータベース名を付けます。たとえば、次の問合せは、リモート・サーバーに格納されているSALESデータベースのscott.empという名前の表から情報を選択します。
SELECT * FROM scott.emp@sales.division3.acme.com
分散データベース・システムは、システム内の各データベースが一意のデータベース名を持つように構成でき、それによって効果的なグローバル・オブジェクト名を提供されます。
さらに、リモート・オブジェクト名に対してシノニムを定義することによって、リモート・データベースの名前を参照する必要性がなくなります。シノニムは、リモート・データベース・オブジェクトを参照する、ローカル・データベース内のオブジェクトです。シノニムによって、アプリケーション開発者ではなくDBAの責任でデータを分散することができます。DBAは、シノニムを使用することによって、アプリケーションに影響を与えることなく必要なときにオブジェクトを移動できます。
シノニムは、次のようにして定義できます。
CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.division3.acme.com;
このシノニムを使用することにより、前述のSQL文を次のように変更できます。
SELECT * FROM emp;
Microsoft SQL Serverでは、分散データベース内のスキーマ・オブジェクトが、完全修飾されたオブジェクト名によってSQL文内で参照される必要があります。スキーマ・オブジェクト名は次のとおりです。
server_name.database_name.object_owner_name.object_name
server_name
は、リモート・サーバーの名前です。 database_name
は、リモート・サーバー上のリモート・データベースの名前です。
Microsoft SQL Serverは、シノニムの概念や位置の透過性をサポートしていません。分散環境では、開発者がオブジェクトの位置をアプリケーション・コードに含める必要があるため、オブジェクトを移動するとアプリケーションに影響します。
ほぼすべての静的問合せには、リモート・サーバーおよびリモート・データベースへの参照を含める傾向があります。一部のアプリケーションではユーザー表を保持して、完全なオブジェクト名(リモート・サーバー名およびデータベース名を含む)をダミーのオブジェクト名にマップします。問合せは、このようなダミーのオブジェクト名を参照します。変換は、ユーザー表でのマップを使用して、リアルタイムで実行されます。 この制限によって、OracleとMicrosoft SQL Serverで動作できるリモート・オブジェクトへのすべての一般的な参照方法が使用できなくなります。
Microsoft SQL ServerのOmni SQL Gatewayサーバーでは、位置の透過性がサポートされていますが、これには、分散環境に関連するすべてのデータベースのスキーマ定義がOmni SQL Gatewayサーバーで使用可能である必要があります。
Microsoft SQL Serverのレプリケーション機能には、次の特性があります。
一方向
トランザクション・ベースではなく表ベース
自動競合解消がない(手動で解消する必要がある)
Open Database Connectivity(ODBC)を介した異機種間のレプリケーション
前述した特性に加えて、Microsoft SQL Server 7.0のレプリケーションは、ODBCによる異機種間レプリケーションを提供します。
Oracleレプリケーションには、次に示す豊富なレプリケーション機能があります。
双方向
すべてのデータベース・オブジェクトがレプリケート可能
自動再同期化
自動競合解消
ゲートウェイを介した異機種間レプリケーション
Oracle分散環境およびレプリケーションは、Microsoft SQL Serverのスーパーセットをサポートするため、分散アプリケーションを、Microsoft SQL ServerからOracleへ変換できます。
現在使用可能ないくつかのアプリケーション開発ツールは、いずれかのデータベース・サーバーの特定の機能を使用します。そのため、このような製品を別のデータベース・サーバーに移植することが、非常に困難な場合があります。クリティカルなアプリケーションでは、ODBCサポートは適していないため、基礎となるデータベースと最適に動作する別のアプリケーション開発ツールを開発してメンテナンスすることが最適である場合があります。
Microsoft SQL Serverアプリケーションの多くは、ODBCアプリケーション・プログラミング・インタフェース(API)またはVisual Basicで記述されています。 DB-Libraryは、バックエンドにMicrosoft SQL Serverを使用する3GLアプリケーションの開発に広く使用されています。
Oracleでは、ODBCの接続性が提供されているため、Oracleバックエンドで動作するようにODBCベースのMicrosoft SQL Serverアプリケーションを変換できます。
Visual Basicアプリケーションが、Microsoft SQL Serverにアクセスする接続プロトコルとしてODBCを使用して記述されている場合は、そのVisual BasicアプリケーションがOracleバックエンドで動作するように変更できます。
多くのVisual Basicアプリケーションは、Visual Basic用のDB-LibraryであるVB-SQLを使用しています。 VB-SQLによって、Visual BasicプログラムからMicrosoft SQL Serverへネイティブに(ODBCを使用しないで)アクセスできます。そのようなアプリケーションは、VB-SQLデータベース・アクセス・ルーチンを、Oracle Objects for OLEに変更すると、Oracleバックエンドで動作するように変換することもできます。
Oracleには、Oracle Call Interface(OCI)と呼ばれるコール・インタフェースが用意されています。これには、DB-Library APIと同等の機能があります。DB-LibraryアプリケーションからOCIアプリケーションへ変換できます。