ZEIT2301 – Database DesignEntity-Relationship Diagrams

School of Engineering and Information Technology

UNSW@ADFA

Dr Kathryn Merrick

Bldg 16, Rm 212 (Thursdays and Fridays only)

k.merrick@adfa.edu.au

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