ISBN Felelős kiadó: Nógrádi PC Suli Kft. Írta és szerkesztette: Nógrádi László

Átírás

1 Nógrádi László Access XP alapokon (ECDL adatbázis-kezelés modul) 2005.

2 ISBN Felelős kiadó: Nógrádi PC Suli Kft. Írta és szerkesztette: Nógrádi László A könyvborító tervét készítette, és a könyvet nyomtatta: Text-Print Kft, Győr A könyv készítése során a szerző a lehető legnagyobb gondossággal jártak el. Ennek ellenére hibák előfordulása nem zárható ki, melyekért a szerző felelősséget nem vállal. Nógrádi László Minden jog fenntartva! Jelen könyv egyetlen része sem másolható, vagy sokszorosítható semmilyen formában a szerző előzetes írásbeli engedélye nélkül!

3 Access XP alapokon N apjainkban egyre több ember mindennapi munkaeszköze a számítógép. Bár a legtöbben nap mint nap írnak ugyan leveleket, készítenek táblázatokat, de az adatbázis-kezelést egyáltalán nem ismerik. Ez a könyv nekik szól, vagyis azoknak, akik már megtanulták egy szövegszerkesztő használatát, dolgoztak már táblázatkezelő programban is, de adatbázis-kezelővel még nem találkoztak. Ennek megfelelően azok az eljárások kerülnek csak ismertetésre, melyek számukra újdonságok, esetleg másként kell őket használni. Ebből adódóan nem lesz szó a fájl műveletekről, a formázásokról, a vágólap használatáról, stb. Ugyanakkor az adatbázis-kezelők rendszeresen használt elemei mellett viszonylag sok érdekességet, kiegészítő információt is tartalmaz a könyv, melyek tipográfiailag jól elkülönítve (kisebb, dőlt betűs szedéssel) jelennek meg. Szó esik az adatbázisok tervezéséről is, mely az önállóan megoldandó adatbázis-kezelési feladatokhoz nélkülözhetetlen ismeret. A könyv témakörei gyakorlati tapasztalatok alapján logikailag egymásra épülő sorrendben követik egymást. Mivel a részletes magyarázatok mellett gyakorló feladatok, és azok megoldásai is megtalálhatóak benne, a könyv nagyszerűen használható önképzésre, de ajánlható iskolai tankönyvnek és tanfolyami jegyzetnek is. A tanulást rengeteg táblázat, képernyőkép és ábra segíti, melyek minden esetben egy oldalon szerepelnek a róluk szóló leírással. Itt szeretném felhívni minden informatikát tanuló (és tanító kolléga) figyelmét további könyveimre. Az XP alapokon sorozat Jelen könyv részét képezi egy tankönyvsorozatnak, mely az érettségi, az ECDL, valamint az OKJ alap és középfokú tanfolyamok vizsgakövetelményei alapján lett összeállítva. A sorozat kötetei: Windows XP alapokon (ECDL operációsrendszer modul); Word XP alapokon (ECDL szövegszerkesztés modul); Excel XP alapokon (ECDL táblázatkezelés modul); Internet Explorer és Outlook Express (ECDL információ és kommunikáció modul); PowerPoint XP alapokon (ECDL prezentáció és grafika modul); Access XP alapokon (ECDL adatbázis-kezelés modul). PC Suli XP alapokon sorozat Azok számára, akik a fenti sorozat teljes tananyaga mellett további fontos informatikai ismereteket is el kívánnak sajátítani, ajánlom a következő könyveimet: PC Suli XP alapokon I. (eszközök, szám- és kódrendszerek, szerzői jog, Windows XP alapok, Windows kellékek, Word XP, Excel XP, Internet); PC Suli XP alapokon II. (Windows XP haladó, PowerPoint XP, Access XP, Programozási alapismeretek, HTML szerkesztés). A PC Suli I-II. is hasonló felépítésű és tematikájú, mint az Access XP alapokon, így mindkét kötetet sok kép és feladat jellemzi. Iskoláknak összeállításra került egy olyan költségtakarékos kiadás is, mely nem tartalmazza a feladatokat, így egy kötetbe, olcsóbban lehetett a tananyagot összevonni. Könyvek megrendelése, segédanyagok letöltése A fenti könyvek megrendelhetők a internet címen. Ugyancsak innét letölthető a könyvek összes feladata, valamint számtalan további, a tanulást és a tanítást támogató anyag, többek között: közel diából álló tanári prezentáció a 97-es verziókról; a DOS részletes tankönyve; rengeteg alap és középfokú OKJ-s vizsga írásbeli feladatsora; ajánlott érettségi tételsorok; próba és éles érettségik feladatsorai, stb. Befejezésül jó tanulást kívánok: Nógrádi László Nógrádi PC Suli Kft Győr, Munkácsy u

4 ECDL Adatbázis-kezelés modul A z Access az Office programcsomag MDB (Microsoft Database) adatbázisok kezelésére készített eleme. A Microsoft célja a program kifejlesztésével az volt, hogy az Office irodai programcsomag használóinak egy olyan, szervesen a rendszerbe illeszkedő fejlesztőeszközt nyújtsanak, amellyel nagymértékben automatizálva hozhatnak létre munkájukhoz kapcsolódó adatnyilvántartásokat. Az Access mindent tud, ami egy ügyviteli feladatok ellátásához szükséges adatbázis-kezelő program könnyű elkészítéséhez, valamint a kapcsolódó, haladó szintű feladatok megoldásához szükséges. Ebben a könyvben az adatbázis-kezelő működését és kezelését egy nagyobb feladat, egy raktározási rendszer elkészítésének segítségével fogjuk megismerni. Ez a módszer egy kicsit eltér az XP alapokon sorozat többi kötetében alkalmazottól, de több okból is ez látszott célszerűnek. 1. Az adatbázis-kezelés témaköre egy átlag irodai felhasználó látókörétől messze esik, ezért aztán minden csak példákon keresztül magyarázható. 2. Mivel bizonyos komplikációk feloldása gyakran hatással van egymásra, célszerű egy életszerű feladaton keresztül bemutatni a jellemző problémák megoldását. 3. A választott feladatot a gyakorlatban is elkészítve egy olyan alkalmazáshoz juthatunk, melyet szinte mindenki fel tud használni. A fejezet feladatait megoldva végtermékként ugyanis egy raktári nyilvántartó programot kapunk, amely a következőket fogja tudni: nyilvántartja a szállítók legfontosabb adatait; letárolja a raktárban tárolt anyagok és termékek alapadatait és a pillanatnyi raktárkészletet; nyomon követhető a készlet változása, mert letárolásra kerülnek a készletet növelő be-, illetve a készletet csökkentő kivételezések (csak leveszi a készletről a kivételezési jegyen megadott árukat, de nem tud számlázni). Kapcsolódhat a fejezetben elkészítendő raktárrendszerhez egy számlázó program? Természetesen igen. A probléma csak az, hogy egy számítógépes számlázó programra szigorú előírások érvényesek azért, hogy ne lehessen fiktív, vagy szabálytalan számlák alapján az államot megkárosítva könyvelni, jogosulatlanul ÁFA-t visszaigényelni, vagy más visszaélést elkövetni. Ha valaki a már kész raktár rendszerhez kapcsolódó számlázó programot szeretne készíteni, akkor annak minden vonatkozásban meg kell majd felelnie az erre vonatkozó jogszabályi előírásoknak, melyek közül a legfontosabbak: egyedi, folyamatos, nem ismételhető számlaazonosítónak kell szerepelnie minden számlán; a számla több példányban kell, hogy készüljön, de minden példányon szerepelnie kell annak sorszámának (első, második, harmadik példány); stb. 1. Az Access eszközigénye, telepítése Az Access XP az Office programcsomag szerves része, így eszközigénye és telepítése is megegyezik a Word és az Excel programokéval: a program XP verziójának hatékony futtatásához minimum Pentium III gép és 128 MB RAM ajánlott; az automatikus telepítő program az Office telepítő CD-jének behelyezése után magától elindul. Az én Office programom nem tartalmazza az Accesst! Miért? Az Access csak az Office Professional verziójában található meg. Az alacsonyabb ára miatt sokkal elterjedtebb Small Business verzióban hiába keressük, annak ugyanis nem része. Az alacsony ár egyébként csak relatíve igaz. 2. Az Access elindítása, képernyőjének felépítése A programot a Start menü Minden program elemének Office Programok pontjából a Microsoft Access opcióval, vagy az Office eszközsor megfelelő ikonjával tudjuk elindítani. A megjelenő programablak a már jól megszokott felépítésű: felül a menü és eszközsorok; középen az adatbázis-ablak; alul az állapotsor. 4

