ORM

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 7. června 2021; kontroly vyžadují 7 úprav .

ORM ( anglicky  Object-Relational Mapping , rusky objektově-relační mapování nebo transformace) je programovací technologie, která propojuje databáze s koncepty objektově orientovaných programovacích jazyků a vytváří „virtuální objektovou databázi“. Existují proprietární i bezplatné implementace této technologie.

Výzva

Je potřeba pracovat s daty z hlediska tříd, nikoli tabulek dat, a naopak termíny a data tříd transformovat na data vhodná pro uložení v DBMS. Je také nutné zajistit rozhraní pro datové operace CRUD . Obecně se musíte zbavit nutnosti psát SQL kód pro interakci v DBMS [1] .

Relační DBMS

Řešení problému ukládání dat existuje – jedná se o systémy pro správu relačních databází . Použití relační databáze k ukládání objektově orientovaných dat vede k sémantické mezeře , což nutí programátory psát software , který musí být schopen zpracovávat data objektově orientovaným způsobem, ale ukládat tato data v relační formě. Tato neustálá potřeba převádět mezi dvěma různými formami dat nejen výrazně snižuje výkon, ale také vytváří potíže pro programátory, protože obě formy dat na sebe ukládají omezení.

Relační databáze používají sadu tabulek, které představují jednoduchá data. Další nebo související informace jsou uloženy v jiných tabulkách. Často se k uložení jednoho objektu v relační databázi používá více tabulek; to zase vyžaduje operaci JOIN pro získání všech informací souvisejících s objektem, aby bylo možné jej zpracovat. Například pro ukládání dat notebooku budou s největší pravděpodobností existovat alespoň dvě tabulky: lidé a adresy a možná i tabulka s telefonními čísly.

Vzhledem k tomu, že systémy pro správu relačních databází obvykle neimplementují relační reprezentaci fyzické vrstvy vztahů, může být spouštění více po sobě jdoucích dotazů (odkazujících na stejnou „objektově orientovanou“ datovou strukturu) neúměrně nákladné. Zejména jeden dotaz jako „najít takového a takového uživatele a všechny jeho telefony a všechny jeho adresy a vrátit je v tomto formátu“ bude pravděpodobně rychlejší než série dotazů jako „Najít uživatele. Najděte jeho adresu. Najděte jeho telefony. Je to kvůli práci optimalizátoru a nákladům na analýzu dotazu.

Některé implementace ORM automaticky synchronizují objekty v paměti s databází. Aby to bylo možné, po vytvoření SQL dotazu transformujícího objekt na SQL (třída, která implementuje komunikaci s DB), se přijatá data zkopírují do polí objektu, stejně jako ve všech ostatních implementacích ORM. Poté musí objekt sledovat změny těchto hodnot a zapisovat je do databáze.

Systémy správy relačních databází vykazují dobrý výkon při globálních dotazech, které ovlivňují velkou oblast databáze, ale objektově orientovaný přístup je efektivnější při práci s malým množstvím dat, protože snižuje sémantickou mezeru mezi objektovými a relačními formami. data.

Se současnou existencí těchto dvou odlišných světů se zvyšuje složitost objektového kódu pro práci s relačními databázemi a stává se náchylnější k chybám. Vývojáři databázového softwaru hledali jednodušší způsob, jak dosáhnout stálosti svých objektů.

Řešení

Bylo vyvinuto mnoho balíčků, které eliminují potřebu převádět objekty pro ukládání v relačních databázích.

Některé balíčky řeší tento problém poskytováním knihoven tříd, které mohou tyto převody provádět automaticky. Mají-li seznam tabulek v databázi a objektů v programu, automaticky převádějí dotazy z jednoho typu na druhý. V důsledku dotazu na objekt "osoba" (z příkladu adresáře) bude vygenerován a proveden požadovaný SQL dotaz a výsledky budou "magicky" převedeny v rámci programu na objekty "telefonní číslo".

Z pohledu programátora by měl systém vypadat jako trvalé úložiště objektů. Může jednoduše vytvářet objekty a pracovat s nimi jako obvykle a automaticky se uloží do relační databáze.

V praxi není vše tak jednoduché a zřejmé. Všechny systémy ORM mají tendenci se tak či onak projevovat, čímž se snižuje možnost nějakým způsobem ignorovat databázi. Transakční vrstva může být navíc pomalá a neefektivní (zejména z hlediska generovaného SQL). To vše může způsobit, že programy běží pomaleji a využívají více paměti než ručně psané programy.

ORM ale ušetří programátorovi psaní velkého množství kódu, často se opakujícího a náchylného k chybám, čímž výrazně zvyšuje rychlost vývoje. Většina moderních ORM implementací navíc umožňuje programátorovi v případě potřeby napevno zakódovat SQL dotazy, které budou použity pro určité akce (ukládání do databáze, načítání, vyhledávání atd.) s perzistentním objektem.

Implementace ORM

Poznámky

  1. Noble et al., 2011 .

Literatura

Odkazy