Adatbázis-kezelés

A táblázatkezelő használata után már van fogalmunk az adatról, mint az informatika fő nyersanya-
gáról. Ősidők óta az ember célja, hogy megőrizzen forrásokat a jövő számára. Nincs ez másként
ma sem, azzal a különbséggel, hogy manapság minden születő új adatot, a kőbe vésés helyett a
0,1 jelek sorozatává alakítjuk, és így próbáljuk eltárolni korunk csúcstechnológiáinak segítségével.
Azt is tudjuk már, hogy az adataink különböző típusúak lehetnek, és tárolásukkor fontos, hogy
ezzel tisztában legyünk. Eddig nem tartottuk fontosnak, hogy a különböző helyen és időben ke-
letkező adatok milyen kapcsolatban lehetnek egymással, és ezt az ismeretet hogyan tudnánk ma-
gunk javára fordítani. Vajon a twitter üzenetekben terjedő negatív hangulatú szavak területi elő-
fordulásának gyakoriságát figyelve előre tudnánk-e jelezni valamilyen katasztrófát? Nos már ez
sem tűnik lehetetlen, ha az adatbányászatot elfogadjuk mint az információ szerzésének egyik jö-
vőbeli módszerét.
Az elmúlt évtizedek technológiájának fejlődése hatalmas mennyiségű adat tárolását teszi szüksé-
gessé nap mint nap. Ez rendkívül változatosan történhet, az egyéni módszerektől kezdve egészen
a világ minden pontjáról elérhető, jogosultsági szintekkel megosztott kereshető megoldásokig. Az
informatikában jelentős erőforrásokat köt le az adatok tárolására, és kezelése. Szinte nem lehet
az élet olyan területét említeni, ahol ne függenénk valamilyen módon a különböző tárolt adatok-
tól.

Alapfogalmak
Adat: Észlelhető, érzékelhető, megérthető, felfogható ismeret
Információ: Új ismeretté értelmezett adat
Adatbázis: Az adatokon kívül az adatok közötti kapcsolatokat is tartalmazó rendszer
Az adatbázisra tekintsünk úgy, mint a hangjegyekre a zenében. Az adatok, mint a hangok a zene
világában, önmagukban értelmezve kevés jelentőséggel bírnak, ahhoz, hogy megszólaljanak, vagy
zenéljenek nekünk, ahhoz szükség van a közöttük lévő kapcsolatok értelmezésére. Az adatbázis
kezelő rendszerek alkalmasak arra, hogy alkalmas adathalmazt alapul véve konkrét kérdésekre
kaphassunk választ.
Képzeljük el, hogy egy rendszám nélküli elhagyott kocsi áll már napok óta az utcán. Hogyan tud-
nánk kideríteni, hogy ki a tulajdonosa? Ha lenne rendszám, akkor könnyűnek tűnhet a dolgunk.
De a népi érdeklődésen túl gyakorlatilag nem tehetünk mást, mint segítséget kérünk a rendőrség-
től. Mehetnénk még az okmányirodába is, de ott sem fognak segíteni a titok kiderítésében. Vajon
miért? A válasz egyszerű, az autó és a tulajdonos adatai nem nyilvánosak, csak akik erre munkájuk
során felhatalmazást kapnak, azok nézhetnek utána. Elvileg mi ismerhetünk minden más embert,
és látjuk az utakon haladó autókat is, még sem tudjuk minden esetben a járművet és az embert
összekapcsolni. Ehhez ismernünk kell a tulajdonosi kapcsolatot az autók és az emberek halmaza
között. Az emberek és az autók halmaza létező, látható, érzékelhető elemekből áll, addig a tulaj-
donlás már egy nehezebben értelmezhető halmaz. Mégis, abban az esetben, ha szeretnénk kide-
ríteni, hogy egy autónak ki a tulajdonosa, akkor tudnom kell, hogy az adott autó, a tulajdonláson
keresztül kivel, vagy kikkel hozhatók kapcsolatba. Az autók, az emberek, és a tulajdonlás egy adat-
bázist alkot. Nem csak az adatokat tároljuk el benne, hanem az adatok közötti kapcsolatokat is. A
mi esetünkben a tulajdonlás teremt kapcsolatot az emberek és az autók halmaza között.

