DATABASE DESIGN

BITS Pilani SESSION 1

Pilani Campus
 BITS Pilani
Pilani Campus

INTRODUCTION TO DATABASE
SYSTEMS
Learning Objectives

 Basic terminologies in Database

 Advantages of data base system over
conventional file system
 Architecture of data base system
 Three schema levels of data base
system

3
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Basic terminologies
Database and Database system
An organization contains different set of data.
The organization must have accurate and reliable data
for effective decision making.
An organization can not run without data.
So the data in the organization should be maintained
properly.
Database is used to maintain the data in proper way.
A data base is a collection of data and a database
system is computerized record keeping system.
The data are stored in the secondary storage device
(permanent Storage) in the form of files, tables, objects,
etc. 4
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Basic terminologies

A file is a collection of one or more record(s) where a

record is a collection of field values / attribute value.
A field is the lowest level of data item of a record or an
entity.
The collection of inter-related files is called as the
database.
The hierarchy is represented as follows:

Data Record File

Database

5
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Basic terminologies

A single database may contain more than one heterogeneous files.

Example:
The database for a manufacturing company contains the files as
1. Employee file – It is a collection of records of all the employees
working in the company
2. Customer file - It is a collection of records of all the customers
of the company
3. Inventory file – It is a collection of records of maintaining the
stock

6
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Basic terminologies

4. Invoice file – It is a collection of records of bills of the customers

The database of the company can be represented as follows

Employee Invoice File

File

Inventory File Customer File

7
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Basic terminologies

Database management System – The software which is used to manage the

data in the database is called as the database management system.
The management represents the following
(i) Creating a new database for collecting the data
(ii) Adding new data into the existing database
(iii) Deleting existing data in the database
(iv) Modifying an existing data in the database
(v) Listing data of the database with or without using a condition.

8
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
1. Redundancy can be reduced
When data are redundant, we face two problems.
They are
i. Wastage of spaces in the disk
ii. Inconsistency problem
In data base system, redundancy can be avoided with a
mechanism called as Normalization.
Normalization is the procedure which removes the
unwanted duplicate data by splitting the table into
two or more tables. For Eg.
Assume that a table consists of the data of the students
who are doing a particular course.
9
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
Student table

Stu# StuName dept# Coun# CounName

S101 Ram D1 ST002 Dr. Jackson

S102 Bala D2 ST002 Dr.Jackson
S111 Madhu D1 ST001 Dr. Venkat
S122 Divya D1 ST001 Dr. Venkat
S115 Hema D2 ST001 Dr. Venkat
S103 Sachin D1 ST001 Dr. Venkat

Coun# - Counselor Id CounName – Counselor name

10
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
The above table is split into two tables (Student and Staff)
as follows:
Student Staff
Stu# StuName dept# Coun# Coun# CounName
S101 Ram D1 ST002
S102 Bala D2 ST002 ST001 Dr. Venkat
S111 Madhu D1 ST001 ST002 Dr. Jackson
S122 Divya D1 ST001
S115 Hema D2 ST001
S103 Sachin D1 ST001
Duplicate data related to staff is reduced

11
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
2.Inconsistency is avoided
If the value of the attribute shows similar value when it
is accessed by two different applications, then data is
said to be Consistent.
Inconsistency may arise if they are redundant.
When duplication is avoided, there is no possibility of
Inconsistency (Single copy has a single value only).
Though multiple copies are available and when a
transaction accesses any one of the copy, a
procedure in data base system called as “Propagating
updates“ updates the latest value in all the copies.
It avoids inconsistency.
12
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
3.Data can be shared
Concurrently, data can be accessed by more than one
application.
Database which share data to multiple applications is
called as the distributed data base.
Distributed data base creates multiple mirror image
copies of data and are shared with different
applications that are executed in different locations.
When any modification is done on the mirror image
copies, they automatically updated in the original copy
of the data.
Example: Railway reservation system shares the data to
different reservation counters.
13
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
4.Data can be integrated
Data that exist in different files can be integrated
(Combined) to answer the query of an application.
Example:
Assume that tables Student and Staff consist of the data
about the students and staff who handle various
courses.
To answer a query , “List the students who have scored
more than 90% of marks in various subjects and the
information of the staff who handled the subject”, we
need the data from both the tables (Student and
Staff)
14
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
5. Security mechanism can be applied
Confidential data should be secured from unauthorized
users.
To protect them from unauthenticated access, data
base systems support a security mechanism known
as Control access mechanism.
The control mechanism is divided into two types such as
Software Controlling mechanism and hardware
control mechanism.
Software Control mechanism – Data are protected
with the help of a software.

15
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
Examples:
a. Authentication procedure which asks login name and
password to distinguish authorized and others.
b. Encryption procedure which encrypts the data into
unknown format known as Cipher text so that it can be
understood by the intruders
Hardware Control mechanism – Data are permitted to
be accessed if the user should use physical component.
Example:
Usage of Access Entry card to enter into the prohibited
area.

16
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
6.Integrity can be maintained
The problem of integrity is the problem of ensuring that
data in the database is correct.
When the input values (data) are given to be added into
the database, there is a possibility of giving invalid
values.
Invalid values create a lot of problem in the data base
management.
Some conditions called as integrity constraints in
Database system can be enforced at the time of
creating the schema of the table.
These constraints check whether the inputs given by the
user are valid or not. 17
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
If they are invalid, the constraints produce appropriate
error messages without storing the invalid values in to
the table.
So there is no possibility of keeping Invalid values in the
table.
Example: Assume that a table is created for keeping the
information about employees working in hourly basis
and one of the field is HOURS_WORKED which is used
to calculate the wage.
We know that the field may have the value from 0 to 24.
If invalid value is given for the field constructing the
record, database system displays the error message if
integrity constraints are set.
18
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
7.Conflicting requirements can be balanced
We know that data base can be accessed by more than
one users and applications.
They may require different storage structures and access
methods.
DBA chooses the best storage structure and access
method so that performance of the system is
improved.
8.Data Independence
In the conventional file system, all the database are
dependent data.

19
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
When the modification is to be performed on the storage
structure, or if we need to make changes in the application of
the data base also, the data is said to be dependent data.
If the application does not require any updating, the data is said
to be independent data. Database system supports data
dependence.
There are two types of data independence. They are
i. Logical data independence
ii. Physical data independence

20
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Advantages of Database
System
Logical data independence - When the modification is
performed on the application of the data base, If we
do not need any change in the storage structure,
then the data dependence is called as Logical data
independence

Physical data independence - When the modification

is performed on the storage structure, If we do not
need any change in the application of the data base,
data dependence is called as Physical data
independence

21
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
Components of a database system
1. Data – Data which can be shared between multiple
applications and integrated for a single application.
Example for Sharing, the Faculty file can be accessed by
the HR department application related to the
promotion or for doing some other HR related
operations.
Same data can be accessed by the application of the
Finance department to prepare payroll.
Example for integrating, Faculty and student files are to
be accessed for preparing the list which requires data
of both students and Faculty member.
22
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
2. Hardware – The hardware components of the system that
consists of
a. SSD (Secondary Storage Device) such as Magnetic tape,
Disk to hold data permanently
b. Processors for executing data(ALU and Control Unit)
c. Main memory for executing and storing data temporarily
d. Network – the mechanism to connect more than one
Computers
3. Software – It is a software which is used for performing
the operation on the database.
It is called as the database management system (DBMS).

23
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
The requests from the users to access the data in the
database like adding / removing data, retrieving data
and updating data are handled by the DBMS.
4. Users – The users in the database system are
classified into four types as Application
Programmers, Naïve users, Sophisticated Users and
database administrator.
Application Programmers – They are the computer
professionals who write the application program in a
database language or a programming language to
access the data in the database.

24
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
Naïve Users are unsophisticated users who interact with
the system by invoking one of the application programs
that have been written by the application programmer.
Sophisticated Users are the users who interact without
writing programs.
Instead, they form their requests in a query language.
They submit the query to the tool called as query
processor.
The query processor breaks the query into multiple
instructions that the storage manager can understand.

25
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
Database Administrator (DBA) is the person who has a
central control over the data and the programs that
can access the data.
The functions of the DBA include
• Schema definition – Schema represents the overall
structure of the database.
DBA is responsible for deciding what fields are to be
used, their data types and their length.
• Storage structure and access method – DBA is
responsible for deciding how the data are to be
stored in the database (disk) and the way in which the
data can be accessed (Sequential and random)
26
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
• Modification in Schema definition and storage structure
–
DBA is responsible for making any changes in the data
structure of the database and storage structure
• Granting authorization for data access – DBA has the
rights to grant the permission to the users who are
authorized to access the data
• Performing periodical operations – DBA is responsible for
performing routine maintenance activities such as
- Doing back up periodically for preventing loss of data
- Monitoring the performance
- Ensuring that enough free disk space is available

27
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Architecture of Database
system
naïve users application Sophisticated DBA
programmers Users

application application query tools administration

interfaces programs tools
compiler DML queries DDL interpreter
& Linker

1 application DML compiler

program object code

query engine query processor

2 Buffer manager file manager authorization manager transaction

manager
storage manager

indices data dictionary

disk storage

data Statistical data

28
Database Design, Lecture-1, 03/02/2024 BITS Pilani, Pilani Campus
Architecture of Database
system
5. Other components
The systems has some more components such as indices,
data dictionary and Statistical data.
• Indices are the tables which are used for accessing the
records randomly
• Data dictionary is also table which is the data about data.
It contains information such as type, length, etc., about the
data stored in the database
• Statistical data – These are the data which contain
statistical information of the data (How often they are
accessed , who had accessed frequently, etc.,)

29
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
Database systems comprise of complex data structures.
Thus, to make the system efficient for retrieval of data
and reduce the complexity of the users, developers
use the method of Data Abstraction.
There are mainly three levels of data abstraction:
Internal Level: Actual PHYSICAL storage structure and
access paths.
Conceptual or Logical Level: Structure and constraints
for the entire database
External or View level: Describes various user views
30
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External

31
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External

User View 1 User View 2 . . . . . . User View n

Conceptual Level

Internal Level

32
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
External (PL/I) External (COBOL)
External Level DCL 1 EMPP 01 EMPRECORD
2 Emp# char (6) 02 Eno pic x(6)
2 Sal fixed Bin(5) 02 DeptNo pic x(20)

Conceptual level EMPLOYEE

E-NO CHARACTER (6)
DEPT-NO CHRACATER (10)
SALARY NUMERIC (5)

internal Level STORED EMP

PREFIX LENGTH = 20
EMP# TYPE =BYTE(6) OFFSET=0
DEPT# TYPE=BYTE(10) OFFSET=6
PAY TYPE=FULLWORD OFFSET=16

33
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
The purpose of each level is given below
Internal Level/Schema
The internal schema specifies the physical storage
structure of the database.
The internal schema is a very low-level representation of
the entire database.
It contains multiple occurrences of multiple types of
internal record.
These records are also called "stored records”.
Facts about Internal schema:
• The internal schema is the lowest level of data
abstraction
34
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
• It helps us to keep information about the actual
representation of the entire database.
• It is like the actual storage of the data on the disk in the
form of records
• The internal view tells us what data is stored in the
database and how they are stored
• It never deals with the physical devices.
• Instead, internal schema views a physical device as a
collection of physical pages
Conceptual Schema/Level
The conceptual schema mentions the Database structure
of the whole database for the community of users.

35
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
This schema hides information about the physical
storage structures and focuses on describing data
types, entities, relationships, etc.
This logical level lies between the user level and physical
storage view.
However, there is only single conceptual view of a single
database.
Facts about Conceptual schema:
• Defines all database entities, their attributes, and
their relationships
• Security and integrity information
36
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
• In the conceptual level, the data available to a user must
be contained in or derivable from the physical level
External Schema/Level
An external schema specifies the part of the database which
specific user is interested in.
It hides the unrelated details of the database from the user.
There may be "n" number of external views for each
database.
Each external view is defined using an external schema,
which consists of definitions of various types of external
record of that specific view.

37
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
An external view is just the content of the database as it
is seen by some specific particular user.
For example, a user from the sales department will see
only sales related data.
Facts about external schema:
• An external level is only related to the data which is
viewed by specific end users.
• This level includes some external schemas.
• External schema level is nearest to the user
• The external schema describes the segment of the
database which is needed for a certain user group
and hides the remaining details from the database
from the specific user group. 38
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
Goal of three level schema of Database
Here, are some Objectives of using Three schema
Architecture:
• Every user should be able to access the same data
but able to see a customized view of the data.
• The user need not to deal directly with physical
database storage detail.
• The DBA should be able to change the database
storage structure without disturbing the user's views.
• The internal structure of the database should remain
unaffected when changes made to the physical
aspects of storage.
39
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
Advantages of Database Schema
• We can manage data independent of the physical
storage
• Faster Migration to new graphical environments
• DBMS Architecture allows us to make changes on the
presentation level without affecting the other two
layers
• As each tier is separate, it is possible to use different
sets of developers.
• It is more secure as the client doesn't have direct
access to the database business logic
• In case of failure of one-tier, no data loss is acquired,
as we are always secure by accessing the other tier. 40
Database Design, Lecture-1 BITS Pilani, Pilani Campus
DBMS Schemas: Internal,
Conceptual, External
Disadvantages Database Schema
• Complete DB Schema is a complex structure which is
difficult to understand
• Difficult to set up and maintain
• The physical separation of the tiers can affect the
performance of the Database

41
Database Design, Lecture-1 BITS Pilani, Pilani Campus
Thanks

Database Design, Lecture-1, 03/02/2024 BITS Pilani, Pilani Campus

 Database Design

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Contact Session 2: Data Modelling

 What are we dealing today?

Database Design and ER Modelling

1.Steps in database Design Process
2.Concepts and notations
3.Relationships and constraints
4.Examples

Database Design 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Relationship Model

Database Design 4 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ERD

•It describes the data involved in a real world enterprise

in terms of objects and their relationship
•It illustrates the logical structure of databases .
•It is used in a phase called conceptual database design
•ER model is used mainly as a design tool and
documentation for the system
•Peter Chen developed ERDs in 1976.

Database Design 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity, Entity Set Attributes

•An entity is an object or concept about which you want

to store information.
•An entity may be an object with a physical existence
(person, car) or with a conceptual existence ( company,
university).
•An entity has properties which are known as attributes
of the entity.
•Attributes can be simple or composite.

Database Design 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Examples:
An entity STUDENT has the following attributes
StName (Student Name), Stu# (Student Number) , age and
dep(Department Name)

Database Design 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Database Design 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Relationship Model

The following is the ER diagram that consists of different types of attributes

9
Database Design 9 BITS Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Ent it y R elat ionshi p Model
•3. Relationship
•A relationship represents the association between two or more entities.
•Example: Assume that there are two entity sets: Customer and Loan as

Database Design 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Relationship Model

In the above diagram , there are two relationships.

First relationship is defined that Customer Mr. Ram has taken a loan of
Rs.10000 and its number is L8019.
The second relationship shows that Mr. SreeRam has received the loan
amount of Rs.30000 and its loan number is L1005.
Entity set
It is a set of entities of the same type that share same properties or
attributes.
Example: A set of persons who are customers at a particular bank can
be defined as the entity set Customer as in the following diagram

Database Design 11 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Relationship Model

Customer
Cust# Cust Name Address Balance(Rs)
C101 Mr.Ram Chennai-5 28235
C112 Mr.Raj Chennai-12 3140
C109 Mr.SreeRam Chennai-1 112
C107 Mr.Bala Chennai-2 12345

Database Design 12 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model

Symbols used for drawing ER diagrams and their usages

are :
Rectangles - To represent entity sets
Ellipses - To represent attributes
Diamonds - To represent the relationship set
Line - To link attributes with the entity and entity
to another entity
Double Ellipses – To represent multivalued attributes
Dotted Ellipses – To represent Derived attribute
Double rectangles – Representing weak entity sets

Database Design 13 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
Database Design 14 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ERD
•Identifying Entities
Given a system description you can identify entities by:

• Select all nouns

• Eliminate one’s not necessary

• Filter those for which system needs to store record.

• Identify the attributes that describes the entity

Database Design 15 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity

Entities are classified as:

– DOMINANT ENTITIES: An entity that does not depend on

another entity for its existence is a dominant or strong entity

– WEAK ENTITIES: An entity that depends on some other entity

for its existence

Database Design 16 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Existence Dependencies

• If the existence of entity x depends on the existence of

entity y, x is said to be existence dependent on y.

• Entity y is said to be a Dominant entity and x is said to

be a subordinate entity

