An Introduction to Banner Glossary of Terms

An Introduction to Banner Glossary of Terms

• 
  Alumni/Development
  
• 
  Financial Aid
  
• 
  Finance
  
• 
  General
  
• 
  Payroll
  
• 
  Human Resources
  
• 
  Student
  

• 
  Portal Services: software designed to collect, manage and serve-up personalized software services in a Web browser.
  
• 
  Data Caching: much of the work of accessing data is offloaded from the database to IAS, enabling Web sites to respond faster
  
• 
  Web/HTTP Services: based on the standard Apache web server, provides greater reliability and scalability for all Web applications
  
• 
  Business Intelligence Services: access to Oracle Discoverer and Oracle Reports
  
• 
  Component Services: allows software developers to easily build applications from pre-built, Java-based components
  
• 
  Forms Services: serves Oracle Forms while minimizing network traffic  
  

In most datamarts, there is a materialized view for each table in the Banner database. This materialized view is basically a copy of the Banner table. These materialized views are set to be automatically updated or refreshed once every 24 hours. They are refreshed incrementally, meaning only changes or additions made since the previous refresh are brought into the view.

• 
  Each data item is stored in only one location; someone's mailing address is stored in one table; every data entry form and report looks at this one table; all changes are made in this one table;
  
• 
  The database is designed once, with an emphasis on the relationships between data. For example, the Banner database was designed to allow more than one type of address, so additional address types can be added at any time without altering the design.
  
• 
  To query related data, data must often be pulled from multiple tables; tables are joined together via a common field(s)
  

SELECT

FROM
spriden

SELECT

FROM

WHERE
id = 'A01521421'

- ID number (ID)

When you are requesting information about a particular student or group of records, the information is often stored in more than one table. These tables must be joined correctly to give the correct information. To retrieve identification information for a particular student, you need to join columns from the SPRIDEN and SGRSATT tables. Assuming that each student has one record in each of these tables, you just want to retrieve those two records. You need to make sure that you don't get a record from SPRIDEN for one student and then get a record from SGRSATT from another student. When you enter the query command, you need to specify the fields you want from each table and then specify the join statement: "where the ID field in the SPRIDEN table is equal to the ID field in the SGRSATT table". Another example might be looking for a student's records from a particular year, so we would include in the join the ID field and also the year field.

Unlike a table, no data is actually stored in the view, what is stored is a set of query commands that retrieve the information from the different columns that make up the view. When a view is accessed, the query is run and the data is presented to the user as if it had been sitting in the view. Views do not require storage space like tables do. (see Materialized View, Table)

Views are useful for hiding the complexity of the tables in the database. A view called STUDENT_IDEN could be created that contains most of the fields from the SPRIDEN table:

Last Name
First Name
ID

Before these fields were pulled from the SPRIDEN table, the SGRSATT table, which contains student data would be checked. Then only the records in SPRIDEN that had a matching record in the SGRSATT table would be placed into the STUDENT_IDEN view.