On Apr 5, 2:06*am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

I would like to make the following note.
In my model (see www.dbdesign11.com) I didn’t use terms as “possible
worlds”, “state of affairs” or “temporal”. Especially I didn’t use the
mentioned terms as basic. They are undefined terms. For example,
nobody knows what “world” is. However I precisely defined the state of
entity and state of relationship which are some of my basic terms.
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.
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”.
You seem to spending a lot of energy using basic terms and ideas from
my db model.
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

Vladimir Odrljin writes:

No, just the present state and all past states. I don't understand
why you split a state of affairs out into states of individual
entities and relationships. Those states must at all times form
a consistent whole, and that whole is what I called the state of affairs.
For databases that only hold information about the present,
a state of affairs simply corresponds to the database contents.
But this is really just a manner of speaking, the relationship
between your model and relational databases can be described in terms
of transformations that don't depend in any way on how the data
in databases are interpreted.

[...]

I can't answer this, but the converse is unclear to me,
namely, why you don't just formulate your ideas in terms of
working with ordinary relational databases.

--
Reinier Post

wrote:

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

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.

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

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.

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.

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

OK .... me too ...

--
Reinier

I just wrote

Not much. I meant to say changes to other attributes.

--
Reinier

<vldm10 (AT) yahoo (DOT) com> wrote

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?

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

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

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.

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