Normalizáció

1. Normalizáció A normalizáció egy táblázatszétbontó eljárás, mely ebből adódóan a relációs adatmodell kialakításában van segítségünkre. Hogy miért van erre szükség? Remélem ez hamarosan mindenki számára egyértelmű lesz! T.R.

2. Amikor még csak egy táblázatunk van Atáblázatkezelés rohamos terjedésével egyre többen vannak azok a felhasználók, akik az adatokat táblázatos formában el tudják képzelni, azaz egy egyszerű, egyetlen táblázatból álló relációs (=táblázatos) adatbázist könnyen elképzelnek. Tegyük fel, hogy egy adatbázisban a dolgozók azonosítóit, neveit, címüket, foglalkozásukat, fizetésüket szeretnénk nyilván tartani. Sokak fejében hamar összeáll a következő oldalon látható táblázat >>>

3. Miért előnyös több, egymással kapcsolatban lévő táblázatból felépíteni az adatbázist? A táblázat adatit jól megfigyelve fölösleges ismétlődéseketun. redundanciát figyelhetünk meg. A pék szó a maga78 000-es fizetésével többször is előfordul. A redundancianemcsak fölösleges adattárolást eredményez, hanemmódosítási, bővítési, törlési anomáliát is okozhat!

4. Módosítási anomália:Pék dolgozóink bérének 86 000-re való emelésekor a táblázatbantöbb (jelen esetben 3*) helyen kell módosítani az adatértékeket. * nagyobb adatbázisoknál ez a szám jóval nagyobb is lehetne. Az ideális eset az, ha az adatbázisok frissítését egyetlen egy módosítással el lehetne érni.

5. Bővítési anomália:Egy új foglalkozás felvételekor (pl. Kukta 70 000-es fizetéssel) a többi mező mindaddig üresen maradna, amíg egy ilyen dolgozót fel nem veszünk. Ezt bővítési anomáliának nevezzük. Példánkban az azonosító oszlop töltené be az elsődleges kulcs szerepét. Az adatbáziskezelő rendszerek nem is engedik meg az elsődleges kulcs mező üresen hagyását!

6. Törlési anomália:C. Icus kilépésével, sorának törlésével, olyan fontos adatok is vesznének, minthogy a Konyhalányok fizetése 83 000. A konyhalányoknak mennyit szoktunk fizetni???

7. A megoldás:1 táblázat helyett 2, egymással kapcsolatban lévő táblázat létrehozása. Ideiglenes kulcs Egyszerű elsődleges kulcsok Az anomáliát megszüntetni nem lehet, de minimálissá tettük!

8. Egy táblázat szétbontását több, egymással kapcsolatban álló kis táblázatra józan ésszel is el lehet végezni, de van rá tudományos módszer is ez a normalizáció (jegyezzük meg, vannak akik nem nevezik táblázat szétbontó eljárásnak a normalizációt, csupán az EER-modell minőségének ellenőrzésére szolgáló módszert látnak benne). Normálformák A normalizáció során un. normálformákon kell keresztül vezetnünk a kiinduló relációnkat. Az adatbázis normáltságának 3 (esetleg 4) foka van: - első normálforma - második normálforma - harmadik normálforma - (negyedik normálforma - nem foglalkozunk vele) Ismerjük meg a normálformákat egy példán keresztül!

9. PéldaKészítsünk nyilvántartó programot egy kis könyvtárnak, mely szeretné nyilvántartani ki, mikor, melyik könyvet kölcsönözte, visszahozta-e, a könyv kiadóját, könyv kiadójának címét, stb. A nyilvántartani kívánt adatok: szemigszám, név, cím, leltáriszám, könyvcím, kiadó, kiadócím, kiviteldátuma, visszahozta-e,

10. Az első normálforma (1. NF) - oszlopok száma és sorrendje minden sorban azonos - minden oszlop csak meghatározott típusú értéket vehet fel - minden attribútum, csak egyetlen értéket vehet fel - minden sorhoz egyedi kulcs tartozik, mely egyértelműen azonosítja (!!!nincs két azonos sor!!!)- a reláció(k)nak neve van A példánk a következőképp festene 1. NF-be:Kölcsönzés(szemigszám, név, cím, leltáriszám, könyvcím, kiadó, kiadócím, kiviteldátuma, visszahozta-e) !!!Figyeljük meg az összetett elsődleges kulcsot!!!

11. Teljes funkcionális függés!Az egész elsődleges kulcstól függ!Megmaradhat! kiadócíme Az második normálforma (2. NF) - 1. NF-ben van - a nem kulcs attribútumok funkcionálisan teljesen függnek az elsődleges kulcstól (magyarán szólva a teljes elsődleges kulcstól függnek a többiek!) A teljes és részleges funkcionális függőség megállapításához egy un. függőségi diagrammot kell rajzolnunk: Részleges funkcionális függés esetén az attribútumok csak az elsődleges kulcs egy részétől függenek!!! Ki kell küszöbölni! visszahozta-e névcímkönyvcímkiadó szemigszámleltáriszámkiviteldátuma

12. Kölcsönzés(szemigszám, leltáriszám, kiviteldátuma, visszahozta-e) Tag(szemigszám, név, cím) Könyv(leltáriszám, könyvcím, kiadó, kiadócím) kiadócíme Hogyan bontsuk a relációnkat? névcím könyvcímkiadó szemigszám leltáriszám kiviteldátuma visszahozta-e Máris 3 relációnk van, melyek un. idegenkulcsokon keresztül kap-csolódnak össze. Ezek 1:N kapcsolatokat jelentenek. A kölcsönzés reláció szemigszámát kikeresve a tag relációból, megtudhatjuk a kölcsönző tag nevét, címét. Hasonlóan a leltáriszámból a könyv címére, kiadójára, és a kiadó címére tudunk következtetni!

14. kiadócíme Az harmadik normálforma (3. NF) - 2. NF-ben van - a nem kulcs attribútumok közvetlenül az elsődleges kulcstól függenek szemigszámleltáriszámkiviteldátuma visszahozta-e névcím könyvcímkiadó szemigszám leltáriszám A kiadócíme attribútum nem a közvetlenül az elsődleges kulcstól függ!

15. Egy nem túl szerencsés eset szemigszámleltáriszámkiviteldátuma visszahozta-e névcím könyvcímkiadó szemigszám leltáriszám kiadó kiadócím A problémát a kiadó idegen és elsődleges kulcs okozza! Meglehetősen hosszú is lehet egy kiadó neve. Ezért nem célszerű ez alapján összekapcsolni két táblát. Megoldás>>>

16. A végleges megoldás szemigszámleltáriszámkiviteldátuma visszahozta-e névcím könyvcímkiadókód szemigszám leltáriszám kiadókód kiadókiadócíme A megoldást egy kiadókód mező szolgáltatja, mellyel jobb híján pl. 1-től kezdve elkezdjük sorszámozni a kiadókat!

18. Vége