Re: Hierarchies in the relational model

From: Bob Badour <bbadour_at_golden.net>
Date: Mon, 20 Oct 2003 14:30:42 -0400
Message-ID: <-r-dnfUUj_OXtwmiU-KYjA_at_golden.net>


"Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message news:51d64140.0310200434.68c75a5f_at_posting.google.com...
> The relational model is based on first-order logic.
> Sometimes you want to be able to express propositions of second-order
> logic. For example, "transitive closure" can't be expressed in
> first-order logic.
>
> I know there are application-specific ways of encoding second-order
> concepts within first-order logic like the "nested set model" for
> hierarchies.
>
> You've also got things like "dynamic SQL" that some DBMSs support.
>
> But in our idealized DBMS we would like to be able to do this kind of
> thing in a more elegant way.
>
> Is the answer to add a "transitive closure" operator to the model?
> Would this cover all possible requirements for second-order logic?
> Or would be be forever adding new operators to cover new situations?
> Is there a finite set of operators that would cover all possibilities?
>
> In another thread it was mentioned writing applications in the
> relational model i.e. replacing procedural languages with a
> declarative one. But procedural languages can handle second-order
> logic. Things like the nested sets model require a procedural element
> to the language for things like updates.
>
> If we are speaking theoretically, how would our ideal DBMS deal with
> hierarchies in particular? Does a transitive closure operator cover
> all hierarchy-based problems? Are there some other examples of common
> problems that require second-order logic and can't be solved with a
> transitive closure operator?

Recursion. See recursion. Received on Mon Oct 20 2003 - 20:30:42 CEST

Original text of this message