Databases Reference
In-Depth Information
in the relvar” to each part of this rule, since we're talking about a one to one join and the
A
portion of
t
simply won't exist elsewhere in
A
, nor will the
B
portion of
t
exist elsewhere in
B
).
If we can agree on the foregoing position, then we'll have agreed on a universal set of rules
for updating one to one join views that do at least always work and do guarantee that joins are
strictly one to one when they're supposed to be. What's more, if those rules do sometimes give
rise to consequences that are considered unpalatable for some reason, then there are always
certain ad hoc fixes (such as using the DBMS's authorization subsystem to prohibit certain
updates) that can be adopted to avoid those consequences.
Note:
Please don't misunderstand me here. I'm not saying we
must
employ such fixes in
order for the system to work properly. A system that relies for its correct operation on the user,
or the DBA, always “doing the right thing”—e.g., using the authorization subsystem
appropriately—is obviously not acceptable.
8
So we must always at least permit join view
updates, even when the joins aren't strictly one to one, and we must have a set of rules that work
even in that case. That's why I advocate the position I do.
9
CONCLUDING REMARKS
There are a couple of final points I'd like to make in connection with updating one to one joins.
The first is this. In terms of our running example, I've considered two possibilities: Every
supplier has both a status and a city, or every supplier has at least one of those two properties.
But there are at least two further possibilities:
The properties are mutually exclusive (i.e., every supplier has exactly one of them).
One property is mandatory but the other is optional (e.g., every supplier has a city, and
some suppliers have a status as well).
A moment's reflection is sufficient to show that the first of these possibilities isn't very
interesting. The reason is that such a supplier would always be represented in either ST or SC
but not both; the join S would therefore always be empty, and deletes on that join would always
8
And here is as good a place as any to make the more general point that whatever view updating rules we do adopt, they certainly
can't rely on the database being well designed (e.g., they can't assume relvars are always properly normalized). In other words,
we must allow the database designer the freedom to make a mess of things.
Note:
That said, I feel bound to say too that much of
the complexity (such as it is) that arises with view updating in general arises precisely when the design we're dealing with is a
bad one—in particular, when it's incomplete, in the sense that it's incapable of capturing all of the facts about the real world that
it ought to be capable of capturing.
9
The idea that if you don't like what happens when you do
X,
then you shouldn't do
X
—“If it hurts when you hit yourself over
the head with a hammer, then don't hit yourself over the head with a hammer”—is sometimes referred to as
The Groucho
Principle
. My suggestion here (viz., if you don't like what happens when you do certain updates, then don't do those updates)
can be seen as an appeal to that principle. Now, I would certainly agree in general that if the only argument you can find in
support of some position is an appeal to
The Groucho Principle
, then that position must be pretty weak. But, of course, I don't
believe in the case at hand that an appeal to
The Groucho Principle
is the only argument I have to support my position.
