ソースとターゲットが大きく異なるため、これは非常に難しい作業です。列が空または null であっても、新しいテーブルに列がないことをツールが理解するのは容易ではありません。ソース列のデータを分析し、それらすべての値が型に対応しているかどうかを確認し (ただし、事前に多くの型をテストする必要があります)、マッチングを実行する必要があるため、キャストも困難です。
おそらく、ソース テーブルとターゲット テーブルの列名が同じであれば、作業はより簡単になる可能性があります。名前を一致させてから、データを挿入するだけです。
この状況を分析した結果、このケースではメタデータはあまり役に立たないという結論に達しました。これは、移行によってテーブルのプロパティが大幅に変更されるためです。ほとんどの場合、移行はメタデータに基づいていますが、そのほとんどすべてを変更しているため、カタログ データベースはほとんど役に立ちません。また、多くのツールは、データ自体ではなく、メタデータに知識を基にしています。
他の型の値を入れることができる最も一般的なデータ型である varchar から取得しており、データに応じて適切なデータ型を割り当てることでストレージを最適化したいが、関係の整合性のためにも行う必要がある; つまり、関係の主キーである列のデータ型は、データ型だけでなく精度も、他のテーブルの外部キーと一致する必要があります。この最後の問題は余分な問題であり、関係の整合性が保たれていることを願っています。
あなたが探しているほどインテリジェントなツールを私は知りません。ただし、手動で作業することをお勧めします。まず、列名のポリシーを検出してみてください。つまり、列がaddressと呼ばれる場合、すべてのテーブルで 64 の varchar であることがわかります。price と呼ばれる列は、すべてのテーブルで double の列になる可能性があります。この列名の辞書式分析を行うだけで、モデルを標準化できます。ただし、その名前のすべての列の値がその列の精度で「入力」されているかどうかを確認する必要があります。この最後の部分は、すべてのテーブルから値を読み取り、日付タイプごとに最も長い値を探す必要があるため、非常に時間のかかるプロセスです。