Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

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

From: VC <boston103_at_hotmail.com>
Date: Sun, 10 Jul 2005 23:00:31 -0400
Message-ID: <BtidnUZL-45RfUzfRVn-uQ@comcast.com>

"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message news:MPG.1d39d1798bf8535b9896f0_at_news.ntnu.no...
> In article <1120833398.573397.92590_at_o13g2000cwo.googlegroups.com>,
> boston103_at_hotmail.com says...
>> > > You cannot apply any function dealing with ints to the value of the
>> > > my_data type, you need to define functions capable of handling
>> > > values
>> > > of the type you've just defined.
>> >
>> > Then what use is it? What can you do with it except assign values to
>> > variables of that type? There seems to be at least some operators
>> > associated with it by default, since you can say x.c='f' and y.f=3.14.
>> > What is the type of the expression x.c? Is it char or my_data? If it is
>> > my_data, there at least is an operator to convert char to my_data. Why
>> > isn't there one to to do the opposite? Can you compare a my_data value
>> > to a char, int or float?
>> >
>> In order to do anything with any user defined type, one has to define
>> operations/functions that can handle elements of the newly defined
>> type. What can you do with the T.D. TYPE without defining functions
>> over the type ?
>
> Express literals, perform assignments, check for equality, access
> components of the representations....

The same is possible with datatype in say ML with the exception of accessors which would have to be defined manually which is not a big deal.

>> As to comparing apples with oranges, can you compare TEMPERATURE with
>> RATIONAL ?
>
> Not directly, of course, but it's not a problem either. It seems you
> know TD syntax better than me, but isn't this approximately right?
>
> VAR T : TEMPERATURE;
> VAR R : RATIONAL;
> T := CELSIUS(23.5);
> R := 23.5;
> IF THE_CELSIUS(T) = R .... // true
> IF THE_KELVIN(T) = R .... // false
> IF T = R .... // compilation error: type mismatch
>
> I think some D implementations use the syntax T.CELSIUS instead of
> THE_CELSIUS(T).
The same is possible in any language that can extract the component to be comapred of course.

>
>> > > E.g. you'd need to define conversion functions (my_data->int,
>> > > my_data->char, etc) and any additional functions you'd want to
>> > > have.
>> >
>> > How would the definition of such a function look?
>>
>> Given datatype t = L1 of int| L2 of float;
>>
>> fun get_int(L1 x)= x | get_int(_) = /*raise error */
>> fun get_float(L2 x) = x | get_float(_) = /*raise error*/
>
> Thanks. This makes it pretty clear that a t value is either an L1 or an
> L2. I suppose you have some mechanism for determining which it is?

Actually, I've extracted an integer (get_int: t->int) -- the tag L1 was lost. The ML mechanism is pattern matching: the argumnet is matched either with L1 x or L2 x and the variable x bound or an exception is thrown. It would be similar say in Pascal where one would use the tag in some sort of a case statement( the usual union type implemetation saves the tag with the value as I believe would probably be done in a possrep implementation).

>
>> > > Let's use the Tutorial D example instead in order to avoid Java type
>> > > system pecularities. There, TEMPERATURE is defined as having one
>> > > possible representation:
>> > >
>> > > TYPE TEMPERATURE POSSREP CELSIUS ( C RATIONAL ) ;
>> >
>> > ...and possreps FAHRENHEIT ( F RATIONAL ) and KELVIN ( K RATIONAL ).
>>
>> There was no 'and possreps FAHRENHEIT ( F RATIONAL ) and KELVIN ( K
>> RATIONAL )' in my discussion.
>
> Temperature was *my* example, with three possreps. I don't understand
> why you ignored the two other.
>
>> > Great. Is your temperature a union type?
>>
>> Certainly not. The original example from which I derived mine has only
>> one component datatype (one "possrep").
>
> So your position is that a datatype with just one possrep is not a union
> type, but one with multiple is? Then I don't see how you can claim they
> are the same concept.

I apologize if I've created the impression that I said that the union type was equivalent to a TD type with any number of possreps. My claim is that a type defined by *one* possrep is equivalent to a record/struture/or whaever u.d.t. in some PL and a data type with *multiple* possreps is eqivalent to a union datatype (combining records/structures/or whatever).

>
>> > (By the way, I find it counter-intuitive to treat celsius as a
>> > datatype.
>> > Celsius is a representation of temperature.)
>>
>> I'll ignore the remark for now since we already have more than enough
>> "representations" to talk about.
>
> Fair enough, but I am not trying to introduce another meaning of the
> term "representation". It is the same I have used all along.
>
>> > > datatype temperature = {c:rational} and describe a value of the type
>> > > temperature as just {c=10}.
>> >
>> > I guess I really should learn ML, but.... Can I now define a datatype
>> > coloumb {c:rational}? How can celsiuses and coloumbs then be
>> > distinguished? If I can't, what is the use of defining the datatypes as
>> > opposed to just using rational?
>>
>> Of course, you can. They'll be distinguished by their tags {celsius,
>> coloumb}.
>
> I'm sorry. When you said "describe a value of the type temperature as
> just {c=10}", I though you meant just {c=10}, not celsius {c=10} or
> whatever. Where does the celsius tag enter into your example? Or do you
> mean the datatype names "temperature" and "coloumb"?

