IEEE ©1998 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Return to Table of Contents


A Cooperative Learning Approach to Database Group Projects: Integrating Theory and Practice

Suzanne W. Dietrich  and Susan D. Urban 


Abstract - This paper describes the use of cooperative learning concepts in support of an introductory database management course that emphasizes the theoretical and practical aspects of database application development. The database practice is realized through the use of cooperative group projects. The course project is divided into three main phases, involving requirements analysis and conceptual design, relational database mapping and prototyping, and database system implementation using Microsoft AccessTM. Students are required to actively participate in each phase, with students assuming different roles in each phase to allow them to experience different leadership responsibilities. This paper also describes a cooperative learning approach to integrating the practical use of a database product into the theoretical curriculum of a database management course. The paper concludes with a detailed evaluation of the group projects effect on the student's performance in the class.


Outline

Introduction
Course Curriculum
Project Content
Group Administration
Integrating Database Use into the Curriculum
Evaluation of the Approach
Conclusions and Future Research
Acknowledgments
References
Contact Information
Biographies


I. Introduction

The study of database management systems has always been an important aspect of computer science education in support of practical business, scientific, and engineering data access needs. With the current explosion in information access associated with the World Wide Web, the management of data has elevated to an even more critical level in computer science education. Database education, in particular, has matured to the point where there is a strong base for teaching database theory and a strong practical side to the use of database management systems [9]. Database theory is important, not only because of the foundation it provides for research, but also because it is a prerequisite for effective use of database management systems [1]. Database practice is important for preparing students to address the needs of real-world applications. As a result, there is a wealth of both theoretical and practical material that must be covered within a typical undergraduate course on database management systems. It is important, however, to achieve the appropriate balance of theoretical and practical concepts. The focus of database education must remain on teaching concepts that students can apply within any database system, rather than teaching the mechanics of using a specific database product.

Another concern with respect to database education is the overall approach to teaching database concepts, such as the use of cooperative learning [6] in the college classroom. In cooperative learning, in contrast to individual or competitive learning, students work in small groups, helping each other learn the assigned material. Cooperative learning has advantages that go beyond simply learning the course material. In particular, cooperative learning often emphasizes oral and written communication and provides students the opportunity to improve their leadership capabilities. These issues are an orthogonal aspect of the educational process that many employers view just as important as technical capabilities.

This paper describes the results of a three year grant on the use of cooperative group projects in an introductory database management course (CSE 412) within the Department of Computer Science and Engineering (CSE) at Arizona State University (ASU). The development of our particular approach has been supported by an award from the National Science Foundation under the Leadership in Laboratory Development Projects component of the Education and Human Resources Program (Grant No. DUE-9451489). The primary emphasis of the course is on theoretical issues of the relational model and relational query languages as well as systems issues of relational database management systems. Cooperative group projects are then used to provide hands-on access to a commercial database product. As a result, students have the opportunity to apply their knowledge of database theory within an actual design and implementation project.

The course project is divided into three main phases, involving requirements analysis and conceptual design, relational database mapping and prototyping, and database system implementation using Microsoft AccessTM. The project deliverables are designed so that students not only develop a database implementation, but also evaluate their design from a theoretical point of view, thus establishing the need for sound database design principles. Students within each group are required to actively participate in each phase, with students assuming different roles over the course of the project to allow them to experience different leadership responsibilities. As part of the grading process, students must evaluate their own performance as well as the performance of others in the group. Our experience with this approach indicates that overall student performance in the course has increased, giving students a sound understanding of database concepts and, at the same time, providing them with practical database and group interaction experience [4].

