Database Administration Today in Evaluating

Database Administration Today

In evaluating the current field of database administration, the areas of Database Management Systems (DBMS), Database Administrator (DBA) roles and responsibilities, the concepts of database designs, performance of databases, and data integrity and availability are all critical concepts that need to be covered. In addition, database security, so essential for any company to continue operating, as is evidenced by the many breaches of databases today, which happen nearly on a daily basis. The breach at social networking site Twitter is particularly troublesome given the rapid growth of that social platform and the information stored on its servers. Additional areas include database backup and database recovery. Each of these topic areas forms the foundation of a DBAs' many tasks in supporting an organization. The intent of this paper is to provide insights into each of these areas from a DBA standpoint, in terms of managing these areas as strategic concerns relative to the value of data in an organization. Critical success factors essential for the development of effective database management systems (Guynes, Vanecek, 1996) including thorough systems analysis and design, the development of security and fault tolerance plans, and the development of change management programs to ensure departments and employees the systems were created for, in addition to customers external to the company, can effectively use the systems designed. Database security forms the foundation of DBMS best practices (Jajodia, 1996) and also serves as the precursor to Service-oriented Architectures (SOA) and the use of DBMS taxonomies for the creation of Web Services as well based on the XML language protocol (Erickson, Siau, 2008). All of these factors will be taken into account throughout the analysis of the factors presented regarding DBMS operation, optimization, management, security, scalability and future trending relative to SOAs and Web Services-based designs.

Database Management Systems

The evolution of databases from simple hierarchical structures to enterprise-wide DBMS platforms parallels their growth from being purely focused on IT tasks to being entirely focused on business and strategic processes and objectives. In order for this transition to occur, databases had to make the transition away from being purely hierarchical in design and adopt a more relational data structure that treated each data element as a logical, not necessarily, physical element of the database (Greene, 2008). In order for databases to become more aligned with the business needs of companies, the shift from hierarchical to relational and objective-based structures began decades ago and continues today. This allows for databases to be structured so they can also support logical table structures, records definitions and the defining of logical connections across multiple databases regardless of their location.

Corresponding to the growth of relational databases is the increasing sophistication of data modeling (Geiger, 2009) and the continued growth of constraint-based modeling through constraint-based analysis and modeling including the development of optimization routines to ensure high performance queries and related applications (Benedikt, Dong, Libkin, Wong, 1998). The development of query-based database logic in conjunction with constraint-based engines for database application development is leading to the development of configurable Web Services (Firat, Wu, Madnick, 2009).

The variation in data models has progressed rapidly, with the development of multidimensional tables that can pivot data sets to find additional insights not intuitively obvious from looking at the data itself. Multidimensional analysis of data using constraints and rules-based logic is also being applied to the more complex business applications including optimizing supply chains and creating more effective approaches to distributed logistics networks (Segev, Zhao, 1994). The ability to define additional data structures through the many languages that are used for creating, augmenting or increasing the performance of databases, and integrating them into enterprise applications, all are predicated on the structuring of databases to be more process-centric, not necessarily focused on purely functional areas (Post, Kagan, 2001). One of the primary catalysts of this process-centric approach to defining the role of databases as a strategic asset is the en masse adoption of XML as a communications protocol, as it has been continually improved in terms of security and scalability (Roth, Hernandez, Coulthard, Yan, et al., 2006). The role of XML is also critically important in the context of creating Web Services that have as their foundation the use of relational databases for enabling both informational and financial transactions (Erickson, Siau, 2008). The use of Web Services as part of the broader structure and framework of SOA architectures is also predicated on the use of databases that can scale over time, to align with the rapidly changing needs of an enterprise that relies on complex data analysis quickly done to get feedback on strategies and initiatives over time.

