3. adatbázis definiálása és kezelése - bge · pdf...

3. Adatbázis definiálása és kezelése

3.1. Bevezetés

3.2. Tevékenységek és eszközök áttekintése

3.3. Adatbázis definiálása

3.4. Adatkezelı SQL parancsok

3.5. Adatkezelés az Access grafikus felületén

INFORMATIKUS SZAKMAI ISMERETEK

94

3.1 Bevezetés

Ez a fejezet a relációs adatbázisok létrehozásának és mőködtetésének tevékenységeirıl és e tevékenységek eszközeirıl szól. Az utóbbiak közül részletesen ismerteti az SQL parancs-nyelvet és az Access adatbáziskezelı felületét.

A 3.2. alfejezet áttekinti az adatbázisok létrehozásának feladatait, köztük a migrációt, az adattisztítást; azután az adatbázis biztonságával összefüggı ellenırzési, megelızési és helyre-állítási megoldásokat; az adatbázistartalom hitelességének feltételeit biztosító megoldásokat; az adatbázis-adminisztrátor feladatait, a felhasználók konkurens kiszolgálásának és a tranzak-ciók korrekt lekezelésének megoldásait.

A 3.3. alfejezetben az olvasó példák útján is részletesen megismerheti az adatbázis eleme-inek definiálására szolgáló fıbb SQL parancsokat, mint a CREATE TABLE és a CREATE INDEX parancs, valamint az Access tábladefiniáló grafikus felületét.

A 3.4. alfejezet az adatok bevitelére, törlésére, módosítására és lekérdezésére szolgáló to-vábbi SQL parancsokat (INSERT, DELETE, UPDATE, SELECT) mutat be példák sorozatán keresztül. Ebben a részben az olvasó egészen összetett adatkezelı feladatok megoldásában is jártasságot szerezhet.

A 3.5. alfejezet a 3.4 alfejezetben elıfordultakhoz hasonló feladatok megoldását mutatja be, de már nem SQL parancsok, hanem az Access párbeszédes, grafikus adatkezelı felületé-nek felhasználásával.

ADATBÁZIS DEFINIÁLÁSA ÉS KEZELÉSE

95

3.2 Tevékenységek és eszközök áttekintése

3.2.1 Adatbázis létrehozásának és m őködtetésének tevékenységei

Adatbázis definiálása és létrehozása

A 2.7. alfejezetben ismertetett adatbázistervezés végeredménye a fizikai adatbázisdefiní-ció. Ez relációs adatbázisok esetében egy SQL nyelvő parancsfájl (lásd a 3.2.2. és a 3.3.1. szakaszban), amelynek tartalmát az adatbázistervezést (adatmodellezést) támogató CASE1 szoftver – a benne elkészült adatmodell alapján – automatikusan generálja. Ez a parancsfájl az adatbázis adattábláit (annak összetevıit), indextábláit, táblakapcsolatait, megszorításait, adat-integritási és üzleti szabályait leíró parancsokból (röviden adatdefiniáló parancsokból), vala-mint a hozzáférési jogokat adó parancsokból áll. Ha egy ilyen SQL parancsfájlt valamely (relációs) adatbáziskezelı rendszerrel lefuttatunk, akkor létrejön a definíciónak megfelelı szerkezető üres adatbázis, amely persze nem teljesen üres, hiszen az adatszótárában a saját szerkezetleírását már tartalmazza.

Egy adatbázist használó új szoftverrendszer fejlesztésekor az adatbázis tesztváltozatát legkésıbb a programok kódolásának megkezdése elıtt létre kell hozni, mert nélküle a kódo-lással párhuzamosan folyó egységtesztek nem hajthatók végre.

Az adatbázis feltöltése – Adatmigráció

A létrehozott adatbázist elıször is fel kell tölteni adatokkal. Ha a kezdeti feltöltéskor egy korábban használt adatbázis(ok) vagy valamilyen fájlrendszer(ek) adatait töltik be az új adat-bázisba, akkor ezt adatmigrációnak nevezik. A migráció minimálisan adatkonverziót jelent, de gyakran adattisztítást is magában foglal.

A forrásadatbázisban vagy forrásfájlban az elemi adatok (adatmezık) formátuma vagy az összetett adatok szerkezete eltérhet az új adatbázisban elvárt formátumtól és szerkezettıl, ezen segít a konverzió mint olyan eljárás, amely a forrásoldali formátumot és szerkezetet a céloldalon elvárt formátumra és szerkezetre alakítja át.

Az adattisztítás alatt a forrásadatok hiányosságainak és ellentmondásainak (egy szóval: inkonzisztenciájának) kiszőrését és javítását értjük. Ebbıl a szőrés általában automatizálható, a javítás azonban már egyedi emberi beavatkozást, utánajárást igényel. – Gyakran éppen azért kerül sor új rendszer fejlesztésére, mert korábbi megbízhatatlanul mőködött, azaz hiányos, illetve ellentmondásos (egy szóval: inkonzisztens) adattartalomhoz vezetett; ilyenkor az adat-tisztítás elkerülhetetlen. Mivel a szigetrendszerek adatellenırzési lehetıségei korlátozottabbak az integrált rendszerekénél, a szigetrendszerekrıl integrált rendszerekre való áttérés esetén is indokolt az adattisztítás.

Adattárház frissítése

A vezetıi információrendszerek (üzleti intelligencia rendszerek) adatbázisának, az adat-tárháznak (lásd a 2.6.3. szakaszban) a frissítése az új adatoknak a szervezet más (OLTP) adatbázisaiból és adatforrásaiból való rendszeresen ismételt áttöltésével történik. Tehát az adattárház frissítése napi gyakorisággal igényli azoknak a migrációs eljárásoknak a végrehaj-tását, amelyek az OLTP adatbázisoknak csak a kezdeti feltöltését jellemzik.

1 Computer Aided Software Engineering szoftver– lásd a 4.2.4. fejezetben.


96

Az adatbázis biztonságával és hitelességével összefüggı feladatok

Az adatbázis biztonsága megkívánja, hogy • azon csak azok végezhessenek mőveletek, akik arra jogosultak, és • csak olyan mőveleteket végezhessenek, amelyekre jogosultak, illetve • csak olyan mőveleteket végezhessenek, amelyek nem sértik az adatbázis integritását,

konzisztenciáját.

Ennek érdekében minden mőveletnek át kell esni egy szigorú és automatizált ellenırzé-sen, amely kiszőri, ha a fenti megkötések valamelyike nem teljesül.

Az adatbázis különbözı elemeihez kötött hozzáférési jogok ellenırzését az adatbáziske-zelı automatikusan elvégzi az adatbázisdefiníció részeként (vagy utólag) kiadott hozzáférés-beállító parancsoknak megfelelıen. Egyéb szabályok betartásának ellenırzését és a szabályt sértı mőveletek visszautasítását külön megszorításokkal, bonyolultabb szabályok esetén trig-gerekkel és tárolt eljárásokkal vagy az adatbázist használó alkalmazásokba programozott eljárásokkal valósítják meg.

A tárolt adatbáziseljárások vagy önálló programnyelven vagy az SQL speciális kiegészí-tését képezı procedurális nyelven (pl. PL/SQL) írt utasításokból álló programegységek, ame-lyek maguk is az adatbázisban tárolódnak, és az adatbáziskezelı adott adatbázisszabály által elıírt módon (a szabályban hivatkozott típusú esemény bekövetkezésekor) automatikusan lefuttatja ıket. (Az Oracle adatbáziskezelı esetében az olyan szabályokat, amelyek adott típu-sú esemény bekövetkezésekor automatikusan egy adott tárolt eljárást indítanak el, triggernek nevezik.)

Megjegyzés: Az adatbázisszabályok és azok által indított tárolt eljárások nem csak ellen-ırzést szolgálnak; és ellenırzés esetén sem mindig az a feladatuk, hogy visszautasítsák vala-milyen nem megengedett mőveletek végrehajtását. Vannak olyan ún. vízesésszabályok is, amelyek úgy gondoskodnak az adatbázis integritásának megırzésérıl, hogy a felhasználó által kezdeményezett mőveleten felül további mőveleteket is végrehajtatnak. Például a felhasználó (vagy egy program) egy rendelés törlését kéri, és egy vízesésszabály gondoskodik arról, hogy a rendeléssel együtt annak tételei is törlıdjenek.

Tipikusan nem ellenırzést szolgáló adatbázisszabály egy olyan üzleti szabály, amely valamely cikk adott készletezési helyen vett készletének adott szint alá csökkenésekor egy rendelés készítését és elküldését kezde-ményezi.

Ha az ellenırzési szabályokat adatbázist használó alkalmazásokba programozott eljárá-sokkal (tehát nem az adatbázisban tárolt eljárásokkal) valósítják meg, akkor gondoskodni kell arról, hogy a felhasználók az adatbázist csak az erre szolgáló alkalmazás(ok)ból érhessék el.

Megjegyzés: Érdekes dilemma, hogy az alkalmazáslogikát adatbázisszabályokkal és tárolt eljárásokkal vagy alkalmazásokba programozott eljárásokkal célszerőbb-e megoldani. Az olyan adabáziskezelı rendszer esetében, amely lehetıséget ad rá, az adatbázisszabályokkal és tárolt eljárásokkal „elegánsabb” és hatékonyabb megoldá-sok készíthetık. Azonban egyidejőleg romlik a rendszer hordozhatósága, mert az egyik típusú adabáziskezelı rendszerre írt tárolt eljárások nem mőködnek más típusú adabáziskezelı vezérlése alatt.

Az illetéktelen és a hibás / téves mőveleteken túl olyan más okok is vezethetnek sérü-léshez vagy meghibásodáshoz, amelyek elıfordulását megelızı biztonsági eljárásokkal nem lehet kizárni. Ilyen eshetıségek miatt arra is fel kell készülni, hogy a sérült adatbázis rövid idın belül helyreállítható legyen. Ennek érdekében az adatbázis állapotáról elıírt idıközön-ként biztonsági mentést kell készíteni, a mentések között történt tranzakciókat pedig naplózni kell. A helyreállítás alkalmával visszatöltik az adatbázis valamely, a sérülést megelızıen elmentett állapotát, majd megismételtetik az ennek mentése óta történt tranzakciókat.


97

Az adatbázis tartalmának hitelessége csak akkor ítélhetı meg, ha bármely rekord (adat-sor) tartalmáról vagy akár az egyes mezık értékérıl megállapítható, hogy az melyik felhasz-náló beavatkozásának eredményeként és mikor állt elı. Ez az igény vagy az adatállapotok (állapot + ki állította be + mikor) vagy a mőveletek (mővelet + ki hajtotta végre + mikor) naplózásával szolgálható ki. Valamilyen szintő naplózást az adatbáziskezelı eleve végez, de speciális igények esetén az adatbázisba a szakterületi adatok tábláin felül a naplóadatok struk-turált tárolására alkalmas táblákat is tervezni kell, és az ezek töltését és elemzését végzı eljárásokat is ki kell fejleszteni.

Adatbázis-adminisztráció

Az adatbázis felhasználói között van egy kitüntetett: az adatbázis-adminisztrátor. Az ı dolga:

• szaktanácsadással szolgálni az adatbázis és a migráció tervezése, valamint az adatbá-zist használó alkalmazások fejlesztése során;

• létrehozni az új adatbázist; • irányítani, felügyelni a migrációt; • hozzáférési jogokat osztani a többi felhasználó részére; • felügyelni a biztonsági feladatok ellátását (naplók ellenırzése, biztonsági mentések

felügyelete), szükség esetén végrehajtani a helyreállítást, a tapasztalatok alapján javí-tani, fejleszteni a biztonsági megoldásokat;

• végrehajtani a fizikai tárolási struktúrák rendszeres újraszervezését (pl. hash leképezés egyenletesebbé tétele vagy az indextáblák kiegyensúlyozása céljából végzett újraszer-vezéseket);

• elvégezni az esetlegesen elégtelen teljesítmény javítására alkalmas hangolásokat (ez általában az eredetileg tervezett tárolási struktúrák, leképezési eljárások lecserélését; az eredetileg tervezett kulcsok helyett más kulcsok szerinti indextáblák alkalmazását jelentheti);

• végrehajtani az adatbáziskezelı szoftver verzióváltásaival járó feladatokat; • szükség esetén bıvíteni, módosítani az adatbázis (logikai) sémáját; • elvégezni a felhasználóknak az adatbázis használatával összefüggı képzését.

Nagyobb szervezeteknél az adatbázis-adminisztrátornál szélesebb hatáskörrel rendelkezı, az egész szerve-zet adatvagyonáért felelıs adat-adminisztrátorra is szükség van. Az adat-adminisztrátor tevékenységének súly-pontja nem az adatbázisok üzemeltetésére, hanem azok tervezésére, fejlesztésére esik. Az ı feladata a fejlesztési projektek koordinálása és felügyelete a szervezeti szintő adatintegráció fenntartása céljából. Az adatvagyont egy szervezeti szintő adatszótár írja le. Ez az adattervezés tekintetében meghatározó kiindulási alapot képez minden fejlesztési projekt számára, egyúttal a fejlesztések hatására – szervezeti szinten érdekelt és az adat-adminisztrátor által jóváhagyott – új adatfogalmakkal bıvül.

Az adatbázis használata – adatkezelési mőveletek

Végül nézzük azokat a mőveleteket, amelyek végrehajthatósága céljából az adatbázist létrehozzuk: a folyamatos üzemeltetés során az adatbázist újabb és újabb adatokkal bıvítjük, a már tárolt adatokat pedig módosíthatjuk, némelyeket archiváljuk és töröljük, valamint az ada-tokat különbözı célokból lekérdezzük. Relációs adatbázisok esetén e mőveletek is SQL nyelvő parancsokkal (lásd a 3.2.2. szakaszban és a 3.4. alfejezetben) kezdeményezhetık még akkor is, ha a felhasználó ebbıl semmit sem lát, mert ı egy felhasználói programmal áll kap-csolatban, és az SQL parancsokat ez a program adja ki helyette.

Az adatbázismőveletek végrehajtási mechanizmusának megértéséhez tisztában kell lenni két fontos körülménnyel:


98

• Az adatkezelési mőveletek mindig valamilyen tranzakció feldolgozásának a részét képezik.

• Az adatbázist konkurens módon több felhasználó használja, azaz az adatbázismo-tornak egyidejőleg több felhasználó által kezdeményezett mőveleteket kell végre-hajtania.

Az alkalmazói környezetben tranzakciónak számít minden olyan esemény, amelyet az adatbázis valamilyen állapotváltozásának kell reprezentálni. Az adatbázisnak egy eseményt megfelelıen tükrözı állapotváltozását általában nem egyetlen adatbázismővelettel, hanem mőveletek egy sorozatával lehet produkálni. Ezért az adatbáziskezelı rendszer számára a tranzakció egy olyan mőveletsorozat, amelynek végét egy tranzakció vége parancs jelöli. A továbbiakban az ilyen mőveletsort technikai értelemben vett tranzakciónak nevezzük, de ahol az nem okoz félreértést, röviden ezt is tranzakciónak mondjuk.

Megjegyzés: Egy tisztán lekérdezı mővelet elvben nem számít tranzakciónak, mert nem változtatja meg az adatbázis állapotát. Azonban technikailag a lekérdezı parancsok is egy (technikai értelemben vett) tranzakció részeként adhatók ki.

Példa tranzakcióra: Ha egy kereskedelmi tevékenységet folytató cég belföldre árukat értékesít, akkor egy (esetleg több tételes) kiszállítás esemény alkalmával az adatbázis tartalmát a következı mőveletek együttesével kell aktualizálni: – Létre kell hozni egy új sort a KISZÁLLÍTÁS táblában. – A kiszállítás minden egyes tételének megfelelıen létre kell hozni egy-egy sort a KISZÁLLÍ-

TÁSTÉTEL táblában. – A KÉSZLET táblában minden olyan árukészlet sorában, amibıl e kiszállítás valamely tételéhez

árut vételeztek, csökkenteni kell a készleten lévı mennyiséget az onnan kiszállított mennyiséggel. – Minden kiszállítástételrıl létre kell hozni öt sort a FİKÖNYVISZÁMLA-FORGALOM táblában (egy

„Eladott áruk beszerzési értéke tartozik”, egy „Áruk elszámolóáron követel” egy „Belföldi vevık tartozik” egy „Belföldi értékesítés árbevétele követel” és egy „Fizetendı ÁFA követel” forgalom-sort).

