MORE ON

ER DİAGRAM
COMP 305 DBMS COURSE
LECTURE PLAN

• Quick Review
• More on ER Diagrams
• Some Tips for Better ER Diagrams
• Examples
• Term Projects

2
STEPS IN BUILDING A DB APPLICATION

Pick application
Conceptual design
domain

What data do I
need for my
application
How can I domain?
describe that
data?

3
 STEPS IN BUILDING A DB APPLICATION

Pick application
Conceptual design
domain

diagram
SQL & Java/C+

ER
+/etc + user
interface

Implement Convert ER diagram

application code & to the data model of
user interface your DBMS product
4
ENTITY RELATIONSHIP (E/R) MODEL
• A popular data model – useful to database designers
– Graphical representation of miniworld

• E/R design is translated to a relational design

– then implemented in an RDBMS

• Elements of E/R model

– Entities
– Entity Sets
– Attributes
– Relationships

5
E/R MODEL: ENTITIES AND ENTITY SETS

• Entity: object or “thing”

– real-world object distinguishable from other objects
– described by its attributes
• Entity set: collection of similar entities
– Similar to a class in object-oriented languages
– All with same attributes
– Correspond to class of physical or bussiness objects
Students
• E.g., Employees, products, accounts, grades, campaigns, etc.
Courses
• Represented by a rectangle:

6
E/R MODEL: ATTRIBUTES
ID Name

• Attributes are:
– Properties of entities Student
• Like fields in a struct
• Like columns in a table/spreadsheet
• Like data members in an object
– Values in some domain (e.g., ints, strings)
• Attributes are simple values, e.g. integers or character strings, not structs, sets, etc.
• Represented by ovals:

7
ER MODEL: RELATIONSHIPS

• Connect two or more entity sets

– e.g. students enroll in courses
– Binary relationships: connect two entity sets
• most common
– Multiway relationships: connect several Entity Sets

Students Enroll Courses

• Represented by diamonds:

8
E/R MODEL: RELATIONSHIPS
• Students Enroll in courses
• Courses are Held in rooms
• The E/R data model:
Students Enroll Courses

ID Name Held
Semester
Rooms

A relationship can also have “descriptive attributes”.

9
MULTIPLICITY OF RELATIONSHIPS

Many-many Many-one One-one

Representation of relationships

• No arrow: many-to-many
• Sharp arrow: many-to-one
• Rounded arrow: “exactly one”
– “key constraint”
• One-one:
10
REPRESENTING “MULTIPLICITY”
• Show a many-one relationship by an arrow
entering the “one” side.

• Show a one-one relationship by arrows entering

both entity sets.

• Rounded arrow = “exactly one,” i.e., each entity of

the first set is related to exactly one entity of the
target set.
11
MULTIPLICITY OF RELATIONSHIPS
Many-to-many:
Students Enrolls Courses

Many-to-one: a student living in a residence hall

Student Live Residence hall

Many-to-exactly-one: a student must live in a residence hall

Student Live Residence hall

12
EXAMPLE E/R DIAGRAM
Name
Name

Students Enrolls Courses

ID ID

Assisting

ID TA Name

13
SECOND MULTIWAY E.G.: RENTING MOVIES

• Scenario: a Customer Rents a Movie from a VideoStore

on a certain date
date
VideoStore

Rental Movie

Customer

• date should belong to the fact of the renting

– Relationship attribute
14
ROLES IN RELATIONSHIPS
• Entity set may appear more than once in a relship
– Generally distinct entities
• Each appearance is in a different role
• Edges labeled by roles
Course (Pre- Course
Successor req) (Successor)
Accounting Finance-I
Pre-req Course Finance-I Derivatives
Prereq Finance-I Finance-II
Calculus Derivatives

15
KEYS

• A key is a set of attributes for one entity set such that no two entities in this set agree on all the
attributes of the key.
– It is allowed for two entities to agree on some, but not all, of the key attributes.
• We must designate a key for every entity set.

16
UNDERLINE THE KEY FOR EACH ENTITY SET

name category

multi-attribute keys
price are okay!

Product
Multiple
“candidate keys”?
Pick just one to be Is this a good
the key. Person
key?

address name ssn

17
EXAMPLE: A MULTI-ATTRIBUTE KEY

dept number hours room

Courses

 Note that hours and room could also serve as a

key, but we must select only one key.

18
LECTURE PLAN

• Quick Review
• More on ER Diagrams
• Some Tips for Better ER Diagrams
• Examples
• Term Projects

