design issue

[nati]

I've been appointed the lucky person to develop an inhouse training database. I have a few questions if you don't mind.

There will be several courses, each course will have many sessions and each session can be attended by many employees.

I'm seeing this as course to sessions as 1 to many, sessions to employees as many to many with a join file.

Some of the requirments are quarterly reports on courses, reports on completed sessions by employee, reports by year, etc.

This should be pretty straight ahead or am I missing something (yet again!)

many thanks,

nati

[Vaughan]

I designed a similar database a few years ago. It has a Courses database with course outlines and descriptions. This is related to a Dates datbase which is the day/session that the course is scheduled for. (There is also a Locations database to track where the course is scheduled, and an Instructor database to track who teaches the course that are related to the Dates file.)

A People database tracks the student's names and details. This and the Dates database are related to an Enrolments database which is where all of the real work happens.

How many files is that... six in total. It works well for us, but I did it years ago and as it was my first, there are things that I'd now do differently, mainly interface stuff. The data design is pretty solid.

[nati]

Hi Vaughn,

Thanks for your input. That's what I'm wondering here, is the sessions database the "real work" one? There are a finite number of courses, occasionnaly one may be added or removed, but there are always new sessions with new dates. So to me that is the "work" file. Create a new session, give it it's time and date, add employees from the employee file to it. Does this sound right?

Thanks,

nati