Re: a union is always a join!

"Tegiri Nenashi" <TegiriNenashi_at_gmail.com> wrote in message news:ab49ab5f-a8e6-4b2a-a1ca-c85013828fdc_at_a12g2000yqm.googlegroups.com...
> On Mar 7, 9:05 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > 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
> > n eed
> > 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?
>
> A simple Traffic Lights database design
>
> table TrafficLights (
> streetCrossId integer,
> state {red,yellow,green}
> )
>
> has no concept of light switching ordering. However, as soon as we
> have time added it becomes temporal database, and everything becomes
> more complicated, including queries! Yet, the constraint is
> expressible (although as quite unwieldy SQL assertion).
>

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.

Wouldn't it be simpler to write something like

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

This expression would return false if the state of any traffic light is switching from green to red.

> > 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.
>
> Perhaps there are other reasons why constraint enforcement migrated
> into application code? Such as application programmers' ignorance of
> database fundamentals, client-server latency, and, most important,
> weak support from RDBMS vendors?
>

I don't deny those other reasons, but I don't think they're the whole story.

> > My goal is to describe a logical framework under which
> > all constraints can be specified declaratively--including transition
> > constraints.
>
> Transition constraints are more complicated than state constraints.
> Think of simple inequality x < 10. How many transition constraints
> would it take to represent it? Assuming domain of integers we would
> allow transitions 1->2, 1->3, 1->4, 2->3, ... and reject 1->11, 3-
> >12, ... How would you express functional dependency as a transition
> constraint, without explicitly enumerating all legitimate state
> transitions?
>

In the framework I sketched, state constraints such as functional dependencies would be defined using just the primed relations--that is, the proposed relations. This does not differ significantly from how state constraints are specified now. I did not intend to reinvent the wheel, just augment what is already there to also allow the specification of declarative transition constraints.

> I'd suggest that state constraints are much more common than
> transition constraints, therefore having transition constraints as a
> foundation seems to be a wrong idea. It requires quite a lot of effort
> and sophistication to develop something workable along this ideas --
> we are looking into fields that study dynamics, in general, and
> differential equations, in particular.

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.

> Your criticism of algebraic foundation for constraint system might get
> some ground if you focus on (un)expressiveness and (im)maturity of
> underlying algebraic system...

The algebra is perfectly suited for what it was intended to do. I don't object to its use as a foundation for a constraint system. In fact, since it is equivalent to relational calculus, it could in fact be an integral component. What I object to is trying to cast it as an update mechanism, which is clearly beyond not just its intended purpose, but also its capabilities. Received on Mon Mar 09 2009 - 00:45:00 CET