Имя Пароль
Зарегистрироваться


* При перепечатке материалов ссылка на www.SeoLiga.ru обязательна! RSS



Базы данных, СУБД, дифференциальные файлы
17 марта 2009

Службы баз данных NetWare Btrieve и NetWare SQL фирмы Novell позволяют разработчикам создавать надежные прикладные программы баз данных без необходимости написания собственных программ управления записями, что обеспечивает удобный перенос прикладных программ в среду клиент — сервер.
В настоящее время разработаны десятки тысяч прикладных автономных и многозадачных программ, ориентированных на клиента версий NetWare Btrieve, NetWare SQL, которые могут быть использованы организациями, создающими или имеющими сеть ЭВМ. Более того, версии NetWare Btrieve и NetWare SQL фирмы Novell для клиентов имеют согласованные API, что упрощает перенос программ из среды одного клиента в среду другого.
По степени изменчивости все базы данных (БД) можно разделить на два класса:
А — условно-постоянные (в основном для справочных систем);
Б — сильно динамичные (для банковских, биржевых систем и т. п.).
Для ведения баз данных первого и второго классов используются системы управления базами данных (СУБД), которые в значительной степени отличаются друг от друга как по функциональным возможностям, так и по эксплуатационным характеристикам, например:
- для условно-постоянных БД наиболее важными показателями являются показатели скорости отработки запросов и скорости формирования выходных отчетов по БД, а такие показатели, как скорость отработки транзакций и контроль целостности БД при отработке транзакций, не столь критичны;
- для сильно динамичных БД на первый план выходят такие показатели, как: скорость отработки транзакций, возможность контроля целостности, скорость формирования отчетов, согласованность по чтению и транзакциям. Менее критичны здесь скорости отработки запросов.
Поэтому любая СУБД не может одинаково успешно применяться при работе с БД разных классов. Такие системы, как CLIPPER, FOXPRO, ориентированы на первый класс БД — (А), и здесь имеются неплохие результаты, а такие СУБД, как Informix, Ingres, SyBase, создавались для второго класса — (Б).
Всё вышесказанное подводит к решению найти «золотую середину», которая удовлетворяла бы требованиям обоих классов, (А) и (Б). Решением этой противоречивой задачи является использование дифференциальной организации файлов базы данных, или дифференциальных файлов (ДФ).
В последнее время разработчики СУБД ведущих фирм подошли к использованию идеи ДФ. Причинами явились следующие факты:
- значительное расширение класса решаемых на IBM PC задач, так что термин «персональный компьютер» уже не соответствует действительности;
- широкое распространение локальных вычислительных систем (ЛВС);
- разработка многопользовательских и многозадачных систем;
- стремительное развитие технической базы ЭВМ (в большей степени дисковой памяти).
Остановимся на сути ДФ применительно к БД в ЛВС. Реализация идеи ЛВС в различных СУБД значительно отличается.
Идея ДФ включает три положения:
- основной файл БД остается неизменным при любых обновлениях базы данных, т. е. любые изменения БД последовательно накапливаются в специальном файле изменений (не путать с журналом транзакций) — ДФ;
- никакие индексы для него не создаются и не поддерживаются.
Когда ДФ достигнет значительных размеров (примерно 25 — 40% от размеров БД), администратор вносит все изменения в основной файл БД в удобный момент времени в пакетном режиме.
Достоинства ДФ относятся к обеспечению высокой надежности, целостности БД и скорости отработки транзакций.
Вопрос, какие скорости отработки транзакций можно обеспечить при использовании ДФ, является довольно важным. Очевидно, что скорость отработки транзакций при такой организации БД возрастет в десятки раз. При этом сервер базы данных практически напоминает обычный файл-сервер.
Что касается индексов, то проблемы их поддержания не существует (скорости добавления, удаления и модификации записей БД находятся на самом высоком уровне). Добавления в БД не отличаются от добавлений в обычный последовательный файл. Время обновления записей БД не зависит ни от размеров БД, ни от длины ключей, ни от их числа. Временные затраты на блокировку (одно из узких мест для БД и ЛВС) сведены к минимуму.
Для того, чтобы обеспечить согласованность данных по чтению, нет необходимости блокировать целиком таблицу, что имеет место в ряде СУБД, т. е. когда запрос (или формируемый отчет) начинает выполняться, СУБД «запоминает» старший адрес в ДФ (моментальный снимок). При этом пользователь, инициирующий свой запрос, не обязан ждать «своего момента». Он «не видит» никого из пользователей и получает снимок БД именно в этот момент времени. Далее, по мере выполнения запроса (даже очень быстрого), часть записей-целей могла быть или изменена, или удалена. Это отразится только на старших адресах ДФ, а поэтому СУБД просто проигнорирует любые изменения данных, случившиеся после начала выполнения запроса. Гарантируется корректировка сложных и длительных запросов к БД, т. е. обеспечение согласованности по чтению и транзакциям.
Как же в этом случае ведется поиск в БД? В этом случае по ассоциатору находится множество записей-целей: число и список их адресов в основной БД, после чего производится считывание ассоциатора ДФ, и производится корректировка этого списка. За счет этой корректировки время поиска увеличивается, причем величина этого увеличения зависит от размеров ДФ. Своевременность обновления БД должна быть в компетенции администратора БД. Чтобы исключить существенные издержки, связанные с ДФ, можно накапливать изменения БД для их пакетной обработки и при поиске ДФ не учитывать. В ряде систем, таких, как банковские, допускается потеря некоторой точности в период между циклами обновления — «контролируемое запаздывание».
Помимо всего прочего использование ДФ обеспечивает:
- восстановление администратором случайно удаленных записей;
- хранение индексных файлов на самих рабочих станциях;
- создание распределенных БД;
- одновременное выполнение транзакций.
Непротиворечивость данных может обеспечиваться механизмом захвата на уровне записи — откат транзакций любой доступной вложенности.
Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз данных.


Теги: asus socket, amd socket, intel socket, athlon socket, pentium socket, socket error, windows sockets, СУБД, SQL-сервер, Application Server, расширения SQL Borland Delphi

Статьи по теме:

Панель HTML Format
Вопросы разработки информационных технологий обработки данных
Свойство ChildBand
OnIndexMissing
Автоматизация административных функций
Свойство DataField
Базовые технологии обработки запросов в архитектурах файл —сервер и клиент — сервер
Свойство LeftOffset
Свойство PaperLength
Системы искусственного интеллекта
Классы построителя отчетов (Report Builder)
Интеллектуальный анализ данных (ИАД)
Использование выражений
IndexFieldNames
Сетевая технология Ethernet
| Borland Delphi | Alex |
 


Пн Вт Ср Чт Пт Сб Вс
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30


     



Rambler's Top100

Данный сайт или домен продается ICQ: 403-353-727

© 2009 Seoliga.ru | Borland Delphi | Базы данных, СУБД, дифференциальные файлы. Регион сайта: Москва и Санкт-Петербург