Re: Entity vs. Table

From: Laconic2 <laconic2_at_comcast.net>
Date: Tue, 15 Jun 2004 08:24:39 -0400
Message-ID: <n8mdnUrX9LSzd1PdRVn-gw_at_comcast.com>


"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0406150243.6ba141da_at_posting.google.com...
> "Alan" <not.me_at_uhuh.rcn.com> wrote in message
news:<b7qzc.27464$wi2.9450_at_nwrdny01.gnilink.net>...

> > Then you are perfect. Congratulations.
>
> No, but I don't see value in ERD.
>

Just because you don't see the value in ERD doesn't mean the value isn't there...

Going back a couple of posts, we see this exchange between you and Alan,

>> And wrong. If it was true, the ERD would
>>have been scrapped years ago.

>ERD was scrapped decades ago by many people, but many poor practices
>survive for a very long time.

Instead of scorning those people who did not scrap ERD, you would do well to learn from them.

I can't speak for Alan, but to me the principal value of ERD is communication with the SME's. That's two way communication, by the way. My ERD is my reaction to the business requirements. Their reaction to my ERD can be a much needed correction to the data analysis at the stage where it can still do some good. It isn't just "presentations" on my part. It's what I can learn as much as what I can teach. And an ERD communicates more effectively in this context than an RD

If I contrast my own experience in building successful and useful databases with the scenarios Dawn outlines about subject matter experts becoming learning enough IT to implement what they want in Pick, the salient point is NOT the difference in data models. It's the difference in how the gap between subject matter expertise and IT expertise gets bridged.

You need both subject matter expertise and IT expertise to build either a good database or a good application. In cases where the subject matter is easily learned, the IT expert can proceed directly to design without cross checking analysis. Maybe in these cases, an ERD is superfluous.

In cases where the IT expertise is easily learned, the SME can learn what's needed, and implement the right thing. Maybe these cases are where Pick, and products like it, do their best.

In cases where neither the subject matter nor the required technology are easily learned, and no one knows both of them a priori, it gets interesting. This is where we start to play volleyball. Received on Tue Jun 15 2004 - 14:24:39 CEST

Original text of this message