Planning Your Database

Planning Your Database

During the planning phase, create a worksheet to map out what your database will look like.

Because the objects in a database are related to one another, building a database requires careful planning.

Determining the purpose of the database

Brainstorm with your class about the questions that you would like the database to answer, and the reports that you would like the database to produce. For example, you might want to look at the causes of shipwrecks and whether those causes changed o 12512f54m ver the years as ship construction evolved, leading to a report on how future wrecks can be prevented. Or, your students can gather data first and then look for patterns in where, when, or how shipwrecks occur. Think about the information sources that you want to use to obtain data.

Mapping the structure of the database

As you determine what information you want from the database, you can decide what facts you need to store in the database and what subject each fact belongs to. You might decide, for example, to create multiple tables. Or, with an assignment like the one for shipwrecks, you may need only one table. Each record within the table can contain information about an individual ship.

Each field in your database represents a fact about a particular subject For example, certain facts about shipwrecks are historically important, such as name of ship, type of ship, dimensions, date built, date of first voyage, date of sinking, cause of sinking, location, cargo aboard, number of crew, and number of passengers. You might want to create a separate field for each of these. Here are some guidelines for determining the fields you need:

Include all of the information you will need.

Store information in the smallest logical parts. For example, if you believe that the majority of shipwrecks have been caused by storms, and you want to examine which months have the highest concentrations of sinkings due to storms, you should create separate fields for months and years.

If it's logical to divide your database into multiple tables, you need to think about relationships between common fields among the tables. Establishing these relationships will help you bring related information together in meaningful ways. For example, you may eventually want to use the Cause of Sinking field to list all ships that sank due to storms.

Create fields for data that contains only one item, not lists of multiple items. For example, instead of creating one field for ship dimensions, create separate fields for length, width, and weight. To ensure that you can sort and filter data effectively, make sure your fields contain discrete data types.

Don't include derived or calculated data-for example, a field that multiplies the values of two other fields-as you might in an Excel spreadsheet.

Create fields that are different from each other in a way that is relevant, even if the type of data you will enter under them will be similar. For example, instead of creating fields like Date 1, Date 2, and Date 3, create self-explanatory fields for dates: Year Built, Year of First Voyage, Month Sunk, and Year Sunk.

After you determine the purpose and structure of the database, study your plan and look for potential flaws. Although you can modify and extend your database at any time after it has been created, it is easier to change your overall design in the planning phase than it is after the tables are filled with data.