It isn't as though we have set annual time tables like a professional
training organisation would have. The training where I work is done on an
ad-hoc basis and whenever its required so I will include a date field to say
when the employee did that course.

I had a discussion with BruceM which turned rather heated but it was my
fault for not being clearer than I should have been.

"Allen Browne" wrote:

The other important piece of the puzzle is that each course can be run
multiple times. Therefore employees enrol in an instance of a unit (e.g. the
2006 instance of "Basic Firefighting"), not just a unit

Therefore you need:
Unit table: one record for each subject that an employee can do:
UnitID primary key

Course table: One record for every time a Unit is offered
CourseID primary key
UnitID foreign key to Unit.UnitID
StartDate when this instance of this unit begins.

Enrol table: One record for every student in a course.
EnrolID Primary key
CourseID Which couse the person enrolled in. (Defines Unit too.)
EmployeeID Who enrolled in this course.
Outcome Whether the employee met all criteria

Employee table: One record for each person
EmployeeID primary key

The Enrol table above resolves the many-to-many relationship between Course
and Employee into a pair of one-to-many.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"scubadiver" wrote in message
...
...what I am missing?

If I have training courses and employees, I know that each employee
attends
many training courses and each course is attended by many employees. That
I
can understand.

If I set up a "1:n" relationship between "employee" and "course" I will
know
by DEFAULT who attended what course. Since I am assuming that this is the
purpose of having a "1:n" relationship between "course" and "employee"
doesn't this make the 2nd relationship completely redundant?

I could be entirely wrong ... *sigh!*