1. Az adatbázis fogalma, fontosabb összetevÿi, felhasználási módjai

4. tétel Az egyed-kapcsolat modell 1. Az adatbázis fogalma, fontosabb összetevÿi, felhasználási módjai 1.1. Adatbáziskezelÿ rendszer (DBMS - DataBase Management System) A DBMS komplex SW-HW rendszer, mely adatok magas szintÿ kezelését szolgálja. A "magas szintÿ" jelz igényes felhasználói felületre utal. Jellemz i: ÿ nagy adatmennyiség: ez mega-, újabban pedig már terrabyte-os (10 12 byte) adatmennyiséget jelent. A tárolás eszköze lehet diszk, dob vagy CD. ÿ gazdag struktúra: ezadatmodellfelállításátteszilehetÿvé. Pl. a Newton-közelítése 16 jegyre pontosan nem szolgáltat adatbázist, csupán strukturálatlan bitfolyamot. Adatbázisról akkor beszélhetünk, amikor a biteknek struktúrája és így jelentése van. ÿ hosszú életciklus: fontos az adatok permanens megÿrzése, mert az együtt lévÿ adatmennyiség értéket képvisel. 1.2. A DBMS felhasználásával szembeni követelmények 1.2.1. Új adatbázis (a továbbiakban DB) létrehozása, ún. séma kialakítása és kezelése ÿ Séma: adatok fogalmi struktúráját rögzíti. Ennek nyelvi eszköze a DDL (Data Definition Language), az adatdefiníciós nyelv. Erre a létrehozáskor ill. a rendszer változásakor van szükség. 1.2.2. Adatok beillesztése, törlése, módosítása, lekérdezése Ennek nyelvi eszköze a ÿ DML (Data Management Language), az adatmanipulációs nyelv, és a ÿ QL (Query Language), a lekérdezÿ nyelv. (Ilyen pl. az SQL - Structured QL, ami felvállal DDL funkciókat is.) 1.2.3. Hatékony tárolás, kezelés, hozzáférés 1.2.4. Biztonság és védelem ÿ Biztonság a meghibásodásokkal (Security), és védelem az illetéktelen hozzáférésekkel szemben (Privacy). 1.2.5. Felügyelje több felhasználó egyidej konfliktusmentes munkáját ÿ A '90-es évektÿl kezdve a komolyabb rendszerek már ezt is figyelembe veszik. 1

4. tétel Az egyed-kapcsolat modell 1.3. A DBMS vázlatos modellje sémam veletek lekérdezések adatm veletek "lekérdezés" processzor tárkezelÿ tranzakciókezelÿ DB adatok metaadatok A DBMS-hez az alábbi m veletekkel fordulhatunk: 1. Sémamÿveletek: ÿ a DB logikai vázának kialakítását, módosítását jelentik (a DDL igénybevételével). 2. Lekérdezések: ÿ kérdéseket fogalmazunk meg a DB tartalmával kapcsolatban. Ennek kétféle (bár nem teljesen független) változata: lekérdezÿ nyelven (QL) megfogalmazott kérdésekkel (pl. SQL), vagy alkalmazói programon keresztül feltett kérdésekkel nyerünk ki adatokat. Ez utóbbi esetben beszélhetünk gazdanyelvrÿl (host language), mely egy, a DBMS-hez hívásokat intézÿ általános célú programozási nyelv. 3. Adatmÿveletek: ÿ adatok beillesztését, törlését, módosítását célozzák - ezek a DML funkciói is egyben. Az adatm veletekben is érvényes a lekérdezéseknél megismert két ("a.)" és "b.)") változat. ("b.)"-re példa: banki rendszerekben kamatok jóváírása.) A DBMS architektúra komponensei: 1. Tárkezel : a diszkre ír és onnan olvas. Részei: ÿ File-kezel : a fizikai szint I/O-ot végzi, ami az állomány nyilvántartására és elemeinek kezelésére szolgál. (DB-környezetben az adatvesztés veszélye miatt nem megengedett a "nem fizikai" írás/olvasás, így például a UNIX-ban használt lapozás, ami nem mindig jár konkrét I/O-tal. Vagyis a módosításokat azonnal rögzíteni kell!) ÿ Puffer-kezel : ez a file-kezelÿ belsÿ memóriás kiegészítése; elkülönülést tesz lehetÿvé az operációs rendszer tárkezelÿ mechanizmusaitól és kezeli az I/O számára rendelkezésre álló belsÿ memóriát. A puffer felépítése: blokk 1 blokk 2 2

4. tétel Az egyed-kapcsolat modell ÿ A blokk egy ütemben írható/olvasható terület, mérete leggyakrabban 2 12-2 14 byte (ez egy rendszerfüggÿ paraméter). ÿ A tárkezelÿ puffer-blokkjai elkülönülésének oka a fizikai adatfüggetlenség elve: ha igényeinkben változások állnak be, akkor a továbbiakban is használható legyen az adatbázis, vagyis logikai vázát ne kelljen átszervezni. Célunk tehát az, hogy a fizikai kérdéseket a többitÿl nagyrészt függetlenül tudjuk kezelni. 2. "Lekérdezés" processzor (lekérdezés feldolgozó): magas szint (pl. szelektor) kérdések átalakítását végzi egyszer utasítások sorozatára. A "MIT"-et bontja le kisebb elemekre, amelyek válaszolnak már a "HOGYAN"-ra is. Ebben a lebontásban fontos az optimalizálás, a lehetséges végrehajtások közül az "intelligens" feldolgozó választ: végrehajtási tervet készít. A standard formában megfogalmazott kérdéseket lehetÿséghez mérten átalakítja, majd a már végrehajtható utasításokkal a tárkezelÿ felé fordul. Példa: ÜGYFÉLtábla NÉV CÍM EGYENLEG NEMZETISÉG SELECT név FROM ügyfél WHEREegyenleg<0AND nemzetiség = 'DOGON' Azokra az nevekre vagyunk kíváncsiak az ÜGYFÉL táblából, akikhez negatív egyenleg tartozik és nemzetiségük "dogon" (<- afrikai népcsoport). A feltétel szÿrése hatékonyabb, ha elsÿként a nemzetiség szerint szelektálunk (mert példánkban egy ritka népcsoportot keresünk, s így a kisz rt hátralékos ügyfelek közül sokat kéne az eredménybÿl kizárni, mert nemzetiségük más), és csak ezután az egyenleg szerint. Látható tehát, hogy a jó szelektor-kérdések kialakítása nagyon fontos. Lényeges a tábla elérési mechanizmusa is, ami lehet szekvenciális vagy indexelt, esetleg B-fával megoldott, stb. A rendszerek nem törekszenek valódi optimum megtalálására - hiszen a sz rési feltételek egymástól és az adatoktól való függése, hatékonysági sorrendje nagyon bonyolult lehet -, ezért inkább csak valamilyen módon közelítik az optimumot. 3. Tranzakció-kezel : célja az, hogy egyidej leg több folyamat párhuzamos hozzáférését biztosítsa az adatbázishoz. Kulcsfogalma a tranzakció: ez utasítások egybetartozó sorozata, ami felfogható egy program-egységnek is (amit egyes nyelveken {}-ek között írunk le). Alapvetÿ követelmény a rendszerben a tranzakciók atomisága. A tranzakcióhoz tartozó utasítás-sorozat a "mindent vagy semmit" elven hajtódik végre, vagyis megszakíthatatlanul, oszthatatlanul. Vagy az összes, egy tranzakcióhoz tartozó utasítás lefut, vagy közülük egy sem. Ez a követelmény ahhoz, hogy teljesülhessen, a valós alkalmazásokban gyakran abortálást igényel (amikor a "semmit" ágon folytatódik a végrehajtás), mivel ütköztek az adatokhoz való hozzáférési igények. 3

