Az adatbázis normál formák (normal forms) az adatbázisok tervezési szabályait jelentik, amelyek célja az adatok redundanciájának csökkentése és az adatok integritásának biztosítása. Az 1NF-től az 5NF-ig terjedő normál formák mindegyike egyre szigorúbb feltételeket ír elő.
🔹 1. Miért fontosak a normál formák?
- Csökkentik a redundanciát (ugyanaz az adat ne ismétlődjön feleslegesen).
- Minimalizálják az anomáliákat (beszúrási, módosítási és törlési hibák).
- Biztosítják az adatok konzisztenciáját és hatékonyabb lekérdezéseket tesznek lehetővé.
💡 Fontos: A normalizálás és a denormalizálás közötti egyensúlyt mindig az adott alkalmazás teljesítményigényei és funkcionalitása alapján kell meghatározni!
🔹 2. A normál formák részletesen
1NF – Első normál forma
📌 Feltétel:
- Minden mező atomikus (oszthatatlan) kell legyen.
- Minden rekordnak egyedi azonosítója (elsődleges kulcs) kell legyen.
✅ Használata:
- Alapvető szintű normalizálás, minden relációs adatbázis legalább 1NF-ben kell legyen.
📌 Példa: Nem 1NF (mert a "Telefon" mezőben több érték is van)
| ID | Név | Telefon |
|---|---|---|
| 1 | Anna | 123-456, 789-012 |
| 2 | Béla | 555-678 |
✅ Megoldás (1NF-be hozva)
| ID | Név | Telefon |
|---|---|---|
| 1 | Anna | 123-456 |
| 1 | Anna | 789-012 |
| 2 | Béla | 555-678 |
2NF – Második normál forma
📌 Feltételek:
- Az 1NF teljesül.
- Minden nem kulcs attribútum teljes függésben van az elsődleges kulccsal (nincs részleges függőség).
🔴 Probléma, ha nincs 2NF:
Ha egy összetett elsődleges kulcs van, akkor egyes attribútumok csak annak egy részétől függenek.
📌 Példa: Nem 2NF (az "Edző neve" csak a "Csapat" mezőtől függ, nem az egész kulcstól)
| Játékos_ID | Csapat | Edző neve |
|---|---|---|
| 1 | Barca | Xavi |
| 2 | Barca | Xavi |
| 3 | Real | Ancelotti |
✅ Megoldás: Külön táblába bontjuk az edzőt
🔹 Játékosok tábla
| Játékos_ID | Csapat |
|---|---|
| 1 | Barca |
| 2 | Barca |
| 3 | Real |
🔹 Csapatok tábla
| Csapat | Edző neve |
|---|---|
| Barca | Xavi |
| Real | Ancelotti |
3NF – Harmadik normál forma
📌 Feltételek:
- A 2NF teljesül.
- Nincsenek tranzitív függőségek (egy oszlop nem függhet közvetetten a kulcstól).
📌 Példa: Nem 3NF
| ID | Név | Irányítószám | Város |
|---|---|---|---|
| 1 | Anna | 1051 | Budapest |
| 2 | Béla | 4031 | Debrecen |
🔴 Probléma: Az "Irányítószám" és a "Város" kapcsolata független az ID-tól → tranzitív függőség.
✅ Megoldás: Városokat külön táblába tesszük
🔹 Emberek tábla
| ID | Név | Irányítószám |
|---|---|---|
| 1 | Anna | 1051 |
| 2 | Béla | 4031 |
🔹 Városok tábla
| Irányítószám | Város |
|---|---|
| 1051 | Budapest |
| 4031 | Debrecen |
BCNF – Boyce-Codd normál forma
📌 Feltétel:
- A 3NF teljesül.
- Minden meghatározó attribútumnak (determinánsnak) kulcsnak kell lennie.
🔴 Probléma: Ha egy nem elsődleges kulcsmező határozza meg egy másik oszlop értékét.
📌 Példa: Nem BCNF
| Tanár | Tantárgy | Osztály |
|---|---|---|
| Kovács | Matek | 10.A |
| Kovács | Matek | 10.B |
| Tóth | Fizika | 10.A |
🔴 Itt a "Tanár" határozza meg a "Tantárgyat", de nem egyedi kulcs.
✅ Megoldás: Külön táblák létrehozása
| Tanár | Tantárgy |
|---|---|
| Kovács | Matek |
| Tóth | Fizika |
| Tantárgy | Osztály |
|---|---|
| Matek | 10.A |
| Matek | 10.B |
| Fizika | 10.A |
4NF és 5NF – Magasabb szintű normalizáció
- 4NF (Negyedik normál forma): Megszünteti a többértékű függőségeket. Ha egy táblában egy oszlop többféle független értéket tartalmazhat egy másik oszlophoz képest, azt külön táblákba kell bontani.
- 5NF (Ötödik normál forma): Kiküszöböli az összetett (összetett kulcsok által meghatározott) kapcsolódási problémákat.
💡 4NF és 5NF ritkán szükséges, főként nagy és komplex rendszereknél alkalmazzák.
🔹 3NF vs. Denormalizáció – Mikor melyiket használjuk?
✅ Amikor normalizálunk (3NF vagy BCNF):
- Az adatbázis mérete csökken.
- Az adatfrissítések egyszerűbbek és gyorsabbak.
- Jobb adatkonzisztencia.
❌ Amikor denormalizálunk:
- Gyorsabb lekérdezésekre van szükség.
- Adattárházaknál gyakran denormalizálnak (pl. OLAP rendszerek).
📌 Gyakorlati tanács:
- OLTP rendszerekben (napi használat, sok írás) → 3NF vagy BCNF
- Adattárházaknál (kimutatások, gyors lekérdezések) → Denormalizálás, dimenziós modellek
Példa
Tegyük fel, hogy egy egyetemi kurzusnyilvántartó rendszer adatbázisát tervezzük. Az adatbázis célja, hogy rögzítse a hallgatók, az általuk felvett kurzusok és az oktatók adatait.
🔹 Kiinduló táblázat (nem normalizált adatok)
Hallgató_ID Hallgató_név Kurzus Oktató Oktató_telefon Terem Időpont 1 Kovács Péter Matek 1 Dr. Nagy 123-456 A101 Hétfő 10:00 2 Szabó Anna Prog 1 Dr. Kiss 987-654 B202 Kedd 12:00 3 Kovács Péter Prog 1 Dr. Kiss 987-654 B202 Kedd 12:00 4 Tóth Ádám Matek 1 Dr. Nagy 123-456 A101 Hétfő 10:00 🔴 Problémák ezzel a struktúrával:
- Redundancia: Az oktatók és az időpontok többször szerepelnek.
- Frissítési anomália: Ha egy oktató telefonszáma változik, több sorban kell módosítani.
- Törlési anomália: Ha egyetlen kurzust törlünk, elveszíthetjük az oktató adatait is.
🔹 1NF – Első normál forma
📌 Feltételek:
- Minden mező atomikus (oszthatatlan) kell legyen.
- Nincsenek többszörös értékeket tartalmazó oszlopok.
✅ Módosított tábla (1NF-be hozva)
Hallgató_ID Hallgató_név Kurzus Oktató Oktató_telefon Terem Időpont 1 Kovács Péter Matek 1 Dr. Nagy 123-456 A101 Hétfő 10:00 2 Szabó Anna Prog 1 Dr. Kiss 987-654 B202 Kedd 12:00 3 Kovács Péter Prog 1 Dr. Kiss 987-654 B202 Kedd 12:00 4 Tóth Ádám Matek 1 Dr. Nagy 123-456 A101 Hétfő 10:00 🔹 Mi változott?
- Az oszlopok oszthatóak maradtak, de még mindig redundancia van az oktatóknál és az órarendi adatoknál.
🔹 2NF – Második normál forma
📌 Feltételek:
- Az 1NF teljesül.
- Nincsenek részleges függőségek (minden nem kulcs attribútumnak teljesen az elsődleges kulcshoz kell kapcsolódnia).
🔴 Probléma:
- Az Oktató_telefon mező csak az Oktató oszloptól függ, nem a teljes kulcstól (Hallgató_ID, Kurzus).
✅ Megoldás: Az oktatókat külön táblába bontjuk
🔹 Hallgató-Kurzus tábla (2NF)
Hallgató_ID Hallgató_név Kurzus 1 Kovács Péter Matek 1 2 Szabó Anna Prog 1 3 Kovács Péter Prog 1 4 Tóth Ádám Matek 1 🔹 Kurzus-Oktató tábla
Kurzus Oktató Matek 1 Dr. Nagy Prog 1 Dr. Kiss 🔹 Oktatók tábla
Oktató Oktató_telefon Dr. Nagy 123-456 Dr. Kiss 987-654 🔹 Kurzus-Órarend tábla
Kurzus Terem Időpont Matek 1 A101 Hétfő 10:00 Prog 1 B202 Kedd 12:00 🔹 Mi változott?
- Az oktatók és a kurzusok adatai külön táblába kerültek.
- Nincs több felesleges adatismétlés.
🔹 3NF – Harmadik normál forma
📌 Feltételek:
- A 2NF teljesül.
- Nincsenek tranzitív függőségek (egy attribútum nem függ közvetetten az elsődleges kulcstól).
🔴 Probléma:
- Az "Időpont" az "Terem" oszloptól függ, tehát tranzitív függőség van.
✅ Megoldás: A termeket külön táblába tesszük
🔹 Kurzus-Órarend tábla (3NF)
Kurzus Terem_ID Matek 1 A101 Prog 1 B202 🔹 Termek tábla
Terem_ID Időpont A101 Hétfő 10:00 B202 Kedd 12:00 🔹 Mi változott?
- Az időpontokat külön táblába helyeztük, így nem függnek közvetetten a kurzustól.
🔹 BCNF – Boyce-Codd normál forma
📌 Feltételek:
- A 3NF teljesül.
- Minden determináns (meghatározó mező) kulcs kell legyen.
🔴 Probléma:
- Egyes esetekben az "Oktató" meghatározza a "Kurzus" attribútumot, ami nem elsődleges kulcs.
✅ Megoldás: Oktató-Kurzus kapcsolat külön táblába kerül
🔹 Kurzusok
Kurzus_ID Kurzus 1 Matek 1 2 Prog 1 🔹 Oktató-Kurzus tábla (BCNF)
Oktató Kurzus_ID Dr. Nagy 1 Dr. Kiss 2 Összegzés
Normál forma Fő célja 1NF Atomikus adatmezők 2NF Részleges függőségek eltávolítása 3NF Tranzitív függőségek eltávolítása BCNF Minden meghatározó kulcs kell legyen 💡 Tipikus gyakorlat:
- OLTP rendszerekben (pl. CRM, ERP) 3NF vagy BCNF ajánlott.
- Adattárházaknál (pl. BI rendszerek) denormalizálás hasznos lehet.
Megjegyzések
Megjegyzés küldése