JP2006053724A - Xml data management method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a transparent structure retrieval function while optimizing an MXL document-relational table schema mapping definition. <P>SOLUTION: A mapping definition tuning module 105 refers to issuing history of a structure retrieve formula to change a schema-to-schema mapping definition 109 so that an XML document is properly divided and stored in a relational database 105 and a structure retrieval engine 106 for the purpose of enhancing the efficiency of retrieval processing with high issuing frequency. A structure retrieval formula conversion module 102 converts the structure retrieval formula based on the schema-to-schema mapping definition 109. A query execution control module 103 issues queries to the relational database 105 and the structure retrieval engine 106, respectively, and reconstitutes a result for the original structure retrieval formula from the respective results. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a database management system. In particular, the present invention relates to an XML (extensible Markup Language) document management method using a relational database (or relational database, hereinafter referred to as RDB), and more particularly to a method of managing one XML document by decomposing it into an XML structure search engine and RDB. In particular, the present invention relates to a method for providing a structure search interface that is transparent to a user while improving the decomposition method as appropriate based on a search history for the document.

  Currently, there are several products called Native XML Database (NXDB) that specialize in managing XML documents. However, all NXDBs are in the process of development and generally are insufficient in performance for the purpose of managing a large amount of data and a totaling process, and are therefore not suitable for mission-critical tasks. Since the development of business-related XML specifications such as XBRL (extensible Business Reporting Language) is expected for the basic business application of XML, technology capable of processing a large amount of XML documents with sufficient performance is required. ing. On the other hand, XML document management functions are also provided in main RDB products. RDB provides performance that can withstand the processing of large amounts of data due to improvements over many years, so it can be said that RDB is also suitable for XML mission-critical business applications.

  Non-Patent Document 1 and Non-Patent Document 2 describe typical XML document management methods related to main RDB products.

  According to the method of Non-Patent Document 1, the tagged data included in the XML document is structurally decomposed according to the correspondence between the document schema of the XML document to be managed and the relation table schema of the RDB, and a plurality of data is decomposed. Store in value units by dividing into relational tables. Such a storage method is hereinafter referred to as an XML document schema-relational table schema mapping method. The method of Non-Patent Document 1 is based on the definition of an XML document schema, defines a relation table schema for storing an XML document valid for the definition, and between the XML document schema and the relation table schema. The correspondence definition (hereinafter referred to as schema mapping definition) is automatically created. In addition, a structure search expression in the XML standard search specification XPath format is automatically converted into a relational table search expression (hereinafter referred to as an SQL expression) in accordance with the schema mapping definition.

  The method of Non-Patent Document 2 is also basically a schema mapping method. However, the schema mapping definition is manually defined by the user in the direction of constructing an XML document from data stored in the RDB. In addition, a structure search expression in the XML standard search specification XQuery format is automatically converted into an SQL expression according to the schema mapping definition.

Store ML Schemas in Oracle XML DB R. Murthy, S, Banerjee; VLDB2003 轍 uerying XML Views of Relational Data J. Shanmugasundaram, et al., VLDB2001