Database Design 17 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Weak Entity
• A weak entity does not have a primary key of its own
• You can use a combination of the primary key of the dominant entity & an
attribute of the weak entity as the primary key of the weak entity.
• Thus a discriminator of Weak Entity + Prime attribute of the its Dominant
Entity. Emp_id

EMPLOYEE Emp_id+Nom_id+Relation

Has NOMINEE

Database Design 18 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relationships

• Entities are linked to each other through relationships.

Hence a relationship is an association between 2 entities.

• Eg:

Entity Relationship Entity

SUPPLIER supplies ITEM

Database Design 19 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Participation of an entity set in a relationship

•Total: The participation of an entity set E in a relationship

set R is said to be total if every entity in E participates in at
least one relationship R

•Partial: Part of the set of entities participate in some

relationship

Database Design 20 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Total & Partial Participation

amount
Soc SNo loan-no
Cust-name
cust-city

CUSTOMER borrower LOAN

Database Design 21 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Degree of Relationship
Unary : Degree 1 EMPLOYEE

manages

Binary : Degree 2 Soc SNo loan-no

amount
Cust-name cust-city

CUSTOMER borrower LOAN

Ternary : Degree 3

ITEM
ORDER Has

Order_dtls
N-ary : Degree n
Further Reading: https://www.gatevidyalay.com/tag/total-and-partial-participation-in-dbms/

Database Design 22 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Cardinality Ratio/ Mapping Cardinality
•Mapping Cardinality express the number of entities to which another entity can be
associated via a relationship set.
•Once the entities & relationship between the entities is identified you can represent
them in a ER diagram

Database Design 23 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER Example

Database Design 24 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER …(contd.)

This schema has 3 entity types

– EMPLOYEE
– DEPT
– PROJECT
& one weak entity type DEPENDENT

There is M:N relationship between PROJECT and EMP entity sets

There is a 1:1 relationship between DEPT and PROJECT

There is a 1:M relationship between DEPT and EMP entity sets

No of hrs is an attribute on the relation “assigned to” between EMP and PROJECT

Database Design 25 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Relationship Model

Steps to Create an ERD

Following are the steps to create an ERD.

Let's study them with an example:

In a university, a Student enrols in Courses.
A student must be assigned to at least one or more Courses.
Each course is taught by a single Professor.
To maintain instruction quality, a Professor can deliver only one course

Database Design 26 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model

Step 1) Entity Identification – Identification of entities

in
the given application
We have three entities
Student, Course and Professor and are
represented as follows

Student Course Professor

Database Design 27 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model

Step 2) Relationship Identification – Identifying the relationships

between the entities
We have the following two relationships
1. The student is assigned a course (Relationship between a Student and the
course)
2. Professor delivers a course (Relationship between a Course and the
Professor)

Database Design 28 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model
Step 3) Cardinality Identification – Identification of mapping
cardinalities between the entities.
A student can be assigned multiple courses
A Professor can deliver only one course
A Course can be taken by only one Professor

Database Design 29 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model

Step 4) Identify Attributes – Identifying the attributes of each entity of

the application and the primary key of the entity set.
For Entity Set Student, the attributes are Name and Number in which Number
is the Primary key
For Entity Set Course, the attributes are Course Name and Course Id in which
Course Id is the Primary key
For Entity Set Professor, the attributes are PName and PNumber in which
PNumber is the Primary key

Database Design 30 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Entity Relationship Model
Step 5) Create the ERD – Produce the Entity relationship diagram by linking
all the attributes with the corresponding Entities.
The resultant ERD for the given application is

Database Design 31 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Enhanced features of ER Model

Database Design 32 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Enhanced-ER (EER) Model Concepts

•Includes all modeling concepts of basic ER

•Additional concepts: subclasses / super classes,
specialization/generalization, categories, attribute inheritance
•The resulting model is called the enhanced-ER or Extended ER (E2R or
EER) model
•It is used to model applications more completely and accurately if
needed
•It includes some object-oriented concepts, such as inheritance
Database Design 33 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Subclasses and Super classes
•An entity type may have additional meaningful sub groupings of its entities
•Example: EMPLOYEE may be further grouped into SECRETARY, ENGINEER, MANAGER,
TECHNICIAN, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE,…
• Each of these groupings is a subset of EMPLOYEE entities
• Each is called a subclass of EMPLOYEE
• EMPLOYEE is the superclass for each of these subclasses
•These are called superclass/subclass relationships.
•Example: EMPLOYEE/SECRETARY, EMPLOYEE/TECHNICIAN
•These are also called IS-A relationships (SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A
EMPLOYEE, …)

Database Design 34 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Attribute Inheritance in Superclass / Subclass Relationships

•An entity that is member of a subclass inherits all attributes of the entity
as a member of the superclass
•It also inherits all relationships.

Database Design 35 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Specialization

Specialization is the process of defining a set of subclasses of a superclass

The set of subclasses is based upon some distinguishing characteristics of
the entities in the superclass
Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of
EMPLOYEE based upon job type.
– May have several specializations of the same superclass

Database Design 36 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Specialization

Example: Another specialization of EMPLOYEE based on method of pay is

{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
– Superclass/subclass relationships and specialization can be diagrammatically
represented in EER diagrams
– Attributes of a subclass are called specific attributes. For example, TypingSpeed of
SECRETARY
– The subclass can participate in specific relationship types. For example, BELONGS_TO
of HOURLY_EMPLOYEE

Database Design 37 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example of a Specialization

Database Design 38 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Generalization

• The reverse of the specialization process

• Several classes with common features are generalized into a

superclass; original classes become its subclasses
• Example: CAR, TRUCK generalized into VEHICLE; both CAR, TRUCK
become subclasses of the superclass VEHICLE.
– We can view {CAR, TRUCK} as a specialization of VEHICLE
– Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK

Database Design 39 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Constraints on Specialization and Generalization

• If we can determine exactly those entities that will become

members of each subclass by a condition, the subclasses are called
predicate-defined (or condition-defined) subclasses
– Condition is a constraint that determines subclass members
– Display a predicate-defined subclass by writing the predicate
condition next to the line attaching the subclass to its
superclass.
– Two types of conditions or constraints
• Attribute defined
Database Design • 40 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Constraints on Specialization and Generalization
• If all subclasses in a specialization have membership condition on same attribute of
the superclass, such specialization is called an attribute defined-specialization
– Attribute is called the defining attribute of the specialization
– Example: JobType is the defining attribute of the specialization {SECRETARY,
TECHNICIAN, ENGINEER} of EMPLOYEE
• If no condition determines membership, the subclass is called user-defined
– Membership in a subclass is determined by the database users by applying an
operation to add an entity to the subclass
– Membership in the subclass is specified individually for each entity in the
superclass by the user. Eg. Dependent of an employee can be wife, parent, child

Database Design 41 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Constraints on Specialization and Generalization

Two other conditions apply to a specialization/generalization:

1. Disjoint Constraint:
– Specifies that the subclasses of the specialization must be disjointed (an entity can be a
member of at most one of the subclasses of the specialization)
– Specified by d in EER diagram
– If not disjointed, overlapping constraint; that is the same entity may be a member of
more than one subclass of the specialization
– Specified by o in EER diagram

Database Design 42 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Constraints on Specialization and Generalization

2. Completeness Constraint:
– Total specifies that every entity in the superclass must be a member of some subclass in
the specialization/ generalization
– Shown in EER diagrams by a double line
– Partial participation − Not all entities are involved in the relationship.
– Partial participation is represented by single lines.

Database Design 43 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Constraints on Specialization and Generalization

• Hence, we have four types of specialization/generalization:

– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial

• Note: Generalization usually is total because the superclass is

derived from the subclasses.

Database Design 44 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example of disjoint partial Specialization

Database Design 45 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Categories (UNION TYPES – Multiple Inheritance)

•All of the superclass/subclass relationships we have seen thus far have a

single superclass
•A shared subclass is subclass in more than one distinct
superclass/subclass relationships, where each relationships has a single
superclass (multiple inheritance)
•In some cases, need to model a single superclass/subclass relationship
with more than one superclass
•Super classes represent different entity types
•Such a subclass is called a category or UNION TYPE
Database Design 46 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Categories (UNION TYPES)

•Example: Database for vehicle registration, vehicle owner can be a

person, a bank (holding a lien on a vehicle) or a company.
• Category (subclass) OWNER is a subset of the union of the three super
classes COMPANY, BANK, and PERSON
• A category member must exist in at least one of its super classes

Database Design 47 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example of
categories
(UNION
TYPES)

Database Design 48 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 UML Example for Displaying Specialization /
Generalization

Database Design 49 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Database Design 50 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Database Design
BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Contact Session 3: Relational Model

Database Design 2 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Session Outline

• Relational Model Concepts

• Relational Model Constraints and Relational Database Schemas
• Update Operations and Dealing with Constraint Violations

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-QUIZ

Which type of entity cannot exist in the database unless another type of
entity also exists in the database?

A. Weak entity
B. Strong entity
C. Dependent entity
D. Independent entity

Answer: A – Weak Entity - An entity that depends on some other entity for
its existence

Database Design 4 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-QUIZ

The attribute name could be structured as an attribute consisting of first

name, middle initial, and last name. This type of attribute is called
a) Simple attribute
b) Composite attribute
c) Multivalued attribute
d) Derived attribute

Answer: B - Composite attribute

Database Design 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-QUIZ

_____________ express the number of entities to which another entity can

be associated via a relationship set.
a) Mapping Cardinality
b) Relational Cardinality
c) Participation Constraints
d) None of the mentioned

Answer: A – Mapping cardinality - Mapping cardinality is the

maximum
number of relationship instances in which an entity can participate

Database Design 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-QUIZ

The entity which is created through specialization is considered as

a) Medium Class of entity
b) Mini Class of entity
c) Sub class of entity
D) Super class of entity

Answer: Sub class of entity

Database Design 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-QUIZ

• Generalization is

ANS: Grouping entity types, bottom up

Database Design 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Recap-Exercise
We wish to create a database for BITS Data Science trainings. For this, we must store
data about the Participants and the Faculty. For each course participant, identified by an
ID, we want to store her social security number, surname, age, sex, place of birth,
employer’s name, address and telephone number, previous employers (and periods
employed), the courses attended and the final assessment for each course. If a participant
is self-employed, we need to know her area of expertise, and, if appropriate, her title. For
somebody who works for a company, we store the level and position held. Each course
has a code and a title and any course can be given any number of times. Each time a
particular course is given, we will call it an ‘instance’ of the course. For each instance, we
represent the start date, the end date, and the number of participants. For each Faculty,
we will show the SSN, surname, age, place of birth, the instance of the course currently
being taught, those taught in the past and the courses that the faculty is qualified to
teach. All the faculty’s telephone numbers are also stored. An instructor can be
permanently employed by BITS or can be a guest faculty.
1) Identify the entity sets.
2) Identify the relationships .
3) Identify the structural constraints of all the relationships
4) Identify the specializations /generalizations involved.
Database Design BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
9
 Relational Model Concepts

• The relational Model of Data is based on the concept of a Relation

• A Relation is a mathematical concept based on the ideas of sets
• The model was first proposed by Dr. E.F. Codd of IBM Research in 1970

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics

• Using this representational (or implementation) model we represent a

database as collection of relations.

• The notion of relation here is different from the notion of relationship

used in ER modeling.

• Relation is the main construct for representing data in relational model.

• Every relation consists of a relation schema and Relation instance.

Database Design 11 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics
Relation Schema is denoted by R (A1, A2, A3,……,An)

Relation name Attribute list

• The number of columns in a relation is known as its degree or arity’.

• A relation of degree seven, which stores information about university

students, would contain seven attributes describing each student. as follows:

• STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)

• Using the data type of each attribute, the definition is sometimes written as:
• STUDENT(Name: string, Ssn: string, Home_phone: string, Address:
string,Office_phone: string, Age: integer, Gpa: real)

Database Design 12 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics

Database Design 13 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relation instance

Relation instance or Relation State (r) of R (thought of as a table)

• Each row in the table represents a collection of related data.
• Each row contains facts about some entity of same entity-set.
R = (A1, A2, A3,……., An)
r(R) is a set of n tuples in R
r = {t1, t2, t3,…….,tn}
• r is an instance of R each t is a tuple and is an ordered list of values.
• t = (v1 , v2 ,…, vn ) where vi is an element of domain of Ai

• Attribute A of relation R is accessed by notation - R.A.

Ex: Student (name, age, branch). Here Student is the relation name.
Student.age - denotes age attribute of Student relation.
Database Design 14 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics

• Entities of each type/set are stored as rows in a single relation.

• Hence in general, a relation corresponds to a single entity type in ER
diagram.
• In some cases a relationship between two entities can have some
specific attributes which can be captured in a relation (table).
• A row is called a tuple.
• The columns of the table represent attributes of that entity type.
• The column header is known as attribute or field.
• Data type or format of an attribute: is the format of data for that
attribute. Ex. Character strings, numeric, alphanumeric etc.
• Values that can appear in a column for any row is called the domain of
that attribute.
• Example: “USA_phone_numbers” are the set of 10 digit phone
numbers valid in the U.S.
Database Design 15 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics

Relational Database Schema is denoted by

S ={R1, R2, ……,Rn}

Database Relations in the

name database (tables)

Database Design 16 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model

For example the following is the relation for the

Students

Database Design 17 BITS Pilani, Deemed to be University under Section

BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Characteristics of a Relation

• Ordering of tuples is not significant.

• Ordering of values in a tuple is important.
• Values in a tuple under each column must be atomic (simple &
single).
• Example Multiple Phone numbers to be stored separately
under different columns namely phone #1, phone#2, etc.

• NULL values : used to represent the values of attributes that may be

unknown or may not apply to a tuple
• Interpretation (Meaning) of a Relation : a type of assertion
• An assertion is a statement in SQL that ensures a certain
condition will always exist in the database. Assertions are
like column and table constraints.
Database Design 18 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model Characteristics

• Key of a Relation:
– Each row has a value of a data item (or set of items) that uniquely
identifies that row in the table
• Called the key
– In the STUDENT table, SSN is the key

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 19 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Model - Keys

Key – An attribute in a relation that is used to distinguish one tuple from

another tuple is referred as the Key.
Different types of keys
1. Primary and Secondary keys
If the key uniquely identifies only one tuple/ record from all tuples / record
is called as the Primary Key.
Otherwise the key is called as the Secondary key.
Example: In the above relation Student, the attributes Stu# and StName
are the Primary and Secondary Keys respectively.

20
Database Design , Database Systems & Applications
20 ,Lecture 2, BITS
10-5-2020
Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Relational Model - keys
2. Composite or concatenated key
When a table has no primary key for unique identification, we can
combine more than one secondary keys to identify unique
record/tuple, the key is called as the Composite or Concatenated keys.

21
Database Design 21 BITS Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Relational Model - keys

3. Candidate Key – It is an attribute or a set of attributes that can act as a

primary key which can uniquely identify the record/tuple in a relation
4. Alternate key – If a relation has two separate primary key attributes say
a1 and a2 and one of the attribute is used as the primary key, the other is
called as alternate key for the primary key.
5. Foreign Key – It is one of the attribute in a table which is a primary key
of another table.
The candidate, alternate and foreign keys are explained in the following
tables

22
Database Design 22 BITS Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Relational Model - keys

23
Database Design 23 BITS Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Relational Model - Rules

Best Practices for creating a Relational Model

• Data need to be represented as a collection of relations
• Each relation should be depicted clearly in the table
• Rows should contain data about instances of an entity
• Columns must contain data about attributes of the entity
• Cells of the table should hold a single value
• Each column should be given a unique name
• No two rows can be identical
• The values of an attribute should be from the same domain

24
Database Design 24 BITS Pilani, Deemed to be University under Section
BITS Pilani,
3 of UGC
PilaniAct,
Campus
1956
 Terminology

Informal Terms Formal Terms

Table Relation
Column Header Attribute
All possible Column Domain
Values
Row Tuple
Table Definition Schema of a Relation
Populated Table State of the Relation

Database Design 25 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Constraints

Constraints are restrictions on data of a relation.

• Domain level Constrains – Format of data Ex. Character numeric etc.

• Entity integrity constraints – Primary key, unique key
• Referential integrity constraints– Foreign key
• Semantic Constraints.

Database Design 26 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Relational Integrity Constraints

