Re: Entity vs. Table

"ben brugman" <ben_at_niethier.nl> wrote in message news:40cd9655$0$4922$4d4ebb8e_at_read.news.nl.uu.net...
> On most I do agree with you.
>
> We have some differences.
> For me a fysical model (a term I try to avoid) is the
> model which represents the fysical implementation.
> The closer the model describes of what it is, the more
> detailed (and sometimes better) the model is.
> But I prefere to use the fysical implementation, because
> I know what the fysical implementation is.
>
> But it seems that you use the 'fysical model' as
> a model which is made from the logical model
> before implementation is made.

You create the logical model, and then following specific transformation rules (which also contain options where applicable), you trasform the logical model into a physical model. You can then implement the physical model. For example:

You start with business requirements, which you turn into an ERD. You then follow the rules referred to above, to turn it into an actual relational schema. This is the physical model. The physical model contains all of your tables. Now that you have this, you implement it in your RDBMS using SQL.Then you add indexes as needed.

>
> The fysical implementation, normaly does have
> indexes, errorchecking bits and is often implemented
> on a Raid. Therefore the implementation contains
> redundancy. The fysical implementation therefore
> is not 3NF, although it often is an implementation
> of a logical model which should be 3NF.
>
> (By the way, indexes (which can be rebuild) are
> definitely redundant information).
>
> ben

I've been nice up till now, but I'm sorry- you clearly do not know what you are talking about. 3NF has nothing to do with RAID, error checking bits, or anything else that is not data. Indexes are not redundant information. They are references. Indexes are analagous to looking in the index of a book. You look there to get a specific place to look in the book. If indexes were redundant, they would serve no purpose. Indexes are part of the physical implelmetation, and have zero to do with the logical model, which is where you establish 3NF.

>
>
> "Alan" <alan_at_erols.com> wrote in message
> news:2ittqgFqitf3U1_at_uni-berlin.de...
> >
> > "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 Mon Jun 14 2004 - 15:16:27 CEST