Re: Entity vs. Table

From: Alan <alan_at_erols.com>
Date: Tue, 8 Jun 2004 12:45:10 -0400
Message-ID: <2im8ooFotdj5U1_at_uni-berlin.de>


See in line...

"ben brugman" <ben_at_niethier.nl> wrote in message news:40c5d6f9$0$4922$4d4ebb8e_at_read.news.nl.uu.net...
>
> > But everyone just uses the term "entity" to
> > mean "entity set", and tuple, row, or instance to mean one instance
> > (example) of that entity set.
>
> If everyone (except a single person) uses the term "entity" for something,
> shouldn't the single person conform to what everyone is using ?

If the person wants to. That's not the point, anyway.

>
> >
> > But back to the difference between an entity and a table - Briefly(?):
> > An entity is a thing of interest in the real world. A table is a
> collection
> > of rows and columns that contain data about the entity (set). An entity
is
> > used on an Entity Relationship Diagram (ERD) to explain the
realtionships
> > among the data. An EMPLOYEE works_for a DEPARTMENT (works_for is the
> > relationship). A CUSTOMER purchases ITEMS. ITEMS make_up an ORDER.
>
> What about things which are not real but get a 'real' meaning in the
> modelling world (sometimes only after a long time or several versions).
> (Things like groupings, relationships etc. which only evolved to 'real'
> things
> because the computer forced the users into this 'kind' of model.).

These are all accounted for in an ERD. It's not a computer that forces the model. The model can exist quite well without computers to implement it. Anyway, it's not a computer model, it's a business model.

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

>
> What I am actually saying that in the actual world (even the one without
> computers)
> it is difficult to define what is an entity and what is not.

That's why data modelers and DBAs get the big bucks. It's almost as much an art as a science.

 In a world with
> computers
> this is even more difficult, because working methods adapt to the
computers
> and
> concepts which were first only part of an artificial world become part of
> the
> real world.
> (Things like internal unique numbers become external clientnumbers in the
> next version
> 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.

>

> just my 2 cents
>
> ben brugman
>
>
Received on Tue Jun 08 2004 - 18:45:10 CEST

Original text of this message