Database Reference
In-Depth Information
data in one place. This is a major difference you encounter while designing and
implementing a distributed system.
Therefore, your design should include considerations for placement of data at
the various sites. How can you make the design and implementation decisions on
what parts of data must be kept at which points? Of course, you need to find out
the usage patterns and match them up with data content. This expands the scope of
your requirements definition phase. In that phase, you must gather details to address
two basic issues:
•
How to fragment the database
•
How to allocate fragments to sites
We will address these issues for a relational data model. Let us list a
few suggestions on these issues and indicate some design and implementation
steps:
•
On the basis of the requirement definition, proceed through the design phase
and come up with a global schema for the entire database. This schema will
include all the relations.
•
Next comes the decision point on how to divide the database and then which
segments to store where. Once you are able to determine the location of parts
of the data, then the local schema at each site will represent the part of the data
stored at that site.
•
Consider each relation for the possibility of fragmenting it horizontally or
vertically.
•
When you are examining a potential subset for fragmentation, evaluate data
sharing as it applies to the subset. Determine which site is likely to use the
subset most. If you can establish the site that is expected to use the subset most,
then assign the fragment to that site.
•
Sometimes a number of sites are likely to use a subset or a complete relation
with almost equal frequency. If so, consider full or partial replication and place
copies at all such sites.
•
Decisions on fragmentation and replication are never easy and clear-cut.
That is why a lot of preliminary work must be done in the requirements defi-
nition phase itself. Analysts and designers must “know” their data extremely
well.
•
Remember that usage access patterns change over time. Business conditions
change. New applications are added. The initial set of applications is enhanced.
So the data allocation plan must be reviewed periodically after deployment and
adjusted as necessary.
•
Another key factor in the allocation plan is the placement and management of
the global system catalog. Consider alternatives.
Figure 18-14 presents an example of a data allocation scheme. Note how the data-
base is fragmented and fragments are placed at different sites. Also note the repli-
cated copies stored at different sites.
Search WWH ::
Custom Search