Re: a union is always a join!

"Walter Mitty" <wamitty_at_verizon.net> wrote in message news:Ydvsl.1741$gm6.1135_at_nwrddc02.gnilink.net...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:BEpsl.24370$ZP4.9956_at_nlpi067.nbdc.sbc.com...
>>> So, what does "whenever nothing is happening" mean in the context of the
>>> point you are making?
>>>
>>
>> A changing world can be described as a series of snapshots or as a series
>> of events. I prefer the latter because while the series of snapshots can
>> be derived from the series of events, the series of events cannot always
>> be derived from the series of snapshots.
>
> So what?

So what? I had mentioned change in the preceding paragraph, so I thought I should elaborate. Now let me elaborate further. Clearly the series of events that describes the changing world contains more information than the series of snapshots, and as a result, database update mechanisms based on it promise both greater economy and precision since only what is different need be stated and since exactly which set of differences that results in a successor snapshot is clearly stated in each transition. In addition, more granular transition constraints can be specified without resorting to the introduction of superfluous temporal attributes or identity fields. What has time to do with the requirement that a traffic light that is green can only either remain green or become yellow?

I think that what is missing from commercial DBMSs is the ability to declaratively specify constraints that limit the behavior of objects, and as a consequence, those constraints and their enforcement have migrated into application code. My goal is to describe a logical framework under which all constraints can be specified declaratively--including transition constraints. An implementation of such a framework would eliminate the need for many triggered procedures and even some stored procedures, at least when those procedures are used to maintain integrity. What follows is a rough sketch of what I have in mind.

A database is an assertion that states what things have been in the world and exactly how those things have been related to each other. A transition is an assertion that in the context of a database states what in the world is different and exactly how. Since both databases and transitions are just assertions, and since databases can be represented as collections of relations, it follows that transitions should also be able to be represented as collections of relations. So during a database update, for each relation schema in the database schema, there is one relation in the database and three in the proposed transition: one that enumerates the tuples for things that have been in the world but are no longer, one that enumerates the tuples for things that are still in the world but differ in appearance, and one that enumerates the tuples for things that have not been in the world but now are. (Every tuple in the database maps to something in the world because every tuple has a key value.) Since the resulting proposed relation can be calculated from the corresponding relation in the database and three relations in the proposed transition, it makes sense to materialize all of those relations for all relation schemata as potential operands of constraints defined using the relational calculus or something equivalent.

For example, if R{A, B, C} is a relation schema, then during a database update the following relations would be materialized along with those for every other relation schema for specifying declarative constraints

R{A, B, C}, the current relation
R-{A, B, C}, tuples about to be deleted
R%{A, B, C, A', B', C'}, tuples about to be updated

    A', B' and C' contain new components values for A, B and C respectively R+{A, B, C}, tuples about to be inserted R'{A, B, C}, the proposed relation

State constraints would involve only the primed relations. Transition constraints could be defined using just the primed and unadorned relations for those relations with key values that are permanent identifiers, or using the -, % and + relations together with the unadorned relations for those with key values that are not.

So what? Context is critical. In order to support declarative specification of transition constraints, it is necessary for the context of both the proposed database and the current database to be the same. From a series of snapshots it is not always possible to derive a series of events, and as a consequence, the context of each snapshot is different. This invalidates the result of a comparison of the proposed database to the current database. From the series of events, on the other hand, it is always possible to derive the series of snapshots, and since each snapshot is derived from its predecessor, the context of that derivation can be the context of both the proposed database and the current database during a database update. So in effect, supporting declarative specification of transition constraints is only always possible when the changing world is described as a series of events. Received on Sun Mar 08 2009 - 06:05:43 CET