Пролог-автомат (pa) в поисковом движке FAIND: СУБД

Оригинален ли данный подход? Вообще говоря, нет.

В Сети можно найти достаточно много информации по этой теме (в основном англоязычные документы). Лучше всего искать через научный поисковик www.scirus.com, но гугль тоже полезен. Мы собрали несколько ссылок на ресурсы, посвященные языку Пролог и логическому программированию - см. здесь.

Вся хранимая информация в Словаре является по сути своей реляционной базой данных (РБД). Например, есть список словарных статей (свойство entries класса SynGram). Каждая статья помечена уникальным кодом (primary key в терминологии РБД). Это целое число, которое однозначно идентифицирует статью в лексиконе. Более того, так как этот код присваивается статье при ее создании и не зависит от индекса статьи в списке, то оказывается возможным в ходе компиляции, например, продукционного правила (см. раздел по синтаксическому автомату) запомнить ключ статьи - и в ходе выполнения правила оперировать именно ключами статей.

Аналогичный подход применяется для хранения любой другой информации в Словаре. Грамматические координаты представляют собой именованные списки значений. Координатная пара - это имя координаты и имя состояния. В словаре координатная пара представляется двумя целыми числами - индексом координаты и индексом состояния. В данном случае вместо абстрактных ключей используется физический индекс элемента во внутреннем списке. Это упрощает работу и ускоряет доступ, но накладывает ограничения: после компиляции Словаря нельзя менять списки с описаниями координат.

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

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

Но есть часть Системы - Пролог-автомат - которая и внутренне и внешне является настоящей СУБД. Может показаться странным использование достаточно экзотичного языка вместо индустриального стандарта SQL. Тому есть простое объяснение. Пролог прост и в смысле описания (в принципе, это пара десятков страниц с примерами), и в смысле реализации. Движок SQL-базы данных очень сложен, начиная от парсера выражений (синтаксис SQL'а достаточно витиеват и разнообразен), и заканчивая необходимостью писать планировщик-оптимизатор запросов, который будет строить алгоритм доступа к данным для каждого поступающего SELECT'а, UPDATE'а и DELETE'а. Кроме этого, средства процедурного программирования - языки PL/SQL и TSQL - сами являются отдельной песней со своим синтаксисом и идеологией, так как процедурный подход - с открытием курсора, чтения результирующего множества по записям и выполнения действий над каждой считанной записью, принципиально отличается от SQL - декларативного языка с неявными циклами, со своеобразными локальными переменными и т.д.

Пролог предлагает однородные средства как описания данных, так и доступа к ним. SQL таблицам прямо соответствуют предикаты. SQL отображения (VIEW) без каких-либо усложнений языка реализуются также через предикаты-теоремы (:-). Процедуры для работы с множествами записей в Прологе реализуются просто через AND-связку команд-предикатов.

Рассмотрим элементарный пример. Допустим, есть таблица сущностей ENTITY с полями:

id desc id_type
Primary_key Описание сущности Код типа - Foreign key на стоблец id таблицы ENTITY_TYPE

Есть также справочник типов сущностей ENTITY_TYPE:

id desc
Primary key Описание типа - строка с произвольным текстом

Пусть справочник типов содержит записи:

id desc
1 subject
2 object
3 action

Чтобы получить список сущностей, относящихся к типу action, в общем случае на SQL надо написать:

SELECT E.desc
    FROM ENTITY E, ENTYTY_TYPE T
    WHERE T.desc='action' AND E.id_type=T.id;

На Прологе этот запрос выглядит так:

subject( Sbj ) :- entity_type( Id_type, "action" ), entity( _, Sbj, Id_type )?

Различия невелики, она даже скорее формальны. К примеру, для подсчета записей о сущностях типа action потребуется минимальные дополнения в оба кода:

SELECT COUNT(E.desc) ...

и

count( subject(_), C )?

В данном случае count/2 - это встроенный предикат расширенного Пролога, который функционально аналогичен оператору COUNT языка SQL.

Разумеется, язык SQL предлагает некоторые мощные средства обеспечения целостности данных, которые отсутствуют в стандартном Прологе. Primary keys и foreign keys - удобные и эффективные способы гарантировать, что в БД не появятся записи, ссылающиеся на отсутствующие данные в других таблицах. Чтобы компенсировать этот изъян Пролога, в него были введены некоторые средства. В частности, с помощью встроенных предикатов можно объявлять требования к таблицам, то есть предикатам-записям одинаковой структуры и с одинаковым корневым атомом.

  © Mental Computing 2010