Vajon hol húzódik az a határ, amikor egy alkalmazásunk elengedhetetlenül rászorul arra, hogy adatainkat külön, egy külső adatbázisba tároljuk? - A határ meghúzásához nem közvetlen választ szeretnék adni. Helyette a leírásban arra törekszem, hogy megmutassam, hogy hogyan lehet gyorsan, egyszerűen, adatbázis típusától független megoldásokat készíteni. Ezzel serkentve, és közvetve válaszolni a kérdésre: ahol lehetséges, használjuk bátran az adatbázisok által kínált megoldásokat. Válasszuk szét a logikát, a megvalósítást és felhasznált adatokat.
Sok helyen olvashatunk tanácsokat arról, hogy mikor kell adatbázishoz nyúlnunk. Mekkora az az adatmennyiség, amikor elkerülhetetlenné válik, hogy egy külön adatbázist építsünk adataink tárolásához. Ezek a tanácsok kezdve a 15 recordtól az 1000 fölötti recordokat említik. Én úgy ítélem, hogy itt nem a mennyiség a mérvadó. Inkább utalnék itt arra, hogy aki már szerzett tapasztalatokat az adatbázisokkal kapcsolatban, az már „jövőheti programjaim” feladatnál is automatikusan egy adatbázis vázát látja maga előtt. Itt nem komoly tervezési, előkészítő munkára gondolok. Egy egyszerű MS Access vagy LibreOffice Base-re gondolok. Ez a két program már grafikus felületen biztosít lehetőséget a számunkra, hogy átlássuk az adatbázisban tárolt információk előnyeit.
Objektum-relációs leképezés (ORM)
Először ejtsünk szót a program alapjáról. Az objektum-relációs leképezésekről (Object-relational mapping, ORM). A témáról bővebben egy BME-s prezentációt olvashatunk (pdf). Maga a mögöttes logikát úgy tudjuk a legegyszerűbben elképzelni és értelmezni, hogy ha az adatbázis megtervezését elkezdjük közelíteni az objektum-orientált (OO) programok megtervezéséhez. Az osztályok maguk a táblák. Míg ezen osztályok példányai a tábla sorait prezentálják. A példány tagfüggvényeivel érhetjük el, módosíthatjuk, törölhetjük a sorok recordjait. Továbbá az osztályok közti öröklődés fedi le a relációkat a különböző táblák között. Ezzel a megközelítéssel egyből visszajutunk a relációs adatbázis-tervezéshez. Csupán a fogalmakat cseréltük le. A szavak lecserélésével viszont egyből átkerültünk egy másik informatikaelméleti (és -gyakorlati) paradigmába, az objektum-orientált programozás területére. - Ezzel a modellcserével pedig az adatbázis felépítése és megtervezése egyből segítséget és mankót nyújt az adatok kezeléséhez. Az adatok elérésére egy másik, külső alkalmazás szempontjából.
Összefoglalóan úgy tekinthetünk az Objektum-relációs leképezésre mint egy olyan modellre, ami az adatbázist egy osztályként definiálja. Ennek az osztálynak a leszármazottai a különböző táblák. A leszármaztatott osztályok példányai pedig az aktuális sorok, amelyeket a példány tagfüggvényeivel érhetünk el.
Miért használjam?
Áttekintettük az elméleti megfontolásokat. De én ezt miért használjam? A paradigmaváltás itt is előreutal. Azzal, hogy az adatbázisok fogalmát átemeltük az Objektum-orientált programozás gondolatvilágába: elszakadtunk az eredeti, a fogadó adatbázis típusától. A típus alatt érthetjük a két fő családot, a relációs adatbázisokat vagy a NoSQL-t. De gondolhatunk ezen típusok bármelyik altípusára is. Ez a modellezésünk szempontjából lényegtelen.
A gondolat, hogy szakadjunk el a fogadó adatbázistól, annak lehetőségeit, konkrét megvalósítási lehetőségeitől, ehelyett átkerültünk egy absztraktabb, elvontabb közegbe. Ez a közeg teszi lehetővé számunkra egy olyan adatbázis-kezelő rendszer felépítésének a lehetőséget, ahol adatbázisrendszertől függetlenül építhetjük fel a szükséges keretrendszert, amiben tárolni kívánjuk az adatainkat. - Konkrét megvalósítását pedig a rendszer újra specifikációja nélkül megváltoztathatjuk.
ORM-ek megvalósítása
Maga a gondolat, az objektum-relációs leképezés az adatbázis-kezelő rendszerek egy új generációját hívta életre. Ma már szinte bármelyik programozási nyelven találkozhatunk ilyen modullal, gem-el, beépített könyvtárral (az adott programozási nyelv zsargonjának megfelelően). A lényegük a konkrét megvalósítást, hogy milyen adatbázisrendszeren fut az alkalmazásunk, elválasszuk az adatbázis logikáját. Hiszen ez adatbázisrendszertől független. Egy-egy függvény, lekérési módszer, a különböző adatbázisok sebessége és a többi rendszerspecifikus jellemző a program logikájától független változó. Lehetséges, hogy alkalmazásunk szerkezete olyan, hogy gyorsabban fut az egyik rendszeren, míg a másikon elviselhetetlen lassú. Ezt egy ilyen modul bevezetésével, beiktatásával kényelmesen ki is próbálhatjuk a gyakorlatban, hiszen lehetőségünk nyílik, hogy néhány sor hozzátoldásával (a beállítási fájlok módosításával) tíz perc múlva egy új adatbázisrendszer környezetében futtathatjuk az adatbázisunkat.
Összefoglaló
Ez a rövid poszt most csak arra törekedett, hogy felhívja a figyelmünket a lehetőségre. Felkeltse az érdeklődésünket az ORM-ek iránt. Egy későbbiekre tervezett folytatásban egy konkrétan megvalósított példával fogom folytatni, ahol egy példán keresztül be is mutatom, hogy milyen szabadságot jelenthet a számunkra, ha az adatbázisunk megépítése során egy ilyen rendszert használunk.
Objektum-relációs leképezés (ORM)
Először ejtsünk szót a program alapjáról. Az objektum-relációs leképezésekről (Object-relational mapping, ORM). A témáról bővebben egy BME-s prezentációt olvashatunk (pdf). Maga a mögöttes logikát úgy tudjuk a legegyszerűbben elképzelni és értelmezni, hogy ha az adatbázis megtervezését elkezdjük közelíteni az objektum-orientált (OO) programok megtervezéséhez. Az osztályok maguk a táblák. Míg ezen osztályok példányai a tábla sorait prezentálják. A példány tagfüggvényeivel érhetjük el, módosíthatjuk, törölhetjük a sorok recordjait. Továbbá az osztályok közti öröklődés fedi le a relációkat a különböző táblák között. Ezzel a megközelítéssel egyből visszajutunk a relációs adatbázis-tervezéshez. Csupán a fogalmakat cseréltük le. A szavak lecserélésével viszont egyből átkerültünk egy másik informatikaelméleti (és -gyakorlati) paradigmába, az objektum-orientált programozás területére. - Ezzel a modellcserével pedig az adatbázis felépítése és megtervezése egyből segítséget és mankót nyújt az adatok kezeléséhez. Az adatok elérésére egy másik, külső alkalmazás szempontjából.
Összefoglalóan úgy tekinthetünk az Objektum-relációs leképezésre mint egy olyan modellre, ami az adatbázist egy osztályként definiálja. Ennek az osztálynak a leszármazottai a különböző táblák. A leszármaztatott osztályok példányai pedig az aktuális sorok, amelyeket a példány tagfüggvényeivel érhetünk el.
Miért használjam?
Áttekintettük az elméleti megfontolásokat. De én ezt miért használjam? A paradigmaváltás itt is előreutal. Azzal, hogy az adatbázisok fogalmát átemeltük az Objektum-orientált programozás gondolatvilágába: elszakadtunk az eredeti, a fogadó adatbázis típusától. A típus alatt érthetjük a két fő családot, a relációs adatbázisokat vagy a NoSQL-t. De gondolhatunk ezen típusok bármelyik altípusára is. Ez a modellezésünk szempontjából lényegtelen.
A gondolat, hogy szakadjunk el a fogadó adatbázistól, annak lehetőségeit, konkrét megvalósítási lehetőségeitől, ehelyett átkerültünk egy absztraktabb, elvontabb közegbe. Ez a közeg teszi lehetővé számunkra egy olyan adatbázis-kezelő rendszer felépítésének a lehetőséget, ahol adatbázisrendszertől függetlenül építhetjük fel a szükséges keretrendszert, amiben tárolni kívánjuk az adatainkat. - Konkrét megvalósítását pedig a rendszer újra specifikációja nélkül megváltoztathatjuk.
ORM-ek megvalósítása
Maga a gondolat, az objektum-relációs leképezés az adatbázis-kezelő rendszerek egy új generációját hívta életre. Ma már szinte bármelyik programozási nyelven találkozhatunk ilyen modullal, gem-el, beépített könyvtárral (az adott programozási nyelv zsargonjának megfelelően). A lényegük a konkrét megvalósítást, hogy milyen adatbázisrendszeren fut az alkalmazásunk, elválasszuk az adatbázis logikáját. Hiszen ez adatbázisrendszertől független. Egy-egy függvény, lekérési módszer, a különböző adatbázisok sebessége és a többi rendszerspecifikus jellemző a program logikájától független változó. Lehetséges, hogy alkalmazásunk szerkezete olyan, hogy gyorsabban fut az egyik rendszeren, míg a másikon elviselhetetlen lassú. Ezt egy ilyen modul bevezetésével, beiktatásával kényelmesen ki is próbálhatjuk a gyakorlatban, hiszen lehetőségünk nyílik, hogy néhány sor hozzátoldásával (a beállítási fájlok módosításával) tíz perc múlva egy új adatbázisrendszer környezetében futtathatjuk az adatbázisunkat.
Összefoglaló
Ez a rövid poszt most csak arra törekedett, hogy felhívja a figyelmünket a lehetőségre. Felkeltse az érdeklődésünket az ORM-ek iránt. Egy későbbiekre tervezett folytatásban egy konkrétan megvalósított példával fogom folytatni, ahol egy példán keresztül be is mutatom, hogy milyen szabadságot jelenthet a számunkra, ha az adatbázisunk megépítése során egy ilyen rendszert használunk.
Nincsenek megjegyzések:
Megjegyzés küldése