KOKIA YRA TREČIOJI NORMALIOJI FORMA? (DUOMENŲ BAZĖS) - TECHNOLOGIJA - 2025

Trečias normalus forma (duomenų bazės) yra reliacinės duomenų bazės dizainas technika, kur skirtingi stalai, kurie sudaro jos laikytis ne tik su antroje normalios formos, tačiau visos jos elementai ar laukai tiesiogiai priklauso nuo pirminio rakto.

Kuriant duomenų bazę, pagrindinis tikslas yra sukurti tikslų duomenų, jų tarpusavio ryšių ir tinkamų duomenų apribojimų atvaizdą.

Šaltinis: pixabay.com

Norint pasiekti šį tikslą, gali būti naudojami kai kurie duomenų bazių projektavimo būdai, tarp kurių yra normalizavimas.

Tai yra duomenų tvarkymo duomenų bazėje procesas, siekiant išvengti pertekliaus ir galimų duomenų įterpimo, atnaujinimo ar pašalinimo anomalijų, sukuriant paprastą ir stabilų koncepcinio modelio dizainą.

Tai pradedama tiriant funkcinius ryšius ar priklausomybę tarp požymių. Tai apibūdina tam tikrą duomenų savybę arba jų ryšį.

Normalios formos

Normalizavimui naudojama testų, vadinamų normaliomis formomis, serija, padedanti nustatyti optimalų šių požymių grupavimą ir galiausiai nustatyti tinkamą ryšių, palaikančių įmonės duomenų reikalavimus, rinkinį.

Tai yra, normalizavimo technika yra pagrįsta normalios formos sąvoka, apibrėžiančia apribojimų sistemą. Jei santykiai atitinka tam tikros normalios formos suvaržymus, yra sakoma, kad santykiai yra normalios formos.

Pirmoji normali forma (1FN)

Sakoma, kad lentelė yra 1FN, jei visi jos atributai ar laukai turi tik unikalias reikšmes. T. y. Kiekviena kiekvieno atributo reikšmė turi būti nedaloma.

Pagal apibrėžimą reliacinė duomenų bazė visada bus normalizuota į pirmąją normaliąją formą, nes atributų reikšmės visada yra atominės. Visi santykiai duomenų bazėje yra 1FN.

Tačiau paprasčiausias duomenų bazės palikimas skatina daugybę problemų, tokių kaip atleidimas iš darbo ir galimos naujovinimo nesėkmės. Šioms problemoms ištaisyti buvo sukurtos aukštesnės normalios formos.

Antroji normalioji forma (2FN)

Jis susijęs su apskrito priklausomybių pašalinimu nuo stalo. Sakoma, kad santykis yra 2FN, jei jis yra 1FN, be to, kiekvienas ne rakto laukas ar atributas visiškai priklauso nuo pirminio rakto, tiksliau, jis užtikrina, kad lentelė turi vieną tikslą.

Ne rakto atributas yra bet koks atributas, kuris nėra pirminis santykių raktas.

Trečioji normalioji forma (3FN)

Jame siekiama pašalinti pereinamąsias priklausomybes nuo stalo. Tai yra, pašalinti ne rakto atributus, kurie nepriklauso nuo pirminio rakto, bet nuo kito atributo.

Tranzityvioji priklausomybė yra funkcinės priklausomybės rūšis, kai ne rakto lauko ar atributo vertė nustatoma pagal kito lauko, kuris taip pat nėra raktas, vertę.

Reikėtų pakartoti ne rakto atributų reikšmes, kad įsitikintumėte, jog šie ne rakto atributai nepriklauso nuo nieko, išskyrus pirminį raktą.

Sakoma, kad atributai yra vienas nuo kito nepriklausomi, jei nė vienas iš jų nėra funkciškai priklausomas nuo kitų derinio. Ši abipusė nepriklausomybė užtikrina, kad atributus galima atnaujinti atskirai, nesukeliant pavojaus paveikti kitą atributą.

Taigi, kad santykiai duomenų bazėje būtų trečiosios normalios formos, jie turi atitikti:

- Visi 2FN reikalavimai.

- Jei yra atributų, nesusijusių su pirminiu raktu, jie turi būti pašalinti ir sudėti į atskirą lentelę, susiejant abi lenteles svetimu raktu. T. y., Neturėtų būti jokių pereinamųjų priklausomybių.