A challenge within this course has been the integration of the use of a commercial database management system into the database curriculum [12]. The difficulty of supporting a practical database implementation effort is to integrate the use of a database product into the curriculum without reducing the content of the course to a commercial database training course. We have developed an approach that minimizes the amount of class time that is allocated to teach students how to use a database product, while at the same time providing guidance for students in the use of such a tool. As with the entire group project experience, introduction to the use of the database management system is performed using cooperative learning concepts, where students help other students learn the intricacies of the system. To assist in the cooperative learning process, we have developed a complete database implementation example. The example represents the scope of the project to be implemented as part of the course. Using this example, students advance from a tutorial exercise, to a step-by-step extension of the example, and finally to more difficult extensions. Our approach only requires two class periods devoted to the discussion of Microsoft Access, with most of the discovery of how to use the system performed as out-of-class group activities. The content and timing of the exercises, however, is critical to the success of the project. The approach that we describe is general enough to be tailored to any introductory database course and any commercial database product. Furthermore, all of the material that we have developed is available for public use (http://www.eas.asu.edu/~cse412).

In the remainder of this paper, we provide an overview of the database curriculum for CSE 412. We then describe the structure of our approach to group projects and discuss the administrative aspects of using group projects. We also describe the details of the commercial database introduction process, followed by a detailed evaluation of our project approach. The paper concludes with a discussion of future research directions.


II. Course Curriculum

The topic of database systems has become an important educational component within the CSE Department at ASU. Enrollment within CSE 412 averages approximately 40 undergraduate students a semester, with an additional 20 graduate students that take the course as a prerequisite to more advanced database courses, such as deductive database systems, object-oriented database systems, semantic data modeling, distributed database systems, and multimedia database systems.

Prior to the 1994-95 academic year, CSE 412 emphasized theory rather than practice due to: 1) the dilemma of what to teach from the myriad of topics available for a 15 week database management class, and 2) a lack of database computing resources. At that time, we only used cooperative learning in the database classroom through informal groups working on study problems. In the 1994-95 academic year, we modified the course structure of CSE 412 to provide a better balance between the theory of database management systems and the practical application of that theory as a result of funding from the NSF award described in the introduction to this paper. The curriculum changed by removing coverage of legacy databases, such as network and hierarchical databases, and introducing cooperative group projects that focus on the practical aspects of databases using relational database technology.

The topics covered and the order in which they are presented are tightly integrated with the semester-long group project and the individual homework assignments on relational query languages. Table I provides a weekly view of the course curriculum topics and how they integrate in a timeline with the course assignments and exams.

The theoretical curriculum of CSE 412 starts by covering an introduction to database concepts and the design of database systems. The concepts of conceptual data modeling are introduced through the use of the Entity-Relationship (ER) model. We then cover the relational data model as an implementation data model and the heuristic process of mapping from ER conceptual schemas to relational database schemas. The fundamentals of expressing queries over a relational database are introduced using the relational algebra query language. We also address query optimization so that students become aware of efficiency issues related to expressing and processing relational queries.

TABLE I
Weekly Timeframe

WEEK

Topics and Assignments

1

Introduction

Database Design Overview

2

Assign: Phase 1 - Analysis & Design
Project Overview & Teams

Entity-Relationship (ER) Conceptual Model

3

ER Model
Study Problems

Relational Introduction
ER-to-Relational Mapping

4

Due: Tutorial
Introduction to MS Access

Due: Phase 1 Intermediate - ER diagram
Relational Algebra

5

Return: Phase 1 Intermediate
Assign: HW 1 - WinRDBI Rel. Algebra
WinRDBI
Relational Algebra

Relational Algebra

6

Due: Phase 1 (Step-By-Step Extension)
Assign: Phase 2 - Rel. Design & Prototype
Project Presentations
Relational Algebra

Query Optimization
Project Presentations

7

Due: HW 1
Return: Phase 1
Relational Design

Relational Design

8

Return: HW 1
Exam Review
Relational Design

Midterm

9

Relational Design

Due: Phase 2 Intermediate
Return: Midterm
Relational Design

10

Return: Phase 2 Intermediate
Tuple Relational Calculus (TRC)

Assign: HW 2 - WinRDBI TRC & DRC
Domain Relational Calculus (DRC)

11

Due: Enhancements
MS Access Assessment

SQL

12

Due: Phase 2
Assign: Phase 3 - Implementation
SQL

Due: HW 2
Assign: HW 3 - WinRDBI SQL
SQL

13

Return: Phase 2
System Catalog
Transactions

Return: HW 2
Recovery Control

14

Due: Phase 3 Intermediate
Concurrency Control

Due: HW 3
Return: Phase 3 Intermediate
Concurrency Control

15

Security & Authorization
Student Evaluation & Survey

Due: Phase 3
Return: HW 3
Exam review

16

Project Demonstrations

Final Exam

At this point in the course, students have a good understanding of the relational model and the use of relational algebra, providing the necessary foundation to address more theoretical issues related to relational database design. In particular, we address functional dependencies and the use of normalization to avoid the occurrence of update anomalies. We also address issues related to lossless join and dependency preservation properties, as well as the use of functional dependencies in top-down and bottom-up design strategies.

After covering the theory of relational design, we complete our coverage of relational query languages. We first address the more theoretical languages of tuple and domain relational calculus, providing students with a basic understanding of the relationship between logic and databases. We then turn to the more practical side of query languages by introducing SQL. Students learn SQL rather quickly since they are already familiar with the underlying algebraic and calculus issues related to relational database query languages. Specifically, the basic select-from-where statement of SQL is defined in terms of relational algebra, and the similarity of a tuple relational calculus statement and an SQL select-from-where statement is clear.

