paul c wrote:
...
eg. show that 1) when A <AND> B is indeterminate, the equations can
always be rewritten as a union with the term A <XOR> B and 2) A <AND> B
is only indeterminate when A and B have equal headings and unequal
extensions.

I'm guessing this might be a more fruitful avenue than talking about
which relvars should change.

paul c wrote:
...
eg. show that 1) when A <AND> B is indeterminate, the equations can
always be rewritten as a union with the term A <XOR> B and 2) A <AND> B
is only indeterminate when A and B have equal headings and unequal
extensions.

I'm guessing this might be a more fruitful avenue than talking about
which relvars should change.

paul c wrote:
...
eg. show that 1) when A <AND> B is indeterminate, the equations can
always be rewritten as a union with the term A <XOR> B and 2) A <AND> B
is only indeterminate when A and B have equal headings and unequal
extensions.

I'm guessing this might be a more fruitful avenue than talking about
which relvars should change.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.

On Dec 19, 6:47*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I'm not sure what you mean by "extension". Wouldn't two relations x
and y such that their headings and content equals be the same
relation?

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.