JPH08190479A - データベース移行方式 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 データ形式、文字コード、数字データ等が異
なるデータベース間のデータ移行システムにおいて、デ
ータ定義体等のレコードおよびフィールドの正確な情報
がない場合においてもそれらの候補の自動生成、決定の
ための支援、検証を行うデータベース移行方式を提供す
る。 【構成】 移行元データベース１０とバイトパターン種
別の集合１１を与えて、データベース内の各バイトの所
属集合の統計をとるステップと、それをもとにレコード
およびフィールド情報１６の解析を行い、移行元データ
定義体と移行先データ定義体を生成するステップと、移
行元データ定義体、移行先データ定義体をもとに移行元
データベースのデータ形式、文字コード、数字データ等
を変換するステップを備えている。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は情報処理システム上に
構築されたデータベースシステムにおいて、その利用形
態の変更に伴い、データ形式、文字コード、数字表現形
式等が異なるデータベースへ移行する際のデータ変換技
術に関するものである。

【０００２】

【従来の技術】従来、データ形式、文字コード、数字表
現などが異なるデータベース間においてデータを変換し
て移行しようとした場合、それぞれのレコード内のフィ
ールドのデータタイプに応じたデータ変換が必要であ
り、そのためには、フィールドの境界位置およびフィー
ルドのデータタイプを、ソースプログラム、データ定義
体から得るか、若しくは、それらが存在しない場合に
は、データのダンプ表現から技術者が判断して得る必要
があった。

【０００３】たとえば、特開平３−２４２７２７号公報
に示された「計算機システムの新旧交換時における移行
システム」や、特開平４−４０５５５号公報に示された
「移行資産難易度評価装置」では、ソースプログラム、
定義体、ＪＣＬ、データといったユーザ資産をシステム
としてトータルに移行するシステムが示されている。

【０００４】定義体にはレコード内のフィールド位置、
データタイプが記述されており、それに基づいて、変換
すべきデータの情報を得ることができる。

【０００５】ソースプログラムには、例えばＣＯＢＯＬ
のように、すべてのフィールド情報を指定する必要はな
いため、必ずしも１箇所にすべての情報が存在している
わけではないが、ソースプログラムの集合を解析するこ
とによりその情報を自動的に得ることは不可能ではな
い。しかし、正確な情報を自動的に得ることは困難であ
る。

【０００６】

【発明が解決しようとする課題】データ定義体を用いて
フィールド情報を得るためには、データ定義体とデータ
ベースの対応が確定している必要がある。近年のＳＱＬ
に代表される関係型データベースでは、データ定義体は
必須であり、実際のデータベースとの関連付けもなされ
ている。しかし、ＣＯＢＯＬに代表されるファイルを基
本とするデータベースでは、データ定義体は必ずしも必
要ではなく、寧ろ存在しないことも多く、データ移行時
に利用することができないという問題点があった。

【０００７】ソースプログラムには、フィールド情報が
定義されるが、必要フィールドの定義のみで十分であ
る。また、実際に格納されているフィールド境界とは関
係なく一括して読み込んだり、異なるデータタイプとし
て読み込むことも可能である。そのような場合は、関連
するソースプログラムをすべて解析しても、矛盾してい
たり、情報が損失していることがあり、完全なフィール
ド情報を取り出すことは非常に困難であるという問題点
があった。

【０００８】また、アプリケーションプログラムによっ
ては、ソースプログラムの管理が十分になされていな
く、オブジェクトコードのみで運用されている場合も多
い。そのような場合は、経験の豊富な技術者が実際にデ
ータベースの内容を覗いて判断しなければならないとい
う問題点があった。

【０００９】本発明はこのような問題点を解決するため
になされたもので、データ定義体が存在しない場合、ま
たはソースプログラムが存在していても十分な情報が得
られない場合、もしくはソースプログラムが存在しない
場合において、データ形式や文字コード、数字形式等が
異なるデータベースシステムへデータを移行する際にお
けるレコード、フィールドの境界およびそのデータタイ
プの候補提供、決定のための支援、および候補の検証を
可能としたデータベース移行方式を提供することを目的
とする。

【００１０】

【課題を解決するための手段】第１の発明に係わるデー
タベース移行方式は、移行元データベースのバイトパタ
ーンを定義したバイトパターン集合定義体と、バイトパ
ターン集合定義体情報に基づいてデータベースのレコー
ド長候補を選定するレコード長候補選定手段と、候補選
定されたレコード長とバイトパターン集合定義体に基づ
いてレコード内におけるバイトパターンのレコード内オ
フセット位置ごとの出現頻度を算出する出現頻度算出手
段とを備えるようにしたものである。

【００１１】第２の発明は、第１の発明におけるデータ
ベース移行方式において、レコード内におけるバイトパ
ターンのオフセット位置ごとの出現頻度情報の視覚表示
手段を備えるようにしたものである。

【００１２】第３の発明に係わるデータベース移行方式
は、移行元データベースのバイトパターンを定義したバ
イトパターン集合定義体と、バイトパターン集合定義体
情報に基づいてデータベースのレコード長候補を選定す
るレコード長候補選定手段と、候補選定されたレコード
長ごとにバイトパターンを解析しレコードを構成するバ
イトパターン種別および該バイトパターンのレコード内
オフセット位置情報に基づいて同一バイトパターン構造
を有するレコードの出現頻度を集計するレコードパター
ン集計手段とを備えるようにしたものである。

【００１３】第４の発明に係わるデータベース移行方式
は、移行元データベースのバイトパターンを定義したバ
イトパターン集合定義体と、バイトパターン集合定義体
情報に基づいてデータベースのレコード長候補を選定す
るレコード長候補選定手段と、候補選定されたレコード
長に基づいてレコード内オフセット位置ごとに所属する
バイトパターン集合からなる集合を算出し集合の変化点
に着目してレコードを構成するフィールド候補を出力す
るフィールド解析手段とを備えるようにしたものであ
る。

