Az ORM ( angolul Object-Relational Mapping , orosz objektum-relációs leképezés vagy transzformáció) egy olyan programozási technológia, amely összekapcsolja az adatbázisokat az objektum-orientált programozási nyelvek fogalmaival , létrehozva egy "virtuális objektum adatbázist". Ennek a technológiának vannak szabadalmaztatott és ingyenes megvalósításai is.
Az adatokkal osztályok szerint kell dolgozni, nem adattáblázatokban, és éppen ellenkezőleg, az osztályok feltételeit és adatait DBMS-ben tárolható adatokká kell átalakítani. A CRUD adatműveletekhez interfészt is kell biztosítani . Általában meg kell szabadulnia attól, hogy SQL kódot kell írnia a DBMS-ben való interakcióhoz [1] .
Az adattárolás problémájára létezik megoldás – ezek a relációs adatbázis-kezelő rendszerek . A relációs adatbázis használata az objektumorientált adatok tárolására szemantikai hézaghoz vezet, ami arra kényszeríti a programozókat, hogy olyan szoftvereket írjanak , amelyeknek képesnek kell lenniük az adatok objektumorientált feldolgozására, de az adatokat relációs formában tárolják. Ez a két különböző adatforma közötti állandó konvertálási igény nemcsak nagymértékben csökkenti a teljesítményt, hanem nehézségeket is okoz a programozóknak, mivel mindkét adatforma megszorításokat szab egymásra.
A relációs adatbázisok egyszerű adatokat reprezentáló táblázatokat használnak. A további vagy kapcsolódó információkat más táblázatok tárolják. Gyakran több táblát használnak egyetlen objektum tárolására egy relációs adatbázisban; ehhez viszont egy JOIN műveletre van szükség , amely az objektumhoz kapcsolódó összes információt megkapja annak feldolgozása érdekében. Például a notebook adatok tárolására nagy valószínűséggel legalább két táblázat lesz: személyek és címek, és talán még egy táblázat is telefonszámokkal.
Mivel a relációs adatbázis-kezelő rendszerek jellemzően nem valósítják meg a kapcsolatok fizikai rétegének relációs reprezentációját, több egymást követő lekérdezés futtatása (ugyanaz az "objektum-orientált" adatszerkezetre hivatkozva) megfizethetetlenül költséges lehet. Egyetlen lekérdezés, mint például „keressen meg egy ilyen és olyan felhasználót, az összes telefonját és az összes címét, és adja vissza őket ebben a formátumban”, valószínűleg gyorsabb, mint az olyan lekérdezések sorozata, mint a „Felhasználó keresése. Keresse meg a címét. Keresse meg a telefonjait. Ez az optimalizáló munkájának és a lekérdezés elemzési költségének köszönhető.
Egyes ORM-megvalósítások automatikusan szinkronizálják a memóriában lévő objektumokat az adatbázissal. Ennek lehetővé tétele érdekében egy objektum-SQL-transzformáló SQL lekérdezés (az osztály, amely a DB-vel való kommunikációt megvalósító osztály) létrehozása után a kapott adatok az objektum mezőibe másolódnak, mint minden más ORM-megvalósításnál. Ezt követően az objektumnak figyelnie kell ezen értékek változásait, és be kell írnia azokat az adatbázisba.
A relációs adatbázis-kezelő rendszerek jó teljesítményt mutatnak az adatbázis nagy területét érintő globális lekérdezések esetén, de az objektumorientált hozzáférés hatékonyabb, ha kis mennyiségű adattal dolgozik, mivel csökkenti az objektum és a relációs formái közötti szemantikai rést. adat.
E két különböző világ egyidejű fennállásával a relációs adatbázisokkal való munkavégzés objektumkódjának összetettsége megnő, és hajlamosabbá válik a hibákra. Az adatbázisszoftver-fejlesztők egyszerűbb módot kerestek objektumaik tartósságának elérésére.
Számos csomagot fejlesztettek ki annak érdekében, hogy kiküszöböljék az objektumok átalakítását a relációs adatbázisokban való tároláshoz.
Egyes csomagok úgy oldják meg ezt a problémát, hogy olyan osztálykönyvtárakat biztosítanak, amelyek automatikusan végrehajtják ezeket az átalakításokat. Az adatbázisban található táblázatok és a programban lévő objektumok listája birtokában automatikusan konvertálják a lekérdezéseket egyik típusból a másikba. A "person" objektum lekérdezése eredményeként (a címjegyzék példájából) a szükséges SQL lekérdezés generálódik és lefut, és az eredmények "varázsütésre" a programon belül "telefonszám" objektumokká alakulnak.
A programozó szemszögéből a rendszernek úgy kell kinéznie, mint egy állandó objektumtár. Egyszerűen létrehozhat objektumokat, és a szokásos módon dolgozhat velük, és ezek automatikusan egy relációs adatbázisban kerülnek tárolásra.
A gyakorlatban nem minden olyan egyszerű és nyilvánvaló. Valamennyi ORM rendszer hajlamos arra, hogy ilyen vagy olyan módon mutassa be magát, ami csökkenti annak lehetőségét, hogy valamilyen módon figyelmen kívül hagyják az adatbázist. Ezenkívül a tranzakciós réteg lassú és nem hatékony (különösen a generált SQL tekintetében). Mindez azt eredményezheti, hogy a programok lassabban futnak, és több memóriát használnak, mint a kézzel írt programok.
Az ORM azonban megkíméli a programozót attól, hogy nagy mennyiségű, gyakran ismétlődő és hibára hajlamos kódot írjon, ezáltal jelentősen megnöveli a fejlesztés sebességét. Ezen túlmenően a legtöbb modern ORM implementáció lehetővé teszi a programozó számára, hogy egy perzisztens objektum segítségével keményen kódolja azokat az SQL lekérdezéseket, amelyeket bizonyos műveletekhez (adatbázisba mentés, betöltés, keresés stb.) fog használni.