Объектно-реляционный разрыв и несоответствие (сопротивление и импеданс)

Привет, Вы узнаете о том , что такое объектно-реляционный разрыв , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое объектно-реляционный разрыв , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.

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

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

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

(оbject-relational impedance mismatch).

Разрыв и несоответствие

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

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

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

Доступ

В реляционном мышлении, "частный" против "публичный" доступ является относительной, а не абсолютной характеристикой состояния данных, как в объектно-ориентированной модели. Реляционные и OO модели часто имеют конфликты относительности против абсолютизма классификаций и характеристик.

Подражания и полиморфизм

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

Отражение в реляционную концепцию

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

Видминости в типах данных

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

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

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

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

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

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

Доступность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3 - Наша концептуальная структура несоответствия импеданса, включающая стратегии ORM

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

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

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

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

Минимизация

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

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

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

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

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

Компенсация

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

Подходы к объединению объектных и реляционных БД

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

.

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

Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами выполнять роль мощного объектно-реляционного адаптера, позволяя объектно-ориентированным приложениям обращаться к реляционным БД.

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

Объектно-реляционные шлюзы. При использовании такого метода пользователь взаимодействует с БД при помощи языка OODBMS, а шлюз заменяет все объектно-ориентированные элементы этого языка на их реляционные компоненты. За это опять приходиться расплачиваться производительностью. Например, шлюз должен преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы (original identifier – OID) объектов и передать это в реляционную БД. Затем шлюз должен каждый раз, когда используется интерфейс реляционной СУБД, преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный в RDBMS.

Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая RDBMS состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к RDBMS при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД. Еще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8, выпуск которой намечен на конец 1996 г.

С другой стороны, производители объектных СУБД, такие как компания Object Design, сознают, что объектно-ориентированные базы данных в обозримом будущем не заменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержки реляционных и иерархических баз данных иди различного рода интерфейсы, характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмы Ontos, применяемый в сочетании с ее ООБД Ontos/DB. ^{[Источник 3]}

Преимущества ORD

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

Недостатки ORD

• Очевидным недостатком подхода с использованием ORDBMS являются сложность и связанные с ней повышенные расходы. Простота и ясность, присущая реляционной модели, утрачивается при использовании подобных типов расширения. Некоторые считают, что расширения RDBMS предназначены для незначительного количества приложений, причем в последних не может быть достигнута оптимальная производительность при использовании имеющейся реляционной технологии. И многие другие, вплоть до терминологии.
• Обширные возмодности можно так же отнести и к недостаткам так как некоторые возможности в значительной степени противоречит учению Эвгара Кодда, в котором обосновывалась целесообразность независимости базы данных от приложений. Независимость базы данных от приложений часто выглядит очень привлекательной идеей, но для ее применения разумно отказаться от многих расширений SQL.
• Еще одной проблемой, не связанной с возможностями серверной реализации логики приложений, является использование в базах данных типов коллекций. Поддержка в стандарте SQL типов мультимножеств, элементами которых могут быть значения анонимных строчных типов, обеспечивает теперь возможность определения вложенных таблиц с произвольным (теоретически, неограниченным) уровнем вложенности. Поскольку все значения, хранимые в базе данных, продолжают оставаться строго типизированными, такая возможность не противоречит базовому требованию первой нормальной формы, унаследованному из реляционной модели данных, но, по существу, обеспечивает подход к прямому моделированию иерархических структур.

Вау!! 😲 Ты еще не читал? Это зря!

• Объектно-реляционное отображение
• Объектно-реляционная база данных
• паттерны обработки объектно-реляционных метаданных , metadata mapping , query object repository ,
• структура базы данных , иерархическая структура базы данных , сетевая структура базы данных , реляционная структура базы данных ,
• паттерны , объектно-реляционного структурирования , identity field , foreign key ,
• orm , object-relational mapping , объектно-реляционное отображение , active record ,

Исследование, описанное в статье про объектно-реляционный разрыв , подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое объектно-реляционный разрыв и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.