ORM ( în engleză Object-Relational Mapping , rusă object-relational mapping , sau transformare) este o tehnologie de programare care conectează bazele de date cu conceptele limbajelor de programare orientate pe obiecte , creând o „ bază de date de obiecte virtuale ”. Există atât implementări proprietare , cât și gratuite ale acestei tehnologii.
Este necesar să se lucreze cu date în termeni de clase, nu tabele de date și, dimpotrivă, să se transforme termenii și datele claselor în date adecvate pentru stocarea în SGBD. De asemenea, este necesar să se furnizeze o interfață pentru operațiunile de date CRUD . În general, trebuie să scapi de necesitatea de a scrie cod SQL pentru interacțiunea în SGBD [1] .
Soluția la problema stocării datelor există - acestea sunt sisteme de gestionare a bazelor de date relaționale . Folosirea unei baze de date relaționale pentru a stoca date orientate pe obiect duce la un decalaj semantic , forțând programatorii să scrie software care trebuie să fie capabil să proceseze datele într-un mod orientat pe obiecte, dar să stocheze acele date într-o formă relațională. Această nevoie constantă de conversie între două forme diferite de date nu numai că reduce foarte mult performanța, dar creează și dificultăți pentru programatori, deoarece ambele forme de date impun restricții reciproce.
Bazele de date relaționale folosesc un set de tabele care reprezintă date simple. Informațiile suplimentare sau conexe sunt stocate în alte tabele. Adesea, mai multe tabele sunt folosite pentru a stoca un singur obiect într-o bază de date relațională; aceasta, la rândul său, necesită o operație JOIN pentru a obține toate informațiile legate de obiect în vederea procesării acestuia. De exemplu, pentru a stoca datele din blocnotes, cel mai probabil vor exista cel puțin două tabele: persoane și adrese și poate chiar un tabel cu numere de telefon.
Deoarece sistemele de gestionare a bazelor de date relaționale de obicei nu implementează o reprezentare relațională a stratului fizic de relații, rularea mai multor interogări consecutive (referitoare la aceeași structură de date „orientată pe obiecte”) poate fi prohibitiv de costisitoare. În special, o singură interogare precum „găsiți un astfel de utilizator și toate telefoanele și toate adresele lui și returnați-le în acest format” este probabil mai rapidă decât o serie de interogări precum „Găsiți utilizator. Găsiți-i adresa. Găsește-i telefoanele. Acest lucru se datorează muncii optimizatorului și costului de analiză a interogării.
Unele implementări ORM sincronizează automat obiectele din memorie cu baza de date. Pentru a face acest lucru posibil, după crearea unei interogări SQL de transformare obiect în SQL (clasa care implementează comunicarea cu DB), datele primite sunt copiate în câmpurile obiectului, ca în toate celelalte implementări ORM. După aceea, obiectul trebuie să urmărească modificările acestor valori și să le scrie în baza de date.
Sistemele de management al bazelor de date relaționale prezintă performanțe bune la interogările globale care afectează o zonă mare a bazei de date, dar accesul orientat pe obiect este mai eficient atunci când se lucrează cu cantități mici de date, deoarece reduce decalajul semantic dintre obiect și formele relaționale ale bazei de date. date.
Odată cu existența simultană a acestor două lumi diferite, complexitatea codului obiect pentru lucrul cu baze de date relaționale crește și devine mai predispus la erori. Dezvoltatorii de software de baze de date au căutat o modalitate mai ușoară de a obține persistența obiectelor lor.
Multe pachete au fost dezvoltate pentru a elimina necesitatea de a converti obiecte pentru stocare în baze de date relaționale.
Unele pachete rezolvă această problemă oferind biblioteci de clase care pot face aceste conversii automat. Având o listă de tabele în baza de date și obiecte în program, acestea convertesc automat interogările de la un tip la altul. Ca urmare a interogării obiectului „persoană” (din exemplul agendei de adrese), interogarea SQL necesară va fi generată și executată, iar rezultatele vor fi convertite „magic” în obiecte „număr de telefon” în cadrul programului.
Din punctul de vedere al unui programator, sistemul ar trebui să arate ca un depozit persistent de obiecte. El poate pur și simplu să creeze obiecte și să lucreze cu ele ca de obicei, iar acestea vor fi stocate automat într-o bază de date relațională.
În practică, totul nu este atât de simplu și evident. Toate sistemele ORM tind să se manifeste într-un fel sau altul, reducând posibilitatea de a ignora baza de date într-un fel. Mai mult, stratul de tranzacție poate fi lent și ineficient (mai ales în ceea ce privește SQL-ul generat). Toate acestea pot face ca programele să ruleze mai lent și să utilizeze mai multă memorie decât programele scrise de mână.
Dar ORM salvează programatorul de la scrierea unei cantități mari de cod, adesea repetitiv și predispus la erori, crescând astfel semnificativ viteza de dezvoltare. În plus, majoritatea implementărilor ORM moderne permit programatorului, dacă este necesar, să codifice hard interogările SQL care vor fi folosite pentru anumite acțiuni (salvare în baza de date, încărcare, căutare etc.) cu un obiect persistent.