Autók Emberek

Az "ember" és az "autó" gyűjtőfogalmak, leírnak, jelölnek egy sok-sok létező elemből álló halmazt.
Ezeket egyedeknek (entitásoknak) nevezzük. Ha az utcán álló autót nézzük, vagy azt az embert,
aki birtokolja, már egy úgynevezett egyed előfordulás. A "tulajdonlás" is egyed, az egyed előfor-
dulás itt azt jelenti, hogy egy konkrét autó egy ember tulajdonában van.

Tulajdonlás
Egyednek nevezzük azokat az élő és élettelen dolgokat, cselekvéseket, állapotokat, mely tulajdon-
ságokkal leírhatók. Az ember jellemezhető például a nevével, születési adataival, nemével, lakcí-
mével, és még sok-sok tulajdonsággal, az autó pedig a rendszámával, típusával, színével, motor-
térfogatával.
A következő nyilvánvaló kérdés, hogy miként kellene eltárolni a fenti példában szereplő adatokat,
hogy a kívánt információt (ki az autó tulajdonosa) meg tudjuk szerezni. Az adatbázisok leírásához,
tervezéséhez többféle modellt használhatunk. A hétköznapi gondolkodáshoz a legközelebb az
úgynevezett relációs adatmodell áll.
A relációs modellben az adatokat logikailag egy táblázatban tároljuk. A táblázatokat az adatbázis-
ban szereplő egyedek számára hozzuk létre (autó, ember, tulajdonos). A táblázat első sora a me-
zőlista, itt jelöljük mezőnevekkel az egyed tulajdonságait (név, lakcím, nem, stb.). A táblázat többi
sora a konkrét egyed előfordulások. Az ember táblában egy létező ember adatai ezek.

Autó tábla

Gyártmány Típus Szín Évjárat Motortérfogat

Renault Scenic Szürke 2004 1496
Suzuki Swift Piros 2010 1200
Volkswagen Turan Kék 2013 2000
Térjünk vissza a konkrét esetünkhöz! Van egy "beépített" emberünk, aki a következő mondattal
próbál segíteni nekünk: Egy metálszürke négyajtós 1600 cm3-s 1998-as Audi típusú gépjármű egy
hónapja a Szegeden lakó K.G. férfi tulajdonában volt. Ez az információ első ránézésre nagy segít-
ségnek tűnhet, de ahhoz túlságosan pontatlan, hogy valakit "gyanúba" hozzunk az autóval. A
problémát az jelenti, hogy nem tudjuk pontosan beazonosítani sem az ember, sem az autó tábla
megfelelő egyedét. Lakhat több K.G. nevű férfi Szegeden, és gyárthattak a megadott tulajdonságú
Audiból is többet. Persze a keresés szűkült, már csak pár ezer "párkapcsolatot" (autó-ember) kel-
lene ellenőrizni.
Az adatbázisok megismerésében eljutottunk odáig, hogy szükségünk van az egyedek pontos azo-
nosítására. Az emberek esetében lehet ez pl. igazolványszám, adóazonosító, vagy bármi más
olyan alkalmas jelzés, ami két ember esetén nem lehet azonos. Lehetnek biológiai jellemzők is,
mint az újlenyomat, írisz, vagy DNS.
A tábla elsődleges kulcsának (primary key) nevezzük azt a mezőt, mely egyedi a tábla soraira
nézve. Nem fordulhat elő, hogy a tábla két sora kulcsában megegyezne. Nem létezhet két ember
azonos adójellel, vagy TAJ számmal és két autó sem ugyanazzal a rendszámmal.
A tábla különböző számú egyedtulajdonságokat (mező) tartalmazhat. Ahány tulajdonság, annyi
oszlopa van a táblázatnak. Fontos tisztában lennünk azzal, hogy az adott mező milyen típusú ada-
tot rejt. A táblázatkezeléshez hasonlóan itt is megkülönböztetjük a szöveg, szám, és logikai típusú
adatokat, de például a szöveg esetén korlátozhatjuk annak méretét. Erre azért van szükség, hogy
csökkentsük a tároláshoz szükséges tárhelyet. A különböző adatbázis-kezelő rendszerek még több
típust is támogatnak (dátum, idő, halmaz)
 Ember tábla

