Реализация высокоуровнего интерфейса вокруг базы данных Berclee DB (стр. 2 из 5)

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

· Первый уровень - отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция 1 изменяет объект базы данных A. До завершения транзакции 1 транзакция 2 также изменяет объект A. Транзакция 2 завершается оператором ROLLBACK (например, по причине нарушения ограничений целостности). Тогда при повторном чтении объекта A транзакция 1 не видит изменений этого объекта, произведенных ранее. Такая ситуация называется ситуацией потерянных изменений. Естественно, она противоречит требованию изолированности пользователей. Чтобы избежать такой ситуации в транзакции 1 требуется, чтобы до завершения транзакции 1 никакая другая транзакция не могла изменять объект A. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

· Второй уровень - отсутствие чтения "грязных данных". Рассмотрим следующий сценарий совместного выполнения транзакций 1 и 2. Транзакция 1 изменяет объект базы данных A. Параллельно с этим транзакция 2 читает объект A. Поскольку операция изменения еще не завершена, транзакция 2 видит несогласованные "грязные" данные (в частности, операция транзакции 1 может быть отвернута при проверке немедленно проверяемого ограничения целостности). Это тоже не соответствует требованию изолированности пользователей (каждый пользователь начинает свою транзакцию при согласованном состоянии базы данных и в праве ожидать видеть согласованные данные). Чтобы избежать ситуации чтения "грязных" данных, до завершения транзакции 1, изменившей объект A, никакая другая транзакция не должна читать объект A (минимальным требованием является блокировка чтения объекта A до завершения операции его изменения в транзакции 1).

· Третий уровень - отсутствие неповторяющихся чтений. Рассмотрим следующий сценарий. Транзакция 1 читает объект базы данных A. До завершения транзакции 1 транзакция 2 изменяет объект A и успешно завершается оператором COMMIT. Транзакция 1 повторно читает объект A и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения транзакции 1 никакая другая транзакция не должна изменять объект A. В большинстве систем это является максимальным требованием к синхронизации транзакций, хотя, как мы увидим немного позже, отсутствие неповторяющихся чтений еще не гарантирует реальной изолированности пользователей.

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

Курсоры представляют собой совершенно другую сущность БД. Одной из самых распространенных операций с БД является предоставление набора информации по запросу пользователя. В реляционной БД это организуется через конструкцию “ select …”. Итак, результатом выполнения такого запроса будет набор данных, взятый из БД. Однако как получить доступ к этим данным? В соответствии с новой парадигмой ООП – шаблонами проектирования, определяется некоторый объект, называемый курсором, который выполняет функции простого итератора. Фактически через его интерфейс пользователь в состоянии перебирать все данные, хранящиеся в полученном наборов произвольном порядке.

Такой объект имеет обычно такой интерфейс:

Init (…); создание итератора

Bool GetNextInfo (); перейти на следующую порцию данных

GetCurrData (); получить текущую порцию данных

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

Естественно, понятие курсора тесно связано с механизмом транзакций.

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

3.Основные сведения из BerkeleyDB

Berkeley DB – « open source » библиотека баз данных, которая обеспечивает масштабируемое, быстродействующее, управление данных, их защиту в приложении. Berkeley DB обеспечивает простой функциональный вызов API для доступа к данным и их управления для множества языков программирования, включая C, C++, Java, Perl, Tcl, Pyton , и PHP. Все операции с базой совершаются в библиотеке. Низкий уровень операций включает в себя механизм блокировок, транзакционных блокировок, коллективного буферного управления, управления памяти и т. п.

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

Библиотека является достаточно портативной. Она работает под почти всеми UNIX и вариантами Linux, Windows, и множеством других операционных систем в реальном времени. Она работает как на 32- бите так и 64- битовых системах .

Сама база данных библиотеки является чрезвычайно компактной (под 300 килобайтами текстового пространства в общей архитектуре), но она может управлять базами данных вплоть до 256 terabytes. Она также поддерживает высокий параллелизм, с тысячами пользователей, действующих на той же базе данных в то же самое время.

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

Таблицы Hash обычно хороши для очень больших баз данных, когда необходим поиск и разумное время коррекции для произвольного доступа записей. Таблицы Hash позволяют спрашивать, "этот объект существует?" или, чтобы выбирать запись с известным объектом. Таблицы Hash не позволяют, например, требовать записи с объектами, которые близки к известному объекту. Btree используется для поисков, базирующихся на диапазонах, когда приложению нужно находить все записи с объектами между некоторым начальным значением и концом. Btree также подходит для организации ссылочной зависимости. Структура Btree хранит близкие данные рядом в памяти (на диске), так что при выборе соседних величин обычно не требуется дисковый доступ. Очереди, основанные на числовой индексации записей. Каждая запись имеет уникальный номер. И поиск, удаление, изменение записи осуществляется через этот номер. Berkeley DB генерирует эти рекордные номера автоматически.

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

Berkeley DB не является сервером баз данных. Так как библиотека для работы с Berkeley загружается в адресное пространство приложения и доступно только для него. Хотя такое решение реализуемо.

Итак, Berkeley DB состоит из следующих объектов: Dbt , Db , DbEnv . Они связаны следующим образом

4.Основные сведения по программной системе генерации языков программирования YAPP

YAPP представляет собой программную систему с использованием Perl для генерации и использования синтаксических анализаторов LALR. Фактически это коллекция модулей расширения, написанных на Perl , совместимая с форматом YACC и позволяющих генерировать perl -код.

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

yapp grammar _ file . yp

На выходе получаем perl - модуль, выполняющий синтаксический анализатор языка, описываемого пользователем. То есть, фактически, yapp и генерирует синтаксические анализаторы.

Чтобы подключить синтаксический анализатор, пользователь должен подготовить уже своими силами лексический анализатор и использовать примерно такой код:

use MyParser; $parser=new MyParser(); $value=$parser->YYParse(yylex => \&lexer_sub, yyerror => \&error_sub);

Файл грамматики

1) Комментарии бывают в стиле Perl # или в стиле С // , /* */.

2) Признаки литералов и строк.

В любом грамматическом файле могут появиться только два типа символов: нетерминальные символы, назвавшие также лево-лежащие символы (имена правил), и терминальные символы названные также лексемами. Лексемы являются символами, получаемыми на выходе лексического анализатора.

Синтаксис нетерминальных символов и символьных лексем: [ A - Za - z ][ A - Za - z 0-9_]*.

Запрещено использование название « error » для литералов.

Структура его выглядит следующим образом (очень похожа на yacc , фактически является ее подмножеством)

Файл состоит из трех секций, разделенных %% :

заголовок %% секция правил %% нижняя секция

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