Re: Weak entity types

From: beginner16 <kaja_love160_at_yahoo.com>
Date: Tue, 14 Aug 2007 11:00:48 -0700
Message-ID: <1187114448.792926.236720_at_r34g2000hsd.googlegroups.com>


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.

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

 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.

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

> > 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:00:48 CEST

Original text of this message