19
NO KEY?
Weak entity set: some or all of its key attributes
come from other classes to which it is related.

Team affiliation ) University

sport record name

Identifying
Partial key owner
Dark lines or Double lines indicate total participation
20
E-R DIAGRAM ALTERNATE REPRESENTATIONS

21
Slide from Silberschatz, et al.
 E-R DIAGRAM ALTERNATE REPRESENTATIONS

22
Slide from Silberschatz, et al.
ALTERNATIVE ER NOTATIONS
Chen IDE1FX (Crows feet notation)

23
Slide from Silberschatz, et al.
LECTURE PLAN

• Quick Review
• More on ER Diagrams
• Some Tips for Better ER Diagrams
• Examples
• Term Projects

24
FOUR PRINCIPLES OF ER DIAGRAM
• Faithfullness

• Avoid Redundancy

• Avoid Entitiry Set Overuse

• Avoid Weak Entity Overuse

25
FAITHFULNESS
• Is the relationship many-many or many-one?
• Are the attributes appropriate?
• Are the relationships applicable to the entities?

• Examples:
– Courses & instructors
• maybe many-one, maybe many-many
– Bosses & subordinates
• maybe one-many, maybe many-many

26
PRINCIPLE #1:
MODEL YOUR DOMAIN FAITHFULLY
Product Purchase Person

Country President Person

Instructor Teaches Course

27
PRINCIPLE #2: AVOID REDUNDANCY

• Redundancy = saying the same thing in two (or more) different ways.
• Wastes space and (more importantly) encourages inconsistency.
– Two representations of the same fact become inconsistent if we change one and forget to change the
other.

28
EXAMPLE:

name manf manfAddr

Toys

This design repeats the manufacturer’s address

once for each toy and loses the address if there
are temporarily no toys for a manufacturer.

29
EXAMPLE:

name name addr

Toys ManfBy Manfs

manf

This design states the manufacturer of a toy

twice: as an attribute and as a related entity.

30
 PRINCIPLE #3:
DON’T OVERUSE ENTITY SETS
• An entity set should satisfy at least one of the following
conditions:
– It is more than the name of something; it has at least one nonkey
attribute.
or
– It is the “many” in a many-one or many-many relationship.

31
EXAMPLE:

name name addr

Toys ManfBy Manfs

Manfs deserves to be an entity set because of

the nonkey attribute addr.
Toys deserves to be an entity set because it is
the “many” of the many-one relationship ManfBy.

32
EXAMPLE:

name name

Toys ManfBy Manfs

Since the manufacturer is nothing but a name,

and is not at the “many” end of any relationship,
it should not be an entity set.

33
EXAMPLE:

name manf

Toys

If there is no manf address, there is no need to

make the manufacturer an entity set, because
we record nothing about manufacturers besides
their name.
34
PRINCIPLE #4:
DON’T OVERUSE WEAK ENTITY SETS
• Beginning database designers often make most entity
sets weak, supported by all other entity sets to which
they are linked.

• In reality, we usually create unique ID’s for entity sets.

– Examples include social-security numbers, automobile VIN’s etc.

35
WHEN DO WE NEED WEAK ENTITY SETS?
• The usual reason is that there is no global authority
capable of creating unique ID’s.

• Example: it is unlikely that there could be an agreement

to assign unique player numbers across all football
teams in the world.

36
LECTURE PLAN
• Quick Review
• More on ER Diagrams
• Some Tips for Better ER Diagrams
• Examples
• Term Projects

37
EXAMPLES
will be given in the lecture.

38
LECTURE PLAN
• Quick Review
• More on ER Diagrams
• Some Tips for Better ER Diagrams
• Examples
• Term Projects

39
TERM PROJECT TOPIC
• Any realistic topic...
– Any idea that you want to implement
– Any start-up idea in your mind
– In the next semester, an idea that you can implement in
Software Engineering course.

40
TERM PROJECT IMPLEMENTATION
• First of all, create your group with 5 persons.
• Produce realistic scenario as in the examples in this lecture (more
detailed).
• Create your DBMS.
• Write SQL statements.
• Implement a basic user interface

41
TERM PROJECT DELİVERABLES
• You will meet each week and produce a meeting report (who will do
what and when)

• You will deliver one report for scenario and ER Diagram. (Week 7)

• You will deliver another report for everything in your term project.
(Week 14)

• You will also present your work in front of the audiance. (Week 15-16)
42