1

Tartalomjegyzék 1. Bevezetés ................................................................................................................................2 2. Az adatbázisok általános jellemzıi.........................................................................................3

2.1. Adatok tárolásának lehetıségei ..................................................................................3 2.2. Az adatkezelés problémái és megoldásai ...................................................................7 2.3. A relációs adatbázis-kezelı rendszerek jelentısége.................................................10

2.3.1. A relációs adatkezelés alapfogalmai.................................................................10 2.3.2. Megvalósítások: hasonlóságok és különbségek ...............................................13 2.3.3. Az SQL szabvány .............................................................................................14

2.4. Adatbázisok szerepe a vállalkozás életében .............................................................15 2.4.1. Papír-alapú nyilvántartások és elektronikus adattárak .....................................15 2.4.2. Igények az adatbázissal szemben: tervezés, kialakítás, üzemeltetés ................16

2.5. Összefoglalás ............................................................................................................18 3. Adatbázisok a gyakorlatban .................................................................................................20

3.1. A vállalkozásokra jellemzı adattárak használata .....................................................20 3.1.1. Karakteres felülető adatbázisok........................................................................20 3.1.2. Grafikus felülető adatbázisok ...........................................................................22

3.2. A Microsoft Access adatbázis-kezelı rendszer ........................................................23 3.2.1. Általános jellemzık ..........................................................................................24 3.2.2. Felépítés: munkaterületek, mőveletek ..............................................................25

3.3. Adattárolás................................................................................................................27 3.3.1. A táblák ............................................................................................................27 3.3.2. Adattípusok.......................................................................................................29

3.4. Beviteli és kiviteli eszközök.....................................................................................32 3.4.1. Őrlapok .............................................................................................................32 3.4.2. Jelentések..........................................................................................................38

3.5. Adatkezelési mőveletek............................................................................................41 3.5.1. Lekérdezések ....................................................................................................42 3.5.2. Egyszerő lekérdezések......................................................................................46 3.5.3. Adatmódosító lekérdezések..............................................................................52

4. Összefoglalás........................................................................................................................56 4.1. Az adatmodelltıl a jelentésig ...................................................................................56

5. Irodalomjegyzék ...................................................................................................................57 6. Melléklet – Access SQL.......................................................................................................58

2

1. Bevezetés Az adatokkal kapcsolatos tevékenységek (az adatbázis-kezelés) az informatika egyik

némileg speciális, sokak számára talán kicsit misztikus területe. Pedig ha jobban belegondolunk, a mindennapi életben – mind a munkánk során, mind a magánéletünkben – lépten-nyomon adatbázisokba, köznapian szólva nyilvántartásokba botlunk: egyik oldalról például a szervezetek raktárnyilvántartásai, a különbözı elszámolási rendszerek, mint amilyen a számlázás vagy a munkaidı-nyilvántartás, az ügyfelekkel vagy üzletfelekkel kapcsolatos információk győjtése, a másik oldalról a személyi adataink számtalan központi adattára (rendırség, népesség-nyilvántartó, APEH, TB) vagy akár a különbözı a társaságok tagságával (sportklub, könyvtár) kapcsolatos információk tárolása és kezelése mind ide tartozik. Ezen nyilvántartások hatékony szervezésének illetve a (bennük) tárolt információ felhasználásának képessége számos elınnyel ruházza fel mind az egyént, mind pedig az adott szervezetet. Ebben a jegyzetben ezeket a kérdéseket járjuk körül.

A modul célja, hogy képet adjon a vállalkozások által használt információ szervezett tárolásának és felhasználásának lehetıségeirıl, módszereirıl. Az ismerkedés során (elsıdlegesen a gazdálkodó szervezetekre jellemzı) nyilvántartási és adattároló rendszerek elemzésén keresztül megvizsgáljuk az adatbázisok alkalmazásának lehetıségeit, a megvalósítás, a felhasználás és az üzemeltetés során jelentkezı problémákat és az ezek megoldásával kapcsolatos lehetıségeket. Ehhez elıször áttekintjük a különbözı nyilvántartási rendszerek közös jellemzıit és az esetleges eltéréseket. Ezután az adatbázis-kezeléssel kapcsolatos legfontosabb elvek ismertetésére kerül sor, hogy az így elsajátított elméleti ismeretek alapján végül képesek legyünk akár önálló nyilvántartások megtervezésére és elkészítésére, akár létezı adattárak hatékony kezelésére. A jegyzet nem titkolt célja annak bemutatása, hogy az elektronikus nyilvántartási rendszerek használata hatékonyabb ügymenetet tesz lehetıvé – természetesen megfelelı ismeretekkel rendelkezı felhasználókat feltételezve –, ezért külön rész foglalkozik az elektronikus nyilvántartási rendszer kialakításakor felmerülı feladatokkal.

A gyakorlati ismeretek elsajátítása során (és a jegyzetben is) a konkrét példák a „Microsoft Access” adatbázis-kezelı program specifikumait követik, de (a lehetıségekhez mérten) igyekszünk a vázolt technikákat és módszereket általánosan alkalmazható módon bemutatni.

Jelen tananyag elsıdleges célja az adatbázis-kezelés gyakorlati feladataival kapcsolatos ismeretek bemutatása, ezért az elméleti jellegő anyagrészek nem kerülnek teljes mélységükben ismertetésre. Ezen a részek bıvebb kifejtése a jegyzethez kapcsolódó kurzus tananyagát képezi, illetve a jegyzet végén szereplı irodalomjegyzékben feltüntetett források tanulmányozásával további információk szerezhetık a témakörrel kapcsolatban.

3

2. Az adatbázisok általános jellemz ıi A számunkra fontos adatok és információk tárolásának számtalan módja létezik a

hagyományos papír-alapú nyilvántartásoktól kezdve az elektronikus adattárakig. Azt is elfogadhatjuk kiindulásként, hogy legyen szó bármilyen nyilvántartásról, jellemzıen hasonló tevékenységek kapcsolódnak mindegyikhez: idırıl idıre meg kell keresnünk egy-egy régebbi adatot, különbözı szempontok szerint csoportosítani kell az adatainkat, listákat, kimutatásokat készítünk belılük, egyik-másik néha megváltozik és elıfordul, hogy az idejét múlt adataink között selejteznünk, törölnünk kell. Mindezt lehetıleg úgy, hogy tekintettel kell lennünk a rendelkezésre álló hely nagyságára (legyen ez egy mappa, egy szekrény vagy egy irattár – de akár a merevlemez tárterülete) és arra, hogy elvárjuk, hogy az éppen elvégzendı feladat szempontjából fontos adatok gyorsan elérhetıek legyenek.

Miért használunk adatbázisokat? Egy rendszerezett nyilvántartás (általában) áttekinthetı, ami meggyorsíthatja a keresést (más kérdés, hogy mit tegyünk abban az esetben, ha mindig más szempont szerint kell valamit megkeresnünk: a számlatömb többé-kevésbé rendezett a dátumok vonatkozásában, de ha arra vagyunk kíváncsiak, hogy az elmúlt fél évben melyik partnerünk vásárolt a legtöbbször nálunk, akkor bizony végig kell néhányszor lapozni a teljes tömböt...). Egy kialakított rendszer bıvítése (vagy akár átstrukturálása) egyszerőbb, mint egy rendezetlen adathalmazé. Végül, de nem utolsó sorban az elızıekben nem beszéltünk az adatok azon sajátosságáról, hogy adott esetben bizalmas jellegőek: védeni kell ıket mind az esetleges megsemmisüléstıl, mind az illetéktelen hozzáféréstıl. Egy szervezett nyilvántartás esetén ezek a feladatok jól definiálhatók (pl. páncélszekrénnyel, amelyhez csak bizonyos személyeknek van kulcsa – míg ha a fontos dokumentumok a szervezet minden egységénél megtalálhatók, akkor egy ilyen biztonsági rendszer megvalósítása elég körülményes lehet).

Ha az elızı gondolatokat (amelyek egyaránt igazak bármilyen: akár hagyományos, akár számítógépes nyilvántartásra) kiegészítjük azzal, hogy a számítógép alkalmazása ezen a téren is magában hordozza azokat az elınyöket (ezek nem csak az adatbázisokkal kapcsolatos mőveletekre jellemzı tulajdonságai a számítógépes rendszereknek!), hogy egyértelmő (csak azt hajtja végre, amire utasítást kap), pontos (nem téved) és ellenırizhetı (akár visszamenılegesen is) módon mőködik, láthatjuk, hogy a fenti problémák kezelésének alkalmas eszköze lehet az elektronikus nyilvántartások használata. Végül pedig arról sem szabad megfeledkezni, hogy ebben az „információs társadalom”-ként aposztrofált korban az elektronikus dokumentumok használata egyre elterjedtebbnek tekinthetı, és talán nem túlzást azt kijelenteni, hogy elıbb-utóbb vetélytársa lesz (ha ki nem szorítja – de ez már filozófiai mélységeket érintı kérdés...) a hagyományos iratkezelésnek – amibıl már egyenesen következik, hogy ha az adataink eredendıen elektronikusan állnak rendelkezésre, miért ne tárolnánk is ıket elektronikusan?

Összességében azt mondhatjuk, hogy a strukturálatlan nyilvántartások számos veszélyt hordoznak: nehézkesen ellenırizhetı és/vagy visszakereshetı adatok, felesleges többszörös tárolás, rugalmatlanság (a felhasználói igényekkel szemben), adatvédelmi és jogosultsági kérdések. Természetesen ha csak elektronizáljuk a nyilvántartásunkat, attól mindez nem fog egycsapásra megoldódni, de a (megfelelı módon kialakított) adatbázisok segítségével ezen problémák megoldása egyszerőbb (és hatékonyabb).

2.1. Adatok tárolásának lehet ıségei Az adatbázisok-kezelés ugyanolyan tudomány (mások szerint már szinte mővészet...),

mint a matematika vagy a biológia, természetes hát, hogy megvan a kialakult fogalomrendszere, saját definíciókkal és szabályokkal rendelkezik. (A teljességhez

4

hozzátartozik, hogy természetesen saját (és sajátos) történelemmel is, ennek ismertetése azonban meghaladja jelen jegyzet kereteit.) Annak érdekében, hogy egyszerően (és ugyanakkor egzakt módon) foglalkozhassunk ezzel a területtel, tisztázzuk a legfontosabb alapfogalmakat!

A továbbiakban az adatbázis alatt olyan nyilvántartást értünk, amely a valós világ valamely konkrét vagy absztrakt elemeirıl azonos jelentéstartalmú információkat tárol. Azaz ha az adatbázisunk a könyvtár lesz, akkor ebben az adatbázisban a kölcsönzık adatait (minden egyes kölcsönzırıl külön-külön, de ugyanazokat az adatokat: neve, lakcíme, telefonszáma, stb.) és a könyvek adatait (ismét könyvenként, de minden könyvrıl ugyanazt: szerzıje, címe, ára, stb.) fogjuk nyilvántartani.

Adatbázis: valamilyen (az egyén vagy a szervezet számára lényeges) szempont alapján összetartozó információk szervezetten tárolt együttese. Az információk kiválasztott csoportját (amit tulajdonképpen az adatbázisban tárolunk) egyednek (a munkaügyi nyilvántartásban minden egyes dolgozó egy-egy önálló egyed), az egyes egyedekrıl tárolt jellemzıket tulajdonságnak (ugyanezen nyilvántartásban tulajdonság lehet a dolgozó neve, a születési ideje, a fizetése, stb.) nevezzük.

Ahogy az a fenti definícióból is kiderül, egy adatbázis mindig két komponensbıl épül fel:

� a benne tárolt információból, ez az adatbázis adattartalma, a felhasználó számára jelentéssel bíró része - tulajdonképpen az egyedek;

� az információ tárolásának módjával kapcsolatos szabályokból, ez az adatbázis szerkezete (struktúrája) – ami nem más, mint az összes tulajdonság.

A két komponens nem választható el egymástól: az adatok jellege és a velük kapcsolatos mőveletek köre határozza meg, hogy milyen módon kell (célszerő) az adatbázist kialakítani.

Adatbázis-kezelı rendszer1: az adatbázis tárolását illetve az adatokkal végezhetı mőveletek megvalósíthatóságát biztosító rendszer.

Fontos megjegyezni, hogy adatbázis-kezelı rendszer alatt általánosabb fogalmat értünk, mint egy konkrét szoftver (az adatbázis-kezelı program): az adatbázis-kezelı rendszerbe egyaránt beletartozik az adatok tényleges tárolását végzı számítástechnikai hardver eszköz (egy winchester, egy optikai vagy szalagos tárolóegység), az ezekhez való hozzáférést biztosító szoftverek (elsıdlegesen az adatbázis-kezelı program, de ide tartozik (többek között) az operációs rendszer is), maguk a tárolt adatok és természetesen mindazok a személyek (felhasználók), akik ezekkel az eszközökkel valamilyen mőveletet végeznek. (1. ábra)

1 angolul DataBase Management System - rövidítése a szakirodalomban is gyakran használt DBMS (vagy a magyar megfelelı kezdıbetőibıl képzett ABKR)

5

1. Ábra – az adatbázis-kezelı rendszer komponensei

Mit látunk az ábrán? Az adatbázisban tárolt információ alapesetben valamilyen háttértárolón helyezkedik el – ezeknek az eszközöknek a kezelése az operációs rendszer (egyik) feladata. Amennyiben valamilyen kérés érkezik (akár új információt szeretnénk tárolni – írás –, akár valamely tárolt adatra van szükségünk – olvasás –), az operációs rendszer elvégzi a megfelelı mőveletet és az eredményrıl értesíti a szolgáltatását igénylı adatbázis-kezelı programot (ABK). Az adatbázis-kezelı program feladata többrétegő: szervezi az adatok tárolását (azaz kezeli az adatszerkezetet: melyek a szöveges típusú adatok, melyek a számok, dátumok, egyebek), biztosítja a felhasználó által meghatározott összetartozás (az adattartalom) fenntartását (egy adott személynek a neve, születési ideje és munkahelye például egyetlen logikai egységet képvisel), és kommunikál az adatbázis felhasználóival: megjeleníti az adatokat, értelmezi és végrehajtja a felhasználó kéréseit, listákat készít, stb. A teljességhez hozzátartozik, hogy az egyes komponensek nem feltétlen egyetlen elemet jelölnek, például (más és más jogosultság mellett) az adatbázis-kezelı többféle különbözı felületen keresztül is kommunikálhat a felhasználóival.

(A fenti séma konkrétan az adatbázis-kezelı programok segítségével megvalósított adatbázis-rendszert szemlélteti. A gyakorlatban azonban nem csak ilyen adatbázisok létezhetnek: ha a nyilvántartásunk azonos jelentéstartalmú egyedek tulajdonságait szervezetten tárolja, akkor bármilyen alkalmazást tekinthetünk adatbázis-kezelınek. A legjobb példa erre az operációs rendszerek állományszervezése (amit a saját céljainkra is kitőnıen felhasználhatunk, ha dokumentumainkat valamilyen rendszer szerint győjtjük különbözı mappákba), de a mindennapi életben gyakran találkozhatunk Excelben készült táblázatokkal is, amelyek szintén a hasonló szerepet tölthetnek be – gondoljunk csak a rendezés mőveletére vagy a szőrık alkalmazására!)

Tekintsük át a legfontosabb adatbázis-rendszer modelleket!

6

A számítógépeknek a megjelenésük óta az egyik legfontosabb feladata, hogy (viszonylag) nagy mennyiségő információt tartósan és biztonságosan tároljon. Az elsı idıkben ez minden rendszer nélkül valósult meg, ekkor csak az volt a fontos, hogy bizonyos adatok „megmaradjanak az utókornak”. Az idık során azonban felismerték, hogy ezek a rendszerek alkalmas programokkal kiegészítve hatékony adatkezelésre is képesek, így születtek meg a kimondottan az adatkezelésre specializálódó programok, az adatbázis-kezelık. A különbözı próbálkozások az adatbázis-kezelı rendszer más és más komponensét ítélték a legfontosabbnak (vagy legcélszerőbben kezelendınek), így számos elképzelés alakult ki (és jónéhány közülük meg is valósult, míg akadnak meddınek bizonyult fikciók is).

Az adatbázis-kezelık elsı generációját a hierarchikus adatbázis-kezelık alkották (legismertebb képviselıje az IBM cég IMS2 rendszere volt). Alapegysége a rekord volt (a tulajdonságok csoportja, amely rendelkezik azzal a kényelmes jellemzıvel, hogy a számítógép a háttértárak elérésére hasonló szerkezeti egységet használ, így a felhasználói és a fizikai adatszerkezet nem sokban különbözött egymástól), az adatok összefüggésének leírására pedig hierarchikus fastruktúrát használtak – ennek lényege, hogy minden rekordban volt egy „plusz”-tulajdonság, nevezetesen hogy ki az adott rekord „szülırekordja” (fölérendeltje, innen a hierarchikus elnevezés). Az ilyen elvő rendszerek legnagyobb elınye, hogy sémája a valós életben leggyakrabban elıforduló szervezıdéseket képes pontosan modellezni – a hátrányairól mindjárt szót ejtünk.

A módszer továbbfejlesztéseként születtek meg a hálós adatmodellt megvalósító adatbázis-kezelık (ilyen volt például az IDMS3), amelyek legfontosabb eltérése a hierarchikushoz képest az volt, hogy kétirányú kapcsolatot lehetett megadni az egyes rekordok közti összefüggések leírásához. Ez azért különösen fontos, mert a valós világban viszonylag gyakoriak az olyan összefüggések – az adatbázis-kezelés terminológiájában kapcsolatok –, amelyek több egyed között és nem feltétlen kölcsönösen egyértelmő módon léteznek – azaz a hálós adatmodell alkalmazásával lényegesen több területen alkalmazhatóvá vált az adatbázis-kezelés (olyan területeken is, amelyek számítógépes feldolgozására a hierarchikus modell – nem tudván kezelni az ilyen kapcsolatokkal leírható prblémákat – nem volt képes).

Ezek a rendszerek elsıdlegesen a számítógép specifikumait és mőködési sajátosságait vették figyelembe, és ezt egészítették ki az adatkezeléshez szükséges egyéb mőveletekkel. Ehhez képest hatalmas elırelépés volt, hogy a következı generációs ABKR-ek felhasználói oldalról közelítették meg az adatbázis-kezelést. A relációsnak elnevezett adatbázis-kezelık átszervezték a tárolási rendszert, újraértelmezték az adatbázis-kezelés alap- és kiegészítı feladatait, szabványosították a legfontosabb mőveleteket – és mindezt egy olyan modellben, amely matematikailag levezethetı és igazolható rendszerre épül. Mivel jelenleg ez a modell tekinthetı a legelterjedtebbnek, ezzel a következıkben részletesen foglalkozunk (ismertebb képviselıi korábban a dBase, Clipper, FoxPro, manapság az Access, Oracle és a különbözı SQL megvalósítások).

Végül meg kell említeni, hogy a fejlıdés természetesen ezen a téren sem állt meg, jelenleg az objektum-orientált elvő adatbázis-kezelık tekinthetık a következı generációnak, azonban ezek elterjedésére (és ebbıl következıen a gyakorlati tapasztalatokra) még várni kell – mint ahogy arra is, hogy kiderüljön, hogy fejlıdésrıl vagy zsákutcáról van-e szó?

2 Information Management System (kb. információ-felügyeleti rendszer) – érdekes, hogy nem adatbázisnak nevezi magát... 3 Integrated Database Management System (kb. integrált adatbázis felügyelı rendszer)

7

2.2. Az adatkezelés problémái és megoldásai Az adatbázis-kezelı rendszerek jellemzıen közel azonos tevékenységekkel,

feladatokkal foglalkoznak: az adatokat be kell vinni a számítógépbe, a tárolt adatokat meg kell jeleníteni, az esetleges változásokat el kell rajtuk végezni, a feleslegessé vagy idejétmúlttá vált adatokat pedig törölni kell. A fenti tevékenységeket alapvetıen négy csoportba oszthatjuk, az egyes csoportokba sorolt mőveletek megvalósításáért felelıs adatbázis-kezelı komponenseket alnyelveknek nevezzük. Az alnyelvek és a hozzájuk kapcsolódó tevékenységek a következık:

1. adatdefiníciós (Data Definition Language, DDL): az adatok tárolási szerkezetének kialakításában és az adatok felvitelében részt vevı tevékenységek összessége;

2. adatmódosító (Data Manipulation, DML): az adatok tartalmának változtatásával illetve az adatok törlésével kapcsolatos feladatok;

3. adatlekérdezı (QUERY): az adatok kiválogatásával, listázásával, valamilyen szempontnak megfelelı módon történı megjelenítésével kapcsolatos mőveletek;

4. vezérlı (Data Control, DCL): az ellenırzéssel (pl. a felhasználói jogosultságok kezelésével) és a biztonsággal (adatok mentésével és helyreállításával) kapcsolatos parancsok.

Ha alaposabban szemügyre vesszük ezeket a mőveleteket (és összevetjük a korábban tárgyalt, az adatbázisokra jellemzı problémákkal), akkor láthatjuk, hogy a konkrétan alkalmazott rendszertıl és az adatok jellegétıl függetlenül az egyes tevékenységek (és ilyen értelemben az alnyelvek) közel azonos problémakörrel kapcsolatos tevékenységekre koncentrálnak. A legfontosabbak (a teljesség igénye nélkül) ezek közül a redundancia, az inkonzisztencia, az ismeretlen adat tárolásának kérdése, a többszörös hozzáférés, az elosztott adattárolásból adódó problémák, stb.

A redundancia ismétlıdést jelent, az adatbázis-kezelés során a nem kívánatos, felesleges ismétlıdéseket értjük alatta. Ez a probléma elsısorban az adattárolással kapcsolatos: ugyanaz az egyed többször is szerepel az adatbázisban – szemléletesen Kiss Béla személyi adatait kétszer vesszük fel. Miért okoz ez problémát? Részint a második példány feleslegesen foglalja a rendelkezésre álló tárterületet, másrészt (és ez a fontosabb) ellentmondáshoz vezethet: tegyük fel, hogy Kiss elköltözik, és kijavítjuk a lakcímét az egyik egyedben – a következı bérjegyzékben már 2 Kiss Béla fog szerepelni, más és más címmel, melyik is az igazi? Azt, hogy ez mennyire nem elméleti probléma, jól szemlélteti az a (hibás!, de általános) gyakorlat, hogy az egyes szervezeteknél a különbözı egységek külön nyilvántartásokat vezetnek: egyet a bér, egyet a munkaügy, egyet az üzemorvos, stb. (Természetesen példálózhatnánk olyan nagyobb léptékő rendszerekkel is, mint az állami hivatalok – gondoljunk bele, hogy egy névváltoztatás során hány helyen kell aktualizáltatnunk az adatainkat...)

(Itt kell azonban megjegyeznünk azt is, hogy éppen a relációs adatbázis-kezelıkre jellemzı az úgynevezett irányított redundancia, ami alatt a szükséges ismétlıdéseket értjük – itt is többször kerülnek bizonyos adatok tárolásra, de ellenırzött módon és csak a modell korlátai miatt.)

Mit lehet tenni? Rendszerszinten vajmi keveset. Az adatbázis-kezelık többsége nem nyújt eszközt az ismétlıdı felvitel megakadályozására (nem is tehetné, hiszen elképzelhetı olyan extrém eset, amikor éppen ez a cél!), de általában támogatja az ismétlıdések megkeresését, illetve pl. kulcsok vagy megszorítások (ld. késıbb) használatával csökkenthetı a véletlen ismétlıdı felvitelek veszélye.

8

Inkonzisztenciának az adatok tartalmában megjelenı ellentmondást nevezzük – az elızı példában ugyanazon dolgozó két lakcíme inkonzisztens adat volt (valóban az inkonzisztencia gyakori kísérıje a redundáns tárolásnak), de ide tartozik az is, amikor egy bető elgépelése miatt valakinek a bankszámla-száma nemlétezı bankot próbál azonosítani, stb. Ezek a problémák teljes egészében csak felhasználói szinten kezelhetık, hiszen az adatok értelmezésének képességét tételezik fel.

