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

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

>

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.

>

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.

>

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 Thu Nov 09 2006 - 04:59:14 CET