• Constraints are conditions that must hold on all valid relation states.
• There are three main types of constraints in the relational model:
– Key constraints
– Entity integrity constraints
– Referential integrity constraints
• Another implicit constraint is the domain constraint
– Every value in a tuple must be from the domain of its attribute (or it could be
null, if allowed for that attribute)

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 27 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Key Constraints
• Superkey of R:
– Is a set of attributes SK of R with the following condition:
• No two tuples in any valid relation state r(R) will have the same value for SK
• That is, for any distinct tuples t1 and t2 in r(R), t1[SK]  t2[SK]
• This condition must hold in any valid state r(R)
• Key of R:
• It is used to uniquely identify any record or row of data from the table.
• ID is used as a key in the Student table because it is unique for each student. In the
PERSON table, passport_number, license_number, SSN are keys since they are unique for
each person.
• It is also used to establish and identify relationships between tables.
– A key is a "minimal" superkey
– That is, a key is a superkey K such that removal of any attribute from K
results in a set of attributes that is not a superkey (does not possess the
superkey uniqueness property)
Database Design 28 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Key Constraints (continued)
• Example: Consider the CAR relation schema:
– CAR(State, Reg#, SerialNo, Make, Model, Year)
– CAR has two keys:
• Key1 = {State, Reg#}
• Key2 = {SerialNo}
– Both are also superkeys of CAR
– {SerialNo, Make} is a superkey but not a key.
• In general:
– Any key is a superkey (but not vice versa)
– Any set of attributes that includes a key is a superkey
– A minimal superkey is also a key.

» Further Reading: https://www.javatpoint.com/dbms-keys#:~:text=Super%20key%20is%20an%20attribute,can%20also

%20be%20a%20key.

Database Design 29 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Key Constraints (continued)
• If a relation has several candidate keys, one is chosen arbitrarily to be
the primary key.
– The primary key attributes are underlined.
• Example: Consider the CAR relation schema:
– CAR(State, Reg#, SerialNo, Make, Model, Year)
– We chose SerialNo as the primary key

• The primary key value is used to uniquely identify each tuple in a relation
– Provides the tuple identity
• Also used to reference the tuple from another tuple
– General rule: Choose as primary key the smallest of the candidate keys (in
terms of size)
– Not always applicable – choice is sometimes subjective

Database Design 30 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-1

Consider the relation

CLASS(Course#, Univ_Section#, Instructor_name, Semester, Building_code,

Room#, Time_period, Weekdays, Credit_hours).

This represents classes taught in a university, with unique Univ_section#s.

Identify what you think should be various candidate keys with justification.

Database Design 31 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Entity Integrity

• Entity Integrity:
– The primary key attributes PK of each relation schema R in S cannot
have null values in any tuple of r(R).
• This is because primary key values are used to identify the individual tuples.
• t[PK]  null for any tuple t in r(R)
• If PK has several attributes, null is not allowed in any of these attributes
– Note: Other attributes of R may be constrained to disallow null
values, even though they are not members of the primary key.

Database Design 32 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Referential Integrity

• A constraint involving two relations

• Used to specify a relationship among tuples in two relations:
– The referencing relation and the referenced relation.

Database Design 33 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Referential Integrity

• Tuples in the referencing relation R1 have attributes FK (called foreign

key attributes) that reference the primary key attributes PK of the
referenced relation R2.
– A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].
• A referential integrity constraint can be displayed in a relational
database schema as a directed arc from R1.FK to R2.

Database Design 34 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Referential Integrity

Example from a Course/Class database:

•Course(CrsCode, DeptCode, Description)
•Class(CrsCode, Section, ClassTime)
 The referential integrity constraint states that CrsCode in the Class table
must match a valid CrsCode in the Course table.
 In this situation, it’s not enough that the CrsCode and Section in the Class
table make up the PK, we must also enforce referential integrity.
 When setting up referential integrity it is important that the PK and FK have
the same data types and come from the same domain, otherwise
the relational database management system (RDBMS) will not allow the
join.
Database Design 35 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Referential Integrity (or foreign key) Constraint

• Statement of the constraint

– The value in the foreign key column (or columns) FK of the
referencing relation R1 can be either:
• (1) a value of an existing primary key value of a corresponding
primary key PK in the referenced relation R2, or
• (2) a null.
• In case (2), the FK in R1 should not be a part of its own primary key.

Database Design 36 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Other Types of Constraints

• Semantic Integrity Constraints:

– based on application semantics (business rules, standards,
constraints) and cannot be expressed by the model
– Example: “the max. no. of hours per employee for all projects he or
she works on is 56 hrs per week”

Database Design 37 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Displaying a relational database schema and its constraints

• Each relation schema can be displayed as a row of attribute names

• The name of the relation is written above the attribute names
• The primary key attribute (or attributes) will be underlined
• A foreign key (referential integrity) constraints is displayed as a directed
arc (arrow) from the foreign key attributes to the referenced table
– Can also point the primary key of the referenced relation for clarity

Database Design 38 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 COMPANY DB-Relational Model

Database Design 39 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-2-Relational Model

• Consider the following relations for a database that keeps track of

business trips of salespersons in a sales office:
– SALESPERSON(Ssn, Name, Start_year, Dept_no)
– TRIP(Ssn, From_city, To_city, Departure_date, Return_date, Trip_id)
– EXPENSE(Trip_id, Account#, Amount)
• A trip can be charged to one or more accounts. Specify the foreign keys
for this schema, stating any assumptions you make. Draw the Relational
model

Database Design 40 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-3-Relational Model

Consider the following relations for a database that keeps track of

student enrollment in courses and the books adopted for each course:
STUDENT(SSN, Name, Major, Bdate)
COURSE(Course#, Cname, Dept)
ENROLL(SSN, Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_ISBN)
TEXT(Book_ISBN, Book_Title, Publisher, Author)
Draw a relational schema diagram specifying the foreign keys for this
schema.

Database Design 41 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Operations on Relations and constraints
• The following operations update and modify the database
• INSERT a tuple.
• DELETE a tuple.
• MODIFY a tuple.
• Integrity constraints should not be violated by the update operations.
• Several update operations may have to be grouped together.
• Updates may propagate (AKA cascading) to cause other updates
automatically.
• This may be necessary to maintain integrity constraints.

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 42 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Update Operations on Relations

• In case of integrity violation, several actions can be taken:

– Cancel the operation that causes the violation (RESTRICT or REJECT
option)
– Perform the operation but inform the user of the violation
– Trigger additional updates so the violation is corrected (CASCADE
option, SET NULL option)
– Execute a user-specified error-correction routine

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 43 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Operations on Relations and constraints

Actions need to be taken when FK is set , on operations like update, insert, and
FK
delete. PK
R1 R2
a b c p q r

c in R1 refers to p in R2

• To insert a tuple in R1 where the value for c is not in p of R2, then don’t
allow.

• What if a tuple in R2 is deleted:

Cascade, don’t allow, set to default, set to null.

• What if update on R2’s p happens:

Cascade, don’t allow, set to default, set to null.
Database Design 44 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Operations on Relations and constraints

Operation on Constraints need to be taken care

relations
Insert Null, Not Null, PK, unique, FK, format,
Domain
Delete FK
Update Null, Not Null, PK, unique, FK, domain, and
Semantic

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 45 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Operations on Relations and constraints
Emp Dept
eid ename age dno
dnum dname dlo
101 Kiran 28 10 c
105 Gopu 32 20 10 Payroll Che
121 Ahmed 29 20 20 Prod Hyd
136 John 28 20 30 Acct Bgl
138 Mike 30 30
143 Ali 38 10

Op : Care for constraints. Op : Care for constraints.

Insert :PK, Unique, null, notnull, format, FK Insert : PK, Unique, null, notnull, format
Update :PK, Unique, null, notnull, format, FK Update : PK, Unique, null, notnull, format, FK
Delete :No care Delete : FK

Copyright @2007 Ramez Elmasri, Shamkant B.

Navathe
Database Design 46 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Possible violations for each operation

• INSERT may violate any of the constraints:

– Domain constraint:
• if one of the attribute values provided for the new tuple is not of the specified
attribute domain
– Key constraint:
• if the value of a key attribute in the new tuple already exists in another tuple in
the relation
– Referential integrity:
• if a foreign key value in the new tuple references a primary key value that does
not exist in the referenced relation
– Entity integrity:
• if the primary key value is null in the new tuple

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 47 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Possible violations for each operation
• DELETE may violate only referential integrity:
– If the primary key value of the tuple being deleted is referenced from other
tuples in the database
• Can be remedied by several actions: RESTRICT, CASCADE, SET NULL
– RESTRICT option: reject the deletion
– CASCADE option: propagate the new primary key value into the foreign keys of the
referencing tuples
– SET NULL option: set the foreign keys of the referencing tuples to NULL
– One of the above options must be specified during database design for each
foreign key constraint

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 48 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Possible violations for each operation

• UPDATE may violate domain constraint and NOT NULL constraint on an

attribute being modified
• Any of the other constraints may also be violated, depending on the
attribute being updated:
– Updating the primary key (PK):
• Similar to a DELETE followed by an INSERT
• Need to specify similar options to DELETE
– Updating a foreign key (FK):
• May violate referential integrity
– Updating an ordinary attribute (neither PK nor FK):
• Can only violate domain constraints

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 49 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-4
• Suppose that each of the following Update operations is applied directly to
the database state shown below. Discuss all integrity constraints violated
by each operation, if any, and the different ways of enforcing these
constraints.

• Insert <‘Robert’, ‘F’, ‘Scott’, ‘943775543’, ‘1972-06-21’, ‘2365 Newcastle Rd, Bellaire, TX’, M,
58000, ‘888665555’, 1> into EMPLOYEE.
• Delete the EMPLOYEE tuple with Ssn = ‘123456789’.

Database Design 50 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-5
Suppose that each of the following Update operations is applied directly to
the database state shown below. Discuss all integrity constraints violated
by each operation, if any, and the different ways of enforcing these
constraints.

Insert <‘ProductA’, 4, ‘Bellaire’, 2> into PROJECT.

Insert <‘Production’, 4, ‘943775543’, ‘2007-10-01’> into DEPARTMENT.

Database Design 51 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-6

Suppose that each of the following Update operations is applied directly to

the database state shown below. Discuss all integrity constraints violated
by each operation, if any, and the different ways of enforcing these
constraints.

Insert <‘677678989’, NULL, ‘40.0’> into WORKS_ON.

Database Design 52 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-7

Suppose that each of the following Update operations is applied directly to

the database state shown below. Discuss all integrity constraints violated
by each operation, if any, and the different ways of enforcing these
constraints.

Insert <‘453453453’, ‘John’, ‘M’, ‘1990-12-12’, ‘spouse’> into DEPENDENT.

Delete the WORKS_ON tuples with Essn = ‘333445555’.

Database Design 53 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-8

• Suppose that each of the following Update operations is applied directly

to the database state shown below. Discuss all integrity constraints
violated by each operation, if any, and the different ways of enforcing
these constraints.

• Delete the PROJECT tuple with Pname = ‘ProductX’.

• Modify the Mgr_ssn and Mgr_start_date of the DEPARTMENT tuple with
Dnumber = 5 to ‘123456789’ and ‘2007-10-01’, respectively.

Database Design 54 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-9
• Suppose that each of the following Update operations is applied directly
to the database state shown below. Discuss all integrity constraints
violated by each operation, if any, and the different ways of enforcing
these constraints.

• Modify the Super_ssn attribute of the EMPLOYEE tuple with Ssn

=‘999887777’ to ‘943775543’.
• Modify the Hours attribute of the WORKS_ON tuple with Essn
=‘999887777’ and Pno = 10 to ‘5.0’.
Database Design 55 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Exercise-10

Give an example of an attribute (or set of attributes) that you can deduce
is not a candidate key, based on this instance being legal.

Is there any example of an attribute (or set of attributes) that you can
deduce is a candidate key, based on this instance being legal?

Database Design 56 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Summary
Presented Relational Model Concepts
– Definitions
– Characteristics of relations
Discussed Relational Model Constraints and Relational Database Schemas
– Domain constraints’ - It makes sure that the data value entered for that particular column matches with
the data type defined for that column .
– Key constraints - A unique constraint (also referred to as a unique key constraint) is a rule that forbids
duplicate values in one or more columns within a table.
– A primary key constraint is a column or combination of columns that has the same properties as a unique
constraint.
– Entity integrity - Entity integrity is concerned with ensuring that each row of a table has a unique and non-
null primary key value;
– Referential integrity - You can use a primary key and foreign key constraints to define relationships
between tables.
– The reference from a row in one table to another table must be valid.

Described the Relational Update Operations and Dealing with Constraint

Violations
Database Design BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
57
 Database Design

BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Contact Session 4: ER to Relational Mapping

 What are we dealing today?

ER to Relational Mapping
1.Mapping rules/guidelines for mapping ER
constructs
2.Mapping rules/guidelines for mapping
hierarchies
3.Examples

Database Design 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Entity
Relationship
Model:
COMPANY
database.

Database Design 4 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Database Design 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types
• For each regular (strong) entity type E in the ER
schema, create a relation R that includes all the
simple attributes of E.
• Include only the simple component attributes of a
composite attribute
• Choose one of the key attributes of E as the primary
key for R

Database Design 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types
• If the chosen key of E is a composite, then the set of
simple attributes that form it will together form the
primary key of R
• If multiple keys were identified for E during the
conceptual design, the information describing the
attributes that form each additional key is kept in
order to specify secondary (unique) keys of relation R.

Database Design 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Database Design 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 2: Mapping of Weak Entity Types
• For each weak entity type W in the ER schema with
owner entity type E, create a relation R and include all
simple attributes (or simple components of
composite attributes) of W as attributes of R.
• In addition, include primary key of E as foreign key
attributes of R (this takes care of mapping the
identifying relationship type of W)
• The primary key of R is the combination of the
primary key(s) of the owner(s) and the partial key of
the weak entity type W(if any)
Database Design 9 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm

Database Design 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 2: Mapping of Weak Entity Types
• If there is a weak entity type E2 whose owner is also a
weak entity type E1, then E1 should be mapped
before E2 to determine its primary key first
• It is common to choose the propagate (CASCADE)
option for the referential triggered action on the
foreign key in the relation corresponding to the weak
entity type, since a weak entity has an existence
dependency on its owner entity. This can be used for
both ON UPDATE and ON DELETE.
Database Design 11 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
• For each binary 1:1 relationship type R in the ER
schema, identify the relations S and T that correspond
to the entity types participating in R.
• There are three possible approaches to represent this
relationship types:
1) Foreign key approach
2) Merged relationship approach
3) Cross-reference or relationship relation approach

Database Design 12 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
1) Foreign key approach:
• Choose one of the relations—S, and include as a foreign
key in S the primary key of T
• It is better to choose an entity type with total
participation in R in the role of S
• Include all the simple attributes of the 1:1 relationship
type R as attributes of S.

Database Design 13 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
1) Foreign key approach:

Database Design 14 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
2) Merged relationship approach :
• Mapping of a 1:1 relationship type is to merge the two
entity types and the relationship into a single relation.
• This is possible when both participations are total, as
this would indicate that the two tables will have the
exact same number of tuples at all times.

Database Design 15 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
3) Cross-reference or relationship relation approach :
• set up a third relation R for the purpose of cross-
referencing the primary keys of the two relations S and T
representing the entity types.
• The relation R is called a relationship relation (or
sometimes a lookup table), because each tuple in R
represents a relationship instance that relates one tuple
from S with one tuple from T.

Database Design 16 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 3: Mapping of Binary 1:1 Relationship Types
3) Cross-reference or relationship relation approach :
• The relation R will include the primary key attributes of S
and T as foreign keys.
• The primary key of R will be one of the two foreign keys,
and the other foreign key will be a unique key of R.
• The drawback is having an extra relation, and requiring
an extra join operation when combining related tuples
from the tables.

Database Design 17 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 4: Mapping of Binary 1:N Relationship Types
• For each regular binary 1:N relationship type R, identify
the relation S that represents the participating entity
type at the N-side of the relationship type
• Include as foreign key in S the primary key of the
relation T that represents the other entity type
participating in R
• Include any simple attributes of the 1:N relationship
type as attributes of S.

Database Design 18 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 4: Mapping of Binary 1:N Relationship Types

Database Design 19 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 4: Mapping of Binary 1:N Relationship Types

Database Design 20 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 5: Mapping of Binary M:N Relationship
Types
• For each binary M:N relationship type R, create a new
relation S to represent R.
• Include as foreign key attributes in S the primary keys of
the relations that represent the participating entity types
• Their combination will form the primary key of S.
• Also include any simple attributes of the M:N
relationship type as attributes of S.
• we must create a separate relationship relation S.
Database Design 21 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 5: Mapping of Binary M:N Relationship
Types

Database Design 22 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 5: Mapping of Binary M:N Relationship
Types
• The propagate (CASCADE) option for the referential
triggered action should be specified on the foreign keys
in the relation corresponding to the relationship R
• This is due to each relationship instance has an
existence dependency on each of the entities it relates.
• This can be used for both ON UPDATE and ON DELETE.

Database Design 23 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 5: Mapping of Binary M:N Relationship
Types
• Notice that we can always map 1:1 or 1:N relationships
in a manner similar to M:N relationships by using the
cross-reference (relationship relation) approach.
• This alternative is particularly useful when few
relationship instances exist, in order to avoid NULL
values in foreign keys.
• In this case, the primary key of the relationship relation
will be only one of the foreign keys that reference the
participating
Database Design entity relations.
24 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 5: Mapping of Binary M:N Relationship
Types
• For a 1:N relationship, the primary key of the
relationship relation will be the foreign key that
references the entity relation on the N-side.
• For a 1:1 relationship, either foreign key can be used as
the primary key of the relationship relation.

Database Design 25 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 6: Mapping of Multivalued Attributes
• For each multivalued attribute A, create a new relation R.
• This relation R will include an attribute corresponding to
A, plus the primary key attribute K—as a foreign key in R
—of the relation that represents the entity type or
relationship type that has A as a multivalued attribute.
• The primary key of R is the combination of A and K.
• If the multivalued attribute is composite, we include its
simple components.

Database Design 26 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 6: Mapping of Multivalued Attributes

Database Design 27 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 6: Mapping of Multivalued Attributes
• The propagate (CASCADE) option for the referential
triggered action should be specified on the foreign key
in the relation R corresponding to the multivalued
attribute for both ON UPDATE and ON DELETE.
• We should also note that the key of R when mapping a
composite, multivalued attribute requires some analysis
of the meaning of the component attributes.

Database Design 28 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 6: Mapping of Multivalued Attributes
• In some cases, when a multivalued attribute is
composite, only some of the component attributes are
required to be part of the key of R
• These attributes are similar to a partial key of a weak
entity type that corresponds to the multivalued attribute

Database Design 29 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 7: Mapping of N-ary Relationship Types
• For each n-ary relationship type R, where n > 2, create a
new relation S to represent R.
• Include as foreign key attributes in S the primary keys of
the relations that represent the participating entity
types.
• Also include any simple attributes of the n-ary
relationship type as attributes of S.

Database Design 30 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 7: Mapping of N-ary Relationship Types
• The primary key of S is usually a combination of all the
foreign keys that reference the relations representing
the participating entity types.
• However, if the cardinality constraints on any of the
entity types E participating in R is 1, then the primary
key of S should not include the foreign key attribute that
references the relation E corresponding to E

Database Design 31 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm
Step 7: Mapping of N-ary Relationship Types

Database Design 32 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 ER-to-Relational Mapping Algorithm: Summary

Database Design 33 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
Attrs(R) to denote the attributes of relation R
PK(R) to denote the primary key of R
Convert each specialization with m subclasses {S1, S2, ...,
Sm} and (generalized) superclass C, where the attributes of
C are {k, a1, ...an} and k is the (primary) key, into relation
schemas using one of the following options:
8A: Multiple relations—superclass and subclasses.
8B: Multiple relations—subclass relations only.
8C: Single relation with one type attribute.
8D:Design
Database Single relation with multiple type attributes.BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
34
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8A: Multiple relations—superclass and subclasses.
• Create a relation L for C with attributes Attrs(L) = {k,
a1, ..., an} and PK(L) = k.
• Create a relation Li for each subclass Si, 1≤i≤m , with
the attributes Attrs(Li) = {k} ꓴ {attributes of Si} and PK(Li)
= k.
• This option works for any specialization (total or partial,
disjoint or overlapping).
Database Design 35 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8A: Multiple relations—superclass and subclasses.

Database Design 36 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8B: Multiple relations— Subclasses relations only.
• Create a relation Li for each subclass Si, 1 ≤ I ≤ m , with
the attributes Attrs(Li) = {attributes of Si} ꓴ {k, a1, ..., an}
and PK(Li) = k.
• This option only works for a specialization whose
subclasses are total (every entity in the superclass must
belong to (at least) one of the subclasses).

Database Design 37 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8B: Multiple relations— Subclasses relations only.
• Additionally, it is only recommended if the specialization
has the disjointedness constraint.
• If the specialization is overlapping, the same entity may
be duplicated in several relations.

Database Design 38 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8B: Multiple relations— Subclasses relations only.

Database Design 39 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8C: Single relation with one type attribute.
• Create a single relation L with attributes Attrs(L) = {k,
a1, ..., an} ꓴ {attributes of S1} ꓴ ... ꓴ {attributes of Sm} ꓴ
{t} and PK(L) = k.
• The attribute t is called a type (or discriminating)
attribute whose value indicates the subclass to which
each tuple belongs, if any.
• This option works only for a specialization whose
subclasses
Database Design are disjoint, and has the potential for
40 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8C: Single relation with one type attribute.

Database Design 41 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8D: Single relation with multiple type attributes.
• Create a single relation schema L with attributes Attrs(L)
= {k, a1, ..., an} ∪ {attributes of S1} ∪ ... ∪ {attributes of
Sm} ∪ {t1, t2, ..., tm} and PK(L) = k.
• Each ti, 1 ≤ i ≤ m, is a Boolean type attribute indicating
whether a tuple belongs to subclass Si.
• This option is used for a specialization whose subclasses
are overlapping (but will also work for a disjoint
specialization).
Database Design 42 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 8: Mapping of
Specialization/Generalization
8D: Single relation with multiple type attributes.

Database Design 43 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Mapping of Shared Subclasses (Multiple

Inheritance)
• A shared subclass, such as ENGINEERING_MANAGER in
Figure 8.6, is a subclass of several superclasses,
indicating multiple inheritance.
• These classes must all have the same key attribute;
otherwise, the shared subclass would be modeled as a
category (union type)
• We can apply any of the options discussed in step 8 to a
shared subclass, subject to the restrictions discussed in
Database Design 44 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Mapping of Shared Subclasses (Multiple

Inheritance)

Database Design 45 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 9: Mapping of Categories (Union Types)

• A category (or union type) is a subclass of the union of
two or more superclasses that can have different keys
because they can be of different entity types
• For mapping a category whose defining superclasses
have different keys, it is customary to specify a new key
attribute, called a surrogate key, when creating a
relation to correspond to the category.

Database Design 46 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Mapping EER Model Constructs to Relations

Step 9: Mapping of Categories

(Union Types)

Database Design 47 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example: 1. Map ER-Model to Relational Model

Database Design 48 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example: 2. Map ER-Model to Relational Model

Database Design 49 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Example: 3. Map ER-Model to Relational Model

Database Design 50 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 https://www.youtube.com/watch?v=7LRH7DY1QbQ

Database Design 51 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 DATABASE DESIGN
BITS Pilani
Pilani Campus
 BITS Pilani
Pilani Campus

SQL Commands and Relational

Algebra
Learning Objectives

 SQL Commands
i. Definition
ii. Types of SQL commands
a. DDL commands b. DML Commands c. DQL commands d.
DCL commands and e. TCL commands
 Setting the constraints in Create command
 Definition of Relational Algebra
 Types of Relational algebra
 Basic Operations in Relational Algebra
i. Select ii. Project iii. Union iv. Set Difference v.
Cartesian product vi. Rename

3
Database Design - Contact Session - 5
BITS Pilani, Pilani Campus
SQL Commands

SQL commands are instructions coded into SQL

statements which communicate with the database to
perform specific tasks, work, function and queries with
data.
SQL commands are classified into five categories. They
are
1.DDL(Data Definition Language) Commands
2.DML (Data manipulation Language) Commands
3.DQL (Data Query Language) Commands
4.DCL (Data Control Language) Commands
5.TCL (Transaction Control Language) Commands

Database Design - Contact Session - 5 BITS Pilani, Pilani Campus

SQL Commands

1. DDL commands
DDL commands are used to make or perform changes
on the physical structure of any table residing inside
a database. When these commands are executed,
the changes in the table are saved immediately. The
DDL commands are
(i) CREATE TABLE
(ii) ALTER TABLE
(iii) DROP TABLE
(iv) RENAME

5
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

(i) CREATE TABLE- This command is used to create the

structure of the table. The syntax of this command is
CREATE TABLE TABLENAME ( Attribute 1 data
type, Attribute 2 data type, ……..
Attribute n data type);
There are various data types such as integer, number,
double, varchar,varchar2,date,etc.,).
Example:
CREATE TABLE Student
( StName varchar2(20), StNum number (3),
Dept varchar2(20),Average number (7,2));
6
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

The above command creates a table with four attributes

as

StName StNum Dept Average

(ii) ALTER TABLE- This command is used to alter the

structure of the already created table such as changing
size of the attribute, adding a new attribute or deleting
an existing attribute. The syntax is
ALTER TABLE Table name Add/Modify/Drop
(specification of the alteration); 7
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Examples:
a. ALTER TABLE Student Add (dob date); // To
add a new attribute dob into the Student Table
b. ALTER TABLE Student Modify (average
number(5,2); // Change the size of the attribute
average in Student Table
c. ALTER TABLE Student drop Dept; // To delete a
attribute Dept from the Student Table
(iii) RENAME – It is used to rename the table or database
name. The syntax of the command is
RENAME Old table name to New table Name;
8
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Example:
RENAME Student to Students; // The table Student
is renamed as Students
(iv) DROP Command – This command is used to delete
a table from the database.
Its syntax is
DROP TABLE table name;
Example:
DROP TABLE Students; // DROP command
deletes the table names Students from the database
permanently
9
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

2. DML commands
Once the tables are created using DDL Commands, the
manipulation inside those tables is done with the DML
commands. The advantages of using DML command is,
if we did any wrong changes, they can be rolled back
easily. The DML Commands are
(i)INSERT
(ii)DELETE
(iii)UPDATE
(iv)LOCK

10
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands
(i) INSERT COMMAND – This DML command is used to
insert a tuple / record into the table. The general format
of the command is
INSERT INTO TABLE NAME (Attribute names )
VALUES(the values of the attributes );
The String and Date values are to be enclosed in Single
quotes.
Examples:
a. INSERT INTO Students VALUES
(‘Yuvaraj’,10001,’CSE’,98.78);

11
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

The INSERT command inserts a new tuple into the table

Students.
b. INSERT INTO Students(StName,StNum,Average)
VALUES (‘Bumrah’,10010,88.75);
The above INSERT command inserts a new tuple into
the table Students in which Dept is filled with
NULL.After executing the above commands, the
Students table will be
StName StNum Dept Average
Yuvaraj 10001 CSE 95.78
Bumrah 10010 NULL 88.75
12
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands
(ii) DELETE COMMAND – This DML command is used to
delete a tuple / record from the table. The general format
of the command is
DELETE * from TABLE NAME [WHERE
Condition];
Here Condition is optional. If there is no condition, all the
records / tuples are deleted. Otherwise, the records /
tuples satisfying the condition are deleted.
Examples:
a. DELETE * from Students;
The DELETE command deletes all the records in the table.

13
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands
a. DELETE from Students WHERE Average<=90;
The DELETE command deletes all the student records who
have got average <= 90 from the table.
(iii) UPDATE COMMAND – This DML command is used to
Modify/change the content of a tuple / record in a table.
The general format of the command is
UPDATE TABLE NAME SET ATT = V WHERE
CONDITION;
Where
ATT is the attribute which requires modification
V is a value or an expression

14
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Examples
a.UPDATE Student SET StName = ‘Yuvaraj
Singh’WHERE StName = ‘Yuvaraj’;
The UPDATE command modifies the StName,’Yuvaraj’
with ‘Yuvaraj Singh’
b. UPDATE Student SET Average = Average + 2.5
WHERE StName = ‘Yuvaraj Singh’;
The UPDATE command updates the attribute Average
with Average + 2.5. That is, 2.5 marks are added with
Average for all the records / tuples.

15
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

(iv) LOCK Command – This command is used to lock the

privilege as either READ or WRITE. Its syntax is
LOCK TABLE Table name READ / WRITE;
Example;
LOCK TABLE Student READ ; // Locks the privilege as
READ.
3. DQL commands
DQL commands are used for performing data selection in
SQL. It is performed with SELECT command. Its syntax is
SELECT ATTNAMES FROM TABLE NAME WHERE
CONDITION;

16
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Assume that a table has the tuples as follows:

StName StNum Dept Average
Yuvaraj 10001 CSE 98.78
Bumrah 10010 IT 88.75
ROY 10019 Mech 65.25
Foster 55001 CSE 50.55
BIJU 10111 IT 55.75
RAM 44448 CSE 44.00
David 12345 CSE 88.00

17
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Examples – a. SELECT StNum,Average FROM

Students; // displays StNum and Average of all the
records in Students table as
StNum Average
10001 98.78
10010 88.75
10019 65.25
55001 50.55
101116 55.75
44448 44.00
12345 88.00

18
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

b. SELECT StNum,Average FROM Students where

Average>=76; // displays StNum and Average of all the
records in Students table who have the average >=76 as

StNum Average
10001 98.78
10010 88.75
12345 88.00

c. SELECT * FROM Students; // displays all the

records in Students table as

19
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

StName StNum Dept Average

Yuvaraj 10001 CSE 98.78
Bumrah 10010 IT 88.75
ROY 10019 Mech 65.25
Foster 55001 CSE 50.55
BIJU 10111 IT 55.75
RAM 44448 CSE 44.00
David 12345 CSE 88.00
d. SELECT * FROM Students where
Average>=76; // displays all the information of all the
records in Students table who have the average >=76 as

20
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

StName StNum Dept Average

Yuvaraj 10001 CSE 98.78
Bumrah 10010 IT 88.75
David 12345 CSE 88.00
4. DCL commands
These command are used for granting and revoking
permission to the users. The commands are GRANT and
REVOKE. The syntax of GRANT command is
GRANT Privilege on Object to User name;
Example:
GRANT CREATE TABLE to UserMe;
21
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

Granting the Create command privilege to the user

UserMe
The syntax of REVOKE command is
REVOKE Privilege on Object from User name;
Example:
REVOKE CREATE TABLE from UserMe;
Revoking the Create command privilege from UserMe.
The privileges are Alter, Drop, Select, Update, Delete,
etc.,

22
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
SQL Commands

5. TCL commands
These commands are applied to rollback and commit
the changes what we have made in the database.
The TCL Commands are
(i)ROLLBACK – It is used to Undo the changes made in
the database
(ii)Commit – It is used to save the changes made in the
database.

23
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints
Integrity Constraints
We know that it is possible to set some conditions
(constraints) at the time of creating the structure of the
table to maintain the integrity.
Integrity checks the validity of the value given for the
attribute of the table.
These constraints are called as Integrity Constraints.
When the values of the attributes are give, these
constraints check whether they are valid or not.
If they are valid, the values will be permitted to construct
the tuple.

24
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints
After the tuple/record is constructed, it can be added into
the table.
If the value of the attribute is not valid(incorrect value) , the
constraint generates the error code and is displayed on
the user’s screen without giving the permission to
construct the tuple.

25
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints

The constraints can be set with various formats. Some

of them are
Constraint Type 1. Setting an attribute as NOT NULL
This constraint is set to accept a value for mandatory
attribute and it can be assigned a NULL value.
Example for setting this constraint is
CREATE TABLE Student
( StName varchar2(20) NOT NULL,
StNum number NOT NULL, Dept varchar2(20),
Average number (7,2));

26
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints

Constraint Type 2. Setting an attribute as a Primary

Key.
The primary key is set for avoiding duplicate value for
an attrbute.
Example for setting this constraint is
CREATE TABLE Student
( StName varchar2(20), StNum number NOT
NULL, Dept varchar2(20),Average number
(7,2) primary key(StNum));

27
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints

Constraint Type 3. Setting the possible value (s) for an

attribute.
The set of valid values to be assigned for an attribute is
given by using a constraint called as CHECK.
Example2 for setting this constraint is
1.CREATE TABLE Student
( StName varchar2(20), StNum number NOT
NULL, Dept varchar2(20),Average number
(7,2) CHECK (Dept in
(‘CSE’,’IT’,’Mech’,’BIO’))); // valid
values for the attribute Dept is set

28
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Setting the Constraints

2.CREATE TABLE Daily_wages

(Name varchar2(20), Num number NOT NULL,
Hrs_worked number (3,2), Wage number (4,2)
CHECK (Hrs_worked between 0 and 24)));
The valid value for attribute Hrs_worked is set between
0 and 24.
If the value for the attribute is given out of this range,
the system generates the error message.

