Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
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.
>
> 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.pdf, "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.
-- JonReceived on Tue Jul 05 2005 - 12:41:16 CEST