OK. In ML (or many other P/L.s), we can have a *record* datatype:

datatype cartesian = {x:rational, y:rational}

.. in which fields have names (x and y).

Let's introduce another record datatype:

datatype polar = {r:rational, theta:rational}

... and combine them using the union datatype:

datatype point = Cartesian of cartesian| Polar of polar

Now, to define a point constant, one would say: Cartesian {x=1, y=2} ( or maybe Polar {r=5, theta=6}). If one just said {x=1, y=2}, the resulting constant would be of the cartesian datatype, not of the point type. Quiet similar to what you would do in the TD i(gnoring minor syntactical differences). My using Cartesian vs. cartesian may have been a little confusing since those are different language objects:. cartesian is a datatype (as are polar and point), but "Cartesian" is a union *tag*. You can use any names that make sense.

What I meant by the phrase "describe a value of the type temperature as just {c=10}" was the following:

Let's assume (as I did in my earlier example} that we have only one possrep:

TYPE CELCIUS POSSREP (C RATIONAL). There are two possible translation into ML:

  1. datatype celcius = {c:rational} datatype temperature = Celcius of celcius

A constant: Celcius {c=15};

A little bit silly (a union type with only one component plus a record datatype) but closest to the the original TD example.

2. datatype temperature = {c:rational}.

A constant {c=15}.

We've defined a record type with one field. No need for a union datatype. That's what I meant by "just {c=10}"

Another translation might be a union type with one component but witout the record definition: datatype temperature = Celsius of rational; and a constant Celsius 15.

>> > > Now, to the POINT example. The T.D. example:
>> > >
>> > > TYPE POINT
>> > > POSSREP CARTESIAN( X RATIONAL, Y RATIONAL )
>> > > POSSREP POLAR ( R RATIONAL, THETA RATIONAL ) ;
>> > >
>> > > .. can be expressed in ML as:
>> > >
>> > > datatype cartesian = {x:rational, y:rational}
>> > > datatype polar = {r:rational, theta:rational}
>> > > datatype point = Cartesian of cartesian|Polar of polar
>> > >
>> > > The last datatype (point) is called a union type because it's a union
>> > > of two types, cartesian and polar. To designate a value, one would
>> > > say:
>> > >
>> > > Cartesian {x=1, y=2} or Polar {r=3, theta=4}. naturally, both values
>> > > would be of the point type.
>> >
>> > But you have three types instead of just one. And I guess comparing {x=
>> > 3,y=0} and {r=3,theta=0} would be a type mismatch error, while
>> > comparing
>> > Cartesian {x=3,y=0} and Polar {r=3,theta=0} would yield true. Or would
>> > it?
>>
>> Of course there are three type (actually more, but that's beside the
>> point), two component types and one resulting type as, in my opinion,
>> there are in the T.D. POINT example.
>
> Not in my understanding of TD. Given your definition, CARTESIAN and
> POLAR are not types; you cannot define variables of those "types". The
> expression CARTESIAN(2,4) has type POINT, as do the expression POLAR
> (4,5).

That is correct. In TD , you cannot use the CARTESIAN and POLAR as datatype names in order to define independent values/constants (as you could do in ML by virtue of having exposed type names). But does it make a substanial difference with respect to undertanding what those components are ?

>> What do you mean by comparing ?
>> What specific comparison function do you have in mind ?
>
> Equality.

As I said earlier, equality is "automatically" defined in many languages having user defined type.

>
>> OK, let's approach the problem from another side. A type is a set.
>> When we say TYPE T POSSREP P(X INTEGER), how T is related to P ?
>> Obviously T is a set which means that something defined by "POSSREP P(X
>> INTEGER)" must be a set too. What kind of set this is ? How would you
>> describe its elements ?
>
> T is a set. P is a mechanism (sorry about that vague word) for denoting
> the members of that set: T = { P(X) | X element_of INTEGER }. P is not a
> set. You might perhaps say is is a mapping from INTEGERs to Ts?

OK, what kind of mapping is it ? Could you give a "for example" ? Let's assume we have a small domain/set: MY_INTS= {1,2,3}. Now, we define:

TYPE T POSSREP P(X in MY_INTS)

What is T ?

Thanks.

>
> It becomes more complicated if you have more than one possrep, because
> then you have to provide mappings between the possreps.

We'll deal with that later ;) Received on Sun Jul 10 2005 - 22:00:31 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US