Re: Entity vs. Table

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

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

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.

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.

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

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

> > just my 2 cents
ben brugman

>
>
>
> >
> > ben brugman
> >
> >
>
>
Received on Thu Jun 10 2004 - 14:25:55 CEST