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

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つずつ作成してテストします。