how to identify a weak entity ?

[saleemMSMS]

how can we identify a weak entity ??
is all the weak entities have a 1:1 relationship with their owning entity ?
how can we distinguish a weak entity with a normal entity ?
can a weak entity have strong relationships with other strong entities except the owning entity ?
please answer those questions


and also please consider this scenario

a village has population data one village has one set of population data
a village has a village committee one village has one village committee. the village committee participates in training
a village has one producer group one producer group the group belongs to one village
the producer group hosts events one producer group may host several events where a given event is hosted by only one producer group.

what are the weak entities and why are they weak entities ?
what are the strong entities and why are they strong entities ?

 

[DCrake]

Which exam does this question come from Hey we are not that easily fooled. Either RTFM() or STFW() will get you the answer.

David

 

[saleemMSMS]

WTF ????
u call urslef an Administrator ?? have F-ing Manners please... this is not from an Exam u idiot... this is a F-ing practical problem !!

 

[namliam]

LOL F-ing all over the place... RTFM? Guess I should pick up a manual, I have been working with databases for years but have never heard of a "weak entity" ??
WTF is it?

 

[saleemMSMS]

DCrake, ma man, sorry dude.. i was little pissed off... ok ok cool man... cool !!
i take it back ma man..

@namliam > havent heard about weak entities ???????? OMHG !!
http://en.wikipedia.org/wiki/Weak_entity

 

[namliam]

how can we identify a weak entity ??
is all the weak entities have a 1:1 relationship with their owning entity ?
how can we distinguish a weak entity with a normal entity ?
can a weak entity have strong relationships with other strong entities except the owning entity ?
please answer those questions

Looks like you found your answers on wiki?

Also I dont realy see how a "weak entity" would be any different form a normal entity or why it might be a problem you need to know about?
It seems a natural product of normalization (Order > Orderitem, where order item is a weak entity?)

 

[Atomic Shrimp]

I've never heard of weak entities either (not that I'm any kind of expert). Looks like it's something that depends entirely on its foreign key to relate to the parent table or other tables (i.e. can't be reliably related by meaningful values in the data).

Given that meaningless foreign keys seem (rightly, IMO) to be everybody's favourite here, I'm not surprised this topic is unfamiliar.

 

[Access Hero]

You can identify a weak entity on a logical diagram a couple of ways.

One is to look at the shape and boldness (square/rectangle and bold) of the box representing the entity. Also, the lines/diamonds will be bold.

The other is to look at the key and see if it contains an FK.

These things will look slightly different depending on what tool you are using.

Now you didn't say that you wanted to be able at design time to determine whether an entity should be weak or strong. Frankly, it doesn't matter too much. Make your unique keys unique using whatever attributes/columns will make it unique or that uniquely identify the object in question.

 

[dportas]

Strong / Weak Entity is part of ER modelling terminology rather than relational design theory.

Consider a relation with two candidate keys: A and B. A is also a foreign key. Now according to ER modelling convention if A is selected to be the "primary" key then it's a "weak" entity; if we call B the primary key then it's a "strong" entity. Yet the form, function and meaning of the relation is exactly the same in both cases! That is why I have my doubts about the relevance of this particular ER modelling concept to relational database design.

 

[MarkK]

Aren't there about four weak entities in a month?

 

[boblarson]

Funny how I've been doing database development for 13 years and never once came across the terms strong/weak entity until today. The question certainly did sound like a question from some sort of course, rather than out of real life. But then again, I do not follow strict modeling structures either. <lol>

 

[georgedwilkinson]

The topic is mostly useless. It's a way of snobby data modelers to try to outdo each other.

 

[boblarson]

The topic is mostly useless. It's a way of snobby data modelers to try to outdo each other.

That makes sense to me; like an Access person who knows AND can describe the 4th and 5th level normalization rules, right?

 

[dportas]

Funny how I've been doing database development for 13 years and never once came across the terms strong/weak entity until today.

