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

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

Первый уровень — отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция 1 изменяет объект базы данных A. До завершения транзакции 1 транзакция 2 также изменяет объект A. Транзакция 2 завершается оператором ROLLBACK (например, по причине нарушения ограничений целостности). Тогда при повторном чтении объекта A транзакция 1 не видит… Читать ещё >

Реализация высокоуровнего интерфейса вокруг базы данных Berclee DB (реферат, курсовая, диплом, контрольная)

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ УКРАИНЫ ОДЕССКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

им. И. И. Мечникова ИНСТИТУТ МАТЕМАТИКИ, ЭКОНОМИКИ И МЕХАНИКИ курсовая работа На тему

«Реализация высокоуровнего интерфейса для работы с базой данных Berkeley DB»

студента 5 курса

кафедры математического обеспечения компьютерных систем Трофимова Бориса Научный руководитель:

доц. Каменева А. В.

Одесса 2004

1. Введение

2. Основные сведения из баз данных

· основные определения и классификация

· типы пользователей к БД

· механизм транзакций и курсоров

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

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

5. Структура разрабатываемой программы

· Ядро, включающее в себя библиотеку классов и все необходимые для работы стаба инструменты

· Лексический анализатор, его структура

· Синтаксический анализатор, его структура

· Семантика, генерация С++ стабов (автоматически сгенерированный программный код)

6. Пример работы программы

7. Заключение

8. Список используемой литературы

9. Приложения

1.Введение

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

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

1. Реляционная модель является универсальной, то есть с ее помощью в принципе можно реализовать любую схему данных.

2. Реляционная модель имеет под собой математический аппарат реляционной алгебры, она более формализована, нежели остальные модели.

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

Однако за универсальность нужно платить. И одним из слабых мест у реляционных СУБД является скорость выполнения запроса! Конечно, создаются интеллектуальные препроцессоры, оптимизирующие запрос, а также время его выполнения (так, например, такой есть в InterBase, Oracle, Informix), но проблема заключается в самой модели. Были проведены эксперименты, в ходе которых работа с навигационно-сетевой СУБД (Berkeley DB) была эффективней на порядок, чем с реляционной СУБД (Informix).

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

Итак, постановка задачи:

Сформировать транслятор генерации объектно-ориентированного интерфейса на С++ для работы с низкоуровневой СУБД BerkeleyDB по заданной пользователем схеме данных.

2.Основные сведения из баз данных

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

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

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

К основным функциям СУБД принято относить следующие:

· управление данными во внешней памяти;

· управление буферами оперативной памяти;

· управление транзакциями;

· журнализация и восстановление БД после сбоев;

· поддержка языков БД;

Любая СУБД обеспечивает как минимум две услуги.

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

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

Базы данных по доступу к данным можно разделить на следующие категории:

· Базы данных с низкоуровневым интерфейсом, такие базы не имеют встроенных средств определения типов данных и работают с «сырыми» блоками данных. Они обладают обычно достаточно быстрым доступом к данным.

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

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

Пользователи системы баз данных

Здесь под пользователем СУБД будем понимать субъект (пользователь, программист, прикладная программа), взаимодействующий с каким-нибудь интерфейсом к ней. Пользователей можно разбить на несколько категорий:

Первая — системные, отвечающие за программирование, например оболочек для базы. У нас это субъект, который формирует стабы по заданной схеме хранения данных.

Вторая — прикладные, отвечающие за написание прикладных программ, использующих базу данных (эту оболочку).

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

Механизм транзакций и курсоров

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

Итак, транзакция обладает следующими свойствами:

· Атомарность — либо транзакция принимается целиком, либо вообще нет.

· Согласованность — транзакция начинает выполняться при целой БД и переводит БД, в случае успешного завершения, также в целостное состояние

· Изолированность — выполнение одной транзакции не влияет на выполнение другой.

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

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

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

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

· Первый уровень — отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция 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-z0−9_]*.

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

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

заголовок

секция правил

нижняя секция

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

Она содержит также декларации приоритета, представленных %left, %right и %nonassoc (определяющ. ассоциативность).

%start указывает на правило (левую часть), выполняющееся первым.

Секция правил содержит грамматические правила:

