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

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:313gnaF37921qU1_at_uni-berlin.de...
> Rene de Visser wrote:
> > "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> > news:311b0fF35fc3vU1_at_uni-berlin.de...
> >
> >>Rene de Visser wrote:
> >>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.
> >>
> >
> > While I get what your saying, your example does not show this because
your
> > two statements do completely different things.
> >
> > Under Model1 it should be
> >
> > select address_id from country
> >
> > and under model2 it should be
> >
> > select address from country
> >
> > They look pretty similar to me.
> >
> > i.e. your first select is also extracting the components/ related
variables
> > from the address, which your second select is not doing.
> > They are not equivalent and so can not be compared.
> >
>
> No, the second select is doing just that. Consider that the complex type
> address contains embeddded as components street, city, zip., etc.
>
> Update users set address= :new_address where user_id= :v_user_id
>
> Versus updating the components of an address one by one.
>
> > Rene.
> >
You are assuming that the program language, evalution and typing are separate entities from the RM system, and that I am talking about the RM supporting the complex types of this seperate programming language/system.

I am not talking about this case at all.

In this case it is trivial that the models are not equivalent when we have to take into account the different language semantics.

I am talking about a RM system with no separate programming language with its own type system.
i.e. the complex types are defined within the RM system itself, and the RM system can access the components of the values of this type.

Quoting from Codd

"A domain is simple if all its components are atomic (nondecomposable by THE DATABASE SYSTEM)." Emphasis mine.

i.e. a Complex type in the context of RM is a type decomposable by the database system ITSELF.

I suspect the way you are thinking about an address object, is actually a simple type with respect to RM, because it is not decomposable by the database system). i.e. You are actually making another model 1 example, even though outside of the RM system, i.e. in the seperate programming language, it is not a simple type.

> No, the second select is doing just that. Consider that the complex type
> address contains embeddded as components street, city, zip., etc.

Your select is selecting the address entity. That it "contains components" is irrevalent. That is a question of physical implementation. At the logical level it is irrellavent whether attributes are contained / embedded or related to the entity.

The select select address_id from country also selects the country entity and its related attributes street, city, zip., etc.

select street1,street2, city, state,zip, country from users actually explodes the address into new free variables and is somewhat similar to

select address from country

assign address.get_street1() to street1. assign address.get_street2() to street2. ...

which doesn't look anymore effecient to me.

Similarly you are assuming

Update users set address= :new_address where user_id= :v_user_id under model2
is different to
Update users set address= :new_address_id where user_id= :v_user_id under model1.

Ths difference would only be true if :new_address was something outside the RM system itself, that needed to be transfer to the RM system.

Rene. Received on Tue Nov 30 2004 - 17:31:57 CET