Мы приближаемся к миграции устаревших файлов OpenVMS RMS в реляционную базу данных (доступны как MS SQL 2012, так и Oracle 10g). Интересно, есть ли:
Доступно несколько инструментов, в частности, через поставщиков ODBC (я работаю на одного из них: Attunity).
1 >> Инструменты для получения схемы индексированных файлов
Просьба уточнить. Ищете только макет записи/столбца и индексы в файлах, а также отношения между файлами.
1a) Как сейчас используются файлы? Программы Cobol, Basic, Fortran? Сбор данных? Они будут использовать какой-то метод определения данных, поэтому вам нужен инструмент, который может использовать это. Connx и Attunity Connect могут «импортировать» определения CDD, файлы BASIC — MAP, тетради Cobol. Варианты также обычно рассматриваются. Я написал много скриптов (perl/awk) для преобразования специального определения в XML.
1b) Analyze/RMS, или программа с вызовом RMS XAB может получить доступную информацию индекса. Atunity connect будет знать, как сопоставить их с полями из 1a)
1c) Между (индексированными) файлами в OpenVMS нет формальной, сохраненной связи. Это все в логике программы. Однако некоторые скромно умные сценарии Perl/Awk/DCL часто могут генерировать таблицу вероятных внешних/первичных ключей, просматривая имена полей и совпадения типов данных.
О каком количестве файлов/макетов/гигабайт идет речь?
2 >> Инструменты для анализа индексированных файлов
Просьба уточнить? Как только структура известна (вопрос 1), синтаксический анализ выполняется путем чтения с использованием этой структуры, верно? Вы никогда не захотите разбираться во внутреннем устройстве индексированного файла. Просто скажите RMS, чтобы получить записи.
3 >> Инструменты для работы с пользовательскими форматами данных RMS (зонированные десятичные числа и т. д.) в виде пакета/API/библиотеки
Еще раз прошу пояснить. Как только структура известна, просто используйте «правильный» инструмент для чтения с использованием этой структуры, и, безусловно, он будет учитывать подробные определения данных.
(Я знаю, что написать его самостоятельно довольно просто, просто подумал, что в отрасли будет что-то подобное)
Знаменитые последние слова... "довольно просто". Целые компании были построены и процветают, делая только это для общих случаев. Я допускаю, что для конкретных случаев это может быть относительно просто, но «дьявол кроется в деталях».
В случае Attunity Connect у нас есть UDT (пользовательский тип данных) для обработки «нечетных» случаев, часто связанных с ДАТАМИ. Даты в целых числах, в строках, в виде единиц измерения, начиная с xxx, доступны из коробки, но, например, у некоторых есть -1, означающее «какая-то высокая дата», которая требует некоторой помощи для хранения в БД.
Во всех базах данных есть инструмент массовой загрузки (BCP, SQL$LOADER). Пока вы можете предоставлять данные, соответствующие их ожиданиям (табличные, с разделителями-запятыми, в кавычках или без, с экранированием или без), вы должны быть в хорошей форме.
Инструмент EGH Vselect может быть удобным и высокопроизводительным способом массового чтения индексированных файлов, фильтрации и форматирования некоторых и выдачи последовательных файлов для загрузчиков БД. Он может читать индексированный файл RMS быстрее, чем RMS! (Хотя у него есть собственный язык метаданных!)
Attunity предлагает услуги полного доступа и репликации. Они включают в себя CDC (сбор данных об изменениях), чтобы не только загружать данные, но и поддерживать их в актуальном состоянии почти в реальном времени. Это полезно для «эволюции» и «революции». Проверьте Attunity 'Replicate'. Когда у вас есть словарь данных, просто укажите нужные таблицы (включить, исключить фильтры), укажите на целевую БД и щелкните, чтобы реплицировать. Конечно, есть варианты преобразования (глобальные или для каждой таблицы) (например, КОД ОБЛАСТИ+ОБМЕН+НОМЕР в один номер телефона или добавление измененных столбцов даты).
Будет ли это одно большое преобразование коммутатора, или есть желание перенести данные и сохранить старые системы в течение нескольких дней, месяцев, возможно, лет, сохраняя при этом данные в точной синхронизации?
Надеюсь, это поможет некоторым, Хайн ван ден Хевел.
ОП: Возможно, мне следует изменить подход? Возможно.
Вы можете подумать о том, чтобы найти поставщиков миграции данных, некоторые из которых, вероятно, имеют готовые решения, если не в виде COTS-инструмента, скорее, в виде услуги (я не думаю, что это большой рынок).
В чем это вам не поможет, так это в том, что я считаю гораздо более серьезной проблемой с кодом приложения: кто собирается менять весь код, выполняющий вызовы RMS, в соответствующий код, выполняющий вызовы реляционной БД? Как объект ("Джо Программист" или какой-либо инструмент) узнает, куда данные перенесены куда, чтобы он мог написать правильный вызов? Что вы делаете для того, чтобы изменить представление данных?
В идеале вам нужен автоматический инструмент миграции, который будет перемещать сами данные (поэтому знает, что макеты данных и представления меняются) и будет вносить соответствующие изменения в код. Таких продавцов тоже можно поискать.
