Re: Entity vs. Table

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:40cf23aa.24819548_at_news.wanadoo.es...
> On Tue, 15 Jun 2004 08:24:39 -0400, "Laconic2" <laconic2_at_comcast.net>
> wrote:
>
> >Instead of scorning those people who did not scrap ERD, you would do
well
> >to learn from them.
>
> I don't see what I can learn from them.
>
> >I can't speak for Alan, but to me the principal value of ERD is
> >communication with the SME's.
>
> Whan an SME is?

I would think he was referring to subject-matter experts.
>
> Small and Medium size Enterprise?
>
> >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
>
> I completely disagree. You can communicate a lot more precisely with a
> relational design because it is a lot more expressive. ERD is a toy
> language.

Communicating MORE is not necessarily helpful in those situations where using an ERD is effective. We want to communicate more clearly and collect useful information rapidly.

If you look at the relational model, you see that whether "an entity" turns into a base relation, an attribute, a value, a schema, a view, etc has to do with the relationship of that noun to others. The end-user never needs to care whether a noun ends up as anything in the actual system, much less whether that something is a relation or an attribute.

When the user starts talking about the subject, they will toss out nouns and relate them. Later some of these could turn out to become attributes in a base relation or relations themselves, but to start with, they are just parts of sentences being tossed out. Putting nouns in bubbles and their relationships to each other in diamonds is an amazingly effective and simple tool for collecting information prior to relational modeling. It is particularly useful in the requirements-gathering process.

> >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.
>
> It is a lot easier to teach The Relational Model to the subject
> experts, and they will be able to implement or to check what they want
> with a little fraction of the effort needed if they used the archaic
> and primitive Pick.
>
> Pick is good only for things like a phone list.

Tell that to the developers of Teradata (among other significant places where Pick can be found).

> >You need both subject matter expertise and IT expertise to build either a
> >good database or a good application.
>
> And ERD does not help for this. The IT expert will think that he
> understands the problem but he only understands a part.

An ERD is not used to gather ALL requirements -- there are many tools, but it is a solid tool in the toolkit of most systems analysts. I'm thinking that perhaps you are a designer and developer but not an analyst?

> The subject matter experts don't know ERD, but most of them already
> know predicate logic and set theory. I prefer to teach them The
> Relational Model than ERD. With ERD most rules will not be captured
> causing a lot of communication problems.

I've never taught subject-matter experts ER -- I just use it and they catch on handily. The fact that it is used to capture less than everything is not a failing at all. It is but one tool in the analyst's toolkit, but one that is amazingly powerful considering its extent.

> > 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.
>
> In my experience it is often easier to teach The Relational Model to
> the subject experts than to teach it to the IT "experts".

Because IT folks ask "why"? ;-)

> > Maybe these cases are where Pick,
> >and products like it, do their best.
>
> No, Pick is a very limited archaic toy. Here is where The Relational
> Model does 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.
>
> ERD promotes volleyball because the subject matter expert can not
> communicate the requirements to the IT expert and the IT expert can
> not know the subject matter with detail. This leads to a long and
> painful iterative process.

I can imagine that if an ERD is used to communicate design this could become an issue.
cheers! --dawn Received on Tue Jun 15 2004 - 21:52:11 CEST