LOGICAL

DESIGN Enhanced ER
to
Relational
Models
CMPS 342
Database Systems

Spring 2022
Database Systems 1
Enhanced ER Model
• ER models are used for traditional database applications
• Some databases have more complex requirements than traditional
ones
• Databases for engineering design
• Telecommunications
• Geographic information systems
➔development of additional semantic data modeling concepts
➔Enhanced Entity Relationship (EER) Model

Database Systems 2
COMPANY DATABASE
• Members of the EMPLOYEE entity type may be distinguished further
into

SECRETARY SALARIED ENGINEER PROGRAMMER MANAGER

EMPLOYEE

• Every entity of these subgroupings is also an employee

Database Systems 3
Subclasses and Superclasses
• An entity type can have numerous subgroupings of its entities
• These are meaningful subtypes that need to be represented explicitly
due to some significance in the database
• We call each of these subgroupings subclass or subtype
• The main entity that they derive from is the superclass or supertype
• The subclass member is the same as the entity superclass but in a
distinct specific role
EMPLOYEE

Database Systems 4
Subclass Superclass Representation
Local Attribute
specific to the SUPERCLASS
subclass

Attribute Specific
relationship type

SUBCLASS SUBCLASS REL

Database Systems 5
Subclass Existence
• An entity cannot exist merely as a member of a subclass
• Must be a member of the superclass
• An entity can exist in a superclass but not in the subclass
• An entity can exist in multiple subclasses ➔ Specialization
EMPLOYEE

ENGINEER PROGRAMMER
SALARIED SALARIED
EMPLOYEE EMPLOYEE
Database Systems 6
Specialization
• A specialization defines a set of subclasses of an entity type
• based on a distinguishing characteristic

SUBCLASS

Database Systems 7
EMPLOYEE Specializations

Job type Method

of pay

position

Database Systems 8
Type Inheritance
• A subclass inherits all the
attributes and relationships
of its superclass
• A subclass also has specific
attributes and relationships
that don’t apply to the
superclass

Database Systems 9
Subclass Instances

Same entity

An entity in
superclass but
not in a
subclass

Database Systems 10
Subclass Membership
Predicate-Defined Subclass User-Defined Subclass

• Subclass is defined automatically • Subclass is specified individually

by a condition on the attribute by a user
of the superclass • No condition for determining
• Place a condition on the value of membership of a subclass
some attribute of the superclass
SUPERCLASS SUPERCLASS

Predicate_Attribute

‘Attribtue Value’ ‘Attribtue Value’

Database Systems 11
Predicate-Defined Specialization

Database Systems 12
Disjointness Constraint
Disjoint Specialization Overlapping Specialization

• An entity can be a member of at • An entity may be a member of

most one of the subclasses of more than one subclasses of he
the specialization specialization

d o

Database Systems 13
Disjointness Constraint

Database Systems 14
Completeness Constraint
Total Specialization Patial Specialization

• Every entity in the superclass • An entity may be in the

must be a member of at least superclass and not belong to any
one subclass in the of the subclasses
specialization

SUPERCLASS SUPERCLASS

Database Systems 15
Combination of Constraints
• Four possible combination of constraints

d d o o

Database Systems 16
Completeness Constraint

Database Systems 17
Some Insertion Deletion Rules
• Delete an entity from a superclass
➔ Entity is deleted from all the subclasses

• Inserting an entity in a superclass Predicate

➔Entity is inserted in all predicate-defined subclasses

• Insert an entity in a total specialization superclass

➔ Entity is inserted in at least one of the subclasses

Database Systems 18
Add Constraints to EMPLOYEE Superclass

d
d

Database Systems 19
Generalization
• A reverse process of specialization
• Generalize a set of entity types into a superclass

