Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Объектно-реляционное сопоставление ( инструмент сопоставления ORM , O / RM и O / R ) в информатике - это метод программирования для преобразования данных между несовместимыми системами типов с использованием объектно-ориентированных языков программирования. По сути, это создает « базу данных виртуальных объектов », которую можно использовать изнутри языка программирования. Доступны как бесплатные, так и коммерческие пакеты, которые выполняют объектно-реляционное сопоставление, хотя некоторые программисты предпочитают создавать свои собственные инструменты ORM.

В объектно-ориентированном программировании , управление данными задачи действуют на объектах , которые почти всегда не- скалярных значения. Например, рассмотрим запись в адресной книге, которая представляет одного человека с нулем или более телефонными номерами и нулем или более адресами. Это может быть смоделировано в объектно-ориентированной реализации с помощью « объекта Person » с атрибутом / полем.для хранения каждого элемента данных, который включает запись: имя человека, список телефонных номеров и список адресов. Список телефонных номеров сам будет содержать «объекты PhoneNumber» и так далее. Каждая такая запись адресной книги рассматривается языком программирования как отдельный объект (например, на нее может ссылаться одна переменная, содержащая указатель на объект). С объектом могут быть связаны различные методы , например методы для возврата предпочтительного номера телефона, домашнего адреса и т. Д.

Напротив, многие популярные продукты для баз данных, такие как системы управления базами данных SQL (СУБД), не являются объектно-ориентированными и могут хранить и управлять только скалярными значениями, такими как целые числа и строки, организованные в таблицах . Программист должен либо преобразовать значения объекта в группы более простых значений для хранения в базе данных (и преобразовать их обратно при извлечении), либо использовать только простые скалярные значения в программе. Объектно-реляционное отображение реализует первый подход. [1]

Суть проблемы заключается в переводе логического представления объектов в атомизированную форму, которая может храниться в базе данных с сохранением свойств объектов и их взаимосвязей, чтобы их можно было перезагружать как объекты при необходимости. Если эта функция хранения и поиска реализована, объекты считаются постоянными . [1]

Обзор [ править ]

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

Ниже приведен простой пример, написанный на коде C # , для выполнения запроса, написанного на SQL, с использованием механизма базы данных.

var  sql  =  "ВЫБЕРИТЕ идентификатор, имя, фамилию, телефон, дату рождения, пол, возраст ОТ лиц, ГДЕ id = 10" ; var  result  =  context . Лица . FromSqlRaw ( sql ). ToList (); var  name  =  result [ 0 ] [ "first_name" ];

Напротив, следующее использует API-интерфейс ORM-job, позволяющий писать код, который естественным образом использует функции языка.

var  person  =  репозиторий . GetPerson ( 10 ); var  firstName  =  person . GetFirstName ();

В приведенном выше случае используется объект, представляющий репозиторий хранилища и методы этого объекта. Другие фреймворки могут предоставлять код в виде статических методов, как показано ниже, а другие методы могут вообще не реализовывать объектно-ориентированную систему. Часто выбор парадигмы делается таким образом, чтобы ORM наилучшим образом соответствовал принципам проектирования окружающего языка.

var  person  =  Человек . Получить ( 10 );

Обычно платформа предоставляет некоторые функции фильтрации и запросов, позволяя получать доступ и изменять подмножества базы хранения. Приведенный ниже код запрашивает людей в базе данных, значение идентификатора которых равно «10».

var  person  =  Человек . Получить ( Person . Properties . Id  ==  10 );

Сравнение с традиционными методами доступа к данным [ править ]

По сравнению с традиционными методами обмена между объектно-ориентированным языком и реляционной базой данных ORM часто сокращает объем кода, который необходимо написать. [2]

Недостатки инструментов ORM обычно связаны с высоким уровнем абстракции, скрывающим то, что на самом деле происходит в коде реализации. Кроме того, сильная зависимость от программного обеспечения ORM была названа основным фактором создания плохо спроектированных баз данных. [3]

Объектно-ориентированные базы данных [ править ]

