| 1 | | . |
| | 1 | = Normalization = |
| | 2 | |
| | 3 | == De-normalized database form == |
| | 4 | To begin, we combine all attributes from the ER model into a single universal relation '''R''': |
| | 5 | |
| | 6 | {{{ |
| | 7 | R = {univ_id, univ_name, univ_location, univ_is_private, fac_id, fac_name, fac_location, |
| | 8 | fac_study_field, prof_id, prof_name, prof_surname, prof_age, stud_id, stud_name, |
| | 9 | stud_surname, stud_location, stud_index, subj_id, subj_name, subj_semester, |
| | 10 | subj_credits, enroll_id, enroll_date, final_grade, status, absence_count, |
| | 11 | advice_id, request_sent, consult_date, advice_status} |
| | 12 | }}} |
| | 13 | |
| | 14 | == Functional dependencies == |
| | 15 | The canonical cover of functional dependencies based on the project business rules: |
| | 16 | |
| | 17 | univ_id -> {univ_name, univ_location, univ_is_private} |
| | 18 | |
| | 19 | fac_id -> {fac_name, fac_location, fac_study_field, univ_id} |
| | 20 | |
| | 21 | prof_id -> {prof_name, prof_surname, prof_age, fac_id} |
| | 22 | |
| | 23 | stud_id -> {stud_name, stud_surname, stud_location, stud_index, fac_id} |
| | 24 | |
| | 25 | subj_id -> {subj_name, subj_semester, subj_credits, fac_id} |
| | 26 | |
| | 27 | {prof_id, subj_id} -> (The "Teach" relationship) |
| | 28 | |
| | 29 | {stud_id, subj_id} -> {enroll_date, final_grade, status, absence_count} |
| | 30 | |
| | 31 | {stud_id, prof_id} -> {request_sent, consult_date, advice_status} |
| | 32 | |
| | 33 | == Candidate keys and primary key == |
| | 34 | |
| | 35 | '''Candidate Key:''' {stud_id, prof_id, subj_id} |
| | 36 | |
| | 37 | '''Primary Key:''' {stud_id, prof_id, subj_id} |
| | 38 | |
| | 39 | '''Current Normal Form:''' '''1NF'''. The relation is in 1NF because all attributes are atomic, but it contains massive redundancies and partial dependencies. |
| | 40 | |
| | 41 | == 2NF decomposition == |
| | 42 | '''Analysis:''' The universal relation '''R''' has multiple Partial Functional Dependencies, where non-key attributes depend on only part of the primary key. |
| | 43 | |
| | 44 | '''Step 1:''' Attributes depending only on stud_id are moved to a new relation '''Student'''. |
| | 45 | |
| | 46 | '''Step 2:''' Attributes depending only on prof_id are moved to a new relation '''Professor'''. |
| | 47 | |
| | 48 | '''Step 3:''' Attributes depending only on subj_id are moved to a new relation '''Subject'''. |
| | 49 | |
| | 50 | '''Step 4:''' Attributes depending on the combinations are moved to junction relations. |
| | 51 | |
| | 52 | '''Resulting Relations:''' |
| | 53 | |
| | 54 | '''R1 (Student):''' {stud_id, name, surname, location, index, fac_id} |
| | 55 | |
| | 56 | '''R2 (Professor):''' {prof_id, name, surname, age, fac_id} |
| | 57 | |
| | 58 | '''R3 (Subject):''' {subj_id, name, semester, credits, fac_id} |
| | 59 | |
| | 60 | '''R4 (University_Data):''' {univ_id, univ_name, univ_location, univ_is_private} |
| | 61 | |
| | 62 | '''R5 (Faculty_Data):''' {fac_id, fac_name, fac_location, fac_study_field, univ_id} |
| | 63 | |
| | 64 | '''R6 (Enrollment):''' {stud_id, subj_id, enroll_date, grade, status, absence} |
| | 65 | |
| | 66 | '''R7 (Advice):''' {stud_id, prof_id, request_sent, consult_date, status} |
| | 67 | |
| | 68 | '''R8 (Teach):''' {prof_id, subj_id} |
| | 69 | |
| | 70 | == 3NF decomposition == |
| | 71 | '''Analysis:''' We check for Transitive Dependencies. In '''R1 (Student)''', the fac_id determines the faculty location, but since we already moved faculty attributes to '''R5''', there are no remaining transitive dependencies in the primary entities. All non-key attributes are now functionally dependent only on the primary keys of their respective tables. |
| | 72 | |
| | 73 | == BCNF if possible == |
| | 74 | '''Analysis:''' A relation is in BCNF if for every non-trivial dependency X -> Y, X is a superkey. In our Enrollment ('''R6'''), Advice ('''R7'''), and Teach ('''R8''') relations, the determinants are the composite primary keys. The design is already in BCNF. |
| | 75 | |
| | 76 | == Final result and discussion == |
| | 77 | === Normalized relational model === |
| | 78 | The final design consists of 8 normalized tables: |
| | 79 | |
| | 80 | '''University''' (univ_id, name, location, is_private) |
| | 81 | |
| | 82 | '''Faculty''' (fac_id, name, location, study_field, univ_id) |
| | 83 | |
| | 84 | '''Professor''' (prof_id, name, surname, age, fac_id) |
| | 85 | |
| | 86 | '''Student''' (stud_id, name, surname, location, index, fac_id) |
| | 87 | |
| | 88 | '''Subject''' (subj_id, name, semester, credits, fac_id) |
| | 89 | |
| | 90 | '''Subject_Professor''' (prof_id, subj_id) |
| | 91 | |
| | 92 | '''Student_Subject''' (stud_id, subj_id, enroll_date, final_grade, status, absence_count) |
| | 93 | |
| | 94 | '''Advice''' (stud_id, prof_id, request_sent, consult_date, advice_status) |
| | 95 | |
| | 96 | === Discussion === |
| | 97 | The decomposition process successfully eliminated update, insertion, and deletion anomalies. Formal normalization confirmed that the "Teach" relationship must be a separate junction table (subject_professor) to avoid partial dependency issues. All decompositions preserve functional dependencies and maintain loss-less join properties. |
| | 98 | |
| | 99 | = Normalization AI Usage = |
| | 100 | |
| | 101 | '''Name of AI service:''' Gemini 3 Flash |
| | 102 | |
| | 103 | '''URL:''' https://gemini.google.com/ |
| | 104 | |
| | 105 | '''Type of service:''' Free Tier |
| | 106 | |
| | 107 | '''Final result:''' AI verified functional dependencies against the ER diagram and provided BCNF decomposition logic. |
| | 108 | |
| | 109 | '''Results in details:''' |
| | 110 | |
| | 111 | '''Dependency Mapping:''' AI mapped "Advises" and "Teaches" relationships into junction tables. |
| | 112 | |
| | 113 | '''Formatting:''' AI structured the documentation for Trac WikiMarkup. |
| | 114 | |
| | 115 | '''Corrective Logic:''' AI identified the need for separate University and Faculty relations. |