Kulcs Mezőnév Adattípus

Elsődleges Adóazonosítójel Szöveg
Név Szöveg
Születési idő Dátum
Férfi Logikai
Az ember és az autó tábla tulajdonságaival, és szerepével már tisztában vagyunk, most vizsgáljuk
meg a tulajdonlással kapcsolatos táblát. Ezt funkcióját tekintve kapcsolótáblának nevezzük, mert
az ember és az autó tábla rekordjait kapcsolja össze. Az emberek és az autók azonosítására az
egyes kulcsmezőket használja. Tulajdonságként megadhatjuk, hogy a tulajdonlás mely naptól
meddig tart.
Ábrázoljuk most a táblákat, és a kapcsolatokat! Ezt nevezzük az adatbázis sémájának. A kapcsola-
tokat jelölő vonalak azt jelentik, hogy az adatbázis-kezelő rendszer "motorja" képes megkeresni
a kapcsolat egyik végén lévő adathoz (általában kulcsa alapján) tartozó összes olyan sort a másik
táblában, ahol ezek a mezők megegyeznek. Azt már nem kell tudnunk, miként teszi ezt.

Most tűnődjünk el azon, hogy van-e kulcsa a tulajdonlás táblának? Nyilván a benne lévő négy
mező önállóan nem tölthet be kulcs szerepet. Egy embernek lehet több autója (tulajdonlása), és
az autónak is lehet több tulajdonosa. Az sem kizárt, hogy az ember újra tulajdonosa lesz ugyan-
annak az autónak. Nem feltétlenül szükséges kulcs mezőt létrehozni egy kapcsoló táblához. Az,
hogy mi elegendő kulcsnak, az a probléma specifikációja során kell kiderüljön. Ha azt mondjuk,
hogy nem engedhető meg, hogy egy ember újra megvásárolja ugyanazt az autót, akkor már az
(adóazonosító, rendszám) értékpár alkalmas lenne a kulcs betöltésére. Ha több mezőből áll a
kulcs, akkor azt összetett kulcsnak nevezzük. Általában akkor van szükségünk egyedi azonosí-
tásra, ha az egyedet szeretnénk egy újabb táblával összekapcsolni. Ha a tábla kulcsa megjelenik
egy másik táblában, akkor azt idegen kulcsnak nevezzük (foreign key).
Ejtsünk még néhány szót a kapcsolatok típusáról. Háromféle kapcsolati típust különböztetünk
meg: egy az egyhez (1:1), egy a többhöz (1:N), több a többhöz (N:M) kapcsolatokat.
Egy az egyhez (1:1) kapcsolat azt jelenti, hogy az egyik tábla tetszőleges rekordjához a másik tábla
pontosan egy rekordja tartozhat, és ez fordítva is teljesül. Ilyen kapcsolatot ritkán használunk,
mert a két tábla mezőit egyetlen táblába is helyezhetjük. akkor lehet erre szükség, ha túl sok tu-
lajdonság van már egy táblában, esetleg nagyon sok sora van.
Leggyakrabban egy a többhöz típusú kapcsolatot használunk, mint a példánkban is. Az ember
tábla egyetlen sorához a tulajdonlás tábla több rekordja is tartozhat, fordítva viszont ez nem igaz.
Hasonlóan az autó tábla egy sorához a tulajdonlás tábla több sora tartozhat.
Több a többhöz típusú kapcsolatot relációs adatbázisokban nem használunk. Ilyen lenne, ha össze
tudnánk kötni az autó és az ember táblát. Helyette egy harmadik, kapcsoló táblát alkalmazunk,
ami jelen esetben a tulajdonlás.
Ezzel az adatbázisok megismerésének bevezető szakasza véget ért, most néhány példán keresztül
bemutatjuk, hogyan születik meg az adatbázis szerkezete, vagyis a sémája.
Eddig nem beszélünk róla, de most már időszerű szót ejteni arról, milyen alapvető elvei vannak
az adatbázis tervezésének. Nevezhetjük ezt egyszerűen ökölszabályoknak is, melyek mindig a sze-
münk előtt kell, hogy lebegjenek:
1. Az adatbázis ne tartalmazzon többszörös (felesleges) adattárolást. Ezt idegen szóval redundan-
cia mentességnek nevezzük. Ez akkor fordulhatott volna elő a bevezető példában, ha egy tulaj-
donlás leírását egyetlen táblával kísérelnénk meg, ilyenkor ha több autója is van egy embernek,
akkor az ő személyes adatait, jellemzőit minden egyes tulajdonlásnál fel kell venni. Vagy beszél-
jünk konkrétabban, ha az ember lakcímét tároljuk, akkor ezt ne tegyük meg minden egyes alka-
lommal, ha ugyanarra az emberre hivatkozunk.
2. Az adatbázist ellentmondásmentesnek nevezzük, ha Egy kérdésre adott válasz független attól,
hogy a tábla kapcsolatain keresztül miként járjuk be az adatbázist. Például ne fordulhasson elő,
hogy egy autó tulajdonosaként egy adott napra több tulajdonost is találunk.
Amíg egy adatbázis az előző két szabályt sérti, addig dolgoznunk kell ennek elhárításán. Ezt ne-
vezzük normalizálásnak. Ennek több szintje van, itt középiskolában nem foglalkozunk vele, csak a
két sérthetetlen szabály teljesülésével foglalkozunk.

