Skip Headers
Oracle® Multimedia DICOM Developer's Guide
11g Release 2 (11.2)

Part Number E10778-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

F Migrating from Release 10.2 DICOM Support

This appendix describes two options for migrating data and application code from DICOM support (in ORDImage objects) in 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:

This appendix includes these sections:

F.1 Using the DICOM Relational Interface to Migrate Applications

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:

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:

  1. Leave your data in ORDImage columns.

  2. Use ORDImage methods to access ORDImage functions, as you did in Release 10.2.

  3. 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.

F.2 Copying Data and Rewriting Applications for DICOM

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:

Use this migration option as follows:

  1. 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.

  2. 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.

See Also:

Oracle XML DB Developer's Guide for more information about XMLType operations

F.3 Choosing a Migration Option

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.