Graduate Student Database Project

Nicholas Wallen Department of Computer Science Florida State University Major Professor: Dr. David Whalley

n partial fulfillment of the re!uirements for the De"ree of Master of Science

Introduction
#ac$"round
n the Computer Science Department at Florida State University% trac$in" a student&s pro"ress throu"h the "raduate pro"ram has 'een handled separately and disjointly 'y the different staff mem'ers 'ased on (hat they oversee. )o(ever% as multiple aspects of the students data must 'e shared for various tas$s% this data is often shared via email and stored redundantly in e*cel spreadsheets across the department. +his manner of stora"e often leads to hardships (ith re"ards to ho( the data (as mana"ed% updated% and shared, (hen data needs to 'e updated% all copies must 'e updated manually (ith "reat care so that out of date information is not $ept and recirculated throu"h the system. n addition% various "overnmental and provisional 'odies re!uest periodic surveys to 'e done on the ma$eup of the student 'ody. Currently% this is done 'y siftin" throu"h hundreds of papers for all the students and countin" them manually. With a centrali-ed system% it could potentially ta$e a sin"le !uery to count the students on a moments notice.

.oal
+he o'jective of this master/s project is to create a data'ase to centrally handle the information of all the "raduate students in the Computer Science Department% and to provide access to this information (ith an easy to use (e'0'ased interface that can 'e accessed 'y any device (ith 'asic html renderin" capa'ilities.

1e!uirements
1e!uirements for the system fall into three cate"ories% those tendin" to(ards the usa'ility of the system% those to(ards the maintenance and alteration of the system% and those to(ards the security of the system. For the first re!uirement% accessi'ility (as addressed 'y ma$in" the system accessi'le

from the (e' via a standard (e' 'ro(ser% and no re!uired e*tensions% such as java% javascript% or flash. +he system (as also desi"ned so that the users (ould 'e a'le to complete the repeata'le tas$s in a streamlined manner to cut do(n on (asted time% and in a concise (ay to s(itch 'et(een tas$s. +o address the maintenance of the system% a modular desi"n (as used. +his (as done so that 'u"s can easily 'e found and additional features can easily 'e added to the system. +o address the security of the system% users are re!uired to run sessions over )yperte*t +ransfer Protocol over Secure Soc$et 2ayer% https.

Functional Description
Method of Use
+here are multiple users for this system defined 'y their role. First is the Director of .raduate Studies. t is this person/s jo' to initiate the student into the system 'y usin" the accept function. Usin" this functionality% (hen a student arrives at the university% the director accesses the list of accepted students and creates an entry for the ne( student into the "raduate student data'ase. +his is done 'y chan"in" the status under 3attendin"4 to either 3yes4 or 3no4 and hittin" the su'mit 'utton. +he list of students can 'e filtered 'y year% semester% and (hether the sou"ht de"ree is MS or PhD.

Fig. 1: Accept Function

+he ne*t jo' of the supervisor is to initiali-e the data (hen the student meets (ith the director to discuss the de"ree pro"ram re!uirements. 5t this time the director records into the system the class prere!uisites% and advisor status for the student. 2ater as the student pro"resses throu"h the pro"ram% the director can set the faculty mem'ers that are on the student/s defense committee if the student intends to defend a dissertation% project% or thesis. +o edit a student&s information in the system% the supervisor selects the 35lter student information4 'utton on the left panel% and selects the student to edit 6see Fi" 78. +he students can 'e !ueried 'ased on their status in the system. +he choices are 3attendin"4 for ordinary students% 3uninitiali-ed4 for students ne( to the system% and 3"raduated4% 3left4% and 3e*pelled4 for students no lon"er in the department. Selectin" the student to edit (ill ta$e the director to the pa"e to alter that student&s data 6Fi" 98.

Fig. 2: Alter/View Detail Function Student Select Page

Fig. !: Alter/View Detail Function Student Detail Page

+he final jo' of the director is to indicate that the student is no lon"er an active student upon the student&s "raduation or other(ise departure from the school. +his is done 'y a"ain "oin" into the 3modify permanent info4 form and selectin" 3de"ree status4 and chan"in" it to either e*pelled% left% or

"raduated. +he ne*t set of users of the system is the 15 mana"er and +5 mana"er. t is their jo' to record the semesterly information re"ardin" the students/ position and their related pay. For first time students% the data must 'e initiali-ed in the semester data ta'le. +o do this% the mana"er clic$s on the 35dd a +54 or the 35dd a 154 'utton on the navi"ation panel% and then chooses 3enter a sin"le student4 and then fills out the appropriate data for that student. 1ecurrin" students may 'e entered at the same time 'y instead choosin" 3enter students in 'atch mode%4 (hich copies a su'set of the students from the previous semester to the current one. Finally% the mana"ers can edit the information (ith the +5:15 matri* mana"er.

Fig " Add Single #A/$A

+he person in char"e of payroll also has access to the system to vie( the costs associated (ith employin" the +5s and 15s. +he payroll mana"er has read access to the +5:15 matri* that the 15

and +5 mana"ers use to input the financial information. +he names of the students (ere omitted from this vie(in" of the matri*.

Fig % #A/$A &atri' &anager

I(ple(entation
+he system (as (ritten to (or$ (ith a mys!l data'ase 'ac$0end to store the data% and is (ritten in Perl to create the pa"es to serve via apache. +he content of the data'ase is divided into four major components. +he first is the applicant information that the student su'mits (hen re!uestin" admission into the pro"ram. +his ta'le is pree*istin" 'efore the creation of this system% and (as adapted for its ne( use. +his ta'le is used to loo$ up the student D% name and standardi-ed testin" scores. +he second ta'le used is for data that is static for most of the student&s time in the department. +his ta'le holds the follo(in" data:

Fig. ) Per(anent In*o #able

+he id is the student D that lin$s the permanent information to the students entry in the applicant data'ase. +he username is the student&s username and email address% and lin$ is a lin$ to their picture. De"reeStatus descri'es (hether the student has 'een initiali-ed% has left the pro"ram% or is a currently attendin" student. De"ree+ype descri'es (hich de"ree the student is pursuin": computer science% soft(are en"ineerin"% or information security. De"ree2evel represents (hether the student is pursuin" a PhD% or a course% project% or thesis 'ased MS de"ree. StartSem and start;ear comprise the semester and year the student enters the system. 1oom is the student&s office room num'er. PostDe"ree<mp lists the students employment after leavin" the system. +he third ta'le used 'y the system is used to trac$ the semester to semester information of the student&s information throu"h the de"ree pro"ram. +his ta'le also uses an D field for referencin" a

student% and a semester and year field for the semester and year this entry trac$s. startDate and endDate mar$ the dates 'y (hich the appointment 'e"in and end. Fundin"+ype descri'es the type of position the student has and can 'e one of the follo(in": &+5 = M5& for a student teachin" a class in the CS major% &+5 0NM& for students teachin" a non0majors class% &+5 = 2 & for those teachin" a literacy class% &+5 0>1& for any other teachin" assi"nment% &15& for research assistants% &S.& for those in the systems "roup% and &>1& for all other jo' positions. ?o'code% projectcode% fundin"code% record% and employee D all represent codes needed 'y the school to descri'e the student&s jo' position internally. ?descripction descri'es the jo' and jSupervisor lists the staff or faculty mem'er that the student reports to for the jo'. )ours lists the num'er of hours the student (or$s (ee$ly. +each is a fla" that is set if the student is in a teachin" position.

Fig + Se(ester In*or(ation #able

+hree other ta'les are used 'y the data'ase to mana"e users and their privile"es. .radUsers% .radPa"es% and .radPrivile"es 6see Fi" @8. .radUsers contains the username and the pass(ord for the

account. .radPa"es contains pa"e D% used to uni!uely identify the pa"e% pa"e2in$% a lin$ that the script uses to find the correct section of code for that pa"e% and &pa"eDesc& (hich is a description for the end users to $no( (hat that pa"e is for. .radPrivile"es descri'es user privle"es 'y mappin" a user&s username to the pa"e D&s of the pa"es he has access to.

Fig , -ser Pri.ileges #ables

Sessions
User sessions are mana"ed 'y the Perl module c"i:sessions. c"i:sessions provides t(o (ays to trac$ users of the (e' pa"e. +he first is throu"h a coo$ie mana"ement system. +his mana"ement system (as not chosen for this project so that users (ithout a coo$ie supportin" 'ro(ser could use the system. +he second (ay of detectin" users is 'y callin" Asession0Bid68% (hich returns the id of the session% and em'eddin" the value in the (e' pa"e. When a related (e' pa"e is su'mitted to the (e'server% if it has a session id% the perl script connects to the data'ase server% loo$s up the id% and if it

e*ists% loads the saved data into the session varia'le. f the pa"e does not send a session id% the script "enerates one for it% and if it sends a faulty id% it returns the user to the lo"in screen.

)+M2
We' pa"e desi"n (as done (ith the aid of the perl module html:template. +his allo(s for the html to 'e (ritten in a template file separate from the perl code to increase code reada'ility and reusa'ility. When a template is called% the script loads data from the template and su'stitutes any perl varia'les in the template (ith the correspondin" varia'le in the script. Many different templates (ere desi"ned for the various pa"es% as (ell as a "eneric template for pa"es (ith less content. 5ll templates load t(o frames: &content&% for the specific content of the pa"e% and &noncontent& for items standard to each pa"e such as the lin$s to the different section and the lo"out 'utton.

Future /or0
While this project has supplied the 'asics for a system to $eep trac$ of students% many further enhancements are desired for "reater control of the information. +he first major enhancement (ould 'e for advisors to 'e a'le to lo" in and see the information for their students. +hey should 'e a'le to see (hat prere!uisites the students have ta$en% and still need to ta$e% as (ell as information a'out their jo'% pay% room assi"nment% and email address. +he advisors should also 'e a'le to fill out semester and yearly pro"ress reports on phd students (ho have advanced to candidacy. 5lso useful (ould 'e the a'ility to record (hich classes have 'een recommended 'y the student&s advisor% as (ell as ta$en classes and "rades made in said classes. 5nother useful addition to the system (ould 'e an e*tended system 'y (hich a student should e*it the system. Currently% the .rad Supervisor simply mar$s &"raduated&% &left&% or &e*pelled& in a

students status (hen the student leaves, instead% a system could 'e set that allo(s the supervisor to simply clic$ a 'utton and have the system automatically chec$ (hich "raduation re!uirements have 'een met% (hich are currently 'ein" (or$ed on% and (hich are unmet. >ther improvements to the system should relate to the maintenance of the system. +here should 'e some method for the users of the system to correct mista$es made 'y themselves that do not re!uire them to contact the (e'master to modify the mys!l ta'les to fi* the pro'lem. Similarly% user account "eneration% pass(ord mana"ement% and course and advisor status should 'e modifia'le from (ithin the user interface for privile"ed users. 5nother (ay the system could 'e improved upon is (ith the matri* mana"er. Currently% it re!uires the user to type in the values for each of the fields that are in the matri*. +he 'urden of typin" in the users could 'e eased 'y creatin" pull do(n menus for enumerated values and 'ooleans. 5 prototype for a more visually appealin" and intuitive template (as (or$ed on and implemented for the matri* mana"er. +his ne(% more user friendly desi"n could 'e propa"ated throu"hout the system. Finally% a "eneral !uery capa'ility should 'e added. +his feature (ill 'e very useful (hen attemptin" to fill out surveys re"ardin" our "raduate students% to ans(er !uestions from administrators% or to o'tain information for various reports.

1onclusions
n conclusion% a data'ase is a far more efficient mechanism to store and or"ani-e data than spreadsheets, it allo(s for a centrali-ed facility that can easily 'e modified and !uic$ly shared amon" multiple users. )avin" a (e' 'ased front end removes the re!uirement of users havin" to understand and use a data'ase directly% and allo(s users to connect from any(here (ith an internet connection and

a 'asic (e' 'ro(ser. t also allo(s the possi'ility of !ueries to o'tain information for various surveys. Due to the num'er of users readin" and modifyin" student data in the department% it is an ideal use for such a system.