Modeling Your Data

Goal: specification of database schema

The Entity-Relationship Model
High-level Conceptual Modeling
Technique for DB Applications
Dr. Pritee Khanna
PDPM IIITDM Jabalpur
Jun 24, 2017
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
Overview of Database Design Process

4
 Database Design Process

• Requirements collection
and analysis
– Users’ data and functional
requirements
– Using software engineering
tools, e.g., data flow diagrams)

• Conceptual design (Creation of conceptual schema)

– Concise description of users’ data requirements
– Uses high-level conceptual data model, e.g., E/R model
– Data model operations used to specify user operations from
functional analysis
– Compatibility check and possible modification 5
 Database Design Process
• Logical design/data
model mapping
– Uses implementation data
model, e.g., relational data
model
– Conceptual schema
transformed from high-
level data model to
implementation data
model
• Physical design
– Internal storage structures, access paths, file organisation
specified
– Application programs designed and implemented
6
 Database Modeling
• Analysis of the information and relationships among its
components the database must hold
• Database schema is specified in one of the several
languages or notations suitable for expressing designs
• 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 7
 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

• The E-R model is extremely useful in mapping the meanings and

interactions of real-world enterprises onto a conceptual schema

• The E-R model

– should be understandable to both: the user and the IT technologist
– must be as ‘open’ as possible and not tied to any technology or to
any particular business methodology
– must be flexible enough so that it can be used and understood in
practically any environment where information is modelled 8
 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?

9
 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, sex, 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, sex, birth date, and relationship to the
employee 10
An ER Schema Diagram for the
COMPANY Database

11
 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
• For example: set of all employees, companies, trees, holidays
12
 Entity-Relationship Model
• Attribute:
– Properties used to describe an entity
• An EMPLOYEE entity may have the attributes Name, SSN, Address,
Sex, BirthDate
• amendment_5 = (number, definition)
– A specific entity will have a value for each of its attributes
• A specific employee entity may have Name = ‘Neena Singh’, SSN =
‘123456789’, Address = ‘731, Pashchim Vihar, New Delhi’, Sex =‘F’,
BirthDate = ‘09-JAN-85’
– Each attribute has a value set (Domain or data type)
associated with it
• Relationship: Association among two or more entity sets
• Relationship type/set: Collection of similar relationships
13
 Another Example - “Movie Database”
• Entity:
– Movie, Star
• Attributes:
– Name: “Hritik Roshan” (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)
14
 Types of Attributes (1/4)
• Simple and Composite
• Single valued and Multi valued
• Simple and Derived
• Null

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

• 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., a Colors attribute for a car or a PreviousDegrees attribute
for a person
• Denoted as {Colors} or {PreviousDegrees}
16
 Types of Attributes (3/4)
• Stored versus Derived
– The Age and BirthDate attributes of a person
– Age: a derived attribute; BirthDate: a stored attribute
• In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels, (rare possibility)
– PreviousDegrees of a PERSON: a composite multi-valued attribute
– Denoted by {PreviousDegrees (College, Year, Degree, Field)}
– Multiple “PreviousDegrees” values can exist where each has four
subcomponent attributes: College, Year, Degree, Field
• Complex attributes:
– e.g., if a person can have more than one residence and each
residence can have multiple phones
17
 Types of Attributes (4/4)

• 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

18
 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
– For example, SSN of EMPLOYEE
• 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), also known as license
plate number
19
 Entity Type - Graphical Rep.
• An entity type is displayed in a rectangular box
• Attributes are displayed in ovals
– Each attribute is connected to its entity type
– Components of a composite attribute are connected to the
oval representing the composite attribute
– Each key attribute is underlined
– Multivalued attributes displayed in double ovals
Engine_no • There may be any no. of CAR
entity instances in the entity
set for CAR
• Entity set is the current state
of the entities of that type that
are stored in the database 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
– The WORKS_ON relationship type in which EMPLOYEEs and
PROJECTs participate
– The MANAGES relationship type in which EMPLOYEEs and
DEPARTMENTs participate
– Degree of a relationship type is the no. of participating entity types
– Both MANAGES and WORKS_ON are binary relationships
22
 Example: Relationship Instances

The WORKS_FOR relationship type in which The WORKS_ON relationship type in which
EMPLOYEEs and DEPARTMENTs participate EMPLOYEEs and PROJECTs participate

• Another Example:
Priya Depositor A-102
Customer entity Relationship Account entity
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 represented 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
 Refining the COMPANY DB Schema by