A következı kérdés az, hogy mit kezdjünk azokkal az adatokkal, amelyek értékét jelenleg nem ismerjük? Hagyjuk ki! Persze, azonban ez közel sem ilyen egyszerő: gondoljunk csak bele, hogy pl. egy egyszerő átlagolásnál sem mindegy, hogy mennyivel osztok: ha van 10 termékem, de csak 7-nek tudom az árát, akkor mennyi is lesz az átlagáruk? Az tehát nem megoldás, hogy az ismeretlen adatot nullával helyettesítjük (már csak azért sem, mert – mint azt rövidesen látni fogjuk – az adatbázis-kezelık típusokat rendelnek az egyes tulajdonságokhoz: a név jellemzıen valamilyen szöveg jellegő információ, a születési idı pedig általában egy konkrét dátum – de mikor is volt 0?). A másik lehetıség, hogy nem engedjük meg, hogy az adatbázisunk hiányos legyen: minden adatot kötelezı megadni! Ez azonban olyan megszorítás lenne, ami szinte használhatatlanul megnehezítené az adatbázis-kezelést. A kompromisszum az ismeretlen érték megkülönböztetése az ismerttıl: az adatbázis-kezelık általában tartalmaznak egy speciális adatot, aminek a neve hagyományosan NULL , és ami nem egyenlı nullával, nem feleltethetı meg (bár mutat némi rokonságot) az egyetlen karaktert sem tartalmazó szöveggel – egyszerően csak azt jelzi, hogy a kérdéses adat nem áll rendelkezésre, hiányzik, ismeretlen.

A következı probléma az adatbázisok azon sajátosságából adódik, hogy alapértelmezés szerint az adatbázissal egy idıben több felhasználó is dolgozik. Képzeljük el a vállalat nyilvántartási rendszerét, amelybe raktáros éppen felviszi a beszerzett anyagokat, az értékesítés pedig az aktuális vevı által vásárolt árukról készíti a számlát – vagy képzeljük magunk elé a hipermarketek pénztárláncát vagy a bankjegykiadó automatákat, és még sokáig lehetne folytatni a sort. Miért okoz ez gondot? Részben azért, mert a számítógép egy idıben csak egyetlen tevékenység elvégzésére képes – ez azonban nem az adatbázis-kezeléshez kapcsolódó probléma, ennek megoldása az operációs rendszer feladata –, részben pedig azért, mert az egyidıben zajló mőveletek között akadhatnak ellentmondásosak – ez viszont már szigorúan az adatbázis-kezelı hatáskörébe tartozó probléma.

Vegyük a következı példát: a személyi nyilvántartásban az egyik munkatárs nyomtatja a dolgozók adatait, miközben egy másik módosítja azokat: a kinyomtatott változat nem fog megegyezni az adatbázis tényleges tartalmával (már megint az inkonzisztencia...). Rosszabb esetben az is elıfordulhat, hogy mindkét munkatárs ugyanazt az egyedet módosítja: a fınök éppen megváltoztatná a beosztott munkahelyét, miközben a gazdasági osztály kollégája a szabadságra fordítható napok számát szeretné csökkenteni a kivett napokkal. Mivel ugyanazzal az adattal dolgoznak, induláskor mindketten ugyanazokkal a kiinduló értékekkel rendelkezınek látják a dolgozó kartonját, elvégzik a saját módosításukat és elmentik a változásokat – igen ám, de a mentések sorrendjének függvényében az elsı mővelet eredménye elvész: a második mentés visszaírja az eredeti adatot! Ennek megelızésére az adatbázis-kezelı rendszerek zárolják a módosítás alatt álló adatokat, azaz egy idıben összesen egyetlen személy módosíthatja egy egyed valamilyen tulajdonságának az értékét.

Ugyanebbe a problémakörbe tartozik a felhasználók eltérı jogosultságából adódó problémák kezelése: a gazdasági ügyekért felelıs kollégának szükséges, hogy meg tudja változtatni a dolgozók fizetésének értékét, de képzeljük el mi történne, ha ezt minden dolgozó számára lehetıvé tennénk... Másrészt nem biztos, hogy minden munkatárs számára az összes tárolt információ elérhetı kell, hogy legyen: a dolgozó megnézheti saját adatait, de nem biztos, hogy joga van betekinteni a kollegáiról nyilvántartott adatokba. A különbözı

9

felhasználókhoz kapcsolódó adatbázis-részeket szokás nézeteknek, az egyes felhasználók által elvégezhetı mőveletek körét pedig szerepeknek nevezni – ezek definiálása egy kitüntetett felhasználó (az adatbázis-adminisztrátor) feladata, de az ellenırzésüket és betartatásukat már az adatbázis-kezelı végzi.

Hasonló megközelítésbıl adódik az adatbázisok elosztott jellegével kapcsolatos problémakör is. Az adatbázisban nagy mennyiségő információt tárolunk (és itt fontos, hogy „nagy” alatt ténylegesen sokat képzeljünk, nem néhány száz vagy néhány ezer, hanem százezres vagy még nagyobb elemszámú nyilvántartások is léteznek, és az adatbázis-kezelıknek ezekkel is meg kell tudni birkózni!), és elıfordulhat, hogy a rendelkezésre álló hely elfogy – ez esetben egy másik háttértárolón vagy akár egy másik számítógépen folytathatjuk a tárolást. A másik jellemzı eset, mikor az adatbázis tartalmához térben eltérı helyeken kell hozzáférnünk (gondoljunk csak a szervezet központja és az egyes településeken megtalálható telephelyek vagy kirendeltségek példájára!): ebben az esetben az információt el kell juttatnunk egyik számítógéprıl a másikra (ami már önmagában is adatbiztonsági problémákat vet fel, de ezek tárgyalása a hálózati ismeretekkel kapcsolatos témakör feladata). Mit tegyünk?

Az egyik lehetıség, hogy az adatbázis marad a központ számítógépén, és az egyes telephelyek minden alkalommal, amikor valamilyen mőveletet szeretnének végezni, elkérik a számukra fontos adatokat – ez azonban adott esetben nagy mértékben lelassíthatja a munkavégzést (az adatátvitel sebessége nagyságrendekkel elmarad a számítógép mőveletvégzési sebességétıl), nem szólva arról, hogy ebben az esetben az elıbb említett kölcsönös hozzáférésbıl adódó problémák hatványozottan jelentkeznek, hiszen a központi számítógép majd csak akkor érzékeli, hogy két telephelyen ellentétes értelmő mőveleteket végeztek, mikor azok (megnyugodva az elvégzett munka örömével) visszaküldik az általuk módosított adatokat...

A másik lehetıség, hogy minden telephely rendelkezik egy saját adatbázissal, amit használ és karbantart és idırıl idıre elküldi a központnak a saját változatát – ami az idıkihasználást tekintve lényegesen hatékonyabb módszer, viszont szinte lehetetlenné teszi a telephelyek egymás nyilvántartásával kapcsolatos feladatainak megoldását (csak azért, mert az egyik helyen elfogyott egy alkatrész, nem biztos, hogy rendelni kell, ha a másik telephelyen hegyekben áll...), és lényegesen bonyolítja a központ feladatát, akinek az (esetenként szerkezetileg is eltérı) adatbázisokat kell valahogyan egységes, kezelhetı egésszé alakítani, hogy a számára fontos döntésekhez mindenhonnan rendelkezésre álló információt ki tudja bányászni az adathalmaz(ok)ból.

Látható, hogy ebben a kérdésben nincs egyetlen és üdvözítı megoldás, akármelyik módszert is választjuk, mindenképpen járulékos feladatokkal és (át)szervezési kérdésekkel találjuk szemben magunkat. Ezzel a problémakörrel kapcsolatban a legfontosabb fogalom a szinkronizáció, a különbözı helyeken tárolt adatok idıben állandóan helyes (konzisztens) állapotának fenntartásának a képessége.

Láthatjuk, hogy az adatbázis-kezelés nem egyszerő problémakör – de alkalmas eszközzel ezen problémák és a szükséges megoldások jelentıs része nagyon egyszerően elvégezhetı. Az elsı és legfontosabb (ezen a területen is) az elızetes tervezés. Az adatbázisok kiépítését egy hosszú elméleti elemzési-tervezési folyamat elızi meg (adatmodellezés), amely során az elıre látható problémák körét megpróbálják szőkíteni, és szabályok és biztonsági intézkedések beépítésével automatizálható eszközöket biztosítani ki nem szőrt esetek kezelésére. Az adatbázis-kezelı rendszerek egyik legfontosabb feladata, hogy ezen problémák megoldásában minél nagyobb arányban vegyen részt, megkímélve (a lehetıségekhez mérten) a felhasználót attól, hogy ezeket a problémákat egyáltalán érzékelje.

10

A következıkben megismerkedünk a jelenleg legelterjedtebbnek tekinthetı adatbázis-kezelési módszerrel, a relációs elvő adatbázis-kezeléssel.

2.3. A relációs adatbázis-kezel ı rendszerek jelent ısége Habár a relációs adatbázis-kezelı rendszerek elméleti alapjai az 1970-es évek elejétıl

rendelkezésre álltak4, az elsı ilyen elven mőködı programok megjelenésére egy évtizedet kellett várni5, elterjedésük pedig a csak a ’80-as évek második felétıl indult meg. A relációs adatbázis-kezelı rendszerek elterjedését nagy mértékben megkönnyítette az a tény, hogy az adatbázis filozófiája igazodott a való világ objektumaihoz (jelentısen megkönnyítetve az adatbázisok tervezését), szabványszinten tartalmazott olyan megszorításokat, amelyek automatizálhatóvá tették az adatok ellenırzését (csökkentve ezzel a hibalehetıségek számát) és végül, de nem utolsó sorban platform-független szabvány kidolgozását tette lehetıvé (így a gyártóknak már nem kellett a konkrét számítógépes környezet specifikumaira koncentrálniuk a fejlesztések során, a felhasználók pedig lényegesen nagyobb szabadságot kaptak az adatok hordozhatósága, egy rendszerbıl egy másikba való átvitele (például fejlesztés) során).

2.3.1. A relációs adatkezelés alapfogalmai A relációs adatbázis-kezelésben a leggyakrabban alkalmazott fogalom, a reláció

számos jelentéssel bír. Részben utal arra, hogy a modell alapját egy olyan matematikai módszertan képezi (a reláció-algebra), amelynek mőveletei és szabályai definiáltak, jól ismertek és hatékonyan adaptálhatók számítógépes megvalósításra. Másrészt relációnak nevezzük az adatainkat tartalmazó táblázatokat, de ugyanígy hívják összefoglalóan a táblákon elvégezhetı mőveleteket (sorok és oszlopok kiválasztása, bıvítés, törlés) is.

Reláció: olyan kétdimenziós táblázat, amely meghatározott számú, azonosítóval („névvel”) rendelkezı oszlopból és tetszıleges számú sorból áll.

A reláció sorait rekordoknak, az oszlopokat attribútum oknak (tulajdonságoknak, egyes hazai terminológiában mezınek – ez utóbbival azért érdemes vigyázni, mert más forrásokban a sor és oszlop metszéspontját jelölik ugyanezzel az elnevezéssel!) nevezzük. Egy adott rekord esetében minden attribútumhoz tartozik egy (és csak egy) érték.

A relációval kapcsolatban számos megkötést tartalmaz a szabvány (ezek egy része a gyakorlati megvalósításokból (a konkrét relációs adatbázis-kezelı programokból) az egyszerőbb, hatékonyabb kezelhetıség érdekében kimaradt), ezek közül a legfontosabbak:

1. Egy adatbázis tetszıleges számú relációt (táblázatot) tartalmazhat, de minden relációnak egyedi azonosítója (neve) van az adatbázison belül.

2. Egy sor és oszlop keresztezıdésében egyetlen érték szerepel (nincs többértékő attribútum).

3. A soroknak egyedieknek kell lenniük (nem lehet két olyan rekord, amely minden tulajdonságában megegyezı értékeket tartalmaz).

4. Az oszlopok nevei egyediek.

5. Az oszlopok és a sorok sorrendje (az adatbázisban tárolt információ értelmezését tekintve) lényegtelen.

6. Integritási (érvényességi) szabályok.

4 Edgar F. Codd, a relációs adatbázis-kezelés „szülıatyja” 1971-ben publikálta elsı eredményeit 5 IBM SEQUEL (1976), IBM DB2: 1982, Oracle: 1982, dBase II: 1982 (?)

11

Az elsı és a negyedik megkötés tulajdonképpen teljesen természetes, hiszen csak azt mondja ki, hogy a táblázatunk egyes (nem az adatokkal kapcsolatos) részeinek megkülönböztethetınek kell lennie – nem sok értelme lenne, ha ugyanazzal a névvel különbözı részeit jelölnénk a táblázatnak, hiszen akkor valahányszor használni szeretnénk valamelyiket („hivatkozunk rá”), a név mellett további leíró információkat kellene megadni, teljesen feleslegesen.

A második szabály talán egy kicsit szigorúnak tőnik, ha a valós világ oldaláról közelítjük meg a kérdést, ugyanis azt mondja ki, hogy nem lehet olyan tulajdonság, aminek egynél több értéke lehet – márpedig a valóságban számos ilyen példát tudunk mondani, elég csak (egy személyi nyilvántartásban) a „gyermeke neve” vagy „kedvenc színe” tulajdonságra gondolni – ez azonban a hatékony mőködés ára: a többértékő tulajdonságok kezeléséhez az adatbázis-kezelés összes mőveletét ki kellene egészíteni újabb ellenırzı feltételekkel, ami jelentısen lassítaná a rendszer. (A gyakorlati megvalósítás során látni fogjuk, hogy ezt a problémát viszonylag könnyen – igaz, ismételt tárolással, de emlékezzünk vissza: azt mondtuk, a relációs adatbázis-kezelés során igenis van némi (szükségszerő) redundancia! – meg tudjuk oldani.)

A harmadik megszorítás tulajdonképpen megint természetes: ha két rekord minden tulajdonságában rendre ugyanazok az értékek szerepelnek, akkor ugyanazt az egyedet írják le, tehát valaki vagy valami duplán szerepel az adatbázisban – ennek nemkívánatos hatásait szintén áttekintettük korábban. Ennél azonban lényegesen több – és a relációs adatbázis-kezelés szempontjából sokkal fontosabb – következménye van ennek a szabálynak: lehetıvé teszi a kulcsok definiálását.

Kulcs: az attribútumok olyan csoportja, amely egyértelmően megkülönbözteti a rekordokat.

A kulcs tehát egy vagy több attribútum. Ha a relációból kiragadjuk ezeket (és csak ezeket) az attribútumokat (mivel a definíció szerint egyértelmő megkülönböztetést tesz lehetıvé), biztos, hogy minden rekordban más és más értékek fognak szerepelni. Mi biztosítja azt, hogy mindig találunk ilyen attribútum-csoportot? A harmadik megszorítás, ugyanis ha minden rekordunk különbözı, akkor (legrosszabb esetben) az összes attribútumot kiválasztva biztosan teljesül a kulccsal kapcsolatos feltételünk.

A kulcsok szerepe a relációs adatbázis-kezelésben nem elhanyagolható: azon túl, hogy megkönnyítik a rekordok megkeresését (nem kell az összes jellemzıt ismernünk vagy megvizsgálnunk ahhoz, hogy kiválasszuk a keresettet), részt vesznek a kapcsolatok kezelésében és bizonyos fokú ellenırzési lehetıséget is biztosítanak.

Az ötödik megszorítás csak azt jelenti, hogy akár hogy is rendezgetjük a táblázatunkat (sorokat vagy oszlopokat is cserélgethetünk tetszés szerint), ettıl az adattartalomban semmilyen változás nem következik be: ily módon nem jön létre és nem is vész el egyetlen adatunk sem, az adatbázisunk nem lesz ezáltal ellentmondásos vagy hibás, stb. – azaz szinte szabad kezet kapunk, hogy az adatainkat az adott feladat szempontjából legmegfelelıbb formában kezelhessük.

Végül itt vannak még az integritási szabályok. Ez a kifejezés egy győjtıfogalom, a relációs adatbázis-kezelés olyan szabályait tartalmazza, amelyek azt hivatottak elısegíteni, hogy az adatbázis tartalma helyes, ellentmondásoktól és felhasználói hibáktól mentes legyen. Ezek közül a legfontosabb a lehetséges értékek körét meghatározó ún. tartományi integritás, de ide tartozik a kulcsok kezelésével kapcsolatos szabályok (entitás és referenciális integritási szabályok: kulcsban szereplı tulajdonság értéke nem lehet NULL, kulcsként megjelölt tulajdonságokban nem fordulhat elı ismétlıdı érték, két adattábla közti kapcsolat definiálásának és kezelésének szabályai, stb.)

12

Tartományi integritás: minden attribútumhoz hozzárendelhetı egy olyan értékkészlet, amelybıl a rekordok az adott attribútumra vonatkozó értékeiket felvehetik.

Ez legegyszerőbben az adott tulajdonság típusának megadását jelenti (a „fizetés” oszlopban nem szerencsés a „Kiss” érték megjelenése), de tartalmazhat értéktartományt (a „fizetés” nem lehet negatív, de nem haladhatja meg az 500 000 Ft-ot sem) vagy formai megkötést (a „rendszám” tulajdonság értékei pontosan 6 karakterbıl kell, hogy álljanak, amelyek közül az elsı három bető, a második három szám kell, hogy legyen) is.

Látható, hogy az integritási szabályok arról gondoskodnak, hogy a potenciális hibalehetıségek közül a legtöbbet már rögtön az adatfelvitel során kiszőrjük, megelızve ezáltal a késıbbi hibakeresés és az (esetleg sokkal bonyolultabb) utólagos ellenırzés vagy javítás szükségességét.

A teljességhez hozzátartozik, hogy a relációs adatbázis-kezelı rendszerek sem jelentenek univerzális megoldást minden problémára. Egy ilyen rendszer kidolgozása komoly tervezı munkát igényel, amelyben a normalizálásnak nevezett folyamat játszik központi szerepet. Ennek lényege, hogy az adatbázist elıre meghatározott szabályok alapján bizonyos strukturális szabályoknak eleget tevı részekre bontjuk, így biztosítva azt, hogy a felhasználás során a lehetı legkevesebb adatkezelési anomáliával (hibás vagy nem meghatározható eredményt produkáló mővelettel) találkozzunk.

Anélkül, hogy a normalizálás menetére részletesen kitérnénk, a relációs adatbázis-kezelı rendszerek általános jellemzıinek összefoglalásaként nézzünk meg egy példát:

2. Ábra – relációs adattábla

A fenti táblázat egy dolgozói nyilvántartás részlete. Az elsı sorban az attribútumok (szürke háttérrel, félkövér betővel jelölve) szerepelnek, az azt követı 3 sor 1-1 dolgozó adatait tartalmazó rekord. Kulcsnak válasszuk a Sorszám tulajdonságot! A fentiek megfelelnek a relációs adatbázis definíciójának és a vele szemben támasztott általános követelményeknek is (gyakorlásként ellenırizzük!)

Nézzük meg azonban, mi történik, ha ezzel az adatbázissal különbözı mőveleteket végzünk:

� ha bérlünk egy új telephelyet, az adatait mindaddig nem tudjuk felvenni a nyilvántartásba, míg dolgozót is nem veszünk fel erre a telephelyre – különben megsértenénk a „kulcs nem tartalmazhat NULL értéket” megszorítást;

� ha megváltozik a debreceni telephely címe, ezt a tényt annyiszor kell az adatbázisban módosítani, ahányan az adott telephelyen dolgoznak (képzeljük ezt el egy nagyvállalat esetében...) – különben adatbázisunk ellentmondásossá válik;

� ha Nagy Éva kilép a vállalattól, és kitöröljük az adatait, ezzel elveszítjük a miskolci telephelyre vonatkozó összes adatunkat is...

Mindezek a problémák azért merülhetnek fel, mert az adatbázisunk ugyan eleget tesz a reláció formai megkötéseinek, de rosszul szervezett (nem normalizált). Amennyiben az adatbázisunkat normalizáljuk, ezek a hibák a késıbbiekben nem jelentenek problémát.

13

2.3.2. Megvalósítások: hasonlóságok és különbségek A relációs adatbázis-kezelı rendszerek elvét számos adatbázis-kezelı programban

megvalósították. Az alapok (lévén szó koncepcióról, amit egy szabvány is kiegészít) minden esetben hasonlóak (az adatok tárolásának módja, a táblák kezelésével kapcsolatos mőveletek köre, stb.), de természetesen számos eltérés is megfigyelhetı. A következıkben (a teljesség igénye nélkül) az ismertebb (vagy a történetiség végett fontosabb) relációs adatbázis-kezelı rendszerek néhány jellemzı sajátosságát tekintjük át. Ezek a konkrét gyakorlati megvalósítások elvek, módszerek, ötletek – nem állítjuk, hogy egyik vagy másik jobb vagy rosszabb lenne a többinél: különbözı megközelítések léteznek, biztosítva ezzel a választás lehetıségét.

A dBase (és családja, a különbözı Clipper változatok) sokáig az asztali számítógépek szinte kizárólagos adatbázis-kezelı rendszerének számított. Jelentıségét (jellegzetes karakteres felületén túl) az adja, hogy mind a mai napig számos intézmény használja nyilvántartásai kezelésére. Elsıdlegesen programozási eszköznek tekinthetı, a közvetlen adatkezelési mőveletek elvégzésére rendelkezett ugyan egy parancsértelmezıvel (azaz kiadhattunk parancsot az adatbázis-kezelınek, amelyet az értelmezett és azonnal végre is hajtott), de ennek mőveletvégzési képessége korlátozott volt a programok nyújtotta lehetıségekhez képest (a dBase III Plus-ban debütált menüvezérelt kezelıfelület (ASSIST) sem nyújtott teljesen szabad kezet a felhasználónak – azonban ezt már jóval kényelmesebben tette...).

További érdekessége a dBase filozófiájának, hogy az adatbázis logikai egységét az adatokat tartalmazó fizikai állományok elhelyezkedése határozta meg: minden adattáblát külön állományként mentett el (a hozzá kapcsolódó segédtáblákkal: indexekkel, képernyıképekkel, szőrıkkel együtt), az egy adatbázist alkotó állományok pedig (általában) egy könyvtárba kerültek. A IV-es változattól támogatja az SQL szabványt, az V-ös változattól rendelkezik teljes grafikus felülettel, jelenleg (a jegyzet írásakor) aktuális változata a dBase Plus, amely már tartalmaz objektum-orientált fejlesztıeszközöket is.

Az Oracle története tulajdonképpen megegyezik a relációs adatbázis-kezelés történetével: az elsık között megjelent adatbázis-kezelı program jelenlegi (Oracle 9i) változata (egyes felmérések szerint6) ma is piacvezetı ezen a területen. Az Oracle specialitása is a tárolási szerkezet kezelésében keresendı: a logikai (a felhasználó által érzékelhetı) adattárolást fizikai szinten (a számítógép adatkezelési eljárásainak szintjén) további részekre bontja (táblaterületekre, adatblokkokra, szegmensekre), amelyek segítségével a többi rendszerhez képest lényegesen nagyobb szabadsággal alkalmazhatók a legkülönbözıbb hozzáférési és jogosultsági beállítások, továbbá ez a megoldás támogatja a jelenleg leghatékonyabb fürtözési technikát (a fürtözést az elosztott adatbázisok használják, a technológia lényege, hogy a kéréseket különbözı számítógépek dolgozzák fel, így egy idıben jóval több mővelet végezhetı).

A Microsoft mindjárt két adatbázis-kezelést támogató megoldással is igyekszik felvenni a versenyt a piac többi szereplıjével: az MS SQL Server elsıdlegesen a nagymérető adatbázissal, sok tranzakciós igénnyel rendelkezı felhasználók kiszolgálója, az MS Access pedig (az Office programcsomag részeként) az irodai illetve az otthoni felhasználók számára biztosít kényelmes lehetıséget az adatbázis-kezeléssel kapcsolatos egyszerőbb tevékenységek elvégzéséhez. (A késıbbiekben az Access jellemzıit részletesen meg fogjuk vizsgálni.)

Végül, de nem utolsó sorban meg kell említeni a MySQL nevő adatbázis-kezelı környezetet, amely (nem egyedülálló módon, de a hasonló programok közül talán ez a legelterjedtebb, legismertebb) legjellemzıbb különbsége az elızıleg bemutatott adatbázis- 6 IDC jelentés az adatbázis-kezelık elterjedtségérıl: http://www.oracle.com/ip/index.html?database1.html

14

kezelıkhöz képest, hogy ingyenes. A másik érdekessége, hogy számos operációs rendszerhez készült belıle változat (a jelenleg aktuális, 4.0 verziójú változatát több, mint 10 különbözı operációs rendszeren futtathatjuk a közismertektıl a legegzotikusabbakig) , így általánosságokat nehéz róla megfogalmazni.

2.3.3. Az SQL szabvány A relációs adatbázis-kezelés történetének talán legnagyobb hatású, és az ilyen jellegő

alkalmazások elterjedésében nagyon fontos szerepet játszó tényezıje az, hogy a számtalan gyártó és egyéni elképzelés ellenére sikerült egy egységes, mindenki számára alapul szabvánnyá alakítani az adatkezeléssel kapcsolatos tevékenységeket és az ezek megoldásához kapcsolható feladatok körét.

Mi is az az SQL?

A Structured Query Language (strukturált lekérdezı nyelv) egy nyitott szabvány, a relációs adatbázisokkal való kommunikáció nyelve.

