A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Setup Tables



 
 
Thread Tools Display Modes
  #1  
Old October 20th, 2008, 02:01 AM posted to microsoft.public.access.tablesdbdesign
QuestionsAcc via AccessMonster.com
external usenet poster
 
Posts: 4
Default 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  
Old October 20th, 2008, 02:39 AM posted to microsoft.public.access.tablesdbdesign
Allen Browne
external usenet poster
 
Posts: 11,706
Default 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  
Old October 22nd, 2008, 07:45 PM posted to microsoft.public.access.tablesdbdesign
QuestionsAcc via AccessMonster.com
external usenet poster
 
Posts: 4
Default 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  
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.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:20 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.