BLOOD BANK MANAGEMENT SYSTEM

ABSTRACT

This project alms to develop a Blood Bank Management System. A Blood Bank Management
System can be used In any cllnlc, hospital, labs or any emergency situation which requires
blood units for survival. Our system can be used to find required type of blood In emergency
situations from either blood bank or even blood donors.

Current system uses a grapevine communication for finding blood in cases of emergency, may
it be by a donor or blood bank. The intentions of proposing such a system is to abolish the
panic caused during an emergency due to unavailability of blood.

INTRODUCTION

Blood banks collect, store and provide collected blood to the patients who are In need of
blood. The people who donate blood are called 'donors'. The banks then group the blood
which they receive according to the blood groups. They also make sure that the blood is not
contaminated. The main mission of the blood bank Is to provide the blood to the hospitals
and health care systems which saves the patient's life. No hospital can maintain the health
care system without pure and adequate blood.

The major concern each blood bank has is to monitor the quality of the blood and monitor
the people who donates the blood, that Is 'donors'. But this a tough Job. The existing system
will not satisfy the need of maintaining quality blood and keep track of donors. To overcome
all these limitations we Introduced a new system called 'Blood Donation Management
System'.

The 'Blood Bank Management System' allows us to keep track of quality of blood and also
keeps track of available blood when requested by the acceptor. The existing systems are
Manual systems which are time consuming and not so effective. 'Blood Bank Management
system' automates the distribution of blood. Th is database consists of thousands of records
of each blood bank.

By using this system searching the available blood becomes easy and saves lot of time than
the manual system. It w ill hoard, operate, recover and ana lyse information concerned with
the administrative and inventory management with in a blood bank. This system is developed
in a manner that it is manageable, t ime effective, cost effective, flexible and much man power
is not required.
ER DIAGRAM
INFORMATION OF ENTITIES

In t otal we have eight entities and information of each entity is

mentioned below:-

1. Blood_Donor:
(Attributes - bd_JD, bd_name, bd_sex, bd_age, bd_Bgroup,
bd_reg_date, bd_phNo}

The donor is the person who donates blood, on donation a donor id (bd_lD) is
generated and used as primary key to identify the donor information. Other
than that name, age, sex, blood group, phone number and registration dates
will be stored in database under Blood_Donor entity.

2. Recipient:
(Attributes - reci_/0, reci_name, reci_age, reci_Bgrp,
reci_Bqnty, reci_sex, reci_reg_date, reci_phNo}

The Recipient is the person who receives blood from blood bank, when blood
is given to a recipient a recipient ID {reci_lD) is generated and used as primary
key for the recipient entity to identify blood recipients information. Along with
it name ,age, sex, blood group {needed), blood quantity(needed), phone
number, and registration dates are also stored in the data base under recip ient
entity.

3. BB_ Manager:
(Attributes - m_lD, m_Name, m_phNo)

The blood bank manager is the person who takes ca re of the ava ilable blood
samples in the blood bank, he is also responsible for handling blood requests
from recipients and hospitals. Blood manager has a unique identification
number (m_lD) used as primary key along with name and phone number of
blood bank manager will be stored in data base under BB_Manager entity.
 4. Recording_Staff :
(Attributes - reco_/0, reco_Name, reco_phNo}

The recording staff is a person who registers the blood donor and recipients
and the Recording_Staff enitity has reco_lD which is primary key along with
recorder's name and recorder's phone number will also be stored in the data
base under Recording_Staff entity.

5. BloodSpecimen :
(Attributes -specimen_number, b_group, status)

In data base, under Blood Specimen entity we will store the information of
blood samples which are available in the blood bank. In this entity
specimen_number and b_group together will be primary key along with status
attribute which will show if the blood is contaminated on not.

6. Diseasefinder :
(Attributes - dfind_/0, dfind_name, dfind_PhNo}

In data base, under DiseaseFinder entity we will store the information of the
doctor who checks the blood for any kind of contaminations. To store that
information we have unique identification number (dfind_lD) as primary key.
Along with name and phone number of the doctor will also be stored under
same entity.

