Adatbázis tervezése

Adatbázis

Normalizálás, adatbázis tervezése

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

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:

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:

• 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:

• 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:

• 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:

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):

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

• 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):

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.