Re: Another view on analysis and ER



On Dec 4, 11:42 pm, Ruud de Koter <nob...@xxxxxxxxxxxx> wrote:
David Cressey wrote:
"JOG" <j...@xxxxxxxxxxxxx> wrote in message
news:58c47eeb-adf0-414a-a1f4-9077039bd7fd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.

.



Relevant Pages

  • Re: Another view on analysis and ER
    ... -- Fred married Wilma in Bedrock. ... How do I decide whether I am dealing with a marriage entity or a ... Once you switch over from analysis to design, ... of entities in the subject matter. ...
    (comp.databases.theory)
  • Re: Another view on analysis and ER
    ... marriage relationship? ... I am much more comfortable seeing that some variants ... If the subject matter experts all treat ... Once you switch over from analysis to design, ...
    (comp.databases.theory)
  • Re: Another view on analysis and ER
    ... marriage relationship? ... I am much more comfortable seeing that some variants ... Once you switch over from analysis to design, ... I'm used to expressing a relational model in terms of tables ...
    (comp.databases.theory)
  • Re: Another view on analysis and ER
    ... How do I decide whether I am dealing with a marriage entity or a ... If the subject matter experts all treat ... One of the hardest choices I 'd say, because in order to stay neutral, a thorough knowledge of the universes of discourse is necessary. ... In that case I 'd much rather make these conscious choices instead of keeping up a pretense of neutrality. ...
    (comp.databases.theory)
  • Re: Another view on analysis and ER
    ... -- Fred married Wilma in Bedrock. ... How do I decide whether I am dealing with a marriage entity or a ... I am much more comfortable seeing that some variants ... But then again, as has been repeated ad nauseum, analysis is not design. ...
    (comp.databases.theory)