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

In article <FNhye.137315$PH4.7042098_at_phobos.telenet-ops.be>, jan.hidders_at_REMOVETHIS.pandora.be says...
> >>>What does NOLOT being 'abstract' mean ?
> >>
> >>That there is no value representation associated with non-lexical objects.
> >
> > They have reference schemes, which provide values (or representations
> > thereof) that identify them! What is the difference?
>
> Well, for one thing, the number five is always (by definition)
> identified by the same representations, but the values that represent
> you can change over time.

Ok, thanks. That is a pretty straightforward definition of the difference.

> > In the ConQuer paper you directed me to
> > (http://www.orm.net/pdf/ConceptQueries.pdf), there is a ORM diagram
> > where Employee is a NOLOT, identified/represented by "nr", while PhoneNr
> > is a LOT. A sample population of the fact type "Employee has main-
> > phonenr PhoneNr" might look like this:
> >
> > 23 555-12345
> > 24 555-54321
> >
> > Again, what is the difference between the NOLOT and the LOT here? The
> > NOLOT Employee is involved in ten other fact types, with similar-looking
> > sample populations. If you want to change the "nr" of a certain
> > employee, this change must be propagated to all the sample populations.
>
> That is an artefact of the implementation that Terry Halpin has chosen
> to describe the semantics of the language.

I would say that sample populations are an important part of the *model* as such (I'm not sure what you mean by "implementation" in this context); Halpin presents them as a main selling point. Of course, you can implement it differently on a computer, but on the model level, propagation *is* required.

I am aware that the NOLOT notation is a shorthand for a particular pattern of fact type---that Employee is involved in a fact type with the LOT "nr" with certain mandatoryness and uniqueness constraints. In sample populations with the longhand notation, I have seen Employee values/objects represented by stick figures. This avoids the propagation (given that the stick figure for a certain Employee never changes), and is for all intents and purposes equivalent to a surrogate key.

> > It seems to me that the difference between LOTs and NOLOTs is that the
> > representation of a NOLO is allowed to change (but really shouldn't,
> > like RM keys), and that the change must be propagated.
>
> Except for the propagation and the "really shouldn't" part I would say
> that is correct.

So when teaching ORM, you don't advise your students to choose stable reference schemes for their NOLOTs? That is nice.

> >>No, not really. It has to do with the distinction between on the one
> >>hand houses, people and countries and on the other hand strings, numbers
> >>and booleans. The latter three can be denoted directly, the first three
> >>only indirectly by denoting a certain combination of values associated
> >>with them.
> >
> > ---which seems to refer to a particular programming language's
> > capability to denote literals. Many dialects of SQL cannot denote a
> > boolean value directly---does that mean that boolean is an "abstract"
> > NOLOT? Can I denote a point directly by saying (3,6)? How about a date?
> > Or a phone number? A phone number is not a string, but it can be
> > represented by a string, or perhaps by an integer. Or both. A string is
> > an array of characters. Is an array of integers a LOT or a NOLOT?
>
> You can decide that by asking a simple question: can the representation
> change w/o changing the identity of the object? If the answer is "no"
> then it is a LOT. Since the answer for all of the above is "no" they are
> all LOTs.

Well, it could be argued whether (3,6) is the direct denotation of a point, or whether it is the denotation of a certain combination of values associated with it, namely the x and y coordinate.

I'd again say that decision then is not based on whether something is a house or a point, but how you are going to use it in a particular database. I'm sure it is possible to come up with examples where the identity of a house is not important, but that of a point is; say, a 3D modelling system where you manipulate polygon meshes by dragging points. You might then say that what you drag are not points, but vertices whose representations are points.... Well, I think we have explored the depth of this to my satisfaction.

> > The other thing is Halpin's diagram. He has a fact type "Employee (nr)
> > earns Salary (usd)", where Salary is a NOLOT.
>
> Interesting, I would say that is probably not a very good model,
> although it is conceivable that is appropriate, but very unlikely.

That was my sentiment too, though I find it hard to believe that Halpin would make such an obvious mistake. On second glance, the Salary NOLOT has a plus sign after the reference scheme---"Salary (usd)+". Is this significant? Does it resolve the matter? If so, please disregard the comments below. :)

> > Does this mean that if two
> > employees should ever happen to earn the same, they will do so ever
> > after?
>
> No. You can alwasy disconnect one of them and reconnect him/her to
> another salary object.
>
> > Or does it mean that the user must be able to say "Employee 23
> > earns $40, but it is a *different* $40 than Employee 24 earns"? If so,
> > how does the user distinguish between the two $40s?
>
> By looking at the person that earns it. Probably the terminology would
> be something like "the income of Hidders" for one object and "the income
> of Heggland" for the other object.

Doesn't that defeat the entire purpose of the reference scheme?

> As I said, this model is a bit
> farfetched, so I don't think that it makes a lot of sense.

Yes, the model is probably wrong; salary should be a LOT, in my opinion. However, I believe that my first interpretation is the correct one.

> > I believe the decision to model something as a LOT or a NOLOT depends on
> > how you are going to use it, not what it "really" represents.
>
> True, although I don't see a very big difference between the two.
>
> > There is no logical difference between ORM and RM.
>
> I'm not sure here what you mean by "logical difference" but to some
> extent I agree with that. It is quite clear that everything you can
> model in ORM can also be modelled in the RM. I also have no problems
> with the claim that the mapping from ORM to RM is relatively simple.

In that case, I am content. It was statements to the contrary that prompted my involvement in this subthread.

> > To repeat myself, I quite like ORM. The NOLOT/LOT distinction
> > may even be a useful abstraction for modelling, but to claim that ORM is
> > logically different from the RM, and that the difference is crippling
> > the RM, is counterproductive.
>
> Well, to be fair, yes, I was trolling a bit there. But wouldn't you
> agree that if you would tell people who are used to modelling in ORM
> that from now on they can only use LOTs, these people would feel that
> their models would become less elegant?

Yes, certainly. Thus ends the great debate about RM vs. ORM, I hope. :)

-- 
Jon