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

Rene de Visser wrote:
> "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.

Well, you could paraphrase that if you want to be in the trolling mode. If you want to actually think about you write, you wouldn't want to paraphrase that.

>

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

You are not forced into doing that, but it has been proven the sensible solution by some 50 years of experience with programming languages, logics and other formal language applications.

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

So what exactly would an address_id be ? A reference to a particular address stoired in the central global_addresses ?

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

??

>

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

Codd was not speaking about type theory, he was speaking about domains, which are sets of admissible values for. He was not an expert in type theory. So he gives what in proper Type Theory would be a corollary deriving from the definition that I presented.

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

No, there isn't. But a DBMS can use a simple type theory, or a more powerful type theory.

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

Primitive types in type algebra would do just fine.

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

If you visited the introduction to type theory that I recommended you;d have noted that together with constructor for this complex types, you also get "destructors" (in the language of type theory) which are operators needed to access the components.

And those would not be relational operators but functions defined over these types. Like if you define a type Date you'd get a function

next_day : Date -> Date

that in its very nature is no different than an accessor function (deconstructor) like

zipCode : Address -> String

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

It depends on what you want to include in RM. If you want to include strictly relational algebra for theoretic explorations, than they are for all intents and purposes indistinguishable, because even the unnesting operators can be defined with standard operators against their domains.

If you want to include in RM also the practical language for defining user types and user functions, then these distinctions are important.

Without complex types you cannot define a decent programming language.

> Aside:
>
> Supposing we have to types
>
> A. The even numbers, with operator add 2
> B. The odd numbers, with operator add 2
>

You confuse sets with types. Yes, you could define these two types *BUT*
> We take the union of these two types and get the integers with the operator
> add 2.

You cannot expect the type system to recompose these two types using an UNION operator that would be semantically identical to Set Union and recompose the set of all integers for you.

Such thing is a useful application of Set Theory and Logic, but not the domain of Type Theory. Types are not sets, not because we don't want to be as powerful as sets, but because language theorists (including mathematicians and especially logicians who also need to study formal languages) wisely decided that SET THEORY is good enough for its domain of application, but TYPE THEORY should be distinct and should have different applications.

Therefore if you think that the above is a limitation of Type Theory, you should think it is an assumed limitation (otherwise we run into Halting problem and similar impossibility results) that makes Type Theory useful in its range of application.

> Is this a composite type?
>

Again, your assumptions and ideas about type systems are largely wrong, and I'm affraid coincide with some mistaken assumptions present in The Third Manifesto (either because you subscribe to it, or because you want to take their point of view to its bottom logical consequences for the purpose of criticizing the model).

Unfortunately The Third Manifesto discusses types without providing one single relevant citation from the domain of type theory. Which makes it for an interesting read, because it's important when somebody challenges the premises and assumptions of a theory, but unfortunately the results are missing. So I wouldn't follow the assumptions in The Third Manifesto.

> Rene.
>
>

Cheers,
Costin Received on Thu Dec 02 2004 - 01:38:51 CET