Ebben a feladatban most fordítva készítünk el egy táblát, ami jobban hasonlít a valósághoz. Az igény van meg, kell egy nyilvántartás a webshop vásárlóiról, ehhez keresünk adatokat és hozunk létre kapcsolatokat 1 NF-3NF-ig. 

1NF - Első normál forma

Adatok: Vevőkód (kulcs), vevőnév, irányítószám, megye, település, utca

Első normál formában van, az adatok táblázatos szerkezetűek és atomiak. Minden mező egy értéket tartalmaz. 

 A vevőre így az elképzelt táblánk: 

2NF - Második normál forma

• A vevőkód meghatározza az összes adatot.
• Probléma: az irányítószám tranzitív függőségben van a megye és település adatokkal.
• Megoldás: Külön táblába helyezzük az irányítószámot, megyét és települést.

3NF - Harmadik normál forma

A tranzitív függőségek megszüntetése után a vevőkód közvetlenül meghatározza az összes adatot a vevő táblában.

Vevő tábla:

Mező neve	Adattípus	Leírás
Vevőkód	Rövid szöveg	Egyedi azonosító (kulcs).
Vevőnév	Rövid szöveg	A vevő teljes neve.
Irányítószám	Rövid szöveg	Kapcsolat a régió táblával.
Vevőcím	Rövid szöveg	Számlázási cím.

Régió tábla:

 

Mező neve	Adattípus	Leírás
Irányítószám	Rövid szöveg	Egyedi azonosító (kulcs).
Település	Rövid szöveg	Város vagy község neve.
Megye	Rövid szöveg	Az adott régió megyéje.

 Áruk adatai: Árukód (kulcs), árunév, bruttó ár, kategórianév

Az árucikkeket is 1NF formára kell hozni, nem lehet pl egy sorban több termék. 

2NF - Második normál forma
A kategórianév tranzitív függőségben van az árukóddal. A kategórianév meghatározható lenne egy új kategóriatáblából.
Megoldás: a kategóriákat külön táblába helyezzük.

3NF - Harmadik normál forma
A tranzitív függőségek megszüntetése után minden attribútum közvetlenül függ az árukódtól

Áru tábla:

Mező neve	Adattípus	Leírás
Árukód	Rövid szöveg	Egyedi azonosító (kulcs).
Árunév	Rövid szöveg	Az áru megnevezése.
Bruttó ár	Szám	Az áru ára.
Kategóriakód	Rövid szöveg	Kapcsolat a kategória táblával.

Kategória tábla:

Mező neve	Adattípus	Leírás
Kategóriakód	Rövid szöveg	Egyedi azonosító (kulcs).
Kategórianév	Rövid szöveg	A kategória neve.

Számla és kapcsolódó adatok
Számlaszám (kulcs) vevőkód, vásárlás dátuma

1NF - Első normál forma
Az adatok táblázatos szerkezetőek és atomi értékűek

2NF - Második normál forma
A vevőkód közvetlenül meghatározza a vevők adatait, tehát nincs részletes függőség

3NF - Harmadik normál forma
Az összes adat közvetlenül függ a számlaszámtól, nincs tranzitív függőség

 

Számla tábla:

Mező neve	Adattípus	Leírás
Számlaszám	Számláló	Egyedi azonosító (kulcs).
Vevőkód	Rövid szöveg	Kapcsolat a vevő táblával.
Vásárlás dátuma	Dátum/idő	A vásárlás időpontja.

Számlarészletező tábla:

Mező neve	Adattípus	Leírás
Számlaszám	Számláló	Kapcsolat a számla táblával.
Árukód	Rövid szöveg	Kapcsolat az áru táblával.
Vásárolt mennyiség	Szám	Az adott termék darabszáma.

A számlarészletező táblában szükség lesz összetett kulcsra. Az összetett kulcs olyan táblákban fordul elő, amelyek más táblák közti kapcsolatokat kezelnek. A számlarészletező táblában a számlaszám és az árukód kombinációja azonosítja az egyes sorokat. Ez a tábla rögzíti a számlán szereplő termékeket és azok mennyiségét. Egy számlán többféle termék is szerepelhet és egy termék több számlához is tartozhat. Ez az összetett kulcs biztosítja az egyedi azonosítást. 

Táblázat szerkezete:

Mező neve	Adattípus	Leírás
Számlaszám	Számláló	A számlát azonosítja (idegen kulcs).
Árukód	Rövid szöveg	A terméket azonosítja (idegen kulcs).
Vásárolt mennyiség	Szám	Az adott termék darabszáma.

Kapcsolatok az adatbázisban

