CS2300: File Structures and

Introduction to Database Systems

Lecture 6: Entity-Relationship Model

Chapter 3

Doug McGeehan

1

22

Brief Review

• ER Model

– Entity

• Collection of attributes

defining a particular

object

• Entity type

• Entity set

– Attributes

• Simple vs …

• Key

Choosing Key Attributes

• Key must uniquely identify an entity

• Uniqueness property depends on

requirements

3

Album

title

year

catalog

number

record

labelnumber

artist

Choosing Key Attributes

4

Title Artist Year Label Number

Culcha Vulcha Snarky Puppy 2016 Ropeadope 125

Sylva Snarky Puppy 2016 Impulse! 13

W:/2016ALBUM/ deadmau5 2016 Mau5trap 23

while(1<2) deadmau5 2014 Astralwerks 132

The Inevitable End Röyksopp 2014 Dog Triumph 13

Senior Röyksopp 2010 Wall of Sound 80

Choosing Key Attributes

5

Title Artist Year Label Number

Culcha Vulcha Snarky Puppy 2016 Ropeadope 125

Sylva Snarky Puppy 2016 Impulse! 13

W:/2016ALBUM/ deadmau5 2016 Mau5trap 23

while(1<2) deadmau5 2014 Astralwerks 132

The Inevitable End Röyksopp 2014 Dog Triumph 13

Senior Röyksopp 2010 Wall of Sound 80

Choosing Key Attributes

6

Instructor SectionTEACHES

numbersem

year

time

slotroom

number

building

Choosing Key Attributes

7

Instructor SectionTEACHES

numbersem

year

time

slotroom

number

building

Which attributes

would build a

composite key?

• During a particular semester

and year

– Only one section can use a

particular classroom at a

particular time slot

More on

Cardinality Ratios

Brief Review +

Higher-Degree Relationships

8

9

Cardinality Ratios for

Binary Relationships

• Cardinality ratio: specifies the maximum

number of relationship instances in which an

entity can participate

Many-to-Many One-to-Many One-to-One

Participation Constraints

• Total Participation

– Every entity in the entity set must be related to another entity set

– Represented as double line in ER diagram

• Partial Participation

– Some entities need not be related to another entity set

– Represented as single line in ER diagram

10

11

Exercise

name addr license

name manf name addr

Beer Person

Tavern

VISITS

LIKES

FAVORITE

M

N

M

NM N

N

1

SERVES

Attributes on Relationships

• Attributes of 1:1 relationship types can be migrated to either one of the

participating entity types.

• Attributes of 1:N relationship types can be migrated to the participating

entity type on the N-side.

12

Employee DepartmentWORKS

IN

N 1

name

ID

startDate

Employee DepartmentWORKS

IN

N 1

name

ID

startDate

Attributes on Relationships

• Can this attribute be moved?

13

Tavern BeerSELLSN M

name

addr

price

More on the Weak Entity

14

DependentEmployee DependentCARES FOR

name

Weak Entity

• Recall: No key attribute, only partial key

• Partial key combined with its identifying owner’s key

uniquely identifies a weak entity

• e.g. “Doug’s sister Sarah”

• The relationship degree is One-to-Many

• Existence dependency: Full participation constraint

15

More on the Weak Entity

• Can we allow Many-to-Many?– With many-many, we wouldn't know

which owner provides uniqueness

16

DependentEmployee DependentCARES FOR

name

N M

Chain of Weakness

Example: A movie studio may have several film crews.

– The crews may be designated by a given studio as crew 1,

crew 2, and so on

– Other studios might use the same designations for crews,

so the crew number is not a key for crews.

– To name a crew uniquely, we need to give the name of the

studio and the crew number.

– Each crew has his dependents, and only their names are

stored.

17Crew Studio

number namename

N 1WORKS

FOROFDependentN1

name

More on the Weak Entity

• A weak entity set can be connected to an

entity set other than its owner entity set.

18

Crew Studio

number namename

1WORKS

FOR

MAKE Film

N

M

name

N

Relationship To Weak Entities

• Problem:

– Some database design tools permit

only binary relationships

• Solution:

– Represent a multiway relationship

as a weak entity set

19

Relationship To Weak Entities

20

Tavern Beer

Drinker

name nameaddr manf

name addr

license

PREFERENCE

Relationship To Weak Entities

21

TavernBeer

Person

name

name

addr

manf

name addr

license

Preference

DP

BP PBN N

N

1

1

1

What is the key of

the “Preference”

entity set?

Design Issues

22

Database Design

Survival Tactics

• Client has (possibly vague) ideas of what he/she wants

• Be Lean and Agile in your design

– Phase 1: Organic implementation• Learn the problem domain as you go

• Only implement what is required and nothing more

• Ask for clarification when ambiguities arise

23

Database Design

Survival Tactics

• Client has (possibly vague) ideas of what he/she wants

• Be Lean and Agile in your design

– Phase 2: Refactoring• Replace relationship-implying attributes

with relationships

• Add all constraints

• Remove redundancies when appropriate

24

Design Principles

1. DRY: Don’t Repeat Yourself

Storing the same thing more than once

= A waste of space, enables inconsistency

25

Beer

name manufact.

address

Bad Design: repeats

manufacturer address for

each beer they manufacture.

Design Principles

26

Bad Design: manufacturer’s name said twice

Beer Manufact.

name addrname manufact.

N 1MAKES

Design Principles

27

Good!

Beer Manufact.

name addrname

N 1MAKES

Design Principles

2. Enforce as many constraints as possiblein your design schema

– Don't rely on future data to follow assumptions.

Example• Registrar dictates only one instructor per course section

• Don’t assume departments will always honor it

• Force compliance within the design

28

Design Principles

2. Enforce as many constraints as possiblein your design schema

– Enforcing constraints guarantees a valid stateof a database at all times

– Loosening constraints may require manual cleanup later on

29

Design Principles

3. Entity sets vs. Attributes

– Which concepts should be attributes?

– Which concepts should be entities?

– KISS: Keep It Simple, Stupid-- Navy, 1960

30

Design Principles

Do we need an address for our

application?

31

Beer Manufact.

name addrname

MAKES

Which One is Better?

32

Some redundancy

is okay.

Not going to change

often.

Beer

name manf

Beer Manufact.

namename

MAKES

33

Example

• Why is this a not-so-great design?

Tavern BeerSells

Price

phone

34

Design Principles

Person

name phone

area

code

country

calling

code

local

exchange

number

station

number

addressbuilding

number

streetapt number

city

state

zip

country

No.

phone

Person

namephone

address

Yes.

Intuitive Rule for

Entity vs. Attribute Make an entity set only if it either:

1. Is more than a name of something;

i.e. it has non-key attributes

or relationships with other entity types;

OR

2. Is the “many” in a many-one relationship.

35

Design Principles

4. Don’t overuse weak entity set

– Many times, there is no “global” keyfor an entity

• e.g. Player numbers for Football teams

– In Practice: synthetic keys are used• The DB designer becomes the global

authority of unique IDs within the mini-world

36

Design Principles

• The only times weak entity sets seem necessary are when:

– We can't easily create such ID's. There is no global authority to create them• Example: player numbers across all football teams

– Limitations to design tools and database systems• Example: only binary relations

37

What’s Next

• Enhanced Entity-Relationship (EER)

Model (Chapter 4)

• Homework #1 has been released

• Due Next Tuesday before / during

lecture

38