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

NENASHI, Tegiri wrote:
> > > 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

Ah, monkey feces throwing! That's entertaining.

> because this:--
> |
> V
> create table t1(x)
>
> insert into (select x, 7 typ from t1)(x) values(3)

Let's not argue about a particular SQL syntax, because it's not worth it. All I was trying to say is that when you insert a tuple into AllPosters you have to be unambiguous about the "typ" attribute.

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

Because, I can't solve the equation

V = T1/T2

in terms of T1 and T2. Pretty much like in ordinary algebra one can't solve

5 = x - y

In ordinary algebra the idea may be as naive as noticing that there are more variables than equations. In RA finding such a criteria is more challenging.

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

There is pretty clear intuition what view is updateable and what is not. For example, the view that pivots a table is updateable. In practice, you find pivoted views in virtually all the distributed databases. Say one database represents the customer as

Name Phone Typ

-------   -------   ------
Joe     650-    work
Joe     651-    mobile

while the other

Name WorkPhone CellPhone

-------   -------         -----
Joe     650-        651-

The problem there is usually table synchronization. It can be reduced view update!

Clearly, any practical solution should be able to accomodate simple idea that pivot view is updateable.

Do you see similarity between the pivot and my example, or would like more clarification?

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

Speaking of my method, it is easier to prove that a view is updateable than not. Given the view equation

V = V( R1, R2, R3, ..., C1, C2, ...)

where R1, R2, R3, ... are relation variables and C1, C2, ... are relation constants, if I can solve it in terms of R1, R2, R3

R1 = R1(V, C1, C2, ...)
R2 = R2(V, C1, C2, ...)
R3 = R3(V, C1, C2, ...)

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

If you insist. A view is updateable if one can exibit a set of inverse views. The updateability algorithm is standard view maintenance problem (which is much easier than view updateability problem). Received on Thu Nov 09 2006 - 19:11:29 CET