Adatbáziskezelés és Adatbázis szervezés Jegyzet Fábián Zoltán 2007
1 Bevezetés 5 1.1 Adatbázis fogalma 5 1.2 Történelmi áttekintés 5 2 Miről beszélünk, azaz általános definíciók? 6 2.1 Adat, információ 6 2.2 A Shannon féle információs elmélet 6 2.3 Az adatok tulajdonságai 7 2.4 Az adatfeldolgozás formalizálható 7 2.5 Az adatok osztályozása funkciójuk szerint 7 2.6 Az adatszerkezetek fajtái 7 2.7 Az adatok között kapcsolatok 7 2.8 Adatmodellek története röviden 8 3 Adatbáziskezelő rendszerek és feladataik 9 3.1 Adatbázis-kezelők elemei 9 3.2 A file-kezelő 9 3.3 A lekérdező nyelv 9 3.4 Adatbáziskezelőkben ellátott segédfeladatok 9 3.5 Adatbázis statisztikák 9 3.6 Az adatbázis adminisztrátor 10 3.7 A 4GL-ek 10 3.8 Integrált CASE eszközök 10 3.9 Az ANSI/SPARC modell 10 3.10 Logikai, fizikai szerkezet 11 3.11 A programok és az adatok függetlensége 11 3.12 Az adatbázis életciklusa 11 3.13 Objektum-orientált adatbázisok 12 4 Az adatmodellek a logikai séma 13 4.1 Az egyed fogalma 13 4.2 A rekordtípus 13 4.3 A tulajdonság fogalma, Azonosítók 13 4.4 Kulcs 13 4.5 Többértékű vagy összetett tulajdonságok 13 4.6 A kapcsolat fogalma 13 4.7 A kapcsolat fokai 14 4.8 A kapcsolatok fajtái 14 4.9 A kardinalitás 14 4.10 A belső szerkezete, belső tulajdonságai 14 4.11 Az egyed külső tulajdonságai 14 4.12 A settipus fogalma 14 4.13 A kapcsolatok ábrázolásának különféle módjai 15 4.14 Egyed-szupertípus, egyed-altípus 15 2
4.15 Aggregáció 15 5 Az adatmodellek és az adatbázisok 16 5.1 Az adatmodell fogalma 16 5.2 A hálós adatmodell 16 5.3 A hierarchikus adatmodell 16 5.4 A relációs adatmodell 16 5.5 Reláció definíciója 17 5.6 Reláció, tábla, adatbázis 17 5.7 Egyedtípus és reláció kapcsolata 17 6 A relációs adatbázis belső szerkezete 19 6.1 A funkcionális függőség - Adatok közötti funkcionális kapcsolat 19 6.1.1 Teljes funkcionális függőség... 19 6.1.2 Adatok közötti többértékű függőség... 20 6.2 Reláció kulcs fogalma 20 6.3 A külső kulcs 21 6.3.1 Külső kulcs ugyanabban a táblában (Rekurzív kapcsolat)... 21 6.3.2 Külső kulcs párhuzamos kapcsolatban... 21 6.3.3 Külső kulcs egy-egy típusú kapcsolatban... 21 6.3.4 Generátorhalmaz:... 21 6.4 Redundancia fogalma 21 6.5 Normálformák a redundancia megszűntetése 22 6.5.1 Első normál forma (1NF)... 22 6.5.2 Második normál forma (2NF)... 23 6.5.3 Harmadik normál forma (3NF)... 23 6.5.4 Boyce/Codd normál forma (BCNF)... 24 6.5.5 Negyedik normál forma (4NF)... 24 6.6 Anomáliák az adatbázisban 24 6.6.1 Módosítási anomália... 25 6.6.2 Törlési anomália... 25 6.6.3 Bővítési anomália... 25 6.6.4 Inkonzisztencia... 25 6.6.5 Tranzakció... 25 6.7 Az adatmodell időfüggvényének szerepe az adatmodell kialakításában. 25 6.8 Metaadatok tárolása az adatbázisokban 25 6.9 Fizikai tervezés 26 6.9.1 Indexek fogalma és felépítése... 26 6.9.2 Hash kódok... 26 6.9.3 A hash kód kulcsütközés kezelése... 26 6.9.4 Bináris fa... 27 6.9.5 Asszociatív rendszerek... 27 6.9.6 A hálózati adatkezelés problémái... 27 6.9.7 Tervezés a feldolgozási módok szerint... 28 3
6.9.8 Szinkronizálási módszerek... 28 6.9.9 Hálózati, adatbázisokkal kapcsolatos biztonsági kérdések... 29 7 Adatbázis-kezelőkben alkalmazható adattípusok 31 8 Az adatbázis- rendszer dokumentálása 33 9 Az SQL lekérdező nyelv 34 9.1 Az SQL története, általános tulajdonágai 34 9.2 Az adatdefiniciós nyelv 35 9.2.1 Adattípusok az SQL-ben... 35 9.2.2 Adattípusok a MySql-ben... 35 9.2.3 Speciális adattípusok a Microsoft Accesben... 36 9.2.4 Adatdefiníáló utasítások Táblák létrehozása... 37 9.2.5 Táblák módosítása... 38 9.2.6 Teljes táblák törlése... 38 9.2.7 Nézettáblák létrehozása, módosítása, törlése... 38 9.2.8 Indexek létrehozása... 39 9.2.9 Az indexek megszüntetése... 39 9.3 Az adatmanipulációs nyelv 39 9.3.1 Új sorok beszúrása... 39 9.3.2 A mezők tartalmának módosítása... 40 9.3.3 Sorok törlése... 40 9.4 A lekérdező nyelv 41 9.4.1 Az eredményhalmaz szűkítése WHERE feltétel... 41 9.4.2 Halmaz műveletek SQL-ben... 48 9.5 Egyéb SQL parancsok 49 9.5.1 Tranzakciókezelés... 49 9.5.2 Jogosultság kezelés... 49 9.5.3 Tárolt eljárások (MySQL 5.x.x-től)... 50 9.5.4 Triggerek... 55 10 Függelék 56 4
1 evezetés Az adatbáziskezelés és szervezés tantárgy keretén belül az adatbázis tervezés elméletét, a relációs algebra alapjait, illetve a relációs adatbáziskezelők lekérdező nyelvét (SQL) ismertetjük. Az SQL esetén megismerkedünk az ASNI SQL 92 alapjaival, illetve alkalmanként a MySQL és a Microsoft Access specialitásaival is. Nem beszélünk az Access kezeléséről és nem beszélünk a MySql kezeléséről sem. Ezeket a tudnivalókat a kedves olvasó más kiadványokból vagy a gyakorlatban sajátíthatja el. A jegyzet belső használatra, a Szily Kálmán Műszaki Középiskola diákjkai számára készült, de az internetről szabadon letölthető és tovább felhasználható. Jelen állapotában ideiglenes jegyzet, mely tovább formálódik. Az adatbáziskezelés és szervezés tantárgy keretén belül az adatokkal kapcsolatos alapfogalmakat, az adatok leírásának alapfogalmait, adatbázis tervezés elméletét, a relációs algebra alapjait, illetve a relációs adatbáziskezelők lekérdező nyelvét (SQL) és az ACCESS adatbáziskezelő használatát (a teljesség igénye nélkül) ismertetjük. 1.1 Adatbázis fogalma Adatbázison 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. Képzeljük el, hogy egy céghez naponta átlagban 20 levél érkezik. A cég irattárosa kellő adattárolási tapasztalat híján a leveleket az irattár ajtajára vágott lyukon keresztül bedobja. Elképzelhető, hogy pár év eltelte után milyen reménytelen vállalkozás egy levelet megtalálni az irattárban. Ez az adathalmaz nem tekinthető adatbázisnak, ahhoz hogy adatbázis legyen nem elegendő a nagyszámú adat. Az adathalmaz csak akkor válik adatbázissá, ha az valamilyen rend szerint épül fel, mely lehetővé teszi az adatok értelmes kezelését. Természetesen ugyanazon adathalmazból többféle rendszerezés alapján alakíthatunk ki adatbázist. Például egy könyvtárban a könyveket rendezhetnénk a könyvek mérete vagy akár a szerző vagy szerzők testsúlya alapján. Ez már egy rendszert ad az adatok tárolásához. Íly módon minden könyv helye meghatározott. De bizonyára nehéz helyzetben lennénk, ha szerző és cím alapján próbálnánk meg előkeresni egy könyvet. Az adatok tárolásába bevitt rendszernek alkalmasnak kell lennie a leggyakrabban előforduló igények hatékony kielégítésére. Az adatbázisok mellé egy adatbázis-kezelő rendszer (DBMS) is járul, mely az adatbázis vagy adatbázisok üzemeltetését biztosítja. Hagyományos adatbázis esetén ez a kezelő személyzet intelligenciájának része, elektronikus adatbázisok esetén pedig valamilyen szoftver. 1.2 Történelmi áttekintés Azóta rendelkezünk adatbázisokkal, mióta írásban vagyunk képesek rögzíteni adatokat. Ez az ókorban történhetett akár kőtáblákra vagy papirusz tekercsekre. Az adatbázisok fejlettebb formái később a kartoték rendszerek lettek, melyek a számítógépek megjelenéséig az alapvető adatbázis rendszerek voltak. A számítástechnika hőskorában az 50-es 60-as években az adatok tárolása még lyukszalagon, lyukkártyán történt, az adatok közvetlenül nem voltak elérhetők a számítógép számára. A mágneses háttértárolók elterjedésével az adatok tárolása egyszerűbbé, elérésük hatékonyabbá vált. Ezekben az időkben még nem léteztek univerzális módszerek illetve rendszerek, melyek segítségével az adatbázisokkal kapcsolatos problémák nagy része általánosan megoldható lett volna. A számítógépek fejlődésével együtt fejlődtek a programozói lehetőségek is. Az első számítógépeken csak a gépi kód (a bináris formában kiadott utasítások a mikroprocesszornak) állt rendelkezésre. Ezt első generációs programnyelvnek nevezzük. Ezt követték a második generációs (assembler) nyelvek, melyekben a gépi kód helyett úgynevezett mnemonikok és szimbólumok alkalmazhatók. Az első illetve második generációs programnyelvekben még nem észültek komoly adatbáziskezelő alkalmazások. Ezekre egyrészt a magas szintű nyelvek (3. generációs program nyelvek) COBOL, FORTRAN stb., másrészről a lemezes operációs rendszerek kialakulásáig kellett várni. Ekkor már komoly adatbázis alkalmazások születtek, melyek egyedi problémák megoldására voltak alkalmasak. Az adatbázisok méretének és számának gyors növekedése következtében az egyedi alkalmazások létrehozása fárasztó és időrabló feladattá vált, ezért a programfejlesztők törekedtek az adatbáziskezelés általános formában történő megfogalmazására. Ennek eredményeként jöttek létre az adatbázis kezelő rendszerek és a negyedik generációs nyelvek (4GL). Az adatbázis kezelő rendszerek számos eszközt nyújtanak az interaktiv adatbevitel, menük létrehozása terén, melyek kialakítása a harmadik generációs nyelvekben sok sok oldal kód leírásával lenne csak lehetséges. A szabványos eszközök bevezetésével nem csak a programozói munka csökkent le, hanem az egységes felhasználói felület kialakítására késztetik a programozókat. 5
2 Miről beszélünk, azaz általános definíciók? 2.1 Adat, információ Az eltelt több mint 30 évben nagy terminológiai viták folytak az adatfeldolgozással kapcsolatban. Volt idő amikor az volt a felfogás, hogy az adat- feldolgozás (data processing) helyett információfeldolgozást (information processing) célszerűbb mondani és információs rendszerekről beszéltünk. Ennek megfelelően megkísérelték megadni az adat és az információ definícióját. Felesleges erőfeszítés és talán nem is lehet az adat fogalmát matematikai precízséggel definiálni, mint ahogy nem definiáljuk a halmazt, a teret stb sem. Elfogadhatjuk, hogy a valóságos világ minden objektumához, jelenségéhez tartozhat egy sor olyan "jellemző", paraméter, "adat" ami számokkal, betűkombinációkkal, tehát szöveggel vagy akármilyen jellel, jelsorozattal, jelenséggel, mozgással, stb. kifejezve megadható Az információ fogalmát már fontosabb definiálni, de a létező definíciók nem túl meggyőzőek. Mindenesetre az információt célszerű megkülönböztetni az adattól. Egy adat egyik ember számára jelent valamit a másik számára nem. Vannak irányzatok, amelyek azt javasolják, hogy a felhasználható, vagy hasznos adatot nevezzük információnak. Mások azt mondják az információ olyan adat, ami döntés megtételére alkalmas. Az információ tehát több mint adat, és az információt adatok hordozzák, az információt adatokkal adjuk meg. Az információ mint világunk harmadik fő attribútuma Noha az információ fogalmát pontosan nem tudjuk definiálni, érezzük, tudjuk, hogy az anyag és az energia mellett a valóságos világ egy harmadik nagyon fontos jellemzője, dolga, attribútuma. Információról beszélünk akkor, amikor adatfeldolgozást végzünk. Információ a tárgya a híradástechnikának. Információ a tárgya a folyamatok vezérlésének. Információ megy, adódik át a természetes nyelvekben. A biológiai kommunikációs rendszerekben is információ-feldolgozás történik például magában a sejtben, az élővilág minden egyedének minden sejtjében. Pontos definíciót nem adunk, számok szövegek, speciális jeleket értünk rajtuk. 2.2 A Shannon féle információs elmélet Az első kísérlet az információ fogalmának megalkotására C.E. Shannon nevéhez fűződik aki 1948-ban megjelent. "A kommunikáció matematikai elmélete" című munkájában vizsgálta, kísérelte megadni az információ fogalmát. Azt mondhatjuk, hogy Shannon alapozta meg az információelmélet tudományát. Shannon elméletének a lényege az; hogy az információt jelek, adatok hordozzák. Pontosan ugyan nem adta meg, hogy mi is az információ amit ezek a jelek hordoznak, de megkísérelte mérni ennek az információnak a nagyságát, tehát egy mértéket próbált definiálni az információra. Shannon úgy gondolta, hogy egy jel akkor hordoz nagyobb információt, hogy ha ezen jel megjelenésének a váratlansága nagyobb. Shannon szerint tehát ha egy jel kisebb valószínűséggel jelenik meg valahol, akkor nagyobb információt hordoz. E filozófiát követve Shannon egy képletet adott meg egy jelsorozat által hordozott információ nagyságára, amiről kiderítették, hogy ez voltaképpen, teljesen egybeesik az energiával kapcsolatos u.n. entrópia megadására szolgáló képlettel, úgy hogy sokan éppen emiatt egymás mellé állítják, közös tulajdonságúnak tekintik az energiát és az információt. A Shannon féle információelmélet nem foglalkozik az információ tartalmával. Nem foglalkozik azzal, hogy egy szöveg értelmes, fölfogható, helyes, vagy éppen helytelen, vagy értelmetlen. Ezen elmélet szerint több információt hordoz egy véletlenszerűen összedobott betűkombináció, mint egy azonos hosszúságú de nyelvileg, tartalmilag érdekes szöveg. A Shannon féle elmélettel nagyon jól leírható ezen elmélet alapján a híradástechnika, átviteltechnika számos problémája, illetve az információtárolás néhány feladata is jól megfogható ezen elmélet segítségével. Számos próbálkozás történt az információ szemantikai definíciójára, egy olyan definíció megadására, amely az információ tartalma szerint adna lehetőséget arra, hogy mérjük, melyik jelsorozatnak, melyik közleménynek van nagyobb információtartalma. A Shannon féle információelméletben az információhoz voltaképpen egy bitsorozatot rendeltek hozzá és azt mondták, hogy egy információ mennyisége annál nagyobb, minél több bitből áll, minél több bittel adható meg, vagyis a bitek száma adta meg az információ nagyságát. Nyilvánvaló, hogy ennek az információ tartalmához nincs sok köze. Ez ideig nem sikerült az információra olyan definíciót adni, amelynek a segítségével minden területen tudnánk vizsgálni az információ nagyságát, a hordozhatóság tulajdonságait, a feldolgozás egzakt szabályait. Elfogadjuk, hogy létezik egy ilyen dolga a világnak, elfogadjuk, hogy ugyanúgy, mint ahogy az anyag energiát tud hordozni képes arra is, hogy információt hordozzon, információt közvetítsen. Elfogadjuk, hogy mint ahogy az energiát fel lehet dolgozni, át lehet alakítani, hasonlóan az információfeldolgozás is egy "valóságos" dolgon történik. 6
Úgy vesszük tehát, hogy az információt adatok hordozzák, és ennek megfelelően amikor adatfeldolgozást végzünk, voltaképpen információfeldolgozás történik. Különösen igaz ez az adatbázisok tekintetében. Maga az adatbázis vagy az adatbázisok információkat hordoznak, és az adatbázisból való lekérdezésekkel voltaképpen új információkhoz jutunk, az adatbázisban lévő elemi információkból összetett információt hozunk létre. Ha az adatbázist erre a célra létrehozott speciális eljárásokkal, algoritmusokkal dolgozzuk fel, akkor az adatbázist un. tudásbázisnak tekinthetjük (ez a tárgya az un. szakértői rendszereknek). 2.3 Az adatok tulajdonságai A 60-as évek elején a számítógépek alkalmazásának nagyobbik részét az ún. adatfeldolgozás tette ki. A programozók rájöttek, hogy az adatokat és azok kapcsolódásait matematikai struktúrákkal lehet leírni, a feladatok megoldására pedig algoritmusok használhatók. 2.4 Az adatfeldolgozás formalizálható Az adatfeldolgozás jobban "gépesíthető", ha az adatok közötti kapcsolatokat struktúrának tekintjük és adatmodellekben, adatsémákban gondolkodunk. Ez lehetővé teszi az egységes kezelést, olyan nyelvek kialakítását, amelyekkel szabványosan kezelhetők a tartalmuk szempontjából teljesen eltérő adathalmazok is. Az olyan adathalmazokat, amelyeket modellbe foglalva kezeltek, adatbankoknak, később pedig adatbázisoknak nevezték el. 2.5 Az adatok osztályozása funkciójuk szerint Felhasználói információhordozó alatt a felhasználót ténylegesen érdeklő adatokat értjük. Szerkezethordozó adatról beszélünk, ha az információ tárolásához szükséges elengedhetetlen adatokat tekintjük. Ilyenek lehetnek például mutatók, indexek, egyéb jelölő és vezérlő (törlés jelző, rekordhossz jelző, állapotjelző, termináló és termináló jelek) 2.6 Az adatszerkezetek fajtái Bár ezt a témát a szerző Módszeres programozás jegyzetében korábban már körüljártuk, de itt mégegyszer röviden áttekintjük a kérdést: Egyszerű adatszerkezetről beszélünk, ha az adat egy fajta értéket tartalmaz. Ilyen lehet például egy szám, karakter, logikai érték, dátum, stb... Az így kezelt adatokat csak egyesével, egymástól független módon tudjuk kezelni, elérni. Összetett adatszerkezetről beszélünk, ha az adatokat valamiféle struktúrába illesztjük. Az így keletkezett adatstruktúrát egységesen tudjuk kezelni, elérni. Ezekre példa, az egy-, és két dimenziós tömb, rekord, láncolt adatszerkezet, pédlául a lista (egy és kétirányú, vagy gyűrűs). Filekezelés kapcsán említhetjük meg a soros vagy szekvenciális filekezelést (például Pascal text file), Direkt filekezelést amikor a file-ban lévő adat fizikai helyére hivatkozunk Random file-ok, amikor a file tetszőleges rekordját elérjük, Index-szekvenciális, amikor a helyes elérési sorrendet indexek segítségével határozzuk meg, stb. Master vagy struktúrafile-ról beszélünk, amikor egy fileban tárojuk egy adatfile tartalmának leíróját és segítségével tudjuk kezelni az állományt. 2.7 Az adatok között kapcsolatok Adatbázison voltaképpen adatoknak kapcsolataikkal együtt va1ó ábrázolását, tárolását értjük. Annak, hogy egy konkrét adatrendszert egy megadott szerkezetű adatbázisba foglalnak egybe, nagyon nagy előnye, hogy egyszerre sokan használhatják. Maguk az adatok csak "egyszeresen" vannak tárolva, a közöttük lévő kapcsolatok (az adatrendszer struktúrája) ismerete mégis lehetővé teszi, hogy a felhasználók egymástól függetlenül hozzáférjenek szinte úgy, hogy ki-ki "kiszakít" magának egy részt (nem fizikailag); vagy átszerkeszti az adathalmaz egy részét a maga számára (ezt az angol view szóból felhasználói nézetnek nevezzük). Az adatbázisok tehát "többfelhasználós" adathalmazok. Az adatbázis szemléletben az adatokat egy sémába 'foglaljuk bele"; ezt központilag tervezzük meg és ha ezt jól végezzük el, akkor minden adatérték csak egyszer szerepel a rendszerben, ráadásul egységes formátumban és így séma az "kompatibilisek" az adatok. adatbázis Az adatbázis-séma a valóság egy részének tükörképe Az adatbázis-sémát úgy tekintjük, mint a valóságos világ egy olyan adatmodelljét, amely az adott szervezet szempontjából érdekes. Azok az objektumok (később ezeket egyedeknek, vagy egyedtípusoknak hívjuk) amelyek kapcsolatban vannak egymással a valóságos világban; az adatbázisban is kapcsolatban lesznek, tehát az adatbázisban a kapcsolatok is tükröződnek. kövei. Természetesen a valós világ egy adott részéhez nem csak egy adatbázis-séma rendelhető. 7
2.8 Adatmodellek története röviden Adatbázisok modelljéül szolgáló struktúra kidolgozására számos próbálkozás történt. Ezek a próbálkozások az alábbi három irány körül csoportosultak. Formalista megközelítés. Ezen irányzat képviselői gráfokkal, diagramokkal kísérelték meg felírni az adatok közötti kapcsolatot, a szerkeze- tet (Bachmann, Nijssen, Sowa, stb. modelljei). Egy kis erőltetéssel azt mondhatjuk, hogy ezek a később elterjedt hierarchikus illetve hálós adatmodell alapjait képezték A szemantikai megközelítés lényege az volt, hogy a modellt teljesen verbálisan, szavak segítségével kísérelték meg leírni. Ez a modellfajta teljesen életképtelen volt, mert nehéz volt olyan programokat írni, amelyek tudták volna kezelni a nem teljesen precízen megadott adatbázisokat. A matematikai jellegű modellekben az adatok közötti kapcsolatot szintaktikusan pontosan, matematikai struktúrák felhasználásával írták le. Több egymástól eltérő felfogásban próbálkoztak, leginkább Codd relációs adatmodellje (1970) látszott életképesnek, de azt senki sem gondolta, hogy a század végére az adatbáziskezelő rendszerek nagy része a Codd féle modellre támaszkodik. 8
3 Adatbáziskezelő rendszerek és feladataik Az adatbázis önmagában semmit sem ér. A felhasználó számára akkor válik értékké, ha megadunk hozzá egy olyan szoftvert (programnyelvet), amellyel az adatbázist kezelni tudjuk. Az ilyen szoftver nagyon bonyolult, általában több elemből álló rendszert képez. Ezt a szoftvert adatbáziskezelő rendszernek hívjuk. Az adatbázisokkal lényegében két fontos műveletet kell elvégezni, nevezetesen az adatbázis létrehozását (az adatbázis szerkezetének definiálását és a szerkezet feltöltését konkrét adatokkal, illetve ezek módosítását, törlését), valamint az adatok visszakeresését, lekérdezését az adatbázisból. Ennek megfelelően az adatbáziskezelő rendszereknek (DBMS=DataBase Management System) is két fő funkciójuk van: az adatdefiníció ill. a lekérdezés. 3.1 Adatbázis-kezelők elemei 3.2 A file-kezelő Az adatbáziskezelő rendszerek nagyon magas szintű nyelvek, de voltaképpen filekezelést végeznek. Az adatbázist alkotó fele-okban lévő adatok fizikailag pontosan úgy vannak tárolva mint minden más esetben: bináris jegyek kombinációjaként. Az adatbázisok létrehozásakor mi a logikai szerkezetet (az adatbázis sémáját) adjuk meg, az adatbáziskezelő rendszer fordítja ezt le, készíti el a "fizikai" file-okat, és kialakítja a logikai kapcsolatoknak megfelelő fizikai kapcsolatokat az adatok között. Ezeket a feladatokat a file-kezelő (fele-manager) végzi ami az DBMS fő része. Ez vezérli a file-ok létrehozását, a rekordok "beszúrását" (felvitelét) a törléseket; a módosításokat. A fele-kezelő tartja nyilván az adatok (fizika helyét, a köztük lévő kapcsolatokat, stb. Erre a célra a file-kezelő mélyén elhelyezkedő adatszótár (Data Dictionary) szolgál. 3.3 A lekérdező nyelv A lekérdező nyelv egy interaktív eszköz, amelynek segítségével dialógus folytathatunk a rendszerrel. Ilyen például az SQL-nyelv. Az ilyen nyelveknek az a lényege, hogy nagyon könnyen felírhatók bennük "ad-hoc" kérdések, amelyekre rendszer azonnali választ ad. (lásd az SQL SELECT parancsát). Az adatbáziskezelő rendszereknek, mint nyelveknek két fajtája van: a. egyik az ún. beépülő típusú, befogadó típusú (host-típusú), amelyik voltaképpen nem is igazi programnyelv, hiszen csak egy másik valódi program nyelvvel (COBOL, PL1, PASCAL stb.) együtt használható fel alkalmazó: programok írására, alkalmazói rendszerek felépítésére. Ilyen az SQL nyelv is. A másik típus valóságos programozási nyelv. Ezeknél ahhoz, hogy alkalmazói rendszereket készítsünk az adatbázis felhasználására, nem kell más programnyelvet bekapcsolni. Erre példa a dbase (III, IV, V) vagy a Clipper nyelv. 3.4 Adatbáziskezelőkben ellátott segédfeladatok Az adatbáziskezelő rendszerek a fő funkciókon kívül több "segédfeladatot" is ellátnak. Ezek közül kiemeljük a következőket. Adatvédelem, adatbiztonság. Nem minden felhasználónak van joga az adatbázis minden adatához hozzáférni. Amikor a felhasználó programján keresztül az adatbázishoz fordul egy jelszóval kell azonosítani magát. Ezt az adatbáziskezelő rendszer értékeli, és csak azokhoz az adatokhoz engedi hozzáférni, amelyekhez annak jogosultsága van. Az adatok védelme nagy adatbázisoknál rendkívül fontos dolog, hiszen az adatbázis tönkretétele nagyon nagy károkat okozhat (gondoljunk egy óriási bank adatbázisára). Az adatok védelmének szoftver eszközökkel történő biztosítása programozói szemszögbál nézve igen érdekes, de nagyon nehéz feladat. Az integritási feltételek teljesülésének figyelése. Az adatbázis adataival kapcsolatban gyakran meg lehet fogalmazni olyan feltételeket; amelyek ellenőrzésével az adatbázis létrehozásakor kiszűrhetők azok az input adatok, amelyek nem az adott adatbázisba valók (hibásak). Az adatbázis belső szerkezete is hordozhat olyan információkat, amelyek meghatározzák, hogy új adatok bevitele esetén ezek illeszkednek-e az adatbázishoz. Például kiköthetjük, hogy a dátum nevű adattétel nem vehet fel az 1900-as évek előtti dátumot, vagy előfordulhat, a rendszer olyan, hogy két adat megegyezése valahol az adatbázisban maga után hozza másik két adat megegyezését. Az ilyen típusú információkat integritási feltételeknek nevezzük. Az adatbáziskezelő feladata ezen integritási feltételek teljesülésének vizsgálata is. Szinkronizáció. Különösen hálózatban-üzemelő nagy adatbázisoknál, egyidejűleg nagyon sok felhasználó fordulhat esetleg ugyanazon adathoz. Ráadásul úgy, hogy egyik éppen módosítani akarja, a másik pedig lekérdezni. Ezeknek az ún. holtpont helyzeteknek a megoldása nagyon nehéz feladat. 3.5 Adatbázis statisztikák Mivel az adatbáziskezelő rendszerekben az adatokhoz való hozzáférés a központi szoftver vezérlése alatt megy végbe, ezért az ilyen rendszerek minden, az adatokkal kapcsolatos műveletről feljegyzést vezetnek, mindent nap- 9
lóznak. Ezeknek az adatoknak a felhasználásával azokhoz a műveletfajtákhoz, amelyek gyakran szerepelnek különféle gyorsításokat (pl. indexelés) hajthat végre a rendszer. 3.6 Az adatbázis adminisztrátor Az adatok központosítása lehetővé teszi, hogy egy személy az un. adatbázis adminisztrátor (ABA) (nagy adatbázisok esetén ez több személy is lehet) feleljen a teljes adatszervezésért, a biztonságért, az egész rendszerért. Az ABA adja ki a különféle jelszókat, engedélyez hozzáféréseket, módosításokat. Mivel minden releváns információ "egy fejben" van, így könynyebb biztosítani az adatbázis konzisztenciáját és integritását. Az adatbázis adminisztrátort speciális szoftverek segíthetik. 3.7 A 4GL-ek A 4GL-ek (Fourth Generation Languages = Negyedik Generációs Nyelvek) adatbáziskezelő rendszerek, amelyekkel nagyon kényelmesen, gyorsan írhatók fel adatbázis-alkalmazások, rendszerfejlesztések. Nincs mindenki által elfogadott definíció arra, hogy pontosan mit tekinünk 4GL-nek. Mindenesetre fóbb paraméterekként a következők sorolhatók fel. A 4GL segítségével képernyőn könnyen és gyorsan tervezhető meg az input és a módosítás. A felhasználónak nincsen más dolga, mint a képernyőn megjelenő képen (ábrán) kitölteni a mezőket. Bizonyos mezők letilthatók, vagyis ezekbe nem lehet beírni. Több adatbázis-táblán egyszerre is végrehajthatók a képernyőn keresztül bevitelek, módosítások. A másik fontos tulajdonsága a 4GL-eknek, hogy rendelkeznek olyan, az output megvalósítására szolgáló eszközzel, amelyekkel jól formázott, sablonokból előállítható listák írhatók ki (akár több adatbázis táblából is) anélkül, hogy programot kellene írnunk. Ez azt jelenti, hogy szabványos kiírási képeket definiálhatunk, azt könyvtárba foglaljuk és szükség szerint építjük bele "grafikusan" a különféle felhasználói programokba. A 4GL-tulajdonságú adatbáziskezelő rendszerekben nem csak az input, output támaszkodhat képernyőelemekre, hanem más felhasználói műveletek is (Pl. keresés, módosítás, stb. az adatbázisban). Azt szokták mondani, hogy 4GL esetén vagy 4GL tulajdonságú adatbáziskezelő alkalmazásakor csak azt kell megmondani, mivel mit akarunk elvégezni, de azt nem, hogy hogyan, tehát az eljárásnak, a procedúrának nincs szerepe, azaz a nyelv nem eljárásorientált. A 4GL jellemzője az is, hogy az előbbiekben említett "képi" megoldásokkor a 4GL programkódokat is generál, amiket a programozó módosíthat, átírhat. 3.8 Integrált CASE eszközök A korszerű, relációs modellre támaszkodó adatbáziskezelő rendszerek közül sokban megtalálható a CASE csomag (CASE = Computer Aided Softver Engineering = Számítógéppel támogatott szoftver technológia) A CASE többek között lehetővé teszi az adatbázistervező számára az un. egyed-tulajdonság diagramok interaktív felrajzolását, az adatbázisséma létrehozását, módosítását. A CASE-zel automatikusan generáltatók a tényleges táblák, relációk, (lásd később) és elvégezhetők bizonyos normalizálási teendők is (lásd később) Az adatbázis tervezést használó programok Az összetett feladatok ellátásához ma már meglehetősen bonyolult feladatrendszerek állnak rendelkezésre. Több olyan módszertan fejlődött ki, amelyek alkalmazások fejlesztéséhez használhatók. Ilyen például az UML (=Unified Modelling Language) vagy az SSADM. Ezekkel a tervezőeszközökkel az adatok struktúrűja, a tevékenységek struktúrája formálisan leírható, majd a formális leírás alapján néha az adatbázisok szerkezetén kívül a kezelő program, vagy annak váza is létrehozható. 3.9 Az ANSI/SPARC modell A 70-es években az adatfeldolgozásban nagyon elterjedt az adatbázis szemlélet, és számos adatbáziskezelő rendszer jött létre. Abból a célból, bizonyos szabványosítást lehessen elvégezni a fogalmak és a terminológiák tekintetében, az ANSI/X3/SPARC bizottság elkészített egy ANSI/SPARC modellt. A belső nézet a tárolt, fizikai adatbázist jelenti. A belső koncepcionális leképezés a belső nézet a koncepcionális sémát, az un. logikai sémáját hozza létre A külső koncepcionális leképezés a logikai sémákból külső nézeteket hoz létre. A felhasználók az alkalmazások használatán keresztül általában csak a külső nézetekkel találkoznak. Az adatbázisok tervezésénél a logikai séma megalkotása a legfontosabb 10
3.10 Adatbázis tervezés lépései 3.11 Logikai, fizikai szerkezet Az adatbáziskezelésben (általában az adatkezelésben) a logikai jelző azt jelenti, hogy felhasználó-orientált, azaz a felhasználó számára érthető. Például egy adatbázis tervezésénél logikai szerkezetben írjuk le a dolgokat, amikor a valóságos világ objektumait képezzük le adatmodellé. A fizikai jelző azt fejezi ki, hogy az adatok szerkezete "gépközeli" azaz a memóriában való tárolás, a file-kezelés szempontjából tekintjük az adatok szerkezetét, úgy ahogy a rendszerprogramozó "látja" amikor az adatbáziskezelő fordítóprogramjait írja. 3.12 A programok és az adatok függetlensége Ez az adatbázisok fontos tulajdonsága. A program és az adatok függetlenségén azt értjük, hogy kis módosítások az adatbázis struktúráján megtehetők anélkül, hogy az alkalmazói programot módosítani kellene. Természetesen teljes függetlenség nem valósítható meg, de minél nagyobb ez a függetlenség, annál jobb a rendszer. 3.13 Az adatbázis életciklusa A felhasználó számára kész termékként átadható, üzemeltethető adatbázisok (a kezelő-programokkal együtt) többlépcsős folyamaton keresztül jönnek létre nagyjából egy adott séma szerint. 3.13.1 Az elemzés Az első lépcső az adatbázissá formálandó valóságos probléma megértése, a korlátozó feltételek felismerése, a lehetséges variációk feltérképezése. A probléma megértéséhez először azonosítjuk a problémakörben szereplő valóságosan létező tárgyakat, személyeket. Összefoglalva ezeket szereplőknek hívom. Meghatározzuk a szereplők figyelembe venni kívánt tulajdonságait és elvetjük a nem szükséges tulajdonságaikat. A fontosság kritériuma, hogy az adatbázis céljához van-e köze az illető tulajdonságnak Meghatározzuk, az adatbázissal modellezendő folyamatokat. Ezek lesznek az események. Az események általában valamiféle dinamizmust, változást határoznak meg. Megnézzük, hogy ezekben a folyamatokban hogyan vesznek részt a szereplők. A fentiek alapján megvizsgáljuk, hogy az egyes szereplők milyen csoportokba sorolhatók, a valóságos folyamatokban milyen szerepekben vesznek részt (pl. egy üzleti folyamatban vevő, vagy szállító, vagy eladó...) Megvizsgáljuk, hogy az egyes szereplők között a valóságban milyen statikus és vagy dinamikus kapcsolat van. Csak az adatbázis szempontjából lényeges kapcsolatokat vesszük figyelembe, a többi kapcsolatot figyelmen kívül hagyjuk. Ebben a folyamatban matematikai értelemben vett halmazokat definiálunk, amely halmazok elemei a fent említett szereplők és az események. 3.13.2 A modellalkotás A második lépésben megalkotjuk az adatmodellt (az egyed-kapcsolat modellt), meghatározzuk a kulcsokat. Az adatmnodell valójában a valóság leképezéseként jön létre. Az adatmodell nem a valóság tükörképe, hiszen a résztvevők tulajdonságaiból elhagytunk, a kapcsolatoknak csak a fontos tulajdonságait emeljük át a modellbe. Meghatározzuk a modell típusát (hierarchikus, hálós vagy relációs - lásd később). Meghatározzuk a modellben szereplő egyedek kapcsolatait egymással (az egyed meghatározása később). Adatmodellünket normalizálási procedúrának vetjük alá a következő lépésben. Az adatbázisokat általában a lehető legmagasabb normálformása hozzuk, azonban időnként el kell rontani a normalizált állapotot. Ezt denormalizálásnak hívják. Miután megalkotjuk az adatbázis modelljét létrehozzuk a fizikai adatbázist. 3.13.3 Fizikai létrehozás Az adatbázis modllje alapján szintén egyfajta leképezéssel jön létre a fizikai adatbázis. Gyakran az adatbázismodellt nem tudjuk az eszközeinkkel egyszerű módon leképezni, ezért ilyenkor előfordulhat, hogy visszanyúlunk a tervezési fázishoz és módosítjuk az adatmodellt. A fizikai adatmodell az alkotó táblák halmaza, melyeket az adatbázis adminisztrátor az adatbáziskezelő rendszer programmal (SQL-ben a CREATE TABLE paranccsal) definiál. 11
A következő lépés a különféle file-ok létrehozása, az indexelés. Az indexelés során megállapítjuk, hogy mely mezőkre keres a rendszer gyakran, ezekre állítunk be indexeket. Ezután jöhet és a szükséges nézetek definiálása. Ezután a lekérdezések megtervezése következik. Bár ez a folyamat sokadik lépése, de minden előtte lévő lépést is befolyásol, mivel szinte minden amiatt történik az adatbázisban, hogy lekérdezéseket adhassunk fel. A képernyőtervet a beviendő adatok és a kimenő eredmények határozzák meg; itt voltaképpen az ember-gép kapcsolatot, a felhasználó és az alkalmazási rendszer kapcsolatát határozzuk meg. A képernyőterv alkalmas is, hogy egyszerűbb kérdés-felelet dialógust szerkesszünk meg, amelyek segítségével a nem profi alkalmazók jól definiált feladatokat oldhatnak meg. Létrehozhatunk a képernyőn olyan menüket, amelyek egy sor lehetőséget kínálnak fel a felhasználónak aki különféle sorrendben választhat a menüpontok közül abból a célból, hogy kitűzött feladatát megoldja. A listázási terv szintén fontos eleme az adatbáziskezelésnek. Itt speáljuk mit és milyen standard táblázatban akarunk kiírni az adatbázisból lekérdezett eredményekből. A legtöbb DBMS-ben megtalálhatók az un. report writer"- ek, a listázó programok, amelyek segítségével könnyen tudjuk szerkeszteni az output formátumát. A következő lépés a tesztelés megtervezése. Ez természetesen nemcsak az adatbázistervezés fontos eleme, hanem bármilyen más program írásakor is lényeges szerepe van; kulcs-lekérdezések, input és karbantartó képernyőképek, listázó programok szolgálnak az adatbázis helyességének illetve az egész rendszer életképességének ellenőrzésére. Nagy jelentősége van egy teszt-adatbázisnak, ami pontosan olyan, mint az "élő" adatbázis, de a benne szereplő adatokat úgy tervezzük meg, hogy a lehető legtöbb esetet reprezentálják. Az utolsó lépés a rendszer átadása, amikor a felhasználó megkapja az adatbázist, az alkalmazói programokat és elkezdődhet az adatbázis feltöltése. 3.14 Objektum-orientált adatbázisok Az adatbázisok egy új generációját jelentik az objektum-orientált adatbázisok (illetve adatbáziskezelők). Ez a filozófia abban tér el az eddigiektől, hogy integrálja az adatkezelés és az adatdefiniálás mechanizmusát. Ez a gyakorlatban azt jelenti, hogy az adattáblák definiálásakor nem csak a mezők típusát, és méretét definiáljuk, hanem az mező validálási információit, formátum információit, kezdőértékét, indexelését stb... Ilyen módon az adatbázis kezelése során nem kell plusz eljárásokat írni azadatbevitel és megjelenítés minde esetét tekintve, hanem ha egy adatot beviszünk vagy megjelenítünk, akkor a rendszer önmagától képes a megfelelő vizsgálatokra és formátumok alkalmazására. (Nagyon szépen látdszik ez a fajta gondolkodás a Microsoft Access tábladefiniálásakor) Magában az adatbázistervezésben az objektum-orientált szemlélet nem jelent lényeges eltérést az egyed-kapcsolat modellhez képest, a korszerű adatbáziskezelő rendszerek (pl. a 4GL-ek) viszont teljességgel követik az objektumorientált nyelvek filozófiáját. 12
4 Az adatmodellek a logikai séma 4.1 Az egyed fogalma Egyednek hívunk minden olyan dolgot (objektumot), ami minden más objektumtól megkülönböztethető és amiről adatokat tároltunk. Az egyed konkrét dolgok absztrakciója, konkrét dolgokat fog egybe. Matematikailag az egyed bizonyos tulajdonságú dolgok halmaza. Például az autó mint egyed sok autót jelent. Egy adott egyed által képviselt konkrét elemek halmazát egyedhalmaznak is szoktuk nevezni. Például a dolgozó nevű egyed egyedhalmaza az összes dolgozókból áll, a személy egyedhalmaz az összes személyt tartalmazza, az érzelem egyedhalmaz az összes érzelem. Az egyed egy konkrét értékét az egyed egy előfordulásának nevezzük, de az előfordulás helyett mondhatunk egyedértéket is. Megjegyzés. Gyakori, hogy az egyed helyett egyedtípust mondunk. 4.2 A rekordtípus Az adatbáziskezelő rendszerekben (elsősorban a hálós, hierarchikus modelleken alapulókban) az egyedtípust rekordtípusnak hívjuk. Ez a legkisebb címezhető egység (ennél kisebb részeire nem lehet hivatkozni az adatbázisnak). 4.3 A tulajdonság fogalma, Azonosítók Az egyedeket tulajdonságokkal (attribútumokkal) írjuk le, a tulajdonság az egyed egy jellemzője, ami megadja, meghatározza az egyed e részletét. A tulajdonság is absztrakció, amely több elemet foglal magába, tehát konkrést előfordulásokból áll. A tulajdonságok lehetnek: - azonosítók (például a kulcsmezők) Ha egy tulajdonság minden értéke minden egyed előfordulásra más és más értéket vesz fel, akkor azonosítónak hívjuk. - leírók (nem kulcsmezők) A leírók nem határozák meg egyértelműen az egyed előfordulásait. Az azonosítók létrehozása esetenként az egyed természetes tulajdonságaiból adódik. Erre példa a személyi szám a személyek azonosítása terén. Ekkor beszélhetünk egyszerű azonosítóról. Amikor nem lehet ilyen azonosítót alkalmazni, két lehetőségünk van: Addig bővítjük az azonosításra alkalmas tulajdonságok körét, amíg elérjük, hogy a sajátosságok kombinációja már egyedileg azonosítja a kérdéses egyedek előforulásait, Mesterséges nevet alkotunk, aminél biztosítjuk az egyediséget, de aminek esetleg semmi köze nincsen az egyedtípushoz. (pl. automatikusan növekvő sorszám) 4.4 Kulcs A menniyben a tulajdonságok vagy a tulajdonságok egy csoportja egyértelműen meghatározza, hogy az egyed melyik értékéről, előfordulásáról van szó, akkor ezeket kulcsoknak nevezzük. 4.5 Többértékű vagy összetett tulajdonságok Ha a tulajdonságok olyanok, hogy több értékkel rendelkeznek, akkor összetett vagy többértékű tulajdonságnak hívjuk. 4.6 A kapcsolat fogalma Kapcsolatnak nevezzük az egyedek közötti viszonyt. A kapcsolat mindig valóságos objektumok közötti viszonyt fejez ki, hiszen az egyed ilyen objektumokat képvisel; A kapcsolat is absztrakció: két egyed értékei közötti konkrét viszonyokat fejez ki. A konkrét kapcsolatokat a kapcsolat értékeinek (előfordulásainak) nevezzük. A kapcsolódó egyedek között általában nem egyenrangú a viszony, hanem lehet egyfajta irányításról beszélni. A kapcsolat meghatározója a tulajdonos (owner) és a kapcsolat másik oldalán lévő egyed vagy egyedek a tagok (member). Az egyedek közötti kapcsolat lehet kötelező, félig kötelező, opcionális. Kötelező kapcsolatról beszélünk, ha az adatmodell időfüggvényének szerepe van az adatmodell kialakításában. 13
Az archiválás problémaköre (inaktív egyed-előfordulások). 4.7 A kapcsolat fokai Kapcsolat egyidejűleg több egyed között is lehet. Ha a kapcsolat n egyedet "köt össze" akkor n-edfokúnak nevezzük. A leggyakoribb a bináris (másodfokú) kapcsolat, amikor is két egyed között van viszony. Speciális bináris kapcsolat a rekurzív bináris kapcsolat. Ilyenről van szó akkor, ha az egyeden belül az előfordulások vannak kapcsolatban. Pl.: a dolgozó egyedben benne vannak a vezetők is (általában ők is dolgozók), de a többi dolgozóval speciális kapcsolátban vannak: vezetői-beosztotti kapcsolatban. Gyakoriak a valóságos világ objektumai között a harmadfokú (angolul ternary) kapcsolatok, vagyis olyanok amikor három egyed között van viszony. 4.8 A kapcsolatok fajtái Egy kapcsolat voltaképpen az egyedhalmazok elemei közötti viszonyt fejezi attól függően, hogy az egyedhalmaz elemei milyen módon kapcsolódik egymáshoz, azaz egy adott egyed egy előfordulásához hány előfordulás kapcsolódik a másik egyedből három esetet különböztetünk meg a) Egy-egy típusú kapcsolat (1:1 kapcsolat) A kapcsolat lelet olyan, hogy az egyik egyedhalmaz mindegyik eleméhez a másik egyedhalmaznak pontosan egy eleme kapcsolódik (tehát a két egyedhalmaz egymásba kölcsönösen egyértelműen képezhető le. Az ilyen kapcsolatot egy-egy (jelben 1 :1) típusúnak nevezzük. b) Egy-több típusú kapcsolat (1:N kapcsolat) Azt mondjuk, hogy az A egyed és a B egyed között egy-több (jelben: 1:N) típusú kapcsolat van, 1a az A egyedhalmaz mindegyik eleméhez a B egyedhalmaznak több eleme is tartozhat. c) Több-több típusú kapcsolat (N:M kapcsolat) Több-több (jeiben N:M) típusú kapcsolatnak nevezzük az A egyed és a B egyed közötti kapcsolatot; ha az A egyedhalmaz minden eleméhez B halmaz több eleme is tartozhat, továbbá B minden eleméhez A több eleme is kapcsolódhat. Az ilyen kapcsolatot az adatbvázis-kezelő rendszerek nem feltétlenül tudják automatikusan lekezelni, ezért ilyenkor szokásos automatikusan a két egyedtípus közé felvenni egy kapcsoló egyedtípust, amely a kapcsolatokat szétvágja két egy-több típusú kapcsolatra. Az ilyen kapcsoló egyedek gyakran valamiféle eseményt hordoznak. d) Nulla vagy egy-egy típusú kapcsolat Ez a kapcsolattípus akkor jön létre, ha egy egydhalmaz előfordulásaihoz a másik egyedhalmazból nem feltétlenül tartozik egy előfordulás e) Egy-nulla vagy egy több típusú kapcsolat Ha az egyik egyedtípushoz a másik egyedtípusban nem feltétlenül tartozik előfordulás vagy több előfordulás tartozhat. A kapcsolatok ábrázolásához használhatjuk az Egyedkapcsolat diagramot. (Entity RelationShip Diagram ERD) Ilyen diagramokat lehet készíteni a Microsoft Access kapcsolattervezőjében vagy sok más hasonló alkalmazásban. 4.9 A kardinalitás Az egyedek a kapcsolat szempontjából az un. kardinalitási számmal is jellemezhetők. Az egyed kardinalitási száma a kapcsolatban azt adja meg, hogy egy egyed egy előfordulásához a másik egyedből maximálisan hány előfordulás kapcsolódhat, azaz az N:M kapcsolatban a kardinalitási szám : max. (N), max. (M). 4.10 A belső szerkezete, belső tulajdonságai Egy adatmodellben valamennyi egyedet egyenként véges számú tulajdonsággal írunk le. Ezek a tulajdonságok együttesen alkotják az egyed belső szerkezetét, és az egyed belső tulajdonságainak hívjuk őket. 4.11 Az egyed külső tulajdonságai Az egyedek kapcsolatainak összességét külső tulajdonságoknak hívjuk 4.12 A settipus fogalma Az adatbáziskezelő rendszerekben (elsősorban a hálós és hierarchikus modellen alapulókban) két egyedtípust (agyaz rekordtípust) a köztük lévő kapcsolattal együtt settipusnak nevezzük. Ezt névvel látjuk el; így a feldolgozás során hivatkozni lehet rá (a rekordtípushoz képest eggyel magasabban címezhető egység). 14
A settipusban a kapcsolatnak mindig "irányt" is adunk, rajzban ezt nyíllal fejeszük ki. Az egyik rekordtípust (a.miből a nyíl vezet) tulajdonosnak (owner) a másikat (amibe a nyíl vejet) taginak (member) nevezzük. (1.14 ábra) 4.13 A kapcsolatok ábrázolásának különféle módjai A kapcsolatok ábrázolására több módszer terjedt el. Vonalas összekötés A legegyszerűbb ezek közül az, amikor két egyedtípust egy egyenessel, vagy kifejezve a kapcsolat irányát egy nyíllal kötünk össze. A Chen féle jelölés Egyes szerzők a Chen féle jelölést használják. A kapcsolatot itt rombusz jelöli; amibe beírjuk a kapcsolat "tartalmát", nevét is. Ennél a jelölésnél megadjuk a kapcsolat fajtáját és a zérus minimális kardinalitást is (körrel). Nyíllal jelölhetjük a kapcsolat irányát is. A magyar nyelvben nehezebb felírni a kapcsolat tartalmát, mint azokban a nyelvekben, ahol a rag a főnév előtt van (pl. angol, német, stb.). A "varjú-lábas" ábrázolás A kapcsolatban előforduló egyedeket dobozokba írjuk, a kapcsolatot egy vonal jelképezi, amely összeköti a dobozokat, a kapcsolat típusát az egy oldalon egy vonal, a több oldalon három kis vonal jelöli. 4.14 Egyed-szupertípus, egyed-altípus Amennyiben több egyedtípus ugyanazon tulajdonságtípusokkal rendelkezik, úgy ezek az egyedtípusok egy magasabb szintű egyedtípusba vonhatók össze. Ezt az absztrakciót generalizálásnak nevezzük. Azt az egyedtípust amit több egyedtípusból generalizálunk egyed-szupertípusnak, az öt alkotó egyedtípusokat pedig egyed-altípusoknak nevezzük. Az egyed-szupertípust más szemszögből is nézhetjük; azt mondhatjuk, az egyed-altípusok az egyed-szupertípus specializációi. Egy egyed-szupertípus egy kapcsolatban, lehet egyed-altípus egy másik kapcsolatban. Ha az egyed-szupertípus és az egyed-altípus kapcsolatok egy struktúrát hoznak létre, akkor ezt generalizációs hierarchiának nevezzük. Az egyed-altípusokat két csoportra sorolhatjuk. Ezek lehetnek ugyanis diszjunktak, vagyis olyanok, amelyeknek nincsen közös elemük. A generalizációnál azt mondhatjuk, hogy a tulajdonságokat az egyed-altípusok öröklik az egyed-szupertíustól. 4.15 Aggregáció Az aggregáció egy másik absztrakció az egyed-szupertípus és az egyed-altípus között. Az aggregáció esetén az altípus része az egyed szupertípusnak. Pl. egy szoftverterméknek része a program és a felhasználói kézikönyv. Az aggregációnál a tulajdonságok nem öröklődnek, mindegyik egyednek saját tulajdonságai vannak. 15
5 Az adatmodellek és az adatbázisok Az előbbiekben megismert elemekből többféle adatmodell hozható létre. 5.1 Az adatmodell fogalma Az adatmodell egyszerű, tulajdonságok és kapcsolatok halmaza, amely absztrakt módon tükrözi a valós objektumoknak, szak jellemzőinek (tulajdonságainak) és viszonyainak (kapcsolatainak) elvont kategóriáit. Az adatmodell egy olyan séma, amelyben megadjuk milyen tulajdonságok határozzák meg az egyedeket, milyen egyedek szerepelnek a sémában, és ezek között milyen kapcsolatok vannak. Az adatbázisokat különféle adatmodell szerint építhetjük fel. Az adatmodell meghatározza az adatbázis szerkezetét, sémáját. Az adatmodell, adatbázismodell szavak ugyanazt jelentik. Az egyedet, a tulajdonságot és a kapcsolatot adatmodell-elemeknek nevezzük. Attól függően, hogy ezekből milyen módon hozzuk létre az adatmodell szerkezetét, különféle adatmodelleket kapunk. Három adatmodell terjedt el az elmúlt 30 év alatt. Az első két modellről (a hierarchikusról és a hálósról) úgy látszott, hogy velük sikerült véglegesen "megfogni" az adatfeldolgozást. A harmadikról (a `relációsról) sokan azt hittük, hogy zsákutca. A nyolcvanas évek elejére kiderült, hogy az utóbbi jóslat tévedés volt; ma már a relációs modell szinte egyeduralkodóvá vált. Az, hogy milyen modellre alapozva végezzük az adatfeldolgozást, az adatbázis megszerkesztését meghatározza az adatbáziskezelő rendszert, a nyelvet is. Minden egyes modellre számos nyelvet dolgoztak ki. 5.2 A hálós adatmodell A "történelem" folyamán nem ez volt időben az első adatmodell, de mivel úgy tekinthető, mint a hierarchikus általánosítása (azaz a hierarchikus ennek speciális esete), ezért a hálós adatmodell ismertetésével kezdjük. A hálós adatmodell szerkezetét gráffal adjuk meg. Ebben a gráfban a csomópontok az egyedek, az élek pédig a kapcsolatot fejezik ki. Az egyedeket tulajdonságaikkal írjuk le. A hálós adatmodell adatbázisaiban az egyedek (tehát az előfordulásaik) közötti kapcsolatot listaszerkezettel (pointerek, mutatók használatával) adják meg. Például: Tejüzemeket és boltokat nézünk. Az egyes tejüzemek több boltba szállítanak árut. A tejüzemeknek a teherautókkal a lehető legrövidebb úton (leggazdaságosabban) kell eljuttatni az árukat a boltokba. A csomópontok a termelőegységek és a boltok, az élek megfelelnek az útvonalaknak. 5.3 A hierarchikus adatmodell A hierarchikus adatmodell szerkezetét specilis gráffal adjuk meg, fával. A csomópontok itt is egyedeket jelentenek és a nyilak a kapcsolatokat fejezik ki. A hierarchikus adatmodellre épülő adatbázisok kezelésére számos adatbáziskezelő rendszert dolgoztak ki. Például: Hierarchikus adatmodell alakítható ki egy cég szervezeti hierarchiájának leírására Hierarchikus adatbodellt használnak a windows rendszerek felhasználói adatbázisának tárolására. Hierarchikus adatszerkezetet használunk egy filerendszer leírására. 5.4 A relációs adatmodell A relációs adatmodell más filozófiára épül, mint az előbbi kettő. Ennél az adatmodellnél a három adatmodellelem közül a kapcsolat nem játszik szerepet, pontosabban szólva a kapcsolat nem, csak a lehetőség épül be az adatmodellbe. A relációs adatmodellnél a tulajdonságok kapják a fő hangsúlyt, a tulajdonságokkal definiáljuk az adatmodell szerkezetét. Az olvasó bizonyára észrevette, hogy az előbbi két modellben a gráffal történő leírásban éppen a tulajdonságok nem szerepeltek, ezeket külön adtuk meg. A relációs adatmodellben az egyedet egy táblázattal adjuk meg, a táblát oszlopai a tulajdonságok. A táblázat sorai az egyed értékei (vagyis a táblázat maga éppen az egyedhalmaz). A táblázat egy-egy sorát a tulajdonságok konkrét értékei adják. A relációs adatmodellben létrehozott adatbázisokat több táblázattal adjuk meg (ne felejtsük el, minden tábla egy egyedhalmaz), de a táblázatok (tehát az egyedek) közötti kapcsolatokat nem definiáljuk az adatmodell felírásakor. 16
Ez nem azt jelenti, hogy nincsen közöttük kapcsolat, de ezeket a kapcsolatokat például egyszerűen az fejezi ki, hogy két táblának van közös oszlopa (mindkét táblában szerepel ugyanaz a tulajdonság). Miért hívják ezt a modellt relációsnak? 5.5 Reláció definíciója Definíció Legyenek D1, D2,...Dn adott halmazok. E halmazok Descartes szorzatán azt a D halmazt értjük, amelyeknek az elemei a (v1,v2,...,vn) érték n-esek, amelyekben v1 elme D1-nek, v2 eleme D2, nek stb... Azaz minden halmazból kiveszünk pontosan egy elemet és a megadott sorrendben egymás után írjuk. Az így kapott elemsorozat lesz a szorzathalmaz egy eleme. A Descartes szorzat egy R részhalmazát relációnak nevezzük. A D,, D~,..., D halmazokat a reláció tartományainak (domain), a reláció egy elemét n-esnek (elem n-esnek, angolul taple-nak) nevezzük. Az R reláció elemeit gyakran rekordoknak hívjuk. A továbbiakban az adatbázis egy "oszlopát" attribútumnak nevezzük. Úgy is fogalmazhatunk, hogy az attribútum egy változó, ami az oszlopba írt értékeket "veszi fel" a tartományban szereplő értékek közül, azaz a tartományt az adott attribútum értékkészletének tekinthetjük. Jelöljük a továbbiakban az attribútumokat az A1,A2,..., An indexes nagybetűkkel, ezeket együtt (vagyis az attribútumok halmazát) A-val, azaz A = { A1,,A2~,..., An}. Megadtuk tehát a relációs adatmodell két definícióját. Az egyik definíció szerint a relációs adatbázis táblázatokból áll, a táblázatokat az oszlopok definiálják. A másik definíció szerint a relációs adatbázis relációkból áll. Az olvasó bizonyára észrevette, hogy voltaképpen elnevezésbeli különbségről van szó. A továbbiakban vegyesen használjuk a táblázat ill. reláció elnevezést. Az attribútumok számát (az oszlopok számát) az R reláció fokának, a sorok számát pedig a reláció számosságának nevezzük. Ahelyett, hogy n-ed fokú, gyakran mondjuk, hogy n változós. A relációs adatbázist röviden jelölni, a következő módon lehet: R ( A1,A 2,..., An). alakban tesszük, ahol R a reláció neve, Ai pedig egy attribútum. A továbbiakban a reláció nevét és az attribútumokat nagybetűkkel jelöljük. Az R (A2,A2,..., An) alakot a reláció sémájának nevezzük. Gyakran attribútum helyett egyszerűen oszlopnevet mondunk sőt még egyszerűbben azt mondjuk, hogy a reláció oszlopokból áll. (pl. az SQL nyelvben) Több adatbáziskezelő rendszerben mezőnek nevezzük az attribútumot, és a mező értékeiről beszélünk (pl. dbase IIL, IV.) 5.6 Reláció, tábla, adatbázis Az előbbiekben egy táblát (relációt) adatbázisnak neveztünk. A relációs adatbázisok általában nem egyetlen relációból, táblából állnak, hanem több tábla alkot egy adatbázist. Azt, hogy egy adatbázist hány táblára bontunk szét, vagy hány táblát fogunk össze egy adatbázisba, már az adatbázis megtervezésekor eldöntjük. A táblákra bontásnál az attribútumok közötti kapcsolat jelentősen befolyásolja, hogy mely oszlopok kerülnek egy táblába. Egy adatbázis nem egymástól független. táblák halmaza, hiszen így semmit sem érnénk velük. A relációs adatbázisokban a különböző táblákat közös attribútumokkal (oszlopokkal) kötjük össze. Az ilyen oszlopokat kulcsoszlopoknak, (kulcsmezőknek) is szoktuk nevezni. 5.7 Egyedtípus és reláció kapcsolata Valójában minden egyedtípus egy relációnak felel meg. Ezzel vége is van a hálós (hierarchikus) illetve a relációs adatmodell közötti kapcsolatnak. Miben áll a különbség ettől a ponttól kezdve? Abban, hogy amíg a hálós (hierarchikus) modellben az egyedtípusok közötti kapcsolatot is megadjuk, azaz két egyedből egy settípust hozunk létre és listaszerkezettel valósítjuk meg az előfordulások kapcsolatait, vagyis pontosan megmondjuk, hogy a tulajdonos egyedtípus mindegyik előfordulásához a tag egyedtípus melyik előfordulása tartozik addig a relációs modellben nem rögzítjük a kapcsolatot. Természetesen, mint az előbbi pontban láttuk a relációs adatbázis táblái között is van kapcsolat (azonos tartalmú oszlopokon keresztül) de az egyik reláció soraihoz (rekordjaihoz) nem fűzzük hozzá a másik reláció sorait. 17