R18 B.TECH. COMPUTER SCIENCE & ENGG.

CS407PC: DATABASE MANAGEMENT SYSTEMS LAB

B.TECH II Year II Sem. L T P C

0 0 3 1.5
Co-requisites:
 Co-requisite of course “Database Management Systems”

Course Objectives:
 Introduce ER data model, database design and normalization
 Learn SQL basics for data definition and data manipulation

Course Outcomes:
 Design database schema for a given application and apply normalization
 Acquire skills in using SQL commands for data definition and data manipulation.
 Develop solutions for database applications using procedures, cursors and triggers

LIST OF EXPERIMENTS:
1. Concept design with E-R Model
2. Relational Model
3. Normalization
4. Practicing DDL commands
5. Practicing DML commands
6. Querying (using ANY, ALL, IN, Exists, NOT EXISTS, UNION, INTERSECT, Constraints
etc.)
7. Queries using Aggregate functions, GROUP BY, HAVING and Creation and dropping of
Views.
8. Triggers (Creation of insert trigger, delete trigger, update trigger)
9. Procedures
10. Usage of Cursors

TEXT BOOKS:
1. Database Management Systems, Raghurama Krishnan, Johannes Gehrke, Tata Mc Graw
Hill, 3rd Edition
2. Database System Concepts, Silberschatz, Korth, McGraw Hill, V edition.

REFERENCES BOOKS:
1. Database Systems design, Implementation, and Management, Peter Rob & Carlos Coronel
7th Edition.
2. Fundamentals of Database Systems, Elmasri Navrate, Pearson Education
3. Introduction to Database Systems, C.J. Date, Pearson Education
4. Oracle for Professionals, The X Team, S. Shah and V. Shah, SPD.
5. Database Systems Using Oracle: A Simplified guide to SQL and PL/SQL, Shah, PHI.
6. Fundamentals of Database Management Systems, M. L. Gillenson, Wiley Student Edition.
 Analyze the problem and come with the entities in it. Identify what Data has to be persisted in
the databases. The Following are the entities and its attributes.

ACCOUNT:

Acc_no Branch_name Balance

A-101 Ccc 500

A-102 Ddd 400

A-201 Bbb 900

A-215 Yyy 700

A-217 Bbb 750

A-222 Mmm 700

A-305 Aaa 350

BRANCH:

branch_name branch_city assets

bbb city1 7100000

ccc city1 9000000

yyy city2 400000

nnn city3 3700000

ddd city2 1700000

ppp city4 300000

mmm city5 2100000

aaa city2 8000000

DEPOSITOR:

cust_name Acc_no

Johnson A-101

Hayes A-102

Johnson A-201

Smith A-215

Jones A-217

Lindsay A-222

Turner A-305

BORROWER:

cust_name Loan_no

Smith L11

Jackson L14

Hayes L15

Adams L16

Jones L17

Williams L17

Smith L23

Curry L93

LOAN:

Loan_no branch_name amount

L11 aaa 900

L14 ccc 1500

L15 ddd 1500

L16 ddd 1300

 L17 ccc 1000

L23 mmm 2000

L93 yyy 500

1. Account:
Acc_no: varchar (10) (primary key)
Branch_name: varchar (20)
Balance: int (10)

2. Branch:
Branch_name: varchar (20)
B_city: varchar (20)
Assets: int(15)

3.Depositor:
Cust_name : varchar(20)
Acc_No: varchar(20) (foreign key)

4.Borrower :
Cust_name : varchar(20)
Loan_No: varchar(20) (foreign key)

5.Loan:
Loan_No : varchar(20)(primary key)
Branch_name:varchar(20)
Amount : int(10)
6.Customer:
Cust_id : varchar(20)(primary key)
Cust_name:varchar(20)
Cust_street:varchar(20)
Cust_city:varchar(20)
 1: Concept design with E-R model
Symbols Used in E-R Notation

E-R Diagrams

 Rectangles represent entity sets.

 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to relationship sets.
 Ellipses represent attributes
--Double ellipses represent multivalued attributes.
--Dashed ellipses denote derived attributes.
 Underline indicates primary key attribute
 E-R Diagram With Composite, Multivalued, and Derived Attributes

