AZ OSZTOTT LEKÉRDEZŐ NYELV BABEŞ BOLYAI TUDOMÁNYEGYETEM, KOLOZSVÁR MATEMATIKA INFORMATIKA KAR INFORMATIKA SZAK ÁLLAMVIZSGA DOLGOZAT KÉSZÍTETTE BUZOGÁNY LÁSZLÓ TÉMAVEZETŐ DR. CSÖRNYEI ZOLTÁN EGYETEMI DOCENS EÖTVÖS LORÁND TUDOMÁNYEGYETEM, BUDAPEST INFORMATIKA KAR PROGRAMOZÁSI NYELVEK ÉS FORDÍTÓPROGRAMOK TANSZÉK KOLOZSVÁR, 2004
LIMBAJUL DE INTEROGARE DISTRIBUITĂ UNIVERSITATEA BABEŞ BOLYAI, CLUJ-NAPOCA FACULTATEA DE MATEMATICĂ ŞI INFORMATICĂ SPECIALIZAREA INFORMATICĂ LUCRARE DE DIPLOMĂ ABSOLVENT BUZOGÁNY LÁSZLÓ COORDONATOR ŞTINŢIFIC DR. CONF. CSÖRNYEI ZOLTÁN UNIVERSITATEA EÖTVÖS LORÁND, BUDAPESTA FACULTATEA DE INFORMATICĂ CATEDRA DE LIMBAJE DE PROGRAMARE ŞI COMPILATOARE CLUJ-NAPOCA, 2004
Tartalomjegyzék Technikai előszó...7 Előszó...9 1. HONNAN SZÁRMAZIK AZ ÖTLET?...11 1.1. Az osztott komponenscsomag története...12 1.1.1. A végzetes feladat...12 1.1.2. Dilemma...12 1.1.3. Az alapötlet...13 1.1.4. Megvalósítás: ki, mit, hogyan?...13 1.1.5. Babérok...14 1.1.6. A siker buzdító hatása...14 1.2. A kutatás lépései...15 2. RÉGI ÉS ÚJ PROBLÉMÁK...16 2.1. Alapfogalmak...17 2.1.1. Mező...17 2.1.2. Rekord...17 2.1.3. Tábla...17 2.1.4. Adatbázis...17 2.1.5. Adatállomány...18 2.1.6. Adatbázis-kezelő rendszer...18 2.1.7. Reláció...18 2.2. Az adatbázis-kezelő rendszerek felépítése...19 2.2.1. Adatok és metaadatok...19 2.2.2. Indexek...19 2.2.3. Tárkezelő...20 2.2.4. Lekérdezés-feldolgozó...20 2.2.5. Tranzakció-kezelő...20 3
2.2.6. Lekérdezések...20 2.2.7. Módosítások...21 2.2.8. Sémamódosítások...21 2.3. Osztott adatbázisrendszerek jellemzői...21 2.3.1. Általános leírás...21 2.3.2. Adatbázisok kliens-szerver architektúrája...22 2.3.3. Adatok felosztása...23 2.3.4. Táblafragmentációk...24 2.3.5. Előnyök...26 2.3.6. Hátrányok...26 2.3.7. Általános problémák...27 2.4. Elemzés, problémafeltárás...28 3. MEGOLDÁSI JAVASLAT...30 3.1. Tipikus feladat...31 3.1.1. Leírás...31 3.1.2. Követelmények...32 3.1.3. Elemzés...32 3.1.4. Hagyományos megoldás...33 3.2. Az osztott komponenscsomag bemutatása...35 3.2.1. A DistributedConnection komponens...35 3.2.2. A DistributedDataset komponens...37 3.2.3. A MemoryDataset komponens...39 3.3. A feladat megoldása az osztott komponenscsomaggal...39 4. AZ OSZTOTT KOMPONENSCSOMAG...41 4.1. A komponensek általános szerepköre...42 4.1.1. Adatelérés...42 4.1.2. Adattovábbítás és -szűrés...44 4.1.3. Felhasználás...44 4
4.2. Osztályhierarchia...44 4.2.1. A TDistributedConnection osztály...46 4.2.2. A TDistributedDataset osztály...47 4.2.3. A TMemoryDataset osztály...47 4.3. Előkészítés és végrehajtás...48 4.4. Osztott táblák definiálása...50 4.5. Metaadatok és metaadat-lekérdezések...50 5. AZ OSZTOTT LEKÉRDEZŐNYELV...52 5.1. Általános bemutatás...53 5.1.1. Definíció...53 5.1.2. Példa...54 5.2. Az elemzés fázisai...56 5.3. Lexikális elemzés...58 5.3.1. A lexikális elemző feladata...58 5.3.2. Lexikális egységek...58 5.3.3. A szimbólumsorozat tárolása...58 5.3.4. A lexikális elemzést végző függvény...59 5.3.5. Az automata definíciója...59 5.3.6. Az automata implementációja...61 5.3.7. Kulcsszavak...62 5.3.8. Hibakezelés...62 5.3.9. Példa...62 5.4. Szintaktikus elemzés...63 5.4.1. A szintaktikus elemző feladata...63 5.4.2. Szintaktikus egységek...63 5.4.3. A szintaktikus elemzést végző függvény...64 5.4.4. A szintaktikus elemző grammatikája...64 5.4.5. A szintaktikus elemző implementációja...66 5.4.6. A rekurzív leszállás módszere...66 5
5.4.7. A szintaxisfa...68 5.4.8. Példa...69 5.5. Szemantikus elemzés...70 5.5.1. A szemantikus elemző feladata...70 5.5.2. Relációs algebrai alapfogalmak...71 5.5.3. A végrehajtási fa...72 5.5.4. A szemantikus elemzést végző függvény...75 5.5.5. A végrehajtási fa előkészítése és a valódi szemantikus ellenőrzés...76 5.5.6. Példa...77 5.6. Lekérdezés-optimalizálás...78 5.6.1. A lekérdezés-optimalizáló feladata...78 5.6.2. Algebrai szabályok lekérdezések javítására...78 5.6.3. Példa...79 5.7. Végrehajtás...80 5.7.1. A végrehajtó rész feladata...80 5.7.2. A végrehajtást végző algoritmusok...81 5.7.3. Példa...81 6. ÖSSZEFOGLALÁS, EREDMÉNYEK...82 6.1. Összefoglalás...83 6.2. Hogyan tovább?...85 7. BIBLIOGRÁFIA...86 7.1. Könyvek, cikkek, egyetemi jegyzetek...87 7.2. Internetes források...88 6
Technikai előszó 1170 óra munka, 19 unit, 633 KB begépelt forráskód, 14152 sor, 63 osztály, 499 eljárás és függvény és több mint 22 egyedi megoldás, mindez 3 komponensben. A dolgozat tárgyát az általam kifejlesztett osztott lekérdezőnyelv, röviden DQL (Distributed Query Language) képezi. A nyelv a 3 elemből álló osztott komponenscsomag legfontosabb része. A komponenscsomag Borland Delphi 7 rendszer alatt működik, és feladata az osztott adatbázisrendszerek alkalmazásszintű implementálása, valamint az így összekapcsolt adatbázisokon értelmezett osztott lekérdezések végrehajtása. A csomag legfontosabb eleme a DistributedConnection komponens, amelynek bemenete tetszőleges számú, különböző típusú és elérhetőségű adatbázis, esetleg tetszőleges számú előkészített táblakimenet, kimenete pedig egyetlen, jól felépített virtuális adatbázis. A felhasználónak meg kell adnia a bemeneti adatbázisokat és táblákat, valamint a kimenetet jelentő osztott táblák definícióit. Az osztott táblák lehetnek egyszerű (valódi) táblák vagy vízszintesen/függőlegesen fragmentált táblák. A fragmentumok egyesítését mindkét esetben a komponens végzi el. A virtuális adatbázis felépítésének titka az alias-nevek használatában rejlik, ugyanis ezek a nevek teszik lehetővé több adatbázis tábláinak egy adatbázisban való értelmezését, és ezáltal a forrástáblák szimbolikus elérését. A második komponens, a DistributedDataset feladata a konnekciós komponens tábladefinícióinak adatcsomagok formájában történő továbbítása az adatmodul következő szintjéhez. A komponens bemenete egyetlen DistributedConnection osztály. Ugyanitt nyílik lehetősége a felhasználónak a kimeneti adatszett típusának a meghatározására is. Három típusú kimenet létezik: osztott tábla (a legegyszerűbb kimeneti forma, amely a konnekciós komponens által definiált adatcsomagok direkt reprezentációja), metaadat (ezek különböző belső információk lehetnek, mint például az aktuális konnekció és azok alias-nevei vagy a belső és az osztott tábladefiníciók) és osztott lekérdezés. Az osztott lekérdezések alkalmazásával a legkomplexebb, de egyben legáltalánosabb kimenetet hozhatjuk létre. Ezekben a lekérdezésekben a felhasználónak lehetősége nyílik kiválogatni a kimeneti oszlopokat (akár különböző adatbázisok különböző tábláiból) és sorokat (bizonyos feltételek beírásával) úgy, hogy közben összegzési és sorbarendezési feltételek megadására is lesz lehetősége. 7
Az osztott lekérdezések szintaxisa megegyezik az SQL-parancsok szintaxisával. A DQL és az SQL közötti különbség a végrehajtás módjában nyilvánul meg, hiszen az osztott lekérdezések nem csupán egyetlen adatbázisra vonatkoznak, hanem adatbázisok összességére, ezért ezeknek a végrehajtása nem tartozik egyetlen adatbázis-kezelő hatáskörébe sem. Továbbá az osztott lekérdezésekben fragmentált táblákra is hivatkozhatunk, ami szintén nem megengedett hagyományos SQL-lekérdezésekben. A komponenscsomag utolsó eleme a MemoryDataset, amelynek szerepe a konnekciós komponens és az adatszettek közötti információátadásban van, ahol egyrészt tartalmazza a visszatérített adatszett struktúráját, másrészt pedig magát az adatokat is. A komponens kitűnően használható tetszőleges, nem adatbázis-alapú adatok memóriában történő tárolására, ami nagy segítséget jelent az osztott adatbázisok adatainak a feldolgozásában. A komponenscsomag a bennfoglalt osztott lekérdezőnyelvvel együtt tehát egyedülálló módszert (technológiát) biztosít osztott adatbázisok definícióinak megadására és az osztott adatok kinyerésére, az alias-nevek alkalmazásával pedig kikerüli az adatbázisok elérésének címmel történő megadását. A csomag önmagában helyettesítheti bármilyen osztott adatbázisokat támogató alkalmazás adathozzáférési rétegét, azaz teljesen általánosan valósítja meg a táblák elérését mind helyi, mind pedig távoli szerverek esetén. A komponenscsomag használatának részletes leírása megtalálható a 3. fejezetben, a 4. fejezetben a komponensek technikai megvalósítását mutatom be, az 5. fejezetben az osztott lekérdezések elemzését és végrehajtását ismertetem, a 6. fejezetben pedig összegzem a leírtakat. 8
Előszó Az osztott lekérdezőnyelv. Úgy hiszem kevesen vannak, ha egyáltalán vannak, akik hallottak már erről a nyelvről. 1+1=1. A matematikusok minden bizonnyal nagyot néznének egy ilyen összeadás láttán. E szakdolgozatban új dolgokról lesz szó, új megközelítésben és a legfrissebb megoldási javaslatokkal fűszerezve. A dolgozatot azt hiszem nevezhetjük kutatómunkának is. Kutatómunka, hiszen szembesültem egy problémával (1. fejezet), amire megpróbáltam megoldást keresni, elsősorban a már létező ajánlatok közül (2. fejezet), és mivel egyetlen egy ilyen megoldást sem találtam, szükségesnek láttam egy olyan rendszer kidolgozását, amely igyekszik pótolni e hiányosságot (3. fejezet). Éppen ezért olyan komponenscsomagot fejlesztettem ki (4. fejezet), amely a címadó osztott lekérdezőnyelv által (5. fejezet) remélhetőleg egyszerű és hatékony gyakorlati segédeszközként fog szolgálni a jövő programozói számára. E munka során tehát feltártam, megvizsgáltam, megoldottam és nem utolsó sorban összegeztem, a szakirodalomnak pedig remélhetőleg egy új szikrát adtam (6. fejezet). Azt hiszem érdemes lesz egy kis időt rászánni e dolgozatra. Mindezek mellett remélem, hogy e munka nem csak egyike lesz azon államvizsga dolgozatoknak, amelyek a védést követően polcra kerülnek és idővel feledésbe merülnek. Sajnos számos ötlet és rengeteg munka végzi hasonlóképpen. Úgy érzem, hogy az egyetem legfőbb célja a tanítás mellett az, hogy a diákokat ösztönözze és segítse a haladásban, az új ötletek megtalálásában és kidolgozásában, és ha már ebben segített nekik, akkor az eredményeket kellőképpen értékelje és felhasználja. Köszönet illeti tehát azon tanárokat, diákokat és szakembereket, akik a tanulókat munkára és kutatásra ösztönzik, és segítenek nekik ebben. Külön ajándéknak tekinthetjük a különböző versenyeket, különös tekintettel az ETDK-t és egyes konferenciákat, amelyeknek éppen az a céljuk, hogy ösztönözzenek és értékeljenek. Az államvizsga dolgozat a következő nagy lehetőség, amelyen mindenki bizonyíthat. Az egyéni és csoportos projekt tantárgyaknak szintén gyakorlati ösztönző szerepük van. De azt hiszem, hogy mindez nem elég: az egyetemnek még több kutatómunkára, kutatócsoportra, lelkes diákra és tanárra lenne szüksége. A hallgatókban van igény munkára, a gyakorlatra, csak egy kicsit ösztönözni kell őket, hogy teljesítőképességük legjavát mutathassák meg. 9
Itt szeretném megköszönni a segítséget minden tanáromnak, akik legjobb tudásuk szerint igyekeztek minket minél jobban kiképezni az előttünk álló küldetésekre. Nekik továbbra is jó munkát kívánok! Külön köszönet illeti dr. Varga Ibolya tanárnőmet, aki folyamatos ösztönzésével és biztatásával olyan helyzetbe kényszerített engem, hogy tanuljak, dolgozzam és gondolkodjam. Neki köszönhetem, hogy az adatbázis-kezelés egy új területével (az osztott adatbázisrendszerekkel) megismerkedhettem, és rálátást kaptam a terület hiányosságaira, ami ösztönzően hatott rám. Külön hálás vagyok az általa biztosított szakirodalomért és szakmai tanácsokért. Másodsorban köszönettel tartozom vezetőtanáromnak, dr. Csörnyei Zoltánnak, aki a fordítóprogramok tantárgy révén egy külön világ felé nyitotta ki a szememet. Sikerült átadnia azt a lelkesedést és hozzáállást, amellyel ő maga is rendelkezik a fordítás iránt, és amely a programozóknak abból az erős vágyából fakad, hogy egy rendszertelen leírásban logikát találjanak, általánosítsák és leegyszerűsítsék azt, vagyis az emberek bonyolult nyelvét a számítógép bonyolult nyelvére alakítsák. Ezt az egyik legszebb és legérdekesebb dolognak találom, amelyet programozó végezhet. Végül pedig hálás köszönetet mondok Lukács Sándor kollégámnak, akivel az elején közösen vágtunk bele e feladat megoldásába, de aki mindvégig hasznos gyakorlati segítséggel és tanácsokkal látott el. Tőle tanultam a lelkesedést és a kitartást, ő volt aki a nehéz pillanatokban is kiállt mellettem és biztatott. Részben neki köszönhetem, hogy e komponenscsomag és e dolgozat elkészült. A szakemberek azt tartják, hogy egy kézikönyvnek csak a harmadik kiadása használható igazán. Mivel nem áll módomban e dolgozatnak rögtön a harmadik, javított változatával előállni de idővel szeretnék, kérem Önöket, hogy megjegyzéseiket, javaslataikat, kritikai észrevételeiket osszák meg velem, hogy egy következő változatban már ezeket is figyelembe vehessem. Kolozsvár, 2004. június 13. Buzogány László 10
1. FEJEZET HONNAN SZÁRMAZIK AZ ÖTLET?
HONNAN SZÁRMAZIK AZ ÖTLET? 1.1. Az osztott komponenscsomag története Ezt az ötletet amelyet e dolgozatban igyekszem részletesen ismertetni elsősorban a kényszer szülte. Ez így működik valahányszor egy hallgató valamilyen feladatot kap és azt nem akarja, nem tudja, vagy csak nagyon nehezen tudja elvégezni. Ilyen esetekben az illető diák gondolkozni kezd, hogyan lehetne másképpen megközelíteni a problémát, hogyan lehetne kicselezni vagy esetleg kikerülni a feladatot? Megoldást keres, természetesen a maga módján, és az esetek többségében talál is. 1.1.1. A végzetes feladat Egyetemünkön az informatika csoportok általában tanulják az adatbázis-kezelés alapjait, majd ennek folytatásaként az osztott adatbázisrendszerek nevezetű tantárgyat. E tárgyak keretében a hallgatók megismerkednek az adatbázis-kezelés alapfogalmaival, megtanulják a legismertebb adatbázis-kezelő rendszerek használatát, és olyan projekteken dolgoznak, amelyek hozzásegítik a terület szakmai-gyakorlati részének a megismeréséhez és elsajátításához. Az osztott adatbázis-kezelő rendszerek tanulmányozása céljából olyan alkalmazást kellett írnunk, amely az adatokat különböző típusú adatbázisokból gyűjti össze, ezeket mégis valamilyen célból egy egységként kezeli, összefüggőnek látja. Ennek egyszerűbb változata amikor az egyes adatbázisok ugyanazon rendszerben találhatók mindennapi feladatnak számít a gyakorlatban. Az adatok különböző típusú és elérésű adatbázisokból való lekérdezése és napratétele, illetve az egyes feladatok összehangolása (szinkronizálása) viszont már jóval nehezebb feladat. 1.1.2. Dilemma Az ilyen feladatokat általában bonyolult programozási technikákkal oldják meg, és a legtöbb esetben nem nyújtanak kellő biztonságot, nem garantálják az adatok mindenkori elérését, sőt a műveletek szinkronizálását sem. Továbbá ezen alkalmazások többsége erősen testre szabott, egyedi környezetet igényel és csak a konkrét feladatra optimalizált. Ennek folyományaként a későbbi javítások nagyon nehezen végezhetők el, egyes esetekben pedig teljességgel lehetetlenek. Nem volt ez másként a mi feladatunk esetén sem. 12
HONNAN SZÁRMAZIK AZ ÖTLET? Lukács Sándor társammal együtt tehát döntenünk kellett: a hagyományos utat választjuk és egy egyszerű, egyszeri használatú alkalmazást írunk, amely a feladat követelményeinek minimálisan megfelel ugyan, de egyébre nem használható, vagy valami sokkal jobbat találunk ki. Előbb az első lehetőséggel kísérleteztünk, de sajnos nem az általunk elvárt eredményt hozta, ezért végül elhatároztuk: belevágunk és sokkal nagyobb erőfeszítéssel, de valami maradandót és használhatót alkotunk, ami reményeink szerint a jövőben sok más, hasonló helyzetben levő programozón segít majd. Végül egy olyan módszert sikerült kidolgoznunk, amely az eredeti bonyolult (heteket igénylő) feladatot egy délutános kattintgatással oldja meg. 1.1.3. Az alapötlet Adott tehát több különböző típusú és elérhetőségű adatbázis. A feladat egy olyan rendszer kidolgozása, amely az adatbázisok tábláin műveleteket képes végezni, és lehetővé teszi olyan lekérdezések megfogalmazását, amelyek ugyanúgy működnek helyi, központi, és összesített adatok esetén is. A megoldás leegyszerűsítése céljából olyan komponenscsomagot dolgoztunk ki, amely egyidőben tetszőleges számú és típusú adatbázishoz, illetve táblához képes kapcsolódni. Az így összegyűjtött adatokat a felhasználó ezután becenévvel (alias-névvel) látja el, és ezáltal egyetlen, nagy, virtuális adatbázishoz jut. A komponenscsomag egy másik eleme lehetővé teszi az ily módon létrehozott adatbázisokból való lekérdezések végrehajtását. 1.1.4. Megvalósítás: ki, mit, hogyan? Az ötlet egyedisége miatt ki kellett dolgoznunk a tervet az első lépéstől az utolsóig. Ez nem volt könnyű feladat, hiszen minden új ötlet felvetése újabb kérdéseket, akadályokat és ellenérveket hozott magával. Az elején a társammal közösen dolgoztunk, próbáltuk a legjobb megoldást megtalálni. A feladatot különösen bonyolították a különböző típusú adatbázisok, a szinkronizációs problémák, a komponensek közti viszonyok, a lekérdezőnyelv alapfilozófiája, az adatok begyűjtésének és módosításának kérdései. Ekkor értettük meg, hogy korábban miért nem foglalkoztak mások is e témával. Végül körvonalazódni kezdett a feladat, az ábrák lassan algoritmusokká alakultak, és az elmélet gyakorlati formát öltött. Elkészítettük az első változatokat, és prototípusok segítségével tesztelni kezdtük az ötleteinket. Úgy tűnt a rendszer működőképes lesz. 13
HONNAN SZÁRMAZIK AZ ÖTLET? A problémát két jól elkülöníthető részre osztottuk: A társam a két alapvető DistributedConnection és DistributedDataset nevű komponens megírására vállalkozott. Az első a különböző adatbázisrendszerekhez való kapcsolódást végzi, míg a második az így felépített virtuális adatbázisból képez valamilyen adatcsomagot. Egy ilyen adatcsomag lehet a virtuális adatbázis egy táblája, valamilyen metaadat vagy osztott lekérdezés. A komponensek felépítését a 4. fejezetben mutatom be. Az én feladatom az osztott lekérdezőnyelv kidolgozása és megvalósítása volt. Ez az ún. lekérdező-végrehajtó motor logikailag a DistributedConnection komponensben helyezkedik el. E nyelv feladata az osztott adatbázisokon értelmezett lekérdezések elemzése és végrehajtása, vagyis az adatok különböző adatbázisokból való begyűjtése és összesítése. Ez a komponenscsomag azon része, amely az előzőleg begyűjtött információk alapján elvégzi az osztott adatbázis-műveleteket (5. fejezet). 1.1.5. Babérok A komponenscsomag első, bemutató jellegű változatával jelentkeztünk a 2003-as Erdélyi Tudományos Diákköri Konferenciára (ETDK), ahol az ötletünket első díjjal jutalmazták. 1.1.6. A siker buzdító hatása Az ETDK-n való szereplés azonban csak a kezdet volt. Úgy gondolom, hogy a projekt teljes kidolgozása akár két évet is igénybe venne, és eközben rengeteg más, újabb megoldandó problémát vetne fel. Tehát e téma körbejárása akár egy élet kutatómunkája is lehetne. A kezdeti sikerektől és eredményektől felbuzdulva úgy döntöttem, hogy folytatom a megkezdett munkát. Éppen ezért a komponenscsomagot tovább fejlesztettem, létrehozva egy működőképes, a végcélhoz sokkal közelebb álló programot. Ezen túlmenően igyekeztem a dolgozatot elméleti szempontból is megalapozni: utánanéztem a már létező, hasonló jellegű munkáknak és rendszereknek, illetve a saját rendszeremen belül törvényszerűségeket, szabályokat próbáltam felállítani. Új fogalmakat vezettem be a szakirodalomba, és tisztáztam az egyes komponensek szerepkörét, a lekérdező és végrehajtó mechanizmusok működését, valamint általánosítottam a felhasznált algoritmusokat. A kutatás eredményeit összefoglaltam, ezáltal munkámat a tudományág egy bizonyos területébe illesztettem. 14
HONNAN SZÁRMAZIK AZ ÖTLET? 1.2. A kutatás lépései A komponenscsomag és a dolgozat jelen formájához több lépésen keresztül jutottam. Ezek a kutatási lépések a következők voltak: 1. A probléma feltárása. Miután az osztott rendszereken alapuló alkalmazás megírásánál problémák merültek fel, igyekeztem meghatározni azokat a tényezőket, és igényeket, amelyek egy ilyen rendszer megvalósításánál jelentkeznek. Ezek alapján egy követelményrendszert állítottam fel, amelyekhez a következőkben igazodni próbáltam. 2. Az ötletek begyűjtése. A felmerülő problémákra megoldási javaslatokat tettem, amelyeket egy előzetes összehasonlítás után rangsoroltam. A legjobb ötleteket kiválasztottam és elkészítettem a komponenscsomag vázlatát. 3. A prototípus elkészítése. A vázlatok alapján az ötleteket néhány általam összeállított példára alkalmaztam, és megállapítottam, hogy milyen elvárt eredményhez kellene jutnom. 4. A komponenscsomag elkészítése. A felvázolt elméleti adatstruktúrákat és algoritmusokat implementáltam, és elkészítettem a komponenscsomag első változatát. 5. A példaprogram megírása. Olyan példaalkalmazást készítettem, amely átfogóan bemutatja és egyben ellenőrzi a program működését. 6. Tesztelés. A komponenscsomagot különböző helyzetekben és adatbázisokra kipróbáltam. A felmerülő hibákat folyamatosan javítottam, mígnem egy általam elfogadhatónak tartott, stabil alkalmazáshoz jutottam. 7. Összegzés és általánosítás. Az ötleteket és eredményeket még egyszer átgondoltam, a szerkezetet letisztítottam, a forráskódot megjegyzésekkel láttam el, valamint megpróbáltam az eredményeket megfelelőképpen értelmezni. 8. A dolgozat megírása. A komponens szerkezetéhez, illetve a kutatás lépéseihez igazodva elkészítettem a dolgozat vázlatát, megrajzoltam a külalaktervet, majd megfogalmaztam és leírtam a gondolataimat. Végül a dolgozatot korrektor jelenlétében még egyszer figyelmesen átnéztem és kijavítottam. 15
2. FEJEZET RÉGI ÉS ÚJ PROBLÉMÁK
RÉGI ÉS ÚJ PROBLÉMÁK 2.1. Alapfogalmak Mielőtt mélyebb adatbázis-kezelési problémák tárgyalásába kezdenék, szükségszerű tisztázni néhány nagyon fontos fogalmat, amelyekre a későbbiekben gyakran fogok hivatkozni. 2.1.1. Mező Mezőnek (field) nevezünk egy egységnyi, különálló jellemzőt. Egy mezőbe írhatjuk például valakinek a nevét, a telefonszámát vagy az e-mail címét. [5, 438. p.] 2.1.2. Rekord Az egy egységet leíró, logikailag összetartozó mezőket együttesen rekordnak (record) vagy bejegyzésnek nevezzük. Például egy személyhez tartozó adatok (név, cím, telefonszám) egy rekordot alkotnak. [5, 438. p.] 2.1.3. Tábla Több, azonos szerkezetű bejegyzés táblát (table) alkot. Egy táblában tárolhatjuk például egy csoport minden tanulójának a nevét, jegyeit és kedvenc tantárgyait. A táblák, amint a nevük is jelzi táblázatos formában tárolják az információt, azaz a sorok jelentik a rekordokat, míg az oszlopok egy-egy mezőt azonosítanak. [5, 438. p.] 2.1.4. Adatbázis A logikailag összetartozó adathalmazokat tehát táblákba szervezzük. Előfordulhatnak azonban olyan bonyolultabb feladatok is, amelyek adatai nem rögzíthetők egyetlen táblába. (Képzeljünk el egy autókölcsönzőt, ahol minden adatot számítógépen tárolnak. Egy tábla a raktáron levő autók típusát és darabszámát tárolja, egy másik az autók jellemzőit, egy harmadik a kliensek nyilvántartásáért felelős, de a cég alkalmazottjainak is külön táblázatot kell létrehozni.) Ekkor célszerű ezen összefüggő adattáblákat valamilyen nagyobb egységbe tömöríteni. Egy ilyen összefüggő adatszerkezetet nevezünk adatbázisnak (database). [5, 438. p.] Egy másik meghatározás szerint az adatbázis nem más, mint hosszú ideig gyakran évekig meglévő információk gyűjteménye. [1, 19. p.] 17
RÉGI ÉS ÚJ PROBLÉMÁK 2.1.5. Adatállomány Többféle adatbázis létezik, amelyek különféle módszereket alkalmaznak az adatok tárolására. A legtöbb típusnál az adatbázisok külön fájlokban vannak elhelyezve, ezeket adatállományoknak (data file) nevezzük. [5, 438. p.] 2.1.6. Adatbázis-kezelő rendszer Az adatbázis-kezelő rendszer (DBMS Database Management System) az adatbázisok adatainak a kezelését végzi. Szokás ezeket a rendszereket egyszerűen csak adatbázisrendszereknek nevezni. Egy adatbázisrendszerrel szemben a következő elvárásaink vannak: Tegye lehetővé a felhasználók számára új adatbázisok létrehozását, és az adatok sémáját, vagyis az adatok logikai struktúráját egy speciális nyelven adhassák meg. Ezt a speciális nyelvet adatdefiníciós nyelvnek nevezzük. Engedje meg a felhasználóknak, hogy az adatokat egy megfelelő nyelv segítségével lekérdezhessék és módosíthassák. Ez a nyelv a lekérdezőnyelv vagy adatmanipulációs nyelv. Támogassa nagyon nagy mennyiségű adat (gigabájtok vagy még több adat) hosszú időn keresztül való tárolását, garantálja az adatok biztonságát a meghibásodásokkal és az illetéktelen felhasználókkal szemben, és tegye lehetővé a hatékony adathozzáférést a lekérdezések és az adatbázis-módosítások számára. Felügyelje a több felhasználó által egy időben történő adathozzáféréseket úgy, hogy az egyes felhasználók műveletei ne legyenek hatással a többi felhasználóra és az egyidejű adathozzáférések ne vezethessenek az adatok hibássá vagy következetlenné válásához. [1, 19 20. p.] 2.1.7. Reláció Ted Codd 1970-ben publikált egy híres cikket, amelynek megjelenése után az adatbázisrendszerek jelentősen megváltoztak. Codd azt javasolta, hogy az adatbázisrendszereknek a felhasználó felé az adatokat táblázatok formájában kellene megjeleníteniük, ezeket a táblákat nevezzük relációknak. A háttérben persze egy bonyolultabb adatstruktúra is lehet, amelyik lehetővé teszi, hogy a rendszer gyorsan adjon választ a legkülönbözőbb kérdésekre, de ellentétben a korábbi rendszerekkel egy relációs rendszer felhasználójának nem kell törődnie az adatok tárolási struktúrájával. A lekérdezések egy olyan magas színtű nyelv segítségével fejezhetők ki, amelyek használata jelentős mértékben növeli az adatbázis-programozók hatékonyságát. [1, 22. p.] 18
RÉGI ÉS ÚJ PROBLÉMÁK 2.2. Az adatbázis-kezelő rendszerek felépítése Az adatbázis-kezelő rendszerek legfontosabb részeit a 2.1. ábrán láthatjuk. [1, 26 28. p.] 2.2.1. Adatok és metaadatok Az 2.1. ábra alján az adatok tárolására szolgáló helyet lemez alakú ábrával jelöltem. Megjegyzem, hogy az ábrán azt is jelöltem, hogy ez a rész nem csak adatokat, hanem ún. metaadatokat is tartalmaz, ami az adatok szerkezetét írja le. Például ha az adatbázis-kezelő relációs, akkor a metaadatok között szerepelnek a relációk nevei, a relációk attribútumainak nevei és az attribútumok adattípusai (mind például egész vagy 20 hosszúságú karakterlánc). Sémamódosítások Lekérdezések Módosítások Lekérdezés-feldolgozó Tárkezelő Tranzakció-kezelő Adatok Metaadatok 2.1. ábra. Az adatbázis-kezelő rendszerek főbb részei és a köztük levő kapcsolatok 2.2.2. Indexek Az adatbázis-kezelő rendszerek gyakran indexeket használnak az adatok elérésére. Az index olyan adatstruktúra, amely lehetővé teszi, hogy az adatelemeket gyorsan megtaláljuk, ha ismerjük a hozzájuk tartozó értékek bizonyos részeit. A leggyakrabban előforduló példa egy olyan index, amelynek a segítségével egy reláció azon sorait kereshetjük meg, amelyekben az egyik attribútum értéke adott. Az indexek a tárolt adatok közé tartoznak, az az információ azonban, hogy mely attribútumokra léteznek indexek, a metaadatok részét képezi. 19
RÉGI ÉS ÚJ PROBLÉMÁK 2.2.3. Tárkezelő Az 2.1. ábrán láthatjuk még a tárkezelőt, amelynek feladata a kért információ beolvasása a kérést fogalmaznak meg. 2.2.4. Lekérdezés-feldolgozó Láthatunk még egy olyan komponenst, amelyet lekérdezés-feldolgozónak neveztünk, habár ez az elnevezés nem teljesen helyes. Ez a rész ugyanis nem csak a lekérdezéseket kezeli, hanem az adatok és a metaadatok módosítására vonatkozó kéréseket is ez adja ki. Ennek a komponensnek kell megtalálnia egy művelet legjobb végrehajtási módját, és ez adja ki a tárkezelőnek szóló utasításokat is. 2.2.5. Tranzakció-kezelő A tranzakció-kezelő rész felelős a rendszer sértetlenségéért. Neki kell biztosítania, hogy az egyidőben futó lekérdezések és módosítások ne ütközzenek össze egymással, és hogy a rendszer még rendszerhiba esetén se veszíthessen adatokat. Kapcsolatot tart a lekérdezés-feldolgozóval, hiszen a konfliktusok elkerüléséhez tudnia kell, hogy az aktuális lekérdezések éppen mely adatokon dolgoznak, és épp e konfliktusok megakadályozásáért késleltethet bizonyos lekérdezéseket vagy műveleteket. Kapcsolatot tart a tárkezelővel is, mert az adatok védelmére szolgáló módszerek többnyire magukba foglalják a módosítások naplózását is. Ha a műveleteket a megfelelő sorrendben végzi el a rendszer, akkor a naplóban benne lesznek a változtatások, és így egy rendszerhiba után még azok a módosítások is újra végrehajthatók lesznek, amelyeknek a lemezre írása eredetileg nem volt sikeres. 2.2.6. Lekérdezések Az 2.1. ábra felső részén az adatbázis-kezelő rendszer három különböző fajta inputját láthatjuk. Az első a lekérdezések, amelyek az adatokra vonatkozó kérdések. Ezek két különböző módon jöhetnek létre. Egy általános lekérdező-interfészen keresztül. Például a rendszer megengedi a felhasználónak, hogy SQL lekérdezéseket gépeljen be, amelyeket aztán a lekérdezés-feldolgozó fog megkapni és végrehajtani. 20
RÉGI ÉS ÚJ PROBLÉMÁK Egy alkalmazói program interfészén keresztül. Az adatbázis-kezelő rendszerek általában megengedik a programozónak, hogy olyan programot írjon, amely az adatbázis-kezelőnek szóló hívásokon keresztül kérdezi le az adatbázist. Például egy repülőgép-helyfoglalási rendszert használó ügynök egy olyan programot futtat, amelyik a különböző járatok adatait kérdezi le az adatbázisból. A lekérdezések egy speciális interfészen keresztül adhatók meg, ahol tulajdonképpen mezőket kell kitölteni városok neveivel, időpontokkal vagy egyéb adatokkal. Ezen az interfészen keresztül nem tehetünk fel tetszőleges kérdéseket, de amit kérdezhetünk azt általában egyszerűbben kérdezhetjük le ezen az interfészen keresztül, mintha nekünk kellene megírnunk a lekérdezést SQL-ben. 2.2.7. Módosítások Ezek a műveletek az adatok változtatására szolgálnak. Ugyanúgy, ahogyan a lekérdezéseket, ezeket is kiadhatjuk egy általános interfészen, vagy egy alkalmazás interfészén keresztül. 2.2.8. Sémamódosítások Ezeket az utasításokat általában csak az illetékes személyek (adatbázis-adminisztrátorok) adhatják ki, akik megváltoztathatják az adatbázis sémáját, vagy akár új adatbázist hozhatnak létre. Például, amikor a bankokat arra kötelezték, hogy a kamatfizetéseket az ügyfelek személyi számával együtt jelentsék az adóhatóság felé, akkor minden bizonnyal egy új attribútummal a személyi számmal kellet bővíteniük azt a relációt, amelyik az ügyfelek adatait tárolta. 2.3. Osztott adatbázisrendszerek jellemzői 2.3.1. Általános leírás Az osztott adatbázisrendszerek tulajdonképpen az informatika két különböző, látszólag egymástól független ágának az egyesítéséből alakultak ki. E két terület az adatbázisrendszerek és a számítógép-hálózatok rendszere. A hagyományos adatbáziskezelő-rendszerek alapvető feladata az adatok tárolása és rendszerezése. Ezek az adatok egyetlen központi gépen helyezkednek el, ahonnan a különböző alkalmazások elérhetik, és felhasználhatják őket saját céljaikra (2.2. ábra). Ez a megoldás erős adatfüggőséget okoz, mivel a rendszer esetleges összeomlásával az alkalmazás képtelen lesz tovább működni. 21