Entity Relationship

Model
 Chapter2: Entity Relationship Model
(T2: 42-65)

 Using High-Level Conceptual Data Models for

Database Design
 An Example of database Application
 Entity types, Entity sets, Attributes and Keys
 Relationships, Relationship types
 Roles and Structural Constraints
 Weak Entity Types

2 B.S.Shankar, Dept of MCA, VVIET

 Chapter2: Entity Relationship Model
(T2: 42-65)

 Refining the ER Design for the COMPANY Database

 ER Diagrams
 Naming Conventions and Design Issues
 Relationship types of degree higher than two

3 B.S.Shankar, Dept of MCA, VVIET

4 B.S.Shankar, Dept of MCA, VVIET
Using High-Level Conceptual Data Models
for Database Design

1st Step: Requirements analysis

2nd Step: Conceptual design
3rd Step: Logical design or data model mapping
4th Step: Physical design

5 B.S.Shankar, Dept of MCA, VVIET

 Using High-Level Conceptual Data
Models for Database Design

1st Step: Requirements analysis

 Database designers interview prospective
database users to understand and document
their data requirements

 Two types of requirements

• Functional requirements
• Database requirements

6 B.S.Shankar, Dept of MCA, VVIET

 Using High-Level Conceptual Data
Models for Database Design

 Functional requirements
 User defined operations that are applied to the
database
 Include updates and retrieval
 DFDs, Sequence diagram, scenarios can be
used to define

7 B.S.Shankar, Dept of MCA, VVIET

 Using High-Level Conceptual Data
Models for Database Design

 Database requirements
 Data and data type to be stored
 Constraints applied on data

8 B.S.Shankar, Dept of MCA, VVIET

 Using High-Level Conceptual Data
Models for Database Design
2nd Step: Conceptual design
 Create conceptual schema using high level
conceptual data model
 Conceptual schema is a description of the data
requirements of the users and includes entity types,
relationships, constraints.
 Conceptual schema do not include implementation
details and can be used to communicate with non
technical users.
 It can be used to ensure that all users data
requirements are met and no conflict exists
9 B.S.Shankar, Dept of MCA, VVIET
 Using High-Level Conceptual Data
Models for Database Design

3rd Step: Logical design or data model mapping

 Actual implementation of the database using a

commercial DBMS
 Conceptual schema is transformed from the high
level data model into the implementation data
model.

10 B.S.Shankar, Dept of MCA, VVIET

 Using High-Level Conceptual Data
Models for Database Design

4th Step: Physical design

 Internal storage structures, access paths, and file
organizations for the database files are specified

 In parallel with all steps, application programs are

designed and implemented as database
transactions corresponding to the high level
transaction specifications.

11 B.S.Shankar, Dept of MCA, VVIET

 Example: Company database

The company is organized into DEPARTMENTs

 Each department has a unique name, unique
number.
 An employee manages the department.
 We keep track of the start date of the department
manager.
 A department may have several locations.

12 B.S.Shankar, Dept of MCA, VVIET

 Example: Company database

Each department controls a number of PROJECTs.

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

13 B.S.Shankar, Dept of MCA, VVIET

 Example: Company database

Each EMPLOYEE's details are also stored

 Like social security number, address, salary, sex,
and birth date.
 Each employee works for one department but may
work on several projects.
 We keep track of the number of hours per week that
an employee currently works on each project.
 We also keep track of the direct supervisor of each
employee.

14 B.S.Shankar, Dept of MCA, VVIET

 Example: Company database

Each employee may have a number of DEPENDENTs.

 For each dependent, we keep track of their name, sex,

birth date, and relationship to employee.

15 B.S.Shankar, Dept of MCA, VVIET

 Minit Lnam Number
Fnam e
e Sex N 1
Name
Name WORKS_FOR Locations
ENO SSN Salary

EMPLOYEE Number of Employees DEPARTMENT

DOB
StartDate

1 1 1
MANAGES
supervisor supervisee CONTROLS
Hour
1 SUPERVISION N s N
M N
WORKS_ON

