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

Aloha Kakuikanu wrote:
> 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.

You are funny. I like it :}

You know that it is not my fault that you do not know the SQL of views.

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

If you do not like the SQL why you have used it for your presentation ?

>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

It is correct and it says that the view is not updatable. But C.J. Date does not agree, but you do not agree with C.J. Date, is it true ? You and C.J. Date have your private criteria of the view updatability.

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

It is a joke, no ?
Is it that you use the intuition to drive in a city that you do not know or you use a plan ? You use the intuition to know when the number is prime ?

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

It is another joke ? When the name of your computer is "math" your can transpose the matrix but it is not "practical solution", not of all.

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

I know that the computer has not the intuition. The computer must use rules. If you have the intuition you can probably describe it, no ? It's like with the numbers: one has the intuition of what 1,2,3,.. is and then one invents the axioms.

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

I am sorry but I do not understand the notation. What is 'V' ?

>
> 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, ...)
> ...
>
> then the view is updateable. One can witness that R1, R2, R3,... are
> indeed solutions of the original view equation by substitutition. The
> equation
>
> V = V(R1(V, C1, C2, ...), R2(V, C1, C2, ...), R3(V, C1, C2, ...), ...,
> C1, C2, ...)
>
> has reduce to identity. (Hence the term "inverse view").
>
> > > 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).

I can not say a lot because I do not understand the notation.

--
Tegi