SlideShare uma empresa Scribd logo
1 de 56
Adatbázis kezelés 2010.04.12. 1. rész. 1
Az adatbázis fogalma 	Az adatbázis, logikailag összefüggő, meghatározott szerkezetben tárolt adatok halmaza. 2
Adatbázisrendszerek 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. 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.  3
Adatbázis Kezelő Rendszerek 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. 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 4
Az ABKR szolgáltatásai: az adatbázis szerkezetének létrehozása strukturált (meghatározott szerkezetű) adattárolás szabályozott adat karbantartás ( bővítés, módosítás, törlés ) adatrendezés ( adott szempont szerinti sorba állítás ) adatszűrés ( adott szempont szerinti kiválogatás ) szerkesztett lekérdezés ( interaktív és nyomtatott ) egyszerű listázás adat export és import ( kapcsolat más adatbázisokkal ) adatvédelmi eljárások  5
Az ABKR-ek függetlenséget biztosítanak: Az adatkezelés fizikai, azaz hardware lehetőségeitől:  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. 6
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. 7
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. 8
Az ABKR-kel szembeni elvárások: Az adatok definiálása különüljön el az adatkezeléstől, (adatkatalógusban történik) Az adatkatalógus maga is az adatbázis része, az adatokkal azonos módon történjen a feldolgozása  Az adatdefiníciónak, az adatkezelésnek és az adatbiztonságnak legyen programozási nyelve.  Ezen nyelvi eszközök adjanak módot más alkalmazások, programnyelvek számára a hozzáféréshez. (interfész elemek ) 9
Az adatbázisokat kezelő programozási nyelvek tagolódása: 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. 10
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.  11
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. 12
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. 13
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.  14
Adatbázis szerkezet Az adatbázis adatállományok (adatfájlok) halmaz. 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. Az adatállomány logikailag összetartozó adatok meghatározott (előre megtervezett) szerkezetű tárolási formája. Más néven adat file.  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. 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. 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. 15
Videofilmek adatállomány: Ügyfelek adatállomány: 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. 16
Az adatbázis szerkezete tehát az alábbi hierarchikus modellel írható le:ADATBÁZIS  { ADATÁLLOMÁNYOK   { REKORDOK   { MEZŐK } } } Adatbázis Adatállomány Rekord Mező 17
Adatkapcsolatok Az adatbázist, az egymással jól definiált kapcsolatban álló adatállományok alkotják. A kapcsolatok lehetnek: 1  :  1  fokú   kapcsolat 1  :  N fokú   kapcsolat N : M   fokú   kapcsolat 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. 18
1:1 fokú kapcsolat A kapcsolatban mindkét egyedtípus előfordulásai egyetlen egy Férfi Nő HÁZAS 19
1:N fokú kapcsolat 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 Ember Birtokol Autó 20
N:M fokú kapcsolat Mindkét egyedtípus előfordulásai több előfordulással is tarthatják a kapcsolatot Oktató Tanít Tárgyat 21
Kulcs mező 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. 22
Az egyedi azonosító 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. 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. 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.  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. 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ó. 23
Adatbázis modellek 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. 24
Hierarchikus adatbázis modell 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. A Hierarchikus adatmodell jellemzői: csak 1 : N típusú kapcsolat lehetséges az adatbázisban a Fa csomópontja és levelei az adatrekordok alá-fölérendeltségi viszony van a rekordok között az alárendelt ( MEMBER ) rekord csakis egyetlen rekordhoz tartozhat, a Tulajdonosához a fölérendelt ( OWNER ) rekordhoz egy vagy több rekord tartozhat 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. 25
Hálós adatbázis modell 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. Példa: 1 : N    Osztály   -  Tanulók  adatainak kapcsolata N : M   Diákok    -  Tanárok  adatainak kapcsolata 26
Relációs adatbázis modell 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. 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. 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. 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ó. 27
Kulcsok a relációs modellben 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  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)  28
Adattípusok karakteres       - betűk, számok, jelek numerikus        - egész és tizedes számok (esetleg normál alakban) dátum              - általában formázható (pl. ÉÉÉÉ/HH/NN vagy  HH/NN/ÉÉ) logikai              - tartalma csak igen/nem illetve igaz/hamis (y/n ill. t/f) lehet 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  A null érték fogalma 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. 29
Redundancia 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á. 30
Redundancia megszüntetése példa Eredeti adatok Ismétlődő adatok kiemelése 31
Redundancia megszüntetése normál formákkal 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.  32
1. Normál Forma (1NF) Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat. 33
Összetett adatú reláció (Szakkörök) Reláció első normál formában (Szakkörök) 34
2. Normál Forma (2NF) 1 normál formában van (minden attribútuma egyszerű, nem összetett adat) A reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal 35
1NF reláció (Konferenciák) 2NF: Konferenciák Termek 36
3. Normál Forma (3NF) 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  A reláció második normál formában van.  A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attribútumok között.  37
2NF reláció (szakkörök) 3NF: Szakkörök Tanárok 38
Boyce/Codd Normál Forma (BCNF) 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.  A reláció harmadik normál formában van  Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része  39
3NF reláció (Tantárgyak) BCNF: Tantárgyak Tanárok 40
Magyarázat: 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:  Tanár, Félév -> Tantárgy Tantárgy, Félév -> Tanár  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. 41
4. Normál Forma (4NF) 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  Harmadik normál formában van és 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. 42
3NF reláció (Barátok-Hobbik) 4NF: Barát Hobbi 43
Magyarázat: 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. 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ő. 44
5. Normál Forma 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. 45
Reláció 5NF: 46
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ő.  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.  47
VAGY 48
Struktúra Generális Mátrix (SGM) A normalizált reláció ábrázolható Struktúra Generális Mátrixban is. A mátrixban a következő jeleket alkalmazzuk:  Jelölések: 	azonosító 	részazonosító ,[object Object],Típusok: Cx: Szöveg;hossz N:	Szám M:Pénznem D:	Dátum[/Idő] L:	Logikai 49
Példa SGM-re 3NF reláció: Táblák:  TANULÓ (Tanuló kód, Név, Ir_szám, Út) HELYSÉG (Ir_szám, Város) GYŰJTÖTT TÁRGYAK (Gyűjtött tárgy kódja, Gyűjtött tárgy neve) KI MIT GYŰJT (Tanuló_kód, Gyűjtött tárgy kódja, Db) A táblák közötti kapcsolatok: HELYSÉG (Ir_szám)  TANULÓ (Ir_szám) (1:N) TANULÓ (Tanuló kód)  KI MIT GYűJT(Tanuló kód) (1:N) 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) 50
51
Bachman féle adatszerkezeti diagram Adatszerkezeti diagram: Az egyedek egymáshoz való viszonyainak grafikus ábrázolására használjuk. Jelölések: Egyed 52
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. A fenti kapcsolatban a kör azt fejezi ki, hogy lehetnek olyan kapitányok, akiknek nincsen hajója. 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. 53
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. 54
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. 55
Gyakorlófeladat. Vége az első résznek 56

Mais conteúdo relacionado

Mais procurados

ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
제관 이
 
WSO2 ESB Integration with REST
WSO2 ESB Integration with RESTWSO2 ESB Integration with REST
WSO2 ESB Integration with REST
WSO2
 
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
confluent
 

Mais procurados (20)

OAuth 2.0 for Web and Native (Mobile) App Developers
OAuth 2.0 for Web and Native (Mobile) App DevelopersOAuth 2.0 for Web and Native (Mobile) App Developers
OAuth 2.0 for Web and Native (Mobile) App Developers
 
Apache Kafka in the Public Sector (Government, National Security, Citizen Ser...
Apache Kafka in the Public Sector (Government, National Security, Citizen Ser...Apache Kafka in the Public Sector (Government, National Security, Citizen Ser...
Apache Kafka in the Public Sector (Government, National Security, Citizen Ser...
 
ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
ISMS 개발보안, 시큐어코딩을 위한 sonarqube의 활용.건국대학교병원.이제관 기술사
 
WSO2 ESB Integration with REST
WSO2 ESB Integration with RESTWSO2 ESB Integration with REST
WSO2 ESB Integration with REST
 
서버리스 데이터 플로우 개발기 - 김재현 (Superb AI) :: AWS Community Day 2020
서버리스 데이터 플로우 개발기 - 김재현 (Superb AI) :: AWS Community Day 2020서버리스 데이터 플로우 개발기 - 김재현 (Superb AI) :: AWS Community Day 2020
서버리스 데이터 플로우 개발기 - 김재현 (Superb AI) :: AWS Community Day 2020
 
Azure Messaging Services #1
Azure Messaging Services #1Azure Messaging Services #1
Azure Messaging Services #1
 
IBM MQ - better application performance
IBM MQ - better application performanceIBM MQ - better application performance
IBM MQ - better application performance
 
Liferay Portal Introduction
Liferay Portal IntroductionLiferay Portal Introduction
Liferay Portal Introduction
 
Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.
 
MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드MSA ( Microservices Architecture ) 발표 자료 다운로드
MSA ( Microservices Architecture ) 발표 자료 다운로드
 
Protecting your APIs with Doorkeeper and OAuth 2.0
Protecting your APIs with Doorkeeper and OAuth 2.0Protecting your APIs with Doorkeeper and OAuth 2.0
Protecting your APIs with Doorkeeper and OAuth 2.0
 
What is an API Gateway?
What is an API Gateway?What is an API Gateway?
What is an API Gateway?
 
OAuth 2
OAuth 2OAuth 2
OAuth 2
 
OAuth
OAuthOAuth
OAuth
 
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
Using Kafka in Your Organization with Real-Time User Insights for a Customer ...
 
Azure Service Bus
Azure Service BusAzure Service Bus
Azure Service Bus
 
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
 
Processing IoT Data from End to End with MQTT and Apache Kafka
Processing IoT Data from End to End with MQTT and Apache Kafka Processing IoT Data from End to End with MQTT and Apache Kafka
Processing IoT Data from End to End with MQTT and Apache Kafka
 
Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
 

Destaque

Információ és tudásmenedzsment jegyzet 1. rész
Információ és tudásmenedzsment jegyzet 1. részInformáció és tudásmenedzsment jegyzet 1. rész
Információ és tudásmenedzsment jegyzet 1. rész
szszptr
 
MOL Tudásmenedzsment rendszere
MOL Tudásmenedzsment rendszereMOL Tudásmenedzsment rendszere
MOL Tudásmenedzsment rendszere
Eszter Séra
 
Tudásmenedzsment stratégiák
Tudásmenedzsment stratégiákTudásmenedzsment stratégiák
Tudásmenedzsment stratégiák
Péter Fehér
 
Internetkeresők 1resz
Internetkeresők 1reszInternetkeresők 1resz
Internetkeresők 1resz
szszptr
 
Fehér Miklós KSZR prezentációja - 2010.03.30.
Fehér Miklós KSZR prezentációja - 2010.03.30.Fehér Miklós KSZR prezentációja - 2010.03.30.
Fehér Miklós KSZR prezentációja - 2010.03.30.
szszptr
 
Szabó_Dániel_Szakdolgozat
Szabó_Dániel_SzakdolgozatSzabó_Dániel_Szakdolgozat
Szabó_Dániel_Szakdolgozat
Dániel Szabó
 
Bővített m otp_120131_bev+zaro_dizajnos
Bővített m otp_120131_bev+zaro_dizajnosBővített m otp_120131_bev+zaro_dizajnos
Bővített m otp_120131_bev+zaro_dizajnos
Eszter Séra
 
Knowledge Management Presentation
Knowledge Management PresentationKnowledge Management Presentation
Knowledge Management Presentation
kreaume
 
Knowledge management
Knowledge managementKnowledge management
Knowledge management
Sehar Abbas
 

Destaque (16)

Információ és tudásmenedzsment jegyzet 1. rész
Információ és tudásmenedzsment jegyzet 1. részInformáció és tudásmenedzsment jegyzet 1. rész
Információ és tudásmenedzsment jegyzet 1. rész
 
MOL Tudásmenedzsment rendszere
MOL Tudásmenedzsment rendszereMOL Tudásmenedzsment rendszere
MOL Tudásmenedzsment rendszere
 
Tudásmenedzsment stratégiák
Tudásmenedzsment stratégiákTudásmenedzsment stratégiák
Tudásmenedzsment stratégiák
 
Internetkeresők 1resz
Internetkeresők 1reszInternetkeresők 1resz
Internetkeresők 1resz
 
Fehér Miklós KSZR prezentációja - 2010.03.30.
Fehér Miklós KSZR prezentációja - 2010.03.30.Fehér Miklós KSZR prezentációja - 2010.03.30.
Fehér Miklós KSZR prezentációja - 2010.03.30.
 
Knowledge only real when shared
Knowledge only real when sharedKnowledge only real when shared
Knowledge only real when shared
 
How to establish and maintain a Commnunity if Practice
How to establish and maintain a Commnunity if PracticeHow to establish and maintain a Commnunity if Practice
How to establish and maintain a Commnunity if Practice
 
Szabó_Dániel_Szakdolgozat
Szabó_Dániel_SzakdolgozatSzabó_Dániel_Szakdolgozat
Szabó_Dániel_Szakdolgozat
 
Bővített m otp_120131_bev+zaro_dizajnos
Bővített m otp_120131_bev+zaro_dizajnosBővített m otp_120131_bev+zaro_dizajnos
Bővített m otp_120131_bev+zaro_dizajnos
 
Tudásmenedzsment és tudástípusok
Tudásmenedzsment és tudástípusokTudásmenedzsment és tudástípusok
Tudásmenedzsment és tudástípusok
 
Knowledge Worker 2.0 - Power to the people
Knowledge Worker 2.0 - Power to the peopleKnowledge Worker 2.0 - Power to the people
Knowledge Worker 2.0 - Power to the people
 
Communities of practice presentation
Communities of practice presentationCommunities of practice presentation
Communities of practice presentation
 
Creating strong & passionate agile communities of practice
Creating strong & passionate agile communities of practiceCreating strong & passionate agile communities of practice
Creating strong & passionate agile communities of practice
 
Communities of Practice: Conversations To Collaboration
Communities of Practice: Conversations To CollaborationCommunities of Practice: Conversations To Collaboration
Communities of Practice: Conversations To Collaboration
 
Knowledge Management Presentation
Knowledge Management PresentationKnowledge Management Presentation
Knowledge Management Presentation
 
Knowledge management
Knowledge managementKnowledge management
Knowledge management
 

Semelhante a Adatbázis kezelés (6)

Adatbanyaszati technologiak
Adatbanyaszati technologiakAdatbanyaszati technologiak
Adatbanyaszati technologiak
 
Adatbányászat
AdatbányászatAdatbányászat
Adatbányászat
 
Szakmódszertani gyakorlat - vizsgatanítás prezentáció.
Szakmódszertani gyakorlat - vizsgatanítás prezentáció.Szakmódszertani gyakorlat - vizsgatanítás prezentáció.
Szakmódszertani gyakorlat - vizsgatanítás prezentáció.
 
Microsoft Windows Azure Platform
Microsoft Windows Azure PlatformMicrosoft Windows Azure Platform
Microsoft Windows Azure Platform
 
Adatbazis
AdatbazisAdatbazis
Adatbazis
 
It3 4 2 1 2 1
It3 4 2 1 2 1It3 4 2 1 2 1
It3 4 2 1 2 1
 

Adatbázis kezelés

  • 2. Az adatbázis fogalma Az adatbázis, logikailag összefüggő, meghatározott szerkezetben tárolt adatok halmaza. 2
  • 3. Adatbázisrendszerek 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. 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. 3
  • 4. Adatbázis Kezelő Rendszerek 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. 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 4
  • 5. Az ABKR szolgáltatásai: az adatbázis szerkezetének létrehozása strukturált (meghatározott szerkezetű) adattárolás szabályozott adat karbantartás ( bővítés, módosítás, törlés ) adatrendezés ( adott szempont szerinti sorba állítás ) adatszűrés ( adott szempont szerinti kiválogatás ) szerkesztett lekérdezés ( interaktív és nyomtatott ) egyszerű listázás adat export és import ( kapcsolat más adatbázisokkal ) adatvédelmi eljárások 5
  • 6. Az ABKR-ek függetlenséget biztosítanak: Az adatkezelés fizikai, azaz hardware lehetőségeitől: 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. 6
  • 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. 7
  • 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. 8
  • 9. Az ABKR-kel szembeni elvárások: Az adatok definiálása különüljön el az adatkezeléstől, (adatkatalógusban történik) Az adatkatalógus maga is az adatbázis része, az adatokkal azonos módon történjen a feldolgozása Az adatdefiníciónak, az adatkezelésnek és az adatbiztonságnak legyen programozási nyelve. Ezen nyelvi eszközök adjanak módot más alkalmazások, programnyelvek számára a hozzáféréshez. (interfész elemek ) 9
  • 10. Az adatbázisokat kezelő programozási nyelvek tagolódása: 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. 10
  • 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. 11
  • 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. 12
  • 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. 13
  • 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. 14
  • 15. Adatbázis szerkezet Az adatbázis adatállományok (adatfájlok) halmaz. 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. Az adatállomány logikailag összetartozó adatok meghatározott (előre megtervezett) szerkezetű tárolási formája. Más néven adat file. 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. 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. 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. 15
  • 16. Videofilmek adatállomány: Ügyfelek adatállomány: 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. 16
  • 17. Az adatbázis szerkezete tehát az alábbi hierarchikus modellel írható le:ADATBÁZIS  { ADATÁLLOMÁNYOK   { REKORDOK   { MEZŐK } } } Adatbázis Adatállomány Rekord Mező 17
  • 18. Adatkapcsolatok Az adatbázist, az egymással jól definiált kapcsolatban álló adatállományok alkotják. A kapcsolatok lehetnek: 1  :  1  fokú   kapcsolat 1  :  N fokú   kapcsolat N : M   fokú   kapcsolat 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. 18
  • 19. 1:1 fokú kapcsolat A kapcsolatban mindkét egyedtípus előfordulásai egyetlen egy Férfi Nő HÁZAS 19
  • 20. 1:N fokú kapcsolat 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 Ember Birtokol Autó 20
  • 21. N:M fokú kapcsolat Mindkét egyedtípus előfordulásai több előfordulással is tarthatják a kapcsolatot Oktató Tanít Tárgyat 21
  • 22. Kulcs mező 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. 22
  • 23. Az egyedi azonosító 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. 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. 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. 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. 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ó. 23
  • 24. Adatbázis modellek 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. 24
  • 25. Hierarchikus adatbázis modell 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. A Hierarchikus adatmodell jellemzői: csak 1 : N típusú kapcsolat lehetséges az adatbázisban a Fa csomópontja és levelei az adatrekordok alá-fölérendeltségi viszony van a rekordok között az alárendelt ( MEMBER ) rekord csakis egyetlen rekordhoz tartozhat, a Tulajdonosához a fölérendelt ( OWNER ) rekordhoz egy vagy több rekord tartozhat 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. 25
  • 26. Hálós adatbázis modell 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. Példa: 1 : N    Osztály   -  Tanulók  adatainak kapcsolata N : M   Diákok    -  Tanárok  adatainak kapcsolata 26
  • 27. Relációs adatbázis modell 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. 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. 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. 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ó. 27
  • 28. Kulcsok a relációs modellben 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 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) 28
  • 29. Adattípusok karakteres       - betűk, számok, jelek numerikus        - egész és tizedes számok (esetleg normál alakban) dátum              - általában formázható (pl. ÉÉÉÉ/HH/NN vagy  HH/NN/ÉÉ) logikai              - tartalma csak igen/nem illetve igaz/hamis (y/n ill. t/f) lehet 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 A null érték fogalma 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. 29
  • 30. Redundancia 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á. 30
  • 31. Redundancia megszüntetése példa Eredeti adatok Ismétlődő adatok kiemelése 31
  • 32. Redundancia megszüntetése normál formákkal 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. 32
  • 33. 1. Normál Forma (1NF) Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat. 33
  • 34. Összetett adatú reláció (Szakkörök) Reláció első normál formában (Szakkörök) 34
  • 35. 2. Normál Forma (2NF) 1 normál formában van (minden attribútuma egyszerű, nem összetett adat) A reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal 35
  • 36. 1NF reláció (Konferenciák) 2NF: Konferenciák Termek 36
  • 37. 3. Normál Forma (3NF) 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 A reláció második normál formában van. A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attribútumok között. 37
  • 38. 2NF reláció (szakkörök) 3NF: Szakkörök Tanárok 38
  • 39. Boyce/Codd Normál Forma (BCNF) 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. A reláció harmadik normál formában van Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része 39
  • 40. 3NF reláció (Tantárgyak) BCNF: Tantárgyak Tanárok 40
  • 41. Magyarázat: 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: Tanár, Félév -> Tantárgy Tantárgy, Félév -> Tanár 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. 41
  • 42. 4. Normál Forma (4NF) 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 Harmadik normál formában van és 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. 42
  • 43. 3NF reláció (Barátok-Hobbik) 4NF: Barát Hobbi 43
  • 44. Magyarázat: 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. 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ő. 44
  • 45. 5. Normál Forma 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. 45
  • 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ő. 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. 47
  • 49.
  • 50. Példa SGM-re 3NF reláció: Táblák: TANULÓ (Tanuló kód, Név, Ir_szám, Út) HELYSÉG (Ir_szám, Város) GYŰJTÖTT TÁRGYAK (Gyűjtött tárgy kódja, Gyűjtött tárgy neve) KI MIT GYŰJT (Tanuló_kód, Gyűjtött tárgy kódja, Db) A táblák közötti kapcsolatok: HELYSÉG (Ir_szám) TANULÓ (Ir_szám) (1:N) TANULÓ (Tanuló kód)  KI MIT GYűJT(Tanuló kód) (1:N) 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) 50
  • 51. 51
  • 52. Bachman féle adatszerkezeti diagram Adatszerkezeti diagram: Az egyedek egymáshoz való viszonyainak grafikus ábrázolására használjuk. Jelölések: Egyed 52
  • 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. A fenti kapcsolatban a kör azt fejezi ki, hogy lehetnek olyan kapitányok, akiknek nincsen hajója. 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. 53
  • 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. 54
  • 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. 55
  • 56. Gyakorlófeladat. Vége az első résznek 56