Databases Reference
In-Depth Information
many, or many to many. What's more, if those rules do sometimes give rise to consequences
that are considered unpalatable for some reason, then there are always certain pragmatic fixes,
such as using the DBMS's authorization subsystem to prohibit certain updates, that can be
adopted to avoid those consequences.
CONCLUDING REMARKS
There's one more point I want to make in connection with many to many joins. It has to do with
the fact that—as is of course well known—cartesian product is a special case of many to many
join. It follows that the rules for updating through a many to many join apply to cartesian
product in particular (more precisely, they reduce to the rules for updating through a cartesian
product, in the case where the join itself reduces to a cartesian product). To spell those rules out,
let
V
be defined as
A
TIMES
B
and let
HA
and
HB
be the attributes of
A
and
B
, respectively, and
let
HA
and
HB
have no attribute names in common. Then we have:
ON INSERT
i
INTO
V
:
INSERT
i
{
HA
} INTO
A
,
INSERT
i
{
HB
} INTO
B
;
ON DELETE
d
FROM
V
:
DELETE ( (
A
MATCHING
d
) NOT MATCHING
V
) FROM
A
,
DELETE ( (
B
MATCHING
d
) NOT MATCHING
V
) FROM
B
;
ON INSERT
ia
INTO
A
, INSERT
ib
INTO
B
:
INSERT (
B
TIMES
ia
) INTO
V
,
INSERT (
A
TIMES
ib
) INTO
V
;
ON DELETE
da
FROM
A
, DELETE
db
FROM
B
:
DELETE (
V
MATCHING
da
) FROM
V
,
DELETE (
V
MATCHING
db
) FROM
V
;
