データ・カートリッジ作成の概要

2 データ・カートリッジ作成の概要

プロセスのステップ間の関係や依存性など、データ・カートリッジ開発プロセスに関する推奨事項について説明します。

2.1 データ・カートリッジ開発プロセス

データ・カートリッジ開発プロセスを理解するために、プロジェクト全体を考えてみます。

目的の把握

データ・カートリッジ開発の最初のステップは、カートリッジの新機能を明確に定義し、提供予定のドメイン固有の値を設定することです。カートリッジでユーザーに公開するオブジェクトを指定します。

対象ユーザーの把握

カートリッジの対象ユーザーがソフトウェア開発者の場合は、カートリッジの拡張性が最重要課題の1つになります。エンド・ユーザーの場合は、意図したドメインにあわせてカートリッジをできるかぎり調整する必要があります。カートリッジの設計には、ユーザー全員が明確に理解しているビジネス・モデルを反映させてください。カートリッジのサイズに関係なく、開発チームはオブジェクト・リレーショナル・データベース管理システムを細部に至るまで理解し、その知識をカートリッジのドメインの問題に応用する必要があります。

プロジェクトの計画

適切に定義されたソフトウェア開発プロセスを使用し、期待される成果を明確に識別し、データ・カートリッジ開発の妥当な中間目標を設定します。適切なプロジェクト期間をスケジュールし、使用可能なリソースのスキルを具体的に把握することで、プロジェクトを成功に近づけることができます。

プロジェクトの実装

データ・カートリッジ開発のこのフェーズについては、プロジェクトの実装で詳しく説明します。

テストとインストール

最終ステップは、アプリケーションをテストして必要なインストール・スクリプトを作成することです。

2.1.1 プロジェクトの実装

オブジェクトを選択して設計する際には、その名前とセマンティクスが開発者とエンド・ユーザーにとって理解しやすい明確なものであることを確認します。
オブジェクトのコレクションを定義する際には、オブジェクト・メソッドのSQL側とアプリケーション開発で使用されるプログラミング言語とのインタフェースを考慮します。このインタフェースはできるかぎり単純にしておきます。そのために、ライブラリ・ルーチンをコールするメソッドの数を制限し、低レベルのライブラリ・エントリ・ポイントへの多数のコールを回避し、プリフェッチ済データを処理する大きなコード・ブロックを記述します。
インタフェースを定義したら、図2-1に示すパラレル・パスに沿って作業を進めます。使用可能なリソースに応じて適切な順序で作業を進めることができます。

このパラレル・パスの左端では、可能であれば古いコードの上に新しいエントリ・ポイントを設けて、DLLなどのランタイム・ライブラリ内に関連操作を実行する既存の3GLコードをパッケージします。ライブラリ・ルーチンは、オブジェクトのメソッド・コードのSQLコンポーネントによりコールされます。可能な場合は、3GLテスト・プログラムを使用して、このコードをスタンドアロンでテストしてください。

中間パスでは、オブジェクトの型指定とオブジェクトのメソッド・コードのPL/SQLコンポーネントを定義して記述します。一部のメソッドは全体をPL/SQLで記述できますが、他のメソッドは外部ライブラリにコールします。アプリケーションが外部ライブラリを必要とする場合は、ライブラリ定義とライブラリ・エントリ・ルーチンへの詳細なバインディングを提供します。

その後は、データを操作するためにデプロイする必要があるアクセス・メソッドの複雑度に応じて、作業の進行方向を選択します。必要な問合せメソッドが比較的単純な場合は、標準的な索引を作成できます。データが複雑な場合は、Oracleの拡張可能索引付けテクノロジを使用できるように複合索引タイプを定義する必要があります。プロジェクトでマルチドメイン問合せを使用する場合は、Oracleの拡張可能オプティマイザ・テクノロジを使用する必要があります。

複数ドメインに対する問合せを実行する必要がなく、パフォーマンスに影響する重大要素がI/Oのみの場合は、標準的な最適化方法で十分であると思われます。ただし、パフォーマンスに影響するCPUコストなどの他の要素がある場合も、拡張可能オプティマイザの使用が必要になることがあります。

図2-1 カートリッジ開発プロセス

「図2-1 カートリッジ開発プロセス」の説明

2.2 データ・カートリッジのインストールと使用

