Re: Basic question?What 's the key if there 's no FD(Functional Dependencies)?
Date: 9 Nov 2006 06:14:20 -0800
Message-ID: <1163081660.266114.220700_at_e3g2000cwe.googlegroups.com>
Aloha Kakuikanu wrote:
> 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.
You are not correct, you must learn some SQL not only the Venn
diagrammes because this:--
insert into (select x, 7 typ from t1)(x) values(3)
|
V
create table t1(x)
It works
> Admittedly, my typo triggered your misinterpretation.
>> > if the tables are disjoint. If the tables are not disjoint the view is
> > > > 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
> > 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.
But you used criteria to decide why your view is updatable, no ? What are your criteria ?
>> > PT2(duplication) is false. One cannot see the insert. The insert must
> > 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
> > be not be permitted.
>
> I'm not proposing any set of rules for view updatability.
If you do not have means to decide, then all the views are not updatable !. If you say that "means" are not "rules", then you do not have the honest answer and play with words. .
>And, AFAIK
> Date gave up on this too. I'm just exibiting a single example which is
> supposed to challenge your view update method.
>
Very well. How you decide if you do not have rules -- "I'm not proposing any set of rules for view updatability." -- ?
> > > 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.
I do not understand "which image is" but suppose that you mean that one cannot insert the same name into Impostors and RealPeople with view. I can not respond this because I do not know now what your rules rules of updatability are.
>
> Proof: "RMI" and "IMR" sets are mutually disjoint. You can't insert the
> same element ('JanHidders') into both.
This is no proof: you have not gave the rules of derivation. Also I have talked about the direct insertion into the base tables, not into the view.
>> > AND 'JanHidders'
> > No we insert ('JanHidders', 'RMI') into allposters
> > already is in the Impostors base table.
>
> OK. Define 2 views
It is not "OK" so long as one does not have your rules of updatability. You put a pile of symbols on the pile of symbols: it does not have sense without the rules. Please provide the rules, simple examples and then one can go to more complex examples.
-- Tegi >Received on Thu Nov 09 2006 - 15:14:20 CET
> 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.