Re: A numerical methods viewpoint on OO/FP/Relational

"peter_douglass" <baisly_at_gis.net> wrote in message news:<3b478659_at_tobjects.newsource.com>...
> Mikito Harakiri wrote in message ...
> >In article <3b47185f_at_tobjects.newsource.com>, peter_douglass says...
 

> >>Might I ask if there is anything in constraint databases which violates
 the
> >>relational model?
> <snip>
> If, constraint databases generalize
> relational databases, there must be instances of constraint databases which
> violate some aspect of the relational model. I personally suspect that if
> such deviations from the relational model exist, that these deviations are
> not logically tied to the ability to impose arbitrary constraints on the
> database.

KaneLLakis&Co define generalized _tuples_ as conjunction of constraints. The most trivial example of such tuple demonstrates the difference:

x*x+y*y=1

can't be represented in classic Relational Model. Indeed, what do we do in relational, store cartesian points? There are _infinetely_ many of them. Store some shapes? How do we impose constraints on shapes?

The shorter (and more simplistic) answer to your question might be that relational calculus doesn't have negation (for query safety). Constraint databases don't have this restriction.

>
> >>If so, is this violation of the relational model
> >>necessary in order to impose arbitrary constraints on the database?
 

> >I thought I answered this one previously. Can Relational answer spatial
 queries?
> >OK, we'll introduce spatial domains, but then we'll have to introduce
 spatial
> >operators as well. Constraint databases don't need to program any special
> >operators. It can be viewed as a higher abstraction level.
>
>
> And does having this level of abstraction violate the relational model? I
> don't see how.
>
> >Assume that I have a system:
 

> >x*x+y > 5
> >y*y-3*x < 3
 

> >how would I store it in the relational?
>
> If your DBMS doesn't support such declarative constraints, you would need to
> use triggers. It would be best if DBMSs did support such declarative
> constraints, but that is another story.

There are 2 approaches for solving this system of equation: 1. Numerical
2. Analythical

#1 resemble Relational Approach: iterate through all the (x,y) tuples and find those that math predicate. #2 is how Constraint DB would approach this problem: we have only 2 tuples in the database, and ask if the tuple x+y*y<2, for example, is a valid fact as well.

It's easy to see that tere is a tradeoff between a class of structures taken as a semantics and the class of admissible queries.  

> > By limiting the base facts that can be
> >stored in the relational database, we limit also the class of problems that
 fit
> >into the model.
>
>
> True. I'm not sure what is the point, however.

When going into complex domains like spatial, Classic Relational Model is no longer the best answer. With complex user definable domains (objects) or without them.

> >It is not all that rosy in Constraints DBs as well. In the above example,
 am I
> >suggesting that Constraints DB has to be aware of Groebner Basis?
>
>
> You are suggesting that the DB knows how to test a pair of values x and y
> for consistancy with the system of inequations you have provided. Am I
> missing something?

It is not just testing simple relational tuples against the predicate. It is about solving predicates.  

> >>Leaving theory aside for a moment and looking at commercial products,
> >>ugliness aside, is it not true that with sufficient effort, one can
 program
> >>any arbitrary constraint on a database?
>
> Well, are there constraints that I couldn't implement (perhaps very
> inefficiently) with procedural triggers? I suppose there are, if they are
> not computable/decidable, but other than that? My point is that the
> relational model does not place restrictions per-se on what sorts of
> constraints may exist in a relational database, and that even commercial
> products place no such restrictions, although support for complex
> constraints may be quite poor.

Again, Constraints in Comnstraint DB are not constraits any more. They are tuples.  

> >>Similarly, ugliness aside, doesn't
> >>the Turing completeness of SQL (with recursive queries) imply that any
 query
> >>can be expressed in SQL?
 

> >You are welcome to write a query that returns all numbers from 1 to 1000. I
> >reserve my rights to change the upper boundary.
>
> Yes, but I don't see your point. I'm questioning whether it is appropriate
> to say that "relational databases" can't do x. Existing products might not
> support x very well, but if they allow x to be implemented at all, then I
> would say that x is compatible with the relational model. If so, then a
> database which supports x and otherwise doesn't violate the relational model
> should be called relational. If your constraint databases use the
> relational model of storing data in normalized tables etc. then the fact
> that they also support complex constraints doesn't make them non-relational.
> Rather, it makes them better relational products. That would be my point.

Once again, in Constraint DB we have completely different set of operations, it's no longer just project, restrict, join, etc. From your responce, I feel that you think of constraint databases as just Relational databases with some fancy constraints. Maybe the word "constraint" is somewaht misleading, as it halready has very well defined meaning in the Relational Model. Received on Tue Jul 10 2001 - 00:35:30 CEST