DBMS and the

Entity-Relationship
Model
COMP2411
 What is Data?
Data is recorded or observable facts such as
age, address, height, etc.
Data is everywhere and there is a lot of it
Each piece of data takes up space on a
computer, so how do we store it efficiently and
effectively?
Student ID Student name Year Course Course Name
Grade
50000000 Peter Wong 4 CM2411 Database Systems
B+
50000000 Peter Wong 4 CS2302 Data Structures
A
50000000 Peter Wong 4 …. ….
..
50000001 Mary Tsui 2 CM2411 Database Systems
A-
50000002 Bob Lee 3 CM2411 Database Systems
B
Databases and the
DBMS
What is a Database (DB)?
◦ A non-redundant, persistent collection of logically
related records/files that are structured to support
various processing and retrieval needs

Database Management System (DBMS)

◦ A set of software programs for creating, storing,
updating, and accessing the data of a DB.
Accounting

Sales DB

Marketing DBMS
Databases and the
DBMS
Difference between DBMS and other
programming systems
◦ the ability to manage persistent data
◦ Primary goal of DBMS: to provide an environment that
is convenient, efficient, and robust to use in retrieving
& storing data
Other DBMS capabilities
◦ data modeling
◦ high-level languages to define, access and manipulate
data
◦ transaction management & concurrency control
◦ access control
◦ recovery
Data Abstraction
Databases can be complex and depending on
your role what you need to understand about
the system is limited
Data Abstraction is simplifying or hiding details
of the data depending on what you need to
know
Levels of Abstraction (Lowest to Highest)
◦ Physical/Internal Level: How data is actually stored on
disk/cloud
◦ Logical/Conceptual Level: The schema, what data is
actually stored
◦ External/View Level: A partial schema, irrelevant
information is removed or simplified
 Data Abstraction
COMP Student Finance Office
External Level
view 1 view 2 ..……... view n

Conceptual Level Logical PolyU database

view

Physical Files on disks/cloud

Physical Level
view
Models, Schemas and
Instances
Data Model
◦ A collection of conceptual tools for describing data,
relationships between data, operations and consistency
details
◦ We will be studying the Entity-Relationship (ER) Model

Data Schema
◦ Each level of Data Abstraction is defined by a schema
◦ Logical Schema: Defines the logical/conceptual structure of
the database
◦ Physical Schema: Defines the file formats/locations

Data Instance
◦ The actual contents of the database at a specific period of
time
◦ The instance conforms to the schema
Data Independence
Data Independence is the ability to modify a
schema at one level without affecting schemas
at higher levels
Physical Data Independence
◦ The ability to modify the physical schema without
altering the conceptual schema and thus, without
causing the application programs to be rewritten
Logical Data Independence
◦ The ability to modify the conceptual schema without
causing the application programs to be rewritten
 Data Independence
COMP Student Finance Office
External Level
view 1 view 2 ..……... view n

Logical Data Independence

Conceptual Level Logical PolyU database

view
Physical Data Independence

Physical Files on disks/cloud

Physical Level
view
The Language of
Databases
Data Definition Language (DDL)
◦ A language for defining the DB Schema
◦ DDL statements compile to a data dictionary which if a file
containing metadata, e.g. descriptions about the tables

Data Manipulation Language (DML)

◦ A language that enables users to manipulate data
◦ An important subset for retrieving data is called a Query
Language
◦ Two types of DML:
◦ Procedural: User specifies what data is required and how to get
it
◦ Declarative: User only species what data is required and not
where it is
Who Uses Databases?
Database/End Users:
◦ Naïve Users
◦ Interact with the database via application programs
◦ Interact with the database via a Graphical User
Interface (GUI)
◦ Application Programmers
◦ Develop applications that interact with the DBMS via
DML
◦ Sophisticated/Interactive Users
◦ Issues queries either directly via a Query Language
(such as SQL) or via tools such as analysis software
Who Uses Databases?
Database Administrator (DBA)
◦ The DBA are the people who holds central control over
the DB and coordinates its activities
◦ Functions of the DBA
◦ Define and Maintain the schemas
◦ Define and Maintain the physical storage organization
◦ Monitors and Optimizes DB performance
◦ Monitors and Grants authorization for data access
◦ Maintains the integrity of the DB
 Application Sophisticated
