Re: relationship in the database

> >> What limitations? There are no limitations.
> >
> >You force the the user (application) to use only one tuple at a time
> >updates (ahem relational assignments).
>
> No, I don't. All that happens is that in those cases the trigger fires,
and
> otherwise it doesn't.

ANd if the trigger doesn't fire the update doesn't succeed, which is kind of limiting don;t you think ?

> >>>What's so fishy about UPDATE after all.
> >> It assumes a hidden notion of object identity.
> >
> >No, it doesn't. It only assumes there's a well defined relation
(functional
> >relation is desirable) between the new tuples and the old tuples.
>
> Yes, and what is this relation? It is the relation that tells you when the
> tuples represents the same entity. That means that you apparently have a
> notion of entity identity that is distinct from the keys you specified. So
> you have a hidden notion of entity identity. Why not make it explicit
then?

I don't enforce such an identity in the database, but I can let the user (programmer) specify the correspondence between the old and the new tuples. I don't see why this correspondence should be specifically regarded as reflecting entity identity. It's up to the user to decide what are the semantics (of the UPDATE .. CASCADE), and if they fit the business rules, possibly it's worth taking into consideration making the CASCADE clause part of the UPDATE rather than part of the constraint declaration.

Please note that the tuples may not necessarily be about entities. The update and CASCADE on foreign keys may also apply to "relationship" tuples, loosely speaking, meaning tuples that reflect what in conceptual model would be qualified as "relationship" .

Why not make it explicit then ? Because it's not necessarily needed. However, if the user needs it he may choose to declare it explicitly, and possibly be automatically implemented (managed) by the database.

> >If it is an injective function from tuples to tuples, then the effects
> >of the UPDATE operator in the presence of candidate keys and foreign
> >keys are well defined, and semantically useful and desirable to be
> >supported by the DBMS as shown in the example I posted.
>
> I assume you mean "injective for the given relation" because almost no
> simple update is actually an injective transformation in the general sense
> of the word.

Yes, indeed. The system shouldn't care if it's injective over the largest domain it can be defined on.

> But how is this different from an UPDATE statement? It looks to me as the
> same thing wrapped in another syntax.

I didn't claim it was essentially different, I put it in the form that would more easily reflect the semantics of the operation, and that this particular semantics can be adequate to handle common practical needs.

Paul Vernon (and you seemed to agree) claimed that the CASCADE effects are not well defined. For the UPDATE statement they can be very well defined, and this what I was trying to prove.

> >If you have a paper published somewhere on the web, or have a better
> >reference on these diachronic keys, I'd be happy to read about them.
>
> There is not that much to understand. A diachronic key is a minimal key
that
> tells you when two entities are actually one and the same entity. Note
that
> in an ER model a key is a set of attributes and relationships. Also note
how
> similar it is to the the definition of candidate key. However a candidate
> key only tells you when two entities are the same *at a certain moment*.

So then how is it different than an OID ?

I'd say it's only different if it has business meaning (i.e. it is a natural key that in addition has the property that it can't be updated), but such keys may not exist for all relations (or entities) for that matter.

> -- Jan Hidders
>

Best regards,
Costin Cozianu Received on Mon Sep 30 2002 - 04:26:05 CEST