Ha egy tranzakció feldolgozása valamilyen akadály miatt nem fejezıdhet be, akkor az adatbázis tartalma szükségképpen valótlan és ellentmondásos (inkonzisztens) lesz. Így ha a keretezett példában a feldolgozás a kiszállítástételek létrehozása után megszakad, azaz a készletsorok aktualizálására már nem kerül sor, akkor az adatbázis a valóságosnál nagyobb készleteket fog mutatni. A mondottakból következik, hogy a tranzakció megbonthatatlan egy-ségként kezelésének képessége kézenfekvı elvárás az adatbáziskezelı rendszerekkel szem-ben. Másképpen szólva a (technikai értelemben vett) tranzakció lényegi jellemzıje, hogy az csak egészében hajtható végre, vagy sehogy sem, azaz egy félbeszakadt tranzakció esetében az adatbáziskezelınek képesnek kell lenni a tranzakció odáig végrehajtott mőveleteinek érvénytelenítésére; vagyis a tranzakció elıtti állapot visszaállítására az adatbázis mindazon részében, amit a tranzakció addigi mőveletei érintettek.

Az SQL nyelvben egy tranzakció végét a COMMIT parancs vagy a ROLLBACK parancs jelzi. (A tranzakció kezdetét jelzı parancsra általában nincs szükség: a tranzakció kezdete azonos a felhasználó adatbázishoz való kapcsolódását követı elsı adatbázismővelettel vagy egy tranzakciót lezáró parancs utáni elsı adatbázismővelettel. Kivétel a Microsoft SQL Server, amelynél létezik a BEGIN TRANSACTION parancs.):

• A COMMIT parancs következménye a tranzakció olyan befejezése, hogy az adatbá-ziskezelı a tranzakció mőveleteinek hatását érvényesíti (véglegesíti) az adatbázison.

• A ROLLBACK paranccsal az aktuális tranzakciót félbehagyásra kényszerítı hiba esetén kérhetı fel az adatbáziskezelı a tranzakció odáig végrehajtott mőveleteinek érvénytelenítésére; azaz az ezen mőveletek által érintett adatbázirész tranzakció elıtti állapotának visszaállítására.


99

Még arról is szólni kell, hogy a traknzakciók korrekt kezelése hogyan mőködik az adatbázis konkurens használata esetén. Bár a hozzáférési jogok behatárolják, hogy egy-egy felhasználó az adatbázis mely részét éri el, ez általában nem jelenti azt, hogy az egyes felhasználók csak elkülönült privát részek felett rendelkeznének; jellemzıbb hogy azonos adatokat több felhasználó közösen is használhat. Tehát a konkurens felhasználási mód nem csak az adatbázis egészére, hanem az egyes adatokra külön-külön is fennáll.

Többfelhasználós környezetben minden felhasználónak külön csatlakozása (angolul session2) van az adatbázishoz. (Pontosabban egy felhasználó többszörösen is kapcsolódhat egy adatbázishoz, és abban az esetben azonos felhasználó különbözı sessionjei is konkurál-hatnak egymással). Egy tranzakció mindig egy felhasználói csatlakozáshoz (sessionhöz) tartozik. Ha egy T tranzakció már végrehajtott utasításai érintették valamely tábla valamely sorát, akkor a sor zárolódik a T tranzakciót kezdeményezı C csatlakozás számára. (Az „érintés” fogalmába általában az írási mőveletek tartoznak, de csatlakozásonként beállítható, hogy az olvasási mővelet, azaz lekérdezı mővelet – SQL-ben a SELECT mővelet – is tegyen zárat az olvasott sorokra.) A zárolt sorokat írásra más C1 csatlakozásból nem lehet elérni, olvasásra is csak akkor, ha a C1 csatlakozásnál az olvasás nem zároló mőveletként van beál-lítva, de ekkor a C1 csatlakozás az elért sor(ok)nak a T tranzakciót megelızı állapotát látja. A T tranzakció minden hatását a többi csatlakozás (még az ugyanazon felhasználó másik csatlakozása is) csak akkor érzékeli, amikor a C csatlakozás a T tranzakciót befejezte. A tranzakzió befejezésekor (akár érvényesítéssel – COMMIT, akár érvénytelenítéssel – ROLLBACK) a tranzakció által az adatbázisra tett összes zár eltávolítódik.

A tranzakciókat megszakító akadályok gyakran éppen a zárolások miatt a konkurens csat-lakozások között elıálló konfliktusokból, konkrétabban a holtponti helyzetbıl (angolul: dead lock „döglött zár”) adódnak. A holtponti helyzet úgy jön létre, hogy egy T1 tranzakció zárolni akar egy S1 táblasort, de nem tudja, mert azt egy másik T2 tranzakció már zárolta, és ezért a T1 várakozik a T2 befejezésére. Azonban a T2 nem tud befejezıdni, mert ı meg éppen a T1 befejézésére várakozik, mert egy olyan S2 táblasorra szeretne zárat rakni, amelynek a zárolá-sában ıt a T1 megelızte. A holtponti helyzetet az adatbáziskezelı felismeri, és hibaüzenetet produkál az abban elakadt tranzakciók részére.

Megjegyzés: A fejezet példáiban tranzakciókezeléssel nem foglalkozunk, mivel az esz-közként feltételezett Accessben erre sem az egyszerő párbeszédes módban, sem a lekérdezés-definiáló felület SQL-nézetében nincs lehetıség. Bár az Access SQL-je (a súgója szerint) tartalmazza a BEGIN TRANSACTION, a COMMIT és a ROLLBACK parancsokat, a lekér-dezésdefiniáló felület SQL-nézetében kiadva mégsem ismeri fel azokat. Ennek következtében az Accessben minden SQL mővelet önálló tranzakciót képez. – Egyébként a többfelhasználós adatbázishasználat (hálózatban) még Accessben is kipróbálható, azonban két okból is csak nagyon korlátozott mértékben: Egyrészt néhány felhasználó felett romlik a teljesítmény, más-részt mert (a fentiekben mondottak miatt) csak azon nem életszerő esetekben mőködik kor-rekten, amikor az SQL mőveletek egyenként képeznek tranzakciót.

3.2.2 Az SQL nyelv

Manapság legelterjedtebben használatos relációs vagy objektumrelációs adatbázisok általánosan használt parancsnyelve az SQL (Structured Query Language). A név szó szerint strukturált lekérdezı nyelvet jelent, de ténylegesen ezen a nyelven nemcsak

• lekérdezı parancsok, hanem

2 Ejtsd szesön.


100

• az adatbázis szerkezetét definiáló parancsok (Data Definition Language – DDL); valamint

• adataktualizáló parancsok (Data Manipulation Language – DML) – pl. adatok beírása, módosítása, törlése);

• tranzakcióvezérlı parancsok (Transaction Control – TC) – pl. COMMIT, ROLLBACK;

• bejelentkezésvezérlı és rendszervezérlı parancsok (Session Control & System Control – SC) parancsok – pl. ALTER SESSION, ALTER SYSTEM, SET ROLE

is írhatók.

Az SQL a következı módokon, illetve környezetekben használatos:

• parancsmód: interaktív SQL parancs vagy parancsfájl (script) formájában;

• adatbázisban tárolt SQL eljárás formájában (a tárolt eljárás az SQL parancsokon felül egyéb procedurális – azaz elágazásokat, ismétlıdéseket vezérlı – utasításokat is tartal-maz);

• harmadik generációs (3GL) vagy negyedik generációs (4GL) nyelvő forráskódba (programkódba) beágyazott SQL formájában.

Az SQL nyelv jelenleg legfrissebbnek számító megvalósításai az ANSI/ISO SQL-99 szabványt követik. Azonban az SQL-nek a kölönbözı típusú adatbáziskezelı rendszereknél eltérı nyelvjárásai lehetnek, ezek a szabványos parancskészleten felüli speciális bıvítménye-ket is tartalmaznak, illetve a parancsok szintaktikai egységeire a szabványtól eltérı változato-kat is megengednek. – Lehet, hogy bizonyos feladatok megoldására az egyes bıvítmények hatékonyabb megoldást kínálnak, viszont az ezeket is tartalmazó SQL parancsoknak komoly hátránya a hordozhatatlanságuk.

Minden SQL nyelvjárás közös jellemzıje, hogy a parancsok kulcsszavaiban a függvény-nevekben és az adatbázisobjektumok (adattáblák, oszlopok, megszorítások, indextáblák stb.) nevében nem különböztetik meg a kis és a nagybetőket. Ez a szabály nem vonatkozik a parancsokban hivatkozott szövegkonstansokra. Például a

SELECT FIZETES FROM ALKALMAZOTT WHERE NEV = 'Kovács János'

select fizetes from alkalmazott where nev = 'Kovács János'

parancsok egyenértékőek, viszont a select fizetes from alkalmazott where nev = 'KOVÁCS JÁNOS'

select fizetes from alkalmazott where nev = 'Kovács János'

parancsok már nem azok. Az utóbbi kettı közül csak az elsı fog jól mőködni, ha az alkalma-zott neve csupa nagybetővel van letárolva a nev mezıben, illetve csak a második fog jól mőködni, ha az alkalmazott letárolt nevében csak a kezdıbetők nagyok.

A 3.3.1. szakasz és a 3.4. alfejezet több SQL parancsot ismertet. Az egyes parancsok leírását egy, a parancs (egyszerőbb változatainak) felépítését (szintaktikáját) mutató parancs-sablonnal kezdjük, majd a sablonnak megfelelı konkrét parancsokkal folytatjuk. Példaként tekintsük az INSERT parancs (egyszerőbb változatának) sablonját:

INSERT INTO táblanév [ [AS] másodnév] [ (oszlopnévlista) ] VALUES (értéklista)


101

A sablonok elemei:

• NAGYBETŐKKKEL írt utasításszavak – INSERT INTO, AS, VALUES3 – vagy kerek zárójelek és bizonyos más elválasztójelek (pl. vesszık) a sablonnak megfelelı konkrét parancsba változatlanul beírandó elemek;

• dılt betőkkel szedett részeket még további minták magyarázzák (itt ilyen az oszlop-névlista, értéklista), vagy magyarázat hiányában a konkrét parancsban értelemszerően alkalmazandók (itt ilyen a táblanév, másodnév);

• olyan metajelek, amelyek egy konkrét parancsnak nem részei, mert csak a mintában bírnak jelentéssel, mint a [ ] zárójelek vagy a … ponthármas.

Az oszlopnévlista további sablonnal kifejtve:

oszlopnév [, oszlopnév]…

A [ ] zárójelek azt jelzik, hogy a közéjük zárt rész nem kötelezı egység, azaz egy konkrét parancsban csak szükség esetén kell alkalmazni. Az INSERT parancs sablonjában ilyenek az [ (oszlopnévlista) ] az [ [AS] másodnév] és azon belül az AS kulcsszó magában is. Az oszlopnévlista sablonjában ilyen az [, oszlopnév]. Az utóbbi azt jelzi, hogy lista egyetlen névbıl is állhat, ha van második oszlop is, akkor annak nevét vesszı választja el a megelızı oszlop nevétıl.

A … ponthármas azt jelzi, hogy a (sablonban) megelızı egység további példányai is elıfordulhatnak egy konkrét parancsban, ha azokra szükség van. Az oszlopnévlista sab-lonjában elhelyezett ponthármas szerint a 2. oszlopnevet további (3., 4. stb.) oszlopnevek is követhetik.

1. megjegyzés: A tankönyvnek nem célja az SQL szabványos változatának kézikönyvsze-rő leírása. Így a parancsoknak nem a teljes, hanem csak egy-egy nagyon leegyszerősített sab-lonját adjuk meg4. A fejezet nagyobb részében a Microsoft Access program SQL nyelvjárá-sát fogjuk bemutatni, mivel ez a legtöbb helyen megtalálható olyan program, amely az adat-báziskezelés gyakorlását (akár SQL használatával, akár interaktív felületen) lehetıvé teszi. Ez azonban azzal jár, hogy a parancsok leírása, szintaktikája tartalmazni fog bizonyos ACCESS-sajátosságokat, de néhol kitérünk más SQL nyelvjárások sajátosságaira is, fıleg olyan paran-csok esetében, amelyek az Accessben nem mőködnek.

2. megjegyzés: Ha az olvasó a Microsoft Accessben akar SQL parancsokat kipróbálni, ak-kor azt furcsa módon lekérdezéstervezı (-definiáló) felületen teheti meg akkor is, ha nem lekérdezı parancsot akarunk szerkeszteni. Ezt a felületet a 3.1-3.3. ábrákkal mutatott lépésekkel lehet elıhozni. Az elsı két lépés a 3.1. ábrán látszik: (1) Az objektumok közül a Lekérdezéseket, majd azon belül (2) a Lekérdezés létrehozása Tervezı nézetben mőveletet kell választani. Az ezután megjelenı Tábla megjelenítése ablakból (lásd a 3.2. ábrán) nem kell választani egyetlen táblát sem (különösen nem, ha egy új táblát definiáló SQL parancsot akarunk írni). Így a normál (grafikus) lekérdezı felület üresen jelenik meg (lásd a 3.3. ábrán), róla az SQL gombra kattintva válthatunk az SQL parancsok szerkesztésére szolgáló nézetre. A 3.4. ábra mutatja, hogyan kezdeményezhetı a megírt parancs végrehajtása.

3. megjegyzés: A 3.4. ábrán az SQL parancsszerkesztı ablak fejszegélyében az „adatde-finiáló lekérdezés” körülbelül annyira értelmes elnevezés, mint a fagyasztó tőz vagy a sóíző cukor. A furcsa nevet egyedül az Accessnek az a furcsa megoldása magyarázza, hogy benne

3 A konkrét parancsban ezek már kisbetővel is írhatók, mert az SQL a parancsszavakban (és a névhivatkozásokban) nem különbözteti meg a kis- és a nagybetőket.) 4 Az olvasó további SQL tudásra tehet szert például [Bhamidipati-1999] kézikönyvbıl.


102

nem csak a lekérdezı parancsokat, hanem mindenféle SQL parancsot a lekérdezésdefiniáló felületen kell megadni.

3.1. ábra: Lekérdezéstervezés kezdeményezése Accessben

3.2. ábra: Lekérdezéstervezéshez táblák kiválasztása Accessben

2

1


103

3.3. ábra: SQL szerkesztı nézet választása a lekérdezı felületen

3.4. ábra: SQL parancs szerkesztése Accessben

3.2.3 Interaktív adatbáziskezel ı felületek

Az egyszerő felhasználónak nem kell tudnia, milyen táblákból, adatoszlopokból épül fel az adatbázis, nem kell ismernie az SQL parancsokat, mert általában nem közvetlenül hasz-nálja az adatbázist, hanem valamilyen célalkalmazás vezérlése alatt, és helyette a célprogram ad ki SQL parancsokat az adatbáziskezelı irányában úgy, hogy arról a felhasználó nem is vesz tudomást. Ebben a szakaszban egy olyan köztes megoldást tárgyalunk, amelynél

• a felhasználó ismeri az adatbázis felépítését, és közvetlenül elérheti és manipulálhatja az adatbázis tábláit, a táblák részeit;

Ha a normál lekérdezéstervezı nézet látszik, akkor erre a gombra kattintva válthatunk az SQL paran-csok szerkesztésére szolgáló nézetre.

Erre a gombra kattintás kezde-ményezi az éppen beírt SQL parancs(ok) végrehajtását.


104

• de nem kell ismernie az SQL nyelvet, mert helyette egy könnyen megtanulható grafi-kus, párbeszédes (interaktív) felületen közölheti kívánságait, amelyeket a felület mö-gött mőködı program alakít át SQL parancsokká.

Egy interaktív adatbáziskezelı felület birtokában a felhasználó közel akkora szabadsággal rendelkezik, mintha SQL parancsokat adna ki, mert nem csak azokat a mőveleteket kezdemé-nyezheti, amelyeket a programozók egy speciális alkalmazásba beleírtak. (Az eszköz korlátai csak a különösen bonyolult lekérdezési feladatok esetén mutatkoznak meg.)

Sokféle párbeszédes adatbáziskezelı felület létezik, azonos adatbáziskezelıhöz esetleg többféle is. (A PC kategóriájú számítógépek használói az ilyen szoftverek közül leggyak-rabban valószínőleg az Microsoft Access programmal találkozhatnak.) Ezekkel általában adatdefiniáló, adataktualizáló és lekérdezı mőveletek egyaránt végezhetık, de itt most csak a lekérdezésre szorítkozva utalunk a képességeikre. – Egy lekérdezés esetén a szoftver és a felhasználó közötti párbeszéd egy lehetséges menete a következı:

