SUBMITTED IN PARTIAL FULFILLMENT OF THE

REQUIREMENTS FOR THE DEGREE OF

B.TECH IN INFORMATION TECHHNOLOGY

ACKNOWLEDGEMENT

APART FROM THE EFFORTS OF MINE, THE SUCCESS OF MY PROJECT

DEPENDS LARGELY ON THE ENCOURAGEMENT AND GUIDELINES OF MANY
OTHERS. I TAKE THIS OPPORTUNITY TO EXPRESS MY GRATITUDE TO THE
PEOPLE WHO HAVE BEEN INSTRUMENTAL IN THE SUCCESSSFUL
COMPLETION OF THIS PROJECT.

THE GUIDANCE AND SUPPORT RECEIVED FROM ALL OTHER MEMBERS EHO
CONOTRIBUTED IN THIS PROJECT WAS VITAL FOR THE SUCCESS OF THE
PROJECT. I AM GRATEFUL FOR THEIR CONSTANT SUPPORT AND HELP.

CONTENTS:

1.

INTRODUCTION
PURPOSE
SCOPE
TECHNOLOGIES & TOOLS USED
OVERVIEW

2.

REQUIREMENT SPECIFICATIONS
GOAL OF PROPOSED
BACKGROUND
FUNCTIONAL REQUIREMENTS
NON-FUNCTIONAL REQUIREMENTS
CONSTRAINTS
USER CHARACTERISTICS
ISSUES RESOLVED
ACCESS LEVEL ANALYSIS

3.

FEASIBILITY STUDY
STEPS IN FEASIBILITY STUDY
TECHNICAL FEASIBILITY
ECONOMIC FEASIBILITY
SCHEDULE FEASIBILITY

4.

TASK STRUCTURE DIAGRAMS.

5.

DATABASE DESIGN

6.

ENTITY RELATIONSHIP DIAGRAM

& DATA TABLES.

7.

PAGE FLOW DIAGRAMS.

8.

CODING

9.

COST ESTIMATION

10.

FUTURE ENHANCEMENTS

11.

CONCLUSION

12.

BIBLIOGRAPHY

1..) INTRODUCTION

Purpose:
-- The main purpose of the study was to create electronic blood donor management
information system in order to assist in the management of blood donor records,
planning and share information in a more confidential, convenient and secure way and
distributing bloods through respective blood banks, clinics, and hospitals using modern
technology.

-- It maintains three levels of users:A. Administrator (this should be a general body , could be from central blood bank
agency)
B. Blood Banks, Hospitals, Clinics, etc
C. Blood Donors
D. Non- Members

-- The software includes :Maintaining blood donor details.

Availability of blood at blood-banks.
Up to date stock of blood
Online searching of blood donor.

Scope :
It can be used in any Hospital , Clinic, Blood banks and by the registered blood
donors for the purpose of checking blood stocks, donor details, updating donor
details, validity checking of registered donor cards.

 Technologies to be used :
1. Database Design ( Oracle 9i )
2. form design ( HTML)
3. Coding ( JSP, JAVA SCRIPT)

Tools to be used :

Eclipse IDE

JBoss 4.2

Java development kit 1.6

Any web browser

Microsoft windows professional (sp-3)

Presentation and documentation tools :

Microsoft Word 2007

Microsoft Powerpoint 2007

HARDWARE REQUIREMENTS:
o PENTIUM CORE 3.06GHZ
o 1 GB RAM

2. REQUIREMENT SPECIFICATIONS:

 Goals of proposed system:

Planned approach towards working: The working in the

organization will be well planned and organized. The data
will be stored properly in the database and will help in proper
access to it.

Accuracy: The level of accuracy in the proposed system will

be higher. All operation would be done correctly and it
ensures that whatever information is coming from the center
is accurate.
Reliability: The reliability of the proposed system will be
high due to the above stated reasons. The reason for the
increased reliability of the system is that now there would be
proper storage of information.
Immediate retrieval of information: the main objective
of the proposed system is to provide for a quick and efficient
retrieval of information. Any type of information would be
available whenever the user requires.
No redundancy: In the proposed system utmost care would
be taken so that no redundancy occurs. This would ensure
economic use of storage space and consistency in the data
stored.
Easy to operate: The system should be easy to operate
and should be such that it can be developed within a short
course of time and fit in the limited budget of the user.
Security: only the DBA could access through out the
database. Other users are going to work on or view a certain
part of the database that is also through proper registration
and validation. Authentication is a must in case of providing
security for the database.

 Background:

Normally incase of medical treatments, we are often prescribed, from

hospitals or
polyclinics to get blood for the patients belonging to a respective
blood group. The blood
banks are the sources of getting blood of the right group and right
quality.. Some other way
to get blood is to find out a donor who is available within a short time.

Our system provides facilities like:

Updating, modifying and deleting donor details

Registration of new donors

Checking validity of donor cards

look for donors in their nearby area who will be available

in quick time.

Putting feedback against a donor i.e. serving well to the

customers.

Non-members can also look for blood donors or Bloods in

any particular banks

FUNCTIONAL REQUIREMENTS:

i.
ii.

Administrator should have access to all details of blood donors

While filling the personal information page for any donor, only
Name, Region, contact details which could be phone number / email
and blood group should be made mandatory. Other details should
not be made mandatory. The details of donors should be saved in
such a way that there should be less blank spaces .

iii.

Blood Banks , hospitals etc could browse for blood donors in their
near by area and also the search result should provide only those
donors who have not donated blood in last 3 months

iv.

Blood donors should be asked to give feedback of the health

report of donors (on basis of their blood taken), for future
consideration after the blood donation is being made by donor.

v.

No user could access any details of donors without being a

member of website.

vi.

Only hospitals, blood banks etc should be able to see the contact
details of donors (like phone number / email)

vii.

Blood donor should be allowed to see only the name and region
they live in. Also if they need to ask another blood donor for any
blood donation help it should be through admin and proper reason
for which there should be a form to be filled by donor.

viii.

A points should be given to every donor on basis of their blood

donation which could be used by blood donors if they need blood for
any of their relatives , friends etc. (The priority for making blood
available by member blood banks for those donors)

ix.

The search for donors should be made flexible , for example a user
can give delhi in different forms like , DELHI, delhi, Delhi . So the
query to search on the basis of region should be made case
sensitive by using available functions. (Extra points on using xml
functions)

x.

Non-members can also look for blood donors or Bloods in any

particular banks and then do quick register through their mobile
phones and raise a ticket for Blood requirements.

NON-FUNCTIONAL REQUIREMENTS:

Try to link this application with any social networking website

like facebook using it as a marketing strategy.

The system should be smart enough to choose different donors

every time, instead of selecting the same dono after every 3
months.

USER CHARACTERISTICS:
Every user should be:

Computer savvy.

Must have knowledge about medical field.

Must have knowledge of English language.

CONSTRAINTS:

GUI is in English.

Separate users are to be created through which the respective

users can login to the blood donor website portal.

ISSUES RESOLVED ??
Immediate information storage and retrieval:
In early days, these things were done manually using pen &
paper, which took lots of time in data entry and retrieval of
accurate information. This procedure was too time

consuming and at times it also seemed to be unreliable due to

manual mistakes. But , the advent of database management
system has helped to tide over the problems resulting in fast
retrieval of data and data storage.
Providing security:

In early times, as data was maintained manually, enforcing

security was tough, but by the use of computers we could easily
enforce some security algorithms to protect our data.

Finding out the blood donors were a hectic job decade

before. But through online access we could reach the donors
within a few mouse-clicks.

ACCESS LEVEL ANALYSIS:

In order to take closer look into what the system should do and how,
it was necessary to decompose the systems functionalities based on
the user type and levels of access. The three main user groups and
access levels are:
Global User Group (normal access level)
Blood Banks, Hospitals, Clinics (privileged access level)
The Administration (privileged access level)
Therefore, the requirements could be efficiently analyzed depending
on the user group and the functionalities they should be allowed to
perform.

 3.) FEASIBILITY

STUDY:

Depending on the results of the initial investigation the survey is now

