MI A HARMADIK NORMÁL FORMA? (ADATBÁZISOK) - TECHNOLÓGIA - 2025

A harmadik normál forma (adatbázisok) egy relációs adatbázis-tervezési technika, ahol az azt alkotó különféle táblák nemcsak megfelelnek a második normál formanak, hanem annak összes attribútuma vagy mezője közvetlenül függ az elsődleges kulcstól.

Az adatbázis tervezésekor a fő cél az adatok pontos ábrázolása, az azok közötti kapcsolatok és az adatokra vonatkozó korlátozások pontos létrehozása.

Forrás: pixabay.com

E cél elérése érdekében néhány adatbázis-tervezési technika alkalmazható, ezek között a normalizálás.

Ez egy olyan eljárás, amelyben az adatokat egy adatbázisban rendezik, hogy elkerüljék az adatok beillesztésének, frissítésének vagy kiküszöbölésének esetleges rendellenességeit és esetleges rendellenességeit, és így a fogalmi modell egyszerű és stabil kialakítását hozzák létre.

A tulajdonságok közötti funkcionális kapcsolat vagy függőség vizsgálatával kezdődik. Ezek leírják az adatok bizonyos tulajdonságait vagy a közöttük fennálló kapcsolatot.

Normál alakzatok

A normalizálás egy teszt-sorozatot használ, amelyet normál formáknak neveznek, hogy megkönnyítsék ezen attribútumok optimális csoportosítását, és végül létrehozzák a megfelelő kapcsolatkészletet, amely támogatja a vállalat adatszolgáltatási követelményeit.

Vagyis a normalizálási technika a normál forma koncepciójára épül, amely meghatározza a kényszerrendszert. Ha egy kapcsolat megfelel egy adott normál forma korlátainak, akkor azt mondják, hogy a kapcsolat ebben a normál formában van.

Első normál forma (1FN)

Azt mondják, hogy egy táblázat 1FN-ben van, ha az összes attribútum vagy mező csak egyedi értékeket tartalmaz. Vagyis az attribútumok minden értékének oszthatatlannak kell lennie.

Definíció szerint egy relációs adatbázis mindig normalizálódik az első normál formára, mivel az attribútumértékek mindig atomi értékek. Az adatbázisban szereplő összes kapcsolat 1FN-ben van.

Az adatbázis ilyen egyszerű elhagyása azonban számos problémát ösztönöz, például redundációt és esetleges frissítési hibákat. Ezen problémák orvoslására magasabb normál formákat fejlesztettek ki.

Második normál forma (2FN)

A kör alakú függőségeknek az asztalról történő eltávolításával foglalkozik. Azt mondják, hogy egy reláció 2FN-ben van, ha az 1FN-ben van, és emellett minden nem kulcsmező vagy attribútum teljes mértékben az elsődleges kulcstól függ, vagy pontosabban biztosítja, hogy a tábla egyetlen célja legyen.

Nem kulcsfontosságú attribútum bármely olyan attribútum, amely nem része a kapcsolat elsődleges kulcsának.

Harmadik normál forma (3FN)

A tranzitív függőségek megszüntetésével foglalkozik egy táblából. Vagyis távolítsa el a nem kulcstartományokat, amelyek nem az elsődleges kulttól, hanem egy másik attribútumtól függnek.

A tranzitív függőség egy olyan típusú funkcionális függőség, amelyben a nem kulcsmező vagy az attribútum értékét egy másik mező értéke határozza meg, amely szintén nem kulcs.

Meg kell ismételnie az értékeket a nem-kulcs attribútumokban annak biztosítása érdekében, hogy ezek a nem-kulcs-attribútumok nem az elsődleges kulcson múlik.

Azt mondják, hogy az attribútumok kölcsönösen függetlenek, ha funkcionálisan egyikük sem függ mások kombinációjától. Ez a kölcsönös függetlenség biztosítja, hogy az attribútumok egyénileg frissíthetők, anélkül, hogy veszélyt jelenthet egy másik attribútum megsértésére.

Ezért ahhoz, hogy az adatbázis kapcsolata harmadik normál formában legyen, ennek meg kell felelnie:

- A 2FN összes követelménye.

