1. ZEIT2301 – Database Design Entity-Relationship Diagrams
ZEIT2301 Design of IS
Week 01: Intro
ZEIT2301 – Database Design Entity-Relationship Diagrams
School of Engineering and Information Technology
Dr Kathryn Merrick
Bldg 16, Rm 212 (Thursdays and Fridays only)
Session 2, 2010

2. Topic 08: Database Design
ZEIT2301 Design of IS
Week 01: Intro
Topic 08: Database Design
Objectives:
To review Entity Relationship Diagrams for modelling data and its relationships
To review the Relational model for database management systems 2
Session 2, 2010

3. ZEIT2301 Design of IS
Week 01: Intro
Data Storage
The Class Diagram identifies the classes and attributes of interest from the problem domain.
We now consider how this data can best be stored in order to support the specified requirements of the system.
The most popular storage format today is the relational database.
Session 2, 2010 3
Session 2, 2010

4. ZEIT2301 Design of IS
Week 01: Intro
Database Design
To reap the potential benefits offered by database technology, databases must be properly designed
Effort spent in design is always rewarded in data quality
There are different (though complementary) approaches to achieving a good design 4
Session 2, 2010

5. Approaches to Database Design
ZEIT2301 Design of IS
Week 01: Intro
Approaches to Database Design
Entity-Relationship (ER) data modelling
A graphical technique for understanding and organizing the data independently of the eventual database implementation
Normalization (next week’s lecture):
An approach for evaluating the quality of a database design - most applicable to relational database designs
ER modelling and normalization are the core techniques for good database design 5
Session 2, 2010

6. Entity-Relationship Diagrams
ZEIT2301 Design of IS
Week 01: Intro
Entity-Relationship Diagrams
ER models are based on the following concepts:
Entities (or, more correctly, entity types)
Relationships (between entities)
Attributes (of entities and relationships)
Similar to the discussion of Class Diagrams
Entities are similar to Classes in OO analysis.
But:
Entities do not have any methods (data only)
Entities have a Primary Key (PK) 6
Session 2, 2010

7. Entity-Relationship Diagrams
ZEIT2301 Design of IS
Week 01: Intro
Entity-Relationship Diagrams
There are various diagrammatic styles for ERDs
We will use the UML style notation
But note that we are talking about Entities
Which store attributes (ie data) only
Not Classes
Which store attributes (data) and have processes (operations or methods)
Session 2, 2010 7
Session 2, 2010

8. An Entity and its Attributes
ZEIT2301 Design of IS
Week 01: Intro
An Entity and its Attributes
student
An entity is represented on entity-relationship diagram as a named rectangle with two parts
An entity is conventionally named in the singular (because it is a type of thing) 8
Session 2, 2010

9. ZEIT2301 Design of IS
Week 01: Intro
Attribute Domain
Domain: set of values that may be assigned to an attribute
Not shown on an ER diagram; recorded in a data dictionary
e.g. for attribute ‘gender’ the possible values are 'Male' and 'Female', so
domain(Gender) = {'Male', 'Female'}
e.g. for attribute ‘quantityHeld' the possible values range from 0 onwards, so
domain(quantityHeld) = {all natural numbers}
A particular value doesn’t have to be assigned
limits the values for an attribute
allowance for large set
Example - domain for qty_held would be the same as for an attribute Chapters
Used in later stages of database design, important for understanding user requirements 9
Session 2, 2010

10. Composite Attribute Composite Attribute: component parts
ZEIT2301 Design of IS
Week 01: Intro
Composite Attribute
student
studentID
name
address
streetAddress
suburb
state
postcode
DOB
Gender
Composite Attribute:
component parts
indented slightly. 10
Session 2, 2010

11. Multi-Valued Attribute
ZEIT2301 Design of IS
Week 01: Intro
Multi-Valued Attribute
student
studentID
name
DOB
phoneNo [1..3]
gender
Multi-valued Attribute:
1 to 3 occurrences (for a particular student)
phoneNo [1..*] means 1 or more occurrences
Session 2, 2010 11
Session 2, 2010

