0% found this document useful (0 votes)
621 views27 pages

DBMS Project Report - BLOOD BANK MANAGEMENT

The document describes the normalization of tables in a blood bank database management system into third normal form. It contains three tables - Blood_Donor, City, and Recording_staff. The Blood_Donor table, which contains donor information, is already in third normal form as the primary key uniquely identifies each attribute. The City and Recording_staff tables only contain the primary key and one other attribute each, so they are also in third normal form.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
621 views27 pages

DBMS Project Report - BLOOD BANK MANAGEMENT

The document describes the normalization of tables in a blood bank database management system into third normal form. It contains three tables - Blood_Donor, City, and Recording_staff. The Blood_Donor table, which contains donor information, is already in third normal form as the primary key uniquely identifies each attribute. The City and Recording_staff tables only contain the primary key and one other attribute each, so they are also in third normal form.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 27

“BLOOD BANK MANAGEMENT SYSTEM”

Submitted as Mini Project Report

for

CB19442– Database Technology

Submitted by

Avantika K(211401012)

DEPARTMENT OF COMPUTER SCIENCE & BUSINESS


SYSTEMS
Rajalakshmi Engineering College,

Thandalam, Chennai
Nov-Dec 2022

1|Page
BONAFIDE CERTIFICATE

Certified that this project report titled “BLOOD BANK MANAGEMENT

SYSTEM“ the bonafide work of "AVANTIKA K" who carried out the project

work under my supervision.

SIGNATURE SIGNATURE
Dr.K.Devaki Ms.K.Poornimathi
HEAD OF THE DEPARTMENT SUPERVISOR
Computer Science and Business Systems
Rajalakshmi Engineering College, Rajalakshmi Engineering College,
Rajalakshmi Nagar, Thandalam, Rajalakshmi Nagar, Thandalam,
Chennai- 602 105 Chennai - 602 105.

2|Page
ACKNOWLEDGEMENT

I thank the Almighty God for the successful completion of the project. Sincere

thanks to our Chairman Mr. S.MEGANATHAN B.E, F.I.E., for his sincere

endeavour in educating us in his premier institution.

I would like to express our deep gratitude to our beloved chairperson Dr.

(Mrs.)THANGAM MEGANATHAN, Ph.D., for her enthusiastic motivation which

inspired us a lot in completing our project.

I also express our gratitude to our principal Dr.S.N.MURUGESAN,Ph.D., who

helped us in providing the required facilities for completing the project.

I would like to thank our Head of the Department of Computer Science and

Business Systems Dr.K.Devaki,Ph.D., for her invaluable guidance and

encouragement for completing the project.

I are also thankful to Ms.K.Poornimathi,M.Tech., Department of Computer

Science and Business Systems for her invaluable guidance, ideas, and encouragement

for the successful completion of this project.

3|Page
CONTENTS

Chapter Title Page No


No.
1. INTRODUCTION
1.1 Overview
2. ER Diagram
2.1 Relationship Assumptions for ER Diagram
2.2 Relationships according to the requirements
2.2.1 One-to-One Binary Relationships
2.2.2 One-to-Many Binary Relationships
2.2.3 Many-to-Many Binary Relationships
3. Relational Schema
4. Normalization of Schema
5. Queries
6.1 Create Table & Insert Queries
6.2 SQL Queries
6. CONCLUSION

4|Page
CHAPTER 1

INTRODUCTION

1.1. Introduction
Blood Bank Management System is a browser-based solution that is designed to store,
process, retrieve and analyze information concerned with the administrative, inventory
management and clinical aspects of providing services within a blood bank.
Donor Registration: The application allows the users to store the donor details in the
application itself. As soon as a donor is registered, a unique identification number is
assigned to him/her automatically which remains same throughout the life time of donor.
Any subsequent donations made by the same donor automatically got linked up with the
same identification number.
Donor physical and medical details: System allows the user to store physical and
medical details of the donor at the time of the registration which could later on be edited
during the time of subsequent donations. Application also allows the users to check the
eligibility criteria of the donors for making donations, depending on which a track of the
deferred donors can be kept for the future referrals.
TTI screening and Inventory management: The Application provides its users to
organize and manage the inventory (Blood bags, blood component etc.) for their blood
bank. User can store the records for blood bags present in the bank, the blood
components created and imported in the bank. Every single unit/component will be
assigned with a unique ID for which Bar code can be generated and can be pasted on the
bags itself for later on identification. The end user is able to store the blood in quarantine
till the time it has passed the TTI screening as per specified standards issued by NACO.
After which the blood which has passed the tests will be moved to inventory with their

