Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Mon, 04 Jul 2005 21:23:49 GMT
Message-ID: <FNhye.137315$PH4.7042098_at_phobos.telenet-ops.be>
Jon Heggland wrote:
> In article <eHrxe.135259$JD6.7251058_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.
> 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. If he had chosed the formal semantics of ORM as a basis he could have given a direct description of the semantics similar to that of the Calvanese paper and then such propagation would not be necessary.
> 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.
> However, I can't
> reconcile that with two things. One, your reply to Marshall Spight:
>
>>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.
> 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.
> 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. As I said, this model is a bit farfetched, so I don't think that it makes a lot of sense.
> 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.
> 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?
- Jan Hidders