5 Access XP alapokon Menü és eszközsorok A menüből kiválasztható elemek, és maguk az eszközsorok is folyamatosan változnak, attól függően, hogy éppen mit teszünk. Ez nem jelent újdonságot, hiszen a korábban megismert programok is így viselkednek (gondoljunk csak az Excel program diagram rajzolására). Adatbázis-ablak A képernyő középső, és egyben legnagyobb részét az adatbázis-ablak foglalja el (az ábrán teljes méretre nagyítva látható), melynek bal oldalán az egyes elemnevekre kattintva válthatunk aszerint, hogy az adatbázis rövidesen bemutatásra kerülő elemei közül éppen melyikkel akarunk dolgozni. Az eszközsoron lévő ( Megnyitás ), ( Tervezés ) és ( Új ) gombok segítségével 1. Ábra: Az Access programablaka alakíthatjuk majd kedvünkre adatbázisunk éppen kiválasztott alkotóelemét. Az egyes elemekről mutatott információ függ az adatbázis-ablak nézetétől. A kérhető nézetek remélhetően ismerősek: Nagy ikonok Kis ikonok Lista Részletek Az adatbázis-ablakhoz bármikor visszatérhetünk, csak az eszközsor adatbázis-ablak ikonjára kell kattintanunk (ez az ikon csak akkor jelenik meg, ha nem látható az adatbázis-ablak). Állapotsor A képernyő alján található állapotsor ugyanúgy, mint a már megismert programoknál, most is hasznos kiegészítő információkat nyújt a pillanatnyi szerkesztési helyzetről. Az viszont általánosságként ebben a programban is leszögezhető, hogy egy adott feladatot több módon is elvégezhetünk, azaz egyező eredményhez juthatunk egy billentyűkombináció leütésével, menü kiválasztásával, illetve egy ikonra kattintással, de a menüt használva több lehetőség áll rendelkezésünkre. Abban az esetben, ha egy konkrét célunk van ugyan, de nem tudjuk, hogy azt miként valósíthatjuk meg, kattintsunk a manipulálni kívánt elemre az egér jobb gombjával. A megjelenő helyi menü tájékoztatást nyújt az adott helyen elérhető összes lehetőségről. Ha az általunk elérni kívánt esemény nem szerepel benne, akkor azt valószínűleg nem is lehet az adott szituációban végrehajtani. További segítséget kapunk az Access szituáció érzékeny súgójától, amit az F1 billentyűvel indíthatunk el. Nem így néz ki a képernyőm (nincs eszközsor és állapotsor, illetve adatbázis-ablak) A Nézet menü megfelelő opcióit indítva ki-be kapcsolhatjuk az egyes képernyőelemeket. Adatbázis-ablak pedig csak akkor van, ha megnyitottunk, vagy létrehoztunk egy adatbázist. 3. Mit ért az Access adatbázison? Míg az Excel adatbázis alatt csak magukat az adatokat érti, az Access értelmezésében az adatbázis már jelentősen több ennél: az adatbázis egy olyan komplex fájl, melynek az adatok mellett részei többek között adatbevitelt megkönnyítő űrlapok, a keresett adatok leválogatását végző lekérdezések, és a különféle formázott nyomtatási lehetőségeket nyújtó jelentések is. Egy Access adatbázis valójában tehát egy olyan öszszetett állományt jelent, ami az adott adminisztrációs, pénzügyi, termelésirányítási, vagy egyéb feladathoz kapcsolódik, és számtalan különböző szerepű összetevőből állhat. Újszerűsége és fontossága miatt tekintsük át részletesebben az egyes elemeket és szerepüket. 5

6 ECDL Adatbázis-kezelés modul Különféle adatmodellek Az Access a 70-es években megjelent relációs adatmodellre épül, melynek lényege az, hogy az adatokat több, egymáshoz kapcsolódó táblázatban tárolják. A relációs adatmodell mellett azonban két másik, ma már kevésbe elterjedt adatmodell is létezik, melyek tárgyalásával terjedelmi okokból egyáltalán nem foglalkozunk: hálós a 60-as évek elején jelent meg; hierarchikus a 60-as évek végén fejlesztették ki. 3.1 Adattábla, adatmező, adatrekord Adattábla Az adattáblákban összetartozó információcsoportok adatait tároljuk, pl. raktári készletek, szállítók és vevők adatai, stb. Ezt egy táblázatként képzelhetjük el, és a valóságban is, mint egy táblázatot jeleníti meg az Access. Egyedtípus 2. Ábra: Egy tábla adatlap nézetben 6 mezővel és 5 rekorddal A szakirodalomban gyakran lehet találkozni az egyedtípus kifejezéssel, ami a relációs modellben az egy táblába kerülő információcsoportoknak felel meg. Rekord Az adattáblák az adatokat úgynevezett rekordokban tárolják. A rekord az adattábla egy-egy sorának felel meg, és az információcsoport egy elemének összes adatát tartalmazza, például egy alkalmazott összes paraméterét (Kovács Péter, Elnök, 125, (96) , ). Mező Az azonos jellegű, tehát az egy oszlopba kerülő adatok gyűjtőneve a mező, mint például az összes különféle beosztás neve (elnök, pénztáros, alelnök, ). Az adattábla azonban a tényleges adatokon kívül még sok fontos további olyan információt is tartalmaz, mely az egész adatbázis viselkedését, megjelenését döntően befolyásolja. Ilyenek például az adatok különféle szempontok szerinti sorrendjét tároló úgynevezett indexek ( ), vagy az elfogadható adatokat megadó érvényességi szabály ( ), illetve maguknak az egyes adatoknak az adattáblában való megjelenési képét befolyásoló formátum ( ), és beviteli maszk ( ). 3.2 Lekérdezés Az adattáblákban tárolt adatok megjelenítésére többnyire nem közvetlenül adattáblákat fogunk majd alkalmazni, hanem lekérdezéseket. Ennek az oka az, hogy gyakran nem minden adatra vagyunk kíváncsiak, hanem csak bizonyos feltételnek megfelelő rekordokra, sőt, azoknak is csak adott mezőire. Ezt a legegyszerűbben lekérdezésekkel valósíthatjuk majd meg. Sajnos azonban a lekérdezés is táblázatos formában jeleníti meg az adatokat, ami nem minden esetben megfelelő. Ilyenkor, illetve egészen profi megoldásoknál, nem közvetlenül alkalmazzuk adatmegjelenítésre a lekérdezést. Űrlapokat, illetve jelentéseket hívunk majd segítségül, de általában ezek mögött is ott van egy-egy jól összeállított lekérdezés. A lekérdezések tehát annyiban jelentenek többet egy adattáblánál, hogy: ha szükséges, nem mutatnak meg minden adatmezőt, de ennek az ellenkezője is megoldható, azaz olyan adatot is kijelezhetnek a lekérdezések, melyek több adatmező tartalmából kerülnek kiszámolásra; az egyes rekordokhoz tartozó, és a lekérdezésben megjelenített adatokból igényünknek megfelelő statisztikai számításokat is végeztethetünk, mint például összegzés, átlag számítása, stb.; és végül akár külön adattáblában tárolt mezők is megjeleníthetőek egyszerre (ez ugyan űrlapokkal és jelentésekkel közvetlenül is megoldható, de egyszerűbb lesz a dolgunk, ha előbb készítünk egy több táblán alapuló lekérdezést); 6

7 Access XP alapokon A lekérdezések azonban az adatok leválogatott megjelenítésén kívül alkalmazhatók bizonyos feltételeknek megfelelő rekordok törlésére, módosítására is. Bár még ezzel sincs vége a lehetőségeknek, a továbbiakat már csak a lekérdezések részletes ismertetésekor tárgyaljuk, mert azokat nehéz lenne ilyen röviden bemutatni. 3.3 Jelentés Mivel a jelentések végcélja az adatok papír adathordozón történő bemutatása, ennek érdekében az információk nyomtatásra szánt formában kerülnek elrendezésre rajta. Ugyanakkor, mivel a jelentések kifejezetten csak kimeneti eszköznek tekinthetőek, az adatok módosítására nem alkalmazhatóak. A jelentések segítségével is készíthetünk olyan összesítéseket, mint a lekérdezésekkel, azoknál azonban sok szempontból mégis jelentősen többet nyújtanak. Segítségükkel többek között lehetőség nyílik: az adatok tételes és göngyölített értékeinek egy időben történő listázására (lekérdezéseknél vagy csak az egyik, vagy csak a másik értékek szerepelhetnek); az adatok grafikus megjelenítésére. 3.4 Űrlap Az űrlapok az adatokat látványos, jól áttekinthető grafikus formában jelenítik meg, s egyúttal biztosítják azok módosítását is. Űrlapokat az Access programban általában két okból hozhatunk létre: leggyakrabban adatfelviteli szándékkal; illetve ritkábban az elsősorban képernyőre szánt összetett lekérdezések megjelenítése céljából. Ennek megfelelően az űrlapokat elsősorban képernyő orientált bemeneti eszköznek kell tekinteni, bár kinyomtatásuk is lehetséges. Igazság szerint nekem az jelentette eleinte a legnagyobb problémát, hogy ugyanarra a célra több Access eszköz is szolgál. Például: adatbevitel lehetséges közvetlenül az adattáblába; egy lekérdezésen keresztül; illetve egy űrlappal. információ kigyűjtés megoldható lekérdezéssel; jelentéssel; illetve űrlappal is. Sokáig nem értettem mi a különbség a jelentés, a lekérdezés és az űrlap között. Pontosan ezért a későbbiekben egy-egy táblázatban is összehasonlítom a jelentést és a lekérdezést egymással (7.), illetve az űrlapot az összes többi elemmel (8.). 3.5 Makró Ha valamely feladat megoldását nem találjuk meg a menükben, vagy az egyéb lehetőségek között, bátran fordulhatunk a makrókhoz. A makrókat az Access programban majd nem rögzítjük mint az Excelben, hanem előre megírt makrókat alkalmazunk úgy, hogy a megfelelő paramétereiket megadjuk. Amennyiben az Access programban egy komolyabb alkalmazást kívánunk készíteni, ne is reménykedjünk abban, hogy elkerülhetjük őket, mert szinte biztosan szükségünk lesz néhány makró alkalmazására is. Terjedelmi okokból a könyvben nem tárgyaljuk a makrókat, de a címen részletes dokumentáció található róla. 4. Új adatbázis létrehozása Új adatbázis létrehozására két lehetőségünk van: 1. Az alapoktól kezdve, a saját elképzeléseinknek megfelelően mi magunk alakíthatunk ki mindent. Ehhez a Munkaablak Üres adatbázis elemét kell választanunk. A kapott Új adatbázis ablak valójában nem más, mint egy mentő párbeszédablak, melyben meg kell adnunk, hogy hová és milyen néven kerüljön elmentésre az adatbázis, vagyis az az állomány, mely tartalmazza majd a korábban már röviden megbeszélt táblákat, lekérdezéseket, űrlapokat, jelentéseket és makrókat. 7