4. tétel Az egyed-kapcsolat modell A tranzakció határait képezÿ elvi {}-ek a belül lévÿ utasítás-sorozat védelmét szolgálják. Ezek elhelyezése a tervezés lényeges kérdése. A tranzakció-kezel feladatai: atomiság biztosítása következetesség (konzisztencia) biztosítása: adatok "közbülsÿ", tranziens állapota nem megengedett tranzakciók elkülönítése: a véletlenszer en, keveredve érkezÿ tranzakciók hatását el kell szeparálni tranzakció-tartósság: egy sikerrel befejezÿdött tranzakció hatása legyen permanens, állandó; lehessen késÿbb is erre a hatásra, eredményeire építeni. Komoly rendszerhibák ellen is legyen biztosítva a védettség, a DB ne sérüljön. A tranzakció-kezel alapeszközei: zárak: egy tranzakció "lelakatol" egy adatot, adatelemet, és biztosítja, hogy más tranzakció ne dolgozhasson a használt adattal. A tranzakció végeztével a zár feloldódik. A zárral ellátható adatelemek mérete rendszerenként változik, a méret meghatározása külön tervezési szempontokkal rendelkezik. naplózás: a naplóból végigkövethetÿk és "elszállás" esetén rekonstruálhatók a végzett tranzakciók, azaz a DB konzisztens állapotba hozható. érvényesítés: a tranzakciók eredményének érvényességét igazolja. Például a "piszkos adatok" káros hatásait kisz rÿ protokollok tartoznak ide. Vázlatos modellünket bizonyos árnyaló tényezÿk teszik a valódi rendszerekhez hasonlóvá. Ezek közül egy hatékony munkamegosztási eszköz a kliens-szerver architektúra: Kliens kér teljesít Szerver Aklienselÿfeldolgozott SQL kérdést ad a szervernek és táblát kap vissza. Célszer tehát, ha a kliens oldal minél több munkát elvégez, hogy a szervertÿl gyors válaszidÿkkel kaphassa meg az eredményt. A szerverhez való fordulás e módja trendként is felfogható. 1.4. A DBMS-sel kapcsolatos tevékenységek szintjei 1.4.1. Naiv felhasználó Egyszer lekérdezéseket intéz a rendszerhez vagy alkalmazói programokat indít. 1.4.2. DB-programozó Összetett kérdéseket állít össze, alkalmazói programokat ír. Lehetÿsége van arra, hogy árnyaltabban, összetettebben használja ki a rendszer lehetÿségeit. 1.4.3. DB-tervezÿ Tevékenységi körébe tartozik a DB séma kialakítása, az adatok szerkezetének meghatározása, az adatok kapcsolatainak és a fizikai felépítésnek a tervezése. 4

4. tétel Az egyed-kapcsolat modell (Itt húzhatunk egy képzeletbeli vonalat, mert nagy az ugrás a szakmai felkészültségben:) 1.4.4. DBMS-megvalósító Tudja, hogyan kell DBMS-t készíteni, ami már komoly, specializált tudást igényel. 1.5. Amivel mi foglalkozunk 1.5.1. Tervezés: ez az adatmodellezés feladatköre. Ezen belül is szó lesz a következÿkrÿl: ODL: objektumos adatmodellezés Egyed/Kapcsolat megközelítés, modellezés hálós és hierarchikus adatmodellezés relációs adatmodellezés (fontos eleme a modell normalizálása) 1.5.2. Programozás: ORACLE/SQL és alkalmazása (a Szg.labor 6 keretében) 1.5.3. Megvalósítás: szisztematikusan nem, de az alapötletek szintjén vizsgálni fogjuk a kérdést. Szó lesz: a fizikai szervezésrÿl, a lekérdezés feldolgozásáról, és a tranzakciókról. 2. Az ODL-modellez nyelv 2.1. Az adatmodellezésr l általában Az adatmodellezés a DB logikai vázának megalkotását jelenti. Ez fogalmi szint mely az alábbi ábrával írható le: m velet, a valóság egy darabja a. adatmodell leírás b. DB séma adatmodellezÿ eszköz pl. ODL, E/K A folyamat tehát felfogható úgy, hogy egy "a valóság egy darabjáról" - pl. egy cég nyilvántartásáról szeretnénk adatmodellt és arról késÿbb egy DB sémát, azaz konkrét adatbázist készíteni. A DB séma már egy tényleges. értelmezhetÿ kód. A fázisok közötti átmenetek a következÿk: a. adatmodellezÿ eszközöket használva (pl. ODL, E/K) készítjük el az adatmodell leírását 5 DDL

4. tétel Az egyed-kapcsolat modell b. DDL segítségével alakítható ki a DB séma. A folyamat legfontosabb része az a.-ban zajló tevékenység; b. ebbÿl már nagyrészt automatikusan adódik. Az adatmodellezÿ eszköz többé-kevésbé formális jelölésrendszert biztosít adatok, kapcsolataik és a rajtuk végzett mÿveletek kifejezésére. Az adatmodellezés egyes eszközeinek kapcsolata és eredménye: ODL obj.db a valóság egy darabja E/K relációk relációs DB 2.2. Az ODL (Object Definition Language) módszertan 2.2.1. Az ODL elemei: ÿ Lehetÿvé teszi az objektumos DB-tervezést (a módszer közel áll a szabványossághoz); ÿ és része a CORBA-nak, az osztott objektumos számítások tervezett szabványának. 2.2.2. Az ODL tulajdonságai ÿ a világot elsÿsorban objektumokkal írja le. Pl.: Emberek, Termékek, stb. ÿ az objektumok tartalmuktól független azonosítóval, OID-vel rendelkeznek. (Az objektumos világban két azonos példány két különbözÿ elem lehet.) ÿ az objektumokat osztályokba csoportosítja: egy adott osztály objektumai hasonlók ábrázolt tulajdonságaik (típusaik, jellegzetességeik) azonosak képet róluk a rekordsablon alapján kaphatunk. 2.2.3. Az ODL osztály-megvalósításának fÿ tényezÿi: 1. Attribútumok Az osztály-objektumok egyszer bb tulajdonságai egyszer bb típusokkal vannak ábrázolva (egész, valós, mutató, struct, enum, char, string, stb.). Osztály nem számít egyszer típusnak! 2. Kapcsolatok osztályok között Két alapvetÿ formája van: lehet hivatkozás egy (másik) osztály egy objektumára (egyértékÿ kapcsolat), vagy ÿ hivatkozás egy (másik) osztály több objektumára (többértékÿ kapcsolat). 3. Metódusok ÿ Az osztály objektumaira alkalmazott függvények. (A metódusok DB szempontból kevésbé relevánsak, de a modern SW-technológiának központi kérdése a metódusok tervezése és implementálása.) 2.2.4. Az osztálydeklaráció formája az ODL-ben: 6

4. tétel Az egyed-kapcsolat modell interface < Osztálynév > { < jellemzÿk listája > }; Az "interface" kulcsszó az ún. osztálykonstruktor. Példák 1. filmes példa interface Film { attribute string cím; attribute integer év; attribute integer hossz; attribute enum Szalag {színes, feketefehér} szalagfajta; } Tapasztalatok: az attribútumnak van típusa és neve; enum: felsorolás típusú típusneve: Szalag neve: szalagfajta egy objektum képe ennek megfelelÿen: OID +{"Azerÿszak vége", 1998, 122, színes} 2. színészes példa interface Színész { attribute string név; attribute struct Cím { string város string utca} lakcím} típus rekordkonstruktor attribútumnév mezÿ neve mezÿ típusa 2.2.5. Kapcsolatok leírása A kapcsolatok (relationship) osztályszinten más objektumhoz való viszonyokat írnak le. Két alapvetÿ leírási formájuk van: 1. < osztálynév > < kapcsolatnév >, és 2. < kollekció típus > << osztálynév >> < kapcsolatnév >. A kollekció típusa lehet Set, Bag, List, vagy Array. Az 1. leírás azt fejezi ki, hogy az objektum az adott típusú (nev ) kapcsolatban van a megadott osztállyal, a 2. pedig azt, hogy az objektum kapcsolatban van osztályok egy kollekciójával. A kapcsolat megfordítható, annak az objektumnak a szempontjából is megfogalmazható, amivel a kitüntetett objektumunk kapcsolatban áll. Ezt a fordított kapcsolatot (reverse) jelölni is kell, tehát maga a kapcsolat mindkét (ill. valamennyi) érintett objektumnál fel kell tüntetni. Lényeges, hogy a kapcsolat (relationship) - inverz kapcsolat (reverse) páregybetartozó szerkezet, ne válasszuk ÿket külön! Az inverz feltüntetése fontos konzisztencia-tényezÿ. Példák 1. filmes példa (kapcsolat a Film oldaláról) (2.)relationship Set < Színész > szereplÿk; reverse Színész: szerepel benne; 7

