# Re: On specialization constraints time of application

Date: Sat, 13 Jun 2009 20:44:02 -0400

Message-ID: <jJXYl.31615$Ws1.10058_at_nlpi064.nbdc.sbc.com>

"Cimode" <cimode_at_hotmail.com> wrote in message
news:e8559d73-1998-4caf-8192-072a07cb9054_at_i28g2000prd.googlegroups.com...

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

The relational algebra and the calculus have equivalent expresive power, even when extended with aggregate functions. See

"Equivalence of Relational Algebra and Relational Calculus Query Languages Having Aggregate Functions", Anthony Klug, Journal of the ACM, July, 1982.

Incidentally, Date references this paper in the chapter on relational algebra in the eighth edition of /Introduction/.

*>
*

>> 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 Sun Jun 14 2009 - 02:44:02 CEST