DS4001 Databases (7.

5 credits)

Lecture 5 – Entity-Relationship Diagrams

Yuantao Fan
[email protected]

Halmstad University
Overview

• Schema
• Database design flow
• Entity-Relationship diagram
– Domain description
– Entities, multiple entities, weak entities
– Attributes of an entity, or a relationship
– Relationships
– Multiplicity
– Relations in ER-diagrams
• Examples
Designing Databases with Entity-Relationship (ER) Diagram

• We have learnt how to use DDL to implement a databse design

– Given tables
– Create a database via SQL
– Query for data

• Knowing the concept of constraints

– Primary keys, prevent duplicate values
– Foreign keys (reference constraints)

• Design a database based on a domain description

 Teacher(tid, full_name, age, nationality)
Example Database tid full_name age nationality
How to design, and construct these tables?
11 John Smith 42 America

Course(cid, Course_name, Course_code, Credit_hours) 22 Jens Jonathon 31 Sweden

cid course_name course_code credits 33 Stefan Miller 39 Sweden

Intro to Computer 44 Kayle Persson 33 UK

1 CS1310 4
Science
2 Data Structures CS3320 4 Teaches(tid, cid, hours)
Discrete hours
3 MATH2410 3 tid cid
Mathematics
11 1 80
4 Database CS3380 3
11 2 100
22 4 50
33 4 50
44 3 100
Designing Databases with Entity-Relationship (ER) Diagram

• We have learnt how to use DDL to implement a databse design

– Given tables
– Create a database via SQL
– Query for data

• Knowing the concept of constraints

– Primary keys, prevent duplicate values
– Foreign keys (reference constraints)

• Design a database based on a domain description

Domain ER-diagram / SQL code

Schema
descriptioin high level design Relational DBMS
Schema
tid cid hours

• A database schema is a collection of relation: 11 1 80

11 2 100
Teaches(tid, cid, hours)
tid -> Teacher.tid 22 4 50
cid -> Course.cid 33 4 50
hours > 0
44 3 100
• You can write SQL code for implementing the design
CREATE TABLE Teaches(
tid tinyint(4) NOT NULL,
cid tinyint(4) NOT NULL,
hours INT,
CHECK (hours > 0),
FOREIGN KEY (tid) REFERENCES Teacher(tid),
FOREIGN KEY (cid) REFERENCES Course(cid)
);
Schema
• Why the following databse design is bad?
Schedule

tid cid c_name date time room nn_seats

33 4 Databases 2030-01-23 10:15 - 12:00 D415 50
33 4 Databases 2030-01-24 08:15 - 10:00 D415 50
11 3 Mathematics 2030-01-24 13:15 - 15:00 D208 30
11 3 Mathematics 2030-01-25 13:15 - 15:00 D415 50
Schema
• Why the following databse design is bad?
Schedule

tid cid c_name date time room nn_seats

33 4 Databases 2030-01-23 10:15 - 12:00 D415 50
33 4 Databases 2030-01-24 08:15 - 10:00 D415 50
11 3 Mathematics 2030-01-24 13:15 - 15:00 D208 30
11 3 Mathematics 2030-01-25 13:15 - 15:00 D415 50

• Redundancy
– Duplicates in the number of seats for room D415
• Update anomaly & delete anomaly
– Change nn_seats in one row but not others
– nn_seats information is gone if all bookings of D415 is removed
Decomposing the table
Room

Schedule room nn_seats

D415 50
tid cid date time room
D208 30
33 4 2030-01-23 10:15 - 12:00 D415
33 4 2030-01-24 08:15 - 10:00 D415 Course
11 3 2030-01-24 13:15 - 15:00 D208 cid course_name
11 3 2030-01-25 13:15 - 15:00 D415
Discrete
3
Mathematics
Nice and simple when tables are small 4 Databases
Domain descriptions

• The domain description of a database is an informal description of everything that a

database should contain
• Provided by the stakeholders (experts in this domain), or your clients
• Written in natural language
– Depending on it’s structure, maybe difficult to generate SQL code without error
• Has certain abstraction
– Ambigous on some details
• Development of the databases is likely to be iterative
– Contious meetings between developers and the clients
Modelling Domains

• Model the domain for developing databaseas

• A model contains formal, well-defined definitions
• Given a description on the domain
– Classrooms can be booked for courses on working days during daytime
• How to model a domain?
• Problems
– Directly write SQL code for implmenting databases according the description is prone to error
– Hard to present it efficienty when the tables are large

