The Cold Fusion Web Database Construction Kit
The best way to learn a development tool such as Cold Fusion is to see it used. So, from this point on, everything I describe will be within the framework of a fictitious company called A2Z Books.
Before you go any further, however, you should review the fundamentals of application design. The application design process is the most important part of application development. Building an application without a thorough design document is like building a house without a blueprint. Without such a document, you will most certainly overlook some details, you probably will end up with components that just won't work together, and your finished product probably will not be what you intended it to be.
The key to successful application development is careful application design. Like anything else, this design requires planning.
The design process has the following four basic steps:
Through the rest of this chapter, I explain these steps in detail.
A2Z Books is a small bookstore with big ideas. The company prides itself on top-notch customer service and goes out of its way to ensure complete customer satisfaction. A2Z Books is a mail- and phone-order company, and like many other small companies, A2Z Books is suffering from growing pains.
Just last week you were called into the boss's office and assigned a new project. "Orders are up," the boss said. "Way ahead of year-to-date projections. We've doubled our order processing staff to handle the load, but we can't seem to keep up. New titles are not being made available to our customers quickly enough, and orders are taking too long to ship out. Our customers have grown to expect better service than we can offer right now. We desperately need to find a way to streamline our operations and eliminate whatever is causing these bottlenecks. I want you to give this some thought and make recommendations. Oh, and I'll need them within the week."
And that is why you're sitting there, amidst piles of pads and sticky notes, trying to work out exactly what is wrong and how you're going to fix it. You know that the manual processes of order taking, shipping, accounting, and billing just cannot work anymore. Computers could, and should, be performing many of these tasks for you. But where do you start?
After reading and rereading your notes, you come to the conclusion that you just don't know enough about the individual processes and procedures that make up the day-to-day operations of the company. To design a computer system that will be both usable and useful, you really need to interview personnel around the company to learn just what they do, why they do it, and how the work gets done.
You start to compile a list of questions to ask during the interviews. Starting with the accounting department, you create the following list:
How often are invoices processed?
How is order information provided to you?
How is client information provided to you?
What are the steps you take to create an invoice?
What happens to the invoices after they are printed?
What reports do you run after printing invoices?
Who gets these reports?
You also may want to observe some of these operations being performed. This way, you can pick up details that you missed during the interview.
TIP: When you're conducting these interviews, ask very specific questions and try to obtain very specific answers. Remember, you're talking to someone who does a particular task regularly and who most likely takes many of the details involved for granted. The more explicit your questions are, the more useful the answers will be.
After you have this information in hand, creating a flowchart is often useful. It can depict the steps that make up a complete process, as shown in Figure 5.1. You also can have whoever gave you the information review the flowcharts for accuracy. This way, you can be sure that no steps have been overlooked.
Figure 5.1 Making flowcharts is an effective way to review and analyze business processes.
This process might sound like a tedious and time-consuming task, but the more preparation you do up front, the more likely your computer program will work the first time and will be accepted. The acceptance, or lack thereof, usually determines the fate of any computer program.
NOTE: Often, you may find that people have determined that their business needs computerizing, but they have no idea what they want or what the computer can actually do for them. Bear in mind that noncomputer users usually know only what they want an application to do for them once they have seen the application and know what they don't like about it.
Too often, programs are designed and implemented by programmers working in a vacuum, without any real knowledge of the problems that they are trying to solve. A program like this might be built around great business ideas and work models, but if it requires a change in the way employees go about their business, then employees will look for every excuse not to use it. Without mass acceptance, the new program is doomed to fail.
TIP: Computers are supposed to make our lives easier, not force us to relearn what we are already familiar with. A computer program that forces people to change the way they work will probably never be used.
The interview process should be conducted thoroughly and should include a diverse set of employees for another important reason. Often, employees view computerization and technology as a threat to their jobs instead of as a boon to their productivity. Although some of this fear might be justified, as a whole, it is usually the result of computerphobia and horror stories of corporate downsizing. The interview and due-diligence process enables you to reassure employees and to persuade them to buy into your plans and suggestions instead of rejecting them. Making employees feel like they are a part of the application design rather than its victims can go a long way to boost mass acceptance.
TIP: Never rely on the input of a single individual. The more people you interview during the research project, the more likely you are to obtain information that is an accurate reflection of the way business is performed.
Armed with all this information, you now might be tempted to actually start application development, knowing that you can make educated suggestions and that you have the data to back them up. But don't run out to buy database applications and development tools just yet. You still have quite a bit more preparation to do.
Before you start actual development, you should document your application goals thoroughly. Include the various components of your application, what each component does, and how the components interact. You can use this document as your roadmap throughout the actual application development process.
What you should not be documenting, at this point, is databases, tables, and fields. Try not to get caught up in any technical details yet. This document is not a database schema; it is a high-level overview of what your program will do and how it will do it. What data will be stored in which tables and how that data will be stored are not considerations at this stage. You should make sure that the application design decisions that you make are based on business needs and practices, not on features or peculiarities of any particular database system or development tool.
TIP: Don't let the features of any database system or development tool influence your high-level application design. You know your business; the designers of the databases systems do not. If a particular database system does not have the features you need, you can always pick another one. Switching databases is much easier than switching business practices.
You now can sift your way through the piles of data sitting in front of you and begin to formulate your application plan. The plan is initially broken down by department, so you can list the needs of each department based on the results of your interviews.
Human Resources Department. You start with the human resources needs and break down
the requirements into an organized list, as follows:
Accounting Department. The human resources list is relatively simple. So next, you try your accounting department, as follows:
Marketing Department. The marketing department's chief complaint is that they cannot easily get information they need from other departments. Here's their list of requirements:
Sales Department. The sales team has the closest interaction with the customers. Therefore, you can safely assume that most of requests from the sales department are customer driven. Here's their list of requirements:
Shipping and Receiving Department. Shipping and receiving is the place where much of the bottleneck occurs.
NOTE: The preceding list is just an example demonstrating the kind of information to include in a high-level design document. The list has been simplified, it is by no means a complete list, and your own documents will typically be far more detailed than this one.
Remember, the more detail you include, the more complete your design will be. Just make sure that it isn't so detailed that it is no longer a high-level document.
You review the design document and refer back to your notes and scribbles to verify that all needs have been included. And just to make sure that you haven't omitted anything, you circulate the design document to department heads for their approval.
Now that you have your basic application goals documented, the next step is to determine what data sets you need to actually design the application. The goal-oriented design document implicitly lists all the sets of data you need to build the application. You just need to extract it.
So, look through the design goals again, and determine the data requirements for each.
You can now summarize the data requirements for your entire application in one simple table, as shown in Table 5.1.
| Data Set | Notes |
| Employee Information | Employee lists, personal information, vacation details |
| Customer Information | Customer details |
| Inventory Information | List of all book categories, book titles, number in stock, availability |
| Accounting Information | Invoicing, accounts receivable, financial reporting |
There, this list is probably not as intimidating as you thought it would be. In fact, it's a rather manageable list. So, just to make sure that you haven't missed anything, run through the goal list one more time. If you were to have these data sets in place and the tools with which to manipulate them, would you be able to meet all these goals? If yes, then you're ready to move on to the final step.
You're almost there. You have determined the goals for the application and what data sets you need to meet these goals--and all this without thinking about databases and tables. Well, that's not exactly true. Without even realizing it, you have started defining what your database and tables should look like. The data sets listed earlier roughly equate to database tables, and the relationship between these data sets can be translated into relationships between the tables.
Before you can create the tables, however, you need to list the details that make up each data set. Don't worry about how the data is stored and what information will go into which field. They are table creation concerns, and you're not creating tables yet. Right now, you just want to ensure that you have all the data details you need so that you can complete your design documents.
TIP: With most database applications, you can add columns or fields to your database tables after they have been created. However, restrictions that limit you to the types of columns you may add often exist. You therefore should make every effort to include all the needed data right now, before you create the application's first table.
The details for the first data set, the one for employee information, are listed in Table 5.2. The Notes column is useful for jotting down details you don't want to forget when you actually create your tables.
| Data | Notes |
| Name | First name, middle initial, last name |
| Address | Make sure that space is available for suite or apartment numbers |
| City | |
| State | |
| Zip Code | |
| Home Phone | Also cellular phone and pager number |
| Social Security | |
| Birth Date | |
| Date of Hire | |
| Title | |
| Department | |
| Phone Extension | |
| E-Mail Address |
The details for the customer information data set are listed in Table 5.3.
| Data | Notes |
| Name | First name, middle initial, last name |
| Address | Make sure that space is available for suite or apartment numbers |
| City | |
| State | |
| Zip Code | |
| Phone | |
| E-Mail Address | |
| Customer Since |
The details for the inventory information data set are listed in Table 5.4.
| Data | Notes |
| Category | Also need a category list |
| ISBN | |
| Title | |
| Publisher | |
| Publication Date | |
| Author | |
| Pages | |
| Description | Brief title description |
| Number in Stock | |
| Due Date | This data provides the date more copies are due in, especially if the number in stock is 0 |
| Location | To help shipping locate the books, tracking where they are stored would be useful |
I'm not going to list all the sample application data sets and their details here. When you're creating your own application, however, make sure that you list every data set and all information details.
In this chapter, you learned the basics of application design. The design process is a vital part of application development and one that is often not given as much attention as it deserves.
For more information about topics mentioned in this chapter, see the following chapters:
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}