【００１４】第５の発明は第４の発明に係わるデータベ
ース移行方式において、バイトパターン集合からなる集
合とデータタイプの対応付けを記載した推論規則定義体
を備え、推論規則定義体情報とフィールド解析手段が出
力したフィールド候補情報に基づいてフィールド境界お
よび該フィールドのデータタイプを推論するフィールド
推論手段を備えるようにしたものである。

【００１５】第６の発明は第１乃至第５の発明に係わる
データベース移行方式において、移行元データベースの
レコードを構成するフィールド境界および各フィールド
のデータタイプ選定候補結果に基づいて移行元データベ
ースのバイトパターンを解析し、指定したバイトパター
ン種別のレコード内オフセット位置に関する整合性を確
認する検証手段を備えるようにしたものである。

【００１６】第７の発明は第１乃至第６の発明に係わる
データベース移行方式において、移行先データベースの
文字コード等によりデータ長が伸縮する文字集合に対し
てはフィールド長補正を行なった後に移行先のフィール
ド長候補を決定するフィールド候補自動決定手段を備え
るようにしたものである。

【００１７】

【作用】この発明におけるデータベース移行方式では、
バイトパターン集合定義体に基づいてファイル内のバイ
トパターンを解析しレコード長候補を選定し、候補指定
されたレコードに対してレコード内におけるバイトパタ
ーンのオフセット位置ごとの出現頻度を算出する。

【００１８】また、この第２の発明は第１の発明におけ
るデータベース移行方式において、レコード内における
バイトパターンのオフセット位置ごとの出現頻度情報を
視覚表示する。

【００１９】また、この第３の発明におけるデータベー
ス移行方式では、バイトパターン集合定義体に基づいて
データベースのレコード長候補を選定し、候補指定され
たレコード長ごとにバイトパターンを解析してレコード
を構成するバイトパターン種別および該バイトパターン
のレコード内オフセット位置に基づいて同一バイトパタ
ーンで構成されるレコードの出現頻度を集計する。

【００２０】また、この第４の発明におけるデータベー
ス移行方式では、バイトパターン集合定義体情報に基づ
いてデータベースのレコード長候補を選定し、候補指定
されたレコード長に基づいてレコード内オフセット位置
ごとに所属するバイトパターン集合からなる集合を算出
し、集合の変化点に着目してレコードを構成するフィー
ルド候補を出力する。

【００２１】また、この第５の発明は第４の発明におけ
るデータベース移行方式において、バイトパターン集合
からなる集合とデータタイプの対応付けを記載した推論
規則定義体情報とフィールド候補情報に基づいて、フィ
ールド境界および該フィールドのデータタイプを推論す
る。

【００２２】また、この第６の発明は第１乃至第５の発
明におけるデータベース移行方式において、 移行元デ
ータベースのレコードを構成するフィールド境界および
各フィールドのデータタイプ候補に基づいて移行元デー
タベースのレコード単位にバイトパターンを解析し、候
補選択結果に対する正確さの検証を行なう。

【００２３】また、この第７の発明は第１乃至第６の発
明におけるデータベース移行方式において、移行先デー
タベースの文字コード等によりデータ長が伸縮する文字
集合に対してフィールド長補正処理を行なった後に移行
先のフィールド長候補を決定する。

【００２４】

【実施例】

実施例１．図１は、本発明の実施例全体の概略を示すブ
ロック図である。本発明の第１の実施例では移行元デー
タベース１０とバイトパターン集合１１を入力として、
その情報を解析してレコード長候補１２を出力した後、
ステップ１４−１にてフィールド情報決定のための頻度
情報を算出し、ステップ１５−１においてシステムエン
ジニアが判断／解析を支援してフィールド情報を出力す
る。

【００２５】以下に、第１の実施例を図２乃至図４のフ
ローチャートに基づいて詳しく説明する。図２におい
て、２０は入力データのバイトパターン集合であり、取
り扱う言語のデータタイプ、数字データ形式、文字コー
ドによって規定されるものとする。たとえば、 ０：英数字 １：半角カナ ２：十進数 ３：パック形式十進数 ４：スペース ５：漢字 というように与えることができる。対応するバイト集合
は、文字コード等に依存する。例えば、シフトＪＩＳコ
ードの場合、０：英数字は１６進数（１バイト）で２０
−７Ｃ、１：半角カナはａｌ−ｆｃ、２：十進数は数字
に対応する文字コード（１バイト）と最小桁の符号ビッ
トを合わせて３０−３９，７０−７９、３：パック形式
十進数は１バイトを４ビットづつに分けた０から９まで
と符号の組み合わせになる。一般にあるバイトが与えら
れた場合、それが所属する集合は、必ずしも一つとは限
らない。

【００２６】２１は入力される移行元データベースを示
し、固定長形式に限り、データ部の長さはファイルの大
きさから得ることができるものと仮定する。ここでは、
実施例説明のために、以下に示すデータベースを想定す
る。便宜上、フィールドごとに区切って示すが、この時
点では、レコード長、フィールド長、データタイプは未
だ不明であるとする。Ｘ（５）は文字タイプで長さ５バ
イト、Ｐ９（３）はパック形式十進数３桁（２バイト）
を意味する。また１０進数の上位は、０を詰めるものと
する。 部品ＩＤ 構成部品ＩＤ 個数 Ｘ（５） Ｘ（５） Ｐ９（３） ──────────────────── A0LC C9X 18 BA1C D05Z 223 C9X EA14A 9