Database Systems 20
Generalization
• A generalization is always total since superclass is
derived from the subclasses
• Generalization is a bottom-up approach and
specialization is a top-down approach.
• Generalization is always applied to the group of
entities whereas, specialization is always applied on
a single entity.
• Generalization results in a formation of a single
entity whereas, Specialization results in the
formation of multiple new entities.
Database Systems 21
Special/Generalization Hierarchy and Lattice
• A subclass may have further subclasses forming a hierarchy
• A specialization hierarchy
• Every subclass participates in only one class/subclass relationship
• Every subclass has only one parent
• Tree structure
• specialization lattice
• A subclass can have more than one parent (shared subclass)
• Grid structure
• A subclass inherits the attributes of all its predecessor superclasses

Database Systems 22
Specialization Lattice

Database Systems 23
University Database
• The database keeps track of three types of persons: employees,
alumni, and students.
• A person can belong to one, two, or all three of these types.
• Each person has a name, SSN, sex, address, and birth date.

Database Systems 24
University Database
• Every employee has a salary, and there are three types of employees:
faculty, staff, and student assistants.
• Each employee belongs to exactly one of these types.
• For each alumnus, a record of the degree or degrees that he or she
earned at the university is kept, including the name of the degree, the
year granted, and the major department.
• Each student has a major department.

Database Systems 25
University Database
• Each faculty has a rank, whereas each staff member has a staff
position.
• Student assistants are classified further as either research assistants
teaching assistants, and the percent of time that they work is
recorded in the database.
• Research assistants have their research project stored, whereas
teaching assistants have the current course they work on.

Database Systems 26
University Database
• Students are further classified as either graduate or
undergraduate, with the specific attributes
• degree program (M.S., Ph.D., M.B.A., and so on) for graduate
students
• class (freshman, sophomore, and so on) forvundergraduates.

Database Systems 27
University Database

Database Systems 28
 Relational
Data Model

Database Systems 29
Database Design Phases
1

2B 2A

3
4B
4A
5
Phase 3
• Database implementation using a
DBMS
• Transform conceptual high level
data model to implementation
(DBMS specific) data model

Microsoft Access MySQL Oracle

DBMS Data Model
• To implement a database, you need to transform your ER model into
a model that can store your data
• This is done using a DBMS

Database Systems 32
DBMS

RELATIONAL NOSQL
DATABASE DATABASE
Database Systems 33
Relational Database
Relational Data Model Structured Query Language (SQL)

Database Systems 34
 Relational Data Model
• Represent the database as a collection of relations
• Each relation resembles a table of values or a flat file of records
Collection of STUDENT
related values
that correspond
to a real world
entity or
relationships

Meaning of
values in each
row Database Systems 35
Formal Relational Model Terminology

Database Systems 36
Relation Schema and Attributes
• A relation schema is used to describe a relation
• It is made up of a list of attributes
• Attributes denoted by 𝐴1 , 𝐴2 , … , 𝐴𝑛
• Relation denoted by 𝑅(𝐴1 , 𝐴2 , … , 𝐴𝑛 )
• Degree of a relation is the number of attributes 𝑛

Database Systems 37
Relation Schema and Attributes
STUDENT

• Relation definition
STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)

• Relation Degree
7

Database Systems 38
Relation State and Tuples
• A tuple represents a particular entity or object shown as a row
• Denoted as 𝑡
• Relation state is a specific state of the relation defined as a set of tuples
• Denoted as 𝑟(𝑅)
• 𝑟 = 𝑡1 , 𝑡2 , … , 𝑡𝑚
𝑛
• 𝑡 =< 𝑣1 , 𝑣2 , … , 𝑣𝑛 >

𝑟(STUDENT) 𝑚
𝑡2

𝑡4 𝐴2 𝑜𝑟 𝑡4 . 𝐴2
Database Systems 39
Domain (Domain Constraint)
• Domain is a set of possible values for each attribute
• Denoted as 𝑑𝑜𝑚(𝐴𝑖 )
• Specified by a name, a datatype, format
• Domain name: a logical definition of the domain
• Usa_phone_numbers: The set of ten-digit phone numbers valid in US
• Names: The set of character strings that represent names of persons
• Employee_ages: Possible ages of employees between 15 and 80
• Domain Datatype: string, integer, character, …
• Domain Format: 𝑑𝑑𝑑 𝑑𝑑𝑑 − 𝑑𝑑𝑑𝑑