8 ECDL Adatbázis-kezelés modul Érdemes az adatbázisokat az Adatforrások mappába menteni, mert ez a tervezett helyük, és sok program később majd itt is keresi az őket. Az adatbázisok alapértelmezett neve dbn, ahol N egy futó sorszám. Természetesen helyette célszerűbb most is a beszélő nevek alkalmazása. Az adatbázisok az Accessnél MDB típusúak, ikonjuk alakja pedig. Ezzel azonban még csak egy olyan fájlt hoztunk létre, mely tökéletesen üres, nincs benne semmilyen információ. Az egészet úgy kell elképzelni, mintha az Excelben történő munkát úgy kellene kezdeni, hogy elmentünk egy olyan munkafüzetet, melyben egyetlen munkalap sincs. Amikor azután adatokat akarunk bevinni, hozzáadunk egy üres munkalapot, ha diagramot akarunk rajzolni, akkor pedig egy diagram lapot, stb. Mindez elsőre eléggé furcsa, de majd megszokjuk. 2. Egy varázsló segítségével sablonok alapján dolgozunk. Ezt úgy tehetjük meg, hogy a Munkaablak Általános sablonok pontjára kattintunk. Ekkor az Adatbázis varázsló segítségével egy, a Microsoft által tervezett minta alapján fogunk majd egy új adatbázist létrehozni. Miután kiválasztottuk a sablont, ez esetben is el kell menteni az adatbázist. A varázsló a továbbiakban segít összeválogatni az adott feladathoz egyáltalán szóba 3. Ábra: Üres adatbázis elmentése 4. Ábra: Sablon választása kerülhető adatok közül a nekünk szükségeseket. Így az adatbázisba belekerülnek az általunk megadott adatokon alapuló üres adattáblák, illetve az előre elkészített lekérdezések, űrlapok és jelentések. 1. Feladat: Hozzunk létre egy új adatbázist Raktári rendszer néven! A feladat megoldásához most nem fogunk varázslót alkalmazni, mivel így nehezebb a feladat. Ez első hallásra eléggé ésszerűtlennek tűnik, de nem véletlen. Ha ugyanis varázsló nélkül is el tudunk készíteni egy teljes adatbázist (több adattáblával, kapcsolatokkal, lekérdezésekkel, stb.), akkor mindez varázslóval, ahol csak kérdésekre kell majd választ adni, már könnyen fog menni. Igazság szerint a varázsló mellőzésének más oka is van, amiről a kiegészítő információkban lehet többet olvasni. Megoldás: Indítsuk el az Access programot a Start menü Minden program eleméből az Office programok, majd a Microsoft Access pontokat választva. A Munkaablakban kattintsunk az Üres adatbázis elemre. Ha valamilyen okból nem lenne munkaablakunk, kattintsunk a ikonra. A megjelenő Új adatbázis ablakban lépjünk be az Adatforrások mappába, azután pedig a Fájlnév mezőbe gépeljük be a Raktári rendszer nevet, végül kattintsunk a Létrehozás gombra. 8

9 Ahol lehet, használjunk varázslót (?) Access XP alapokon Az Access használatának egy fontos alapelve, hogy sok helyen varázslók segítik a munkánkat, amelyekkel a legtöbb probléma automatizáltan oldható meg. Ezért ha nem vagyunk tisztában azzal, hogy miként kezdjünk neki egy feladatnak, az a legjobb stratégia, hogy a varázslók segítségével egy, az elvárásokhoz leginkább közelítő megoldást készítünk el. A későbbiek során azután az így létrehozott elemeket folyamatosan finomítva azokat saját célunkhoz igazítjuk. Konkrét esetünkben tehát, amikor is egy raktári rendszert akarunk elkészíteni, célszerű lenne a Leltár nevű sablont használva az Adatbázis varázslóval dolgoznunk. Az így elkészített adatbázis a következő adattáblákat tartalmazná: Az adattábla neve a táblában lévő mezők (a felsorolás nem mindig teljes körű) Információk a cégemről TelepítésKód, Cég neve, Postacím, Város, Állam, Irányítószám, Ország/terület, Telefonszám, Faxszám; Termékek Termékkód, Terméknév, Termékleírás, Kategóriakód, Sorozatszám, Egységár, Minimumkészlet, Tartalék; Vétel és eladási információk Tranzakciókód, Tranzakció dátum, Termékkód, Beszerzés megbízás kód, Tranzakció leírás, Egységár, ; Beszerzési megbízás információk Beszerzési megbízás kód, Megbízás száma, Beszerzési megbízás leírása, Szállító kód, Alkalmazottkód, ; Kategóriák Kategóriakód, Kategórianév; Információ alkalmazottakról Alkalmazottkód, Vezetéknév, Keresztnév, Beosztás, Mellék, Mhelyi telefon; Szállítási módok Szállításmód-kód, Szállítás módja; Szállítók Szállítókód, Szállítónév, Ügyintéző, Kapcsolat címe, Postacím, Város, Irányítószám, Állam, ; A sablonokkal való munkával csak az a baj, korántsem biztos, hogy azok az adatok kerülnek letárolásra, melyekre szükségünk van. Ez a példa szerinti Leltár sablonnál sincs másként. A felesleggel nem lesz gond, mert ami nem kell, az a varázsló egyik lépésében törölhető, de ami nincs a listában, azt az adatot nem is tudjuk majd letárolni, csak ha módosítjuk az adattábla szerkezetét. A varázsló egyúttal elkészíti az adatbevitelhez és módosításhoz szükséges összes űrlapot, valamint az esetleg igényelt listák készítéséhez szükséges jelentéseket. Ezeken kívül egy menürendszerhez hasonló funkciójú, úgynevezett kapcsolótábla is kialakításra kerül. A varázsló futása közben lehetőség van az egyes táblák mezői közül a nem szükségesek elhagyására, valamint minták választásával a beviteli képernyők és a kimeneti listák megjelenésének befolyásolására is. Igazság szerint azonban egy ilyen automatikusan generált komplett adatbázis valószínűleg elég messze fog esni az általunk kívánt eredménytől. Nekem az a véleményem, hogy leginkább csak a program egyes elemeinek megismerésére, a trükkök ellesésére használható. Ezzel szemben az egyes részfeladatoknál, űrlapok, jelentések készítésénél bátran alkalmazzunk varázslókat. Nyomtatással kapcsolatos problémák megelőzése Felhívom a figyelmet arra, hogy ha a Windowsban nincs beállítva alapértelmezett nyomtató, akkor az XP-nél régebbi Access esetében adatbázis létrehozás közben hibaüzenetet kaphatunk, az automatikus létrehozás pedig megszakad. Ezt egy nyomtató telepítésével kerülhetjük el, amit akkor is megtehetünk, ha nem is rendelkezünk vele. 5. Adattáblák tervezése, létrehozása Mint azt éppen az imént leszögeztük, adattáblák alatt azokat a táblázatokat értjük, amelyek az adatbázisban a tulajdonképpeni adatokat tárolják. De még mielőtt az adattáblák létrehozásáról részletesebben szót ejtenénk, az adatbázisok és az adattáblák tervezéséről is kell beszélnünk. Miért? Mert mind az Accessben, mind bármelyik más adatbázis-kezelő programban csak gondos tervező-előkészítő munka után lehet elkezdeni dolgozni. 5.1 Adattáblák tervezése A most következő, a tervezéshez kapcsolódó ismeretek fontosságát sejtésem szerint az olvasók közül sokan csak akkor fogják felismerni, miután már beletörött a bicskájuk egy feladat megoldásába. Ezt megelőzendő ne lapozzuk át, hanem inkább próbáljuk megérteni Egyetlen tábla problémai: redundancia, anomália Nyilvántartások készítésekor elsőként azt kell gondosan áttanulmányozni, hogy az adott feladattal kapcsolatban milyen adatokra lehet egyáltalán szükségünk. 9