4. tétel Az egyed-kapcsolat modell A filmben szereplÿ színészek egy halmazba vannak foglalva. A Filmnek annyi kapcsolata lesz a Színésszel, ahány színész benne játszik. Ez a kapcsolatok leírásának 2. formája. (1.)relationship Színész szereplÿje; reverse Színész: szerepel benne; A kapcsolat leírható az 1. módon is, bár ez nem szerencsés. 2. színészes példa (kapcsolat a Színész oldaláról) relationship Set < Film > szerepel benne; reverse Film: szereplÿk; 3. konkrét adatokkal a kapcsolatok így néznek ki: Film Színész Berlin fölött az ég Bruno Ganz Távol s mégis közel Bruno Ganz Távol s mégis közel Peter Falk Columbo Peter Falk Tanulság: egy színész több filmhez is tartozhat, ill. egy filmhez több színész tartozik. 2.2.6. Kapcsolatok osztályozása Két osztály - pl. C és D - közötti kapcsolat lehet: ÿ egy-több (sok-sok, N:N) típusú: egy C osztálybeli objektumhoz az adott kapcsolatra nézve a D- bÿl több tartozhat, és fordítva. Pl.: C = Film, D= Színész köztük a "szereplÿk", "szerepel benne" kapcsolatok N:N típusúak Ez a kapcsolat-típus a leggyakoribb (strukturálatlan) eset. Az N:N kapcsolat árulkodó jele az ODL-leírásban a két kollekció-operátor. (Színészek halmaza, Filmek halmaza - mindkét oldalon több objektum van megengedve.) ÿ több-egy (sok-egy, N:1) típusú: egy C osztálybeli objektumhoz az adott kapcsolatra nézve legfeljebb egy D-beli tartozhat, de fordított irányban nincs megkötés (egy D-beli több C-belihez is tartozhat). Pl.: C = Film, D = Stúdió köztük a "gyártó" kapcsolat N:1 típusú Jó példa a gyermek-anya kapcsolat is (egy gyereknek legfeljebb egy anyja lehet, de egy anyának lehet több gyereke). Az N:1 kapcsolat árulkodó jele az ODL-leírásban: egyértékÿ kapcsolat C-nél és kollekció D- nél. ÿ egy-több (egy-sok, 1:N) típusú: ez az N:1 kapcsolat fordítottja. ÿ egy-egy (1:1) típusú: egy C osztálybeli objektumhoz az adott kapcsolatra nézve legfeljebb egy D- beli tartozhat, és fordítva. Pl.: C = Stúdió, D = Személy az "elnök" kapcsolat 1:1 típusú, feltéve, hogy egy stúdiónak legfeljebb egy elnöke lehet, és egy személy nem lehet több stúdió elnöke. Figyelem! A"legfeljebb egy" és "pontosan egy" nem ugyanazt jelenti. Az 1:1 kapcsolatban szerencsésebb a "legfeljebb egy"-et kikötni. A kapcsolatok osztályozásánál tehát azt vizsgáljuk, hogy a kapcsolat két oldaláról mennyire függvényszerÿ a kapcsolat (mikor egyértelmÿ a hozzárendelés). Alapvet tehát, hogy "mennyi dolog köt dik mennyihez". A kapcsolatok jó megválasztása rendkívül fontos szemantikai és hatékonysági szempontból is. Megj.: az ODL gyenge értelemben képes többágú kapcsolatot leírni. Pl.: (a felírás megengedi két azonos egyed felvételét) interface Szerzÿdés { attribute integer Gázsi; realtionship Stúdió gyártós; 8

4. tétel Az egyed-kapcsolat modell relationship Színész színész; relationship Film film;} 2.2.7. Típusok az ODL-ben Az ODL az alaptípusokra és bizonyos építkezési szabályokra (melyeket a bonyolultabb adatszerkezetek kialakításához használ fel) támaszkodik. Ezen készlettel (adattípusok + szabályok) rendkívül sokféle feladat megoldható. 2.2.7.1. Alaptípusok: 1. Atomi típusok: a szokásos számítástechnikai adattípusok tartoznak ide, vagyis az egészek (integer), lebegÿpontos számok (float), karakterek (character), karakterláncok (string), logikai értékek (boolean), felsorolt adatok (enum). 2. Interface típusok: ezeket az interface kulcsszó vezeti be (ilyen pl. a Film). 2.2.7.2. Típuskonstruktorok ÿ ezek adják az ODL építkezési szabályait. Tegyük fel, hogy T egy típus. 1. Set < T > típus értéke T típusú elemek véges halmaza. Pl.: Szereplÿk halmaza a Filmnél. 2. Bag < T > típus értéke T típusú elemek véges multihalmaza, vagyis a halmazban lévÿ elemek multiplicitással rendelkezhetnek (az ismétlÿdés megengedett). Akkor használják, amikor a Set nem alkalmazható. 3. List <T > típus értéke T típusú elemek véges - esetleg üres - listája. A Set-tÿl annyiban különbözik, hogy benne fontos az elemek helye, sorszáma. Pl.: string = List < char > 4. Array < T, i > típus értéke T típusú elemek i-hosszú tömbje. 5. Rekordkonstruktor Adott a T 1,...,T n (attribútum) típus-sorozat és az f 1,..., f n mezÿnév-sorozat. Ekkor a Struct N {T1 f1, T2 f2,..., Tn fn} egy N nev, n komponens rekordstruktúra. Az i. komponens (mezÿ) típusa T1, neve fi. Pl. A Színésznél a Cím egy kétkomponens struktúra (rekord). Az 1.-4. típuskonstruktorok az ún. kollekció-operátorok. Ezek valamilyen homogén összességet definiálnak, amelyekben eltérÿ lehet az, hogy megengednek-e ismétlÿdést vagy hogy fontos-e a pozíció, stb. Az attribútumok típusa lehet: ÿ atomi típus, ÿ atomi típusokból álló struktúra, ÿ vagy egy, az elÿzÿekre alkalmazható konstruktor 1.-5. közül. Példa: Array < Struct T...{string név, integer tömeg}, 3 > A kapcsolat típusa lehet: ÿ interface típus ÿ egy, interface típusra alkalmazott konstruktor 1.-4. közül. 9

4. tétel Az egyed-kapcsolat modell 2.2.8. Alosztályok és öröklÿdés Az alosztály egy osztály speciális tulajdonságú objektumaiból jön létre (differenciális specifikációval). Ehhez a tevékenységhez tartozik a szÿkítés és a részképzés. Alosztály jelölése: feltüntetjük a felettes osztály(oka)t. Pl.: filmes példa interface Rajzfilm: Film {relationship Set (Színész) hangok;}; interface Krimifilm: Film {attribute Set < string > bizonyítékok ;}: interface Krimirajzfilm: Rajzfilm, Krimifilm {}; Az alosztály örökli az összes felettes osztály (ún. "szuperosztály") tulajdonságait. Ezek az attribútumok, metódusok és kapcsolatok. Pl.: a Krimirajzfilm örökli a Filmtÿl acímet. Az alosztály-szerkezet hierarchiát definiál (egy felfelé irányított gráfot). Ez nem feltétlenül fastruktúra, bár ez a legjellemzÿbb. Pl.: a filmes példa öröklÿdési gráfja: Film Rajzfilm Krimifilm Krimirajzfilm Az öröklÿdés révén konfliktus merülhet fel, ha egy alosztály többfelÿl örökölhet tulajdonságokat. Pl.: rajzfilm: vég = boldog / szomorú krimi: vég = ítélet / felmentés. Megoldás: átnevezést hajtunk végre a felsÿbb szinteken, vagy újradefiniáljuk a tulajdonságot az alsóbb szinten. (Például, ha a Sokszög - Négyszög - Négyzet alosztály öröklÿdési struktúrát nézzük, akkor célszer a területet alsóbb szinten definiálni.) 2.2.9. Megszorítások modellezése az ODL-ben Általunk az adatok közt további összefüggések is definiálhatók. Ezek ugyanúgy megszorítást jelentenek, mint a séma részei - például az N:1 kapcsolat, mert a kapcsolat másik oldalán egyetlen objektum állhat csak. Amegszorításokfÿtípusai: 1. Kulcsok ÿ Olyan attribútum-halmazok, melyek egyértelm en azonosítják az objektumot. (Ha ismerjük a kulcsok értékét, akkor az azonosítás elvégezhetÿ.) ÿ 0 vagy több attribútum lehet kulcs; ugyanekkor több kulcs is megadható. 10