Database Systems 40
Relational Model Notation
• Relation schema of degree 𝑛: 𝑅(𝐴1 , 𝐴2 , … , 𝐴𝑛 )
• Relation name: 𝑅
• Relation state: 𝑟(𝑅)
• Tuple: 𝑡 = < 𝑣1 , 𝑣2 , … , 𝑣𝑛 >
• Attribute: 𝐴
• Tuple value in an attribute: 𝑡[𝐴𝑖 ]
• Domain of an attribute: 𝑑𝑜𝑚(𝐴𝑖 )

Database Systems 41
Relation Characteristics
• Ordering of tuples
• No particular order
• Can order by any attribute
• Ordering of values within a tuple
• A tuple is an ordered list of 𝑛 values
• Correspondence between attributes and their values must be maintained

Database Systems 42
Relation Characteristics
• Values and NULLs in Tuples
• Values are atomic (not divisible into components)
• Multivalued Attribute ➔ Separate Relation
• Composite Attribute ➔ Aggregated into one attribute
• NULL represent unknown/not-applicable values

• Interpretation (Meaning of a Relation)

• Relation Schema interpreted as an assertion of entities or relationships
• Asserts that a student entity has Name, Ssn, Home_phone…
• Asserts that students major in academic disciplines
• Tuple interpreted as an instance or assertion fact
• First tuple in STUDENT asserts that there is a student whose Name is Benjamin Bayer, Ssn
is 305-61-2435 …

Database Systems 43
Relational Constraints

Domain Key
Constraint Constraint

Entity Referential
Integrity Integrity
Constraint Constraint

Database Systems 44
Domain Constraint
• Tuple values must be an atomic value from 𝑑𝑜𝑚(𝐴)
• Satisfy the domain description, data type and format

Database Systems 45
Key Constraint
• No two tuples can have the same combination of values for all their
attributes
• Use a key attribute to uniquely identify each tuple in a relation
• A key can be a set of attributes or a single attribute
• Must be minimal (if we remove one attribute, it is no longer unique)

Database Systems 46
Key Constraint
• A relation can have more than one key
• Each key is called a candidate key
• Choose one of the candidate keys as a primary key (PK)
• The primary key is used to identify each tuple in the relation
Primary Key
Candidate Keys

Database Systems 47
Integrity Constraints on Relations

Domain Key
Constraint Constraint

Database Systems 48
So far single relations, so what about relational
database?

Database Systems 49
Relational Database
• A relational database contains many relations
• Tuples in relations are related in various ways
• Includes the database schema and current database state
• Satisfy a set of integrity constraints
• Defined in a DBMS using a data definition language (DDL)
• Current DBMSs are mostly using SQL as a DDL

Database Systems 50
Relational Database Schema
• A set of relation schemas denoted as 𝑆 = {𝑅1 , 𝑅2 , … , 𝑅𝑘 } and
integrity constraints 𝐼𝐶
• COMPANY = {EMPLOYEE, DEPARTMENT, … }
• 𝐼𝐶: key constraint shown as underlined attributes

Database Systems 51
Relational Database State
• A set of relation states denoted as 𝐷𝐵 = {𝑟1 , 𝑟2 , … , 𝑟𝑘 }
• 𝑟𝑖 must satisfy the integrity constraints 𝐼𝐶

Database Systems 52
Entity Integrity Constraint
• No primary key value can be NULL
• Primary key value is used to identify individual tuples in a
relation
• If primary key is NULL
➔ we cannot identify corresponding tuple

