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)
.