DBMS systems have progressed beyond just being repositories of data and have become knowledge systems that rely on enterprise data management and Master Data Management (MDM) approaches for aligning content, intelligence and knowledge to specific strategic needs (Reagan, Rowlands, 2007). DBMS is now more synonymous with strategic planning than ever before, and has become engrained in many of the planning, execution and monitoring processes of companies including strategic market planning (Weinberger, 2004).

DBA Roles and Responsibilities

For DBAs their roles and responsibilities are have significantly changed from being the support staffs that keep databases software and systems running to being more required to complete projects as part of broader teams or completely on their own. As a result the role of the DBA is now marked more by collaboration combined with problem solving and less about purely being focused on technology expertise. In other words there needs to be a balance of focus on collaboration, strategic vision of where the company is going and how databases fit in and contribute, and also how user preferences and needs can be translated into real-time data modeling (Konana, Gupta, Whinston, 2000). All of these requirements force the role of the DBA from single contributor to more of a focus on project management. As a result, the critical skill set of being able to continually manage and coordinate people, processes and resources to align with critical path timelines is one of the most important roles that any DBA can continually improve over time.

In conjunction with this essential role of being a catalyst of collaboration and communication the DBA must also concentrate on anticipating and responding to the need for making workflows as agile and aligned to both system user goals and internal requirements as possible (Smith, Smarkusky, Corrigall, 2008). As a result, DBAs' roles need to also concentrate on creating an exceptionally clear and strong communication series of processes between teams. This is also critical from the standpoint that many of them are involved in the development of internal applications that are highly dependent on databases as the means to make these applications deliver useful results. Obviously the role of the DBA must be focused on technical expertise yet there is also the need for being able to intermediate the purely technical with the ability to create significant value through strategies that impact the company positively over time. Studies have in fact shown that the ability to translate and teach technical skills is as important if not more important than the pure technical acuity. It is in the ability to teach others and assist them in getting to their goals as employees, while helping them see how their contributions make a significant impact on strategic initiatives and results (Smith, Smarkusky, Corrigall, 2008). The ability to DBAs to act as leaders of projects while coordinating and sharing responsibility for the attainment of strategic objectives is critically important as well. DBAs then must also have the ability to define roles in the context of projects, and then be able to create programs that can lead to more complex, shared objectives over time. The role of the DBA then as a strategic level of a project management leader also needs to have a high degree of shared accountability, responsibility, transparency, all aimed at earning trust as a leader over time. DBAs must also be able to nurture a strong sense of a shared objective and then keep teams motivated to accomplish longer-term goals as well. As can be seen from these requirements, DBAs are much more than just being technicians that keep systems working over time. They are critical members of strategic teams and provide useful guidance and leadership in the attainment of complex, cross-functionally shared goals and objectives as well.

Database Design Considerations

There are many design considerations in the context of database structural development and the continual fine-tuning of them to the needs of those departments and individuals that use them to do their jobs. The design process needs to be based on the Systems Development Lifecycle (SDLC) where the specific user requirements are first taken into account, followed by a review of each stage of the database development, from the structure of how data is provided to the structure of the graphical interfaces as well (Danahy, 2008). The SDLC process is used to ensure alignment of the database design to the unmet needs of the database users.

Design criteria exist at the levels of the technical, system integration aspects of the database to other systems through XML. This integration is critically important to ensure that the applications created can be effectively used over time and not have any scalability issues. There is also the need for designing the databases at the presentation layer to provide for scalability and flexibility of being able to create applications relatively quickly at the portal level. This is especially important from a Business Process Management (BPM) standpoint as databases must be able to support the various process workflows as defined as part of business process re-engineering efforts over time. There is also the need from a design standpoint to have a continued development initiative going to capture user needs over time and include them into the next generation of database updates. The use of councils to create update plans and define the future direction of applications is critically important from a design perspective.

Database Performance

