adatbázis, fejlesztés, hogyan

Adatokat sokféle módon tárolhatunk de az biztos, hogy bizonyos méret felett a saját dolgunkat könnyítjük meg ha valamilyen struktúrába szervezzük őket. Így vagyunk ezzel mindennel amiben kereséseket akarunk végezni. Ezért van egy fiókunk a zokniknak és a gatyáknak, egy az ingeknek és egy a pólóknak. Helykihasználtság szempontjából rakhatnánk mindent egybe is, de így sokkal nehezebb lenne megtalálni a kedvenc piros-citromsárga kockás szerencse zokninkat. No, ilyen egy adatbázis.

Az adatbázis elv

Vegyünk egy iskolai személyi nyilvántartó rendszert példaként. Vannak diákok, tanárok és osztályok. Ha szereténk egy táblázatba rendezni az adatokat akkor valami ilyesmit kapunk.

Talán 3 diák és 4 tantárgy esetében még nem olyan problematikus ez a megoldás, de mondjuk egy átlagos iskola esetében pár száz diáknál már sok problémánk lesz ezzel a megközelítéssel. Mi történik ha Szőrös Bertold pályát módosít és a továbbiakban lángossütőként tengeti életét? Mivel a diákok nem maradhatnak matek tanár nélkül az iskola felveszi Izzó Ilonát. A táblázatunkban pontosan annyi cserét kell végrehajtanunk ahányszor szerepel Szőrös Bertold neve a táblázatban. Persze ez még viszonylag könnyen automatizálható, de mi van akkor ha az új inkvizítor csak az 1/A és a 3/C osztályt veszi át és ideiglenes jeleggel 4-5 óraadóval helyettesítik a régi tanárt? Egy ilyen jellegű változás végigzongorázása már jóval bonyolultabb és így több hibalehetőséget rejt magában.

Egy adat tárhellyel szemben két fő igényünk van. Az egyik, hogy adatokat tudjunk bele eltárolni, a másik pedig az, hogy az eltárolt adatokat ki tudjuk nyerni belőle. Egyszerű kis táblázatunk egyik szempontból sem áll a helyzet magaslatán. Ha jön egy új diák valamelyik osztályba annyi példányban kell berögzítenünk ahány tantárgyat tanul.

Azt is könnyen láthatjuk, hogy a táblázatunk sok felesleges ismétlődést tartalmaz.

Minek szerepel minden diák neve olyan sokszor? Teljesen felesleges, de ebben a változatban nem tudjuk másképpen megoldani. Mi lenne ha a felesleges ismétlődéseket kiszűrnénk vagy legalábbis minimalizálnánk?

Itt jönnek az adatbázisok a képbe. Pontosabban a relációs adatbázisok. A relációs adatbázisok segítségével egymással kapcsolatban álló adatokat tárolhatunk.

Gyakorlati példa

Legyen egy táblánk a tanárok és egy a diákok számára. Ezzel elérjük, hogy a nem összefüggő adatok külön vannak tárolva, egy helyen. Ehhez mindkét táblában hozzáadunk egy-egy azonosítót is. Ezen felül kell egy olyan tábla is amely a kettő kapcsolatát tartalmazza. Valahogy így.

A helyzet határozottan javult, de a fenti problémáink még mindig fennállnak bizonyos fokig. Mi van ha valaki átmegy egy másik osztályba? Mi van ha egy tanár több mint egy tantárgyat tanít? Egyébként meg honnan fogjuk tudni, hogy melyik osztálynak ki az osztályfőnöke? No kicsit gyurmázzunk még az adatbázis tervünkön.

Következmény

A fenti képünk első látásra talán felesleges bonyolításnak tűnik, de ha kicsit utána gondolunk akkor látnunk kell, hogy a különféle adatok külön táblákba mozgatása és a kapcsolataik ábrázolása milyen rugalmassá teszi az adattárolási eljárásunkat. A fenti elvi váz segítségével megoldunk minden fent vázolt problémát. Persze nem feltétlenül ez a végleges adatbázis felépítés és modell, az igényeknek megfelelően a későbbiekben még módosítható.

Fogalmak

Az adataink többszörös megjelenését redundanciának hívjuk. Amint láttuk a redundancia – legalábbis általánosságban – üldözendő. A rajzunkon lévő kis dobozkák az adatbázis tábláinkat ábrázolják. Egy táblába pakoljuk a valamilyen okból együtt kezelendő adatokat. Pl a tanár táblánkat bővíthetnénk a tanár személyes adataival, stb. A táblán belül az adatokat oszlopokba soroljuk. A tanár neve, születési dátuma, stb egy-egy oszlop.

Maguk az eltárolt adatok sorokban vagy rekordokban vannak. Az egyes rekordokat meg kell különböztetni egymástól. Ehhez többnyire egy olyan mezőt választunk (példánkban az id) amely garantáltan nem ismétlődik. Ez az elsődleges kulcs, a primary key.

A folyamat ami során a kezdeti, ismétlődéseket (azaz redundanciát) tartalmazó táblázatunkból eljutottunk egy több táblába tagolt ismétlődéseket nem tartalmazó adatbázis szerkezetig pedig a normalizálás. Az egyes lépcsőfokok a különböző normálformák.

Az adattábláink összessége pedig maga az adatbázis.

Normálformák

Az első normálforma esetében kiszűrjük az ismétlődéseket és külön táblába rakjuk a külön kezelendő adatokat.

A második normálforma esetében arról gondoskodunk, hogy egy táblán belül a mezők csak az elsődleges kulcsttól függjenek.

A harmadik normálformában a táblákban egy mező sem függ valamelyik másiktól.

A normálformák magyarázata elég technikai, általában akkorra érti meg az ember, mikorra már párszor sikeresen alkalmazta Ördögi kör, de ha a józan eszünkre hallgatunk akkor a fenti leírás alapján bármilyen problémát le tudunk modellezni a harmadik normálformára.

A harmadik normálforma azért fontos, mert ez biztosítja, hogy az adatbázisunk megfelelően tagolva és szervezve legyen.

Ez a bejegyzés rrd billentyűzetéből potyogott ki 2008 szeptember 18. napján 12:00:20-kor. Eddig 3,532 olvasást ért meg. A visszajelzéseket nyomonkövetheted ezzel az RSS feed-el. Véleményt nyilváníthatsz, vagy trackbackolhatsz a saját oldaladon.