Changes between Version 4 and Version 5 of Normalization


Ignore:
Timestamp:
09/25/25 12:41:48 (3 weeks ago)
Author:
223270
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Normalization

    v4 v5  
    33
    44
    5 Со цел да се постигне функционален и скалабилен дизајн на базата на податоци за веб-апликацијата TravelSage, започнав со обединета релација која ги содржи сите атрибути од моделот. Оваа релација служи како почетна точка за анализа на функционските зависности. Врз основа на таа анализа, се применува нормализација до третата нормална форма (3НФ), при што секој чекор вклучува логичка декомпозиција на релациите со цел да се избегнат вишоци, аномалии при ажурирање и несоодветни зависности.
     5Со цел да се постигне функционален и скалабилен дизајн на базата на податоци за веб-апликацијата TravelSage, започнав со обединета релација која ги содржи сите атрибути од моделот. Оваа релација служи како почетна точка за анализа на функционалните зависности. Врз основа на таа анализа, се применува нормализација до третата нормална форма (3НФ), при што секој чекор вклучува логичка декомпозиција на релациите со цел да се избегнат вишоци, аномалии при ажурирање и несоодветни зависности.
     6
    67Бидејќи табелата на сите атрибути би била преголема, ја поделив по функционалност на апликацијата:
    7 1.      Менаџирање на дестинации и тагови
    8 2.      Менаџирање на корисници и нивни активности (рецензии, преференци)
    9 3.      Менаџирање на патувања (пакети, активности, резервации)
    10 4.      Менаџирање на настани, временски услови
    11 
     8* Менаџирање на дестинации и тагови
     9* Менаџирање на корисници и нивни активности (рецензии, преференци, телефони)
     10* Менаџирање на патувања (пакети, активности, резервации)
     11* Менаџирање на настани и временски услови
     12* Менаџирање на метеоролошки податоци
    1213
    1314=== 1. Менаџирање на дестинации и тагови
    1415Почетна релација:
    15 R = { idDest, imeLokacija, opisLokacija, tipoviMesta, preporachanaSezona, prosechnaTemp, geoLokacija, drzhava, popularnost, ime, opis, idTag, tagOznaka }
     16R = { id_destination, location_name, location_desc, types_of_places, recommended_season, average_temp, latitude, longitude, country, popularity, important_location_name, important_location_description, id_tag, tag_name }
    1617
    1718
    1819Функциски зависности:
    19 •       idDest → сите атрибути што се однесуваат на една конкретна дестинација
    20 •       idTag → tagOznaka (секој таг има уникатна ознака)
    21 
     20* id_destination → сите атрибути што се однесуваат на една конкретна дестинација
     21* id_tag → tag_name
    2222
    2323Објаснување:
    24 Секој ред во оваа релација ја претставува комбинацијата од дестинација и некој нејзин таг. Бидејќи една дестинација може да има повеќе тагови, а еден таг може да се користи кај повеќе дестинации, станува збор за многу-на-многу релација меѓу idDest и idTag.
    25 Од анализата на податоците кои ги собрав при развојот, сметав дека ваквата декомпозиција е најсоодветна за да се овозможи флексибилно поврзување помеѓу дестинации и нивните тагови.
     24Секој ред во оваа релација ја претставува комбинацијата од дестинација и нејзиниот таг. Една дестинација може да има повеќе тагови, а еден таг може да се користи кај повеќе дестинации → многу-на-многу релација. Слично, types_of_places и recommended_season се повеќевредносни атрибути и мораат да се одвоени. important_location_name + important_location_description се сложени атрибути, па се декомпонирани во посебна табела.
    2625
    27 
    28 1НФ: Сите атрибути се атомарни - задоволена
    29 
    30 2НФ: tagOznaka не зависи од idDest, па се одделува - не е целосно (бидејќи tagOznaka не зависи од idDest)
    31 
    32 3НФ: Нема транзитивни зависности - не (заради 2НФ)
    33 
     26Нормализација:
     27* 1НФ: Сите атрибути се атомарни (поделени се).
     28* 2НФ: Податоците за тагови и повеќевредносни атрибути се одвоени во посебни табли, зависни од PK.
     29* 3НФ: Нема транзитивни зависности; сите non-prime атрибути зависат само од PK.
    3430
    3531Декомпозиција:
    36 •       R1 = { idDest, imeLokacija, opisLokacija, tipoviMesta, preporachanaSezona, prosechnaTemp, geoLokacija, drzhava, popularnost, ime, opis }
    37 •       R2 = { idTag, tagOznaka }
    38 •       R3 = { idDest, idTag } → релација DESTINACII_HAS_TAGOVI
     32R1 = { id_destination, location_name, location_desc, average_temp, latitude, longitude, country, popularity }
     33
     34R2 = { id_tag, tag_name }
     35
     36R3 = { id_destination, id_tag } → destination_has_tags
     37
     38R4 = { id_destination, place_type } → destination_place_type
     39
     40R5 = { id_destination, season } → destination_season
     41
     42R6 = { id_location, id_destination, name, description } → important_location
    3943
    4044
    … …  
    4246=== 2. Менаџирање на корисници и нивни активности
    4347Почетна релација:
    44 R = { idKorisnik, ime, prezime, ePoshta, telBr, datumRagjanje, tip, idDest, idRecenzija, idRezervacija, korisnichkoIme, kvalitet, zabeleshka, datumRecenzija, brGlasovi, idPreferenca, tipPreferenca, prioritet }
     48R = { id_user, first_name, last_name, email, phone_number, birth_date, is_premium, id_review, id_reservation, username, quality, comment, review_date, vote_count, id_preference, type_preference, priority }
    4549
    4650
    4751Функциски зависности:
    48 •       idKorisnik → сите лични податоци
    49 •       idKorisnik, idDest → рецензии и резервации
    50 •       idKorisnik → преференци
     52* id_user → сите лични податоци
     53* id_user, id_destination → рецензии и резервации
     54* id_user → преференци
     55* id_user → повеќе телефонски броеви
    5156
    5257
    5358Објаснување:
    54 Еден корисник може да има повеќе рецензии и преференци, но секоја преференца е поврзана со само еден корисник. Резервациите и рецензиите зависат од комбинацијата на корисник и дестинација. R5 е најчувствителна за аномалии при ажурирање, бидејќи содржи различни типови податоци поврзани со повеќе ентитети. Затоа ја третирав посебно внимателно при декомпозицијата.
     59Еден корисник може да има повеќе рецензии, преференци и телефонски броеви. Секој non-prime атрибут мора да зависи од целосен PK на релацијата, а не од дел од него. Повеќевредносните атрибути се одвоени во посебни табли.
    5560
    56 
    57 1НФ: Атомарни вредности - задоволена
    58 
    59 2НФ: Одделени се податоците за рецензии и преференци за да се избегнат парцијални зависности - не (рецензии и преференци не зависат од цел клуч)
    60 
    61 3НФ: Нема транзитивни врски (на пример, ePoshta не одредува korisnichkoIme) - не (можна транзитивност korisnichkoIme ↔ ePoshta)
     61Нормализација:
     62* 1НФ: Атомарни вредности (phone_number, type_preference распарсани).
     63* 2НФ: Рецензии, преференци и телефони се одвоени во посебни табли за да нема делумни FD.
     64* 3НФ: Нема транзитивни зависимости; username се елиминира и се користи reservation → user.
    6265
    6366
    6467Декомпозиција:
    65 •       R4 = { idKorisnik, ime, prezime, ePoshta, telBr, datumRagjanje, tip }
    66 •       R5 = { idKorisnik, idDest, idRecenzija, idRezervacija, korisnichkoIme, kvalitet, zabeleshka, datumRecenzija, brGlasovi }
    67 •       R6 = { idPreferenca, idKorisnik, tipPreferenca, prioritet }
     68R7 = { id_user, first_name, last_name, email, birth_date, is_premium }
     69
     70R8 = { id_user, phone_number } → user_phone
     71
     72R9 = { id_review, id_user, id_destination, quality, comment, review_date, vote_count } → review
     73
     74R10 = { id_preference, id_user, priority }
     75
     76R11 = { id_preference, type_preference } → preference_type
    6877
    6978
    … …  
    7180=== 3. Менаџирање на патувања, активности и резервации
    7281Почетна релација:
    73 R = { idPaket, imePaket, cena, pochetok, kraj, idDest, idAktivnost, imeAktivnost, informacii, kategorija, iznos, idRezervacija, idKorisnik, vremenskaTochka, status, vkupnaCena, idMeteo }
     82R = { id_package, package_name, price, start_date, end_date, id_destination, id_activity, activity_name, information, category, amount, id_reservation, id_user, time_point, premium_discount_applied, discount_amount, total_price }
    7483
    7584
    7685Функциски зависности:
    77 •       idPaket → основни податоци за патниот пакет
    78 •       idAktivnost → опис на активноста
    79 •       idRezervacija → информации за резервацијата
    80 •       idAktivnost, idPaket → активности во конкретен пакет
     86* id_package → основни податоци за пакет
     87* id_activity → опис на активноста
     88* id_reservation → информации за резервацијата
     89* id_activity, id_package → активности во пакет
    8190
    8291
    8392Објаснување:
    84 Секој патен пакет може да содржи повеќе активности, а секоја активност може да биде вклучена во повеќе пакети (многу-на-многу). Корисникот прави резервација за конкретен пакет, а понекогаш и за поединечна активност.
     93Многу-на-многу релација меѓу пакети и активности. Резервации се однесуваат на пакети или активности. category е повеќевредносен атрибут → одвоен.
    8594
    8695
    87 1НФ: Атомарни вредности - задоволена
    88 
    89 2НФ: Резервации и активности се одвоени, бидејќи не зависат од целиот составен клуч -  не (многу информации зависат од дел од клучот)
    90 
    91 3НФ: Нема транзитивни зависимости (на пример, idMeteo е надворешен клуч, но сите метео атрибути се одвоени)  - не (пр. idMeteo има свои податоци, што се мешаат)
     96Нормализација:
     97* 1НФ: Атомарни вредности.
     98* 2НФ: Резервации и активности се одвоени.
     99* 3НФ: Нема транзитивни зависимости; PK е секогаш јасен.
    92100
    93101
    94102Декомпозиција:
    95 •       R7 = { idPaket, imePaket, cena, pochetok, kraj, idDest, vkupnaCena, idMeteo }
    96 •       R8 = { idAktivnost, imeAktivnost, informacii, kategorija, iznos, idDest }
    97 •       R9 = { idPaket, idAktivnost }
    98 •       R10 = { idRezervacija, idKorisnik, idPaket, vremenskaTochka, status }
    99 •       R11 = { idRezervacija, idAktivnost }
     103R12 = { id_package, package_name, price, start_date, end_date, id_destination }
     104
     105R13 = { id_activity, activity_name, information, amount, id_destination }
     106
     107R14 = { id_package, id_activity } → package_activity
     108
     109R15 = { id_reservation, id_user, id_package, time_point, premium_discount_applied, discount_amount, total_price }
     110
     111R16 = { id_reservation, id_activity } → activity_reservation
    100112
    101113
    … …  
    103115=== 4. Менаџирање на настани и метеоролошки услови
    104116Почетна релација:
    105 R = { idNastan, naziv, vidovi, pochetenDatum, kraenDatum, detali, idDest, idMeteo, momentTemp, sostojbaVreme, predupreduvanja, vlazhnost, veter, mesec, datum }
     117R = { id_event, event_name, event_type, start_date, end_date, details, id_destination, id_meteo, current_temp, weather_condition, warnings, humidity, wind, month }
    106118
    107119
    108120Функциски зависности:
    109 •       idNastan → сите податоци за настанот
    110 •       idMeteo → временски параметри
     121* id_event → сите атрибути за настан
     122* id_meteo → временски параметри (weather_condition и warnings се мулти)
    111123
    112124
    113125Објаснување:
    114 Секој настан е поврзан со одредена дестинација и има временски услови регистрирани преку idMeteo. Метео податоците може да се поврзат и со други настани на истата локација, така што е логично да се одвојат.
     126Секој настан е поврзан со дестинација и метео податоци. Повеќевредносните атрибути weather_condition и warnings се декомпонирани во посебни табли.
    115127
    116128
    117 1НФ: Атомарни вредности - задоволена
    118 
    119 2НФ: idMeteo атрибути одвоени во посебна релација - не (метео не зависат од idNastan)
    120 
    121 3НФ: Нема A → B → C транзитивни врски - не (заради мешање на idMeteo податоци)
    122 
     129Нормализација:
     130* 1НФ: Атомарни вредности (мулти атрибути корегирани).
     131* 2НФ: Метео податоците се во посебна релација.
     132* 3НФ: Нема транзитивни врски.
    123133
    124134Декомпозиција:
    125 •       R12 = { idNastan, naziv, vidovi, pochetenDatum, kraenDatum, detali, idDest, idMeteo }
    126 •       R13 = { idMeteo, momentTemp, sostojbaVreme, predupreduvanja, vlazhnost, veter, mesec, datum, idDest }
     135R17 = { id_event, event_name, start_date, end_date, details, id_destination }
     136
     137R18 = { id_event, event_type } → event_type
     138
     139R19 = { id_meteo, id_destination, current_temp, humidity, wind, month } → meteorological_condition
     140
     141R20 = { id_meteo, condition_value } → meteo_condition_value
     142
     143R21 = { id_meteo, warning_text } → meteo_warning_value
    127144
    128145
    129146=== Кратко резиме
    130 1NF
    131 Сите релации се во 1NF — атрибутите се атомарни, без листи или вгнездени структури.
     147* 1NF: Сите релации се атомарни, без list или вгнездени структури.
     148* 2NF: Секој non-prime атрибут зависи од целиот PK; делумни зависности се елиминирани.
     149* 3NF: Нема транзитивни зависимости.
    132150
     151Lossless & Dependency‑preserving decomposition:
     152* Декомпозициите се lossless, бидејќи пресеците секогаш вклучуваат PK, а сите FD се зачувани.
    133153
    134 2NF
    135 Секој non-prime атрибут целосно зависи од примарниот клуч, така што нема парцијални функционални зависности. Пример: Во R5 (рецензии), PK=(idKorisnik, idDest, idRecenzija), а сите други атрибути зависат од нив комбинација, не од дел од нив.
     154Придобивки од нормализација:
     155*Елиминација на вишоци и дупликации
     156* Отстранување на аномалии при внесување, бришење или ажурирање
     157* Подобра логичка организација на податоците
     158* Јасна поделба според функционалност (модули)
     159* Можност за идно проширување на моделот без пречки
    136160
    137 
    138 3NF
    139 Сите non-prime атрибути зависат директно од PK, нема транзитивни зависимости (ниедно A → B → C). Пример: idMeteo → метео параметри, и idMeteo е дел од PK во R13, па нема транзитивност.
    140 
    141 
    142 * Lossless & Dependency‑preserving decomposition - Декомпозициите се lossless, бидејќи за сите R → R1, R2, пресекот вклучува PK, а PK → R1 или R2 е Functional dependency во F+. Исто така, декомпозицијата е dependency‑preserving бидејќи сите оригинални функционални зависимости се реализирани во новите релации без потреба за join.
    143 
    144 
    145 
    146 Примената на функционска декомпозиција и нормализација до третата нормална форма (3НФ) резултира со оптимизирана структура на базата која ги исполнува следниве цели:
    147 •       Елиминација на вишоци и дупликации
    148 •       Отстранување на аномалии при внесување, бришење или ажурирање
    149 •       Подобра логичка организација на податоците
    150 •       Јасна поделба според функционалност (модули)
    151 •       Можност за идно проширување на моделот без пречки
    152 На овој начин, дизајнот на базата не само што ги задоволува тековните барања на апликацијата TravelSage, туку и обезбедува стабилна основа за нејзина понатамошна еволуција.
    153 
    154 
    155 Целиот процес го дизајнирав така што ќе овозможи јасна логичка структура во иднина. Од моја перспектива, ова е особено важно за апликации како TravelSage што може да прераснат во посложени системи.
     161На овој начин, дизајнот на базата ги исполнува тековните барања на апликацијата TravelSage и обезбедува стабилна основа за идно проширување и еволуција.