Schema

A Schedule can essentially be described as a “folder” for games. This deviates somewhat from how other systems categorize games using “sub-seasons”, but it’s more or less the same concept with a somewhat confusing name and additional structure.

The idea was to have a common model to define any sort of series of games whether it’s league or tournament play, which is where the term “schedule” came from, but that gets confusing when referring to a schedule in the general sense (see?).

¹ It’s not possible to have mixed-division schedules, but you can technically have games of different divisions within the schedule. These are generally used for searching/filtering. This could be changed to accept multiple values.

² Worth noting that when designing schedules, an assumption made was that associations could have multiple tournaments for a single division. In practice, this doesn’t seem to be the case, but this design would allow for this. e.g., Kamloops could have a U13C tournament at the start and end of the season, but in practice they’ll have a U13C tournament in the fall and a U15C tournament in the winter, if not concurrently. Downside of this design is you have to create two separate schedules in this scenario, so you can’t link to a single page for an event like this.

³ These are hardcoded enum values and will need to be aligned with SID soon to allow flexibility for multi-sports.

Relations

Office

A schedule belongs to a single Office. An office does not have any concept of division/gender/category, which generally is defined by a schedule or team belonging to the office, and further enforced by permissions which may be limited in this way.

¹ An office typically follows the HCR office hierarchy, with a deviation for a type “League” that has OfficeMembers, which is a separate hierarchy construct to define associations part of the league (while still maintaining a relationship to the district). Therefore it’s possible for an MHA from district A to be part of district B’s league (e.g., PCAHA typically has USA teams regularly playing in their leagues). Similar exists for “Zone”, used for assigning.

For league games (Exhibition, Placement, League, Playoffs), schedules typically belong in either a League office (e.g., PCAHA Female hosts all female games for Pacific Coast) or a smaller association that only plays internally may decide to place their schedules within the association.

Tournaments are schedules that typically belong to an association office.

Permissions have a significant impact here. A league manager may have access to a given league (e.g., PCAHA Female) which would grant access to all schedules directly in that office and also in member associations (to manage tournaments). This permission may be further filtered by division/gender/category, as offices do not have any concept of that.

Note: the office and schedule type may have an impact on assigning. Rules can be configured to assign tournaments by the schedule office (tournaments are typically assigned by the host association) and another rule can be configured to schedule league games based on the arena office. This is a whole design doc in itself.

Teams

A schedule is essentially the table above, and it also has a many-to-many relation with Teams through ScheduleTeams. This is presented on the teams tab of the schedule page, which is the second step when creating a schedule.

This relationship determines what teams can be included in scheduled games and what teams will make up the standings.

When adding a team, any team within the tenant may be added, the user is not limited by the schedule attributes and there is nothing stopping them from adding a U9C team to a U15A schedule if they really wanted.

Games

A game belongs to a single schedule, and it’s stats affect that schedule.

¹ A noted under the schedule, the schedule attributes do not restrict the game attributes, so while the division defaults to the schedule division, you could change the division for the game.

² There is no concept of arena time slots in the existing model. This is currently being developed to add an ArenaSlot model and then extract start/end time and venue from the game to an arena slot instead. The existing API will continue to remain the same.

When entering a game, the list of teams is limited to the teams related to the schedule. The venue is currently not limited, but it theoretically could be limited based on the arena office relations.

Scoresheet

A scoresheet has a 1:1 relation with a game. Nothing special to note here wrt scheduling.

Stats

Stats belong to either a game or a schedule and need to be queried through a schedule. Currently game stats are not publicly exposed.

• Team Game Stats
  gameId, teamId, schemaId, stats

• Team Schedule Stats
  scheduleId, groupId, teamId, schemaId, ranking, stats

• Participant Game Stats
  gameId, participantId, teamId, schemaId, type, stats

• Participant Schedule Stats
  scheduleId, groupId, participantId, teamId, schemaId, type, ranking stats

Each completed scoresheet produces game stats, which are aggregated into schedule stats. Participant stats have a type to identify whether they’re skater or goalie stats.