If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Setup Tables
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. -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/For...esign/200810/1 |
#2
|
|||
|
|||
Setup Tables
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. -- 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:8bec9869ef46e@uwe... 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. |
#3
|
|||
|
|||
Setup Tables
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. -- Message posted via http://www.accessmonster.com |
#4
|
|||
|
|||
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. |
Thread Tools | |
Display Modes | |
|
|