Domain ER-diagram / SQL code

Schema
descriptioin high level design Relational DBMS
The Entity-Relationship (ER) Model

• An ER model describes interrelated things of interest in a specific domain of

knowledge.
– Entities (including its attributes) An ER diagram
– Relationships between different entities
• Entities are concepts (or things) from the domain cid
– Teacher, Courses, Students etc.
– Attributes are properties of the entities
• Relationship connect entities name Course code
– Teachers teach courses etc.

credits
Entities in boxes
Attributes in ellipses
 From ER model to relational schema

Domain ER-diagram / SQL code

Schema
descriptioin high level design Relational DBMS

“Each Course has its own

name, a unique ID, and a
cid
number of credits to be
acquired.” CREATE TABLE Course(
cid tinyint(4),
Courses(cid, name, credits) name TEXT ,
name Course credits tinyint(4),
PRIMARY KEY (cid)
);

credits
Multiple Entities

• Entities are named singular, while relations are in plural (in ER-diagrams)

cid tid

name Course Teacher

credits name

Courses(cid, name, credits) Teachers(tid, name)

Plural can be used for Schema
Relationship between two entities

• It is required to assign teachers

onto the course to fulfill tasks cid tid

• How can it be implemented?

• Add attributes?
name Course Teacher

credits name

Courses(cid, name, credits) Teachers(tid, name)

Relationship between two entities

• It is required to assign teachers

onto the course to fulfill tasks cid tid

• How can it be implemented?

• Add attributes?
name Course Teacher
• How about a a new relation?
– A binary relation with (course,
teacher) pairs
credits name
Courses(cid, name, credits)
Teachers(tid, name)
TaughtBy(course, teacher)
Courses(cid, name, credits) Teachers(tid, name)
course -> Courses.cid
teacher -> Teachers.tid
Multiple Entities

• Relationships in diamond-shpes
• Name describe the relationship

cid tid

name Course TaughtBy Teacher

credits name
Courses(cid, name, credits)
Teachers(tid, name)
TaughtBy(course, teacher)
course -> Courses.cid
teacher -> Teachers.tid
Compound keys and relationshipes

• Include whole key of both relations

cid tid

name Course TaughtBy Teacher

credits name
Courses(cid, name, credits)
Teachers(tid, name)
TaughtBy(course, c_name, teacher)
course -> Courses.(cid, name)
teacher -> Teachers.tid
Attributes of relationships

• Specifiy the year of responsible teacher of each course

– Is year an attribute of course? teacher? or the relationship?

cid year tid

name Course TaughtBy Teacher

credits name
 Attributes of relationships
• Specifiy the year of responsible teacher of each course Courses(cid, name, credits)
Teachers(tid, name)
– Is year an attribute of course? teacher? or the relationship? TaughtBy(course, c_name, teacher, year)
• Note that relationship can never have key attributes course -> Courses.(cid, name)
– Always identified by the related entities teacher -> Teachers.tid

• Identify attributes on relationships in domains

– A might have a B in/at/for/to a C, where A and C are entities, and z is an attribute

e.g. Teacher can be

cid year tid assigned with hours in
courses

name Course TaughtBy Teacher

credits name
Degree of Relationships

• The degree of a
relationship tupe is the
number of participating
entity types
• The WORKS_FOR
relationship is of degree
two - binary
• The SUPPLY
relationship is of degree
three - ternary
Degree of Relationships

• The degree of a
relationship tupe is the
number of participating
entity types
• The WORKS_FOR
relationship is of degree
two - binary
• The SUPPLY
relationship is of degree
three - ternary
 Page 83

Multiplicity

• Example relationship models

– Each course has a single teacher
– Each course has at least one
teahcer
– Each teacher has a single course

cid tid

name Course TaughtBy Teacher

credits name
Multiplicity

• ER-diagrams

Cardinalities represent the relaitonships between databases

Multiplicity
• Identifying many-to-exactly-one in domains
– With the form “Every X has a Y” (Y is another entity)
– Ambigous cases, e.g. “Xs have Ys”, each X can have multiple Ys, or each X has one Y.
– Use many-to-one relationships for attributes that can be more accurately modelled as an entity
• Most-to-at-most-one
– Some teachers have an office
– A teachers may have an office

At most one

Teache
oid Office rOffice Teacher tid
Multiplicity

Teache
oid Office rOffice Teacher tid

At most one

Teache
oid Office rOffice Teacher tid
Multiplicity

