___________ ___________

D.A.V PUBLIC SCHOOL

SECTOR-VI B.S. CITY(JH)
__________________________

BLOOD BANK MANAGEMENT

SYSTEM(BBMS)
Project guided by Mr. Nagendra Prasad

GROUP MEMBERS: ADARSH KUMAR,

SANSKAR KUMAR
CLASS: XI/A,XI/C
Roll no.: 02,13
Subject: Computer Science

0|Page
Session: 2023-2024

| Certificate

This is to certify that Mr. Adarsh Kumar and Sanskar

Kumar student of Class - XI / A and XI/C DAV
PUBLIC SCHOOL BOKARO SEC-6 has satisfactorily
completed the project on Computer Science on the
topic: Blood Bank Management course in the
academic year.

I have examined the Project and hereby accord my

approval of it's as a study carried out and presented
in the manner required for its acceptance.

We wish a grand success in his life.

Internal Examiner's Signature External Examiner's Signature

1|Page
ABSTRACT
This project aims to develop a Blood Bank Management
System. A Blood Bank Management System can be used in
any clinic, 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. This database
consists of thousands of records of each blood bank. By using

2|Page
this system searching the available blood becomes easy and
saves lot of time than the manual system. It will hoard, operate,
recover and analyse information conc concerned with the
administrative and inventory management within a blood bank.
This system is developed in a manner that it is manageable,
time effective, cost effective, flexible and much man power is
not required.
ER DIAGRAM

3|Page
INFORMATION OF ENTITIES
In total we have eight entities and information of each entity is
mentioned below:-
1. Blood_Donor:
(Attributes – bd_ID, 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_ID) 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_ID, 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_ID)
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 recipient entity

3. BB_Manager:
(Attributes – m_ID, m_Name, m_phNo)

The blood bank manager is the person who takes care of the
available blood samples in the blood bank, he is also

4|Page
responsible for handling blood requests from recipients and
hospitals. Blood manager has a unique identification number
(m_ID) 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_ID, reco_Name, reco_phNo)
The recording staff is a person who registers the blood donor
and recipients and the Recording_Staff enitity has reco_ID
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_ID, 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_ID) as primary key. Along with
name and phone number of the doctor will also be stored under
same entity.

5|Page
7. Hospital_Info :

(Attributes – hosp_ID, hosp_name, hosp_needed_Bgrp,

hosp_needed_Bqnty)

In the data base, under Hospital_Info entity we will store the

information of hospitals. In this hosp_ID 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_ID, city_name)

This entity will store the information of cities where donors,

recipients and hospitals are present. A unique identification
number (City_ID) will be used as primary key to identify the
information about the city. Along with ID city names will also be
stored under this entity.

6|Page
RELATIONSHIP BETWEEN ENTITIES
1. City and Hospital_Info:
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:
Relationship = “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:
Relationship = “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 register with one recording officer.
5. Recording_Staff and Recipient:
Relationship = “records”
Type of relation = 1 to many
Explanation = One recording staff can record many recipients.
One recipient will be recorded by one recording officer.

7|Page
6. Hospital_Info and BB_Manager:
Relationship = “gives order to”
Type of relation = 1 to many
Explanation = One Blood bank manager can handle and process
requests from many hospitals.
One hospital will place request to on blood bank manager.

7. BB_Manager and Blood Specimen:

Relationship = “deales with specimen”
Type of relation = 1 to many
Explanation = One Blood bank manager can manage many blood
specimen and one specimen will be managed by one manager.

8. Recipient and BB_Manager:

Relationship = “requests to”
Type of relation = 1 to many
Explanation = One recipient can request blood to one manager and one manager
can handle requests from many recipients.

9. Disease_finder and Blood Specimen:

Relationship = “checks”,
Type of relation = 1 to many
Explanation = A disease finder can check many blood samples. One
blood sample is checked by one disease finder.

8|Page
RELATIONAL SCHEMAS

Donor Table:
• 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 to many. That’s why primary
key of City is used as a foreign key in Donor.
Recipient Table:
• The relationship with Recording staff and Blood Recipient is 1 to many.
That’s why primary key of Recording staff is used as a foreign key in
Blood Recipient.
• The relationship with City and Blood Recipient 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 is 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.

Blood Specimen Table:

• The relationship with Disease 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.

9|Page
• 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
Disease finder 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 foreign key in Blood Specimen, Recipient and Hospital info.

Hospital info Table: • The relationship with City and Hospital info is 1 to
many. That’s why primary key of City is used as a foreign key in Hospital
info. • The relationship with Blood Bank Manager and Hospital info is 1
to many. That’s why primary key of Blood Bank manager is used as a
foreign key in Hospital info.

10 | P a g e
NORMALIZATION
Normalization Rule
Normalization rules are divided into the following normal forms:
1. First Normal Form
2. Second Normal Form
3. Third Normal Form

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.
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.

11 | P a g e
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.

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

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 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.

12 | P a g e
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).
{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).

13 | P a g e
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 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.
14 | P a g e
TABLES AFTER NORMALIZATION
• BB_Manager:

• Blood_Donor:

15 | P a g e
• BloodSpecimen:

• City:

16 | P a g e
• DiseaseFinder:

• Hospital_Info_1:

17 | P a g e
• Hospital_Info_2:

• Recipient:

18 | P a g e
• Recording_Staff:

19 | P a g e