JSS SCIENCE AND TECHNOLOGY UNIVERSITY

(Formerly Sri Jayachamarajendra College of Engineering)

JSS TI Campus, Manasagangothri, Mysore – 570006.

Project Report on “Blood Bank Management System”

Submitted To :
Dr. Trisiladevi C. Nagavi,
Professor, Dept. Of Computer Science,
JSS Science and Technology University,
Mysore – 570006.

Submitted By :
❏ Mehdi Sadath Assadi : USN – 01JST18IS024
❏ Sarungbam Dinaraj : USN – 01JST17CS141
❏ Guruprakash : USN – 01JST18IS014
 Contents :

1. Acknowledgement…………………………………………….…...….…2
2. Abstract……………………………………………………………....…...3
3. Problem definition……………………………………………..…...…....4
4. Aim……………………………………………………………..…...…….4
5. Objective and Scope ……………………………………………..…….5
6. System Requirement Engineering…………………….……..……...6-9
6.1 Functional Requirements…………………….………..………….6
6.2 Non-functional Requirements……………………………...…..6-7
6.3 Security Requirements…………………………………….…..….7
6.4 System Requirements…………………………………….…...….8
6.4.1 Security Requirements…………………………….....….8
6.4.2 Hardware Requirements……………………….…….…..8
7. System Design and Implementation…………………………...…..9-18
7.1 Architectural Design…………………………………...…...….9-10
7.2 Data Flow Diagram……………………………………..…….10-11
7.3 E-R Diagram……………………………………………..……….12
7.4 Schema Diagram……………………………………..………….13
7.5 Tables and Attributes…………………………………..…….14-17
7.6 Database Normalization…………………………………..……...17-18
8. Modules of Blood Bank Management System………….……....19-20
9. Unit testing and Result analysis………………………….…...….21-22
10. Graphical Representation of the Website…………….…….. 23-29
11. Result analysis…………………………………………….…….….30
12. Conclusion……………………………………………………..…...31
13. References……………………………………………………….....32

1
1. Acknowledgement
We would like to express our special thanks of gratitude to our teacher
Dr.Manimala S, who gave us the golden opportunity to do this wonderful project on
the topic " Blood Bank Management System", which also helped us in doing a lot of
research and we learnt a great deal by doing them.

We also would like to thank our friends and family, whose guidance was always a
support to us. We also enjoyed working as a team and are looking forward to
implementing it successfully.

2
2. Abstract

Our project is a web based Blood Bank Management System. It will help the
donors to register and donate blood at the blood bank and manage the entire internal
database through one portal. It also helps the medical center to collect blood from
the blood bank. For doing this project we have used Django Framework based on
Python 3, Bootstrap, HTML, CSS and SQLite on Windows Operating System. The
Website is hosted on PythonAnywhere.
The goal of this report is to provide clear specifications and a clear concept of the
implementation of the system. This project explores a new dimension to make it
more interesting and challenging.

3
3. Problem Definition

The percentage of people donating blood is increasing day by day due to awareness
to donate blood for those needed. The blood received has to be managed thoroughly
so that there will be no negative effect to the blood receiver once they receive blood.
To handle these internal operations of a Blood Bank we have made a Web based
application.

4. Aim

The main aim of developing this system is to provide blood to the people who are
in need of blood. The number of people who are in need of blood are increasing in
large numbers day by day. Using this system users can search blood groups available
in the blood bank and he can also get the contact number of the donor who has the
same blood group he needs. In order to help people who are in need of blood, this
Online Blood Bank management system can be used effectively for getting the details
of available blood groups and users can also get the contact number of the blood
donors having the same blood group and within the same city. So if the blood group
is not available in the blood bank, the user can request the donor to donate the blood
to him and save someone's life.

4
5. Objective

This blood donation system is an online website so it is easily available to