The remainder of the semester is devoted to coverage of more systems-oriented issues related to transaction processing and concurrency control. In particular, we cover transaction logging, rollback and recovery issues, and the theoretical aspects of serializability. We then cover concurrency control protocols such as time-stamping and two-phase locking. The course ends with coverage of security and authorization issues.

As indicated in Table I, there are three individual homework assignments given during the semester. These assignments involve the use of an educational tool, which was developed at Arizona State University, to test the student's understanding of the formal relational query languages (relational algebra, domain relational calculus and tuple relational calculus) and the industry standard query language SQL. The RDBI [2] educational tool and its Windows-based version, WinRDBI [3], are based on the connection between databases and logic programming. The data and meta-data are stored as Prolog facts. A query in each of the query languages is parsed and converted into Prolog code, which is then executed to evaluate the query over the Prolog database. The students use the same database enterprise in a sequence of individual assignments. The task of creating the database instance for these individual assignments is the responsibility of the teaching assistant, since the students will experience the creation and population of a database within their group project. In the first assignment, students learn how to use the educational tool and answer queries over the database in relational algebra. The subsequent assignments on relational calculus (both domain and tuple) and SQL are over the same database enterprise. Some of the queries change in the subsequent assignments, especially for SQL where queries are included to reinforce the concepts of aggregation and grouping.

Grades in CSE 412 are based on the midterm exam (20%), the comprehensive final exam (30%), the WinRDBI assignments (15% - 3 at 5% each), and the group project (35%). Individual performance is therefore worth 65% of the grade while the rest of the grade is based on group activity. The following sections describe the group project in more detail.


III. Project Content

Before introducing group projects into our undergraduate database management class, we looked at other approaches [1, 7, 10, 11] to the use of projects in database education. Apenyo [1] describes a two semester database management course, where the first course focuses on theory and the second course focuses on practice with students working in teams to develop an actual database design and implementation, rather than the one semester course that our work is targeting. Leeper [7] also describes a team design project for a database management course but focuses on the integration of individual subportions of the project. Other approaches to database team projects are described by Saiedian and Farhat [11] and by Pigford [10]. Saiedian and Farhat describe an approach where each team implements a database application in six different phases with documentation due after each phase. Pigford describes an approach to database design teams that is close in content to the team approach used in our curriculum. Pigford's work, however, does not describe the organization of the team itself. In fact, most of the above projects have not focused on the different roles that exist in team projects and the way in which students can have the opportunity to assume different roles. These projects did not mention evaluating the participation and contribution of a group member as part of the assessment process or guiding the students on the use of a commercial database product.

The practical component of our course introduces the use of a database product to support the implementation of a realistic application as a semester-long cooperative group project. Each group of 4-5 students is responsible for identifying the specific application to be developed and for identifying the expert in the application area to provide input in the design and development of the database. The project is divided into three phases: 1) requirements analysis and conceptual design; 2) relational database mapping and prototyping; and 3) database system implementation. Students within each group are required to actively participate in each phase, with students assuming different roles (leader, recorder, checker, technical advisor) over the course of the project to allow them to experience different leadership responsibilities. Each phase has specific technical deliverables, which are identified later in this section, and assessment deliverables, which include group status reports, confidential evaluations (self and peer) and team assessment. The assessment consists of questions in which students must assess their understanding of the course material with respect to their own projects. We also use the team assessment to introduce the use of the commercial database product.

Phase 1 is the requirements analysis and conceptual design phase, which is currently allocated 4 weeks. The technical deliverables due at the end of this phase include: a description of the requirements; an Entity-Relationship (ER) diagram with structural constraints specified; a list of constraints that are not captured on the ER diagram; and a summary of processing needs, categorized with respect to expected forms, reports and queries. Two weeks into Phase 1, the group must hand in both the requirements description and the ER diagram for review. The instructor provides feedback on these intermediate technical deliverables by the next class meeting. This feedback is based on the consistency of the requirements description and the ER diagram, as well as the scope of the project. Also, at the end of this phase, each group must give a brief class presentation on the enterprise that they have chosen for their project. This presentation is given by a group-designated speaker, who is typically the group liaison to the expert user.

