Конспект Лекций БД. Конспект лекций_БД. Конспект лекций по курсу Информационное обеспечение, базы данных
![]()
|
Создание ИС, использующих РСБД. Основная проблема состоит в распределение данных по сети. В основном при создании РСУБД используют следующие основные подходы. Неявность адресации позволяет пользователю произвольно обращаться к данным (пользователь не касается распределения данных по узлам, не имеет понятия об их местонахождении). Неявность тиражирования если существует более одной копии данных, то при вызове необходимо обеспечить автоматическое извлечение данных из одного узла (одной копии), а внесение изменений во все копии. Если РСУБД не обеспечивает такую возможность, то пользователи могут не внести изменения во все копии, следствием чего станут ошибки в работе системы. Тиражирование обычно применяется с целью повышения доступа к данным (если одна копия не доступна, то м.б. доступна другая). Преимущества тиражирования: 1. Если на каком то из узлов произошел отказ, система может обойти этот узел и продолжить работу. Следовательно, повышается надежность хранения данных. 2. Чем больше копий, тем выше вероятность того, что запрос может работать без передачи данных с других узлов. Следовательно, снижается время и выполнения и затраты. Недостатки тиражирования: необходимость обеспечения неявности тиражирования. Независимость от конфигурации позволяет изменять систему не меняя компонентов существующего ПО РСУБД, т.е. это возможность добавлять и удалять узлы, менять оборудование. Независимость от СУБД (в случае использования различных СУБД на некоторых узлах) обеспечивается созданием пользовательского интерфейса, который можно применять для доступа к данным, управляемыми разными СУБД. Расчленение БД. При таком подходе БД, распределяется так, чтобы не было пересечения или дублирования данных, хранящихся на разных участках. Преимущества: отсутствуют затраты на хранение и поддержание избыточных данных. Недостаток: ограниченный доступ к данным, в случае использования их более чем на одном узле; возможность потери данных без восстановления, в случае выходи из строя хранящего их узла. Наиболее простоя способ реализации расчлененной БД состоит в создании нескольких независимо функционирующих систем БД с возможностью дистанционного доступа. Другой более сложный вариант, состоит в такой интеграции систем БД, при которой один пользовательский запрос может требовать обращения к нескольким системам БД. Хотя пользователь не касается конкретной реализации, для него может быть сложна манипуляция с несколькими БД при операциях реляционной алгебры. Продолжением стратегии расчленения БД является фрагментация данных. Фрагментация данных касается реляционных таблиц. Она связана с тем, каким образом реляционные таблицы могут быть разделены и распределены по сети. Если реляционная таблица фрагментирована, это означает, что она разделена на подмножества. Фрагментация может быть горизонтальной, разделяющей кортежи по разным фрагментам, или вертикальной, проектирующей атрибуты в разные фрагменты. Если фрагментация возможна, то таблица не обязательно храниться в одном узле. Ее подмножества могут быть распределены между несколькими узлами, а сами подмножества могут быть тиражированы. Восстановление БД Любая информационная система должна обладать средствами восстановления правильных данных. Приведение БД точно в то состояние, которое существовало перед отказом, не всегда возможно, но процедуры восстановления БД могут привести ее в состояние, существовавшее незадолго до отказа и идентифицировать состояние обработки транзакций в момент отказа. При таких возможностях невыполненные транзакции можно выполнить для восстановленной БД и привести ее снова в текущее состояние. Источники отказов: 1. Системные ошибки. Система вошла в нежелательное состояние, такое, как взаимоблокировка, не позволяющая нормально продолжать выполнение программы. Такой тип отказа может приводить, а может и не приводить к повреждению файлов БД. 2. Отказы оборудования. Два наиболее часто встречающихся типа отказов оборудования таковы: ошибка диска и потеря способности передачи данных через соединительную линию. В первом случае причиной обычно является физический контакт считывающей/записывающей головки с поверхностью диска (“авария головки”). 3. Логические ошибки. Плохие данные или их отсутствие часто являются причиной, не позволяющей нормально продолжать выполнение программы. Процедуры восстановления. Для того чтобы поддерживалась целостность данных, транзакция должна находится в одном из следующих состояний: 1. Прервана. Транзакция не всегда успешно завершается. Для того чтобы гарантировать непротиворечивое состояние БД, такую транзакцию необходимо прервать, восстановить состояние, в котором БД была до начала выполнения транзакции. Такое восстановление достигается при помощи отката. 2. Фиксирована. Если транзакция успешно завершается, то говорят, что она фиксирована. Фиксированная транзакция всегда оставляет БД в непротиворечивом состоянии. В восстановлении после отказов ключевую роль играет протокол. Протокол в данном случае это история всех изменений, внесенных в БД, а также состояние каждой транзакции. Очевидно, чрезвычайно важно, чтобы данные протокола не терялись и не повреждались. Следовательно, информация протокола должна хранится на “мифически устойчивом” от сбоев и повреждений запоминающем устройстве. На практике к этому приближаются путем создания нескольких копия на дисках. Стратегия восстановления строится по двум вариантам: протоколирование с отложенными обновлениями и протоколирование с немедленными обновлениями. Контрольные точки обеспечивают дополнительную эффективность. Протоколирование с отложенными обновлениями происходит следующим образом: 1. Когда транзакция А начинает свою работу, в протокол записывается “А Begin”, или “A START”. 2. На протяжении выполнения транзакции А при записи нового значения xi в атрибут Х, обозначаемым “Write(X, xi) в протокол заносится новая запись. 4. Каждая запись, описанная в предыдущем пункте состоит из следующих полей: а) имя транзакции, А; б) имя атрибута, Х; в) новое значение атрибута xi. 3. Если все действия, из которых состоит транзакция А, успешно выполнены, то говорят, что А частично фиксируется, а в протокол записывается “Х, СООММIТ”. После того, как А частично фиксирована, записи протокола, относящиеся к этой транзакции, используются для внесения соответствующих записей в БД. Рассмотрим пример оплаты счета, фирме перечислено 5 000 рублей. Действия, из которых состоит транзакция: А: Read (X, xi) Чтение текущего баланса клиента; х1 = x1 – 5 000 Уменьшение баланса счета клиента на 5 000 руб.; Write (X, x1) Запись нового баланса; Read (Y, yi) Чтение текущего кассового баланса у1 = у1 + 5 000 Увеличение кассового баланса на 5 000 руб.; Write (Y, y1) Запись нового баланса. Запись протокола отложенного обновления для законченного выполнения А. Записи протокола Значения БД ![]() Y = 15 000 A, begin Время A,X, 5 000 A,Y, 20 000 A,COMMIT X = 5 000 B = 20 000 Пользуясь представленным протоколом, СУБД может справится с любым отказом, не приведшим к потери информации самого протокола. Для предотвращения потери данных протокола он копируется на несколько дисков. Поскольку вероятность потери необходимых для восстановления БД очень маленькая, такой вариант хранения часто называют устойчивым запоминающим устройством. В случае отказа системы, СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Для восстановления используется процедура REDO(A), которая заменяет все значения элементов данных, обновляемых транзакцией А, на новые значения записанные в протоколе. Например, отказ произошел сразу после того, как запись A,COMMIT была внесена в протокол, но до того, как записи были сделаны в БД. Выполняется операция REDO, после чего записи в БД обновляются. Записи протокола Значения БД ![]() Y = 15 000 A, begin Время A,X, 5 000 A,Y, 20 000 A,COMMIT Если транзакция не была завершена, то есть в протоколе отсутствует запись A,COMMIT, например, сбой произошел перед выполнением операции Write (Y, y1), то значения в БД остаются такими же, какими они были до выполнения транзакции. В этом случае транзакцию необходимо перезапустить. |