ДИНАМИЧЕСКИЕ БАЗЫ ДАННЫХ В ТУРБО-ПРОЛОГЕ

Программы баз данных (БД) на Турбо-Прологе есть частный случай систем управления базами данных (СУБД). СУБД являются компьютеризованной системой хранения информации. Данные в БД представляют собой набор фактов и цифр, записанных в доступной для компьютера форме. Эта упорядоченная совокупность и является содержимым базы данных.

СУБД должны предоставлять возможность добавления, удаления и корректировки данных. Эти функции реализуются специальными программами. Совокупность базы данных и функциональных программ образует систему управления базой данных.

Существуют три хорошо известные модели организации БД.

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

Пролог хорошо поддерживает реляционную базу данных. Предикаты базы данных нужно объявлять в отдельном разделе Database. Программная секция Database должна предшествовать объявлению предикатов Predicates. Объявление предикатов базы данных аналогично их описанию в секции Predicates.

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

Для работы с базой данных используют стандартные предикаты asseta, assertz, retractall, consult, save и др. Также нужно иметь представление о структуре памяти системы Пролога. Исходная программа на Прологе хранится в области SOURSE, в то время как для размещения фактов динамической базы данных отведена область HEAP. Поэтому на экране нельзя видеть информацию, записанную в базу данных. Однако ее можно просмотреть как текстовый файл, если сохранить его в каталоге под своим именем.

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

14.2 Файлы базы данных.

Любой файл базы данных представляет собой совокупность записей. В свою очередь запись - это совокупность полей. Каждое поле содержит часть данных.

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

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

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

14.3 Терминология.

Как уже было сказано, данные в реляционных БД можно представлять себе как элементы таблицы, состоящей из колонок и строк.

Рассмотрим следующий пример.

Эта таблица состоит из трех колонок и пяти строк. player является названием таблицы, всей структуры данных. player есть отношение. Имя колонки задает имя атрибута, который связан в таблице с другими атрибутами. Для отношения player введены три атрибута.

Набор атрибутов, в данном случае атрибутов Name1, Name2 и Name3, называется реляционной схемой. Количество колонок (атрибутов) называется арностью отношения. Арность отношения player равна 3. Строку таблицы в реляционной базе данных обычно называют элементом отношения. В нашем примере первым элементом отношения является

Marino, Miami, Zet

Число элементов отношения называется мощностью отношения. Мощность отношения player равна 5. Приведенные термины составляют необходимую для разговора о системах управления реляционных динамических БД терминологию.

База данных называется динамической, если во время работы программы из нее можно удалять любые содержащиеся в ней утверждения, а также добавлять новые. В этом состоит ее отличие от "статических" баз данных, где утверждения являются частью кода программы и не могут быть изменены во время счета. Другая важная особенность динамической базы данных состоит в том, что такая база может быть записана на диск, а также считана с диска в оперативную память.

Иногда бывает предпочтительно иметь часть информации базы данных в виде утверждений статической БД; эти данные заносятся в динамическую БД сразу после активизации программы. (для этой цели например используются предикаты asserta и assertz, которые будут рассмотрены ниже.) В общем, предикаты статической БД имеют другое имя, но ту же самую форму представления данных, что и предикаты динамической. Предикат статической БД, соответствующий предикату dplayer динамической базы данных.

Пример программы:

Predicates

player(name,team,position)

Clauses

player("Dan Marino","Miami Dolphins","QB").

player("Richart Dent","Chicago Bears","DE").

player("Bernie Kosar","Cleveland Browns","QB").

player("Doug Cosbie","Dallas Cowboy","TE").

player("Mark Malone","Pittsburgh Steelers","QB").

Заметим, что все отличие предиката dplayer по сравнению с player заключается лишь в одной лишней букве терма. Добавление латинской буквы d - обычный способ различать предикаты динамической и статической баз данных.

Правилом для занесения в динамическую БД информации из утверждений предиката player служит

assert_database :-

player(Name,Team,Number),

assertz(dplayer(Name,Team,Number) ),

fail.

assert_database :- !.

В этом правиле применяется метод отката после неудачи, который позволяет перебрать все утверждения предиката player.

Можно выделить следующее соответствие понятий:

База данных Турбо-Пролога ð Реляционная база данных

Предикат БД ð Отношение

Объект ð Атрибут

Отдельное утверждение ð Элемент отношения

Количество утверждений ð Мощность