Re: Entity vs. Table

From: Alan <not.me_at_uhuh.rcn.com>
Date: Mon, 14 Jun 2004 23:01:27 GMT
Message-ID: <b7qzc.27464$wi2.9450_at_nwrdny01.gnilink.net>


"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:40cdde00.28454475_at_news.wanadoo.es...
> On Mon, 14 Jun 2004 11:15:22 -0400, "Alan" <alan_at_erols.com> wrote:
>
> >> So, an implementation of a 3NF logical design migth have redundancy.
> >
> >Those are your words, not mine. There should be no redundancy in a
properly
> >implemeted 3NF design
>
> If you mean that there should not be redundancy in the physical level
> it is a striking statemen!

Not what I mean at all. "Properly implemented" means tables that contain the proper attributes.

>
> Why not?
>
> All the books I readed say the contrary.
>
> > 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.

You're going to have to prove that one.

>
> >> For instance this very simple rule: the stock of an article is the
> >> initial stock plus the inputs minus the outputs.
> >>
> >
> >That is an aggregation and fits on an ERD with no problem.
>
> How?
>

Depends on the taxonomy you use. The one I am familiar with works like this:

An entity is represented by a rectangle (of course). "Attached" to the rectangle are the attributes. These are encased in small ovals.
Derived attributes (such as an aggregation) are encased in a double oval.

> > The underlying
> >calculation does not belong on an ERD- it is an implementation detail.
>
> My example is a logical integrity rule. The implementation is
> irrelevant in this context. We are talking about the logical model.
>
> That rule is very easy to declare with a relational language.
>
> Another example: No supplier with status less than 20 supplies any
> part in a product with quality extra.

I am not sure what you mean here (language problem).

>
> >> I can start directly whith a relational design without wasting time
> >> with a very limited sketch.
> >
> >So can I, and I often do, but I've also been burnt by not creating an
ERD.
>
> I never had problems.
>

Then you are perfect. Congratulations.

> >Relationships among data that you may not otherwise anticipate often
reveal
> >themselves in an ERD, especially with specialization/generalization.
>
> Relationships among data are database relations also known as tables.
>
> The relational model is the best way to represent relationships among
> data, and it does not have the problems of ERD, like the arbitrary and
> artificial distinction among entities and relationships (there are
> only relationships), and it has a lot greater expresive power.

My motto: "Whatever works." If it's working for you, fantastic. I'll use what works for me. We'll have to agree to disagree, I think.

>
>
> Regards
> Alfredo
>
Received on Tue Jun 15 2004 - 01:01:27 CEST

Original text of this message