Updated: January 25.

2005

Designing E/R
Diagrams

Christoph F. Eick: Designing E/R Diagrams

 Conceptual Data Models
 Conceptual data models provide languages to
describe conceptual schemas.
 Conceptual schemas are used to describe the classes
of objects that occur in an application area, their
properties, their relationships, and the constraints
that hold with respect to those classes of objects.
 Center on “what kind of objects a database contains”
and not on “how these objects are stored” ( Internal
Schema) and not on “how these objects are
represented / displayed to a person that accesses the
database” ( External Schema).

Christoph F. Eick: Designing E/R Diagrams

 Conceptual Data Models ---
What are they good for?
 As a database design tool formalizing the
information requirements of the end users
 As a documentation tool for databases (to help
programmers, especially those that have to update
the database)
 As a data model of a database management system
(only very few experimental systems exist)
 As a tool to describe domain ontologies (terminology
and concepts in a UoD)
 As a tool of system analysis

Christoph F. Eick: Designing E/R Diagrams

 (n,m)
Person Entity Type X R

Attribute Entities of type X participate at least n, at most m

name times in relationship R; * indicates .

Relationship X  Y
Is-insured Type
Entity type X is a subtype of type Y
Weak
Wedding Entity Type T1 T2
Type T1 and T2 are overlapping; an entity can
belong to both T1 and T2; default is disjoint
occurred Identifying
Relationship
phone# Multi-valued Attribute

ssn Key Attribute

to Derived Attribute
from
------- Partial Key
T1

Optional Attribute  T3 T3=T2 T1
amount 
T2

E/R Model Symbols for COSC 3480

 UGrad
(1,1)
 ssn
gre 
salary mentor Student
(0,25) 
name
(1,1))
(0,2) Grad
(0,*)
employs
home
(0,30)
(0,*) took
Department (0,*)
(0,*)

Semester Course
name grade
semesterid title Cou#

took-not-a-set: -2.5
Other Errors: -1.5 (or 3-4 if major)

University Problem Final’03 COSC 3480

 Exam1 Fall 2005 Problem
 Design a “good” entity-relationship diagram that describes the following
objects in a university application: students, departments, sections taught in the
present and future, and courses. Departments have a name that uniquely
identifies the department. Students are identified by a unique social security
number, zero, one or multiple e-mail addresses, and an optional gpa (new
students do not have a gpa yet). Courses have a unique course number and a
course title. Courses are offered in one or more sections at a particular time.
Sections are identified by the time they are offered (e.g. 10:30-noon TUTH) and
by the course they are associated with. Additionally sections are characterized
by the class room the section is taught in. Only information concerning sections
that are taught in the present or in the future is stored in the database. Students
take a course in a particular semester and receive a grade for their performance.
Sometimes students take the same course again in a different semester. There
are no limits on how many courses a student can complete, and on how many
students completed a particular course. Each student is associated with a least
one department. Some students are graduate students that are additionally
characterized by their most recent GRE-score. Some graduate students work for
a department and receive a salary for their services. Each department employs
at most 75 graduate students; graduate students are not allowed to work for
multiple departments.

Christoph F. Eick: Designing E/R Diagrams

 University Problem Exam1’05 E-mail

gre ssn
salary Student
 name
(0,1) Grad
(1,*)
employs
(0,*) gpa
assoc
(0,75) (0.*)
took title
Department (0,*) Cou#
(0,*)

Semester Course
name grade (0,*)

semesterid
offered
(1,1)

took-not-a-set: -1.5
Section not weak: -2
Section
Other Errors: -0.5--1 if minor
-2—3 if major Time-offered classroom
 Sal
name Month ssn
(0,*) birthd name
name from
to
(0,*)
(0,*)
Team (25,*) contr Player
city
Home Visit
(0,*) (0,*)
Contract set viol –3, (0,*)
pos
Other: -2 play
played-in.

(1,1)
pos
(18,*)
score
Game Date
Game#

Solution Problem6 Exam0 Spring 2003

Christoph F. Eick: Designing E/R Diagrams
 Identifying Keys and Relationships
for Entity Types
Each entity type that is not subtype of another entity type
needs:
 Case1: Normal Entity Type (single rectangle)
1. A single attribute (straight line) or
2. A set of attributes or
 Case2: Weak Entity Type (double rectangle)
1. A set of relationships (double diamond) or
2. A set of relationships or a single attribute (dotted line) or
3. A set of relationships and a set of attributes (dotted line)
that uniquely identifies the instances of the entity type

Remark: min-max cardinalities for weak entity types for their

participation in identifying relationships have to be (1,1)!!

Christoph F. Eick: Designing E/R Diagrams

 ssn name
(0,*) Male
husband 
occurred  Person
wife 
(0,*) Female
(1,1)

(0,*) (0,*)
Wedding Is-insured Company

location
name
amount
to from

E/R Diagram for Multi-Weddings

 Valid E/R Diagrams
An E/R diagram is valid if and only if:
 It is syntactically correct (e.g. specifies all
key constraints,…)
 It specifies the entity types, relationship
types, attribute types, and subtype
relationships necessary to satisfy all
information requirements.
 It does not specify any invalid constraints.

1
Christoph F. Eick: Designing E/R Diagrams
 Priorities when Choosing
Between Valid E/R Diagrams
1. Express all constraints (you can express!)
2. Use and do not change terminology and
class structure of the application domain
3. Keep it simple (avoid defining entity types
that do not serve any purpose)
4. Avoid redundancy (but derived attributes
are okay)!

