You are on page 1of 8

Entity-Relationship Model

1. Basic Concepts
2. Design Issues
3. Mapping Constraints
4. Keys
5. Entity-Relationship Diagram
6. Weak Entity Sets
7. Extended E-R Features

Author: Prashanth B.A.

DATE: 28-02-2000
Basic Concepts:

Entity set:

The entity is thing / object in the real world containing set of properties and the values to those
properties. The values of the properties uniquely identify the entity uniquely. The entity may be concrete
such as person or it may be abstract like loan, loan, and intelligence etc.

The entities of the same type and properties form the entity sets.
Ex: the entity set customer contains the all the tuple of the same type.

The attributes are the descriptive properties of the entities. The domain specifies the range of
allowed values that the entity set can have.
Ex: the age attribute can take values b/w 1 to 105
The name attribute can take any string.

The various types of attributes used in the E-R model are as follows.

• Simple and Composite.

The simple attributes are those that is not having the sub-pats.
Ex: age, sex, salary

The composite attributes are those that is formed by combining two of more.
Ex: the name attribute composed of first-name, middle-name, last-name
the address attribute is composed of street, door no etc.

• Single valued and Multi-valued.

The single valued attributes are those consisting of single value for an entities in the entity set.
Ex: the employee number is constant for the employee.

The multi valued attributes are those which can take the range of values.
Ex: the salary of employee depends on experience.
The age of employee depends on time

• Null

This value is used when the attribute of an entity does not have value or undefined/unknown.
Ex: the value of residence phone of an employee is NULL at the time of joining.

• Derived

The value of this type of attributes is derived from other attributes of the entity. It depends on the
values of other entities.
Ex: consider assets of an person it terms of Rs, it depends on the salary, ancestral property, bank
balance, shares etc.

Relationship set:
Relationship set is an association among existing entities. Relationship set is set of relations of the
same type.
Ex: consider a customer table and assets. We can define a relationship owner b/w these two as

Id Last-name First-name Age Address Phone-no Assets

01 Ram Kosal 34 Add1 3422434 01

02 Krishna Ram 43 Add2 343343 02

03 Hasa Chandra 32 ADD3 03


04 Kanth Chandra 18 Add4 <NULL> <NULL>


Assets Total amount Salary Balance Ancestral

01 5,00,000 <NULL> 2,00,000 (3,00,000)
House, four
02 8,05,000 5,000 1,50,000 wheeler

03 2,50,000 5,000 2,45,000 <NULL>

Relationship set Owner

Mathematically the relationship set consists of entities N > = 2. If E1, E2, …. En are entity sets,
then a relationship set R is subset of

{ (e1,e2, .. , en) | e1 E1, e2 E2 ……, en En }

where (e1,e2,…… e3) is a relationship.

The number of entity set participate in the relationship set is called as degree of the relationship
set. In the above relation the entities that are present are customer and assets. Therefore the degree of the
relationship set is two / binary.

Mapping Constraints:
In E-R schema we may define certain constraints that the database must satisfy. The most
important types of constraints are mapping cardinalities & existence dependencies.

Mapping Cardinalities:
It specifies the number of entities to which another entity can be associated via a relationship set.
Consider a binary relationship set R b/w entities A and B the mapping cardinalities one of the following

• One to one
An entity in A is associated with at most one entity of B and Vice-Versa.
Ex: consider person and passport. Relationship is possessed.
• One to many
An entity of A can have any number of association with entities in B. but the entities of B can have at
most only one association with entity in A.
Ex: customer and account. Relationship is depositor.
• Many to one:
An entity of A can have only one association with B. but entities of B can have any number of
association with entities of A.
Ex: customer and loan . relationship is borrower.
• Many to Many
An entity in A can have any number of association with entities in B and vice- versa.
Ex: customer and sales man. Relationship is sells.

Existence dependencies:
Consider two entities X and Y. if existence of Y is depends on existence of X the we say that
entity Y is dependent on X. X is called a dominant entity and Y is subordinate entity.
Consider two entities customer & accounts. The account is dependent on customer. If we delete
the customer entity the corresponding entity in accounts is also deleted.

The entities in an entity set are identified uniquely by the key values. The are basically two types
of keys Primary Key and Foreign Key.
Primary Key is key formed by the set of attributes by which the entities in the entity set are
identified uniquely.
Foreign Key is a key in the table used to reference the attribute values of the other table. The
Foreign Key is Primary Key in the referencing entity set.

Entity-Relationship Diagram:

The database can be pictorially represented by the E-R diagram. It is relatively simple and easy to
write. Therefore it is adopted in the most database system. The elements of E-R diagram are as follows.
• Rectangles represents the entity sets
• Ellipses represents the attributes
• Diamonds represents the relationship sets
• Lines which links the attributes to entity set and entities to relationship set.
• Double Ellipses represents the multi-valued attributes.
• Dashed Ellipses represents the derived attributes.
• Double lines represent the total participation of entities in a relationship set.
The attributes of the entity set which are primary key is underlined.

Consider the entity set customer and loan. The primary keys are social-security number and
loan-number. The relationship b/w these two is One-to-One. Pictorially it is represented as follows

Social Customer
-security street Loan-
number amount

Customer Customer
name city

customer borrow loan

Weak Entity Sets:
Some times, an entity set doesn’t have an attribute to form a primary key. Such entity set is called
as the weak entity set. Entity set having a primary key is called as strong entity set. An entity set to be
meaningful it should be part of one-to-many relationship.
Consider a payment relation which is having the attribute payment-number, payment-date,
payment-amount. It doesn’t have a primary key because one or more loan shares the same payment-

The primary key of weak entity set is formed by the primary key of the strong entity set on which
the weak entity set existence is depends plus the weak entity set discriminator. Hence the primary key of
the payment is { loan-number, payment-number }
The weak entity set in the E-R diagram is indicated by the doubly outlined box with corresponding
identifying relationship set loan-payment.

Payment-No Payment-
Loan- ---------- amount

Loan Loan-
payment payment

Extended E-R Features:

These features are extension to the basic E-R concepts. The features can be listed as follows
• Specialization
• Generalization
• Attribute Inheritance
• Aggregation.

The process of sub-grouping of entities within the entity set is called as specialization.
The some entities in the entity set may distinct in some form from other entity set. The subset of
entities in the entity set does not share the some distinct attributes with other entities. The E-R diagram
provides a grouping mechanism to specify this.
Consider the entity set account with the attributes account-number and amount. The account can
be classified further into
• Savings-account
• Checking-account

These account types are derived from base entity account hence it contains all the properties
of account with additional attributes. The Savings-account contains additional attributes
interest-rate. The Checking-account contains additional attribute overdraft-amount. The
specialization of account allows us to distinguish among accounts based on the type of account.

Account-No Balance


A Overdraft-
Interest-rate amount

Savings-account Checking-account

Specialization and Generalization


The generalization is a reverse process of specialization. There is no distinction in the E-R

diagram. The both the processes applied in combination to while designing the E-R schema for the
enterprise. Differences in these approaches in their starting point and overall goal.

Specialization starts at the single entity set. It identifies the groups among the entity set. These
lower level entity set have attributes and participate in the relationship. And the do not apply to all entities
in the higher level.

Generalization proceeds from the recognition of the sameness among the various entity sets.
Based on these commonalties generalization synthesizes these sets into a single higher-level entity set.

Attribute Inheritance:

The property of higher-level entity set and the lower-level entity set is the attribute inheritance.
The lower-level entity set inherits the attributes of the higher-level entity set.

Ex: the savings-account and the checking-account inherit the attribute balance of entity account. The lower-
level entity set also participates in the relationship in which higher-level entity set participates.
It is an abstraction through which relationships are treated as higher-level entities.

Customer-street Loan-number amount

Customer-name Customer-city

customer loan



e-social-security Telehone-no


Consider the above example.

Each customer-loan pair may have a loan-officer of guiding while operating the accounts
in the loan. The E-R diagram is as shown above. It seems to be the two relations can be merged together. If
we do this, every customer-loan pair should have a loan-officer which is not true. The separation solves the
problem but it is redundant because the customer-loan pair is also present in the borrower relationship.

The aggregation solves this problem. We consider the relationship set borrower and entity set
customer and loan as a higher-level entity set borrower. It is mentioned in the dashed rectangle.
Design of E-R Database Schema:
While designing the database schema using E-R model the following decisions are to be made.

1. To represent an object, whether to use entity set or attribute.

2. The real world concept is expressed accurately by entity set or relationship set.
3. Which relationship has to use, binary or ternary
4. Whether to use strong entity set or weak entity set.
5. Whether to use generalization or aggregation is appropriate.

Design Phases:
Brief description of design phases as followes.

Specification of user Requirements:

The initial requirements are collected by interviewing the user who uses the database. The analysis
is done by the designer on the collected data. If he needs the more information he consults the user of the

Data Model:

The designer chooses the data model. He translates the above specifications into the appropriate
database schema using the concepts of that data model. The designer reviews the schema that all data
requirements are satisfied and no conflict in the schema.

The fully developed schema specifies the functional requirements. This specifies the transactions
can be performed on the data.

Ex: Modifying data, searching, deleting, and inserting the data.

Next the physical implementation is follows depending on the DBMS selected.