29
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Relational Algebra
Relational Algebra in DBMS
Relational algebra is a procedural query language that
performs operation on relational model.
The purpose of a query language is to retrieve data
from database or perform various operations such as
insert, update, delete on the data in the database.
Conversely relational calculus is a non-procedural
query language.
It specifies what data to be retrieved from the database
but doesn’t specify how to retrieve it.

30
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Relational Algebra

Types of operations in relational algebra

The types of operations in relational algebra are classified into
broad two categories. They are
1. Basic Operations – these are the fundamental
operations which are to be performed on the data.
2. Derived Operations – these are the advanced operations
which are used for extension operations
1. Basic/Fundamental Operations in relational algebra are:
i. Select (σ)
ii. Project (∏)

Database Design - Contact Session - 5

BITS Pilani, Pilani Campus

Relational Algebra

iii. Union (∪)

iv. Set Difference (-)
v. Cartesian product (X)
vi. Rename (ρ)
2. The Derived Operations in relational algebra are:
i. Natural Join (⋈)
ii. Left, Right, Full outer join (⟕, ⟖, ⟗)
iii. Intersection (∩)
iv. Division (÷)

Database Design - Contact Session - 5

BITS Pilani, Pilani Campus

Relational Algebra - BASIC OPERATIONS

BASIC OPERATIONS
i. Select Operator
Select Operator is denoted by sigma (σ) and it is used to
find the tuples / rows in a relation / a table which satisfy
the
given condition. Syntax of Select Operator (σ)
σ Condition/Predicate(Relation/Table name)
Example for Select Operator
Assume that a customer table has the following data
Table: CUSTOMER

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

Customer_Id Customer_Name Customer_City

C10100 Sachin Agra
C10111 Laxman Agra
C10115 Shewag Noida
C10117 Virat Delhi
C10118 Dravid Delhi

If the Query is
σ Customer_City="Agra" (CUSTOMER) ,
the output will be
Database Design - Contact Session - 5

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

Customer_Id Customer_Name Customer_City

C10100 Sachin Agra
C10111 Laxman Agra

Note:- The Select operation in SQL is performed with

SELECT command with a where clause.
The above operation is performed with SQL command as
Select * from CUSTOMER where
Customer_city=”Agra”;

BITS Pilani, Pilani Campus

Relational Algebra
ii. Project Operator
Project operator is denoted by ∏ symbol and it is used to
select desired columns / attributes from a table / a relation.
Syntax of Project Operator
∏ column_name1, column_name2, ....,
column_nameN(table_name)
Example for Project Operator
Consider a table CUSTOMER with three columns, we want to fetch
only two columns of the table,
∏ Customer_Name, Customer_City (CUSTOMER)
The above relational algebra query selects and returns the columns
specified from the table

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

Then the Output would be

Customer_Name Customer_City
Sachin Agra
Laxman Agra
Shewag Noida
Virat Delhi
Dravid Delhi
Note:- The corresponding SQL command is:
Select Customer_Name ,Customer_City from
CUSTOMER;

Database Design - Contact Session - 5

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

iii. Union Operator

Union operator is denoted by ∪ symbol and it is used to select
all the rows / tuples from two tables / relations.
Let us discuss union operator a bit more.
Assume that there are two relations R1 and R2 both have
same columns and we want to select all the tuples /rows
from these relations then we can apply the union operator
on these relations.
Note: The rows / tuples that are present in both the tables
will only appear once in the union set.
In short we can say that there are no duplicates present after
the union operation.

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS
Syntax of Union Operator: table_name1 ∪ table_name2
Example for Union Operator
Assume that the tables COURSE and STUDENT have the data as
follows
Table 1: COURSE

Database Design - Contact Session - 5 BITS Pilani, Pilani Campus

Relational Algebra

Table 2: STUDENT

If we use the Query is executed with the intersection operator as

∏ Student_Name (COURSE) ∪ ∏ Student_Name (STUDENT),
the Output table will be

Database Design - Contact Session - 5 BITS Pilani, Pilani Campus

Relational Algebra

Note: As we can see there are no duplicate names present in the

output even though we had few common names in both the
tables, also in the COURSE table we had the duplicate name
itself.

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

iv. Intersection Operator

Intersection operator is denoted by ∩ symbol and it is
used to select common rows /tuples from two
tables /relations.
Assume that we have two relations R1 and R2 both have
same columns and we want to select all those tuples /
rows that are present in both the relations, then in
that case we can apply intersection operation on
these two relations R1 ∩ R2.

BITS Pilani, Pilani Campus

Database Design - Contact Session - 5
Relational Algebra - BASIC
OPERATIONS
Note: Only those rows that are present in both the tables
will appear in the result set.
Syntax of Intersection Operator
table_name1 ∩ table_name2
Example for Intersection Operator
Let us take the same example that we have taken above
operator.
If the Query is executed with the intersection operator as
∏ Student_Name (COURSE) ∩ ∏ Student_Name (STUDENT),
the Output table is shown as follows

Database Design - Contact Session - 5

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

The Equivalent SQL command is

Select Student_Name from Course INTERSECT Select Student_Name from STUDENT;

v. Set Difference - Set Difference is denoted by –

symbol.
Let us assume that we have two relations R1 and R2 and
we want to select all those tuples / rows that are
present in Relation R1 but not present in Relation R2,
this can be done using Set difference R1 – R2.
BITS Pilani, Pilani Campus
Relational Algebra - BASIC
OPERATIONS

Example for Set Difference

Let us take the same tables COURSE and STUDENT that
we have seen above.
Query:
Let us write a query to select those student names that
are present in STUDENT table but not present in
COURSE table.
∏ Student_Name (STUDENT) - ∏ Student_Name
(COURSE)

Database Design - Contact Session - 5 BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

The Equivalent SQL command is

Select Student_Name from STUDENT MINUS
Select Student_Name from COURSE;

BITS Pilani, Pilani Campus

Database Design - Contact Session - 5
Relational Algebra - BASIC
OPERATIONS

vi. Cartesian product

Cartesian Product is denoted by X symbol.
Assume that R1 and R2 are the given relations.
The Cartesian product of these two relations (R1 X R2)
would combine each tuple of first relation R1 with the
each tuple of second relation R2.
Syntax of Cartesian product (X)
R1 X R2;

BITS Pilani, Pilani Campus

Relational Algebra - BASIC
OPERATIONS

Example for Cartesian product

Table 1: R Table 2 : S
Col_A Col_B Col_X Col_Y
AA 100 XX 99
BB 200 YY 11
CC 300 ZZ 101

If the Query is to find the Cartesian product (RXS) of the

tables R and S, the output will be

48
BITS Pilani, Pilani Campus
Relational Algebra - BASIC
OPERATIONS

Col_A Col_B Col_X Col_Y

AA 100 XX 99
AA 100 YY 11
AA 100 ZZ 101
BB 200 XX 99
BB 200 YY 11
BB 200 ZZ 101
CC 300 XX 99
CC 300 YY 11
CC 300 ZZ 101

49
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Relational Algebra - BASIC
OPERATIONS

Note: The number of rows in the output will always be

the cross product of number of rows in each table.
In our example table 1 has 3 rows and table 2 has 3
rows, so the output has 3×3 = 9 rows.
vi. Rename
The rename operation is represented with the symbol ρ.
This operation is used to rename a relation or an
attribute of a relation.
Rename Syntax:
ρ(new_relation_name, old_relation_name)

50
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Relational Algebra - BASIC
OPERATIONS

Example for Rename - Let us say we have a table

customer, we are fetching customer names and we
are renaming the resulted relation to CUST_NAMES.
Table: CUSTOMER

51
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
 Relational Algebra - BASIC
OPERATIONS

If the Query is formed as

ρ(CUST_NAMES, ∏(Customer_Name)(CUSTOMER)),
the output will be

52
Database Design - Contact Session - 5 BITS Pilani, Pilani Campus
Thanks

53
BITS Pilani, Pilani Campus
 DATABASE DESIGN
BITS Pilani SESSION 6
Pilani Campus
 BITS Pilani
Pilani Campus

Relational Algebra and SQL

Commands
Learning Objectives

 Derived Operations in Relational Algebra

• Different types of Joins
i. Inner Join
ii. Full Join
iii. Left Join
iv. Right Join
 Nested Query / Sub query
 SQL Aggregate Functions
 SQL EXISTS / NOT EXISTS Condition
 SQL command with GROUP By Clause
 SQL Command with HAVING clause

3
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands
What are Joins?
JOINS in SQL are commands which are used to combine rows
from two or more tables, based on an associated column
between those tables. There are largely used when a user
tries to extract data from tables which have one-to-many or
many-to-many relationships between them.
Types of Joins
There are 4 types of Joins. They are
1. Inner Join
2. Full Join
3. Left Join
4. Right Join 4
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands
The following represents the various Joins

To explain various Join operations, we consider two tables such as

EMPLOYEE and PROJECT in which EMPLOYEE table consists of
records of Employee and PROJECT contains the records of the
information about various projects done by the employees

5
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands
EMPLOYEE
EmpId Name Age EmailId
E101 Mr. Dhoni 33 [email protected]
E102 Mr.Sachin 40 [email protected]
E103 Mr.Rohit Sharma 30 [email protected]
E104 Mr. Virat Kohli 28 [email protected]
PROJECT
ProjId EmpId Proj_Name Start_date
P1 E102 Project A 07-2-2018
P2 E104 Project B 03-8-2018
P3 E102 Project C 01-1-2019
P4 E120 Project D 10-8-2019
6
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Inner Join
I. INNER JOIN
INNER join returns those records which have matching
values in both tables. So, if you perform an INNER join
operation between the Employee table and the Projects
table,
all the tuples which have matching values in both the tables
will be given as output.
Syntax:
SELECT Table1.Column1,Table1.Column2,Table2.Column1,....
FROM Table1INNER JOIN Table2 ON
Table1.MatchingColumnName =
Table2.MatchingColumnName;
7
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Inner Join
Example: SELECT EMPLOYEE.NAME,EMPLOYEE.EmpId, PROJECT.
ProjId, PROJECT. Proj_Name FROM EMPLOYEE INNER JOIN
PROJECT ON EMPLOYEE.EmpId = PROJECT. EmpId;
The output of the above query is
Name EmpId ProjId Proj_Name
Mr.Sachin E102 P1 Project A
Mr. Virat Kohli E104 P2 Project B
Mr.Sachin E102 P3 Project C

II. FULL JOIN

Full Join or the Full Outer Join returns all those records which
either have a match in the left(Table1) or the right(Table2)
table. The Syntax FULL JOIN is
for
8
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Commands

SELECT Table1.Column1,Table1.Column2,Table2.Column1,....
FROM Table1 FULL JOIN Table2 ON
Table1.MatchingColumnName =
Table2.MatchingColumnName;
Example:
SELECT EMPLOYEE.NAME,EMPLOYEE.EmpId, PROJECT. ProjId,
PROJECT. Proj_Name FROM EMPLOYEE
FULL JOIN PROJECT ON
EMPLOYEE.EmpId = PROJECT. EmpId;
If the above query is executed , we get the following result:

9
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Left Join
Name EmpId ProjId Proj_Name
Mr. Dhoni E101 NULL NULL
Mr.Sachin E102 P1 Project A
Mr.Sachin E102 P3 Project C
Mr.Rohit Sharma E103 NULL NULL
Mr. Virat Kohli E104 P2 Project B
NULL NULL P4 Project D

III. LEFT JOIN

The LEFT JOIN or the LEFT OUTER JOIN returns all the records
from the left table and also those records which satisfy a
condition from the right table. Also, for the records having no
matching values in the right table, the output or the result-set
10
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Left Join
will contain the NULL values.
s Syntax:
It
SELECT Table1.Column1,Table1.Column2,Table2.Column1,....
FROM Table1 LEFT JOIN Table2 ON
Table1.MatchingColumnName =
Table2.MatchingColumnName;
Example:
SELECT EMPLOYEE.NAME,EMPLOYEE.EmpId, PROJECT. ProjId,
PROJECT. Proj_Name FROM EMPLOYEE
LEFT JOIN PROJECT ON
EMPLOYEE.EmpId = PROJECT. EmpId;
If the above query is executed , we get the following result:
11
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Right Join
EmpName EmpId ProjId Proj_Name
Mr. Dhoni E101 NULL NULL
Mr.Sachin E102 P1 Project A
Mr.Sachin E102 P3 Project C
Mr.Rohit Sharma E103 NULL NULL
Mr. Virat Kohli E104 P2 Project B

III. RIGHT JOIN

The RIGHT JOIN or the RIGHT OUTER JOIN returns all the
records from the right table and also those records which
satisfy a condition from the left table. Also, for the records
having no matching values in the left table, the output or the
result-set will contain the NULL values.

12
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Right Join
s Syntax:
It
SELECT Table1.Column1,Table1.Column2,Table2.Column1,....
FROM Table1 RIGHT JOIN Table2 ON
Table1.MatchingColumnName =
Table2.MatchingColumnName;
Example:
SELECT EMPLOYEE.NAME,EMPLOYEE.EmpId, PROJECT. ProjId,
PROJECT. Proj_Name FROM EMPLOYEE
RIGHT JOIN PROJECT ON
EMPLOYEE.EmpId = PROJECT. EmpId;
If the above query is executed , we get the following result:

13
Database Design- Session 6 BITS Pilani, Pilani Campus
JOIN operation in SQL
Commands – Right Join
EmpName EmpId ProjId Proj_Name
Mr.Sachin E102 P1 Project A
Mr. Virat Kohli E104 P2 Project B
Mr.Sachin E102 P3 Project C
NULL NULL P4 Project D

14
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

SUBQUERY / NESTED QUERY

A subquery consists of two queries as out and inner queries.
A subquery is used to return data that will be used in the main
query as a condition to further restrict the data to be retrieved.
Subqueries can be used with the SELECT, INSERT, UPDATE,
and DELETE statements along with the operators like =, <, >,
>=, <=, IN, BETWEEN, etc.
There are a few rules that subqueries must satisfy −
• Subqueries must be enclosed within parentheses.
• A subquery can have only one column in the SELECT clause,
unless multiple columns are in the main query for the
subquery to compare its selected columns.
15
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

• An ORDER BY command cannot be used in a subquery,

although the main query can use an ORDER BY. The GROUP
BY command can be used to perform the same function as
the ORDER BY in a subquery.
• Subqueries that return more than one row can only be
used
with multiple value operators such as the IN operator.
• A subquery cannot be immediately enclosed in a set
function.
1. Subqueries with the SELECT Statement
Subqueries are most frequently used with the SELECT
statement. The syntax for a subquery is as follows −
16
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

SELECT column_name [, column_name ] FROM table1 [, table2 ]

WHERE column_name OPERATOR
(SELECT column_name [, column_name ]
FROM table1 [, table2 ] [WHERE condition]);
Example
Consider the CUSTOMERS table having the following records −
ID NAME AGE ADDRESS SALARY
1 Ramesh 35 Ahmedabad 2000.00
2 Keshav 25 Delhi 1500.00
3 kaushik 23 Kota 2000.00
4 Chaitanya 25 Mumbai 6500.00
5 Rajesh 27 Bhopal 8500.00
6 Kamal 22 MP 4500.00

17
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

Now, let us check the following subquery with a SELECT

statement.
SQL> SELECT * FROM CUSTOMERS WHERE ID IN (SELECT ID FROM
CUSTOMERS WHERE SALARY > 4500) ;
This would produce the following result.
ID NAME AGE ADDRESS SALARY
4 Chaitanya 25 Mumbai 6500.00
5 Rajesh 27 Bhopal 8500.00

2. Subqueries with the INSERT Statement

Subqueries also can be used with INSERT statements. The
INSERT statement uses the data returned from the subquery to
insert into another table. The selected data in the subquery
18
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

can be modified with any of the character, date or number

