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

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:3167cfF379ukqU1_at_individual.net...
> Rene de Visser wrote:
> > "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> > news:314pe5F371n2cU1_at_individual.net...
> >
> >
> >>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 ?
> >
> >
> > No, under model 1 I would pass address_id
> > and under model 2 I would pass address
> >
>
> But under model 1 address_id is superfluous. It is an entity that is
> entirely unnecessary !!! Plus you'll pass an address_id to the function
> and that function has to look in some global_addresses table. You
> increased the coupling and put entirely gratuituous constraints on the
> design.

We could paraphase that and say that the complex type address is superfluous.
It is a type that is entirely unncessary. Plus you'll pass an address instance to the function
 and that function has to look in some globally defined components of that complex type. You
 increased the coupling and put entirely gratuituous constraints on the  design.

> Maybe I don't want to have a global_addresses table with some ridiculous
> address_id to take care of.

 Maybe I don't want to have a global type address with some ridiculous  address instances to take care of.

[Aside: the address_id is not a pet. It can look after itself, or the DBMS can look after it]

> There's no need to have "identity" for values. Values are
> self-identifying. If you have the number 3 you don't need an 3_ID for it
> to identify. So if you have the address ((zip 1234) (street "X no 4")
> (country "USA")) that's your value right there, just like the value 3.

Theres no need to have identity for complex type instances. But then I would claim that you need equivalence classes, and that these are effectively the same.

> The difference is by construction. Types are constructed according to an
> algebra of types (type system) starting from primitive values (bool,
> int, char, string, etc).

What do your believe Codd is referring when he says:

"A domain is simple if all its components are atomic (nondecomposable by the database system."

I took this to mean that he was talking about types. Maybe my mistake here is missing a crucial difference between type and domain?

What do you think he means by nondecomposable by the database system?

>
> Types that are derived from other types using composition operators
> (ARRAY, RECORD, UNION, "->", etc) are composite types.

This seems a good starting point. This then brings us to the two questions:

If we only allow access to values of these constructed types using relational operators,
does this allow us access the full power of these types? What advantages / disadvantages would that bring?

Are then the complex types indistiguishable from atomic types in the RM system?

Aside:

Supposing we have to types

1. The even numbers, with operator add 2
2. The odd numbers, with operator add 2

We take the union of these two types and get the integers with the operator add 2.
Is this a composite type?

Rene. Received on Wed Dec 01 2004 - 17:16:43 CET