1.5. Абс на основе менеджера записей Btrieve (rs-Bank, «Новая Афина», «бис», «Кворум»)

Btrieve — программный продукт (СУБД), для организации транзакционных (или «навигационных»[1]) баз данных. Основан на методе организации данных ISAM, обеспечивающем высокую скорость поиска и извлечения данных. Существовало несколько версий этого продукта для DOS, Linux, старых версий Microsoft Windows: Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003 - и Novell NetWare.

Первоначально это был менеджер записей, выпущенный компанией SoftCraft приблизительно в то же время, что и первые IBM PC. После завоевания популярности и доли рынка, он был выкуплен компанией Novell для интеграции в её операционную систему Netware, с одновременным развитием версии для MS-DOS. Этот продукт не смог завоевать сколь-либо значительный рынок и после некоторой реорганизации внутри Novell — был выделен для разработки в рамках отдельной, вновь созданной, компании — Btrieve Technologies, Inc. (BTI).

Начиная с версии 6.15 Btrieve был разделён на отдельные модули, а само название закрепилось за одним из двух backend средств доступа к данным, подключенных к стандартному программному интерфейсу, получившему название Micro-Kernel Database Engine (MKDE). Второй вариант backend, Scalable SQL, — средство работы с реляционными БД, использующее язык SQL. После выпуска нескольких версий компания была переименована в Pervasive Software и сейчас она поставляет этот продукт под названием Pervasive PSQL.

Н овые версии АБС (в числе первых были Афина и Диасофт 5NT) разрабатывались в графическом интерфейсе с использованием таких СУБД, как Oracle Database, Sybase и в дальнейшем Microsoft SQL Server. Кроме того, ПрограмБанк и ЭСКЕЙП-М использовали в своих продуктах СУБД Caché. В основном переход на новые платформы завершился к 2000 году.

Прежде всего, Btrieve не является реляционной СУБД (РСУБД). Ранние описания называли ее «менеджер записей»(англ. record manager); Pervasive первоначально использовали термин «навигационная база данных» (англ. navigational database), позже измененный на «транзакционная база данных» (англ. transactional database). Такая терминология обусловлена тем, что Btrieve имеет дело только с элементарными операциями создания/обновления записей, извлечения/удаления данных. В качестве внутреннего механизма хранения и индексирования данных используется ISAM. Ключевой частью архитектуры, принятой Pervasive Software, является использование микроядерного механизма построения СУБД(англ. MicroKernel Database Engine (MKDE), который позволяет выполнять различные варианты backend в виде модулей, и довольно просто интегрировать их в общий пакет СУБД Pervasive.SQL. Это позволило поддерживать оба механизма доступа к данным — навигационный Btrieve, и реляционный, основанный на SQL, — Scalable SQL.

Т екущие версии Btrieve поддерживают два вида транзакций, системные и пользовательские, где системные транзакцииявляются пакетами не-транзакционных операций и/или пользовательских транзакций, а пользовательские транзакции — транзакциями над реальными данными в БД. Механизм системных транзакций был создан для возможности исполнения нескольких транзакций в одном пакете и большей простоты восстановления данных.

Файлы формата Btrieve состоят из страниц, которые и являются порциями данных, передаваемыми между оперативной памятью и долговременным хранилищем в процессе операций ввода/вывода, выполняемых ядром СУБД. В версиях до 6.0 использовались только страницы данных, индексов и специальная запись FCR (англ. file control record), содержащая важную информацию о файле БД (размер страницы, число использованных страниц и т. п.). Такой файл содержал поисковый индекс, привязанный к физическим страницам. Начиная с версии 6.0 было введено понятие логическая страница, а уже эти страницы отображались на физические страницы, имеющие фиксированное положение в файле, на диске. Отображение осуществляется посредством таблиц распределения страниц PAT (англ. page allocation tables). Для предотвращения нарушений логической целостности в файлах БД, Btrieve использует два подхода к обновлению зависей: pre-image paging в версиях до 6.0 и shadow paging в последующих. Переход от pre-image paging к shadow paging потребовал существенной перестройки, которая привела к кардинальному изменению формата файлов и утрате совместимости между 6-й версией и предыдущими.

При доступе к файлам, ядро СУБД может использовать две стратегии, сокращённо именуемые SEFS и MEFS, от англ. Single Engine File Sharing (SEFS); Multi Engine File Sharing (MEFS). SEFS подразумевает, что с файлами будет работоть только один экземпляр ядра СУБД, в то время как MEFS позволяет нескольким независимым экземплярам работать с одними и теми же файлами одновременно (причём каждое такое ядро будет обслуживать собственных пользователей).