Re: a union is always a join!
Date: Sat, 4 Apr 2009 04:40:03 -0700 (PDT)
Message-ID: <9d65ce23-fa96-4925-bde0-61d6cb78eb9d_at_z9g2000yqi.googlegroups.com>
On Apr 1, 11:31 pm, rp..._at_pcwin518.campus.tue.nl (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