1.
Distributed Blood Bank
Management System Database
An Overview
1

2.
Prepared By:
Saimunur Rahman
Dept. Computer Science & Engineering
International Islamic University Chittagong
2

3.
Before I start my discussion
Let us know
What is Blood Bank?
3

4.
What is Blood Bank?
 A blood bank is a cache or bank
of blood or blood components,
gathered as a result of blood
donation or collection, stored and
preserved for later use in blood
transfusion.
 The term "blood bank" typically refers
to a division of a hospital where the
storage of blood product occurs and
where proper testing is performed.
4

5.
What is Blood Bank? (Cont.)
 It sometimes refers to a collection
center, and indeed some hospitals
also perform collection.
 The Blood Bank Management System
has been created with a purpose of
replacing all of paperwork done at the
Blood Bank.
 All aspects of blood banking is
completely managed by the software.
5

6.
Basic Project Overview
 In this project we are trying to
implement a distributed database from
a centralized database of Blood Bank
Management System.
 Here, we have designed a distributed
database system for Blood Bank
Management from a centralized
database system.
 Which will increase the system
performance, reliability and
throughput.
6

7.
Methodology
I have incorporated several
methodologies for creating this
system, which is shown in next slide
7

8.
Methodology (Cont.)
8
Existing
System Review
i.e. Centralized
DB
Data
distribution
based on
horizontal
fragmentation
Getting Query
Statistics
Vertical
Fragmentation
based on
Query statistics
Figure: Developing Methodology

9.
Methodology (Cont.)
 Existing System Review: First we
reviewed the existing centralized
database for Blood Bank Management
System that was also created by us.
 Data distribution based on
horizontal fragmentation: We have
distributed our data’s into several sites
which is the main criteria of distributed
database system.
9

10.
Methodology (Cont.)
 Getting Query Statistics: After data
distribution into sites we are then
getting the query statistics and based
upon that we go for vertical
fragmentation.
 Vertical Fragmentation based on
Query statistics: Then we fragment
our site database vertically based on
site query statistics.
10

11.
Methodology (Cont.)
 Vertical Fragmentation based on
Query statistics (Cont.): Vertical
fragmentation is actually for several
site applications which used to access
the data form database system.
 Here, are also calculating query hit
and miss for a general query
generated from a site.
11

12.
Existing Centralized Database ERD
12

13.
Sample Tables with Dates
13
Figure: Branch Table

14.
Sample Tables with Dates
(Cont.)
14
Figure: Donor Table

15.
Distribution among sites
15
Site Name Site area
Blood Bank Chwakbazar Chwakbazar
Blood Bank CMCH Prabortok Circle
Blood Bank Bahaddarhat Chandgaon
Blood Bank Anderkilla Anderkilla
Blood Bank Agrabad Agrabad
Blood Bank New Market New Market
Blood Bank CEPZ CEPZ
Blood Bank Halishohor Halishohor

16.
Distribution among sites (Cont.)
16
Chwakbazar
Halishohor
CEPZ
New Market
Agrabad
Anderkilla
Chandgaon
Prabortok
Circle
Fig: Distributed Sites are connected with each Other where each of them
has their own data

17.
Data Distribution techniques
 The data was distributed among the
sites based on horizontal
fragmentation technique.
 In SQL we are using SELECT
operation for horizontal fragmentation
of data. We did also same things here.
 We have used some simple
predicates for fragmentation with
SELECT operation for fragmentation.
17

18.
Data Distribution techniques
(Cont.)
 SELECT * FROM
distributed_blood_bank.donor
where
sub_area='Chwakbazar’
 which selects all the table values within
that sub_area.
 We just put that values into site located
at Chwakbazar.
 We will use separate sub_area values
for different sites and after that we will
put them into their related sites.
18

19.
Data Distribution techniques
(Cont.)
 The result of previous shown query is
given below:
 By this way we have also selected our
other table values.
19

20.
Query Statistics Collection
 We have assumed some queries. Based
upon that we’ll make decision for vertical
fragmentation.
 Suppose we have some applications in
our site which generate quires in
following areas:
 Donor
◦ Find d_name,blood_group,phone via
sub_area
◦ Update donor details
◦ Etc
20

21.
Query Statistics Collection
(Cont.)
 Branch
◦ Find branch_name,address phone via
sub_area
 Blood_Request
◦ Find
Name,address,hospital,blood_group,blood_a
mount,phone via branch_id
◦ Find
Name,hospital,blood_group,blood_amount,d
elivery_confirmation via branch_id
◦ Etc.
21

22.
Query Statistics Collection
(Cont.)
 Blood
◦ Find donor_id,blood_amount via
branch_id
◦ Update donor_id,blood_amount via
branch_id
◦ Find Total_blood_amount_in_branch via
branch_id
◦ Find
donor_id,paid_amount,blood_amount via
branch_id
22

23.
Query Statistics Collection
(Cont.)
 Employee
◦ Find
emp_id,emp_name,emp_address_emp_role,emp
_sal,phone,email via branch_id
◦ Find emp_id,emp_name,
emp_role,emp_sal,phone via branch_id
◦ Find emp_id,emp_name, emp_role,emp_sal via
branch_id
◦ Find emp_id, emp_sal, via branch_id
◦ Update
emp_id,emp_name,emp_address_emp_role,emp
_sal,phone via branch_id
◦ Etc.
23

24.
Query Statistics Collection
(Cont.)
 These are our assumed quires that
can be generated from any of the 8
sites because all the sites have the
same table which is necessary for
every site operation.
24

25.
Vertical Fragmentation based on
Query statistics
 We have fragmented the database vertically
based on the query written above.
 Fragments of Donor
◦ Donor_fragment1(d_id,d_name,address,blood_g
roup,phone)
◦ Donor_fragment1(d_id,br_id,area,sub_area,natio
nal_id,email)
 Fragments of Blood_request
◦ Bloodrequest_frg1(name,address,hospital,blood_
gruop,blood_amount,phone)
◦ Bloodrequest_frg2(id,name,delivery_confirmation
,email)
25

26.
Vertical Fragmentation based on
Query statistics (Cont.)
 Fragments of Employee
◦ Employee_frag_1(emp_id,emp_name,em
p_address,emp_role,emp_sal,phone,emai
l)
◦ Employee_frag_2(emp_id,branch_id,emp
_area)
26

27.
Testing Query Response Time
Using Centralized and
Distributed Model
 All models were developed by using
My-SQL web-based version integrated
on Xampp 1.7.7 server.
 Everything were tested by using My-
SQL server version.
27

28.
Query Hit & Query Miss
Statistics
 Sometimes it is necessary to view the
blood availability around the area.
 At that time only query miss will be
occurred that means global query will
be generated.
 This possibility of query hit & query
miss is shown in a chart in next slide
28

29.
Query Hit & Query Miss
Statistics (Cont.)
29
0
20
40
60
80
100
120
Query Hit
Query Miss
Figure: Query hit & Query miss statistics

30.
Minimum Response Time at
Centralized Database &
Distributed Database
 Minimum Response Time is defined
as the minimum time required for
responding to a query in the
Centralized Database or in the local
site in case of distributed database.
 Minimum Response time of
centralized is more than the
distributed database here
30

31.
Minimum Response Time at
Centralized Database &
Distributed Database (Cont.)
31
0
5
10
15
20
25
30
Centralized
Distributed
Figure: Minimum Response Time at Centralized Database &
Distributed Database

32.
Maximum Response Time at
Centralized Database &
Distributed Database
 Maximum Response Time is defined as
the maximum time required for
responding to a query in the Centralized
Database
 Or in the local site in case of distributed
database (when data is not reside in
local site).
 Maximum Response time of centralized
is slightly more than the distributed
database here.
32

33.
Maximum Response Time at
Centralized Database &
Distributed Database (Cont.)
33
0
5
10
15
20
25
30
Centralized
Distributed
Figure: Maximum Response Time at Centralized Database &
Distributed Database

34.
Average Response Time at
Centralized Database &
Distributed Database
 Average Response Time is defined as
the average time required for
responding to a query in the
Centralized Database or in the local
site in case of distributed.
34

35.
Average Response Time at
Centralized Database &
Distributed Database
35
0
5
10
15
20
25
30
Centralized
Distributed
Figure: Average Response Time at Centralized Database &
Distributed Database

36.
Conclusion
 The purpose of conducting this study
& doing project is to know the
conversion of Centralized DB to
Distributed DB
 And its impact on the response time
while moving from centralized to
distributed databases.
 Distributed databases have many
aspects and every organization has
certain preferences.
36

37.
Conclusion (Cont.)
 For this sector, the response time is
prioritized.
 Our experiment showed that the
average response time is decreased if
we switch from centralized database
to distributed database.
 In distribution we put the data to
the site where it is used most
frequently.
37

38.
Conclusion (Cont.)
 This locality of data reduces the
response time.
 In the distributed database, data is
fragmented. These fragments are
short compared to the full database
(centralized database contains
maximum columns).
38

39.
Conclusion (Cont.)
 However, when we need data from
multiple sites for a query (report
queries), the response time is
increased.
 Accessing data from multiple remote
sites and then joining those takes long
time.
 But in the centralized database since
data is at one place so, it is easy and
fast to search it.
39

40.
Conclusion (Cont.)
 Experiment results showed that the
response time is decreased in
distributed databases.
 Due to fragmentation data set for
single site contains less records than
centralized database, so response
time is less.
40

41.
Any Question??
Fell free to ask me
I would love to ans. Them.
41

42.
Thank You All
42