Changes between Version 4 and Version 5 of Normalization

Timestamp:

08/24/25 16:10:31 (9 days ago)

Author:

221007

Comment:

--

Normalization

@@ -172 +172 @@
 Бидејќи **punishment_id → report_id** важи само за криминални извештаи, а **r_d_id → report_id** само за медицински, потребно е да се додаде независно **report_id што ќе биде генеричко за сите можни работи кои може да се стигне од него, бидејќи нема потекло, туку е само report_id**. Со тоа ги опфаќам останатите атрибути кои фалат. Според „**Секој атрибут може да биде дел од кандидат клучот**“, може да се заклучи дека додавањето на report_id е правилно, во склоп на правилата за формирање на супер клучот во нашата шема.
 
-[[span(style="color:#FF0000") complete_closure = {log_id, export_id, punishment_id, r_d_id, report_id}]]
-
+[[span(style="font-size: 20px; color:#FF0000; font-weight: bolder;", complete_closure = { log_id, export_id, punishment_id, r_d_id, report_id } )]]
+
+=== 1NF - Прва Нормална форма
+
+Оваа нормална форма бара секој атрибут во секоја редица да содржи само една вредност, односно атрибутите да не се составени од повеќе вредности. Не смее да има листи, множества или некои типови на колекции кои во суштина даваат повеќе од една информација. 
+
+Пример за нешто што не би било во нормална форма е доколку се постават повеќе вредности за contact_phone (“071628936”, “078549987”) во иста колона. Ова би го нарушило правилот на 1NF.
+
+Ако се прегледа целата шема на базата на податоци, ќе може да се заклучи дека таа ја задоволува првата нормална форма, каде не се увидени повторувачки групи или некои неатомски вредности (повеќе вредности под ист атрибут).
+
+=== 2NF - Втора Нормална форма
+
+Втората нормална форма е задоволена ако е задоволена првата нормална форма и дополнително ако нема парцијални функционални зависности. Подобро објаснето, секој атрибут кој не е примарен, треба целосно да биде функционално зависен од примарниот клуч.
+
+Во оваа фаза, мегарелацијата R е декомпонирана во неколку логички релации, така што:
+* Секој атрибут е целосно функционално зависен од еден атомски примарен клуч
+* Нема парцијални функционални зависности
+* Секоја релација ја задоволува Втората Нормална Форма (2NF)
+
+За да ги отстраниме парцијалните зависности потребно е да ги оделиме атрибутите во релации во кои целосно ќе зависат од нивниот клуч:
+
+export_id -> session_id, export_format, file_name, filter_summary, export_date
+
+punishment_id -> report_id, value_unit, punishment_type, fine_to_pay, release_date
+
+log_id -> profile_id, change_description, changed_at
+
+r_d_id -> diagnosis_id, report_id, added_on
+
+report_id -> report_type, report_created_at, summary, person_id, location, resolved, crime_type_id, descriptive_punishment, academic_field, institution_id, description_of_report, start_date, end_date, job_role, income_per_month, next_control_date, doctor_id
+
+=== BCNF комбинирано со 3NF
+
+R1: export_id PK, session_id , export_format, file_name, filter_summary, export_date – во BCNF
+
+R2: log_id PK, profile_id, change_description, changed_at – во BCNF
+
+R3: punishment_id PK, report_id, value_unit, punishment_type, fine_to_pay, release_date – во BCNF
+
+R4: r_d_id PK, diagnosis_id, report_id, added_on – во BCNF
+
+R5: report_id PK, report_type, report_created_at, summary, person_id, location, resolved, crime_type_id, descriptive_punishment, academic_field, institution_id, description_of_report, start_date, end_date, job_role, income_per_month, next_control_date, doctor_id – е во BCNF, но ќе резултира со многу null полиња во еден запис, по што може да употребиме „''Supertype-Subtype Specialization''“
+
+Бидејќи report_id е клуч кај сите, и тие би биле соодветно диференцирани по тип земајќи го во предвид report_type, ќе може да се издвои еден Supertype и од него да произлегуваат соодветно неколку Subtypes. За правилно да го направиме ова, ќе ги гледаме функционалните зависности:
+
+* R5.1: report_id PK, report_type, report_created_at, summary, person_id – во BCNF
+* R5.1.1: report_id PK, location, resolved, crime_type_id, descriptive_punishment – во BCNF
+* R5.1.2: report_id PK, academic_field, institution_id, description_of_report – во BCNF
+* R5.1.3: report_id PK, start_date, end_date, job_role, income_per_month – во BCNF
+* R5.1.4: report_id PK, next_control_date, doctor_id – во BCNF
+
+Атрибутите од подтип се условни од report_type својството, затоа ги логички подобро би фигурирале во погрануларни релации. Секоја од овие продолжува поединечно да го задоволува својството за BCNF, а со тоа и 3NF.
+
+R6: остатокот од атрибути = { report_id, export_id, log_id, punishment_id, r_d_id, user_id, user_name, user_surname, email, password_hash, is_user_active, user_created_at, role_id, username, profile_created_at, role_name, role_descrioption, filter_description, searched_at, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – во ниту еден случај не е во BCNF
+
+Гарантиравме дека role_name е уникатно, па затоа може да издвоиме релација
+
+Ф.З кои ги гледаме:
+* role_id -> role_name
+* role_name -> role_description
+
+R6.1: role_id PK,  role_name UNIQUE, role_description – во BCNF
+
+R6.2: role_id U R6-initial -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, user_name, user_surname, email, password_hash, is_user_active, user_created_at, role_id, username, profile_created_at, filter_description, searched_at, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+Сега може со корисник да одиме, каде ги гледаме следните Ф.З
+
+* user_id -> email, user_name, user_surname, password_hash, is_user_active, user_created_at
+* email -> user_id
+
+Бидејќи email е во склоп со функционалната зависност, но тој е исто така уникат, може да кажеме дека имаме алтернативен клуч, по кој исто така може да ги пребаруваме самите записи.
+
+R6.2.1: user_id PK, email UNIQUE, user_name, user_surname, password_hash, is_user_active, user_created_at – во BCNF
+
+R6.2.2: user_id U R6.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, username, profile_created_at, filter_description, searched_at, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+Потоа тргнуваме со следната функционална зависност а тоа е
+* profile_id -> user_id, role_id, profile_created_at, username
+
+R6.2.2.1: profile_id PK, user_id UNIQUE FK→R6.2.1, role_id FK→R6.1, profile_created_at, username – во BCNF
+
+R6.2.2.2: profile_id U R6.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, filter_description, searched_at, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+Еве уште една функционална зависност поради која се нарушува правилото за BCNF
+* session_id → user_id, filter_description, searched_at
+
+R6.2.2.2.1: session_id PK, user_id FK→ R6.2.1, filter_description, searched_at – во BCNF
+
+R 6.2.2.2.2: session_id U R6.2.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+Следна Ф.З е
+* person_id → embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone
+
+R6.2.2.2.2.1: person_id PK, embg, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone – во BCNF
+
+R 6.2.2.2.2.2: person_id U R6.2.2.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, institution_name, institution_address, city, type, year_established, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+Потоа следува
+* institution_id -> institution_name, institution_address, city, type, year_established
+
+R6.2.2.2.2.2.1: institution_id PK, institution_name, institution_address, city, type, year_established – во BCNF
+
+R 6.2.2.2.2.2: institution_id U R6.2.2.2.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, label, severity_level, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+* Функционална зависност crime_type_id -> severity_level, label
+
+R6.2.2.2.2.2.2.1: crime_type_id PK, severity_level, label – во BCNF
+
+R 6.2.2.2.2.2.2.2: crime_type_id U R6.2.2.2.2.2.2-> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, doctor_name, doctor_surname, specialization, years_of_experience, is_active, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+* Ф.З doctor_id -> doctor_name, doctor_surname, specialization, years_of_experience, is_active
+
+R6.2.2.2.2.2.2.2.1: doctor_id PK, doctor_name, doctor_surname, specialization, years_of_experience, is_active – во BCNF
+
+R 6.2.2.2.2.2.2.2.2: crime_type_id U R6.2.2.2.2.2.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id, short_description, therapy, is_chronic, severity } – сеуште не е во BCNF
+
+* Ф.З diagnosis_id -> short_description, therapy, is_chronic, severity
+
+R6.2.2.2.2.2.2.2.2.1: diagnosis_id PK, short_description, therapy, is_chronic, severity – во BCNF
+
+R 6.2.2.2.2.2.2.2.2.2: crime_type_id U R6.2.2.2.2.2.2.2.2 -> { report_id, export_id, log_id, punishment_id, r_d_id, user_id, role_id} – оваа релација е непотребна бидејќи содржи само клучеви, кои си имаат веќе свои посебни релации, затоа истата не би била додадена во самата шема од табели.
+
+Издвоени сите релации кои се добиваат на крајот од нормализацијата:
+
+**EXPORT**(export_id PK, session_id FK→SESSION, export_format, file_name, filter_summary, export_date)
+
+**LOG**(log_id PK, profile_id FK→PROFILE, changed_at, change_description)
+
+**PUNISHMENT**(punishment_id PK, report_id FK→CRIMINAL_REPORT, value_unit, punishment_type, fine_to_pay, release_date)
+
+**MEDICALREPORT_DIAGNOSIS**(r_d_id PK, report_id FK→MEDICAL_REPORT, diagnosis_id FK→DIAGNOSIS, added_on)
+
+**REPORT**(report_id PK, report_type, report_created_at, summary, person_id FK→PERSON)
+
+**CRIME_REPORT**(report_id PK/FK→REPORT, location, resolved, crime_type_id FK→CRIME_TYPE, descriptive_punishment)
+
+**ACADEMIC_REPORT**(report_id PK/FK→REPORT, academic_field, institution_id FK→INSTITUTION, description_of_report)
+
+**EMPLOYMENT_REPORT**(report_id PK/FK→REPORT, start_date, end_date, job_role, income_per_month)
+
+**MEDICAL_REPORT**(report_id PK/FK→REPORT, next_control_date, doctor_id FK→DOCTOR)
+
+**USER**(user_id PK, email UNIQUE, user_name, user_surname, password_hash, is_user_active, user_created_at)
+
+**PROFILE**(profile_id PK, user_id UNIQUE FK→USER, role_id FK→ROLE, profile_created_at, username)
+
+**ROLE**(role_id PK, role_name UNIQUE, role_description) (or split ROLE/ROLE_NAME if role_name isn’t unique)
+
+**SESSION**(session_id PK, user_id FK→USER, filter_description, searched_at)
+
+**PERSON**(person_id PK, embg UNIQUE, name, surname, gender, date_of_birth, is_alive, date_of_death, address_of_living, contact_phone)
+
+**INSTITUTION**(institution_id PK, institution_name, institution_address, city, type, year_established)
+
+**CRIME_TYPE**(crime_type_id PK, label, severity_level)
+
+**DOCTOR**(doctor_id PK, doctor_name, doctor_surname, specialization, years_of_experience, is_active)
+
+**DIAGNOSIS**(diagnosis_id PK, short_description, therapy, is_chronic, severity)
+
+=== Заклучок
+Процесот на нормализација на базата на податоци Reportium беше успешно спроведен преку систематска примена на теоријата на релациони бази на податоци. Почнувајќи од единечна мега-релација R која ги содржеше сите можни атрибути од системот, преку детална анализа на функционалните зависности, идентификување на кандидат клучеви и примена на алгоритмот за декомпозиција, успешно се постигна Бојс-Кодова нормална форма (BCNF) за сите релации во шемата.
+
+**''Финалната нормализирана шема се состои од 18 логички поврзани релации кои го опфаќаат целосниот домен на системот Reportium.''**
+
+Секоја релација има јасно дефиниран примарен клуч, не содржи парцијални или транзитивни функционални зависности, и ги задоволува сите критериуми за добар дизајн според теоријата на релациони бази на податоци. Декомпозицијата е извршена **lossless (без загуба на податоци) и dependency-preserving (со зачувување на функционалните зависности)**.
+
+Нормализираната шема е налик на самата шема од почетокот, што покажува добар почетен дизајн и додавањето на нови типови на извештаи или нови ентитети во иднина, не би било проблем бидејќи нема да ја наруши самата скалабилност и нормализираност на шемата во базата на податоци.