Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika Tanszék 2011 Dr. Alhusain Othman oalhusain@gmail.com 5.1. Definíciók 5.2. Adatbázis kialakításának kellékei 5.3. Az adatbázis létrehozásának főbb fázisai 5.4.. Adatbázis tervezés 5.5. Az adatbázis-tervezés tervezés folyamata 5.6. Az adatbázis-tervezés tervezés lépései 5.7. Adatbázis rendszer tervezése 5.7.1. Rendszer tervezés elmélete 5.7.2. Rendszer tervezési technikák 5.7.3. Rendszer elemzés 5.7.4. Rendszer tervezés 5.7.5. Fizikai szint tervezése (szempontok) 1 5.8. Adat függetlenség 5.9. Adat biztonság 5.10. Kapcsolatok az adatbázisban 5.10.1. Az 1:1 kapcsolat típus 5.10.2. Az 1: N kapcsolat típus 5.10.3. Az M: N kapcsolat típus 5.11. Adatbázis anomáliák (emlékeztető) 5.12. Adatbázis normalizálás 5.13. Normál formák 5.13.1. Első normálforma (1NF) 5.13.2. Második normálforma (2NF) 5.13.3. Harmadik normálforma (3NF) 5.13.4. Boyce-Codd normálforma (BCNF) 5.1. Definíciók: Adatbázis: köznapi értelemben valamely rendezett, valamilyen szisztéma szerint tárolt adatokat értünk, melyek nem feltétlenül számítógépen kerülnek tárolásra. Egy adott szakterületet jellemző adatokból az adatok típusát és kapcsolatát leíró adatokból (métaadatok) és az adatkezelő rendszerből áll. Egy megvalósított adatmodell, amely - a valódi adatokon kívül - tartalmazza az adatok típusát, jellemzőit, adatcsoportok közötti kapcsolatokat leíró metaadatokat. Adatmodell: Olyan koncepciók gyűjteménye amelyek egy adatbázis szerkezetét egyértelműen leírják. 4 5.2. Adatbázis kialakításának kellékei: 5.3. Az adatbázis létrehozásának fő fázisai: DDL: Data Definition Language, adatszerkezet leíró nyelv SDL: Storage Description Language, fizikai szerkezet DML: Data Manipulation Language, adatmanipulációs nyelv DBMS: (Data Base Management System) adatbázis kezelő rendszer Összegyűjtjük az adattárolási és adatfeldolgozási igényeket (specicikáció és analízis). Az adatokat az igények szerint csoportosítva és az egyes csoportok közötti összefüggéseket feltárva kialakíthatjuk az adatbázis magas színtű modelljét (koncepcionális séma) és lekérdezési sémákat. Kiválasztjuk az adatbázis kezelő rendszer típusát. A koncepcionális séma alapján megalkotjuk az alacsony szintű, logikai modellt (relációs, hálós, hierarchikus, objektum-orientált, stb..). Az igények szerint és a konkrét adatbázis-kezelő szoftverek ismeretében megtervezzük az adattárolási szerkezeteket és hozzáférési módokat (pl fastruktúra, indexelt hozzáférés). Továbbá elkészítjük az előre tervezhető adatbázis-kezelő műveletek (lekérdezések, tranzakciók) sémáit. A konkrét adatbázis-kezelő rendszer (pl. DB2, ORACLE, MS ACCESS) adatleíró és manipuláló nyelvének felhasználásával létrehozzuk az adatbázis szerkezetét és a lekérdezési sémákat, majd ezt követően feltöltjük az adatbázist az addig összegyűjtött adatokkal. 5 6 1
5.4. Adatbázis tervezés: 5.5. Az adatbázis tervezés folyamata: adatbázis rendszer Felhasználók Alkalmazói program Adatbázis-kezelő rendszer (DBMS) A lekérdezéseket kezelő szoftver komponens A tárolt adatokat kezelő szoftver komponens Operációs rendszer Magának az alkalmazandó adatbázis-kezelő rendszer adattárolási módjának és adatkezelési jellemzőinek megismerése nagyon lényeges Az információk hatékony kinyerése céljából: Relációs adatbázisok: Minden témakörnek megfelelni egy külön táblában. Meghatározni milyen kapcsolat rendszer áll fen a táblák között. métaadatok tárolt adatok 8 5.6. Az adatbázis-tervezés tervezés lépései: 1. Lépés: Fogalmi modell alkotása: Adatbázis céljai és feladatai megfogalmazása. 2. Lépés: Logikai modell alkotása 1: A szükséges táblák meghatározása 3. Lépés: Logikai modell alkotása 2: A táblák szükséges mezőinek meghatározása 4. Lépés: Logikai modell alkotása 3: A kapcsolatok felállítása a táblák között 5. Lépés: A modell tesztelése: Az adatbázis terv finomítása 5.6. Az adatbázis-tervezés tervezés lépései: 5.6.1. Adatbázis céljai és feladatai megfogalmazása: Kell tisztázni: Az adatbázis létrehozásának célját. Az adatbázis használati módját. Az adatbázissal szemben támasztott követelményeket. Az adatbázis által elvégezendő részfeladatokat. Adatbázis felhasználói Adatgyűjtés: Jelenlegi adat rögzítés. Használatos űrlapok, jelentések, kinyomtatások, összesítések Tárolandó adatok köre meghatározása: szőkítés de teljes körősség. 9 10 5.6. Az adatbázis-tervezés tervezés lépései: 5.6.2. A szükséges táblák meghatározása: Normalizálás Az információk témakörre lebontása Témakörök meghatározása Táblák Mezők meghatározása Táblák oszlopai Kerülni kell az úgynevezett többszöri adatbevitel. Kerülni kell az úgynevezett értékes adattörlést. 3.6. Az adatbázis-tervezés tervezés lépései: 3.6.3. A táblák mezőinek meghatározása: Kell dönteni, hogy a táblában szereplő egyedekről mit szeretnénk megtudni. A tábla minden egyes rekordjában ugyanazon jellemzők értékeit tároljuk a különböző egyedekről. Minden mező álljon közvetlen kapcsolatban a tábla témakörével. Az olyan mező, ami egy másik tábla tárgykörét érinti, lehet, hogy abba a táblába tartozik. Ne felejtsünk ki egyetlen információt sem. Tekintsük át még egyszer az adatbázis-tervezés tervezés első - lépésében körvonalazott információk körét. Lehetőleg soha ne tároljunk számított adatot, amely a táblák más mezőjéből vagy mezőiből kalkulálhatók. Az információt a lehető legkisebb egységekben tároljuk. Kerüljük a redundáns mezőket, amelyek más táblákban már szerepelnek. 11 12 2
5.6. Az adatbázis-tervezés tervezés lépései: 5.6.3. A táblák mezőinek meghatározása: Nézzük meg, van-e a táblának olyan mezője (vagy mezői), amely egyértelműen azonosítja a tábla rekordjait, és betöltheti az elsődleges kulcs szerepét. Ha nincs, akkor vegyünk fel egy ilyen mezőt, amely akár egy egyszerű sorszámozással biztosítja a rekordok egyértelmű azonosítását. Gondolkodni kell azon, milyen mezőneveket használjunk a táblában az adatok megkülönböztetésére, a mezők milyen adattípusúak (szöveges, szám, dátum, stb.) és milyen hosszúak legyenek. Van-e a mezőknek esetleg valamilyen jellemző alapértéke illetve formátuma, tudunk-e valamilyen szabályt felállítani a bevihető adatok körére. Kell meghatározni hogy, melyek azok a mezők, amelyek kitöltése mindenképpen szükséges egy rekordnál és melyek maradhatnak üresek. 5.6. Az adatbázis-tervezés tervezés lépései: 5.6.4. A kapcsolatok felállítása a táblák között: Vizsgáljuk meg, mely táblák tartoznak valami módon egymással. Vannak-e kapcsolatban a különböző táblák, vagy talán un. Átfogó kapcsolótáblát be kell iktatni. A kapcsolat létrejöttéhez meg kell vizsgálnunk, melyik az a mező, ami a kapcsolatot biztosítja a két tábla között. A kulcs mezőt mindkét kapcsolódó táblának tartalmaznia kell. Meg kell vizsgálnunk a kapcsolat típusát (egy az egyhez, egy a többhöz, több a többhöz) és a kapcsolat minőségét, az adatintegritási szabályokat. 13 14 5.6. Az adatbázis-tervezés tervezés lépései: 5.6.5. Adatbázis terv finomítása: Táblák, mezők, és kapcsolatok elméleti meghatározása után újból át kell néznünk a tervet, azt elemeznünk kell, hogy az esetleges hiányosságok kiderüljenek. A táblák fizikailag is létrehozni, és teszt adatokkal tölteni. A szükséges űrlapok, jelentések, lekérdezések prototípusát is elkészíthetjük. Eközben kiderülhet az, hogy a mezők adattípusát, méretét megfelelően határoztuk-e meg, s a táblák közötti kapcsolatot biztosító mezők nem mondanak-e ellent az adatintegritási szabályoknak. Fény derülhet arra is, helyesen választottuk-e meg a táblák elsődleges kulcsát, a beviendő adatok nem sértik-e a táblák közötti kapcsolatokat. Ezek ismeretében korrigáljuk, finomítsuk az adatbázis tervét, ami többször bizonyos tervezési lépések megismétlésével jár. 5.7.1. Rendszer tervezés elmélete: Rendszer elemzés: Tárolandó adatok körét: Adatbázissal szemben felmerülő igényeket: Rendszer tervezés: Megvizsgáljuk a relációk közötti kapcsolatokat, ennek eredménye a rendszer specifikáció, vagy logikai modell. A fizikai szint leképzés: képezzük le a logikai adatbázis modellt a felhasználható szoftver és hardver függvényében. 15 16 5.7. Adatbázis rendszer tervezése: 5.7.1. Rendszer tervezés elmélete: Rendszer elemzés: Tárolandó adatok körét: Adatbázissal szemben felmerülő igényeket: Rendszer tervezés: Megvizsgáljuk a relációk közötti kapcsolatokat, ennek eredménye a rendszer specifikáció, vagy logikai modell. A A fizikai szint leképzés: képezzük le a logikai adatbázis modellt a felhasználható szoftver és hardver függvényében. 5.7.2. Rendszer tervezési fogalmak: Funkcionális függőség: Funkcionális függőség: Adatok között akkor áll fenn funkcionális kapcsolat, ha egy vagy több adat konkrét értékéből más adatok egyértelműen következnek. Például a személyi szám és a név között funkcionális kapcsolat áll fenn, mivel minden embernek különböző személyi száma van. Például a személyi szám és a nem között funkcionális kapcsolat áll fenn, mivel minden embernek lehet határozni a nemét a személyi száma alapján. 17 18 3
5.7.2. Rendszer tervezési fogalmak: Reláció kulcs: A reláció kulcs egy relációnak egy sorát azonosítja egyértelműen. A reláció nem tartalmazhat két azonos sort, ezért minden relációban létezik kulcs. A reláció kulcsnak a következő feltételeket kell teljesítenie: Az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelműség). A kulcsban szereplő attribútumok egyetlen részhalmaza sem alkot kulcsot. A kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL). 5.7.2. Rendszer tervezési fogalmak: Redundancia: A logikai adatbázis tervezés egyik fő célja a redundanciák megszüntetése. A redundanciáról akkor beszélünk, ha valamely tényt vagy többszörösen tároljuk, vagy a többi adatból levezethető mennyiséget ismételten tároljuk az adatbázisban. A redundancia, a szükségtelen tároló terület lefoglalása mellett, komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek könnyen az adatbázis inkonzisztenciáját okozhatják. A megoldás: normálizáció 19 20 5.7.2. Rendszer tervezési fogalmak: Indexek fogalma és felépítése: Az indexek logikailag egy rendezett listaként foghatóak fel. Fizikailag a rendezett sorrendet táblába rendezett mutatók biztosítják. A relációkban tárolt információk visszakeresését az indexek nagymértékben meggyorsíthatják, így a tervezés során nagy hangsúlyt kell fektetni a helyes indexek kiválasztására. Az indexek számának indokolatlan növelésével az adatok beviteléhez illetve módosításához szükséges idő megnövekszik az indexek frissítése miatt. A relációkhoz kapcsolt indexek segítségével az index kulcs ismeretében közvetlenül megkaphatjuk a kulcsot tartalmazó sor fizikai helyét az adatbázisban. 5.7.3. Rendszer elemzés: Elemzési elvek: Adatállományok lebontása és/vagy csoportosítása. Kapcsolat és átfedések a csoportok között. különböző jogosultsági és hozzáférési szinteket kell határozni. 21 22 5.7.4. Rendszer tervezés: A rendszertervezés során a rendszerelemzés alatt összegyűjtött információk alapján egy kész logikai modellt kell előállítni. A logikai modell közvetlenül felhasználható az adatbázis kialakításakor. A logikai szint megalkotásakor már figyelembe veszünk olyan szempontokat, amelyek már a konkrét használattal kapcsolatosak. A tervezési folyamatok során mérlegelnünk kell, hogy a táblák mezőinek számát növeljük meg, vagy több táblában helyezzük el az információkat, és így a táblák közötti kapcsolatrendszerre helyezzük át a hangsúlyt. Szintén a táblák kialakításának fontos szempontja és befolyásoló tényezője, hogy előre rögzítsünk tulajdonságokat az információ mennyiséget, vagy hagyjuk meg a lehetőséget a későbbi bővítésre 5.7.5. Fizikai szint tervezése: A fizikai tervezés során inkább arra koncentrálunk, hogy a logikai szerkezet mennyire felel meg a hatékony végrehajtás feltételeinek, illetve milyen indexeket rendeljünk az egyes relációkhoz. A relációkon végrehajtott művelet együttest tranzakciónak nevezzük és általában a tranzakciók gyors végrehajtását kívánjuk elérni. A tervezéskor figyelembe kell vennünk a táblákban történő tranzakciók gyakoriságát, hiszen nem mindegy, hogy egy háttér információkat tartalmazó tábláról van szó, amit néhány adminisztrátor használ, vagy pedig gyakori és mindenki által kezelt tábláról van szó. Az index állományok segítségével gyorsabban kereshetünk a tábláink között, azonban egy új rekord beszúrása több időt vesz igénybe. A végleges adatstruktúra kialakításkor fontos szempont ugyanazon adatok különböző módokon történő rögzítése. Ezen problémák elkerülése érdekében, ahol csak lehet, meg kell szüntetni a szöveges adatrögzítési feladatokat, ezt checkbox (többválasztós), rádió (egyválasztós), vagy legördülő mező alkalmazásával lehet elkerülni. 23 24 4
5.8. Adat függetlenség: 5.8.1. Logikai függetlenség: Logikai szinten az adatbázis leírása megváltoztatható anélkül, hogy a fizikai szinten változás történne. Az adatszerkezet megváltozása csak métaadatokban jelent változást. Az adatbázis használata közben szükségessé válhat a fogalmi adatbázis módosítása, például új objektumok bevezetése (új táblák létrehozása), vagy régi objektumok új információval való kibővítése (pld. egy meglévő táblákhoz új oszlop hozzáadása), vagy feleslegessé vált objektumok törlése (többé nem használt táblák ). A fogalmi sémán számos változtatás hajtható végre anélkül, hogy ezek a létező felhasználói nézeteket érintenék. Néhány, a fogalmi sémán végrehajtott változtatás igényelheti az érintett felhasználói szintek módosításait. Az alkalmazói programoknak ügy szintén az esetek többségében minden változtatás nélkül kell hogy futnak. Ha van egy olyan változtatás ami mindenképpen a felhasználói séma átírását igényli, akkor ebben az esetben szükségessé válhat egyes alkalmazói programok módosítása is. 5.8. Adat függetlenség: 5.8.2. Fizikai függetlenség: Fizikai szinten az adatbázis leírása megváltoztatható anélkül, hogy a logikai szinten változás történne. Az adattárolási szerkezet és a hozzáférési módok változása nem vonja maga után a koncepcionális séma- és az alkalmazói program megváltozását. Röviden mondható hogy, egy jól szervezett adatbázisban a fizikai séma megváltoztatható, anélkül, hogy változtatni kellene a fogalmi sémán, vagy hogy újra kellene definiálni a nézeteket, a külső szintet. 25 26 5.9. Adat biztonság: A falhasználók egyes csoportjai nem látják (nem láthatják) a teljes adatbázist illetve annak részeit is esetleg másképpen látják. Minden felhasználó a látási szintjén (tartományon) belül teljesen kell hogy követhető és rekonstruálható a tevékenysége. Egy felhasználói szinten kell tervezni a különböző végrehajtható műveleteket hogy a hiba eredménnyel járó végrehajtás nulla csökkenjen (kötések). 5.10. Kapcsolatok az adatbázisban: Az adatbázis táblái között leggyakrabban (de nem mindig) létezik kapcsolat. A kapcsolat lehet Zérós-, Egyes-, vagy Többes típusú. Ha egyik rekord létezik a forrás táblán, viszont egyáltalán nem létezik egy cél táblán, ilyen kapcsolat a két tábla között Zéró-kapcsolatot szokták nevezni. Zérós Kapcsolat: Zérós rekord nem kötelezően de létezhet a cél táblán. Egyes Kapcsolat: Egyes rekord kell hogy legalább egyszer létezik a cél táblán. Többes Kapcsolat: Többes rekord kell hogy többször létezik a cél táblán. 27 28 5.10. Kapcsolatok az adatbázisban: A kapcsolat létezése: Két egyed halmaz között akkor van kapcsolat, ha legalább egy elemnek az első halmazból van kapcsolata legalább egy elemmel a másik halmazból. Kapcsolat típusok: Totális: Amennyiben egy kapcsolatban résztvevő egyedtípus minden egyede valóban részt vesz a kapcsolatban, azaz minden egyede kapcsolatban van legalább egy másik egyeddel, akkor az egyedtípus teljes (totális) részvételéről beszélünk. Parciális: Ha létezik az egyedtípusnak olyan előfordulása, amely nem létesít kapcsolatot egyetlen más egyeddel sem, akkor az őt tartalmazó egyedtípus A kapcsolat tipusa az határozza hogy, egy adott egyedtípushoz tartozó egyed hány másik egyedtípushoz tartozó egyeddel van kapcsolatban. Számszerűség: 1 : 1 1 : N M : N N-ágú kapcsolat: Több bináris kapcsolat 5.10.1. Az 1 : 1 Kapcsolat: Definíció: Akkor beszélünk 1:1 kapcsolatról (egy-egy), ha a kapcsolatban résztvevő egyedtípusok egyedei legfeljebb egy (és nem több!) másik egyedtípusbeli egyeddel létesítenek kapcsolatot. Az 1:1 kapcsolatok nagyon hasznosak a Null- értékű cellák (mezők) eleminasában. Grafikon: Házastársi kapcsolat 29 30 5
5.10.1. Az 1 : 1 Kapcsolat: Tábla: Emberek és személyi számaik: Kovács József 12045678 Nagy Lajos 32551230 Andrásy Botond 23511114 Kiss István 01234567 Nagy Istvánné 01010101 5.10.2. Az 1 : N Kapcsolat: Definíció: Az 1: N kapcsolat esetében az egyik egyedei legfeljebb egy másik beli egyeddel létesíthetnek kapcsolatot, míg a másik előfordulásai között biztosan van legalább egy olyan egyed, amely több (legalább kettő) előző beli egyeddel van kapcsolatban. Tulajdonság: Az 1:N kapcsolat típus nagyon elterjedt az adatbázisok táblai között. A legjobban mutatható a VAN E logikai kifejezésben. 31 32 5.10.2. Az 1 : N Kapcsolat: Grafikon: Egy embernek több autója lehet, de egy autónak legfeljebb egy tulajdonosa van. 5.10.2. Az 1 : N Kapcsolat: Tábla: Egy szülő (anya vagy apa) és gyerekek (az "1" re mutató nyíl használata) nyilvántartása egy táblán Kissné Nagy Valéria Kiss Norbert Ember Van-e Auto Tóth Lajosné Tóth Mária E1 * A1 Tóth Lajosné Tóth Fatime E2 * A2 Tóth Lajosné Tóth András E3 * A3 Kovács József Kovács Laszló Kovács József Kovács Heidi 33 34 5.10.3. Az M : N Kapcsolat: Definíció: Az M :N kapcsolat esetében mindkét tartalmaz legalább egy olyan egyedet, amely több másik beli előfordulással van kapcsolatban. Tulajdonság: Az M:N kapcsolat párosul összetettebb egyed struktúrával. Az M:N kapcsolatot egy adatbázisban a legjobban kifejezhető több tábla használatában, ahol egy rekord az egyik táblából kapcsolódik több rekordhoz egy másik táblában. A legjobban mutatható a TÖBBEK CSINALNAK TÖBBET logikai kifejezésben. 5.10.3. Az M : N Kapcsolat: Grafikon: Színészek játszanak színdarabokban. Szinész Játszik Darab 35 36 6
5.10.3. Az M : N Kapcsolat: Tábla: Egy táblázatos példa a több- több (M:N) kapcsolatokra, a lóverseny fogadók és a lovak nyilvántartása. Egy másik példa, egyetemen a hallgatók és a kurzusok nyilvántartása ahol egy hallgató több kurzus vehet fel, és egy kurzushoz több hallgató tartozhat. Szentpéteri István Szentpéteri István Kovács Vazul Károlyi Elek Elek valaki AlföldCsillaga Overdose FehérMax Kiss zürkeség FehérMax 5.11. Adatbázis anomáliák 5.11.1. Bevezetés: Az adatstruktúra megalkotásánál a kezelés hatékonyságára is gondolni kell. A rossz adatmodell adat többszörözés (redundanciához ) vezethet. A redundancia mellett számos egyéb műveleti nehézséget is okozhatnak a modell hiányosságai, ezek közül legszembetőnúbb az hogy, nem az összetartozó adatok kerülnek egy relációba (anomáliák). Hogy melyik mezők kerülnek egy relációba, maga után vonja hogy a mezők közötti összetartozási viszony, és a mezők közötti függőségek határozza meg. A legfontosabb függőségi típus a funkcionális függőség, mely megközelítőleg megfogalmazva azt jelenti, hogy az egyik mező minden értékéhez a másik mező egy értéke kapcsolható. 37 38 5.11. Adatbázis anomáliák 5.11.2. Emlékeztető: 5.11.2.1. Redundanciák: A redundanciáról akkor beszélünk, ha valamely adat (tényt) többszörösen tároljuk az adatbázisban, vagy a többi adatból levezethető mennyiséget ismételten tároljuk. Felesleges adattárolás. Komplikált adatbázis frissítési és karbantartási műveletekhez vezet. Okozhat adatbázis inkonzisztenciáját. Megoldás: Normálizáció Relációs modellezés és tervezés Strukturált tervezés Logikai tervezés Több táblás tervezés 5.11. Adatbázis anomáliák 5.11.2. Emlékeztető: 5.11.2.2. Anomáliák: Beszúrási anomália: Amikor egy rekord felvitelekor, felesleges, már letárolt információkat is újra be kell vinni; Módosítási anomália: Amikor egy információegység módosításához több helyen is módosítani kell az adatbázisban, ami nem csak többletmunkát okoz, de növeli az inkonzisztens (nem egyértelmű) állapot valószínűségét is, ha valahol elmarad a módosítás; Törlési anomália: A törlési anomália azt jelenti, hogy egy információelem megszűnésekor más, hozzá nem tartozó információk is elvesznek. 39 40 5.11. Adatbázis anomáliák: 5.11.2. Emlékeztető: 5.11. Adatbázis anomáliák: 5.11.2. Emlékeztető: 5.11.2.2. Anomáliák: Beszúrási anomália: Törlési anomália: Módosítási anomália: 5.11.2.2. Anomáliák: Bövítési (beszúrási) anomália: Amikor egy rekord felvitelekor, felesleges, már letárolt információkat is újra be kell vinni; 41 42 7
5.11. Adatbázis anomáliák: 5.11.2. Emlékeztető: 5.11. Adatbázis anomáliák: 5.11.2. Emlékeztető: 5.11.2.2. Anomáliák: Módosítási anomália: Amikor egy információegység módosításához több helyen is módosítani kell az adatbázisban, ami nem csak többletmunkát okoz, de növeli az inkonzisztens (nem egyértelmű) állapot valószínűségét is, ha valahol elmarad a módosítás; 5.11.2.2. Anomáliák: Törlési anomália: A törlési anomália azt jelenti, hogy egy információelem megszűnésekor más, hozzá nem tartozó információk is elvesznek. 43 44 5.12.1. Definíció: A normalizációt lehet definiálni mint szétbontó műveletek sorozata, amelyek eredményeként egymással kapcsolatban álló relációkat kapunk. A helyes modell megtervezésére irányuló elvek és módszerek normalizálás néven is ismeretesek. Így a normalizációt lehet definiálni mint sorozat lépés amelyben a relációs adatmodell létrehozható és javítható (korrigálható) egyben. A normalizálás tehát egy tervezési metodika, amely segítséget nyújt a helyes, anomália mentes relációs sémák és adatbázis kialakításában. 5.12.2. Normalizációs eljárás: Az ER diagramok átírásából kapott reláció sémák még nem véglegesek. Az adatbázis tervezésének következő szakasza az egyes relációs sémákban szereplő attribútumok egymás közötti kapcsolatainak ellenőrzése. A kapcsolatokat ûn. függőségekkel írjuk le. Az ellenőrzés, és ha szükséges, az azt követő sémaátalakítási folyamaton keresztül elérhető lesz a normálizáció. 45 46 5.12.3. A normalizáció céljai és haszna: A normalizálás célja, hogy a lehető legkisebbre csökkentsük az adatbáziskezelő rendszerben a használat során előforduló potenciális hibaforrásokat. A normalizáció alkalmazásával csökken a tárolási igény. Megszűnnek vagy legalább csökkennek az anomáliák. Logikailag áttekinthetőbb lesz az adatbázis. 5.12.4. Függőségek az adatbázisban: 1. Determináns: X determináns a következő egyenletben mert értékétől függ Y értéke. Y=X+1 2. Funkcionális függőség: A fenti egyenletben Y funkcionálisan függ X-től mert Y értéke függ X értékétől. 47 48 8
5.12.4. Függőségek az adatbázisban: 3. Tranzitiv funkcionális függőség: A következő egyenlet rendszerben Z tranzitiv funkcionális függőségben X-el, mivel Y funkcionálisan függ X értékétől, és Z funkcionálisan függ Y értékétől. Y=X+1 Z=Y 2 USD meghatározza hogy a FizetőEszköz US Dollar Kanadai Dollar függ ettől hogy a FizetőEszközKód CAD 5.12.4. Függőségek az adatbázisban: 4. Teljes funkcionális függőség: A teljes funkcionális függőségben Y függ csak X értékétől és nem mástól, és X kombinálva Z-vel nem határozhat meg Y-t. Így X mint determináns nem alkothat összetett kulcsot. Pld.: A következő táblában összetett külcs (VáltóÉrték, Ország), szortírozva a VáltóÉrték-el, az Ország meghatározza a Lakosság-ot, a Lakosságot viszont meg van határozva csak az Ország-al és nem a VáltóÉrték-el. Így a funkcionális függőség teljes a Lakosság és az Ország között, mert a. VáltóÉrték nem relevans a Lakossághoz nézve. 49 50 5.12.4. Függőségek az adatbázisban: 5. Multi- értékes funkcionális függőség: Történik listás (multi-értékű) mezőknél. A multi-értékek függenek az elsődleges külcstől. Létezik triviális- és nem triviális-funkcionális függőség (két mezős illetve több mezős tábláknál). 5.12.4. Függőségek az adatbázisban: 6. Ciklikus funkcionális függőség: A ciklikus függőséget lehet modellezni kör alakú struktúrával. A függőség lehet direkt vagy indirekt. Pld1.: Y függ X-től, és az ellenkező is igaz. Pld2.: X kapcsolódik Y-re, Y kapcsolódik Z-re, és Z kapcsolódik X-re, következés képen Z kapcsolódik X-re. 51 52 A relációk közötti felállított tervezési irányelveket követelmények formájában szokás adni, több, egymásra épülő követelmény alakjában. Az egyes követelményeket szokás normálformáknak is nevezni. Az egyes normálformáknak megfelelő ellenőrzéseket, vizsgálatokat és módosítási lépéseket normalizációs lépéseknek nevezzünk. A normálformák fokának emelkedésével egy egyre szigorodó követelményrendszert reprezentálnak, ill. feltételrendszert jelentenek. A feltételek egymásra épülése alapján az egyes normálformákat rangsorba lehet helyezni. A rangsor alján elhelyezkedő, leglazább feltételt nevezzük első normálformának. Bár egy adatbázis struktúra több normál formára lehet bontani, a gyakorlat szempontjából csak az első három normálformának van jelentősége. 5.13.1. Első normálforma (1NF): Az Első normálformában van a relációs séma, ha minden mezője funkcionálisan függ a kulcsmező csoporttól. E szerint, a függőségi rendszerben léteznie kell egy kulcsnak, s minden más mezőnek ettől kell függenie. Másképen: Az első normálformát lehet jellemezni a következő tulajdonságokkal: Egy reláció 1NF, ha minden sorban pontosan egy attribútum értéke van reprezentálva Nincs felőlről lefelé (top-to-bottom )sorrend a sorokon Nincs balról jobb felé sorrend az oszlopokon Nincs duplikáció a sorokon Minden sor és oszlop keresztezésében (cella) van egyetlen egy érték. Az összes oszlopok regulárisak (nincs bújtatott komponensek, pld. sor-, objektum- id-k 1NF-re hozás: Sorok szétbontása Több relációra bontás Az oszlopok száma és sorrendje minden sorban azonos Minden oszlop csak meghatározott értéket vehet fel az attribútum értéktartományából 53 54 9
5.13. Normál formák: 5.13.1. Első normálforma (1NF): 5.13.1. Első normálforma (1NF): Példák nem felelnek meg az 1NF-nek: Elsődleges kulcs nélküli tábla. Tábla a legalább egy nullás attribútummal. Tábla nézet amely feltételezi sorrendet a kulcs mezőn kívül. 55 56 A második normálformában van a reláció, ha az első normálformát teljesíti, és ezen felül minden nem kulcs mező a teljes kulcstól függ, de nem függ a kulcs bármely részhalmazától. Ezzel azt fejezzük ki, hogy a kulcsközponti szerepet játszik a relációban, minden mezőnek a teljes kulcstól, s nem annak egy részétől kell függnie. A második normálformát sokszor az eredeti reláció feldarabolásával lehet elérni. Másképen: A Második normálformát lehet jellemezni a következő tulajdonságokkal: Egy reláció 2NF, ha 1NF és minden másodlagos attribútum teljesen függ a kulcstól Ha a kulcs egyszerű (nincs része): 2NF Ha nincs másodlagos attribútum: 2NF Nincs részleges függőség Több relációra való felbontás: Kiemeljük a kulcsból azokat az attribútumokat, amelyek önállóan meghatározzák a másodlagos attribútumokat Ezekből új relációt képezünk A kulccsal teljes függésben lévő attribútumokat a kulcs elsődleges attribútumaival új táblában fogjuk össze új relációk elsődleges kulcsai idegen kulcsként bekerülnek az 57 eredeti relációba 58 és tábla között 1:N kapcsolat van. Kiadó adatok statikusak, egy Kiadó több könyvet kiadhat. Tema adatok statikusak. (IK) cim 1 N nem_ és tábla között 1:N kapcsolat van. Kiadó és Tema statikus adatok különítése 2NF-ban. Kiado _Kontakt (IK) konyvcim Tema nem_ (IK) cim nem_ 59 60 10
2NF-ban létrehozunk több 1:N kapcsolat: és tábla között 1:N kapcsolat van. Kiado és között 1:N kapcsolat van. Tema és között 1:N kapcsolat van. Kiado _Kontakt (IK) konyvcim Tema nem_ (IK) cim nem_, Kiado, Tema táblák egy és tábla között 1:N kapcsolat van. Elsődleges kölcsök a statikus tablákban kötjük a dinamikus tábla mint része az összetett elsődleges kölcsnek. (IK) konyvcim (IK) (IK) Kiado _Kontakt Tema nem_ (IK) cim nem_ 61 62, Kiado, Tema táblák egy és tábla között 1:N kapcsolat van. Elsődleges kölcsök a statikus tablákban kötjük a dinamikus tábla mint része az összetett elsődleges kölcsnek. és táblák között 1:N kapcsolat van. Kiado, Tema táblák egy és tábla között 1:N nem azonosító kapcsolat van. (IK) konyvcim (IK) (IK) Kiado _Kontakt Tema nem_ (IK) cim nem_ 63 64 5.13.3. Harmadik normálforma (3NF): A Harmadik normálformában van a reláció, ha teljesíti a második normálformát és ezenkívül igaz, hogy nem áll fenn tranzitív függőség, azaz nem áll fenn az egyik nem kulcs mezőből egy másik nem kulcs mezőbe irányuló függőség. A kulcs ugyanis a köztes mezőn keresztül, tranzitíven határozza meg a másik mező értékét. Ezért a köztes mező egyfajta kulcs szerepet játszik a másik mezőnél. A tranzitív függőség feloldás is szintén a reláció feldarabolásával történik. Ehhez kiemeljük a tranzitív függést egy külön relációba. Az eredeti táblában csak a kapcsolatot biztosító mező marad meg. 5.13.3. Harmadik normálforma (3NF): Másképpen: A reláció 3NF, ha 2NF és: Nincsenek tranzitív függőségek. A tranzitív függőség egy olyan függőség láncolat, amelyben az elsődleges kulcs meghatároz valamilyen attribútumot, és az attribútum meghatároz egy harmadik attribútumot. A kapcsolat 3NF ha minden mező a relációban amely nem kulcs mező kell hogy direkt módon függjön az elsődleges kulcstól. 3NF-be hozás: A reláció felbontása A tranzitív függőséget egy új relációba helyezzük. Az eredeti relációban meghagyjuk az összes többi attribútumot. Az új reláció elsődleges kulcsa a kiindulási táblában idegen kulcsként szerepel. 65 66 11
5.13.3. Harmadik normálforma (3NF): Az M:N kapcsolat átírása áttekinthető formában. 5.13.3. Harmadik normálforma (3NF): Az M:N kapcsolatban eredményez duplikált rekordok hol az egyedi rekordok kívánatosak. Join lekérdezes eredményezhet duplikált rekordok egy M:N kapcsolatban Dolgozo dolgozo Feladat feladat Dolgozo dolgozo Feladat feladat Munka dolgozo (IK) feladat (IK) Biztosít egyedi Munkak 67 68 5.13.3. Harmadik normálforma (3NF): A 3NF transzformáció önti a rekord duplikációt új táblában. Ugyfel és beszalito függetlenek egymástől 5.13.3. Harmadik normálforma (3NF): A 3NF transzformáció tranzitiv függőség szeparálása új táblában. Minden osztaly egy varosban van Ugyfel Beszalito ugyfel beszalito fizetoeszk. kod fizetoeszk. kod fizetoeszk fizetoeszk Valtoar Valtoar cim cim A fizetoeszkoz adatai közös a két táblában Ugyfel ugyfel fizetoeszk. Kod (IK) cim Beszalito beszalito fizetoeszk. Kod (IK) cim Penzváltás fizetoeszk. kod fizetoeszk Valtoar Dolgozo dolgozo osztaly varos 1. A varos tamaszkodik az osztalyra. 2. Az osztaly tamaszkodik a dolgozora 3. Következésképen a varos indirekt módon (tranzitiv módon) tamaszkodik a dolgozora. Ugyfel ugyfel fizetoeszk. Kod (IK) cim Penzváltás osztaly varos Tranzitiv függőség megoldott! 3NF transzformáció rendeli a fizetoeszkoz adatai új táblában 69 70 5.13.4. Boyce-Codd normálforma (BCNF): A normál formák definíciója alkalmazható a több jelölt kulccsal rendelkező relációkra is (un. Surrogate és Natural keys). Ebben az esetben minden attribútum, mely valamely kulcsnak a része, elsődleges attribútum, de ez az attribútum függhet egy másik, ezt nem tartalmazó kulcs részétől. Ha ez a helyzet fennáll, redundanciát tartalmaz a reláció. Ennek a felismerése vezetett a harmadik normál forma egy szigorúbb definíciójához, a Boyce/Codd normál formához. BCNF tulajdonságai: Minden reláción belüli nem triviális függőség van. BCNF-re hozás: felbontással A Boyce-Codd normál forma egy erősebb normál forma, ami közvetlenül ellenőrizhető a funkcionális függőségek szempontjáből Ha BCNF, akkor biztosan 3NF is. Ha a relációban csak egy jelölt kulcs található akkor a reláció 3FN és Boyd-Codd formában van. Determinánsoknak kulcsjelölteknek kell lenniük. 5.13.4. Boyce-Codd normálforma (BCNF): Ugyfel-cim Ugyfel ugyfel-id ugyfel-nev cim tel fax email valtas jjelveny tartozas Aktivitasi-datum Napok-kredit Ugyfel-nev ugyfel-id (IK) Ugyfel-tel Ugyfel-id (IK) Ugyfel-id (IK) cim Ugyfel-nev UgyfelStockJ Ugyfel-id(IK) Ugyfel Ugyfel-id Tartozas Aktivitasi-datum tel valtas Napok-kredit fax jelveny Ugyfel-email Ugyfel-id(IK) email Ugyfel-fax ugyfel-id (IK) 71 72 12
5.13.4. Boyce-Codd normálforma (BCNF): 73 13