everyone. When a person wants to donate blood he has to register to the system.
Donor registration is very easy, to get registered to the system he has to fill up a
registration form. Donors have to give information like blood group, contact details
etc.
For hospitals to place orders first that hospital has to register to the system. Then
the hospital can search blood groups available which are needed. They check it online
using our blood bank management website. If a blood group is not available in a blood
bank they can also get contact numbers of the persons who have the same blood
group they need. And they can request the person to donate blood for saving
someone's life.

5. Scope

I. This project covers Web based Blood Bank Management System within a
Blood Bank
II. It also covers Donor registration and hospital management which make use of
the BLood Bank
III. It provides secure access for admin to the database and users to a limited set
of information.
IV. This project is to be built on one databases - Admin database and he has the
full power over the complete infrastructure
V. For the users the website works without any delay of login as thought to be
important in the case of emergencies where every second is important for the
survival of the person

5
6. System Requirements Engineering

6.1 Functional Requirements

This subsection contains the requirement for the loan section of the banking
system. These requirements are gathered on real world banking scenarios.
Features form there, they are refined into use case diagrams and sequence
diagrams to best capture the functional requirements of the system.
i. User

• Get to know the availability of blood in the database

• Register as a Donor or Hospital

• Place order for the blood required

ii. Admin

• Maintain the entire system and infrastructure

• Check details of table and related data

• Filtering and sorting of details

• Maintaining other users on the database

6.2 Non-functional Requirements

This subsection contains requirements that specify criteria that can be used to
judge the operation of a system, rather than specific behaviors. They serve as
constraints or restrictions on the design of the system across the different
backlogs.

i. Performance
• The product shall be based on the web and has to be run on a web
server.
• The product shall take initial load time depending on the system
hardware.
• The performance shall depend upon hardware components of the
client/customer.

6
ii. Security

• The system’s back-end servers shall never display a user’s password or any
other sensitive credentials.

• The system’s back-end servers shall only be accessible to

authenticated administrators.

• The system’s back-end databases shall be encrypted and within the

company's perimeter if possible.

iii. Reliability

• The reliability of the overall program depends on the reliability of

separate components.

• The main pillar of reliability of the system is the backup of the database
which is continuously maintained and updated to reflect the most recent
changes.

iv. Maintainability

• A relational database is used for maintaining the database and the

application server takes care of the site.

• In case of a failure, a re-initialization of the program will be done.

• Also, the software design is done with modularity in mind so that

maintainability can be done efficiently.

6.3 Security Requirements

• Admin or User id and password protection

• Sign off button

• Failed login attempts

• Check for validity of data of Donor or Hospital while registration attempts

7
6.4 System Requirements

6.4.1 Software Requirements

This project is developed mainly using open source technologies like Python,
Django, Linux based OS, etc.

● Front End: HTML, CSS, Bootstrap, JQuery

● Back End: Django Framework
● Middleware: Django Framework
● Database: Sqlite

6.4.2 Hardware Requirements:

These are the minimum requirements to run the web app smoothly.

● Minimum RAM: 256 MB

● Hard Disk: 10 GB
● Processor: Intel Core i3 3rd Gen or higher
● Operating System: Windows 10/ Linux

8
7. System Design and Implementation

7.1 Architectural Design

Architectural design elements give us an overall view of the software.It involves

identifying the major components of the system and the communication between
these components. The architectural design element is usually depicted as a set of
interconnected subsystems, often derived from analysis packages within the
requirements model. Architectural Style: Our software is based on data centered
architecture.
Data centered software architecture is characterized by a centralized data store that
is shared by all surrounding components. All the modules or components access this
repository to store,retrieve or manipulate data as a result of which any changes
made to the database will be updated and this updated version is available to all
modules. Main purpose of data centered architecture is to achieve integrality of data.
Data-centered architecture consists of different components that communicate
through shared data repositories. The components access a shared data structure
and are relatively independent, in that, they interact only through the data store.
We are using sqlite in the backend which acts as the data repository for our bank
management system. Different modules like customers and accounts interact with
this database to insert , update and delete data in the database. The data is
consistent and integrity of data is also maintained. We are making use of the Django
web framework. It acts as middleware, sqlite for backend and html, css for frontend
design.

9
 Figure: System Architecture of the WebApp

