JP2006228155A - Xml data processing apparatus, xml data processing method, xml data processing program, and storage medium having xml data processing program recorded therein - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an apparatus which efficiently performs inquiry processing by eliminating unnecessary reference to links with respect to an inquiry about XML data. <P>SOLUTION: When XML data to be a retrieval object is registered, an XML data loader part 230 constitutes summary information of XML data and gives a range label to the summary information and stores them in a secondary storage device 130. On retrieval, an inquiry about XML data and summary information are inputted, and an inquiry analysis part 150 converts the inquiry to a tree structure to generate a structural part of an inquiry tree from which a value part is deleted, and an inquiry execution part 170 collates an intermediate inquiry tree and summary information to generate a set of intermediate summary trees and converts it to a set of substantial intermediate trees including data resulting from substantiating the set of intermediate summary trees with respect to the XML data, and a value part corresponding to the set of substantial intermediate trees is used to perform filter processing with respect to the XML data, and an inquiry result is outputted. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an XML data processing apparatus, an XML data processing method, an XML data processing program, and a storage medium on which the XML data processing program is recorded, which processes XML (eXtensible Markup Language) data at high speed.

Several techniques for accelerating XML data processing have already been released. For example, Non-Patent Document 1 proposes a fast structure join algorithm for XML data. Here, the structure join is an operation similar to the join operation of the relational database, and is an operation that combines a plurality of search results (details will be described later). Further, in Non-Patent Document 2, using a label speeds up database search specifying an ancestor-descendant relationship and a parent-child relationship. Non-Patent Document 3 proposes a method of optimizing the execution order of the structure join operation and using the statistical information of the XML data to speed up the search.
Shurug Al-Khalifa, HV Jagadish, Nick Koudas, Jignesh M. Patel, Divesh Srivastava, and Yuqing Wu, "Structural Joins: A Primitive for Efficient XML Query Pattern Matching", (USA) In Proc. ICDE (2002) Quanzhong Li and Bongki Moon, "Indexing and Querying XML Data for Regular Path Expressions", (USA) In Proc. VLDB (2001) Yuqing Wu, Jignesh M. Patel, and HV Jagadish, "Structural Join Order Selection for XML Query Optimization", (USA) In Proc. ICDE (2003)

  However, these technologies have not fully utilized the structure of XML data, and there is still room for speeding up. In particular, there has been a problem that sufficient measures have not been taken in terms of reducing the number of costly structural join operations.

  Accordingly, the present invention provides an XML data processing apparatus, an XML data processing method, an XML data processing program, and a storage medium on which the XML data processing program is recorded, which solves the above-described problems and realizes high-speed XML data processing. Objective.

  In order to achieve the above object, the present invention (Claim 1) is an XML data processing apparatus realized by using a computer having at least an arithmetic means and a storage means, and the XML data processing apparatus is an XML data. And means for storing XML data, and at the time of registering the XML data to be searched, the means for analyzing the XML data constitutes summary information including information on the structure and statistics of the XML data. A means for assigning a label capable of determining an ancestor-descendant relationship between nodes of the XML data to the summary information, and storing the XML data stores the XML data, the summary information, and the label.

  According to this configuration, summary information of XML data can be configured.

  In the present invention (Claim 2), the computing means receives an SAX event sequence of XML data as input, determines whether or not node information corresponding to each SAX event is included in the summary information, and the node When the information is not included in the summary information, the means for analyzing the XML data adds the node information to the summary information, thereby forming the summary information by a predetermined number of scans.

  According to this configuration, the summary information can be configured by a predetermined number of scans.

  In the present invention (Claim 3), a range label having a function of specifying a search target node in the tree structure is used as a label capable of determining the ancestor-descendant relationship.

  According to this configuration, an efficient search can be performed using the range label.

  According to the present invention (Claim 4), there is provided an XML data processing device realized by using a computer having at least an arithmetic means and a storage means, the XML data processing device analyzing means for querying XML data; Means for executing the query, and means for analyzing the query by using the query and summary information including information on the structure and statistics of the XML data as input, and converting the query into a tree structure to obtain attribute values or A query tree structure part from which the node value part has been deleted is generated, and the means for executing the query collates the intermediate query tree, which is a part of the query tree structure part, with the summary information, and provides a summary information. A set of intermediate summary trees including part information, and converting the XML data into a set of entity intermediate trees including data obtained by materializing the set of intermediate summary trees. For the XML data, performs filter processing using part of the value corresponding to said set of entities intermediate tree to obtain query results.

  According to this configuration, it is possible to input summary information and an inquiry and obtain a desired search result from XML data.

  In the present invention (Claim 5), XPath is used as a search language for describing the query.

  According to this configuration, an inquiry can be made in the XPath format.

  In the present invention (Claim 6), the means for analyzing the query creates an event sequence for the summary information.

  According to this configuration, summary information can be converted into an event sequence.

  In the present invention (Claim 7), the XML data processing apparatus further includes means for performing a structure join operation for combining a plurality of search results, and the means for performing the structure join operation is included in the intermediate summary tree. On the other hand, it is converted into a set of entity intermediate trees by using a structure join operation.

  According to this configuration, it is possible to improve the efficiency of the intermediate processing stage of the inquiry to the XML data.

  In the present invention (Claim 8), the XML data processing apparatus further includes means for optimizing a query, and the means for optimizing the query includes the entity including data obtained by materializing the intermediate summary tree. Optimal execution by calculating the cost of an execution plan that combines the materialization method that is the process of converting into a set of intermediate trees and the filtering method using the value part corresponding to the set of the intermediate tree Decide on a plan.

  According to this configuration, it is possible to further improve the efficiency of query processing.

  In the present invention (Claim 9), the XML data processing apparatus further includes means for managing a database, and the means for managing the database manages the XML data.

  According to this configuration, it is possible to efficiently refer to XML data stored in the secondary storage device.

  In the present invention (Claim 10), the XML data processing apparatus further includes means for analyzing the XML data and means for storing the XML data, and the XML data is stored when registering the XML data to be searched. Analyzing means configures summary information including information on the configuration and statistics of the XML data, assigns a label that can determine an ancestor-descendant relationship between nodes of the XML data to the XML data, and stores the XML data Means for storing the XML data, the summary information and the label.

  According to this configuration, the query can be efficiently processed by obtaining the summary information by the pre-processing on the XML data and further giving the summary information and the query.

  In the present invention (claim 11), the computing means receives an SAX event sequence of XML data as input, determines whether or not node information corresponding to each SAX event is included in the summary information, and the node When the information is not included in the summary information, the means for analyzing the XML data adds the node information to the summary information, thereby forming the summary information by a predetermined number of scans.

  According to this configuration, summary information can be efficiently configured.

  In the present invention (Claim 12), a range label having a function of specifying a search target node in the tree structure is used as a label capable of determining the ancestor-descendant relationship.

  According to this configuration, an efficient search can be performed using the range label.

  According to the XML data processing apparatus, the XML data processing method, the XML data processing program, and the storage medium on which the XML data processing program is recorded, the structure of the data included in the XML data to be searched is utilized to perform high-speed processing. XML data can be processed.

  Next, embodiments of the present invention will be described in detail with reference to the drawings as appropriate.

