Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
5 views31 pages

Data Modeling Using ER Model - Cont. Ch3

Chapter 3 discusses data modeling using the Entity-Relationship (ER) model, focusing on the design of a COMPANY database with entities such as EMPLOYEE, DEPARTMENT, PROJECT, and DEPENDENT. It introduces relationships between these entities, including WORKS_FOR, MANAGES, and WORKS_ON, and explains the concepts of relationship types, cardinality, and participation constraints. The chapter emphasizes the importance of refining initial designs and understanding how attributes can be associated with relationship types.

Uploaded by

arifinnayem60
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views31 pages

Data Modeling Using ER Model - Cont. Ch3

Chapter 3 discusses data modeling using the Entity-Relationship (ER) model, focusing on the design of a COMPANY database with entities such as EMPLOYEE, DEPARTMENT, PROJECT, and DEPENDENT. It introduces relationships between these entities, including WORKS_FOR, MANAGES, and WORKS_ON, and explains the concepts of relationship types, cardinality, and participation constraints. The chapter emphasizes the importance of refining initial designs and understanding how attributes can be associated with relationship types.

Uploaded by

arifinnayem60
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

CHAPTER 3

Data Modeling Using the


Entity-Relationship (ER) Model

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 1- 1


NOTATION for ER diagrams

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 2


Example COMPANY Database
◼ We need to create a Database Schema design
based on the following (simplified) requirements
of the COMPANY Database:
◼ The company is organized into DEPARTMENTs. Each
department has a name, number and an employee
who manages (manager) the department. We keep track
of the start date of the department manager. A
department may have several locations.

◼ Each department controls a number of PROJECTs.


Each project has a unique name, unique number and
is located at a single location.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 3


Example COMPANY Database (cont.)
◼ The database will store each EMPLOYEE’s social security
number, address, salary, gender/sex, and birthdate.
◼ Each employee works for one department but may work

on several projects.
◼ The DB will keep track of the number of hours per

week that an employee currently works on each project.


◼ It is required to keep track of the direct supervisor of

each employee.

◼ Each employee may have a number of DEPENDENTs.


◼ For each dependent, the DB keeps a record of name,

gender/sex, birthdate, and relationship to the


employee.
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 4
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 5


Refining the initial design by introducing
relationships
◼ The initial design is typically not complete
◼ Some aspects in the requirements will be
represented as relationships
◼ Example: Each EMPLOYEE works for one
DEPARTMENT but may work on several PROJECTs
◼ ER model has three main concepts:
◼ Entities (and their entity types and entity sets)
◼ Attributes (simple, composite, multivalued)
◼ Relationships (and their relationship types and
relationship sets)

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 6


Relationships and Relationship Types
◼ A relationship relates two or more distinct entities with a
specific meaning.
EMPLOYEE Franklin Wong works for the Research DEPARTMENT
EMPLOYEE John Smith works on the ProductX PROJECT

◼ Relationships of the same type are grouped or typed into a


relationship type.
the WORKS_FOR relationship type in which EMPLOYEE and
DEPARTMENT participate
the WORKS_ON relationship type in which EMPLOYEEs and
PROJECTs participate

◼ The degree of a relationship type is the number of


participating entity types.
◼ Both WORKS_FOR and WORKS_ON are binary relationships.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 7


Relationship instances of the WORKS_FOR N:1
relationship between EMPLOYEE and DEPARTMENT

N 1

N number of employees work in 1 department


Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 8
Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT

M N

M number of employees work in N projects


Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 9
Relationship type vs. Relationship set

◼ Relationship Type:
◼ the schema description of a relationship
◼ e.g., WORKS_FOR, WORKS_ON

◼ Relationship Set:
◼ The current set of relationship instances (r1, r2, ...)
represented in the database
◼ The current state of a relationship type

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 10


Relationship type vs. Relationship set (2)
◼ Previous figures displayed the relationship sets
◼ Each instance in the set relates individual participating
entities – one from each participating entity type
◼ In ER diagrams, we represent the Relationship type as
follows:
◼ Diamond-shaped box is used to display a Relationship

type
◼ Connected to the participating entity types via straight

lines
◼ Note that the relationship type is not shown with an

arrow. The name should be typically be readable from


left to right and top to bottom.
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 11
Refining the COMPANY database
schema by introducing relationships
◼ By examining the requirements, six relationship types are
identified
◼ All are binary relationships( degree 2)
◼ Relationship types with participating Entity types:
◼ WORKS_FOR (between EMPLOYEE, DEPARTMENT)
◼ MANAGES (also between EMPLOYEE, DEPARTMENT)
◼ CONTROLS (between DEPARTMENT, PROJECT)
◼ WORKS_ON (between EMPLOYEE, PROJECT)
◼ SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
◼ DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 12


ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 13