【００２７】ステップ２２では、移行元のデータベース
ファイル２１をバイトごとに読み込み、所属バイトパタ
ーン２０を対応させ、所属バイトパターン集合列を出力
する。この所属バイトパターンの対応は移行元ファイル
全てに対して適用する必要はなく、時間、空間、候補の
正確度の要求のトレードオフによって適用範囲を適宜決
定すればよい。この例の場合、 0 1 2 3 4 5 6 7 8 9 10 11 {0},{0,2},{0},{0},{0,4},{0},{0,2},{0},{0,4},{0,4},{3},{3,5}, A O L C C 9 X 01 8f 12 13 14 15 16 17 18 19 20 21 22 23 {0},{0},{0,2},{0},{0,4},{0},{0,2},{0,2},{0},{0,4},{0,3},{0,3}, B A 1 C D 0 5 Z 22 3f 24 25 26 27 28 29 30 31 32 33 34 35 {0},{0,2},{0},{0,4},{0,4},{0},{0},{0,2},{0,2},{0},{3},{3,5} C 9 X Z A 1 4 A 00 9f という列が得られる。尚、上記文字列は移行元ファイル
２１におけるバイトオフセット位置、所属バイトパター
ン集合列、入力データの順に示してある。

【００２８】次に、ステップ２４にてレコード長候補を
決定する。ステップ２４のレコード長候補決定の詳細フ
ローチャートを図３に示す。まず、ステップ３０で上記
入力データを所属バイトパターン集合（0:英数字、1:半
角カナ、2:十進数、3:パック形式十進数、4:スペース、
5:漢字）ごとに、その出現位置を展開する。上記の入力
データ例では、バイトパターンは下記で示されるオフセ
ット位置に出現していることが分かる。 ハ゛イトハ゜ターン オフセット 位置 0: 1,2,3,4,5,6,7,8,9,12,13,14,15,16,17,18,19,20,21,22,23, 24,25,26,27,28,29,30,31,32,33 1: 2: 1,6,14,18,19,25,31,32 3: 10,11,22,23,34,35 4: 4,8,9,16,21,27,28 5: 11,35

【００２９】次に、全てのバイトパターンについてその
周期性を解析する。まず、ステップ３１にてバイトパタ
ーンを１つ選択し、解析の処理であるステップ３２〜３
３に入る。ステップ３２では、出現バイト位置の間隔お
よびファイル長の約数より周期性を解析する。この例で
は、ファイル長が３６であるためその約数である１，
２，３，４，６，９，１２，１８，３６をレコード長候
補として、その間隔に適用する。例えば、３のパック形
式十進数では１０に１を足すと１１となり該当するが、
さらに１を足すと該当しなくなる。同様に１０に２，
３，４，９を足してもその位置にはパック形式十進数は
なく該当しない。さらに、１０に１２を足すと２２、ま
た２２に１２を足すと３４となり、いずれもパック形式
十進数に該当しその周期性を抽出することができるの
で、結局１２が候補となる。同様にして、ステップ３３
にてバイトパターンごとに候補を登録する。ステップ３
４で次のバイトパターン集合に進み、全てのバイトパタ
ーンに対して処理が終了すると、ステップ３５に進む。

【００３０】ステップ３５では、それぞれのバイトパタ
ーン集合から導かれた候補を解析する。それらの和集合
がレコード長候補となり得る。その中からの選択方針と
して、たとえば、最も候補として多くあげられたものの
うち最小のものを選択するという方式が考えられる。こ
の例の場合、英数字”０”，パック形式十進数”３”，
スペース”４”の４つのバイトパターンタイプで候補と
してあげられる１２が選択される。以上のようにして、
図２のステップ２４でレコード長候補が決定される。

【００３１】ステップ２４にて決定されるレコード長候
補２５と所属バイトパターン集合列に基づいて、ステッ
プ２６ではレコード単位に解析を行ない、レコード内オ
フセット位置ごとの出現頻度情報２７を出力する。この
例の場合、 となる。次にステップ２８で、出現頻度情報を視覚的に
表示して、フィールド情報決定を支援する。例えば、図
４に示すようにグラフ表現を行なうと、システムエンジ
ニアは次のような推論を行なうことができる。

【００３２】（１）バイト位置１，２，６，７，８では
数字が出現しているが、１００％ではないので、データ
タイプは数字タイプではない。 （２）バイト位置１１は、文字データが１００％ではな
いのでパック形式十進数である。また、その隣のバイト
位置１０は文字データの可能性もあるが、バイト位置１
１の関係からパック形式十進数であると考えられる。 （３）バイト位置が３→４および８→９にかけてスペー
スの割合が増加しているので、４と５の間および９と１
０の間にフィールドの切れ目がある可能性が高い。

【００３３】これらの判断材料から、システムエンジニ
アは次の候補を導き出すことができる。 レコード長：１２バイト フィールド情報： 0-4 文字列タイプ 長さ ５バイト 5-9 文字列タイプ 長さ ５バイト 10-11 パック形式十進数 長さ ２バイト ただし、ここまでの経過では、パック形式十進数が２桁
か３桁かの判断はできないが、バイトパターン集合をパ
ック形式十進数の上位４ビットまで厳密に定義すれば判
断が可能となる。

【００３４】図５は、図３にて示したレコード長候補決
定のためのフローチャートの詳細である。ステップ１０
１の判定処理で、バイトパターン集合の各要素に対し、
それに所属するファイル内のバイトのオフセットを要素
とする集合を得ることができる。ここでは、その集合
を、Ｂi （ｉ＝１，２，３，…）、その要素をＢij（ｊ
＝１，２，３，…）（Ｂi1＜Ｂi2＜Ｂi3＜…）とする。

【００３５】ステップ１０３では、変数ｉに初期値を与
え、ステップ１０４ではｉに１を加える。

