Re: relationship in the database

In article <3D9337C3.70702_at_hotmail.com>, Costin Cozianu <c_cozianu_at_hotmail.com> wrote:
>Jan.Hidders wrote:
>> In article <3D92457D.1030608_at_hotmail.com>,
>> Costin Cozianu <c_cozianu_at_hotmail.com> wrote:
>>>Jan.Hidders wrote:
>>>
>>>>In article <61c84197.0209250311.5660da8c_at_posting.google.com>,
>>>>Peter Koch Larsen <pkl_at_mailme.dk> wrote:
>>>>
>>>>No, the consequence is that some assignments are recognized as a single
>>>>tuple update.
>>>
>>>This is an unwanted and unwarranted limitations.
>>
>> 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.

>>>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'd say that we can define an operator over relvars
>>> UPDATE (relvar, transformation)
>>>where relvar has to be the name of a relvar (later we can think of
>>>views, maybe), and /transformation/ should be a function
>>>TUPLETYPE_OF(relvar) -> TUPLETYPE_OF(relvar).
>>>I ommitted the WHERE clause because it can eb easily expressed by
>>>letting the transformation be the identity when restricted to tuples
>>>that don't match.
>>>
>>>Now the semantics is clear (kind of), but I try, we have to cases:
>>>
>>> - transformation is injective with regards to the keys (all the
>>>candidate keys) -- formally that means the projection of tuple over the
>>>candidate key composed with the transformation is injective.
>>
>> A transformation is injective if two different relations are always
>> mapped to different relations. I don't think that's what you mean here.
>> I'm guessing you mean that every result of the transformation satsfies
>> the key constraints. That's an undecidable property, by the way, so I
>> don't think you would want to depend on that.
>
>I meant the transformation function takes a tuple and returns a tuple.

Yes, sorry for that, you wrote that already quite clearly.

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

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

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

• Jan Hidders