„Ereje” abban áll, hogy az adatbázis-kezelı rendszerek összes jelentıs gyártója elfogadta és megvalósította saját rendszerében, így azt mondhatjuk, hogy az SQL az összes (!) relációs adatbázis-kezelı rendszer közös nyelve! Az, hogy egy szabvány nyitott, azt jelenti, hogy egyetlen cég sem birtokolja (formailag az ANSI (Amerikai Szabványügyi Hivatal) tulajdona), így minden cég szabadon felhasználhatja a saját alkalmazásaiban – ami legalább akkora elıny (ha az elıbb említett „közös nyelv” jelleget nézzük), mint hátrány (ha figyelembe vesszük azt, hogy az egyes gyártók igyekeznek mást (többet) nyújtani a saját programjukban, mint a konkurencia, így az SQL-t is átalakítják (kibıvítik) a saját megvalósításukhoz illeszkedı módon – ami viszont már semmi mással nem kompatibilis, így aztán tulajdonképpen beszélhetünk PL/SQL-rıl, Access SQL-rıl, stb.)

Habár a elnevezés alapján jogosan következtethetnénk arra, hogy az adatkezeléssel kapcsolatos feladatok közül csak a az adat-visszakereséssel kapcsolatos mőveleteket támogatja, ennél lényegesen általánosabb: az adatbázis-kezeléshez kapcsolódó valamennyi tevékenységre vonatkozóan (adatfelvitel, törlés, módosítás, stb.) tartalmaz utasításokat.

Az SQL parancsnyelv (nem fejlesztı környezet és nem programozási nyelv): a formailag kötött szabályoknak eleget tevı utasítást minden esetben az adatbázis-kezelı dolgozza fel. Minden SQL utasítás valamilyen (az elvégzendı mőveletet meghatározó) kulcsszóval kezdıdik, ezt követi a mőveletben érintett adatok pontos meghatározása, feltételek, módosítók, stb. megadása, és végül az utasítást minden esetben pontosvesszı zárja le. Az egyszerőség (és a célszerőség) végett az SQL kulcsszavai az adott tevékenység jellemzı angol kifejezésével egyeznek meg, ami nagymértékben megkönnyíti a nyelv elsajátítását:

SELECT név, lakcím FROM dolgozó ORDER BY születés;

- ennek az utasításnak eredményeként kapunk egy listát, amely a „dolgozó” nevő táblában nyilvántartott rekordok „név” és „lakcím” tulajdonságait „születési idı” szerint rendezve jeleníti meg.

Az SQL szabványosítására 1986-ban került sor, azóta azonban többször is változtattak a szabványban foglaltakon, így újabb és újabb SQL verziókról beszélhetünk: SQL1 (1986, más források szerint 1989 – ez utóbbi a szabvány nyilvánossá tételének éve), SQL2 (1992), SQL3 (1999). (A gyakorlatban a mai adatbázis-kezelık túlnyomó részt még mindig az SQL2 szabványban megfogalmazott elveket valósítják meg.)

Az SQL nyelv utasításkészletének részletes leírását a melléklet tartalmazza.

15

2.4. Adatbázisok szerepe a vállalkozás életében Ahogy azt már az eddigiek során is láthattuk, az elektronikus nyilvántartások illetve a

különbözı adatbázisok hatékonyan támogathatják bármely vállalkozás vagy szervezet ügymenetét. Ide tartoznak a különbözı gazdasági jellegő bizonylatok (számlák, szállítólevelek, pénzfelvételi bizonylatok, bérjegyzék, stb.), de ide tartozik a raktárkészlet nyilvántartás, a gépjármővek menetlevelei, a különbözı szerzıdések, a személyi kartonok, a munkáltatói kölcsön folyósításának bizonylatai vagy a jogszabály-győjtemények és még hosszasan lehetne folytatni a sort. Az esetek túlnyomó többségében a szervezetek rendelkeznek valamilyen (általában több különbözı...) nyilvántartással, a kérdés csupán az, hogy ezek használata mennyire nevezhetı hatékonynak vagy célszerőnek? A gyakorlat és a tapasztalat azt mutatja, hogy mind a mai napig elterjedtebbek a papír alapú nyilvántartások, néhol alkalmasint kiegészülve elektronikus adattárakkal - jellemzıen a kétféle nyilvántartási rendszert párhuzamosan vezetve.

2.4.1. Papír-alapú nyilvántartások és elektronikus adattárak Elsı lépésként vizsgáljuk meg, milyen elınyei és hátrányai lehetnek a hagyományos

(papír alapú) és az elektronikus nyilvántartások használatának!

Ami a hagyományos nyilvántartásokat illeti, a legfontosabb elınyös tulajdonságuk az, hogy már eleve adottan léteznek: számlákat ki kell állítani, a bérjegyzéket oda kell adni a dolgozónak, a Magyar Közlönyt a megjelenés másnapján hozza a Posta, és így tovább. Ennek köszönhetıen – és annak, hogy ezeket a nyilvántartásokat használja is a szervezet nap mint nap –, használatukhoz nem szükséges a meglévık mellett új ismeret: a munkatársak ismerik azokat a szabályokat, amelyek az adott dokumentum elkészítésével, kezelésével, tárolásával kapcsolatosak, nincs szükség (át)képzésre, betanításra. Nincs szükség új rendszer kidolgozására, fejlesztésre és az ezzel kapcsolatos beruházásokra, az ilyen nyilvántartások használatának (látszólag! – erre még késıbb visszatérünk) nincs jelentıs költségvonzata.

Másik nagyon fontos jellemzıje a papír alapú dokumentumok kezelésének a hitelesség kérdése. Az aláírás, a cégszerő bélyegzı és hasonló egyértelmő azonosítók használata elfogadott – a hasonló szerepet betölteni hivatott digitális azonosítási rendszerekkel7 szemben (egyelıre) erıteljes tartózkodás figyelhetı meg (dacára a törvényi szabályozásnak és számos mőködı gyakorlati példának – gondoljunk csak az elektronikus banki szolgáltatások gyarapodó körére – és annak a közgazdasági ténynek, hogy a (tisztán) elektronikus kereskedelem évrıl évre jelentıs forgalomnövekedést produkál szerte a világban....).

Ami az elektronikus nyilvántartások használata mellett szól, az mindenekelıtt a gyorsaság és megbízhatóság. Ahogy azt az eddigiekbıl is láthattuk, adatbázis használatával csökkenthetı az emberi hibákból adódó pontatlanság, a számítógép lényegesebben gyorsabban képes elıkeresni a kérdéses adatot, mint az irattáros tenné. Nem lebecsülendı tényezı a helyigény: papír alapú dokumentumok évekre (adott esetben évtizedekre) visszamenıleg történı tárolásához, archiválásához lényegesen nagyobb helyre van szükség, nem szólva az archivált információ szükségessé válásakor jelentkezı kísérı tevékenységekrıl...

Ahogy azt már a különbözı nyilvántartások általános jellemzıinél említettük, az elektronikus nyilvántartások többszintő biztonsági rendszerrel garantálhatják az adatok biztonságát (tartalmi helyességet biztosító megoldások (inkonzisztencia megelızése), ellenırzött hozzáférés (jelszavak, adatonként változtatható hozzáférési jogosultság), titkosítás,

7 A különbözı digitális biztonsági megoldásokkal az „Adatvédelem, adatbiztonság” c. modul foglalkozik részletesen.

16

a felhasználói tevékenységek visszakövethetı módon történı feljegyzése („naplózás”), automatizálható biztonsági másolatok készítése, stb.).

Ami pedig a költségeket illeti: képzeljünk el egy teljesen elektronikus nyilvántartó rendszert (olyat, ahol az adatok, információk, dokumentumok kizárólag számítógépen léteznek): ez esetben nincs szükség nyomtatóra (beszerzés, üzemeltetési költség, karbantartás, tartozékok...) és papírra! (Egyes elemzések szerint egy közepes vállalatot tekintve az éves papírfelhasználás költsége milliárdos nagyságrendet elérı összegre tehetı – ha emlékszünk még az elıbbiekben elınyként emlegetett alacsony üzemeltetési költségre...)

Mint az a fenti (kiragadott) példákból is kiderül, a két módszer egyike sem tökéletes, mindkettı rendelkezik számos elınyös és számos hátrányos tulajdonsággal. A hagyományos nyilvántartások vonatkozásában mindig is ott lesz az „emberi tényezı” (tévesztünk, felejtünk, elveszítünk dolgokat, stb.), míg a másik oldalon a rendszer kialakításának (általában jelentıs) költsége mellett ott van a felhasználók felkészültségének kérdése (tovább- vagy átképzések szükségessége; bizalmatlanság az új technológia iránt) – olyan gazdasági, humánpolitikai, szervezési, stb. kérdések ezek, amelyeket csak gondos felkészülés, elızetes elemzések, különbözı tervek és alternatív lehetıségek mérlegelésével lehet érdemlegesen megválaszolni. Az adatbázis-kezelés kérdésköréhez olyannyira hozzátartozik a tervezés, hogy már az elıkészítés során sem nélkülözhetjük!

2.4.2. Igények az adatbázissal szemben: tervezés, k ialakítás, üzemeltetés

Mindezek után már csak az a kérdés, melyek azok a szempontok, amelyeket érdemes figyelembe venni a tervezés során? Ehhez elıször is gondoljuk végig, hogy (eddigi ismereteink alapján) milyen lépéseken keresztül valósítható meg egy adatbázis-kezelı rendszer bevezetése8:

I. az adatbázissal szemben támasztott elvárások megfogalmazása (igények);

II. az adatbázis általános jellemzıinek meghatározása (nyilvántartott adatok köre, adatbázis felülete (beviteli képernyık, eredménylisták formátuma), kapcsolódó feladatok, felhasználók köre (szerepek és nézetek), biztonsági kérdések);

III. konkrét adatbázis-kezelı rendszer kiválasztása (lehetıségek);

IV. a II. pontban deklarált adatbázis megvalósítása a kiválasztott rendszerben (dokumentálás);

V. bevezetés (tesztelés, betanítás, felügyelet).

Elıször is tételezzük fel, hogy gondos mérlegelés (elsısorban valószínőleg gazdasági jellegő, de ahogy azt az elıbbiekben említettük, más szempontokat is figyelembe vevı) elemzés után úgy döntöttünk, adatbázist alkalmazunk az üzletvitel hatékonyságának növelésére.

Az elsı kérdés, hogy a bevezetésre kerülı rendszer valamely létezı nyilvántartásunkat hivatott kiváltani, vagy új nyilvántartás alapját képezi. Ez elsısorban azért fontos, mert létezı nyilvántartásról való áttérés során sokat segíthet abban, hogy a felhasználók elfogadják és hatékonyan alkalmazzák az elektronikus adattárat, ha annak felülete, megjelenése (a lehetıségekhez mérten) követi a papír alapú nyilvántartásban alkalmazott (megszokott) formai, elrendezési sajátosságokat. Célszerő továbbá összegyőjteni mindazokat a feladatokat (akár rendszeresen, akár elszórtan jelentkezı jellegőek), amelyek a nyilvántartásba bevonni

8 Egy informatikai rendszer kifejlesztése ennél lényegesen összetettebb feladat, a problémával az „Információs rendszerek” c. modul foglalkozik részletesen.

17

kívánt adatokhoz kapcsolódnak – és itt próbáljunk meg az adatok természetébıl adódó nyilvánvaló feladatokon túl minden lehetséges egyéb tevékenységet is végiggondolni: pl. a munkaügyi nyilvántartás a bérjegyzék kinyomtatása mellett alkalmas lehet statisztikai elemzések (mennyi idıt töltenek a munkatársaink szabadságon, melyek a legkedveltebb idıpontok) elkészítésére is...

Az elızıekbıl következik, hogy az adatbázissal szemben alapvetıen háromféle követelményt kell megfogalmaznunk:

1. milyen feladatai lesznek („dolgozói adatok felvitele”, „dolgozó törlése a nyilvántartásból”),

2. milyen felületet rendelünk az egyes feladatokhoz („dolgozók felvitelére szolgáló képernyı”, „aktuális dolgozó törlésére szolgáló parancsgomb (megerısítési kérelemmel)”), és

3. milyen formában várjuk az adatbázisban tárolt adatok elemzésével nyert információt („nyomtatott bérjegyzék”, „grafikon egy adott dolgozó távollétének megoszlásáról, havi bontásban”).

Említettük, hogy az SQL egy olyan eszköz a relációs adatbázis-kezelésben, amely a használt rendszertıl függetlenül lehetıséget biztosít az adatbázisban tárolt adatok elérésére, bizonyos mőveletek elvégzésére. Ezt felhasználhatjuk arra, hogy a tervezés során nem látható, „ad-hoc” problémák kezelésére alkalmas eszközzel ruházzuk fel az adatbázisunkat, ha lehetıséget biztosítunk közvetlen SQL parancsok kiadására. Így egy elıre nem látott feladat megoldásához nem kell az adatbázist módosítani, esetleg áttervezni: a kérdéses mőveletet megfelelı SQL utasítással közvetlen módon elvégezhetjük. Azonban ezzel az eszközzel is érdemes vigyázni: ne feledjük, hogy az SQL nem csak lekérdezési (adat-visszakeresési) parancsokat, hanem módosításra alkalmas parancsokat is tartalmaz – a használatához megfelelı biztonsági beállítások megléte is szükséges!

Ezek után meghatározzuk a lehetséges felhasználók körét, amibıl már következhet a feladat-felelıs összerendelés (azaz kinek melyik tevékenységgel kapcsolatban lesznek feladatai) – ez képezi az alapját a rendszer biztonsági beállításainak: jogosultságok meghatározása, az adatbázis védelme (mentések gyakorisága, másolatok száma, felhasználói tevékenységek naplózása, stb.).

A következı kérdés annak eldöntése, hogy a rendelkezésre álló adatbázis-kezelı rendszerek közül melyik lesz az, amely számunkra a leginkább megfelelı. Ebben az elıbb megfogalmazott feladatok és az adatbázis-kezelı lehetıségei, valamint a rendelkezésre álló számítógépes erıforrások köre és az adott rendszer igényei közötti összefüggések, megfelelések vagy ellentmondások segítenek. Meg kell vizsgálni, hogy a szóba jöhetı programok közül melyek rendelkeznek mindazon eszközökkel, ami képessé teszi ıket az általunk vázolt feladatok megoldására (tud grafikont készíteni? lehetıvé teszi az adatok törlését egy parancsgombon keresztül? van lehetıség az egyes felhasználók munkájának elkülönítésére, ellenırzésére?). Ezután jön az anyagi lehetıségek felmérése: milyen erıforrás-igénye van az általunk kiválasztott rendszernek, rendelkezünk-e olyan eszközzel (számítógéppel és megfelelı operációs rendszerrel), amely képes lesz futtatni – és ha nem, akkor a „bıvítés – új beszerzés – másik rendszer választása” lehetıségek közül melyik a legkedvezıbb.

Lényegében készen is vagyunk: a következı lépés már (az esetek túlnyomó többségében, és egy szervezeti szintő adatbázis esetében mindenképpen) számítástechnikai szakember(ek) bevonását igényli – láthattuk, hogy egy adatbázis-kezelı rendszer elkészítése elég összetett tevékenység. (Ez persze nem jelenti azt, hogy (némi gyakorlattal) ne

18

készíthetnénk el akár saját magunk is az adatbázisunkat: a jegyzet második felében a megvalósítás lépéseit, a gyakorlati módszereket járjuk körül és a végül képesek leszünk önállóan elkészíteni egy adatbázist – innentıl kezdve csak a lépték a kérdés...)

És végül ne feledkezzünk meg (már a tervezési szakaszban sem!) arról, hogy egy rendszer elkészítése nem egyenlı a program elkészítésével és feltelepítésével: a mőködés minden részletére kiterjedı leírás (a dokumentáció) a késıbbiek során (különösen, mikor egy-egy ritkábban használt szolgáltatást próbálunk mőködésre bírni...) nagy segítségünkre lehet, mint ahogy a dolgozóktól sem várhatjuk el, hogy egy új rendszer kezelésével („csak úgy!”) tisztában legyenek - segítség, képzés, bemutatás nélkül.

Ahogy a dokumentum-kezelésnek is (jó esetben) megvan a maga szabályzata, ugyanúgy az adatbázis-kezelés sem nélkülözhet bizonyos korlátozásokat. A felhasználói tevékenységek meghatározására külön nincs szükség – ezt (a tervezéskor meghatározott biztonsági beállítások érvényesítésével) az adatbázis-kezelınek kell megoldania –, azonban a mőködtetés során adódhatnak olyan problémák, amelyek túlmutatnak az adatokkal kapcsolatos mőveleteken és magának a rendszernek a beállításait érintik: a munkakörök változása miatt meg kell változtatni a jogosultsági rendszert, újabb felhasználó számára kell biztosítani a hozzáférést, biztonsági másolatot kell készítenünk az adatbázisról, az idıközben bekövetkezett fejlesztések miatt át kell a rendszerünket telepíteni egy másik helyre vagy számítógépre, esetleg bıvíteni szeretnénk az elektronikusan kezelt adataink körét, stb. Ezekre a feladatokra célszerő (megfelelı szakértelemmel rendelkezı munkatárs megléte esetén) külön embert kinevezni, ı lesz az adatbázis gazdája, karbantartója, adminisztrátora.

Hogyan tovább?

Az elektronikus nyilvántartási rendszerek, a saját adatbázisok használata számos elınyt hordoz. Az adatok elemzése alapján nyert információk segíthetnek a tervezésben (beszerzések ütemezése, költségek optimalizálása), de alapját képezheti az ügyfélkapcsolati rendszer hatékonyabb mőködtetésének (célzott megkeresések a vásárlói szokások alapján, tájékoztató az aktuális akciókról), stb. Az adatbázis használata során szerzett tapasztalatokat felhasználhatjuk az elektronikus üzletvitel kialakítására is: az adatbázisban tárolt adatokból egyszerően készíthetünk Internetes megjelenésre alkalmas felületet (honlapot), amely szolgálhat a partnerek vagy a vásárlók tájékoztatására, de alkalmas lehet elektronikus kereskedelmi szolgáltatások biztosítására is (Internetes katalógus, elektronikus rendelés vagy vásárlás), egyszerősíthetjük (és gyorsíthatjuk) a különbözı hivatalokkal folytatott kommunikációt – vagy csak hogy a napjainkban egyre nagyobb teret hódító mobil kommunikációs eszközök nyújtotta lehetıségekbıl is említsünk egy példát: (megfelelı technikai feltételek mellett) bárhol hozzáférhetünk az adatokhoz.

2.5. Összefoglalás Ebben a fejezetben az adatbázisokkal, az adatbázis-kezeléssel illetve az adatbázisok

gyakorlati jelentıségével kapcsolatos kérdéseket jártuk körül. Nem definiáltuk az adatbázis-kezelés valamennyi alapfogalmát, mint ahogy nem elemeztük az egyes (tárgyalt) fogalmak mélyebb összefüggését sem: a fejezet célja az volt, hogy megteremtse a következı fejezetben tárgyalásra kerülı gyakorlati feladatok megoldása során használt fogalomrendszer (elméleti) hátterét. Éppen ezért azt javasoljuk, ne haladjon addig tovább, míg az ebben a fejezetben szereplı alapfogalmak jelentésével nincs teljesen tisztában!

Reméljük, hogy a fejezet végére sikerült rávilágítani az elektronikus adatkezelésben rejlı elınyök némelyikére (természetesen nem szabad megfeledkezni ezen terület jellemzı veszélyforrásairól sem! – az elektronikus adatok védelmével kapcsolatos kérdések tárgyalása

19

azonban nem témája jelen jegyzetnek), bemutatni a legalapvetıbb elméleteket, a legelterjedtebb módszertanokat és az azok megvalósítását biztosító szoftvertermékeket.

Mindezen ismeretek birtokában pedig eséllyel kezdhetünk egy adatbázis tényleges kezeléséhez, a gyakorlati ismeretek elsajátításához.

20

3. Adatbázisok a gyakorlatban Az eddigiekben az adatbázis-kezeléssel, az adatbázis-kezelı rendszerek használatának

lehetıségeivel és feltételeivel ismerkedtünk meg. A következıkben az adatbázis-kezeléshez kapcsolódó gyakorlati tevékenységeket tekintjük át. A fejezet célja kettıs: részben néhány (hangsúlyozottan csak kiragadott – semmilyen szempontból nem rangsort vagy minısítést tükrözı!) példa alapján bemutatni a gazdálkodó szervezetek jellemzı tevékenységeihez kapcsolódó (létezı) adatbázisokat, részben megismertetni a saját adatbázisok készítésével és használatának kapcsolatos technikákat.

Természetesen jelen jegyzetnek nem célja (terjedelménél és szerzıi jogi vonatkozások miatt nem is lehet) konkrét (létezı) adatbázisok használatának és mőködésének részletes ismertetése. Ehelyett arra törekszünk, hogy bizonyos általánosságokra, hasonló jellemzıkre hívjuk fel a figyelmet.

3.1. A vállalkozásokra jellemz ı adattárak használata

3.1.1. Karakteres felület ő adatbázisok Aligha megkérdıjelezhetı tény, hogy a mindennapi gyakorlatban alkalmazott

adatbázisok túlnyomó többsége valamely gazdasági folyamat támogatására szolgál. Az elsı példánk a RoBit Bt. (www.robitbt.hu) kettıs könyvviteli rendszere. (3. ábra) A rendszer alapja egy dBase alapú adatbázis, ennek köszönhetı a karakteres megjelenítési felület. Mint azt korábban is említettük, a hasonló alkalmazások jelentıségét az adja, hogy mind a mai napig számos szervezetnél mőködnek ezen adatbázis-kezelı programcsalád valamelyik változatával készült adatbázisok, amelyek felülete és kezelése alapvetıen nem sok különbséget mutat.

3. Ábra – egy karakteres felülető adatbázis mőködés közben

A grafikus felülethez szokott felhasználók számára talán elsıre kissé szokatlan lehet a kezelése, de a menük elérésének megszokott módja (ALT + a kiemelt billentyő leütésével aktiválhatók az egyes parancsok), a képernyı alján látható billentyő-súgó nagyban megkönnyíti az ismerkedést.

A munkavégzésben az alkalmazás színkódolással segíti a felhasználót a tájékozódásban: az adatok bevitelére szolgáló mezıket színes háttér jelöli, a tájékoztatásul

21

szolgáló leírásoknak és a nem módosítható (számított) adatoknak nincs hátterük, míg a hibajelzések feltőnı piros alapon jelennek meg.

A program (természetesen) könyvvitellel kapcsolatos szinte valamennyi tevékenységhez nyújt támogatást, amelyeket olyan szolgáltatásokkal egészít ki (többféle kimutatás készítésének lehetısége, eredmények listázása képernyıre vagy nyomtatóra, stb.), amelyeket a korszerő, grafikus felülettel rendelkezı adatbázisoktól megszokhattunk – ami ékes bizonyítéka annak, hogy a különbözı relációs adatbázis-kezelı rendszerek által támogatott technológiák között nincsenek igazán nagy különbségek, legyen szó bármilyen felületrıl. (4. ábra)

4. Ábra – elérhetı szolgáltatások

Annak szemléltetésére, hogy az adatbázisok a szervezet minden tevékenységével kapcsolatba hozhatók, nézzünk meg még két ábrát (5. és 6. ábra), amelyen egy (szintén a Robit Bt-tıl származó) gépjármú útiköltség-elszámoló és útnyilvántartó adatbázist láthatunk. A szembetőnı hasonlóságok ellenére van egy jelentıs különbség az elızı és ezen adatbázis között: a felhasználói munka megkönnyítése érdekében nem csak az elıbb említett (gyorsbillentyő, használható billentyők leírása) eszközöket alkalmazza a felület, hanem lehetıvé teszi az egér használatát is – így kezelése immár tulajdonképpen semmiben nem különbözik egy teljesen grafikus felülető adatbázisétól.

22

5. Ábra – egy karakteres felülető adatbázis indító képernyıje

6. Ábra – adatbeviteli képernyı

3.1.2. Grafikus felület ő adatbázisok Természetesen léteznek (de még egyszer: nem feltétlenül korszerőbbek – legalábbis

ami az adatbázis-kezelés alapfeladatait illeti) grafikus felülettel rendelkezı adatbázisok is. (A legismertebb valószínőleg a KJK-KERSZÖV Jogi és Üzleti Kiadó Kft. Complex CD Jogtára, amely a grafikus felület mellett még egy szempontból mindenképpen figyelemre méltó: a hagyományos adatbázis-kezelés által használt adattípusok mellett teljes dokumentumok tárolását és kezelését is képes megoldani.)

Szintén csak a példa kedvéért álljon itt két ábra (7. és 8. ábra) egy grafikus felülető adatbázisról is, ez a Szintézis Informatikai Rt. EVA-nyilvántartó programja. A felület a grafikus alkalmazásoknál megszokott elemekbıl épül fel: a menüsor, a gyakrabban használt