Phase 2 is the relational database mapping and prototyping phase, which is currently allocated 6 weeks. After receiving detailed comments on the conceptual design in Phase 1, the group may need to refine the ER diagram before beginning the definition and prototype of the application. The intermediate technical deliverables include: a refined ER diagram; a relational schema for the enterprise that indicates the attributes and keys of each relation; a list of functional dependencies holding on the enterprise; a discussion of their relational design with respect to normal form, lossless join and dependency preservation properties; and a revised summary of processing needs, categorized with respect to forms, reports and queries. This gives the students the opportunity to apply the design theory learned in class to their realistic application. The technical deliverables at the end of the phase include updates of the intermediate technical deliverables and a prototype of the database implemented in Microsoft Access. This prototype includes the definition of the schema, including referential integrity as defined via the relationships window in Access, and a prototype of the forms and reports listed. Each group member must be responsible for the prototype (and later implementation) of at least one form, one report and one query from the processing needs identified in Phase 1. Only the look and feel of the forms and reports are required for this phase.

Phase 3 is the database system implementation phase, which is allocated 4 weeks. There are no intermediate technical deliverables for this phase. This phase is dedicated to the correctness of the implementation of the database system, including robust test data. The technical deliverables due at the end of the phase include a revision of the Phase 2 technical deliverables excluding the discussion of the relational design theory, and a complete implementation of the database application. The Access implementation is demonstrated by the group, typically during the week of final exams.


IV. Group Administration

Our approach to administering groups was influenced by the cooperative learning literature [6]. Some of the basic elements of cooperative learning that we have incorporated into the group projects include positive interdependence, face-to-face promotive interaction and individual accountability. Positive interdependence is realized through the shared group goal of implementing a database application by the end of the semester. The assessment deliverables promote face-to-face interaction of the group through the discussion of the answers to the assessment questions. Individual accountability is addressed through the confidential evaluations, where an individual's grade may be lower than the group grade if they do not contribute equally to the phase deliverables.

Each group consists of a team of 4 or 5 students. We hand out a questionnaire during the first week of class to gather information on the students to help form groups. Initially we are using prior database experience and geographical area within the Phoenix metropolitan area to form teams such that each group has at least one member with database experience and most group members live in the same region (if possible, to facilitate group meetings). In a joint offering of the class at the introductory graduate level, the groups are assigned at least two undergraduates and at least 2 graduate students, if possible. The heterogeneity of the students in the group improves the cooperative learning experience.

The assignment of complementary and interconnected roles to group members is also an important component of cooperative learning [6]. The roles that we assign to the members at each phase include phase leader, phase recorder, phase checker and phase technical advisor(s). The phase leader is responsible for coordinating the activities of the phase, establishing intermediate deadlines and ensuring the on-time completion of the deliverable. The phase recorder establishes an outline and plan for generating the phase documentation by delegating subportions of documentation to other group members, and ensures the correctness and quality of the final documentation. The phase checker is responsible for leading the assessment process. The phase technical advisor serves as technical support for the group.

The roles are assigned primarily at random during phase 1 except that the leader is the group member that has had some prior database experience. The roles for the other phases are determined so that students are assigned different roles during different phases (for the most part). The default assignment of roles for both 4 and 5 member groups is shown in Table II, where L=Leader, R=Recorder, C=Checker and T=Technical Advisor. (Note that 5 member groups have two technical advisors.) The phase 1 leader, who has previous database experience, is assigned the role of technical advisor in the implementation phase 3. Other assignments are possible. We have allowed groups to petition for a change of roles in phases 2 and 3, provided that each group member is assigned a different role.

TABLE II
Role Assignment

Phases

4 member group

5 member group

1

L

R

C

T

L

R

C

T

T

2

C

T

L

R

C

T

T

L

R

3

T

C

R

L

T

L

R

T

C

Groups are formed the second week of class. Each group member signs a statement that acknowledges the importance of their membership in the group and the penalty of withdrawing after groups are formed, which is a failing grade within the course. Students also acknowledge that failure to contribute to the project results in a grade of zero. Each team must turn in the appropriate documentation at each assigned due date, even if it is incomplete. In particular, each phase has an intermediate and final phase deliverable. The intermediate phase deliverable is not graded but is used to provide feedback to the group for improving the final phase deliverable. Satisfactory performance in each phase is required before going on to the next phase. Teams that do not meet the minimum requirements for satisfactory work are required to revise their work before moving on to the next phase. The group project is worth 35% of the total course grade: phase 1 is 8%, phase 2 is 12% and phase 3 is 15%. An individual's grade on the group project can be adjusted based on their contribution to the group project.

At the end of each phase, each group member must submit a confidential phase evaluation that evaluates each group member's participation and contribution on the deliverable. This evaluation is both a self evaluation and a peer evaluation. When there is a consensus on the lack of the group member's contribution, points are deducted from that member's grade. The confidential evaluations include a column indicating the percentage of the group grade that each group member deserves on this phase of the project. For example, students who fully participate should be rated at 100%, whereas students who fail to contribute anything should be rated at 0%. Generally, the self evaluations are consistent with the peer evaluations, confirming any lack of participation as well as excellent contributions.

