Database Reference
In-Depth Information
local knowledge) or not (for example, when deleting some information of a lo-
cal database is recommended and such information is locally managed by its
own legacy applications; or when inserting the tuples which would make the
local knowledge inconsistent is recommended). In such an architecture, we do
not require that each schema mapping in
G
be satisfied in each stable state of a
database mapping system in
G
(i.e., when any backward/forward chaining is not
in action).
If we adopt a P2P database architecture for a database mapping system in
G
, where
each schema (a vertex in
G
) is a peer database, then we can consider a number
of papers [
9
,
10
,
12
,
15
,
16
,
21
,
23
] that describe the Strong Data Integration and,
especially, the problems about the inconsistencies caused by a forced transfer of
the information from other peers into a given peer with its own local knowledge of
integrity constraints.
The second solution is a more sophisticated solution, and it makes explicit an
epistemic difference from the local knowledge of each peer (which is consistently
managed by its own legacy applications) and the imported information from other
peers: each peer (partially) accepts the imported information from other peers and
is independent in its own decision which one to accept and which one to ignore.
This extra knowledge received from a network of other peers and filtered locally
(based on local knowledge) is similar to a kind of the social database-networks,
where this imported knowledge from other peers is used not to brutally substitute
its local consistent knowledge but only to consistently enlarge it (thus, it is a much
more flexible solution of the standard data-exchange settings). Such an epistemic
solution, however, without a material transfer of the information between the peers,
based on an intensional FOL is analyzed in a number of papers [
24
-
32
].
In such a P2P architecture, each database schema (or vertex in
G
) can be im-
plemented as an independent peer database
V
G
managed by a universal ma-
chine
M
U
A
(with its DBMS machine
M
R
A
), and the schema mappings are used
as a program of a universal machine
M
U
DB
which communicate by
Out
U
and
In
∗
EU
functions (see Definition
38
in Sect.
6.1
) with each single peer database ma-
chine
M
U
A
. In fact, for example, during a forward chaining process, for a given
mapping
A
∈
M
AB
:
A
→
B
and its operads-operations
q
i
∈
MakeOperad(
M
AB
)
,
q
i
∈
O(r
A
1
,...,r
A
1
,r
B
i
)
,
M
U
DB
will ask
M
U
A
for the extensions of the current
relations
r
A
j
,j
1
,...,k
, and
M
U
B
for the extension of
r
B
i
,byusing
Out
U
and
In
∗
EU
functions. Hence, it will compute
=
and
hence communicate it with
Out
U
to the machine
M
U
B
. The machine
M
U
B
will take
B
recommended to be inserted into
B
B
by its
In
∗
EU
function and then will decide which part of it to (consistently) insert
into its database
α
1
(
B
=
B
)
.
We are interested in the operational semantics of such programs specified by a
graph
G
(i.e., a
program
) in the machine
M
U
DB
, that is, in their
processes
of execu-
tion provided by its Computation system (Definition
37
in Sect.
6.1
), but abstracted
(reduced) to the transitions of the types defined in Propositions
31
and
32
, and then
refined as follows.
In order to be able to provide this operational semantics, the first step is just
to specify
which
algebra of processes is adequate for it, and to define its process-
programming grammar (or language). Hence, in what follows in this chapter,
by generation of a new model (instance-database)
B
