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

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

Термин объектно-относительное рассогласование импеданса происходит от электротехнического термина « согласование импеданса» .

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

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

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

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

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

Доступность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минимизация

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

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

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

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

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

Компенсация

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

Разногласия

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

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

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

Утверждалось, что SQL из-за очень ограниченного набора типов доменов (и других предполагаемых недостатков) затрудняет правильное моделирование объектов и доменов; и что SQL представляет собой очень неэффективный и неэффективный интерфейс между СУБД и прикладной программой (независимо от того, написан ли он в объектно-ориентированном стиле или нет). Однако в настоящее время SQL является единственным широко распространенным языком баз данных на рынке; использование языков запросов, зависящих от поставщика, считается плохой практикой, когда ее можно избежать. Были предложены другие языки баз данных, такие как Business System 12 и Tutorial 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. (Некоторые сторонники реляционных отношений предлагают использовать триггеры, хранимые процедуры и т. Д. Для обеспечения сложного поведения, но это не обычная точка зрения.)
  • Привязка  к схеме - объекты не обязательно должны следовать «родительской схеме», для каких атрибутов или средств доступа имеет объект, в то время как строки таблицы должны следовать схеме объекта. Данная строка должна принадлежать одной и только одной сущности. Самая близкая вещь в объектно-ориентированном подходе - это наследование, но обычно оно имеет древовидную форму и необязательно. Системы динамических баз данных, которые позволяют создавать специальные столбцы, могут ослабить ограничения схемы, но такие системы либо в настоящее время редки, либо их классификация как «реляционные» находится под вопросом.
  • Правила доступа  - в реляционных базах данных доступ к атрибутам и их изменение осуществляется с помощью предопределенных реляционных операторов, в то время как объектно-ориентированный объект позволяет каждому классу создавать свой собственный интерфейс и методы изменения состояния. С точки зрения объектно-ориентированного подхода "самообрабатывающееся существительное" каждому объекту предоставляется независимость, которую реляционная модель не допускает. Это дебаты «стандарты против местной свободы». ОО имеет тенденцию утверждать, что реляционные стандарты ограничивают выразительность, в то время как сторонники реляционных отношений предполагают, что соблюдение правил допускает более абстрактные математические рассуждения, целостность и согласованность дизайна.
  • Связь между существительными и глаголами  - объектно-ориентированный подход поощряет тесную связь между глаголами (действиями) и существительными (сущностями), над которыми оперируют операции. Результирующая тесно связанная сущность, содержащая как существительные, так и глаголы, обычно называется классом или в объектно-ориентированном анализе - концептом . В реляционных проектах обычно не предполагается, что в таких тесных ассоциациях есть что-то естественное или логичное (кроме операторов отношения).
  • Идентичность объекта  - объекты (кроме неизменяемых) обычно считаются уникальными; два объекта, которые находятся в одном и том же состоянии в данный момент времени, не считаются идентичными. С другой стороны, отношения не имеют внутренней концепции такой идентичности. Тем не менее, это обычная практика - подделывать «идентичность» для записей в базе данных с помощью глобально уникальных ключей-кандидатов ; хотя многие считают это плохой практикой для любой записи базы данных, не имеющей однозначного соответствия с реальной сущностью. (Отношения, как и объекты, могут использовать доменные ключи, если они существуют во внешнем мире для целей идентификации). На практике реляционные системы стремятся к «постоянным» и проверяемым методам идентификации и поддерживают их, тогда как методы идентификации объектов имеют тенденцию быть временными или ситуативными.
  • Нормализация  - методы реляционной нормализации часто игнорируются объектно-ориентированными проектами. Однако это может быть просто дурной привычкой, а не встроенной функцией объектно-ориентированного программирования. Альтернативная точка зрения состоит в том, что набор объектов, связанных между собой указателями определенного типа, эквивалентен сетевой базе данных ; которую, в свою очередь, можно рассматривать как чрезвычайно денормализованную реляционную базу данных .
  • Наследование схемы.  Большинство реляционных баз данных не поддерживают наследование схемы. Хотя такая функция может быть добавлена ​​теоретически, чтобы уменьшить конфликт с ООП, сторонники реляционных отношений с меньшей вероятностью верят в полезность иерархических таксономий и подтипов, поскольку они склонны рассматривать основанные на множествах таксономии или системы классификации как более мощные и гибкие. чем деревья. Сторонники объектно-ориентированного программирования указывают на то, что модели наследования / подтипов не должны ограничиваться деревьями (хотя это ограничение во многих популярных объектно -ориентированных языках, таких как Java ), но OO-решения, не являющиеся деревьями, считаются более сложными для формулирования, чем вариации на основе наборов. тематические методы управления, предпочитаемые реляционными. По крайней мере, они отличаются от техник, обычно используемых в реляционной алгебре.
  • Структура против поведения  - объектно-ориентированный подход в первую очередь фокусируется на обеспечении разумной структуры программы (поддерживаемой, понятной, расширяемой, многократно используемой, безопасной), тогда как реляционные системы фокусируются на том, какое поведение имеет результирующая система времени выполнения (эффективность, адаптируемость , отказоустойчивость, живучесть, логическая целостность и др.). Объектно-ориентированные методы обычно предполагают, что основным пользователем объектно-ориентированного кода и его интерфейсов являются разработчики приложений. В реляционных системах взгляд конечных пользователей на поведение системы иногда считается более важным. Однако реляционные запросы и «представления» являются обычными методами для представления информации в конфигурациях для конкретных приложений или задач. Кроме того, реляционный подход не запрещает создание локальных или специфичных для приложения структур или таблиц, хотя многие распространенные инструменты разработки не предоставляют такую ​​возможность напрямую, предполагая, что вместо них будут использоваться объекты. Это затрудняет понимание того, является ли заявленная точка зрения не-разработчика реляционной присущей реляционной или просто продуктом текущей практики и предположений о реализации инструмента.
  •  Отношения между набором и графом - отношения между различными элементами (объектами или записями), как правило, обрабатываются по-разному в разных парадигмах. Отношения обычно основаны на идиомах, взятых из теории множеств , в то время как объектные отношения склоняются к идиомам, заимствованным из теории графов (включая деревья ). Хотя каждый из них может представлять ту же информацию, что и другой, подходы, которые они предоставляют для доступа к информации и управления ею, различаются.

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

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

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

использованная литература

внешние ссылки