【００３６】ステップ１０５は、Ｂi が有効な集合を示
すものであるか否かを検査する。Ｂi が有効でない場合
には、ステップ１０６から１１８までの処理が全てのＢ
i （ｉ＝１，２，３，…）に対して行なわれたことを示
し、ステップ１１９に進む。

【００３７】Ｂi が有効である場合には、ステップ１０
６に進む。ステップ１０６では、Ｒi のただ一つの要素
としてファイル長を設定する。Ｒi は、Ｂi に関するス
テップ１０７から１１８の処理によって得られるレコー
ド長候補の集合である。ファイルがただ一つのレコード
からなる可能性は常にあるので、ファイル長は常にレコ
ード長候補となり得る。

【００３８】ステップ１０７では、変数であるｊに初期
値を与え、ステップ１０８ではｊに１を加える。

【００３９】ステップ１０９では、Ｂijが有効な要素を
示すものであるか否かを検査する。Ｂijが有効でない場
合には、ステップ１１０から１１８までの処理が全ての
Ｂij（ｊ＝１，２，３…）に対して行なわれたことを示
し、次のＢi を処理するためステップ１０４に進む。

【００４０】Ｂijが有効である場合には、ステップ１１
０でＢij−Ｂi1の値を変数Ｒに設定する。Ｒはレコード
長の候補として検査される値である。

【００４１】ステップ１１１では、Ｒがファイル長の約
数であるかどうかを検査する。Ｒがレコード長であるな
らば、Ｒはファイル長の約数である。Ｒがファイル長の
約数でない場合には、Ｒはレコード長ではあり得ないの
で、次のＢijの処理を処理するため、ステップ１０８に
進む。

【００４２】Ｒがファイル長の約数である場合には、Ｒ
はレコード長である可能性があり、ステップ１１２から
ステップ１１８の処理を行なう。

【００４３】ここで、もしＲがレコード長として有効で
あるならば、ファイル内でＢi1からＲの整数倍離れたバ
イトもＢi の要素である可能性が高い。これを利用し、
Ｒの検査を行なう。

【００４４】まずステップ１１２で変数であるＸにＢij
を設定する。次にステップ１１３ではＸにＲを加える。
したがって、Ｘは、Ｂi1からＲの整数倍離れたバイトを
示す。また、ステップ１１２では変数であるＮに０を設
定する。Ｎは、このようなバイトがＢi の要素であった
数を表わす。

【００４５】ステップ１１４では、Ｘをファイル長と比
較し、Ｘが有効な値であるかどうかを検査する。

【００４６】Ｘが有効な値であった場合には、ステップ
１１５に進み、Ｘが示すバイトがＢi の要素であるかど
うかを判定し、Ｂi の要素であった場合には、ステップ
１１６でＮに１を加える。

【００４７】ステップ１１４で、Ｘが有効な値でない場
合には、ステップ１１５，１１６の処理が可能な全ての
Ｘの値について検査が終了したと判断し、ステップ１１
７に進む。

【００４８】ステップ１１７では、ステップ１１８でＲ
をＲi の要素として加えるかどうかを判定するために、
Ｎが１以上かどうかを判定する。１以上であった場合に
は、ステップ１１８でＲをＲi の要素として加える。そ
して、次のＢijに関する判定を行なうために、ステップ
１０８に進む。

【００４９】ステップ１０５で、全てのＢi についてこ
の処理が終了したことが判断された場合には、ステップ
１１９で、全てのＲi の要素の和集合の要素を、レコー
ド長の候補として保存する。

【００５０】なお、この実施例ではステップ１１０でＢ
i1のみを用いてステップ１１１から１１８の処理を行な
っているが、Ｂi2以降の要素でもよく、また、複数の要
素を用いて同様の処理を行なってもよい。

【００５１】また、この実施例ではステップ１１８でＲ
をＲi に加えるかどうかを判断するために、ステップ１
１７でＮの値が１以上かどうかを判定しているが、この
値は必ずしも１である必要はない。また、Ｂi 毎に異な
る値であってもよい。

【００５２】さらに、この実施例ではステップ１１８で
ＲのみをＲi に記憶し、ステップ１１９でその和集合を
候補としているが、ステップ１１８でＮをＲと同様に記
憶し、ステップ１１９でその情報を保存してもよい。こ
れは、後のレコード長決定に役立てることができる。

【００５３】この実施例によれば、バイトパターン集合
定義体に基づいてファイル内のバイトパターンを解析し
レコード長候補を選定し、候補指定されたレコードに対
してレコード内におけるバイトパターンのオフセット位
置ごとの出現頻度を算出するようにしたので、ファイル
データ定義体およびソースプログラムの情報が十分でな
い場合においても、データ形式の異なるデータベース間
でデータ移行を実現することできるという効果がある。
また、ファイル構造の解析結果をグラフ等を使用して視
覚的に表示するようにしたので、フィールド境界やデー
タタイプの評価及び決定支援をユーザが容易に行なうこ
とができるという効果がある。

【００５４】実施例２．この発明の第２の実施例は、図
１の全体概要図のステップ１２で候補選定されたレコー
ド長候補に対し、レコードを構成するフィールドパター
ンごとに同一パターン構造をとるレコードの出現回数を
解析（ステップ１４ー２）して、システムエンジニアに
よるフィールド長、フィールドタイプ決定を支援するよ
うにしたものである。

【００５５】以下に、第２の実施例を図６に示すフロー
チャートに基づいて説明する。まず、ステップ６１にて
実施例１によって得られた所属バイトパターン集合列２
３をレコード長候補２５ごとに区切って読み込む。この
ようにして得られるレコードのバイト位置ごとの所属バ
イトパターン集合列は、実施例１における例を用いると
以下のようになる。 0 1 2 3 4 5 6 7 8 9 10 11 {0},{0,2},{0},{0},{0,4},{0},{0,2},{0},{0,4},{0,4},{3},{3,5}, A O L C C 9 X 01 8f {0},{0},{0,2},{0},{0,4},{0},{0,2},{0,2},{0},{0,4},{0,3},{0,3}, B A 1 C D 0 5 Z 22 3f {0},{0,2},{0},{0,4},{0,4},{0},{0},{0,2},{0,2},{0},{3},{3,5} C 9 X Z A 1 4 A 00 9f ・ ・ ・ ここでは、３レコードの例を示したが、一般のデータベ
ースでは、膨大な量になり、それをすべて解析すること
は非常に困難である。ここでは、出現回数によってデー
タを整理して表示する。

【００５６】まず、ステップ６２で読み込んだパターン
ごとの出現回数を求める。すなわち、レコードのバイト
位置ごとの所属バイトパターン集合列を、同一のパター
ンごとに数え上げ、それぞれの出現回数をもとめる。次
にステップ６３において、出現回数によってソートされ
た所属バイトパターン集合列を表示し、システムエンジ
ニアによるフィールド長およびフィールドタイプの決定
の支援を行なう（ステップ６４）。

【００５７】たとえば、 0 1 2 3 4 5 6 7 8 9 10 11 出現回数{ 0},{0,2},{0}, {0},{0,4},{0},{0,2}, {0}, {0,4},{0,4}, {3},{3,5}, 1250 {0},{0},{0,2}, {0},{0,4},{0},{0,2},{0,2}, {0},{0,4},{0,3}, {0,3}, 980 {0},{0,2},{0},{0,4},{0,4},{0}, {0},{0,2},{0,2}, {0}, {3}, {3,5} 20 ・ ・ ・ ・ ・ ・ {0},{0,2},{0,4},{0,4},{0,4},{0},{0},{0,2},{0,4},{0,4},{3}, {3,5}, 1 のように表示する。システムエンジニアはこの表示結果
に基づいて、典型的なパターンに注目し、また、逆に出
現回数１回のような特殊な場合にも着目して、例外条件
を見逃さないようにして、より正確な決定支援を行なう
ができる。

【００５８】この実施例によれば、バイトパターン集合
定義体に基づいてデータベースのレコード長候補を選定
し、候補指定されたレコード長ごとにバイトパターンを
解析してレコードを構成するバイトパターン種別および
該バイトパターンのレコード内オフセット位置に基づい
て同一バイトパターンで構成されるレコードの出現頻度
を算出するようにしたので、フィールド長、フィールド
タイプの決定に際して正確な支援を行なうことができ
る。

【００５９】実施例３．この発明の第３の実施例は、図
１の全体概要図のステップ１２で候補選定されたレコー
ド長候補に対し、隣り合うバイトのタイプによりフィー
ルドの候補を解析し（ステップ１４ー３）、システムエ
ンジニアによる判断、解析の支援を行なう（ステップ１
５ー１）方式と、推論規則に従って自動推論によって
（ステップ１５ー２）フィールド情報を出力する方式を
示したものである。

【００６０】以下に、この第３の実施例を図７に示すフ
ローチャートに基づいて説明する。まず、対象としてい
るシステムのデータタイプとバイトパターン集合の包含
関係によって、システムエンジニアがバイトパターン集
合を選択する（ステップ７１）。実施例１，２の例にお
いて、６種類のバイトパターン集合のうち、文字、十進
数、パック形式十進数を考慮して、 ０：英数字 １：半角カナ ２：十進数 ３：パック形式十進数 の４種類を選択したものとする。

【００６１】次に、レコード内オフセット位置ごとに所
属バイト集合の集合を集計する（ステップ７２）。前述
の例では、 0 1 2 3 4 5 6 7 8 9 10 11 {0},{0,2},{0},{0},{0,4},{0},{0,2},{0},{0,4},{0,4},{3},{3,5}, A O L C C 9 X 01 8f {0},{0},{0,2},{0},{0,4},{0},{0,2},{0,2},{0},{0,4},{0,3},{0,3}, B A 1 C D 0 5 Z 22 3f {0},{0,2},{0},{0,4},{0,4},{0},{0},{0,2},{0,2},{0},{3},{3,5} C 9 X Z A 1 4 A 00 9f であったので、そのレコード内オフセット位置ごとの所
属バイト集合の集合は、以下のようになる。 0 1 2 3 4 5 6 {{0}},{{0},{0,2}},{{0},{0,2}},{{0}},{{0}},{{0}},{{0},{0,2}}, 7 8 9 10 11 {{0},{0,2}},{{0},{0,2}},{{0}},{{0,3},{3}},{0,3},{3}}

【００６２】次に、オフセットの若い方から順にサーチ
して行き、集合の変わり目をフィールドの切れ目の候補
（ステップ７３）とし、フィールド開始位置候補、フィ
ールド長候補、所属バイト集合から成る新たな集合を出
力する。上記の例では、 (0,1,{{0}}) (1,2,{{0},{0,2}}) (3,3,{{0}}) (6,3,{{0},{0,2}}) （９，１，｛｛０｝｝） （１０，２，｛｛０，３｝，｛３｝｝） が出力される。この情報をデータタイプに結びつける方
法には、システムエンジニアによる判断方法（ステップ
７４）と、人工知能的に規則を定義して推論する方法
（ステップ７５，７６）が存在し、以下にこれらについ
て示す。