10 ECDL Adatbázis-kezelés modul Ha például egy fuvarozó vállalat járműveinek nyilvántartása a feladat, akkor egy olyan adatbázist kell létrehozni, melyben a gépkocsik összes alapadata megtalálható. A táblázatot megvizsgálva azonban azt látjuk, hogy nagyon sok adat többször is ismétlődik benne. Redundancia A többszörös letárolást redundanciának nevezik, amit mindenképpen el kell kerülni. Miért? Azért, mert a redundáns adatok azon kívül, hogy felesleges helyet foglalnak el, egy további problémát, úgynevezett módosítási anomáliát is okoznak. Anomáliák A redundancia tehát módosítási anomáliát okoz, de még két további anomáliáról is szokás beszélni. Lássuk tehát az anomáliákat: módosítási anomália A redundancia miatt az adatok módosítása nehézkes. Példánknál maradva tegyük fel, az APEH úgy dönt, hogy az Opel Corsa típusra előírt fogyasztási norma túlságosan magas. Kevesebből, mondjuk 6,8 literből is ki kell, hogy jöjjön az autót üzemeltető. Ekkor azonban minden rekordban módosítani kellene ezt az adatot. törlési anomália Ha egyetlen táblában tárolunk minden adatot változatlanul eredeti példánknál maradva amennyiben mindkét Peugeot Partnert törölnénk, a típusra vonatkozó adatok is törlésre kerülnének. beszúrási anomális Amíg valamely járműtípusból egyetlen darab sincs, addig nem tudjuk a típus adatait sem felvenni Több tábla és azok kapcsolata elsődleges és idegen kulccsal Mi a megoldás? Pontosan az, mint amit a lusta gépjármű előadók már 50 éve kitaláltak erre a célra. A járművek nyilvántartására szánt füzet egyik Egyedi adatok oldalára csak a rendszámot és típust, egy másik lapra pedig az egyes típusok paramétereit (lökettérfogat, fogyasztási norma, üzemanyag, terhelhetőség, stb.) kell írni. Így nem kell újra és újra leírni ugyanazokat a típusadatokat, illetve az esetleges változtatás is könnyebb. A két tábla közötti kapcsolatban a mindkét táblában szereplő Típus mező különleges szerepet tölt be. Elsődleges kulcs és idegen kulcs elsődleges kulcs Azt az adatát nevezzük a tábla elsődleges kulcsnak, melynek segítségével minden sora azonosítható. Ilyen szerepe van például a Típus mezőnek a Típus adatok táblában. Az elsődleges kulcs egy-egy értéke a táblákban mindig egyedi. Tervezéskor aláhúzás szolgál a jelölésére. idegen kulcs A kapcsolat érdekében az elsődleges kulcs értékét a másik táblában is tárolni kell. Ez az adat ott csak az azonosítás miatt, mint egy idegen adat szerepel, ezért idegen kulcsnak is nevezik. Az idegen kulcs adott értéke egy-egy táblában többször is elő- Gépkocsik egyedi és típus adatai Norma Rendszám Típus Lökettérfogat szerinti Terhelhetőség (kg) Üzemanyag fogyasztás (liter) GKB-121 Opel Corsa ,2 Benzin 450 KHJ-253 Peugeot Partner ,6 Gázolaj 600 HHB-257 Opel Corsa ,2 Benzin 450 HHB-251 Opel Corsa ,2 Benzin 450 IGH-754 Opel Astra ,9 Benzin 300 PSK-125 Peugeot Partner ,6 Gázolaj Táblázat: Egy táblázat esetén elkerülhetetlen a redundancia Rendszám Típus Típus Lökettérfogat Típus adatok Norma szerinti fogyasztás Üzemanyag Terhelhetőség (kg) GKB-121 Opel Corsa Opel Corsa ,2 Benzin 450 KHJ-253 Peugeot Partner Opel Astra ,9 Benzin 300 HHB-257 Opel Corsa Peugeot Partner ,6 Gázolaj 600 HHB-251 Opel Corsa IGH-754 Opel Astra PSK-125 Peugeot Partner 2. Táblázat: Ha két táblázatra bontjuk az adatokat, a problémák egy része megoldódik 10

11 Egyedi adatok Rendszám Típus Lökettérfogat Típus adatok Norma szerinti fogyasztás (liter) Access XP alapokon fordulhat. Példánkban a Típus mező tölt be ilyen funkciót az Egyedi adatok táblában. A tervezéskor szaggatott aláhúzással szokták jelölni. Egy-egy táblában természetesen egyszerre fordulhat elő elsődleges és idegen kulcs is. Az egyedi adatok táblában például elsődleges kulcs szerepe lesz majd a Rendszám mezőnek, míg a Típus idegen kulcsként funkcionál. Összetett és mesterséges elsődleges kulcs Példánkban a két táblázat összekapcsolására a típusok tényleges megnevezése szolgált. Ezzel nem is lenne gond, ha még mindig ZISZ, Pobjeda, Moszkvics, Volga, stb. (made in CCCP) típusú gépkocsikból állna egy-egy cég gépkocsiparkja. A típusfejlesztés e márkáknál felesleges volt, hiszen mindegyik típus olyan remekül sikerült, hogy évtizedekig változatlan kivitelben lehetett velük építeni a szocializmust. Az állandó harckészültség érdekében az alkatrészellátást is egy agyafúrt módszerrel egyszerűsítették: minden márka csak egyetlen Egyedi adatok Rendszám Típus Típus Lökettérfogat Típus adatok Norma szerinti fogyasztás (liter) Üzemanyag Típuskód Típuskód Üzemanyag Terhelhetőség (kg) GKB-121 Opel Corsa Opel Corsa ,2 Benzin 450 KHJ-253 Peugeot Partner Opel Astra ,9 Benzin 300 HHB-257 Opel Corsa Peugeot Partner ,6 Gázolaj 600 HHB-251 Opel Corsa Peugeot Partner ,6 Benzin 600 IGH-754 Opel Astra PSK-125 Peugeot Partner PXK-235 Peugeot Partner 3. Táblázat: Egyetlen mező sokszor nem használható egyértelmű azonosítóként Terhelhetőség (kg) változatban volt forgalomban. Némi mozgalmasságot csak a gazdag HHB Peugeot Partner ,6 Gázolaj 600 GKB Opel Corsa ,2 Benzin 450 KHJ Opel Astra ,9 Benzin 300 színválaszték jelentett: fekete az IGH HHB Peugeot Partner ,6 Benzin 600 PSK ÁVH és a Temetkezési Vállalat, PXK fehér a Mentők, 4. Táblázat: Ha nevek helyett kódokat alkalmazunk, tovább javul a helyzet és szürke a Főtaxi számára. Ma már azonban számtalan konstrukcióban készül minden típus, mint például különféle lökettérfogatú, illetőleg üzemanyagú motorvariációk, stb. (pl. benzines és diesel, 1,4-es és 1,6-os, stb.). A típus így már nem felel meg elsődleges kulcsnak. Tegyük fel, hogy képzeletbeli cégünk vesz egy új Peugeot Partnert, de nem diesel, hanem benzin üzeműt. Ha beviszi a táblázatba, rögtön fellép ez a probléma: nem lehet a típus alapján beazonosítani a műszaki adatokat, hiszen több különböző paraméterekkel rendelkező járművet ugyanúgy hívnak. Erre két megoldás lehetséges: vagy összetett elsődleges kulcsot alkalmazunk, vagy egy külön mezőt veszünk fel elsődleges kulcsnak. A konkrét esetben ez annyit jelent, hogy vagy felveszünk egy külön mezőt elsődleges kulcsnak; vagy a Típus, és az Üzemanyag mezőket együtt alkalmazzuk kulcsként. Bár a két megoldásból általában az összetett kulcs választása a célszerűbb, most mint azt az előző ábrán is láthatjuk nem ezt alkalmaztuk. Ha azonban figyelmesen átnézzük eddigi munkánkat, most is láthatunk ismétlődő adatokat, mégpedig az üzemanyag mezőben. Ezt egy újabb táblázattal megszüntethetjük, melyben a különféle üzemanyagok kerülnek megnevezésre. Persze aki a kákán is csomót keres, most is felfedezhet némi redundanciát, hiszen mind a Típuskód mind az Üzemanyag kód ismétlődik. 11

