Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message news:MPG.1d35174a7f9255929896e2_at_news.ntnu.no...
> In article <1120578666.773825.118800_at_f14g2000cwb.googlegroups.com>,
> boston103_at_hotmail.com says...
>> > Perhaps. The difference between representation and presentation is just
>> > two letters. :) I think it is more convenient to define a single
>> > Temperature domain, with possreps Celsius, Fahrenheit and Kelvin, than
>> > to define three different domains, and make operators for converting
>> > between them.
>>
>> It's an illusion ;) You still have to define three data types and then
>> union them(see below).
>
> No, I don't. :) See below.
>
>> Here's an example in C:
>>
>> union my_data
>> {
>> char c;
>> int i;
>> float f;
>> };
>>
>> x, y my_data;
>>
>> x.c='x';
>> y.f=3.14;
>> x=y;
>> -- etc --
>
> I'm still not clear on how this works. Do character, integer and float
> operators work on this union?

No, they don't. You need to define functions operating on the new data type.

What happens if you attempt to multiply x
> by y (before the assignment x=y)?

You'll get a type error at the compilation stage.

>
> Here's an example in Java:
>
> class Temperature
> {
> private double celsius;
>
> public double getCelsius() { return celsius; }
> public double getFahrenheit() { return celsius * 9 / 5 + 32; }
> public double getKelvin() { return celsius + 273.15; }
>
> public void setCelsius(double c) { celsius = c; }
> public void setFahrenheit(double f) { celsius = (f - 32) * 5 / 9; }
> public void setKelvin(double k) { celsius = k - 273.15; }
> }
>

That's called cheating ;) In Java, you're just narrow the single double datatype by defining accessor/mutator functions on the double d.t.. This is different from the possrep example where you define multiple possreps using different data types in a way identical to the union type.

>> I am not sure that "possible representation" in TTM is a good name
>> either. Why not use the established terminology and just call the
>> whole construct a [disjoint] union type (as has been done in
>> programming languages for ages) ? I may be missing some subtle
>> difference betewen the u.t. the p.r., though.
>
> I don't think union types are relevant. In C, you can say int i = 14; or
> int i = 0xE;---that does not mean int is a union type.
>

The ability to say i=14 or i=0xE has got nothing to do with union data types. In both cases you assign an integer constant to an integer data type . How is it even relevent to the issue of types ?

>> I think that using the word "representation" is rather confusing. If a
>> representation is just [one of constituent] data type[s], why not just
>> say so ?
>
> I don't think it is.

I guess it's a matter of taste, not substance, but still why invent a new term where there is already a good enough old one ? What does it add to understanding of the typing system ?

> --
> Jon
Received on Wed Jul 06 2005 - 03:42:28 CEST