Re: On specialization constraints time of application

From: Tegiri Nenashi <TegiriNenashi_at_gmail.com>
Date: Sat, 13 Jun 2009 10:26:58 -0700 (PDT)
Message-ID: <3908d891-d678-4a3b-b192-e06eeb5450a3_at_s38g2000prg.googlegroups.com>


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