12 ECDL Adatbázis-kezelés modul 12 Egyedi adatok Rendszám Típus Típus adatok Lökettérfogat Norma szerinti fogyasztás Üzemanyag kód Típuskód Típuskód Terhelhetőség (kg) GKB Opel Corsa , KHJ Opel Astra , HHB Peugeot Partner , HHB Peugeot Partner , IGH PSK Üzemanyagok PXK Üzemanyag kód Üzemanyag 1 Benzin 2 Gázolaj Ez azonban már nem jelent gondot, mert a duplikált tárolás szempontjából az egyedi azonosítóként használt kódok nem zavarnak. Ennek ellenére azért jó, ha megjegyezzük azt, hogy minden kulcs csak a szükséges minimális hosszúságú legyen, hiszen ellenkező esetben felesleges helyet foglal el. Befejezésül lássuk az elsődleges és az idegen kulcsokat: elsődleges kulcs Üzemanyagok táblából Üzemanyag kód ; Típus adatok táblából Típuskód ; Egyedi adatok táblából Rendszám ; idegen kulcs Típus adatok táblából Üzemanyag kód ; Egyedi adatok táblából Típuskód. 5. Táblázat: Egy további táblázattal már minden redundancia és anomália megszüntethető Időben állandó és változó adatok tárolása (törzs és mozgás adatok) A példának választott fuvarozó vállalatnál csak olyan adatokat tárgyaltunk eddig, melyek egy viszonylag bővebb időintervallumon belül is állandónak tekinthetőek. Ha valamelyik adat meg- Gépkocsik Típusok változik, egyszerűen kikeressük a megfelelő táblázatban, és értékét átírjuk az újra. Létezhetnek azonban olyan adatok (a jelenlegi példa esetében is), amelyek eseményeket írnak le. Olyan eseményeket, amelyek paramétereit a későbbiekben tanulmányozva döntéseket hozhatunk, illetve mely események adataiból később (hónap, negyedév, év végén) számításokat, jelentéseket kell készíteni. Ehhez azonban minden korábbi értéknek is meg kell lennie, tehát az adatokat is másként kell kezelni. A probléma úgy oldható meg, hogy az eseményeket leíró adatok külön táblákba kerülnek, melyeket majd folyamatosan bővítünk: minden esemény egy-egy újabb sor, azaz egy-egy rekord hozzáadását fogja eredményezni. Ha például a gépkocsik tankolási adatait is meg kívánjuk őrizni amire a költségelszámolás miatt szükség is lesz akkor ezt egy újabb táblázatban kell megtennünk. Természetesen majd ez a táblázat is tartalmaz a tankolás adatain kívül egy egyedi azonosító adatot, célszerűen a rendszámot. Amikor egy-egy autót feltöltenek üzemanyaggal, akkor a táblázat egy-egy újabb sorral, azaz rekorddal fog bővülni. Törzsek A törzs adattáblákban tárolt rekordok általában egy személy, tárgy alapadatait tartalmazzák, és csak nagyon ritkán változnak. Ebbe a kategóriába tartozhatnak például a következők: Típus Lökettérfogat Norma szerinti fogyasztás Üz. ag. kód Rendszám Típuskód Típuskód Terhelhetőség (kg) GKB Opel Corsa , KHJ Opel Astra , HHB Peugeot Partner , HHB Peugeot Partner , IGH PSK Üzemanyagok Tankolási adatok PXK Üz. ag. kód Üzemanyag Rendszám Dátum Km óra állás Mennyiség (l) 1 Benzin GKB Gázolaj KHJ GKB Táblázat: Egy újabb táblázattal az események adatai is megőrizhetőek (a arra utal, hogy az adott táblázat nagyobb, de csak egy része került ábrázolásra)

13 Access XP alapokon termékek; mértékegységek; szállítók; vevők; gépkocsitípusok. Mozgás, vagy változó adatok A mozgás állományokban a tevékenységhez kapcsolódó, változást okozó folyamatok adatai kerülnek letárolásra. Ilyenek például: be- és kivételezés adatai; tankolási adatok Táblákra bontás eljárásai: a normalizálás, az ER modell és a józan ész módszer Amennyiben egy nagyobb feladathoz a józan észen alapuló módszerrel akarnánk a kritériumoknak minden szempontból megfelelő adattáblákat megtervezni, ahhoz nagyon nagy gyakorlatra lenne szükség, és még akkor is komoly nehézségekbe ütköznénk. Szerencsére erre a feladatra két, a munkánkat jelentősen megkönnyítő módszert is lehet alkalmazni. Normalizálás Alkalmazásával egyetlen nagy adattáblát több kisebb, egymáshoz kapcsolódó adattáblára lehet bontani. A normalizálás tudományosan megalapozott matematikai módszeren alapul. ER modell Ez egy könnyebben megtanulható, rendkívül szemléletes grafikai módszer Normalizálás A normalizálás lényege a következő: 1. Létrehozunk egy olyan táblázatot, melyre igazak a következők: az oszlopok száma és sorrendje rögzített; minden oszlop tartalma meghatározott, és nincs köztük két egyforma; minden sora azonosítható, és nincs közöttük két azonos; nincs benne többértékű mező (minden mezőben csak egy-egy érték található); 2. Amennyiben összetett elsődleges kulcsú a tábla, az olyan mezőt, mely az összetett elsődleges kulcsnak csak egy összetevőjétől függ, külön táblába kell rakni. Az új táblába a kérdéses mezőn kívül fel kell venni az összetett kulcs adott komponensét is, mely ott önmagában lesz az elsődleges kulcs. Az összetett kulcs adott eleme természetesen megmarad az eredeti táblában is, ahol egyben idegen kulcs is lesz. Erre azért van szükség, mert két tábla közötti kapcsolathoz mindig mindkét táblában kell szerepelnie ugyanannak az adatnak, az egyikben elsődleges, a másikban idegen kulcs funkcióval (de ezt már tanultuk). 3. Nincs olyan mező, mely nem az elsődleges kulcstól függ. Amennyiben van, annak külön táblát hozunk létre Ha egy tábla megfelel mindhárom feltételnek, akkor normál állapotban, vagy harmadik normál formában (3NF) van. E munkánk során nem szükséges a teljes táblákat lerajzolni. Elegendő a táblák neve után zárójelben a mezőneveket felsorolni. Az elsődleges és idegen kulcsokat a már megbeszélt aláhúzásos módszerrel, a kapcsolatokat pedig egy-egy vonallal szokás jelölni. Sajnos a három szabályból a 2. és a 3. még sokszori olvasásra is nehezen értelmezhető. Megértésükhöz sok-sok példára lenne szükség, de terjedelmi okokból erre nincs lehetőség. Akit a témakör részletesebben is érdekel, a címen talál hozzá anyagot. Mit jelent a többértékű mező? Tegyük fel, hogy le szeretnénk tárolni egy osztály tanulóinak adatait, beleértve mindenkinek az általa felsorolt, tetszőleges számú kedvenc együttesét is. Az együttesek neveit külön-külön mezőkben tárolva a feladatot nem oldhatjuk meg, mert azt sem tudjuk megmondani, hogy hány ilyen mezőt kellene felvenni. A problémát azonban úgy sem oldhatjuk meg, hogy egy mezőben tároljuk az összes együttes nevét (ez utóbbi eset lenne a többértékű mező). 13

