Version 8.1.4
 —  DBA Tasks  —

Establishing Database Control and Administration

When establishing the system for controlling and administering the database environment, the general responsibilities of the DBA include

This document covers the following topics:


Establishing Database Procedures and Standards

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.

Database Procedures

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.

Data Security Procedures

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.

Planning Recovery Procedures

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.

Setting Standards

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 some rules 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:

Top of page

Maintaining Procedures and Standards

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.

Top of page

Assisting in Database Design

The assistance that the DBA provides to the project team in this area is best illustrated by the following questions:

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.

Top of page

Educating Users

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.

Top of page

Selecting Applications Suitable for the Database System

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:

The DBA, as a center of competence in database matters, is thus the ideal person to oversee the selection of new database projects.

Top of page

DBA Function Summary

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

Top of page