7.2 Data Flow Diagrams

A data-flow diagram(DFD) is a way of representing the flow of a data of a process or

a system. The DFD also provides information about the outputs and inputs of each
entity and the process itself.
There are different levels of DFD’s. The description of the system indicating only an
overview of the system is represented using DFD level-0. It is also known as context
diagram. It’s designed to be an abstraction view, showing the system as a single
process with its relationship to external entities. It represents the entire system as a
single bubble with input and output data indicated by incoming/outgoing arrows.

10
Figure: Level 0 Data Flow Diagram

11
7.3 E-R DIAGRAM

Figure: Entity Relationship Diagram of the Database

12
7.4 SCHEMA DIAGRAM

13
7.5 Tables & Attributes

7.5.1 Donor
SL.NO FIELD DATA TYPE CONSTRAINTS DESCRIPTION

1. Donor_ID varchar(20) Primary Key Donor ID

2. D_Name varchar(30) Not Null Donor Name
3. D_Age int Not Null Donor Age
4. Sex varchar(10) Not Null Donor Sex
5. Weight int Not Null Donor Weight
6. D_Address varchar(30) Not Null Donor Address
7. D_DOB date Not Null Donor Birth Date
8. D_Phone_No varchar(20) Not Null Donor Phone No.
9. Mid_Hist varchar(30) Null Donor Medical
History (Any past
medical report)

Functional Dependencies:-
R:- Donor(Donor_ID, D_Name, D_Age, Sex,Weight,D_Address, D_DOB,
D_Phone_No, Mid_Hist)
FD:- Donor_ID->{ D_Name, D_Age, Sex,Weight,D_Address, D_DOB,
D_Phone_No, Mid_Hist}

The above FD is in BCNF form.

7.5.2 Blood
SL.NO FIELD DATA TYPE CONSTRAINTS DESCRIPTION

1. Blood_ID varchar(10) Primary Key Blood ID

2. Bld_Type varchar(10) Not Null Blood Type
3. Date date Not Null Date on which blood
is donated
4. Time time Not Null Time on which blood
is donated
5. Donor_ID varchar(10) Foreign Key Donor ID
6. Bld_Qty int Not Null Blood Quantity
7. BloodBank_ID varchar(10) Foreign key BloodBank_ID

14
Functional Dependencies:-
R:- Blood(Blood_ID, Bld_Type, Date, Time, Donor_ID, Bld_Qty,
BloodBank_ID)
FD:- Blood_ID->{ Bld_Type, Date, Time, Donor_ID, Bld_Qty,
BloodBank_ID}
The above FD is in BCNF form.

7.5.3 BloodBank
SL.NO FIELD DATA TYPE CONSTRAINTS DESCRIPTION
1. BloodBank_ID varchar(20) Primary Key Blood Bank ID
2. BB_Name varchar(30) Not Null Blood Bank Name
3. BB_Phone_No varchar(15) Not Null Blood Bank Phone No.
4. BB_Address varchar(40) Not Null Blood Bank Address
5. BB_Email varchar(40) Null Email Address of Blood
Bank

Functional Dependencies:-
R:-Blood bank( BloodBank_ID, BB_Name, BB_Phone_No,
BB_Address, BB_Email)
FD:-BloodBank_ID-> {BB_Name, BB_Phone_No,
BB_Address, BB_Email}

The above FD is in BCNF form.

7.5.4 Hospital
SL.NO FIELD DATA TYPE CONSTRAINT DESCRIPTION

1. Hospital_ID varchar(20) Primary Key Hospital ID

2. H_Name varchar(30) Not Null Hospital Name
3. H_Phone_No varchar(15) Not Null Hospital Phone No
4. H_Address varchar(30) Null Hospital Address

Functional Dependencies:-
R:-Hospital( Hospital_ID, H_Name, H_Phone_No, H_Address)
FD:-Hospital_ID->{H_Name, H_Phone_No, H_Address}

The above FD is in BCNF form.

15
7.5.5 Employee
SL.NO FIELD DATA TYPE CONSTRAINT DESCRIPTION