14 ECDL Adatbázis-kezelés modul Azért nem szabad többértékű mezőt használni, mert a tartalmára történő keresés minden szituációban más és más technikát kívánna. Helyette azt a megoldást kell alkalmazni, hogy a többértékű mezőt egy külön táblába visszük, és a táblát kiegészítjük az eredeti tábla elsődleges kulcsot betöltő mezőjével, mint idegen kulccsal. Esetünkben konkréten: eredeti tábla mezői Tanuló(tanulókód, név, címe, osztály, stb., együttes); új táblák mezői Tanuló(tanulókód, név, címe, osztály, stb.) és Kedvenc(együtteskód, tanulókód, együttes) ER modell Az ER modell egy alapvetően grafikus tervezési módszer, melynek főbb lépései az alábbiak: meghatározzuk az úgynevezett egyedtípusokat és felsoroljuk azok mezőit; szintén meghatározzuk az egyedtípusok közötti kapcsolatokat; megrajzoljuk a nyers, úgynevezett csontvázmodellt, amit fokozatosan finomítunk (az egyedtípusok szimbóluma téglalap, a kapcsolatoké rombusz); az egyedtípusokra felrajzoljuk a mezőket, kijelöljük az elsődleges és idegen kulcsokat (a mezők jele pálcika; a kulcsok jelzése a korábban már megbeszélt aláhúzás, illetve szaggatott aláhúzás); ha van olyan adat, mely a kapcsolathoz kötődik, ezeket is felrajzolunk a kapcsolatokra, mint mezőket (ezek gyakorlatilag megfelelnek a korábban már más vonatkozásban tárgyalt mozgás adatoknak); meghatározzuk, hogy az egyes kapcsolatokban a táblák hány egyede vesz részt (1 : 1, 1 : N, M : N, amit a kapcsolat vonalához írunk); amennyiben egy-egy kapcsolatban nem minden egyed diák szereti vesz részt, azt szaggatott vonallal jelöljük (ezt a szakzsargonban parciális kapcsolatnak hívják); 1 N tkód az úgynevezett leképezési szabályokkal az ER modellt átalakítjuk relációs modellé, azaz táblákká. cím név A lépéseknél megadott jelölési rendszer nincs szabványosítva, ezért más szakirodalmakban ettől eltérő szimbólumok osztály is előfordulhatnak. A témával kapcsolatos információk, mint például a leképezési szabályok, illetve a megértést segítő példák szintén a címen találhatók Józan ész módszer Mint látjuk, a tudományosan megalapozott módszerek sem egyszerűnek, így sokszor mégis marad a józan ész módszere. Ennek során a következőket tegyük: Gondoljuk át, hogy egy feladathoz kapcsolódóan milyen adatokat szeretnénk letárolni, és milyen információkat szeretnénk nyerni. Ezek lesznek a majdani adatbázisunkat alkotó adattáblák mezői. Az egy tárgyhoz, személyhez, folyamathoz kapcsolódó adatmezőket csoportosítva alkossuk meg a táblákat. Az időben nagyjából állandó törzs, és a folyamatosan gyarapodó mozgás adatokat külön táblákba rakjuk. A következő lépésben keressük ki azokat a mezőket, melyek csak bizonyos értékeket vehetnek fel. Ezeket az adatokat külön táblázatban, szükség esetén táblázatokban tároljuk le. Az így kapott második, harmadik, stb. táblázatokat is meg kell vizsgálni, és ha szükséges, azokat is további táblázatokra kell bontani Indexek Ha lesznek olyan adataink, melyek szerint gyakran kell információt kikeresni, illetve az adott adat szerint sorba rendezve kell listákat készítenünk, akkor a kérdéses mezőt index mezőnek kell majd definiálnunk. Természetesen indexek nélkül is bármikor sorba rendezhetjük adatainkat, de az indexek előre történő meghatározása meggyorsítja a rendezést. Hatására ugyanis az adott index (indexek) szerinti sorrendet folyamatosan karbantartja a program, és amikor bármely előre meghatározott index szerinti sorrendben vagyunk kíváncsiak az adatokra, azok időveszteség nélkül máris rendelkezésünkre állnak. Ez nagy előny lehet egy több ezer, esetleg több tízezer rekordot tartalmazó adattábla esetén. Arról, hogy miként adhatjuk meg az index mezőket, a későbbiekben esik szó ( ). 14 együttes ekód tkód együttes 5. Ábra: A kiegészítő információban lévő feladat ER modellje

15 5.1.6 Adattáblákkal kapcsolatos további tervezési feladatok Access XP alapokon Miután elvégeztük a feladathoz kapcsolódó adatok adattáblákra bontását, az elsődleges, és az idegen kulcsok, valamint az indexek meghatározását, még néhány további feladatot is el kell végezni: meg kell határozni a tábla és mezőneveket; meg kell adni a mezők hosszát; valamint el kell dönteni, hogy az egyes mezők milyen típusúak legyenek Tábla és mezőnév Tábla- és mezőnévként lehetőség szerint egyes számú főneveket alkalmazzunk, mint például tanuló, gépkocsi, dolgozó, stb. A név természetesen utaljon a tábla tartalmára. Mindkettő hossza maximum 64 karakter lehet. Használhatóak bennük az ékezetes karakterek és a szóköz is, de nem lehet benne idézőjel, pont, szögletes zárójel, és felkiáltójel. [ ]! (ezeknek a karaktereknek ugyanis más szerepük lesz). Célszerű rövid, de pontos meghatározásokat alkalmazni. Például egy raktári rendszert tartalmazó adatbázisban a termékeket tároló adattábla esetében az árucikk nevét egy Termék név, az árucikk árát pedig egy Nettó egységár mezőben célszerű tárolni. Bizonyos esetekben bár sok mindent megenged az Access mégis célszerűbb a régebbi adatbázis-kezelők névadási szabályait betartani, ezért alkalmazzuk inkább a következő mezőneveket: Régi név helyettesítő név Termék név Term_nev Nettó egységár N_egysar Miért legyen rövid a mezőnév? Azért, mert ha a mezőkben lévő adatokkal majd számolnunk kell, akkor a kifejezésekben a mezők nevével kell majd az adott adatra hivatkozni (pontosan ugyanúgy, mint az Excelben). Mivel a hosszú mezőnevekkel csak értelmezhetetlenül terjedelmes kifejezéseket tudunk létrehozni, marad a rövidítés. Vigyázat! Még ha rövidítünk, akkor sem rakhatunk pontot a mezőnévbe! Nem jelent majd gondot, ha nem elég szabatos a mezőnév? Nem, mivel megadhatunk majd egy olyan másik nevet is, amely a párbeszédablakokban, listákban, stb. fog szerepelni a mezőnevek helyett. Ennek az adatnak majd Cím lesz a neve, és a későbbiekben részletesen fogjuk tárgyalni Mezők típusa és mérete (hossza) Azt, hogy mit jelent a mezők típusa, az Excel ismeretében után már nem kell Ádámtól és Évától kezdve magyarázni. Az azonban jelentősen bonyolítja a dolgot, hogy itt sokkal több adattípus létezik: Típus az adott típus leírása tárolási hossza Szöveg Maximum 255 karakteres alfanumerikus szöveg. max. 255 bájt 1 Feljegyzés Maximum karakteres alfanumerikus adat. max bájt Pénznem Számításokhoz is használható, 4 tizedes pontosságú szám 2. 8 bájt Dátum/idő Időpontokat és 100 és 9999 közötti dátumokat tárol. 8 bájt Számláló 3 Rekordonként automatikusan egyesével növekvő szám. 4 bájt Igen/Nem Csak Igen/Nem értéket vehet fel. 1 bit OLE objektum Egy objektum, mely lehet kép, hang, film. max. 1 GB Hiperhivatkozás www, vagy cím letárolására alkalmas. 3 * bájt Keresés varázsló Kapcsolat alapján egy másik táblából, vagy általunk megadott paraméterekből ad vissza értéket. A feljegyzés típus Egy feljegyzés típusú mezőben szinte korlátlan mennyiségű karakteres adatot tárolhatunk. Mivel azonban a benne tárolt adatok feldolgozása nehézkesebb, mégis csak ritkán alkalmazzuk. A régebbi programokban e típus neve memo volt. A Szám típust a végére hagyva külön táblázatban szerepeltetem, mert több altípusa is létezik. Közülük választani majd a mezőhossznál lehet. A legfontosabb szabály az, hogy amennyiben a letárolandó szám tizedes értéket is tartalmaz, akkor a táblázat jobb oldali oszlopából válasszunk! 1 Az MS Access nem foglal helyet szövegmezők üres részeinél. 2 Az adat végére automatikusan kiírásra kerül a Területi beállításoknál megadott nemzeti valuta. 3 Külön kérésre értéke véletlenszerű, illetve 16 bájtos is lehet. 15

