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

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.

One could have supposed that it was the insert into allposters('JanHidders') or something else. One can not read your brain.

>
> is translated into
>
> insert ('JanHidders') into RMI
> -- no action on IMR
> -- no action on I
>
> This in turn is unambiguously translated into into an action on base
> tables
>
> insert ('JanHidders') into RealPeople
> -- no action on Imposters
>
> Kind of obvious, isn't it?

No it is not because you did not say in full specification what you insert.

>
> > 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.

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.

>
> 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 ?

>
> > > > "Suppose we insert 'JanHidders' into the RealPeople" and suppose
> > > > 'JanHidders' is an impostor and exists in 'i'.
>
> In other words, we have a tuple
>
> ('JanHidders', 'I')
>
> in the AllPeople view already, and we do
>
> insert ('JanHidders', 'IMR') into AllPosters;

No we insert ('JanHidders', 'RMI') into allposters AND 'JanHidders' already is in the Impostors base table. Then the two sets: |
V

Impostors minus RealPeople
and
Impostors intersect RealPeople

... will not "remain the same".

>
> ?
>
> Clearly, if we have have a tuple ('JanHidders', 'I') in the view, then
> there is a tuple ('JanHidders') in RealPeople base table and a
> duplicate tuple in Impostors.

There is no duplication.

> Now tell me what transaction are you
> trying to commit in terms of the base tables. Because, I have no way to
> interpret it as a consistent action. Maybe you do empty transaction?

There is no duplication. What is the empty transaction ?

>
> > >
> > > What you might want to do is to consider additional cases:
> > >
> > > 5. Delete record from RMI and insert it into I.
> > >
> >
> > The view is not delete updatable. How do you decide from what table to
> > delete ? One can not decide.
>
> Same as in insert case. Remember, in my view each name is labeled with
> a "typ". Therefore, for every atomic insert/delete I know what
> partition of Venn diagramm should be affected. If I delete from the "I"
> for example, then the record is deleted from both RealPeople and
> Impostors (pun intended).

Your Venn is not useful. To speak reasonably please give your rules for the union, minus and intersect operations. So long as we do not have the rules it is a game of words:

union: insert is permitted. Why ?
union: delete. The same
...
et cetera.

>
> > This remark can be correct but the transactions are not connected to
> > your questions. Do you want to talk about transacions ? We can talk
> > about them, also.
>
> By transaction I have a sequence of deletes/inserts, nothing more.

If so the transaction is not a useful word: there is no concurrency. They are not relevant of the view updatability.

--
Tegi