Discussion on Relationship Types
◼ In the refined design, some attributes from the initial entity
types are refined into relationships:
◼ Manager of DEPARTMENT -> MANAGES
◼ Works_on of EMPLOYEE -> WORKS_ON
◼ Department of EMPLOYEE -> WORKS_FOR
◼ Etc.
◼ In general, more than one relationship type can exist
between the same participating entity types
◼ MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 14


Constraints on Relationships
◼ Constraints on Relationship Types
◼ (Also known as ratio constraints)
◼ Cardinality Ratio / Cardinality Mapping

- mapping of one entity set to another entity set in a


relationship set

Four types of cardinality mapping in DBMS


◼ One-to-one (1:1) • 1 student can have only 1 student ID
◼ One-to-many (1:N)
• 1 university can have many (N) students
◼ Many-to-one (N:1) • Many (N) students can have 1 teacher
◼ Many-to-many (M:N) • Many (M) students can work on a single
project and a single student can work
on many (N) projects

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 15


Many-to-one (N:1) Relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 16


Many-to-many (M:N) Relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 17


Recursive Relationship Type
◼ A relationship type between the same participating entity
type in distinct roles
◼ Also called a self-referencing relationship type.
◼ Example: the SUPERVISION relationship
◼ EMPLOYEE participates twice in two distinct roles:
◼ supervisor (or boss) role
◼ supervisee (or subordinate) role
◼ Each relationship instance relates two distinct
EMPLOYEE entities:
◼ One employee in supervisor role
◼ One employee in supervisee role

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 18


Displaying a recursive relationship
◼ In a recursive relationship type.
◼ Both participations are same entity type in
different roles.
◼ For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor)
and (another) EMPLOYEE (in role of
subordinate).
◼ We create a relationship between the same entity
type.
◼ In following figure, first role participation labeled
with 1 and second role participation labeled with
2.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 19


A Recursive Relationship Supervision

1 N

1 2
(role) (role)

1 supervisor can
supervise N employees

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 20


Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 21


Attributes of Relationship types
◼ A relationship type can have attributes:
◼ For example, HoursPerWeek of WORKS_ON
◼ Its value for each relationship instance describes
the number of hours per week that an EMPLOYEE
works on a PROJECT.
◼ A value of HoursPerWeek depends on a particular
(employee, project) combination
◼ Most relationship attributes are used with M:N
relationships
◼ In 1:N relationships, they can be transferred to the
entity type on the N-side of the relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 22


Example Attribute of a Relationship Type:
Hours of WORKS_ON

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 23


Participation constraint
◼ Rules that determine the minimum and maximum
participation of entities or relationships in a given
relationship set
◼ Total participation (Total
participation)
(Total
participation)
◼ Partial participation

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 24


Example: Relationship Type in ER Diagram

In ER Diagram,

Total participation: double line

Partial participation single line

(Partial (Total
participation) participation)
EMPLOYEE Manages DEPARTMENT

e1 r1
d1
e2 r2
e3 r3
d2
e4 r4
e5 r5
d3
. .
.
. .
.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 25


Alternative way to show Participation
(min, max):
◼ Specifies that each entity e in E participates in at least min and at
most max relationship instances in R
◼ Default(no constraint): min=0, max=n (signifying no limit)
◼ Must have min  max, min0, max 1
◼ Only single lines are represented instead of double/single

◼ Examples:
◼ An employee can work for exactly one department but a
department can have any number of employees.
◼ Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
◼ Specify (0,N) for participation of DEPARTMENT in WORKS_FOR
◼ A department has exactly one manager and an employee can
manage at most one department.
◼ Specify (0,1) for participation of EMPLOYEE in MANAGES
◼ Specify (1,1) for participation of DEPARTMENT in MANAGES

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 26


The (min,max) notation for
relationship constraints

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 27


Practice Task

country

per account.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 28


Practice Task (Solution)

country

per account.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 29


Crows Foot Notation

Each teacher can teach One and only one course


Each course can be taught by One or Many teachers

Customer can order Zero or Many pizzas (min 0, max N)


Pizza can be ordered by Zero or Many customers

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 30


Quiz 1
◼ When: June 21, 2025 (Saturday) during class
time

◼ Topics:
◼ Chapter 2 and 3

No class on June 19, 2025 (Thursday)*

* Makeup class as required later

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 31

You might also like