16 ECDL Adatbázis-kezelés modul Csak egész szám tárolására Tizedest is tartalmazó szám tárolására alkalmas altípusok alkalmas altípusok Bájt bájt Egyszeres -3,4*1038 és 3,4* közötti szám 7 tizedessel Egész Hosszú egész Azért, mert: és közötti szám és közötti szám 2 bájt Dupla 4 bájt -1,79*10308 és 1,79*10308 közötti szám 15 tizedessel Miért pont abban az értéktartományban tudnak adatot tárolni az egyes számtípusok? az egész típusok kettes komplemensükkel kerülnek letárolásra; a tizedeseket is tárolni képes szám típusok lebegőpontosak. 8 bájt 16 bájt Mire használjuk az egyes típusokat? Csak azokat az alapvető fontosságú szabályokat szeretném ismertetni, melyeket feltétlenül figyelembe kell vennünk egy-egy adattábla tervezésekor. Arra külön felhívom a figyelmet, hogy bizonyos adattípusok nem adhatóak meg elsődleges kulcsként! Szöveg és feljegyzés Az esetek legnagyobb részében szöveges adatokat tárolunk bennük. Egyetlen korlátunk az, hogy egy szöveg mezőbe maximum 255 karaktert lehet megadni. Amennyiben ez kevés, válasszuk a feljegyzés típust. A feljegyzés típus azonban nem lehet elsődleges kulcs! 16 Egyszerű és összetett mező Gyakran előfordul, hogy egy-egy mező tartalma további komponensekre bontható. Az ilyen mezőt szokás összetett mezőnek nevezni. Két példa összetett mezőkre, illetve komponenseikre: Összetett mező komponensei Lakcím irányítószám, város, utca, házszám; Született születés éve, születés hónapja, születés napja Szám Attól, hogy egy mező nevében szerepel a szám szó, még nem kell feltétlenül szám típusúra állítani (pl. jármű rendszáma, személyi szám, TAJ szám, adószám, stb.). Általánosságban kijelenthető, hogy akkor kell szám típust alkalmazni, ha az adattal számolni is szeretnénk. Miért jobb Szöveg típust rendelni egyes, csak számot tartalmazó mezőkhöz? Lehetőleg csak az olyan mezőket válasszuk tehát szám típusúra, amelynek adataival számolni is akarunk. Sajnos, ha adatlap nézetben hozzuk létre a táblát, az automatikus típus megállapítás minden, csak számot tartalmazó mezőhöz szám típust rendel. De miért jobb Szöveg típust rendelni egy olyan mezőhöz, melyben számot tárolunk ugyan, de nem számolunk vele? Azért, mert tapasztalatok szerint többnyire előbb-utóbb kiderül, hogy karakteres adatokat is meg kell adni az addig csak számokat tartalmazó mezőben. Ha Szöveg típust rendeltünk a mezőhöz, akkor ez nem jelent gondot. Nem így szám típus esetén. Persze a Szöveg típus hozzárendelés hátránnyal is jár: több tároló hely szükséges az adat letárolásához Pénznem Olyan adatok esetében alkalmazandó, mint a szám típus, csak éppen pénzt akarunk tárolni a mezőben. Előnye, hogy a mező formázásával nem kell külön foglalkozni, mivel a mező értéke mögé a nemzeti valuta automatikusan kiírásra kerül. A nemzeti valuta a Windows területi beállítása szerinti valutanem lesz Dátum/idő Akkor alkalmazzuk, ha egy dátumot, egy időpontot, esetleg egyszerre mindkettőt akarunk a mezőben tárolni. Használatakor az adatbevitel során hasonló szabályokra kell ügyelnünk, mint az Excel esetében, de cserébe egy fontos szolgáltatást ebben a programban is kapunk: csak valós dátumot fogad el az Access. Mely évekre adhatunk meg dátum és idő adatokat? Az Access ilyen szempontból is elég bőkezűen bánik velünk: közötti dátumokat alkalmazhatunk.

17 Access XP alapokon Számláló Ezt az adattípust akkor célszerű használnunk, ha mesterséges elsődleges kulcsot kell alkalmaznunk. Erre akkor lesz szükségünk, ha nincs olyan mező a táblában, mely elsődleges kulcsnak önmagában is megfelelne, összetett elsődleges kulcsot pedig nem szerencsés megadni. A számláló típusú mező értékét adatbevitelkor nem lehet megadni, mivel annak tartalma minden rekordban automatikusan kerül generálásra. Két lehetőség közül választhatunk: véletlenszerű szám; vagy egyesével növekedő érték kerüljön a számláló mezőbe. Akármelyik mellett is döntünk, a mező tartalma egyedi lesz, tehát elsődleges kulcsnak tökéletesen megfelel Igen/Nem Akkor alkalmazzuk, ha az adott mező csak két értéket vehet fel (ez nem csak igen/nem, hanem bármilyen két adat lehet). Tapasztalatom szerint egy bizonyos idő eltelte után gyakran rájövünk, hogy harmadik, negyedik, stb. variáció is létezhet, és ilyenkor sajnos utólag kell módosítani az adattábla struktúráját. Mivel ez szinte mindig különféle problémákat okoz, e típust tényleg csak akkor használjuk, ha egészen biztosak vagyunk abban, hogy csupán két lehetőség van. Az, hogy az igen/nem típus nem lehet elsődleges kulcs, logikus, hiszen már három rekord esetén is lesz legalább két egyező érték ebben a mezőben OLE 1 objektum Az OLE egy szabvány, melynek segítségével alkalmazásunkba dokumentumokat, táblázatokat, képeket, hangokat illeszthetünk be. Ha egy OLE objektumot aktivizálunk futás közben, akkor automatikusan betöltődik az azt kezelő program (Word, Excel, Paint, Médialejátszó, stb.), így további lehetőségekkel ruházhatjuk fel alkalmazásunkat. Természetesen az OLE objektum sem lehet elsődleges kulcs! Hiperhivatkozás Szabványos Web, vagy címek tárolását teszi lehetővé. Aktivizáláskor betöltődik a gépen lévő levelező-, vagy böngészőprogram. A hiperhivatkozás sem lehet elsődleges kulcs! Keresés varázsló Akkor kell alkalmaznunk, ha egy táblában egy adott mező tartalma csak bizonyos értékeket vehet fel. A korábbi, 2. táblázat szerinti kiinduló feladatunkban ilyen például a Gépkocsik egyedi és típus adatai tábla Típus mezője, amelybe csak létező márka kerülhet be, vagy az Üzemanyag mező, mely csak Benzin és Gázolaj értéket vehet fel. A két adat között azonban van egy lényeges különbség: Üzemanyag ennél a mezőnél előre tudjuk a lehetséges értékeket, és ráadásul azok száma nagyon csekély; Típus a mező megengedett tartalma az idő múlásával változhat, és azok száma akár nagyon nagy is lehet. A megengedett értékeket előre ismerjük, és azok száma csekély Amennyiben a megengedett értékeket előre tudjuk, és azok később sem fognak változni, akkor a lehetséges értékeket előre megadjuk, és magában a táblában tároljuk. A már hivatkozott 2. táblázat szerinti kiinduló feladatunkban az Üzemanyag mező megengedett értékeit célszerű így megadni. A megengedett értékeket előre nem ismerjük, azok időben változnak, vagy a megengedett értékek száma nagy A korábban már megbeszélt módon egy külön táblában tároljuk le a lehetséges értékeket úgy, hogy a két tábla között vagy mi építünk, vagy a Keresésvarázsló segítségével építtetünk ki kapcsolatot. Ehhez mindkét táblának tartalmaznia kell egy-egy olyan mezőt, melyek tartalma a kapcsolódó rekordokban azonos értéket vesz majd fel. Ez a mező a megengedett értékeket tartalmazó táblában elsődleges kulcs, a másikban idegen kulcs szerepet fog majd általában betölteni. A Keresés varázsló valójában tehát nem is önálló típus, hanem csak két tábla között épít fel kapcsolatot (mint később majd látni fogjuk, illetve mint az imént 1 OLE, azaz Object Linking and Embedding, magyarul objektum kapcsolás és beágyazás 17

18 ECDL Adatbázis-kezelés modul már szóba is került, néha nem is kell hozzá két tábla). A Keresés varázsló mindkét módszer szerinti alkalmazását részletesen megtárgyaljuk a későbbiekben ( ) A mezők hosszáról Az Microsoft Access esetében a mezőhosszokkal nem kell sokat törődni, mivel a legtöbb adattípus eleve meghatározza a mezők hosszát. Ez alól csak a Szöveg típus jelent kivételt. Szerencsére azonban ekkor sem kell összes kéz- és lábujjaink felhasználásával pontosan kiszámolni a leghosszabb lehetséges adatok figyelembevételével a minimálisan szükséges mezőhosszt. Az Access ugyanis roppant intelligensen kezeli az adatokat: ha egy karakteres mezőbe bevitt adat rövidebb, mint a mező hossza, a ki nem töltött mezőrészt nem tölti fel szóközökkel. Ehhez persze elég sokat kell a programnak trükköznie az adatokkal, de mégis elég megbízhatóan működik minden. Pontosan az adatok kezelése miatt viszont mégse adjunk meg mindent 255 karakteresre, mondván, hogy abba minden adat elfér! A feleslegesen nagyra vett mezőhossz ugyanis komolyabb adatbázisok esetében lassíthatja a program futását! Az alapértelmezett 50 karakter még a legtöbb, kifejezetten terjedelmesnek számító, de rekordonként változó hosszúságú adat esetében is megfelel. Erre példaként a teljes személy- és áruneveket, komplett lakcímeket, stb. tudnám felsorolni. Ha a név és cím adatokat részekre bontjuk, azaz külön-külön mezőben tároljuk a vezeték- és keresztneveket, a helység- és utcaneveket, akkor nyugodtan vegyük még kisebbre, mondjuk kb. 30 karakterre a mezők hosszát. Amennyiben viszont pontosan tudjuk a letárolandó adat maximális hosszát, akkor azt pontosan is illik megadni. Ez utóbbira példaként az irányítószámot (4 karakter), a személyi számot (11 karakter), a rendszámot (6 karakter), stb. említhetem. Mi a helyzet a régebbi adatbázis-kezelőkkel? A klasszikus adatbázis-kezelők esetében (pl. dbase, Clipper) minden rekord fix méretű helyet foglalt el a lemezen akkor is, ha a rekordban lévő karakteres adatok nem töltötték ki a mezőt. Sőt! A régebbi programok némelyike a numerikus adatokat is karakteres formában tárolta. Ez persze nagy pazarlást jelentett. Így persze nagyon gondosan mérlegelni kellett az egyes mezők hosszát. 2. Feladat: Tervezzük meg a raktári adatbázisban letárolandó adattáblákat. Ez alatt egyaránt értsük az egyes táblák, valamint azok mezőneveinek, típusának, és hosszának meghatározását, az elsődleges kulcsok és idegen kulcsok, a kapcsolatok, és az indexek megadását. Ehhez elsőként pontosan meg kell határozni, hogy mit várunk el a programtól. Ezt ugyan korábban már ismertettem, de mivel a követelményeket most kell felhasználni, még egyszer felsorolom a kívánságlistát : az adatbázis tárolja le a raktárban lévő anyagok és termékek alapadatait, és mutassa a pillanatnyi raktárkészletet; tartsa nyilván a szállítók legfontosabb adatait (feltételezve, hogy minden árucikket csak egy szállítótól szerez be a cég); legyen nyomon követhető a készlet változása, azaz a készletet növelő be-, illetve a készletet csökkentő kivételezések (a változás pontos jellege csak a bizonylatszámból, készletnövelő, vagy csökkentő volta pedig a mennyiség előjeléből fog kiderülni). Megoldás: 1. lépés: Mezőnevek, típusok és hosszak meghatározása Elsőként össze kell gyűjteni az összes, tárolni kívánt információt, azaz meg kell határozni a majdani adattáblák mezőit. Azért beszélek adattáblákról, mert úgyis több részre kell osztani az adatokat. Akkor lássuk a mezőket: Az adat leírása a választott mezőnév típus hossz a termék neve Termék név Szöveg 30 a termék mértékegysége Mértékegység név Szöveg 10 a termék VTSZ 1 száma VTSZ szám Szöveg 10 a termék ÁFA kulcsa ÁFA kulcs Szám a termék szállítójának neve Szállító név Szöveg 30 a szállító, vevő címe Irányítószám Szöveg 4 Város Szöveg 30 1 A VTSZ szám a vámtarifa szám rövidítése. Ez alapján kerül meghatározásra, hogy az adott termék, vagy szolgáltatás milyen módon vehető figyelembe a könyvelések során. Fontossága miatt célszerű már a raktári rendszerben is nyilvántartani. 18

