Database Mark Analysis

CSC303S Database Assignment 2004 Hilton Jacobson JCBHIL002 Alex Karpul KRPALE001 David Seaward SWRDAV002

Plagiarism Declaration
1. I know t hat plagiarism is wrong. Plagiarism is t o use anot her s work and pretend that it is ones own. 2. Each cont ribut ion t o t his pract ical/ t ut orial from t he work(s) of ot her people has been attributed, and has been referenced. 3. This practical/tutorial is my own work. 4. I have not allowed, and will not allow, anyone t o copy my work wit h t he intention of passing it off as his or her own work.

Student number: JCBHIL002

Student number: KRPALE001

Student number: SWRDAV002

Specification
The purpose of t his dat abase applicat ion is t o provide a t ool for analyzing st udent result s. As well as t hree fixed funct ions, an adapt able funct ion is provided, allowing t he course convenor or ot her UCT administ rat or t o make their own analysis function. The aim is to provide a tool to extract, combine and display results in a useful fashion (i.e. not as raw data) by allowing the user t o creat e t heir own funct ions, we have creat ed a t ool t hat allows t hem t o discover influencing fact ors. The st at ist ical significance of t he analysis is beyond t he scope of t his proj ect , but would be a useful addit ion in fut ure development.

Design
For t he purposes of t he proj ect , our first st ep was t o det ermine what raw dat a was required. The specificat ion included reference t o personal and school details for st udents, and course det ails and result s. By delineat ing t he relat ionships bet ween t hese dat a clearly, we were able t o draw up t he following ER diagram as the basis for our database:
Surname Name DOB Address Student_no Joined Year _matrc

Students

Progress Res

AYOS

4..*
Student_no Course_code Year Mark Supp

5..9
Student_no Subject

Mat_Ex_Body

Course_ Results

Matric_ Results

Mark Grade

Courses
Course_code

Description Credits

Description

Matric_Subjects
Course_code

Important elements of the diagram to notice are: All basic st udent dat a is st ored in [Students]. In act ualit y, t his dat a might be st ored in separat e dat abases across a net work. (e.g.

residence dat a wit h St udent Housing, biographical dat a wit h St udent Records). The attribute (Address) stores the student s suburb of residence. The at t ribut e (Mat _Ex_Body) has been added t o [Students]. This indicat es t he Mat ric Examinat ion Body (e.g. provincial or IEB) and is used in one of the fixed functions. (Joined) refers t o year st udent j oined UCT, (Year_mat rc) is t he year in which the student matriculated, and (Res) indicates whether or not the student is in residence (used in a fixed function). [Courses] and [Mat ric_Subj ect s] are self-explanatory, but t heir respective relationships wit h [St udent s] are t he core of t he functionality of this database. <Course_Results> cont ains a part icular st udent s exam result s for a given course and year. This means t hat each of (St udent _no), (Course_code) and (Year) are part ial keys i.e. t oget her t hey define a unique exam result . That result is st ored as a (Mark) and possibly (Supp) result (Supp) is the only field that may be null. Whet her or not a st udent can writ e a supp, or whet her t he dat a is valid is out side t he scope of t his proj ect . Any int errogat ions or calculat ions wit h t hese result s are handled wit hin t he respect ive funct ions, what is st ored here is simply t he raw dat a. When a st udent passes a supp, t heir final mark is always 50% , but in t his dat abase we store t he act ual result , and leave it t o t he funct ion t o calculat e t he final value. Every student has taken at least four courses. Three of t hose courses are: AARPENG, AARPMAM and AARPNUM. The AARP t est s have been included as 0 credit courses rat her t han being st ored in a special t able. By collect ing dat a in t his way it is easier t o extract. <Mat ric_Result s> is similar t o <Course_Result s> except t hat only a (Mark) and (Grade) are st ored. Every mat riculant has t aken bet ween 5 and 9 subjects. Note that matric data that does not need to be repeated (e.g. year of matriculation) is stored in [Student] rather than <Matric_Results>. From t his diagram it is clear t hat each of t he ent it y set s and relat ionships should be st ored as a separat e t able in t he dat abase, wit h t he at t ribut es as fields. Keys are as indicated in the diagram.

Analysis Functions
Multipurpose FAF Analysis
The Fundamentals Analysis Function st art s wit h a menu t hat asks whet her you would like t o view informat ion t hat relat es t o course codes and st udent information. Under t he course code ent ry it asks quest ions of t he user unt il it can generat e a query t hat ret urns wit h t he result s of Average Mark for t hat course, Pass Rat e and Failure Rat e. It also does t his by grouping by year. The year can be select ed or all years can be given. To see t he line of questioning refer to the diagram below. Under t he st udent informat ion ent ry it asks whet her you want t o see a specific st udent s informat ion. If t his is select ed t hen it asks for a st udent number and brings back t he st udent s det ails, t heir mat ric marks and t heir UCT marks. If t he opt ion is not select ed it brings up a menu of filt ers t hat can be applied t o t he course result s t hat will eliminat e all result s t hat are not in those filters. Again to see the line of questioning see the diagram

FAF
Course Code

Year

Average Mark

Pass Rate

Failure Rate

Specific Year

Student Information

Single Student

Filters

Student Number

Filter by Name

Filter by Surname

Filter by Suburb

Filter by AYOS

Filter by Year Matriculated Filter by Course code Exit

Filter by Year Joined UCT

