Relációs adatbázisok: egy korszak vége
kategória: Hírek — forrás: Computerworld — dátum: 2008-09-03 17:10:03A számítástechnikában akár évek alatt is alapjaiban változhatnak meg a programozási modellek, processzorarchitektúrák.
A relációs adatbázisok ötlete 1970-re nyúlik vissza, amikor Edgar Codd kitalálta és dokumentálta ezt a fajta adattárolási módszert. Még 38 évvel később is a relációs adatbázisok jelentik az "adatbázisokat", alternatív rendszerekkel aligha lehet találkozni. A relációk, ismertebb nevükön a táblák tárolják az adatokat, illetve definiálják az egymás közötti kapcsolatokat. A táblázatos adattárolás egyszerűbb adatok esetében praktikus - gondoljunk csak a "verhetetlen" Excelre mint mini adatbázisra. Könyvelők, pénzügyesek el sem tudnak képzelni ennél jobb adatbázist! Egyszerű tervezni ilyen rendszereket, könnyű áttekinteni azokat, mindenki megszokta már, így már-már jónak is lehet gondolni. Ráadásul annyira nincs alternatíva, hogy nem is bosszankodunk, ha valami nagyon hiányzik vagy nagyon nem jó.
A relációs rendszereknek tehát van létjogosultságuk, ám kérdéses, hogy a számítási kapacitás és a szoftverkeretrendszerek drámai fejlődésével nem lehet-e ennél jobb ötletekkel előállni. A különös az egészben az, hogy az üzleti igények, a rendszerekkel szemben támasztott mondatokba önthető követelmények nem adatbázisokról, relációkról, kulcsokról, távoli kulcsokról szólnak... Sokkal inkább "szerződésről", "partnerről", "díjfizetésről" és egyéb ilyen magas szintű üzleti objektumról, amelyek relációs leképezése nem egyszerű feladat.
Azt el kell fogadnunk, hogy a rendszerek alapjában egyszerű adatokat kérnek a felhasználótól (név, cím, életkor stb.), és ezeket kell tárolni valahol. A relációs rendszerek erre alkalmasak egészen addig, amíg tényleg csak ilyen egyszerű adatokról van szó. Amint egy "szerződés" objektumhoz tetszőleges számú "követelés" és "teljesítés" tartozhat, már rögtön nem ennyire egyszerű a helyzet. Amíg például az egy-több reláció még magától értetődő (egyetlen távoli kulcs), addig a több-több reláció már nem: fel kell venni egy összekapcsoló táblát, azt speciálisan kell kezelni, figyelni a referenciák megtartására és így tovább. Innentől persze bármeddig bonyolíthatjuk az adatbázistervet, hamar olyan táblák és összefüggések fognak körvonalazódni, amelyek egészen távol esnek az egyszerűen megfogalmazható üzleti igényeken. Éppen ezért egyre inkább szükségszerűnek tűnik, hogy a relációs adatbázisokat leváltsák más rendszerek, amelyek közelebb állnak az üzleti igényekhez, a felhasználói igényspecifikációkhoz.
Triviális irány az objektumrelációs leképező rendszerek beépítése az adatbázismotorba. Erre már van próbálkozás néhány gyártótól, és az elgondolás nem is rossz: a háttérben továbbra is a jól bevált, jó teljesítményű, 38 éve megszokott rendszer áll, a külvilág felé pedig egy magas szintű objektumokkal dolgozó rendszer látszik. Általában ezeket Java vagy .NET nyelven lehet elérni, azon rendszer objektumait menteni, betölteni. Vannak már olyan keretrendszerek is, amelyek objektumrelációs leképezést végeznek, de nem az adatbázis szintjén vannak implementálva, hanem egy réteget képeznek az adatbázis és a fejlesztői felület között. Ennek nagy hátránya, hogy a háttérben a relációs rendszerhez is érteni kell; hiszen ha teljesítmény-, inkompatibilitási vagy egyéb gondok vannak, akkor nem lehet az adatbázis gyártójára mutogatni. Ez fog változni az adatbázisba épített környezettel, hiszen ott minden felelősség az adatbázis gyártójáé. Hosszabb távon ezek teljes integrációja várható.
Ezzel párhuzamosan pedig vissza fognak szorulni a relációs adatbázisok, amelyek amúgy is igen kényelmetlenek, s egyre kevésbé lehet a magas szintű üzleti igényeket kiszolgálni velük. Egy-egy könnyen megfogalmazható riport lekérdezése nemritkán 2-3 oldal SQL-lekérdezésre képezhető le, és ember legyen a talpán, aki azt utána megérti, vagy esetleg még javítani is tudja...