At the phase intermediate and final deliverables, a group status report is required. The status report provides the dates and attendance at group meetings during the phase, an overview of the progress of the project and a detailed list of expected and completed contributions for each group member. The group status report is primarily the responsibility of the phase leader with assistance by the phase recorder. However, each group member must sign the report, indicating that they have reviewed the report for correctness. The group status report gives a good indication of the division of labor among group members. At the intermediate deliverable, the report gives the instructor the opportunity to provide feedback on the delegation of responsibilities.

The group status report is an abstraction of the minutes of the group meetings. Each group is required to maintain minutes of group meetings, which is the responsibility of the recorder. These meeting minutes are to be emailed to the group as a summary of the meeting, so each group member is aware of the decisions made at the meeting. Although the group meeting minutes are not required to be handed in with the phase deliverables, we reserve the right to request to see the minutes to facilitate group processing.

Also required at the end of a phase is a phase assessment that evaluates how well team members understand the relationship between the theoretical components of the course material and the practical aspects of the course project. The format for team assessment is provided by the instructor and may be a combination of a written quiz, oral discussion questions, or a self-assessment checklist. In all cases, the phase checker coordinates the assessment process. Each assessment question is delegated to a team member. The answers to the assessment questions are discussed at a group meeting to encourage an environment in which peers help peers. The phase checker is responsible for summarizing the group's experience on the assessment and for coordinating the inclusion of the written answers to the assessment questions as part of the phase deliverable. The quality of these answers contributes to the group's grade in the phase.


V. Integrating Database Use into the Curriculum

Our approach to introducing students to the fundamentals of Microsoft Access consists of 1) providing the class with a complete implementation example, and 2) providing exercises that allow students to explore and extend the implementation. Since CSE 412 uses the Elmasri and Navathe [5] textbook, the example database provided is based on the Company Database example from that book. As a guideline for the preparation of their own project deliverables, the students are provided with sample deliverables based on the Company database implementation. Our database training approach is then based on three specific exercises: 1) a tutorial that allows students to explore the Company Database example, 2) a step-by-step extension exercise, and 3) a collection of more difficult enhancements to the example database. Whereas the step-by-step extension exercise provides complete details on how to change the database, the collection of enhancements require more effort to discover how to change the implementation. Each of these exercises are incorporated into the assessment component of the group project. Table I, which is included in the overview of the course curriculum, illustrates the point at which the training exercises occur within each phase.

A. The Tutorial

We have prepared a tutorial document that introduces the most relevant features of Microsoft Access that will be needed during the semester. The tutorial is based on the Company Database example and is accompanied by the actual Access implementation of the Company Database.

Since the group projects begin the second week of the semester, with phase 1 spanning approximately 4 weeks, the tutorial is introduced at the midpoint of phase 1, as soon as the students have been taught the fundamentals of mapping an ER diagram to a relational schema. At this point students are familiar with the concept of referential integrity and are just beginning to learn relational algebra. The students are also beginning to think about the forms, reports, and queries that will be needed in their own projects. This is an excellent point at which to provide an overview of the database tool.

The students are expected to work through the tutorial on their own time before a dedicated class period that is devoted to the online discussion of the features of Access. The tutorial is not intended to teach the students how to use the features of Access but to provide a guided tour of the features they will need to investigate. The tutorial also introduces students to basic terminology associated with the use of the system. In particular, the tutorial allows students to examine the definition of the Company Database relations, including the definition of primary key to foreign key relationships and the additional semantics that can be defined for cascaded updates and deletes. Since the students are just beginning to learn about query expression, the Query-By-Example (QBE) feature of Access is examined. The corresponding SQL queries are introduced as a feature that we will explore later in the semester. The tutorial also examines form and report definitions, together with macro definitions and Access Basic. At the end of the tutorial, the students have a fairly good understanding of what needs to be designed for their own projects and of what features of Access they will need to use. The class period devoted to an online explanation of Access does not go through the tutorial. We use a small example from our class notes to illustrate the ease of use of the Access interface to define tables, to define the relationship between tables, to populate tables and to define simple queries using the Access QBE interface.

B. The Step-By-Step Extension Exercise

As mentioned in the course overview, part of the deliverable for each phase of the project includes a team assessment. The second major training exercise for Microsoft Access occurs as part of this assessment process. The students are assigned an out-of-class exercise that involves implementing an extension to the Company Database example. Every student must do the extension on an individual basis, although students are encouraged to help others in their group that have difficulty with the exercise. The phase checker must provide a summary of the group's experience with performing the extension as part of the assessment questions for Phase 1.

