ODS & Application Development Colin DeLong College of Liberal Arts UM Analysts Group,

Overview Why do we need ODS? Why do we need ODS? What have we done? What have we done? Lessons (possibly) learned Lessons (possibly) learned In the future In the future ODS wish list ODS wish list

Why do we need ODS? Closing the gap between DW and PS Closing the gap between DW and PS –From an outreach perspective:  Minimize time between student status change, such as dropping below 13 credits, and follow-up from adviser/counselor/etc –Might still have a chance to address an issue –Student perception of responsiveness improved –From a user perspective:  Don’t have to double-check PS to see if data is still current, saving time and reducing frustration  Trust in accuracy of data = trust in application utilizing the data –From an analyst perspective:  Near real-time flow modeling (i.e., enrollments)  Better than having to qualify reporting results with DW delay disclaimer :-)  Little thing (but nice) – timestamps! –LAST_ENRL_TM_STMP, for example

Lessons (possibly) learned Replication paradigm change necessary Replication paradigm change necessary –Once a day  every 10 minutes –Replace table  append to local table –Don’t want to kill ODSPROD, so we only use “_D” tables and only grab transaction records we don’t already have locally; append new records to local copy –This process ensures that we’re minimizing bandwidth/ODS server processor time/memory/etc as well as overall update time DW data reflects “current” state; ODS is a transaction log  merging the two can be non-trivial DW data reflects “current” state; ODS is a transaction log  merging the two can be non-trivial –First, we extracted the most recent “state” from ODS (from O_PS_STDNT_ENRL_D, for example) –Second, when extracted records conflicted with DW records, ODS records take priority (they always reflect the most recent state)

What have we done? Enrollment Tracking System (ETS) Enrollment Tracking System (ETS) –Monitors entire CLA undergraduate population for status changes we want to know about  Dropped all their courses, dropped below 13 credits, not registered for next term when they should be, etc –Alerts are generated to academic advisers when something problematic happens –Data accuracy is vital when following up with student, as well as timeliness of outreach –Currently makes use of O_PS_STDNT_ENRL_D, O_PS_STDNT_CAR_TERM_D, and O_PS_SRVC_IND_DATA_D –Being able to track retention progress in near real-time incredibly valuable  advisers can monitor outreach follow-up (i.e., did the student register after we met?)

In the future Section status integration Section status integration –…without having to peg OneStop –For example: Advisers need bulk course searches to help create schedules for students quickly during Orientation (30 min appts) –Would be useful for curriculum management as well System access updates via HR data System access updates via HR data –New staff would have access as soon as we can see/verify their HR records –Outgoing staff (including transfers to other units) access updates/revocation essentially synchronized with PS HR record changes – very helpful

ODS wish list Financial aid & student financial data Financial aid & student financial data EFS transaction data EFS transaction data Admissions data Admissions data Tuition attribution data Tuition attribution data Complete historical transaction data for ps_stdnt_enrl & ps_stdnt_car_trm Complete historical transaction data for ps_stdnt_enrl & ps_stdnt_car_trm –Could perfectly re-create STIX tables, for example, by identifying retroactive updates in PS (AFAIK, not detectable in ps_dwsa_stdnt_enrl_rt)

Fin. Questions? Questions?