Introducing Relationships
• Six relationship types are identified by analyzing the
requirements
• All are binary relationships (degree 2)
– 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)); and
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT).
25
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
26
 Recursive Relationship Type
• Same participating entity type in
distinct roles
• In SUPERVISION relationship,
Employee participates twice in
two distinct roles:
– supervisor (or boss) role
– supervisee (or subordinate) role 1st role participation labeled with 1 &
2nd role participation labeled with 2
• Each relationship instance
relates two distinct EMPLOYEE
entities:
– One employee in supervisor role
– One employee in supervisee role
27
In ER diagram, need to display role names to distinguish participations
 Weak Entity Types
• A weak entity must participate in an identifying relationship
type with an owner or identifying entity type
• 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
– The specific EMPLOYEE (identifying entity type) with whom the
dependent is related (DEPENDENT_OF: identifying relationship
type)
• Boxes of weak entities are surrounded with double lines
• Always has a total participation constraint in its identifying
relationship type 28
 Constraints on Relationship Types

• Relationship types usually have certain constraints that

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

29
 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
30
Cardinality Ratios (maximum participation)
1:1 Specifies the
maximum no. of
relationship
instances that
an entity can
participate in
N:1

M:N 31
 Participation Constraints (1/2)
• Specifies whether the existence of an entity depends on its
being related to another entity via the relationship type
• 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: a company policy states that every employee must work for a
department. Now an employee entity can exist only if it
participates in at least one WORKS_FOR relationship instance.
Participation of employee in WORKS_FOR is total.
– In E-R diagram, it is displayed as a double line 32
 Participation Constraints (1/2)

• Participation Constraints specifies whether the existence

of an entity depends on its being related to another entity
via the relationship type

• Partial participation constraint

• We do not expect every employee to manage a deptt, so
participation of EMPLOYEE in the MANAGES relationship
type is partial. Some employee entities are related to some
deptt entity via MANAGES, but not necessarily all.
• In E-R diagram, it is represented by a single line

33
 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.
• A value of HoursPerWeek depends on a particular (employee,
project) combination

– For ex: Startdate

of MANAGES
• Its value for each
relationship
instance describes
the date on which
a manager started
managing a
department 34
 Attributes of Relationship Types
– Attributes of 1:1 relationship types can be migrated/
transferred to any one of the participating entity types
• Ex: The StartDate attribute for the MANAGES relationship
– MANAGES is a 1:1
relationship, therefore
the value of the
StartDate attribute can
be determined
seperately, either by
the participating
department entity or
by the participating
employee (supervisor)
entity 35
 Attributes of Relationship Types
– Attributes of 1:N relationship types can be migrated to the
entity type on the N-side of the relationship
–If relationship WORKS_FOR has an attribute StartDate that
indicates when an employee started working for a department
–This attribute can be included as an attribute of EMPLOYEE
– In both 1:1 and 1:N
relationship types, the
decision of where to keep
relationship attribute (as a
relationship type attribute
or as an attribute of a
participating entity type)
is determined subjectively
by the schema designer
36
 Attributes of Relationship Types
–But the situation is different in case of M:N mapping
• For M:N relationship types, some attributes may be determined
by the combination of participating entities in a relationship
instance, not by any single entity
• Such attributes must be specified as relationship attributes
– HOURS attribute of the
M:N relationship
WORKS_ON
– The number of hours an
employee works on a
project is determined by
an employee-project
combination and not
separately by either
entity 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. 10
If some cardinality ratio or
dependency can not be determined
from the requirements, the user must
be questioned further to determine
these structural constraints

• 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 38
 Final ER Design for the COMPANY
Database
• WORKS_FOR
– 1:N relationship type between
DEPARTMENT and EMPLOYEE
– Both participations are total
• CONTROLS
– 1:N relationship type between
DEPARTMENT & PROJECT
– The participation of PROJECT
is total
• WORKS_ON – The participation of
– M:N relationship type with attribute DEPARTMENT is partial
Hours (since a project can have (user’s consultation indicates
several employees working on it) that some deptt may control
– Both participations are total no projects)
39
 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 40
 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

41
 Alternative (min, max) notation for
Relationship Structural Constraints
• Specified on each participation of an entity type E in a relationship
type R
• 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) 42
 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
43
 COMPANY ER
Schema Diagram
using (min, max)
notation

44
Summary of Notation for ER Diagram

45
 Defining Constraints: Example

An ER Diagram with constraints defined below

