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

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

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

4. 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. “
How can we achieve this in Powerschool?
DDE Exports

5. 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” !!!

6. PowerSchool ODBC Training Notes
4/1/2017
Data-Driven Decision Process
We (Powerschool admins) work at step three in the data driven decision process

7. PowerSchool ODBC Training Notes
4/1/2017
PowerSchool Schema
Put the following in your URL bar:
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

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

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

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

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

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

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

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

15. Enrollment table

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

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

18. 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…

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

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

21. 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…

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

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

24. PowerSchool ODBC Training Notes
4/1/2017
Resources
Excel Pivot table
Informing Practices and Improving Results with Data-Driven Decisions
Informing Practices and Improving Results with Data-Driven Decisions