23

tevékenységek közvetlen elérésére szolgáló nyomógombok, az egymást átfedhetı ablakok, a nyomtatás elıtt megtekinthetı nyomtatási lista bizonyára mindenki számára ismerıs.

7. Ábra – grafikus adatbázis szokványos kezelıfelülete

8. Ábra – nyomtatásra elıkészítve

3.2. A Microsoft Access adatbázis-kezel ı rendszer Mindezek után azt gondolhatnánk, hogy az adatbázisok készítése és használata

valamiféle komoly szaktudást igénylı tevékenység – de ez nem igaz! Az adatbázis szerkezetének meghatározása, a tervezés és optimalizálás valóban számos buktatót rejt, de ha

24

ezek az adatok rendelkezésre állnak (mit fogunk nyilvántartani, milyen szerkezetben, milyen mőveletek elvégzésére lesz szükség, stb.), akkor az adatbázis elkészítése a korszerő adatbázis-kezelı programok segítségével szinte gyerekjáték.

A gyakorlati ismereteket a Microsoft Office9 irodai programcsomag Access nevő adatbázis-kezelıjének a jegyzet készítésekor aktuális (MS Access 10.2627) változatán keresztül tekintjük át. Azért esett a választás erre a programra, mert az Office programcsomag többi komponense (pl. a Word és az Excel) viszonylag széles körben ismert, így jogosan tételezhetjük fel részint azt, hogy a felhasználók számára a program kezelıfelülete már ismerıs lesz (eszköztárak, ikonok, egyes menüpontok használata), másrészt azt, hogy a gazdálkodó szervezetek nagy részénél ez az adatbázis-kezelı program elérhetı, így nincs szükség újabb alkalmazás beszerzésére, telepítésére, beállítására. A teljességhez azonban hozzátartozik, hogy számos más korszerő és hatékony adatbázis-kezelı program is létezik (akadnak közöttük kereskedelmi forgalomban árusítottak és olyanok is, amelyek ingyenesen letölthetık az Internetrıl), az alapelvek ezekben a rendszerekben is megegyeznek, legfeljebb máshogy hivatkoznak az egyes elemekre, más menüben vagy más ikon segítségével oldható meg ugyanaz a feladat.

3.2.1. Általános jellemz ık Az MS Access egy grafikus felülető relációs elvő adatbázis-kezelı program és

fejlesztıkörnyezet. Ez egyrészt azt jelenti, hogy alkalmas adatbázisok készítésére és az abban tárolt adatokra vonatkozó mőveletek elvégzésére (rendezés, keresés, listázás, stb.), másrészt azt, hogy rendelkezik olyan eszközökkel, amelyek segítségével (akár az Access-tıl független) önálló adatbázis-kezelı programokat hozhatunk létre.

Elindítására a grafikus felülető operációs rendszereknél megszokott lehetıségek állnak rendelkezésre, alapértelmezés szerint a Start menü Programok csoportjában, a többi Office komponens mellett szerepel, ikonja egy (a használt verziótól függı: korábban sárga, az újabb változatokban bordó színő) kulcsot formát. (9. ábra)

9. Ábra – Az Access ikonja

Az Access használatával kapcsolatban meg kell említeni, hogy (az Office programcsomag más elemeitıl eltérıen) az Access egyes változatai nem kompatibilisek egymással: ez azt jelenti, hogy az adatbázis erısen kötıdik azon Access verzióhoz (változathoz), amely alatt létrehoztuk, más verzióval nem (pontosabban bizonyos átalakítások után, ezt nevezzük konvertálásnak, ld. késıbb) használható.

Az Access az adatbázis minden elemét (adatokat, táblákat, képernyıképeket, stb.) egyetlen állományban tárolja, amelynek (alapértelmezett) típusa (kiterjesztése) .mdb. Az adatbázis-kezelés során mindvégig ezzel az állománnyal fogunk dolgozni, bár a munkavégzés közben létrejönnek átmeneti információkat tartalmazó (segéd)állományok is.

Az elızıekbıl következik, hogy elsı lépésként meg kell határoznunk az adatbázist tartalmazó állomány helyét. Ez akkor is így van, ha még nincs adatbázisunk: ez esetben azt kell megadni, hogy hol fogjuk tárolni az adatbázis által hordozott információt. Ez a gyakorlatban azt jelenti, hogy (a szövegszerkesztésnél megszokott módszerhez képest kicsit

9 A jegyzet készítésekor az Office programcsomag alapvetıen kétféle változatban volt elérhetı kereskedelmi forgalomban, az Access csak az ún. „Professional” változatnak képezi a részét!

25

„fordítva”) elıször kell elmentenünk az adatbázisunkat és csak azután tudunk vele mőveleteket végezni! Az Access megkeresi a megadott állományt, megnyitja, az elvégzett tevékenységek eredményeként bekövetkezı változásokat pedig (legyen az egy újabb adat a nyilvántartásban vagy módosítás valamely korábban létrehozott listánk fejlécében) folyamatosan rögzíti ebbe az állományban. Ennek a kezelési filozófiának két (más rendszerekhez képest érdekes) „kísérıjelensége” van:

1. minden elvégzett (és jóváhagyott) mővelet automatikusan és azonnal mentésre kerül! – ez pedig nagymértékben korlátozza az „Utolsó mővelet visszavonása” parancs használhatóságát...

2. mivel a mentés (lényegében) automatikus, a „Mentés...” típusú mőveletek nem a teljes adatbázisra, csak annak (éppen aktuális) részére vonatkoznak! – ha az adatbázis (pontosabban az adatbázist hordozó állomány) jellemzıit (nevét, helyét, stb.) akarjuk megváltoztatni, akkor be kell zárnunk és állományként (valamilyen alkalmas állomány-kezelı program, mint pl. az „Intézı” vagy a „Saját gép) elvégezni a kívánt mőveletet – szemléletesen: ha az adatbázisomat lemezre (is) le szeretném menteni, akkor nem használhatom a „Mentés másként” parancsot...

Mindebbıl következik, hogy az Access elindítását követıen a megjelenı tevékenység-listában az adatbázist tartalmazó állomány elhelyezkedésével kapcsolatos információkat kell megadni: megnyithatjuk a legutóbb használt adatbázisainkat (amennyiben nem szerepel a felsorolásban, úgy a tallózás segítségével megkereshetjük) vagy létrehozhatunk új adatbázist. Ez utóbbi esetben két lehetıségünk van: ha teljesen önállóan szeretnénk elkészíteni az adatbázisunkat, akkor válasszuk az „üres adatbázis”-t, de válogathatunk az Access sablonjaiból is: ezek olyan elıre elkészített adatbázisok, amelyek egy jellemzı tevékenységkörhöz kapcsolódóan tartalmazzák az adatok tárolására szolgáló táblákat és a legáltalánosabb beviteli és megjelenítési eszközöket – nekünk csak az adatfeltöltés és a használatba vétel marad. (Ez utóbbi „adatbázis-vázlatok” segítségével is megismerkedhetünk az Access elemeivel és a velük kapcsolatos mőveletekkel, de az Access tartalmaz egy teljesen kidolgozott és feltöltött minta-adatbázist is (a Nortwind üzletház nyilvántartásával), ami elérhetı a Súgó menü „ Mintaadatbázisok” parancsán keresztül).

A továbbiakban – annak érdekében, hogy minden fontos tevékenységgel megismerkedhessünk – egy új, üres adatbázison keresztül mutatjuk be az Access mőködését.

Még egy megjegyzés: a munkavégzés során az Access minden objektumhoz külön ablakot rendel: a legkülsı tartozik az Access programhoz, a következı az egész adatbázist reprezentálja (címsorában az adatbázis neve olvasható), valamint minden megnyitott adatbázis-komponens (az egyes táblák, a listák, a beviteli képernyık, stb.) külön ablakban jelennek meg – fokozott odafigyelést igényel tehát, hogy átlássuk, mikor melyik ablak az aktív, illetve hogy az ablak bezárása melyik objektumot zárja be!

3.2.2. Felépítés: munkaterületek, m őveletek Access az adatbázis minden jellemzı tevékenységéhez (tárolás, mőveletvégzés,

megjelenítés) külön objektumokat rendel. Az azonos típusú objektumok egymástól elkülönített részeken, úgynevezett munkaterületeken tárolódnak. A munkaterületek mind a felépítésükben, mind a használatukban közös jellemzıkkel rendelkeznek. (10. ábra)

26

10. Ábra – Az Access munkaterületei

Az adatbázis-ablak bal felsı sarkában (az ábrán piros körrel jelölve) az adott munkaterületre vonatkozó négy alapmővelet ikonja szerepel: a Megnyitással egy már létezı objektum tartalmát jeleníthetjük meg (pl. magukat az adatokat), a Tervezéssel az adott objektum szerkezetéhez férünk hozzá (ez objektumonként más és más lehet: adatok esetében pl. a típusok, egy lekérdezésben a lekérdezés eredményét meghatározó parancsok, stb.), az Új ikon segítségével hozhatunk létre újabb objektumot, végül a Törléssel – természetesen – eltávolíthatjuk a felesleges objektumainkat. A mellettük szereplı ikonok (ismerısek lehetnek az állomány-kezelı alkalmazások eszköztárából) az objektumok megjelenítésével kapcsolatos lehetıségeket tartalmazzák: kisebb vagy nagyobb mérető ikonok jelképezzék az egyes objektumokat, vagy minden objektumról részletes leírás jelenjen meg.

A munkaterületen (az ablak jobb oldali része, az ábrán kékkel szegélyezve) jelennek meg az adott típusú adatbázis-komponensek. A lista automatikusan ábécé szerint növekvı sorrendben tartalmazza az objektumokat és kezelésében az állomány-kezelık könyvtár (mappa) fogalmával mutat rokon vonásokat: egy munkaterületen belül nem lehet 2 azonos nevő objektum, az objektumokat az állományoknál megszokott módon törölhetjük vagy nevezhetjük át (DEL billentyő vagy az elıbb említett ikon, illetve a kijelölt objektumon történı egyszeres kattintás vagy az F2 billentyő lenyomása). Az egyetlen kivétel a másolás mővelete: a munkaterületek sajátosságai (ti. hogy minden munkaterület csak egyetlen adott típusú objektumot tartalmazhat) miatt objektumot csak munkaterületen belül másolhatunk (duplikálás) – ezt megtehetjük a vágólapon keresztül (Másolás és Beillesztés, a Szerkesztés menü vagy az eszköztár ikonjai használatával), vagy vonszolással (a kérdéses objektumot a munkaterület egy üres részére húzzuk az egérrel a CTRL billentyő nyomva tartása mellett.)

A munkaterületek eredendıen is tartalmaznak objektumokat, ezek azonban nem tényleges elemek az adatbázisban, hanem az Access által nyújtott szolgáltatások: bizonyos gyakran használt tevékenységet elıre programozott eszközök (ún. varázslók) segítenek – használatukkal az adatbázis-kezelés mélyebb ismerete nélkül is megoldhatunk egyszerő feladatokat. (A vázolt elvek megértésének érdekében az adatbázis-kezelési feladatok megoldása során csak kevésszer fogunk varázslót használni, de az egyéni felkészülés során ajánlott velük megismerkedni.)

Az egyes munkaterületek között a baloldali lista megfelelı nyomógombjára kattintva váltogathatunk. Fontos: a munkaterület váltása nem zárja be az adott munkaterület nyitott objektumait (a munkaterületünk változatlan állapotban marad, csupán egy másik munkaterület tartalma jelenik meg), és nyitott objektumokkal bizonyos mővelet nem végezhetık el – tehát ha

27

befejeztük az adott munkaterületen a tevékenységet, lehetıleg zárjuk be a használt objektumokat!

Az Access által alkalmazott munkaterületek és szerepük:

Tábla: az adattáblák tárolására szolgáló munkaterület. Feladata a tárolási szerkezet (a táblák, az adattípusok) meghatározása, az adatok tárolása és megjelenítése, de támogatja az adatbevitelt és egyszerőbb keresési-rendezési feladatok elvégzését is.

Lekérdezés: az adatokkal mőveletet végzı komponenseket (ezek a lekérdezések) tartalmazó munkaterület. Az adatbázis-kezelés szinte minden (nem tárolás jellegő) mővelete elvégezhetı lekérdezéseken keresztül: rendezés, kiválogatás, módosítás, törlés, számítási feladatok, listakészítés.

Őrlap : az adatbázis megjelenése, felülete: a (felhasználói) munkavégzés eszköze. A grafikus felület hordozta számos vezérlıelem (legördülı listák a választáshoz, jelölıgombok az igen/nem típusú információ meghatározásához, stb.) segítségével az új adatok felvitelét és a tárolt adatok módosítását lényegesen egyszerőbben oldhatjuk meg, mintha közvetlenül a tábla tartalmát kellene kezelnünk.

Jelentés: az adatok nyomtatott megjelenítésének az eszköze. Bár az adatbázis összes komponense nyomtatható közvetlenül (a Fájl menü Nyomtatás parancsa segítségével), a jelentések használatával egyedi („testre szabott”) nyomtatási képet alakíthatunk ki.

Adat(elérési) lap: az adatbázisnak az Interneten történı megjelenítésére szolgáló eszközöket tartalmazó munkaterület. Az adat(elérési) lapok segítségével az adatbázis-kezelés szinte valamennyi mőveletének elvégzésére alkalmas weblapokat hozhatunk létre: adatbevitelt és módosítást támogató oldalt (ld. őrlapok), az adatokat különbözı szempontok szerint rendezve, csoportosítva megjelenítı oldat (ld. lekérdezések) vagy akár a nyomtatott változattal megegyezı megjelenéső képernyıképet (ld. jelentések).

A makrókkal és a modulokkal pedig egyéni igényeinkhez igazodó eszközökkel bıvíthetjük az Access mőveletvégzı képességét: a makrók elıre definiált (beépített) mőveletek, amelyeket tetszés szerint csoportosítva automatizálhatjuk bizonyos feladatok megoldását, a modulok segítségével (programozási ismeretek birtokában) további (pl. az Access-ben nem megvalósított) mőveleteket definiálhatunk.

Látható, hogy az Access meglehetısen széles eszközkészletet biztosít a felhasználó számára, hogy minél egyszerőbben kezelhesse adatait. A következıkben az adatbázis-kezelés alapfeladatainak megismerése közben szemügyre vesszük a leggyakrabban használt munkaterületek és objektumok kezelésének lehetıségeit. A munkaterületek általános jellemzıinél említettük, hogy az egyes munkaterületek jellem

3.3. Adattárolás

3.3.1. A táblák Adatbázis nem létezhet tárolt adatok nélkül, és ahogy azt már korábban megjegyeztük,

a relációs elvő adatbázis-kezelı rendszerekben az adatok tárolásának eszközei az adattáblák. Ahhoz, hogy az adatbázisunkban tárolni tudjuk az adatainkat, elsı lépésben ki kell alakítanunk a megfelelı táblaszerkezetet (emlékezzünk: ez adott esetben komoly elızetes elemzési munkát feltételez!). A tábláinkkal kétféle módon jeleníthetjük meg, az egyes megjelenítési módokat a tábla nézetének nevezzük. Amikor a táblában tárolt adatokat látjuk, a táblánk adatlap nézetben jelenik meg, amikor pedig a tábla szerkezetével (a táblázat oszlopainak jellemzıivel) kapcsolatos információkat látjuk, a táblázat tervezı nézetben van.

28

Amikor megnyitunk egy táblát, a menüsor alatt megjelenı elsı eszköztárban10 a baloldali elsı ikon, a nézetváltó (vegyük észre mellette a lefelé mutató háromszöget! – ha erre kattintunk, egy legördülı listában megjelennek a választási lehetıségeink) szolgál az egyes nézetek közötti átkapcsolásra.

11. Ábra – a nézetváltó mőködés közben

Ha új adattáblát akarunk létrehozni (emlékezzünk: a munkaterület bal felsı sarkában vannak az objektumok kezelésével kapcsolatos parancsgombok!), akkor az Új parancsgomb hatására megjelenı lista szerint többféle lehetıségünk van:

� adatlap nézetben maguknak az adatoknak a megadásával hozzuk létre az adattáblánkat: az Access biztosít egy (alapértelmezés szerint 10 oszlopból és 20 sorból álló) táblázatot, az egyes mezıkbe írhatjuk be a tárolni kívánt adatainkat. Bár látszólag gyors és kényelmes módszerrıl van szó, amennyiben így hozzuk létre az adattáblát, a késıbbiekben számos többletfeladat elvégzésére lesz szükség. (Például gondoljuk végig, hogy a „Mezı1”, „Mezı2”, stb. oszlopnevek mennyire „beszédesek”, mennyire utalnak a tartalmukra, ha valamelyikre hivatkozni akarunk...);