There are common measure of SPEC Marks is often used for benchmarking the performance of databases being offered by software vendors. The use of internally defined key performance indicators (KPIs) and metrics of performance that show the relative loads on a database application is critical for DBAs to understand the scalability factors of databases over time (Guynes, Pelley, 1993). This focus on performance needs to be evolutionary as well, seeking continual improvement over time (Zdonik, 2008). For the role of the DBA, the ability to quickly define KPIs, test them for their relevancy, and then include them in a broader set of metrics as part of a dashboard is essential to measuring the scalability of systems as well. The aspects of database performance also must be tied to the integration testing of applications, hardware platforms and the performance of APIs over time in terms of connection to databases with each other and continually testing their performance. The scalability of integration is also critically important, and the DBA, as the hand-built connectors and adapters must be tested to ensure they can manage the traffic generated from inter-database and intra-data transactions over time (Winkler, Seip, 2006).

Database Data Integrity and Availability

The use of approaches and methodologies to ensure a high level of data integrity and availability are based on both hardware and software-based technologies. From a hardware standpoint, the combining of Redundant Array of Inexpensive Disks (RAID) technologies, combining with software partitioning and the use of fall-back and redundancy algorithms to back up databases by the record, file or entire structure (Son, Choe, 1988). Data integrity is preserved through the use of Cyclic Redundancy Checking (CRC) and Error Correction (ECC), in addition to the concept of ACID compliance, which is explained in detail later in this paper. These approaches and methodologies also matter from a data availability perspective as well, as the logical structure of databases across multiple physical locations ensures data redundancy. For the DBA the choice of which approach to choose is critically important. The selection of a fail-safe RAID-based approach is costly yet preserves data entirely and can be configured to do selective backups over time. The combining of these systems with CRC and ECC based approaches to data integrity and availability is the essence of how databases systems at the enterprise level are made fault-tolerant.

Database Security

When many IT professionals consider the concept of database security, the overall perception is more about passwords usage and complexity than about the architectural elements so critical to keep any database secure. Beyond authentication processes and logic workflows at the presentation layer of database hierarchical models, the development of an architectural layer of security at the process management and integration layer of a database is critical (Jajodia, 1996). This translates into the ability to define role-based and information asset-based security through XML-based messaging protocols secured to 256 bits or higher (Iwaihara, Hayashi, Chatvichienchai, Anutariya, Wuwongse, 2007). Central to these process-based and asset-specific security controls is the ability to define more stringent Authentication and Access Control processes and systems. In conjunction with this approach to security there is also increasing focus, especially in DBMS systems from Microsoft, IBM and Oracle in the concept of each specific transaction within a database being ACID compliant. Additional areas of coverage in this analysis include database connection and security, the use of encryption and server security approaches and strategies.

Contrary to the common perception of authentication, there is much more to the securing of access to any database than the use of passwords or even biometrics. Databases need to take into account the concepts of cross-system and intersystem security to be as effective as possible and authentication cannot be relegated just to one single system (Bertino, Sandhu, 2005). Instead there needs to be more of a focus how at the interprocess integration and system integration levels, in some early adopters this would include SOA integration to the transaction level, can validate a given request from a given system to another in real-time. While all database management systems have Kerberos security, beginning with Microsoft, the lack of consistency of cross-system security beyond just using the ticket or alert-based authentication is critical to the stability of any network-based database (Ma, Orgun, 2008). What has been most significant about this aspect of database security is its rapid maturation from role-based authentication predominately only for military purposes first (Pangalos, 1994) top its uses throughout SOA platforms and architectures as well (Bertino, Sandhu, 2005).

Another aspect of enterprise-wide databases that has become increasingly prevalent is the requirement of having ACID compliance (Dolgicer, 1993) to the transaction level of a database. At its most fundamental, ACID compliance at it's most fundamental focuses on how to take each identifiable data element and isolate them, audit the activity performed on them, and be able to define an audit trial the values that have been written to the field, record, and table level. Global governments and militaries including ministries of defense use ACID compliance is to measure how often data has been accessed on specific supplies of munitions and armament for example.