Re: more on delete from join
- From: "Mr. Scott" <do_not_reply@xxxxxxxxx>
- Date: Tue, 1 Sep 2009 09:40:20 -0400
"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:t6Amm.41661$Db2.31934@xxxxxxxxxxx
Mr. Scott wrote:
...
The system having to guess what the user intended is a direct consequence
of view updates being nondeterministic. For example, an insert into a
union view involving two tables is not deterministic because there are
three different combinations of values that could result in the same
value for the view. The system has to guess whether the row must be
inserted into one table or the other or both. The same can be said of a
delete from a join view.
This the standard absolutist, self-serving complaint. Of course if you
set up a system that defines certain view updates as being
nondeterministic, certain view updates will be nondeterministic, but that
is not a consequence of relational theory. I don't care whether the
motive comes from wilfulness or a wish to have simplistic implementations
or just confusion about the significance of atttribute names, instead I'll
take a stab at discarding the non-essential stuff and stick to what I hope
involves only predicates and a strict (TTM) algebra.
i) Suppose we have a relation S with predicate "s is a supplier" and
value:
S:
s
Bill
and a relation C with predicate "c is a customer" and value:
C:
c
Bill
Bob
So Bill is a supplier, Bill is a customer and Bob is a customer.
ii) Supposing we wish to distinguish customers who are also suppliers and
suppliers who are also customers, mere join (conventional) doesn't quite
produce a relation that can be queried without qualification, ie
S JOIN C:
s c
Bill Bill
Bill Bob
This has the predicate "s is a supplier and c is a customer". In
practice, it is more likely that 's' and 'c' would not be distinct
attribute names, still this join does allow us to conclude that Bill is
both a supplier and a customer, if the application language includes an
"equals" operator and users remember to use it. .
iii) If we want the recording form itself to reflect the predicate we
want without depending on implementation language, eg., a slightly
different predicate, say "s is a supplier and c is a customer and s and c
have the same name", we need a join definition that makes the equality
explicit, by restricting the join to tuples where s = c, eg.,
:
R1 = ((S <RENAME> (s, c) ) <AND> C) <AND> S with value:
s c
Bill Bill
In fact, S JOIN C, aka S <AND> C isn't quite what we want, rather what we
want is equivalent to: S <AND> C <AND> R1.
R1's predicate could also be written as "s is a customer and s is a
supplier and c is a customer and c is a supplier" which might seem a
little "redundant" because it amounts to saying the same thing twice.
iv) We could say the same thing as R1 with two relations R2 and R3:
R2 = ((S <RENAME> (s, c) ) <AND> C) with value:
c
Bill
R2 has the predicate "c is a customer and c is a supplier".
and with R3 = R2 <RENAME> (c,s) with value:
s
Bill
R3 has the predicate "s is a customer and s is a supplier".
v) Note that R2 = R1{c} and R3 = R2{s} and R1 = R2 JOIN R3 = R2 <AND> R3.
vi ) Suppose we wish to retract the fact that "Bill is a customer and Bill
is a supplier, ie.::
<NOT> R1 =
<NOT> (R2 <AND> R3) =
<NOT> R2 <OR> <NOT> R3
As many people point out, the 'disjoin' has three possible values. But if
we assert one of them, say, that <NOT> R2 is true and <NOT> R3 is false,
we are left with the truth of R3, ie., "Bill is a customer and Bill is a
supplier", which contradicts what we intended. We can avoid that
contradiction by asserting (<NOT> R2) <AND> (<NOT> R3).
An appeal to logic. Affirming the disjunction of two ground atoms,
Pabc OR Qabc
implies that either Pabc is true or Qabc is true or both are true.
Similarly, denying the conjunction of two ground atoms,
NOT (Pabc AND Rabd),
is equivalent to affirming the disjunction
NOT Pabc OR NOT Rabd
which implies that either Pabc is false or Qabd is false or both are false.
Either case involves affirming a disjunction, not a conjunction.
Now let's apply this logic to relational theory. Let there be tables with
predicates P, Q and R, a view that is the union of the table with predicate
P and the table with predicate Q, and a view that is the join of the table
with predicate P and the table with predicate R. Inserting a row (a,b,c)
into the union view affirms the disjunction Pabc OR Qabc; deleting a row
(a,b,c,d) from the join view affirms the disjunction NOT Pabc OR NOT Rabd.
Both inserts into the union view and deletes from the join view affirm
disjunctions, and as a consequence, neither inserts into the union view nor
deletes from the join view have unique results.
I can see the benefit of recording disjunctive information. If it is known
that A OR B is true, then it should be possible to assert A OR B, even if it
is not known which is true. I just don't think that an insert into a union
view is the correct way to do it. A better way would be to use three
tables, one for facts like 'It is known that A.' one for facts like 'It is
known that B.' and one for facts like 'It is known that A OR B, but not
which.'
<snip>
.
- Follow-Ups:
- Re: more on delete from join
- From: paul c
- Re: more on delete from join
- From: Kevin Kirkpatrick
- Re: more on delete from join
- Prev by Date: Re: more on delete from join
- Next by Date: Re: more on delete from join
- Previous by thread: Re: more on delete from join
- Next by thread: Re: more on delete from join
- Index(es):
Relevant Pages
|
Loading
