Database Reference
In-Depth Information
ROUTES
INFO FLIGHT
SERVES
f#
src
dest
f#
dep
arr
airl
airl
city
coun phone
(1)
(2)
(1)
(1)
(1)
(2)
(2)
src
dest
airl
dep
city
coun
pop
FLIGHT
GEO
Figure 1.2 Schema mapping: a proper graphical representation
Furthermore, there are several rules in a mapping that help us populate the target
database. In this example, we can distinguish two rules. One uses table FLIGHT to pop-
ulate ROUTES and INFO FLIGHT , and the other uses both FLIGHT and GEO to populate
SERVES . So in addition we annotate arrows with names or numbers of rules that they are
used in. Such a revised representation is shown in Figure 1.2 .
While it might be easy for someone understanding source and target schemas to produce
a graphical representation of the mapping, we need to translate it into a formal specifica-
tion. Let us look at the first rule which says:
whenever we have a tuple (src,dest,airl,dep) in relation FLIGHT , we must have a tuple in
ROUTES that has src and dest as the values of the second and the third attributes, and a tuple in
INFO FLIGHT thathas dep and airl as thesecondand the fourthattributes.
Formally, this can be written as:
−→
ROUTES( ,src,dest) , INFO FLIGHT( ,dep, ,airl) .
FLIGHT(src,dest,airl,dep)
This is not fully satisfactory: indeed, as we lose information that the flight numbers must be
the same; hence, we need to explicitly mention the names of all the variables, and produce
the following rule:
FLIGHT(src,dest,airl,dep) −→
ROUTES(f#,src,dest) , INFO FLIGHT(f#,dep,arr,airl) .
What is the meaning of such a rule? In particular, what are those variables that appear
in the target specification without being mentioned in the source part? What the mapping
says is that values for these variables must exist in the target, in other words, the following
must be satisfied:
FLIGHT(src,dest,airl,dep) −→
f# arr ROUTES(f#,src,dest)
INFO FLIGHT(f#,dep,arr,airl) .
Search WWH ::




Custom Search