A Quick Review of Objects

An object is a representation of a physical thing or a process. Think of it as a noun. Let's return to our table of addresses. Our object is an address.

An object contains properties (or attributes) that describe it. Think of these as adjectives. The properties become the fields (columns) in our table.

The structure of the table represents the structure of our object.

In order to use an object, we need instances, or copies, of the object. These are the rows, or records, in our table. Each row (record) is a specific instance, or copy, of an address object.

All of this work should be done on paper first, before you actually get to the database. You want to know what the structure of your database will be before you create the tables.

Decide on a name for your object. For my example, it is an Address. The name of the table will be the plural form: Addresses.

Make a list of the properties for your object. You will now have your first draft of the main table. This is known as a flat-model database, because one table is used to store all the data.

A note regarding naming of tables and fields:

Avoid using any word that would be a reserved word in a programming language. For example, I might be tempted to use the field name "Type" to store the type of the phone number for one of my addresses (home, work, cell, fax). In this case, I would use the field name "PhoneType." Avoid spaces. These can cause SQL issues in your program.

You may, if you choose, follow the process of database normalization to re-work your main table and create your additional tables in a relationtional model. However, we have enough work to do in this course, so it is not necessary for our purposes.

If you choose to, the additional categorizations would actually become "look-up" values, and you would populate them by selecting from a drop-down list. I can provide more detail on how to do this if anyone is interested.

As you develop your tables, make sure that each table has a unique id - one field (column) that contains different value for each row (record). There is a lot of debate on creating unique id's for a table. Some people prefer to use a combination of fields to create the unique id. I prefer the single field scheme. Generally, I use Microsoft Access' auto-number capability. So, for my Addresses table, I will have a column called "AddressID" that will be an auto-number field. This guarantees a unique id for every record I add to the table.

Also, the unique id field should be declared first, at the top of the list in design view. Tables are accessed more efficiently when indexed fields are declared in the beginning.

Now you are ready to actually create the tables in the database.

If you have Microsoft Access, you can create it by reading the lecture "Using Microsoft Access".

If you do not have Microsoft Access, you can create it by reading the lecture "Using Visual Basic Data Designer".