Adatbázis kezelés

8,822 views
8,632 views

Published on

Adatbázis kezelés tanfolyam elméleti anyaga

Published in: Education
2 Comments
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
8,822
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
54
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

Adatbázis kezelés

  1. 1. Adatbázis kezelés<br />2010.04.12.<br />1. rész.<br />1<br />
  2. 2. Az adatbázis fogalma<br /> Az adatbázis, logikailag összefüggő, meghatározott szerkezetben tárolt adatok halmaza.<br />2<br />
  3. 3. Adatbázisrendszerek<br />magába foglalják az adatbázisokat, a hozzájuk kapcsolódó számítógépes erőforrásokat, s tágabb értelemben az adatbázisok tervezését, kezelését végző személyeket is. Ez utóbbiakat nevezzük: Adatbázis adminisztrátoroknak.<br />Minden adatbázisnak van egy belső struktúrája sémája. Ez tartalmazza az összes adatelem és a köztük lévő kapcsolatok definícióját, leírását. <br />3<br />
  4. 4. Adatbázis Kezelő Rendszerek<br />Adatbázis feldolgozásról beszélünk akkor, amikor egy nagytömegű, kötött szerkezetű adathalmaz (az adatbázis) feldolgozását végezzünk számítógéppel támogatott  AdatBázis Kezelő Rendszer( ABKR ) keretében.<br />Az ABKR, a számítógépen tárolt Adatbázisok létrehozását, karbantartását, feldolgozását biztosító, valamint az adatok sérülését megakadályozó szoftverek összefoglaló neve. angolul: DBMS - DataBaseManagement System<br />4<br />
  5. 5. Az ABKR szolgáltatásai:<br />az adatbázis szerkezetének létrehozása<br />strukturált (meghatározott szerkezetű) adattárolás<br />szabályozott adat karbantartás ( bővítés, módosítás, törlés )<br />adatrendezés ( adott szempont szerinti sorba állítás )<br />adatszűrés ( adott szempont szerinti kiválogatás )<br />szerkesztett lekérdezés ( interaktív és nyomtatott )<br />egyszerű listázás<br />adat export és import ( kapcsolat más adatbázisokkal )<br />adatvédelmi eljárások <br />5<br />
  6. 6. Az ABKR-ek függetlenséget biztosítanak:<br />Az adatkezelés fizikai, azaz hardware lehetőségeitől: <br />Egy adatbázis és a hozzá kapcsolódó feldolgozó eljárások attól függetlenül legyenek kialakíthatók, hogy a feldolgozást végző hardver eszközök (processzor, háttértár, nyomtató, stb.) éppen milyen típusú, illetve a hardvert működtető alapszoftverek milyenek.<br />6<br />
  7. 7. Az adatelérés módjától:Az adatok elérésének és tárolásának módja (lásd fájlszerkezetek) különböző lehet. Az adatbázis kezelő szoftvereknek azonban még a rendszert fejlesztő programozó előtt is "el kell fednie" azokat az eljárásokat, amelyek által hozzájut a kívánt tartalmú és szerkezetű adatokhoz. A fejlesztőnek csak logikai adatkapcsolatokat kell meghatározni illetve a feldolgozás során csak a szükséges kérdéseket kell megfogalmazni a kívánt információ érdekében, de az eredmény előállításának módját nem kell definiálnia.<br />7<br />
  8. 8. Az adatszerkezettől:Az adatbázis szerkezete nem állandó. Új felhasználói igények merülnek fel az üzemeltetés során. Ezek többnyire további input adatok bevitelét és újabb output szolgáltatást (új listák, képernyők, stb.) jelentenek. Mindez az adatszerkezet módosulását vonja maga után. Ugyanakkor a "régi" feldolgozást változatlan formában igénylik. Egy új igény beépítése hagyományos rendszerben komoly program és adatállomány rekonstrukciót igényel. Az adatbázis kezelő rendszereknek azonban fontos kritériuma, hogy a változtatás ne érintse a korábbi feldolgozó eljárásokat bár az adatok szerkezete természetesen megváltozott.<br />8<br />
  9. 9. Az ABKR-kel szembeni elvárások:<br />Az adatok definiálása különüljön el az adatkezeléstől, (adatkatalógusban történik)<br />Az adatkatalógus maga is az adatbázis része, az adatokkal azonos módon történjen a feldolgozása <br />Az adatdefiníciónak, az adatkezelésnek és az adatbiztonságnak legyen programozási nyelve.<br /> Ezen nyelvi eszközök adjanak módot más alkalmazások, programnyelvek számára a hozzáféréshez. (interfész elemek )<br />9<br />
  10. 10. Az adatbázisokat kezelő programozási nyelvek tagolódása:<br />Adatleíró nyelv: (Data DefinitionLanguage  -  DDL) Az adatbázis sémájának kialakításához használt programozási nyelv. Program utasítások csoportja, mellyel definiáljuk az adatok nevét, adattípusát, méretét, formátumát, hozzáférhetőségét. A teljes adatbázisnak az adott felhasználói igény szerinti részhalmazát alsémánaknevezzük.<br />10<br />
  11. 11. Az Adatmanipuláló nyelv : (Data ManipulationLanguage  -  DML) Az adatbázisok feldolgozása az úgynevezett adatbázis-kezelő műveletek sorozataként valósul meg. A DML parancskészlet Az adatbázis elemeket (állományokat, rekordokat, kapcsolat leíró elemeket, stb.) és az adatokat mozgatni, létrehozni, felvinni, keresni, módosítani, törölni, egyszóval manipulálni képes. <br />11<br />
  12. 12. A Lekérdezőnyelv: (Query Language  -  QL)Parancskészlet, mely segítségével az adatbázisban tárolt adatokat meghatározott igények szerint kinyerhetjük. Szabványos lekérdező nyelv az SQL  - StructuredQueryLanguage, azaz magyarul a Strukturált lekérdező nyelv.<br />12<br />
  13. 13. Az Adatvezérlő nyelv: (Data ControlLanguage  -  DCL) Az adatbázis feldolgozása során sok és bonyolult művelet kerül végrehajtásra. Ahhoz, hogy az adatbázis egy ilyen tranzakció után is „jó” maradjon, ne sérülhessenek benne adatok vagy adat kapcsolatok, folyamatosan ellenőrizni (kontrollálni) kell a műveletvégzéseket. Biztosnak kell lenni abban, hogy valóban végrehajtódott-e a kívánt művelet, minden szükséges művelet megtörtént-e és abban a sorrendben ahogy kell, nem szakadt-e meg egy művelet lánc. Az adatbázis működését kontrolláló parancsok csoportja alkotja az adatvezérlő nyelvet.<br />13<br />
  14. 14. Adatvédelmi utasítások: Külön adatvédelmi nyelvről nem beszélünk, de léteznek adatvédelmi utasítások. Két alapvető célt valósítanak meg, hozzáférési jogokat definiálnak az adatbázishoz és annak elemeihez illetve a műveletvégzést szabályozzák. Például egy adatbázis bizonyos adatcsoportjához férhet csak hozzá az adott kezelő illetve amihez hozzáfér azt is csak olvashatja és módosíthatja de már nem törölheti. <br />14<br />
  15. 15. Adatbázis szerkezet<br />Az adatbázis adatállományok (adatfájlok) halmaz.<br />Pl. Egy Videó kölcsönző forgalmát feldolgozó adatbázis a Videofilmek és a Kölcsönző személyek adatait tartalmazó adatállományokból áll.<br />Az adatállomány logikailag összetartozó adatok meghatározott (előre megtervezett) szerkezetű tárolási formája. Más néven adat file. <br />Pl. A Videofilmek adatállománya a Videotékában forgalmazott filmek Címét, a megjelenés Dátumát, a film Műfaját, Kölcsönzési díját, stb. tartalmazza.<br />A Kölcsönző személyek adatállomány a Videotékából kölcsönző ügyfelek Személyi igazolvány számát, Nevét, Lakcímét, Születési dátumát, stb. tartalmazza.<br />Az adatállomány rekordokból áll, amelyek egy-egy konkrét adatsort tartalmaznak. Az előbb felsorolt adatok, ( Műfaj, Név, Lakcím, stb.) nem konkrét tartalmak, csak az adatok nevei, amelyekkel hivatkozunk rájuk. Egy adott film vagy ügyfél adatai az adatállomány rekordjaiban kerülnek eltárolásra. Minden rekordban egy-egy konkrét film vagy személy összetartozó adatai szerepelnek. Fontos jellegzetesség, hogy az adatok sorrendje minden rekordban azonos. Ezt értjük a "meghatározott szerkezetű" azaz strukturált adattárolás alatt.<br />15<br />
  16. 16. Videofilmek adatállomány:<br />Ügyfelek adatállomány:<br />A rekord eleme a Mező (field), amely egy konkrét adatot jelent az adatsorozatból.Pl.  A mező neve: Cím, tartalma: Star Wars 1.   vagy   a mező neve:  Lakcím,  tartalma: Gerbera köz 3.<br />16<br />
  17. 17. Az adatbázis szerkezete tehát az alábbi hierarchikus modellel írható le:ADATBÁZIS  { ADATÁLLOMÁNYOK   { REKORDOK   { MEZŐK } } }<br />Adatbázis<br />Adatállomány<br />Rekord<br />Mező<br />17<br />
  18. 18. Adatkapcsolatok<br />Az adatbázist, az egymással jól definiált kapcsolatban álló adatállományok alkotják. A kapcsolatok lehetnek:<br />1  :  1  fokú   kapcsolat<br />1  :  N fokú   kapcsolat<br />N : M   fokú   kapcsolat<br />A kapcsolat foka azt jelenti, hogy az egyik adatállomány rekordja(i) hány rekorddal áll(nak) kapcsolatban a másik adatállományban.<br />18<br />
  19. 19. 1:1 fokú kapcsolat<br />A kapcsolatban mindkét egyedtípus előfordulásai egyetlen egy<br />Férfi<br />Nő<br />HÁZAS<br />19<br />
  20. 20. 1:N fokú kapcsolat<br />Az egyik egyedtípus előfordulásai több előfordulással tarthatnak kapcsolatot a másikból, de a másik előfordulás továbbra is csak egy előforduláshoz kapcsolódhat<br />Ember<br />Birtokol<br />Autó<br />20<br />
  21. 21. N:M fokú kapcsolat<br />Mindkét egyedtípus előfordulásai több előfordulással is tarthatják a kapcsolatot<br />Oktató<br />Tanít<br />Tárgyat<br />21<br />
  22. 22. Kulcs mező<br />Az adatállományok kapcsolatát az adatállományok rekordjainak kitüntetett jelentőségű adata (mezője) biztosítja. Ezt a különleges adatot kulcsnak  ( kulcsmező-nek ) nevezzük.A kulcs lehet, egyszerű kulcs- amikor csak 1 db, illetve összetett kulcsha 2 vagy több attribútum vesz részt az egyedi azonosító képzésben. Az összetett kulcsból elhagyva bármelyik összetevőjét, a kulcs elveszti azonosító tulajdonságát. Elvileg egy egyednek több kulcsa is lehet, de a legtöbb esetben egyet szokás kiválasztani, amely a leginkább alkalmas az egyértelmű azonosításra. Ezt hívjuk elsődleges kulcsnak.<br />22<br />
  23. 23. Az egyedi azonosító<br />Az egyedi azonosító egy kiemelt jelentőségű adat, amely a rekordok egyediségét, a rekordra (annak adataira) való egyértelmű hivatkozás lehetőségét biztosítja. Egyedi azonosító ( vagy rövidebben azonosító ) bármilyen adat lehet, amely a fenti feltételt teljesíti. A gyakorlat azonban többnyire az, hogy az adatbázis tervezése, ezen belül az adatállomány tartalmának meghatározása során a Rendszerszervező kialakít egy megfelelő egyedi azonosítót, amely célszerűen biztosítja a rekord egyedi azonosíthatóságát. Az egyedi azonosító bárhol elhelyezkedhet, a rekord adatai között, de célszerű azt az 1. mezőben elhelyezni.<br />Az egyedi azonosító lehet az azonosítandó objektum egy létező adata, amelyet természetes azonosítónak nevezünk és lehet az adatbázist létrehozó szakember által kialakított azonosító kód.<br />Fontos még az azonosító kódok kialakításának módszere. Tulajdonképpen másra nem is kellene figyelni, mint, hogy biztosított legyen az egyediség (nem ismétlődhet) elvének érvényesülése. A számítástechnikai feldolgozhatóság azonban különleges igényekkel lép fel. <br />Ilyenek az azonos hossz, azonos szerkezet, könnyű megjegyezhetőség, a tévesztés lehetőségének kiküszöbölése. A felsorolás sorrendje egyben a fontosság növekedését és a feltétel érvényesítésének bonyolultságát is jelenti.<br />A legegyszerűbb egyedi azonosítás a rekordok sorszámozása, amely sok adatbázis kezelőben automatikusan beépített. Ebben az esetben biztosan nem ismétlődik az azonosító.<br />23<br />
  24. 24. Adatbázis modellek<br />Az adatbázis modellek, a vizsgált rendszer elemeire nézve leírják azok fontos tulajdonságait, összefüggéseit és tartalmukat, valamint meghatározzák felhasználásuk körülményeit. Az adatbázisok logikai adattárolási módszereit értjük Adatbázis modell alatt. Az egyes  modellek, elsősorban az adatkapcsolatok jellegében térnek el.<br />24<br />
  25. 25. Hierarchikus adatbázis modell<br />Gyakorlatilag egy fa struktúráról van szó, ahol a gyökérből (angolul root) kiindulva elágazások, más néven csomópontok sorozatán keresztül jutunk el a tovább már nem elágazó csúcshoz.<br />A Hierarchikus adatmodell jellemzői:<br />csak 1 : N típusú kapcsolat lehetséges az adatbázisban<br />a Fa csomópontja és levelei az adatrekordok<br />alá-fölérendeltségi viszony van a rekordok között<br />az alárendelt ( MEMBER ) rekord csakis egyetlen rekordhoz tartozhat, a Tulajdonosához<br />a fölérendelt ( OWNER ) rekordhoz egy vagy több rekord tartozhat<br />egy közös szempont (pl. a tanulók lakhelye) szerinti lekérdezése vagy csoportosítása, mindig a gyökérből kiindulva és az összes csomóponton áthaladva lehetséges.<br />25<br />
  26. 26. Hálós adatbázis modell<br />Az adatkapcsolatok mellérendelt jellegűek (nincs tulajdonos), lehetséges az  N : M  és nyilván lehetséges ennek különleges esete az  1 : N  típusú kapcsolat is.<br />Példa:<br />1 : N    Osztály   -  Tanulók  adatainak kapcsolata<br />N : M   Diákok    -  Tanárok  adatainak kapcsolata<br />26<br />
  27. 27. Relációs adatbázis modell<br />A legelterjedtebb adatbázis modell, a matematikai halmazelméleten alapul.  A reláció fogalma: adathalmazok Descartes szorzata által létrejött táblázat. A Descartes szorzat két halmaz egyesítése olyan módon, hogy az egyik halmaz minden egyes eleméhez hozzárendeljük a másik halmaz minden elemét. Reláció például a lehetséges összes vezetéknév és a magyar utónevek összerendelésével keletkező személynév halmaz, amely biztosan tartalmazza bármelyik magyar ember nevét.<br />A táblázat nem tartalmazhat két (vagy több) azonos tartalmú sort, a rekordok sorrendje a táblázaton belül tetszőleges, az adatok, vagyis a táblázat oszlopainak sorrendje szintén tetszőleges lehet.<br />A relációs adatbázis tehát egymással meghatározott kapcsolatban álló, táblázatok halmaza. Lényege, hogy az adatok kapcsolata csak logikai szinten kerül meghatározásra, azaz nincs fizikai kapcsolat leírás sem az adatállományokban sem külön állományban.<br />Az adattárolás, táblázatos (sor - oszlop) formában történik, a logikai adatkapcsolat a táblák között, kapcsoló adatelemek, kulcsok segítségével biztosítható.<br />27<br />
  28. 28. Kulcsok a relációs modellben<br />A reláció kulcs a reláció egy sorát azonosítja egyértelműen. A reláció kulcsnak a következő feltételeket kell teljesítenie <br />az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelműség) <br />a kulcsban szereplő attribútumok egyetlen részhalmaza sem alkot kulcsot <br />a kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL) <br />28<br />
  29. 29. Adattípusok<br />karakteres       - betűk, számok, jelek<br />numerikus        - egész és tizedes számok (esetleg normál alakban)<br />dátum              - általában formázható (pl. ÉÉÉÉ/HH/NN vagy  HH/NN/ÉÉ)<br />logikai              - tartalma csak igen/nem illetve igaz/hamis (y/n ill. t/f) lehet<br />kötetlen  vagy bináris    - alkalmas nagyméretű szövegek, képek, térképek tetszőleges állományok bináris formájú tárolására <br />A null érték fogalma<br />Az adatdefiníció során a név, hossz típus mellett tartalmi előírások is hozzárendelhetők az adott tulajdonságtípushoz. ( dátum intervallum, min-max érték, stb.) Jelentősége abban áll, hogy lekérdezések esetén az „üres” tartalom is jelenthet valamit, de ha azért üres mert nem tudtunk még értéket adni az adatnak és ez kizáró ok arra , hogy lekérdezésben szerepeljen, akkor a típusát „null értéknek” kell előírni.<br />29<br />
  30. 30. Redundancia<br />Adatredundancián azt értjük, ha egy adatot egynél több helyen tárolunk egy számítógépes rendszerben. Azt nehéz elkerülni, hogy redundancia egyáltalán ne forduljon elő, azonban a többszörös előfordulások minimálisra csökkentése minden esetben fontos cél. Például ha egy adat több helyen szerepel, és azt módosítjuk, akkor az összes előfordulást módosítani kell. A redundancia kiküszöbölésének szokásos módszere, hogy az adatbázis tervezése során az ismétlődő adatokat „kiemeljük” és külön helyen tároljuk, a megfelelő helyen hivatkozva rá.<br />30<br />
  31. 31. Redundancia megszüntetése példa<br />Eredeti adatok<br />Ismétlődő adatok kiemelése<br />31<br />
  32. 32. Redundancia megszüntetése normál formákkal<br />A logikai tervezés célja egy redundancia mentes reláció rendszer, relációs adatbázis. A reláció elmélet módszereket tartalmaz a redundancia megszüntetésére, az úgynevezett normál formák segítségével. A normál formák képzése során leegyszerűsítve, olyan relációk felírása a cél, melyekben csak a reláció kulcsra vonatkozó tényeket tárolunk. Öt normál formát különböztetünk meg. A különböző normál formák egymásra épülnek, a második normál formában levő reláció első normál formában is van. A tervezés során a legmagasabb normál forma elérése a cél. Az első három normál forma a funkcionális függőségekben található redundanciák, míg a negyedik és ötödik a többértékű függőségekből adódó redundanciák megszüntetésére koncentrál. <br />32<br />
  33. 33. 1. Normál Forma (1NF)<br />Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat.<br />33<br />
  34. 34. Összetett adatú reláció (Szakkörök)<br />Reláció első normál formában (Szakkörök)<br />34<br />
  35. 35. 2. Normál Forma (2NF)<br />1 normál formában van (minden attribútuma egyszerű, nem összetett adat)<br />A reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal<br />35<br />
  36. 36. 1NF reláció (Konferenciák)<br />2NF:<br />Konferenciák<br />Termek<br />36<br />
  37. 37. 3. Normál Forma (3NF)<br />A második normál formájú relációkban nem lehetnek olyan tények, amelyek a reláció kulcs részeihez kapcsolódnak. Azonban ennek ellenére is lehet bennük redundancia, ha olyan tényeket tartalmaznak, amelyek a nem elsődleges attribútumokkal állnak kapcsolatban. Ezt a lehetőséget szünteti meg a harmadik normál forma. Egy reláció harmadik normál formában van, ha <br />A reláció második normál formában van. <br />A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attribútumok között. <br />37<br />
  38. 38. 2NF reláció (szakkörök)<br />3NF:<br />Szakkörök<br />Tanárok<br />38<br />
  39. 39. Boyce/Codd Normál Forma (BCNF)<br />A normál formák tárgyalása során eddig olyan relációkra mutattunk példákat, melyeknek csak egy reláció kulcsa van. A normál formák definíciója természetesen alkalmazható a több kulccsal rendelkező relációkra is. 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. <br />A reláció harmadik normál formában van <br />Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része <br />39<br />
  40. 40. 3NF reláció (Tantárgyak)<br />BCNF:<br />Tantárgyak<br />Tanárok<br />40<br />
  41. 41. Magyarázat:<br />Tételezzük fel, hogy minden tanár csak egy tantárgyat, de annak különböző féléveit oktatja. Ezek alapján a következő funkcionális függőségek írhatók fel: <br />Tanár, Félév -> Tantárgy<br />Tantárgy, Félév -> Tanár <br />A relációnak két kulcsa van, a (Tanár, Időpont, Félév) és a (Tantárgy, Időpont, Félév). A relációban csak egy nem elsődleges attribútum található, a Diák_szám. Ez teljes funkcionális függőségben van mindkét reláció kulccsal, az elsődleges attribútumok között nincs függőségi viszony. Ezek alapján a reláció harmadik normál formában van. Azonban tartalmaz redundanciát, mivel ugyanazon tanár mellett többször is tároljuk a tantárgyat azonos időpontokban. A redundanciának az az oka, hogy a tanár attribútum az őt nem tartalmazó reláció kulcs (Tantárgy, Időpont, Félév) csak egy részétől (Tantárgy, Félév) függ.<br />41<br />
  42. 42. 4. Normál Forma (4NF)<br />Mindeddig csak a funkcionális függőségeket vizsgáltuk, a többértékű függőségeket nem. A további két normál forma a többértékű függőségekből adódó redundancia kiszűrését szolgálja. Egy reláció negyedik normál formában van <br />Harmadik normál formában van és<br />egy X->>Y többértékű függőséget tartalmazó relációban csak az X és Y-ban megtalálható attribútumokat tartalmazza.<br />42<br />
  43. 43. 3NF reláció (Barátok-Hobbik)<br />4NF:<br />Barát<br />Hobbi<br />43<br />
  44. 44. Magyarázat:<br />Képzeljük el azt, hogy egy relációban tároljuk a személyek, és barátaik nevét valamint hobbiját. Minden személynek több barátja és több hobbija is lehet.<br />Az eredeti reláció kulcsa valamennyi attribútumot tartalmazza. Csak egy kulcs van és nincsenek nem elsődleges attribútumok. Ezek alapján a reláció harmadik, sőt Boyce/Codd normál formában van, de mégis tartalmaz redundanciát, ugyanaz a személy-barát illetve személy-hobby kapcsolat többször is szerepelhet. A barát illetve hobby oszlop nem maradhat üres (NULL), mert része a kulcsnak! A reláció két többértékű függőséget tartalmaz: Személy->>Barát és Személy->>Hobbi. A negyedik normál forma szabályait kielégítő két relációra felbontva a redundancia megszüntethető.<br />44<br />
  45. 45. 5. Normál Forma<br />Hosszú ideig a negyedik normál formát tartották a normalizálás utolsó lépésének. A többértékű függőségek külön relációkban tárolásával azonban információt veszthetünk. Ennek bemutatására nézzünk egy példát. Egy számítógépes ismeretek oktatására szakosodott Kft. több jól képzett tanárral rendelkezik. A tanárok többfajta tanfolyam oktatására is alkalmasak. A tanfolyamok az ország különböző részeiben kerülnek megtartásra. Ezek alapján állítsuk össze a Tanár-Tanfolyam-Helyszín relációt. Ebben a relációban csupán azt kívánjuk tárolni, hogy hol és milyen tanfolyamokat tartottak a tanárok, feltételezzük, hogy ugyanazon a helyszínen egyfajta tanfolyam csak egyszer kerül megtartásra.<br />45<br />
  46. 46. Reláció<br />5NF:<br />46<br />
  47. 47. A következő függőségeket írhatjuk fel Tanár->>Tanfolyam Tanár->>Helyszín Tanfolyam->>Helyszín. Az egyetlen reláció kulcs tartalmazza az összes attribútumot (Tanár, Tanfolyam, Helyszín), ebből következik, hogy Boyce/Codd normál formában van a reláció, de mégis tartalmaz redundanciát. Például két sorban is megtalálható, hogy Kiss Pál Adatbázis I. tanfolyamot tanít. A relációt felbontva két - csak egy többértékű függőséget tartalmazó - relációra, (Tanár, Tanfolyam) és (Tanár, Helyszín), a redundancia megszüntetésével információt is vesztünk. A felbontás után már nem tudjuk, hogy a tanár melyik tantárgyát oktatja az adott helyszínen. Például Nagy Éva adatbázis I. vagy adatbázis II. tanfolyamot tart-e Pécsett. Az eredeti relációt három relációra felbontva kapjuk meg az ötödik normál formát. Az eredményül kapott három reláció összekapcsolásával előállítható az eredeti reláció, de bármelyik két reláció összekapcsolása még nem elegendő. <br />Az ötödik normál formának megfelelő felbontás eredményeképpen a tárolandó adatmennyiség megnövekszik, a reláció három táblára bontásával. Általában célszerűbb egy újabb oszlop bevezetésével csak két táblára bontani a relációt. <br />47<br />
  48. 48. VAGY<br />48<br />
  49. 49. Struktúra Generális Mátrix (SGM)<br />A normalizált reláció ábrázolható Struktúra Generális Mátrixban is. A mátrixban a következő jeleket alkalmazzuk: <br />Jelölések:<br /> azonosító<br /> részazonosító<br /><ul><li>leíró tulajdonság</li></ul>Típusok:<br />Cx: Szöveg;hossz<br />N: Szám<br />M:Pénznem<br />D: Dátum[/Idő]<br />L: Logikai<br />49<br />
  50. 50. Példa SGM-re<br />3NF reláció:<br />Táblák: <br />TANULÓ (Tanuló kód, Név, Ir_szám, Út)<br />HELYSÉG (Ir_szám, Város)<br />GYŰJTÖTT TÁRGYAK (Gyűjtött tárgy kódja, Gyűjtött tárgy neve)<br />KI MIT GYŰJT (Tanuló_kód, Gyűjtött tárgy kódja, Db)<br />A táblák közötti kapcsolatok:<br />HELYSÉG (Ir_szám) TANULÓ (Ir_szám) (1:N)<br />TANULÓ (Tanuló kód)  KI MIT GYűJT(Tanuló kód) (1:N)<br />GYŰJTÖTT TÁRGYAK (Gyűjtött tárgy kódja)  KI MIT GYŰJT (Gyűjtött tárgy kódja) (1:N)<br />50<br />
  51. 51. 51<br />
  52. 52. Bachman féle adatszerkezeti diagram<br />Adatszerkezeti diagram: Az egyedek egymáshoz való viszonyainak grafikus ábrázolására használjuk.<br />Jelölések:<br />Egyed<br />52<br />
  53. 53. A kapcsolat mindkét végén kis merőleges szakasz vagy kör szerepelhet, ami a kapcsolat jellegére utal. A vonal a kapcsolat kötelező, a kör a kapcsolat opcionális voltára utal. Azaz a fenti Egyed-kapcsolat diagram azt fejezi ki, hogy minden kapitánynak van hajója és minden hajónak van kapitánya.<br />A fenti kapcsolatban a kör azt fejezi ki, hogy lehetnek olyan kapitányok, akiknek nincsen hajója.<br />Az egy a többhöz kapcsolat esetén is lehetnek kötelező vagy opcionális megjelölések. A fenti kapcsolaton szereplő körök azt fejezik ki, hogy lehetnek munkanélküliek és lehetnek alkalmazott nélküli cégek. A kapcsolaton megjelenhet a kapcsolatot kifejező szöveg.<br />53<br />
  54. 54. A fenti kapcsolat azt fejezi ki, hogy egy járművet több személy vezethet (persze nem egy időben), és egy személy több járművet vezethet. A több a többhöz kapcsolat a legtöbb esetben rejtett egyedet tartalmaz illetve az áttekinthetőséget, értelmezést zavarja. A több a többhöz kapcsolat egy újabb egyed beiktatásával és két egy a többhöz kapcsolattá alakítható át.<br />54<br />
  55. 55. Előfordulhat, hogy egy egyed példányi között áll fent kapcsolat. Ezt rekurzív kapcsolatnak nevezzük. Ilyen lehet például a munkahelyi főnök - beosztott kapcsolat.<br />55<br />
  56. 56. Gyakorlófeladat.<br />Vége az első résznek<br />56<br />

×