Weak Entities, Specialisation and Aggregation

Beyond the basics

A weak entity set cannot be identified by its own attributes alone; it depends on an owner (identifying) entity through an identifying relationship. A dependent of an employee is identified by the employee's ID plus the dependent's name (the partial key or discriminator, drawn with a dashed underline). Weak entities are drawn with a double rectangle and the identifying relationship with a double diamond, and they always have total participation. Specialisation divides an entity set into sub-classes (an EMPLOYEE is a PROFESSOR or STAFF), and generalisation is the reverse, combining similar entities into a super-class; both form IS-A hierarchies where sub-classes inherit attributes. Constraints describe them: disjoint versus overlapping (can an entity belong to several sub-classes?) and total versus partial (must every super-class entity belong to some sub-class?). Aggregation treats a relationship as an entity so it can take part in another relationship, for example a monitors relationship between a manager and a works-on relationship.

Weak entities and an IS-A hierarchy

Textual notation for the extended ER concepts.

weak entity DEPENDENT (name [partial key], relation, dob)
  identifying relationship HAS_DEPENDENT: EMPLOYEE 1 --- N DEPENDENT  (total for DEPENDENT)
  full key of DEPENDENT = (emp_id, name)

EMPLOYEE (emp_id, name, salary)
   |  ISA  (disjoint, total)
   +-- PROFESSOR (research_area)
   +-- STAFF     (shift)

aggregation: [EMPLOYEE --WORKS_ON-- PROJECT] --MONITORED_BY-- MANAGER

Rooms in a building

Room 101 means nothing on its own; it becomes unique only as "Room 101 in Block C". A room is a weak entity whose partial key (101) is completed by its owner (the block).

Quick check: What identifies a weak entity?

• Its own primary key alone
• Its partial key combined with the key of its owner entity
• A random number
• The relationship's attributes only