Prototype Database for Managing a Large Self-Paced Introductory Microcomputer Applications Course
For most students and many college teachers, tests and grades are an unpleasant and unavoidable reality. Most schools require instructors to assign letter grades for each studentís work. Likewise, society, rightly or wrongly, deems these distinctions between high, passing and failing performance as important.
Few teachers enjoy the time-consuming and troublesome process of calculating and recording grades. The problems associated with evaluation are even greater for large classes. Software application programs can be used to automate the grading process, reducing both the tedium and the possibility of computational errors. However, the choices become limited and the needs more complex when enrollment exceeds 200 students.
The purpose this project is to find a viable solution for managing the evaluation process for a large, self-paced introductory course in microcomputer applications at a mid-size university. Several alternatives are investigated and needs, such as various reporting requirements, are taken into consideration.
A database management system was selected because it efficiently accomplishes three things: 1) gathers related data into a central collection, 2) reorders that data in various ways depending on need, and 3) retrieves the product of that reordering in a useful form without destroying the original data. Using Microsoft Access, a prototype grade management system is developed, tested and implemented. Concluding comments include a comparison between the database management system and a spreadsheet program as well as recommendations for improving the system.
Self-Paced Course
Microcomputers in Education (CI432) is a self-paced introductory microcomputer applications course. It is required for all College of Education students at the University of Nevada, Reno. Consequently, each semester its enrollment frequently exceeds the cap of 200. The semester this project was initiated there were 233 students enrolled.
The class meets formally only once, at the beginning of the semester. During this session, the students are given the syllabus and instructions as to how to proceed with the self-paced course. They are also asked to complete a Student Profile (see Figure 1), which is used to verify attendance and to capture skill-level information.
The course is designed so that students work at their own pace. They complete 10 modules from a study guide that includes a variety of hands-on activities. In addition, there is a reading assignment from the course textbook, Educational Computing: Learning with Tomorrowís Technologies, Second Edition, for each module. After completing a module, the student takes an online test in the computer lab that reflects learning objectives from that module.
Students are encouraged to do their work in the campus' Educational Computer Lab. A traditional method of easing the burden of large sections is to have one or more teaching assistants, or proctors, assist the instructor. The argument for this practice is that assistants can do much of the "grubby" work, freeing the professor to teach, grade and perform other class-management responsibilities.
Twenty proctors were selected from the current class to work in the lab. Information from the Student Profile is used to identify potential proctors. Only those students who express an interest are considered, and graduate students are given top priority. Students are then selected for interviews based on their skills indicated on the form. Preference is given to those with experience in Windows 95 and Microsoft Office products. Three of the Proctors are selected to be Graders. Instead of assisting students in the lab, these students would grade certain completed modules. Finally, the last criteria for proctors are availability and dependability, as these students must commit to two hours each week.
When a student finishes a module, they turn it in to a proctor who reviews the packet to ensure all required materials are present and completed. If anything is incomplete, the student is given the packet back to finish. As a receipt, the proctor initials the packet's cover sheet and the studentís study guide.
After much consideration, it was decided that the studentís modules were to be graded on a pass/fail system. While this may not be the most ideal way to grade studentsí work, it eliminates grading bias and minimizes the proctorís workload. If everything is done correctly and they earn a 70% or higher on the test, the student passes that module. Students are allowed three attempts at passing the test. Ten completed modules earn an "A," nine completed modules a "B," eight completed modules a "C," and anything less is a "F."
Grade-Management Options
Grades based upon points and percentage weighting offer a natural transition to computerized grade management. Additionally, by selecting the right software, students' grade-to-date printouts and individualized printouts can be easily provided.
Programs designed for grade management usually permit generation of: parent letters, proficiency reports, deficiency reports, grade reports for public posting, seating charts, attendance reports, line charts and second-language reports. Grading programs are generally easy to use, relatively inexpensive (prices range from $30 -$100) and available for both Macintosh and Windows operating systems. However, most do not have network capabilities and very few support large class sizes (most programs support a class size of 40-50 students.)
Spreadsheet programs offer another easy alternative for grade management. In fact, many of the grade management programs act and look like spreadsheets. Most spreadsheets programs even offer a generic grading template that is fairly easy to modify. Figure 2 represents a simple spreadsheet format that illustrates the grade management template provided by Microsoft Works 3.0.
Spreadsheets are probably one of the most popular methods for managing grades with university and community college teachers. When provided with some basic instruction, most teachers can easily create their own template. Spreadsheets have an assortment of advantages including built-in formulas, look-up features, and database capabilities such as sorting and extracting data.
Unfortunately, they do not provide the variety of reporting features needed for this course. Grading requirements for CI432 include accommodating over 2,000 "transactions." Information that needs to be captured includes: date the module was turned in, date and grade of the module test, who received the module, and who graded the module. These records need to be sorted by Student ID for public posting of received and completed modules, and by Proctor ID for workload summaries. Another report needs to be generated for tracking the proctorís time in the computer lab. In addition, the information on the Student Profile was intended to facilitate research comparisons regarding the successful completion and retention of course material to the studentís self-identified skill level. Finally, it would be desirable to locate and display only a specific student record for one-on-one student conferences.
The proposed alternative for grade management for large-sized classes is the use a relational database program. Once data has been entered correctly, the user can search it for all cases conforming to some predetermined criterion or combination of criteria.[1] The relational database model is an advantage to teachers in several ways: student information is entered into a table only once and linked to all their other relevant data, any variety of reports can be created, and inquires can be a one-time printout or tied to a permanent report.
An additional benefit of a relational database is that it can transparently load information into the computer's memory (RAM) when needed, and empty it again when necessary. This means that even computers with limited RAM can manage classes with virtually unlimited number of students, assignments and assignment categories.
Database Design
For the purpose of investigating this option, the author experimented with Microsoft Access and looked at the course management example that comes with it. This was a good exercise because it provided insight as to the options available and the SQL statements that could be incorporated to customize the grade management database.
To begin by designing a prototype instead of a full-functioning database program is beneficial for several reasons. First, with the potential size of the database, testing for operational and technical functionality is easier on a smaller model. Second, previously unidentified needs can be incorporated without jeopardizing the database integrity. Third, and most importantly, learning to use Microsoft Access is simpler with a smaller database.
The next step is to visualize the database by creating an entity relationship model (see Figure 3).
From this, four tables were identified:
- Students (student id, last name, first name, middle initial, phone #, major)
- Profile (student id, course id, experience, proctor, proctor id)
- Modules (student id, module #, date recd, proctor id, grader id)
- Switchboard (switchboard id, item number, item text, command, argument)
Students, Profile and Modules are related in that they share the primary key "student id." This simplifies linking tables and doing queries. There are two input forms: one for the students and one for the modules. There are four reports:
- A completed modules report sorted by student id and detailing all the completed and missing modules;
- An incomplete modules report sorted by student name, used to contact the students about modules that need to be finished;
- A proctor list; and
- A master student list.
The data for the proctor list and the incomplete modules reports are obtained from queries.
A menu is activated when opening the file. The opening menu offers the user options that include: modifying student records, inputting grades and previewing reports. The latter option leads to a subsequent menu allowing the user to pick from the four reports or to return to the main menu.
Conclusion
An efficient grade management system must assure both good quality of information and provide a simple way to retrieve that information. This project demonstrates that a database management system is a viable alternative -- offering many benefits over other options including spreadsheets. Consequently, the subsequent Microcomputers in Education classes will have a working grade management model in place.
In creating this prototype, grades were also maintained in a spreadsheet program. While this doubled the work involved, the purpose was twofold: 1) to determine the actual benefits of the database system over the spreadsheet system, and 2) to determine which system would maintain the most accurate data over time. It didnít seem like a fair fight, after all, the spreadsheet had been the system of choice for years and the database program was new and complex. However, when other elements were added, the database system faired much better than anticipated. A comparison of the advantages of each system is offered in Table 1.
INSERT TABLE 1 near here (or link to it)
The need for a structured approach to database design arises as both the amount of data and the number of users increase. Goals of the database design process are to ensure efficient data processing by eliminating redundant information and minimizing update and deletion problems. This became immediately obvious when using the spreadsheet. While initially easier to use and set up, many sheets had to be used to accommodate the variety of information needed. This created duplicate information on several sheets. On the other hand, in the database management system it was only necessary to input the data once in its respective table. Likewise, updating and deleting records only needed to be done in one place.
The process got further complicated as the proctor/graders were assigned the task of inputting grades. The database management system and its input forms reduced the amount of training required to get the graders up and running. A recommendation for future use is to add password restrictions to the database. Graders should be allowed to input grades, but not change grades or delete records. An additional feature that could be implemented is to have the proctors and graders input their start and end work times directly into the database, thus eliminating the sign-in sheet. Once again, security measures need to be added to minimize the changing of past hours.
The biggest advantage of the database management system is doing queries. Queries can be done in a spreadsheet program, but there is always the risk of overwriting the original data. Also, printing the queries in a report format can take a little more effort. Queries from the database management system can be done very easily with the Wizard feature, and results can be produced onscreen and/or printed out as hardcopy. Other advantages include the ability to save queries for later retrieval, to easily add headers and footers to the report, and name the column heading anything you want.
Sorting data in a spreadsheet is very easy, however, returning the data to its original arrangement is more problematic. Also, if all the necessary columns are not selected in the sort range, data can be mixed up. For example, one proctor sorted the data in the spreadsheet by Student ID so that the grades could be posted. Unfortunately, the column that included the studentsí name was not included in the sort range and, suddenly, all the students had new grades! To make matters worse, this error was not noticed immediately and more grades were input into the spreadsheet. The database printout had to be used to correct the spreadsheet, thus proving that data maintained in the database management system was more accurate.
Last, but not least, is the issue of reports. Four reports were originally created, but using the database management system easily generated reports and so several more were added. These included a proctorís workload report showing how many assignments each had received, a time log for the proctors showing how many hours they had worked in the lab, and a report showing how many modules had been turned in late and by whom.
For persons familiar with databases, the grade management template is an easy and valuable creation. For those not yet familiar with them, the time it takes to learn to create the template will prove to be a worthwhile investment in grading efficiency.
Todayís emphasis on technology integration, instead of on courseware creation, reflects a general move toward viewing computers as standard instructional tools, rather than as exotic newcomers to the business of teaching. The consensus on campuses across the country seems to be "Computers are here to stay; letís learn how to use them to our best advantage."
Beth Chandler is a doctoral candidate in the Department of Educational Technology at the University of Nevada, Reno. Before joining the Ph.D. program, Chandler has worked several years in various community and two-year colleges. She is a very active researcher and holds membership in various organizations. E-mail: [email protected] Nari Ramarapu is an Assistant Professor of Computer Information Systems in the Department of CIS at University of Nevada, Reno. His current research is in the areas of Nonlinear Information Presentation, Hypertext/Hypermedia, Global Information Systems and Applying Technology to Education. Ramarapu has published in the Information and Management, International Journal of Information Management, International Journal of Operations and Production Management, Journal of Information Technology, Journal of Systems Management, T.H.E. Journal and others. E-mail: [email protected]
References:
- Maddux, Cleborne, D., Johnson, D. LaMont, & Willis, Jerry W. (1997), Educational Computing: Learning with Tomorrowís Technologies, Second Edition, Needham Heights, MA: Allyn & Bacon.
- Greive, Donald, Editor (1989), Teaching in College, A Resource for College Teachers, Cleveland, OH: Info-Tec, Inc.
- Lowman, Joseph. (1984), Mastering the Techniques of Teaching, San Franciso, CA: Jossey-Bass.
Ricciardi, Sal (1994), "Database Design: Redundancy and Normalization," PC Magazine, January 25, 13(2), p285.
This article originally appeared in the 11/01/1997 issue of THE Journal.