ORM

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 7 juni 2021; kontroller kräver 7 redigeringar .

ORM ( engelsk  Object-Relational Mapping , rysk objektrelationell mappning eller transformation) är en programmeringsteknik som kopplar samman databaser med begreppen objektorienterade programmeringsspråk och skapar en "virtuell objektdatabas ". Det finns både proprietära och gratis implementeringar av denna teknik.

Utmana

Det är nödvändigt att arbeta med data i termer av klasser, inte tabeller med data, och tvärtom, att omvandla termer och data för klasser till data som är lämpliga för lagring i DBMS. Det är också nödvändigt att tillhandahålla ett gränssnitt för CRUD -dataoperationer . I allmänhet måste du bli av med behovet av att skriva SQL-kod för interaktion i DBMS [1] .

Relationellt DBMS

Lösningen på problemet med datalagring finns - dessa är relationsdatabashanteringssystem . Att använda en relationsdatabas för att lagra objektorienterad data leder till en semantisk lucka , vilket tvingar programmerare att skriva programvara som måste kunna bearbeta data på ett objektorienterat sätt, men lagra dessa data i en relationsform. Detta ständiga behov av att konvertera mellan två olika former av data minskar inte bara prestandan avsevärt, utan skapar också svårigheter för programmerare, eftersom båda formerna av data lägger restriktioner på varandra.

Relationsdatabaser använder en uppsättning tabeller som representerar enkla data. Ytterligare eller relaterad information lagras i andra tabeller. Ofta används flera tabeller för att lagra ett enda objekt i en relationsdatabas; detta kräver i sin tur en JOIN- operation för att få all information relaterad till objektet för att kunna bearbeta det. Till exempel, för att lagra anteckningsbokdata, kommer det troligen att finnas minst två tabeller: personer och adresser, och kanske till och med ett bord med telefonnummer.

Eftersom relationsdatabashanteringssystem vanligtvis inte implementerar en relationsrepresentation av det fysiska lagret av relationer, kan det vara oöverkomligt dyrt att köra flera på varandra följande frågor (med hänvisning till samma "objektorienterade" datastruktur). I synnerhet kommer en enskild fråga som "hitta en sådan och en sådan användare och alla hans telefoner och alla hans adresser och returnera dem i detta format" sannolikt att vara snabbare än en serie frågor som "Hitta användare. Hitta hans adress. Hitta hans telefoner. Detta beror på optimerarens arbete och kostnaden för att analysera frågan.

Vissa ORM-implementeringar synkroniserar automatiskt objekt i minnet med databasen. För att göra detta möjligt, efter att ha skapat en objekt-till-SQL-transformerande SQL-fråga (klassen som implementerar kommunikation med DB), kopieras mottagna data till objektets fält, som i alla andra ORM-implementationer. Därefter måste objektet titta efter ändringar av dessa värden och skriva dem till databasen.

Relationella databashanteringssystem visar bra prestanda på globala frågor som påverkar ett stort område av databasen, men objektorienterad åtkomst är effektivare när man arbetar med små mängder data, eftersom det minskar det semantiska gapet mellan objektet och relationsformer av data.

Med den samtidiga existensen av dessa två olika världar ökar komplexiteten i objektkoden för att arbeta med relationsdatabaser, och den blir mer benägen för fel. Utvecklare av databasprogramvara har letat efter ett enklare sätt att uppnå uthålligheten hos sina objekt.

Lösning

Många paket har utvecklats för att eliminera behovet av att konvertera objekt för lagring i relationsdatabaser.

Vissa paket löser detta problem genom att tillhandahålla klassbibliotek som kan göra dessa konverteringar automatiskt. Med en lista över tabeller i databasen och objekt i programmet konverterar de automatiskt frågor från en typ till en annan. Som ett resultat av att fråga efter "person"-objektet (från adressboksexemplet), kommer den nödvändiga SQL-frågan att genereras och exekveras, och resultaten kommer att "magiskt" konverteras till "telefonnummer"-objekt i programmet.

Ur en programmerares synvinkel bör systemet se ut som ett beständigt lager av objekt. Han kan helt enkelt skapa objekt och arbeta med dem som vanligt, och de kommer automatiskt att lagras i en relationsdatabas.

I praktiken är allt inte så enkelt och självklart. Alla ORM-system tenderar att visa sig själva på ett eller annat sätt, vilket minskar möjligheten att ignorera databasen på något sätt. Dessutom kan transaktionslagret vara långsamt och ineffektivt (särskilt när det gäller genererad SQL). Allt detta kan göra att program körs långsammare och använder mer minne än handskrivna program.

Men ORM räddar programmeraren från att skriva en stor mängd kod, ofta repetitiv och felbenägen, vilket avsevärt ökar utvecklingshastigheten. Dessutom tillåter de flesta moderna ORM-implementationer programmeraren att vid behov hårdkoda SQL-frågorna som kommer att användas för vissa åtgärder (spara till databasen, ladda, söka, etc.) med ett beständigt objekt.

ORM-implementeringar

Anteckningar

  1. Noble et al., 2011 .

Litteratur

Länkar