4. tétel Az egyed-kapcsolat modell ÿ A kulcs általános alakja: interface < osztálynév > (key(s) K 1, K 2,..., K n ) {-}; AK i kulcsleírás alakja: < attribútumnév >; vagy (attr 1,..., attr n ) Példák filmes példa interface Film (key (cím, év)) {-}; dolgozói nyilvántartás interface Dolgozó (keys dolgazon, tbszám) {-} 2. Egyérték ségi megszorítások Azt rögzítik, hogy egy érték (-kombináció) az adott helyzetben egyedi. Pl. a termék meghatározza az árat. Attribútumoknál a kollekció-operátorok mellÿzése szolgál az egyérték ség kifejezésére. Kétfajta értelmezés kapcsolódik az egyérték séghez: ÿ "legfeljebb egy": ez felel meg az N:1 felfogásnak ÿ "pontosan egy": ez már egy "hivatkozási épség" (lásd késÿbb) típusú követelmény. A "legfeljebb egy" értelmezés hatására vezették be a NULL értékeket. Ezen érték azt mutatja, hogy adott esetben megengedett "üresen" hagyni egy attribútum-mezÿt. Pl.: {színes, feketefehér, NULL} - ebbÿl ahalmazbólkerülkiafilmszalagtípusa. HaaNULLérték van megadva, az azt jelenti, hogy a szalag típusa nem ismert. 3. Hivatkozási épség (referential integrity) Az a követelmény, hogy a hivatkozott dolognak léteznie kell (vagyis nem fordulhatnak elÿ "lógó" mutatók, hivatkozások). Lényeges, hogy az ODL a hivatkozási épség kérdését nem kezeli, csupán a megvalósítás szintjén ajánl különbözÿ módszereket: ÿ létrehozáskor kötelezÿ a "pontosan egy" kapcsolat kitöltése; ÿ hivatkozott objektum nem törölhetÿ - ez az ún. gyenge törlési elv (az elÿbbi pont inverze); ÿ a hivatkozott objektum csak a hivatkozóval együtt törölhetÿ. 4. Értelmezési tartomány korlátozása Ezen korlátozások a típusok értelmezési tartományára vonatkoznak! 5. Általános megszorítások Általános követelmények, pl. a kapcsolat fokának korlátozása tartozik ide. Megadhatjuk például, hogy legfeljebb hány színész szerepelhet egy filmben. Ha ez történetesen 10, akkor ez így írható le: relationship Array < Színész, 10 > Szereplÿk; 2.3. Adatmodellezési alapelvek 2.3.1. Valósághÿ modellezés ÿ a fontos adatelemek és ÿ a fontos kapcsolatok is legyenek benne a modellben! 2.3.2. A redundancia elkerülése ÿ Ugyanazt a dolgot két vagy több helyen ne jelenítsük meg az ábrázolt modellben. Ez azért fontos a következ kmiatt: 11

4. tétel Az egyed-kapcsolat modell ÿ helygazdálkodás: nem ez a legfontosabb szempont, de mérlegelni kell; ÿ konzisztencia: akétvagytöbbhelyenlév azonos adatnak minden el fordulási helyén mindig ugyanolyan tartalmúnak kell lennie. Ha ez nem teljesül, akkor anomáliák lépnek fel; ÿ egyszerÿség: a redundancia bonyolítja a modellt. 2.3.3. Megfelelÿ típusú elemek kiválasztása Alapkérdések: ÿ mit reprezentálunk attribútumként? ÿ mit reprezentálunk kapcsolatként? ÿ Amegfelelÿtípusú elemek kiválasztásának szempontjai: ÿ az attribútum: egyszer bb, mint a kapcsolat (hiszen ez direkt köthetÿ alaptulajdonság) ÿ az egyedhalmaz, osztály (azaz a kapcsolat): bonyolultabb, de kifejezÿbb. 3. Az egyed-kapcsolat modell 3.1. Az adatmodellezésr l általában Az adatmodellezés a DB logikai vázának megalkotását jelenti. Ez fogalmi szint alábbi ábrával írható le: m velet, mely az a valóság egy darabja a.) adatmodell leírás b.) DB séma adatmodellezÿ DDL eszköz pl ODL E/K A folyamat tehát felfogható úgy, hogy egy "a valóság egy darabjáról" - pl. egy cég nyilvántartásáról szeretnénk adatmodellt és arról késÿnn egy DB sémát, azaz konkrét adatbázist készíteni. A DB séma már egy tényleges. értelmezhetÿ kód. A fázisok közötti átmenetek a következÿk: a. adatmodellezÿ eszközöket használva (pl. ODL, E/K) készítkjük el az adatmodell leírását b. DDL segítségével alakítható ki a DB séma. A folyamat legfontosabb része az a.)-ban zajló tevékenység; b.) ebbÿl már nagyrészt automatikusan adódik. Az adatmodellezÿ eszköz többé-kevésbé formális jelölésrendszert biztosít adatok, kapcsolataik és a rajtuk végzett mÿveletek kifejezésére. Az adatmodellezés egyes eszközeinek kapcsolata és eredménye: a valóság egy darabja ODL E/K obj.db relációk relációs DB 12

4. tétel Az egyed-kapcsolat modell 3.2. Az Egyed/Kapcsolat (E/K) modell Nevezik még Tárgy/Kapcsolat,vagyEntitás-relációs modellnek is. Az E/K modell nem teljeskör, mert nem tartalmaz m veleteket. Elÿnye viszont az, hogy látható formába önti a DB modelljét, vagyis jobban átlátható, mint az ODL formális leírásmódja. Elsÿdleges leírást ad, ami könnyen - jórészt gépiesen - finomítható igazi DB sémáig. Az E/K modell alapfogalmai 1. Egyedhalmazok (tárgy-, entitáshalmazok) Közelítÿleg az egyedek az objektumoknak, az egyedhalmazok pedig az osztályoknak felelnek meg. (A különbség, mint tudjuk, az, hogy az objektumoknak mindig van azonosítójuk.) Egyedhalmaz lehet bármi, aminek egyedei azonosíthatók. Az E egyedhalmaz jelölése: Például: E Film 2. Attribútumok Ezek az egyedek jellemzésére szolgáló egyszer - azaz egyszer típusú - tulajdonságok. (Egyes nézetek szerint attribútum nem lehet rekordtípus - aminek az ODL-ben nem volt akadálya.) Ha az E egyedhalmaz attribútumai rendre az A 1,...,A k attribútumok, akkor a formális jelöléssel: E(A 1,...,A k ). Rajzban: E A k A 1 A 2... Példa: az ODL-nél megismert Film az E/K modellben cím év Film hossz 3. Kapcsolatok 13

4. tétel Az egyed-kapcsolat modell Az egyedhalmazok közötti viszonyok kifejezésére szolgálnak. Jelentös eltérés az ODL-hez képest az, hogy az E/K modell megenged sokágú kapcsolatokat - nem úgy, mint az ODL, ami csak kétszereplÿs kapcsolatokat ábrázol. Az E 1,...,E m egyedhalmazok közti R nev kapcsolat jelölése: R(E 1,...,E m ). (Az egyedhalmazok sorrendjének nincs lényegi szerepe.) Rajzban a kapcsolat nevét rombuszba foglaljuk: E m.. Példák 1. Film-Színész kapcsolat:. R E 3 E 2 E 1 cím év név Film Szereplÿk Színész hossz szalagfajt Megj.: az ODL-ben a lakcím rekordként volt definiálva. Itt ez nem megy! 2. Nemzetközi munkamegosztás Cég Ország Termel Termék Egy cég termékeit több országban is termelheti / értékesítheti. Ez egy m=3 komponens kapcsolat. 14

4. tétel Az egyed-kapcsolat modell 3. a filmes példa továbbfejlesztése gázsi Film Szerzÿdés Színész Stúdió A filmet egy adott stúdió forgatja; erre a produkcióra szerzÿdik a színész. Ha a "gázsi" attribútumot szerepeltetni akarjuk az ábrán, akkor az csak a Szerzÿdés nev kapcsolathoz köthetÿ,mert: ÿ egy filmhez több színész és így gázsi tartozik; ÿ egy stúdió több filmet forgat; ÿ egy színész több filmben játszik. Tapasztalat: kapcsolatnak is lehet attribútuma. (Bár ez új egyedhalmaz felvételével kiváltható.) Kapcsolatok típusa az E-K modellben A kapcsolatok típusa megegyezik az ODL-ben ismertetett típusokkal, csak a jelöléstechnika más - a függvény-jellegre nyíl utal. 1:1 kapcsolat N:1 kapcsolat N:N kapcsolat R E 1 E 2 R E 1 E 2 Pl.: Személy - Stúdióvezetó kapcsolat ("elnök") mindkét végén nyíl Pl.: Gyermek -Anya kapcsolat ("anyja") csak egy nyíl R E 1 E 2 nincs nyíl Az N:1 (több-egy) kapcsolat értelmes lehet kettÿnél több komponens példa - nyíl a Stúdió felé.) kapcsolatnál is. (Lásd: filmes Általánosan: az R(E 1,...,E k ) több-egy kapcsolatban a nyíl E j felé mutat, ha tetszÿlegesen választott e E(i j) egyedkollekcióhoz legfeljebb egy olyan e j van, amivel (e 1,...,e j,...,e n ) R. Azaz a maradék - nyíl által nem mutatott - komponenseket (egyedeket) egyféleképp egészíthetjük ki úgy, hogy egy relációt kapjunk. 15

4. tétel Az egyed-kapcsolat modell Sokágú kapcsolat átalakítása kétágú (több-egy) kapcsolattá Menete: R E 1 E 2 => E 1. E 1-k R ' E 2-k E 2 E k-k. E 2 R' - melyet kapcsoló halmaznak szokás nevezni - elképzelhetÿ úgy, mint egy k mutatót tartalmazó egyedhalmazt. R'-nek gyakran nincs attribútuma (ekkor gyenge egyedhalmazról beszélünk). Példa: a Szerzÿdés kapcsolat átalakítása N:1 típusúvá (számunkra ez jobb) Színész Film Sz Szerz dés F S gázsi Stúdió 16

4. tétel Az egyed-kapcsolat modell Örökl dés, alosztályok az E/K modellben Tfh. az E 1 egyedhalmaz sz kítése az E 2 -nek. Ezt jelölhetjük ezekkel: is-a vagy az egy is-a vagy az egy magyar Az alárendelt egyedhalmaz örökli felmenÿi attribútumait. Egy "objektum" nem feltétlen egy "osztályyhoz" tartozik. Példa: Film, Rajzilm, Krimifilm cím év hossz Színész Film Hangok is-a is-a bizonyíték Rajzfilm Krimifilm Itt nincs szükség külön Krimirajzfilm egyedhalmazra. Pl. ha a "Macskafogó" a krimirajzfilm, akkor lesz egy neki megfelelÿ Rajzfilm és egy Krimifilm egyed is, melyek ugyanoda, ugyanarra a filmre fognak mutatni, azaz közös apjuk lesz. Megszorítások az E/K modellben 1. Kulcsok a rajzból indulunk ki, ezért fontos, hogy az egyszer legyen - ami a séma egyszer ségét is mutatja. a rajzon csak egyetlen kulcsot jelölünk: ez az ún. elsÿdleges kulcs (primary key) a nem elsÿdleges (azaz másodlagos) kulcsokat a modell külön leírásban tünteti fel. 17

4. tétel Az egyed-kapcsolat modell Pl. a Filmet a címe és a gyártási éve azonosítja, tehát itt a (cím,év) pár az elsÿdleges kulcs (amit aláhúzással jelölünk). Film cím év hossz 2. Egyérték ség ajánlás: használjunk egyérték attribútumokat! a NULL érték alapértelmezésben megengedett, kulcsokban azonban nem (aminek nem is lenne sok értelme, ha jól belegondolunk) a NULL érték tiltását külön leírás tartalmazza az N:1 jelleget nyilak fejezik ki. 3. Hivatkozási épség A "pontosan egy" kapcsolatot lekerekített nyílhegy jelöli. Példák: 1. Egy filmnek kötelezÿen van egy (pontosan egy) gyártó stúdiója Film Gyártó Stúdió 2. Minden stúdiónak pontosan egy elnöke van, azaz nem létezhet stúdió elnök nélkül. Egy elnök legfeljebb egy stúdióhoz tartozhat. Stúdió Vezeti Elnök 3. A kapcsolat fokának korlátozása Pl.: <= 3 Hajóraj Része Flotta (mindkét nyílfajta értelmes) Azt szabályozza, hogy egy egyedhez legfeljebb hány másik kapcsolódhat. A példában: egy flottához legfeljebb 3 hajóraj tartozhat. Gyenge egyedhalmazok Gyenge egyedhalmazról beszélünk, ha egy egyedhalmaz egyedei önmagukban nem, csak kapcsolataikon keresztül azonosíthatók. 18

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Egy több komponens kapcsolat átalakításakor a kapcsoló rekordot így jelöljük: Ennek az azonosításban résztvevÿ kapcsolatait pedig így: Követelmények: ha az F egyedhalmaz hozzájárul az E gyenge egyedhalmaz kulcsához, akkor azt az megfelelÿ R (N:1) kapcsolattal együtt így kell ábrázolni (F is lehet gyenge egyedhalmaz): E R F az E azonosítására szolgáló F-beli attribútumok elemei F kulcsának is. Példa: szervezeti egységek részegységekbÿl - csoportokból - épülnek fel. A csoportokat számukkal írjuk le (ez egyetlen attribútumuk): szám név cím Csoport Része Stúdió A Csoport gyenge egyedhalmazt jelöl: ennyi attribútummal (szám) önmagában nem azonosítható, csak a "Része" kapcsolatot követve a Stúdió alapján. Ha a Csoportba bekerülne a stúdiónév (azonosító!) is, akkor további redundanciaprobléma is felmerülhetne (inkonzisztens nevek: a névváltozást nem minden elÿfordulásában követjük). 3. Adatmodellezési alapelvek 1. Valóságh modellezés a fontos adatelemek és a fontos kapcsolatok is legyenek benne a modellben! 2. A redundancia elkerülése 19

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Ugyanazt a dolgot két vagy több helyen ne jelenítsük meg az ábrázolt modellben. Ez azért fontos a következÿkmiatt: helygazdálkodás: nem ez a legfontosabb szempont, de mérlegelni kell; konzisztencia: a két vagy több helyen lévÿ azonos adatnak minden elÿfordulási helyén mindig ugyanolyan tartalmúnak kell lennie. Ha ez nem teljesül, akkor anomáliák lépnek fel; egyszerÿség: a redundancia bonyolítja a modellt. 3. Megfelelÿ típusú elemek kiválasztása Alapkérdések: mit reprezentálunk attribútumként? mit reprezentálunk kapcsolatként? Amegfelelÿtípusú elemek kiválasztásának szempontjai: az attribútum: egyszer bb, mint a kapcsolat (hiszen ez direkt köthetÿ alaptulajdonság) az egyedhalmaz, osztály (azaz a kapcsolat): bonyolultabb, de kifejezÿbb. 4. Egyed-kapcsolat sémák átalakítása relációs, hálós és hierarchikus sémákká 1 1. E/K - relációs séma átalakítás Az átalakításra van egy teljesen gépies út, ami azonban nem adja mindig a legjobb megoldást. Egyed: E(A 1,...,A k ) R(A 1,...,A k ) Reláció Az egyed egy az egyben átalakítható relációvá (k-oszlopos táblává). E R(A 1,...,A k ) A 1... A k Bonyolultabb átalakítás: E 1 E m R E 2..... R(A 1,...,A s,b 1,...,B l,..., S 1,...,S t ) E 1 kulcsa E 2 kulcsa E m kulcsa 1 ez egy innen-onnan összeszedett tétel, a témával kapcsolatban ezt találtam! 20

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Hogyan kaphatunk jó átalakított relációs sémát? ábrázoljunk minden információ-elemet! a fontos igényeket kifejezÿ m veletek legyenek hatékonyak! Például: ne kelljen túl sok helyrÿl összeszedni egy fontos lekérdezés adatait. 2. E/K - hálós séma átalakítás Tétel: minden E/K diagram átalakítható hálós diagrammá, azaz felrajzolható kizárólag kétkomponens N:1 kapcsolatok (kapcsoló rekordok) felhasználásával. Ez a megállapítás már az E/K modellben is szerepelt, amikor a több-több kapcsolatok számunkra kedvezÿbb, több-egy kapcsolatokká való átalakításáról beszéltünk. Mintapélda: E/K - hálós átalakításra Modellünkben egy kereskedelmi adatbázist ábrázolunk, melyben a Szállító és Megrendelÿ közötti kapcsolat az attribútumként felvett terméken ill. az Ár és Rendelés reláción keresztül valósul meg. E/K Hálós sznév szcím Szállító Szállító Ár' SZ_Á TERÁR Ár egys_á Termék TERREN termék Rendelés SZEMREN szám Rendelés menny Személy Megrendel név cím egyenleg 21

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban 3. Hierarchikus séma átalakítása Állítás: minden hálós séma átírható hierarchiákká (amely m veletben általában VRT-kre is szükség van). Az állítás bizonyítását egy példán keresztül mutatjuk be: 1. Hálós séma -> hierarchia A D A B C E B C D vd vb E ve va Az átíráskor minden rekordtípust és nyilat ábrázolunk. Kijelöljük az elsÿ gyökeret - ez általában egy nagy be-fokszámú rekordtípus. (Itt: A) Az átalakítással gyakran nem kapunk "szép" fát, sokszor nem is lehet a feladatot egyetlen fával megoldani. Ezért célszer vagy szükséges is lehet több gyökeret választani. 2. Hierarchia -> hálós séma B A B D A C va va vc C D Az eredmény több fa lett. A módszer elvileg jó, de nem ad túl értelmes megoldást. (Hármas lépcsÿben nemigen kérdezünk.) 22

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban 5. Az alapvet fizikai tárolási szerkezetek összehasonlítása 1. Alapfogalmak A fizikai szervezés célja, hogy egy rekordokból álló állomány kezelése megoldható legyen a következÿ m veletekkel: beszúrás, törlés, keresésé, módosítás. Ez a külsÿ táras (diszkek, dobok) adatkezelés kérdésköre. A fizikai szervezés elemei: ÿ blokk (lap): fix méretÿ adatterület, tipikusan k. 512 byte (ált. k=1,...,10) méretÿ (ez egy rendszerenként változó paraméter). A blokk számunkra egyetlen I/O mÿvelettel elérhet tárterületet jelent. Egy blokk több rekordot tartalmazhat. A blokkok elérése történhet abszolút vagy relatív cím alapján. A küls táras módszerek hatékonyságát a blokk(lap-)elérések számában mérjük. Tipikus blokkfelépítés: menedzsment információk fej rek 1... rek n maradék ÿ mutató (pointer): bejegyzés, ami egy blokk / rekord címét tartalmazza blokk / rekord ÿ ÿ kötött rekord / blokk: mutat(hat) rá mutató. (Ellentéte: szabad rekord / blokk.) Pl. a 2-3 fáknál a csúcsvágás mÿvelete nem végezhet korlátok nélkül, mert "lógó", semmibe mutató pointerek keletkezhetnek. rekord: kétféle lehet 23

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban ÿ ÿ rögzített formátumú (ez a tipikus eset): a mez k száma és hossza fix. Ekkor a rekord felépítése: menedzsment információk fej mezÿ 1 mezÿ 2... fix változó hosszúságú: kétféle alkalmazási módjuk: fix mezÿszerkezet változó hosszúságú mezÿkkel: például regények text adatbázisában egy egész könyv szövege szerepelhet egy mezÿben. szerzÿ cím szöveg fix fix változó Ez a struktúra kizárólag fix hosszúságú mezÿkkel így írható le: A rekordban szerepelhetnek azért fix hosszúságú mezÿk is, ha ezek hosszára található valamilyen ésszer szerzÿ cím szöveg_mutató fix fix Itt a szöveg-mutató mezÿ egy kevéssé struktúrált másodlagos szövegállomány meghatározott mezÿjére tartalmaz egy mutatót. ÿ ismétlÿdÿ mezÿ csoportok (többérték mezÿk): a rekordok mezÿszerkezete nem egységes. Például: filmek adatait tároljuk változó hosszúságú rekordokban. A változó hossz alkalmazását az indokolja, hogy nem lehet elÿre tudni, hogy az egyes filmeknek hány szereplÿje van. További mezÿkre bomlik Azt, hogy egy mezÿt többször (ebben benne van a 0 is!) ismételi kell, a * jelöléssel ábrázoljuk. Itt: Film(Cím, Év, Szereplÿ*) a változó hosszúságú rekord leírása. Ezen felül a többérték mezÿk tárolási módszerei a következÿklehetnek: 1. Foglalt hely technika: minden ismétlÿdésnek elÿre helyet kell foglalni. Például az egy filmben szereplÿ színészek számát 30-ban maximáljuk. Ekkor a Szereplÿkmezÿ30 mezÿre bomlik szét: 2. Mutató módszer: egyetlen mutató mezÿt kell lefoglalni, amely egy, az ismétlÿdÿ elemeket tartalmazó listára fog mutatni. A mutató tehát kimutat az eredeti állományból. Például: fix... szöveg... Film Cím Év... Szereplÿk Film Cím Év... Szereplÿ1... Film Cím Év... 24... Szereplÿ-lista

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban 3. Kombinált módszer: valamennyi ismétlÿdésnek elÿre helyet foglalunk úgy, hogy az esetek döntÿ többségében a lefoglalt hely elégnek bizonyuljon (de ne legyen feleslegesen nagy), és ne kelljen mutatók mentén keresgélnünk. A bÿvítés lehetÿségét az utolsó lefoglalt mezÿ biztosítja, amiben egy listára mutató pointer foglal helyet. Például: C db színész számára méretezzük a rekordot: Film Cím Év... Szereplÿ1... SzereplÿC állomány: blokkokon elhelyezkedÿ információtárolási szerkezet. Az állomány blokkjai elérésfolytonosan helyezkednek el a diszken - így van értelme a következÿ blokk (lap) fogalmának. A rendszer a következÿ lapot különbözÿ mechanizmusokkal határozhatja meg. Az állomány felépítése: lap 1 lap 2... lap n Szereplÿ-lista ÿ ÿ kulcs: a fizikai szervezés is ismeri a kulcsok fogalmát, de az eddig megismerthez képest más jelentéssel ruházza azt fel. A kulcs bizonyos kitüntetett mezÿk összessége, ami a keresés alapjául szolgál és gyakran - de nem mindig - meghatározza a rekordot. elérési módok: elsÿdleges elérés: a rekordok keresése, elérése elsÿdleges kulcs szerint történik. másodlagos elérés: ide tartozik a rekordok elérésének minden más módja. Az elérési módok tárgyalásánál szokás az állományok "invertálásáról" beszélni. Ha egy állomány nemcsakazelsÿdleges kulcs (pl. név) adta logikával áll rendelkezésünkre, hanem valamilyen másodlagos kulcs szerint is, akkor azt mondjuk, hogy az állomány az adott másodlagos kulcs (pl. telefonszám) szerinti inverzével dolgozhatunk. 2. Alapvetÿ fizikai szervezési elvek Ezek a következÿk: 1. Kupac (heap) (az alábbi kettÿrÿl a következÿ tételben lesz szó:) 2. Hash 3. Indexelt szervezés. 1. Kupac (heap) Általában kis állományok fizikai szervezésére szolgál. Az állomány lapjai így helyezkednek el: Új rekord beillesztése az utolsó rekord utáni elsÿ szabad helyre történik. A módszer a törlést "törölt" bit használatával oldja meg. A keresés elérés-folytonos, az alkalmazott operációs rendszertÿl függetlenül van megoldva a DBMS által. A rendszer a rekordot az állomány elejétÿl keresi mindaddig, míg meg nem találja (legrosszabb esetben az sikertelenül az állomány végére ér). 25 új rekord

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban ÿ A sikeres keresés általánosan a blokkok felét érinti; ÿ a sikertelen keresés általánosan az összes blokkot megnézi. A kupac-szerkezet fenntartásához szükséges munka nem túl nagy, de a szerkezet bonyolódásával növekszik. Az adatbázis-állományok "pályafutásukat" kezdhetik kupacos szervezésben, növekedve pedig új formát, szerkezetet kaphatnak. 6. Hashelés és ritka indexes szervezési módszerek 1. Adatbázisok alapvetÿ fizikai szervezési elvei Ezek a következÿk: 1. Kupac (heap) (errÿl azelÿzÿrételben már volt szó) 2. Hash 3. Indexelt szervezés. 2. Hash-szervezés Elsÿsorban a vödrös (bucket) hash-elés és változatai használatosak. Az alapmódszerben adott: Bdbvödör (egy vödör egy kis - kevés lapból álló - lap-láncot jelent); egy vödörkatalógus (0-tól (B-1)-ig indexelt tömb) és a h: {kulcsok} -> [0,B-1] hash-függvény, mely legyen gyorsan számítható és ne okozzon túl sok ütközést (ütközés: két kulcshoz h ugyanazt a tömb-cellát rendeli) Ábrázolva: 0... i....... vödör vödörkatalógus A hash-függvény a K kulcsú rekordhoz az i. vödröt sorsolja: h(k) = i. A keresés a sorsoláshoz egész hasonlóan zajlik: a K' rekordot keresve ki kell számítani a h(k') értékét és a megfelelÿ vödörhöz kell fordulni. Ez a módszer átlagos értelemben igen jó (a vödrök nem lesznek túl kicsik / túl nagyok); átlagban konstans lapelérés elég. Tipikusan B-t prímnek választják, és a hash-függvényt így határozzák meg: h(k) := K (mod p). Az alapmódszer hibája, hogy statikus: rögzítve a vödörkatalógus méretét elÿfordulhat, hogy túl hosszú lap-láncok alakulnak ki a vödrökben, vagyis a szervezés nem követi dinamikusan az állomány méretváltozásait. Javaslatok a statikusság kiküszöbölésére: 1. Dinamikus hash-elés 26

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Ötlete: a szófa és a vödrös hash-elés ötvözete segít. h(k)-t fogjuk fel úgy, mint egy bitsorozatot. A szerkezet így épül fel: 0 vödör 1 azon rekordokat tárolja, melyekre h(k) = 00... 00... 0 1 mindegy vödör 2 1 01... vödör 3 1... A vödrök itt is lap-láncok, de méretük fix (bár rendszerenként más és más lehet). Keresés: h(k) bitjeit olvasva lehet megtalálni a kívánt vödröt és benne a megfelelÿ lapot. Kezdÿállapot: vödör 2 1... Ha egy vödör megtelik, akkor szét kell vágni. Például a 01... kezdet, 2-es számú vödör telt meg. Ebbÿl csinálunk két vödröt a 010... és 011... -gyel kezdÿdÿ lapok számára. 0 1 Van értelme a testvér-vödrök összevonásának is. Ha törlünk egy vödörbÿl, akkor megnézzük a testvérét: ha együtt jobban ki vannak töltve, akkor érdemes összevonni ÿket. Természetesen a dinamikus hash-elés az alapmódszernél nehézkesebb és költségesebb. Ez részint attól is függ, hogy mi kerülhet be a belsÿ memóriába (esetleg az egész szerkezet vagy csak a gyökérhez közeli csúcsok, stb.). A költséget ezért nehéz pontosan megbecsülni. 2. Növelhetÿ (extendable) szervezés A módszer paramétere: d pozitív egész szám, ez a katalógus globális mélysége. A katalógusnak ekkor 2 d számú bejegyzése lesz. h(k) továbbra is egy bitsorozatnak tekinthetÿ. A szerkezet így épül fel d=3 esetén: 000... 001... 010... 011...... 0 1 0 1 1 vödör 3 1... vödör 1 0... vödör 1 00... vödör 0 21 010... vödör 22 011... 27 A rendszer fenntart egy-egy vödröt a 0-val és 1-gyel kezdÿdÿ hash-függvény lapoknak. Ha ez az elválasztás nem lehetséges a következÿ (jelen esetben a harmadik) bitnél, akkor egy bittel tovább kell nézni a h(k) értékeket. A legrosszabb esetben ez a megkülönböztetés sosem ejthetÿ meg (de ennek nagyon kicsi a valószín sége). d' 3 vödör d' 2 vödör

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban d' a lokális mélység. Pl. d'=3=d => a katalógus elemeit címzÿ háromjegy cím mindhárom bitjére szükség van a vödörben; benne minden rekord 000-val kezdÿdik. Ha d'=2, akkor az azt jelenti, hogy itt elég 2 bit a rekord eléréséhez, elhelyezéséhez. A szervezés során mindvégig igaz, hogy d<= d'. Tehát a globális mélység a használható, alokális mélység pedig a használt bitek számát jelenti. Túlcsordulás esetén a vödör lapjait két vödörben próbáljuk elhelyezni. d nÿ (azaz új, nagyobb táblát készítünk), ha a d' lokális mélységÿ vödör túlcsordult; ÿ d csökken (azaz új, kisebb táblát készítünk), ha minden d' < d. 3. Indexelt szervezés A módszer kihasználja a kulcsok rendezettségét és alapvet Adott a tényleges, tárolni kívánt "fÿ" állomány ("nagy" rekordokkal). Felette helyezkedik el az index állomány, mely(kis) index rekordokból áll. A kett közötti összefüggések segítik a lapok elérését. Az index rekordokból - kis méretük miatt - sok férhet el egy lapon. mÿveletek megvalósítására szolgál. Index állomány F állomány Rekordok rendezettségi sorrendje (a sorrendben lehetnek, s t, jó indexeknél vannak is hézagok) Az index rekord felépítése: Kulcs igazi rekordkulcs általában egy lapra mutat (ez lehet az index [bonyolultabb] vagy a f állomány [egyszerÿbb] egy lapja) Az indexelés fajtái: a. Egyszintes ritka indexelés (ISAM) ÿ az index rekordok kulcs szerint rendezve vannak az index állományban elhelyezve; ÿ mutatójuk a f állományba mutat. Kapcsolat a mutató és a mutatott rekord között: K m index rekord K K'... rek 1 rek 2... a f állomány egy Kazels (legkisebb) kulcsérték a mutatott lapon. 28

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Keresés: a K kulcsú rekordot keresve az index állományban megkeressük a legnagyobb K' kulcsú index rekordot, amelyre K<=K'teljesül. Ekkor biztosak lehetünk abban, hogy K' mutatóját, m- et követve megkapjuk az "esélyes lapot", ahol K rekordja talán megtalálható - feltéve, hogy egyáltalán része a szerkezetnek. A ritka indexrekordok között - kihasználva a rendezettséget - kereshetünk (feltéve, hogy N db index lap van): ÿ lineáris kereséssel: az index állományt az elejét l kezdve szekvenciálisan járjuk be. A keresés id igénye az index lapok számával arányos, ~ N lapelérés (N<<f állomány lapjainak száma). ÿ bináris kereséssel: felezéses módszerrel járjuk be az index állományt. Az id igény ~ logn lapelérés. ÿ interpolációs kereséssel: (pl. a telefonkönyvben így keresünk) szükség van valamilyen tárolt tudásra, statisztikára az index állomány bejárásában. A keresés jósága ennek a tudásnak a min ségéhez mérhet, ~ loglogn lapelérés. A további mÿveletekben lényeges, hogy mennyire mozgathatók a f állomány rekordjai: szabadok avagy kötöttek. Tegyük fel hogy a f állomány rekordjai szabadok, vagyis lógó mutatóktól nem kell tartani (a f állomány rekordjaira csak az index rekordok mutatói mutatnak). ÿ beszúrás: a rekordok helyét kereséssel határozzuk meg. Túlcsordulás esetén lapvágást kell végezni (ez a B-fáknál megismert módszert jelenti) és ennek megfelel en új index rekordot létrehozni - ami esetleg az index állományban is lapvágást okozhat. ÿ ÿ kilistáztatására szolgál. új törlés: a lapvágás inverzét, a lapösszevonást kell alkalmazni szükség esetén. tólig: a szervezés támogatja ezt a mÿveletet, ami adott kulcs-értékek közötti rekordok A stratégia következménye, hogy a lapok legalább félig telítve lesznek a f állományban. Ha a f állomány tömör, akkor a fenti mÿveletek nehézségekbe ütköznek. Ezért találták ki a módszer statikus változatát (kötött rekordokra). b. Egyszintes ritka indexelés - statikus változat Itt az index állomány el re elkészül; az index rekord pedig nem a f állomány egy lapjára, hanem egy "lap-oszlopára", listájára mutat. index állomány lapvágás A B... Itt nincs szükség vágásra és összevonásra; a f állomány rekordja nem mozdul és az index sem változik.... A ritka index szabad és kötött változata között a költség szempontjából drámai különbség van. 29

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban További módszerek: (a köv. tétel anyaga) c. Többszintes indexelés d. Sÿrÿ indexelés 7. B-fák és sÿrÿ indexek 1. Adatbázisok alapvet fizikai szervezési elvei Ezek a következÿk: 1. Kupac (heap) 2. Hash 3. Indexelt szervezés (ennek további módjairól lesz most szó). 2. Indexelt szervezés A módszer kihasználja a kulcsok rendezettségét és alapvetÿ m veletek megvalósítására szolgál. Adott a tényleges, tárolni kívánt "fÿ" állomány ("nagy" rekordokkal). Felette helyezkedik el az index állomány, mely(kis) index rekordokból áll. A kettÿ közötti összefüggések segítik a lapok elérését. Az index rekordokból - kis méretük miatt - sok férhet el egy lapon. Index állomány Fÿ állomány Rekordok rendezettségi sorrendje (a sorrendben lehetnek, sÿt, jó indexeknél vannak is hézagok) Az index rekord felépítése: Kulcs igazi rekordkulcs általában egy lapra mutat (ez lehet az index [bonyolultabb] vagy a fÿállomány [egyszer bb] egy lapja) Az indexelés fajtái: a. Egyszintes ritka indexelés (ISAM) b. Egyszintes ritka indexelés - statikus változat (ezekrÿl már az elÿzÿ tételben esett szó) c. Többszintes indexelés Ötlet: az index állomány fölé tegyünk egy (vagy több) újabb index állományt! 30

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Index állomány Index állomány Fÿ állomány A felsÿindex állomány ritka indexe az alatta lévÿnek. Ha az index állomány túl nagy lett (vagyis a fÿ állomány hatalmas), akkor a szerkezet fölé teendÿ egy újabb index állomány. A dinamikus többszint indexek B-fákkal valósíthatók meg Az index állomány szintek ún. index fát alkotnak: Index fa Fÿ állomány gyökér szint i. index szint utolsó index szint Tulajdonságok: ÿ minden lap legalább félig telítve van (ez alól csak az egész kicsi szerkezetek jelentenek kivételt); ÿ a gyökér-levél utak egyforma hosszúak (ez egy kiegyensúlyozottsági tényezÿ); ÿ a keresés logaritmikus; a logaritmus alapszáma attól függ, hogy hány index rekord fér egy lapra (tehát nem az elágazások száma befolyásolja); ÿ a módszer teljesen dinamikus - elkerüljük ezáltal, hogy egy nagy állomány közepébe ugorjunk. Ezt a szervezési módot az egyes SW-cégek többnyire szabványosítják - ilyen például az IBM VSAM szabványa, amelyben B-fákat használnak. d. S r indexelés Afÿállomány minden rekordjához tartozik index bejegyzés. index állomány Fontos, hogy itt nem tételezünk fel semmiféle rendezettséget a fÿ állomány rekordjaival kapcsolatban! rek 1 rek2... rek n fÿ állomány Asÿrÿindexelés célja, hogy a kötött fÿ állományt felszabadítsuk: ritka index A s r indexre építünk valamilyen elérési utat, például egy ritka indexet. s r index szabad rekordok Fÿ állomány kötött rekordok 31