<< first embodiment >>
[System configuration]
FIG. 1 is a diagram for explaining the configuration of an XML data processing apparatus 100 according to the first embodiment of the present invention. The XML data processing apparatus 100 is configured by reading a computer program for processing XML data into a computer including a main storage device 110, a CPU (Central Processing Unit) 120, and a secondary storage device 130. The

  The query analysis unit 150 performs lexical analysis and syntax analysis on the query to the XML data (see FIG. 5), and generates a query tree (see FIG. 7) that is an internal representation of the query. In addition, the query analysis unit 150 separates the query tree into a structure unit and a value processing unit, and generates an intermediate query tree.

  When performing query optimization, the query optimization unit 160 generates a query execution plan (explained later) from the intermediate query tree, and calculates the cost of each execution plan from information related to the configuration of XML data, statistical information, and the like. Calculate and choose the optimal execution plan.

  The query execution unit 170 executes the intermediate query tree passed from the query analysis unit 150 or the execution plan passed from the query optimization unit 160. At this time, the query execution unit 170 obtains a data guide tree (strong data guide tree, corresponding to summary information in the claims) 240 that summarizes XML data stored in the secondary storage device 130 and information on the tree structure of the XML data. Perform a query as a target. The secondary storage device 130 is accessed via a disk manager unit 190, which will be described later, and the data guide tree (strong data guide tree) 240 is accessed via the event sequence generation unit 210.

  The structure join calculation unit 180 performs a structure join calculation which is an existing technique. At this time, the secondary storage device 130 is accessed via the disk manager unit 190.

  Note that the structure join is an operation similar to the join operation of the relational database. In join operations in relational databases, entries corresponding to all combinations of only entries that appear in common in both table entries (tuples) to which the value of the item specified during table join processing is joined Generate. In contrast, in a structure join for XML data, when querying a parent-child relationship or an ancestor-descendant relationship, two tag names are searched individually, and these search results are based on the parent-child relationship or ancestor-descendant relationship. Are combined to obtain a desired search result. For example, when a query "// Book // person" is made, an operation that searches for "Book" and an operation that searches for "person" are performed separately, and these search results are combined to create "// Book // Create a result for "person". At this time, if the normal method of tracing the link of the parent-child relationship or the ancestor-descendant relationship is used, a search for all target nodes is required, but if the target node is limited using a range label described later, Desired data can be obtained efficiently.

  The disk manager unit 190 provides a means for accessing the XML data stored in the secondary storage device 130.

  The result generation unit 200 generates a query processing result using an existing technology. Since the XPath query processing result is a subtree specified by the result node, the result generation unit 200 generates such a result.

  The event sequence generation unit 210 generates an event sequence (see FIG. 4, description will be described later) from the data guide tree (strong data guide tree) 240. The data guide tree (strong data guide tree) 240 will be described later in the description using FIGS.

  The data guide tree loader unit 220 loads a data guide tree (strong data guide tree) 240 from the XML data 20 before recording in the secondary storage device 130 or the XML data 140 after recording.