The extension involves defining a new relation, establishing appropriate links for referential integrity between the new relation and existing relations, constructing a form for input/modification of the relation, and modifying an existing form with a subform based on the new relation. Simple queries must be constructed using Access QBE to support the extensions. Access QBE is used since we have covered relational algebra but we have not yet covered SQL. The exercise provides step-by-step instructions on how to implement the extensions. Furthermore, the extensions are all based on the concepts that we have covered in class up to that point. Students therefore have the opportunity to put fundamental concepts into practice. For most of the students, this is their first attempt at actually constructing a portion of a database using Access. Students really seem to enjoy the exercise and acquire a sense of confidence about the more substantial implementation requirements to follow in the next two phases.

C. The Company Database Enhancements

The final Access training exercise occurs as part of the phase assessment deliverable for Phase 2. Phase 2 involves building relations, establishing field and table level constraints, defining referential integrity relationships, and populating the tables with test data. A prototype of all forms and reports must also be constructed in Access as a design step to prepare for the full implementation effort in Phase 3. The Access training exercise in Phase 2 focuses on providing students with a more in-depth examination of implementation issues for forms and reports so that they will be prepared to implement their own projects as soon as Phase 3 begins.

There are four Company Database enhancement exercises that are distributed among the members of each group. In the case of groups with five group members, students are allowed to pair up on the more difficult enhancements. As with the Phase 1 extension, students can help each other on the exercises, but each student must take the primary responsibility for the implementation of one of the enhancements. One class period is devoted to discussion of the enhancements. For each enhancement, groups are selected at random to provide an on-line illustration of their implementation. The group member responsible for the enhancement must be prepared to lead the discussion. This random in-class selection encourages the conscientious completion of the enhancement.

Each enhancement is designed so that students are presented with the requirements for the enhancement as well as general guidelines about what needs to be done to make the appropriate extensions. Unlike the Phase 1 extension, however, the students need to do more work on their own to discover exactly how to implement the changes. Students are therefore required to use the Access help facility or their favorite Access book.

The enhancements are also designed to give the students experience with several features of Access that are useful in the implementation of their own projects. The first enhancement involves the addition of a list box to an existing form to provide a quick search facility for finding records according to a specific field value. The enhancement involves modifying the form design as well as writing appropriate queries and macros to implement the search. The second enhancement requires that students construct a parameterized query and develop a form to launch the query, where the parameter values are entered through the form. The third enhancement again involves the modification of a form, but students also learn how to dynamically modify the properties of a form so that different queries are executed depending on selections that are made on the form. The fourth enhancement introduces students to the construction of reports and subreports and the corresponding queries that are needed to support report generation.

It generally takes from 1 to 3 hours to complete each enhancement depending on the student's previous experience with Access. Each member of the group is required to teach the other members of the group how they implemented their specific enhancement. The in-class discussion also allows students from other groups to collectively discuss different approaches to the implementation. As a result of the discussion, students discover new features of Access.


VI. Evaluation of the Approach

As part of our work on the use of course projects, we have performed an evaluation of the effectiveness of our approach. The evaluation period covers a five year time frame, with two years of data on student performance before our use of cooperative group projects and three years of data on student performance during the period of the NSF grant that supported our work. In the two years before the use of cooperative group projects, projects were performed as individual student assignments. The topic of the project focused on the simulation of a network database environment rather than the implementation of a relational database application. We removed coverage of network and hierarchical legacy databases when we introduced the group projects. Table III provides a comparison of the grading criteria before and after the introduction of the group projects. In the first year of the grant, which started Fall 1994, we taught separate offerings of the undergraduate and graduate sections so that both investigators on the grant could experience the group projects firsthand. In the last two years of the grant, we had joint offerings of the course, with the goal of having at least two undergraduate students and two graduate students in each group.

TABLE III
Grading Criteria

Grade Component

Prior to Fall 94

Since Fall 94

RDBI/WinRDBI Assignments

15%

15%

Project

15% (individual)

35% (group)

Midterm Exam

40% (2 exams at 20% each)

20% (1 exam)

Final Exam (Comprehensive)

30%

30%

