Personal tools
You are here: Home Forums Public Forum Using Oracle 10g XML DB for MPEG-7 Storage

Using Oracle 10g XML DB for MPEG-7 Storage

by renzel last modified Feb 18, 2008 10:46 AM
Up to Public Forum

Using Oracle 10g XML DB for MPEG-7 Storage

Posted by renzel at February 22. 2007
This article describes experiences a colleague and I made with Oracle 10g v2 during the process of creating an XML Index over subelements of an XMLType column storing MPEG-7 documents. All attempts until now failed and we tried to track down what might be the problem. In the end we came to the conclusion that the concept of XML schema type inheritance and its frequent use in the MPEG-7 schema might be the reason for the problem. In the following I'll describe our particular scenario and sum up the steps we took until we arrived in the current dead end. The scenario is the following: We are using Oracle 10g v2. Data is stored in Oracle as XML Documents conforming to the MPEG-7 XML Schema. The following excerpt from the original MPEG-7 XML schema will be sufficient to illustrate our problem. One fact derived from the above schema excerpt is that a Description element is of the abstract type ContentDescriptionType. An instance will need to use one of the non-abstract types derived from ContentDescriptionType, e.g. ContentEntityType using the xsi:type attribute as usual. The following is an excerpt of an MPEG-7 document as we use it in our project: http://somesite.org/someimage.jpg K1 K2 Kn The first step we took was to register the MPEG-7 schema to Oracle. A first attempt failed because of the size of the MPEG-7 schema. Oracle reported that there was not enough shared pool memory available to register the whole schema. We tried to raise the shared pool memory by changing the Oracle initialization configuration init.ORA, but still we got the same error. Thus, we had to somehow reduce the size of the schema in order to be able to register it in the end. In our case this was not too much of a problem, because a typical document as we use it only makes use of ca. 30% of the types resp. elements defined in the original schema. Thus, we could create a valid sub-schema by throwing out all superfluous type- resp. element definitions. Finally we were able to register the schema. The next step was to create appropriate tables storing MPEG-7 XML documents in XMLType columns and an an index over collections of subelements of the Mpeg7 root element. In our case we wanted to index all Keyword elements, that are reachable using the following XPath expression: declare namespace mpeg7="urn:mpeg:mpeg7:schema:2001"; /mpeg7:Mpeg7/mpeg7:Description/mpeg7:MultimediaContent/mpeg7:Image/mpeg7:TextAnnotation/mpeg7:KeywordAnnotation/mpeg7:Keyword Because the result of such an XPath expression is a collection of Keywords, we decided to use Oracle's concept of structured storage using nested tables. The Oracle XML DB Developer Guide proposed to use an SQL statement like the following: CREATE TABLE media_image OF XMLType XMLSCHEMA "http://www.mpeg7.org/Mpeg7.xsd" ELEMENT "Mpeg7" VARRAY "XMLDATA"."Description"."MultimediaContent"."TextAnnotation"."KeywordAnnotation"."Keyword" STORE AS TABLE keyword_table ((PRIMARY KEY (NESTED_TABLE_ID, SYS_NC_ARRAY_INDEX$)) ORGANIZATION INDEX OVERFLOW) On the execution of the above statement Oracle always returns error ORA22809. The error description is the following: ORA-22809: nonexistent attribute Cause: An attempt was made to access a non-existent attribute of an object type. Action: Check the attribute reference to see if it is valid. Then retry the operation. After that we tried the same statement like the above, but with a shorter path. Any path longer than up to the Description element resulted in the same error. A path only up to the Description Element worked without any problems. CREATE TABLE media_image OF XMLType XMLSCHEMA "http://www.mpeg7.org/Mpeg7.xsd" ELEMENT "Mpeg7" VARRAY "XMLDATA"."Description" STORE AS TABLE description_table ((PRIMARY KEY (NESTED_TABLE_ID, SYS_NC_ARRAY_INDEX$)) ORGANIZATION INDEX OVERFLOW) Our assumption is now that our problem results from the use of type inheritance in the MPEG-7 XML schema. The element Description is - according to the schema - defined to be of type ContentDescriptionType. This type does not define an attribute (resp. subelement) MultimediaContent. Such an attribute is defined later in a derived type ContentEntityType. It seemed to us that in such a setting, Oracle must have problems choosing the right subtype, that defines the attribute MultimediaContent, since this choice is in most cases non-deterministic, if not undecideable. We are now in contact with the Oracle XML DB support... to be continued...

Re: Using Oracle 10g XML DB for MPEG-7 Storage

Posted by Viral Desai at December 26. 2007
Hi- I have been looking for a solution to a similar problem with XDB for version 10.2.0.2, and I have tried this on version 11, both on linux platform. My schema uses inheritance and I get the same error message. Have you had any success related to this problem? Any information that you may have would be much appreciated. Thanks, -Viral

Re: Using Oracle 10g XML DB for MPEG-7 Storage

Posted by renzel at February 18. 2008
Viral, first of all sorry for not answering for such a long time. Honestly, I didn't expect that somebody would answer to this totally ill-formatted article. Obviously, I was wrong...;) Now to your question: We continued our experiments for a couple of more days and tried to get rid of type inheritance by "flattening out" the inheritance hierarchy, i.e. by copying element and attribute definitions from supertypes into all subtypes. Of course, this approach is quite awkward and not satisfying at all. First, the schema gets even more bloated than it already is. Second, the flattening steps were sometimes not applicable and/or yielded a schema that was not completely equivalent to the original. However, we finally managed to create some index for a "tainted" schema version, but also started experiments with the same set of testdata on the new native XML Storage of IBM DB2 9.1 (now 9.2) in parallel. The results were a lot more satisfying than all the hassle with Oracle. Even without creating any special kind of index IBM DB2 was much faster and stable. As a consequence we totally dropped Oracle. So, my recommendation would be to try IBM DB2 >=9.2 (if you haven't already tried...). Best regards from Aachen, Dominik
Powered by Ploneboard
Document Actions