Database Reference
In-Depth Information
Fig. 4.1
Conceptual
architecture
In what follows, we will consider the translation of the data exchange/integration
systems into our semantic framework. In this framework, the concepts are defined
in a more abstract way than in the instance database framework represented in the
“computational”
DB
category. Consequently, we require an interpretation mapping
from the scheme into the instance level, which will be given categorially by functors.
4.2.1 Data Integration/Exchange Framework
The task of a data integration system [
10
] is to provide the user with a unified view,
called
global schema
, of a set of heterogeneous data sources. Once the user issues a
query over the global schema, the system carries out the task of suitably accessing
the different sources and assemble the retrieved data into the final answer to the
query. In this context, a crucial issue is the specification of the relationship between
the global schema and the sources, which is called
mapping
[
7
,
10
]. In this section,
we use a more complex mapping, called GLAV [
4
,
6
], which consists in associating
views over the global schema to views over the sources.
Since the global schema is a representation of the domain of interest of the sys-
tem, it needs to be represented by means of a flexible an expressive formalism: to
this aim,
integrity constraints
are expressed on it. The data at the sources may not
satisfy the constraints on the global schema; in this case, a common assumption
(which is the one adopted in what follows) is to consider the sources as
sound
, i.e.,
they provide a
subset
of the data that satisfy the global schema.
We formalize a
relational data integration system
I
in terms of a triple
G
,
S
,
M
, where
•
G
=
(S
G
,Σ
G
)
is the
target global schema
, expanded by the
new unary predicate
Va l(
_
)
such that
Va l(c)
is true if
c
∈
dom
,expressedinaFOL.
•
S
is the
source schema
, expressed in a FOL. While the source integrity con-
straints may play an important role in deriving dependencies in
, they do not
play any direct role in the data integration/exchange framework and we may ig-
nore them.
•
M
M
is the
mapping
between
G
and
S
, constituted by a set of
assertions
q
S
q
,
(4.1)
G