【００６３】システムエンジニアはこの情報をもとに所
属バイト集合とデータタイプを結びつけてデータタイプ
を決定する。次の情報が判断材料となる。 （１）｛｛０｝｝は文字タイプである。 （２）{{0,2}}はすべてが十進数であるので数字タイプ
である。 （３）{{0},{0,2}}はすべてが十進数字ではなく、数字
以外の文字を含むので文字タイプである。 （４）{{0,3},{3}}} はすべてが文字ではなく、かつ、
全てがパック十進数なのでパック十進数である。 これによって、バイト位置が０から長さ１０バイトが文
字タイプ、バイト位置１０から長さ２バイトがパック十
進数であることが分かる。

【００６４】自動推論する方法では、システムエンジニ
アが予めバイトパターン集合の集合とデータタイプを結
び付ける規則を与える。たとえば、次のように定義され
る。Ｘは文字タイプを、９は十進数タイプを、Ｐはパッ
ク形式十進数タイプを表すものとする。また矢印（→）
の左にバイトパターン集合の集合を右に対応するデータ
タイプを示す。上記の例では次のようになる。 {{0}} →Ｘ {{0,2}} →９ {{0},{0,2}} →Ｘ {{3}} →Ｐ {{0,3},{3}} →Ｐ

【００６５】この規則とバイトパターン集合の集合の列
に基づいて、フィールド開始位置候補、フィールド長候
補、データタイプの候補の３つ組を出力する。上記の例
である (0,1,{{0}}) (1,2,{{0},{0,2}}) (3,3,{{0}}) (6,3,{{0},{0,2}}) (9,1,{{0}}) (10,2,{{0,3},{3}}) に、このルールを適用すると (0,1,X)(1,2,X)(3,3,X)(6,3,X)(9,1,X)(10,2,P) となる。これを、同一のデータタイプでまとめ挙げる
と、 (0,10,X)(10,2,P) となる。ここでは説明を判り易くするために方法を単純
化して示したので、システムエンジニアによる判断、及
び推論規則に基づいて自動的に推論する方法のいずれの
場合においても、連続した同じデータタイプのフィール
ドの切れ目をこれ以上詳細に分割して判断することはで
きない。しかしながら、空白の出現頻度や半角カナ等の
情報を付加することで推論規則を更に詳細化すれば、フ
ィールドの切れ目認識等に関してさらに処理を高精度化
することができる。

【００６６】図８は図７のステップ７３に対応し、オフ
セットの若い方から順にサーチして行き、集合の変わり
目をフィールドの切れ目の候補とする処理ステップの詳
細を示すフローチャートである。ステップ１２６では、
変数であるバイトポインタに１を代入する。このバイト
ポインタは、レコード内のバイトオフセットを表す。

【００６７】ステップ１２７では、変数である現在フィ
ールド開始位置、現在フィールド長、現在フィールド所
属集合に値を代入する。

【００６８】現在フィールド所属集合に代入する値は、
現在バイトの所属集合である。現在バイトの所属集合と
は、フィールド内の全てのレコードで、バイトポインタ
が示す位置のバイトが所属するバイトパターン集合の一
つ以上の組である。これは、ステップ１２０で得た情報
から得ることができる。

【００６９】ステップ１２８では、バイトポインタに１
を加える。ステップ１２９では、バイトポインタとレコ
ード長とを比較し、プログラムを終了するかどうかを判
定する。

【００７０】ステップ１３０では、現在フィールド所属
集合と、現在バイトの所属集合とを比較する。もし、こ
れらの所属集合が同じ場合は、現在判定中のフィールド
に、バイトポインタが示すバイトが含まれると判断し、
ステップ１３１で現在フィールド長に１を加え、次のバ
イトの判定に進むため、ステップ１２８に戻る。

【００７１】もし、これらの所属集合が異なる場合は、
現在判定中のフィールドには、バイトポインタが示すバ
イトは含まれないと判断し、ステップ１３２で、現在フ
ィールド開始位置、現在フィールド長を保存する。そし
て、新たなフィールド判定を行なうため、ステップ１２
７に戻る。

【００７２】ステップ１２９において、バイトポインタ
がレコード長より大きくなった場合には、ステップ１３
３に進む。ステップ１３３では、最後に判定したフィー
ルドの情報を保存するため、現在フィールド開始位置、
現在フィールド長を保存する。

【００７３】上述の例では、ステップ１３２、ステップ
１３３で現在フィールド開始位置と現在フィールド長の
みを保存しているが、後の処理に使用するために現在フ
ィールド所属集合をも保存してもよい。

【００７４】この実施例によれば、バイトパターン集合
定義体情報に基づいてデータベースのレコード長候補を
選定し、候補指定されたレコード長に対しレコード内オ
フセット位置ごとに所属するバイトパターン集合からな
る新たな集合を算出し、これら集合の変化点に着目して
レコードを構成するフィールドの候補を出力するように
したので、妥当性ある分析結果を得ることができる。

【００７５】実施例４．この発明の第４の実施例では、
図１のステップ１６に示すように既に実施例１〜３で求
められたレコード長およびフィールド情報（位置、長
さ、データタイプ）に関する候補選定結果を、対象とす
る移行元のデータベースに対して適用することによっ
て、候補選定結果の正確さを検証している。

【００７６】以下に、この実施例を図９に示すフローチ
ャートに基づいて説明する。ここでは、対象とするデー
タベースのレコード長およびフィールド情報（位置、長
さ、データタイプ）の候補が、実施例１〜３により求め
られているものとする。まず、ステップ９１において、
これらのレコード長およびフィールド情報の候補とバイ
トパターン集合を与える。この段階では、データタイプ
の候補が決定しているのでの、バイトパターン集合はデ
ータタイプに則して決定されたものが与えられるものと
する。