The XML data loader unit 230 loads the XML data 20 into the secondary storage device 130. The XML data loader unit 230 can move in parallel with the data guide tree loader unit 220. Then, the XML data loader unit 230 stores a range label (details will be described later) to be given to the data guide tree 240 by the following three methods according to the capacity of the main storage device 110.
(1) When the capacity of the main storage device 110 is sufficiently large, all range labels are stored in the main storage device 110.
(2) When the capacity of the main storage device 110 is medium, a part of the range label is stored in the main storage device 110 and the remaining part is stored in the secondary storage device 130.
(3) When the capacity of the main storage device 110 is small, all range labels are stored in the secondary storage device 130.

  This storage method can be selected by the user. In the case of (1), since all the range labels are held in the main storage device 110, the required capacity becomes large, but since all the structure joins are completed in the main storage device 110, the processing is very fast. It can be carried out.

  In the case of (2), while holding the range labels of the nodes that frequently appear in the user's inquiry in the main storage device 110, while reducing the capacity of the primary storage device required compared to (1), Queries that appear frequently can be processed efficiently.

  In the case of (3), it is necessary to take out the range label to the main storage device 110 when executing the structure join. Good processing is possible.

  In the present embodiment, the user 10 makes an inquiry to the database from a programming API, an interactive interface program, or the like using an XPath search expression. The XPath search expression input by the user 10 is parsed by the query analysis unit 150 into a query tree. The query tree is decomposed into a structure unit 300 and a value processing unit 310 as shown in FIG. Further, it is processed in combination with a strong data guide tree and converted into a query intermediate summary tree. The query optimization unit 160 determines the execution order (plan) of the intermediate tree materialization processing and the filtering processing of the value processing unit. At this time, information regarding the configuration of the XML data stored in the secondary storage device 130, statistical information of the XML data, and the like are used. Then, the query execution unit 170 executes search processing according to the determined execution order (plan).