Naïve user DBA
Programmer user

Applicatio Applicatio
n n (SQL) DB schema
query
interfaces programs

DML compiler Query DDL compiler

processor

Application Database
programs manager
object code DBMS

File manager

Data files DB
Data dict.
disk storage
System Architecture
File Manager
◦ Allocates space on disk/cloud and controls operations
on files
Database Manager
◦ Interfaces between stored data and applications
programs/queries
◦ Translates conceptual commands to physical
commands
◦ Responsible for:
◦ Access Control
◦ Concurrency Control
◦ Backup and Recovery
◦ Integrity
System Architecture
Query Processor
◦ Translates high-level queries into tangible instructions
◦ Optimizes queries to improve performance

DML (Pre-)compiler
◦ Translates DML statements embedded in application
programs into procedure calls
DDL (Pre-)compiler
◦ Converts DDL states to data dictionary items (e.g. table
descriptions)
 Application Sophisticated
Naïve user DBA
Programmer user

Applicatio Applicatio
n n (SQL) DB schema
query
interfaces programs

DML compiler Query DDL compiler

processor

Application Database
programs manager
object code DBMS

File manager

Data files DB
Data dict.
disk storage
Course Topics
ER Model: Plan the data in your database and how they
related to each other
Relational Model: Turn a conceptual ER diagram into
tables/schema
SQL: The language of writing queries
Relational Algebra: A logical way to represent queries
Normalization and Integrity Constraints: Making tables
efficient and robust
File Organization: Structure files to speed up queries
Query Optimization: Make queries more efficient
Transaction and Concurrency Controls: Handle concurrent
operations and guarantee correctness of the DB
The Entity-Relationship
Model
The most widely understood database model, it
is a logical schema for record-based databases
Proposed by P. Chen in 1976
ER Diagrams are a critical tool of efficiently
conveying the structure of the DB
Entities
An Entity is a real-world ‘thing’ or ‘object’ which
is distinguishable from other objects via its
attributes
◦ Examples: John Chan, PolyU, HSBC, etc.

An Entity Set is the set of entities which are of

the same type and (largely) share the same
types of attributes
◦ Examples: Student, University, Bank, etc.

Entity Sets (often just shortened to Entities) in

an ER Diagram are represented by rectangles
Student
Attributes
Attributes are a piece of information that
describes an entity
Each attribute takes a value from a domain (i.e.
Integer)
Example attributes for a student:
◦ Name (Character String)
◦ Student ID (Integer or Character String)
◦ Date of Birth (Date)
◦ Address (Character String)
Formally,
◦ An attribute is a function which maps an Entity Set
into a domain
Attributes
On an ER Diagram, Attributes are represented
as ovals connected to entities
◦ Domain information is often omitted in the ER Diagram

StudentID Date_of_Birth

Name Address

Student
Spot the Entities and
Attributes
“I would like to create a network for our PolyU
cinema. Each movie has has a MovieID, title, and
genre. Each screening includes has a
ScreeningID, date and time, and room. The
customers record their name, email and unique
customer number. A movie can have multiple
screenings and each customer can attend
multiple screenings. Also, customers can give as
many movies as they want a rating.
Based on this project brief, what are the entities and
their attributes for this potential database?
Relationships
A Relationship is an association among two or
more entities
◦ Example: Student John Chan takes the Course
COMP2411
A Relationship Set is the set of relationships of
the same type connecting the same Entity Sets
◦ Example: Students take Courses

Formally, a Relationship Set is a subset of:

 Relationships
On an ER Diagram, Relationship Sets (again
often shortened to Relationships) are
represented by a diamond that connects two or
more Entities
Relationships may have attributes