データ・カートリッジのインストールは、サーバーで検出してユーザー定義型の定義を認識できるように、コンポーネントをアセンブルするプロセスです。コンポーネントを適切に配置する手順は、次のとおりです。

サーバーで表とユーザー定義型を定義します。通常、そのためにはSQLスクリプトを実行します。
リンク指定で予期される位置に動的リンク・ライブラリを配置します。
オンライン・マニュアル、ヘルプ・ファイルおよびエラー・メッセージ・ファイルを管理されている位置にコピーします。
カートリッジ用に新しく定義した各型をロードするSQLスクリプトを実行し、ユーザー定義型をサーバーに登録します。この手順は、権限が付与されているアカウントから実行する必要があります。
カートリッジのユーザーに必要なアクセス権限を付与します。

2.3 データ・カートリッジ・コンポーネントの要件とガイドライン

データ・カートリッジに関連する一部のデータベース・オブジェクトには、次の要件とガイドラインが適用されます。

2.3.1 カートリッジのスキーマ

各カートリッジを構成するデータベース・コンポーネントは、カートリッジと同じ名前のスキーマにインストールする必要があります。カートリッジで複数のスキーマを使用する場合は、各スキーマ名の最初の10文字をカートリッジ名と同じにする必要があります。Oracleではスキーマ名の長さが30バイト(シングルバイト言語では30文字)に制限されていることに注意してください。

カートリッジ・スキーマに配置する必要のあるデータ・カートリッジのデータベース・コンポーネントは、型名、表名、ビュー名、ディレクトリ名、ライブラリ名およびパッケージ名などです。Oracleでは、スキーマ名とユーザー名は常に同一であるため、スキーマ名の選択によりユーザー名が決定されます。

2.3.2 カートリッジのグローバル名

一部のデータベース・レベル・カートリッジ・コンポーネントは有効範囲内にあるため、単一ユーザーまたはスキーマの有効範囲にあるのではなく、ユーザー全員が参照可能です。この種のグローバルの例として、ロール、シノニムおよび順序があります。すべてのグローバル名は、カートリッジ名で始めて次の書式に従う必要があります。

C$CARTRIDGEGLOBAL

2.3.3 カートリッジのエラー・メッセージ名またはエラー・コード

現在、エラー・コードORA-20000はOracle製品を使用するアプリケーションで生成される全エラー用に予約されています。エラー・メッセージのテキストはカスタマイズ可能です。カートリッジ固有のエラー・メッセージは、次の書式で記述する必要があります。

ORA-20000: C$CARTRIDGE-NNNN:%s

各項目の意味は次のとおりです。

C$CARTRIDGEは、エラーが発生したカートリッジの名前です。
NNNNは、そのカートリッジに対して一意のエラー・メッセージ番号です。
%sは、カートリッジ固有のエラーの説明です。

注意:

エラー・メッセージの記述と管理の詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。

2.3.4 カートリッジ・インストール・ディレクトリ

ベンダーまたはクライアント組織に固有のカートリッジ・インストール・ディレクトリを作成することをお薦めします。このインストール・ディレクトリには、共有ライブラリ、構成ファイル、ディレクトリおよび類似のコンポーネントなど、カートリッジのオペレーティング・システム・レベル・コンポーネントを配置する必要があります。このディレクトリは、組織で選択した接頭辞と同じ名前でプラットフォームのルート・ディレクトリの下に作成します。

2.3.5 カートリッジ・ファイル

各カートリッジに関連するエラー・メッセージ・ファイルを、カートリッジ固有のサブディレクトリに配置することをお薦めします。構成ファイルもカートリッジ固有のサブディレクトリに格納しておくと便利です。

2.3.6 外部プロシージャの共有ライブラリ名

共有ライブラリ(.soまたは.dllファイル)は、カートリッジ・インストール・ディレクトリ(すべてのライブラリ名を一意にする必要があります)または個別ディレクトリに配置できます。個別ディレクトリを使用する場合、ファイル名は先頭のC$に続けてカートリッジ名を使用する必要があります。この種のライブラリが多数存在する場合も、各ライブラリ名は先頭のC$に続けてカートリッジ名の最初の7文字で始める必要があります。

2.4 データ・カートリッジ・デプロイメント

デプロイメント・レベルで発生する共通の問題がいくつかあります。これらの問題に対する最適のアプローチは、アプリケーションのニーズに応じて異なります。次のリストに、チェックリストの基礎となるタスクと提案する解決策を示します。

