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

From: NENASHI, Tegiri <>
Date: 7 Nov 2006 13:44:14 -0800
Message-ID: <>

Jan Hidders wrote:
> NENASHI, Tegiri wrote:
> > Jan Hidders wrote:
> > > NENASHI, Tegiri schreef:
> > >
> > > > Jan Hidders wrote:
> > > > > Do you know of any results that might be interesting for database
> > > > > theory and could not already be shown with good old set theory?
> > > >
> > > > The categorical sketches to use for universal view updatability:
> > > >
> > > > Michael Johnson and Robert Rosebrugh.
> > > > Universal view updatability
> > >
> > > That's not a result but a reformulation of the problem in new
> > > terminology.
> >
> > It is not a reformulation but to find the universal property of
> > updatability: let E be a sketch, V a view of the sketch, Mon(E) the
> > category of models of the sketch E whose arrows are monic. The
> > universal property of updatability is the functor F:Mon(V)==>Mon(E)
> > must be left and right fibration.


> 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. You can be also interested to know that there are some rudimentary systems that implement direct manipulation of the objects of categories. It is a pity that more resource is not given to them but that is life.

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


> > -- The union view is a coproduct in the category language. Generally,
> > the
> > -- coproduct is not updatable but if one injects an element that is not
> > in
> > -- the database like one of the legs of the coproduct, it will be
> > -- updatable. The universal property of updatability that the functor
> > -- F:Mon(V)==>Mon(E) must be left and right fibration is honored. The
> > -- proof is easy. Like I recollect the SQL union is never updatable.
> >
> > It is a new result, no ?

> No. It was already known that under some definitions of updatability it
> is updatable. The problem is not to come up with a notion of
> updatability that allows the most. The problem is to understand what
> the different proposals mean and whether they make sense, and
> understanding to what extent they allow the static and algorithmic
> analysis of allowable updates.

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. Like I said to Aloha, to convince does not interess me. To show that there are other tools, yes it does. Sure I can be wrong about the current utility of the tools of the category theory but comment ša s'dit ? time will tell...


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


> > The sketch model permits the closure that other models that are not
> > relational do not permit. The people in other nonrelational models are
> > very busy to climb in the XML trees and to lose their time in the XML
> > forest. It is sad that they do not have the time to study the category
> > theory. It is why they can not have the closure of algebra of XML.
> Some of them know category theory, Phil Wadler certainly does and so do

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.

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

>Having or

> not having closure is not the problem here.

It is very true. The XML is the real problem and the terrible language of XLST is a more large problem. One does not want even to start talking about the XML 'database' or 'datamodel'. One undrstand perfectly that it is where all the money is, that is lfe.

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


> > The sketch model permits to study the generic model management. You
> > can read works of Philip Bernstein and Zinovy Diskin. You can learn
> > that the relational algebra does not permit to study the generic model
> > management.

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


> -- Jan Hidders
Received on Tue Nov 07 2006 - 22:44:14 CET

Original text of this message