Modeling Your Data

Goal: specification of database schema

The Entity-Relationship Model

High-level Conceptual Modeling
Technique for DB Applications
August 12, 13, 14, 19, 2024
The Real World The Model
Real customers
customer stand-ins

2
 Overview of Database Design Process
• Database application
– refer to a particular database, e.g. a BANK database

• Two main activities

– Database design
– Applications design

• Focus in this part on database design

– To design the conceptual schema for a database application

• Applications design focuses on the programs and interfaces

that access the database
– Generally considered part of software engineering
3
 Database Modeling
• Analysis of the information and relationships among its
components the database must hold
• Database schema - specified in languages/notations
• Next, design is committed to a form which can be input to a
DBMS  DB takes on physical existence
• Design notation in this course: Entity-Relationship model
• The E-R model is a detailed, logical representation of the
data for an organisation or business area
Object-Oriented
DBMS
ODL, UML, etc.
Ideas
Relational
E/R Relations
DBMS 4
 The Entity-Relationship Model
• “Design methodology” independent from “relational data
model”

• Methodology:
– Use E-R model to get a high-level graphical view of essential
components of enterprise and how they are related
– E-R diagram
– Convert E-R diagram to DDL

• Extremely useful in mapping the meanings and

interactions of real-world enterprises onto a conceptual
schema
5
 The Entity-Relationship Model

• Enterprise (database) viewed as set of

– Entities in the business environment
– Relationships (associations) among entities
• What are the entities and relationships in the enterprise?
• What are the integrity constraints or business rules that hold?

– Attributes (properties) of both the entities and their

relationships
• What information about these entities and relationships
should we store in the database?
6
 Entity-Relationship Model
• Entity:
– Real-world object, concept, or event in the mini-world
that exists and is distinguishable from other objects
• The EMPLOYEE Neena Singh, the Research DEPARTMENT, the
ProductX PROJECT
• Event, plant, president, amendment_5, senate, job etc.

• Entity type/set:
– Collection of entities of the same type that share the
same properties
• Set of all employees, companies, trees, holidays
7
 Entity-Relationship Model
• Attribute:
– Properties used to describe an entity
• EMPLOYEE entity attributes: Name, SSN, Address, Gender,
BirthDate
• amendment_5 = (number, definition)
– A specific entity have a value for each of its attributes
• A specific employee entity may have Name = ‘Neena’, SSN =
‘1234’, Address = ‘731, Daya Vihar, Delhi’, Gender =‘F’,
BirthDate = ‘09-01-85’
– Each attribute has a value set (Domain or data type)
associated with it
8
 Entity-Relationship Model
• Relationship:
– Association among two or more entity sets
• Relationship type/set:
– Collection of similar relationships
• Examples:
– Employee and Department
– Employee and Project

9
 A Simple Example - “Movie Database”
• Entity:
– Movie, Star
• Attributes:
– Name: “********” (simple, single-valued / multivalued)
– Address: “123, Malabar Hill, Mumbai” (complex)
– Birthdate: “1-1-80” (simple)
– Age: 34 (could be derived from Birthdate and current date)
• Entity Types:
– Stars (Name, Address, Birthdate, Age)
– Movies (Title, Year, Length, FilmType)
• Relationship Type:
– Works_in (Name, Title, Year)
10
 Types of Attributes (1/5)

• Simple and Composite

• Single valued and Multi valued

• Simple and Derived

• Null

11
 Types of Attributes (2/5)
• Simple versus Composite
– Simple (or atomic): Each entity has a single atomic value for the
attribute; e.g., SSN or Gender
– Composite: Composition may form a hierarchy where some
components are themselves composite
• e.g., Address(StreetAddress, City, State, Zip)

12
 Types of Attributes (3/5)
• Single-valued versus Multivalued
– Single-valued: a single value for a particular entity; e.g., Age
– Multivalued: An entity may have multiple values for that attribute
• e.g., PreviousDegrees attribute for a person
• Denoted as {PreviousDegrees}

13
 Types of Attributes (4/5)
• Stored versus Derived
– The Age and BirthDate attributes of a person
– Age: a derived attribute; BirthDate: a stored attribute

• Complex attributes:
– e.g., if a person can have more than one residence and each
residence can have multiple phones

14
 Types of Attributes (5/5)

• Null Values: in some cases, a particular entity may not have

an applicable value for an attribute.
• The meaning of Null can be classified into
– Not applicable
• A person with no college degree having null for College Degree
– Unknown
• Exists but is missing
–If the Height attribute of a person is listed as null
• Not known
–If the HomePhone attribute of a person is null