カートリッジ・コンポーネントをインストールおよびアンインストールする方法が必要です。これには、ライブラリ、データベース・オブジェクト、フラット・ファイル、プログラム、構成ツール、管理ツールおよびその他のオブジェクトが含まれます。
下位互換性と可用性を提供するために、カートリッジの複数バージョンのインストールを可能にする必要があります。計画にはOracle移行機能を取り入れてください。
他のカートリッジをサポートするためにインストールされている(他のカートリッジが依存している)データ・カートリッジを追跡する必要があります。
また、インストールされているコンポーネントの様々なバージョンを追跡する必要があります。
新バージョンのカートリッジに移行するためのアップグレード・パスを提供する必要があります。この場合も、Oracle移行機能を使用できます。
カートリッジ・コンポーネントへのアクセスを特定のユーザーおよびロールに限定するために、Oracleのセキュリティ・メカニズムをニーズに応じて実行者権限および定義者権限で操作するプロシージャと併用します。
管理の目的で、カートリッジへのアクセス権限を持つユーザーを追跡する必要があります。適切なトリガーを持つ表を使用することを検討してください。
カートリッジのインストール場所情報は、しばしばセキュリティ上および管理上の問題になります。現在、特定のデータベースにインストールされているカートリッジやカートリッジまたはコンポーネントへのアクセス権限を持つユーザーを簡単に確認する手段はありません。この情報が重要な場合は、使いやすい方法で継続的に追跡してください。

2.4.1 データ・カートリッジのネーミング規則

データ・カートリッジ・コンポーネントのネーミング方法について説明します(独立系ソフトウェア・ベンダー(ISV)および他のユーザー向けにカートリッジを作成するユーザーが対象)。

データ・カートリッジについて説明する例のほとんどは、簡潔性と汎用性を高めるためにネーミング規則に従っていません。このテクノロジに対する理解が深まり、他のユーザー向けにデータ・カートリッジの作成を検討する段階になったら、ここで説明するネーミング規則に従う必要があります。

ネーミング規則では、シングルバイト・キャラクタ・セットの使用を前提としています。

2.4.1.1 データ・カートリッジでのネーミング規則の必要性

本番環境では、Oracleデータベースに複数のデータ・カートリッジがインストールされている場合があります。これらのデータ・カートリッジは、異なる開発グループやベンダーにより個別に開発されている場合があります。各データ・カートリッジの構成要素には、データベース内の各種スキーマ・オブジェクトのほか、オペレーティング・システム・レベルで参照可能な他のコンポーネント(共有ライブラリ内の外部プロシージャなど)も含まれます。複数のデータ・カートリッジがスキーマ・オブジェクトやオペレーティング・システム・レベルのエンティティに同じ名前を使用しようとすると、正確な結果が得られず、動作の一貫性が失われます。

さらに、データ・カートリッジのランタイム操作中の例外条件が原因でOracleサーバーがエラーを戻す場合があるため、様々なデータ・カートリッジのエラー・コードまたはメッセージ・コードの間で競合を防止することが重要です。たとえば、2つのカートリッジで異なるエラー条件に同じエラー・コードが使用されている場合に、このような競合が発生することがあります。一意のエラー・コードおよびメッセージ・コードを使用することにより、例外条件の発生箇所を確実にすばやく識別できます。

2.4.1.2 一意の名前書式

複数のデータ・カートリッジ・コンポーネントの名前が同一にならないように、次の規則に従ってデータ・カートリッジに確実に一意の名前を使用することをお薦めします。この規則は、データ・カートリッジの各開発組織が一意名を選択するかどうかに依存します。カートリッジ開発者は、C$で始まる一意の名前書式に従うことをお薦めします。

データ・カートリッジとそのコンポーネントには、次の書式の名前を使用する必要があります。

C$pppptttm.ccccc

表2-1に、このネーミング規則の書式の一部を示します。

名前の2文字目はドル記号($)ですが、それ以外の文字はすべて英数字(英字、数字、アンダースコアおよびハイフン)にすることをお薦めします。

たとえば、Acme Cartridge Companyが接頭辞ACMEを選択して登録するとします。この会社はオーディオ・データ・カートリッジとビデオ・データ・カートリッジを提供しており、それぞれのタイプ・コードとしてAUDおよびVIDを選択します。他にカートリッジ名に含める情報はないため、その他の情報インジケータとして任意の番号1を選択します。その結果、2つのカートリッジ名は次のようになります。