1. Emp_ID varchar(20) Primary Key Employee ID

2. E_Name varchar(20) Not Null Employee Name
3. E_Phone_No varchar(15) Not Null Employee Phone No.
4. E_Address varchar(40) Not Null Employee Address
5. E_Email varchar(40) Null Email Address of
Employee
6. Position varchar(20) Not Null Role of Employee in
Blood Bank
7. BloodBank_ID varchar(20) Foreign Key Blood Bank ID

Functional Dependencies:-

R:- Employee ( Emp_ID, E_Name, E_Phone_No, E_Address, E_Email,

Position, BloodBank_ID)
FD:-Emp_ID->{ E_Name, E_Phone_No, E_Address, E_Email,
Position, BloodBank_ID}

The above FD is in BCNF form.

7.5.6 Orders
SL.NO FIELD DATA TYPE CONSTRAINT DESCRIPTION

1. Order_ID varchar(20) Primary Key Order ID

2. Hospital_ID varchar(20) Foreign Key Hospital ID
3. Bld_Typ_Req varchar(20) Not Null Blood Type required
by Recipient in
Hospital
4. Quantity int Not Null Blood Quantity
required
5. Recipient_name varchar(30) Not Null Receiver Name

16
 6. Date date Not Null Date on which blood
is received
Functional Dependencies:-

R:- Orders ( Order_ID, Hospital_ID, Bld_Typ_Req, Quantity, Recipient_name, Date)

FD:-Order_ID-> { Hospital_ID, Bld_Typ_Req, Quantity, Recipient_name, Date}

The above FD is in BCNF form.

7.6 Database Normalization:-

The above Database Has Normalization up to BCNF.

First Normal Form (1NF):-

● A relation is in 1NF if it contains an Atomic Value.

● It states that an attribute of a table cannot hold multiple values. It must hold only
single-valued attributes. In other words, First Normal Form disallows the use of
Multi-valued Attributes, Composite Attributes and their combinations.
● If a table has multi-valued attributes, the multiple values are added to other
rows to make every attribute single-valued.

Second Normal Form (2NF):-

● To be in 2NF, a relation must first be in 1NF.

● In the Second Normal Form, all Non-Key attributes are fully functional
dependents of the Primary Key.
● If 2NF is violated by an attribute, the table is decomposed and that attribute is
put in the new table with a relation to the Original table.

17
Third Normal Form (3NF):-

● A Relation is in 3NF if it is in 2NF and does not contain any transitive partial
dependency.
● 3NF is used to reduce data duplication and achieve data integrity.
● If there is no transitive dependency for non-prime attributes, then the relation
must be in third normal form.

Boyce-Codd Normal Form (BCNF):-

● Relation is in bcnf if it's 3NF.

● A relation schema R is in BCNF if whenever an FD X -> A holds in R, then X is
a superkey of R.
● A relation NOT in BCNF should be decomposed so as to meet this property,
while possibly forgoing the preservation of all functional dependencies in the
decomposed relations.

Therefore, as per the requirements our database is in BCNF.

18
8. Modules of Blood Bank Management System

Blood Bank Management system is to provide services for the people who are in
need of blood by getting help from the donors who are interested in donating blood.
There are five main modules in this system.
● Admin
● Donor Registration
● Hospital Registration
● Order
● Availability

Admin:-
Admin can manage all the relations in the database. He can add or remove or
modify any information from the database system. The database has following
relations:-
● Bloodbanks
● Bloods
● Donors
● Employees
● Hospitals
● Orders

Donor Registration:-
In this module, people who are interested in donating blood get registered in the
website and give his overall details related to him, i.e. he fills in a registration form by
giving the total details such as name, age, sex ,weight, address, DOB, phone no.,
Medical History etc.

Hospital Registration:-
In this module, any hospital can get registered in the website and give details
about the hospital, i.e. they fill in a registration form by giving total details such as
hospital name, hospital phone number and address. Then the hospital can place
orders for the blood group available. This can be checked online using our blood
bank management website

