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

In article <g96dnThMNL_oxFXfRVn-gg_at_comcast.com>, boston103_at_hotmail.com says...
> If you like ORM, you apparently understand what a LOT is. Could you please
> provide, for my benefit, a [semi]formal definition of what a LOT really is?

I'm not sure---I may have misunderstood ORM. My take is that NOLOTs are user-defined data types, and LOTs are system-defined data types; thus the distinction is rather trivial.

I can try to elaborate a little. However, be aware that my understanding of ORM is primarily based on the 1989 book by Nijssen and Halpin. Things may have changed since then for all I know.

The book unfortunately does not define "entity", but says that entities are "referenced" by "labels". It unfortunately does not define "label" either. However, it tries to clarify thing with examples, e.g. by noting that the fact

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. I understand this as the approximately the same thing as the data type / domain concept in The Third Manifesto. Dog is a domain, with a possible representation of the dog's name as a string. In Tutorial D, you can refer to the dog Pluto as DOG("Pluto"), which of course is not even comparable to PLANET("Pluto"), since they are values from different domains.

System-defined domains have possreps too, of course. For instance the string representing the name of the dog in question might be represented by "Pluto", 'Pluto', or perhaps { 'P', 'l', 'u', 't', 'o' }. An integer might be represented by 14, "14", 0xE or XIV, depending on the choices of the language designer when providing shorthands for certain literal expressions ("14" is probably a bad choice, but something like INTEGER ("14") might be defined to denote the same value as 14).

Where ORM and TTM differs, is that ORM has a tacit assumption that only certain domains can be used as representations, i.e. the lexical object types / labels. In TTM, this is not so. You can define a domain POINT, possibly represented by a pair of numbers X and Y (in some unit), or a pair of numbers R and THETA (each domain can have more than one possible representation (possrep)). You can then define a domain LINE, with a possrep of two points. And so on.

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

As for the question of "identity", I have not considered that very interesting of relevant. If you define a domain PERSON with possrep NAME (a string), something must be done if that person changes his/her name. However, the ORM material I have read, doesn't consider such database updates at all---it is presented as "just" a conceptual model, possibly with a query language. (Hence my confusion at Hidders's adamant claims that ORM and other approaches consider separation of identity and value THE central issue.)

Thus, I have assumed that you either have to cascade the changes, or you introduce a level of indirection using a surrogate key (without necessarily showing it to the user at the conceptual level). And that the distinction between LOTs and NOLOTs is primarily an artifact of the lack of user-defined data types in DBMS implementations.

-- 
Jon