Database Management Systems - selection factors

Factors:

data dictionary

Catalog of data about the database which records the types of data stored, names and formats of data variables, and relationships. This also records the links and functions that may impact on a particular data variable, so that if a change is made to the name or format of a data variable, a listing of the programs or tables that use it are more readily available. Data dictionaries may be available to the user and may be automatically or manually updated. Automatic updates are preferable but are found on more expensive DBMS implementations.
(back to top)

 

data recovery

If the database server should fail and the database become corrupted or out of date, a database recovery will need to be performed. This process can be more involved that simply loading a backup copy; for databases which are updated frequently, the state of the database at the time of the failure must be reconstructed. Each transaction that occurs to the databases is recorded in a continuously running log file. Some transactions must occure nearly simultaneously; other must occur in a sequence in order to update the database properly. The "before-image" and "after-image" of the database is recorded for each transaction. The reconstruction process occurs in two steps. First, the backup copy is loaded and then the log file is used to reconstruct the state of the database. This is done by either the "rollforward" process of updating the database from the point of the last backup or the "rollback" process of undoing erroneous or partially performed transactions until the database is complete, and then restarting transactions again.
(back to top)

 

replicated databases

It may be advantageous to have copies of data. For example, a lab may want to have a copy of a database with limited fields available on the internet or for downloading to laptops. A more complete version will exist on the NT server, a "master" copy. Reading data from all these copies is not difficult, but coordinating the updating of all copies to make sure that all are current presents a challenge. A DBMS should have hav a distributed transaction manager (DTM) that will help ease this burden by providing customizable procedures to automate this multiple updating process.
(back to top)

 

resource locking

While most of SERC's data is not accessed by multiple users at the same time, there may be some databases in the future that may need to accept inputs from different sources simultaneously. Examples of this might be the Invasion lab's Coast Guard data, SERC bibliographic data and abstracts, or a listing of SERC's data assets. In order to prevent conflicts as to which change takes precedence, DBMS can lock resources, or prevent a change to take place while another is occurring, resulting in a conflict message sent to the end user. Locks can be exclusive, preventing reading and writing of data, or shared, in which another user can only read data. DBMS can differ in the levels of locking, ranging from the particular data record, the data table, or to the entire database. The small scale locking of particular records can result in fewer conflicts but requires more overhead in time and resources from the DBMS. Larger scale locking can give more conflict messages but is easier to administer.
(back to top)

 

security

Although little of SERC's research information is of a sensitive nature (such as personal or financial information), security can afford protection against mistaken deletions and erroneous edits of information. DBMS offer protection through different means. Subject-oriented security defines the privileges of users, programs, and routines to perform a certain task. Object-oriented security defines privileges in terms of the data structure: a row, table or database can accept operations from a particular class of users or programs. Some DBMS define security from both the subject and the object points of view. Another method of providing protection is to provide constraints via programmable exits. This method provides triggers that are called when a user performs a certain action. For example, if a user defined as an "intern" tries to delete a record, then the trigger might refuse to perform the action and display a message to consult the head lab tech for further help. DBMS can differ in the ways they implement security and the level to which they apply it. Providing security on a record level can demand considerable processor time and storage space; at the other end of the scale providing permissions at the level of databases may be quick and convenient but not flexible enough to accommodate differing levels of authority.
(back to top)