【課題】利便性の向上と開発者の開発負担の軽減とを図り、高速処理を確保すること。
【解決手段】本データ変換は、ロジックを必要としない定義駆動型により、処理効率と柔軟性とを両立する機能を実現する。具体的には、データ１０４を変換するとき、変換元１０１（Ｆｒｏｍ側）のメタ定義１３１と変換先１０２（Ｔｏ側）のメタ定義１３２が異なっていれば、変換機能１００を起動して変換先のメタ定義１３２に揃えるようにデータを変換する。図１の例では、変換元１０１のメタ定義１３１に従って“１３０円”という文字列がデータ１４１として入力された場合、変換元１０１と変換先１０２とでは、型属性の文字コードおよび文字種が相違するため、文字コード変換機能１１２と文字種変換機能１１３とを起動する。これにより、変換先１０２に出力されるデータ１４２である“１３０円”は、文字コードがＵＴＦ−８、文字種が半角（数字の部分）の文字列となる。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを変換するデータ変換装置、データ変換方法、およびデータ変換プログラムに関する。
【背景技術】
【０００２】
抽出したデータをまとめて統合する処理は、物理統合（ＥＴＬ：Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄｉｎｇ）と呼ばれる。物理統合では、抽出機能（Ｅｘｔｒａｃｔ）により情報源から抽出したデータについて、物理的な統合（Ｔｒａｎｓｆｏｒｍ）をおこなう。そして、統合結果を登録機能（Ｌｏａｄｉｎｇ）によって利用側に登録する。物理統合は、バッチ処理としてまとまった処理を行うのに適している。物理統合では、情報の鮮度は抽出した時点の情報となり、情報源と統合結果の重複管理が発生しやすい。
【０００３】
また、統合機能の部品化を行い、予め統合ロジックをＴＤＬ（Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などの統合処理ロジック記述言語により記述してリポジトリに登録しておく。そして、実行時にＴＤＬなどの統合処理ロジックに沿って統合部品を順次処理することにより、物理統合を実現する方法もある（たとえば、下記特許文献１，２を参照。）。
【０００４】
また、複数の情報源に存在するデータを利用側の要求によりリアルタイムに収集して統合する処理は、仮想統合（ＥＩＩ：Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）と呼ばれる。仮想統合では、利用側からの検索要求に応じて、必要な情報を情報源から検索して収集を行い、収集したデータを統合して利用側に返すことにより、仮想的な情報統合を実現する。仮想統合は、利用側が必要とする時点のリアルタイムな情報を情報源から取得するため、鮮度が良い情報を利用できる。また、利用後は情報を廃棄することにより情報の重複管理が不要である。
【０００５】
上述した物理統合（ＥＴＬ）や仮想統合（ＥＩＩ）などの情報統合において、元の値（Ｆｒｏｍ値）の形式を、目的の値（Ｔｏ値）の形式に変換する機能は必須であり、一般にデータ型変換機能またはクレンジング機能と呼ばれている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第６，０１４，６７０号明細書
【特許文献２】米国特許第６，３３９，７７５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来のクレンジング機能は、データ型やその詳細な性質をあらわす型属性およびそれらを変換する型変換機能、クレンジング機能の組み合わせが予め決定されていることを前提にしており、拡張性について問題があった。具体的には、システムが予め持っているデータ型および型属性を拡張する手段がなく、たとえば、文字コード系を指定する文字コード系指定型属性（ｃｈａｒ＿ｃｏｄｅ）に対する文字コード系変換機能など、クレンジング機能との組み合わせや、指定できる型属性も予め決められている必要があった。
【０００８】
また、複数のデータ型や型属性、クレンジング機能を組み合わせて使用するケースにおける各型属性及び処理の整合性を確保する手段がないため、拡張時の整合性を損なうという問題があった。たとえば、既存のデータ型と類似したデータ型を定義するときに、既存のデータ型およびそのクレンジング機能との整合性を保障する手段がなく、開発者の負担が増大するという問題があった。
【０００９】
さらに、データ型や型属性および型変換機能、クレンジング機能が多くなると、それらの組み合わせ数が増大するため、開発者の負担が増大し、管理が複雑になるという問題があった。また、多くの組み合わせが存在する中で、必要なクレンジング機能を効率よく使い分ける手段が提供されていないため、性能が低下するという問題があった。
【００１０】
本発明は、上述した従来技術による問題点を解消するため、利便性の向上と開発者の開発負担を軽減とを図ることができ、変換性能を確保できるデータ変換装置、データ変換方法、およびデータ変換プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、本データ変換装置、データ変換方法、およびデータ変換プログラムは、変換元データおよび変換先データの性質をあらわすメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを構成する要素に対して固有なコードとしてメタデータコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで性質が規定される変換元データを前記変換先のメタデータで規定される性質を持つ変換先のデータに変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに担当するメタデータコードを変換ルールコードとして関連付けた変換ルールと、を記憶しておき、変換対象データの入力を受け付け、該当する前記変換元および前記変換先のコード化メタ定義情報について、前記変換ルールコード毎に前記変換元および前記変換先のメタデータコードを検出し、検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断し、判断結果に基づいて、変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定し、特定されたデータ変換機能を用いて、前記変換対象データ（変換元データ）を、前記変換元のメタデータで規定される性質から前記変換先のメタデータで規定される性質に変換することを要件とする。
【００１２】
また、前記メタ定義情報として使用するメタデータに関する仕様および、前記変換元のメタデータで性質が規定される前記変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能をメタデータとの関連と併せて定義した仕様定義情報を取得し、取得された仕様定義情報におけるメタデータに関する仕様に基づいて、前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定し、設定されたメタデータコード化テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定し、設定された変換ルールテーブルごとに担当するデータコードを変換ルールコードとして関連付けることにより、変換ルールを構築し、併せてメタデータコード化テーブルを参照することにより前記コード化メタ定義情報を構築することを要件とする。
【発明の効果】
【００１３】
本データ変換装置、データ変換方法、およびデータ変換プログラムによれば、利便性の向上と開発者の開発負担を軽減とを図るとともに、変換処理性能を確保することができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】実施の形態１にかかるデータ変換の一例を示す説明図である。
【図２】実施の形態１にかかるデータ変換装置のハードウェア構成を示すブロック図である。
【図３−１】実施の形態１にかかるデータ変換装置の機能的構成を示すブロック図である。
【図３−２】型変換機能ライブラリ３０２の記憶内容を示す説明図である。
【図３−３】クレンジング機能ライブラリ３０３の記憶内容を示す説明図である。
【図４】クレンジング仕様定義ファイル３０１の一記述例を示す説明図である。
【図５】図４に示したクレンジング仕様定義ファイル３０１の拡張例を示す説明図である。
【図６】クレンジング仕様定義ファイル３０１の型属性の追加／拡張例を示す説明図である。
【図７】変換元１０１で用いられる表Ａと変換先１０２で用いられる表Ｂを示す説明図である。
【図８】メタ定義ファイル３０４の一記述例を示す説明図である。
【図９】継承が追加されたクレンジング仕様定義ファイル３０１の一記述例を示す説明図である。
【図１０】継承先と継承元との関係を示す説明図である。
【図１１】メタ定義ファイル３０４の他の記述例を示す説明図である。
【図１２】図９に示したクレンジング仕様定義ファイル３０１と図１１に示したメタ定義ファイル３０４とを用いた場合のクレンジング処理を示す説明図である。
【図１３】継承元としてデータ型：日付型が追加された場合の継承関係を示す説明図である。
【図１４】図１３の継承によるデータ型変換例を示す説明図である。
【図１５】図１３に示した継承先（Ｃｈａｒ型）と継承元（日付型）との継承関係を記述したクレンジング仕様定義ファイル３０１の一例を示す説明図である。
【図１６】型属性にデフォルト値を定義したクレンジング仕様定義ファイル３０１の一記述例を示す説明図である。
【図１７】メタ定義ファイル３０４の簡素化を示す説明図である。
【図１８】クレンジング機能例（その１）を示す説明図である。
【図１９】クレンジング機能例（その２）を示す説明図である。
【図２０】クレンジング機能例（その３）を示す説明図である。
【図２１】クレンジング機能の実行順序を示す図表である。
【図２２】複数の型属性に対応するクレンジング機能が定義されたクレンジング仕様定義ファイル３０１の一例を示す説明図である。
【図２３】図２２で定義された文字コード系（ｃｈａｒ＿ｃｏｄｅ）と外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）の両方の処理を実行するクレンジング機能を示す説明図である。
【図２４】メタ定義ファイル３０４の一例を示す説明図である。
【図２５】クレンジング仕様定義ファイル３０１の一例を示す説明図である。
【図２６】データ型コード表３２１を示す説明図である。
【図２７】型属性コード表３２２を示す説明図（その１）である。
【図２８】型属性コード表３２２を示す説明図（その２）である。
【図２９】型属性コード表３２２を示す説明図（その３）である。
【図３０】型属性値コード表３２３を示す説明図（その１）である。
【図３１】型属性値コード表３２３を示す説明図（その２）である。
【図３２】型属性値コード表３２３を示す説明図（その３）である。
【図３３】型属性値コード表３２３を示す説明図（その４）である。
【図３４】型属性値コード表３２３を示す説明図（その５）である。
【図３５】型属性値コード表３２３を示す説明図（その６）である。
【図３６】データ型変換ルールテーブル３３１を示す説明図である。
【図３７】クレンジングルールテーブル３３２を示す説明図（その１）である。
【図３８】クレンジングルールテーブル３３２を示す説明図（その２）である。
【図３９】クレンジングルールテーブル３３２を示す説明図（その３）である。
【図４０】クレンジングルールテーブル３３２を示す説明図（その４）である。
【図４１】クレンジングルールテーブル３３２を示す説明図（その５）である。
【図４２】クレンジングルールテーブル３３２を示す説明図（その６）である。
【図４３】変換ルール群３３０を示す説明図である。
【図４４】図２４に対応するコード化メタ定義情報３４０を示す説明図である。
【図４５】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図（その１）である。
【図４６】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図（その２）である。
【図４７】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図（その３）である。
【図４８】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図（その４）である。
【図４９】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図（その５）である。
【図５０】実施の形態１にかかるデータ変換装置３００によるデータ変換処理手順を示すフローチャートである。
【図５１】図５０に示した初期化部３１１による初期化処理（ステップＳ５００１）の詳細な処理手順（前半）を示すフローチャートである。
【図５２】図５０に示した初期化部３１１による初期化処理（ステップＳ５００１）の詳細な処理手順（後半）を示すフローチャートである。
【図５３】図５１に示した型属性値コード表作成処理（ステップＳ５１０４）の詳細な処理手順を示すフローチャートである。
【図５４】図５０に示したデータ変換処理（ステップＳ５００２）の詳細な処理手順を示すフローチャートである。
【図５５】機能Ｆ１により制約が設定されたクレンジング仕様定義ファイル３０１の一例を示す説明図である。
【図５６】機能Ｆ２による変換例を示す説明図である。
【図５７】機能Ｆ５による変換例を示す説明図である。
【図５８】機能Ｆ６の一例を示す説明図である。
【図５９】制約の導入例を示す説明図である。
【図６０】制約条件テーブルの一例を示す説明図である。
【図６１】制約が追加された場合の変換ルール群３３０を示す説明図である。
【図６２】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図（その１）である。
【図６３】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図（その２）である。
【図６４】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図（その３）である。
【図６５】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図（その４）である。
【図６６】図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図（その５）である。
【図６７】実施の形態２にかかるデータ変換装置３００によるデータ変換処理手順を示すフローチャートである。
【図６８】図６７に示した初期化部３１１による初期化処理（ステップＳ６７０１）の詳細な処理手順（前半）を示すフローチャートである。
【図６９】図６７に示した初期化部３１１による初期化処理（ステップＳ６７０１）の詳細な処理手順（後半）を示すフローチャートである。
【図７０】図６８に示した制御パターン選定処理（ステップＳ６８０２）の詳細な処理手順を示すフローチャートである。
【図７１】図６７に示したデータ変換処理（ステップＳ６７０２）の詳細な処理手順を示すフローチャート（その１）である。
【図７２】図６７に示したデータ変換処理（ステップＳ６７０２）の詳細な処理手順を示すフローチャート（その２）である。
【図７３】実施の形態にかかるデータ変換装置の詳細な機能的構成を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下に添付図面を参照して、この発明にかかるデータ変換装置、データ変換方法、およびデータ変換プログラムの好適な実施の形態を詳細に説明する。実施の形態にかかるクレンジング機能は、値のメタ定義として、データ型およびその詳細を指定する型属性を持ち、変換元（Ｆｒｏｍ側）と変換先（Ｔｏ側）のメタ定義をデータとともに与え、Ｆｒｏｍ値（変換元の値）をＴｏ値（変換先の値）に変換する。
【００１６】
これにより、メタ定義だけで、変換ロジックや手順が不要となる。したがって、メタ定義を操作することで拡張可能であり、利便性が向上する。また、開発者もメタ定義を操作することで容易に拡張したり、機能を組み合わせたりできるため、開発者にとっても開発負担の軽減となる。以下、実施の形態１について説明する。
【００１７】
（実施の形態１）
＜データ変換＞
図１は、実施の形態１にかかるデータ変換の一例を示す説明図である。実施の形態にかかるデータ変換は、ロジックを必要としない定義駆動型により、処理効率と柔軟性とを両立する機能を実現する。具体的には、データ１０４を変換するとき、変換元１０１（Ｆｒｏｍ側）のメタ定義１３１と変換先１０２（Ｔｏ側）のメタ定義１３２が異なっていれば、変換機能１００を起動して変換先のメタ定義１３２に揃えるように変換する。
【００１８】
ここで、メタ定義１０３（１３１，１３２）とは、変換元１０１と変換先１０２におけるデータのデータ型および型属性を定義する情報である。たとえば、データ型には、文字列型（Ｃｈａｒ）や整数型（Ｉｎｔｅｇｅｒ）がある。また、型属性は、データ型のより詳細な特徴をあらわしており、たとえば、文字コード系や文字種がある。文字コード系には、たとえば、ＳＪＩＳ（Ｓｈｉｆｔ Ｊａｐａｎｅｓｅ Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ、シフトＪＩＳ）、ＪＥＦ（Ｊａｐａｎｅｓｅ ｐｒｏｃｅｓｓｉｎｇ Ｅｘｔｅｎｄｅｄ Ｆｅａｔｕｒｅ）、ＵＴＦ−８（ＵＣＳ／Ｕｎｉｃｏｄｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ ８）などがある。また、文字種には、全角、半角がある。
【００１９】
図１では、一例として、変換元１０１のメタ定義１３１について、データ型を文字列型とし、型属性の文字コード系をシフトＪＩＳ、文字種を全角としている。一方、変換先１０２のメタ定義１３２について、データ型を文字列型とし、型属性の文字コード系をＵＴＦ−８、文字種を半角としている。変換元１０１のデータ１４１は、変換元１０１のメタ定義１３１に従って変換機能１００に入力される。一方、変換先１０２のデータ１４２は、変換先１０２のメタ定義１３２に従って変換機能１００から出力される。
【００２０】
また、変換機能１００は、変換元１０１のメタ定義１３１と変換先１０２のメタ定義１３２とを比較して、異なる箇所がある場合、当該異なる箇所を変換して、変換先１０２のメタ定義１３２に揃えて、データ出力する。具体的には、変換機能１００は、データ型を変換するデータ型変換機能１１１と、文字コード系を変換する文字コード変換機能１１２と、文字種を変換する文字種変換機能１１３とを有する。
【００２１】
たとえば、変換元１０１と変換先１０２とでデータ型が相違する場合は、データ型変換機能１１１を起動して、変換元１０１のデータ１４１のデータ型を変換先１０２のデータ型に変換する。同様に、変換元１０１と変換先１０２とで文字コード系が相違する場合は、文字コード変換機能１１２を起動して、変換元１０１のデータ１４１の文字コード系を変換先１０２の文字コード系に変換する。また、変換元１０１と変換先１０２とで文字種が相違する場合は、文字種変換機能１１３を起動して、変換元１０１のデータ１４１の文字種を変換先１０２の文字種に変換する。
【００２２】
図１の例では、変換元１０１のメタ定義１３１に従って“１３０円”という文字列がデータ１４１として入力された場合、変換元１０１と変換先１０２とでは、型属性の文字コード系および文字種が相違するため、文字コード変換機能１１２と文字種変換機能１１３とを順次起動する。これにより、変換先１０２に出力されるデータ１４２である“130円”は、文字コードがＵＴＦ−８、文字種が半角（半角にできる数字の部分）の文字列となる。
【００２３】
＜データ変換装置のハードウェア構成＞
図２は、実施の形態１（後述の実施の形態２も同様）にかかるデータ変換装置のハードウェア構成を示すブロック図である。図２において、データ変換装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、磁気ディスクドライブ２０４と、磁気ディスク２０５と、光ディスクドライブ２０６と、光ディスク２０７と、ディスプレイ２０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。
【００２４】
ここで、ＣＰＵ２０１は、データ変換装置の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。磁気ディスクドライブ２０４は、ＣＰＵ２０１の制御にしたがって磁気ディスク２０５に対するデータのリード／ライトを制御する。磁気ディスク２０５は、磁気ディスクドライブ２０４の制御で書き込まれたデータを記憶する。
【００２５】
光ディスクドライブ２０６は、ＣＰＵ２０１の制御にしたがって光ディスク２０７に対するデータのリード／ライトを制御する。光ディスク２０７は、光ディスクドライブ２０６の制御で書き込まれたデータを記憶したり、光ディスク２０７に記憶されたデータをコンピュータに読み取らせたりする。
【００２６】
ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００２７】
インターフェース（以下、「Ｉ／Ｆ」と略する。）２０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク２１４に接続され、このネットワーク２１４を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク２１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
【００２８】
キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００２９】
スキャナ２１２は、画像を光学的に読み取り、データ変換装置内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
【００３０】
＜データ変換装置の機能的構成＞
図３−１は、実施の形態１（後述の実施の形態２も同様）にかかるデータ変換装置の機能的構成を示すブロック図である。図３−１において、データ変換装置３００は、クレンジング処理部と初期化部とを含む。クレンジング処理部および初期化部は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶装置に記憶されたプログラムをＣＰＵ２０１に実行させることにより、または、Ｉ／Ｆ２０９により、その機能を実現する。
【００３１】
また、データ変換装置３００では、クレンジング仕様定義ファイル３０１、型変換機能ライブラリ３０２、クレンジング機能ライブラリ３０３およびメタ定義ファイル３０４を用いる。クレンジング仕様定義ファイル３０１、型変換機能ライブラリ３０２、クレンジング機能ライブラリ３０３およびメタ定義ファイル３０４は、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶装置に記憶され、または、Ｉ／Ｆ２０９によりネットワーク２１４経由でアクセスすることができる。
【００３２】
クレンジング仕様定義ファイル３０１には、データ変換装置で扱うデータ型の性質がデータ型変換機能と併せて定義され、データ型の詳細な性質を定義する型属性がクレンジング機能と併せて定義されている。
【００３３】
また、データ変換装置３００は、初期化部３１１とクレンジング処理部３１２とを有する。初期化部３１１は、クレンジング仕様定義ファイル３０１とメタ定義ファイル３０４とを読み込んで、データ型コード表３２１と型属性コード表３２２と型属性値コード表３２３と生成する。すなわち、データ型、型属性、および型属性値をコード化する。
【００３４】
メタ定義ファイル３０４には図１に示したメタ定義１０３が記述されている。初期化部３１１は、メタ定義ファイル３０４をコード化して、コード化メタ定義情報３４０を生成する。コード化メタ定義情報３４０は、変換元１０１と変換先１０２とに分けて生成される。
【００３５】
また、初期化部３１１は、クレンジング仕様定義ファイル３０１のデータ型変換定義とデータ型コード表３２１からデータ型変換ルールテーブル３３１を生成し、クレンジング仕様定義ファイル３０１のクレンジング機能定義と型属性コード表３２２および型属性値コード表３２３からクレンジングルールテーブル３３２を生成する。初期化部３１１は、データ型変換ルールテーブル３３１およびクレンジングルールテーブル３３２をまとめ上げて、変換ルール群３３０を構築する。変換ルール群３３０は、たとえば、バイナリデータである。これにより、コード化されたデータ型、型属性、および型属性値に関する変換元から変換先へのデータ変換規則を構築する。
【００３６】
クレンジング処理部３１２は、クレンジング制御部３５１と型変換呼出し部３５２とクレンジング呼出し部３５３とを有する。クレンジング制御部３５１は、変換元１０１のＦｒｏｍ値（元の値）１４１およびＦｒｏｍ側のコード化メタ定義３４０と変換先１０２のＴｏ値（目的の値）１４２およびＴｏ側のコード化メタ定義情報３４０を読み込み、変換ルール群３３０を参照して、型変換呼出し部３５２とクレンジング呼出し部３５３とを制御する。
【００３７】
具体的には、クレンジング制御部３５１は、Ｆｒｏｍ側とＴｏ側のコード化メタ定義（型）を比較することによってどの型変換処理を実行させるかを決定し、決定した型変換処理を実行するための型変換機能を型変換機能ライブラリ３０２から型変換呼出し部３５２に呼び出して実行させる。同様に、Ｆｒｏｍ側とＴｏ側のコード化メタ定義（型属性）を比較することによってどのクレンジング処理を実行させるかを決定し、決定したクレンジング処理を実行するためのクレンジング機能をクレンジング機能ライブラリ３０３からクレンジング呼出し部３５３に呼び出して実行させる。
【００３８】
図３−２は、型変換機能ライブラリ３０２の記憶内容を示す説明図である。図３−２において、型変換機能ライブラリ３０２は、型変換機能を記憶している。型変換機能は、変換元１０１（Ｆｒｏｍ側）のデータ型と変換先１０２（Ｔｏ側）のデータ型との組み合わせで特定される。型変換機能は予め準備された関数を用いる。
【００３９】
図３−３は、クレンジング機能ライブラリ３０３の記憶内容を示す説明図である。図３−３では、文字コード系変換におけるクレンジング機能ライブラリ３０３を示している。このクレンジング機能ライブラリ３０３は、型属性が文字コード系である場合のクレンジング機能を記憶している。クレンジング機能は、Ｆｒｏｍ側の型属性値とＴｏ側の型属性値との組み合わせで特定される。クレンジング機能も型変換機能と同様、予め準備された関数を用いる。
【００４０】
つぎに、データ変換装置３００で用いられる各種データ（クレンジング仕様定義ファイル３０１、型変換機能ライブラリ３０２、クレンジング機能ライブラリ３０３およびメタ定義ファイル３０４）の詳細について例を用いて説明する。
【００４１】
＜クレンジング仕様定義ファイル３０１＞
図４は、クレンジング仕様定義ファイル３０１の一記述例を示す説明図である。図４のクレンジング仕様定義ファイル３０１では、データ型として、文字列型（Ｃｈａｒ型）と整数型（Ｉｎｔｅｇｅｒ型）を定義している。符号４０１が文字列型の定義記述であり、符号４０２が整数型の定義記述である。
【００４２】
文字列型の定義記述４０１において、符号４１１は、型変換機能の記述である。型変換機能の記述４１１では、型変換を定義するＤＴＣＶ＿ＲＵＬＥタグで定義されている。変換元１０１（Ｆｒｏｍ側）のデータ型は文字列型であるため省略されており、変換先１０２のデータ型は、ｔｏ属性として整数型「ｔｏ＝“Ｉｎｔｅｇｅｒ”」と記述される。また、ＤＴＣＶ＿ＲＵＬＥタグの値として、型変換機能として呼び出す関数名（ここでは、「文字の整数変換」）が指定される。ここで指定された関数名がポインタとなり、該当する型変換機能が呼び出されることとなる。
【００４３】
また、文字列型の定義記述４０１において、符号４１２は、型属性を定義するタグである。型属性を定義する「ＤＡＴＡ＿ＡＴＴＲ」タグ４１２では、型属性名として文字コード系（ｃｈａｒ＿ｃｏｄｅ）が記述されている。また、型属性を定義するタグ４１２の子タグとして、その型属性の値として使用することができる型属性値を定義する「ＶＡＬＵＥ」タグ４１３が記述されている。ここでは、“ＳＪＩＳ”、“ＪＥＦ”、“ＵＴＦ８”の３通りの型属性値が定義されている。
【００４４】
また、型属性値を定義するタグ４１３に引き続き、クレンジングルール定義タグ「ＣＬ＿ＲＵＬＥ」４１４が記述される。クレンジングルール定義タグ４１４には、変換元１０１（Ｆｒｏｍ側）の型属性値と変換先１０２（Ｔｏ側）の型属性値とが記述される。たとえば、変換元１０１の型属性値がシフトＪＩＳであり、変換先１０２の型属性値がＪＥＦである場合、クレンジングルール定義タグ４１４の開始タグ内に、「ｆｒｏｍ＝“ＳＪＩＳ”ｔｏ＝“ＪＥＦ”」と記述しておく。そして、タグの値として、シフトＪＩＳからＪＥＦへのクレンジング機能（文字コード系変換）を実行する関数名「ＳＪＩＳ＿ＪＥＦ変換」を記述する。ここで指定される関数名がポインタとなり、該当するクレンジング機能が呼び出されることとなる。
【００４５】
また、整数型の定義記述４０２において、符号４２１は、型変換機能の記述である。型変換機能の記述４２１では、変換元１０１（Ｆｒｏｍ側）のデータ型は整数型になっているため省略されており、変換先１０２のデータ型は、型変換を定義するＤＴＣＶ＿ＲＵＬＥタグの「ｔｏ」属性の値として、文字列型「ｔｏ＝“Ｃｈａｒ”」と記述される。また、ＤＴＣＶ＿ＲＵＬＥタグの値として、型変換機能を呼び出す関数名（ここでは、「整数の文字変換」）が記述される。ここで指定された関数名がポインタとなり、該当する型変換機能が呼び出されることとなる。
【００４６】
このクレンジング仕様定義ファイル３０１では、１個以上のデータ型を定義することが可能であり、それぞれのデータ型の性質として１つのデータ型に対して０個以上の型属性と各型属性の値として使える型属性値が定義される。ここで定義された変換元１０１（Ｆｒｏｍ側）と変換先１０２（Ｔｏ側）で使えるデータ型および型属性、型属性値を用いて、メタ定義ファイルとして各値の性質（メタ定義）を記述することによって、Ｆｒｏｍ側１０１のデータ値１４１に対応するメタ定義１３１が指定され、Ｔｏ側１０２のデータ値１４２に対するメタ定義１３２が指定される。これにより、変換元１０１のメタ定義および変換先１０２のメタ定義が変換元１０１のデータとともに図３−１に示したクレンジング処理部３１２に渡されると、クレンジング処理部３１２では、変換ルール群３３０を参照して変換元１０１と変換先１０２の型および型属性の組み合わせにより必要な型変換や文字コード系変換などのクレンジングを実行することができる。
【００４７】
尚、クレンジング仕様定義ファイル３０１において変換元１０１（Ｆｒｏｍ側）と変換先１０２（Ｔｏ側）を対称に定義する（ｆｒｏｍ側とｔｏ側のどちらの方向でも使えるようにする）ことによって、メタ定義ファイルを記述する際に、ｆｒｏｍ側とｔｏ側で使用可能なデータ型、型属性、型属性を区別する必要が無くなる。また先述の仮想統合（ＥＩＩ）においては、問合せの分解処理と、結果の統合処理の両方でデータ変換機能が使われ、ここではｆｒｏｍ側とｔｏ側が逆転するので、ｆｒｏｍ側とｔｏ側を対称に定義することが必須になる。
【００４８】
図５は、図４に示したクレンジング仕様定義ファイル３０１の拡張例を示す説明図である。図４では、クレンジングルールとして、型属性値の組み合わせごとに型属性変換機能を呼び出す関数名を記述したが、クレンジング機能を実現する関数には、それ自身でどの型属性値の組み合わせにも対応できる関数もある。このように、図５では、単一の関数で担当する型属性の全組み合わせに対応可能なクレンジング機能を用いる場合、クレンジングルール定義タグ４１４の「ｆｒｏｍ」属性や「ｔｏ」属性の値として「＊」を用いる。「＊」は該当する型属性で使用可能な全ての型属性値をあらわすワイルドカードである。
【００４９】
たとえば、図５の下線で示した行において、クレンジングルール定義タグ４１４の開始タグを、＜ＣＬ＿ＲＵＬＥ ｆｒｏｍ＝“＊” ｔｏ＝“＊”＞と記述する。これにより、変換元１０１の「ｃｈａｒ＿ｃｏｄｅ」型属性の型属性と変換先102の同型属性値とが異なる場合は、常に、クレンジングルール定義タグ４１４の開始タグおよび終了タグで挟まれた関数によりクレンジング機能「文字コード系変換」が実行される。
【００５０】
また、＜ＣＬ＿ＲＵＬＥ ｆｒｏｍ＝“Ａ” ｔｏ＝“＊”＞と記述した場合は、変換元１０１の該当する型属性の型属性値が“Ａ”で変換先１０２の同型属性値が“Ａ”以外の値であるときには常に、クレンジングルール定義タグ４１４の開始タグおよび終了タグで挟まれた関数によりクレンジング機能が実行される。
【００５１】
また、＜ＣＬ＿ＲＵＬＥ ｆｒｏｍ＝“＊” ｔｏ＝“Ａ”＞と記述した場合は、変換元１０１の該当する型属性の型属性値が“Ａ”以外の値で変換先１０２の同型属性値が“Ａ”であるときには常に、クレンジングルール定義タグ４１４の開始タグおよび終了タグで挟まれた関数によりクレンジング機能が実行される。
【００５２】
図６は、クレンジング仕様定義ファイル３０１の型属性の追加／拡張例を示す説明図である。図６のクレンジング仕様定義ファイル３０１は、図５に示したクレンジング仕様定義ファイル３０１に、例として文字の最大長（バイト長）を指定する“ｍａｘ＿ｌｅｎｇｔｈ”という型属性を、型属性：文字コード系（“ｃｈａｒ＿ｃｏｄｅ”）のあとに追加した例である。
【００５３】
このように、型属性定義タグ＜ＤＡＴＡ＿ＡＴＴＲ＞を追加することで、該当するデータ型で扱える型属性およびクレンジング機能を追加することができる。本例の場合は、文字列のｌｅｎｇｔｈ調整処理を実行することができる。
【００５４】
型属性定義の順番は、重要（基本的）な性質の型属性定義を先にすることで、優先して実行されるように制御することができる。原則的に新しい型属性定義は末尾に追加することによって、既存の変換機能に対する影響を最小化できる。本例では、型属性として“ｍａｘ＿ｌｅｎｇｔｈ”より“ｃｈａｒ＿ｃｏｄｅ”が重要な型属性となる。
【００５５】
また、型属性値は、型属性値を定義する＜ＶＡＬＵＥ＞タグを持たない型属性定義＜ＤＡＴＡ＿ＡＴＴＲ＞にすることによって、任意の型属性値を扱えるように拡張することができる。たとえば図６の点線枠内のように、＜ＶＡＬＵＥ＞タグによる型属性値の定義を行わない型属性定義とすることによって、型属性：ｍａｘ＿ｌｅｎｇｔｈは型属性値として任意の値を採ることができる。文字列の最大長（バイト長）を指定するｍａｘ＿ｌｅｎｇｔｈのように、その値を予め限定する事が難しい型属性に便利である。＜ＶＡＬＵＥ＞タグによる型属性値の定義をしない場合は、予め値を想定することが難しいため、クレンジングルール定義タグでは、＜ＣＬ＿ＲＵＬＥ ｆｒｏｍ＝“＊”ｔｏ＝“＊”＞のように必ず「＊」を使用したルールを記述する必要がある。この場合、型属性：ｍａｘ＿ｌｅｎｇｔｈが変換元１０１と変換先１０２とで異なるときには無条件にクレンジング機能「ｌｅｎｇｔｈ調整」が実行される。
【００５６】
ここで、クレンジング仕様定義ファイル３０１に基づいたメタ定義について説明する。ここでは、図６に示したクレンジング仕様定義ファイル３０１を例として用いる。
【００５７】
図７は、変換元１０１で用いられる表Ａと変換先１０２で用いられる表Ｂを示す説明図である。表Ａと表Ｂはメタ定義ファイル３０４で定義された表のモデルである。表Ａ、表Ｂではともに、カラムごとに、データ型、型属性、主キー制約が定義されている。表Ａでは、「従業員番号」のデータ型は整数型で主キー制約がある。「氏名」のデータ型は文字列型で、型属性である文字コード系はＪＥＦである。また、型属性である最大文字列長は２０バイトである。「電話番号」のデータ型は文字列型で、型属性である文字コード系はＪＥＦである。
【００５８】
また、表Ｂでは、「従業員番号」のデータ型は整数型で主キー制約がある。「氏名」のデータ型は文字列型で、型属性である文字コード系はＳＪＩＳである。また、型属性である最大文字列長は１４バイトである。「電話番号」のデータ型は整数型である。更に、表Ａの各カラムは（１）〜（３）により表Ｂの同名のカラムに対応している。
【００５９】
なお、ここでは表Ａを変換元１０１、表Ｂを変換先１０２として説明しているが、一般的にデータ変換の方向（変換元と変換先の決定）は、処理目的に応じて変化するものである。たとえば、前述の物理統合（ＥＴＬ）では、情報源側のデータモデルを表Ａ、ターゲット側のデータモデルを表Ｂとして、表Ａの各カラムを変換元１０１、表Ｂの対応するカラムを変換先１０２としてデータ変換が行われる。また、前述の仮想統合（ＥＩＩ）では、情報源側である物理モデルを表Ａ、利用側である論理モデルを表Ｂとして、表Ｂに対して入力された検索条件を表Ａに対する検索条件に変換する処理では、論理モデルである表Ｂの対象カラムに対する検索条件を変換元１０１、物理モデルである表Ａの対応するカラムに対する検索条件を変換先１０２としてデータ変換が行われ、情報源側の検索結果データ（物理モデル）を利用側の論理モデルのデータに変換する処理では、表Ａの各カラムを変換元１０１、表Ｂの対応するカラムを変換先１０２としてデータ変換が行われる。以下のすべての説明においては、仮想統合（ＥＩＩ）における物理モデルのデータ（表Ａ）を論理モデルのデータ（表Ｂ）に変換するためのデータ変換処理を例として用いているため、変換元１０１を表Ａとし、変換先１０２を表Ｂと仮定している。
【００６０】
図８は、メタ定義ファイル３０４の一記述例を示す説明図である。図８に示したメタ定義ファイル３０４は、図７に示した物理モデル表Ａおよび論理モデル表Ｂ、ならびに表Ａと表Ｂとの対応関係を定義したファイルである。
【００６１】
ここでは、物理モデル表Ａを＜Ｒ＿ＭＯＤＥＬ＞、論理モデル表Ｂを＜Ｖ＿ＭＯＤＥＬ＞で定義しており、ｎａｍｅ属性には表の名前を、ｋｅｙｔｙｐｅ属性にはキー指定を指定する。また、各表を構成するカラムを＜ＣＯＬＵＭＮ＞（ｎａｍｅ属性にカラム名を指定する）で定義し、各カラムの性質としてデータ型を＜Ｄ＿ＴＹＰＥ＞、型属性を＜Ｄ＿ＡＴＴＲ＞（ｎａｍｅ属性に型属性の名称を指定する）で定義している。また、各カラム間の対応関係は＜ＭＡＰ＿ＲＵＬＥ＞で定義し、＜ＦＲＯＭ＿ＣＯＬＵＮＭ＞（ｔａｂｌｅ属性に表の名前を指定する）で指定されたカラムが、＜ＴＯ＿ＣＯＬＵＭＮ＞（ｔａｂｌｅ属性に表の名前を指定する）に対応していることを示している。＜ＭＥＴＡ＿ＤＡＴＡ＞はメタ定義全体をまとめるルートタグである。
【００６２】
変換元１０１（物理モデル表Ａ）のデータをデータ変換して変換先１０２（論理モデル表Ｂ）に出力する場合、「氏名」については型属性である文字コード系の型属性値が相違するため、ＪＥＦからＳＪＩＳにクレンジングされる。また、最大文字列長を規定する型属性が表Ｂ側に指定されているため、文字列長が１４バイトを超える場合、１４バイトまでがコピーされ、１５文字目以降が削除される。「電話番号」については、データ型が相違するため、文字列型（ＪＥＦ）から整数型に型変換される。
【００６３】
つぎに、データ型の継承について説明する。クレンジング仕様定義ファイル３０１では、データ型は既存データ型を継承する記述を追加することで、クレンジング仕様を拡張することができる。ここで、既存のデータ型を継承先とし、継承先を継承した新しいデータ型を継承元とする。
【００６４】
継承については、継承元である新しいデータ型の定義に、「ｓｕｐｅｒ＝“継承先の型名”」と記述して継承先を指定することで定義することができる。継承が定義された場合、継承元のデータ型は継承先のデータ型が持つ型属性やクレンジング機能などの性質をすべて継承することとなる。
【００６５】
以下、継承の記述の追加例について説明する。ここでは、継承先のデータ型を文字列型とし、型属性：文字コード系のクレンジングルールを文字コード系変換とする。一方、継承元のデータ型を人名型とし、型属性：ｎａｍｅ＿ｓｐａｃｅのクレンジングルールを姓名空白処理とする。
【００６６】
図９は、継承が追加されたクレンジング仕様定義ファイル３０１の一記述例を示す説明図である。図９のクレンジング仕様定義ファイル３０１は、図４に示したクレンジング仕様定義ファイル３０１に、人名データ型定義記述９００（図９中、点線枠）を追加することによって、新たに「人名型」のデータと、対応するクレンジング機能を使えるようにした例である。
【００６７】
人名データ型定義記述９００において、データ型：人名型に対して、継承先を特定する記述として「ｓｕｐｅｒ＝”Ｃｈａｒ”」が追加されている。データ型：人名は、継承先を特定する記述により特定された文字列型が持つ型属性：文字コード系（型属性値はＳＪＩＳ，ＪＥＦ，ＵＴＦ８の３通り）とクレンジング機能：文字コード系変換などの性質をすべて受け継ぐことができる。
【００６８】
また、継承元は、継承先とは独立した独自の型属性として、ｎａｍｅ＿ｓｐａｃｅ（型属性値は、Ｙｅｓ，Ｎｏの２通り）とクレンジング機能：姓名空白処理機能を持つことができる。型属性：ｎａｍｅ＿ｓｐａｃｅは姓と名との間の空白の有無である。型属性値がＹｅｓであれば、空白を設け、Ｎｏであれば、姓と名との間を空白なしとする。
【００６９】
また、継承元に追加された型属性は継承先の型属性の後ろに追加されることとなる。これにより、常に継承先の型属性の方が、継承元の型属性より基本的な型属性として扱われる。
【００７０】
図１０は、継承先と継承元との関係を示す説明図である。図１０では、図９に示したクレンジング仕様定義ファイル３０１での継承先と継承元との関係を示している。継承先のデータ型：文字列型（Ｃｈａｒ）を継承した継承元のデータ型：人名型は、継承先のデータ型：文字列型（Ｃｈａｒ）が持つ型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）と、継承元のデータ型：人名で拡張した型属性：ｎａｍｅ＿ｓｐａｃｅを使用することができる。すなわち、継承元である人名型は継承先である文字列型（Ｃｈａｒ）としての性質をすべて引き継いで文字列型としても扱えることに加えて、人名型として独自の性質である「姓名間の空白」を扱うことができるように定義されている。
【００７１】
図１１は、メタ定義ファイル３０４の他の記述例を示す説明図である。図１１に示したメタ定義ファイル３０４は、図８に示したメタ定義ファイル３０４の表Ａおよび表Ｂについて「氏名」カラムの定義（Ｃｈａｒ型）を図９で追加したデータ型である「人名」型で置き換えたものである。したがって、人名型固有の型属性である「ｎａｍｅ＿ｓｐａｃｅ」を新たに定義しており、表Ａの「氏名」カラムは「ｎａｍｅ＿ｓｐａｃｅ＝“Ｙｅｓ”」で空白あり、表Ｂの「氏名」カラムは「ｎａｍｅ＿ｓｐａｃｅ＝“Ｎｏ”」で空白無しとしている。なお、図８の下線の記述（型属性：最大文字列長）は説明を簡単にするために削除した例とした。
【００７２】
図１２は、図９に示したクレンジング仕様定義ファイル３０１と図１１に示したメタ定義ファイル３０４とを用いた場合のクレンジング処理を示す説明図である。「氏名」カラムに関して、変換元１０１（Ｆｒｏｍ側）のデータ型：人名型で定義された人名『嶺野 和夫』を変換先１０２（Ｔｏ側）にクレンジング処理する例を示している。なお、図１２中、一点鎖線より上は、データ型：文字列型としての性質によるクレンジング処理であり、一点鎖線より下は、データ型：人名型固有の性質によるクレンジング処理である。
【００７３】
図１１を参照すると、変換元１０１で定義された表Ａの「氏名」カラムのデータ型：人名型は、文字コード系がＪＥＦでｎａｍｅ＿ｓｐａｃｅがＹｅｓ（空白あり）である。また、対応する変換先１０２で定義された表Ｂの「氏名」カラムのデータ型：人名型は、文字コード系がＳＪＩＳでｎａｍｅ＿ｓｐａｃｅがＮｏ（空白なし）である。したがって、図１２において、人名『嶺野 和夫』の文字コード系については、文字コード系変換機能を実行することで、ＪＥＦからＳＪＩＳに変換される。
【００７４】
一方、人名『嶺野 和夫』のｎａｍｅ＿ｓｐａｃｅについては、姓名空白処理機能を実行することで、Ｙｅｓ（空白あり）からＮｏ（空白なし）に変換される。したがって、変換先１０２（Ｔｏ側）では、文字コード系はシフトＪＩＳとなり、姓『嶺野』と名『和夫』との間の空白は削除され、人名『嶺野和夫』（シフトＪＩＳで表記）となる。
【００７５】
また、継承元のデータ型変換も継承先を引き継ぐことができる。具体的には、継承元独自のデータ型変換が不要であるデータ型との組み合わせについては、継承元にデータ型変換処理を定義しないことにより、継承先に定義されている該当データ型とのデータ型変換処理を引き継ぐように構成する。また、継承元独自のデータ型変換処理が必要な場合には、継承元に独自のデータ型変換処理を追加定義することによって、継承先に定義されているデータ型変換処理より優先して適用されるように構成する。
【００７６】
図１３は、継承元としてデータ型：日付型が追加された場合の継承関係を示す説明図である。図１３において、データ型：日付型の追加前から定義されているデータ型：文字列型（Ｃｈａｒ）とデータ型：整数型（Ｉｎｔｅｇｅｒ）の組み合わせに着目すると、「文字の整数変換」と「整数の文字変換」のデータ変換処理によって、相互のデータ型変換ができることを示している。一方、継承元のデータ型：日付型と既存のデータ型：整数型の組み合わせに着目すると、継承元とデータ型：整数型の間には明にデータ型変換は定義されていない。したがって、継承先である文字列型に対して定義済みの整数型とのデータ型変換が引き継がれることとなる。この場合、継承元もデータを継承先のデータ型であるとしてデータ型変換処理を行うことを意味するので、「継承元は継承先の性質を引き継ぐ」という継承の概念に沿った動作となり、矛盾は生じない。
【００７７】
図１４は、図１３の継承によるデータ型変換例を示す説明図である。図１４において、変換元１０１（Ｆｒｏｍ側）で定義された日付型のデータ『２００９０５２６』は、継承先である文字列型から引き継がれたデータ型変換処理（文字→整数変換）「文字の整数変換」により、整数『20,090,526』に変換される。
【００７８】
図１５は、図１３に示した継承先（Ｃｈａｒ型）と継承元（日付型）との継承関係を記述したクレンジング仕様定義ファイル３０１の一例を示す説明図である。日付型にはデータ型変換を示す＜ＤＴＣＶ＿ＲＵＬＥ＞タグが定義されていないため、継承先である文字列型（Ｃｈａｒ）に定義されている次のデータ型変換機能が継承されて適用される。具体的には、日付型のデータをＣｈａｒ型として扱うことによって、日付型からＩｎｔｅｇｅｒ型へのデータ型変換にはＣｈａｒ型で定義されているデータ型変換機能：文字の整数変換が適用され、Ｉｎｔｅｇｅｒ型から日付型へのデータ型変換にはＩｎｔｅｇｅｒ型で定義されているデータ型変換機能：整数の文字変換が適用される。
【００７９】
これにより、データ型の追加によって必要になる既存データ型とのデータ型変換を必要最小限にすることができる。したがってデータ型追加のコストを削減し、データ型変換に対する矛盾防止も同時に実現することができる。
【００８０】
つぎに、型属性値にデフォルト値を定義して、メタ定義ファイル３０４を簡素化する場合について説明する。型属性の数が増加すると、メタ定義ファイル３０４のすべての項目毎に定義されているすべての型属性を指定する手間が問題になる。そこでクレンジング仕様定義ファイル３０１における型属性の定義としてｄｅｆａｕｌｔ属性でデフォルト値を指定することで、メタ定義ファイル３０４の項目に定義されない型属性の値はデフォルト値が設定されているとみなせる。これにより、メタ定義ファイル３０４を簡素化することができる。
【００８１】
図１６は、型属性値にデフォルト値を定義したクレンジング仕様定義ファイル３０１の一記述例を示す説明図である。図１６において、下線部に示したように、型属性の定義として、「ｄｅｆａｕｌｔ＝“ＪＥＦ”」、「ｄｅｆａｕｌｔ＝“２０”」、「ｄｅｆａｕｌｔ＝“Ｙｅｓ”」というようにデフォルトの型属性値を記述しておく。
【００８２】
図１７は、メタ定義ファイル３０４の簡素化を示す説明図である。図１７において、上のメタ定義ファイル３０４は、簡素化前の記述例であり、下のメタ定義ファイル３０４は、図１６に示すクレンジング仕様定義ファイル３０１にもとづいてメタ定義ファイル３０４を簡素化した記述例である。
【００８３】
図１７の簡素化前のメタ定義ファイル３０４をみると、カラム名「氏名」について、データ型：人名型の型属性には、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）があり、その型属性値に“ＪＥＦ”が定義されている。また、カラム名「電話番号」について、データ型：文字列型の型属性には、型属性：文字コード系があり、その型属性値に“ＪＥＦ”が定義されている。図１６では、型属性：文字コード系のデフォルト型属性値として“ＪＥＦ”が定義されているため、メタ定義ファイル３０４において型属性：文字コード系の記述の省略が可能である。
【００８４】
また、図１７の簡素化前のメタ定義ファイル３０４をみると、カラム名「氏名」について、データ型：人名型の型属性には、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）があり、その型属性値に“２０”が定義されている。また、カラム名「電話番号」について、データ型：文字列型の型属性には、型属性：最大文字列長があり、その型属性値に“２０”が定義されている。図１６では、型属性：最大文字列長のデフォルト型属性値として“２０”が定義されているため、メタ定義ファイル３０４において型属性：最大文字列長の記述の省略が可能である。
【００８５】
また、図１７の簡素化前のメタ定義ファイル３０４をみると、カラム名「氏名」について、データ型：人名型の型属性には、型属性：姓名空白（ｎａｍｅ＿ｓｐａｃｅ）があり、その型属性値に“Ｙｅｓ”が定義されている。図１６では、型属性：姓名空白のデフォルト型属性値として“Ｙｅｓ”が定義されているため、メタ定義ファイル３０４において型属性：姓名空白の記述の省略が可能である。
【００８６】
＜クレンジング処理部３１２の詳細機能＞
つぎに、図３−１に示したクレンジング処理部３１２の詳細機能について説明する。上述したように、クレンジング処理部３１２は、クレンジング制御部３５１により、変換ルール群３３０を参照して、型変換呼出し部３５２とクレンジング呼出し部３５３とを制御する。具体的には、クレンジング制御部３５１は、どの型変換処理を実行させるかを決定し、決定した型変換処理を型変換機能ライブラリ３０２から型変換呼出し部３５２に呼び出させる。同様に、どのクレンジング処理を実行させるかを決定し、決定したクレンジング処理をクレンジング機能ライブラリ３０３からクレンジング呼出し部３５３に呼び出させる。まず、クレンジング呼出し部３５３とクレンジング機能におけるクレンジングインタフェースの拡張について説明する。
【００８７】
図１８は、クレンジング機能例（その１）を示す説明図である。クレンジング機能とは入力されたＦｒｏｍ値について変換を行い、Ｔｏ値として出力する機能であり、クレンジングルール３３２に基づいてクレンジング機能が一意に決定され、クレンジング制御部３５１の制御下でクレンジング呼出し部３５３から呼び出される。
【００８８】
たとえば、図５に示したクレンジング仕様定義ファイル３０１では、データ型としてデータ型：文字列型（Ｃｈａｒ）に対する型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）が定義され、その型属性値として「ＳＪＩＳ」「ＪＥＦ」「ＵＴＦ８」（ＪＥＦ）が使用可能である。また、クレンジングルール（ＣＬ＿ＲＵＬＥ）として、文字コード系変換機能が指定されている。ここでの文字コード系変換は、Ｆｒｏｍ側（変換元１０１）の動作条件である「ｆｒｏｍ＝“＊”」とＴｏ側（変換先１０２）の動作条件である「ｔｏ＝“＊”」が規定されており、予め定義されたｃｈａｒ＿ｃｏｄｅ型属性の任意の型属性値の組み合わせにより必要な文字コード系間の変換を実行する機能として定義されている。
【００８９】
このような複数の変換パターンを有するクレンジング機能にも対応できるように、クレンジングインタフェースは図１８に示すようにＦｒｏｍ側とＴｏ側の型属性値を「Ｆｒｏｍ定義」、「Ｔｏ定義」としてクレンジング機能に入力するように構成する。
【００９０】
たとえば、図８に示したメタ定義ファイル３０４について、表Ａの「従業員番号」項目を表Ｂの「従業員番号」に対応させる（１）のマッピング定義における文字コード系のクレンジング処理についてみると、図１８に示すように「Ｆｒｏｍ定義」として変換元である表Ａの「従業員番号」項目の文字コード系として「ＪＥＦ」がＦｒｏｍ値とともにクレンジング制御部３５１から渡され、「Ｔｏ定義」として変換先である表Ｂの「従業員番号」項目の文字コード系として「ＳＪＩＳ」がクレンジング制御部３５１からクレンジング機能に渡される。
【００９１】
つぎに、「Ｆｒｏｍ定義」「Ｆｒｏｍ値」「Ｔｏ定義」を受け取ったクレンジング機能は、「Ｆｒｏｍ定義」と「Ｔｏ定義」から「ＪＥＦ」から「ＳＪＩＳ」への文字コード系変換が必要であることを識別して、「Ｆｒｏｍ値」の値をＪＥＦ文字列としてシフトＪＩＳ（ＳＪＩＳ）の文字列への変換を実行し、その変換結果を「Ｔｏ値」に出力する。この仕組みによって、「Ｆｒｏｍ定義」と「Ｔｏ定義」の組み合わせによって決まる複数の変換パターンに対応するクレンジング機能を実現することができる。
【００９２】
図１８に示した仕様拡張に加えて、クレンジング機能にＦｒｏｍ定義、Ｔｏ定義として変換対象のデータ項目に定義されたデータ型および型属性値のすべてを渡すことにより、クレンジング機能の実装をより容易にし、または高度なクレンジング機能を実現可能にする例について、図１９を用いて説明する。
【００９３】
図１９は、クレンジング機能例（その２）を示す説明図である。図１９では、図８に示したメタ定義ファイル３０４で定義される（１）のマッピング定義について図１８に示した文字コード系変換処理を完了した後の次のクレンジング機能として文字列の全体長を調整する機能であるｌｅｎｇｔｈ調整機能を実行する場合を例示している。クレンジング制御部３５１からは、Ｆｒｏｍ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＪＥＦ、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：２０が渡される。このように、データ型およびすべての型属性と型属性値が渡されることとなる。
【００９４】
Ｔｏ定義も同様で、クレンジング制御部３５１からは、Ｔｏ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＪＥＦ、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：１４が渡される。このように、データ型およびすべての型属性と型属性値が渡されることとなる。
【００９５】
したがって、ｌｅｎｇｔｈ調整機能では、クレンジング制御部３５１から同時に渡されたＦｒｏｍ値の文字列が１４バイト以内であればそのままＴｏ値にコピーする。一方、Ｆｒｏｍ値の文字列が１４バイトを超えていれば、１４バイトより後ろを切ってＴｏ値にコピーする。なお、文字列を切る場合に、ｃｈａｒ＿ｃｏｄｅ型属性を参照して、マルチバイト文字の途中で切れる場合は、その前で切ることにより、文字の泣き別れを防止することができる。または、ｃｈａｒ＿ｃｏｄｅ型属性を参照して正確な文字数を計測することによって文字数で管理するｌｅｎｇｔｈ調整機能を実現することもできる。
【００９６】
つぎに、図１９による仕様拡張に加えて、クレンジング機能が処理結果の状態をＦｒｏｍ定義に反映する例について、図２０を用いて説明する。
【００９７】
図２０は、クレンジング機能例（その３）を示す説明図である。図２０は、図８に示したメタ定義ファイル３０４で定義される（１）のマッピング定義について、図１８に示した文字コード系変換処理と、図１９に示したｌｅｎｇｔｈ調整機能とを、より効率的なクレンジング制御ができるように仕様拡張した方式を用いて実行する場合を例示している。図２０の左側では、ｃｈａｒ＿ｃｏｄｅ型属性に対するクレンジング処理を実行している。クレンジング機能：文字コード系変換に対し、Ｆｒｏｍ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＪＥＦ、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：２０を与える。同様に、Ｔｏ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＳＪＩＳ、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：１４を与える。
【００９８】
この状態でＦｒｏｍ定義に従ったＦｒｏｍ値がクレンジング機能に与えられると、Ｆｒｏｍ値の文字コード系がＪＥＦからＳＪＩＳに変換される。クレンジング機能は、Ｔｏ値に変換結果をコピーするとともに、Ｆｒｏｍ定義の型属性値：ＪＥＦを処理結果であるＴｏ定義のＳＪＩＳに更新する。
【００９９】
次段の処理として、図２０の右側では、ｍａｘ＿ｌｅｎｇｔｈ型属性に対するクレンジング処理を実行している。クレンジング機能：ｌｅｎｇｔｈ調整機能に対し、Ｆｒｏｍ定義として、前段（図２０中左側）の処理において更新されたＦｒｏｍ定義をそのまま与える。同様に、Ｔｏ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＳＪＩＳ、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：１４を与える。
【０１００】
この状態でＦｒｏｍ定義に従ったＦｒｏｍ値がクレンジング機能に与えられると、Ｆｒｏｍ値の最大文字列長が２０バイトから１４バイトに調整される。クレンジング機能は、Ｔｏ値に変換結果をコピーするとともに、Ｆｒｏｍ定義の型属性値：２０（バイト）を処理結果であるＴｏ定義の１４（バイト）に更新する。これにより、最終的なＦｒｏｍ定義は、Ｔｏ定義と同一内容となるため、処理を終了する。
【０１０１】
このように、処理結果の状態をＦｒｏｍ定義に反映することにより、同一値を処理する次のクレンジング処理（次段の処理）にＦｒｏｍ定義をそのまま入力でき、その入力となる値の状態を伝えることが可能になり、全体の処理効率が高まるとともに、Ｆｒｏｍ定義がＦｒｏｍ値の状態を正確に反映しているために次段の処理がより正確になる。なお、Ｔｏ定義はそのまま次段に渡せるが、前段のＴｏ値は次段のＦｒｏｍ値として渡す必要がある。
【０１０２】
つぎに、クレンジング機能の実行順序について説明する。本実施の形態では、クレンジング機能の実行順序は、定義された順とすることで、重要な型属性から順に実行するようにする。具体的には、１つの値に対して、複数の型属性それぞれに対応するクレンジング機能を実行する場合の順序は、先に定義された型属性からとする。これにより、重要な型属性から順にクレンジングが実行されるので、無駄な処理の発生を防止でき、クレンジングの処理も簡素化することができる。
【０１０３】
図２１は、クレンジング機能の実行順序を示す図表である。図２１では、図６に示したクレンジング仕様定義ファイル３０１に基づき、図８に示したメタ定義ファイル３０４でのマッピング定義（２）である氏名をクレンジングする場合の実行順序を示している。図８の氏名のクレンジングにおいては、図６のクレンジング仕様定義ファイル３０１においてｃｈａｒ＿ｃｏｄｅ型属性がｍａｘ＿ｌｅｎｇｔｈ型属性より先に定義されている。
【０１０４】
まず、データ型の処理については、Ｆｒｏｍ側およびＴｏ側がともに文字列型（Ｃｈａｒ型）であるため、型変換は不要である。データ型変換はクレンジング処理より先に実行されるため、クレンジング処理ではデータ型は一致している。
【０１０５】
つぎに、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）の処理については、メタ定義された氏名の文字コード系を、Ｆｒｏｍ側の型属性値：ＪＥＦからＴｏ側の型属性値：ＳＪＩＳに文字コード系変換する。さらに、文字コード系（ｃｈａｒ＿ｃｏｄｅ）の処理後の型属性値ＳＪＩＳとなった氏名について、最大文字列長を２０から１４にしてｌｅｎｇｔｈ調整する。このように、重要（基本的）な性質についての型属性は先に定義され、実行される。
【０１０６】
これにより、注目型属性より重要な（上位の）型属性は一致していることを前提に処理することができる。また、注目型属性より下位の型属性は考慮する必要がない。さらに、処理の順序が一定になり、処理が簡素化されることとなる。
【０１０７】
つぎに、複数の型属性に対応するクレンジング機能の実装例について説明する。複数の型属性に対応できるクレンジング機能を実装することにより、型属性とクレンジング機能の組み合わせが柔軟になる。したがって、より高度なクレンジング機能を実現でき、クレンジング処理を実行する回数の低減化を図ることができ、性能向上に寄与することとなる。
【０１０８】
図２２は、複数の同種の型属性に対応するクレンジング機能が定義されたクレンジング仕様定義ファイル３０１の一例を示す説明図である。図２２では、クレンジング機能である「文字コード系変換」が、文字コード系（ｃｈａｒ＿ｃｏｄｅ）と外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）の２つの型属性で定義されており、両方の型属性に対応するクレンジング機能となる。ここで、外字コード系とは複数の外字対系（外字１、外字２）を扱うときに外字対系を識別するものであり、文字コード系の拡張仕様として追加した型属性である。
【０１０９】
図２３は、図２２で定義された文字コード系（ｃｈａｒ＿ｃｏｄｅ）と外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）の両方の処理を実行するクレンジング機能を示す説明図である。図２３において、クレンジング機能は、文字コード系変換を実行する。文字コード系変換では、ｃｈａｒ＿ｃｏｄｅ型属性に対するクレンジング処理のほか、ｃｈａｒ＿ｅｘｃｏｄｅ型属性に対するクレンジング処理も実行する。
【０１１０】
具体的には、Ｆｒｏｍ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＪＥＦ、外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）とその型属性値：外字１、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：２０を与える。同様に、Ｔｏ定義として、データ型：文字列型（Ｃｈａｒ）、型属性：文字コード系（ｃｈａｒ＿ｃｏｄｅ）とその型属性値：ＳＪＩＳ、外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）とその型属性値：外字２、型属性：最大文字列長（ｍａｘ＿ｌｅｎｇｔｈ）とその型属性値：１４を与える。
【０１１１】
この状態でＦｒｏｍ定義に従ったＦｒｏｍ値がクレンジング機能：文字コード系変換に与えられると、クレンジング機能：文字コード系変換は、Ｆｒｏｍ値の文字コード系をＪＥＦからＳＪＩＳに変換する。併せて、クレンジング機能：文字コード系変換は、Ｆｒｏｍ値の外字コード系を外字１から外字２に変換する。
【０１１２】
このように、１回の型属性変換において、文字コード系変換と外字コード系変換という異なる複数の型属性に対応する変換を、１つのクレンジング機能により実行することで、実行回数を削減（本例では２回のところを１回）することができる。この場合、次段の処理では、クレンジング機能としてｌｅｎｇｔｈ調整を実行することとなる。
【０１１３】
＜クレンジング処理部３１２による高速処理化＞
つぎに、クレンジング処理部３１２における速処理化について説明する。ここでは、上述したデータ変換処理について、図２５のクレンジング仕様定義ファイル３０１と図２４のメタ定義ファイル３０４とを用いて説明する。
【０１１４】
図２４は、メタ定義ファイル３０４の一例を示す説明図である。高速処理化において、メタ定義ファイル３０４は図４４で後述するように、統合処理の開始前（初期化時）に高速処理が可能な状態に最適化してコード化メタ定義３４０としてＲＡＭ２０３またはＲＯＭ２０２に展開しておく。
【０１１５】
図２５は、クレンジング仕様定義ファイル３０１の一例を示す説明図である。図２５において定義されたデータ型は、Ｃｈａｒ型（文字列型）、人名型、住所型、Ｉｎｔｅｇｅｒ型（整数型）の定義順で記述されている。クレンジング仕様定義ファイル３０１は、図２６〜図４６で後述するように、メタ定義ファイル３０４の初期化前の段階で、データ変換装置３００全体で一意な型ＩＤを割り当てることによって最適化した状態にして変換ルール群３３０としてＲＡＭ２０３またはＲＯＭ２０２に展開しておく。
【０１１６】
図２６は、データ型コード表３２１を示す説明図である。データ型コード表３２１において、型ＩＤは、データ型をＩＤ化するものであり、クレンジング仕様定義ファイル３０１で定義されたデータ型の定義順に１から始まる連続した整数となる。
【０１１７】
同様に、クレンジング仕様定義ファイル３０１で定義された型属性についても、各データ型内で一意であり、継承している型属性については、継承関係にあるデータ型間において同一となる型属性ＩＤを割り当てることでＩＤ化する。また、Ｃｈａｒ型の型属性コード表３２２は、継承元のデータ型に含めて説明しているが、独立した型属性コード表３２２として構成してもよい。
【０１１８】
図２７〜図２９は、型属性コード表３２２を示す説明図である。図２７は、Ｃｈａｒ（文字列型）および人名型の型属性コード表３２２であり、図２８は、Ｃｈａｒ（文字列型）および住所型の型属性コード表３２２であり、図２９は、Ｉｎｔｅｇｅｒ（整数型）の型属性コード表３２２である。
【０１１９】
図２７〜図２９に示した型属性コード表３２２において、型属性ＩＤは、クレンジング仕様定義ファイル３０１に記述された型属性の定義順に各データ型毎に１から始まる連続した整数となる。また、継承関係のあるデータ型の型属性は、最も祖先のデータ型の型属性から順に割り当てる。したがって、共通の祖先の型属性ＩＤは一致する。
【０１２０】
たとえば、図２７では、Ｃｈａｒ型を人名型が継承しているため、人名型の祖先であるＣｈａｒ型の型属性ＩＤ：１〜３は一致することとなる。同様に、図２８では、Ｃｈａｒ型を住所型が継承しているため、住所型の祖先であるＣｈａｒ型の型属性ＩＤ：１〜３は一致することとなる。
【０１２１】
同様に、クレンジング仕様定義ファイル３０１で定義された型属性値についても、各型属性内で一意な型属性値ＩＤを割り当てる。
【０１２２】
図３０〜図３５は、型属性値コード表３２３を示す説明図である。図３０は、ｃｈａｒ＿ｃｏｄｅ型属性の型属性値に型属性値ＩＤを割り当てた型属性値コード表３２３である。図３１は、ｃｈａｒ＿ｅｘｃｏｄｅ型属性の型属性値に型属性値ＩＤを割り当てた型属性値コード表３２３である。図３２は、ｎａｍｅ＿ｓｐａｃｅ型属性の型属性値に型属性値ＩＤを割り当てた型属性値コード表３２３である。図３３は、ｃｈｏｕ＿ｂａｎｃｈｉ型属性の型属性値に型属性値ＩＤを割り当てた型属性値コード表３２３である。
【０１２３】
図３０〜図３３に示した型属性値コード表３２３において、型属性値ＩＤは、各型属性毎に割り当てられ、型属性値の定義順に０から始まる連続した整数となる。なお、未定義の型属性値に対しては、型属性値として“−１”を割り当てる。また、図３０〜図３３中、「＊」のある型属性値は、デフォルト宣言された型属性値（デフォルト値）である。
【０１２４】
図３４は、ｍａｘ＿ｌｅｎｇｔｈ型属性の型属性値コード表３２３である。図３５は、ｍａｘ＿ｄｉｇｉｔ型属性の型属性値コード表３２３である。図３４および図３５に示したように、クレンジング仕様定義ファイル３０１で型属性値が定義されず、任意な型属性値を持つ型属性の場合、メタ定義ファイル３０４で定義された型属性値をそのまま型属性値ＩＤとして使用することにする。
【０１２５】
つぎに、データ型変換ルールについて説明する。データ型変換ルールとは、変換対象となるデータを、Ｆｒｏｍ側（変換元１０１）のデータ型からＴｏ側（変換先１０２）のデータ型に変換する機能の実行パターンを決定する変換規則表である。
【０１２６】
図３６は、データ型変換ルールテーブル３３１を示す説明図である。図３６において、データ型変換ルールテーブル３３１では、データ型ＩＤをＦｒｏｍ／Ｔｏに配置して、その組み合わせによって実行する変換機能を決定するように構成する。具体的には、データ型変換ルールテーブルの値として、型変換機能ライブラリ３０２に存在する型変換機能へのリンク（型変換機能の呼び出しポインタ）を、該当するデータ型ＩＤの組み合わせとなる位置に設定する。
【０１２７】
また、変換が不要なＦｒｏｍ／Ｔｏの組み合わせには単純に値を複製するコピー機能を設定する（図３６では、該当カラム内に「Ｃｏｐｙ」と表記）。また、継承したデータ型変換機能は最も身近な祖先のデータ型で定義された機能を採用する。なお、Ｆｒｏｍ／Ｔｏの「０」は「データ型ＩＤが未定義」の意味として使用し、Ｆｒｏｍ／Ｔｏが同じデータ型ＩＤの組み合わせについては使用しないため空欄にする。
【０１２８】
同様に、型属性値についても型属性ごとに変換規則をクレンジングルールとして定義する。クレンジングルールとは、変換対象となるデータを、Ｆｒｏｍ側（変換元１０１）の型属性値からＴｏ側（変換先１０２）の型属性値に変換する機能の実行パターンを決定する変換規則表である。
【０１２９】
図３７〜図４２は、クレンジングルールテーブル３３２を示す説明図である。図３７のクレンジングルールテーブル３３２は、ｃｈａｒ＿ｃｏｄｅ型属性用のクレンジングルールである。図３８のクレンジングルールテーブル３３２は、ｃｈａｒ＿ｅｘｃｏｄｅ型属性用のクレンジングルールである。図３９のクレンジングルールテーブル３３２は、ｎａｍｅ＿ｓｐａｃｅ型属性用のクレンジングルールである。
【０１３０】
図４０のクレンジングルールテーブル３３２は、ｃｈｏｕ＿ｂａｎｃｈｉ型属性用のクレンジングルールである。図４１のクレンジングルールテーブル３３２は、ｍａｘ＿ｌｅｎｇｔｈ型属性用のクレンジングルールである。図４２のクレンジングルールテーブル３３２は、ｍａｘ＿ｄｉｇｉｔ型属性用のクレンジングルールである。
【０１３１】
図３７〜図４０において、クレンジングルールテーブル３３２では、型属性値ＩＤをＦｒｏｍ／Ｔｏに配置して、その組み合わせによって実行するクレンジング機能を決定するように構成する。具体的には、クレンジングルールテーブル３３２の値として、クレンジング機能ライブラリ３０３に存在するクレンジング機能へのリンク（クレンジング機能の呼び出しポインタ）を、該当する型属性値ＩＤの組み合わせとなる位置に設定する。
【０１３２】
また、変換が不要なＦｒｏｍ／Ｔｏの組み合わせには単純に値を複製するコピー機能を設定する。なお、Ｆｒｏｍ／Ｔｏが同じ型属性値ＩＤの組み合わせについては使用しないため空欄にする。また、Ｆｒｏｍ／Ｔｏの組み合わせで異なるクレンジング機能を定義することとしてもよい。
【０１３３】
また、図４１および図４２に示したように、任意の値を持つ型属性は、型属性値によるクレンジング機能の使い分けを行わないのでクレンジング機能が１つである。したがって、Ｆｒｏｍ／Ｔｏの０：０座標に該当するクレンジング機能へのリンクを設定する。
【０１３４】
つぎに、上述したデータ型変換ルールテーブル３３１とクレンジングルールテーブル３３２とをまとめ上げる処理をおこなう。具体的には、たとえば、データ型ＩＤや型属性ＩＤ、型属性値ＩＤから直接参照可能な変換ルール群３３０を構築する。
【０１３５】
図４３は、変換ルール群３３０を示す説明図である。変換ルール群３３０は、変換ルールテーブル４３００とデータ型用変換ルールテーブル４３０１〜４３０４とで構成される。変換ルールテーブル４３００は、データ型ＩＤを配列番号として参照することによって該当するデータ型に対応するデータ型用変換ルールテーブルを参照するテーブルである。
【０１３６】
具体的には、変換ルールテーブル４３００の配列番号［０］は空欄とし、配列番号［１以上］はデータ型ＩＤと一致させる。また、変換ルールテーブル４３００に記載している各データ型は、実際にはそれぞれのデータ型用変換ルールテーブル４３０１〜４３０４を割り当てる（該当テーブルへの呼び出しポインタを入れる）ことでリンクされる。
【０１３７】
データ型用変換ルールテーブル４３０１〜４３０４は、データ型毎に作成され、配列番号［０］により該当データ型を変換元とするデータ型変換ルールテーブルを参照し、型属性ＩＤを配列番号として参照することによって該当する型属性に対応するクレンジングルールテーブルを参照するテーブルである。
【０１３８】
具体的には、データ型用変換ルールテーブルの配列番号［０］には該当するデータ型変換ルールテーブル３３１を割り当て、配列番号［１以上］には、一致する型属性ＩＤに対応するクレンジングルールテーブル３３２を割り当てる。
【０１３９】
たとえば、データ型ＩＤ：１のＣｈａｒ型は、変換ルール４３００の配列番号［１］にＣｈａｒ型用変換ルールテーブル４３０１を設定する。また、Ｃｈａｒ型用変換ルールテーブル４３０１では、配列番号［０］に図３６に示したデータ型変換ルールテーブル３３１へのポインタを設定し、配列番号［１］には型属性ＩＤ：１であるｃｈａｒ＿ｃｏｄｅ型属性用のクレンジングルールテーブル３３２（図３７）へのポインタを設定し、配列番号［２］には型属性ＩＤ：２であるｃｈａｒ＿ｅｘｃｏｄｅ属性用のクレンジングルールテーブル３３２（図３８）へのポインタを設定し、配列番号［３］には型属性ＩＤ：３であるｍａｘ＿ｌｅｎｇｔｈ型属性用のクレンジングルールテーブル３３２（図３４）へのポインタを設定する。
【０１４０】
つぎに、メタ定義ファイル３０４をコード化してコード化メタ定義３４０を作成する処理について説明する。ここでは、図２４に示したメタ定義ファイル３０４を例に挙げて説明する。メタ定義ファイル３０４での項目定義は、クレンジング仕様定義ファイル３０１の初期化により割り当て済みの各ＩＤ（データ型ＩＤ、型属性ＩＤ、型属性値ＩＤ）を用いてコード化する。図２４のメタ定義ファイル３０４では、項目定義として、従業員番号、氏名、住所、電話番号が表Ａ（物理モデル）および表Ｂ（論理モデル）に定義されている。したがって、項目定義ごとに表別にコード化する。
【０１４１】
図４４は、図２４に対応するコード化メタ定義３４０を示す説明図である。コード化メタ定義情報３４０では、メタ定義ファイル３０４において＜ＣＯＬＵＭＮ＞タグで定義されている項目定義に対応する項目メタ定義テーブルを作成し、各項目の性質は前述の変換ルール群３３０におけるデータ型用変換ルールテーブルと同じ構造にすることによって、データ型用変換ルールテーブルの参照を簡素化するように構成する。具体的には、項目メタ定義テーブルの配列番号［０］はデータ型ＩＤとし、配列番号［１以降］は配列番号を型属性ＩＤとしたときの、型属性値ＩＤとする構造にする。なお、項目メタ定義テーブル間の矢印はメタ定義ファイル３０４において＜ＭＡＰ＿ＲＵＬＥ＞タグで定義されているマッピング定義を表しており、表Ａから表Ｂへのデータ変換を行う場合は、矢印の始端はＦｒｏｍ側（変換元）を示しており、終端はＴｏ側（変換先）を示している。
【０１４２】
図４４の（Ａ）は、従業員番号について、Ｆｒｏｍ側のデータモデルである表ＡとＴｏ側のデータモデルである表Ｂとのコード化メタ定義情報３４０を示している。（Ｂ）は、氏名について、Ｆｒｏｍ側のデータモデルである表ＡとＴｏ側のデータモデルである表Ｂとのコード化メタ定義情報３４０を示している。（Ｃ）は、住所について、Ｆｒｏｍ側のデータモデルである表ＡとＴｏ側のデータモデルである表Ｂとのコード化メタ定義情報３４０を示している。（Ｄ）は、電話番号について、Ｆｒｏｍ側のデータモデルである表ＡとＴｏ側のデータモデルである表Ｂとのコード化メタ定義情報３４０を示している。
【０１４３】
たとえば、図４４の（Ｂ）に示す表Ａの氏名を例に挙げると、配列番号［０］には、表Ａの氏名項目のデータ型として定義されている人名型のデータ型ＩＤ：２（図２６を参照）を設定する。また、配列番号［１］には、表Ａの氏名項目に定義されている型属性について、配列番号［１］を型属性ＩＤとするｃｈａｒ＿ｃｏｄｅ型属性（図２７を参照）について、その型属性値：ＪＥＦの型属性値ＩＤ：１（図３０を参照）を設定する。同様に、配列番号［２］には、型属性ＩＤ：２であるｃｈａｒ＿ｅｘｃｏｄｅ型属性（図２７を参照）の型属性値：外字１の型属性値ＩＤ：０（図３１を参照）を設定する。同様に、配列番号［３］には、型属性ＩＤ：３であるｍａｘ＿ｌｅｎｇｔｈ型属性（図２７を参照）の型属性値：２０（図４１を参照）を設定する。同様に、配列番号［４］には、型属性ＩＤ：４であるｎａｍｅ＿ｓｐａｃｅ型属性（図２７を参照）の型属性値：Ｙｅｓの型属性値ＩＤ：０（図３２を参照）を設定する。なお、表Ａの電話番号項目におけるｍａｘ＿ｌｅｎｇｔｈ型属性のように、メタ定義ファイル３０４で型属性値が未定義でありクレンジング仕様定義ファイル３０１でデフォルト値も定義されていない場合は“−１”を設定する。
【０１４４】
このように、コード化メタ定義情報３４０では、項目メタ定義テーブルの項目番号［０］にその項目のデータ型ＩＤを設定し、項目番号［１］から順次項目番号を型属性ＩＤとする型属性値ＩＤを設定する。これにより、クレンジング仕様定義ファイル３０１に基づいて展開された変換ルール群３３０との照合を効率化することができる。ここで、図４４の（Ｂ）に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例について説明する。表Ａの氏名の値となる変換対象データを、「山田 和夫」とする。
【０１４５】
図４５〜図４９は、図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例１を示す説明図である。初期化処理により、あらかじめ上述したように、システム全体として整合性のあるコード化が行われ、各処理はコードによって処理を実行することができる（各処理が意味を認知しているのと同意である）。つぎにクレンジング処理部によるデータ変換処理では、クレンジング制御部３５１には図４５に示した変換対象の項目に関する項目メタ定義テーブルと値が与えられ、変換処理が開始される。
【０１４６】
変換処理では、まず、Ｆｒｏｍ側とＴｏ側とのデータ型の比較をおこなう。Ｆｒｏｍ側のコード化メタ定義情報３４０とＴｏ側のコード化メタ定義情報３４０について、配列番号［０］の値が比較される。この場合は、ともに“２”でありデータ型ＩＤ：２（人名型）で同じデータ型と認識される。
【０１４７】
データ型が同じであるため、つぎに、Ｆｒｏｍ側とＴｏ側との型属性の比較をおこなう。すなわち、先頭の型属性である配列番号［１］の値どうしが比較される。図４５では、Ｆｒｏｍ側が“１”（ＪＥＦ）、Ｔｏ側が“０”（ＳＪＩＳ）であるため、図４３の変換ルール群３３０により変換処理を特定する。
【０１４８】
具体的には、データ型ＩＤ：２（人名型）であるため変換ルールテーブル４３００を配列番号［２］で参照することによって、人名型用変換ルールテーブル４３０２を参照する。
【０１４９】
つぎに、人名型用変換ルールテーブル４３０２において現在比較している配列番号［１］のｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２（図３７）を参照する。つぎに、Ｆｒｏｍ側の型属性値ＩＤが“１”（ＪＥＦ）、Ｔｏ側の型属性値ＩＤが“０”（ＳＪＩＳ）であるため各ＩＤを配列番号として図３７のｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２を参照することによって、「文字コード系変換」の呼び出しポインタを特定する。これらの処理はプログラミング言語（例えばＣ言語）では次のように一度に処理でき、高速に動作する。
【０１５０】
変換処理＝変換ルール［データ型ＩＤ］−＞ルール［型属性ＩＤ］−＞クレンジングルール［Ｆｒｏｍ側の型属性値ＩＤ］［Ｔｏ側の型属性値ＩＤ］；
【０１５１】
このように、クレンジング機能として「文字コード系変換」が特定されたため、図２３で前述した「文字コード系変換」を実行することにより、文字コード系（ｃｈａｒ＿ｃｏｄｅ）と外字コード系（ｃｈａｒ＿ｅｘｃｏｄｅ）を同時に変換し、当該変換結果をＦｒｏｍ定義とＴｏ値に設定する。これにより、図４６に示すように表Ａの氏名に関するコード化メタ定義情報３４０の配列番号［１］，［２］の値が変換後の値である“０”（ＳＪＩＳ）、“１”（外字２）に更新される。併せて、表Ｂの氏名値にはＳＪＩＳで外字２を用いた値として「山田 和夫」が設定される。
【０１５２】
つぎに、図４６のメタ定義について、同様につぎの配列番号［２］に設定されている型属性値ＩＤを比較する。ここでは、型属性値ＩＤがともに“１”（外字２）であるため、つぎの配列番号［３］に進む。
【０１５３】
配列番号［３］の型属性値ＩＤどうしを比較すると、表Ａの氏名では“２０”、表Ｂの氏名では“１４”である。このように両者の値が異なるため、変換処理を特定する。
【０１５４】
具体的には、現在比較している人名型用変換ルールテーブル４３０２の配列番号［３］のｍａｘ＿ｌｅｎｇｔｈ用クレンジングルールテーブル３３２を参照する。ｍａｘ＿ｌｅｎｇｔｈ用クレンジングルールテーブル３３２（図４１を参照）は任意の型属性値を用いるため、Ｆｒｏｍ側およびＴｏ側がともに“０”で定義されているクレンジング機能として「ｌｅｎｇｔｈ調整」が特定される。したがって、「ｌｅｎｇｔｈ調整」を呼び出す。そして、前の処理結果のＴｏ値をＦｒｏｍ値に設定して「ｌｅｎｇｔｈ調整」を実行する。図４７は、「ｌｅｎｇｔｈ調整」機能の実行を示しており、図４８はその結果を示している。具体的には、Ｆｒｏｍ値の文字列長が１４バイトを超えている場合は、１４バイトに調整される。
【０１５５】
図４８では、「ｌｅｎｇｔｈ調整」を実行したことにより、Ｆｒｏｍ定義の配列番号［３］が変換結果の型属性値（Ｔｏ定義の配列番号［３］の値）に更新されている。具体的には、表Ａの氏名に関するメタ定義の配列番号［３］の値が、“２０”から“１４”に更新される。このあと、次の配列番号［４］についても同様に実行することで、「姓名空白処理」が特定され、Ｆｒｏｍ定義の値は、変換後の型属値に更新される（図４９を参照）。
【０１５６】
これにより、Ｆｒｏｍ定義である表Ａの氏名に関するコード化メタ定義とＴｏ定義である表Ｂの氏名に関するコード化メタ定義において、全ての配列番号における値が一致する。このようにすべてが一致したため、変換処理を終了する。このように、Ｆｒｏｍ定義の値を左から順に順次比較して、異なる場合に処理を特定して実行することを繰り返すことで、高速なデータ変換を実現することができる。
【０１５７】
＜データ変換処理手順＞
つぎに、実施の形態１にかかるデータ変換装置３００によるデータ変換処理手順について、図５０〜図５４を用いて説明する。
【０１５８】
図５０は、実施の形態１にかかるデータ変換装置３００によるデータ変換処理手順を示すフローチャートである。まず、初期化部３１１により、初期化処理を実行する（ステップＳ５００１）。初期化処理（ステップＳ５００１）の詳細については、図５１および図５２において説明する。
【０１５９】
つぎに、クレンジング処理部３１２により、データ変換処理を実行する（ステップＳ５００２）。データ変換処理（ステップＳ５００２）の詳細については、図５４において説明する。このあと、データ変換を継続するか否かを判断する（ステップＳ５００３）。判断基準は、ユーザによる操作入力でもよく、変換対象データの有無でもよい。
【０１６０】
継続する場合（ステップＳ５００３：Ｙｅｓ）、ステップＳ５００２に戻って、データ変換処理を実行する。一方、継続しない場合（ステップＳ５００３：Ｎｏ）、開放処理を実行する（ステップＳ５００４）。開放処理では、初期化処理（ステップＳ５００１）で獲得したメモリ上の資源を開放する。これにより、データ変換処理を終了する。
【０１６１】
図５１は、図５０に示した初期化部３１１による初期化処理（ステップＳ５００１）の詳細な処理手順（前半）を示すフローチャートである。図５１において、まず、クレンジング仕様定義ファイル３０１を読み込んで解析する（ステップＳ５１０１）。つぎに、データ型コード表作成処理を実行する（ステップＳ５１０２）。具体的には、各データ型にデータ型ＩＤを付与する。たとえば、図２６に示したように、すべてのデータ型について、定義順に１から始まり隙間のない全体で一意な整数を、データ型ＩＤとして付与する。
【０１６２】
そして、型属性コード表作成処理を実行する（ステップＳ５１０３）。具体的には、各型属性に型属性ＩＤを付与する。たとえば、図２７〜図２９に示したように、データ型毎に、すべての型属性について、祖先のデータ型から順に定義順に１から始まり、隙間のないデータ型内で一意な整数を、型属性ＩＤとして付与する。ここで、継承関係にあるデータ型間においては、共通する型属性の型属性ＩＤはシステム全体で一致するように制御する。
【０１６３】
そして、型属性値コード表作成処理を実行する（ステップＳ５１０４）。具体的には、たとえば、図３０〜図３５に示したように、各型属性値に型属性値ＩＤを付与する。型属性値コード表作成処理（ステップＳ５１０４）の詳細については、図５３において説明する。
【０１６４】
型属性値コード表作成処理（ステップＳ５１０４）のあと、図３６に示したように、データ型変換ルールテーブル３３１を生成する（ステップＳ５１０５）。そして、図３７〜図４２に示したように、クレンジングルールテーブル３３２を生成する（ステップＳ５１０６）。このあと、図４３に示したように、変換ルール群３３０としてまとめて（ステップＳ５１０７）、図５２のステップＳ５２０１に移行する。
【０１６５】
図５２は、図５０に示した初期化部３１１による初期化処理（ステップＳ５００１）の詳細な処理手順（後半）を示すフローチャートである。変換ルール群３３０が構築されたあと、図５２において、メタ定義ファイル３０４を読み込んで解析する（ステップＳ５２０１）。つぎに、解析された情報の種類を順次判断する（ステップＳ５２０２）。具体的には、データ型であるか、型属性であるか、型属性値であるかを判断する。ここでは、メタ定義ファイル３０４の記述順で判断することとなる。
【０１６６】
データ型である場合（ステップＳ５２０２：データ型）、データ型のＩＤ化を実行する（ステップＳ５２０３）。具体的には、データ型コード表３２１（図２６）を参照してデータ型ＩＤに変換する。そして、ステップＳ５２０８に移行する。
【０１６７】
また、情報の種類が型属性である場合（ステップＳ５２０２：型属性値）、型属性のＩＤ化を実行する（ステップＳ５２０４）。具体的には、型属性コード表３２２（図２７〜図２９）を参照して型属性ＩＤに変換する。そして、ステップＳ５２０８に移行する。
【０１６８】
また、情報の種類が型属性値である場合（ステップＳ５２０２：型属性値）、コード化している型属性値であるか否かを判断する（ステップＳ５２０５）。コード化している型属性値である場合（ステップＳ５２０５：Ｙｅｓ）、型属性値コード表３２３（図３０〜図３５）を参照して、型属性値ＩＤに変換する（ステップＳ５２０６）。そして、ステップＳ５２０８に移行する。
【０１６９】
一方、コード化している型属性値ではない場合（ステップＳ５２０５：Ｎｏ）、整数値である型属性値をそのまま型属性値ＩＤとする（ステップＳ５２０７）。そして、ステップＳ５２０８に移行する。
【０１７０】
ステップＳ５２０８においては、図４４に示したように、メタ定義ファイル３０４内のデータモデルの項目定義をコード化することによって項目メタ定義テーブルを作成する（ステップＳ５２０８）。具体的には、配列番号［０］にデータ型ＩＤを設定し、配列番号［１］、［２］、［３］、…に、その配列番号を型属性ＩＤとする型属性の型属性値ＩＤや型属性値（コード化していない場合）を設定する。たとえば、データモデルが表Ａの従業員項目に関する項目メタ定義テーブルを作成する場合、図４４に示したように、配列番号［０］には従業員番号項目のデータ型である整数型を示すデータ型ＩＤ：４（図２６を参照）を設定し、配列番号［１］には整数型の型属性ＩＤ：１であるｍａｘ＿ｄｉｇｉｔ型属性（図２９参照）の型属性値：１２（図３５参照）を設定する。ここで、ｍａｘ＿ｄｉｇｉｔ型属性の型属性値はコード化していない型属性値なので、メタ定義ファイル３０４で指定されている型属性値：１２をそのまま設定している。
【０１７１】
このあと、メタ定義ファイル３０４内のすべてのデータモデルがコード化されたか否かを判断する（ステップＳ５２０９）。すべてコード化されていない場合（ステップＳ５２０９：Ｎｏ）、ステップＳ５２０２に戻って残りのコード化を行う。一方、すべてコード化された場合（ステップＳ５２０９：Ｙｅｓ）、図４４に示したように、コード化された項目メタ定義の集合として、コード化メタ定義情報３４０を構成する（ステップＳ５２１０）。このあと、データ変換処理（ステップＳ５００２）に移行する。
【０１７２】
図５３は、図５１に示した型属性値コード表作成処理（ステップＳ５１０４）の詳細な処理手順を示すフローチャートである。まず、クレンジング仕様定義ファイル３０１において未選択の型属性をポイントする（ステップＳ５３０１）。つぎに、ポイントされた型属性について型属性値が定義されているか否かを判断する（ステップＳ５３０２）。型属性値が定義されている場合（ステップＳ５３０２：Ｙｅｓ）、ポイントしている型属性の型属性値として定義されているすべての型属性値について型属性値ＩＤを付与する（ステップＳ５３０３）。具体的には、型属性毎の定義順に、０から始まり隙間のない型属性内で一意な整数を型属性値ＩＤとして付与する。このあと、ステップＳ５３０５に移行する。
【０１７３】
一方、型属性値が定義されていない場合（ステップＳ５３０２：Ｎｏ）、定義されていない型属性値に対しては、メタ定義ファイル３０４を参照し、該当する型属性に関して、すべての型属性値がそのまま型属性値とすることができる整数値である場合は、メタ定義ファイル３０４に定義されている型属性値をそのまま型属性値ＩＤとして使用することとする。それ以外の値が存在する場合は、０から始まり隙間のない型属性内で一意な整数を型属性値ＩＤとして付与する（ステップＳ５３０４）。このあと、ステップＳ５３０５に移行する。
【０１７４】
そして、ステップＳ５３０５において、未選択の型属性があるか否かを判断する（ステップＳ５３０５）。未選択の型属性がある場合（ステップＳ５３０５：Ｙｅｓ）、ステップＳ５３０１に戻る。一方、未選択の型属性がない場合（ステップＳ５３０５：Ｎｏ）、図５１のステップＳ５１０５に移行して、データ型変換ルールテーブル３３１を生成することとなる。
【０１７５】
図５４は、図５０に示したデータ変換処理（ステップＳ５００２）の詳細な処理手順を示すフローチャートである。まず、未選択のコード化メタ定義情報３４０のペアがあるか否かを判断する（ステップＳ５４０１）。未選択のコード化メタ定義情報３４０のペアがある場合（ステップＳ５４０１：Ｙｅｓ）、未選択のコード化メタ定義情報３４０のペアを選択する（ステップＳ５４０２）。
【０１７６】
ここで、コード化メタ定義情報３４０のペアとは、Ｆｒｏｍ側のコード化メタ定義情報３４０と、当該コード化メタ定義情報３４０に対応するＴｏ側のコード化メタ定義情報３４０との組み合わせである。たとえば、図４４の例では、Ｆｒｏｍ側である表Ａの氏名に関するコード化メタ定義情報３４０を、Ｆｒｏｍ側のコード化メタ定義情報３４０とした場合、Ｔｏ側である表Ｂの氏名に関するコード化メタ定義情報３４０が、対応するＴｏ側のコード化メタ定義情報３４０となる。
【０１７７】
つぎに、定義ポイントｄをｄ＝０に設定し、選択されたコード化メタ定義情報３４０のペアを参照して、定義ポイントｄの最大値Ｄを取得する（ステップＳ５４０３）。定義ポイントｄは、選択されたコード化メタ定義情報３４０を参照するときに使用する配列番号を指定するための変数である。たとえば、ｄ＝０の場合は、Ｆｒｏｍ側のコード化メタ定義情報３４０およびＴｏ側のコード化メタ定義情報３４０の配列番号［０］に設定された情報（この場合はデータ型ＩＤ）を指定する。
【０１７８】
また、定義ポイントｄの最大値Ｄは、選択された各コード化メタ定義情報３４０での配列番号の最大値となる。たとえば、図４４の（Ｂ）に示したコード化メタ定義情報３４０のペアの場合、配列番号の最大値が“４”であるため、Ｄ＝４とする。
【０１７９】
つぎに、現在の定義ポイントｄで指定されたＦｒｏｍ側のコード化メタ定義情報３４０およびＴｏ側のコード化メタ定義情報３４０について定義ポイントｄを配列番号として設定されている情報を参照する（ステップＳ５４０４）。そして、参照された情報が同じ値か否かを判断する（ステップＳ５４０５）。同じ値である場合（ステップＳ５４０５：Ｙｅｓ）、ステップＳ５４１１に移行する。
【０１８０】
一方、参照された情報が同じ値でない場合（ステップＳ５４０５：Ｎｏ）、Ｆｒｏｍ側のコード化メタ定義情報３４０の配列番号［０］を参照してデータ型ＩＤの取得を行い、そのデータ型ＩＤを配列番号として変換ルールテーブル４３００を参照することにより、該当するデータ型用変換ルールテーブル４３０１〜４３０４を取得する（ステップＳ５４０６）。取得したテーブルを「特定データ型用変換ルールテーブル」と称して記憶する。そして、ステップＳ５４０９に移行する。
【０１８１】
たとえば、図４４の（Ｄ）に示したコード化メタ定義情報３４０のペアの場合、配列番号［０］に設定されたデータ型ＩＤが異なる（１（Ｃｈａｒ）と４（Ｉｎｔｅｇｅｒ））が、Ｆｒｏｍ側である表Ａの電話番号に関するコード化メタ定義情報３４０の配列番号［０］に設定されたデータ型ＩＤ：１（Ｃｈａｒ）を取得する。そして、この値（データ型ＩＤ：１（Ｃｈａｒ））を配列番号として変換ルールテーブル４３００を参照することによって、Ｃｈａｒ型変換ルールテーブル４３０１を特定データ型用変換ルールテーブルとして取得することとなる。
【０１８２】
このあと、ステップＳ５４０７では、定義ポイントｄを配列番号として特定データ型用変換ルールテーブルを参照することによって必要な変換ルール（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）を取得し、その変換ルールのＦｒｏｍ／ＴｏをステップＳ５４０４で取得済みのＦｒｏｍ側およびＴｏ側のコード化メタ定義情報３４０の値によって参照することによって、使用する変換機能を取得する。（ステップＳ５４０７）。
【０１８３】
具体的には、前述の図４４の（Ｄ）に示したコード化メタ定義情報３４０のペアの場合は、Ｃｈａｒ型変換ルールテーブル４３０１について定義ポイントｄ＝０で参照することによって、データ型変換ルールテーブル３３１（図３６を参照）を取得し、Ｆｒｏｍ側として、データ型ＩＤ：１（Ｃｈａｒ）、Ｔｏ側としてデータ型ＩＤ：４（Ｉｎｔｅｇｅｒ）で参照することによって変換機能「文字の整数変換」を取得する。このように、データ型変換ルールテーブル３３１と、クレンジングルールテーブルを同じ構造にすることによって、データ変換処理において区別することなく変換機能の取得を実現することができる。
【０１８４】
つぎに、取得された変換機能が有効であるか否かを判断する（ステップＳ５４０８）。有効であるか無効であるかの判断基準は、「インストールされて動作可能である」など、予め設定しておけばよい。無効である場合（ステップＳ５４０８：Ｎｏ）、データ変換処理は失敗となるため、終了する。一方、有効である場合（ステップＳ５４０８：Ｙｅｓ）、取得した変換機能により変換処理を実行する（ステップＳ５４０９）。具体的には、たとえば、Ｆｒｏｍ値を変換してＴｏ値に設定する。また、対処済みの定義内容をＦｒｏｍ定義に反映する（図２３および、図４５〜図４９を参照）。
【０１８５】
このあと、変換機能による変換処理が成功したか否かを判断する（ステップＳ５４１０）。不成功である場合（ステップＳ５４１０：Ｎｏ）、データ変換処理は失敗となるため、終了する。一方、成功である場合（ステップＳ５４１０：Ｙｅｓ）、ステップＳ５４１１に移行する。
【０１８６】
そして、ステップＳ５４１１では、定義ポイントｄをインクリメントする（ステップＳ５４１１）。このあと、ｄ＞Ｄであるか否かを判断する（ステップＳ５４１２）。ｄ＞Ｄでない場合（ステップＳ５４１２：Ｎｏ）、次の定義ポイントｄについて処理するためにステップＳ５４０４に戻る。一方、ｄ＞Ｄである場合（ステップＳ５４１２：Ｙｅｓ）、全ての定義ポイントについて処理が完了したので、ステップＳ５４０１に戻る。ステップ５４０１において、未選択のコード化メタ定義情報３４０のペアがない場合（ステップＳ５４０１：Ｎｏ）、データ変換処理（ステップＳ５００２）を完了して、図５０のステップＳ５００３に移行することとなる。
【０１８７】
このように、本実施の形態１によれば、データ型や型属性、クレンジング機能を、目的に応じて拡張することができる。また、複数のデータ型や型属性、クレンジング機能を組み合わせて使用する場合の整合性も取れているため、拡張時の整合性を損なうことがない。したがって、開発者の負担軽減を図ることができる。
【０１８８】
また、データ型や型属性、型属性値およびデータ型変換機能、クレンジング機能を必要最小限に抑えることにより、開発コストの低減化や管理の容易化を図ることができる。クレンジング機能を効率よく使い分けることにより、データ変換性能の向上を図ることができる。更に、データ型や型属性、型属性値についてシステム全体についてコード化を行うことによって、更なるデータ変換性能の向上を図ることができる。
【０１８９】
（実施の形態２）
つぎに、実施の形態２について説明する。実施の形態２は、実施の形態１に対し、下記の機能Ｆ１〜Ｆ７を付加する。
【０１９０】
Ｆ１：既存の型属性に対して制約（前提条件）を設定し、その範囲内で動作するクレンジング機能を定義できるようにする。
Ｆ２：クレンジング処理の実行時には、制約を守るための変換処理を先に実行した後で、処理本体を実行する。
Ｆ３：新規追加する機能は、自ら別の型属性の変換を行う。
Ｆ４：型属性を合わせるクレンジング処理の順番を、後方（より特殊な型属性）から処理する。
Ｆ５：クレンジング処理の制約（前提条件）については、自分以外のすべての型属性を扱えるように拡張する。その上で、最後に実行した変換が扱う型属性から、順番に処理して、一巡するまでは、繰り返し変換処理を実行する。
Ｆ６：機能Ｆ５の処理する順番は、必ずしも後方向（より拡張的な型属性）から前方に向かう（逆順である）必要はなく、正順（より基本的な型属性から順に拡張的な型属性を処理する）でもよい。従って、効率のよい処理方向を選択することも可能。
Ｆ７：共通の処理系で機能Ｆ１〜機能Ｆ６を選択できるようにする。
【０１９１】
上記機能Ｆ１〜Ｆ６の組み合わせパターン（以下、「制御パターンＰ＃」）は、下記の制御パターンＰ１〜Ｐ６となる。
【０１９２】
Ｐ１：クレンジング処理に制約（前提条件）を定義して、前提条件を守った処理を実現する。ただし、制約条件は自分より前（より基本的な型属性）とする（逆順）。機能Ｆ１，Ｆ２，Ｆ４の組み合わせで実現される。
【０１９３】
Ｐ２：クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は自分より前（より基本的な型属性）とする（逆順）。機能Ｆ３および機能Ｆ４の組み合わせで実現される。
【０１９４】
Ｐ３：クレンジング処理に制約（前提条件）を定義して、前提条件を守った処理を実現する。制約条件にする型属性は任意の型属性を使える（逆順）。機能Ｆ１，Ｆ２，Ｆ５の組み合わせで実現される。
【０１９５】
Ｐ４：クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は任意の型属性にできる（逆順）。機能Ｆ３，Ｆ５の組み合わせで実現される。
【０１９６】
Ｐ５：クレンジング処理に制約（前提条件）を定義して、前提条件を守った処理を実現する。制約条件にする型属性は任意の型属性を使える（正順）。機能Ｆ１，Ｆ２，Ｆ６の組み合わせで実現される。
【０１９７】
Ｐ６：クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は任意の型属性にできる（正順）。機能Ｆ３，Ｆ６の組み合わせで実現される。以下、機能Ｆ１〜Ｆ７ごとに説明する。
【０１９８】
＜機能Ｆ１＞
図５５は、機能Ｆ１により制約が設定されたクレンジング仕様定義ファイル３０１の一例を示す説明図である。機能Ｆ１は、既存の型属性に対して制約（前提条件）を設定し、その範囲内で動作する。図５５に示したクレンジング仕様定義ファイル３０１は、図２５に示したクレンジング仕様定義ファイル３０１について、人名型に着目して、機能Ｆ１を追加した例である。ここでは、Ｃｈａｒ型が既に定義されているクレンジング仕様定義ファイル３０１に対して、人名のデータ型定義記述５５０１を新規に追加する場合について例示している。
【０１９９】
図５５において、人名のデータ型定義記述５５０１では、新規に追加するクレンジング機能として姓名空白処理機能が定義されている。図４９に示した（実施の形態１における）姓名空白処理機能では、姓名空白処理機能は自分が扱う型属性（ｎａｍｅ＿ｓｐａｃｅ） とは異なる型属性（ｍａｘ＿ｌｅｎｇｔｈ，ｃｈａｒ＿ｅｘｃｏｄｅ，ｃｈａｒ＿ｃｏｄｅ）について、指定可能な全ての組み合わせについてＦｒｏｍ値（変換元）およびＴｏ値（変換先）として扱うことが求められる。例えば、全ての文字コード系（ＳＪＩＳ、ＪＥＦ、ＵＴＦ８）についてＦｒｏｍ値、Ｔｏ値として姓名空白処理を実行する機能が求められる。
【０２００】
機能Ｆ１は、自分が扱う型属性（ｎａｍｅ＿ｓｐａｃｅ）と異なる型属性（ｍａｘ＿ｌｅｎｇｔｈ，ｃｈａｒ＿ｅｘｃｏｄｅ，ｃｈａｒ＿ｃｏｄｅ）に対して、クレンジング機能の動作可能な条件を宣言する機能である。この機能により、姓名空白処理機能が動作可能な条件を指定することができ、姓名空白処理機能を簡略化することができる。
【０２０１】
より具体的には、たとえば、人名のデータ型定義記述５５０１のクレンジングルールタグに、「ｒｕｌｅ＝“ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ”」という制約を設定しておくことで、当該制約により型属性ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳという条件で動作するように実装するだけでよく、他の文字コードに対応する必要がなくなるので、姓名空白処理機能を簡略することができることと併せて、文字コード系としてＵＴＦ１６が追加されるケースなど、他の機能追加の影響を最小化する効果がある。
【０２０２】
＜機能Ｆ２＞
図５６は、機能Ｆ２による変換例を示す説明図である。機能Ｆ２は、クレンジング処理の実行時にはクレンジング処理部によって、機能Ｆ１で指定された制約を守るための変換処理を先に実行した後で、クレンジング処理本体を実行する。図５５において、人名のデータ型定義記述では、新規追加クレンジング機能として姓名空白処理機能が定義され、「ｒｕｌｅ＝“ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ”」という制約が定義されている。図５６においては、新規追加の姓名空白処理機能により姓名空白処理を実行する前に、「ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ」の制約を守るための文字コード系変換を行うことによって、姓名空白処理は文字コード系「ＳＪＩＳ」を前提とした動作で十分となるように制御できる。
【０２０３】
＜機能Ｆ３＞
機能Ｆ３では、新規追加機能は、当該機能が担当する型属性とは別の型属性に対する必要な変換を行う機能を有し、自ら型属性値を変更することを許す。この場合は機能Ｆ１の制約の定義と、機能Ｆ２の制約を守るためのクレンジング処理部の機能は不要になるので、クレンジング仕様定義ファイル３０１は図２５に示す人名型の定義と同じでよい。また、機能Ｆ３による他の型属性の変換機能は、追加するクレンジング機能がクレンジング制御部に依頼して実行することも可能である。前述の姓名空白処理について機能Ｆ３を適用すると、姓名空白処理の前に自ら型属性ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳという変換を行い、型属性値を変更する機能を持たせることになる。
【０２０４】
＜機能Ｆ４＞
機能Ｆ４は、型属性を合わせるクレンジング処理の順番を、後方（より特殊な型属性）から処理する。すなわち、逆順で実行する機能である。この場合、機能Ｆ１において制約に指定できる型属性、または機能Ｆ３で変更できる型属性は、自分より前の（自分より基本的な）型属性とする。
【０２０５】
これにより、新しく追加した型属性（機能）から先に実行され、同時に処理が済んだ基本的な型属性を変更することにより、既存の機能が動作することを抑制することができる。また、機能Ｆ２の制約による前処理のための制御戻り（無理やり変更した部分に戻って再処理すること）が不要になる。前述の姓名空白処理における文字コード系の制約のように、自分より前の（自分より基本的な）型属性を制約とする場合が多いので、機能Ｆ４は有効である。
【０２０６】
＜機能Ｆ５〜Ｆ７＞
機能Ｆ５〜Ｆ７は、すべての型属性を制約として扱うための機能である。機能Ｆ４は、クレンジング処理の制約（前提条件）として、自分が扱う型属性より前方に定義されている（より基本的な）型属性に限定している。一般的にこの方が処理効率が良いので、この条件で十分なケースでは、機能Ｆ４で実装すべきである。一方、自分が扱う型属性より後方向に定義されている（より拡張的な）型属性も制約条件にする必要があるケースでは、機能Ｆ５により実現できる。
【０２０７】
図５７は、機能Ｆ５による変換例を示す説明図である。機能Ｆ５では、クレンジング処理の制約（前提条件）については、自分以外のすべての型属性を扱えるように拡張する。その上で、最後に実行した変換が扱う型属性から、順番に処理して、一巡するまでは、繰り返し変換処理を実行するように構成する。
【０２０８】
図５８は、機能Ｆ６の一例を示す説明図である。機能Ｆ５の処理する順番は、必ずしも後方向（より拡張的な型属性）から前方に向かう（逆順である）必要はない。したがって、機能Ｆ６のように、正順（より基本的な型属性から順に拡張的な型属性を処理する）でも処理は完結する。したがって、効率よい処理方向を選択することも可能になる。
【０２０９】
以下に、実施の形態２の一実施例について説明する。ここでは、図５５に示したクレンジング仕様定義ファイル３０１における人名データ型定義記述で定義されている姓名空白処理を例に挙げて説明する。
【０２１０】
図５９は、制約の導入例を示す説明図である。図５９において、人名データ型定義記述で定義されている姓名空白処理では、「ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ」の制約を宣言している。これにより、姓名空白処理は、担当する型属性：ｎａｍｅ＿ｓｐａｃｅ（型属性ＩＤ＝４）がＦｒｏｍ側とＴｏ側で異なるときに実行されることと併せて、型属性：ｃｈａｒ＿ｃｏｄｅ（型属性ＩＤ＝１）の型属性値がＳＪＩＳ（型属性値ＩＤ＝０）であるという前提のもとに実行される。したがって、追加実装したいときは、クレンジングルールにおいて制約を宣言するだけでよく、ＳＪＳＩ以外の文字コード系に対応する必要はなくなるので、クレンジング機能の実装を大幅に簡素化することができる。
【０２１１】
制約を導入する場合、クレンジング仕様定義ファイル３０１の初期化時（図５１）に、制約条件をクレンジングルールとともに変換ルールから参照できるように、制約条件テーブルを生成して、制約として展開する。具体的には、制約を宣言したクレンジング処理のクレンジングルールテーブル３３２と併せて参照できるような構造として、該当するクレンジング機能が設定されているＦｒｏｍ／Ｔｏの組み合わせと同一箇所に、コード化された制約を制約条件テーブルとして設定する。
【０２１２】
図６０は、制約条件テーブルの一例を示す説明図である。姓名空白処理が担当するｎａｍｅ＿ｓｐａｃｅ型属性用クレンジングルールテーブル３３２では、Ｆｒｏｍ／Ｔｏが（１，０）と（０，１）の場合に、姓名空白処理機能が呼び出される。したがって、姓名空白処理に関する制約条件は、クレンジングルールテーブル３３２と同じ構造で、同様に、Ｆｒｏｍ／Ｔｏが（１，０）と（０，１）の位置にコード化した制約条件『１（ｃｈａｒ＿ｃｏｄｅ）＝０（ＳＪＩＳ）』を設定することにより、図６０に示すｎａｍｅ＿ｓｐａｃｅ用制約条件テーブル６０００を作成する。
【０２１３】
図６１は、制約が追加された場合の変換ルール群３３０を示す説明図である。図６１の変換ルール群３３０は、図４３に示した変換ルール群３３０に制約条件を展開した状態を示している。図６１において、各データ型用変換ルールテーブル４３０１〜４３０４には、制約条件用のレコードが追加される。制約条件用のレコードにおいて、デフォルトは「ＮＵＬＬ」である。図５９のように制約が導入された場合、該当するデータ型用変換ルールテーブル４３０１〜４３０４の制約条件用のレコードにおいて、該当するクレンジングルールに対して制約条件テーブルへのポインタを設定する。
【０２１４】
図６１では、人名型用変換ルールテーブルの配列番号［４］に対して、ｎａｍｅ＿ｓｐａｃｅ用クレンジングルールテーブル３３２の呼び出しポインタとともに、ｎａｍｅ＿ｓｐａｃｅ用制約条件テーブルの呼び出しポインタが設定されている。これにより、人名型用変換ルールテーブルの配列番号［４］が指定されると、ｎａｍｅ＿ｓｐａｃｅ用クレンジングルールテーブル３３２が呼び出されるとともに、ｎａｍｅ＿ｓｐａｃｅ用制約条件テーブルも参照可能になる。つぎに、制約を導入した場合のデータ変換処理例について説明する。ここでは、機能Ｆ１，Ｆ２，Ｆ４を組み合わせた制御パターンＰ１を用いたデータ変換処理例について説明する。
【０２１５】
図６２〜図６６は、図４４に示した表Ａおよび表Ｂの氏名に関するコード化メタ定義情報３４０を用いたデータ変換例２を示す説明図である。まず、初期化処理により、あらかじめデータ型や型属性、型属性値のコード化が行われ、各処理はコードの意味を認知している。つぎに、図６２に示したコード化メタ定義３４０および値の情報がクレンジング制御部３５１に与えられ、変換処理が開始される。
【０２１６】
クレンジング制御部では、まず、Ｆｒｏｍ側とＴｏ側とのデータ型の比較をおこなう。具体的には、Ｆｒｏｍ側のコード化メタ定義情報３４０とＴｏ側のコード化メタ定義情報３４０について、配列番号［０］（データ型）の値が比較される。この場合は、ともに“２”（人名）で同じデータ型と認識される。
【０２１７】
データ型が同じであるため、つぎに、Ｆｒｏｍ側とＴｏ側との型属性の比較をおこなう。本例では、機能Ｆ４を採用するため、末尾の型属性である配列番号［４］（ｎａｍｅ＿ｓｐａｃｅ）の値どうしが比較される。図６２では、Ｆｒｏｍ側が“０”（Ｙｅｓ）、Ｔｏ側が“１”（Ｎｏ）であるため、図６１の変換ルール群３３０により変換処理を特定する。
【０２１８】
具体的には、データ型ＩＤ：２（人名）であるため、データ型ＩＤ：２を配列番号として変換ルールテーブル４３００を参照することにより、人名型用変換ルールテーブル４３０２を取得する。
【０２１９】
つぎに、人名型用変換ルールテーブル４３０２において現在比較している配列番号［４］のｎａｍｅ＿ｓｐａｃｅ用クレンジングルールテーブル３３２（図３９）を参照する。つぎに、図３９のｎａｍｅ＿ｓｐａｃｅ用クレンジングルールテーブル３３２について、着目しているコード化メタ定義３４０の値であるＦｒｏｍ側が“１”（Ｎｏ）、Ｔｏ側が“０”（Ｙｅｓ）で参照することによって、姓名空白処理機能の呼び出しポインタを特定する。この姓名空白処理は、つぎの制約条件に対する処理の実行後に実行されることとなる。
【０２２０】
また、人名型用変換ルールテーブル４３０２において現在比較している配列番号［４］の制約条件を参照すると、ｎａｍｅ＿ｓｐａｃｅ用制約条件テーブル（図６０）が設定されているので、ｎａｍｅ＿ｓｐａｃｅ用制約条件テーブルを使用した制約条件に対する処理に移行する。図６０のｎａｍｅ＿ｓｐａｃｅ用制約条件テーブル６０００について、着目しているコード化メタ定義３４０の値であるＦｒｏｍ側が“１”（Ｎｏ）、Ｔｏ側が“０”（Ｙｅｓ）で参照することによって、制約条件『１（ｃｈａｒ＿ｃｏｄｅ）＝０（ＳＪＩＳ）』を特定する。
【０２２１】
つぎに、図６３に示すように、特定された制約条件『１（ｃｈａｒ＿ｃｏｄｅ）＝０（ＳＪＩＳ）』を遵守するため、ｎａｍｅ＿ｓｐａｃｅ型属性に基づく姓名空白処理に先立って、型属性ＩＤ：１（文字コード系）をＦｒｏｍ側の値から制約条件に変換する処理を先に実行する。尚、図６３〜図６６は各処理の実行後の状態を示しており、網掛け部分は値の更新を示している。
【０２２２】
具体的には、制約条件『１（ｃｈａｒ＿ｃｏｄｅ）＝０（ＳＪＩＳ）』で指定された型属性ＩＤ：１について、Ｆｒｏｍ定義の値と、制約条件の値を比較して、制約条件に合っているかを確認する。この例では、図６２に示すようにＦｒｏｍ定義の値“１”（ＪＥＦ） ≠ 制約条件の値“０”（ＳＪＩＳ）であるので、Ｆｒｏｍ側を制約条件に合わせる処理が先に必要になる。Ｆｒｏｍ定義はデータ型ＩＤ：２であるため、データ型ＩＤ：２を配列番号として図６１の変換ルールテーブル４３００を参照して、人名型用変換ルールテーブル４３０２を参照する。
【０２２３】
つぎに、人名型用変換ルールテーブル４３０２において現在比較している配列番号［１］のｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２（図３７）を参照する。図６２に示したように、Ｆｒｏｍ側が“１”（ＪＥＦ）、Ｔｏ側（制約条件）が“０”（ＳＪＩＳ）であるため、図３７のｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２をＦｒｏｍ［１］、Ｔｏ［０］で参照して文字コード系変換処理の呼び出しポインタを特定する。そして、特定された呼び出しポインタにより文字コード系変換処理を呼び出して、文字コード系変換処理を実行する。これにより、図６３に示すように、文字コード系がＪＥＦであるＦｒｏｍ値の対象文字列「山田 和夫」が制約条件であるＳＪＩＳに変換されＴｏ値に設定され、Ｆｒｏｍ定義の項目番号［１］（ｃｈａｒ＿ｃｏｄｅ）の値が、”０”（ＳＪＩＳ）に更新される。
【０２２４】
つぎに、図６４に示すように、保留しておいた姓名空白処理を実行する。姓名空白処理では、図６３に示すように、Ｆｒｏｍ側のコード化メタ定義情報３４０の配列番号［４］（ｎａｍｅ＿ｓｐａｃｅ）は“０”（Ｙｅｓ）、Ｔｏ側のコード化メタ定義情報３４０の配列番号［４］では“１”（Ｎｏ）であるため、図６４に示すように、ＳＪＩＳに変換された対象文字列「山田 和夫」をＦｒｏｍ値として、姓名間の空白が削除され、ＳＪＩＳの「山田和夫」としてＴｏ値に設定される。そして、Ｆｒｏｍ側のコード化メタ定義情報３４０の配列番号［４］の値を“０”（Ｙｅｓ）から“１”（Ｎｏ）に更新する。
【０２２５】
つぎに、図６５に示すように、一つ前の配列番号［３］（ｍａｘ＿ｌｅｎｇｔｈ）の処理を実行する。具体的には、図６４に示す配列番号［３］（ｍａｘ＿ｌｅｎｇｔｈ）の値について、Ｆｒｏｍ定義とＴｏ定義との比較をおこなう。この場合は、Ｆｒｏｍ側が“２０”、Ｔｏ側が“１４”であり、値が異なるため、図６１の変換ルール群３３０により変換処理を特定する。
【０２２６】
更に具体的には、データ型ＩＤ：２（人名）であるため、データ型ＩＤ：２を配列番号として変換ルールテーブル４３００を参照することにより人名型用変換ルールテーブル４３０２を得る。
【０２２７】
つぎに、取得した人名型用変換ルールテーブル４３０２において現在比較している配列番号［３］の変換ルールによりｍａｘ＿ｌｅｎｇｔｈ用クレンジングルールテーブル３３２（図４１）を参照する。ｍａｘ＿ｌｅｎｇｔｈ型属性は任意の値をとるため、図４１のｍａｘ＿ｌｅｎｇｔｈ用クレンジングルールテーブル３３２において、Ｆｒｏｍ／Ｔｏの値にかかわらず、Ｆｒｏｍ［０］，Ｔｏ［０］のｌｅｎｇｔｈ調整処理の呼び出しポインタを特定する。
【０２２８】
また、図６１において、配列番号［３］では、制約条件テーブルの呼び出しポインタが設定されておらず、ＮＵＬＬとなっているため、そのまま、ｌｅｎｇｔｈ調整処理を実行する。図６５に示すように、姓名間の空白を削除されたＳＪＩＳのＦｒｏｍ値文字列「山田和夫」に対しては４の文字８バイトしかないため、ｌｅｎｇｔｈ調整処理が実行されてもＴｏ値はＦｒｏｍ値と同じ値となる。また、Ｆｒｏｍ定義［３］（ｍａｘ＿ｌｅｎｇｔｈ）の値は変換後の状態である“１４”（１４バイト）に更新される。
【０２２９】
つぎに、図６６に示すように、一つ前の配列番号［２］（ｃｈａｒ＿ｅｘｃｏｄｅ）の処理を実行する。具体的には、図６５に示す配列番号［２］（ｃｈａｒ＿ｅｘｃｏｄｅ）の値について、Ｆｒｏｍ定義とＴｏ定義との型の比較をおこなう。この場合は、Ｆｒｏｍ定義が“０”（外字１）、Ｔｏ定義が“１”（外字２）であり、値が異なるため、図６１の変換ルール群３３０により変換処理を特定する。
【０２３０】
更に具体的には、データ型ＩＤ：２（人名）であるため、データ型ＩＤ：２を配列番号として変換ルールテーブル４３００を参照することによって、人名型用変換ルールテーブル４３０２を取得する。
【０２３１】
つぎに、取得した人名型用変換ルールテーブル４３０２において現在比較している配列番号［２］のｃｈａｒ＿ｅｘｃｏｄｅ用クレンジングルールテーブル３３２（図３８）を参照する。図６５に示したように、Ｆｒｏｍ側が“０”（外字１）、Ｔｏ側が“１”（外字２）であるため、図３８のｃｈａｒ＿ｅｘｃｏｄｅ用クレンジングルールテーブル３３２をＦｒｏｍ［０］，Ｔｏ［１］で参照して、文字コード系変換処理の呼び出しポインタを特定する。
【０２３２】
そして、特定された呼び出しポインタにより文字コード系変換処理を呼び出して、文字コード系変換処理を実行する。なお、文字コード系変換処理では、ｃｈａｒ＿ｅｘｃｏｄｅだけでなくｃｈａｒ＿ｃｏｄｅについても処理するが、ｃｈａｒ＿ｃｏｄｅについては制約条件により実行済みであるため、ｃｈａｒ＿ｅｘｃｏｄｅのみの変換となる。図６６に示すように、変換結果はＴｏ値にＳＪＩＳ、外字２による「山田和夫」が設定され、Ｆｒｏｍ定義の［２］の値は“１”（外字２）に更新される。
【０２３３】
以上で、データ型およびすべての型属性が同じになったので、変換処理を終了する。このように、先頭のデータ型の次は、定義の値を右から順に順次比較して、異なる場合に処理を特定して実行する。また、制約条件が設定されている場合は、先に制約条件を守るための変換を行うことを繰り返す。これにより、柔軟性を損なうことなく、制約を遵守したデータ変換処理を最小限のコストで実現することができる。
【０２３４】
また、型属性を後方（右側）から順に処理することにより、新しく追加された型属性が先に評価され、新変換機能が優先して実行される。また、新変換機能と競合する旧変換機能は、新変換機能が旧変換機能の型属性を変更することができる。したがって、新変換機能の制御下で動作を抑制することができる。
【０２３５】
たとえば、図６６に示したように、型属性を後方（右側）から順に処理することにより、新規追加型属性であるｃｈａｒ＿ｅｘｃｏｄｅが旧型属性であるｃｈａｒ＿ｃｏｄｅよりも先に評価され、新変換機能（文字コード系変換処理）が優先して実行される。またこの場合、新変換機能と旧変換機能はともに文字コード系変換処理であるため、先に実行される文字コード系変換処理において、ｃｈａｒ＿ｃｏｄｅ型属性を変換することで、旧変換機能での文字コード系変換処理を抑制することが可能となる。すなわち、重複処理を回避することができる。
【０２３６】
＜データ変換処理手順＞
つぎに、実施の形態２にかかるデータ変換装置３００によるデータ変換処理手順について、図６７〜図７２を用いて説明する。
【０２３７】
図６７は、実施の形態２にかかるデータ変換装置３００によるデータ変換処理手順を示すフローチャートである。まず、初期化部３１１により、初期化処理を実行する（ステップＳ６７０１）。初期化処理（ステップＳ６７０１）の詳細については、図６８および図６９において説明する。
【０２３８】
つぎに、クレンジング処理部３１２により、データ変換処理を実行する（ステップＳ６７０２）。データ変換処理（ステップＳ６７０２）の詳細については、図７１において説明する。このあと、データ変換を継続するか否かを判断する（ステップＳ６７０３）。判断基準は、ユーザによる操作入力でもよく、変換対象データの有無でもよい。
【０２３９】
継続する場合（ステップＳ６７０３：Ｙｅｓ）、ステップＳ６７０２に戻って、データ変換処理を実行する。一方、継続しない場合（ステップＳ６７０３：Ｎｏ）、開放処理を実行する（ステップＳ６７０４）。開放処理では、初期化処理（ステップＳ６７０１）で獲得したメモリ上の資源を開放する。これにより、データ変換処理を終了する。
【０２４０】
図６８は、図６７に示した初期化部３１１による初期化処理（ステップＳ６７０１）の詳細な処理手順（前半）を示すフローチャートである。図６８において、まず、クレンジング仕様定義ファイル３０１を読み込んで解析する（ステップＳ６８０１）。つぎに、制御パターン選定処理を実行する（ステップＳ６８０２）。制御パターン選定処理（ステップＳ６８０２）とは、上述した制御パターンＰ１〜Ｐ６および実施の形態１に相当する制御パターンＰ０の中から該当する制御パターンを選定する。制御パターン選定処理（ステップＳ６８０２）の詳細については、図７０において後述する。
【０２４１】
制御パターン選定処理（ステップＳ６８０２）により制御パターンＰが選定された場合、データ型コード表作成処理を実行する（ステップＳ６８０３）。具体的には、各データ型にデータ型ＩＤを付与する。たとえば、図２６に示したように、すべてのデータ型について、定義順に１から始まり隙間のない全体で一意な整数を、データ型ＩＤとして付与する。
【０２４２】
そして、型属性コード表作成処理を実行する（ステップＳ６８０４）。具体的には、各型属性に型属性ＩＤを付与する。たとえば、図２７〜図２９に示したように、データ型毎に、すべての型属性について、祖先のデータ型から順に定義順に１から始まり、隙間のないデータ型内で一意な整数を、型属性ＩＤとして付与する。ここで、継承関係にあるデータ型間においては、共通する型属性の型属性ＩＤはシステム全体で一致するように制御する。
【０２４３】
そして、型属性値コード表作成処理を実行する（ステップＳ６８０５）。具体的には、たとえば、図３０〜図３５に示したように、各型属性値に型属性値ＩＤを付与する。型属性値コード表作成処理（ステップＳ６８０５）の詳細については、図５３に示した処理内容と同一であるため説明を省略する。
【０２４４】
型属性値コード表作成処理（ステップＳ６８０５）のあと、図３６に示したように、データ型変換ルールテーブル３３１を生成する（ステップＳ６８０６）。そして、図３７〜図４２に示したように、クレンジングルールテーブル３３２を生成する（ステップＳ６８０７）。このあと、図６９のステップＳ６９０１に移行する。
【０２４５】
図６９は、図６７に示した初期化部３１１による初期化処理（ステップＳ６７０１）の詳細な処理手順（後半）を示すフローチャートである。クレンジングルールテーブル３３２が生成されたあと、図６９において、選定された制御パターンを識別する（ステップＳ６９０１）。制御パターンＰがＰ０，Ｐ２，Ｐ４，Ｐ６である場合（ステップＳ６９０１：Ｐ０，Ｐ２，Ｐ４，Ｐ６）、ステップＳ６９０３に移行する。一方、制御パターンＰがＰ１，Ｐ３，Ｐ５である場合（ステップＳ６９０１：Ｐ１，Ｐ３，Ｐ５）、図６０に示したように、制約条件テーブルを生成する（ステップＳ６９０２）。そして、ステップＳ６９０３に移行する。
【０２４６】
ステップＳ６９０３では、図６１に示したように、変換ルール群３３０としてまとめる（ステップＳ６９０３）。このあと、メタ定義ファイル３０４を読み込んで解析する（ステップＳ６９０４）。つぎに、解析された情報の種類を順次判断する（ステップＳ６９０５）。具体的には、データ型であるか、型属性であるか、型属性値であるかを判断する。ここでは、メタ定義ファイル３０４の記述順で判断することとなる。
【０２４７】
データ型である場合（ステップＳ６９０５：データ型）、データ型のＩＤ化を実行する（ステップＳ６９０６）。具体的には、データ型コード表３２１（図２６）を参照してデータ型ＩＤに変換する。そして、ステップＳ６９１１に移行する。
【０２４８】
また、情報の種類が型属性値である場合（ステップＳ６９０５：型属性値）、型属性のＩＤ化を実行する（ステップＳ６９０７）。具体的には、型属性コード表３２２（図２７〜図２９）を参照して型属性ＩＤに変換する。そして、ステップＳ６９１１に移行する。
【０２４９】
また、情報の種類が型属性値である場合（ステップＳ６９０５：型属性値）、コード化している型属性値であるか否かを判断する（ステップＳ６９０８）。コード化している型属性値である場合（ステップＳ６９０８：Ｙｅｓ）、型属性値コード表３２３（図３０〜図３５）を参照して、型属性値ＩＤに変換する（ステップＳ６９０９）。そして、ステップＳ６９１１に移行する。
【０２５０】
一方、コード化している型属性値ではない場合（ステップＳ６９０８：Ｎｏ）、整数値である型属性値をそのまま型属性値ＩＤとする（ステップＳ６９１０）。そして、ステップＳ６９１１に移行する。
【０２５１】
ステップＳ６９１１においては、図４４に示したように、メタ定義ファイル３０４内のデータモデルの項目定義をコード化することによって項目メタ定義テーブルを作成する（ステップＳ６９１１）。具体的には、配列番号［０］にデータ型ＩＤを設定し、配列番号［１］、［２］、［３］、…に、その配列番号を型属性ＩＤとする型属性の型属性値ＩＤや型属性値（コード化していない場合）を設定する。たとえば、データモデルが表Ａの従業員項目に関する項目メタ定義テーブルを作成する場合、図４４に示したように、配列番号［０］には従業員番号項目のデータ型である整数型を示すデータ型ＩＤ：４（図２６を参照）を設定し、配列番号［１］には整数型の型属性ＩＤ：１であるｍａｘ＿ｄｉｇｉｔ型属性（図２９参照）の型属性値：１２（図３５参照）を設定する。ここで、ｍａｘ＿ｄｉｇｉｔ型属性の型属性値はコード化していない型属性値なので、メタ定義ファイル３０４で指定されている型属性値：１２をそのまま設定している。
【０２５２】
このあと、メタ定義ファイル３０４内のすべてのデータモデルがコード化されたか否かを判断する（ステップＳ６９１２）。すべてコード化されていない場合（ステップＳ６９１２：Ｎｏ）、ステップＳ６９０５に戻って残りのコード化を行う。一方、すべてコード化された場合（ステップＳ６９１２：Ｙｅｓ）、図４４に示したように、コード化された項目メタ定義の集合として、コード化メタ定義情報３４０を構成する（ステップＳ６９１３）。このあと、データ変換処理（ステップＳ６７０２）に移行する。
【０２５３】
図７０は、図６８に示した制御パターン選定処理（ステップＳ６８０２）の詳細な処理手順を示すフローチャートである。まず、クレンジング仕様定義ファイル３０１に制約があるか否かを判断する（ステップＳ７００１）。具体的には、たとえば、図５５の人名データ型定義５５０１に示したように、制約が宣言されているか否かを判断する。
【０２５４】
制約がある場合（ステップＳ７００１：Ｙｅｓ）、制約の方向を判断する（ステップＳ７００２）。制約の方向判断については、たとえば、制約の対象となる型属性がすべて自分（制約を宣言しているクレンジング定義がある型属性）より上位であるか、制約の対象となる型属性がすべて自分より下位であるか、制約の対象となる型属性が自分より上位の型属性と下位の型属性とが混在しているか、を基準とする。
【０２５５】
たとえば、図５５の例では、制約が「ｒｕｌｅ＝“ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ”」であるため、制約の対象となる型属性は“ｃｈａｒ＿ｃｏｄｅ”である。また、自分（の型属性）は、制約「ｒｕｌｅ＝“ｃｈａｒ＿ｃｏｄｅ＝ＳＪＩＳ”」が宣言されているクレンジングルール（＜ＣＬ＿ＲＵＬＥ＞タグ）を持つ型属性“ｎａｍｅ＿ｓｐａｃｅ”である。この場合、図５５において、“ｃｈａｒ＿ｃｏｄｅ”は“ｎａｍｅ＿ｓｐａｃｅ”よりも上位に定義（同じデータ型定義内の上の行、または継承先のデータ型定義に記述）されているため、制約の方向は「上位」となる。
【０２５６】
上位である場合（ステップＳ７００２：上位）、制御パターンＰ１に決定して（ステップＳ７００３）、ステップＳ６８０３に移行する。一方、下位または混在である場合（ステップＳ７００２：下位または混在）、競合する変換機能があるか否かを判断する（ステップＳ７００４）。ここで、競合する変換機能について説明する。
【０２５７】
例えば、ｃｈａｒ＿ｃｏｄｅ型属性について文字コード系変換を行う一般的な文字コード系変換機能（ここでは文字コード系変換機能１と称する）が使用されている環境に、外字の違いを変換することができる（ｃｈａｒ＿ｃｏｄｅ型属性と併せてｃｈａｒ＿ｅｘｃｏｄｅ型属性に対応することができる）文字コード系変換機能（ここでは文字コード系変換機能２と称する）を追加するときに、外字体系が同じデータの変換は効率的な文字コード系変換機能１を使用し、外字体系が異なるデータの変換は高機能な文字コード系変換機能２を使用したい場合がある。
【０２５８】
このように同じ型属性値に対する変換機能を有する変換機能を同時に使用可能な状態にするとき、両者は「競合する変換機能」であるとする。一般的に文字コード系変換機能２のような高機能なクレンジング機能は後方の型属性に対する変換として設定するので、後方の型属性から先に処理する制御パターンとすることにより競合を解消して効率的な使い分けを実現することができる。
【０２５９】
競合する変換機能がある場合（ステップＳ７００４：Ｙｅｓ）、制御パターンＰ３に決定し（ステップＳ７００５）、競合する変換機能がない場合（ステップＳ７００４：Ｎｏ）、制御パターンＰ５に決定する（ステップＳ７００６）。そして、ステップＳ６８０３に移行する。
【０２６０】
一方、ステップＳ７００１において、クレンジング仕様定義ファイル３０１に制約がない場合（ステップＳ７００１：Ｎｏ）、制約を自ら実行する機能Ｆ３を持つ変換機能があるか否かを判断する（ステップＳ７００７）。具体的には、＜機能Ｆ３＞で前述したように、クレンジング仕様定義ファイル３０１には制約を定義しないため、クレンジング機能の「制約を実行する機能の有無」は、例えばクレンジング仕様定義ファイルのクレンジング機能を定義する部分に、制約を実行する機能の有無と、具体的な制約対象の型属性を示す情報を記載しておき、その情報によって判断することになる。ここで、「具体的な制約対象の型属性」は後述するステップＳ７０１１の判断に必要となる情報である。
【０２６１】
制約を実行する変換機能がない場合（ステップＳ７００７：Ｎｏ）、競合する変換機能があるか否かを判断する（ステップＳ７００８）。ステップＳ７００８は、ステップＳ７００４と同一処理である。競合する変換機能がある場合（ステップＳ７００８：Ｙｅｓ）、制御パターンＰ２に決定する（ステップＳ７００９）。一方、競合する変換機能がない場合（ステップＳ７００８：Ｎｏ）、制御パターンＰ０に決定する（ステップＳ７０１０）。そして、ステップＳ６８０３に移行する。
【０２６２】
また、ステップＳ７００７において、制約を実行する変換機能がある場合（ステップＳ７００７：Ｙｅｓ）、制約の方向を判断する（ステップＳ７０１１）。ステップＳ７０１１は、ステップＳ７００２と同一処理であるが、制約対象の型属性はステップＳ７００７で前述したように別途情報を得る手段を必要とする。下位である場合（ステップＳ７０１１：下位）、制御パターンＰ０に決定する（ステップＳ７０１２）。
【０２６３】
また、上位である場合（ステップＳ７０１１：上位）、制御パターンＰ２に決定する（ステップＳ７０１３）。また、混在である場合（ステップＳ７０１１：混在）、競合する変換機能があるか否かを判断する（ステップＳ７０１４）。ステップＳ７０１４は、ステップＳ７００４と同一処理である。競合する変換機能がある場合（ステップＳ７０１４：Ｙｅｓ）、制御パターンＰ４に決定する（ステップＳ７０１５）。一方、競合する変換機能がない場合（ステップＳ７０１４：Ｎｏ）、制御パターンＰ６に決定する（ステップＳ７０１６）。そして、ステップＳ６８０３に移行する。
【０２６４】
図７１は、図６７に示したデータ変換処理（ステップＳ６７０２）の詳細な処理手順を示すフローチャート（その１）である。まず、未選択のコード化メタ定義情報３４０のペアがあるか否かを判断する（ステップＳ７１０１）。未選択のコード化メタ定義情報３４０のペアがない場合（ステップＳ７１０１：Ｎｏ）、ステップＳ６７０３に移行する。一方、未選択のコード化メタ定義情報３４０のペアがある場合（ステップＳ７１０１：Ｙｅｓ）、未選択のコード化メタ定義情報３４０のペアを選択する（ステップＳ７１０２）。
【０２６５】
つぎに、制御パターンＰを識別する（ステップＳ７１０３）。制御パターンＰがＰ０〜Ｐ２である場合（ステップＳ７１０３：Ｐ０〜Ｐ２）、ステップＳ７１０５に移行する。一方、制御パターンＰがＰ３〜Ｐ６である場合（ステップＳ７１０３：Ｐ３〜Ｐ６）、制約ポイントＲをＲ＝０に設定して（ステップＳ７１０４）、ステップＳ７１０５に移行する。
【０２６６】
ステップＳ７１０５では、定義ポイントｄをｄ＝０に設定し、選択されたコード化メタ定義情報３４０のペアを参照して、定義ポイントｄの最大値Ｄを取得する（ステップＳ７１０５）。
【０２６７】
このあと、制御パターンＰを識別する（ステップＳ７１０６）。制御パターンＰがＰ０，Ｐ５，Ｐ６である場合（ステップＳ７１０６：Ｐ０，Ｐ５，Ｐ６）、ステップＳ７１０８に移行する。一方、制御パターンＰがＰ１〜Ｐ４である場合（ステップＳ７１０６：Ｐ１〜Ｐ４）、定義ポイントｄを最大値Ｄに設定して（ステップＳ７１０７）、ステップＳ７１０８に移行する。そして、指定されたＦｒｏｍ側のコード化メタ定義情報３４０およびＴｏ側のコード化メタ定義情報３４０について、現在の定義ポイントｄを配列番号として設定されている情報を参照する（ステップＳ７１０８）。つぎに、参照された情報が同じ値か否かを判断する（ステップＳ７１０９）。
【０２６８】
同じ値である場合（ステップＳ７１０９：Ｙｅｓ）、制御パターンＰを識別する（ステップＳ７１１０）。制御パターンＰがＰ１〜Ｐ４である場合（ステップＳ７１１０：Ｐ１〜Ｐ４）、定義ポイントｄをデクリメントして（ステップＳ７１１１）、ステップＳ７１１３に移行する。一方、制御パターンＰがＰ０，Ｐ５，Ｐ６である場合（ステップＳ７１１０：Ｐ０，Ｐ５，Ｐ６）、定義ポイントｄをインクリメントして（ステップＳ７１１２）、ステップＳ７１１３に移行する。
【０２６９】
そして、ステップＳ７１１３において、再度制御パターンＰを識別する（ステップＳ７１１３）。制御パターンＰがＰ１，Ｐ２である場合（ステップＳ７１１３：Ｐ１，Ｐ２）、定義ポイントｄがｄ＝０であるか否かを判断する（ステップＳ７１１４）。そして、ｄ＝０でない場合（ステップＳ７１１４：Ｎｏ）、ステップＳ７１０８に戻り、ｄ＝０である場合（ステップＳ７１１４：Ｙｅｓ）、ステップＳ７１０１に戻る。
【０２７０】
また、制御パターンＰがＰ０である場合（ステップＳ７１１３：Ｐ０）、定義ポイントｄがｄ＝Ｄであるか否かを判断する（ステップＳ７１１５）。そして、ｄ＝Ｄでない場合（ステップＳ７１１５：Ｎｏ）、ステップＳ７１０８に戻り、ｄ＝Ｄである場合（ステップＳ７１１５：Ｙｅｓ）、ステップＳ７１０１に戻る。
【０２７１】
また、制御パターンＰがＰ３〜Ｐ６である場合（ステップＳ７１１３：Ｐ３〜Ｐ６）、定義ポイントｄがｄ＝Ｒであるか否かを判断する（ステップＳ７１１６）。そして、ｄ＝Ｒでない場合（ステップＳ７１１６：Ｎｏ）、ステップＳ７１０８に戻り、ｄ＝Ｒである場合（ステップＳ７１１６：Ｙｅｓ）、ステップＳ７１０１に戻る。
【０２７２】
また、ステップＳ７１０９において、Ｓ７１０８で参照された情報が同じ値でない場合（ステップＳ７１０９：Ｎｏ）、図７２のステップＳ７２０１に移行する。
【０２７３】
図７２は、図６７に示したデータ変換処理（ステップＳ６７０２）の詳細な処理手順を示すフローチャート（その２）である。
【０２７４】
まず、Ｆｒｏｍ側のコード化メタ定義情報３４０を配列番号［０］で参照することによりＦｒｏｍ側のデータ化ＩＤを取得し、取得したデータ型ＩＤを配列番号にして変換ルールテーブル４３００を参照し、該当するデータ型用変換ルールテーブル４３０１〜４３０４を取得する（ステップＳ７２０１）。取得されたテーブルを「特定データ型用変換ルールテーブル」と称す。
【０２７５】
このあと、制御パターンＰを識別する（ステップＳ７２０２）。制御パターンＰがＰ０，Ｐ２，Ｐ４，Ｐ６である場合（ステップＳ７２０２：Ｐ０，Ｐ２，Ｐ４，Ｐ６）、ステップＳ７２０７に移行する。一方、制御パターンＰがＰ１，Ｐ３，Ｐ５である場合（ステップＳ７２０４：Ｐ１，Ｐ３，Ｐ５）、制約条件があるか否かを判断する（ステップＳ７２０３）。
【０２７６】
この、ステップＳ７２０３の処理は、特定データ型用変換ルールテーブルについて定義ポイントｄを配列番号として参照することによって、変換ルールテーブル（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）の取得を行い、その変換ルールテーブルについて、ステップＳ７１０８で参照したコード化メタ定義ペアの値をそれぞれ、Ｆｒｏｍ／Ｔｏの配列番号として制約条件の参照を行い、ＮＵＬＬであれば、制約条件がないと判断し、ＮＵＬＬ以外であれば制約条件があると判断して、その制約条件テーブルへのポインタを記憶しておく。
【０２７７】
このとき、ステップＳ７１０８で参照したコード化メタ定義ペアの値がコード化されない任意の値である場合は、Ｆｒｏｍ／Ｔｏの配列番号は共に［０］として変換ルールテーブルの参照を行い、制約条件を参照する。制約条件がない場合（ステップＳ７２０３：Ｎｏ）、ステップＳ７２０７に移行する。
【０２７８】
一方、制約条件がある場合（ステップＳ７２０３：Ｙｅｓ）、制約条件を実行する（ステップＳ７２０４）。この制約条件の実行は、図６２〜図６４で説明したように、現在の値の状態をＦｒｏｍ定義とし、制約条件をＴｏ定義とする他は通常のクレンジング処理に準じた処理である。つぎに、再度制御パターンＰを識別する（ステップＳ７２０５）。制御パターンＰがＰ１である場合（ステップＳ７２０５：Ｐ１）、ステップＳ７２０７に移行する。一方、制御パターンＰがＰ３，Ｐ５である場合（ステップＳ７２０５：Ｐ３，Ｐ５）、制約ポイントＲを現在の定義ポイントｄに設定し（ステップＳ７２０６）、ステップＳ７２０７に移行する。
【０２７９】
このあと、ステップＳ７２０７では、特定データ型用変換ルールテーブルについて定義ポイントｄを配列番号として参照することによって、変換ルールテーブル（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）の取得を行い、その変換ルールテーブルについて、ステップＳ７１０８で参照したコード化メタ定義ペアの値をそれぞれ、Ｆｒｏｍ／Ｔｏの配列番号として実行すべき変換機能を取得する（ステップＳ７２０７）。このとき、ステップＳ７１０８で参照したコード化メタ定義ペアの値がコード化されない任意の値である場合は、Ｆｒｏｍ／Ｔｏの配列番号は共に［０］として変換ルールテーブルの参照を行い、実行すべき変換機能を取得する（ステップＳ７２０７）。
【０２８０】
そして、取得された変換機能により変換処理を実行する（ステップＳ７２０８）。具体的には、たとえば、Ｆｒｏｍ値を変換してＴｏ値に設定する。また、対処済みの定義内容をＦｒｏｍ定義に反映する（図４５〜図４９を参照。）。このあと、図７１のステップＳ７１１０に戻る。
【０２８１】
このように、実施の形態２では、多様な条件で動作するクレンジング機能を低負担で開発することができる。また、新たなクレンジング機能の追加においても、既存の機能への悪影響を与えることなく、柔軟に対応することができる。さらに、クレンジング機能がリアルタイム処理を含む様々な機能から実行される場合であっても、高性能化を図ることができる。
【０２８２】
つぎに、上述した実施の形態１および実施の形態２で説明したデータ変換装置の機能的構成について説明する。
【０２８３】
図７３は、実施の形態にかかるデータ変換装置の詳細な機能的構成を示すブロック図である。図７３では、図３−１に示した初期化部３１１とクレンジング処理部３１２の詳細な機能的構成を示している。まず、初期化部３１１の詳細な機能的構成について説明する。なお、記憶部７３１０には、クレンジング仕様定義ファイル３０１、型変換機能ライブラリ３０２、クレンジング機能ライブラリ３０３、メタ定義ファイル３０４が記憶されているものとする。
【０２８４】
初期化部３１１は、仕様定義情報取得部７３００と、第１の設定部７３０１と、第２の設定部７３０２と、構築部７３０３と、第３の設定部７３０４と、メタ定義情報取得部７３０５と、生成部７３０６と、補完部７３０７と、を有する。
【０２８５】
仕様定義情報取得部７３００は、変換元（Ｆｒｏｍ側）のメタデータおよび変換先（Ｔｏ側）のメタデータとして使用することができるデータ変換装置が扱うメタデータの仕様（データ型、型属性、型属性値など）と、それらの組み合わせとして実現できるデータ変換機能を定義した仕様定義情報を取得する機能を有する。
【０２８６】
ここで、仕様定義情報とは、データ変換の仕様を定義した情報であり、たとえば、上述したクレンジング仕様定義ファイル３０１が挙げられる。また、メタデータとは、変換対象データそのものではなく、変換対象データの性質に関する情報と、対象データ間の関連情報である。上述したクレンジング仕様定義ファイル３０１では、データの性質を表すデータ型、型属性、型属性値、および、データの構造を表す表、カラム、マッピングなどがメタデータに相当する。
【０２８７】
データ変換機能とは、変換元のメタデータ（Ｆｒｏｍ定義）で定義された性質を持つ変換元のデータ値（Ｆｒｏｍ値）を、変換先のメタデータ（Ｔｏ定義）で定義されたデータ値（Ｔｏ値）に変換する機能である。データ変換機能は、具体的には、たとえば、図３−１〜図３−３に示した型変換機能やクレンジング機能に相当する。また、上述したクレンジング仕様定義ファイル３０１においては、型変換機能の場合は、変換できるデータ型の組み合わせと併せてＤＴＣＶ＿ＲＵＬＥタグ４１１で定義されている。また、クレンジング機能の場合は、変換できる型属性および型属性値の組み合わせと併せて、クレンジングルール定義タグ（ＣＬ＿ＲＵＬＥタグ）４１４で定義されている。
【０２８８】
第１の設定部７３０１は、仕様定義情報取得部７３００によって取得された仕様定義情報に基づいて、データ変換装置で使用できるメタデータの仕様を確定し、確定したメタデータの仕様について、外部表現で規定されているメタデータ仕様を可能な限りＩＤ化（数値化）してメタデータコードとすることによって、内部表現のメタデータ仕様を作成する機能を有する。ここで、メタデータコードとは、メタデータ仕様の外部表現に対応する数値コードである。また、メタデータ仕様の外部表現とメタデータコードを対応付けるために管理表としてメタデータコード化テーブルを作成する。
【０２８９】
たとえば、図２６に示したように、メタデータ仕様がデータ型である場合、メタデータコードは、データ型ＩＤである。そして、第１の設定部７３０１は、メタデータコード化テーブルとして、データ型コード表３２１を設定する。
【０２９０】
また、図２７〜図２９に示したように、メタデータ仕様が型属性である場合、メタデータコードは、型属性ＩＤである。そして、第１の設定部７３０１は、メタデータコード化テーブルとして、型属性コード表３２２を設定する。また、図３０〜図３３に示したように、メタデータ仕様が型属性値である場合、メタデータコードは、型属性値ＩＤである。そして、第１の設定部７３０１は、メタデータコード化テーブルとして、型属性値コード表３２３を設定する。
【０２９１】
また、メタデータ仕様が任意の値を取ることができる場合、メタデータ仕様の外部表現をそのままメタデータコードにする。たとえば、図３４に示したように、型属性：ｍａｘ＿ｌｅｎｇｔｈの型属性値は任意の値をとるため、メタデータコード化テーブルとして、「そのまま値を使用する」という情報を記録した型属性値コード表３２３を設定する。
【０２９２】
また、仕様定義情報において定義された第１のメタデータ仕様を、第２のメタデータ仕様が継承する記述が定義されている場合、仕様定義情報における第１のメタデータ仕様の下位階層のメタデータ仕様のメタデータコードを、第２のメタデータ仕様の下位階層のメタデータ仕様として取り込むようなメタデータコード化テーブルを設定することとしてもよい。
【０２９３】
具体的には、図９に示したデータ型の継承を規定することができる。たとえば、第１のメタデータ仕様がｃｈａｒ型で、第２のメタデータ仕様が人名型である場合、人名型の下位階層となる型属性や型属性値は、ｃｈａｒ型の型属性や型属性値を引き継いで、図２７に示したような型属性コード表３２２を設定することができる。
【０２９４】
継承の機能によって下位階層のメタデータ仕様について共通部分が統一されるため、処理系全体の矛盾を解消し、重複するデータ変換を防止することができる。
【０２９５】
また、第２の設定部７３０２は、第１の設定部７３０１によって設定されたメタデータコード化テーブルを参照することにより、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに応じてデータ変換機能を関連付けることにより、データ変換ルールテーブルを設定する機能を有する。ここで、データ変換ルールテーブルとは、変換元のメタデータコードと変換先のメタデータコードとの組み合わせによりデータ変換機能を特定するテーブルである。上述した実施の形態では、データ型変換ルールテーブルとクレンジングルールテーブルが該当する。
【０２９６】
たとえば、メタデータ仕様がデータ型である場合、図３６に示したように、データ変換ルールテーブルはデータ型変換ルールテーブルとなり、メタデータ仕様が型属性である場合、図３７〜図４２に示したように、その型属性値に基づいてデータ変換（クレンジング）するクレンジングルールテーブルとなる。
【０２９７】
また、構築部７３０３は、第２の設定部７３０２によって設定された変換ルールテーブルごとに上位の変換ルールコードと関連付けることにより、変換ルールを構築する機能を有する。ここで、変換ルールコードとは、変換ルールテーブルが適用される上位のメタデータ仕様に割り当てられたコードである。
【０２９８】
具体的には、たとえば、最上位のメタデータ仕様がデータ型である場合、図４３に示したように、最上位の変換ルールコードはデータ型ＩＤである。最上位であるデータ型変換ルールテーブルに対しては、直下の階層における変換ルールコードとして０が割り当てられる。また、メタデータ仕様が型属性である場合、図４３に示したように、各型属性に適用されるクレンジングルールテーブル３３２に対し、型属性ＩＤが割り当てられる。
【０２９９】
そして、構築部７３０３は、これらをまとめあげることで、変換ルールとして、データ型用変換ルールテーブル４３０１〜４３０４を構築する。また、データ型が複数ある場合には、図４３に示したように、データ型用変換ルールテーブル４３０１〜４３０４をまとめあげて、変換ルール群３３０を構築する。
【０３００】
また、第３の設定部７３０４は、データ変換機能に制約条件が設定されている場合、データ変換機能が設定されている変換ルールテーブルをコピーして、データ変換機能に代えて、制約条件を割り当てることにより、制約条件テーブルを設定する機能を有する。具体的には、たとえば、実施の形態２において、図６０で説明したように、クレンジングルールテーブル３３２をコピーしてデータ変換機能に対応する制約条件を設定することによって制約条件テーブル６０００を作成する。そして、構築部７３０３により、制約条件テーブル６０００は、図６１に示したように、データ変換機能と併せて参照できるように構成される。
【０３０１】
また、メタ定義情報取得部７３０５は、変換元および変換先のメタデータが定義されたメタ定義情報を取得する機能を有する。ここで、メタ定義情報とは、変換元と変換先のデータについて、その性質および構造をあらわすメタデータを定義するとともに、どの変換元と変換先の関連を定義した情報である。たとえば、上述したメタ定義ファイル３０４が該当する。
【０３０２】
また、生成部７３０６は、メタ定義情報取得部７３０５によって取得されたメタ定義情報内のメタデータごとに、当該メタデータの第一の設定部７３０１で割り当てられた変換ルールコードを使用してコード化することにより、コード化メタ定義情報を生成する機能を有する。具体的には、たとえば、メタ定義ファイル３０４内のデータ型や型属性、型属性値に、そのデータ型や型属性、型属性値に、データ型ＩＤ，型属性ＩＤ、型属性値ＩＤによりコード化する（図４４を参照。）。このように処理系全体で統一したコード化を行うことで、変換ルール群３３０との照合の効率化を実現することができる。
【０３０３】
また、補完部７３０７は、メタ定義情報取得部７３０５によって取得されたメタ定義情報内に省略されているメタデータが有る場合に、仕様定義情報取得部から取得して補完部に記憶しているメタデータ仕様のデフォルト値指定を利用して省略されているメタデータを補完する機能を有する。具体的には、たとえば、図１６に示したように、クレンジング仕様定義ファイル３０１において、型属性のデフォルト属性値として“ｃｈａｒ＿ｃｏｄｅ：ＪＥＦ”、“ｍａｘ＿ｌｅｎｇｔｈ：２０”、“ｎａｍｅ＿ｓｐａｃｅ：Ｙｅｓ”のように指定されている場合に、図１７の下段に示すように型属性が省略されたメタ定義ファイル３０４をメタ定義情報取得部が取得すると、記憶している型属性とそのデフォルト値を使用して補完することによって、図１７上段のメタ定義ファイル３０４と等価なコード化メタ定義情報に補正することができる。
【０３０４】
これにより、メタ定義ファイル３０４であは意味を保ったまま簡略化することができる。つぎに、クレンジング処理部３２１の詳細な機能的構成について説明する。
【０３０５】
図７３において、クレンジング処理部３２１は、入力部７３１１と、検出部７３１２と、判断部７３１３と、変換機能特定部７３１４と、テーブル特定部７３１５と、変換部７３１６と、更新部７３１７と、出力部７３１８とを有する。検出部７３１２、判断部７３１３、変換機能特定部７３１４、およびテーブル特定部７３１５は、図３−１に示したクレンジング制御部３５１を構成する機能である。
【０３０６】
入力部７３１１は、変換対象データの入力を受け付ける機能を有する。具体的には、たとえば、メタ定義ファイル３０４で定義された変換元のメタデータを持つ変換対象データの入力を受け付ける。変換対象データの入力と併せて、変換元のメタデータを特定する情報も指定することにより、変換対象データの変換元のメタデータが特定されれば、メタ定義ファイル３０４にて変換先が定義されているため、メタ定義ファイル３０４に従ってデータ変換を実行することができる。ここで、変換先のメタデータを特定する情報も指定するように構成することもできる。
【０３０７】
また、検出部７３１２は、コード化メタ定義情報３４０を参照することにより、変換元および変換先で変換ルールコードが一致する変換元および変換先のメタデータコードを検出する機能を有する。具体的には、たとえば、図４４に示したように、変換元（表Ａ）と変換先（表Ｂ）とで、変換ルールコードである配列番号が一致する変換元（表Ａ）のデータ型ＩＤ／型属性値ＩＤと変換先（表Ｂ）のデータ型ＩＤ／型属性値ＩＤとを検出する。
【０３０８】
たとえば、図４４の（Ｂ）において、変換元（表Ａの氏名）と変換先（表Ｂの氏名）とで一致する配列番号：０（データ型）について、変換元（表Ａの氏名）のデータ型ＩＤ：２（人名型）と変換元（表Ｂの氏名）のデータ型ＩＤ：２（人名型）とを検出する。
【０３０９】
また、コード化メタ定義情報３４０において、図４４に示したように、変換ルールコード（配列番号）が、メタデータの優先順位順の連続番号として割り当てられている場合、優先順位の高い順から変換元（表Ａ）と変換先（表Ｂ）とのメタデータコード（データ型ＩＤ／型属性値ＩＤ）を検出して、一致判断することとしてもよい。これにより、重要な型属性から順次クレンジングが実行されることになるため、無駄な処理の発生を防止でき、クレンジング処理の簡素化を図ることができる。
【０３１０】
また、判断部７３１３は、検出部７３１２によって検出された変換元のメタデータコードと変換先のメタデータコードとが一致するか否かを判断する機能を有する。一致する場合は変換先として変換元と同じ性質を求めているので、変換元のメタデータコードで規定される性質から変換先のメタデータコードで規定される性質に変換する必要はない。したがって、メタデータコードの一致を検出して変換処理に渡さないことで、データ変換の効率化を図ることができる。
【０３１１】
また、不一致である場合、テーブル特定部７３１５による変換ルールテーブルの特定をおこなう。テーブル特定部７３１５は、判断部７３１３によって不一致であると判断された場合、変換元の変換ルールコードに基づいて変換ルールを参照することにより、データ型変換ルールテーブル３３１（変換ルールコード＝０である場合）またはクレンジングルールテーブル３３２（変換ルールコード≠０である場合）の中から該当する変換ルールテーブルを特定する機能を有する。
【０３１２】
この変換ルールテーブルの特定は、図４３に示した変換ルール群３３０を参照し、変換元のコード化メタ定義の項目番号［０］の値を項目番号として変換ルール４３００を参照することによって該当するデータ型用変換ルールテーブル４３０１〜４３０４を特定し、不一致となった変換ルールコード（コード化メタ定義の項目番号）を項目番号として特定したデータ型用変換ルールテーブルを参照することによって変換ルールテーブル（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）を特定する。
【０３１３】
たとえば、図４４の（Ｂ）の変換ルールコード：１について考えると、配列番号［１］（ｃｈａｒ＿ｃｏｄｅ）では、変換元（表Ａの氏名）は型属性値ＩＤ：１（ＪＥＦ）、変換先（Ｂの氏名）は型属性値ＩＤ：０（ＳＪＩＳ）となり、型属性値ＩＤが不一致である。この場合、変換元（表Ａの氏名）の配列番号［０］（データ型）を配列番号として変換ルール４３００を参照してＣｈａｒ型用のデータ型用変換ルールテーブル４３０１を特定し、処理対象の変換ルールコード：１を配列番号として特定したデータ型用変換ルールテーブル４３０１を参照することによりｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２を特定することとなる。ここで、処理対象の変換ルールコードが［１］である場合には、データ型用変換ルールテーブル４３０１を配列番号［０］で参照することによって、Ｃｈａｒ型用のデータ型変換ルールテーブル３３１と特定することになる。
【０３１４】
また、変換機能特定部７３１４は、判断部７３１３によって判断された判断結果に基づいて、変換ルールテーブルを参照することにより、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに応じてデータ変換機能を特定する機能を有する。具体的には、変換元のメタデータコードをＦｒｏｍ側の配列番号として、変換先のメタデータコードをＴｏ側の配列番号として、テーブル特定部７３１５によって特定された変換ルールテーブル（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）を参照することによって、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに該当するデータ変換機能を特定する。
【０３１５】
たとえば、上述した図４４の（Ｂ）、変換ルールコード：１の例では、ｃｈａｒ＿ｃｏｄｅ用クレンジングルールテーブル３３２（図３７参照）において、Ｆｒｏｍ側の配列番号を変換元（表Ａの氏名）の型属性値ＩＤ：１（ＪＥＦ）、Ｔｏ側の配列番号を変換先（表Ｂの氏名）の型属性値ＩＤ：０（ＳＪＩＳ）として参照する。これにより、データ変換機能として「文字コード系変換機能」を特定することができる。
【０３１６】
また、変換ルールテーブル（データ型変換ルールテーブル３３１またはクレンジングルールテーブル３３２）では、変換元および変換先のメタデータコードが同一である場合、データ変換機能を割り当てていない（図３６〜図４０参照）。これは判断部７３１３において変換元および変換先のメタデータコードが一致する場合は、変換が不要と判断して以降の変換処理を行わないため使用されない組み合わせとなる。また、判断部に頼ることなく、変換ルールテーブルにデータ変換機能が割り当てられていない場合には変換部による変換が行われないように制御することもできる。したがって、無駄なデータ変換を防止することができる。
【０３１７】
また、変換部７３１６は、変換機能特定部７３１４によって特定されたデータ変換機能を用いて、変換元のメタデータで規定される性質を有する変換元の対象データを、変換先のメタデータで規定される性質に変換する機能を有する。具体的には、たとえば、データ変換機能に、変換元のメタデータ、変換先のメタデータ、変換対象データをまとめて与えることで、変換対象データを変換する。
【０３１８】
たとえば、上述した図４４の（Ｂ）、変換ルールコード：１の例では、文字コード系変換機能に対し、変換元の型属性値：１（ＪＥＦ）、変換先の型属性値：０（ＳＪＩＳ）、変換対象データ（たとえば、文字列）を与えることで、ＪＥＦで表現された変換対象データを、ＳＪＩＳで表現されたデータに変換する。
【０３１９】
また、更新部７３１７は、変換部７３１６によって変換された場合、検出部７３１２による検出処理の次の実行に先立って、コード化メタ定義情報３４０のうち、変換部７３１６によって変換された変換元のメタデータコードを変換先のメタデータコードに更新する機能を有する。具体的には、たとえば、図４５と図４６において、変換元（表Ａの氏名）の配列番号［１］（ｃｈａｒ＿ｃｏｄｅ）の型属性値ＩＤを比較すると、変換前である図４５では、型属性値ＩＤ：１（ＪＥＦ）であるが、変換後である図４６では、変換前である図４５の変換先（表Ｂの氏名）の配列番号［１］の型属性値ＩＤ：０（ＳＪＩＳ）に更新する。（図４５、図４６では変換機能が同時にＣｈａｒ＿ｅｘｃｏｄｅの変換も行っている。）
【０３２０】
これにより、後続ではこれまでの変換が反映されて、変換元（表Ａの氏名）と変換先（表Ｂの氏名）とでは、ともに型属性値がＳＪＩＳとなり、データ変換が不要となる。したがって、変換対象データ（変換元）は、最新状態のコード化メタ定義情報３４０で処理されることとなり、データ変換の効率化を図ることができる。
【０３２１】
また、実施の形態２に示したように、制約条件テーブル６０００がある場合、制約条件が設定されている変換ルールコードに対応するデータ変換機能に先立って、制約条件に従って制約条件に指定された変換ルールコードに対するデータ変換をおこなう。したがって、制約条件を設定したデータ変換機能では、制約条件の基で動作するよう実装するだけでよく、それ以外のメタデータについて対応する必要がなく、実装を大幅に簡素化することができる。
【０３２２】
また、出力部７３１８は、変換後の変換対象データを出力する機能を有する。具体的には、たとえば、変換先となるコンピュータに送信したり、記憶部７３１０に記憶したりする。また、ディスプレイに表示したり、プリンタにより印刷することとしてもよい。
【０３２３】
このように、実施の形態１および実施の形態２によれば、利便性の向上と開発者の開発負担を軽減とを図ることができ、処理効率も高いという効果を奏する。
【０３２４】
なお、本実施の形態で説明したデータ変換方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ変換プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本データ変換プログラムは、インターネット等のネットワークを介して配布してもよい。
【０３２５】
上述した実施の形態に関し、さらに以下の付記を開示する。
【０３２６】
（付記１）変換元および変換先のデータに関する性質をあらわすメタデータが定義されたメタ定義情報内のメタデータを構成する要素に対して固有なコードとしてメタデータコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで性質が規定される変換元データを前記変換先のメタデータで規定される性質を持つ変換先のデータに変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに担当するメタデータコードを変換ルールコードとして関連付けた変換ルールと、を記憶する記憶手段と、
変換対象データの入力を受け付ける入力手段と、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段と、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段と、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換元のメタデータコードで規定される性質を有する前記変換対象データ（変換元データ）を、前記変換先のメタデータで規定される性質に変換する変換手段と、
を備えることを特徴とするデータ変換装置。
【０３２７】
（付記２）前記変換機能特定手段は、
前記判断手段によってメタデータコードが一致すると判断された場合、前記データ変換機能を特定せず、
前記変換手段は、
前記変換対象データを変換しないことを特徴とする付記１に記載のデータ変換装置。
【０３２８】
（付記３）前記判断手段によって不一致であると判断された場合、前記変換元の変換ルールコードに基づいて前記変換ルールを参照することにより、前記データ型変換ルールテーブルまたは前記クレンジングルールテーブルの中から該当する変換ルールテーブルを特定するテーブル特定手段を備え、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定することを特徴とする付記１に記載のデータ変換装置。
【０３２９】
（付記４）前記変換ルールテーブルでは、前記変換元のメタデータが任意の値をとる場合、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせにかかわらず、共通のデータ変換機能が割り当てられており、
前記コード化メタ定義情報では、前記任意の値をとる前記変換元および前記変換先のメタデータを特定するメタデータコードとして前記メタデータをそのまま用いており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせにかかわらず、前記共通のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記共通のデータ変換機能を用いて、前記変換対象データのデータを変換することを特徴とする付記１〜３のいずれか１つに記載のデータ変換装置。
【０３３０】
（付記５）前記変換ルールテーブルでは、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる組み合わせの場合に、前記変換元のメタデータで規定された性質を持つデータから前記変換先のメタデータで規定された性質を持つデータに変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記１〜４のいずれか１つに記載のデータ変換装置。
【０３３１】
（付記６）前記変換ルールテーブルでは、前記変換元のメタデータが予め指定されたメタデータであり、前記変換先のメタデータが前記変換元のメタデータとは異なるメタデータとなる組み合わせの場合に、前記変換元のメタデータで規定される性質を有する変換元データから前記変換先のメタデータで規定される性質に変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記１〜４のいずれか１つに記載のデータ変換装置。
【０３３２】
（付記７）前記変換ルールテーブルでは、前記変換先のメタデータが予め指定されたメタデータであり、前記変換元のメタデータが前記変換先のメタデータとは異なるメタデータとなる組み合わせの場合に、前記変換元のメタデータで規定される性質を有する変換元データから前記変換先のメタデータで規定される性質に変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記１〜４のいずれか１つに記載のデータ変換装置。
【０３３３】
（付記８）前記コード化メタ定義情報では、前記変換ルールコードが、前記メタデータの優先順位順の連続番号として割り当てられており、
前記検出手段は、
前記コード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出処理を、優先順位が最も高い変換ルールコードから順次実行することを特徴とする付記１〜７のいずれか１つに記載のデータ変換装置。
【０３３４】
（付記９）前記メタデータは、前記変換対象データのデータ型、当該データ型の型属性、当該型属性の値の中から選ばれた要素で記述されており、
前記コード化メタ定義情報では、前記変換ルールコードについて前記データ型、前記型属性の順に優先順位が設定されていることを特徴とする付記８に記載のデータ変換装置。
【０３３５】
（付記１０）前記検出手段は、
最初に前記データ型について前記検出処理を実行し、当該検出処理以降は、前記型属性の変換ルールコードの優先順位にしたがって前記検出処理を実行することを特徴とする付記９に記載のデータ変換装置。
【０３３６】
（付記１１）最初に前記データ型について前記検出処理を実行し、当該検出処理以降は、前記型属性の変換ルールコードの優先順位の逆順にしたがって前記検出処理を実行することを特徴とする付記９に記載のデータ変換装置。
【０３３７】
（付記１２）前記変換手段によって変換された場合、前記検出手段による前記検出処理の次の実行に先立って、前記コード化メタ定義情報のうち、前記変換手段によって変換された前記変換元のメタデータコードを前記変換先のメタデータコードに更新する更新手段を備えることを特徴とする付記８または９に記載のデータ変換装置。
【０３３８】
（付記１３）前記記憶手段は、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能による変換処理を制約する制約条件が設定された制約条件テーブルを記憶しており、
前記変換ルールは、さらに、前記制約条件により変換処理が制約されるデータ変換機能に関連付けられた変換ルールコードに前記制約条件テーブルが関連付けられており、
前記テーブル特定手段は、
前記判断手段によって不一致であると判断された場合、前記変換元の変換ルールコードに基づいて前記変換ルールを参照することにより、前記変換ルールテーブルの特定に先立って、前記変換ルールテーブルに関連付けされた制約条件テーブルを特定し、
前記検出手段は、
前記テーブル特定手段によって特定された制約条件テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記制約条件として定義されている前記変換元の変換ルールコードおよびメタデータコードを検出し、前記コード化メタ定義情報を参照することにより、前記制約条件として定義されている前記変換元の変換ルールコードと一致する前記変換先のメタデータコードを検出し、
前記判断手段は、
前記検出手段によって検出された前記制約条件として定義されている前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断し、
前記変換機能特定手段は、
前記判断手段によって判断された判断結果に基づいて、前記変換ルールを参照することにより、前記制約条件として定義されている前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記３に記載のデータ変換装置。
【０３３９】
（付記１４）変換元および変換先のメタデータに関する仕様および前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段と、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記メタデータを特定するメタデータコードを前記メタデータに関連付けたメタデータコード化テーブルを設定する第１の設定手段と、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定手段と、
前記第２の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段と、
を備えることを特徴とするデータ変換装置。
【０３４０】
（付記１５）前記第１の設定手段は、
前記メタデータが任意の値をとることができる特殊なメタデータである場合、前記メタデータを前記メタデータコードとしてそのまま用いた特殊なメタデータコード化テーブルを設定し、
前記第２の設定手段は、
前記特殊なメタデータについて、前記変換元の前記特殊なメタデータから前記変換先の前記特殊なメタデータに変換するデータ変換機能を関連付けた変換ルールテーブルを設定することを特徴とする付記１４に記載のデータ変換装置。
【０３４１】
（付記１６）前記第１の設定手段は、
前記仕様定義情報において定義されている第１のメタデータと同階層の第２のメタデータについて、前記第１のメタデータを継承する記述が定義されている場合、前記仕様定義情報における前記第２のメタデータは、前記第１のメタデータに定義されている下位階層のメタデータそのまま包含するように構成されたメタデータコード化テーブルを設定することを特徴とする付記１４または１５に記載のデータ変換装置。
【０３４２】
（付記１７）前記第１の設定手段は、
前記第１のメタデータについて前記メタデータコード化テーブルを設定しないことを特徴とする付記１６に記載のデータ変換装置。
【０３４３】
（付記１８）前記データ変換機能に制約条件が設定されている場合、前記データ変換機能が設定されている変換ルールテーブルをコピーして、前記データ変換機能に代えて、前記制約条件を割り当てることにより、制約条件テーブルを設定する第３の設定手段を備え、
前記構築手段は、
さらに、前記制約条件により変換処理が制約されるデータ変換機能に関連付けられた変換ルールコードに前記第３の設定手段によって設定された制約条件テーブルを関連付けることにより、前記変換ルールを構築することを特徴とする付記１４〜１７のいずれか１つに記載のデータ変換装置。
【０３４４】
（付記１９）前記変換元および前記変換先のメタデータが定義されたメタ定義情報を取得するメタ定義情報取得手段と、
前記メタ定義情報取得手段によって取得されたメタ定義情報内のメタデータごとに、当該メタデータに関する前記変換ルールテーブルに固有な変換ルールコードを割り当ててコード化することにより、コード化メタ定義情報を生成する生成手段と、
を備えることを特徴とする付記１４〜１８のいずれか１つに記載のデータ変換装置。
【０３４５】
（付記２０）前記仕様定義情報に定義されている特定のメタデータの下位階層のメタデータがデフォルト指定されている場合、前記メタ定義情報において省略されている当該デフォルト指定されたメタデータを補完する補完手段を備え、
前記生成手段は、
前記補完手段による補完後のメタ定義情報内のメタデータごとに、当該メタデータに関する前記変換ルールテーブルに固有な変換ルールコードを割り当ててコード化することにより、コード化メタ定義情報を生成することを特徴とする付記１９に記載のデータ変換装置。
【０３４６】
（付記２１）変換対象データの入力を受け付ける入力手段と、
前記生成手段により生成されたコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段と、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記構築手段によって構築された変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段と、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを変換する変換手段と、
を備えることを特徴とする付記１９または２０に記載のデータ変換装置。
【０３４７】
（付記２２）変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶装置にアクセス可能なコンピュータが、
変換対象データの入力を受け付ける入力工程と、
前記記憶装置に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出工程と、
前記検出工程によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断工程と、
前記判断工程によって判断された判断結果に基づいて、前記記憶装置に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定工程と、
前記変換機能特定工程によって特定されたデータ変換機能を用いて、前記変換対象データを、前記変換元のメタデータで規定されている性質から前記変換先のメタデータで規定されている性質に変換する変換工程と、
を実行することを特徴とするデータ変換方法。
【０３４８】
（付記２３）コンピュータが、
変換元のメタデータおよび前記変換元のメタデータから変換先のメタデータに変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得工程と、
前記仕様定義情報取得工程によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第１の設定工程と、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定工程と、
前記第２の設定工程によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築工程と、
を実行することを特徴とするデータ変換方法。
【０３４９】
（付記２４）コンピュータを、
変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶手段、
変換対象データの入力を受け付ける入力手段、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを、前記変換元のメタデータで規定される性質から前記変換先のメタデータで規定される性質に変換する変換手段、
として機能させることを特徴とするデータ変換プログラム。
【０３５０】
（付記２５）コンピュータを、
変換元および変換先のメタデータに関する仕様および前記変換元のメタデータで規定される性質を持つ変換元データを前記から変換先のメタデータで規定される性質に変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第１の設定手段、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定手段、
前記第２の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段、
として機能させることを特徴とするデータ変換プログラム。
【符号の説明】
【０３５１】
３００ データ変換装置
３０１ クレンジング仕様定義ファイル
３０２ 型変換機能ライブラリ
３０３ クレンジング機能ライブラリ
３０４ メタ定義ファイル
３１１ 初期化部
３１２ クレンジング処理部
３２１ データ型コード表
３２２ 型属性コード表
３２３ 型属性値コード表
３３０ 変換ルール群
７３００ 仕様定義情報取得部
７３０１ 第１の設定部
７３０２ 第２の設定部
７３０３ 構築部
７３０４ 第３の設定部
７３０５ メタ定義情報取得部
７３０６ 生成部
７３０７ 補完部
７３１０ 記憶部
７３１１ 入力部
７３１２ 検出部
７３１３ 判断部
７３１４ 変換機能特定部
７３１５ テーブル特定部
７３１６ 変換部
７３１７ 更新部
７３１８ 出力部

