You’re teaching Access for what seems like the hundredth time. All of a sudden, in the middle of explaining the relationship between the tables, you realize there are 10 sets of glazed-over eyes staring back at you dumbfounded. What do you do? Got any shining examples that will turn the light bulbs back on in their heads?
In reading through the forums this week, I found a forum question that specifically addresses this scenario. Donna, a TechRepublic reader, asked the following question:
“Does anyone have a technique for explaining the relationships among tables for beginning database students?”
If you have any Access tips you’d like to share, please post your comments at the bottom of the page.
Here are two randomly chosen tips that our TechRepublic readers shared with Donna in the Forum:
Draw them a picture
Beverly uses the following example to illustrate an overloaded table:
“I show them a large table with the following field names (abbreviated on the table):
- Job title
- Company car yes/no
- Make of car
- Car Reg
- Year of car
- Date of last service
- Garage used
Then I make them understand that although this information is all related, the table is too big. Considering the fact that the “date of last service” will only accept one entry and the “garage used” field would get too messy, the information must be separated into 3 tables.
|FName||LName||Job title||DOB||Salary||Company car yes/no|
|Make of car||Car Reg||Year of car|
|Date of last service||Garage used|
Then I explain the common denominator needed. Add “Employee ID” field to tables 1 and 2. I've found it is easier to explain the fields you're going to use for the relationship at this point, and not at the beginning. They then add the same field to both tables and they pretty much understand why they are doing it.
Finally, I encourage them to work out what common denominator would be good to link tables 2 and 3 together.”
Understand the experience of your audience first
Peter Nelson sent us the following:
“I think you must understand your audience’s experience level first. Here are two topics that I cover when I am teaching beginning database students:
Most users have an Excel view of the world. They think Excel is a database. So I talk about how they have to repeat lots of information, row by row, in order to have a complete "record" about something.
Just about everyone has called L.L. Bean (or Land's End or Eddie Bauer), so I run through the scenario about how you first give the rep your phone number or customer id. The rep then brings up your information and asks you for your order. You order two sweaters, some boots, and a tent. Then I ask the question, “Which do you think would be the better way to store the information?”
- Copy your address information over, and over, for each product you ordered.
- Save the address information once and then "access it" with a unique number?
When I present it this way, they understand the "goal" of trying to store data efficiently. What you’re really trying to explain is a normalized database design.”
Post your question in our Forums
If you have a training question, post it in our Forums. Your post just might become one of our next challenges. Please note that the size limit is 1,000 characters.
To post a question, you need to participate in our TechPoints program. To check if you're already a participant, click My Passport on the left navigation bar. Scroll down to the second section and make sure the TechPoints box is checked.
Then, go to Forums and choose a topic. Click the Ask A ? link. While you're there, don't forget to answer any questions you can for your fellow community members. Click here to go straight to the main Forums page .