10

UNIT II
Entity Relational Model (E-R Model)
The E-R model can be used to describe the data involved in a real world enterprise in terms of
objects and their relationships.
Uses:
These models can be used in database design.
It provides useful concepts that allow us to move from an informal
description to precise description.
This model was developed to facilitate database design by allowing the specification of overall logical structure
of a database.
It is extremely useful in mapping the meanings and interactions of real world enterprises onto a conceptual
schema.
These models can be used for the conceptual design of database
applications.

1. OVERVIEW OF DATABSE DESIGN

The problem of database design is stated as below.
'Design the logical and physical structure of 1 or more databases to accommodate the information needs of
the users in an organization for a defined set of applications'.
The goals database designs are as below.
1. Satisfy the information content requirements of the specified
users and applications.
2. Provide a natural and easy to understand structuring of
the information.
3. Support processing requirements and any performance objectives
such as 'response time, processing time, storage space etc..

ER model consists the following 3 steps.

a. Requirements Collection and Analysis:

This is the first step in designing any database application.
This is an informal process that involves discussions and studies and analyzing the expectations of the users
& the intended uses of the database.
Under this, we have to understand the
following. 1.What data is to be stored n
a database? 2.What applications must be
built?
3.What operations can be used?
Example:
For customer database, data is cust-name, cust-city, and cust-no.

b. Conceptual database design:

The information gathered in the requirements analysis step is used to develop a higher-level description of
the data.
The goal of conceptual database design is a complete understanding of the database structure, meaning
(semantics), inter-relationships and constraints.

Characteristics of this phase are as below.

1.Expressiveness:
The data model should be expressive to distinguish different types of data, relationships and
constraints.

2. Simplicity and Understandability:

The model should be simple to understand the concepts.

3. Minimality:
The model should have small number of basic concepts.
4. Diagrammatic Representation:
The model should have a diagrammatic notation for displaying the conceptual schema.
 11
5.Formality:
A conceptual schema expressed in the data model must represent a formal specification of the data.
Example:
Cust_name : string;
Cust_no : integer;
Cust_city : string;

c. Logical Database Design:

Under this, we must choose a DBMS to implement our database design and convert the conceptual database
design into a database schema.
The choice of DBMS is governed by number of factors as below.
1. Economic Factors.
2. Organizational
Factors.
Explanation is as below.

1. Economic Factors:

These factors consist of the financial status of the applications.

a. Software Acquisition Cost:
This consists buying the software including language options such as forms, menu, recovery/backup
options, web based graphic user interface (GUI) tools and documentation.

b. Maintenance Cost:
This is the cost of receiving standard maintenance service from the vendor and for keeping the DBMS
version up to date.

c. Hardware Acquisition Cost:

This is the cost of additional memory, disk drives, controllers and a specialized DBMS storage.

d. Database Creation and Conversion Cost:

