Data Modeling Using the Entity-Relationship

(ER) Model

Entity-Relationship (ER) model

◦ Popular high-level conceptual data model

ER diagrams
◦ Diagrammatic notation associated with the ER model
Using High-Level Conceptual
Data Models for Database Design
Requirements collection and analysis
◦ Database designers interview prospective database users to understand and
document data requirements
◦ Result: data requirements
◦ Functional requirements of the application
Using High-Level Conceptual
Data Models (cont’d.)
Conceptual schema
◦ Conceptual design
◦ Description of data requirements
◦ Includes detailed descriptions of the entity types, relationships, and
constraints
◦ Transformed from high-level data model into implementation data model
Using High-Level Conceptual
Data Models (cont.)
Logical design or data model mapping
◦ Result is a database schema in implementation data model of DBMS

Physical design phase

◦ Internal storage structures, file organizations, indexes, access paths, and
physical design parameters for the database files specified
A Sample Database
Application
COMPANY
◦ Employees, departments, and projects
◦ Company is organized into departments
◦ Department controls a number of projects
◦ Employee: store each employee’s name, Social Security number, address,
salary, sex (gender), and birth date
◦ Keep track of the dependents of each employee
Entity Types, Entity
Sets, Attributes, and
Keys
ER model describes data as:
◦ Entities
◦ Relationships
◦ Attributes
Entities and Attributes
Entity
◦ Thing in real world with independent existence

Attributes
◦ Particular properties that describe entity
◦ Types of attributes:
◦ Composite versus simple (atomic) attributes
◦ Single-valued versus multivalued attributes
◦ Stored versus derived attributes
◦ NULL values
◦ Complex attributes
Entities and Attributes (cont.)
Entity Types, Entity
Sets, Keys, and Value
Sets
Entity type
◦ Collection (or set) of entities that have the same attributes
Entity Types, Entity Sets, Keys, and Value
Sets (cont.)
Key or uniqueness constraint
◦ Attributes whose values are distinct for each individual entity in entity set
◦ Key attribute
◦ Uniqueness property must hold for every entity set of the entity type

Value sets (or domain of values)

◦ Specifies set of values that may be assigned to that attribute for each
individual entity
Initial Conceptual Design of the COMPANY
Database
Relationship Types, Relationship Sets,
Roles, and Structural Constraints

Relationship
◦ When an attribute of one entity type refers to another entity type

◦ Represent references as relationships not attributes

Relationship Types,
Sets, and Instances
Relationship type R among n entity types E1, E2, ..., En
◦ Defines a set of associations among entities from these entity types

Relationship instances ri

◦ Each ri associates n individual entities (e1, e2, ..., en)

◦ Each entity ej in ri is a member of entity set Ej

Relationship Degree
Degree of a relationship type
◦ Number of participating entity types

◦ Binary, ternary

Relationships as attributes
◦ Think of a binary relationship type in terms of attributes
Role Names and
Recursive Relationships
Role names and recursive relationships
◦ Role name signifies role that a participating entity plays in each relationship
instance

Recursive relationships
◦ Same entity type participates more than once in a relationship type in
different roles
◦ Must specify role name
Constraints on Binary
Relationship Types
Cardinality ratio for a binary relationship
◦ Specifies maximum number of relationship instances that entity can
participate in

Participation constraint
◦ Specifies whether existence of entity depends on its being related to
another entity
◦ Types: total and partial
Attributes of Relationship
Types
Attributes of 1:1 or 1:N relationship types can be migrated to one entity
type
For a 1:N relationship type
◦ Relationship attribute can be migrated only to entity type on N-side of
relationship

For M:N relationship types

◦ Some attributes may be determined by combination of participating entities
◦ Must be specified as relationship attributes
Weak Entity Types
Do not have key attributes of their own
◦ Identified by being related to specific entities from another entity type

Identifying relationship
◦ Relates a weak entity type to its owner

Always has a total participation constraint

Refining the ER Design for
the COMPANY Database
Change attributes that represent relationships into relationship types
Determine cardinality ratio and participation constraint of each
relationship type
ER Diagrams, Naming
Conventions, and Design Issues
Proper Naming of Schema
Constructs
Choose names that convey meanings attached to different constructs in
schema
Nouns give rise to entity type names
Verbs indicate names of relationship types
Choose binary relationship names to make ER diagram readable from
left to right and from top to bottom
Design Choices for ER
Conceptual Design
Model concept first as an attribute
◦ Refined into a relationship if attribute is a reference to another entity type

Attribute that exists in several entity types may be elevated to an

independent entity type
◦ Can also be applied in the inverse
Alternative Notations for ER
Diagrams
Specify structural constraints on relationships
◦ Replaces cardinality ratio (1:1, 1:N, M:N) and single/double line notation for
participation constraints
◦ Associate a pair of integer numbers (min, max) with each participation of an
entity type E in a relationship type R, where 0 ≤ min ≤ max and max ≥ 1
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.
y Problem Exam1’05 E-mail

gre ssn
salary Student
 name
(0,1) Grad
(1,*)
(0,*) gpa
employs
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

Section not weak: -2
Other Errors: -0.5--1 if minor
-2—3 if major Time-offered classroom
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!
 Sal
empl. (0,4) ssn name
name Manager
(1,3) 
Team Person
city (24,99) (0,1)

Home Visit
contr Player birthd

(0,*) (0,*)
Sal (0,*) weight height pos

play played-in.
score
(1,1)
min
(22,*)
Scoring:
1. Play relationship a Set: 3
2. Person/Player/Manager: 3 Game Date
3. Weak Game Entity: 3
4. Played-in: 2
5. Can Only Play once on a day: 1
6. Contract: 3
7. Salary, score, min attribute: 3