Online Blood Donation Database Management System

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 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: 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 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) 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 Donor’s names Donor’s sex Date of birth District of origin Date of registration

Text

8

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)

Recipient’s identificatio n number .

Text

8

No

No

-rNames

Recipients names

Text

30

No

No

-sex

Text

6

No

No

- dob

recipient’s sex Date of birth

Date

30

No

No

- distId (FK)

District of origin

Int

3

No

No

- doreg

Date of registration Disease identificatio n number

Date

30

No

No

Text

8

No

No

Disease names Disease rating on how people

Text

30

No

No

text

20

No

No

Text

2

No

No

Text

8

No

No

Text

8

No

No

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

text

15

No

text

8

No

No

hNames

Hospital name

text

100

No

No

distId (FK)

District identificatio n number

int

3

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

8

No

No

staffNames

Staff names

text

50

No

No

sex

Sex

sex

6

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

3

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

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 :

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 :

CITY

STATE

LOGOUT

AREA

SEARC H

GROUP

SEARCH RESULT. PRINT Name

Gender

Age Location

Mobile

Residence

Office

Email

Donated Date

sdasgupta Somen Dasgupta

M

42

Dum Dum

9331980343

033-25487843

-NA-

anirban Anirban Majumdar

M

28

Dum Dum

9830716054

033 25510946

-NA-

snehadri snehadri

M

28

Dum Dum

9831168356

(033) 25492428

-NA-

Nilanjan Nilanjan

M

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.