Нормализација на база и подобрување на дизајн

Функциски зависности и нормализација

Со цел да се постигне функционален и скалабилен дизајн на базата на податоци за веб-апликацијата TravelSage, започнав со обединета релација која ги содржи сите атрибути од моделот. Оваа релација служи како почетна точка за анализа на функционските зависности. Врз основа на таа анализа, се применува нормализација до третата нормална форма (3НФ), при што секој чекор вклучува логичка декомпозиција на релациите со цел да се избегнат вишоци, аномалии при ажурирање и несоодветни зависности. Бидејќи табелата на сите атрибути би била преголема, ја поделив по функционалност на апликацијата:

1. Менаџирање на дестинации и тагови
2. Менаџирање на корисници и нивни активности (рецензии, преференци)
3. Менаџирање на патувања (пакети, активности, резервации)
4. Менаџирање на настани, временски услови

1. Менаџирање на дестинации и тагови

Почетна релација: R = { idDest, imeLokacija, opisLokacija, tipoviMesta, preporachanaSezona, prosechnaTemp, geoLokacija, drzhava, popularnost, ime, opis, idTag, tagOznaka }

Функциски зависности:

• idDest → сите атрибути што се однесуваат на една конкретна дестинација
• idTag → tagOznaka (секој таг има уникатна ознака)

Објаснување: Секој ред во оваа релација ја претставува комбинацијата од дестинација и некој нејзин таг. Бидејќи една дестинација може да има повеќе тагови, а еден таг може да се користи кај повеќе дестинации, станува збор за многу-на-многу релација меѓу idDest и idTag. Од анализата на податоците кои ги собрав при развојот, сметав дека ваквата декомпозиција е најсоодветна за да се овозможи флексибилно поврзување помеѓу дестинации и нивните тагови.

Декомпозиција:

• R1 = { idDest, imeLokacija, opisLokacija, tipoviMesta, preporachanaSezona, prosechnaTemp, geoLokacija, drzhava, popularnost, ime, opis }
• R2 = { idTag, tagOznaka }
• R3 = { idDest, idTag } → релација DESTINACII_HAS_TAGOVI

2. Менаџирање на корисници и нивни активности

Почетна релација: R = { idKorisnik, ime, prezime, ePoshta, telBr, datumRagjanje, tip, idDest, idRecenzija, idRezervacija, korisnichkoIme, kvalitet, zabeleshka, datumRecenzija, brGlasovi, idPreferenca, tipPreferenca, prioritet }

Функциски зависности:

• idKorisnik → сите лични податоци
• idKorisnik, idDest → рецензии и резервации
• idKorisnik → преференци

Објаснување: Еден корисник може да има повеќе рецензии и преференци, но секоја преференца е поврзана со само еден корисник. Резервациите и рецензиите зависат од комбинацијата на корисник и дестинација. R5 е најчувствителна за аномалии при ажурирање, бидејќи содржи различни типови податоци поврзани со повеќе ентитети. Затоа ја третирав посебно внимателно при декомпозицијата.

Декомпозиција:

• R4 = { idKorisnik, ime, prezime, ePoshta, telBr, datumRagjanje, tip }
• R5 = { idKorisnik, idDest, idRecenzija, idRezervacija, korisnichkoIme, kvalitet, zabeleshka, datumRecenzija, brGlasovi }
• R6 = { idPreferenca, idKorisnik, tipPreferenca, prioritet }

3. Менаџирање на патувања, активности и резервации

Почетна релација: R = { idPaket, imePaket, cena, pochetok, kraj, idDest, idAktivnost, imeAktivnost, informacii, kategorija, iznos, idRezervacija, idKorisnik, vremenskaTochka, status, vkupnaCena, idMeteo }

Функциски зависности:

• idPaket → основни податоци за патниот пакет
• idAktivnost → опис на активноста
• idRezervacija → информации за резервацијата
• idAktivnost, idPaket → активности во конкретен пакет

Објаснување: Секој патен пакет може да содржи повеќе активности, а секоја активност може да биде вклучена во повеќе пакети (многу-на-многу). Корисникот прави резервација за конкретен пакет, а понекогаш и за поединечна активност.

Декомпозиција:

• R7 = { idPaket, imePaket, cena, pochetok, kraj, idDest, vkupnaCena, idMeteo }
• R8 = { idAktivnost, imeAktivnost, informacii, kategorija, iznos, idDest }
• R9 = { idPaket, idAktivnost }
• R10 = { idRezervacija, idKorisnik, idPaket, vremenskaTochka, status }
• R11 = { idRezervacija, idAktivnost }

4. Менаџирање на настани и метеоролошки услови

Почетна релација: R = { idNastan, naziv, vidovi, pochetenDatum, kraenDatum, detali, idDest, idMeteo, momentTemp, sostojbaVreme, predupreduvanja, vlazhnost, veter, mesec, datum }

Функциски зависности:

• idNastan → сите податоци за настанот
• idMeteo → временски параметри

Објаснување: Секој настан е поврзан со одредена дестинација и има временски услови регистрирани преку idMeteo. Метео податоците може да се поврзат и со други настани на истата локација, така што е логично да се одвојат.

Декомпозиција:

• R12 = { idNastan, naziv, vidovi, pochetenDatum, kraenDatum, detali, idDest, idMeteo }
• R13 = { idMeteo, momentTemp, sostojbaVreme, predupreduvanja, vlazhnost, veter, mesec, datum, idDest }

Кратко резиме

1NF Сите релации се во 1NF — атрибутите се атомарни, без листи или вгнездени структури.

2NF Секој non-prime атрибут целосно зависи од примарниот клуч, така што нема парцијални функционални зависности. Пример: Во R5 (рецензии), PK=(idKorisnik, idDest, idRecenzija), а сите други атрибути зависат од нив комбинација, не од дел од нив.

3NF Сите non-prime атрибути зависат директно од PK, нема транзитивни зависимости (ниедно A → B → C). Пример: idMeteo → метео параметри, и idMeteo е дел од PK во R13, па нема транзитивност.

• Lossless & Dependency‑preserving decomposition - Декомпозициите се lossless, бидејќи за сите R → R1, R2, пресекот вклучува PK, а PK → R1 или R2 е Functional dependency во F+. Исто така, декомпозицијата е dependency‑preserving бидејќи сите оригинални функционални зависимости се реализирани во новите релации без потреба за join.

Примената на функционска декомпозиција и нормализација до третата нормална форма (3НФ) резултира со оптимизирана структура на базата која ги исполнува следниве цели:

• Елиминација на вишоци и дупликации
• Отстранување на аномалии при внесување, бришење или ажурирање
• Подобра логичка организација на податоците
• Јасна поделба според функционалност (модули)
• Можност за идно проширување на моделот без пречки

На овој начин, дизајнот на базата не само што ги задоволува тековните барања на апликацијата TravelSage, туку и обезбедува стабилна основа за нејзина понатамошна еволуција.

Целиот процес го дизајнирав така што ќе овозможи јасна логичка структура во иднина. Од моја перспектива, ова е особено важно за апликации како TravelSage што може да прераснат во посложени системи.