Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Link to library

Video 1

Image RemovedImage Added

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

  •  does it also include data changes fed to DW?)

(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

Degree Works URLs

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)

Student Card (time stamp 1:16:05)

  • 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.

Image Added

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:

  1. A place to identify grad req

  2. 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

Task report
pages399376439
isMissingRequiredParameterstrue

On this page

Table of Contents