StudentID Grade Code

Name Title

Student Takes Course

Date_of_Birth

Address Attributes of connected entities do not need to be

added to the entity (i.e. Students doesn’t need
Course Code attribute)
Relationship Degree
The degree of a relationship is the number of
participating entity types
Binary Relationship
◦ The most common relationship type between two
entities

Student Takes Course

Relationship Degree
Recursive Relationship
◦ Sometimes a relationship can connect two Entities of
the same Entity Type
◦ In order to differentiate between the two sides of the
relationship we use labels called Role Indicators

Supervisor

Employee Supervises

Supervisee
Relationship Degree
Sometimes 3 entities are involved in a
relationship, in which case this is referred to as
a Ternary Relationship
◦ A ternary relationship can sometimes be broken into 3
binary relationships but not always
For a relationship with n entities, this is called a
n-ary Relationship
◦ This is exceedingly rare for n > 3
Student Takes Course

Lecturer
Relationship Degree
Are these two different?

Student Takes Course

Lecturer

Student Takes Course

Has Lecturer Has

Keys
For an Entity Set, a Key is a set of attributes
which are distinct for each Entity in the Entity
Set
◦ i.e. no two entities can share the same key
Superkey: A set of attributes which, taken together,
uniquely identifies an Entity
◦ Example: {Student ID, Name} uniquely identifies a Student
◦ The Trivial Superkey is just all the attributes of entity

Candidate Key: A minimal set of attributes which, taken

together, uniquely identifies an Entity
◦ Example: Student ID can be a Candidate Key, but Name
cannot (Why?)
The Primary Key
Out of the set of Candidate Key, one is selected
to be the Primary Key, denoted by an underline
(a.k.a. Key Attribute)
◦ This is usually the smallest Candidate Key
◦ If the PK consists of two or more attributes, all are
underlined
Student_ID Date_of_Birth

Name Address

Student
The Primary Key
When the Primary Key consists of two or more
attributes, this is called a Composite Primary
Key and all attributes in the Primary Key are
underlined
In Strong Entities, these are rare and when they
exist are often replaced with the use of an ID for
elegance assuming physical memory permits
Name
Name Number ProjectID Number

Project Project
Spot the Primary Keys
“I would like to create a network for our PolyU
cinema. Each movie has has a MovieID, title, and
genre. Each screening includes has a
ScreeningID, date and time, and room. The
customers record their name, email and unique
customer number. A movie can have multiple
screenings and each customer can attend
multiple screenings. Also, customers can give as
many movies as they want a rating.
Based on this project brief, what are the entities and
their relationships for this potential database?
 Other Attribute Types
Multivalued Attribute:
When an Entity may have
Phone#
multiple different instances
of the same attribute

Derived Attribute:
An attribute which can be
Age
derived from other
information (e.g. Age can
be derived from Date of
Birth)
GivenName FamilyName Composite Attribute:
An attribute which can be
broken up into smaller
Name attributes which combine
to form a whole
Attribute vs Entity
Sometimes it seems difficult to decide whether
something should be an attribute or an entity
◦ Example: The degree of a student

In general, you model as an entity if it has its

own attributes which are of different types or
other relationships with other entities
◦ If they are of the same general type of information, just
split into different parts, maybe it can just be a
composite attribute
An Example
Create an ER Diagram for the following
paragraph

Students have a unique StudentID, as well as a

name which is split into given and family
names. They also have an address which stores
their flat number, street number, street name
and district. Their date of birth is also stored
which can be used to calculate their age based
on the current date.
 An Example
Street#
Family Flat# Street
Given Name Name
Name

Address District
Name

StudentID Date_of_Birth
Student
Phone# Age

When selecting attributes for your ER

diagram, think about what you actually
need in your system
Weak Entities
Sometimes, an entity does not have enough
attributes to form a primary key as there is no
unique combination
In this instance, it borrows the Primary Key of a
Strong Entity to combine with its own attributes
to form its own Primary Key
◦ The attributes selected to join with the Strong Entities
Primary Key is called the Partial Key
 Weak Entities
