Change Section entity natural key to make non-volatile

Summary of outcomes for Data Standard 2.1

• Problem Addressed: Natural composite key of Section contains volatile attributes and UniqueSectionCode does not make it clear enough that value should be unique.
• High-level Reasoning: Location, ClassPeriod, and SequenceOfCourse are included in Section key but are reportedly subject to change frequently, leading to volatility of the key. Additionally, multiple implementations were reviewed and provide reason to believe that UniqueSectionCode is not sufficiently unique today. Updating the property name may provide a stronger signal that the value should be unique.
• Changes Made: Location and SequenceOfCourse were removed from the Section key and made optional; ClassPeriod was removed from the Section key and made an optional collection; UniqueSectionCode was renamed SectionIdentifier

Original ticket description follows:

Change the natural key of section to adopt the partial key surrogate pattern, using a SectionIdentifier attribute that represents a source system assigned ID and dropping extra (and some volatile) attributes. A possible natural key of Section would be comprised of:

• LocalCourseCode
• SchoolID
• SchoolYear
• TermDescriptorId
• SectionIdentifier

This list is a combination of the natural key for CourseOffering and the new attribute SectionIdentifier. The references / natural keys for ClassPeriod, Location and attributes UniqueSectionCode and SequenceOfCourse are all dropped from the key, as they are subject to change.

—

Design

• Remove ClassPeriodReference, LocationReference, and SequenceOfCourse from the key.
• UniqueSectionCode is renamed to SectionIdentifier
• ClassPeriodReference to be made optional
• LocationReference to be made optional
• SequenceOfCourse to be made optional

Alternates Considered

None, as the design is in essence a simplification of the current key

Breaking change summary and possible transformations

The change is breaking in that a key field name will change and the key change will change the set of fields that define uniqueness.

The main breaking change is that current API or other clients may wish to use the references to be removed to get access to those entities (i.e. use the LocationReference to lookup the Location). In a model where Location is removed from the key, that operation will fail.

One possible solution is to return a system "dummy" reference for references made optional in the model.