Каждое правило состоит из слева лежащего символа (нетерминального), разделенного ':' и одним или несколькими возможными правилами, разделенными '|' и завершенными ';':

exp: exp '+' exp

| exp '-' exp

;

Правило справа может быть пустым

input: #empty

| input line

;

Для задания явного приоритета в случае неоднозначности следует использовать директиву %prec, дающую правилу высокий приоритет.

exp: '-' exp %prec NEG { -$_[1] }

| exp '+' exp { $_[1] + $_[3] }

| NUM

;

Примечательно, что YAPP позволяет встраивать в синтаксический анализатор семантику. Это организуется путем добавления в конце правила конструкций {…}, ограничивающих Perl-команды. Они встраиваются в синтаксический анализатор и выполняются после применения анализатором этого правила. Такой код может возвращать некоторую величину, используемую в определении следующего правила по дереву.

Переменные $_[1], $_[n] являются параметрами и хранят значения разобранного правила.

Нижняя секция может содержать корректный Perl-код, встраиваемый в конце сформированного синтаксического анализатора. Там можно указать лексер, процедуру анализа ошибок.

5.Структура разрабатываемой программы

Идеология оболочки состоит в том, что пользователь будущей базы данных сначала описывает на специальном языке структуры данных, из которых должны состоять таблицы в базе (то есть фактически интерфейсы) их ссылочные связи, индексы и т. п. Затем при помощи специального транслятора он получает готовый С++ код, реализующий интерфейс работы с базой данных, определенный пользователем, включая саму базу, ее таблицы, записи данных, транзакции и некоторые другие объекты. Код, генерируемый транслятором, на самом деле, является тоже оболочкой. Дело в том, что многие части транслятора имеют под собой общее основание. Эти статические классы и функции можно выделить в библиотеку. Еще одна причина для этого — семантика самого транслятора должна быть как можно проще. И как следствие этого, сокращаются размеры генерируемых файлов.

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

Новая база данных должна располагать такими возможностями:

· Добавление пользовательских данных их модификация и удаление.

· Открытие базы в нескольких режимах: например, в нормальном многопользовательском транзакционном режиме, безопасном режиме (как правило, для монопольного доступа и используется утилитами), а также в режиме восстановления базы данных.

· Импорта данных, то есть, представления данных в некотором текстовом формате, и их перемещение в пустую базу данных

· Экспорта данных, то есть, перемещение данных из базы, и представление их в определенном текстовом формате в файле, удобном для чтения. Является взаимно обратной операцией предыдущей.

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

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

Итак, вся оболочка состоит из следующих частей:

1. Собственно, базовая библиотека статических классов, для высокоуровневой работы с Berkeley, необходимая транслятору.

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

Библиотека классов

«Движок» представляет собой библиотеку классов, которые с одной стороны являются надстройками вокруг стандартных соответствующих структур, а с другой стороны делают их интерфейс более удобным и инкапсулируют часть работы транслятора. Основными компонентами являются:

· Транзакции

· Исключения

· Базовые записи

· Таблицы

· Базы данных

· Курсоры

Базовые записи

Базовая запись — это элементарная единица хранения в таблице. Описание ее класса:

//! базовый класс для записей с vtable pointer

class hbObj{

Dbt dbt;

protected:

void dbtInit (uint s, void* d)

{

dbt.set_flags (DB_DBT_USERMEM);

dbt.set_ulen (s);

dbt.set_size (s);

dbt.set_data (d);

}

public:

operator Dbt*(){return &dbt;}

void* getData (void) {return dbt. get_data ();};

uint getSize (void) {return dbt. get_size ();};

hbObj () {}

virtual ~hbObj () {}

};

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

//! реальный класс, который приводится к Dbt

template class hbRec: public hbObj

{

A data;

public:

A* getPnt (void) { return &data;} // если в в A массив то можно переопределить операцию & для А

hbRec () { memset (&data, 0, sizeof (A));dbtInit (sizeof (A),&data);}

hbRec (const hbRec& a):data (a.data) { dbtInit (sizeof (A),&data);}

hbRec (const A& a) :data (a) { dbtInit (sizeof (A),&data);}

void SetData (const A& a) { data = a;dbtInit (sizeof (A),&data);}

virtual ~hbRec () {}

};