Re: What is a Relationship !?

From: Tom Hester <tom_at_metadata.com>
Date: Thu, 20 Nov 2003 15:06:50 -0800
Message-ID: <b1299$3fbd490b$45033832$14813_at_msgid.meganewsservers.com>


"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news:bpjfpo$vre$1_at_nyytiset.pp.htv.fi...
> Tom Hester wrote:
>
> >>By that definition most of the relations in a database could be
> >>classified as relationships, I guess...
> >>
> >>
> >No, first of all; there is the question of levels of abstraction. I
suppose
> >that you mean that the relations in a database model or describe a
relation?
> >But in fact, some will describe entities and some relationships or they
may
> >in fact not describe either or describe only parts of either. It depends
on
> >how the modeling was done, among other things.
> >
> >
> >>And, further, a relationship could become an entity just by giving it a
> >>unique identifier.
> >>
> >>
> >No, it also must exist in the domain of discourse. Admittedly a squishy
> >concept but one that is common in modeling--both data modeling and
logical
> >modeling.
> >
> >
> >>job(person_id, company_id, etc...) //current job(s) of person
> >>
> >>Now would 'job' be an entity or a relationship?
> >>
> >>
> >Job would be a relationship.
> >
> >
> >>What if I add start_date?
> >>
> >>
> >As I said, relationships can have attributes.
> >
> >
> >>job(person_id, company_id, start_date, etc...) //job history of person
> >>
> Yes, but since this saves the history start_date is part of the key (you
> can go back to
My point was that relationships inherently have a complex key, including at least the keys of entities that play major roles in the relationship. I must admit that it boggles my mind that start_date might be part of a key. What happens when people change jobs within a company?
> the same company at a later time; sorry, forgot to mention that)
> Still a relationship?
Yes, see above.
>
> >>What if I add a surrogate key?
> >>
> >>
> >I would say that you are doing relational modeling and not ER modeling.
> >
> OK, but perhaps the database was for a labour pension company, whose
> main function is to track
> peoples employment history over the years and the concept of an
> employment is essential. Is it a relationship then?
You seem to think that relationships are somehow less valued--or less essential--than entities? That is certainly not the case.
> (OK: this must be the "squishy concept" you mentioned earler)
>
> My point here is that I fail to understand the added value of EM
> diagrams (as opposed to pure
> entity diagrams). And if the distinction is basically arbitrary (in
> some, if not most cases) then why
> waste energy trying to decide which one it is?
It wouldn't take me much time.
>
> If we can get along with one concept (entity) instead of two (entity,
> relationship), why should we introduce this extra concept??
The difference between entities and relationships is often important in object modeling. If all you are doing is a relational model in isolation of any process model, you're right it probably doesn't make any difference; but I can't imagine why you would do that!
>
> The danger I see in E/R modelling is that N:M relationships are "left
> alone" for too long in the process
> resulting in nasty surprices down the road.
I'm not pushing ER as opposed to relational modeling. I merely attempted to answer a question that seemed to have been asked in good faith. If your claim is that ER modeling does not capture sufficient data semantics, then I absolutely agree. However, I think that relational modeling is only marginally better...
>
> best regards,
> Lauri Pietarinen
>
>
>
>
>
Received on Fri Nov 21 2003 - 00:06:50 CET

Original text of this message