15
 Entity Type and Keys
• Key attribute: An attribute of an entity type for which each
entity must have a unique value is called a key attribute of
the entity type
– Example: SSN of EMPLOYEE, Roll No. of a student

• A key attribute may be composite

– VehicleRegNumber: key of the CAR entity type: (Number, State)

• An entity type may have more than one key

– The CAR entity type may have two keys:
– VehicleIdentificationNumber (Engine no., Chasis no)
– VehicleRegNumber (Number, State) - known as license plate no.
16
 Entity Type - Graphical Rep.
Engine_no

• Entity type - rectangular box

• Attributes – ovals (Connected to its entity type)
– Components of a composite attribute - connected to the
oval representing the composite attribute
– Each key attribute - underlined
– Multivalued attributes - double ovals 17
 Database Application Ex: Company DB
• Keeps track of a company’s employees, departments, and projects
– The company is organized into DEPARTMENTs.
• Each department has a unique name, a unique number, and a particular
employee who manages the department
• Keep track when that employee began managing the department
• A department may have several locations
• A department controls a number of PROJECTs, each of which has a unique
name, a unique number, and single location
– Store each EMPLOYEE’s name, ssn, address, salary, gender, and birth date
• Each employee works for one deptt. but may work on several projects
• Keep track of the no. of hours/week that an employee works on each project
• Keep track of the direct supervisor of each employee
• Each employee may have a number of DEPENDENTs
• Keep each dependent’s first name, gender, birth date, and relationship to the
employee 18
An ER Schema Diagram for the
COMPANY Database
• How to get this
schema?
• Well, it’s a
systematic process
• Let’s see

19
 Database Application Ex: Company DB
• Keeps track of a company’s employees, departments, and projects
– The company is organized into DEPARTMENTs.
• Each department has a unique name, a unique number, and a particular
employee who manages the department
• Keep track when that employee began managing the department
• A department may have several locations
• A department controls a number of PROJECTs, each of which has a unique
name, a unique number, and single location
– Store each EMPLOYEE’s name, ssn, address, salary, gender, and birth date
• Each employee works for one deptt. but may work on several projects
• Keep track of the no. of hours/week that an employee works on each project
• Keep track of the direct supervisor of each employee
• Each employee may have a number of DEPENDENTs
• Keep each dependent’s first name, gender, birth date, and relationship to the
employee 20
 Initial design of Entity Types for the
COMPANY Database Schema
• Based on the
requirements, four
initial entity types are
identified in the
COMPANY database: incomplete
– DEPARTMENT design
– PROJECT
– EMPLOYEE
– DEPENDENT
• The initial attributes
are derived from the
requirements
description 21
 Refinement: Introducing Relationships
• A relationship relates two or more distinct entities with a
specific meaning
– EMPLOYEE Hina works on the Container PROJECT
– EMPLOYEE Umesh Gupta manages Research DEPARTMENT

• Relationships of the same type are grouped into a

relationship type
– WORKS_ON relationship type - EMPLOYEEs and PROJECTs
participate
– MANAGES relationship type - EMPLOYEEs and DEPARTMENTs
participate
– Degree of a relationship type - the no. of participating entity types
– MANAGES and WORKS_ON - binary relationships 22
 Example: Relationship Instances

The WORKS_FOR relationship type in which

EMPLOYEEs and DEPARTMENTs participate

The WORKS_ON relationship type in which

EMPLOYEEs and PROJECTs participate
23
 Relationship Type Vs Instances
• Relationship Type: is the schema description of a relationship
– Identifies the relationship name, the participating entity types,
and certain relationship constraints

• Relationship Set: The current state of a relationship type

– The current set of relationship instances in the database

• Each instance in the set relates individual participating

entities – one from each participating entity type
• In ER diagrams:
– Diamond-shaped box is used to display a relationship type
– Connected to the participating entity types via straight lines
24
 Database Application Ex: Company DB
• Keeps track of a company’s employees, departments, and projects
– The company is organized into DEPARTMENTs.
• Each department has a unique name, a unique number, and a particular
employee who manages the department
• Keep track when that employee began managing the department
• A department may have several locations
• A department controls a number of PROJECTs, each of which has a unique
name, a unique number, and single location
– Store each EMPLOYEE’s name, ssn, address, salary, gender, and birth date
• Each employee works for one deptt. but may work on several projects
• Keep track of the no. of hours/week that an employee works on each project
• Keep track of the direct supervisor of each employee
• Each employee may have a number of DEPENDENTs
• Keep each dependent’s first name, gender, birth date, and relationship to the
employee 25
 Refining the COMPANY DB Schema by
