2. Az adatbázisok általános jellemzıi

Átírás

1 Tartalomjegyzék 1. Bevezetés Az adatbázisok általános jellemzıi Adatok tárolásának lehetıségei Az adatkezelés problémái és megoldásai A relációs adatbázis-kezelı rendszerek jelentısége A relációs adatkezelés alapfogalmai Megvalósítások: hasonlóságok és különbségek Az SQL szabvány Adatbázisok szerepe a vállalkozás életében Papír-alapú nyilvántartások és elektronikus adattárak Igények az adatbázissal szemben: tervezés, kialakítás, üzemeltetés Összefoglalás Adatbázisok a gyakorlatban A vállalkozásokra jellemzı adattárak használata Karakteres felülető adatbázisok Grafikus felülető adatbázisok A Microsoft Access adatbázis-kezelı rendszer Általános jellemzık Felépítés: munkaterületek, mőveletek Adattárolás A táblák Adattípusok Beviteli és kiviteli eszközök Őrlapok Jelentések Adatkezelési mőveletek Lekérdezések Egyszerő lekérdezések Adatmódosító lekérdezések Összefoglalás Az adatmodelltıl a jelentésig Irodalomjegyzék Melléklet Access SQL

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. 2

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) 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 3

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. fel: Ahogy az a fenti definícióból is kiderül, egy adatbázis mindig két komponensbıl épül 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ı rendszer 1 : 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) 4

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! 5

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áziskezelı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 IMS 2 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 IDMS 3 ), 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) 6

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. 7

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áziskezelé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ı 8

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áziskezelı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. 9

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 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 álltak 4, az elsı ilyen elven mőködı programok megjelenésére egy évtizedet kellett várni 5, 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) 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útumoknak (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 (?) 10

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áziskezelé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.) 11

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 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áziskezelı 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. 12

13 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 szerint 6 ) 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: 13

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 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. 14

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 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 rendszerekkel 7 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. 15

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! Igények az adatbázissal szemben: tervezés, kialakí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ése 8 : 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. 16

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ásigé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 17

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 egyegy 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 Ö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áziskezelé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 18

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. 19

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 A vállalkozásokra jellemzı adattárak használata 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. ( 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 20

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. 21

22 5. Ábra egy karakteres felülető adatbázis indító képernyıje 6. Ábra adatbeviteli képernyı 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 22

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 23

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áziskezelı programok segítségével szinte gyerekjáték. A gyakorlati ismereteket a Microsoft Office 9 irodai programcsomag Access nevő adatbázis-kezelıjének a jegyzet készítésekor aktuális (MS Access ) 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 Á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! 24

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 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églistá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! 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) 25

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 26

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 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. 27

28 Amikor megnyitunk egy táblát, a menüsor alatt megjelenı elsı eszköztárban 10 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! 28

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ó 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 karakter), 29

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 10 5 = ). 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 közötti egész szám lehet, 2. Egész: 2 bájt, értéke és ( ) 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 tıl ig) közötti egész szám lehet, 4. Egyszeres: 4 bájt, értéke -3,4x10 38 és +3,4x10 38 közötti valós szám lehet, legfeljebb 7 tizedesnyi pontossággal, 5. Dupla: 8 bájt, értéke -1,8x és +1,8x 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 és 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 30

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 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 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 vagy a 10/24/2000 vagy a 13:55:32 vagy az 1935 január :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 december :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 31

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 Beviteli és kiviteli eszközök Ő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 ( *). 32

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 33

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. 34

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 35

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. 36

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. 37

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! 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é, 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. 38

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 39

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 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. 40

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 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. 41

42 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áziskezelı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 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 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 meg 11 (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. 42

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áblaspecifikusak), 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éget 12. 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! 43

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 44

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ölni 13 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 (# #, # #, # #) : azok a rekordok, ahol az adott (dátum) tulajdonság értéke 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. 45

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 < Ábra Több feltétel egy lekérdezésben = KISS < 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 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 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 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; 46

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? 47

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ézetben 14 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! 48

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.) 49

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 50

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ı! 51

52 25. Ábra Paraméteres származtatott értéket tartalmazó lekérdezés terve Ábra -...indítása Ábra -.. és eredménye 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 52