# Re: On specialization constraints time of application

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.

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.

What are constraints? They are equations and inequalities in
relational algebra, or some propositions in relational calculus.
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.

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.

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".

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.
Received on Sat Jun 13 2009 - 19:26:58 CEST

Original text of this message