In general, XML document management in the RDB is based on a system in which tagged data included in an XML document is structurally decomposed and divided into a plurality of relational tables and stored in units of values. The schema mapping method between the XML document schema and the relational table schema has the following disadvantages in managing the XML document:
(A) Mapping definition in consideration of search efficiency Generally, the search performance varies depending on the mapping method. In order to obtain optimum search performance, tuning of the mapping definition is necessary, but this work is a heavy burden for the user.
(B) Management of atypical data In XML, it is possible to include atypical partial data that does not conform to a strict schema definition in a document, and the flexibility of data representation due to this becomes a major factor in expanding the use of XML. However, in RDB, such data is managed as one-dimensional character string data called LOB, so that it is not possible to perform an advanced search for that portion.
(C) Management of a document having a complicated structure In XML, a complicated data structure can be expressed by a data model based on a tree structure. On the other hand, since the relational table manages data in units of one-dimensional values, complicated data such as a tree structure must be expressed by an external reference relationship between a plurality of relational tables. However, when the XML document schema has a deep hierarchy, the XML document schema is managed by dividing it into a large number of relational tables, which is undesirable in terms of search efficiency and storage efficiency. As described above, there is an XML document that is inefficiently managed in the relational table based on the difference in data model between RDB and XML.
(D) Retrieval designation method Retrieval for an XML document schema-mapped to a relational table needs to be defined according to the mapping definition. Therefore, the user is aware of the mapping definition and the relational table retrieval expression (hereinafter, SQL expression). Need to be described. Further, when the mapping definition is changed in consideration of the search efficiency as described in the problem (a), it is necessary to rewrite the SQL expression. In general, it is ideal for a user to be able to specify a structure search in consideration of only the XML document schema, and these necessitys that do not exist in the management of an XML document are very burdensome for the user.

  In order to overcome the disadvantages (a) to (d) in the schema mapping scheme between the XML document schema and the relational table schema, the present invention aims to solve the following problems.

  First, provide an automatic tuning function for schema mapping definitions.

  Second, to provide a structure search function for atypical partial data that has been managed by LOBs.

  Third, data that is inefficient in the management of relational tables should be isolated and managed by efficient means.

  Fourthly, a transparent XML document structure search function is provided with respect to a method for storing XML documents in a relational table.

  First, in order to solve the second and third problems, it cooperates with an RDB external database or an XML structure search engine that exists as an RDB plug-in.

  Conventionally, the atypical partial data stored in the LOB column of the relational table is stored in the structure search engine, thereby solving the second problem. The third problem is solved by managing inefficient data in the relational table with the structural search engine instead.

  In order to solve the first problem, a mapping definition tuning module that refers to the query issuance history and derives an appropriate schema mapping definition by using the retrieval performance efficiency of frequent queries as an index is introduced. This module also separates XML partial data that is inappropriately managed in the relationship table in the third problem solving.

  Furthermore, in order to solve the fourth problem, a query rewrite function for automatically converting a structure search expression for an XML document into an SQL expression based on a schema mapping definition is provided. When the search target extends to partial data managed by the structural search engine, the search target is converted into an SQL expression that includes a search expression for the search engine as a UDF (User Define Function). By this query rewrite, the user can transparently specify the structure search with respect to the difference between the XML document relation table and the structure search engine storage method in the first to third problem solving.

In the schema mapping method between the XML document schema and the relation table schema,
(1) Based on the query issuance history, the schema mapping definition can be automatically improved so as to reduce the search processing cost.
(2) By managing the atypical partial data with the structural search engine, a structural search for the partial data can be performed.
(3) It is possible to avoid inefficient search processing by separating data that is inefficiently managed in the relational table and managing it with the structural search engine.
(4) With the query rewrite function, it is possible to transparently specify the structure search for the XML document regarding the relation table of the XML document and the storage method in the structure search engine.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. For the sake of simplicity, an embodiment of the invention described below will be simply referred to as “this example” in the present specification.

  A schematic configuration of the present embodiment will be described with reference to FIG.

The system of the present embodiment is composed of the following four modules as basic components:
Tagged structured document-relational table data conversion module 101
Structure search expression conversion module 102
-Query execution control module 103
Mapping definition tuning module 104
The following outlines each module.

  The tagged structured document-relationship table data conversion module 101 converts a tagged structured document (hereinafter referred to as an XML document) 107 into a relational database (hereinafter referred to as RDB) 105 from a data body obtained by structurally decomposing and removing the tag. Store attribute values corresponding to the columns of the relationship table. However, some XML documents are stored in the structure search engine 106 dedicated to the XML document in units of subtrees with tags. Among the XML documents, the distinction between the part stored in the RDB 105, the relation table column of the storage destination, and the part stored for each tag in the structure search engine 106 is a tagged structured document schema definition (hereinafter referred to as an XML document structure definition) 108. , The mapping definition between schemas 109, and the relation table schema definition 110.

  The XML document structure definition 108 represents the structure definition of the XML document, and the relation table schema definition 110 represents the schema definition of the relation table. The XML document 107 needs to be valid with respect to the XML document structure definition 108, and the relationship tables 201 and 202 stored in the RDB 105 are configured according to the relationship table schema definition 110. The inter-schema mapping definition 109 defines a correspondence between a node value (an element value or an attribute value modified with a tag) of an XML document and a relation table column storing the node value.

  The structure search expression conversion module 102 converts a structure search expression 111 defined by the user in accordance with an XML standard search specification such as XQuery or XPath into a SQL language search expression (hereinafter referred to as an SQL expression) 112 which is a search specification for the RDB 105. This is the module to convert. This conversion is performed according to the inter-schema mapping definition 109. If the search range extends to the partial XML document stored in the structural search engine, the SQL expression 112 is converted into an expression in which an extended function (UDF) for the structural search engine is embedded.

  The query execution control module 103 separates the SQL expression 112 including the UDF into an SQL part and a UDF part, issues the former to the RDB 105 and the latter to the structural search engine 106, and integrates the results to obtain the original This is a module for constructing a result 113 for the structure search formula 111. When the RDB 105 has a plug-in processing mechanism, this module is naturally realized on the function (this case will be described later with reference to FIG. 3).

  The mapping definition tuning module 104 refers to the issuance history of the structure search formula 111 of the user, and refers to the XML document structure definition 108 by using the efficiency of processing of the frequently used search formula as an index. The relation table schema definition 110 is updated as appropriate. The change of the relation table accompanying the update of the relation table schema definition 110 is left to the function of the RDB 105.

  Hereinafter, a hardware configuration for realizing the system shown in FIG. 1 will be described. This system is configured by one or a plurality of computers including a CPU, a memory, an external storage device, an input device, a display device, and the like in hardware. The XML document 107, the XML document structure definition 108, the inter-schema mapping definition 109, and the relation table schema definition 110 are stored as files on the storage device. The structure search formula 111 is input from an input device via a text editor or generated via an application program (not shown) and stored in a memory. The result 113 is data stored in the memory and output to a display device or a printer, or passed to an application for further processing. The structure search engine 106 has a tree structure file of an XML document stored in a storage device, and is a database management system for managing these files. The tagged structured document-relational table data conversion module 101, the structure retrieval formula conversion module 102, the query execution control module 103, and the mapping definition tuning module 104 are programs stored in the memory of a computer and executed by the CPU. . The RDB 105 has a relational database stored on a storage device, and is a database management system for managing this database. A part or all of the data conversion module 101, the structure search expression conversion module 102, the query execution control module 103, and the mapping definition tuning module 104 may be incorporated in the RDB 105 and implemented. These modules, RDB 105, and structure search engine 106 may be executed on the same computer, or a part or all of them may be executed on different computers via a network. The system may be realized by a client-server type system.

  The above is the outline of the present embodiment. Hereinafter, the operation outline of the data conversion module 101 in this embodiment is shown in FIG. 2, the operation outline of the structure search expression conversion module 102 is shown in FIG. 3, and the operation outline of the query execution control module 103 is shown in FIG. This will be described with reference to FIGS.

