US20060179049A1 - System for querying markup language data stored in a relational database according to markup language schema - Google Patents
System for querying markup language data stored in a relational database according to markup language schema Download PDFInfo
- Publication number
- US20060179049A1 US20060179049A1 US11/338,339 US33833906A US2006179049A1 US 20060179049 A1 US20060179049 A1 US 20060179049A1 US 33833906 A US33833906 A US 33833906A US 2006179049 A1 US2006179049 A1 US 2006179049A1
- Authority
- US
- United States
- Prior art keywords
- query
- data
- markup language
- schema
- instructions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/84—Mapping; Conversion
- G06F16/86—Mapping to a database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/954—Relational
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
Definitions
- the present invention relates to a system and method for data processing, including database and file management. More particularly, the invention receives data structured in a markup language such as XML, and stores the data in a different, relational database format. The invention, however, responds to subsequent query input expressed in the markup language format to query the underlying relational database data and also utilizes the markup language format in outputting query results.
- a markup language such as XML
- XML extensible Markup Language
- HTML HyperText Markup Language
- HTML HyperText Markup Language
- HTML HyperText Markup Language
- HTML HyperText Markup Language
- XML is a language for creating markup languages that describe data.
- HTML HyperText Markup Language
- XML describes data in a human readable format with no indication of how the data is to be displayed.
- XML is also popular due to its flexibility, and easy adaption to changing requirements.
- XML is said to employ a database-neutral, device-neutral format.
- relational databases are not a completely satisfactory solution.
- relational databases are inherently inconsistent with XML data.
- Relational databases organize data into tables, rows, and columns, whereas XML organizes data into elements and sub-elements, the nature of which is inherently variable and not subject to placement in tables.
- XML-SQL utility commercially available from the ORACLE CORPORATION.
- XSU XML-SQL utility
- SQL structured query language
- the present invention concerns a data processing system that receives data in a markup language such as XML, and stores the data in a different, relational database (or object-relational database) format.
- the system then translates between subsequent query input expressed in the markup language format to apply corresponding query instructions to the underlying relational database data, and thereafter output markup language style results appropriate to the query input.
- this system includes a translator, with loader, map, and wrapper subcomponents.
- the loader and wrapper interface with a relational database management system including a data server and data store.
- the loader receives input including a statement of a markup language data schema and data described by the markup language data schema.
- the loader then prepares a translation of the markup language data schema into a relational database schema that comprises multiple tables where each table comprises multiple columns.
- the loader stores the translation in the map.
- the loader utilizes the translation to translate the received data into translated data comprising an instance of the relational database schema.
- the loader also issues instructions to the data server to store the translated data.
- the wrapper receives query input including 1) query conditions referring to data according to the markup language data schema, and 2) markup language result-assembly instructions.
- the received query input resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising two or more of the following: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum.
- the wrapper prepares query instructions implementing at least a portion of the query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema and SQL result-assembly instructions.
- SQL structured query language
- the wrapper also instructs the data server to execute the query instructions, and thereafter receives query results organized according to the SQL result-assembly instructions. Ultimately, the wrapper utilizes the map to provide an output of the query results according to the markup language result-assembly instructions.
- the invention may be implemented to provide a method of processing and querying data.
- the invention may be implemented to provide an apparatus such as a data management system.
- the invention may be implemented to provide a signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital data processing apparatus to perform data storage and query operations as discussed herein.
- Another embodiment concerns logic circuitry having multiple interconnected electrically conductive elements configured to store and query data as described herein.
- the invention affords its users with a number of distinct advantages. Chiefly, the invention supports the widespread popularity of XML data by permitting users to provide such data for storage in a relational database and to construct future data queries according to the XML format of the data. Invisible to the user, the data is actually stored in a relational database format, separate from its original XML format. Consequently, the invention stores data with the accuracy, reliability, efficiency, and powerful accessibility afforded by relational databases without requiring users to abandon their XML mentality. The invention is convenient to use because users' queries can observe the same model as was originally used to organize the data under XML.
- the invention is also advantageous because it can be utilized with non-proprietary or even commercially available relational database management systems that conform or partially conform to the SQL standard. Furthermore, by facilitating queries that are more simple, clear, and direct, the invention also permits less skilled people to store and query data, reducing the database's operating costs and susceptibility to error. As another advantage, system administrators can update the invention's translator to universally tune the system for better optimization of queries. Such optimizations are applied universally to incoming queries, rather than requiring individual query constructors to optimize their own queries.
- the invention also provides a number of other advantages and benefits, which should be apparent from the following description of the invention.
- FIG. 1 is a block diagram of the hardware components and interconnections of a data management system according to the invention.
- FIG. 2 is a block diagram of a digital data processing machine according to the invention.
- FIG. 3 shows an exemplary signal-bearing medium according to the invention.
- FIG. 4 is a flowchart of an operational sequence for storing and querying data, where data and queries are received under a markup language data schema but queried and stored in a relational database schema, according to the invention.
- One aspect of the invention concerns a data management system, configured to receive data and queries under a markup language data schema, but to store and query the data according to a relational database schema.
- this system may be embodied by various hardware components and interconnections, the system 100 of FIG. 1 provides one illustrative example.
- the system 100 is comprised of a translator 102 and relational database management system (RDBMS) 104 . As shown below, the translator interacts with one or more data sources 106 , query sources 107 , and output destinations 108 .
- RDBMS relational database management system
- the RDBMS 104 includes hardware and software components to store, retrieve, and query data of one or more relational databases.
- the RDBMS 104 may be implemented by a data server 104 a and data store 104 b , as shown.
- the RDBMS 104 may be implemented by one or more personal computers, computer servers, computer workstations, mainframe computers, digital data storage devices, network attached storage devices, storage area networks, or any other appropriate system.
- the RDBMS 104 may comprise a non-proprietary or even commercially available product.
- Data resides in the data store 104 b , which comprises one or more digital data storage devices such as magnetic disk drive, circuit storage, magnetic tape, optical storage, or any other storage.
- the data server 104 a comprises an execution engine that manages storage, retrieval, and querying of data, and may for example comprise a software module running in a storage controller, device controller, server machine, or other construct.
- the system 100 also includes various sources of information and destinations for information. More particularly, the data source 106 provides input data 150 to the translator 102 for storage in the RDBMS 104 . The data source 106 also provides a schema 152 describing the data 150 . The query source 107 provides query input 154 to the translator 102 . The query input 154 includes various query conditions 154 a and result-assembly instructions 154 b . Each of the data source 106 and query source 107 may comprise one or more sources of automated or manually generated information, such as terminals, human interface devices, computers, scanners, computer networks, telephonic devices, or other source of input data and schema.
- the output destination 108 represents the place where the translator 102 sends query results 156 prepared according to the query input 154 .
- the destination 108 may comprise a computer, computer network, video display monitor, computer printer, teletype machine, communications link, or any other means for storing, presenting, relaying, or otherwise receiving the query results 156 .
- the translator 102 receives data in a first “markup language” format, and stores the data in a different, “relational database” format.
- the markup language format includes, without limitation, XML, SGML, HTML, WML, and the like, whereas the relational database format involves multiple tables and multiple columns, etc.
- the translator 102 also translates query input 154 expressed in the markup language format to prepare representative query instructions in SQL or another query language compatible with relational database data, directs execution of the prepared instructions upon data in the relational database, and outputs results of the query in the markup language format dictated by the query input.
- the translator 102 may comprise a personal computer, computer workstation, computing network, mainframe computer, software module running on another machine (such as the data server 104 a , if suitably powerful), etc.
- a personal computer such as the data server 104 a , if suitably powerful
- mainframe computer such as the data server 104 a , if suitably powerful
- the translator 102 includes a loader 102 a , map 102 b , and wrapper 102 c .
- the loader 102 a receives input including a statement of a markup language data schema 152 and data 150 described by the markup language data schema.
- the loader 102 a generates an appropriate relational database schema 162 , and creates a map 102 b that provides a translation between this schema 162 and the markup data schema 152 .
- the schema 162 which specifies multiple tables each with multiple columns, may reside in the RDBMS 104 (as illustrated), or another location such as the loader 102 a or another location within or accessible to the translator 102 .
- the map 102 b may be stored in the translator 102 (as illustrated), or another location accessible to the translator 102 , such as the RDBMS 104 .
- the loader 102 a utilizes the map 102 b to translate the received data 150 into translated data 153 constituting an instance of the relational database schema 162 .
- the loader 102 a also issues instructions to the data server 104 a to store the translated data 153 .
- the map 102 b may be represented as a sequence of connected nodes i.e., a tree of nodes. Each node maintains information on one element in the data schema 152 and its mapping to a column attribute in the relational database schema 162 .
- each map node may contain the information shown in TABLE 1, below.
- TABLE 1 name Element name -- as defined in data schema
- type Element type -- as defined in data schema (e.g., Integer, float, string, etc).) optional (Flag indicating whether this element is optional or not in the data schema.
- repeatable Flag indicating whether this element is repeatable or not, i.e., whether there can be multiple copies of it).
- the wrapper 102 c receives query input 154 including 1) query conditions 154 a referring to data under the markup language data schema, and 2) markup language result-assembly instructions 154 b .
- the received query input 154 resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising any two or more of the following actions: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum.
- XQUERY discussed in greater detail below.
- the wrapper 102 c prepares query instructions 158 implementing some or all of the query input 154 .
- the query instructions 158 include (1) query conditions referring to the relational database schema 162 and (2) result-assembly instructions.
- the instructions 158 are stated in a relational database query language, such as SQL, QUEL, or QBE (Query By Example), with SQL being used as the dominant example herein.
- the wrapper 102 c instructs the data server 104 a to execute the query instructions; the data server 104 a provides the wrapper 102 c with query results organized according to the query instructions 158 .
- the wrapper 102 c ultimately provides an output of the query results 156 to the output destination 108 , this output observing the markup language result-assembly instructions 154 b.
- software of the wrapper 102 c may be updated, upgraded, de-bugged, or otherwise supplemented by a system administrator, designer, developer, remote computer, or other updating source in order to universally tune the system for better optimization of queries.
- optimizations are therefore applied universally to incoming queries, rather than requiring individual query constructors to optimize their own queries.
- the translator 102 may be implemented in various forms. As one example, these components may be provided by separate digital data processing apparatuses (or a single, combined unit), exemplified by the hardware components and interconnections of the digital data processing apparatus 200 of FIG. 2 .
- the apparatus 200 includes a processor 202 , such as a microprocessor or other processing machine, coupled to a storage 204 .
- the storage 204 includes a fast-access storage 206 , as well as nonvolatile storage 208 .
- the fast-access storage 206 may comprise random access memory (“RAM”), and may be used to store the programming instructions executed by the processor 202 .
- the nonvolatile storage 208 may comprise, for example, one or more magnetic data storage disks such as a “hard drive”, a tape drive, or any other suitable storage device.
- the apparatus 200 also includes an input/output 210 , such as a line, bus, cable, electromagnetic link, or other means for the processor 202 to exchange data with other hardware external to the apparatus 200 .
- a different embodiment of the invention uses logic circuitry instead of computer-executed instructions to implement the computing features of the system 100 .
- this logic may be implemented by constructing an application-specific integrated circuit (“ASIC”) having thousands of tiny integrated transistors.
- ASIC application-specific integrated circuit
- Such an ASIC may be implemented with CMOS, TTL, VLSI, or another suitable construction.
- Other alternatives include a digital signal processing chip (“DSP”), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (“FPGA”), programmable logic array (“PLA”), and the like.
- DSP digital signal processing chip
- FPGA field programmable gate array
- PLA programmable logic array
- the operational aspect of the invention generally involves (1) receiving data in a markup language format, (2) storing the data in a different, relational database format, (3) translating subsequent query input expressed in the markup language format to prepare representative query instructions in SQL or another relational database query language, (4) executing the prepared instructions upon data in the relational database, and (5) outputting representative results in the markup language format.
- the present invention has broad applicability to various markup languages and query languages, the specifics of the configuration as described is particularly suited for use of XML and SQL, and the explanation that follows will emphasize such an application of the invention without any intended limitation.
- the translator 102 , RDBMS 104 , or other computing features comprise machine-executed program sequences, they may be implemented in various forms of signal-bearing media.
- this signal-bearing media may comprise, for example, the storage 204 or another signal-bearing media, such as a magnetic data storage diskette 300 ( FIG. 3 ), directly or indirectly accessible by a processor 202 .
- the instructions may be stored on a variety of machine-readable data storage media.
- Some examples include as direct access storage (e.g., a conventional “hard drive”, redundant array of inexpensive disks (“RAID”), or another direct access storage device (“DASD”)), serial-access storage such as magnetic or optical tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), optical storage (e.g., CD-ROM, WORM, DVD, digital optical tape), paper “punch” cards, or other suitable signal-bearing media including analog or digital transmission media and analog and communication links and wireless.
- the machine-readable instructions may comprise software object code, compiled from a language such as “C,” etc.
- the method aspect of the invention may be implemented using logic circuitry, without using a processor to execute instructions.
- the logic circuitry is implemented in the translator 102 , RDBMS 104 , and/or any other computing feature of the system 100 , and is configured to perform operations to implement the method of the invention.
- the logic circuitry may be implemented using many different types of circuitry, as discussed above.
- FIG. 4 shows a sequence 400 to illustrate one example of the method aspect of the present invention.
- this sequence serves to receives data in a markup language such as XML, and stores the data in a different, relational database (or object-relational database) format.
- the system then translates between subsequent query input expressed in the markup language format to apply representative query instructions to the underlying relational database data, and thereafter output markup language style results appropriate to the query input.
- a markup language such as XML
- relational database or object-relational database
- the loader 102 a receives input from the data source 106 , this input including (1) data 150 to be stored and possibly queried in the future and (2) a schema 152 describing this data.
- step 402 may be implemented by a user operating this computer to transmit, upload, or otherwise transfer the data 150 and schema 152 to the loader 102 a .
- the schema 152 comprises a markup language data schema, namely, a schema describing data formatted with tags and other indicia of a markup language.
- the schema 152 itself may be expressed in this same markup language, in a different markup language, by graphical means, etc.
- the arriving data 150 is formatted according to this markup language and comprises an instance of the schema 152 .
- step 404 the loader 102 a generates or receives a relational database schema 162 .
- the relational database schema 162 describes data comprising multiple tables, each with multiple columns, and therefore describes data stored in relational database format. As of step 404 , this data is non-existent, although such relational database data will be subsequently written to the store 104 b as discussed below.
- step 404 involves the loader 102 a analyzing the data 150 and then generating details of the relational database schema 162 (such as the number of tables, columns, etc.). The foregoing operation also has the effect of preparing a translation of the markup language data schema 152 into the relational database schema 162 .
- step 404 may involve receiving the details of the relational database schema 162 from various sources, such as the data source 106 , pre-programming of the loader 102 a , or user input to the loader 102 a .
- a separate step is performed to prepare a translation of the markup language data schema 152 into the relational database schema 162 .
- the loader 102 a as part of step 404 stores the translation (prepared as discussed above) in the map 102 b.
- the loader 102 a utilizes the map 102 b to translate the markup language data 150 into relational database data 153 , this data providing an instance of the relational database schema 162 .
- the loader 102 transmits the translated data 153 to the data server 104 a , which stores the newly translated relational database data 153 in the store 104 b .
- the data 153 now residing in the RDBMS 104 , is available for retrieval by the data server 104 a , querying by the data server 104 a , supplementing by the data server 104 a with new data, and other data management operations.
- step 410 the wrapper 102 c determines whether it has received any query input 154 from the query source 107 . If not, the wrapper 102 c may wait or perform other tasks (step 412 ). In contrast, if query input is received, step 410 advances to step 414 .
- the query input 154 is submitted by a user operating this computer to transmit, upload, or otherwise transfer the query input 152 to the wrapper 102 c .
- the query input 154 includes query conditions 154 a referring to data under the markup language data schema 152 , and markup language result-assembly instructions 154 b .
- the markup language result-assembly instructions 154 b provide instructions on how to construct markup language data of the appropriate structure to return the result.
- the query input 154 resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising any two or more of the following: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum.
- An exemplary query language meeting these requirements is XQUERY, which is a draft recommendation of the World Wide Web Consortium having its specification set forth at http://www.w3.org/TR/xquery/. The entirety of the foregoing specification is incorporated herein by reference. Responsive to the query input 154 , step 410 advances to step 414 .
- the wrapper 102 c responds to the query input 154 by preparing query instructions 158 implementing some or all of the query conditions 154 a and/or some or all of the result-assembly instructions 154 b .
- the wrapper prepares instructions 158 by consulting the map 102 b .
- the query instructions 158 include query conditions and result-assembly instructions both occurring in a query language compatible with the RDBMS 104 and therefore referring to the relational database schema 162 .
- the query instructions 158 may, for example, be embodied in a query language such as SQL, QUEL, or QBE. In the case of SQL, the result-assembly instructions 158 are implemented by an SQL SELECT clause in the query instructions 158 .
- step 414 involves the wrapper 102 c reading the map 102 b and the query input 154 .
- the query input 154 is given either in a query language with the characteristics discussed above or in another representation that has the same characteristics, such as one or multiple sequences of operators, an algebraic expression, an execution plan etc.
- the wrapper 102 c breaks the query input down into a sequence of operations (or the query input may be initially stated as a sequence of operations). For each operation in this sequence, the wrapper 102 c determines which element(s) of the data schema 154 is referred to, utilizes the map 102 b to find the corresponding columns and tables in the relational database schema 162 , and translates each operation into the appropriate piece of SQL code. The wrapper then generates SQL result-assembly instructions, completing construction of the SQL query 158 . In step 416 , the wrapper 102 c instructs the data server 104 a to execute the query instructions 158 .
- the wrapper 102 c may omit some of the query conditions 154 a and/or result-assembly instructions in preparing the instructions 158 .
- some operations such as NAVIGATION cannot be executed by relational databases, and must be processed later as discussed below.
- efficiency may be gained by omitting some conditions (such as ORDERING) for later processing.
- selection conditions on string type data certain RDBMS do not provide reliably accurate results.
- the wrapper 102 c may omit certain conditions 154 a from the instructions 158 . As discussed below, these conditions are implemented later by actions of the wrapper 102 c upon the RDBMs query results 160 .
- step 418 the wrapper 102 c receives the results 160 of the execution of the instructions 158 by the data server 104 a . These results are organized according to the result-assembly instructions of 158 .
- step 420 the wrapper 102 c itself applies any remaining query conditions 154 a that were omitted from the query instructions 158 and therefore not executed by the RDBMS 104 .
- the wrapper 102 c reformats the query results 160 according to the markup language result-assembly instructions 154 b , and provides a representative output to the destination 108 . Namely, upon delivery of the relational data results 160 by the data server 104 a , the wrapper 102 c executes the result-assembly instructions 154 b part of the query input 154 to generate a final XML result 156 .
- the steps 410 - 422 may be performed repeatedly in order to process new query input.
- the steps 402 - 408 may be repeated as needed to redefine the relational database schema, translation, and the like to accommodate different types of input data.
Abstract
A data processing system receives data in a first format utilizing a markup language such as extensible Markup Language (XML), and stores the data in a different, relational database format involving multiple tables and columns, etc. The system translates subsequent query input expressed in the first format to prepare representative query instructions in SQL or another query language compatible with relational data, and thereafter executes the prepared instructions upon data in the relational database. The system outputs results of the query in format dictated by the query input.
Description
- This application is a continuation of continuation of the following application, and claims the benefit thereof in accordance with 35 USC 120: U.S. application Ser. No. 09/859,256, entitled “SYSTEM FOR QUERYING MARKUP LANGUAGE DATA STORED IN A RELATIONAL DATABASE ACCORDING TO MARKUP LANGUAGE SCHEMA” and filed on May 17, 2001 in the names of Balmin et al. The entirety of the foregoing applications is hereby incorporated herein by reference.
- 1. Field of the Invention
- The present invention relates to a system and method for data processing, including database and file management. More particularly, the invention receives data structured in a markup language such as XML, and stores the data in a different, relational database format. The invention, however, responds to subsequent query input expressed in the markup language format to query the underlying relational database data and also utilizes the markup language format in outputting query results.
- 2. Description of the Related Art
- Rapid improvements in computing technology help people to create, exchange, and process information with increasing speed and efficiency. This, however, leads to even greater volumes of data to further exchange and process. Still, computers provide the most effective tool for organizing this data and searching for items of interest.
- With the advent of the Internet, and attendant need to express data in browser-compatible format, many applications format their data according to one of various markup languages. One of the most powerful markup languages is the extensible Markup Language (XML). XML is a non-mutually exclusive alternative to presentation-dependent markup languages such as HyperText Markup Language (HTML). Basically, XML is a language for creating markup languages that describe data. In contrast to HTML which describes document structure and visual presentation, XML describes data in a human readable format with no indication of how the data is to be displayed. XML is also popular due to its flexibility, and easy adaption to changing requirements. XML is said to employ a database-neutral, device-neutral format.
- In any case, all data is generated with the expectation and purpose of storage for some later use. With XML data, however, there are numerous obstacles to efficiently accessing and recalling voluminous data, despite the other advantages that XML offers toward ease of exchange and presentation. One option is to store XML data in various “files”. This presents difficulties, such as the burden of universally applying changes to data across the files, and correlating related data. From the standpoint of data reliability and ease of use, “file” storage of XML data is therefore less than satisfactory. Initially, storage of XML data in a relational database or an object-relational database would appear to make sense. In other contexts, database queries are known to save countless hours of human endeavor by rapidly searching enormous machine-readable databases for user-specified data. Databases (and especially relational or object-relational databases) ensure consistent implementation of changes, provide universally identical access to different users, and organize data for particularly efficient access.
- With XML data, however, relational databases are not a completely satisfactory solution. Broadly, relational databases are inherently inconsistent with XML data. Relational databases organize data into tables, rows, and columns, whereas XML organizes data into elements and sub-elements, the nature of which is inherently variable and not subject to placement in tables.
- Some approaches have addressed the problem of transforming XML data into relational databases. One example is the XML-SQL utility (XSU), commercially available from the ORACLE CORPORATION. Even when XML data is transformed into relational database data, however, new problems crop up. Chiefly, it is difficult to address queries to the relational database contents, since the data have been originally supplied as XML data. In particular, the user must manually construct structured query language (SQL) queries aimed at the relational database data. To do this, however, the user must know various details about how the data is stored in the database, and must change his/her thinking from the XML data (as originally supplied) to the relational database data (in its current form). In many cases, this is inconvenient or difficult, as the data (as stored) does not correspond to the user's vision of the data, since the user is still partially thinking in terms of the XML data's completely different organization. This thinking is often perpetuated because of the user's desire to treat data retrieved from the relational database as XML data once again.
- Consequently, such relational database queries can be complex and error prone. This increases the cost of accessing the data, both in terms of (1) manpower, since a more sophisticated user is required to construct difficult database queries and (2) errors, since mistakes in constructing the difficult queries yield incorrect query outputs.
- Consequently, known approaches to storing XML data in a relational database systems are not completely adequate due to various unsolved problems.
- Broadly, the present invention concerns a data processing system that receives data in a markup language such as XML, and stores the data in a different, relational database (or object-relational database) format. The system then translates between subsequent query input expressed in the markup language format to apply corresponding query instructions to the underlying relational database data, and thereafter output markup language style results appropriate to the query input.
- More particularly, this system includes a translator, with loader, map, and wrapper subcomponents. The loader and wrapper interface with a relational database management system including a data server and data store. Initially, the loader receives input including a statement of a markup language data schema and data described by the markup language data schema. The loader then prepares a translation of the markup language data schema into a relational database schema that comprises multiple tables where each table comprises multiple columns. In anticipation of future use, the loader stores the translation in the map. The loader utilizes the translation to translate the received data into translated data comprising an instance of the relational database schema. The loader also issues instructions to the data server to store the translated data.
- Initially, the wrapper receives query input including 1) query conditions referring to data according to the markup language data schema, and 2) markup language result-assembly instructions. The received query input resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising two or more of the following: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum. The wrapper prepares query instructions implementing at least a portion of the query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema and SQL result-assembly instructions. The wrapper also instructs the data server to execute the query instructions, and thereafter receives query results organized according to the SQL result-assembly instructions. Ultimately, the wrapper utilizes the map to provide an output of the query results according to the markup language result-assembly instructions.
- The foregoing features may be implemented in a number of different forms. For example, the invention may be implemented to provide a method of processing and querying data. In another embodiment, the invention may be implemented to provide an apparatus such as a data management system. In still another embodiment, the invention may be implemented to provide a signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital data processing apparatus to perform data storage and query operations as discussed herein. Another embodiment concerns logic circuitry having multiple interconnected electrically conductive elements configured to store and query data as described herein.
- The invention affords its users with a number of distinct advantages. Chiefly, the invention supports the widespread popularity of XML data by permitting users to provide such data for storage in a relational database and to construct future data queries according to the XML format of the data. Invisible to the user, the data is actually stored in a relational database format, separate from its original XML format. Consequently, the invention stores data with the accuracy, reliability, efficiency, and powerful accessibility afforded by relational databases without requiring users to abandon their XML mentality. The invention is convenient to use because users' queries can observe the same model as was originally used to organize the data under XML. From the standpoint of convenience, the invention is also advantageous because it can be utilized with non-proprietary or even commercially available relational database management systems that conform or partially conform to the SQL standard. Furthermore, by facilitating queries that are more simple, clear, and direct, the invention also permits less skilled people to store and query data, reducing the database's operating costs and susceptibility to error. As another advantage, system administrators can update the invention's translator to universally tune the system for better optimization of queries. Such optimizations are applied universally to incoming queries, rather than requiring individual query constructors to optimize their own queries.
- The invention also provides a number of other advantages and benefits, which should be apparent from the following description of the invention.
-
FIG. 1 is a block diagram of the hardware components and interconnections of a data management system according to the invention. -
FIG. 2 is a block diagram of a digital data processing machine according to the invention. -
FIG. 3 shows an exemplary signal-bearing medium according to the invention. -
FIG. 4 is a flowchart of an operational sequence for storing and querying data, where data and queries are received under a markup language data schema but queried and stored in a relational database schema, according to the invention. - The nature, objectives, and advantages of the invention will become more apparent to those skilled in the art after considering the following detailed description in connection with the accompanying drawings.
- Introduction
- One aspect of the invention concerns a data management system, configured to receive data and queries under a markup language data schema, but to store and query the data according to a relational database schema. Although this system may be embodied by various hardware components and interconnections, the
system 100 ofFIG. 1 provides one illustrative example. - The
system 100 is comprised of atranslator 102 and relational database management system (RDBMS) 104. As shown below, the translator interacts with one ormore data sources 106,query sources 107, andoutput destinations 108. - Relational Database Management System
- The
RDBMS 104 includes hardware and software components to store, retrieve, and query data of one or more relational databases. To this end, theRDBMS 104 may be implemented by a data server 104 a anddata store 104 b, as shown. TheRDBMS 104 may be implemented by one or more personal computers, computer servers, computer workstations, mainframe computers, digital data storage devices, network attached storage devices, storage area networks, or any other appropriate system. TheRDBMS 104 may comprise a non-proprietary or even commercially available product. - Data resides in the
data store 104 b, which comprises one or more digital data storage devices such as magnetic disk drive, circuit storage, magnetic tape, optical storage, or any other storage. The data server 104 a comprises an execution engine that manages storage, retrieval, and querying of data, and may for example comprise a software module running in a storage controller, device controller, server machine, or other construct. - Source/Destination for Data
- The
system 100 also includes various sources of information and destinations for information. More particularly, thedata source 106 providesinput data 150 to thetranslator 102 for storage in theRDBMS 104. Thedata source 106 also provides aschema 152 describing thedata 150. Thequery source 107 providesquery input 154 to thetranslator 102. Thequery input 154 includesvarious query conditions 154 a and result-assembly instructions 154 b. Each of thedata source 106 and querysource 107 may comprise one or more sources of automated or manually generated information, such as terminals, human interface devices, computers, scanners, computer networks, telephonic devices, or other source of input data and schema. - The
output destination 108 represents the place where thetranslator 102 sends query results 156 prepared according to thequery input 154. Thedestination 108 may comprise a computer, computer network, video display monitor, computer printer, teletype machine, communications link, or any other means for storing, presenting, relaying, or otherwise receiving the query results 156. - Translator
- Generally, the
translator 102 receives data in a first “markup language” format, and stores the data in a different, “relational database” format. The markup language format includes, without limitation, XML, SGML, HTML, WML, and the like, whereas the relational database format involves multiple tables and multiple columns, etc. Thetranslator 102 also translatesquery input 154 expressed in the markup language format to prepare representative query instructions in SQL or another query language compatible with relational database data, directs execution of the prepared instructions upon data in the relational database, and outputs results of the query in the markup language format dictated by the query input. To suit the foregoing purposes, thetranslator 102 may comprise a personal computer, computer workstation, computing network, mainframe computer, software module running on another machine (such as the data server 104 a, if suitably powerful), etc. Ordinarily skilled artisans having the benefit of this disclosure will also recognize a variety of other implementations of thetranslator 102, still contemplated by the present invention. - The
translator 102 includes aloader 102 a,map 102 b, andwrapper 102 c. Theloader 102 a receives input including a statement of a markuplanguage data schema 152 anddata 150 described by the markup language data schema. Theloader 102 a generates an appropriaterelational database schema 162, and creates amap 102 b that provides a translation between thisschema 162 and themarkup data schema 152. Theschema 162, which specifies multiple tables each with multiple columns, may reside in the RDBMS 104 (as illustrated), or another location such as theloader 102 a or another location within or accessible to thetranslator 102. Themap 102 b may be stored in the translator 102 (as illustrated), or another location accessible to thetranslator 102, such as theRDBMS 104. Theloader 102 a utilizes themap 102 b to translate the receiveddata 150 into translateddata 153 constituting an instance of therelational database schema 162. Theloader 102 a also issues instructions to the data server 104 a to store the translateddata 153. - In one embodiment, the
map 102 b may be represented as a sequence of connected nodes i.e., a tree of nodes. Each node maintains information on one element in thedata schema 152 and its mapping to a column attribute in therelational database schema 162. As one particular example, each map node may contain the information shown in TABLE 1, below.TABLE 1 name (Element name -- as defined in data schema) type (Element type -- as defined in data schema (e.g., Integer, float, string, etc).) optional (Flag indicating whether this element is optional or not in the data schema. repeatable (Flag indicating whether this element is repeatable or not, i.e., whether there can be multiple copies of it). schema (Name given by Translator to the relational schema that it creates tblName (Name of a table in the relational DB in which the element is stored.) colName (Name of a column in relational schema to which this element defined in the data schema maps.) children (List of “children” of this map node, i.e., other map nodes.) - The
wrapper 102 c receivesquery input 154 including 1)query conditions 154 a referring to data under the markup language data schema, and 2) markup language result-assembly instructions 154 b. The receivedquery input 154 resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising any two or more of the following actions: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum. One example of a query language meeting these requirements is XQUERY, discussed in greater detail below. Thewrapper 102 c preparesquery instructions 158 implementing some or all of thequery input 154. Thequery instructions 158 include (1) query conditions referring to therelational database schema 162 and (2) result-assembly instructions. Theinstructions 158 are stated in a relational database query language, such as SQL, QUEL, or QBE (Query By Example), with SQL being used as the dominant example herein. Thewrapper 102 c instructs the data server 104 a to execute the query instructions; the data server 104 a provides thewrapper 102 c with query results organized according to thequery instructions 158. Thewrapper 102 c ultimately provides an output of the query results 156 to theoutput destination 108, this output observing the markup language result-assembly instructions 154 b. - Advantageously, software of the
wrapper 102 c may be updated, upgraded, de-bugged, or otherwise supplemented by a system administrator, designer, developer, remote computer, or other updating source in order to universally tune the system for better optimization of queries. Such optimizations are therefore applied universally to incoming queries, rather than requiring individual query constructors to optimize their own queries. - Exemplary Digital Data Processing Apparatus
- As mentioned above, the
translator 102,RDBMS 104, and other computing features of the invention may be implemented in various forms. As one example, these components may be provided by separate digital data processing apparatuses (or a single, combined unit), exemplified by the hardware components and interconnections of the digitaldata processing apparatus 200 ofFIG. 2 . - The
apparatus 200 includes aprocessor 202, such as a microprocessor or other processing machine, coupled to astorage 204. In the present example, thestorage 204 includes a fast-access storage 206, as well asnonvolatile storage 208. The fast-access storage 206 may comprise random access memory (“RAM”), and may be used to store the programming instructions executed by theprocessor 202. Thenonvolatile storage 208 may comprise, for example, one or more magnetic data storage disks such as a “hard drive”, a tape drive, or any other suitable storage device. Theapparatus 200 also includes an input/output 210, such as a line, bus, cable, electromagnetic link, or other means for theprocessor 202 to exchange data with other hardware external to theapparatus 200. - Despite the specific foregoing description, ordinarily skilled artisans (having the benefit of this disclosure) will recognize that the apparatus discussed above may be implemented in a machine of different construction, without departing from the scope of the invention. As a specific example, one of the
components storage 204 may be provided on-board theprocessor 202, or even provided externally to theapparatus 200. - Logic Circuitry
- In contrast to the digital data processing apparatus discussed above, a different embodiment of the invention uses logic circuitry instead of computer-executed instructions to implement the computing features of the
system 100. Depending upon the particular requirements of the application in the areas of speed, expense, tooling costs, and the like, this logic may be implemented by constructing an application-specific integrated circuit (“ASIC”) having thousands of tiny integrated transistors. Such an ASIC may be implemented with CMOS, TTL, VLSI, or another suitable construction. Other alternatives include a digital signal processing chip (“DSP”), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (“FPGA”), programmable logic array (“PLA”), and the like. - Having described the structural features of the present invention, the operational aspect of the present invention will now be described. As mentioned above, the operational aspect of the invention generally involves (1) receiving data in a markup language format, (2) storing the data in a different, relational database format, (3) translating subsequent query input expressed in the markup language format to prepare representative query instructions in SQL or another relational database query language, (4) executing the prepared instructions upon data in the relational database, and (5) outputting representative results in the markup language format. Although the present invention has broad applicability to various markup languages and query languages, the specifics of the configuration as described is particularly suited for use of XML and SQL, and the explanation that follows will emphasize such an application of the invention without any intended limitation.
- Signal-Bearing Media
- In embodiment where the
translator 102,RDBMS 104, or other computing features comprise machine-executed program sequences, they may be implemented in various forms of signal-bearing media. In the context ofFIG. 2 , this signal-bearing media may comprise, for example, thestorage 204 or another signal-bearing media, such as a magnetic data storage diskette 300 (FIG. 3 ), directly or indirectly accessible by aprocessor 202. Whether contained in thestorage 206,diskette 300, or elsewhere, the instructions may be stored on a variety of machine-readable data storage media. Some examples include as direct access storage (e.g., a conventional “hard drive”, redundant array of inexpensive disks (“RAID”), or another direct access storage device (“DASD”)), serial-access storage such as magnetic or optical tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), optical storage (e.g., CD-ROM, WORM, DVD, digital optical tape), paper “punch” cards, or other suitable signal-bearing media including analog or digital transmission media and analog and communication links and wireless. In an illustrative embodiment of the invention, the machine-readable instructions may comprise software object code, compiled from a language such as “C,” etc. - Logic Circuitry
- In contrast to the signal-bearing medium discussed above, the method aspect of the invention may be implemented using logic circuitry, without using a processor to execute instructions. In this embodiment, the logic circuitry is implemented in the
translator 102,RDBMS 104, and/or any other computing feature of thesystem 100, and is configured to perform operations to implement the method of the invention. The logic circuitry may be implemented using many different types of circuitry, as discussed above. - Overall Sequence of Operation
-
FIG. 4 shows asequence 400 to illustrate one example of the method aspect of the present invention. Broadly, this sequence serves to receives data in a markup language such as XML, and stores the data in a different, relational database (or object-relational database) format. The system then translates between subsequent query input expressed in the markup language format to apply representative query instructions to the underlying relational database data, and thereafter output markup language style results appropriate to the query input. For ease of explanation, but without any intended limitation, the example ofFIG. 4 is described in the context of thesystem 100 described above (FIG. 1 ). - In
step 402, theloader 102 a receives input from thedata source 106, this input including (1)data 150 to be stored and possibly queried in the future and (2) aschema 152 describing this data. In one example, where thedata source 106 is a computer,step 402 may be implemented by a user operating this computer to transmit, upload, or otherwise transfer thedata 150 andschema 152 to theloader 102 a. Theschema 152 comprises a markup language data schema, namely, a schema describing data formatted with tags and other indicia of a markup language. Optionally, theschema 152 itself may be expressed in this same markup language, in a different markup language, by graphical means, etc. Any one of various markup languages may be used, such as XML, HTML, SGML, WML, or other known markup languages or markup languages that arise in the future. The arrivingdata 150 is formatted according to this markup language and comprises an instance of theschema 152. - In
step 404, theloader 102 a generates or receives arelational database schema 162. Unlike the markuplanguage data schema 152, therelational database schema 162 describes data comprising multiple tables, each with multiple columns, and therefore describes data stored in relational database format. As ofstep 404, this data is non-existent, although such relational database data will be subsequently written to thestore 104 b as discussed below. In one embodiment,step 404 involves theloader 102 a analyzing thedata 150 and then generating details of the relational database schema 162 (such as the number of tables, columns, etc.). The foregoing operation also has the effect of preparing a translation of the markuplanguage data schema 152 into therelational database schema 162. Alternatively, step 404 may involve receiving the details of therelational database schema 162 from various sources, such as thedata source 106, pre-programming of theloader 102 a, or user input to theloader 102 a. In this embodiment, a separate step is performed to prepare a translation of the markuplanguage data schema 152 into therelational database schema 162. In any case, theloader 102 a as part ofstep 404 stores the translation (prepared as discussed above) in themap 102 b. - In
step 406, theloader 102 a utilizes themap 102 b to translate themarkup language data 150 intorelational database data 153, this data providing an instance of therelational database schema 162. Instep 408, theloader 102 transmits the translateddata 153 to the data server 104 a, which stores the newly translatedrelational database data 153 in thestore 104 b. Thedata 153, now residing in theRDBMS 104, is available for retrieval by the data server 104 a, querying by the data server 104 a, supplementing by the data server 104 a with new data, and other data management operations. - In
step 410 thewrapper 102 c determines whether it has received anyquery input 154 from thequery source 107. If not, thewrapper 102 c may wait or perform other tasks (step 412). In contrast, if query input is received, step 410 advances to step 414. - In one example of
step 410, where thequery source 107 is a computer, thequery input 154 is submitted by a user operating this computer to transmit, upload, or otherwise transfer thequery input 152 to thewrapper 102 c. Thequery input 154 includesquery conditions 154 a referring to data under the markuplanguage data schema 152, and markup language result-assembly instructions 154 b. The markup language result-assembly instructions 154 b provide instructions on how to construct markup language data of the appropriate structure to return the result. Thequery input 154 resides in a query language that is structured to operate upon markup language data and contemplates query concepts comprising any two or more of the following: JOIN, GROUPING, SELECTION, PROJECTION, ORDERING, and NAVIGATION, with JOIN and/or GROUPING at minimum. An exemplary query language meeting these requirements is XQUERY, which is a draft recommendation of the World Wide Web Consortium having its specification set forth at http://www.w3.org/TR/xquery/. The entirety of the foregoing specification is incorporated herein by reference. Responsive to thequery input 154, step 410 advances to step 414. - In
step 414, thewrapper 102 c responds to thequery input 154 by preparingquery instructions 158 implementing some or all of thequery conditions 154 a and/or some or all of the result-assembly instructions 154 b. Namely, the wrapper preparesinstructions 158 by consulting themap 102 b. Thequery instructions 158 include query conditions and result-assembly instructions both occurring in a query language compatible with theRDBMS 104 and therefore referring to therelational database schema 162. Thequery instructions 158 may, for example, be embodied in a query language such as SQL, QUEL, or QBE. In the case of SQL, the result-assembly instructions 158 are implemented by an SQL SELECT clause in thequery instructions 158. - More particularly,
step 414 involves thewrapper 102 c reading themap 102 b and thequery input 154. Thequery input 154 is given either in a query language with the characteristics discussed above or in another representation that has the same characteristics, such as one or multiple sequences of operators, an algebraic expression, an execution plan etc. Thewrapper 102 c breaks the query input down into a sequence of operations (or the query input may be initially stated as a sequence of operations). For each operation in this sequence, thewrapper 102 c determines which element(s) of thedata schema 154 is referred to, utilizes themap 102 b to find the corresponding columns and tables in therelational database schema 162, and translates each operation into the appropriate piece of SQL code. The wrapper then generates SQL result-assembly instructions, completing construction of theSQL query 158. Instep 416, thewrapper 102 c instructs the data server 104 a to execute thequery instructions 158. - Optionally, the
wrapper 102 c may omit some of thequery conditions 154 a and/or result-assembly instructions in preparing theinstructions 158. For instance, some operations such as NAVIGATION cannot be executed by relational databases, and must be processed later as discussed below. In other cases, efficiency may be gained by omitting some conditions (such as ORDERING) for later processing. In still other cases, such as selection conditions on string type data, certain RDBMS do not provide reliably accurate results. Thus, thewrapper 102 c may omitcertain conditions 154 a from theinstructions 158. As discussed below, these conditions are implemented later by actions of thewrapper 102 c upon the RDBMs query results 160. - In
step 418, thewrapper 102 c receives theresults 160 of the execution of theinstructions 158 by the data server 104 a. These results are organized according to the result-assembly instructions of 158. Instep 420, thewrapper 102 c itself applies any remainingquery conditions 154 a that were omitted from thequery instructions 158 and therefore not executed by theRDBMS 104. - Finally, in
step 422, thewrapper 102 c reformats the query results 160 according to the markup language result-assembly instructions 154 b, and provides a representative output to thedestination 108. Namely, upon delivery of therelational data results 160 by the data server 104 a, thewrapper 102 c executes the result-assembly instructions 154 b part of thequery input 154 to generate afinal XML result 156. - The steps 410-422 may be performed repeatedly in order to process new query input. The steps 402-408 may be repeated as needed to redefine the relational database schema, translation, and the like to accommodate different types of input data.
- While the foregoing disclosure shows a number of illustrative embodiments of the invention, it will be apparent to those skilled in the art that various changes and modifications can be made herein without departing from the scope of the invention as defined by the appended claims. For example, while reference has been made to relational databases, the invention also contemplates object-relational database technology, with the term “relational database” therefore being utilized as shorthand. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, ordinarily skilled artisans will recognize that operational sequences must be set forth in some specific order for the purpose of explanation and claiming, but the present invention contemplates various changes beyond such specific order.
Claims (9)
1-16. (canceled)
17. A query processing method, comprising the operations of:
receiving input including a statement of a markup language data schema and data described by the markup language data schema;
preparing a translation of the markup language data schema into a relational database schema comprising multiple table definitions each table definition comprising multiple column definitions;
utilizing the translation to translate the received data into translated data comprising an instance of the relational database schema;
receiving query input including at least one of the following: 1) query conditions referring to data formatted according to the markup language data schema, and 2) result-assembly instructions for constructing query results according to the markup language;
wherein the received query input resides in a query language that is structured to operate upon markup language data and contemplates query actions comprising any two or more of Selection, Projection, Join, Grouping, Ordering, and Navigation with at least one of Join and Grouping at minimum;
preparing query instructions implementing at least a portion of said query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema;
issuing one or more commands to execute the query instructions upon the translated data to produce query results;
receiving the query results and providing an output of the query results according to the query input.
18. The method of claim 17 , where the markup language data schema utilizes one or more of the following: SGML, HTML, WML.
19. The method of claim 17 , further comprising the operations of:
generating the relational database schema.
20. The method of claim 17 , the operations further comprising:
responsive to the issuing of commands to execute the query instructions, a data server executing the query instructions upon the translated data and providing an output according to said query instructions.
21. The method of claim 17 , wherein:
the operation of preparing query instructions implements only a portion of said query input and leaves a remainder of the query input free from implementation;
the operation of receiving query results further comprises execution of the remainder of the query input.
22. A computer-readable storage medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform operations for processing queries, said operations comprising:
receiving input including a statement of a markup language data schema and data described by the markup language data schema;
preparing a translation of the markup language data schema into a relational database schema comprising multiple table definitions each table definition comprising multiple column definitions;
utilizing the translation to translate the received data into translated data comprising an instance of the relational database schema;
receiving query input including at least one of the following: 1) query conditions referring to data formatted according to the markup language data schema, and 2) result-assembly instructions for constructing query results according to the markup language;
wherein the received query input resides in a query language that is structured to operate upon markup language data and contemplates query actions comprising any two or more of Selection, Projection, Join, Grouping, Ordering, and Navigation with at least one of Join and Grouping at minimum;
preparing query instructions implementing at least a portion of said query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema;
issuing one or more commands to execute the query instructions upon the translated data to produce query results;
receiving the query results and providing an output of the query results according to the query input.
23. Logic circuitry of multiple interconnected electrically conductive elements configured to perform operations to process queries, the operations comprising:
receiving input including a statement of a markup language data schema and data described by the markup language data schema;
preparing a translation of the markup language data schema into a relational database schema comprising multiple table definitions each table definition comprising multiple column definitions;
utilizing the translation to translate the received data into translated data comprising an instance of the relational database schema;
receiving query input including at least one of the following: 1) query conditions referring to data formatted according to the markup language data schema, and 2) result-assembly instructions for constructing query results according to the markup language;
wherein the received query input resides in a query language that is structured to operate upon markup language data and contemplates query actions comprising any two or more of Selection, Projection, Join, Grouping, Ordering, and Navigation with at least one of Join and Grouping at minimum;
preparing query instructions implementing at least a portion of said query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema;
issuing one or more commands to execute the query instructions upon the translated data to produce query results;
receiving the query results and providing an output of the query results according to the query input.
24. A query processing method, comprising the operations of:
receiving multiple different schema/data inputs, each schema/data input including a statement of a markup language data schema and data described by the markup language data schema;
for each schema/data input, performing operations comprising:
preparing a translation of the markup language data schema into a corresponding relational database schema comprising multiple table definitions each table definition comprising multiple column definitions;
utilizing the translation to translate the received data into translated data comprising an instance of the relational database schema;
receiving query input including at least one of the following: 1) query conditions referring to data formatted according to the markup language data schema, and 2) result-assembly instructions for constructing query results according to the markup language;
wherein the received query input resides in a query language that is structured to operate upon markup language data and contemplates query actions comprising any two or more of Selection, Projection, Join, Grouping, Ordering, and Navigation with at least one of Join and Grouping at minimum;
preparing query instructions implementing at least a portion of said query input, the query instructions including structured query language (SQL) query conditions referring to said relational database schema;
responsive to issuance of one or more commands to execute the query instructions upon the translated data and produce query results, receiving the query results and providing an output of the query results according to the query input.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/338,339 US20060179049A1 (en) | 2001-05-17 | 2006-01-23 | System for querying markup language data stored in a relational database according to markup language schema |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/859,256 US7028028B1 (en) | 2001-05-17 | 2001-05-17 | System for querying markup language data stored in a relational database according to markup language schema |
US11/338,339 US20060179049A1 (en) | 2001-05-17 | 2006-01-23 | System for querying markup language data stored in a relational database according to markup language schema |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/859,256 Continuation US7028028B1 (en) | 2001-05-17 | 2001-05-17 | System for querying markup language data stored in a relational database according to markup language schema |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060179049A1 true US20060179049A1 (en) | 2006-08-10 |
Family
ID=36127853
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/859,256 Expired - Lifetime US7028028B1 (en) | 2001-05-17 | 2001-05-17 | System for querying markup language data stored in a relational database according to markup language schema |
US11/338,339 Abandoned US20060179049A1 (en) | 2001-05-17 | 2006-01-23 | System for querying markup language data stored in a relational database according to markup language schema |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/859,256 Expired - Lifetime US7028028B1 (en) | 2001-05-17 | 2001-05-17 | System for querying markup language data stored in a relational database according to markup language schema |
Country Status (1)
Country | Link |
---|---|
US (2) | US7028028B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070219976A1 (en) * | 2006-03-20 | 2007-09-20 | Microsoft Corporation | Extensible query language with support for rich data types |
US20090164413A1 (en) * | 2007-12-21 | 2009-06-25 | Sap Ag | Generic table structure to xml structure mapping |
US20100094838A1 (en) * | 2008-10-10 | 2010-04-15 | Ants Software Inc. | Compatibility Server for Database Rehosting |
CN107679172A (en) * | 2017-09-29 | 2018-02-09 | 北京奇艺世纪科技有限公司 | A kind of query statistic method and device of data |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7873649B2 (en) * | 2000-09-07 | 2011-01-18 | Oracle International Corporation | Method and mechanism for identifying transaction on a row of data |
AUPS084902A0 (en) * | 2002-03-01 | 2002-03-28 | Speedlegal Holdings Inc | A document assembly system |
EP1552427A4 (en) * | 2002-06-13 | 2009-12-16 | Mark Logic Corp | Parent-child query indexing for xml databases |
US7127469B2 (en) * | 2002-06-13 | 2006-10-24 | Mark Logic Corporation | XML database mixed structural-textual classification system |
EP1552426A4 (en) * | 2002-06-13 | 2009-01-21 | Mark Logic Corp | A subtree-structured xml database |
US7711675B2 (en) * | 2002-07-22 | 2010-05-04 | Microsoft Corporation | Database simulation of data types |
US6889231B1 (en) * | 2002-08-01 | 2005-05-03 | Oracle International Corporation | Asynchronous information sharing system |
JP4046086B2 (en) * | 2004-01-21 | 2008-02-13 | トヨタ自動車株式会社 | Variable compression ratio internal combustion engine |
US7440954B2 (en) * | 2004-04-09 | 2008-10-21 | Oracle International Corporation | Index maintenance for operations involving indexed XML data |
US7398265B2 (en) * | 2004-04-09 | 2008-07-08 | Oracle International Corporation | Efficient query processing of XML data using XML index |
US7603347B2 (en) * | 2004-04-09 | 2009-10-13 | Oracle International Corporation | Mechanism for efficiently evaluating operator trees |
US7516121B2 (en) * | 2004-06-23 | 2009-04-07 | Oracle International Corporation | Efficient evaluation of queries using translation |
DE602005022069D1 (en) * | 2004-06-23 | 2010-08-12 | Oracle Int Corp | EFFICIENT EVALUATION OF QUESTIONS BY TRANSLATION |
US7668806B2 (en) * | 2004-08-05 | 2010-02-23 | Oracle International Corporation | Processing queries against one or more markup language sources |
US7685137B2 (en) * | 2004-08-06 | 2010-03-23 | Oracle International Corporation | Technique of using XMLType tree as the type infrastructure for XML |
US7163060B2 (en) * | 2004-11-09 | 2007-01-16 | Halliburton Energy Services, Inc. | Difunctional phosphorus-based gelling agents and gelled nonaqueous treatment fluids and associated methods |
US8447774B1 (en) * | 2004-11-23 | 2013-05-21 | Progress Software Corporation | Database-independent mechanism for retrieving relational data as XML |
US7523131B2 (en) | 2005-02-10 | 2009-04-21 | Oracle International Corporation | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
WO2007014256A2 (en) * | 2005-07-26 | 2007-02-01 | Wifimed, Inc. | System and method for facilitating integration of automated applications within a healthcare practice |
US8150847B2 (en) | 2005-08-31 | 2012-04-03 | Ebay Inc. | System and method to transform results of client requests using client uploaded presentation formats |
US8346725B2 (en) * | 2006-09-15 | 2013-01-01 | Oracle International Corporation | Evolution of XML schemas involving partial data copy |
US7870163B2 (en) * | 2006-09-28 | 2011-01-11 | Oracle International Corporation | Implementation of backward compatible XML schema evolution in a relational database system |
US7624078B2 (en) * | 2006-10-18 | 2009-11-24 | International Business Machines Corporation | Method and apparatus for specification and interpretation of input source semantics |
US7783656B2 (en) * | 2007-09-24 | 2010-08-24 | International Business Machines Corporation | Accessing objects in a service registry and repository using a treat as function |
US9009181B2 (en) * | 2007-08-23 | 2015-04-14 | International Business Machines Corporation | Accessing objects in a service registry and repository |
US8209340B2 (en) * | 2008-03-31 | 2012-06-26 | Microsoft Corporation | Efficient functional representation of result shaping |
US8819046B2 (en) * | 2008-06-24 | 2014-08-26 | Microsoft Corporation | Data query translating into mixed language data queries |
US8364751B2 (en) | 2008-06-25 | 2013-01-29 | Microsoft Corporation | Automated client/server operation partitioning |
US20110302220A1 (en) * | 2010-06-08 | 2011-12-08 | Albert Marcella | Sql processing for data conversion |
WO2014123529A1 (en) * | 2013-02-07 | 2014-08-14 | Hewlett-Packard Development Company, L.P. | Formatting semi-structured data in a database |
US20140258838A1 (en) * | 2013-03-11 | 2014-09-11 | Sap Ag | Expense input utilities, systems, and methods |
CN104572649B (en) * | 2013-10-11 | 2019-10-25 | 南京中兴新软件有限责任公司 | The processing method of the data of distributed memory system, apparatus and system |
US10621152B2 (en) * | 2015-12-02 | 2020-04-14 | Speedment, Inc. | Methods and systems for mapping object oriented/functional languages to database languages |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5970490A (en) * | 1996-11-05 | 1999-10-19 | Xerox Corporation | Integration platform for heterogeneous databases |
US6009436A (en) * | 1997-12-23 | 1999-12-28 | Ricoh Company, Ltd. | Method and apparatus for mapping structured information to different structured information |
US6105043A (en) * | 1997-12-16 | 2000-08-15 | International Business Machines Corporation | Creating macro language files for executing structured query language (SQL) queries in a relational database via a network |
US6154738A (en) * | 1998-03-27 | 2000-11-28 | Call; Charles Gainor | Methods and apparatus for disseminating product information via the internet using universal product codes |
US6202072B1 (en) * | 1997-05-08 | 2001-03-13 | Jusystem Corp. | Method and apparatus for processing standard generalized markup language (SGML) and converting between SGML and plain text using a prototype and document type definition |
US6418448B1 (en) * | 1999-12-06 | 2002-07-09 | Shyam Sundar Sarkar | Method and apparatus for processing markup language specifications for data and metadata used inside multiple related internet documents to navigate, query and manipulate information from a plurality of object relational databases over the web |
US20020107889A1 (en) * | 2001-02-08 | 2002-08-08 | Tilion Corporation | Markup language routing and administration |
US20020120685A1 (en) * | 1999-06-01 | 2002-08-29 | Alok Srivastava | System for dynamically invoking remote network services using service descriptions stored in a service registry |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2633800A (en) | 1999-01-29 | 2000-08-18 | Object Design, Inc. | Database management system with capability of fine-grained indexing and querying |
-
2001
- 2001-05-17 US US09/859,256 patent/US7028028B1/en not_active Expired - Lifetime
-
2006
- 2006-01-23 US US11/338,339 patent/US20060179049A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5970490A (en) * | 1996-11-05 | 1999-10-19 | Xerox Corporation | Integration platform for heterogeneous databases |
US6202072B1 (en) * | 1997-05-08 | 2001-03-13 | Jusystem Corp. | Method and apparatus for processing standard generalized markup language (SGML) and converting between SGML and plain text using a prototype and document type definition |
US6105043A (en) * | 1997-12-16 | 2000-08-15 | International Business Machines Corporation | Creating macro language files for executing structured query language (SQL) queries in a relational database via a network |
US6009436A (en) * | 1997-12-23 | 1999-12-28 | Ricoh Company, Ltd. | Method and apparatus for mapping structured information to different structured information |
US6154738A (en) * | 1998-03-27 | 2000-11-28 | Call; Charles Gainor | Methods and apparatus for disseminating product information via the internet using universal product codes |
US20020120685A1 (en) * | 1999-06-01 | 2002-08-29 | Alok Srivastava | System for dynamically invoking remote network services using service descriptions stored in a service registry |
US6418448B1 (en) * | 1999-12-06 | 2002-07-09 | Shyam Sundar Sarkar | Method and apparatus for processing markup language specifications for data and metadata used inside multiple related internet documents to navigate, query and manipulate information from a plurality of object relational databases over the web |
US20020107889A1 (en) * | 2001-02-08 | 2002-08-08 | Tilion Corporation | Markup language routing and administration |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070219976A1 (en) * | 2006-03-20 | 2007-09-20 | Microsoft Corporation | Extensible query language with support for rich data types |
US7797304B2 (en) * | 2006-03-20 | 2010-09-14 | Microsoft Corporation | Extensible query language with support for rich data types |
US20090164413A1 (en) * | 2007-12-21 | 2009-06-25 | Sap Ag | Generic table structure to xml structure mapping |
US20100094838A1 (en) * | 2008-10-10 | 2010-04-15 | Ants Software Inc. | Compatibility Server for Database Rehosting |
CN107679172A (en) * | 2017-09-29 | 2018-02-09 | 北京奇艺世纪科技有限公司 | A kind of query statistic method and device of data |
Also Published As
Publication number | Publication date |
---|---|
US7028028B1 (en) | 2006-04-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7028028B1 (en) | System for querying markup language data stored in a relational database according to markup language schema | |
US7024425B2 (en) | Method and apparatus for flexible storage and uniform manipulation of XML data in a relational database system | |
US6947945B1 (en) | Using an XML query language to publish relational data as XML | |
CN1705945B (en) | Method and system for providing query attributes | |
US7149752B2 (en) | Method for simplifying databinding in application programs | |
US7502779B2 (en) | Semantics-based searching for information in a distributed data processing system | |
US7165073B2 (en) | Dynamic, hierarchical data exchange system | |
US8019770B1 (en) | Dynamic rendering of content that includes query expressions | |
US7747610B2 (en) | Database system and methodology for processing path based queries | |
US7188100B2 (en) | Search-on-the-fly report generator | |
US6292802B1 (en) | Methods and system for using web browser to search large collections of documents | |
US7162484B2 (en) | Method and system for hierarchical visibility marks for hierarchical elements in hierarchical database structure, filtering hierarchical elements, hide any hierarchical element not having either a user hierarchical visibility mark or a propagated hierarchical visibility mark | |
US8370375B2 (en) | Method for presenting database query result sets using polymorphic output formats | |
US20050120016A1 (en) | Searching in a computer network | |
US7133864B2 (en) | System and method for accessing biological data | |
US7440963B1 (en) | Rewriting a query to use a set of materialized views and database objects | |
US20050138052A1 (en) | Method, computer program product, and system converting relational data into hierarchical data structure based upon tagging trees | |
US20030030656A1 (en) | Method and system for dynamic hierarchical data display | |
US20040249824A1 (en) | Semantics-bases indexing in a distributed data processing system | |
KR20030048423A (en) | A universal output constructor for xml queries | |
US20080140694A1 (en) | Data transformation between databases with dissimilar schemes | |
US7966312B2 (en) | Updatable result set for multiple joined tables | |
US20040049495A1 (en) | System and method for automatically generating general queries | |
US8090737B2 (en) | User dictionary term criteria conditions | |
US7574421B2 (en) | Explicit key paging |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |