В статье В.И. Тихонова «Организация архивного хранения электронных документов: проблемы, практика, рекомендации» классифицированы следующие подходы к архивации ЭД:
Миграция
Заключается в переносе архивируемых данных в новое приложение. Целесообразность в данном случае сомнительна, поскольку для текущих расчетов данные прошлых лет не требуются, а различия в структурах влекут значительное число неопределенностей, разрешаемых преимущественно вручную.
Некоторый личный опыт миграции напоминает, что дело это хлопотное. Обычно историю не перетаскивают, а ограничиваются остатками по счетам (Бухгалтерия), парой-тройкой справок физических лиц (Зарплата). И начинают новую жизнь с первого рабочего дня января.
Конвертация
— преобразование структуры БД в иные формы электронных документов. Т.е. отчетов (форм), генерируемых приложением, в систематизированный набор файлов в любом общепринятом читабельном формате (.txt, .xls, .doc, .pdf).
При высокой частоте отчетности (ежемесячно) и большом количестве подотчетных объектов трудозатраты могут оказаться велики, а управление конечным архивом — затруднительным.
В клинических случаях (не документирована или недоступна структура исходной БД) конвертация с последующим парсингом отчетов может стать единственным способом выгрузки данных (по крайней мере, ясна их семантика).
В базе данных Oracle для анализа содержимого xlsx-отчетов пригодится PL/SQL пакет AS_READ_XLSX, а для массового преобразовать xls в xlsx — утилита Libre Office:
soffice --headless --convert-to xlsx --outdir <папка_назначения> <файл.xls>
Эмуляция и виртуализация
Поскольку любые преобразования не исключают ошибки и потери, неоспоримое достоинство подхода заключается в доступе к оригинальным данным из оригинального приложения. Трудозатраты минимальны, возможны варианты:
- виртуальная машина VirtualBox с FREE DOS. Вспомнил управление памятью, и, после нескольких попыток завел приложение.
- DOSemu на Linux-сервере. Приложение стартовало без каких-либо дополнительных манипуляций. Доступ клиентов по SSH (из Windows с помощью PutTTY, не требующего установки). На клиенте возможен копипаст экранных отчетов и форм в новые документы.
На сервере можно залить зазипованные базы Clipper в iso образ и при запуске приложения деархивировать во временную папку, сохраняя неизменным оригинал. - Dosbox. JS-DOS API: запускаем DOS в браузере / Хабрахабр (не пробовал).
- виртуализация средствами Windows.
Инкапсуляция
— экспорт (выгрузка) БД в структурированные файлы межплатформенных форматов (XML).
Возможен контекстный поиск по XML-документам и просмотр любым браузером. Объемы конечного XML- архива могут существенно вырасти относительно DBF.
Экспорт/импорт таблиц в XML поддерживается большинством СУБД, а средства встроенных языков (DOM, XMLQuery, XSLT) позволяют обрабатывать более сложные структуры.
Экспорт DBF в XML «как есть» — промежуточное решение. Предпочтительней 'отсечь лишнее' и трансформировать реляционную модель в иерархическую (естественную для XML). Отделив данные от представления, можно снабдить XML-файлы стилями или подавать XML на вход генераторам отчетов.
Возвращаюсь к задаче. Предполагался импорт в базу данных основной СУБД организации — Oracle (опять миграция!). Но импорт и слияние баз — пол дела. А дальше что? Снабдить набором отчетов, дублирующим функции и исходного и нового приложения?
Обеими руками за эмуляцию, но готовился к любому развитию событий. Опытные коллеги подсказали: в Oraclе хорошо работает импорт из Access с присоединенными DBF. Есть одно но: DBF-таблицы содержат поля с целыми числами, упакованными в C4. И при различии кодировок… Ну, вы сами понимаете. На этот случай припас PL/SQL пакет импорта таблиц из BLOB.
Пока история не имеет продолжения.
Обновил 15.06.16
Комментарии (6)
eviland
10.06.2016 20:51Т.е. платформу вы уже сменили, а что делать с данными ещё только определяетесь? Отличное планирование.
Критичные данные необходимые вам самим для дальнейшей работы обычно мигрируют прямо в новую систему. Это долго, дорого но абсолютно необходимо.
Менее критичные, но необходимые, например для регулирующих органов данные часто переносят куда-либо на новую платформу и передоставляют доступ в виде репортов. Это часто требует меньше трудозатрат.
Если данные никому не нужны, либо никто в этом не признаётся, тем не менее есть риск ..., то делаются бекапы, архивы и всё переносится на виртуалки. Трудозатраты обычно минимальные.
Я бы начал снизу вверх. Т.е. сделал бы архивы и бекапы, перенёс бы существующую систему на виртуальную машину в любом случае, а вот остальное уже дополнительно и по необходимости.
Далее, есть несколько моментов на которые стоит обратить внимание:
— Как долго у вас будут работать сотрудники, которые разбираются в старой системе? Через некоторое время можется оказаться так, что никто не знает, как старая система работает и где там что найти.
— Сейчас у всех навязчивая идея хранить всё, что только можно, и потом анализировать это, строить отчёты и прогнозы. Делать это проще, если данные будут в какой-либо совсеменной базе данных.
Ну и в итоге it is up to the Customer — сколько человекочасов, а в конечном итоге денег они готовы на это потратить.miktim
11.06.2016 12:34Как вы поняли, ответ оказался сверху.
На ваши первые два абзаца ответ в п1. Новая система работает более 2-х лет. К ее эксплуатации отношения не имею.
Мой п2 не в тему. Относится к перетаскиванию всех данных, нажитых непосильным трудом пользователей, в новую среду.
Остальное более-менее по сути вашего коммента.
Относительно регулирующих органов:
бывают ситуации, когда штатными отчетами (которые есть и в старом работающем приложении) их не удовлетворишь.
Тут все упирается в недокументированную структуру БД сторонних разработчиков. Да — разбирался, сопоставляя экранные формы с dbf, но все ли понял правильно — вопрос открытый.
А точно зная структуру, стоит ли стрелять из пушки Oracle (или иной современной СУБД) по Clipper воробьям? Зацепи Access'ом или DB либры, ну перестрой NTX индексы в IDX на свой вкус для ускорения выборки. Датамайни в свое удовольствие.
Сейчас, правда, мало кто в курсе технологий прошлого тысячелетия.
Слияние данных — отдельная история, об этом я упоминал.
Перенос в Oracle вопрос не денег и человекочасов, а требований заказчик (конечных пользователей организации) и сформулированной задачи. Без этого, просто ради современных технологий, не стоит затеваться.
Я так думаю, а вы?
beerchaser
13.06.2016 08:39Согласен с eviland. Сам на руках имею такую же проблему. Жизненный цикл ПО завершен 10 лет назад. Людей, которые помнят как работать с системой, уже не осталось — только смутные отрывочные знания. Необходимость/ частота обращений -1-2раза вгод. Реверсом заниматься некому.
Склоняюсь к тому, чтобы сформировать максимальное количество отчетов с возможностью контекстного поиска и похоронить систему.miktim
13.06.2016 10:47Может быть, торжественно похоронить все? С актом за подписями первых лиц и печатями.
Не гипотетическая ситуация: есть отчет из базы данных, а есть отчет подправленный заботливыми руками исполнителя, но с подписями и печатями. Где юридически значимые данные? А где достоверные? Наверное, для ручной правки были основания.
И поди разберись, что там было n-лет назад.
miktim
1. Данные в новую систему перенесены в необходимом объеме. Это следует из текста.
2. Долго, дорого и абсолютно необязательно.Старая система как работала, так и работает. Насколько я знаю, ею пользуются справочно. Здесь приведены альтернативные варианты.
3. Действительно, инструкции по эксплуатации старой системы я не видел (это не означает, что ее нет). Но я так же не видел описания структуры базы данных: ее просто нет. Предполагаю, что от базы к базе она существенно изменилась за десять лет.
4. В виде zip все помещается на DVD. Трепетно отношусь к данным, хотя вы правы — процедура утилизации нужна.
5. Проще != рациональней (см п2).
Я несправедлив к инкапсуляции, как к вероятному продолжению истории. Исправляю.