Re: a union is always a join!

"Tegiri Nenashi" <TegiriNenashi_at_gmail.com> wrote in message news:28078b81-9b60-412d-915c-cbac79fcaf4b_at_l16g2000yqo.googlegroups.com...
> On Mar 8, 3:45 pm, "Brian Selzer" <br..._at_selzer-software.com>
> > During a database update, assuming that streetCrossIds are permanent
> > identifiers, the relations,
> >
> > TrafficLights- {streetCrossId, state},
> > TrafficLights% {streetCrossId, state, streetCrossId', state'}, and
> > TrafficLights+ {streetCrossId, state}
> >
> > would be populated with tuples representing those traffic lights that
> > have
> > been removed from service, those traffic lights whose state is now
> > different, and those traffic lights that have been placed into service
> > respectively.
>
> This is not a good example of database update. Why do we care what
> state traffic light was during maintenance upgrade? I suspect they
> turn it out before actually unplugging the electrics and removing
> other mechanical artifacts. Moreover, the state is probably a
> calculated value, function of time and perhaps some other conditions.

If the state of a traffic light were always a function of time, then the constraint could possibly be written as a state constraint, but not all traffic lights follow a regular schedule. Some depend upon traffic conditions, others allow for manual intervention. (Those buttons you push to get the walk signal come to mind.)

What I thought was obvious apparently isn't: a traffic light that is being removed from service would have to be switched off and dismantled for parts or relegated to the trash heap; a traffic light that is being placed into service would have to be assembled, installed and switched on, and so would also have to have an intial state; a traffic light that is neither being removed from nor placed into service must have been and must still be in service, though its state may or may not have changed. So the transition constraint,

NOT EXISTS TrafficLights%
  (TrafficLights%.state = green AND TrafficLights%.state' = red)

would apply only to traffic lights that have been and still are in service.

> Any other realistic example of transition constraint?

The transition constraint,

NOT EXISTS TrafficLights+
  (TrafficLights+.state != red)

would require that whenever a traffic light is placed into service that its initial state be red.

> > I think you've misinterpreted my intent. I did not intend that state
> > constraints be rewritten as transition constraints. I intend instead
> > that
> > both state constraints and transition constraints can be specified
> > declaratively.
>
> Good luck with that. For transition constraints you'd have to summon
> automata theory? That is not one of the prettiest subjects of computer
> science...

I don't think we need to summon automata theory. A transition only ever involves two states: that which has obtained up to but not including the instant of change and that which obtains at that instant. How those states and the transition fits into an abstract state machine is incidental. For any implementation to support transition constraints, however, requires both a syntactic and semantic definition of what constitutes a state and what constitutes a transition.

A state is simply a database--a collection of relations that together represent and by extension assert just what things have been in the world and exactly how those things have been related to each other. A transition is also a collection of relations, specifically three relations for each relation in the database, that together represent and by extension assert what in the world is different and exactly how, or more specifically, that which has been in the world but no longer is, that which is still in the world but appears different, and that which hadn't been in the world but now is.

For example, if there are just relations P{A, B, C}, Q{A, D} and R{A, E} in the database, then a proposed transition will consist of the following relations

P-{A, B, C} -- tuples to be "deleted" from P
P%{A, B, C, A', B', C'} -- tuples in P to be "updated" with new components
P+{A, B, C} -- tuples to be "inserted" into p
Q-{A, D} -- tuples to be "deleted" from Q
Q%{A, D, A', D'} -- tuples in Q to be "updated" with new components
Q+{A, D} -- tuples to be "inserted" into Q
R-{A, E} -- tuples to be "deleted" from R
R%{A, E, A', E'} -- tuples in R to be "updated" with new components
R+{A, E} -- tuples to be "inserted" into R

One or more or even all of these relations may contain tuples during a database update. Just not none. The proposed relations are:

P'{A, B, C} =

    (P MINUS (P- UNION P%{A, B, C}))
    UNION (P%{A', B', C'} RENAME {A' AS A, B' AS B, C' AS C'})     UNION P+
Q'{A, D} =

    (Q MINUS (Q- UNION Q%{A, D}))
    UNION (Q%{A', D'} RENAME {A' AS A, D' AS D})     UNION Q+
R'{A, E} =

    (R MINUS (R- UNION R%{A, E}))
    UNION (R%{A', E'} RENAME {A' AS A, E' AS E})     UNION R+ During a database update, and only during a database update, the relations

P, P-, P%, P+, P', Q, Q-, Q%, Q+, Q', R, R-, R%, R+, R'

contain the current database (P, Q, R),
the transition (P-, P%, P+, Q-, Q%, Q+, R-, R%, R+), and the proposed database (P', Q', R').

Since constraints only need to be checked during a database update, they can reference any of the above relations because it is only during a database update that they are all populated with data. Received on Wed Mar 11 2009 - 05:35:18 CET