Re: Object-oriented thinking in SQL context?

On Jun 24, 5:12 am, rp_at_raampje.(none) (Reinier Post) wrote:
> 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?

I would allow recursive types but disallow recursively defined values.

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

I would disallow that.

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

I would disallow that too.

> Or can we only have finite nonrecursive instances such as
> S3 =D= {A: {{B:3, C: {A: {{B:1, C:{}}}}}}}
> ?

Yes, allow that

Or are we even stricter and completely disallow the use of
> the same relation name at different levels of nesting?

No I think that's too strict.

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

Yes. Note that a "database value" is really just a tuple with RVAs. So it should be sufficient to be able to deal with RVAs and tuple 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.)

Actually I suspect that is not the case. i.e. one cannot always eliminate abstract identifiers. A Triangulated Irregular Network seems to be an example of that. How can a set of triangles reference shared vertices without introducing identifiers for them? The only alternative seems to be to use the value (i.e. x,y,z) of a vertex to identify it and then use integrity constraints to somehow reduce the degrees of freedom in the model. It's not clear to me whether it could be practical. For example, when a user selects and moves a vertex around in a GUI, it would be necessary to update multiple appearances of the same (x,y,z) in the model. Failing to do so would typically cause an integrity constraint violation.

A TIN may not be a very good example because in practise it is usually based on a Delaunay triangulation. In other words the triangles are / calculated/ from the vertices. Therefore it is sufficient to only model the vertices, and so we just have a set of (x,y,z) and no need to introduce abstract identifiers. Received on Wed Jun 24 2009 - 04:13:21 CEST