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

Jon Heggland wrote:
> In article <jeadnc-OYJU-TFTfRVn-rA_at_comcast.com>, boston103_at_hotmail.com
> says...
> > I think that multiple "possible representations" is merely an attempt to
> > inroduce the union type (available in languages from C to ML) into the RM.
> > I do not think that the Celcius vs. F example is motivating enough for
> > multiple p.r. (this stuff belongs to the presentation layer rather than to
> > the database).
>
> 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).

>
> > More useful example might be this:
> >
> > In ML:
> >
> > datatype money = cash of int | cheque of string * real;
> >
> > val x = cash 150;
> > val y = cheque("Bank of Whatever", 150.0)
>
> I'm unfortunately not familiar with ML (nor with the use of union types,
> I must admit). Are these equal, is x = y? Are you able to designate the
> string of x? What is its value?

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

my_data defines a "union type" which, as its name says, is a union of three data types, char, int, float. Apparently possreps are just data types making up the resulting data type, that's all.

>
> > > ORM talks about entity type (e.g. temperature), label (e.g. 37) and
> > > reference mode (e.g. degrees Celcius). In TTM, this is corresponds to
> > > domain / data type and possrep, which includes both "label" and "mode".
> >
> > Yeah, probably (since I am not sure what label and the r.m. are).
>
> You're right, it's mostly a guess from my side. But to try to relate it
> to TTM domains and possreps: a domain POINT can have a possrep (X
> INTEGER, Y INTEGER) (where INTEGER is a domain defined elsewhere, with
> possreps including simple numerals). POINT(4, 5) is a value of "entity
> type" POINT, 4 and 5 are "labels", and X and Y the respective "reference
> modes" of each label (given implicitly by ordering---I'm not sure what
> the correct Tutorial D syntax is).

Why not call 4 and 5 just values of the POINT type components ? If anything can be called a "label" (or a tag), it's X and Y in the type declaration (possrep). What is gained by using the terminology of labels and reference modes ?

>
> > Still wondering what a "semantic domain" as well as a a "conceptual object
> > type" (http://www.orm.net/pdf/ER96.pd­f, "Conceptual query language"),
> > might be. Do you have any idea ?
>
> Your guess is as good as mine. I'd guess (hope?) that "semantic" means
> approximately the same as "conceptual", and that "domain" is the same as
> "object type", but I wouldn't count on it. As for the difference between
> domains that are semantic/conceptual and those that are not, I assume
> the reasoning is something like this:
>
> A number in and of itself does not mean much; hence, "number" is not a
> semantic domain. A temperature (represented by a number), however, does
> mean something; thus "temperature" is a semantic domain.
>
> I may be attacking a straw man here, but I think this distinction is
> spurious and rather useless. A temperature in and of itself does not
> mean much either.
>

Thank you.

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.

> The ConQuer article says it "exposes semantic domains as conceptual
> object types, thus allowing queries to be formulated in terms of paths
> through the information space"---I think it could be said more precisely
> that it knows the difference between value and representation, thus
> preventing confusion between disjoint types such as Countries and Car
> models, both of which are represented by name.

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 ?

> --
> Jon
Received on Tue Jul 05 2005 - 17:51:06 CEST