PowerSchool ODBC Training Notes 4/1/2017 Intros… Phil Bettendorf / Level Data Background: Teacher, PowerSchool Admin, Network Admin, programmer, systems engineer

Agenda Understanding Powerschool internals – review Export via DDE and analysis in Excel Another method to get at data… Bonus!!!

PowerSchool ODBC Training Notes 4/1/2017 Background… Scope part 1 Power School Admin http://your URL/admin Subs http://your URL/subs Teachers http://your URL/teachers Web based Parents http://your URL/public Data Electronic Gradebook

Background… Definition “As an important step of knowledge discovery in databases, data mining is a process of analyzing data in order to discover implicit, but potentially useful information and uncover previously unknown patterns and relationships hidden in data, which has been applied in many fields. “ http://www2.computer.org/portal/web/csdl/doi/10.1109/IITA.Workshops.2008.235 How can we achieve this in Powerschool? DDE Exports

Background… DDE provides us a tool to pull information out of Powerschool for analysis. Bridging the “Data Gap” is only inhibited by creativity… Don’t be limited to traditional methods; think “outside the box” !!!

PowerSchool ODBC Training Notes 4/1/2017 Data-Driven Decision Process We (Powerschool admins) work at step three in the data driven decision process http://dev.ecs.org/clearinghouse/24/02/2402.doc

PowerSchool ODBC Training Notes 4/1/2017 PowerSchool Schema Put the following in your URL bar: http://<IP address>/admin/home?ac=structure Foundation tables – These are the tables that I consider the “Master” tables. These tables get completed by pulling information from other tables. I like to call these “feeder” tables. Others may not come up with the number that I have here, but this is what I consider the foundation tables. I am basing this analysis on the live side. I am not considering scheduling tables. The tables in PowerSchool are relational. They depend in some way, shape, or form on one another. The key to finding links is by searching within a table for the word ID. If it stands on its own, it is the tables unique fingerprint in the system. The ID number is an integer that gets auto generated by PowerSchool when that record gets created by some user initiated process. From then on, that record is known internally by its Internal ID ad is referenced by feeder tables when that ID is related to its table. It is the “glue” that holds the data together. Feeder tables – These are the tables that I consider supporting cast. They don’t stand out on their own, but complete the picture. Without them, the data would not make sense. There are over 195 tables within Powerschool that all are related in one way or another

PowerSchool ODBC Training Notes 4/1/2017 Table relationships CC Table ID DateEnrolled DateLeft StudentID SchoolID SectionID TermID Student Table Schools Table Section Table Terms Table Field 1 Field 2 ID Feeder 1 ID Feeder 2 ID Feeder 3 ID Feeder X ID Feeder X ID Feeder 1 ID Feeder 2 ID Feeder 3 ID

DDE / DDA Exporting Data From PowerSchool Using DDE - DDE stands for Direct Database Export and can be found by going to System, Direct Database Export.  Since it's part of the System pages, not everyone may be able to access it depending on security privileges.  DDE lets you view information in the various database tables that make up the PowerSchool database and export that information out to a file that can be opened by Excel.  DDE does not allow you to make any changes to the database directly - something known as DDA (Direct Database Access) allows you to do that instead.  -Matt Fruend

DDE Background Direct Data Export (DDE) Why use DDE? Export or filter information not easily obtained through the PowerSchool interface Track down data issues (technical staff) Effective management of student data via database interface requires: Knowledge of data elements Knowledge of table relationships

DDE Background data elements Data are stored for efficiency; not convenience Foreign key naming (most of the time) The letters ID are added to the name of the field Examples / foreign keys: TermID is stored internally as a # in all feeder tables and the term name is defined in Terms SchoolID is stored internally as a # in all feeder tables and the school name is defined in Schools StudentID is stored internally as a # in all feeder tables and the students name is defined in the Student table

DDE Background data elements Knowing which primary keys are stored as a foreign key in a related table allows the DDE user to export information that makes sense (ie Semester 1 instead of 1601) There are some caveats to the foreign key naming. An example… The Sections table has a field called Teacher. It contains the ID of the Teacher; not the teacher name.

DDE Background data elements Another example of storing data for efficiency… lookup values vs. literals: Examples: FTE (stored as # but might mean “Full Time”) Attendance codes (stored as a # but might mean “A” for Absent) Another example are defined values that are not stored anywhere; they just “are” Enroll_status in the student table 0 = active, 2 = transferred, etc.

DDE Background data elements Related tables How to link up tables Next slide will show an example of the CC (enrollment) table and related tables.

Enrollment table

DDA What is DDA? Who needs to use DDA? Why would you want to use DDA? Ability to modify/delete data Who needs to use DDA? Authorized technical support contacts Why would you want to use DDA? Fix corrupt data as a result of a system bug or a user error Some use it as a “quick fix” without regard to related table data. Can cause bigger problems! Recommendation Give at most 1 person in your district access to DDA

Exporting out of DDE Live examples of getting data from Powerschool with DDE

Pivot tables Allows analysis of vast amounts of data into concise views Who is the target audience? DDE exports provide the source for these tables Important note: Pivot tables are built on static data sets… But there is a way for them to be dynamic…

Pivot tables – building a dynamic pivot table Dynamic pivot tables start with a data set defined with a named range and a formula that will ebb and flow with number of rows in the range. =OFFSET(‘{sheetname}'!$A$1,0,0,COUNTA('{sheetname}'!$A:$A),COUNTA('{sheetname}'!$1:$1)) {sheetname} refers to the sheet that the data resides in. Note: 2007 Excel allows you to change a data source range, but it is not dynamic. You have to change the range each time rows grow and shrink

Other ways to get at data… Match Function This is one of the more under-utilized features in the Powerschool admins “data” mining arsenal…

Match Function Data are stored in individual “buckets” that are specific to a functional area within the system. Each “bucket” of information (table) has connectors to other “buckets” of information (table) so that the data makes sense. The Match functions works by being able to extract related data that is associated from one table to another related table. This is one of the more under-utilized features in the Powerschool admins “data” mining arsenal…

Match Function Match function overview… Process: Start with the Source table – filter the selection for which you want the match Go to the Target table – select all… Then Match to the table that holds the selection for which the match is to happen. note: there must be a relationship between the tables

Match Function Exercise Match back to the Student table… If the result of a Match function is student centric, and you want the ability to manage the group (browse, create a stored selection), perform a Match back to the Student table… Powerschool maintains the current selection from DDE to the front page of the application for the user performing the Match function… StoredGrades -> Student

PowerSchool ODBC Training Notes 4/1/2017 Resources Excel Pivot table http://www.ozgrid.com/Excel/PivotTables/ExCreatePiv1.htm Informing Practices and Improving Results with Data-Driven Decisions http://www.nsba.org/site/docs/9200/9154.pdf Informing Practices and Improving Results with Data-Driven Decisions