Интеграция языков программирования с базами данных: в чем состоит проблема?

Интеграция  языков программирования с базами данных: в чем состоит  проблема?

Вильям Кук (William R. Cook), Али Ибрагим (Ali H. Ibrahim)  
Перевод: Сергей Кузнецов  
Оригинал: Integrating Programming Languages & Databases: What's the Problem?

Предисловие переводчика

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

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

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

Аннотация

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

Обновлено 10/12/2005

1. Введение

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

Процедурные языки  и языки запросов баз данных основываются на разных семантике и стратегиях оптимизации. Эти различия неформально  называются «потерей соответствия» (impedance mismatch) [32]: между императивными программами и декларативными запросами; алгоритмами и структурами данных, с одной стороны, и отношениями и индексами, с другой стороны; потоками управления и транзакциями; пустыми указателями и неопределенными значениями в смысле отсутствия данных. Различаются также подходы к модульности и сокрытию информации. Поскольку базы данных и языки программирования могут выполнять много одинаковых задач, разработчикам приходится принимать архитектурные решения по поводу функциональной организации и разделения системы. Для распределенного исполнения также требуются эффективная структуризация и управление специализированными паттернами коммуникаций. В результате приложения, нуждающиеся в доступе к базам данных, трудно проектировать и разрабатывать. Языки программирования не облегчают эффективное использование баз данных, и для достижения хорошей производительности обычно требуется тщательная оптимизация, основанная на экспертных знаниях, что затрудняет сопровождение и развитие программ.

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

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

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

2. Родственные исследования

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

В 1987 г. Аткинсон и Бьюнман опубликовали статью [6], в которой анализировались ранние исследования в области интеграции языков программирования и баз данных; в своей статье они сосредотачиваются на создании четкой, единой программной модели персистентных данных, обеспечивающей каркас для дальнейших исследований. Дэвид Майер в [32] сформулировал ключевое требование для решений проблемы потери соответствия: «Какой бы ни была модель программирования баз данных, она должна допускать вынесение из программ сложных операций над большими объемами данных и их выполнение менеджером памяти, а не принуждать программистов к использованию интерфейса уровня записей». Блюм и Здоник в [12] выявили культурные и технические различия между языками программирования и базами данных, включая управление параллелизмом, триггеры, оптимизацию и масштабирование данных. Манифест систем объектно-ориентированных баз данных [4] не включал какие-либо требования к интерфейсу ООБД с языками программирования, и производительность не включалась в состав требований верхнего уровня. Десять лет спустя Кэри и Девитт предсказали кончину персистентных языков программирования и объектно-ориентированных баз данных, а также итоговый успех объектно-реляционных баз данных [14]. Они также идентифицировали в качестве одной из ключевых исследовательских проблем интеграцию баз данных и языков программирования, которую они назваликлиентской интеграцией. Аткинсон в [5] анализировал сложность экспериментальной проверки нового подхода к персистентности.

Йордан в [29] сравнивает персистентные среды для платформы Java. В [15] Йордан характеризует реализацию эталонного тестового набора OO7 как Java-программу, манипулирующую Java-объектами, расположенными в основной памяти. Затем этот тестовый набор используется в качестве стандарта для количественного и качественного сравнения. К сожалению, тестовый набор OO7 моделирует только единственного пользователя, так что не затрагивается важный аспект параллельности. Йордан также предполагает, что все данные могут поместиться в основной памяти. Наконец, тестовый набор OO7 не представляет наиболее распространенные операции в типичных транзакционных/корпоративных приложениях, поскольку фокусируется на обходе иерархических структур. OO7 создавался для тестирования той разновидности специализированных приложений, для которой разрабатывались объектно-ориентированные базы данных. Йордан приводит числовые показатели производительности, но не обобщает свой количественный анализ. В этом обзоре мы не приводим числовые показатели производительности. Вместо этого мы предполагаем, что языки программирования должны давать возможность доступа к оптимизациям базы данных, и приводим качественный анализ того, насколько эффективными они являются при обеспечении этого доступа.

3. Типизация

Сложности согласования типов между языками программирования и базами данных традиционно считаются ключевой причиной потери соответствия.

И в языках программирования, и в базах данных имеется поддержка  примитивных типов и структур данных. Хотя детали отображения разных представлений данных могут вызывать неприятные проблемы, на концептуальном уровне модели данных в языке программирования и в базе данных являются совместимыми. Это не является удивительным при имеющейся универсальности методов структуризации данных. Хотя данные и типы совместимы, имеются существенные проблемы при статической типизации запросов и составных программ.

class Employee {  class Department {

    String  name;      String name;

    float salary;       Set<Employee> employees;

    Department department;     Employee manager;

}    }

Рис. 1. Пример схемы базы данных, определяемой на основе классов

3.1 Отображение данных (T1)

Примитивные типы в языках программирования обычно не соответствуют типам в базе данных, и примитивные типы в разных базах  данных обычно различаются. Например, в SQL-92 не определяется абсолютная точность многих числовых типов. Операции также могут быть не согласованными; распространенным примером является сравнение интернациональных строк.

Методы отображения  классов в реляционные базы данных являются предметом расширенных исследований и разработок [1]. В общих словах, наиболее распространенный подход заключается в определении отображений между моделью «сущность-связь» (entity/relationship, ER-моделью) и объектно-ориентированной моделью классов. ER-модель обеспечивает логическое представление структуры реляционной базы данных. В ER-модели атрибуты представляют примитивные значения данных, такие как строки символов и целые числа. Они отображаются в члены экземпляра объекта в объектно-ориентированной модели. Связи ER-модели отображаются в ссылки между объектами. Многозначная связь является коллекцией ссылок. В ER-модели может быть также представлена подтипизация, имеющаяся в объектно-ориентированной модели. В некоторых случаях имеется несколько способов выполнения отображения, и результирующие проектные решения обычно основываются на производительности или других факторах.

Например, на рис. 1 определена простая модель служащих и отделов в виде двух Java-классов. В терминах баз данных поля department и employees представляют связь один-ко-многим между Departments и Employees.

Персистентность методов. При рассмотрении отображения между объектами и базами данных некоторые исследователи предлагают персистентно сохранять методы объекта, а не только состояние объекта [7]. Иногда предлагается разрешить даже персистентность потоков управления, элементов управления пользовательских интерфейсов и сетевых соединений [30]. Учитывая, что интеграция состояния и поведения является одной из ключевых концепций объектно-ориентированного программирования, можно утверждать, что персистентное отображение, в котором не сохраняются поведение/методы, нарушает базовые принципы объектно-ориентированного программирования. С другой стороны, разделение данных и поведения оказалось достаточно полезным при разработке и развитии приложений, требующих переработки большого объема данных. Этот вопрос остается без ответа, и в данном обзоре не предлагается какой-либо критерий для оценки полезности персистентности методов.

3.2 Интеграция null-значений (T2)

Поведение null-значений в SQL отличается от поведения null-значений в большинстве процедурных объектно-ориентированных языков. В SQL null представляет «неизвестное» значение, так что примитивные операции, такие как сложение или конъюнкция, возвращают null-значение, если хотя бы один их операнд является null-значением. Например, x == null всегда возвращает null, даже если x является null-значением. С другой стороны, в агрегатных функциях SQL, таких как sum, null-значения игнорируются. В объектно-ориентированных языках программирования обычно допускаются null-значения объектных ссылок, но для примитивных типов, таких как целые числа, null-значения невозможны. В реляционных соединениях null-значения также обрабатываются как «неизвестные» значения, но разыменование null-указателя в объектно-ориентированном языке обычно приводит к возникновению исключительной ситуации.