Database Design and Implementation

MOD002589

Lecture 3
Extended Entity Relationship Diagram (EERD)
Dr. Arooj Fatima
 Demo
&
Submission
Week12

Week11
Get Week10
Feedback
on your
Week9
design Week8
Week7
Week6
Week5
ation
evalu
tion,
enta
, Implem
n
Desig

elling
Mod

Week1: Introduction to the learning Outcomes and module

DATABASE DEVELOPMENT LIFECYCLE
n ts 1
me
ire
e qu
e wR
N
G et
5 2

Database
Development
Lifecycle
3
4
 EXTENDING ER_MODEL
To Create Extended Entity Relationship Diagram (EERD)
MAPPING WITH LEARNING OUTCOMES

LO1: Link the flow of activity in the sequence of capturing the

state of the real world in terms of data

LO2: Model data, and the prescriptive translation of that model to

data constructs for machine purposes.
MAPPING WITH ASSIGNMENT
Requirements Analysis 15%

Design / Modelling 25%

Implementation 10%

Testing Queries 50%

EXTENDING ATTRIBUTES

At this stage, we identify attributes types

Composite Attributes
Derived Attributes
Single-Valued Attributes
Multi-valued Attributes
Primary Keys
Foreign Keys
(Conolly and Begg, 2015, pp. 413-417)
EXTENDING ATTRIBUTES

Composite Attributes
…have multiple attributes e.g. address is an attribute that can be
extended to further attributes i.e. post-code, street-name and
building no.

Derived Attributes
…can be derived from an existing attribute e.g. %age of marks.
(Conolly and Begg, 2015, pp. 413-417)
EXTENDING ATTRIBUTES…

Single-valued Attributes
…can have only one value.

Multi-valued Attributes
…can have more than one value e.g. telephone-number
(Conolly and Begg, 2015, pp. 413-417)
EXTENDING ATTRIBUTES…

Primary Key
…can be a single or a set of attributes that uniquely identify an
instance or occurrence of an entity type e.g. StaffID, StudentID +
CourseID (composite key)

(Conolly and Begg, 2015, pp. 413-417)

EXTENDING ATTRIBUTES…

Foreign Key
•Foreign key relate one entity to the other
•There can be multiple foreign keys in one entity

(Conolly and Begg, 2015, pp. 413-417)

Student StudentAttendance
SID {PK} AttendanceID {PK}
Name SID {FK}
DoB 1..1 0..* ClassID {FK}
Email TapInTime
…. TapInDate
TapeInDeviceID {FK)
….
EXTENDING ATTRIBUTES…

(Conolly and Begg, 2015, p. 416)

EERD – Extended Relations
ER-Diagram can be extended using following enhanced
relations.

Generalization
Aggregation
Composition
GENERALIZATION
The concept of generalization is associated with special type
of entities called superclasses and subclasses.
Superclass
An entity that includes one or more subgroups.

Subclass
A sub group of a superclass is called subclass.
(Conolly and Begg, 2015, p. 434)
GENERALIZATION
Staff
Superclass
FirstName
LastName
StaffID

Subclasses

Paramedics Doctors
Certification Specialization
… …
… …
GENERALIZATION IMPLICATIONS
• Each instance of a subclass is an instance of its
superclass e.g. David Dunhill is an instance of the class
Doctors then it is by default an instance of the class
Staff. In other words, we can say David is a doctor and
doctor is a staff.

• Each subclass inherits the attributes of its superclass

WHY WE NEED GENERALIZATION
IN DATABASE?
 It helps to understands groups and their subgroups (if
any).

 It helps the database designers to understand which

tables (data) need to be linked.
AGGREGATION
Aggregation represents ‘has-a’ relationship between entity
types where both entities can exist separately such that
destroying one entity will not affect the related entity.
AGGREGATION
Staff
FirstName
LastName
StaffID

Aggregation

Branch
BranchID
…
…
WHY WE NEED AGGREGATION IN
DATABASE?
 It helps the database designers to plan Staff
instance or entity deletion e.g. FirstName
LastName
StaffID
•If one entity instance is deleted, its
related instances for the other entity will
exist e.g. in the example Staff has an
aggregation relation with Branch. This
tells the database designers that they Branch
need not to write a query to delete the BranchID
…
staff if a branch is deleted. …
COMPOSITION
Composition represents ‘is-part-of’ relationship between
entity types where one entity is dependent on the other for
its existence such that destroying one entity will destroy the
related entity.
COMPOSITION
Articles
ID
Title
Description

Composition

Newspapers
Title
…
…
WHY WE NEED COMPOSITION IN
DATABASE?
 It helps the database designers to plan Article
instance or entity deletion e.g. ID
Title
Description
•If top-level entity instance is deleted, its
related instances for the other entity will
no more exist e.g. in the previous example
Articles has an composition relation with
Newspaper. This tells the database Newspaper
designers that they need to write a query Title
…
to delete the articles if their related …

newspaper is deleted.
PARTICIPATION CONSTRAINTS
 Mandatory OR Optional – These constraints identify if
it is mandatory or optional for a member of a superclass
to be a member of a subclass.

 Disjoint OR Non-disjoint – This constraint only applies

if a superclass has more than one subclass.
• If the subclasses are disjoint, the entity instance can
be member of only one class.
• If the subclasses are non-disjoint, the entity
instance can be member of more than one sub-
classes.
PARTICIPATION CONSTRAINTS

(Conolly and Begg, 2015, p. 439)

WEAK AND STRONG ENTITIES
strong entity
exist without relying on
STUDENT anything else MODULE

1 1

has has

n ENROLLMENT n

weak entity
cannot exist by itself

Min-Max ER-Notation Model

WEAK AND STRONG ENTITIES

(Conolly and Begg, 2015, p. 419) - UML ER-Model

READING LIST FOR THIS WEEK
Complete Reading List

Chapter 13:

Enhanced Entity
Relationship
Modelling

Sixth Edition Available at ARU Library (online and hard copy)

REFERENCES
 Connolly, T.M. Begg, C., 2015. Database Systems : practical approach to
design, implementation, and management. [e-book] Sixth edition, Global
edition.. ed. Harlow : Pearson Education Limited. Available through: Primo.
 Figure : Source (Office Online Resources) | License

ANY QUESTIONS?