Learning and Teaching Idea

[Guest]

Not sure if this will fly at all but thought I'd give this a shot. I'm
teaching myself Access and just picked up a workshop registration project
that will be a great learning experience. It addresses some basic relational
database concepts which I'm struggling with but I thought it might also be a
learning opportunity for anyone else out there who may be trying to teach
themselves the app.

I was thinking I'd post my steps to this point, ask questions related to the
next step and get the feedback. It would be a good step by step reference for
anyone out there who is or will be in a similar position.

So, here's the project description:

Workshop is a single day event with advanced registration. Registrants
provide basic information, Name, Business Addy, Email addy, phone, titles,
credentials, etc. They then select one seminar from a choice of 8 offered in
the morning and in the afternoon. The 8 choices are the same seminars the
only difference is the time they're offered.

I want develop a basic, easy to use data entry form and when the db design
is completed I'd like to:

1) Have a master list of all participants with their
contact information
2) Output sign in sheets that will correspond to the
classes the
registrants have selected. I'd like those to be Excel
sheets.
My actions so far:

- Built 2 tables: Registrant name and contact info table
and
workshop table containing the workshop titles

Which brings me to my first question:

One participant will have 4 choices, 2 workshop titles and 2 times of day
from which to choose (AM/PM) Should I build a 3rd table that will be a Time
of Day table, ie, AM/PM.

 

[Jeff Boyce]

Garnet

Were this my project, I'd probably not bother with the AM/PM table.

On the other hand, since one person can sign up for multiple sessions, and
one session could have multiple registrants, I'd probably want a table to
hold valid combinations of these two. These two are in a many-to-many
relationship, which Access can only resolve via a third table (variously
called a "junction"/"relation"/"resolver" table).

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Guest]

I would like to pass along a sugestion I received from this group. (Sorry I
don't remember who told me, BUT THANKS)

Find a copy of "Database Design for Mere Mortals Second Edition" By Michael
J. Hernandez. I got mine at Amazon.com. Spend some time reading it. I am only
3/4 through the book and have already totaly changed how I approach projects
such as yours.

It is written for us plan folks. Excilent book.

 

[Guest]

Ron, thanks for the suggestion on the book, got it yesterday and you're right
it's the most straightforward desciption of db design theory I've read thus
far. I'm getting used to the idea that it is a completely different language
and a completely different mind set than what I've been used to.

Jeff, after reading the first few chapters of Hernandez I understand your
response a little better. I am looking for a db with a many to many design.
I'll be back for some additional guidance.