Oracle® Multimedia DICOM Developer's Guide 11g Release 2 (11.2) Part Number E10778-01 |
|
|
View PDF |
This appendix describes two options for migrating data and application code from DICOM support (in ORDImage objects) from Oracle Database 10g Release 2 (10.2) to the new DICOM support in Oracle Database 11g Release 1 (11.1). The first migration option has less impact on existing applications. The second migration option takes full advantage of the new DICOM features.
The examples in this appendix are based on the table imageTable
, which is defined as follows:
imageTable( id integer, image ordsys.ordimage, thumb ordsys.ordimage
where:
image: the name of the ORDImage column.
thumb: the name of the thumbnail image column.
This appendix includes the following sections:
You can leave the data in the original ORDImage objects and use the new DICOM relational interface to access the new DICOM functions.
The advantages of using this migration option are as follows:
You can migrate your applications quickly, and with minimal impact to your existing Oracle Database 10g Release 2 application.
You do not have to copy your existing DICOM content.
The only disadvantage of using this migration option is that the DICOM relational interface does not take full advantage of the new DICOM features. Use the migration option explained in Section F.2 to take full advantage of the new DICOM features.
Use this migration option as follows:
Leave your data in ORDImage columns.
Use ORDImage methods to access ORDImage functions, as you did in Release 10.2.
Use the new ORD_DICOM relational package to access new DICOM features.
The following code segment shows this process, using ORDImage objects to store DICOM content.
alter table imageTable add (meta sys.xmltype); declare img ordsys.ordimage; thb ordsys.ordimage; ctx raw(64) := null; meta sys.xmltype; begin insert into imageTable (id,image, thumb) values (1, ordsys.ordimage.init(), ordsys.ordimage.init()) returning image, thumb into img, thb; img.importFrom(ctx, 'file', 'DICOMDIR', 'example.dcm'); img.processCopy('fileFormat = jfif maxScale=100 100', thb); meta := ORD_DICOM.extractMetadata(img.getContent, 'ALL'); . . .
In this segment, the first two lines of code highlighted in bold show how to modify the ORDImage table (imageTable
) by adding a column to store DICOM metadata as an XML document. The last line of highlighted code shows the use of the extractMetadata( ) method in the ORD_DICOM package (relational interface) to extract all attributes of the embedded DICOM content.
You can copy data into the ORDDicom object type and rewrite your application to use ORDDicom methods. Using this migration option enables you to take full advantage of the features of the new ORDDicom object type.
The disadvantages of using this migration option are as follows:
You must copy your existing DICOM content into an ORDDicom object type.
You must rewrite the parts of your application that access Oracle Multimedia.
Use this migration option as follows:
Copy your data into ORDDicom objects, as shown in the following code example:
alter table imageTable add (dicomImage ORDSYS.ORDDicom, metadata sys.XMLTYPE); -- For each row update imageTable t set t.dicomImage = new orddicom(t.image); alter table imageTable drop column image;
Assuming that you have an existing table (imageTable
) with an ORDImage column (image
), this example adds a DICOM image column (dicomImage
) to store DICOM content as type ORDDicom, adds a metadata column (metadata
) to store extracted attributes as an XML document, updates the table by copying the new DICOM content from the image
column into the dicomImage
column, and then removes the image
column from the table.
Modify your application to use the new ORDDicom methods, as shown in the following code segment:
declare img ordsys.orddicom; thb ordsys.ordimage; meta sys.xmltype; begin insert into imageTable (id, dicomImage, thumb, metadata) values (1, ordsys.orddicom('file', 'DICOMDIR', 'example.dcm', 1), ordsys.ordimage.init(), null)) returning dicomimage, thumb into img, thb; img.processCopy('fileFormat=jfif maxScale=100 100', thb); meta := img.extractMetadata('ALL'); . . .
This segment shows an existing application that has been changed to use the new ORDDicom object type. The first two lines of code highlighted in bold show variable declarations for the ORDDicom object (img
) and the XMLType metadata (meta
). The next line of highlighted code shows how to insert a row into a table with an ORDDicom object pointing to a DICOM file in the local file system. The next line of highlighted code is similar to the syntax for Oracle Database 10g Release 2, and shows how to generate a JPEG thumbnail image from a DICOM image. The last line of highlighted code shows how to extract all attributes in the embedded DICOM content into an XML document.
Determining whether to migrate your application by using either the new DICOM relational interface or the new ORDDicom object type depends on your situation and the kinds of applications that exist in your environment. For example, if you have extensive data and limited resources, the migration option of copying your existing DICOM content into an ORDDicom object type might prove too costly and inconvenient. Instead, you might choose to forego the new DICOM features in favor of speedily migrating your application, with limited impact on the existing data. In contrast, if you have limited data in ORDImage objects, you might choose to rewrite your applications and copy your existing data into the ORDDicom object type to enable access to all the new DICOM features.