Re: Entity vs. Table

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

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

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

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

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

Logical datamodel is describing the data in at least 3NF (with no redundancy) and
should be implementing/describing the business model. An ERD is often used to describe part of the logical datamodel.

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

just my 2 cents
ben brugman

>
Received on Fri Jun 11 2004 - 14:17:53 CEST