1. A szoftver az adatbázis adatszótárából kiolvassa, milyen táblák léteznek az adatbázisban, és ezek közül melyekhez férhet hozzá a bejelentkezett felhasználó. A szoftver az elérhetı táblák5 listáját megmutatva, kéri a felhasználót, válassza ki azokat a táblákat, amelyek szerinte az aktuális lekérdezésben érintettek. A felhasználó azonos táblát többször – többféle szerepben – is kiválaszthat. (Ilyen feladatokra a 3.5.2. szakaszban talál példákat.)

2. A szoftver kéri definiálni a kimenet adatait (a kimenet oszlopait), azok forrásait (tábla-oszlopkat) és az említettek közötti transzformációt. A szoftver a válaszadást azzal könnyíti meg, hogy kiválasztásra felajánlja az elıbbi lépésben megjelölt táblák oszlopait, illetve az ezeken (ezek közt) végezhetı mőveleteket.

3. A szoftver kéri definiálni azokat a feltételeket, amelyek a forrástáblák sorait (az alap-adatokat) a felhasználó igényeinek megfelelıen szőrik. Egyszerőbb esetben a feltételek az 1. lépésben kiválasztott táblák oszlopaira hivatkoznak, azokat különféle összehasonlító, illetve logikai mőveletekkel kapcsolják össze. Tehát most a szoftver ezek választékát ajánlja fel a felhasználónak. Bonyolultabb feladat esetén a feltétel egy újabb – beágyazott – lekérdezés eredményére is hivatkozhat. (Ilyen feladatra a 3.5.2. szakasz mutat példá-kat.). Ekkor a beágyazott lekérdezésre is be kell járni a párbeszéd 1-5. lépéseit.

4. A felületen jelezhetı, ha a felhasználó a 2. lépésben definiált kimenı adatokat nem az egyes adatsorokról, hanem az adatsorok csoportjairól szeretné kérni. Akkor a szoftver a csoportosító ismérv(ek) választása céljából ismét felajánlja az 1. lépésben megjelölt táblák oszlopainak listáját.

5. Amennyiben a felhasználó élt a 4. lépésben adott lehetıséggel, akkor a szoftver kéri definiálni a csoportokból aggregált adatokra vonatkozó feltételeket, amelyek már a kapott csoportok (aggregátum sorok) halmazát szőkítik. Egyszerőbb esetben a feltételek csak a 2. lépésben megadott aggregáló kifejezésekre hivatkoznak, azokat különféle összehasonlító, illetve logikai mőveletekkel kapcsolják össze. Tehát most a szoftver ezek választékát ajánlja fel a felhasználónak. Bonyolultabb feladat esetén ez a feltétel is hivatkozhat egy újabb – beágyazott – lekérdezés eredményére. Ekkor a beágyazott lekérdezésre is be kell járni a párbeszéd 1-5. lépéseit.

6. Amennyiben a felhasználó több, azonos szintő lekérdezés eredményét halmazmőveletek-kel akarja összekapcsolni, akkor mindegyik lekérdezésre külön-külön le kell folytatni az

5 Itt és a továbbiakban a táblák közé a virtuális táblákat – a view-kat (lásd a 3.4.2. szakaszban) –, illetve Access a korábban megírt és elmentett lekérdezéseket (lásd a 3.5.2. szakaszban) is odaértjük.


105

1-5. párbeszédet, továbbá ki kell választani az összekapcsoló mőveletet (egyesítés, met-szet vagy különbség).

7. A felületen jelezhetı, ha a felhasználó a kimenet sorait valamilyen sorrendben rendezetten szeretné kapni. Ekkor a rendezı ismérvek kiválasztása céljából a szoftver felajánlja a 2. lépésben definiált adatok listáját, és minden kiválasztott ismérvre külön-külön megadható, hogy a rendezés iránya növı vagy csökkenı.

3.2.4 Ellenırzı kérdések a 3.2. alfejezethez

1. Mit jelent az adatmigráció?

2. Az adatbázis biztonsága milyen ellenırzési, megelızési és helyreállítási megoldásokat igényel?

3. Mik a szükséges feltételei az adatbázistartalom hitelességének?

4. Milyen feladatokat lát el az adatbázisadminisztrátor?

5. Az adabáziskezeléssel összefüggésben mit jelent a (technikai értelemben vett) tranzakció?

6. Milyen módokon zárulhat egy tranzakció?

7. Többfelhasználós környezetben hogyan kezeli le az adatbáziskezelı rendszer azt az esetet, amikor különbözı felhasználók (sessionök) azonos adatot egyszerre akarnak változtatni?

8. Hogyan jön létre a holtponti helyzet? - Hogyan lehet kezelni?

9. Milyen típusú parancsokat tartalmaz az SQL nyelv?

10. Milyen módot kínál az Access az SQL parancsok kipróbálására?

11. Milyen lehetıségeket kínálnak az interaktív adatbáziskezelı felületek?


106

3.3 Adatbázis definiálása

3.3.1 Adatbázis definiálása SQL nyelven

Az SQL DDL parancsai közül itt csak az adattábla és az indextábla definiálására szolgáló CREATE TABLE és CREATE INDEX parancsokkal ismerkedünk meg, azokkal is csak kivo-natosan, az egyszerőbb eseteikre szorítkozva: Nem foglalkozunk a parancsok olyan elemeivel, amelyekben az adattábla vagy az indextábla fizikai tárolási struktúrájáról lehet rendelkezni. (A 3.4. alfejezet az alapvetı adatkezelı parancsokat is tárgyalja.)

Adattábla definiálása (CREATE TABLE parancs)

Alább az adattáblát definiáló CREATE TABLE parancs leegyszerősített változatának sémája látható. (Az ilyen sémákban alkalmazott jelek értelmezését a 3.2.2. szakasz tárgyalta.)

CREATE TABLE táblanév ( definíciós egység [, definíciós egység] … )

Egy definíciós egység kétféle lehet: vagy oszlopdefiníció, vagy tábla-megszorítás.

Egy oszlopdefiníció mintája: oszlopnév adattípus [oszlopmegszorítás] …

Az oszlopnév értelemszerően alkalmazandó, de minden névhivatkozásra (tábla, index-tábla, view, oszlop, megszorítás stb. nevére) be kell tartani a következı szabályokat: egy név alapesetben betővel kezdıdhet, betővel és számjegyekkel folytatódhat. A betők alatt az angol ábécé 26 betőjét és az _ (aláhúzás) jelet kell érteni. Ha más karaktereket is akarunk alkal-mazni a névben (pl. a magyar ábécé ékezetes betőit, szóközt, kötıjelet stb.), akkor a nevet névzárójelek közé kell tenni. A legtöbb SQL nyelvjárásban névzárójelként a ”” macska-körmök alkalmazhatók (pl. ”négy szóból álló név” ). Ez alól pont az Access SQL-je képez kivételt. Az Accessben a [ ] zárójelpár alkalmazható névzárójelként, tehát az elıbbi példa az Accessben így néz ki: [négy szóból álló név]. (A [ ] jeleket most nem meta-jelként, hanem a konkrét parancsban ténylegesen alkalmazandó jelekként kell értelmezni, hiszen itt nem sablonról, hanem névhivatkozásra adott konkrét példákról van szó.)

Az Access más tekintetben is eltér a szabványos SQL-tıl. Némi „magyarításon” esett át, ezért a névhi-vatkozásokban megengedi az ékezetes betőket anélkül, hogy a nevet [ ] jelek közé kellene tenni. Tehát az Access SQL-ben az Egységár szabályos oszlopnév. (Ha azonban a leírt parancsokat az olvasó egy másik SQL-ben is ki akarja próbálni, akkor ajánlatos az [Egységár] formánál maradni. Ugyanis errıl a [ ] � ”” globális cserével könnyő áttérni a szabványos SQL-ben is mőködı ”Egységár” alakra. ) Sajnos a „magyarítás” felemásra sikerült, elsısorban a grafikus felületen végzett mőveletekre terjed ki, az SQL-ben kiadott parancsokra már kevésbé, aminek az lett az eredménye, hogy az Access önmagával sem kompatibilis, ha váltogatjuk a grafikus felületen és az SQL-ben való használatot. Például a grafikus felületen a dátumot ilyen formában lehet megadni: #2007.09.27.# , azonban ugyanez a dátum egy SQL parancsba már csak így írható be: #9/27/2007# . Hasonlóan az Igen/Nem típusú adat értékei a grafikus felületen: Igaz vagy Hamis . Ugyan-ezek egy SQL parancsban csak a True , illetve False , esetleg -1 , illetve 0 alakban állhatnak.

Emlékeztetünk rá, hogy az SQL a névhivatkozásokban nem különbözteti meg a kis és a nagy betőket, tehát egy vevocim oszlopnév azonos a VEVOCIM vagy a VevoCim oszlop-névvel.


107

Az adattípus az adott adatbáziskezelı által ismert adattípust jelent, pl.: INTEGER – biná-ris egész szám, CHAR(hossz) – fix hosszúságú karakterlánc, VARCHAR(maximális hossz) – változó hosszúságú karakterlánc, DATE – dátum, MONEY – pénztípus.

Az oszlopmegszorítás és a táblamegszorítás alakja:

[CONSTRAINT megszorításnév] megszorítástörzs

A fenti minta azt is kifejezi, hogy a CONSTRAINT kulcsszót csak akkor kell alkalmazni, ha a megszorítást névvel akarjuk ellátni, ha ezt nem tesszük meg, úgy az adatbáziskezelı fog valamilyen nevet adni a megszorításnak.

A megszorítástörzs néhány változata oszlopmegszorítás esetén:

[NOT] NULL

PRIMARY KEY

REFERENCES táblanév [(hivatkozott oszlopnév)] [ON DELETE CASCADE]

CHECK (feltétel)

NOT NULL – Jelzi, hogy az oszlop nem lehet definiálatlan (NULL) értékő semelyik konkrét sorban. A NULL viszont éppen megengedi, hogy a táblában lehessenek olyan sorok, amelyekben az oszlop definiálatlan értékő. Az ilyen megszorítás hiánya a NULL megadásával egyenértékő, kivéve ha más megszorítás (pl. PRIMARY KEY) ezt ki nem zárja.

A NULL érték egy speciális „üres” érték, ami azt jelenti, hogy egy egyedre egy (különben értelmezhetı) érték történetesen ismeretlen. Ha egy alkalmazottra a FIZETES oszlop 0 étékő, az azt jelenti, hogy ez az alkal-mazott határozottan ingyen dolgozik; de ha NULL értékő, az azt jelenti, hogy nem tudjuk, mennyi a fizetése. Ha egy személyre a Leánykori_nev oszlop üres láncot tartalmaz, akkor az adott személynek határozottan nincs leánykori neve (születési neve), ha viszont NULL értéket tartalmaz, akkor a leánykori név ismeretlen.

PRIMARY KEY – Jelzi, hogy az oszlop elsıdleges kulcs.

REFERENCES táblanév [(hivatkozott oszlopnév)] [ON DELETE CASCADE] – Jelzi, hogy a definiált oszlop idegen kulcs a táblanévvel adott (fölérendelt) táblából. A hivatkozott oszlopnév a definiált oszloppal hivatkozott oszlop neve a fölérendelt táblában; és azt csak akkor kell megadni, ha különbözik a definiált oszlop nevétıl. Az [ON DELETE CASCADE] rész magyarázatát lásd késıbb, a táblamegszorításoknál!

CHECK (feltétel) – A zárójelek között a definiált oszlopra vonatkozó feltétel adható meg logikai kifejezés formájában.

A megszorítástörzs néhány változata táblamegszorítás esetén:

PRIMARY KEY (oszlopnév [, oszlopnév] …)

FOREIGN KEY (oszlopnév [, oszlopnév] …) REFERENCES táblanév [(hivatkozott oszlopnév [, hivatkozott oszlopnév] …)] [ON DELETE CASCADE]

CHECK (feltétel)

PRIMARY KEY (oszlopnév [, oszlopnév] …) – Ha az elsıdleges kulcs több oszlopból tevıdik össze, akkor annak komponenseit a zárójelek közt vesszıvel elválasztva kell felsorolni.

FOREIGN KEY (oszlopnév [, oszlopnév] …) REFERENCES táblanév [(hivatkozott osz-lopnév [, hivatkozott oszlopnév] …)] [ON DELETE CASCADE] – Ha több oszlop együtt alkot egy idegen kulcsot akkor azt így – táblamegszorításként – lehet megadni. Az ON DELETE CASCADE rész alkalmazásával azt a (hivatkozás-integritási) szabályt lehet jelezni,


108

hogy ha az idegen kulccsal hivatkozott sor törlıdik a fölérendelt táblából, akkor az arra hivat-kozó összes sornak is törlıdni kell az éppen definiált táblából. (Például ha egy rendelés sor törlıdik a RENDELES táblából, akkor a ráhivatkozó tételeknek is törlıdni kell a RENDE-LESTETEL táblából.) Az ON DELETE CASCADE rész hiánya viszont azt jelzi, hogy a fölérendelt tábla egy sora mindaddig nem törölhetı, amíg legalább egy ráhivatkozó sor létezik az éppen definiált táblában. (Például nem törölhetı egy árucikk sora a CIKK táblából, amíg legalább egy ráhivatkozó készletsor létezik a KESZLET táblában.)

CHECK (feltétel) – A zárójelek között a tábla több oszlopa közötti összefüggést lehet megadni mint feltételt logikai kifejezés formájában. Például CHECK(Szuletes_datum <= Halalozas_datum) .

Két tábla definiálása: Az elmondottakat egy Alkalmazott és egy Irat tábla definíciójával szemléltetjük:

CREATE TABLE Alkalmazott ( Torzsszam INTEGER PRIMARY KEY, Nev VARCHAR(40) NOT NULL, Neme CHAR(1) NOT NULL CHECK('N' OR 'F'), Szul_datum DATE NOT NULL, Osztalykod INTEGER NULL REFERENCES Osztaly, Fizetes MONEY NULL, Utolso_fiz_emeles DATE NULL, Ervenyesseg_vege DATE NULL );

CREATE TABLE Irat ( Iktatoszam INTEGER PRIMARY KEY, Ugyszam INTEGER NOT NULL REFERENCES Ugy, Bejovo_kimeno CHAR(2) NOT NULL CHECK(Bejovo_kimeno IN ('BE', 'KI')), Kuldte_partnerkod INTEGER NOT NULL CONSTRAINT Kuldo REFERENCES Partner (Partnerkod ), Keszitette_torzsszam INTEGER CONSTRAINT Keszito REFERENCES Alkalmazott (Torz sszam), Intezkedo_torzsszam INTEGER CONSTRAINT Intezkedo REFERENCES Alkalmazott (To rzsszam), CONSTRAINT Partnerek_ugyintezok CHECK( ( Bejovo_kimeno='BE' AND Kuldte_partnerkod>0 AND Keszitette_torzsszam=0 AND Intezkedo_torzsszam>0 ) OR ( Bejovo_kimeno='KI' AND Kuldte_partnerkod=0 AND Keszitette_torzsszam>0 AND Intezkedo_torzsszam=0 ) ) );

1. megjegyzés: Ha egy parancsfájlban több SQL parancsot helyezünk el, akkor elválasz-tásul az egyes parancsokat pontosvesszıvel (;) kell lezárni.

2. megjegyzés: Amennyiben a fenti parancsokat az olvasó az Access alatt akarja kipró-bálni, az egyrészt elıkészítést igényel, másrészt – az Access korlátai miatt – csak részben lehetséges. Az elıkészítés a 3.2.2. szakaszban a 3.1-3.4. ábrákon mutatott mőveleteken felül azt is jelenti, hogy a CREATE TABLE Alkalmazott … parancsot megelızıen létre kell hozni a benne hivatkozott Osztaly táblát. Az Access hiányossága, hogy a CHECK(feltétel) alakú megszorítást nem ismeri, tehát a fenti példában adott parancsokból a CHECK megszo-rításokat (az Accessben való kipróbálás idejére) ki kell hagyni, és utólag a tábladefiniálás


109

párbeszédes, grafikus felületén (lásd a 3.3.2. szakaszban) oszlopra vagy táblára vonatkozó érvényességi szabályokkal lehet pótolni. – Az Osztaly táblát elızetes létrehozása történhet vagy a tábladefiniálás párbeszédes, grafikus felületén vagy az alábbi SQL paranccsal:

CREATE TABLE Osztaly (Osztalykod INTEGER PRIMARY KEY, Osztaly_neve VARCHAR(40) NOT NULL)