PROJECT
DEPENDENTS_OF

N Name
Locations
Number
An ER Schema diagram
for the COMPANY
DEPENDENT
Database

Name
16 B.S.Shankar, Dept of MCA, VVIET
Sex DOB Relationship
 ER Model

 A database can be modeled as:

 a collection of entities having attributes
 relationship among entities
 Entity, Entity type, Entity set
 Attributes, Type of attributes
 Keys
 Relationships, Relationship type
 Roles
 Constraints

17 B.S.Shankar, Dept of MCA, VVIET

 Entities

 An entity is an object that has existence and is

distinguishable from other objects
 Physical existence
• Person, car, employee etc.
 Conceptual existence
• Company, job, university course
 An entity lies within the scope of the business world
being modelled.
 Each entity has attributes – the particular properties
that describe it.
18 B.S.Shankar, Dept of MCA, VVIET
 Attributes

 Attributes are properties used to describe an entity.

 For example an EMPLOYEE entity may have a

Name, SSN, Address, Sex, BirthDate

 A specific entity will have a value for each of its

attributes.

 For example a specific employee entity may have

Name=‘Ram', SSN='123456789', Address ='731, RR
Nagar, Bangalore, Karnataka', Sex='M',
BirthDate='09-JAN-65’
19 B.S.Shankar, Dept of MCA, VVIET
 Attributes

 Each attribute has a data type associated with it e.g.

integer, string, date etc.
 Each attribute must have a unique name across the
entity.

20 B.S.Shankar, Dept of MCA, VVIET

 Types of Attributes
 Simple
 Each entity has a single atomic value for the
attribute. For example, SSN or Sex.
 Composite
 The attribute may be composed of several
components.
 The value of a composite attribute is the
concatenation of the values of its simple
attributes.
 Composition may form a hierarchy where some
components are themselves composite.
21 B.S.Shankar, Dept of MCA, VVIET
 Types of Attributes

 Composite
 If components of the composite attributes have to
be referred, it is necessary to store the
components separately.
 If composite attribute is referred only as a whole,
there is no need to subdivide it into component
attributes e.g. if address has to be referred as a
whole only, there is no need to divide it.

22 B.S.Shankar, Dept of MCA, VVIET

 Composite attributes

For example, Address (Apt#, House#, Street, City,

State, ZipCode, Country)
Name (FirstName, MiddleName, LastName).

23 B.S.Shankar, Dept of MCA, VVIET

 Types of Attributes

 Single-valued
 Only single value for a particular entity e.g. DOB
 Multi-valued
 An entity may have multiple values for that
attribute.
 Multiple value may have lower and upper bounds
on the number of values.
 For example,
Color of a CAR: {Color}
phone_numbers: {phone number}
24 B.S.Shankar, Dept of MCA, VVIET
 Types of Attributes

 Stored attributes
 Stored in the database
 Derived attributes
 Can be computed from other related attributes
 E.g. Birthdate ---stored
Age ----derived

Joining date ------stored

Year of Experience ---derived

25 B.S.Shankar, Dept of MCA, VVIET

 Types of Attributes: Example

26 B.S.Shankar, Dept of MCA, VVIET

 Null values

 A particular entity may not have the value for a

particular attribute
 Value is not applicable
 Value is unknown
 A special value NULL is written
 e.g. Every employee may not have Fax no.

27 B.S.Shankar, Dept of MCA, VVIET

 Complex attributes

 Composite attributes can be nested arbitrarily.

 Components of a composite attribute can be shown
in () and multivalued attribute can be shown in {}.

For example:
 {Address_phone (

{phone (Area_code, phone_number)},

Address (Street_Address
(Number, Street, Apartment_No), City, State, Zip)
) } 28 B.S.Shankar, Dept of MCA, VVIET
 Entity Type
 An entity type defines a collection of entities that
have the same attributes
 Each entity is defined in database by its name and
attributes.
 Each entity type must have a name that is unique
across the entire model and has a consistent
meaning across the modelling team and the end
users.
 For example,
 EMPLOYEE is an entity type
 PROJECT is an entity type.
