CC BY
22
DOI: 10.25702/KSC.2307-5252.2019.9.109-115 УДК 004.832
Ю.А. Олейник, А.А. Зуенко
Институт информатики и математического моделирования ФИЦ КНЦ РАН
АНАЛИЗ ВОЗМОЖНОСТЕЙ СОВМЕЩЕНИЯ ПАРАДИГМ ПРОГРАММИРОВАНИЯ В ОГРАНИЧЕНИЯХ И ОБЪЕКТНО-ОРИНТИРОВАННОГО ПРОГРАММИРОВАНИЯ*
Аннотация
В работе обосновывается принципиальная схожесть ограничений в задачах удовлетворения ограничений и отношений в реляционных базах данных. На основе этой схожести делается предположение о возможности переноса опыта интеграции объектного представления в реляционные базы данных на технологию программирования в ограничениях. Проводится обзор вариантов такой интеграции и анализ их применимости для решения задач удовлетворения ограничений. Ключевые слова:
программирование в ограничениях, объектно-ориентированная базы данных, объектно-реляционная базы данных, постреляционная базы данных.
Y.A. Oleynik, A.A. Zouenko
POSSIBILITY ANALYSIS OF CONSTRAINT AND OBJECT-ORIENTED PROGRAMMING PARADIGMS COMBINING
Abstract
The paper substantiates similarity of constraints in the constraint satisfaction problems and relationships in relational databases. Based on this similarity, an assumption is made about the possibility of transferring the experience of integrating the object representation into relational databases to the constraint programming technology. A review of variants for such integration and an analysis of their applicability for solving constraint satisfaction problems is carried out.
Keywords:
constraint programming, object databases, object-relational databases, postrelational databases. Введение
Программирование в ограничениях является довольно молодым направлением. Оно находит применение в решении комбинаторных задач, задач составления расписаний, распределения ресурсов и других направлениях, область которых продолжает расширяться. Задачи, описываемые и решаемые с помощью парадигмы программирования в ограничениях, называются задачами удовлетворения ограничений (Constraint Satisfaction Problem - CSP).
Ограничения можно также рассматривать, как отношения над множествами областей определения переменных задачи. Таким образом, решения задачи CSP — это такие значения переменных, которые делают все отношения истинными. При такой интерпретации становится очевидным родство CSP с реляционными базами данных (РБД), из которого вытекает ряд их общих недостатков.
* Работа выполнена в рамках темы НИР «Развитие методологии построения интеллектуальных мультипредметных систем информационной поддержки регионального развития на примере территорий Арктической зоны Российской Федерации (АЗРФ)» (№ 0226-2019-0036).
1. Парадигма программирования в ограничениях
В общем виде задача удовлетворения ограничений задается тремя множествами[1]: X - множество переменных задачи; В - множество областей определения переменных задачи; С - множество ограничений над переменными задачи. Под ограничением понимается любое соотношение между переменными предметной области. В качестве ограничений могут выступать арифметические выражения; логические формулы; таблицы; выражения, формулируемые на языке специализированных теорий.
Решением задачи CSP является полное присваивание, которое удовлетворяет всем ограничениям, и в некоторых случаях необходимо получить все решения. Иногда требуется найти такое решение, в котором значения переменных оптимизировали бы некоторый заданный функционал. CSP-задачи принадлежат классу ОТ--полных задач.
Технология программирования в ограничениях предоставляет мощные и гибкие методы, алгоритмы решения задач комбинаторного поиска. Особенности технологии:
• С точки зрения конечного пользователя задача CSP формулируется в декларативном виде, на языке близком к языку математики. Порядок задания ограничений несущественен.
• Любой алгоритм удовлетворения ограничений должен содержать две обязательных компоненты: а) компоненту, реализующую вывод (распространение); Ь) компоненту, реализующую поиск.
• Вывод (распространение) реализуется как целенаправленное сужение изначально заданных областей определения переменных.
• Эвристики, используемые в процедурах поиска, разрабатываются не под конкретную задачу, а являются универсальными.
• Благодаря архитектуре систем программирования в ограничениях, появляется возможность совместно обрабатывать количественные и качественные ограничения.
• Обеспечивается возможность сопровождать модели, отрытые для оперативных модификаций. При добавлении/удалении из модели ограничений нет необходимости писать новые методы решения задачи.
В С8Р условия задачи описываются декларативно, а алгоритмы поиска решений (распространение и ветвление) остаются скрыты от пользователя, аналогично в РБД декларативно описывается структура и наполнение базы данных, а алгоритмы поддержания согласованности и целостности данных скрыты в используемой СУБД. Очевидно, для реализации такого подхода, средства описания как РБД, так и С8Р должны быть типизированы, а сами типы переменных (данных) и отношений над ними должны быть достаточно примитивны для их успешной автоматической интерпретации и обработки. Так, достаточно популярная библиотека программирования в ограничениях СЬоео[2] позволяет создавать переменные всего 4 различных типов: целый, логический, вещественный и множество целых, причем поддержка вещественного типа до сих пор неполная.
Поскольку примитивность типов является существенным ограничением для описания баз со сложными данными и отношениями над ними, был предпринят ряд шагов для расширения функционала РБД, часть из которых будет
рассмотрено ниже. Эти подходы видятся вполне применимыми и для расширения функционала средств решения задач CSP.
2. Предпосылки интеграции объектного представления в реляционные базы данных
Для обеспечения полноценной интеграции с языками программирования разработчики современных СУБД все более стремятся перенести парадигмы объектно-ориентированного программирования на технологию БД [3]. Таким образом, можно условно выделить объектно-ориентированный подход к представлению баз данных.
Как правило, реляционные СУБД (РСУБД) не позволяют добавлять новые типы данных, то есть набор типов данных в РСУБД заранее определен и фиксирован. Классические РСУБД не поддерживают композитных атрибутов (доменами таких атрибутов являются пользовательские типы данных, составленные из предопределенного набора элементарных типов), несмотря на то, что они не противоречат реляционной модели.
Сильная сторона реляционных СУБД заключается в том, что они содержат встроенный язык запросов SQL, реализующий операции проекции и соединения отношений и предоставляющий необходимые средства для выполнения незапланированных запросов. Запросы к базе данных возвращают результаты в виде таблиц, которые тоже могут выступать как объект запросов.
К основным недостаткам РСУБД относят и то, что их семантическая составляющая развита слабо. Это, с одной стороны, затрудняет использование РСУБД в системах поддержки принятия решений и в предметных областях, имеющих сложно структурированные данные, где требуются дополнительные средства представления семантики данных. С другой стороны, программирование алгоритмов выборки данных на языке SQL порождает громоздкие конструкции.
Эти недостатки привели к появлению направления семантического моделирования и широкому использованию объектного подхода при организации хранения и обработки информации БД.
Объектно-ориентированный подход [4] был создан для решения задачи повышения уровня абстракции данных и стал фактическим стандартом разработки программного обеспечения. В объектно-ориентированных языках программирования (ООЯП) предметная область описывается в виде совокупности экземпляров различных типов, которые определяются программистом. ООЯП поддерживают три парадигмы: 1) инкапсуляция данных; 2) наследование; 3) полиморфизм.
Разработчики современных СУБД стремятся тем или иным способом реализовать объектные парадигмы, расширяя возможности базовых моделей данных. В то же время, для баз данных, использование в чистом виде объектно-ориентированного подхода зачастую может оказаться вредным, поскольку ограничивает возможность выполнения незапланированных запросов.
3. Направления развития объектного представления в базах данных
В зависимости от того, каким образом реализуются парадигмы объектно-ориентированного программирования, среди современных СУБД можно выделить три основных направления:
• объектно-ориентированные (ООСУБД);
• объектно-реляционные (ОРСУБД);
• постреляционные СУБД.
Объектно-ориентированные СУБД (ООСУБД) [3] предназначены для постоянного хранения объектов ООЯП и в них обеспечивается та или иная форма настройки по адресам. В качестве основы организации ООСУБД был принят стандарт ODMG (Object Data Management Group - консорциум разработчиков БД), описывающий способы хранения объектов в базах данных[5]. Основными элементами стандарта являются:
Объектная модель - основа стандарта, расширяет модель консорциума OMG(Object Management Group) свойствами, необходимыми для взаимодействия с БД (связи, транзакции). Особенностями объектной модели ODMG являются:
• наделение объектов такими свойствами, как атрибуты и связи;
• методы объектов (поведение);
• множественное наследование;
• идентификаторы объектов (ключи);
• определение таких совокупностей объектов как списки, наборы, массивы и т.д.;
• блокировка объектов и изоляция доступа;
• операции над базой данных.
Язык описания объектов (ODL - Object Defifnition Language) - средство определения схемы базы данных. ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний. Схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования.
Язык объектных запросов (OQL - Object Query Language) - SQL -подобный декларативный язык, который предоставляет эффективные средства для извлечения объектов из базы данных, включая высокоуровневые примитивы для наборов объектов и объектных структур. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).
Связывание с ОО-языками. Стандарт связывания с С++, Smalltalk и Java определяет Object Manipulation Language (OML) — язык манипулирования объектами, который расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программирования и доступа к данным.
Продукты на основе этого стандарта не имели коммерческого успеха, поскольку требовали преобразования существующих данных в формат СУБД. При этом ООСУБД изначально интегрированы с ООЯП, поэтому в код
приложения нет необходимости встраивать дополнительные конструкции типа SQL. ООСУБД входят в состав компилятора, который обрабатывает исходный текст и автоматически создает в БД структуры для хранения объектов. Объект сохраняется в БД при вызове специального метода. Основной недостаток ООСУБД, который они унаследовали от иерархических СУБД, - невозможность осуществления незапланированных запросов к БД без изменения её структуры (добавления новых структур данных или методов), а значит, изменения и самой программы. Кроме того, если с одной и той же БД работают приложения, количество которых заранее не определено, то появление нового приложения требует перекомпиляции уже имеющихся.
Другим направлением являются объектно-реляционные СУБД, появившиеся в результате расширения функционала реляционных СУБД и языков обращения к ним [6]. ОРСУБД наряду с хранением реляционных данных, обеспечивают постоянное хранение объектов. Такие системы используют отображение "объектный класс - домен" и поддерживают создание пользовательских типов данных. Это позволяет создавать композитные атрибуты, применять парадигмы наследования и полиморфизма. Так, если поле таблицы имеет базовый тип, то в нем может содержаться также и объект любого дочернего типа. Методы типа описываются в его теле, что поддерживает инкапсуляцию данных. Методы могут описывать преобразования к другим типам, что обеспечивает поддержку приведения типов на уровне доменов. Множественное наследование в современных ОРСУБД не поддерживается, хотя не исключается в будущем.
Помимо объектных расширений, ОРСУБД поддерживают все реляционные операторы. Поэтому ОРСУБД свободны от недостатков ООСУБД и поддерживают следующие возможности:
• незапланированные запросы;
• каскадное удаление (ссылочная целостность);
• поиск указателей и идентификаторов объектов скрыт от пользователя;
• использование преимуществ инкапсуляции для внутренней структуры отношений.
Поскольку ОРСУБД, по сути, реализуют реляционную модель с дополнительной поддержкой пользовательских типов на уровне доменов, то они наследуют все основные недостатки этой модели, связанные с семантикой.
Третьим направлением к объединению возможностей РБД и объектного представления данных является создание объектно-ориентированной надстройки над уже существующими реляционными СУБД. Получившиеся в результате СУБД были названы постреляционными. Этот вариант был предложен Майклом Стоунбрейкером [7] и реализован под его началом в университете Беркли в виде СУБД Postgres[8]. Постреляционные СУБД - результат эволюции РСУБД. Они позволяют создавать пользовательские типы данных (с некоторыми ограничениями) и таблицы с композитными столбцами. В качестве домена столбца может выступать таблица, а точнее - тип данных, соответствующий структуре таблицы и создаваемый одновременно с таблицей. Композитные типы создаются на основе некоторого базового множества элементарных типов, априорно поддерживаемых СУБД. Современные постреляционные СУБД не позволяют напрямую (средствами языка SQL или его объектных расширений)
создавать массивы для хранения произвольных структур, несмотря на то, что сами пользовательские типы данных определяются без особого труда. Создание массивов пользовательских типов средствами таких СУБД требует описания на одном из объектно-ориентированных языков самого массива, а также операторов преобразования массива в строку и обратно. Постреляционные СУБД позволяют хранить функции обработки данных, использующие в качестве параметров определяемые пользователем типы. В PostgreSql поддерживается возможность множественного наследования таблиц, которая вызывает ряд проблем (например, уникальность значений ключевых полей таблиц-наследниц). Проблемы возникают из-за неадекватности отображения "объектный класс - таблица", характерного для постреляционных СУБД [3]. Реляционную таблицу нельзя считать аналогом объектного класса, несмотря на то, что она тоже описывается набором атрибутов, по следующим причинам:
• Таблица, в отличие от объектного класса, является коллекцией однотипных объектов. В связи с этим, таблица должна иметь ключевой атрибут, который не характерен для объектного класса.
• Таблица не имеет методов. Конечно, можно описать функции, работающие с данной таблицей. Но между вызовами "taЫe.method(3)" и "procedure(taЫe,3)" нельзя ставить знак равенства, поскольку разрушается инкапсуляция объектного класса - ключевая парадигма объектно-ориентированного программирования.
Другими словами, более корректно отображение «динамический массив -таблица». Также постреляционные СУБД не поддерживают полиморфного поведения объектов, лежащих в одной иерархии наследования. Более того, если таблица содержит поле базового типа, то добавление объекта дочернего типа приводит к усечению последнего.
Заключение
Программирование в ограничениях является новым направлением, опирающимся на реляционное представление информации. Данное направление, по мнению авторов, не получило еще должного развития с точки зрения интеграции с объектно-ориентированным подходом. Принципиальное отличие технологии программирования ограничений от технологий управления данными состоит в том, первая предназначена для организации вывода на знаниях, а не манипулирования структурами данных. Отсутствие таких препятствий, как необходимость обеспечения одновременного доступа и целостности данных создает значительные предпосылки для упомянутой интеграции.
В статье рассмотрены различные способы интеграции объектного и реляционного подхода в СУБД. Наиболее перспективным из представленных и наименее противоречивым видится направление ОРСУБД. Учитывая успешный опыт применения ОРСУБД, по мнению авторов, именно отображение «объектный класс - домен» должно лежать и в основе разрабатываемых способов интеграции парадигмы программирования в ограничениях с объектно-ориентированным подходом.
Дальнейшие направления исследований в этой области предположительно будут связаны с разработкой контекстно-ориентированных механизмов формирования и активации систем ограничений на основе объектно-
ориентированного представления информации о предметной области, что обеспечит ускорение комбинаторного поиска в слабо формализованных предметных областях по сравнению с существующими средствами программирования ограничениях, поддерживающими только простые типы переменных.
Литература
1. Russel S., Norvig P. Artificial Intelligence: A Modem Approach. 3nd ed. / S. Russel, P. Norvig. Pearson Education, 2010. 1152 p.
2. Jussien N., Rochart G., Lorca X. Choco documentation. Режим доступа: http : //www. choco-solver.org.
3. Дейт К. Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. К.; M.; СПб.: Издательский дом «Вильямс», 2000. - 848 c.
4. Буч Г. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++. / Г. Буч. «Издательство Бином», «Невский диалект», 1998. 560 с.
5. Калиниченко Л.А. Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния. / Л.А. Калиниченко // СУБД. -1996. № 1. С. 102-109.
6. Бич Д. К объектным базам данных. // Открытые системы. 1994. № 4. С. 50-55.
7. Стоунбрейкер М. Объектно-реляционные системы баз данных // Открытые системы. 1994. № 4. С. 43-49.
8. Булах Е.В. Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95 // СУБД. 1997. № 2.
Сведения об авторах
Олейник Юрий Андреевич
младший научный сотрудник e-mail: yoleynik@iimm.ru Yurii A. Oleynik junior research fellow
Зуенко Александр Анатольевич к.т.н., ведущий научный сотрудник е-mail: zucnko@ iimm. ru Alexander A. Zouenko
Ph.D. (Tech. Sci.), lcading researcher
