2023-11-16 Degree Works video 1
Overview of relationships
Banner/SIS (Student Data)
Roles are not assigned directly in DW, but rather extracted from Banner.
REG users – highest level of authority.
Periodic bridging - Banner course catalog (DW Course Master), equivalency extract
Data bridge = extract
Configuration and validation tables
How do we want to treat the data when the auditor creates an audit for X school?
These settings can be changed
At install, several validation tables were loaded. Extracted ONCE. Degree, major, concentration, minors, cy, ct, program codes. Because when the tables are changed, if extract is run again, all settings would be lost.
Controller
Used to access Banner tables
Scribe
Foundation of the audits
Responsive dash
Looking at an audit, processing exceptions. Refers to the latest version of what the audit looks like
Petitions, notes, exceptions, SEPs
DAP22/Auditor
The process that generates the audit (process button). When you click process, it runs a new audit. Pulls together from RAD, DAP, and UCX tables.
RAD tables
Anything that comes from Banner lives in a RAD (Repository Audit Data) table in DW. SIS → RAD
DAP tables
Anything added directly to the database lives in DAP tables (Degree Audit Process). Scribe, exceptions, SEPs. Scribe/responsive dash → DAP
UCX tables
Where validation and configuration tables are stored. Universal Code Extension. Controller → UCX
Composer
Modify what the web looks like; institution branding. Separate log in.
Transit
Also separate log in. Batch reports and processes.
4 sites
Responsive Dash, Controller, Scribe, Transit
When does DAP22 run in the timeline of when data is extracted?
Process run every single night (“Banner extract student”) which goes to Banner to bring in new students and identify changes for existing students.
When the student data is updated in RAD, it kicks off DAP22 which is the algorithm to run a new audit. A new audit is generated when the Banner data we’re bridging for a student is updated. (grades posted, major changed)
If nothing changes, you don’t get a new audit.
Refresh timestamp shows the last time DW asked Banner if there were any changes.
Hover over date refreshed and you can see the last time there was a Banner data change that was fed to DW.
Historic audit dates - Every time process button is clicked
(time stamp: 25:12)
If Scribe is changed, the nightly process will not generate a new audit - only does it if Banner data changes.
Nightly: Courses, equivalencies, curric rules (what-if) extract - extracted to UCX and RAD tables
Nightly: Student changes extracted to RAD tables
If there are changes, a new audit is run
If no changes, no new audit run
Validation tables from Banner - one time ever - extracted to UCX tables
Configuration
STU307 Degree code table (STVDEGC)
Ordered according to the key
Can manage codes on DW side, doesn’t feed back to Banner.
Can remove what we don’t use/don’t teach. For example, if we’re pulling in degrees faculty have earned (if we use Banner HR), we could remove those degrees.
These degree values can be used in search - all search values come from STU307 table.
For each degree, you can choose whether to show as option in SEP pick list, TA SS pick list, what-if pick list, adv search pick list (if it’s blank, it assumes Yes)
Even if no Banner data changes, but Scribe is update, you have to click Process to run a new audit.
Blocks
University, Degree, core, major, other requirements, electives, fall through
Fall through - any college level course successfully completed but doesn't apply to requirements.
Insufficient - not successfully completed (I, W, failing grade, excluded courses, grades that don’t meet the requirement’s minimum grade req.)
Over the limit - Scribed max credits/classes surpassed in degree block. Sometimes named Not Counted
Legend, disclaimer
Presentation
What is Scribe?
Each requirement displayed is written in Scribe. Defines degree and course requirements.
Reserved words
Block - collection of requirements specific to this definition. Kind of a like a Word document
Block type - degree, major, minors/conc, other - type of requirements
Other - for core/gen ed, electives, additional requirement
Rules - requirements
Qualifier - Places restrictions on a requirement or a set of requirements (grade requirement, GPA requirement, # credits in residence)
Can place a qualifier on a rule, block, or whole audit
Labels - Text that identifies the requirement
Remarks - comments; want to use judiciously - be brief
Comments - Text added within Scribe to give the user some information. Ignored by auditor and not rendered in audit.
Parser - Checks scribe for proper syntax. Can’t save a block with parsing errors.
Block layout hierarchy
Degree block
Must identify block type and value
Block type major - requires that we have to have a major. The major is XXXX and if we have major XXXX we pull in that major XXXX block.
Block structure
Comments - italicized in green
University
Block type - block value
Block title
Catalog ranges
Additional tabs (Degree-BA)
ST016 - term table - Each term mapped to catalog year. When scribe block says 2022, it pulls from the terms mapped to cy. Not scribing by term, but rather by cy.
Block Details should be set to the correct catalog year. First year through end of time.
If core is different by degree, create a core block for each degree and indicate the degree it should display for.
The algorithm reads everything after [BEGIN] up to [END.]
Change log at the end of the scribe block to see the history of what changed and when.
Semicolon distinguishes the header from the body.
Header enforces all the requirements for a given block of data. If you call in other blocks, anything in the header would also apply to those. Any qualifier in the header block applies to all the blocks called in.
Body is where rules are entered:
A place to identify grad req
Advice to students through SCRIBE req text and labels.
Body: basic course rules
Classes vs. credits
Individual course vs. course list
Time stamp 2:11:35
Questions
On this page
- 1 Overview of relationships
- 1.1 Banner/SIS (Student Data)
- 1.2 Controller
- 1.3 Scribe
- 1.4 Responsive dash
- 1.5 DAP22/Auditor
- 1.6 RAD tables
- 1.7 DAP tables
- 1.8 UCX tables
- 1.9 Composer
- 1.10 Transit
- 1.11 4 sites
- 2 Configuration
- 3 Presentation
ID numbers should never be released via ticket, phone, or email. Students can access their ID numbers via Gibson. Students needing ID numbers for transcript orders can enter their SSN or 9 0's in the ID number field.