Re: Entity vs. Table

Replies in line...

"ben brugman" <ben_at_niethier.nl> wrote in message news:40c8533d$0$4923$4d4ebb8e_at_read.news.nl.uu.net...
>
> >
> > If the person wants to. That's not the point, anyway.
> >
>
> You are 'trying' to make a definition and telling in the same sentence
> that "But everyone just uses" the term not conforming to the definition.
> This makes the definition not very practical. For me that is a point.
>
> In some countries everybody is driving on the WRONG side of the
> road, if you are driving there I would advise to do the same.
> (You might even practise driving on the wrong side while still at
> home, allthough that might be less practical :-)
>

There is what is right, and there is what really happens. It's great when their the same, but often they are not. Sometimes going with what really happens is more efficient and causes no harm.

> >
> > >
> > > Or what about things which are less real, but are percieved real by
most
> > > people, for example a 'relationship', is this an object, an entity, or
a
> > > relation.
> > >
> > > The entity I have borrowed this book from that library. Or is it the
> > > registration
> > > off that fact. Is a fact an entity ? Or an attribute and from who ?
> >
> >
> > That is not an entity. It is a relationship. In fact, it is a M:N
> > relationship with optional participation on both sides. A book can exist
> > without being borrowed, and a card_holder can exist without borrowing a
> > book. LIBRARY_CARD_HOLDER(S) borrow(s) BOOK(S). It will eventually be
> > converted into three tables.
> >
>
> Real people (outside the 'automation' department) see this as a "Thing of
> interest".
> This "Thing of interest" holds information not held by any other 'entity',
> attributes
> like startdate and returndate. (For historical and statistical purposes).
> As a modeller I see the thing as a "Thing of interest" having attributes
and
> relations
> with other "Things of interest" (Objects to lend (books, cd's) and
> persons/institutions).
> This might be implemented in three tables, but why will it be converted to
> three tables.
> Is there a required mapping from entities to tables ?

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.

> Other mappings than three tables are quite possible and valid. There is no
> rule
> that two set entities can not be implemented in the same table. There is
no
> rule that
> one set of entities has to be implemented in one table.

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.

>
> My point is that if we can have a disagreement over an example as above,
> (not agreeing what the entities are),
> which is realy a simple example, for real complex situations, there are
lots
> of
> opportunities to come with different models, which are not in agreement
> with eachother but aren't wrong either.

Certainly.

>
> If there is more than one interested party, then those parties might have
> different
> models, none of them being wrong, but neither of the being in agreement.
> The choice of which model is choosen (if one is choosen) is often made by
> influential person, but not always by knowledgeble persons.

Unfortuantely, true.

>
>
>
> > > and therefore an entity for the next generation of modelers)
> >
> > This happened long before computers. SSNs were around well before. So
were
> > serial numbers. Computers have nothing to do with it. BTW, did you know
> that
> > the first Roman soldier's ID number was MCMXLVII? This way, if the
soldier
> > was captured, the enemy wouldn't know that there were really only CCCL
> > soldiers in the army.
> >
>
> The moment the numbers are used outside the computer they have meaning
> outside the computere and are therefore not meaningless. Your example
> of the Roman's soldier's ID even shows an intended meaning to deceive
> others.

I made that up. Don't believe everything you read, especially on the internet.

A meaningless number can be exchanged for any other number
> (or identification) as long as everywhere it is registered within the
> computer
> the change takes place there is no difference. Once the number is
> outside the computers 'control', this change is not feasable anymore.
>

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.

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

(Except of encription to make the
> information
> only accesable for the 'intended' users).
>
> With computers the holding of information can be very different from the
> presentation of information. The same information can be kept in very
> different ways. Even with a know presentation of information, there still
> is a lot of freedom to model the information.
>
> Businesses and business rules change because of automation.
> Often an automated 'solution' becomes the busines model for the
> next generation solution.
>
> But yes I do agree that an 'Entity' and a 'Table' are two different
> 'things off interest', but because 'Entity' is (for most people) so vague,
> people tend to talk more about the implementation of the entity
> which is (can be) the table, because that is more concrete.
> (Hence the confusion.)
>

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.

> > > just my 2 cents
> ben brugman
>
>
> >
> >
> >
> > >
> > > ben brugman
> > >
> > >
> >
> >
>
>
Received on Thu Jun 10 2004 - 15:44:45 CEST