19 Utca és házszám Szöveg 30 a szállító telefonszáma Telefonszám Szöveg 11 a szállító fax száma Fax szám Szöveg 11 a készletváltozás bizonylatának száma Bizonylatszám Szöveg 1 10 a készletváltozás dátuma Dátum Dátum a készletváltozás jellege 2 Jelleg Szöveg 1 a készletváltozás nettó egységára Nettó egységár Szám és a készletváltozás változás mennyisége Mennyiség Szám A következő lépésben a felsorolt mezőket több táblára kell bontani. Access XP alapokon Termék név Mértékegység név VTSZ szám ÁFA kulcs Szállító név Irányítószám Város Utca és házszám Telefonszám Fax szám Bizonylatszám Dátum Jelleg Nettó egységár Mennyiség A termék neve A termék mértékegysége A termék VTSZ száma A termék ÁFA kulcsa A termék szállítójának / vevőjének neve A termék szállítójának / vevőjének irányítószáma A termék szállítójának / vevőjének városa A termék szállítójának / vevőjének utcája, házszáma A termék szállítójának / vevőjének telefonszáma A termék szállítójának / vevőjének fax száma A készletváltozás bizonylatszáma A készletváltozás dátuma A készletváltozás jellege A termék nettó egységára A készletváltozás nagysága 7. Táblázat: Az adattábla első nekifutásra így néz ki (felül az adat leírása, alul a választott mezőnevek) 2. lépés: Táblákra bontás A józan ész módszerrel kapcsolatban azt tanultuk, hogy több egymással kapcsolatban lévő táblára történő bontással próbáljuk kiszűrni a redundáns, illetve az olyan időben változó adatokat, melyeknek minden korábbi értéke is megőrzendő (természetesen, ha a táblákra bontáshoz a normalizálást, vagy az ER módszert használhatjuk, a végeredmény akkor is több, egymással kapcsolatban lévő tábla lesz). Arról is volt szó, hogy a redundancia megelőzése miatt szétbontott táblák közötti kapcsolat fenntartásához szükség van olyan mezőkre, melyek mindig mindkét egymáshoz kapcsolódó táblában szerepelnek. Ezek a mezők az egyik táblában elsődleges kulcsok, a másik táblában idegen kulcsok lesznek. Redundáns adatok kiszűrése Elsőként felveszünk egy Szállító kód mezőt (hiszen lehet két azonos nevű szállító is, így a név nem használható elsődleges kulcsként). Átgondolva a dolgokat nyilvánvaló, hogy több termék is származhat ugyanattól a szállítótól (azt viszont korábban kikötöttük, hogy minden termék csak egy szállítótól származhat). Ez azt eredményezné, hogy a szállítók adatai redundánsak lennének. Így az már biztos, hogy a szállítók adatait egy külön adattáblában kell majd tárolni. Minden szállítói adatot át kell rakni tehát egy külön táblába, melynek a neve legyen Szállító törzs. A kapcsolat érdekében az eredeti helyen megmarad a Szállító kód mező, mint idegen kulcs, míg a Szállító törzs táblában ugyanez a mező elsődleges kulcs lesz. A tábla mezői tehát a következők legyenek: Szállító törzs Mező név típus hossz Szállító kód Számláló Szállító név Szöveg 30 Irányítószám Szöveg 4 Város Szöveg 30 Utca és házszám Szöveg 30 1 Csak akkor kell Szöveg típust választanunk, ha a bizonylatszámot mi adjuk meg. Ha a készletváltozás bizonylatszáma a gép által kerül kiosztásra, akkor Számláló típust kell deklarálni. 2 Célszerűnek látszik a készletváltozás jellegét is letárolni (beszerzés, visszáru szállító felé, selejtezés, eladás, visszáru vevőtől, ). 19

20 ECDL Adatbázis-kezelés modul 20 Telefonszám Szöveg 11 Fax szám Szöveg 11 Mivel ugyancsak redundanciát jelentene, ha minden mértékegységet újra és újra begépelnénk, ezért alkalmazzunk egy további adattáblát melynek neve Mértékegység törzs legyen. A kapcsolattartás céljából a régi helyén lesz egy Mértékegység kód mező, mint idegen kulcs, míg a Mértékegység törzs táblában ugyanez a mező elsődleges kulcsként fog szerepelni. Mértékegység törzs Mező név típus hossz Mértékegység kód Számláló Mértékegység név Szöveg 10 Miért rakjuk külön adattáblába a mértékegységeket? A kérdés arra vonatkozik, hogy miért nem tároljuk a megengedett értékeket a Termék törzs táblában, hiszen a Keresés varázsló típus alkalmazásával ez is megoldható lenne ( ). Azért rakjuk mégis külön táblába, mert a megengedett mértékegységek az idők folyamán bővülhetnek. Változó adatok kiszűrése Valószínűsíthetően az egyes beszerzések és raktárból történő kivételezések (selejtezés, eladás, szállítónak visszaküldött áru) pontos adatai a későbbiekben is a rendelkezésünkre kell, hogy álljanak. Ezt úgy tudjuk biztosítani, hogy egy külön adattáblában minden ilyen esemény fontos adatát letároljuk. Természetesen erre a célra is egy külön adattáblát kell felvenni, melynek neve Tranzakciók, legyen. A mezőit is rögtön ismertetem, de előtte egy megjegyzés: nem kell külön mezőt felvenni elsődleges kulcsnak, mivel a Bizonylatszám egyedi azonosító. Akkor lássuk a mezőket: Tranzakciók (első nekifutásra) Mező név típus hossz Bizonylatszám Szöveg 5 Dátum Dátum Jelleg Keresés varázsló Termék kód Keresés varázsló Mennyiség Szám Nettó egységár Szám He belegondolunk, sajnos a Tranzakciók adattáblában még van redundancia: ha több terméket is egy bizonylaton mozgatunk, akkor minden rekordban letárolásra kerül a Dátum, és a Jelleg. Ezt a két mezőt rakjuk át egy másik adattáblába, ennek a neve legyen a Tranzakciók, és a maradék kapjon új nevet: Tranzakciók tételei Tranzakciók (végleges) Mező név típus hossz Bizonylatszám Szöveg 5 Dátum Dátum Jelleg Keresés varázsló Tranzakciók tételei Mező név típus hossz Bizonylatszám Szöveg 5 Termék kód Keresés varázsló Mennyiség Szám Nettó egységár Szám Az eredeti adattábla maradék mezői képeznék a Termék törzs adattáblát, melynek persze szintén lenne egy Termék kód mezője is. Nézzük át, mire is jutottunk. Termék törzs Mező név típus hossz Termék kód Számláló Termék név Szöveg 30 Szállító kód Keresés varázsló