Database Systems 53
Referential Integrity Constraint
• Specified between two relations
• Maintain consistency among tuples in two relations
• A tuple that refers to another relation must refer to an existing tuple
in that relation

Database Systems 54
Foreign Key
𝑹𝟏
𝐹𝐾 𝑹𝟐
𝑃𝐾

𝑑𝑜𝑚 𝐷𝑛𝑜 = 𝑑𝑜𝑚 𝐷𝑛𝑢𝑚𝑏𝑒𝑟

𝑡𝐸𝑀𝑃𝐿𝑂𝑌𝐸𝐸 𝐷𝑛𝑜 = 𝑡𝐷𝐸𝑃𝐴𝑅𝑀𝐸𝑁𝑇 [𝐷𝑛𝑢𝑚𝑏𝑒𝑟]

• A foreign key must have the same domain as the primary key
• 𝑑𝑜𝑚 𝐹𝐾 = 𝑑𝑜𝑚(𝑃𝐾)
• Value of 𝐹𝐾 in 𝑡𝑅1 corresponds to a value in 𝑃𝐾 in 𝑡𝑅2 or is NULL
• 𝑡𝑅1 𝐹𝐾 = 𝑡𝑅2 𝑃𝐾 𝑜𝑟 𝑡𝑅1 𝐹𝐾 = 𝑁𝑈𝐿𝐿

Database Systems 55
Foreign Key
• A foreign key can also refer to its own relation

Database Systems 56
Referential Integrity Constraint

• In a database of many relations,

there are many referential
integrity constraints
• They arise from relationships
among entities
• Must all be specified as part of the
relational database definition

Database Systems 57
Referential Integrity Constraint Diagram

Database Systems 58
Integrity Constraints

Domain Key
Constraint Constraint

Entity Referential
Integrity Integrity
Constraint Constraint

Database Systems 59
 ER to
Relational
Data Model

Database Systems 60
Mapping an E-R Diagram to a Relational
Schema
• We cannot store data in an ER schema
(there are no ER database management
systems)

• We have to translate our ER schema

into a relational schema

Database Systems 61
Translation Principles

• Map
• ER schemas to relational schemas
• ER instances to relational instances

• Ideally, the mapping should

• be one-to-one in both directions
• not lose any information

Database Systems 62
Let’s Try on our Own

Database Systems 63
Translate the EMPLOYEE entity type
into a relation

CREATE an EMPLOYEE Relation with the following attributes:

Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Fname String of characters max length 15 not null
Minit Character length 1
Lname String of characters max length 15 not null
Ssn String of Characters length 9 Primary Key Not Null
Bdate Date dd/mm/yyyy
Address String of characters max length 30
Sex Character length 1
Salary Decimal 10,2

Database Systems 64
Do the Same for All Strong Entity Types
CREATE a Relation with
specified domain values, entity
integrity constraints and
primary key for
• EMPLOYEE
• DEPARTMENT
• PROJECT

Dsicard for now since we can’t

add specify a multivalued
attribute in a relational model

Database Systems 65
Schema Diagram Result

Underline the primary key

Database Systems 66
What about Weak Entity DEPENDENT?

CREATE a DEPENDENT Relation

with the following attributes:
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Essn String of characters length 9 Foreign Key --> Employee Ssn Not Null
Primary Key
Dependent_name String of characters max length 15 Not Null
Sex Character length 1
Bdate Date dd/mm/yyyy
Relationship String of characters max length 8

Database Systems 67
Schema Diagram Result

Database Systems 68
MANAGES 1:1 Relationship
EMPLOYEE
Ssn Fname Dnumber
123 John NULL DEPARTMENT
223 Franklin 1 Dname Dnumber Mgr_Ssn Mgr_Start_Date
323 Joyce 4 Headquarters 1 223 1/1/2017
423 Rames NULL Admin 4 323 13/5/2016
523 James NULL Research 5 723 1/2/2012
623 Jennifer NULL
723 Ahmad 5

Database Systems 69
MANAGES 1:1 Relationship