functions.The basic syntax is as follows.
INSERT INTO table_name [ (column1 [, column2 ]) ]
SELECT [ *|column1 [, column2 ]
FROM table1 [, table2 ]
[ WHERE VALUE OPERATOR ]

Example
Assume a table CUSTOMER_TEMP has similar structure as
CUSTOMER table. To copy the complete CUSTOMER table
into the CUSTOMER_TEMP table, we can use the following
SQL subquery command
19
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

INSERT INTO CUSTOMER_TEMP

SELECT * FROM CUSTOMER WHERE ID IN
(SELECT ID FROM CUSTOMER) ;
As usual, the inner query is executed first. When it is executed,
it creates a table with all IDs from the CUSTOMER table. Then
all the records of the CUSTOMER matching the condition are
retrieved (in this case, all the records satisfy the condition) and
are inserted into the table CUSTOMER_TEMP.
3. Subqueries with the UPDATE Statement
The subquery can be used in conjunction with the UPDATE
statement. Either single or multiple columns in a table can be
updated when using a subquery with the UPDATE statement.
20
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

The basic syntax is as follows.

UPDATE table
SET column_name = new_value [ WHERE OPERATOR
[ VALUE ] (SELECT COLUMN_NAME FROM
TABLE_NAME) [ WHERE condition) ]
Example
Assume that we have CUSTOMER_TEMP table available
which is backup of CUSTOMER table. The following example
Increments the SALARY by 10 % in the CUSTOMERS table for
all the customers whose AGE is greater than or equal to 27.

21
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

UPDATE CUSTOMER
SET SALARY = SALARY + SALARY * 0.10
WHERE AGE IN
(SELECT AGE FROM CUSTOMER_TEMP
WHERE AGE >= 27 );

The inner query is executed first which retrieve all the ages of
the records in the CUSTOMER table satisfying the condition
(>=27). Then the outer query is performed to update the
salary for the records. The resultant CUSTOMER table is

22
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

CUSTOMER
ID NAME AGE ADDRESS SALARY
1 Ramesh 35 Ahmedabad 2200.00
2 Keshav 25 Delhi 1500.00
3 kaushik 23 Kota 2000.00
4 Chaitanya 25 Mumbai 6500.00
5 Rajesh 27 Bhopal 9350.00
6 Kamal 22 MP 4500.00

4. Subqueries with the DELETE Statement

The subquery can be used in conjunction with the DELETE
statement like with any other statements mentioned above.
23
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

Its syntax is :
DELETE FROM TABLE_NAME [ WHERE OPERATOR [ VALUE ]
(SELECT COLUMN_NAME
FROM TABLE_NAME) [ WHERE Condition) ]
Example
Assuming, we have a CUSTOMER_TEMP table available which
is a backup of the CUSTOMER table. The following example
deletes the records from the CUSTOMER table for all the
customers whose AGE is greater than or equal to 25.
DELETE FROM CUSTOMER
WHERE AGE IN (SELECT AGE FROM CUSTOMER_TEMP
WHERE AGE >= 25 );
24
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL NESTED QUERY

Now the CUSTOMER table is

CUSTOMER
ID NAME AGE ADDRESS SALARY
3 kaushik 23 Kota 2000.00
6 Kamal 22 MP 4500.00

25
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Aggregate Functions

AGGREGATE FUNCTIONS
The aggregate functions are the predefined functions to
calculate average, sum and count the number of occurrences
of the records satisfying a cretria . The aggregate functions are
SQL COUNT(), AVG() and SUM() Functions
1.COUNT() function – It returns the number of rows that
Matches a specified criterion.
Its syntax is
SELECT COUNT(column_name) FROM table_name
WHERE condition;
AVG()
2. function – It returns the average value of a
numeric column. Its syntax is
26
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Aggregate Functions

SELECT AVG(column_name)
FROM table_name
WHERE condition;
3.SUM() function - It returns the total sum of a numeric
column. Its syntax is
SELECT SUM(column_name)
FROM table_name
WHERE condition;
Examples for the aggregate functions:
Assume that we are given a CUSTOMER table as follows:

27
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Aggregate Functions

CUSTOMER
ID NAME AGE ADDRESS SALARY
1 Ramesh 35 Ahmedabad 2200.00
2 Keshav 25 Delhi 1500.00
3 kaushik 23 Kota 2000.00
4 Chaitanya 25 Mumbai 6500.00
5 Rajesh 27 Bhopal 9800.00
Example 1: If we execute the SQL command
SELECT COUNT(ID) FROM CUSTOMER
WHERE age >=25; , the output is
COUNT(ID)
4
28
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Aggregate Functions

Example 2: If we execute the SQL command as

SELECT SUM(salary)
FROM CUSTOMER
WHERE age >=25; , the output is
SUM(salary)
20000
Example 3: If we execute the SQL command as
SELECT AVG(salary)
FROM CUSTOMER
WHERE age >=25; , the output is
AVG(salary)
20000
29
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Exists / Not Exists
Condition
SQL EXISTS
The EXISTS condition in SQL is used to check whether the
result of a correlated nested query is empty (contains no
tuples) or not. The result of EXISTS is a boolean value which
is
either True or False. This condition can be used in a SELECT,
UPDATE, INSERT or DELETE statement.
Its Syntax is:
SELECT column_name(s) FROM table_name WHERE
EXISTS
(SELECT column_name(s) FROM table_name
WHERE condition);
30
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Exists / Not Exists
Condition
Example: Consider the following two relations “Customer”
and “Order”.
CUSTOMER
CustId CustName Location
C001 Mr. Ram Chennai – 10
C008 Ms.Geetha Chennai-22
C110 Mr.Anand Chennai-78
ORDER
OrderId CustId Amount
O1001 C008 12345
O1002 C001 50000
O998 C222 43000
31
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Exists / Not Exists
Condition
Using EXISTS condition with SELECT statement
To fetch the name of the customers who placed atleast one
order.
SELECT CustName FROM Customer WHERE
EXISTS (SELECT * FROM Order WHERE
Customer. CustId = Order. CustId);
The output is
CustName
Ms.Geetha
Mr. Ram

32
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Exists / Not Exists
Condition
Using NOT with EXISTS
To fetch name of the customers who has not placed any
order.

SELECT CustName FROM Customer WHERE

NOT EXISTS (SELECT * FROM Order WHERE
Customer. CustId = Order. CustId);

CustName
Mr.Anand

33
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
The GROUP BY clause is used in the SELECT statement .
Optionally it is used in conjunction with aggregate functions to
produce summary reports from the database.
That's what it does, summarizing data from the database.
The queries that contain the GROUP BY clause are called
grouped queries and only return a single row for every
grouped item.
GROUP BY Syntax
Now that we know what the GROUP By clause is, let's look at
the syntax for a basic group by query.
SELECT statement... GROUP BY
column_name1[,column_name2,...] [HAVING condition];
34
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
Where
(i) "SELECT statement..." is the standard SQL SELECT
statement
(ii) "GROUP BY column_name1" is the clause that performs
the grouping based on a particular column which is
specified as column_name1.
(iii) "[,column_name2,...]" is optional; represents other
column names when the grouping is done on more than
one columns.
(iv) "[HAVING condition]" is optional; it is used to restrict the
rows affected by the GROUP BY clause. It is similar to the
WHERE clause.

35
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
Grouping using a Single Column
Assume that a table members has the data as follows:
Name MemNo Gender Age Place
Ram M1001 Male 25 Chennai-1
Hema M1010 Female 23 Chennai-10
Amrutha M1005 Female 19 Chennai-5
Akshitha M1111 Female 24 Chennai-45
Anand M0009 Male 45 Chennai-78
In order to help understand the effect of Group By clause, let
us execute a simple query that returns all the gender entries
from the members table.
SELECT Gender FROM members ;
36
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
It produces the following output:
Gender
Male
Female
Female
Female
Male
Suppose we want to get the unique values for genders. We can
use a following query -
SELECT Gender FROM members GROUP BY Gender;
It produces the following output:

37
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
Gender
Male
Female
Note that it returns only two results. This is because we only
have two gender types Male Female
and . The GROUP BY
clause grouped all the "Male" members together and returned
only a single row for it. It is same with the "Female" members.
If we use the SQL Query as
SELECT Gender,Avg(Age) FROM members GROUP BY
Gender;
it returns the average Age value of each Gender as

38
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
Gender Avg(Age)
Male 35 (25+45) / 2
Female 22 (23+19+24)/3
Grouping using a Multiple Columns
Assume that a table Orders has the data as follows:
SalesId CustIdAmount
S1000 C5001 8000
S1003 C5003 13000
S1000 C5010 28000
S1000 C5004 40000
S1000 C5001 70000
S1003 C5001 8000
39
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
SELECT SalesId,CustId,Sum(Amount),Avg(Amount) FROM
Orders GROUP BY SalesId, CustId;
it displays the output as
SalesId CustId Sum(Amount) Avg(Amount)
S1000 C5001 78000 39000
S1000 C5010 28000 28000
S1000 C5004 40000 40000
S1003 C5003 13000 13000
S1003 C5001 8000 8000
In the above query, the records are grouped with two
columns
/ attributes such as SalesId and CustId.
40
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Group
By option
If the same table is grouped with a single attribute as
SELECT SalesId,Sum(Amount),Average(Amount) FROM Orders
GROUP BY SalesId;
it displays the output as
SalesId Sum(Amount) Average(Amount)
S1000 146000 36500
S1003 21000 10500

41
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Having
option
We know that WHERE clause is used to select and reject the
individual rows from a table, the HAVING is also used to
select
and reject row groups. The format of the HAVING clause
parallels that of the WHERE clause, consisting of the keyword
HAVING followed by the search condition. Thus, the HAVING
clause specifies a search condition for groups.
If a query is asked as , “What is the average salesperson
whose
order total more than Rs 30,000?”, we can use the HAVING
clause as
SELECT SalesId,Sum(Amount),Average(Amount) FROM Orders
GROUP BY SalesId HAVING Sum(Amount)>30000; 42
Database Design- Session 6 BITS Pilani, Pilani Campus
SQL Command with Having
option
it displays the output as
SalesId Sum(Amount) Average(Amount)
S1000 146000 36500

43
Database Design- Session 6 BITS Pilani, Pilani Campus
Select Statement with Order
By Clause
The Order By clause in the Select statement is used to sort the
query result in an order of a column. The order may be in
ascending order or descending order. The default order is
ascending.
Assume that a table Student has the following data
StName Stno Dept Percent
Dravid S110 Mech 78
Meera S200 Cse 92
Levin S078 Mech 80
Leela S012 Mech 62
Raman S003 Mech 91
Pavithra S235 Cse 77
Pavithra S234 Cse 67
44
Database Design- Session 6 BITS Pilani, Pilani Campus
Select Statement with Order
By Clause
If we want to sort the records of the Student table according
to
the department, we use the Order by clause as
Select * from Student order by Dept;
The output of the above query is
StName Stno Dept Percent
Meera S200 Cse 92
Pavithra S235 Cse 77
Pavithra S234 Cse 67
Levin S078 Mech 80
Leela S012 Mech 62
Raman S003 Mech 91
Dravid S110 Mech 78
45
Database Design- Session 6 BITS Pilani, Pilani Campus
Select Statement with Order
By Clause
If we want to sort the records of the Student table according
to
the department and Stno within the department, we use the
Order by clause as Select * from Student order by
Dept,Stno; The output of the above query is
StName Stno Dept Percent
Meera S200 Cse 92
Pavithra S234 Cse 67
Pavithra S235 Cse 77
Raman S003 Mech 91
Leela S012 Mech 62
Levin S078 Mech 80
Dravid S110 Mech 78
46
Database Design- Session 6 BITS Pilani, Pilani Campus
Select Statement with Order
By Clause
If we want to sort the Student table according to the
descending values of percentage of the students,we use the
SQL statement as Select * from Student order by Percent
desc; The output of the above query is
StName Stno Dept Percent
Meera S200 Cse 92
Raman S003 Mech 91
Levin S078 Mech 80
Dravid S110 Mech 78
Pavithra S235 Cse 77
Pavithra S234 Cse 67
Leela S012 Mech 62
47
Database Design- Session 6 BITS Pilani, Pilani Campus
Thanks

48
BITS Pilani, Pilani Campus
 Database Design
SESSION 7
BITS Pilani
Pilani | Dubai | Goa | Hyderabad
 BITS Pilani
Pilani | Dubai | Goa | Hyderabad

Contact Session 7:
 Session Outline
• Exercises in Nested Query

• Features of Correlated Sub queries

• Trigger

• Views

• Substring handling and other features of SQL

 Some More Examples in Nested Queries, Tuples, and Set/Multiset
Comparisons

 Some queries require that existing values in the database be fetched and
then used in a comparison condition.

 Such queries can be conveniently formulated by using nested queries, which

are complete select-from-where blocks within another SQL query.

 That other query is called the outer query.

 These nested queries can also appear in the WHERE clause or the FROM
clause or the SELECT clause or other SQL clauses as needed.

Database Design 4 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Nested Queries - Example

A Nested query for make a list of all project numbers for projects that involve
employee Smith either as worker or as a manager of the department that
controls the project:

Database Design 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Nested Queries - Example

 If a nested query returns a single attribute and a single tuple, the query
result will be a single (scalar) value. In such cases, it is permissible to use
= instead of IN for the comparison operator.
 To illustrate this, consider the following query:

This query will select the Essns of all employees who work the same (project, hours) combination
on some project that employee ‘John Smith’ (whose Ssn = ‘123456789’) works on.

Database Design 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Nested Queries - Example

Use other comparison operators to compare a single value v

– = ANY (or = SOME) operator [equivalent to IN]
• Returns TRUE if the value v is equal to some value in the set
– Other operators that can be combined with ANY (or SOME): >, >=, <, <=, and <>
– ALL: value must exceed all values from nested query

Above query returns the names of employees whose salary is greater than the
salary of all the employees in department 5:
Database Design 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Nested Queries - Example

A reference to an unqualified attribute refers to the relation declared in the innermost

nested query.
Example: Retrieve the name of each employee who has a dependent with the
same first name and is the same sex as the employee.

In above query, we must qualify E.Sex because it refers to the Sex attribute of EMPLOYEE from the
outer query, and DEPENDENT also has an attribute called Sex. If there were any unqualified
references to Sex in the nested query, they would refer to the Sex attribute of DEPENDENT.

Database Design 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 1. Correlated Nested Queries
 Whenever a condition in the WHERE clause of a nested query references some
attribute of a relation declared in the outer query, the two queries are said to be
correlated
 Queries that are nested using the = or IN comparison operator can be collapsed
into one single block: Example:
 Example 1.3A:
 Query: SELECT E.Fname, E.Lname
FROM EMPLOYEE AS E, DEPENDENT AS D
WHERE E.Ssn=D.Essn AND E.Sex=D.Sex AND
E.Fname=D.Dependent_name;

 Correlated nested query

 Evaluated once for each tuple in the outer query

Database Design 9 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 2. Introduction to Triggers in SQL

 CREATE TRIGGER statement

 Used to monitor the database
 Typical trigger has three components which make it a rule for an “active
database”.
 Event(s)
 Condition
 Action

Database Design 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Introduction to Triggers: USE OF TRIGGERS

 AN EXAMPLE with standard Syntax.

 Suppose we want to check whenever an employee’s salary is greater than
the salary of his or her direct supervisor in the COMPANY database. Several
events can trigger this rule: inserting a new employee record, changing an
employee’s salary, or changing an employee’s supervisor. Suppose that the
action to take would be to call an external stored procedure
SALARY_VIOLATION, which will notify the supervisor

Database Design 11 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Introduction to Triggers: USE OF TRIGGERS

Database Design 12 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 3. Views (Virtual Tables) in SQL

 Concept of a view in SQL

 Specification of Views in SQL
 View Implementation, View Update, and Inline Views
 Views as Authorization Mechanisms

Database Design 13 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Concept of a view in SQL

 Concept of a view in SQL:

 Single table derived from other tables called the defining tables
 Considered to be a virtual table that is not necessarily populated

Database Design 14 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Specification of Views in SQL

 CREATE VIEW command

 Give table name, list of attribute names, and a query to specify the contents of
the view
 In V1, attributes retain the names from base tables and In V2, attributes are
assigned names

Database Design 15 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Specification of Views in SQL

 Once a View is defined, SQL queries can use the View relation in the FROM
clause
 View is always up-to-date
 Responsibility of the DBMS and not the user
 DROP VIEW command
 Dispose of a view

Database Design 16 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 View Implementation, View Update, and Inline Views

 Complex problem of efficiently implementing a view for querying.

 Strategy1: Query modification approach

 Compute the view as and when needed. Do not store permanently

 Modify view query into a query on underlying base tables

 Disadvantage: inefficient for views defined via complex queries that are

time-consuming to execute

Database Design 17 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 View Implementation, View Update, and Inline Views

Strategy 2: View materialization

– Physically create a temporary view table when the view is first queried.
– Keep that table on the assumption that other queries on the view will follow.
– Requires efficient strategy for automatically updating the view table when the
base tables are updated.
Incremental update strategy for materialized views
– DBMS determines what new tuples must be inserted, deleted, or modified in a
materialized view table.

Database Design 18 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 View Implementation, View Update, and Inline Views

 Multiple ways to handle materialization:

I. Immediate update strategy updates a view as soon as the base tables are
changed
II. Lazy update strategy updates the view when needed by a view query
III. Periodic update strategy updates the view periodically (in the latter strategy, a
view query may get a result that is not up-to-date). This is commonly used in
Banks, Retail store operations, etc.

Database Design 19 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 View Update

Update on a view defined on a single table without any aggregate functions

– Can be mapped to an update on underlying base table- possible if the
primary key is preserved in the view

Update not permitted on aggregate views. E.g.,

UPDATE DEPT_INFO
SET Total_sal=100000
WHERE Dname=‘Research’;

Cannot be processed because Total_sal is a computed value in the view

definition

Database Design 20 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Views as authorization mechanism

SQL query authorization statements Views can be used to hide certain

attributes or tuples from unauthorized users.
Suppose a certain user is only allowed to see employee information for
employees who
work for department 5;
Then we can create the following view DEPT5EMP and grant the user the
privilege to query the view but not the base table EMPLOYEE itself.
This user will only be able to retrieve employee information for employee
tuples whose Dno = 5, and will not be able to see other employee tuples when
the view is queried.
Database Design 21 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Views as authorization mechanism

CREATE VIEW DEPT5EMP AS

SELECT *
FROM EMPLOYEE
WHERE Dno = 5;

In a similar manner, a view can restrict a user to only see certain columns;
for
example, only the first name, last name, and address of an employee may
be visible
as follows:

Database Design 22 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Summary of SQL Syntax

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 23 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Summary of SQL Syntax

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 24 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Summary of SQL Syntax

 Complex SQL:
 Nested queries, joined tables (in the FROM clause), outer joins,
aggregate functions, grouping
 Handling semantic constraints with CREATE ASSERTION and CREATE
TRIGGER
 CREATE VIEW statement and materialization strategies
 Schema Modification for the DBAs using ALTER TABLE , ADD and DROP
COLUMN, ALTER CONSTRAINT etc.
Copyright @2007 Ramez Elmasri, Shamkant B. Navathe
Database Design 25 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 SUBSTRING() Function
• The SUBSTRING() extracts a substring with a specified length starting from a
location in an input string.
• The syntax of the SUBSTRING() function:
SUBSTRING(input_string, start, length);
• In this syntax:
• input_string can be a character, binary, text, ntext, or image expression.
• start is an integer that specifies the location where the returned
substring starts. Note that the first character in the input_string is
1, not zero.
• length is a positive integer that specifies the number of characters of
the substring to be returned. The SUBSTRING() function raises an error
if the length is negative. If start + length > the length of input_string,
the substring will begin at the start and include the remaining
characters of the input_string.
Database Design 26 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 SUBSTRING() examples-1
A) Using SUBSTRING() function with literal strings
• This example extracts a substring with the length of 6, starting from the
fifth character, in the 'SQL Server SUBSTRING' string.
SELECT SUBSTRING('SQL Server SUBSTRING', 5, 6) result;
• output:
result
------
Server
(1 row affected)

