This document covers the following topics:
Everyone involved with the database must apply a uniform methodology and standard procedure for data definition (this overlaps with the task of establishing the data dictionary). The DBA must formulate, establish, and maintain a consistent set of controls and standards in this area. These standards must be planned in conjunction with all affected parties: users, IS operations, applications designers, and the DBMS vendor.
Ultimately, one user department must be given the sole responsibility for maintaining a subset of the data in the database, ensuring its currency and integrity relative to the remainder of the database. The decision as to which user this will be is for the DBA to make. It is not only necessary to decide who shall be responsible; this decision must be made known to (and agreed by) all the other affected users. This is where the DBA's diplomacy will be called into play. Although it is natural that user A is responsible now, in a years time, when the use of the database has changed, it may be that user B is now the appropriate person to accept responsibility for some or all of the data.
The selection of applications for database implementation should be made by a committee, chaired by the DBA. The organization should decide whether or not the users should participate in this process. As a general rule, the user will only be interested in the cost, facilities, feasibility and extensibility of the system, if the database design team has performed it's data gathering and analysis tasks adequately. The DBA must be an impartial judge with the DBA's own independent advisers on the various topics which are likely to be discussed.
As a center of competence, the DBA and the related staff should be in a position to advise on systems development (but only insofar as to whether the DBMS should be used or not)-advice that can only be given if the DBA is serving a full and useful role within the database environment and has the wholehearted support of all interested parties.
As far as involvement in systems development is concerned, the DBA should be responsible for the process of defining and describing new data entities and relationships, using uniform data definition procedures. the DBA's is the task of maintaining records of the organization's "logical database" and controlling what part of it is and is not implemented.
The DBA should be responsible for establishing and enforcing uniform procedures for describing and defining the attributes of the data entities in the database. The DBA should also introduce standards for editing and validation of the input to the database.
Besides ensuring that the minimum criteria for data quality are met, it is important that the quality of the input be uniform so that the database remains as consistent as is practical.
The data dictionary can serve as a tool for the recording and implementation of these edit and validation rules.
Two types of data should be considered:
| Private data | That is, data with a defined, single "owner". Here, the DBA can only insist that certain satisfactory data validation procedures and reasonability checks are performed; |
| Common data | That is, common-usage data. Unless a particular user can be identified who should have control and is prepared to accept that responsibility, the DBA should accept and exercise the appropriate level of control over the quality of such data. |
The majority of the documentation requirements for the database environment are supportable by the data dictionary. The data dictionary is one of the DBA's most important tools. It must be based upon a set of uniform data definition procedures as indicated above. The dictionary should record logical data formats and relationships and be broken down into three main areas:
| Conceptual | the data and existing natural relationships |
| Usage | how it is used now |
| Implementation | how it is currently stored in the database |
Standards are required relating to the use and/or interpretation of specific data entities.
The data dictionary should contain
logical data structures;
physical storage structures;
data attributes;
a description of data sources:
Where the data comes from
How it is obtained
How it is edited and validated
accuracy and security requirements:
What are the accuracy requirements?
What are the security requirements?
Who may access each data item?
Who may update each data item?
response requirements: for each application area, what are the retrieval and response requirements?
Database Documentation lists these requirements in more detail. The online capability provided by Predict, the Adabas data dictionary, significantly reduces the effort involved in satisfying documentation requirements.
