Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Борри Хелен

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

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

значения различных столбцов одной таблицы или столбцов из нескольких таблиц.

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

"Руки прочь" от доступа к данным

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

Если приложение запрашивает набор данных для чтения, то клиентский модуль берет результат выполнения сервером операции и передает его приложению. Данные, видимые приложению, являются образом состояния исходных данных в базе данных на момент начала "переговоров" между клиентом и сервером. Этот образ, который видят пользователи, отключен - или изолирован - от базы данных. "Момент изоляции" может не совпадать с тем моментом, когда сервер получает запрос. В окружении клиент-сервер, где предполагается, что более чем один пользователь читает и пишет данные, каждый запрос имеет контекст.

Множество пользователей и параллельность

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

Транзакции

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

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

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

Транзакции завершаются, когда приложение обращается к клиенту, чтобы он запросил сервер подтвердить (commit) всю работу, выполненную с момента старта транзакции (даже если ничего не выполнялось, кроме чтения), или в случае ошибок отменить всю работу (rollback). Правило атомарности гласит: "Если одно из изменений оканчивается неудачей и требует отмены по причине невозможности подтверждения, то все ожидающие завершения изменения в этой транзакции также должны быть отменены". Отмена включает любые изменения, которые были сделаны триггерами и хранимыми процедурами в процессе выполнения этой транзакции.

! ! !

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

. ! .

Транзакции настолько важны в системах клиент-сервер, что в настоящем руководстве им посвящены три главы. 25, 26 и 27.

Пора дальше

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

ГЛАВА 6. Сервер Firebird.

Сервер Firebird - это программа, которая выполняется на узле хоста в сети, и слушает клиентов с порта коммуникации. Она обслуживает запросы множества клиентов к множеству баз данных. Суперсервер (Superserver) является многопоточным процессом, который запускает новый поток для каждого соединившегося клиента. В модели Классического сервера (Classic server) новый процесс запускается для каждого соединения.

Серверы Firebird могут выполняться почти на любом оборудовании персональных компьютеров и принимать клиентские соединения от приложений, выполняющихся в совершенно других операционных системах. С одной стороны, небольшой и легкий дистрибутив сервера может быть установлен на устаревшем оборудовании, даже для старых процессоров Pentium в операционной системе Windows 95 или в минимальных системах Linux. С другой стороны, серверы Firebird выполняются на распределенном оборудовании, управляя базами данных размерами в терабайты [8] .

8

Трудно определить, какой возможен максимальный размер баз данных Firebird. Пользователи сообщают о базах данных в 900 Гбайт, которые еще "продолжают расти".