Scribd
Upload
24 views9 pages

DBMS Chapter5

chapter 5 notes

Uploaded by

nainularab999
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
24 views9 pages

DBMS Chapter5

chapter 5 notes

Uploaded by

nainularab999
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

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

You might also like