expanded to a more detailed feasibility study. FEASIBILITY STUDY is a
test of system proposal according to its workability, impact of the
organization, ability to meet needs and effective use of the resources. It
focuses on the following issues:
Where are the users demonstrable needs and ow does a candidate
system meet them?
What resources are available for given candidate system?
What are likely impacts of the candidate system on the organization?
Whether it is worth to solve the problem?
During feasibility analysis of a project , following primary areas of interest
are to be considered. Investigation and generating ideas about a new
system does this.
The various kinds of feasibility studies are discussd below:
i.) TECHNICAL FEASIBILITY:
A study of resource availability that mat may affect the ability to
achieve an acceptable system. This evaluation determines weather
the technology needed for the proposed system is available or not.

Can the work get done with current equipment existing software
technology and available personal?
Can the system be upgraded if developed?
If new technology is needed then what can be developed?

This is concerned with specifying the user requirement. The technical needs
of the system may include:
i. FRONT-END SELECTION:
a.)
b.)
c.)
d.)

Scalability and extensibility.

Flexibility and robustness.
Excellent reporting with good printing
supports.
Platform independent.

e.)
f.)
g.)

Must have a GUI that assists employees from

non-I.T background.
Event-driven program facility.
Front end must support a suitable and popular
backend (eg: MySQL).

As per the above stated feature we selected as our front-end J2EE

and HTML technologies.

ii.

BACK-END SELECTION:
1.
2.
3.
4.

Multiple user support

Efficient data handling.
Provide inherent features for security.
Stored procedures.

5.
6.
7.
8.

Popularity.
Operating system compatibility.
Various drivers must be available.
Easy to implant the front-end.

As per the above stated features well select ORACLE 9i / MySQL

SERVER as backend technology.
ii)

ECONOMICAL FEASIBILITY:

Economic justification includes a broad range of concerns that includes cost

benefit analysis. The financial and economic questions during the
preliminary investigation are verified to estimate the following:
a)
b)
c)
d)

The cost to conduct a full system investigation.

The cost of hardware and software to be used.
The benefits in the form of reduced cost.
Proposed system will give the minute information
and improve performance which in turn gives
increased profits.

e) This feasibility checks whether the system can

be developed with the available funds. This
particular project need not a huge amount of
money for development.

f) Cost of the project depends of the required manpower.

iii) OPERATIONAL FEASIBILITY:

It is mainly related to human organizations and political aspectsthe
points to be considered as:

What changes will be brought to the system ?

What organization structures are distributed ?
What new skills will be required? Do the existing staff
have these skills? If not, can they get trained in due
course of time?

iv) SCHEDULE FEASIBILITY:

It deals with the time evaluation, the most important consideration in
the development of
the project. The cost of the project also
depends on the time taken to complete it.

4.) TASK STRUCTURE DIAGRAMS.:

The Administrator User:

ADMINISTRATIVE
FUNCTIONALITIE
S

The administrator
can perform any
task that are
performed by other
users

Delet
e data

Backup data

Delete
donor

Reset
database
Backup
database

Restore
database

Delete
recipen
t
Delete a
phased out
disease

The Users :

User Functionalities

Logi
n

Search
database
Login as
clinic,blood
bank,hospita
l user

Login
Administrat
or

Search by
donors

Search
by
recipients

Search
by Year

Want to
donate
blood

 5.) DATA BASE DESIGN:

Database design involves the production of a model of the data to be stored
in the database. A data model is a diagram of the database design that
documents and communicates how the database is structured. The
database design methodology followed in this project presents quite a
detailed guide to designing databases, but not all of those steps may apply
Data Dictionary Entity Name
Donors
Recipients
Diseases

Description
A person who donates blood

A person who receives blood

The diseases which are found in
the infected donated blood
Blood group
The blood that is donated by the
donors
Hospital/Clinic
Hospitals to which donated blood
is distributed
Staff
Respective staffs
District
Districts from which donors and
recipients originate from
here, as this project is not too complex.
The design process is divided into three main stages conceptual, logical
and physical database design. The purpose of the conceptual database
design is to decompose the design into more manageable tasks, by
examining user perspectives of the system. That is, local conceptual data
models are created that are a complete and accurate representation of the
TABLE: DATA DICTIONARY.

