Re: "No one does ER Modelling any more" <-- Is this claim true?

From: Alfredo Novoa <alfredono_at_gmail.com>
Date: Fri, 01 Jun 2007 11:27:13 -0700
Message-ID: <1180722433.140993.237610_at_m36g2000hse.googlegroups.com>


On 1 jun, 08:08, nupul <nupul.kukr..._at_gmail.com> wrote:

> There was a discussion on OOAD/UML at my workplace and the this was
> the facilitator's comments. It was difficult to digest but this is
> what was said/done:
>
> We have a business application to develop. We read the problem
> statement and do the following:
>
> 1. First we model the "entity classes" which we would like to store in
> the DB (aka persistent classes).

He does not have a clue.

> 2. In case of any M..N relationships between classes, we add an
> "association class" to the relationship (strikingly similar to that of
> a "relation table" in an ER diagram.)

He is using "class" with the same mean of "entity". Programming language classes are completely different to entities. If you confuse both things you are lost.

> 4. The tool is capable of generating the corresponding ER diagram and
> the required DDL statements for the corresponding database chosen.
> (The generated ER model has a 1:1 correspondence with the
> corresponding class diagram,

Because both things are the same with a different notation.

> showing the appropriate Primary/foreign
> keys...so integrity constraint is not a problem)

Integrity is a lot more than this.

> When I questioned about this approach, he said that "ER modeling is
> not done any more.

They are doing ER modeling with UML notation.

> Data Modeling Experts have now migrated to the
> Systems analyst domain where all the modeling is done using 'entity
> classes'...and i won't let any one touch/modify them"

He is an unprofessional clueless ignorant.

> This left me with a few questions...Isn't data design as important as
> application design?

It is more important.

> What about maintaining functional dependencies and
> Normalization? If i "don't touch" the entity classes how will i
> normalize, won't this be a rigid approach? (i mean the tables will
> surely split up in case of normalizing)

You have to do good database design and to ignore all the OOAD/UML bullshit.

Regards Received on Fri Jun 01 2007 - 20:27:13 CEST

Original text of this message