| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
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?
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.
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.
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.
 |
 |