Database Reference
In-Depth Information
Configuration Control
After a database and its applications have been implemented, changes in requirements are
inevitable, as described in Chapter 8. Such changes can arise from new needs, from changes
in the business environment, from changes in policy, and from changes in business pro-
cesses that evolve with system use. When changes to requirements necessitate changes to
the database structure, great care must be used because changes to the database structure
seldom involve just one application.
Hence, effective database administration includes procedures and policies by which
users can register their needs for changes, the entire database community can discuss the
impacts of the changes, and a global decision can be made whether to implement proposed
changes. Because of the size and complexity of a database and its applications, changes
sometimes have unexpected results. Thus, the DBA must be prepared to repair the database
and to gather sufficient information to diagnose and correct the problem that caused the
damage. The database is most vulnerable to failure after its structure has been changed.
Documentation
The DBA's final responsibility in managing the database structure is documentation. It is
extremely important to know what changes have been made, how they were made, and when
they were made. A change in the database structure may cause an error that is not revealed for
six months; without proper documentation of the change, diagnosing the problem is next to
impossible. Considerable work may be required to identify the point at which certain symptoms
first appeared. For this reason, it also is important to maintain a record of the test procedures and
test runs made to verify a change. If standardized test procedures, test forms, and recordkeeping
methods are used, recording the test results does not have to be time consuming.
Although maintaining documentation is tedious and unfulfilling, the effort pays off when
disaster strikes and the documentation is the difference between a quick problem solution
and a confused muddle of activity. Today, several products are emerging that ease the burden
of documentation. Many CASE tools, for example, can be used to document logical database
designs. Version-control software can be used to track changes. Data dictionaries provide
reports and other outputs that present database data structures.
Another reason for carefully documenting changes in the database structure is so that
historical data are used properly. If, for example, marketing wants to analyze three-year-old
sales data that have been in the archives for two years, it will be necessary to know what struc-
ture was current at the time the data were last active. Records that show the changes in the
structure can be used to answer that question. A similar situation arises when a six-month-old
backup copy of data must be used to repair a damaged database (although this should not
happen, it sometimes does). The backup copy can be used to reconstruct the database to the
state it was in at the time of the backup. Then transactions and structural changes can be
made in chronological order to restore the database to its current state. Figure 9-2 summarizes
the DBA's responsibilities for managing the database structure.
Concurrency control measures are taken to ensure that one user's work does not inappropri-
ately influence another user's work. In some cases, these measures ensure that a user gets the
same result when processing with other users that he or she would have received if processing
alone. In other cases, it means that the user's work is influenced by other users, but in an antic-
ipated way. For example, in an order entry system, a user should be able to enter an order and
get the same result, regardless of whether there are no other users or hundreds of other users.
In contrast, a user who is printing a report of the most current inventory status may want to
obtain in-process data changes from other users, even if there is a danger that those changes
may later be cancelled.
Unfortunately, no concurrency control technique or mechanism is ideal for every cir-
cumstance. All involve trade-offs. For example, a program can obtain very strict concurrency
control by locking the entire database, but no other programs will be able to do anything
while it runs. This is strict protection, but at a high cost. As you will see, other measures are
Search WWH ::
Custom Search