Changes between Version 6 and Version 7 of RelationalDesign
- Timestamp:
- 09/15/26 01:45:59 (13 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RelationalDesign
v6 v7 1 1 = Relational Design = 2 2 3 This page documents the relational design for BEST Skopje Hub, based on ERModel_v1 1. The design uses partial transformation from the ER model into a PostgreSQL relational schema. Strong entities are mapped directly to relations, weak entities include the primary keys of their owner entities, specializations are mapped with one relation for the supertype and one relation for each subtype, and M:N relationships are mapped as separate relations.3 This page documents the relational design for BEST Skopje Hub, based on ERModel_v12. The design uses partial transformation from the ER model into a PostgreSQL relational schema. Strong entities are mapped directly to relations, weak entities include the primary keys of their owner entities, specializations are mapped with one relation for the supertype and one relation for each subtype, and M:N relationships are mapped as separate relations. 4 4 5 5 == Descriptive representation of the relational schema == … … 49 49 ) 50 50 51 has_stage(52 student_index, ms_id, valid_from, valid_to,53 PK( student_index, ms_id, valid_from),51 membership_stage_records( 52 msr_id, student_index, ms_id, valid_from, valid_to, 53 PK(msr_id), 54 54 FK(student_index) -> members(student_index), 55 55 FK(ms_id) -> membership_stages(ms_id) … … 75 75 76 76 function_mandates( 77 student_index, of_id, mandate_year,78 PK( student_index, of_id, mandate_year),77 fm_id, student_index, of_id, mandate_year, 78 PK(fm_id), 79 79 FK(student_index) -> full_members(student_index), 80 80 FK(of_id) -> organizational_functions(of_id) … … 222 222 The specialization of students into members and then into observers, young members, full members, and alumni is represented through subtype tables whose primary keys are also foreign keys. `young_members` also contains `mentor_index`, which represents the mentorship relationship directly as a foreign key to `full_members`. 223 223 224 The weak entities from ERModel_v1 1are represented with composite primary keys where they still depend on an owner entity. `event_functions` uses `(ee_id, ef_no)`, and `event_sessions` uses `(ee_id, es_no)`. Other concrete entities such as `activity_sessions` and `event_editions` use their own numeric identifiers.224 The weak entities from ERModel_v12 are represented with composite primary keys where they still depend on an owner entity. `event_functions` uses `(ee_id, ef_no)`, and `event_sessions` uses `(ee_id, es_no)`. Other concrete entities such as `activity_sessions` and `event_editions` use their own numeric identifiers. 225 225 226 226 The Locations entity is represented with `locations`. The relationship between !EventEditions and Locations is represented with `event_edition_locations`. … … 248 248 == AI Use == 249 249 250 AI was used during this phase as a consultation, drafting, and checking tool while preparing the relational design from the already completed ER Model_v11. The AI-assisted parts were reviewed against the existing ER model and project requirements before being included.250 AI was used during this phase as a consultation, drafting, and checking tool while preparing the relational design from the already completed ER model. The AI-assisted parts were reviewed against the existing ER model and project requirements before being included. 251 251 252 252 Full AI usage documentation: [wiki:RelationalDesignAIUsage RelationalDesignAIUsage].