• An employee may work in up to two departments or may not be
assigned to any department
• Each department must have one and may have up to three phone
numbers
• Each department can have anywhere between 1 and 10 employees
• Each phone is used by one, and only one, department
• Each phone is assigned to at least one, and may be assigned to up to 10
employees
• Each employee is assigned at least one, but no more than 6 phones46
 Defining Constraints:
Lets try some problems….

47
 UML Class Diagrams
• Represent classes (similar to entity types) as large
rounded boxes with three sections:
– Top section includes entity type (class) name
– Second section includes attributes
– Third section includes class operations (operations are not
in basic ER model)
• Relationships (called associations) represented as lines
connecting the classes
– Other UML terminology also differs from ER terminology
• Used in db design and object-oriented software design
• UML has many other types of diagrams for software
design (see Chapter 12 in Navathe)
48
UML Class Diagram for COMPANY
Database Schema

49
Other Alternative Diagrammatic
Notations for ER Diagrams (1/2)

50
 Other Alternative Diagrammatic
Notations for ER Diagrams (1/2)

For details refer Annexure A in the text book.

51
 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
52
 Example of a Ternary Relationship

Instances (s, j, p)
(supplier, project, part)
The SUPPLY Relationship

Three binary relationships not 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
53
 How to Represent Higher Degree
Relationships
• If needed, the binary and n-ary relationships can all be included
in the schema design
• Represent relationship as a relationship type of degree n or
break it down into several relationship types of smaller degrees
is tricky
• This decision must be based on the semantics or meaning of the
particular situation being represented
• Some DB design tools are based on variations of the ER model
that permit only binary relationships
– In this case, represent a ternary relationship as a weak entity with
no partial key and with three identifying relationships
54
Example: Ternary Relationship Type

The SUPPLY Relationship The weak

entity type
3 binary relationships not equivalent to SUPPLY SUPPLY is
identified by
the
combination
of its 3 owner
entities from
SUPPLY represented as weak entity type SUPPLIER,
PART, and
PROJECT

55
 Another Ex. of Ternary Relationship Type

OFFERS (i, s, c)
Constraints among the
relationships

• A relationship instance (i, s, c) should not exists in OFFERS unless an

instance (i, s) exists in TAUGHT_DURING, an instance (s, c) exists in
OFFERED_DURING, and an instance (i, c) exists in CAN_TEACH
• We may have instances (i, s), (s, c), and (i,c) in the three binary
relationship types with no corresponding instance (i, s, c) in OFFERS
56
Another Ex. of Ternary Relationship Type
• Based on the meaning of the
relationships, instances of
TAUGHT_DURING and
OFFERED_DURING can be
obtained from the instances in
OFFERS, but we can not infer the
instances of CAN_TEACH
• So TAUGHT_DURING and
OFFERED_DURING are redundant
and can be left out
Schema designer must analyze
• In general, 3 binary relations can
the meaning of each specific
not replace a ternary relationship,
situation to decide which of the
but it may happen under certain
binary and ternary relationship
additional constraints
types are needed 57
Representing Ternary Relationship Type
with three Binary Relationships
• If the CAN_TEACH
relationship is 1:1 (an
instructor can teach one
course and a course can be
taught by only one
instructor), then the ternary
relationship OFFERS can be
left out
• Because it can be inferred
from the 3 binary
relationships CAN_TEACH,
TAUGHT_DURING, and
OFFERED_DURING
58
An ER diagram for an Airline
Reservations System

59
 Data Modeling Tools
• A number of popular tools that cover conceptual modeling
and mapping into relational schema design.
– Examples: ERWin, S- Designer (Enterprise Application Suite), ER-
Studio, etc.
• POSITIVES:
– Serves as documentation of application requirements, easy user
interface - mostly graphics editor support
• NEGATIVES:
– Most tools lack a proper distinct notation for relationships with
relationship attributes
– Mostly represent a relational design in a diagrammatic form
rather than a conceptual ER-based design
(See Chapter 12 for details) 60
Some Automated Database Design Tools
COMPANY TOOL FUNCTIONALITY
Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration, space and security
management
Oracle Developer Database modeling, application development
2000/Designer 2000
Popkin Software System Architect Data modeling, object modeling, process modeling,
2001 structured analysis/design
Platinum Enterprise Modeling Data, process, and business component modeling
(Computer Suite: Erwin, BPWin,
Associates) Paradigm Plus
Persistence Inc. Pwertier Mapping from O-O to relational model
Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA

Resolution Ltd. Xcase Conceptual modeling up to code maintenance

Sybase Enterprise Data modeling, business logic modeling
Application Suite
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++
61