If you haven't acquired it through education and study then what vocabulary you use may depend on what tools and techniques you have worked with. The concept of Weak/Strong entities and their corresponding Identifying/Non-identifying relationships exists in Object Role Modelling, in Chen, Barker and IDEF1X notations and in UML.

But then of course there are also those silly pictures used in Access as a pathetic excuse for a data model. Obviously that's purely a Microsoft invention and it has nothing to do with any industry standard notation or vocabulary. It is shocking that screenshots of Access-style diagrams have even crept into a few books that claim to teach data modelling. Microsoft (and bad authors) have a lot to answer for if their users end up learning only rubbish like that (I don't mean to assume that applies to you by the way).

Rant over. I do in fact agree that the Strong / Weak distinction is of negligible value at the database level. I think the point is that data models usually have to work on multiple levels - as a source document for data architects, database developers and OO programmers as well.

 

[boblarson]

A reasonable explanation and it is all good. It really does depend on what you've been exposed to, what your training is in, and whether or not you are going to use it. As for me, if the distinction between strong and weak entities deals with the use of one over the other as a primary key, I will be outside of all of it as I never use natural keys; only surrogates. So, I would probably be considered anathema by true data modelers.

 

[The_Doc_Man]

I looked at the Wikipedia article for a long time before I came to this conclusion.

how can we identify a weak entity ??

In a properly normalized database in most non-trivial cases, all child entries (on the child side of a 1:m relationship) are weak. (Because the weakness is related to whether the m-side entry contains all of its attributes or whether you need to do JOIN or LOOKUP to parent for some attributes.)

is all the weak entities have a 1:1 relationship with their owning entity ?

I would say no. In fact, 1:1 relationships in most databases must be considered rare, the only practical cases I recall having to do with whether the table in question has some fields with different security requirements than other fields. The other case is when you have such a large number of attributes (fields) that you need to partition the table into three or more parts, only two of which are ever in use at once.

how can we distinguish a weak entity with a normal entity ?

Do you need to do JOIN or LOOKUP on a parent to determine that item's complete set of attributes? The entity is weak if you answer yes.

can a weak entity have strong relationships with other strong entities except the owning entity ?

I tend to think not. The condition of not containing all of its attributes would not be changed by establishing other relationships. If you have to look up the extraneous attributes, it doesn't matter through which relationship you got to the weak item.

Dportas: In your example with a record with two candidate keys, A (=FK) or B (=independent key), doesn't this imply two things?

1. The relationship of this table to the parent (where A is the PK) must be either 1:1 or 1:1-sparse, because in Access an FK must be a PK on the other table. So if A by itself is a candidate, it must be unique in the second table and it is KNOWN to be unique in the first table where it is PK. Which means you have already established that this is a segmented table.

2. Doesn't the presence of B in this table, taken together with the fact that A=FK to another table, mean that either B must also be present in the parent or that it really should not be a candidate (if it doesn't apply to the first table?) And further, doesn't it suggest - if not actually require - that A is a surrogate key whereas B might be a natural key? (Otherwise they would not be different.)

 

[dportas]

As a rule I disregard anything on Wikipedia. Peter Chen (the inventor of ER modelling) defines a weak entity type as one whose identifying attributes include a relationship to another entity. The fact that a non-key attribute is a foreign key or exists in another table does not make a weak entity.

Dportas: In your example with a record with two candidate keys, A (=FK) or B (=independent key), doesn't this imply two things?

The textbook definition (in the books I have read) is that a weak entity is being represented whenever a foreign key is a subset of a primary key. The point of my example was simply to show how arbitrary this distinction can be since primary keys have no special significance and no practical consequences in the relational model - all candidate keys are equal. I hadn't meant to imply anything else about those keys and I don't see what difference it makes, but maybe I'm missing the point of your questions.

 

[The_Doc_Man]

If all you meant to convey was just how arbitrary those definitions were, you succeeded and I understand. Even agree with you. Strongly.