Indextábla definiálása (CREATE INDEX parancs)

Az indextáblát definiáló CREATE INDEX parancsnak is csak az egyszerő eseteire adunk sémát:

CREATE [UNIQUE] INDEX indextábla neve ON adattábla neve ( oszlopnév [ , oszlopnév ] … )

Az oszlopnevek annak kulcsnak a komponensei, amelyre az indexelés történik, egyébként pedig az adattáblából vett oszlopokat jelentenek. Több oszlopnevet összetett kulcs esetén kell felsorolni. Az UNIQUE rendelkezést akkor kell alkalmazni, ha minden kulcsérték az adattáb-lának csak egy sorában fordulhat elı. Tehát elsıdleges kulcsra indexeléskor ezt a rendelkezést alkalmazni kell.

Indextáblák definiálása: A parancs további magyarázata helyett, szemléltetésül álljon itt három konkrét parancs:

CREATE UNIQUE INDEX Ugyirat_index1 ON Ugyirat (Ugyi ratszam); CREATE INDEX Ugyirat_index2 ON Ugyirat (Kuldte_part nerkod); CREATE UNIQUE INDEX RT_index ON Rendelestetel (Rendelesszam, Cikkszam);

A relációs adatbázisokban az elsıdleges kulcsra és az idegen kulcsokra indokolt indexet felépíteni, de elıfordulhat, hogy olyan oszlopra célszerő indexelni, ami egy adott táblában sem elsıdleges kulcs, sem idegen kulcs. Erre tipikus példa egy személyi nyilvántartás név szerinti indexelése. – Az is igaz, hogy az OLTP adatbázisokban az indexeléssel takarékoskodni kell. Mert amíg az indextáblák alkalmazása a lekérdezést általá-ban gyorsítja, addig a karbantartást jelentısen lassíthatja. Ennek az az oka, hogy amikor például egy új sort iktatunk be egy adattáblába, azzal együtt indexbejegyzéseknek kell keletkezni az azon táblára felépített összes indextáblában is.

3.3.2 Adatbázis definiálása az Access grafikus felü letén

Új adatbázist vagy egy adatbázisban új elemeket a 3.2.3. szakaszban már említett párbe-szédes felületeken is definiálhatunk. Ezek közé tartozik a Microsoft Access programmal gra-fikus (táblázatos) felülete. Az ezen szakaszban bemutatott példák és képernyıábrák is az Access felhasználásával készültek.

Tábla definiálása

A 3.5. ábrán az olvasó az Access táblatervezı felületét, és abban történetesen a fıkönyvi számlák forgalomtételeit tartalmazó tábla (táblanév: Fkvisza_forg ) tervét (definícióját) látja. Ezen a felületen megadhatók a tábla oszlopainak, más szóval mezıinek a jellemzıi (mezınév, adattípus és további – általános, illetve megjelenítési – jellemzıi). Mivel a fókusz éppen az Fkvisza_forg tábla Számlaoldal nevő mezıjén van, az alsó füleslapokon ennek a mezınek a további jellemzıit lehet látni, illetve megadni. Például az Érvényességi szabály nevő rovatban a Számlaoldal lehetséges értékeire vonatkozó megszorítás adható meg: a =’T’ Or =’K’ megszorítás azt jelenti, hogy a tábla Számlaoldal mezıjében csak a T (tartozik) vagy a K (követel) érték állhat.


110

Az Fkviszla_forg tábla értelmezése:

E tábla rendeltetése, hogy a gazdasági események (az azokat képviselı bizonylatok) könyvelé-sekor keletkezı fıkönyvi forgalomtételeket tárolja.

Tetelsorszam : Egy fıkönyvi számlára könyvelt forgalomtétel azonosítója (elsıdleges kulcsa).

Idoszakkod : Annak a mérlegidıszaknak a kódja, amelyre a forgalomtétel könyvelve lett.

Szamlatukorkod : A Szamlatukor -sor azonosítója, azaz idegen kulcs a Szamlatukor táb-lából (lásd a 3.9. ábrán), amely a létezı fıkönyvi számlaszámokat (Fkviszla_szam ) tárolja. Tehát az Fkviszla_forg tábla soraiban a Szamlatukorkod hivatkozza azt a fıkönyvi számlaszámot, amelyre a sorban tárolt tétel könyvelve lett. (De akkor miért nem a fıkönyvi számlaszám áll a Szamlatukorkod helyén? – Azért, mert a Szamlatukor tábla sorait a fıkönyvi számlaszám nem azonosíthatja, hiszen azonos fıkönyvi számlaszám a tábla több sorában is megjelenhet. Ugyanis ez a tábla a számlaszámokat történetileg tárolja, azaz nem csak az aktuálisam érvényes számlaszámokat, hanem a korábbi években érvényeseket is tartalmazza. Így, ha egy számlaszám valamikor érvényes volt, majd érvénytelenítették, majd ismét érvényessé vált – de már a korábbitól különbözı jelentéssel, akkor ez a számlaszám szükségképpen több Szamlatukor -sorban van jelen.)

Szamlaoldal : Azt mutatja, hogy a Szamlatukorkod hivatkozott számla melyik oldalára lett könyvelve a tétel összege. Értékei: T = tartozik; K = követel.

Osszeg : Az adott számla adott oldalára könyvelt forgalomérték (forintban).

Bizonylatkod : A Bizonylat táblában a tétel forrásbizonylatát hivatkozó idegen kulcs. – Az azonos bizonylatról keletkezett tételek éppen arról ismerhetık fel, hogy mindegyikben azonos a Bi-zonylatkod értéke.

Tételleírás : Tetszıleges emlékeztetı szöveg.

TJ_tetelsorszam : Csak törlı vagy javító tételben van kitöltve, és az azzal törölt vagy javított forgalomtétel azonosítóját tartalmazza.

Kapcsolat : Szintén csak törlı vagy javító tételben van kitöltve. Értékei: T = törlés; J = javítás.

Megjegyzés: A számvitel szabályai szerint az egyszer már lekönyvelt tétel nem változtatható. Ha esetleg utóbb hibásnak bizonyul, akkor is az adatbázisban marad, a hiba csak további strornózó és javító tételek hozzáadásával korrigálható: Ha a hiba csak annyi, hogy egy tételt egyáltalán nem kellett volna könyvelni, akkor csak stornózni kell, azaz a tételével azonos összeggel és azonos számlára, de a számla ellenkezı oldalára vonatkozó újabb tételt kell létrehozni, ez a törlı tétel. Ha viszont máskép-pen kellett vona könyvelni, akkor a törlı tételen felül még olyan javító tétel(eke)t is létre kell hozni, amely(ek) már a helyes könyvelésnek megfelelı tartalommal bír(nak). – Hogy egyértelmő legyen, hogy egy törlı vagy egy javító tétel melyik tételnek törlése vagy javítás, a törlı, illetve javító tétel a TJ_tetelsorszam mezıjében tartalmazza a törölt, illetve javított tétel azonosítóját, a Kapcsolat mezıjében pedig viszony típusát jelzı kódot.

A 3.5. ábrán a Tetelsorszam elıtti kulcsszimbólum jelzi, hogy a Tetelsorszam képezi a tábla elsıdleges kulcsát. Egy mezı elsıdleges kulcs minıségét úgy lehet beállítani, hogy a jobb egérgombbal a mezıre kattintva, arra helyezzük a fókuszt, majd az Elsıdleges kulcs funkciógombra kattintunk.

Nem csak egy-egy oszlopra vonatkozó érvényességi szabályok, hanem a tábla egészére vonatkozóak is megadhatók. Ilyen példát mutat a 3.6. ábra. Az ott látható Tábla tulajdonságai ablak a Nézet menü Tábla tulajdonságai menüparancsára kattintással jeleníthetı meg. Az ablak Érvényességi szabály mezıjébe írt feltételt itt kinagyítva megismételjük:

([TJ_Tetelsorszam] Is Null And [Kapcsolat] Is Null) Or ([TJ_Tetelsorszam] Is Not Null And [Kapcsolat] Is N ot Null)

A fenti feltétel azt jelenti, hogy a TJ_Tetelsorszam és a Kapcsolat mezık (osz-lopok) pontosan egyszerre lehetnek üresek, illetve pontosan egyszerre lehetnek kitöltve. – Ez a szabály azért nem adható meg mezıszabályként, mert nem egyetlen mezıre, hanem – egy soron beüli – két mezı közötti viszonyra vonatkozó feltételt foglal magában.


111

Az elıbbinél lényegesen bonyolultabb szabályok is elıfordulhatnak. Például olyanok, amelyek több – esetleg különbözı táblákban lévı – adatsor közötti összefüggésre vonatkoz-nak. Ilyen az a szabály is, hogy az egy gazdasági eseményrıl (egy bizonylatról) könyvelt „követel” oldali tételek együttes összege egyenlı kell legyen az ugyanarról könyvelt „tar-tozik” oldali tételek együttes összegével. – Az ilyen szabályok már táblára vonatkozó érvé-nyességi szabályban sem adhatók meg, teljesülésük ellenırzésére tárolt eljárásokat kell írni (lásd a 3.2.2. szakaszban). A fejezet azonban ezekkel már nem foglalkozik.

3.5. ábra: Tábladefiniáló (tervezı) felület Accessben

3.6. ábra: Táblára vonatkozó érvényességi szabály a Tábla tulajdonságai ablakban

Elsıdleges kulcs minıség jelzése

A fókusz jelzése

Az aktuális oszlopra vonatkozó érvényességi szabály

Elsıdleges kulcs mi-nıség be- vagy kikap-csolásásra szolgáló funkciógomb


112

3.7. ábra: A Bizonylatkód megjelenítési

jellemzıinek beállítása

A 3.7. ábra a Bizonylatkod mezı Meg-jelenítés jellemzıit mutatja. A jellemzık értelme az, hogy egy új tétel rögzítésekor a bizonylatkó-dot a táblába ne a felhasználónak kelljen beírni, hanem a felhasználó egy választéklistából (lásd Kombinált lista) választhassa ki. (A megjelenítés ilyen beállításának mőködés közbeni eredményét a 3.8. ábra mutatja.)

A választéklista a Bizonylatvalasztek nevő lekérdezés eredményét jeleníti meg (lásd Sorforrás típusa: Tábla/lekérdezés; Sorforrás: Bi-zonylatvalasztek). A lista a sorforrás elsı két osz-lopát mutatja (lásd Oszlopszám: 2), és a kiválasz-tott sorból az elsı oszlop tartalmát adja vissza (lásd Kötött oszlop: 1), és az lesz a tételben a Bi-zonylatkod mezı tartalma. Az oszlopszéles-ségek, a listasorok száma és a listaszélesség a választéklista megjelenítési méreteit határozzák meg. A felhasználó közvetlenül nem írhat be bi-zonylatkódot, azt csak kiválaszthatja (lásd Csak listaelem: Igen).

3.8. ábra: A 3.5-3.7 ábrák szerint definiált Fkviszla_forg tábla mőködés közben

Megjegyzés: Az Fkviszla_forg táblában a Bizonylatkód mezı valójában egy Bizonylat táblából származó idegen kulcs. De ha ez így van, akkor miért nem a Bi-zonylat tábla lett megadva a választéklista sorforrásaként, miért volt szükség a Bizony-latvalasztek nevő lekérdezésre? Azért, mert a felhasználó kívánsága az volt, hogy a választéklistában a Bizonylatkód -értékek csökkenı sorrendjében jelenjenek meg a biz-onylatok, hiszen új tételeket általában a legutoljára felvitt bizonylat(ok)hoz kapcsolódnak. Ha a Bizonylat táblában nem ilyen a rendezettség, mert például más célból általában a növekvı (pontosabban nem csökkenı) Bizonylatkód -értékek szerinti rendezettséget felté-telezünk, akkor kénytelenek vagyunk a Bizonylat tábla egy olyan lekérdezését használni


113

sorforrásként, amely a bizonylatokat a Bizonylatkód -értékek csökkenı (pontosabban nem növı) sorrendjében adja vissza.

A teljes adatbázis tervezése általában sok tábla megtervezését foglalja magában, és persze meg kell határozni a táblák kapcsolatait is. Az Access kapcsolattervezı felülete a 3.9. ábrán látható. Ezen a grafikus felületen a kapcsolatot jelölı vonalak egérrel húzhatók be a táblákat jelölı dobozok közé. A vonalakat úgy kell húzni, hogy a dobozok oldalán adódó tapadási pontjaik a kapcsolómezıket mutassák. Egyes táblákat több doboz is képviselheti ebben az ablakban. Például az Fkvisza_forg tábla azért szerepel kétszer (a második szerepének neve: Fkvisza_forg_1 ), mert önmagára visszamutató kapcsolatot is alkot (t.i. a sztornó-zó/javító és a sztornózott/javított sorok közötti kapcsolat miatt). Ugyancsak kétszer szerepel a kapcsolattervezı felületen a Szamlatukor tábla is (a második szerepének neve: Szamlatukor_1 ), mert az két szerepben is fölérendeltje a Gyujtoleiro táblának.

3.9. ábra: Táblák kapcsolatait meghatározó (kapcsolattervezı) felület ACCESS-ben

Egy kapcsolóvonalra duplán kattintva, vagy a kapcsolóvonalon a jobb egérgomb lenyo-mása után elıtőnı menübıl a Kapcsolat szerkesztése menüparancsot választva, a 3.10. ábra szerinti Kapcsolatok szerkesztése ablak jelenik meg.

Ha egy kapcsolatra a Kapcsolatok szerkesztése ablakban a Hivatkozás integritás meg-ırzése be van kapcsolva, akkor a rendszer nem engedi meg, hogy egy Fkviszla_forg -sor létrehozásakor vagy módosításakor olyan értéket írjunk a kapcsolómezıbe (jelen esetben a Bizonylatkod ba), amely nem létezik a Bizonylat táblában. A további két kapcsoló is csak a Hivatkozás integritás megırzése bekapcsolt állapotában használható.


114

Ha a Kapcsolt mezık kaszkádolt frissítése be van kapcsolva, akkor abban a rendkívüli6 esetben, amikor egy bizonylat kódja (elsıdleges kulcsa) változik, automatikusan a bizonylat-ról keletkezett tételekben is az új értékre módosul a Bizonylatkod tartalma.

Ha a Kapcsolt mezık7 kaszkádolt törlése be lenne kapcsolva, akkor egy bizonylat törlése esetén, automatikusan a bizonylatról keletkezett összes tétel is törlıdne. Esetünkben ez nem lenne jó, mert könyvelt tételt nem szabad törölni, ezért a 3.10. ábrán ez a kapcsoló kikapcsolt állapotban van, aminek az a hatása, hogy ha egy bizonylatra már hivatkozik könyvelt tétel, akkor ennek a bizonylatnak a törlését a rendszer visszautasítja.

3.10. ábra: A Bizonylat és az Fkviszla_forg kapcsolata a Kapcsolatok szerkesztése ablakban

3.11. ábra: A Bizonylat és az Fkviszla_forg kapcsolat

illesztési típusa az Illesztési tulajdonságok ablakban

Az elıbbiek szerint megtervezett táblákon – ugyancsak az Access felületét használva – különféle adatkezelési mőveleteket lehet végezni: új adatsorokat lehet bevinni, korábban bevitt adatokat meg lehet változtatni, adatsorokat ki lehet törölni, az adattartalmat le lehet kérdezni (lásd a 3.5. alfejezetben).

6 Ez azért rendkívüli, mert az elsıdleges kulcsnak stabilnak kell lenni, azaz rendesen nem változhat. 7 Ez egy hibás fordítás eredménye. Helyesen Kapcsolt rekordok kaszkádolt törlése lenne.

Ezzel hozható elı az Illesz-tési tulajdonságok ablak.

Kikapcsolva, ezért visszautasítja az olyan bizonylat törlését, amelyhez létezı ráhi-vatkozó tétel.

Be van kapcsolva, ezért létrehozás vagy módosítás ese-tén csak olyan érték írható az Fkviszla_forg tábla Bizonylatkod mezıjébe, amilyen már létezik a Bizonylat táblában.

Az Access automatikusan felismeri, hogy a kapcsolat típusa egy-a-többhöz.

Az illesztés típusa a kapcsolatnak nem egy stabil tulajdonsága, mert a célnak megfelelıen átállítható. Azt szabályozza, hogy az olyan lekérde-zésekben, amelyekben a két tábla együtt vesz részt, köztük a JOIN milyen típusát kell elıállítani.


115

3.3.3 Ellenırzı feladatok a 3.3. alfejezethez

