Planning the DBLC
According to the textbook, the Database Life Cycle (DBLC) contains six phases, which are: database initial study, database design, implementation and loading, testing and evaluation, operation, and maintenance and evolution. The idea of the DBLC is to encompass the lifetime of the database. Each step has specific targets that need to be achieved in order to be completed.
In order to mitigate risks associated with a database, it is essential to consider common sources of database failures. Describe at least two possible database failures that may occur once a database is placed into operation. Suggest actions that may be performed in order to avoid or mitigate these possible failures.
- Database Initial Study: The situation of the company needs to be analyzed to define the problems and constraints along with objectives, scope and boundaries in the database. In our scenario, we need to track monthly expenditures by departments on a specific organization. In this case, we will need to know initially how does the company operates, and what is their mission, as well as to what is the organizational structure, this is key in order to determine how the information within the company flows. Once this is complete, problems or target outcomes must be pinpointed, for example, what are current systems they are using to track this? Is it failing? Why do they need a new DB to track expenditures? Once problems are identify, then the plan of action comes into play and objectives need to be defined. For example, creating ad-hoc queries in order for general managers to track expenditures by departments.
- Database Design: the design of the database that will support company operations and objectives is done on this step. We need to make sure that the final product meets use and system requirements. In the process of database design, we must concentrate on the data characteristics required to build the database model. There is the Minimal Data Rule, which states that “All that is needed is there, and all that is there is needed”. This is all done in four steps: data analysis and requirements, ER modeling and normalization, data model verification and distributing database design.
- Implementation and loading: once the design is done, this will concentrate in installing the DBMS and creating the databases. We will need to pay close attention as to the level of security and access to the database, which your analysis on the organizational structure will pay on. A system administrator will need to install the DBMS and create the database(s) as well as to take care of security and access to the data. On our example a consideration to have will be to not have regional managers or local department managers to have access to other department’s entities in the database. While a general manager might needs access to all departments under his structure. Once DBMS is installed, databases are created; the final step for the system administrator is to load the data.
- Testing and evaluation: In my opinion, one of the most overlooked steps in any system design models I have studied. If careful consideration and special attention is given to this step, it will translate in less maintenance and troubleshooting of problems and errors in the database. The database should be tested and fine-tuned extensively before going into production, and even in production testing and evaluation must be regularly done. In this phase, consideration to backup options must be done, and the backup process should be designed. Security and access should be tested in this step as well.
- Operation: Once the database has passed the evaluation stage, it is considered operational. At that point, the database, its management, its users, and its application programs constitute a complete information system. Problems that were not foreseen will happen during this phase, and careful testing in remediation must be done in order to restore the database to a functional state, were functional is a relative term as to the fulfillment of the initial objectives. Are managers able to produce ad-hoc reports? Is the information of the data accurate? Is the database operational? Is it baking up correctly? All this and many others are sample of a database not been operational.
- Maintenance and evolution: Sample of regular maintenance that needs to be performed by an admin are: backup, recovery, enhancing performance, adding entities and attributes, assignment of access permissions and their maintenance for new and old users, generation of database access statistics to improve the efficiency and usefulness of system audits and to monitor system performance, periodic security audits, monthly, quarterly, or yearly system usage summaries for internal billing or budgeting purposes. Once the database is not functional, or have fallen short to the needs of an organization, then evolution is needed and a new cycle should be started if a new system or database is needed.
Two of the most common errors after a database is places into operation are database connection errors and database query errors. With database connection errors, the most common root cause for it are: a network issue, a server configuration issue, a firewall issue, a client driver issue, an application configuration issue or an authentication and logon issue. Chances are that is proper troubleshooting is done following each of the common suspects; it will be fixed once pinpointed. Troubleshooting should be done on that particular order.
On the other hand, database query errors might be a bit more cumbersome to troubleshoot because it might be specific to the selection that you are making at the moment. Most common are division by 0 and can be as complicating as missing indexes in searches. To troubleshoot queries, ne most go into the actual statement and try to either write it using other commands or joins, or even try to substitute nested queries and peel them apart to pinpoint the point of failure.