FAQ: Database System Development Life Cycle

Transcription

1 Question 1: Why study database management system (DBMS) designs? Answer 1: Understanding and designing databases is truly an evolutionary learning process. There is not a right way or a wrong way to develop a database; instead, there is a set of established principles that can be employed in an infinite number of possibilities. The best learning actually takes place on the job: Through designing and developing database solutions, one can learn from his or her experience. Database analysts (DBAs) are exposed to other ideas either through peers who work alongside them or through industry groups where the examples and ideas of others could be studied. Every new database that a DBA encounters is really a learning opportunity for the DBA to see what areas of the database are predictable and what areas of the database are elegant and even perhaps revolutionary. Every database is a learning experience for the DBA. Question 2: How is the database system development life cycle (DSDL) similar to the systems development life cycle (SDLC)? Answer 2: The database system development life cycle (DSDL) is very similar to the systems development life cycle (SDLC) because the SDLC is a best practices approach to managing software development projects. These best practices can be translated into the activities that one would use when developing a database project. It has a similar structure because it works and is highly effective in providing oversight over a complex problem. It is not incorrect to suggest that the DSDL was deliberately patterned after the SDLC. Question 3: Does documenting a database slow down the development process? Answer 3: Documenting a database does slow the development process; however, there are two different opinions on this problem of speed and accuracy. One opinion suggests that the documentation provides a way of understanding the database conceptually before any expensive development work is performed. It suggests that quality control is built into the front of the development process because the time and energy spent in conceptualizing the database is 1

2 less expensive than going back and repairing the database after it has been constructed. The second opinion suggests that quality control is built into the end of the development process because the testing phase of the database system development life cycle (DSDL) will reveal any database inconsistencies, and those inconsistencies can be repaired. In the first opinion, you are slowed down by the analytical process of conceptualizing the database prior to development. In the second opinion, you gain more speed in the development process because there is no analytical work, and the assumption is the corrections found during the testing phase will be relatively minor. The problem is that working under the assumption that these changes will be relatively minor, it could turn out that the entire structure of the database was incorrectly assumed; thus, the whole thing needs to be rewritten, and you must start from scratch. The DSDL attempts to avoid assumption in clarifying work before it begins. This slows down the development process but also ensures a greater degree of accuracy from that process. Question 4: How can documentation be used after the development process? Answer 4: It is unfortunate that many companies rely upon individuals to manage their databases. When this happens, there is a built-in dependency upon that individual to stick around and help the company extend and use its database. This creates an unnatural relationship where a company is entirely dependent upon the knowledge of just one person; if this individual left the company, the risks could conceivably affect its business plan. Documentation objectifies the database just as a blueprint for a building might. Blueprints for facilities can be shared with a myriad of contractors and vendors so everyone is on the same page when making alterations or changes. The same is true for database systems where many individuals (such as vendors, software developers, report writers, customers, and employees) will need to understand the database's structure to complete their work. Documentation can reduce the overall risk to the company, because one individual is not solely responsible for understanding the entire database. 2

3 Question 5: Do all companies use the same database system development life cycles (DSDL)? Answer 5: Many companies do not use database system development life cycles (DSDL) at all but instead fit the database development process into a broader systems development life cycle (SDLC). Depending on the size, complexity, and risks associated with the company s business process, management may require more transparency in the development process and trust its database analysts (DBAs) and software developers less. Some companies do not require a great deal of transparency in the process of developing and designing databases and instead invest a staggering amount of trust into their DBAs and software developers. Their SDLC might not even be written down and may be just a generalized process. Some customers (e.g., government contracts) may absolutely require extensive documentation concerning requirements and the fulfillment of those requirements so an extensive DSDL is absolutely required. The bottom line is that companies use the DSDL framework as they might an SDLC framework and customize it for their own needs and purposes. Question 6: What is transparency? Answer 6: Transparency simply means that management can see all of the happenings and events during the development process for a database. More transparency means more complexity in the database system development life cycle (DSDL) and is often equated to greater micromanagement. Less transparency is indicative of more trust placed in the database analysts (DBAs) to do their jobs and is often equated to a management by objectives (MBO) philosophy in managing projects. Management might absolutely want a say in the decisions made by its DBAs, which could adversely affect schedule and cost, and the DSDL is designed to interject management oversight at key areas during the development process. 3

4 Question 7: Is there risk associated with not documenting a database? Answer 7: Just as there is a risk in building a house without blueprints, there is risk associated with not documenting a database. All of the information that went into constructing that house resides in the mind of a single builder. If that builder becomes unavailable, the architectural understanding of the house is lost. The same is true for a database. Without documentation, the database could easily become a black box: A working component for a software application that is not thoroughly understood and could inhibit the company s ability to leverage that asset or to expand upon it. In some cases, database analysts (DBAs) may even be called upon to reverse-engineer the database so they are able to understand it and develop the documentation that was never prepared in the first place, creating more cost and wasting more time. A vast number of companies run databases that were created as legacy systems that they paid tens or hundreds of thousands of dollars for and do not thoroughly understand and cannot support because they lack documentation. It is without question that DBAs will be called upon within the course of their careers to reverse-engineer many databases with which they were not initially involved. Question 8: Is documentation for the database good for software development? Answer 8: The relationship between a database analyst (DBA) and a software developer is a strained one. The application developers want to offer the greatest possible product to meet user needs, and the DBAs want to protect the integrity of the information system and the speed and performance of the database. Sometimes, these goals are not directly aligned. The users want to have information available to them throughout multiple areas of their application, which would force the database to store information redundantly or inefficiently. If the software developer has the right to make changes to the database, more often than not, this developer will sacrifice relational database principles to meet the needs of his or her end users. If the software developer is prohibited from making these changes, there is likely going to be contention between the needs of the software developer and the DBA. Documentation helps clarify the structure and intention of the database so it can be shared with all software developers without having to reiterate the 4

5 DBA s intention. In this way, stronger and more uniform database and application solutions can be constructed. Question 9: How can documentation be used in future projects? Answer 9: As with any blueprint or map, documentation for the database could be useful for preparing new extensions and new capabilities. Without documentation, future projects may attempt to reinvent database structures that already exist and could introduce additional complexity and redundancy into the information system of a company. The adage If one does not understand the mistakes of history, one is doomed to repeat them is applicable to database design and development. With extensive documentation, future projects could leverage database structures that have solved previously understood problems so process is not repeated. This could save time and energy and allow the company to deploy a more integrated software solution. Question 10: Should all databases be centralized to just one machine or one server? Answer 10: There is a school of thought that suggests everything should be centralized, which is supported by Moore s law and Metcalfe s law in terms of technology principles. Processor speed will double every 18 months while the price drops by half, and broadband speed will double while the price drops by half in the same period; therefore, more bandwidth is available every year at lower costs, and more processing speed is available every year at lower costs. It makes perfect sense to decentralize as much as you can to a single machine to lower the total cost of ownership (TCO). Cost alone does not justify putting all databases on just one machine. If a banking institution centralized all of its database activity to a single point and branches used wide area connectivity to interface with that centralized database, the obvious risk is network connectivity. If the network goes down with this centralized database strategy, the banking branch would be incapable of performing its core competencies: accepting deposits and performing withdrawals. If a retail company centralized all of its database activity, and connectivity to the database was lost by a retail outlet, inventories could not be reconciled, and point of sale stations could not record 5

6 customer transactions the retail company would be unable to sell anything, and the corporation could not have any transparency over its remote inventories. Moore and Metcalfe aside, it makes sense to distribute databases and have the database management system (DBMS) engine synchronize and replicate the databases' contents in the event of connectivity failure. Although centralization lowers total cost of ownership, it also increases risk because of failures and connectivity. In designing database solutions, one must balance the inherent need for centralization and cost containment with the need for business continuity. 6