Objektově relační mapování

Při modelování a vývoji aplikací je snaha co nejvěrněji zachytit realitu. Objekty reálného světa jsou v aplikaci reprezentovány jako entity. Zatímco je v relační databázi entita reprezentována jako řádek, resp. množina řádků v databázových tabulkách, tak v objektově orientovaném jazyce je entita zpravidla reprezentována jako instance nějaké třídy.

Tato rozdílná reprezentace entit vedla ke vzniku programovací techniky, označované jako ORM, která se stará o konverzi mezi relační databází a objekty, se kterými se pracuje v objektově orientovaném jazyce. Technika se tak snaží vývojáři dát unifikovaný přístup k libovolnému objektu, resp. entitě, se kterou v aplikaci pracujeme. Díky tomu je vývojář při práci s daty, které jsou v aplikaci reprezentovány právě pomocí objektů, do jisté míry odstíněn od nutnosti pracovat s SQL dotazy konkrétní relační databáze. Použití ORM usnadňuje zejména provádění běžných databázových operací jako je čtení, zápis, úprava a mazání dat. Zkráceně označované jako CRUD operace. Důležitou funkcí ORM je zajistit persistentní uchování dat, tedy aby data, která jsou v aplikaci uložena v operační paměti, zůstala nepoškozena po plánovaném či neplánovaném ukončení běhu aplikace.

ORM se dále stará o automatickou konverzi rozdílných datových typů mezi databázovým systémem a programovacím jazykem. Pokročilé techniky ORM také řeší například možnost využití objektové dědičnosti, kterou relační databáze nepodporují.

Nicméně hlavním cílem ORM je synchronizace mezi používanými objekty v aplikaci a jejich reprezentací v databázovém systému tak, aby byla zajištěna persistence dat. Vývojář potřebuje persistentně uchovávat objekty, ale nepotřebuje se starat, jak se tato persistence provede.

Řada implementací ORM se snaží v co největší míře odstínit vývojáře od nutnosti psaní SQL dotazů a pro selekci objektů z databáze používá raději objektový přístup. Takovýto postup však zpravidla umožňuje vyhledávat objekty jen podle databázového primárního klíče, což zpravidla nestačí. Proto některé implementace ORM využívají pro selekci objektů objektový dotazovací jazyk.

Jedna z výhod odstínění od práce s SQL může být i určitá nezávislost aplikace na konkrétním databázovém systému, resp. možnost zvolit databázový systém či jiné datové úložiště tak, aby vyhovovalo konkrétním podmínkám a požadavkům.

Nezávislost na konkrétním databázovém systému a skrývání SQL dotazů jsou však již jen příjemné důsledky použití ORM, není to ale primárním cílem.

Konverze mezi relační databází a modelovými objekty není bezproblémová, ale je spojena s řadou komplikací, souhrnně označovaných jako object-relational impedance mismatch . Tyto problémy, resp. jejich možné řešení jsou důvodem pro existenci návrhových vzorů pro ORM. Martin Fowler ve své publikaci[1] definoval návrhové vzory pro práci s ORM.

• Table Data Gateway
• Row Data Gateway
• Active Record
• Data Mapper

Dědičnost je jedna ze stěžejních vlastností objektově orientovaného programování. Pomocí dědičnosti lze vytvářet hierarchickou strukturu tříd a při správném návrhu zvýšit znovu-použitelnost kódu. Relační databáze však dědičnost (a tím pádem ani polymorfismus) nepodporují a proto je potřeba využít techniky, jak hierarchii tříd rozložit do databázových tabulek. V případě použití dědičnosti je typické, že podoba datového modelu závisí na vybraném návrhovém vzoru. Návrhové vzory pro dědičnost lze kombinovat se vzory Row Data Gateway, Active Record a Data Mapper. U vzorů Row Data Gateway a Active Record je nutné, aby entitní třída byla potomkem speciální třídy, která je součástí ORM knihovny. To může komplikovat návrh diagramu tříd. Proto je vhodné kombinovat vzory pro definování dědičnosti se vzorem Data Mapper, jehož implementace zpravidla nevyžaduje, aby entitní třída byla potomkem speciální třídy, která by byla součástí ORM knihovny.

• Single Table Inheritance
• Class Table Inheritance
• Concrete Table Inheritance

• Databáze
• SQL
• Objektově orientované programování
• Objektově orientovaná analýza a design