【００７７】実施例１〜３では、フィールドの区切りを
明確にするために、半角カナやスペースもバイトパター
ン集合としたが、ここでは、データタイプに則した集合
を利用する。即ち、本来の目的であるデータ移行の観点
からデータタイプごとにバイトパターン集合を定義す
る。一般に、レコードを構成しているフィールドの切れ
目を分析、判断する際に用いられるバイトパターン集合
よりも大きな括りとなる。例えば、 ０：文字 １ 十進数 ２：パック形式十進数 ３：バイナリ というように与えることができる。対応するバイト集合
は、文字コードなどに依存する。たとえば、シフトＪＩ
Ｓコードの場合、０：文字は２０−７Ｃ，ａｌ−ｆｃ，
８１−ｅｆ，４０−ｆｃ、１：十進数は３０−３９，７
０−７９，のようになる。

【００７８】次にステップ９２で、与えられたレコード
長ごとにレコードを順に読み込み、バイトパターン集合
をもとに移行元データベースのデータタイプを検証す
る。すなわち、読み込んだレコードについて１バイトご
とに与えられたフィールドとデータタイプにそのバイト
データが合致するか否かを判断する。フィールド情報と
矛盾が生じたレコードはそのバイトパターン集合列とと
もに保存する。移行元データベース内のデータが終了す
るまで、この操作を繰り返す。

【００７９】次にステップ９３で、矛盾したレコードが
保存されているかどうかを判定する。矛盾したレコード
が存在しない場合には、与えられたレコード長およびフ
ィールド情報候補が正しいことが検証される。他方、矛
盾したレコードが存在する場合は、ステップ９５でその
レコードとバイトパターン集合列を表示し、システムエ
ンジニアによる修正支援を求める。システムエンジニア
はレコード長、フィールド情報を修正して、ステップ９
２に戻る。

【００８０】この実施例によれば、候補選定されたレコ
ード長およびフィールド情報（位置、長さ、データタイ
プ）結果を、対象となる移行元のデータベースに対して
適用することにより候補選定結果の正確さを検証するよ
うにしたので、移行処理の精度を向上させることができ
るという効果がある。

【００８１】実施例５．この発明の第５の実施例は、図
１のステップ１７に示すように既に実施例１〜４によっ
て得られたレコード長、フィールド情報をもとにして、
データベースを新しい環境に移行する場合に必要となる
移行先のレコード長、フィールド情報の決定を支援する
方式を付加したものである。

【００８２】以下に、この第５の実施例について、図１
０のフローチャートに基づいて説明する。移行先データ
ベースの文字コードや数字データ等の情報からデータ長
が変わるバイトパターンを抽出して、その伸縮の長さに
応じてバイトパターン集合を決定する。例えば、移行元
データベースの文字コードがシフトＪＩＳで移行先デー
タベースの文字コードがＥＵＣの場合、半角カナ文字を
表現するのに１文字あたり１バイトから１文字あたり２
バイト必要となり、同じフィールド長とするとデータ欠
けが生じる。たとえば、移行元データベースにおいて
“データベース”というデータが半角カナ６文字シフト
ＪＩＳでフィールド長８バイトの領域に格納されていた
と仮定する。シフトＪＩＳでは、このデータ（“データ
ベース”）は６バイトで表現することができるので、８
バイトの領域に十分格納されていた。ここで、文字コー
ドがＥＵＣである環境にデータベースを移行することを
想定すると、半角カナの“データベース”というデータ
を格納するためには１２バイトの領域が必要となる。従
って、移行先データベースにおいてはフィールド長を拡
張する必要がある。

【００８３】バイトパターン集合２０、レコード長情報
１５、フィールド情報１６を入力し、ステップ１００１
〜１００２で移行元データベース２１内容をレコードご
とに読み込み、フィールドごとに所属バイトパターン集
合列を求め、バイトパターンによる伸縮を考慮して、移
行先における必要フィールド長を求める。次に、ステッ
プ１００３でフィールドごとに保存されている最大必要
長と比較して、最大より大きい場合は、保存値を更新す
る。

【００８４】移行元データファイルが終了するまで以上
の操作を繰り返し、ファイル終了時に、フィールドごと
の最大必要長をシステムエンジニアに表示し、移行先デ
ータベースのレコード長および、フィールド情報（位
置、長さ、データタイプ）の決定を支援する（ステップ
１００５）。

【００８５】この実施例によれば、移行先データベース
の文字コード等によりデータ長が伸縮する文字集合に対
してはフィールド長補正を行なった後に移行先のフィー
ルド長候補を決定するようにしたので、移行元と移行先
間のファイル間においてフィールド長に差が生じるよう
な場合においても、情報損失を生じさせることなく整合
性ある移行処理を実現できる。

【００８６】

【発明の効果】この発明によれば、バイトパターン集合
定義体に基づいてファイル内のバイトパターンを解析し
てレコード長候補を選定し、候補指定されたレコードに
対してレコード内におけるバイトパターンのオフセット
位置ごとの出現頻度を算出するようにしたので、ファイ
ルデータ定義体およびソースプログラム情報が十分でな
い場合においても、データ形式の異なるデータベース間
でデータ移行を実現することできるという効果がある。

【００８７】また、ファイル構造の解析結果をグラフ等
を使用して視覚的に表示するようにしたので、フィール
ド境界やデータタイプの評価及び決定支援をユーザが容
易に行なうことができるという効果がある。

【００８８】また、バイトパターン集合定義体に基づい
てデータベースのレコード長候補を選定し、候補指定さ
れたレコード長ごとにバイトパターンを解析してレコー
ドを構成するバイトパターン種別および該バイトパター
ンのレコード内オフセット位置に基づいて同一バイトパ
ターンで構成されるレコードの出現頻度を算出するよう
にしたので、フィールド長、フィールドタイプの決定に
際して、正確な支援が実現できるという効果がある。

