Re: Another view on analysis and ER
Date: Wed, 05 Dec 2007 07:09:03 +0100
Message-ID: <4756407b$0$235$e4fe514c_at_news.xs4all.nl>
JOG wrote:
> On Dec 4, 11:42 pm, Ruud de Koter <nob..._at_internet.org> wrote:
>> David Cressey wrote:
>>> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>> news:58c47eeb-adf0-414a-a1f4-9077039bd7fd_at_l1g2000hsa.googlegroups.com...
>>>> Genuine question guys. From an E/R perspective (one of the good
>>>> variants, that allows relationships to have attributes), if I'm faced
>>>> with the following data.
>>>> -- Fred married Wilma in Bedrock.
>>>> -- Barney and Betty married in Paris.
>>>> How do I decide whether I am dealing with a marriage entity or a
>>>> marriage relationship?
>>>> The literature I'm reading here is telling me that the choice is based
>>>> on what 'things' are key to the business. If my business is concerned
>>>> with people (tax collection say), 'marriage' is best modelled as a
>>>> relationship, whereas if the marriages themselves are my focus
>>>> (perhaps I run a church) then its probably better as an entity.
>>>> Have I made the right interpretation here, and is there general
>>>> agreement here? I am much more comfortable seeing that some variants
>>>> allow relationships to themselves have attributes, and that there is
>>>> nothing sacred about choices between using relationships or entities,
>>>> making it a design decision instead.
>>>> Thanks in advance, J.
>>> My answer is that it's subjective. If the subject matter experts all treat
>>> a marriage as a relationship, follow their lead. If the subject matter
>>> experts all treat it as an entity, follow their lead, but insist that
>>> there's a key attroubt that identifies it. (Do the SME's have any such
>>> thing as a "marriage ID" attribute?
>>> Once you switch over from analysis to design, here's what happens: the
>>> attributes that you discovered during analyisis and attached to entities or
>>> relationships will be carried over from your ER model your design model,
>>> which I presume will be a relational model.
>>> The entities and relationships themselves, as such, will all disappear!
>>> Another thing that will carry over is the keys, used to identify instances
>>> of entities in the subject matter (or UoD if you prefer). Sometimes the
>>> keys used by the SME (subject matter experts) are a little too informal and
>>> require "common sense" to disambiguate. That's a special case, and doesn't
>>> affect this discussion.
>>> I'm used to expressing a relational model in terms of tables (relational
>>> tables), but I presume that what follows could be transliterated into terms
>>> of relvars without any difficulty.
>>> Each entity will have a table of its own, with the attributes that pertain
>>> to that entity. The primary key of the table will be the key attribute of
>>> the entity.
>>> Each relationship will have a table of its own, except for a few that can
>>> be piggy backed onto entity tables. The primary key of a relational table
>>> will consists of two or more foreign keys, compound. These tables will
>>> automatically be normalized up to 3NF unless your analysis put an attribute
>>> on the "wrong entity". I'm not sure about normalization beyond 3NF.
>>> The above process is so automatic that you can have software that does it
>>> for you. Indeed, that's what several tools do. They express an ER model
>>> in terms of metadata, and likewise express the relational model in terms of
>>> metadata. And they have a programmed process that will create a relational
>>> model from an ER model. The only tool I know calls the relaional model a
>>> "physical model" and makes it specific to some product like Oracle or DB2,
>>> etc. But that's a trivial detail. The software also turns models into
>>> diagrams and/or create scripts for you.
>>> So where did the entities and relationships go? They disappeared into the
>>> ether! However,
>>> when the application people get around to designing screens and reports,
>>> they can tie each feature back to an original entity or relationship. That
>>> can make the resulting system coherent for the users.
>>> I apologize for this repsonse. It's really a lot more than you asked for.
>>> But it's actually easier to use than it is to describe. It may also
>>> oversimplify. The relational model that software constructs may not be the
>>> best relational model that could be designed to deal with the original
>>> problem.
>> Very clear, this answer. One minor point I 'd like to add is that it is >> not subjective. Instead, the choices are governed by the goal to be >> served with the application (assuming the analysis aims at building an >> application). > > Shared data anyone? Isn't the point that we _don't_ necessarily know > all the applications? > >> As clearly stated, there is a difference in perspective >> between tax inspectors and priests (and spouses, for that matter). There >> simply is no single authorative model for a marriage, there are several >> points of view, depending on the universe of discourse one operates in. >> What we, in analysis, can do is to make sure we are aware of these UoDs >> , and make a conscious choice. That is something else than being subjective. > > Why make the choice? Keep the data neutral and its good for both tax > inspectors and priests right.
> >> Hope this helps, >> >> Ruud de Koter. >Received on Wed Dec 05 2007 - 07:09:03 CET