12. Derived Attribute Derived Attribute:
ZEIT2301 Design of IS
Week 01: Intro
Derived Attribute
student
studentID
name
DOB
/age
gender
Derived Attribute:
use “/” in front of attribute name
Session 2, 2010 12
Session 2, 2010

13. ZEIT2301 Design of IS
Week 01: Intro
Entity Uniqueness
Each entity instance should be distinguishable from all other instances of the same entity type by inspection of the values of all of its attributes
eg distinguish one student from another student
That distinguishing attribute (or group of attributes) is called the Primary Key
This is a significant difference between a Class Diagram and an Entity-Relationship Diagram
A Class does not have a PK 13
Session 2, 2010

14. Identify Primary Key Primary Key ISBN {PK} title textbook edition
ZEIT2301 Design of IS
Week 01: Intro
Identify Primary Key
textbook
ISBN {PK}
title
mainTitle
subTitle
edition
author [1..*]
publisher
price
quantityHeld
/valueOfStock
Primary Key 14
Session 2, 2010

15. Relationships between Entities
ZEIT2301 Design of IS
Week 01: Intro
Relationships between Entities
A relationship is a set of meaningful associations among entities.
Three types of relationships are:
Unary: one entity involved
Binary: two entities involved (the most common)
Ternary: three entities involved 15
Session 2, 2010

16. Multiplicity constraints
ZEIT2301 Design of IS
Week 01: Intro
Multiplicity constraints
Multiplicities indicate how many instances of each entity participate in the relationship
Generally these are zero, one or many eg:
one-to-one (1..1)
one-to-many (1..*)
many-to-many (*..*)
zero-to-one (0..1)
zero-to-many (0..*) or simply * 16
Session 2, 2010

17. Multiplicity Constraints
ZEIT2301 Design of IS
Week 01: Intro
Multiplicity Constraints
“A student enrols in up to 4 courses and must enrol in at least one course”
“A course may have zero or many students.”
student
studentID {PK}
course
courseCode {PK}
1..4
enrols In
student
studentID {PK}
course
courseCode {PK}
0..*
enrols In 17
Session 2, 2010

18. Unary (recursive) Relationship
ZEIT2301 Design of IS
Week 01: Intro
Unary (recursive) Relationship
1..*
course
courseCode {PK}
courseName
creditPoints
is prerequisite for
0..*
A course “is a prerequisite for” another course 18
Session 2, 2010

19. Binary Relationship ISBN {PK} title textbook edition author [1..*]
ZEIT2301 Design of IS
Week 01: Intro
Binary Relationship
textbook
ISBN {PK}
title
mainTitle
subTitle
edition
author [1..*]
publisher
price
quantityHeld
/valueOfStock
student
studentID {PK}
name
DOB
address
gender
buys
1..*
0..* 19
Session 2, 2010

20. Ternary Relationship “buys”
ZEIT2301 Design of IS
Week 01: Intro
Ternary Relationship “buys”
student
studentID {PK}
textbook
ISBN {PK}
buys
bookshop
name{PK} 20
Session 2, 2010

21. Attributes of a Relationship
ZEIT2301 Design of IS
Week 01: Intro
Attributes of a Relationship
student
studentID {PK}
textbook
ISBN {PK}
1..*
0..*
buys
datePurchased
Relationships may also have attributes. These attribute(s) are connected to the relationship via a dashed line. 21
Session 2, 2010

22. ER Modelling Context is important
ZEIT2301 Design of IS
Week 01: Intro
ER Modelling
Context is important
an attribute in one context may be an entity in another
Is author an attribute of a Book entity or an entity in its own right?
The model is about what is possible, not what is a fact at a particular point in time
A candidate for employment potentially has many qualifications (or possibly none?)
A candidate fills several position (ie over a period of time) 22
Session 2, 2010

23. Steps to create an ER Diagram:
ZEIT2301 Design of IS
Week 01: Intro
Steps to create an ER Diagram:
Identify Entities
Look for nouns, major objects that we want to store data about.
Identify Relationships
Look for associations, verbs between nouns..… then add constraints
Identify Attributes
Look for nouns, noun phrases that are properties of things … decide if multi-valued, derived, etc … record description in data dictionary
Choose Primary Key 23
Session 2, 2010

24. ZEIT2301 Design of IS
Week 01: Intro
Case Study
Temps for Hire (TFH) has a file of candidates that are willing to work at short notice. The file lists the id, name, address and contact number for each candidate. All candidates at TFH have a number of qualifications and TFH uses a unique code and general description to specify the qualification.
TFH also has a list of companies (name and address) that use their services. When a company has a position to be filled, they specify the start date, end date and hourly rate of the position. The company also specifies the essential qualifications required for the position.
TFH matches the position qualifications against the candidates' qualifications and selects a candidate to fill the position. 24
Session 2, 2010

25. 1. Identify Entities candidate company position qualification
ZEIT2301 Design of IS
Week 01: Intro
1. Identify Entities
candidate
company
position
qualification
look for nouns, major objects
Note: TFH itself not an entity in the database
Session 2, 2010 25
Session 2, 2010

26. 2. Identify Relationships
ZEIT2301 Design of IS
Week 01: Intro
2. Identify Relationships
All candidates at TFH have a number of qualifications …
When a company has a position to be filled, …
The company also specifies the essential qualifications required for the position.
… and selects a candidate to fill the position.
Look for associations, verbs between nouns..… then add constraints 26
Session 2, 2010

27. 2. Identify Relationships
ZEIT2301 Design of IS
Week 01: Intro
2. Identify Relationships
candidate
qualification
has
fills
requiredFor
company
position
specifies
Session 2, 2010 27
Session 2, 2010

28. ZEIT2301 Design of IS
Week 01: Intro
3. Identify Attributes
… the id, name, address and contact number for each candidate …
… a unique code and general description to specify the qualification.
a list of companies (name and address) …
… the start date, end date and hourly rate of the position.
Look for nouns, noun phrases that are properties of things … decide if multi-valued, derived, etc … record description in data dictionary 28
Session 2, 2010

29. 3. Identify Attributes candidate qualification company position has
ZEIT2301 Design of IS
Week 01: Intro
3. Identify Attributes
candidate
candidateID
name
address
contactNo
qualification
qualificationCode
description
has
fills
requiredFor
company
name
address
position
startDate
endDate
hourlyRate
specifies 29
Session 2, 2010

30. ZEIT2301 Design of IS
Week 01: Intro
4. Determine Keys
… the id, name, address and contact number for each candidate …
… a unique code and general description to specify the qualification.
a list of companies (name and address) …
… the start date, end date and hourly rate of the position. (no obvious key here?)
Choose primary key … create artificial key if necessary
Session 2, 2010 30
Session 2, 2010

31. 4. Determine Keys candidate qualification company position has fills
ZEIT2301 Design of IS
Week 01: Intro
4. Determine Keys
candidate
candidateID {PK}
name
address
contactNo
qualification
qualificationCode {PK}
description
has
fills
requiredFor
company
Name {PK}
address
position
positionNo {PK}
startDate
endDate
hourlyRate
specifies 31
Session 2, 2010

32. ZEIT2301 Design of IS
Week 01: Intro
Multiplicity
candidate
candidateID {PK}
name
address
contactNo
qualification
qualificationCode {PK}
description
has
0..*
0..*
1..*
requiredFor
fills
0..1
0..*
0..*
company
Name {PK}
address
position
positionNo {PK}
startDate
endDate
hourlyRate
specifies
1..1
1..*
Some assumptions on multiplicities made here - would need to clarify with stakeholders
Session 2, 2010 32
Session 2, 2010

33. Summary After today’s lecture you should be able to
Construct an ER-diagram
Identify entities
Identify relationships
Determine attributes
Select keys