Add relationship attribute Add a foreign key attribute

as an attribute in referencing the Ssn attribute
DEPARTMENT table
Set it as UNIQUE why?
DEPARTMENT
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Dname String of characters max length 30 Not Null
Dnumber Integer Primary Key Not Null
Mgr_ssn String of characters length 9 unique Foreign Key --> Employee Ssn
Mgr_start_date Date dd/mm/yyyy

Database Systems 70
Schema Diagram Result

Mgr_ssn Mgr_start date

Database Systems 71
WORKS_FOR N:1 Relationship
EMPLOYEE
Ssn Fname Dno
123 John 5 DEPARTMENT
223 Franklin NULL Dname Dnumber Emp_Ssn
323 Joyce 4 Headquarters 1 223, 523
423 Rames 5 Admin 4 323, 623
523 James 1 Research 5 723, 423, 123
623 Jennifer 4
723 Ahmad 5

Database Systems 72
WORKS_FOR N:1 Relationship

EMPLOYEE
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Add a foreign key referencing Fname String of characters max length 15 Not Null
the Dnumber attribute Minit Character length 1
Lname String of characters max length 15 Not Null
Ssn String of Characters length 9 Primary Key Not Null
How is it different from 1:1 Bdate Date dd/mm/yyyy
relationship? Address String of characters max length 30
Sex Character length 1
Salary Decimal 10,2
How to ensure total Dno Integer Foreign Key --> Department Dnumber Not Null
participation?
Database Systems 73
WORKS_FOR N:1 Relationship
EMPLOYEE DEPARTMENT
Ssn Fname Dno Dname Dnumber
123 John 5 Headquarters 1
223 Franklin 1 Admin 4
323 Joyce 4 Research 5
423 Rames 5
523 James 1
623 Jennifer 4
723 Ahmad 5

ensure total participation

Don’t allow it to be NULL!

Database Systems 74
WORKS_FOR N:1 Relationship

EMPLOYEE
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Add a foreign key referencing Fname String of characters max length 15 Not Null
the Dnumber attribute Minit Character length 1
Lname String of characters max length 15 Not Null
Ssn String of Characters length 9 Primary Key Not Null
How is it different from 1:1 Bdate Date dd/mm/yyyy
relationship? Address String of characters max length 30
Sex Character length 1
Salary Decimal 10,2
How to ensure total Dno Integer Foreign Key --> Department Dnumber Not Null
participation?
Database Systems 75
Schema Diagram Result

Dno

Mgr_ssn Mgr_start date

Database Systems 76
Do the same for all 1:1 and 1:N Relationships

PROJECT
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Dnum Integer Foreign Key --> Department Dnumber Not Null

EMPLOYEE
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Super_Ssn String of characters length 9 Foreign Key --> Employee Ssn

Done as part of the weak entity

type mapping

Database Systems 77
Schema Diagram Result

Dno Super_ssn

MANAGES SUPERVISES
Mgr_ssn Mgr_start date

WORKS_FOR

Dnum

CONTROLS

DEPENDENTS_OF
Database Systems 78
WORKS_ON M:N Relationship
EMPLOYEE
Ssn Fname Pr_num
PROJECT
123 John 2
223 Franklin 1 Pname Pnum Emp_Ssn
323 Joyce 3 Product X 1 223, 523
423 Rames NULL Product Y 2 323, 623
523 James 1,2 Computerization 3 723, 423, 123
623 Jennifer 3,2
723 Ahmad 2

We need to add multiple values in both tables!

Database Systems 79
WORKS_ON M:N Relationship
EMPLOYEE PROJECT WORKS _ON
Ssn Fname Pname Pnum Pr_num Emp_Ssn
123 John Product X 1 1 223
223 Franklin Product Y 2 1 523
323 Joyce Computerization 3 2 323
423 Rames 2 623
523 James 3 723
623 Jennifer 3 423
723 Ahmad 3 123

