Database Design: General Description

Some years back, I received a request from a nearby city to help them develop data for an ongoing comparison of their city with several other similar cities (nowadays, we would call it “benchmarking.”) They wanted at least 3 years of data for their city and 6-12 other cities. Some of the cities were to be of similar population, some of similar taxbase, some of similar area, etc. They also wanted the data to feed internal and external peer evaluations of various city operations, including Planning and Budgeting (both capital and operating); Acquisition and use of equipment and materials; Human Resources (selection, training, responsibility, and accountability); Communications (including public relations and customer service); and Evaluation Procedures (findings, recommendations, and imlementation).

This is a big project. It is going to take a lot of time and money to assemble all these data, and once it is done it has to be usable by a widely divergent group of people for a number of different purposes. How do you go about doing something like this?

Welcome to the exciting (really, it is!) world of database design. This little project involves a number of conceptual elements: The first is simply figuring out how to manage all that information. How many pieces of data do you need? Where do you store them? How do you interrelate them? And what do you want to do with them, anyhow? The second issue is figuring out how to gather the information to populate all the cells of the database. What type of measures will one use? What type of sample will one draw? How large a sample does one need? The third issue revolves around reporting (and interpreting) the results. How much confidence can you have in the results you will draw from the data?

Next Section

Back to Syllabus

609