29 B.S.Shankar, Dept of MCA, VVIET
 Entity set

 The collection of all entities of a particular entity type

in the database at any point of time is called an
entity set.
 The entity set is usually referred to using the same
name as the entity type.
For example,
 EMPLOYEE refers to both

 ‘type of entity’
 ‘set of entity’

30 B.S.Shankar, Dept of MCA, VVIET

 Notations

 Entity type by rectangular box enclosing the entity

type name
 Attributes by ovals attached to entity type by straight
line
 Composite attributes shown by attaching
components to it
 Multivalued by double oval

31 B.S.Shankar, Dept of MCA, VVIET

 Example

32 B.S.Shankar, Dept of MCA, VVIET

 Extension & Intension

 An entity type describes the schema or intension for

a set of entities that share structure.

 The collection of all entities of a particular entity type

are grouped into an entity set, is also called the
extension of the entity type.

33 B.S.Shankar, Dept of MCA, VVIET

 Extension & Intension

34 B.S.Shankar, Dept of MCA, VVIET

 Key attributes

 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.
 (Key attribute defines the each entity of an entity
type uniquely)
 Uniqueness of key attribute must hold for every
extension of the entity type.
 It is not the property of a particular extension of the
entity type, it is a constraint on all extension of entity
type.
35 B.S.Shankar, Dept of MCA, VVIET
 Key attributes

 A key attribute may be composite.

 For example,
Registration is a composite key of the CAR entity
type with components (Number, State).
 Some entity types have more than one key attributes,
those attributes can behave as keys on their own
separately, they are called candidate keys.

36 B.S.Shankar, Dept of MCA, VVIET

 Key attributes

 All key attributes should be underlined in ER diagram

 Selected key will work as Primary key.
 Other potential keys will be Alternate keys.
 An entity type may have no key, it is called a weak
entity type.

37 B.S.Shankar, Dept of MCA, VVIET

 Value Sets (Domains) of attributes

 Domain specifies the set of permitted values for each

attribute for each individual entity.
 For example,
 Birth Date: Range of all valid dates
 Employee Name: All possible range of names
 DeptCode: Set of all department codes
 Value sets are specified using the basic data types,
size and other constraints.
 Value set provides all possible values

38 B.S.Shankar, Dept of MCA, VVIET

 Value Sets (Domains) of attributes

 A : E  P(V)

 A is Attribute of E Entity Type having value set V, is

a function to the power set P(V)

 For composite attribute

 V = P(V1) * P( V2) * ……* P(Vn)

 Where V1, V2 ….Vn are the value set of each

component of composite arribute.

39 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

1. An entity type DEPARTMENT with attributes Name,

Number, Location, Manager, Manager_Start_Date.
Location is multivalued.
Name & Number are (separate) key attributes.

40 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

1. An entity type DEPARTMENT with attributes Name,

Number, Location, Manager, Manager_Start_Date.
Location is multivalued.
Name & Number are (separate) key attributes.

41 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

2. An entity type PROJECT with attributes Name,

Number, Location, Controlling_Department.
Name & Number are (separate) key attributes.

42 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

2. An entity type PROJECT with attributes Name,

Number, Location, Controlling_Department.
Name & Number are (separate) key attributes.

43 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

3. An entity type EMPLOYEE with attributes SSN,

Name, Sex, Address, Salary, Birth_date, Department
and Supervisor.
Name & Address are composite,SSN is key attribute.
Projects and Number_Of_Hours for which Employee
is working.

44 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

3. An entity type EMPLOYEE with attributes SSN,

Name, Sex, Address, Salary, Birth_date, Department
and Supervisor.
Name & Address are composite,SSN is key attribute.
Projects and Number_Of_Hours for which Employee
is working.

45 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

4. An entity type DEPENDENT with attributes

Employee_Name, Dependent_Name, Sex,
Birth_date, Relationship (to Employee)

46 B.S.Shankar, Dept of MCA, VVIET

 Initial Conceptual Design of COMPANY Database