Database Design 27 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 SUBSTRING() examples-2
B) Using SUBSTRING() function with table columns
• The example returns the names attribute in the first column, the first letter of
the name attribute in the second column, and the third and fourth characters
in the final column.
SELECT name, SUBSTRING(name, 1, 1) AS Initial ,
SUBSTRING(name, 3, 2) AS ThirdAndFourthCharacters
FROM sys.databases
WHERE database_id < 5;
• Output: name Initial ThirdAndFourthCharacters
master M St
tempdb T Mp
model M De
msdb M Db

Database Design 28 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 REPLACE() function
• Replace in SQL is a built-in function that allows you to replace all the
incidents of a substring within a specified string with a new substring.
• To replace all occurrences of a substring within a string with a new
substring.
• Syntax
REPLACE(input_string, substring, new_substring);
• In this syntax:
• input_string is any string expression to be searched.
• substring is the substring to be replaced.
• new_substring is the replacement string.
• The REPLACE() function returns a new string in which all occurrences of
the substring are replaced by the new_substring.
• It returns NULL if any argument is NULL.
Database Design 29 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Distinct Keyword

• The SQL DISTINCT keyword is used in conjunction with the SELECT

statement to eliminate all the duplicate records and fetching only unique
records.
• There may be a situation when you have multiple duplicate records in a
table, it makes more sense to fetch only those unique records instead of
fetching duplicate records.
• Syntax
SELECT DISTINCT column1, column2,.....columnN
FROM table_name
WHERE [condition]

Database Design 30 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 SQL - LIKE Operator
• The LIKE operator is used in a WHERE clause to search for a specified
pattern in a column.
• There are two wildcards often used in conjunction with the LIKE
operator:
• The percent sign (%) represents zero, one, or multiple characters
• The underscore sign (_) represents one, single character
• You can also combine any number of conditions using AND or OR
operators.
• Syntax-
SELECT column1, column2, ...
FROM table_name
WHERE columnN LIKE pattern;

Database Design 31 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Examples :LIKE operators with '%' and '_' wildcards:
LIKE Operator Description

WHERE CustomerName LIKE 'a%' Finds any values that start with "a"

WHERE CustomerName LIKE '%a' Finds any values that end with "a"

WHERE CustomerName LIKE '%or%' Finds any values that have "or" in any position

WHERE CustomerName LIKE '_r%' Finds any values that have "r" in the second position

WHERE CustomerName LIKE 'a_%' Finds any values that start with "a" and are at least 2
characters in length

WHERE CustomerName LIKE 'a__%' Finds any values that start with "a" and are at least 3
characters in length

WHERE ContactName LIKE 'a%o' Finds any values that start with "a" and ends with "o"

Database Design 32 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #1.1: (create)
Q1: Create the table suppliers that contains four columns: supplier_id,
supplier_name, city, state and supplier_id is primary key

Solution:
CREATE TABLE suppliers
( supplier_id int NOT NULL,
supplier_name char(50) NOT NULL,
city char(50),
state char(25),
CONSTRAINT suppliers_pk PRIMARY KEY (supplier_id)
);

