|
Schema design is the process of determining:
In practice you usually start with the idea that you want to store some data. For example, let's say you are a bicycle collector and you want to keep track of the bicycles you own. Thinking about the problem it occurs to you that it would also be nice to keep track of the people associated with your hobby–other collectors and the people who supply you parts and related services. The first step in schema design is deciding what tables and what fields in each table are needed. Since each table should describe one type of entity you decide to create two tables–one for the bicycles you own, and another for your contacts. (In this concept we will only be concerned with the table of bicycles.) |
Thinking about the domain and the anticipated uses for your database you come up with a list of possible fields: make, model, year, price, condition, description, and notes.
The next step is deciding what the granularity of each field should be. Should "make" and "model" be separate fields? Should "condition" and "description" be separate fields? There are no right or wrong answers. It depends on how you plan to use the database. If you ever expect to sort, filter or list a value alone you should make it a separate field.
The names of fields are somewhat less of a concern, but having descriptive well chosen names make it easier to work with and understand your database.
And finally, you must specify the type of each field. The type of a field is important because it will determine how you can use the data in the field. In our bicycle database example, if we declare "price" to be a text field we will not be able to sort the records by price.
Copyright 1996 by the Curators of the University of Missouri