| 228 | | The relationships `has_stage`, `participation`, `required_attendance`, `announces_absence`, `responsible_for`, `volunteers`, `cooperation`, `related_to`, `holds_function`, `holds_event_function`, and the event-edition location relationship are represented as relations because they either have M:N cardinality, their own attributes, or are clearer without nullable foreign-key columns. The relationship `related_to` is represented separately because only some activity sessions are connected to event editions. The relationship `applies_with` is represented with the foreign key `student_index` in `applications`, because each application belongs to one student. The N:1 relationships `for_function`, `for_participation`, `takes_place_at`, `held_at`, `is_of_function_type`, and `mentorship` are represented directly with foreign keys on the N-side relation. |
| | 228 | The relationships `has_stage`, `participation`, `required_attendance`, `announces_absence`, `responsible_for`, `volunteers`, `cooperation`, `related_to`, `holds_event_function`, and the event-edition location relationship are represented as relations because they either have M:N cardinality, their own attributes, or are clearer without nullable foreign-key columns. The relationship `holds_function` is represented in the relational schema as `function_mandates` because it has the attribute `mandate_year`. The relationship `related_to` is represented separately because only some activity sessions are connected to event editions. The relationship `applies_with` is represented with the foreign key `student_index` in `applications`, because each application belongs to one student. The N:1 relationships `for_function`, `for_participation`, `takes_place_at`, `held_at`, `is_of_function_type`, and `mentorship` are represented directly with foreign keys on the N-side relation. |