Teachers(tid)
Office(oid)
Teache
oid Office rOffice Teacher tid TeacherOffice(teacher, office)
office -> Office.oid
teacher -> Teachers.tid

At most one

Teache
oid Office rOffice Teacher tid
Multiplicity

Teachers(tid)
Office(oid)
Teache
oid Office rOffice Teacher tid TeacherOffice(teacher, office)
office -> Office.oid
teacher -> Teachers.tid

At most one
Teachers(tid)
Office(oid)
Teache TeacherOffice(teacher, office)
oid Office rOffice Teacher tid
office -> Office.oid
teacher -> Teachers.tid
Multiplicity

Teachers(tid)
Office(oid)
Teache
oid Office rOffice Teacher tid TeacherOffice(teacher, office)
office -> Office.oid
teacher -> Teachers.tid

At most one
Teachers(tid)
Office(oid)
Teache TeacherOffice(teacher, office (or null))
oid Office rOffice Teacher tid
office -> Office.oid
teacher -> Teachers.tid
Multiway relationship

rid
Courses(cid, credits)
Teachers(tid, name)
Role(rid)
Role TaughtBy(course, teacher, role)
cid tid
course -> Courses.cid
teacher -> Teachers.tid
roleà Roles.rid
Course CourseRole Teacher
Key pairs (course, teacher)
ensures assignment of any
number teachers with any
number of courses, for each
credits name
association we need to select a
valid role
Multiway relationship

rid
Courses(cid, credits)
Teachers(tid, name)
Role(rid)
Role TaughtBy(course, teacher, role)
cid tid
course -> Courses.cid
teacher -> Teachers.tid
roleà Roles.rid
Course CourseRole Teacher
At most one (teacher, role) pair
per course

credits name
Translating self relationships

• Similar to how other relationships are handled

id name • Make the self-referencing nullable

Employees(id, name, boss (or null))

boss -> Emplyees.id
Employee

CREATE Table Employees(

id INT PRIMARY KEY,
name TEXT NOT NULL,
boss INT REFERENCES Employees
BossOf );
Translating self relationships

• How to model Users can block other users

id name

ChatApp
User

Blocked
Translating self relationships

• How to model Users can block other

id name
users?
• Cardinality of the relationship?

ChatApp
ChatAppUsers(id, name)
User
Blocked(blocking, blocked)
blocking -> ChatAppUsers.id
blocked -> ChatAppUsers.id

Blocked
Translating self relationships

• How to model Users can block other

id name
users?
• Cardinality of the relationship?
– Many to Many

ChatApp
ChatAppUsers(id, name)
User
Blocked(blocking, blocked)
blocking -> ChatAppUsers.id
blocked -> ChatAppUsers.id

Blocked
Translating self relationships

• How to model Users can block other

id name
users?
• Cardinality of the relationship?
– Many to Many

ChatApp
ChatAppUsers(id, name)
User
Blocked(blocking, blocked)
blocking -> ChatAppUsers.id
blocked -> ChatAppUsers.id

• Limitation of self-relationships in ER-diagrams?

– Self-referrencing (I block myself?)
Blocked
– Cycles
• Identifying self-relations in domain
– With the form “X has … to another X”
Weak Entities

• A weak entity can be identified uniquely only by considering the primary key of
another (owner) entity
– In other words, it cannot be identified only by its own attributes
– The owner entity set and weak entity set must participate in a one to many relationship set
(one owner, many weak entities)
– Weak entity set must have total participation in this identifying relationship set
– Weak entities have only a partial key (dashed underline)

N 1
dname Department of Company name

Dashed underline
Weak entity Identifying relationship
(partial primary key)
(always many-to-one)
Weak Entities

• A weak entity can be identified uniquely only by considering the primary key of
another (owner) entity
• Identifying relationship is when the existence of a row in a child table depends on a
row in a parent table
– Make the foreign key part of the child's primary key
– logical relationship is that the child cannot exist without the parent

N 1
dname Department of Company name

Dashed underline
Weak entity Identifying relationship
(partial primary key)
(always many-to-one)
 Example translating weak entities
Common Many-to-one relationship:
N 1
Companies(name)
dname Department of Company name department(dname, company)
company->companies.name

Many-to-one relationship with weak entities:

N 1 Companies(name)
dname Department of Company name department(dname, company)
company->companies.name

• Identifying weak entities in domain descriptions

– If attributes determined for an entity are not sufficient to identify members
– E.g. Student id are unique within classes
 Page 71

ER Diagram Examples
Page 64 Page 84