Relationship Sets with Attributes

Cardinality Constraints

 We express cardinality constraints by drawing either a directed line (), signifying “one,” or an
undirected line (—), signifying “many,” between the relationship set and the entity set.
 One-to-one relationship:
--A customer is associated with at most one loan via the relationship borrower
--A loan is associated with at most one customer via borrower
 In the one-to-many relationship a loan is associated with at most one customer via borrower, a
customer is associated with several (including 0) loans via borrower
 In a many-to-one relationship a loan is associated with several (including 0) customers via
borrower, a customer is associated with at most one loan via borrower

 In a many-to-many relationship a customer is associated with several (possibly 0) loans via

borrower
 A loan is associated with several (possibly 0) customers via borrower

Alternative Notation for Cardinality Limits

 Cardinality limits can also express participation constraints
 Weak Entity Sets

 We depict a weak entity set by double rectangles.

 We underline the discriminator of a weak entity set with a dashed line.
 payment_number – discriminator of the payment entity set
 Primary key for payment – (loan_number, payment_number)
E-R Diagram for a Banking Enterprise
 2: Relational Model
Represent all entities in a tabular fashion. Represent all relationships in a tabular fashion. The
following is tabular representation of the above entities and relationships

ACCOUNT:

Acc_no Branch_name Balance

BRANCH:

branch_name branch_city assets

DEPOSITOR:

cust_name Acc_no
BORROWER:

cust_name Loan_no

LOAN:

Loan_no branch_name amount

CUSTOMER:

Cust_id Cust_name Cust_street Cust_city

 3. NORMALIZATION
 Database Normalization is a technique of organizing the data in the database.
 Normalization is a systematic approach of decomposing tables to eliminate data
redundancy(repetition) and undesirable characteristics like Insertion, Update and Deletion
Anomalies.
 It is a multi-step process that puts data into tabular form, removing duplicated data from the
relation tables.
 Normalization is used for mainly two purposes,
--Eliminating redundant(useless) data.
--Ensuring data dependencies make sense i.e data is logically stored.

Problems Without Normalization

 If a table is not properly normalized and have data redundancy then it will not only eat up
extra memory space but will also make it difficult to handle and update the database, without
facing data loss.
 Insertion, Updation and Deletion Anomalies are very frequent if database is not normalized.
 To understand these anomalies let us take an example of a Student table.

rollno name branch hod office_tel

401 Akon CSE Mr. X 53337

402 Bkon CSE Mr. X 53337

403 Ckon CSE Mr. X 53337

404 Dkon CSE Mr. X 53337

 In the table above, we have data of 4 Computer Science students. As we can see, data for the
fields branch, hod(Head of Department) and office_tel is repeated for the students who are in
the same branch in the college, this is Data Redundancy.
 Insertion Anomaly:
 Suppose for a new admission, until and unless a student opts for a branch, data of the student
cannot be inserted, or else we will have to set the branch information as NULL.
Also, if we have to insert data of 100 students of same branch, then the branch information
will be repeated for all those 100 students.
These scenarios are nothing but Insertion anomalies.

 Updation Anomaly:

What if Mr. X leaves the college? or is no longer the HOD of computer science department?
In that case all the student records will have to be updated, and if by mistake we miss any
record, it will lead to data inconsistency. This is Updation anomaly.

 Deletion Anomaly:

In our Student table, two different informations are kept together, Student information and
Branch information. Hence, at the end of the academic year, if student records are deleted, we
will also lose the branch information. This is Deletion anomaly.

Normalization Rule:

Normalization rules are divided into the following normal forms:

1. First Normal Form

2. Second Normal Form
3. Third Normal Form
4. BCNF
5. Fourth Normal Form
6. Fifth Normal Form

1. First Normal Form (1NF)

For a table to be in the First Normal Form, it should follow the following 4 rules:

1. It should only have single(atomic) valued attributes/columns.

2. Values stored in a column should be of the same domain
3. All the columns in a table should have unique names.
4. And the order in which data is stored, does not matter.
 To illustrate the First normal form let us consider the below table:

roll_no name subject

501 Aaa OS, DBMS

502 Bbb Java

503 Ccc C, C++

 Our table already satisfies 3 rules out of the 4 rules, as all our column names are unique, we
have stored data in the order we wanted to and we have not inter-mixed different type of data
in columns.
 But out of the 3 different students in our table, 2 have opted for more than 1 subject. And we
have stored the subject names in a single column. But as per the 1st Normal form each column
must contain atomic value.
 It's very simple, because all we have to do is break the values into atomic values.
 Here is our updated table and it now satisfies the First Normal Form.

roll_no name subject

501 Aaa OS

501 Aaa DBMS

502 Bbb Java

503 Ccc C

503 ccc C++

2. Second Normal Form (2NF)

For a table to be in the Second Normal Form,

1. It should be in the First Normal form.

2. And, it should not have Partial Dependency.

Partial Dependency:

 In partial dependency, where an attribute in a table depends only on a part of the primary key
but not on the whole key.

Let us consider an example table:

stud_id subj_id marks teacher

510 1 77 Java Teacher

510 2 72 C++ Teacher

511 1 70 Java Teacher

 Here teacher depends on sub_id so teacher is partially dependent with sub_id

 Thus inorder to remove partially dependence, the above table should be divided into 2 tables,
named marks table and subject table:
Marks table

stud_id subject_id marks

510 1 77

510 2 72
 511 1 70

Subject table

subj_id Sub_name teacher

1 Java Java Teacher

2 C++ C++ Teacher

3 DBMS DBMS Teacher

3. Third Normal Form (3NF)

A table is said to be in the Third Normal Form when,

1. It is in the Second Normal form.

2. And, it doesn't have Transitive Dependency.

 Transitive Dependency means- when a non-prime attribute depends on other non-prime

attribute rather than depending upon the prime attribute.
 Let us consider the following marks table:

stud_id subj_id marks exam_name Total_marks

501 1 75 Java 50

502 2 75 DBMS 60

503 3 75 OS 56

 Here in above table we had inserted two extra columns exam_name and total_marks.
 Let us consider the primary key for the above table is composite key which is the combination
of 2 columns that is student_id and sub_id.
 In the above marks table exam name depends on both student_id and subject_id. But
total_marks depends on exam_name.
 Hence the above table is having Trasitive Dependency and is removed by decomposing the
above table into two tables: Marks table and Exam table

Marks table

stud_id subj_id marks

501 1 75

502 2 75

503 3 75

Exam table

subj_id exam_name Total_marks

1 Java 50

2 DBMS 60

3 OS 56

4. Boyce and Codd Normal Form (BCNF)

 BCNF is a higher version of the Third Normal form. This form deals with certain type of
anomaly that is not handled by 3NF. A 3NF table which does not have multiple
overlapping candidate keys is said to be in BCNF.
 For a table to be in BCNF, following conditions must be satisfied:

1.R must be in 3rd Normal Form

2.and, for each functional dependency ( X → Y ), X should be a super Key.

 Let us consider the below subject table:

 stud_id Subj_name Teacher_name

501 Java JavaTeacher1

501 C++ C++Teacher

502 Java JavaTeacher2

503 DBMS DBMSTeacher

504 Java JavaTeacher1

 In the above table 501 has opted for subjects java and C++, and we have two teachers for
Java subject.
 In the table above, student_id, subject form primary key, which means subject column is
a prime attribute.
 But, there is one more dependency, professor → subject.
 And while subject is a prime attribute, professor is a non-prime attribute, which is not
allowed by BCNF.
 To make this relation(table) satisfy BCNF, we will decompose this table into two
tables, student table and Teacher table.

stud_id Teacher_id

501 1

501 2

502 3

503 4

504 1

Teacher_id Teacher_name subj_name

1 JavaTacher1 Java

2 C++Teacher C++

3 JavaTeacher2 Java
 4 DBMSTeacher DBMS

5. Fourth Normal Form (4NF)

A table is said to be in the Fourth Normal Form when,

1. It is in the Boyce-Codd Normal Form.

2. And, it doesn't have Multi-Valued Dependency.

 A table is said to have Multi-valued dependency if and only if the following conditions are
true:
-- For a dependency AB, if for a single value of A multiple value of B exists then the
table may have multi-valued dependency
-- It should have atleast 3 columns.
-- For a relation R(A,B,C) if there is a multi-valued dependency between A and B the
B&C should be independent to each other.
 To illustrate the 4th normal form let us consider the below student table:

stud_id subject hobbies

1 science cricket

1 maths hockey

2 computer cricket

2 hindi hockey

 Here hobbies depends on stud_id so it contains multi-valued dependency, which can be

removed by decomposing the above table into 2 tables: subject table and hobbies table

stud_id subject

1 science

1 maths

2 computer

2 hindi
stud_id hobbies

1 cricket

1 hockey

2 cricket

2 hockey
 4: PRACTICING DDL COMMANDS.

CREATING Tables
a) Passenger Table

Create table Passenger (PNR_NO int(9) primary key , Ticket_NO int(9), Name
varchar(20), Age int(4), Sex char(10), PPNO varchar(15));

Desc Passenger;

b) Reservation Table

Create table Reservation (PNR_NO int(9), No_of_seats int(8), Address

varchar(50), Contact_No int(9), Status char(3));

Desc Reservation;

c) Bus Table

Create table Bus (Bus_No varchar (5) primary key, source varchar (20), destination
varchar (20));

Desc Bus;

d) Cancellation Table

Create table Cancellation (PNR_NO int(9), No_of_seats int(8), Address

varchar(50), Contact_No int(9), Status char(3));

Desc Cancellation;

e) Ticket Table
Create table Ticket (Ticket_No int(9) primary key, age int(4), sex char(4) Not null, source varchar(20),
destination varchar(20), dep_time varchar(4));

Desc Ticket;

ALTER Table

ALTER TABLE Reservation ADD FOREIGN KEY (PNR_NO) REFERENCES

Passenger (PNR_NO);

Result: query ok, 0 rows affected

ALTER TABLE Cancellation ADD FOREIGN KEY (PNR_NO) REFERENCES
Passenger (PNR_NO);

Result: query ok, 0 rows affected

Alter table Ticket add constraint check_age check (age>18);

Result: query ok, 0 rows affected

Drop command:

Drop table table name;

Truncate command:

Truncate table table name;

 5: PRACTICING DML COMMANDS
INSERT Command:

BUS;

INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b01', 'src1', 'des1');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b02', 'src2', 'des2');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b03', 'src3', 'des3');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b04', 'src4', 'des4');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b05', 'src5', 'des5');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b06', 'src6', 'des6');
Result: 1row affected
INSERT INTO bus (`Bus_No`, `source`, destination) VALUES ('b07', 'src7', 'des7');
Result: 1row affected

Select * from bus;

Bus_no source destination

b01 src1 des1
b02 src2 des2
b03 src3 des3
b04 src4 des4
b05 src5 des5
b06 src6 des6
b07 src7 des7

PASSENGER:

INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (1, 101, 'name_1', 13, 'm',
'pp01');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (2, 102, 'name_2', 14, 'f',
'pp02');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (3, 103, 'name_3', 15, 'm',
'pp03');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (4, 104, 'name_4', 16, 'f',
'pp04');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (5, 105, 'name_5', 17, 'm',
'pp05');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (6, 106, 'name_6', 18, 'f',
'pp06');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (7, 107, 'name_7', 19, 'm',
 'pp07');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (8, 108, 'name_8', 20, 'f',
'pp08');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (9, 109, 'name_9', 21, 'm',
'pp09');
Result: 1row affected
INSERT INTO passenger (`PNR_NO`, `Ticket_NO`, `Name`, `Age`, `Sex`, `PPNO`) VALUES (10, 110, 'name_10', 22, 'f',
'pp10');
Result: 1row affected

Select * from passenger;

Result:

PNR NO Ticket_NO Name Age Sex PPNO

1 101 name_1 13 m pp01

2 102 name_2 14 f pp02
3 103 name_3 15 m pp03
4 104 name_4 16 f pp04
5 105 name_5 17 m pp05
6 106 name_6 18 f pp06
7 107 name_7 19 m pp07
8 108 name_8 20 f pp08
9 109 name_9 21 m pp09
10 110 name_10 22 f pp10

TICKET:

INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (101, 13, 'm', 'src1', 'des1', '0830');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (102, 14, 'f', 'src2', 'des2', '1030');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (103, 15, 'm', 'src3', 'des3', '1230');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (104, 16, 'f', 'src4', 'des4', '1430');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (105, 17, 'm', 'src5', 'des5', '1630');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (106, 18, 'f', 'src6', 'des6', '1830');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (107, 19, 'm', 'src7', 'des7', '2030');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (108, 20, 'f', 'src8', 'des8', '2230');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (109, 21, 'm', 'src9', 'des9', '0030');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (110, 22, 'f', 'src10', 'des10', '0230');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (111, 22, 'f', 'src1', 'des1', '0830');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (112, 35, 'f', 'src1', 'des1', '0830');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (113, 19, 'm', 'src2', 'des2', '1030');
Result: 1row affected
INSERT INTO ticket (`Ticket_No`, age, sex, `source`, destination, dep_time) VALUES (114, 40, 'm', 'src2', 'des2', '1030');
Result: 1row affected

Select * from ticket;

Ticket_no Age sex source destination dep-time

101 13 m src1 des1 0830
102 14 f src2 des2 1030
103 15 m src3 des3 1230
104 16 f src4 des4 1430
105 17 m src5 des5 1630
106 18 f src6 des6 1830
107 19 m src7 des7 2030
108 20 f src8 des8 2230
109 21 m src9 des9 0030
110 22 f src10 des10 0230
111 22 f src1 des1 0830
112 35 f src1 des1 0830
113 19 m src2 des2 1030
114 40 m src2 des2 1030

RESERVATION:

INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (1, 1, 'adrs_1', 9891, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (2, 1, 'adrs_2', 9892, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (3, 1, 'adrs_3', 9893, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (4, 1, 'adrs_4', 9894, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (5, 1, 'adrs_5', 9895, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (6, 1, 'adrs_6', 9896, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (7, 3, 'adrs_7', 9897, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (8, 4, 'adrs_8', 9898, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (9, 2, 'adrs_9', 9899, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (10, 5, 'adrs_10', 98910, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (11, 6, 'adrs_11', 98911, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (12, 3, 'adrs_12', 98912, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (13, 7, 'adrs_13', 98913, 's');
Result: 1row affected
INSERT INTO reservation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (14, 10, 'adrs_14', 98914, 's');
Result: 1row affected

Select * from reservation;

PNR NO no of seats address contact status

1 1 adrs_1 9891 S
2 1 adrs_2 9892 S
3 1 adrs_3 9893 s
4 1 adrs_4 9894 S
5 1 adrs_5 9895 S
6 1 adrs_6 9896 S
7 3 adrs_7 9897 S
8 4 adrs_8 9898 S
9 2 adrs_9 9899 S
10 5 adrs_10 98910 S
11 6 adrs_11 98911 S
12 3 adrs_12 98912 S
13 7 adrs_13 98913 S
14 10 adrs_14 98914 S

CANCELLATION:

INSERT INTO cancellation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (2, 1, 'adrs_2',
9892, 's');
Result: 1row affected
INSERT INTO cancellation (`PNR_NO`, `No_of_seats`, `Address`, `Contact_No`, `Status`) VALUES (3, 1, 'adrs_3',
9893, 's');
Result: 1row affected
And we should change the status field in RESERVATION
TABLE, so set status ‘N’ where pnr no from cancellation
table. Or update the reservation table.
(Those are red marked in reservation table.)

Select * from cancellation;

PNR NO no of seats address contact status

2 1 adrs_2 9892 S
3 1 adrs_3 9893 S

UPDATE Table

Update Passenger set age='43' where PNR_NO='2';

Result: 1row affected

DELETE Command:

Delete from Passenger where PNR_NO=’2’;

Result: 1row affected