3 Поскольку корнеиоП узел В-дереиа используето! при кажлом поиске. вклю-1аюшем иклекс. его блок ч 1Сто обнаружиопется в основной памяти и занимает опну страницу буфера, поэтому на практике аостаточио доступа к ануи дисковым блокам.

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

Простой, но дорогостоящий план - проверять все кортежи (строки) отношения Customers до тех пор, пока не найдется имя клиента Салли Джонс. В срелнем придется проверить половину кортежей, чтобы найти это имя. Поскольку банк может иметь множество клиентов, отношение Customers займет много дисковых блоков, так что этот шаг окажется очень дорогим. Недостаточно полутть номер етри.чового полиса Салли Джонс. Нужно еще просмотреть кортежи отношения Accounts и найти счета с этим номером. Поскольку таких счетов может быть мною, придется просматривать все кортежи. Как правило, в банке много счетов, поэтому отношение Accounts гоже займет много дисковых блоков и их просмотр обойдется весьма дорого.

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

Разумеется, нужно сделать и второй шаг: найти кортеж с заданным номером страхового полиса в отношении Accounts. Для этого обычно требуется многократный доступ к диску. Однако при наличии индекса на номере страхового полиса для отношения Accounts можно найти каждый блок, содержащий один из счетов с данным номером, просматривая указанный индекс. Для этого необходимы два или три доступа к диску, как и в случае с индексным доступом к отношению Customers. Если все требуемые кортежи находятся в различных дисковых блоках, нужен доступ к каждому из этих блоков. Но один человек может и не иметь множества счетов, так что на этом шаге, возможно потребуется небольшое количество доступов к лиску.

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

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

1.2.4 Менеджер транзакций

Как говорилось в разделе 1.1, СУБД должна гарантировать выполнение оп>с-яе>1енных nnepauiiM на БД Например, важно, чтобы результат выполнения операции никогда не был утрачен, даже о случае серьезной поломки системы Типичная

Разд1еры блокируемых элементов

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

СУЬД позволяет пользователю сгруппировать несколько запросов и/нли изменений и олиой транзакции. Неформально говоря, тршпакцих - это группа операций, которые необходимо выполнить последовательно как единое целое.

Чаао система ЬД допускает параллельную поддержку .множества транзакций (например, что-то может происходить иа нескольких банкоматах одновременно). Гарантировать правильное выполнение всех таких транзакций - задача компонента СУБД. називаемо10 менеджером транзакций. Говоря точнее, правильное выполнение транз:1КИ11й требует того, что часто называется /Юй-свойствами (atomicity, consistency, isolation, durability - четырех основных требования к выполнению транзакций).

Атомарность. Требуется, чтобы были выпол)1ены все транзакции или не была выполнена ни одна из них. Например, изъятие денег из банкомата и BHCceHite соответствующего дебета в счет клиента должны быть единственной атомарной транзакцией. Отдельное выполнение одной из этих операций не допускается

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

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

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

Реализация транзакций с ACID-свойствами может быть темой отдельной книги, и мы не будем пытаться осветить эту тему полностью. Однако в разделе 7.2 будет показано, как в яз1чке SQL определить операиии, относящиеся к транзакциям, и что .может извлечь программист SQL из объединения операций в транзакции. В этом разделе очень кратко описаны общие методы обеспечения свойств ACID.

Блокировка

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

Регистрация

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

Завершение транзакции

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

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

1.2.5 Архитектура клиент/сервер

Во многих вариантах современного ПО реализуется архетектура, в которой один процесс {клиент) посылает запрос для выполнения другому процессу (серверу). БД не исключение, и работа компонентов, показанных иа рис. 1.1, часто разделяется иа Процесс сервера и несколько процессов клиентов.

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