Re: Entity vs. Table

"ben brugman" <ben_at_niethier.nl> wrote in message news:40c9a2db$0$4927$4d4ebb8e_at_read.news.nl.uu.net...
> I do not think a term can be wrong, it's use can be wrong.
> (But before that there has to be agreement on what the term
> means, defines, or represents).
> But if : "But everyone just uses the term "entity" to
> mean "entity set", and tuple, ", they must be right because
> there is nobody to oppose them.
>
> >
> > Only if you want to implement 3NF correctly, so, yes. In some cases you
> have
> > some choices, in other cases there is only one "best" way.
> >
> 3NF dictates no redundancy. Indexes are redundancy.

No they are not. Indexes have nothing to do with 3NF. They are strictly an implementation detail.

So
> most implementations are not 3NF.
> The 3NF term belongs to the domain of the concept, or logical model,
> not to the implementation.
 For complex situations there often are loads
> of 'best' ways, for the logical model as wel as the implementation.
>
> But I do understand your desire to keep the implementation as
> close as possible to the logical model. (I do not see this as an
> requirement).
>

It's not a requirement, but it is a starting point. If you start with a 3NF physical model, you can denormalize for the sake of performance.

> >
> > There are definite rules to convert an ERD (your logical design) into
> tables
> > (the physical implementation) to achieve 3NF, but you obviously don't
know
> > about them.
> >
> Sorry, here the language problem creeps up. With rules I meant 'binding
> rules',
> not rules as 'guidelines'.

Again, there are definite rules to get to 3NF, and some of these rules include a choice.

>
> >
> > I made that up. Don't believe everything you read, especially on the
> > internet.
> >
> There is no problem with you making up an example. Examples (real or
madeup)
> can be used perfectly to illustrate something.
> Except that this example did not illustrate your point.
>
> >
> > An arificial key. So what? Sometimes you need one. There are lengthy
> > arguments on both sides as to whether or not to use a natural key (if
> > available), or to always use an artificial key.
> >
> Do you mean an artificial key. (Like ISBN, social security number)
> This is by no mean meaningless (to me and most others).
> Or
> Do you mean a surrogate key. (Totally internal not to be communicated to
> the outside world).
> (The surrogate key if viewed on it's own does not hold information).

Surrogate key. I use the terms "artificial" and "natural". In my definition, SSN or ISBN is a "natural" key, because it has meaning. An artificial key, would be your surrogate key. I'm not dogmatic about it, though. It just has more meaning to me. I've heard both sets of terms used.

>
> >
> > > Before computers, information that was written down (or kept in any
> other
> > > form), there was no real distinction between 'the holding of
> information'
> > > and
> > > the 'presentation' of information.
> >
> >
> > Not true, actually. Before the general population knew how to read, the
> > "priests" of knowledge routinely distorted data to enhance their own
> power.
> > Enter organized religeon (just ask Galileo) - but that's a real big can
of
> > worms.
> >
> What is your point here. I allready made that exception :
> >
> > (Except of encription to make the
> > > information
> > > only accesable for the 'intended' users).
> > >
>

Semantic argument. "Accesable for the 'intended' users (sic)" implies taking clear data and obfuscating it- at least to me.

> >
> > In this forum, it is important to distinguish between the business
model,
> > the logical model (there is much overlap, though), and the physical
model.
> > Entities belong to the first two, tables to the last. In this case, it
is
> > important to distinguish what is right from what really happens to avoid
> the
> > confusion you wrote about.
> >
> I do agree with you.
> It would be nice to have definitions for these terms which are usable and
> understandable by most.
>
> A TRY :
> Physical datamodel is a model of the
> database implementation ? (The databasemodel).
> (Can contain redundancy does not have to be like the
> logical datamodel, but MUST implement the logical model).

Yes and no. There should be no redundancy, or it is not a propely implemented 3NF relational database. Otherwise, yes.

>
> Logical datamodel is describing the data in at least
> 3NF (with no redundancy) and
> should be implementing/describing the business model.

Yes.

> An ERD is often used to describe part of the logical datamodel.
>

A logical data model follows after the ERD, so I would say no to this part.

> Business model is a description of the problem / solution / a desired
> solution / a desired description of the 'real' world.
> (There is no requirement how the business model is described.
> Sometimes an ERD is used for a part of the business model).

Yes, with one small change. An ERD is a conceptual business model of the data and the realtionships(associations) among the data.

>
>
> just my 2 cents
> ben brugman
>
> >
>
>
Received on Fri Jun 11 2004 - 16:27:30 CEST