9. tétel Tárolási struktúrák és sémakezelés hálós adatbázisokban Asr indexelés tehát önmagában nem egy új elérési technika, hanem csak egy segédeszköz a fÿ állomány felszabadítására. Ez "szabadság" a módszer fÿ elÿnye, hiszen a s r index állomány rekordjait úgy mozgathatjuk, ahogy csak akarjuk. Ha fontos számunkra a fÿ állomány rekordjainak különbözÿ kulcsok szerinti gyors elérése, akkor a fenti s r indexes szervezés egyenesen el sem kerülhetÿ, nem csak praktikus szempontok miatt van rá szükség. Például: többféle elérési logikát használunk a fÿ állomány elérésére (név és telefonszám szerint is akarunk keresni) B-fa név szerint s r index 1. hash tel.szám szerint s r index 2. fÿ állomány [név, telefonszám,...] As r indexek használatának hátránya, hogy a fÿ állomány fölé egy plusz szintet iktat, ami azt jelenti, hogy extra lapelérésekre van szükség. A helyzet azért nem olyan rossz, mert ez a veszteség nem mindig számottevÿ. Ez abból ered, hogy az index rekordok gyakran sokkal kisebbek, mint a fÿ állomány rekordjai - hiszen csak rekord kulcsokat és mutatókat tartalmaznak -, és így több fér belÿlük egy lapra. Ha például B-fával szervezzük az indexet, akkor a fa alapja keskeny lesz és a kiegyensúlyozottsági tulajdonságból fakadóan a magassága sem lehet túl nagy. Mindebbÿl az következik, hogy az extra lapelérések száma sem lesz jelentÿsen nagy, vagyis a keresési sebesség döntÿen nem csökken. 3. Keresés részleges információ (Partial Match) alapján Az elsÿdleges elérések - és a legtöbb másodlagos is - valamilyen rekord kulcs (pl. személyi szám) alapján keresnek az állományokban. Részleges információra alapuló keresésnél azonban az elérés nem kulcs-szer információ alapján történik. Ennek megfelelÿen az elérés már nem lesz olyan gyors, mint a kulcs-alapú kereséseknél. Módszerei: 1. Többszörös (másodlagos) indexek alkalmazása Többféle szempont szerint férünk hozzá az állományhoz, és ennek megfelelÿen többszörös indexeket használunk. (Például egy személy adatainak lekérdezése történhet név, cím, vagy telefonszám alapján is.) Ez egy célravezetÿ, de nagyon sok extra munkát igénylÿ módszer (gondoljunk csak a többszörös indexek követésére és a beillesztések elvégzésére). 2. Particionált hash-függvények alkalmazása A hash-függvényt úgy kell kialakítani, hogy ellenÿrizhetÿ módón a h függvény valamennyi rekord-mezÿbÿl számítható legyen. Vagyis nyomon követhetÿvé kell tenni h(k) kiszámításában az egyes mezÿk hozzájárulását. (K-val most a rekordot jelöljük, h(k)-t pedig egy N-hosszú bitsorozatként foghatjuk fel.) K= m 1 m 2... h 1 h 2... h n "kis" hash-függvények b 1 b 2... b n bitek h(k) = h 1 (m 1 )+h 2 (m 2 )+...+h n (m n ) "nagy" hash-függvény; eredménye Σbi bit hosszú 32