Training records

[BruceM]

Is there a table with a listing of courses? How do the courses become parts
of the records you have described?

 

[Guest]

I have look up tables. The fields in tble_course will have combo boxes which
will select the appropriate course name depending on the course type, dept
and subdept.

The user hasn't got as far knowing which employees will have which courses
(but may likely depend on which subdept the employee is working in).

I appreciate the help about junction tables but I'm not convinced yet. In
principle it maybe considered important but for the practicalities of
entering information into a form, I still regard it as redundant. From my
example below, I don't need to establish a relationship that one course has
many employees when I can find this information just by using a query! Maybe
I'm missing something.

 

[BruceM]

Then go ahead and do whatever you want to do, but had I known your mind was
made up I would never have wasted my time attempting to explain junction
tables. But understand this: junction tables are not an abstract
theoretical concept, and they are not my personal little crusade; they are
*essential* to database design.

 

[Guest]

but had I known your mind was made up I would never have wasted my time attempting to explain junction tables.

BruceM - and all the others who spend their valuable time answering
questions here -

Your time is NOT wasted. There are people like me that spend time just
reading through these discussion groups, picking up ideas, learning new
things.

 

[BruceM]

Thanks for saying that. I too have picked up a great many things just be
reading messages. Some of the things I learned came from posts in which the
user resisted the suggestions. I usually don't let it get to me, but the
length of the exchange and the detail that went into it left me a bit
peevish, I guess.

 

[Guest]

One issue to consider in adding the supervisor field to the employee table:
IS it possible that an employee might, over the course of employment, have a
differnt supervisor. Might it be necessary at some point to report data based
on an employee's supervisor at the time a course was taken. Setting the
supervisor in teh employee table would almost certainly limit you to showing
data based on CURRENT supervisor only. I.e. if am empoyee is assigned to a
new supervisor then all courses taken by that empoyee are now linked to the
current supervisor.

I have a similiar situation, and used a "participant TRansaction table" much
like a point of sale tranasction table. The transaction table includes FK
links to employee, course, and session; with specific fields such as
supervisor, home department, registration, attendance, completion, and
certification. This way it is possible to report over the long term, all
attendance, and to indicate which supervisor and department employee reported
to at the time each course was taken.

If your personnel do not "move" around in the organization then this would
not be an issue!

 

[BruceM]

I do not see why this would be a concern. The person who conducts the
training is linked to the record that contains the training session or
course information. Parameter queries, report grouping, and other means can
be used to filter and arrange the records as needed. If it is necessary to
keep track of past supervisors, job titles, etc. then that information
should be stored in a separate History table rather than as part of the
employee's record. I do not understand your situation, in part perhaps
because I do not connect with the comparison to a POS transaction table.
You mentioned movement within the organization. What happens if an employee
gets promoted to Supervisor? What becomes of that employee's training
records in the pre-promotion days? Do you create a parallel record in the
Supervisor table? If you have a Yes/No field for Supervisor in the employee
table you can filter by that field to produce a listing of supervisors.