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)?
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?
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 Jthen 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.
> -- 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.
> > 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.
> 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 Val Tannen and Christoph Koch. XML algebras do have closure. Having or not having closure is not the problem here.
> 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.
> 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. :-)