4. An entity type DEPENDENT with attributes

Employee_Name, Dependent_Name, Sex,
Birth_date, Relationship (to Employee)

47 B.S.Shankar, Dept of MCA, VVIET

 Relationships
 A relationship is an association among two or more
entities.
 Whenever an attribute of one entity type refers to
the attribute of another entity type, some relationship
exists.
 Specifically a relationship relates two or more
distinct entities with a specific meaning
 For example, manager of the DEPARTMENT
refers to an employee who manages the
department.
 Department of EMPLOYEE refers to the
department for which the employee works.
48 B.S.Shankar, Dept of MCA, VVIET
 Relationships Type

 Relationships of the same type are grouped into a

relationship type.

 For example, the WORKS_FOR relationship type

in which EMPLOYEEs and DEPARTMENTs
entities participate,

 or The MANAGES relationship type in which

EMPLOYEEs and DEPARTMENTs entities
participate.
49 B.S.Shankar, Dept of MCA, VVIET
 Relationships Type (contd..)

 More than one relationship type can exist with the

same participating entity types.
 For example, MANAGES and WORKS_FOR are
distinct relationships between EMPLOYEE and
DEPARTMENT, but with different meanings and
different relationship instances.

50 B.S.Shankar, Dept of MCA, VVIET

 Relationships Type: Example

Initial Lnam Number

Fnam e
e N 1
Fnam
Name
Name e WORKS_FOR Locations
EN
Sex Fnam
O
e

EMPLOYEE DEPARTMENT
DOB
StartDate

1
1
MANAGES

51 B.S.Shankar, Dept of MCA, VVIET

 Relationships Set

 A relationships set is a set of relationships of the

same type.
 A relationship set and a relation type are referred to
by the same name.
 The relationship set R is a set of relationship
instances ri, where each ri associates n individual
entities (e1, e2, ….., en) and each entity ej in ri is a
member of entity type Ej,
1≤ j ≤ n
 E.g. each employee and department participates in
the relationship of works_for.
52 B.S.Shankar, Dept of MCA, VVIET
Some instances in the WORKS_FOR relationship
set, which represents a relationship type
WORKS_FOR between Employee and department.

EMPLOYEE WORKS_FOR
DEPARTMENT
● e1 ■ r1
● e2
● e3
■ r2 ● d1

● e4 ■ r3 ● d2

● e5 ● d3
■ r4

•••
● e6
■ r5
•••

● e7
■ r6
•••

■ r7 Binary Relationship
53 B.S.Shankar, Dept of MCA, VVIET
 Degree of Relationships Type

 The degree of a relationship type is the number of

participating entity types.
 Binary Relationship
 Ternary Relationship

54 B.S.Shankar, Dept of MCA, VVIET

 Degree of Relationships Type
 Binary Relationship
 When two entities participate in relation.
 WORKS_FOR is binary relationship and
participating entities are EMPLOYEE and
DEPARTMENT
 Ternary Relationship
 When three entities participate in relation.
 SUPPLY is ternary relationship and participating
entities are SUPPLIER, PROJECT and PARTS.

55 B.S.Shankar, Dept of MCA, VVIET

 Degree of Relationships Type: Example

Binary Relationship

EMPLOYEE PROJECT
WORKS_ON

Ternary Relationship

SUPPLIER
SUPPLY PROJECT

PART
56 B.S.Shankar, Dept of MCA, VVIET
 Some relationship instances in the
‘SUPPLY’ ternary relationship set

SUPPLIER
SUPPLY
● S1
PROJECT
● S2 ■ r1
•••

● j1
● j2
PART ■ r2

•••
● P1
● P2 ■ r3
● P3
•••

57 B.S.Shankar, Dept of MCA, VVIET

 Role names

 Each entity type that participate in a relationship

type plays a particular role in the relationship.
 Role name signifies the role that a participating
entity plays in each relationship instance.
 For example,
In the WORKS_FOR relationship type, EMPLOYEE
plays the role of employee or worker and
DEPARTMENT plays a role of department or
employer.
 Each participating entity type name can be used as
