Несоответствие объектно-реляционного импеданса - Object–relational impedance mismatch

В объектно-относительное рассогласование импеданса представляет собой набор концептуальных и технических трудностей, которые часто встречаются, когда система управления реляционной базой данных (RDBMS) обслуживается прикладной программой (или несколькими прикладными программами), написанной на объектно-ориентированный язык программирования или стиль, особенно потому, что объекты или определения классов должны быть нанесенный на карту в таблицы базы данных, определенные реляционной схемой.

Период, термин объектно-относительное рассогласование импеданса происходит из электротехника срок согласование импеданса.

Несоответствия

Объекты (экземпляры) ссылаются друг на друга и поэтому образуют график в математическом смысле (сеть, включающая петли и циклы). Реляционные схемы, напротив, являются табличными и основаны на реляционная алгебра, который определяет связанные разнородные кортежи (группирование полей данных в «строку» с разными типами для каждого поля).

Объектно-ориентированные концепции

Инкапсуляция

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

Доступность

В реляционном мышлении «частный» доступ по сравнению с «публичным» зависит от потребности. В объектно-ориентированной (ОО) модели это абсолютная характеристика состояния данных. У реляционных и объектно-ориентированных моделей часто возникают конфликты по поводу относительности и абсолютизма классификаций и характеристик.

Интерфейс, класс, наследование и полиморфизм

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

Сопоставление с реляционными концепциями

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

Различия в типах данных

Основное несоответствие между существующими реляционными и объектно-ориентированными языками - это система типов различия. Реляционная модель строго запрещает ссылочные атрибуты (или указатели ), тогда как объектно-ориентированные языки принимают и ожидают поведения по ссылке. Скалярные типы и их оператор семантика могут сильно различаться между моделями, вызывая проблемы при отображении.

Например, большинство SQL системная поддержка нить типы с различными сопоставления и ограниченная максимальная длина (открытые типы текста, как правило, снижают производительность), в то время как большинство объектно-ориентированных языков рассматривают сопоставление только как аргумент для процедуры сортировки Размер строк по сути соответствует доступной памяти. Более тонкий, но связанный пример: системы SQL часто игнорируют завершающие белое пространство в строке для целей сравнения, тогда как строковые библиотеки OO этого не делают. Как правило, невозможно создать новые типы данных из-за ограничения возможных значений других примитивных типов в объектно-ориентированном языке.

Структурные различия и различия в целостности

Другое несоответствие связано с различиями в структурных аспектах и ​​аспектах целостности сравниваемых моделей. В объектно-ориентированных языках объекты могут состоять из других объектов - часто в высокой степени - или зависеть от более общего определения. Это может сделать сопоставление с реляционными схемами менее простым. Это связано с тем, что реляционные данные обычно представляются в именованном наборе глобальных, не вложенных переменных отношения. Сами отношения, будучи наборами кортежи все соответствуют одному заголовку (см. кортежное реляционное исчисление ) не имеют идеального аналога в объектно-ориентированных языках. Ограничения в объектно-ориентированных языках обычно не объявляются как таковые, но проявляются как логика защиты, вызывающая исключение, окружающая код, который работает с инкапсулированными внутренними данными. С другой стороны, реляционная модель требует декларативный ограничения на скалярные типы, атрибуты, переменные отношения и базу данных в целом.

Манипулятивные различия

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

Транзакционные различия

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

Устранение несоответствия импеданса

Работа над проблемой несоответствия импеданса для объектно-ориентированных программ начинается с распознавания различий в конкретных используемых логических системах. Затем несоответствие либо минимизируется, либо компенсируется.[1]

Альтернативные архитектуры

Проблема несоответствия объектно-реляционного импеданса не является универсальной проблемой между объектно-ориентированными объектами и базами данных. Как следует из названия, эта проблема импеданса возникает только с реляционные базы данных. Наиболее распространенное решение этой проблемы - использование альтернативной базы данных, например NoSQL или База данных XML.

Минимизация