7. Hospital_lnfo :
(Attributes - hosp_lD, hosp_name, hosp_needed_Bgrp,
hosp_needed_Bqnty)

In the data base, under Hospital_lnfo entity we will store the inform ation of
hospitals. In this hosp_lD and hosp_needed_Bgrp together makes the primary
key. We will store hospital name and the blood quantity required at the
hospital.
 8. City:
(Attributes- city_lD, city_name)

This entity will store the information of cities where donors, recipients and
hospitals are present. A unique identification number (City_lD) will be used as
primary key to identify the information about the city. Along with ID city
names wil l also be stored under this entity.

RELATIONSHIP BETWEEN ENTITIES

1. City and Hospital_lnfo:

Relationship= "in"
Type of relation = 1 to many
Explanation= A city can have many hospital in it. One hospital will
belong in one city.

2. City and Blood_Donor:

Relationshi p= " lives in"
Type of relation= 1 to many
Explanation= In a city, many donor can live. One donor will belong to
one city.

3. City and Recipient:

Re lationshi p= " lives in"
Type of relation = 1 to many
Explanation= In a city, many recipient can live. One recipient will
belong to one city.

4. Recording_Staff and Donor:

Relationship= "registers"
Type of relation = 1 to many
Explanation= One recording staff can register many donors. One
donor will rregister with one recording officer.
5. Recording_Staff and Recipient:
Re lationship = "records"
Type of relatio n = 1 to many
Explanation= One recording st aff can reco rd many recipients. One
recipient will be recorded by one reco rding officer.

6. Hospital_Info and BB_Manager:

Relation ship= "gives order t o"
Type of relation = 1 to many
Explanation= One Blood bank manager can handle and process
requests from many hospitals. One hospit al w ill place request to on
blood bank manager.

7. BB_Manager and Blood Specimen:

Relationsh ip= "deales w ith specimen"
Type of relation = 1 to many
Explanation= On e Blood bank manager can manage ma ny blood
specimen and one specimen wi ll be managed by one manager.

8. Recipient and BB_Manager:

Relationship = " requests to"
Type of relatio n = 1 to many
Explanation= One recipient can req uest blood to one manager and
one manager can handle requests from many recipient s.

9. Disease_finder and Blood Specimen:

Relationsh ip= "checks",
Type of relation= 1 to many
Explanation= A disease f inder ca n check many blood samples. One
blood sample is checked by one disease finder.
RELATIONAL SCHEMAS

Donor Tabl e:
• The relationship with Recording staff and Donor is 1 to many. That's
why primary key of Recording staff is used as a foreign key In Donor.
• The relationship with City and Donor is 1 t o many. That's why
primary key of City Is used as a foreign key In Donor.

Recipient Tabl e:
• The relationsh ip with Recording staff and Blood Recipient is 1 to
many. That's why primary key of Recording staff is used as a for,eign
key in Blood Recipient.
• The relat ionship with City and Blood Recip ient is 1 to many. That's
why primary key of City is used as a foreign key in Blood Recipient.
• The relationship with Blood Bank Manager and Blood Recipient is 1
to many. That's why primary key of Blood Specimen is used as a
foreign key in Blood Recipient.

City Table:
• The relationship between City and Recipients, Donor, Hospital Info
are all of 1 to many. So that's why primary key of City ls used as a
foreign key in Recipients, Donor and Hospital info.

Recording Staff Table:

• The relationship between Recording Staff and Blood Donor,
Recipients are all of 1 to many. That's why the primary key of
Recording staff is used as a foreign key in Donor and Recipient.

Bl ood Specimen Table:

• The relationship with Di sease finder and Blood Specimen is 1 to
many. That's why primary key of Disease finder Is used as a foreign key
in Blood Specimen.
• The relationship with Blood Bank manager and Blood Specimen is 1
to many. That's why primary
key of Blood Bank manager is used as a foreign key in Blood Specimen

Disease Finder Table:

• The relationship with Disease finder and Blood Specimen is of 1 to
many. Therefore, the primary key of Di sease find er is used as a foreign
key In Blood Specimen.

Blood Bank Manager Table:

• The relationship between Blood Bank Manager and Blood Specimen,
Recipient, Hospital info are all of 1 to many. So therefore, the primary
key of Blood Bank Manager is used as a f oreign key in Blood Specimen,
Recipient and Hospital info.

Hospital info Table:

• The relationship with City and Hospital info is 1 to ma ny. That's why
primary key of City is used as a fore ign key in Hospital info.
• The relationship with Blood Bank Manager an d Hospit al info is 1 to
many. That's why primary key of Blood Bank manager is used as a
foreign key in Hospital info.
 Hospital Info
l·l#ii#ihHMM l·ll!Hld!■ Hosp_rd (111<1
SpeCimen_No (PK) Dflnd_td (PKI
BJtl)(Pl<) Hosp_Name
Olttts • Dflnd_name
Status Hosp_nttded_Bcrp (Pl()
Dfind_PhNo
M_ld (FKI GivH Order\ to Hosp_needed_qnty

J
Oty_id (FKI
Oflrid_ld (F K)
mmmall
uwlz:~h
M_ld (FK)
Rec;1_1d {PIC)
Ll-csln Hosp_PhNo
Recl_name • Clty_ld (PK)
Recl_age In
M_ld (PK) Clty_Name
~ ~ to Recl_sei 1!%111111

l
M_Name
Recl_bgrp Bd_ld(Pll:I
M_PhNo
Re(;I_Bqnty Bd_Name
LhlH In
Recl_reg_date Bd_ase
Realrds Reco_ld (FKI Bd_sex
lil~!·ll·IBi!II Oty_ld (FKI Bd_bQrp
Reco_ld (PK)
M_ld(FK) Bd_rl'gdalP
Reco_Name ~,tsters w,u, Reco_,d (f l()
Reco_PhNo
Clty_ld (FK)

NORMALIZATION

Normalization Rule
Normalization rules are divided into the fo llowing normal forms:
1. First Normal Form
2. Second Normal Form
3. Third Normal Form

First Normal Form (lNF)

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 co lumns in a table should have unique names.
4. And the order in which data is stored, does not matter.

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.
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 Tran sitive Depend ency.

Normalization of Blood Bank Database:

1. Blood_Donor (bd_!d, bd_name, bd_phNo bd_sex, bd_age,

bd_reg_date, bd_Bgroup, reco_/0, City_lD}

{b d_ld} = > {bd_name} (functional dependency exists, because two

different bd_name do not correspond to th e same bd_ld).
{bd_lD} = > {bd_sex} (functional dependency exists).
{bd_lD} = > {bd_age} {functional dependency exists).
{bd_lD} = > {bd_reg_date} date {functional dependency exists).
{bd_lD} = > {reco_id} (functiona l dependency exists).
{bd_lD} = > {city_id} (functional dependency exists).
{bd_l D} = > {bd_Bgroup} (functional dependency exists).

As 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 tab le and it is
already in f irst 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 tab le is in second normal form.
The table is in third normal form.
3. Recording_staff (reco_name, reco_lD, 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_ld, reci_sex, reci_phNo, reci_age, reci_date,

reci_name, reci_Bqnty, reci_Bgrp, reco_id, city_id, m_id)

{reci_ld} = > {reci_sex} (fu nctional dependency exists).

{reci_ld} = > {reci_age} (functional dependency exists).
{reci_ld} = > {recl_date} (functional dependency exists).
{reci_ld} = > {reci_name} (functional dependency exists).
{reci_ld} = > {reci_bqnty} (functional dependency exists).
{reci_ld} = > {reci_Bgrp} (functional dependency exists).
{reci_ld} = > {reco_id} (functional dependency exists).
{reci_ld} = > {city_id} (functional dependency exists).
{reci_ld} = > {m_id} (functiona l dependency exists).

Th e table is in first normal form.

Th e table is in second normal form.
Th e table is in third normal form.

5. Blood Specimen ( b_group, specimen_no, status, dfind_id, m_ld)

{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).
Th e table is in fi rst normal form.
The table is in second normal form.
The table is in th ird normal form.

6. Disease_finder ( dfind_id, dfind_name, dfind_PhNo}

{ dfind_id} = > { dfind_name}

{ dfind_id} = > { dfind_PhNo } (functional dependency exists).

The tabl e 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}

Th e table is in first normal fo rm .

The t able is in second normal form.
The table is in thi rd normal form.

8. Hospit al_ lnfo ( hosp_ld, hosp_Name, hosp_phNo,

hosp_needed_Bgrp, hosp_needed_ qty, clty_id, m_id)

{hosp_ld}= > {hosp_Name, hosp_phNo, city_id, m_id}

{hosp_ld, hosp_needed_Bgrp} = > hosp_needed_qty (functional
dependency exists}

The table is in first normal form .

.Since every non-primary key attribute is not fu lly functionally
dependent on the primary key of t he table, th is table is not in second
normal form. Hence we have t o split t he table.

1Hospital_l (hosp_ld, hosp_phN o, hosp_Name, city_id, m_id}.

 SAMPLE SQL QUERIES

1. Create a View of recipients and donors names having

the same blood group registered on the same date and
the name of recording staff name.

- Sample Query - 1 -
CREATE VIEW Blood_Recipient_SameBGrp AS
select Blood_Donor. bd_name,Recipient. reci_name, reco_ Name from
Record ing_Staff
inner join Blood_Donor on Recording_Staff.reco_lD =
Blood- Donor.reco- ID
inner join Recipient on Recording_Staff.reco_lD = Recipient.reco_lD
where Blood_Donor.bd_Bgroup = Recipient. reci_Brgp and
Blood_Donor.bd_reg_date = Recipient.reci_reg_date;
select* from Blood_ Recipient_ SameBGrp;

Output:

bd_name reci_name reco_Name

shweta Peter Walcot

I

2. Show the blood specimen verified by disease finder

shivam which are pure (status=1 ).

-- Sample Query - 2 --
Select specimen_number,b_group from BloodSpecimen, DiseaseFinder
WH ERE BloodSpecimen.dfind_lD= DiseaseFinder.dfind_lD AND
dfind_name='shivam' AND status=1;
Output:

specimen_number b_gr oup

-
1012 o-

1013 B-

3. Show the pure blood specimen handled by BB_Manager

who also handles a recipient needing the same blood
group along with the details of the BB_Manager and
Recipient.

-- Sample Query - 3 --
se,lect BB_ Manager.M_ id,mName,Recipient.reci_name,
Recipient.reci_ Brgp,BloodSpecimen.b _group from
BB_ Manager,Recipient ,BloodSpecimen
where Recipient.M_id = BloodSpecimen.M_id and Recipient.reci_Brgp =
BloodSpecimen.b_group and Recipient.M_id = BB_Manager.M_id
and status = 1;

Output:

M_id mName rec1_nam e reci_Brgp b_group

-
101 shlvank Peter B+ B+

102 shwetanshu akh1I AB+ AB+

4. Show the donors having the same blood groups requir ed

by the recipient staying in the same city along with
. t__det_a,·1s.
rec ip1en

-- Sample Query - 4 --
Select bd_l D,bd_name,reci_lD ,reci_name FROM
Blood_ Donor, Recipient
WH ERE bd_Bgroup=reci_ Brgp AND Blood_Donor.City_lD=
Recipient.City_lD;

Output:

bd_ ID bd- name rec1- ID

. .
-
rec1 name I

150013 Shlvank 10003 akhll

"
150013
I Sh1vank 10010 Marsh I!

150014 shweta ' 10004 Parker

I
150014 shweta 10008 Swathl
I
150017 Mtke 10005 Jojo

5. Display the information of Hospital_lnfo_ 1 handled by

BB_Manager whose ID is 103:
- Sample Query - 5--
Select hosp_lD,hosp_name, City_lD, HOspital_lnfo_ 1.M_id from
Hospital_lnfo_1,BB_Manager
where BB_Manager.M_id=Hospital_lnfo_ 1.M_id and
BB_Manager.M_id=103;

Output:

11

hosp_ID hosp_name City_ID M id-

·-
2 CleavelandChnlc 1200 103
I

3 NYU 1300 103

II 5 Charlton 1800 103

.