【００８９】また、バイトパターン集合定義体情報に基
づいてデータベースのレコード長候補を選定し、候補指
定されたレコード長に基づいてレコード内オフセット位
置ごとに所属するバイトパターン集合からなる新たな集
合を算出し、集合の変化点に着目してレコードを構成す
るフィールドの候補を出力するようにしたので、妥当性
ある分析結果を得ることができるという効果がある。

【００９０】また、候補選定されたレコード長およびフ
ィールド情報（位置、長さ、データタイプ）結果を、対
象となる移行元のデータベースに対して適用することに
より候補選定結果の正確さを検証するようにしたので、
移行処理の精度を向上させることができるという効果が
ある。

【００９１】また、移行先データベースの文字コード等
によりデータ長が伸縮する文字集合に対してはフィール
ド長補正を行なった後に移行先のフィールド長候補を決
定するようにしたので、移行元と移行先間のファイル間
においてフィールド長に差が生じるような場合において
も、情報損失を生じさせることなく整合性ある移行処理
を実現できるという効果がある。

【図面の簡単な説明】

【図１】 本発明の概要を記載したブロック図。

【図２】 本発明の第１の実施例を示すフローチャー
ト。

【図３】 本発明の第１の実施例において、所属バイト
パターン集合列の規則性をもとにレコード長を求めるス
テップを示したフローチャート。

【図４】 本発明の第１の実施例において、フィールド
情報決定のためにレコードのバイトごとの出現頻度を示
したグラフ例。

【図５】 本発明の第１の実施例において、所属バイト
パターン集合列の規則性をもとにレコード長を求めるス
テップの詳細を示すフローチャート。

【図６】 本発明の第２の実施例を示すフローチャー
ト。

【図７】 本発明の第３の実施例を示すフローチャー
ト。

【図８】 本発明の第３の実施例において、フィールド
の切れ目を自動推論するステップの詳細を示すフローチ
ャート。

【図９】 本発明の第４の実施例を示すフローチャー
ト。

【図１０】 本発明の第５の実施例を示すフローチャー
ト。

【符号の説明】

１０、２１ 移行元データベース（入力） １１、２０ バイトパターン集合（入力） １５ レコード長（出力） １６ フィールド情報（位置、長さ、データタイプ）
（出力） ２３ 所属バイトパターン集合列 ２５ レコード長候補 ２７ 出現頻度情報 ７５ パターン変換規則テーブル

Claims (7)

【特許請求の範囲】
1. 【請求項１】 データ形式の異なるデータベース間のデ
   ータ移行システムにおいて、 移行元データベースのバイトパターンを定義したバイト
   パターン集合定義体と、 前記バイトパターン集合定義体情報に基づいてデータベ
   ースのレコード長候補を選定するレコード長候補選定手
   段と、 候補選定されたレコード長と前記バイトパターン集合定
   義体に基づいてレコード内におけるバイトパターンのレ
   コード内オフセット位置ごとの出現頻度を算出する出現
   頻度算出手段とを備えたことを特徴とするデータベース
   移行方式。
2. 【請求項２】 レコード内におけるバイトパターンのオ
   フセット位置ごとの出現頻度情報の視覚表示手段を備え
   たことを特徴とする請求項第１項記載のデータベース移
   行方式。
3. 【請求項３】 データ形式の異なるデータベース間のデ
   ータ移行システムにおいて、 移行元データベースのバイトパターンを定義したバイト
   パターン集合定義体と、 前記バイトパターン集合定義体情報に基づいてデータベ
   ースのレコード長候補を選定するレコード長候補選定手
   段と、 候補選定されたレコード長ごとにバイトパターンを解析
   しレコードを構成するバイトパターン種別および該バイ
   トパターンのレコード内オフセット位置情報に基づいて
   同一バイトパターン構造を有するレコードの出現頻度を
   集計するレコードパターン集計手段と、を備えたことを
   特徴とするデータベース移行方式。
4. 【請求項４】 データ形式の異なるデータベース間のデ
   ータ移行システムにおいて、 移行元データベースのバイトパターンを定義したバイト
   パターン集合定義体と、 前記バイトパターン集合定義体情報に基づいてデータベ
   ースのレコード長候補を選定するレコード長候補選定手
   段と、 候補選定されたレコード長に基づいてレコード内オフセ
   ット位置ごとに所属するバイトパターン集合からなる集
   合を算出し集合の変化点に着目してレコードを構成する
   フィールド候補を出力するフィールド解析手段と、を備
   えたことを特徴とするデータベース移行方式。
5. 【請求項５】 前記バイトパターン集合からなる集合と
   データタイプの対応付けを記載した推論規則定義体を備
   え、 前記推論規則定義体情報と前記フィールド解析手段が出
   力したフィールド候補情報に基づいてフィールド境界お
   よび該フィールドのデータタイプを推論するフィールド
   推論手段を備えたことを特徴とする請求項第４項記載の
   データベース移行方式。
6. 【請求項６】 移行元データベースのレコードを構成す
   るフィールド境界および各フィールドのデータタイプ選
   定候補結果に基づいて移行元データベースのバイトパタ
   ーンを解析し、指定したバイトパターン種別のレコード
   内オフセット位置に関する整合性を確認する検証手段、
   を備えることにより候補選択結果に対する正確さの検証
   を可能にしたことを特徴とする請求項第１項乃至５項い
   づれかに記載のデータベース移行方式。
7. 【請求項７】 移行先データベースの文字コード等によ
   りデータ長が伸縮する文字集合に対してはフィールド長
   補正を行なった後に移行先のフィールド長候補を決定す
   るフィールド候補自動決定手段、を備えたことを特徴と
   する請求項第１項乃至第６項いづれかに記載のデータベ
   ース移行方式。