5|Page
unique identification numbers and the rejected blood will be processed to the discard
samples for which the reports can be generated any time later on.
Blood requisition and Cross matching: The Application allows the user to request for
blood and blood transfusion for which the cross matching using the appropriate
technique can be carried out and the results can further be processed and analyzed by the
experts to issue the blood. Also, various reports for blood requisition and the cross
matching can be generated at run time.
Secured environment and login facility: System provides the users a secured
environment to work inside the application by accepting the log in ID’s and passwords
from the users.
Report generation: Various comprehensive reports can be generated any time by the
end user to measure the performance parameters in the blood bank and also to analyses
the inventory and other aspects in blood bank.

6|Page
CHAPTER 2

ER DIAGRAM

2.1 Relationship Assumptions for ER Diagram

7|Page
2.2 Relationships according to the requirements:

2.2.1 One-to-One Binary Relationships

(a)one donor can donate only one blood group


(b)one donor can have only one id
2.2.2 One-to-Many Binary Relationships
(a) One donor can give blood to many receivers
(b) one blood group can be present in many donors
2.2.3 Many-to-Many Binary Relationships
(a) Many blood groups can be collected from many
donors
(b)Many Blood inventory can conduct many Blood
camps

8|Page
CHAPTER 3

RELATIONAL SCHEMA

9|Page
CHAPTER 4

NORMALIZATION OF SCHEMA

Normalization of Blood Bank Database:

1. Blood_Donor (bd_Id,
bd_name, bd_phNo
bd_sex, bd_age,
bd_reg_date, bd_Bgroup,
reco_ID, City_ID)
{bd_Id} = > {bd_name}
(functional dependency
exists, because two

10 | P a g e
different bd_name do not
correspond to the same
bd_Id).
{bd_ID} = > {bd_sex}
(functional dependency
exists).
{bd_ID} = > {bd_age}
(functional dependency
exists).
{bd_ID} = >
{bd_reg_date} date
11 | P a g e
(functional dependency
exists).
{bd_ID} = > {reco_id}
(functional dependency
exists).
{bd_ID} = > {city_id}
(functional dependency
exists).
{bd_ID} = >
{bd_Bgroup} (functional
dependency exists).
12 | P a g e
1. Blood_Donor (bd_Id,
bd_name, bd_phNo
bd_sex, bd_age,
bd_reg_date, bd_Bgroup,
reco_ID, City_ID)
{bd_Id} = > {bd_name}
(functional dependency
exists, because two
different bd_name do not
correspond to the same
bd_Id).
13 | P a g e
{bd_ID} = > {bd_sex}
(functional dependency
exists).
{bd_ID} = > {bd_age}
(functional dependency
exists).
{bd_ID} = >
{bd_reg_date} date
(functional dependency
exists).

14 | P a g e
{bd_ID} = > {reco_id}
(functional dependency
exists).
{bd_ID} = > {city_id}
(functional dependency
exists).
{bd_ID} = >
{bd_Bgroup} (functional
dependency exists).
1. Blood_Donor (bd_Id, bd_name, bd_phNo bd_sex, bd_age, bd_reg_date, bd_Bgroup,
reco_ID, City_ID) {bd_Id} = > {bd_name} (functional dependency exists, because
two different bd_name do not correspond to the same bd_Id). {bd_ID} = > {bd_sex}
(functional dependency exists). {bd_ID} = > {bd_age} (functional dependency
exists). {bd_ID} = > {bd_reg_date} date (functional dependency exists). {bd_ID} = >
{reco_id} (functional dependency exists). {bd_ID} = > {city_id} (functional
dependency exists). {bd_ID} = > {bd_Bgroup} (functional dependency exists). As
15 | P a g e
the attributes of this table does not have sub attributes, it is in first normal form.
Because every non-primary key attribute is fully functionally dependent on the
primary key of the table and it is already in first normal form, this table is now in
second normal form. Since the table is in second normal form and no non-primary
key attribute is transitively dependent on the primary key, the table is now in 3NF. 2.
City (city_id , city_name) {city_id}= > {city_name} The table is in first normal form.
The table is in second normal form. The table is in third normal form.