Были попытки построить объектно-ориентированные системы управления базами данных (OODBMS), что позволит избежать проблемы несоответствия импеданса. Однако на практике они оказались менее успешными, чем реляционные базы данных, отчасти из-за ограничений объектно-ориентированных принципов в качестве основы для модели данных.[2] Были проведены исследования по расширению возможностей объектно-ориентированных языков, подобных базам данных, с помощью таких понятий, как транзакционная память.

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

  • Простые способы создания фреймворков и автоматизации для транспортировки, представления и проверки данных предметной области.
  • Меньший размер кода; более быстрое время компиляции и загрузки.
  • Способность к схема меняться динамически.
  • Избегает проблем с пространством имен и семантическим несоответствием.
  • Выразительная проверка ограничений
  • Нет необходимости в сложном картировании

К недостаткам можно отнести:

  • Отсутствие проверок «безопасности» статического типа. Типизированные средства доступа иногда используются как один из способов смягчить это.
  • Возможные эксплуатационные расходы на создание и доступ во время выполнения.
  • Неспособность изначально использовать уникальные объектно-ориентированные аспекты, такие как полиморфизм.

Компенсация

Смешивание уровни дискурса внутри объектно-ориентированного кода приложения возникают проблемы, но для их компенсации используются некоторые общие механизмы. Самая большая проблема заключается в обеспечении поддержки фреймворка, автоматизации манипулирования данными и шаблонов представления на уровне дискурса, в котором моделируются данные предметной области. Чтобы решить эту проблему, отражение и / или генерация кода используются. Отражение позволяет обращаться к коду (классам) как к данным и, таким образом, обеспечивать автоматизацию транспортировки, представления, целостности и т. Д. Данных. Генерация решает проблему путем обращения к структурам сущностей в качестве входных данных для инструментов генерации кода или языков метапрограммирования, которые производят классы и поддерживающую инфраструктуру в массовом порядке. Обе эти схемы все еще могут быть подвержены определенным аномалиям, когда эти уровни дискурса сливаются. Например, сгенерированные классы сущностей обычно будут иметь свойства, которые соответствуют домену (например, имя, адрес), а также свойства, которые обеспечивают управление состоянием и другую инфраструктуру инфраструктуры (например, IsModified).

Спор

Это утверждалось Кристофер Дж. Дат и другие, что действительно реляционная СУБД не было бы такой проблемы,[3][4][5] так как домены и классы суть одно и то же. Собственное отображение между классами и реляционными схемами - фундаментальная ошибка дизайна. [6]; и что отдельные кортежи в таблице (отношении) базы данных следует рассматривать как устанавливающие отношения между объектами; не как представления самих сложных объектов. Однако этот взгляд имеет тенденцию уменьшать влияние и роль объектно-ориентированного программирования, используя его как нечто большее, чем систему управления типами полей.

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

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

Утверждалось, что SQL, из-за очень ограниченного набора типов предметной области (и других предполагаемых недостатков) затрудняет правильное моделирование объекта и предметной области; и что SQL представляет собой очень неэффективный интерфейс между СУБД и прикладной программой (независимо от того, написан ли он в объектно-ориентированном стиле или нет) с потерями. Однако в настоящее время SQL является единственным широко распространенным языком баз данных на рынке.[нужна цитата ]; использование языков запросов конкретных поставщиков считается плохой практикой, когда ее можно избежать. Другие языки баз данных, такие как Бизнес-система 12 и Учебник D Были предложены; но ни один из них не получил широкого распространения среди поставщиков СУБД.

В текущих версиях основных «объектно-реляционных» СУБД, таких как Oracle и Microsoft SQL Server, вышеуказанный момент может не иметь значения. С помощью этих механизмов функциональность данной базы данных может быть произвольно расширена с помощью хранимого кода (функций и процедур), написанного на современном объектно-ориентированном языке (Java для Oracle и язык Microsoft .NET для SQL Server), и эти функции могут быть вызваны в свою очередь, в операторах SQL прозрачным образом: то есть пользователь не знает и не заботится о том, что эти функции / процедуры изначально не были частью механизма базы данных. Полностью поддерживаются современные парадигмы разработки программного обеспечения: таким образом, можно создать набор библиотечных процедур, которые можно повторно использовать в нескольких схемах баз данных.