role name.
58 B.S.Shankar, Dept of MCA, VVIET
 Recursive relationship

 In some cases, same entity participates more than

once in a relationship type and plays different roles.
 In such cases, role names become necessary for
distinguishing the meaning of each participation.
 Such relationship types are called Recursive
relationship.

59 B.S.Shankar, Dept of MCA, VVIET

Recursive relationship: Example

Initial Lname
Fname
Address
Name
ENO Sex Salary

EMPLOYEE
DOB

supervisor supervisee

1 N
SUPERVISE

60 B.S.Shankar, Dept of MCA, VVIET

 A recursive relationship SUPERVISION between
EMPLOYEE in the supervisor role (1) and
EMPLOYEE in the subordinate role (2)

EMPLOYEE SUPERVISION

1
● e1
2
■ r1
e1 ● e2 1

e2 e3 ● e3
2
■ r2
e4 e5 ● e4 1
2

● e5 ■ r3
2 1
•••

■ r4
61 B.S.Shankar, Dept of MCA, VVIET
 Constraints on Relationships

 Structural Constraints on Relationship Types ( Also

known as ratio constraints) are determined from the
mini-world situation.

 Maximum Cardinality (or cardinality ratio)

 Minimum Cardinality (also called participation

constraint or existence dependency constraints)

62 B.S.Shankar, Dept of MCA, VVIET

 Constraints on Relationships

 Maximum Cardinality (or cardinality ratio) for Binary

relationship
 It refers to the number of entities to which another
entity can be associated via a relationship set
 Cardinality must be one of the following types:
 One to one
 One to many
 Many to one
 Many to many
 Shown by placing appropriate number on the link.
63 B.S.Shankar, Dept of MCA, VVIET
 One-to-one (1:1) Relationships

An entity in A is associated with at most one entity

in B, and an entity in B is associated with at most
one entity in A

64 B.S.Shankar, Dept of MCA, VVIET

One-to-one (1:1) Relationships

EMPLOYEE MANAGES
DEPARTMENT
● e1
● e2 ■ ● d1
● e3 r1
● d2
● e4 ■ ● d3
● e5 •••
r2

•••
•••

● e6 ■
● e7 r3

65 B.S.Shankar, Dept of MCA, VVIET

 One-to-many (1:N) Relationships

An entity in A is associated with any number of

entities in B, and an entity in B however can be
associated with at most one entity in A,

66 B.S.Shankar, Dept of MCA, VVIET

 One-to-many (1:N) Relationships

EMPLOYEE HAS
DEPPENDENT
● e1
● e2
■
r1 ● d1
● e3
● e4 ■ ● d2
r2 ● d3
● e5 ● d4
■
•••

● e6

•••
● e7 r3
■
r4
67 B.S.Shankar, Dept of MCA, VVIET
1:1 & 1:N Relationships: Example

68 B.S.Shankar, Dept of MCA, VVIET

 Many-to-one (N:1) Relationships

An entity in A is associated with at most one entity

in B, and an entity in B however can be
associated with any number of entities in A

69 B.S.Shankar, Dept of MCA, VVIET

 Many-to-1 (N:1) Relationships

EMPLOYEE WORKS_FOR

• e1 ■ r1 DEPARTMENT

• e2 ■ r2 ● D1
• e3 ■ r3 ● D2
• e4 ■ r4

•••
•••

•••

70 B.S.Shankar, Dept of MCA, VVIET

 Many-to-Many (N:1) Relationships

An entity in A is associated with any number of

entities in B, and an entity in B can also be
associated with any number of entities in A,

71 B.S.Shankar, Dept of MCA, VVIET

 Many-to-many (N:M) Relationships
EMPLOYEE WORKS_ON

• e1 ■ r1 PROJE CT

• e2 ■ r2 ● P1
• e3 ■ r3 ● P2
• e4 ■ r4
● P3
■ r5
•••

● P4
■ r6

•••
■ r7
•••

