Re: Logical equivalence of simple and complex types under the relational model?

Rene de Visser wrote:
> I have read a number of papers that discuss whether complex data types
> should be allowed under the relational model.
>
> What I haven't seen analysed is whether there is actually any logical
> difference (upto renaming/isomorphism) between the resulting models.
>
> It seems to me at first sight that
>
> 1) RM with simple types
> 2) RM with complex types
>
> are indistiguishable at the logical level.
>
> Naturally in a particular programming language it is possible for them to
> look different (but not necessary).
>
> I came to this thought by looking at some simple examples. And noting in
> some relational programming that it appears to be only a question of
> physical storage allocation whether to use complex types or not.
>
> Consider the following two examples
>
> A. Business partner with optional first and last names.
> B. The common date type example (a complex type) compared to stored day,
> month and year.
>
> And their alternate physical implementations (or lower level logical
> implemenations if you prefer to think of this at a lower level of semantics
> rather than an actual physical level).
>
> 1.A. We have an identifier for the person. Person1, and the relations first
> name and last name.
> i.e. we have the tuples (id: Person1 last-name: "Smith") (id: Person1
> firstname: "John")
>
> 2.A. We have a person object (complex type). For example Person1. Person one
> has accessor functions/methods first-name and last-name.
> However functions are only a special case of relations and so these
> fucntions are also relations, equivalent to the relations above.
>
> No difference between 1.A and 2.A at the logical level.
>
> 1.B We have three fields: day, month, year which may be present in a
> relation.
>
> 2.B. We have a complex type: date. Similar to above we have functions day,
> month, year. Using these relations for every relation in 1.B we can
> construct an updatable view that maps to the relation above in 1.B. This
> construct view behaves exactly the same as the view/relation defined in 1.B
> above.
>
> Again no difference between 1.B and 2.B at the logical level.
>
> I am guessing that this is true in general.
>
> If this is so why was there in the past debate about whether to allow
> complex types or not, when it seems in theory (and in at least some
> languages) it makes no logical difference?
>
> Rene.
>
>
>

It makes big logical difference with regards to one very important criteria: Economy of Expression.

In other words why should you say

-> select street1,street2, city, state,zip, country from users

when you can simply say

-> select address from country

That's one of the reasons you have complex type in the first place in common languages, otherwise languages without complex type are computationally just as powerful. Anything that can be expressed using complex type can be expressed with simple type by unfolding a large number of variables.

Costin Received on Mon Nov 29 2004 - 20:18:16 CET