A hónap témája:
Adatbázisok |
Nézzünk körül a
nagyvilágban. Akárhová tekintünk, mindenütt egy adatbázisba botlunk. A céges
belépőkártyánk, az autónk rendszáma, a merevlemezünk típusa, gyártási
éve, mind-mind egy hatalmas adatbázis aktív részei lettek ez utóbbi években.
Ha picit el akarunk rugaszkodni a valóságtól, akkor hivatkozzunk a
"Hálózat" (The Net) című filmre. Pár gombnyomással a gonosz
hacker módosítja a szövetségi adatbázisban a szimpatikus programozó adatait,
aki ezentúl mint körözött bűnöző szerepel a nyilvántartásokba. És talán ezzel a
mondattal elmondtam az adatbázisok felhasználásának egyik lehetőségét
is, de semmiképpen nem szerettem volna elhallgatni az előnyeit és
természetesen a fennálló veszélyeket se. Egy adatbázis megoldja a rengeteg
nyilvántartáshoz szükséges hely hiányából kiinduló problémákat, egy helyen
tárolja az adatokat, bármikor hozzáférést biztosít hozzájuk, és természetesen
védelmi rendszert is nyújt az adatok biztonsága érdekében. Nem akarok nagyon
elkalandozni, hisz az számunkra, programozók számára nyilvánvaló, hogy ahhoz,
hogy valaki módosítani tudja az adataimat, és körözött(es) bűnözőt
faricskáljon belőlem, oda bizony többre is szükség van, mint pár
gombnyomásra, és aránylag kicsi a valószínűsége, hogy ez meg fog
történni. Vizsgáljuk inkább
sokkal praktikusabb szemszögből az egész adatbázis világot.
Adatbázisokra igenis szükségünk van, a fent említett (teljesség igénye
nélküli felsorolásban szereplő) előnyök miatt. És nem elég, ha ma
meghozzuk a döntést, hogy nekünk igenis, holnaptól kell egy ilyen és ilyen
képességekkel bíró adatbázis. Ezt az adatbázist meg kell tervezni, papíron,
itt jelenik meg az első kapcsolat az adatbázis programozó és a kliens
közt (akik mi vagyunk). Az adatbázis
tervezés talán a legfontosabb szakasz egy adatbázis életében hisz ilyenkor
hozunk olyan döntéseket, melyek függvényében később egy keresés tíz
másodpercig vagy éppen százig fog tartani, hogy az adatbázisunk mekkora
tárterületet fog elfoglalni, és minden, a tervezés idejében felmerülő
kis tényező a későbbi, adatbázissal történő munkánkat fogja
befolyásolni. Az adatbázis tervezőnek van talán a legnagyobb
felelősséggel rendelkező feladata, hisz tőle függ, hogy a
kliens felkérései alapján az adatbázis módosítása a programozó részéről
tízperces vagy éppenséggel háromórás munka lesz–e, egy jó adatbázis
tervező kizárja a redundanciákat az adatbázisból, modularizálja az adat
entitásokat, és még rengeteg más lényeges munkát végez el. Az adatbázis
létrehozás életciklusában a másik fontos szerepet talán az adatbázis programozó(k) foglalja(ák) el. Szoros
közreműködése a tervezővel és a klienssel létrehozzák az utóbbinak
megfelelő "infrastrukturát", kezdve a legapróbb kis
CheckBox-tól egészen addig a nagy fontosságú döntésig, hogy milyen adatbázist
fognak használni, hisz kínálat van... Beismerem, régebben
valahogy idegenkedtem az adatbázisoktól, nem is beszélve a programozásukról,
valamiért mindig úgy tekintettem azokra, akik adatbázisokat programoznak,
hogy ők a "hátulgombolós" programozók, hiszen nincs bajuk
memóriacímekkel, bittérképekkel, színekkel a képernyőn, ők csak
ülnek az SQL mellett, és néha egy-egy Delphi komponenst bedobnak a Formra, és
semmi látványos erőfeszítés nélkül megjelennek az adatbázis adatai az ablakba.
Mintha nem is lett volna semmi munkájuk. Aztán később,
mikor én is elkezdtem mélyrehatóbban adatbázisokkal foglalkozni, rádöbbentem,
hogy nem is olyan egyszerű, és a kihívások sokkalta nagyobbak, mint az
"előlgombolós" programozók esetében. Az teljesen igaz, hogy
nagyon egyszerűen megoldható egy két dolog, amire a Windows/DOS
programozás aránylag bonyolult megoldásokat kínál, viszont az igazi kihívások
nem ott kezdődnek, hogy rakjunk fel három beviteli mezőt a
képernyőre, írjuk bele, hogy "Hello World" és ugráltatjuk
őket. Az igazi kihívás az
"életcsiholás" az adatbázisba. Amikor a rendelkezésünkre álló
élettelen adathalmazból a kliens
elvárásainak megfelelően létrehozzuk a lüktető, életteli,
változásokat reflektáló dinamikus rendszert. Szerintem ez az igaz
művészet. Deák F. |