Charting the Evolution from DBA to e-DBA

Internet technologies are changing the way we do business. The transformation of businesses to e-businesses impacts the disciplines of data management and database administration. New skills and requirements cause the DBA to morph into an eDBA-- a DBA who manages e-business data.

An e-business never closes. Customers expect full functionality on the Web regardless of the time of day. An e-business must be prepared to engage with customers at any time or risk losing business to a company whose Web site is more accessible. Some studies show that if a Web user clicks his mouse and does not receive a transmission back within seven seconds, he will abandon that request and go somewhere else.

As e-businesses integrate their Web presence with traditional IT services such as database management systems, it creates heightened expectations for data availability. Downtime and outages are the enemy of availability. There are two general causes of application downtime: planned outages and unplanned outages.

Most outages are planned, caused by the need to apply system maintenance or make changes to the application, database, or software components. Some studies show that as much as 70 percent of application downtime is caused by planned outages to the system, with only 30 percent due to unplanned outages.

Because planned outages occur more frequently, they will have a greater impact on availability than unplanned outages. How can an e-DBA reduce downtime associated with planned outages? The best way to reduce downtime is to avoid it. High-speed database utilities, concurrent reorganization products, and on-the-fly tuning techniques should be used by eDBAs to enhance data availability. Another way to minimize downtime is to automate routine maintenance tasks.

Some e-businesses are encountering the DBMS for the first time, resulting in many rookie mistakes. Novice database developers frequently begin with the quick-and-dirty approach to database implementation. Novices do not have experience with databases and data requirements gathering, so they attempt to design databases like the flat files they are accustomed to using. This is a major mistake, as anyone using this approach quickly finds out once the database and application move to production. At best, performance will suffer, and data may not be as readily available as required. At worst, data integrity problems may arise, rendering the entire application unusable. A relational database design cannot be thrown together quickly.

A practiced and formal approach to gathering data requirements and modeling that data is required. This modeling effort requires that the naming entities and data elements follow an established and standard naming convention. Failure to apply standard names will result in the creation of databases that are difficult to use, because no one knows their actual contents.

Data modeling also requires the collection of data types and lengths, domains (valid values), relationships, anticipated cardinality (number of instances), and constraints (mandatory, optional, unique). Once collected, and the business usage of the data is known, a normalization process is applied to the data model.

Normalization is an iterative process that I will not cover in detail here. A normalized data model reduces data redundancy and inconsistencies by ensuring that the data elements are designed appropriately.

There are other challenges for e-DBAs, such as dealing with new technologies (e.g. XML), task automation, multimedia objects, and dealing with procedural database objects. But the biggest problems invariably involve getting the database to work efficiently and effectively under harsh requirements. When an e-DBA gets the availability and design issues licked, he is more than half-way to the finish line.