Both attributes are not UNIQUE

Database Systems 80
WORKS_ON M:N Relationship

WORKS_ON
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Essn String of characters length 9 Foreign Key --> Employee Ssn Not Null
Primary Key
Pno Integer Foreign Key --> Project Pnumber Not Null
Hours Decimal 3,1 Not Null

Database Systems 81
Schema Diagram Result
Dno Super_ssn

MANAGES SUPERVISES
Mgr_ssn Mgr_start date

WORKS_FOR

Dnum

CONTROLS

DEPENDENTS_OF

Database Systems 82
Multivalued Attribute Locations

LOCATION
Dnumber Dlocation
DEPARTMENT
1 Houston
Dname Dnumber Location 4 Stafford
Headquarters 1 Houston 5 Bellaire
Admin 4 Stafford 5 Houston
Research 5 Bellaire, Houston, Sugarland 5 Sugarland

Database Systems 83
 Multivalued Attribute Locations

DEPT_LOCATIONS
Domain Constraint Key Entity Integrity
Referential Integrity Constrait
Name Datatype Format Constraint Constraint
Dnumber Integer Foreign Key --> Department Dnumber Not Null
Primary Key
Dlocation String of characters max length 15 Not Null

Database Systems 84
Schema Diagram Result

Database Systems 85
ER to Relational Model Mapping
Step 1: Mapping of Regular Entity Types.
Step 2: Mapping of Weak Entity Types.
Step 3: Mapping of Binary 1:1 Relationship Types.
Step 4: Mapping of Binary 1:N Relationship Types.
Step 5: Mapping of Binary M:N Relationship Types.
Step 6: Mapping of Multivalued Attributes.

Database Systems 86
Step 1: Mapping of Regular Entity Types.

• For every entity type create a relation

• Every atomic attribute of the entity type becomes a relation attribute
• Composite attributes: include all the atomic attributes
• Derived attributes are not included (can be added as aggregate
function in a view, more on this later)
• One of the key attributes of the entity make up the primary key of
the relation

Database Systems 87
Step 2: Mapping of Weak Entity Types.
• Create a relation with all its attributes
• Include in the relation a foreign key referencing the primary key of
the entity of the identifying relationship
• Set the primary key of the relation as a combination of the partial key
attribute and the foreign key attribute

Database Systems 88
Step 3: Mapping of Binary 1:1 Relationship Types.
• Include in one of the relations a foreign key attribute referencing the
primary key of the other relation
• Make sure to set the FK attribute as UNIQUE
• To include total participation, set the FK attribute value as NOT NULL
• Add attributes of the relationship to any of the relations

Database Systems 89
Step 4: Mapping of Binary 1:N Relationship Types.
• Identify the relation R at the N side
• Include in R a foreign key referencing the primary key of the other
entity of the relationship (should not be unique)
• Include the attributes of the relationship in R

Database Systems 90
Step 5: Mapping of Binary M:N Relationship Types.
• Create a new relation R to represent the relationship
• Include as foreign key the primary keys of the relations that represent
the participating entity types
• Use the combination of the foreign keys as a primary key
• Include relationship attributes in R

Database Systems 91
Step 6: Mapping of Multivalued Attributes.
• Create a new relation R to represent the multivalued attribute
• Include an attribute corresponding to the multivalued attribute values
• Add a foreign key referencing the entity type corresponding to the
attribute

Database Systems 92
ER to Relational Model

Database Systems 93
Mapping EER Model to Relations

Database Systems 94
Option A: Multiple-Relation

Database Systems 95
Option B: Multiple-Relation

Database Systems 96
Option C: Single-Relation

Database Systems 97
Option D: Single-Relation

Database Systems 98
Mapping of Multiple Inheritance
Option A

Option B, C

Option B

Options C, D

Database Systems 99
Reading Reference

Database Systems 100

Reading Reference

Database Systems 101

Reading Reference

Database Systems 102