Kapcsolat	Kapcsolat típusa	Kulcsok
Vevő → Régió	Egy-a-többhöz	Irányítószám
Számla → Vevő	Egy-a-többhöz	Vevőkód
Számla → Számla részletező	Egy-a-többhöz	Számlaszám
Számla részletező → Áru	Egy-a-többhöz	Árukód
Áru → Kategória	Egy-a-többhöz	Kategóriakód

Érdekességek a táblázatok szerkesztésénél Accessben:

Irányítószám: 
Tehetem rövid szöveg adattípusba, mert nem fogok vele számolni
Mezőméret: 4, mert az irányítószám 4 karakteres
Beviteli mező: 0000, mert ilyen formában várom a megjelenítését
Érvényességi szabály: >=1000
Érvényesítási szöveg: Nem megfelelő adatforma (ezt írja ki, ha az irányítószámot rossz formában adom meg)

Ha eladókkal dolgozok, akik jutalékot kapnak pl egy meghatározott eladás után, ide a vevőtáblázatba felvihetem őket is. Létrehozhatok egy listát, melyből ki lehet válaszani az adott eladót. Ezt az adatot Keresés varázslóval hozom létre:

Egy mappában létre lehet hozni (akár több oszlopban is) az adatokat:

Tovább gombbal véglegesíthetjük az eladók listáját, így ha nézetet váltunk, akkor egy legördülő mezőből kiválaszthatjuk az eladókat a táblázat kitöltésénél. 

A számlarészletezőnél összetett kulcsot adunk meg. Itt mind a két mezőt ki kell jelölnünk, az indexelés pedig igen (lehet azonos).

Végül állítsuk be Accessben a kapcsolatokat: 

Az alábbi adatokból állítunk össze egy adatbázist:
rendszám, szín, név, lakcím, évjárat, érték, személyi szám, típus, 

Célunk az, hogy az adatok redundanciáját minimalizáljuk, miközben biztosítjuk az adatbázis hatékony és logikus működését. A folyamatot az 1NF-től egészen a 3NF-ig és a BCNF-ig vezetjük végig.

1NF (Első normál forma)

Az 1NF követelményei:

• Minden mezőnek atomi (oszthatatlan) értékeket kell tartalmaznia.
• Minden sor egyedi.
• Az adatok táblázatos szerkezetben vannak.

Elemzés:

• A tábla már táblázatos formátumú, és minden mező atomi értéket tartalmaz.
• Probléma: az adatok redundanciát tartalmaznak, például "Kovács P." kétszer szerepel ugyanazzal a lakcímmel és személyi számmal.

Eredmény:

Az 1NF biztosítja, hogy az adatok oszthatatlan értékek formájában jelenjenek meg, de még mindig tartalmaz redundanciát, amelyet további normalizálással kell csökkenteni.

 

2NF (Második normál forma)

A 2NF követelményei:

• Az 1NF-ben van.
• Minden nem kulcs attribútumnak teljesen függenie kell az elsődleges kulcstól (nincs részleges függőség).

Elemzés:

• Kulcs azonosítása: Az autókhoz kapcsolódó adatok (pl. rendszám, szín, évjárat, érték) az rendszám attribútumtól függnek.
• A tulajdonosokhoz kapcsolódó adatok (pl. név, lakcím, személyi szám) az személyi szám attribútumtól függenek.

A redundancia csökkentéséhez két táblát hozunk létre:

1. Autók tábla: Az autók adatai + a tulajdonos azonosítója (személyi szám) idegen kulcsként.
2. Tulajdonosok tábla: A tulajdonosok adatai, ahol a személyi szám az elsődleges kulcs.

Normalizáld az alábbi relációt:
SZAKÁCS(név, születési év, ételkód, ételnév, adag, cím, fajtakód, fajtanév)

Az 1NF (Első Normál Forma) biztosítja, hogy:

1. Az oszlopok értékei atomiak, azaz minden mező csak egyetlen értéket tartalmaz (nincs többértékű attribútum, például egyetlen cellában nem szerepel több ételkód vagy cím).
2. Minden sorban az oszlopok száma és sorrendje konzisztens.

A jelenlegi relációban (SZAKÁCS):

• "név", "születési év", "ételkód", "ételnév", "adag", "cím", "fajtakód", "fajtanév" mezők vannak.
• A reláció megfelel az 1NF követelményeinek, mivel minden attribútum atomi, és nincs többértékű érték egy mezőben.

Második Normál Forma (2NF)

A 2NF követelményei:

1. Az előfeltétel az, hogy a reláció már 1NF-ben van.
2. Minden nem kulcs attribútum teljesen funkcionálisan függ az elsődleges kulcstól, azaz:
   • Egyik nem kulcs attribútum sem függhet az elsődleges kulcs egy részétől (ez a részleges függőség kiküszöbölése).

Elemzés a példára (SZAKÁCS táblázat):

A reláció elsődleges kulcsa: (név, ételkód)

