1. A felhasználói interface
1.1. Adatdefiniciós lehetőségek
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]
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 további utalást tartalmazhat a fizikai adatel
helyezésre. A CLUSTERING tulajdonság előirja a rendszernek, hogy az index definiálta sorrendben egymáshoz közel elhelyez
kedő sorok az 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^
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ó./
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ó
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'
f C F a M