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. Administrator should have access to all details of blood donors

ii. 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 system’s 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:

I. Scalability and extensibility.

a.) Flexibility and robustness.
b.) Excellent reporting with good printing supports.
c.) Platform independent.
d.) Must have a GUI that assists employees from non-I.T
background.
e.) Event-driven program facility.
f.) 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. Multiple user support

2. Efficient data handling.
3. Provide inherent features for security.
 4. Stored procedures.

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

As per the above stated features we’ll 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) The cost to conduct a full system investigation.

b) The cost of hardware and software to be used.
c) The benefits in the form of reduced cost.
d) 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 man-power.

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 Delet Backup data
Reset
task that are e data database
performed by other
users Backup
Delete database
donor

Restore
Delete database
recipen
t
Delete a
phased out
disease
  The Users :

User Functionalities

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

Login
Administrat
or

Search by Search Want to

donors by Search donate
recipients by Year 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 here, as this project

is not too complex.

Data Dictionary Entity Name Description

A person who donates blood
Donors
Recipients A person who receives blood
Diseases 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
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 Description Data Size Nulls Multi

Type valued

donorId Donor Text 8 No No

(a)(PK) identificatio
n number
(a)-dNames Donor’s Text 30 No No
names
(a)-sex Donor’s sex Text 6 No No
- dob Date of birth Date 30 No No
- distId District of Int 3 No No
(FK) origin
- doreg Date of Date 30 No No
registration
Recipients -rId (PK) Recipient’s Text 8 No No
identificatio
n number .

-rNames Recipients Text 30 No No

names

-sex recipient’s Text 6 No No

sex
- dob Date of birth Date 30 No No

- distId District of Int 3 No No

(FK) origin

- doreg Date of Date 30 No No

registration
Diseases -dId (PK) Disease Text 8 No No
identificatio
n number

-dNames Disease Text 30 No No

names
-drating Disease text 20 No No
rating on
how people

are infected
from it
Blood bGroup(P Blood group Text 2 No No
K)

donorId Donor Text 8 No No

(FK) identificatio
n number

rId (FK) recipient

identificatio Text 8 No No
n number

status status of the text 15 No

donated No
blood
whether
infected or
not
Hospital/ hId (PK) Hospital text 8 No No
Clinic identificatio
n number

hNames Hospital text 100 No No

name

distId District
(FK) identificatio int 3 No No
n number
Staff staffId Staff text 8 No No
(PK) identificatio
n number

staffNames Staff names text 50 No No

sex Sex sex 6 No No

dob Date of birth date 15 No No

departmen Department text 100 No No

t to which the
staff belongs
District distId District int 3 No No
number

distName District text 100 No No

name

ENTITY RELATIONS
 Entity name Multiplicity Relationship Entity Name Multiplicity
1 Donates Blood 1
(a)
Recipients 1 Receives Blood 1
Diseases 1 Contained in Blood 0 ..*
Blood 1 Donated by Donor 1 ..*
Hospital/ 1 Receives Blood 1 ..*
Clinic
Staff 1 Registers Donors 1 ..*
District 1 Has Recipients 1 ..*

 6.) ENTITY RELATIONSHIP DIAGRAM:

An entity relationship (ER) diagram is used to visualize the system and represent the user’s
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.

Staff
(PK staffId
Producing a logical data model involves normalization. The
aim of normalization is to eradicate staffNames certain undesirable
characteristics from a database design. It removes data
sex
redundancy and thus prevents update anomalies. Normalization
helps increase the clarity of the data dob model.

department

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.

Donors
(PK donor
Id 1..*
dNam
es
sex
FK dob

distId
doreg

Diseases Registe
1..1
(PK dId Recipient rs
PK rId
dNam rNames
sex
es dob

dRati FK distId
ng doreg
 1..* 1..*

1..*

1..1

Fig: E-R diagram.

Hospital Blood
PK bGroup
(PK
hId FK donorI
(PK) d

FK rId
status
FK  PAGE FLOW
hNam DIAGRAMS:-
es
distId District
PK
ONLINE BLOOD DONOR
distId DATABASE AND WEB-PORTAL
distName

LOGIN HERE

USER TYPE:
USER ID:
PASSWORD:

REGISTER FREE!!
CLICK TO SEARCH LOGOUT
ON CLICKING SIGN UP!!! THECONTROL GOES TO THIS PAGE:-

SELECT USER:

O HOSPITALS ,CLINICS
& BLOOD BANKS
O OTHER USERS
O DONORS

ON SELECTING ANY USER (hyperlinks), THEIR CORRESPONDING

REGISTRATION FORM OPENS: --

DONOR REGISTRATION FORM

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

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 :

DONOR’S 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 : LOGOUT

STATE CITY AREA GROUP SEARCH

SEARCH RESULT. PRINT
Donated
  Name Gender Age Location Mobile Residence Office Email
Date
sdasgupta Somen Dum
M 42 9331980343 033-25487843     -NA-
Dasgupta Dum

anirban Anirban Dum

M 28 9830716054 033 25510946     -NA-
Majumdar Dum

Dum (033) 2549-

snehadri snehadri M 28 9831168356     -NA-
Dum 2428

Dum +91 33 2560

Nilanjan Nilanjan M 35 9830746565     -NA-
Dum 0060

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