Re: Weak entity types

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 14 Aug 2007 15:35:42 -0300
Message-ID: <46c1f5c1$0$4052$9a566e8b_at_news.aliant.net>


beginner16 wrote:

> uh, confused
> 
> On Aug 12, 3:01 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> 

>>beginner16 wrote:
>>
>>>hello
>>
>>>a)
>>>Weak entity type cannot be uniquely identified by its own attributes
>>>alone and thus needs another entity to be uniquely identified.
>>
>>I suggest you stop and question the above statement.
>
> I'm just quoting from a text.

Are you suggesting one should never question the content of texts?

>>>So in relational model, every relation which has primary key made of
>>>foreign key and perhaps some other attribute, is weak entity type?
>>
>>Basically, yes.
>>
>>
>>>Ok, but I could instead of creating a foreign key create another
>>>attribute which could uniquely identify rows in a table. By
>>>definition the relation would no longer be weak entity type --> there
>>>has to be more to this --> perhaps it’s more of a subjective thing?!
>>
>>The original definition you give above is absurd on its face. To be a
>>relation, one must be able to uniquely identify each of its tuples by value.

> 
> I'm not sure I understand what you are trying to say. Above I stated
> that if we have weak entity type, then we could create another unique
> attribute ( and make it a part of that weak entity type ) just for the
> purpose of uniquely identifying tuples --> in short we would make this
> attribute a primary key --> then the definition of weak entity type
> would no longer describe this relation.

Exactly, and I gave an example of adding an arbitrary lookup table to the schema suddenly turning a so-called strong entity into a so-called weak entity.

> But on the other hand entities describe real world objects and if an
> existence of some type of object ( call it A ) in real world depends
> on the existence of objects of another type, then  A  should be
> considered weak, regardless of whether A type object can uniquely be
> identified by its own attributes or  with the help of compound primary
> key ( made from foreign key )

If I have a relation that describes properties of relations, does it describe a 'real world object' ?

An attribute doesn't make sense without the existence of some relation type or tuple type just as an order line item doesn't make sense without an order.

>  And that is what is confusing me the most --> we can make real world
> objects ( which we could consider weak  ) strong by just adding some
> attribute and making that attribute primary key. Entity type  Weak
> entity type should be considered weak, if its existence depends on the
> existence of entity of another type, and not whether part of its
> primary key consists of foreign key.

I agree. But then I suspect every entity will be weak at some level of consideration. The hypothetical entity I introduced that was partially described using a two-letter country code cannot really exist unless a country entity exists regardless whether the entity gets expressed within the dbms. And conceptually, of course, the country entity does exist even if we do not include it in our E-R diagram.

A problem always arises when levels of discourse mix. Defining "weak entity", which is a conceptual level construct, on the basis of keys, which are logical level constructs, is no doubt a mistake. Of course, you may be required to reliably reproduce the mistake on your final exam.

>>>Meaning two tables can both have compound primary key, but one table
>>>could be considered weak and other strong entity type, based on how
>>>the person creating the two tables would perceive the world?! Can you
>>>show me an example?
>>
>>I think the statement is wrong.
>>
>>
>>>If so, aren’t there some regulations that would in more objective way
>>>define when an entity is weak and when strong ( assuming entity has
>>>compound primary key in both cases )
>>
>>The distinction is arbitrary in the first place. Consider for a moment
>>an application that has a two-letter country code as a component of a
>>compound key. After several years in service, people complain they can
>>never remember whether England should be UK or GB so a lookup tables is
>>added to the dbms with a foreign key.
>>
>>The original relation is still the exact same relation with exactly the
>>same values and exactly the same external predicate. How does adding the
>>lookup table weaken it?

> 
> If that new foreign key is now part of a compound primary key, then
> the definition of weak entity type says the table is weakened ( though
> that doesn't make sense to me either ).

The whole E-R business is pretty fuzzy and generally arbitrary. But if the text defines the terms, then within the scope of the text, the terms are well-defined. If you are to be tested on the text, then you need to learn how the text defines them. At least, you are smart enough to grasp some of the limitations and to see beyond the scope of the text.

>>>b)
>>>Looking at few E-R diagrams I noticed that attributes being drawn for
>>>particular entity type ( entity type is drawn as rectangle ) often
>>>don’t include an attribute acting as foreign key 
>>>I’d understand if this entity type was weak entity type and thus would
>>>include foreign key attribute only when E-R model was converted into,
>>>say, relational model, but in the examples I saw the entity type
>>>wasn’t represented as a weak type. So when do we also draw foreign key
>>>attributes and when not?!
>>
>>I do not use ER diagrams of any flavour so I cannot really say. Perhaps
>>someone familiar with the text you are using will have answers more
>>relevant to your immediate needs.
Received on Tue Aug 14 2007 - 20:35:42 CEST

Original text of this message