C$ACMEAUD1
C$ACMEVID1

カートリッジごとに個別のスキーマを作成する必要があり、Acme社はスキーマ名としてカートリッジ名を使用します。そのため、オーディオ・カートリッジのデータベース・コンポーネントはすべてスキーマC$ACMEAUD1の下に作成し、ビデオ・カートリッジのデータベース・コンポーネントはすべてスキーマC$ACMEVID1の下に作成する必要があります。一部のコンポーネントの例を次に示します。

C$ACMEVID1.mf_rewind
C$ACMEVID1.vid_ops_package
C$ACMEVID1.vid_stream_lib

各組織は、オブジェクト名のC$pppp部分の後に続く特定のネーミング要件を受け持ちます。たとえば、Acme Cartridge Companyは、すべてのカートリッジに一意名があり、カートリッジ内のすべてのコンポーネントにも一意名があることを確認する必要があります。

2.4.1.3 データ・カートリッジのネーミング規則

次の表に、このネーミング規則の書式の各部分を示します。

表2-1 データ・カートリッジのネーミング規則

部分	説明	例
`C$`	すべてのデータ・カートリッジに使用することをお薦めします。
`pppp`	データ・カートリッジ作成者が選択する接頭辞。(常に4文字。)	`ACME`
`ttt`	作成者にわかりやすい短縮形によるカートリッジのタイプ。3文字。	`AUD` (オーディオ)
`m`	作成者にわかりやすい指定を可能にするその他の情報インジケータ。1文字。	`1`(通常はバージョン番号)
`.` (ピリオド)	オブジェクトを完全なschema.object形式で指定する場合は、ピリオドが必要です。
`ccccc`	コンポーネント名。可変長。	`mf_set_volume`

2.4.2 カートリッジの登録

ネーミング方法では、データ・カートリッジを構成するコンポーネントの名前の管理を処理するための登録プロセスが必要です。

2.4.3 カートリッジのディレクトリ構造と標準

バイナリ、サポート・ファイル、メッセージ・ファイル、管理ファイルおよびライブラリの格納場所を指定する、なんらかのディレクトリ標準が必要です。

カートリッジをインストールするデータベース・ユーザーも定義する必要があります。解決策の1つとして、外部データ・カートリッジ・システム・ユーザーを表すEXDSYSを使用する方法が可能です。

注意:

EXDSYSユーザーには、カートリッジを実行するための特別な権限が必要です。このユーザーはカートリッジをインストールする際にインストールできますが、データベースをインストールする際にインストールする方が適切です。そのためには、このプロセスを標準のデータベース作成スクリプトに組み込みます。

2.4.4 カートリッジのアップグレード

管理者には、カートリッジおよび関連メタデータを新バージョンに安全にアップグレードできる方法が必要です。また、データをアップグレードして古いデータを削除するプロセスも必要です。新しいデータベース・カートリッジ・タイプへの移行に対するインストールのサポートとデータベースのサポートを必要とする場合があります。

管理者には、カートリッジに変更があった場合に、カートリッジ・タイプを使用する表を更新する方法も必要です。

2.4.5 カートリッジ・オブジェクトのインポートとエクスポート

オブジェクトをインポートおよびエクスポートするには、Oracleのインポート機能とエクスポート機能でOracleオブジェクトが処理される仕組みを理解する必要があります。特に、型の処理方法、型メソッドのインポートとエクスポートが行われるかどうか、またユーザー定義メソッドがサポートされるかどうかも知る必要があります。

2.4.6 カートリッジのバージョニング

カートリッジのバージョニングについては、内部と外部の2種類の問題に対処する必要があります。

外部バージョニング

2つの問題の中では外部バージョニングの方が容易です。カートリッジのバージョン番号を追跡し、インストール時または構成時にバージョニング情報に基づいてアクションを実行できる必要があります。

内部バージョニング

内部バージョニングの方が困難な問題です。データベース内で1つのカートリッジの複数バージョンをサポートするためのメカニズムがあれば理想的です。これにより下位互換性が得られ、可用性も向上します。

2.4.7 カートリッジの国際化

カートリッジを国際化できます。これにより、複数の言語をサポートし、メッセージ用のグローバリゼーション・サポート機能にアクセスして解析できます。

データ・カートリッジ・コンポーネント名にはASCIIキャラクタ・セットを使用することをお薦めします。

