Az_SQL_nyelv leirás

Oldalszám:
1/11

Ugrás:

Keresés:


Az SQL nyelv
Általános áttekintés az SQL nyelvről
Az előző fejezetekben a relációs adatmodellre támaszkodó állománykezelő dBase rendszerek múködését és használatát vettük át. A dBase rendszerek áttekintése során tapasztalhattuk, hogy a megvalósított integritási és múveleti elemek mennyire eltérnek a relációs adatmodellnél megismert irányelvektől, melynek ugyan nagyban lecsökkentették a rendszer erőforrásigényét, és széles körben elterjesztették a relációs elveket, azonban e rendszerek csak igen kicsi, korlátozott méretú és igényú rendszerek kezelésére alkalmas. A nagyobb mértékú, érzékenyebb integritási és védelmi igényekkel fellépő rendszerek esetében a dBase alapú adatbáziskezelők nem nyújtanak megfelelő megoldást. Ezen esetekben egy tekintélyesebb, igazi relációs alapokon nyugvó adatbáziskezelőt kell kiválasztani.
Mint már korábban is mondtunk a relációs adatbáziskezelők a mini gépek kategóriájából fejlődtek ki. Az első RDBMS, a System/R kidolgozásánál fontos szempont volt, hogy minél tökéletesebben megvalósítsák Codd elveit, a relációs adatmodell és a relációs algebra elemeit. A kezelő felület esetében tehát egy olyan parancsnyelvet kellett kidolgozni, amely lehetővé teszi a relációknak, mint rekord halmazoknak a kezelését, melyben a lekérdezésekben deklaratív formában lehet megadni a kívánt eredményreláció tulajdonságát, felhasználva a relációs algebra ismert múveleteit, mint pl. a szelekció, projekció vagy összekapcsolás.
Ez a kezelő felület lényegesen eltér a hagyományos rekord orientált, ciklusokat és elágazásokat tartalmazó lekérdező felületektől. A System/R-ben megvalósított relációs algebrán alapuló kezelő felületet SEQUEL-nek nevezték el, utalva e nyelv néhány alapvonására. A SEQUEL, mint rövidítés a Structured English Query Language kifejezésre utal, azaz jelzi, hogy ez egy strukturált, az angol nyelvre épülő lekérdező nyelv. A parancsok kulcsszavai értelmes, a múvelet jelentéséhez közel álló angol szavak, melyekből a parancsok, mint mondatok hozhatók létre. Természetesen igen szigorúan kötött e mondatok szerkezete, emiatt is nevezhető strukturált nyelvnek. A lekérdezés szó azért szerepel a rövidítésben, mert ugyan e nyelv többre is alkalmas, mint puszta lekérdezés, azonban a nyelv igazi ereje a lekérdezési részben, a relációs algebrára épülő komponensben rejlik. E nyelv részleteit elsőként 1974-ben publikálták. Az elnevezés a későbbiekben az SQL-re változott, de a nyelv felépítése, múködési filozófiája változatlan maradt.
A System/R után következő RDBMS rendszerek a belső múködési elveken kívül e kezelő nyelvet is átvették, értve ez alatt a kulcsszavakat és az operátorokat is. Emellett természetesen voltak egyéni, egyedi megvalósítások is, mint például a DEC RDB kezelő nyelve, melyek más szintaktikára épültek, azonban e nyelvek idővel mind eltúntek, nem bírták a versenyt az SQL-lel szemben. Az SQL lassan egyeduralkodóvá vált az RDBMS piacon, emiatt az igazi adatbáziskezelő szolgáltatásokat nyújtó rendszereket szokás SQL adatbázisoknak is nevezni. A SQL elterjedésének és előnyeinek köszönhetően szabvánnyá vált a relációs adatbáziskezelők világában, s azóta elterjedése még jobban fokozódik, s lassan a korábbi xBase-es termékek is mind bevonják rendszerükbe az SQL alapú kezelő felületet is.
Az SQL első szabványosítási lépése az ANSI nevéhez és az 1986-os évhez kötődik. A rákövetkező évben a nemzetközi szabványhivatal az ISO is felvette és megjelent az ISO SQL szabvány. A gyakorlati élet fejlődéseit követve többször, pontosabban napjainkig kétszer módosították a szabványt, először 1989-ben, majd utána 1992-ben. Az egyes SQL szabványok megkülönböztetésére meg szokták adni az évszámot is, s így hivatkozhatunk SQL86-ra, SQL89-ra, vagy éppen SQL92-re.
Az SQL szabványok valójában a piacon megjelenő RDBMS-ek kezelő felületeit kívánják mederben tartani, vagy éppen követni. Az SQL86 éppenséggel csak a legfontosabb elemeket gyújtötte össze a megvalósulásokból, ezért már megalkotásakor is több olyan RDBMS volt, mely kezelő nyelve többet tudott a szabványnál. Az azóta készült RDBMS megvalósítások egyre többet nyújtanak a múveletek és az integritási feltételek, és a vezérlő utasítások terén is. A lemaradást igyekeztek bepótolni az újabb. SQL89 szabvánnyal, sőt az SQL92-t már előre mutatási céllal készítették. Az SQL92 egy sor olyan elemet is tartalmaz, melyet a legfejlettebb RDBMS-ek is csak a közeljövőben tudnak megvalósítani.
Éppen ezért a SQL92 esetében a szabvány is különböző teljesítettségi fokot állapít meg:
entry level: alapszint, mely az SQL89 kiegészítve a kulcsra és értéktartományra vonatkozó integritási feltételekkel intermediate level: közbenső szint full level: a teljes szint, mely minden elemet tartalmaz
Az egyes SQL szabványokról elmondható, hogy viszonylag kompatibilisek egymással alulról felfelé, azaz az SQL86 ismerete felhasználható az SQL92-ben is, ugyanis az újabb szabványok a régi elemeket rendszerint változatlanul hagyják, s a változás az újabb elemek befúzéséből ered. A SQL szabványokra épülő piacon megjelenő adatkezelő nyelveket szintén SQL nyelveknek nevezik, azonban tudnunk kell, hogy a megvalósított nyelvek a szabványos elemek mellett egyedi elemekkel is rendelkeznek, hiszen az SQL szabvány átfogó jellege ellenére több olyan dologra nem tér ki, melyek a megvalósított rendszerekben viszont szükségesek, mint pl. az adattípusok fajtái és jelölésének kérdése.
Így valójában egy konkrét RDBMS kezelő nyelvének használatához három szintet kell bejárni. Mindenek előtt ismerni kell a relációs modellt, a relációs algebrát. Ezután ismerni kell a SQL szabványt, majd legvégül meg kell ismerkedni a kiválasztott RDBMS SQL alapú kezelő nyelvével. Ha ezt az utat követjük, akkor egy másik SQL alapú rendszerre való átállást igen hatékonyan és gyorsan megoldhatjuk.
Az SQL részletezése előtt azonban célszerú előbb az SQL általános leírását, jellemzését áttekinteni, illetve összefoglalni. Mint már az előzőekből kiderült az SQL a relációs adatmodellen alapuló adatbázisok kezelő nyelve, méghozzá szabványosított nyelve. Ebből egyrészt következik az, hogy az SQL-t nem tekinthetjük adatbáziskezelő rendszernek, hiszen az SQL annak csak egy komponense, a kezelő nyelvezete. Egy RDBMS az SQL mellett rendelkezhet más kezelő nyelvezettel is, mint pl. az RDB rendszernek (DEC VMS alapon futó RDBMS) is volt SQL alapú és saját kezelő nyelve is.
A másik lényeges jellemzője az SQL-nek, hogy kimondottan az adatbáziskezelés, az adatkezelés megvalósítására szolgál, tehát nem tartalmaz algoritmikus elemeket, mint pl. a ciklusszervezés vagy elágazások, illetve nincsenek benne a felhasználói képernyőkezelésre, a normál file kezelésre vonatkozó utasítások. Emiatt mondhatjuk, hogy az SQL nem algoritmikus nyelv, ellentétben a C vagy a Pascal nyelvvel. Az adatkezelésnél az SQL a relációs algebrára épül, tehát a relációkat halmazokon végzi, s az SQL-ben egész relációkra vonatkozó múveletek adhatók ki. Mint ismert a hagyományos programozási nyelvek a rekordorientált adat megközelítést használják. E különbség kihangsúlyozására nevezik az SQL-t halmazorientált nyelvnek.
Az SQL és a relációs adatmodell kapcsoltára vonatkozólag megemlíthető, hogy az SQL több különböző szinten keresztül közelíti az elméleti relációs adatmodellt, amiben benne van, hogy bizonyos elemeket nem tartalmaz, ezért az SQL a relációs adatmodellnek csak részleges leképzése.
Az adatkezelési funkciókon belül az SQL-nek a legszélesebb lehetséges igényhalmazt ki kell elégítenie, hogy az SQL önmagában használható legyen, ne kelljen mellé más kiegészítő nyelv. Az eddig ismert adatkezelési funkciókra hivatkozva az SQL-ben is elvégezhetőnek kell lennie az adatszerkezetek definiálásának, ami megfelel a már általánosságban említett DDL nyelvi komponensnek, mely segítségével létrehozhatók és módosíthatók többek között a különböző relációk, domainek és integritási feltételek. Mivel a létező RDBMS-ekben a relációk elnevezésére inkább a táblázat kifejezés honosodott meg, ezért a továbbiakban, ha az RDBMS-ben fizikailag tárolt relációra gondolunk, akkor a táblázat elnevezést fogjuk használni.
A DDL mellett az SQL része az adatkezelő, úgynevezett DML csoport is, melyben elvégezhetők a táblázatokban tárolt adatok módosítása, törlése vagy új adatok felvitele.
Ugyan legtöbbször az adatok lekérdezését is ebbe a körbe veszik, de az SQL-ben, a relációs modellben betöltött fontossága miatt külön csoportot alkotnak a lekérdező utasítások, melyre a Query elnevezést használjuk. A megvalósított RDBMS kezelő nyelvek hatásának köszönhetően az SQL tartalmaz a relációs adatmodellhez szorosan nem kötődő utasításokat is, melyekkel a múveletek végrehajtását szabályozhatjuk, vezérelhetjük. Emiatt a negyedik utasításcsoportot adatvezérlő csoportnak is nevezik, melynek jelölése a DCL.
Az SQL utasításokat több különböző módon is eljuttathatjuk az RDBMS-hez. A legegyszerúbb módszer egy interaktív SQL parancsértelmező használata, mely közvetlenül kapcsolódik az RDBMS-hez. A promptnál kiadhatjuk az SQL parancsot, melynek rögtön végre is hajtódik, és az eredményt a terminálra kiírva kapjuk meg. Mivel így csak adatkezelő utasításokat adhatunk ki és feltételezi, hogy a felhasználó ismeri az SQL-t, ez a módszer nem alkalmas normál alkalmazói programok készítésére. Ehhez az SQL utasításokat algoritmikus elemekkel kell kibővíteni, melyre kétféle lehetőség is kínálkozik. Egyrészt magát az SQL-t lehet egy létező algoritmikus nyelvbe beépíteni, beágyazni, másrészt az SQL-t lehet kibővíteni algoritmikus elemekkel. Természetesen ez utóbbi esetben a kapott nyelv már igen messze esik az SQL szabványtól. A valóságban viszont mindkét eset előfordul.
Összefoglalóan a következőket állapíthatjuk meg az SQL-ről:
relációs RDBMS kezelő nyelv szabvány, nem RDBMS relációs algebrán alapszik szöveges, nem algoritmikus, előíró jellegú utasításokat tartalmaz halmazorientált négy utasításcsoportot tartalmaz: adatdefiníciós adatlekérdező adatkezelő adatvezérlő kiadható interaktívan és algoritmikus környezetbe építve
Az SQL általános áttekintése után az SQL utasításokat vesszük sorra, mégpedig elsőként a legegyszerúbb SQL86 szabványt, mivel sok esetben már ez is elegendő erővel rendelkezik utasításaink kiadásához köszönhetően a kompatibilitásnak, s egyszerúsége miatt könnyebben is elsajátítható. Az SQL86 ismertetése után röviden összefoglaljuk az SQL92 legfontosabb változásait és lehetőségeit.
Az SQL86 szabvány DDL utasításai
Elsőként a DDL komponenst vesszük át, hiszen az alkalmazások során is előbb meg kell alkotni a struktúrákat, az üres adatszerkezeti elemeket, hogy a későbbiek folyamán fel tudjuk tölteni azokat adatokkal, illetve fel tudjuk használni a bennük letárolt adatokat. A relációs adatmodell esetére vonatkoztatva ez azt jelenti, hogy előbb létre kell hoznunk a táblázatokat, mely során üres, azaz adatok nélküli táblázatok jönnek létre. Szemléletesen kifejezve úgy is mondhatnánk, hogy elsőként a táblázatokat fejlécét alkotjuk meg, s a táblázat sorait csak későbbi múveletekkel hozzuk létre.
A táblázat szerkezete, sémája, mint már ismert, a táblázathoz tartozó mezőkkel írható le. Azaz, ha megadjuk, hogy milyen mezőkből épül fel a táblázat, akkor ezzel egyértelmúen megadjuk a táblázat szerkezetét is, tehát két táblázat szerkezete különbözik egymástól, ha található olyan mező, mely az egyikben benne van, a másikban nincs. A mezők megadása pedig a mező névének és a mező adattípusának a kijelölésével történik. Mivel a szerkezetek megadása nem azonosít egyértelmúen egy táblázatot, hiszen több táblázat is létezhet ugyanazzal a szerkezettel, másrészről a szerkezet leírása igen hosszadalmas, ezért minden táblázat kap egy egyedi azonosító nevet az adatbázison belül. Ezzel a névvel egyértelmúen lehet azonosítani a táblázatokat a múveletek során. A táblázat névnek tehát az adatbázison belül, a mezőnévnek pedig a táblázaton belül kell egyedinek lennie. Összefoglalva a táblázat létrehozásakor meg kell adni a táblázat nevét, valamint az őt alkotó mezők nevét és típusát.
Mivel a relációs modellnek az integritási feltételek is szerves részei, és az integritási feltételek szorosan kötődnek a táblázatokhoz, rendszerint a táblázathoz annak megszúnéséig kötődnek, ezért a táblázatok létrehozásakor lehetőséget kell adni a hozzá kapcsolódó integritás feltételek definiálására is. Az SQL'86 szabvány nem tartalmazza az összes általunk említett integritási feltételt, azok együttesen csak a későbbi szabványokban jelentek meg. Így itt még nincs lehetőség sem a kulcs, sem a kapcsolókulcs integritási feltételek megadására. Az átmeneti helyzetet jól mutatja, hogy a korábbi RDBMS változatok ugyan már elfogadták a PRIMARY KEY integritási feltételt, azonban figyelmen kívül hagyták ezt a megkötést, azaz nem tudták biztosítani az elsődleges kulcs feltétel ellenőrzését.
Az utasítások részletezése
Táblák létrehozása
Az SQL utasításait az angol nyelvhez igazítva rögzítette le, ennek megfelelően az adatszerkezetek létrehozásának utasítása a CREATE utasítás. A táblázat létrehozása a következő utasítással lehetséges:
CREATE TABLE táblázatnév (m1 t1 [i1][,..., mi ti [ii]],[ig]);
Az SQL utasításokat mindig pontosvessző határolja, zárja le. Az utasítás több soron keresztül is folytatódhat, csak a pontosvessző jelzi az utasítás végét. Az utasítás leírásában a mi mezőnevet, a ti típust, az ii mezőhöz kötött, míg az ig mezőcsoporthoz kötött integritási feltételt jelent. Az integritási feltételt lehet mezőhöz kötve és táblázathoz kötve is megadni.
Az ii a következő elemeket tartalmazhatja:
UNIQUE: a mező egyedi értékeket tartalmaz, azaz egy érték nem fordulhat elő egynél több rekordban
NOT NULL: a mezőnek tartalmaznia kell értéket, nem maradhat üres egyetlen egy rekordban sem
Egy mezőre több integritási feltétel is megadható, ekkor egymás után írjuk az egyes integritási elemek kulcsszavait. Az ig esetében külön meg kell adni, hogy a feltétel mely mezőre vonatkozik. A mezőneveket rendszerint a kulcsszót követő zárójelben adhatjuk meg. A megadott két feltételből csak az UNIQUE értelmezhető külön mezőcsoporton, melynek használata:
UNIQUE (m1 [,m2..,mi])
Az adattípusok esetében sajnos nem lehet szabványosított hivatkozást megadni, mivel a legtöbb elterjedt RDBMS rendszer más-más elnevezést használ. Mi most csak a legfontosabb alaptípusokat a következő megjelölésekkel együtt vesszük át:
CHAR (n): n hosszúságú szöveg
NUMBER (n [,m]): n hosszú számjegy, m a tizedes jegyek hossza
DATE: dátum
A példaként megadott táblák az alábbi utasításokkal hozhatók létre:
CREATE TABLE AUTO (TUL NUMBER(3) NOT NULL,
RSZ CHAR(7) NOT NULL UNIQUE,
TIP CHAR(10),
SZIN CHAR(10),
EVJ NUMBER(4),
AR NUMBER(8));
CREATE TABLE EMBER (ID NUMBER(3) NOT NULL UNIQUE,
NEV CHAR(20),
SZULEV NUMBER(4),

1 2 3 4 5 6 7 8 9 10

Kilépés

Oldal generálása 0.0677 mp-ig tartott

Mini optimalizalt))
Opera

Webstat