Project Contexts & Use Cases
Minnesota DOE (SEA) | Florida CODE (Collaborative) | Tulsa (LEA) | Tucson (LEA) | |
---|---|---|---|---|
Project Context | MDE is deploying an Ed-Fi data collection system for 18-19 school year to collect student demographic and enrollment data elements from a pilot group of school districts. We are planning to ramp up this data collection over several years with the goal of all districts reporting student demographic and enrollment data elements in the 21-22 school year and retirement of the legacy student enrollment data collection system the following year. MDE is evaluating T-ODS as the next-generation system for statewide data validation and data snapshots which will be used to populate data marts for the various systems that consume student demographic and enrollment data. MDE’s legacy student enrollment data collection system uses a mainframe-based statewide data validation and data snapshot system which is over 25 years old. | Summary of Ed-Fi investments to date, include:
| We are loading our data using a custom API and are working on Attendance and are poised to start on Assessments. We plan to leverage the Ed-Fi ODS for our Power Bi/SSRS reporting requirements. We may also make modifications on the Dashboard if none are planned by Ed-Fi to allow views into past data (beyond prior year). | |
Temporal/Longitudinal Use Cases A general description of the temporal/multi-year use case(s) you are trying to address. Information should include:
|
|
| Domains:
Outputs:
|
|
Ed-Fi ODS/API Deployment Configurations
Minnesota DOE (SEA) | Florida CODE (Collaborative) | Tulsa (LEA) | Tucson (LEA) | |
---|---|---|---|---|
Ed-Fi ODS/API Versions
|
|
| Dev, Prod: v2.3.1 |
|
ODS/API Deployment Architecture (On-premise, Azure, AWS) | On-premise
| On-premise
| Cloud - AWS |
|
ODS/API Tenancy/Segmentation Model (Multi-tenant or single-tenant) | Multi-tenant MDE is planning to deploy Ed-Fi ODS/API in a multi-tenant model with a single ODS database per year, similar to WI. | Have both:
| Single tenant (LEA) | Single tenant (LEA) |
ODS Storage Model (Year-specific or multi-year) | Year-specific model
| Multi-year model
| Multi-year | Multi-year model (preference) |
T-ODS Functionality
Functionality | Minnesota DOE (SEA) | Florida CODE | Tulsa | Tucson |
---|---|---|---|---|
T-ODS Snapshot capability: What is the anticipated periodicity of snapshots? | A total of 8 snapshots per year Initially we plan two distinct snapshots, Fall and End of Year.
| A total of 18 different snapshots per year
| Daily | We currently have 2 years of daily historical data for our Synergy SIS, but we have not yet determined the feasibility of using this data. This data does allow us to pull any point, such as Term, Semester, EOYr, 10th day, 40th day, 100th day or other points |
T-ODS query: Do you anticipate querying temporal data natively (via SQL queries) ,through an application, or both? | Likely natively, but not yet designed. | Both:
| Both. SQL queries and API calls from another application | Both.
|
T-Bulk: Is bulk-load of prior years of data required? If so, are you able to produce or acquire prior year data in Ed-Fi XML format? | No. For the current project vision, no, we do not need bulk-load of prior year of data. The T-ODS will be used for creating snapshots from which downstream data warehouses and data marts will be populated. If our project vision changed to include bulk-load of prior years’ data into the T-ODS, it will likely not be for at least 5 years. | Yes. The Bulk Load will be through the Mass Send to API functionality that exists in Skyward SIS. We plan to mass send data through API for previous years, snap-shot each year, and then set the current year for live data. Snapshots of the Current Year (1819SY) will be during each state reporting period (Chris Moffatt (Deactivated)) Does this produce Ed-Fi XML? | Yes. We are bulk-loading prior years of data, and yes, we are able to produce these data in Ed-Fi XML format | (rick.foster) What is the best method?, We have data 9 years back in common data structures and could use the API. We can produce XML format if necessary. (Chris Moffatt (Deactivated)) The current T-ODS design supports Ed-Fi XML format as the only supported way of loading prior years of data |
Do you anticipate needing to modify temporal data? If yes, indicate how/where you anticipate performing the modification | No. | Yes.
| Probably so...but we are not yet certain. One case where we anticipate needing to modify the temporal data is delayed entry of compliance based data. For instance, most compliance data in Oklahoma is reported as of October 1. In the event that a student has been tested and qualifies as an English Language Learner but that data is not in the source system, it will be important to be able to add that data in to be reflected on the tested date (not the entry date) in order to make sure compliance reporting is accurate and to make sure the correct $ amount is received from the state (assuming reporting is done through the ODS). How/where update would be made: Via ODS/API. The current process is that these changes are updated in our source system. In an ideal state, the update in the source system would trigger a change in the ODS but this may have unintended consequences. | No. We would like to support point in time/repeatable results type data sets. |
If relevant, provide information about alternative technologies/approaches you have investigated or intend to evaluate (in addition to T-ODS | We will be comparing the results of the T-ODS to the current MARSS statewide reporting data marts on the mainframe. However, this is not really an “alternative” technology, but rather a “legacy” technology. Our hope is that the T-ODS solution will allow us to eventually (in 5 years, once legacy MARSS system is retired) replace the legacy technology with T-ODS. |
| Continuing with our data mart approach in the current dashboard application as the source of data and data changes is an option that we will consider if we are unable to utilize the T-ODS to the level we hope to. | As mentioned above we have historical-lized the complete Synergy database (300GB of non-image data). The method used was dynamically built merge statements using Effective Begin and End Dates with current row identified as Effective End Date of 29990101. |
...