データ・カートリッジ・コンポーネントにASCII以外のキャラクタ・セットで名前を付ける必要がある場合は、Oracleで4文字の一意の接頭辞が割り当てられます。ただし、これにより接頭辞の保持に必要なバイト数が増えます。すべてのOracleスキーマ・オブジェクトの名前は30バイト以内である必要があります。ASCIIでは、これは30文字に相当します。たとえば、6バイトのキャラクタ・セットで、4文字の接頭辞文字列を要求すると、Oracleでは要求した内容がさらに少ない文字数になるよう切り捨てられる場合があります。

2.4.8 カートリッジの管理

データ・カートリッジの計画を作成して開発する際には、その使用の管理に伴う問題を考慮する必要があります。

データ・カートリッジ・アクセスの管理

カートリッジへのアクセス権限を持つユーザーを管理者が確認する方法

管理者は、内部と外部のコンポーネント(プログラムやデータファイルなど)へのアクセス権限を、特定のユーザーおよびロールについて管理する必要があります。

管理者が特定の表、型、ビューおよび他のカートリッジ・コンポーネントへのアクセスを、個別のユーザーおよびロールに限定する方法

セキュリティ上の理由で、管理者は型へのアクセスを個別に制限できるようにする必要があります。

Oracle Multimediaなどの一部のデータ・カートリッジには、セキュリティ上の問題はほとんどありません。この種のカートリッジでは、データベース内の各ユーザーに権限を付与できます。より複雑な他のカートリッジは、異なるセキュリティ・モデルを必要とする場合があります。複合データ・カートリッジを作成する際には、管理者が識別可能なコンポーネントに対するセキュリティ・ロールを付与したり取り消したりできるように、カートリッジの各種コンポーネントとインスタンスを識別する方法が必要となります。

実行者権限

実行者権限とは、通常はアクセスできないデータベース・オブジェクトにシステムでアクセスできるようにする特別な権限です。特殊ユーザーSYSには、この種の権限が付与されます。権限をパブリックに付与しないかぎり、カートリッジをインストールして実行するために作成するユーザーにはこの権限が必要です。

データ・カートリッジ構成

データ・カートリッジには、インストールなどのデプロイメント上の問題を処理するためのフロントエンドのほか、構成ツールが必要です。セキュリティ上のニーズはデータ・カートリッジごとに異なりますが、ユーザーに対してデータ・カートリッジ・コンポーネントのインストール、構成および管理を許可する基本的なフロントエンドが必要です。

このフロントエンドは、単になんらかの形式のナレッジ・ベースであるか、オンライン・マニュアルの場合もあります。いずれにせよ、オンラインで容易にナビゲーション可能であり、標準と始点を示すテンプレートを含む必要があります。

2.4.9 データ・カートリッジ開発アプローチ

データ・カートリッジ開発の一般的なアプローチを示します。

データ・カートリッジの開発では、体系的なアプローチを採ります。つまり、小規模で簡単なタスクから始めて、徐々に包括的なソリューションを構築していきます。

2.4.9.1 データ・カートリッジの計画作成

データ・カートリッジを作成するための計画について概説します。

電力需要カートリッジの例、PSBTREE: 拡張可能索引付けの例およびパイプライン・テーブル・ファンクション: インタフェース・アプローチの例の各例を試してみます。
単一のユーザー定義型と小数のデータ要素およびメソッドから始めて、独自データ・カートリッジのプロトタイプを作成します。カートリッジの機能を拡張するにつれて、ユーザー定義型、データ要素およびメソッド、特定の索引タイプおよびユーザー定義演算子を追加できます。
最初に、メソッド全体をSQLで実装し、必要になった場合は後で3GLコードにコールアウトを追加します。
カートリッジをテストしてデバッグします。

2.4.9.2 データ・カートリッジの開発

データ・カートリッジの一般的な開発プロセス

実際に使用できるプロトタイプがある場合は、次のステップを含む開発プロセスに従うこともできます。

ドメインの専門知識の領域を識別します。
永続データに関連する専門知識の領域を識別します。
これらの領域の1つ以上を新規データ・カートリッジまたは既存カートリッジへの拡張機能としてパッケージする方法の実現可能性を検討します。
オブジェクト指向の方法論を使用すると、データ・カートリッジに組み込むオブジェクト型を決定しやすくなります。
カートリッジを一度に1つずつ作成してテストします。