Chapter three

Database modeling
logical structure of a database
define how data is connected to each other and
how they are processed and stored inside the
system
ER Model
based on the notion of real-world entities and
relationships among them
for the conceptual design of a database

ER Model is based on −
Entities and their attributes.
Relationships among entities.
Entity
a real-world entity having properties called
attributes.
Every attribute is defined by its set of values called
domain.
e.g. in a school database, a student is considered as
an entity. Student has various attributes like name,
age, class, etc.
 logical association among entities
Mapping cardinalities define the number of
association between two entities

one to one one to many

many to one many to many
Relational Model defines a table as an a relation
Data is stored in tables called relations
Each row in a relation contains a unique value
Each column in a relation contains values from a
same domain.
ER DIAGRAM REPRESENTATION
Entity types rectangle boxes
Weak entity type  double box

EMPLOYEE DEPENDENT

Entity Weak Entity

Entity types are similar to classes,
they describe potential objects (entities)
that will appear in the database.
Weak entity types describe dependent entities,
entities that depend on other entities for identity.

EMPLOYEE DEPENDENT

Entity Weak Entity

 Attributes ellipses, ovals
Every ellipse represents one attribute and is directly connected to its
entity rectangle
Key attributes  underlined name
Partial key attributes dotted underlined name

Age SSN Date

Attribute Key Attribute Partial Key

Attribute
Key attributes must be unique for each entity
Keys are used to identify particular entities
Partial keys are only partially unique
 used for weak entity types

Age SSN Date

Attribute Key Attribute Partial Key

Attribute
Attributes are connected to entity types by lines

Name EMPLOYEE Phone

EID

DEPENDENT
Age
Entities are instances of an entity type.
All regular entity types must
have a key attribute or set of key attributes

Weak entity types must have partial keys

Weak entities get part of their key

(and part of their identity)
from some related entity.
 Multi valued attributes  double ellipse (double
lined oval)
Multi valued = set valued
that there may be more than one value for the
attribute.
Derived attributes  dashed line ovals
 the attribute is computed from other data

Locations NumEmployees

Multivalued Derived
Attribute Attribute
Composite attributes  tree
 composed of other attributes.
 used for a set of related attributes,
when the set is not a conceptual entity
 the composite doesn’t have identity … it doesn’t have a key

Address
City
ZipCode
Street State
Composite
Attribute
Relationships  diamonds
Identifying relationship  double diamond

WorksOn DependentOf

Relationship Identifying
Relationship
Relationships indicate a meaningful connection
between two entity types
diamond-shaped box
Relationships may have attributes,
but they cannot have key attributes.
Identifying relationships connect a weak entity type
to some other entity type
 indicates where the weak entity gets a key
to complete its own partial key

WorksOn DependentOf

Relationship Identifying
Relationship
 DEPENDENT Age
DependentOf

EID
Name EMPLOYEE
Phone

Name
PROJECT
WorksOn Budget

StartDate
binary relationship where two entities are participating

Cardinality number of instance of an entity from a relation that can

be associated with the relation

One-to-one ('1:1') only one instance of an entity is associated with

the relationship.
One-to-many ('1:N') when more than one instance of an entity is
associated with a relationship

Many-to-one ('N:1') more than one instance of an entity

on the left and only one instance of an entity on the right
can be associated with the relationship.
Many-to-many (N:N) more than one instance of an entity on
Both left and right side can be associated with the
relationship
Total participation  Each entity is involved in the
relationship. double lines
Partial participation Not all entities are involved
in the relationship. single line
EMPLOYEE WorksFor DEPARTMENT

Total Participation

EMPLOYEE WorksOn PROJECT

Partial Participation
Arrowheads can be used to indicate
an upper bound of 1 for participation
 (not used in our textbook)

X R Y

X must participate in exactly one R

X R Y

X may participate in at most one R

Cardinality ratios specify
the maximum number of relationship instances
that an entity may participate in
1 1
EMPLOYEE Manages DEPARTMENT

1:1 ratio
n 1
EMPLOYEE WorksFor DEPARTMENT

n:1 ratio
n m
EMPLOYEE WorksOn PROJECT

n:m ratio
Structural constraints specify the minimum and
maximum number of relationship instances
that an entity may participate in
(1,1) (4,n)
EMPLOYEE WorksFor DEPARTMENT

An employee must work for exactly 1 department.

A department must have at least 4 employees.

(0,1) (1,1)
EMPLOYEE Manages DEPARTMENT

An employee may manage at most 1 department.

A department must have exactly 1 manager.
There’s generally numerous ways to express a
relationship constraint.
(0,N) optional participation in any
number of relationships
(0,1) optional participation in at
most one relationship
(1,N) required participation in at
least one relationship

(1,1) required participation in

exactly one relationship
An employee can manage at most one department.
A department must have exactly one manager.

(0,1) (1,1)
EMPLOYEE Manages DEPARTMENT

1 1
EMPLOYEE Manages DEPARTMENT

EMPLOYEE Manages DEPARTMENT

An employee must work for exactly one department.
A department must have at least one employee.

(1,1) (1,n)
EMPLOYEE WorksFor DEPARTMENT

n 1
EMPLOYEE WorksFor DEPARTMENT

EMPLOYEE WorksFor DEPARTMENT

 (1,1) (1,n)
EMPLOYEE WorksFor DEPARTMENT

Each EMPLOYEE instance

is connected to exactly
one WORKS_FOR
instance.

Each DEPARTMENT
instance is connected to
at least one WORKS_FOR
instance.
It is sometimes convenient
to name an entity’s role in a relationship.
 particularly useful in recursive relationships
 removes ambiguity in direction of relationship

Supervision
supervisor supervisee

(0,N) (0,1)
EMPLOYEE
 Supervision

supervisor supervisee

(0,N) (0,1)

EMPLOYEE

1 = supervisor
2 = supervisee
Equivalent Schema defined in UML
Design an ER schema for the following enterprise: