DBMS PBL 60
DBMS PBL 60
DBMS PBL 60
A PROJECT REPORT
Submitted in partial fulfillment of the requirements for the award of the degree of
Bachelor of Technology
In
INFORMATION TECHNOLOGY
Submitted by
KONDETI VINAY
20331A1260
Officer have officer name ,id,rank.and officer manages the soldier and
armory.
Design er model for given cse and convert into r and normalize it.
ER –Diagram:
Schemas:
Soldier(ssn id int,address char,name char,age int,experience int)
Barracks(barracks id int,capacity int,area char,name char,location id int)
Armory(Serial no int,idno int,no_of_times_used int, weight float,license
no int)
Officer(officer name char,office id int,rank int)
Relational Schemas:
Livesin(ssnid int,barracksid int,no of days lives int)
Armony_mangement(officerid int,armory id int)
Armory maintainance(armory_idno int,enginner_id
int,dateofmaintainance date);
assign_armory(ssnid int,officer_id int,dateofassignment date)
1.Table creation:
Database creation:
use military;
Describe Soldier:
desc soldier;
Output:
Output:
Table Creation for Barracks :
desc barracks;
Output:
Output:
desc officer;
Output:
Output:
desc armory;
Output:
Output:
char(200));
desc engineer;
Output:
Output:
Creation of assign_armory table:
Output:
Output:
Creation of armory_maintainance table:
references engineer(enginner_id));
Output:
Output:
Creation of armory_management table:
Output:
Queries:
Query:
Output:
Query:
Output:
Query:
output:
4.Identify the soldier with maximum experience?
Query:
soldier s2;
output:
5.find the officer id who manages the barracks whose barracks_id is 102
Query:
Output:
Query:
Output:
l.barracks_id=101;
Output:
Output:
Output:
Output:
Normalization:
1NF:
2NF:
Ssnid →name
Ssnid →height
Ssnid→age
Ssnid→experience
Ssnid→address
ssnid address
1201 Vzg
1202 Chattisghar
And every non key attributes are partially dependent on key attribute(ssnid)
There it is 2 NF
3NF:
From the above table we don’t have any transitive dependency exists
Therefore it is 3Nf .
For officer table:
301 navven 3
302 vinay 1
303 sunny 4
1NF:
2NF:
Officer_id→Officername
Officer_id→rankno
Officer_id→(officername,rankno)
Closures are:
(Officerid)+ →(officer_id,officername,rankno)
The candiates keys are { officerid}, The set of key attributes are: { officerid}
Therefore key attributes is determines every non key attribute so there is no partial
dependency
So it is in 2NF.
3NF:
It is 3nf because the table is in 2nf and there no Transitive dependency .Therefore
it is in 3NF
For Armory table:
used
1000 14321 5 7
34.45
1001 13451 6 10
54.45
1002 14532 6 4
46.43
For the above table there is all atomic values so table is in 1NF
2NF:
Armory_id→(license_no)
Armory_id→(Weight)
License_no→(Serial_no)
The candidates keys are { Armory id}, The set of key attributes are: { Armoryid}
Therefore key attributes is determines every non key attribute so there is no partial
dependency
So it is in 2NF.
3NF:
Initially rel[1] is the original table with the original functional dependencies.
In each round we check the FDs one by one to see if there is a violation of 3NF
14321 5 7
13451 6 10
14532 6 4
id --> lno,weight
Therefore it is 3NF.
For Barracks table:
From the above table there is all are in atomic values so there is 1NF
2NF:
Barracks_id→bname
Barracks_id→capacity
Location_id→barracks_id
Location_id→area
bname→capacity
(location_id)+={bid,capacity,area,bname}
The candidates keys are { Armory id}, The set of key attributes are: { Armoryid}
Therefore key attributes is determines every non key attribute so there is no partial
dependency.So it is in 2NF.
3NF:
Initially rel[1] is the original table with the original functional dependencies.
In each round we check the FDs one by one to see if there is a violation of 3NF
there all the tables are in 3NF so there is no Transitive dependencies so it is in 3NF
Conclusion:
Our project is only a humble venture to satisfy the needs to manage their project
Work .several user friendly coding have also been adopted.with this project we
can or the any military management can know the details about the order