Database Reference
In-Depth Information
7.3
Denotational Model (Database-Mapping Process) Algebra
First of all, we need to clarify the relationships between the
database-mapping pro-
grams
specified by a schema-mapping graph
G
(V
G
,E
G
)
, where the nodes in
V
G
are the database schemas and the edges in
E
G
are the SOtgds which logically spec-
ify the schema mappings, and the
process-algebra language
(or its grammar) able
to specify the execution of the database-mapping programs by a kind of process-
programs. From the algebraic point of view, this
database-mapping program
is rep-
resented by the sketch category
Sch
(G)
(with the embedding
γ
:
G
→
=
Sch
(G)
)
where the arrows are algebraic R-operads obtained by “algebraization” of the SOt-
gds with its models represented by the R-algebras (i.e., the functors)
α
∗
:
Sch
(G)
→
DB
satisfying all sketch's arrows, that is,
α
∗
∈
DB
Sch
(G)
.The
input
for such a program specified by the graph
G
(or sketch
Sch
(G)
) is a model
α
∗
:
Mod(G)
⊆
A
∈
V
G
,in
one of two possible ways described in Sects.
7.2.1
and
7.2.2
, so that after such
an update with obtained instance-database
A
Sch
(G)
→
DB
and a
A
of initial updating of a node (schema)
α
∗
(
)
, this modified functor
α
is
not generally a new model of the mapping system
G
. Thus, the execution of the
database-mapping program in
Sch
(G)
begins with this initial updating of
=
A
A
and
propagates in backward-chaining (if
A
is a deletion of tuples in
A
)orinforward-
chaining (if
A
is an insertion of tuples in
A
) up to the moment when is reached
the end. Two semantic scenarios are possible:
•
Strong Data Integration
. In this version, we consider the schema mappings and
the integrity constraints of the schemas at the same ontological level, without
any epistemic distinction of them. Thus, the updates (deletions and insertions)
in each “local” database (a schema vertex in a graph
G
) caused by the schema
mappings are obligatory and has to be respected as every integrity constraint of
the schemas. This renders inconsistent the whole logic of a database mapping
system if every mapping in
G
is not satisfied, so that from the architectural point
of view this is a strongly centralized omniscient system, as in the case of a data-
exchange setting. The end of a backward/forward chaining described above, in
this case, must result in
a new model
(i.e., functor)
α
1
∈
DB
Sch
(G)
of
G
of the whole mapping system
G
(i.e., a model of all schemas and all schema
mappings as well).
Mod(G)
⊆
•
Weak Data Integration
. In this case, we only preserve the requirements that each
single instance-database in
G
must be a model of its schema (as in all practical
applications of RDB systems with the legacy application over them, which pre-
serves its integrity constraints), but do not require that at the end of such a back-
ward/forward chaining all (inter)schema mappings have to be satisfied. Thus, the
architecture of such a solution will have two levels: a strong consistency level
for each independent database in
G
, and a higher epistemic level which uses
the SOtgd's schema mappings in order to communicate to single databases in
G
the
recommendations
which information has to be inserted/deleted in them as a
response to one local changing of information in one database in
G
. The epis-
temic independence of these two logical systems permits each single database
to (partially) implement such recommendations (if they are consistent with their