Fig. 1 provides a summary of the letter grade distribution within the timeframe of the study for a) CSE 412 undergraduate students and b) CSE 598 graduate students (graduate students register for the course under the CSE 598 course identifier). Prior to the Fall of 1994, undergraduate grades in the course were not as high as graduate grades. In particular, undergraduate scores indicated a higher number of B's and C's than A's, whereas graduates demonstrated a large percentage of A's with fewer grades in the B and C range. Undergraduates also demonstrated a higher number of D's and E's than graduates. After the introduction of the group project in the Fall of 1994, Fig. 1 demonstrates that the group project has served as an equalizer for graduate students. The percentage of A's has decreased, but the number of A's and B's is balanced. The percentage of C grades and lower for graduates remains low. For undergraduates, however, the letter grades in the class have improved significantly. The number of A's, B's, and C's has increased, while failing grades have diminished. The Fall 1995 semester is an anomalous situation where violation of the class collaboration policy by several students resulted in lower grades.

(a) CSE 412

(b) CSE 598

Fig. 1. Letter Grade Distribution.

Fig. 2 provides details on the average performance of the students in CSE 412 versus CSE 598 on various factors within the course: a) RDBI/WinRDBI individual homework assignments, b) projects, c) midterm examinations, d) final examinations, and e) total weighted score. Fig. 2a illustrates the performance of undergraduate and graduate students with respect to individual homework assignments using RDBI and WinRDBI. The graduate scores on homework assignments have decreased slightly but still shows a consistent level of performance on the assignments. The slight decrease may be due to the additional workload caused by the group project. On the other hand, undergraduate scores have increased dramatically. The increase may be due to the fact that students see a need to do well on the WinRDBI assignments in order to support activities on the group project, especially since WinRDBI has been integrated into group study problems and phase assessments. The 1996-97 academic year shows an overall improvement by both graduate and undergraduate scores, which is probably due to the upgrade of the original RDBI tool to a Windows-based interface, making the system easier to use.

(a) Homework

(b) Project

(c) Midterm

(d) Final

(e) Total Score

Fig. 2. Average Scores.

Fig. 2b details student performance on the projects. We attribute the increase in performance at the undergraduate level to the benefits that they have gained from the group experience. Many teams are a mix of graduate and undergraduate students. Undergraduates therefore have the opportunity to work with more experienced graduate students. The nature of the project also seems to be appealing to undergraduates who are interested in gaining hands-on experience with a database product. As a result, undergraduates seem to be more motivated to do the group project than they were with the individual programming project. The graduate performance shows an overall increase in performance over the five year timeframe. However, the best graduate performance on the group projects occurred during the 1994-1995 academic year, when the groups consisted of all graduate students. In the last two years, the graduate and undergraduate group grades are essentially equal, which one would expect from heterogeneous groups receiving essentially the same grade on the project.

Fig. 2c and Fig. 2d illustrate an interesting effect in midterm and final exam scores, respectively. Overall, midterm exam scores have increased. We attribute this to the fact that the midterm exam covers less technical material than it did prior to the introduction of the group project. In order to cover necessary details related to the group project, some of the more difficult material on database design theory related to functional dependencies, the lossless join property, and dependency preservation has been moved into the second half of the semester. The midterm exam therefore covers "easier" material on ER modeling, mapping of ER models to relational schemas, and relational algebra queries. Final exam scores, however, have decreased due to 1) the shift of more difficult material to the final exam (although the final exam has always been comprehensive) and 2) student involvement in the implementation of the group project at the end of the semester. The focus of students on the successful completion of the course project appears to overshadow the need to study for the final exam, which is 30% of their total grade. We believe that the slight increase in final exam scores in the Spring 1997 semester are indicative of our warnings to students to take the time to study for the final, since our initial evaluation was indicating a dramatic decrease in final exam scores. We also believe that the final exam scores in the Fall 1993 semester are an anomalous situation since that is the only semester within the five year study that the course was taught on television. Total scores for the course are shown in Fig. 2e. Consistent with the previous data, overall averages have increased since the introduction of the group project.

At the end of each semester, we handed out detailed surveys regarding the group project. The constructive feedback that we received from the students provided input in refining the group projects over the three year period. The students, therefore, have been a valuable factor in helping to shape the current format of the group projects. Although all students agree that the group projects are a lot of work, they appreciate the opportunity to get hands-on experience with a database product. We have many students who work in industry that support our approach to team work and have been able to validate its importance. Other students that have not previously been involved in group work may not realize the benefits of the group project experience until after they have graduated and become a team member in industry. While we have received some communication from students to this effect, we do not have a way to evaluate this measure.


VII. Conclusions and Future Research

The group projects require a substantial effort from both students and instructor. Due to the lack of in-class time, most of the work for the group project is done out-of-class. The instructor, not the teaching assistant, must assess the quality of the deliverables and provide feedback, which is challenging since each group has chosen their own enterprise. However, the extra effort is worthwhile. The students enjoy the opportunity to use a real database product and better appreciate the theoretical aspects of the course as a result of the practical experience. An overwhelming majority of the students appreciate the group experience, learning intercommunication skills as well as database topics from their fellow group members. For the instructor, the group projects provide an additional avenue of communication with the students that gives the instructor the opportunity to know the students better.

