I have built a similar program for advising graduate students. I used
access. The key is in building your tables and relationships.
I have the following tables, you will most likely want something different
in specifics, but similar in structure. I probably should have a table of
'people' and pull both the students and faculty advisors from that table,
but since I only had to deal with less than five faculty members, I chose to
let that slip by.

Using these tables and some tabbed pages, with subforms, I got a reasonable
user interface simple enough that even a college professor with advanced
degrees can understand ;

Ed Warren

---------------------------------------------------------------------------sample
table structure--------------
Admission Data (stuff about the student's admission)
AdmissionID (key)
StudentID (fk)
DateAdmitted
DateWithdrew
DateGraduated
ProgramID (fk)
Comment
Course Availability (stuff about when courses are
offered)
CourseAvailabilityID (key)
CourseID (fk)
Semester date/time -- had to fight with the professors on this,
they think semesters start 'in September' and want to use two
fields (Spring, winter, fall) (year). Using just one field as a date you
can show the semesters in the proper, logical, temporal order.

Course Lookup (stuff about the course)
CourseID (key)
Department
CourseNumber
CourseCredits
CourseName

Course To Program (this maps a many:many relationship)
(stuff about courses and study programs)

ProgramID
CourseID (combined programid and courseid as key)

Email lookup (this is a lookup for types of email, e.g. school, home,
office) (a simple list of types of email)
EmailTypeID key
emailType

Phone Numbers (stores the student's phone numbers 1:M) (allow 0:m
telephone number for each student.
PhoneId (key)
StudentID (fk)
PhonetypeID (fk)
PhoneNumber

Phone Type Lookup (lookup table for types of telephone numbers (home,
office, cell, fax, etc) (a simple list of type of telephone)
PhonetypeID (key)
Phonetype

Plan of Study (ties a 'plan' of study (student/courses) to course
availability, completion, and date)
PlanID (key)
StudentID (fk)
CourseAvailabilityID (fk)
DateCompleted
Grade

Program Lookup (programs offered)
ProgramID (key)
ProgramType

Semesters (Semester List)
SemesterStartDate Date/time (key) (Note: I use a rather
arbitary date like Sept 01, 2005)
Semester (text) e.g. Spring, Fall, Summer

Student Demographics (student specific stuff)
StudentID (key)
FirstName
MiddleInitial
LastName
Address1
Address2
City
State
ZipCode
Comments
CurrentStudent (yes/no)
FacultyAdvisor

Student Email (allows 0:n student emails)
EmailID (key)
StudentID (fk)
EmailTypeID (fk)
EmailAddress




"BMB" wrote in message
...
I have recently had a large amount of data dumped on me and was asked to
organize it. If the data were finite, it wouldn't be a problem; but it is
subject to weekly updates with new records being added. This might take
some
explaining. . .

I work in a university program office and am trying to figure out the best
way to keep up with which students are in which degree concentrations,
each
of which has its own set of requisite courses. For example, there are 5
different degree concentrations with the program; one has only 6 required
courses, one has 16. I have projected dates that students anticipate
taking
the courses that are required for them (e.g., "Spring, 2007").

Keeping up with the basic data (name, address, phone, program, etc.) is
fairly simple. I have it set up in Access and Excel. But what I want is
some kind of smart form that will know which classes are required of which
students based on their concentrations and can create detailed reports
showing how many students are projected to take each class during upcoming
semesters.

Does this make sense to anyone? I'm looking at it and still not sure what
to do. Any help with deciding which application (and how) to use would be
most appreciated.