Access to the OAT Database

Sep 17, 2026

Uploaded by Aria

Access to the OAT database is defined for both users and applications, covering how people (directly via SQL or web services, or indirectly through applications) obtain and maintain authorized access. The document establishes core principles for application users, analysts, developers, and applications, emphasizing confidential data handling, compliance with University Policy 46, and limits on local storage. It also outlines the approval and nomination process and recommended technical access methods such as web services or approved schemas.

LanguageEnglish

CategoryResearch & Report

FormatPDF

Pages4

Reading Time10 min

AccessFree to download

Core Principles

Core Principles for Application Users

Core Principles for Analysts and Developers

Core Principles for Applications

Gaining Access

Access for Users

Access for Analysts and Developers

Access for Applications

Access to the OAT Database This document describes how the OAT database may be accessed, including access by people (“users”) and by applications. The following diagram shows the high-level architecture. The OAT Database is the central resource of concern in this document. It is updated nightly from the Quest database. The OAT Database may be accessed via SQL or web services, either by people or programs. People may access it directly (via SQL or web services) or indirectly (via an application program) . Definitions: 1. OAT database: The database that stores data from Quest and other sources and is the central subject of this document. In some contexts this database is also known as“Odyssey”. 2. Application: A program that accesses data from the OAT database. Current examples include the OAT suite of tools (ASIS, canned queries, etc), the Exam Management System, and Evaluate. 3. Application users: People who access the OAT database indirectly through an application. This is by far the most common case. 4. Analysts: People who have the SQL skill and appropriate permissions to write queries against the OAT database to: a. answer immediate one-off questions for administrative and/or academic support, b. create repeat-use queries to be added to OAT’s collection of canned queries, c. or, create single-user applications using tools such as Excel, Access, or R. 5. Developers: People who develop applications that depend on OAT data and will be accessible to other users. Access to the OAT Database Page 1 of 4 Core Principles Core Principles for Application Users 1. Access to confidential data, including the data stored in the OAT database, is governed by University Policy 46. This document clarifies how Policy 46 is implemented with respect to the OAT database. If any conflict arises, Policy 46 takes precedence. 2. Anyone who is given access to data via OAT is bound by Policy 46 and Appendix A (Access to and Release of Student Information) in particular. 3. Some applications allow data to be downloaded to local machines. Users will not store such data longer than necessary to complete the immediate business function. Core Principles for Analysts and Developers 1. Don’t store data. 2. Analysts will endeavour to write their queries to be applicable to as broad an audience as possible and will submit appropriate queries to be included in OATs Canned Queries feature. 3. Developers will give appropriate consideration to making their applications available to other UWaterloo users who have similar needs. Core Principles for Applications 1. Applications will not store data from the OAT database without prior written authorization from the OAT Management Board. Whenever feasible, it is preferable to query OAT again rather than storing data locally. 2. Applications must implement appropriate user access controls. 3. Applications and their sponsors will expect and encourage the above principles for their own users. 4. Each application should have its own approval process and OAT credentials for accessing data. Gaining Access Access for Users Application users gain access by being authorized to use one or more applications via the policies and procedures associated with the specific application. For example, access to the OAT applications is approved by an Associate Dean, Undergrad, orthe equivalent within non-academic units (the “sponsor”) . Most users gain access by requesting it from their sponsor. The sponsor has access to a OAT web page that can grant the user specific permissions for using the system. The sponsor may also record a rationale for granting access in case the rationale is not apparent from the user's job title. In some cases, a user may gain access by making a request directly to the OAT Management Board, but such a user still requires a sponsor. Each user account has an expiry date which must be periodically updated by the sponsor or the user will automatically lose acces

FAQs

How is access to confidential OAT data governed?

Access to confidential data in the OAT database is governed by University Policy 46. If there is any conflict, Policy 46 takes precedence.

What are the key principles for analysts and developers regarding data storage?

Analysts and developers are instructed not to store data. Analysts should create queries suitable for a broad audience and submit appropriate queries to OAT’s Canned Queries feature.

What technical access mechanisms are recommended for applications?

Applications should request data when needed and avoid caching to disk. Preferred mechanisms include accessing a web service; alternatively, using an application-specific schema or an application-specific view developed with OAT staff.

Sep 17, 2026

Uploaded by Aria