Введение
Набор концептуальных и технических трудностей
Несоответствие объектно-реляционных импедансов – это совокупность трудностей, возникающих при взаимодействии между данными в реляционных хранилищах и данными в объектных моделях, ориентированных на предметную область. Системы управления реляционными базами данных (RDBMS) являются стандартным способом хранения данных в выделенной базе данных, а объектно-ориентированное (ОО) программирование – предпочтительным методом бизнес-ориентированного проектирования в языках программирования. Проблема заключается не в самих реляционных базах данных или ОО-программировании, а в концептуальной сложности отображения между этими двумя логическими моделями. Обе логические модели могут быть реализованы различными способами с использованием серверов баз данных, языков программирования, шаблонов проектирования и других технологий. Проблемы возникают в масштабах от отдельных приложений до целых предприятий, когда хранящиеся реляционные данные используются в объектных моделях, ориентированных на предметную область, и наоборот. Объектно-ориентированные хранилища данных могут обменять эту проблему на другие сложности реализации. Термин "несоответствие импедансов" заимствован из области электротехники, где используется понятие согласования импедансов.
Несовпадения
ОО математически представляет собой ориентированные графы, где объекты ссылаются друг на друга. Реляционные данные – это кортежи в таблицах, оперируемые реляционной алгеброй. Кортежи – это поля данных, сгруппированные в "строку" с полями, имеющими определенный тип. Связи обратимы (INNER JOIN симметричен при прохождении по внешним ключам в обратном направлении), формируя неориентированные графы.
Инкапсулирование
Инкапсуляция объектов скрывает внутреннее устройство. Свойства объекта доступны только через реализованные интерфейсы. Однако многие ORM делают свойства общедоступными для работы со столбцами базы данных. ORM, использующие метапрограммирование, позволяют избежать нарушения инкапсуляции.
Доступность
Различие между "приватным" и "публичным" определяется потребностью в контексте отношений. В объектно-ориентированном программировании оно определяется исключительно классом. Эта относительность классификаций и характеристик противоречит их абсолютизму.
Интерфейс, класс, наследование и полиморфизм
Объекты должны реализовывать интерфейсы для предоставления доступа к внутренним компонентам. Реляционные системы используют представления для изменения перспектив и ограничений. В них отсутствуют объектно-ориентированные концепции, такие как классы, наследование и полиморфизм.
Картирование на реляционные понятия
Для корректной работы ORM таблицы, связанные отношениями внешнего ключа и первичного ключа, необходимо сопоставить с ассоциациями при объектно-ориентированном анализе.
Различия в типах данных
Реляционные системы запрещают использование ссылок (например, указателей), в то время как объектно-ориентированные системы поддерживают их. Различия в скалярных типах затрудняют сопоставление между ними. SQL поддерживает строки с максимальной длиной (что быстрее, чем без ограничений) и кодировки. В объектно-ориентированных системах кодировки используются только в процедурах сортировки, а длина строк ограничена только объемом памяти. SQL обычно игнорирует завершающие пробелы при сравнении символьных строк, но объектно-ориентированные библиотеки этого не делают. В объектно-ориентированных системах отсутствует механизм создания новых типов на основе примитивных с использованием ограничений.
Структурные и целостные различия
Объекты могут состоять из других объектов или специализироваться. Реляционная модель не предполагает вложенность, а отношение (кортежи с одинаковой схемой) не соответствует объектно-ориентированной парадигме. Реляционная модель использует декларативные ограничения на скалярные типы, атрибуты, переменные отношений и/или в глобальном масштабе. Объектно-ориентированная модель использует исключения для защиты внутренней структуры объектов.
Манипулятивные различия
Реляционная модель использует стандартизированные операторы для манипулирования данными, а объектно-ориентированная – императивный подход, специфичный для каждого класса и конкретного случая. Любая декларативная поддержка в объектно-ориентированном программировании ограничена списками и хеш-таблицами, в отличие от множеств, используемых в реляционной модели.
Различия по сделкам
Единицей в реляционной модели является транзакция, которая значительно превосходит любые методы классов объектно-ориентированного программирования. Транзакции включают в себя произвольные комбинации манипулирования данными, тогда как объектно-ориентированное программирование оперирует лишь отдельными присваиваниями значениям примитивных типов. Объектно-ориентированному программированию не свойственны изоляция и надёжность, поэтому атомарность и согласованность обеспечиваются только для примитивных типов данных.
Решение несоответствия импедансов
Решения начинаются с понимания различий между системами логики. Это минимизирует или компенсирует несовместимость.
Альтернативные архитектуры
NoSQL. Несоответствие не между ООП и СУБД. Проблема несовместимости объектно-реляционных моделей возникает исключительно между ООП и СУБД. Альтернативы, такие как NoSQL или XML-базы данных, позволяют избежать этой проблемы. Функциональное реляционное отображение. Функциональное программирование является популярной альтернативой объектно-ориентированному программированию. Конструкции включений в функциональных языках программирования изоморфны реляционным запросам. Некоторые функциональные языки программирования реализуют функциональное реляционное отображение. Прямое соответствие между конструкциями включений и запросами позволяет избежать многих проблем объектно-реляционного отображения.
Минимизация в ОО
Объектные базы данных (OODBMS) существуют для устранения несоответствия, но менее успешны, чем реляционные базы данных. Объектно-ориентированный подход – неудачная основа для схем. Будущие исследования объектно-ориентированных баз данных включают транзакционную память. Другое решение заключается в разделении логики предметной области и фреймворка. В этом случае объектно-ориентированное представление реляционных аспектов выполняется во время выполнения, а не статически. Фреймворки имеют класс кортежа (также называемый строкой или сущностью) и класс отношения (также известный как набор данных).
Компенсация
Смешивание уровней дискурса объектно-ориентированного программирования проблематично. В основном, поддержка фреймворка компенсирует это, автоматизируя манипулирование данными и шаблоны представления на уровне моделирования. Для этого используются рефлексия и генерация кода. Рефлексия рассматривает код как данные, позволяя автоматическую передачу данных, их представление и обеспечение целостности. Генерация кода преобразует схемы в классы и вспомогательные функции. Оба подхода имеют недостатки, связанные с разрывом между уровнями, когда сгенерированные классы содержат как свойства предметной области (например, Имя, Адрес, Телефон), так и свойства фреймворка (например, IsModified).
Возникновение
Хотя несоответствия между объектной и реляционной моделями могут возникать в объектно-ориентированном программировании в целом, особую сложность представляют объектно-реляционные отображатели (ORM). Поскольку ORM часто задаются посредством конфигурации, аннотаций и ограниченных предметно-ориентированных языков, им не хватает гибкости полноценного языка программирования для устранения этого несоответствия.
Настоящая модель СУБД
Кристофер Дж. Дейт утверждает, что настоящая реляционная СУБД решает эту проблему, поскольку домены и классы равнозначны. Отображение между реляционной и объектно-ориентированной моделями – ошибка. Реляционные кортежи устанавливают связи, а не представляют сущности. Роль объектно-ориентированного подхода сводится лишь к управлению полями.
Ограничения и незаконные сделки
Объекты домена и пользовательские интерфейсы имеют несовместимые характеристики. Эффективные пользовательские интерфейсы должны предотвращать недопустимые операции (нарушения ограничений базы данных), чтобы помочь операторам и другим пользователям, не являющимся программистами, управлять данными. Для этого требуется знание атрибутов базы данных, выходящее за рамки имени и типа, что приводит к дублированию логики в реляционных схемах. Фреймворки используют ограничения ссылочной целостности и другую информацию о схеме для стандартизации обработки, избегая написания кода для каждого отдельного случая.
Специфические для SQL импиденции и обходные пути
SQL, не имеющий типов доменов, затрудняет объектно-ориентированное моделирование. Он приводит к потере данных при обмене между СУБД и приложением (независимо от того, объектно-ориентированное оно или нет). Однако многие избегают NoSQL и альтернативных языков запросов, специфичных для конкретных поставщиков. СУБД также игнорируют Business System 12 и Tutorial D.
Популярные СУБД, такие как Oracle и Microsoft SQL Server, решают эту проблему. Объектно-ориентированный код (Java и .NET соответственно) расширяет их функциональность и может вызываться из SQL так же естественно, как если бы он был встроен в СУБД. Повторное использование библиотечных подпрограмм в различных схемах – это поддерживаемый современный подход. Объектно-ориентированное программирование вынесено в бэкенд, поскольку SQL никогда не получит современных библиотек и структур, необходимых сегодняшним программистам, несмотря на стремление комитета ISO SQL 99 добавить процедурные расширения. Разумнее использовать их напрямую, чем пытаться изменить SQL. Это размывает границы ответственности между "прикладным программированием" и "администрированием баз данных", поскольку реализация ограничений и триггеров теперь требует знаний как от администратора баз данных, так и от разработчика объектно-ориентированного кода. Однако этот вопрос может быть не столь актуальным. Реляционные СУБД не предназначены для моделирования. SQL теряет данные только при неправильном использовании для целей моделирования. SQL предназначен для запросов, сортировки, фильтрации и хранения больших объемов данных. Использование объектно-ориентированного подхода в бэкенде может привести к плохой архитектуре, поскольку бизнес-логика не должна находиться на уровне данных.
Местонахождение канонической копии данных
Реляционная модель утверждает, что СУБД является основным источником данных, а объекты объектно-ориентированной программы – временными копиями (которые могут устареть, если база данных изменяется параллельно). Объектно-ориентированная модель утверждает, что объекты являются основным источником данных, а СУБД используется лишь для хранения.
Разделение ответственности
Новые функции изменяют как код, так и схемы данных. Ответственность за схемы данных лежит на администраторах баз данных (DBA). DBA отвечают за надежность, поэтому отклоняют необоснованные изменения, вносимые программистами. Использование промежуточных баз данных помогает, но лишь переносит процесс утверждения на этап релиза. DBA предпочитают, чтобы изменения вносились в код, где последствия дефектов менее критичны. Большее взаимодействие между командами поможет решить эту проблему. Решения об изменении схемы данных должны приниматься исходя из бизнес-требований. Появление новых данных или необходимость повышения производительности также приводят к изменению схемы данных.