Re: Object-oriented thinking in SQL context?

From: none <rp_at_raampje.>
Date: 23 Jun 2009 21:12:21 GMT
Message-ID: <4a414535$0$18802$>

David BL wrote:

>I am suggesting you can have a "database" type where a given value of
>that type is a set of named relation values, where the relations
>values are of distinct types. More specifically I'm thinking that the
>database type fixes the names and types of the relations.

In a book on database design I've used, your idea is called 'composition'. Recursion is disallowed there.

Do you allow recursion? If you do, you have to specify what sorts of instances of your database types you're going to allow.

E.g. consider a database type T with a single relation A with two attributes, B (an integer) and C (a T). What are possible values for T? The singleton S1 =D= {A: {{B:3, C:S1}}} ? (This is possible if instances can be recursive. But it is not a valid set in the set theory I've seen; it can be expressed in terms of valid sets by introducing arbitrary identifiers, which you were trying to eliminate.) The singleton S2 =D= {A:{{B:3, C: {A:{{B:1, C:{A:{{B:4, (...)}}}}}}}} where the subsequent B values form the decimal expansion of pi? Or can we only have finite nonrecursive instances such as   S3 =D= {A: {{B:3, C: {A: {{B:1, C:{}}}}}}} ? Or are we even stricter and completely disallow the use of the same relation name at different levels of nesting? It's up to you. Allowing values such as S1 and S3 seems straightforward (instances remain finite), allowing values such as S2 doesn't.

Another decision you'll need to make is how to extend the relational query language to operate on such values. Even when all values are nonrecursive and finite it may be worthwhile to add operations. E.g. the nested relational model (which allows relation types, rather than database types, as attribute types), extends the relational algebra with two operations: nest, which groups a set of attributes within a relation into a relation-valued attribute, and unnest, which does the opposite. You may want to introduce corresponding operations for your database-valued attributes.

Finally, your motivation is that database-valued attributes give us the same addition in expressive power that surrogate identifiers do, when compared to flat, surrogate-less databases. How do you know? What do you mean by it? (I have an idea, but this posting is growing too long.)

Received on Tue Jun 23 2009 - 23:12:21 CEST

Original text of this message