Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

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

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Wed, 29 Jun 2005 17:51:56 GMT
Message-ID: <0dBwe.133168$ut1.7226423@phobos.telenet-ops.be>


Jon Heggland wrote:
> In article <EThwe.132522$eO.7105566_at_phobos.telenet-ops.be>,
> jan.hidders_at_REMOVETHIS.pandora.be says...
>

>>>>Another small thing is updating primary keys. If a primary key has 
>>>>accidentally been entered wrong and you want to fix that with an update 
>>>>then it is usually not possible to simply update it, and the problem 
>>>>gets even worse if it is also refered to by foreign keys. In an ER model 
>>>>this is a non-problem.
>>>
>>>Isn't this just hand-waving? How exactly do you "indicate" the 
>>>relationships? 
>>
>>?? You are asking how one indicates a relationship in the ER model?

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

>>>The ER model is not formal, and it's conceptual rather 
>>>than logical.
>>
>>I'm speaking loosely of ER-like models here, and for these there are 
>>already several formalizations known. See for example the work on 
>>ORM/NIAM. 

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

> 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 don't see a big fundamental difference in the basic concepts of ER and ORM. The biggest differences are probably the objectification in ORM and that you don't have explicit attributes but non-lexical object types. Hardly very deep issues.

>>Formalizing the ER model is a no-brainer and that makes it a 
>>data model that you can compare with the RM. 

>
> In that case, you can call the RM a formalisation of the ER model as
> well.

Not by itself, you would have to formally describe the mapping and that might not be so straightforward. Moreover, giving a full industrial-strength formalization of the RM is actually not that easy (I 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.

Received on Wed Jun 29 2005 - 12:51:56 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US