BLOOD BANK

MANAGEMENT
Project submission for:- SYSTEM
Course Number/Section: MIS 6326.501 85761
Course Title: Data Management
Term: Fall 2018
By:
1. Siri Chandana Reddy Reddy Reddy
(Responsible for Introduction, Literature Work, ER diagram
and SQL implementation)
2. Ashwin Rathore
(Responsible for Relationship schema, ER diagram and SQL
implentation)
3. Yashvardhan Rathi
(Responsible for ER diagram, Normalization, References
and SQL implementation)
4. Manoj Saravanan
(Responsible for Relationship schema, Normalization and
SQL implementation.
5. Sukanth Rajan
(Responsible for ER Diagram, Normalization, conclusion
and SQL implementation)

Under the guidance of: Professor Hakki C. Cankaya

Page |1
 INDEX
TOPIC PAGE NO.
INTRODUCTION 3
LITERATURE WORK 4
ER DIAGRAM USING CREATLY 5
AND RELATION BETWEEN THE
ENTITIES
INFORMATION OF ENTITIES 6-7
RELATIONSHIP BETWEEN 7-8
ENTITIES
RELATIONAL SCHEMAS 8 - 11
ER DIAGRAM WITH TABLES 11
NORMALIZATION 12 -14
TABLES AFTER NORMALIZATION 15 - 19
ER DIAGRAM AFTER 19
NORMALIZATION
SQL IMPLEMENTATION 20 - 25
SAMPLE SQL QUERIES 25 - 27
CONCLUSION 28
REFERENCES 28

Page |2
 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 this system searching the available blood becomes easy and saves
lot of time than the manual system. It will hoard, operate, recover and analyze information
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.[4]

Page |3
 LITERATURE WORK
‘Blood Donation Management system’ is similar to ‘Organ Donation Management
System’ and ‘Charity Management System’ databases.

‘Organ donation management system’ is a database that automates the organ donation to the patients
who are in need of it. Each hospital maintains the ‘Organ Donation Management System’. This system
keeps track of organs available in the hospital to donate them to the patients. This system also contains
donors and acceptors. So this system is similar to ‘Blood Bank Management System’. [1]

‘Charity Management System’ keeps track of the donation of money to different organizations which
are in need of it. Here in this system, Donor is a person who donates money and acceptor is an
organization who requests for money or to whom the money is donated. This database contains
thousands of records to whom the money is donated by a person. This system is similar to ‘Blood Bank
Management System’ because the functioning is very similar when compared. [2]

Page |4
ER DIAGRAM USING CREATLY AND RELATION BETWEEN
THE ENTITIES [7]

Page |5
 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 recivies blood from blood bank, when blood is given to a
recipient a rericipient ID (reci_ID) is generated and used as primary key for the recipient entity
to indentify 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 avaible blood samples in the blood
bank, he is also resposible for handaling blood requests from recipients and hospitals. Blood
manager has a unique indentfication 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 recoder’s name and
recodrer’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 BloodSpecimen 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 entitity.

7. Hospital_Info : (Attributes – hosp_ID, hosp_name, hosp_needed_Bgrp, hosp_needed_Bqnty)

Page |6
 In the data base, under Hospital_Info entity we will store the information of hospitals. In this
hosp_ID and hosp_needed_Bgrp toether makes the primary key. We will store hospital name
and the blood quantity reqiured 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 indentification number (City_ID) will be used as primary key to indefiy the
information about the city. Along with ID city names will also be stored under this entity.

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.

6. Hospital_Info and BB_Manager:

Page |7
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”,
RELATIONAL
Donor Table: Type of relation = 1 to manySCHEMAS
Explanation = A disease
Attribute Name finder can check
Description
many Type
bd_id blood samples. OneDonor’s
Blood blood Id int
bd_Name sample is Blood Donor’s Name varchar
bd_age checked by one disease
Blood Donor’s Age int
bd_sex finder. Blood Donor’s Sex char
bd_bgrp Blood Donor’s blood group varchar
bd_regdate Registration Date of Donor date
reco_id Id of Recording Staff int
city_id City Id int

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

Page |8
Recipient Table:

Attributes Name Description Type

reci_id Recipient’s Id int
reci_Name Recipient’s Name varchar
reci_age Recipient’s age int
reci_sex Recipient’s sex char
reci_bgrp Recipient’s blood group varchar
reci_bqnty Recipient’s blood quantity int
reci_reg_date Recipient’s registration date date
reco_id Recording Staff’s Id int
city_id City’s unique Id int
M_id Blood Bank Manager’s Id int

 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:

Attributes Name Description Type

city_id City’s unique id int
city_name City’s name varchar

 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:

Attributes Name Description Type

reco_id Recording Staff’s id int
reco_name Recording Staff’s Name Varchar
reco_PhNo Recording Staff’s Phone number bigint

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

Page |9
Blood Specimen Table:

Attributes Name Description Type

specimen_No Blood Sample’s unique id int
b_grp Blood Group varchar
status Whether blood is pure or not? int
M_id Blood Bank Manager’s id int
dfind_id Disease Finder’s unique id int

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

 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:

Attributes Name Description Type

dfind_id Disease Finder’s unique id Int
dfind_name Disease Finder’s name varchar
dfind_phNo Disease Finder’s phone number bigint

 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:

Attributes Name Description Type

M_id Blood Bank Manager’s id int
m_name Blood Bank Manager’s name varchar
m_phNo Blood Bank Manager’s phone bigint
no

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

P a g e | 10
Hospital info Table:

Attributes Name Description Type

hosp_id Hospital’s unique id int
hosp_name Hospital’s name varchar
hosp_needed_Bgrp Blood group needed by hospital varchar
hosp_needed_qnty Quantity of blood group needed int
city_id City’s unique id int
M_id Blood Bank Manger’s id int

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

ER DIAGRAM WITH
TABLES

P a g e | 11
 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,
4. It should be in the First Normal form.
5. And, it should not have Partial Dependency.

Third Normal Form (3NF)

A table is said to be in the Third Normal Form when,
6. It is in the Second Normal form.
7. And, it doesn't have Transitive Dependency. [3][6]

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

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

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

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.

P a g e | 14
 TABLES AFTER
NORMALIZATION
BB_Manager:

Blood_Donor:

P a g e | 15
BloodSpecimen:

City:

P a g e | 16
DiseaseFinder:

Hospital_Info_1:

P a g e | 17
Hospital_Info_2:

Recipient:

P a g e | 18
Recording_Staff:

ER DIAGRAM AFTER
NORMALIZATION

P a g e | 19
 SQL
IMPLEMENTATION
The implementation on SQL Server is given below [3] [5] [6] [8]:

CREATE TABLE
BB_Manager ( M_id int
NOT NULL,
mName varchar(max) NOT
NULL, m_phNo bigint
-- CONSTRAINT Mid_pk
PRIMARY KEY (M_id)
);

INSERT into BB_Manager

VALUES(102,'Jack',
4693959671),
(103,'Peter', 4693959601),
(104,'Mark', 4693959677),
(105,'Jason', 4693957671);

INSERT into BB_Manager

VALUES(106,'Steve',
4694959671),
(107,'Jason', 4695959671),
(108,'Stella', 4663959671),
(109,'Monika', 4673959671),
(110,'John', 4693859671);

select * from BB_Manager

P a g e | 20
CREATE TABLE
Blood_Donor ( bd_ID
int NOT NULL,
bd_name varchar(max) NOT
NULL, bd_age varchar(max),
bd_sex varchar(max),
bd_Bgroup
varchar(10),
bd_reg_date date,
reco_ID int NOT
NULL, City_ID int
NOT NULL
-- CONSTRAINT
bdID_pk PRIMARY KEY
(bd_ID)
);

INSERT into Blood_Donor

VALUES(150221,'Mark',25,'M','B+','2015-12-
17',101212,1100),
(160011,'Abdul',35,'F','A+','2016-11-22',101212,1100),
(160101,'Smith',22,'M','O+','2016-01-04',101312,1200),
(150011,'Pat',29,'M','O+','2015-07-19',101412,1300),
(150021,'Shyam',42,'F','A-','2015-12-24',101412,1300),
(150121,'Dan',44,'M','AB+','2015-08-28',101212,1200),
(160031,'Mike',33,'F','AB-','2016-02-06',101212,1400),
(160301,'Elisa',31,'F','AB+','2016-09-
10',101312,1200),
(160091,'Carrol',24,'M','B-','2016-10-
15',101312,1500),
(160401,'Mark',29,'M','O-','2016-12-17',101212,1200);

select * from

Blood_Donor CREATE

TABLE BloodSpecimen
( specimen_number
INSERT int
into BloodSpecimen
NOT NULL, 'B+',
VALUES(1001,
b_group
1,11,101),varchar(10) NOT
(1002,
NULL, 'O+',
status1,12,102),
int,
(1003, 'AB+',
dfind_ID 1,11,102),
int NOT
(1004,
NULL, 'O-', 1,13,103),
M_id int NOT
(1005,
NULL 'A+', 0,14,101),
CONSTRAINT
(1006, 'A-', 1,13,104),
specimenumber_pk
(1007, 'AB-', 1,15,104),
PRIMARY
(1008, KEY 0,11,105),
'AB-',
(specimen_number)
(1009, 'B+', 1,13,105),
);
(1010, 'O+', 0,12,105),
(1011, 'O+', 1,13,103),
(1012, 'O-', 1,14,102),
(1013, 'B-', 1,14,102),
(1014, 'AB+', 0,15,101);

Select * from
BloodSpecimen

P a g e | 21
CREATE TABLE City
( City_ID int NOT NULL,
City_name varchar(max) NOT NULL,
-- CONSTRAINT CityID_pk PRIMARY KEY
(City_ID)
);

INSERT into City

VALUES(1200,'Austin'
),
(1300,'Irving'),
(1400,'Houston'),
(1500,'Richardson'
);

INSERT into City

VALUES(1600,'Plano'
),
(1700,'Frisco'),
(1800,'Arlington'),
(1900,'San
Antonio'),
(2000,'Tyler');

select * from City

CREATE TABLE
DiseaseFinder
( dfind_ID int NOT
NULL,
dfind_name varchar(max) NOT
NULL, dfind_PhNo bigint
-- CONSTRAINT dfindID_pk
PRIMARY KEY (dfind_ID)
);
INSERT into DiseaseFinder
VALUES(11,'Peter',469380422
3), (12,'Park',4693804223),
(13,'Jerry',4693804223),
(14,'Mark',4693804223),
(15,'Monika',4693804223);

INSERT into DiseaseFinder

VALUES(16,'Ram',469380412
3),
(17,'Swathi',4693804223),
(18,'Gautham',4693804323)
,
(19,'Ashwin',4693804423),
(20,'Yash',4693804523);

select * from

DiseaseFinder drop table

DiseaseFinder

P a g e | 22
CREATE TABLE
Hospital_Info_1 ( hosp_ID
int NOT NULL,
hosp_name varchar(max) NOT
NULL, City_ID int NOT NULL,
M_id int NOT NULL
primary
key(hosp_ID)
-- CONSTRAINT
hospID_pk PRIMARY
KEY (hosp_ID)
);

INSERT into Hospital_Info_1

VALUES(1,'MayoClinic',1100,10
1),
(2,'CleavelandClinic',1200,10
3), (3,'NYU',1300,103);

INSERT into
Hospital_Info_1
VALUES(4,'Baylor',1400,10
4),
(5,'Charlton',1800,103),
(6,'Greenoaks',1300,106),
(7,'Forestpark',1300,102)
,
(8,'Parkland',1200,106),
(9,'Pinecreek',1500,109)
CREATE TABLE
,
Hospital_Info_2 ( hosp_ID
(10,'WalnutHill',1700,10
int NOT NULL,
5);
hosp_name varchar(max)
NOT NULL,
select * from
hosp_needed_Bgrp
Hospital_Info_1
varchar(10),
hosp_needed_qnty int
primary
key(hosp_ID,hosp_needed_Bg
rp)
-- CONSTRAINT hospID_pk
PRIMARY KEY (hosp_ID)
);

INSERT into Hospital_Info_2

VALUES(1,'MayoClinic','A+',2
0),
(1,'MayoClinic','AB+',0),
(1,'MayoClinic','A-',40),
(1,'MayoClinic','B-',10),
(1,'MayoClinic','AB-',20);

INSERT into Hospital_Info_2

VALUES(2,'CleavelandClinic','A+',4
0),
(2,'CleavelandClinic','AB+',20),
(2,'CleavelandClinic','A-',10),
(2,'CleavelandClinic','B-',30),
(2,'CleavelandClinic','B+',0),
(2,'CleavelandClinic','AB-',10);

INSERT into
P a g e | 23
Hospital_Info_2
VALUES(3,'NYU','A+',0),
(3,'NYU','AB+',0),
(3,'NYU','B+',10),
(3,'NYU','AB-',0);

INSERT into
Hospital_Info_2
VALUES(4,'Baylor','A+',1
0),
(5,'Charlton','B+',30),
(4,'Baylor','A-',40),
(7,'Forestpark','B-',40)
,
(8,'Parkland','B+',10),
(9,'Pinecreek','AB-',20)
;

CREATE
select TABLE
* from
Recipient ( reci_ID
Hospital_Info_2
int NOT NULL,
reci_name varchar(max) NOT
NULL, reci_age varchar(max),
reci_Brgp varchar(max),
reci_Bqnty float,
reco_ID int NOT
NULL, City_ID int
NOT NULL, M_id int
NOT NULL, reci_sex
varchar(max),
reci_reg_date date
-- CONSTRAINT
reciid_pk PRIMARY
KEY (reci_id)
);

Alter table Recipient

ADD reci_sex
varchar(max);

Alter table Recipient

ADD reci_reg_date
date;

INSERT into Recipient

VALUES(10001,'Mark',25,'B+',1.5,101212,1100,101,'M','2015-
12-17'),
(10002,'Dan',60,'A+',1,101312,1100,102,'M','2015-12-16'),
(10003,'Steve',35,'AB+',0.5,101312,1200,102,'M','2015-10-
17'),
(10004,'Parker',66,'B+',1,101212,1300,104,'M','2016-11-17'),
(10005,'Jason',53,'B-',1,101412,1400,105,'M','2015-04-17'),
(10006,'Preetham',45,'O+',1.5,101512,1500,105,'M','2015-12-
17'),
(10007,'Swetha',22,'AB-',1,101212,1500,101,'F','2015-05-
17');

INSERT into Recipient

VALUES(10008,'Swathi',25,'B+',2,101412,1300,103,'F','2015-
12-14'),
(10009,'Lance',30,'A+',1.5,101312,1100,104,'M','2015-02-
16'),
(10010,'Marsh',25,'AB+',3.5,101212,1200,107,'M','2016-10-
17');
P a g e | 24
select * from
CREATE TABLE
Recording_Staff ( reco_ID
int NOT NULL,
reco_Name varchar(max) NOT
NULL, reco_phNo bigint
-- CONSTRAINT recoID_pk
PRIMARY KEY (reco_ID)
);

INSERT into Recording_Staff

VALUES(101212,'Walcot',404580655
3), (101312,'Henry',4045806553),
(101412,'Silva',4045806553),
(101512,'Adrian',4045806553),
(101612,'Mark',4045806553);

INSERT into Recording_Staff

VALUES(101712,'Abdul',404581655
3),
(101812,'Jerry',4045826553),
(101912,'Tim',4045836553),
(101012,'Lekha',4044846553),
(101112,'Mark',4045856553);

select * from Recording_Staff

update City set City_name = 'Allen' where City_ID

= 2000

delete from Hospital_Info_2 where hosp_name =

'Charlton'

SAMPLE SQL QUERIES

1. Create a View of recipients and donors names having the same blood group registered on the
same date.
CREATE VIEW Blood_Recipient_SameBGrp;
AS
select
Blood_Donor.bd_name,Recipient.reci
_name,reco_Name from
Recording_Staff
inner join Blood_Donor on Recording_Staff.reco_ID =
Blood_Donor.reco_ID inner join Recipient on
Recording_Staff.reco_ID = Recipient.reco_ID where
Blood_Donor.bd_Bgroup = Recipient.reci_Brgp and
Blood_Donor.bd_reg_date = Recipient.reci_reg_date

P a g e | 25
 Output:
select* from
Blood_Recipient_SameBGrp;

2. Show the blood specimen verified by disease finder Mark which are pure (status=1).
Select specimen_number,b_group from
BloodSpecimen,DiseaseFinder WHERE BloodSpecimen.dfind_ID=
DiseaseFinder.dfind_ID AND dfind_name='Mark' AND status=1

Output:

3. Show the pure blood specimen handled by BB_Manager who also handles a recipient needing
the same blood group along with the details of the BB_Manager and Recipient.

select BB_Manager.M_id,mName,Recipient.reci_name,
Recipient.reci_Brgp,b_group from BB_Manager,Recipient,BloodSpecimen
where Recipient.M_id = BloodSpecimen.M_id and Recipient.reci_Brgp =
BloodSpecimen.b_group
and status = 1

Output:

P a g e | 26
 4. Show the donors having the same blood groups required by the recipient staying in the same
city along with recipient details.

Select bd_ID,bd_name,reci_ID,reci_name FROM Blood_Donor,Recipient

WHERE bd_Bgroup=reci_Brgp AND Blood_Donor.City_ID=
Recipient.City_ID

Output:

5. Display the information of Hospital_Info_1 handled by BB_Manager whose ID is 103:

Select hosp_ID,hosp_name , City_ID, HOspital_Info_1.M_id from

Hospital_Info_1,BB_Manager where BB_Manager.M_id=Hospital_Info_1.M_id and
BB_Manager.M_id=103

P a g e | 27
 CONCLUSION
Our project well addressed the limitations of the existing system. We designed well organized database
management system which is a challenging job in this era. We have built a database for a Blood Bank
using Microsoft SQL Server. Before implementing the database, in the design phase, we have explored
various features, operations of a blood bank to figure out required entities, attributes and the
relationship among entities to make an efficient Entity Relationship Diagram(ERD). After analyzing all the
requirements, we have created our ERD and then converted the ERD to relational model and normalized
the tables. Using Microsoft SQL Server we have created the tables for our database and inserted some
sample values in the tables. Finally, we have executed sample queries on our database to check its
performance to retrieve useful information accurately and speedily.

REFERENCES
1 Organ Donation Management System - Chitra , Ramasamy (2007) - Melaka, Malaysia, UTeM.
2 Charity Management System - Sara Aljohani (2015)
3 DATABASE DESIGN, APPLICATION DEVELOPMENT, AND ADMINISTRATION (6thedition) –
Michael Mannino
4Blood Donation Management: Recent trends – Sunil K Joseph, Johnson Michael, Prem
Jose Vazhacharickal
5 SQL server tutorial: https://www.tutorialspoint.com/ms_sql_server/
6 Notes from Prof. Hakki C Cankaya, University of Texas at Dallas, Dallas, Texas
7Tool for ER diagram: Creately
https://creately.com/app/?tempID=hqdgwjki1&login_type=de
mo#
8 SQL Implementation Tool: Microsoft SQL Server 2017

P a g e | 28
P a g e | 29