2. City (city_id , city_name) {city_id}= > {city_name}


The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
3. Recording_staff (reco_name, reco_ID, reco_phNo)
{reco_id} = > {reco_name} (functional dependency exists).
{reco_id} = > {reco_phNo} (functional dependency exists).
The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
4. Blood_recipient (reci_Id, reci_sex, reci_phNo, reci_age, reci_date, reci_name,
reci_Bqnty, reci_Bgrp, reco_id, city_id, m_id)
{reci_Id} = > {reci_sex} (functional dependency exists).
{reci_Id} = > {reci_age} (functional dependency exists).
{reci_Id} = > {reci_date} (functional dependency exists).
{reci_Id} = > {reci_name} (functional dependency exists).
{reci_Id} = > {reci_bqnty} (functional dependency exists).
{reci_Id} = > {reci_Bgrp} (functional dependency exists).
{reci_Id} = > {reco_id} (functional dependency exists).
{reci_Id} = > {city_id} (functional dependency exists).
16 | P a g e
{reci_Id} = > {m_id} (functional dependency exists).
The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
5. Blood Specimen ( b_group, specimen_no, status, dfind_id, m_id )
{b_group, specimen _no} = > {status} (functional dependency exists).
{b_group, specimen _no} = > {dfind _id} (functional dependency exists).
{b_group, specimen _no} = > {m_id} (functional dependency exists).
The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
6. Disease_finder ( dfind_id, dfind_name, dfind_PhNo)
{ dfind_id } = > { dfind_name }
{ dfind_id } = > { dfind_PhNo } (functional dependency exists).
The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
7. BB_manager ( M_id, m_name, m_phNo)
{M_id} = >{m_name}
{M_id} = > {m_phNo} (functional dependency exists)
The table is in first normal form.
The table is in second normal form.
The table is in third normal form.
8. Hospital_Info ( hosp_Id, hosp_Name, hosp_phNo, hosp_needed_Bgrp,
hosp_needed_qty, city_id, m_id) {hosp_Id}= > {hosp_Name, hosp_phNo, city_id,
m_id}
{hosp_Id, hosp_needed_Bgrp } = > hosp_needed_qty (functional dependency exists)
The table is in first normal form. Since every non-primary key attribute is not fully
17 | P a g e
functionally dependent on the primary key of the table, this table is not in second
normal form. Hence we have to split the table. Hospital_1 (hosp_Id, hosp_phNo,
hosp_Name, city_id, m_id).
Hospital_2 (hosp_Id, hosp_needed_Bgrp, hosp_needed_qty) Now it is in second
normal form. The table is in third normal form.

CHAPTER 5

QUERIES