This is the cost of creating the database system from scratch and converting an existing system to the new
DBMS software.
e. Personal Cost:
This is the cost of re-organization of the data processing department.
f. Training Cost:
` This is the cost of training for Programming, Application Development and Database Administration.

g. Operating Cost:
The cost of continued operation of the database system.

2. Organizational Factors:
These factors support the organization of the vendor, can be listed as below.
a. Data Complexity:
Need of a DBMS.
b. Sharing among applications:
The greater the sharing among applications, the more the redundancy among files and hence the greater the
need for a DBMS.
c. Dynamically evolving or growing data:
If the data changes constantly, it is easier to cope with these changes using a DBMS than using a file
system.
d. Frequency of ad hoc requests for data:
File systems are not suitable for ad hoc retrieval of data.
e. Data Volume and Need for Control:
These 2 factors needs for a DBMS.
Example:
Customer database can be represented in the form of tables or diagrams.

3. Schema Refinement:
Under this, we have to analyze the collection of relations in our relational database schema to identify the
 12
potential problems.

4. Physical Database Design:

Physical database design is the process of choosing specific storage structures and access paths for the
database files to achieve good performance for the various database applications.
This step involves building indexes on some tables and clustering some tables.
The physical database design can have the following options.
1. Response Time:
This is the elapsed time between submitting a database transaction for execution and receiving a
response.
2. Space Utilization:
This is the amount of storage space used by the database files and their access path structures on
disk including indexes and other access paths.
3. Transaction Throughput:
This is the average number of transactions that can be processed per minute.
5. Security Design:
In this step, we must identify different user groups and different roles played by various users.
For each role, and user group, we must identify the parts of the database that they must be able to access,
which are as below.

2.ENTITIES

1. It is a collection of objects.
2. An entity is an object that is distinguishable from other objects by a set of attributes.
3. This is the basic object of E-R Model, which is a 'thing' in the real world with an independent existence.
4. An entity may be an 'object' with a physical existence.
5. Entities can be represented by
'Ellipses'. Example:
i. Customer, account etc.

3. ATTRIBUTES
Characteristics of an entity are called as an attribute.
The properties of a particular entity are called as attributes of that specified entity.
Example:
Name, street_address, city --- customer database.
Acc-no, balance --- account database.
Types:
These can be classified into following types.

1. Simple Attributes.
2. Composite Attributes.
3. Single Valued
Attributes.
4. Mutivalued Attributes.
5. Stored Attributes.
6. Derived Attributes.
Explanation is as below.

1. Simple Attributes:
The attributes that are not divisible are called as 'simple or atomic attributes'.
Example:
cust_name, acc_no etc..

2. Composite Attributes:

The attributes that can be divided into smaller subparts, which represent more basic attributes with
independent meaning.
These are useful to model situations in which a user sometimes refers to the composite attribute as unit but at
other times refers specifically to its components.
Example:
 13
Street_address can be divided into 3 simple attributes as Number, Street and Apartment_no.
Street_address

City State Zip

3. Single Valued Attribute:

The attributes having a single value for a particular entity are called as 'Single Valued Attributes'.
Example:
'Age' is a single valued attribute of 'Person'.

4. Muti Valued Attribute:

The attributes, which are having a set of values for the same entity, are called as 'Multi Valued Attributes'.
Example:
A 'College Degree' attribute for a person.i.e, one person may not have a college degree, another
person may have one and a third person may have 2 or more degrees.

A multi-valued attribute may have lower and upper bounds on the number of values allowed for each
individual entity.

5. Derived Attributes:
An attribute which is derived from another attribute is called as a ‘derived attribute.
Example:
‘Age’ attribute is derived from another attribute ‘Date’.

6. Stored Attribute:
An attribute which is not derived from another attribute is called as a ‘stored attribute.
Example:
In the above example,’ Date’ is a stored attribute.

4. ENTITY SETS
Entity Type:
A collection entities that have the same attributes is called as an 'entity type'.
Each entity type is described by its name and attributes.

Entity Set:
Collection of all entities of a particular entity type in the database at any point of time is called as an entity
set.
The entity set is usually referred to using the same name as the entity type.
An entity type is represented in ER diagrams as a rectangular box enclosing the entity type name.
Example:
Collection of customers.

5. Relationships

It is an association among entities.

6. Relationship Sets

It is a collection of relationships.
Primary Key:
The attribute, which can be used to identify the specified information from the tables.

Weak Entity:
Relationships.
A weak entity can be identified uniquely by considering some of its attributes in conjunction with the primary key of
another entity.
The symbols that can be used in this model are as follows.

1. Rectangles ---- Entities.

 14
2. Ellipses------------------------------------------Attributes.

3. Lines------------------------------------------------Links.

4. Diamonds -----
5. Under Lined Ellipse ----- Primary key.
Key Attribute.

6. Doubled Lined Ellipse ---- Multi Valued

Attribute. 7.Dashed Ellipse ---- Derived Attributes.

8. Double Lined Rectangle ---- ---- Weak ntity Set.

9. Double Lined Diamond-------------------------------Weak Entity Relationship.

Identifying Relationship.

10. Entity Set having a Primary Key ----

Srong Entity
Set.

----
11. Cylinder ---- Database.

12. Curved Inside Rectangle ---- --- End Users.

EXAMPLE:

Name
Street Acc_no Balance
City

Customer Cust_acc Account

Descriptive Attributes:
A relationship can also have some attributes, which are called as ‘descriptive attributes’.
These are used to record information about the relationship.
Example:
James of ‘Employees’ entity set works in a department since 1991.

Name Dno
Street Dname
City Since
Budget

Customer Works_in Departments

Instance:
 15
An instance of a relationship set is a set of relationships.
It is a snapshot of the relationship at some instant of time.
EX:
1111 1/1/91 60
70
2222 2/2/94
3/3/96 80
3333
 11

Ternary Relationship:

A relationship set, which is having 3 entity sets, is called as a ternary relationship.

7.Additional Features of the E-R Model

1. Key Constraints:
These can be classified into 4 types as below.
1. Many to Many:
An employee is allowed to work in different departments and a department is allowed to have several
employees.

Name Dno
Since Dname
Street
City
Budget

Customer Works_in Departments

2.One to Many:
1 employee can be associated with many departments, where as each department can be associated with at
most 1 employee as its manager.

Name Since Dno

Street Dname
City
Budget

Customer Works_in Departments

3. Many to One:
Each employee works in at most 1 department.i.e, many employees can work in same department.

Name Dno
Since Dname
Street
City
Budget

Customer Works_in Departments

4. One to One:

Each employee can manage at most 1 department.

Name Since Dno
Street Dname
City
Budget

Customer Departments
Works_in
2. Participation Constraints:
 12

The participation constraint specifies whether the existence of an entity depends on its being related to
another entity via the relationship type.
A department has at most one manager. This requirement is an example of participation constraints.
There are 2 types of participation constraints, which are as below.

1. Total.
2.Partial.
Explanation is as below.

1. Total:
An entity set dependent on a relationship set and having
one to many relationships is said to be ‘total’.
The participation of the entity set ‘departments’ in the relationship
set ‘manages’ is said to be total.

2. Partial:
A participation that is not total is said to be partial.

Example:
Participation of the entity set ‘employees’ in ‘manages’ is partial, since not every employee gets to
manage a department.
In E-R diagram, the total participation is displayed as a ‘double line’ connecting the participating entity type to
the relationship, where as partial participation is represented by a single line.
If the participation of an entity set in a relationship set is total, then a thick line connects the two.
The presence of an arrow indicates a key constraint.

Budget
No
Name Dname

Partial Participation

Employees Manages Department

Total Participation
Works_in
3. Weak Entity Set:

1. Explain ‘weak Entities’? (3 Marks)(Jan-2005)

(4 Marks)(Semptember-2005) (4 Marks)(Feb-2002)

Weak Entity Type:

Entity types that do not have key attributes of their own are called as weak entity types.
A weak entity type always has a ‘total participation constraint’.

A weak entity set can be identified uniquely only by considering some of its attributes in conjunction with
the primary key of another entity (Identifying owner).
For any weak entity set, following restrictions must hold.

a. The owner entity set and the weak entity set must participate in
a One-to-many relationship set, which is called as the
‘Identifying Relationship Set’ of the weak entity set.
b. The weak entity set must have total participation in the identifying relationship set.
 13
Example:

‘Dependents’ is an example of a weak entity set.

Partial key of the weak entity set:

The set of attributes of a weak entity set that uniquely identify a weak entity for a given owner entity is
called as ‘partial key of the weak entity set’.
Example:

‘Pname’ is a partial key for dependents.

The dependent weak entity set and its relationship to employees is shown in the following diagram.
Linking them with a dark line indicates the total participation of dependents in policy.
To understand the fact that dependents is a weak entity and policy is its identifying relationship, we draw
both with dark lines.
To indicate that ‘pname’ is a partial key for dependents, we underline it using a broken line.

No Cost Pname Age

Name --------

Employees Policy Dependents

4.Aggregation:

1. Explain ‘Aggregation’? (3 Marks, Jan-2005)

2. Explain how to use a ternary relationship instead of
‘aggregation’? (5 Marks, Jan-2005)
3. Explain ‘Aggregation in ER model? (4 Marks, July-
2004) (5 Marks, March-2003) (4 Marks, July-2002)

Aggregation is an abstraction for building composite objects from their component objects.
Aggregation is used to represent a relationship between a whole object and its component parts.
Aggregation allows us to indicate that a relationship set (identified through a dashed box) participates
in another relationship set.
This is illustrated with a dashed box around sponsors.
If we need to express a relationship among relationships, then we should use aggregation.
Aggregation versus Ternary Relationship:
We can use either aggregation or ternary relationship for 3 or more entity sets.
The choice is mainly determined by
a. The existence of a relationship that relates a relationship set to an
entity set or second relationship set.
b. The choice may also guided by certain integrity constraints that
we want to express.
 14
Name Employees No

Monitors
Until

Pid Since
Budget Dname Budget

Sponsors Departments
Projects

According to the

above diagram,

1.A project can be sponsored by any number of departments.

2.A department can sponsor 1 or more projects.
3.1 or more employees monitor each sponsorship.
(Many to Many Relationship)

Consider the constraint that each relationship be monitored by at most 1 employee.

We cannot express this constraint in terms of the ternary relationship in the following diagram. In that
we are using a ternary relationship instead of aggregation.
Aggregation groups a part of an E-Are diagram into a single entity set allowing us to treat the aggregate
entity set as a single unit without concern for the details of it’s internal structure.
Thus, the presence of such a constraint serves as another reason for using aggregation rather than a
ternary relationship set.

8.Conceptual Database Design With The ER Model

The information gathered in the requirements analysis step is used to develop a higher-level description of
the data.
The goal of conceptual database design is a complete understanding of the database structure, meaning
(semantics), inter-relationships and constraints.
Characteristics of this phase are as below.

1. Expressiveness:

The data model should be expressive to distinguish

different types of data, relationships and constraints.

2. Simplicity and Understandability:

The model should be simple to understand the concepts.

3. Minimality:

The model should have small number of basic concepts.

 15

4. Diagrammatic Representation:
 16
The model should have a diagrammatic notation for
displaying the conceptual schema.

5. Formality:

A conceptual schema expressed in the data model must

represent a formal specification of the data.

Example:
Cust_name: string;
Cust_no: integer;
Cust_city: string;

a. Entity Versus Relationships:

Suppose that each department manager is given a ‘Dbudget’ as shown in the figure.

Name Since Dno

Street Dname
City
Budget

Customer Works_in Departments

There is at most 1 employee managing a department, but a given employee could manage several
departments (1 to many relationships).
We can store starting date and ‘Dbudget’ for each manager-department pair.

This approach is natural, if we assume that a manager receives a single ‘Dbudget’ for each department that
he manages. But if the ‘Dbudget’ is the sum of all departments, then ‘manages’ relationship that involves
each employee will have the same value (total value).
So this leads to redundancy.

This can be solved by the appointment of the employee as a manager of a group of departments.
We can model ‘mgr_appt’ as an entity set for manager appointment, use a ternary relationship and we can
have at most 1 manager for each department due to 1 to many relationship.
 17

Name Since Dno

Street Dname
City
Budget

Customer Works_in Departments

Mgr_appt
Since Dbudget

Conceptual Database Design For Large Enterprises

The process of conceptual database design consists describing small fragments of the application in terms of
E-R diagrams.
For a large Enterprise, the design may
require, 1.More than 1 designer.
2.Span data and application by a number of user groups.
Using a high level semantic data model such as ER diagrams for conceptual design offers the additional
advantages that,
1. The high level design can be diagrammatically represented.
2. Many people, who provide the input to the design process, easily understand it.
An alternative approach is to develop separate conceptual schemas for different user groups and then
integrate all those.
To integrate, we must establish correspondences between entities, relationships and attributes, so that this
process is somewhat difficult.
The relations of degree 1 are called as ‘Unary Relations’. The relations of degree 2 are called as ‘Binary Relations’. The
relations of degree 3 are called as ‘Ternary Relations’.
 18
model
address
driver-id name license year

location
person owns car
report-number
date

driver participated accident

damage-amount

Car insurance compny

insurance
date−admitted
name
date−checked−out
ss#

patients
test−log Dr−Patient

test_id test performed_by

dss# name
test_name date time result

insurance
date−admitted
name
date−checked−out
ss#

patients
test−log Dr−Patient

test_id test performed_by

dss# name
test_name date time result
 19

RELATIONAL MODEL
A database is a collection of 1 or more ‘relations’, where each relation is a table with rows and columns.
This is the primary data model for commercial data processing applications.
The major advantages of the relational model over the older data models are,
1.It is simple and elegant.
2. simple data representation.
3. The ease with which even complex queries can be expressed.

Introduction:

The main construct for representing data in the relational model is a ‘relation’.
A relation consists of
1.Relation Schema.
2.Relation Instance.
Explanation is as below.

1. Relation Schema:

The relation schema describes the column heads for the table.
The schema specifies the relation’s name, the name of each field (column, attribute) and the ‘domain’ of
each field.
A domain is referred to in a relation schema by the domain name and has a set of associated values.
Example:
Student information in a university database to illustrate the parts of a relation schema.

Students (Sid: string, name: string, login: string, age: integer, gross: real)

This says that the field named ‘sid’ has a domain named ‘string’.
The set of values associated with domain ‘string’ is the set of all character strings.

2. Relation Instance:

This is a table specifying the information.

An instance of a relation is a set of ‘tuples’, also called ‘records’, in which each tuple has the same number
of fields as the relation schemas.
A relation instance can be thought of as a table in which each tuple is a row and all rows have the same
number of fields.
The relation instance is also called as ‘relation’.
Each relation is defined to be a set of unique tuples or rows.

Example:
Fields (Attributes, Columns)

sid Name login age Gross Field names

1111 Dave dave@cs 19 1.2
2222 Jones Jones@cs 18 2.3 Tuples (Records, Rows)
333 Smith smith@ee 18 3.4
4444 Smith smith@math 19 4.5

This example is an instance of the students relation, which consists 4 tuples and 5 fields. No two rows are
identical.
 20

Degree:
The number of fields is called as ‘degree’.
This is also called as ‘arity’.

Cardinality:
The cardinality of a relation instance is the
number of tuples in it. Example:
In the above example, the degree of the relation is 5 and the cardinality is 4.
Relational database:
It is a collection of relations with distinct relation names.
Relational database schema:
It is the collection of schemas for the relations in the database.
Instance:
An instance of a relational database is a collection of relation instances, one per
relation schema in the database schema.
Each relation instance must satisfy the domain constraints in its schema.

2.Integrity constraints over relations

An integrity constraint (IC) is a condition that is specified on a database schema and

restricts the data can be stored in an instance of the database.
Various restrictions on data that can be specified on a relational database schema in the
form of ‘constraints’. A DBMS enforces integrity constraints, in that it permits only
legal instances to be stored in the database.
Integrity constraints are specified and enforced at different times as below.

1. When the DBA or end user defines a

database schema, he or she specifies the
ICs that must hold on any instance of this
database.
2. When a data base application is run, the DBMS
checks for violations and disallows changes to
the data that violate the specified ICs.

Legal Instance:
If the database instance satisfies all the integrity constraints specified on the
database schema.
The constraints can be classified into 4 types as below.
1. Domain constraints
2 key constraints
3 Entity Integrity Constraints.
4.Referential Integrity Constraints.
 21

Data Independence
o Data independence can be explained using the three-schema architecture.
o Data independence refers characteristic of being able to modify the schema at one level
of the database system without altering the schema at the next higher level.

There are two types of data independence:

1. Logical Data Independence

o Logical data independence refers characteristic of being able to change the conceptual
schema without having to change the external schema.
o Logical data independence is used to separate the external level from the conceptual view.
o If we do any changes in the conceptual view of the data, then the user view of the data would
not be affected.
o Logical data independence occurs at the user interface level.

2. Physical Data Independence

o Physical data independence can be defined as the capacity to change the internal schema
without having to change the conceptual schema.
o If we do any changes in the storage size of the database system server, then the
Conceptual structure of the database will not be affected.
o Physical data independence is used to separate conceptual levels from the internal levels.
o Physical data independence occurs at the logical interface level.
 22

Fig: Data Independence

Relational Algebra in DBMS: Operations with Examples

RELATIONAL ALGEBRA is a widely used procedural query language. It collects instances of

relations as input and gives occurrences of relations as output. It uses various operations to
perform this action. SQL Relational algebra query operations are performed recursively on a
relation. The output of these operations is a new relation, which might be formed from one or
more input relations.
In this tutorial, you will learn:

 SELECT(σ)
 Projection(π)
 Rename (ρ)
 Union operation (υ)
 Set Difference (-)
 Intersection
 Cartesian product(X)
 23

 Join Operations

Basic SQL Relational Algebra Operations

Relational Algebra devided in various groups

Unary Relational Operations

 SELECT (symbol: σ)
 PROJECT (symbol: π)
 RENAME (symbol: ρ)

Relational Algebra Operations From Set Theory

 UNION (υ)
 INTERSECTION ( ),
 DIFFERENCE (-)
 CARTESIAN PRODUCT ( x )

Binary Relational Operations

 JOIN
 DIVISION

Let’s study them in detail with solutions:

SELECT (σ)
The SELECT operation is used for selecting a subset of the tuples according to a given selection
condition. Sigma(σ)Symbol denotes it. It is used as an expression to choose tuples which meet
the selection condition. Select operator selects tuples that satisfy a given predicate.

σp(r)

σ is the predicate

r stands for relation which is the name of the table

p is prepositional logic

Example 1

σ topic = "Database" (Tutorials)

Output – Selects tuples from Tutorials where topic = ‘Database’.
 24

Example 2

σ topic = "Database" and author = "guru99"( Tutorials)

Output – Selects tuples from Tutorials where the topic is ‘Database’ and ‘author’ is guru99.

Example 3

σ sales > 50000 (Customers)

Output – Selects tuples from Customers where sales is greater than 50000

Projection(π)
The projection eliminates all attributes of the input relation but those mentioned in the projection
list. The projection method defines a relation that contains a vertical subset of Relation.

This helps to extract the values of specified attributes to eliminates duplicate values. (pi) symbol
is used to choose attributes from a relation. This operator helps you to keep specific columns
from a relation and discards the other columns.

Example of Projection:

Consider the following table

CustomerID CustomerName
1 Google Active
2 Amazon Active
3 Apple Inactive
4 Alibaba Active
Here, the projection of CustomerName and status will give

Π CustomerName, Status (Customers)

CustomerName Status
Google Active
Amazon Active
Apple Inactive
Alibaba Active

Rename (ρ)
Rename is a unary operation used for renaming attributes of a relation.

ρ (a/b)R will rename the attribute ‘b’ of relation by ‘a’.

 25

Union operation (υ)

UNION is symbolized by ∪ symbol. It includes all tuples that are in tables A or in B. It also
eliminates duplicate tuples. So, set A UNION set B would be expressed as:

The result <- A ∪ B

For a union operation to be valid, the following conditions must hold –

 R and S must be the same number of attributes.

 Attribute domains need to be compatible.
 Duplicate tuples should be automatically removed.

Example

Consider the following tables.

Table A Table B
column 1 column 2 column 1 column 2
1 1 1 1
1 2 1 3
A ∪ B gives

Table A ∪ B
column 1 column 2
1 1
1 2
1 3

Set Difference (-)

– Symbol denotes it. The result of A – B, is a relation which includes all tuples that are in A but
not in B.

 The attribute name of A has to match with the attribute name in B.

 The two-operand relations A and B should be either compatible or Union compatible.
 It should be defined relation consisting of the tuples that are in relation A, but not in B.

Example

A-B
Table A – B
column 1 column 2
1 2
 26

Intersection
An intersection is defined by the symbol ∩

A∩B

Defines a relation consisting of a set of all tuple that are in both A and B. However, A and B
must be union-compatible.

Visual
Definition of Intersection
Example:

A∩B
Table A ∩ B
column 1 column 2
1 1

Cartesian Product(X) in DBMS

Cartesian Product in DBMS is an operation used to merge columns from two relations.
Generally, a cartesian product is never a meaningful operation when it performs alone. However,
it becomes meaningful when it is followed by other operations. It is also called Cross Product or
Cross Join.
Example – Cartesian product

σ column 2 = ‘1’ (A X B)

Output – The above example shows all rows from relation A and B whose column 2 has value 1

σ column 2 = ‘1’ (A X B)
column 1 column 2
1 1
1 1
 27

Summary
Operation(Symbols) Purpose
The SELECT operation is used for selecting a
Select(σ)
tuples according to a given selection condition
The projection eliminates all attributes of the in
Projection(π)
those mentioned in the projection list.
UNION is symbolized by symbol. It includes a
Union Operation(∪)
in tables A or in B.
– Symbol denotes it. The result of A – B, is a r
Set Difference(-)
includes all tuples that are in A but not in B.
Intersection defines a relation consisting of a se
Intersection(∩)
are in both A and B.
Cartesian operation is helpful to merge column
Cartesian Product(X)
relations.