Эти поставщики решили поддержать интеграцию объектно-ориентированного языка в серверной части СУБД, потому что они осознали, что, несмотря на попытки комитета ISO SQL-99 добавить процедурные конструкции в SQL, SQL никогда не будет иметь богатый набор библиотек и структур данных, который современные прикладные программисты принимают как должное, и разумно использовать их как можно напрямую, вместо того, чтобы пытаться расширить базовый язык SQL. Следовательно, разница между «программированием приложений» и «администрированием баз данных» теперь размыта: для надежной реализации таких функций, как ограничения и триггеры, часто может потребоваться человек с двумя навыками программирования DBA / OO или партнерство между людьми, которые сочетают эти навыки . Этот факт также имеет отношение к вопросу о "разделении ответственности" ниже.

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

Здесь находится «каноническая» копия государства. Модель базы данных обычно предполагает, что система управления базами данных является единственным авторитетным государственным хранилищем информации о предприятии; любые копии такого состояния, хранящиеся в прикладной программе, являются всего лишь временными копиями (которые могут быть устаревшими, если основная запись базы данных была впоследствии изменена транзакцией). Многие объектно-ориентированные программисты предпочитают рассматривать представления самих объектов в памяти как канонические данные и рассматривать базу данных как резервное хранилище и механизм сохранения.

Еще одним предметом спора является правильное разделение ответственности между программистами приложений и администраторы баз данных (DBA). Часто бывает так, что необходимые изменения в коде приложения (для реализации запрошенной новой функции или функциональности) требуют соответствующих изменений в определении базы данных; в большинстве организаций за определение базы данных отвечает администратор баз данных. Из-за необходимости поддерживать производственную систему базы данных 24 часа в сутки многие администраторы баз данных неохотно вносят изменения в схемы базы данных, которые они считают ненужными или излишними, а в некоторых случаях и вовсе отказываются это делать. Использование баз данных для разработки (помимо производственных систем) может в некоторой степени помочь; но когда новое разработанное приложение «запустится», администратор баз данных должен будет утвердить любые изменения. Некоторые программисты считают это непримиримым; однако администратор баз данных часто несет ответственность, если какие-либо изменения в определении базы данных вызывают потерю обслуживания в производственной системе - в результате многие администраторы баз данных предпочитают содержать изменения дизайна в коде приложения, где дефекты дизайна с гораздо меньшей вероятностью будут иметь катастрофические последствия. .

Однако в организациях с нефункциональными отношениями между администраторами баз данных и разработчиками вышеупомянутая проблема не должна проявляться, поскольку решение об изменении схемы базы данных или нет будет зависеть только от бизнес-потребностей: нового требования для сохранения дополнительных данных или Например, повышение производительности критически важного приложения вызовет изменение схемы.

Философские различия

