Introduce Period Common type for Address, StudentCharacteristics and StudentIndicators

Summary of outcomes for Data Standard 3.0

• Problem Addressed: The Address, StudentCharacteristic, and StudentIndicator common types previously included optional begin and end dates, making it impossible to preserve a date history when an address, characteristic, or student indicator becomes active again after being inactive for a period of time.
• High-level Reasoning: Adding the new Period common type (created in DATASTD-1085) as an optional collection allows an array of begin and end dates to be provided for each record, preserving a date history.
• Changes Made: The Period common type was added to Address, StudentCharacteristic, and StudentIndicator common types as an optional collection.

Original ticket description follows:

Apply the Period common type (DATASTD-1085) to these entities. For each of these, the current UDM model is seen as having a strong limitation: since Begin and EndDate are optional, it is unclear how (in a strongly referential model driven by natural keys) identity could be established such that history can be captured.

To take StudentCharacteristics as an example, the key to the entity will be Student (UniqueStudentID) and Characteristic (a string essentially). As new records are written for the same student and characteristic, older values will overwritten because they share this same key, hence the entity looks historical, but in reality is not.

These entities are candidates because:

• there is some evidence of need for historical data, generally following a pattern where student characteristics are critical for some longitudinal analytics
• all have optional Begin and EndDates