1. SQL nyelven definiáljon egy olyan PROJEKT táblát, amely a Projektkod (Integer), Projektnev (Varchar(50)), Projekt_kezdete (Date), Projekt_vege (Date) oszlopokat tartalmazza! (Az oszlopnevek mellett zárójelben az adattípus áll.) A tábla elsıdleges kulcsa a Projektkod . A parancsban rendelkezzen arról is, hogy a Projekt_kezdete nem lehet üres, és a Projekt_vege (ha ki van töltve) nem lehet korábbi a Projekt_kezdete értékénél.

2. SQL nyelven definiáljon egy olyan EROFORRAS táblát, amely az Eroforraskod (Integer), Eroforras_neve (Varchar(50)), Eroforrastipuskod (Integer), Standard_fajlagos-

_ktsg (Money), Tulmunka_fajlagos_ktsg (Money), Vetitesi_mertekegyseg_kodja (Integer), Hasznalatonkenti_ktsg (Money) oszlopokat tartalmazza. (Az oszlopnevek mellett zárójelben az adattípus áll.) A tábla elsıdleges kulcsa az Eroforraskod . A parancsban rendelkezzen arról is, hogy az Eroforras_neve , az Eroforrastipuskod , a Standard_fajlagos_ktsg és a Vetitesi_mertekegyseg_kodja nem lehet üres, a Standard_fajlagos_ktsg csak pozitív értékő lehet, továbbá a Tulmunka_fajlagos-

_ktsg (ha ki van töltve) nem lehet kisebb a Standard_fajlagos_ktsg értékénél.

3. SQL nyelven definiáljon egy olyan PROJEKTHEZ_RENDELT_EROFORRAS táblát, amely a Projektkod (Integer), Eroforraskod (Integer) és a Kapacitas (Integer) oszlopokat tartalmazza. (Az oszlopnevek mellett zárójelben az adattípus áll.) A tábla elsıdleges kulcsa a Projektkod+Eroforraskod . A parancs nyilvánítsa ki azt is, hogy a Projektkod a PROJEKT táblából, az Eroforraskod pedig az EROFORRAS táblából származó idegen kulcs.

4. Az Access grafikus tervezıfelületén definiáljon egy TEVEKENYSEG táblát, amely a Tevekenysegkod (Számláló), Tevekenyseg_neve (Szöveg), Projektkod (Szám), Tevekenyseg_idotartama (Szám), Idomertekkod (Szám), Tevekenyseg_kezdete (Dá-tum/Idı), Tevekenyseg_vege (Dátum/Idı), Nem_muveleti_ktsg (Pénznem) oszlopokat tartalmazza. (Az oszlopnevek mellett zárójelben az adattípus áll.) A tábla elsıdleges kulcsa a Tevekenysegkod . A definíció nyilvánítsa ki azt is, hogy a Projektkod a PROJEKT táblából származó idegen kulcs. A definíció rendelkezzen arról is, hogy a Tevekenyseg_neve , a Projektkod , a Tevekenyseg_idotartama , a Idomertekkod és a Tevekenyseg_kezdete nem lehet üres, továbbá a Tevekenyseg_vege (ha ki van töltve) nem lehet kisebb a Tevekenyseg_kezdete értékénél.


116

3.4 Adatkezel ı SQL parancsok

3.4.1 Adatok bevitele, törlése és módosítása SQL-be n

Új adatsor bevitele (INSERT parancs)

Ha az adatbázis egy tábláját egy új adatsorral akarjuk bıvíteni, azt az INSERT paranccsal tehetjük meg. Ennek egy egyszerő formája a következı:

INSERT INTO táblanév [ [AS] másodnév] [ (oszlopnévlista) ] VALUES (értéklista)

A parancs használatát az egyes szintaktikai egységek alakját részletes magyarázat helyett csak egy példával szemléltetjük (közülük a másodnévrıl csak késıbb, a 3.4.2. szakaszban a SELECT parancsnál lesz szó).

Új sor bevitele: A 3.3.1. szakaszban definiált Alkalmazott táblába a következı paranccsal vihetünk be egy új alkalmazottat leíró új sort:

INSERT INTO Alkalmazott (Torzsszam, Nev, Neme, Szul_datum, Osztalykod, Fi zetes) VALUES (192, 'Kiss József', 'F', #1/21/1952#, 7, 300000)

Az létrejövı új sor tartalma: Torzsszam 192, Nev'Kiss József', Neme'F', Szul_datum '1952.01.21', Osztalykod 7, Fizetes 300000.

1. megjegyzés: Ha az oszlopnévlista a tábla összes oszlopát felsorolja, és éppen abban a sorrendben, mint a táblát definiáló CREATE TABLE parancs, akkor az oszlopnévlista akár el is hagyható.

2. megjegyzés: Az értéklistában látható #1/21/1952# érték a '1952.01.21' dátumnak felel meg.

Adatsor fizikai törlése (DELETE parancs)

Ha az adatbázis egy táblájából (fizikailag) törölni akarunk egy vagy több sort, akkor a DELETE parancsot kell alkalmazni. Ennek egy egyszerőbb alakja:

DELETE FROM táblanév [ [AS] másodnév] WHERE feltétel

A feltétel egy logikai kifejezés: azok a sorok törlıdnek az adott táblából, amikre a feltétel igaz értéket ad.

Törlés az Alkalmazott táblából: Példaként nézzük elıbb az 1164-es törzsszámú alkalmazott sorának törlését, majd az 5-ös osztályhoz tartozó alkalmazottak sorainak törlését:

DELETE FROM Alkalmazott WHERE Torzsszam = 1164 ;

DELETE FROM Alkalmazott WHERE Osztalykod = 5 ;


117

Megjegyzés: A gyakorlatban tartózkodnak a fontosabb adatok fizikai törlésétıl, helyette inkább logikai törlést alkalmaznak, ami lényegében a sor módosítással (lásd a következıkben az UPDATE parancsot) történı érvénytelenítését jelenti. Például egy Alkalmazott sor logikai törlése abból állhat, hogy benne az Ervenyesseg_vege oszlop tartalmát NULL értékrıl egy konkrét idıpontra változtatják, és az adott idıpontnál késıbbi idıpontban az adatsor már érvénytelennek számít.

Adatsor tartalmának módosítása (UPDATE parancs)

Ha az adatbázis egy táblájában meg akarjuk változtatni egy vagy több sor tartalmát, akkor azt az UPDATE paranccsal tehetjük meg. Ennek egy egyszerőbb alakja:

UPDATE táblanév [ [AS] másodnév] SET oszlopnév1 = kifejezés1 [, oszlopnév2 = kifejezés2]... WHERE feltétel

Fizetésemelés: Tegyük fel, hogy a 6-os osztályhoz tartozók fizetését 5%-kal emelik azoknál az alkalmazottaknál, akiknek a fizetése még nem érte el a 300000 forintot, és az utolsó fizetésemelésük 2001. december 31-nél korábban történt (vagy még soha sem emelték a fizetésüket). Ekkor az adat-bázis tartalma a következı paranccsal aktualizálható:

UPDATE Alkalmazott SET Fizetes = Fizetes * 1.05 WHERE Osztalykod = 6 AND Fizetes < 300000 AND ( Utolso_fiz_emeles IS NULL OR Utolso_fiz_emeles < #12/31/2001# )

A fenti megoldásban látható #12/31/2001# dátumkonstans a '2001.12.31' dátum ACCES SQL-ben alkalmazható alakja.

Az UPDATE parancsnak van olyan változata is, amelynél a módosító (új) értékeket vagy a módosítás feltételeit az aktualizált táblától különbözı táblából kell venni. Ez azonban épít a következı szakaszban tárgyalt SELECT parancsra, így elıbb azzal kell megismerkedni.

3.4.2 Adatok lekérdezése SQL-ben

Lekérdezés az adatbázisból (SELECT parancs)

Az adatbázisban tárolt adatok a SELECT parancs segítségével kérdezhetık le. Ezzel a paranccsal egy kicsit többet foglalkozunk, elıször egy egyszerő alakjával kezdjük:

SELECT [ALL | DISTINCT] mit/hova FROM honnan [WHERE feltétel] [GROUP BY csoportosítás] [HAVING csoportfeltétel] [ORDER BY rendezés] ;

Ebben a mit/hova rész azt írja le, hogy

• mit: milyen adatokat kérdezünk le, az adat (egy mit-elem) megadható oszlopnévvel, kifejezéssel, konstanssal;

• hova (milyen nevő változókba, képernyıoszlopokba, képernyımezıkbe) kérjük elhe-lyezni az adatokat, – tehát egy hova-elem mindig egy célobjektum nevét jelenti.


118

A hova rész elmaradhat, és akkor a mit felépítése: mit-elem1 [, mit-elem2]....

Itt és a késıbbi szintaktikai leírásokban is a mit-elem egy oszlop neve vagy minısített neve vagy egy kifejezés. Ha egy kifejezés oszlopra hivatkozik, azt szintén az oszlop nevével vagy minısített nevével teheti meg. (A minısített névrıl késıbb.) Ha a mit-elem egy oszlop neve (akár minısítéssel együtt), akkor a hiányzó hova-elem neve azzal lesz azonos; ha viszont a mit-elem egy kifejezés, akkor (párbeszédes felületen) a rendszer generál neki nevet.

Ha a SELECT kulcsszó után a mit is és a hova is szerepel, akkor a következı alakok lehetségesek:

mit-elem1 [, mit-elem2]... INTO hova-elem1 [, hova-elem2]... mit-elem1 AS hova-elem1 [, mit-elem2 AS hova-elem2]... hova-elem1 = mit-elem1 [, hova-elem2 = mit-elem2]...

A harmadik eset csak speciális SQL változatokban, általában programnyelvbe beágyazott változatban fordul elı.

A honnan egy vagy több honnan-elem vesszıvel elválasztott felsorolása lehet: honnan-elem1 [, honnan-elem2] ...

Ebben a honnan-elem az alábbi változatok egyike lehet: forrás neve [ [AS] másodnév] JOIN-kifejezés (al-SELECT).

A forrás lehet: tábla vagy view (ennek fogalmát késıbb tárgyaljuk a 3.4.3. szakaszban) vagy (csak az Access esetében) egy korábban definiált és névvel elmentett lekérdezés.

A másodnévre vonatkozó tudnivalók: • A másodnév felépítésére ugyanazok a szabályok vonatkoznak, mint általában az adat-

bázisobjektumok nevének felépítésére. • Ha másodnevet alkalmazunk, akkor a parancs további részében (például egy tábla

oszlopainak minısített nevében) a forrás (a tábla) csak a másodnévvel hivatkozható. • A másodnév alkalmazása elkerülhetetlen, ha egy SELECT parancs vagy másmilyen

SQL parancs valamely forrást többszörösen – több szerepben – is használ (lásd késıbb a 3.14. táblázat szerinti kimenetet produkáló lekérdezést), mert akkor a forrás különbözı szerepei csak a különbözı másodnevekkel különböztethetık meg.

A forrásokkal összefüggéssel a mit felépítésérıl még el kell mondani néhány további tudnivalót:

• Ha a lekérdezésnek egyetlen forrása van, és a mit a forrás összes oszlopa (abban a sorrendben, amilyenben a forrás oszlopait definiáltuk), akkor a mit-elem1 [, mit-elem2].... lista egyetlen *-gal helyettesíthetı.

• Az oszlop minısített neve: F.O alakú, amelyben F a forrás neve vagy a forrás má-sodneve, az O pedig az oszlop neve.

• Ha a lekérdezés több forrásból dolgozik, és valamely mit-elem olyan oszlopot hivat-kozik, amely több forrásban is jelen van, akkor ez a mit-elem csak minısített oszlopnév lehet.

• Ha a lekérdezés több forrásból dolgozik, és a mit tartalmazza az egyik forrás összes oszlopát (egy tömbben és abban a sorrendben, amilyenben a forrás oszlopait defini-áltuk), akkor a mit-lista ezen része egy F.*-gal helyettesíthetı, amelyben F a forrás neve vagy a forrás másodneve.


119

A JOIN-kifejezés és az al-SELECT eseteket késıbb tárgyaljuk a 3.4.3. szakaszban.

A feltétel egy logikai kifejezés, azaz egy igaz vagy hamis értéket eredményezı kifejezés, amellyel szőkíthetı a visszakeresendı adatsorok halmaza. – A csoportosítást, a csoportfelté-telt és a rendezést a késıbbiekben konkrét példákhoz kötve mutatjuk be.

A 2-es osztályhoz tartozó alkalmazottak minden adatának lekérdezése a 3.3.1. szakaszban defi-niált Alkalmazott táblából (az összes oszlop felsorolása a * jellel helyettesíthetı):

SELECT * FROM Alkalmazott WHERE Osztalykod = 2 ;

Csak a Fizetes oszlop értékére vagyunk kiváncsiak (háromféle megoldás – az ALL és a

DISTINCT értelmezése):

SELECT ALL Fizetes FROM Alkalmazott;

SELECT DISTINCT Fizetes FROM Alkalmazott;

SELECT Fizetes FROM Alkalmazott;

Az utóbbi példa elsı megoldás esetén a kimeneti sorok száma azonos az alkalmazottak számával; tehát ha 5 olyan alkalmazott van, akinek 300.000 Ft a fizetése, akkor ez az összeg 5 sorban fog ismételten megjelenni. A második megoldás esetén a kimeneti sorok száma annyi, ahány különbözı fizetés összeg létezik az Alkalmazott táblában; tehát az elıbb említett 300.000 Ft a kimeneten csak egy sorban jelenik meg. A harmadik megoldás egyenértékő az elsıvel, mert ahol az ALL opció értelmezhetı, és nem alkalmazták a DISTINCT opciót, ott automatikusan az ALL van érvényben.

Hány alkalmazott tartozik a 2-es osztályhoz?

SELECT COUNT(*) FROM Alkalmazott WHERE Osztalykod = 2;

Osztály Alkalmazottak száma

3.12. táblázat: A következı lekérdezési példa kimenete

Hány alkalmazott tartozik az egyes osztályokhoz külön-külön? A kimenetet a 3.12. táblázat sze-rinti formában kell elıállítani. A kimenet sorai az alkalmazottak száma szerint csökkenı (nem növı) sorrendben, azonos alkalmazott szám mellett pedig az osztálykódok növekvı sorrendjében jelenjenek meg!

SELECT Osztalykod AS [Osztály], COUNT(*) AS [Alkalm azottak száma] FROM Alkalmazott GROUP BY Osztalykod ORDER BY COUNT(*) DESC, Osztalykod ASC;

A GROUP BY csoportosítással elıírhatjuk, hogy nem külön-külön az egyes forrás-sorokról, hanem azok csoportjairól kérünk aggregált adatokat. A fenti megoldásban a sorokat Osztalykod szerint csoportosítottuk, és az aggregált érték a csoportba tartozó sorok száma volt, amit a COUNT() függvénnyel lehet elıállítani. Az ORDER BY záradékban a DESC szó a csökkenı (nem növı – descendig) rendezettséget jelenti, ennek ellenkezıje az ASC (ascending) szóval kérhetı, de az utóbbinak felel meg az is ha, az ASC és DESC egyikét sem tüntetjük fel.

1. megjegyzés a legutóbbi példához: A COUNT( ) függvényben a zárójelek között osz-lopnév vagy oszlopsorszám állhat. Például lehetséges a COUNT(Utolso_fiz_emeles) kifejezésben az Utolso_fiz_emeles argumentum annyiban befolyásolja az eredményt, hogy a csoportba tartozó sorok közül csak azok számlálódnak meg, amelyekben az


120

Utolso_fiz_emeles nem üres. A COUNT(* ) úgy mőködik, mintha a * helyén az összes oszlopot felsoroltuk volna, azaz a csoporton belül megszámolja az összes olyan sort, amelyben legalább egyik oszlop nem üres, tehát végeredményben a csoport összes sorát számításba veszi, hiszen az összes oszlop között biztosan van kötelezıen kitöltendı – azaz nem üres – oszlop.

2. megjegyzés a legutóbbi példához: Ebben a SELECT parancsban a mit mellett látható a hova egység is.

Mit (a kért érték hivatkozás oszlopnévvel vagy

kifejezéssel)

Hova (annak az oszlopnak a fejcíme, amelyben a

képernyın a kért érték látszani fog) Osztalykod Osztály

COUNT(*) Alkalmazottak száma

3. megjegyzés a legutóbbi példához: Ha egy SELECT parancsban alkalmaztuk a GROUP BY záradékot, a SELECT kulcsszó után mit szerepben tisztán csak olyan oszlopok nevei állhatnak, amelyek a GROUP BY záradékban is szerepelnek. Például nem megengedett a

SELECT Osztalykod AS [Osztály], COUNT(*) AS [Alkalmazottak száma], Fizetes AS [Fizetés] FROM Alkalmazott GROUP BY Osztalykod ORDER BY COUNT(*) DESC, Osztalykod ASC

parancs, mert a GROUP BY záradékban nem szerepel a Fizetes . Viszont a következı parancs már hibátlan:

SELECT Osztalykod AS [Osztály], COUNT(*) AS [Alkalmazottak száma], AVG(Fizetes) AS [Fizetés] FROM Alkalmazott GROUP BY Osztalykod ORDER BY COUNT(*) DESC, Osztalykod ASC.

Ugyanis itt a Fizetes oszlop nem „tisztán”, hanem az átlagot képezı AVG( ) függvény argumentumában áll.

Osztály Nık átlagfizetése


Mekkora a nık átlagfizetése az egyes osztályokon? A kimenetet a 3.13. táblázat szerinti formában kell elıállítani. Csak azok az osztályok érdekelnek minket, amelyeknél a nık átlagfizetése 200.000 Ft felett van.

SELECT Osztalykod AS [Osztály], AVG(Fizetés) AS [N ık átlagfizetése] FROM Alkalmazott WHERE Neme=’N’ /* Feltételezük, hogy n ık kódja ’N’. */ GROUP BY Osztalykod HAVING AVG(Fizetés) > 200000;

Mint a fenti megoldás mutatja, csoportosítás esetén a HAVING csoportfeltétel is alkalmazható, ami a „sima” WHERE feltétellel ellentétben csak az aggregálás után értékel-hetı ki, azaz nem az alapadatsorok, hanem a kapott csoportok (aggregátumsorok) halmazát szőkíti. A legutóbbi két példában látott COUNT() és AVG() aggregáló függvényeken kívül


121

gyakran használatosak még: SUM(kifejezés) – összegzés, MIN(kifejezés) – minimális érték, MAX( kifejezés) – maximális érték.

3.4.3 Összetettebb feladatok megoldása SQL-ben

Ebben a szakaszban kerítünk sort olyan összetettebb feladatok tárgyalására, amelyek más SQL parancsokba beágyazott SELECT parancsokat (al-SELECT-eket), JOIN mőveleteket, virtuális táblákat (view-kat), bonyolultabb logikai mőveleteket, illetve halmazmőveleteket igényelnek; vagy a megoldásukhoz azonos forrást több szerepben is fel kell használni.

Beágyazott SELECT parancsok (al-SELECT-ek)

Itt ismételten megoldjuk a 3.4.2. szakasz legutolsó feladatát, de ezúttal úgy, hogy a le-kérdezés forrása a FROM záradékba beágyazott al-SELECT lesz.

Mekkora a nık átlagfizetése az egyes osztályokon? A kimenetet a 3.13. táblázat szerinti formában kell elıállítani. Csak azok az osztályok érdekelnek minket, amelyeknél a nık átlagfizetése 200.000 Ft felett van.

SELECT * FROM ( SELECT Osztalykod AS [Osztály], AVG(Fizetes) AS [N ık átlagfizetése] FROM Alkalmazott WHERE Neme='N' GROUP BY Osztalykod ) WHERE [Nık átlagfizetése] > 200000;

A fenti megoldás mőködését úgy kell elképzelni, hogy a belsı SELECT eredményébıl létrejön egy ideiglenes – csak a külsı SELECT végrehajtási ideje alatt élı – munkatábla Osztály és [N ık átlagfizetése] nevő oszlopokkal, és a külsı SELECT-nek ez lesz a forrása. Mivel a külsı SELECT már nem sorcsoportokat dolgoz fel, hanem az említett munkatábla sorait egyenként, benne a HAVING [N ık átlagfizetése] > 200000 feltétel helyett WHERE [Nık átlagfizetése] > 200000 feltételnek kell állni.

SELECT parancsot nem csak a FROM záradékba lehet beágyazni, amint azt a következı példában látni fogjuk.

Osztály Törzsszám Név Fizetés


Minden osztályról listáztassuk azon dolgozók törzsszámát, nevét és fizetését, akiknek a fizetése magasabb az osztályuk átlagfizetésénél! A kimenetet a 3.14. táblázat szerinti formában kell elıállítani. A kimenet sorai az Osztalykod szerint növı, azon belül a Fizetes szerint csökkenı (nem növı) sorrendben jelenjenek meg!

SELECT A.Osztalykod AS [Osztály], A.Torzsszam AS [T örzsszám], A.Nev AS [Név], A.Fizetes AS [Fizetés] FROM Alkalmazott AS A WHERE A.Fizetes > ( SELECT AVG(B.Fizetés) FROM Alkalmazott AS B WHERE B.Osztalykod = A.Osztalyk od ) ORDER BY A.Osztalykod ASC, A.Fizetes DESC


122

A fenti megoldás az eddigiekhez képest több újdonságot is mutat: Itt történetesen a külsı SELECT WHERE feltételébe ágyaztuk be a soron lévı alkalmazott osztályához tartozó átlag-fizetést kiszámító SELECT parancsot. A másik újdonság, hogy egy lekérdezés azonos táblát több szerepben is használ. Itt az Alkalmazott táblát egyik szerepben a külsı SELECT, a másik szerepben pedig a belsı SELECT használta, ráadásul a belsı SELECT az Alkal-mazott tábla elsı szerepe szerint aktuális sorából vett Osztalykod értékére és a második szerepe szerint aktuális sorából vett Osztalykod értékére is hivatkozik. – Mint az látható, azonos tábla két szerepe csak másodnevekkel (itt A és B) különböztethetı meg.

Források összekapcsolása (INNER JOIN, LEFT JOIN, RIGHT JOIN)

Az adatforrások összekapcsolásának legegyszerőbb módja, hogy a FROM záradékban több forrást sorolunk fel, és az összekapcsolásuk módját a WHERE záradékban adjuk meg, mint a következı példában.

Iktatószám Készítı neve


Iratok kilistázása a készítı ügyintézı nevével együtt: Vegyük a 3.3.1. szakaszban definiált Irat táblát, és listáztassuk ki az Ugyszam = 324 azonosítójú ügyhöz készített összes kimenı iratot a készí-tı ügyintézı nevével együtt. A kimenetet a 3.15. táblázat szerinti formában kell elıállítani.

Elsı megoldás: SELECT Iktatoszam AS [Iktatószám], Nev AS [Készít ı neve] FROM Irat, Alkalmazott WHERE Ugyszam = 324 AND Keszitette_torzsszam = Torzsszam

A példa fenti megoldásában a WHERE záradékban a Keszitette_torzsszam = Torzsszam

feltétel adja meg, hogy minden Irat -sorhoz azt az az Alkalmazott -sort kell kapcsolni, amelyben Torzsszam értéke egyenlı az Irat -sorban lévı Keszitette_torzsszam értékével.

Az adatforrások összekapcsolására, valamivel több lehetıséget ad a források közötti JOIN mővelet valamelyik változatának alkalmazása. Az elıbbi példa elıbbi megoldásával egyen-értékő az alábbi – az Irat és az Alkalmazott közötti INNER JOIN mővelettel operáló – második megoldás.

Második megoldás (példa JOIN-kifejezésre, történetesen az INNER JOIN összekapcsolásra): SELECT Iktatoszam AS [Iktatószám], Nev AS [Készít ı neve] FROM Irat INNER JOIN Alkalmazott ON Keszitette_torzsszam = Torzsszam WHERE Ugyszam = 324

A második megoldásban a kapcsolófeltétel a WHERE záradék helyett a JOIN mővelet ré-sze lett (annak ON záradékába ment át).

A táblakapcsolások esetén (beleértve a több forrás JOIN mővelet nélküli felsorolásának esetét is) a háttérben rejtetten mindig létrejön egy munkatábla, és tulajdonképpen az a lekérdezés közvetlen forrása. A JOIN mővelet három esetére e munkatábla képzési szabályait a 3.16. és a 3.17. ábrák mutatják be.


123

T1 T2 T1 INNER JOIN T2 ON T1.B = T2.B

A B B C T1.A T1.B T2.B T2.C

a1 b9 b1 c3 a3 b1 b1 c3

a3 b1 b2 c2 a4 b2 b2 c2

a4 b2 b3 c5 a7 b1 b1 c3

a7 b1 b4 c1 a8 b1 b1 c3

a8 b1

a9 b9

3.16. ábra: A T1 és a T2 források és azok INNER JOIN-jaként elıállt munkatábla

T1 LEFT JOIN T2 ON T1.B = T2.B T1 RIGHT JOIN T2 ON T1.B = T2.B

T1.A T1.B T2.B T2.C T1.A T1.B T2.B T2.C

a1 b9 --- --- a3 b1 b1 c3

a3 b1 b1 c3 a4 b2 b2 c2

a4 b2 b2 c2 a7 b1 b1 c3

a7 b1 b1 c3 a8 b1 b1 c3

a8 b1 b1 c3 --- --- b3 c5

a9 b9 --- --- --- --- b4 c1

3.17. ábra: A T1 és a T2 források LEFT JOIN-ja, illetve RIGHT JOIN-ja

A T1 és T2 források INNER JOIN-jaként létrejövı munkatábla a 3.16. ábrán látható. Ebbıl kitőnik, hogy az INNER JOIN kimenetében az ON feltétel szerint párosítható T1-, T2-sorok összekapcsolásai szerepelnek.

A T1 és T2 források LEFT JOIN-jaként létrejövı munkatáblában (a 3.17. ábrán bal oldalt) az INNER JOIN-nal elıállított sorokon felül a T1 forrás azon sorai is szerepelnek, amelyeknek nincs – az ON feltételt kielégítı – párja a T2 forrásban. A munkatábla ilyen soraiban a T2-bıl származó oszlopok üresek (NULL értékőek).

A T1 és T2 források RIGHT JOIN-jaként létrejövı munkatáblában (a 3.17. ábrán jobb oldalt) az INNER JOIN-nal elıállított sorokon felül a T2 forrás azon sorai is szerepelnek, amelyeknek nincs – az ON feltételt kielégítı – párja a T1 forrásban. A munkatábla ilyen soraiban a T1-bıl származó oszlopok üresek (NULL értékőek).

Azon ügyintézık kilistázása, akik még nem készítettek iratot: Kihasználjuk a RIGHT JOIN-nal elıállított munkatábla tulajdonságait.

SELECT Nev AS [Még nem készített iratot] FROM Irat RIGHT JOIN Alkalmazott ON Keszitette_torzsszam = Torzsszam WHERE Iktatoszam IS NULL

A fenti a megoldás magyarázata: Azok az alkalmazottak nem készítettek még iratot, amelyek adatsorának nincs a Keszitette_torzsszam = Torzsszam feltételt kielégí-tı párja az Irat táblában. – A lekérdezés közvetlen forrását képezı munkatábla a RIGHT JOIN miatt az Alkalmazott tábla minden sorát tartalmazza, azokat is, amelyeknek nincs párja az Irat táblában, és a munkatábla ezen sorai arról ismerhetık fel, hogy benne az


124

Irat ból származó oszlopok (így az Iktatoszam oszlop is) üres (azaz NULL értékő). Tehát az Iktatoszam IS NULL feltétel éppen ezeket választja ki.

Logikai értéket elıállító halmazmőveletek az SQL-ben

A bonyolultabb lekérdezések (vagy más SQL parancsok) WHERE záradékában nagyon hasznosak lehetnek azok az SQL-ben is alkalmazható halmazmőveletek, amelyek a halmaz tartalmától függıen igaz / hamis logikai értéket állítanak elı:

Halmazmővelet Magyarázat x IN (halmaz) Igaz értéket ad vissza, ha az x eleme a halmaznak. x NOT IN (halmaz) Igaz értéket ad vissza, ha az x NEM eleme a halmaznak. x = | != | < | > | <= |>= ANY (halmaz)

Igaz értéket ad vissza, ha az x és a halmaz valamely eleme között teljesül az adott hasonlítási reláció. Az x = ANY (halmaz) alak egyenértékő az x IN (halmaz) mővelettel. A NOT(x = ANY(halmaz)) alak egyenértékő az x NOT IN (halmaz) mővelettel. Figyelem! Az x != ANY (halmaz) alak nem egyenértékő a NOT(x = ANY(halmaz)) alakkal.

x = | != | < | > | <= |>= ALL (halmaz)

Igaz értéket ad vissza, ha az x és a halmaz minden eleme között teljesül az adott hasonlítási reláció. Az x != ALL (halmaz) alak egyenértékő az x NOT IN (halmaz) mővelettel, illetve a NOT(x = ANY(halmaz)) mővelettel; . viszont NEM egyenértékő a NOT( x = ALL (halmaz)) alakkal. A NOT( x = ALL (halmaz)) alak egyenértékő az x != ANY(halmaz)) alakkal.

EXISTS (halmaz) Igaz, ha a halmaznak van legalább egy eleme. NOT EXISTS (halmaz)

Igaz, ha a halmaz üres.

Az ANY és az ALL mőveletek sablonjában a | jel alternatívan választható lehetıségeket határol el egymástól. A != a „nem egyenlı” hasonlító mővelet jele, az Accessben helyette a <> jel alkalmazható.

Az elıbbi táblázatban adott halmazmőveletek argumentuma beágyazott SELECT pa-ranccsal elıállított halmaz is lehet. Ennek felhasználásával legutolsó lekérdezési feladatra itt további három megoldást adunk.

Azon ügyintézık kilistázása, akik még nem készítettek iratot: Kihasználjuk a NOT EXISTS halmazmővelet tulajdonságait.

SELECT Nev AS [Még nem készített iratot] FROM Alkalmazott WHERE NOT EXIST ( SELECT * FROM Irat WHERE Keszitette_torzsszam = Torz sszam )

Azon ügyintézık kilistázása, akik még nem készítettek iratot: Kihasználjuk a NOT IN

halmazmővelet tulajdonságait.

SELECT Nev AS [Még nem készített iratot] FROM Alkalmazott WHERE Torzsszam NOT IN ( SELECT Keszitette_torzssza m FROM Irat )


125

Azon ügyintézık kilistázása, akik még nem készítettek iratot: Kihasználjuk a != ALL halmazmő-velet tulajdonságait.

SELECT Nev AS [Még nem készített iratot] FROM Alkalmazott WHERE Torzsszam <> ALL ( SELECT Keszitette_torzssza m FROM Irat )

Megjegyzés: Az Accesstıl különbözı környezetben a Torzsszam <> ALL … rész helyett a Torzsszam != ALL … alkalmazandó.

Virtuális táblák definiálása (CREATE VIEW) és használata

A következı példa megoldásához szükség lesz a view fogalmára. A view egy virtuális tábla, ami a tényleges táblák tartalmából ideiglenesen – csak a view felhasználásának idejére – áll elı. Egy view ugyanúgy használható a SELECT parancsokban, mint a rendes táblák. A view felépítése és tartalma a CREATE VIEW paranccsal specifikálható:

CREATE VIEW view neve (oszlopnév [, oszlopnév] …) AS elıállító SELECT parancs

View-k használatával megkönnyíthetı a bonyolultabb lekérdezések parancsának megírá-sa, illetve a view-val elıkészített lekérdezések általában hatékonyabban (rövidebb válasz-idıvel) hajtódnak végre.

A legtöbb kimenı iratot készítı ügyintézık közül ki kel íratni az elsı 5 helyezettet. A kimenetet a 3.18. táblázat szerinti formában kell elıállítani. A kimeneti sorok rendezettek legyenek a készített ira-tok darabszáma szerint csökkenı (nem növı) sorrendben!

Ezt a feladatot két lépésben oldjuk meg. Elıbb definiálunk egy olyan Teljesitmeny view-t, amelynek felépítését a 3.19. táblázat mutatja: A Teljesitmeny ben az összes ügyintézı megjelenik, aki legalább egy iratot készített, nemcsak az elsı 5 helyezett. A második lépésben ebbıl a view-ból állapítjuk meg az elsı 5 helyezettet. A második lépés SELECT parancsa kétféle szerepben is hasz-nálja a Teljesitmeny view-t. A külsı SELECT végigmegy a view-ban lévı összes ügyintézın, a bel-sı SELECT pedig azt vizsgálja, hogy hány olyan alkalmazott van, aki több iratot készített, mint a külsı SELECT-ben soron levı ügyintézı. (A megoldás tekintettel van a holtversenyre, amely szerint akár 10 alkalmazott is beletartozhat az elsı 5 helyezettbe.)

CREATE VIEW Teljesitmeny (Keszitette_torzsszam, "Készített iratok darabszáma ") AS SELECT Keszitette_torzsszam, COUNT(*) FROM Irat WHERE Bejovo_kimeno = ’KI’ GROUP BY Keszitette_torzsszam; SELECT Nev AS "Készít ı neve", T1."Készített iratok darabszáma" FROM Teljesitmeny AS T1, Alkalmazott WHERE Keszitette_torzsszam = Torzsszam AND 5 > ( SELECT COUNT(*) FROM Teljesitmeny AS T2 WHERE T2."Készített iratok darabszáma" > T1."Készített iratok darabszáma" ) ORDER BY T1."Készített iratok darabszáma" DESC;

Készítı neve Készített iratok darabszáma

3.18. táblázat: A fenti lekérdezési példa kimenete


126

Keszitette_torzsszam Készített iratok darabszáma

3.19. táblázat: A lekérdezési példában használt Teljesitmeny view kimenete

Az Access nem támogatja a view alkalmazását, ezért az elıbbi feladat megoldásában nem is az Access, hanem az SQL99 szabvány formai szabályait követtük az olyan több szóból álló adatnevek esetében, mint a "Készített iratok darabszáma" . (Az Accessben ugyan-ennek így kell kinézni: [Készített iratok darabszáma] .) Az Access a view-t azzal helyettesíti, hogy megengedi, a lekérdezés forrása egy másik lekérdezés eredménye legyen, azaz az Accessben a SELECT parancs FROM záradékában nem csak táblák nevére, hanem elızetesen definiált lekérdezések nevére is lehet hivatkozni. – Ez lényegében egyenértékő a view használatával. Tehát Accessben a fenti példa megoldása sem próbálható ki, de ahhoz nagyon közelálló megoldás adható; íme:

Az elıbbi feladat megoldásának Accessben is mőködı változata:

Elsı lépésben definiálni kell egy lekérdezést, amely lényegében az elıbbi megoldás view-jának felel meg:

SELECT Keszitette_torzsszam, COUNT(*) AS [Készített iratok darabszáma] FROM Irat WHERE Bejovo_kimeno = ’KI’ GROUP BY Keszitette_torzsszam;

Ha ezt a lekérdezést Teljesitmeny névvel elmentjük, akkor az az Accessben ugyanúgy hasz-nálható, mint más adatbáziskezelık esetében a view. Tehát a megoldás második fele (a helyezési sorrendet elıállító SELECT parancs) csaknem változatlan: csak a "Készít ı neve" , és a "Készített iratok darabszáma" neveket kell a [Készít ı neve] , és a [Készített iratok darabszáma] alakokra lecserélni.

Azonos szintő SELECT parancsok összekapcsolása (UNION, INTERSECT és MINUS)

Eddig két példát láttunk olyan összetett SELECT parancsra, amely valamely részébe beágyazott másik SELECT parancsot tartalmaz. Azonban összetett lekérdezések nemcsak beágyazással, hanem azonos szintő SELECT parancsok (pontosabban azok kimenetei) UNION (egyesítés), INTERSECT (metszet) vagy MINUS (különbség) mőveletekkel való összekapcsolásával is lehetséges.

Törzsszám Név

3.20. táblázat: Kimeneti forma a következı három példához

Példa az UNION halmazmőveletre: Az összes olyan ügyintézı lekérdezése, aki vagy intézkedett egy bejövı irattal kapcsolatban, vagy készített egy kimenı iratot.

SELECT DISTINCT U.Intezkedo_torzsszam AS Törzsszám, A.Nev AS Név FROM Alkalmazott AS A, Irat AS U WHERE U.Intezkedo_torzsszam = A.Torzsszam UNION SELECT DISTINCT U.Keszitette_torzsszam AS Törzsszám , A.Nev AS Név FROM Alkalmazott AS A, Irat AS U WHERE U.Keszitette_torzsszam = A.Torzsszam; ORDER BY Törzsszám


127

Példa az INTERSECT halmazmőveletre: Az összes olyan ügyintézı lekérdezése, aki mindkét említett tevékenységet végezte már valamelyik irattal.

SELECT DISTINCT U.Intezkedo_torzsszam AS "Törzsszám ", A.Nev AS "Név" FROM Alkalmazott AS A, Irat AS U WHERE U.Intezkedo_torzsszam = A.Torzsszam INTERSECT SELECT DISTINCT U.Keszitette_torzsszam AS "Törzsszá m", A.Nev AS "Név" FROM Alkalmazott AS A, Irat AS U WHERE U.Keszitette_torzsszam = A.Torzsszam; ORDER BY "Törzsszám"

Példa a MINUS halmazmőveletre: Az összes olyan ügyintézı lekérdezése, aki intézkedett már

egy bejövı irattal kapcsolatban, de még nem készített kimenı iratot.

SELECT DISTINCT U.Intezkedo_torzsszam AS "Törzsszám ", A.Nev AS "Név" FROM Alkalmazott AS A, Irat AS U WHERE U.Intezkedo_torzsszam = A.Torzsszam MINUS SELECT DISTINCT U.Keszitette_torzsszam AS "Törzsszá m", A.Nev AS "Név" FROM Alkalmazott AS A, Irat AS U WHERE U.Keszitette_torzsszam = A.Torzsszam; ORDER BY "Törzsszám"

Megjegyzés: Az Access az INTERSECT és a MINUS mőveleteket nem támogatja, így abban csak az UNION mővelet próbálható ki. Ez az oka annak is, hogy az utóbbi két a Törzsszám és a Név adatnevek "Törzsszám" és "Név" alakban állnak, ugyanis az Accesstıl különbözı környezetekben az angol ábécén kívüli ékezetes betőket tartalmazó adatneveket ugyanúgy "" zárójelek közé kell tenni, mint a több szóból álló adatneveket.

Más parancsokba beágyazott SELECT parancsok

A SELECT parancs beágyazható a DELETE vagy az UPDATE parancsok WHERE záradékába is, továbbá az INSERT parancsnak van egy olyan változata, amely a céltáblába beírandó sorokat SELECT mővelettel egy másik táblából veszi:

INSERT INTO táblanév [ [AS] másodnév] [(oszlopnév [, oszlopnév ] … )] forrássorokat elıállító SELECT parancs

INSERT parancsba beágyazott SELECT parancs: Az Alkalmazott táblába írjunk be új sorokat, melyeket Belepo táblából veszünk. (Feltételezzük, hogy a Belepo tábla szerkezete azonos az Alkalmazott tábláéval.)

INSERT INTO Alkalmazott SELECT * FROM Belepo

Az UPDATE parancs hasonló változatában az új értékek vagy a módosítási feltételek a beágyazott SELECT mővelettel egy másik táblából vehetık:

UPDATE aktualizált tábla neve [ [AS] másodnév1] SET oszlopnév1 = ( SELECT … FROM forrás tábla neve [ [AS] másodnév2] WHERE feltétel1 ) WHERE feltétel2


128

UPDATE parancsba beágyazott SELECT parancs: Az Alkalmazott táblában azok fizetése módosul, akiknek van adatsoruk az Ujfizetes táblában. (Feltételezzük, hogy az Ujfizetes tábla a Torzsszam és a Fizetes oszlopokat tartalmazza.)

UPDATE Alkalmazott A SET Fizetes = (SELECT UF.Fizetes FROM Ujfizetes UF WHERE A.Torzsszam = UF.Torzsszam)

Megjegyzés: Az ACCESS az UPDATE parancsnak ezt a változatát nem támogatja, abban nem próbálható ki.

3.4.4 Ellenırzı feladatok a 3.4. alfejezethez

A következı feladatok megoldásához az alábbi szerkezető egyedtípusokat (táblákat) kell felhasználni.

SZÁMLATÜKÖR (Számlatükörkód , Fkvi_számlaszám, Szla_érvkezd, Szla_érvvége, Számlanév, Számlatípuskód, Gyüj t ıszint) FKVISZLA_FORGALOM (Tételsorszám , Id ıszakkód, Számlatükörkód, Számlaoldal, Összeg, Bizonylatkód) BIZONYLAT ( Bizonylatkód , Tranzakció_megnevezés, Könyvelésdátum, Bizonylatszám) SZÁMLAOLDAL_ELİJEL ( Számlatípuskód + Számlaoldal , El ıjel)

Megjegyzés: Az El ıjel értékei 1 és –1. GYŐJTİLEÍRÓ ( Győjt ıszámla_kód + Alszámla_kód + Gyüjt ıhöz_érvkezd, Gyüjt ıhöz_érvvége)

Megjegyzés: A Győjt ıszámla_kód és az Alszámla_kód szerepnevei a Számlatükörkód nak. A Gyüjt ıhöz_érvvége üres is lehet.

1. Pótolja az alábbi CREATE VIEW parancs hiányzó részeit úgy, hogy az eredménye tar-talmazza a megfelelı Könyvelésdátum és Fkvi_számlaszám oszlopokat is, továbbá a Számlaoldal és az Összeg helyett a megfelelı elıjellel ellátott El ıjeles_összeg álljon benne. A megfelelı elıjelet a SZÁMLAOLDAL_ELİJEL tartalma alapján lehet meg-állapítani.

CREATE VIEW " Kiegészített_el ıjeles_forgalom " ( " Tételsorszám " , " Id ıszakkód " , " Számlatükörkód " , " El ıjeles_összeg " , " Bizonylatkód " , " Könyvelésdátum " , " Fkvi_számlaszám " ) AS SELECT " Tételsorszám " , " Id ıszakkód " , " Számlatükörkód " , ___________________, F. " Bizonylatkód " , " Könyvelésdátum " , " Fkvi_számlaszám " ) FROM FKVISZLA_FORGALOM F, " SZÁMLATÜKÖR" S, BIZONYLAT B,

