Re: Basic question?What 's the key if there 's no FD(Functional Dependencies)?

From: Aloha Kakuikanu <aloha.kakuikanu_at_yahoo.com>
Date: 8 Nov 2006 19:59:14 -0800
Message-ID: <1163044753.938674.139230@i42g2000cwa.googlegroups.com>

NENASHI, Tegiri wrote:
> Aloha Kakuikanu wrote:
> > NENASHI, Tegiri wrote:
> > > Aloha Kakuikanu wrote:
> > > > OK. I have to do complete case-by-case analysis:
> > > > 1) A record is inserted into RMI. Nothing gets inserted into IMR and
> > > > into I.
> > >
> > > This is different of your preceding question. You have never said that
> > > you insert into RMI. Please you must learn how to pose questions
> > > correctly.
> >
> > It is not different. I have a view
> >
> > view AllPosters
> > select name, 'RMI' AS typ from (
> > select name from RealPeople
> > minus
> > select name from Impostors
> > )
> > union
> > select name, 'IMR' from (
> > select name from Impostors
> > minus
> > select name from RealPeople
> > )
> > union
> > select name, 'I' from (
> > select name from RealPeople
> > intersect
> > select name from Impostors
> > )
> >
> > with 2 columns "name" and "typ" which is equivalent to the system of
> > three views "RMI", "IMR" and "I". Whenever I insert into that view,
> > this action can be unambiguously interpreted as actions on those 3
> > views. E.g.:
> >
> > insert ('JanHidders', 'RMI') into AllPosters

>

> It is precisement that you did NOT specify in your question. It did
> not have the 'RMI" tag.

I didn't change the view, or did I? Admittedly, there was the second column alias missing, which is not a syntactic error when we write query, but is the error when declaring a view.

> One could have supposed that it was the insert into
> allposters('JanHidders') or something else.

There is no way to insert a record with one attribute into a view that has two. Admittedly, my typo triggered your misinterpretation.

> > > The insertion of record is possible only when the realpeople and
> > > impostors are disjoint. You have never said that they are. It was me
> > > who made the supposition. Please ask the question correctly.
> >
> > There is no such an assumption. You perform a sequence
> > insertions/deletions from "RMI", "IMR" and "I" in a single transaction,
> > and those actions can be easily interpreted on the base tables just
> > like in the insertion example above.

>

> Very well. Now you say that the tables are not disjoint. Let T1(x
> int) and T2(x int) be two tables. insert (x) into (T1 minus T2)
> values(10), into what table the new 10 goes ? Is it into T1 ? in T2
> in two alltogether ? Why ? The sketch model will allow the T1 update
> if the tables are disjoint. If the tables are not disjoint the view is
> not updatable.

Once again, there is not enough info in the view "T1 minus T2" alone to resolve update ambiguity. My view AllPeople, as you notice, is more sophisticated than that.

> C.J. Date has a strange rule that the insertion is permitted if PT1 and
> not PT2 where PT1 and PT2 are table predicates. Very well. Suppose T1
> = {1} and T2 = {2} because one inserted the values directly before.
> insert(2) into (T1 minus T2) is permitted by Date because
> PT2(duplication) is false. One cannot see the insert. The insert must
> be not be permitted.

I'm not proposing any set of rules for view updatability. And, AFAIK Date gave up on this too. I'm just exibiting a single example which is supposed to challenge your view update method.

> > Please note, that the actions should be consistent. For example, you
> > can not do
> >
> > insert ('JanHidders', 'RMI') into AllPosters;
> > insert ('JanHidders', 'IMR') into AllPosters;
> > commit;
> >
> > because no transaction on the base tables could produce such result on
> > the view.

>

> Why not ? What constraint does not permit the insert ? The insertion
> can be done into the tables directly, no ?

Please exibit a sequence of base tables updates which image is the two insertions

insert ('JanHidders', 'RMI') into AllPosters; insert ('JanHidders', 'IMR') into AllPosters;

in the AllPosters view. You can't.

Proof: "RMI" and "IMR" sets are mutually disjoint. You can't insert the same element ('JanHidders') into both.

> No we insert ('JanHidders', 'RMI') into allposters
> AND 'JanHidders'
> already is in the Impostors base table.

OK. Define 2 views

view RealPeopleV
select name from AllPosters
where typ='I' or typ='RMI'

view ImpostorsV
select name from AllPosters
where typ='I' or typ='IMR'

Then, insert a tuple ('JanHidders', 'RMI') into AllPosters and observe what happens on these two views. As you see, all you need to do is to figure out how an update on the base AllPosters view translates into RealPeopleV and ImpostorsV. This is view maintenace problem. I agree, thereto, whatever actions on RealPeopleV and ImpostorsV view maintenance algorithm prescribes (be it reject, or do nothing)

This is an inverse view system, BTW. To extend this example into some practical method one needs to figure out how to derive inverse view system by leveraging formal RA axioms. Received on Wed Nov 08 2006 - 21:59:14 CST