[Query processing]
(A) of FIG. 2 is a figure explaining the outline | summary of the XPath pre-process performed before an XPath process. FIG. 2B is a diagram for explaining the outline of the XPath process.

  In the XPath pre-process that is performed prior to the XPath process shown in FIG. 2A, a strong data guide tree corresponding to XML data given in advance is generated (S100). Then, using this strong data guide tree, an XPath process described later is performed.

  In the XPath process shown in FIG. 2B, first, an event sequence is generated based on the strong data guide tree (S110). Note that step S110 may be performed in the XPath pre-processing.

  Next, XPath processing is performed using the event sequence corresponding to the strong data guide tree created in step S110 (S120). Step S120 corresponds to processing until an intermediate summary tree to be described later is obtained. In the present embodiment, a method is used in which a strong data guide tree is converted into an event sequence in step S110, and the event sequence generated in step 120 is processed by XPath to obtain an intermediate summary tree. However, the present invention is not limited to this. Instead, various existing XPath processing methods may be used. For example, known techniques such as an XPath processing algorithm that can be processed in polynomial time by processing a query bottom-up (Georg Gottlob, Christof Koch and Reinhard Pichler, "Efficient Algorithms for Processing XPath Queries" (USA) In Proc. XPath processing may be performed by regarding the strong data guide tree as an XML tree using VLDB (2002). In this process, an event sequence need not be created.

  Then, it is determined whether to optimize the remaining XPath processing that has not been performed in the XPath processing so far (S130). When the XPath processing is not optimized (No in S130), the remaining XPath processing is performed in a predetermined order using the XML data 140 (see FIG. 1) of the secondary storage device 130. That is, the XML data is searched according to a processing procedure fixed in advance, and the process ends.

  When optimizing the remaining XPath processing (Yes in S130), the cost of the remaining XPath processing is estimated and the processing order is determined (S150). That is, the optimum processing order is determined. Then, the remaining XPath processes are performed in the determined order (S160), and the process ends.

FIG. 3 is a diagram illustrating an example of XML data. As shown in FIG. 3, the XML data is structured using tags. For example, the following lines included in FIG. 3 correspond to one tag group.
<title> XML 1 </ title>
The title tag is also structured in a form included in the Booklist tag. The XML data describes the data by structuring with such tags.

  FIG. 4 is a diagram illustrating an example of an event sequence of SAX (Simple API for XML). Note that SAX is a technology that performs parsing processing by scanning an XML document from top to bottom without creating a tree with a small amount of memory in real time. The event sequence in FIG. 4 is generated by extracting an event using the SAX technique with respect to the example of the XML data in FIG.

  FIG. 5 is a diagram showing an example of an XML tree constructed for the XML data of FIG. As shown in FIG. 5, the XML tree defines one node corresponding to one tag. The XML tree has a structure in which a leaf node indicating a text value or an attribute value is connected under a bottom node corresponding to a tag or attribute surrounded by a frame.

  In the XML tree of FIG. 5, the Booklist is the root node, and three Book nodes appear below it. A title node appears below the Book node. As described above, in the XML tree obtained by simply converting the original XML data, a plurality of similar node patterns may appear. Since the strong data guide tree aggregates the repeated patterns, it can be used to perform a search without waste.

  In the XML tree, node names whose description starts with “@” are nodes representing attributes, and the attribute values are described below. In this example, “@isbn” is an attribute node.

  FIG. 6 is a diagram illustrating an example of an inquiry by XPath. FIG. 6 shows an example of four queries from (1) to (4). In the query, the search target can be specified using not only the parent-child relationship but also the ancestor-descendant relationship. “/” Represents a parent-child relationship between nodes, and “//” represents an ancestor-descendant relationship between nodes.

  In the example of FIG. 6, the example of (1) is an example using a parent-child relationship, and a node called “Booklist” is connected under a root node in a parent-child relationship, and similarly, a “Book” node is connected to that Booklist node. This is a query for retrieving data having a structure in which a book node, an authors node, and a person node are connected in a parent-child relationship.

  In the queries (2) to (4), not only the parent-child relationship but also the ancestor-descendant relationship is used. For example, in the example of (4), there is a description that there is an ancestor-descendant relationship between the root node and the book. The examples (2) to (4) are examples of queries that specify values and attribute values.

  FIG. 7 is a diagram illustrating an example of a query tree corresponding to queries (1) to (4) in FIG. As in this example, the XPath query can be expressed by a tree.

  FIG. 8 is a diagram illustrating an example of a strong data guide tree corresponding to the XML tree illustrated in FIG. 5. The strong data guide tree represents information that summarizes the information of the tree structure shown in the XML tree of FIG. That is, the information is obtained by extracting the relationships between the nodes. A method for generating a strong data guide tree will be described later.

  FIG. 9 is a diagram illustrating an example of a strong data guide tree with range labels. As shown in FIG. 9, each node of the strong data guide tree has one queue, and a label in which two numbers on the left and right are arranged is stored in the queue. A method of constructing a strong data guide tree with range labels will be described later.

  FIG. 10 is a diagram for explaining the structure part and the value processing part of the query tree. The query tree shown in FIG. 10 is the same as the query tree shown in FIG. 7, but can be divided into a structure unit 300 and a value processing unit 310 as shown in FIG. At this time, in the query tree having no value and attribute value, only the structure unit 300 and the value processing unit 310 do not exist. The process of dividing the inquiry unit 300 and the value processing unit 310 is used in a process for obtaining an intermediate summary tree described later.

  FIG. 11 is a diagram for explaining processing for generating a strong data guide tree without a range label. In this process, a SAX event is input and a strong data guide tree without a label is output.

  First, the first or next SAX event is input (S200), and the process is started. Then, it is checked whether the SAX event is a start event (S210). The start event is an event in the form of “start ()” such as “start (Booklist)” in the example shown in FIG.

  If it is not a start event (No in S210), it is checked whether the input SAX event is an end event (S220). Here, the end event is an event in the form of “end ()” such as “end (Booklist)” in the example shown in FIG. If the event is an end event (Yes in S220), the current node, which is the target node at each point in the strong data guide tree, is changed to the parent node of the current node (the node that is one higher on the root node side). It moves (S230) and progresses to step S290 mentioned later. If it is not an end event (No in S220), the process proceeds to step S290 as it is.

  In step S210, if the SAX event is a start event (Yes in S210), it is checked whether the tag name of the input SAX event exists in the strong data guide tree (S240). If the tag name does not exist (No in S240), a child node is added to the strong data guide tree with the tag name (S250), and the process proceeds to step S260. If the tag name exists (Yes in S240), the process proceeds to step S260 without executing step S250 as it is.

  In step S260, the current node is moved to that node, that is, the node with the same tag name or the newly added child node. Then, it is checked whether or not the input SAX event has an attribute (S270). If it does not have an attribute (No in S270), the process proceeds directly to step S290, and if it has an attribute (Yes in S270), a child node corresponding to the attribute is added (S280), and the process proceeds to step S290. Details of the child node addition process corresponding to the attribute will be described later.

  In step S290, it is checked whether all SAX events have been input at that time. As a result, when there is a non-input SAX event (No in S290), the process is repeated from step S200. If all SAX events have been input (Yes in S290), the strong data guide tree created up to that point is output (S300), and the process is terminated.

  FIG. 12 is a diagram illustrating processing for adding a child node corresponding to an attribute to a strong data guide tree without a range label. FIG. 12 shows details of the process in step S280 in FIG.

  First, the attribute name A to be processed is input (S400). Then, it is checked whether or not a child node named “@A” corresponding to the attribute name A exists in the current node (S410). For example, if the attribute name A is “isbn”, it is checked whether or not there is a child node named “@isbn”. If it does not exist (No in S410), a child node named “@A” corresponding to the attribute name A is added to the current node (S420), and the process proceeds to step S430. When it exists (Yes of S410), it progresses to step S430 as it is.

  In step S430, it is checked whether all attributes have been processed at that time (S430). If all the attributes have been processed (Yes in S430), the process is terminated as it is, and if any unprocessed attributes remain (No in S430), the process returns to Step S400 to repeat the process.

FIG. 13 is a diagram for explaining processing for generating a strong data guide tree with a range label.
As shown in FIG. 9, the range label uses a pair of left and right two values as a label. First, a left value left and a right value right for managing the label are initialized (S500). . For example, each value may be set to 1. Then, a root node is created, and the current node is set as the root node (S510). This corresponds to initialization of the strong data guide tree.

  Then, the first or next SAX event is input (S520). Then, a process for constructing a strong data guide tree with a range label according to the SAX event is performed (S530). Details of the processing in step S530 will be described later.

  Then, it is checked whether or not all SAX events have been input by that time (S540). As a result, when there is an uninput SAX event (No in S540), the processing is repeated from Step S520. If all SAX events have been input (Yes in S540), the strong data guide tree with the range label created up to that point is output (S550), and the process is terminated.

  FIG. 14 is a diagram for explaining a process of constructing a strong data guide tree with a range label according to one SAX event. The process described with reference to FIG. 14 corresponds to the process of step S530 in FIG. 13 and plays the role of a subroutine that takes over the input and variables in FIG.

  First, it is checked whether or not the input SAX event is a start event (S600). If it is a start event (Yes in S600), the value of left described in the process of FIG. 13 is stored in the variable l, and the value of left is increased (S610). At this time, the increment for increasing the value of left may be a predetermined value. For example, the predetermined increment may be 1 or 10.

  Then, it is checked whether or not there is a child node whose name is the start tag name TAG of the SAX event (S620). For example, if the start tag name of the SAX event is “title”, it is checked whether or not there is a child node named “title”. If there is no child node having the same name as the start tag name TAG of the SAX event (No in S620), a child node whose name is the TAG is added to the current node (S630). For example, in the case of the start tag name “title”, a child node named “title” is added. Then, the process proceeds to next Step S640. If a child node with the same name already exists (Yes in S620), the process proceeds to step S640 as it is.

  In step S640, the current node is moved to its child node (S640). That is, when a child node is added, the current node is moved to the child node. When a child node with the same name exists, the current node is moved to the child node. Then, it is checked whether or not the SAX event has an attribute (S650). If it has an attribute (Yes in S650), an attribute child node addition and range label assignment process is performed (S660), and the process proceeds to step S670. Details of the process in step S660 will be described later. If it has no attribute (No in S650), the process proceeds to step S670 as it is.

  In step S670, the label of (l, NULL) is added to the end of the queue of the current node using the value of the variable l saved in step S610, and the process ends. Note that NULL is a special value indicating that no valid label value is entered.

  If the SAX event is not a start event in step S600 (No in S600), it is then checked whether the SAX event is an end event (S680). If it is not an end event (No in S680), it is checked whether the SAX event is a text node event (S690). Note that the text node event refers to an event having the form “text ()” that is the same as “text (“ XML 1 ”)” appearing in the event sequence shown in FIG. As a result of the examination, if it is not a text node event (No in S690), the process is terminated as it is. If it is a text node event (Yes in S690), the left of the text node label is left and the right is right. A value is entered and the label is placed in the queue of the current node (S700). Then, the values of left and right are increased (S710), and the process ends.

  If the SAX event is an end event in step S680 (Yes in S680), the right value of the label in the current node's queue is set to the right of the last label whose value is NULL. The label is put in the queue (S720). Then, the value of right is increased (S730). Then, the current node is moved to the parent node of the current node (S740), and the process ends.

  FIG. 15 is a diagram for explaining attribute child node addition and range label assignment processing. This process corresponds to the process of step S660 in FIG. 14, and plays the role of a subroutine that takes over input and variables and performs processing.

  First, the values of left and right are taken over (S800), and the process is started. First, the attribute name A is input (S810). Then, it is checked whether or not there is a child node named “@A” corresponding to the attribute name A in the current node (S820). As a result, if there is no such child node (No in S820), a child node whose name is “@A” is added to the current node (S830), and the process proceeds to step S840. If there is a child node with the same name (No in S820), the process proceeds directly to step S840.

  In step S840, a label of (left, right) is queued for the child node whose name is “@A” corresponding to the attribute name A (S840). Then, the values of left and right are increased (S850). Then, it is checked whether or not all attributes have been processed at this time (S860). If all attributes have already been processed (Yes in S860), the process ends. If there is an attribute that has not yet been processed (No in S860), the process returns to step S810 and the process is repeated.

  FIG. 16 is a diagram for explaining processing for constructing an event sequence from a strong data guide tree. FIG. 17 is a diagram for explaining an iterator search example for the strong data guide tree. A process for constructing an event sequence will be described with reference to FIG. 17 as appropriate in addition to FIG.

  In this process, first, a strong data guide tree is input, and the root node is set as the current node (S900). Then, it is checked whether or not the iterator of the current node moves in the descending direction (S910). Note that descending means moving away from the root node. The iterator here refers to a processing module for handling tree structure data such as a strong data guide tree, and the iterator is initially located at the root node, as shown in the example of FIG. It moves to search the whole tree while descending or ascending the tree structure.

  As a result of the investigation in step S910, when the iterator moves in the descending direction (Yes in S910), “start (N)” is output using the node name N of the current node (S940), and the process proceeds to step S970. At this time, for example, when the node name N is “authors”, “start (authors)” is output.

  If the iterator does not move in the descending direction as a result of the investigation in step S910 (No in S910), it is next examined whether the iterator of the current node moves in the ascending direction (S920). When moving in the upward direction (Yes in S920), “end (N)” is output using the node name N of the current node (S950), and the process proceeds to step S970.

  As a result of checking in step S920, if the iterator does not move in the upward direction (No in S920), it is checked whether or not the iterator of the current node recognizes the attribute (S930). When the attribute is recognized (Yes in S930), “attr @ (N)” is output using the node name N of the current node (S960), and the process proceeds to step S970. If the attribute is not recognized (No in S930), the process proceeds directly to Step S970.

  In step S970, the next event is set in the iterator of the current node (S970), and it is checked whether all nodes have been processed and returned to the root node at this point (S980). At this time, if a NULL value is returned from the iterator, it means that all nodes have been processed and the process has returned to the root node. If all the processes are completed (Yes in S980), the process is terminated, and if there are still processes (No in S980), the process returns to Step S910 and the process is repeated.

FIG. 18 is a diagram for explaining processing for obtaining an intermediate summary tree by inquiring with a strong data guide tree.
First, a strong data guide tree and an inquiry by XPath are input (S1000). Then, the structure part of the inquiry by XPath is taken out (S1010). It should be noted that the structure part of this inquiry is the same as the structure part 300 described in FIG.

  Then, the strong data guide tree is regarded as XML data, the XPath processing of the structure part is executed, and an internal match tree sequence is obtained (S1020). Then, an intermediate summary tree sequence composed of a pair of branch nodes and branch nodes is extracted from the internal match tree and output (S1030), and the process is terminated.

FIG. 19 is a diagram for explaining processing for generating an actual intermediate tree from an intermediate summary tree.
First, an intermediate summary tree is input (S1100), a structure join is performed between all nodes of the intermediate summary tree, and an actual intermediate tree is generated (S1110).

  Thereafter, it is checked whether or not all intermediate summary trees have been processed (S1120). If the processing has not been completed (No in S1120), the process returns to step S1100 to repeat the process. If all intermediate summary trees have been processed (Yes in S1120), the actual intermediate tree sequence obtained by the processing so far is output (S1130), and the process is terminated.

FIG. 20 is a diagram for explaining processing for obtaining an XPath query result by applying a filter condition to an entity intermediate tree sequence.
First, a real intermediate tree sequence is input, and a queue QO for preparing an output node generated in the process is prepared (S1200). Then, it is checked whether or not there is a value processing unit in the entity intermediate tree sequence (S1210). At this time, if there is a value processing unit in one or more entity intermediate trees in the entity intermediate tree sequence, there is a value processing unit in the entity intermediate tree sequence, and if there is no value processing unit, there is no value processing unit.

  As a result, if there is no value processing unit (No in S1210), the process proceeds to step S1250 as it is. If there is a value processing unit (Yes in S1210), the filter condition of the value processing unit of the query tree is extracted from the secondary storage device 130 and applied to the leaf node (the node at the end of the entity intermediate tree) (S1220). Then, the output node is added to the queue QO (S1230). Then, it is checked whether or not all the entity intermediate trees have been processed at this time (S1240). If the processing is not completed (No in S1240), the processing is repeated from step S1220, and the processing is completed. In step S1250, the process proceeds to step S1250.

  In step S1250, duplicate labels are removed from the queue QO to which nodes have been added in the processing so far (S1250). Here, since there is a possibility that the same label exists in the output node obtained by this process, only one identical label is left and all other duplicate labels are deleted. Then, the retrieval result is extracted from the secondary storage device 130 using the QO label and output (S1260), and the process is terminated.

  FIG. 21 is a diagram illustrating processing for generating an execution plan group and obtaining a minimum cost. This process is a process of determining an execution plan that can be substituted for a predetermined execution plan as described with reference to FIG. 19 (materialization plan) and FIG. 20 (filter condition application). At this time, combinations of various materialization plans and filter conditions are examined, and the one with the minimum cost is determined as the execution plan.

  First, a set of materialization plan and filter condition is output (S1300). Then, the combination of the materialization plan and the filter condition is set as one execution plan, and the cost is obtained (S1310). The cost at this time may be, for example, the number of accesses to the secondary storage device 130 or the like, but may be any index that reflects the search cost.

  Then, it is checked whether or not all materialization plans and filter condition sets (execution plans) have been input (S1320). If there are any items that have not been input yet (No in S1320), the process returns to step S1300 to repeat the process. Is output (S1330), and the process is terminated.

  In the actual search, after this process, a process corresponding to the process described in FIGS. 19 and 20 (a process for actually obtaining a search result) is performed based on this execution plan. For example, the processing described in FIG. 19 and FIG. 20 can be an example of the processing as long as the cost is minimum. A description of the specific processing of the execution plan with the minimum cost will be omitted.

  Up to this point, the first embodiment has been described. According to this embodiment, the XML data tree structure is obtained by aggregating the XML data structure and holding it in advance as summary information (strong data guide tree). It is possible to perform a search corresponding to the query efficiently without waste. Moreover, efficient query processing can be performed by taking an optimal data arrangement according to the configuration of the main storage device 110 of the XML data processing device 100 in accordance with the capacity.

<< Second Embodiment >>
FIG. 22 is a diagram for explaining the configuration of the XML data processing apparatus according to the second embodiment.
In the first embodiment, the XML data 140 is recorded in the secondary storage device 130 and is managed by the disk manager 190. The XML data 140 recorded in the secondary storage device 130 is stored in the XML data 140. In order to manage more efficiently, a relational database management system may be introduced to record and manage the XML data 140 as a relational database. In the second embodiment, the configuration other than the portion related to the relational database management system is the same as that of the first embodiment, and thus the description thereof will be omitted. Here, the components different from those of the first embodiment will be described. .

  In the second embodiment, the XML data 140A recorded in the secondary storage device 130 is recorded as a relational database (RDB). In the second embodiment, a programming API 250 of a relational database management system is introduced in place of the disk manager unit 190 to manage access to XML data 140A recorded as a relational database.

  Since the inquiry process in the second embodiment is the same as that in the first embodiment, a description thereof will be omitted. However, as described above, only the method of accessing the XML data 140A recorded in the secondary storage device 130 is different.

  According to the second embodiment, as in the first embodiment, the XML data structure is aggregated and stored in advance as summary information (strong data guide tree). A search corresponding to the query can be efficiently performed without waste. Furthermore, in the second embodiment, since the access to the XML data recorded in the secondary storage device is made efficient, more efficient query processing can be performed.

  So far, the embodiment of the present invention has been described, but the embodiment can be changed without departing from the gist of the present invention. For example, instead of recording the XML data in the secondary storage device, the capacity of the main storage device is increased and all the XML data is recorded there, or the secondary storage device is changed to a disk device composed of semiconductors. You may do it. Note that the XML data processing apparatus according to the present embodiment is realized by a program using arithmetic means, and can be operated by reading a predetermined program into a computer having a predetermined function. Then, the XML data processing apparatus may be realized by recording the program in a storage medium and causing the computer to read the program.

It is a figure explaining the structure of the XML data processing apparatus in 1st Embodiment. (A) is a figure explaining the outline | summary of the XPath pre-processing performed before an XPath process, (b) of FIG. 2 is a figure explaining the outline | summary of an XPath process. It is a figure explaining the example of XML data. It is a figure which shows the example of the event sequence of SAX. It is a figure which shows the example of the XML tree constructed | assembled with respect to the XML data of FIG. It is a figure which shows the example of the inquiry by XPath. It is a figure which shows the example of the query tree corresponding to the example of the query of FIG. It is a figure which shows the example of the strong data guide tree corresponding to the XML tree shown in FIG. It is a figure which shows the example of the strong data guide tree with a range label. It is a figure explaining the structure part and value processing part of a query tree. It is a figure explaining the process which produces | generates the strong data guide tree without a range label. It is a figure explaining the process which adds the child node corresponding to an attribute to the strong data guide tree without a range label. It is a figure explaining the process which produces | generates the strong data guide tree with a range label. It is a figure explaining the process which builds a strong data guide tree with a range label according to one SAX event. It is a figure explaining an attribute child node addition and a range label provision process. It is a figure explaining the process which builds an event sequence from a strong data guide tree. It is a figure explaining the search example of an iterator with respect to a strong data guide tree. It is a figure explaining the process which inquires with a strong data guide tree and obtains an intermediate | middle summary tree. It is a figure explaining the process which produces | generates the actual condition intermediate tree from an intermediate | middle summary tree. It is a figure explaining the process which applies a filter condition to an entity intermediate tree sequence, and obtains an XPath inquiry result. It is a figure explaining the process which produces | generates an execution plan group and calculates | requires the minimum cost. It is a figure explaining the structure of the XML data processing apparatus in 2nd Embodiment.

Explanation of symbols

10 users 20 XML data (before recording)
100 XML Data Processing Device 110 Main Storage Device 120 CPU
130 Secondary storage device 140, 140A XML data (after recording)
DESCRIPTION OF SYMBOLS 150 Query analysis part 160 Query optimization part 170 Query execution part 180 Structure join calculation part 190 Disk manager part 200 Result generation part 210 Event sequence generation part 220 Data guide tree loader part 230 XML data loader part 240 Data guide tree (strong data guide) wood)
250 Programming API