72 B.S.Shankar, Dept of MCA, VVIET

N:1 & N:M Relationships: Example

73 B.S.Shankar, Dept of MCA, VVIET

 Participation constraint or existence
dependency constraints

 The partition constraint specifies whether the

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

 Total Participation
 Partial participation

74 B.S.Shankar, Dept of MCA, VVIET

 Total Participation

 Total Participation is a constraint when every entity

in the entity set participates in at least one
relationship in the relationship set.
 Total Participation is also called existence
dependency.
 Shown by double lining the link
 For example
 Every employee must work in some department
 Every employee must work on some project

75 B.S.Shankar, Dept of MCA, VVIET

 Partial Participation

 Partial participation is the constraint when some

entities may not participate in any relationship in the
relationship set.
 Represented by single line link.

 Example: participation of ‘EMPLOYEE’ as

manager in relationship type ‘MANAGES’ is
partial

76 B.S.Shankar, Dept of MCA, VVIET

 Attributes of Relationship types

 Relationship types can also have attributes similar to

attributes of entity types.
 E.g. To record ‘Number of Hours per Week’ that an
employee works on a particular project, No_of_hours
can be included as an attribute with relationship type
‘Works_on’.
 Attribute ‘Manager_start_date’ can be included with
relationship type ‘Manages’.

77 B.S.Shankar, Dept of MCA, VVIET

 Weak Entity Types

 An entity that does not have a key attribute is called

weak entity type
 A weak entity can not be identified without its owner.
 A weak entity type must participate in an identifying
relationship type with an owner or identifying entity
type.
 A weak entity type always has a total participation
constraint (existence dependency) with respect to its
identifying relationship.

78 B.S.Shankar, Dept of MCA, VVIET

 Weak Entity Types
 Weak entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the
identifying entity type
For example:
 Weak Entity Type: DEPENDENT

 Identifying Relationship: HAS_DEPENDENTS

 Identifying Entity Type: EMPLOYEE

 Partial key of DEPENDENT: Dependent_name

 Thus, Primary key of DEPENDENT TABLE: (SSN,

Dependent_name) B.S.Shankar, Dept of MCA, VVIET
79
 Weak Entity Types

name Salary
ENO Sex
Address
EMPLOYEE
DOB

HAS_DEPENDENT

DEPENDENT

Name
Sex DOB Relationship
80 B.S.Shankar, Dept of MCA, VVIET
 Refining the ER Design for the
Company Database

 The cardinality ratio and participation constraint of

each relationship type in company database can be
determined by the following requirements:

1. ‘manages’ a 1:1 relationship type between employee

and department
 employee’s participation is partial but department
participation is mandatory i.e. total
 the attribute StartDate is assigned to the
relationship type
81 B.S.Shankar, Dept of MCA, VVIET
 Refining the ER Design for the
Company Database (contd..)
2. ‘works_for’, a N:1 relationship type between
employee and department
 Both participations are total.
3. ‘controls’, a 1:N relationship type between
department and project
 Participation of project is total but Participation of
department is partial
4. ‘supervision’, a 1:N relationship type between
employee and employee
 Both participation is partial

82 B.S.Shankar, Dept of MCA, VVIET

 Refining the ER Design for the
Company Database (contd..)
5. ‘works_on’, a M:N relationship type between
employee and project
 Both participations are total.
 Attribute for this can be No-of-hours.
6. ‘has_dependents’, a 1:N relationship type between
employee and dependent
 Participation of dependent is total but Participation
of employee is partial
 Relationship is identifying for weak entity
dependent.
83 B.S.Shankar, Dept of MCA, VVIET
 ER diagrams, naming conventions
and design issues

 In ER diagram, emphasis is on representing the

schema rather than the instances.
 Schema is much smaller than extensions
 Schema is relatively much more stable than
extensions
 Schema changes rarely.
 Extensions changes frequently.

84 B.S.Shankar, Dept of MCA, VVIET

 Notations for ER Diagrams

ENTITY

WEAK ENTITY

RELATIONSHIP

