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

Mikito Harakiri wrote in message ...

[snip]

>KaneLLakis&Co define generalized _tuples_ as conjunction of
>constraints.

Thanks for the pointer. I read a few of their papers and now have a much better understanding of what you mean. Sorry to have been so dense.

The most trivial example of such tuple demonstrates the
>difference:
 

>x*x+y*y=1
 

>can't be represented in classic Relational Model.

Well, that region of space (circle) can't be represented in the Relational Model the same way that it is represented in a Constraint Database. However the Relational Model allows the storage of arbitrary objects or values, including an object that would represent x*x+y*y=1.

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

For example, how would store a constraint that all shapes in a column are circles? Or something else? If the former, you would need something like Date's tutorial D (not a commercial product :-( .

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

The predicates corresponding to a table may have negation, and so may constraints on the table. As far as queries go, I use a version control system daily which is built ontop of an SQL layer, and I can search for files etc. which are _not_ owned by me, if I don't mind waiting a few hours.

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

Yes. Represent each region as a function that takes a point as an argument and returns, say -1 if the point is outside the region, 0 if it is on the boundry of the region, and 1 if it is inside the region (but not on the boundry). Select those rows where applying this function to a point returns 1 or whatever. Note however, that I am representing regions as single cells in a table, whereas in Constraint databases, a region is represented by a tuple.

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

I don't know what special spacial operators we'll need.

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

As a function in a cell. The function maps points to booleans. If applying the function to a point satisfies these inequations, then return true, else false.

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

I don't understand these last paragraphs.

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

Why are complex user definable domains insufficient? I have values (objects) representing regions. I can query them. What is missing?

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

Just a terminological point. Relational tuples are never tested against their predicate. They instantiate the predicate and make it a proposition. (Viewing a predicate as a proposition with free variables). Relational tuples are tested against the constraints of the domain (column), table and database. Here, I think we are mostly referring to table constraints.

As far as "solving" predicates, I'm not sure if you are referring to having some logic programming front-end to your database.

[snip]

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

Yes, thanks for the explanation. I misunderstood.

[snip]

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

Yes, I had gotten the impression that a constraint database was a Relational database with fancy constraints from your earlier post, saying that Richard's definition of the relational model really applied to Constraint databases. Thanks for the clarification. Yes, the terminology is quite overloaded, and provides a trap for the unwary.

--PeterD Received on Tue Jul 10 2001 - 18:53:37 CEST