Смекни!
smekni.com

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

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ УКРАИНЫ

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

им. И.И.Мечникова

ИНСТИТУТ МАТЕМАТИКИ, ЭКОНОМИКИ И МЕХАНИКИ

курсовая работа

На тему

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

студента 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) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД, т.е. происходит ее откат. Поддержание механизма транзакций необходимо для поддержания логической целостности БД при работе одновременно с несколькими пользователями, то есть в многопользовательских СУБД.

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

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

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

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

· Устойчивость – выполнение транзакции не должно привести к краху БД

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

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

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