Об'єктно-реляційне відображення — Вікіпедія

ORM (англ. Object-relational mapping, Об'єктно-реляційна проєкція) — технологія програмування, яка зв'язує бази даних з концепціями об'єктно-орієнтованих мов програмування, створюючи «віртуальну об'єктну базу даних».

В об'єктно-орієнтованому програмуванні об'єкти в програмі представляють об'єкти з реального світу. Як приклад можна навести адресну книгу, яка містить список людей разом з кількома телефонами і кількома адресами. В термінах об'єктно-орієнтованого програмування вони будуть представлені об'єктами класу «Людина», які міститимуть такі атрибути: ім'я, список (або масив) телефонів і список адрес.

Суть проблеми полягає в перетворенні таких об'єктів у форму, в якій вони можуть бути збережені у файлах або базах даних, і які легко можуть бути витягнуті в подальшому, зі збереженням властивостей об'єктів і відношень між ними. Ці об'єкти називають «постійними» (англ. persistent). Існує кілька підходів до розв'язання цієї задачі.

Вирішення проблеми зберігання даних існує — це реляційні системи управління базами даних. Використання реляційної бази даних для зберігання об'єктно-орієнтованих даних приводить до семантичного провалу, примушуючи програмістів писати програмне забезпечення, яке повинне вміти як обробляти дані в об'єктно-орієнтованому вигляді, так і вміти зберегти ці дані в реляційній формі. Ця постійна необхідність в перетворенні між двома різними формами даних не тільки сильно знижує продуктивність, але і створює труднощі для програмістів, оскільки обидві форми даних накладають обмеження одна на одну.

Реляційні бази даних використовують набір таблиць, що представляють прості дані. Додаткова або зв'язана інформація зберігається в інших таблицях. Часто для зберігання одного об'єкта в реляційній базі даних використовують кілька таблиць; це, у свою чергу, вимагає застосування операції JOIN для отримання всієї інформації, що стосується об'єкта, для її обробки. Наприклад, в розглянутому варіанті із записною книгою, для зберігання даних, швидше за все, використовуватимуться як мінімум дві таблиці: люди і адреси, і, можливо, навіть таблиця з телефонними номерами.

Оскільки системи управління реляційними базами даних зазвичай не реалізують реляційного представлення фізичного рівня зв'язків, виконання кількох послідовних запитів (що стосуються однієї «об'єктно-орієнтованої» структури даних) може бути дуже витратним. Зокрема, один запит вигляду «знайти такого-то користувача і всі його телефони і всі його адреси і повернути їх у такому форматі», швидше за все, буде виконаний швидше за серію запитів вигляду «Знайти користувача. Знайти його адреси. Знайти його телефони». Це відбувається завдяки роботі оптимізатора і витратам на синтаксичний аналіз запиту.

Деякі реалізації ORM автоматично синхронізують завантажені в пам'ять об'єкти з базою даних. Для того, щоб це було можливим, після створення SQL-запиту, що перетворює об'єкт в SQL, отримані дані копіюються в поля об'єкта, як у всіх інших реалізаціях ORM. Після цього об'єкт повинен стежити за змінами цих значень і записувати їх у базу даних.

Системи управління реляційними базами даних показують хорошу продуктивність на глобальних запитах, які зачіпають велику ділянку бази даних, але об'єктно-орієнтований доступ ефективніший при роботі з малими обсягами даних, бо це дозволяє скоротити семантичний провал між об'єктною і реляційною формами даних.

При одночасному існуванні цих двох різних світів збільшується складність об'єктного коду для роботи з реляційними базами даних, і він стає схильнішим до помилок. Розробники програмного забезпечення, що ґрунтується на базах даних, шукали легший спосіб досягнення постійності їхніх об'єктів.

Розроблено безліч пакетів, що знімають необхідність у перетворенні об'єктів для зберігання в реляційних базах даних.

Деякі пакети вирішують цю проблему, надаючи бібліотеки класів, здатних виконувати такі перетворення автоматично. Маючи список таблиць в базі даних і об'єктів в програмі, вони автоматично перетворять запити з одного вигляду в іншій. В результаті запиту об'єкта «людина» (з прикладу з адресною книгою) необхідний SQL-запит буде сформований і виконаний, а результати «магічним» чином перетворені в об'єкти «номер телефону» всередині програми.

З погляду програміста система повинна виглядати як постійне сховище об'єктів. Він може просто створювати об'єкти і працювати з ними як завжди, а вони автоматично зберігатимуться в реляційній базі даних.

На практиці все не так просто і очевидно. Всі системи ORM зазвичай проявляють себе в тому або іншому вигляді, зменшуючи в деякому роді можливість ігнорування бази даних. Більш того, шар транзакцій може бути повільним і неефективним (особливо в термінах згенерованого SQL). Все це може привести до того, що програми працюватимуть повільніше і використовуватимуть більше пам'яті, ніж програми, написані «вручну».

Але ORM позбавляє програміста від написання великої кількості коду, часто одноманітного і схильного до помилок, тим самим значно підвищуючи швидкість розробки. Крім того, більшість сучасних реалізацій ORM дозволяє програмістові при необхідності жорстко задати код SQL-запитів, який використовуватиметься при тих чи інших діях (збереження в базу даних, завантаження, пошук тощо) з постійним об'єктом.

Існують як комерційні, так і вільні реалізації цієї технології.

• Sequelize (JavaScript)
• JPA, Hibernate (Java)
• Syrius, Doctrine (PHP)
• SQLAlchemy (Python)
• Entity Framework (.NET Framework)
• Entity Framework Core (.NET Core)

• Список ORM-бібліотек

Ця стаття не містить посилань на джерела. Ви можете допомогти поліпшити цю статтю, додавши посилання на надійні (авторитетні) джерела. Матеріал без джерел може бути піддано сумніву та вилучено. (жовтень 2014)

Це незавершена стаття про інформаційні технології. Ви можете допомогти проєкту, виправивши або дописавши її.