Setup Tables

[QuestionsAcc via AccessMonster.com]

I have my main database and have been asked to add additional functionality.
What is needed is to create courses, with dates, times, fees, and other
particulates. Of couse they need to find out who is attending what, be put
on a waiting list, get list of who is attended who, etc. My question is as
follows. I know I will need serveral tables, some I already have; but the
data that I just need some help with is...realating to the courses. Should I
create two tables, one holding just the courses name, and maybe discrption
and of course the primary ID, and a second table that with have linked fields
with the course primary ID and will hold the times, dates, descrption, ect.
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.

 

[Allen Browne]

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.

 

[QuestionsAcc via AccessMonster.com]

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.

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.

 

[Allen Browne]

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

Reply to group, rather than allenbrowne at mvps dot org.

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.

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.