Alexs Analysis of how places where students live relate to their marks over a time period
This Analyzer is t arget ed at t he admissions office and t o see where it would be best t o purchase land for resident st udent s. The User is asked for t he beginning year and end year of t he period t hey would like t o observe t hen the SQL query starts It st art ed by going t o t he [Students] t able and ext ract ing where t he student lived. Then going t o t he <Course_Results> t able and get t ing t heir (Marks). It t hen calculat ed in SQL t he average mark grouping it by where t he st udent s lived and by t he year t hat it was done. It t hen discards in SQL all years that dont fall in the time period. The funct ion t he receives t his informat ion and proceeds t o ext ract it int o t he correct cells of a t wo dimensional array and print s it out in more or less t able format . The t able would be more complet e if t he dat abase had been filled in more t horoughly. Unfort unat ely due t o t ime const raint s and t he immensit y of t his t ask it would not really be possible t o populat e t he database with extra students and where they live.

Davids AARP/MEB Analysis

The purpose of t he A/ M Analysis funct ion is t o provide st at ist ics for the convenor of a first -year course such as ECO110F. Year-by-year result s of t he AARP t est s are ret urned, grouped by Mat ric Examining Body (and % (t he SQL wildcard), i.e. a grand t ot al). Result s for t hat course are also ret urned, namely pass rate and minimum, maximum and average marks. The pass rat e t akes supp result s int o account (supp passes are count ed as a pass), as does the average function: Mark Pass (50 Count _ Supp _ Pass ) Fail Count _ Total

Thus supp passes count as 50% , ot her result s count as t he act ual mark obtained in the exam. The funct ion ext ract s t he best performing MEBs in each AARP t est , and in t he course. These should give t he convenor an indicat ion of which results are more likely t o have a st rong correlat ion. Act ual correlat ion fit ness t est ing is beyond t he scope of t his proj ect , and would require ext ensive dat a over at least five years t o produce meaningful result s. At t he moment , t his t ool should provide a course convenor wit h a st art ing point . (For example, one would expect t hat higher AARPENG always indicat es bet t er result s, whereas in Science and Commerce courses AARPNUM and AARPMAM would have more influence t han in Humanit ies courses. It would be possible t o det ermine t hat AARPENG results are significant ly lower wit h students mat riculat ing under a part icular examining body, suggest ing that an ext ra courses should aut omat ically be suggest ed t o st udent s applying from t hat area/body.)

When using t his funct ion t he course convenor first ent ers his or her course code, t hen t he years t o analyse. If t he st art ing year is 0 , t he funct ion ext ract s t he first and last year t he course has result s from the <Course_Results> table and uses that as the range. For each year raw data is ext ract ed for each MEB (including % ) and t he pass rat e and average are calculat ed. Result s are displayed in a simple t able, and t op performers are recorded below. A result of -1 indicat es a null for t hat field (e.g. a null ent ry or a null result , such as when t here were no st udent s from a particular board who wrot e an AARP t est in t hat year). For t he purposes of seeing some int erest ing result s in t his dat abase it is recommended using t he course ECO110F as it is heavily populated.

Hiltons Residence Analysis

The goal of my analysis is t o find out whet her living independent ly in residence affect s a UCT st udent . In order t o achieve t his, I compared st udent s wit h equal abilit y, i.e. st udent s wit h similar mat ric result s, and whet her t hey live in residence. My SQL query gave t he averages of a resident and non-resident st udent s mat ric and UCT marks. These figures were pulled from the [Students], <Matric_Marks> and <UCT_Marks> tables. I made sure t hat each resident st udent was compared wit h a non-resident student with a similar average matric mark. The results showed that six out of the ten resident students had lower marks compared t o t he marks of t he non-resident st udent wit h similar mat ric result s. To get an overall assessment of t he difference, I averaged all resident and non-resident st udent s average UCT marks. The result , from our designed dat abase, showed t hat t he average UCT mark for a resident student was 59, compared to 60 for a non-resident student. This reveals, surprisingly, t hat living in residence does not significant ly affect a UCT st udent s marks. It would be int erest ing t o know t he result of t his analysis using act ual dat a on UCT s dat abase, unfort unat ely our database is relatively small and random.

Testing
The main purpose of t est ing is t o confirm t hat a function can deal wit h out liers and ot her odd (but valid) data ent ries. In populat ing t he t ables, though, we also discovered it was useful in checking t hat t he code was implemented correctly, for example in dealing with valid null values. For each funct ion we select ed result s t hat we could calculat e manually and alt ered t hem slight ly t o confirm t hey were implement ed correct ly. We also creat ed t uples t hat confirmed our SQL queries were ext ract ing t he correct set s each t ime. (For example, consider t he difference bet ween a st udent who writes a supp and passes, versus writing a supp and failing.) We also used t he FAF query analyser in performing calculat ions and selecting test data for the fixed functions. 5

Future improvements and extensions

As well as populat ing t he dat abase wit h more ext ensive ent ries (particularly st udent s and result s), a significant ext ension would be t o implement statistical add-ons t o our current functions; t his would allow us t o confirm fitness-of-t est and significance of result s. This would require a st at ist ician t o look at our funct ions and det ermine what t est s are required, which we would then implement. Anot her ext ension would be allowing a choice in int erpret ing supp result s. One may want t o ignore supps and look at init ial result s only (48% does not become 50% even if t he st udent passes t heir supp), or count supp result s as t heir act ual values rat her t han 50% (get t ing 75% in a supp would count as a first), or the default option of counting supp passes as only 50%.

Teamwork
All members cont ribut ed t o each sect ion of t he proj ect , including commentary and revisions, although we found it more effective to designate a leader for each maj or part : aft er t he team design phase Alex was in charge of coding, David edit ed document at ion and diagrams and Hilt on implemented the database and populated test data. Each fixed function was designed, coded and documented by individual members.

I hope I passed my Politics supp

This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.