migration - RMS から RDB への移行

Question

従来の OpenVMS RMS ファイルをリレーショナル データベースに移行しようとしています (MS SQL 2012 と Oracle 10g の両方が利用可能です)。私はあるのだろうか：

• インデックス付きファイルのスキーマを取得するツール
• インデックス付きファイルを解析するツール
• カスタム RMS データ形式 (ゾーン 10 進数など) をバンドル/API/ライブラリとして処理するためのツール おそらくアプローチを変更する必要がありますか?

Answer 1

いくつかのツールが利用できますが、特に ODBC ベンダー (私は Attunity で働いています) を通じて入手できます。

1 >> 索引ファイルのスキーマを取得するツール

どうか明らかにしてください。ファイル内のレコード/列のレイアウトとインデックス、またはファイル間の関係だけを探しています。

1a) ファイルは現在どのように使用されていますか? Cobol、Basic、Fortran プログラム? データトリーブ？彼らは何らかのデータ定義方法を使用するため、それを利用できるツールが必要です。Connx、および Attunity Connect は、CDD 定義、BASIC - MAP ファイル、Cobol コピーブックを「インポート」できます。通常、バリアントも対象となります。特殊な定義を XML に変換する (perl/awk) スクリプトを多数作成しました。

1b ) Analyze/RMS、または RMS XAB を呼び出すプログラムは、利用可能なインデックス情報を取得できます。Atunity connect は、これらを 1a) のフィールドにマッピングする方法を認識します。

1c ) OpenVMS 上の (索引付けされた) ファイル間には、正式な保存された関係はありません。それはすべてプログラムロジックにあります。ただし、適度にスマートな Perl/Awk/DCL スクリプトの中には、ファイル名とデータ型の一致を調べることで、可能性のある外部キー/主キーのテーブルを生成できるものがあります。

何個のファイル / レイアウト / ギガバイトについて話しているのですか?

2 >> 索引ファイルを解析するためのツール

どうか明らかにしてください？構造がわかったら (質問 1)、その構造を使用して読み取ることによって解析が行われますよね? インデックス化されたファイルの内部を理解したいと思うことは決してありません。RMS にレコードをフェッチするように指示するだけです。

3 >> カスタム RMS データ形式 (ゾーン 10 進数など) をバンドル/API/ライブラリとして処理するツール

もう一度、明確にしてください。構造がわかったら、「適切な」ツールを使用してその構造を使用して読み取るだけで、詳細なデータ定義が確実に尊重されます。

(業界に何かあると思っただけで、自分で書くのはとても簡単だと思います)

有名な最後の言葉...「とてもシンプル」。企業全体が、一般的なケースでまさにそれを行って構築され、繁栄しています。特定のケースについては、比較的簡単にできることは認めますが、「悪魔は細部に宿る」のです。

Attunity Connect のケースでは、多くの場合 DATES を含む「奇妙な」ケースを処理するための UDT (ユーザー定義データ型) があります。xxx以降の整数、文字列、単位の日付はすべてすぐに使用できますが、たとえば、DBに保存するために何らかの助けが必要な「いくつかの高い日付」を意味する-1を持つものもあります。

すべてのデータベースには、バルク ロード ツール (BCP、SQL$LOADER) があります。それらが期待するもの (表形式、コンマ区切り、引用するかしないか、エスケープするかしないか) に準拠したデータを提供できる限り、あなたは良い状態にあるはずです。

EGH ツールの Vselect は、インデックス付きファイルを一括読み取りし、一部をフィルタリングしてフォーマットし、DB ローダー用のシーケンシャル ファイルを吐き出す便利で高性能な方法です。RMS よりも高速に RMS インデックス ファイルを読み取ることができます。(ただし、独自のメタデータ言語があります!)

Attunity は、フル アクセスとレプリケーション サービスを提供します。それらには、データをロードするだけでなく、ほぼリアルタイムで最新の状態に保つための CDC (変更データ キャプチャ) が含まれています。これは、「進化」対「革命」に役立ちます。Attunity 'Replicate' をチェックしてください。データ ディクショナリを作成したら、必要なテーブル (包含、除外フィルター) をポイントし、ターゲット DB をポイントして、クリックして複製します。もちろん、(グローバルまたはテーブルごとの) 変換のオプションがあります (単一の電話番号への AREA-CODE+EXHANGE+NUMBER、または変更された日付列の追加など)。

これは単一の大きなスイッチ変換でしょうか? それとも、データを移行して古いシステムを何日、何ヶ月、何年も維持し、その間ずっとデータを緊密に同期させたいという願望がありますか?

Hein van den Heuvelさん、これがお役に立てば幸いです。

Answer 2

OP:アプローチを変えた方がいいのではないでしょうか? おそらく。

データ移行ベンダーを見つけることを検討してください。COTS ツールとしてではなくても、既製のソリューションを提供している可能性が高く、サービスとしてパッケージ化されている可能性が高いです (これは大きな市場ではないと思います)。

これが役に立たないのは、アプリケーション コードのより大きな問題として私が考えるものです: リレーショナル DB 呼び出しを行う対応するコードで、RMS 呼び出しを行うすべてのコードを誰が変更するのでしょうか? エンティティ (「Joe Programmer」または何らかのツール) は、どのようにしてデータの移行先を知り、正しい呼び出しを作成できるでしょうか? データ表現が変化しているという事実について、あなたは何をしていますか?

理想的には、自動化された移行ツールが必要です。これは、データ自体を移動し (したがって、データのレイアウトと表現の変更を認識します)、対応するコードの変更を行います。この種のベンダーも探すことができます。