� hasonló a helyzet a varázsló alkalmazása esetén is (az elızı változatnál is az Access „találja ki” – pontosabban bizonyos elıre definiált szabályoknak megfelelıen határozza meg – az egyes tulajdonságok (oszlopok) jellemzıit, és a varázsló is kész minta alapján dolgozik, a különbség „csupán” annyi, hogy a varázsló bizonyos típusfeladatokra vonatkozóan konkrét alapértelmezésekkel rendelkezik (pl. egy személyi nyilvántartásban kell lennie „Név”, „Irányítószám”, „Város”, stb. mezıknek);

� az importálás és a hivatkozás már számítógépen (de nem feltétlen adatbázisban, bár ez sem kizárt) tárolt adatok elérésére szolgál, az importálás „átemeli” az adatainkat az eredeti helyükrıl az adatbázisba, a hivatkozás esetében az adatok megmaradnak az eredeti helyükön (így nem történik duplikálás), de ugyanúgy tudok velük mőveletet végezni, mintha az adatbázisban ebben az adatbázisban tárolódnának;

� végül tervezı nézetben, amikor az adattábla valamennyi jellemzıjét magunknak kell megadni – ez az ellenkezıje az adatlap nézet segítségével történı táblalétrehozásnak, de mivel jobban követi az adatbázis-kezelés filozófiáját (elıször a tervezés és csak utána az adatkezelés) és (talán) a felhasználói logikát (elıször a helyrıl kell gondoskodnunk, ha el akarunk tárolni valamit...) is,

10 Az Access nagyon sok helyen használ környezet-érzékeny vezérlı elemeket: ez azt jelenti, hogy az egyes menüben megjelenı parancsok listája, az eszköztárban szereplı ikonok, az egyes parancsok használhatósága, stb. attól függ, hogy az adatbázisunknak éppen mi az aktív (kiválasztott) eleme. Ezért ne lepıdjünk meg, ha idınként más elemek jelennek meg (vagy ismerısök tünnek el) – ez nem hiba, csupán azt jelenti, hogy az adott esetben annak a mőveletnek úgysem lenne értelme, hatása. Próbáljunk meg munka közben odafigyelni arra, hogy melyik mőveletet mikor alkalmazhatjuk!

29

valamint lehetıvé teszi a tábla szerkezetének megismerését, ezzel a módszerrel ismerkedünk meg.

Tervezı nézetben a táblázat tulajdonságait (emlékezzünk, gyakorlatilag az oszlopokról van szó!) kell meghatároznunk. A relációs adatbázis-kezelés alapelveinek megfelelıen ez azt jelenti, hogy különbözı nevet kell adnunk a táblázat valamennyi oszlopának és minden oszlophoz meg kell határozni azt, hogy az oszlop milyen jellegő (típusú) adatokat fog tartalmazni. Ezen túl minden oszlophoz rendelhetünk egy leíró részt (magyarázat vagy emlékeztetı) és néhány tartalmi vagy formai beállítást.

A tervezı nézetben megjelenı háromoszlopos táblázat egyes sorai a (majdani) adattáblánk egy-egy oszlopának információját tartalmazzák. Az elsı oszlopba (Név) az adattábla oszlopnevei kerülnek (az Access viszonylag szabadon bánik az azonosítókkal, az oszlopok nevében a pont (.), a felkiáltójel (!) és a szögletes zárójelek ([]) kivételével szinte bármi lehet, de – gondolva a késıbbiekre, amikor majd hivatkozni szeretnénk ezekre az azonosítókra – célszerő rövid, de a tartalomra utaló neveket adni, és bár nem tilos, de nem is szerencsés a névben a szóköz használata, ha több szóból álló azonosítót adunk, használjunk aláhúzást (_) az egyes szavak elválasztására, pl. „Gyerekek_száma”)

A tervezırács második oszlopában (Típus) az adattábla megfelelı oszlopának (tulajdonságának) típusát kell kiválasztani (megint egy legördülı lista!). Az Access számos beépített típussal rendelkezik, de ezeken túl további (felhasználó által definiált) típusok használatára nincs lehetıség (az esetek többségében szükség sem). Minden tulajdonsághoz kötelezı típust rendelni. Az oszlop típusa határozza meg, hogy az adattáblában ezekbe a mezıkbe milyen értékek vihetık be. Az adott tulajdonság típusának kiválasztását követıen a szerkesztırács alatt a (Mezıtulajdonságok) lehetıség nyílik további jellemzık megadására.

A tervezırács harmadik oszlopát (Leírás) nem kötelezı kitölteni, ide írhatók azok a megjegyzések, amik az adott oszloppal kapcsolatosak – amennyiben kitöltjük, a felhasználás során, amikor a kurzor egy, az adott oszlophoz tartozó mezıben tartózkodik, a munkaterület alatt (az ablak alsó szürke keretében, az ún. Státusz-sorban) megjelenik ez az információ.

3.3.2. Adattípusok Az adatbázis-kezelı rendszerek szigorúan tipizált alkalmazások, ami azt jelenti, hogy

valamennyi tárolt adatot be kell tudniuk sorolni valamely általuk ismert típusba – azaz egyértelmően eldönthetınek kell lennie, hogy a mezıben szereplı bető, számok, egyéb jelek az adott mezıben szöveget, számot, dátumot stb. jelentenek. A relációs adatbázis-kezelés alapelveinek tárgyalásakor említettük, hogy a típusokat nem az adatokhoz, hanem az egyes attribútumokhoz kell hozzárendelni, a továbbiakban az adott oszlopba csak és kizárólag az oszlop típusának megfelelı jellegő adat vihetı be. Ahhoz, hogy meg tudjuk határozni, hogy melyik tulajdonsághoz milyen típust célszerő választani, ismernünk kell az egyes típusok jellegzetességeit.

A szöveges típusok az adatbázis-kezelés legáltalánosabban használható típusai. Az ilyen típussal megjelölt tulajdonság mezıibe bármilyen karaktert bevihetünk, azaz az ilyen típusú adatban szerepelhetnek betők, számok, írásjelek, speciális szimbólumok, stb.

Az Access három szöveges jellegő adattípust különböztet meg:

1. Szöveg: maximális mérete 255 karakter (alapértelmezett mérete 50 karakter, a típus kiválasztása utána a „Mezıtulajdonságok” elsı, „Méret” nevő jellemzıjénél lehet megadni ettıl eltérı értéket),

2. Feljegyzés: maximális mérete 64 K (azaz 65 535 karakter),

30

3. Hivatkozás: maximális mérete 2048 karakter – érdekessége, hogy tartalma szabályos Internet cím lehet, amelynek tárolása szövegként történik, de ezt a tárolt szöveget az Access értelmezi: az ilyen típusú mezıbe írt adatok az Internetes böngészı programok linkjeihez hasonló módon mőködnek – azaz segítségükkel lépegethetünk különbözı elemek között.

Az adatbázis-kezelı rendszerekben a számok tárolására általában nem egyetlen típus szolgál: (kezelési és tárolási szempontok miatt) szokás megkülönböztetni pl. az egész és a valós értékek tárolására szolgáló adattípusokat. Az Access ezen a téren is számos lehetıséget biztosít, azonban az eltérı jellegő számértékek tárolására szolgáló típusok az Access filozófiája szerint nem önálló adattípusok, hanem valamennyi a Szám típus módosulása (altípusa), ami a beállításukkal kapcsolatos plusz feladatban nyilvánul meg: Szám típusú tulajdonság létrehozásához:

1. a „Típus” oszlopban ki kell választani (a legördülı listából) a „Szám” bejegyzést,

2. majd a „Mezıtulajdonságok” között a „Méret”-nél (ugyancsak legördülı listából) kiválasztani a megfelelı szám-altípust!

Az egyes altípusok között eltérés van adatok tárolásának méretében és módjában, valamint minden típushoz tartozik egy értéktartomány: az adott típusú tulajdonság mezıibe csak olyan adatok vihetık be, amelyek ebbe a tartományba esnek. A szám típusú mezıkbe csak helyesen felírt (értelmezhetı) számok szerepelhetnek, ez pedig azt jelenti, hogy egy szám típusú mezıbe a következı karakterek vihetık be: számjegyek (0-9), a tizedes elhatároló szimbólum (tizedespont (.) vagy tizedesvesszı (,) – a használt operációs rendszer területi beállításától függıen), elıjelek (pozitív (+) vagy negatív (-)) és az „E” szimbólum (ez a számok tudományos- vagy normálalakjának felírásakor használt szimbólum a 10 megfelelı hatványával való szorzást jelent: 1,25E5 = 1,25 x 105 = 125 000).

Az Access által támogatott numerikus (Szám) altípusok a következık:

1. Bájt: tárolása 1 bájton történik, értéke 0 – 255 közötti egész szám lehet,

2. Egész: 2 bájt, értéke -32 768 és +32 767 (-215 – +215-1) közötti egész szám lehet,

3. Hosszú egész: 4 bájt, értéke hozzávetılegesen -2 milliárd és +2 milliárd (pontosan -231-tıl +231-1-ig) közötti egész szám lehet,

4. Egyszeres: 4 bájt, értéke -3,4x1038 és +3,4x1038 közötti valós szám lehet, legfeljebb 7 tizedesnyi pontossággal,

5. Dupla: 8 bájt, értéke -1,8x10308 és +1,8x10308 közötti valós szám lehet, legfeljebb 15 helyiérték pontossággal.

A fentiek mellett numerikus típusúak a következı adattípusok is:

6. Pénznem: 8 bájt, értéke -1015 és +1015 közötti, legfeljebb 4 tizedest tartalmazó valós szám lehet – érdekessége, hogy a kevés tizedest tartalmazó valós számokra (márpedig a gazdasági számításokban rendszerint elegendı az 1-4 tizedesnyi pontosság!) vonatkozó mőveletek nagyságrendekkel gyorsabban hajtódnak végre ezen a típuson, mint az egyszeres valós típus használata esetén!

7. Sorszám: 4 bájt, lényegében hosszú egésznek megfelelı adattípus – érdekessége, hogy értékét az Access automatikusan generálja minden új rekordban és ez az érték a késıbbiek során felhasználóként nem módosítható!

A következı típusba a dátumokat tartalmazó tulajdonságok típusa tartozik, az esetek többségében az adatbázis-kezelık nem tesznek különbséget aközött, hogy dátum vagy idı jellegő érték tárolására van szükség – így van ez az Access esetében is, a típus neve

31

Dátum/Idı. (Az Access (az Excel-hez hasonlóan) számként tárolja a dátumokat: az érték egész része az 1900. január 1. óta eltelt napok száma, a törtrész pedig a nap 24 óráját 1 egésznek tekintve az adott idıpont ehhez viszonyított aránya. Ez azt is jelenti, hogy egy Dátum/Idı típusú mezı felvitele –alapértelmezés szerint – egy érvényes dátum és az azon (a napon) belüli idıpont megadását is feltételezi!)

A Dátum/Idı adattípus tárolása 8 bájton történik, értékeit 100. január 1. és 9999. december 31. közötti érvényes dátumokból veheti (ismeri a szökınapokat...). Amennyiben az évszám helyére 100-nál kisebb számjegyet írunk, az automatikusan a XX. század megfelelı évszámát jelenti.

Az egyes dátumrészeket kötelezı elválasztani egymástól (az operációs rendszer területi beállításaitól függ, hogy a pont (.) vagy a per-jel (/) a dátumelválasztó, mint ahogy az is, hogy év.hónap.nap, hónap/nap/év, stb. a dátum helyes alakja), az idı típusú értékek esetében ez az elválasztó szimbólum minden esetben a kettıspont (:). (Érvényes értékek lehetnek pl. a 2000.10.24. vagy a 10/24/2000 vagy a 13:55:32 vagy az 1935 január 27. 17:14:55, stb.)

A „ Mezıtulajdonságok” „ Formátum” jellemzıje (legördülı menü!) segítségével határozható meg, hogy amennyiben nem pontos idıpontot kívánunk megadni, akkor a dátum vagy az idı rész bevitele legyen kötelezı (a hiányzó részt az Access alapértelmezi!, így pl. ha egy Dátum/Idı típusú mezıbe a 12:24 értéket visszük be, a mezı az 1899. december 30. 12:24:00 értéket fogja tartalmazni – miért?).

És végül egy megjegyzés a Dátum/Idı adattípussal kapcsolatban: az így megjelölt típusú tulajdonság mezıbe csak teljes dátum vihetı be, azaz ha nem ismerjük pl. az napot (ld. egy könyv megjelenése) vagy az évet (pl. rendszeres ünnepek, évfordulók), akkor az ilyen típusú információ tárolására nem használhatjuk ezt az adattípust!

A logikai adattípus elsıdlegesen az igaz-hamis jellegő információk tárolására szolgál, az Access által alkalmazott elnevezése Igen/Nem, tárolási mérete 1 bájt, alapértelmezett megjelenési formája pedig egy jelölınégyzet (�vagy�). Jelentıségét az adja, hogy bármilyen olyan adat tárolására felhasználható, ahol pontosan két lehetséges érték közül kell választani. Például a nyilvántartásunkban a dolgozó nemét jelölhetjük szöveggel („Férfi”, „Nı”), de rekordonként legalább 4 bájtot megtakarítunk a logikai típus alkalmazásával.

És végül az utolsó, némileg speciális adattípus az Access-ben az OLE objektum . Errıl a típusról annyit illik tudni, hogy olyan adatok tárolására szolgál, amelyek más alkalmazások segítségével hozhatók létre és kezelhetık: tartalmazhat egy Word-ben készült dokumentumot, egy Excel-ben elkészített kimutatást, de leggyakrabban multimédia jellegő információk tárolására szolgál: kép (álló vagy mozgó) vagy hang típusú adatokat tartalmaz. Ennek megfelelıen maximális méretének a lemez kapacitása szab határt (elvi korlátja 1 giganbájt, azaz 1 mezıbe legfeljebb ekkora mérető objektum illeszthetı be).

Látható, hogy az adatok jellegétıl, tartalmától és méretétıl függıen más és más adattípus a legalkalmasabb a nyilvántartás szerkezetének kialakítására. De nincsenek általánosan érvényes elvek vagy aranyszabályok, csupán a konkrét feladat ismerete és a tapasztalat adhat támpontot arra nézve, hogy mikor melyik adattípus választása a legcélszerőbb. Gyakorlásként íme néhány (gondolatébresztı) kérdés: milyen típust válasszunk egy gépjármő-nyilvántartás tervezésekor a rendszám, a gyártási év, a hengerőrtartalom, az üzemanyag-típus vagy a tulajdonos jogosítványának illetve telefonszámának tárolására?

Miután az adattábla valamennyi oszlopára vonatkozóan meghatároztuk az alapvetı jellemzıket, lényegében készen vagyunk az elıkészületekkel. Azonban meg kell jegyezni, hogy a táblaszerkezet a típusok meghatározásán túl még számos lehetıséget rejt, amely mind

32

az adatok kontisztenciájának biztosításához, mind az adatbázis hatékony használatához hozzájárulhatnak. Ezek a beállítások a „Mezıtulajdonságok” eddig nem tárgyalt sorainak megfelelı beállításával érhetık el, azonban tárgyalásuk meghaladja jelen jegyzet témakörét. (Az egyes sorok jelentésérıl a sor aktiválása és az F1 (Súgó) billentyő megnyomásával részletes leírást kaphatunk.)

Az elkészült táblaszerkezetet végül el kell mentenünk (ekkor – ha a tulajdonságok megadása során nem tettük – az Access rákérdez, hogy akarunk-e kulcsot is rendelni az adattáblához: emlékezzünk, a kulcsok egyértelmő megkülönböztetésének eszközei, részben biztonsági, részben mőveletvégrehajtás-gyorsítási szerepük van): mivel az Access-ben az adatbázis minden objektuma egyedi azonosítóval rendelkezik, így a táblának is nevet kell adnunk. Ezután kezdıdhet a tényleges munka: az adatok felvitele és a különbözı keresési, megjelenítési feladatok elvégzése.

3.4. Beviteli és kiviteli eszközök

3.4.1. Őrlapok Az adatok felvitelének egyszerő, bár kicsit kényelmetlen módja az elkészült tábla

Adatlap nézetben történı megnyitása révén az egyes mezık közvetlen feltöltése. Ehhez vagy a Tábla munkaterület Megnyitás parancsgombját (vagy Tervezı nézetben a Nézetváltó nyomógombot) kell megnyomnunk. A tábla egyes sorai reprezentálják az egyes rekordokat, az oszlopok a tervezés során megadott névvel és típussal rendelkeznek, az egyes mezık között az egérrel, a kurzormozgató billentyőkkel, a TAB és az Enter billentyővel is mozoghatunk. Az aktuálisan szerkesztett (feltölteni kívánt) rekordot a tábla bal szélén levı kijelöl ısávban egy fekete háromszög jelzi, az adattábla következı szabad helyét (az elsı üres rekordot) pedig ugyanitt egy csillag (*) szimbólum. (12. ábra) Az adatbevitel során sor kerül az elsı ellenırzésre is: az Access automatikusan ellenırzi, hogy az adott mezıbe begépelt adat típusa és értéke megfelel-e a tulajdonságnál meghatározott jellemzıknek, és hibás adatot nem enged bevinni – sıt, amíg helyes adatot nem adunk meg, addig kilépni sem enged a mezıbıl!

A tábla alsó szélén láthatjuk a Rekordnavigátort (a 12. ábrán pirossal jelölve), amivel mozoghatunk a rekordjaink között (természetesen erre használhatjuk a tábla Gördítısávjait is), a szimbólumok jelentése balról jobbra a következı: ugrás a legelsı rekordra (▐◄); lépés az elızı rekordra (◄); a beviteli mezıben az aktuális rekord sorszáma látható, ha ezt átírjuk, akkor a megadott sorszámú rekordra léphetünk; lépés a következı rekordra (►); ugrás a legutolsó rekordra (►▌); ugrás az üres rekordra (►*).

33

12. Ábra – Adatbevitel a tábla Adatlap nézetében

Ebben a nézetben az adatfelvitel mellett az eszköztár parancsgombjai segítségével elvégezhetjük a legegyszerőbb adatkezelési mőveleteket is: az aktuális tulajdonság (amelyik oszlopban a kurzorunk tartózkodik) szerint rendezhetjük a rekordokat (a 13. ábrán kékkel jelölve); kiválogathatjuk az adatok közül azokat a rekordokat, amelyek valamilyen feltételnek eleget tesznek („szőrés”; a 13. ábrán zölddel jelölt ikonok), megkereshetünk egy adott értéket tartalmazó rekordot (a 13. ábrán sárgával jelölve) és törölhetjük az aktuális rekordot (a 13. ábrán pirossal jelölve).

13. Ábra – Az Adatlap nézethez tartozó eszköztár

Természetesen a mőveletek egy része vonatkozhat több rekordra vagy akár különbözı tulajdonságokra, ehhez a tábla megfelelı részét ki kell jelölnünk : a tábla bal szélén levı szürke sávban az egér bal gombjának nyomva tartása mellett húzva az egeret rekordokat, az oszlopazonosítók fölött hasonló módon eljárva tulajdonságokat jelölhetünk ki.

Az adatok megjelenésével kapcsolatban ebben a nézetben nincs sok lehetıségünk: adott a tábla rácsszerkezete, ezzel dolgozhatunk. Ugyanez a helyzet, ha az adatainkat ki szeretnénk nyomtatni: maga a táblázat kerül kinyomtatásra, az egyes mezık határát halvány segédvonalak jelzik, az egyes lapok fejlécére a tábla neve és a nyomtatás dátuma kerül.

Elégséges ez? Bizonyos esetekben igen, de gondoljunk csak bele: ha napi 8 órában kellene képernyıkön keresztül gördülı rácstenger mezıiben keresgélnünk, vagy a különbözı kimutatásokat egyetlen hatalmas, tagolatlan adatfolyamként kapnánk meg (és mivel nem fér ki egy oldalra, az egy rekordhoz tartozó adatokat 3-4 lap egymás mellé illesztésével és vonalzóval próbálgathatnánk összeállítani...) – látható, hogy nem a leghatékonyabb (de legalábbis a felhasználó – jogos – elvárásaitól nagyon távol álló) megoldások ezek.

Természetesen nem ez az egyetlen lehetıség: a Táblák munkaterület – ahogy azt a munkaterületek áttekintésekor említettük – elsıdlegesen a tárolási szerkezet kialakítására szolgál: a táblák létrehozására, a tulajdonságok és a típusok meghatározására, esetleg bizonyos (automatikus) ellenırzési mőveletek megadására. A formázott adatbevitel eszközei az Őrlapok, formázott nyomtatványokat pedig a Jelentések segítségével készíthetünk.

A két munkaterület objektumainak kezelése szinte teljesen megegyezik (ezért is tárgyaljuk együtt – de nem egyszerre! – a kettıt), bár elsıre talán kicsit bonyolultnak tőnik, de ez csak addig van így, amíg nem látjuk át az egyes vezérlıelemek szerepét (amelyek

34

egyébként jó ismerıseink a grafikus felülettel való mindennapi munkavégzésbıl, csak eddig valószínőleg nem gondoltunk még bele, melyiket mikor célszerő alkalmazni...).

Csakúgy, mint az adattáblák esetében, ezeket az objektumokat is létrehozhatjuk különbözı módon (saját magunk Tervezı nézetben, varázslók vagy elıre gyártott sablonok alkalmazásával), ebben a fejezetben a varázslók használatával ismerkedünk meg. Tesszük mindezt azért, mert amíg az adattáblák jellemzıen különbözıek (ezért a varázslók által létrehozott adattáblákat alkalmasint ugyanannyi ideig tart a saját igényünknek és adatainknak megfelelı formára alakítani, mint önállóan létrehozni), az adatfelvitellel kapcsolatos mőveletek függetlenek a tárolt adatok jellegétıl, így sokkal egységesebbnek tekinthetık: majd minden adatbázis felviteli képernyıje valamilyen adatbevitelre alkalmas vezérlıelemek elrendezett együttese – csak az elrendezés a kérdés: egymás alatt, mellett, átlósan, pirosban vagy kékben szimpatikusabb?

Az őrlapok az adatbázis rekordjait jelenítik meg, csakúgy, mint az adattábla sorai (ugyanazokat a mőveleteket hajthatjuk végre itt is: felvehetünk újabb adatokat, módosíthatjuk vagy törölhetjük a meglevıket – vegyük észre, hogy az eszköztárban az elızıekben említett ikonok változatlan formában és szerepben elérhetıek!), azzal a különbséggel, hogy az egyes tulajdonságok tetszés szerint elhelyezkedhetnek (nem kötelezı egymás mellett felsorolni az összest). Alapértelmezés szerint kétféle őrlapot különböztethetünk meg: a Táblázatos és az Oszlopos elrendezésőt (14. ábra).

A Táblázatos elrendezéső őrlap lényegében egy formai elemekkel (kiemelések, színek, háttér, stb.) ellátott Adatlapnak felel meg: egy rekord egy sort foglal el, a képernyın egyszerre annyi rekord jelenik meg, amennyit az őrlap magassága lehetıvé tesz.

Ezzel szemben Oszlopos elrendezéső őrlap használata esetén az őrlap teljes terjedelmét egyetlen rekord mezıi foglalják el (mintha elforgattuk volna az adattáblánkat 90° -kal: bal szélen, egymás alatt a tulajdonságok, mindegyik mellett az aktuális rekord megfelelı értéke), az egyes rekordok között az őrlap alján a Rekordnavigátorral lépegethetünk.

Látható, hogy a két alapvetı őrlap közti választást az határozza meg, hogy a feldolgozás során mi a cél: minél több rekord áttekintése, vagy egyszerre csak egyetlen rekord megjelenítése.

Természetesen ezek csak az alapvetı elrendezések, ezeket módosítva tetszés szerinti őrlapszerkezet kialakítható – de jegyezzük meg, hogy függetlenül az oszlopnevek és a mezıértékek elhelyezkedésétıl: ha az őrlapon egyszerre több rekord adatait kezelhetjük, táblázatos, ellenkezı esetben oszlopos elrendezéső őrlapról beszélünk.

35

14. Ábra – Táblázatos és oszlopos elrendezéső őrlapok (azonos formai jellemzıkkel)

Őrlapok készítésekor (ahogy azt már az elıbb említettük) bátran használjuk az Access beépített varázslóit – majd az elkészített (sablon)őrlapon a megfelelı elemeket igény szerint átalakítjuk. Ehhez hozzunk létre egy új őrlapot a munkaterület Új parancsgombja segítségével.

A két alapvetı típusú őrlap készítése során nincs is más dolgunk, mint a varázsló számára azonosítani azt az adattáblát, amelynek a tartalmát meg szeretnénk jeleníteni: parancsgomb hatására megjelenı párbeszédablakban a felsı felsorolásban jelöljük ki a megfelelı őrlap-típust, alatta pedig a legördülı menüben megjelenı táblák közül válasszuk ki a használni kívánt adattáblát. (A pontosság kedvéért jegyezzük meg, hogy őrlap alapja nem csak adattábla, hanem egy lekérdezési mővelet eredményeként elıálló lista is lehet – ennek az a magyarázata, hogy a relációs adatbázis-kezelı rendszerekben a mőveletek eredményei is tábláknak tekinthetık.)

Ezek a varázslók alapértelmezés szerint az adattábla valamennyi tulajdonságát felveszik az őrlapra, az őrlap beállításai pedig az ezt megelızıen utoljára létrehozott őrlap alapbeállításaival egyeznek meg.

Ennél lényegesen finomabb beállítások elvégzésére van lehetıségünk, ha a megjelenı párbeszédablakban az „Őrlapkészítı varázsló”-t választjuk ki – ebben az esetben ugyanis nincsenek alapértelmezések: mind a megjeleníteni kívánt tulajdonságokat, mind a megjelenés formai elemeit magunknak kell megadni (kiválasztani). Ehhez a varázsló 4 lépésben nyújt segítséget (minden lépést külön párbeszédablak jelenít meg, az egyes ablakok között az „Elıre” és a „Vissza” gombok segítségével lépegethetünk, 15. ábra):

1. az elsı párbeszédablakban a megjeleníteni kívánt tulajdonságok meghatározása történik: a bal oldali ablakban a kiválasztott tábla tulajdonságai jelennek meg (itt nem kötelezı a varázsló indításakor megadnunk az adattáblát, aminek az a magyarázata, hogy ezzel a módszerrel különbözı táblából származó tulajdonságok egyazon őrlapon történı megjelenítésére is van lehetıség – bizonyos feltételek mellett), a jobb oldaliban pedig azok, amelyek majd megjelennek az őrlapon – a két ablak között látható (nyíl szimbólumokkal rendelkezı) parancsgombokkal vehetünk fel vagy távolíthatunk el tulajdonságokat az őrlapról (az egyszeres nyilak egy tulajdonság hozzáadását vagy törlését végzik, a dupla nyilak az összes tulajdonságra vonatkoznak);

2. a második párbeszédablakban az őrlap típusát (azaz a tulajdonságok elrendezésére vonatkozó beállításokat) kell megadnunk, itt új őrlaptípusként szerepel a „Sorkizárt ”, ami a szövegszerkesztésbıl ismerıs fogalom „átemelése”: olyan oszlopos őrlap (azaz

36

egy őrlapon egy rekord jeleníthetı meg a segítségével), amelyben a tulajdonságok nem egymás alatt, hanem az ablak méretének függvényében egymás mellett, több sorba tördelıdve jelennek meg (mivel megjelenítési elemek, itt szerepelnek a „ (kereszttáblás) kimutatások” is (ld. táblázat-kezelés), ezek azonban nem tekinthetık az adatbázis-kezelés szempontjából őrlapoknak, így részletesen nem tárgyaljuk a kezelésükkel kapcsolatos lehetıségeket);

3. a harmadik lépésben az őrlap megjelenítésével kapcsolatos (rögzített) minták közül választhatunk (a bal oldalon a kiválasztott minta vázlatos képe jelenik meg: a háttér, a címkék és az adatok szín- illetve keretbeállításai);

4. a negyedik lépésben pedig az őrlap azonosítóját (nevét) kell megadnunk.

15. Ábra – Őrlap(készítı) varázsló

Az elkészült őrlappal azonnal megkezdetjük a munkát, de további módosításokat is végezhetünk rajta: ehhez az őrlap tervezı nézetére kell váltanunk (bezárt őrlap esetén a munkaterület „Tervezés” parancsgombja segítségével, nyitott őrlap esetén a „nézetváltó”-val.) A tervezés során alapvetıen három eszközzel dolgozhatunk: az őrlapon szereplı (illetve az őrlap alapjául – „adatforrás”-ul – szolgáló) tulajdonságok listájával („Mezılista”, a 16. ábrán piros vonallal jelölve) , az őrlapon elhelyezhetı vezérlıelemeket tartalmazó „Eszközkészlettel” (a 16. ábrán kék vonallal jelöve) és az adott elem megjelenésének és mőködésének beállítására szolgáló „Tulajdonságok” párbeszédablakkal (a 16. ábrán zölddel jelölve). Mindhárom eszköz kapcsolóként mőködik: az eszköztárban rákattintva megjeleníti illetve elrejti a megfelelı elemet.

37

16. Ábra – Őrlap, tervezı nézetben

Az őrlap tervezése során az őrlapon megjelenı valamennyi elem (a továbbiakban objektum) azonosítására két rész szolgál: minden objektumnak van egy leíró („címke”) része és egy tartalmi („adat”) része. Az elıbbi az objektum leírására, azonosítására, megkülönböztetésére szolgál, az utóbbi az adott objektum által reprezentált tulajdonság adatait (a tábla megfelelı mezıiben szereplı értékeket) jelenti. Az objektum két elemének az elnevezése alapértelmezés szerint azonos, de csak a címke tartalma változtatható meg szabadon, az adattagé soha!

Újabb objektumot akár a mezılistából (vonszolással), akár az Eszközkészletbıl (a megfelelı vezérlıelemre kattintva, majd az őrlap területén az objektum számára rendelkezésre álló területet „megrajzolva”) vehetünk fel, a meglevı elemeket pedig az adott objektumon a gyorsmenü (a jobb gomb hatására megjelenı parancsok) „Objektum átalakítása” parancsával módosíthatjuk. Természetesen módosításra használhatjuk a „Formázó eszköztár” ikonjait (betőszín, háttérszín, szegély típusa, stb.), de az objektum megjelenésére vonatkozó beállítások leghatékonyabban (pontosabban és az eszköztárban megjelenı lehetıségeknél jóval több mőveletre vonatkozóan) a „Tulajdonságok” ablak megfelelı elemén keresztül érhetık el (a módosítani kívánt objektumot legegyszerőbben a „Tulajdonság” ablak fejléce alatti legördülı menüben választhatjuk ki: itt az őrlap részei és a rajta szereplı összes objektum szerepel).

Az objektumot áthelyezhetık (vonszolással, ehhez az objektumot szegélyezı keretnél kell az adott elemet megragadni az egérrel) és átméretezhetık (a szegélyvonal sarok- és felezıpontjainál megjelenı „méretezıpontok” segítségével). A méretezıpontok közül az objektum bal felsı sarkában szereplı pontnak kitüntetett szerepe van: alapértelmezés szerint az objektum leíró- és adattagja együtt mozog, ennél a pontnál megfogva ugyanazon objektum egyes elemei egymástól függetlenül mozgathatók. Egyszerre több objektumot is kijelölhetünk, ha az egeret az őrlap (egy objektum által nem takart) területérıl kiindulva, a bal gomb nyomvatartása mellett elhúzzuk a kijelölni kívánt objektumok fölött.

38

Ennyi ismeret birtokában már megkezdhetjük a varázsló által összeállított őrlap ízlésünknek leginkább formára történı átalakítását (testre szabását), de meg kell jegyezni, hogy professzionális őrlapok készítéséhez mind az eszközkészlet, mind az egyes objektumok tulajdonságainak alapos ismerete szükséges – ezek tárgyalása (részint az Access által ismert objektumok nagy száma, részint az egyes objektumok beállításaiban jelentkezı különbségek miatt) nem képezi jelen jegyzet tárgyát – kísérletezı kedvő hallgatóinknak bátran ajánljuk azonban a különbözı lehetıségek kipróbálását!

3.4.2. Jelentések A jelentések (ahogy azt a rész bevezetésében is említettük) sokban hasonlítanak az

őrlapokhoz: hasonló a szerepük (a tárolt információ megjelenítése), hasonlóan tipizálhatók (oszlopos, táblázatos), azonos módon hozhatók létre (varázslók) illetve szerkeszthetık (vezérlıelemek és azok tulajdonságain keresztül) – éppen ezért most csak a legfontosabb különbségek tárgyalására térünk ki.

A legjellemzıbb eltérés köztük az őrlapok és a jelentések között, hogy amíg az elıbbi képernyın keresztüli feldolgozásra alkalmas módon jelenítik meg az adatokat, a jelentések kimondottan nyomtatási elıkészítési céllal készülnek. Az alapértelmezett elrendezéső (oszlopos, táblázatos) jelentések létrehozásához szintén meg kell adni az adatforrást (Jelentések munkaterület, Új parancsgomb, jelentés formátumának és alatta az adattáblának a kiválasztása), míg a „Jelentés varázsló” segítségével az elrendezés mellett további mőveleteket is megadhatunk, ezek közül a (gyakorlatban) legfontosabb az adatok rendezése és csoportosítása.

A „ Jelentés(készítı) varázsló” szintén párbeszédablakok sorozataként győjti össze a szükséges információkat, az egyes lépések a következık (17. ábra):

1. elsı lépésben itt is a jelentésben szereplı tulajdonságokat kell (az őrlapnál megismerttel azonos módon) megadni;

2. a következı párbeszédablakban van lehetıség az adatok csoportosítására: amennyiben az adattábla valamely tulajdonsága tartalmaz azonos (értékő) adatokat, akkor azok a rekordok, amelyekben ezek az értékek megegyeznek, egy-egy csoportot képeznek (pl. az azonos városban lakó személyek adatai együtt jeleníthetık meg). A csoportosításhoz elıször is meg kell adnunk, hogy melyik tulajdonság értékei alapján képezzük a csoportokat (ez az elızı lépésben megismert módon történik: a bal oldali listából a nyíl alakú ikonok segítségével átmozgatjuk a megfelelı tulajdonságot a jobb oldali mintára – figyelem! van lehetıség (több tulajdonság átmozgatásával) többszintő listák készítésére (pl. megyénként, és az egyes megyéken belül településenkénti csoportosítás) és a csoportosítás sorrendjének módosítására (a fel illetve a lefelé mutató nyilak segítségével) is), és a csoportosító tulajdonság típusának függvényében a csoportosítás szempontjának beállítására (a tulajdonságlista alatt található „Csoportosítási beállítások” parancsgomb segítségével:

� karakteres típusú tulajdonságokat csoportosíthatunk a mezı teljes tartalma (azaz csak az azonos mezık alkotnak egy csoportot) vagy szöveg elsı 1-5 karaktere (pl. kezdıbetők) szerint,

� numerikus értékeket értéktartományok szerint csoportosíthatunk (pl. tízesével történı csoportosítás esetén azok a rekordok alkotnak egy csoportot, ahol a csoportosítási tulajdonság értéke 0-9 közé, 10-19 közé, ... esik, stb.),

� dátumok esetén pedig naptári egységek képezhetik a csoportosítás alapját: heti, havi, negyedéves, stb. bontásban jeleníthetık meg az adatok.

39

17. Ábra – Jelentéskészítés lépései

3. a harmadik lépésben a rekordok rendezettségével kapcsolatos beállítások végezhetık el: itt kell meghatároznunk, hogy mely tulajdonság értékei szerint legyen rendezett az eredménylista. Figyelem: amennyiben az elızı lépésben megadtunk csoportosítási szempontokat, akkor a rendezés csak az egyes csoportokon belül érvényesül, a csoportosítás alapértelmezés szerint a legmagasabb szintő rendezettséget is jelenti! Természetesen van lehetıség több rendezési szempont megadásár, ez esetben amennyiben az elsıként meghatározott tulajdonságban azonos értékek szerepelnek, akkor az Access a másodikként (harmadikként, stb.) megadott tulajdonságokban szereplı értékek alapján állítja fel a sorrendet.

Szintén a harmadik párbeszédablak szolgál a jelentés numerikus értékeket tartalmazó mezıire vonatkozó összesítési mőveletek meghatározására is. Ez azt jelenti, hogy amennyiben a rendezési szempontok alatt található „Összesítési beállítások” parancsgombra kattintunk, akkor egy új párbeszédablakban meghatározhatjuk, hogy a táblában szereplı tulajdonságok közül melyikkel (természetesen csak valamilyen szám típusú tulajdonság jöhet szóba!) milyen (elemi statisztikai) mőveletet végezzen az Access: összegezze (adja össze) az adott tulajdonság értékeit („Össz”), átlagolja az adatokat („Átl ”) vagy csak a legnagyobb vagy legkisebb értékeket jelenítse meg („Max”, „ Min ”). Ezek a (leszámlálási) mőveletek (megfelelı csoportosítással kombinálva) tetszıleges mélységő ún. összegfokozatos lista elkészítésére adnak

40

lehetıséget (gondoljunk csak vissza pl. a bankok által küldött egyenlegközlı levelekre...).

4. A negyedik és az ötödik lépés a formai beállítások meghatározására szolgál: az őrlapoknál már megszokott módon, sémákból választhatjuk ki

� a negyedik párbeszédablakban a rekordok elrendezésének módját (behúzással, szegélyekkel, keretezéssel, kiemelések alkalmazásával tegyük szembetőnıvé a rekordhatárokat),

� az ötödik párbeszédablakban pedig a jelentés általános megjelenésének jellemzıit (karakterkészlet, színhasználat, stb.);

5. és végül a jelentésnek is nevet (egyedi azonosítót) kell adnunk.

Látható tehát, hogy a „Jelentés varázsló” (a megfelelı beállításokkal) egy általánosan használható, azonnal nyomtatható formátumú anyagot állít elı az adatainkból. Ez persze nem jelent tökéleteset: amennyiben módosítani szeretnénk a varázsló által elkészített jelentés valamely elemét, akkor ezt a tervezı nézet segítségével és az őrlapokkal teljesen megegyezı módon tehetjük meg (18. ábra, a kék keret a rendezés és csoportosítás parancsikonját jelöli):

18. Ábra – A jelentés formázása tervezı nézetben

Végezetül nézzünk meg egy példát: a 19. ábrán egy varázsló által (elı)készített jelentésen elvégzett néhány módosítás hatására elıálló nyomtatási kép látható. Mit látunk? A jelentésben a Fizetés tulajdonság értékei szerint 10 000-es csoportok figyelhetık meg, az egyes csoportokba tartozó rekordok fizetés (és azonos fizetés esetén névsor) szerint rendezetten jelennek meg és minden csoporthoz meghatározásra került az adott csoportra vonatkozó legalacsonyabb és legmagasabb fizetés. (Gondolja végig, milyen lépések, milyen beállítások szükségesek mindezekhez!) Ami a jelentés formai részét illeti, kiemelési eszközként a vastag betők és a különbözı szegélyvonalak szolgálnak.

41

19. Ábra – Egy kész jelentés

Természetesen (csakúgy, mint az őrlapok esetében is) a bemutatott alapmőveleteknél jóval több lehetıséget rejtenek a jelentések is.

Ennek a résznek nem volt (nem is lehetett) célja az, hogy az adatbázis-kezelés két alapvetı komponensének, az adatok bevitelének és a tárolt információ megjelenítésének valamennyi eszközét és lehetıségét megismertesse, így csupán arra szorítkozhattunk, hogy megismerkedjünk az őrlapok és a jelentések használatának a gyakorlatban leginkább használható (alapvetı) lehetıségeivel. Számos (érdekes) részterületet nem érintettünk (beágyazott őrlapok használata, adatelemzések kimutatások és/vagy grafikonok segítségével, stb.), de ismételten arra bátorítunk minden érdeklıdıt, hogy kísérletezzen: a varázslók és a környezetérzékeny súgókban található példák és minták segítségével szebb és hatékonyabb őrlapok és jelentések készíthetık, az Access mintaadatbázisában (elérhetı a Súgó menüpont Mintaadatbázisok parancsán keresztül) pedig további ötleteket találhatunk – a többi (ahogy mondani szokták) már csak fantázia kérdése...

3.5. Adatkezelési m őveletek Még mielıtt abba az illúzióba ringatnánk magunkat, hogy mindent tudunk az

adatbázis-kezelésrıl, emlékezzünk vissza arra az (az adatbázisok általános jellemzıinek tárgyalásakor megfogalmazott) állításra, mely szerint az adatbázis-kezelés során leggyakrabban alkalmazott mővelet az adatok megkeresésével, a tárolt információ-tömegben rejlı összefüggések vagy járulékos (új) információk meghatározásával kapcsolatos mővelet – a relációs adatbázis-kezelı rendszerek szóhasználatában a lekérdezés.

42

3.5.1. Lekérdezések Mi is az a lekérdezés? Hagyományos értelmezés szerint adatok kiválogatása. Más

(tágabb) értelemben pedig mindazon eszközök és módszerek összessége, amelyek képesek az adattáblában tárolt adatok közül megkeresni azokat (és itt megint csak értsünk adatok egy – jó nagy! – csoportját egy-egy konkrét adatrekord helyett), amelyek a feladat megoldása szempontjából fontosak, illetve az adatok egy-egy ilyen csoportján valamilyen (jellemzıen azonos) mőveletet gyorsan elvégezni.

Vegyük például a legegyszerőbb lekérdezést, a kiválogatást. Tegyük fel, hogy szükségünk van egy listára azokról a budapesti beszállítóink elérhetıségérıl. Hagyományos esetben fellapozzuk a nyilvántartásunkat, egyesével végignézzük az egyes szállítók kartonját, és ahol az adott cég székhelye Budapest, ott feljegyezzük a címet, telefonszámot, stb. Ha mélyebben elemezzük a feladatot, akkor lényegében 3 dolgot ismétlünk: fogunk egy kartont (rekordot), megnézzük, hogy a számunkra szükséges adatcsoportba tartozik-e (budapesti ?), és ha igen, feljegyezzük az adatait – majd vesszük a következıt, amíg az adataink el nem fogynak. Mechanikusan ismétlıdı tevékenység – tehát gépesíthetı: bízzuk az adatbázis-kezelıre, hogy nézze végig az összes rekordot, ahol a megadott tulajdonság értéke megegyezik az általunk meghatározott értékkel, azokat győjtse ki és végül jelenítse meg ezen kigyőjtött rekordok adatai közül a számunkra érdekeseket. Máris a lekérdezéseknél tartunk.

Az Access (hasonlóan a legtöbb korszerő adatbázis-kezelı programhoz) a lekérdezés fogalmát általánosan használja: nem csak az adat-visszakeresési mőveletet sorolja ide, hanem az összes olyan tevékenységet, amelyben nem egyetlen rekord, hanem rekordok egy csoportja vesz részt. Ennek a jelentıségéhez csak azt gondoljuk végig, hogy ha a nyilvántartásunkban van mondjuk 50 000 rekord (pl. az elmúlt 3 év gazdasági eseményeivel kapcsolatos feljegyzéseink) és törölni szeretnénk a két évnél régebbi adatokat, akkor ezt (eddigi ismereteink szerint) megtehetnénk oly módon, hogy a Tábla munkaterület Adatlap nézetében (vagy egy alkalmas őrlap segítségével) egyesével megkeresem ezeket a rekordokat és (egyesével) ki is tudom törölni ıket – de ha 10 000 van belılük?... és ha még csak nem is egymás mellett, hanem elszórtan helyezkednek el az egész táblában?...

A lekérdezéseket a mőködésük jellegzetessége szerint két csoportba sorolhatjuk: az egyszerő lekérdezések a táblában tárolt információt nem változtatják meg11 (csupán rendezik, csoportosítják, felhasználják különbözı számítási mőveletekhez, stb.), míg az adatmódosító lekérdezések hatására a táblában tárolt adattartalom megváltozik – azaz a lekérdezés belenyúl az adattáblába, megváltoztatja a mezık értékét, töröl bizonyos rekordokat!

A lekérdezéseket csoportosíthatjuk aszerint is, hogy milyen módon hozzuk létre. Az Access ezzel kapcsolatban is kétféle lehetıséget biztosít (leszámítva a varázslókat): használhatjuk a „lekérdezés-tervezı”-t (QBE, „Query By Example”, kb. „Lekérdezés Mintának Megfelelıen”) vagy az Access SQL-t (emlékezzünk, errıl az eszközrıl mondtuk azt, hogy a relációs adatbázis-kezelık univerzális kezelı nyelve!)

A lekérdezésekre egyébként többé-kevésbé ugyanazok a szabályok vonatkoznak, mint az adatbázis bármely más munkaterületének az objektumaira, a különbség csupán annyi, hogy a parancsgombok közül a „Megnyitás” hatására a lekérdezés végrehajtódik – ha ez egy egyszerő lekérdezés, akkor elkészíti a megadott feltételeknek eleget tevı listát, stb.; ha adatmódosító, akkor módosítja vagy törli a megfelelı rekordokat. Ez utóbbi sajátosság az, ami miatt a lekérdezések kezelése külön odafigyelést igényel: egy hibás lekérdezés javításához (de

11 Az ilyen módon kiválasztott adatok egy átmeneti táblában (az ún. eredménytáblában) tárolódnak, ami semmilyen módon nem férhet hozzá a kiinduló adatokat tartalmazó táblához – azonban teljes értékő addattáblaként is képes viselkedni (hivatkozhatunk rá), így pl. adhatunk meg olyan mőveletet, amely az eredménytábla adataira vonatkozik.

43

akár egy helyes lekérdezés módosításához is) csak a „Tervezés” parancsgomb segítségével foghatunk hozzá...

Ellentétben az őrlapokkal és a jelentésekkel (és hasonlóan az adattáblákhoz) a lekérdezések készítése során ritkán fogjuk alkalmazni a varázslókat (ugyanazon okból kifolyólag, mint az adattáblák esetében: a lekérdezések erısen feladat és adattábla-specifikusak), elıbb a grafikus tervezıfelülettel (QBE), majd (valamivel rövidebben) az SQL lehetıségeivel ismerkedünk meg.

Új lekérdezés létrehozásához használjuk a „Lekérdezések” munkaterület „Új ” parancsgombját és a megjelenı listából válasszuk ki a „Tervezı nézet” lehetıséget12.

A lekérdezés készítésekor (csakúgy, mint az őrlapok és a jelentések esetén) elsı lépésként meg kell adni, hogy mely tábla vagy táblák tartalmazzák azokat a tulajdonságokat, amelyekkel valamilyen mőveletet el szeretnénk végezni: ezeket a „Hozzáadás” parancsgombbal tudjuk felvenni. Miután valamennyi szükséges táblát hozzárendeltünk a lekérdezéshez, zárjuk be ezt a párbeszédablakot (ha a késıbbiek során kiderül, hogy valamelyik táblát mégsem vettük fel, akkor tervezı nézetben az eszköztár középsı részén találjuk a „Tábla hozzáadása” ikon: segítségével ezt az ablakot bármikor újra megjeleníthetjük).

(Mivel az egyszerőség kedvéért feltesszük, hogy az adatbázisunk egyetlen táblából áll (ez a gyakorlatban szinte sosincs így!), fontos megjegyezni, hogy az elkövetkezık csak bizonyos megszorítások mellett igazak olyan lekérdezésekre, amelyek egynél több táblából származó tulajdonságokkal végeznek mőveletet. Anélkül, hogy ezen megszorítások részletezésébe belemennénk, jegyezzük meg, hogy egy lekérdezéshez egy adattáblát csak egyszer rendelhetünk hozzá és hogy nem lehet lekérdezés alapja táblák olyan csoportja, amelyek között nincs (logikai és az Access-ben is definiált) kapcsolat – a gyakorlatban a kapcsolatban levı táblákat az Access egy folytonos fekete vonallal köti össze: ha a lekérdezés valamely táblája nem csatlakozik egy vagy több másik táblához ily módon, akkor biztos, hogy hibásan határoztuk meg az adattáblákat.)

A lekérdezés alapjául szolgáló tábla (táblák) kiválasztására szolgáló párbeszédablak bezárását követıen megjelenı felület a QBE, az Access grafikus lekérdezés-szerkesztı eszköze. A módszer lényege, hogy azt kell meghatározni, hogy hogyan nézzen ki a lekérdezés eredményeként elıálló táblázat (milyen oszlopokat, milyen adatokat milyen sorrendben tartalmazzon). Ehhez a QBE felsı részén a lekérdezésben használható táblák szerepelnek (újabb táblát felvenni az elıbb látott módon lehet, a tévedésbıl vagy többszörösen felvett táblát eltávolítani legegyszerőbben a táblára történı kattintással és a „DEL ” billentyő lenyomásával), az alsó rész az ún. szerkesztı (vagy QBE) rács: minden sora a lekérdezés valamely mőveletének meghatározására szolgál.

A lekérdezés összeállításához elıször a táblák között megkeressük azt a tulajdonságot, amellyel valamilyen mőveletet el akarunk végezni, és áthúzzuk a szerkesztırács valamelyik (üres) oszlopának elsı mezıjére, majd sorra beállítjuk az adott oszlop többi mezıjének az értékét és így tovább a második, harmadik, ... tulajdonságokkal. Amennyiben el szeretnénk távolítani egy tulajdonságot a szerkesztırácsról, akkor egyszerően töröljük ki a nevét a „Mezı” sorból.

12 A létrejövı lekérdezés minden esetben egyszerő lekérdezés lesz. Amennyiben másik típusú lekérdezést szeretnénk létrehozni, abban az esetben is ugyanígy kell eljárni, és a késıbbiekben, a lekérdezés szerkezetének kialakítása során tudjuk megváltoztatni a lekérdezés típusát – azaz itt pont fordított a mőveletek sorrendje, mint az őrlapok vagy a jelentések esetében volt!

44

20. Ábra – Lekérdezés tervezés közben

A QBE rács sorai az adott tulajdonságnak az eredménytáblában betöltött szerepét határozzák meg, az egyes sorok jelentése a következı:

� a „Mezı” sorban a tulajdonság neve szerepel (az elıbb említett módszer mellett kitölthetjük úgy is, hogy az egérrel belekattintunk a sor megfelelı mezıjébe, és a legördülı menübıl választjuk ki a megfelelı tulajdonságot, a lista elején szereplı csillag (*) az adattábla valamennyi tulajdonságát (együttesen) jelképezi);

� a „Tábla” sorban annak a táblának a neve, ahonnan a tulajdonság származik (értelemszerően csak abban az esetben van jelentısége, ha több-táblás lekérdezéssel dolgozunk, és az egyes táblákban vannak azonos elnevezéső oszlopok – ilyenkor így különböztethetjük meg, hogy melyikre hivatkozunk);

� a „Rendezés” legördülı menü, értéke („Növekvı”, „ Csökkenı”, „ Nem rendezett”) határozza meg, hogy az eredménytábla az adott tulajdonság értékei szerint rendezett legyen (és ha igen, milyen irányba) vagy sem – amennyiben több tulajdonságra vonatkozóan is megadjuk ezt a jellemzıt, akkor a szerkesztırácsban elfoglalt sorrendjük szerinti (balról jobbra) rendezettsége lesz az eredménytáblának (azaz ha az elsı oszlopban megadjuk, hogy NÉV tulajdonság szerint növekvı lista készüljön és a második oszlopban (a HELYSÉG alatt) is kiválasztjuk a rendezés sor valamely opcióját, akkor az eredménytáblánk névsor szerint lesz rendezve, az azonos neveket tartalmazó rekordok esetén veszi csak figyelembe az Access a HELYSÉG tulajdonság értékeit);

� a „Megjelenés” sor jelölınégyzete azt határozza meg, hogy a szerkesztırácsra felvett tulajdonság megjelenjen-e (látszik-e) az eredménytáblában, vagy sem: ahol nincs pipa, azokkal a tulajdonságokkal végezhetünk különbözı mőveleteket a lekérdezésben, de a végrehajtásakor megjelenı eredménytáblában nem kerülnek kiírásra;

� a „Feltételek” sorban pedig azt határozhatjuk meg, hogy az adott tulajdonság mely értékei szerepeljenek az eredménytáblában.

A feltételmezık az Excel irányított szőrıjével azonos módon mőködnek, azaz a mezıbe csak a relációs jelet (kisebb (<), nagyobb (>), egyenlı (=), kisebb vagy egyenlı (<=), nagyobb vagy egyenlı (>=) és nem egyenlı (<>) ) és az összehasonlításban felhasznált értéket kell beírni, a bal oldalt mindig a „Mezı” sorban szereplı tulajdonság rekordjainak

45

aktuális értéke képviseli. Az összehasonlításban használt érték típusának meg kell felelni a tulajdonság típusának és ezt jelölni13 is kell: a számokat nem jelöljük külön, a szöveges értékeket idézıjelek (” ”) között, a dátumot kettıskereszt („hash mark”, #) között kell megadni. A relációs jeleken túl használhatunk elıre definiált relációs kifejezéseket (predikátumokat) is a feltételekben, amelyekre ugyanezek a típusjelölési konvenciók érvényesek. A fontosabb predikátumok a következık:

� IN (halmaz): azok a rekordok kerülnek bele az eredménytáblába, amelyek értéke szerepel a halmazban (zárójelek között vesszıvel felsorolt értékek);

� BETWEEN küszöb1 AND küszöb2: azok a rekordok kerülnek bele az eredménytáblába, amelyek értéke a küszöb1-nél nagyobb és a küszöb2-nél kisebb (az egyenlıség mindkét küszöbértéknél megengedett), azaz egy értéktartomány meghatározására szolgál;

� LIKE „minta” : azok a rekordok kerülnek bele az eredménytáblába, amelyek formailag (!) eleget tesznek a mintában megadott leírásnak – azaz szemben az elızı kettıvel, ez a predikátum nem vizsgálja a mezı értékét, csupán azt, hogy a mezıt alkotó karakterek (típustól függetlenül) úgy néznek-e ki, mint azt a minta leírja. A mintában helyettesítı karakterek használhatóak (a kérdıjel (?) pontosan egy tetszıleges szimbólumot jelöl, a csillag (*) tetszıleges számú, bármilyen karaktert jelent), amelyek segítségével az ismeretlen vagy nem meghatározható részre hivatkozhatunk. Figyelem: a LIKE típus-független predikátum, ami azt jelenti, hogy rá nem vonatkozik a típusok jelölésének kényszere: a LIKE után minden esetben idézıjelek között szerepel a minta!

Végül az egyazon tulajdonságra vonatkozó feltételek logikai összekötı jelekkel összekapcsolhatóak, a használható logikai jelek az AND („ÉS”), OR („VAGY”) és a NOT („NEM”, tagadás). Az egyes feltételeket célszerő (a jobb áttekinthetıség végett) külön-külön zárójelbe tenni – ekkor a logikai összekötık a zárójelek közé kerülnek.

Ahhoz, hogy kicsit jobban megértsük a feltételek mőködését, néhány példa:

1. feltételek relációs jelekkel:

� >100 : azok a rekordok, amelyeknél az adott (numerikus) tulajdonság értéke 100-nál több;

� <>”Budapest” : azok a rekordok, ahol az adott (szöveges) tulajdonság értéke nem a „Budapest” szó. Figyelem: az Access nem tesz különbséget kis- és nagybető között, de figyelembe veszi a szó elején álló szóközöket!;

2. feltételek predikátumokkal:

� IN (#2003.06.01#, #2003.07.01#, #2003.08.01#) : azok a rekordok, ahol az adott (dátum) tulajdonság értéke 2003. június, július vagy augusztus 1.

� BETWEEN „K” AND „O” : azok a rekordok, ahol az adott (szöveges) tulajdonság elsı betője az ábécé K és O közötti valamelyik betőjével egyezik meg;

� LIKE „1?1” : azok a háromjegyő számok, amelyek elsı és utolsó jegye 1;

� LIKE „*.03.*.” : az összes márciusi dátum(!)

3. összetett feltételek:

13 Az MS Access kompatibilitása sajnos ezen a téren kissé hiányos: pl. az egyes nemzeti változatok (angol, magyar) eltérı módon értelmezik és kezeli a dátum típusú adatokat (már a dátumértékek megadása sem tetszıleges), vagy a logikai típusú értékeket.

46

� (<100) OR (>200) : a 100-tól 200-ig terjedı számok kivételével az összes szám;

� (LIKE „*3*”) AND (BETWEEN 1000 AND 2000) : azok az 1000 és 2000 közötti számok, amelyekben van 3-as (akármelyik helyiértéken)

A feltételrács mőködésével kapcsolatban még egy dolgot kell megjegyezni: amennyiben egy lekérdezésben több feltételt is alkalmazunk (jellemzıen eltérı tulajdonságokra, hiszen ha ugyanazon tulajdonságra vonatkozik több feltétel, azt logikai összekötı jelekkel fel tudjuk írni egyetlen feltételként!), akkor az egyes feltételek elhelyezkedése határozza meg a köztük levı összefüggést: azok a feltételek, amelyek a feltételrács azonos sorában szerepelnek, egyszerre kell, hogy teljesüljenek (azaz „ÉS” logikai kapcsolat van köztük), míg a különbözı sorokba írt feltételek valamelyikének elég teljesülnie (azaz „VAGY” logikai kapcsolat van köztük).

Példa:

NÉV FIZETÉS NÉV FIZETÉS

=”KISS” <100000 =”KISS”

<100000

21. Ábra – Több feltétel egy lekérdezésben

A 21. ábra bal oldalán látható esetben az eredménytáblába azon KISS nevő dolgozók adatai kerülnek bele, akiknek a fizetése nem éri el a 100 000 Ft-ot (egy sorban szerepelnek a feltételek: mindkettınek teljesülnie kell!). A jobb oldali esetben azonban a lista tartalmazza az összes KISS nevő dolgozó adatát (függetlenül a fizetésének a nagyságától) és az összes olyan dolgozó adatát, akinek a fizetése nem éri el a 100 000 Ft-ot (függetlenül attól, hogy hogyan hívják)... Miért? Mivel nem azonos sorban szerepel a két feltétel, elég, ha csak az egyik teljesül!

A lekérdezés összeállítása során (ha használjuk) nagy segítség a nézetváltó: bármikor átválthatunk tervezı nézetbıl adatlap nézetbe (hogy megnézzük, a lekérdezés jelenlegi beállításaival milyen rekordok alkotják az eredménytáblát) és vissza (hogy adott esetben tovább alakítsuk vagy finomítsuk a lekérdezésünket). A kész lekérdezést elmenthetjük (egyedi névvel kell rendelkeznie, mint az összes eddig megismert adatbázis-objektumnak, ha nem mentettük el, a lekérdezés bezárásakor az Access automatikusan felajánlja a mentést), az elmentett lekérdezéseinket bármikor megnyithatjuk a „Megnyitás” (ebben az esetben végrehajtódik a benne meghatározott mővelet, tehát egyszerő lekérdezés esetén megjelenik az eredménytábla) vagy a „Tervezés” (ebben az esetben visszakapjuk a QBE felületet, ahol tovább alakíthatjuk a lekérdezés szerkezetét) parancsgombok segítségével.

3.5.2. Egyszer ő lekérdezések A lekérdezések az adatbázis-kezelés leguniverzálisabban használható eszközei. Szinte

minden feladat megoldásában alkalmazhatóak, éppen ezért nehéz általánosan megfogalmazni, milyen jellemzıkkel rendelkeznek. A következıkben néhány, a mindennapi munkában viszonylag gyakran felmerülı probléma megoldására szolgáló lekérdezés-típust tekintünk át. Ehhez a lekérdezések két alapvetı típusát további csoportokra bontjuk:

1. egyszerő lekérdezések:

a) listák: az adatbázisban tárolt összes vagy csak bizonyos tulajdonságokra vonatkozó értékek megjelenítése a tárolással megegyezı vagy attól eltérı (rendezett) sorrendben;

47

b) szőrık: feltételes lekérdezések, az adatbázis azon rekordjait jeleníti meg, amelyek a megadott feltételeknek eleget tesznek;

c) leszámláló típusú lekérdezések: bizonyos rekordok azonos értékei alapján az adatok csoportosítását illetve a teljes adatbázisra vagy az adatcsoportokra vonatkozó meghatározott számítási mőveleteket megvalósító lekérdezések;

d) származtatott értékő lekérdezések: az adatbázisban tárolt adatok alapján képletek és/vagy függvények segítségével újabb értékeket meghatározó lekérdezések.