enterprise as seen by different users. Each local conceptual data model is

made up of entity types, relationship types, attributes and their domains,
primary keys and integrity constraints. For each user view identified a local
conceptual data model would be built. In building the conceptual data
model, a data dictionary is built to identify the major entities in the system.

CONCEPTUAL DATABASE DESIGN :

In this stage, a local conceptual data model is built for each identified view in the
system. A local conceptual data model comprises of entity types, relationship
types, attributes and their domains, primary and alternate keys, and integrity
constraints. The conceptual data model is supported by documentation such as a
data dictionary.
The entity types are the main objects the users are interested in. Entities have an
existence in their own right. Entity types are identified and their names and
description are recorded in a data dictionary. Care is taking to ensure that all
relationships in the users requirements specification are identified.

Entity name

Attributes
donorId
(a)(PK)
(a)-dNames
(a)-sex
- dob
- distId
(FK)
- doreg

Description

Data
Type

Size

Nulls

Multi
valued

Donor
identificatio
n number
Donors
names
Donors sex
Date of birth
District of
origin
Date of
registration

Text

No

No

Text

30

No

No

Text
Date
Int

6
30
3

No
No
No

No
No
No

Date

30

No

No

Recipients

Diseases

-rId (PK)

Recipients
identificatio
n number .

Text

No

No

-rNames

Recipients
names

Text

30

No

No

-sex

Text

No

No

- dob

recipients
sex
Date of birth

Date

30

No

No

- distId
(FK)

District of
origin

Int

No

No

- doreg

Date of
registration
Disease
identificatio
n number

Date

30

No

No

Text

No

No

Disease
names
Disease
rating on
how people

Text

30

No

No

text

20

No

No

Text

No

No

Text

No

No

Text

No

No

status of the
donated
blood
whether
infected or
not
Hospital
identificatio
n number

text

15

No

text

No

No

hNames

Hospital
name

text

100

No

No

distId
(FK)

District
identificatio
n number

int

No

No

-dId (PK)

-dNames
-drating

Blood

bGroup(P
K)
donorId
(FK)

Donor
identificatio
n number

rId (FK)

recipient
identificatio
n number

status

Hospital/
Clinic

are infected
from it
Blood group

hId (PK)

No

Staff

District

staffId
(PK)

Staff
identificatio
n number

text

No

No

staffNames

Staff names

text

50

No

No

sex

Sex

sex

No

No

dob

Date of birth

date

15

No

No

departmen
t

Department
to which the
staff belongs
District
number

text

100

No

No

int

No

No

District
name

text

100

No

No

distId
distName

ENTITY RELATIONS
Entity name

Recipients
Diseases
Blood
Hospital/
Clinic
Staff
District

Multiplicity
1
(a)
1
1
1
1
1
1

Relationship
Donates
Receives
Contained in
Donated by
Receives
Registers
Has

Entity Name
Blood

Multiplicity
1

Blood
Blood
Donor
Blood

1
0 ..*
1 ..*
1 ..*

Donors
Recipients

1 ..*
1 ..*

 6.) ENTITY RELATIONSHIP DIAGRAM:

An entity relationship (ER) diagram is used to visualize the system and
represent the users requirements. The ER diagram is used to represent
entities and how they relate to one another. The ER diagram also shows the
relationships between the entities, their occurrence (multiplicities) and
attributes.

Logical Database:

The process of logical database design constructs a model of the

information used in an enterprise based on a specific data model, such as
the relational model, but independent of a particular DBMS and other
physical considerations (Connolly et al, 2002)[xx]. The logical database
design consists of an ER diagram, a relational schema, and any
supporting documentation for them. In the logical data model, all attributes
of entities are primitive.

Producing a logical data model involves normalization. The aim of

normalization is to eradicate certain undesirable characteristics from a
database design. It removes data redundancy and thus prevents update
anomalies. Normalization helps increase the clarity of the data model.

Integrity constraints are imposed in order to protect the database

