Az adatbázis-kezelés nehéz „műfaj”. Ehhez képest az érettségin nem díjazzák túlzottan. Bár a megszerezhető húsz pont fele, a rutin-fe­la­da­tok megoldásával, könnyen bezsebelhető.

    Átnéztem az oktatas.hu-n elérhető érettségi vizsgák adatbázis-feladatait és a megoldásukhoz szükséges műveleteket egy táb­lá­zat­ban (jegyzőkönyv) gyüjtöttem össze, feladatok szerinti bontásban (név, dátum # sorszám). A listát néhány ponton kiegészítettem a szak­ma­i­lag elengedhetetlen műveletekkel, majd a műveleteket csoportba foglaltam.

    Tapasztalatom szerint, az érettségizők többsége a Microsoft Office programjaival vizsgázik, ezért a listában és a megjegyzésekben az Access elnevezéseit használom. De ez nem jelenti azt, hogy a feladatok is ezeket használják! Lássuk a műveleteket!

Minden feladatlap így kezdődik: „Készítsen új adatbázist…” És ezután egy név következik, újmagyarul. Például, cukraszda, szeleromu, re­pu­lo­ter. Szóval, ékezeteket nem kérnek. De nem csak az adatbázis-, de a belső objektumok nevében sem.

A feladatok többségében megadják a text fájl elkészítéséhez használt kódrendszert, de ha hiányzik, akkor a megfelelőt, „próba sze­ren­cse” alapon, nekünk kell kiválasztanunk a varázsló listájából. Apropó, lista. Az egyik feladat állományait, a leírás szerint, az ISO8859-2 szab­vány szerinti kódolással hozták létre, de ilyet nem találunk a segédprogramban. Azért nem, mert ezt a kódrendszert az Access „kö­zép-eu­ró­pa­i (ISO)”-nak nevezi.

    A varázsló a dátumokat tartalmazó-, valamint hiányzó adatokat és számokat vegyesen tartalmazó oszlopokhoz „Rövid szöveg” adat­tí­pust állít be. Viszont a csak nullákat (0) és egyeket (1), valamint a nullákat és mínusz egyeseket (-1) vegyesen tartalmazó oszlopokat „Hosszú egész” mezőméretű számnak látja. Ezeket az automatikus besorolásokat módosítanunk kell!

    A dátumoknak „Dátum és időpont”-, az egész számoknak „Hosszú egész”-, a tizedestört számoknak „Dupla”-, a nulláknak és az egye­sek­nek, valamint a nulláknak és a mínusz egyeseknek „Igen/Nem” adattípust, illetve mezőméretet állítsunk be!

Ha a varázslóban elmulasztottuk, akkor az adattípus-cserét a tábla tervező nézetében is el tudjuk végezni. Egy kivétellel! A dátumokat tar­tal­ma­zó Rövid szövegnek beállított mező adatai az átállítás során törlődnek. Erre a program „a Microsoft Access által végzett kon­ver­tá­lás­kor hibák történtek” szöveggel figyelmeztet. Ezt a problémát, tehát csak a text-fájl ismételt importálásával orvosolhatjuk. A többi eset­ben a csere nem jár adat-vesztéssel, annak ellenére sem, hogy az Access a műveletet követően a „néhány adat elveszett” szö­veg­gel pa­ráz­tat­ja a szegény felhasználót.

    Az elsődleges kulcs mező beállítását tervező nézetben is el kell tudnunk végezni! Két feladat többmezős elsődleges kulcs beállítását ké­ri. A végrehajtás nem okozhat gondot! Először Ctrl billentyűvel jelöljük ki a mezőket, majd a szalagon kattintsunk az elsődleges kulcs ve­zér­lő­re.

Figyelem, figyelem! Több feladatlapon a kapcsolat ábrázolása szimbolikus! A vonal megvan, de nem a kapcsoló mezőket köti össze. Az idegen kulcs mezőt tehát nekünk kell „megtalálni”. Az esetek többségében ez nem okoz problémát, mert a neve tartalmazza az el­sőd­le­ges tábla nevét és az „id” (identification) rövidítést. A kapcsolat egy-, illetve több oldalának jelzését (1, ∞) hiába keressük, mert azt egyik fe­la­dat­la­pon sem tüntették fel.

Az érettségi adatbázis-feladat nagyrésze, különböző „fajsúlyú”, lekérdezésekből áll, amelyeket tervező nézetben, a QBE (Query By Ex­am­ple) rács, vagy egyszerűen a tervező-rács, segítségével hozunk létre. Ez a grafikus felület teszi lehetővé, hogy ne SQL (Struc­tured Query Language) nyelven kelljen megfogalmaznunk, milyen adatokra vagyunk kíváncsiak. A program nézet-váltáskor vagy a le­kér­de­zés men­té­se­kor „leolvassa” a rácsot és összeállítja a megjelenítési utasítást, amelyet SQL nézetben meg is jeleníthetünk.

Az én gépemen (Win’ 10, Office 2019) az Access, a lekérdezés feltételében, nem fogadja el a konkrét dátumot (#2020. 02. 02.#), „Ér­vény­te­len dátumértéket tartalmazó kifejezést írt be”, kapom az üzenetet. Ha ez program-hiba, és valószínűleg az, akkor ne kí­sér­le­tez­zünk, én megtettem, semmi eredménye! Használjuk a DateSerial függvényt. Szintaktikája: DateSerial(évek száma; hónapok száma; na­pok szá­ma). Például, DateSerial(2020; 2; 2). Vagy relációval: >=DateSerial(2020;2;2). Vagy periódust meghatározva: Between DateSerial(2020; 2; 2) And DateSerial(2020;3;2).

    Az egyik feladatban a dátumot és időpontot is tartalmazó (2020. 02. 10. 13:48:52) mezőből kell kiválogatni egy teljes nap be­jegy­zé­se­it. Két megoldás között választhatunk: [1] Between #2020. 02. 10. 0:00:01# And #2020. 02. 10. 23:59:59# vagy [2] Year( [mezőnév] )=2020 And Month( [mezőnév] )=2 And Day( [mezőnév] )=10.

    Figyelem, figyelem! A mezőnév a feltételben mindig szögletes zárójelek között áll! Ha a zárójelek megvannak, de elgépeljük a me­ző­ne­vet, akkor ezt a panelt jeleníti meg az Access:

A képen látható esetben a mezőnév biztos ékezetek nélküli, mi meg, természetesen, ékezetekkel írtuk. Mellékesen, ez az újmagyar, éke­ze­tes karakterek nélküli, nyelv csak az érettségi vizsgán használatos, az ÉLET-ben, windozos környezetben, nem!

    A mezőnévről jut eszembe! Mit jelent az, ha egy mezőnek egy másik mező a feltétele? Például, a „lakhely”, amely egy település-ne­ve­ket tartalmazó mező, feltétele a „szuletesi hely” mező, amely szintén település-neveket tartalmaz. Ebben az esetben a megjelenítési uta­sí­tás emberek között így hangzana: Mutasd, azoknak az embereknek az adatait, akik a szülőhelyükön laknak. Ember és az Access között meg így: Jelenítsd meg azokat a rekordokat, amelyekben a „lakhely” és a „szuletesi hely” mezők bejegyzései azonosak!

A feltételt tartalmazó mezőt, az egyszerűség kedvéért, nevezzük feltétel-mezőnek! Ha a lekérdezés csak egyetlen feltétel-mezőt tar­tal­maz, akkor a felsorolt „lehetőségek”, több feltétel esetén, különböző megoldásokat kínálnak. Több feltétel-mező esetén, ez a sza­bad­ság elvész, mindig az adott feladatnak megfelelő elrendezést, illetve írás-módot kell választanunk.

A feladatok többségében a statisztikai függvények (Min, Max, Sum, Avg, Count) alkalmazása összesítő lekérdezéssel elkerülhető.

    Az egyik feladatban két dátum között eltelt napok számát kell „lekérdeznünk”. Ez a számítás elég gyakori az adatbázis-kezelésben. Gon­dol­junk például egy munka elvégzéséhez szükséges napok számának megállapítására. Napok: [befejezes]-[kezdes]+1. Miért kell az a plusz egy? Képzeljünk el egy egynapos munkát. Reggel elkezdik, este befejezik. Tehát a két mező dátuma azonos. De mégse le­het nulla az eredmény, hiszen egy teljes napot dolgoztak az emberek!

    A „feltétel-rendszerek” művelet-csoportban szándékosan nem említettem, hogy a feltétel kifejezés is lehet. Azért nem tettem, mert ez a lehetőség fogalmilag nem magyarázható. Nézzük miről van szó! Vegyünk példának egy dátumokat tartalmazó mezőt: „vizsga”. Tudni sze­ret­ném ki vizsgázott 2019-ben. Két megoldás közül választhatunk.

A „klasszikus”, tehát a fogalmilag helyes változat felül látható, az Access specifikus pedig alul. A két lekérdezés azonos eredményt ad.

Tehát a lekérdezés „Csúcsérték” és „Egyedi értékek” tulajdonságairól van szó. Fontos a pontos megnevezés, mert a „Csúcsérték” tu­laj­don­sá­got a menüszalagon is beállíthatjuk, de ott „Visszatérés” a felirata a vezérlőjének. Az „Egyedi értékek”-et pedig könnyű össze­ke­ver­ni, a tulajdonságlapon közvetlen alatta álló, „Egyedi rekordok” tulajdonsággal.

    A lekérdezés tulajdonságlapját a menüszalag vezérlőjével vagy az Alt+Enter billentyű-paranccsal jeleníthetjük meg. Az esetek több­sé­gé­ben, azonban nem a lekérdezés-, hanem az aktív mező tulajdonságait kapjuk. A lekérdezés tulajdonságainak megjelenítéséhez kat­tint­sunk a tervező-rács fölé, a táblák területére!

    A lekérdezés eredménye egy táblázat, az egyszerűség kedvéért, nevezzük eredmény-táblázatnak. A két tulajdonság az eredmény-táb­lá­zat sorait befolyásolja. A Csúcsérték-kel csak azoknak a soroknak a megjelenítését írjuk elő, amely egy mező, rangsor szerinti, szél­ső­ér­té­ke­it tartalmazzák. A lekérdezés rendező-mezőjének a szélső-értékeket tartalmazó mezőnek kell lennie. Ha a leg­na­gyob­bak­ra va­gyunk kí­ván­csi­ak, akkor csökkenő, ha a legkisebbekre, akkor emelkedő rendezést kell beállítanunk. A Rövid szöveg adattípusú mező be­jegy­zé­se­i­nek rangsorán az ABC szerinti rendezettséget értjük. A megjelenítendő sorok számának, Csúcsérték szerinti, meg­ha­tá­ro­zá­sá­nál az Access „nem tesz igazságot”. Tehát, ha a három legnagyobbat kérjük, és mondjuk, a harmadik legmagasabb pont­szám tíz re­kord­ban is szerepel, akkor az eredmény-táblázatban mind a tíz sor meg fog jelenni. A Csúcsérték nem csak egész szám, de szá­za­lék is lehet. A vi­szo­nyí­tá­si alap, vagyis a száz százalék, az eredmény-táblázat, szelektálás nélküli, sor-száma.

    Az Egyedi értékek tulajdonság Igaz értékével az eredmény-táblázat ismétlődő sorainak megjelenítését tilthatjuk meg.

Az összesítő lekérdezésben állhatnak csoportosító (Group By), statisztikai (Sum, Count, Avg…), kifejezés (Expression) és feltétel (Where) mezők. Mindegyiket szelektálhatjuk feltétellel, csak a Where szócskával deklarált mezők nem fognak megjelenni az eredmény-táb­lá­zat­ban.

    Az eredmény-táblázat sorait az Access a Group By mezők adatai alapján, növekvő sorrendben, automatikusan rendezi.

A módosító kifejezésben az adatokat tartalmazó mező nevét is szerepeltethetjük. Például, árleszállítás miatt az ár harminc százalékkal csökken: [ar]*0,7. A kis képlet két fontos tulajdonságot mutat: [1] az SQL nyelvben a pont a tizedes elválasztó, de ennek ellenére a ter­ve­ző-rácson nekünk vesszőt kell használnunk, amit majd az Access pontra konvertál az SQL utasítás összeállításakor, [2] a program kép­le­te­i­ben a százalékjel nem használható.

A tábla-készítő lekérdezés mentése egy utasítás rögzítése: ezekkel a mezőkkel és rekordokkal hozz majd létre egy új táblát, ha majd szó­lok! A tábla létrehozására felszólító utasítás a lekrdezés futtatása!

Az SQL utasítás szerepeltetése a feltételben, a segéd-lekérdezés kezelésének legegyszerűbb módja. Néhány szabályt azonban be kell tartanunk. Az utasítás mindig álljon zárójelben! Ha függvénybe helyezzük, akkor a függvény zárójeleit is ki kell tennünk! Például, Year(( SQL )). Ha a segéd-lekérdezés egynél több adatot ad vissza, akkor az SQL utasítást az In szócska előzi meg: In(SQL). Természetesen ezt a kifejezést is tagadhatjuk! Nem ezekre vagyok kíváncsi: Not In(SQL).

   Egy kivételtől eltekintve, az érettségi feladatok űrlap-készítést nem tartalmaznak. Tehát, akkor már csak a jelentés van hátra. A je­len­té­se­ket a vizsgán varázslóval hozzuk létre!

Ha a jelentés lekérdezésen alapul, akkor a lekérdezést is nekünk kell létrehozni. A lekérdezés tartalmazza, sorrendben, a jelentés me­ző­it, csoportosítás és rendezés nélkül, az esetleges feltételekkel! A csoportosítást és a rendezést a varázslóban állítsuk be! Ha a cso­por­to­sí­tó mező Dátum/Idő adattípusú, akkor az Access automatikusan hónapos csoportokat képez. Ezt a Csoportosítási beállítások… fel­i­ra­tú ve­zér­lő­re kattintva módosíthatjuk.

A lista Normál tételét választva a rekordok dátum szerint lesznek csoportosítva. Például, 2020.02.14-i csoportban három, a 2020.02.15-i csoportban öt vásárlás lesz felsorolva.

    De az automatikus csoportosítás, illetve annak felajánlása akkor is előfordulhat, ha a jelentés adatai több táblából származnak. Az aláb­bi képen egy ilyen helyzetet látunk.

A segédprogram automatikus csoportosítás ablakának bal oldalán álló, a jelentés által érintett, táblák nevére kattintva tudjuk a cso­por­to­sí­tást módosítani, illetve elvetni. Felül az automatikusan csoportosított-, alul a csoportosítás nélküli elrendezést látjuk. Az automatikus cso­por­to­sí­tás elfogadása vagy elvetése, nincs befolyással a jelentés-készítés további lépéseire. Magyarul, az automatikus cso­por­to­sí­tás ab­la­ka után a varázsló, minden esetben, megjeleníti az egyéni csoportosítás ablakát is.

Visszatérve oda, ahol elkezdtük, az adatbázis-kezelés nehéz „műfaj”. Időt kell szánni rá! Gyakoroljunk érettségi feladatokon, és né­ze­ges­sük a megoldásukat! A lekérdezések tervező nézete, számos esetben, érthetetlen részleteket tartalmaz. Ennek oka, hogy a fe­la­da­tok ké­szí­tői a lekérdezéseket SQL nyelven állítják össze, és ennek elemeit próbálja az Access a tervező rácson megjeleníteni. De ez nem min­dig eredményez „értelmes” elrendezést, mert ahogy azt már említettem, ezt a felületet pont az ellenkező célra fejlesztették ki: SQL uta­sí­tás készítésére, a tervező-rácsra helyezett elemekből.