| Oracle Multimedia DICOM開発者ガイド 11g リリース1（11.1） E05685-01 |
|
 戻る |
 次へ |
この章では、Oracle Multimedia DICOMデータ・モデル・リポジトリの管理に関連するタスクの概要を説明します。
Oracle Multimedia DICOMデータ・モデル・リポジトリでは、ユーザーによる構成が可能な一連のXML文書が集中管理されており、これらのXML文書によって、Oracle Multimedia DICOMの実行時の動作が定義されます。 Oracle Multimediaをインストールすると、Oracle Multimedia DICOMは完全に機能するため、管理者は、リポジトリを更新して特定のデータベース・インスタンスに合わせてOracle Multimedia DICOMを構成する必要がないかぎり、リポジトリにアクセスする必要はありません。 各データベースには専用の構成ドキュメント・セットがあります。 管理者は、構成ドキュメントを追加したり削除してリポジトリをカスタマイズできます。 一度に1人の管理者のみが、データ・モデル・リポジトリを変更できます。 DICOMデータ・モデル・リポジトリの管理者は、ORDADMINロールが割り当てられます。
管理者は、多くのリポジトリ管理タスクを実行できます。 この章では、リポジトリのロード、リポジトリ内のコンテンツの検索、追加および削除といったタスクのガイドラインを説明します。 構成ドキュメントの記述方法の詳細は、第11章を参照してください。
DICOMデータ・モデル・リポジトリには、構成ドキュメントを管理するための管理用（PL/SQL）アプリケーション・プログラミング・インタフェース（API）が用意されています。 ORD_DICOM_ADMINデータ・モデル・リポジトリAPIの詳細なリファレンス情報は、第9章を参照してください。
この他、管理者は次のAPIを使用できます。これらのAPIもOracle Multimedia DICOMによって用意されています。
ORDDicomオブジェクトAPI
DICOMデータ・モデル・ユーティリティAPI
DICOMリレーショナルAPI
DICOM Java API
|
注意: 次の管理ガイドラインに留意してください。
|
この章は、次の項で構成されています。
表8-1には、Oracle Multimediaソフトウェア・ドキュメント・セット内の他項目への管理者用の相互参照を示します。この表からは、この章で説明されているトピックの追加情報にアクセスできます。
表8-1 管理者用の追加リファレンス
| トピック | 参照先 |
|---|---|
|
パブリック情報ビューのリファレンス情報 |
|
|
管理者情報ビューのリファレンス情報 |
|
|
DICOMデータ・モデル・ユーティリティAPIのリファレンス情報 |
|
|
ORDDicomオブジェクトAPIのリファレンス情報 |
|
|
DICOMリレーショナルAPIのリファレンス情報 |
|
|
ORD_DICOM_ADMINデータ・モデル・リポジトリAPIのリファレンス情報 |
|
|
DICOM Java APIのリファレンス情報 |
『Oracle Multimedia DICOM Java API Reference』 |
|
DICOMコンテンツの操作の例 |
|
|
データ・モデル・リポジトリの管理操作の例 |
|
|
構成ドキュメントの記述に関する情報 |
|
|
DICOM XMLスキーマのリスト |
|
Oracle Multimedia DICOMをインストールすると、DICOMデータ・モデル・リポジトリの管理に必要なデータベース・システム権限を持つORDADMINロールが作成されます。
ORDADMINロールは、DICOMデータ・モデル・リポジトリの管理者に割り当てる必要があります。 次に示すコードは、管理者dcmadminに対するGRANT文の例です。
GRANT ORDADMIN to dcmadmin;
データベース・ロールの動作と同様に、管理者がPL/SQL名前付きプロシージャを記述する必要のあるタスクでは、明示的な権限が必要です。 次に示すコードは、dcmadminという名前の管理者に対するGRANT文の例です。
GRANT EXECUTE on ORD_DICOM_ADMIN to dcmadmin;GRANT SELECT on orddcm_document_refs to dcmadmin;
管理者には、特定のディレクトリへの書込み権限も付与する必要があります。 たとえば、構成ドキュメントをエクスポートする操作では、構成ドキュメントの保存先のディレクトリに対する書込みアクセス権限を管理者が所有している必要があります。
すべてのユーザーは、データ・モデル・リポジトリをメモリー構造にロードして、多くのパブリック情報ビューを表示することができます。 データ・モデル・リポジトリから構成ドキュメントをエクスポート、挿入または削除できるのは、管理者のみです。 また、管理者のみが管理者専用の情報ビューへの問合せを実行できます。
データベース・セッションを開始するたびに、管理者およびユーザーは、データベースからメモリー構造にデータ・モデル・リポジトリをロードする必要があります。 ユーザーは、setDataModel( )プロシージャをコールしてデータ・モデルをロードします。 管理者は、setDataModel( )プロシージャまたはeditDataModel( )プロシージャをコールして、データ・モデルをロードします。
リポジトリがメモリーにロードされると、管理者およびユーザーは、データ・モデルの新しい変更をアプリケーションで確認する必要があるときはいつでも、setDataModel( )プロシージャをコールできます。
|
注意: 管理者およびユーザーは、他のDICOMメソッド、ファンクションまたはプロシージャをコールする前に、setDataModel( )プロシージャをコールする必要があります。データ・モデルに対して変更を行わない場合、管理者はsetDataModel( )プロシージャをコールできます（例: getDocumentContent( )プロシージャまたはexportDocument( )プロシージャのみをコールする場合）。 データ・モデルを変更する場合、管理者はeditDataModel( )プロシージャをコールできます（例: ドキュメントを挿入または削除する場合）。 |
ORD_DICOMパッケージのDICOMデータ・モデル・ユーティリティを使用して、次のようにsetDataModel( )プロシージャをコールします。
exec ord_dicom.setdatamodel;
リファレンス情報は、第4章のsetDataModel( )プロシージャを参照してください。
ORD_DICOM_ADMINパッケージを使用して、次のようにeditDataModel( )プロシージャをコールします。
exec ord_dicom_admin.editDataModel();
リファレンス情報は、第9章のeditDataModel( )プロシージャを参照してください。
DICOMリポジトリを表示するために、多くのパブリック情報ビューが用意されています。 DICOMリポジトリの管理に役立つように、管理者専用の情報ビューも用意されています。 情報ビューでは、ドキュメント名、ドキュメント・タイプ、他のドキュメントへの参照、制約名および制約検証メッセージなど、リポジトリ内のドキュメントに関する詳細が提供されます。
表8-2に、情報ビューのリストと、すべてのユーザーが参照可能（パブリック）なのか、または管理者のみが参照可能なのかを示します。
表8-2 管理者情報ビューおよびパブリック情報ビュー
| 名前 | アクセス・カテゴリ |
|---|---|
|
orddcm_conformance_vld_msgs |
パブリック（ユーザーのスキーマに対するメッセージのみ） |
|
orddcm_constraint_names |
パブリック |
|
orddcm_document_refs |
管理者のみ |
|
orddcm_document_types |
パブリック |
|
orddcm_documents |
パブリック |
管理者はorddcm_document_refs情報ビューを使用して、リポジトリ内の他のドキュメントから参照されているドキュメントのリストを参照できます。 この読取り専用の情報ビューは、管理者のみが参照できます。 このビューの詳細は、第9章を参照してください。
また、管理者（および他のユーザー）は、orddcm_documentsビューを使用して、リポジトリ内に格納されているドキュメントの詳細リストを参照できます。 管理者およびユーザーは、orddcm_document_typesビューも使用できます。このビューにはドキュメント・タイプを表すコードが含まれているため、サポートされているOracle Multimedia DICOMのドキュメント・タイプを識別できます。 これらのパブリック情報ビューは読取り専用です。
他に2つのパブリック情報ビューがあります。 orddcm_constraint_namesビューでは、リポジトリにインストールされている制約の名前がリストされます。 orddcm_conformance_vld_msgsビューには、制約の検証中にユーザー所有のスキーマに対してのみ生成される制約メッセージがリストされます。
パブリック情報ビューの詳細は、第4章を参照してください。
管理者がリポジトリに対してドキュメントの挿入、更新および削除を行う場合は、通常、orddcm_documents、orddcm_document_typesおよびorddcm_document_refsのビューを使用します。
リポジトリからドキュメントをエクスポートする前（および場合によっては構成ドキュメントに対して変更を行う前）に、管理者は次のタスクを実行する必要があります。
各データベース・セッションの始めにsetDataModel( )プロシージャをコールして、リポジトリをデータベースからメモリー構造内にロードします。 この時点では、リポジトリをロックする必要はありません。
管理者（および他のユーザー）は、データ・モデルの新しい変更をアプリケーションで確認する必要があるときはいつでも、このプロシージャをコールできます。
setDataModel( )プロシージャのリファレンス情報は、第4章を参照してください。
getDocumentContent( )ファンクションまたはexportDocument( )プロシージャを使用して、リポジトリにある既存のドキュメントのコピーを取得します。
getDocumentContent( )ファンクションでは、指定したドキュメントがデータ型XMLTypeとして戻されます。
exportDocument( )プロシージャでは、管理者に書込み権限が付与されているディレクトリ内の指定したファイルに、指定したドキュメントの内容が書き込まれます。
getDocumentContent( )ファンクションおよびexportDocument( )プロシージャのリファレンス情報は、第9章を参照してください。
リポジトリにドキュメントを挿入する処理では、次のプロシージャを使用します。
editDataModel( )
insertDocument( )
publishDataModel( )
rollbackDataModel( )
プロシージャのリファレンス情報は、第9章を参照してください。 挿入処理の例は、第10章を参照してください。
次の各項では、ドキュメント・タイプ別の挿入処理について簡単に説明します。
匿名ドキュメントおよびマッピング・ドキュメントの場合、挿入する順序は関係ありません。 しかし、制約ドキュメントの場合は挿入する順序が重要になります。 挿入する制約ドキュメントの間に依存性がある場合は、依存性のあるドキュメントを先に挿入します。 その後、残りのドキュメントを挿入します。
標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの挿入では、新しいディクショナリ・ドキュメントを挿入するたびに、次のルールに従ってすべてのディクショナリ属性をマージする必要があります。
属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。
属性タグは、他のドキュメント・タイプで使用されていないことが必要です。
また、プライベート・ディクショナリ・ドキュメントの属性タグは、既存の範囲タグのいずれにも含まれないようにする必要があります。
|
注意: 標準ディクショナリ・ドキュメントの挿入は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。 |
ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、付録Bに記載されているXMLスキーマordcmsd.xsdおよびordcmpv.xsdを参照してください。
プリファレンス・ドキュメントを挿入するには、まず、必要に応じてパラメータ値を変更して、インストール済のOracle定義のプリファレンス・ドキュメントをエクスポートします。 その後、更新したユーザー定義のプリファレンス・ドキュメントをリポジトリに挿入します。
管理者は、ユーザー定義のUID定義ドキュメントを挿入して、新たにプライベートUID値を追加したりDICOM標準規格の更新内容を反映させることができます。 後になってユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントが削除された場合は、Oracleでインストールされたドキュメントが再度適用されます。
|
注意: リポジトリに挿入できるのは、1つのユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントのみです。 |
リポジトリ内のドキュメントを更新する処理では、次のプロシージャを使用します。
editDataModel( )
exportDocument( )
deleteDocument( )
insertDocument( )
publishDataModel( )
rollbackDataModel( )
プロシージャのリファレンス情報は、第9章を参照してください。 更新処理の例は、第10章を参照してください。
次の各項では、ドキュメント・タイプ別の更新処理について簡単に説明します。
匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの更新では、同様の一連の処理を実行します。 匿名ドキュメントおよびマッピング・ドキュメントの場合は、次の手順を実行します。
既存のドキュメントをエクスポートします。
エクスポートしたドキュメントを編集します。
既存のドキュメントを削除します。
編集済のドキュメントを挿入します。
制約ドキュメントの更新は、制約ドキュメントの挿入とは逆の順序で処理します。 また、更新する制約ドキュメントの間に依存性がある場合は、依存性がないドキュメントを先に更新します。 その後、残りのドキュメントを更新します。
標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの更新では、属性タグ、およびリポジトリ内の他のドキュメントとの依存性をチェックする必要があります。 標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントを更新できるのは、その新しいドキュメントに定義されている属性タグが他のドキュメントで使用されていない場合のみです。 他のドキュメントで使用されている属性タグを更新するには、まず、依存しているドキュメントを更新して、参照先の属性タグを削除します。 その後、次のルールに従ってディクショナリ・タグを更新します。
属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。
属性タグは、他のドキュメント・タイプで使用されていないことが必要です。
また、プライベート・ディクショナリ・ドキュメントの場合は、DICOM属性タグが既存の範囲タグのいずれにも含まれないようにする必要があります。
|
注意: 標準ディクショナリ・ドキュメントの更新は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。 |
ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、付録Bに記載されているXMLスキーマordcmsd.xsdおよびordcmpv.xsdを参照してください。
リポジトリからドキュメントを削除する処理では、次のプロシージャを使用します。
editDataModel( )
exportDocument( )
deleteDocument( )
publishDataModel( )
rollbackDataModel( )
元のドキュメントをリポジトリから削除する前に、exportDocument( )プロシージャを使用してドキュメントのコピーを保存します。
削除できるのは、ユーザー定義のドキュメントのみです。 Oracleでインストールされたドキュメントはデフォルトのドキュメントで、削除できません。 また、参照先の制約に準拠するため、ドキュメントをロードした順序とは逆の順序でドキュメントを削除します。
プロシージャのリファレンス情報は、第9章を参照してください。 削除処理の例は、第10章を参照してください。
次の各項では、ドキュメント・タイプ別の削除処理について簡単に説明します。
匿名ドキュメントおよびマッピング・ドキュメントの場合、削除する順序は関係ありません。 しかし、制約ドキュメントの場合は、削除する順序が重要になります。 制約ドキュメントの削除は、制約ドキュメントの挿入とは逆の順序で処理します。 また、削除する制約ドキュメントの間に依存性がある場合は、依存性がないドキュメントを先に削除します。 その後、残りのドキュメントを削除します。