Függőségek az adatok alapján:

1. Név → születési év, cím
   Ez azt jelenti, hogy egy szakács neve alapján egyértelműen meghatározható a születési év és a cím. Ezek nem függnek az ételkódtól.
2. Ételkód → ételnév, fajtakód, fajtanév
   Ez azt jelenti, hogy az ételkódhoz kapcsolódik az étel neve, illetve az ételhez tartozó fajtakód és fajtanév. Ezek sem függnek a szakács nevétől.
3. (Név + Ételkód) → adag
   Ez az egyetlen olyan attribútum, amely teljesen függ az elsődleges kulcstól (a név és az ételkód együtt).

A táblázat részleges függőségei:

• Név → születési év, cím: részleges függőség, mert csak a kulcs egyik része (név) határozza meg az attribútumokat.
• Ételkód → ételnév, fajtakód, fajtanév: részleges függőség, mert csak a kulcs egyik része (ételkód) határozza meg az attribútumokat.

Megoldás: 2NF normalizálás

A részleges függőségek megszüntetése érdekében szétbontjuk a relációt három táblára:

1. SZAKÁCS(név, születési év, cím)
   • Tartalmazza a szakácsokkal kapcsolatos attribútumokat, amelyeket a "név" egyértelműen meghatároz.
2. ÉTEL(ételkód, ételnév, fajtakód, fajtanév)
   • Tartalmazza az ételekhez kapcsolódó adatokat, amelyeket az "ételkód" egyértelműen meghatároz.
3. KÉSZÍT(név, ételkód, adag)
   • Kapcsoló tábla, amely a szakácsok és az általuk készített ételek kapcsolatát tárolja, valamint az ehhez tartozó adagot.

Eredmény (2NF-ben):

1. SZAKÁCS tábla:
   

   Név	Születési év	Cím
   Kovács Anna	1985	Budapest
   Nagy Péter	1990	Debrecen

2. ÉTEL tábla:
   

   Ételkód	Ételnév	Fajtakód	Fajtanév
   101	Gulyás	1	Leves
   102	Túrógombóc	2	Desszert

3. KÉSZÍT tábla:
   

   Név	Ételkód	Adag
   Kovács Anna	101	50
   Nagy Péter	102	30

Összegzés:

A 2NF elérése során megszüntettük a részleges függőségeket:

• A szakácsokkal kapcsolatos attribútumok egy külön táblába kerültek.
• Az ételekhez kapcsolódó attribútumok szintén egy külön táblába kerültek.
• A szakácsok és az ételek közötti kapcsolatot egy harmadik, kapcsoló tábla rögzíti.

Harmadik Normál Forma (3NF)

A 3NF feltételei:

1. Az előfeltétel az, hogy a reláció már 2NF-ben van.
2. Egy reláció akkor van 3NF-ben, ha:
   • Minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ.
   • Nem lehet tranzitív függőség, vagyis egy nem kulcs attribútum nem függhet másik nem kulcs attribútumtól.

Elemzés a példára (SZAKÁCS tábla):

2NF után kapott táblák:

1. SZAKÁCS(név, születési év, cím)
2. ÉTEL(ételkód, ételnév, fajtakód, fajtanév)
3. KÉSZÍT(név, ételkód, adag)

Tranzitív függőség vizsgálata:

1. Az SZAKÁCS tábla rendben van: a "név" egyértelműen meghatározza a "születési év" és "cím" attribútumokat, nincs tranzitív függőség.
2. Az ÉTEL táblában azonban van tranzitív függőség:
   • Ételkód → fajtakód → fajtanév
     • Az "ételkód" meghatározza a "fajtakódot", és a "fajtakód" meghatározza a "fajtanév" attribútumot. Ez egy tranzitív függőség, amelyet el kell távolítani.

Megoldás: 3NF normalizálás

A tranzitív függőség megszüntetése érdekében szétbontjuk az ÉTEL táblát:

1. ÉTEL(ételkód, ételnév, fajtakód)
   • Az "ételkód" alapján meghatározható az étel neve és a fajtakód.
2. FAJTA(fajtakód, fajtanév)
   • A "fajtakód" alapján meghatározható a fajta neve.

 

 

Eredmény (3NF-ben):

1. SZAKÁCS tábla:
   

   Név	Születési év	Cím
   Kovács Anna	1985	Budapest
   Nagy Péter	1990	Debrecen

2. ÉTEL tábla:
   

   Ételkód	Ételnév	Fajtakód
   101	Gulyás	1
   102	Túrógombóc	2

3. FAJTA tábla:
   

   Fajtakód	Fajtanév
   1	Leves
   2	Desszert

4. KÉSZÍT tábla:
   

   Név	Ételkód	Adag
   Kovács Anna	101	50
   Nagy Péter	102	30

Összegzés:

