Reports.  Reports are so commonplace you probably don't realize how often you see them.  For example, your monthly credit card statement is an example of a report.

Think for a bit about the databases that underlie use of your credit card.  They are going to need tables on things such as

  • customers
    • contact info
    • verification info
  • places approved to take the credit card
    • retailers
    • restaurants
    • and on and on
  • charges
    • charges to your card
  • billing_info
  • payment_info

It should be obvious that there is plenty of other information required to get such services to work.

But now you should think of your monthly credit card statement.  It lists new charges incurred in the last payment period.  It also carries over any unpaid balances.  It also carries computations for interest based on unpaid balances.  There may also be some sort of rewards.

But your credit card bill is a report that is most likely generated monthly.  It contains some basic information about each charge to help you be confident you made the charge.

So there are plenty of other reports you deal with all the time.  You get all kinds of bills for things like phone usage, gas and electric.  Each of these systems has their own business rules and data they collect.

You should also be thinking more about how queries underlie almost all reports in one way or another.

What I'm hoping this discussion does is convince you that you already are much more familiar with reports than you probably thought.

QUESBMI.  Now we'll go back over some of the examples we have worked on so far in this course.  Think about some of the reports that the administrators of the QUESBMI would likely want.

  • faculty with particular interests and experience
  • people developing different types of business plans
  • people whose memberships are coming up for renewal
  • potential new members
  • people that attended particular meetings and/or conferences

Obviously, this list can go on and on.  But you should remember, that the sort of reports someone eventually needs has huge impact on the data that must be collected.

Madam Curry.  Madam Curry's situation is somewhat simpler than most retail situations because of the limited number of products, the nature of her markets and her relatively simple operations.  But even with this she is going to want to be able to obtain quite a variety of reports.

  • who is on the email list
  • who's checks bounced
  • how much each purchaser has purchased in the last year
  • how much each purchaser has purchased
  • what is the demand for each of her products
  • what sort of feedback is Madam Curry getting about potential new cookbooks

I have included some of these to illustrate that Madam Curry is likely to want to collect some additional data to help her make some of these decisions better.  Madam Curry should also be watching things like whether advertising or other strategies impact her sales and how.

But I don't want to spend too much time talking about these issues at this point.  We will go through one last example before moving on to more specifics.

Missoula Food Bank.  The Missoula Foodbank is actually collecting quite a bit of data about its clients.  This will really help the administrators determine all kinds of things about the clients and who is coming to the foodbank and why.  Even though there are a huge number of possibilities I still want to list a few.

  • what percentage of clients have come for food every month this year
  • what percentage of clients are new
  • what percentage of clients are within some special group
    • how does this compare to the percentage in this group in the overall population in the area
  • how many dependents does the typical MFB client have

Obviously, this can go on and on, particularly considering all the data that is being collected.

Now I want to get more into developing reports in Access and for a few of our example databases in the next webpages.