Introducing Relationships
• Six relationship types are identified by analyzing the
requirements
– WORKS_FOR (between EMPLOYEE, DEPARTMENT);
– MANAGES (also between EMPLOYEE, DEPARTMENT);
– CONTROLS (between DEPARTMENT, PROJECT);
– WORKS_ON (between EMPLOYEE, PROJECT);
– SUPERVISION (between EMPLOYEE (as subordinate), and
EMPLOYEE (as supervisor));
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT).
26
Refinement with Relationship Types
Some attributes from the initial entity types are
refined into relationships:
Before Manager of DEPARTMENT → MANAGES
Works_on of EMPLOYEE → WORKS_ON
Department of EMPLOYEE → WORKS_FOR

Refined
27
 Recursive Relationship Type
• Same participating entity type in distinct roles
• SUPERVISION relationship: Employee participates twice in two
distinct roles

1st role participation (supervisor (or boss) role) labeled with 1

2nd role participation (supervisee (or subordinate) role) labeled with 2

In ER diagram, need to display role names to distinguish participations

28
 Weak Entity Types
• A weak entity must participate in an identifying relationship
type with an owner or identifying entity type
• Boxes of weak entities are surrounded with double lines
• Always has a total participation constraint in its identifying
relationship type

29
 Weak Entity Types

• Identified by the combination

of a partial key of the weak
entity type (underlined with a
dashed line), and the
particular entity it is related to
in the identifying entity type

A DEPENDENT entity (weak entity type) identified by

– The dependent’s first name (partial key), and
– Specific EMPLOYEE (identifying entity type) with whom dependent is
related (DEPENDENT_OF: identifying relationship type)
30
 Constraints on Relationship Types

• Constraints limit the possible combinations of entities that

may participate in the corresponding relationship set
• Also known as ratio constraints
• These constraints are determined from the miniworld
situation that the relationships represent
• For ex: the company has a rule that each employee must
work for exactly one department, then this constraint must
be described in schema

31
 Constraints on Relationship Types
• Two types of relationship constraints
– Cardinality Ratio (specifies maximum participation)
• One-to-one (1:1), One-to-many (1:N) or Many-to-one, and
Many-to-many (M:N)

– Existence Dependency Constraint (specifies minimum

participation) (also called participation constraint)
• zero (optional participation, not existence-dependent)
• one or more (mandatory participation, existence-dependent)

Cardinality Ratio + Participation Constraint =

Structural Constraints
32
Cardinality Ratios (maximum participation)
Specifies the
1:1
maximum no. of
relationship
instances that
an entity can
participate in
N:1

M:N
33
 Participation Constraints
• Specifies the minimum number of relationship instances that
each entity can participate in
• Total participation constraint
– The participation of an entity type in a relationship type is total if
every entity must participate in at least a relationship of this
relationship type
– Ex: Company policy - every employee must work for a deptt.
– Displayed as a double line

34
 Participation Constraints
• Specifies whether the existence of an entity depends on
its being related to another entity via the relationship type

• Partial participation constraint

• Ex: participation of EMPLOYEE in MANAGES relationship
• In E-R diagram, it is represented by a single line

35
 Attributes of Relationship Types
– Startdate of MANAGES (1:1 relationship)

– HoursPerWeek of WORKS_ON (M:N mapping)

36
 Attributes of Relationship Types
– HoursPerWeek of WORKS_ON
• Its value for each relationship instance describes the number of
hours per week that an EMPLOYEE works on a PROJECT.
• Value depends on a particular (employee, project) combination

– Startdate of MANAGES
• Its value for each
relationship instance
describes the date on
which a manager started
managing a department
37
 Final ER Design for the COMPANY
Database
The cardinality ratio
and participation
constraint of each
relationship type are
determined from the
listed requirement in
Slide no. 25

If some cardinality ratio/dependency can not be determined

from the requirements, the user must be questioned further
to determine these structural constraints 38
 Final ER Design for the COMPANY
Database – Revisit Relationships
• WORKS_FOR
– 1:N relationship type between
DEPARTMENT and EMPLOYEE
– Both participations are total