• A 3NF elérése érdekében megszüntettük a tranzitív függőségeket.
• Az ÉTEL táblából eltávolítottuk a "fajtanév" attribútumot, és egy külön FAJTA táblába helyeztük.
• Most már minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ, nincs tranzitív függőség

 

Boyce-Codd Normál Forma (BCNF) és a Különbség a 3NF-hez Képest

Miért lehet szükség BCNF-re?

A BCNF szigorúbb, mint a 3NF. Egy reláció 3NF-ben lehet, de még mindig tartalmazhat olyan függőségeket, amelyek nem felelnek meg a BCNF kritériumainak.

• 3NF kritériuma: Minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ.
• BCNF kritériuma: Minden funkcionális függőség bal oldala szuperkulcs kell, hogy legyen.

Ez azt jelenti, hogy BCNF-ben nem lehet olyan funkcionális függőség, ahol a bal oldalon nem egy szuperkulcs található.

 

Elemzés a példára (SZAKÁCS tábla)

3NF után kapott táblák:

1. SZAKÁCS(név, születési év, cím)
2. ÉTEL(ételkód, ételnév, fajtakód)
3. FAJTA(fajtakód, fajtanév)
4. KÉSZÍT(név, ételkód, adag)

BCNF vizsgálat:

1. SZAKÁCS: Nincs további függőség. A "név" egyértelműen meghatározza a "születési év" és "cím" attribútumokat. Ez már BCNF-ben van.
2. ÉTEL: Nincs további függőség. Az "ételkód" szuperkulcs, és minden attribútum tőle függ. Ez is BCNF-ben van.
3. FAJTA: Nincs további függőség. A "fajtakód" szuperkulcs, és meghatározza a "fajtanév" attribútumot. Ez BCNF-ben van.
4. KÉSZÍT: Vizsgáljuk meg az esetleges függőségeket.

 

BCNF probléma a KÉSZÍT táblában

A KÉSZÍT(név, ételkód, adag) tábla tartalma:

Név	Ételkód	Adag
Kovács Anna	101	50
Kovács Anna	102	30
Nagy Péter	101	20
Nagy Péter	102	40

Funkcionális függőségek:

1. (Név, Ételkód) → Adag (minden kombináció meghatározza az adagszámot).
2. Nincs olyan további függőség, amely sértené a BCNF-et, mert:
   • A "Név" és "Ételkód" páros szuperkulcs, és minden attribútum kizárólag ettől függ.

Eredmény (BCNF-ben):

A 3NF után a táblák már teljesítik a BCNF kritériumait is, mert:

• Minden funkcionális függőség bal oldala szuperkulcs.
• Nincs olyan további függőség, amely felbontást igényelne.

 

Normalizálás

A normalizálás az adatbázis tervezésének egyik kulcsfontosságú folyamata, amelynek célja az adatok redundanciájának minimalizálása és az adatstruktúra logikai átláthatóságának növelése. A folyamat során az adatokat kisebb, egymással összefüggő táblázatokra bontjuk, miközben biztosítjuk, hogy az adatok közötti kapcsolatok egyértelműek és konzisztens módon kezelhetők legyenek.

Normalizálás definíciója (magyarázattal):

A normalizálás egy táblázatbontó relációs művelet, amely során:

• Az adatok szervezése oly módon történik, hogy az ismétlődő vagy redundáns adatokat eltávolítjuk.
• Az adatbázisban tárolt információk strukturáltan, egymással logikailag összefüggő módon helyezkednek el.
• Minden tárolt adat egyértelműen kapcsolódik egy elsődleges kulcshoz.

Miért fontos a normalizálás?

• Csökkenti a tárolási igényt: Az adatok redundanciájának megszüntetésével kevesebb helyet foglalnak az adatbázisban.
• Megszünteti az anomáliákat: A módosítási, beszúrási vagy törlési műveletek során fellépő hibalehetőségeket minimalizálja.
• Átláthatóságot biztosít: A jól normalizált adatbázis könnyen kezelhető, módosítható és bővíthető.

A relációs adatbázisok és az 1NF követelménye:

Minden relációs adatbázis-kezelő rendszer alapfeltétele az 1. normál forma teljesítése. Ez biztosítja, hogy az adatbázis alapvető struktúrája megfeleljen az adatok hatékony és konzisztens kezelésének.

Normalizálás alapvetések

A normalizálás célja az adatbázis szerkezetének optimalizálása, amely során megszüntetjük a redundáns adatokat, elkerüljük az anomáliákat, és biztosítjuk az adatok konzisztens szervezését. Lássuk részletesen, mit jelent mindez, és hogyan kapcsolódnak hozzá a funkcionális függőségek.

Mi az a redundancia és miért kerülendő?

A redundancia többszörös, felesleges adattárolást jelent. Ez az alábbi problémákat eredményezheti:

