Planning a Report

Using the Report Wizard makes the process of creating a report incredibly easy. Now we're going to build a similar report without the wizard. We'll have more control over the look and feel of the finished report and learn a lot of new Crystal Reports features along the way.

Because very few corporate data sources resemble the simple structure of a sample data source in Crystal Reports, this hour will analyze a complex database schema and help you determine how to use it. For example, we'll create a Crystal Report from the database schema shown in Figure 5.1.

Figure 5.1. A complex database schema can be challenging for report developers to decipher.

Of course, the reports created in this lesson will not use all these tables in the figure. Using Crystal Reports will allow us to provide a highly formatted report that is easy to understand, as shown in Figure 5.2.

Figure 5.2. A highly formatted report providing relevant information for report viewers.

Although the data structures and schemas in Figure 5.1 can be quite a challenge to understand, it is still required that some level of understanding of a data source you need access to for report creation is present. Otherwise, report design can seem chaotic. As a Crystal Report designer, business end users will often ask you to help them make sense of corporate data.

Although understanding the various corporate data sources you'll need to access is a critical success factor in creating Crystal Reports, another key factor is effective report design.

Effective Report Design Considerations

The most common mistake made by report designers is forgetting to plan the creation of a report. Some of the issues to consider might seem quite basic, but it's good practice to walk through the process of validating some key report design considerations before starting.

The basic questions to ask before starting your report are Why? What? How? When?

They might seem simple, but there's nothing worse than finishing a report only to find out that it isn't what the person who requested it wanted. We'll now walk through each of these questions in detail.

Why Do They Need This Report?

As a report designer, you'll never run out of unique requests from end users and report consumers. Some requirements will undoubtedly be

• Including summary Numbers (Quarterly reports enough said).

• Making a collection of numbers make sense. Business users are rarely familiar with the nuances of the database environment.

• Needing key business metrics yesterday. (There is no time like overdue to ask someone to create a report, right?)

• Converting old legacy reports to a new system.

• Providing consumers with information on the Web.

Of course, the person requesting the reports might not really know what he wants, but the common thread throughout each and every report request is the need to bring "people and information together."

What Do They Need?

Perhaps a more appropriate title for this section is "What do they tell you they need?" Ever notice that when someone requests a new report, he starts telling you what he wants, but not what he needs? Those types of requests usually consist of statements like

• Just a final number (I don't care how you get it)

• A map

• A pretty chart

• An Executive Summary

• The Quarter End Summary

• The ROI

It's ultimately the job of the report designer to find out what the real business requirements are for any report that must be created. It's not enough to just prioritize which reports are created first, second, third, and so on. The design requests within the reports themselves are ultimately what drive the complexity and, hence, design longevity.

How Will We Judge the Successful Completion of This Report?

Experience has shown that to get good answers, it works best to make the business user requesting the report feel useful and needed through interaction during the report planning phase. Starting with simple questions, such as

• What features are required for this report?

  Most reports require some graphical representation of the data within, which means charts or a geographic map potentially.

• Are there other reports I can work from?

  If there are sample or existing reports (maybe it's a older, legacy report you need to recreate, such as a mainframe report), it's always faster to work with something than nothing, especially if you're trying to duplicate the look or functionality of an existing report.

• Where is the data coming from?

  This is an important step. If you can't connect to the data that you need to see, you're stuck. Start with a successful database connection, and you'll be off on the right foot. We will be focusing more on this in a future hour. Another follow-up question would be, "Who can I ask to help me get connected to this data source?" Chances are, it's someone in IT.

• What level of detail do you want to see?

  Focus of vision and what level of detail the final results should be are key. If the end result is just a final number, don't spend a lot of time on making the details look pretty. Take the same perspective as the person asking for your help.

• What help or resources can I work with?

  No one is an island in life or in work. Ask colleagues for help and ask a lot of questions. Don't assume anything. Remember, there are no such things as dumb questions.

When Is This Due?

As previously mentioned, make sure to discern the want from the need. Try to get the requesting business user to understand your perspective, abilities, and the features of Crystal Reports available to them. After all, time is precious. Find out what the key drivers are for the business user and the priority placed on each requirement. Meeting somewhere in the middle is usually a good idea.

Now that we've covered some of the typical and most resourceful questions to get you started in writing a report, let's look the physical process of report design.

Mapping Out a Report

A report can be considered a book. It tells a story in words as well as pictures. The complete story needs to be told to get everyone reading it to understand the message it is delivering. The person who has the ultimate idea of how the story should end is the person requesting the report the requestor. He has in his mind that the report should have certain information on it and should look a certain way. He might even come to you with a drawing or picture. To organize your thoughts, be prepared to take notes.

As you begin to write down your thoughts, you may notice that you are writing out the story that the requestor is asking for. So, if the requestor is the illustrator in our example here, you could be considered the author. As an author, you can follow the general rules of writing that you learned in school. Start with an outline and build from there.

Write a paragraph or two in your own words to tell the story that the requestor has relayed to you. Don't worry about missing information. It's a work in progress, and you can ask questions later. After you've finished the first draft, you'll notice that editing the story becomes essential. That's when the real facts about the story, or report, will surface.