19
Order:-
In this module , hospitals or any person in need from a particular hospital can
place an order for Blood type request and quantity . and they get registered in the
website by giving details about
● Hospital id
● Date
● Quantity
● Blood type request
● Recipient name

Availability:-
In this module, it shows the database relation of blood type and stock available .It
will get updated at each transaction. The present availability of the blood and its type
can be checked from this page.

20
9. Unit Testing and Result Analysis

Unit testing focuses verification effort on the smallest unit of software design: the
software component or module. Using the component-level design description as a
guide, important control paths are tested to uncover errors within the boundary of the
module. The relative complexity of tests and the errors those tests uncover is limited
by constrained scope established for unit testing. The unit test focuses on the
internal processing logic and data structures within the boundaries of a component.
In this section of the document, we unveil different tests conducted on each module
and the behaviour in response.

Test Feature Input Expected Actual Remarks

No. Output Output

1. Successful Login Enter correct Admin logs Admin logs to pass

of admin ID and to their their profile
Password profile

2. Unsuccessful Incorrect ID Admin does Admin does pass

Login of admin and Password not logs to not logs to
their profile their profile

3. View all relations Click on the All relations All relations pass
after admin login respective are displayed are displayed
table with details with details

21
4. Approve order Details of the Accept if Accept if pass
hospital and blood blood
requirement quantity is quantity is
including blood present and present and
quantity update update
database database
else reject else reject

5. Reject order Order quantity Reject order Reject order pass

of a particular and display and display
blood type is error error
not available message message
or data
entered is
invalid

6. Accept Donor User inputs all Database Database pass

Registration the details updated if all updated if all
required data is valid data is valid

7. Reject Donor User inputs No changes No changes pass

Registration invalid Data in happen and happen and
the form error error
message message
displayed displayed

8. Update After every Table Table pass

Availability Table order update updated on updated on
table availability availability
page page

22
10. Graphical Representation of the Website

10.1 Home Page

23
10.2 Admin login page:

After Login :

24
10.3 Hospital Registration

10.4 Donor Registration Page

25
10.5 Donor database( after admin login )

10.6 Hospital database ( after admin login )

26
10.7 Employee database ( after admin login )

10.8 Blood bank( after admin login)

27
10.9 Blood Database (after Admin login)

10.10 Orders Database( after admin login)

28
10.11 Current blood availability:

29
11. Result analysis

All the functional and non-functional requirements were taken into consideration and
a web-page was created and viewed in localhost. The database was normalized to
BCNF form. The webpage was created using HTML, CSS and Bootstrap at front
end, MySql at backend and Flask as a middleware that was used to connect to the
backend. Insert, delete and modify options have been provided through the user
Interface itself and easy navigation from one screen to another has been provided.
Aggregate functions such as group by, order by has also been used. A trigger for
checking the medical history and option to delete it has also been given. All the
requirements have been met and tested. Various test cases were developed to
check the functionality of our web-page and all the testcases were provided with
appropriate output.

30
12. Conclusion

The project has greatly enhanced the way in which a blood bank can work through a
web site. Such apps are the need of the hour as the entire world is at the highest
pace for internet adoption and here in India too it will prove to be very beneficial and
worth trying as it minimises errors, makes operations transparent, gives an easy to
use interactive interface along with a great UI. This should really help in making
people aware of the importance of blood and blood banks.While doing the project we
got to know a lot about the internal workings of the blood bank.

This project gave us a great opportunity for a web-based project to design, code,
measure and execute. This has helped to implement the different software
engineering and database management principles Concepts such as data integrity
and continuity. This has also helped me find out more about PythonAnywhere,
Django, HTML, CSS and SQLite and Personal Web Server.

31
13. References

I. Fundamentals Of Database Systems-7th edition by Ramez Elmasri

Shamkant B.Navathe
II. https://docs.djangoproject.com/en/3.1/
III. https://www.djangoproject.com/start/
IV. https://www.w3schools.com/
V. https://www.overleaf.com/project
VI. https://tex.stackexchange.com

32