Az adatbázis tervezése, sémakészítés

Már látható, hogy nem azzal kezdünk egy adatbázist építeni, hogy átgondolás nélkül tárolni kezd-
jük az adatokat. A tervezésnek több lépése van, amit érdemes betartani.
1. A probléma felvetése
Egy adatbázis problémát megadhatunk, ha leírunk olyan kérdéseket, melyekre szeretnénk, ha az
adatbázis meg tudja majd adni a választ.
a) Egy autónak hány tulajdonosa volt?
b) Hány napig volt a tulajdonosa egy autónak egy ember?
c) Melyik a legnépszerűbb típus?
d) Átlagosan hány évesek az autók?
e) Ki volt az első tulajdonosa egy autónak?
2. Specifikáció
Egy adatbázisnak vannak korlátai, ezeket az adott szituáció dönti el. Kompromisszumot kell kötni
sok esetben. Például a mi adatbázisunk nem képes követni, ha egy autót darabokra szednek, és a
fő alkatrészei egy másik kocsiba kerülnek. Vagy ha elveszti a rendszámát, akkor mihez kezdjünk?
Hasonlóan ha változik az ember lakcíme, akkor már nem biztos, hogy megtaláljuk és akkor még
nem beszéltünk arról, hogy az emberek nevet is változtathatnak. Ha minden adatbázis tervezés-
kor az összes lehetséges problémát orvosolni szeretnénk, akkor sosem jutunk el oda, hogy kész
vagyunk.
3. Az egyedek kiválasztása
Erre akkor kerül sor, ha már tudjuk, mely adatok tárolására lesz szükségünk, és elkezdjük a táblák
szervezését. arra kell törekednünk, hogy egy táblába ne keveredjenek a különböző egyedek tulaj-
donságai. Például az emberhez ne tegyük be, hogy az autója hány ajtós, mert az az autóját jel-
lemzi. Ezek a hibák előfordulnak az első tervezésekkor. A legnehezebb eleinte a kapcsolótáblát
meghatározni, mert az nem olyan egyértelmű, mint a "fő" egyedek meghatározása. Ilyenkor tö-
rekedjünk arra, hogy alkossunk olyan mondatokat, melyek arról szólnak, hogy milyen esemény
történhet az adatbázisban. A mi esetünkben például azt mondhatjuk, hogy egy adott rendszámú
autó valamely napon tulajdonost vált.
4. Egyedtulajdonságok meghatározása
A kiválasztott egyedekhez (táblákhoz) meghatározzuk, hogy milyen mezőket hozunk létre, és azo-
kat milyen típusú adatként kezeljük.
ember(név, lakcím, születési idő, férfi)
Ezt így jelöljük:

5. Elsődleges kulcs meghatározása

