| Craig S. Mullins
The DBA Corner
by Craig S. Mullins
What is a DBA?
Every organization that manages data using a database management system (DBMS) requires a database administration group to ensure the effective use and deployment of the company’s databases. And since most modern organizations of every size use a DBMS, the need for database administrators (DBAs) is greater today than ever before. However, the discipline of database administration is not well understood or universally practiced in a coherent and easily replicated manner.
There is a frequently repeated story about database administration that helps to underscore both the necessity for DBA and lack of understanding of the DBA function. It goes something like this:
This is a sad, but too often true commentary on the state of database administration in many organizations. Frequently the DBA is viewed as a guru or magician who uses tricks to make databases and systems operate efficiently. DBMS software is so complex these days that very few people understand more than just the basics (like SQL). But DBAs understand the complexities of the DBMS, making them a valuable resource. Indeed, sometimes the only source of database management and development knowledge within the organization is the DBA.
Another frequent criticism of the DBA staff is that they can be difficult to deal with. Sometimes viewed as a prima donna, DBAs can be curmudgeons who have vast technical knowledge but limited people skills. Just about every database programmer has their favorite 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 manual.” DBAs simply do not have a “warm and fuzzy” image. This probably 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.
The fact that DBAs often must sit down and work things through on their own can be a mitigating factor in this poor reputation. Many database problems require periods of quiet reflection and analysis to resolve. So DBAs do not generally like to be disturbed. But even though many problems will require solitude, there are many other problems that require a whole team to resolve. And due to the vast knowledge most DBAs possess, their quiet time is usually less than quiet; constant interruptions to answer questions and solve problems is a daily fact of life.
DBAs should not be encouraged to be anti-social. In fact, DBAs should be trained to acquire exceptional communication skills. Data is the lifeblood of computerized applications. Application programs are developed to read and write data, analyze data, move data, perform calculations using data, modify data, and so on. Without data there would be nothing for the programs to do. The DBA is at the center of the development life cycle – ensuring that application programs have efficient, accurate access to the corporation’s data. As such, DBAs frequently interface with many different types of people: technicians, programmers, end users, customers, and executives. However, many DBAs are so caught up in the minutiae of the inner-workings of the DBMS that they never develop the skills required to relate appropriately with their co-workers and customers.
But we have not yet answered the question that is the title of this article: what is a DBA? The short answer to that question is simple: a DBA is the information technician responsible for ensuring the ongoing operational functionality and efficiency of an organization’s databases and the applications that access those databases.
But the long answer to that question requires a book to answer—I have written such a book titled Database Administration: Practices and Procedures, to be published in June 2002 by Addison Wesley (ISBN: 0-201-74129-6). Click here for additional details – and keep reading this column in Database Trends and Applications for more details on the management discipline of database administration.
Trends and Applications, April 2002.
© 2002 Craig S. Mullins, All rights reserved.