SQL IMPLEMENTATION
CREATE TABLE BB_Manager
( M_id int NOT NULL PRIMARY KEY,
mName varchar(100) NOT NULL,
m_phNo bigint
);
INSERT into BB_Manager
VALUES(101,'shivank', 9693959671),
(102,'shwetanshu', 9693959672),
18 | P a g e
(103,'singh', 9693959673),
(104,'yusuf', 9693959674),
(105,'jackson', 9693959675);
INSERT into BB_Manager
VALUES(106,'akhil', 9693959676),
(107,'jojo', 9693959677),
(108,'stella', 9693959678),
(109,'monika', 9693959679),
(110,'himanshi', 9693959680);
select * from BB_Manager;
CREATE TABLE Blood_Donor
( bd_ID int NOT NULL PRIMARY KEY,
bd_name varchar(100) NOT NULL,
bd_age varchar(100),
bd_sex varchar(100),
bd_Bgroup varchar(10),
bd_reg_date date,
reco_ID int NOT NULL,
City_ID int NOT NULL,
FOREIGN KEY(reco_ID) REFERENCES Recording_Staff(reco_ID),
FOREIGN KEY(City_ID) REFERENCES City(City_ID)
);
INSERT into Blood_Donor
VALUES(150011,'Mark',25,'M','O+','2015-07-19',101412,1100),
(150012,'Abdul',35,'M','A-','2015-12-24',101412,1100),
(150013,'Shivank',22,'M','AB+','2015-08-28',101212,1200),
(150014,'shweta',29,'M','B+','2015-12-17',101212,1300),
(150015,'Shyam',42,'M','A+','2016-11-22',101212,1300),
19 | P a g e
(150016,'Dan',44,'F','AB-','2016-02-06',101212,1200),
(150017,'Mike',33,'M','B-','2016-10-15',101312,1400),
(150018,'Elisa',31,'F','O+','2016-01-04',101312,1200),
(150019,'Carrol',24,'F','AB+','2016-09-10',101312,1500),
(150020,'shivansh',29,'M','O-','2016-12-17',101212,1200);
select * from Blood_Donor;
CREATE TABLE BloodSpecimen
( specimen_number int NOT NULL,
b_group varchar(10) NOT NULL,
status int,
dfind_ID int NOT NULL,
M_id int NOT NULL,
primary key (specimen_number,b_group),
FOREIGN KEY(M_id) REFERENCES Manager(M_id),
FOREIGN KEY(dfind_ID) REFERENCES DiseaseFinder(dfind_ID)
);
INSERT into BloodSpecimen
VALUES(1001, 'B+', 1,11,101),
(1002, 'O+', 1,12,102),
(1003, 'AB+', 1,11,102),
(1004, 'O-', 1,13,103),
(1005, 'A+', 0,14,101),
(1006, 'A-', 1,13,104),
(1007, 'AB-', 1,15,104),
(1008, 'AB-', 0,11,105),
(1009, 'B+', 1,13,105),
(1010, 'O+', 0,12,105),
(1011, 'O+', 1,13,103),
20 | P a g e
(1012, 'O-', 1,14,102),
(1013, 'B-', 1,14,102),
(1014, 'AB+', 0,15,101);
Select * from BloodSpecimen;
CREATE TABLE City
( City_ID int NOT NULL PRIMARY KEY,
City_name varchar(100) NOT NULL
);
INSERT into City
VALUES(1100,'Dallas'),
(1200,'Austin'),
(1300,'Irving'),
(1400,'Houston'),
(1500,'Richardson');
INSERT into City
VALUES(1600,'Plano'),
(1700,'Frisco'),
(1800,'Arlington'),
(1900,'San Antonio'),
(2000,'Tyler');
select * from City;
CREATE TABLE DiseaseFinder
( dfind_ID int NOT NULL PRIMARY KEY,
dfind_name varchar(100) NOT NULL,
dfind_PhNo bigint
);
INSERT into DiseaseFinder
VALUES(11,'Peter',9693959681),
21 | P a g e
(12,'Park',9693959682),
(13,'Jerry',9693959683),
(14,'shivam',9693959672),
(15,'Monika',9693959679);
INSERT into DiseaseFinder
VALUES(16,'Ram',9693959684),
(17,'Swathi',9693959685),
(18,'Gautham',9693959686),
(19,'Ashwin',9693959687),
(20,'Yash',9693959688);
select * from DiseaseFinder;
CREATE TABLE Hospital_Info_1
( hosp_ID int NOT NULL,
hosp_name varchar(100) NOT NULL,
City_ID int NOT NULL,
M_id int NOT NULL,
primary key(hosp_ID),
FOREIGN KEY(M_id) REFERENCES Manager(M_id),
FOREIGN KEY(City_ID) REFERENCES City(City_ID)
);
INSERT into Hospital_Info_1
VALUES(1,'MayoClinic',1100,101),
(2,'CleavelandClinic',1200,103),
(3,'NYU',1300,103);
INSERT into Hospital_Info_1
VALUES(4,'Baylor',1400,104),
(5,'Charlton',1800,103),
(6,'Greenoaks',1300,106),
22 | P a g e
(7,'Forestpark',1300,102),
(8,'Parkland',1200,106),
(9,'Pinecreek',1500,109),
(10,'WalnutHill',1700,105);
select * from Hospital_Info_1;
CREATE TABLE Hospital_Info_2
( hosp_ID int NOT NULL,
hosp_name varchar(100) NOT NULL,
hosp_needed_Bgrp varchar(10),
hosp_needed_qnty int,
primary key(hosp_ID,hosp_needed_Bgrp)
);
INSERT into Hospital_Info_2
VALUES(1,'MayoClinic','A+',20),
(1,'MayoClinic','A-',0),
(1,'MayoClinic','AB+',40),
(1,'MayoClinic','AB-',10),
(1,'MayoClinic','B-',20);
INSERT into Hospital_Info_2
VALUES(2,'CleavelandClinic','A+',40),
(2,'CleavelandClinic','AB+',20),
(2,'CleavelandClinic','A-',10),
(2,'CleavelandClinic','B-',30),
(2,'CleavelandClinic','B+',0),
(2,'CleavelandClinic','AB-',10);
INSERT into Hospital_Info_2
VALUES(3,'NYU','A+',0),
(3,'NYU','AB+',0),
23 | P a g e
(3,'NYU','A-',0),
(3,'NYU','B-',20),
(3,'NYU','B+',10),
(3,'NYU','AB-',0);
INSERT into Hospital_Info_2
VALUES(4,'Baylor','A+',10),
(4,'Baylor','A-',40),
(7,'Forestpark','B-',40),
(8,'Parkland','B+',10),
(9,'Pinecreek','AB-',20);
select * from Hospital_Info_2;
CREATE TABLE Recipient
( reci_ID int NOT NULL PRIMARY kEY,
reci_name varchar(100) NOT NULL,
reci_age varchar(10),
reci_Brgp varchar(100),
reci_Bqnty float,
reco_ID int NOT NULL,
City_ID int NOT NULL,
M_id int NOT NULL,
FOREIGN KEY(M_id) REFERENCES Manager(M_id),
FOREIGN KEY(City_ID) REFERENCES City(City_ID)
);
Alter table Recipient
ADD reci_sex varchar(100);

