- This line was added.
- This line was removed.
- Formatting was changed.
This section outlines major changes in the Ed-Fi Dashboards v3.0. Major changes are those that break existing integrations of widely operationalized data domains (i.e., domains used in field work across multiple implementations), and changes that represent a new and significant design pattern particularly worthy of note by the community.
The What's New - Release Notes section of this documentation lists all changes.
Discussed in this section:
|Table of Contents|
Detail on each topic follows.
Removal of Type Enumerations
The Ed-Fi Data Standard v3.1 includes changes to how standardized enumeration sets (i.e., controlled vocabularies) are supported in the data model. In Data Standard v2.0, there were both Ed-Fi Descriptors and enumeration types that were directly included in the model. As of Data Standard v3.0, enumeration types were removed, leaving only Descriptors. All existing enumeration types were converted to Descriptors, so the model now contains a RaceDescriptor, an AcademicSubjectDescriptor, and so forth.
The bulk of this release deals with changing types to Descriptors and adjusting to model changes. These changes are primarily in the ETL Readers for Dashboard use. In cases where previous dashboard versions mapped multiple Descriptors to one core type, operational context was used as well as new helper classes in the ETL to address these changes.
You can view these updates in the Enumeration Type to Descriptor Tickets in the Ed-Fi Dashboards JIRA Project. For details on the dashboard operational context, review the How To: Configure Dashboard Operational Context documentation.
Calendar Section Key Updates
The Ed-Fi Data Standard v2.0 model did not allow a school to have different calendars for different grade levels or different calendars for different groups of students and staff. This was because the CalendarDates identity was defined by a School reference and a date in Data Standard v2.0. Additionally, the association between the CalendarDate and Session entities to the CalendarDate and GradingPeriod entities created confusion regarding the intended usage of the CalendarDate entity for attendance and scheduling.
The Ed-Fi Data Standard v3.1 model supports:
- Multiple calendars for a given school
- Calendars associated to a grade level
- Students assigned to Sections with 0 or more Class Periods associated to it
For details on these model updates see Calendar Model Updates.
While the calendar model updates allows more flexibility, the Ed-Fi Dashboards makes the following calendar assumptions to calculate and render metric calculations:
- Only one school calendar exists for all students.
- The school calendar must have the new CalendarTypeDescriptor of "School" assigned in the Ed-Fi namespace. See
Jira server Ed-Fi Issue Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key DATASTD-1300
- In case of multiple calendars of type "School" for a specific school in the current school year, the ETL will use the one with the most recent CreateDate.
- The Draft business rule for this implementation can be found in
Jira server Ed-Fi Issue Tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key MET-1018
Section Key Updates
Under the new v3.0 data model, Section and ClassPeriod associations must be queried from the SectionClassPeriod table, rather than StudentSectionAssociation. It is now possible or a student to be associated with a Section that has zero or many associated class periods. Additionally, now that ClassPeriodName is no longer a required part of Section, the output of some Dashboard items dependent on ClassPeriodName require special handling. Since this is non-nullable and part of a unique index for this Tech Preview, we have created