1
Christoph F. Eick: Designing E/R Diagrams
 A Quite Bad E/R Diagrams


gpa Name
department
(0,*) (0,*)
works-
Person for
Company
gender
wife husband
(0,*)
ssn (0,*) (0,*)
salary takes
(0,*)
is-married-
to
Section S#

time
Course C#
1
Christoph F. Eick: Designing E/R Diagrams
 Example: Too many Entity Types /
Don’t use Foreign Keys
Example: Persons as well as animals can be insured

P#
Name

(0,*) (0,*)
is-
Person insured Company
name

ssn (0,*)
Boss-ssn

Animal Bad E/R Diagram!

A#
1
Christoph F. Eick: Designing E/R Diagrams
 E/R Diagram Design –
Typical Errors
1. Missing Constraints
2. Unexpressed Constraints due to bad design
3. Every entity type needs a key
4. Attribute associated with the wrong entity type (relationship type)
5. Relationships are sets!
6. No partial participation in relationships!
7. Missing existence dependencies (use subclasses)
8. Invalid constraints
9. Using Subtypes for n:1 relationships; using relationships when subtypes should be
used.
10. When defining relationships: Too general entity types for participating entities
11. Too many entity types
12. Using foreign keys instead of relationships

1
Christoph F. Eick: Designing E/R Diagrams
 Other Issues in E/R Design
1. No relationships of relationships --- solution: create an entity type
that represent instances of the relationship (or use aggregation as
discussed in the textbook)
2. value or entity type --- solution: choose entity type if it helps
expressing constraints; otherwise, use value-type.

1
Christoph F. Eick: Designing E/R Diagrams
 University E/R Design Problem
Design a “good” entity-relationship diagram that describes the following objects in an
university application: students, instructors, professors, and courses. Students are
subdivided into graduate and undergraduate students. Students take a course in a
particular semester and receive a grade for their performance. Sometimes students
take the same course again in a different semester. There are no limits on how many
courses a student can take, and on how many students completed a particular course.
Each graduate student has exactly one advisor, who must be a professor, whereas each
professor is allowed to be the advisor of at most 20 students. Courses have a unique
course number and a course title. Students and professors have a name and a unique
ssn; students additionally have a gpa; moreover, graduate students have a GRE-score,
and undergraduate students have a single or multiple majors. Professors can be
students and take courses, but graduate students cannot be undergraduate students.

Indicate the cardinalities for each relationship type; assign roles (role names) to each
relationship if there are ambiguities! Use sub-types, if helpful to express constraints!

1
Christoph F. Eick: Designing E/R Diagrams
 gre advises
Grad (0,1) (0,20) Professor ssn
  name
major  
Ugrad Student 
(0,*) Person
grade took
gpa
(0,*)
(0,*)

Semester Course

title Cou#
semesterid

Enrolls-not-a-set: -4
Student must be ugrad or grad: -1
Other Errors: -2 (or –3 if quite major)

University Problem (slightly different from Exam0’03)

 number
Cred-Card phone# ssn
Problem 1 addr
company
(0,*)
Exam1 Fall’03
A (0,300) Client discount
B 
tr# (0,1) (1,1)
(0,*) Gold_Cl.
(1,1) C
day_ Transaction Hotel
made G#
(1,50)
D
day address Ho#
Grading: (1,1) (1,*)
Minor Error: -1 (1,*)
Medium Error: -2 Reservation Date
Major Error: -3 or –4 F G #total
0-4 points if too many errors
(1,1) #avail (0,*) (0,*)

from to rate Res# E Category

(0,*)

room-type
A:=guaranteed; B:=has_transaction; C:=for_hotel; D:=consists_of;
E:=for_category; F=avail-rooms; G=total-rooms; modified on Feb. 3, 2004
 name
ssn lot

Aggregation Employees

 Used when we have

to model a Monitors until
relationship
involving (entity
since
sets and) a started_on
dname
relationship set. pid pbudget did budget

 Aggregation allows us
Projects Sponsors Departments
to treat a relationship
set as an entity set
for purposes of  Aggregation vs. ternary relationship:
participation in  Monitors is a distinct relationship,
(other) relationships.
with a descriptive attribute.
 Also, can say that each sponsorship
is monitored by at most one employee.
2
Christoph F. Eick: Designing E/R Diagrams
 NFL E/R Design ---
Ungraded Homework --- due: Th., Jan. 27,2005

Design an Entity-Relationship Diagram that models the following objects and

relationships in the world of football (NFL): teams, players, games, managers and
contracts. Each (NFL-) team has a unique team name, and a city it plays in. Each
person being part of the NFL-world has a unique ssn and a name. Additionally,
for players their weight, height, position and birth dates are of importance.
Players have a contract with at most one team and receive a salary for their
services, and teams have at least 24 and at most 99 players under contract. Each
team has one to three managers; managers can work for at most 4 teams and
receive a salary for each of their employments. Players cannot be managers. A
game involves a home-team and visiting-team; additionally, the day of the game,
and the score of the game are of importance; teams play each other several times
in a season (not on the same day!). Moreover, for each game played we like to
know which players participated in the game and how many minutes they played.
 
Indicate the cardinalities for each relationship type; assign roles (role names) to each
relationship if there are ambiguities! Use sub-types, if helpful to express
constraints!

2
Christoph F. Eick: Designing E/R Diagrams