Alter table Recipient


ADD reci_reg_date date;
24 | P a g e
INSERT into Recipient
VALUES(10001,'Peter',25,'B+',1.5,101212,1100,101,'M','2015-12-17'),
(10002,'shivank',60,'A+',1,101312,1100,102,'M','2015-12-16'),
(10003,'akhil',35,'AB+',0.5,101312,1200,102,'M','2015-10-17'),
(10004,'Parker',66,'B+',1,101212,1300,104,'M','2016-11-17'),
(10005,'jojo',53,'B-',1,101412,1400,105,'M','2015-04-17'),
(10006,'Preetham',45,'O+',1.5,101512,1500,105,'M','2015-12-17'),
(10007,'Swetha',22,'AB-',1,101212,1500,101,'F','2015-05-17');
INSERT into Recipient
VALUES(10008,'Swathi',25,'B+',2,101412,1300,103,'F','2015-12-14'),
(10009,'Lance',30,'A+',1.5,101312,1100,104,'M','2015-02-16'),
(10010,'Marsh',25,'AB+',3.5,101212,1200,107,'M','2016-10-17');
select * from Recipient;
CREATE TABLE Recording_Staff
( reco_ID int NOT NULL PRIMARY KEY,
reco_Name varchar(100) NOT NULL,
reco_phNo bigint
);
INSERT into Recording_Staff
VALUES(101012,'Lekha',4044846553),
(101112,'shivam',4045856553),
(101212,'Walcot',4045806553),
(101312,'jackson',4045806553),
(101412,'Silva',4045806553),
(101512,'Adrian',4045806553),
(101612,'shivam',4045806553);
INSERT into Recording_Staff
VALUES(101712,'shyam',4045816553),
25 | P a g e
(101812,'Jerry',4045826553),
(101912,'Tim',4045836553);
select * from Recording_Staff;

CHAPTER 6

CONCLUSION
Prior to this project, a general study of blood bank management system was
conducted from recent researches of various authors and facts were gathered
in which helped to uncover the misfits that the system was facing.
After proper analyzation of these problems, a solution was then developed in
order to meet up the needs of a more advanced system. This system is known
as the centralized blood bank repository which helped in eliminating all the
problems that the previous systems were facing. With this system, Blood banks/
Centers, Hospitals, Patients and Blood donors will be brought together to enjoy
a large number of functionalities and access a vast amount of information,

26 | P a g e
thereby making blood donation and reception a lot easier and faster.
Before implementing the database, in the design phase, we have explored
various features, operations of a blood bank to figure out required entities,
attributes and the relationship among entities to make an efficient Entity
Relationship Diagram (ERD). After analyzing all the requirements, I have created
our ERD and then converted the ERD to relational model and normalized the
tables.
Using SQL Server, I have created the tables for my database and inserted some
sample values in the tables. Finally, I have executed sample queries on the
database to check its performance to retrieve useful information accurately and
speedily.

27 | P a g e

You might also like