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

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).
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.)
3. Next we tell the "Tool" to "Transform to data model"
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, showing the appropriate Primary/foreign keys...so integrity constraint is not a problem)

When I questioned about this approach, he said that "ER modeling is not done any more. 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"

I even googled around and found some references that say "ER modeling" is a "Structured" approach to application design - Incase of OOAD, use UML 'instead of' ER notation!!!

This left me with a few questions...Isn't data design as important as application design? 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)

I hope I'm clear as to what my confusion is? Please help!!! :)

Thanks in advance!

Nupul Received on Fri Jun 01 2007 - 08:08:12 CEST