Страница: 18/18
- широкое распространение локальных вычислительных систем (ЛВС);
- разработка многопользовательских и многозадачных систем;
- стремительное развитие технической базы ЭВМ (в большей степени дисковой памяти).
Остановимся на сути ДФ применительно к БД в ЛВС. Реализация идеи ЛВС в различных СУБД значительно отличается.
Идея ДФ включает три положения:
- основной файл БД остается неизменным при любых обновлениях базы данных, т.е., любые изменения БД последовательно накапливаются в специальном файле изменений (не путать с журналом транзакций) - ДФ;
- никакие индексы для него не создаются и не поддерживаются.
Когда ДФ достигнет значительных размеров (примерно 25-40% от размеров БД), администратор вносит все изменения в основной файл БД в удобный момент времени в пакетном режиме.
В качестве примера возьмем сравнение книги, где наблюдаются опечатки в страницах и, базы данных с ДФ. Нет необходимости переиздания книги из-за нескольких опечаток или незначительных изменений. Если это количество имеет тенденцию к значительному росту и достигло предельного значения, то становятся оправданными затраты на переиздание книги, куда должны быть включены все накопленные изменения.
Достоинства ДФ относятся к обеспечению высокой надежности, целостности БД и скорости отработки транзакций.
Вопрос, какие скорости отработки транзакций можно обеспечить при использовании ДФ, является довольно важным. Очевидно, что скорость отработки транзакций при такой организации БД возрастет в десятки раз. При этом сервер базы данных практически напоминает обычный файл-сервер.
Что касается индексов, то проблемы их поддержания не существует (скорости добавления, удаления и модификации записей БД находятся на самом высоком уровне). Внесение добавлений в БД не отличается от добавлений в обычный последовательный файл. Время обновления записей БД не зависит ни от размеров БД, ни от длины ключей, ни от их числа. Временные затраты на блокировку (как одно из узких мест для БД и ЛВС) сведены к минимуму.
Для того, чтобы обеспечить согласованность данных по чтению нет необходимости блокировать целиком таблицу, что имеет место в ряде СУБД, т.е., когда запрос (или формируемый отчет) начинает выполняться, СУБД "запоминает" старший адрес в ДФ (моментальный снимок). При этом пользователь, инициализирующий свой запрос, не обязан ждать "своего момента". Он "не видит" никого из пользователей и получает снимок БД именно в этот момент времени. Далее, по мере выполнения запроса (даже очень быстрого) часть записей-целей могла быть или изменена или удалена. Это отразится только на старших адресах ДФ, а поэтому СУБД просто проигнорирует любые изменения данных, случившиеся после начала выполнения запроса. Гарантируется корректировка сложных и длительных запросов к БД, т.е. обеспечение согласованности по чтению и транзакциям.
Становится интересным вопрос, как в этом случае ведется поиск в БД. В этом случае по ассоциатору находится множество записей-целей: число и список их адресов в основной БД, после чего производится считывание "ассоциатора" ДФ и производится корректировка этого списка. За счет этой корректировки время поиска увеличивается, причем величина этого увеличения зависит от размеров ДФ. Своевременность обновления БД должна быть в компетенции администратора БД. Чтобы исключить существенные издержки, связанные с ДФ, можно накапливать изменения БД для их пакетной обработки и при поиске ДФ не учитывать. В ряде систем, таких как банковские, допускается потеря некоторой точности в период между циклами обновления - "контролируемое запаздывание".
Помимо всего прочего использование ДФ обеспечивает:
- возможность администратору восстанавливать случайно удаленные записи;
- возможность (при необходимости) хранить индексные файлы на самих рабочих станциях;
- возможность создания распределенных БД;
- одновременное выполнение транзакций.
Непротиворечивость данных может обеспечиваться механизмом захвата на уровне записи - откат транзакций любой доступной вложенности.
Реферат опубликован: 18/10/2006