Другой подход заключается в использовании объектно-ориентированной системы управления базами данных (OODBMS) или документно-ориентированных баз данных, таких как собственные базы данных XML, которые обеспечивают большую гибкость в моделировании данных. OODBMS - это базы данных, разработанные специально для работы с объектно-ориентированными значениями. Использование OODBMS устраняет необходимость преобразования данных в форму SQL и обратно, поскольку данные хранятся в исходном объектном представлении, а отношения представляются напрямую, вместо того, чтобы требовать объединения таблиц / операций. Эквивалент ORM для документно-ориентированных баз данных называется преобразователем объект-документ (ODM).

Документно-ориентированные базы данных также не позволяют пользователю «разрезать» объекты на строки таблицы. Многие из этих систем также поддерживают язык запросов XQuery для извлечения наборов данных.

Объектно-ориентированные базы данных обычно используются в сложных, нишевых приложениях. Одним из аргументов против использования OODBMS является то, что она не может выполнять специальные, независимые от приложений запросы. [ необходима цитата ] По этой причине многие программисты чувствуют себя более комфортно с системой отображения объект-SQL, хотя большинство объектно-ориентированных баз данных способны обрабатывать SQL-запросы в ограниченной степени. Другие OODBMS обеспечивают репликацию в базы данных SQL как средство удовлетворения потребности в специальных запросах, сохраняя при этом хорошо известные шаблоны запросов. [ необходима цитата ]

Проблемы [ править ]

При рассмотрении того, как сопоставить объектную систему с реляционной базой данных, возникает множество трудностей. Эти трудности называются объектно-относительным рассогласованием импеданса . [4]

Альтернативой реализации ORM является использование родных процедурных языков, предоставляемых каждой крупной базой данных. Их можно вызывать из клиента с помощью операторов SQL. Доступ к данным объект шаблон проектирования (DAO) , используются для абстрактных этих заявлений и предлагает легкий объектно-ориентированный интерфейс к остальной части приложения. [5]

См. Также [ править ]

  • Список программ объектно-реляционного сопоставления
  • Сравнение программ объектно-реляционного картографирования
  • AutoFetch - автоматическая настройка запроса
  • Общая архитектура брокера объектных запросов (CORBA)
  • База данных объектов
  • Сохранение объекта
  • Объектно-реляционная база данных
  • Несоответствие объектно-реляционного импеданса
  • Реляционная модель
    • SQL (язык структурированных запросов)
  • Объекты данных Java
  • Объекты служебных данных
  • Entity Framework
  • Шаблон активной записи
  • Шаблон отображения данных
  • Наследование одной таблицы

Ссылки [ править ]

  1. ^ a b "Что такое объектно-реляционное сопоставление?" . Обзор гибернации . JBOSS Hibernate . Проверено 19 апреля 2011 года .
  2. ^ Дуглас Барри, Торстен Станиенда, "Решение проблемы хранилища объектов Java", Компьютер, т. 31, нет. 11, стр. 33-40, ноябрь 1998 г., http://www2.computer.org/portal/web/csdl/doi/10.1109/2.730734 , выдержка на http://www.service-architecture.com/object- реляционное отображение / статьи / transparent_persistence_vs_jdbc_call-level_interface.html . Строки кода, использующие O / R, - это лишь часть тех, которые необходимы для интерфейса уровня вызовов (1: 4). Для этого упражнения потребовалось 496 строк кода с использованием ODMG Java Binding по сравнению с 1923 строками кода с использованием JDBC.
  3. ^ Джош Беркус, «Wrecking Your Database», Компьютер, август 2009 г., http://it.toolbox.com/blogs/database-soup/wrecking-your-database-33298 , Интернет-конференция на https://www.youtube. com / watch? v = uFLRc6y_O3s
  4. ^ Пересмотр объектно-реляционного сопоставления - количественное исследование влияния технологии баз данных на стратегии сопоставления O / R. М. Лоренц, Дж. П. Рудольф, Г. Гессе, М. Юфлакер, Х. Платтнер. Гавайская международная конференция по системным наукам (HICSS), 4877-4886 (DOI: 10.24251 / hicss.2017.592)
  5. ^ Feuerstein, Стивен; Билл Прибыл (сентябрь 1997 г.). «Программирование Oracle PL / SQL» . 18.5 Изменение постоянных объектов . Проверено 23 августа 2011 года .CS1 maint: location ( ссылка )

Внешние ссылки [ править ]

  • О ОРМ по Хейлсберг
  • Отображение объектов в реляционные базы данных: подробное отображение O / R , Скотт У. Амблер.