______________________________ E

WHERE S.________________________ = F.______________ ___________

AND E.________________________ = S.______________ ___________

AND E.________________________ = F.______________ ___________

AND B.________________________ = F.______________ ___________


129

Megjegyzés: Ez a parancs az Accessben nem próbálható ki. Ez magyarázza például a Tételsorszám adatnév helyett a "Tételsorszám" alakú adatnevet is. – Az olva-sóra bízzuk, hogy az ezen feladat és a következı feladatok Accessben való kipróbálha-tósága érdekében milyen lekérdezéssel helyettesíti a fenti view-t.

2. Az elızı alfeladatban adott Kiegészített_el ıjeles_forgalom view felhasználásá-val írja meg a számlaosztály-egyenlegek lekérdezését egy adott (mérleg)idıszakra vonat-kozóan (Id ıszakkód = [Adott id ıszak] ). Kimenet:

Számlaosztály Egyenleg

SELECT ______________________________ AS Számlaoszt ály,

______________________________ AS Egyenleg

FROM __________________________________________

WHERE __________________________________________

_________________________________________________

3. Pótolja az alábbi SELECT parancs hiányzó részeit úgy, hogy annak eredménye a győjtıszámlák egyenlegeinek egy adott (mérleg)idıszakra vonatkozó (Id ıszakkód = [Adott id ıszak] ) listája legyen! A lekérdezés az 1. feladatban adott Kiegészí-

tett_el ıjeles_forgalom view felhasználásával történjen! A győjtési szabályokat (adott érvényességi intervallummal melyik győjtıszámlára mely alszámlákról kell egyen-legezni) a GYŐJTİLEÍRÓ tábla tartalmazza. Adott Kiegészített_el ıjeles_forga-

lom -sorra olyan szabálysorok érvényesek, amelyek Könyvelésdátum a a szabály érvé-nyességi intervallumába esik. Kimenet:

Győjt ıszámla száma Egyenleg

SELECT ______________________________ AS [Gy őjt ıszámla száma],

______________________________ AS Egyenleg

FROM GYŐJTİLEÍRÓ G, __________________________________ F,

_________________________________ S

WHERE F.Id ıszakkód = Adott_id ıszakód

AND S.________________________ = G._____________ ___________

AND F.________________________ = G._____________ ___________

AND Gy őjt ıhöz_érvkezd <= F.____________________________

AND ( F.__________________________ <= Gy őjt ıhöz_érvvége

OR __________________________________________ ___ )

___________________________________________________ ___________

4. Hol és hogyan változik az elızı alfeladat megoldása, ha a Gyüjt ıhöz_érvvége mindig ki van töltve úgy, hogy azon (érvényes) sorokban, amelyeknél az érvényesség vége még nem ismert, nagyon nagy dátumot (pl. 4000.12.31.) tartalmaz?


130

3.5 Adatkezelés az Access grafikus felületén

3.5.1 Adatok bevitele, törlése és módosítása a graf ikus felületen

A párbeszédes adatbáziskezelı felületeknek – mint az Access grafikus felületének – az a legfıbb elınye, hogy azok is tudják használni, akik nem akarják vagy nem tudják megtanulni az SQL-t. Azonban az egész 3. fejezet az Accesst csak olyan könnyen hozzáférhetı segédesz-köznek tekinti, amely lehetıséget ad az SQL kipróbálására. Így ez a szakasz is csak olyan mértékben foglalkozik az Access grafikus felületén való adatkezelés ismertetésével, amennyi ahhoz szükséges, hogy az olvasó könnyebben feltölthesse megfelelı adatokkal az SQL parancsok kipróbálásához szükséges táblákat.

Bármely tábla megnyitható a táblaböngészıbıl többféle módon is, így például a tábla kijelölése utána a Megnyitás gombra kattintással (lásd a 3.21. ábrán).

3.21. ábra: A Bizonylat tábla megnyitása a táblaböngészıbıl

Egy táblába új sort a tábla végén (utolsó sorként) lehet bevinni. (Lásd egy új bizonylatsor bevitelét a Bizonylat táblába a 3.22. ábrán.) Ha a tábladefinícióban adott szabályok nem tiltják, akkor bármely táblasorra kattintva annak adattartalma módosítható (átírható), illetve a törlı gombra kattintással a sor eltávolítható a táblából.

A 3.23. ábrán arra is példát látunk, hogy a Bizonylat táblában is kezdeményezhetı egy bizonylathoz tartozó forgalomtételek rögzítése az Fkviszla_forg táblába.


131

3.22. ábra: Új sor rögzítése a Bizonylat táblába

3.23. ábra: A 25-ös kódú bizonylathoz új tétel rögzítése az Fkviszla_forg táblába

Törlı gomb.

Az éppen létrehozott vagy szerkesztés alatt lévı sor jelzése.

Az éppen létreho-zott bizonylat.

Az új bizonylathoz új tétel létrehozása.

Legördülı választéklista a tétel számlatükörkódjá-nak (közvetve a fıkönyvi számlaszámának) kivá-lasztása céljából.

A bizonylathoz tartozó tételeket megnyitó, illetve bezáró gomb


132

3.5.2 Adatok lekérdezése a grafikus felületen

Ez a szakasz is olyanoknak szól, akiknek az SQL megtanulása gondot okoz, illetve egyszerőbb lekérdezéseket kevesebb munkával szeretnének megoldani, mint amennyire SQL alkalmazásával szükség lehet. – A teljesség igénye nélkül néhány példa megoldásával csupán ízelítıt adunk az Access grafikus lekérdezésdefiniáló felületének használatáról. Emlékezte-tünk rá, hogy egy új lekérdezés létrehozásának kezdeményezése a 3.2.2. szakaszban leírt és a 3.1. ábrán mutatott módon történhet. (Amúgy még ezen az úton is lehet valamennyire SQL-t tanulni: A felhasználó a grafikus felületen definiált lekérdezést megnézheti az SQL nézetben is, így utólag megtudhatja, hogy az adott feladatot SQL-ben hogyan kellett volna megoldani.)

Mindegyik példa a 3.3.2. szakaszban a 3.9. ábrán mutatott táblák valamelyikére (esetleg több tábla együttesére) vonatkozik.

3.24. ábra: A Szamlatukor felépítése

Az itt következı elsı feladatban a Szamlatukor táblát használjuk forrásként. Ebben az Fkviszla_szam jelenti a fıkönyvi számlaszámot, a Szamla_ervkezd jelenti a Szamlatukor-sor érvényességének kezdetét, a Szamla_ervvege jelenti a Szamlatukor-sor érvényes-ségének végét. (A még érvényes sorok érvényességé-nek igazi vége általában még ismeretlen. Ilyenkor egy nagyon nagy dátum, 4000.12.31. áll a Szamla_ervvege mezıben.)