Our future work is focusing on better ways to facilitate group processing and group communication. In particular, in a geographically disbursed environment such as the Phoenix metropolitan area, we want to explore the use of computer-based tools to support group meetings.


Acknowledgments

This work was supported by the National Science Foundation under the DUE ILI-LLD program (DUE-9451489). We would like to thank the students of CSE 412 for their constructive feedback. We are indebted to Hon Wai Rene Chan, Michael Tjahjadi, Neenu Sohi and Mankit Ma for their invaluable support in developing curriculum materials as the Microsoft Access technical advisors for the class, which were supported by the NSF Grant.


References

[1]

K. Apenyo, "A Database Sequence: Theory Then Practice," ACM SIGCSE Bulletin, vol. 22, no. 4, December 1990.

[2]

S. W. Dietrich, "An Educational Tool for Formal Relational Database Query Languages", Computer Science Education, Vol. 4, pp.157-184, 1993.

[3]

S. W. Dietrich, E. Eckert and K. Piscator, "WinRDBI: A Windows-based Relational Database Educational Tool", Proceedings of the 28th ACM SIGCSE Technical Symposium on Computer Science Education, San Jose, California, February 27 - March 1, 1997, pp. 126-130

[4]

S. W. Dietrich, and S. D. Urban, Database theory in practice: learning from cooperative group projects. Proceedings of the SIGCSE Technical Symposium (Feb. 1996), pp. 112-116

[5]

R. Elmasri and S. B. Navathe, Fundamentals of Database Systems (2nd ed.). Benjamin/Cummings, CA, 1994.

[6]

D. W. Johnson, R. T. Johnson, and K. A. Smith, Active Learning: Cooperation in the College Classroom. Interaction Book Company, Minnesota, 1991.

[7]

R. Leeper, "A Project Course in Database," ACM SIGCSE Bulletin, vol. 22, no. 1, February 1990.

[8]

Microsoft Access 97. Microsoft Corporation, Washington, 1997.

[9]

A. Motro, "What to Teach about Databases", Panel Discussion, Proc. of the 1993 ACM SIGMOD Intl. Conf. on Management of Data, pp. 420 Washington, D.C.

[10]

D. V. Pigford, "The Documentation and Evaluation of Team-Oriented Database Projects," ACM SIGCSE Bulletin, vol. 24, no. 1, March 1992.

[11]

H. Saiedian and H. Farhat, "A Team-Oriented, Project-Intensive Database Course," ACM SIGCSE Bulletin, vol. 23, no. 1, March 1991.

[12]

S. D. Urban and S. W. Dietrich, "Integrating the Practical Use of a Database Product into a Theoretical Curriculum," Proceedings of the SIGCSE Technical Symposium (Feb. 1997), pp. 121-125


Author Contact Information

Suzanne W. Dietrich
Department of Computer Science and Engineering
College of Engineering and Applied Sciences
Arizona State University
BOX 875406
Tempe, AZ 85287-5406
Phone: (602) 965-2786
Fax: (602) 965-2751
E-mail: dietrich@asu.edu

Susan D. Urban
Department of Computer Science and Engineering
College of Engineering and Applied Sciences
Arizona State University
BOX 875406
Tempe, AZ 85287-5406
Phone: (602) 965-2784
Fax: (602) 965-2751
E-mail: s.urban@asu.edu


Author Biographies

Suzanne W. Dietrich received the B.S. degree in computer science and applied mathematics in 1983 from the State University of New York at Stony Brook, and as the recipient of an Office of Naval Research Graduate Fellowship, earned her Ph.D. degree in computer science at Stony Brook in 1987. Dr. Dietrich's areas of teaching and research include the educational, theoretical and practical aspects of databases. Her current research focuses on the integration of active, object-oriented and deductive/declarative databases, and the application of this technology. Dr. Dietrich is a member of the Association for Computing Machinery and IEEE Computer Society.

Susan D. Urban received the B.S., M.S. and Ph.D. degrees in computer science in 1976, 1980 and 1987, respectively, from the University of Southwestern Louisiana, Lafayette. Her research interests include object-oriented database systems, active database systems, multidatabase environments, and engineering databases, with research support from the National Science Foundation and Defense Advanced Research Projects Agency. Dr. Urban is a member of the Association for Computing Machinery, IEEE Computer Society and Phi Kappa Phi Honor Society.