Ключевые философские различия между объектно-ориентированной и реляционной моделями можно резюмировать следующим образом:

  • Декларативные и императивные интерфейсы - Реляционное мышление имеет тенденцию использовать данные как интерфейсы, а не поведение как интерфейсы. Таким образом, он имеет декларативный уклон в философии дизайна в отличие от поведенческого уклона OO. (Некоторые сторонники реляционных отношений предлагают использовать триггеры, хранимые процедуры и т. Д. Для обеспечения сложного поведения, но это не обычная точка зрения.)
  • Привязка схемы - Объекты не обязаны следовать «родительской схеме», для которой атрибуты или средства доступа имеют объект, в то время как строки таблицы должны соответствовать схеме объекта. Данная строка должна принадлежать одной и только одной сущности. Самая близкая вещь в объектно-ориентированном подходе - это наследование, но обычно оно имеет древовидную форму и необязательно. Системы динамических баз данных, которые позволяют создавать специальные столбцы, могут ослабить ограничения схемы, но такие системы либо в настоящее время редки, либо их классификация как «реляционные» находится под вопросом.
  • Правила доступа - В реляционных базах данных доступ к атрибутам и их изменение осуществляется с помощью предопределенных реляционных операторов, в то время как объектно-ориентированный объект позволяет каждому классу создавать свой собственный интерфейс и методы изменения состояния. С точки зрения объектно-ориентированного подхода "самообрабатывающееся существительное" каждому объекту предоставляется независимость, которую реляционная модель не допускает. Это дебаты «стандарты против местной свободы». ОО имеет тенденцию утверждать, что реляционные стандарты ограничивают выразительность, в то время как сторонники реляционных отношений предполагают, что соблюдение правил допускает более абстрактные математические рассуждения, целостность и согласованность дизайна.
  • Отношения между существительными и глаголами - ОО поощряет тесную связь между глаголами (действиями) и существительными (сущностями), над которыми оперируют операции. Получающийся в результате плотно связанный объект, содержащий как существительные, так и глаголы, обычно называется класс, или в объектно-ориентированном анализе концепция. В реляционных проектах обычно не предполагается, что в таких тесных ассоциациях есть что-то естественное или логичное (кроме операторов отношения).
  • Идентичность объекта - Объекты (кроме неизменяемых) обычно считаются уникальными; два объекта, которые находятся в одном и том же состоянии в данный момент времени, не считаются идентичными. Отношения, с другой стороны, не имеют внутренней концепции такой идентичности. Тем не менее, это обычная практика - подделывать "идентичность" для записей в базе данных с помощью глобально уникальных ключи-кандидаты; хотя многие считают это плохой практикой для любой записи в базе данных, которая не имеет однозначного соответствия с реальной сущностью. (Реляционные, как и объекты, могут использовать ключи домена, если они существуют во внешнем мире для целей идентификации). На практике реляционные системы стремятся к «постоянным» и контролируемым методам идентификации и поддерживают их, тогда как методы идентификации объектов имеют тенденцию быть временными или ситуативными.
  • Нормализация – Реляционная нормализация ОО-проекты часто игнорируют практики. Однако это может быть просто дурной привычкой, а не встроенной функцией объектно-ориентированного программирования. Альтернативная точка зрения состоит в том, что набор объектов, связанных между собой указатели в каком-то смысле эквивалентен сетевая база данных; что, в свою очередь, можно рассматривать как крайне денормализованный реляционная база данных.
  • Наследование схемы - Большинство реляционных баз данных не поддерживают наследование схемы. Хотя такая функция может быть добавлена ​​теоретически, чтобы уменьшить конфликт с ООП, сторонники реляционных отношений с меньшей вероятностью верят в полезность иерархических таксономий и подтипов, потому что они склонны рассматривать на основе набора таксономии или системы классификации более мощные и гибкие, чем деревья. Сторонники объектно-ориентированного программирования отмечают, что модели наследования / подтипов не должны ограничиваться деревьями (хотя это ограничение во многих популярных объектно-ориентированных языках, таких как Ява ), но ОО-решения, не являющиеся древовидными, считаются более сложными для формулирования, чем основанные на наборах методы управления вариациями темы, предпочитаемые реляционными. По крайней мере, они отличаются от техник, обычно используемых в реляционной алгебре.
  • Структура против поведения - ОО в первую очередь фокусируется на обеспечении того, чтобы структура программы была разумной (поддерживаемой, понятной, расширяемой, многоразовой, безопасной), тогда как реляционные системы фокусируются на том, какое поведение имеет результирующая система времени выполнения (эффективность, адаптируемость, отказоустойчивость , живость, логическая целостность и др.). Объектно-ориентированные методы обычно предполагают, что основным пользователем объектно-ориентированного кода и его интерфейсов являются разработчики приложений. В реляционных системах мнение конечных пользователей о поведении системы иногда считается более важным. Однако реляционные запросы и «представления» являются обычными методами для представления информации в конфигурациях для конкретных приложений или задач. Кроме того, реляционный подход не запрещает создание локальных или специфичных для приложения структур или таблиц, хотя многие распространенные инструменты разработки не предоставляют такую ​​возможность напрямую, предполагая, что вместо них будут использоваться объекты. Это затрудняет понимание того, является ли заявленная точка зрения не-разработчика реляционной присущей реляционной или просто продуктом текущей практики и предположений о реализации инструмента.
  • Отношения набора и графика - Отношения между разными элементами (объектами или записями), как правило, обрабатываются по-разному в разных парадигмах. Отношения обычно основаны на идиомах, взятых из теория множеств, а объектные отношения склоняются к идиомам, заимствованным из теория графов (включая деревья ). Хотя каждый из них может представлять ту же информацию, что и другой, подходы, которые они предоставляют для доступа к информации и управления ею, различаются.

