Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Basic question?What 's the key if there 's no FD(Functional Dependencies)?

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

From: Jan Hidders <>
Date: 7 Nov 2006 15:52:25 -0800
Message-ID: <>

NENASHI, Tegiri wrote:
> Jan Hidders wrote:
> >
> > It is already well known that there is not one correct notion of
> > updatability but several ones that can all be correct depending on what
> > you want to do with the view and expect from it. All the other proposal
> > have easy to understand justifications that explain when and why the
> > apply. Can you give such an explanation for this defintion without
> > using category theory?
> I probably can translate into the language of sets but it is not very
> interesting, it is like not using algebra but only concrete numbers.

I'm asking you to explain to me to what extent it actually solves the problem at hand. If you cannot do that in terms of the problem you do not really have a solution.

> > But apart from that, what does it add to the following?:
> >
> > Given
> > - a set of database instances I,
> > - a set of view instances J
> > - a view definition v : I -> J
> > - a set of view updates VU that is a subset of J x J
> > then we say that the view defined by v is updatable for the updates in
> > VU if there is a consistent propagation strategy for the updates, which
> > means that there is a function s : I x VU -> I such that
> > v(s(i,(j1,j2))) = j2 if v(i) = j1.
> I have doubts of the description of propagation but one can think it is
> OK. What you described, it is the sketch minus limits and colimits
> plus a very incovenient language. The limits and colimits are
> constraints. One can not talk of the database without constraints, eh
> ?

They are included, because they define the set I.

> Very well. But you must admit that the categorical language is more
> useful to talk about the update propagation and the universal property
> is a very nice thing.

No, you still haven't convinced me of that, and I currently have no grasp on what it intuitively means or corresponds to.

> > > > What does it learn us that we didn't know already from
> > > > work by for example Georg Gottlob or Stephen Hegner?
> > >
> > > I do not know the works. Did they use the sketch data model ?
> >
> > Not directly, but some of their work talks about data models in
> > general, so I expect it would also apply there.
> If they do not talk about the constraints, I doubt it is very useful.

I don't think they will be worried by your doubt. :-) But they do deal with certain constraints.

> I know the work of Wadler who was an inventor of the Haskell. It is
> very sad that the man of his talents is wasted with the abomination of
> the XML.

You are entitled to your opinion, of course. More knowledgeable people than you beg to differ.

> > Val Tannen and Christoph Koch. XML algebras do have closure.
> I did not know about the algebraic closure of the XML. Can you tell
> more ?

Yes, I can, but since you seem so hostile towards XML I'm not very motivated to do so.

> It is very true. The XML is the real problem and the terrible language
> of XLST is a more large problem.

It has its purposes.

> > > The sketch model has a very naturel and rich expression of constraints:
> > > the commutativity of diagrams, the finite limits and the coproducts.
> > > Did the people that you speek of develop the constraints ?
> >
> > Yes, view updatabality under constraints has been looked at.
> But the constraints, it is very important and you say like it is
> secondary.

It's not secondary, but you first have to solve the simpeler problem before you can move on to the bigger probem. Besides, for certain constraints , certain simple types of equality generating dependencies and tuple generating dependencies it is trival to see that you can generalize from the case without constraints. I wouldn't be suprised if that is exactly what the Sketch model deals with.

> > I doubt that. As far as I can tell the basic structure of the Sketch
> > model is similar to graph-based data models, which is of course a very
> > restricted (binary or ternary relations only) version of the relational
> > model. :-)
> that is not true at all. Is it that you are saying that the graph is a
> more poor structure that the relation ?

In some sense, yes, graphs are the relational model restricted to unary and binary relations. But things become interesting again if you start thinking about operations that do node creation (hello "object identity") but this has major consequences for theory about query languages, updates languages and views. Can you tell me if this is taken into account in the Sketch model?

Received on Tue Nov 07 2006 - 17:52:25 CST

Original text of this message