Patent Application
20090177681
The present invention provides a method for processing a schema mapping from a source schema to a target schema to generate quasi-inverses of the schema mapping.
Schema mappings are declarative expressions that specify how data that conforms to one or more source schemas is transformed into data that conforms to a target schema. Such mappings can be viewed, in general, as high-level specifications of the data exchange process, and they can be compiled into multiple programming/query languages for the actual implementation of data exchange. A popular logical language for expressing schema mappings is the language of source-to-target tuple-generating dependencies, or source-to-target tgds.
A schema mapping from source to target is invertible if there is a schema mapping from target to source that can completely recover the data source (see Ronald Fagin, Inverting Schema Mappings. PODS 2006, pages 50-59). Existing methods of inverting (i.e., reversing) schema mappings are problematic. For example, most schema mappings in practice cannot be reversed for such reasons as a mapping may not export all source data (some filtering usually takes place), or several data sources may be integrated into one target instance which is a typical union scenario in which the information of where the data “came from” is lost.
Thus, there is a need for a method and system of reversing schema mappings that overcome at least one of the aforementioned difficulties with existing techniques for reversing schema mappings.
The present invention provides a method for processing a schema mapping M from a source schema S to a target schema T, said method performed by executing program code on a processor of a computer system, said method comprising:
determining a schema mapping M′ from T to S via processing the schema mapping M, said mapping M comprising at least one constraint σ, each constraint σ consisting of a source-to-target tuple-generating dependencies (s-t tgd), said schema mapping M′ comprising at least one constraint σ′, each constraint σ′ consisting of a disjunctive tgd with constants and inequalities among the constants; and
storing the schema mapping M′ in at least one computer usable storage device of the computer system and/or outputting the schema mapping M′ in at least one output device of the computer system.
The present invention provides a computer program product, comprising a computer readable storage medium having a computer readable program code embodied therein, said computer readable program code containing instructions that when executed by a processor of a computer system implement a method for processing a schema mapping M from a source schema S to a target schema T, said method comprising:
determining a schema mapping M′ from T to S via processing the schema mapping M, said schema mapping M comprising at least one constraint σ, each constraint σ consisting of a source-to-target tuple-generating dependencies (s-t tgd), said schema mapping M′ comprising at least one constraint σ′, each constraint σ′ consisting of a disjunctive tgd with constants and inequalities among the constants; and
storing the schema mapping M′ in at least one computer usable storage device of the computer system and/or outputting the schema mapping M′ in at least one output device of the computer system.
The present invention provides a computer system comprising a processor and a computer readable memory unit coupled to the processor, said memory unit containing instructions that when executed by the processor implement a method for processing a schema mapping M from a source schema S to a target schema T, said method comprising:
determining a schema mapping M′ from T to S via processing the schema mapping M, said schema mapping M comprising at least one constraint σ, each constraint σ consisting of a source-to-target tuple-generating dependencies (s-t tgd), said schema mapping M′ comprising at least one constraint σ′, each constraint σ′ consisting of a disjunctive tgd with constants and inequalities among the constants; and
storing the schema mapping M′ in at least one computer usable storage device of the computer system and/or outputting the schema mapping M in at least one output device of the computer system.
The present invention advantageously provides a method and system of reversing schema mappings that overcome at least one of the aforementioned difficulties with existing techniques in the related art for reversing schema mappings.
The present invention provides a system and method for reversing the data exchange process in a schema mapping. In other words, given a schema mapping from a source schema to a target schema specified by source-to-target tuple-generating dependencies (tgds), the present invention computes a quasi-inverse of a schema mapping that can be used to transform the data in the “reverse direction” (i.e., from target to source), and then use computed quasi-inverse for performing a “reverse” data exchange.
The quasi-inverse of schema mapping of the present invention eliminates or mitigates restrictive aspects of the existing inverse of schema mappings. A beneficial consequence of the quasi-inverse of a schema mapping is that data exported data with the quasi-inverse of a schema mapping can be recovered. Thus, although the entire source data may not be recovered, enough of the data source is recovered so that when the same mapping is applied again, the same information is recovered again. Furthermore, natural quasi-inverses exist in many cases where inverses do not exist.
The present invention also introduces the language of disjunctive tgds with constants and inequalities, which is an extension of the standard language of tgds. It will be explained infra that if a schema mapping specified by a finite set of tgds is quasi-invertible, then the schema mapping has a natural quasi-inverse specified by a finite set of disjunctive tgds with constants and inequalities. Methods will be described infra for computing such quasi-inverses and for using the quasi-inverses in reverse data exchange. Specifically, Algorithm A and Algorithm B will be described.
With respect to Algorithm A, given a quasi-invertible schema mapping M specified by a finite set of source-to-target tgds, Algorithm A computes a quasi-inverse M′ of M. Moreover, M′ is expressed by a finite set of disjunctive tgds with constants and inequalities.
With respect to Algorithm B, the schema mapping M′ that is the output of Algorithm A is used to implement “reverse” data exchange as follows. Given a target instance J that is the result of applying the “direct” data exchange with schema mapping M on some unknown source instance I, method B applies M′ to compute a source instance I′ such that performing data exchange on I′ with M gives a target instance that is homomorphically equivalent to J. Thus, although the original (but unknown) source instance I cannot be recovered, method B recovers a source instance I′ that produces the same result as I.
The remainder is the Detailed Description of the Invention is divided into the following sections:
When a schema S evolves into a new schema S′, a database instance I that conforms with the old schema S must be migrated (i.e., transformed) into a new database instance I′ that conforms to the new schema S′. This transformation can be represented as a schema mapping M from S to S′. The database instance I′ will then have a separate lifecycle as I i.e., (new tuples will be added in I′ and not in I). However, legacy applications or queries may continue to access the data by using the old schema S, since rewriting of these applications is typically time-consuming and expensive. In order to access the new data that is in I′, a reverse transformation from S′ to S is needed. Without the reverse transformation, the legacy applications or queries will continue to see the old data, which may not be desired. Note that the existing inverse is not applicable, since the mappings from S to S′ that typically appear in schema evolution are not invertible. However, many of the mappings are quasi-invertible by the methodology of the present invention.
Data originating from online public interfaces may be stored into internal repositories (or warehouses). The schema T of the repository does not match the schema S of an interface. Thus, a schema mapping from S to T must be created and the data must be transformed accordingly. At the same time, data must also be retrieved back, on demand, typically using the public interface schema and not the internal schema. This retrieval may be implemented by performing a quasi-inverse schema mapping from T to S to facilitate the retrieval of data.
Independent organizations must often exchange data for collaboration of business purposes. The exchange of data often occurs in the form of messages that flow from one system (S) to another (T). In order to translate between the different schemas these systems use, schema mappings are necessary. Furthermore, to make the exchange bidirectional, schema mappings are needed in both direction; i.e., from S to T and from T to S. Typically, users manually program such mappings and there is no guarantee that one of the mappings is an inverse of the other of the mappings. The present invention can be used to automatically construct quasi-inverses so that only one mapping between a pair of systems needs to be developed. Again, the existing inverse is not applicable, since a mapping from two independently designed schemas S and T will likely be not invertible. However, many of such mappings are quasi-invertible.
A schema of a database is a collection of relational atoms, wherein each relational atom represents a table of the database and consists of a relation and a set of attributers of the relation, each relation denoting a name of a table and each attribute denoting a column of the table. The attributes of each relation is represented as tuple comprising the attributes of each relation. For example, illustrative source schema S and target schema T are as follows.
S: Emp (ssn, name, addr)
T: TEmp (eid, ssn, name)
In this example, the source schema S comprises relational atoms Emp (ssn, name, addr), WorkedOn (ssn, pname, duration), and EmpEval (ssn, name, pname, duration, eval). The relational atom Emp (ssn, name, addr) consists of the relation Emp having associated attributes ssn, name, and addr. The relational atom WorkedOn (ssn, pname, duration) consists of the relation WorkedOn having associated attributes ssn, pname, and duration. The relational atom EmpEval (ssn, name, pname, duration, eval) consists of the relation EmpEval having associated attributes ssn, name, pname, duration, and eval.
Similarly, the source schema S comprises relational atoms TEmp (eid, ssn, name) and EmpProjSummary (eid, pname, duration, eval). The relational atom TEmp (eid, ssn, name) consists of the relation TEmp having associated attributes eid, ssn, and name. The relational atom EmpProjSummary (eid, pname, duration, eval) consists of the relation EmpProjSummary having associated attributes eid, pname, duration, eval.
In this example, the attributes that appear in the schemas S and T represent information about employees (ssn, eid, name, addr), the projects they worked on (pname), the duration of time they worked on a project (duration), and an evaluation file received (eval) in a year for a given project.
Given a schema S consisting of relations described by relation symbols R1, . . . , Rn (each said relation or its associated relation symbol having its respective set of attributes), a database instance (or instance) I over S is a collection of relations (or tables) r1, . . . , rn, such that for each k from 1 to n, rk has the exactly the same attributes as the relation symbol Rk. As an example,
Schema mappings are used to specify relationships between schemas. More precisely, a schema mapping between a schema S and a schema T is a formal way of asserting correspondences between instances over S and instances over T. Additionally, a schema mapping is also used as a specification of how an instance over schema S can be transformed into a corresponding instance over schema T, which will be explained infra.
It is assumed that schema mappings are given as constraints expressed in the language of source-to-target tuple-generating dependencies (tgds). Consider the following example of a schema mapping, M, between the schemas S and T. M comprises two constraints, namely t1 and t2, each being an s-t tgd.
t1: Emp(s,n,a)WorkedOn(s,p,d)→∃E∃F(TEmp(E,s,n)
EmpProjSummary(E,p,d,F))
t2: EmpEval(s,n,p,d,f)→∃E(TEmp(E,s,n)EmpProjSummary(E,p,d,f))
A schema mapping comprises at least one constraint. Each constraint is a constraint of the schema mapping. Each constraint of the schema mapping generally comprises a mapping of the form X→Y, wherein X is a “premise” and Y is a “conclusion” of the schema mapping. The symbol ̂ is a conjunction operator defined as conjoining any two relational atoms A1 and A2 by the expression A1A2. Thus, in the constraint t1, the premise is Emp(s,n,a)
WorkedOn(s,p,d), and the conclusion is ∃E ∃F (TEmp(E,s,n)̂EmpProjSummary(E,p,d,F)). In the constraint t2, the premise is EmpEval(s,n,p,d,f), and the conclusion is ∃E (TEmp(E,s,n)
EmpProjSummary(E,p,d,f)).
In the constraints, variables (e.g., s, n, p, etc.) denote the values that may appear in each of the columns. For example, in Emp (s, n), s and n are variables to represent concrete values for ssn and name, respectively. The s-t tgd t1 asserts that whenever there are two tuples in Emp and WorkedOn with the same value (denoted by s) for the ssn attribute, there exists two corresponding tuples in TEmp and EmpProjSummary. Note that s, n, p, d are “copied” to components of the target tuples: s and n are copied to TEmp; and p and d are copied to EmpProjSummary. The address field (variable a) is not copied to the target. In addition, there are several components in the target tuples that are existentially quantified (and not given by the source values). E is an existentially quantified variable as specified by ∃E, representing an eid value that must exist in both TEmp and EmpProjSummary, in order to correlate the two target tuples. Similarly, F is an existentially quantified variable as specified by ∃F, representing an “unknown” evaluation file value for the EmpProjSummary tuple that is asserted by t1.
The s-t tgd t2 is a similar constraint asserting that for each EmpEval tuple in the source there exists two corresponding tuples in TEmp and EmpProjSummary. In this case, s, n, p, d, f are “copied” to components of the target tuples, and E is existentially quantified.
Generally, in a system that evaluates a mapping, the existentially quantified variables must be replaced by unique values generated by the system. This must be the case for E in the above example, since eid plays the role of a key/foreign key. The values that must appear in the target and are not part of the source instances are called “nulls”.
Const is used to represent the set of all possible source values, and Var is used to represent the set of all possible nulls. An instance can have values in Const∪Var which may be the case for target instances. In contrast, source instances typically have values from Const alone. Such source instances with values from Const alone are called “ground instances”.
In general, given a schema S (the source schema) and a schema T (the target schema), a source-to-target tgd (s-t tgd) is defined as a first-order constraint of the form
φ(x)→∃yψ(x,y)
where φ(x) in the s-t tgd is a single relational atom in S or a conjunction of relational atoms over S, and ψ(x, y) is a single relational atom in T or a conjunction of relational atoms over T, and every variable in x occurs in a relational atom in φ(x). In the above, x represents a sequence of distinct variables and y represents a sequence of distinct variables (different from those distinct variables in x). The variables in x are universally quantified, while the variables in y are existentially quantified. A relational atom that may appear in φ is any expression of the form R(x1, . . . , xn), where R is some relation symbol of the source schema S, and x1, . . . , xn are variables (not necessarily distinct) that appear in x and denote the values for the attributes of R. Similarly, a relational atom that may appear in ψ is any expression of the form P(z1, . . . , zk), where P is some relation symbol of T, and z1, . . . , zk are variables (not necessarily distinct) that appear in x or y and denote values for the attributes of P.
A schema mapping M from S to T is a set of source-to-target tgds. In addition to source-to-target tgds, the present invention utilizes disjunctive tgds with constants and inequalities, which are used to represent the “reverse” schema mappings from T to S that are computed by Algorithm A of the present invention.
Given the source schema S and the target schema T, a disjunctive tgd (from T to S) with constants and inequalities is defined as a first-order constraint of the form:
φ(x)→∃y1ψ1(x,y1))
∃y2ψ2(x,y2))
. . .
∃ynψn(x,yn))
wherein n is at least 2, and wherein the formula φ(x) in the disjunctive tgd is a conjunction of:
Each formula ψi(x, yi), with i=1, . . . , n, is a conjunction of relational atoms over S. A formula Constant(x) evaluates to true if and only if x is interpreted by a value in Const.
Note that if n=1, the above tgd is not disjunctive.
A disjunctive tgd with constants and inequalities among constants is a special case of a disjunctive tgd with inequalities and constants where the formulas Constant(x) and Constant(x′) occur as conjuncts of φ(x) whenever the inequality x≠x′ is a conjunct of φ(x).
Given the preceding illustrative schemas S and T, note the following example of a disjunctive tgd (from T to S) with constants and inequalities among constants:
TEmp(e,s,n)EmpProjSummary(e,p,d,f) (d)
Constant(s)
Constant(n)
Constant(p)
Constant(d)
(n≠p)
→
∃A(Emp(s,n,A)WorkedOn(s,p,d))
∃F(EmpEval(s,n,p,d,F))
Schema mappings can be viewed as describing relationships between instances over two schemas. Under this view, the formulas that appear in a schema mapping are considered as inter-schema constraints. Given a schema mapping M between a schema S1 and a schema S2, the following binary relation Inst (M) is defined as follows.
Inst(M)={(I,J)|I is an instance over S1,J is an instance over S2, and (I,J) satisfies M} (1)
The binary relation Inst (M) comprises all the “valid” pairs of instances, where “valid” means pairs of instances that satisfy all the constraints that appear in M. As an example,
Note that the target instance J contains all the tuples that are required to exist according to the constraints imposed by the two s-t tgds t1 and t2, given the source instance I. Thus, the pair (I, J) is in Inst (M), and Inst(M) consists of all such pairs (I, J). In other words, given a schema mapping M from S1 to S2 and given an instance I over S1, there may be multiple instances J over S2 such that (I, J) satisfies M. For the example instance I in
The following set Sol(M, I) is defined as follows to represent all possible solutions for a given schema mapping M from S1 and S2 and a given instance I over S1:
Sol(M,I)={J|J instance over S2,(I,J) satisfies M} (2)
Sol(M, I) represents the data exchange semantics of a schema mapping M with respect to I, since Sol(M, J) encodes the set of all possible target instances that are consistent with M and I.
Given two schema mappings M12, from schema S1 to schema S2, and M23 from schema S2 to another schema S3, the composition Inst (M12)oInst (M23) is defined, in the usual mathematical sense, as the composition of the two binary relations Inst (M12) and Inst (M23):
Inst(M12)oInst(M23)={(I1,I3)|I1 is an instance over S1,I2 is an instance over S2, and there is an instance I2 over S2 such that (I1,I2) satisfies M12 and (I2,I3) satisfies M23} (3)
Then, by definition, a schema mapping M13 defines the composition of schema mappings M12 and M23 if the following equation is satisfied:
Inst(M13)=Inst(M12)oInst(M23) (4)
The previous notion of composition is defined in a general way, where the schemas S1, S2 and S3 are arbitrary schemas. Next, attention is focused on schema mappings from a source schema S to a target schema T and on their inverses (that is, schema mappings from T to S).
Let S′ be a replica of the source schema S such that for every relation symbol R of S, the schema S′ contains a relation symbol R′ that is not in S and has the same set of attributes as R. Thus, S′ is an identical copy of the schema S.
The identity schema mapping is, by definition, a schema mapping Id from S to S′, where Id consists of all the dependencies R(x)→R′(x) as R ranges over all the relation symbols in S. In other words, Id is a set of “copy” constraints from S to S′ that require all the tuples in a source instance over S appear in a replica instance over S′. Thus, Inst(Id) consists of all pairs (I1, I2) of a ground instance I1 over S and a ground instance I2 over S′ such that I1I2.
A schema mapping M′ from T to S is an inverse of a schema mapping M from S to T if Inst(Id)=Inst(M) o Inst(M′) (see Ronald Fagin, Inverting Schema Mappings. PODS 2006, pages 50-59). In other words, the identity schema mapping Id equals the composition of the schema mappings M and M′. This bears some analogy to the usual mathematical definition of an inverse function, namely composing a function with its inverse must equal the identity function.
The present invention describes a quasi-inverse of a schema mapping that is a relaxation of the existing definition of an inverse, together with Algorithm A for computing the quasi-inverse of a schema mapping and Algorithm B for using quasi-inverses for bidirectional data exchange.
The notion of a quasi-inverse is obtained from the notion of an inverse by not differentiating between ground instances that are equivalent for data-exchange purposes. In more formal terms, consider the equivalence relation ˜ between ground instances such that I1˜I2 holds if I1 and I2 have the same space of solutions; i.e., if Sol(M, I1)=Sol(M, I2). Whenever I1˜I2, I1 and I2 are said to be data exchange equivalent.
By definition, a schema mapping M′ from T to S is a quasi-inverse of a schema mapping M from S to T if Inst(M) o Inst(M′)=Inst(Id) modulo the equivalence relation ˜, which means that for every pair (I1, I2) of ground instances the following properties (1) and (2) hold:
Property (1) recites that if (I1, I2) is in Inst(M) o Inst(M′) then, although (I1, I2) does not have to be in Inst (Id), some data exchange equivalent instances I1′ and I2′ satisfy that (I1′, I2′) is in Inst(Id). In other words, if I2 is a result (solution) of M o M′ with respect to I1, then I2 is data exchange equivalent to some I2′ that is a result (solution) of Id with respect to some instance I1′ that is data exchange equivalent to I1. Thus, the composition M o M′ has the same data exchange behavior as the identity mapping Id, as long as differences between data exchange equivalent instances are not taken into consideration. A similar explanation holds for Property (2).
This relaxation of the notion of an inverse for the quasi-inverse is quite useful in practice, because there are many practical examples where inverses do not exist but quasi-inverses do exist. Furthermore, although quasi-inverses do not fully recover a source instance, quasi-inverses can be used to recover an instance that is equivalent for data exchange purposes (see Algorithm B, described infra). Thus, quasi-inverses can be seen as approximations of inverses and are useful when inverses do not exist. If an inverse mapping exists, the mapping is said to be invertible.
Quasi-inverses have larger applicability than inverses.
The examples of
The input to Algorithm A comprises a schema mapping M from S to T, expressed as a set of source-to-target tgds (e.g., the schema mapping M={t1, t2}, described supra).
The output from Algorithm A comprises a schema mapping M from T to S, expressed as a set of disjunctive tgds with constants and inequalities among the constants, which represents a quasi-inverse of M if such quasi-inverse exists.
Step 195 of
For example, consider the earlier schema mapping M={t1, t2}. In the case of t1, the set of variables that appears in both the premise and the conclusion is {s, n, p, d}. It is assumed, for illustration purposes, that n and p have the same type (“string”), s is of type “integer”, and d is of type “duration”. Then, the only non-empty equality pattern C on {s, n, p, d} that is well-typed is the equality “n=p”. Thus, the following constraint t1′ is generated in step 195:
t1′: Emp(s,n,a)WorkedOn(s,n,d)→∃E∃F(TEmp(E,s,n)
EmpProjSummary(E,n,d,F))
Constraints such as t1′ are considered by the algorithm in order to account for all combinations of values in the target, including any accidental matching of values. In this example, the employee name in a TEmp tuple may match the project name in an EmpProjSummary if such match is coming from the source database.
For the second s-t tgd t2 in M, the set of variables that appears in both the premise and the conclusion is {s, n, p, d, f}. It is assumed, for illustration purposes, that n and p have the same type (“string”), s is of type “integer”, and d is of type “duration”. Furthermore, it is assumed that f is of a type “file”. Then, the only non-empty equality pattern C on {s, n, p, d, f} that is well-typed is the equality “n=p”. Thus, the following constraint t2′ is also generated in step 195:
t2′: EmpEval(s,n,n,d,f)→∃E(TEmp(E,s,n)EmpProjSummary(E,n,d,f)
The schema mapping M* that results at the end of step 195, for this example, is M*={t1, t2, t1′, t2′}.
Step 200 of
Emp(s,n,a)WorkedOn(s,p,d)→∃E∃F(TEmp(E,s,n)
EmpProjSummary(E,p,d,F))
Step 205 of
Step 210 of
∃E∃F(TEmp(E,s,n)EmpProjSummary(E,p,d,F)) (5)
In the example, x={s, n, p, d} and y={E, F}, wherein the variables s, n, p, d in x are universally quantified and the variables E, F in y are existentially quantified.
The minimal generators are defined as follows. Let β(x, z) be a conjunction of relational atoms over the source schema S, and let ψ(x, y) be a conjunction of relational atoms over the target schema T, where x, y, z are sets of distinct variables, and the members of x are exactly the variables that appear in both β(x, z) and ψ(x, y). β(x, z) is defined to be a generator of ∃y ψ(x, y) if the s-t tgd β(x, z)→∃y ψ(x, y) is logically implied by the s-t tgds in M. Moreover, β(x, z) is a minimal generator of ∃y ψ(x, y) if β(x, z) is a generator of ∃y ψ(x, y) and there is no β′(x, z′) that is a conjunction of a strict subset of the relational atoms in β(x, z) such that β′(x, z′) is a generator of ∃y ψ(x, y).
It is known from the standard relational theory of dependencies that logical implication of tgds can be checked by using the chase method (see David Maier, Alberto O. Mendelzon, Yehoshua Sagiv, Testing Implications of Data Dependencies, ACM Trans. Database Syst. 4(4): 455-469 (1979)). To check whether β(x, z)→∃y ψ(x, y) is logically implied by the s-t tgds in M, it is determined whether the chase of β(x, z) with the s-t tgds in M gives the relational atoms in ψ(x, y′) for a substitution of y by y′. An example of how the chase is applied will be provided infra. The terminology “chasing Z” means “applying a chase to Z”, wherein Z denotes an entity (e.g., an instance) to which the chase is applied.
Step 211 of
Step 212 of
As an example, consider the earlier formula (5). It can be verified that s1=2, since the maximum number of relational atoms in the premise of the s-t tgds in M is 2. Also, it can be verified that s2=2, since there are two relational atoms in the formula (5). Thus, there is a need to consider all combinations β(x, z) with at most 4 relational atoms over the source schema S, where x={s, n, p, d}. The following are two such combinations (in general there are an exponential number of distinct combinations) are:
Emp(s,n,a)WorkedOn(s,p,d) (6)
Emp(s,n,a)WorkedOn(s′,p,d) (7)
Emp(s,n,a)WorkedOn(s′,p,d)
EmpEval(s,n,p,d,f) (8)
The formula (6) is an example of β(x, z) with two relational atoms where x={s, n, p, d} and where z={a}. By chasing formula (6) (i.e., applying a chase to formula (6)) with the first tgd (t1) in M, the two relational atoms are obtained in the conclusion of t1, said conclusion of t1 being TEmp(E,s,n)̂EmpProjSummary(E,p,d,F). Said conclusion of t1 comprises precisely the relational atoms in formula (5). Thus, formula (6) is a generator for formula (5).
Formula (7) is another example of β(x, z) with two relational atoms where x={s, n, p, d}, but where z={a, s′}. It can be verified that no chase steps with the tgds in M apply (for example, the tgd t1 only applies if Emp and WorkedOn join on the first field, which is not the case, since s and s′ are distinct variables.). Thus, formula (7) is not a generator for formula (5).
Formula (8) is yet another example of β(x, z), this time, with three relational atoms, where x={s, n, p, d} and where z={a, s′, f}. By chasing formula (8) with the second tgd (t2) in M, the two relational atoms are obtained in the conclusion of t1, said conclusion of t1 being TEmp(E,s,n)̂EmpProjSummary(E,p,d,F) where F is substituted by f. Thus, formula (8) is another generator for formula (5).
In step 213 of
In other words, step 213 performs a generator removal process comprising removing from G′ each generator determined to not be a minimal generator satisfying a condition of non-existence of any generator that is a conjunction of a strict subset of the relational atoms in the minimal generator. The preceding generator removal process in step 213 results in G′ becoming the set G of minimal generators.
As an example, the formula (8) above is not a minimal generator. There is another formula:
EmpEval(s,n,p,d,f) (9)
that is a generator for (5). Furthermore, the relational atoms in (9) form a strict subset of the relational atoms in (8) and, hence, (8) is not a minimal generator. In contrast, (9) is a minimal generator.
At this point, G contains the set of all minimal generators for ∃y ψ(x, y) and execution of step 210 is finished. For this example, the minimal generators for formula (5) are the two formulas (6) and (9).
Step 220 of
As an example, for the earlier s-t tgd t1, the following disjunctive tgd with inequalities and constants among inequalities is created:
TEmp(e,s,n)EmpProjSummary(e,p,d,f) (d)
Constant(s)
Constant(n)
Constant(p)
Constant(d)
(n≠p)
→
∃A(Emp(s,n,A)WorkedOn(s,p,d))
∃F(EmpEval(s,n,p,d,F))
Note the Constant predicate added for each variable in x={s, n, p, d} and also the inequality between the two variables n and p that have the same type. The two minimal generators (formulas (6) and (9) computed in step 212 and 213, respectively) have been added as terms in the disjunction. Note that the variables that appear in the minimal generators, but are not part of x, are existentially quantified (e.g., E and F).
The algorithm terminates with the set of all constraints σ′ (one for each constraints σ* of M*).
The set M′ of all such constraints σ′ (each a disjunctive tgd with constants and inequalities among constants) describes a “reverse” relationship between instances over T and instances over S that is implied by the input schema mapping M. It is noted that there are cases where the schema mapping may not have any quasi-inverses. In such cases, the result M′ of the algorithm A is not a quasi-inverse (although M′ can still be used with Algorithm B). However, in the more common case when M is quasi-invertible, Algorithm A is guaranteed to produce a schema mapping M′ that is a quasi-inverse of M.
In addition to describing a relationship, a schema mapping can be viewed as describing a process (data movement) in which a canonical target instance is materialized, given a source instance I and the schema mapping. This process is called data exchange. If M is a schema mapping from S to T that is expressed as a set of s-t tgds, the chase method can be used to compute a canonical target instance JC over T, when given a source instance I over S. The chase method is a classical method in relational database theory see (David Maier, Alberto O. Mendelzon, Yehoshua Sagiv, Testing Implications of Data Dependencies. ACM Trans. Database Syst. 4(4): 455-469 (1979)). The present invention uses a variation of the chase that applies on instances instead of constraints. This chase is next described.
At the beginning of the chase, the target instance JC is empty. Then, for each s-t tgd t in M, and for each instantiation of the relational atoms in the premise to concrete tuples in the source instance I, the chase adds corresponding tuples to the target instance JC such that the conclusion of t is satisfied. Any existentially quantified variables that appear in the conclusion of the constraint are replaced by fresh new nulls in the actual tuples that are added in the target. These nulls are distinct from any of the source values and different from any earlier nulls. The process is repeated until all the constraints in M are satisfied.
As an example,
First, the two relational atoms in the left-hand side of t1 can be instantiated with the first Emp tuple, [175059999, Alice, 100 Clover Pl.] and the first WorkedOn tuple, [175059999, iNet, 2 yr]. Then, to satisfy the right-hand side of t1, two target tuples must be created in TEmp and EmpProjSummary (the first rows in the two target tables of
The process continues with the next instantiation of the left-hand relational atoms of t1: the second tuple in Emp and the second tuple in WorkedOn. Two more tuples are added to the target. At this point, the constraint t1 is satisfied, and the chase continues with t2. Two more target tuples are added in each of TEmp and EmpProjSummary. The chase finishes with the target instance JC shown in
A similar chase process can be applied for the reverse data exchange, in order to migrate the target data back to the source schema, based on a quasi-inverse mapping. In such case, the chase must be extended to handle disjunctive tgds with constants and inequalities among constants, since the constraints in a quasi-inverse mapping are of this form (see Algorithm A). The main difference from the previously described chase is that now the chase may end up with a set of possible source instances. This is due to the fact that constraints have disjunction.
The disjunctive chase works from a target instance and constructs a set of source instances, as follows. As with the normal chase, for each instantiation of the relational atoms in the left-hand side of a constraint, tuples must be added to satisfy the conclusion of the constraint. However, because of disjunction, there are actually several choices: tuples can be added to satisfy any one of the terms in the disjunction (see the earlier constraint (d) for an example where there are two choices). The disjunctive chase considers all possible choices, by constructing alternative source instances, where each satisfies one of the choices. This process repeats with each of the resulting source instances, for the remaining instantiations and constraints that are not yet satisfied. In particular, each resulting source instance can subsequently branch in further alternative instances. The final result of the disjunctive chase is a set of source instances, where each source instance satisfies the constraints of the quasi-inverse mapping.
In general, target instances that are computed from source instances based on schema mappings are incomplete. The target instances may contain nulls (e.g., E1, E2, F2 in the target instance J shown in
By definition, a homomorphism from a target instance J to a target instance J′ is a function h from the values of J to the values of J′ such that: (1) h(c)=c, for every source (i.e., non null) value c, and (2) for every tuple (v1, . . . , vm) that appears in some relation R of J, a corresponding tuple (h(v1), . . . , h(vm)) must appear in the relation R of J′. Two target instances J and J′ are homomorphically equivalent if there exist two homomorphisms; i.e., one homomorphism from J to J′ and another homomorphism from J′ to J.
As an example, the two instances J and J′ discussed supra (where J′ uses ID1, ID2, and X2, instead of E1, E2 and F2) are homomorphically equivalent.
By definition, two source instances I and I′ have the same data exchange properties with respect to M, if the canonical target instance Jc obtained from 1 and M is homomorphically equivalent to the canonical target instance Jc′ obtained from I′ and M.
Note that for bidirectional data exchange between two schemas S and T, recovering a source instance I′ that has the same data exchange properties as I is good enough since when data exchange is applied again, no difference will be seen (whether starting is from the original source instance I or from I′).
Algorithm B shows how to recover a source instance in a reverse data exchange by using the schema mapping that is obtained by Algorithm A. In particular, if a source instance I is transformed into a canonical target instance Jc based on a schema mapping M, Algorithm B can use a quasi-inverse M′ to recover a source instance I′ that has the same data exchange properties as I.
The input to Algorithm B comprises: (1) a schema mapping M from S to T, expressed as a set of source-to-target tgds (e.g., the schema mapping M={t1, t2}, described supra); (2) a schema mapping M′ that is the result of Algorithm A (on input M), expressed as disjunctive tgds with constants and inequalities among constants; and (3) source instance I over S.
The output from Algorithm B comprises source instance I′ that has the same data exchange properties as I, with respect to M.
Step 310 of
Step 320 of
Step 330 of
Step 321 of
Step 322 of
Step 323 of
Algorithm B is guaranteed to find some instance Ik for which step 303. will succeed, provided that the schema mapping M′ that is used for reverse data exchange is the one produced by Algorithm A (for proof, see Ronald Fagin, Phokion G. Kolaitis, Lucian Popa, Wang-Chiew Tan. Quasi-Inverses of Schema Mappings. PODS 2007, pages 123-132). Note that M′ is a quasi-inverse of M in the case when M is quasi-invertible. However, Algorithms A and B are applicable even in the case when M is not quasi-invertible. Thus, the schema mapping M′ obtained by algorithm A is always applicable in Algorithm B to recover a source instance with the same data exchange properties.
Thus the present invention discloses a process for deploying or integrating computing infrastructure, comprising integrating computer-readable code into the computer system 90, wherein the code in combination with the computer system 90 is capable of executing software to implement the methodology of the present invention.
While
While particular embodiments of the present invention have been described herein for purposes of illustration, many modifications and changes will become apparent to those skilled in the art. Accordingly, the appended claims are intended to encompass all such modifications and changes as fall within the true spirit and scope of this invention.
