Re: Logical equivalence of simple and complex types under the relational model?
Date: Tue, 30 Nov 2004 18:42:54 -0800
Message-ID: <314pe5F371n2cU1_at_individual.net>
Rene de Visser wrote:
> "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.
>
For a nice introduction to the problematic of type systems, please google for Robert Constable "Naive Type theory"
> 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 address object would be decomposable both outside the DBMS (in the host client language) and inside the DBMS. For example I would be able to create a spatial index on address.getZipCode() .
>>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.
It is selecting a complex value
> 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.
>
It is very relevant as it provides for *economy of expression*. Of course you can provide a emulation of the same operation by unraveling complex types into simple types, but you'll have an unnecessary clutter, while according to E.W. Dijkstra
"beauty is our business"
Therefore the ugliness of expressions has very serious consequences.
> 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.
>
It is more economical expression, rather than manipulating 7 component variables you manipulate one complex variable.
If you have to unravel the 7 components into individual variables, then you're right: non economy is done. But some computations can pass the entire complex value to let's say another function. And you wouldn't want that function to have 7 parameters instaed of one, would you ?
> 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.
>
Yes, it is different.
> 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.
>
That would be the case with a client library. The notaion :param is customary for bound parameters to "prepared" statements from client libraries.
> Rene.
>
>
>
Costin Received on Wed Dec 01 2004 - 03:42:54 CET