Lately, I stumbled about the problem of how constraints are to be
implemented in the case of relations runtime-only (I call them virtual
- they can *roughly* be assimilated to functions/views)
representations. I thought that it is necessity for a TRDBMS to allow
the implementation of constraints over the domains of attributes that
are part of these relations. As a consequence, the question came out
about the modalities of constraint implementations in declarative
mindset:

I would to have the opinion of some people here and any material that
dealt with the specific subject at hand.

Thank you/

"Cimode" <cimode (AT) hotmail (DOT) com> wrote

I'm not sure exactly what you're driving at here. Are you concerned with
implementing constraints defined on relational expressions, such as a unique
constraint defined on a view?

Are you seeking a deterministic solution for mapping inserts, updates and
deletes that target a relation derived from a set of base relations to those
base relations? I don't think there is one.

I don't think so. Despite the good intentions of Date and Darwen, among
others, in advocating for the Principle of Interchangability, it still has
huge unresolved issues that relegate it to being just wishful thinking. For
example, how do you map an assignment to a relvar that is defined as a union
or a join to assignments to the base relvars in the union or the join?

I'm not sure what it is you're trying to say here. If you're saying that
the contstraints defined on the base relation schemata impact the set of
possible derived relations (values), then I would agree, since the predicate
of the virtual relation schema includes in its definition the predicates of
the base relations that appear in the definition of the virtual relation
schema.

On Jun 10, 6:07 am, Cimode <cim... (AT) hotmail (DOT) com> wrote:
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.

On 13 juin, 19:26, Tegiri Nenashi <TegiriNena... (AT) gmail (DOT) com> wrote:

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.

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.

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.



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.


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.

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.

"Cimode" <cimode (AT) hotmail (DOT) com> wrote

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

"Cimode" <cimode (AT) hotmail (DOT) com> wrote

Decomposition is only one way to deal with missing information, and all it
does is move the problem. Under the Closed World Interpretation, the
absence of a tuple in a relation does not indicate that information is
missing, but instead denies it. Decomposition as a mechanism for dealing
with missing information, therefore, is in my opinion incompatible with the
Closed World Interpretation. Darwen's is an inconsistent approach because
some relations represent what is true, and some represent what is known to
be true. Those that represent what is known to be true fall under the Open
World Interpretation. That's one problem.

Darwen's approach is directed at the elimination of nulls, but there are in
fact two basic sorts of nulls: nulls that indicate that there should be a
value, but it hasn't yet been supplied, and nulls that indicate that a
particular attribute is not applicable to what is represented by the tuple.
Darwen's approach is in accord with the Closed World Interpretation when it
is applied only to nulls of the 'inapplicable' sort. Decomposition is
therefore a good, and in my opinion, the correct mechanism for dealing with
inapplicable nulls. But of course, that leaves nulls of the 'applicable'
sort.

It is my opinion that nulls are not inherently flawed, but that it is the
misinterpretation, and the consequent misuse of nulls that are. If each
instance of null is /always/ an indication that information should have been
supplied, but hasn't--that is, if there is always only the one accepted
interpretation of the symbol, null, then each null can be replaced by an
expression of the form,

'Exactly one d such that d is an element of D'

where D is the domain of the constant that should have been supplied.

In this way, each tuple that can be in a 'relation'--even if it is
incomplete--maps to a formula in a first order language that can be assigned
a truth value under an interpretation. I'm quoting 'relation' here because
in a relation, every tuple has exactly the same number of components as the
schema has attributes, but if incomplete tuples are permitted, which is the
case when nulls are allowed, then some of the tuples can have fewer
components than the schema has attributes. It should be noted, however,
that an instance of the schema /is/ a relation just in case all values have
been supplied, which isn't true when inapplicable nulls are permitted.

This interpretation of null is in accord with the Closed World
Interpretation because each tuple that appears in a 'relation' represents
something that is true, not just what is known to be true. The distinction
is subtle, and some might call it nitpicking, but I think it bears directly
on how each tuple maps to something in the Universe. I think it is
counterintuitive for a tuple in a base relation to represent the fact that
something is not known, which is one of the consequences of Darwen's
approach.

On 14 juin, 02:44, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:
next one on my bookself.

"Brian Selzer" <brian (AT) selzer-software (DOT) com> wrote



Agreed.

Having said that, my preferred interpretation of NULL is different from
yours.

perfect solution. As far as I am concerned, the mecanism also
describes *applicable* that leaves the applicable type of null at the
level of intent by programmers. Since I only inspired myself from
Darwen mecanism and use subtyping as method for decomposing I would
not be able to say. I have created in the programming language a
tools and functions that allow the programmer to decide the type of
missing information that may be faced.


POCW, there is no need for such method since we are dealing primarily
with missing information. But I agree that the role of interpretation
by final user has been underestimated into applying POCW.

RM.

"Walter Mitty" <wamitty (AT) verizon (DOT) net> wrote

There are a number of interpretations. Raymond Reiter in "A Sound and
Sometimes Complete Query Evaluation Algorithm for Relational Databases with
Null Values," Journal of the ACM, April 1986, argues that nulls are
constants for which there is no unique name axiom. Codd, in his book, RMv2,
states that nulls are not values, but indicators and distinguishes between
inapplicable nulls and applicable nulls by using two separate null
indicators and 4VL. Others argue that there are many different kinds of
null, but what that boils down to is that that there are many different
reasons that a value either should have been supplied but hasn't, or is not
applicable, and that reason should somehow be encoded as the kind of null
value. The interpretation that I take issue with the most is the one that
uses the same symbol to indicate both that there can't be a value and that
there can be a value but it hasn't been supplied.