Trečiosios normalios formos pavyzdžiai

1 pavyzdys

Tegul lentelė yra STUDENTAS, kurio pagrindinis raktas yra studento identifikacija (STUDENT_ID) ir kurį sudaro šie atributai: STUDENT_NAME, STREET, CITY ir POST_CODE, tenkinantys 2FN sąlygas.

Šiuo atveju STREET ir CITY neturi tiesioginio ryšio su pirminiu raktu STUDENT_ID, nes jie nėra tiesiogiai susiję su mokiniu, bet yra visiškai priklausomi nuo pašto kodo.

Kadangi studentas įsikūręs svetainėje, kurią nustato CODE_POSTAL, STREET ir CITY yra susijusios su šiuo atributu. Dėl šio antrojo priklausomybės laipsnio nebūtina šių atributų laikyti STUDENTŲ lentelėje.

Sukurkite naują lentelę

Tarkime, kad tame pačiame pašto kode yra keli studentai, lentelėje STUDENTAS yra nepaprastai daug įrašų ir reikia pakeisti gatvės ar miesto pavadinimą, tada šią gatvę ar miestą reikia rasti ir atnaujinti visoje lentelėje STUDENTAS.

Pvz., Jei jums reikia pakeisti gatvę „El Limón“ į „El Limón II“, turėsite ieškoti „El Limón“ visoje STUDENTO lentelėje ir atnaujinti ją į „El Limón II“.

Paieška didžiulėje lentelėje ir vieno ar kelių įrašų atnaujinimas užtruks ilgai, todėl jie turės įtakos duomenų bazės veikimui.

Vietoj to, šią informaciją galima laikyti atskiroje lentelėje (POSTCARD), kuri yra susijusi su STUDENTO lentele, naudojant atributą POST_CODE.

POST lentelė turės palyginti mažiau įrašų, o šią POST lentelę reikės atnaujinti tik vieną kartą. Tai automatiškai atsispindės STUDENTO lentelėje, supaprastindama duomenų bazę ir užklausas. Taigi lentelės bus 3FN:

2 pavyzdys

Tegul ši lentelė naudojama kaip laukas „Project_Num“ kaip pagrindinis raktas ir su pakartotinėmis atributų, kurie nėra raktai, vertėmis.

Telefono vertė kartojama kaskart, kai tik pakartojamas valdytojo vardas. Taip yra todėl, kad telefono numeris priklauso tik nuo antrojo laipsnio projekto projekto. Tai tikrai pirmiausia priklauso nuo vadovo, o tai savo ruožtu priklauso nuo projekto numerio, o tai daro pereinamąją priklausomybę.

Atributas „Project_Manager“ negali būti galimas raktas „Projektų“ lentelėje, nes tas pats valdytojas valdo daugiau nei vieną projektą. Sprendimas yra pašalinti atributą su pakartotiniais duomenimis (Telefonas), sukuriant atskirą lentelę.

Atitinkami atributai turi būti sugrupuoti, sukuriant naują lentelę, kad juos išsaugotumėte. Duomenys įvedami ir patikrinama, ar pakartotos vertės nėra pirminio rakto dalis. Pirminis raktas nustatomas kiekvienai lentelei ir, jei reikia, pridedami pašaliniai raktai.

Norėdami atitikti trečią įprastą formą, problemai išspręsti sukuriama nauja lentelė (vadybininkai). Abi lentelės yra susijusios per lauką „Project_Manager“:

Nuorodos

1. „Teradata“ (2019 m.). Pirma, antra ir trečia normalios formos. Paimta iš: docs.teradata.com.
2. Vadovo taurė (2019 m.). Trečioji normalioji forma (3NF). Paimta iš: tutorialcup.com.
3. Duomenų bazės kūrėjas (2015). Trečioji normalioji forma (3NF) - jūsų duomenų bazės normalizavimas. Paimta iš: databasedev.co.uk.
4. Reliacinis DB dizainas (2019). Įvadas į trečiąją normaliąją formą. Paimta iš: relationaldbdesign.com.
5. Manekenai (2019 m.). SQL pirmoji, antroji ir trečioji normalios formos. Paimta iš: dummies.com.