| Oracle Databaseデータ・カートリッジ開発者ガイド 11gリリース1（11.1） E05688-02 |
|
 戻る |
 次へ |
この章では、プロセスのステップ間の関係や依存性など、データ・カートリッジ開発プロセスに伴う推奨事項について説明します。
この章の内容は、次のとおりです。
データ・カートリッジ開発プロセスを理解するために、プロジェクト全体を考えてみます。
カートリッジの対象ユーザーがソフトウェア開発者の場合は、カートリッジの拡張性が最重要課題の1つになります。エンド・ユーザーの場合は、意図したドメインにあわせてカートリッジをできるかぎり調整する必要があります。カートリッジの設計には、ユーザー全員が明確に理解しているビジネス・モデルを反映させてください。カートリッジのサイズに関係なく、開発チームはオブジェクト・リレーショナル・データベース管理システムを細部に至るまで理解し、その知識をカートリッジのドメインの問題に応用する必要があります。
適切に定義されたソフトウェア開発プロセスを使用し、期待される成果を明確に識別し、データ・カートリッジ開発の妥当な中間目標を設定します。適切なプロジェクト期間をスケジュールし、使用可能なリソースのスキルを具体的に把握することで、プロジェクトを成功に近づけることができます。
オブジェクトを選択して設計する際には、その名前とセマンティクスが開発者とエンド・ユーザーにとって理解しやすい明確なものであることを確認します。
オブジェクトのコレクションを定義する際には、オブジェクト・メソッドのSQL側とアプリケーション開発で使用されるプログラミング言語とのインタフェースを考慮します。このインタフェースはできるかぎり単純なものにしておきます。そのために、ライブラリ・ルーチンをコールするメソッドの数を制限し、低レベルのライブラリ・エントリ・ポイントへの多数のコールを回避し、プリフェッチ済データを処理する大きいコード・ブロックを記述します。
インタフェースを定義した後、図2-1のようにパラレル・パスに沿って作業を進めます。使用可能なリソースに応じて適切な順序で作業を進めることができます。
このパラレル・パスの左端では、可能な場合は古いコードの最上部に新規のエントリ・ポイントを設けて、DLLなどのランタイム・ライブラリ内に関連操作を実行する既存の3GLコードをパッケージします。ライブラリ・ルーチンは、オブジェクトのメソッド・コードのSQLコンポーネントによりコールされます。可能な場合は、3GLテスト・プログラムを使用して、このコードをスタンドアロンでテストしてください。
中間パスでは、オブジェクトの型指定とオブジェクトのメソッド・コードのPL/SQLコンポーネントを定義して記述します。一部のメソッドは全体をPL/SQLで記述できますが、他のメソッドは外部ライブラリにコールします。アプリケーションが外部ライブラリを必要とする場合は、ライブラリ定義とライブラリ・エントリ・ルーチンへの詳細なバインディングを提供します。
その後は、データ操作用にデプロイする必要のあるアクセス・メソッドの複雑度に応じて、作業の進行方向を選択します。必要な問合せメソッドが比較的単純な場合は、標準的な索引を作成できます。データが複雑な場合は、Oracleの拡張可能索引付けテクノロジを使用できるように複合索引タイプを定義する必要があります。マルチドメイン問合せも可能にする必要がある場合は、Oracleの拡張可能オプティマイザ・テクノロジを使用してください。
複数ドメインに対する問合せを実行する必要がなく、パフォーマンスに影響する重大要素がI/Oのみの場合は、標準的な最適化方法で十分であると思われます。ただし、パフォーマンスに影響するCPUコストなど、他の要素がある場合も、拡張可能オプティマイザの使用が必要になることがあります。
データ・カートリッジのインストールは、サーバーで検出してユーザー定義型の定義を認識できるように、コンポーネントをアセンブルするプロセスです。コンポーネントを適切に配置する手順は、次のとおりです。
サーバーで表とユーザー定義型を定義します。通常、そのためにはSQLスクリプトを実行します。
リンク指定で予期される位置に動的リンク・ライブラリを配置します。
オンライン・マニュアル、ヘルプ・ファイルおよびエラー・メッセージ・ファイルを管理されている位置にコピーします。
カートリッジ用に新しく定義した各型をロードするSQLスクリプトを実行し、ユーザー定義型をサーバーに登録します。この手順は、権限が付与されているアカウントから実行する必要があります。
カートリッジのユーザーに必要なアクセス権限を付与します。
データ・カートリッジに関連する一部のデータベース・オブジェクトには、次の要件とガイドラインが適用されます。
各カートリッジを構成するデータベース・コンポーネントは、カートリッジと同じ名前を持つスキーマにインストールする必要があります。カートリッジで複数のスキーマを使用する場合は、各スキーマ名の最初の10文字をカートリッジ名と同じにする必要があります。Oracleでは、スキーマ名の長さが30バイト（シングルバイト言語では30文字）に制限されていることに注意してください。
カートリッジ・スキーマに配置する必要のあるデータ・カートリッジのデータベース・コンポーネントは、型名、表名、ビュー名、ディレクトリ名、ライブラリ名およびパッケージ名などです。Oracleでは、スキーマ名とユーザー名は常に同一であるため、スキーマ名の選択によりユーザー名が決定されます。
一部のデータベース・レベル・カートリッジ・コンポーネントは有効範囲内にあるため、単一ユーザーまたはスキーマの有効範囲にあるのではなく、ユーザー全員が参照可能です。この種のグローバルの例として、ロール、シノニムおよび順序があります。すべてのグローバル名は、カートリッジ名で始めて次の書式に従う必要があります。
C$CARTRIDGEGLOBAL
現在、エラー・コードORA-20000はOracle製品を使用するアプリケーションで生成される全エラー用に予約されています。エラー・メッセージのテキストはカスタマイズ可能です。カートリッジ固有のエラー・メッセージは、次の書式で記述する必要があります。
ORA-20000: C$CARTRIDGE-NNNN:%s
各項目の意味は次のとおりです。
C$CARTRIDGEは、エラーが発生したカートリッジの名前です。
NNNNは、そのカートリッジに対して一意のエラー・メッセージ番号です。
%sは、カートリッジ固有のエラーの説明です。
|
関連項目 エラー・メッセージの記述と管理の詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。 |
ベンダーまたはクライアント組織に固有のカートリッジ・インストール・ディレクトリを作成することをお薦めします。このインストール・ディレクトリには、共有ライブラリ、構成ファイル、ディレクトリおよび類似のコンポーネントなど、カートリッジのオペレーティング・システム・レベル・コンポーネントを配置する必要があります。このディレクトリは、組織で選択した接頭辞と同じ名前を使用して、プラットフォームのルート・ディレクトリの下に作成してください。
デプロイメント・レベルには、一般的な問題が多数存在します。これらの問題に対する最適のアプローチは、アプリケーションのニーズに応じて異なります。次のリストに、チェックリストの基礎となるタスクと提案する解決策を示します。
カートリッジ・コンポーネントをインストールおよびアンインストールする方法が必要です。これには、ライブラリ、データベース・オブジェクト、フラット・ファイル、プログラム、構成ツール、管理ツールおよびその他のオブジェクトが含まれます。これらの操作の実行にはOracle Universal Installerを使用することを検討してください。
|
関連項目 『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド』 |
下位互換性と可用性を提供するために、カートリッジの複数バージョンのインストールを可能にする必要があります。計画にはOracle移行機能を取り入れてください。
他のカートリッジに依存するカートリッジをインストールしたり、様々なバージョンのインストール済コンポーネントを処理するために、インストールされているデータ・カートリッジを追跡する必要があります。
新バージョンのカートリッジに移行するためのアップグレード・パスを提供する必要があります。この場合も、Oracle移行機能を使用できます。
カートリッジ・コンポーネントへのアクセスを特定のユーザーおよびロールに限定するために、Oracleのセキュリティ・メカニズムをニーズに応じて実行者権限および定義者権限で操作するプロシージャと併用します。
管理のために、カートリッジへのアクセス権限を持つユーザーを追跡する必要があります。適切なトリガーを持つ表を使用することを検討してください。
カートリッジのインストール場所情報は、しばしばセキュリティ上および管理上の問題になります。現在、特定のデータベースにインストールされているカートリッジやカートリッジまたはコンポーネントへのアクセス権限を持つユーザーを簡単に確認する手段はありません。この情報が重要な場合は、使いやすい方法で継続的に追跡してください。
この項では、データ・カートリッジ・コンポーネントのネーミング方法について説明します。この項は、独立系ソフトウェア・ベンダー（ISV）および他のユーザーが使用するカートリッジを作成するユーザーを対象としています。
|
注意: このマニュアルのほとんどの例は、できるかぎり単純で一般的な情報を示すことを意図しているため、ネーミング規則に従っていません。ただし、テクノロジに対する理解を深め、他のユーザーが使用するデータ・カートリッジの作成を検討している場合は、次のネーミング規則を理解して従う必要があります。 |
この章で説明するネーミング規則は、シングルバイト・キャラクタ・セットを想定しています。
本番環境では、Oracleデータベースに複数のデータ・カートリッジがインストールされている場合があります。これらのデータ・カートリッジは、異なる開発グループやベンダーにより個別に開発されている場合があります。各データ・カートリッジの構成要素には、データベース内の各種スキーマ・オブジェクトのみでなく、共有ライブラリ内の外部プロシージャなど、オペレーティング・システム・レベルで参照可能な他のコンポーネントも含まれます。複数のデータ・カートリッジがスキーマ・オブジェクトやオペレーティング・システム・レベルのエンティティに同じ名前を使用しようとすると、正確な結果が得られず、動作の一貫性が失われます。
さらに、データ・カートリッジのランタイム操作中の例外条件が原因でOracleサーバーがエラーを戻す場合があるため、様々なデータ・カートリッジのエラー・コードまたはメッセージ・コードの間で競合を防止することが重要です。たとえば、2つのカートリッジで異なるエラー条件に同じエラー・コードが使用されている場合に、このような競合が発生することがあります。一意のエラー・コードおよびメッセージ・コードを使用することにより、例外条件の発生箇所を確実にすばやく識別できます。
複数のデータ・カートリッジ・コンポーネントの名前が同一にならないように、次の規則に従ってデータ・カートリッジに確実に一意の名前を使用することをお薦めします。この規則は、データ・カートリッジの各開発組織が一意名を選択するかどうかに依存します。カートリッジ開発者は、C$で始まる一意の名前書式に従うことをお薦めします。
データ・カートリッジとそのコンポーネントには、次の書式の名前を使用する必要があります。
C$pppptttm.ccccc
表2-1に、このネーミング規則の書式の一部を示します。
表2-1 データ・カートリッジのネーミング規則
| 部分 | 説明 | 例 |
|---|---|---|
|
|
すべてのデータ・カートリッジに使用することをお薦めします。 |
|
|
|
データ・カートリッジ作成者が選択する接頭辞。（常に4文字。） |
|
|
|
作成者にわかりやすい短縮形によるカートリッジのタイプ。3文字。 |
|
|
|
作成者にわかりやすい指定を可能にするその他の情報インジケータ。1文字。 |
|
|
|
オブジェクトを完全なschema.object形式で指定する場合は、ピリオドが必要です。 |
|
|
|
コンポーネント名。可変長。 |
|
名前の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は、すべてのカートリッジに一意名があり、カートリッジ内のすべてのコンポーネントにも一意名があることを確認する必要があります。
バイナリ、サポート・ファイル、メッセージ・ファイル、管理ファイルおよびライブラリの格納場所を指定する、なんらかのディレクトリ標準が必要です。
また、カートリッジをインストールするデータベース・ユーザーも定義する必要があります。解決策の1つとして、外部データ・カートリッジ・システム・ユーザーを表すEXDSYSを使用する方法が可能です。
|
注意: EXDSYSユーザーは、カートリッジの実行に必要となる特別な権限を持つユーザーです。このユーザーはカートリッジ・インストールの一部としてインストールできますが、データベース・インストールの一部にする方が解決策としては適切です。そのためには、このプロセスを標準データベース作成スクリプトに移動する必要があります。 |
管理者には、カートリッジおよび関連メタデータを新バージョンに安全にアップグレードできる方法が必要です。また、データをアップグレードして古いデータを削除するプロセスも必要です。新しいデータベース・カートリッジ・タイプへの移行に対するインストールのサポートとデータベースのサポートを必要とする場合があります。
管理者には、カートリッジに変更があった場合に、カートリッジ・タイプを使用する表を更新する方法も必要です。
オブジェクトをインポートおよびエクスポートするには、Oracleのインポート機能とエクスポート機能によるOracleオブジェクトの処理方法を理解する必要があります。特に、型の処理方法と、型のメソッドがインポートおよびエクスポートされるかどうか、さらにユーザー定義メソッドに対するサポートの有無も知る必要があります。
カートリッジのバージョニングについては、内部および外部の2種類の問題に対処する必要があります。
カートリッジを国際化できます。これにより、複数の言語をサポートし、メッセージ用のグローバリゼーション・サポート機能にアクセスして解析できます。
|
関連項目 『Oracle Databaseグローバリゼーション・サポート・ガイド』 |
データ・カートリッジ・コンポーネント名にはASCIIキャラクタ・セットを使用することをお薦めします。
データ・カートリッジ・コンポーネント名にASCII以外のキャラクタ・セットを使用する必要がある場合も、Oracleでは4文字の一意の接頭辞が割り当てられます。ただし、これにより接頭辞の保持に必要なバイト数が増えます。すべてのOracleスキーマ・オブジェクトの名前は30バイト以内である必要があります。ASCIIでは、これは30文字に相当します。たとえば、6バイトのキャラクタ・セットで、4文字の接頭辞文字列を要求すると、Oracleでは要求した内容がさらに少ない文字数になるよう切り捨てられる場合があります。
データ・カートリッジの計画を作成して開発する際には、その使用の管理に伴う問題を考慮する必要があります。
カートリッジへのアクセス権限を持つユーザーを管理者が確認する方法
管理者は、プログラムやデータファイルなどの内部および外部コンポーネントへのアクセス権限を、特定のユーザーおよびロールについて管理する必要があります。
管理者が特定の表、型、ビューおよび他のカートリッジ・コンポーネントへのアクセスを、個別のユーザーおよびロールに限定する方法
セキュリティ上の理由で、管理者は型へのアクセスを個別に制限できるようにする必要があります。
Oracleのイメージ・カートリッジなど、一部のデータ・カートリッジにはセキュリティ上の問題はほとんどありません。この種のカートリッジでは、データベース内の各ユーザーに権限を付与できます。より複雑な他のカートリッジは、異なるセキュリティ・モデルを必要とする場合があります。複合データ・カートリッジを作成する際には、管理者が識別可能なコンポーネントに対するセキュリティ・ロールを付与したり取り消すことができるように、カートリッジの各種コンポーネントのみでなく、カートリッジのインスタンスも識別する方法が必要となります。
データ・カートリッジを開発するには、系統的なアプローチを採用し、小規模で容易なタスクから始めて少しずつ包括的なソリューションを作成していきます。この項では、推奨されるアプローチを示します。
プロトタイプ・データ・カートリッジを作成する手順は、次のとおりです。
このマニュアルの関連する章を読みます。第15章「電力需要カートリッジの例」、第16章「PSBTREE: 拡張可能索引付けの例」および第17章「パイプライン・テーブル・ファンクション: インタフェース・アプローチの例」に示す例を試してみます。
単一のユーザー定義型と小数のデータ要素およびメソッドから始めて、独自データ・カートリッジのプロトタイプを作成します。カートリッジの機能を拡張するにつれて、ユーザー定義型、データ要素およびメソッド、特定の索引タイプおよびユーザー定義演算子を追加できます。
最初に、メソッド全体をSQLで実装し、必要になった場合は後で3GLコードにコールアウトを追加します。
カートリッジをテストしてデバッグします。
プロトタイプを機能させる場合は、次のステップを含む開発プロセスに従うことができます。
ドメインの専門知識の領域を識別します。
永続データに関連する専門知識の領域を識別します。
これらの領域の1つ以上を新規データ・カートリッジまたは既存カートリッジへの拡張機能としてパッケージする方法の実現可能性を検討します。
オブジェクト指向の方法論を使用すると、データ・カートリッジに組み込むオブジェクト型を決定しやすくなります。
カートリッジを一度に1つずつ作成してテストします。
