Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Fri, 01 Jul 2005 22:13:11 GMT
Message-ID: <Xdjxe.135078$8T6.7279748_at_phobos.telenet-ops.be>
Jon Heggland wrote:
> In article <0dBwe.133168$ut1.7226423_at_phobos.telenet-ops.be>,
> jan.hidders_at_REMOVETHIS.pandora.be says...
>
>>>Yes. I know how to draw lines on a paper, but how do you do it on the >>>logical level (if there is such a thing)? But it seems you answer that >>>further down. >> >>Ok, but just to be sure let me answer it a bit more. It is quite easy to >>come up with a formal description of the syntax of such a data model, >>and it is also very easy to formally describe what drawing such edges >>exactly means, including any constraint that might be included in the >>notation.
>
> Do you have any examples apart from ORM? (What are the operators of ORM,
> by the way?)
Sure. FDM, IFO, LDM, HERM and even for subsets of UML class diagrams there are formalizations.
For query languages for ORM see for example http://www.orm.net/queries.html or the work by Arthur ter Hofstede et al http://citeseer.ist.psu.edu/70483.html and if you give me a week I can invent two more myself. :-) Really, why do you think coming up with such a language would be a problem?
>>>OMR/NIAM is very nice indeed, but it is little more than a graphical >>>notation for the relational model. >> >>I completely disagree with you here. This mapping can be far from >>trivial with ORM, and usually there is more than one way to map them and >>choosing one involves what I would describe as 'implementation decisions'.
>
> I can't claim much experience using ORM; I have only read a few books
> and articles. But my impression is that ORM's concept pretty much map
> 1:1 to the RM. Object type = domain. Reference scheme = possrep.
> Relationship type = relvar. Uniqueness constraint = key. If we renamed
> the RM terms to match, would it then be an ER model?
>>>Is it really common practice to refer >>>to it as "ER-like"? That is doing it a great disservice, in my mind. >> >>You are the one who just called it "little more than a graphical >>notation for the RM". :-)
>
> I meant that as praise, not criticism. :)
Of course you did. :-)
> But my point was that ORM and
> Chen's ER model are not that alike. What defines whether a conceptual
> modelling notation is ER-like or not? The use of the words "entity" and
> "relationship"?
Yes, these should be the fundamental concepts and they should be used in more or less the same way.
> Are UML class diagrams ER models?
Yes.
> Are semantic networks?
Yes.
> Are XML schemas?
No.
> My main beef with ER is the relatively arbitrary separation of entities
> and relationships. ORM avoids that (though it does separate "non-lexical
> objects" / "entities" and "lexical objects" / "values", perhaps a bit
> needlessly).
>
> And ORM can specify (the equivalent of) multiple candidate keys, and
> keys for relationships. I really miss that in (Chen's) ER (and most
> variants thereof).
Oh yes, and it is very easy to add all that.
>>>>Formalizing the ER model is a no-brainer and that makes it a >>>>data model that you can compare with the RM.
>
> [snip]
>
>>Moreover, giving a full >>industrial-strength formalization of the RM is actually not that easy
>
> Formalising the ER model is a no-brainer, but formalising the RM is not
> that easy? Is this really what you are saying?
Of course it is. Have you ever written down a full formal definition of the relational model in set theory?
>>have taught a few in the past) and often even more complex than doing >>the same directly for some ER-like data models. So given that we can >>give an elegant and simple formalization directly, it doesn't make much >>sense to give an alternative that is indirect in nature and therefore >>harder to understand and reason about.
>
> The RM is harder to reason about?
No, what I said is that the whole that consists of the formalization of the relational model plus the mapping of ER diagrams to that formalism, is harder to reason about.
- Jan Hidders