Классика баз данных - статьи

Отчетность по дублированной базе учетной системы


Альтернатива описанному выше подходу - использование "автономной" (offline) базы данных (data store), которая представляет собой дубликат оперативной базы. Дублированная база обновляется по мере необходимости; в ней применяются те же средства отчетности. Запросы пользователей передаются в автономную базу данных, которая может быть реализована по разному, например в виде плоских файлов (flat files) или копий таблиц исходной базы.

Рис. 2. Отчетность в дублированной базе учетной системы

Надписи на рисунке:

Sales -продажи;

Operations - операции;

Financial - финансы;

HR - человеческие ресурсы;

Business User - бизнес-пользователь

Преимущество этого подхода в том, что выполнение запросов пользователей происходит в другой базе данных, а значит, обработка транзакций не прерывается. При этом системные ресурсы OLTP-сервера используются для быстрой обработки транзакций, а автономная база - только для задач отчетности. Однако многие из проблем, свойственных первому подходу, так и остаются не решенными, поскольку данные по-прежнему не "очищены", их организация не понятна пользователю, а информация за прошлые периоды, как правило, не доступна.

Дублированные данные передаются из OLTP-системы в основном тремя способами: при помощи журналов транзакций (transaction logs), путем репликации базы или через пакетные файлы. Каждый способ имеет свои преимущества и недостатки, о чем будет сказано ниже.

Для дублирования данных лучше всего применять журналы транзакций. Они используют встроенные возможности учетной системы для отслеживания изменений в базе данных. Как правило, журналы создаются для резервного копирования и восстановления баз. Здесь хранится вся структура данных и изменения значений. Последние записываются в файл, копируются и передаются в другую (автономную) базу. Этот метод очень удобен для обеих баз, так как не влияет на производительность.

Репликация позволяет быстро передать измененные данные в автономную базу данных. Пользователю достаточно подождать, пока очистится очередь репликации (replication queue): обычно это занимает 10-15 минут. Тем не менее, для корпоративной отчетности такой способ не удобен. Системные ресурсы оперативной базы данных расходуются на обработку репликационных запросов, следующих один за другим. Настройка и поддержка репликации занимает немало времени для многих учетных систем, которые используются для создания корпоративных отчетов.

Настройка и поддержка пакетных программ для дублирования данных очень трудоемка. К тому же, этот метод не использует встроенных возможностей, предоставляемых поставщиками БД, таких как журналы транзакций или репликация баз.



Содержание раздела