• Felesleges helyfoglalás: Az ismétlődő adatok növelik az adatbázis méretét.
• Anomáliák keletkezése:
  • Módosítási anomália: Egy adat módosításakor az ismétlődő példányokat is frissíteni kell; ennek elmulasztása ellentmondásokat okozhat.
  • Beszúrási anomália: Bizonyos attribútumok hiánya akadályozhatja új adatok beszúrását.
  • Törlési anomália: Egy rekord törlése olyan adatokat is eltávolíthat, amelyekre még szükség lenne.

Az adatbázis konzisztenciájának fontossága

Az adatbázis akkor konzisztens, ha csak egymással logikailag összefüggő, valós adatokat tartalmaz. A redundancia és az anomáliák azonban az adatok inkonzisztenciájához vezethetnek, amelyeket a normalizálással előzhetünk meg.

Funkcionális függőség: A normalizálás alapja

A funkcionális függőség az attribútumok közötti logikai kapcsolatot írja le. Ha egy attribútum (X) értéke meghatározza egy másik attribútum (Y) értékét, azt mondjuk, hogy Y funkcionálisan függ X-től.

Példa:

• Egy alkalmazotti nyilvántartásban az "azonosító" meghatározza a "név" attribútumot. Ez azt jelenti, hogy az azonosítóból egyértelműen levezethető a név.

Főbb tulajdonságok:

• X → Y igaz, de ebből nem következik, hogy Y → X.
• Ha K egy kulcs a relációban, akkor K funkcionálisan meghatározza az összes attribútumot a relációban.

A funkcionális függőségek következményei: Armstrong-axiómák részletesen

Az Armstrong-axiómák a funkcionális függőségek alapvető következtetési szabályai, amelyek segítenek új függőségeket levezetni meglévő függőségek alapján. Ezek az axiómák biztosítják, hogy az adatbázis logikai szerkezete helyesen legyen meghatározva.

1. Reflexivitás

Ha Y egy részhalmaza X-nek, akkor X → Y igaz.

• Magyarázat: Ha egy attribútumhalmaz már tartalmaz egy másik attribútumot vagy annak halmazát, akkor az egyértelműen levezethető.
• Példa:
  • X = {azonosító, név, születési év}
  • Y = {név, születési év} (részhalmaz)
  • Következmény: {azonosító, név, születési év} → {név, születési év}

2. Bővítés (Augmentáció)

Ha X → Y, akkor tetszőleges Z attribútumhalmaz hozzáadása után XZ → YZ is igaz.

• Magyarázat: Ha egy halmaz már meghatároz egy másik halmazt, akkor a közös kiegészítésük is meghatározó lesz.
• Példa:
  • X = {azonosító}, Y = {név}, ahol azonosító → név
  • Z = {beosztás}
  • Következmény: {azonosító, beosztás} → {név, beosztás}

3. Tranzitivitás

Ha X → Y és Y → Z, akkor X → Z is igaz.

• Magyarázat: Ha az egyik attribútumhalmazból levezethetünk egy másikat, és abból további attribútumokat, akkor az elsőből közvetlenül levezethető a harmadik.
• Példa:
  • X = {azonosító}, Y = {név}, Z = {osztály}
  • Ha azonosító → név és név → osztály, akkor azonosító → osztály is igaz.

4. Szétvágási szabály

Ha X → YZ, akkor X → Y és X → Z is igaz.

• Magyarázat: Ha egy halmaz meghatározza két attribútum együttes értékét, akkor ezek külön-külön is levezethetők.
• Példa:
  • X = {azonosító}, YZ = {név, beosztás}
  • Ha azonosító → {név, beosztás}, akkor:
    • azonosító → név
    • azonosító → beosztás

5. Egyesítési szabály

Ha X → Y és X → Z, akkor X → YZ is igaz.

• Magyarázat: Ha egy attribútumhalmaz külön-külön meghatározza két másik halmaz értékét, akkor azok együtt is levezethetők.
• Példa:
  • X = {azonosító}, Y = {név}, Z = {beosztás}
  • Ha azonosító → név és azonosító → beosztás, akkor:
    • azonosító → {név, beosztás}

6. Pseudotranzitivitás

Ha X → Y és WY → Z, akkor WX → Z is igaz.

• Magyarázat: Ha egy attribútumhalmazból (X) egy másik attribútumhalmazt (Y) levezethetünk, és egy harmadik halmaz (W) ezt kiegészítve levezet egy további attribútumot (Z), akkor az első kettő együtt is meghatározó.
• Példa:
  • X = {azonosító}, Y = {beosztás}, W = {név}, Z = {osztály}
  • Ha azonosító → beosztás és {név, beosztás} → osztály, akkor:
    • {azonosító, név} → osztály

