Session 2 Welcome: The fifth learning sequence “ Entity-Relationship Model -2“ E-R Model Recap : In the previous learning sequence, we discussed the introduction to E-R model. Present learning: We shall explore the following definitions: - Keys in E-R MODEL. - Weak Entity. - Design techniques.

Entity-Relationship Model 2 Keys Weak entity sets

Keys A key is a set of attributes for one entity set such that no two entities in this set agree on all the attributes of the key. It is allowed for two entities to agree on some, but not all, of the key attributes. We must designate a key for every entity set.

Keys in E/R Diagrams Underline the key attribute(s).

Example: a Multi-attribute Key dept number hours room Courses Note that hours and room could also serve as a key, but we must select only one key.

Keys A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity. A candidate key of an entity set is a minimal super key Customer-id is candidate key of customer account-number is candidate key of account Although several candidate keys may exist, one of the candidate keys is selected to be the primary key.

Participation of an Entity Set in a Relationship Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set E.g. participation of loan in borrower is total every loan must have a customer associated to it via borrower Partial participation: some entities may not participate in any relationship in the relationship set E.g. participation of customer in borrower is partial

Participation of an Entity Set in a Relationship

Weak Entity Sets Occasionally, entities of an entity set need “help” to identify them uniquely. Entity set E is said to be weak if in order to identify entities of E uniquely, we need to follow one or more many-one relationships from E and include the key of the related entities from the connected entity sets.

Example name is almost a key for football players, but there might be two with the same name. number is certainly not a key, since players on two teams could have the same number. But number, together with the Team related to the player by Plays-on should be unique.

In E/R Diagrams name number name Plays- on Players Teams Double diamond for supporting many-one relationship. Double rectangle for the weak entity set.

Weak Entity-Set Rules A weak entity set has one or more many-one relationships to other (supporting) entity sets. Not every many-one relationship from a weak entity set need be supporting. The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets. E.g., player-number and team-name is a key for Players in the previous example.

Weak Entity-Set (Cont.) An entity set that does not have a primary key is referred to as a weak entity set. The existence of a weak entity set depends on the existence of a identifying entity set it must relate to the identifying entity set via a total, one-to-many relationship set from the identifying to the weak entity set Identifying relationship depicted using a double diamond The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity set’s discriminator.

Weak Entity Sets (Cont.) Note: the primary key of the strong entity set is not explicitly stored with the weak entity set, since it is implicit in the identifying relationship. If loan-number were explicitly stored, payment could be made a strong entity, but then the relationship between payment and loan would be duplicated by an implicit relationship defined by the attribute loan-number common to payment and loan

Weak Entity Sets (Cont.) We depict a weak entity set by double rectangles. We underline the discriminator of a weak entity set with a dashed line. payment-number – discriminator of the payment entity set Primary key for payment – (loan-number, payment-number)

Design Techniques Avoid redundancy. Don’t use an entity set when an attribute will do.

Avoiding Redundancy Redundancy occurs when we say the same thing in two different ways. Redundancy wastes space and (more importantly) encourages inconsistency. The two instances of the same fact may become inconsistent if we change one and forget to change the other, related version.

Example: Good name name addr Advises Students Teacher This design gives the address of each teacher exactly once.

Example: Bad name name addr Advises Student Teachers Adviser This design states the adviser of a student twice: as an attribute and as a related entity.

Example: Bad name Adviser Adviser-Address Students This design repeats the adviser’s address once for each student; loses the address if there are temporarily no students for an adviser.

Entity Sets Versus Attributes An entity set should satisfy at least one of the following conditions: It is more than the name of something; it has at least one non key attribute. or It is the “many” in a many-one or many-many relationship.

Example: Good name name address Advises Students Teacher Teachers deserves to be an entity set because of the nonkey attribute address. Students deserves to be an entity set because it is the “many” of the many-one relationship Advises.

Example: Good name Adviser Students There is no need to make the adviser an entity set, because we record nothing about advisers besides their name.

Example: Bad name name Advises Students Teachers Since the teacher is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

E-R Diagram Summary: In this learning sequence, we discussed the keys and weak entity sets in Entity- Relationship diagram.

END