Join Views III: One to Many Joins - View Updating and Relational Theory - page 137

numbers for suppliers who currently supply no parts.”) As a consequence, it's obvious that there
are going to be certain updates that can be done on S in particular that have no counterpart on
SSP. An example is “Insert a tuple into S for supplier S9,” without simultaneously inserting at
least one tuple for that same supplier S9 into SP.
I don't propose to investigate this example in any further detail here. Instead, I'm simply
going to appeal, as I did in Chapter 7, to the analysis of Example 2 in Chapter 6; to be more
specific, I'm going to claim that the detailed analysis of that example in Chapter 6 applies to the
present example also, mutatis mutandis. In other words, it's my opinion that the rules discussed
earlier in the present chapter for updating a strict one to many join view can be taken, if desired,
to apply to the present case as well. To paraphrase a remark from the discussions in Chapter 6, if
we can agree on this position, then we'll have agreed on a universal set of rules for updating one
to many join views that do at least always work and do guarantee that joins are strictly one to
many when they're supposed to be—not to mention the point that the rules in question in fact
work for all join views, regardless of whether the join in question is one to one, one to 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
This brings us to the end of these three chapters on updating joins. In closing, however, there are
a few additional remarks I'd like to make (they're all somewhat tangential to our main topic,
however, and you can ignore them if you want). The first concerns foreign keys. As you might
have noticed, I made no explicit mention of foreign keys as such in any of these three chapters
(nor in Chapter 5 either, on projections, come to that). In fact this omission was deliberate on
my part. The point is, there seems to be a vague notion in the database community at large that
updating joins has something to do with whether the join in a question is defined on the basis of
some foreign key and its corresponding target key, and I wanted to get away from that notion if I
could. That said, it's certainly true that several of my examples were indeed “foreign key joins”
(if I might be permitted to use such a term)—but not all of them were; in particular, the ones in
Chapter 7 weren't.
That said, I'd still like to say something about foreign keys in Tutorial D specifically. The
following example, repeated from Chapter 2, illustrates the kind of syntax normally used to
declare foreign keys:
VAR SP BASE RELATION
{ SNO CHAR , PNO CHAR , QTY INTEGER }
KEY { SNO , PNO }
FOREIGN KEY { SNO } REFERENCES S
FOREIGN KEY { PNO } REFERENCES P ;