Az Armstrong-axiómák biztosítják az attribútumok közötti kapcsolatok pontos meghatározását és logikai következményeinek levezetését. Ezek a szabályok segítenek az adatbázis helyes tervezésében és a funkcionális függőségek megfelelő kezelésében.

A normalizálás folyamata

0NF, UNF vagy 0. Normál forma

Ez a normalizálatlan relációs séma. Vesszük az összes mezőt, melyet az adatbázisnak tartalmaznia kell. Leírjuk egy nagy táblázatba, ahol minden szükséges mező szerepel, de még nem teljesíti a relációs modell követelményeit, például:
- többértékű attribútumot tartalmaz
- beágyazott táblázatot tartalmaz
- nincs elsődleges kulcsa

Név	Szak	Hobbi
Kék Ibolya	Informatika	Olvasás, Zene

1NF vagy első normálforma 

- az oszlopok szám és sorrendje minden sorban azonos
- minden oszlop csak meghatározott értéket vehet fel az attribútum értéktartományból
- minden mező csak egy értéket vehet fel
- nincs összetett attribútum
- nincs beágyazott reláció (olyan tulajdonság, melynek értéke nem atomi)
- minden sorhoz egy egyedi kulcs tartozik, amitől az összes többi mező funkcionálisan függ (nincs két egyforma sor)

A hobbit külön sorokba bontjuk:

Név	Szak	Hobbi
Kék Ibolya	Informatika	Olvasás
Kék Ibolya	Informatika	Zene

2NF - második normálforma

1NF-ben van (előfeltétel) ÉS a nem kulcs attribútumok funkcionálisan függnek az elsődleges kulcstól. Megszünteti a részleges függőségeket, amelyek akkor fordulnak elő, ha egy nem kulcs attribútum csak a kulcs egy részétől függ.

 

Teljes funkcionális függőség

Egy attribútum teljes mértékben egy másik attribútumhalmaztól függ, azaz az adott attribútumot nem lehet meghatározni a kulcs egyetlen részhalmazából. Minden nem kulcs attribútum kizárólag a teljes elsődleges kulcstól függ.

Példa: Egy adatbázis, amely egyetemek kurzusainak részleteit tárolja:

Kurzus ID	Hallgató ID	Jegy
101	201	5
101	202	4
102	201	3

• Elsődleges kulcs: {Kurzus ID, Hallgató ID}
• Jegy attribútum teljes funkcionális függőségben van a {Kurzus ID, Hallgató ID} kulccsal. Ez azt jelenti, hogy a Jegy értéke csak a teljes kulcs (Kurzus ID és Hallgató ID) alapján egyértelműen meghatározható.

Miért teljes függőség?

• Ha csak a Kurzus ID van megadva, nem tudjuk, melyik hallgató jegyéről van szó.
• Ha csak a Hallgató ID van megadva, nem tudjuk, melyik kurzus jegyéről van szó.
• Csak a {Kurzus ID, Hallgató ID} együttes megléte adja meg a Jegy értékét.

Részleges funkcionális függőség

Egy attribútum csak a kulcs egy részétől függ, nem pedig a teljes kulcstól. Ez redundanciát okozhat, és ellentmond az 2NF követelményeinek.

Példa: Egy adatbázis, amely tanárok által tartott kurzusokat tárolja:

Kurzus ID	Tanárok ID	Kurzus neve	Tanár neve
101	T1	Matematika	Kovács Béla
102	T2	Fizika	Nagy Anna

• Elsődleges kulcs: {Kurzus ID, Tanárok ID}
• Kurzus neve attribútum teljes funkcionális függőségben van a Kurzus ID-tól.
• Tanár neve attribútum részleges funkcionális függőségben van, mert csak a Tanárok ID-tól függ, nem a teljes kulcstól.

Miért részleges függőség?

• A Tanár neve attribútumot meg tudjuk határozni csak a Tanárok ID alapján, függetlenül a teljes kulcstól.

Átalakítás 2NF-re:

1. Hozzunk létre külön táblát a tanároknak:

   Tanárok ID	Tanár neve
   T1	Kovács Béla
   T2	Nagy Anna

2. Az eredeti táblát átalakítjuk:

   Kurzus ID	Kurzus neve	Tanárok ID
   101	Matematika	T1
   102	Fizika	T2

Összegzés

1. Teljes funkcionális függőség:

   • Az attribútum a teljes elsődleges kulcstól függ.
   • Nincs redundancia vagy részleges kapcsolat.
   • Példa: Egy kurzuson belüli jegyek, amelyek a kurzus és hallgató kombinációjától függnek.

2. Részleges funkcionális függőség:

   • Az attribútum csak a kulcs egy részétől függ.
   • Redundanciát okoz, amelyet külön táblázatokba helyezéssel szüntethetünk meg.
   • Példa: Tanárok neve, amely csak a tanár azonosítójától függ, nem a teljes kulcstól.

