Patent Grant
7877421
The present invention relates to data schema, and in particular to deriving transformations for transforming data from one schema to another.
Ontology is a philosophy of what exists. In computer science ontology is used to model entities of the real world and the relations between them, so as to create common dictionaries for their discussion. Basic concepts of ontology include (i) classes of instances/things, and (ii) relations between the classes, as described hereinbelow. Ontology provides a vocabulary for talking about things that exist.
There are many kinds of “things” in the world. There are physical things like a car, person, boat, screw and transistor. There are other kinds of things which are not physically connected items or not even physical at all, but may nevertheless be defined. A company, for example, is a largely imaginative thing the only physical manifestation of which is its appearance in a list at a registrar of companies. A company may own and employ. It has a defined beginning and end to its life.
Other things can be more abstract such as the Homo Sapiens species, which is a concept that does not have a beginning and end as such even if its members do.
Ontological models are used to talk about “things.” An important vocabulary tool is “relations” between things. An ontology model itself does not include the “things,” but introduces class and property symbols which can then be used as a vocabulary for talking about and classifying things.
Properties are specific associations of things with other things. Properties include:
Some properties also relate things to fundamental concepts such as natural numbers or strings of characters—for example, the value of a weight in kilograms, or the name of a person.
Properties play a dual role in ontology. On the one hand, individual things are referenced by way of properties, for example, a person by his name, or a book by its title and author. On the other hand, knowledge being shared is often a property of things, too. A thing can be specified by way of some of its properties, in order to query for the values of other of its properties.
Not all properties are relevant to all things. It is convenient to discuss the source of a property as a “class” of things, also referred to as a frame or, for end-user purposes, as a category. Often sources of several properties coincide, for example, the class Book is the source for both Author and ISBN Number properties.
There is flexibility in the granularity to which classes are defined. Cars is a class. Fiat Cars can also be a class, with a restricted value of a manufacturer property. It may be unnecessary to address this class, however, since Fiat cars may not have special properties of interest that are not common to other cars. In principle, one can define classes as granular as an individual car unit, although an objective of ontology is to define classes that have important properties.
Abstract concepts such as measures, as well as media such as a body of water which cannot maintain its identity after coming into contact with other bodies of water, may be modeled as classes with a quantity property mapping them to real numbers.
In a typical mathematical model, a basic ontology comprises:
In the ensuing discussion, the terms “class” and “class symbol” are used interchangeably, for purposes of convenience and clarity. Similarly, the terms “property” and “property symbol” are also used interchangeably.
It is apparent to those skilled in the art that if an ontology model is extended to include sets in a class, then a classical mathematical relation on C×D can be considered as a property from C to sets in D.
If I(C1, C2) then C1 is referred to as a subclass of C2, and C2 is referred to as a superclass of C1. Also, C1 is said to inherit from C2.
A distinguished universal class “Being” is typically postulated to be a superclass of all classes in C.
Variations on an ontology model may include:
The notion of a class symbol is conceptual, in that it describes a generic genus for an entire species such as Books, Cars, Companies and People. Specific instances of the species within the genus are referred to as “instances” of the class. Thus “Gone with the Wind” is an instance of a class for books, and “IBM” is an instance of a class for companies. Similarly, the notions of a property symbol is conceptual, in that it serves as a template for actual properties that operate on instances of classes.
Class symbols and property symbols are similar to object-oriented classes in computer programming, such as C++ classes. Classes, along with their members and field variables, defined within a header file, serve as templates for specific class instances used by a programmer. A compiler uses header files to allocate memory for, and enables a programmer to use instances of classes. Thus a header file can declare a rectangle class with members left, right, top and bottom. The declarations in the header file do not instantiate actual “rectangle objects,” but serve as templates for rectangles instantiated in a program. Similarly, classes of an ontology serve as templates for instances thereof.
There is, however, a distinction between C++ classes and ontology classes. In programming, classes are templates and they are instantiated to create programming objects. In ontology, classes document common structure but the instances exist in the real world and are not created through the class.
Ontology provides a vocabulary for speaking about instances, even before the instances themselves are identified. A class Book is used to say that an instance “is a Book.” A property Author allows one to create clauses “author of” about an instance. A property Siblings allows one to create statements “are siblings” about instances. Inheritance is used to say, for example, that “every Book is a PublishedWork”. Thus all vocabulary appropriate to PublishedWork can be used for Book.
Once an ontology model is available to provide a vocabulary for talking about instances, the instances themselves can be fit into the vocabulary. For each class symbol, C, all instances which satisfy “is a C” are taken to be the set of instances of C, and this set is denoted B(C). Sets of instances are consistent with inheritance, so that B(C1)⊂B(C2) whenever C1 is a subclass of C2. Property symbols with source C1 and target C2 correspond to properties with source B(C1) and target B(C2). It is noted that if class C1 inherits from class C, then every instance of C1 is also an instance of C, and it is therefore known already at the ontology stage that the vocabulary of C is applicable to C1.
Ontology enables creation of a model of multiple classes and a graph of properties therebetween. When a class is defined, its properties are described using handles to related classes. These can in turn be used to look up properties of the related classes, and thus properties of properties can be accessed to any depth.
Provision is made for both classes and complex classes. Generally, complex classes are built up from simpler classes using tags for symbols such as intersection, Cartesian product, set, list and bag. The “intersection” tag is followed by a list of classes or complex classes. The “Cartesian product” tag is also followed by a list of classes or complex classes. The set symbol is used for describing a class comprising subsets of a class, and is followed by a single class or complex class. The list symbol is used for describing a class comprising ordered subsets of a class; namely, finite sequences, and is followed by a single class or complex class. The bag symbol is used for describing unordered finite sequences of a class, namely, subsets that can contain repeated elements, and is followed by a single class or complex class. Thus set[C] describes the class of sets of instances of a class C, list[C] describes the class of lists of instances of class C, and bag[C] describes the class of bags of instances of class C.
In terms of formal mathematics, for a set S, set[S] is P(S), the power set of S; bag[S] is NS, where N is the set of non-negative integers; and list[S] is
There are natural mappings
Specifically, for a sequence (s1, s2, . . . , sn)εlist[S], φ(s1, s2, . . . , sn) is the element fεbag[S] that is the “frequency histogram” defined by f(s)=#{1≦i≦n: si=s}; and for fεbag[S], ψ(f)εset[S] is the subset of S given by the support of f, namely, supp(f)={sεS: f(s)>0}. It is noted that the composite mapping φψ maps a the sequence (s1, s2, . . . , sn) into the set of its elements {s1, s2, . . . , sn}. For finite sets S, set[S] is also finite, and bag[S] and list[S] are countably infinite.
A general reference on ontology systems is Sowa, John F., “Knowledge Representation,” Brooks/Cole, Pacific Grove, Calif., 2000.
Relational database schema (RDBS) are used to define templates for organizing data into tables and fields. SQL queries are used to populate tables from existing tables, generally by using table join operations. Extensible markup language (XML) schema are used to described documents for organizing data into a hierarchy of elements and attributes. XSLT script is used to generate XML documents from existing documents, generally by importing data between tags in the existing documents. XSLT was originally developed in order to generate HTML pages from XML documents.
A general reference on relation databases and SQL is the document “Oracle 9i: SQL Reference,” available on-line at http://www.oracle.com. XML, XML schema, XPath and XSLT are standards of the World-Wide Web Consortium, and are available on-line at http://www.w3.org.
Often multiple schema exist for the same source of data, and as such the data cannot readily be imported or exported from one application to another. For example, two airline companies may each run applications that process relational databases, but if the relational databases used by the two companies conform to two different schema, then neither of the companies can readily use the databases of the other company. In order for the companies to share data, it is necessary to export the databases from one schema to another.
There is thus a need for a tool that can transform data conforming with a first schema into data that conforms with a second schema.
The present invention provides a method and system for deriving transformations for transforming data from one schema to another. The present invention describes a general method and system for transforming data conforming with an input, or source data schema into an output, or target data schema. In a preferred embodiment, the present invention can be used to provide (i) an SQL query, which when applied to relational databases from a source RDBS, populates relational databases in a target RDBS; and (ii) XSLT script which, when applied to documents conforming with a source XML schema generates documents conforming with a target XML schema.
The present invention preferably uses an ontology model to determine a transformation that accomplishes a desired source to target transformation. Specifically, the present invention employs a common ontology model into which both the source data schema and target data schema can be mapped. By mapping the source and target data schema into a common ontology model, the present invention derives interrelationships among their components, and uses the interrelationships to determine a suitable transformation for transforming data conforming with the source data schema into data conforming with the target data schema.
Given a source RDBS and a target RDBS, in a preferred embodiment of the present invention an appropriate transformation of source to target databases is generated by:
Although the source and target RDBS are mapped into a common ontology model, the derived transformations of the present invention go directly from source RDBS to target RDBS without having to transform data via an ontological format. In distinction, prior art Universal Data Model approaches transform via a neutral model or common business objects.
The present invention applies to N relational database schema, where N≧2. Using the present invention, by mapping the RDBS into a common ontology model, data can be moved from any one of the RDBS to any other one. In distinction to prior art approaches that require on the order of N2 mappings, the present invention requires at most N mappings.
For enterprise applications, SQL queries generated by the present invention are preferably deployed within an Enterprise Application Integration infrastructure. Those skilled in the art will appreciate that transformation languages other than SQL that are used by enterprise application infrastructures can be generated using the present invention. For example, IBM's ESQL language can similarly be derived for deployment on their WebSphere MQ family of products.
Given a source XML schema and a target XML schema, in a preferred embodiment of the present invention an appropriate transformation of source to target XML documents is generated by:
There is thus provided in accordance with a preferred embodiment of the present invention a method for mapping data schemas into an ontology model, including providing an ontology model including classes and properties of classes, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a property of the corresponding class of the ontology model.
There is moreover provided in accordance with a preferred embodiment of the present invention a method for mapping data schemas into an ontology model, including providing an ontology model including classes and properties of classes, each property having associated therewith a target class, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is the corresponding class of the ontology model.
There is additionally provided in accordance with a preferred embodiment of the present invention a method for mapping data schemas into an ontology model, including providing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a property of a superclass of the corresponding class of the ontology model.
There is further provided in accordance with a preferred embodiment of the present invention a method for mapping data schemas into an ontology model, including providing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is a superclass of the corresponding class of the ontology model.
There is yet further provided in accordance with a preferred embodiment of the present invention a method for mapping data schemas into an ontology model, including providing an ontology model including classes and properties of classes, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a composition of properties, one of which is a property of the corresponding class of the ontology model.
There is additionally provided in accordance with a preferred embodiment of the present invention a system for mapping data schemas into an ontology model, including a memory for storing an ontology model including classes and properties of classes, and a data schema, a schema parser for identifying a primary data construct within the data schema, and identifying a secondary data construct within the primary data construct, and a schema mapper for mapping the primary data construct to a corresponding class of the ontology model, and for mapping the secondary data construct to a property of the corresponding class of the ontology model.
There is further provided in accordance with a preferred embodiment of the present invention a system for mapping data schemas into an ontology model, including a memory for storing an ontology model including classes and properties of classes, each property having associated therewith a target class, and a data schema, a schema parser for identifying a primary data construct within the data schema, and identifying a secondary data construct within the primary data construct, and a schema mapper for mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is the corresponding class of the ontology model.
There is yet further provided in accordance with a preferred embodiment of the present invention a system for mapping data schemas into an ontology model, including a memory for storing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, and a data schema, a schema parser for identifying a primary data construct within the data schema, and identifying a secondary data construct within the primary data construct, and a schema mapper for mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a property of a superclass of the corresponding class of the ontology model.
There is moreover provided in accordance with a preferred embodiment of the present invention a system for mapping data schemas into an ontology model, including a memory for storing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, and a data schema, a schema parser for identifying a primary data construct within the data schema, and identifying a secondary data construct within the primary data construct, and a schema mapper for mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is a superclass of the corresponding class of the ontology model.
There is additionally provided in accordance with a preferred embodiment of the present invention a system for mapping data schemas into an ontology model, including a memory for storing an ontology model including classes and properties of classes, and a data schema, a schema parser for identifying a primary data construct within the data schema, and identifying a secondary data construct within the primary data construct, and a schema mapper for mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a composition of properties, one of which is a property of the corresponding class of the ontology model.
There is yet further provided in accordance with a preferred embodiment of the present invention a method for mapping schemas for metadata into a metamodel for metadata, including providing a metamodel for metadata including atomic constructs and composite constructs, providing a schema for metadata, identifying a primary and a secondary metadata construct within the schema for metadata, and mapping the primary and the secondary metadata constructs to corresponding composite and atomic constructs of the metamodel, respectively.
There is moreover provided in accordance with a preferred embodiment of the present invention a system for mapping schemas for metadata into a metamodel for metadata, including a memory for storing a metamodel for metadata including atomic constructs and composite constructs, and a schema for metadata, a metaschema parser for identifying a primary metadata construct and a secondary metadata construct within the schema for metadata, and a metaschema mapper for mapping the primary metadata construct and the secondary data construct to a composite construct and an atomic construct of the metamodel, respectively.
There is additionally provided in accordance with a preferred embodiment of the present invention a method for mapping a given data schema into a generic data schema, including providing a business data schema that represents at least one type of business data instance in terms of alphanumeric values and links to business data instances, providing a plurality of generic instance mappings, defining a mapping from the business data schema into a generic data schema, and representing the mapping from the business data schema into the generic data schema in terms of the generic instance mappings.
There is further provided in accordance with a preferred embodiment of the present invention a system for mapping a given data schema into a generic data schema, including a memory for storing a business data schema that represents at least one type of business data instance in terms of alphanumeric values and links to business data instances, and including a plurality of generic instance mappings, a mapping generator for defining a mapping from the business data schema into a generic data schema, and a mapping analyzer for representing the mapping from the business data schema into the generic data schema in terms of the generic instance mappings.
There is yet further provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a property of the corresponding class of the ontology model.
There is moreover provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, each property having associated therewith a target class, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is the corresponding class of the ontology model.
There is additionally provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a property of a superclass of the corresponding class of the ontology model.
There is further provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, and including inheritance relationships for superclasses, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to an inverse of a property whose target class is a superclass of the corresponding class of the ontology model.
There is yet further provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a composition of properties, one of which is a property of the corresponding class of the ontology model.
There is moreover provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing an ontology model including classes and properties of classes, providing a data schema, identifying a primary data construct within the data schema, identifying a secondary data construct within the primary data construct, mapping the primary data construct to a corresponding class of the ontology model, and mapping the secondary data construct to a composition of properties, one of which is a property of the corresponding class of the ontology model.
There is additionally provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing a business data schema for representing at least one type of business data instance in terms of alphanumeric values and links to business data instances, providing a plurality of generic instance mappings, defining a mapping from the business data schema into a generic data schema, and representing the mapping from the business data schema into the generic data schema in terms of the generic instance mappings.
There is further provided in accordance with a preferred embodiment of the present invention a computer-readable storage medium storing program code for causing a computer to perform the steps of providing a metamodel for metadata including atomic constructs and composite constructs, providing a schema for metadata, identifying a primary and a secondary metadata construct within the schema for metadata, and mapping the primary and the secondary metadata constructs to corresponding composite and atomic constructs of the metamodel, respectively.
The present invention will be more fully understood and appreciated from the following detailed description, taken in conjunction with the drawings in which:
The present invention concerns deriving transformations for transforming data conforming with one data schema to data conforming to another data schema. Preferred embodiments of the invention are described herein with respect to table-based data schema, such as RDBS and document-based schema, such as XML schema.
Reference is now made to
At steps 130-160 a common ontology model is obtained, into which the source data schema and the target data schema can both be embedded, At step 130 a determination is made as to whether or not an initial ontology model is to be imported. If not, logic passes directly to step 160. Otherwise, at step 140 an initial ontology model is imported. If necessary, the initial ontology model may be converted from a standard format, such as one of the formats mentioned hereinabove in the Background, to an internal format.
At step 150 a determination is made as to whether or not the initial ontology model is suitable for embedding both the source and target data schema. If so, logic passes directly to step 170. Otherwise, at step 160 a common ontology model is built. If an initial ontology model was exported, then the common ontology is preferably build by editing the initial ontology model; specifically, by adding classes and properties thereto. Otherwise, the common ontology model is built from scratch. It may be appreciated that the common ontology model may be built automatically with or without user assistance.
At step 170 the source and target data schema are mapped into the common ontology model, and mappings therefor are generated. At step 180 a transformation is derived for transforming data conforming with the source data schema into data conforming with the target data schema, based on the mappings derived at step 170. Finally, the flowchart terminates at step 190.
Reference is now made to
Also shown in
The source and target data schema, and the common ontology model are used by a mapping processor 230 to generate respective source and target mappings, for mapping the source data schema into the common model and for mapping the target data schema into the common ontology model. In a preferred embodiment of the present invention, mapping processor 230 includes a class identifier 240 for identifying ontology classes with corresponding to components of the source and target data schema, and a property identifier 250 for identifying ontology properties corresponding to other components of the source and target data schema, as described in detail hereinbelow.
Preferably, the source and target mappings generated by mapping processor, and the imported source and target data schema are used by a transformation generator 260 to derive a source-to-target transformation, for transforming data conforming to the source data schema into data conforming to the target data schema.
Reference is now made to
Reference is now made to
The initial ontology model and the imported data schema are used by an ontology builder 430 for generating a common ontology model, into which the imported data schema can all be embedded. In a preferred embodiment of the present invention, ontology builder 430 generates the common ontology model by editing the initial ontology model; specifically, by using a class builder 440 to add classes thereto based on components of the imported data schema, and by using a property builder 450 to add properties thereto based on other components of the imported data schema.
Applications of the present invention include inter alia:
Relational database schema (RDBS), also referred to as table definitions or, in some instances, metadata, are used to define templates for organizing data into tables and table columns, also referred to as fields. Often multiple schema exist for the same source of data, and as such the data cannot readily be imported or exported from one application to another. The present invention describes a general method and system for transforming an input, or source relational database schema into an output, or target schema. In a preferred embodiment, the present invention can be used to provide an SQL query, which when applied to a relational database from the source schema, produces a relational database in the target schema.
As described in detail hereinbelow, the present invention preferably uses an ontology model to determine an SQL query that accomplishes a desired source to target transformation. Specifically, the present invention employs a common ontology model into which both the source RDBS and target RDBS can be mapped. By mapping the source and target RDBS into a common ontology model, the present invention derives interrelationships among their tables and fields, and uses the interrelationships to determine a suitable SQL query for transforming databases conforming with the source RDBS into databases conforming with the target RDBS.
The present invention can also be used to derive executable code that transforms source relational databases into the target relational databases. In a preferred embodiment, the present invention creates a Java program that executes the SQL query using the JDBC (Java Database Connectivity) library. In an alternative embodiment the Java program manipulates the databases directly, without use of an SQL query.
For enterprise applications, SQL queries generated by the present invention are preferably deployed within an Enterprise Application Integration infrastructure.
Although the source and target RDBS are mapped into a common ontology model, the derived transformations of the present invention go directly from source RDBS to target RDBS without having to transform data via an ontological format. In distinction, prior art Universal Data Model approaches transform via a neutral model.
The present invention applies to N relational database schema, where N≧2. Using the present invention, by mapping the RDBS into a common ontology model, data can be moved from any one of the RDBS to any other one.
In distinction to prior art approaches that require on the order of N2 mappings, the present invention requires at most N mappings.
A “mapping” from an RDBS into an ontology model is defined as:
In general, although a mapping from an RDBS into an ontology model may exist, the nomenclature used in the RDBS may differ entirely from that used in the ontology model. Part of the utility of the mapping is being able to translate between RDBS language and ontology language. It may be appreciated by those skilled in the art, that in addition to translating between RDBS table/column language and ontology class/property language, a mapping is also useful in translating between queries from an ontology query language and queries from an RDBS language such as SQL (standard query language).
Reference is now made to
Reference is now made to
Also shown in
The labeling also indicates a mapping from table T2 into class K2, and from columns D1, D2 and D4 into respective properties Q1, Q2 and Q4. Column D3 corresponds to a composite property P1oS, where o denotes function composition. In other words, column D3 corresponds to property P1 of S(K2).
The targets of properties P1, P2, P3, P4, Q1, Q2 and Q4 are not shown in
Classes K1 and K2, and property S are indicated with dotted lines in ontology model 650. These parts of the ontology are transparent to the RDBS underlying tables T1 and T2. They represent additional structure present in the ontology model which is not directly present in the RDBS.
Given a source RDBS and a target RDBS, in a preferred embodiment of the present invention an appropriate transformation of source to target RDBS is generated by:
Reference is now made to
As described in detail hereinbelow, the present invention preferably uses an ontology model to determine an XSLT transformation that accomplishes a desired source to target transformation. Specifically, the present invention employs a common ontology model into which both the source XML schema and target XML schema can be mapped. By mapping the source and target XML schema into a common ontology model, the present invention derives interrelationships among their elements and attributes, and uses the interrelationships to determine suitable XSLT script for transforming and generating documents conforming with the target XML schema from documents conforming with the source XML schema.
The present invention can also be used to derive executable code that transforms source XML documents into the target XML documents. In a preferred embodiment, the present invention packages the derived XSLT script with a Java XSLT engine to provide an executable piece of Java code that can execute the transformation.
Preferably, this is used to deploy XSLTs within an EAI product such as Tibco. Specifically, in a preferred embodiment of the present invention, a function (similar to a plug-in) is installed in a Tibco MessageBroker, which uses the Xalan XSLT engine to run XSLT scripts that are presented in text form. As an optimization, the XSLT script files are preferably compiled to Java classfiles.
Reference is now made to
Applicant has developed a software application, named COHERENCE™, which implements a preferred embodiment of the present invention to transform data from one schema to another. Coherence enables a user
Reference is now made to
Left pane 910 includes icons for two modes of viewing an ontology: icon 935 for viewing in inheritance tree display mode, and icon 940 for viewing in package display mode.
Inheritance tree display mode shows the classes of the ontology in a hierarchical fashion corresponding to superclass and subclass relationships. As illustrated in
Tab 960 for Enumerated Values applies to classes with named elements; i.e., classes that include a list of all possible instances. For example, a class Boolean has enumerated values “True” and “False,” and a class Gender may have enumerated values “Male” and “Female.”
As shown in
In
The table named Cities is shown selected in
When tab 925 for Mapping is selected, the right pane includes three tabs for displaying information about the RDBS: tab 975 for Map Info, tab 980 for Table Info and tab 985 for Foreign Keys.
The RDBS named WeatherCelsius is displayed in
As such, the target RDBS is
and the source RDBS is
In
accomplishes the desired transformation.
Reference is now made to
Reference is now made to
For purposes of clarity and exposition, the workings of the present invention are described first through a series of twenty-three examples, followed by a general description of implementation. Two series of examples are presented. The first series, comprising the first eleven examples, relates to RDBS transformations. For each of these examples, a source RDBS and target RDBS are presented as input, along with mappings of these schema into a common ontology model. The output is an appropriate SQL query that transforms database tables that conform to the source RDBS, into database tables that conform to the target RDBS. Each example steps through derivation of source and target symbols, expression of target symbols in terms of source symbols and derivation of an appropriate SQL query based on the expressions.
The second series of examples, comprising the last twelve examples, relates to XSLT transformation. For each of these examples, a source XML schema and target XML schema are presented as input, along with mappings of these schema into a common ontology model. The output is an appropriate XSLT script that transforms XML documents that conform to the source schema into XML documents that conform to the target schema.
In a first example, a target table is of the following form:
Four source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The symbol o is used to indicate composition of properties. The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The symbols in Table XI relate fields of a source table to a key field. Thus in table S1 the first field, S1.Name is a key field. The second field, S1.School_Attending is related to the first field by the composition 10o9o6−1, and the third field, S1.Mother_NI_Number is related to the first field by the composition 4o5o6−1. In general, if a table contains more than one key field, then expressions relative to each of the key fields are listed.
The inverse notation, such as 6−1 is used to indicate the inverse of property 6. This is well defined since property 6 is a unique, or one-to-one, property in the ontology model. The indices of the target properties, keyed on Child_Name are:
Based on the paths given in Table XII, the desired SQL query is:
The rules provided with the examples relate to the stage of converting expressions of target symbols in terms of source symbols, into SQL queries. In general,
When applied to the following sample source data, Tables XIII, XIV, XV and XVI, the above SQL query produces the target data in Table XVII.
In a second example, a target table is of the following form:
Four source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on Name are:
Based on the paths given in Table XXVII, the desired SQL query is:
It is noted that Table S4 not required in the SQL. When applied to the following sample source data, Tables XXVIII, XXIX and XXX, the above SQL query produces the target data in Table XXXI.
In a third example, a target table is of the following form:
Two source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on FlightID are:
Since the path (2o1−1) appears in two rows of Table XXXIX, it is necessary to create two tables for S1 in the SQL query. Based on the paths given in Table XXXVII, the desired SQL query is:
In general,
When applied to the following sample source data, Tables XL and XLI, the above SQL query produces the target data in Table XLII.
In a fourth example, a target table is of the following form:
One source table is given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on ID are:
Based on the paths given in Table XLIX, the desired SQL query is:
In a fifth example, the target property of Father_Name in the fourth example is changed to Grandfather_Name, and the target table is thus of the following form:
One source table is given as above in Table XLIV.
The underlying ontology is again illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is given in Table XLVII above.
The indices of the source properties are given in Table XLVIII above.
The indices of the target properties, keyed on ID are:
Based on the paths given in Table LII, the desired SQL query is:
In a sixth example, a target table is of the following form:
Two source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on ID are:
Based on the paths given in Table LX, the desired SQL query is:
In a seventh example, a target table is of the following form:
Five source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on ID are:
Based on the paths given in Table LXXI, the desired SQL query is:
In general,
When applied to the following sample source data, Tables LXXII, LXXIII, LXXIV, LXXV and LXXVI, the above SQL query produces the target data in Table LXXVII.
In an eighth example, a target table is of the following form:
Two source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on Emp_Name are:
Since each of the source tables S1 and S2 suffice to generate the target table T, the desired SQL is a union of a query involving S1 alone and a query involving S2 alone. Specifically, based on the paths given in Table LXXXV, the desired SQL query is:
In general,
When applied to the following sample source data, Tables LXXXVI and LXXXVII, the above SQL query produces the target data in Table LXXXVIII.
In a ninth example, a target table is of the following form:
Two source tables are given as follows:
The underlying ontology is illustrated in
Temperature_in_Centrigade(City)= 5/9*(Temperature_in_Fahrenheit(City)−32)
The unique properties of the ontology are:
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on City are:
Since each of the source tables S1 and S2 suffice to generate the target table T, the desired SQL is a union of a query involving S1 alone and a query involving S2 alone. Specifically, based on the paths given in Table XCVI, the desired SQL query is:
In general,
When applied to the following sample source data, Tables XCVII and XCVIII, the above SQL query produces the target data in Table XCIX.
In a tenth example, a target table is of the following form:
Two source tables are given as follows:
The underlying ontology is illustrated in
price(Product)=cost_of_production(Product)*margin(Product).
The unique properties of the ontology are:
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on Product are:
Based on the paths given in Table CVII, the desired SQL query is:
When applied to the following sample source data, Tables CVIII and CVIX, the above SQL query produces the target data in Table CX.
In an eleventh example, a target table is of the following form:
One source table is given as follows:
The underlying ontology is illustrated in
full_name(Person)=first_name(Person)∥last_name(Person),
where ∥ denotes string concatenation.
The unique properties of the ontology are:
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on ID# are:
Based on the paths given in Table CXVII, the desired SQL query is:
When applied to the following sample source data, Table CXVIII, the above SQL query produces the target data in Table CXIX.
A source XML schema for books is given by:
A target XML schema for documents is given by:
A common ontology model for the source and target XML schema is illustrated in
A mapping of the target XML schema into the ontology model is given by:
Tables CXX and CXXI use XPath notation to designate XSL elements and attributes.
Based on Tables CXX and CXXI, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A source XML schema for books is given by:
A target XML schema for documents is given by:
A common ontology model for the source and target XML schema is illustrated in
Based on Tables CXX and CXXII, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A source XML schema for books is given by:
A first target XML schema for documents is given by:
A common ontology model for the source and first target XML schema is illustrated in
A mapping of the first target XML schema into the ontology model is given by:
Based on Tables CXXIII and CXXIV, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A second target XML schema for documents is given by:
maxOccurs=“unbounded”/>
A mapping of the second target XML schema into the ontology model is given by:
Based on Tables CXXIII and CXXV, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A third target XML schema for documents is given by:
A mapping of the third target XML schema into the ontology model is given by:
Based on Tables CXXIII and CXXVI, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A source XML schema for people is given by:
A target XML schema for people is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for people is given by:
A target XML schema for people is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for libraries is given by:
A target XML schema for storage is given by:
A common ontology model for the source and target XML schema is illustrated in
Based on Tables CXX and CXXI, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema should accomplish the following tasks:
A source XML schema for plain text is given by:
A target XML schema for case sensitive text is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for list of numbers is given by:
A target XML schema for a list of numbers is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for a person is given by:
A target XML schema for a person is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for temperature in Fahrenheit is given by:
A target XML schema for temperature in Centigrade is given by:
An XSLT transformation that maps the source schema into the target schema is given by:
A source XML schema for a town with books is given by:
A target XML schema for a list of books is given by:
A common ontology model for the source and target XML schema is illustrated in
A mapping of the target XML schema into the ontology model is given by:
Based on Tables CXXVII and CXXVIII, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the target schema is given by:
A source XML schema for a town is given by:
A first target XML schema for police stations is given by:
A common ontology model for the source and target XML schema is illustrated in
A mapping of the first target XML schema into the ontology model is given by:
Based on Tables CXXIX and CXXX, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the first target schema is given by:
A second target XML schema for temperature in Centigrade is given by:
Based on Tables CXXIX and CXXX, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the second target schema is given by:
A third target XML schema for temperature in Centigrade is given by:
Based on Tables CXXIX and CXXX, an XSLT transformation that maps XML documents that conform to the source schema to corresponding documents that conform to the first target schema is given by:
In a twenty-fourth example, a target table is of the following form:
A single source table is given as follows:
The source table lists employees and their cars, and the target table to be inferred lists cars and their owners.
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schema into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on OwnerID are:
Based on the paths given in Table CXXXVII, the desired SQL query is:
In a twenty-fifth example, a target table is of the following form:
Three source tables are given as follows:
The underlying ontology is illustrated in
The mapping of the target schema into the ontology is as follows:
The mapping of the source schemas into the ontology is as follows:
The indices of the source properties are:
The indices of the target properties, keyed on Book_Written_by_niece_of_owner are:
Based on the paths given in Table CXLVI, the desired SQL query is:
As mentioned hereinabove, and described through the above series of examples, in accordance with a preferred embodiment of the present invention a desired transformation from a source RDBS to a target RDBS is generated by:
Preferably the common ontology model is built by adding classes and properties to an initial ontology model, as required to encompass tables and fields from the source and target RDBS. The addition of classes and properties can be performed manually by a user, automatically by a computer, or partially automatically by a user and a computer in conjunction.
Preferably, while the common ontology model is being built, mappings from the source and target RDBS into the ontology model are also built by identifying tables and fields of the source and target RDBS with corresponding classes and properties of the ontology model. Fields are preferably identified as being either simple properties or compositions of properties.
In a preferred embodiment of the present invention, automatic user guidance is provided when building the common ontology model, in order to accommodate the source and target RDBS mappings. Specifically, while mapping source and target RDBS into the common ontology model, the present invention preferably automatically presents a user with the ability to create classes that corresponds to tables, if such classes are not already defined within the ontology. Similarly, the present invention preferably automatically present a user with the ability to create properties that correspond to fields, if such properties are not already defined within the ontology.
This automatic guidance feature of the present invention enables users to build a common ontology on the fly, while mapping the source and target RDBS.
In a preferred embodiment of the present invention, automatic guidance is used to provide a user with a choice of properties to which a given table column may be mapped. Preferably, the choice of properties only includes properties with target types that are compatible with a data type of the given table column. For example, if the given table column has data type VARCHAR2, then the choice of properties only includes properties with target type string. Similarly, if the given table column is a foreign key to a foreign table, then the choice of properties only includes properties whose target is the class corresponding to the foreign table.
In a preferred embodiment of the present invention, automatic guidance is provided in determining inheritance among classes of the common ontology. Conditions are identified under which the present invention infers that two tables should be mapped to classes that inherit one from another. Such a condition arises when a table, T1, contains a primary key that is a foreign key to a table, T2. In such a situation, the present invention preferably infers that the class corresponding to T1 inherits from the class corresponding to T2.
For example, T1 may be a table for employees with primary key Social_Security_No, which is a foreign key for a table T2 for citizens. The fact that Social_Security_No serves both as a primary key for T1 and as a foreign key for T2 implies that the class Employees inherits from the class Citizens.
Preferably, when the present invention infers an inheritance relation, the user is given an opportunity to confirm or decline. Alternatively, the user may not be given such an opportunity.
Preferably, representing fields of the source and target RDBS in terms of properties of the ontology model is performed by identifying a key field among the fields of a table and expressing the other fields in terms of the identified key field using an inverse property symbol for the key field. For example, if a key field corresponds to a property denoted by 1, and a second field corresponds to a property denoted by 2, then the relation of the second field to the first field is denoted by 2o1−1. If a table has more than one key field, then preferably symbols are listed for each of the key fields, indicating how the other fields relate thereto. For example, if the second field above also is a key field, then the relation of the first field to the second field is denoted by 1o2−1, and both of the symbols 2o1−1 and 1o2−1 are listed.
Preferably, deriving expressions for target symbols in terms of source symbols is implemented by a search over the source symbols for paths that result in the target symbols. For example, if a target symbol is given by 3o1−1, then chains of composites are formed starting with source symbols of the form ao1−1, with each successive symbol added to the composite chain inverting the leftmost property in the chain. Thus, a symbol ending with a−1 is added to the left of the symbol ao1−1, and this continues until property 3 appears at the left end of the chain.
Preferably, converting symbol expressions into SQL queries is accomplished by use of Rules 1-7 described hereinabove with reference to the examples.
Preferably, when mapping a table to a class, a flag is set that indicates whether it is believed that the table contains all instances of the class.
1. Begin with the target schema. Preferably, the first step is to identify a candidate root element. Assume in what follows that one such element has been identified—if there are more than one such candidate, then preferably a user decides which is to be the root of the XSLT transformation. Assume that a <root> element has thus been identified. Create the following XSLT script, to establish that any document produced by the transformation will at minimum conform to the requirement that its opening and closing tags are identified by root:
2. Preferably, the next step is to identify the elements in the target schema that have been mapped to ontological classes. The easiest case, and probably the one encountered most often in practice, is one in which the root itself is mapped to a class, be it a simple class, a container class or a cross-product. If not, then preferably the code-generator goes down a few levels until it comes across elements mapped to classes. The elements that are not mapped to classes should then preferably be placed in the XSLT between the <root> tags mentioned above, in the correct order, up to the places where mappings to classes begin.
3. Henceforth, for purposes of clarity and exposition, the XSLT script generation algorithm is described in terms of an element <fu> that is expected to appear in the target XML document and is mapped to an ontological class, whether that means the root element or a parallel set of elements inside a tree emanating from the root. The treatment is the same in any event from that point onwards.
4. Preferably the XSLT generation algorithm divides into different cases depending on a number of conditions, as detailed hereinbelow in Table CXLVII:
For cases C and D, the XML schema code preferably looks like:
For cases E and F, the XML schema code preferably looks like:
For cases G and H, the XML schema code preferably looks like:
For the rules as to what should appear in between the <for-each> tags, see step 5 hereinbelow.
5. Next assume that the classes have been taken care of as detailed hereinabove in step 4. Preferably, from this point onwards the algorithm proceeds by working with properties rather than classes. Again, the algorithm is divided up into cases. Assume that the <fu> </fu> tags have been treated, and that the main issue now is dealing with the elements <bar> that are properties of <fu>.
Suppose that the properties of <fu> are listed in a sequence complex-type in the target schema. Assume, for the sake of definitiveness, that a complexType fu is mapped to an ontological class Foo, with elements bari mapped to respective property, Foo.bari. Assume further that the source XML schema has an Xpath pattern fu1 that maps to the ontological class Foo, with further children patterns fu1/barr1, fu1/barr2, etc., mapping to the relevant property paths.
In a preferred embodiment of the present invention, specific pieces of code are generated to deal with different maximum and minimum occurrences. Such pieces of code are generated inside the <fu> </fu> tags that were generated as described hereinabove. Preferably, the general rule for producing such pieces of code is as follows in Table CXLVIII:
As an exemplary illustration, suppose the complexType appears in the target schema as follows:
Then, based on the above cases, the following XSLT script is generated.
Suppose that the properties of <fu> are listed in a choice complex-type in the target schema. Assume again, as above, that fu is mapped to an ontological class Foo, with each of bari mapped to a property, Foo.bari. Assume further, as above, that the source XML schema has an Xpath pattern foo that maps to the ontological class Foo, with further children patterns foo/barr1, foo/barr2, etc., mapping to the relevant property paths.
Preferably, the general rule for producing XSLT script associated with a target choice bloc is as follows. Start with the tags <xs1:choose> </xs1:choose>. For each element in the choice sequence, insert into the choose bloc <xs1:when test=“barr”> </xs1:when> and within that bloc insert code appropriate to the cardinality restrictions of that element, exactly as above for sequence blocs, including the creation of new templates if needed. Finally, if there are no elements with minOccurs=“0” in the choice bloc, select any tag <barr> at random in the choice bloc, and insert into the XSLT, right before the closing </xs1:choose>, <xs1:otherwise> <barr> </barr> </xs1:otherwise>.
As an exemplary illustration, suppose the complexType appears I the target schema as follows:
Then, based on the above cases, the following XSLT script is generated.
Suppose that the properties of <fu> are listed in an all complex-type in the target schema. Assume again, as above, that foo is mapped to an ontological class Foo, with each of bar.sub.i mapped to a property, Foo.bar.sub.i. Assume further that the source XML schema has an Xpath pattern foo that maps to the ontological class Foo, with further children patterns foo/barr1, foo/barr2, etc., mapping to the relevant property paths.
In a preferred embodiment of the present invention, a general rule is to test for the presence of each of the source tags associated with the target tags, by way of
Preferably, if any of the elements has minOccurs=“1” then the negative test takes place as well:
As an exemplary illustration, suppose the complexType appears I the target schema as follows:
Then the following XSLT script is generated.
6. In a preferred embodiment of the present invention, when the elements of foo/bar1, foo/bar2, etc. have been processed as above in step 5, everything repeats in a recursive manner for properties that are related to each of the bari elements. That is, if the target XML schema has further tags that are children of bar1, bar2, etc., then preferably each of those is treated as properties of the respective target classes of bar1, bar2, and so on, and the above rules apply recursively.
A feature of the present invention is the ability to generate statistical reports describing various statistics relating to data schemas mapped to a central ontology model.
Tables CXLIX, CL and CLI include sample statistical reports.
Although the examples presented hereinabove use relational database schemas and XML schemas, it will be appreciated by those skilled in the art that the present invention applies to a wide variety of data structures, conforming to respective schemas. Also, the central ontology model into which the schemas are mapped may be a generic industry model, or an enterprise specific model.
The same data can often be represented in different ways. Relational database schemas and XML schema documents are two ways of representing data, and are examples of metadata models; i.e., structural models for representing data. Other familiar metadata models include, for example, ontology models, Cobol Copy Books, entity-relationship diagrams (ERD), DARPA Agent Markup Language (DAML), Resource Description Framework (RDF) models and Web Ontology Language (OWL). Such metadata models are designated generically by M1, and the data itself represented according to a metadata model is designated generically by M0. The notation M1 and M0 conveys that an M1 is a schema for an M0.
At a higher level of generality, the Meta Object Facility (MOF) is an Object Management Group (OMG) standard for defining metadata models themselves. MOF is used to define types of metadata and their associations; for example, classes and properties thereof, tables and columns thereof, or XML ComplexTypes and elements thereof. MOF is designated generically by M2, indicating that it is a schema for an M1; i.e., a “schema for schemas.”
The XML Metadata Interchange (XMI) schema is also an M2, being a standard for defining XML schemas. Specifically, XMI is an XML schema that specifies XML formats for metadata.
Generally, an M1 schema includes an atomic data type and a composite data type, the composite data type including zero or more atomic data types therewithin. For relational database schemas, the composite data type is a table and the atomic data type is a column of. Similarly, for XML schemas, the composite data type is a ComplexType and the atomic data type is an element therewithin; for COBOL Copy Books, the composite data type is a COBOL group and the atomic data type is a COBOL field therewithin; and for ontology schemas the composite data type is a class and the atomic data type is a property thereof.
In addition, an M1 schema may include additional structure such as (i) inheritance between composite data types, i.e., a composite data type that inherits atomics data types from another composite data type; and (ii) referential atomic data types, i.e., an atomic data type within a composite data type that is itself a reference to another composite data type. An example of inheritance is class inheritance within an ontology model, and an example of a referential atomic data type is a foreign key column within a relational database table.
Similarly, an M1 schema may include operations such as a join operation for combining relational database tables.
In a preferred embodiment of the present invention, an interface, such as a graphical user interface (GUI) or an application programming interface (API), is provided which enables atomic and composite data types to be identified with aspects of a particular data technology. For example, using such an API, a COBOL Copy Book can be designated as a new type of asset, for which composite data types are identified with COBOL groups and atomic data types are identified with COBOL fields. In addition, such an interface can also be used to designate icons and forms for displaying COBOL Copy Books.
It will be apparent to those skilled in the art that the present invention applies to mapping M2 schemas for metadata into a central metamodel for metadata. Metadata repositories, data modeling tools and runtime environments such as Enterprise Application Integration (EAI) and Extraction, Transformation and Loading (ETL), typically use different formats, or structures, for metadata. A metamodel for the structure of a data model can specify, for example, that data models have “entities” and “relationships.” Using the present invention, schemas with respect to which the various modeling tools persist metadata can be mapped to the metamodel. In turn, the present invention can be used to generate a transformation script that translates metadata from one modeling tool to another, thus enabling interoperability for metadata exchange.
Moreover, the present invention can be applied to the two meta-levels M1 and M2. That is, an M1 can be imported in a syntax specified by an M2, where the M2 has a structure corresponding to a central metamodel.
In reading the above description, persons skilled in the art will realize that there are many apparent variations that can be applied to the methods and systems described. A first variation to which the present invention applies is a setup where source relational database tables reside in more than one database. The present invention preferably operates by using Oracle's cross-database join, if the source databases are Oracle databases. In an alternative embodiment, the present invention can be applied to generate a first SQL query for a first source database, and use the result to generate a second SQL query for a second source database. The two queries taken together can feed a target database.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made to the specific exemplary embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
This application is a continuation-in-part of assignee's application U.S. Ser. No. 10/340,068, filed on Jan. 9, 2003 now abandoned, entitled “Brokering Semantics between Web Services”, which is a continuation-in-part of assignee's application U.S. Ser. No. 10/302,370, filed on Nov. 22, 2002 now U.S. Pat. No. 7,673,282, entitled “Enterprise Information Unification”, which is a continuation-in-part of assignee's application U.S. Ser. No. 10/159,516, filed on May 31, 2002 now abandoned, entitled “Data Query and Location through a Central Ontology Model,” which is a continuation-in-part of application U.S. Ser. No. 10/104,785, filed on Mar. 22, 2002 now U.S. Pat. No. 7,146,399, entitled “Run-Time Architecture for Enterprise Integration with Transformation Generation,” which is a continuation-in-part of application U.S. Ser. No. 10/053,045, filed on Jan. 15, 2002 now abandoned, entitled “Method and System for Deriving a Transformation by Referring Schema to a Central Model,” which is a continuation-in-part of assignee's application U.S. Ser. No. 09/904,457 filed on Jul. 6, 2001 now U.S. Pat. No. 7,093,200, entitled “Instance Brower for Ontology,” which is a continuation-in-part of assignee's application U.S. Ser. No. 09/866,101 filed on May 25, 2001 now U.S. Pat. No. 7,099,885, entitled “Method and System for Collaborative Ontology Modeling.”
| Number | Name | Date | Kind |
|---|---|---|---|
| 5295242 | Mashruwala et al. | Mar 1994 | A |
| 5499371 | Henninger et al. | Mar 1996 | A |
| 5627979 | Chang et al. | May 1997 | A |
| 5710917 | Musa et al. | Jan 1998 | A |
| 5734887 | Kingberg et al. | Mar 1998 | A |
| 5768580 | Wical | Jun 1998 | A |
| 5838965 | Kavanagh et al. | Nov 1998 | A |
| 5857197 | Mullins | Jan 1999 | A |
| 5873093 | Williamson et al. | Feb 1999 | A |
| 5905987 | Shutt et al. | May 1999 | A |
| 5937409 | Wetherbee | Aug 1999 | A |
| 5970490 | Morgenstern | Oct 1999 | A |
| 5995756 | Herrmann | Nov 1999 | A |
| 6014666 | Helland et al. | Jan 2000 | A |
| 6035342 | Bernstein et al. | Mar 2000 | A |
| 6192365 | Draper et al. | Feb 2001 | B1 |
| 6199059 | Dahan et al. | Mar 2001 | B1 |
| 6219654 | Ruffin | Apr 2001 | B1 |
| 6233586 | Chang et al. | May 2001 | B1 |
| 6289338 | Stoffel et al. | Sep 2001 | B1 |
| 6292804 | Ardoin et al. | Sep 2001 | B1 |
| 6301584 | Ranger | Oct 2001 | B1 |
| 6311194 | Sheth et al. | Oct 2001 | B1 |
| 6327593 | Goiffen | Dec 2001 | B1 |
| 6343265 | Glebov et al. | Jan 2002 | B1 |
| 6374252 | Althoff et al. | Apr 2002 | B1 |
| 6397232 | Cheng-Hung et al. | May 2002 | B1 |
| 6424973 | Baclawski | Jul 2002 | B1 |
| 6424974 | Cotner et al. | Jul 2002 | B1 |
| 6497943 | Jimarez et al. | Dec 2002 | B1 |
| 6498795 | Zhang et al. | Dec 2002 | B1 |
| 6513059 | Gupta et al. | Jan 2003 | B1 |
| 6526416 | Long | Feb 2003 | B1 |
| 6532471 | Ku et al. | Mar 2003 | B1 |
| 6560595 | Sanders et al. | May 2003 | B1 |
| 6578046 | Chang et al. | Jun 2003 | B2 |
| 6591272 | Williams | Jul 2003 | B1 |
| 6633869 | Duparcmeur et al. | Oct 2003 | B1 |
| 6633878 | Underwood | Oct 2003 | B1 |
| 6640231 | Andersen et al. | Oct 2003 | B1 |
| 6643633 | Chau et al. | Nov 2003 | B2 |
| 6651244 | Smith et al. | Nov 2003 | B1 |
| 6687873 | Ballantyne et al. | Feb 2004 | B1 |
| 6704744 | Williamson et al. | Mar 2004 | B1 |
| 6711579 | Balakrishnan | Mar 2004 | B2 |
| 6711585 | Copperman et al. | Mar 2004 | B1 |
| 6718320 | Subramanian et al. | Apr 2004 | B1 |
| 6728692 | Martinka et al. | Apr 2004 | B1 |
| 6732109 | Lindberg et al. | May 2004 | B2 |
| 6772031 | Strand | Aug 2004 | B1 |
| 6778990 | Garcia et al. | Aug 2004 | B2 |
| 6792580 | Kawakatsu | Sep 2004 | B2 |
| 6847974 | Wachtel | Jan 2005 | B2 |
| 6871204 | Krishnaprasad et al. | Mar 2005 | B2 |
| 6892238 | Lee et al. | May 2005 | B2 |
| 6947943 | DeAnna et al. | Sep 2005 | B2 |
| 6957214 | Silberberg et al. | Oct 2005 | B2 |
| 6978257 | Halbout et al. | Dec 2005 | B1 |
| 6985905 | Prompt et al. | Jan 2006 | B2 |
| 6999956 | Mullins | Feb 2006 | B2 |
| 7007029 | Chen | Feb 2006 | B1 |
| 7024425 | Krishnaprasad et al. | Apr 2006 | B2 |
| 7027974 | Busch et al. | Apr 2006 | B1 |
| 7096224 | Murthy et al. | Aug 2006 | B2 |
| 7111297 | Sankaranarayan et al. | Sep 2006 | B1 |
| 7200563 | Hammitt et al. | Apr 2007 | B1 |
| 7254589 | Goodwin et al. | Aug 2007 | B2 |
| 7278164 | Raiz et al. | Oct 2007 | B2 |
| 7302410 | Venkatraman et al. | Nov 2007 | B1 |
| 7315849 | Bakalash et al. | Jan 2008 | B2 |
| 7475084 | Edelstein et al. | Jan 2009 | B2 |
| 20020059183 | Chen | May 2002 | A1 |
| 20020059187 | Delo et al. | May 2002 | A1 |
| 20020099738 | Grant | Jul 2002 | A1 |
| 20020107844 | Cha et al. | Aug 2002 | A1 |
| 20020169842 | Christensen et al. | Nov 2002 | A1 |
| 20020194154 | Levy et al. | Dec 2002 | A1 |
| 20030018616 | Wilbanks et al. | Jan 2003 | A1 |
| 20030036917 | Hite et al. | Feb 2003 | A1 |
| 20030050932 | Pace et al. | Mar 2003 | A1 |
| 20030110055 | Chau | Jun 2003 | A1 |
| 20030120665 | Fox et al. | Jun 2003 | A1 |
| 20030163597 | Hellman et al. | Aug 2003 | A1 |
| 20030167445 | Su et al. | Sep 2003 | A1 |
| 20030172368 | Alumbaugh et al. | Sep 2003 | A1 |
| 20030191608 | Anderson et al. | Oct 2003 | A1 |
| 20030233224 | Marchisio et al. | Dec 2003 | A1 |
| 20040010491 | Riedinger | Jan 2004 | A1 |
| 20040054690 | Hillerbrand et al. | Mar 2004 | A1 |
| 20040117346 | Stoffel et al. | Jun 2004 | A1 |
| 20040220893 | Spivack et al. | Nov 2004 | A1 |
| 20050060371 | Cohen et al. | Mar 2005 | A1 |
| 20050080656 | Crow et al. | Apr 2005 | A1 |
| 20050138173 | Ha et al. | Jun 2005 | A1 |
| 20050197926 | Chinnappan et al. | Sep 2005 | A1 |
| 20050267871 | Marchisio et al. | Dec 2005 | A1 |
| 20060218177 | Chang et al. | Sep 2006 | A1 |
| 20070038500 | Hammitt et al. | Feb 2007 | A1 |
| 20080140549 | Eder | Jun 2008 | A1 |
| 20090077051 | Edelstein et al. | Mar 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 2001-92827 | Apr 2001 | JP |
| 2399665 | Sep 2004 | JP |
| 0115042 | Mar 2001 | WO |
| 0205137 | Jan 2002 | WO |
| 0231680 | Apr 2002 | WO |
| 02080028 | Oct 2002 | WO |
| 02099725 | Dec 2002 | WO |
| 2005010653 | Feb 2005 | WO |
| 2006020343 | Feb 2006 | WO |
| 2006071928 | Jul 2006 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20040093344 A1 | May 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10340068 | Jan 2003 | US |
| Child | 10637339 | US | |
| Parent | 10302370 | Nov 2002 | US |
| Child | 10340068 | US | |
| Parent | 10159516 | May 2002 | US |
| Child | 10302370 | US | |
| Parent | 10104785 | Mar 2002 | US |
| Child | 10159516 | US | |
| Parent | 10053045 | Jan 2002 | US |
| Child | 10104785 | US | |
| Parent | 09904457 | Jul 2001 | US |
| Child | 10053045 | US | |
| Parent | 09866101 | May 2001 | US |
| Child | 09904457 | US |