2. adatmódosító lekérdezések

a) frissítı lekérdezés: egy tulajdonság valamennyi (esetleg adott feltételnek eleget tevı) értékének megváltoztatására szolgáló lekérdezés;

b) törlı lekérdezés: rekordok törlésére szolgáló lekérdezés.

3. paraméteres lekérdezések: a lekérdezés végrehajtása során a felhasználó által (az egyes végrehajtások között változtatható módon) megadott értéktıl függı lekérdezések – azért képez külön csoportot, mert valamennyi korábban felsorolt típusú lekérdezéssel együtt alkalmazható.

A listák a legegyszerőbb lekérdezések. Az adattábla meghatározása után a szerkesztırácsra felvesszük azokat a tulajdonságokat, amelyeket az eredménytáblában meg szeretnénk jeleníteni (amennyiben az összes tulajdonságot látni szeretnénk, használhatjuk a QBE rács „Mezı” sorában a legördülı mezılistában található csillag (* ) szimbólumot). Alapesetben a rekordok ugyanabban a sorrendben jelennek meg, mint ahogy az adattáblában letárolásra kerültek, ezen a megfelelı tulajdonság (ami szerint rendezni szeretnénk az adatbázisunkat) „Rendezés” sorhoz tartozó mezıjében a legördülı listából a megfelelı rendezési irányt kell csak kiválasztanunk.