- Ha vannak olyan attribútumok, amelyek nem kapcsolódnak az elsődleges kulcshoz, akkor azokat el kell távolítani és külön táblába kell helyezni, mindkét táblát idegen kulcs segítségével kapcsolva. Vagyis nem lehetnek tranzitív függőségek.

Példák a harmadik normál formára

1. példa

Legyen a táblázat STUDENT, amelynek elsődleges kulcsa a hallgató azonosítása (STUDENT_ID), és a következő attribútumokból áll: STUDENT_NAME, STREET, CITY és POST_CODE, teljesítve a 2FN feltételeket.

Ebben az esetben a STREET-nek és a CITY-nak nincs közvetlen kapcsolata a STUDENT_ID elsődleges kulccsal, mivel ezek nem állnak közvetlenül a hallgatóhoz, hanem teljesen az irányítószámtól függenek.

Mivel a hallgató a CODE_POSTAL által meghatározott helyszínen található, a STREET és a CITY kapcsolatban áll ezzel az attribútummal. E függőség második fokának köszönhetően nem szükséges ezeket az attribútumokat a STUDENT táblában tárolni.

Hozzon létre új táblát

Tegyük fel, hogy ugyanazon irányítószámban több diák található, és a SZERZŐTÁBLÁZAT táblázata óriási mennyiségű rekordot tartalmaz, és meg kell változtatnia az utca vagy a város nevét, akkor ezt az utcát vagy várost meg kell találni és frissíteni kell a teljes táblázatban DIÁK.

Például, ha az „El Limón” utcát „El Limón II” -re kell váltania, akkor a teljes STUDENT táblázatban meg kell keresnie az „El Limón” kifejezést, majd frissítenie kell az „El Limón II” -re.

Egy hatalmas táblában történő keresés és az egy vagy több rekord frissítése sokáig tart, így befolyásolja az adatbázis teljesítményét.

Ehelyett ezeket a részleteket külön táblában (POSTCARD) lehet tárolni, amely a POST_CODE attribútum használatával kapcsolódik a STUDENT táblához.

A POST táblának viszonylag kevesebb rekordja van, és ezt a POST táblát csak egyszer kell frissíteni. Ez automatikusan tükröződik a STUDENT táblában, egyszerűsítve az adatbázist és a lekérdezéseket. Tehát a táblák 3FN formátumban lesznek:

2. példa

Használja a következő táblázatot a Project_Num mezővel elsődleges kulcsként, és az ismételt értékekkel olyan attribútumokban, amelyek nem kulcsok.

A telefonérték megismétlődik minden alkalommal, amikor a menedzser neve megismétlődik. Ennek oka az, hogy a telefonszámnak csak egy második fokú függése van a projekt számától. Valójában először a menedzsertől függ, és ez viszont a projekt számától függ, ami tranzitív függőséget eredményez.

A Project_Manager attribútum nem lehet lehetséges kulcs a Projektek táblában, mivel ugyanaz a menedzser egynél több projektet kezel. Ennek megoldása az attribútum eltávolítása az ismételt adatokkal (telefon), külön táblázat létrehozásával.

A megfelelő attribútumokat össze kell csoportosítani, új táblát kell létrehozni a mentésükhöz. Az adatokat beírják, és ellenőrzik, hogy az ismételt értékek nem képezik-e az elsődleges kulcs részét. Az elsődleges kulcsot minden asztalhoz beállítják, és szükség esetén idegen kulcsok kerülnek hozzáadásra.

A harmadik normál forma betartásához egy új táblázatot (Menedzser) hozunk létre a probléma megoldására. Mindkét táblázat a Project_Manager mezőn keresztül kapcsolódik:

Irodalom

1. Teradata (2019). Első, második és harmadik normál forma. Felvétel: docs.teradata.com.
2. Bemutató kupa (2019). Harmadik normál forma (3NF). Forrás: tutorialcup.com.
3. Database Dev (2015). Harmadik normál forma (3NF) - az adatbázis normalizálása. Feltöltve: databasedev.co.uk.
4. Relációs DB tervezés (2019). Bevezetés a harmadik normál formába. Forrás: relationaldbdesign.com.
5. Dummies (2019). SQL első, második és harmadik normál forma. Forrás: dummies.com.