Re: a union is always a join!

<vldm10_at_yahoo.com> wrote in message
news:e54cca8e-0a50-43a8-8f44-dd8bba13e33f_at_p11g2000yqe.googlegroups.com...
> On Apr 5, 2:06 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > "rpost" <rp..._at_pcwin518.campus.tue.nl> wrote in message
> >
> > news:gq8e2h$1ujr$1_at_mud.stack.nl...
> >
> >
> >
> > > Brian Selzer wrote:
> >
> > >>>> The mathematics of relational calculus and relational algebra are
> > >>>> fully
> > >>>> capable, AFAIK, of describing the difference between two states of
> > >>>> a
> > >>>> database.
> >
> > > [...]
> >
> > >>The algebra is capable of that if and only if each and every tuple has
> > >>a
> > >>key
> > >>that permanently identifies the thing in the universe of discourse
> > >>that
> > >>the
> > >>tuple maps to.
> >
> > > No, the algebra can describe the difference between database states
> > > without any assumption on how these states are interpreted.
> >
> > I don't agree. Even without any assumption on /how/ the states are
> > interpreted, there is still the bald fact that they are subject to
> > interpretation. If one state asserts that the employee operating welder
> > #4
> > is being paid at the overtime rate, and another state asserts that the
> > employee operating welder #4 is being paid at the standard rate, would
> > it be
> > valid to infer that 'the employee operating welder #4' denotes the same
> > employee at both states? I think not. Bottom line: the same term can
> > denote different things at different states, consequently, any
> > conclusion
> > drawn from an algebraic expression, such as R' JOIN R, which in essence
> > relies upon the identity of terms, would be faulty, since identity of
> > terms
> > at differnt states does not necessarily imply identity of the terms'
> > referents.
> >
> > > And as Walter Mitty already wrote, it is not in fact necessary that
> > > databases are inpeepreted in such a way that tuples are about "things"
> > > in the universe of discourse.
> >
> > > I think you are overstating your point, which was, if I understand
> > > you correctly, that while relational algebra and calculus may be used
> > > to express the contents of a database change, they do not express the
> > > fact that the contents change; and this does need to be expressed in
> > > some way when reasoning about database updates.
> >
> > >>But since that isn't a requirement of the RM, the RM must be
> > >>in trouble! If different keys at different states map to the same
> > >>thing
> > >>in
> > >>the universe of discourse, or if the same key at different states maps
> > >>to
> > >>different things in the universe of discourse, then how is it possible
> > >>to
> > >>describe exactly what is different between two states of a database.
> >
> > > It is really simple. However, you are right in that mutability of
> > > keys and other aspects of the relationship between database contents
> > > and its interpretation will fall outside the scope of that
> > > description.
> >
> > > --
> > > Reinier

>
>

You defined entities in terms of the "world" and the "real world." Now, you say that nobody knows what "world" is. Doesn't it follow then that your "state of entity" is in effect the state of the unknown? Does NULL even have state?

> Reinier for example doesn’t distinguish “state of affairs” from the
> state of entity. He wrote about my model the following: “The database
> records not only present state of affairs, but also all past state…” -
> meaning that db records something like “possible worlds” + all past
> states.

The db doesn't record possible worlds, though the database schema specifies what is possible.

> You intensively used terms “possible world” and “rigid designator” but
> you carefully made transformation and now you are using term the
> state. In the above message, you went further and you mentioned term -
> the state of “the employee”.

Actually, I didn't: I used the term "state" because "database state" is redundant, but, conceivably, there could be states of the employee.

> You seem to spending a lot of energy using basic terms and ideas from
> my db model.

I am not using terms or ideas from your "model." Your "definitions" lack clarity and defy convention. For example, a "state" of a thing is exactly what that thing is at a particular location in time; it is not knowledge of a thing.

> But you proclaim superiority of the relational model and it is unclear
> to me why you don’t use basic terms from relational model or maybe
> from a combination of “temporal” data and relational model?
>
> Vladimir Odrljin

I see the Relational Model as an analog of a first order language. The database schema is analogous to sentences in that language that together shape the universe of discourse into a set of possible worlds over a fixed domain. Each database is analogous to an expression of a possible world, and /the/ database is analogous to the expression of the distinguished actual world. Due to the Unique Name, Closed World and Domain Closure Assumptions, that expression is a complete representation of what exists in the universe of discourse. The Unique Name Assumption effectively eliminates NULLs from consideration, the Closed World Assumption effectively limits the set of truth values to just True and False, and the Domain Closure Assumption effectively limits what exists to just what is represented in the database.

The universe of discourse is everything of interest to the participants of a discussion. That includes everything of interest that has ever been, everything of interest that always is, everything of interest that could have ever been and everything of interest that can ever be. For something to have been requires first that it could have been, for something to be requires first that it can be, and although nothing existed before the first transition, what was then is and always will be. The possibility of being is necessary, and as a consequence the universe neither expands nor contracts, otherwise the participants would not be able to discuss what might occur in the future or what occurred in the past; therefore, things in the universe are neither created nor destroyed: instead, they are actualized--they cease to be mere possibilities and become concrete, anchored to locations in time. For things that are momentary, those locations are definite, since both their beginning and end are identical and fixed, but for things that persist, those locations start out being indefinite intervals, since initially just their beginnings are fixed, and only later on become definite whenever their ends actually arrive.

To have existed is to have become actual; to exist is to still actually be. Thus everything of interest that has ever existed occupies an interval in time, definite for what no longer exists, indefinite for what exists now. Something comes into existence at the beginning of an interval, and ceases to exist at the end of the interval, but change is not limited to changes in existence. Changes in something that occur within the interval during which it persists do not amount to changes in existence, but only in appearance. Changes in appearance segment the interval during which something persists into a series of subintervals during which neither changes in its appearance nor changes in its existence occur. The appearance of something during such a subinterval is a "state" of that thing. An insert asserts that something has come into existence; a delete asserts that something has ceased to exist; an update asserts that something has changed in appearance and now has a different state. When the database is ordinary (not historical), the domain of quantification includes everything of interest that could have ever been and everything of interest that can ever be; when the database is historical, the domain of quantification is further qualified to include every state of everything of interest that could have ever been and every state of everything of interest that can ever be. It is easy to see that when something comes into existence, its first state comes into existence, that when something changes in appearance, the end of its previous state becomes fixed while at the same time its next state comes into existence, and that when something ceases to exist, the end of its final state becomes fixed; therefore, insert for an ordinary database is analogous to just an insert for a historical database, update for an ordinary database is analogous to an interval update and an insert for a historical database, and delete for an ordinary database is analogous to just an interval update for a historical database.

A historical database is a relational database but with some additional requirements: first, each relation schema must have an interval attribute; second, transition constraints must be specified that ordinarily disallow deletes, that ordinarily only permit updates to indefinite intervals, and that ordinarily either allow inserts of tuples with definite intervals but disallow inserts of tuples with indefinite intervals or allow inserts of tuples with definite intervals but disallow inserts of tuples with indefinite intervals. (Ordinarily, because it may become necessary to issue corrections.)

Thus the Relational Model is sufficient for both ordinary databases and historical databases, provided it has is a mechanism for declaring transition constraints. There is no need for a "new db model." Received on Thu Apr 09 2009 - 15:28:49 CEST