In an ER Diagram, a Weak Entity is denoted by
double rectangles connected via an Identifying
Relationship (double diamonds)
◦ The Weak Entity is connected to the Identifying
Relationship with double lines
◦ The Partial Key is denoted by a dashed line
Number
StaffID
Name
Name

Staff Supports Dependent

Date_of_Birth

Address Relationship
Relationship Constraints
Relationships also have constraints given to
them based on what these relationships are
describing

The two types of constraints:

◦ Participation Constraints: Which entities must
participate in the relationship
◦ Cardinality Constraints: How many times can each
entity participate in this relationship
Participation Constraints
Partial Participation: The entity can exist even if
it is not ever involved with this relationship.
◦ Example: A department can exist without offering any
courses
◦ This is denoted by a single line

Total Participation: The entity cannot exist

independently if it not in this relationship.
◦ Example: A course cannot exist without being offered by a
department
◦ This is denoted by double lines

Department Offers Course

Cardinality Constraints
◦ 1-to-1 (1: 1)
◦ Both Entities can participate in only one relationship
instance
◦ 1-to-Many (1: N) or Many-to-1 (N: 1)
◦ One Entity can participate in many relationship
instances
◦ Many-to-Many (N: M)
◦ Both Entities can participate in many relationship
instances

1: 1 1: N N: 1 N: M
 Cardinality Constraints
On an ER diagram, this is denoted by labels on
the lines connecting the entities to the
relationships
1 1
1: 1 Staff Heads Department

1 N
1: N Department Offers Course

N M
N: M Students Takes Course
Spot the Relationships
“I would like to create a network for our PolyU
cinema. Each movie has has a MovieID, title, and
genre. Each screening includes has a
ScreeningID, date, time, and room. The
customers record their name, email and unique
customer number. A movie can have multiple
screenings and each customer can attend
multiple screenings. Also, customers can give as
many movies as they want a rating.”
What are the relationships and their cardinalities?
Can we assume any participation constraints?
 ScreeningID MovieID

Room Title
Date N 1
Screening Has Movie
Time Genre
N
M
Attends
Rates
M
N
Customer# Customer Rating

Name
Email
Cardinality Constraints
Cardinality Constraints for Ternary Relationships
read the same way

N M
Student Takes Course

Lecturer

But isn’t this kind of

meaningless?
Or at least too vague?
Min, Max Notation
Min, Max Notation is an alternative variant which
specifically states the minimum and maximum
number of relationship an entity can be involved in
◦ You can still use N for relationships where the maximum
number is unknowable or irrelevant
This provides higher clarity but requires more
knowledge of the system you are building the DB for

Default (no constraint on this entity): min = 0, max

=n
Requirements: min max, min 0, max 1
Binary Example
(0,1) (1,1)
Staff Heads Department

(0,N) (1,1)
Department Offers Course

(1,4) (1,N)
Students Takes Course

(min, max) notation ‘looks away’ from the entity

e.g. A staff can manage 0 to 1 departments and a
department must have 1 to 1 managers.
Ternary Example

(1, 4) (1, 3)
Student Sessions Course

(1, 2)

Lecturer

A Students can take 1 to 4

Sessions
A Course can offer 1 to 3
Sessions
A Lecturer can teach 1 to 2
Sessions
Objectives
Understand the overview concepts of databases
and the DBMS model
Understand the ER Model and the meaning
behind the corresponding notation
Describe what any given ER model is trying to
represent
Create an ER model based on an English project
brief or other paragraph
Extra Question
A bank, identified by its code, name and head
office address, can have several branches. Each
branch within a given bank has a branch number
and address. One branch can have several
accounts, each identified by a unique AC
number. Every account has a type, current
balance, and one or more account holders. A
branch can also have several loans, each given
by a unique loan number, type, amount and one
or more loan holders. The name, address,
phones and unique id of all customers of the
bank are recorded and maintained.