27-06-2012, 03:48 PM
Graduate Student Database Project
Graduate Student Database.pdf (Size: 762.81 KB / Downloads: 247)
Introduction
In the Computer Science Department at Florida State University, tracking a student's progress
through the graduate program has been handled separately and disjointly by the different staff
members based on what they oversee. However, as multiple aspects of the students data must be shared
for various tasks, this data is often shared via email and stored redundantly in excel spreadsheets across
the department. This manner of storage often leads to hardships with regards to how the data was
managed, updated, and shared; when data needs to be updated, all copies must be updated manually
with great care so that out of date information is not kept and recirculated through the system. In
addition, various governmental and provisional bodies request periodic surveys to be done on the
makeup of the student body. Currently, this is done by sifting through hundreds of papers for all the
students and counting them manually. With a centralized system, it could potentially take a single query
to count the students on a moments notice.
Functional Description
Method of Use
There are multiple users for this system defined by their role. First is the Director of Graduate
Studies. It is this person’s job to initiate the student into the system by using the accept function. Using
this functionality, when a student arrives at the university, the director accesses the list of accepted
students and creates an entry for the new student into the graduate student database. This is done by
changing the status under “attending” to either “yes” or “no” and hitting the submit button. The list of
students can be filtered by year, semester, and whether the sought degree is MS or PhD.
Implementation
The system was written to work with a mysql database back-end to store the data, and is written
in Perl to create the pages to serve via apache. The content of the database is divided into four major
components. The first is the applicant information that the student submits when requesting admission
into the program. This table is preexisting before the creation of this system, and was adapted for its
new use. This table is used to look up the student ID, name and standardized testing scores. The second
table used is for data that is static for most of the student's time in the department. This table holds the
following data.
Future Work
While this project has supplied the basics for a system to keep track of students, many further
enhancements are desired for greater control of the information.
The first major enhancement would be for advisors to be able to log in and see the information
for their students. They should be able to see what prerequisites the students have taken, and still need
to take, as well as information about their job, pay, room assignment, and email address. The advisors
should also be able to fill out semester and yearly progress reports on phd students who have advanced
to candidacy. Also useful would be the ability to record which classes have been recommended by the
student's advisor, as well as taken classes and grades made in said classes.
Conclusions
In conclusion, a database is a far more efficient mechanism to store and organize data than
spreadsheets; it allows for a centralized facility that can easily be modified and quickly shared among
multiple users. Having a web based front end removes the requirement of users having to understand
and use a database directly, and allows users to connect from anywhere with an internet connection and
a basic web browser. It also allows the possibility of queries to obtain information for various surveys.
Due to the number of users reading and modifying student data in the department, it is an ideal use for
such a system.
.