US20080082514A1 - Method and apparatus for integrating relational and hierarchical data - Google Patents
Method and apparatus for integrating relational and hierarchical data Download PDFInfo
- Publication number
- US20080082514A1 US20080082514A1 US11/541,260 US54126006A US2008082514A1 US 20080082514 A1 US20080082514 A1 US 20080082514A1 US 54126006 A US54126006 A US 54126006A US 2008082514 A1 US2008082514 A1 US 2008082514A1
- Authority
- US
- United States
- Prior art keywords
- schema
- data
- relational
- query
- language
- 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
Definitions
- the present invention relates generally to data processing techniques and, more particularly, to techniques for integrating relational and hierarchical data, schema definitions, and queries in a data processing system.
- XML is a specification language created to describe data interchange formats and data semantics.
- An XML document consists of data annotation tags that represent relationships between data values.
- An XML schema is an auxiliary document describing the structure of an XML document making it easier to interpret.
- XQuery is a language for querying information from XML documents.
- a relational table is a data structure that represents a mathematical mapping between one or more types of data. Relational databases store information by organizing data in normalized tables where the stored information can be retrieved through querying languages based on Relational Algebra, an example being Structured Query Language (SQL).
- SQL Structured Query Language
- the present invention provides techniques for integrating relational and hierarchical data, schema definitions, and queries in a data processing system through the use of an intermediate data language. While not limited thereto, such techniques have been developed and tested for use with XML documents and schemas, and XQuery and SQL language for querying.
- a method for integrating relational and hierarchical data, schema definitions, and queries in a data processing system It is determined if one or more schema definitions or one or more query expressions are provided as input to the data processing system.
- the one or more schema definitions are converted into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided.
- the one or more query expressions are converted into an intermediate query language component of the intermediate data language when one or more query expressions are provided.
- the intermediate schema language component or the intermediate query language component is compiled in an intermediate data language processing engine into a run-time representation in accordance with a relational-hierarchical analysis.
- the one or more schema definitions may be relational schema or hierarchical schema.
- the one or more query expressions may be one or more relational query expressions or one or more hierarchical query expressions.
- the compiling step may include analyzing the intermediate schema language component or the intermediate query language component to capture relationships between at least one of relational tuples and hierarchical data. The steps of determining, converting and compiling may be repeated for additional input data, and the compiling step may be performed in accordance with relationships between at least one of relational tuples and hierarchical data captured from previously input data.
- the analyzing step may include the step of computing functional dependency information for augmentation with the intermediate schema language component or the intermediate query language component.
- the functional dependency information may be utilized to determine redundant cells and a hierarchical representation of the intermediate schema language component or the intermediate query language component.
- FIG. 1 is a block diagram illustrating a process for integrating relational data expressions and hierarchical data expressions, according to an embodiment of the present invention
- FIG. 2 is a table illustrating a set of flat relations, according to an embodiment of the present invention.
- FIG. 3 is set of tables illustrating a set of nested relations having functional dependencies, corresponding to the flat relations of FIG. 2 , according to an embodiment of the present invention
- FIG. 4 is a table illustrating a set of flat relations with corresponding functional dependencies, according to an embodiment of the present invention
- FIG. 5 is a set of tables illustrating a naming scheme allowing nested relations to be treated as flat, according to an embodiment of the present invention
- FIG. 6 is a table illustrating rules used by the intermediate data language for deriving functional dependencies during querying, according to an embodiment of the present invention
- FIG. 7 is a flow diagram illustrating a relational/hierarchical data expression conversion methodology, according to an embodiment of the present invention.
- FIG. 8 is a diagram illustrating an illustrative hardware implementation of a computing system in accordance with which one or more components/methodologies of the present invention may be implemented, according to an embodiment of the present invention.
- the present invention introduces techniques for integrating relational and hierarchical data, schema definitions, and queries through the use of an intermediate data language.
- hierarchical data may generally refer to a structure of data having several levels arranged in a tree-like structure.
- relational data may refer to a structure of data that is represented as a series of mathematical relations.
- a relational database stores information by organizing data into normalized flat tables, without the multiple levels of nesting seen in a database with a hierarchical structure.
- functional dependency as used herein may refer to a mathematical relation between sets of columns in a given database. If a first column set depends on a second column set such that for a unique combination of values for the first column set there is at most one value for each column of the second column set, then a functional dependency exists between the two columns.
- FIG. 1 a block diagram illustrates a process for integrating relational data expressions and hierarchical data expressions, according to an embodiment of the present invention.
- the process converts relational and hierarchical inputs into a relational like intermediate data language.
- Relational and hierarchical data expressions 100 are input to an intermediate data language converter 110 resulting in the conversion of relational and hierarchical data expressions 100 into an intermediate data language 120 .
- Relational and hierarchical data expressions 100 now expressed in intermediate data language 120 are passed to an intermediate data language processing engine 130 that uses the data definitions and queries to process the data.
- Data 140 can then be stored in a database system or any system designed for processing structured, schematized data.
- this process allows for queries written in a relational language (SQL) to be processed against hierarchical data and vice versa.
- SQL relational language
- relational and hierarchical data expressions 100 may include schematized data in relational form 102 , schematized data in hierarchical form 104 , query expressions written in a relational language 106 and query expressions written in a hierarchical language 108 .
- Schematized relational data 102 is input into a relational schema to IDL converter 112 which converts the data into an intermediate schema language 122 .
- the data may be input into block 130 in accordance with the steps described above.
- Schematized hierarchical data 104 is input into a hierarchical schema to IDL schema converter 114 which converts the data into intermediate schema language 122 .
- the data can be input into block 130 in accordance with the steps described above.
- Relational query expressions 106 are input into a relational query to IDL query converter 116 which converts the data into an intermediate query language 124 . Once in intermediate query language 124 , the data can be input into block 130 in accordance with the steps described above.
- Hierarchical query expressions 108 are input into a hierarchical query to IDL query converter 118 which converts the data into intermediate query language 124 . Once in intermediate query language 124 , the data can be input into block 130 in accordance with the steps described above.
- the intermediate data language is based on classical relational algebra. This intermediate data language is extended however, to be substantially compatible with nested data.
- the intermediate data language encompasses core relational operators for queries, including, the “select”, “extend”, “project”, “top k”, “join”, “merge”, “combine” and “split” operators in addition to several other arithmetic, logical and comparison operators.
- FIG. 2 a table illustrates a set of flat relations according to an embodiment of the present invention.
- This is a more detailed example of block 102 of FIG. 1 , which shows schematized relational data.
- the set of relations shown in this figure is typical of what would be stored in a relational data structure.
- the figure shows a flat table with relations “T”, “Flight No”, “Seats Booked”, “Passengers.ID.” and “Passengers.Name.”
- FIG. 3 a set of tables illustrates a set of nested relations having functional dependencies, corresponding to the flat relations of FIG. 2 , according to an embodiment of the present invention.
- the nested relations shown in FIG. 3 are an example of a hierarchical schematized data expression as shown in block 104 of FIG. 1 .
- the table of functional dependencies demonstrates that with the data in field “T” the data in fields “Flight No” and “Seats Booked” may be determined, and with the data in fields “T” and “Passengers.ID” the data in the field “Passengers.Name” may be determined.
- the set of nested relations is equivalent to a corresponding set of flat relations with identical functional dependencies as shown in FIG. 2 .
- the set of nested relations is also equivalent to a denormalized flat relation which is the join of the set of normalized flat relations.
- the intermediate language treats the query as if it were executed over this denormalized relation, however, at execution time, the compiler actually represents the data more compactly either as a hierarchical structure, or as a set of normalized tables.
- the denormalized form is one that would be very inefficient if actually materialized, but it allows queries either in an SQL-like form or in an XQUERY-like form to be interpreted appropriately. This assumes that the compiler retains the functional dependencies.
- FIG. 4 a set of tables illustrates flat relations with corresponding functional dependencies, according to an embodiment of the present invention.
- FIG. 4 illustrates a typical set of functional dependencies for a flat set of relations.
- the nesting structure of a given relation can be inferred from the given relation's functional dependencies.
- a set of tables illustrates a naming scheme allowing nested relations to be treated as flat, according to an embodiment of the present invention.
- the names of the inner columns are prepended with the names of the inner relations.
- This naming scheme is important in allowing intermediate data language, specifically block 120 of FIG. 1 , to extend the traditional relational algebra to be substantially compatible with nested relations. If the nested relations are analogized to a tree like structure, then the column name outlines a path in that tree to where the column would be located.
- the upper table of FIG. 5 shows relations “T”, “Flight No.”, “Seats Booked” and “Passengers”. Within the field “Passengers”, there are the nested fields “ID”, “Name” and “Emergency Contacts”. Within the nested field “Emergency Contacts” there is the further nested fields of “ID” and “Name”.
- the lower table of FIG. 5 shows how to express these nested relations as flat. This table contains the fields “T”, “Flight No” and “Seats Booked,” however, unlike on the upper table of FIG. 5 , the relations nested within the field “Passengers” are expressed differently.
- Passengers is simply prepended onto the fields of “ID”, “Name” and “Emergency Contacts”, and both the term “Passengers” and “Emergency Contacts” are prepended onto the fields of “ID” and “Name”.
- the prepending of terms allows the information of the nested relations to be accurately expressed in a table of flat relations, thus allowing intermediate data language to use classical relational algebra to express both hierarchical and relational data expressions.
- FIG. 6 a table illustrates the rules used by the compiler for the intermediate data language for deriving functional dependencies during querying, according to an embodiment of the present invention.
- column names and functional dependencies need to be derived.
- the rule for deriving functional dependencies is that when each non-key column depends on the key column in the current relation and on all key columns of outer relations (if there are any) then there is a functional dependency.
- FIG. 6 discloses functional dependency rules for the classical relational operators: “Extend”, “Select”, “Join”, “Merge”, “Top K”, “Project”, “Split” and “Combine”.
- the compiler for the intermediate data language has the additional task of generating efficient code for continuously updating views of stream data as messages appending new tuples to streams arrive.
- a type analysis step computes additional properties of columns of relation given the intermediate language expression that derived that relation, and given the properties of the relation or relations that were input to that expression. Starting with the user-specified schema of the input streams, the system will successively apply steps of type analysis to views derived from these streams, and then to view derived from these views, until these properties are derived for all views. These properties allow the run-time to efficiently compute not just the current value of each row and column of the relation, but also will compute whether and to what degree that value can change.
- This information is used both to advantageously compute whether an intermediate value needs to be saved, and it can also be used to signal to the consumer of such a view whether the value is final. A value which cannot change any more is final, and once it has been propagated to any views which need to know the vale it can be discarded. A consumer may wish to distinguish between the case where the number of responses received within the deadline is currently zero and the case where the number of responses received within the deadline is finally zero, because the deadline has passed.
- the additional information computed by type analysis includes: the maximum positive and negative components of values of aggregate types and the maximum number of steps needed to reach finality; and whether the column is masked as a result of another Boolean selection value, as in SELECT*FROM T WHERE X>Y, in which an intermediate column representing the Boolean intermediate value of X>Y is created, and each column is typed as being masked by this intermediate value.
- a flow diagram illustrates a relational/hierarchical data expression conversion methodology, according to an embodiment of the present invention.
- block 702 it is determined whether the data is schematized. If the data is schematized, block 704 determines whether the data is relational. If the data is relational then in block 706 a relational schema converter converts data to intermediate schema language. If the data is not relational, it is assumed that the data is hierarchical and then in block 708 a hierarchical schema converter converts data into intermediate schema language.
- Block 710 determines whether the data is relational. If the data is relational, then in block 712 a relational query converter converts data to an intermediate query language. If the data is not relational, it is assumed to be hierarchical, and in block 714 a hierarchical query converter converts data to intermediate query language. Once the data is in intermediate form, block 716 processes the data through an intermediate data language processing engine.
- FIG. 8 a block diagram illustrates an exemplary hardware implementation of a computing system in accordance with which one or more components/methodologies of the invention (e.g., components/methodologies described in the context of FIGS. 1-7 ) may be implemented, according to an embodiment of the present invention.
- one or more components/methodologies of the invention e.g., components/methodologies described in the context of FIGS. 1-7 .
- the computer system may be implemented in accordance with a processor 810 , a memory 812 , I/O devices 814 , and a network interface 816 , coupled via a computer bus 818 or alternate connection arrangement.
- processor as used herein is intended to include any processing device, such as, for example, one that includes a CPU (central processing unit) and/or other processing circuitry. It is also to be understood that the term “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices.
- memory as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc.
- input/output devices or “I/O devices” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, scanner, etc.) for entering data to the processing unit, and/or one or more output devices (e.g., speaker, display, printer, etc.) for presenting results associated with the processing unit.
- input devices e.g., keyboard, mouse, scanner, etc.
- output devices e.g., speaker, display, printer, etc.
- network interface as used herein is intended to include, for example, one or more transceivers to permit the computer system to communicate with another computer system via an appropriate communications protocol.
- Software components including instructions or code for performing the methodologies described herein may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU.
- ROM read-only memory
- RAM random access memory
Abstract
Methods and apparatus for integrating relational and hierarchical data, schema definitions, and queries in a data processing system are provided. It is determined if one or more schema definitions or one or more query expressions are provided as input to the data processing system. The one or more schema definitions are converted into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided. The one or more query expressions are converted into an intermediate query language component of the intermediate data language when one or more query expressions are provided. The intermediate schema language component or the intermediate query language component is compiled in an intermediate data language processing engine into a run-time representation in accordance with a relational-hierarchical analysis.
Description
- The present invention relates generally to data processing techniques and, more particularly, to techniques for integrating relational and hierarchical data, schema definitions, and queries in a data processing system.
- Two main standards of describing and querying data have evolved. One of these standards is based on a relational model that is used by most modern databases. The other is based on a hierarchical model, examples of which include, XML (Extensible Markup Language), XML Schema Language (XSD) and XQuery Language.
- XML is a specification language created to describe data interchange formats and data semantics. An XML document consists of data annotation tags that represent relationships between data values. An XML schema is an auxiliary document describing the structure of an XML document making it easier to interpret. XQuery is a language for querying information from XML documents.
- Before the inception of XML, the majority of data was stored in relational tables. A relational table is a data structure that represents a mathematical mapping between one or more types of data. Relational databases store information by organizing data in normalized tables where the stored information can be retrieved through querying languages based on Relational Algebra, an example being Structured Query Language (SQL).
- As XML continues to gain popularity, the need for effective integration of hierarchical data expressions and relational data expressions grows. Effective integration between the two has proven difficult because of key differences between them. For example, XML documents organize data in a hierarchical structure with multiple levels of nesting, while the relational model organizes data in flat tables with inter-table functional dependencies. Additionally, in hierarchical data expressions, document order of a node (the position each node occurs in the document) is important, while in relational data expressions document order is not relevant.
- Previous attempts have been made at developing techniques to effectively integrate hierarchical data schemas and relational data schemas. These attempts have suffered from problems such as excessive use of the computationally very expensive “join” operation. Such attempts include, XML shredding, as described in P. Bohannon et al., “LegoDB: Customizing Relational Storage for XML Documents,” 2002, mapping XML data values to a set of predefined tables based on node type, and mapping XML data to a relational table by number-encoding each of the XML data values.
- Attempts have also been made to convert queries written over hierarchical data into queries over relational data. These attempts have suffered shortfalls similar to those described above. These attempts are described in Y. Diao et al., “Towards an Internet-Scale XML Dissemination Service,” VLDB, 2004, and C. Koch et al., “FluXQuery: An Optimizing XQuery Processor for Streaming XML Data,” VLDB, 2005. These attempts include a pure XML engine to handle processing, and translating hierarchical queries into relational queries.
- Various techniques have been proposed for specifying “continuous queries” over steams. In these environments, data is not fixed, but arrives one message at a time in one or more continuous streams. Queries define views over the entire history of one or more streams. Rather than receiving a single result set, subscribers to continuous queries receive a continuously updated result set reflecting how the view changed as a result of the changes to the streams on which it depends. In a mixed environment, any of the following combinations are possible: schemas defined in a relational (SQL) or hierarchical style (XML); messages delivered in a relational (flat) or hierarchical format (XML); and queries written in a relation language (SQL) or hierarchical language (XQUERY/XSLT).
- The present invention provides techniques for integrating relational and hierarchical data, schema definitions, and queries in a data processing system through the use of an intermediate data language. While not limited thereto, such techniques have been developed and tested for use with XML documents and schemas, and XQuery and SQL language for querying.
- By way of example, in one aspect of the invention, a method for integrating relational and hierarchical data, schema definitions, and queries in a data processing system is provided. It is determined if one or more schema definitions or one or more query expressions are provided as input to the data processing system. The one or more schema definitions are converted into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided. The one or more query expressions are converted into an intermediate query language component of the intermediate data language when one or more query expressions are provided. The intermediate schema language component or the intermediate query language component is compiled in an intermediate data language processing engine into a run-time representation in accordance with a relational-hierarchical analysis.
- In an additional embodiment of the present invention, the one or more schema definitions may be relational schema or hierarchical schema. Further, the one or more query expressions may be one or more relational query expressions or one or more hierarchical query expressions.
- In another additional embodiment of the present invention, the compiling step may include analyzing the intermediate schema language component or the intermediate query language component to capture relationships between at least one of relational tuples and hierarchical data. The steps of determining, converting and compiling may be repeated for additional input data, and the compiling step may be performed in accordance with relationships between at least one of relational tuples and hierarchical data captured from previously input data.
- In further embodiments of the present invention, the analyzing step may include the step of computing functional dependency information for augmentation with the intermediate schema language component or the intermediate query language component. The functional dependency information may be utilized to determine redundant cells and a hierarchical representation of the intermediate schema language component or the intermediate query language component.
- These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
-
FIG. 1 is a block diagram illustrating a process for integrating relational data expressions and hierarchical data expressions, according to an embodiment of the present invention; -
FIG. 2 is a table illustrating a set of flat relations, according to an embodiment of the present invention; -
FIG. 3 is set of tables illustrating a set of nested relations having functional dependencies, corresponding to the flat relations ofFIG. 2 , according to an embodiment of the present invention; -
FIG. 4 is a table illustrating a set of flat relations with corresponding functional dependencies, according to an embodiment of the present invention; -
FIG. 5 is a set of tables illustrating a naming scheme allowing nested relations to be treated as flat, according to an embodiment of the present invention; -
FIG. 6 is a table illustrating rules used by the intermediate data language for deriving functional dependencies during querying, according to an embodiment of the present invention; -
FIG. 7 is a flow diagram illustrating a relational/hierarchical data expression conversion methodology, according to an embodiment of the present invention; and -
FIG. 8 is a diagram illustrating an illustrative hardware implementation of a computing system in accordance with which one or more components/methodologies of the present invention may be implemented, according to an embodiment of the present invention. - The following description will illustrate the present invention using exemplary data processing system architecture. It should be understood, however, that the invention is not limited to use with any particular system architecture. The invention is instead more generally applicable to any task that would benefit from the integration of hierarchical data expressions and relational data expressions.
- As will be illustrated below the present invention introduces techniques for integrating relational and hierarchical data, schema definitions, and queries through the use of an intermediate data language.
- As discussed herein the term “hierarchical data” may generally refer to a structure of data having several levels arranged in a tree-like structure. The term “relational data,” as used herein, may refer to a structure of data that is represented as a series of mathematical relations. By way of example, a relational database stores information by organizing data into normalized flat tables, without the multiple levels of nesting seen in a database with a hierarchical structure. The term “functional dependency” as used herein may refer to a mathematical relation between sets of columns in a given database. If a first column set depends on a second column set such that for a unique combination of values for the first column set there is at most one value for each column of the second column set, then a functional dependency exists between the two columns.
- Referring initially to
FIG. 1 , a block diagram illustrates a process for integrating relational data expressions and hierarchical data expressions, according to an embodiment of the present invention. The process converts relational and hierarchical inputs into a relational like intermediate data language. Relational andhierarchical data expressions 100 are input to an intermediatedata language converter 110 resulting in the conversion of relational andhierarchical data expressions 100 into anintermediate data language 120. Relational andhierarchical data expressions 100 now expressed inintermediate data language 120, are passed to an intermediate datalanguage processing engine 130 that uses the data definitions and queries to process the data.Data 140 can then be stored in a database system or any system designed for processing structured, schematized data. By way of example, this process allows for queries written in a relational language (SQL) to be processed against hierarchical data and vice versa. - As shown in
FIG. 1 , relational andhierarchical data expressions 100, may include schematized data inrelational form 102, schematized data inhierarchical form 104, query expressions written in arelational language 106 and query expressions written in ahierarchical language 108. Schematizedrelational data 102 is input into a relational schema toIDL converter 112 which converts the data into anintermediate schema language 122. Once inintermediate schema language 122, the data may be input intoblock 130 in accordance with the steps described above. Schematizedhierarchical data 104 is input into a hierarchical schema toIDL schema converter 114 which converts the data intointermediate schema language 122. Once inintermediate schema language 122, the data can be input intoblock 130 in accordance with the steps described above. -
Relational query expressions 106 are input into a relational query toIDL query converter 116 which converts the data into anintermediate query language 124. Once inintermediate query language 124, the data can be input intoblock 130 in accordance with the steps described above.Hierarchical query expressions 108 are input into a hierarchical query toIDL query converter 118 which converts the data intointermediate query language 124. Once inintermediate query language 124, the data can be input intoblock 130 in accordance with the steps described above. - The intermediate data language is based on classical relational algebra. This intermediate data language is extended however, to be substantially compatible with nested data. The intermediate data language encompasses core relational operators for queries, including, the “select”, “extend”, “project”, “top k”, “join”, “merge”, “combine” and “split” operators in addition to several other arithmetic, logical and comparison operators.
- Referring now to
FIG. 2 , a table illustrates a set of flat relations according to an embodiment of the present invention. This is a more detailed example ofblock 102 ofFIG. 1 , which shows schematized relational data. The set of relations shown in this figure is typical of what would be stored in a relational data structure. The figure shows a flat table with relations “T”, “Flight No”, “Seats Booked”, “Passengers.ID.” and “Passengers.Name.” - Referring now to
FIG. 3 , a set of tables illustrates a set of nested relations having functional dependencies, corresponding to the flat relations ofFIG. 2 , according to an embodiment of the present invention. The nested relations shown inFIG. 3 are an example of a hierarchical schematized data expression as shown inblock 104 ofFIG. 1 . The table of functional dependencies demonstrates that with the data in field “T” the data in fields “Flight No” and “Seats Booked” may be determined, and with the data in fields “T” and “Passengers.ID” the data in the field “Passengers.Name” may be determined. As can be seen from the figures, the set of nested relations is equivalent to a corresponding set of flat relations with identical functional dependencies as shown inFIG. 2 . - The set of nested relations is also equivalent to a denormalized flat relation which is the join of the set of normalized flat relations. The intermediate language treats the query as if it were executed over this denormalized relation, however, at execution time, the compiler actually represents the data more compactly either as a hierarchical structure, or as a set of normalized tables. The denormalized form is one that would be very inefficient if actually materialized, but it allows queries either in an SQL-like form or in an XQUERY-like form to be interpreted appropriately. This assumes that the compiler retains the functional dependencies.
- Referring now to
FIG. 4 , a set of tables illustrates flat relations with corresponding functional dependencies, according to an embodiment of the present invention.FIG. 4 illustrates a typical set of functional dependencies for a flat set of relations. As can be seen fromFIGS. 2 , 3 and 4, the nesting structure of a given relation can be inferred from the given relation's functional dependencies. - Referring now to
FIG. 5 , a set of tables illustrates a naming scheme allowing nested relations to be treated as flat, according to an embodiment of the present invention. In this naming scheme, the names of the inner columns are prepended with the names of the inner relations. This naming scheme is important in allowing intermediate data language, specifically block 120 ofFIG. 1 , to extend the traditional relational algebra to be substantially compatible with nested relations. If the nested relations are analogized to a tree like structure, then the column name outlines a path in that tree to where the column would be located. - The upper table of
FIG. 5 shows relations “T”, “Flight No.”, “Seats Booked” and “Passengers”. Within the field “Passengers”, there are the nested fields “ID”, “Name” and “Emergency Contacts”. Within the nested field “Emergency Contacts” there is the further nested fields of “ID” and “Name”. The lower table ofFIG. 5 shows how to express these nested relations as flat. This table contains the fields “T”, “Flight No” and “Seats Booked,” however, unlike on the upper table ofFIG. 5 , the relations nested within the field “Passengers” are expressed differently. The term “Passengers” is simply prepended onto the fields of “ID”, “Name” and “Emergency Contacts”, and both the term “Passengers” and “Emergency Contacts” are prepended onto the fields of “ID” and “Name”. The prepending of terms allows the information of the nested relations to be accurately expressed in a table of flat relations, thus allowing intermediate data language to use classical relational algebra to express both hierarchical and relational data expressions. - Referring now to
FIG. 6 , a table illustrates the rules used by the compiler for the intermediate data language for deriving functional dependencies during querying, according to an embodiment of the present invention. To interpret queries written in the intermediate data language, column names and functional dependencies need to be derived. For relations specified by hierarchical data expressions or relational data expressions the rule for deriving functional dependencies is that when each non-key column depends on the key column in the current relation and on all key columns of outer relations (if there are any) then there is a functional dependency. For relations derived via querying, the rules inFIG. 6 are used.FIG. 6 discloses functional dependency rules for the classical relational operators: “Extend”, “Select”, “Join”, “Merge”, “Top K”, “Project”, “Split” and “Combine”. - In a streaming system, the compiler for the intermediate data language has the additional task of generating efficient code for continuously updating views of stream data as messages appending new tuples to streams arrive. A type analysis step computes additional properties of columns of relation given the intermediate language expression that derived that relation, and given the properties of the relation or relations that were input to that expression. Starting with the user-specified schema of the input streams, the system will successively apply steps of type analysis to views derived from these streams, and then to view derived from these views, until these properties are derived for all views. These properties allow the run-time to efficiently compute not just the current value of each row and column of the relation, but also will compute whether and to what degree that value can change.
- This information is used both to advantageously compute whether an intermediate value needs to be saved, and it can also be used to signal to the consumer of such a view whether the value is final. A value which cannot change any more is final, and once it has been propagated to any views which need to know the vale it can be discarded. A consumer may wish to distinguish between the case where the number of responses received within the deadline is currently zero and the case where the number of responses received within the deadline is finally zero, because the deadline has passed.
- The additional information computed by type analysis includes: the maximum positive and negative components of values of aggregate types and the maximum number of steps needed to reach finality; and whether the column is masked as a result of another Boolean selection value, as in SELECT*FROM T WHERE X>Y, in which an intermediate column representing the Boolean intermediate value of X>Y is created, and each column is typed as being masked by this intermediate value.
- Functional dependencies alone can specify how many values are in a given column. For example, if column X depends on columns (K1, K2,) and there are 100 values for K1 and 4 values for K2, there could be at most 4*100 values of X.
- Referring now to
FIG. 7 , a flow diagram illustrates a relational/hierarchical data expression conversion methodology, according to an embodiment of the present invention. Inblock 702 it is determined whether the data is schematized. If the data is schematized, block 704 determines whether the data is relational. If the data is relational then in block 706 a relational schema converter converts data to intermediate schema language. If the data is not relational, it is assumed that the data is hierarchical and then in block 708 a hierarchical schema converter converts data into intermediate schema language. - If it is determined that the data is not schematized in
block 702, it is assumed that the data is a query.Block 710 then determines whether the data is relational. If the data is relational, then in block 712 a relational query converter converts data to an intermediate query language. If the data is not relational, it is assumed to be hierarchical, and in block 714 a hierarchical query converter converts data to intermediate query language. Once the data is in intermediate form, block 716 processes the data through an intermediate data language processing engine. - Referring now to
FIG. 8 , a block diagram illustrates an exemplary hardware implementation of a computing system in accordance with which one or more components/methodologies of the invention (e.g., components/methodologies described in the context ofFIGS. 1-7 ) may be implemented, according to an embodiment of the present invention. - As shown, the computer system may be implemented in accordance with a
processor 810, amemory 812, I/O devices 814, and anetwork interface 816, coupled via acomputer bus 818 or alternate connection arrangement. - It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a CPU (central processing unit) and/or other processing circuitry. It is also to be understood that the term “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices.
- The term “memory” as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc.
- In addition, the phrase “input/output devices” or “I/O devices” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, scanner, etc.) for entering data to the processing unit, and/or one or more output devices (e.g., speaker, display, printer, etc.) for presenting results associated with the processing unit.
- Still further, the phrase “network interface” as used herein is intended to include, for example, one or more transceivers to permit the computer system to communicate with another computer system via an appropriate communications protocol.
- Software components including instructions or code for performing the methodologies described herein may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU.
- Although illustrative embodiments of the present invention have been described herein with references to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
-
- The following listing of claims will replace all prior versions and listings of claims in the above-referenced application:
Claims (20)
1. A method for integrating relational and hierarchical data, schema definitions, and queries in a data processing system, comprising the steps of:
converting one or more schema definitions into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided;
converting one or more query expressions into an intermediate query language component of the intermediate data language when one or more query expressions are provided; and
compiling, in an intermediate data language processing engine, at least one of the intermediate schema language component and the intermediate query language component into a run-time representation in accordance with a relational-hierarchical analysis.
2. The method of claim 1 , wherein, in the step of converting the one or more schema definitions, the one or more schema definitions comprise at least one of relational schema and hierarchical schema.
3. The method of claim 1 , wherein, in the step of converting the one or more query expressions, the one or more query expressions comprise at least one of one or more relational query expressions and one or more hierarchical query expressions.
4. The method of claim 1 , wherein the compiling step comprises the step of analyzing at least one of the intermediate schema language component and the intermediate query language component to capture relationships between at least one of relational tuples and hierarchical data.
5. The method of claim 4 , further comprising the step of choosing a preferred run-time representation for the intermediate schema language component in accordance with the analysis of at least one of the intermediate schema language component and the intermediate query language component.
6. The method of claim 4 , further comprising the step of repeating the converting and compiling steps for additional input data, wherein the compiling step is performed in accordance with relationships between at least one of relational tuples and hierarchical data captured from previously input data.
7. The method of claim 4 , wherein the analyzing step comprises the step of computing functional dependency information for augmentation with at least one of the intermediate schema language component and the intermediate query language component.
8. The method of claim 7 , wherein, in the analyzing step, the functional dependency information is utilized to determine redundant cells and a hierarchical representation of at least one of the intermediate schema language component and the intermediate query language component.
9. The method of claim 7 , wherein at least one of the intermediate schema language component and the intermediate query language component comprises inner column names prepended with the names of the inner relations.
10. The method of claim 7 , wherein the analyzing step comprises the step of computing at least one of maximum value ranges, maximum steps to value finality, and masking of columns as a result of a Boolean selection value.
11. The method of claim 1 , wherein the one or more query expressions comprise continuous queries over streaming data.
12. The method of claim 1 , wherein at least one of the intermediate schema language component and the intermediate query language component comprises classical relational algebra.
13. The method of claim 1 , wherein the intermediate schema language component comprises one or more of the core relational operators.
14. Apparatus for integrating relational and hierarchical data, schema definitions, and queries in a data processing system, comprising:
a memory; and
at least one processor coupled to the memory and operative to: (i) convert one or more schema definitions into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided; (ii) convert one or more query expressions into an intermediate query language component of the intermediate data language when one or more query expressions are provided; and (iii) compile, in an intermediate data language processing engine, at least one of the intermediate schema language component and the intermediate query language component into a run-time representation in accordance with a relational-hierarchical analysis.
15. The apparatus of claim 14 , wherein, in the operation of converting the one or more schema definitions, the one or more schema definitions comprise at least one of relational schema and hierarchical schema.
16. The apparatus of claim 14 , wherein, in the operation of converting the one or more query expressions, the one or more query expressions comprise at least one of one or more relational query expressions and one or more hierarchical query expressions.
17. The apparatus of claim 14 , wherein the compiling operation comprises the step of analyzing at least one of the intermediate schema language component and the intermediate query language component to capture relationships between at least one of relational tuples and hierarchical data.
18. The apparatus of claim 17 , further comprising the operation of repeating the converting and compiling steps for additional input data, wherein the compiling operation is, performed in accordance with relationships between at least one of relational tuples and hierarchical data captured from previously input data.
19. The apparatus of claim 17 , wherein the analyzing operation comprises the step of computing functional dependency information for augmentation with at least one of the intermediate schema language component and the intermediate query language component.
20. An article of manufacture for integrating relational and hierarchical data, schema definitions, and queries in a data processing system, comprising a machine readable medium containing one or more programs which when executed implement the steps of:
converting one or more schema definitions into an intermediate schema language component of an intermediate data language when one or more schema definitions are provided;
converting one or more query expressions into an intermediate query language component of the intermediate data language when one or more query expressions are provided; and
compiling, in an intermediate data language processing engine, at least one of the intermediate schema language component and the intermediate query language component into a run-time representation in accordance with a relational-hierarchical analysis.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/541,260 US20080082514A1 (en) | 2006-09-29 | 2006-09-29 | Method and apparatus for integrating relational and hierarchical data |
PCT/EP2007/059304 WO2008037572A1 (en) | 2006-09-29 | 2007-09-05 | Method and apparatus for integrating relational and hierarchical data |
US12/580,815 US8543589B2 (en) | 2006-09-29 | 2009-10-16 | Method and apparatus for integrating relational and hierarchical data |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/541,260 US20080082514A1 (en) | 2006-09-29 | 2006-09-29 | Method and apparatus for integrating relational and hierarchical data |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/580,815 Continuation US8543589B2 (en) | 2006-09-29 | 2009-10-16 | Method and apparatus for integrating relational and hierarchical data |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080082514A1 true US20080082514A1 (en) | 2008-04-03 |
Family
ID=38625872
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/541,260 Abandoned US20080082514A1 (en) | 2006-09-29 | 2006-09-29 | Method and apparatus for integrating relational and hierarchical data |
US12/580,815 Expired - Fee Related US8543589B2 (en) | 2006-09-29 | 2009-10-16 | Method and apparatus for integrating relational and hierarchical data |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/580,815 Expired - Fee Related US8543589B2 (en) | 2006-09-29 | 2009-10-16 | Method and apparatus for integrating relational and hierarchical data |
Country Status (2)
Country | Link |
---|---|
US (2) | US20080082514A1 (en) |
WO (1) | WO2008037572A1 (en) |
Cited By (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080120283A1 (en) * | 2006-11-17 | 2008-05-22 | Oracle International Corporation | Processing XML data stream(s) using continuous queries in a data stream management system |
US20090100029A1 (en) * | 2007-10-16 | 2009-04-16 | Oracle International Corporation | Handling Silent Relations In A Data Stream Management System |
US20090106189A1 (en) * | 2007-10-17 | 2009-04-23 | Oracle International Corporation | Dynamically Sharing A Subtree Of Operators In A Data Stream Management System Operating On Existing Queries |
US20100057736A1 (en) * | 2008-08-29 | 2010-03-04 | Oracle International Corporation | Techniques for performing regular expression-based pattern matching in data streams |
US20100223305A1 (en) * | 2009-03-02 | 2010-09-02 | Oracle International Corporation | Infrastructure for spilling pages to a persistent store |
US20100223606A1 (en) * | 2009-03-02 | 2010-09-02 | Oracle International Corporation | Framework for dynamically generating tuple and page classes |
US20110023055A1 (en) * | 2009-07-21 | 2011-01-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server |
US20110022618A1 (en) * | 2009-07-21 | 2011-01-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server in an embedded context |
US20110029484A1 (en) * | 2009-08-03 | 2011-02-03 | Oracle International Corporation | Logging framework for a data stream processing server |
US20110029485A1 (en) * | 2009-08-03 | 2011-02-03 | Oracle International Corporation | Log visualization tool for a data stream processing server |
US20110161352A1 (en) * | 2009-12-28 | 2011-06-30 | Oracle International Corporation | Extensible indexing framework using data cartridges |
US20110161328A1 (en) * | 2009-12-28 | 2011-06-30 | Oracle International Corporation | Spatial data cartridge for event processing systems |
US8145859B2 (en) | 2009-03-02 | 2012-03-27 | Oracle International Corporation | Method and system for spilling from a queue to a persistent store |
US8713049B2 (en) | 2010-09-17 | 2014-04-29 | Oracle International Corporation | Support for a parameterized query/view in complex event processing |
US8959106B2 (en) | 2009-12-28 | 2015-02-17 | Oracle International Corporation | Class loading using java data cartridges |
US8990416B2 (en) | 2011-05-06 | 2015-03-24 | Oracle International Corporation | Support for a new insert stream (ISTREAM) operation in complex event processing (CEP) |
US9049196B1 (en) * | 2003-03-15 | 2015-06-02 | SQLStream, Inc. | Method for distributed RDSMS |
US9047249B2 (en) | 2013-02-19 | 2015-06-02 | Oracle International Corporation | Handling faults in a continuous event processing (CEP) system |
US9098587B2 (en) | 2013-01-15 | 2015-08-04 | Oracle International Corporation | Variable duration non-event pattern matching |
US9189280B2 (en) | 2010-11-18 | 2015-11-17 | Oracle International Corporation | Tracking large numbers of moving objects in an event processing system |
US9244978B2 (en) | 2014-06-11 | 2016-01-26 | Oracle International Corporation | Custom partitioning of a data stream |
US9256646B2 (en) | 2012-09-28 | 2016-02-09 | Oracle International Corporation | Configurable data windows for archived relations |
US9262479B2 (en) | 2012-09-28 | 2016-02-16 | Oracle International Corporation | Join operations for continuous queries over archived views |
US9292267B2 (en) * | 2014-06-27 | 2016-03-22 | International Business Machines Corporation | Compiling nested relational algebras with multiple intermediate representations |
US9329975B2 (en) | 2011-07-07 | 2016-05-03 | Oracle International Corporation | Continuous query language (CQL) debugger in complex event processing (CEP) |
US20160132496A1 (en) * | 2014-11-06 | 2016-05-12 | Unmesh Gandhi | Data filtering |
US9390135B2 (en) | 2013-02-19 | 2016-07-12 | Oracle International Corporation | Executing continuous event processing (CEP) queries in parallel |
US9418113B2 (en) | 2013-05-30 | 2016-08-16 | Oracle International Corporation | Value based windows on relations in continuous data streams |
US9712645B2 (en) | 2014-06-26 | 2017-07-18 | Oracle International Corporation | Embedded event processing |
US20170308555A1 (en) * | 2016-04-22 | 2017-10-26 | International Business Machines Corporation | Database algebra and compiler with environments |
US9886486B2 (en) | 2014-09-24 | 2018-02-06 | Oracle International Corporation | Enriching events with dynamically typed big data for event processing |
US9934279B2 (en) | 2013-12-05 | 2018-04-03 | Oracle International Corporation | Pattern matching across multiple input data streams |
US9972103B2 (en) | 2015-07-24 | 2018-05-15 | Oracle International Corporation | Visually exploring and analyzing event streams |
US10120907B2 (en) | 2014-09-24 | 2018-11-06 | Oracle International Corporation | Scaling event processing using distributed flows and map-reduce operations |
US10298444B2 (en) | 2013-01-15 | 2019-05-21 | Oracle International Corporation | Variable duration windows on continuous data streams |
US10956422B2 (en) | 2012-12-05 | 2021-03-23 | Oracle International Corporation | Integrating event processing with map-reduce |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8527532B2 (en) * | 2012-01-31 | 2013-09-03 | Adobe Systems Incorporated | Transforming function calls for interaction with hierarchical data structures |
US10810219B2 (en) | 2014-06-09 | 2020-10-20 | Micro Focus Llc | Top-k projection |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5295256A (en) * | 1990-12-14 | 1994-03-15 | Racal-Datacom, Inc. | Automatic storage of persistent objects in a relational schema |
US20040260691A1 (en) * | 2003-06-23 | 2004-12-23 | Desai Arpan A. | Common query runtime system and application programming interface |
US6947945B1 (en) * | 2000-03-21 | 2005-09-20 | International Business Machines Corporation | Using an XML query language to publish relational data as XML |
US20050234889A1 (en) * | 2001-05-25 | 2005-10-20 | Joshua Fox | Method and system for federated querying of data sources |
US20060179068A1 (en) * | 2005-02-10 | 2006-08-10 | Warner James W | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7519577B2 (en) * | 2003-06-23 | 2009-04-14 | Microsoft Corporation | Query intermediate language method and system |
-
2006
- 2006-09-29 US US11/541,260 patent/US20080082514A1/en not_active Abandoned
-
2007
- 2007-09-05 WO PCT/EP2007/059304 patent/WO2008037572A1/en active Application Filing
-
2009
- 2009-10-16 US US12/580,815 patent/US8543589B2/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5295256A (en) * | 1990-12-14 | 1994-03-15 | Racal-Datacom, Inc. | Automatic storage of persistent objects in a relational schema |
US6947945B1 (en) * | 2000-03-21 | 2005-09-20 | International Business Machines Corporation | Using an XML query language to publish relational data as XML |
US20050234889A1 (en) * | 2001-05-25 | 2005-10-20 | Joshua Fox | Method and system for federated querying of data sources |
US20040260691A1 (en) * | 2003-06-23 | 2004-12-23 | Desai Arpan A. | Common query runtime system and application programming interface |
US20060179068A1 (en) * | 2005-02-10 | 2006-08-10 | Warner James W | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
Cited By (79)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9049196B1 (en) * | 2003-03-15 | 2015-06-02 | SQLStream, Inc. | Method for distributed RDSMS |
US20080120283A1 (en) * | 2006-11-17 | 2008-05-22 | Oracle International Corporation | Processing XML data stream(s) using continuous queries in a data stream management system |
US20090100029A1 (en) * | 2007-10-16 | 2009-04-16 | Oracle International Corporation | Handling Silent Relations In A Data Stream Management System |
US7979420B2 (en) | 2007-10-16 | 2011-07-12 | Oracle International Corporation | Handling silent relations in a data stream management system |
US20090106189A1 (en) * | 2007-10-17 | 2009-04-23 | Oracle International Corporation | Dynamically Sharing A Subtree Of Operators In A Data Stream Management System Operating On Existing Queries |
US8296316B2 (en) | 2007-10-17 | 2012-10-23 | Oracle International Corporation | Dynamically sharing a subtree of operators in a data stream management system operating on existing queries |
US20100057663A1 (en) * | 2008-08-29 | 2010-03-04 | Oracle International Corporation | Techniques for matching a certain class of regular expression-based patterns in data streams |
US20100057735A1 (en) * | 2008-08-29 | 2010-03-04 | Oracle International Corporation | Framework for supporting regular expression-based pattern matching in data streams |
US8676841B2 (en) | 2008-08-29 | 2014-03-18 | Oracle International Corporation | Detection of recurring non-occurrences of events using pattern matching |
US8589436B2 (en) | 2008-08-29 | 2013-11-19 | Oracle International Corporation | Techniques for performing regular expression-based pattern matching in data streams |
US8498956B2 (en) | 2008-08-29 | 2013-07-30 | Oracle International Corporation | Techniques for matching a certain class of regular expression-based patterns in data streams |
US9305238B2 (en) | 2008-08-29 | 2016-04-05 | Oracle International Corporation | Framework for supporting regular expression-based pattern matching in data streams |
US20100057736A1 (en) * | 2008-08-29 | 2010-03-04 | Oracle International Corporation | Techniques for performing regular expression-based pattern matching in data streams |
US20100223606A1 (en) * | 2009-03-02 | 2010-09-02 | Oracle International Corporation | Framework for dynamically generating tuple and page classes |
US20100223305A1 (en) * | 2009-03-02 | 2010-09-02 | Oracle International Corporation | Infrastructure for spilling pages to a persistent store |
US8352517B2 (en) | 2009-03-02 | 2013-01-08 | Oracle International Corporation | Infrastructure for spilling pages to a persistent store |
US8145859B2 (en) | 2009-03-02 | 2012-03-27 | Oracle International Corporation | Method and system for spilling from a queue to a persistent store |
US8387076B2 (en) | 2009-07-21 | 2013-02-26 | Oracle International Corporation | Standardized database connectivity support for an event processing server |
US20110023055A1 (en) * | 2009-07-21 | 2011-01-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server |
US20110022618A1 (en) * | 2009-07-21 | 2011-01-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server in an embedded context |
US8321450B2 (en) | 2009-07-21 | 2012-11-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server in an embedded context |
US20110029485A1 (en) * | 2009-08-03 | 2011-02-03 | Oracle International Corporation | Log visualization tool for a data stream processing server |
US8386466B2 (en) | 2009-08-03 | 2013-02-26 | Oracle International Corporation | Log visualization tool for a data stream processing server |
US20110029484A1 (en) * | 2009-08-03 | 2011-02-03 | Oracle International Corporation | Logging framework for a data stream processing server |
US8527458B2 (en) | 2009-08-03 | 2013-09-03 | Oracle International Corporation | Logging framework for a data stream processing server |
US8959106B2 (en) | 2009-12-28 | 2015-02-17 | Oracle International Corporation | Class loading using java data cartridges |
US20110161352A1 (en) * | 2009-12-28 | 2011-06-30 | Oracle International Corporation | Extensible indexing framework using data cartridges |
US8447744B2 (en) | 2009-12-28 | 2013-05-21 | Oracle International Corporation | Extensibility platform using data cartridges |
US9305057B2 (en) | 2009-12-28 | 2016-04-05 | Oracle International Corporation | Extensible indexing framework using data cartridges |
US20110161321A1 (en) * | 2009-12-28 | 2011-06-30 | Oracle International Corporation | Extensibility platform using data cartridges |
US20110161328A1 (en) * | 2009-12-28 | 2011-06-30 | Oracle International Corporation | Spatial data cartridge for event processing systems |
US9058360B2 (en) | 2009-12-28 | 2015-06-16 | Oracle International Corporation | Extensible language framework using data cartridges |
US9430494B2 (en) | 2009-12-28 | 2016-08-30 | Oracle International Corporation | Spatial data cartridge for event processing systems |
US8713049B2 (en) | 2010-09-17 | 2014-04-29 | Oracle International Corporation | Support for a parameterized query/view in complex event processing |
US9110945B2 (en) | 2010-09-17 | 2015-08-18 | Oracle International Corporation | Support for a parameterized query/view in complex event processing |
US9189280B2 (en) | 2010-11-18 | 2015-11-17 | Oracle International Corporation | Tracking large numbers of moving objects in an event processing system |
US9756104B2 (en) | 2011-05-06 | 2017-09-05 | Oracle International Corporation | Support for a new insert stream (ISTREAM) operation in complex event processing (CEP) |
US8990416B2 (en) | 2011-05-06 | 2015-03-24 | Oracle International Corporation | Support for a new insert stream (ISTREAM) operation in complex event processing (CEP) |
US9535761B2 (en) | 2011-05-13 | 2017-01-03 | Oracle International Corporation | Tracking large numbers of moving objects in an event processing system |
US9804892B2 (en) | 2011-05-13 | 2017-10-31 | Oracle International Corporation | Tracking large numbers of moving objects in an event processing system |
US9329975B2 (en) | 2011-07-07 | 2016-05-03 | Oracle International Corporation | Continuous query language (CQL) debugger in complex event processing (CEP) |
US9262479B2 (en) | 2012-09-28 | 2016-02-16 | Oracle International Corporation | Join operations for continuous queries over archived views |
US10042890B2 (en) | 2012-09-28 | 2018-08-07 | Oracle International Corporation | Parameterized continuous query templates |
US11288277B2 (en) | 2012-09-28 | 2022-03-29 | Oracle International Corporation | Operator sharing for continuous queries over archived relations |
US9286352B2 (en) | 2012-09-28 | 2016-03-15 | Oracle International Corporation | Hybrid execution of continuous and scheduled queries |
US11093505B2 (en) | 2012-09-28 | 2021-08-17 | Oracle International Corporation | Real-time business event analysis and monitoring |
US10102250B2 (en) | 2012-09-28 | 2018-10-16 | Oracle International Corporation | Managing continuous queries with archived relations |
US9361308B2 (en) | 2012-09-28 | 2016-06-07 | Oracle International Corporation | State initialization algorithm for continuous queries over archived relations |
US9292574B2 (en) | 2012-09-28 | 2016-03-22 | Oracle International Corporation | Tactical query to continuous query conversion |
US10025825B2 (en) | 2012-09-28 | 2018-07-17 | Oracle International Corporation | Configurable data windows for archived relations |
US9256646B2 (en) | 2012-09-28 | 2016-02-09 | Oracle International Corporation | Configurable data windows for archived relations |
US9990401B2 (en) | 2012-09-28 | 2018-06-05 | Oracle International Corporation | Processing events for continuous queries on archived relations |
US9563663B2 (en) | 2012-09-28 | 2017-02-07 | Oracle International Corporation | Fast path evaluation of Boolean predicates |
US9703836B2 (en) | 2012-09-28 | 2017-07-11 | Oracle International Corporation | Tactical query to continuous query conversion |
US9990402B2 (en) | 2012-09-28 | 2018-06-05 | Oracle International Corporation | Managing continuous queries in the presence of subqueries |
US9715529B2 (en) | 2012-09-28 | 2017-07-25 | Oracle International Corporation | Hybrid execution of continuous and scheduled queries |
US9953059B2 (en) | 2012-09-28 | 2018-04-24 | Oracle International Corporation | Generation of archiver queries for continuous queries over archived relations |
US9946756B2 (en) | 2012-09-28 | 2018-04-17 | Oracle International Corporation | Mechanism to chain continuous queries |
US9805095B2 (en) | 2012-09-28 | 2017-10-31 | Oracle International Corporation | State initialization for continuous queries over archived views |
US9852186B2 (en) | 2012-09-28 | 2017-12-26 | Oracle International Corporation | Managing risk with continuous queries |
US10956422B2 (en) | 2012-12-05 | 2021-03-23 | Oracle International Corporation | Integrating event processing with map-reduce |
US10298444B2 (en) | 2013-01-15 | 2019-05-21 | Oracle International Corporation | Variable duration windows on continuous data streams |
US9098587B2 (en) | 2013-01-15 | 2015-08-04 | Oracle International Corporation | Variable duration non-event pattern matching |
US9047249B2 (en) | 2013-02-19 | 2015-06-02 | Oracle International Corporation | Handling faults in a continuous event processing (CEP) system |
US9262258B2 (en) | 2013-02-19 | 2016-02-16 | Oracle International Corporation | Handling faults in a continuous event processing (CEP) system |
US10083210B2 (en) | 2013-02-19 | 2018-09-25 | Oracle International Corporation | Executing continuous event processing (CEP) queries in parallel |
US9390135B2 (en) | 2013-02-19 | 2016-07-12 | Oracle International Corporation | Executing continuous event processing (CEP) queries in parallel |
US9418113B2 (en) | 2013-05-30 | 2016-08-16 | Oracle International Corporation | Value based windows on relations in continuous data streams |
US9934279B2 (en) | 2013-12-05 | 2018-04-03 | Oracle International Corporation | Pattern matching across multiple input data streams |
US9244978B2 (en) | 2014-06-11 | 2016-01-26 | Oracle International Corporation | Custom partitioning of a data stream |
US9712645B2 (en) | 2014-06-26 | 2017-07-18 | Oracle International Corporation | Embedded event processing |
US9292267B2 (en) * | 2014-06-27 | 2016-03-22 | International Business Machines Corporation | Compiling nested relational algebras with multiple intermediate representations |
US10120907B2 (en) | 2014-09-24 | 2018-11-06 | Oracle International Corporation | Scaling event processing using distributed flows and map-reduce operations |
US9886486B2 (en) | 2014-09-24 | 2018-02-06 | Oracle International Corporation | Enriching events with dynamically typed big data for event processing |
US20160132496A1 (en) * | 2014-11-06 | 2016-05-12 | Unmesh Gandhi | Data filtering |
US10579589B2 (en) * | 2014-11-06 | 2020-03-03 | Sap Se | Data filtering |
US9972103B2 (en) | 2015-07-24 | 2018-05-15 | Oracle International Corporation | Visually exploring and analyzing event streams |
US20170308555A1 (en) * | 2016-04-22 | 2017-10-26 | International Business Machines Corporation | Database algebra and compiler with environments |
US10983966B2 (en) * | 2016-04-22 | 2021-04-20 | International Business Machines Corporation | Database algebra and compiler with environments |
Also Published As
Publication number | Publication date |
---|---|
WO2008037572A1 (en) | 2008-04-03 |
US20100036826A1 (en) | 2010-02-11 |
US8543589B2 (en) | 2013-09-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8543589B2 (en) | Method and apparatus for integrating relational and hierarchical data | |
US7496599B2 (en) | System and method for viewing relational data using a hierarchical schema | |
US5442780A (en) | Natural language database retrieval system using virtual tables to convert parsed input phrases into retrieval keys | |
CN101427249B (en) | There is the extensible query language of the support to rich data types | |
US6934712B2 (en) | Tagging XML query results over relational DBMSs | |
US7194462B2 (en) | Systems and methods for implementing an XML query language | |
US7392239B2 (en) | System and method for querying XML streams | |
CA2484009C (en) | Managing expressions in a database system | |
EP1686495B1 (en) | Mapping web services to ontologies | |
US8484233B2 (en) | Facet, logic and textual-based query composer | |
Elliott et al. | A complete translation from SPARQL into efficient SQL | |
US20020184225A1 (en) | Automatic generation of join graphs for relational database queries | |
KR20050000348A (en) | Query intermediate language method and system | |
JPS59163661A (en) | Computer for translating collation by graphic language into collation of linear language | |
US20090125480A1 (en) | Combining Streaming And Navigation For Evaluating XML Queries | |
CN111198898B (en) | Big data query method and big data query device | |
Higgins et al. | Managing heterogeneous ecological data using Morpho | |
US20040049495A1 (en) | System and method for automatically generating general queries | |
Lee et al. | Conflict classification and resolution in heterogeneous information integration based on XML schema | |
Rishe et al. | Knowledge Management for Database Interoperability | |
Choi et al. | Efficient filtering of branch queries for high-performance XML data services | |
van Zwol et al. | Dxl: Data exchange language | |
Döller et al. | Semantic MPEG Query Format Validation and Processing | |
Buratti et al. | A data model and an algebra for querying XML documents | |
KR100456027B1 (en) | Apparatus and method for transforming ebXML filter query by using G-FQL |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KHORLIN, ANDREY;STROM, ROBERT EVANS;TIAN, LU;REEL/FRAME:018500/0224;SIGNING DATES FROM 20061027 TO 20061102 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |