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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конечно, стимулирует сбор данных именно ценность информации, увеличивает которую технология баз данных, позволяющая связывать данные для получения скрытой информации. Например, покупки можно классифицировать и построить графики предпочтений покупателей, имеющие огромное маркетинговое значение. Формы для подписки на журналы о бодибилдинге можно отправить тем, кто недавно купил тренажеры, а похожие формы для подписки на журналы о дрессировке собак можно отправить покупателям еды для собак. Альтернативные способы комбинирования информации иногда бывают очень изобретательными. Например, записи о социальном благополучии сравнили с криминальной информацией и смогли найти и арестовать нарушителей условий досрочного освобождения, а в 1984 году в Службе воинской повинности в США для идентификации граждан, уклонившихся от призыва на воинскую службу, использовали список дней рождения детей, полученный от популярного поставщика мороженого.

Существует несколько подходов для защиты общества от злоупотребления базами данных. Один из них — применение способов правовой защиты. К сожалению, принятие закона не исключает его нарушения, просто превращает это действие в незаконное. Показательный пример — это закон о вторжении в личную жизнь, принятый в США в 1974 году, Целью которого была защита граждан от неправомерного использования правительственных баз данных. Одним из положений этого закона было требование, чтобы правительственные организации сообщали о существовании внутренних баз данных в Федеральном регистре, и граждане могли получить и исправить касающуюся их информацию. Однако правительственные органы не спешили выполнять данный закон. Это не обязательно предполагает преступные намерения. Во многих случаях проблема кроется в бюрократизме. Но тот факт, что бюрократы могут создавать базы данных с информацией о гражданах, и о существовании этих баз невозможно узнать, не добавляет оптимизма.

Другое, и, возможно, более мощное средство контроля над злоупотреблением базами данных — это общественное мнение. Информация из баз данных не будет использована не по назначению, если наказания за злоупотребления превысят возможные выгоды, а наказание, которого компании боятся больше всего, — это неблагоприятный образ в глазах общества, что и делает такой подход верным. В начале 1990-х годов именно общественное мнение прекратило продажу крупнейшими кредитными организациями списков рассылки в маркетинговых целях. Совсем недавно America Online (крупнейший поставщик услуг Интернета) уступил давлению общества против практики продажи информации о клиентах телемаркетерам. Даже правительственные органы уступили общественному мнению. В 1997 году Администрация социального обеспечения в США изменила свой План лекции размещения записей о социальном обеспечении в Интернете, когда общество поставило вопрос о безопасности этой информации. В таких случаях результат был получен в течение нескольких дней — заметный контраст по сравнению с длительными судебными разбирательствами.

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

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