Oracle® Multimedia DICOM Developer's Guide 11g Release 2 (11.2) Part Number E10778-01 |
|
|
View PDF |
This chapter briefly describes the tasks that are related to the administration of the Oracle Multimedia DICOM data model repository.
The Oracle Multimedia DICOM data model repository is a set of collectively managed, user-configurable XML documents that defines the run-time behavior of Oracle Multimedia DICOM. Because Oracle Multimedia DICOM is fully functional after installing Oracle Multimedia, administrators need not access the repository unless they want to update it to configure Oracle Multimedia DICOM for a particular database instance. Each database has its own set of configuration documents. Administrators can customize the repository by adding or deleting configuration documents. Only one administrator at a time is permitted to make changes in the data model repository. Administrators of the DICOM data model repository are assigned the ORDADMIN role.
Administrators can perform several repository management tasks. This chapter provides guidelines for loading the repository, and retrieving, adding, and removing content from the repository. See Chapter 12 for more information about writing configuration documents.
The DICOM data model repository provides an administrative (PL/SQL) application programming interface (API) for managing configuration documents. See Chapter 10 for reference information about the ORD_DICOM_ADMIN data model repository API.
In addition, administrators can use these application programming interfaces (APIs), which are also provided by Oracle Multimedia DICOM:
ORDDicom object API
DICOM data model utility API
DICOM relational API
DICOM Java API
Note:
Keep these administrative guidelines in mind:Changes in the data model repository are committed only by using the publishDataModel( ) procedure. In addition to committing the changes, this procedure unlocks the data model, making it available to other administrators.
The editDataModel( ) procedure enables administrators to lock the data model while making changes.
See Chapter 10 for more information about these procedures.
This chapter includes these sections:
Table 9-1 provides cross-references to various locations within the Oracle Multimedia documentation set where administrators can access additional information about topics mentioned in this chapter.
Table 9-1 Additional References for Administrators
Topic | More Information |
---|---|
Reference information for public information views |
|
Reference information for administrator information views |
|
Reference information for the DICOM data model utility API |
|
Reference information for the ORDDicom object API |
|
Reference information for the DICOM relational API |
|
Reference information for the ORD_DICOM_ADMIN data model repository API |
|
Reference information for the DICOM Java API |
|
Reference information for the Mid-Tier Java API |
|
Examples of operations on DICOM content |
|
Examples of administrative operations in the data model repository |
|
Information about writing configuration documents |
|
Listings of the DICOM XML schemas |
After installing Oracle Multimedia DICOM, the ORDADMIN role is created, with the database system privileges required for administration of the DICOM data model repository.
The ORDADMIN role must be assigned to the administrator of the DICOM data model repository. The following code segment shows a sample GRANT statement for the administrator dcmadmin
:
GRANT ORDADMIN to dcmadmin;
Because of the way database roles behave, tasks for which the administrator must write PL/SQL named procedures require explicit privileges. The following code segment shows a sample of a GRANT statement for an administrator named dcmadmin
:
GRANT EXECUTE on ORD_DICOM_ADMIN to dcmadmin; GRANT SELECT on orddcm_document_refs to dcmadmin;
Administrators must also be granted the write privilege for specified directories. For example, during operations where configuration documents are exported, administrators must have write access to the directory where those documents are to be stored.
All users can load the data model repository into memory structures and view several public information views. Only administrators can export, insert, or delete configuration documents from the data model repository. And, only administrators can query administrator-only information views.
The DICOM XML schemas in Oracle Multimedia DICOM are registered as global XML schemas in Oracle Database with Oracle XML DB. (See Appendix B for listings of the installed DICOM XML schemas.)
If you define custom XML schemas, you must register them as global schemas with Oracle XML DB. See Oracle XML DB Developer's Guide for more information about registering XML schemas.
Querying the dictionary view ALL_XML_SCHEMAS
enables you to find and examine the registered XML schemas. See Oracle Database Reference for more information about this dictionary view.
Oracle requires that you register all user-defined XML schemas as global schemas, using Oracle XML DB. See Oracle XML DB Developer's Guide for an example, which shows how to set the parameter LOCAL to FALSE
to indicate that the schema is global.
After registering the custom XML schemas for your DICOM data model repository, you can search for and examine them.
Example 9-1 shows a sample of how to list the namespaces for the metadata schemas associated with the user-defined mapping documents in your DICOM data model repository.
Example 9-1 Finding User-Registered XML Schemas
exec ord_dicom.setdatamodel; select t.doc_name, xmlcast(xmlquery( 'declare default element namespace "http://xmlns.oracle.com/ord/dicom/mapping_1_0"; $x//NAMESPACE' passing ord_dicom_admin.getdocumentcontent(t.doc_name) as "x" returning content) as varchar2(4000) ) as schema_url from orddcm_documents t where t.installed_by_oracle=0 and t.doc_type= 'MAPPING' order by t.doc_id asc; DOC_NAME SCHEMA_URL -------------------- ------------------------------------- sample_map_10.xml http://www.mycompany.com/metatest10 sample_map_11.xml http://www.mycompany.com/metatest11
See Oracle XML DB Developer's Guide for more information about finding registered XML schemas.
At the start of every database session, administrators and users must load the data model repository from the database into memory structures. Users load the data model by calling the setDataModel( ) procedure. Administrators load the data model by calling either the setDataModel( ) procedure or the editDataModel( ) procedure.
After loading the repository into memory, administrators and users can call the setDataModel( ) procedure whenever the application requires the new data model changes.
Note:
Administrators and users must call the setDataModel( ) procedure before calling any other DICOM methods, functions, or procedures.Administrators can call the setDataModel( ) procedure when no changes are being made to the data model (for example: when calling the getDocumentContent( ) procedure or the exportDocument( ) procedure only).
Administrators can call the editDataModel( ) procedure when making changes to the data model (for example: when inserting or deleting documents.)
Using the DICOM data model utility in the ORD_DICOM package, administrators and users call the setDataModel( ) procedure as follows:
exec ord_dicom.setdatamodel;
See the setDataModel( ) Procedure for reference information.
Using the ORD_DICOM_ADMIN package, administrators call the editDataModel( ) procedure as follows:
exec ord_dicom_admin.editDataModel();
See the editDataModel( ) Procedure for reference information.
Several public information views are available for browsing the DICOM repository. An administrator-only information view is also available to assist with DICOM repository administration. Information views provide details about documents in the repository, including names of documents, types of documents, references to other documents, names of constraints, and constraint validation messages.
Table 9-2 lists the information views and indicates which views are available to all users (public) or only to administrators.
Table 9-2 Administrator and Public Information Views
Name | Access Category |
---|---|
orddcm_conformance_vld_msgs |
Public (messages for user's schema only) |
orddcm_constraint_names |
Public |
orddcm_document_refs |
Administrators only |
orddcm_document_types |
Public |
orddcm_documents |
Public |
Administrators can use the orddcm_document_refs information view to see the list of documents that are referenced by other documents in the repository. This read-only information view is available to administrators only. (See orddcm_document_refs.)
In addition, administrators (and other users) can use the orddcm_documents view to see the list of details about the documents stored in the repository. They can also use the orddcm_document_types view, which identifies the supported Oracle Multimedia DICOM document types by providing the list of codes for the document types. These public information views are read-only. (See orddcm_documents and orddcm_document_types.)
Two other public information views are available. The orddcm_constraint_names view lists the names of the constraints installed in the repository. In addition, the orddcm_conformance_vld_msgs view lists the constraint messages generated during constraint validation only for the schema that belongs to the user. (See orddcm_constraint_names and orddcm_conformance_vld_msgs.)
Administrators commonly use the orddcm_documents, orddcm_document_types, and orddcm_document_refs views when inserting, updating, and deleting documents from the repository.
Before exporting documents from the repository (and possibly before making any changes to the configuration documents), administrators should perform the following tasks:
Call the setDataModel( ) procedure at the beginning of each database session to load the repository from the database into memory structures. Locking the repository at this point is not required.
Administrators (and other users) can also call this procedure whenever the application requires the new data model changes.
See Chapter 4 for reference information about the setDataModel( ) procedure.
Obtain copies of the existing documents in the repository, using either the getDocumentContent( ) function or the exportDocument( ) procedure.
The getDocumentContent( ) function returns the specified document as data type XMLType.
The exportDocument( ) procedure writes the contents of the specified document to a specified file in a directory for which the administrator has been granted the write privilege.
See Chapter 10 for reference information about the getDocumentContent( ) function and the exportDocument( ) procedure.
The process of inserting documents into the repository can involve the use of these procedures:
editDataModel( )
insertDocument( )
publishDataModel( )
rollbackDataModel( )
See Chapter 10 for reference information about these procedures. See Chapter 11 for an example of the insertion process.
The following subsections briefly describe the insertion process for different types of documents.
For anonymity documents and mapping documents, the order of insertion is irrelevant. For constraint documents, however, the order of insertion is important. If there are dependencies among any of the constraint documents to be inserted, insert the documents without dependencies first. Then, insert the remaining documents.
Inserting standard or private dictionary documents requires merging all dictionary attributes each time a new dictionary document is inserted, in accordance with the following rules:
Attribute tags must be unique, and must not match existing wildcard tags.
Attribute tags must not be used in other document types.
In addition, for private dictionary documents, attribute tags must not be included in any existing range tags.
Note:
Oracle recommends limiting insertions of standard dictionary documents to reflect changes or additions to the DICOM standard only.See the XML schemas ordcmsd.xsd
and ordcmpv.xsd
in Appendix B for more information about DICOM attributes and attribute tags in dictionary documents.
Administrators can insert user-defined preference documents into the repository to include custom values for specified parameters. In addition, administrators can insert user-defined UID definition documents to add new private UID values, or to reflect updates in the DICOM standard.
To insert a user-defined preference or UID definition document, follow these steps:
Export the installed, Oracle-defined document and rename it.
Update the exported, renamed document, changing the parameter values as required.
Insert the updated user-defined document into the repository.
If a user-defined preference or UID definition document is later deleted, the Oracle-installed document is reapplied.
Note:
Only one user-defined preference or UID definition document is permitted in the repository.Administrators can use the generateTagListDocument( ) function to create a stored tag list document, which is a list of the attribute tags used in a specified set of mapping and constraint documents in the repository.
The stored tag list document is an optional XML document that specifies the DICOM attributes to be extracted from the embedded DICOM content and stored in the XML metadata attribute of the ORDDicom object when the setProperties( ) method is called. Generally, stored tag list documents contain the attribute tags used in mapping and constraint documents.
See Chapter 10 for reference information about the generateTagListDocument( ) function. See Chapter 11 for an example of the stored tag list document insertion process.
The process of updating documents in the repository can involve the use of these procedures:
editDataModel( )
exportDocument( )
deleteDocument( )
insertDocument( )
publishDataModel( )
rollbackDataModel( )
See Chapter 10 for reference information about these procedures. See Chapter 11 for an example of the update process.
The following subsections briefly describe the update process for different types of documents.
Updating anonymity documents, mapping documents, and constraint documents involves a similar set of actions. For both anonymity documents and mapping documents, follow these steps:
Export the existing document.
Edit the exported document.
Delete the existing document.
Insert the edited document.
Constraint documents are updated in reverse order from their insertion order. In addition, if there are dependencies among any of the constraint documents to be updated, update the documents with no dependencies first. Then, update the remaining documents.
Updating standard or private dictionary documents requires checking the attribute tags and dependencies with other documents in the repository. Standard and private dictionary documents can be updated only if no other documents are using the attribute tags that are defined in the new documents. To update the attribute tags that are being used by other documents, first update the dependent documents to remove the referenced attribute tags. Then, update the dictionary tags in accordance with the following rules:
Attribute tags must be unique, and must not match existing wildcard tags.
Attribute tags must not be used in other document types.
In addition, for private dictionary documents, DICOM attribute tags must not be included in any existing range tags.
Note:
Oracle recommends limiting updates of standard dictionary documents to reflect changes or additions to the DICOM standard only.See the XML schemas ordcmsd.xsd
and ordcmpv.xsd
in Appendix B for more information about DICOM attributes and attribute tags in dictionary documents.
To update existing user-defined preference documents or UID definition documents, follow these steps:
Export the user-defined document.
Edit the exported document.
Delete the existing user-defined document.
Insert the edited document.
Note:
UID values defined by Oracle or the DICOM standard must not be changed.The process of deleting documents from the repository can involve the use of these procedures:
editDataModel( )
exportDocument( )
deleteDocument( )
publishDataModel( )
rollbackDataModel( )
Use the exportDocument( ) procedure to save a copy of an original document before deleting it from the repository.
Only user-defined documents can be deleted. Documents installed by Oracle are default documents that cannot be removed. Additionally, to ensure conformance with referenced constraints, remove documents in the reverse order from the order in which they were loaded.
See Chapter 10 for reference information about these procedures. See Chapter 11 for an example of the deletion process.
The following subsections briefly describe the deletion process for different types of documents.
For anonymity documents and mapping documents, the order of deletion is irrelevant. Constraint documents, however, must be deleted in reverse order from their insertion order.
Deleting standard or private dictionary documents requires checking dependencies with other documents in the repository. For example, a user-defined dictionary document can be deleted only if no other documents reference it.
When a user-defined preference document is deleted, the values of the preference parameters revert to the installed values from the default Oracle-defined preference document (ordcmpf.xml
). Similarly, when a UID definition document is deleted, the UID values revert to the installed values from the default Oracle-defined UID definition document (ordcmui.xml
).
Export and import using Oracle Data Pump is described in Oracle Database Utilities. This section provides guidelines and examples for using the Oracle Data Pump commands expdp
and impdp
to perform export and import operations on the DICOM data model repository, which is stored in the ORDDATA schema. Do so only if you have made changes to your data model repository.
See Oracle Database Utilities for more information about Oracle Data Pump and its command-line clients, expdp
and impdp
.
Caution:
Because the tables in the ORDDATA schema can change with each database release, Oracle Data Pump Export and Import utilities for the ORDDATA schema are supported within the same database release only.These examples use the commands expdp
and impdp
. After you enter the command with your user name and the appropriate parameters, you are prompted for a password. The examples in this section do not show these prompts.
Note:
To export documents in the data model repository into a ZIP file, use the exportDataModel( ) procedure in the ORD_DICOM_ADMIN package. (See the exportDataModel( ) Procedure for reference information.)To perform export and import operations on the ORDDATA schema, administrators must have these roles, respectively:
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE
See Oracle Database Utilities for more information about the required roles for the Oracle Data Pump Export and Import utilities.
Export and import operations for Oracle Multimedia are supported in the following modes:
Schema (recommended)
Full
The following subsections describe these modes for export and import operations.
Use schema mode to export the DICOM data model repository in the ORDDATA schema.
Example 9-2 shows how to perform a schema mode export.
Example 9-2 Schema Mode Export
expdp SCHEMAS=ORDDATA CONTENT=ALL DIRECTORY=DUMP_DIR DUMPFILE=exp_orddata.dmp LOGFILE=exp_orddata.log
Example 9-2 defines the following parameters and values:
SCHEMAS=ORDDATA
: This parameter specifies the schema to export. There is no default value.
CONTENT=ALL
: This parameter specifies what to export. The default value ALL indicates that data and metadata are to be exported.
DIRECTORY=DUMP_DIR
: This parameter specifies the default location for the dump file and the log file. The directory DUMP_DIR
must already exist, and you must have access to it.
DUMPFILE=exp_orddata.dmp
: This parameter specifies the name of the dump file for the export job.
LOGFILE=exp_orddata.log
: This parameter specifies the name of the log file for the export job.
Note:
This operation does not export the corresponding metadata schemas, which are associated with any user-defined mapping documents in the ORDDATA schema. Without these metadata schemas, the data model repository is incomplete. (See Section 9.2.2 for information about how to find these schemas.)See Oracle Database Utilities for more information about schema mode export.
No recommendations apply for the ORDDATA schema.
See Oracle Database Utilities for more information about full mode export.
Use schema mode to import configuration documents into the DICOM data model repository.
Example 9-3 shows how to perform a schema mode import.
Example 9-3 Schema Mode Import
impdp SCHEMAS=ORDDATA CONTENT=ALL TABLE_EXISTS_ACTION=REPLACE DIRECTORY=DUMP_DIR DUMPFILE=exp_orddata.dmp LOGFILE=imp_orddata.log
Example 9-3 defines the following parameters and values:
SCHEMAS=ORDDATA
: This parameter specifies the schema to import. There is no default value.
CONTENT=ALL
: This parameter specifies what to import. The default value ALL indicates that data and metadata are to be imported.
TABLE_EXISTS_ACTION=REPLACE
: This parameter specifies what to do if the table already exists. Oracle supports only the value REPLACE
.
DIRECTORY=DUMP_DIR
: This parameter specifies the default location for the dump file and the log file. The directory DUMP_DIR
must already exist, and you must have access to it.
DUMPFILE=exp_orddata.dmp
: This parameter specifies the name of the dump file for the import job.
LOGFILE=imp_orddata.log
: This parameter specifies the name of the log file for the import job.
Note:
This operation does not import the corresponding metadata schemas, which are associated with any user-defined mapping documents in the ORDDATA schema. Without these metadata schemas, the data model repository is incomplete. (See Section 9.2.2 for information about how to find these schemas.)This operation generates several errors; however, this behavior is expected because the metadata already exists.
See Oracle Database Utilities for more information about schema mode import.
Oracle recommends using the following parameter setting to import the ORDDATA schema: TABLE_EXISTS_ACTION=REPLACE
. If this setting does not apply to a full database import operation, Oracle recommends using the following two-step process:
Exclude the ORDDATA schema from the full import operation (see Oracle Database Utilities).
Perform a schema mode import of the ORDDATA schema with the supported setting for the parameter TABLE_EXISTS_ACTION
(see Example 9-3).
See Oracle Database Utilities for more information about full mode import.