Database Design 33 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #1.2 (insert)
Q2: Insert some records in the table suppliers that contains four columns:
supplier_id, supplier_name, city, state and supplier_id is primary key
Solution:
INSERT INTO suppliers (supplier_id, supplier_name, city, state)
VALUES (100, 'Microsoft', 'Redmond', 'Washington’),
(200, 'Google', 'Mountain View', 'California’),
(300, 'Oracle', 'Redwood City', 'California’),
(400, 'Kimberly-Clark', 'Irving', 'Texas’),
(500, 'Tyson Foods', 'Springdale', 'Arkansas’),
(600, 'SC Johnson', 'Racine', 'Wisconsin’),
(700, 'Dole Food Company', 'Westlake Village', 'California’),
(800, 'Flowers Foods', 'Thomasville', 'Georgia’),
(900, 'Electronic Arts', 'Redwood City', 'California');
Database Design 34 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #1.3: (select)
Q3: Based on the supplier table, select the unique city values that reside in
the state of California and order the results in descending order by city:
• Solution:
SELECT DISTINCT city
FROM suppliers
WHERE state = 'California'
ORDER BY city DESC;
• These are the results that you should see:
city

Westlake Village

Redwood City

Mountain View

Database Design 35 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #1.4: (update)
Q4: Based on the suppliers table populated with the following data, update
the city to 'Boise' and the state to "Idaho" for all records whose
supplier_name is "Microsoft".
Solution: UPDATE suppliers SET city = 'Boise’,
state = 'Idaho’ WHERE supplier_name = 'Microsoft’;
supplier_id supplier_name city state
The supplier table 100 Microsoft Boise Idaho
would now look like this200 Google Mountain View California
300 Oracle Redwood City California
400 Kimberly-Clark Irving Texas
500 Tyson Foods Springdale Arkansas
600 SC Johnson Racine Wisconsin
Dole Food
700 Westlake Village California
Company
800 Flowers Foods Thomasville Georgia
900 Electronic Arts Redwood City California
Database Design 36 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #1.5: (delete)
Q5: Based on the suppliers table, delete the supplier record whose state is
'California' and supplier_name is not Google:
Solution: DELETE FROM suppliers WHERE state = 'California’
AND supplier_name <> 'Google’;
There would be 3 records deleted and the suppliers table would now look like
this:
supplier_id supplier_name city state

100 Microsoft Redmond Washington

200 Google Mountain View California
400 Kimberly-Clark Irving Texas
500 Tyson Foods Springdale Arkansas
600 SC Johnson Racine Wisconsin
800 Flowers Foods Thomasville Georgia

Database Design 37 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #2
Sample employees table for the queries:

CREATE TABLE employees

( employee_number int NOT NULL,
last_name char(50) NOT NULL,
first_name char(50) NOT NULL,
salary int,
dept_id int, emailid varchar(100),
CONSTRAINT employees_pk PRIMARY KEY (employee_number)
);

Database Design 38 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #2:
INSERT INTO employees
(employee_number, last_name, first_name, salary, dept_id, emailid)
VALUES
(1001, 'Smith', 'John', 62000, 500, ‘[email protected]’),
(1002, 'Anderson', 'Jane', 57500, 500, ‘[email protected]’),
(1003, 'Everest', 'Brad', 71000, 501, ‘[email protected]’),
(1004, 'Horvath', 'Jack', 42000, 501, ‘[email protected]’);
(1005, ‘Mohan', ‘Radha’, 55000, 502, ‘[email protected]’);

Database Design 39 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #2:
1. Select all fields from the employees table whose salary is less than or
equal to $52,500 (no sorting is required)
2. Select the details of the employee whose first name starts with B.
3. Print name and Id of employee whose email-id is in Gmail.
4. Select the details of the employee who work either for department 501
or 502.
5. Select all the employees working in department 501 in descending
order of their salary.

Database Design 40 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Solution for Practice Exercise #2

• Solution 1:
SELECT * FROM employees WHERE salary <= 52500;
• Output:
employee_number last_name first_name Salary dept_id Emailid
1004 Horvath Jack 42000 501 [email protected]
• Solution 2:
SELECT * FROM employees WHERE first_name like ‘b%’
• Output:-
employee_number last_name first_name salary dept_id emailid
1003 Everest Brad 71000 501 [email protected]

Database Design 41 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Solution for Practice Exercise #2
• Solution 3:
SELECT employee_number as E_no, last_name, first_name FROM
employees where emailid like '%@gmail.com’;
• Output E_no last_name first_name
1001 smith John
• Solution 4: 1002 Anderson Jano

SELECT * FROM employees WHERE dept_id=501 or dept_id=502; or

SELECT * FROM employees WHERE dept_id in (501, 502)
Output:-
employee_number last_name first_name salary dept_id emailid
1003 Everest Brad 71000 501 [email protected]
1004 Horvath Jack 42000 501 [email protected]
1005 Mohan Radha 55000 502 [email protected]

Database Design 42 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Solution for Practice Exercise #2

• Solution 5:
SELECT * FROM employees WHERE dept=501 ORDER BY salary DESC;

• Output

employee_number last_name first_name salary dept_id emailid

1003 Everest Brad 71000 501 [email protected]
1004 Horvath Jack 42000 501 [email protected]

Database Design 43 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #3
Sample customers table:

Cust_id First_name Last_name Gender Phone_number

100 Steven Austin M 515.123.4567
101 Neena Singh F 515.124.4568
102 Bruce King M 516.124.4569
103 David Russell M 590.123.4560
104 Den Lee M 590.124.4561
105 John Gates M 590.423.4565
106 Amit Banda M 515.124.4550
107 Sundar Bhatt M 590.124.4566
108 Clara Doran F 515.123.4562

Database Design 44 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Practice Exercise #3:
1. Write a query to update the portion of the phone_number in the customers
table, within the phone number the substring '124' will be replaced by '999’.
2. Write a query to get the details of the customers where the length of the first
name greater than or equal to 6.
3. Write a query to extract the last 4 character of phone numbers.
4. Write a query that displays the first name and the length of the first name for
all customers whose name starts with the letters ‘D', 'J' or ‘N'. Give each
column an appropriate label. Sort the results by the employees' first names.
5. Write a query to display the length of first name for employees where
last name contain character ‘a' after 2nd position.

Database Design 45 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Solution Practice Exercise #3:
• Solution Q1:
UPDATE customers SET phone_number = REPLACE(phone_number, '124',
'999')
WHERE phone_number LIKE '%124%’;
• Solution Q2:
SELECT * FROM customers WHERE LENGTH(first_name) >= 6;
• Solution Q3:
SELECT SUBSTRING(phone_number, 9, 4) as ‘Ph.no’ FROM customers;
• Solution Q4:
SELECT first_name "Name", LENGTH(first_name) "Length" FROM customers
WHERE first_name LIKE ‘D%' OR first_name LIKE ‘J%' OR first_name LIKE ‘N%'
ORDER BY first_name ;
• Solution Q5:
SELECT first_name, last_name FROM customers WHERE INSTR(last_name,’A')
> 2;
Database Design 46 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 Thank you

Copyright @2007 Ramez Elmasri, Shamkant B. Navathe

Database Design 47 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 DATABASE DESIGN
BITS Pilani SESSION - 8
Pilani Campus
 BITS Pilani
Pilani Campus

DEPENDENCY AND
NORMALIZATION
Learning Objectives

 What is Functional Dependency?

 Different types of dependencies
(i) Functionally dependent
(ii) Partially dependent
(iii) Transitive dependent
 What is Normalization ?
 Different types of Normal forms
i. First normal form
ii. Second normal form
iii. Third normal form
iv. Boyce Codd normal form
 Exercises
3
Database Design - Session 8 BITS Pilani, Pilani Campus
Functional Dependency

What is a Functional Dependency?

Functional Dependency (FD) determines the relation of one
attribute to another attribute in a database management
system (DBMS) system.
Functional dependency helps you to maintain the quality of
data in the database. A functional dependency is denoted
by an arrow →.
If attribute A functionally determines attribute B we write this
as A→B.
Functional Dependency plays a vital role to find the
difference between good and bad database design.
Assume that an employee table consists of the data about
employees who are working in a company as
4
Database Design - Session 8 BITS Pilani, Pilani Campus
Functional Dependency
EMPLOYEE
EmpNo EmpName Dept Salary
E101 Zaheer HR 78000
E102 Basheer Production 67000
E103 Naveen Sales 54000
E110 Siva System 60000
E112 Shankar Production 39000

In this example, if we know the value of EmpNo(Employee

number), we can obtain EmpName, Dept and salary.
By this, we can say that the EmpName, Dept and Salary are
functionally dependent on Employee number.
5
Database Design - Session 8 BITS Pilani, Pilani Campus
Functional Dependency
It is represented as follows
EmpNo  EmpName, Dept ,Salary
In other words, we can say that for each EmpNo, there is a
single value for attributes EmpName, Dept and Salary.
There are various types of functional dependencies:
1. Fully Functional dependency
2. Partial Functional dependency
3. Transitive Functional dependency
The dependencies which are used in normalization process are
1. Partial dependency and
2. Transitive dependency

6
Database Design - Session 8 BITS Pilani, Pilani Campus
Full Functional Dependency

In full functional dependency an attribute or a set of

attributes uniquely determines another attribute or set
of attributes.
If a relation R has attributes X, Y, Z with the dependencies
X->Y and X->Z which states that those dependencies are
fully functional.
Example:
In the given Employee relation, if we know the value of
EmpNo(Employee number), we can obtain EmpName,
Dept and salary.
By this, we can say that the EmpName, Dept and Salary
are fully functionally dependent on Employee
number.
BITS Pilani, Pilani Campus
Partial Functional
Dependency
Partial Dependency
Assume that a table consists of two attributes are
combined for forming a primary key.
All non key attributes may either depend on both the key
attributes or depend on any one of the key attribute.
If all non key attributes in the table are functionally
dependent on any one of the key attributes (not
dependent on both), the dependency is called as partial
dependency
Example :
Assume that STUDENT table consists of student
information as follows:
8
Database Design - Session 8 BITS Pilani, Pilani Campus
Partial Functional
Dependency
STUDENT Key attributes Non-key attributes

StuID FacultyID FacName Course

S001 F1001 Mr. A DBSA
S101 F1005 Mr. B Datastructures
S006 F1001 Mr. A DBSA
S010 F0024 Mr.C OOPS
S001 F1111 Mr.D Web
Technology
S101 F0012 Mr. M Unix
S101 F0024 Mr.C OOPS
9
Database Design - Session 8 BITS Pilani, Pilani Campus
Partial Functional
Dependency
In the above table, the non key attribute FacName is
functionally dependent on only FacultyID (not on the
other key attribute StuID).
So the table has Partial Dependency.
Note :- If a table has a single key attribute, it does not
have partial dependency by default.

10
Database Design - Session 8 BITS Pilani, Pilani Campus
Transitive dependency

Transitive dependency
We know that a table consists of both key attributes and
non key attributes in which the key attributes are
used to identify /locate a record /a tuple uniquely.
All the non key attributes are functionally dependent on
the key attribute (s).
There are some instances in which a non key attribute
may depend on another non key attribute.
If a table has such type of attribute, the table is said to
be having transitive dependency.

BITS Pilani, Pilani Campus

Transitive dependency

Example: Assume that a STUDENT table consists of the

student records as follows:
STUDENT
StuID FacultyID FacName Qual
S001 F1001 Mr. A ME , PhD
S101 F1005 Mr. B ME
S006 F1001 Mr. A ME , PhD
S010 F0024 Mr.C Mtech

In the above table, StuID and FacultyID are the key

attributes.
FacName and Qual are the non key attributes.
12
Database Design - Session 8 BITS Pilani, Pilani Campus
Functional Dependency
The non key attribute Qual is functionally dependent on
another non key attribute, FacName.

FacName Qual

Hence, the table STUDENT has transitive dependency.

If a table has some dependencies like partial
dependency and transitive dependency, there are lot
of redundancy (duplication).

13
Database Design - Session 8 BITS Pilani, Pilani Campus
Functional Dependency

Advantages of Functional Dependency

The advantages of functional dependency are
(i) Functional Dependency enables to idendify and avoid data
redundancy.
Therefore same data do not repeat at multiple locations in
the database
(ii) It helps you to maintain the quality of data in the database
(iii) It helps you to defined meanings and constraints of
databases
(iv) It helps you to identify bad designs
(v) It helps you to find the facts regarding the database
design
14
Database Design - Session 8 BITS Pilani, Pilani Campus
Data Normalization

Data normalization is the process of organizing data in

a database in order to minimize redundancy and
increase data integrity.
Functional dependencies play an important part in data
normalization.
With the help of functional dependencies we are able to
identify the primary key, candidate key in a table
which in turns helps in normalization.

BITS Pilani, Pilani Campus

NORMALIZATION
Normalization is the analysis of functional dependency
between attributes of user views.
It reduces the complex user view to a set of small and
stable subgroups of fields / relations.
This process helps to design a logical data model known
as conceptual data model.
There are different levels of normalization as listed below:
1. Un normalized form ( UNF ) – The relation is in un
normalized form if it satisfies all the properties of a
relation
2. First normal form ( 1NF ) – The relation is said to be in
the first normal form if it is already in the un normalized
form and has no repeating group.
16
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
3. Second normal form ( 2NF ) – The relation is said to be in
the second normal form if it is already in the first
normalized form and has no partial dependency.
In a relation having more than one key field , a sub set of non
– key fields may depend on all the key fields but another
subset / a particular non – key fields may depend on only
one of the key fields ( ie., not depend on all the key fields ).
Such dependency is called as the partial dependency.
4. Third normal form ( 3NF ) – The relation is said to be in
the third normal form if it is already in the second form and
has no transitive dependency.
In a relation, there may be dependency among non – key
fields.
Such dependency is called as transitive dependency.
17
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

5. Boyce – Codd form ( BCNF ) – The relation is said to be in

the Boyce – codd normal form if it is already in the third
normal form and every determinant is a candidate key.
It is a stricter version of the third normal form.
A determinant is any field ( simple or composite field ) on
which some other field is fully functionally dependent.

18
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION - Example

CASE PROBLEM
Let us consider the two report requirements namely , INVOICE
and REORDER REPORT of XYZ book house as shown in the
following figures:
XYZ Book House
Chennai – 600 001
Customer N0 : C10001
Customer Name : WIPRO Systems Date : XX / XX / XX
Customer Address : Chennai - 125
Book# Title Author’s Name No.of copies Price (Rs.) Amount
Rs.
B10001 Production and Operations Management Benher10 50 250
B10010 System Simulation Gordon 20 400 8000
B10011 Engineering Mathematics Benher 40 300 12000

Invoice of a book company

19
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
The XYZ book house supplies the books to the institutions
which frequently buy books from them.
The customers are very keen on the data item namely author.
Normalization of Invoice report.
The invoice report is represented in the relation mentioned
above.
The relation is named as INVOICE.
This is in un normalized form.
It is represented as
INVOICE ( Cus_no, Cus_name, Cus_Add, Book_No, Title,
Author_name, Auth_coun, Unit_price)

20
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

The amount in the last column of the invoice for each book
can be computed by multiplying the number of copies
( Qty) with their respective unit price.
Similarly, the grand total at the bottom of the invoice
representing the invoice amount can be calculated by
summing the entries in the last column of the invoice.
Similarly, the date at the top right corner of the invoice can
be printed using the system clock.
A sample instance of the data of the INVOICE relation is
shown in the following table.
This is nothing but the file containing all the data items of the
INVOICE report.

21
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

Sample Invoice Form

Cus_no Cus_name Cus_Add Book_No Title Author_name Auth_coun Unit_price
C1001 SIST Chennai-1 B1001 Applied OR Manmohan INDIA 355
C1001 SIST Chennai-1 B1010 OOPS with C++ Schildt US 450
C1001 SIST Chennai-1 B2000 Java Herbert US 525
C1002 RMK Chennai-10 B2000 Java Herbert US 525

The above relation is in un normalized form.

FIRST NORMAL FORM
First normal form ( 1NF ) – The relation is said to be in the first
normal form if it is already in the un normalized form and has
no repeating group.
In the above relation the fields Cus_no , Cus_name and Cus_Add
are forming repaeating group.

22
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

This will result in redundancy of data for the first three

fields.
It leads to inconsistency of data.
Hence the relation can be divided into two sub relations to
remove the repeating group as
CUSTOMER (Cus_no , Cus_name and Cus_Add)
CUSTOMER-BOOK(Cus_no , Book_No , Title , Author_name ,
Auth_coun, Unit_price )
The corresponding relations in their normalized form are as
follows:

23
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

CUSTOMER relation [Relation 2]

Cus_no Cus_name Cus_Add

C1001 SIST Chennai-1

C1001 SIST Chennai-1
C1001 SIST Chennai-1
C1002 RMK Chennai-10

CUSTOMER-BOOK relation [Relation 3]

Cus_no Book_No Title Author_name Auth_coun Unit_price

C1001 B1001 OOPS with C++ Manmohan INDIA 355

C1001 B1010 Applied OR Schildt US 450
C1001 B2000 Java Herbert US 525
C1002 B2000 Java Herbert US 525

Now each relation is in 1NF.

24
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
SECOND NORMAL FORM
The relation is said to be in the second normal form if it is
already in the first normalized form and has no partial
dependency.
In relation 2 (CUSTOMER relation ), the number of key fields
is only one and hence there is no scope for partial
dependency.
The absence of partial dependency in a relation takes it to
the 2NF without any modification.
But in relation 1 ( CUSTOMER-BOOK relation), the field Qty
depends on Cus_No as well as Book_No.
But the non key fields (Title , Author_name, Unit_price )
depend only on Book_No.
This situation is an example of partial dependency.
25
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

Partial dependency will result into insertion update and

deletion anomalies.
Insertion Anomaly :- In the relation 3, if we want to insert
data of a new book , there must be at least one customer
buying it.
It means that a new book can be inserted into the
CUSTMOER-BOOK relation only when the first customer
buys the book.
Update Anomaly :- In the relation, if we want to change any
non key fields , it will result into inconsistency because the
same is available in more than one record.
This is an example for updation anomaly.

26
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

Deletion Anomaly :- Once the customer order is fully

satisfied, the customer’s record should be deleted.
If the customer is the only person buying a particular book ,
the information of the book will not be available when
his/her record is deleted.
To overcome this, relation 3 is divided into two relations as
relation 4 and relation 5 where both of them are in the 2nd
Normal form as

SALES(Cus_no , Book_No Qty )

BOOK-AUTHOR(Book_No , Title , Author_name , Unit_price )

27
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
The corresponding relations are:
SALES relation (Relation 4)
Cus_no Book_No
C1001 B1001
C1001 B1010
C1001 B2000
C1002 B2000

BOOK-AUTHOR relation (Relation 5)

Book_No Title Author_name Auth_coun

B1001 Applied OR Manmohan INDIA

B1010 OOPS with C++ Schildt US
B2000 Java Herber US
B2000 Java Herbert US

In the relations , there are no partial dependencies.

.

28
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
So both the relations are in second normal form.
THIRD NORMAL FORM
The relation is said to be in the third normal form if it is already
in the second form and has no transitive dependency.
In a relation, there may be dependency among non – key fields.
Such dependency is called as transitive dependency.
In relation 4 (SALES relation ), there is only one non - key field
and hence there is no scope for any dependency between the
non – key fields.
It means that there is no transitive dependency.
Hence the relation 3 can be treated to be in 3NF without any
modification. But in relation 5 (BOOK-AUTHOR relation), the
field Auth_Coun depends on author’s name.

29
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
This situation is an example of the transitive dependency.
Transitive dependency will result into insertion update and
deletion anomalies.
Insertion Anomaly :- In case, the book has resident authors
who are in the process of developing new books, it will be
difficult to include the author’s detail in relation 5 .
It means that there should be at least one published book to
insert the details of a resident author.
Update Anomaly :- Since the author’s details are duplicated ,
there will be significant redundancy and inconsistency.
Some problem arises when the updation is done.
Deletion Anomaly :- If the only book of a resident author is
not reprinted , then the respective author’s data is lost.
30
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

To overcome these anomalies, relation 5 can be divided into

two relations as
BOOK (Book_No , Title , Author_name )
AUTHOR(Author_name , Author_Coun )
The corresponding relations are:
BOOK relation (Relation 6)
Book_No Title Author_name

B1001 Applied OR Manmohan

B1010 OOPS with C++ Schildt
B2000 Java Herbert
B2000 Java Herbert

31
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

AUTHOR relation (Relation 7)

Author_name Auth_coun

Manmohan INDIA
Schildt US
Herbert US
Herbert US

In the relations , there are no partial dependencies.

So both the relations are in second normal form.
For practical applications , it is sufficient to normalize up to
3NF.

32
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

4. Boyce Codd Normal form (BCNF)

A table is said to be in Boyce Codd Normal form iff it is
already in third normal form and every determinant
in the relation is a candidate key.
Candidate Key – It is an attribute or a collection of
attributes that uniquely identify a record
Determinant- The attribute on the left hand size of the
arrow in representing the functional dependency is
called as the determinant.
Let Y is an attribute that is functionally dependent on
another attribute X and is denoted as

33
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

X Y
where the attribute X is the determinant
Example: Assume that a student table consists of
student data with the following restrictions:
(i) An advisor can handle only one major subject
(ii) A Major Subject may have multiple advisors
According to the restrictions, we identify that Major is
functionally dependent on Advisor.
So we have the representation
Advisor Major

34
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION
The table is given as

StuID AdvisorID Major_Sub Major_Grade

S1 A1 M1 A+
S1 A2 M1 A+
S3 A2 M1 B
S4 A1 M1 C
S5 A2 M1 A
The table is in third normal form because it has no
repeating group, no partial dependency and
transitive dependency.

35
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

But it is not in BCNF because the determinant (Advisor)

is not a candidate key (ie. it is only a part of the key)
because the combination of the attributes StuID and
AdvisorID is used as the candidate key.
To make the table to be in Boyce Codd Normal form ,
we have to split the table into two tables such as
STUDENT (StudID,AdvisorId, Major_Grade)
Advisor(AdvisorID,Major_Sub)
The records of these tables are

36
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

STUDENT
StuID AdvisorID Major_Grade
S1 A1 A+
S1 A2 A+
S3 A2 B
S4 A1 C
S5 A2 A
ADVISOR
AdvisorID Major_Sub
A1 M1
A2 M1
In both the tables every determinant is a candidate key. So
the
tables are in Boyce Codd Normal form 37
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

ADVANTAGES OF NORMALIZATION
Here we can see why normalization is an attractive prospect in
RDBMS concepts.
1) A smaller database can be maintained as normalization
eliminates the duplicate data. Overall size of the database is
reduced as a result.
2) Better performance is ensured which can be linked to the
above point. As databases become lesser in size, the passes
through the data becomes faster and shorter thereby
improving response time and speed.
3) Narrower tables are possible as normalized tables will be
fine-tuned and will have lesser columns which allows for
more data records per page.
38
Database Design - Session 8 BITS Pilani, Pilani Campus
NORMALIZATION

4) Fewer indexes per table ensures faster maintenance tasks

(index rebuilds).
5) Also realizes the option of joining only the tables that are
needed.
DISADVANTAGES OF NORMALIZATION
1) More tables to join as by spreading out data into more
tables, the need to join table’s increases and the task
becomes more tedious.
2) Data model becomes extremely difficult to query against
as the data model is optimized for applications

39
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

Let us take an EMPLOYEE table consisting of the employee

records as follows:
EMPLOYEE
EmpId EmpName DeptId Salary
E001 Nikhil D100 76000
E002 Suresh D106 45200
E003 Kamal D100 55000
E004 Kavya D101 49000
E005 Ramya D108 56240
E006 Keshav D101 34500
E007 Midhun D100 49000
E010 Saran D101 34800
40
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise
Query 1: Write SQL command to display all employee records
who are getting salary between Rs.40000 and Rs.60000
Solution:
Select * from EMPLOYEE where salary >40000 AND
salary <60000;
Query 2: Write SQL command to display all employee records
Whose name begins with ‘K’
Solution:
Select * from EMPLOYEE where EmpName LIKE ‘K%’;
Query 3: Write SQL command to display the number of
departments in the company
Solution:
Select distinct( count(DeptId)) from EMPLOYEE;
41
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

Query 4: Write SQL command to add 5% increment in salary

those who are getting the salary <= average salary
Solution:
Update EMPLOYEE
set salary=salary+0.05*salary where
salary<=(select avg(salary) from EMPLOYEE);
Query 5: Write SQL command to display the DeptId that have
less than 2 people in it
Solution:
Select DeptId, count(DeptId) from EMPLOYEE where
group by DeptId having count(DeptId)<2;

42
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

Query 6: Write SQL command to fetch departments along

with the total salaries paid for each department
Solution:
Select DeptId,sum(salary) from EMPLOYEE group by DeptId;
Query 7: Write SQL command to display the name and salary
of the employees who earn more than EmpId ‘E004’
Solution:
Select EmpName,salary from EMPLOYEE where
salary > (select salary from EMPLOYEE where
EmpId=‘E004’);

43
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

Query 8: Write SQL command to fetch the list of employees

with the same salary
Solution:
Select distinct E1.EmpId,E1.EmpName,E1.Salary from
EMPLOYEE E1,EMPLOYEE E2 where
E1.salary=E2.salary and E1.EmpId!=E2.EmpId;
Query 9: Write SQL command to display the employee
records whose names are neither ‘Ramya’ nor ‘Midhun’
Solution:
Select * from EMPLOYEE where
EmpName not in (‘Ramya’,’Midhun’);

44
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

Assume that a Store has different branches to sell the

products.
It does the sales through internet also. The data are given in
the following tables:
STORES
Store_location Sales Date
Chennai 280050 5-5-2020
Bangalore 432000 6-5-2020
Madurai 120000 5-5-2020
Chennai 490000 6-5-2020
Bangalore 343250 10-5-2020
Chennai 123000 15-5-2020
45
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

INTERNET
Date Sales
5-5-2020 45000
7-5-2020 34300
8-5-2020 10450
13-5-202 23325
16-5-2020 45000

Examples:
1.If we want to find out all the dates where there is a sales transaction,
the SQL command is
SELECT Date FROM STORES UNION SELECT Date FROM INTERNET;
46
Database Design - Session 8 BITS Pilani, Pilani Campus
Exercise

2. If we want to find out all the dates where there are both store sales
and internet sales, we use the following SQL command
SELECT Date FROM STORES INTERSECT
SELECT Date FROM INTERNET;
3. We want to find out all the dates where there are store sales, but no
internet sales. To do so, we use the following SQL statement:
SELECT Date FROM STORES MINUS
SELECT Date FROM INTERNET;

47
Database Design - Session 8 BITS Pilani, Pilani Campus
Thanks

48
BITS Pilani, Pilani Campus