【特許請求の範囲】
【請求項１】
変換元および変換先のデータに関する性質をあらわすメタデータが定義されたメタ定義情報内のメタデータを構成する要素に対して固有なコードとしてメタデータコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで性質が規定される変換元データを前記変換先のメタデータで規定される性質を持つ変換先データに変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに担当するメタデータコードを変換ルールコードとして関連付けた変換ルールと、を記憶する記憶手段と、
変換対象データの入力を受け付ける入力手段と、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段と、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段と、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換元のメタデータコードで規定される性質を有する前記変換対象データ（変換元データ）を、前記変換先のメタデータで規定される性質に変換する変換手段と、
を備えることを特徴とするデータ変換装置。
【請求項２】
前記変換機能特定手段は、
前記判断手段によってメタデータコードが一致すると判断された場合、前記データ変換機能を特定せず、
前記変換手段は、
前記変換対象データのメタデータを変換しないことを特徴とする請求項１に記載のデータ変換装置。
【請求項３】
前記判断手段によって不一致であると判断された場合、前記変換元の変換ルールコードに基づいて前記変換ルールを参照することにより、前記データ型変換ルールテーブルまたは前記クレンジングルールテーブルの中から該当する変換ルールテーブルを特定するテーブル特定手段を備え、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定することを特徴とする請求項１に記載のデータ変換装置。
【請求項４】
変換元および変換先のメタデータに関する仕様および前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段と、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記メタデータを特定するメタデータコードを前記メタデータに関連付けたメタデータコード化テーブルを設定する第１の設定手段と、
前記第１の設定手段によって設定されたメタデータコード化テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定手段と、
前記第２の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段と、
を備えることを特徴とするデータ変換装置。
【請求項５】
変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶装置にアクセス可能なコンピュータが、
変換対象データの入力を受け付ける入力工程と、
前記記憶装置に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出工程と、
前記検出工程によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断工程と、
前記判断工程によって判断された判断結果に基づいて、前記記憶装置に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定工程と、
前記変換機能特定工程によって特定されたデータ変換機能を用いて、前記変換対象データを、前記変換元のメタデータで規定されているし性質から前記変換先のメタデータで規定されている性質に変換する変換工程と、
を実行することを特徴とするデータ変換方法。
【請求項６】
コンピュータが、
変換元のメタデータおよび前記変換元のメタデータから変換先のメタデータに変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得工程と、
前記仕様定義情報取得工程によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第１の設定工程と、
前記第１の設定工程によって設定されたメタデータコード化テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定工程と、
前記第２の設定工程によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築工程と、
を実行することを特徴とするデータ変換方法。
【請求項７】
コンピュータを、
変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータから前記変換先のメタデータに変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶手段、
変換対象データの入力を受け付ける入力手段、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データのメタデータを、前記変換元のメタデータから前記変換先のメタデータに変換する変換手段、
として機能させることを特徴とするデータ変換プログラム。
【請求項８】
コンピュータを、
変換元のメタデータおよび前記変換元のメタデータから変換先のメタデータに変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第１の設定手段、
前記第１の設定手段によって設定されたメタデータコード化テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第２の設定手段、
前記第２の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段、
として機能させることを特徴とするデータ変換プログラム。

【図１】

【図２】

【図３−１】

【図３−２】

【図３−３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【図４９】

【図５０】

【図５１】

【図５２】

【図５３】

【図５４】

【図５５】

【図５６】

【図５７】

【図５８】

【図５９】

【図６０】

【図６１】

【図６２】

【図６３】

【図６４】

【図６５】

【図６６】

【図６７】

【図６８】

【図６９】

【図７０】

【図７１】

【図７２】

【図７３】

【公開番号】特開２０１１−３４２４６（Ｐ２０１１−３４２４６Ａ）
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願番号】特願２００９−１７８４４６（Ｐ２００９−１７８４４６）
【出願日】平成２１年７月３０日（２００９．７．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】