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

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Tue, 5 Jul 2005 12:41:16 +0200
Message-ID: <MPG.1d346d7d966020f19896dc_at_news.ntnu.no>


In article <jeadnc-OYJU-TFTfRVn-rA_at_comcast.com>, boston103_at_hotmail.com says...
> > Pluto is owned by Mickey
> >
> > is ambiguous, because we don't know what the labels Pluto and Mickey
> > represent. In contrast,
> >
> > The dog Pluto is owned by the mouse Mickey
> >
> > and
> >
> > The planet Pluto is owned by the person Mickey
> >
> > are not ambiguous, because the "entity types" dog, mouse, planet and
> > person are mentioned.
>
> But would not it be much simpler just to use first-order logic language and
> say:
>
> Pluto is_owned_by Mickey & is_dog(Pluto) & is_mouse(Mickey)
>
> What additional power does using the notions of "entity type" and the
> "label" provide ?

Isn't that sorted vs. un-sorted predicate logic? I don't know about power; ask a logician. :) Convenience, perhaps? That is after all one of the main motivations for notations / Conceptual modelling languages like ORM. When I think about it, I believe my ORM book made a point of that entity types are disjoint (TTM does too, of course). That is, the dog Pluto and the mouse Pluto are not the same, even though their representations are the same. Thus,

The dog Pluto is owned by the mouse Pluto

means something different than

Pluto is_owned_by Pluto & is_dog(Pluto) & is_mouse(Pluto)

---at least if we don't go into subtypes.

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

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

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

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

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.

-- 
Jon
Received on Tue Jul 05 2005 - 12:41:16 CEST

Original text of this message