Re: A different definition of MINUS, Part 3
Date: Fri, 19 Dec 2008 10:29:57 -0800 (PST)
Message-ID: <ce22f4df-90d6-4233-b35b-59da514b6dab_at_p2g2000prn.googlegroups.com>
On Dec 19, 6:47 am, paul c <toledobythe..._at_oohay.ac> wrote:
> Would you like try to your hand on the case where A and B have equal
> headings and extensions to see if you get what I get?
x ^ R00 = y ^ R00 &
x ^ R11 = y ^ R11 ->
x = y
is a theorem in RL.
I can't establish join view update under any "reasonable" condition. Here is my reworked calculation
x - base relation
dx - its increment
y - base relation
dy - its increment
dz - increment of join view
x ^ R00 = dx ^ R00 & % x and dx have the same headers y ^ R00 = dy ^ R00 & % y and dy have the same headers x ^ R00 = y ^ R00 & % x and y have the same headers x ^ R00 = dz ^ R00 & % x and dz have the same headers (dz ^ (x ^ y)) v R00 = R00 & % dz disjoint with x ^ y(x v dx) ^ (x v dy) = (x ^ y) v dz % application of increments on the base relations
% is the same as increment on
join view
-> x v dx = x v dz.
QBQL output:
*** False Assertion ***
dx = {<x=1,>,<x=2,>,}
dy = {<x=1,>,}
dz = {}
y = {<x=1,>,}
x = {<x=1,>,}
Generally, I'm not sure if this focus on a single join view update
makes any sense. I understand D&D motivation behind it, but their
approach is different. They are trying to establish a set of (ad-hock)
view update rules for each and every basic RA operation. Then, view
update of any complex view would be just a composition of basic rules.
However, the futility of this idea is obvious from algebraic point of
view. Unconditional view updates of basic RA operations are impossible
(for example projection loses information). As soon as they started
making premises, they lost me because it doesn't look like their
method is anything more than case analysis that have any chances to be
scaled up to practical problems.
Speaking of practice, here is an example of nontrivial database schema
reorganization:
TABLE contact (
id NUMBER,
voice VARCHAR2(10),
fax VARCHAR2(10)
);
might require additional cellular column. Instead of growing the table, however, it is better to reorganize it like this:
CREATE TABLE newcontact (
id NUMBER, phonetype VARCHAR2(5), number VARCHAR2(10)
);
Each record in the old contact table
ID VOICE FAX
1 4150000000 4081111111 2 80012345672 6501234567
is equivalent to 2 records in the newcontact table
ID PHONETYPE NUMBER
1 VOICE 4150000000 1 FAX 4081111111 2 VOICE 8001234567 2 FAX 6501234567
The view is updatable, but I fail to see how this can be established within D&D framework. Received on Fri Dec 19 2008 - 19:29:57 CET