Working as a Database Administrator
On the whole, there are some great reasons to become a DBA. The DBA profession is one of the better-paying ones in the field of IT, and is recognized and accepted as one of great importance and responsibility. Managing a company’s data, plus the ability to extract and gather meaningful results and reports from it (thus transforming it from raw data into useful, actionable information), is vital to any organization looking to keep ahead of the competition. That’s why job growth for database administrators is expected to grow much faster than the average for all occupations through 2018.
But a DBA is also a career with a lot of options. Some DBAs focus on very specific aspects of a database, such as logical design and integration with applications; others specialize in performance tuning and backups. Another type of DBA may zero in on data warehousing and data marts
The System DBA
The system DBA is the most common type of DBA, and is therefore sometimes simply referred to as a DBA. This type of DBA is strictly concerned with technical rather than business issues. (The work of aligning a business’s needs with its technical IT capabilities falls to the business or systems analyst, a wholly different role.) The system DBA, then, will primarily be concerned with ensuring that the databases that support the organization’s application systems are running efficiently. He or she will also likely be the one in charge of:
- Periodic database tuning
- Applying database patches and upgrades
- Setting up the operating system environment
- Setting up and checking on backups
The system DBA is therefore truly a generalist, and most DBAs, even specialists, start out in this role because it’s a way to get acquainted with as many aspects of the DBA world as possible.
However, as is true of almost all professions, there is a huge difference between a fresh-out-of-college DBA and a seasoned veteran with 10 years of experience. Especially in large organizations, a more experienced DBA will have the separate title of senior DBA, and may be placed in charge of a team of junior DBAs to oversee and direct the team’s efforts. In this way, the senior DBA is less concerned with day-to-day database-maintenance activities, and will instead be tasked with aligning the team’s efforts with the organization’s strategic goals. He is also likely to be in charge of investigating new technologies and software, and evaluating their potential for inclusion in the organization’s database environment, thus improving efficiency and reducing the organization’s total cost of ownership. All this must be done while managing a team and keeping a close eye on the efforts of the junior DBAs. Senior DBAs thus maintain a fine balance between the technical and business realms. Even though their duties become far less technical than when they were juniors, many a senior DBA is still a techie at heart, which means you may catch one sighing wistfully at the memory of a simpler time when he was a junior DBA, when he could fully immerse himself and get lost in SQL scripts, and database tuning, and table and index creation. Mmm, the nostalgia of the good old days!
The system DBA will frequently be called upon to double up as the system administrator. This is especially true in smaller organizations, where the separate specialized roles may not be so clear-cut. As part of the his role, a DBA needs to be very familiar with the operating system and related setup issues, such as which server the DB runs on, how to allocate and partition
hard disk space, how to ensure optimal use of hardware and network resources, and so on. There is a definite overlap of some of these responsibilities with the systems administrator’s (sysadmin) role, so many organizations simply hire one person to wear both hats. This joint role is then called the systems and database administrator, or just SysDBA for short.
For an aspiring DBA, it makes a lot of sense to learn as much as possible about sysadmin tasks in order to be as marketable as possible. Sometimes the DBA will also be called upon to double up as the systems analyst. Again, this is more common in smaller organizations which, like we have said before, simply do not have the luxury of employing both a DBA and a systems analyst. However, it turns out that this multi-role responsibility is usually very beneficial later in life, as it gives the DBA a good perspective of how his role relates to and meshes with others in IT and the rest of the organization.
We should once again note that the system DBA is usually not concerned with the development of databases, only with their maintenance. The development portion will usually be done by the next type of DBA we will look at.
A database architect is a specialist only involved in the design and development of new databases, not their maintenance, backup, tuning or administration. He works closely with developers, programmers and systems analysts when a new application is created. He needs to understand the business functions or logic being developed, and then translate these into the corresponding database structures in a new DB.
Assume that we are designing a new DB to support the business activities of a commercial bank. The DB architect will first look closely at the data flow and logic diagrams of the new application. He will then work on a database model to accurately reflect the same, and present it to the rest of the development team, especially the programmers. The DB architect will also:
- Be in charge of the effort to separate loans, accounts, investments and customers into separate tables
- Ensure accurate representation of the relationships between various business objects (customers, bank accounts, transactions, loans, etc.),
- Map business rules and restrictions onto the database where applicable (for example ensure all customers must have a Social Security number)
- Create indexes on the various tables and columns to optimize data retrieval and searching
The DBA architect role requires a different skill set from that of the system DBA. Unlike the system DBA, the architect must be able to create database models and work closely as part of a development team to deliver the final application. For very large applications, it is more likely that there will be a DBA architect team than a lone data architect.
Nowadays, only a few organizations regularly design their own software applications; an even tinier percentage do so regularly enough to require a full-time data architect. Instead, what most organizations need is someone to maintain their already-developed databases and applications. Therefore, there are far fewer database architects than system DBAs. Most architects are either individual consultants or are employed by software development firms, where they work mainly on different projects to develop applications and databases specific to certain clients, market segments, or industries. That said, there are some large organizations with significant in-house software design and development needs; such companies can afford to employ full-time database architects.
Data Warehouse Administrator
A data warehouse is a special type of database used for in-depth data analysis that provides a multi-domain insight into an organization’s data. This is usually not easy to grasp for someone who has never interacted with a data warehouse before, so an example may help clarify things.
Take a commercial bank, for example, and think through some of the different software applications in such a bank and the databases that support them. The first one would be the database (and application) that runs the core banking operations, such as keeping records of bank accounts, loans, currency dealings and ATM transactions. A totally different application (and therefore separate database) is the HR and payroll-management system, which is used to keep track of how the bank’s HR department manages its own staff. Yet another database-application combo would be the bank’s own financial accounting system for keeping track of its profitability, business transactions and financial records. This last one is interesting because as a business, the bank needs to operate several bank accounts. These accounts are most likely maintained in its own core banking application, so that the bank is a client in its own software application. (Learn more about data warehouses in Data Warehousing 101.)
This is where the data warehouse administrator comes in. Each of these application-database systems maintains its own independent data, but if we could find a way of dumping all the historical data from all the disparate systems into another database, then we could start to pick up some interesting and hidden trends. Enter the data warehouse. This is a special database into which all the data from the core system, the HR system, the accounting system and many others will periodically be added. That data is then transformed using special extraction, transformation and loading(ETL) tools and procedures in the data warehouse to ensure all the data conforms to a single standard that the data warehouse can upload. Finally, the data warehouse’s in-depth and fine-grained reporting and analysis are used to pick up unknown trends and facts that are only revealed by bringing together data from separate systems.
But by crossing the data from the two systems over a long period, data warehouse administrators can pick out a trend that could be used to determine whether changes are required in the way a company does business, or what avenues a business should be capitalizing on. Data warehouses provide business value by shedding light on trends and analyses that are not only unknown when separate systems are used, but may be unknowable. Management then decides what to do with the valuable information gleaned from the warehouses.
A data warehouse is mostly read-only and needs to be optimized as such, unlike the read-write databases that support the day-to-day transactional application systems. It also calls for someone proficient in the ETL process for that particular RDBMS. Finally, it requires a person who can initiate and exploit the advanced reporting and analysis tools in the data warehouse. Of course, this person will first and foremost be required to have the skills of a normal DBA, then go a bit further and specialize in the particular requirements of a data warehouse. This is akin to a vet or surgeon who first must learn the standard medical course, then narrow her expertise in to a specialized field.
Other Types of DBAs
Although these are the main types of DBAs, there are still more specialized sub-categories.
Some in the profession insist on a special category for the application DBA. This is a sub-type of system DBA who deals only with a single application or group of related applications. This DBA is usually an expert on the database structure (and sometimes business aspects) of a critical application. For example in a bank, an application DBA may be an expert who deals only with the database that runs the core banking application, and does not deal with other systems and databases. In a way, the application DBA’s role may cross over into that of the business or systems analyst.
Another special type of DBA that some differentiate is the performance tuning DBA, or performance analyst. This DBA focuses almost exclusively on enhancing the performance of databases. This involves examining and, if necessary, altering the various parameters that affect database response time and performance: table structures, indexes, disk configuration, server specification, and so on. In fact database performance tuning can be complex and involved enough to be a career in its own right.
What Kind of DBA Do You Want to Be?
Along with the various types of DBAs out there, what a DBA does depends on the size of the organization. Smaller organizations can sometimes only afford one DBA – if they can afford one at all. In that case, a company might outsource a DBA from a third party. Or, the DBA role may be tied up with another role in the IT department, such as the systems or network administrator or even IT manager. Larger companies on the other hand, are more likely to have both the funds and the need for specialist or multiple DBAs. It really depends on the funding available and the organization’s priorities. And, of course, all these options have pros and cons for professional DBAs.