from becoming inconsistent. There are five types of integrity constraints
required data, attribute domain constraints, entity integrity, referential
integrity and enterprise constraints. The resulting relations are validated
using normalization. For this project, producing relations in third normal
form (3NF) will suffice. Non-relational features, such as many-to-many
relationships and some one-to-one relationships, are removed from the
conceptual data model. The design is also reviewed to make sure it meets
all the transaction requirements.

Staf
(PK

staffId
staffNam
es
sex
dob
departme
nt

Donors
(PK
donor
Id
dNam
es
sex
FK
dob

1..*

distId
doreg

Registe
rs

1..1
Hospital
Diseases
(PK
dId
(PK
hId
dNam
(PK)
es
FK

dRati
ng
hNam
es
distId

Blood
PK
FK
FK
1..*

1..*

bGroup

Recipient
rId
PK donorI
d

rNames
sex
dob

rId
FK statusdistId
doreg

District
PK
distId
distName

1..*

1..1

Fig: E-R diagram.

PAGE FLOW DIAGRAMS:ONLINE BLOOD DONOR DATABASE AND WEB-PORTAL

LOGIN HERE

USER
TYPE:

USER ID:
PASSWOR
D:

REGISTER
FREE!!

ON CLICKING SIGN UP!!! THECONTROL GOES TO THIS PAGE:-

SELECT USER:
O HOSPITALS ,CLINICS
& BLOOD
BANKS
DONOR
REGISTRATION
FORM
ONAME:
OTHER USERS
O DONORS
DONOR
ID:ADDRESS
PHONE:DISTRICTAREA:PIN:
PHONE:BLOOD GROUP:DISEASE:AGE:LAST DONATED OR NEW:

ON SELECTING ANY USER (hyperlinks), THEIR CORRESPONDING

REGISTRATION FORM OPENS: --

LOGO
UT

HOSPITALS,CLINICS & BLOOD BANK REGISTRATION FORM

NAME:
REG_NO:ADDRESS
DEPARTMENTPHONEDISTRICTAREA:PIN:
PHONE:

OTHER USER REGISTRATION FORM

NAME:
ADDRESS
DISTRICTAREA:PIN:
PHONE:BLOOD GROUP:DISEASE:AGE:LAST DONATED OR NEW:

CANCEL

AFTER SUBMITTING THE REGISTRATION FORMS , A UNIQUE ID IS

GENERATED TO THE PERSON. AND THE DATA IS STORED IN THE
DATABASE :

DONORS IDENTITY

PASTE
PHOTO

NAME:AGE:IDENTITY NO:CARD
VALIDITY:BLOOD GROUP:

TO SEARCH THE DATABASE:

SEARCH DONOR / BLOOD

SEARCH BY:
AREA
YEAR BLOOD GROUPBLOOOD GROUPLOOK FOR:DIRECT
DONORBLOOD BANK AVAILABILITY

G
O

UPON SUCCESSFUL SEARCH , THE RESULT IS SHOWN AS PER THE

FOLLWING STRUCTURE:
ONLINE BLOOD BANK WEB-PORTAL :

CITY

STATE

LOGOUT

AREA

SEARC
H

GROUP

SEARCH RESULT.
PRINT
Name

Gender

Age Location

Mobile

Residence

Office

Email

Donated
Date

sdasgupta Somen
Dasgupta

42

Dum
Dum

9331980343

033-25487843

-NA-

anirban Anirban
Majumdar

28

Dum
Dum

9830716054

033 25510946

-NA-

snehadri snehadri

28

Dum
Dum

9831168356

(033) 25492428

-NA-

Nilanjan Nilanjan

35

Dum
Dum

9830746565

+91 33 2560
0060

-NA-

ON CLICKING THE FEEDBACK , BELOW WILL BE GENERATED:FeedBackName E-MailIDComment

CONCLUSION
The project Online Blood Donor Central Database is to provide easy
and effective storage of information related to blood donors and blood-banks .
Proper design builds upon this foundation to give a blue print, which is actually
implemented by the developers.
On realizing the importance of systematic documentation all the processes
are implemented using a software engineering approach.
We have gained a lot of practical knowledge from this project, which we
think, shall make us stand in a good state in the future.