ВУЗ:
Составители:
Рубрика:
77
Основная идея алгоритма состоит в том, что в каждом узле периодически
производится анализ на предмет существования тупика с использованием информации о
связях транзакций по ожиданию ресурсов, локальной в данном узле и полученной от
других узлов. При проведении этого анализа обнаруживаются либо циклы ожиданий, что
означает наличие тупика, либо потенциальные циклы, которые необходимо уточнить в
других узлах. Эти потенциальные циклы представляются в виде специального вида строк.
Строка представляет собой по сути дела список транзакций. Все транзакции упорядочены
в соответствии со значениями своих идентификаторов ("номеров транзакций"). Строка
передается для дальнейшего анализа в следующий узел (узел, в котором выполняется
самая правая в строке транзакция) только в том случае, если номер первой транзакции в
строке меньше номера последней транзакции. (Это оптимизация, уменьшающая число
передаваемых по сети сообщений). Этот процесс продолжается до обнаружения тупика.
Если обнаруживается наличие синхронизационного тупика, он разрушается за счет
уничтожения (отката) одной из транзакций, входящей в цикл. В качестве жертвы
выбирается транзакция, выполнившая к этому моменту наименьший объем работы. Эта
информация также передается по сети вместе со строками, описывающими связи
транзакций по ожиданию.
Интегрированные или федеративные системы и мультибазы данных
Направление интегрированных или федеративных систем неоднородных БД и
мульти-БД появилось в связи с необходимостью комплексирования систем БД,
основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление
пользователям интегрированной системы глобальной схемы БД, представленной в
некоторой модели данных, и автоматическое преобразование операторов
манипулирования БД глобального уровня в операторы, понятные соответствующим
локальным СУБД. В теоретическом плане проблемы преобразования решены, имеются
реализации.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою
автономность. После включения локальной БД в федеративную систему все дальнейшие
действия с ней, включая администрирование, должны вестись на глобальном уровне.
Поскольку пользователи часто не соглашаются утрачивать локальную автономность,
желая тем не менее иметь возможность работать со всеми локальными СУБД на одном
языке и формулировать запросы с одновременным указанием разных локальных БД,
развивается направление мульти-БД. В системах мульти-БД не поддерживается
глобальная схема интегрированной БД и применяются специальные способы именования
для доступа к объектам локальных БД. Как правило, в таких системах на глобальном
уровне допускается только выборка данных. Это позволяет сохранить автономность
локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в
вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно
к собственным проблемам интеграции приходится решать все проблемы, присущие
распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию
запросов и т.д. Очень трудно добиться эффективности.
Как правило, для внешнего представления интегрированных и мульти-БД
используется (иногда расширенная) реляционная модель данных. В последнее время все
чаще предлагается использовать объектно-ориентированные модели, но на практике пока
основой является реляционная модель. Поэтому, в частности, включение в
интегрированную систему локальной реляционной СУБД существенно проще и
эффективнее, чем включение СУБД, основанной на другой модели данных.
Основная идея алгоритма состоит в том, что в каждом узле периодически
производится анализ на предмет существования тупика с использованием информации о
связях транзакций по ожиданию ресурсов, локальной в данном узле и полученной от
других узлов. При проведении этого анализа обнаруживаются либо циклы ожиданий, что
означает наличие тупика, либо потенциальные циклы, которые необходимо уточнить в
других узлах. Эти потенциальные циклы представляются в виде специального вида строк.
Строка представляет собой по сути дела список транзакций. Все транзакции упорядочены
в соответствии со значениями своих идентификаторов ("номеров транзакций"). Строка
передается для дальнейшего анализа в следующий узел (узел, в котором выполняется
самая правая в строке транзакция) только в том случае, если номер первой транзакции в
строке меньше номера последней транзакции. (Это оптимизация, уменьшающая число
передаваемых по сети сообщений). Этот процесс продолжается до обнаружения тупика.
Если обнаруживается наличие синхронизационного тупика, он разрушается за счет
уничтожения (отката) одной из транзакций, входящей в цикл. В качестве жертвы
выбирается транзакция, выполнившая к этому моменту наименьший объем работы. Эта
информация также передается по сети вместе со строками, описывающими связи
транзакций по ожиданию.
Интегрированные или федеративные системы и мультибазы данных
Направление интегрированных или федеративных систем неоднородных БД и
мульти-БД появилось в связи с необходимостью комплексирования систем БД,
основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление
пользователям интегрированной системы глобальной схемы БД, представленной в
некоторой модели данных, и автоматическое преобразование операторов
манипулирования БД глобального уровня в операторы, понятные соответствующим
локальным СУБД. В теоретическом плане проблемы преобразования решены, имеются
реализации.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою
автономность. После включения локальной БД в федеративную систему все дальнейшие
действия с ней, включая администрирование, должны вестись на глобальном уровне.
Поскольку пользователи часто не соглашаются утрачивать локальную автономность,
желая тем не менее иметь возможность работать со всеми локальными СУБД на одном
языке и формулировать запросы с одновременным указанием разных локальных БД,
развивается направление мульти-БД. В системах мульти-БД не поддерживается
глобальная схема интегрированной БД и применяются специальные способы именования
для доступа к объектам локальных БД. Как правило, в таких системах на глобальном
уровне допускается только выборка данных. Это позволяет сохранить автономность
локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в
вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно
к собственным проблемам интеграции приходится решать все проблемы, присущие
распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию
запросов и т.д. Очень трудно добиться эффективности.
Как правило, для внешнего представления интегрированных и мульти-БД
используется (иногда расширенная) реляционная модель данных. В последнее время все
чаще предлагается использовать объектно-ориентированные модели, но на практике пока
основой является реляционная модель. Поэтому, в частности, включение в
интегрированную систему локальной реляционной СУБД существенно проще и
эффективнее, чем включение СУБД, основанной на другой модели данных.
77
Страницы
- « первая
- ‹ предыдущая
- …
- 75
- 76
- 77
- 78
- 79
- …
- следующая ›
- последняя »
