Meeting Users' Needs

No two database systems are the same. Some may be composed of data that is accessed only through canned programs that are fully optimized. Others may be decision support applications that see a lot of nonstructured, ad hoc query activity. Others may have data that remains in the system for years. Still others may move data through the system in a day and then throw it away. These different modes of use and purpose must be understood by the DBA if he is to manage the entire system.

The purpose of the database is to make the information contained in the database tables accessible in some form to the users. The most controlled access is a system of structured access in which all data flows through well-defined programs. This is the typical form of access in most current database applications designed for end users. Essentially an extension of the "big iron" philosophy, it stresses centralized control over the data resources.

At the other end of the spectrum is a more free form type of access in which users execute many ad hoc queries. As users become more empowered by the client/server paradigm, DBAs can expect to field more requests for this type of access, with the opportunities and pitfalls that accompany it.

Additionally, different types of users may view a database management system in completely different ways. The DBA has to understand all of their uses and needs.

Understanding the Needs of your Users

Different levels of database users can expect to view the database in different ways: users at different levels need different information about what is going on inside the system. Of course, the lines between different types of users are fuzzy at best. It's fun to generalize, but it's also impossible. You are dealing with people, and they will tend to distribute themselves all over the spectrum. I'm certain you will recognize most of your users somewhere in this list.

End Users

The database is usually invisible to the end user. They simply do not see the database: they see the applications. In most cases, the end users do not even know that the application is based upon a database. For them, the whole system, from hardware to application programs, is known simply as "the computer." They do not make the differentiation between hardware, software, and applications.

The end user mostly runs "canned" programs. These programs were either bought from others or developed by other users, the programmers. End users want results, answers, numbers. Give results to the end users and they'll be happy.

End users also want fast response times. The system is not only important to them, often it is the major tool that they use to do their job. If a query that has been coming back in three seconds starts to take six seconds, expect to hear from the users. They are your first line of alert to problems.

Advanced Users

Advanced users are at a point somewhere between end users and programmers. They still get their information from the existing applications, but they have discovered that much more information exists. They will try to get to it either by having programmers write them hundreds of reports or by pushing for client/server tools that let them use the database's data from within their comfortable, PC-based tools. In the absence of client/server orientation, these advanced users may be intercepting print spool files from the print queue or requesting that their reports be formulated to fit their spreadsheets. These advanced users still probably have little or no knowledge of the underlying database.

Advanced users in client/server environments usually learn SQL because their spreadsheets or other client programs accept SQL commands. These users learn a subset of the database's structure and often use tools such as advanced 4GLs and data import/export tools to integrate their PCs with the database. These advanced users often use third-party tools as well.

Programmers

Programmers can run the gamut from inexperienced to very sophisticated. Either type can make incredible demands upon the DBA. Given exposure to the database, the novice programmers usually learn the system quickly. Using programmatic interfaces like ESQL/C, programmers soon begin to view the database as just another function call. As long as they can get the results they are seeking, they do not care much about the inner workings of the database. They tend to view the database as yet another "black box."

The sophisticated programmers often know as much about what's going on "under the hood" as the DBA does. At least, they can seem to know as much. If their knowledge transfers to the overall workings of the database system, these gurus can become quite a resource. Often, however, their in-depth knowledge is restricted in breadth. Many times, they will be generalizing from other databases or from generic experience and will engage you for hours in esoteric discussion of paging algorithms. They can easily suffer from a typical DBA problem, that is, focusing too narrowly in one area. It is possible to write tight, high-performance code that pushes the database to its absolute limits of performance. It's also possible that this same code can bring the system to its knees if the developer has neglected to see how the code interacts with other programs.

Executives

Executives have their own set of needs in understanding the database. Dealing with executives requires the best technical expertise that the DBA can bring to bear, but it also requires at least an awareness of the politics of the situation.

Depending upon the background of the executive, their needs can be met from anything from a confidently delivered "I've got it handled" to a detailed technical explanation. Know which to use and when.

Remember that executives have the same goals you have. They want to accomplish a task efficiently and with the least effort and expenditure. If you can communicate your needs and requests to them in such a way that they can relate it to the overall needs of the organization, you will receive more satisfactory responses.

The quality movement is currently very big in corporate environments. It's been my experience that once companies get on the total quality bandwagon, you can use the jargon and techniques of your particular quality dialect to your advantage. If you phrase your requests and suggestions using the approved quality dialect you'll find that most executives will be more receptive. If you're asking for additional disk space to make your administration job easier, you may or may not be listened to. If you need the same disk space to improve the process of retaining information and making it available to your internal customers on a more timely basis, you'll have a lot better chance of getting your disks. You've requested the same disks in both cases, but the second request is phrased in such a way that only opponents of quality could refuse.

A more recent bandwagon that just everybody is jumping onto is the Y2K problem, caused by legacy code that does not handle the proper conversion from dates in the 1900's to dates in the 2000's. A lesser-understood part of the Y2K problem is the inability of much software to decide whether or not the year 2000 is a leap year (it is). Recently, it seems that everyone has something to say about the Y2K problem, and DBAs are finding that they can couch many of their upgrade requests in terms of "Y2K remediation" and get more support than if they phrased it in other terms.

Even the TV preachers are getting into the Y2K game. I've heard claims that the year 2000 will be the date of Armageddon because of all of the computer failures that will occur. These prophets of doom seem to appear at every century mark, predicting the end of the world. They are now urging people to hoarde food and weapons in preparation for the Y2K bug. It turns out that what all of us software people thought was only sloppy programming was actually the work of the devil. So, if you're involved in Y2K remediation efforts, you can feel secure in knowing that you're doing God's work. Hey, I don't mind. Just don't let them convince you to take vows of chastity or poverty.

DBAs

The DBA needs to be able to understand the mechanics at the lowest level of database operations. DBAs also need to have an overall picture of the operation of the system as a synergistic whole. Knowledge of the low-level operations are critical when debugging the system, as problems often seem to revolve around just one item that refuses to work properly. This in-depth knowledge of the architecture also helps the DBA deal with his own system gurus and with the Informix helpline personnel.

If nothing else, the DBA needs to maintain professional control over database operations. The ability to explain, argue fine points, and to solve unusual problems can do nothing but enhance the DBA's professional stature.

Being able to see the overall picture is at least as important. In many organizations, database design, applications programming, and providing ad hoc data to advanced users are spread across several departments and across many individuals. The DBA has to be able to integrate the different pieces and make them work together in an efficient whole.

Often, there is nobody else with a sufficiently broad job description to handle this most important task.