Re: a union is always a join!

From: <>
Date: Sat, 4 Apr 2009 04:40:03 -0700 (PDT)
Message-ID: <>

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 my model I can exactly determine which procedure or person created any peace of data in the database. 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.”

So ID of state is strictly related to real world. I can always determine a real state using its ID of the state. The identifier of a state is always created from the real world and in real world environment. I wrote in the paper that a change of a state is always caused by real world event. There are some additional things in the model, which also can determine a state which corresponds to its identifier.

In existing db models you can’t determine who created data and how data is created.

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 denotation. 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.
Currently I am busy with everyday duties so I will stop here with this discussion.

Vladimir Odrljin Received on Sat Apr 04 2009 - 13:40:03 CEST

Original text of this message