El kell gondolkodnunk azon, hogy az egyes táblák esetén szükség van-e a sorok egyedi azonosítá-
sára. Ha igen, akkor válasszunk erre alkalmas kulcsmezőt. Ez lehet valami természetes azonosító,
de ki is találhatunk egyet. A valóságban sokszor ezt rábízzuk az adatbázis kezelő rendszerre, csak
azt mondjuk meg, hogy mi legyen a neve, és a típusa.
6. Kapcsolatok kialakítása
Ha ábrázoljuk a táblákat, akkor össze kell kapcsolnunk őket. Annak nem sok értelme lenne, ha a
táblák különállóak. Ebben az esetben akár táblázatkezelővel, vagy szövegszerkesztővel is dolgoz-
hatnánk, a bennünket érdeklő kérdésekre nem kapnánk választ. Gyakran ilyenkor jövünk rá, hogy
szükségünk van egy kapcsolótáblára. A kapcsolatok ábrázolásán túl jelöljük a kapcsolatok típusát
is!
A továbbiakban néhány példán keresztül sajátítjuk el a sémakészítés fortélyait.
Jegyek adatbázis
Egy iskolában adatbázisban akarjuk tárolni a diákoknak adott érdemjegyeket. Készítsük el a sémát
a következő kérdések alapján!
a) Egy diák mikor kapott utoljára jegyet matematikából?
b) Mennyi a 10a osztály átlageredménye, ha a fizika témazáró dolgozatokat vesszük csak figye-
lembe?
c) A fiúk, vagy a lányok jegyei jobbak, ha szóbeli feleletekről van szó?
d) Melyik tanár adta a legtöbb jegyet magyarból?
e) Melyik hónapban szerezték a diákok a legtöbb ötös osztályzatot?
f) Ki tanítja a történelmet a 10c osztálynak?
g) Reál, vagy humán tárgyakból kaptak több jegyet a diákok?
h) Férfi, vagy női tanár tanítja az éneket a 10. évfolyamnak?
i) Egy tanár mely tárgyakat tanítja?
Az eddig közölt információk alapján kell a specifikációt elkészíteni. Meg kell határoznunk az adat-
bázis korlátait. Ilyen lehet például, hogy a jegyek mely időszakra vonatkozzanak. egyszerűsítő fel-
tétel, ha csak egy tanévet ölel fel az adathalmaz. A következő feltevésünk, hogy egy tanár taníthat-
e több tárgyat is? Vagy taníthat-e több tanár ugyanannak a diáknak egy tárgyat (normál óra, fa-
kultáció)? Az is lehetséges, hogy egy tanár több osztály diákjaiból álló csoportot tanít. Egy adat-
bázis tervezésekor egyre több kérdés merülhet fel, ezért van lehetőség arra is, hogy menet közben
újratervezzük, módosítsuk a tervet. Ezt mindaddig megtehetjük, amíg el nem kezdjük az adatokat
rögzíteni. Ha már vannak feltöltött tábláink, akkor már nagyon nehéz változtatást végrehajtani.
Most próbáljuk meghatározni a kérdések alapján, hogy melyek az adatbázis egyedei. Ne keverjük
össze az egyedet a tulajdonságával. Célszerű elkülöníteni egymástól a diákot és a jegyeket. Érez-
zük, hogy még a tárgy és a tanár megadása is szükségessé válik valamikor, de bizonytalanok va-
gyunk, hová is illesszük őket. Mire jellemzőek ők, vagy legyenek külön egyedek? Nem adhatjuk
meg a diák táblába, hogy ki milyen tárgyat tanul. Ez jellemző hiba kezdetben. Tipikus módszer,
hogy vesszővel válasszuk el a tanult tárgyakat egy szövegmezőben.
Most érjük be a két egyeddel, amiből táblákat fogunk készíteni:
diák(név, osztály, nem)
jegy (ki kapta, mikor, miből, hogyan, hányas, kitől)
tárgy (kategória, megnevezés)
tanár (név, nem)
Nézzük meg a jegy tábla egy lehetséges részletét:
diák dátum tárgy tipus érték tanár
K.G 2017.09.12 történelem szóbeli felelet 4 M.T
S.R 2017.10.17 fizika témazáró 5 K.K
projekt-
S.R 2017.11.12 fizika 5 T.K
munka

Azonnal látszik, hogy a diák és a tanár azonosítása nem történhet a nevével, mert nem zárható ki
a névazonosság. Ezért szükséges ezekbe a táblákba egy-egy kulcsmezőt helyezni.