Claims (15)

An XML data processing apparatus realized by using a computer having at least an arithmetic means and a storage means,
The XML data processing device is
Means for analyzing the XML data and means for storing the XML data;
At the time of registering the XML data to be searched, the means for analyzing the XML data constitutes summary information including information on the configuration and statistics of the XML data,
A label that can determine an ancestor-descendant relationship between nodes of the XML data is attached to the summary information,
An XML data processing apparatus, wherein the means for storing the XML data stores the XML data, the summary information, and the label. The computing means receives an SAX event sequence of XML data as input, determines whether or not node information corresponding to each SAX event is included in the summary information,
When the node information is not included in the summary information, the means for analyzing the XML data adds the node information to the summary information, thereby forming the summary information by a predetermined number of scans. The XML data processing apparatus according to claim 1, wherein the apparatus is an XML data processing apparatus. The XML data processing according to claim 1 or 2, wherein the label capable of determining the ancestor-descendant relationship is a range label having a function of identifying a node to be searched in a tree structure. apparatus. An XML data processing apparatus realized by using a computer having at least an arithmetic means and a storage means,
The XML data processing device is
Means for analyzing a query for XML data;
Means for executing the query,
As input, summary information including information about the structure of the query and XML data and statistics,
The means for analyzing the query generates a query tree structure part by converting the query into a tree structure and deleting the attribute value or node value part,
Means for executing said query;
The intermediate query tree that is a part of the structure part of the query tree is collated with the summary information to generate a set of intermediate summary trees including a part of the summary information,
Converting the set of intermediate summary trees into the set of entity intermediate trees including data obtained by materializing the set of intermediate summary trees with respect to the XML data;
Filtering the XML data using a value portion corresponding to the set of entity intermediate trees,
An XML data processing apparatus characterized by obtaining a query result. The XML data processing apparatus according to claim 4, wherein a search language for describing the query is XPath. 6. The XML data processing apparatus according to claim 4, wherein the means for analyzing the inquiry creates an event sequence for the summary information. The XML data processing apparatus further comprises means for performing a structure join operation combining a plurality of search results;
The means for performing the structure join operation is:
7. The XML data processing apparatus according to claim 4, wherein the intermediate summary tree is converted into a set of the entity intermediate trees by using a structure join operation. The XML data processing device is
Further comprising means for optimizing the query;
A method of materialization processing in which the means for optimizing the query is a process of converting the intermediate summary tree into a set of the real intermediate tree including the materialized data, and a value portion corresponding to the set of the real intermediate trees 8. The XML data processing apparatus according to claim 4, wherein an optimal execution plan is determined by calculating a cost of an execution plan using a combination of filtering methods. . The XML data processing device is
Further comprising means for managing the database;
9. The XML data processing apparatus according to claim 4, wherein means for managing a database manages the XML data. The XML data processing device is
Means for analyzing the XML data and means for storing the XML data;
At the time of registering the XML data to be searched, the means for analyzing the XML data constitutes summary information including information on the configuration and statistics of the XML data,
A label that can determine an ancestor-descendant relationship between nodes of the XML data is attached to the summary information,
The XML data processing apparatus according to claim 4, wherein the means for storing the XML data stores the XML data, the summary information, and the label. The computing means receives an SAX event sequence of XML data as input, determines whether or not node information corresponding to each SAX event is included in the summary information,
When the node information is not included in the summary information, the means for analyzing the XML data adds the node information to the summary information, thereby forming the summary information by a predetermined number of scans. The XML data processing apparatus according to claim 10, wherein the apparatus is an XML data processing apparatus. 12. The XML data processing according to claim 10, wherein the label capable of determining the ancestor-descendant relationship is a range label having a function of specifying a node to be searched in a tree structure. apparatus. An XML data processing method executed by a computer having at least an arithmetic means and a storage means,
An XML data processing method for realizing the XML data processing apparatus according to any one of claims 1 to 12. A program executed by a computer having at least a calculation unit and a storage unit,
An XML data processing program for realizing the XML data processing apparatus according to any one of claims 1 to 12.   13. A program executed by a computer having at least an arithmetic means and a storage means, and records an XML data processing program for realizing the XML data processing apparatus according to any one of claims 1 to 12. A storage medium characterized by.

Images