- Your Project: A Time Entry and Billing Database
- Determine the Requirements of the Database
- Introduction to Database Modeling
- Model the Time Entry and Billing Database
- What You Have Learned
This chapter is from the book
This chapter is from the book
This chapter is from the book
Determine the Requirements of the Database
How do you go about making decisions regarding database requirements? The key to making decisions lies in knowing where to find information. In spite of the varied nature of different companies and departments, the sources of information are common. As you develop different database systems, you will find the process of requirements gathering to be very repeatable. Among the many sources of information regarding database requirements, the most common include interviews, business forms, and existing systems.
Interviews
For all the computing power companies use today, people still make the decisions and make things happen in a business. Don't underestimate the power of talking and—perhaps more important—listening to the employees of a firm. These people might not be able to speak in technical database terms, but then again, that is why you are on the scene—to be the gatherer and translator of information.
Through interviews, you will be able to learn how information passes through an organization. You will also be able to learn which specific pieces of data individuals rely on and the decisions they make based on that data.
CLUE
You are putting together a puzzle.
When conducting interviews, don't limit yourself to just the management personnel and the frontline staff. Each level of an organization has a piece of the puzzle to contribute. Each is equally important because without all the pieces of a puzzle, you can never have a complete picture. As a result, without all the pieces, you can never have a complete understanding of the business and the requirements of the database you are being tasked with building.
Understanding Strategic Versus Tactical Needs
The decisions a company makes fall into one of two categories:
- Strategic
- Tactical
Strategic decisions are decisions regarding things such as whether to go into a certain line of business, whether to start or end a specific product line, and whether to alter head count. Strategic decisions affect a company as a whole. As far as timing is concerned, the strategic planning horizon is usually more than six months and can extend for time periods as long as five years. You might be familiar with your company's rolling three-, four-, or five-year plan. If you are tasked with designing a database for your company, you must have an understanding of your company's strategic plan. Your database might very well have to support those plans by providing information for decision making.
Whereas strategic decisions are long range in nature, tactical decisions are short range and much more detailed in nature. Strategic decisions focus on what a company wants to do; in contrast, tactical decisions focus on how those things get done. For example, a strategic decision might be to increase operations over the next two years. To fuel the growth, cash-flow requirements for the business would have to increase by 10%. Tactical decisions to support this strategy might include the following:
Increasing time to pay accounts payable from 30 to 60 days
Requiring payment of invoices in 10 days instead of 30 days
Finding new sources of bank financing
You might be asking what this has to do with database development. The answer is everything! Data is the lifeblood of a business. Without data, a company can't make decisions. To make the tactical decisions previously listed, a database must provide the required information in a usable format. Through interviews, you can learn much about what a company hopes to achieve, and in the process, learn what the requirements of the database need to be.
Business Forms and Documents
Interviews can provide both high-level and detail-oriented information. Examining and analyzing business forms is where you start to get into the nitty-gritty details. The following are examples of business forms:
-
Invoices
-
Reports
-
Shipping documents
-
Timesheets
-
Customer service surveys
-
Any other piece of paper somebody in the business uses
In an interview, you might discover that it is critical the database stores information about customers. Through the analysis and examination of business forms and documents, you discover the specific pieces of customer information that must be captured. Another example is tracking time. In your current project, the Time Entry and Billing database, you know you will have to keep track of time at some level of detail. A typical timesheet might contain some or all of the following information:
- Employee name
- Date of work
- Start time
- End time
- Task performed
- Project
- Client
In looking at this example involving a timesheet, it becomes clearer as to what information the database must store. Chapter 4, "Database Design Continued: An Introduction to Normalization," focuses on how the information is organized. At this point, what is important is where to find the information.
CLUE
Time to stop and catch your breath here. It is important to illustrate how interviews and business forms work together. It is all a seamless web. Interviews provide the big picture of what information the database stores. To some extent, interviews also can provide information on the details. However, an analysis of the business forms and documents a company uses provides the bulk of the detail information.
Existing Systems
It might very well be the case that your project's purpose is to replace an existing system. Perhaps the company has outgrown the capabilities of the existing system. Perhaps the existing database design simply does not meet the growing needs of the company. To understand the requirements of your database design, you must understand the current system. Most importantly, you must understand the shortcomings that might exist. If you don't know and understand issues regarding an existing system, the possibility of perpetuating database design flaws into the new system increases dramatically.
CLUE
In many respects, the user-interface components of an existing system can be regarded as business documents and forms. For example, a physical piece of paper that represents a timesheet might not exist. Rather, employees might enter their time online via a time-entry screen. As a database developer, you will need to be aware that the line between disparate sources of information is not black and white. Further, there is no set order in which the different elements are reviewed. Finally, it might very well be the case that the same sources of information will need to be revisited. For example, after you have analyzed a business document, you might have to return to the process of employee interviews to get further clarification of the database requirements.
Remember the mantra of patience? The process of requirements gathering might seem like a never-ending process. Some believe that systems and databases are never "complete" because the business environment constantly evolves and changes. At some point, you will acquire enough information to establish an initial database design. Just because you create that first design does not mean the requirements-gathering process is complete. Remember, you might have to repeat the process two, three, or perhaps four or more times to achieve that first database design. As you gain experience, the process will become more familiar to you.
At this point, you have an understanding of where sources of information can be found for requirements gathering. The question now is how do you put an initial design together. The answer is in the form of a database model. The process of creating your first database model is the focus of the next section.