В результате несоответствия между объектно-реляционными импедансами сторонники обеих сторон дискуссии часто утверждают, что от других технологий следует отказаться или уменьшить их масштабы.[7] Некоторые сторонники баз данных считают, что традиционные «процедурные» языки более совместимы с СУБД, чем многие объектно-ориентированные языки; или предложить использовать менее объектно-ориентированный стиль. (В частности, утверждается, что долгоживущие объекты домена в коде приложения не должны существовать; любые такие объекты, которые действительно существуют, должны создаваться при выполнении запроса и удаляться после завершения транзакции или задачи). Напротив, некоторые сторонники объектно-ориентированного подхода утверждают, что более дружественные к объектно-ориентированным объектам механизмы сохранения, такие как OODBMS, должны быть разработаны и использованы, а реляционная технология должна быть прекращена. Многие (если не большинство) программистов и администраторов баз данных не придерживаются ни одной из этих точек зрения; и рассматривать несоответствие между объектно-реляционным импедансом как простой факт жизни, который информационные технологии приходится иметь дело.

Также утверждается, что отображение O / R приносит свои плоды в некоторых ситуациях, но, вероятно, оно перепродано: помимо недостатков оно имеет преимущества. Скептики отмечают, что перед его использованием стоит хорошенько подумать, поскольку в некоторых случаях он не принесет никакой пользы.[8]

Смотрите также

Рекомендации

  1. ^ Классификация объектно-реляционного несоответствия импеданса. Ирландия, Кристофер; Бауэрс, Дэвид; Ньютон, Майк и Во, Кевин (2009). Классификация объектно-реляционного несоответствия импеданса. В: Первая международная конференция по достижениям в базах данных, знаниях и приложениях данных (DBKDA), 1-6 марта 2009 г., Канкун, Мексика.
  2. ^ К. Дж. Дэйт, Написание реляционных баз данных
  3. ^ Дата, Кристофер «Крис» Дж; Паскаль, Фабиан (2012-08-12) [2005], «Тип против домена и класса», Разоблачение базы данных (Журнал World Wide Web), Google, получено 12 сентября 2012.
  4. ^ ——— (2006), «4. О понятии логического различия», Дата в базе данных: труды 2000–2006 гг., Голос эксперта в базе данных; Записи выбора реляционной базы данных, Соединенные Штаты Америки: Апресс, с. 39, ISBN  978-1-59059-746-0, Класс кажется неотличимым от типа в классическом понимании этого термина..
  5. ^ ——— (2004), «26. Объектные / реляционные базы данных», Введение в системы баз данных (8-е изд.), Пирсон Аддисон Уэсли, стр.859, ISBN  978-0-321-19784-9, ...Любая такая сближение должен твердо основываться на реляционной модели.
  6. ^ Дата, Кристофер «Крис» Дж.; Дарвен, Хью, «2. Объекты и отношения», Третий манифест, Первая большая ошибка
  7. ^ Ньюард, Тед (26.06.2006). «Вьетнам компьютерных наук». Возможна совместимость. Получено 2010-06-02.
  8. ^ Джонсон, Род (2002). Дизайн и разработка J2EE. Wrox Press. п.256.

внешняя ссылка