Шпаргалка по "Программированию и компьютерам"

ign="justify"> В результате конкуренции за данными между  транзакциями возникают конфликты доступа к данным. Различают следующие виды конфликтов:

 W-W (Запись - Запись). Первая транзакция изменила  объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат - потеря обновления.

 R-W (Чтение - Запись). Первая транзакция прочитала  объект и не закончилась. Вторая  транзакция пытается изменить  этот объект. Результат - несовместимый  анализ (неповторяемое считывание).

 W-R (Запись - Чтение). Первая транзакция изменила  объект и не закончилась. Вторая  транзакция пытается прочитать  этот объект. Результат - чтение "грязных"  данных.

 Блокировки (относится к способам разрешения колнфликтов)

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

 Различают два типа блокировок:

 Монопольные блокировки (X-блокировки, X-locks - eXclusive locks) - блокировки без взаимного доступа (блокировка записи).

 Разделяемые блокировки (S-блокировки, S-locks - Shared locks) - блокировки с взаимным доступом (блокировка чтения).

 Если транзакция A блокирует объект при помощи X-блокировки, то всякий доступ к этому объекту  со стороны других транзакций отвергается.

 Если транзакция A блокирует объект при помощи S-блокировки, то

 запросы со стороны других транзакций на X-блокировку этого объекта будут отвергнуты,

 запросы со стороны других транзакций на S-блокировку этого объекта будут приняты.

 Предикатные блокировки

 Другим  способом блокирования является блокировка не объектов базы данных, а условий, которым могут удовлетворять объекты. Такие блокировки называются предикатными блокировками.

 Поскольку любая операция над реляционной  базой данных задается некоторым  условием (т.е. в ней указывается  не конкретный набор объектов базы данных, над которыми нужно выполнить операцию, а условие, которому должны удовлетворять объекты этого набора), то удобным способом было бы S или X-блокирование именно этого условия. Однако при попытке использовать этот метод в реальной СУБД возникает трудность определения совместимости различных условий. Действительно, в языке SQL допускаются условия с подзапросами и другими сложными предикатами. Проблема совместимости сравнительно легко решается для случая простых условий, имеющих вид:

 {Имя атрибута {= | <> | > | >= | < | <=} Значение}

 [{OR | AND} {Имя  атрибута {= | <> | > | >= | < | <=} Значение}.,..]

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

 Метод временных меток

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

 Основная  идея метода состоит в следующем: если транзакция A началась раньше транзакции B, то система обеспечивает такой  режим выполнения, как если бы A была целиком выполнена до начала B.

 и разных версий данных. 
 
 
 

 3. Распределенные СУБД. Однородные и неоднородные  распределенные СУБД. Методы построения  распределенных баз  данных.

 Распределенная  БД (DBB) – это совокупность логически взаимосвязанных БД распределенных в компьютерной сети.

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

 12 правил распределенной  системы:

 1) Локальная  автономия

 Это качество означает, что управление данными  на каждом из узлов распределенной системы выполняется локально.

 2) Независимость  от центрального узла

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

 3) Непрерывные  операции

 Это качество можно трактовать как возможность  непрерывного доступа к данным (известное "24 часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне зависимости  от операций, выполняемых на локальных  узлах.

 4) Прозрачность расположения

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

 5) Прозрачная  фрагментация

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

 6) Прозрачность  тиражирования

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

 7) Обработка  распределенных запросов

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

 8) Обработка  распределенных транзакций

 Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных.

 9) Независимость  от оборудования

 Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".

 10) Независимость  от операционных систем

 Это качество вытекает из предыдущего и означает многообразие операционных систем, управляющих узлами распределенной системы.

 11) Прозрачность  сети

 Доступ  к любым базам данных может  осуществляться по сети.

 12) Независимость  от баз данных

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

 Однородные  и неоднородные распределенные СУБД.

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

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

 Принципы  построения РБД:

 1) Минимизация  интенсивности обмена данными  (сетевого трафика)

 2) Оптимальным  размещением серверных и клиентских  приложений в сети

 3) Декомпозиция  данных на часто и редко используемые сегменты (для правильной настройки репликации - размещение наиболее часто используемых данных на АРМ конечных пользователей)

 4) Периодическое  сохранение копий данных и  выполнение действий по поддержке  целостности распределенной информационной системы.

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

 Наиболее  простым случаем декомпозиции является тот, когда образующиеся разделы базы данных логически автономны. В терминах концептуальной схемы это означает, что между разделенными сущностями отсутствуют прямые или транзитивные (через другие сущности) связи. В терминах реляционной схемы: ни в одном разделе не присутствует таблица, ссылающаяся на таблицу, которая располагается в другом разделе (рисунки 1.3 и 1.4). Если требование логической автономности компонентов распределенной базы данных выполнено, то дальнейшее проектирование можно производить для каждого компонента независимо.

 

 Рис. 1.3. Распределенная база данных с логически автономными  разделами 

 

 Рис. 1.4. Распределенная база данных с логически неавтономными  разделами 

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

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

 Язык SQL-92 позволяет определить ограничения  целостности, относящиеся к общему состоянию базы данных и включающие ссылки на произвольное число таблиц. Семантика таких ограничений целостности может быть существенно шире, чем ограничения, задаваемые связями 1 к n и даже n к m (1-to-many и many-to-many). Поэтому часто ограничения общего вида не выводятся автоматически из концептуальной схемы базы данных и их приходится добавлять к реляционной схеме вручную. Для того, чтобы понять, какие ограничения общего вида должны быть включены в реляционные схемы разделов, приходится возвращаться к документу, содержащему анализ требований корпорации. Задача проектировщика состоит в том, чтобы, с одной стороны, выявить все необходимые ограничения целостности и, с другой стороны, не перегрузить базу данных необязательными ограничениями (любое дополнительное ограничение целостности вызывает дополнительные проверки на стороне сервера при выполнении операций изменения базы данных; проверки для ограничений общего вида могут быть весьма громоздкими). Конечно, если предполагается использование распределенной базы данных, то опять придется учитывать возможности сервера по части ссылок на объекты "чужих" разделов. Это может повлиять на выбор ограничений целостности и/или повлечь создание новой декомпозиции общей базы данных на разделы.