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

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?
 

>I'm not sure if this is a valid question. Constraint databases generalise
 the
>relational ones. What things could be expresed in Constraint databases and
 which
>cannot in the Relational Model?

That is my question. The mathematical concept of an algebra generalizes the mathematical concept of a group. Thus, there are algebras which violate some of the properties of groups. 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.

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

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

>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?

>>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?
 

>I'm not sure I follow.

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.

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

--PeterD Received on Sun Jul 08 2001 - 04:49:35 CEST