Лекция
Привет, Вы узнаете о том , что такое объектно-реляционный разрыв , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое объектно-реляционный разрыв , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.
объектно-реляционный разрыв представляет собой набор концептуальных и технических трудностей , которые часто встречаются, когда система управления реляционными базами данных ( СУБД ) используется в программе, написанной в объектно-ориентированном стиле, особенно, когда объекты или определения класса отражаются в таблице баз данных или реляционных схемах.
Объектно-реляционная рассогласование импедансов представляет собой набор концептуальных и технических трудностей, которые часто встречаются , когда реляционная система управления базами данных (СУБД) в настоящее время обслуживается (нескольких прикладных программ или) прикладных программ , написанных на объектно-ориентированном языке программирования или стиль , особенно потому, что объекты или определения классов должны отображаться в таблицы базы данных, определенные реляционной схемой.
Термин объектно-относительное рассогласование импеданса происходит от электротехнического термина согласование импеданса .
(оbject-relational impedance mismatch).
Объектно-ориентированные программы разработаны с учетом техники сокрытия представлення.В рамках объектно-ориентированного стиля соответствующие свойства данного объекта не должны быть представлены любым интерфейсом. Тем не менее, объектно-реляционное отображение обязательно выставляет основной контент объекта к взаимодействию с интерфейсом, реализация объекта указать не может. Итак, объектно-реляционное отображение нарушает инкапсуляцию объекта.
В реляционном мышлении, "частный" против "публичный" доступ является относительной, а не абсолютной характеристикой состояния данных, как в объектно-ориентированной модели. Реляционные и OO модели часто имеют конфликты относительности против абсолютизма классификаций и характеристик.
В объектно-ориентированной парадигмой, объекты имеют интерфейсы, которые вместе обеспечивают доступ только к внутренним частям объекта. Реляционная модель, с другой стороны, утилизирует, полученные изменения отношений, чтобы обеспечить различные перспективы и ограничения для обеспечения целостности. Точно так же важны концепции ООП для классов объектов, наследование и полиморфизм которых не поддерживаются реляционными базами данных.
Правильное отображение между реляционными и объектно-ориентированными концепциями может быть сделано, если таблицы реляционных баз данных связаны с ассоциациями, найденными в объектно-ориентированного анализе.
Важным несоответствием между существующими реляционными и ОО языках есть различия типов. Реляционная модель строго запрещает по ссылке атрибуты (или указатели), в то время как OO-языка ожидают переход по ссылке. Скалярные типы и их семантика оператора могут значительно отличаться между моделями, вызывая проблемы в отображении. Например, большинство систем SQL поддерживают строчные типы с различным типом сортировки и ограничениями максимальной длины (открытые текстовые типы, как правило, снижают производительность), в то время как большинство OO языка рассматривают сортировки только в качестве аргумента для процедуры сортировки и строки внутренним размером имеющейся памяти " памяти. Более тонкий, но соответствующий пример, системы SQL часто игнорируют конечные пробелы в лентах для сравнения, в то время как OO строку библиотеки нет, как правило.
Объекты (экземпляры) ссылаются друг на друга и, следовательно, образуют граф в математическом смысле (сеть, включающая петли и циклы). Реляционные схемы, напротив, являются табличными и основаны на реляционной алгебре , которая определяет связанные разнородные кортежи (группирование полей данных в «строку» с разными типами для каждого поля).
Объектно-ориентированные программы хорошо разработаны с использованием методов, которые позволяют создавать инкапсулированные объекты , внутреннее представление которых может быть скрыто. Ожидается, что в объектно-ориентированной структуре базовые свойства данного объекта не будут открыты для любого интерфейса, кроме интерфейса, реализованного вместе с объектом. Однако большинство объектно-реляционных отображений предоставляют базовое содержимое объекта для взаимодействия с интерфейсом, который реализация объекта не может указать. Следовательно, это объектно-реляционное сопоставление нарушает инкапсуляцию объекта, поскольку многие объектно-реляционные сопоставления автоматически генерируют общедоступные поля, соответствующие столбцам базы данных. Некоторые фреймворки вместо этого используют методы метапрограммирования, что позволяет избежать нарушения инкапсуляции.
В реляционном мышлении «частный» доступ по сравнению с «публичным» зависит от потребности. В объектно-ориентированной (ОО) модели это абсолютная характеристика состояния данных. В реляционных и объектно-ориентированных моделях часто возникают конфликты по поводу относительности и абсолютизма классификаций и характеристик.
В объектно-ориентированной парадигме объекты имеют интерфейсы, которые вместе обеспечивают единственный доступ к внутренним компонентам этого объекта. Реляционная модель, с другой стороны, использует производные переменные отношения ( представления ) для обеспечения различных точек зрения и ограничений для обеспечения целостности. Точно так же основные концепции ООП для классов объектов, наследования и полиморфизма не поддерживаются системами реляционных баз данных.
Правильное отображение между реляционными и объектно-ориентированными концепциями может быть сделано , если реляционные таблицы баз данных связаны между собой для объединения найдено в объектно-ориентированном анализе .
Основное несоответствие между существующими реляционными и объектно-ориентированными языками - это различия в системе типов . Реляционная модель строго запрещает использование атрибутов (или указателей ) по ссылке , тогда как объектно-ориентированные языки принимают и ожидают поведения по ссылке. Скалярные типы и их семантика операторов могут сильно различаться в разных моделях, что вызывает проблемы при отображении.
Например, большинство систем SQL поддерживают типы строк с различными сопоставлениями и ограниченными максимальной длиной (типы текста с открытым концом, как правило, снижают производительность), в то время как большинство языков объектно-ориентированного программирования рассматривают сопоставление только как аргумент для процедур сортировки, а размер строк по своей сути соответствует доступной памяти. Более тонкий, но связанный пример: системы SQL часто игнорируют конечные пробелы в строке для целей сравнения, тогда как библиотеки строк OO этого не делают. Как правило, невозможно создать новые типы данных из-за ограничения возможных значений других примитивных типов в объектно-ориентированном языке.
Еще одно несоответствие связано с различиями в структурных аспектах и аспектах целостности контрастирующих моделей. В объектно-ориентированных языках объекты могут состоять из других объектов - часто в высокой степени - или зависеть от более общего определения. Это может сделать сопоставление с реляционными схемами менее простым. Это связано с тем, что реляционные данные обычно представлены в именованном наборе глобальных, не вложенных переменных отношения. Сами отношения, представляющие собой наборы кортежей, все соответствующие одному заголовку (см. Реляционное исчисление кортежей) не имеют идеального аналога в объектно-ориентированных языках. Ограничения в объектно-ориентированных языках обычно не объявляются как таковые, но проявляются как логика защиты от возникновения исключения, окружающая код, который работает с инкапсулированными внутренними данными. С другой стороны, реляционная модель требует декларативных ограничений для скалярных типов, атрибутов, переменных отношений и базы данных в целом.
Однако семантические различия особенно очевидны в манипулятивных аспектах контрастирующих моделей. Реляционная модель имеет внутренний, относительно небольшой и четко определенный набор примитивных операторов для использования в запросах и манипулировании данными, тогда как языки объектно-ориентированного программирования обычно обрабатывают запросы и манипуляции с помощью настраиваемого или низкоуровневого, регистрового и физического доступа императивные операции, зависящие от пути . Некоторые объектно-ориентированные языки поддерживают декларативные подъязыки запросов , но поскольку объектно-ориентированные языки обычно имеют дело со списками и, возможно, хэш-таблицами , манипулятивные примитивы обязательно отличаются от основанных на наборах операций реляционной модели.
Аспекты параллелизма и транзакции также существенно различаются. В частности, транзакции , наименьшая единица работы, выполняемая базами данных, в реляционных базах данных намного больше, чем любые операции, выполняемые классами в объектно-ориентированных языках. Транзакции в реляционных базах данных представляют собой динамически ограниченные наборы произвольных манипуляций с данными, тогда как степень детализации транзакций в объектно-ориентированном языке обычно находится на уровне индивидуальных назначений полям с примитивными типами. В целом, объектно-ориентированные языки не имеют аналогов изоляции или устойчивости, поэтому атомарность и согласованность гарантируются только при записи в поля этих примитивных типов.
Рисунок 3 - Наша концептуальная структура несоответствия импеданса, включающая стратегии ORM
| уровень | рассогласование импеданса |
| Парадигма | Проблемы, связанные с несовместимостью между два разных взгляда на концепцию из вселенной дискурса: один как сеть взаимодействующих объекты; а другой - как набор отношений. |
| Язык | Проблемы, связанные с несовместимостью данных структуры между объектными и реляционными языков. Ламмель называет это каноническое отображение. В этой статье мы будем использовать шаблон термина в контексте Келлера , как набросайте описание решения. |
| Схема | Вопросы, связанные с обслуживанием двух репрезентации определенной концепции, описанной на разных языках. |
| Instance | Вопросы, связанные с хранением и поиском объект в контексте объектно-реляционного заявление. |
Работа над проблемой несоответствия импеданса для объектно-ориентированных программ начинается с распознавания различий в конкретных используемых логических системах. Об этом говорит сайт 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 часа в сутки многие администраторы баз данных неохотно вносят изменения в схемы баз данных, которые они считают ненужными или излишними, а в некоторых случаях и вовсе отказываются это делать. В некоторой степени может помочь использование баз данных для разработки (помимо производственных систем); но когда новое разработанное приложение «запустится», администратор баз данных должен будет утвердить любые изменения. Некоторые программисты считают это непримиримым;
Однако в организациях с нефункциональными отношениями между администраторами баз данных и разработчиками вышеупомянутая проблема не должна возникать, поскольку решение об изменении схемы базы данных или нет будет зависеть только от бизнес-потребностей: нового требования для сохранения дополнительных данных или Например, повышение производительности критически важного приложения вызовет изменение схемы.
Ключевые философские различия между объектно-ориентированной и реляционной моделями можно резюмировать следующим образом:
В результате несоответствия между объектно-реляционными импедансами сторонники обеих сторон дискуссии часто утверждают, что от других технологий следует отказаться или уменьшить их масштабы. Некоторые сторонники баз данных считают традиционные «процедурные» языки более совместимыми с СУБД, чем многие объектно-ориентированные языки; или предложить использовать менее объектно-ориентированный стиль. (В частности, утверждается, что долгоживущие объекты домена в коде приложения не должны существовать; любые такие объекты, которые действительно существуют, должны создаваться при выполнении запроса и удаляться после завершения транзакции или задачи). И наоборот, некоторые сторонники объектно- ориентированного подхода утверждают, что более дружественные к объектно- ориентированным объектам механизмы персистентности, такие как 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]
Исследование, описанное в статье про объектно-реляционный разрыв , подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое объектно-реляционный разрыв и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL