Academic journal article Journal of Research Administration

Facilitating Sponsor Requests: A Relational Database Model for Project and Effort Reporting

Academic journal article Journal of Research Administration

Facilitating Sponsor Requests: A Relational Database Model for Project and Effort Reporting

Article excerpt


Department research administrators (DA) coordinate communication between principal investigators requesting extramural funding and the funding agencies that provide it. When a sponsor decides to fund an investigator-initiated application, the principal investigator is asked to address issues such as (a) current and pending support for the investigators, (b) the institution's review and approval processes for sponsored research, and (c) the ability of the researchers identified in the application to complete the research program, given their other commitments. Sponsor requests are typically forwarded to the DA, who has the responsibility for compiling the information and obtaining institutional endorsement before submitting it to the sponsor.

Sponsor requests can overwhelm even experienced DAs. To facilitate sponsor requests, data must often be compiled from multi-project research programs and individual research projects that are administered in outside departments. Institutional information systems often do not serve the needs of department-level administrators, and many can neither anticipate renewals or extensions of active projects, nor record changes in effort commitments by investigators. Due to the shared responsibility between institutions and departments for ensuring compliance, DAs may not have all of the information to address sponsor concerns. Landen and McCallister (2002) reinforce the DA's share in research compliance, thus reinforcing the need for a department-based database system. "Compliance, both financial and non-financial, is the growth industry in research administration, with the responsibility for compliance being integrated into the jobs of central and departmental administrators." (p. 18)

Baker and Wohlpart (1998) summarized information from a survey of college and university chief research officers conducted in July 1996 and concluded that "Overall, the most popular grant management systems are manual records and files and modified computer database systems, with over half of the responding institutions indicating these types of systems." (p. 38) They further concluded that of 30 survey respondents from public and private R1 research institutions (those that offer the full range of baccalaureate programs, award 50 or more doctoral degrees annually, and receive $40 million or more in federal support), "the most popular grant management system used by R1 institutions is a homegrown computer database, with 60 percent of the 30 respondents." As these homegrown systems have likely been designed for their respective central research offices, one could infer that the institutional reports provided to the DA would be inadequate for addressing sponsor requests.

The DA is positioned to obtain other support for current and pending projects as well as changes in effort commitments. When an individual project is conducted as part of a larger multi-project program, DAs are familiar with their supported investigator's award portion. While electronic spreadsheets and word processors, together with institutionally available data, can provide tools for DAs, relational database tools that maintain project-related information about investigators would be more useful. This paper describes the characteristics of a relational database, explains the benefits of a relational database model, and provides a blueprint for designing a relational database model that can be employed to enhance data retention and reporting capability.

Characteristics of a Relational Database

Relational databases consist of at least two separate, but related sets of data. These separate sets of data are typically referred to as Tables. Frye explained, "The most basic object in a database is the table, where you store your data. You might be tempted to jam every type of data you want to store in a single table, but that's hardly ever the right way to design tables in a database. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed


An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.