A számlaosztályt a fıkönyvi számlaszám elsı számjegye mutatja. Ki fogjuk használni azt a tényt is, hogy a hogy a fıkönyvi számlaszám (bár számjegyekbıl áll) mégis szöveg adat-típusú.

1. feladat:

A Szamlatukor táblából kérdezze le a 4-es számlaosztályba tartozó fıkönyvi számlaszámok közül azokat, amelyek 2008.02.06-án érvényesek! A kimeneten fıkönyvi számlaszámokat a Szam-latukor táblában jellemzı összes oszlop jelenjen meg.

Most a lekérdezés létrehozásának kezdeményezésekor 3.2.2. szakasz 3.2. ábra szerinti Tábla megjelenítése ablakban hozzáadásra ki kell választani a Szamlatukor táblát.

3.25. ábra: Az 1. feladat 1. megoldása

Magyarázat az 1. megoldáshoz: Az 1. oszlopban azt adtuk meg, hogy a kimeneten a Szamlatukor -sor minden oszlopa jelenjen meg (Szamlatukor. * és pipa a jelölı négyzetben). A további három oszlopban nincs bekapcsolva a megjelenítés, tehát ezek csak feltételeket definiálnak. A második oszlop Fkviszla_szam Like '4 * ' feltételének értelme: azokat a számlaszámokat keressük, amelyek 4-essel kezdıdnek. (Itt használtuk ki,


133

hogy a fıkönyvi számlaszám szöveg típusú adat, mert a Like mővelet csak szöveg adat-típusra alkalmazható.) A 3. és a 4. oszlopkban lévı feltételek:

Szamla_ervkezd <=#2008.02.06.# , illetve Szamla_ervvege >=#2008.02.06.#

A három feltétel egymással logikai ÉS (AND) kapcsolatban áll, azaz a lekérdezés azokat a sorokat találja meg, amelyekre mindhárom feltétel egyidejőleg teljesül.

3.26. ábra: Az 1. feladat 2. megoldása

Magyarázat az 2. megoldáshoz: Ez a megoldás csak a 2. oszlopban különbözik az elıbbitıl, ezért csak az igényel magyarázatot. A Left([Fkviszla_szam];1) egy olyan függvénykifejezés, amely az Fkviszla_szam baloldali elsı karakterét (elsı számjegyét) adja vissza. (Ez a függvény is csak szöveg adattípusra alkalmazható.) Végeredményben a második oszlop a Left([Fkviszla_szam];1) = '4' feltételt tartalmazza, amelyet azok a fıkönyvi számlaszámok elégítenek ki, amelyeknek elsı számjegye 4-es. (A második oszlopba a Kif1: szöveget az Access automatikusan írta be, a felhasználónak ezzel nincs dolga. Az Access automatikusan Kif1: , Kif2: , … címkéket tesz a Mezı sorban azokba az oszlopokba, ahol nem egyszerően mezınév, hanem valamilyen kifejezés áll, és a felhasználó nem tett saját címkét.)

Megjegyzések:

• A Left ( mezınév; hossz) függvény csak az Access SQL nyelvjárásában használ-ható, más SQL nyelvjárásokban a Substring ( mezınév, kezdıpozíció, hossz) vagy Substr ( mezınév, kezdıpozíció, hossz) alakú függvény használatos helyette.

• A dátum típusú adatkonstans csak az Access grafikus felületén #eeee.hh.nn.# alakú, az Access SQL szerkesztı felületén már a #hh/nn/eeee# alakot kell alkalmazni. Más SQL nyelvjárásokban a dátum típusú adatkonstans nem ## jelek között, hanem '' jelek (aposztrófok) között áll, pl. '2008.02.06', illetve a felépítése a nemzeti sajátosságoknak megfelelıen rugalmasan választható meg.

2. feladat:

A Számlatükör táblából kérdezze le azokat a Szamlatukor -sorokat, amelyekben értelmezett fıkönyvi számlaszámokra történt könyvelés 2007.11.20-án! A kimeneten a fıkönyvi számlaszám (Fkviszla_szam ), és a számla megnevezése (Szamla_megnevezes ) oszlopok jelenjenek meg. Gondoskodjon arról, hogy egy Szamla-tukor -sor csak egyszer jelenjen meg a kimeneten akkor is, ha az abban definiált fıkönyvi számla-számra több tétel lett könyvelve az említett napon!

Most a lekérdezés definíciójához a 3.27. ábra szerinti három táblát kell hozzáadni. Bár most is Szamlatukor -sorokat keresünk, nem egyedül ez a tábla képezi a lekérdezés forrását. Ugyanis annak eldöntéséhez, hogy mely számlaszámokra történt könyvelés, szükség van a könyvelt forgalomtételeket tartalmazó Fkviszla_forg táblára is. Sıt, ez is kevés, mert az, hogy mely forgalomtételeket könyvelték 2007.11.20-án, a tételekbıl nem derül ki, ugyanis csak a Bizonylatkod dal a tételhez kapcsolt Bizonylat tábla tartalmazza a Konyvelesdatum ot.


134

3.27. ábra: A 2. feladat által használt táblák

3.28. ábra: A 2. feladat nem tökéletes megoldása

3.29. ábra: A 2. feladat szerinti lekérdezés kimenete a megoldás javítása elıtt

A 3.29. ábrán látható kimenet azt mutatja, hogy a 3.28. ábrán adott megoldás nem töké-letes, mert a 384-es fıkönyvi számlaszám duplán jelenik meg benne. Az SQL SELECT parancsában ilyen kimeneten javít a DISTINCT rendelkezés (lásd a 3.4.2. szakaszban). Az Access párbeszédes felületén hasonló rendelkezés a Lekérdezés tulajdonságai ablakban tehetı meg (lásd a 3.31. ábrán) az Egyedi értékek: Igen beállítással. Ez az ablak egy lekér-dezés definiálása közben a 3.30. ábrán mutatott módon hozható elı. A lekérdezésdefiníció javítása utáni kimenet a 3.32. ábrán látható.


135

3.30. ábra: A Lekérdezés tulajdonságai ablak megjelenésének kezdeményezése

3.31. ábra: A megoldás javítása: rendelkezés az ismétlıdések megszüntetésérıl

3.32. ábra: A javított megoldás kimenete

3.33. ábra: A hiányzó kapcsolatokat pótoló két kapcsolófeltétel

Igen

Tulajdonságok gomb.


136

Amikor a lekérdezés definíciójához hozzáadjuk a 3.27. ábra szerinti három táblát, akkor azok az adatbázisdefinícióban adott kapcsolataikkal (lásd a 3.3.2. szakaszban a 3.9. ábrát) együtt lesznek a lekérdezésdefiníció részei. Ez azért lényeges, mert minden ilyen kapcsolat egyenértékő egy kapcsolófeltétellel. Ha ezek a kapcsolatok nem lennének jelen a 3.27. ábra szerinti felületen, akkor azokat két további feltétellel lehetne pótolni. Ez ki is próbálható, mert az említett kapcsolatokat el lehet távolítani: a jobb egérgombbal a kapcsolatra kattintás után elıugró menübıl a Törlés parancsot kell választani. A 3.33. ábra mutatja azokat a plusz feltételeket, amelyek a hiányzó kapcsolatokat pótolják.

Megjegyzés: A Feltétel sorban a táblaneveket és a mezıneveket azért kellett szögletes zárójelek közé tenni (pl. [Bizonylat].[Bizonylatkod] ), mert ellenkezıleg ezeket az Access nem adat nevének, hanem közvetlenül (szöveg típusú) adatértéknek tekintené. A Mezı és a Tábla sorokra ez a szabály nem vonatkozik, mert ott az Access elsıdlegesen mezınevet, kimeneti oszlopnevet, illetve táblanevet (forrásnevet) feltételez. A Mezı sorban csak akkor kell [] jelek közé tenni egy mezı nevét, ha az nem magában áll, hanem egy kifejezés részét képezi, mint például a 3.26. ábra második oszlopában: Left([Fkviszla_szam];1) .

3. feladat:

Az Fkviszla_forg táblából kérdezze le a hibátlanul könyvelt tételeket; tehát azokat, amelyek utóbb sem javítva, sem törölve nem lettek!

3.34. ábra: A 3. feladat megoldása

Ez a feladat egy lényeges körülményben különbözik az elızı kettıtıl. Az 1. feladat ese-tében egy Szamlatukor-sort kiválasztó feltétel teljesülése magában a sorban foglalt adatok (Fkviszla_szam , Szamla_ervkezd , Szamla_ervvege ) eldönthetı volt. Hason-lóan a 2. feladat esetében egy bizonylat köny-velési idıpontja a Bizonylat -sorban álló Konyvelesdatum értéke. Ezzel szemben az, hogy egy forgalomtétel utóbb törlésre / javítás-ra szorult, csak más tétel(ek)bıl, a ráhivatkozó törlı tétel létezésébıl derülhet ki.

Az említett körülmény miatt a lekérdezés egyszerre használja azt a tételt, amelyikrıl el kell döntenie, hogy hibátlan-e, és a törlı téte-leket. (Ugyanis abból derül ki a tétel hibátlan volta, hogy nincs ráhivatkozó törlı tétel.) Ez úgy lehetséges, ha az Fkviszla_forg táblát két szerepben is hozzáadjuk a lekérdezés defi-níciójához.

A 3.34. ábrán a kapcsolat az Fkviszla_forg tábla szerepeit képviselı dobozok egyikéhez a Tetelsorszam nál, a másikához a TJ_tetelsorszám nál tapad, azaz a törölt tételt a TJ_tetelsorszám mal ráhivatkozó (törlı/javító) tételekkel kapcsolja össze. Az is észrevehetı, hogy a kapcsolóvonal Fkviszla_forg_1 felıli vége nyílban végzıdik. Ez a látvány az illesztéstípus 3.35. ábrán látható megválasztásának eredménye. (Az illesz-téstípus beállítása is részét képezi a lekérdezés definíciójának.)


137

3.35. ábra: A 2. illesztéstípus kiválasztása

Itt is igaz a 3.4.3. szakaszban tett megállapítás, miszerint több forrás összekapcsolása esetén olyan munkatábla lesz a lekérdezés közvetlen forrása, amely valamennyi az eredeti források mindegyikének összes oszlopát tartalmazza. Esetünkben ez a munkatábla az Fkviszla_forg tábla oszlopait duplán tartalmazza: egyszer az Fkviszla_forg szerep irányából, egyszer pedig a törlı / javító tételeket szolgáltató Fkviszla_forg_1 szerep irányából. A 2-es illesztéstípus hatása az, hogy az Fkviszla_forg szerep irányából minden tétel megjelenik az említett munkatáblában, a Fkviszla_forg_1 szerep irányából azonban csak azok a tételek, amelyeknek létezik a TJ_tetelsorszám ával hivatkozott párja. (Tehát ez az illesztéstípus lényegében az SQL-ben alkalmazható LEFT JOIN mőveletnek felel meg.) – A 3.34. ábrán látható lekérdezésdefiníció második oszlopában álló

Fkviszla_forg_1.Tetelsorszam Is Null

feltétel a munkatáblából éppen azokat az Fkviszla_forg -tételeket választja ki, amelyek, amelyekhez nem létezik a törlı / javító tétel.

3.36. ábra: A 3. feladat szerinti lekérdezés eredménye

A lekérdezés eredményét a 3.36. ábra mutatja. Ebben a 21. és 22. tételsorszámú tételek nincsenek jelen, de nem is kell jelen lenniük, hiszen a 25-28. tételek pont a 21. és 22. sorszámú tételeket törlik, illetve javítják; azaz a 21. és 22. sorszámú tételek hibásan lettek könyvelve.

Még egy példa erejéig kitérünk a forrássorok csoportjából aggregált értékek lekérdezé-sének módjára is.

Itt látszik, hogy a 21. és a 22. sor-számú tételeket utólag (a 25-28. tételek) törülték, illetve javították.


138

4. feladat:

Számlaosztályonkén kérdezze le egy adott idıszak összes tartozik oldali forgalmát! A kimenet elvárt szerkezetét a 3.37. ábra mutatja.

A számlaforgalmat az Fkviszla_forg táblából lehet összegezni. Azok a tételek tar-toznak azonos számlaosztályba, amelyek azonos számjeggyel kezdıdı számlaszámra lettek könyvelve. A fıkönyvi számlaszám azonban nincs jelen az Fkviszla_forg táblában, azt a Szamlatukor táblából kell venni. Tehát a (Szamlatukorkod dal összekapcsolt) Fkviszla_forg és Szamlatukor táblák adják a lekérdezés forrását.

Számlaosztály Tartozik forgalom

3.37. ábra: A 3. feladat szerinti lekérdezés elvárt kimenete

3.38. ábra: A 4. feladat megoldása

3.39. ábra: Az Összesítés sor hozzáadása a lekérdezésdefiniáló táblázathoz

Összesítés gomb.


139

A 4. feladat megoldása a 3.38. ábrán látható. Itt a lekérdezésdefiniáló táblázat abban különbözik az elızı feladatoknál látottaktól, hogy Összesítés sor is van benne. Ilyen sor az Összesítés gombbal adható hozzá a táblázathoz (lásd a 3.39. ábrán); és mindig szükség van rá, amikor nem az egyes forrássorokból, hanem a forrássorok csoportjaiból képzett értékeket akarunk megjeleníteni a kimeneten.

A 3.38. ábra a lekérdezésdefiníció elsı oszlopa a következıkrıl rendelkezik: Megjelení-tendı adatot definiál (pipa a Megjelenítés kapcsolóban). A kimenı érték a fıkönyvi számla-szám elsı számjegye és az a Számlaosztály nevő oszlopban jelenik meg a kimeneten (lásd Számlaosztály: Left([Fkviszla_szam];1) ). Ez adat (a számlaosztály) egyben a csoportosító ismérv (ezt jelzi a Group By ). – Tehát a kimeneten megjelenı egy-egy sor a forrássorok olyan csoportjáról készül, amelyekben az Fkviszla_szam elsı jegye azonos.

A második oszlop a következıkrıl rendelkezik: Megjelenítendı adatot definiál (pipa a Megjelenítés kapcsolóban). A kimenı érték az egy csoportba tartozó tételek Osszeg érté-keinek összege, azaz Sum(Osszeg) , és az a kimeneten a Tartozik forgalom nevő oszlopban jeleni meg.

A harmadik és a negyedik oszlop nem megjelenítendı adatot, hanem szőrési feltételt definiál (nincs pipa a Megjelenítés kapcsolóban, és Where jelzés az Összesítés a sorban). A Where szó azt is jelenti, hogy a szőrési feltétel az eredeti forrássorokra vonatkozik, nem pedig a csoportokra. A harmadik oszlop értelme az Idoszakkod = [Adott idoszak] feltétel, a negyediké pedig a Szamlaoldal = 'T' .

A harmadik oszlopban az [Adott idoszak] olyan paraméter neve, amelynek értékét az Access a lekérdezés futtatásakor fogja bekérni a felhasználótól a 3.40. ábra szerinti ablakban. Az Access paraméternek tekinti az olyan adatnevet, amely nem azonos a források (táblák) semelyik mezıjének nevével.

A lekérdezés eredménye a 3.41. ábrán látható.

3.40. ábra: Az idıszakparaméter megadása

3.41. ábra: A 4. lekérdezés eredménye

3.5.3 Ellenırzı feladatok a 3.5. alfejezethez A 3.4.4. szakaszban adott feladatokat oldja meg az Access grafikus lekérdezéstervezı felü-letén is. Az ottani 1. feladat view-ját helyettesítse megfelelı lekérdezés definiálásával!


140

FELHASZNÁLT ÉS AJÁNLOTT IRODALOM A 3. FEJEZETHEZ

[Bártfai-2007] BÁRTFAI BARNABÁS: Access 2007 zsebkönyv. BBS-Info Kft., 2007. [Bhamidipati-1999] BHAMIDIPATI , KISHORE: SQL programozói referenciakönyv. Panem Kft,

1999. [Celko-2003] CELKO, JOE: SQL fejtörık. Kiskapu Kiadó, 2003. [Hernandez-2009] HERNANDEZ, M ICHAEL J. – VIESCAS, JOHN L.: SQL-lekérdezések földi

halandóknak - Gyakorlati útmutató az SQL nyelvő adatkezeléshez. Kiskapu Kft., 2009. [Martin-2003] MARTIN, GRUBER: SQL A-Z. Kiskapu Kft., 2003 [Nógrádi-2006] NÓGRÁDI LÁSZLÓ: Access XP alapokon. Nógrádi PC Suli Kft., 2006.

3. adatbázis definiálása és kezelése - bge · pdf...

Documents