When establishing the system for controlling and administering the database environment, the general responsibilities of the DBA include
establishing database procedures and standards;
assisting in database design;
educating users;
selecting applications suitable for the database system;
maintaining database documentation; and
administering the database.
This document covers the following topics:
Standards and procedures are more effectively established as part of the initial planning, rather than later after problems have arisen. This section discusses the general points to consider when defining procedures and standards.
Procedures for effective control of the database environment should be established at the very beginning of the organization's use of a DBMS.
These procedures are outlined elsewhere in this documentation. Although many installations adopt the use of a DBMS in a short space of time, the planning aspect of the whole process (particularly in the design and implementation of administration and control procedures) must not be sacrificed just to enable startup in a minimum period of time.
Obviously, the implementation of these procedures will involve much discussion, both within IS and with the users (particularly in regard to what is acceptable, cost effective, etc.), and the first application of DBMS technology at a particular site may see a parallel development of the DBA procedures. However, it is essential that the organization's IS and user management be made aware of the need for such procedures, and (after due discussion) accept them.
Who decides just how secure a data item must be? The users are too close and too personally involved in the matter. The analysts may miss the organization-wide implications of such a decision. The final arbitrator must be the DBA. After all, the DBA is the one who must monitor the procedures and correct the results of violations.
The DBA must establish standard recovery procedures for use at the installation. These procedures must be adequate for each application before it is implemented. Different approaches (file save/restore instead of database save/restore, for example) must be chosen; the DBA should participate in any decisions made in this area.
Much of this documentation attempts to define guidelines for a database environment. Not all of the topics discussed will be relevant to a particular installation. Whether a guideline becomes a standard or not depends mostly on the size and diversity of the user/developer organization. Small, homogeneous user groups usually have good communication and do not require an extensive, rigidly defined set of rules.
On the other hand, larger user groups comprising various areas or geographic locations usually lack the contact necessary for proper controls; such groups may require "rules of the road" to avoid incongruous data structures or program development. No one likes rules, unless they see an obvious benefit in them. And standards are generally rules. So here are some "guidelines" to consider when defining standards:
Keep standards brief, clear, and to a minimum. However, if a standard could be seen as arbitrary, give a brief justification. For example, a standard covering the use of temporary datasets in the Adabas environment might require the following:
Using Temporary Datasets To ensure that your job is recovery-/restart-capable, always catalog temporary datasets. The Adabas database uses the Adabas Recovery Aid feature to automatically restore and restart the nucleus, rebuild failed job streams, and resubmit the rebuilt job. If temporary datasets are not cataloged, the Recovery Aid cannot include them in the rebuilt job stream.
Review the standards at least as often as you add to them, and remove or revise outdated ones. Provide an overview of changed/deleted/added standards to users.
If a particular control or administration procedure is deemed to be necessary at a particular site, it should be defined as a standard.
The maintenance of database documentation should be treated as a natural part of the application development process. For this reason, the DBA will need to become involved in the development of each new system that uses the DBMS. The data dictionary is a major tool in this documentation process.
With a wide knowledge of current database applications, future plans, and responsibility for the integrity of the database, the DBA should be involved in the design of the data validation procedures inherent in each system that inputs data to the database. In this way, the DBA can ensure that the quality of the data in the database is maintained at an acceptable level. The Data Dictionary may also be used to document such validation requirements.
The assistance that the DBA provides to the project team in this area is best illustrated by the following questions:
Is the logical design a true statement of the problem? A logical database design should not embody any limitations/features of a particular DBMS;
Does the physical design cause any processing disadvantages? A project team will work in isolation on a specific problem unless otherwise directed;
What about the future? Is the design flexible? The DBA and the organization will have to live with this design for some time.
As an independent function, the DBA is the only person who can provide such an objective view of the resulting database design. In some cases, the DBA may even become involved in the design process itself, and at such times will ensure that the right answers can be supplied to these questions.
Users can be oversold on the benefits which are to be derived from DBMS technology, despite the efforts of the system analyst or DP resources manager. Such topics as "flexibility", "program/data independence" and "data availability" can lead to unjustified expectations and give rise to a false sense of "creative freedom".
It is therefore the responsibility of the DBA to ensure that the user appreciates the problems as well as the benefits associated with working in a database environment. The DBA should devise, select and provide introductory training for the user that meets these needs.
When an installation acquires a DBMS, it is only natural that analysts and programmers will be eager to use it. Every new application suddenly seems to require DBMS technology. Someone has to take a firm grasp of this situation and control the selection of applications that truly are suitable for DBMS technology. That person is the DBA.
The DBA should produce a list of the "pros and cons" of using the DBMS for each application. This should be done at the feasibility study stage (that is, before too much time and money is spent), before the system is acquired. The analysis of the proposed application should involve such considerations as:
Does the application need DBMS?
Will the application disturb our existing environment?
Will the proposed system be flexible?
Will it be cost effective?
Has the problem that led to proposal of the application been fully analyzed?
The DBA, as a center of competence in database matters, is thus the ideal person to oversee the selection of new database projects.
The following is a summary of the functions for which the DBA is generally responsible:
| Designing | Standard data definitions Physical database Security, privacy and recovery procedures Support software (if not acquired with the DBMS package) |
| Selecting | Database management system Performance measurement tools Tuning aids |
| Predicting | Effect of changing volumes/new applications |
| Deciding | Search strategies Access methods Database design Record relationships Rules of use of database |
| Training | Analysts and programmers: in database techniques Operators: in database operating procedures |
| Enforcing | Standards for design, documentation, etc. Quality control Access rules |
| Organizing/Administering | Data dictionary creation/maintenance File conversions Integrity, security and recovery benchmarks Acceptance tests Communication of changes to the users |
| Measuring | Hardware performance Software performance Database usage statistics |
| Tuning | System performance |
