Irta: Radó Péter. MAGYAR TUDOMÁNYOS AKADÉMIA SZÁMÍTÁSTECHNIKAI és a u t o m a t iz á l á s i kutató in t é z e t e

MAGYAR TUDOMÁNYOS AKADÉMIA SZÁMÍTÁSTECHNIKAI

és

a u t o m a t iz á l á s i

kutató

RELÁCIÓS ADATBÁZI SKEZELÓ RENDSZEREK ÖSSZEHASONLI TÓ VIZSGÁLATA

Irta: Radó Péter

Tanulmányok 156/1984

in t é z e t e

A kiadásért felelős DR.

yAMOS TIBOR

Főosztályvezető: DEMETROVICS

JÁNOS

ISBN 963 31.1 173 0 ISSN 0324-2951

Coopinvest 8 4 —150

A TANULKÁNYSOROZATBAN

1 9 8 3 - B A N MEGJELENTEK

140/1983

Operation Research Software Descriptions (Vol.l.) Szerkesztette: Prékopa András és Kéri Gerzson

141/1983

Ngo The Khanh: Prefix-mentes nyelvek és egyszerű determinisztikus gépek

142/1983

Pikier Gyula: Dialógussal vezérelt interaktiv gépészeti CAD rendszerek elméleti és gyakorlati megfogalmazása

143/1983

Márkusz Zsuzsanna: Modellelméleti és univerzális algebrai eszközök a természetes és formális nyelvek szemantikaelméletében )

144/1983

Publikációk '81

145/1983

Teles András: Belső állapotú bolyongások

146/1983:

Varga Gyula: Numerical Methods for Computation of the Generalized Inverse of Rectangular Matrices

147/1983

Proceedings of the joint Bulgarian-Hungarian workshop on "Mathematical Cybernetics and data Processing" /Szerkesztette: Uhrin Béla/

148/1983

Sebestyén Béla: Fejezetek a részecskefizikai elektronikus kisérleteinek adatgyűjtő, -feldolgozó

/Szerkesztette: Petróczy Judit/

rendszerei köréből 149/1983

L. Reviczky, J. Hethéssy: A general approach for deterministic adaptive regulators based on explicit identification

150/1983

IFIP TC.2 WORKING CONFERENCE "System Description Methodologies" May 22-27. 1983. Kecskemét. /Szerkesztette: Knuth Előd/

151/1983

Márkusz Zsuzsanna: On First Order Many-Sorted LOGIC

152/1983

Operations Research Software Descriptions /Vol.2./ Edited by A. Prékopa and G. Kéri

153/1983

T.M.R. Ellis: The automatic generation of user-adaptable application-oriented language processors based on quasi-parallel modules

154/1983

Publikációk'82 /Szerkesztette: Petróczy Judit/

1 9 8 4 - b e n EDDIG MEGJELENTEK

155/1984

Deák István, Hoffer János, Mayer János, Németh Ágoston, Potecz Béla, Prékopa András, Straziczky Beáta: Termikus erőmüveken alapuló villamosenergia-rendszerek rövidtávú, optimális, erőmüvi menet­ rendjének meghatározása hálózati feltételek figye­ lembevételével

Néhány technikai megjegyzés

1. A tanulmány szövegében egyes szavak, kifejezések alá vannak huzva folyamatos

vonallal. Szándékunk szerint

ezek azok a fogalmak, megnevezések, néha rész vagy egész mondatok, melyek szövegkörnyezetükből kiemelve is jellemzik az aktuális témát, és igy a rész, feje­ zet és paragrafus-cimekkel támpontul szolgálhatnak a tanulmányt gyorsan átfutni kivánó, csak az ot érdeklő részekben elmélyedő Olvasó számára. Az aláhúzott szö­ vegrészekkel jellemzett egységek részegységeire vo­ natkoznak a szagba tot ^vonallal^ aláhúzott fogalmak, megnevezések. 2. Figyelembe véve, hogy az adatbáziskezelo rendszerek ké­ szítése nem csak tudományos kutatás tárgya, hanem vi­ rágzó iparág is, a rendszerek működésének, felépítésé­ nek leirása a szakirodalomban sok esetben nem található meg egészen pontosan, néha félmondatokból, célzásokból kell kihámozni az /esetleg téves, ellentmondásos vagy kétértelmű/ információt. Szükségesnek véltük ezért, a nem köztudott és sokszor megerősített tények közlésé­ nél és felhasználásánál a forrás pontos megnevezését. Annyiban tértünk el az általános gyakorlattól, hogy né­ hány esetben mondatokon kivül is szerepelnek hivatkozá­ sok. Ilyenkor a hivatkozás az egépz megelőző logikai egység /a tartalom alapján remélhetően jól elkülönülő egy vagy több bekezdés, esetleg egész paragrafus/ tar­ talmára vonatkozik.

5

tartalomjegyzék

0. Bevezetés..........................................

7

0.1. A relációs adatmodell ....................... 0.1.1. A reláció ............................

10 10

0.1.2. A relációkkal végezhető műveletek .... 0.2. Történeti áttekintés ........................

13 17

1. A felhasználói interface ....................

22

1.1. Adatdefiniciós lehetőségek .................. 1.1.1. SQL/DS ............................... 1.1.2. INGRES ...............................

23 24 29

1.1.3. QBE ................ 1.1.4. Általános áttekintés. Mikrogépes rend­ szerek ...............................

31

1.2. Lekérdezés, módosítás ....................... 1.2.1. Relációkalkulus - ALPHA .............

39 40

34

1.2.2. Relációalgebra ............... ........ 4 7 1.2.3. 1.2.4. 1.2.5. 1.2.6.

SQL/DS ................................ INGRES ................................ QBE ................................... Egyéb rendszerek .............

51 57 63 70

1.3. Adatkezelés programozási nyelvekből .......... 1.3.1. Gazdanyelvek és adatnyelvek .......... 1.3.2. Adatkezelo-programozásinyelvek .......

74 75 82

2. Implementáció ..................................... 88 2.1. A rendszer architektúrája ................... 89 2.1.1. SQL/DS .............. 90 2.1.2. INGRES ................................ 94 2.1.3. LIDAS ................................. 97 2.1.4. Néhány mikrogépesrendszer ............ 98 2.2. Optimizálási algoritmusok. Optimizáló implementációk .............................. 104

6

2.2.1. A Palermo algoritmus. LIDAS implementáció ...................... 2.2.2. A Sniith-Chang algoritmus. PRTV implementáció ....................... 2.2.3. Astrahan és Chamberlin TID algorit­ musa ................ 2.2.4. Az INGRES-ben használt dekompoziciós algoritmus ......................... 2.2.5. Az SQL/DS optimizációs módszerei. A "forditóprogram"implementáció ......

105 113 120 132 143

2.2.6. Összefoglaló megjegyzések .....

157

2.3. A tárolási részrendszer ............... 2.3.1. SQL/DS ............................. 2.3.2. INGRES ............................. 2.3.3. Mikrogépes rendszerek ..............

151 162 171 174

Irodalom .....................................

177

7

O. BEVEZETÉS A relációs adatmodell sikerének okát a szakemberek általában két tényezőben látják: 1/ az adatszerkezet egyszerűsége; 2/ a modell matematikai megalapozottsága [LACR 8Í) . Ami a 2/ okot illeti, tény, hogy ez az alapozás az adat­ modell 1970-es bevezetése óta napjainkig nagy intenzitás­ sal folyik. Az is tény azonban, hogy ez a munka még ma sem látszik befejezettnek, és ez az 1/ tényező igazságát is megkérdőjelezi. Valóban olyan egyszerű a relációs adatmodell? Az adatkezelés "relációs "korszakának" kezdetét 1970től E.F. Codd alapvető cikkének [CODD 703 megjelenésétől szokás számítani. Ebben a cikkben a szerző definiálja az elképzelés alapjául szolgáló "reláció" fogalmát, és né­ hány, az adatszerkezeten végezhető műveletet. A reláció fogalma mellé rögtön be is vezeti a "normálforma" fogal­ mát . Erről a normálformáról röviddel később ő maga mutat­ ja meg, hogy ez csak az első normálforma ugyanis {CODD 71b} ben bevezeti a második és a harmadik normálformát. Jelen­ leg óvatos becslések szerint is öt normálformáról beszél­ hetünk [KENT 83} . A különféle normálformáknak, a normálformájú relációkat előállitó algoritmusoknak nemzetközi és hazai viszonylatban is igen komoly, matematikai felkészültséget igénylő irodalmuk van £ d EME 8l] . Az elmélet tehát semmiképpen nem nevezhető egysze­ rűnek az első, felületes vizsgálatok után. A gyakorlat pedig - mint általában - még kuszább, összetettebb képet mutat. Milyen adatbáziskezelő rendszer nevezhető egyál­ talán relációsnak? 1970-ben erre még egyszerű volt a válasz: amik re­ lációkon, tehát fizikai adatszervezés - független táb­ lázatokon manipulálnak (CODD 7qJ . 1971-ben Codd javas­ latot tett egy manipulációs nyelvre is

[CODD 7lá) , majd

8

az akkori és későbbi nyelvek "erősségére" - vagyis kifeje­ zőképességükre, a nyelven leirható és az adatbáziskezelő rendszer által megvalósítandó műveletek minimális bonyolult­ ságának jellemzésére - mércét állitott fel (CODD 71c"} . Ekkor még - természetesen - nem léteztek magukat "relációsnak" ne­ vező adatbáziskezelő rendszerek. Az 1979-es válasz - a nagyszámú relációs adatbáziske­ zelő rendszer létrejötte után - már összetettebb és óvato­ sabb fcODD 1S\ . Az adatbáziskezelő rendszer tökéletesen re­ lációs, ha támogatja 1/ a relációs adatmodell szerkezeti elemeit 2/ bizonyos beillesztési, felújítási, törlési szabályokat 3/ a relációs algebrát, ill. egy legalább azzal ekviva­ lens erősségű adatkezelő nyelvet A csupán az 1/ , 2/ feltéteket teljesitó rendszer félig re­ lációs. 1981-ben a meghatározás még árnyaltabbá vált CcODD 82^ . Megjelentek ugyanis olyan rendszerek, melyek "relációsnak" nevezték magukat ugyan, de teljesitményük - főként az adat­ kezelő nyelv biztosította lehetőségek terén - elég sok kí­ vánnivalót hagyott maga után. Az 1979-ben "félig relációs"-nak hivott rendszereket Codd 1981-ben már csak "táblás"-nak /tabular/ nevezi. Mini­ málisan relációs rendszerek azok, melyek lekérdező nyelve képes a három alapvető relációs művelet /SELECT, PROJECT, JOIN/ realizálása. A relációsán teljes

rendszernek már az

elsőrendű predikátumkalkulussal ekvivalens lekérdező nyelv­ vel kell rendelkeznie, a tökéletesen relációs rendszernek pedig kezelnie kell emellett a hiányosan megadott reláció­ sorokat is [LIPS 79l (CODD 79} , továbbá támogatni kell az adatok integritását is. Az "egyszerű" és "matematikailag megalapozott" reláci­ ós adatmodell, és az ezekre támaszkodó rendszerek tehát ko­ rántsem k“nnyen áttekinthetlek, hiszen az alapvető fogalmak

9

-

is folyton változnak, fejlődnek. Jelen tanulmány célja nem lehet a rendteremtés, inkább a különféle elképzelések, vé­ lemények ismertetésére szorítkozik.

10

0.1. A relációs adatmodell Az adatszerkezetek - a programozási nyelvek és az adat­ báziskezelés elméletében használt értelemben egyaránt - a logikai adatok szerkezetével /pl. verem, sor, fa/, és az eze­ ken definiált műveletekkel /a verem legfelső elemének kieme­ lése, uj sorelem beillesztése, fa valamilyen stratégia sze­ rinti bejárása/ jellemezhetők az adatszerkezet felhasználója számára. A relációs adatmodellt adatszerkezetként kezelve először a logikai adatokat, majd a rajtuk definiált művele­ teket Írjuk le. Az adatok "felhasználó-orientáltak" , a számi­ tógéphez nem értő felhasználó számára ismerős, szemléletes fogalmakkal irhatŐc Je. A műveletek absztraktabbak, az uj rendszerek ezeket igy nem is használják, de a különféle le­ kérdező nyelvek alapjául ezek szolgálnak. 0.1.1. A relációk A relációs adatbázisok alapegysége a relációi egyszerű­ en táblázatnak tekinthető, melynek adatai oszlopokban ill. sorokban helyezkednek el. További, gyakran használt analó­ gia a "rekord" szemlélet, ahol a relációnak a file, egy re­ lációs sornak egy rekord, a sor elemeinek pedig a rekord me­ zői felelnek meg.

Név

Kiss Pál Nagy Elek Simon János Kovács Zsuzsa Nagy Elek

Alapbér Szül.év

5400 4 800 6000 3200 3 200

1946 1954 1944 1964 1964

/I. ábra/

Osztály neve

Munkaügyi Játékok Elektromos cikkek Játékok Textil

Oszt.helye

I. em II. em II.em II. em TIT. e~

11

Az egyszerű "táblázatos" vagy "rekordos" szemléletet néhány szabály pontosítja [SAND 8]}: • minden táblázat csak egy reJcordti pust tartalmaz,* • minden sor rögzített számú, saját névvel rendel­ '

• • •

kező mezőből áll; a mezők mind különbözők és egyszerűek /atomikusak/, ismétlődő csoportok, és összetett mezők /olyanok, melyek maguk is relációk/ nem megengedettek /ez CcODD 70} első normálformája/* minden rekord egyedi - duplikátumok nem megenge­ dettek ; a rekordok sorrendje közömbös; a mezők értékeiket egy meghatározott értékkészlet­

ből /domain/ veszik; ' ugyanaz az értékkészlet több különböző mezőhöz is felhasználható; • uj táblázatok hozhatók létre két létező táblázat azonos értékkészlethez tartozó mezői értékeinek egyezése alapján. Egy mező értékkészlete

általános, alkalmazás-független

halmaz /egész számok alsó és felső határ között/, vagy pedig alkalmazás-függő /az áruház osztályainak nevei/ lehet. [CODD 79} javasolja minden relációhoz az E-értékkészlet,ill. egy pótlólagos mező bevezetését. Az E-értékkészlet /E mint entitás/ lényegében a relációs sorok bel­ ső azonosítóinak halmaza volna és a megfelelő mező egysze­ rűen a sor azonosítását szolgálná azzal, hogy a sor belső azonosítóját tartalmazná a felhasználó számára hozzáfér­ hető módon. Ez az elképzelés az entitás-kapcsolat /entityrelationship/ modell £cHEN 76} felé általánosítaná a re­ lációs adatbázisokat, ugyanis a felhasználó igy könnyebben definiálhatná a különböző táblázatba tartozó sorok /enti­ tások/ közötti összefüggéseket - reláció formában /hiszen minden sornak egyedi, explicite hivatkozható "neve lenne/.

12

Másik érdekes általánositása a relációs modell ér­ tékkészlet lehetőségeinek az absztrakt adatbázis adat­ típusok. Itt a mező értékkészlete absztrakt adattípus, melyre a különféle rendszerek különböző definíciós le­ hetőségeket biztosítanak. Az absztrakt adattípus értékkészletü reláció jellegzetes példája az SDLA rendszer C k Nü T 80] . A jelenleg működő adatbáziskezelő rendszerek rendsze­ rint nem támogatják a bevezetett "értékkészlet" fogalmat teljes általánosságban. Általában az operációs rendszer által támogatott értékkészletekre /karaktersorozat, egész szám, stb./ szorítkoznak, ezek közül választhat a felhasz­ náló. A relációt precízebben a matematikai fogalommal /ér­ tékkészletek Descartes-szorzatának részhalmaza/ szokás definiálni. Megemlítendő, hogy egy relációnak, és minden egyes oszlopának /mezőjének/ saját névvel kell rendelkez­ nie, melyre hivatkozni lehet /Id. 1. ábra "Dolgozó" re­ lációja/ . Az adatszerkezet része az integritási feltétel. Ez valamilyen, az adatbázis adatainak állapotára, köztük lévő összefüggésekre utaló állitás, melynek az adatbázis konzisztens állapotában érvényesnek kell lennie. Néhány példa: "Minden dolgozónak legfeljebb egy közvetlen főnöke van. " "A fizetések /időben/ nem csökkennek." "Az intézet dolgozói alapbéreinek összege nem lehet több, mint az intézeti béralap." Ezeket az állításokat a felhasználónak kell megadnia va­ lamilyen magas szintű nyelven, és a rendszernek automa­ tikusan biztosítania kell az állítások igazságát minden módosítás esetén. A jelenlegi gyakorlat általános integritási felté­ telek kezelésétől elég messze van JcODD 82} . Az INGRES rendszer egyváltozós állítások kezelésére /pl. fizetés 30000 8t fizetés > 2000/ képes. Az ORACLE Version 3. ezen kivül uj érték bevitelénél ellenőrzi, hogy az érték más reláció valamelyik sorában már létezik-e

13

/pl. ha a "dolgozó" relációban az "osztály" mező értéke "elektronika", az "osztályok" relációban ellenőrzi, hogy van-e ilyen nevű osztály/, és felújítási eljárások más felújítások automatikus elvégzését implikálhatják /pl. ha az "elektronika" osztályon dolgozó "N. Wiener" nevű dől- . gozót törli a felhasználó, a "dolgozó" relációból, akkor a rendszer az "osztály létszáma" mező értékét eggyel csök­ kenti az "osztályok" reláció megfelelő sorában/. Az IBM SQL/DS rendszere csupán annyit biztosit, hogy egyes mezőkben nem en­ ged meg "nulla" értéket. [piEC 8l] . Nem foglalkozunk a különféle relációs normálformákkal. Ezek lényegében véve a relációk épitésére vonatkozó javas­ latok, azt célozzák, hogy a felhasználó "célszerűen" de­ finiálja relációit /pl. csak egy dologra vonatkozzon a reláció, ne keveredjenek benne két különböző entitás tu­ lajdonságai, mine ahogyan az 1. ábrán látható relációban a dolgozó adatai keverednek az osztályáéval/. Ezek a nor­ málformák jobb szerkezetű adatbázis felépítést tesznek lehetővé, de egy relációs adatbázis implementálásához nem szükségesek CSAND síi • 0.1.2. A relációkkal végezhető műveletek A relációs modell egyik legrokonszenvesebb vonása, hogy viszonylag

könnyen használható és "erős" felhaszná­

lói nyelveket lehet hozzá konstruálni. Napjainkra a mani­ pulációs nyelvek száma elég sok tucatra becsülhető, és gyarapodásuk sebessége nem csökken. Ezeknek a nyelveknek az értékelése és összehasonlitása nem könnyű feladat. A magas szintű nyelvek alapjául alapvetően két ma­ tematikailag megalapozott formális mechanizmus szolgál: a relációkalkulus és a relációalgebra. Mind a kettőt még Codd vezette be (CODD 70}

[cODD 71aJ, (cODD 71c) . A továb-

14

biakban egyikre sem adunk pontos

definíciót - ez elég

hosszadalmas és fárasztó - inkább példákkal illusztrál­ juk a formalizmusokkal specifikált lekérdezések stilusát /Matematikailag preciz leirásuk megtalálható pl •t A M B 82} ben/. Egy lényeges vonásukat - amit a belőlük készült nyelvek is megőriztek - emeljük csak ki. A műveletek rel ciókon definiáltak, és eredményük is mindig reláció. A relációalgebra műveletei egy vagy két relációt használva operandusként állítanak elő uj relációt. A fon tosabb műveletek felsorolása következik: Projekció /projection/: egy adott reláció egyes ősz lopait kiválogatva, állit elő uj relációt, miután a duplikátumokat kidobta. Ha például valaki az 1. ábra "Dol­ gozó" relációjából

csak az osztályok adataira kiváncsi,

Dolgozó [Osztály neve,Osztály helye] projekcióval kapja válaszként az 1. ábra "osztály" relációj át Osztály

Osztály neve Munkaügyi Játékok Elektromos cikkek Textil

2. ábra

Osztály helye I. em II. em. II. em. III. em.

15

Korlátozás /Restriction, select/: A relációnak egy adott feltételt kielégitő sorait választja ki. A feltétel eredeti formájában CCODD 70] csak a sor két mezőjének összehasonlitása lehetett. Ez elégtelennek bizonyult, igy a definició kiegészült az egyes mező valamilyen konstanssal történő összehasonlíthatóságával. Tehát például a Dolgozó CFizetés > 500Ö1 korlátozás az 1. ábra relációjának első és harmadik sorát adja eredményül, az ábrán látható többi sor kiesik. I^]_e£Ztéj5 /join/: Két relációból /legyenek A és B/ készit egy harmadikat /C / olyan módon, hogy A és B egy-egy sorát egymás mögé illeszti, ha a két sor egyes mezőire egy megadott feltétel teljesül. Ha például A reláció az 1. ábra relációja B pedig a

Főnök

Osztály neve

Osztályvezető neve

Játékok

Barna József

Munkaügyi Elektromos cikkek

Kiss Pál Simon János

Textil

Károly György

3. ábra reláció, a Dolgozó [Dolgozó.Osztály neve=Főnök.Osztály neve] Főnök illesztés eredménye az 1. ábra relációja lesz két uj osz­ loppal kiegészítve. Az egyikben minden dolgozónál az osztály-

16

vezetője neve szerepel - ami megegyezhet a saját nevével, ha 5 az osztály vezetője, a másik, az "Osztály neve" osz­ lop, tehát minden sorban kétszer ismétlődik ugyanaz az osz­ tálynév. A relációalgebrának ezen kivül vannak halmazelméleti műveletei /egyesités, különbség, Descartes-szorzat, metszet/. Ezeket a halmazelméleti értelmükben kell venni, de alkalma­ zásuk persze értelemszerűen korlátozott /pl. két reláció csak akkor egyesíthető, ha oszlopaik száma és azok értékkészletei megegyeznek, és az egyesités után - hogy reláció legyen az eredmény - a duplikátumokat el kell hagyni/. A felsorolt műveleteken kivül egyéb műveletek is bevehetők a relációalgebrába, de már a felsoroltak is redundán­ sak, tehát egyesek levezethetőek a többiből /pl. az illesz­ tés a Descartes-szorzatból és a korlátozásból./ A relációkalkulus

nem más, mint az elsőrendű predi­

kátumkalkulus felhasználása relációs lekérdezésekre. A vál­ tozók a relációs sorokon vagy a reláció oszlopain /értékkészletein/ definiáltak [LACR 83] . A Codd-féle kalkulusból néhány példa: Az osztályok adatai a "Dolgozó"relációból: {d .Osztály neve,D,Osztály kódja: D£ Dolgozó] Az 5000-nél többet kereső dolgozók adatai: (D : D £ Dolgozó, D .Fizetés 7 5000] A "Dolgozó" és a "Főnök" reláció illesztése: ÍD,F: D£ Dolgozó, F £ Főnök, D.Osztály neve=D.Osztályvezető neve] A relációkalkulus szolgált alapul az első relációs lekérdező nyelvhez az ALPHA-hoz [CODD 71a] /Id. 1.2.1./. Sem a relációalgebra, sem pedig a relációkalkulus nem tartalmazza a működő rendszerekben elterjedt, és igen hasz­ nos aggregátum függvényeket /összeg, átlag, elemek száma/.

-

17

-

Ugyancsak hiányoznak belőlük a módosító /beillesztés, fel­ újítás, törlés/ műveletek is. A későbbiekben látni fogjuk, hogy a rendszerek által használt nyelvek általában valamilyen átmenetet képeznek az algebra és a kalkulus között - ez a felhasználó számára a legkényelmesebb. Úgy tűnik, nehezen dönthető el, hogy a procedurálisabb algebra, vagy a kalkulus a kényelmesebb-e. Egy felmérés CWELT 8^ arra az eredményre jutott, hogy az összetett kérdést könnyebb procedurális nyelven megfogal­ mazni /kb. 10 %-kal volt nagyobb a sikeres válaszok aránya/, az egyszerű kérdéseknél a pszichológusok nem találtak szig­ nifikáns eltérést. Lényeges elvi eredmény CCODD 71qJ , hogy amilyen kér­ dés megfogalmazható relációalgebrával, az kalkulussal is megadható, és viszont, tehát a két nyelv kifejezőereje megegyezik. Bármilyen olyan nyelvet, melyben a relációal­ gebra vagy kalkulus műveletei megfogalmazhatóak relációsán telj esnek nevezünk. 0.2. Történeti áttekintés Codd az alapvető CCODD 703 dolgozatot 1970-ben publi­ kálta, és még ebben az évben az MIT projektet kezdeménye­ zett relációs adatbáziskezelő rendszer készítésére /az igazsághoz tartozik, hogy Codd a dolgozat eredményéit már 1969-ben egy belső IBM anyagban /Research Report RJ 599/ közzétette azok számára, akik ilyenhez hozzájutnak/. A projekt eredményeképpen 1970-ben már működött a MADAM rendszer. Ez PL/l-ben készült H6000 gépre, és a MULTICS virtuális memória lehetőségeit használta ki. A rendszer később /1971/ összeolvadt az ugyancsak MIT-s RDMS-sel. Lényeges motívum, hogy a MADAM/RDMS külön tárolja a re­ lációs kapcsolatokat, és külön az adatmezők értékeit, oly

18

módon, hogy a relációkban minden adatot egy rögzitett hoszszuságu azonositó reprezentál.CKIM 79] 1971-ben Codd három nevezetes dolgozatot közöl. CCODD 71a] az ALPHA nyelv leírása, CCODD 71b] indítja útjára a normál­ formák és a velük kapcsolatos matematikai kérdések laviná­ ját, £CODD 71c] vezeti be a relációs teljesség /relational completeness/ fogalmát, megmutatva, hogy a relációkalkulus műveletei kifejezhetők a relációalgebra segítségével. A bi­ zonyítás konstruktiv, és a lényege a következő redukciós algoritmus: 1. A kalkulus változói relációs sorokon vannak defi­ niálva. Legyenek a megfelelő relációk S^#S2 /«--S . 2. Képezzük a D=S.x 1 S„x 2 ...xS n Descartes-szorzatot. 3. Távolítsuk el D-ből azokat a sorokat, melyek nem elégitik ki a predikátum feltételeit. 4. A kvantorok hatását fejezzük ki a relációs algebra műveleteivel, majd végezzük el ezeket a művelete­ ket D-n. 5. Projekcióval megkapjuk D-ből a kivánt relációt. Maga az algoritmus gyakorlatilag nem megvalósítható, mivel a 2. és 3. lépések igen memória és időigényesek. Mégis az algoritmus jelentős, mert felhivja a figyelmet a relációs adatbázisok működésének véleményünk szerint döntő fontos­ ságú kérdésére: a keresési stratégia megválasztására. Egyébként az algoritmus tökéletesített változata - a Palermo-algoritmus [APV1E 82] - működő rendszer része [RE3S 82] . Az IBM első relációs rendszere 1971-ben készült el Angliában IS/1, majd az uj változat 1973-tó'l PRTV /Peterlee Relational Test Vehicle/ néven. Ez relációs algebrát hasz­ nál lekérdező nyelvként. Lényeges vonása, hogy az önálló nyelvhez a felhasználó PL/1 procedúrákat illeszthet. Az adatokat süritve tárolja, és az ehhez szükséges kódolást

-

19

-

dekódolást mikroprogram végzi /a software megoldás túl las­ súnak bizonyult/. A rendszer keresési stratégiáját optimizáló program először átalakítja az algebrai kifejezéseket, majd megkísérli az optimális elérési ut kiválasztását. Az optimizálási algoritmus félhasználja CHALL 761 és USMIT 751 /ld. 2.2,7 dolgozatait, £ KIM 79, TODD 76]. A másik, ebben az időszakban /1972/ kezdődő IBM projekt /ez Massachusetts-ben/ az RM, majd XRM rendszer. Az RM bi­ náris, az XRM már tetszőleges fokszámu relációk tárolására alkalmas rendszer. A rendszer interfaoe-e igen alacsony szin­ tű, a felhasználónak belső azonosítókkal kell dolgoznia. Hasonlóan a MADAM/RDMS-hez az XRM is külön-külön tárolja a relációkat és az adatmezők értékeit. A keresést index tá­ mogatja. CKIM 79, ASTR 751 Az XRM-re épült 1974-ben a SEQUEL, 1976-ban a QBE /Query by Example/ rendszer. Az előbbi rendszer célja tu­ lajdonképpen a SEQEL nyelv használhatóságának ellenőrzé­ se, kísérleti implementáció volt, melynek úgy vágtak neki, hogy a rendszerből csak a tapasztalatokat viszik át az uj kísérleti rendszerbe - ez a System-R nevet kapta. tCHAM 811. A Query by Example jellegzetessége a grafikus adatkezelő nyelv. CKIM 79l A SEQUEL-ből kinövő uj kísérleti rendszert fejlesz­ tették tovább az IBM jelenlegi "hivatalos" relációs adat­ báziskezelő rendszerévé /SQL/DS/. A fejlesztési munka 1975-től egészen 1981-ig tarott. Az SQL/DS rendszer IBM nagygépeken DOS/VSE operációs rendzser alatt fut. Az INGRES /Interactive Graphics and Retrieval System/ kísérleti vállalkozásnak indult 1973-ban a Berkeley egyetemen. Olyan sikeresnek bizonyult, hogy 1981-től bekerült az üzleti forgalomba. VAX-11 gépeken fut. 1979-ben jelentették be az ORACLE relációs adatbázis­ kezelő rendszert. A Relational Software Inc. készítette és

20

forgalmazza, eredetileg PDP-11 gépekre, 82-től azonban IBM-re is. Ez a rendszer lényegében véve a System-Pv pro­ jekt célkitűzéseinek megvalósítása, ugyanazt az adatke­ zelő nyelvet /SEQUEL 2 vagy SQL/ támogatja mint az, fel­ tehetően a belső megoldások is hasonlóak. A nem-mikrogépes relációs rendszerek közül tudományos és üzleti szempontból egyaránt a három utolsónak említett rendszer - SQL/DS, INGRES, ORACLE - tűnik a legérdekesebb­ nek. Sajnos az ORACLE működéséről nem sokat tudunk, a má­ sik két rendszerre azonban a továbbiakban sűrűn fogunk hi­ vatkozni. Az üzleti részről még: 1981 szeptemberében, az SQL/DS még nem volt forgalomban /1982 februárjától tervez­ ték a termék kibocsátását/, az INGRES-nek 15, az ORACLEnak 80 installálását jelnetették CDIEC 811. 1982-től indul meg a mikrogépes relációs adatbázis­ kezelő rendszerek áradata. Az 1981-ben forgalmazott adat­ báziskezelők közül csak a CONDOR deklarálta magát relá­ ciósnak CBARLí 81] , ez is "korlátozott /limited/ relációs rendszer" a cikk szerzői szerint. 1983 februárjában Toulouseban már relációs rendszerek mikrogépes implementációjáról és felhasználásáról szervez az INRIA konferenciát CWORK 83] . Itt a csak az amerikai rendszereket áttekintő [MARY 83] dolgozat hét rendszert ir le /igaz ebből kettő biztos, hogy még a "minimálisan relációs" rendszerekkel szembeni CCODD 82] követelményeket sem elégiti ki, lévén, hogy nem tudja az illesztést/, de emliti, hogy ez csupán önkéntes kiemelés. A létező, és általunk ismert mikrogépes rendszerek közül a továbbiakban jónéhányra fogunk hivatkozni. Nem emlitettük még ebben az igen felületes áttekintés­ ben az adatbázis gépeket /data base machine/. Ezek relá­ ciós adatkezelést támogató speciális célgépek és a rájuk épülő rendszer. 1981-ben már három ilyen rendszert for­ galmaztak tSNYD 82], tehát létező dolgok, de jelen tanulmány

21

ezekkel nem foglalkozik. Ugynacsak hasonló okból maradtak ki, az osztott, és a természetes nyelvű

interface-t biz­

tositó rendszerek is, noha mind a két témakör tekintélyes irodalommal, és működő rendszerekkel /SDD-1, PLANES, stb./, rendelkezik.

22

1. A FELHASZNÁLÓI INTERFACE Egy rendszer használhatósága szempontjából döntő fon­ tosságú az a mód, ahogy a felhasználó a rendszert látja, az a forma, amelyben igényeit közölheti, és az eredményeket meg­ kapja. A relációs adatbáziskezelő rendszerek felhasználói ±nterface-eit áttekintve elég változatos a kép. A legelterjedtebbek az önálló /stand alone/ nyelveken hozzáférhető rendszerek. Ezek a nyelvek interaktívak - a re­ lációs rendszerek ad hoc kérdésekre adott válaszadó képessé­ geit igy lehet kihasználni - de vannak olyan rendszerek, me­ lyek batch lehetőségeket is támogatnak. A terminálon megje­ lenő információk, és a rendszerrel szembeni igények megfogal­ mazása általában szöveges, de léteznek ennél kényelmesebb de legalábbis látványosabb - grafikus rendszerek is. Az önálló nyelv mellett - rosszabb esetben - szükség van adatbázis hozzáférésre programozási nyelvből is. Sok rendszer biztosítja ezt a lehetőséget oly módon, hogy egy programo­ zási nyelv - gazdanyelv /host language/ - utasitáskészletét relációs adatbáziskezelő utasításokkal egészíti ki. Kellemes, ha ezek az uj utasítások megegyeznek a rendelkezésre álló önálló, adatkezelő nyelv utasitáskészletével /vagy legalább annak részhalmazát alkotják/. £CODD 821 ezt a tulajdonságot "univerzálisan relációs"-nak nevezi, és több érvet hoz fel mellette. Léteznek persze rendszerek, ahol ez nincs meg - mikrogépen nem ismerünk olyan rendszert, mely univerzálisan re­ lációs lenne - de sokszor szükséges legalább kettős - önálló és gazdanyelvből való - hozzáférés lehetősége, függetlenül attól, hogy a két nyelv megegyezik-e. Igen érdekes az az irányzat, mely a gazdanyelvek és az adatkezelő nyelvek teljes összeolvadása mellet tör lándzsát. Itt lényegében véve arról van sző, hogy az absztrakt adat­ típus konstrukciókat támogató nyelvek minimális bővítéssel v-e.1áciék kez°lé«3ére alkalmassá tehetők. Ezek a bővítések

23

szervesen illeszkednek bele "stílusukban" is a befogadó nyelv­ be, fogalmaik annak fogalmaival keverednek, annyira, hogy nem lehet "gazdanyelvről" és "adatnyelvről" /data sublanguage/" beszélni, hanem uj egységes programozási-adatkezelő nyelv jön létre /PASCAL/R [SCHM 77, ALAG 8ll, MODULA/R UREIM 833/. Ez persze azt is jelenti, hogy a megfelelő fordítóprogramokat módosítani kell, nem lehet a gazdanyelv - adatnyelv konstruk­ cióknál szokásos előforditási technikát alkalmazni CREIM 833. Ebben a részben először az önálló nyelvek közül Írunk le néhányat, előbb az adatdefiníciós lehetőségeket /adatbázis, reláció, index, stb. létrehozása/, majd a lekérdező és módo­ sító nyelvet tárgyalva. Külön fejezet foglalkozik a magasszintű nyelvekből való adatkezeléssel, bemutatva a különböző irányzatokat. Az egyes nyelvek használatát tCHAM 76j minta adatbázisán mutatjuk be. Ez a következő relációkat tartalmazza. Dolgozó(Törzsszám, Név, Részlegkód, Besorolás,Főnök, Alapbér) Részleg(Részlegkód, Részlegnév, Cim) Felhasználás(Részelgkód, Cikkszám) Szállítás (szállító, Cikkszám') A Dolgozó és Részleg relációk egy vállalat dolgozóiról és részlegeiről, a Felhasználás reláció a részlegek által fel­ használt anyagokról, a Szállítás pedig ezek szállítóiról tar­ talmaz adatokat. 1.1. Adatdefiniciós lehetőségek Egy adatbáziskezelő rendszer használata mindig az ada­ tok definíciójával kezdődik. A felhasználó /adatbázis admi­ nisztrátor/ itt írja le az adatbázis szerkezetét, hogy mi­ lyen adatokat kíván használni, sokszor azt is, hogy milyen

24

módon. A logikai adatszerkezet mellett a fizikai tárolásra vonatkozó útmutatást is adhat a rendszernek - az egyes adat báziskezelők adatfüggetlenségét jellemzi, hogy mennyi ilyen jellegű információt lehet, mennyit kötelező megadni, és ez milyen következményekkel jár majd az adatbázis létezése so­ rán . . Igen nagy előrelépés a CODASYL tipusu adatbázisokhoz képest, hogy a relációs rendszereknél az adatdefiniciós le­ hetőségek sokkal dinamikusabbak, és egy-egy döntésnek a következményei sokkal kisebbek. Mig a CODASYL-nál a séma változtatása igen nehézkes - általában teljes adatbázis új­ raszervezést igényel - a relációs rendszerekben bármikor definiálható vagy törölhető egy reláció, vagy index. A CODASYL séma explicite Írja le a fizikai elérési utakat, mig a relációs rendszerekhez a fizikai elérésre csak igen óvatos utalások - index szervezése, kapcsolat létrehozása - vannak, és ezek is legfeljebb valamilyen elérési lehető­ ség hatékonyságát, de nem a létezését befolyásolják. 1.1.1. SQL/DS a/ Reláció létrehozása A reláció nevét, és az oszlopok neveit, valamint típu­ saikat kell megadni. A felhasználó megtilthatja egyes oszlo pókban a nulla értéket. A Részleg reláció definíciója pl.: CREATE TABLE RÉSZLEG [ RÉSZLEGKÓD (.CHARC2) ,NONULl ) , RÉSZLEGNÉV (cKAR C l 2) VAR) , c í m (c h a r (20) v a r )) Az SQL/DS valamennyi IBM/370 adattípust támogat

£DIEC 81]

25

b / Szinonima definiálása relációhoz DEFINE SYNONYM ÜZEMEGYSÉG AS RÉSZLEG c/ Index létrehozása Az SQL/DS, mint általában a relációs rendszerek az elé­ rés meggyorsitására indexeket használ. Ezeket o képnek /image/ nevezi. Ezek - éppen úgy, mint a relációk - dinamikusan, bár­ mikor, bármilyen oszlop /vagy oszlopkombináció/ szerint lét­ rehozhatók, vagy törölhetők. Létezésük nem befolyásolja a re­ láció lekérdezhetőségét, ha valamilyen oszlop szerint nincs index, azért a relációból kiválasztható pl. az a sor, ahol az illető oszlopban 2568 áll. Mindebből adódik, hogy az "index" fogalmának bevezetése - noha fizikai szervezésre utal - nem csorbitja az adatfüggetlenséget. Az index helyezésre. A hogy az index kedő sorok az

további utalást tartalmazhat a fizikai adatel­ CLUSTERING tulajdonság előirja a rendszernek, definiálta sorrendben egymáshoz közel elhelyez­ adatbázisban is egymás közelében helyezkedjenek

el. /Érdekes lenne tudni, hogy ha egy létező relációhoz de­ finiál az ember CLUSTERING indexet, csinál-e valamit a rend­ szer, tehát megmozgatja-e reláció már létező sorait. Valószinü, hogy a CLUSTERING csak a reláció jövőjére vonatkozik./ Az index másik tulajdonsága a UNIQUE lehet. Ez azt je­ lenti, hogy azok a sorelemek melyekre az indexet szervezzük a reláció kulcsai, vagyis nem lehet a relációnak két olyan sora, ahol ezekn de az elemeknek az értéke egyenlő. A következő példa a Dolgozó relációra Jcészit az Alapbér szerint indexet: CREATE IMAGE FIZIND ON DOLGOZÓ (ALAPBÉR^

26

d / Kapcsolat létrehozása Szintén fizikai elérést meggyorsító mechanizmus, mely­ nek - elvben - nem lenne helye egy relációs nyelvben, de éppúgy mint az index, ez sem jelent adatfüggőséget, A kap­ csolat /link/ két relációnak azokat a sorait köti össze /pointerekkel/, ahol a kapcsolatot meghatározó adatmezők­ ben az adatok értéke megegyezik. Ez nyilvánvalóan az olyan illesztéseket gyorsítja meg, ah~l az illesztés feltétele egyenlőség /o.l.2./. A kapcsolat is lehet CLUSTERING, ilyen kor a rendszer az összetartozó sorokat egymás közelében próbálja elhelyezni. Kapcsoljuk össze a Dolgozó és a Részleg relációk so­ rait a Részlegkód alapján! A kapcsolat /nyilvánvaló l:n lesz/ egy Részleg sorához tartozó Dolgozó sorai legyenek rendezve Besorolás és Fizetés szerint! CREATE LINK L FROM RÉSZLEG RÉSZLEGKÓD TO DOLGOZÓ RÉSZLEGKÖD ORDER BY BESOROLÁS FIZETÉS e / Nézőpont /view/ létrehozása A nézőpont tulajdonképpen nem más, mint az adatbázis relációiból létrehozott uj reláció, amely létrehozása után éppen úgy használható /kérdezhető, felújítható, stb./, mint bármely másik reláció. A létrehozás tulajdonképpen lekérde­ zéssel történik. A lekérdezés eredménye - a relációs modell ben természetesen /o.l.2./ - reláció, de ahelyett, hogy ez nyomtatás, vagy terminálra irás után elveszne, nevet kap és megőrződik. Definiáljuk a Programozási Osztályt, mint részleget! /A lekérdezés formalizmusa 1.2.3.-ban található./

27

DEFINE VIEW PROGRAMOZÁSI-OSZTÁLY SELECT DOLGOZÓ.NÉV,DOLGOZO.ALAPBÉR,RÉSZLEG.CÍM FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.RÉSZLEGKOD=RÉSZLEG. RÉSZLEGKÓD AND DOLGOZó.BESOROLÁS='PROGRAMOZÓ' Az uj relációnak - mert innentől a nézőpont annak számit három oszlopa lesz, és a 'programozó' besorolású dolgozók nevét, fizetését, munkahelyének cimét tartalmazza. Egyéb­ ként a rendszer fizikailag nem hozza létre az uj relációt, pusztán a nézőpont definicióját jegyzi meg, és a nézőpont­ ra való hivatkozásoknál azt helyettesíti be a hivatkozás helyére. f/ Reláció létrehozatala és feltöltése létező relá­ ciókból Formálisan nagyon hasonlit a nézőponthoz: ASSIGN TO PROGRAMOZÁSI-OSZTÁLY SELECT DOLGOZÓ.NÉV,DOLGOZÓ.ALAPBÉR,RÉSZLEG.CÍM FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.RÉSZLEGKÓD=RÉSZLEG.RÉSZLEGKÓD ADN DOLGOZÓ.BESOROLÁS='PROGRAMOZó' de lényegét tekintve más. Mig a nézőpont - noha önálló relációnak számit minden szempontból - a későbbiekben függeni fog azoktól a relációktól, melyekből létrejött /ha azok változnak ő is megfelelően változik, és viszont/ a feljebb lérehozott reláció teljesen független a létreho­ zó /Dolgozó,Részleg/ relációktól. Az uj reláció a két re­ láció megfelelő adatainak a létrehozás pillanatában rög­ zített állapotát tükrözi, és függetlenül attól, hogy a két reláció adatai hogyan változnak a jövőben, ez az álla­ pot nem módosul automatikusan. Itt tehát tényleg uj reláció

28

létrehozataláról és ennek adatokkal való feltöltéséről van szó, mig a nézőpont valóban az, amire a neve utal: egy adatbázis "ablak", melyen benézve tulajdonképpen nem uj relációt látunk, hanem a régi relációkat, csak speciális módon, másként válogatva, csoportosítva. Az SQL/DS garan­ tálja, hgoy a nézőpontok és a többi reláció konzisztens marad, de az ASSION-nai létrehozott reláció és a létreho­ zó relációk között minden kapcsolat megszakad. Itt nyil­ vánvalóan az uj reláció fizikailag is létrejön. A nézőpont nyilvánvalóan "erősebb" lehetőség - ennek megfelelően a megvalósitása is nehezebb lehet. g / Reláció bővítése Jó lehetőség az SQL/DS-ben, hogy szükség esetén^léte­ ző relációk uj oszlopokkal bővíthetők. Az uj oszlopok a létrehozás pillanatától /"definiálatlan mező" értékű adat­ mezőkkel/ léteznek. A mezők a szokásos módositó utasítá­ sokkal kaphatnak értéket. Kiegészítjük a Részleg relációt a Létszám oszloppal: EXPAND TABLE RÉSZLEG ADD COLUMN LÉTSZÁM (INTEGER^ h / Reláció, nézőpont, index, kapcsolat megszüntetése Ez is bármikor megtehető, pl. DROP VIEW PROGRAMOZÁSI_OSZTÁLY h / Megjegyzés COMMENT ON THE VIEW PROG RAMOZÁSI_OSZTÁLY: 'EZ NEM IS EGY OSZTÁLY, CSAK AZ ÖSSZES PROGRAMOZÓ BESOROLÁSÚ DOLGOZÓ HALMAZA' fCFaM

29

1.1.2. INGRES Az utasítások tartalmukban nagyon hasonlóak az SQL/DSéihez, ezért általában nem magyarázniuk okét, legfeljebb azo­ kat, amelyek nincsenek meg, vagy másképp vannak itt mint ez SQL/Ds-ben. a/ Reláció létrehozása, törlése CREATE RÉSZLEG (RÉSZLEGKÓD IS CHAR(.21 , RÉSZLEGNÉV IS CHAR(l2l , CÍM IS CHAR (2Ő)) DESTROY RÉSZLEG /Nincsenek változó hosszúságú karaktersorozatok, 1,2,4 byte fixpontos, 4 és 8 byte lebegőpontos számok, és max. 255 byte hosszú karaktersorozatok vannak./ b / Reláció másolása Ez vagy létező reláció adatait Írja ki adatfile-ba, vagy az adatfile-ból tölt fel egy relációt adatokkal. COPY RÉSZLEG (RÉSZLEGNÉV IS CHAR (40) , RÉSZLEGKÓD IS CHAr CIO)) FROM RÉSZLEGEK Az utasitás a Részleg relációt felölti a Részlegek nevű file-on található adatokkal. A file logikai rekord­ jának felépítése a formátumlistán látható: a részlegnév 40, majd utána a részlegkód 10 karakter hosszú. A rendszer felhasználva a Részleg reláció definícióját elvégzi a szük­ séges konverziót, és feltölti a reláció két oszlopát. Reláció adatfile-ra írása ugyanígy történik 'FROM' helyett 'TO' kulcsszót használva. Speciális adatfile-ra irás a reláció terminálra Írása, pl.: PRINT RÉSZLEG

30

c/ Tárolási struktúra változtatása Ez lényegében véve index definiálását, ill. a fizi­ kai tárolás előírását jelenti. A fizikai tárolást 2.3.2ben Írjuk le, itt csak annyit emlitünk meg, hogy ezek az utasítások éppen úgy nem jelentenek fizikai adatfüggősé­ get az INGRES számára, mint a kép ill. kapcsolat az SQL/DS-nél. Megjegyezzük még, hogy a relációt létrehozó utasításban nem történik utalás a szervezési módra. CDIEC 811-ből kiderül, hogy a rendszer a legegyszerűbb tárolási módra a heap-re - rendezetlen, soros elérésű file - készül fel, és a tárolási struktúra változatásával adható meg a kívánt tárolás. Legyen Részleg reláció index-szekvenciális file-ként tárolva a Részlegkód szerint! MODIFY

RÉSZLEG TO ISAM OL(RÉSZLEGKÓD),

és csináljunk hozzá a'Részleqjév szerint egy indexet! INDEX ON RÉSZLEG IS NÉVINd (r ÉSZLEGNÉv ) Az INGRES egyébként az indexet közönséges reláció­ ként kezeli, melynek oszlopai a relációnak azok az oszlo­ pai, amelyek szerint az index készült /jelen esetben a részlegnév/ és plusz még egy oszlopa a reláció sorainak azonosítóját tartalmazza. d/ Reláció feltöltése létező relációkból Ugyanaz , mint az SQL/DS-ben. Például az. 1.1.1 f-ben definiált Programozási Osztály itt is megadható: /miután egy CREATE definiálta/ RANGE OF D IS DOLGOZÓ RANGE OF R IS RÉSZLEG RETRIEVE INTO PROGFAMOZÁSI_0SZTÁLY D.NÉV, D.ALAPBÉR, R.CIM WHERE D.RÉSZLEGKÓD=R.RÉSZLEGKÓD AND D.BESOROLÁSÉ PROGRAMOZÓ' ÜSTÖN 76, EPST 77}

31

1.1.3. QBE A QBE /Query By Example/ rendszer grafikus interface-t biztosit a felhasználó számráa. A reláció táblázat, és en­ nek a táblázatnak a "csontvázába" /ld. 4. ábra/ helyezi be a szöveges információt a felhasználó, ha igényel valamit a rendszertől, ill. a rendszer válaszadásnál.

I I

4.

ábra

a/ Reláció definiálása A felhasználó kitölti a képernyőn megjelenő "csontváz"at, pl. igy

RÉSZLEG

RÉSZLEGKÓD CHAR

RÉSZLEGNÉV CHAR 12

2

5. ábra

CÍM CHAR 20

32

/Jellemző a QBE-re, hogy a gyakorlatlan felhasználó megkérheti a rendszert, hogy Írja ki, hogy milyen adato­ kat kell megadnia. Miután a reláció nevét is az oszlopo­ két megadta, a relációnév - jelen esetben "Részleg" alá irt"P." /print/ hatására megjelenik a I RÉSZLEG

RÉSZLEGKÖD

RÉSZLEGNÉV

CÍM

TYPE LENGTH KEY DOMAIN SYSNULL

6. ábra táblázat/. b / Reláció bővitése Szintén grafikusan történik, lényegében úgy, mint a definiálás. A rendszer a felhasználó kívánságára kiír­ ja a Részlegtábla definícióját, az első oszlopot a 6. a többit pedig az 5. ábrán látható módon. A felhasználó az üres oszlopot tölti ki, úgy mint reláció definiálása­ kor. Az uj oszlop adatai felújításukig "definiálatlan mező" /sysnull/ értékkel bírnak. c / Reláció törlése, reiácxónév változtatása A lekérdezett táblába /pl. 6. ábra/ a reláció neve elé "D." ill "U." írásával. Névváltoztatás esetén a régi nevet át kell írni vrj ná'né, Oszlón törlése ugyancsak

33

az oszlopnév elé irt "D."-tal, névváltoztatás "U."-tal tör­ ténik . <3/ Reláció feltöltése létező relációkból Ugyanaz a funkciója, mint az INGRES esetében /1.1.2.d/ A formalizmusának lényege - egy lekérdezés eredményét tá­ roló uj relációként - is ugyanaz, de persze mindez QBE-ben. A felhasználó itt három táblával dolgozik. A Dolgozó tábla:

DOLGOZÓ

1--- "'— r- - — ■ " TÖRZiíS ZÁM NÉV |RÉSZLEGKÓD

BESOROLÁS j...

NI

XXX

PROGRAMOZÓI 1

1

ALAPBÉR 5Ft

A részleg tábla: RÉSZLEG

RÉSZLEGKÓD

RÉSZLEGNÉV

CÍM AB

NI Az uj programozási Osztály tábla: PROG RAMO ZÁSI_0 S ZTÁLY

NÉV

ALAPBÉR

CÍM

XXX

5 Ft

AB

t

Az aláhúzott nevek változók.Ezeknél nem a konkrét név szá­ mit, hanem az, hogy hol jelenik meg. Pl. A Dolgozó tábla "Név"

oszlopában az "XXX" helyett állhatna

"KISS PÁL" is,

a fontos az, hogy a Programozási Osztály tábla Név oszlopá­ ban ugyanaz álljon, jelezve, hogy a lekérdezés eredményeként kapott akármilyen nevet - legyen az "XXX" vagy "KISS PÁL",

34

vagy bármi más - kell az uj tábla Név rovatába irni. Ugyan­ az a helyzet az "5 fi", "AB" változókkal is. Az Ni segéd­ változó, a feltétel megfogalmazásához, a Dolgozó és Részleg táblák illesztéséhez szükséges /ld. 1.1.2.d feltételének első tagját/. kat a sorokat /ld. 1.1.2.d. nyelv leirása

A 'Programozó' konstans jelzi, hogy csak azo­ kell kiválogatni, ahol a besorolás 'programozó feltételének második tagját/. /A lekérdező megtalálható 1.2.5-ben/.

e / Nézőpont definiálása A nézőpont a QBE-ben ugyanazt jelenti, és ugyanúgy viselkedik, mint az SQL/DS nézőpontja /l.l.le és l.l.l.f/. Definiálása a d-ben leirt módon történik, de a "Programo­ zási Osztály" név elé odaírandó a "VIEW" kulcsszó.LZLOO 77l 1.1.4 Általános áttekintés. Mikroaéoes rendszerek a/ Reláció létrehozása Ez a rendszereknél gyakorlatilag egyformán történik. Alapkövetelmény, hogy bármikor lehessen uj relációt defi­ niálni /legalábbis a dolgozatok szerzői sehol nem emlitik, hggy előre rögzitett relációs sémával dolgoznának. CEBER_83.1 dolgozat egy TRS 80/I-re készült rendszert ir le. Ez csak karaktersorozat tipusu adatokat enged meg, de ezek a rendszerbe való bekerüléskor automatikusan ellenő­ rizhetők a következő módokon: Formátumlista: legegyszerűbb példán keresztül meg­ mutatni. Ha valamilyen oszlopban szerepelhető adatok formátu maként "AB adunk meg, a rendszer csak olyan adatokat enged meg az oszlopban, melyek első két karaktere 'Ats' utá­ nuk számjegy /0— 9/ következik, a két utolsó karakter tet­ szőleges .

35

Megszámlálható, vagy intervallum adattípus. A progra­ mozási nyelvekből átvett ötlet: előbbinél fel kell sorolni a megengedett adatértékeket, utóbbinál az intervallum /lexikografikusan/ alsó és felső határát. A rendszerbe kerülő értékek ellenőriztetése elég könynyen kivitelezhető, hasznos gondolat, hagyományos file­ kezelő rendszerekben elég gyakori /főleg mikrogépeken/. CKAMB_8J3l egy igen erős séma definíciós és restrukturálási lehetőségekkel biró rendszert ismertet. Itt egy-egy oszlop definiálásánál a szoxasos adatok mellett megadható kétféle null érték /"nem létezik" "nem tudom" null/ meg­ engedése, vagy meg nem engedése is. A rendszer megengedi a halmaz értékű oszlopokat, vagyis azokat ahol egy adat­ mezőben egyszerre több érték is szerepel. /Például a "Könyv" relációnak "Szerző" oszlopában szerepelhet értéknek a (Aho, Ullman) pár, és lekérdezésnél a megfelelő sor úgy a Szerző='Aho', mint a Szerző='Ullman' feltételnek eleget fog tenni./ A reláció definiálásakor az oszlopok, mint halmazok kö­ zött 1:1 és l:n kapcsolatok irhatok elő. b / Relációk átszervezése LKAMB 83l dolgozat ismertetését folytatjuk. A szoká­ sos lehetőségek /uj oszlopok beillesztése, létezők törlé­ se/ megengedi • az oszlop jellemzőinek /tipus, hossz/ változtatásátj ' az a / pontban ismertetett attribútumok /null-érték, l:n kapcsolatok, stb. / változtatását; • egy oszlop több részre vágását, vagy több oszlop egyesítését /pl. a "Dátum" oszlop szétvágható "Év", "Hónap" és "Nap"-ra/ és még egy sor más lehetőséget. A rendszerrel kapcsolatban meg kell jegyeznünk, hogy

36

a példák alapján úgy tűnik, hogy könyvtári nyilvántartásra használják, ezért szükséges a séma fantasztikus rugalmassá­ ga. Egyébként Z-80 alapú japán gépen fut CP/M alatt 10 MBos Winchester lemezt használ. A rugalmas adatdefiniciós és átstrukturálási lehetőséget elég speciális belső szer­ vezéssel éri el. c/ Index létrehozása Az SQL/DS és INGRES esetében ez explicite, a felhasz­ náló utasítására történik /l.l.l.c cs 1.1.2c/. A QBE-nél erre nem találtunk utalást, gyanítjuk, hogy úgy történik, mint az a/ pontban már emlitett [EBER £33] leirta rendszer­ nél. Ott ugyanis a felhasználó a reláció definiálásakor kijelöli azokat a mezőket, melyek a reláció kulcsai /ezt a fogalmat CCODD 70] vezette be, itt egyszerűen mint köz­ vetlen elérési - nem emlitik, hogy azonosítási - lehetősé­ get használják/. A kijelölt kulcsokra készit ezután a rend­ szer automatikusan indexet. Ennek a módszernek hátránya /lehet/ az indexek stati­ kus jellege. Hacsak a rendszer nem engedi meg a kulcsok újradefiniálását menet közben /ez elég valószinütlen/, ak­ kor az indexek, s velük együtt a hatékony közvetlen hozzá­ férés útvonalai egyszer s mindenkorra ki vannak jelölve. Vannak rendszerek, ahol azért nincs indexet létreho­ zó utasitás, mert nincs index. Ilyen például a VIDEBAS_ UBLAN 83l , mely igen sajátos implementáció - minden adat­ mező szerint lerendezi a relációt, és több példányban, index-szekvenciális file-okként tárolja. Ennél a rendszer­ nél /DEC-system 10-en fut természetesen nagy lemezekkel/ nincs szükség indexre. Az RQL esetében fMASR 83] az indexek hiánya elég lassú működéshez /több mint 1 órás várakozási idők/ vezet /viszont 48 K-s APPLE Il-n fut/.

37

Három változattal találkoztunk tehát; • explicit indexdefiniálás /SQL/DS/; • implicit indexdefiniálás /[EBER 833 /; • nincs indexdefiniálás, mert nincs index. Elképzelhetőnek tartanánk egy másik, elég kényelmes és ha­ tékony /de vajon könnyen megvalósítható?/ változatot. A . rendszer maga döntene indexek létrehozásáról, megszünteté­ séről a saját statisztikái alapján. Ily módon, valamiféle stratégia szerint annak jóságától függően előbb vagy utóbb el lehetne jutni oda, hogy a sűrűn használt adatokra létez­ ne index. Az explicit indexdefiniálás majdnem ezt csinálja, csak ő a statisztikát a felhasználóval /adatbázis adminiszt­ rátor/ vezetteti. d/ Reláció másolása külső file-ról/ra Elég könnyű lehet megvalósítani, nyilvánvalóan szüksé­ ges művelet, tehát eléggé elterjedt, ld. pl. a PRTV "relá­ ciós file"-ja [TODD 763. A mikrogépeken ritkábban fordul elő, feltehetően a viszonylag kevés tárolható adatot termi­ nálról is be lehet vinni, és mivel nincs multiprogramozás nem érdemes külön előkészíteni az adatokat. e / Reláció feltöltése más relációkból Ügy tűnik ez bonyolultabb ügy, mint az előző, nem el­ terjedi. lehetőség. [KAMB_8_31 rendszere nem uj relációt szervez más relációkból, hanem átstrukturálja a rendszert, a generáló /feltöltő/ relációk eltűnnek, és az uj reláció veszi át helyüket. f/ Kapcsolat, nézőpont definiálása Előbbivel csak az SQL/DS-nél, utóbbinál pedig az SQL/DS-

38

nél és a QBE-nél találkoztunk. A kapcsolat igen hatékonnyá tud tenni egyes művelete­ ket /illesztések egyenlőség alapján/ de megvalósitása kö­ rülményes pl. egy olyan rendszerben, ahol a sorok B-fában helyezkednek el, fizikai elhelyezkedésük szüntelenül vál­ tozik, igy csak szimbolikus pointer vagy indirekt cimzés alkalmazható. Ez még a kisebbik baj, de az amúgy is igen bonyolult optimizálási algoritmusokba /2.2/ nehéz beillesz­ teni a kapcsolatot - legalábbis erre gondolunk. A nézőpont megvalósitása sem lehet egyszerű. A felújí­ tása körül bonyolult esetekben logikai problémák merülnek fel. Egyébként fCHAM 76] a nézőpont felújításával kapcsola­ tosan korlátozásokat: is eimleget - tehát a felhasználó ko­ molyabb bonyodalmakba is keveredhet. Egyébként CDIEC 81] sem az SQL/DS sem pedig az ORACLE lehetőségei között nem említi a kapcsolat és a nézőpont definiálását. g / A relációs modell kiterjesztése Izgalmas kísérlet ebben az irányban a LIDAS

rendszer­

re épülő interaktiv adatdefiníciós interface, a GAMBIT CBRAG 83, REBS 83]. Entitásokkal és kapcsolatokkal £CHEN 76] dolgozik - ezt az irányzatot már ECODD 79] sürgette - és erős szemantikai kifejezőerővel bir. A rendszer grafikus technikát használ, de a relációs szimbólumok helyett /táblázatok/, az entitás-kapcsolat modell dobozait /ez jelképez egy entitást/ és összekötő vonalait /az entitások közötti kapcsolat/ használja. Ez az első lé­ pés tehát, az entitások és ezek egymás közötti kapcsolata­ inak megadása. Második lépésként az entitásoknak, mint relációknak a megadására kerül sor. Először a szemantikailag fontosabb oszlopokat jelöli meg a felhasználó - egy oszlop fontosságát

39

az jelzi, hogy több entitásban is szerepel ilyen módon tart­ va fenn a közöttük fennálló kapcsolatot /globálisnak nevezi okét a GAMBIT/ - majd a többi, lokális jellegű adatot. Mind­ ez persze grafikus segitséggel. A harmadik lépésben integritási feltételek adhatók meg /l:n kapcsolat, kulcs tulajdonság,stb./. Ezek eléggé bonyo­ lultak is lehetnek, ugyanis a befejező lépés az adattipus kialakításában a műveletek /tranzakciók/ megadása, és ez­ zel a lépéssel valamennyi definiált entitás és kapcsolat a rajtuk definiált műveletekkel együtt MODULA/R absztrakt adattípussá válik. Szó szerint ugyanis a GAMBIT az adatdefinició befejezése után MODULA/R /1.3.2/ programot gene­ rál, és - forditás után - ez lesz a továbbiakban a futó program. Nagyon rokonszenves vonásai a rendszernek a szemantika­ orientáltság, és az, hogy az adatbázis tervezéséhez nyújtott software támogatás valósággal kényszeríti a felhasználót a lépésenkénti finomítás /stepwise refinement/ célszerű ter­ vezési módszerére. Úgy tűnik viszont, hogy ezekért azzal fizet, hogy definiált sémája statikus lesz. Egy már feltöltött adatbázis szerkezetét csak úgy lehet módosítani /reláció oszlopainak változtatása, szemantikus összefüg­ gések változtatása, stb./, ha újradefiniáljuk az egészet, ami uj MODULA/R programot generál és ez - legalábbis úgy gondoljuk, nem találtunk rá utalást - nem képes a régi adatbázison futni, újra kell szervezni azt. 1.2. Lekérdezés, módosítás Az adatdefinició vagy kizárólag az adatbázis adminisztrá­ tor feladata, vagy ha mások is definiálhatnak uj adatokat, az ritkán történik meg, egy "mezei user" nem kell, hogy jól ismerje az adatdefiniciós lehetőségeket. Ezzel szemben

40

a lekérdező, módositó nyelv az, melyen a felhasználók szé­ les köre naponta az adatbázishoz fordul. Lényeges szempont az ilyen nyelvek tervezésénél a felhasználóhoz való alkal­ mazkodás /user friendliness/. Először a két klasszikus nyelvet, a relációkalkulust. é!s a relációalgebrát ismertetjük, majd sorba vesszük az SQL/DS, az INGRES és a QBE rendszereké L, végül külön parag­ rafusban a többieket. A nyelvek bemutatásánál nem törekedhe­ tünk teljességre, csak lehetőségeket és a stilust próbál­ juk érzékeltetni néhány példán keresztül. Valamennyi itt szereplő relációs nyelvnek van egy ki­ emelkedően fontos, a többi adatkezelő nyelvtől megkülönböz­ tető vonása: egy nyelvi utasitás egy vagy több teljes relá­ cióval dolgozik, a műveletek eredménye pedig mindig egy tel­ jes reláció. Ez eltér a relációs modell előtti adatkezelés "egy utasitás egy logikai rekord" elvétől. 1.2.1. Relációkalkulus— ALPHA Az ALPHA az első relációkalkulus /0.1.2/ alapú nyelv. Szerzője Codd mint gazdanyelvbe beépülő adatkezelő nyelvet / sublanguage/ definiál ta

Tronn 71a!},de jellege /egy-egy

utasitás nem sort, hanem teljes relációt dolgoz fel/ igazá­ ból nem olyan. A gazdanyelvre utal viszont a"munkaterület" fogalma: Ezen a területen kommunikál a felhasználó az adat­ bázissal. Itt kapja meg egy-egy lekérdezés eredményét, itt végzi az adatbázis módositását, a beillesztéseket. Persze a munkaterület tulajdonképpen a többi, már egyértelműen önálló relációs nyelvben is teremthető amikor szükség van rá, csak más formában /l.l.l.f, 1.1.2.d, 1.1.3.d/. a/Egyszerü lekérdezés Válasszuk ki azokat a részlegeket, ahol programozók

41

programtervezők dolgoznak! get

w (dolgozö.részlegkód): DOLGOZÓ.BESOROLÁS='PROGRAMOZÓ' V DOLGOZÓ.BESOROLÁS='PROGRAMTERVEZŐ'

A Dolgozó reláció olvasását a GET utasitás végzi, mely aW munkaterületre azoknak a soroknak Részlegkód elemét ad­ ja át, melyre a után álló feltétel teljesül. A műve­ letet nem elég úgy elképzelni, hogy a GET soronként olvas, és a megfelelő sorok részlegkódjait szépen egymás után W-be irja: ugyanis miután mindezt megtette, még kiszűri a duplikátumokat is - összhangban a reláció definíciójával /O.l.l./. Megtehettük volna, hogy a kódokat nagyság szerint rendezve kérjük. Ehhez mindössze az utasitás végére kell biggyeszteni az UP DOLGOZÓ.RÉSZLEGKÓD sort. b / Beépitett függvény Noha a relációkalkulus nem tartalmaz beépitett függ­ vényt, már Codd felismerte ezek szükségességét, és az ALPHA-ba beillesztette őket. Ezek egy reláció sorainak számát, egy oszlopban szereplő különböző értékek számát, egy oszlop összegét, átlagát, minimális, maximális elemé­ nek nagyságát, stb. adják vissza. Hány programozónak van 4000 forintnál nagyobb alapbére? GET W(C0UNT (DOLGOZÓ.TÖRZSSZAm )): DOLGOZÓ.ALAPBÉR> 4000 DOLGOZÓ.BES0R0LÁS='PROGRAMOZÓ'

42

c/ Összetett /több relációt érintő/ lekérdezés Keressük ki minden programozó nevét, alapbérét a részlege címétJ

és

GET PROGRAMOZÁSI_OSZTÁLY (üOLGOZó.NÉV,DOLGOZő.ALAPBÉR RÉSZLEG.CÍM): DOLGOZÓ. RÉSZT,EGKÓD=RÉS ZLEG.RÉSZLEGKŐD DOLGOZÓ.BESOROLÁS='PROGRAMOZÓ' A specifikált adatok most a beszédesebb PROGRAMOZÁSI_OSZTÁLY munkaterületre kerülnek. A két reláció /Dolgozó, Részleg/ közötti kapcsolatot közös adatuk, a Részlegkód teremti meg. A GET minden programozónál megkeresi a megfelelő Részlegkódú Részleg sort /ha a Részlegkód nem azonositó, akkor sorokat/, és abból illeszti hozzá a cimet a dolgozó adatai­ hoz igy állítva elő a kívánt relációs sort /ha a Részleg­ kód nem azonositó, sorokat/. Relációalgebrai nyelven a Részleg és a Dolgozó relációt illesztjük össze, és a DOLGOZÓ.RÉSZLEGKÓD=RÉSZLEG.RÉSZLEGKÓD pusztán azért szerepel, mert az az illesztés feltétele. Keressük ki azokat a dolgozókat, akik alapbére na­ gyobb, mint a főnöküké! RANGE DOLGOZÓ VEZETŐ GET W (DOLGOZÓ.NÉV, VEZETŐ.NÉV) : DOLGOZ Ó.FŐNÖK=VEZETŐ.TÖRZSSZÁM DOLGOZÓ.ALAPEÉR>VEZETŐ.ALAPBÉR Az első utasítás definiálja a Dolgozó reláció sorain értelmezett Vezető változót. Ezt tulajdonképpen úgy képzel­ hetjük el, mint a Dolgozó "reláció" másolatát, vagy mint

43

a Dolgozó sorain futó

cursor-t. A GET utasitás első fel­

tétele nem más, mint a Dolgozó reláció önmagával - illet­ ve Vezető nevű tükörképével való illesztésének feltétele. Minden Dolgozó sorhoz kikeressük a főnöke sorát /nyilván­ valóan az a sor lesz, amelyben a Törzsszám megegyezik a Dolgozó sor Főnök elemével/. Miután ez megvan, ellenőriz­ zük a két sorban, hogy a dolgozó fizetése nagyobb-e mint a főnöké, és ha igen a dolgozó és főnöke neve a munkaterü­ letre kerül. dl Lekérdezés csoportosított adatok szerint

Keressük meg azokat a részlegeket, melyekben 10-nél több programozó dolgozik! A feladatot két lépésben oldjuk meg. Első lépésként kiválogatjuk a Dolgozó relációból a programozók törzs­ számait és részlegkódjait. get

w( d o l g o z ó .t ö r z s s z á m ,d o l g o z ó .r é s z l e g k ö d ) : DOLGOZÓ.BESOROLÁS='PROGRAMOZÓ'

A munkaterületen lévő relációra az ICOUNT csoport­ számláló beépitett függvényt fogjuk használni. Az ICOUNT(r ,A,b) első paramétere az az R reláció, amin használjuk, és működése abból áll, hogy a második paramétereként megadott oszlopnév * \A iminden rögzitett értékére kikeresi j a hozzá tartozó va­ lamennyi különböző B /a reláció egy másik oszlopának neve/ értéket. Az i c o u n t (p r o g r a m o z ó ,r é s z l e g k ó d ,t ö r z s s z á m )

beépitett függvény tehát /ha a Programozó reláció valóban a programozókat tartalmazza/ éppen azt adja vissza amire szük­ ségünk van: az egy részlegben dolgozó programozók számát. Mivel W-ben az előző válogatás eredményeként éppen a prog­ ramozók adatai vannak, igy a

44

RANGE W PROGRAMOZő get

wiC p ROGRAMOzó.r é s z l e g k ó d ) : ICOUNT(PROGRAMOZÓ,RÉSZLEGKÓD,TÖRZSSZÁM)> 1 0

lekérdezés éppen a 10-nél több programozót alkalmazó rész­ legek kódjait /duplikátumok nélkül természetesen!/ helye­ zi el W1 munkaterületen. e / "Az összes“tipusu lekérdezés Keressük meg az olyan szállítókat, akik az 50 kódú részleg által felhasznált összes cikkszámot szállítják! Ismét, két lépésben oldjuk meg a feladatot. Először kiválogatjuk azokat a cikkszámokat, melyeket az 50 kódú részleg használ. GET W(FELHASZNÁLÁS.CIKKSZÁm ) : FELHASZNÁLÁS.RÉSZLEGKÓD=50 Most tehát az olyan szállítókat kell kiirnunk, melyekre az összes W-bol vett cikkszámra létezik olyan Szállítás sor, ahol éppen o a Szállitó. Mivel a relációkalkulns megengedi a kvantorok használatát ez igy irható: RANGE SZÁLLÍTÁS LÉTEZŐ RANGE W MINDEN GET W1(sZÁLLÍTÁS.S ZÁLLÍTÓ) :

V MINDEN 3 LÉTEZŐ:(MINDEN.CIKKSZÁM=LÉTEZŐ.CIKKSZÁM SZÁLLÍTÁS.SZÁLLITÓ=LÉTEZŐ.s z á l l í t ó ) f/ Uj sor illesztése relációba Meglehetősen egyszerűen megy: a megfelelően strukturált W munkaterületen kapnak az egyes sorelemek értéket» majd a PUT utasitás Írja be az uj sort a relációba:

45

W.TÖRZSSZÁM=9286 W .NÉV=/KISS PÁL' W.RÉSZLEGKÓD=52 PUT W (DOLGOZÓ) g/ Lekérdezés eredményének illesztése relációba Illesszük be a "Programozási Osztály" nevű relációba az összes programozó nevét, alapbérét és annak a részleg­ nek a cimét ahol dolgozik! GET W(DOLGOZÓ.NÉV,DOLGOZÓ.ALAPBÉR, RÉSZLEG.CÍM) : DOLGOZÓ.RÉS ZLEGKÓD=RÉSZLEG.RÉSZLEGKÓD DOLGOZÓ.BESOROLÁS='PROGRAMOZÓ' PUT W(DOLGOZÓ) A GET W-ben összegyűjti a kivánt adatokat /Id, c//, a PUT pedig a relációba illeszti őket. h / Egy sor törlése Töröljük az 5618 törzszsámu dolgozót! HOLD W (DOLGOZÓ): DOLGOZÓ.TÖRZSSZÁM=5618 DELETE W A HOLD utasitás ugyanazt csinálja, mint a GET, csak egyben figyelmezteti a rendszert hogy módositás következik /meg­ felel a modern rendszerek "locking"-jának is/. /Mellesleg az, hogy a HOLD-ra szükség van, az a nyelv alkotóinak re­ alizációs elképzeléseiről is árulkodik: ha nem az utasitások szekvenciálisán egymás után következő végrehajtásával mű­ ködik a rendszer nincs szükség HOLD-ra /ld. pl. SQL/DS, 1.2.3./. A DELETE a munkaterületen lévő sorokat törli.

46

i/ Összetett lekérdezés eredményének törlése Töröljük azokat a részlegeket, melyek egyetlen dolgozó sem alkalmaznak! RANGE DOLGOZö D HOLD W(RÉSZLEG) : -i3D :(D .RÉS ZLEGKOD=RÉS ZLEG.RÉS ZLEGKOü) DELETE W j/ Feluj itás Adjunk minden programozónak 10 % béremelést! HOLD W(DOLGOZö): DOLGOZÓ.BESOROLÁS='PROGRAMOZÓ ' ■ ALAPBÉR=1.1 x ALAPBÉR UPDATE W A keresést a HOLD ugyanúgy végzi, mint mindig. Az értéka­ dás az oszlop valamennyi elemére vonatkozik /akár a PL/1 tömbmüvelete/. A felujitás az UPDATE hatására következik be. CDATE 77}

47

1.2.2. Relációalqebra A most ismertetésre kerülő nyelv CDATE 77]-bői szár­ mazik. Nem egyezik meg pontosan semelyik relációalgebrát használó rendszer nyelvével, de az eltérések pusztán szin­ taktikai jellegűek, valamennyi ilyen nyelv ugyanazokat a műveleteket használja, melyek közül a szokásos halmazelmé­ leti műveleteken kivül a projekció, a korlátozás és az il­ lesztés /0.1.2/ bir számunkra jelentőséggel. Codd neveze­ tes eredménye E.CODD 72c'] szerint már ezek a műveletek ga­ rantálják a relációs teljességet /O.I.2./. A relációalgebrában a relációkalkulus "munkaterület"ének nincs pontos megfelelője, viszont egy művelet eredmé­ nyeként előálló reláció a továbbiakban felhasználható, az­ zal további műveletek végezhetők. Megjegyezzük, hogy egy több lépésből álló műveletsor zárójelek alkalmazásával egyetlen, bár több műveletből álló lépéssé .-alakitható. Mi itt az érthetőség érdekében általában több lépésben hajtunk végre mindent . a/ Egyszerű lekérdezés Válasszuk ki azokat a részlegeket, ahol programozók vagy programtervezők dolgoznak! SELECT DOLGOZÓ WHERE BESOROLÁS='PROGRAMOZÓ' UNION SELECT DOLGOZÓ WHERE BESOROLÁS='PROGRAMTERVEZŐ PROJECT T OVER RÉSZLEGKÓD GIVING EREDMÉNY

GIVING T

Az első lépés T relációt állitja elő. Ez két .reláció egye­ sítése. Mind a kettő a Dolgozóból keletkezett, az egyik a programozók, a másik a programtervezők Dolgozóból kiválasz­ tott sorait tartalmazza /korlátozás/. Mivel csak a részle­ gekre /azok kódjaira/ vagyunk kiváncsiak a második lépésben

48

ezt az oszlopot emeljük ki projekcióval az Eredmény relá­ cióvá. Ez a lépés egyben garantálja a duplikátum részleg­ kódok megszűnését is. Az eredmény rendezésére /v.ö. 1.2.1a/ itt nincs lehetőség. b/ Beépített függvény Itt nincs, igy 1.2.1.b kérdését relációalgebrával nem tudjuk megválaszolni. /Egyébként "tiszta", beépített függvények nélküli relációkalkulussal sem tudnánk./ A relációalgebra kiegészítése beépített függvényekkel sok­ kal bonyolultabb, mint a relációkalkulusé. CCODD 71cD c / Összetett /több relációt érintő/ lekérdezés Keressük ki minden programozó nevét, alapbérét részlege címét!

és

SELECT DOLGOZÓ WHERE BESOROLÁS='PROGRAMOZÓ'GIVING PROGRAMOZÓ JOIN PROGRAMOZÓ AND RÉSZLEG OVER RÉSZLEGKÓD GIVING ADATOK PROJECT ADATOK OVER NÉV,ALAPBÉR,CÍM GIVING EREDMÉNY Az első lépés - a korlátozás - kiválogatja a programozókra vonatkozó sorokat, a második mindegyik sor mögé odailleszti a megfelelő Részleg sort /erre a Cim miatt van szükség/, a harmadik kiválasztja a kért adatokat tartalmazó oszlopo­ kat. d / Lekérdezés csoportosított adatok szerint 1.2.1.d-ben megkerestük a lo-nél több programozót foglalkoztató részlegeket. Ezt itt nem tudjuk megtenni, ismét csak a beépített függvények hiánya miatt /nincs

49

lehetőség egy reláció sorainak leszámolására/, e / "Az összes" tipusu lekérdezés Keressük meg az olyan szállítókat, akik az 50 kódú rész­ leg által felhasznált összes cikkszámot szállítják! A kérdés kényelmes megválaszolásához uj relációalgebrai műveletet vezetünk be, az osztást /division/. Ez a művelet egy kétoszlopos relációból /A/ és egy másik oszlopból /B / /egyetlen oszlopból álló relációból/ állit elő, egy egyoszlopos relációt /C/, a következő módon: Legyen az A reláció egy sora /x,y/! Az x elem csak akkor kerül be C-be, ha A minden B-ben előforduló z értékre tartalmazza az /x,z/ párt /feltételeztük, hogy A második oszlopa és B ugyanazon az értékkészleten vannak értelmezve/. Fontosnak tartjuk megjegyezni, hogy a most bevezetett műveletet a 0.1.2.-ben bevezetettekbol előállítható, igy nem jelenti a relációalgebra bővítését. Most pedig a lekérdezés: SELECT FELHASZNÁLÁS WHERE RÉSZLEGKÓD=50 GIVING ADATOK PROJECT ADATOK OVER CIKKSZÁM GIVING CIKKSZÁMOK DIVIDE SZÁLLÍTÁS BY CIKKSZÁMOK GIVING EREDMÉNY A megoldás a szinte épp a feladatra szabott osztással igen egyszerű: az első két lépés előállítja az 50 osztály által felhasznált összes cikkszámot: az első lépés a Felhasználás i adataiból válogatja ki az 50-es osztályra vonatkozókat, a második kiemeli a szükséges oszlopot /a másik oszlopban úgyis csupa 50 szerepelt/. Az osztás-definiciója szerint - éppen a kivánt eredményt adia/még egyszer hangsúlyozzuk levezethetőségét a többi műveltből/.

50

f / Uj sor illesztése relációba DOLGOZÓ UNION {.9286, 'KISS PÁL',52] GIVING DOLGOZÓ Annyi az uj benne, hogy a GIVING rész egy uj reláció helyett agy már meglévőt | tartalmazza, s az Íródik /logikailag/ új­ ra. g/ Lekérdezés eredményének illesztése relációba Illesszük be a "Programozási Osztály" nevű relációba az összes programozó nevét, alapbérét és annak a részlegnek a cimét, ahol dolgozik! a

A c/-ben leírt lekérdezést kell még egy sorral kiegé­ szíteni : PROGRAMOZÁSI-OSZTÁLY UNION EREDMÉNY GIVING PROGRAMOZÁSI„OSZTÁLY h / Egy sor törlése Töröljük az 5618 törzsszámú dolgozót! DOLGOZÓ MINUS {5618,?,?,?,? ,?] GIVING DOLGOZÓ /A MINUS a halmazelméleti különbség./ i / Bonyolult, lekérdezés eredményének törlése Töröljük azokat a részlegeket, melyek egyetlen dolgo­ zót sem foglalkoztatnak! PROJECT DOLGOZÓ OVER RÉSZLEGKÓD GIVING LÉTEZŐ-RÉSZLEG JOIN RÉSZLEG AND LÉTEZŐ-RÉSZLEG OVER RÉSZLEGKÓD GIVING T

51

Az első lépés kiválogatja azoknak a részlegeknek a kódját, amelyben legalább egy dolgozó van. A második ezt az oszlo­ pot illeszti a részleg relációhoz, elérve ezzel, hogy Tben már csupán azok a sorok szerepeljenek, melyek részleg­ kódja a "Létező részleg" relációban benne van. Most rear csak a két - tökéletesen azonos - Részlegkód sor egyikétől kel.] megszabadulni: PROJECT T OVER RÉSZLEG.RÉSZLEGKÓD AND RÉSZLEGNÉV AND CÍM GIVING RÉSZLEG j / Feluj itás 1.2.1.j-ben minden dolgozónak 10 %-os béremelést adtunk. Ez itt nem megy, mert nincsenek aritmetikai kifejezések. Egyébként ÜDATE 773 nyelvén nincs speciális felujitási le­ hetőség, helyette azt emliti, hogy a régi sorok MINUS-szal törölhetők a felujitottak pedig UNION-nal hozzácsatolhatok a relációhoz. CDATE 773 1.2.3. SQL/DS Az SQL vagy SEQEL 2 nyelv természetesen már "igazi" relációs nyelv, működő adatbáziskezelő rendszer része. Az adatdefiniciós lehetőségeit 1.1.1.-ben irtuk le, itt most a lekérdező-módositó részét vizsgáljuk. Megemlítjük még, hogy a lekérdezések - ahogy a következő példákban szerepelnek - eredményei közvetlenül terminálra kerülnek. Ha a felhasználónak más szándékai vannak az eredménnyel l.l.l.e és l.l.l.f-ben tárgyalt lehetőségek állnak a rendelkezésre. a / Egyszerű lekérdezés ,7*l°.soz”v ki 37nVat a részlegeket, ahol programozók

52

vagy programtervezők dolgoznak! SELECT RÉSZLEGKŐD FROM DOLGOZÓ WHERE BESOROLÁS IN 'PROGRAMOZÓPROGRAMTERVEZŐ' Az első sor a kivánt adatot, a másik a kérdezett relációt a harmadik a feltételt specifikálja. Tulajdonképpen 1.2.1.a, "áramvonalasabb" formája, jól olvasható angol mondat. A feltételt Írhattuk volna WHERF BESOROLÁS-'PRCGRAMGZő' GR Be 's OROLÁS= 'PROGRAMTERVEZŐ' formában is. Elérhetjük - az ALPHA-hoz hasonlóan - az ered­ mény rendezettségét is az ORDER BY RÉSZLEGKÓD sor WHERE után biggyesztésével. Ami eltérés az ALPHA-tól - és általában a relációkkal dolgozó nyelvek filozófiájától - az, hogy az eredményből kapott adathalmazból a duplikátumok nincsenek kiszűrve le­ zárt nem is nevezzük az eredményt "reláció"-nak/, vagyis

minden részlegkódot annyiszor kapunk meg, ahány programozó vagy programtervező dolgozik ez illető részlegben. Termé­ szetesen ez elkerülhető, de ezt az igényt külön jelezni kell SELECT UNIQUE RÉS ZLBGKÚD formában a rendszernek. CCHAM 761 ezt avval indokolja, hogy a duplikátumok kiszűrése nagyon költséges művelet /ez nyil­ ván igaz/, és csak akkor érdemes elvéqezni, ha ez valóban szükséges. Meggyőző hiszen sokszor fordul elő, hogy sze­ mantikus meggondolásokból biztosak lehetünk abban, hogy az eredmény nem tartalmaz azonos sorokat. Olyan is előfordulhat,

53

hogy nem baj, sőt esetleg egyenesen kívánatos, hogy a duplikátumok benne maradjanak az eredményben. b / Beépített függvény Hány programozónak van 4000 forintnál nagyobb alapbére? SELECT C0UNT(.x) FROM DOLGOZÓ WHERE ALAPBÉR> 4000 AND BES0R0LÁS='PROGRAMOZÓ' Ez is nagyon hasonlít a megfelelő ALPHA kérdésre /1.2.1.b/. Ami talán magyarázatra szorul az a COUNT^x) kifejezés. A "x" a teljes sort jelzi az összes mezővel COUNT(x) pedig a sorok számát - amire szükségünk van. Az SQL - az ALPHA-hoz hasonlóan /1.2.1.b./ - széleskörű beépített függvénykész­ lettel rendelkezik. c/ Összetett /több relációt érintő/ lekérdezés Kti'2^:vk ki minden programozó nevét, alapbérét, és a részlege cimét! SELECT DOLGOZÓ.NÉV,DOLGOZÓ.ALAPBÉR,RÉSZLEG.CÍM FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.RÉSZLEGKÓD=RÉSZLEG.RÉSZLEGKÓD AND DOLGOZÓ. BES0R0LÁS='PROGRAMOZÓ' Ugyanazok a megjegyzések vonatkoznak erre a lekérdezésre is, mint ALPHA nyelvű megfelelőjére /1.2.1.c/. Keressük ki azokat a dolgozókat, akik alapbére magasabb mint a főnöküké! SELECT D.NÉV,F.NÉV FROM DOLGOZÓ D,DOLGOZÓ F WHERE D. FŐN0K=F .TÖRZSSZÁM AND D .ALAPBÉR > F .ALAPBÉR

54

Összevetve megint az ALPHA-val 11.2.1.c l , jól látható a RANGE áramvonalasitott formája. Jobban olvasható, kényelmesebb, de a lényege ugyanaz: A D és F a Dolgozó reláció két pél­ dánya. Az olyan sorpárokat keressük a két táblában, ahol a D-beli dolgozónál a Főnök mezőben az F-beli dolgozó törzsszáma van /tehát az F sorral reprezentált dolgozó a D sorral reprezentált főnöke/; és a D sorban az alapbér összege nagyobb, mint az F-ben. d/ Lekérdezés csoportositott adatok szerint Keressük meg azokat a részlegeket, melyekben 10-nél több programozó dolgozik! SELECT RÉSZLEGKŐD FROM DOLGOZÓ WHERE BESOROLÁSÉ PROGRAMOZÓ' GROUP BY RÉSZLEGKŐD HAVING COUNT U)> 10 Ez első ránézésre nem hasonlit annyira ALPHA-beli megfele­ lőjére /1.2.1.d/, pedig hasonló a végrehajtás logikája. Először az első három sor szerinti lekérdezés kiválogatja a Dolgozó reláció, programozókra vonatkozó sorait. Utána részlegkód szerint létrejönnek a csoportok, majd a csopor­ tok közötti kiválasztásra vonatkozó HAVING /mögötte mindig a csoport egészét jellemző beépitett függvénynek - COUNT, SUM, AVG, stb. - kell állnia a feltételben/ működik, és kiszűri a 10-nél több sort tartalmazó csoportokat. A GROUP állhat a HAVING csoportszürő feltétel nélkül is. Pl. SELECT RÉSZLEGKÓD, AVG (ALAPBÉR) FROM DOLGOZÓ GROUP BY RÉSZLEGKŐD

55

lekérdezés a részlegek kódját, és az ott dolgozók átlagbé­ rét adja vissza. e / "Az összes" tipusu lekérdezés Keressük meg az olyan szállítókat, akik az 50 kódú részleg által felhasznált összes cikkszámot szállítják! SELECT SZÁLLÍTÓ FROM SZÁLLÍTÁS X WHERE (SELECT CIKKSZÁM FROM SZÁLLÍTÁS WHERE SZÁLLITÓ=X.SZÁLLÍTÓ ) CONTAINS■ (s e l e c t c i k k s z á m FROM FELHASZNÁLÁS WHERE RÉS ZLEGKÓD=50) A lekérdezést a következőképpen lehet "magyarra fordítani": a Szállítás reláció X másodpéldányából válogatjuk ki azokat a szállítókat, amelyekre fennáll az, hogy kiválasztva a Szállitó relációból az összes általuk szállított cikkszámot /ezt a WHERE-t követő SELECT csinálja/ az igy kapott halmaz tartalmazza az 50-es részleg által használt összes cikk­ számot /a CONTAINS utáni SELECT generálta halmaz/. A lekérdezés illusztrálja az SQL relációalgebrai /halmazalgebrai/ lehetőségeit. A SELECT-ek eredményei hal­ maznak tekinthetők, ha halmazelméleti műveleteket /a CONTAINS mellett más egyéb, pl. UNION, MINUS, INTERSECTION is van/ alkalmazunk rájuk. Ez azt is jelenti, hogy a duplikátumok kiszűrése automatikusan megtörténik. Nincs lehetőség az összes relációalgebrai lehetőség ismertetésére

56

- a/-ban láttuk az IN-t - , de szeretnénk hangsúlyozni: az SQL nem tekintehto tisztán relációkalkuluson alapuló nyelv­ nek. /Már csak azért sem mert nincsenek benne kvantorok/. f/ Uj sor illesztése relációba INSERT INTO DOLGOZÓ (t ő RZSSZÁM,NÉV, RÉSZLEGKÓD) : <9286, 'KISS PÁL', 52> g / Lekérdezés eredményének illesztése relációba Illesszük be a "Programozási Osztály" nevű relációba az összes programozó nevét, alapbérét és annak a részlegnek a cimét ahol dolgozik! INSERT INTO PROGRAMOZÁSI OSZTÁLY SELECT DOLGOZÓ.NÉV,DOLGOZÓ.ALAPBÉR,RÉSZLEG.CÍM FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.RÉSZLEGKÓD-KÉSZLEG.RÉSZLEGKÓD AND DOLGOZÓ.BESOROLÁS^'PROGRAMOZÓ' h / Egy sor törlése Töröljük az 5618 törzsszámú dolgozót! DELETE DOLGOZÓ WHERE TÖRZSSZÁM—5610 i / Összetett lekérdezés eredményének törlése Töröljük azokat a részlegeket, melyek egyetlen dol­ gozót sem alkalmaznak! DELETE RÉSZLEG R WHERE (s e l e c t

count

U;

FROM DOLGOZÓ WHERE DOLGOZÓ.r é s z l e g k ó d =r .r é s z l e g k ó d )=0

-

57

-

j / Felujitás Adjunk minden programozónak 10 % béremelést! UPDATE DOLGOZÓ SET A LA PB ÉR=ALAP BÉ R x 1.1 WHERE BESOROLÁS^PROGRAMOZÓ' r ríjT > ** *7c H

1.2.4. INGRES Az INGRES rendszer lekérdező-módositó nyelvét QUEL-nek /QUE^'y Language/ hivják. Az 1.1.2-ben ismertetett adat­ definíciós parancsok nem tartoznak a QUEL-be, önálló "INGRES utility commands"-nak nevezi okét CSTON 761. Az INGRES mint ezt látni fogjuk - inkább nevezhető relációkalkulus alapú nyelvnek, mint az SQL, noha sok kö­ zös vonásuk van, lényegében csak kulcsszavak, és a bonyo­ lultabb lehetőségek - beépitett függvények, halmazművele­ tek, stb. - különböznek. Az alább következő lekérdezések eredménye itt is rögtön terminálra kerül - ha másként kivánja a felhasználó, úgy 1.1.2.d lehetősége áll rendelkezésére. a/ Egyszerű lekérdezés Válasszuk ki azokat a részlegeket, ahol programozók vagy programtervezek dolgoznak! RANGE OF D IS DOLGOZÓ r e t r i e v e (d .r é s z l e g k ó d ) WHERE D.BESOROLÁS='PROGRAMOZÓ' OR D. BESOROLÁS='PROGRAMTERVEZŐ’ ' A RANGE ugyanaz, mint az ALPHA-ban /1.2.1.c/, de itt ha re­ lációval akar dolgozni az ember, minden esetben meg kell

58

acjni rajta egy változót/ a reláció nevére nein lehet hivat kozni, mint ezt a megfelelő ALPHA és SQL lekérdezések /1.2.1-a és 1.2.3.a/teszik. Az SQL "IN" lehetősége /l.2.3.a/itt nincs meg. Az INGRES a duplikátumokat másképpen kezeli, mint az eddig vizsgált rendszerek. Egy terminálra Írandó lekérde­ zés eredményéből sosem szűri ki őket, és erre nincs is nyelvi lehetőség. Viszont, ha a lekérdezés eredményét egy uj re­ lációba irányítjuk /1.1.2. d/t akkor a duplikátumok kiszűrése automatikusan megtörténik /sőt le is rendezi az uj relációt/. b / Beépített függvény Hány programozónak van 4000 forintnál nagyobb alapbére? RANGE OF D IS DOLGOZÖ RETRIEVE (COUNT (d .ALL)) WHERE D.BES0R0LÁS='PROGRAMOZÓ' AND D.ALAPBÉR> 4000 Lényegében megegyezik az SQL-beli megfelőjével /1.2.3.b/. Az ALL az egész sort jelöli, a COUNT a szokásos számláló függvény. Az INGRES—nek is megvannak a szokásos beépített függvényei. c/ Összetett /több relációt érintő/ lekérdezés Keressük ki minden programozó nevét, alapbérét és a részlege címét! RANGE OF D IS DOLGOZÓ RANGE OF R IS RÉSZLEG RETRIEVE (d .NÉV, D. ALAPBÉR, R. CÍM) WHERE D. RÉSZLEGKÓD=R. RÉSZLEGKÓD AND D.BESOROLÁS Keressük ki azokat á dolgozókat, akiknek alapbére na­ gyobb, mint a főnöküké!

59

RANGE OF D IS DOLGOZÓ RANGE OF F IS DOLGOZÓ RETRIEVE (D.NÉVrF.NÉv) WHERE D .FÖNÖK=F.TÖRZSSZÁM AND D.ALAPBÉR > F.ALAPBÉR d / Lekérdezés csoportosított adatok szerint Keressük meg azokat a részlegeket, melyekben lo-nél több programozó dolgozik! RANGE OF D IS DOLGOZÓ retrieve

(d .r é s z l e g k ó d )

WHERE COUNT(d .ALL By D.ÜÉSZLEGKÓD WHERE D.BESOROLÁSÉ PROGRAMOZÓ)> ÍO A COUNT beépített függvényben lévő két konstrukció közül a BY... végzi a csoportositást, a WHERE... pedig a programozók kiválogatását /nem szükségképpen ebben a sor­ rendben, és nem is biztos, hogy külön lépésben zajlanak ezek a műveletek/. A COUNT az igy kapott csoportok tagja­ it számlálja. A BY-nak az INGRES-ben értelme csak beépített függvény /lehet más is, nem csak a COUNT/ belsejében van. A WHERE feltétele kivehető a beépített függvényből, de ezzel a le­ kérdezés értelme megváltozik. A RANGE OF D IS DOLGOZÓ r e t r i e v e (d .r é s z l e g k ó d ) WHERE COUNT (ü.ALL BY RÉSZLEGKÓD)> 10 D.BESOROLÁSÉPROGRAMOZÓ'

AND

lekérdezés azt csinálja, hogy végigmegy a dolgozókon, és ha egy programozót talál, akkor leszámolja a részlege összes dolgozóját, és ha ezek száma 10-nél nagyobb, akkor

60

kiirja a részlegkódot. A lekérdezés eredménye tehát a 10-nél nagyobb létszámú, legalább egy programozót alkalmazó részle­ gek kódjai lesznek - mindegyik annyiszor kiirva ahány progra­ mozójuk van. Elég nyilvánvaló, hogy az INGRES BY lehetősége és az SQL GROUP BY-a egymás meqfeleloi, és mindkettő őse az ALPHA ICOUNT / ISUM,IAVG stb./ beépitett függvénye /1.2.1.d./, noha annál jobbak. e/ "Az összes"tipucu lekérdezés Keressük meg az olyan szállítókat, akik az 50 kódú rész­ leg által felhasznált összes cikkszámot szállítják! A választ éppen úgy, mint az ALPHA-nál /1.2.1.e./ két lépéssel kapjuk meg. Először előállítjuk egy önálló reláció­ ban - ezt persze előbb létre kell hozni /ld. 1.1.2.d/ az 50-es részleg által felhasznált összes cikkszámot: RANGE OF F IS FELHASZNÁLÁS RETRIEVE INTO CIKKSZÁMOK (f .CIKKSZÁIl) WHERE F .RÉS ZLEGKÓD=50 A következő lépésben kapjuk az eredményt: RANGE OF S IS SZÁLLÍTÁS RANGE OF SX IS SZÁLLÍTÁS RANGE OF C IS CIKKSZÁMOK RETRIEVE (S.SZÁLLÍTÓ) WHERE COUNT (c.CIKKSZÁM WHERE C .CIKKS ZÁM=SX.CIKKS ZÁM AND SX.SZÁLLITÓ=S.SZÁLLÍTÓ)= COUNT (C .CIKKSZÁm ) A lekérdezés logikája szerint azokat az S sor-beli szállítókat Írjuk ki, melyekre fennáll a következő: azoknak a C-be tarto­ zó cikkszámoknak a szama, melyekre létezik olyan

SX

sor,

61

amely sorban a szállitó éppen az S szállítója, a cikkszám pe­ dig a C-beli cikkszám /vagyis S.szállitó szállítja.C.cikkszá­ mot/ megegyezik a C-be tartozó összes cikkszám számával. Meg­ jegyezzük, hogy az eredményben minden szállitókód annyiszor szerepel, ahány különböző sorban fordul elő a Szállítás re­ lációban . A lekérdezés logikája megegyezik az ALPHA megfelelő le­ kérdezésének /1.2.1.e./ logikájával. A különbség az, hogy az INGRES nem használ kvantorokat, ugyanis nincs rájuk szükség. Az egzisztenciális kvantor /3/ implicite minden feltételben hpnno van: igy definiált a lekérdezés szemantikája. Az uni­ verzális kvantor /V / pótolható pl. a COUNT beépített függ­ vénnyel; a\/x p Cx ) predikátum ekvivalens a COUNt (-i p (x))= 0val

CDATE 77]. Ennél a lekérdezésnél szembeötloek az INGRES és az SQL /1.2.3.e/ közötti különbségek. Lényegében itt az INGRES erő­ sebb relációkalkulus-orientáltságáról van szó, az SQL reláció­ algebrai logikája /a CONTAINS/ nincs meg benne, igy bizonyos dolgokat körülményesebb QUEL-ben leirni. Az SQL logikája di­ rekt: egy-egy SELECT előállítja a két halmazt /egy-egy szál­ litó által szállított cikkszámokét, ill. az 50-es osztály által felhasznált cikkszámokét/ és a CONTAINS összehason­ lítja őket. f/ Uj sor illesztése relációba APPEND TO DOLGOZÓ (t ÖRZSSZÁM=9826,NÉV='KISS PÁL', RÉSZLEGKÓD=52) g / Lekérdezés eredményének illesztése relációba Illesszük be a "Programozási Osztály" nevű relációba az összes programozó nevét, alapbérét és annak a részlegnek a cimét

62

ahol dolgozik! RANGE OF D IS DOLGOZ0 RANGE OF R IS RÉSZLEG APPEND TO PROGRAMOZÁSI OSZTÁLy (n ÉV =D.NÉV, ALAPBÉR=D.ALAPBÉR,RÉS ZLEGKÖD=R.RÉSZLEGKÓü) WHERE D. RÉSZLEGKÓD=K. KÉSZIjEGKÓl) AND D. BESOROLÁS=/PROGRAMOZÓ' h / Egy sor törlése Töröljük az 5618 törzsszámú dolgozót! RANGE OF D IS DOLGOZÓ DELETE D WHERE D.TÖRZSSZÁM=5618 i/ Összetett lekérdezés eredményének törlése Töröljük azokat a részlegeket, melyek egyetlen dolgozót sem alkalmaznak! RANGE OF R IS RÉSZLEG RANGE OF D IS DOLGOZÓ DELETE R WHERE COUNT(d .ALL WHERE D. RÉSZLEGKÓD=R.RÉSZLEGKÓD) =0 j/ Feluj itás RANGE OF D IS DOLGOZÓ REPLACE D (ALAPBÉR=1.lxALAPBÉR) WHERE D. BESOROLÁS='PROGRAMOZÓ' CSTON 76, EPST 771-

63

1.2.5. QBE

I

Mint erről 1.1.3-ban már beszámoltunk, a QBE grafikus nyelv, a felhasználó a rendszer által képernyőre irt táblá­ zatokba "full-screen" módban a megfelelő helyekre szöveger két irva tartja a kapcsolatot a rendszerrel. Alapgondolata, hogy mindent példákon keresztül ért meg a rendszer. A fel­ használó beir a táblázat egy-két sorába egy megoldást -"igy néz ki egy olyan sor, amilyenre szükségem van"- és a QBE kikeresi az adatbázisból az összes "olyan"sort. a/ Egyszerű lekérdezés Válasszuk ki azokat a részlegeket, ahol programozók vagy programtervezők dolgoznak!

DOLGOZÓ

TÖRZSSZAM

NÉV

RÉSZLEGKÓD

BESOROLÁS

P. EGY

PROGRAMOZÓ PROGRAM-

P . KETTŐ

FŐNÖK

ALAPBÉR

TERVEZŐ

Az aláhúzott EGY és KETTŐ a változók, vagy mintaelemek. Az aláhuzatlan szövegek konstansok. Milyen legyen a kivánt lista? Két mintasor van megadva, mind a két sor jó. A két sor kitöltetlen oszlopaiban lévő értékek a lekérdezés szem­ pontjából közömbösek. A Részlegkódban lévő értékeket kell kiirni - e n e utal a P. - de csak a mintának megfelelő sorok­ ból, tehát azokból ahol a Besorolás programozó /első sor/ vagy programtervező /második sor/. A rendszer a duplikátumokat automatikusan kiszűri. Rendezés

64

megadható ha P. helyett P. AO. /Print Ascending Order./ sze­ repel . b / Beépített függvény Hány programozónak van 4000 R-ot meghaladó alapbére? DOLGOZÓ

TÖRZSSZÁM

NÉV

RÉSZLEGKÓD

BESOROLÁS

FŐNÖK ALAPBÉR

-

PROGRAMOZÓ

P.CNT.ALL

>4000

A mintasorból jól látni, hogy milyen sorokat kell a rendszernek kiválogatni az adatbázisból: a Besorolás prog­ ramozó, az Alapbér pedig 4000-nél nagyobb. Az egész sort jelképező dolgozó oszlopban van a kiiratást jelző "P". A mögötte álló CNT, a számláló /eddigiekben COUNT/ beépí­ tett függvény. Az ALL kaxinaz képzése^. jelenti /du.piikatu~ mok kiszűrése nélkül/, a CNT. ALL tehát a halmaz számos­ ságát jelzi - ezt kell kiirni. SQL/DS-ben a "SET"/.

/Az ALL. megfelelője az

c / Összetett /több relációt érintő/ lekérdezés Keressük ki minden programozó nevét, alapbérét

és a

részlege cimét!

DOLGOZÓ TÖRZSSZÁM

NÉV

RÉSZT,FGVÓn

XXX

NI

BESOROLÁS

PROGRAMOZÓ

FŐNÖK ALAPBÉR

Y

65

RÉSZLEG

RÉSZLEGKÓD

RÉSZLEGNÉV

NI

VALAMI

IZÉ P. XXX

CIM AB

MINDEGY P. Y.

Q P. AB

A lekérdezéshez három tábla szükséges. A Dolgozó oszlopaiban meg­ adjuk, hogy csak a programozók érdekelnek, és mintaértékeket Írunk a Név, Részlegkód, Cim oszlopokba, vagyis ezeknek az értékeit kívánjuk használni. A Részleg tábla Részlegkód mező­ jében ugyanaz a mintaérték /NI/ áll, mint a Dolgozóéban egy konkrét Dolgozó sorhoz tehát azt a Részleget kell megta­ lálni, ahol a Részlegkód a Dolgozóéval egyezik /de csinálhat­ ja a rendszer fordítva is, a részlegekhez keresve a dolgozó­ kat, az illesztés feltétele akkor is változatlan/. A Részleg relációra a Cim miatt van szükségünk, mint azt a mintaérték /AB/ jelzi. A harmadik tábla csak a listázás miatt kell, mint azt azt oszlopnevek is jelzi}:. Ebben kapjuk majd meg az ered­ ményt. Ha a harmadik tábla nem lenne, és a Dolgozó, ill. Rész­ leg táblában P .XXX-et, P.Y-t ill. P .AB-t adunk meg, akkor két, egymástól független listát kapunk: egyiken a programozók nevei és alapbérei, másikon a részlegeik kódjai szerepelnek majd, de ezeket összeilleszteni - a duplikátumok kiszűrése miatt - nem lehetne. Keressük ki azokat a dolgozókat, akik alapbére több, mint a főnöküké! Nagyon elegánsan, egy táblával megoldható:

66

DOLGOZÓ TÖRZSSZÁM

NÉV

D

RÉSZLEGKÓD

BESOROLÁS

ALAPBÉR

FŐNŐK

P. P.

SOK >S0K

D

1^4 a főnöké/ az glnó ^ Az ób; to kot se: beosztotté. Ezt a viszonyt a felső sor Törzsszám és az alsó sor Főnök mezőjében álló azonos érték /D/ jelzi. A főnök alapbére SOK /valamennyi/ a beosztotté > SOK /nagyobb, mint valamennyi/. A két név írandó k i . -L

i

d/ Lekérdezés

csoportositott adatok szerint

Keressük meg azokat a részlegeket, ahol 10-nél több programozó dolgozik!

DOLGOZÓ

TÖRZSSZÁM All SÍ

NÉV

— KUSZtUtOAUL) P. R

—

tíliSUROLÁS

FŐNÖK

AiiAPBÉR :

PROGRAMOZÓ

CONDITIONS CNT.ALL.S1> 1 0 I A megoldáshoz egy speciális QBE eszközt, a feltétel-dobozt /condition-bok/ is igénybe kell venni. A Dolgozó táblázat­ ból kiderül, hogy a programozókat kell kiválogatni,

f

.k a

Részlegkódban azt tudatja, hogy csoportosítani kell a Részlegkód szerint a sorokat és a megfelelő részlegkódok kiirandók. A kiíratás feltétele a feltétel-dobozban van

67

megadva - az egy csoportba tartozó törzsszámok halmazának /ALL.SÍ/ tagszáma 10-nél nagyobb kell hogy legyen. e / "Az összes tipusu lekérdezés Keressük meg az olyan szállítókat, akik az 50 kódú részleg által felhasznált összes cikkszámot szállítják!

FELHASZNÁLÁS RÉSZLEGKÓD

50

SZÁLLÍTÁS

szállító

P.S

CIKKSZÁM

ALL.CIKK

CIKKSZÁM "ALL.CIKK X

A megoldás lényegében az SQL/DS "CONTAINS" lehetőségének /1.2.3.e./ grafikus megfelelője. A Felhasználás táblában az 50-es részleg által felhasznált összes cikkszámot jel­ képezi az Aul..CIKK. A Szállítás tábla jelzi, hogy Szállitó szerint csoportosítva a cikkszámokat, azokat a szállítókat kell kiirni, ahol a kapott cikkszámhalmaz megegyezik ALL.CIKK-kel, ill. még további elemet is tartalmazhat /x/. A QBE logikájában igen hasonlit az SQL/DS-hez, szinte annak grafikus megfelelője, erősségben sem marad el tőle, ugyanúgy tartalmaz relációkalkulus és algebra jellegű le­ hetőségeket, mint az. f/ Uj sor illesztése relációba

68

DOLGOZÓ TÖRZSSZÁM I.

9826

NÉV

RÉSZLEGKÓD

KISS PÁL

BESOROLÁS

FŐNÖK ALAPBÉR

52

A Dolgozó oszlopban álló I. miatt kerül be a fenti /hiányo­ san megadott/ sor a Dolgozó táblába. g / Lekérdezés eredményének illesztése relációba Illesszük be a "Programozási Osztály" nevű relációba az összes programozó nevét, alapbérét, és annak a részleg­ nek a cimét, ahol dolgozik!

DOLGOZÓ TÖRZSSZÁM

NÉV

BESOROLÁS

RÉSZLEGKÓD NI

XXX

FŐNÖK ALAPBÉR

PROGRAMOZÓ

Y

i

RÉSZLEG

RÉSZLEGKÓD

RÉSZLEGNÉV

NI

PROGRAMOZÁSI_OS ZTÁLY I.

CÍM rixo

NÉV XXX

ALAPBÉR Y

I 1

CÍM AB

Teljesen úgy megy, mint a c/-ben tárgyalt lekérdezés, csak az eredményül kapott reláció /ezelőtt valamikor definiál­ nunk is kellett, hogy ez a beillesztés menjen/ és a kiirást jelző P. helyett ezúttal az eaész sorra vonatkozó, beillesz­ tést jelző I. áll.

69

h/ Egy sor törlése Töröljük az 5618 törzsszámú dolgozót DOLGOZÓ

TÖRZSSZÁM

D.

NÉV

RÉSZLEGKÓD

BESOROLÁS

FŐNŐK ALAPBÉR

5618 i / összetett lekérdezés eredményének törlése

Töröljük azokat a részlegeket, melyek egyetlen dolgozót sem alkalmaznak!

RÉSZLEG

RÉSZLEGKÓD

D.

RÉSZLEGNÉV

CÍM

Rl

DOLGOZÓ

TÖRZSSZÁM

NÉV

n

RÉSZLEGKÓD

BESOROLÁS

FŐNÖK

ALAPBÉR

Rl

A rendszer végigmegy a Részleg táblán, és megpróbálja tö­ rölni sorban az összes sort. A Dolgozó tábla kitöltése mi­ att ezt azonban csupán azoknál a soroknál teszi meg, ahol a Részlegkód /Rl/ a Dolgozó tábla egyetlen sorában sem for­ dul elő. j / Feluj itás Adjunk minden programozónak 10 % béremelést! DOLGOZÓ

TÖRZSSZÁM

NÉV

RÉSZLEGKÓD

BESOROLÁS

FŐNÖK

ALAPBÉR l.lxSl

U. PROGRAMOZÓ

SÍ -

CZLOO 771.

70

1.2.6. Egyéb rendszerek A rendszereket a felhasználói interface vizsgálata két csoportra osztja; az egyikbe a relációsán teljes /O.I.2./ rendszerek tartoznak, a másikba azok, melyek nem rendel-r kezmk ezzel a tulajdonsággal. Utóbbiaknál ez a gyakorlat­ ban az illesztés hiányában mutatkozik meg, ami viszont azt jelenti, hogy a felhasználó egy kérdéssel csak egy relá­ cióra kérdezhet rá. A felhasználói interface döntő jelen­ tőségű jellemzőjének tartjuk a relációs teljességet. /Ér­ dekes kompromisszum ebből a szempontból a dBASE II_, for­ galmazott adatbáziskezelő rendszer. Ebben létezik ugyan illesztés /JOIN/, de javasolja annak mértékletes használa­ tát, mert nagy file-okra időigényes CASHT 8ll./ A nem relációsán teljes rendszereket az [’EBER 83} dolgozatban leirt, 1.1.4.-ben emlitett rendszer példáján mutatjuk be. A felhasználói interface kellemes kérdez-felelek játékból áll, melynek során először a lekérdezendő re­ lációt, annak kiirandó oszlopait, majd a lekérdezés fel­ tételeit lehet megadni. Lehetőség van rendezés kérésére is. Az adatmódositások hasonlóan zajlanak. A relációs rendszerek általában az 1.2.1.-1.2.5.-ben ismertetett "nagy" nyelvek valamelyikét használják - többé kevésbé átalakítva. E szerint csoportosítottuk mi is a rendszereket. A relációalgebrát használó rendszerek őse a PRTV /ld. 0.2/ volt. Az INGRES-ről és a SEQUEL-ről szóló első publikációk /[STON 76 , ASTR 751/ után a relációalgebrát kényelmesebben olvasható, és kevésbé procedurális nyelvek váltották fel. A relációalgebra szemmel láthatóan a mikrogépeken indul uj virágzásnak. Úgy gondoljuk, ennek első­ sorban a könnyebb implementálhatóság az oka /ezt a fel­ tevést CDEEN 83l explicite megerősíti/.

71

Az RQL

műveletei

tás/ és a projekció.

az illesztés,

Az

/pl.

SUM-oszlop összege/,

l á t o z á s t á l t a l á n o s í t o t t á k több, feltétel irányába.

a kor­

és

Boole művelettel összekap­

M i v e l az a l g e b r a p r o c e d u r á l i s

legű - e g y - e g y l e k é r d e z é s - és

/k i v á l a s z ­

algebrai műveleteket kiegészítették

v'~Ay !*.„4-4- f ü g g v é n y e k k e l

csolt

korlátozás

t öbb l é p é s b ő l á l l h a t

/ld.

jel­

1.2.2./

a g épén e g y - e g y l épés v á l a s z i d e j e elég h o s s z ú lehet,

a tapasztalatok szerint batch

i p e r c és 1 óra k ö z ö t t i

l e h e t ő s é g e t is b i z t o s í t o t t a k

"USE OF"

-

idő k vauinak

a felhasználónak. A

parancs h a t á s á r a a r e n d s z e r az utasításokat a p a ­

rancsban megadott nevű mellett ülni

f i l e - r ó l várja,

v á r v a az a k t u á l i s

és n e m k e l l a gép

lépés v é g r e h a j t á s á r a ,

a k ö v e t k e z ő t be l e h e s s e n gépelni. Cm AS T 83l Az _ M R D B S _

a korlátozást,

az i l l e s z t é s t h asználja.

hogy

/ld, m é g 1.1.4./

projekciót,

p e r m u t á c i ó t és

Természetesen a halmazelméleti m ű ­

v e l e t e k e t is im p l e m e n t á l j a .

A szerzők szerint ezzel a rend­

s z e r r e l is v a n n a k h a t é k o n y s á g i p r o b l é m á k - f ő k é n t t e r m é s z e ­ t e s e n az illesztéssel. £ R E V E 83} Az

INGRES Q U E L - j é t i m p l e m e n t á l t a az R ~ D B M S

Ez I N T E G R A - 1001 g é p e n

fut,

n e m m i k r o g é p , 1 m e r t a r e n d s z e r e gyes m o d u l j a i g o t is elérik.

Az a l k o t ó k

rendszer.

a m i r ő l azt b i z t o s a n tudjuk,

hogy

a 220K nagysá­

szerint megfelelő overlay-esités-

sel 16 bites m i k r o p r o c e s s z o r o k r a is a l k a l m a s s á

lehetne ten­

ni a rendszert. Érdekes

továbbfejlesztés

zív lekérdezés. ható.

Ez

"alkatrész

az I N G R E S - h e z k é p e s t a r e k u r ­ tipusu"

relációknál használ­

Ha van egy a l k a t r é s z e k b ő l ö s s z e á l l í t o t t s zerkezet,

a m e l y n e k a l k a t r é s z e i m a g u k is ö s s z e t e t t s z e r k e z e t e k és igy tovább, d e z ések,

akkor a rélációs nyelvek nem képesek olyan lekér­ m i n t pl.

"Keressük meg X gép elemi

t o v á b b n e m bon t h a t ó / lációs

nyelven,

/alkatrészekre

alkatrészeit!" megválaszolására.

/Re­

itt a r e l á c i ó t r a n z i t í v l e z á r á s á n a k le­

k é r d e z é s é r ő l v a n szó/. CAPS!

83*1

72

Az S Q L - s z e r ű n y e l v e k e t h a s z n á l ó r e n d s z e r e k k ö z ü l az 1 . 1 . 4 -ben m á r e m l í t e t t V I D E B A S

r e n d s z e r t e m e l j ü k ki.

az S Q L b o n y o l u l t a b b l e h e t ő s é g e i t előírása,

stb./

is t u d j a . £ B L A N

/pl.

G R O U P BY,

32K-s

/1/ H P 2 l M X - e n

o p e r á c i ó s r e n d s z e r alatt. Ehhez

rendszer.

fut - e r ő s e n s z e g m e n t á l v a ,

m i n d i g csak e g y k i s p r o g r a m r é s z

n e m ismerünk/.

rendezés

83l

A Q B E g r a f i k u s n y e l v é t h a s z n á l j a az R D B A S Ez

egyszerre

t a r t ó z k o d i k a m e m ó r i á b a n - RTE

/ H a t é k o n y s á g á r a v o n a t k o z ó ada t o t

a rendszerhez

parancsfile lehetőség.

Ez

is l é t e z i k ü g y e s

batch

A felhasználó a szokásos módon

definiálja a műveletet,

m a j d ö n á l l ó n e v e t a d neki,

r e n d s z e r az a z o n n a l i v é g r e h a j t á s h e l y e t t a n e v e t és a m ű v e l e t e t .

Ezek

/I.2.5./

és a

csupán megjegyzi

a f e l h a s z n á l ó i p a r a n c s o k pa-

r a m e t r i z á l h a t ó a k , és m é g a p a r a m é t e r e k m e g a d á s á r a f e l s z ó ­ lító ü z e n e t e k

is k ü l ö n m e g a d h a t ó k a p a r a n c s

definiálásakor.

C HERM 83l A T I T A N UCSD-PASCAL-»ban készült. fut.

Uj

lehetőség benne

M i n d a két

feltöltése

lemezfile-ról

823

teljes,

tehát a QBE-nek legalábbis

részét k é p e s e k m e g v a l ó s i t a n i . A b o n y o l u l t a b b

hetőségekre

/1.2.5.d,e/

adatbázis-problémák mellett még

bonyolultabb grafikus A LIDAS

első rá­

/Hierarchical

lekérdező nyelve

technikát használ,

a szövegesnél

i n t e r f a c e - t is m e g k e l l c s i n á l n i . /

rendszer HÍQUEL

Query Language/

ban,

le­

a QBE l á t s z i k a l e g n e h e z e b b e n m e g v a l ó s i t h a t ó n a k

/a s z o k á s o s

QBE-t ő l .

je­

vonatkozó utalást nem találtunk,

a z é r t e lég m e g l e p ő n e k t ű n n e k az i m p l e m e n t á c i ó k , nézésre

Írási

rendszer - a közleményekben látható példák

szerint-relációsan lentős

Il-n 5 4 K - b a n

- a QBE-hez képest - reláció

lehetősége l e m e z f i l e - b a , illetve /v .ö . 1 . 1 . 2 . b /. E F A L Q

APPLE

Interactive

is Q B E - s z e r ü g r a f i k u s

de ez a n y e l v l é n y e g e s e n k ü l ö n b ö z i k a

M á r az e g y r e l á c i ó s

a feltételek megadásánál

lekérdezések megfogalmazásá­ jelentkezik különbség,

de

de

73

lényegi eltérés az összetett lekérdezéseknél van. A HIQUEL hierarchikus struktúrák definiálására ad„lehetőséget ter­ mészetes nyelvű kapcsolatok segítségével. Egy könyvtári adatbázisban pl. A "Persons" és a "Borrowed-items" relá­ ciók "hierarchikus nézőponttá" /semmi köze az SQL/DS "né-, zopont"-jához/ kapcsolhatók össze a "borrowed items OF A person" kapcsolattal. Az ábrán látható lekérdezés ered­ ménye Miller vagy Smith urak által kölcsönzött könyvek jegyzéke lesz

PERSONS NAME

BORROWED-ITEMS OF A PERSON TITLE

MILLER SMITH

[REBS 83, URSP 83] A mikrogépes rendszereknél váltak elterjedtté az adat­ szerkesztők /data base editor/. Ezek a szövegszerkesztők­ höz /text editor/ hasonló stílusban Írják képernyőre és engedik módosítani egy reláció sorait. Adatszerkesztő le­ hetőség van pl. az MRDSA ^MERR 83] és a dBASE^ I_I_ Ia SHT 8l] rendszerekben. Az előbbi a szerkesztő mellett még PASCAL ru­ tinokból hívható relációalgebrai nyelvvel is rendelkezik méghozzá általánossal, olyan extra lehetőségekkel, mint a többfajta definiálatlan értéknek megfelelő különböző illesz­ tések. Külön említjük az APPLE

/Access Path Producing LanguagE/

nyelvet. Ez az RSXll-M operációs rendszer PDP 11-en létező DATARETRIEVE utility-jának általánosítása. Jellegzetessége, hogy a felhasználónak még a relációkat sem kell megadnia, mindössze az adatok nevét. Az 1.2.1.c.-1.2.5.c lekérdezés

74

/a programozók neve, alapbére és részlegük cime itt igy irható/: SELECT NÉV,ALAPBÉR,CÍM WHERE BEOSZTÁS='PROGRAMOZÓ' A rendszer maga találja meg a relációkat, melyben a hivat­ kozott oszlopnevek vannak, és kapcsolja őket össze közös oszlopnevek alapján. Ha több lehetséges összekapcsolás van, a felhasználó választ közülük. Ez igy nagyon egyszerű és elegáns, de a módszer elég rugalmatlan, hiszen csak a közös névvel rendelkező oszlopok szerint illeszthetők relációk. Ez igen komoly korlátozás, és a nyelv nyilvánvalóan nem relációsán teljes. £PATN 83l A batch lehetőség továbbfejlesztésével találkozunk a dBASS.J.1 rendszernél. Itt a parancsfile-ban nem csak adat­ bázis utasitások nevei, hanem programozási nyelv-szerű vezérlőutasitások /DO WHILE, GO TO,stb./ is lehetnek. Egyegy ilyen parancsfile szabályos program, végrehajtandó adatbázis és programnyelv-szerű vezérlő utasításokkal. Mindez nem ugyanaz, mint egy programozási nyelvbe beépülő adatkezelő nyelv, itt ugyanis nincs lehetőség pl. egy le­ kérdezési eredményből programozási nyelvű feldolgozással statisztika készítésére. £ASHT síi 1.3. Adatbáziskezelés programozási nyelvekből Az eddigiekben megvizsgáltunk néhány relációs adatke­ zelő nyelvet. Ennek alapján nyugodtan állíthatjuk, hogy valamennyi sokkal egyszerűbb, mint egy programozási nyelv, és emellett elég bonyolult megfogalmazású kérdésekre is képes választ adni. Mégis úgy tűnik, hogy szükség van a hagyományosabb módszerre, a programozási nyelvekből vé­ gezhető adatkezelésre is. A vizsgált nyelvek egyike sem rendelkezik ugyanis egy programozási nyelv számoló, vezérlő

75

utasításainak erejével /ha rendelkezne, maga is programo­ zási nyelvvé válna,és elvesztené fő vonzerejét - egyszerű­ ségét/. Az önálló nyelvek nem alkalmasak pl. statisztikák készítésére, és nem irhatok le bennük olyan bonyolult lo­ gikájú felújítások, mint pl. egy bérszámfejtés. A magasszintü nyelvekből való adatkezelés sokféle mó­ don megvalósítható, pl. az MRDSA-ban alkalmazott rutinhivástól a MODULA/R saját fordítóprogrammal implementált be­ ágyazott adatkezelő utasításáig. Először ismertetjük az SQL/DS és az INGRES PL/1 és C gazdanyelvü adatkezelő inter face-ét, majd megvizsgáljuk programozási-adatkezelő nyel­ veket. 1.3.1. Gazdanyelvek és adatnyelvek Az INGRES és az SQL/DS rendszerek lehetőségeit fogjuk röviden ismertetni. Mind a két rendszer univerzálisan re­ lációs /Id. 1./, vagyis a programozási nyelvbe beépülő adatkezelő nyelv mind a kettőnél megegyezik az önálló adat kezelő nyelvvel, a QUEL-lel ill. az SQL-lel. Mind a kettő­ nél előforditót /preprocessor/ alkalmaznak. Ez az adatke­ zelő utasításokat a gazdanyelv CALL utasításaira alakitja /megfelelő paraméterekkel/, és a gazdanyelv fordítóprog­ ramja már gazdanyelvü programot kap. Az INGRES-ben a C programozási nyelvet a beépülő QUEL lel EQUEL-nek /Embedded QUEL/ nevezik, i Az EQUEL-t a kö­ vetkező szabályok definiálják: a/ Minden C nyelvű utasitás EQUEL nyelvű utasitás /va gyis az EQUEL programban bármilyen C utasitás szerepelhet/ b/ Minden QUEL utasitás EQUEL nyelvű utasitás /tehát az EQUEL a QUEL teljes kifejezőerejével bir/. A QUEL uta­ sításokat az utasitás előtt álló " # " jelzi.

76

cl A QUEL utasításokban mindenhol szerepelhetnek C

változók, de ezek deklarációját is " #- # előzni .

"-nek kell meg­

d/ Mig a RETRIEVE utasitás /1.2.4./ a QUEL-ben egész relációkkal dolgozik, az EQUEL-ben egy hivásra csak egy sort ad vissza. Egymás utáni hivásai soronként mennek végig azon a reláción, amit a megfelelő QUEL hivás egyszerre adna viszsza. Ennek szintaktikája: RETRIEVE /változólista/ WHERE /feltételek/

C-blokk A C-blokk minden RETRIEVE után egyszer hajtódik végre. Ez végzi az aktuális sor feldolgozását. a/ írjuk ki néhány dolgozó nevét és alapbérét! A ki­ írandó dolgozók törzsszámait a C program olvassa be. main( ) í # # char NÉV[2o] ; # # c h a r TÖRZSÉ-]; # # int ALAP; while (READ (TÖRZS)) í # # RANGE OF D IS DOLGOZÓ' # # RETRIEVE NÉV=D.NÉV,ALAP=D.ALAPBÉR # fr WHERE D .TÖRZSS ZÁM=TŐRZS

PRINT NÉV," FIZETÉSE ",ALAP," FORINT" ;

}

}

/

77

A NÉV, 6s ALAP változók a dolgozók neveit, alapbéreit tar­ talmazzák majd a lekérdezés eredményeképpen. A TÖRZS-be olvassuk be a törzsszámokat, igy ez szerepel majd a fel­ tételben. A "while" utasitás vezérli a programot, sorban olvasva a törzsszámokat, addig mig el nem fogynak. A cik­ lus két utasitást - RETRIEVE és PRINT - tartalmaz. A RETRIEVE mindig a frissen beolvasott törzsszámra keres, - ezt a TÖRZS-bol veszi /az adatbázisban ténylegesen ke­ reső rutin már minden alkalommal D .TÖRZSSZÁM=konstans tipusu feltételt kap/- és az eredményt a NÉV és az ALAP változókba rakja. A PRINT már csak megfelelő formátumban kiir. Erős lehetőség, hogy a QUEL utasításokban maguk az adatbázis reláció és oszlopnevek is változók lehetnek, mó­ dot adva ezzel pl. tetszőleges önálló adatkezelő nyelv interface-ének megprogramozására EQUEL-ben /SQL inter­ face az INGRES-hez/. Erre is egy egyszerű példa: b/ Valamilyen reláció egyik oszlopának beolvasott összes értékére hivjun^meg egy PROCESS nevű rutint. Legyen ennek paramétere a másik oszlopban lévő megfelelő érték! main í # # # #

C

)

int ÉRTÉK1,ÉRTÉK2 ; char RELÁCIÓ [l 3] ,OSZLOPl[ 13] ,0SZL0P2 £ 13] ;

READ(RELÁCIÓ); READ(OSZLOPI) ; READ(0SZL0P2) ; # # RANGE OF R IS RELÁCIÓ while (READ (ÉRTÉKl í)

í # # RETRIEVE ÉRTÉK2=R.OSZLOP2 # # WHERE R.OSZL0P1=ÉRTÉK1 PROCESS (ÉRTÉK2) ;

^

frft]

78

A lekérdezni kivánt reláció nevét RELÁCIÖ-ba, a két osz­ lopét 0SZL0P1 és 0SZL0P2-be olvassuk, az első oszlop adott értéke ÉRTÉKl, a másodiké - ezt a RETRIEVE olvassa be ÉRTÉK2. A RANGE utasitás szokásos helye a RETRIEVE előtt lenne, - oda is helyezhettük volna - de az INGRES emlé­ kezik a definicióra, s mindaddig mig R-t újra nem definiál­ juk, az a RELÁCIÓ változóban lévő relációnéven lesz megha­ tározva. CSTON 76l Az IBM SQL/OS gazdanyelvként PL/l-et és COBOL-t hasz­ nál, mi a példákban PL/l-gyel dolgozunk. /Mellesleg az INGRES gazdanyelvként a C-n kivül FORTRAN-t és Pascal-t, az ORACLE COBOL és PL/1 mellett Assembler-t, FORTRAN-t, C-t és Pascal-t is kinál £ d IEC 8ll./ A PL/1—SQL tetszőleges PL/1 és SQL utasításokból áll. Az SQL utasitást előzi meg. Ugyancsak $ kell, hogy le­ gyen az első karaktere az SQL utasításokban használt PL/1 változóknak. A beépített SQL kiegészül néhány speciális utasítással. Ezek közül néhány: $LET Cl BE SELECT NÉV INTO $X FROM DOLGOZÓ WHERE BESOROLÁS=$Z; Ez az utasitás Cl-et deklarálja mint lekérdezést, mely a Dolgozó relációból azoknak a nevét, -akiknek besorolása megegyezik a $Z változó aktuális értékével a $X változó­ ban adja vissza. Az utasitás hatására semmi sem történik még, az SQL/DS tudomásul veszi a deklarációt. A $ OPEN Cl; megnyitja a lekérdezést. Ez a felhasználó számára annyit jelent, hogy Cl utasitás input - tehát felhasználó szol­ gáltatta - értékeit megjegyzi a rendszer, és azokon töb­ bet változtatni nem lehet. Ez lényeges eltérés az EQUEL

79

filozófiájától, mely a C változóknak mindig az aktuális értékét vette. Egy-egy sor beolvasása a $ FETCH Cl; hatására történik. A lekérdezés lezárását $ CLOSE Cl; utasitás

végzi.

c/ írjuk ki néhány dolgozó nevét és alapbérét! A kii randó dolgozók törzsszámát a PL/1 program olvassa be. KIÍR:PROC; DCL EOF BITCi) INIT ('0' $NÉV CHAR (20) ,

b) ,

gTÖRZS CHAR (5), $ALAP BIN FIXED; ^ RENDSZER INTERFACE DEKLARÁLÁS > $LET C BE SELECT NÉV,ALAPBÉR INTO $NÉV,$ALAP FROM DOLGOZÓ WHERE TÖRZSSZÁM=$TÖRZS; ON ENDFILe (s YSIn ) EOF='1' B; GET LIST($TÖRZs ) ; DO WHILE (iEOf ); $OPEN C ; IF SYR_C0DE~1 =0 $FETCH C; IF SYR.CODE-j =0

THEN CALL BAj( 'OPEN ') ; THEN CALL BAJ ('FETCH') ;

$CLOSE C; IF SYR_CODE 1 =0 THEN CALL BAJ ('CLOSE') ; IF SYR_C0DE=0 THEN PUT LIST($NEV,' FIZETÉSE ',$ALAP,' FORINT') GET LIST($TÖRZS) ; END; END KIIR;

80

A rutin lényegében véve az a/-ban látható C program PL/1 megfelelője. Két megjegyzést teszünk: A $OPEN és #CLOSE utasítások nem helyezhetők a cikluson kívülre. Ekkor ugyanis a program mindig az elsőnek beolvasott törzsszámú dolgozó adatait Írná ki, hiszen az input változók értékeit íjOPEN-nél egyszer s mindenkorra megjegyzi. Szemben a EQUEL-lel itt jól láthatóan van hibakezelés. /Az EQUEL-ben is van, mint CSTON 761 egy mellékmondatából ki­ derül, de a cikkben közölt példákból a részletek nem derülnek ki./ A SYR_CODE változóban adja vissza a rendszer a hibakódot Ezt - jelen programban kicsit furcsán - a BAJ rutin feldolgoz hatja, és megteheti a megfelelő intézkedéseket. d/ Valamilyen relláció egyik oszlopának beolvasott összes értékére hivjunk meg egy PROCESS nevű rutint1 . Legyen ennek paramétere a másik oszlopban lévő megfelelő érték 1 Ennek a feladatnak a megoldásához meg kell ismerkednünk ^PREPARE és $EXECUTE utasításokkal. A ^PREPARE formátuma: $PREPARE 4.utasitásnév> AS (karaktersorozat); Például a $PREPARE C AS SZÖVEG; értesíti az SQL/DS-t, hogy a SZÖVEG nevű változóban SQL/DS utasítás lesz, és azt végre szándékozunk hajtatni. A végrehaj tás ^EXECUTE (utasitásnév)

USING (változósorozat)

hatására következik be. Pl. a SZÖVEG='UPDATE DOLGOZÓ SET ALAPBÉR=? WHERE NÉV=?'; $ EXECUTE' C USING $UJBÉR, \ $NÉV utasítások a $UPDATE DOLGOZÓ SET ALAPBÉR=$UJBÉR, WHERE NÉV=$NÉV; utasítások végrehajt5s51 »redménvezik.

81

Most pedig nézzük a feladatot! PRÓBA:PROC; DCL ($ÉRTÉK1,$ÉRTÉK2) BIN FIXED (3l) , EOF BIT Cl) INIt ('o 'b ), UTASÍTÁS CHAr (i Oo ) VARYING; ^RENDSZER INTERFACE DEKLARÁCIÓ> $PREPARE VJ AS UTASÍTÁS; IF SYR_CODE 1=0 THEN CALL BAJ; GET LIST(UTASÍTÁS); ON ENDFILE(s YSIN) E0F='1'B; GET LIST(SÉRTÉKl) ; DO WHILE (“I EOF) ; ^EXECUTE U USING $ÉRTÉK2, $ÉRTÉK1; IF SYR_CODE -I =0 THEN CALL BAJ; ELSE CALL PROCESS($ÉRTÉK2); GET LIST($ÉRTÉK1 ); END; END PRÓBA; A b/-ben tárgyalt C programmal szemben itt a teljes utasitást beolvassuk /ott csak a lekérdezni kivánt reláció és a kérdés­ ben szereplő oszlopok neveit kellett/. Az utasitást tartalmazó kártya: SELECT ?= (oszlopnév2'>

FROM ^relációnév^ WHEREAoszlopnévl) =?

Itt a ..> a konkrét neveket jelölik. A ^EXECUTE a "?"-ek helyére"irja" a #ÉRTÉK2-t és $ÉRTÉKl-et igy hajtva végre a lekérdezést. Meg kívánjuk jegyezni, hogy természetesen itt is megoldható lett volna, hogy csak a neveket, és nem a tel­ jes utasitást kelljen beolvasni /a PL/1 azok alapján össze­ szerkeszthette volna a megfelelő karaktersorozatot/. Figyelemre méltó, hogy a ^EXECUTE biztosította parametrizálási lehetőség erősebb, mint amit az EQUEL lehetővé tesz. Az EQUEL-ben ugyanis az utasítás neve nem parametrizálható,

82

annak explicite szerepelnie kell CSTON 76] a $EXECUTE vi­ szont csak egy karaktersorozat tipusu változóval dolgozik, amibe bármi irható, tehát az utasitás fajtája is futás köz­ ben dönthető el. CcHAM 81^

1.3.2. Adatkezelő-programozási nyelvek Az előző paragrafusban vizsgált két beépülő nyelv uta­ sításai szintaktikájukban, koncepciójukban teljesen elütnek a gazdanyelv stílusától. A két nyelv közötti kapcsolatot a közösen használt gazdanyelvi változók teremtik meg, ezeken mint "paramétereken" keresztül kommunikál a két nyelv. Az elkülönülést formai jegyek / # # , $ / is hangsúlyozzák. A most ismertetendő nyelvek célja éppen ellenkező: alkotóik elképzelése szerint az adatkezelő rész elválaszt­ hatatlan egységet alkot a befogadó programozási nyelvvel; azzal nem csak változókon át kommunikál, de utasításai fel­ építésükben, koncepciójukban, szintaktikájukban a programo­ zási nyelv szerkezetére, fogalmaira, stílusára támaszkodnak. Ezt a lehetőséget a programozási nyelvek "absztrakt adattípus" fogalma teremti meg. Az absztrakt adattípus tu­ lajdonképpen nem más, mint adatok együttese és a rajtuk definiált műveletek. A klasszikus példa a verem, ahol a definiáló adatok a verembe helyezhető adatok tipusa, és egy Boole-változó, mely jelzi, hogy van-e elem a veremben, és a műveletek: elem kivétele a veremből, elem verembe il­ lesztése, a verem ürességét eldöntő függvény. Absztrakt tipusu változókat gyakorlatilag bármelyik, szubrutinhivási művelettel rendelkező programozási nyelv­ ben lehet implementálni. A verem például egy tömbbel és egy egész értékű változóval implementálható, és egyszerű szubrutinok a műveletek. Az adatok és a műveletek leírásá­ ra alkalmas eszközökön kivül azonban ahhoz, hogy absztrakt

-

83

-

adattípusról beszéljünk szükség van legalább még egy további eszközre is, az adott tipusu változók generálásának lehető­ ségére. Példánkban ez azt jelenti, hogy miután definiáltuk a "verem" absztrakt adattípust, a nyelv fogadja el az A,B,C STACK stb. változókat mint "verem" tipusunak deklaráltakat /és generálja automatikusan az implementálásukhoz szükséges változókat úgy, ahogy a tipus definíciójában meghagytuk/. Az adatkezelő-programozási nyelvekben a relációk abszt­ rakt adattípusok lesznek. Nem a "reláció", mint olyan, ha­ nem minden reláció egyfajta tipust alkot. A "reláció" fo­ galma tipusképző - a nyelvben definiált - "mód"-ként jelent­ kezik /mint a PASCAL array,record, stb./. Ennek segítségé­ vel definiáljuk a Dolgozó relációt: /Az alábbi az CALAG 8l3 cikk javasolta konstrukció szellemében készült, de a PASCAL/R rendszerben CSCHM 77l, vagy a MODULA /R-ben £ REIM 83l ugyan­ így megy a reláció definiálása/. type dolgozótipus = record törzsszám: integer; név: string; részlegkód: integer; besorolás: string; főnök: integer; alapbér: integer; end; var dolgozó t relation of dolgozótipus; Az első tipusdefinició a reláció egy sorát adja meg, PASCAL rekord formájában. A második definíció a dolgozó nevű változót a "relation" mód segítségével relációként generálja. /Ezzel ekvivalens lett volna a: type dolgozóreláció = relation of var dolgozó: dolgozóreláció; felirás/.

dolgozótipus;

84

E SCHM

77lés EREIM 83"] javaslataiban kulcs megadása is

szerepel; type dolgozóreláció

= relation £ t ö r z s s z á m >

of

dolgozótipus;

A "törzsszám" kulcsnak azonosítónak kell lennie, és a reláció soronkénti olvasásánál növekvő értékei szerinti sorrendben kapjuk meg a sorokat. EREIM 83l előirja, hogy a relációsornak megfelelő rekord­ ban csak strukturálatlan adattípusok szerepelnek. Ez valóban összhangban van az első normálforma /a reláció/ definíciójá­ val /O.l.l./. ESCHM 773 erre nem tartalmaz utalást, EALAG 8ll pedig - később látni fogjuk - pointert is engedélyez oszloptipusnak. A reláció adatainak definiálása után lássuk a relációval végezhető műveleteket! ESCHM 771 és Ea l a G 8l"} nyomán: var d: dolgozótipus; • d.törzsszám=9826; d.név='Kiss Pál'; d.részlegkód=52; dolgozó=dolgozó+Edl; A programrészletben az egyik művelet az elemi relációképző, a "Cl". Ez a "relációt alkotó sor" tipusu változó­ ból egy egyetlen sorból álló relációt készit /a PASCAL halmazképző mintájára/ A "+ " relációkat egyesit, /a különbséget, a "x" metszetet képez/. Mindez a PASCAL hal­ maz műveleteinek megfelelően történik, tehát a reláció mindeddig ekvivalens a halmazzal /leszámítva a kulcs meg­ adását / . A következő konstrukció ESCHM 7 7jés a

Ea L A G

8l]

az áltáÉnos

'relációképző.

a l a p j á n m u t a t j u k be, m é g e m l i t v e ,

hogy

MODULA/R h a s o n l ó k o n s t r u k c i ó j a ettől c s a k s z i n t a k t i k á j á ­

ban k ü l ö n b ö z ő E R EB S

83"] :

w S lo"=»cen> ki * nrnaramozókat a dolgozók közül, és

-

85

helyezzük el nevüket, alapbérüket, és részlegük cimét a Programozási Osztály relációban var

/Id. 1.2.1. c-1.2.5 .c. /'.

programozási_osztály: relation of

név: string; alapbér': integer; cim:string;

programozási ősztály:=[each d.név, d.alapbér, r.cim for d,r in dolgozó,részleg where d. besorolás='programozó' and d. részlegkód=r. részlegkód "] A relációképző valóban relációs művelet: relációkon definiált, és a| művelet eredménye ugyancsak reláció. A másik művelet, amit bemutatunk szintén teljes relá­ ciókkal dolgozik, ebben hasonlit az előzőhöz. A kettő közöt­ ti lényeges különbség,hogy mig a relációképzo eredménye uj reláció, addig a "foreach" utasitás eredménye tetszőlegesen - a PASCAL keretein belül-előirható /MODULA/R-ben ilyen uta­ sitás nem létezik/: Adjunk minden programozónak 10 % béremelést! /1.2.1.j-1.2.5.j / foreach in dolgozó where

d.besorolás='programozó'

do d. alapbér=l.lxd.alapbér A "foreach" több relációval is képes egyszerre dolgozni, és a do után bármi állhat, amit a PASCAL eltűr. A "foreach" természetesen képes a relációképzo helyettesitésére /a do után elemi relációképzőt Írva/, mégsem mondható hogy feleslegessé teszi azt. Ezen az alapon ugyanis maga a "foreach" is felesleges, mert a PASCAL-ban van ciklusképzés

86

/kiegészítésképpen | mindössze három egyszerű, relációsorokon értelmezett beépített függvényre van szükség - a konstrukciót CSCHM 77} tartalmazza/. Éppen ezek az utasítások azok, melyek a PASCAL-ból PASCAL/R-t csinálnak elegáns PASCAL stilusu re­ lációs műveleteikkel. /Úgy az EQUEL, mint a PL/l-SQL soron­ ként dolgozza fel a relációt/. A bevezetett műveletek erejét a következő példával /1.2.1.e .-1.2.5.e/ jellemezzük. Képezzünk relációt olyan szállítókból, akik az 50-es kódú részleg által felhasznált összes cikkszámot szállítják! [each s.szállitó for s in szállítás where [ each sx.cikkszám for sx in szállítás where s .szállitó=s.xszállitó} > = feach c.cikkszám for c in felhasználás where c. részelgkód=5o}l A megoldás logikája azonos az SQL/DS-ével /1.2.3.e/ kihasznál va a PASCAL halmazműveletét />=/. A két konstrukció /relációképzo, "foreach"/ nyilván a relációalgebra valamennyi műveletét képes előállítani /PASCAL utasítások segítségével/. LsCHM 77} és a MODULA/R azonban ezek mellé még kvantorokat is alkalmaz, [ALAG 81}hivatkozva arra, hogy a nyelv nélkülük is relációsán teljes az egysze­ rűség kedvéért elveti őket.

87

[ÁLAG 81}

inde x e t is d e f i n i á l a r e l á c i ó h o z .

lyen uj k o n s t r u k c i ó r a n i n c s egy b i n á r i s

reláció,

Az

semmi­

i n d e x n e m más, mint

m e l y n e k e g y i k o s z l o p á b a n az i n d e x e l t

m e z ő k ü l ö n b ö z ő é r t ékei, rokra mutató pointerek

a másodikban pedig /a z é r t ezek csak

meg a PASCAL pointerekkel/ szerinti

szükség.

Ehhez

állnak.

a m e g f e l e l ő so­

f o r m á l i s a n egyeznek

A Dolgozó reláció Név

indextáblázata például:

v a r névindex:

r e l a t i o n of r e c o r d

név:

string

ref: f d o l g o z ó t i p u s

n a g y o n szemléletes. vása

generálná.

toztatni

Az

indexet a "createimage"

A p o i n t e r e k csa k o l v a s h a t ó a k

e l j á r á s hilen n é n e k , v á l ­

csak az a d a t b á z i s k e z e l ő r e n d s z e r v á l t o z t a t h a j a okét

A cikk - helyes i ndexeket.

ó v a t o s s á g g a l - k ü l ö n s z i n t r e h e l y e z i az

Az e g y s z e r ű

f e l h a s z n á l ó ezt a k o n s t r u k c i ó t jobb,

h a n e m h a s z n á l j a ez a " m á s o d i k szint"

lehetősége.

Algorit­

m u s k é s z i t h e t ö - C A S T R 75l n y o m á n - " első szinten"

indexek

h a s z n á l a t a nélkül irt p r o g r a m o k index s e g í t s é g é v e l

tört é n ő

gyorsítására. A d o l g o z a t egy h a r m a d i k s z i n t e t is def i n i á l . lációkat soronként manipuláló

ruti n o k h a l m a z a .

Ez a re­

-

88

2. IMPLEMENTÁCIÓ Egy absztrakt adattípus implementálása tulajdonképpen egy leképezés létrehozását jelenti. Ez az adattípus fel­ használójának a fogalmait - adatokat, műveleteket - a meg­ valósító adatokra és műveletekre képezi le. Ha verem tipusu változót akarunk FORTRAN-ban imple­ mentálni, a triviális megoldás egy tömb kijelölése, ahol a verem elemeit elhelyezzük, és egy egész értékű változó, mely a veremben aktuálisan tárolt elemek számát jelzi. A felhasz­ nálói interface itt nyilván a verem a rajta végezhető mű­ veletekkel, a közeg, melyben implementáljuk a "FORTRAN’gép" vagyis a számitógép, ahogyan azt a FORTRAN-on keresztül látjuk. Az "absztrakt adattípust", melynek implementációjával ez a rész foglalkozik, az 1. részben irtuk le. Persze ahány rendszer, annyi tipus - a verem esetében is több lehetőség van pl. a túlcsordulás kezelésére - de valamennyinél - amint ezt láttuk - az alapmodell a reláció és a rajta definiált műveletek /O.l./. Összehasonlitva a többi "nagy" adatmodellel, a relációs implementálása nehéz feladatnak tűnik. Jellemző, hogy mig a CODASYL DBTG 1971. évi jelentése után 1-2 évvel már forgalmaztak olyan hosszútávon is nagysikerű rendszereket, mint az IDMS vagy a DMS/1100 addig ^KIM 79^ - a szép számú kisérleti rendszer mellett - csak két olyan rendszert emlit, mely forgalmazási céllal készült /MAGNUM és QBE/, de ^SNYD 82) áttekintése az 1981-es adatbáziskezelő rendsze­ rekről ezeket már nem emliti. Ezzel együtt éppen 1981 volt a relációs adatbáziskezelők megjelenésének éve a piacon / [SNYD 82^ / - 11 évvel Codd

első cikke után.

/Léteznek rendszerek, melyekben csak a második leképzés definiált £KISS 833. Ezek vagy önállóan, az adatbázis assembleren, vagy - az első leképzés megvalósitásával -

89

tets z é s

szerinti,

erre épithető felhasználói

interface-n

keresztül h a s z n á l h a t ó k . / A r e l ációs m o d e l l tri v i á l i s venciális vezés

file

/ld.

0.1.1./.

felel m e g a m o d e l l

i m p l e m e n t á c i ó j a a sze k ­

Ez a l e g e g y s z e r ű b b a d a t s z e r ­

logikai e g y s z e r ű s é g é n e k ,

f o g a l m a k n a k d i r e k t m e g f e l e l ő j e van stb./.

A probléma ezzel

l ó k r a túl lassú.

Ennek

nálja a szekvenciális

/sor-rekord,

a megoldással

az,

reláció-file

hogy gyakorlati

e l l e n é r e sok m i k r o g é p e s file i m p l e m e n t á c i ó t

egyes

cé

rendszer hasz

/dBASE II, M R D B S ,

stb. / E bben a r é s z b e n a r e l á c i ó s a d a t b á z i s k e z e l ó r e n d s z e r e k implementálásáról

lesz

szó.

Az e l s ő

- a software - f e l é p í t é s é r ő l , ké t - á l t a l á b a n k ü l ö n t evőjükről,

fejezetben a rendszerek

a m á s o d i k b a n és

a harmadikban

interface-szel elválasztott - össze­

az a d a t t á r o l á s i

r e n d s z e r r ő l és a f e l h a s z n á l ó i

n y e l v e t e nnek a r e n d s z e r n e k az i n t e r f a c e - é r e

lefordító

optimizáló programról.

2.1.

A rendszer architektúrája

A felhasználói talános g y a k o r l a t

interface-t implementáló

s z e r i n t két,

egymást követő részleképezés

alkotja

/ld.

értése,

és az i g é n y k i e l é g í t é s é h e z

megtervezése.

7. ábra/.

E l s ő lépés

a felhasználói

igény m e g ­

szükséges műveletsor

Ezt a műveletsort be l s ő nyelvre - a reláció

soronkénti elérését

l e h e t ő v é tevő,

"adat b á z i s a s s e m b l e r -re

interface"-e

r u t i n h i v á s o k b ó l álló

f o r d i t j a az e l s ő leképzés.

s o d i k leképzés h a j t j a v é g r e nálói

leképezést ál­

a műveleteket.

az a d a t b á z i s a s s e m b l e r ,

t á c i ó k ö z e g e á l t a l á b a n az o p e r á c i ó s

Ennek és

rendszer

A má­

"felhasz­

az i m p l e m e n ­ file-kezelője.

90

7.

ábra

A két l é p é s n e k m e g f e l e l ő e n á l t a l á b a n az egyes, r e n d s z e ­ r e k is két r é s z r e o s z t h a t ó k . r é s z t "O p t i m i z á l ó "-nak legfontosabb

A z els ő l e k é p e z é s t m e g v a l ó s í t ó

/Optimizer/

feladatából

f o g j u k nevez n i .

a dódik:a felhasználói

A név

i g é n y leh e ­

tő l e g h a t é k o n y a b b a n t ö r t é n ő k i e l é g í t é s é n e k m ó d j á t k e l l m e g ­ találnia. A második d a t a az a d a t o k

leképzés a t á r o l á s i r é s z r e n d s z e r . E n n e k

fizikai e l é r é s e - r e n d s z e r i n t az o p e r á c i ó s

rendszer file-jaival, g e s - az i n d e x e k

2.1.1.

f ela­

de e n n e k m e g k e r ü l é s é v e l

automatikus karbantartása,

is l e h e t s é ­

h a s z n á l a t a stb.

SQL/DS

A 7. á b r á n

látható á l t a l á n o s

esetén a k ö v e t k e z ő módon

/8.

ábra/

f e l é p í t é s az S Q L / D S realizálódik

/System R/

91

Egyéb önálló nyelvek

/pl.

QBE/

1 1 1________

1

1-------1 1 1— -------

U s e r Friendly Interface /UFI /

Relational

Data Interface

/RDI/

Relational Data System /RDS /

.Relational

/RSI/

R e l a t i o n a l S t o r a g e Sy s t e m

-VSAM ESD S

------------ 1.MSS.J________

8.

Alulról

ábra

fölfelé h a l a d v a :

V S A M ESDS s z e r v e z é s i m ó d ú nyeges

döntés:

zési

lehetőségeket.

a tárolási részrendszer

file-ra t á m a s z k o d i k .

azt j e l e n t i ,

h a s z n á l j a az o p e r á c i ó s

Storage I n t e r f a c e

Ez

igen lé­

hogy a r e n d s z e r l é n y e g é b e n nem

rendszer biztositotta file-szerve-

A V S A M ESDS

/Virtual S e q u e n t i a l Access

M e t h o d - E n t r y S e q u e n c e d D a t a Set/

l é n y e g é b e n n e m több, m i n t

a blokk sorszáma szerinti közvetlen elérést támogató s z e r v e z é s i mód. ható,

Az t tehát,

hogy egy r e l á c i ó s

az R S S - n e k m e g á n a k k e l l tudnia,

rendszer lehetőség

/pl.

ebben n e m segiti.

mészetesen

a blokkokon belüli

hova

helyezi,

semmiféle operációs f i l e index­

S z a b a d s á g o t é lvez v i s z o n t t e r ­ szervezésben.

s z i n t ú g y dönt arról,

/az o p e r á c i ó s

file-

sor hol talál­

egy index-szekvenciális

táblá z a t a /

r e n d s z e r feletti

/RSS/

Egy operációs

h o g y m e l y i k adatát

r e n d s z e r s z e m p o n t j á b ó l m e l y i k blokkba/

ahogy akar.

92

Az RSS feladata a külső tárolóterülettel való gazdál­ kodás, az indexek karbantartása, az elérési utak realizá­ lása. Emelett ezen a szinten történik a konkurrens hozzá­ férés vezérlése, a mentés és visszaállitás. Az RSS bemenő nyelvét az "adatbázis assemblert" RSI-^ nek nevezi az SQL/DS. Ez a reláció egyszerű, soronkénti elérését biztositó utasitásokon kivül adatdefiniciós, viszszállitó, tranzakció-kezelő utasításokat is tartalmaz. Az RSI-vel mint felhasználói interface-szel az RSS komplett adatbáziskezelö rendszert alkot. Ez persze egy igen ké­ nyelmetlen rendszer, a felhasználói interface-nek ismernie kell olyan fogalmakat, mint "szegmens", tudnia kell arról, hogy létezik-e index valamilyen relációra, vagy van-e pointeres kapcsolat két reláció között, stb. Ennek az adatbáziskezelö rendszernek a felhasználója az RDS /a 7. ábrán Optimizáló/. A feladata nyilvánvaló - a felhasználó nyelv utasításait "forditja" RSI programmá. Ehhez fel kell ismernie azokat, és a belső táblázatok alapján megkeresnie a legkedvezőbb "elérési utat". Ez annyit jelent, hogy ő az, aki a különböző tulajdonságú indexek, kapcsolatok szövevényében eligazodva eldönti, hogy egy le­ kérdezés megválaszolásához pl. melyik oszlop szerinti indexet érdemes használni, vagy egy illesztést milyen al­ goritmussal érdemes csinálni. /Innen a neve: Optimizáló/. Az RDS bemeneti nyelve az RDI. Ez nem más, mint prog­ ramozási nyelvbe beépülő SQL ez már a felhasználó számára Szellemes az önálló SQL /Ezt az ábrán UFI jelöli/. A

/leirását ld. 1.3.1./, tehát hozzáférhető interface. nyelvű interface megoldása. terminál előtt ülő felhasz­

náló egy PL/1 - SQL programmal kommunikál. A párbeszédet ez folytatja a felhasználóval, ez adja a hibaüzeneteket, stb. A program - éppen úgy, mint bármely más közönséges felhasználói program - az SQL/DS-sel a beágyazott SQL

93

u t a s í t á s o k o n k e r e s z t ü l k e r ü l k a p c s olatba.

Itt használják

ki a r e n d s z e r a l k o t ó i a P R E P A R E és EXEC U T E b i z t o s í t o t t a lehetőségeket - vagy ennek a megoldásnak a kedvéért k e ­ rül t a n y e l v b e a P R E P A R E és az EXECUTE? - u g y a n i s ezek t e s z i k lehetővé,

h o g y az UFI t e t s z ő l e g e s r e l á c i ó k r a v o ­

n a t k o z ó t e t s z ő l e g e s p a r a n c s o t v é g r e tu d j o n hajtatni az RDS-sel

/I.3.I./.

külön kezelni

A d o l o g b a n az a szép,

hogy

n e m kell

az ö n á l l ó és a p r o g r a m o z á s i n y e l v b ő l é r ­

k e z ő igényeket,

az SQ L f e l h a s z n á l ó a t e r m i n á l

P L / 1 p r o g r a m o t fu t t a t - n o h a e z t

nem tudja

e lőtt egy - és igy az

ő ad hoc i g é n y e az RDS-hez m á r az UFI-n,' v a g y i s sos módon,

egy P L / l - S Q L p r o g r a m o n k e r e s z t ü l érkezik.

U g y a n i g y l ehet m á s ö n á l l ó QBE/

a szoká­

relációs n y e l v e k h e z

interface programot késziteni.

/pl.

/Ez is e l e g á n s - a

f e l h a s z n á l ó - ha n e m t e t s z i k n e k i az SQL - s a j á t m aga t e r ­ vezhet,

és

f e l h a s z n á l ó i e s z k ö z ö k k e l i m p l e m e n t á l h a t egy

s z i m p a t i k u s a b b n y e l v e t a r e n d s z e r fölé./ A á lló n y e l v e t

szimbolizáló két téglalapot

n a l b ó l r a j z o l t u k - jelezve, tudunk.

CASTR 76, BLAS

8Ű

többi ö n ­ szaggatott v o ­

h o g y ilyenek l é t e z é s é r ő l n e m

94

2.1.2. INGRES

elérési módok

9.

ábra

95

A 9.

ábr a az

INGRES

s z e r k e z e t é t m u t a t j a be. Az á b r á n

látható t é g l a l a p o k U N I X f o l y a m a t o k a t ,

a nyilak pedig c s ö ­

v e k e t s z i m b o l i z á l n a k . Eze k e t a f o g a l m a k a t m a g y a r á z z u k el először: A folyamat

/process/ a U N I X o p e r á c i ó s

egy p r o g r a m által jelent.

címezhető

rendszerben

/virtuális/ m e m ó r i a d a r a b o t

E n n e k m a x i m á l i s n a g y s á g a P D P - l l / 4 0 - e n 64K,

ön vag y 1 1 / 7 0 - e n

1 28K

/byte/.

11/45-

Eg y f e l h a s z n á l ó i p r o g r a m

több f o l y a m a t b ó l állhat.

Ezek a f o l y a m a t o k e g y m á s t ó l

getlenül tevékenykednek,

és s z i n k r o n i z á c i ó s u t a s í t á s o k k a l ,

file-okon

füg­

és c s ö v e k e n k e r e s z t ü l t a r t a n a k e g y m á s s a l k a p ­

csolatot. A cső

/pipe/

egy e g y i r á n y ú k o m m u n i k á c i ó s

f o l y a m a t o k között. tei a f o l y a m a t o k on keresztül

Egy folyamat m á s i k n a k k ü l d ö t t ü z e n e ­

s z e m p o n t j á b ó l o l y a n o k , m i n t h a egy f ile-

t a r t a n á k a k a p c s o l a t o t , m e l y r e az ü z e n ő f o ­

lyamat irni tud, netet.

csatorna

a v e v ő pedig l e o l v a s h a t j a ról a az ü z e ­

V a l ó j á b a n a U N I X szervezi m e g a k ü l d e m é n y c é l b a

j utását e nnél h a t é k o n y a b b módon, adás és a v é t e l

és o g o n d o s k o d i k az

szinkronizálásáról.

L á s s u k m o s t t e h á t a r e n d s z e r m ű k ö d é s é t 1 M i n t az á b r a tetejéről

látható, aszerint,

k e z e l ő nyelv/

h ogy a Q U E L - b ö l

/önálló a d a t ­

v a g y az EQU E L - b ő l h a s z n á l j u k a r e ndszert,

v á l t o z i k a f o l y a m a t o k k a p c s olata.

A QUEL felhasználó p a ­

r a n c s a i t i n t e r a k t i v t e r m i n á l k e z e l ő m o n i t o r fogadja, a rendszer üzeneteit

is ez t o v á b b í t j a

és

/a Q U E L i n t e r f a c e

és a m o n i t o r k ö z ö t t i nyíl az á b r á n p e r s z e n e m csövet, nem terminálra

Írást

ram m u n k a t e r ü l e t r e felhasználónak és tárolni

ill, o n n a n o l v a s á s t olvassa a

QUEL utasításokat,

lehetősége van ott

az u t a s í t á s a i t .

jelent/.

ha­

A prog­ igy a

f elépíteni, m ó d o s í t a n i

A monitor paraméterezhető

m a k r o l e h e t ő s é g e t is tar t a l m a z

CDIEC 81] . K i h a s z n á l v a a

UNIX standard lehetőségeit a m o n itor inputját file-ként

96

m e g a d v a n e m i n t e r a k t i v m ó d o n is l e h e t Q U E L p a r a n c s s o r o ­ zatot f u t t a t n i - Id.

/ilyen l e h e t ő s é g más r e n d s z e r e k b e n

is va n

1.2.6. /. Az

E Q U E L - t h a s z n á l v a a f e l h a s z n á l ó p r o g r a m j a lép a

monitor

f o l y a m a t h e l y é b e a struktúrában.

ram m e g k e r ü l i

a mon i t o r t ,

és c s ö v ö n k e r e s z t ü l k ö z v e t l e ­

nül a s z i n t a k t i k u s e l e m z ő n e k rancsokat

/az e l o f o r d i t ó

I l y e n k o r a prog--

/2 j folyamat/ k ü l d i a Q U E L p a ­

á l t a l az E Q U E L u t a s í t á s o k h e l y é ­

re p r o g r a m b a i l l e s z t e t t IN G R E S h i v á s o k p a r a m é t e r e i ezek a p a r a n c s o k - ld.

1.3.1./.

Az

e r e d m é n y r ő l a 2.

folyamat ered­

m é n y k ó d o t küld,

l e k é r d e z é s n é l p e d i g a s o r o k a t a 3.

folya­

m a t k ü l d i vissza.

tSTON 763 két é r v e t h o z fel a k e t t ő s f o l y a m a t s t r u k tura m e l l e t t ,

megemlítve,

hogy a monitort meg lehetett

volna Írni

E Q U E L - b e n és k ö z ö n s é g e s E Q U E L p r o g r a m k é n t

hatna.

az

/Ez

a monitor még tekintették

SQL/DS m e g o l d á s

- ld.

2.1.1./.

az E QUEL l é t e z é s e előtt k é s z ü l t

sür g ő s n e k az á t i r á s á t

óta v á l t o z o t t - e a h e l y z e t / .

el,

/nem tudjuk,

és nem

h o g y 1976

ha a 3. f o l y a m a t ahelyett,

hogy k ö z v e t l e n csövön át e l k ü l d e n é sorokat,

E l ő s z ö r is

A második érv szerint a fu­

tást v a l a m e n n y i v e l l a s s í t a n á ,

ramnak a m e g t a l á l t

fut­

a 2.

a felhasználói prog­

folyamaton keresztül

adná át az elsőnek. A 2.

f o l y a m a t a s z i n t a k t i k u s e l e m z ő . F e l a d a t a mé g

emellett a konkurrens zőpont,

h o z z á f é r é s m e g s z e r v e z é s e és a n é ­

v a l a m i n t az i n t e g r i t á s i

feltételek realizálása.

A nézőpontot - ugyanaz, mint az SQL/DS-é /ld.1.1.1./ még nem implementálták /emiatt maradt ki 1.1.2.ből/, de CKIM 811 már működőként említi. 1976-ban

A l e k é r d e z é s p r o c e s s z o r a 3.

folyamat.

A 7.

ábra

O p t i m i z á l ó j á n a k a t é n y l e g e s e n csak l e g k e d v e z ő b b e l é r é s i ut k i v á l a s z t á s á v a l f o g l a l k o z ó ré s z é t elemzés

a 2.

folyamatban megvolt/

/a s z i n t a k t i k u s

és a t á r o l á s i r é s z ­

97

rendszer programjainak a lekérdezéshez tartalmazza.

s z ü k s é g e s részét

A két r é s z r e n d s z e r é r i n t k e z ő f e l ü l e t e - az

I N G R E S elérési m ó d

/access m e t h o d /

itt is p o n t o s a n d e f i n i á l t , r u t i n o k b ó l áll.

Látni

i n t e r f a c e - n e k nevezi -

soronkénti elérést biztositó

fogjuk h o g y ez a f o l y a m a t

n e m vélet-ler-

nül t a r t a l m a z z a m i n d a k é t r é s z r e n d s z e r l e g f o n t o s a b b el e ­ meit:

egy- e g y r é s z l e k é r d e z é s

kérdezés

egy r e l á c i ó s

/a több r e l á c i ó t é r i n t ő le­

r é s z l e k é r d e z é s e k r e b o m l i k az INGRES-

ben / eredménye döntően befolyásolja a további

elér é s i u-

tat. A módositó

/törlés,

beillesztés,

felújítás/

d e f i n í c i ó s u t a s í t á s o k a t r e a l i z á l j a a 4. folyamat

8 overlay-bŐl

áll.

folyamat.

és a d a t ­ Ez a

A módosítandó adatok kiválo­

g a t á s a - l e k é r d e z é s k é n t - a 3. f o l y a m a t b a n tör t é n i k . a d a t o k speciális 19.

ábra/.

f i l e - b a n k e r ü l n e k át a 4.

r a k oztat:

folyamathoz

Emellett a megoldás - a módosítandó

előválogatása - mellett

CSTON 76]

Az

adatok

több é r v e t is

felso­

h á r o m - e l é g s z é l s ő s é g e s - p é l d á t h o z o lyan

f e l ú j ításra,

ahol a m ó d o s í t á s

soronkénti előrehaladása

- t ö b b sort é r i n t ő f e l ú j í t á s o k r ó l v a n szó - b e f o l y á s o l j a a

még hátralévő módosításokat,

ugyanis a felujitás

t é t e l e i n e k vag y a m á r f e l ú j í t o t t s orok m é g m i a t t u k m á s sorok e l e g e t l anul v á l t o z n a k m e g

fognak tenni,

sorok.

h a t ó s á g r a vonatkozik. CSTON 76]

e g y s z e r , vagy

s Így

Negyedik érve

fel­

indokolat­

a visszaállít­

megjegyzi,

h o g y ez a m e g ­

oldás

/ő k é s l e l t e t i m ó d o s í t á s n a k - d e f e r r e d u p d a t e - n e ­

vezi/

ige n k ö l t s é g e s és o l y a n f e l h a s z n á l ó t eml í t ,

k á b b v á l l a l t a volna, tást a ren d s z e r n e k ,

aki i n ­

hogy nem adhat meg b á rmilyen módosí­ ha azok m á r a 3. f o l y a m a t b a n lezaj­

lanak. A folyamat-struktura kialakításánál s z e m p o n t a 64 K-s m e m ó r i a k o r l á t volt. je n a g y s z e r ű ö s s z e f o g l a l ó - é r t é k e l ő

az e l s ő d l e g e s

A rendszer CSTON 80]

tervező­

cikké b e n

98

emliti/

hogy

csökkenéshez matból álló maton kell

a f o l y a m a t s z e r k e z e t igen j e l e n t ő s vezetett.

/ E b b e n a c i k k b e n m á r egy 5 f o l y a ­

rendszerről áthaladnia,

l é t e s i t é s t jelent/.

sebesség­

ir, ami

ahol a v e z é r l é s n e k

8 folya­

8 UNIX s c h e d u l e r hivást,

Emliti,

cso-

hogy t a l á n h e l y e s e b b lett

v o l n a k i h a s z n á l n i a P D P - 1 1 / 7 0 b i z t o s i t o t t a 128 K-t - ezt a kisebb g é p e k k e l d o l g o z ó ték meg - d e

felhasználók kedvéért nem tet­

igazi m e g o l d á s k é n t egy 32 b i t e s m i k r o p r o c e s z -

szorral m ű k ö d ő gép h a s z n á l a t á t javasolja. VAX-ll-en

forgalmazzák.

A

Ez

INGRES-t

r e n d s z e r 180 K b y t e r e n d s z e r t e ­

rületet + f e l h a s z n á l ó n k é n t CDIEC 811

Az

90 K byte m e m ó r i á t

a rends z e r e g y e t l e n f o l y a m a t b ó l

igényel. áll Ü A L L M 82^

ÜSTÖN 76l .

2.1.3.

LIDAS

1.1.4., szerről.

1.2.6.

és 1 . 3 . 2 . - b e n m á r v o l t

Emlékeztetünk arra,

szó erről a r e n d ­

hogy 128 K 2 b y t e - o s

ponti m e m ó r i á j u LILITH s z e m é l y i s z á m i t ó g é p e n fut, ben programozták.

A rendszer

felépitése

a 10.

szó k ö z ­ MODULA-2-

á brán látható.

__ DISCUSS DISCUSS interpreter

interface

MODULA/R interface

MODULA/R adatmodulok Lekérdezés vezérlő elem Tárolási részrendszer

interface operációs rendszer

10.

ábra

99

A rendszer két felhasználói

interface-t biztosit,

egyiket a számítógéphez nem értő felhasználó, programozó-felhasználó

számára.

Az

előbbi

a másikat

a DISCUSS

kérdező nyelvet

/I.2.6./, /ld.

tartalmazza.

adatkezelő-programozási nyelv

/id.

Az u t ó b b i

séma d e f i n i á l á ­

sakor k e l e t k e z ő M O D U L A / R a d a t m o d u l o k . E z e k e t a rendszer

/ld.

definíciós

és a

futtatható modulokat.

mint absztrakt adattípusoknak

a definícióit

GAMBIT i n t e r ­

1.1,4./ generálja,

MODULA/R forditóprogram készit belőlük

+ műveletek/

a MODULA/R

1.3 . 2 . / . !

A rendszer jellegzetessége a relációs

A relációknak,

S y s t e m / , Ez

ü r l a p d e f i n i á l ó t , és a H I Q U E L l e ­

1.2.6./

a ktiv a d a t d e f i n i c i ó s

a

/ Data­

base I n t e r f a c e S p e c i f i e d for a C a s u a l U s e r of a S m a l l adatszerkesztőt

az

tartalmazzák.

/adatszerkezet

A felhasználó a

fázis u t á n m á r c s a k az o t t d e f i n i á l t m ó d o s i t ó

tranzakciókat használhatja, modulokon keresztül.

és e z e k e t csa k a l é t r e h o z o t t

A módszer hátránya rugalmatlansága,

el ő n y e viszont,

hog y k o m p l i k á l t k o n z i s z t e n c i a - f e l t é t e l e k

megadását teszi

lehetővé

/ld.

A lekérdezés-vezér1Ő

1 . 1 .4./.

/query e v a l u a t i o n m a n a g e r ,

felad a t a az e l é r é s i ut o p t i m i z á l á s a .

A tárolási r é s z r e n d ­

szerrel a s z o k á s o s a d a t b á z i s a s s e m b l e r e n tül tart k a p c s o l a t o t , /element i n t e r f a c e /

2.1.4.

san m e n n y i r e

hivják

A P P L E II m i k r o g é p e n é p í t é s e a 11.

fREBS

82,

keresz­

REB S 83]

rendszer

rendszer lényegében a QBE teljes/

/7. ábra/

csa k itt a z t e l e m i n t e r f a c e - n e k

Néhány mikrogépes

A TITAN

QEM/

/nem t u d j u k p o n t o ­

implementációja PASCAL-ban 56 K b y t e m e m ó r i á v a l

á b r á n látható:

/ld.

/7000 sor/,

1 . 2 .6./.

Fel­

100

l}.

ábr a

Az ábra t e t e j é n látható A l a p s z e q m e n s

a vezérlő része

a rendszernek. E z á l l a n d ó a n a m e m ó r i á b a n t a r t ó zkodik. E g y szinttel lejjebb

4 egymástól

független

szegmens helyezkedik

101

el,

az A l a p s z e g m e n s

e z e k e t t ölti be a m e m ó r i á b a aszerint,

hogy mikor melyikre van

szükség.

Balról j o b b r a h a l a d v a az els ő S z i n t a k t i k u s k é p e r n y ő k e z e l ő szegmens. A Relációkezelő

Ez k o m m u n i k á l

szegm e n s

és READ,

szer.

tör­

iró és o n n a n o l v a s ó s z e gmens a W R I T E

a QBE-hez képest újdonságnak

számitó parancsokat

1.2.6./ h a j t j a végre. A Lekérdezések végrehajtása

Elég

/reláció definiálása,

listázás/. A Relációt file-ra

/ld.

a felhasználóval.

tartalmazza a relációkat le­

iró táblákkal v é g z e t t m ű v e l e t e k e t lése,

elemzó és

szegmens

a legösszetettebb.

jól elvá l i k b e n n e az o p t i m i z á l ó és a t á r o l á s i r é s z r e n d ­ Elkülönitett blokkban vannak a keresési

összeállító,

a relációalgebrai

stratégiát

s z i n t ű m ű v e l e t e k e t végző,

ill.

az i n d e x b e n és a r e l á c i ó k b a n s o r o n k é n t m a i n i p u l á l ó p r o g r a m ­ r é s z e k . CFALQ 82] Az

RDBAS r e n d s z e r m é g j o b b a n s z e g m e n t á l t , ami érthető,

h i s z e n egy 32 K-s H P 2 1 M X - e n i m p l e m e n t á l fikus nyelvet

/ld.

1.2. 6 . / A 12.

ö n á l l ó s z e g m e n s t jelöl:

eg y Q B E - s z e r ü g r a ­

á b r á n v a l a m e n n y i doboz

102

12.

ábra

103

F i g y e l e m r e m é l t ó a T I T A N és az R D B A S s o n l ó s á g a . A két speciális Írása, sa

olvasása,

/ld.

l e h e t ő s é g t ő l - TITÁN:

L e k é r d e z ő nyelv,

str a t é g i a m e g v á l a s z t á s a

goritmus, index/

Korlátozás

kezelés.

/ld.

elemző,

algoritmus,

Ú g y t ű n i k az R D B A S - n á l n i n c s

de k e r e s ő nincs.

2.1,6./!

A 13.

13.

Il l e s z ­

/ o p t i m i z á l á s /, I l l e s z t é s i a l ­

/+ Proje k c i ó /

V é g e z e t ü l n é z z ü k meg, nyelv

s z e r e p e l n e k a két

Szintaktikus

e l k ü l ö n í t e t t t á r o l á s i részr e n d s z e r , p r o g r a m van,

file-ok

felhasználói utasítások definiálá­

1.1.2./ - u g y a n a z o k a b l o k k o k

rendszerben: tési

RDBAS:

szerkezetének ha­

hiszen

Reláció

/és

interface-szel

s ort m ó d o s i t ó

CHERM 83] .

h o g y a n r e a l i z á l ó d i k az A P P L E ábra

ábra

ennek a felépítését mutatja

104

Ez a s z e r k e z e t az ö s s z e s m e g lepő,

eddigitől különbözik,

h i s z e n maga a r e n d s z e r sokkal e g y s z e r ű b b .

valósitás

A meg-

a P D P D A T A R E T R I E V E - 11 u t i l i t y - jár a táma s z k o d i k ,

m i n d e n a d a t o k k a l k a p c s o l a t o s m ű v e l e t e t ez v é g e z az ábráról

is

el

/mint ez

leolvasható./

A f e l h a s z n á l ó e l ő s z ö r az latba.

ami nem

Interpreterrel kerül kapcso­

Ez a n a g y o n e g y s z e r ű p a r a n c s n y e l v u t a s í t á s a i t é r ­

telmezi

/ellenőrizve közben,

hogy a f e l h a s z n á l ó m i l y e n a d a ­

to k m i l y e n j e l l e g ű h a s z n á l a t á r a

j ogosult/,

függően i n d i t j a a három feldolgozás melyikét.

Ezek

és j e l l e g ü k t ő l

előkészítő modul vala­

fo f e l a d a t a az elér é s i u t m e g h a t á r o z á s a ,

hi­

s z e n az A P P L E - f e l h a s z n á l ó

az ál t a l a h a s z n á l n i k i v á n t r e l á ­

c iók n e v e i t

s e m adja meg,

c s u p á n az a d a t m e z ő k

neveit

1.2.6./.

/ld.

Az e l é r é s i ut az E l é r é s m á t r i x b ó l

kapha t ó .

azonos o s z l o p n e v e k a l a p j á n p r ó b á l m e g el az i n p u t t ó l

az o u t p u t i g .

/oszlopok/

A r e n dszer

i l l e s z t é s e k k e l jutni

Ha ez sike r ü l az e r e d m é n y ü l k a ­

p o t t m ű v e l e t s o r t f i l e - r a i r j a - és a t ö b b i m á r az u t i l i t y dolga.

LPATN

831

A mikrogépes

r e n d s z e r e k közül k é t b o n y o l u l t a t és egy

n a g y o n e g y s z e r ű t m u t a t t u n k be. s z e g m e n t á l t s á g , az o v e r l a y

Közös

h asználata.

szű k memóriaíkapacitásból

adódik,

m e g i r n i őket.

viszont,

Má s ké r d é s

j e l l e m z ő j ü k az erős Ez n y i l v á n v a l ó a n a

t ehát m á s k é p p n e m lehetne h o g y az o v e r l a y v a l ó s z i -

nüleg sokat ront a hatékonyságukon. E zek a r e n d s z e r e k k e v é s b é szer i n t s t r u k t u r á l t a k , m i n t tétlenül

létezik adatbázis

szigorúan,

és m á s

a n a g y g é p r e Írottak. assembler,

m o d u l o k v é g z i k el az e g y e s m ű v e l e t e k e t . szépszámú rendszer

t e r m é s z e t e s /.

- 1.2.6.

Nem fel­

és m i u t á n e g y - e g y l e ­

kérdezést relációalgebrai műveletsorra bontottak,

használó

szempontok

külön-külön

/Az a l g e b r a i n y e l v e t

- e s e t é b e n ez egészen

105

N e m t é r ü n k ki k ü l ö n a r e l á c i ó s á n ne m t e l j e s r e n d s z e r e k szerkezetére. viális,

Ez a r e l á c i ó s r e n d s z e r e k é h e z k é p e s t elég t r i ­

h i s z e n e g y s z e r r e c s a k egy r e l á c i ó v a l - ez á l t a l á b a n

egy f i l e - t jel e n t - d o l g o z n a k .

2.2.

Optimizálási algoritmusok.

M i n t a 7. á brán látható, rendszerekben a felhasználói logikailag/

Optimizáló implementációk

a r e l ációs a d a t b á z i s k e z e l ő igények kielégitése

ké t l é p é s b e n t ö rténik.

/legalábbis

A tárolási részrendszer

feladata egy reláció hatékony manipulálása. • Az O p t i m i z á l ó b o n t j a le a s o k s z o r k o m plex,

több relációt

érintő lekérdezéseket vagy módosításokat egy-relációs műve­ l e t e k sorozatára. Elég n y i l v á n v a l ó ,

mekkora

hatást gyakorol

az o p t i ­

mizáló algoritmus a rendszer h a tékonyságára. Feladata, r e n d e l k e z é s r e álló k ü l s ő és k ö z p o n t i m e m ó r i á b a n , idő a l a t t v é g r e h a j t h a t ó

műveletsor

t a l á b a n n a g y s zámú l e h e t s é g e s b ő l . sorrendjéről,indexek,

a legrövidebb

kiválasztása

Döntenie kell

a

az

ál­

a lépések

s z e r v e z é s i m ó d o k h a s z n á l a t á r ó l vag y

nem kihasználhatóságáról,

az e gyes m ű v e l e t e k e l v é g z é s é h e z

r e n d e l k e z é s r e álló a l g o r i t m u s k é s z l e t b ő l az a d o t t h e l y z e t b e n legjobban

alkalmazható megválasztásáról

stb.

Az i s m e r t e t e n d ő o p t i m i z á l á s i a l g o r i t m u s o k h e u r l s z t i k u s a k , és a z t s e m t u d j u k m e g m o n d a n i ,

m e l y i k a "l e g j o b b "

/m é g a

"legjobb" fogalmát sem o l y a n e g y s z e r ű d e f i n i á l n i / .

A

b o n y o l u l t s á g á t jól j e l l e m z i

ha te­

a következő eredmény:

k i n t j ü k a l e k é r d e z é s e k n e k az ille s z t é s , az e g y e n l ő s é g nyelvét

feltételű korlátozás

már

a k k o r az e rre k é ­

algoritmus bonyolultsága

zés m é r e t é t ő l e x p o n e n c i á l i s a n függ. ájának eldöntése

ö s s z e h a s o n l í t á s és

/kiválasztás/ generálta

/nem lesz r e l á c i ó s á n teljes!/,

szíthető optimizálási

az N D - t ~ l j e s

feladat

Két k é r d é s

a lekérde­ ekvivalenci­

f e l a d a t o k k ö r é b e tartozik.

106

Egy,

a fentinél

csupán

szükebb körű lekérdezés osztályra sikerült

o(n^‘) b o n y o l u l t s á g ú a l g o r i t m u s t

d é s b e n s z e r e p l ő v á l t o z ó k száma/. goritmusok,

a tárolási

/n a k é r ­

És e z e k az a b s z t r a k t a l ­

szerkezet kinálta lehetőségeket

/index, k ö z v e t l e n h o z z á f é r é s , be!

találni

stb./ nem veszik figyelem­

CAHO 791

2.2.1.

A P a l e r m o - a l g o r i t m u s . LIDAS i m p l e m e n t á c i ó

Ez az 1 9 7 2 - b e n p u b l i k á l t e l j á r á s r e d ukciós a l g o r i t m u s á n a k tele.

/O.2./

Codd a l g o r i t m u s á n a k

l ó a n a 2. és

3.

lépés,

lényegében véve Codd

javítása, hatékonyabbá té­

legköltségesebb része nyil v á n v a ­

a lekérdezésben részt vevő relációk

Descartes-szorzatának képzése,

m a j d az

i g y kapott,

hetően hatalmas méretű relációból a lekérdezés

felte­

feltételei­

n e k eleget t e v ő s orok k i v á l a s z t á s a . A javitott Des c a r t e s

algoritmus

alapötlete

szorzatot képezni,

indextáblákat

létrehozni,

s z e r i n t n e m kell

ehelyett elegendő speciális

azokban összegyűjteni a válasz­

k é n t szóba j ö h e t ő s o r o k k ö z v e t l e n e l é r é s é t p o i n t ereket.

Az

l e h etővé t e v ő

indextáblák összevetésével kapjuk majd meg

a v á l a s z k é n t a d a n d ó r e l ációt. Kétfajta indextáblát definiálunk:

az é r t é k l i s t a

eg y

adott T változó

adott A o s z l o p á r a k é s z ü l és e g y s z e r ű inverz

file.

az A - b a n

nak

Legyen a^

s z e r e p l ő t e t s z ő l e g e s érték,

a s o r o k n a k a m u t a t ó i pedig,

P j l ,Pj2 ' * ' * 'P jk ! E k k o r az

azok­

ahol az A o s z l o p b a n a^

í a j ' ( Pji ' • * •

áll

j=l/2,...,m

elemek halmazát nevezzük értéklistának. Párlista

o l y a n T és U v á l t o z ó k A és B o s z l o p a i n a k é r ­

t é k e i r e készül,

melyekre

a lekérdezés

T.A0C.B

vagy>,vagy = / alakú feltételt tartalmaz. ^ (Pj^ / halmaza,

/ ••• aho l

A párlista ekkor

’ C <3^ /^k^ ' * * * '*^k ^ ^ k = ^ , 2 , . . . , p

a p-k olyan

/0 vagyad

elemek

T s o r o k r a m u t a t ó p o i n t e r e k ahol

107

T.A =ak , a U . B=b^,

pedig olyan U sorokra mutató pointerek,

és

t e l j e s ü l az a ^ 0 b^

ha T . A - r a v a g y

feltétel.

Nyilvánvaló,

U . B - r e m á r v a n értékl i s t a ,

ahol hogy

a párlista el­

készítése leegyszerűsödik. Az a l g o r i t m u s t r e l á c i ó k a l k u l u s terminológiában-'/1.2.1. / Írjuk le.

Az i n d e x t á b l á k a t é p í t ő r é s z a l g o r i t m u s t

i n v e r t á l á s á n a k nevezzük.

reláció

A reláció invertálása a következő­

k é p p e n történik: a/ ha a r e l á c i ó n d e f i n i á l t v á l t o z ó s z a b a d

/nem k v a n t o -

r o s /, a k k o r a r e l á c i ó n a k a l e k é r d e z é s b e n h a s z n á l t o s z l o p a i ­ ra v o n a t k o z ó p r o j e k c i ó j á t á l l í t j u k elő, és a z z a l dolgo z u n k . b / H a az r^ v á l t o z ó

/akár szabad,

akár kvantoros/

l a m i l y e n r ^ Ö rj ö s s z e h a s o n l í t á s b a n s z e repel és

va­

az r^ v á l ­

t o z ó n a k az ö s s z e h a s o n l í t á s á b a n s z e r e p l ő o s z l o p á r a m á r v a n értékindex,

a kkor e l k é s z í t j ü k az ö s s z e h a s o n l í t á s p á r i n d e x é t .

Ha az r ^ - n e k n incs m e g f e l e l ő é r t é k i n d e x e ,

az

r^ ö s s z e h a s o n ­

lításban szereplő oszlopára készül értékindex. index készítésénél

Az é r t é k ­

az r ^ - r e v o n a t k o z ó e g y v á l t o z ó s

lek f i g y e l e m b e veendők,

és c s a k

feltéte­

az e z e k e t k i e l é g i t Ő s orok

p o i n t e r e i k e r ü l h e t n e k b e az érték i n d e x b e . M a g a az a l g o r i t m u s

ezek után a következő:

1. M i n d e n l e k é r d e z é s b e n s z e r e p l ő v á l t o z ó r a m e g b e c s ü l ­ jük az i n v e r t á l á s á h o z

szükséges memória méretét.

A becs­

l ések a l a p j á n n a g y s á g s z e r i n t n ö v e k v ő s o r r e n d b e r e n d e z e t t L v á l t o z ó l i s t á t h o z u n k létre. 2. A l i s t a e l s ő

/követ k e z ő /

relációját

invertáljuk,

és k i h ú z z u k a m e g f e l e l ő v á l t o z ó n e v é t a l i s t á b ó l . 3. Ha L üres, s eket k é s z i t ü n k ,

u g r á s a 4.

lépésre.

Ha nem,

uj b e c s l é ­

s z ü k s é g e s e t é n á t r e n d e z z ü k L-t,

és v i s z -

s z a t é r ü n k 2-re. 4. Az é r t é k és p á r i n d e x b ő l a l e k é r d e z é s i

feltételnek

108

m e g f e l e l ő e n u n i ó k k a l és m e t s z e t e k k e l e g y e t l e n közös i n d e x ­ t á b l á t hozunk lé t r e .

/Ez l é n y e g é b e n C odd

algoritmusának h a r m a d i k s z o r z a t n a k felel m e g . dukciós algoritmussal,

lé p é s e u t á n l é t r e j ö v ő D e s c a r t e s -

Innen az a l g o r i t m u s m e g e g y e z i k a r e ­ vagyis:/

5. A k v a n t o r o k h a t á s á n a k m e g f e l e l ő m ű v e l e t e k elvégeése. 6. P r o j e k c i ó v a l m e g k a p j u k a k i v á n t r e l á c i ó t

/miután a

pointerekkel sorokkal helyettesitettük/. Az algoritmus LIDAS

/ld.

2.1.3./

1.3.2./

ció j át példán k e r e s z t ü l m u t a t j u k be:

Az adatbázis két relációból áll. Ezek:

implementá­

109

Az ös s z e s p o z i t i v hős és az összes ü v e g h e g y e n i n n e n e l ­ helyezkedő részlegben alkalmazott

"dolgozó" n e v é n e k és

b e s o r o l á s á n a k k i v á l a s z t á s a a k ő v e t k e z ő M O D U L A /R

lekér­

dezéssel v a l ó s í t h a t ó meg: i

t< x d . n é v , d . b e s o r o l á s x> OF E A C H d IN dolgozó: ( d . b e s o r o l á s = ' p o z i t í v hős') O R SOME r IN r é s z l e g ((r.cim='az ü v e g h e g y e n innen') A N D ( d . r é s z l e g k ó d = r .részlegkód))} Az o p t i m i z á l á s program végrehajtja:

e l s ő lépését m á r a M O D U L A /R f o r d í t ó ­ az adott p r e d i k á t u m o t d i s z j u n k t l v

n o r m á l f o r m á r a hozza: {<,x d . n é v , d . b e s o r o l á s x ^ O F

E A C H d IN dolgozó:

SOME r IN r é s z l e g ( ( d . b e s o r o l á s = ' p o z i t i v hős') O R (r.cim='az ü v e g h e g y e n innen')

A N D (d. r é s z l e g k ó d = r . részlegkód))}

/Mivel d i s z j u n k t i v n o r m á l f o r m á r ó l vaui szó, sorrendje szempontjából

a müveletvégzés

t e r m é s z e t e s e n az A N D p r i o r i t á s t é l ­

vez az OR-ral s z e m b e n . / A m á s o d i k l épés

a relációk invertálása.

/M e g j e g y e z z ü k ,

hog y az i n v e r t á l á s h e l y e t t a r e l á c i ó s a d a t b á z i s inde x e i h a s z n á l h a t ó k

/ha vauinak/,

séggel nem f o g l a l k o z u n k . / i-e d i k

konjunkcióra

/T,U,i/ p á r l i s t á k

de

itt ezzel a l e h e t ő ­

A L I D A S m i n d e n T v á l t o z ó r a és

/T,i/ é r t é k l i s t á t ,

létrehozása 0

T és U v á l t o z ó n k é n t és

standard

hoz létre.

A

művelettel összekapcsolt

i k o n j u n k c i ó n k é n t történik.

/A L I D A S

ezt G y ű j t ő f á z i s n a k nevezi/. A példában

az O p t i m i z á l ó e l ő s z ö r az r - R é s z l e g e n é r ­

t e l m e z e t t - v á l t o z ó t i nvertálja. szerepel,

Az

1.

a m á s o d i k b a n k é t s z e r is.

m e r i azt a l e h e t ő s é g e t ,

konjunkcióban nem

A p r o g r a m itt

felis­

h ogy az r . c i m = ' a z ü v e g h e g y e n innen'

\

110

taghoz t a r t o z ó é r t é k l i s t a é s

a d.részlegkód=r.részlegkód

taghoz t a r t o z ó p á r l i s t a e g y e t l e n p á r l i s t á v á o l v a s z t h a t ó össze, m e l y b e n csak a z o k az lyekre m i n d a két f e l t é t e l els ő l é p é s e k é n t - a P a l e r m o

r sorok s z e r e p e l n e k m a j d , igaz.

A párlista létrehozásának

algoritmus

s z e l l e m é b e n - el

kel l k é s z í t e n i

az r. r é s z l e g k ó d s z e r i n t i é r t é k l i s t á t .

t ehát

teszi,

már úgy

szerepelteti,

értéklista

Ez

c sak a z o k a t

-

Ezt

a részlegkódokat

m e l y e k az Ü v e g h e g y e n i n n e n h e l y e z k e d n e k el,

vagyis m e l y e k r e feltétel.

hogy

me­

fennáll az

az é r t é k l i s t a

(r,2^

Részlegkód

r . c i m = ' a z ü v e g h e g y e n innen' a k ö v e t k e z ő k é p p e n néz ki:

pointer

Részleg

Részlegkód

CIC

FBI

CIA

CIC CIA

Most a d- D o l gozón é r t e l m e z e t t - v á l t o z ó k ö v e t k e z i k . e l s ő tagra

Az

/ d . b e s o r o l á s = ' p o z i t i v hős'/ é r t é k l i s t a kész ü l :

értéklista^d,l)

Besorolás

pointer

pozitiv

Dolgozó

Név Csipke

hős

Rózs i k a Hétfejü

pozitiv

Sárk á n y

hős

Gonosz Mostoha Hó F e h é r k e H é t k i s Törpe

A második ta g r a k é s z í t h e t ő az

- f e l h a s z n á l v a az

(r,d,2)

p á r lista:

(r^')

értéklistát

- el­

Ill

Dolgozó

Név Csipke Rózsika

Az i n v e r t á l á s e zzel b e f e j e z ő d ö t t .

/a LIDAS t e r m i n o l ó g i á b a n az első f á z i s / A második lépés a Kombinációs

fázis.

Ez elős z ö r az A N D k a p c s o l a t b a n álló l i s t á k k ö z ö s e l e m e i ­ nek kiválogatásából

/ g y a k o r l a t i l a g egy m e r g e / ,

igy ka p o t t l i s t á k e g y e s í t é s é b ő l

m a j d az

áll.

E s e t ü n k b e n az A N D - e k e l v é g z é s e szüksé g t e l e n , ( r,d, 2) p á r l i s t á t 1 m á r úgy é p í t e t t ü k AND viszonyban álló

az

fel, h o g y m i n d a k é t

feltétel t e l j e s ü l j ö n .

Az OR v i s z o n y ­

ban álló l i s t á k a t kel l e g y e s íteni.

Ehhez

és az ös s z e s R é s z l e g sor D e s c a r t e s

s z o r z a t á t vesszük,

ezt e g y e s i t j ü k

(r,d,2)

kusza pointerdzsungel:

párlistával.

(d,l)

értéklista

Az e r e d m é n y elég

és

112

párlista

dpointer

/Az első h a t pedig

rpointer

Részleg

sor a D e s c a r t e s - s z o r z a t ,

/ r , d , 2/ p á r l i s t a 1.

és

3. sora.

a Descartes-szorzatban szerepelt,

Részlegkód

az u t o l s ó k e t t ő A második

so r m á r

igy az e g y e s í t é s n é l

kiesett. / A Pal e r m o algoritmus nek. A S O M E /univerzális

szerint a kvantorok követ k e z ­

/ e g z i s z t e n c i á l i s kvantor/ kvantor/

osztást

/ld.

projekciót,

1.2.2./

dánkban a S O M E a p á r l i s t a d p o i n t e r - r e v a l ó jelenti.

párlista

Az

jelent.

az AL L Pél­

projekcióját

e r e dmény

dpointer Dolgozó Név___________ •----------------------- ♦ Csipke Rózsika •----------------------- ► Hétfejü Sárkány Gonosz Mostoha Hó Fehérke Hétkis Törpe

113

A L I D A S h a r m a d i k fázisa a K o n s t r u k c i ó . A p o i n t e r e k az a k t u á l i s

Eredmény

sorokra cserélődnek,

majd projekció következik

Név

Besorolás

C s i p k e RózsiTca

p o z i t i v hÖs

Hétfejü Sárkány

tüzokádó

Hó F e h é r k e

p o z i t i v hős

Hétkis

bányász

T örpe

A r e n d s z e r alko t ó i é r t é k e l é s t is a d n a k az a l g o r i t ­ musról.

Eszerint elsősorban a munkaterület minimális

szinten t a r t á s á r a v aló t ö r e k v é s m i a t t v á l a s z t o t t á k ezt az algoritmust. Második észrevételük

szerint azokra a változókra,

m e l y e k c s a k eg y k é t v á l t o z ó s ö s s z e h a s o n l í t á s b a n 0

változó2/'

szerepelnek m á r a Gyűjtő fázisban k i é r ­

t é k e l h e t ő a kvantor.

Ez a mi e s e t ü n k b e n - S O M E r, és az

r csak eg y k é t v á l t o z ó s ö s s z e h a s o n l í t á s b a n d.részlegkód/ /r,d,2/

/r.

s z e r e p e l - azt j e l e n t e t t e volna,

párlista rpointer oszlopát

e l i n t é z v e ezzel K o m b i n á c i ó s

részlegkód* h o g y az

f i g y e l m e n k i v ü l hagy v a ,

a dpointer oszlopot egyesíthettük volna val,

/változói;

fázist.

/d,l/ é r t é k l i s t á ­ A működő LIDAS

O p t i m i z á l ó v a l ó j á b a n igy c s i n á l t a volna. M é g eg y m e g j e g y z é s :

ha e g y l e k é r d e z e n d ő r e l á c i ó

fel­

t é t e l e k e t k i e l é g í t ő el e m e i a r e l á c i ó egy v é g i g o l v a s á s á val k i v á l o g a t h a t o k

/tehát pl.

ha n e m s z e r e p e l k é t v á l t o ­

zós ö s s z e h a s o n l í t á s b a n a r e l á c i ó n é r t e l m e z e t t v á l t o z ó / , a k k o r n i n c s é r t e l m e é r t é k l i s t á t kész í t e n i . az O p t i m i z á l ó

felismeri,

és egy,

l ö n b ö z ő a l g o r i t m u s t h a s znál.

E z t az e s e t e t

az itt i s m e r t e t e t t ő l k ü ­

£REBS

821

114

2.2.2.

A S m i t h - C h a n g al g o r i t m u s .

Az e r e d e t i cesszoros gépek

CSMIT 75j

számitógépeken

Optimizálójának

dicionális

c i k k az a l g o r i t m u s t t ö b b p r o ­ futó r e n d s z e r e k ,

szánta,

/Smart Q u e r y

de e t t ő l f ü g g e t l e n ü l ,

Az a l g o r i t m u s

Interface

k e z e l ő r e n d s z e r része.

tra­

Erről

a rendszerről

bázis a s s e m b l e r é p e d i g

/7.

műveletet:

korlátozást

illesztést,

jekc i ó t r e a l i z á l ó

hogy más

ábra,

eljárásokat

re t ö b b f a j t a e l j á r á s

a hipotetikus SQUIRAL

for a R e l a t i o n a l A l g e b r a /

h o g y a f e l h a sználói i n t e r f a c e

való pl.

vagy adatbázis

a r c h i t e k t ú r á j ú g é p e k e n is jól f e l h a s z n á l h a t ó

ötleteket tartalmaz.

nunk,

PRTV implementáció

elég a n n y i t t u d ­

r e l á c i ó a l g e b r a , az a d a t ­

2.1./

a három klasszikus

/kivála s z t á s t /

t artalmaz.

is r e n d e l k e z é s r e

és p r o ­

Egy-egy m ű v e l e t ­

áll,

algoritmussal érdemes

illesztendő o s z l o p o k szerint

adatbázis-

hiszen nyilván­

i l l e s z t e n i két,

r e n d e z e t t relációt,

az

és m á s k é p p

két r e n d e z e t l a n t . Az a l g o r i t m u s

elvi v á z l a t a a 14.

á b r á n látható:

/<

^transzformációk;

(Eljáráskészlet

Művelet L Adatbázis Lekérdezés — »Szintaktikus 4j Fa elemzés transzformáció konstruktőri gép H

ß

Transzformálási szabályok

14.

ábra

115

A lekérdezésből a Szintaktikus

elemzés

fát készít.

A fa levelei a l e k é r d e z é s b e n s z e r e p l ő a d a t b á z i s relációk, gyökere a válasz

reláció,

a közbülső csomópontok

az e gyes

e l v é g z e t t m ű v e l e t e k u t á n k a p o t t i d e i g l e n e s relációk. 2 . 2 . 1-ben b e m u t a t o t t p é l d á n k e g y s z e r ű s í t v e :

az ü v e g h e g y e n

innen e l h e l y e z k e d ő r é s z l e g e k b e n a l k a l m a z o t t

dolgozók ne­

v e i n e k és b e s o r o l á s a i n a k k i v á l a s z t á s a a r e l á c i ó a l g e b r a nyelvén

/I.2.2./:

JOIN DOLGOZÓ AND RÉSZLEG OVER RÉSZLEGKÓD GIVING TI S E L E C T TI W H E R E C I M = ' A Z Ü V E G H E G Y E N

INNEN'

GIVING T2

P R O J E C T T2 O V E R N É V , B E S O R O L Á S G I V I N G T3

E n n e k a m ű v e l e t s o r n a k a 15.

Jelölés: Projekció - /

\

ábra

korlátozás

15.

ábra

fája felel meg:

, illesztés

-X

116

A m á s o d i k l é p é s , a k a p o t t fa t r a n s z f o r m á l á s a k ö v e t ­ kezik.

Ez m e g h a t á r o z o t t k é s z l e t b e t a r t o z ó

transzformációk

m e g f e l e l ő s z a b á l y o k s z e r i n t i a l k a l m a z á s á v a l t ö rténik. re még v i s s z a t é r ü n k /

Ezek­

e g y e l ő r e c sak a n n y i t j e g y z ü n k meg,

h o g y e s e t ü n k b e n c é l s z e r ű n e k t űnne az i l l e s z t é s és a k i v á ­ lasztás

sorrendjét megcserélni.

E z z e l két p o n t o n is h a t á ­

rozott s e b e s s é g n ö v e k e d é s t é r n é n k el: a / c s ö k k e n n e az i l l e s z t e n d ő s o r o k r elác ióban,

száma a R é s z l e g

és ez az i l l e s z t é s n é l - a l g o r i t m u s t ó l

f üggő

mértékben - mindenképpen kedvező b/ a v á l o g a t ó a l g o r i t m u s n a k az i l l e s z t é s e r e d m é n y e ­ ként kapott,

nyilván nagyméretű reláció helyett elegendő

a Részleg r e l á c i ó n v é g i g m e n n i láció,

tehát

/ami m e l l e s l e g t á r o l t r e ­

k ö z v e t l e n e l é r é s t t á m o g a t ó indexe lehet'/.

A transzformáció eredményeként kapott ható.

16.

ábra

fa a 16.

ábrán lát­

117

Ez lesz a Fa t r a n s z f o r m á c i ó /a 14. á b r á n B - v e l jelölt/ kimenetén.

A Művelet konstruktőr

feladata a rendelkezésre

álló m ű v e l e t v é g z ő e l j á r á s o k k ö z ü l a l e g k e d v e z ő b b e k e t k i v á ­ lasztani.

C S M I T 753 a v á l a s z t á s d ö n t ő t é n y e z ő j é n e k

ció r e n d e z e t t s é g é t tartja, mozgástere

és a k i v á l a s z t á s i

l é n y e g é b e n az i d e i g l e n e s

a r elá­

algoritmus

relációk rendezettségé­

ne k m e g v á l a s z t á s a .

A Művelet konstruktőr először _ a le­ velektől a gyökérig járja be a fát, és minden r e l á c i ó m e l l é bejegyzi az un. legkedvezőbb rendezettséget. Ez n e m más, m i n t az előző művelet hatékony megvalósitása után k a p o t t rendezés. Ezek sorozata tulajdonképpen előzetes végrehajtás terv. P é l ­ dánkban tételezzük fel, hogy a Részleg a R é s z l e g k ó d , a D o l g o z ó a Név szerint rendezve van az adatbázisban. /Ezt a nyil m e l l é irt "/Részlegkód/" ill. "/Név/" jelöli a 16. ábrá n / . A k o r ­ látozásra - tegyük fel - az eljáráskészlet a reláció sze k ­ venciális végigkeresését kinálja hatékony e l j á r á s k é n t . /Le­ het ott persze indexen keresztüli hozzáférés, meg sok más is/. Ez a művelet nem változtat a rendezettségen, t e h á t a korlátozás eredményeként kapott reláció R é s z l e g k ó d szer i n t rendezett marad. Ez jól is jön n e k ü n k egy e l é g h a t é k o n y illesztéshez, mely után az eredményül kapott r e l á c i ó N é v szerint rendezve lesz. Az első menet tehát a legkedvezőbb rendezettségek ki­ osztása. Lehet persze több kedvező rendezettség isfilyenkor valamennyit fel kell tüntetni. CSMIT 753 - egy ott de­ finiált eljáráskészlet alapján - táblázatban adja meg a ren­ dezettségek kiosztásának szabályait. A második menet a gyökértől a levelekig járja be a fát. Ennek feladata olyan esetekben döntést hozni, amikor több kedvező rendezés is létezik. Ez a döntés a műveletet végrehajtó eljárások legkedvezőbbjét választja meg - meg­ határozva ezzel a rendezettséget is. Esetünkben nincs

118

választási

lehet ő s é g ,

d e a 17.

á b r á n e r r e is l á t h a t u n k

példát:

A fiktiv R 1#R 2 és

r e l á c i ó k r a h a j t j u k v é g r e a 17.

ábrán l á t h a t ó m ű v e l e t s o r t . tőr első, /b-n

a b/-n a m á s o d i k menete utáni

mindegyik lépéshez

eljá r á s nevé t / . rendezetlen.

álla p o t

látható

odaírhattuk volna a kiválasztott

reláció A , R 2 D szerint rendezett,

E n n e k m e g f e l e l ő e n a l a k u l n a k a 1 7 . a,

rendezettségek.

/Például

nál m i n d e n k é p p e n le k e l l A, B és C szerint, rendezési

Az a/ á b r á n a M ű v e l e t k o n s t r u k ­

sorrend:

ábrán a

az R 2 r e l á c i ó els ő p r o j e k c i ó j á ­ rendezni a relációt a három oszlop

de m e g v á l a s z t h a t ó , ABC,

R^

hogy milyen

le g y e n a

BAC vagy C B A - a többi n e m é r d e k e s -

és e zzel a k i m e n ő r e l á c i ó r e n d e z e t t s é g e / . A második

bejárás

utáni e r e d m é n y t m u t a t j a a b á b ­

ra. Az u t o l s ó n a k v é g r e h a j t a n d ó p r o j e k c i ó h o z n y i l v á n az in­ put G s z e r i n t i

rendezettsége

a k e d vező - hiszen G azon

119

o s z l o p o k egyike, m e l y e k r e p r o j e k t á l u n k . n e t é n e k G s z e r i n t rendezettnek kell G szerint rendezettségét

Az i l l e s z t é s k i m e ­

l e n n i e - ez a bemenet

is m e g h a t á r o z z a ,

A PRTV rendszerben használt

/Id.

s.i.t. C S M I T 753.

0.2./.

t e c h n i k á t i s m e r t e t ő C H A L L 763 cikk C S M I T

optimizálási

7 5 3 -bői két n a ­

g y o n fontos ö t l e t e t - a f a - t r a n s z f o r m á c i ó m á r o t t nem t e l j e s e n á l t a l á n o s a n m e g a d o t t /

/noha

a l a p e l v é t v e s z i át és

finomitj a:

a/ a k o r l á t o z á s o k ö s s z e v o n á s a e g y e t l e n k o r l á t o z á s s á b / az u n á r i s m ű v e l e t e k m i n é l k o r á b b i e l v é g z é s é r e v a l ó t örek v é s T u l a j d o n k é p p e n elég n y i l v á n v a l ó m i n d a ké t elv: r int n e m é r d e m e s a n n y i s z o r v é g i g m e n n i

a / elv s z e ­

egy r e láción*

k ü l ö n b ö z ő f e l tétel v a n az egyes t a g okra,

ahány

célszerűbb egyszer

!

b e o l v a s n i a relációt, f e l t é t e l t e l j esülését.

és e g y s z e r r e e l l e n ő r i z n i

az összes

A b, elv m e l l e t t n y i l v á n v a l ó a n a

relációméretek minél korábbi csökkentése p é l d á n is l á t t u k az előnyeit/.

szól.

/A korábbi

E z e k e t az e l v e k e t

HALL 76

á t f o g a l m a z z a és k i e g é s z í t i : a / a korlátozásokat minél korábban kell

elvégezni

b / a p r o j e k c i ó s o r o z a t o k a t ö s s z e kell v o n n i c / fel kell ismerni, veleteket az d/

/pl.

és k i s z ű r n i

a felesleges mű­

n y i l v á n v a l ó a n n e m é r d e m e s elvégezni

/AUB/-/BUA/ m ű v e l e t s o r t /

a t ö b b h e l y e n s z e r e p l ő t a g o k a t e g y s z e r kell e l ő á l l í ­ tani .

Vizsgáljuk meg sorban ezeket az elveket! Az a /-hoz r ö g t ö n m e g kell jegyezni, h o g y á l i s n a k tűnik,

v a l ó j á b a n n e m az.

Az

i l l e s z t é s és k o r l á t o -

zás s o r r e n d j é n e k m e g c s e r é l é s e k ö r ü l t e k i n t é s t daképpen megemlítjük, d e z é s n e k n em

n oha t r i v i ­

igényel.

I

Pél­

h o g y ha a 2 . 2 . 1 . - b e n s z e r e p l ő l e k é r ­

az e g y s z e r ű s í t e t t * h a n e m az e r e d e t i v á l t o z a t á t

120

- p o z i t í v hö s ö k , és az ü v e g h e g y e n

innen elhelyezkedő rész­

l e g e k b e n a l k a l m a z o t t d o l g o z ó k nevei és b e s o r o l á s a i - k í s é ­ re l j ü k m e g o p t i m i z á l n i , tés és a k i v á l a s z t á s o k

n y i l v á n v a l ó a n n e m t u d n á n k az i l l e s z ­ sorrendjét megcserélni.

PRTV Optimizálóról Írva tés és a k o r l á t o z á s sával t ö r t é n i k egyik,

megjegyzi,

h o g y á l t a l á b a n az i l l e s z ­

felcserélése a korlátozás

/már a m i k o r ez m e g t e h e t ő / .

a másik a másik

C T O D D 76] a

részekre vágá­

Az e g y i k rész az

i n p u t relác i ó n h a j t h a t ó végre,

h a r m a d i k r é s z t maga az

illesztés realizál,

egy

a negyediket pe­

dig az i l l e s z t é s e r e d m é n y é n kell elvég e z n i . A m á s i k probléma,

h o g y nem m i n d i g é r d e m e s a k o r l á t o ­

zást k o r á n v é g r e h a j t a n i .

Például,

láció e g y e s í t é s é t c s e r é l j ü k tozással,

ha k é t n e m d i s z j u n k t r e ­

fel csak g y e n g é n s z ű r ő k o r l á ­

rosszabbul járhatunk, mintha

az e g y e s í t é s

ered­

ményén hajtanánk végre korlátozást. A b, jelent,

e l v h e l y e s s é g e nyi l v á n v a l ó .

A projekció rendezést

- a d u p l i k á t u m o k k i s z ű r é s e - és

rendezni,

m i n t többször.

egy m á s i k k a l

jobb c s a k egys z e r

A g y a k o r l a t b a n e g y é b k é n t ez az elv

egészül ki:

a r e n d e z é s t i g é n y l ő p r o j e k c i ó t m i n é l később, a r e n d e z é s t n e m i g é n y l ő t minél e l ő b b kell v é g r e h a j t a n i CTODD

76]. Ac,

és

d, p o n t o k m e g v a l ó s í t á s a i g e n s z e m l é l e t e s

formációsorozattal történik. f e j e z é s e k a 15.

ábrán

/AUB/-/BUA/UB ki­

á b r á r a e m l é k e z t e t ő fa á b r á z o l á s a

A b, á b r á n ö s s z e v o n t u n k v a ezzel a fát,

A 18.

A b-bol

hogy A k é t s z e r B p e d i g h á ­

a c, á b r á b a a m ű v e l e t i

g á l a t a r é v é n j u t h a t u n k - m i n d a két m ű v e l e t i B-vel v a n ö s s z e k ö t v e , elég e g y s z e r képzelhető,

c,

létreh o z n i ,

ábráról m á r l á t ható, és k é t s z e r

olyan algoritmus,

jelhez a k é t o p e r a n d u s

látható.

e g y - e g y c s ú c s b a A - t és B - t e l r o n t ­

de é s z r e v é v e ,

roms z o r sze r e p e l .

transz­

jel A - v a l és hogy AUB-t

felhasználni

amely tudja,

azonos csomópontból

jelek v i z s ­

azt,

- sót e l ­ h o g y ha a

fut be,

a k k o r ez

121

a rész e g y s z e r ű e n elhagyható.

-

/A P R T V O p t i m i z á l ó C H A L L

u

rint ilyen a l g o r i t m u s /

a/

A

A.

B B

C S M I T 75, H A L L

2.2.3.

76,

b

18.

TODD

76].

ábra

A s t r a h a n és C h a m b e r l i n T I D a l g o r i t m u s a

Ez az a l g o r i t m u s SEQUEL age/

7 6 ] sze

/Id.

0.2./

/Structured English QUery La n g u ­

l e k é r d e z é s e k i n t e r p r e t á l á s á r a készü l t .

Ké t

lényeges k ö r ü l m é n y b e f o l y á s o l t a m ű k ö d é s é n e k f i l o z ó f i á j á t : 1.

A S E Q U E L n y e l v - az SQL

t á m o g a t t a az

" i l l e sztés"

A következő

v á l o g a t j a ki 2.2.1.

leké r d e z é s a z o k n a k a d o l g o z ó k n a k a n e v é t rész D o l g o z ó

SEQUEL: SELECT NÉV FROM D IN DOLGOZő WHERE ALAPBÉR > SELECT ALAPBÉR FROM DOLGOZÓ SQL:

helyettük

/az S Q L - b e n m i n d a k e t t ő l é ­

küknél m a g a s a b b a l a p b é r t kapnak:

VIIIT’T

1.2.3./ e l ő d j e - n e m

ti p u s u l e k é r d e z é s e k e t ,

a "r é s z l e k é r d e z é s t " a j á n l o t t a tezik/.

/ld.

VTyf"'T=B

relációjából,

akik a főnö­

122

SELECT D.NÉV FROM DOLGOZÓ D, DOLGOZÓ F WHERE F .NÉV=D.FŐNÖK AND D.ALAPBÉR> F.ALAPBÉR /Id. 1.2.2.c/. Megjegyezzük mellesleg, hogy SEQUEL-ben nem tudnánk a dolgozó nevével együtt a főnökét is előszedni, mint azt SQL-ben 1.2.3.c.-ben tettük. 2. A SEQUEL realizálása XRM-en /ld.0.2./ alapult. En­ nek jellegzetessége, hogy külön tárolja az adatmezők értéke­ it, és külön a relációs sorokat, mint az értékekre mutató pointer n-eseket. Ebből adódott, hogy a rendszer készitoi arra törekedtek, hogy a válogatásnál minél kevesebb sort kelljen megvizsgálni. Ehelyett inkább igyekeztek maximáli­ san kihasználni az indextáblázatokat, és azok alapján felé­ pített, a válasz szempontjából szóba jöhető sorok XRM belső azonosítóit /tuple identifier - TID/ tartalmazó listákkal manipuláltak. CCHAM 811. Az algoritmus három program együttese. A. LALR/k/ tipusu Szintaktikus elemző /Parser/ a SEQUEL utasításokat ismeri fel, és alakítja át. Bennünket most elősorban a legbonyolultabb rész a WHERE ábrázolása érdekel. Minden WHERE feltételből egy fa lesz, melynek levelei az elemi feltételek, gyökere a válasz, egyes ágai pedig a feltéte­ leket összekötő OR ill. AND műveletek. Ebben a paragrafusban néhány példán keresztül vizsgáljuk az algoritmus működését 2.2.1. adatbázisán. Az első: SELECT x FROM DOLGOZÓ WHERE BESOROLÁSÉ POZITÍV HÓS' AND /NÉV='HÉTFEJÜ SÁRKÁNY' OR RÉSZLEGKÓD='FBI'/

123

Ez azok n a k a p o z i t i v h ő s ö k n e k az a d a t a i t Írja az F B I - n a k d o l g o z n a k , A W H E R E fája a 19.

ki, akik vagy

v a g y H é t f e j ü S á r k á n y n a k hivják

okét.

á b r á n látható.

A m á s o d i k p é l d a m e g e g y e z i k az 2 . 2 . 1 . - b e n t á r g y alttal: Az öss z e s p o z i t i v hő s és az ü v e g h e g y e n i nnen m e g t a l á l h a t ó

rész­

l e g e k b e n a l k a l m a z o t t v a l a m e n n y i d o l g o z ó n eve és b e s o r o l á s a Í r a n d ó ki:

SELECT N É V , B E S O R O L Á S FROM DOLGOZÓ W H E R E B E S O R O L Á S = *P O Z I T Í V HŐS'

O R RÉSZLEGKÓD IN

SELECT RÉSZLEGKÓD FROM RÉSZLEG

WHERE CIM='AZ ÜVEGHEGYEN INNEN' Ehhez

a lekérdezéshez

a Szintaktikus

a két W H E R E - n e k m e g f e l e l ő e n

e l e m z ő két fát g e n e r á l

/20,ábra/,

és v a l a m i l y e n m ó d o n

jelzi a ké t W H E R E b e á g y a z o t t s á g i v i s z o n y á t . Az a l g o r i t m u s t a l k o t ó m á s i k k é t ö n á l l ó egység az O p t i mizáló

/Optimizer/

és a V á l o g a t ó

/Scanner/.

Mig a Szintakti­

kus E l e m z ő a fák e l ő á l l í t á s á v a l b e f e j e z t e tevéken y s é g é t , a két p r o g r a m r é s z

ez

a t o v á b b i a k b a n e g y m á s t és re k u r z i v e s a j á t

m a g u k a t h í v o g a t v a e lég b o n y o l u l t v e z é r l é s i

szerkezetben

több­

ször is fut.

Az Optimizáló feladata a kérdés megválaszolásához b e ­ olvasható sorok minimizálása. Ezt indexek segítségével é s azonosító /TID/ listák egyesítésével, és metszésével éri el. T e r m é s z e t e s e n a k i í r á s h o z - ha n e m e l ő b b - m i n d e n k é p p e n szük s é g v a n a t é n y l e g e s ki az adatb á z i s b ó l .

sorokra.

Ezeket a Válogató választja

U g y a n c s a k az ő f e l a d a t a a f e l t é t e l e k n e k

e l e g e t tevő s o r o k b ó l p r o j e k c i ó v a l k i v á l a s z t a n i a k i í r a n d ó elemeket.

A Válogató

f e l a d a t a az O p t i m i z á l ó h o z képest e l é g

egyszerű,

igy a t o v á b b i a k b a n c s a k h i v a t k o z n i

fogunk rá.

Az O p t i m i z á l ó m ű k ö d é s é t h á r o m l é p é s b e n ismertetjük: A / A vizsgálj osztályozása:

W H E R E - b e n s z e r e p l ő elemi

felt é t e l e k

124

A legegyszerűbb tipust lé t e z ő i n d e x

P l - g y e l jelöljük.

alapján azonnal

g í t ő sorok a z o n o s í t ó i n a k

leg-hez p e d i g

Példa a d a t b á z i s u n k b a n lé­

i n d e x N é v és R é s z l e g k ó d ,

Részlegkód szerint!

E kkor a 19.

lő f e l t é t e l e k k özül a " N É V = H É T F E J Ü SÁRKÁNY" FBI" nyilván

Pl

tipusuak. Megjegyezzük,

feltételek egyváltozósak. be véve ez a z t

jelenti,

jától f ü g g e t l e n . /lista/

tipusu

hogy

A

ugyanis

20.

megoldásukhoz

20.

ábra

felté­

h o g y külső

és ez itt t e l j e s ü l . /

l é t e z i k index, I l y e n a 19.

figyelem­

többi W H E R E b l o k k ­

/csu p á n az szükséges,

feltételek is

v a n szükség.

"RÉSZLEGKÓD*

" R É S Z L E G K Ó D IN"

t í p u s b a sorolt

ez e k r e ne m

szerep­

jelenti a v á l t o z ó = k o n s t a n s

ábra

b l o k k r a ne h i v a t k o z z o n a f e l t é t e l , A P2

és a

a Rész-

h o g y a Pl t i p u s u

a lekérdezés

Ez ne m f e l t é t l e n ü l

tele is Pl t i p u s u ,

ábrán

A SEQUEL szintaktikáját

feltételt.

hogy

előállítható a feltételt kielé­

listája.

t e z z e n a D o l g o z ó relá c i ó h o z

Ez ol y a n ,

függetlenek,

csak

a Válogató hivására

"B E S O R O L Á S = P 0 Z I T I V HŐS "

ábra " B E S 0 R 0 L Á S = P 0 Z 1 T I V HŐS"

és

"CIM=AZ Ü V E G H E G Y E N

és a INNEN"

feltételei. A P3 dex,

tipusu feltételnél

a bal o l d a l i v á l t o z ó r a v a n in­

de a j o b b olda l o n k ü l s ő b l o k k r a t ö r t é n i k h i v a t k o z á s .

Ilyen s z e r e p e l

harmadik p é l d á n k b a n ,

g e k n e k a k ó d j a i t v á l o g a t j a ki,

mely azoknak a részle­

m e l y e k több d o l g o z ó t

is fog­

lalkoztatnak : SE L E C T R É S Z L E G K Ó D FRO M R

IN

WHERE

1<

RÉSZLEG

SELECT C OUNTCx ) F R O M DOLG O Z Ó WHERE RÉSZLEGKÓD=R.RÉSZLEGKÓD Itt a " R É S Z L E G K Ó D = R . R É S Z L E G K Ó D "

f e l t é t e l P3 tipusu,

hiszen

a R é s z l e g k ó d o s z l o p s z e r i n t v a n index a D o l g o z ó relációban. A P3 tipusu

feltételek

nált jellemzője,

lényeges,

az a l g o r i t m u s b a n k i h a s z ­

hogy a j o b b o l d a l

adott értéke m e l lett a

125

feltétel az index alapján azonnal kiértékelhető. A P_4 tipusu feltétel annyival rosszabb a P3 tipusunál, hogy nem létezik rá index, de annyival jobb a P5 tipusunál, hogy érdemes létrehozni

ugyanis létezése csökkenti a be­

olvasandó sorok számát. Harmadik számú példánkban, ha nem lenne index a Részlegkód szerint, érdemes lenne létrehozni azt. Az történik ugyanis, hogy a magasabb szintű blokkban sorra veszi majd elő a részlegkódokat és adja tovább a beágyazott blokknak a részlegben dolgozók számának elokeritésére /rekurzive hiva önmagát/. Ha nincs index Részlegkód szerint, a blokkban minden adott részlegkódra végig kell menni a Dolgozó reláción, viszont i'ha egyszer létrehozzuk azt, attól kezdve már használható. Az index létrehozásával a P4 tipusu feltételből P3 tipusu lesz. A P5 tipusu feltételre nem is érdemes indexet létre­ hozni, mert az nem csökkentené a beolvasandó sorok számát. Ilyen lenne a "RÉSZLEGKÓD=R.RÉSZLEGKÓD" feltétel is a har­ madik példában, ha nem COUNT, hanem pl. SUM(ALAPBÉR) szerepelne a beágyazott SELECT-ben. Az Optimizáló A/ lépése tehát a fenti módon osztályoz­ za a feltételeket a külső blokkban, majd a beágyazottban is. A külső blokkban mindenesetre csak Pl és P2 tipusu felté­ telek vannak, hiszen nem tartalmazhat hozzá képest külső blokkra hivatkozásokat - mivel ilyenek nincsenek. így az Op­ timizáló B/ lépése következik - P3, P4 vagy P5 predikátumot tartalmazó blokkoknál ehelyett a C-re kerül sor, mint azt látni fogjuk. B/ Ennek a lépésnek az első feladata /Bl/ annak megállapitása, hogy a blokkban szereplő Pl feltételek m e n n y i r e képesek a beolvasandó sorok számát csökkenteni. A fa minden csomópontjához hozzárendeljük az indexből megoldható, a beolvasandó sorok számát korlátozó feltételek P listáját az alábbi módon: a/ a fa leveleinél Fx = feltétel Pl, PX = n u l l P2 tiousu

126

feltétel esetében. b / AND csomópontra PX=PX .LÜPX,R, ahol PX .L a bal, PX .R a jobb oldali leszármazott P listája. c/ OR csomópontra, ha PX .L vagy PX .R=null, akkor Px=null

egyébként PX=PX .LUPX .R

19. ábra A 19. ábrán látható első példán részletesebben meg­ nézzük a Px listák képzését: Először a levelekhez állít­ juk össze a listát aszerint, hogy Pl vagy P2 tipusu a feltétel. Mivel az OR egyik leszármazottja sem null, a P listája a két vagy - kapcsolatban álló feltétel lesz. Az AND listája megegyezik az OR csomópontéval, hiszen az avval AND kapcsolatban álló másik feltétel P2 tipusu, igy a listája null. Ezzel a lépéssel tulajdonképpen a feltételek pozícióját értékeltük. Hiába van index ugyanis egy feltételre, ha az

1 27

vagy-kapcsolatban áll egy P2 tipusuval. Ahhoz, hogy ezt a vagy-feltételt kielégito sorokat megkapjuk, mindenképpen végig kell menni a reláción a P2 tipusu feltétel miatt, és ilyenkor nyilván nem érdemes a másik tagra indextáblát használni. A B/ lépés következő feladata /B2/ válasz szempontjából szóba jüheto sorok azonosítóinak kiválogatása minden csomó­ pontra. Az azonositólista mellett minden csomópont indexet is kap, ez jelzi, hogy a csomópontban lévő lista mit jelent. M

/megoldott/ az index, ha a csomópontra pontosan ismerjük

azokat a sorokat /azonosítóikat/, melyek eleget tesznek a csomópont képviselte feltételnek. T /talán/ az index, ha pon­ tos azonositólistánk nincs ugyan, de van egy olyan listánk, mely biztos tartalmazza az összes megfelelő sor azonosítóját, de bővebb is annál, P2 tipusu feltételek miatt ezek az azonositók meg ellenőrzésre szorulnak. N indexet kap a P =null listáju csomópont. Az indexek és a listák készítése a levelekre nyilván­ való: Px=null listáju levél N indexű; PK=feltétel listáju levél M indexű, az azonositólistát az indextáblából kapjuk. A többi csomópontra a közvetlen leszármazottak határozzák meg a listát. AND csomópontra:

m

TCL2)

(L2)

m (li )

M(Llf\ L2)

t (li )

t (l i O

N

t (l 2)

OF- csomópontra:

L2)

T (l IO L2) T (LIO L2) T (L2)

N t (li ) t (li )

N

128

M(L2) M (Li) t (li )

N

ahol L1 és L2

M (l 1ÜL2) t (li\Jl 2) N

T(L2)

N

T (l 1UL2)

N N N

T (L1ÜL2) N

a két leszármazott azonositólistája, M,T és

N pedig az indexeik. Első példánknál a "NÉV=HÉTFEJÜ SÁRKÁNY" feltételnek a Dolgozó reláció második sora tesz eleget /A2 azonosító/, a "RÉSZLEGKÓD=FBI"-nak az első és harmadik. Ezzel a két listával a vagy-feltételre "pontos" /csak a feltételnek eleget tevő sorok azonosítóit tartalmazó/ listát kaptunk, igy az OR csomópont indexe M, listája pedig a két lista egyesítése. Az AND csomópont, mivel a Besorolásról nincs index T cimkét kap /eddig biztosan jó soraink bizonyta­ lanná válnak, lehet, hogy ezekben a sorokban a Besorolás nem mindenütt "pozitív hős"/, az azonositólista változat­ lan /azért afelől nyugodtak lehetünk, hogy ezeken kívül más sorok nem jöhetnek szóba/.. Nézzük meg második példánkat is /20. ábra/! a/

b/

besorolás=pozitiv hős P2 /N /

részlegkód in Pl

ín/

20. ábra

cim=az üveghegyen innen P2 /n /

1 29

/Az Optimizáló a belső blokkra is elvégezte a B1-B2 lépé­ seket /ugyanis csak egy P2 tipusu feltételt tartalmaz/. Észrevehetjük, hogy a "RÉSZLEGKÓD"-ra vonatkozó feltétel, noha Pl tipusu, mégis N cimkét kapott. OR tipusu csomó­ pontnál ugyanis, ha a csomópont cimkéje N lesz, a leszár- . mazottakat is át kell cimkézni, hiszen nem érdemes azonositólistát késziteni hozzájuk. Feltételezzük - nem talál­ tunk rá pontos utalást - hogy a program igy is tesz. A B lépés utolsó feladata B3 következik: a Válogató hivásával be kell olvasni a sorokat, és kiválogatni közü­ lük a feltételeknek eleget tevőket. Ez azonositólistáink segítségével történik. A fa gyökerétől indulunk el. Ha a gyökér cimkéje M, készen is vagyunk, az azonositólistán szereplő azonositóju sorokat a Válogató beolvassa, a megfelelő elemeket kiirja. Ha a gyökér cimkéje N vagy T, akkor az azonositólistán sze­ replő azonositóju sorokat /N esetében az egész relációt/ be kell olvasni, és a sorokat ellenőrizni, lefelé haladva a fán: a/ T vagy N cimkéjü csomópontban, ha van leszármazott, rekurziv hivással meg kell nézni a két leszármazottat. Azt, hogy a csomópont képviselte feltételt kielégiti-e a sor, a leszármazottak vizsgálatából kapott értékek konjunkciója ill. diszjunkciója dönti el a feltétel tipusától függően. b / M cimkéjü csomópontnál egyszerűen meg kell nézni, hogy az éppen vizsgált azonosító benne van-e az azonositólistában. /Ez hatékony XRM művelet/. c/ N cimkéjü leveleknél az azonositó meghatározta sor feltételben szereplő elemét be kell olvasni, és ellenőrizni a feltétel teljesülését. Első példánkban /19. ábra/ csak az Al azonositóju sor­ ban lesz a gyökérnél lévő listán szereplő azonositóju sorok közül a Besorolás éppen "pozitiv hős", igy ez az egy sor a megfelelő. Ezzel az első példában feltett kérdés választ nyert.

130

A második példában a gyökér címkéje N, tehát soronként megy végig a reláción. Az első sornál a Besorolás értéke éppen "pozitív hős", igy ezt a sort - lévén a gyökérben OR el is fogadja a program. A második sornál a Besorolás ér­ téke nem megfelelő, igy a másik ág, az összetett feltétel vizsgálata következik. A Válogató ezen a ponton rekurzive meghivja saját ma­ gát. Ezt annak megfelelően teszi, hogy a beágyazott blokk­ ban a Bl és B2 lépések megvoltak, most B3 - a Válogató hivása - következik. A Részleg reláció átfésülése - a P2 fel­ tétel megoldása - eredményeként egy listát ad, melyen az Üveghegyen innen elhelyezkedő részlegek nevei /CIC,CIA/ szerepelnek. Ezzel a probléma ekvivalenssé vált a SELECT NÉV,BESOROLÁS FROM DOLGOZÓ WHERE BES0R0LÁS='POZITÍV HŐS' AND RÉSZLEGKÓD IN /CIC,CIA/ lekérdezéssel. A Válogató rekurzive hivott példánya befe­ jezi működését. Az eredeti Válogató a külső blokk kiértékelését foly­ tatva a második sorban lévő részlegkódot ellenőrzi, és mi­ vel az szerepel a listán, elfogadja. A harmadik sor érté­ kelésénél a Besorolás nem jó, a Részlegkód sem szerepel a listán, tehát azt elveti, de a negyediket és Ötödiket el­ fogadj a . Nézzük most meg a harmadik példát /21. ábra/!

hl

a/ 1^

RÉSZLEGKÓD=R.RÉSZLEGKÓD P3,/pr : részlegkód=részlegkód /

P2,/pX=null/ /n / 21. ábra

131

Az a/ ábra a külső blokk, egy P2 tipusu feltétel, A B1 és B2 lépés végrehajtásának eredménye az ábráról leolvasható. Mivel a belső blokk P3 tipusu feltételt tartalmaz az Optimizáló B/ lépése helyett erre a C/ hajtódik végre a követ­ kezőképpen : C/ Ez a lépés arra készült fel, hogy a P3, P4,P5 ti­ pusu feltételek miatt a blokk nem oldható meg egy hivással* A feldolgozási stratégia szerint a magasabb szintű blokk feldolgozásakor a B3 lépésben amikor a sorok értékelése van hátra, minden egyes sorra meg kell vizsgálni a beágyazott blokkot. Ilyenkor a magasabb szintű blokk átadja az éppen vizsgált sorból azokat az értékeket, melyre a beágyazott értékeléséhez^ szükség van - jelen esetben a Részlegkódot, az első hivásra "FBI"-t, másodikra "CIC"-t, harmadikra "CIA"-t Az Optimizáló igyekszik előkészíteni a további hívások­ ra a blokkot: a/ a blokk Pl és P2 tipusu feltételeinek azonnali ki­ értékelésével /létrehozva a feltételeknek megfelelő sorok azonosítóját/ b/ a P4 tipusu feltételek P3 tipusuvá alakításával /index létrehozása/ Az előkészítés menete nagyjából a B1-B2 lépések algo­ ritmusai szerint történik. Első lépés annak megállapitása, hogy melyek a beolvasandó sorok számát korlátozandó felté­ telek. Ez B1 algoritmus szerint történik, azzal a különb­ séggel, hogy a Pl tipusu feltételek mellett most már a P 2 , P3, és P4 tipusu feltételek is értékesek számunkra, /a többszöri kiértékelés miatt/ igy a P5 feltételekre lesz csak Px=null, a többi levélnél Px=feltétel. A levelek Px listái után a csomópontokra B1 algoritmus állitja elő a P listákat. A következő lépésben a Px listák alapján B2 algoritmusával

13 2

címkézzük meg a csomópontokat, és egyúttal létrehozzuk az azonositólistákat is. Itt a következő különbségekre hivjuk fel a figyelmet: a/ A P2 tipusu feltételek is kiértékelésre kerülnek, egy speciális válogatás Jétrehozza az azonosítójukat b/ Ha valamelyik Pl vagy P2 tipusu feltétel beágyazott blokkot tartalmaz ennek a blokknak a megoldása rekurziv hí­ vással megkezdődik c / A P3 és P4 tipusu feltételeket általában nem tudjuk megoldani, de a P4-re létrejön az indextábla ezzel P3-má alakitva azt. Lássuk most a B3 lépést a külső blokkra! A Válogató az első részlegkódot próbálja /"FBI"/- Az összetett fel­ tétel értékeléséhez rekurzive hivja önmagát a belső bokkra. Itt a P3 tipusu feltétel "RÉSZLEGKÓD=FBI"-já alakul át, igy Pl tipusuként az indextáblából - egy előkészítő lépéssel - megkapja az azonositólistát /Al,A3/. A sorok számát kell visszaadni csupán /COUNT/ igy nincs szükség a sorok olvasására, a visszaadandó érték 2. A második Válogató példány befejezi működését, az eredeti pedig el­ fogadja az "FBI"-t, mint a megoldás reláció egy sorát. Másodiknak a "CIC"-vel hivja önmagát a Válogató. Az azonositólista egy elemből /A5/ áll, igy ez elvetendő. A harmadik hivás a megoldás relációhoz csatolja a "CIA"-t is. CASTR 753 Az algoritmust elemezve, a System R történetét átfo­ gó és ismertető ÜCHAM 813 cikk megállapítja, hogy: 1.

Az Optimizálónak nem csak a sorok olvasásának költ­

ségét kell figyelembe vennie, hanem az azonositólisták lét­ rehozásával és manipulálásával keletkező veszteségeket is. Ezek elég tekintélyesek lehetnek.

1 33

2. Mértéknek a "beolvasott sorok száma" helyett az I/0-müveletek száma is a CPU-ido súlyozott összege meg­ felelőbb mutató lenne. 3. Drága megoldás külön tárolni az adatmezők értékét, és külön a rájuk mutató pointerek alkotta sorokat - noha. az XRM védelmében meg kell jegyezni, hogy hosszú adatmező­ értékeknél ez a megoldás előnyökkel jár. 4. A "részlekérdezés" mellett be kell vezetni az "il­ lesztés" lekérdezést is. Az Optimizáló szempontjából ennek szimmetriája jobb optimizálási stratégiához vezethet. 5. Nagyobb súlyt kell fektetni a sűrűn előforduló egy­ szerűbb kérdések hatékony optimizálására. CCHAM 8l3 szerint a fenti algoritmus túlzottan komplex lekérdezés-orientált.

2.2.4.

Az INGRES-ben használt dekompoziciós algoritmus

A módszert a következő példán mutatjuk be: Válogassuk ki azoknak a pozitiv hősöknek, és főnöküknek nevét, akik az Üveghegyen innen dolgoznak, és alapbérük nagyobb, mint a főnöküké. RANGE OF RANGE OF RANGE OF RETRIEVE WHERE

D IS DOLGOZÓ F IS DOLGOZÓ R IS RÉSZLEG (D.NÉV,F.NÉV) D .FÖNÖK=F.NÉV AND D.RÉSZLEGKÓD=R.RÉSZLEGKÓD AND d .b e s o r o l A s ='p o z i t í v h ő s ' a n d R.CIM='AZ ÜVEGHEGYEN INNEN' AND D.ALAPBÉR> F.ALAPBÉR

A dekompoziciós algoritmus leirása két cikkben - CSTON 76j és í WONG 76l - is megtalálható, és a két változat lényegesen

134

különbözik. Mi először a tökéletesebb CWONG 76]- féle vál­ tozatot vizsgáljuk, majd a két változat különbségéről szó­ lunk. Az alapgondolat mind a két dolgozatban közös: a több­ változós, bonyolult lekérdezéseket egyváltozósak sorozatára kellene lebontani. Ennek a nyilvánvaló módszernek - vala­ mennyi optimizálási algoritmusnak ez a célja - a megvalósí­ tására két eljárást javasolnak: 1. Helyettesités /tuple substitution/: Tetszőleges nváltozós Q lekérdezés /n-1/-változösak sorozatára bontható oly módon, hogy egyik változóját sorban egymás után kicse­ réljük a változó értelmezési tartományaként szolgáló relá­ ció soraival: Q(X1 ,X2,...,Xn) -* ÍQ*' (X2 ,X3,...,Xn]

R-^

Látható, hogy n-1 darab helyettesítéssel önmagában elérhető a cél, a dolognak csak az a szépséghibája, hogy ez nem más, mint a Codd-féle redukciós algoritmus /0.2./ Descartes-szorzata, és gyakorlatilag megvalósíthatatlan. 2. Leválasztás

/detachment/: Ez a lekérdezés olyan Q'

és Q'' lekérdezések sorozatára bontását jelenti, melyek­ nek csak egy közös változójuk van. Példánk lekérdezése nyilván felbontható pl. igy: RANGE OF D IS DOLGOZÓ RETRIEVE INTO POZITIV_HŐSÖK (D .NÉV,D .FŐNÖK,D.ALAPBÉR^ WHERE D .BESOROLÁS='POZITÍV HŐS' RANGE OF D IS POZITIV_HŐSöK RANGE OF F IS DOLGOZÓ

RANGE OF R IS RÉSZLEG RETRIEVE (d .NÉV,F.NÉV) WHERE D .FÖNÖK=F.NÉV

AND

D.RÉSZLEGKÓD=R.RÉSZLEGKÓD AND R.CIM='AZ ÜVEGHEGYEN INNEN7 AND D .ALAPBÉR > F .ALAPBÉR A két eljárást megvizsgálva látható, hogy a leválasz­ tás általában olcsóbb, mint a helyettesités. Esetünkben az ötsoros Dolgozó relációból hármat kiszűr az első lekérdezés, lényeges megtakarítást eredményezve a második lekérdezésben, ha azt ezek után pl. tisztán helyettesítésekkel kivánjuk megoldani. Ez önmagában véve persze nem döntő, előfordul­ hatott volna, hogy az első lekérdezés egyetlen sort sem szűr ki. A másik - ennél érdekesebb - probléma az, hogy hogyan érdemes két részlekérdezésre bontani egy lekérde­ zést. Nyilvánvaló az is, hogy általában csak leválasztás­ sal nem lehet egyváltozós lekérdezésekre visszavezetni egy lekérdezést, szükség lesz helyettesitésre is. A két emlitett dolgozat az optimális szétválasztások meghatározásának módszerében különbözik. LWONG 76^ algorit­ musa négy lépést tartalmaz: a/ A redukció /reduction/ feladata a lekérdezés kom­ ponensekre bontása vagyis a leválasztások megállapitása. Ennek az algoritmusnak ismertetéséhez néhány fogalmat kell bevezetni: Legyen Q a RANGE OF (xi ,x2 , ... ,Xn) IS ^ RETRIEVE T(X,,X0,...,X ' í z m) WHERE B"(X1 ,X2,...,XJ AND

,R2 ,. . .,Rn)

1 36

általános lekérdezés! X,,...,X 1 n ciókon definiáltak, és X ^ , ...,X^

Változók R,.....R relá1 n változóknak a speciális

alakú feltételeknek - B" AND B' - eleget tevő sorait, ill. ezeknek egyes elemeit kivánjuk kiválogatni/. Kézenfekvő Q-t két komponensre bontani. Az első g/ : HANGE OF (Xm ,Xm+1.... IS

....

RETRIEVE INTO R' ( t 'Cx }) m m WHERE B'(Xm ,Xm+1.... X j Itt T#(x ") a második, Q" komponensnek szükséges információ. Q" a következő lekérdezés: RANGE OF ( X,-L,X„,...,X /L iti) IS (rx. ,Rz ,...,R' m ) RETRIEVE

t

(Xt ,X„,...,X )

WHERE B"(x,,X„,...,X K 1 2' ' nr) Az ilyen leválasztást nevezzük redukciónak. Ha a le­ választás eredményeképpen B* nem függ X^-től, Q-t diszjunkt /disjoint/ lekérdezésnek nevezzük. Ez azt jelenti, hogy az eredeti Q lekérdezésben a B' feltétel akár el is hagyható /ha legalább egy Rm+^,...,R sorkombinációra igaz - ellen­ kező esetben Q eredménye üres halmaz/. Látható tehát, hogy Q' és Q" között az egyetlen kapcsolat az X^ közös változó. Q-t összefüggő /connected/ lekérdezésnek mondjuk, ha nem választható le belőle diszjunkt lekérdezés. Végül Q irreducibilis, ha nem választható le belőle a fenti módon semmi­ féle Q' /nem redukálható/. Példánk nyilvánvalóan összefüggő lekérdezés. Ha elhagy­ nánk belőle a "D. RÉSZLEGKÓD=R.RÉSZLEGKÓD" feltételt nyil­ vánvalóan le tudnánk belőle választani a

137

RANGE OF R IS RÉSZLEG RANGE OF D IS DOLGOZÓ RETRIEVE INTO D" (.D.NÉV,D .FŐNÖK,D .BESOROLÁS ,D .ALAPBÉR) WHERE R.CIM='AZ ÜVEGHEGYEN INNEN ' diszjunkt lekérdezést. Lássuk tehát a leválasztás! algoritmust! Nyilvánvaló, hogy pl. példánk lekérdezése többféleképpen is felbontható. UWONG 76] algoritmusának nagyon lényeges alapgondolata, hogy a felbontásnak redukcióval kell történnie. A dolgozat algo­ ritmust ad arra, hogyan végezhető el a redukció: Feltesszük, hogy a WHERE feltétel konjunktiv normál­ formára van hozva. A feltétel un. karakterisztikus mátrixát /incidence matrix/ úgy képezzük, hogy sorai a normál­ forma Fi'F2'*’''Fm tényezőinek, plusz egy sor a RETRIEVEben szereplő eredmény-listának, oszlopai pedig az X^,X2,..*/xn változóknak feleljenek meg, a^j eleme pedig aszerint legyen 1 vagy 0, hogy a F^ tényezőben szerepel-e az Xj változó. Példánk karakterisztikus mátrixa /a feltételeket felülről lefelé számozva/:

F3 F4

1 1 0

F 1 0 0 0

F5 E

1 1

1 1

FI F2

D 1

R 0 1 0 1 0 0

vagy az áttekinthetőség kedvéért összevonva az azonos sorokat: F

/F1,F5,E/

D 1

1

R 0

F2 F3

1 1

0 0

1 0

F4

0

0

1

138

Egyszerű, algoritmussal ellenőrizhető a lekérdezés összefüggősége: Vegyük sorban az oszlopokat, és egy adott oszlopra azokkal a sorokkal, ahol az oszlopban 1 áll vé­ gezzünk elemenként logikai vagy műveletet. A művelet ered­ ményét tartsuk meg, az operandusaiként szolgáló sorokat huzzuk kii Az első lépés, a D oszlop vizsgálata után mát­ rixunk igy néz ki: D /F1,F5,E,F2,F3/ F4

1 0

F 1 0

R 1 1

Ha végeredményként nem egy sorból álló mátrixot kapunk /ilyen lesz példánk karakterisztikus mátrixa, ha az F2 sort elhagyjuk belőle/, akkor a lekérdezés nem összefüggő, és a sorok reprezentálják a diszjunkt komponenseket. A redukciós algoritmus azon az észrevételen alapul, hogy a redukálható lekérdezés a közös változó elhagyásával nem összefüggővé válik. Hagyjuk el tehát sorban a változó­ kat, /a karakterisztikus mátrix oszlopait/, és ha valamelyik elhagyásával nem-összefüggő lekérdezést nyerünk, akkor meg­ van a közös változó. A következő lépéshez elő kell késziteni az un. redukált karakterisztikus mátrixot. Ez a karakterisz­ tikus mátrix sorainak átrendezésével nyerhető. Felülről le­ felé a sorrend a következő: /1 / egyváltozós sorok /kivéve az eredménylistát/ /2/ a közös változót tartalmazó, és az eredménylistát nem tartalmazó sorok /3/ az eredménylistát nem tartalmazó további sorok /4 / az eredménylista Ez esetünkben:

1 39

D 1 0

R 0 1

1 /F1,F5,E/ 1

1 0

F3 F4 F2

F 0 0 0 1

Megjegyezzük még, hogy noha példánkban a redukció eredménye két leválasztott irreducibilis komponens, ez nem mindig van igy a redukció eredménye több komponens is lehet. b/ A redukált karakterisztikus mátrixot a lekérdezés ütemező /subquery sequencing/ veszi át. A mátrix első többváltozós sorát veszi, hozzáteszi azokat az egyválto­ zós sorokat, melyekben a többváltozós sor változói sze­ repelnek, és ebből lekérdezést képez, majd a felhasznált sorokat kihúzza a mátrixból. Az előállított lekérdezést a helyettesítő eljárásnak továbbítja. Következő hívása­ kor uj lekérdezést generál, amig el nem fogy a mátrix. Esetünkben két lekérdezést

generál:

RANGE OF D IS DOLGOZÓ RANGE OF R IS RÉSZLEG RETRIEVE INTO Dl(ü.NÉV,D .FŐNÖK,D.ALAPBÉR) WHERE D.BESOROLÁS^POZITÍV HŐS' AND R.CIM='AZ ÜVEGHEGYEN INNEN' AND D.RÉSZLEGKÓD=R.RÉSZLEGKÓD RANGE OF D IS Dl RANGE OF F IS DOLGOZÓ RETRIEVE (D.NÉV,F.NÉV) WHERE D .FŐNÖK=F.NÉV AND D. ALAPBÉR> F.ALAPBÉR

140

cl A többváltozós irreducibilis lekérdezést helyette­

sítéssel oldjuk meg. Ennek első - döntő jelentőségű - lé­ pése annak eldöntése, hogy melyik változót - illetve annak értékkészleteként szolgáló relációt - jelöljük ki helyette­ sítésre. Ezt a döntést több tényező befolyásolhatja. Legyen ,..•/X ^ a vizsgálandó lekérdezés, X 1 ,X2,...,Xn értelmezési tartománya ,R2,...,Rn ! Tegyük fel, hogy X^-t választjuk ki soronkénti helyettesitésre. Minden <=< £■ R^-re lekérdezés generálódik. Durva becs­ lés alapján ekkor a Q lekérdezés megválaszolásának költsége R^ számossága x

megválaszolásának költsége

Az első, kézenfekvő gondolat tehát a legkisebb számos­ sága R^-nek megfelelő X^ kiválasztása. Ez azonban nem min­ dig

optimális, mert

a/ az egyváltozós részlekérdezések feldolgozásával R, ,Rn ,...,R számossága megváltozhat. Persze az is kérdés, hogy érdemes-e mindegyik egyváltozós részlekérdezést külön feldolgozni. Ha a benne résztvevő változó a helyet­ tesitésre kijelölt, nyilván érdemes. Az INGRES egyszerűen valamennyi egyváltozós lekérdezést feldolgozza mielőtt döntene a változókiválasztásról, de CWONG 76j más módszert is közöl. b / X^ megválasztása nyomán létrejövő Ch lekérdezés bonyolultsága i-vel igen változó lehet.

[WONG 76 j a kövektező közelítéseket javasolja. Nyil­ vánvaló, hogy c(o)-val jelölve a Q lekérdezés minimális költségét: c( q )= m i n 1^ Z_ l

ahol

c

;

Q q .00)1 1

-R t Ri egyváltozós lekérdezések után még szóbajöhető

141

soraiból összeállított reláció. Ezek után, ha c(_Q,(«<))-t i-tol függetlennek tételezzük fel, akkor a minimális számosságu R,-t kell helyettesitésre kijelölni. 1976 januárjában ez volt az INGRES stratégiája. tWONG 763 ennél bonyolultabb és pontosabb módszereket is közöl, az optimális helyettesités megválasztására. Példánk első lekérdezésének feldolgozása az egy­ változós részlekérdezések feldolgozásával kezdődik. Ezek létrehozzák a POZITIV_HŐS relációt /a Dolgozó reláció 1. és 4. sora tartozik bele/, és az ÜVEGHEGYEN_INNEN relációt /a Részleg 2. és 3. sorából/. Ezután lekérde­ zésünk ekvivalens lesz a RANGE OF D IS POZITIV_HÖS RANGE OF R IS ÜVEGHEGYEN_INNEN RETRIEVE INTO Dl ( D .NÉV,D .BESOROLÁS,D .ALAPBÉR) WHERE D.RÉSZLEGKÓD=R.RÉSZLEGKÓD A két reláció számossága egyaránt 2, jelöljük ki he­ lyettesitésre pl. R-t. Az algoritmus R els5 sorát he­ lyettesítve generálja a RANGE OF D IS POZITIV_HŐS RETRIEVE INTO Dl (jD.NÉV,D .BESOROLÁS ,D .ALAPBÉR) WHERE D. RÉSZLEGKÓD='CIC' lekérdezést, és rekurzive hivja önmagát a redukció lépés­ től kezdve. Jelen esetben nem lesz szükség dekompozicióra, igy a rekurziv példány mindössze az egyváltozós lekérde­ zéseket megoldó processzort hivja meg, és visszatér. Üres listával, ugyanis egyik pozitív hősünk sem dolgozik a CIC-nél. Az eredeti példány most a következő részlegkódot /CIA/ helyettesíti, és ismét rekurziv hívás következik. Ennek eredményeképpen a Dolgozó reláció 4. sora /Hó Fehérke/

142

bekerül a Dl relációba. Az algoritmus most visszatér a lekérdezés ütemezőhöz, és a második lekérdezést is feldolgozza - teljesen hason­ lóan az előzőhöz. Itt Dl egyetlen sora kihull a rostán. Az algoritmus blokkdigaramja a 21. ábrán látható.

dekompozició

|

rekurziv hivása

21. ábra

-

143

-

CSTON 763-ban közölt algoritmus és a fent ismertetett között a leglényegesebb különbség a redukció hiánya. A lekérdezés - példánknál maradunk továbbra is - azonnal /ha nem egyváltozós/ a helyettesítő eljáráshoz kerül. Ez leválasztja róla az egyváltozós lekérdezéseket és az egy­ változós lekérdezés processzor megoldja ezeket. Tehát le­ kérdezésünkből a RANGE OF F IS DOLGOZÓ RANGE OF D IS POZITIV_HŐS RANGE OF R IS ÜVEGHEGYEN_INNEN RETRIEVE (p.NÉV,F .NÉV) WHERE D .FŐNÖK=F.NÉV AND D.RÉSZLEGKÓD=R.RÉSZLEGKÓD D.ALAPBÉR> F.ALAPBÉR

AND

lekérdezés lesz, ahol a "Pozitiv_hős" és az "Üveghegyen« innen" relációk ugyanazok, mint az előbb. Ennek a megol­ dása helyettesitéssel történik, hasonlóan választva meg a helyettesítendő változót, mint az előbb. A programozás­ technikai megoldás ugyancsak a rekurziv hivás. Az ideiglenes relációk - esetünkben pl. "Pozitiv hős" "Üveghegyen innen" - szervezésével CSTON 763 részletesen foglalkozik. Ezeket a közvetlen hozzáférés kedvéért hashelve szervezi, a hash-kulcs megválasztása csak a probléma. Az "Üveghegyen innen" relációnál egyértelmű, hogy Részleg­ kód szerint érdemes szervezni, hiszen a továbbiakban ezt az oszlopát használjuk csak. A "Pozitiv hős" esetén más a helyzet, szóba jöhet a Főnök, és a Részlegkód is /az Alapbér egyenlőtlenségben szerepel, igy kiesik/. Ha pl. az algoritmus - CSTON 76l szerint ilyenkor találomra dönt a Főnök szerint hash-el, és az első helyettesítendő relá­ ció az "Üveghegyen innen" lesz, akkor a "Pozitiv hős"

/

144

relációt újra kell szervezni, hogy Részlegkód szerint köz­ vetlenül elérhetővé váljon. CSTON 80l az INGRES dekompoziciós technikáját érté­ kelve megállapítja, hogy egy fontos esetet rosszul kezel. Abban az esetben ugyanis, ha egyenlőség feltétellel kell illeszteni, gyakran a legcélszerűbb megoldás a két relá­ ciót rendezni az illesztési feltételekben szereplő mezők szerint és aztán összefésüléssel /merge/ lehet az eredmény relációt megkapni. Ezt az esetet a cikk szerint külön kelle­ ne kezelni.

2.2.5. Az SQL/DS optimizációs módszerei. A "forditóprogram" implementáció Az SQL/DS optimizálási stratégiájának alapját CCHAM 813 szerint - Blasgen és Eswaran CBLAS 773-ben kö­ zölt vizsgálatai képezik, ök a három alapvető relációalgeb­ rai műveletből - egyenlőség feltételű illesztés, korlátozás /kiválasztás/, projekció - álló lekérdezéseket vizsgáltak APL modelleket felhasználva. Cikkük 4 lehetséges algorit­ must közöl ilyen lekérdezések megválaszolására: 1. Az illesztendő oszlopok szerinti index felhaszná­ lása: Tegyük fel, hogy az illesztendő oszlopok szerint mind a két relációban /R és S / létezik index! Ekkor eze­ ket használva keressük az olyan párokat, melyek illeszt­ hetők, vagyis a megfelelő elemeik egyenloek. Tegyük fel, hogy találtunk egy ilyen párt! Ekkor az egyik /mondjuk r é R/ sort beolvassuk, és ellenőrizzük, hogy a korlátozás felté­ telét kielégiti-e. Ha igen, akkor S indexét felhasználva, az összes r-hez illeszthető s€. S párt megvizsgáljuk az Sre vonatkozó korlátozás szempontjából, és a megfelelőkre alkalmazzuk a projekciót, majd ideiglenes

tárolóra helyezzük

145

okét. Most R indextáblájában keressük meg az összes rével egyező kulcsu /tehát illeszthető/ sort/ ezekre al­ kalmazzuk a korlátozás feltételét, és a megfelelőket - a projekció után - az ideiglenes tárolón lévő s-ekkel illesztjük, az eredményt az output relációba helyezve. 2. A relációk rendezése: Végigolvasva a két reláci­ ót a korlátozó feltételt kielégítő összes sor megfelelő projekcióját és W2 file-okra Írjuk. A két file-t össze­ rendezve, az eredményül kapott file szekverfijalis olvasá­ sával könnyen kapható az output reláció. 3. Többszörös olvasás: S sorait olvassuk sorban. Ha valamelyik s sora megfelel a korlátozás feltételének, akkor arra alkalmazzuk a projekciót, és az eredményt egy W^, központi memóriában felépített adatszerkezetbe /lehet fa, hash-tábla, rendezetlen adathalmaz, stb. / kíséreljük meg elhelyezni. Ha W'-ben nincs hely, és az s illesztendő „, , „ , , ^ r , mezon eben levő érték kisebb, mint a W -ben levő sorok ha2 sonló mezőjében szereplő maximális érték, akkor töröljük $ a maximális értékű sorokat, és s-t W2~be illesztjük, ellen­ kező esetben s-t egyáltalán nem illesztjük W 2 -be. Miután S-t végigolvastuk, R-ben keresünk a korlátozó feltételt kielégítő sorokat. Ha egy ilyen r sorra bukkantunk, kísérelünk W^-ben hozzáilieszthető sort találni.

meg­

Ha S-ben több sor van, mint amennyinek a projekció­ ja i/-ben elfér, akkor az előző eljárást ismételjük, ter­ mészetesen az előző menetben felhasznált sorokat már ki­ hagyva /ehhez az előző menetben használt maximális illesz­ tési mezőértéket kell megjegyeznünk/. 4. Sorazonositó /TIP/ algoritmus: Tegyük fel, hogy mind a két relációban úgy az illesztési oszlopokra, mint

'

146

a korlátozó feltételben érdekelt oszlopokra van index! Ez utóbbi indexeket használva a megfelelő sorok azonosí­ tóiból összeállítjuk az R' és S' file-okat, majd különkülön rendezzük őket. Ezek után az illesztendő oszlopok szerinti indexeket használva kikeressük azokat az /Al,A2/ azonositópárokat, melyek illeszthető soroknak felelnek meg, és ellenőrizzük, hogy A^ ill. A 2 szerepel-e R' ill. S'-ben. Ha mindez teljesül, a sorokat beolvasva, a projek­ ciót elvégezve kapjuk az eredmény egy sorát. Ennek a négy illesztési algoritmusnak várható költ­ ségét becsüli

£BLAS 77l olyan változók függvényében, mint

• a reláció sorainak számaj • a reláció által lefoglalt adatlapok száma; • az indexben szereplő különböző értékek száma: stb. Ezeket a statisztikákat a rendszer vezetheti /az SQL/DS meg is teszi/. A számolást bonyolítja, hogy egy index lehet CLUSTERING tulajdonságú /ld. 1.1.1./, ami per­ sze elérés szempontjából kedvező. Megjegyezzük, hogy még nagyon sok, a fentiekhez ha­ sonló algoritmus gyártható, csupán az ezekben felhasznált tárolási fogalmak /index, rendezés, sorazonositó/ segít­ ségével, és uj fogalmakat /pl. hash/ bevezetve az egész még tovább bonyolítható. Eb l a S 773 több érdekes következtetésre jut:

' mindegyik algoritmusra létezik olyan gyakorlatban előforduló helyzet, melyben optimális /a fenti négy közül /’ • az index CLUSTERING tulajdonságának komoly jelentő­ sége van. /Ehhez meg kell jegyezni, hogy az SQL/DS az egyes relációkat egymástól nem elkülönítve, kö­ zös adatlapokon tárolja, igy egy reláció sorai nagyon szétszóródhatnak - hacsak egy CLUSTERING

147

elemzés után. Az Optimizáló minden SELECT-re külön optimizál. Az első lépésben történik a nézőpontok feldolgozása Ez annyit jelent, hogy a nézőpont definíciója bekerül a kérdés feltételei közé. Pl. az 1.1.1. e-ben definiált "Programozási Osztály" nézőpontra vonatkozó SELECT NÉV,CÍM FROM PROGRAMOZÁSI_OSZTÁLY WHERE ALAPBÉR> 4000 lekérdezés átalakul a SELECT DOLGOZÓ.NÉV,RÉSZLEG.CÍM FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.ALAPBÉR> 4000 AND DOLGOZÓ.BESOROLÁSA PROGRAMOZÓ' AND DOLGOZÓ.RÉS ZLEG=RÉSZLEG.RÉSZLEGKÓD lekérdezéssé. /Ezt a technikát Stonebraker javasolta [STON 76}-ban, és természetesen az INGRES is használja. Nézőpontokon kivül integritási, konzisztencia feltéte­ lek kezelésére is alkalmazható./ Most következik a tulajdonképpeni optimizálás, az elérési ut megválasztása. Sajnos az ezt részletesebben leiró, sűrűn hivatkozott dolgozatot - egy Boston-ban tar tott konferencia kiadványában szerepel - nem sikerült megszerezni, de a források alapján a következőképpen kép zeljük el: A beérkező fát az Optimizáló a fentiekben vizsgált három-müveletes /illesztés, korlátozás, projekció/ lépé­ sekből álló sorozatra bontja. Ezután fát képez oly mó­ don, hogy a fa egy_-egy szintje egy ilyen kétrelációs műveletnek feleljen meg. A döntési szabadság minden szinten az, hogy az eljáráskészlet melyik algoritmusával végezze

148

index nem helyezi okét egymáshoz közel/; egyszerű számolással összehasonlítható két lehet­ séges elérési ut /módszer/. Mindebből a következő javaslat adódik: az Optimizáló a lehetséges elérési utakat vegye számba, a költségei­ ket - durva előzetes válogatás után - becsülje meg /a rendszer által vezetett statisztikai adatok felhasználá­ sával/, és válassza a legolcsóbbat! EBLAS 770. A System-R rendszer fejlődését összefoglaló - elem­ ző CCHAM 810 cikk az illesztés módszerei közül kettőt emel ki, mint olyat, melyek közül az egyik "az esetek nagy részében közel optimális". Ezek: 1. R korlátozó feltételt kielégitő soraihoz /ezeket R szekvenciális olvasásával vagy index használatával, vagy más módon kapjuk/ keressük ki S megfelelő sorait /indexet használva, de nem minden esetben/. 2. Ha nincs index, rendezzük össze a két relációt, és igy végezzük el az illesztést /UBLAS 773 2.algoritmusa/. Az 1. algoritmus szerintünk nem túl pontos, elég sok különböző változatát el tudjuk képzelni, és az adott hely­ zet dönti el, melyiket érdemes használni. A 2. igazsága elég nyilvánvaló /CSTON 80l is hivatkozik rá - ld. 2.2.4./. Valószínűleg arról a szomorú tényről van szó, hogy még ilyen - az általános lekérdezéshez képest viszonylag egyszerű esetben sem létezik az adott helyzettől függet­ len, legjobb, vagy közel legjobb univerzális megoldás. Lássuk most tehát az Optimizáló működését! A lekérdezésben szereplő minden egyes SELECT-nek /ezek­ ből több is lehet egy kérdésben - ld. 1.2.3./ egy ered­ ménylista /milyen oszlopokból áll majd az eredmény/ egy FROM-lista /a lekérdezésben résztvevő relációk/, és egy WHERE fa /a diszjunktiv normálformáju feltétel feltehe­ tően 2.2.3.-ban leirt alakja/ felel meg a szintaktikai

149

el a szintnek megfelelő műveletet. Egy adott szint egy csomópontjából induló elágazások a szóbajöhető eljárások­ nak felelnek meg. Minden szinten értékeli az ut költsége­ it, és az azonos eredményre vezetők közül a legolcsóbb utat tartja csak meg, megkapva végül az optimálist. Hogyegy-egy szinten miként mérlegel, és milyen algoritmusokat használ, arra vonatkozóan pl. CöLAS 77}nyujt támpontot. Az egyes algoritmusok értékelésének mérőszáma a lapozások és a tárolási részrendszer rutinjaihoz fordulások számá­ nak /utóbbi a CPU idő jó közelítése/ súlyozott összege. tCHAM 8ll A felhasználói interface nyelvének leképzését adat­ bázis assemblerre /vagy közvetlen adatmanipulációra/ in­ terpreter vagy forditóprogram-szerü tevékenységnek is fel­ foghatjuk, egy magasszintü nyelv egy-egy utasításának egy másik, végrehajtható nyelv egy vagy több utasítását kell megfeleltetni. Attól függően, hogy az igy kapott utasítá­ sok végrehajtása azonnal megtörténik, vagy csak tároljuk őket egy későbbi végrehajtás céljára, interpreterről vagy fordítóprogramról beszélhetünk. Ilyen szemszögből a 2.2.1.-2.2.4.-ben vizsgált algo­ ritmusainktól - és általában a relációs adatbáziskezelők optimizálóprogramjaitól - eltérően az*SQL/DS Optimizálót fordítóprogramnak kell tekintenünk. Működése a 22. a, és b, ábrákon látható: Az /1.3.1.-ben ismertetett/ adatkezelő résznyelv uta­ sításait tartalmazó PL/1 programot az ElŐforditó dolgozza fel. Megkeresi a programban lévő adatkezelő utasításokat, megfelelő PL/1 éljárás-hivásokra cseréli őket, majd a módosított, most már "tiszta" PL/1 programot file-ra Írja. Az adatkezelő utasítások feldolgozása három lépésben /Szintaktikus elemző, Optimizáló, Kódgenerátor/ történik, “s eredménye a rendszer könyvtárában elhelyezett adatkeze­ lő Modul /Access Module/ lesz. Ez gépi kódú - vezérlésátf adásokat, adatbázis assembler rutinok hívásait tartalmazó program.

150

Futás

Fordítás

PL/1 forrásprogram

SELECT NÉV INTO $X FROM DOLGOZÓ WHERE_TÖRZSS ZÁM=$Y

Eloforditó /XPREP/

r

^

r

(SZÍNTAN [OPÉJI KODGLbil

A

Módosított PL/1 • —

-

W

modul

--------------------------------------------------------

--------- ----

_

_

______ . . .

CALL..

a/

.

Adatkezelő

..

gépi kódú program

hl

22. ábra

151

Amikor a felhasználó futtatja a programot, az Eloforditó által a programba helyezett első CALL végrehajtása teremti meg a kapcsolatot az SQL/DS futtató rendszerével. Ez betölti a megfelelő Adatkezelő Modult, és átadja neki a vezérlést. A modul az adatbázis assembler rutinokat használva az Optimizáló által megválasztott algoritmus szerint bonyolitja az adatok cseréjét a felhasználó prog­ ramja és az adatbázis között. Ad-noc lekérdezés esetén a felhasználó utasításait az UFI /User Friendly Interface, Id. 2.1.1./ fogadja. Ilyenkor a végrehajtás a 23. ábra szerint történik.

152

A terminálról érkező parancsokat az UFI fogadja, és megfelelő ^PREPARE, ^EXECUTE utasításokon keresztül /ezek persze az előforditott UFI-ban már /PL/1 CALL-ok/ továb­ bítja a futtató rendszernek. Ez felismerve a ^PREPARE és ^EXECUTE utasításokat elvégzi a fordítás három lépését, felépiti és meghívja a megfelelő Adatkezelő Modult, amely a szokásos módon végzi az adatkezelést. /Megjegyezzük, hogy nem csak az UFI, hanem felhasználói program is tar­ talmazhat #PREPARE-t és $EXECUTE~ot. Ilyen esetekben a feldolgozás menete azonos a 23. ábrán láthatóval/. A módszer előnyei /£CHAM 81a") szerint/. a szintaktikus, név megfeleltetési, optimizálási, jogosultsági ellenőrzések nagy része a futás ide­ je helyett a fordításét növeli. Ez főképpen a sok­ szor futtatott programoknál jelentős, • az Adatkezelő Modul, mivel egy speciális programhoz készült, hatékonyabb, és sokkal kisebb, mint egy általános SQL interpreter. Az INGRES rendszer interpretert és nem fordítót használ /legalábbis 1980-ban/, de CSTON 803 megállapítja, hogy tévedtek, alábecsülték a programozási nyelv interface fontosságát, és megfeledkeztek a CcHAM 81al említette két előny - idő és memórianyereség - fontosságáról. A cikk konkrét számokat közöl a veszteség becslésére, külön ki­ emelve azt az időt, ami az egyes QUEL parancsoknál a fel­ használó jogosultságának ellenőrzésére elmegy. Most a fordítás technikai részleteivel fogunk fog­ lalkozni. A 24. ábra az Adatkezelő Modult alkotó egyes szekciótipusokat, és a velük kapcsolatos események idő­ beli alakulását illusztrálja:

Szekciótipus

Utasitástipus

Lekérdezés,

/

módosítás

J

Adatdefincició tranzakciódef., stb.

■ S z i n t a x 1 Opt.

Ideiglenes táb­ V PARSEDSECT lákon végzett műveletek ^PREPARE ^EXECUTE

}

Ford. ------

Ford.

i 1 I 1 1. i 1 \

INDEFSECT

Futás

Fordítás

COMPILESECT

INTERPSECT

Végrehaj tás

1 Kódgen

1

Futás

i í i

1

Futás i 1

1 1

Futás

24. ábra A

COMPILESECT jelentése eléggé nyilvánvaló: az SQL

utasítás végrehajtása. INTERPSECT olyan utasításokra jön létre, mely az adatbázis logikai és fizikai szerkezetétől függetlenül mindig ugyanúgy, és csak egyféleképpen hajtha­ tó végre. Amikor a program ideiglenes relációra hivatkozik, az még nem létezik, igy elérése nem óptimizálható. Ilyenkor generál az Eloforditó PARSEDSECT-et, melyet a futtató rend­ szer optimizál, és a generált kódot végrehajtja. Az INDEFSECT jelentése megint nyilvánvaló: a ^EXECUTE utasításokról fordí­ táskor csak annyit tudunk, hogy melyik karaktersorozatban helyezkednek el - igy a szintaktikus elemzéstől a végrehaj­ tásig minden futás közben történik - ez tulajdonképpen in­ terpretálás .

154

A 25. ábra egy Adatkezelő Modult ábrázol: A Rendszerkatalógusban tárolt leírás:

Programnév

Létrehozó

Dátum

Érvényesség

Szekció tábla Eltolás

Tipus

Szekció #■

CO M1,ILE SECT INTERPSECT PARSEDSECT 1. szekció gépi kód + relokálandó cinek + az eredeti SQL utasitás 2. szekció utasitásfa + relokálandó cimek + az eredeti SQL utasitás 3. szekció utasitásfa + relokálandó cimek + az eredeti SQL utasitás

25. ábra

Cim

155

A leírásban lévő mezők jelentése elég nyilvánvaló/ kivéve az "Érvényességet"-et. Ez a mező jelzi, azt, hogy az Adat­ kezelő Modul érvényes-e még, vagy újra kell fordítani. Elő­ fordulhat ugyanis, hogy a program fordítása és futása kö­ zötti időszakban az adatbázis fizikai szervezése megválto­ zik, pl. egy indexet töröl az adatbázis adminisztrátor, vagy egy erre jogosult felhasználó. Ilyenkor a rendszer megkeresi a katalógusban azokat a Modulokat, melyek ezt az indexet használták, és - az Érvényesség mező segítsé­ gével - érvényteleníti őket. Ha a futtató rendszer érvény­ telen Modulra való hivatkozással találkozik, ujraforditja azt, anélkül, hogy a felhasználó erről tudomást szerezve. Az Adatkezelő Modulok több szekcióból állhatnak. A 25. ábrán 3 különböző tipusu szekcióból álló Modult lát­ hatunk, COMPILESECT az egyetlen, mely gépi kódú utasításo­ kat tartalmaz, a másik kettőben ehelyett a szekciót gene­ ráló utasitás Szintaktikus elemző által előállított fája szerepel. Mind a három szekcióban eredeti formájában sze­ repel a generáló SQL utasitás - erre az ujráfordítás miatt van szükség. Egy felhasználói program fordítását illusztrálja a 26. ábra:

Forrás PL/1

Módosított PL/1

^UPDATE DOLGOZÓ SET ALAPBÉR=ALAPBÉR+ $P

CALL XRDl( t

WHERE TÖRZSSZÁM=$Q;

;

156

$LET Cl BE SELECT NÉV,ALAPBÉR INTO $X,$Y FROM DOLGOZÓ WHERE BESOROLÁSBA,* $OPEN Cl;

$FETCH Cl;

#CLOSE Cl;

26. ábra

/Nem történik XRDI hivás, hiszen ez csak deklaráció. A forditó kijelöli a Ci­ nek a 2. szekciót/.

157

Az első XRDI hivás végrehajtja az SQL utasítást Hivat­ kozik a program nevére, a szekcióra /ezt miridegyik XRDI hivás megteszi/. A művelet. k°dja AUXCALL, a szekció gépi kódú utasításainak végrehajtását eredményezi. Az utasítás­ nak úgy az input, mint output változói a hivás paraméterei lesznek. A második XRDI hivásnál - Cl nyitása - a rendszer megjegyzi az utasitás input adatait /v.ö. 1.3.1./, és fel­ készül a lekérdezés végrehajtására /a gépi kód "OPENCALL" paraméterű végrehajtásával/, A FETCH továbbítja az output paraméterek cimét, és végrehajtja az utasítást. A ^PREPARE utasitás hatására az Eloforditó az Adat­ kezelő Modulban INDEFSECT-et hoz létre, a PL/1 programban pedig az utasítást speciális, "SETUPCALL" paraméterű XRDI hivásra cseréli. Futás közben ennek hatására a futtató rend­ szer /az XRDI/ a karaktersorozat tartalmát lefordítja, és az INDEFSECT-et erre a COMPILESECT-re cseréli /persze csak a memóriában, és nem a Rendszerkatalógusban lévő példánynál/ A ^EXECUTE közönséges "AUXCALL" paraméterű XRDI hivást és ezzel a $PREPARE generálta COMPILESECT végrehajtását ered ményezi. Ha ismét ugyanarra a karaktersorozatra /szekcióra/ vonatkozó $PREPARE| utasítással /"SETUPCALL" paraméterű hí­ vással/ találkozik az XRDI, a szekció régi tartalma - most már COMPILESECT - elvész, helyébe a karaktersorozat aktu­ ális értéke szerint generálódik szekció, és a következő ^EXECUTE már ezt fogja végrehajtani. Még egy speciális hivást a "DESCRIBECALL" paraméterűt emlitünk. Ez a felhasználói program $ DESCRIBE -ben elhelyezi az

utasításban szereplő mezok ne­

veit és tipusait.

158

2.2.6. Összefoglaló megjegyzések A megvizsgált algoritmusok néhány közös gondolatot - módszert, észrevételt - tartamaznak. Ezeket nézzük végig még egyszer, megfigyelve, hogy az egyes algoritmusoknál mi­ képp bukkannak fel az azonos ötletek. Szolgálhat némi tanul­ sággal programozástechnikai - implementációs megoldások vizs gálata is. Jól láthatóan /az algoritmusok alapján/ érdemes relá­ cióalgebrai terminológiát használni. A nem relációalgebrai nyelveknél is világos, hogy melyikben mit jelent a pro­ jekció, korlátozás, és az illesztés. Mivel a relációalgeb­ ra a legprocedurálisabb, a gép számára is a relációalgebra interface a legkönnyebben érthető, és az optimizálási al­ goritmusoknak is kiindulópontot ad, atomi műveleteivel, melyek sorozata alkotja a lekérdezést. A Chang-Smith algoritmus fogalmazta meg az egyváltozós korlátozások mielőbbi elvégzésének és összevonásának elvét. Előnyei nyilvánvalóak: minél korábban érdemes a manipulá­ landó reláció méretét csökkenteni, és egy relációba tarto­ zó feltételeket nem érdemes a reláció többszöri végigolvasásával ellenőrizni. Nézzük meg ennek az elvnek a megvaló­ sulását és módosulásait az egyes algoritmusoknál! A Palermo algoritmus minden reláción csak egyszer megy végig, tehát az egy relációba tartozó feltételeket a lekér­ dezésben elfoglalt pozíciójuktól függetlenül egyszerre elle­ nőrzi. Ügyes implementáció - az ismertetett LIDAS-ban erre nincs utalás, de feltételezzük, hogy ilyen - az értéklista készítésénél kihasználja az indexet /ha van/. Az egyválto­ zós korlátozások illesztés előtti elvégzését jelenti, hogy a párlisták építésénél adott konjunkcióban lévő egyváltozós korlátozásokat figyelembe veszi. A TID algoritmusnál is érvényesül ez az elv. Az egy-

(

159

változós korlátozások kitüntetett szerephez jutnak /Pl és P2 tipusu feltételek/, és noha az algoritmus index-középpor-~ tusága miatt elsősorban a Pl-eket tudja jól felhasználni, a P3,P4,P5 feltételek /ezek jelentik az illesztést/ fel­ dolgozása előtt a belső blokkban előbb a Pl, majd a P2 tipusuak is kiértékelésre kerülnek. Mindennek ellenére lehet olyan lekérdezést Írni, ahol ez az elv csorbát szenved. Az alábbi lekérdezés azoknak a pozitív hősöknek a nevét Írja ki, akik 1-nél több dolgozót foglalkoztató részlegekben dolgoznak /2.2.1. adatbázisát használjuk/: SELECT NÉV FROM D IN DOLGOZÓ WHERE BESOROLÁSÉ POZITÍV HŐS' AND RÉSZLEGKÓD IN SELECT RÉSZLEGKÓD FROM R IN RÉSZLEG WHERE 1 > SELECT COUNT (x) FROM DOLGOZÓ WHERE RÉSZLEGKÓD=R.RÉSZLEGKÓD Ennél a lekérdezésnél az algoritmus ha a külső blokk feltételeinél a "Besorolás"-t tartalmazót P2 típusúnak /nincs index "Besorolás"-ra/, a "Részlegkód"-ot tartal­ mazót pedig Pl-nek találja, akkor lefelé haladva elvég­ zi a Részleg és Dolgozó relációk illesztését, anélkül, hogy a Részleg sorait a "Besorolás"-ra vonatkozó felté­ tel korlátozná /mint az pl. a Palermo-algoritmusnál meg­ történhet/. Persze nyilvánvaló, hogy ezt a lekérdezést egyszerűbben is meg lehet Írni SEQUEL-ben, oly módon, hogy a korlátozást hajtsa végre előbb az algoritmus.

160

A PRTV algoritmusát leiró ÜHALL 76] cikk két fontos megjegyzést tesz evvel az elvvel kapcsolatosan: nem mindig lehet az illesztés előtt korlátozni, és nem is mindig ér­ demes. Az előbbit természetesen minden algoritmus figyelem­ be veszi, az utóbbit nem, ugyanis annak eldöntése, hogy mi­ kor érdemes, mikor nem, nehezen becsülhető. Az SQL/DS algo­ ritmus, mely a rendszer által vezetett statisztikákon ala­ pul, tudj a talán ezt a becslést legjobban elvégezni, és en­ nek alapján választani az optimális illesztés-korlátozásiprojekció algoritmust. Az INGRES ÜSTÖN 76] algoritmusa elsőnek az egyváltozós korlátozásokat hajtja végre /már ha lehet, és az OR-ok ezt nem teszik lehetetlenné/. A módosított ÜWONG 76] algoritmus már azt emliti, hogy csak akkor érdemes ezt megtenni, ha a korlátozásban szereplő változó valószinüleg helyettesitésre kijelölt. /A helyzet azért bonyolult, mert a korlátozás ered­ ményétől függ, hogy kij.elöljük-e a változót helyettesitésre./ Az SQL/DS algoritmusa az egyváltozós korlátozások mi­ előbbi elvégzésének elvét tulajdonképpen igen kritikusan szem­ léli, és pl. tBLAS 77] négy algoritmusából is kiderül, hogy ennek az elvnek az érvényessége - legalábbis az SQL/DS fizikai szervezése mellett - nagymértékben függ a lehetséges elérési utaktól. A Chang-Smith algoritmus projekcióra vonatkozó elve en­ nél egyszerűbb és nyilvánvalóbb. Kisebb méretű /sorhosszuságu/ relációkkal kényelmesebb dolgozni, ésszerűtlen lenne a feles­ leges adatot cipelni. Az algoritmusok általában - ésszerűen úgy értelmezik ezt az elvet, hogy le kell vágni a szükségte­ len adatmezőket, de a duplikátumok eltávolításával /ami ren­ dezést jelent/ nem foglalkoznak. Érdemes megemlíteni még, hogy a sorazonositóval dolgozó algoritmusok /Palermo, TID, CBLAS 77] 4. számú/ szempontjából ennek az elvnek nyilván nincs jelentősége.

161

Az INGRES filozófiában alapvető szerep jut a helyette­ sítendő változó kijelölésének, C.WONG 76] bonyolult algorit­ musokat javasol /nem tudjuk, hogy implementálta-e valame­ lyiket az INGRES/. CSTON 76j egyszerűen azt a változót he­ lyettesíti, mely az egyváltozós korlátozások elvégzése után legkisebbé vált reláción van értelmezve. A Palermo-algoritmus ilyen szempontból még egyszerűbb stratégiával dolgozik. Mindig azt a változót helyettesíti, amelyik a legkisebb reláción van értelmezve /az egyválto­ zós lekérdezések figyelembe vétele nélkül/. tWONG 763 ez ellen több érvet is felhoz /ld. 2.1.4./ A Chang-Smith és a PRTV algoritmus a relációalgebrai interface miatt adott sorrendű műveleteket kapnak, a fát módositó algoritmus illesztési sorrendek felcserélésével nem foglalkozik /ilyen szempontból hátrány a relációalgebra nyelv/. Igaz viszont, hogy az illesztési algoritmus egy megadott készletből történő választása a helyettesítendő változó kijelölését /is/ jelenti. A TID algoritmus a SEQUEL nyelv szerkezete miatt nem foglalkozik a helyettesítendő változó kijelölésével, hi­ szen azt az egymásba ágyazott blokkok sorrendje eleve nem feltétlenül célszerűen - meghatározza. ■ Az SQL/DS statisztikai becslések alapján keresi a he­ lyettesítések optimális sorrendjét. A programozástechnikai megoldások közül kiemelkedő fontosságú a rekurzió. Ez érthető, hiszen a módszerek ál­ talában egyváltozós lekérdezésekre vezetik vissza a több­ változósakat, lépésenként csökkentve a változók számát. Ezt egészen pontosan láttuk a TID és a dekompoziciós al­ goritmusnál. A Palermo-algoritmusra ez nem igaz, ez inkább változónként egyszerű ciklust használó algoritmusnak tűnik. A Chang-Smith algoritmusnál és az SQL/DS algoritmusnál a felépített fák bejáráshoz, transzformálásához kell a rekurzió.

162

Mindenesetre célszerűnek látszik rekurziót biztositó magasszintü nyelven megirni az Optimizálót.

/Ez is a gya­

korlat, hiszen: LIDAS-MODULA-2, TID és SQL/DS-PL/1, INGRES-C/. Az implementációs eltérések közül kiemelkedően fontos­ nak tartjuk a "forditóprogram" megoldást /nem csak mi, rendszer alkotói isUCHAM 8ll/. Az előnyeiről volt már szó, most a hárányait emlitjük: a kódgeneráláshoz szükséges többletidő* • az Adatkezelő Modulok tárolásához szükséges lemez­ terület . CCHAM 81 ál (szerint a kódgenerálási többletidő méréseik szerint általában az optimizáláshoz szükséges idő 1/3 része, egy-egy Adatkezelő Modul pedig 1000-1500 byte-ot foglal le.

2.3. A tárolási részrendszer A tárolási részrendszer feladata a bemenő nyelvén érkező utasítások leképzése operációs rendszer file irás-olvasási utasításokra és,hogy az I/O-müvelet egységén - legyen az az adatbázis lapja bonyolult belső szerve­ zéssel, vagy egyszerűen egy adott reláció egy sorát tá­ roló file blokkja - eligazodjon. Igyekeztünk óvatosan fo­ galmazni, mert sokfajta seervezés lehetséges. A 7. ábrán /2.1./ a tárolási részrendszer bemenő nyelve az adatbázis assembler. Ez elég általánosan elterjedt gyakorlat, de nem kizárólagos - pl. relációalgebrai interface-t használó kisebb rendszereknél teljesen hiányozhat az Optimizáló réteg, és legfeljebb szintaktikus elemzés után azonnal a relációkat tároló file-ok elérése következik, a fel­ használó által adott műveletek alapján. Két rendszert - SQL/DS, INGRES, - valamennyire

163

részletesen ismertetünk, és néhány mikrogépes rendszert is emlitünk. A nagyobb rendszereknél külön foglalkozunk az adatbázis assemblerrel. 2.3.1. SQL/DS Az SQL/DS-ben az adatok szegmensekben tárolódnak. . • i ■ •< i mmmmmmrn

Egy szegmens fizikailag is egymást követő lapok sorozata. Egy szegmens egy vagy több VSAM ESDS file-ból áll, ezek blokkjai a lapok /2.I.I./. Egy szegmensen belül több reláció, index, belső katalógus információ is elhelyezked­ het, de minden struktúra csak egy szegmenshez tartozhat, nem lóghat át másikba. Az egy szegmenshez tartozó relációk tárolása a 4K byte méretű lapokon általában rendezetlenül történik, tehát egy lap több különböző reláció sorait tartalmaz­ hatja. /A rendezetlenségen változtat a már többször em­ lített CLUSTERING tulajdonságú index, melynek hatására a rendszer igyekszik a reláció sorait megadott sorrendben, egymáshoz közeli lapokon elhelyezni. A kapcsolat /ld. 1.1.1./ megadása is befolyásolja a sorok elhelyezését: ilyenkor a különböző relációkhoz tartozó összekapcsolt sorok kerülnek lehetőleg egymás közelébe./ Relációk csak a szegmens adat­ területén - tehát sorok számára fenntartott lapjain - he­ lyezkedhetnek el. Egy lap felépülése a pointertömbös szervezési technikát követi. Eszerint a lapon a sorok tárolása egymást követően folyamatosan történik. Mindegyik sor elejére a lap alján elhelyezett tömb egy eleme mutat, megadva a sor elejének eltolását a lap elejétől. Ha valamelyik beillesztett sort törölni kell, vagy megváltozik a hossza, a többi sor meg­ felelő eltolásával megoldható, hogy a sorok továbbra is folyamatosan helyezkedjenek el. Eltolásnál persze a sorok

164

elejére mutató pointerek értéke is megváltozik, de a sor­ számuk nem, tehát egy adott sor eltolását a lap elejétől továbbra is a tömb ugyanannyiadik eleme Őrzi. Ez igen lé­ nyeges a sorazonositók szempontjából. Ennél a szervezési technikánál ugyanis a sorazonositó két részből - a lap sorszámából /az SQL/DS-ben szegmensen belüli sorszámából/, és a pointertömb sorra mutató elemének sorszámából - áll. /Ez a lapszervezési technika eléggé gyakori az adatbázis­ kezelő rendszereknél - ezt használja pl. az SQL/DS mellett az INGRES vagy IDS és az IDMS is./ Egy tárolt sort a lapon minden esetben egy leiró prefix előz meg. Ebben van a reláció azonosítója, a kapcsolatot realizáló pointerek száma és maguk a pointerek, a sor tá­ rolt elemeinek száma, stb. Ez a prefix biztosítja a relá­ ció kiterjeszthetőségének vagy két reláció közötti kap­ csolat megadásának dinamikus lehetőségét /l.l.l./. Az adatelérést gyorsítják az - SQL/DS-ben "kép"-nek /image/ nevezett - indexek. Ezek agy reláció tetszőleges oszlopkombinációira szervezhetők, és akárhány lehet belő­ lük /ld. 1.1.1./. Index szervezésekor - ez a reláció létrejöttét köve­ tően bármikor kérhető - az SQL/DS a relációt tartalmazó szegmens erre a célra szolgáló lapjain hozza létre a fi­ zikai struktúrát. A lapok B-fa - konkrétabban VSAM KSDS /Key Sequenced Data Set/-szerű hierarchiát alkotnak, a levelekben a mutatók az adatlapokon elhelyezkedő sorok azonosítóit tartalmazzák. A kapcsolat - noha a felhasználói nyelvben szerepel /l.l.l./, és a tárolási részrendszer is felkészült rá végül is úgy tűnik, hogy kimaradt az SQL/DS fizikai elé­ rést gyorsitó repertoárjából. CCHAM 81^ szerint az Optimizáló /RDS/ nem használja őket, mert • a lényeges kapcsolat /essential link/ - ezen a

165

rendszer számára ismeretlen jelentésű/ felhasználó által definiált és fenntartött kapcsolatot árt - a relá­ ciós rendszer adatfüggetlenségének elvét sérti; a lényegtelen kapcsolat /nonessential link/ - ezt a rendszer hozza létre azonos értékű mezőkkel ren­ delkező sorok között, és o is tartja fenn - kar­ bantartása túl költséges. Valóban, ha egy mező ér­ téke megváltozik, nem elég, hogy hosszadalmas le­ het valamennyi vele kapcsolatban álló sorban a po­ intert törölni - ez azért oda-vissza pointerezéssel megoldható - de utána meg kell keresni az uj mezöértékhez tartozó sorokat és összekapcsolni őket. Most rátérünk az SQL/DS adatbázis assemblerének is­ mertetésére. Elöljáróban szeretnénk rámutatni egy lénye­ ges különbségre az SQL/DS és a többi rendszer Optimizálójának működése között. Vizsgáljuk meg ehhez, hogy zajlik általában egy lekérdezés végrehajtása egy relációs adat­ báziskezelő rendszerben! Az Optimizáló működésének eredményeképpen jön létre a válaszadás algoritmusa. A LIDAS esetében ennek első lé­ pése egy döntés;az X változó értékelésével kell kezdeni. A döntésből adódik az algoritmus kezdete: tekintem először az első olyan tagját a diszjunktiv normálformának, melyben részt vesz az X, és értéklistát készitek rá. Ez az algo­ ritmus két rutin hivását, és működésük összehangolását je­ lenti ciklusban: az egyik rutin a feltételnek eleget tevő sorokat választja ki, a másik az előző által visszaadott sorok alapján késziti az értéklistát. Mind a két rutin az adatbázis assembler része lehet. Következő lépés:tovább kell menni a normálformában, ugyanezt megismételni a kö­ vetkező tagra, azután a következő változóra, s.i.t. Nem elég tehát, hogy kész rutinok vannak a relációk soronkénti manipulálására: ezek működését vezérelni kell, fel kell

166

építeni a válaszadás algoritmusát az elemi műveletekből. Ezt a tevékenységet a LIDAS-nál vagy az INGRES-nél maga az Optimizáló látja el. Más a helyzet az SQL/DS esetében. Itt futtatható, "önálló" kódot kell létrehozni az Optimizálónak, hiszen mikor az Adatkezelő Modul működik, 6 már nem lesz a memó­ riában, nem vezérelheti a tárolási részrendszer rutinjainak működését - a kódnak tehát a vezérlési szerkezeteket, elá­ gazási lehetőségeket, stb. is tartalmaznia kell. Ebből adódik, hogy az SQL/DS esetében két szintről be­ szélhetünk: itt is megvan az adatbázis assembler rutinok készlete éppen úgy, mint a többi rendszerben, de ezek fe­ lett még egy Önálló nyelv van: az ASL /Access Specification Language/. A 27. ábra a 22. és 23. ábrán már bemutatott SZINTAX, OPTI és KÓDGEN modulok kapcsolatát világítja meg:

SQL

,_______i__________ SZINTAX szintaktikus elemzés nevek feldolgozása *-

Rendszerkatalógus

OPTI normalizálás költségbecslés *---KÓDGEN ASL program kódgenerálás 2_S

assembler /RSI / ___________ Jr_______ tárolási részrendszer /RSS/

27

ábra

167

Az OPTI tehát itt ASL nyelvű programot generál az algoritmus közvetlen végrehajtása /ill. adatbázis assembler rutinokkal való végrehajtatása/ helyett. Ez az ASL nyelvű program azután gépi kódú utasítássorozattá válik, melyben a vezérlési szerkezet RSI rutinhivásokon keresztül reali­ zálja az Optimizáló által tervezett algoritmust. Vegyük sorra először az RSI rutinokat! OPEN - relációban, indexben, kapcsolatban vagy korábban létrehozott listában keresés kez­ deményezése. Keresésazonositót ad vissza. NEXT - bemenő paramétere az OPEN által visszaadott keresésazonositó. Az OPEN-nel megkezdett ke­ resés következő elemét adja vissza. A NEXTnek paraméterként a keresés objektumára vo­ natkozó feltételt is be lehet adni. Ilyen­ kor a feltételnek megfelelő következő sort adja vissza. Indexben való keresésnél nem az index, hanem az indexelt reláció sorait adja vissza. * PARENT - paraméterei a NEXT-ével egyeznek meg, de ez a keresés a NEXT áital beállitott aktuális sorral /az OPEN-ben megadott/ kapcsolatban lévő sort adja vissza. * CLOSE - keresést zár le. CREATE/ ' DROP

J

üstát, kapcsolatot, indexet /képet/ készit, szüntet meg.

. INSERT - sort relációba vagy listába illeszt. * DELETE - sort relációból töröl, * BUILDLIST - paraméterei: keresésazonositó, feltétel, r^p^PZPttsÁa, A keresésazonositóval

168

megadott sorhalmaznak a feltételt kielégítő elemeiből rendezettség /csökkenő vagy növek­ vő/ sorrendű listát szervez. Mint látni fogjuk, az RSI elég tipikus adatbázis assembler, leszámítva a listakészités lehetőségét. Errq azért lehet szükség, mert mig az interpreter tipusu Optimizálók maguk szervezik ideiglenes file-jaikat /rendez­ ve, vagy hash-elve, vagy másképp/, az SQL-ben ez is az adatbázis assemblerre hárul. Vizsgáljuk most meg az ASL-nyelvet1 Nyilvánvalóan ennek átmenetet kell képeznie a nagyon magas szintű SQL és az alacsony szintű gépi kódú vezérlési szerkezetekből, /különböző tipusu ugrások/, értékadásokból és RSI rutinhivásokból álló "nyelv" között. Az ASL program eljrásokból épül fel. Ezekből az első mindig egy SCANPROC, az ASL alapvető programszerkezete. Felépítése: SCANPROC (paraméterek); ^ideiglenes objektumok definiálása} SCAN sepcif ikáció \WHERE feltétel} ; (jF korlátozás THEN} RETURN Ckifej ezések) ; END; Egy egyszerű példa: A SELECT NÉV FROM DOLGOZÓ WHERE RÉS ZLEGKÓD=50 lekérdezésnek a SCANPROC A; SCAN DOLGOZÓ WHERE RÉSZLEGKÓD=50; RETURN NÉV ; FNU ;

169

ASL program felel meg. Ugyanez a Részlegkód szerinti "Részlegindex" nevű indexet használva: SCANPROC A; SCAN DOLGOZÓ USING IMAGE RÉSZLEGINDEX AT 50; RETURN NÉV ; END; Az első változat fordítása egy PL/l-szerü nyelvre: PROC A; DCL STATUS STATIC INlT

('ZÁRVA') ;

IF STATUS='ZÁRVA' THEN DO; azonositó=OPEN(d OLGOZő ) ; STATUS='NYITVA'; END; sor=NEXT(azonositó , 4. RÉSZLEGKÓD=50^) ; IF sor=NULL THEN DO; CLOSE (azonositó) ; STÁTUS='NYITVA'; RETURN (NULL) ; END; _ : RETURN(sor.NÉv) ; END; A SCANPROC által definiálható ideiglenes objektumok relációk, listák, indexek, és konstansok lehetnek. Eze­ ket az ASL BUILDPROC /és BUILDVALUEPROC/ eljárásai hoz­ zák létre. Lássunk erre is egy példát! A SELECT NÉV,RÉSZLEGKÓD FROM DOLGOZÓ ORDER BY RÉSZLEGKÖD lekérdezésnek megfelelő ASL program pl.:

170

SCANPROC A; LET LIST

l (n ,r )=B;

SCAN L; RETURN (n ,r ) ; END; BUILDPROC B; SCAN DOLGOZÓ; INSERT INTO LISTíNÉV,RÉSZLEGKŐD SORTED BY RÉSZLEGKÓD; END; Ennek a "fordítása" két eljárást tartalmaz dikban természetesen BUILDl ISY hívással. Egy példa illesztésre:

majd, a máso­

SELECT NÉV,RÉSZLEGKÓD FROM DOLGOZÓ,RÉSZLEG WHERE DOLGOZÓ.RÉSZLEGKÓD=RÉSZLEG.RÉSZLEGKÓD AND RÉSZLEG.CIM='BUDAPEST' Legyen a Részlegkód szerint index úgy a Dolgozó, mint a Részleg relációban! Ekkor algoritmusunk a következő lesz: kiválasztjuk az összes budapesti részleget, majd a Rész­ legkód alapján az adott részlegben alkalmazott minden egyes dolgozó nevét a Dolgozó relációból. Ehhez uj ASL konstruk­ ciót kell bevezetni. A FOREACH TUPLE LET azonositő=scanproc-név (paraméterek) RETURN ciklusban hivja az adott nevű eljárást mindaddig, mig az nem ér a keresés végére, majd visszatér a FOREACH előtti SCAN-be: SCANPROC A; SCAN RÉSZLEG USING IMAGE RÉSZLEGINDEX AT 'BUDAPEST'; FOREACH TUPLE LET

e :!Étt=B

(RÉSZLEGKŐD) ;

RETURN DNÉV,RÉSZLEGKÓD ; END;

171

SCANPROC

-

b (r KÓd );

SCAN DOLGOZÓ USING IMAGE DOLGOZÓINDEX AT RKÓD; RETURN (.NÉV) ; END; Ennek az ASL programnak a fordítása: PROC A; DCL STATUS STATIC INIT ('ZÁRVA') ; IF STATUS»'ZÁRVA' THEN DO; azonositó=OPEN Cr ÉSZLEGINDEX,'BUDAPEST') ; STATUS='NYITVA'; X: sor=NEXT(azonosító) ; IF sor=NULL THEN DO; CLOSE(azonositó) ; STATUS='ZÁRVA'; END; END; sori=B(sor.r é s z l e g k ó d ) ; IF SORl-NULL THEN GO TO X; RETURN(sori.NÉV,SOr,RÉS ZLEGKÓü); END; PROC b (r KÓd ) ; DCL STATUS STATIC INIT (' ZÁRVA') ; IF STATUS='ZÁRVA' THEN DO; azonositó=OPEN(DOLGOZÓINDEX,RKÓd ) ; STATUS='NYITVA'; END; sor=NEXT(azonosító) ; IF sor=NULL THEN DO; PT.OQ'P (a^nnriqj t 1^);

STATUS»'ZÁRVA'; END; RETURN sor ; END;

172

Úgy az előző forditás eljárása, mint az ebben a pél­ dában látott két eljárás szerkezete igen hasonló. A SCAN utasitás forditása az IF STATUS=/ZÁRVA'

END; sor=NEXT; IF SOR=NULL END; szerkezet. A FOREACH forditása a példa A eljárásában jól követhető. A GROUP BY és a halmazműveletek ASL fordítására nem térünk ki. Szándékunk pusztán a nyelv stílusának érzékel­ tetése, és mind a két forditás /SQL-ről ASL-re és ASL-ről gépi kódra/ elvégezhetőségének illusztrálása volt. CASTR76, CHAM 81, LÓRI793 2.3.2. INGRES Az INGRES - az SQL/DS-től eltérően - minden relációt kü­ lön file-ként tárol. Egy adatbázison belül négy file-tipus létezik: Az adminisztrációs file az adatbázis adminisztrátor azonosítóját és inicializáló információt tartalmaz. Ez az egyetlen file-tipus, mely nem relációt tárol. A katalógus /rendszer/ relációk file-jal a rendszer adatainak leirását tartalmazza. Tulajdonosuk az adatbázis adminisztrátor, és tartalmukat bármelyik INGRES felhasz­ náló lekérdezheti egyszerű RETRIEVE-vel, módosítani azon­ ban csak az adatdefiniciós parancsok képesek. Az egyes

173

relációk - RELATION, ATTRIBUTE, INDEX, PROTECTION, INTEGRITY neveiből tartalmuk elképzelhető. Az adatbázis adminisztrátor relációi

a felhasználók

számára lekérdezhetők, de nem módosíthatóak - hacsak egyes felhasználóknak az adatbázis adminisztrátor nem engedélyezi. A felhasználói reláció tulajdonosa a létrehozó fel­ használó, és más felhasználó csak az ő engedélyével férhet hozzá. A file-ok 512 byte hosszú rekordokból állnak. Ez ope­ rációs rendszer kötöttség, minden UNIX file fizikailag nem feltétlenül egymás után következő 512 byte-os rekordokból áll. Többek között a rövid lapmérettel indokolja CSTON 76l a relációk egymástól elkülönített tárolását. Az adatbáziskezelő és az operációs rendszerek kapcso­ latával általánosságban foglalkozó CSTON 811 cikkből két idevágó gondolatot emelünk ki: ‘ a virtuális memóriát kezelő operációs rendszerek /a UNIX ilyen/ saját lapozási algoritmust használ­ nak. Ez rendszerint LRU, ami az esetek jelentős részében elég jó, az INGRES esetén azonban sokszor van szükség: . 1. újra nem használandó blokkok soros olvasására; 2. blokkok ciklikus olvasása ./1,2, ... ,n,l,2 ,.. .,n,... / ; 3. újra nem használandó blokkok közvetlen elérésére. Ilyen esetekben az LRU rossz, ezért az adatbázis­ kezelő rendszerek általában belső lapozási mecha­ nizmust használnak az operációs rendszer lapozása felett - ami viszont többletköltség * a file rekordjai logikai sorrendjének és folytonossá­ gának eltérése a fizikai szerkezettől hatékonyság­ csökkenéshez vezet. Végső soron, az értékelő CSTON 80l cikk szerint az INGRES

174

alkotói a tévedések közé sorolják, hogy a UNIX f H ő ­ kezeléséhez alkalmazkodtak, és nem alakítottak ki saját file-kezelést. A lapszervezés az SQL/DS-ével egyező, annyi eltérés­ sel, hogy az INGRES file-okon kétfajta laptipus létezik: az elsődleges lapokat a file létrehozatalakor foglalja le a rendszer. Ehhez pointerrel lehet hozzáláncolva egy vagy több másodlagos lap. Ezek egy-egy elsődleges /vagy másodlagos/ lap túlcsordulásakor keletkeznek. A tulcsordulási lapok létezése az INGRES file-szervezési módjaival függ össze. Egy reláció hash-elt vagy index-szekvenciális file, illetve ezek süritett változata - itt az adatokat a file-ra helyezés előtt összenyomják lehet. Alapvetően kisebb relációk, ill. ideiglenes re­ lációk részére létezik a rendezetlen tárolási mód. Mi­ vel az INGRES az indexet is relációként kezeli, ennek szervezésére ugyanaz vonatkozik, mint bármely más re­ lációéra /ld. még 1.1.2/. Az INGRES az adatbázis assemblert AMI-nak /Access Method Interface/ nevezi. Kilenc rutinból áll, ezeket ismertetjük röviden: OPEN /azonositó,mód,relációnév/. Az "azonositó" a program számára azonosátja a "mód"-tói függően olvasásra vagy módosításra megnyitott "relációnév" relációt. GET /azonositó, sorazanositó 1, sorazonositó 2, sor, mód/. A "mód"-tól függően vagy sorban "sorazonositól"-től "sorazonositó2"-ig adja vissza a "sor"-ban a sorokat, /szekvenciális elérés/, vagy csak a "sorazonositól" azonositóju sort /közvetlen elérés/. FIND /azonosító, kulcs, sorazonositó, kulcstipus/. A "kulcs" alapján a "sorazonositó" értéket adja vissza. A "kulcstipustól" függően fogad el a "kulcs" értékű sor hiányában ahhoz legközelebbi alsó vagy felső kulcsértéket.

175

PARAMD /azonosító, leírás/. Ez a rutin relációra, a RARAMI /azonosító, leírás/ rutin pedig indexre adja vissza a kereséshez használható kulcs /Id. FIND/ jellem­ zőit. INSERT /azonosító, sor/. Beillesztés. REPLACE /azonosító, sorazonositó, uj sor/. Módosit. DELETE /azonosító, sorazonositó/. Töröl. CLOSER /azonosító/. Reláció lezárása. CSTON 763 megjegyzi, hogy a fizikai tárolás és az adat­ bázis assembler fenti szervezése jó lehetőséget ad a rend­ szer uj file-szervezési módokkal történő bővítésére. Való­ ban, az interface-en pusztán a FIND, PARAMI és PARAMD ru­ tinokban lehet szükség változtatásra, feltéve, hogy az uj elérési mód alkalmazkodik az egységes lapszervezéshez és a sorazonositási mechanizmushoz. 2.3.3. Mikrogépes rendszerek A mikrogépes relációs adatbáziskezelő rendszereket összehasonlító cikkében F. Maryanski megállapítja: "Ha valaki egy standard adatbázis tankönyvet kinyit a fileszerkezeteket leiró fejezetnél, tiz-tizenöt különböző szervezési módot talál. Minden szervezési módhoz léte­ zik .legalább egy azon alapuló mikrogépes rendszer". CMARY 83] ügy tűnik, a legelterjedtebbek a B-fák^ Megítélé­ sünk szerint fő előnyük abban rejlik, hogy egyszerre biztosítanak gyors közvetlen hozzáférést kulcs alapján, és emellett a nagyság szerint soros elérést is támogat­ ják. Ilyen "kétarcú" elterjedt szervezési módként csak az index-szekvenciális file-t említhetnénk /figyelembe véve, hogy a dinamikus, lineáris, stb. hash még elég uj^ azonban ennek nehézkes és rossz esetben lassú túl­ csordulás kezelése nem versenyezhet a B-fa elegáns, a túlcsordulást elkerülő dinamikus önátszervező technikájával.

176

/Azért Megjegyezzük, hogy az

INGRES

alkotóinak £HELD 783

cikke néhány valós érvet tartalmaz az index-szekvenciális file mellett: a B-fában tárolt rekordokra mutató másodlagos indexek csak szimbolikus indexeket tartalmazhat­ nak, hisz egy rekord fizikai helye állandóan vál­ tozhat; a konkurrens hozzáférés szervezése bonyolultabb a B-fára, ugyanis egy uj rekord beillesztése a teljes indexstrukturát megbolygathatja. Végső soron, az ellenvetések ellenére, CSTON 803 önkri­ tikusan elismeri, hogy a B-fa előnyös tulajdonságai - nem kell időnként újraszervezni, mint az index-szekvenciális file-t; egy adat eléréséhez beolvasandó lapok száma jól becsülhető - ellensúlyozza a hátrányait./ Az általános B-fa megoldáson belül persze sok külön­ böző változat lehetséges. A TITAN pl. nem is a kulcsot, hanem annak hash-függvényét tartja a B-fa index részében /a prefix B-fák alapgondolatához hasonlit az ötlet/, ez­ zel hely-megtakaritást érve el CFALQ 823. Ugyancsak B-fát használ az /RDBAS. [HERM 833 és a LIDAS CREBS 83l rendszer is. Elég sok rendszer szervez egyszerűen szekvenciális filc-okat, melyeket alkalmanként rendez / RQL[MAST 833, MRDBS CREVE 833, stb/. A forgalmazott rendszerek ezt nem engedhetik meg magunknak. A dBASE I I pl. index file szer vezését teszi lehetővé egy paranccsal. A z index kulcs sze rinti lekérdezéseknél biztosit gyors /a leirás szerint 2 másodpercen belüli/ válaszidőt - érdekes viszont, hogy illesztésnél a rendszer nem használ indexet C A S H T 813. Nagyon egyszerű - bár mikrogépesnek megoldást alkalmaz a VIDEBAS rendszer.

Ez

nem az

nevezhető összes

-

177

relációt index-szekvenciális file-on tárolja, méghozzá többször is, különböző kulcsok szerint rendezve, és szer­ vezve az indexet. Mindehhez persze nagylemezeket használ. /A rendszer értékelésénél persze figyelembe kell venni, hogy készitoi osztott adatbáziskezelö irányába kívánják fejleszteni./ Jellegzetessége, hogy a módosítások nem kerülnek be azonnal a rendszerbe, hanem a "különbség" file-on tárolódnak, és egyszerre, a periodikus újraszer­ vezést végző programok viszik be okét. A megoldásnak sok előnye van: visszaállíthatóság, az index-szekvenciális file-ok nem csordulnak túl, stb. ÜBLAN 831, A PRECjl/P rendszer hash-elt file-okban tárolja a relációit. Olyan hash technikát alkalmaznak mely megőrzi a rendezettséget. ÜDÉÉN 83l Nem népszerű az adatösszenvomás a relációs rendszerek körében/üKIM 79lcsak az INGRES-t és a PRTV-t emliti ellen­ példaként/. Ezért különösen érdekes a C k a m b __831 cikkben leirt, 1.1.4.-ben ismertetett rendszer. Ez is egyszerű szekvenciális file-lal dolgozik, de összenyomja az adato­ kat. Készitoi szerint ezért nincsenek hatékonysági prob­ lémáik. Még egy megjegyzés a mikrogépes rendszerekről: ezek éppúgy, mint a nagygépes relációs adatbáziskezelok a rend­ szer katalógusát közönséges relációkként tárolják és keze­ lik. A megoldásnak az előnyei nyilvánvalóak.

178

I R O D A L O M

AHO 79

AHO A.V. SAGIV Y. - ULLMAN J.D. "Efficient optimization of a class relational transactions", ACM TODS 4,4/1979/, pp. 435-454.

ALAG 81

ALAGIC S. - KULENOVIC A: "Relational Pascal data base interface", The Computer Journal 24, /1981 / pp. 112-117.

ALLM 82

ALLMAN E. - STONEBRAKER M. "Observations on the evolution of a software system", Computer, June 1982, pp. 27-32.

APSI 83

APSINGIKAR V. - PHULE S. "Development of a portable relational DBMS", in ÜWORK 833 pp. 221-244.

ASHT 81

ASHTON-TATE Corp. "dBASE II Assembly language relational database management system",/1981/

ASTR 75

ASTRAHAN M.M. - CHAMBERLIN D.D. "Implementation of a Structured English Query Language", CACM 18, 1 0 /Oct.1975/ pp. 580-588.

ASTR 76

ASTRAHAN M.M. et.al. "System R: relational approach to database management", ACM TODS 1,2 /June 1976/ pp. 97-137.

BLAN 83

BLANKEN H.M. "Another Approach to DBMS implemen­ tation", in C WORK 833 pp. 501-524.

179

BLAS 77

BLASGEN M.W. - ESWARAN K.P. "Storage and access in relational data base", IBM Syst. J. 4/1977/ pp. 363-377.

BLAS 81

BLASGEN M.W. "System R: an architectural overview" IBM Syst. J. 20,1/1981/ pp. 41-62.

BRAG 83

BRAGGER R.P. et. al. "GAMBIT: an interactive database design tool for data structures, integrity constraints and transactions", in CZEHN 833pp. 65-96.

CHAM 76

CHAMBERLIN D.D. et. al. "SEQUEL2: unified approach to data definition, manipulation and control", IBM J. of Res and Dev#20,4/1976/ pp. 560-575 + 21,1/1977/ pp. 94-95.

CHAM 81

CHAMBERLIN D.D. et. al. "A history and evaluation of System-R", CACM 24,11/Oct.1981/ pp. 632-646. j

CHAM 81

CHAMBERLIN D.D. et.al. "Support for repetitive transaction and ad hoc queries in System R", ACM TODS 6,1/March 1981/ pp. 70-94.

CHEN 76

CHEN P.P. "The entity-relationship model. Toward a unified view of data", ACM TODS 1,1/March 1976/ pp. 9-36.

CODD 70

CODD E.F. "A relational model for large shared data banks", CACM 13,6/June 1970/ pp. 909-917.

CODD 71a

CODD E.F. "A data base sublanguage founded on the relational calculus", in ACM SIGFIDET Workfihnn on Data Description, Access and Control, /1971 / pp. 35-68.

180

CODD 71b

CODD E.F. "Further normalization of the data base relational model"/ in Data Base Systems, Courant Computer Science Symposie, Vol. 6, Prentice-Hall, Englewood Cliffs, N.J., May 1971

CODD 71c

CODD E.F. "Relational completeness of data base sublanguages" in Data Base Systems, Courant Computer Sicence Symposie, Vol. 6, Prentice-Hall, Englewood Cliffs, N.J., May 1971.

CODD 79

CODD E.F. "Extending the database relational model to capture more meaning", ACM TODS 4,4 /December 1979/ pp. 397-434.

CODD 82

CODD E.F. "Relational database: a practical foundation for productivity", CACM /February 1982/ pp. 109-117.

25,2

DATE 77

DATE C.J. "An introduction to database systems" second edition, Addison-Wesley 1977

DEEM 83

DEEN S.M. "Some design aspects of Preci/P personal database system", in CWORK 83‘] pp. 441-456.

DIEC 81

DIECKMANN E.M. "Three relational DBMS", Datamation September 1981, pp. 137-146.

A

pme

n

APV4EAC H

DEiME 81

u h c k

/

w

ß,.n.

P e J i R U M O H H feie

6a5H

A

a h h h

x “,

*A.

DEMETROVICS J. - GYEPESI Gy. "Általános füg­ gőségek és lekérdezéssel kapcsolatos algorit­ musok relációs adatmodellekben", SZTAKI Tanulmányok 118/1981

181

EBER 83

EBERLEIN W. - STEINBAUER D. "A menu-driven relational database system for a micro-computer", in CWORK 831 pp. 187-206.

EPST 77

EPSTEIN R. "A tutorial on INGRES", Memorandum No. UCB/ERL M 77/25 15 December 1977

FALQ 82

University of California, Berkeley FALQUET G. et.al. "A portable relationá- data base management system for microcomputer", Microprocessing and Microprogramming 9 /1982/ pp. 17-25.

HALL 76

HALL P.A.V. "Optimization of a single expression in a relational data base system", IBM J. of Res. and Dev. 20,3/1976/ pp. 244-257.

HELD 78

HELD G. - STONEBRAKER M. "B-trees re-examined", CACM 21,2/1978/ pp. 139-143.

HERM 83

KERMIDA R. - RUZ J.J. "Assisted access to data­ bases: the RDBAS approach", in LWORK 831 pp. 419-440.

KAMB 83

KAMBAYASHI Y. et.al. "A micro-computer-based relational database system with database pre­ paration facilities", in [[WORK 83l, pp. 457-476.

KENT 83

KENT W. "A simple guide to five normal forms in relational database theory", CACM 26,2 /February 1983/ pp. 120-125.

KIM 79

KIM W. "Relational database systems" Computing Surveys 11,3/Sept. 1979/ pp. 185-211.

KISS 83

KISS O. "MADAM koncepció", SZTAKI Working Papers 11/63, 1983

182

KNUT 33

KNUTH E. - RADÓ P. - TÖTH Á. "Az SDLA előzetes ismertetése", SZTAKI Tanulmányok 104/1980

LACR 83

LACROIX M. - PIROTTE P. "Relational model and Relational systems" in HWORK 83l

LIPS 79

LIPSKI JR,W. "On semantic issues connected with incomplete information databases", ACM TODS 4,3/Sept, 1979/ pp. 262-296.

LORI 79

LORIE R.A. - NILSON J.F. "An access specification language for a relational data base system", IBM J. Res. and Dev. 23,3/May 1979/ pp. 286-298.

MARY

MARYANSKI F. "Design, implementation, and use of relational DBMS on micro-computers" in CWORK 833 pp. 29-54.

MAST 83

MASTERS S. - DRISCOLL J.R. "RQL. A relational data base system for a low end micro-computer configuration", in CWORK 833 pp. 103-128.

ME RR 83

MERRETT T.H. - CHIU G.K.W. "MRDSA: full support of the relational algebra on an APPLE II.", in CWORK 833 pp. 385-402.

PATN 83

PATNIK I.M. et.al. : "Access path query language for relational database systems", SoftwarePractice and Experience 13,/1983/ pp. 661-670.

REBS 82

REBSAMEN J. - REIMER M. - URSPRUNG P. - ZEHNDER C .A . "LIDAS - a database system for personal computer LILITH" Institut für Informatik der ETK Zürich 1982

183

REBS 83

REBSAMEN J. et.al. "LIDAS - the database system for the personal computer Lilith", in CWORK 83] pp. 291-316.

REIM 83

REIMER M. "Implementation of the database prog­ ramming language Modula/R on the personal computer Lilith", in CZEHN* 83] pp. 49-64.

REVE 83

REVELL N. - SIMS R.J.: "MRDBS: a relational development system for a micro-computer", in CWORK 83] pp. 245-260.

SAND 81

SANDBERG G. "A primer on relational data base concepts", IMB Syst. J. 20,1/1981/ pp. 23-40.

SCHM 77

SCHMIDT J.W. "Some high level language constructs for data of type relation", ACM TODS 2,3/Sept.1977/ pp. 247-261.

SMIT 75

SMITH J.M. - CHANG P.Y. "Optimizing the performance of a relational algebra database interface", CACM 18, 10/1975/ pp. 568-579.

SNYD 81

SNYDERS J. "New trends in DBMS", Computer Decisions February 1982, pp. 100-133.

STON 76

STONEBRAKER M. - WONG E. - KREPS P. "Tne design and implementation of INGRES", ACM TODS 1,1 pp. 189-221.

STON 80

STONEBRAKER M. "Retrospection on a database system", ACM TODS 5,2/June 1980/ pp. 225-240.

184

STON 81

STONEBRAKER M- "Operating system support for database management", CACM 24,7/1981/ pp. 412-418.

TODD 76

TODD S.J. "The Peterlee Relational Test Vehicle-a system overview", IBM Syst. J. 15,4/1976/ pp. 285-308.

URSP 83

URSPRUNG P. - ZEHNDER C.A. "HIQUEL: an interactive query language to define and use hierarchies", in [ZEHN 831 pp. 97-118.

WELT 81

WELTY C. - STEMPLE D.W. "Human factors comparison of a Procedural and a Nonprocedural Query Language", ACM TODS 6,4/December 1981/ pp. 626-649.

WONG 76

WONG E. - YOUSSEFI K. "Decomposition - an algorithm for query processing", ACM TODS 1,3/1976/ pp. 223-241.

WORK 83

WORKSHOP on Relational DBMS Toulouse /France/ February 14-15, 1983 /INRIA edition/

ZEHN 83

ZENHDER C.A. /editor/ "Database techniques for professional workstations", Institut für Informatik der ETH, Zürich 1983

ZLOO 77

ZLOOF M.M. "Query-by-Example: a data base language", IBM Syst.J. 16,4/1977/ pp. 324-343