Re: On specialization constraints time of application

On 13 juin, 19:26, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
> On Jun 10, 6:07 am, Cimode <cim..._at_hotmail.com> wrote:
>
> > > Since a TRDBMS should allow constraint specialization in a declarative way...
>
> IMO, TRDBMS is not a good term. First, why relational model applied to
> database management field only? Somewhere on databasecolumn.com I
> remember reading that Dr.Codd's initial intention was general purpose
> programming language; narrowing the scope to DBMS allowed to avoid
> competition with traditional PL.
Agreed.

By TRDBMS, I meant a system that allows an inner logical representation that allows to operate soundly relations (thanks to a relation declarative operating language) and that truly implements independence between the physical and logical layers as defined according to RM. TRDBMS is here to be understood as a hypothetic objective for what a relational system (be it inside or outside the scope of databases) should do.

> Also I consider the other TRDBMS features such as elimination of NULLs
> and duplicates as trivial. If there only for these one could challenge
> TRDBMS added value, which brings us to the TRDBMS crux feature --
> declarative constraints.
I wish I had your confidence. Since decomposition is the only correct way to deal with missing information, I can tell you that buidling a non direct image system that automatically decomposes relations and implements Darwen approach to missing information is not what I would call a trivial task. It took me one year to get this one to work.

> What are constraints? They are equations and inequalities in
> relational algebra, or some propositions in relational calculus.
Both have advantages that unfortunately mutually exclusive. RA has stronger expressive power while RC allows better abstraction. I am trying to get the best of both by developping a language whose specifications I began to some monthes ago.

> Comparing the two, textbooks always point to the fact that RA has more
> procedural feel to it, compared to RC. Indeed, query has to specify RA
> operations is order, much like commands in traditional PL. This idea
> always bothered me, and only recently I found a satisfactory answer to
> it.
Yes. See above.

> A good illustration for declarative specification is an often cited
> SQRT example. Consider solving quadratic equation:
>
> x*x = 9
>
> Programmatic system where a user asks the system a question about the
> roots of x*x = 9 is declarative. Contrast this to procedural solution
> -- a function that returns a square root of number. It has to
> implement some algorithm, and algorithms are inherently procedural.
> Let's write what the function is doing as a formula
>
> x = SQRT(9)
>
> Now, compare both identities. The first one is constraint, the second
> one is query! So if a user is allowed to write a query as a
> constraint, that is using algebraic expressions with variables on both
> sides of equal sign, then we immediately have declarative query.
It is interesting to compare viewpoints but you are using an argument of traditional algebra to solve relational algebra.

To clarify...Since I assume that a relational system does operates only through relational algebra and I consider x as a relation x*x = 9 is not equivalent to x = sqrt(9) as it would dbe the case in traditional algebra. I consider "*" as a cartesian product between two unknown relations named x.

x in equation would be solved as x = 9
while x = 3 in the second equation.

> So suppose we allow relation variables in a query and elevate queries
> from being written as RA expressions (which are simple identities
> "x=queryExpr") to RA equations. This is already done in one case!
> Transitive closure written as Common Table Expression is an equation
> that has a variable on both sides of the identity. Can we benefit from
> writing some other (nonrecursive) queries as equations too? My
> proposed term for those "genuine declarative queries".
Once they get adequately represented as a set of constraints associated with a header set, nothing in fact precludes the assignment of relations to other relations in a system, since the assignement of the constraints and header becomes the assignment of the relation. If I write down R1 = (R2 * R3), I only assign the set of constraints of R2 * R3 at compile time to ato a specific header set called R1.

> Using algebra for constraint specialization and genuine declarative
> queries, however, has a major obstacle. One can accomplish very little
> if the algebra is (utilizing Marshall's term) misshapen.
Agreed. I am working on a different layer than RM. My effort is at building a computing system (and subsequent engine) while keeping some consistence with previous work. Much more of work remains to be done on that layer than on the layer of RM itself. Received on Sat Jun 13 2009 - 21:53:26 CEST