Chapter 5:
Enhanced/Extended entity relationship model (EER):
Result of adding more semantic constructs to the original entity
relationship (ER) model.
EER diagrams (EERDs) use the EER model
Main EER model constructs –
- Entity supertypes : Generic entity type related to one or more entity
subtypes. Contains common characteristics.
- Entity subtypes : Contains unique characteristics of each entity
subtype.
- Entity clustering : "Virtual" entity type used to represent multiple
entities and relationships in ERD
Criteria to determine usage / When to use supertype and subtype
- There must be different, identifiable kinds or types of the entity in the
user's environment
- The different kinds or types of instances should each have one or more
attributes that are unique to that kind or type of instance
- Consider examples: MECHANIC, ACCOUNTANT, CLERK
Nulls are created by unique attributes.
Entity supertypes and subtypes are organized in a specialization hierarchy
Depicts arrangement of higher-level entity supertypes (parent entities)
and lower-level entity subtypes (child entities)
Relationships are described in terms of "is-a" relationships
Subtype exists within the context of a supertype
Every subtype can have only one supertype (parent) to which it is directly
related
Supertype can have many subtypes, i.e., a specialization hierarchy can
have many levels of supertype or subtype relationships
A specialization hierarchy provides the means to :
Support attribute inheritance
Define a special supertype attribute known as the subtype discriminator
Define disjoint or overlapping constraints and complete or partial
constraints.
Inheritance
Enables an entity subtype to inherit attributes and relationships of the
supertype
All entity subtypes inherit their primary key attribute from their supertype
At the implementation level, supertype and its subtype(s) maintain a 1:1
relationship
Entity subtypes inherit all relationships in which supertype entity
participates
Lower-level subtypes inherit all attributes and relationships from its
upper-level supertypes
Subtype Discriminator
Attribute in the supertype entity that determines to which entity subtype
the supertype occurrence is related
Default comparison condition is the equality comparison
In some situations the subtype discriminator is not necessarily based on
an equality comparison
Disjoint and Overlapping Constraints
Disjoint subtypes : contain a unique subset of the supertype entity set
- Known as nonoverlapping subtypes
- Implementation is based on the value of the subtype discriminator
attribute in the supertype
Overlapping subtypes : contain nonunique subsets of the supertype entity set
- Implementation requires the use of one discriminator attribute for each
subtype
Completeness Constraint
Specifies whether each supertype occurrence must also be a member of at
least one subtype
Partial completeness: not every supertype occurrence is a member of a
subtype
Total completeness: every supertype occurrence must be a member of at
least one subtypes
Entity Clustering :
Formed by combining multiple interrelated entities into a single, abstract
entity object
General rule: avoid the display of attributes to eliminate complications
that result when the inheritance rules change
Selecting Primary Keys
◦ Primary keys: single attribute or a combination of attributes
◦ Uniquely identifies each entity instance
◦ Guarantees entity integrity
◦ Works with foreign keys to implement relationships
◦ Natural key or natural identifier: real-world identifier used to uniquely
identify real-world objects
- Familiar to end users and forms part of their day-to-day business
vocabulary
- Used as the primary key of the entity being modelled
- Usually, if an entity has a natural identifier, a data modeler uses it as a
primary key of the entity being modeled
- Generally, most natural keys make acceptable primary key identifiers.
Primary Key Guidelines / Desirable primary key characteristics
◦ Non intelligent
◦ No change over time
◦ Preferably single-attribute
◦ Preferably numeric
◦ Security-compliant
When to Use Composite Primary Keys
Identifiers of composite entities - Each primary key combination is
allowed once in M:N relationship
Identifiers of weak entities
- Strong identifying relationship with the parent entity
- Represents a real-world object that is existence-dependent on another
real-world object
- Represented in the data model as two separate entities in a strong
identifying relationship
When to Use Surrogate Primary Keys
◦ A system-assigned primary key, generally numeric and auto-incremented.
◦ Primary key used to simplify the identification of entity instances
- Useful when there is no natural key or the existing natural key might
not be a suitable primary key
- Helpful if selected candidate key has embedded semantic contents or
is too long
- Require ensuring that the candidate key of entity in question performs
properly
- Use "unique index" and "not null" constraints
Design Case 1: Implementing 1:1 Relationships
◦ Foreign keys work with primary keys to properly implement relationships
in relational model
- Place primary key of the parent entity on the dependent entity as
foreign key
◦ Options for selecting and placing the foreign key
- Place a foreign key in both entities
- Place a foreign key in one of the entities
Design Case 2: Maintaining History of Time-Variant Data
Time-variant data
- data whose values change over time and for which a history of the data
changes must be retained
Requires creating a new entity in a 1:M relationship with the original entity
New entity contains the new value, date of the change, and any other
pertinent attribute
Design Case 3: Fan Traps
◦ Design trap : occurs when a relationship is improperly or incompletely
identified
- Represented in a way not consistent with the real world
Fan trap: A design trap that occurs when one entity is in two 1:M relationships
to other entities
- Produces an association among other entities not expressed in the model
Design Case 4: Redundant Relationships
Occur when there are multiple relationship paths between related entities (1:M
associative entity 1:M relationship)
◦ Must remain consistent across the model
◦ May help simplify the design in some cases