3NF - harmadik normálforma

A 3NF célja, hogy eltávolítsa a tranzitív függőségeket az adatbázisból. Egy tábla akkor van 3NF-ben, ha:

1. 2NF-ben van, és
2. Nincs olyan nem elsődleges attribútum, amely tranzitív (közvetett) módon függ az elsődleges kulcstól.

Tranzitív funkcionális függőség:

Egy X → Z függőség tranzitív, ha létezik olyan Y attribútumhalmaz, amelyre:

• X → Y és
• Y → Z is teljesül.

👉 Példa tranzitív függőségre:

Dolgozó ID (Szsz)	Osztályszám (Oszám)	Főnök neve
1	101	Kovács Béla
2	101	Kovács Béla
3	102	Nagy Anna

• X → Y: Dolgozó ID → Osztályszám (egy dolgozó csak egy osztályhoz tartozik).
• Y → Z: Osztályszám → Főnök neve (egy osztályhoz egy főnök tartozik).
• X → Z (tranzitív): Dolgozó ID → Főnök neve (közvetett függőség).

Probléma: Ha a főnök neve megváltozik, az adatot több helyen kell módosítani, ami redundanciát okoz.

 

3NF-re normalizálás

1. Bontás külön táblákra:

   • Hozzunk létre egy külön Osztályok táblát, amelyben tároljuk az osztályok azonosítóját és a hozzájuk tartozó főnök nevét.
   • Az eredeti táblában csak a Dolgozó ID és az Osztályszám marad.

2. Átalakított táblák:

   • Dolgozók tábla:

     Dolgozó ID (Szsz)	Osztályszám (Oszám)
     1	101
     2	101
     3	102

   • Osztályok tábla:

     Osztályszám (Oszám)	Főnök neve
     101	Kovács Béla
     102	Nagy Anna

Miért fontos a 3NF?

• Redundancia megszüntetése: Az adatok csak egyszer kerülnek tárolásra, így csökken a redundancia.
• Egyszerűbb adatkezelés: Ha egy adat megváltozik (pl. egy osztály főnöke), csak egy helyen kell módosítani.
• Karbantartás megkönnyítése: A tranzitív függőségek eltávolításával kevesebb adatkonfliktus és inkonzisztencia lép fel.
  A Harmadik normál forma (3NF) célja, hogy az adatbázist tovább optimalizálja azáltal, hogy megszünteti a tranzitív függőségeket. Ezáltal az adatok még strukturáltabbak, könnyebben kezelhetők és karbantarthatók lesznek.
  

Egyéb normálformák

Boyce-Codd normál forma (BCNF)

Definíció:
Egy reláció sémája BCNF-ben van, ha minden X → Y funkcionális függőség esetén X szuperkulcs. Ez azt jelenti, hogy X attribútumainak egyedi módon kell azonosítaniuk az adott reláció összes sorát.
A Boyce-Codd normál forma (BCNF) egy szigorúbb változata a harmadik normál formának (3NF). A különbség lényege, hogy a BCNF kizárja azokat a funkcionális függőségeket is, amelyeket a 3NF megenged, ha azok nem kulcs attribútumokat érintenek.

• A 3NF lehetővé teszi, hogy egy nem kulcs attribútum függjön egy másik nem kulcs attribútumtól, ha ez nem sérti a tranzitív függőségek szabályait.
• A BCNF ezt a megengedést szünteti meg: minden attribútum függősége esetén a függőség bal oldala (determináns) szuperkulcs kell, hogy legyen.

   

  BCNF és 3NF közötti különbség

  1. 3NF: Egy reláció 3NF-ben van, ha:

     • Minden funkcionális függőség esetén legalább az egyik oldal kulcsjelölt.
     • Megengedett, hogy nem kulcs attribútum függjön más nem kulcs attribútumtól (tranzitív függőség), ha a tranzitív függőség nem sérti az adatbázis integritását.

  2. BCNF: Egy reláció BCNF-ben van, ha:

     • Minden funkcionális függőség bal oldala (a determináns) szuperkulcs. Ez azt jelenti, hogy a bal oldali attribútumok egyedileg azonosítják a teljes relációt.

👉 Példa:

Tanár	Tantárgy	Tanári szoba
Kiss Anna	Matematika	101
Kovács Béla	Fizika	102
Kiss Anna	Informatika	101

Függőségek a táblában:

1. Tanár → Tanári szoba
   • Egy tanárhoz mindig ugyanaz a tanári szoba tartozik.
2. Tanár, Tantárgy → Tanári szoba
   • Egy tanár és a tantárgy együttesen meghatározza a tanári szobát.

3NF

• Egy reláció 3NF-ben van, ha:
  1. Minden attribútum közvetlenül az elsődleges kulcstól függ.
  2. Nincs tranzitív függőség a nem kulcs attribútumok között.

3NF alkalmazása a példánkra:

• Az elsődleges kulcs: Tanár, Tantárgy
• A függőségek:
  • Tanár → Tanári szoba → Ez nem sérti a 3NF-et, mert a "Tanár" attribútum lehet nem kulcs attribútum is, ha ez az adatbázis szervezését nem bonyolítja vagy nem vezet redundanciához.

A táblázat tehát 3NF-ben van.

 

BCNF

• Egy reláció BCNF-ben van, ha:
  1. Minden függőség bal oldala szuperkulcs.

Mi a probléma BCNF szempontjából?

• A függőség: Tanár → Tanári szoba → Itt a bal oldali attribútum (Tanár) nem szuperkulcs (mert nem azonosítja egyedileg a táblázat sorait).
• Emiatt a tábla nincs BCNF-ben, mert "Tanár" nem az elsődleges kulcs része.

---

BCNF normalizálása

A táblát két részre kell bontani, hogy minden függőség bal oldala szuperkulcs legyen:

1. Első tábla (Tanár és Tanári szoba kapcsolata):

Tanár	Tanári szoba
Kiss Anna	101
Kovács Béla	102

2. Második tábla (Tantárgy és Tanár kapcsolata):

Tanár	Tantárgy
Kiss Anna	Matematika
Kovács Béla	Fizika
Kiss Anna	Informatika

• 3NF-ben maradhat egy olyan függőség, ahol a bal oldali attribútum nem szuperkulcs, ha ez nem okoz redundanciát vagy adatvesztést.
• BCNF-ben minden függőség bal oldalának szuperkulcsnak kell lennie, ami azt jelenti, hogy minden bal oldali attribútumnak egyedileg azonosítania kell a táblázat minden sorát.

4NF - negyedik normál forma

Definíció:

Egy reláció sémája 4NF-ben van, ha:

• Minden X → Y többrétű függőség esetén X szuperkulcs.
• Többrétű függőség: Egy X attribútum több, egymástól független Y és Z attribútumhoz kapcsolódik.

👉 Példa:

• Adattábla (Diákok):

Diák neve	Nyelv	Sport
Anna	Angol	Kosárlabda
Anna	Német	Kosárlabda
Anna	Angol	Röplabda
Anna	Német	Röplabda

Függőségek:

1. Diák neve → Nyelv
2. Diák neve → Sport

Probléma:
A táblázatban redundancia lép fel, mert a "Nyelv" és a "Sport" független egymástól.

Megoldás (4NF-re normalizálás):

1. Tábla 1: Diák neve → Nyelv

   Diák neve	Nyelv
   Anna	Angol
   Anna	Német

2. Tábla 2: Diák neve → Sport

   Diák neve	Sport
   Anna	Kosárlabda
   Anna	Röplabda

5NF - ötödik normál forma

Definíció:
Egy reláció sémája 5NF-ben van, ha nincs nem-triviális összekapcsolási függőség. Ez azt jelenti, hogy a táblák kapcsolatai nem bonthatók fel további táblákra anélkül, hogy információt veszítenénk.

👉 Példa:

• Munkatárs	Projekt	Szerep
  Anna	A	Tervező
  Anna	B	Fejlesztő
  Bence	A	Fejlesztő
  Bence	B	Tesztelő

  
  Probléma:

  Az adatok redundánsak, és nincs biztosítva, hogy az "Anna" és "Bence" kapcsolatai a projektekhez és a szerepekhez helyesek maradjanak, ha új adatot vezetünk be. Ha például Anna egy új projektben "Tervező" szerepet kap, a redundancia miatt több sor is frissítésre szorul.

  ---

  
  5NF Normalizálása

  Az 5NF célja: Az összekapcsolási függőségeket úgy bontja szét, hogy minden reláció információvesztés nélkül helyreállítható legyen.

   

  1. Táblázat: Munkatárs → Projekt

  Munkatárs	Projekt
  Anna	A
  Anna	B
  Bence	A
  Bence	B

  
  2. Táblázat: Projekt → Szerep

  Projekt	Szerep
  A	Tervező
  A	Fejlesztő
  B	Fejlesztő
  B	Tesztelő

  
  3. Táblázat: Munkatárs → Szerep

   

  Munkatárs	Szerep
  Anna	Tervező
  Anna	Fejlesztő
  Bence	Fejlesztő
  Bence	Tesztelő

• 6NF - Hatodik normál forma 

  Definíció:
  Elméleti normál forma, amely a relációkat teljes mértékben dekomponálja időbeli függőségek kezelésére. Gyakorlatban ritkán alkalmazzák.