I was taught about ER modelling at University but found it to be a pointless
abstraction, preferring to just write down the schema directly. What does
the group think of ER modelling as a design approach, and what alternatives
do you use?

John

In article <3fcee2f7$0$14053$fa0fcedb (AT) lovejoy (DOT) zen.co.uk>, "John" <?>
says...
It depends on the project. While I agree that formal ER modeling process
is often overkill, it certainly has its place. It is, after all, just
another tool. Knowing when to use a particular tool for a particular job
is the mark of the master craftsman.

Alternatives? You mean like a cocktail napkin?

"John" <?> wrote:
dependencies in data than logical data modeling. You may have confused logical
data modeling with database design. They're really two different things.

I agree with both Jawn and dataman. But, I can tell you that sometimes, what
seems to be something that can easily be designed directly as a relational
schema (skipping the ERD), can come back to bite you. The ERD helps you see
relationships in the data that you may miss otherwise. In our case, we
missed that there was a specialization/generalization. We had to rebuild. It
is cheaper to do it right the first time than to go back and rebuild after
you found that something doesn't work the way you need it to.


"John" <?> wrote

"John" <?> wrote

My grandfather said that to plow in a straight line, one had to find a
far off object to aim toward. I think that is the role of the ER
model, a target to focus your aim toward.

"Keith - Recruiter" <ssipositions (AT) yahoo (DOT) com> wrote

What exactly about it keeps one on the straight and narrow?

"dataman" <dataman (AT) ev1 (DOT) net> wrote

" They're really two different things. "

Maybe that's the issue. The data modelling bit seems plausible to me, and I
am happy enough drawing the diagram. I am also happy enough designing a
database, it's just that when I am doing E/R modelling, I find myself trying
to second guess the abstraction in order to ensure that the eventual
relations are sensibly defined. When I'm using it in that fashion, it does
seem pointless. Date (IDS), for example, sees the E/R model as a "set of
informal concepts", while "relations are formal objects, and the relational
model is a formal system". He also (sensibly) suggests that when Codd
constructed the relational model, the "useful semantic concepts" he was
using were "basically ... those of the E/R model". This view seems to
support my belief that E/R modelling is fundamentally informal, something
which questions its very status as a *model*.

Perhaps I just have problems with informal / wooly / subjective things. I
suspect that's why I'm a computer scientist rather than an artist!

John

"John" <?> wrote

Me too.

An ER drawing is not a complete database design like a ground plan is
not a complete building design.

A database design include many aspects (integrity constraints,
derivation rules) that an ER drawing can not express.

I create the logical database design using written Tutorial D.

You can accompain the logical database design with one or several ER
pictures for clarification purposes, but the ER pictures are only
pictures.


Regards
Alfredo

"dataman" <dataman (AT) ev1 (DOT) net> wrote


Logical database modeling is the same as logical database design.

Although some books like Candace & Von Halle use the term "logical
database modeling" for conceptual design.


Regards
Alfredo

I disagree. I usually don't have big problems in seeing referential
constraints, and I don't consider ERD specially helpful in that.

Many people tend to think visually, and for that people ER drawings
are useful, but it is not my case nor the case of other people.


Regards
Alfredo