1. Data Warehouse Student Data User Group Meeting 1/29/2015

2. Agenda New SRS Term Sessions 3-7 How to ensure Instructors can use Courses-in-Touch Graduate Admissions Status How data enters the warehouse – Part 2 of 3 Student Data User Group January 29, 2015

3. New term sessions SRS Before SRS After Student Data User Group January 29, 2015

4. In the warehouse In dwadmin.srs_term_calendar (example is 2014C): Courses in the S session uses the start/end dates on each course section. All of the others use the start/end from the SRS term calendar. Student Data User Group January 29, 2015

5. …and in queries Term_session appears in dwadmin.course_section (2015A): If you have queries where you “hard-coded” a filter on term_session, you might want to take a look to make sure they are doing what you want. Student Data User Group January 29, 2015

6. Additional info The new term sessions were first deployed in 2014C, for Wharton Grad’s use(however, no courses point to them in this term). There are courses in 2015A using the new term sessions. These new sessions in 2015A were not given a “last request date” in the term calendar. Only two new sessions have been deployed for 2015B (so far) and will be used for Nursing and SP2 courses. Student Data User Group January 29, 2015

7. Questions? Student Data User Group January 29, 2015

8. Instructors from previous terms do not by default have access to their class lists in Courses-in-Touch (CIT) for an upcoming term. Requirements for Instructor CIT access: – Instructor is active in Payroll – Has an active PennCommunity “faculty-type” affiliation in this list: { ADJF, SFAC, VFAC, VSCO, WFAC, WSTF} How to Ensure Instructors can use CIT Student Data User Group January 29, 2015

9. B.A.s should check that all instructors are in Payroll, before the payroll deadline in the month the term starts. – Deadline for Payroll ~16th of the month – Check in Jan and Aug/Sept B.A.s should also check for active “faculty-type” affiliations in PennCommunity for instructors who didn’t teach the prior term. How to Ensure Instructors can use CIT Student Data User Group January 29, 2015

10. Graduate Admissions Status CollegeNet (CN) data in the data warehouse Now: Application data & data previously available only in School Staging tables Use query tools to access Join CN tables by Application_key to CN_APPLICATION In-progress: Decision-Response-Enrollment data Student Data User Group January 29, 2015

11. How data enters the warehouse – Part 2 of 3 1994 refresher Student Data from SRS – Bulk Scripts – Deletion of records – Insertion of new records – Rebuild Indexes – Nightly Load Student Data User Group January 29, 2015

12. How data enters the warehouse – Part 2 of 3 Changes to Warehouse Load Techniques 2006-2012 – Materialized Views Materialized View is one-to-one copy of source Once changes commit in source, view updates real-time Limited transformation Views appear as tables and can be indexed Used by FIS, Career Tracker – Global Temporary Table Like real table with indexing, but… It’s a virtual table which truncates itself at the end of a session Must specify whether table preserves rows or drops rows on a commit Student Data User Group January 29, 2015

13. How data enters the warehouse – Part 2 of 3 Changes to Warehouse Load Techniques 2006-2012 – Staging Server Physically different server with same processing capability of warehouse Copy or transformative copy of source data Pull data to staging server Push transformed data to reporting server Handles heavy lifting Minimizes downtime on reporting server – DW Merge Configurable program Can delete rows in target which do not exist in source Reads the table structure of the target and constructs the insert/update/delete sql Updates only the data which changes May retain indexes on target database Student Data User Group January 29, 2015

14. How data enters the warehouse – Part 2 of 3 New Processes – Undergraduate Admissions Extracts from OASIS to staging schema tables Data manipulated and transformed from raw values to reporting values Loaded to Temporary tables Merged into Warehouse Reporting Tables Used for DWUGA reporting, including Census, Sequence, Application tables 10 minute refreshes for volatile data 2 hour refreshes for static data – Graduate Admissions Data downloaded from College Net by FAST application SQL Loaded to Oracle tables on Warehouse Staging server Merged into Warehouse in minutes Student Data User Group January 29, 2015

15. How data enters the warehouse – Part 2 of 3 Development Data – Original process truncated all warehouse tables Used copy process to reload millions of rows from ATLAS Rebuilt indexes Total process took “hours and hours” – New process Currently runs once per day Warehouse tables with indexes left intact Data copied to Warehouse Staging server This copy still takes hours, to move millions of records Transformation occurs from Atlas format to reporting schema Staging data merged into Warehouse Reporting Tables Elapsed time of merge from start to finish ~30 minutes Student Data User Group January 29, 2015

16. How data enters the warehouse – Part 2 of 3 Star Schema / Dimensional Modeling – Facts versus Dimensions Dimensions store the attributes about the fact Fact tables have millions of rows but small row size due to numeric keys – Slowly changing Dimensions – Point in time snapshots – Longitudinal Reporting Used for Tuition Distribution – Reads Warehouse Data (Student, BRS, Employee) – Sets Dimensions First – Loads Fact tables (Student Registration, Instructional program tuition, Instructor Section) – Load final Distribution Fact Student Data User Group January 29, 2015

17. How data enters the warehouse – Part 3 of 3 Next Time We’ll bring you up to date Questions? Student Data User Group January 29, 2015