The Classic Role of the DBA

 <  Day Day Up  >  

Just about every database developer has his or her favorite curmudgeon DBA story. You know, those famous anecdotes that begin with "I have a problem " and end with " and then he told me to stop bothering him and read the (expletive-deleted) manual." DBAs do not have a "warm and fuzzy" image. This image has more to do with the nature and scope of the job than anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization.

To make matters worse , the role of the DBA has expanded over the years . In the prerelational days, both database design and data access were complex. Programmers were required to explicitly code program logic to navigate through the database and access data. Typically, the prerelational DBA was assigned the task of designing the hierarchic or network database design. This process usually consisted of both logical and physical database design, although it was not always recognized as such at the time. After the database was planned, designed, and implemented, and the DBA created backup and recovery jobs, little more than space management and reorganization were required. Keep in mind that I don't want to belittle these tasks. The prerelational DBMS products such as IMS and IDMS required the DBA to run a complex series of utility programs to perform backup, recovery, and reorganization. These tasks consumed a large amount of time, energy, and effort.

As relational products displaced older DBMS products, the role of the DBA expanded. Of course, DBAs still designed databases, but increasingly these databases were generated from logical data models created by data administration staffs. The up-front effort in designing the physical database was reduced but not eliminated. Relational design still required physical implementation decisions such as indexing, denormalization, and partitioning schemes. Instead of merely concerning themselves with physical implementation and administration issues, however, DBAs found that they were becoming more intimately involved with procedural data access.

The nature of the relational model requires additional involvement during the design of data access routines. No longer are programmers navigating through the data; the DBMS is. Optimizer technology embedded into the DBMS is responsible for creating the access paths to the data. The optimization choices must be reviewed by the DBA. Program and SQL design reviews are now a vital component of the DBA's job. Furthermore, the DBA must take on additional monitoring and tuning responsibilities. Backup, recovery, and reorganization are just a starting point. Now, DBAs use EXPLAIN , performance monitors , and SQL analysis tools to administer applications proactively.

Often, DBAs are not adequately trained in these areas, though. Programming is a distinctly different skill than creating well-designed relational databases. DBAs, more often than not, need to be able to understand application logic and programming techniques to succeed as a DBA in a relational world.

 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net