The operation of the data conversion module 101 will be described with reference to FIG. In this description, an example is described in which an XML document 107 that is valid for the XML document structure definition 108 is stored in the RDB 105. In the XML document structure definition 108, a plurality of i elements appear under the root element x, each i element has attributes a and b, and a plurality of j elements appear below it, and each j element has an attribute. It has a, b, c, and a plurality of k elements appear below it, indicating that each k element has attributes a, b. str indicates a character string. X0... N indicates that 0 to n corresponding elements can appear. Also, {ANY} indicates that any element other than the k element can appear under each j element. Note that the notation of the XML document structure definition 108 in FIG. 2 does not limit the embodiment, and any notation is applicable as long as the XML document structure definition specification can express the same meaning. For example, in DTD (Document Type Definition) which is a standard document structure definition specification of an XML document, a document structure definition similar to the above is expressed as follows:
<! ELEMENT x i *>
<! ELEMENT i j *>
<! ATTLIST i
a CDATA #REQUIRED
b CDATA #REQUIRED>
<! ELEMENT j ANY>
<! ATTLIST j
a CDATA #REQUIRED
b CDATA #REQUIRED
c CDATA #REQUIRED>
<! ELEMENT k EMPTY>
<! ATTLIST k
a CDATA #REQUIRED
b CDATA #REQUIRED>
On the other hand, the schemas of the relationship tables 201, 202, and 203 that store the XML document 107 are given by the relationship table schema definition 110. In this example, the relation table i has three columns a, b and id, the relation table j has six columns pid, a, b, c, w and id, and the relation table k has pid, a, b and id. It expresses having 4 columns of id. Here, id and pid are identifiers indicating the connection between the parent and the child. id is an identifier having itself as a parent, pid is an identifier provided in a child, and is an identifier indicating which parent is connected. When id and pid are the same, it indicates that there is a parent-child connection. The notation of the relation table schema definition 110 in FIG. 2 does not limit the embodiment, and any notation can be applied as long as the definition specification of the relation table schema can express the same meaning. For example, since the schema of the relation table is generally defined at the time of creating the table using an SQL expression, the SQL expression can be used as the relation table schema definition 110.

  Based on the XML document structure definition 108 and the relation table schema definition 110 described above, an inter-schema mapping definition 109 defines the association of values between the two definitions. “/X/i/@a⇔i.a” on the first line expresses that the value of the attribute “a” of the i element of the XML document 107 is stored in the column “a” of the relation table i (201). . The same applies to the second, fourth, fifth, sixth, eighth and ninth lines. “/ X / i / j /... J.pid = i.id” in the third row indicates the parent of the j element by the column pid of the relation table j (202), and the column of the relation table i (201). It expresses that id is externally referenced. Similarly, the seventh line expresses an external reference between the relation table k (203) and the relation table j (202). The tenth line indicates that the partial contents of the j element not defined in the XML document structure definition 108 are stored in the column w of the relation table j (202). However, the partial structure is actually stored in the structure search engine 106 for each tag, and only the file ID (xi-a in this example) assigned to the stored image 204 on the structure search engine 106 is a relation table. Stored in column w of j (202).

  The data conversion module 101 first secures each area of the relation table i, j, k in the storage area via the RDB 105 based on the relation table schema definition 110. Next, the data conversion module 101 extracts one of the i, j, k, or o elements from the XML document 107, and whether or not the format of the extracted element with reference to the XML document structure definition 108 matches the schema definition. To check. If the definition is met, the data conversion module 101 stores the attribute value of each attribute of the element extracted by referring to the inter-schema mapping definition 109 as one record of the corresponding relation table in the RDB, and the id and pid of the record Set. id is generated and set according to the record position of the relation table. If the id of the parent element stored in the memory is stored in pid, the id is stored. Next, the data conversion module 101 temporarily stores the element name of the element and its id in the memory. When the o element is extracted from the XML document 107, the data conversion module 101 recognizes that the element extracted with reference to the XML document structure definition 108 corresponds to ANY, and the structure is displayed in the column of the corresponding record in the relation table j. A file ID designated by the search engine 106 is set, and a partial structure in which a tag j is added to the extracted o element is sent to the structure search engine 106. The structure search engine 106 stores the received partial structure as a storage image 204 in the storage area. The data conversion module 101 returns to the step of extracting the next element from the XML document 107 until the extraction of all elements of the XML document 107 is completed, and repeats the above processing.

  The operation of the structure retrieval formula conversion module 102 will be described with reference to FIG. In this description, in accordance with the XML document structure definition 108, the inter-schema mapping definition 109, and the relation table schema definition 110 taken up in the example of FIG. The case where the structure retrieval formula 111 described according to the XQuery standard is processed with respect to the XML document 107 stored as the stored image 204 in the example 106 is taken as an example.

  The structure search formula 111 assigns the i element name to the variable $ i by the FOR clause. Therefore, in the WHERE clause, the attribute a of the i element is “xx19”, and the i element has a j element whose attribute b is “xx22” as a child element. It is conditional on having an o element such as xx24 ″ as a child element. Furthermore, it is required to acquire the entire i element extracted under the above conditions as a result.

  The structure search expression conversion module 102 refers to the schema mapping definition 109 and converts the structure search expression 111 having the above meaning into an SQL expression 112 including a structure designation UDF. According to the mapping definition 109, the meaning of the above search expression is that the condition is applied to the column a of the relation table i (201), the column b of the relation table j (202), and the column w of the relation table j (202). It is equivalent to specifying it. Since the o element is not defined as a child element of the j element, the 10th line of the mapping definition 109 is applied and becomes a condition for the column w of the relation table j (202). However, since this column is a reference to the image 204 stored in the structure search engine 106, this condition is expressed by a structure designation UDF.

  From the above, the query 112 obtained by converting the structure search formula 111 extracts a record in which the column a is “xx19” from the relation table i (201), and the column b is extracted from the record in the relation table j (202). A record is extracted such that “xx22” and the storage image (204) of the structural search engine 106 referred to in the column w includes an o element such that the value of the attribute u = “xx24”. It is generated as an SQL expression that specifies that the external reference relationship is established between both records. The structure designation for the column w of the relation table j (202) is expressed by UDF XMLHAS. This is a Boolean function that determines whether the stored image on the structure search engine 106 indicated by the value of the column specified by the first argument contains partial data that matches the XPath structural formula specified by the second argument. .

  Since the structure retrieval formula 111 requires that all i elements satisfying the above conditions are obtained as a result, the XML document construction UDF XMLVAL is specified in the SELECT clause of the SQL formula 112. This is a scalar function that extracts all descendant elements from the RDB 105 and the structure search engine 106 for the element whose ID is specified by an argument, and reconstructs and returns an XML document.

  The operation of the query execution control module 103 will be described with reference to FIGS.

  FIG. 3 shows a case where the RDB 105 has a plug-in processing mechanism 301. In this case, the function to be realized by the query execution control module 103 is incorporated in the RDB 105. Here, for the sake of explanation, a program that realizes this function alone is called a query execution control module, and is distinguished from the RDB 105 itself. The query execution control module 103 separates the SQL expression 112 including the UDF into a native SQL unit and a UDF unit, the RDB 105 processes the SQL unit, and the plug-in processing mechanism 301 processes the UDF unit. Since XMLHAS, which is a structure designation UDF, is actually processed by the structure search engine 106, it is issued to the engine as a structure search specification XPath query 302 supported by most structure search engines. However, when XMLHAS is realized as a plug-in built in the RDB 105, the structure designation UDF is directly executed on the RDB 105. XMLVAL, which is an XML document construction UDF, is also executed on the plug-in processing mechanism 301.

  When executing the query, the query execution control module 103 determines whether to narrow down the data first with the condition for the structure search engine 106 or narrow down the data with the condition for the relational table, using the processing efficiency of the query as an index.

  Taking the SQL expression 112 as an example, in the former case, first, the stored image 204 on the structure search engine 106 that conforms to the XMLHAS condition determination is extracted, and its ID (xi-a in this example) and the relation table j ( 202), the value of the column w matches, and the data is extracted from the relationship tables 201 and 202, including the condition.

  On the other hand, in the latter case, first, the column a of the relation table i (201), the column b of the relation table j (202), and the column id of the relation table i (201) and the column pid of the relation table j (202). The data is narrowed down by using the external reference relationship as a condition, and the condition determination by XMLHAS is performed on the storage image 204 on the structure search engine 106 indicated by the value of the column w of the record of the extracted relation table j (202).

  The determination of the query execution procedure as described above is optimized by an execution plan determination process provided in a general RDB 105. Therefore, when the RDB 105 including the plug-in processing mechanism 301 is used, it is not necessary to newly provide the query execution control module 103.

  On the other hand, an outline of operation when the RDB 105 does not include the plug-in processing mechanism 301 and the query execution control module 103 needs to be provided outside the RDB 105 will be described with reference to FIGS. 4 and 5. When the query execution control module 103 is newly provided outside the RDB 105, it is necessary to uniquely determine the query execution procedure as described above.

  With reference to FIG. 4, the case where data is first narrowed down by the conditions for the structure search engine 106 will be described. When the query execution control module 103 receives the SQL expression 112 including the UDF, the UDF separation process 401 in the module separates into the native SQL expression 403 and the UDF section. Next, the query execution control module 103 issues the UDF part as an XPath search expression 302 to the structure search engine 106 (circled number 1), and the ID of the storage image 204 including data matching this expression (in this example, xi− a) is acquired and stored in the RDB 105 as a temporary table x (404). Next, on the condition that the ID stored in the column w of the relation table j (202) is included in the temporary table x, the query execution control module 103 performs data from the relation tables 201 and 202 using the SQL expression 403. Is extracted (circled number 2). However, x in the SQL expression 403 means a temporary table x, and x. id means the id column of the temporary table x. As a result of the search based on the SQL expression 403, the query execution control module 103 receives i. Data “r02” is returned as the id.

  In this way, the tagged structured document reconstruction process 402 reconstructs the i element having the extracted ID from the data of the relational tables 201 to 203 and the stored image 204 of the structure search engine 106. For this reason, the tagged structured document reconstruction process 402 creates SQL expressions 405 to 407 that extract data from the relational table with reference to the inter-schema mapping definition 109 and issues these SQL expressions to the RDB 105. (Circled number 3). These are for extracting all descendant elements of the i element having the extracted ID “r02” based on the external reference relationship between the relationship tables. Here, “r02” is assigned to iid of the SQL expression 405. Nothing is substituted for jid, and as a result, the result of the SQL expression 407 is not returned. In the case of this example, the SQL expression 407 may be omitted. On the other hand, since the i element partially includes data of the stored image 204 stored in the structural search engine 106, the tagged structured document reconstruction process 402 executes a query 408 for acquiring the query 408 to obtain the structural image. Is issued (circled number 3 ') to obtain the stored image 204. The tagged structured document reconstruction process 402 refers to the XML document structure definition 108, the inter-schema mapping definition 109, and the relation table schema definition 110, reconstructs the XML document from the extracted data and the storage image 204, and obtains a result 113. Obtain (circled number 4).

  With reference to FIG. 5, the case where data is first narrowed down by the conditions for the relational tables 201 and 202 will be described. In this case, the UDF separation process 401 separates the SQL expression 112 including the UDF into a query like the native SQL expression 502. The query execution control module 103 issues this SQL expression to the RDB 105 (circled number 1), and narrows down the data according to the conditions for the relationship tables 201 and 202. At that time, the value of the column w of the relation table j (202) is also extracted at the same time. The query execution control module 103 performs i. id “r02”, j. The value “xi-a” is received as w. The structure determination processing 501 receives the result of the SQL expression 502, sends the storage image ID “xi-a” and the XPath expression 302 to the structure search engine 106 (circled number 2), and the stored image that matches these conditions is searched for the structure. It is determined whether or not it is registered in the engine 106. If there is data corresponding to the structure search engine 106, the storage image ID “xi-a” is passed to the structured document reconstruction process 402 with tag. The subsequent processing is the same as in the case of FIG.

  In the above description, the structure search expression conversion module 102 and the query execution control module 103 are distinguished from each other, but these may be realized as one module. In that case, it is obvious that there may be an embodiment in which the SQL expression 112 including the UDF is not generated and the structure search expression 111 is directly converted into the SQL expressions 403 and 502.

  Hereinafter, specific mapping definition improvement processing procedures performed by the mapping definition tuning module 104 according to the present embodiment will be described with reference to FIGS. 6, 7 (a), 7 (b), and 8.

  The mapping definition improving process when the search frequency for partial data not explicitly defined in the XML document structure definition exceeds a predetermined number will be described with reference to FIG.

  The system records the issuance history of the structure search formula for the tagged structured document in a search history database (not shown). The mapping definition tuning module 104 refers to the search history database and counts the frequency of issuing structure search formulas for the same UDF. Like the condition specification for the o element in the structure search formula 111 in the examples of FIGS. Mapping definition tuning module 104 automatically generates a relation table storing this part and a mapping definition.

  As a result of improvements over many years, the RDB search processing performance is faster than general structural search engines, and when considering specifying conditions simultaneously with other relational table data, the data is stored outside the RDB. Since it is more efficient to manage with a relational table as much as possible rather than a structural search engine, such a change in mapping leads to improved performance.

  In this example, the mapping definition tuning module 104 newly creates a relation table o (601) on the RDB 105, and defines an external reference relationship with the relation table j (202). At this time, the relation table schema definition 110 is changed to the relation table schema definition 603. The relation table o is defined as having four columns, columns pid, u, v, and id. At the same time, the inter-schema mapping definition 109 is changed to the inter-schema mapping definition 604. The mapping definition tuning module 104 deletes the description indicating that the undefined part existing in the 10th line of the mapping definition 109 is mapped to the structure search engine, and newly adds the relation table j and the relation table o to the 10th line. A description representing the reference relationship and a description representing the correspondence between each attribute of the o element and each column of the relationship table o are added to the 11th and 12th lines. Further, the mapping definition tuning module 104 changes {ANY} of the XML document structure definition 108 to <ou = “str” b = “str” /> × 0... N.

  Details of the processing procedure executed by the mapping definition tuning module 104 are as follows. The mapping definition tuning module 104 follows each definition record of the inter-schema mapping definition 109 and finds partial contents of elements not defined in the XML document structure definition 108. Next, the mapping definition tuning module 104 refers to the relation table schema definition 110 and acquires the relation table and column identifier defined in the partial contents. Next, the mapping definition tuning module 104 sends an SQL search expression to the RDB 105, and acquires an attribute value of the relation table and column position. Since the attribute value indicates the file ID of the structure search engine 106, the mapping definition tuning module 104 acquires the stored image 204 from the structure search engine 106. Next, the mapping definition tuning module 104 secures a storage area of the relation table o in the storage area via the RDB 105. Next, the mapping definition tuning module 104 extracts the o element from the stored image 204 in accordance with the processing procedure of the data conversion module 101 and creates the relation table o via the RDB 105. Next, the mapping definition tuning module 104 adds the definition of the relation table o to the relation table schema definition 110 and updates the relation table schema definition 110 to the relation table schema definition 603. Next, the mapping definition tuning module 104 adds the mapping definition for the relational table o to the inter-schema mapping definition 109 and updates the inter-schema mapping definition 109 to the inter-schema mapping definition 604. Next, the mapping definition tuning module 104 follows the definition sentence of the XML document structure definition 108, finds an undefined element, and replaces it with the definition of the o element. Next, the mapping definition tuning module 104 deletes the stored image 204 from the structure search engine 106.

  In the mapping definition to which the above changes are made, the structure search formula 111 is converted into the SQL formula 602 by the structure search formula conversion module 102. Since this SQL expression does not include the structure designation UDF, it is a desirable form for processing by the RDB 105.

  A processing procedure for realizing improvement of XML data management having a recursive structure will be described with reference to FIGS. 7A and 7B. As shown in FIG. 7A, the XML document 701 has a self-recursive structure that is valid for the XML document structure definition 702. That is, a plurality of j elements themselves appear as child elements of the j element. A method for storing such an XML document in a relation table is defined by an inter-schema mapping definition 703 and a relation table schema definition 704. The third line of the mapping definition 703 means that the parent of the j element is an i element or a j element, and the distinction is expressed by the value of the column prl (“i” or “j”) of the relation table j. Yes. There are two relation tables as the storage destination of the XML document 701, the relation table i (705) and the relation table j (706). The external reference relationship between the relation table i and the relation table j, and the relation table j Self-reference relationship is defined.

  On the other hand, the structure search expression 707 extracts a j element that appears in an arbitrary hierarchy as a descendant element of an i element whose attribute a value is “xx01” and whose attribute a value is “xx18”. Demands. In order to express this in an SQL expression, it is necessary to use a recursive query. The structure search expression 707 is converted into an SQL expression 708 by the structure search expression conversion module 102. This SQL expression is a recursive query that recursively follows the self-reference relationship of the relation table j (706) and extracts all descendants of the i element in the temporary table tmp.

  However, the recursive query of RDB is generally an inefficient process, and such a mapping definition is not preferable when such a structure search expression appears frequently.

  On the other hand, the XML partial data having a recursive structure is intentionally stored in the structure search engine 106 to improve. In general, a structural search engine is designed so that a search process can be performed with a reasonable performance even for deep data, and may be more efficient than managing with a relational table.

  The inter-schema mapping definition 709 shown in FIG. 7B deletes the description in which the j element on the 3rd to 6th lines in the inter-schema mapping definition 703 is associated with the relation table j (706), and 3 A description for storing all descendants of the i element in the structure search engine 106 is added to the line. In the relation table schema definition 710, a column w for storing the ID of the stored image in the structure search engine 106 is added to the relation table i (705).

  In the above mapping definition, the XML document 701 is decomposed and stored in the relationship table 705 and the storage images 711 and 712 of the structure search engine 106. The structure retrieval formula 707 is converted into an SQL expression 713 including UDF by the structure retrieval formula conversion module 102. The SQL expression 713 is a simple query that does not include recursion compared to the SQL expression 708, and appropriate use of the RDB 105 and the structure search engine 106 is achieved.

  Note that the above-described improvement method for changing an XML document that is inefficiently managed by the RDB 105 to be stored in the structure search engine can be applied to an XML document other than an XML document having a recursive structure. For example, when storing an XML document with a deep hierarchy in a relational table, a large number of relational tables are defined to define external reference relationships between them. Must add all the conditions of the external reference relationship to the SQL expression. Such a condition is not efficient because it is processed as a join operation with a high search cost in the RDB. Even in such a case, it is possible to improve the search efficiency by applying the mapping definition tuning method as shown in FIG.

  There is another method that does not use a structural search engine to improve the mapping definition of a deep XML document. This will be described with reference to FIG. The structure search expression 801 is a query that specifies conditions regarding an i element, a j element that is a child element thereof, and a k element that is a child element thereof. When the inter-schema mapping definition 109 is used, this structure search expression is converted into the SQL expression 803 by the structure conversion module 102. This SQL expression includes two join operations, “i.id = j.pid” and “j.id = k.pid”. On the other hand, the relation table k (203) is updated so as to include the values of the column a of the relation table i (201) and the column c of the relation table j (202) as in the relation table k (802). As a result, the same structure retrieval formula can be executed as a query only for the relation table k (802).

  The relation table schema definition 110 and the inter-schema mapping definition 109 are updated to the relation table schema definition 805 and the inter-schema mapping definition 806, respectively. The first line of the inter-schema mapping definition 806 expresses that the value of the attribute a of the i element is also stored in the column ia of the relation table k (802). The same applies to the sixth line. In the above mapping definition, the structure search expression 801 is converted into the SQL expression 804 by the structure search expression conversion module 102. Since the search formula does not include a join operation, the search cost is low.

When the purpose is to improve the efficiency of a plurality of structure search expressions, it is possible to apply the same mapping definition improvement technique as described above by taking the sum of the paths of all structure search expressions. For example, to improve efficiency for all of the following structural search expressions:
/ X / i [@a = “...”] // k [@a = “...”]
// j [@c = “...”] / k [@b = “...”]
// i [@a = “...” and @b = “..”] / j [@c = “..”] / k
The relation table k is updated so as to include the values of the attributes a and b of the i element and the attribute c of the j element.

  Such a change in mapping causes a single value to be managed by a plurality of columns when breaking the normalization of the relational table, and therefore it becomes an overhead when updating data. The mapping definition tuning module 104 also refers to the issuance history of the update query, and determines whether or not to apply this mapping definition improving method according to the balance between the issuance frequencies of the reference query and the update query.

  The notation of the schema-to-schema mapping definition used in the above description is not limited to the embodiment, and any notation is applicable as long as the definition specification can express the same meaning. Although the above description has been given as a method for managing XML documents, it is obvious that the method in this embodiment can also be applied as a general method for managing structured documents with tags typified by SGML and HTML.

It is a whole block diagram of an Example. It is a block diagram of the part regarding the data conversion function of the XML document of an Example. It is a block diagram of the part regarding the query rewrite function of an Example. It is a block diagram of the part regarding the query execution function of an Example. It is a block diagram (continuation) of the part regarding the query execution function of an Example. It is a figure explaining the schema mapping improvement example of an Example. It is a figure (continuation) explaining the schema mapping improvement example of an Example. It is a figure (continuation) explaining the schema mapping improvement example of an Example. It is a figure (continuation) explaining the schema mapping improvement example of an Example.

Explanation of symbols

101. . . Tagged structured document-relational table data conversion module, 102. . . Structure retrieval formula conversion module, 103. . . Query execution control module, 104. . . Mapping definition tuning module, 105. . . Relational database, 106. . . Structure search engine, 107/701. . . Tagged structured document, 108/702. . . Tagged structured document schema definition, 109/604/703/709/806. . . Mapping definition between schemas, 110/603/704/710/805. . . Relation table schema definition, 111/707/801. . . Structure retrieval formula, 112/602/708/713/803/804. . . Rewrite result query, 113. . . As a result (of structure retrieval formula), 201-203 / 601/705/706/802. . . Relation table, 204/711/712. . . Storage image (partial XML document for structural search engine)

Claims (8)

In a method for managing a tree-structured tagged structured document using a relational database and a database dedicated to structure search,
In accordance with the structured document storage definition, a single structured document is decomposed into a first structure part stored in the relational database and a second structure part stored in the structure search dedicated database.
For the first structure part, the data itself with the tag removed is extracted and stored in the column of the relation table associated with the storage definition,
The second structure portion is stored in a structure search dedicated database with the tag included,
Converting a structure search expression for the original structured document into a first search expression for the relational database and a second search expression for the structure search-dedicated database according to the storage definition;
Issuing the first search formula to the relational database and receiving the result, issuing the second search formula to the structure search dedicated database and receiving the result;
An XML data management method comprising a procedure for constructing a structured document equivalent to a result for the structure retrieval formula from both results. In a method for managing a tree-structured tagged structured document using a relational database and a database dedicated to structure search,
In accordance with the structured document storage definition, a single structured document is decomposed into a first structure part stored in the relational database and a second structure part stored in the structure search dedicated database.
For the first structure part, the data itself with the tag removed is extracted and stored in the column of the relation table associated with the storage definition,
The second structure portion is stored in a structure search dedicated database with the tag included,
Converting a structure search expression for the original structured document into a first search expression for the relational database and a second search expression for the structure search-dedicated database according to the storage definition;
The second search expression is expressed by a relational database search expression extension function that can be embedded in the first search expression that executes a structure search process equivalent to the second search expression.
Generating a relational database search expression with an extension function in which the extension function is embedded in the first search expression;
An XML data management method comprising issuing a relational database retrieval formula with an extension function to the relational database and obtaining a structured document equivalent to a result of the structural retrieval formula. Record the issuance history of structural search formulas for tagged structured documents,
Using the search processing efficiency of frequently issued search expressions as an index,
The XML data management method according to claim 1, wherein the structured document storage definition and the schema definition of the relation table are updated. Among the tagged structured documents, when the frequency of issuing the same structure search formula for the partially structured document stored in the structure search dedicated database exceeds a predetermined number,
Create a new relational table for storing the partially structured document stored in the structure search database;
Add the correspondence between the partially structured document and the newly created relation table to the structured document storage definition,
4. The XML data management method according to claim 3, wherein the partially structured document stored in the structure search dedicated database is stored again in the newly created relational table. In a structured document with a tag, the element indicated by a tag has a self-recursive structure with an element of the same type as the tag as a child element,
And the tag data is stored in the relational database,
And when the same structural search expression appears regardless of the depth of the hierarchy for the tag,
4. The XML data management method according to claim 3, wherein the self-recursive data is stored again in a structure search database. In the structured document with tag, when the same structure search expression that specifies the multi-level hierarchy for the data stored in the relational table database appears,
4. The XML data management method according to claim 3, wherein the data is stored again in a structure search database. In the structured document with tag, when the same structure search expression that specifies the multi-level hierarchy for the data stored in the relational table database appears,
Create a new single relational table with columns that list all levels of data appearing in the structure search expression,
4. The XML data management method according to claim 3, wherein the data is stored again in the newly created relationship table. In the tagged structured document, when multiple identical structure search expressions that specify multiple levels of hierarchy for the data stored in the relational table database appear,
Create a new single relational table with a column in which the union of the data of all layers appearing in the plurality of structural search expressions is arranged,
4. The XML data management method according to claim 3, wherein the data is stored again in the newly created relationship table.

Images