Re: Entity vs. Table

On Tue, 15 Jun 2004 14:52:11 -0500, "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote:

>> Whan an SME is?
>
>I would think he was referring to subject-matter experts.

Thanks.

>> 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.

I don't think that those situations are frequent.

I can't imagine situations where referential constraints are important and the rest of the constraints and derivation rules are not.

> We want to communicate more clearly and collect
>useful information rapidly.

And you can not collect the most part of the fundamental information with ERDs.

>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.

If you look at the relational design model you will see logical predicates and not entities.

> 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.

The user and the IT profesional need to understand the logic of the database, and ERDs don't help a lot.

>When the user starts talking about the subject, they will toss out nouns and
>relate them.

And we can build the database predicates using those nouns and the relations among them.

> Later some of these could turn out to become attributes in a
>base relation or relations themselves

Why not in the begining?

The Relational Model is the best way to relate those nouns creating logical predicates.

Attributes are like nouns and relations are like sentences. Sentences relate nouns like relations relate attributes.

The ERD is extremely poor for that.

>, 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.

Why?

> It is
>particularly useful in the requirements-gathering process.

Why?

>> 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).

I would like.

>> 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.

It is extremely limited and not very solid. The distinction between entities and atributes is informal and arbitrary.

>> 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.

Then you never used ERDs to communicate.

>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.

Something with a tiny "capturing" power can't be amazingly powerful.

What is amazingly powerful is a good relational design.

>> 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"? ;-)

No, because IT folks need to unlearn many many misconceptions before they can start to learn what The Relational Model really is.

Like Dijkstra would say: you have to repare the brain damage first, and in many cases it is almost impossible.

Regards
  Alfredo Received on Thu Jun 17 2004 - 11:34:26 CEST