IDENTIFYING RELATIONSHIP
85 B.S.Shankar, Dept of MCA, VVIET
 Notations for ER Diagrams (contd..)

ATTRIBUTE KEY ATTRIBUTE

DERIVED ATTRIBUTE
MULTIVALUED ATTRIBUTE

••• COMPOSITE ATTRIBUTE

86 B.S.Shankar, Dept of MCA, VVIET
 Notations for ER Diagrams (contd..)

E1 R E2 TOTAL PARTICIPATION OF E2 IN R

1 N CARDINALITY RATIO 1:N FOR

E1 R E2
E1:E2 IN R

STRUCTURAL CONSTRAINT
(min,max)
R E (min,max) ON PARTICIPATION OF
E IN R

87 B.S.Shankar, Dept of MCA, VVIET

 Naming conventions of Schema
constructs

 Singular names for entity type and relationship type

 Entity type & Relationship Type:

 Uppercase
 Attribute names:
 Capitalized
 Role names:
 Lowercase

88 B.S.Shankar, Dept of MCA, VVIET

 Naming conventions of Schema
constructs

 Nouns: Entity Type name

 Verbs: Relationship Type

 Additional Nouns that describe the nouns

corresponding to Entity types: Attributes

 Binary relationship should be readable

 from left to right
 top to bottom

89 B.S.Shankar, Dept of MCA, VVIET

 Design Choices for ER Conceptual Design

 Schema design is an iterative process, it

continues until the most suitable design is
reached.

90 B.S.Shankar, Dept of MCA, VVIET

 Alternative Notations for ER Diagrams

For specifying structural constraints on relationships

 This involves associating a pair of integer numbers
(min, max) with each participation of an entity type E
in a relationship type R,
 min=0 partial participation
 min>0 total participation (mostly 1)
 Max = 1 or N
 Either cardinality ratio and single/double line

 Or (min, max)

91 B.S.Shankar, Dept of MCA, VVIET

 Initial Lname Number
Fname
Address (4,N) Name
name (1,1) WORKS_FOR Locations
ENO Sex Salary department
employee
EMPLOYEE Number of Employees DEPARTMENT
DOB StartDate
(0,1)
manager (1,1) Controlling
department
(0,N)
(0,1) Department
(0,N) MANAGES managed
supervisee Worker
supervisor (1,N) CONTROLS
Hours
SUPERVISE Controlled
(0,N) (1,N) project
(1,1)
employee WORKS_ON
project PROJECT
HAS_DEPENDENT

dependent Name
(1,1)
Locations
Number
ER diagram for the
COMPANY Schema, with
structural constraints DEPENDENT
specified using (min,max)
notation.
92 Name B.S.Shankar, Dept of MCA, VVIET

Sex Relationship
DOB
 Ternary Relationship: SUPPLY

 Relationship set of SUPPLY is a set of relationship

instances (s, j, p), where s is a supplier who currently
supplying a part p to a project j.

93 B.S.Shankar, Dept of MCA, VVIET

 Three Binary relationships
 Three binary relationship sets:
 SUPPLIES: relationship instances (s, j),
 CAN_SUPPLY: relationship instances (s, p),
 USES: relationship instances (j, p),

94 B.S.Shankar, Dept of MCA, VVIET

 SUPPLY as Weak entity

 Some variations of ER model does not allow ternary

relationships.
 A ternary relationship must be represented by weak
entity without any partial key, and with three
identifying relationship.
 Three participating entity types SUPPLIER,
PROJECT, PART are owner entities.

95 B.S.Shankar, Dept of MCA, VVIET

 SUPPLY as Weak entity

 Three binary 1:N relationships relate SUPPLY to the

three participating entity types.

 A surrogate key “Supply_id” can also be introduced

to convert weak entity as regular entity

96 B.S.Shankar, Dept of MCA, VVIET

Choosing between Binary and Ternary (or
higher-degree) Relationships

97 B.S.Shankar, Dept of MCA, VVIET

 End of chapter-2

98 B.S.Shankar, Dept of MCA, VVIET