Database Table Design
Database design is a complex topic, an art which few people seem able to master and
even fewer to explain. At a minimum, however, you should know the basic terminology
and principles of database tables. That’s what this topic is about.
Data Types
As you recall, the columns in a table are also referred to as fields. Just like variables in
VB, fields have data types. To confuse the issue, the names of the data types aren’t the
same between VB and DBMS’s. For example, what is called “String” in VB is called
“Text” in Access, and “varchar” in SQL Server. It’s too bad the people at Microsoft,
which makes VB, can’t get together with the people at Microsoft, which makes Access,
and the people at Microsoft, which makes SQL Server, to come up with consistent field
names, but apparently the people at those three companies just don’t get along.
Here are a few VB data types and their equivalents in Access and SQL Server:
VB
String
Single
Double
Byte
Short
Integer
Long
Access
Text
Single
Double
Byte
Integer
Long Integer
[doesn’t have]
SQL Server
varchar
real
float
tinyint
smallint
int
bigint
Field Names
Like VB, Access allows you to do things that will get you in trouble later. It won’t
complain (at least at first) if you give your field names are multi-word, contain
punctuation, or are actually Access keywords. However, sooner or later, doing any of
these things will lead to errors in either your database or in your VB program that uses it.
Therefore, use the following guidelines when naming your fields in Access:
 Don’t use Access keywords: Name and Year being the most common ones that
cause problems.
 Don’t use any punctuation except the underscore—no quote marks, apostrophes,
commas, etc. These make querying the table very difficult, especially from VB.
 Don’t use any spaces. If you want multi-word field names, use either internal caps
(StudentName) or underscores (student_name)—not spaces.
NULL Values
Fields can be set to allow NULL values, or not. NULL means “no entry” or “don’t
know.” NULL values can’t be compared to actual data values: NULL doesn’t equal
anything, nor is it greater than or less than anything. Fields which allow NULL values
generally correspond to fields on data entry forms which are optional: If the data might
be useful but isn’t required, allow NULLs. If the data is required, don’t allow NULLs.
Primary Keys
A well-designed database table will not have any two rows being identical. This is
enforced by requiring tables to have a primary key: A field or combination of fields
which uniquely identify one particular row and differentiate it from all other rows.
Occasionally, a table has a natural primary key—one which comes from the nature of
the data and which guarantees uniqueness. For example, a table of solar eclipses
could use the date/time as the key—with only one sun, one moon, and one earth, there
can be at most only one solar eclipse at a time.
More commonly, a table will have an obvious, though less natural, key which is a
standard identifier used widely by government or business. Examples include social
security numbers for employees, vehicle indentification numbers (VINs) for cars, and
ISBN’s for books. If you’ve ever organized a student group, you have probably used
either uniqname or student id as a key in your member list. If there is no natural or
ready-made primary key available, it is common for the database designer to create
one—some sort of identification number which uniquely identifies each record.
Sometimes, a table may have two fields which could qualify as a primary key: both
uniquely identify each record. At UM, StudentID and Uniqname are an example—
any list of students could use either one as the primary key. In this case, one is chosen
and referred to as the primary key; the other one is called a candidate key.
Finally, there are many instances where no single field will serve as a primary key.
This generally occurs in what are called correlation tables—tables which link two or
more tables in a many-to-many relationship (more on relationships in the next topic).
For example, consider a table listing all sections of all courses in the College of
Engineering. To completely specify a particular section, you would need to identify
the department, the course number, and the section number. These three fields
together make up the primary key. This is an example of a compound key—a primary
key composed of two or more fields.
That section table could have several non-key fields as well: room, time, instructor.
You could even eliminate section number if you wanted, since the combination of
room and time should also uniquely identify a section, as should instructor and time.
However, those candidate keys are much less useful than the department/course
number/ section number key, which is why department/course number/section
number is the key actually used.
Designing a Table in Access
Getting started designing a table in Access is pretty straightforward, although a little
different between versions of Access. I’ll assume you can figure it out. When you do
design a table, make sure you do the following (and don’t just leave things up to Access):




Assign data types carefully—don’t leave everything as text
Consider whether each field should allow NULL values
Set a primary key
Save the table with a descriptive name—the same name you would give to a
Structure or Class in VB.