Thread: Setup Tables
View Single Post
  #4  
Old October 23rd, 2008, 03:03 AM posted to microsoft.public.access.tablesdbdesign
Allen Browne
external usenet poster
 
Posts: 11,706
Default Setup Tables

One course has many instances (Course and CourseDetails)

Students enrol on a CourseDetail, so you will have a CourseDetailStudent
table (the students in the particular CourseDetail.)

Sounds like you've already discovered there's quite a bit to a training
database.

--
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.

"QuestionsAcc via AccessMonster.com" u42698@uwe wrote in message
news:8c0f09115cd1d@uwe...
I like what you said about if the course is offered more then once of the
years. It will most likely be just twice a year that the course will be
offered. No marking(s) will be done. Simply will need to beable to run a
report later to see who attended the course and maybe a class list. I
don't
mind the extra work to make sure the database has the proper links and is
normilized. The database has about fifty tables, hundreds of querys, many
many many reports and forms; so I just wanted to make sure I set the part
up
correctly; I have spent over two years adding functionality. It has been
"live" for those two years, I simply add the new functionality on the
weekends. What I was thinking was a table for the course name and
descritions called "Courses", and then a table call "coursedetails". The
one
"courses" to many "coursedetails" relationship and have a link to the
"student" table. Sound right? Crap...gettting my self mixed up. Should I
have another table to combines the courses, coursesdetails and students
incase a studnet takes more then one course. This should be easy at this
point, however, I just can't think stright on this one.

Allen Browne wrote:
The former.

If a course may be offered more than once over the years, you have a
one-to-many relation between the course and the actual instances of the
course.

Students don't enrol in a course: they enrol in a course instance. Or it
may
be that courses are made up of units, and the students enrol in the unit
instances (or possibly the instances of the subjects that make up the
units
that make up the courses.)

BTW, there's a *lot* of work in setting up a database like that, tracking
students, lecturers, government departments (if the courses are
registered),
courses, course instances, the units that make up the course, the
instances
of those units, the unit coordinators, class dates, attendances,
assignments
set, assignments submitted (including re-submits), exams (and resits),
results achieved in assessments, results for the subjects/units,
certificates/qualifications issued, fees due, fees paid, applications and
enrolments, documentation, interactions with students, handling specific
issues (such as plagiarism), and the like.

I have my main database and have been asked to add additional
functionality.

[quoted text clipped - 13 lines]
These course will be offered many times over and over.....OR should I
just
continueally add new courses names, dates, times, etc. in one table.