Database Design

Databases Systems [BS IV][Spring 2025]

Abdul Rehman Soomrani

Most of the content was taken from slides of book “Database System Concepts, 7th Ed, Silberschatz, Korth and Sudarshan”
The Enhanced Entity-Relationship Model

• Semantic concepts are incorporated into the original ER

model and called the Enhanced Entity-Relationship
(EER) model.

• Examples of additional concept of EER model is called

specialization / generalization.
Specialization / Generalization

• Superclass
• An entity type that includes one or more distinct
subgroupings of its occurrences.

• Subclass
• A distinct subgrouping of occurrences of an entity type.
Specialization / Generalization
• Superclass/subclass relationship is one-to-one (1:1).

• Superclass may contain overlapping or distinct subclasses.

• Not all members of a superclass need be a member of a subclass.

Specialization / Generalization

• Attribute Inheritance
• An entity in a subclass represents same ‘real world’
object as in superclass, and may possess subclass-
specific attributes, as well as those associated with the
superclass.
Specialization / Generalization
• Specialization
• Process of maximizing differences between members of an
entity by identifying their distinguishing characteristics.

• Generalization
• Process of minimizing differences between entities by
identifying their common characteristics.
AllStaff relation holding details of all staff
 staffNo Name Position salary

Staff

isA
typingSpeed
mgrStartdate bonus

Manager Secretary

salesArea carAllowance

SalesPersonnel
Constraints on Specialization / Generalization
Two constraints that may apply to a specialization/generalization:

• Participation constraint
• Determines whether every member in superclass must participate as a member
of a subclass.
• May be total or partial.

• Disjoint constraint
• Describes relationship between members of the subclasses and indicates whether
member of a superclass can be a member of one, or more than one, subclass.
• May be disjoint {OR} or overlap{AND}.
 staffNo Name Position salary

Staff
{OR, Total}
isA {AND, Partial} isA
mgrStartdate
bonus typingSpeed

Secretary
Manager SalesPersonnel
salesArea carAllowance
hourlyRate
salaryScale Allownce

Permanent PartTime
Translation to Relation
Schemas
Derive relations for logical data
model
(1) Strong entity types
• For each strong entity in data model,
• Create relation that includes all simple attributes of entity
• For composite attributes, include only constituent simple attributes
(2) Weak entity types
• For each weak entity in data model,
• Create relation that includes all simple attributes of entity
• Primary key of weak entity is partially or fully derived from each
owner entity
Derive relations for logical data
model
• (3) One-to-many (1:*) binary relationship types
• For each 1:* binary relationship,
• Entity on ‘one side’ of relationship designated as parent entity
• Entity on ‘many side’ designated as child entity
• Represent relationship by posting copy of primary key
attribute(s) of parent entity into relation representing child
entity
• Acts as foreign key
• If relationship has attributes
• Post attributes to child entity along with copy of parent entity primary key
Derive relations for logical data
model
(4) One-to-one (1:1) binary relationship types
• Cardinality cannot be used to identify parent and child entities
• Participation constraints used
• Options:
1) Represent relationship by combining entities involved into one relation
2) Create two relations and post copy of primary key from one relation to other
• Consider the following:
• (a) total participation on both sides of 1:1 relationship
• (b) total participation on one side of 1:1 relationship
• (c) partial participation on both sides of 1:1 relationship
Derive relations for logical data
model
(a) Total participation on both sides of 1:1 relationship
• Combine entities involved into 1 relation
• Choose one primary key of original entities to be primary key of new relation
• Other primary key (if one exists) used as alternate key
• If relationship has attributes → include in merged relation

(b) Total participation on one side of a 1:1 relationship

• Identify parent and child entities using participation constraints
• Entity with partial participation in relationship designated as parent
• Entity with total participation designated as child
• Place copy of primary key of parent in relation representing child
• If relationship has one or more attributes → post to child relation following primary
key
• Preference example
Derive relations for logical data
model
(c) Partial participation on both sides of a 1:1 relationship
• Designation of parent and child entities arbitrary unless
more about relationship known
• If one entity closer to being total → choose as child
• ‘Staff Uses Car’ Example

17
 Derive relations for logical data
model
(5) One-to-one (1:1) recursive relationships
• Follow rules for participation for 1:1 relationship
• Total participation on both sides
• Represent recursive relationship as single relation with two copies of primary key
• One copy => primary key; other copy => foreign key, should be renamed
• Total participation on only one side
• Options:
1. Create single relation with two copies of primary key
2. Create new relation to represent relationship
• New relation would only have two attributes => both copies of primary key
• Copy of primary keys act as foreign keys, should be renamed to indicate purpose
• Partial participation on both sides
• Create new relation as described above
18
Derive relations for logical data
model
(7) Many-to-many (*:*) binary relationship types
• Create relation to represent relationship and include any
attributes that are part of relationship
• Post copy of primary key attribute(s) of entities that
participate in relationship into new relation - act as foreign
keys
• Foreign keys also form primary key of new relation
• Possibly in combination with other attributes of relationship
• See ‘Client Views PropertyForRent’ relationship
Guidelines for representation of
superclass / subclass relationship
 Representation of Entity Sets with
Composite Attributes
• Composite attributes are flattened out by creating a
separate attribute for each component attribute
• Example: given entity set instructor with composite attribute
name with component attributes first_name and last_name the
schema corresponding to the entity set has two attributes
name_first_name and name_last_name
• Prefix omitted if there is no ambiguity (name_first_name could be
first_name)
Representation of Entity Sets with
Multivalued Attributes
• A multivalued attribute M of an entity E is represented by a separate
schema EM
• Schema EM has attributes corresponding to the primary key of E and an
attribute corresponding to multivalued attribute M
• Example: Multivalued attribute phone_number of instructor is
represented by a schema:
inst_phone= ( ID, phone_number)
• Each value of the multivalued attribute maps to a separate tuple of the
relation on schema EM
• For example, an instructor entity with primary key 22222 and phone numbers 456-
7890 and 123-4567 maps to two tuples:
(22222, 456-7890) and (22222, 123-4567)