Re: erd to db

From: Jan Hidders <hidders_at_uia.ua.ac.be>
Date: Thu, 28 Mar 2002 15:11:37 +0100
Message-ID: <3ca32423$1_at_news.uia.ac.be>


"Daniel Guntermann" <guntermann_at_uswest.net> wrote in message news:MMwo8.117$pV.116516_at_news.uswest.net...
>
> 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).

Yes, that is a definition that is often given, and even in the better data modeling books, but it is also a cumbersome one. Let me try to explain this. As you already said yourself, it is not always exactly clear whether this is true or not. The most unambiguous interpretation is that if an entity type A is weak then for every A there must be a corresponding B. However, this is something that we already can indicate by making the relationship between A and B total for the side of B. So that would make the notion of weak entity a redundant one. So why was this notion introduced then? If you look at Chen's original paper you see that he starts his section on this subject with the following motivation: "In certain cases, the entities in an entity set cannot be uniquely identified dy the values of their own attributes; thus we must use a reationship(s) to identify them." This is very important since this means that when he maps the entity set to a table (what he calls its representation at level 2) he has to include the primary keys of other entity sets in the table for this entity set. So you see that this notion is not only less ambiguous, it is also not redundant, and it is very relevant for how you map your model to the relational model.

Note, by the way, that this definition of weak entity is a stronger version of the other definition: if you can only identify A with some of B's attributes then clearly there must be a corresponding B for every A.

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

Off the top of my head I can only think of the book "Fund. of database systems" by Elmasri and Navathe. But I assume that Chen is probably also a good reference, right? :-)

Let me give you a small example. Let's say we have entity types ORDER and LINE where an order consists of several lines that describe each how much was ordered of a certain article. The relationship between ORDER and LINE is indicated bya ORDER-LINE relationship. The attributes of LINE will be something like 'line number', 'article code' and 'amount'. All these attrbutes are not enough to identify a line because two lines in different orders might have the same values for these attributes. What is missing here is an attribute like 'order number' but that is not an attribute of LINE but of ORDER. So you see that the entity type LINE does not have enough attributes and you should include the primary key of the table for ORDER when mapping it to a table.

> I hope you'll forgive my semantic sniping.

The smiley wasn't added for nothing. :-)

  • Jan Hidders
Received on Thu Mar 28 2002 - 15:11:37 CET

Original text of this message