• MANAGES
–1:1 relationship type b/w EMPLOYEE and DEPARTMENT
–EMPLOYEE participation is partial
–DEPARTMENT participation is total (assume a department must have
a manager at all times)
–The attribute StartDate is assigned to this relationship type 39
 Final ER Design for the COMPANY
Database
• CONTROLS
– 1:N relationship type between
DEPARTMENT & PROJECT
– The participation of PROJECT
is total
– The participation of
DEPARTMENT is partial
(user’s consultation indicates
that some deptt may control
no projects)
• WORKS_ON
– M:N relationship type with attribute Hours (since a project can
have several employees working on it)
– Both participations are total
40
 Final ER Design for the COMPANY
Database
• SUPERVISION
– 1:N relationship type between
EMPLOYEE (in the supervisor
role) and EMPLOYEE (in the
supervises role)
– Both participations are partial
(since not every employee is a
supervisor and not every
employee has a supervisor)
• DEPENDENTS_OF
– 1:N relationship type between EMPLOYEE and DEPENDENT
– It is the identifying relationship for the weak entity type DEPENDENT
– The participation of EMPLOYEE is partial
– The participation of DEPENDENT is total 41
 Final ER Design
for
the COMPANY Database

It is imp to have the least possible

redundancy when we design the
conceptual schema of the DB

42
 Alternative (min, max) notation for
Relationship Structural Constraints
• Specifies that each entity e in E participates in at least min and
at most max relationship instances in R at any point in time
• Associate a pair of integer nos (min, max) with each
participation of an entity type E in a relationship type R, where 0
 min  max and max 1
• min=0 implies partial participation
• min > 0 implies total participation
• Default (no constraint): min = 0, max = n
• Derived from the knowledge of mini-world constraints
• Use either the cardinality ratio/single-line/double- line notation
or the (min, max) notation (The (min, max) notation is more
precise and we will follow this notation for exercises.) 43
 Example
(0,1) (1,1)

(1,1) (1,N)

• A department has exactly one manager and an employee can

manage at most one department
– Specify (1, 1) for participation of DEPARTMENT in MANAGES
– Specify (0, 1) for participation of EMPLOYEE in MANAGES
• An employee can work for exactly one department but a department
can have any number (at least one) of employees
– Specify (1, 1) for participation of EMPLOYEE in WORKS_FOR
– Specify (1, N) for participation of DEPARTMENT in WORKS_FOR 44
 COMPANY ER
Schema Diagram
using (min, max)
notation

45
 Summary of Notation for ER Diagram

46
Check for Other Alternative Diagrammatic Notations for ER Diagrams
 Relationships of Higher Degree
• Relationship types:
– degree 2: binary; degree 3: ternary; degree n: n-ary
• Task:
– Differences between binary and higher-degree relationships
– When to choose higher degree or binary relationships
– Constraints on higher-degree relationships
• Constraints are harder to specify for higher-degree
relationships (n > 2) than for binary relationships
• In general, an n-ary relationship is not equivalent to n
binary relationships
– e.g., 3 binary relationships can represent different information
than a single ternary relationship
47
 Example of a Ternary Relationship
Instances
SUPPLY (s, j, p)
The SUPPLY Relationship (supplier, project, part)

Examine three binary relationships: are they equivalent to SUPPLY ?

Instances
CAN_SUPPLY (s, p)
USES (j, p)
SUPPLIES (s, j)

Existence of 3 relationship instances (s, p), (j, p), (s, j) does not necessarily
imply that an instance (s, j, p) exists in the ternary relationship
48
 Example: Ternary Relationship Type
What to do now as some DB design tools are based on variations of
the ER model that permit only binary relationships ??

3 binary relationships not equivalent to SUPPLY

In this case, represent a ternary relationship as a weak entity

with no partial key and with three identifying relationships
49
 Example: Ternary Relationship Type
In this case, represent a ternary relationship as a weak entity with no
partial key and with three identifying relationships
3 binary relationships ≠ SUPPLY

SUPPLY represented as weak entity type

The weak entity type SUPPLY is identified by the combination

of its 3 owner entities from SUPPLIER, PART, and PROJECT 50
An ER diagram for an Airline
Reservations System

51
 Data Modeling Tools
• A number of popular tools that cover conceptual modeling
and mapping into relational schema design.
• Examples:
– Draw.io, Lucidchart, SQuirreL SQL Client, MySQL Workbench,
erwin Data Modeler, ER/Studio, Postico, Navicat, Datagrip, etc.

52
 Defining Constraints:
Lets try some problems….

53