9.5 Поддержка целостности базы данных

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

9.5.1Пространственные базы данных

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

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

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

9.5.2Протоколы фиксации/отката изменений

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

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

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

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

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

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

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