A szőrık használatához a megadott tulajdonság alatt a „Feltételek” sor(ok)ban kell megadni azt a feltételt (vagy feltételeket), ami alapján ki szeretnénk válogatni az adatbázis rekordjait. Az eredménytáblába csak azok a rekordok kerülnek bele, amelyek a megadott feltétel(ek)nek eleget tevı értékekkel rendelkeznek.

A 22. ábrán két egyszerő lekérdezést láthatunk, a bal oldalon a lekérdezés terve, a jobb oldalon a lekérdezés eredménytáblájának részlete látható. Az elsı lekérdezés eredménytáblája teljes egészében megegyezik az adattáblával, a második lekérdezés névsor szerint rendezetten jeleníti meg a budapesti munkatársak minden adatát. Vajon miért kapcsoltuk ki a megjelenítést a NÉV és a VÁROS oszlopokra?

48

22. Ábra – Listázó és szőrı lekérdezések

A leszámláló típusú (szakirodalomban gyakran használt jelzıvel „aggregáló”) lekérdezések a legfontosabb statisztikai számításokhoz nyújtanak segítséget: az adatbázisban tárolt (vagy valamilyen feltételnek eleget tevı) értékek számosságát („hány (darab) vidéki munkatársunk van?”), összegét („mennyi volt az elmúlt hónapban az összes költség?”), átlagát („átlagosan hány napot töltött XY szabadságon az elmúlt 5 évben?”), szélsıértékeit („mekkora a legmagasabb és a legalacsonyabb fizetés?”), és egyéb statisztikai jellemzıit (szórás, szórástól való eltérés, stb.) határozhatjuk meg a segítségükkel. Ugyanebbe a típusba sorolja az Access azokat a lekérdezéseket is (nem véletlenül, hiszen a két tevékenység nagyon gyakran jár együtt!), amelyek nem végeznek konkrét számítási mőveletet, hanem kigyőjtik az adatbázis azon elemeit, amelyek egy adott tulajdonságban ugyanazt az értéket tartalmazzák: azaz csoportosítják az adatokat. Ahhoz, hogy egy egyszerő lekérdezésben ezek a mőveletek elvégezhetıek legyenek, ahhoz a lekérdezés tervezı rácsát át kell alakítanunk: ehhez tervezı nézetben14 az eszköztár középsı részén elhelyezkedı „Összesítés” (alakja szumma (ΣΣΣΣ)) ikonra kell kattintanunk (de elérhetı a „Nézet” menü „Összesítés” menüpontja alatt is).

Ennek hatására a QBE rács bıvül egy újabb sorral („Összesítés”), amelyben legördülı listából választhatjuk ki a megfelelı mőveletet. Ennek a sornak a legfontosabb jellemzıje, hogy minden tulajdonsághoz kötelezı valamilyen összesítı mőveletet rendelni – azaz leszámláló típusú lekérdezésben csak olyan tulajdonságokat vehetünk fel a QBE rácsra,

14 Emlékezzünk: minden új lekérdezés egyszerő lekérdezésként jön létre, és csak az adattábla hozzáadása után változtathatjuk meg a típusát!

49

amely szerint csoportosítani akarjuk a rekordjainkat (az összesítés sorban a „Group by” mővelet szerepel), vagy amelyre valamilyen feltétel vonatkozik (az összesítés sorban a „Where” mővelet szerepel) vagy amivel valamilyen leszámlálási mőveletet akarunk végezni (az összesítés sorban a mővelet angol megfelelıje szerepel: darabszám: Count, összegzés: Sum, átlag: Avg, legnagyobb érték: Max, legkisebb érték: Min , stb.). További megszorítás, hogy az a tulajdonság, amelyre feltétel vonatkozik, nem szerepelhet az eredménytáblában (a „Megjelenítés” sorban az Access automatikusan kikapcsolja a pipát és nem is kapcsolhatjuk vissza!)

23. Ábra – Leszámláló lekérdezés I.

24. Ábra – Leszámláló lekérdezés II.

A 23. és a 24. ábrán a leszámláló típusú lekérdezésekre láthatunk egy példát. A lekérdezés a budapesti kerületekre vonatkozóan győjt ki adatokat (amolyan „állatorvosi ló” módjára: a lehetıségekhez képest mindent igyekszik bemutatni: az eredménytáblából az olvasható ki, hogy az adatbázisban tárolt személyek adatai alapján hányan laknak az egyes kerületekben, mennyi kerületenként az átlagfizetés és mikor született az egyes kerületek legidısebb lakosa). Figyeljük meg a lekérdezés tervét és próbáljuk meg értelmezni az eredménytáblában látható adatokat: mi miért szerepel vagy nem szerepel? (Az eredménytábla oszlopneveit ennél a lekérdezéstípusnál az Access automatikusan állítja elı, de ez természetesen megváltoztatható, ahogy azt a késıbbiekben (az álneveknél) látni fogjuk.)

50

A leszámláló típusú lekérdezések megértéséhez és helyes használatához egyfajta elengedhetetlen egyfajta szemléletmód: elsı lépésben azt kell megfogalmazni, mi az a (számszerő! ne feledjük: a leszámláló lekérdezés számol!) információ, amire szükségünk van, azután meg kell határozni, hogy ehhez mely tulajdonságok használatára lesz szükség, végül pedig meg kell határozni, hogy az egyes tulajdonságokhoz milyen mőveletet rendeljünk hozzá. Fontos megjegyezni, hogy téves (mert gyakori hibához vezetı) az az elképzelés, hogy a leszámláló lekérdezésben a felhasznált tulajdonságokhoz kapcsolódó adatokat is meghatározhatunk: ha pl. a fenti lekérdezésben arra is kíváncsiak lennénk, hogy ki a legöregebb az adott kerületben, a NÉV tulajdonság hozzáadása elrontaná az egész lekérdezésünket – ugyanis nem tudunk hozzá mőveletet rendelni (nem csoportosítani akarjuk a neveket, nem akarjuk megszámolni-átlagolni-összegezni ıket, feltétel sem vonatkozik rá: ha viszont nem kapcsolódik hozzá mővelet, nem is szerepelhet ebben a lekérdezésben)!

A származtatott értéket elıállító lekérdezések létjogosultságának megértéséhez elevenítsük fel az adatok redundáns tárolásával kapcsolatban megfogalmazott fenntartásainkat! Ugyanis ebbıl következik, hogy egy jól szervezett adatbázisban nem tárolunk olyan adatokat, amelyek más, tárolt adatok felhasználásával elıállíthatók. Például, ha a nyilvántartásban szerepel a dolgozó órabére és az adott hónapban munkában eltöltött ideje, akkor felesleges (és a számos hiba lehetısége miatt veszélyes is) tárolnunk a fizetését, hiszen az elızı két adatból egy egyszerő szorzással bármikor elıállítható. Az adatbázisban tárolt adatokkal végzett mőveletek eredményeként elıálló új ismeretet nevezzük származtatott adatnak. Ebbıl következik, hogy a származtatott értéket elıállító lekérdezésekben mőveleteket kell megadnunk: képleteket kell felírni, amelyek alapján az adatbázis-kezelı kiszámíthatja a hiányzó információt.

A kérdés csak az, hogy a QBE rács kötött szerkezetébe (ahogy azt az eddigiekben már láthattuk, minden sornak megvan a saját szerepe!) hová és milyen módon írjuk be a képletet? Mivel a képlet eredményét meg szeretnénk jeleníteni (azaz a kiszámolt értéknek szerepelnie kell az eredménytáblában – különben miért végeztük volna el a mőveletet?), kézenfekvı, hogy a képletet a QBE rács azon sorába írjuk, ahol az eredménytábla tartalmát meghatározzuk: a „ Mezı” sorba. A képlet bevitelére használhatjuk a „Kifejezés szerkesztıt” (a „Mezı” sor megfelelı mezıjében az egér jobb gombjának megnyomására megjelenı gyorsmenübıl választható ki) vagy bevihetjük közvetlenül a billentyőzetrıl is. A képletben a hagyományos mőveleti jelek (összeadás (+), kivonás (-), szorzás (*), osztás (/), hatványozás (^), szövegösszefőzés (&) ) mellett a (feltételeknél ismertetett) összehasonlító és logikai operátorokat (<, >, =, <>, AND, OR, NOT), a zárójeleket és függvényeket (a függvények neve után mindig zárójelek között adjuk meg a paramétereket) használhatunk.

A képlet szerkezetét tekintve két részbıl áll, ezeket kettıspont (:) választja el egymástól: a kettıspont elıtt a képlet neve szerepel (emlékezzünk: az eredménytábla oszlopait azonosítani kell, alapértelmezés szerint az eredménytábla oszlopneve megegyezik az adattábla oszlopnevével, de származtatott érték esetén az adattábla nem tárolja ezt az adatot, tehát neve sincs!), a kettıspont után pedig maga a képlet. Amennyiben a képletben az adatbázis valamely oszlopának az értékeire hivatkozunk (a származtatott értékek jellemzıen ilyenek!), akkor az oszlop nevét szögletes zárójelek ([, ]) között kell megadni a képletben.

Példa képletekre:

UjFizetés: [FIZETÉS]+5000

KezdıBető: Left([NÉV],1)

A képletek használatával kapcsolatban két megjegyzést kell még tennünk: egyrészt, hogy (ahogy az a fenti példából is látható), az Access a függvények terén ragaszkodik a hagyományos angol elnevezésekhez (ami némi kényelmetlenséget jelent a függvények

51

használatakor, de ebben segíthet a „Kifejezés szerkesztı”), másrészt (és ez a fontosabb) a megismert módszer (tudniillik, hogy az eredménytábla oszlopának a nevét megadhatjuk oly módon is, hogy a megjelenítendı adat elé beírjuk a megjeleníteni kívánt nevet és a kettıt kettısponttal választjuk el egymástól) minden lekérdezésben használható – azaz az eredménytábla oszlopneveinek nem kell megegyeznie sem a forrástábla oszlopneveivel, sem az Access által használt alapértelmezésekkel (nézzük meg újra a 24. ábra oszlopneveit!). Az eredménytábla felhasználó által definiált oszlopneveit nevezzük álneveknek.

És ugyan külön csoportba soroltuk, de hasonlóképpen mőködnek (olyannyira, hogy az elsı paraméteres lekérdezését valószínőleg a legtöbb felhasználó akaratlanul (tévedésbıl) hozza létre...) a paraméteres lekérdezések is: amennyiben a lekérdezésben olyan adatot szeretnénk felhasználni, amely a lekérdezés tervezése során nem ismert (azaz nem tartalmazza az adattábla és képlettel sem állítható elı), akkor az oszlopnevekhez hasonlóan tetszıleges (de minden létezı oszlopnévtıl különbözı) szöveget írhatunk szögletes zárójelek közé. A lekérdezés végrehajtásakor az Access felismeri, hogy nem egy oszlopra hivatkoztunk (ezért van az, hogy az elsı paraméteres lekérdezés általában véletlenül jön létre: elgépeljük a képletben az oszlopnevet...), és egy párbeszédablakban bekéri a felhasználótól a kérdéses értéket és a továbbiakban ezt az értéket használja. A paraméter azonosítójának mérete nem lehet 255 karakternél hosszabb, de egyébként szinte bármi lehet: amit a szögletes zárójelekbe írunk, az megjelenik párbeszédablakban – ily módon tudathatjuk a felhasználóval, hogy milyen jellegő információra van szükség. A paraméter értékét a QBE rács azon soraiban használhatjuk, ahol egyébként is megadhatunk oszlopneveket, azaz a „Mezı” és a „Feltétel” sorokban.

Összefoglalásként nézzük meg a következı három ábrát (25., 26. és 27. ábra)! A 25. ábrán a lekérdezés tervét láthatjuk: a VÁROS és a FIZETÉS oszlopokban szögletes zárójelek között olyan kifejezések szerepelnek, amilyen nevő oszlopokat nem tartalmaz az adattáblánk (ezek lesznek a paraméterek), a FIZETÉS értékét pedig rendre megnöveljük 5000-rel és az így kapott értékeket az eredménytábla UJFIZ nevő oszlopába helyezzük el (származtatott érték, a negyedik oszlopban). A lekérdezés végrehajtásakor az Access bekéri az összes általa ismeretlen értéket (a három paramétert) és a megadott adatokkal helyettesíti a lekérdezésben a paramétereket (azaz a feltételeink átalakulnak, mintha eleve a feltételrácsba írtuk volna be a paraméterként megadott értékeket) és ennek megfelelıen állítja elı az eredménytáblát.

Látható, hogy a paraméterek segítségével egyetlen lekérdezéssel számos különbözı esetet kezelhetünk: a paraméter aktuális (a lekérdezés indításakor megadott) értékének függvényében más és más eredménytáblát kapunk. Még egyszer hangsúlyozzuk: minden lekérdezés paraméterezhetı!

52

25. Ábra – Paraméteres származtatott értéket tartalmazó lekérdezés terve...

26. Ábra - ...indítása...

27. Ábra - .. és eredménye

3.5.3. Adatmódosító lekérdezések Az egyszerő lekérdezésekkel való megismerkedés után térjünk át az adatmódosító

lekérdezésekre! Annak érdekében, hogy ezeket a lekérdezéseket is hatékonyan és biztonsággal kezelhessük, elevenítsük fel az adatmódosító típusba tartozó lekérdezések legfontosabb jellemzıit!

Az elsı a két lekérdezés-típus közti mőködésbeli különbség: az egyszerő lekérdezés „csupán” felhasználja az adattábla tartalmát, az adatmódosító viszont meg is változtatja azt! Ennek a következménye az, hogy ezek a lekérdezések külön odafigyelést érdemelnek, ami fıleg akkor érthetı, ha visszaemlékszünk arra, hogy az adatbázis-kezelésben egy-egy mővelet

53

eredménye (a mővelet hatására elıálló új vagy megváltozott adatrekord vagy adattábla) azonnal elmentésre kerül, tehát a „Visszavonás” mőveletet csak korlátozottan alkalmazható.

A másik sajátossága az adatmódosító lekérdezéseknek, hogy nem hoznak létre eredménytáblát. Nincs is rá szükségük, hiszen a meghatározott mőveletet közvetlenül az adattáblán hajtják végre. Ebbıl a viselkedési jellemzıbıl viszont az következik, hogy (az egyszerő lekérdezésekkel ellentétben) a szerkesztés során nem váltogathatunk a lekérdezés tervezı és adatlap nézete között (ugyanis ez utóbbi nem sok információval szolgál a lekérdezés eredményét tekintve...).

Végül ismét felhívjuk a figyelmet a „Lekérdezések” munkaterület „Megnyitás” parancsgombjának mőködésére: a parancsgomb hatására a lekérdezés végrehajtódik, és az eredménye jelenik meg! Ez egyszerő lekérdezések esetén nem okozott gondot (sıt, pontosan ez volt a célunk: a lekérdezés eredményeként elıálló eredménytábla létrehozása volt a lekérdezés feladata), azonban adatmódosító lekérdezés esetén ez azt jelenti, hogy minden egyes megnyitás ismételten végrehajtja a lekérdezésben foglalt (módosító) mőveletet – azaz ha létrehozunk egy adatmódosító lekérdezést, amely megemeli a munkatársak fizetését 3,5%-kal, akkor a lekérdezés következı megnyitásakor... Éppen ezért a már elkészített és elmentett adatmódosító lekérdezéseinket minden esetben tervezı nézetben (a „Tervezés” parancsgomb segítségével) nyissuk meg!

Felmerül viszont ebben az esetben a kérdés, hogy akkor hogyan hajtsuk végre ezeket a módosításokat? Nos, az adatmódosító lekérdezések végrehajtásának legbiztonságosabb módja a lekérdezés közvetlen (direkt) végrehajtatása, a futtatás. Ezt a mőveletet a lekérdezés tervezı nézetének eszköztárában középen elhelyezkedı piros felkiáltójel alakú ikonnal vagy a „Lekérdezések” menü „Futtatás” parancsával kezdeményezhetjük. Tekintettel arra, hogy ezek a mőveletek módosítják az adattábla tartalmát, az Access figyelmeztet („biztosak vagyunk abban, hogy meg kívánjuk változtatni az adattáblát?”) és statisztikát készít („hány rekord érintett a lekérdezésben?”), és csak akkor hajtja végre, ha ezekre a kérdésekre igennel válaszolunk.

Annak érdekében, hogy a fenti megkötések minél könnyebben ellenırizhetıek legyenek, az Access a lekérdezések munkaterületen megkülönbözteti az egyszerő és az adatmódosító lekérdezések ikonját: az egyszerő lekérdezés két táblázatot ábrázoló ikonja helyett az adatmódosító lekérdezések ikonja egy fekete felkiáltójel, elıtte pedig a lekérdezés altípusára utaló szimbólum (sárga ceruza jelzi a frissítı, piros kereszt a törlı lekérdezéseket).

És végezetül még egy emlékeztetı: minden lekérdezés egyszerő lekérdezésként hozható létre és csak az adatforrás (a lekérdezésben szereplı oszlopokat tartalmazó tábla vagy táblák) megadása után alakíthatjuk át más típusúvá! Ehhez létre kell hoznunk egy új lekérdezést (tervezı nézetben), az adattábla hozzáadása után pedig vagy az eszköztár „Lekérdezés típusok” ikonja által reprezentált legördülı listából vagy a „Lekérdezések” menübıl kiválasztani a megfelelı típust. (28. ábra)

28. Ábra – Lekérdezés típusok

54

Nos, ennyi ráhangolódás után nézzük meg az adatmódosító lekérdezések két legjelentısebb típusát részletesebben!

A frissítı lekérdezés – elnevezése (pontosabban a fordítása, mert az angol eredeti („update”) híven tükrözi a lekérdezés szerepét) talán nem a legszerencsésebb, bár kétségkívül jól hangzik – az adatmezık értékének megváltoztatására szolgál. Eddigi ismereteink alapján gondolhatjuk úgy, hogy egy eszközzel van dolgunk, hiszen ezt a mőveletet el tudjuk végezni őrlapok segítségével (vagy közvetlenül az adattáblában), de ne feledkezzünk meg arról, hogy az adatbázis-kezelés (általában) nem néhány tíz, hanem néhány százezer rekordra optimalizál...

Miután a lekérdezésünket átalakítottuk frissítı típusúra, a QBE rács szerkezete megváltozik: eltőnik a „Rendezés” és a „Megjelenítés” sor és megjelenik „Módosítás” sor. Ebbe a sorba kerül az a kifejezés, amire a „Mezı” sorban megadott tulajdonság értékeit meg szeretnénk változtatni. Figyelem! A „ Módosítás” sorba nemcsak állandó értéket, hanem képletet is írhatunk (a származtatott értéket elıállító lekérdezéseknél tárgyalthoz hasonló módon, azaz amennyiben a képletben az adatbázis valamelyik tulajdonságának az értékére hivatkozunk, akkor a tulajdonság nevét szögletes zárójelek ([,]) közé kell tenni). Gyakran elıforduló típushiba, hogy nem megfelelıen adjuk meg a módosítás után kívánt értéket, ahogy azt a következı példa is szemlélteti (29. ábra):

29. Ábra – Frissítı lekérdezések

Mi a hiba? A bal oldali lekérdezésben a FIZETÉS új értéke (ahogy az a „Módosítás” sorban is látható) +1000 (olv. „plusz ezer”) lesz – ez azonban nem összeadás, hiszen hiányzik a másik összeadandó! (hanem csak egy pozitív elıjel) – azaz ennek a mőveletnek a hatására mindenkinek 1000 Ft lesz a fizetése... A helyes lekérdezés a jobb oldalon látható, amelyben a módosítás hatására elıálló új érték FIZETÉS tulajdonság aktuális értékéhez (az oszlop nevével hivatkozunk az értékeire, az oszlopneveket pedig szögletes zárójellel jelezzük) adódik hozzá 1000, így mindenki fizetése 1000 Ft-tal megnı. (Emlékeztetıül: ezek a változások csak a lekérdezés végrehajtásakor érvényesülnek, amit vagy (tervezı nézetben) a „Futtatás” paranccsal vagy (elmentett lekérdezés esetén) a lekérdezés megnyitásával kezdeményezhetünk!)

Természetesen a módosítani kívánt rekordok körét ennél a lekérdezés típusnál is korlátozhatjuk alkalmas módon megadott feltételek segítségével.

A törlı lekérdezés mőködése (ha lehet) még egyszerőbb: miután a lekérdezés típusát törlıre változtattuk, a QBE rácsban megjelenik a „Törlés” sor, ahol a törlés hatókörét tudjuk megadni: nevezetesen azt, hogy az adattábla összes rekordját törölni kívánjuk (ebben az esetben a „Mezı” sorban csak a csillag15 (*) szerepelhet, a „Törlés” sorban pedig a „From” kulcsszó) vagy csak bizonyos feltételnek eleget tevı rekordokat (ekkor a „Mezı” sorban annak a tulajdonságnak a neve szerepel, amire a „Feltétel” sorokban szereplı feltételek vonatkoznak, a „Törlés” sorban pedig a „Where” kulcsszó16).

15 Az összes tulajdonság együttesét reprezentáló szimbólum. 16 Ebbıl persze az is következik, hogy amennyiben egy tulajdonságot a hozzáadunk a törlı lekérdezéshez, akkor a törlés típusa csak Where lehet és hogy ekkor kötelezı feltételt is megadni, ellenkezı esetben az összes rekord

55

És ezzel elérkeztünk az Access leggyakrabban használt komponenseivel való ismerkedésünk végére. Az ebben a fejezetben bemutatott eszközök és módszerek általában elegendıek a napi adatkezelési feladatok megoldására, de természetesen az Access az ismertetetteken túl számos (jelen jegyzetben nem tárgyalt) elemmel rendelkezi, mind az objektumok, mind az adatbázis-kezelést hatékonyabbá és biztonságosabbá tevı technikák terén. Bízunk azonban abban, hogy a tárgyalt alapismeretek birtokában immár bárki képes lehet mind újabb eszközök használatának elsajátítására, mind a tárgyalt megoldások nem részletezett jellemzıinek megismerésére és mőködésének megértésére.

Egyetlen olyan elemre külön szeretnénk felhívni a figyelmet, amely nélkül gyakorlati adatbázis-kezelés nem képzelhetı el: a jegyzetben tárgyalt módszerek mindegyike egyetlen adattábla meglétét tételezte fel – a gyakorlatban általában több adattáblában (célszerő elrendezésben) található információval kell dolgoznunk, ennek kezeléséhez pedig elengedhetetlen az Access kapcsolat-fogalmának ismerete és mőködésének megértése.

Végezetül pedig ismételten szeretnénk megjegyezni, hogy az Access nem az egyetlen megoldási lehetıség az adatbázis-kezelési problémákra (ám valószínőleg az egyik legkönnyebben megismerhetı kezelıfelülettel rendelkezik), így az itt tárgyalt eszközök és fogalmak alkalmazhatók bármilyen relációs adatbázis-kezelı rendszer használata esetén is.

törlésre kerül (az „üres” feltétel minden rekordra igaz!) – amibıl pedig látható, hogy a törlı lekérdezésben csak és kizárólag olyan tulajdonságok szerepelhetnek, amelyre valamilyen feltétel vonatkozik!

56

4. Összefoglalás

4.1. Az adatmodellt ıl a jelentésig Jelen jegyzetben az adatbázis-kezelés legfontosabb alapfogalmait és gyakorlatban

felmerülı problémákat és azok megoldására alkalmas módszereket tekintettük át. Láttuk, hogy az adatbázis-kezelés minden esetben tervezési, megvalósítási és alkalmazási jellegő tevékenységek sorozata. Az adatbázis-kezelı rendszerek (bár általában megkísérlik megkönnyíteni a tárolási szerkezet kialakítását és számos eszközt biztosítanak az adatbázisban felmerülı hibák kivédésére vagy kijavítására) hatékony mőködéséhez elengedhetetlen egy jól megtervezett rendszer, az adatbázis sémája vagy modellje.

Ennek a modellnek (relációs adatbázis-kezelı rendszerek esetén) alapvetı elemei az adattáblák, amelyekben szervezett módon, a tárolni kívánt adatok egyes jellemzıit elemi részekre bontva (tulajdonságok), bizonyos tartalmi és mőködésbeli megszorításoknak megfelelıen helyezkednek el az adatok (rekordok). Az adattáblák szerkezetének kialakításakor törekedni kell arra, hogy egy adattáblában a lehetıségekhez mérten csak egyetlen típusú adatot tároljunk (egy filmes adatbázisban pl. filmek táblában csak az egyes film (általános, közös, minden filmre jellemzı) adatait (cím, mőfaj, hossz, stb.), a rendezı és a szereplık nyilvántartása külön-külön táblákban történhet) – az ily módon szétdarabolódott információ tartalmának helyreállítását szolgálják az adattáblák közti összefüggéseket meghatározó kapcsolatok.

Az adattáblákon különbözı típusú mőveleteket végezhetünk el, a legfontosabb alapmőveletek közé az adatok felvitele, karbantartása (beleértve a javítás és a törlés mőveletét) és a tárolt adatok (illetve a köztük fennálló összefüggések) visszakeresése, feldolgozása tartozik.

A megismert adatbázis-kezelı rendszerben, az MS Access-ben minden egyes mőveletet különbözı adatbázis-objektumok segítségével oldhatunk meg. Az egyes objektumtípusok egymástól függetlenül (munkaterületeken) tárolódnak, a munkaterületek kezelése lényegében egységesnek tekinthetı, de az egyes munkaterületek objektumai mind kezelésében, mind jellemzı tulajdonságaikban alapvetıen eltérnek egymástól.

Megismerkedtünk a tábla típusú objektumokkal, mint a tárolási szerkezet meghatározásának és módosításának eszközével, az őrlapokkal, mint az adatok hatékonyabb bevitelét lehetıvé tevı komponenssel, sorra vettük a legalapvetıbb adatkezelési mőveleteket megvalósító lekérdezés-típusokat és áttekintettük az adatok formázott megjelenítését lehetıvé tevı jelentéseket. Nem hangsúlyoztuk az egyes részek tárgyalása során, de reméljük, így is észrevehetı volt, hogy az egyes komponensek nem függetlenek egymástól: együttmőködve képesek biztosítani egy kényelmes adatkezelési környezetet.

Az elsajátított ismeretek birtokában remélhetıleg senkinek nem okoz gondot egy létezı adatbázissal kapcsolatos feladatok megoldása, de a tárgyalt megoldásokat tervezési (elméleti) jellegő ismeretekkel kiegészítve (az irodalomjegyzékben szereplı szakkönyvek megfelelı alapot biztosítanak ehhez) akár egyéni adatbázis kialakításához is bátran hozzákezdhet bárki.

Ennek reményében és azzal a bizalommal, hogy élvezettel kalandoztak velünk együtt az adatbázis-kezelés (hol bonyolultabb vonalvezetéső, hol látványosabb) útvesztıjében, eredményes munkát kívánunk.

57

5. Irodalomjegyzék Napjainkban a Microsoft termékeivel kapcsolatos kiadványoknak jóformán se szeri, se

száma. Úgy gondoljuk, bármelyik kiadvány, amely az adatbázis-kezelés témakörét az MS Access adatbázis-kezelı programon keresztül (is) mutatja be, egyformán alkalmas arra, hogy a jegyzetben nem tárgyalt jellemzıkkel megismerkedhessen az érdeklıdı. Éppen ezért az alábbi kiadványok nem azért kerültek az irodalomjegyzékbe, mert jobbak vagy többek, mint mások, csupán azért, mert jelen jegyzet szerzıje ezeket ismeri (és mint ilyet, meri ajánlani).

� http://www.microsoft.com/hun/office/Access.mspx - A Microsoft hivatalos oldalán valamennyi termékükkel kapcsolatban részletes információt illetve a használattal kapcsolatos tippeket, ötleteket találhatunk.

� Northwind adatbázis – Az Access beépített mintaadatbázisa (elérhetı a Súgó menü Mintaadatbázisok menüpontja alatt), egy komplex adatbázis valamennyi tárgyalt (és számos nem tárgyalt) objektummal, amelyeket elemezgetve (tervezı nézet!) számos ötlettel lehetünk gazdagabbak.

� Dr. Kovácsné Cohner Judit – Dr. Kovács Tivadar – Ozsváth Miklós: Adatkezelés az MS Access 2000 alkalmazásával (Computerbooks, 2003)

� Simon András: Alkalmazások fejlesztése Accessben (Panem, 2002)

58

6. Melléklet – Access SQL Az MS Access (mint minden relációs adatbázis-kezelı) tartalmaz egy SQL

kezelıfelületet is, azaz az adatbázis-kezelés (szinte) valamennyi mővelete megvalósítható SQL parancsok segítségével is. Az SQL parancsfelület eléréséhez egy üres (adattábla nélküli) lekérdezés tervezı nézetén keresztül juthatunk el, de attól függıen, hogy milyen mőveletrıl van szó, vagy a „Lekérdezés” menü „SQL specifikus” menüpontjának „Adatdefiniáló” parancsa segítségével (a lekérdezéseket kivéve minden esetben), vagy a nézetváltó gomb legördülı listájából kiválasztva az „SQL nézet” parancsot (ez utóbbi megtalálható a „Nézet” menüben is, csak lekérdezés jellegő feladatokhoz használható17).

Ahogy azt az SQL általános tárgyalásánál már említettük, az SQL parancsnyelv: utasításokból épül fel, az utasítást mindig egy SQL parancsszó (kulcsszó) vezeti be és pontosvesszı (;) jelzi a végét, a kettı között (meghatározott szabályok szerint) pontosító, módosító, kiegészítı részek szerepelhetnek. Az SQL nem határozza meg, hogy az egyes utasításokat hogyan tagoljuk (írhatjuk egyetlen sorba folytatólagosan az egészet vagy akár minden egyes szavát új sorba – ez szinte korlátlan lehetıséget biztosít arra, hogy úgy szerkesszük meg a parancsainkat, hogy azok a késıbbiekben is áttekinthetıek legyenek), csupán azt köti ki, hogy a parancs minden egyes elemét szóközzel (a felsorolás típusú elemeket vesszıvel (,) ) kell elválasztani egymástól. Nem szabály, csak gyakran alkalmazott (konvencionális) jelölésmód, hogy az SQL kulcsszavait (a parancsokat és a nyelv kötött elemeit) CSUPA NAGYBETŐVEL, a képletek, formulák, konstansok és függvények alkotórészeit kisbetővel, a tulajdonságokat nagy kezdıbetővel írjuk.

Az elkészült SQL utasítást (az adatmódosító lekérdezésekhez hasonlóan) végre kell hajtatni, amire a Futtatás parancsot használhatjuk (tervezı nézetben ez eszköztár piros felkiáltójel alakú ikonjával vagy a „Lekérdezések” menü „Futtatás” menüpontjával). Végrehajtás elıtt az Access ellenırzi a beírt kifejezést, de csak formai (nyelvhelyességi) elemzést végez. Amennyiben hibásan adtuk meg a mőveletet, a hibajelzést követıen az Access a parancsnak arra a részére mozgatja a kurzort, ahol a hibát megtalálta – azonban ez nem azt jelenti, hogy ténylegesen az a szó vagy kifejezés a hibás: elıfordulhat, hogy a környékén (egy vesszı vagy szóköz kimaradt, stb.), vagy a megjelölt utasításrészhez kapcsolódó másik módosítóban (elírtuk egy tulajdonság nevét, nem szám típusú mezıt szeretnénk összegezni, stb.) kell a hibát keresni.

Szintén említettük már, hogy bár az SQL nemzetközi szabvány, az egyes konkrét adatbázis-kezelı programok a szabványban megfogalmazottakon túl általában bıvítik az alkalmazható mőveletek körét. Ennek ellenére igaz az is (és ez az, amiért külön foglalkozunk az Access SQL utasítás-készletével), hogy az utasítások alakja a különbözı adatbázis-kezelıkben lényegében azonos, azaz ha valaki egyszer megismerkedik ezzel az eszközzel, akkor bármilyen adatbázis-kezelıt tud használni – még ha nem is olyan kényelmesen, mint a grafikus felület által biztosított eszközök segítségével.

A következıkben az SQL utasításainak szerkezetét és mőködését tekintjük át, a lehetıségekhez képest az adatkezelés logikájának megfelelı sorrendben.

17 A legegyszerőbben úgy különböztethetjük meg a két parancsmódot, hogy amennyiben a megjelenı szövegdobozban szerepel a SELECT utasítás, akkor lekérdezés típusú mőveletet (és csak azt!) adhatunk meg, ellenkezı esetben minden mást (természetesen ekkor meg lekérdezési parancsot nem adhatunk meg).

59

Az adatbázisok kezelésére az Access SQL-ben nincsenek parancsok18, aminek az Access mőködése az oka: emlékezzünk, mielıtt bármilyen mőveletet kezdeményezhetnék, meg kell nyitnom (vagy létre kell hoznom) az adatbázist tartalmazó állományt.

Az adattábla szerkezetével kapcsolatos SQL utasítások a következık:

1. CREATE TABLE táblanév (tulajdonságok listája);

– ez a parancs az adattábla létrehozására szolgál. Létrehozáskor meg kell adni a létrejövı tábla nevét és utána zárójelek között, vesszıvel elválasztva kell felsorolni az egyes tulajdonságok jellemzıit (nevét, típusát (Figyelem! Az SQL adattípusainak elnevezése azonos az Access által használt típusnevekkel! – már csak azért sem, mert az SQL eredendıen angol szavakat használ, így a típusokra is: pl. CHAR, INTEGER, stb.), esetleges speciális jellemzıit – csakúgy, mint a grafikus felület tervezı nézetében).

Példa: hozzunk létre egy adattáblát, amelyben a dolgozó nevét (szöveges típusú tulajdonság), fizetését (numerikus típusú tulajdonság) és nemét (férfi vagy nı, de az egyszerőség kedvéért (mivel csak kétféle érték fordulhat elı, bem szövegesen hanem logikai típusú értékként tároljuk: ha értéke igaz, akkor férfi, ha hamis, akkor nı): CREATE TABLE dolgozo (Nev CHAR(30), Fizetes INTEGER, Nem BOOLEAN) ;

2. ALTER TABLE táblanév ADD COLUMN tulajdonság(lista);

ALTER TABLE táblanév DROP COLUMN tulajdonságnév(lista) ;

– a tábla szerkezetének megváltoztatására szolgáló parancsnak két alakja is van: az elsı változat egy (vagy több) újabb oszloppal bıvíti az adattáblát (az oszlopokat ugyanolyan módon kell megadni (valamennyi jellemzıjével együtt!), mint a tábla létrehozásakor), a második alak törli a megadott tulajdonság(ok)at (azok minden értékével együtt!) az adattáblából.

Példa: vegyünk fel egy újabb oszlopot a születési idı tárolására: ALTER TABLE dolgozo ADD COLUMN SzulIdo DATE ;

3. DROP TABLE táblanév;

– az adattábla törlése.

Rekordokra vonatkozó SQL parancsok:

1. INSERT INTO táblanév (tulajdonságnév(lista)) VALUES (érték(ek listája) );

– új rekord felvétele az adattáblába. Ahogy az a fenti alakból is kiderül, SQL-ben az adatok bevitele nem a legegyszerőbb: a táblanév után fel kell sorolni, mely tulajdonságoknak szeretnénk megadni az értékét (ebbıl következik, hogy nem kötelezı az összes tulajdonság értékét megadni, a ki nem töltött mezık NULL értékkel fognak rendelkezni) és a VALUES kulcsszó után ugyanilyen sorrendben kell megadni az egyes tulajdonságok aktuális értékét – az értékek típusának jelölésére ugyanazok a szabályok vonatkoznak, mint az Access-ben (azaz számokat nem kell jelölni, a szöveget idézıjelek, a dátumot kettıs-keresztek (#)

18 Az SQL szabvány definiál adatbázisra vonatkozó utasításokat is, ezek a CREATE DATABASE (létrehozás), START DATABASE (megnyitás), STOP DATABASE (bezárás), DROP DATABASE (törlés) és a SHOW DATABASE (listázás).

60

között kell megadni). Értelemszerően egy INSERT utasítással csak egyetlen rekord vihetı fel, minden újabb adat újabb INSERT utasítást igényel...

Példa: vegyünk fel egy dolgozót az elıbb létrehozott adattáblánkba (vegyük észre, hogy az oszlopok sorrendjének nem kell megegyezni a táblában elfoglalt sorrenddel, csupán annyi a kikötés, hogy az oszlopok neveinek és az oszlopok értékeinek a sorrendje feleljen meg egymásnak, továbbá azt, hogy az egyes típusokat az értékek megadásakor jelölnünk kell, és hogy a dátumot az SQL az angol dátumformátum szerint kezeli): INSERT INTO dolgozo (Nev, SzulIdo, Fizetes, Nem) VALUES („Nagy”, #05/18/1975#, 80000, TRUE) ;

2. UPDATE táblanév SET tulajdonságnév = új érték;

– rekord módosítása. Az értékadás (vesszıvel elválasztott felsorolás formájában) több tulajdonságra is megadható. Az új érték lehet konstans vagy az adattáblában tárolt értéket felhasználó kifejezés (képlet), ez utóbbi esetben a tárolt értékre ugyanolyan módon (szögletes zárójelek között a tulajdonság neve) kell hivatkozni, mint a frissítı lekérdezésben. A parancs alapértelmezés szerint az adattábla összes rekordját frissíti, de az értékadás(ok) után szerepelhet a WHERE kulcsszó, amit feltételnek kell követnie – ebben az esetben csak a feltételnek eleget tevı rekordokban fog a megadott tulajdonság értéke megváltozni. A feltételek kezelése eltér a grafikus felületen megismerttıl, ugyanis SQL-ben nem egyértelmő, hogy melyik tulajdonságra vonatkozik, így azt is jelölni kell: „tulajdonságnév – reláció – hasonlító érték” alakban.

Példa: növeljük meg Nagy fizetését 2,5%-kal: UPDATE dolgozo SET Fizetes = [Fizetes]*1,025 WHERE Nev = „Nagy” ;

3. DELETE FROM táblanév;

– rekordok törlésére szolgáló parancs, módosító nélkül az adattábla valamennyi rekordját törli, de (az UPDATE-tel azonos módon) alkalmazható a WHERE feltételes rész a törlendı rekordok kiválasztására.

Példa: töröljük az adatbázisból az 1960-as születéső dolgozókat: DELETE FROM dolgozo WHERE SzulIdo BETWEEN #01/01/1960# AND #12/31/1960# ;

És végül a lekérdezésekkel kapcsolatos mőveletek kezelésére egyetlen SQL utasítás szolgál (igaz, annak viszont meglehetısen sok módosító értelmő kiegészítı része („tag”-ja) van):

1. SELECT eredm_lista_mód tulajdonság_lista FROM forrástábla_lista WHERE feltétel_lista GROUP BY csoportosítási_mezı HAVING csoportosítás_eredményére_vonatkozó_feltétel ORDER BY rendezési szempont ;

– az a parancs egymagában szolgál (szinte) az összes lekérdezési jellegő feladat megoldására: kiválogatás, rendezés, csoportosítás, leszámlálás, származtatott

61

értékek meghatározása (vessük össze ezt a listát az egyszerő lekérdezések csoportjába tartozó tanult mőveletekkel!). A SELECT utasításban (a SELECT és a FROM záradék kivételével) az egyes részek elmaradhatnak, de amelyek szerepelnek, azok csak ilyen sorrendben követhetik egymást (azaz ha a lekérdezésben valamilyen feltételnek megfelelı rekordokat rendezetten szeretnénk megjeleníteni, akkor az ORDER BY csak a WHERE után fordulhat elı). Az egyes elemek szerepel a következı:

SELECT: az eredménytábla szerkezetének meghatározására szolgál, az utána felsorolt tulajdonságok vagy az itt megadott képletek eredménye alkotja a lekérdezés hatására kialakuló listát. Közvetlenül a SELECT parancs után megadhatók olyan módosítók, amelyek az eredménylista szerkezetére vonatkoznak (és nem annak tartalmára): az ALL kulcsszó (ezt nem kötelezı kiírni, ugyanis ez a SELECT alapértelmezett módosítója) hatására az eredménytábla valamennyi rekordja megjelenik, a DISTINCT kulcsszó kiszőri az eredménytáblából az esetleges ismétlıdéseket (azaz minden rekord csak egyszer szerepel az eredménylistában), a TOP n (ahol n egy, a kulcsszótól szóközzel elválasztott szám) kulcsszó pedig csak az eredménylista elsı n darab elemét jeleníti csak meg.

FROM : a kulcsszó után vesszıvel elválasztott lista formájában fel kell sorolni azoknak az adattábláknak a neveit, amelynek valamely tulajdonságára a SELECT parancs bármely elemében hivatkozunk19.

Példa: írassuk ki az összes különbözı vezetéknevet: SELECT DISTINCT Nev FROM dolgozo ;

WHERE : a lekérdezés feltételrendszerét bevezetı kulcsszó. A feltételek (az adatmódosító mőveleteknél már említett okokból) teljes alakban szerepelhetnek (tulajdonság – mőveleti jel vagy predikátum – összehasonlítási érték), és ugyanazt a mőveleti jel és predikátum-készletet alkalmazhatjuk, mint amivel a grafikus felület feltétel-kezelésének tárgyalásakor megismerkedtünk. Több feltételt az egyes feltételeket zárójelezve és a logikai összekötı jelek alkalmazásával adhatunk meg.

Példa: írassuk ki azoknak a nıi dolgozóknak a nevét és fizetését, akinek a fizetése nem éri el a 100 000 Ft-t: SELECT Nev, Fizetes FROM dolgozo WHERE (Nem = False) AND (Fizetes < 100000) ;

GROUP BY: azon tulajdonságok felsorolására szolgáló módosító, amelyek szerint az adattábla rekordjait csoportosítani szeretnénk (ld. leszámláló típusú lekérdezések!). A csoportosítás jellegő vonatkozó szigorú megszorítások itt is érvényesek, azaz a GROUP BY záradék alkalmazása esetén a SELECT-ben csak olyan tulajdonság szerepelhet, amelyre vagy csoportosítási mővelet vonatkozik (azaz szerepel a GROUP BY után is), vagy leszámlálási mőveletben vesz részt (ez esetben a SELECT után a leszámlálási mőveletet függvényként kell felírni: max(FIZETÉS), count(VAROS), stb.)

19 Mivel a jegyzetben nem tárgyaltuk a több adattábla kezeléséhez szükséges kapcsolat fogalmát és mőködését, ezért itt sem ismertetjük a FROM záradéknak a kapcsolatok kezelésében betöltött szerepét (a JOIN kulcsszó mőködését).

62

Példa: számoljuk ki, hogy az azonos években született dolgozóknak mennyi az átlagkeresete: SELECT YEAR(SzulIdo), AVG(Fizetes) FROM dolgozo GROUP BY YEAR(SzulIdo) ;

HAVING : szintén feltételek kezelésére szolgáló záradék, de ezen feltételek vizsgálata a rekordok csoportosítása után történik és a csoportosítási vagy leszámlálási mővelet eredményére vonatkozik – ebbıl következik, hogy ez a kulcsszó általában a GROUP BY kulcsszóval együtt szerepel.

Példa: csak azokat az éveket jelenítsük meg az elızı listából, ahol az átlagfizetés legalább 80 000 Ft: SELECT YEAR(SzulIdo), AVG(Fizetes) FROM dolgozo GROUP BY YEAR(SzulIdo) HAVING AVG(Fizetes)>80000 ;

ORDER BY: az eredménylista rendezettségét meghatározó záradék. A kulcsszó után fel kell sorolni azokat a tulajdonságokat, amelyek szerint az eredménytáblát rendezni szeretnénk (a rendezettség a tulajdonságok felsorolásának sorrendje alapján valósul meg). A rendezés irányát minden tulajdonság esetén külön-külön kell megadni közvetlenül a tulajdonság neve után írt ASC („ascending”, növekvı) vagy DESC („descending”, csökkenı) kulcsszavak segítségével.

Példa: készítsük névsor szerint rendezett listát, amelyben az azonos nevő munkatársak születési idejük sorrendjében követik egymást: SELECT Nev, SzulIdo, Fizetes, Nem FROM dolgozo ORDER BY Nev ASC, SzulIdo ASC ;

Az ACCESS SQL természetesen ennél lényegesen több utasítást tartalmaz és az is igaz, sıt az egyes utasítások bizonyos feltételek mellett alkalmazhatók együttesen is – ezáltal a grafikus felület által biztosított eszközöknél jóval hatékonyabb módon írhatók fel az adatbázis-kezelés mőveletei. Azonban azt is meg kell jegyeznünk (mint ahogy az a fenti győjteménybıl is kiderül), hogy az SQL nem definiál a megjelenítéssel kapcsolatos eszközöket (az őrlapok vagy a jelentések kezeléséhez nem nyújt segítséget), így azt mondhatjuk, hogy egy igazán kényelmes és ugyanakkor hatékony adatbázis-kezelı rendszer kialakítása során a két technológia együttes használata a legeredményesebb módszer.