Lesson 6: Introduction to the Base Database
Rule 3—Plan!
The more complex the data, the more you need to plan. But even the simplest database should be
thought through on paper before being created in Base. Poor planning often results in a database
that fails to meet longer term needs. So think about your database ahead of time—and PLAN!!
When planning a database, the rule of thumb that should guide you is this: it becomes
increasingly difficult to make changes to anything the further along you go. If you think about it,
this is true of anything you create.
Here, then, are some words of wisdom that you should bear in mind when designing a database.
If you take your time up front it will save time later on
The database you create will have a long, useful life if you take time to plan it carefully.
After you have decided on the fields to include with each record, and before you create the
database, you should still invest time designing layouts for reports. Thinking about reports
will cause you to think about what data you plan to put in the database.
Teamwork helps
During the planning stage, run your ideas by others who are familiar with the kind of
database you have in mind. Network among your colleagues and friends. Tell them what
you have in mind. Ask them to review your design. You'll be surprised how many valuable
ideas they'll come up with that may have escaped you if you had relied on your own
resources. Another good idea is to involve your students in the design. This will help them
learn skills that will benefit them throughout their lives.
Keep fields simple
The more "atomic" your fields the more flexible will be your database. Atomic here means
"reduced to its simplest form." For example, in a database of names and addresses, you
would keep each part of the person's names (first, middle, and last) as a separate field.
Lumping the whole name under one field limits your options. The first name should be
stored by itself; the same for the middle name and last name. You can print a listing last
name first or first name last, with or without the middle name, and so on. By keeping the
data Atomic you have a wider range of choices when working with the data in the database.
Design guidelines for a Student Roster database
You have to build a database for a Student Roster. Let us say that your planning has helped you
decide the following about the database and its use:
• You have decided that the database will be accessible to, and managed by, your students.
Each of them will enter their own data at the beginning of the year. You will advise them
that they are not obliged to fill out every field—that it is OK to leave entries blank. Privacy
is an important issue to which our students need to be sensitized. We need to take every
opportunity to teach them that they should exercise control over data about themselves. They
must make decisions about what is, and is not, privileged information. In a world where,
inevitably and increasingly, personal data will be available to whoever wants to use them,
our students must learn early on in their lives that they have a responsibility to keep tabs on
their own personal data so as to ensure, as far as is humanly possible, that the data are correct
at all times. Managing their own records on the class database will give them valuable
experience in dealing with issues of privacy such as this.
• You have decided on a list of fields for each record in the database.
• You have decided that all the fields will be treated as simple text, except the Date of Birth
field, which will be of Date type, and the Brothers and Sisters fields, which will be of Number