Re: erd to db
Date: Wed, 27 Mar 2002 20:33:39 -0800
Message-ID: <MMwo8.117$pV.116516_at_news.uswest.net>
"Jan Hidders" <hidders_at_uia.ua.ac.be> wrote in message
news:3c9f223a$1_at_news.uia.ac.be...
> "Daniel Guntermann" <guntermann_at_uswest.net> wrote in message
> news:Fa_m8.6$JN1.10619_at_news.uswest.net...
> >
> > "Jan Hidders" <hidders_at_uia.ua.ac.be> wrote in message
> > news:3c9af4b6$1_at_news.uia.ac.be...
> > >
> My point was that we are talking about a *weak* entity type here. An
entity
> type is weak if it doesn't have enough attributes of its own to identify
its
> entities. Of course you can extend the notion of key such that you can
also
> include the involved weak relationsips but as far as I know that isn't
> usually done.
Again, probably a matter of definition and/or point of view, but I've often been exposed to the concept of the 'weak' entity in the data modeling sense as an entity that is entirely dependent on the existence of some other entity(s). The example I'm most familiar with is the relationship between 'Employee' and 'Dependent' entities (from Date's Intro to Database Systems 7th Ed., I think). I've even heard the semantics-oriented debates on whether this definition is really robust enough considering that, technically speaking, even if an Employee is removed/deleted/killed off, his or her dependents (in the real world) really don't cease to exist (and a System might have a compelling reason to keep them). However, in cases where there is a dependency that needs to be enforced, then, according to at least some authors, the 'Dependent' is a weak entity.
Interestingly enough, I've never the definition of a weak entity as one that "does not have enough attributes to identify its own entities." I'm not sure I understand this concept. Could you elaborate, or point me towards a valid authoritative source document?
<snip>
>
> I beg to differ. It is not true that a relationship *is* or *can be* a
> relation. What is true is that it *can be implemented* or *modeled* as a
> table.
I thought a relation was synonymous, at least at some levels, with a table...Don't you agree? A view or even a basic SELECT statement could also return the representation of some entity (or relationship :-) ) - thus I've used the term relation to avoid being pinned to one logical construct, such as 'table'.
Additionally, an entity in the mind of someone at the user level will not necessarily always translate to a table as a one-to-one mapping. I can think of several examples. A relatively complicated one might be a representation of the purchase order *relationship*. Some might model this as the multiple associations, such as a single supplier (header with date, etc.) and parts/items (po lines), where actual data elements are derived from several different tables. The actual representation of this entity might be materialized as a table, or as a view (but in either case as a relation).
>
> Kind regards,
>
> -- Jan Hidders
> > >
Thank you for the comments and perspective. I hope you'll forgive my semantic sniping.
Daniel Guntermann Received on Thu Mar 28 2002 - 05:33:39 CET