Управление базами данных (стр. 2 из 5)

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

- каждая таблица состоит из однотипных строк и имеет уникальное имя;

- строки имеют фиксированное число полей (столбцов) и значений, т. е. в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего;

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

- столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных;

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

1.7 Основные функции СУБД

Управление данными во внешней памяти.

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

Управление оперативной памятью.

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

Управление транзакциями.

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

Журнализация.

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

Очевидно, что независимо от типа сбоя для восстановления БД нужно иметь некоторые дополнительные сведения, которые имеются и в журнале изменений БД. Это недоступная пользователям СУБД часть БД, в которую заносятся записи обо всех изменениях основной части БД. При занесении записей в журнал поддерживается протокол «упреждений» (Write Ahead Log - WAL), т. е. запись об изменении любого объекта БД попадает во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД.

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

Поддержка языков БД.

Для работы с базами данных используются специальные языки, называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных языков, среди которых чаще всего использовались язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language).

Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который сочетает в себе средства SDL и DML, т. е. позволяет определять схему реляционной БД и манипулировать данными. SQL содержит специальные средства определения ограничений целостности БД, а его специальные операторы позволяют определять так называемые представления БД, которые фактически являются хранимыми в БД запросами. Результатом любого запроса к реляционной БД является таблица с именованными столбцами.

1.8 Язык запросов SQL

Язык SQL (Structered Query Language - язык структурированных запросов) появился более 30 лет назад в рамках проекта экспериментальной реляционной СУБД под названием System R. Сначала он назвался SEQUEL (Structered English Query Language).

Практически одновременно с появлением первых его коммерческих реализаций SQL появился и первый его стандарт ANSI/ISO (1985 г.). Вскоре появился SQL 92, который охватывает практически все необходимые для реализации аспекты: манипулирование схемой БД, управление транзакциями и сессиями (последовательностью транзакциями, в пределах которой сохраняются временные отношения), подключение к БД, динамический SQL, стандартизованы отношения-каталоги.

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

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

Кроме того, в SQL является необязательным удаление кортежей-дубликатов в окончательной или промежуточных таблицах. Строго говоря, результатом оператора выборки (SELECT) в языке SQL является не отношение, а множество кортежей.

Самый общий вид запроса на языке SQL представляет выражение, составленное из элементарных запросов. В SQL System R допускались все базовые теоретико-множественные операции (UNION, INTERSECT и MINUS).

Операторы манипулирования данными UPDATE и DELETE построены на тех же принципах, что и оператор выборки данных SELECT. Набор кортежей указанного отношения, подлежащих модификации или удалению, определяется входящим в соответствующий оператор логическим выражением, которое может включать сложные предикаты, в том числе и с вложенными подзапросами.

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

SELECT PERSONS.PERSONA, PERSONS.FAMILIA, PERSONS.IMIA, PERS.ONS.OTCHEST, PERSONS.IDNUM, PERSONS.TABNUM

FROM PERSONS

WHERE (((PERSONS.IMIA) = «Сергей») AND ((PERSONS.TABNUM)>10));

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

Рис. 1.3. Пример использования SQL в настольной СУБД

2. Настольные реляционные базы данных

2.1 Общие замечания

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

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

На сегодняшний день известно множество настольных СУБД, однако наиболее популярными являются dBase, Paradox, FoxPro и Access. Особо нужно отметить Microsoft Data Engine (MSDE) - по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server, но предназначенную для использования главным образом в настольных системах.

2.2 Краткая характеристика настольных систем

2.2.1 dBase и Visual dBase

Хранение данных в dBase (www.dbase2000.com) основано на принципе «одна таблица - один файл» (эти файлы обычно имеют расширение *.dbf). МЕМО-поля и BLOB-поля, как и индексы для таблиц, хранятся в отдельных файлах (обычно с расширением *.dbt). Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД.