ZEIT2301 – Database DesignEntity-Relationship Diagrams
School of Engineering and Information Technology
UNSW@ADFA
Dr Kathryn Merrick
Bldg 16, Rm 212 (Thursdays and Fridays only)
2
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
Session 2, 2010 3
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.
4
Database Design
Effort spent in design is always rewarded in data quality
There are different (though complementary) approaches to achieving a good design
To reap the potential benefits offered by database technology, databases must be
properly designed
5
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
6
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)
Session 2, 2010 7
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)
8
An Entity and its Attributes
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)
student
9
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}
10
Composite Attribute
student
studentIDnameaddress streetAddress suburb state postcodeDOBGender
Composite Attribute:
component parts indented slightly.
Session 2, 2010 11
Multi-Valued Attribute
student
studentIDnameDOBphoneNo [1..3]gender
Multi-valued Attribute:
1 to 3 occurrences (for a particular student)
phoneNo [1..*] means 1 or more occurrences
Session 2, 2010 12
Derived Attribute
student
studentIDnameDOB/agegender
Derived Attribute:
use “/” in front of attribute name
13
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
14
Identify Primary Key
textbook
ISBN {PK}title
mainTitlesubTitle
editionauthor [1..*]publisherpricequantityHeld/valueOfStock
Primary Key
15
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
16
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 *
17
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.”
course
courseCode {PK}
student
studentID {PK} enrols In
1..4
course
courseCode {PK}
student
studentID {PK} enrols In
0..*
18
Unary (recursive) Relationship
course
courseCode {PK}courseNamecreditPoints
is prerequisite for
A course “is a prerequisite for” another course
0..*
1..*
19
Binary Relationship
student
studentID {PK}nameDOBaddressgender
textbook
ISBN {PK}title
mainTitlesubTitle
editionauthor [1..*]publisherpricequantityHeld/valueOfStock
buys
1..* 0..*
20
Ternary Relationship “buys”
textbook
ISBN {PK}
student
studentID {PK}buys
bookshop
name{PK}
21
Attributes of a Relationship
textbook
ISBN {PK}
student
studentID {PK}buys
datePurchased
Relationships may also have attributes. These attribute(s) are connected to the relationship via a dashed line.
0..*1..*
22
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)
23
Steps to create an ER Diagram:
1. Identify Entities Look for nouns, major objects that we want to store data
about.
2. Identify Relationships Look for associations, verbs between nouns..… then add
constraints
3. Identify Attributes Look for nouns, noun phrases that are properties of
things … decide if multi-valued, derived, etc … record description in data dictionary
4. Choose Primary Key
24
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.
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.
Session 2, 2010 25
look for nouns, major objects Note: TFH itself not an entity in the database
1. Identify Entities
candidate company
qualification position
26
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
Session 2, 2010 27
2. Identify Relationshipscandidate qualification
has
company positionspecifies
fillsrequiredFor
28
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
29
3. Identify Attributes
candidate
candidateIDnameaddresscontactNo
qualification
qualificationCodedescription
has
company
nameaddress
position
startDateendDatehourlyRate
specifies
fillsrequiredFor
Session 2, 2010 30
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
31
4. Determine Keys
candidate
candidateID {PK}nameaddresscontactNo
qualification
qualificationCode {PK}description
has
company
Name {PK}address
position
positionNo {PK}startDateendDatehourlyRate
specifies
fillsrequiredFor
Session 2, 2010 32
Multiplicitycandidate
candidateID {PK}nameaddresscontactNo
qualification
qualificationCode {PK}description
has
company
Name {PK}address
position
positionNo {PK}startDateendDatehourlyRate
specifies
fillsrequiredFor
0..* 0..*
0..1
0..*
1..*1..1
1..*
0..*
Some assumptions on multiplicities made here - would need to clarify with stakeholders
Summary
After today’s lecture you should be able to Construct an ER-diagram Identify entities Identify relationships Determine attributes Select keys
Top Related