Re: a union is always a join!

From: rpost <>
Date: Tue, 7 Apr 2009 18:43:49 +0000 (UTC)
Message-ID: <grg6t5$29jn$>


>On Apr 1, 11:31 pm, (rpost) wrote:
>> If I understand it correctly,
>I am afraid that you didn't understand it.
>Let me shortly explain just one thing among of all others you didn't
>understand here. It is about the identifier of a state.

In case you didn't notice: most regulars in this newsgroup are "relational purists" who abhor identifiers.

>In my model I
>can exactly determine which procedure or person created any peace of
>data in the database.

But you don't need to introduce identifiers in order to do that. I do see what identifiers are good for, namely, the identification of entities across different states. But relational purists say that such identification is "magic": if you can point out which entity has changed, there must be some property or properties in the real world by which you made that identification, and those properties must be key attributes in your database model, so we should express the change in terms of changes to key attribute values and the identifier is superfluous. Makes sense, doesn't it.

>For example, I can ask this person: why you
>changed four times this line in the m-n relationship on 31 January
>2008. I want to see corresponding real world documentation for every
>ID of the states for this line i.e. the documentation for every of the
>four states. He can answer to me, for example: On 31 January 2008,
>the line was broken two times this is documentation. Third time they
>send me wrong report. Fourth time I made mistake.

Yes, but you don't need IDs don't help you do that, and what is more, they don't help you do it, either; unless the person walks around with the ID in real life (in which case it isn't an ID but just a regular key attribute).

>So ID of state is strictly related to real world. I can always
>determine a real state using its ID of the state.

Yes, but you can't determine the ID of a state given the state, which you need to do if you want to express changes, unless your state info has a unique key, in which case it can replace the ID.

>In the paper many things are new, for example I defined states,
>concepts, relationship between entity and its states. Semantic is also
>new - it is related to identifying and matching rather then only to

I don't know what you mean to say by that. Relational databases are all about identifying entities based by matching on attribute values, but that doesn't mean you have to introduce identifiers.

>Meaning of entity is defined as totality of its states. I
>have access on the level of attributes. Expressed in terms of
>relational theory I have binary relations for complex structures
>(states). The access on the level of attributes enable me to apply
>logic, constrains and powerful algorithms on the level of attributes.
>Therefore it is new model.

But it can be phrased in terms of relational databases, and it is very beneficial to do so.

>Currently I am busy with everyday duties so I will stop here with this

OK .... me too ...

>Vladimir Odrljin

Received on Tue Apr 07 2009 - 20:43:49 CEST

Original text of this message