以下に添付図面を参照して、この発明にかかるデータ変換装置、データ変換方法、およびデータ変換プログラムの好適な実施の形態を詳細に説明する。実施の形態にかかるクレンジング機能は、値のメタ定義として、データ型およびその詳細を指定する型属性を持ち、変換元(From側)と変換先(To側)のメタ定義をデータとともに与え、From値(変換元の値)をTo値(変換先の値)に変換する。
これにより、メタ定義だけで、変換ロジックや手順が不要となる。したがって、メタ定義を操作することで拡張可能であり、利便性が向上する。また、開発者もメタ定義を操作することで容易に拡張したり、機能を組み合わせたりできるため、開発者にとっても開発負担の軽減となる。以下、実施の形態1について説明する。
(実施の形態1)
<データ変換>
図1は、実施の形態1にかかるデータ変換の一例を示す説明図である。実施の形態にかかるデータ変換は、ロジックを必要としない定義駆動型により、処理効率と柔軟性とを両立する機能を実現する。具体的には、データ104を変換するとき、変換元101(From側)のメタ定義131と変換先102(To側)のメタ定義132が異なっていれば、変換機能100を起動して変換先のメタ定義132に揃えるように変換する。
ここで、メタ定義103(131,132)とは、変換元101と変換先102におけるデータのデータ型および型属性を定義する情報である。たとえば、データ型には、文字列型(Char)や整数型(Integer)がある。また、型属性は、データ型のより詳細な特徴をあらわしており、たとえば、文字コード系や文字種がある。文字コード系には、たとえば、SJIS(Shift Japanese Industrial Standard、シフトJIS)、JEF(Japanese processing Extended Feature)、UTF−8(UCS/Unicode Transformation Format 8)などがある。また、文字種には、全角、半角がある。
図1では、一例として、変換元101のメタ定義131について、データ型を文字列型とし、型属性の文字コード系をシフトJIS、文字種を全角としている。一方、変換先102のメタ定義132について、データ型を文字列型とし、型属性の文字コード系をUTF−8、文字種を半角としている。変換元101のデータ141は、変換元101のメタ定義131に従って変換機能100に入力される。一方、変換先102のデータ142は、変換先102のメタ定義132に従って変換機能100から出力される。
また、変換機能100は、変換元101のメタ定義131と変換先102のメタ定義132とを比較して、異なる箇所がある場合、当該異なる箇所を変換して、変換先102のメタ定義132に揃えて、データ出力する。具体的には、変換機能100は、データ型を変換するデータ型変換機能111と、文字コード系を変換する文字コード変換機能112と、文字種を変換する文字種変換機能113とを有する。
たとえば、変換元101と変換先102とでデータ型が相違する場合は、データ型変換機能111を起動して、変換元101のデータ141のデータ型を変換先102のデータ型に変換する。同様に、変換元101と変換先102とで文字コード系が相違する場合は、文字コード変換機能112を起動して、変換元101のデータ141の文字コード系を変換先102の文字コード系に変換する。また、変換元101と変換先102とで文字種が相違する場合は、文字種変換機能113を起動して、変換元101のデータ141の文字種を変換先102の文字種に変換する。
図1の例では、変換元101のメタ定義131に従って“130円”という文字列がデータ141として入力された場合、変換元101と変換先102とでは、型属性の文字コード系および文字種が相違するため、文字コード変換機能112と文字種変換機能113とを順次起動する。これにより、変換先102に出力されるデータ142である“130円”は、文字コードがUTF−8、文字種が半角(半角にできる数字の部分)の文字列となる。
<データ変換装置のハードウェア構成>
図2は、実施の形態1(後述の実施の形態2も同様)にかかるデータ変換装置のハードウェア構成を示すブロック図である。図2において、データ変換装置は、CPU(Central Processing Unit)201と、ROM(Read‐Only Memory)202と、RAM(Random Access Memory)203と、磁気ディスクドライブ204と、磁気ディスク205と、光ディスクドライブ206と、光ディスク207と、ディスプレイ208と、I/F(Interface)209と、キーボード210と、マウス211と、スキャナ212と、プリンタ213と、を備えている。また、各構成部はバス200によってそれぞれ接続されている。
ここで、CPU201は、データ変換装置の全体の制御を司る。ROM202は、ブートプログラムなどのプログラムを記憶している。RAM203は、CPU201のワークエリアとして使用される。磁気ディスクドライブ204は、CPU201の制御にしたがって磁気ディスク205に対するデータのリード/ライトを制御する。磁気ディスク205は、磁気ディスクドライブ204の制御で書き込まれたデータを記憶する。
光ディスクドライブ206は、CPU201の制御にしたがって光ディスク207に対するデータのリード/ライトを制御する。光ディスク207は、光ディスクドライブ206の制御で書き込まれたデータを記憶したり、光ディスク207に記憶されたデータをコンピュータに読み取らせたりする。
ディスプレイ208は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ208は、たとえば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
インターフェース(以下、「I/F」と略する。)209は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワーク214に接続され、このネットワーク214を介して他の装置に接続される。そして、I/F209は、ネットワーク214と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F209には、たとえばモデムやLANアダプタなどを採用することができる。
キーボード210は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス211は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
スキャナ212は、画像を光学的に読み取り、データ変換装置内に画像データを取り込む。なお、スキャナ212は、OCR(Optical Character Reader)機能を持たせてもよい。また、プリンタ213は、画像データや文書データを印刷する。プリンタ213には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
<データ変換装置の機能的構成>
図3−1は、実施の形態1(後述の実施の形態2も同様)にかかるデータ変換装置の機能的構成を示すブロック図である。図3−1において、データ変換装置300は、クレンジング処理部と初期化部とを含む。クレンジング処理部および初期化部は、具体的には、たとえば、図2に示したROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されたプログラムをCPU201に実行させることにより、または、I/F209により、その機能を実現する。
また、データ変換装置300では、クレンジング仕様定義ファイル301、型変換機能ライブラリ302、クレンジング機能ライブラリ303およびメタ定義ファイル304を用いる。クレンジング仕様定義ファイル301、型変換機能ライブラリ302、クレンジング機能ライブラリ303およびメタ定義ファイル304は、図2に示したROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶され、または、I/F209によりネットワーク214経由でアクセスすることができる。
クレンジング仕様定義ファイル301には、データ変換装置で扱うデータ型の性質がデータ型変換機能と併せて定義され、データ型の詳細な性質を定義する型属性がクレンジング機能と併せて定義されている。
また、データ変換装置300は、初期化部311とクレンジング処理部312とを有する。初期化部311は、クレンジング仕様定義ファイル301とメタ定義ファイル304とを読み込んで、データ型コード表321と型属性コード表322と型属性値コード表323と生成する。すなわち、データ型、型属性、および型属性値をコード化する。
メタ定義ファイル304には図1に示したメタ定義103が記述されている。初期化部311は、メタ定義ファイル304をコード化して、コード化メタ定義情報340を生成する。コード化メタ定義情報340は、変換元101と変換先102とに分けて生成される。
また、初期化部311は、クレンジング仕様定義ファイル301のデータ型変換定義とデータ型コード表321からデータ型変換ルールテーブル331を生成し、クレンジング仕様定義ファイル301のクレンジング機能定義と型属性コード表322および型属性値コード表323からクレンジングルールテーブル332を生成する。初期化部311は、データ型変換ルールテーブル331およびクレンジングルールテーブル332をまとめ上げて、変換ルール群330を構築する。変換ルール群330は、たとえば、バイナリデータである。これにより、コード化されたデータ型、型属性、および型属性値に関する変換元から変換先へのデータ変換規則を構築する。
クレンジング処理部312は、クレンジング制御部351と型変換呼出し部352とクレンジング呼出し部353とを有する。クレンジング制御部351は、変換元101のFrom値(元の値)141およびFrom側のコード化メタ定義340と変換先102のTo値(目的の値)142およびTo側のコード化メタ定義情報340を読み込み、変換ルール群330を参照して、型変換呼出し部352とクレンジング呼出し部353とを制御する。
具体的には、クレンジング制御部351は、From側とTo側のコード化メタ定義(型)を比較することによってどの型変換処理を実行させるかを決定し、決定した型変換処理を実行するための型変換機能を型変換機能ライブラリ302から型変換呼出し部352に呼び出して実行させる。同様に、From側とTo側のコード化メタ定義(型属性)を比較することによってどのクレンジング処理を実行させるかを決定し、決定したクレンジング処理を実行するためのクレンジング機能をクレンジング機能ライブラリ303からクレンジング呼出し部353に呼び出して実行させる。
図3−2は、型変換機能ライブラリ302の記憶内容を示す説明図である。図3−2において、型変換機能ライブラリ302は、型変換機能を記憶している。型変換機能は、変換元101(From側)のデータ型と変換先102(To側)のデータ型との組み合わせで特定される。型変換機能は予め準備された関数を用いる。
図3−3は、クレンジング機能ライブラリ303の記憶内容を示す説明図である。図3−3では、文字コード系変換におけるクレンジング機能ライブラリ303を示している。このクレンジング機能ライブラリ303は、型属性が文字コード系である場合のクレンジング機能を記憶している。クレンジング機能は、From側の型属性値とTo側の型属性値との組み合わせで特定される。クレンジング機能も型変換機能と同様、予め準備された関数を用いる。
つぎに、データ変換装置300で用いられる各種データ(クレンジング仕様定義ファイル301、型変換機能ライブラリ302、クレンジング機能ライブラリ303およびメタ定義ファイル304)の詳細について例を用いて説明する。
<クレンジング仕様定義ファイル301>
図4は、クレンジング仕様定義ファイル301の一記述例を示す説明図である。図4のクレンジング仕様定義ファイル301では、データ型として、文字列型(Char型)と整数型(Integer型)を定義している。符号401が文字列型の定義記述であり、符号402が整数型の定義記述である。
文字列型の定義記述401において、符号411は、型変換機能の記述である。型変換機能の記述411では、型変換を定義するDTCV_RULEタグで定義されている。変換元101(From側)のデータ型は文字列型であるため省略されており、変換先102のデータ型は、to属性として整数型「to=“Integer”」と記述される。また、DTCV_RULEタグの値として、型変換機能として呼び出す関数名(ここでは、「文字の整数変換」)が指定される。ここで指定された関数名がポインタとなり、該当する型変換機能が呼び出されることとなる。
また、文字列型の定義記述401において、符号412は、型属性を定義するタグである。型属性を定義する「DATA_ATTR」タグ412では、型属性名として文字コード系(char_code)が記述されている。また、型属性を定義するタグ412の子タグとして、その型属性の値として使用することができる型属性値を定義する「VALUE」タグ413が記述されている。ここでは、“SJIS”、“JEF”、“UTF8”の3通りの型属性値が定義されている。
また、型属性値を定義するタグ413に引き続き、クレンジングルール定義タグ「CL_RULE」414が記述される。クレンジングルール定義タグ414には、変換元101(From側)の型属性値と変換先102(To側)の型属性値とが記述される。たとえば、変換元101の型属性値がシフトJISであり、変換先102の型属性値がJEFである場合、クレンジングルール定義タグ414の開始タグ内に、「from=“SJIS”to=“JEF”」と記述しておく。そして、タグの値として、シフトJISからJEFへのクレンジング機能(文字コード系変換)を実行する関数名「SJIS_JEF変換」を記述する。ここで指定される関数名がポインタとなり、該当するクレンジング機能が呼び出されることとなる。
また、整数型の定義記述402において、符号421は、型変換機能の記述である。型変換機能の記述421では、変換元101(From側)のデータ型は整数型になっているため省略されており、変換先102のデータ型は、型変換を定義するDTCV_RULEタグの「to」属性の値として、文字列型「to=“Char”」と記述される。また、DTCV_RULEタグの値として、型変換機能を呼び出す関数名(ここでは、「整数の文字変換」)が記述される。ここで指定された関数名がポインタとなり、該当する型変換機能が呼び出されることとなる。
このクレンジング仕様定義ファイル301では、1個以上のデータ型を定義することが可能であり、それぞれのデータ型の性質として1つのデータ型に対して0個以上の型属性と各型属性の値として使える型属性値が定義される。ここで定義された変換元101(From側)と変換先102(To側)で使えるデータ型および型属性、型属性値を用いて、メタ定義ファイルとして各値の性質(メタ定義)を記述することによって、From側101のデータ値141に対応するメタ定義131が指定され、To側102のデータ値142に対するメタ定義132が指定される。これにより、変換元101のメタ定義および変換先102のメタ定義が変換元101のデータとともに図3−1に示したクレンジング処理部312に渡されると、クレンジング処理部312では、変換ルール群330を参照して変換元101と変換先102の型および型属性の組み合わせにより必要な型変換や文字コード系変換などのクレンジングを実行することができる。
尚、クレンジング仕様定義ファイル301において変換元101(From側)と変換先102(To側)を対称に定義する(from側とto側のどちらの方向でも使えるようにする)ことによって、メタ定義ファイルを記述する際に、from側とto側で使用可能なデータ型、型属性、型属性を区別する必要が無くなる。また先述の仮想統合(EII)においては、問合せの分解処理と、結果の統合処理の両方でデータ変換機能が使われ、ここではfrom側とto側が逆転するので、from側とto側を対称に定義することが必須になる。
図5は、図4に示したクレンジング仕様定義ファイル301の拡張例を示す説明図である。図4では、クレンジングルールとして、型属性値の組み合わせごとに型属性変換機能を呼び出す関数名を記述したが、クレンジング機能を実現する関数には、それ自身でどの型属性値の組み合わせにも対応できる関数もある。このように、図5では、単一の関数で担当する型属性の全組み合わせに対応可能なクレンジング機能を用いる場合、クレンジングルール定義タグ414の「from」属性や「to」属性の値として「*」を用いる。「*」は該当する型属性で使用可能な全ての型属性値をあらわすワイルドカードである。
たとえば、図5の下線で示した行において、クレンジングルール定義タグ414の開始タグを、<CL_RULE from=“*” to=“*”>と記述する。これにより、変換元101の「char_code」型属性の型属性と変換先102の同型属性値とが異なる場合は、常に、クレンジングルール定義タグ414の開始タグおよび終了タグで挟まれた関数によりクレンジング機能「文字コード系変換」が実行される。
また、<CL_RULE from=“A” to=“*”>と記述した場合は、変換元101の該当する型属性の型属性値が“A”で変換先102の同型属性値が“A”以外の値であるときには常に、クレンジングルール定義タグ414の開始タグおよび終了タグで挟まれた関数によりクレンジング機能が実行される。
また、<CL_RULE from=“*” to=“A”>と記述した場合は、変換元101の該当する型属性の型属性値が“A”以外の値で変換先102の同型属性値が“A”であるときには常に、クレンジングルール定義タグ414の開始タグおよび終了タグで挟まれた関数によりクレンジング機能が実行される。
図6は、クレンジング仕様定義ファイル301の型属性の追加/拡張例を示す説明図である。図6のクレンジング仕様定義ファイル301は、図5に示したクレンジング仕様定義ファイル301に、例として文字の最大長(バイト長)を指定する“max_length”という型属性を、型属性:文字コード系(“char_code”)のあとに追加した例である。
このように、型属性定義タグ<DATA_ATTR>を追加することで、該当するデータ型で扱える型属性およびクレンジング機能を追加することができる。本例の場合は、文字列のlength調整処理を実行することができる。
型属性定義の順番は、重要(基本的)な性質の型属性定義を先にすることで、優先して実行されるように制御することができる。原則的に新しい型属性定義は末尾に追加することによって、既存の変換機能に対する影響を最小化できる。本例では、型属性として“max_length”より“char_code”が重要な型属性となる。
また、型属性値は、型属性値を定義する<VALUE>タグを持たない型属性定義<DATA_ATTR>にすることによって、任意の型属性値を扱えるように拡張することができる。たとえば図6の点線枠内のように、<VALUE>タグによる型属性値の定義を行わない型属性定義とすることによって、型属性:max_lengthは型属性値として任意の値を採ることができる。文字列の最大長(バイト長)を指定するmax_lengthのように、その値を予め限定する事が難しい型属性に便利である。<VALUE>タグによる型属性値の定義をしない場合は、予め値を想定することが難しいため、クレンジングルール定義タグでは、<CL_RULE from=“*”to=“*”>のように必ず「*」を使用したルールを記述する必要がある。この場合、型属性:max_lengthが変換元101と変換先102とで異なるときには無条件にクレンジング機能「length調整」が実行される。
ここで、クレンジング仕様定義ファイル301に基づいたメタ定義について説明する。ここでは、図6に示したクレンジング仕様定義ファイル301を例として用いる。
図7は、変換元101で用いられる表Aと変換先102で用いられる表Bを示す説明図である。表Aと表Bはメタ定義ファイル304で定義された表のモデルである。表A、表Bではともに、カラムごとに、データ型、型属性、主キー制約が定義されている。表Aでは、「従業員番号」のデータ型は整数型で主キー制約がある。「氏名」のデータ型は文字列型で、型属性である文字コード系はJEFである。また、型属性である最大文字列長は20バイトである。「電話番号」のデータ型は文字列型で、型属性である文字コード系はJEFである。
また、表Bでは、「従業員番号」のデータ型は整数型で主キー制約がある。「氏名」のデータ型は文字列型で、型属性である文字コード系はSJISである。また、型属性である最大文字列長は14バイトである。「電話番号」のデータ型は整数型である。更に、表Aの各カラムは(1)〜(3)により表Bの同名のカラムに対応している。
なお、ここでは表Aを変換元101、表Bを変換先102として説明しているが、一般的にデータ変換の方向(変換元と変換先の決定)は、処理目的に応じて変化するものである。たとえば、前述の物理統合(ETL)では、情報源側のデータモデルを表A、ターゲット側のデータモデルを表Bとして、表Aの各カラムを変換元101、表Bの対応するカラムを変換先102としてデータ変換が行われる。また、前述の仮想統合(EII)では、情報源側である物理モデルを表A、利用側である論理モデルを表Bとして、表Bに対して入力された検索条件を表Aに対する検索条件に変換する処理では、論理モデルである表Bの対象カラムに対する検索条件を変換元101、物理モデルである表Aの対応するカラムに対する検索条件を変換先102としてデータ変換が行われ、情報源側の検索結果データ(物理モデル)を利用側の論理モデルのデータに変換する処理では、表Aの各カラムを変換元101、表Bの対応するカラムを変換先102としてデータ変換が行われる。以下のすべての説明においては、仮想統合(EII)における物理モデルのデータ(表A)を論理モデルのデータ(表B)に変換するためのデータ変換処理を例として用いているため、変換元101を表Aとし、変換先102を表Bと仮定している。
図8は、メタ定義ファイル304の一記述例を示す説明図である。図8に示したメタ定義ファイル304は、図7に示した物理モデル表Aおよび論理モデル表B、ならびに表Aと表Bとの対応関係を定義したファイルである。
ここでは、物理モデル表Aを<R_MODEL>、論理モデル表Bを<V_MODEL>で定義しており、name属性には表の名前を、keytype属性にはキー指定を指定する。また、各表を構成するカラムを<COLUMN>(name属性にカラム名を指定する)で定義し、各カラムの性質としてデータ型を<D_TYPE>、型属性を<D_ATTR>(name属性に型属性の名称を指定する)で定義している。また、各カラム間の対応関係は<MAP_RULE>で定義し、<FROM_COLUNM>(table属性に表の名前を指定する)で指定されたカラムが、<TO_COLUMN>(table属性に表の名前を指定する)に対応していることを示している。<META_DATA>はメタ定義全体をまとめるルートタグである。
変換元101(物理モデル表A)のデータをデータ変換して変換先102(論理モデル表B)に出力する場合、「氏名」については型属性である文字コード系の型属性値が相違するため、JEFからSJISにクレンジングされる。また、最大文字列長を規定する型属性が表B側に指定されているため、文字列長が14バイトを超える場合、14バイトまでがコピーされ、15文字目以降が削除される。「電話番号」については、データ型が相違するため、文字列型(JEF)から整数型に型変換される。
つぎに、データ型の継承について説明する。クレンジング仕様定義ファイル301では、データ型は既存データ型を継承する記述を追加することで、クレンジング仕様を拡張することができる。ここで、既存のデータ型を継承先とし、継承先を継承した新しいデータ型を継承元とする。
継承については、継承元である新しいデータ型の定義に、「super=“継承先の型名”」と記述して継承先を指定することで定義することができる。継承が定義された場合、継承元のデータ型は継承先のデータ型が持つ型属性やクレンジング機能などの性質をすべて継承することとなる。
以下、継承の記述の追加例について説明する。ここでは、継承先のデータ型を文字列型とし、型属性:文字コード系のクレンジングルールを文字コード系変換とする。一方、継承元のデータ型を人名型とし、型属性:name_spaceのクレンジングルールを姓名空白処理とする。
図9は、継承が追加されたクレンジング仕様定義ファイル301の一記述例を示す説明図である。図9のクレンジング仕様定義ファイル301は、図4に示したクレンジング仕様定義ファイル301に、人名データ型定義記述900(図9中、点線枠)を追加することによって、新たに「人名型」のデータと、対応するクレンジング機能を使えるようにした例である。
人名データ型定義記述900において、データ型:人名型に対して、継承先を特定する記述として「super=”Char”」が追加されている。データ型:人名は、継承先を特定する記述により特定された文字列型が持つ型属性:文字コード系(型属性値はSJIS,JEF,UTF8の3通り)とクレンジング機能:文字コード系変換などの性質をすべて受け継ぐことができる。
また、継承元は、継承先とは独立した独自の型属性として、name_space(型属性値は、Yes,Noの2通り)とクレンジング機能:姓名空白処理機能を持つことができる。型属性:name_spaceは姓と名との間の空白の有無である。型属性値がYesであれば、空白を設け、Noであれば、姓と名との間を空白なしとする。
また、継承元に追加された型属性は継承先の型属性の後ろに追加されることとなる。これにより、常に継承先の型属性の方が、継承元の型属性より基本的な型属性として扱われる。
図10は、継承先と継承元との関係を示す説明図である。図10では、図9に示したクレンジング仕様定義ファイル301での継承先と継承元との関係を示している。継承先のデータ型:文字列型(Char)を継承した継承元のデータ型:人名型は、継承先のデータ型:文字列型(Char)が持つ型属性:文字コード系(char_code)と、継承元のデータ型:人名で拡張した型属性:name_spaceを使用することができる。すなわち、継承元である人名型は継承先である文字列型(Char)としての性質をすべて引き継いで文字列型としても扱えることに加えて、人名型として独自の性質である「姓名間の空白」を扱うことができるように定義されている。
図11は、メタ定義ファイル304の他の記述例を示す説明図である。図11に示したメタ定義ファイル304は、図8に示したメタ定義ファイル304の表Aおよび表Bについて「氏名」カラムの定義(Char型)を図9で追加したデータ型である「人名」型で置き換えたものである。したがって、人名型固有の型属性である「name_space」を新たに定義しており、表Aの「氏名」カラムは「name_space=“Yes”」で空白あり、表Bの「氏名」カラムは「name_space=“No”」で空白無しとしている。なお、図8の下線の記述(型属性:最大文字列長)は説明を簡単にするために削除した例とした。
図12は、図9に示したクレンジング仕様定義ファイル301と図11に示したメタ定義ファイル304とを用いた場合のクレンジング処理を示す説明図である。「氏名」カラムに関して、変換元101(From側)のデータ型:人名型で定義された人名『嶺野 和夫』を変換先102(To側)にクレンジング処理する例を示している。なお、図12中、一点鎖線より上は、データ型:文字列型としての性質によるクレンジング処理であり、一点鎖線より下は、データ型:人名型固有の性質によるクレンジング処理である。
図11を参照すると、変換元101で定義された表Aの「氏名」カラムのデータ型:人名型は、文字コード系がJEFでname_spaceがYes(空白あり)である。また、対応する変換先102で定義された表Bの「氏名」カラムのデータ型:人名型は、文字コード系がSJISでname_spaceがNo(空白なし)である。したがって、図12において、人名『嶺野 和夫』の文字コード系については、文字コード系変換機能を実行することで、JEFからSJISに変換される。
一方、人名『嶺野 和夫』のname_spaceについては、姓名空白処理機能を実行することで、Yes(空白あり)からNo(空白なし)に変換される。したがって、変換先102(To側)では、文字コード系はシフトJISとなり、姓『嶺野』と名『和夫』との間の空白は削除され、人名『嶺野和夫』(シフトJISで表記)となる。
また、継承元のデータ型変換も継承先を引き継ぐことができる。具体的には、継承元独自のデータ型変換が不要であるデータ型との組み合わせについては、継承元にデータ型変換処理を定義しないことにより、継承先に定義されている該当データ型とのデータ型変換処理を引き継ぐように構成する。また、継承元独自のデータ型変換処理が必要な場合には、継承元に独自のデータ型変換処理を追加定義することによって、継承先に定義されているデータ型変換処理より優先して適用されるように構成する。
図13は、継承元としてデータ型:日付型が追加された場合の継承関係を示す説明図である。図13において、データ型:日付型の追加前から定義されているデータ型:文字列型(Char)とデータ型:整数型(Integer)の組み合わせに着目すると、「文字の整数変換」と「整数の文字変換」のデータ変換処理によって、相互のデータ型変換ができることを示している。一方、継承元のデータ型:日付型と既存のデータ型:整数型の組み合わせに着目すると、継承元とデータ型:整数型の間には明にデータ型変換は定義されていない。したがって、継承先である文字列型に対して定義済みの整数型とのデータ型変換が引き継がれることとなる。この場合、継承元もデータを継承先のデータ型であるとしてデータ型変換処理を行うことを意味するので、「継承元は継承先の性質を引き継ぐ」という継承の概念に沿った動作となり、矛盾は生じない。
図14は、図13の継承によるデータ型変換例を示す説明図である。図14において、変換元101(From側)で定義された日付型のデータ『20090526』は、継承先である文字列型から引き継がれたデータ型変換処理(文字→整数変換)「文字の整数変換」により、整数『20,090,526』に変換される。
図15は、図13に示した継承先(Char型)と継承元(日付型)との継承関係を記述したクレンジング仕様定義ファイル301の一例を示す説明図である。日付型にはデータ型変換を示す<DTCV_RULE>タグが定義されていないため、継承先である文字列型(Char)に定義されている次のデータ型変換機能が継承されて適用される。具体的には、日付型のデータをChar型として扱うことによって、日付型からInteger型へのデータ型変換にはChar型で定義されているデータ型変換機能:文字の整数変換が適用され、Integer型から日付型へのデータ型変換にはInteger型で定義されているデータ型変換機能:整数の文字変換が適用される。
これにより、データ型の追加によって必要になる既存データ型とのデータ型変換を必要最小限にすることができる。したがってデータ型追加のコストを削減し、データ型変換に対する矛盾防止も同時に実現することができる。
つぎに、型属性値にデフォルト値を定義して、メタ定義ファイル304を簡素化する場合について説明する。型属性の数が増加すると、メタ定義ファイル304のすべての項目毎に定義されているすべての型属性を指定する手間が問題になる。そこでクレンジング仕様定義ファイル301における型属性の定義としてdefault属性でデフォルト値を指定することで、メタ定義ファイル304の項目に定義されない型属性の値はデフォルト値が設定されているとみなせる。これにより、メタ定義ファイル304を簡素化することができる。
図16は、型属性値にデフォルト値を定義したクレンジング仕様定義ファイル301の一記述例を示す説明図である。図16において、下線部に示したように、型属性の定義として、「default=“JEF”」、「default=“20”」、「default=“Yes”」というようにデフォルトの型属性値を記述しておく。
図17は、メタ定義ファイル304の簡素化を示す説明図である。図17において、上のメタ定義ファイル304は、簡素化前の記述例であり、下のメタ定義ファイル304は、図16に示すクレンジング仕様定義ファイル301にもとづいてメタ定義ファイル304を簡素化した記述例である。
図17の簡素化前のメタ定義ファイル304をみると、カラム名「氏名」について、データ型:人名型の型属性には、型属性:文字コード系(char_code)があり、その型属性値に“JEF”が定義されている。また、カラム名「電話番号」について、データ型:文字列型の型属性には、型属性:文字コード系があり、その型属性値に“JEF”が定義されている。図16では、型属性:文字コード系のデフォルト型属性値として“JEF”が定義されているため、メタ定義ファイル304において型属性:文字コード系の記述の省略が可能である。
また、図17の簡素化前のメタ定義ファイル304をみると、カラム名「氏名」について、データ型:人名型の型属性には、型属性:最大文字列長(max_length)があり、その型属性値に“20”が定義されている。また、カラム名「電話番号」について、データ型:文字列型の型属性には、型属性:最大文字列長があり、その型属性値に“20”が定義されている。図16では、型属性:最大文字列長のデフォルト型属性値として“20”が定義されているため、メタ定義ファイル304において型属性:最大文字列長の記述の省略が可能である。
また、図17の簡素化前のメタ定義ファイル304をみると、カラム名「氏名」について、データ型:人名型の型属性には、型属性:姓名空白(name_space)があり、その型属性値に“Yes”が定義されている。図16では、型属性:姓名空白のデフォルト型属性値として“Yes”が定義されているため、メタ定義ファイル304において型属性:姓名空白の記述の省略が可能である。
<クレンジング処理部312の詳細機能>
つぎに、図3−1に示したクレンジング処理部312の詳細機能について説明する。上述したように、クレンジング処理部312は、クレンジング制御部351により、変換ルール群330を参照して、型変換呼出し部352とクレンジング呼出し部353とを制御する。具体的には、クレンジング制御部351は、どの型変換処理を実行させるかを決定し、決定した型変換処理を型変換機能ライブラリ302から型変換呼出し部352に呼び出させる。同様に、どのクレンジング処理を実行させるかを決定し、決定したクレンジング処理をクレンジング機能ライブラリ303からクレンジング呼出し部353に呼び出させる。まず、クレンジング呼出し部353とクレンジング機能におけるクレンジングインタフェースの拡張について説明する。
図18は、クレンジング機能例(その1)を示す説明図である。クレンジング機能とは入力されたFrom値について変換を行い、To値として出力する機能であり、クレンジングルール332に基づいてクレンジング機能が一意に決定され、クレンジング制御部351の制御下でクレンジング呼出し部353から呼び出される。
たとえば、図5に示したクレンジング仕様定義ファイル301では、データ型としてデータ型:文字列型(Char)に対する型属性:文字コード系(char_code)が定義され、その型属性値として「SJIS」「JEF」「UTF8」(JEF)が使用可能である。また、クレンジングルール(CL_RULE)として、文字コード系変換機能が指定されている。ここでの文字コード系変換は、From側(変換元101)の動作条件である「from=“*”」とTo側(変換先102)の動作条件である「to=“*”」が規定されており、予め定義されたchar_code型属性の任意の型属性値の組み合わせにより必要な文字コード系間の変換を実行する機能として定義されている。
このような複数の変換パターンを有するクレンジング機能にも対応できるように、クレンジングインタフェースは図18に示すようにFrom側とTo側の型属性値を「From定義」、「To定義」としてクレンジング機能に入力するように構成する。
たとえば、図8に示したメタ定義ファイル304について、表Aの「従業員番号」項目を表Bの「従業員番号」に対応させる(1)のマッピング定義における文字コード系のクレンジング処理についてみると、図18に示すように「From定義」として変換元である表Aの「従業員番号」項目の文字コード系として「JEF」がFrom値とともにクレンジング制御部351から渡され、「To定義」として変換先である表Bの「従業員番号」項目の文字コード系として「SJIS」がクレンジング制御部351からクレンジング機能に渡される。
つぎに、「From定義」「From値」「To定義」を受け取ったクレンジング機能は、「From定義」と「To定義」から「JEF」から「SJIS」への文字コード系変換が必要であることを識別して、「From値」の値をJEF文字列としてシフトJIS(SJIS)の文字列への変換を実行し、その変換結果を「To値」に出力する。この仕組みによって、「From定義」と「To定義」の組み合わせによって決まる複数の変換パターンに対応するクレンジング機能を実現することができる。
図18に示した仕様拡張に加えて、クレンジング機能にFrom定義、To定義として変換対象のデータ項目に定義されたデータ型および型属性値のすべてを渡すことにより、クレンジング機能の実装をより容易にし、または高度なクレンジング機能を実現可能にする例について、図19を用いて説明する。
図19は、クレンジング機能例(その2)を示す説明図である。図19では、図8に示したメタ定義ファイル304で定義される(1)のマッピング定義について図18に示した文字コード系変換処理を完了した後の次のクレンジング機能として文字列の全体長を調整する機能であるlength調整機能を実行する場合を例示している。クレンジング制御部351からは、From定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:JEF、型属性:最大文字列長(max_length)とその型属性値:20が渡される。このように、データ型およびすべての型属性と型属性値が渡されることとなる。
To定義も同様で、クレンジング制御部351からは、To定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:JEF、型属性:最大文字列長(max_length)とその型属性値:14が渡される。このように、データ型およびすべての型属性と型属性値が渡されることとなる。
したがって、length調整機能では、クレンジング制御部351から同時に渡されたFrom値の文字列が14バイト以内であればそのままTo値にコピーする。一方、From値の文字列が14バイトを超えていれば、14バイトより後ろを切ってTo値にコピーする。なお、文字列を切る場合に、char_code型属性を参照して、マルチバイト文字の途中で切れる場合は、その前で切ることにより、文字の泣き別れを防止することができる。または、char_code型属性を参照して正確な文字数を計測することによって文字数で管理するlength調整機能を実現することもできる。
つぎに、図19による仕様拡張に加えて、クレンジング機能が処理結果の状態をFrom定義に反映する例について、図20を用いて説明する。
図20は、クレンジング機能例(その3)を示す説明図である。図20は、図8に示したメタ定義ファイル304で定義される(1)のマッピング定義について、図18に示した文字コード系変換処理と、図19に示したlength調整機能とを、より効率的なクレンジング制御ができるように仕様拡張した方式を用いて実行する場合を例示している。図20の左側では、char_code型属性に対するクレンジング処理を実行している。クレンジング機能:文字コード系変換に対し、From定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:JEF、型属性:最大文字列長(max_length)とその型属性値:20を与える。同様に、To定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:SJIS、型属性:最大文字列長(max_length)とその型属性値:14を与える。
この状態でFrom定義に従ったFrom値がクレンジング機能に与えられると、From値の文字コード系がJEFからSJISに変換される。クレンジング機能は、To値に変換結果をコピーするとともに、From定義の型属性値:JEFを処理結果であるTo定義のSJISに更新する。
次段の処理として、図20の右側では、max_length型属性に対するクレンジング処理を実行している。クレンジング機能:length調整機能に対し、From定義として、前段(図20中左側)の処理において更新されたFrom定義をそのまま与える。同様に、To定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:SJIS、型属性:最大文字列長(max_length)とその型属性値:14を与える。
この状態でFrom定義に従ったFrom値がクレンジング機能に与えられると、From値の最大文字列長が20バイトから14バイトに調整される。クレンジング機能は、To値に変換結果をコピーするとともに、From定義の型属性値:20(バイト)を処理結果であるTo定義の14(バイト)に更新する。これにより、最終的なFrom定義は、To定義と同一内容となるため、処理を終了する。
このように、処理結果の状態をFrom定義に反映することにより、同一値を処理する次のクレンジング処理(次段の処理)にFrom定義をそのまま入力でき、その入力となる値の状態を伝えることが可能になり、全体の処理効率が高まるとともに、From定義がFrom値の状態を正確に反映しているために次段の処理がより正確になる。なお、To定義はそのまま次段に渡せるが、前段のTo値は次段のFrom値として渡す必要がある。
つぎに、クレンジング機能の実行順序について説明する。本実施の形態では、クレンジング機能の実行順序は、定義された順とすることで、重要な型属性から順に実行するようにする。具体的には、1つの値に対して、複数の型属性それぞれに対応するクレンジング機能を実行する場合の順序は、先に定義された型属性からとする。これにより、重要な型属性から順にクレンジングが実行されるので、無駄な処理の発生を防止でき、クレンジングの処理も簡素化することができる。
図21は、クレンジング機能の実行順序を示す図表である。図21では、図6に示したクレンジング仕様定義ファイル301に基づき、図8に示したメタ定義ファイル304でのマッピング定義(2)である氏名をクレンジングする場合の実行順序を示している。図8の氏名のクレンジングにおいては、図6のクレンジング仕様定義ファイル301においてchar_code型属性がmax_length型属性より先に定義されている。
まず、データ型の処理については、From側およびTo側がともに文字列型(Char型)であるため、型変換は不要である。データ型変換はクレンジング処理より先に実行されるため、クレンジング処理ではデータ型は一致している。
つぎに、型属性:文字コード系(char_code)の処理については、メタ定義された氏名の文字コード系を、From側の型属性値:JEFからTo側の型属性値:SJISに文字コード系変換する。さらに、文字コード系(char_code)の処理後の型属性値SJISとなった氏名について、最大文字列長を20から14にしてlength調整する。このように、重要(基本的)な性質についての型属性は先に定義され、実行される。
これにより、注目型属性より重要な(上位の)型属性は一致していることを前提に処理することができる。また、注目型属性より下位の型属性は考慮する必要がない。さらに、処理の順序が一定になり、処理が簡素化されることとなる。
つぎに、複数の型属性に対応するクレンジング機能の実装例について説明する。複数の型属性に対応できるクレンジング機能を実装することにより、型属性とクレンジング機能の組み合わせが柔軟になる。したがって、より高度なクレンジング機能を実現でき、クレンジング処理を実行する回数の低減化を図ることができ、性能向上に寄与することとなる。
図22は、複数の同種の型属性に対応するクレンジング機能が定義されたクレンジング仕様定義ファイル301の一例を示す説明図である。図22では、クレンジング機能である「文字コード系変換」が、文字コード系(char_code)と外字コード系(char_excode)の2つの型属性で定義されており、両方の型属性に対応するクレンジング機能となる。ここで、外字コード系とは複数の外字対系(外字1、外字2)を扱うときに外字対系を識別するものであり、文字コード系の拡張仕様として追加した型属性である。
図23は、図22で定義された文字コード系(char_code)と外字コード系(char_excode)の両方の処理を実行するクレンジング機能を示す説明図である。図23において、クレンジング機能は、文字コード系変換を実行する。文字コード系変換では、char_code型属性に対するクレンジング処理のほか、char_excode型属性に対するクレンジング処理も実行する。
具体的には、From定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:JEF、外字コード系(char_excode)とその型属性値:外字1、型属性:最大文字列長(max_length)とその型属性値:20を与える。同様に、To定義として、データ型:文字列型(Char)、型属性:文字コード系(char_code)とその型属性値:SJIS、外字コード系(char_excode)とその型属性値:外字2、型属性:最大文字列長(max_length)とその型属性値:14を与える。
この状態でFrom定義に従ったFrom値がクレンジング機能:文字コード系変換に与えられると、クレンジング機能:文字コード系変換は、From値の文字コード系をJEFからSJISに変換する。併せて、クレンジング機能:文字コード系変換は、From値の外字コード系を外字1から外字2に変換する。
このように、1回の型属性変換において、文字コード系変換と外字コード系変換という異なる複数の型属性に対応する変換を、1つのクレンジング機能により実行することで、実行回数を削減(本例では2回のところを1回)することができる。この場合、次段の処理では、クレンジング機能としてlength調整を実行することとなる。
<クレンジング処理部312による高速処理化>
つぎに、クレンジング処理部312における速処理化について説明する。ここでは、上述したデータ変換処理について、図25のクレンジング仕様定義ファイル301と図24のメタ定義ファイル304とを用いて説明する。
図24は、メタ定義ファイル304の一例を示す説明図である。高速処理化において、メタ定義ファイル304は図44で後述するように、統合処理の開始前(初期化時)に高速処理が可能な状態に最適化してコード化メタ定義340としてRAM203またはROM202に展開しておく。
図25は、クレンジング仕様定義ファイル301の一例を示す説明図である。図25において定義されたデータ型は、Char型(文字列型)、人名型、住所型、Integer型(整数型)の定義順で記述されている。クレンジング仕様定義ファイル301は、図26〜図46で後述するように、メタ定義ファイル304の初期化前の段階で、データ変換装置300全体で一意な型IDを割り当てることによって最適化した状態にして変換ルール群330としてRAM203またはROM202に展開しておく。
図26は、データ型コード表321を示す説明図である。データ型コード表321において、型IDは、データ型をID化するものであり、クレンジング仕様定義ファイル301で定義されたデータ型の定義順に1から始まる連続した整数となる。
同様に、クレンジング仕様定義ファイル301で定義された型属性についても、各データ型内で一意であり、継承している型属性については、継承関係にあるデータ型間において同一となる型属性IDを割り当てることでID化する。また、Char型の型属性コード表322は、継承元のデータ型に含めて説明しているが、独立した型属性コード表322として構成してもよい。
図27〜図29は、型属性コード表322を示す説明図である。図27は、Char(文字列型)および人名型の型属性コード表322であり、図28は、Char(文字列型)および住所型の型属性コード表322であり、図29は、Integer(整数型)の型属性コード表322である。
図27〜図29に示した型属性コード表322において、型属性IDは、クレンジング仕様定義ファイル301に記述された型属性の定義順に各データ型毎に1から始まる連続した整数となる。また、継承関係のあるデータ型の型属性は、最も祖先のデータ型の型属性から順に割り当てる。したがって、共通の祖先の型属性IDは一致する。
たとえば、図27では、Char型を人名型が継承しているため、人名型の祖先であるChar型の型属性ID:1〜3は一致することとなる。同様に、図28では、Char型を住所型が継承しているため、住所型の祖先であるChar型の型属性ID:1〜3は一致することとなる。
同様に、クレンジング仕様定義ファイル301で定義された型属性値についても、各型属性内で一意な型属性値IDを割り当てる。
図30〜図35は、型属性値コード表323を示す説明図である。図30は、char_code型属性の型属性値に型属性値IDを割り当てた型属性値コード表323である。図31は、char_excode型属性の型属性値に型属性値IDを割り当てた型属性値コード表323である。図32は、name_space型属性の型属性値に型属性値IDを割り当てた型属性値コード表323である。図33は、chou_banchi型属性の型属性値に型属性値IDを割り当てた型属性値コード表323である。
図30〜図33に示した型属性値コード表323において、型属性値IDは、各型属性毎に割り当てられ、型属性値の定義順に0から始まる連続した整数となる。なお、未定義の型属性値に対しては、型属性値として“−1”を割り当てる。また、図30〜図33中、「*」のある型属性値は、デフォルト宣言された型属性値(デフォルト値)である。
図34は、max_length型属性の型属性値コード表323である。図35は、max_digit型属性の型属性値コード表323である。図34および図35に示したように、クレンジング仕様定義ファイル301で型属性値が定義されず、任意な型属性値を持つ型属性の場合、メタ定義ファイル304で定義された型属性値をそのまま型属性値IDとして使用することにする。
つぎに、データ型変換ルールについて説明する。データ型変換ルールとは、変換対象となるデータを、From側(変換元101)のデータ型からTo側(変換先102)のデータ型に変換する機能の実行パターンを決定する変換規則表である。
図36は、データ型変換ルールテーブル331を示す説明図である。図36において、データ型変換ルールテーブル331では、データ型IDをFrom/Toに配置して、その組み合わせによって実行する変換機能を決定するように構成する。具体的には、データ型変換ルールテーブルの値として、型変換機能ライブラリ302に存在する型変換機能へのリンク(型変換機能の呼び出しポインタ)を、該当するデータ型IDの組み合わせとなる位置に設定する。
また、変換が不要なFrom/Toの組み合わせには単純に値を複製するコピー機能を設定する(図36では、該当カラム内に「Copy」と表記)。また、継承したデータ型変換機能は最も身近な祖先のデータ型で定義された機能を採用する。なお、From/Toの「0」は「データ型IDが未定義」の意味として使用し、From/Toが同じデータ型IDの組み合わせについては使用しないため空欄にする。
同様に、型属性値についても型属性ごとに変換規則をクレンジングルールとして定義する。クレンジングルールとは、変換対象となるデータを、From側(変換元101)の型属性値からTo側(変換先102)の型属性値に変換する機能の実行パターンを決定する変換規則表である。
図37〜図42は、クレンジングルールテーブル332を示す説明図である。図37のクレンジングルールテーブル332は、char_code型属性用のクレンジングルールである。図38のクレンジングルールテーブル332は、char_excode型属性用のクレンジングルールである。図39のクレンジングルールテーブル332は、name_space型属性用のクレンジングルールである。
図40のクレンジングルールテーブル332は、chou_banchi型属性用のクレンジングルールである。図41のクレンジングルールテーブル332は、max_length型属性用のクレンジングルールである。図42のクレンジングルールテーブル332は、max_digit型属性用のクレンジングルールである。
図37〜図40において、クレンジングルールテーブル332では、型属性値IDをFrom/Toに配置して、その組み合わせによって実行するクレンジング機能を決定するように構成する。具体的には、クレンジングルールテーブル332の値として、クレンジング機能ライブラリ303に存在するクレンジング機能へのリンク(クレンジング機能の呼び出しポインタ)を、該当する型属性値IDの組み合わせとなる位置に設定する。
また、変換が不要なFrom/Toの組み合わせには単純に値を複製するコピー機能を設定する。なお、From/Toが同じ型属性値IDの組み合わせについては使用しないため空欄にする。また、From/Toの組み合わせで異なるクレンジング機能を定義することとしてもよい。
また、図41および図42に示したように、任意の値を持つ型属性は、型属性値によるクレンジング機能の使い分けを行わないのでクレンジング機能が1つである。したがって、From/Toの0:0座標に該当するクレンジング機能へのリンクを設定する。
つぎに、上述したデータ型変換ルールテーブル331とクレンジングルールテーブル332とをまとめ上げる処理をおこなう。具体的には、たとえば、データ型IDや型属性ID、型属性値IDから直接参照可能な変換ルール群330を構築する。
図43は、変換ルール群330を示す説明図である。変換ルール群330は、変換ルールテーブル4300とデータ型用変換ルールテーブル4301〜4304とで構成される。変換ルールテーブル4300は、データ型IDを配列番号として参照することによって該当するデータ型に対応するデータ型用変換ルールテーブルを参照するテーブルである。
具体的には、変換ルールテーブル4300の配列番号[0]は空欄とし、配列番号[1以上]はデータ型IDと一致させる。また、変換ルールテーブル4300に記載している各データ型は、実際にはそれぞれのデータ型用変換ルールテーブル4301〜4304を割り当てる(該当テーブルへの呼び出しポインタを入れる)ことでリンクされる。
データ型用変換ルールテーブル4301〜4304は、データ型毎に作成され、配列番号[0]により該当データ型を変換元とするデータ型変換ルールテーブルを参照し、型属性IDを配列番号として参照することによって該当する型属性に対応するクレンジングルールテーブルを参照するテーブルである。
具体的には、データ型用変換ルールテーブルの配列番号[0]には該当するデータ型変換ルールテーブル331を割り当て、配列番号[1以上]には、一致する型属性IDに対応するクレンジングルールテーブル332を割り当てる。
たとえば、データ型ID:1のChar型は、変換ルール4300の配列番号[1]にChar型用変換ルールテーブル4301を設定する。また、Char型用変換ルールテーブル4301では、配列番号[0]に図36に示したデータ型変換ルールテーブル331へのポインタを設定し、配列番号[1]には型属性ID:1であるchar_code型属性用のクレンジングルールテーブル332(図37)へのポインタを設定し、配列番号[2]には型属性ID:2であるchar_excode属性用のクレンジングルールテーブル332(図38)へのポインタを設定し、配列番号[3]には型属性ID:3であるmax_length型属性用のクレンジングルールテーブル332(図34)へのポインタを設定する。
つぎに、メタ定義ファイル304をコード化してコード化メタ定義340を作成する処理について説明する。ここでは、図24に示したメタ定義ファイル304を例に挙げて説明する。メタ定義ファイル304での項目定義は、クレンジング仕様定義ファイル301の初期化により割り当て済みの各ID(データ型ID、型属性ID、型属性値ID)を用いてコード化する。図24のメタ定義ファイル304では、項目定義として、従業員番号、氏名、住所、電話番号が表A(物理モデル)および表B(論理モデル)に定義されている。したがって、項目定義ごとに表別にコード化する。
図44は、図24に対応するコード化メタ定義340を示す説明図である。コード化メタ定義情報340では、メタ定義ファイル304において<COLUMN>タグで定義されている項目定義に対応する項目メタ定義テーブルを作成し、各項目の性質は前述の変換ルール群330におけるデータ型用変換ルールテーブルと同じ構造にすることによって、データ型用変換ルールテーブルの参照を簡素化するように構成する。具体的には、項目メタ定義テーブルの配列番号[0]はデータ型IDとし、配列番号[1以降]は配列番号を型属性IDとしたときの、型属性値IDとする構造にする。なお、項目メタ定義テーブル間の矢印はメタ定義ファイル304において<MAP_RULE>タグで定義されているマッピング定義を表しており、表Aから表Bへのデータ変換を行う場合は、矢印の始端はFrom側(変換元)を示しており、終端はTo側(変換先)を示している。
図44の(A)は、従業員番号について、From側のデータモデルである表AとTo側のデータモデルである表Bとのコード化メタ定義情報340を示している。(B)は、氏名について、From側のデータモデルである表AとTo側のデータモデルである表Bとのコード化メタ定義情報340を示している。(C)は、住所について、From側のデータモデルである表AとTo側のデータモデルである表Bとのコード化メタ定義情報340を示している。(D)は、電話番号について、From側のデータモデルである表AとTo側のデータモデルである表Bとのコード化メタ定義情報340を示している。
たとえば、図44の(B)に示す表Aの氏名を例に挙げると、配列番号[0]には、表Aの氏名項目のデータ型として定義されている人名型のデータ型ID:2(図26を参照)を設定する。また、配列番号[1]には、表Aの氏名項目に定義されている型属性について、配列番号[1]を型属性IDとするchar_code型属性(図27を参照)について、その型属性値:JEFの型属性値ID:1(図30を参照)を設定する。同様に、配列番号[2]には、型属性ID:2であるchar_excode型属性(図27を参照)の型属性値:外字1の型属性値ID:0(図31を参照)を設定する。同様に、配列番号[3]には、型属性ID:3であるmax_length型属性(図27を参照)の型属性値:20(図41を参照)を設定する。同様に、配列番号[4]には、型属性ID:4であるname_space型属性(図27を参照)の型属性値:Yesの型属性値ID:0(図32を参照)を設定する。なお、表Aの電話番号項目におけるmax_length型属性のように、メタ定義ファイル304で型属性値が未定義でありクレンジング仕様定義ファイル301でデフォルト値も定義されていない場合は“−1”を設定する。
このように、コード化メタ定義情報340では、項目メタ定義テーブルの項目番号[0]にその項目のデータ型IDを設定し、項目番号[1]から順次項目番号を型属性IDとする型属性値IDを設定する。これにより、クレンジング仕様定義ファイル301に基づいて展開された変換ルール群330との照合を効率化することができる。ここで、図44の(B)に示した表Aおよび表Bの氏名に関するコード化メタ定義情報340を用いたデータ変換例について説明する。表Aの氏名の値となる変換対象データを、「山田 和夫」とする。
図45〜図49は、図44に示した表Aおよび表Bの氏名に関するコード化メタ定義情報340を用いたデータ変換例1を示す説明図である。初期化処理により、あらかじめ上述したように、システム全体として整合性のあるコード化が行われ、各処理はコードによって処理を実行することができる(各処理が意味を認知しているのと同意である)。つぎにクレンジング処理部によるデータ変換処理では、クレンジング制御部351には図45に示した変換対象の項目に関する項目メタ定義テーブルと値が与えられ、変換処理が開始される。
変換処理では、まず、From側とTo側とのデータ型の比較をおこなう。From側のコード化メタ定義情報340とTo側のコード化メタ定義情報340について、配列番号[0]の値が比較される。この場合は、ともに“2”でありデータ型ID:2(人名型)で同じデータ型と認識される。
データ型が同じであるため、つぎに、From側とTo側との型属性の比較をおこなう。すなわち、先頭の型属性である配列番号[1]の値どうしが比較される。図45では、From側が“1”(JEF)、To側が“0”(SJIS)であるため、図43の変換ルール群330により変換処理を特定する。
具体的には、データ型ID:2(人名型)であるため変換ルールテーブル4300を配列番号[2]で参照することによって、人名型用変換ルールテーブル4302を参照する。
つぎに、人名型用変換ルールテーブル4302において現在比較している配列番号[1]のchar_code用クレンジングルールテーブル332(図37)を参照する。つぎに、From側の型属性値IDが“1”(JEF)、To側の型属性値IDが“0”(SJIS)であるため各IDを配列番号として図37のchar_code用クレンジングルールテーブル332を参照することによって、「文字コード系変換」の呼び出しポインタを特定する。これらの処理はプログラミング言語(例えばC言語)では次のように一度に処理でき、高速に動作する。
変換処理=変換ルール[データ型ID]−>ルール[型属性ID]−>クレンジングルール[From側の型属性値ID][To側の型属性値ID];
このように、クレンジング機能として「文字コード系変換」が特定されたため、図23で前述した「文字コード系変換」を実行することにより、文字コード系(char_code)と外字コード系(char_excode)を同時に変換し、当該変換結果をFrom定義とTo値に設定する。これにより、図46に示すように表Aの氏名に関するコード化メタ定義情報340の配列番号[1],[2]の値が変換後の値である“0”(SJIS)、“1”(外字2)に更新される。併せて、表Bの氏名値にはSJISで外字2を用いた値として「山田 和夫」が設定される。
つぎに、図46のメタ定義について、同様につぎの配列番号[2]に設定されている型属性値IDを比較する。ここでは、型属性値IDがともに“1”(外字2)であるため、つぎの配列番号[3]に進む。
配列番号[3]の型属性値IDどうしを比較すると、表Aの氏名では“20”、表Bの氏名では“14”である。このように両者の値が異なるため、変換処理を特定する。
具体的には、現在比較している人名型用変換ルールテーブル4302の配列番号[3]のmax_length用クレンジングルールテーブル332を参照する。max_length用クレンジングルールテーブル332(図41を参照)は任意の型属性値を用いるため、From側およびTo側がともに“0”で定義されているクレンジング機能として「length調整」が特定される。したがって、「length調整」を呼び出す。そして、前の処理結果のTo値をFrom値に設定して「length調整」を実行する。図47は、「length調整」機能の実行を示しており、図48はその結果を示している。具体的には、From値の文字列長が14バイトを超えている場合は、14バイトに調整される。
図48では、「length調整」を実行したことにより、From定義の配列番号[3]が変換結果の型属性値(To定義の配列番号[3]の値)に更新されている。具体的には、表Aの氏名に関するメタ定義の配列番号[3]の値が、“20”から“14”に更新される。このあと、次の配列番号[4]についても同様に実行することで、「姓名空白処理」が特定され、From定義の値は、変換後の型属値に更新される(図49を参照)。
これにより、From定義である表Aの氏名に関するコード化メタ定義とTo定義である表Bの氏名に関するコード化メタ定義において、全ての配列番号における値が一致する。このようにすべてが一致したため、変換処理を終了する。このように、From定義の値を左から順に順次比較して、異なる場合に処理を特定して実行することを繰り返すことで、高速なデータ変換を実現することができる。
<データ変換処理手順>
つぎに、実施の形態1にかかるデータ変換装置300によるデータ変換処理手順について、図50〜図54を用いて説明する。
図50は、実施の形態1にかかるデータ変換装置300によるデータ変換処理手順を示すフローチャートである。まず、初期化部311により、初期化処理を実行する(ステップS5001)。初期化処理(ステップS5001)の詳細については、図51および図52において説明する。
つぎに、クレンジング処理部312により、データ変換処理を実行する(ステップS5002)。データ変換処理(ステップS5002)の詳細については、図54において説明する。このあと、データ変換を継続するか否かを判断する(ステップS5003)。判断基準は、ユーザによる操作入力でもよく、変換対象データの有無でもよい。
継続する場合(ステップS5003:Yes)、ステップS5002に戻って、データ変換処理を実行する。一方、継続しない場合(ステップS5003:No)、開放処理を実行する(ステップS5004)。開放処理では、初期化処理(ステップS5001)で獲得したメモリ上の資源を開放する。これにより、データ変換処理を終了する。
図51は、図50に示した初期化部311による初期化処理(ステップS5001)の詳細な処理手順(前半)を示すフローチャートである。図51において、まず、クレンジング仕様定義ファイル301を読み込んで解析する(ステップS5101)。つぎに、データ型コード表作成処理を実行する(ステップS5102)。具体的には、各データ型にデータ型IDを付与する。たとえば、図26に示したように、すべてのデータ型について、定義順に1から始まり隙間のない全体で一意な整数を、データ型IDとして付与する。
そして、型属性コード表作成処理を実行する(ステップS5103)。具体的には、各型属性に型属性IDを付与する。たとえば、図27〜図29に示したように、データ型毎に、すべての型属性について、祖先のデータ型から順に定義順に1から始まり、隙間のないデータ型内で一意な整数を、型属性IDとして付与する。ここで、継承関係にあるデータ型間においては、共通する型属性の型属性IDはシステム全体で一致するように制御する。
そして、型属性値コード表作成処理を実行する(ステップS5104)。具体的には、たとえば、図30〜図35に示したように、各型属性値に型属性値IDを付与する。型属性値コード表作成処理(ステップS5104)の詳細については、図53において説明する。
型属性値コード表作成処理(ステップS5104)のあと、図36に示したように、データ型変換ルールテーブル331を生成する(ステップS5105)。そして、図37〜図42に示したように、クレンジングルールテーブル332を生成する(ステップS5106)。このあと、図43に示したように、変換ルール群330としてまとめて(ステップS5107)、図52のステップS5201に移行する。
図52は、図50に示した初期化部311による初期化処理(ステップS5001)の詳細な処理手順(後半)を示すフローチャートである。変換ルール群330が構築されたあと、図52において、メタ定義ファイル304を読み込んで解析する(ステップS5201)。つぎに、解析された情報の種類を順次判断する(ステップS5202)。具体的には、データ型であるか、型属性であるか、型属性値であるかを判断する。ここでは、メタ定義ファイル304の記述順で判断することとなる。
データ型である場合(ステップS5202:データ型)、データ型のID化を実行する(ステップS5203)。具体的には、データ型コード表321(図26)を参照してデータ型IDに変換する。そして、ステップS5208に移行する。
また、情報の種類が型属性である場合(ステップS5202:型属性値)、型属性のID化を実行する(ステップS5204)。具体的には、型属性コード表322(図27〜図29)を参照して型属性IDに変換する。そして、ステップS5208に移行する。
また、情報の種類が型属性値である場合(ステップS5202:型属性値)、コード化している型属性値であるか否かを判断する(ステップS5205)。コード化している型属性値である場合(ステップS5205:Yes)、型属性値コード表323(図30〜図35)を参照して、型属性値IDに変換する(ステップS5206)。そして、ステップS5208に移行する。
一方、コード化している型属性値ではない場合(ステップS5205:No)、整数値である型属性値をそのまま型属性値IDとする(ステップS5207)。そして、ステップS5208に移行する。
ステップS5208においては、図44に示したように、メタ定義ファイル304内のデータモデルの項目定義をコード化することによって項目メタ定義テーブルを作成する(ステップS5208)。具体的には、配列番号[0]にデータ型IDを設定し、配列番号[1]、[2]、[3]、…に、その配列番号を型属性IDとする型属性の型属性値IDや型属性値(コード化していない場合)を設定する。たとえば、データモデルが表Aの従業員項目に関する項目メタ定義テーブルを作成する場合、図44に示したように、配列番号[0]には従業員番号項目のデータ型である整数型を示すデータ型ID:4(図26を参照)を設定し、配列番号[1]には整数型の型属性ID:1であるmax_digit型属性(図29参照)の型属性値:12(図35参照)を設定する。ここで、max_digit型属性の型属性値はコード化していない型属性値なので、メタ定義ファイル304で指定されている型属性値:12をそのまま設定している。
このあと、メタ定義ファイル304内のすべてのデータモデルがコード化されたか否かを判断する(ステップS5209)。すべてコード化されていない場合(ステップS5209:No)、ステップS5202に戻って残りのコード化を行う。一方、すべてコード化された場合(ステップS5209:Yes)、図44に示したように、コード化された項目メタ定義の集合として、コード化メタ定義情報340を構成する(ステップS5210)。このあと、データ変換処理(ステップS5002)に移行する。
図53は、図51に示した型属性値コード表作成処理(ステップS5104)の詳細な処理手順を示すフローチャートである。まず、クレンジング仕様定義ファイル301において未選択の型属性をポイントする(ステップS5301)。つぎに、ポイントされた型属性について型属性値が定義されているか否かを判断する(ステップS5302)。型属性値が定義されている場合(ステップS5302:Yes)、ポイントしている型属性の型属性値として定義されているすべての型属性値について型属性値IDを付与する(ステップS5303)。具体的には、型属性毎の定義順に、0から始まり隙間のない型属性内で一意な整数を型属性値IDとして付与する。このあと、ステップS5305に移行する。
一方、型属性値が定義されていない場合(ステップS5302:No)、定義されていない型属性値に対しては、メタ定義ファイル304を参照し、該当する型属性に関して、すべての型属性値がそのまま型属性値とすることができる整数値である場合は、メタ定義ファイル304に定義されている型属性値をそのまま型属性値IDとして使用することとする。それ以外の値が存在する場合は、0から始まり隙間のない型属性内で一意な整数を型属性値IDとして付与する(ステップS5304)。このあと、ステップS5305に移行する。
そして、ステップS5305において、未選択の型属性があるか否かを判断する(ステップS5305)。未選択の型属性がある場合(ステップS5305:Yes)、ステップS5301に戻る。一方、未選択の型属性がない場合(ステップS5305:No)、図51のステップS5105に移行して、データ型変換ルールテーブル331を生成することとなる。
図54は、図50に示したデータ変換処理(ステップS5002)の詳細な処理手順を示すフローチャートである。まず、未選択のコード化メタ定義情報340のペアがあるか否かを判断する(ステップS5401)。未選択のコード化メタ定義情報340のペアがある場合(ステップS5401:Yes)、未選択のコード化メタ定義情報340のペアを選択する(ステップS5402)。
ここで、コード化メタ定義情報340のペアとは、From側のコード化メタ定義情報340と、当該コード化メタ定義情報340に対応するTo側のコード化メタ定義情報340との組み合わせである。たとえば、図44の例では、From側である表Aの氏名に関するコード化メタ定義情報340を、From側のコード化メタ定義情報340とした場合、To側である表Bの氏名に関するコード化メタ定義情報340が、対応するTo側のコード化メタ定義情報340となる。
つぎに、定義ポイントdをd=0に設定し、選択されたコード化メタ定義情報340のペアを参照して、定義ポイントdの最大値Dを取得する(ステップS5403)。定義ポイントdは、選択されたコード化メタ定義情報340を参照するときに使用する配列番号を指定するための変数である。たとえば、d=0の場合は、From側のコード化メタ定義情報340およびTo側のコード化メタ定義情報340の配列番号[0]に設定された情報(この場合はデータ型ID)を指定する。
また、定義ポイントdの最大値Dは、選択された各コード化メタ定義情報340での配列番号の最大値となる。たとえば、図44の(B)に示したコード化メタ定義情報340のペアの場合、配列番号の最大値が“4”であるため、D=4とする。
つぎに、現在の定義ポイントdで指定されたFrom側のコード化メタ定義情報340およびTo側のコード化メタ定義情報340について定義ポイントdを配列番号として設定されている情報を参照する(ステップS5404)。そして、参照された情報が同じ値か否かを判断する(ステップS5405)。同じ値である場合(ステップS5405:Yes)、ステップS5411に移行する。
一方、参照された情報が同じ値でない場合(ステップS5405:No)、From側のコード化メタ定義情報340の配列番号[0]を参照してデータ型IDの取得を行い、そのデータ型IDを配列番号として変換ルールテーブル4300を参照することにより、該当するデータ型用変換ルールテーブル4301〜4304を取得する(ステップS5406)。取得したテーブルを「特定データ型用変換ルールテーブル」と称して記憶する。そして、ステップS5409に移行する。
たとえば、図44の(D)に示したコード化メタ定義情報340のペアの場合、配列番号[0]に設定されたデータ型IDが異なる(1(Char)と4(Integer))が、From側である表Aの電話番号に関するコード化メタ定義情報340の配列番号[0]に設定されたデータ型ID:1(Char)を取得する。そして、この値(データ型ID:1(Char))を配列番号として変換ルールテーブル4300を参照することによって、Char型変換ルールテーブル4301を特定データ型用変換ルールテーブルとして取得することとなる。
このあと、ステップS5407では、定義ポイントdを配列番号として特定データ型用変換ルールテーブルを参照することによって必要な変換ルール(データ型変換ルールテーブル331またはクレンジングルールテーブル332)を取得し、その変換ルールのFrom/ToをステップS5404で取得済みのFrom側およびTo側のコード化メタ定義情報340の値によって参照することによって、使用する変換機能を取得する。(ステップS5407)。
具体的には、前述の図44の(D)に示したコード化メタ定義情報340のペアの場合は、Char型変換ルールテーブル4301について定義ポイントd=0で参照することによって、データ型変換ルールテーブル331(図36を参照)を取得し、From側として、データ型ID:1(Char)、To側としてデータ型ID:4(Integer)で参照することによって変換機能「文字の整数変換」を取得する。このように、データ型変換ルールテーブル331と、クレンジングルールテーブルを同じ構造にすることによって、データ変換処理において区別することなく変換機能の取得を実現することができる。
つぎに、取得された変換機能が有効であるか否かを判断する(ステップS5408)。有効であるか無効であるかの判断基準は、「インストールされて動作可能である」など、予め設定しておけばよい。無効である場合(ステップS5408:No)、データ変換処理は失敗となるため、終了する。一方、有効である場合(ステップS5408:Yes)、取得した変換機能により変換処理を実行する(ステップS5409)。具体的には、たとえば、From値を変換してTo値に設定する。また、対処済みの定義内容をFrom定義に反映する(図23および、図45〜図49を参照)。
このあと、変換機能による変換処理が成功したか否かを判断する(ステップS5410)。不成功である場合(ステップS5410:No)、データ変換処理は失敗となるため、終了する。一方、成功である場合(ステップS5410:Yes)、ステップS5411に移行する。
そして、ステップS5411では、定義ポイントdをインクリメントする(ステップS5411)。このあと、d>Dであるか否かを判断する(ステップS5412)。d>Dでない場合(ステップS5412:No)、次の定義ポイントdについて処理するためにステップS5404に戻る。一方、d>Dである場合(ステップS5412:Yes)、全ての定義ポイントについて処理が完了したので、ステップS5401に戻る。ステップ5401において、未選択のコード化メタ定義情報340のペアがない場合(ステップS5401:No)、データ変換処理(ステップS5002)を完了して、図50のステップS5003に移行することとなる。
このように、本実施の形態1によれば、データ型や型属性、クレンジング機能を、目的に応じて拡張することができる。また、複数のデータ型や型属性、クレンジング機能を組み合わせて使用する場合の整合性も取れているため、拡張時の整合性を損なうことがない。したがって、開発者の負担軽減を図ることができる。
また、データ型や型属性、型属性値およびデータ型変換機能、クレンジング機能を必要最小限に抑えることにより、開発コストの低減化や管理の容易化を図ることができる。クレンジング機能を効率よく使い分けることにより、データ変換性能の向上を図ることができる。更に、データ型や型属性、型属性値についてシステム全体についてコード化を行うことによって、更なるデータ変換性能の向上を図ることができる。
(実施の形態2)
つぎに、実施の形態2について説明する。実施の形態2は、実施の形態1に対し、下記の機能F1〜F7を付加する。
F1:既存の型属性に対して制約(前提条件)を設定し、その範囲内で動作するクレンジング機能を定義できるようにする。
F2:クレンジング処理の実行時には、制約を守るための変換処理を先に実行した後で、処理本体を実行する。
F3:新規追加する機能は、自ら別の型属性の変換を行う。
F4:型属性を合わせるクレンジング処理の順番を、後方(より特殊な型属性)から処理する。
F5:クレンジング処理の制約(前提条件)については、自分以外のすべての型属性を扱えるように拡張する。その上で、最後に実行した変換が扱う型属性から、順番に処理して、一巡するまでは、繰り返し変換処理を実行する。
F6:機能F5の処理する順番は、必ずしも後方向(より拡張的な型属性)から前方に向かう(逆順である)必要はなく、正順(より基本的な型属性から順に拡張的な型属性を処理する)でもよい。従って、効率のよい処理方向を選択することも可能。
F7:共通の処理系で機能F1〜機能F6を選択できるようにする。
上記機能F1〜F6の組み合わせパターン(以下、「制御パターンP#」)は、下記の制御パターンP1〜P6となる。
P1:クレンジング処理に制約(前提条件)を定義して、前提条件を守った処理を実現する。ただし、制約条件は自分より前(より基本的な型属性)とする(逆順)。機能F1,F2,F4の組み合わせで実現される。
P2:クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は自分より前(より基本的な型属性)とする(逆順)。機能F3および機能F4の組み合わせで実現される。
P3:クレンジング処理に制約(前提条件)を定義して、前提条件を守った処理を実現する。制約条件にする型属性は任意の型属性を使える(逆順)。機能F1,F2,F5の組み合わせで実現される。
P4:クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は任意の型属性にできる(逆順)。機能F3,F5の組み合わせで実現される。
P5:クレンジング処理に制約(前提条件)を定義して、前提条件を守った処理を実現する。制約条件にする型属性は任意の型属性を使える(正順)。機能F1,F2,F6の組み合わせで実現される。
P6:クレンジング機能に他の型属性の変換機能を持たせる。ただし、変換する型属性は任意の型属性にできる(正順)。機能F3,F6の組み合わせで実現される。以下、機能F1〜F7ごとに説明する。
<機能F1>
図55は、機能F1により制約が設定されたクレンジング仕様定義ファイル301の一例を示す説明図である。機能F1は、既存の型属性に対して制約(前提条件)を設定し、その範囲内で動作する。図55に示したクレンジング仕様定義ファイル301は、図25に示したクレンジング仕様定義ファイル301について、人名型に着目して、機能F1を追加した例である。ここでは、Char型が既に定義されているクレンジング仕様定義ファイル301に対して、人名のデータ型定義記述5501を新規に追加する場合について例示している。
図55において、人名のデータ型定義記述5501では、新規に追加するクレンジング機能として姓名空白処理機能が定義されている。図49に示した(実施の形態1における)姓名空白処理機能では、姓名空白処理機能は自分が扱う型属性(name_space) とは異なる型属性(max_length,char_excode,char_code)について、指定可能な全ての組み合わせについてFrom値(変換元)およびTo値(変換先)として扱うことが求められる。例えば、全ての文字コード系(SJIS、JEF、UTF8)についてFrom値、To値として姓名空白処理を実行する機能が求められる。
機能F1は、自分が扱う型属性(name_space)と異なる型属性(max_length,char_excode,char_code)に対して、クレンジング機能の動作可能な条件を宣言する機能である。この機能により、姓名空白処理機能が動作可能な条件を指定することができ、姓名空白処理機能を簡略化することができる。
より具体的には、たとえば、人名のデータ型定義記述5501のクレンジングルールタグに、「rule=“char_code=SJIS”」という制約を設定しておくことで、当該制約により型属性char_code=SJISという条件で動作するように実装するだけでよく、他の文字コードに対応する必要がなくなるので、姓名空白処理機能を簡略することができることと併せて、文字コード系としてUTF16が追加されるケースなど、他の機能追加の影響を最小化する効果がある。
<機能F2>
図56は、機能F2による変換例を示す説明図である。機能F2は、クレンジング処理の実行時にはクレンジング処理部によって、機能F1で指定された制約を守るための変換処理を先に実行した後で、クレンジング処理本体を実行する。図55において、人名のデータ型定義記述では、新規追加クレンジング機能として姓名空白処理機能が定義され、「rule=“char_code=SJIS”」という制約が定義されている。図56においては、新規追加の姓名空白処理機能により姓名空白処理を実行する前に、「char_code=SJIS」の制約を守るための文字コード系変換を行うことによって、姓名空白処理は文字コード系「SJIS」を前提とした動作で十分となるように制御できる。
<機能F3>
機能F3では、新規追加機能は、当該機能が担当する型属性とは別の型属性に対する必要な変換を行う機能を有し、自ら型属性値を変更することを許す。この場合は機能F1の制約の定義と、機能F2の制約を守るためのクレンジング処理部の機能は不要になるので、クレンジング仕様定義ファイル301は図25に示す人名型の定義と同じでよい。また、機能F3による他の型属性の変換機能は、追加するクレンジング機能がクレンジング制御部に依頼して実行することも可能である。前述の姓名空白処理について機能F3を適用すると、姓名空白処理の前に自ら型属性char_code=SJISという変換を行い、型属性値を変更する機能を持たせることになる。
<機能F4>
機能F4は、型属性を合わせるクレンジング処理の順番を、後方(より特殊な型属性)から処理する。すなわち、逆順で実行する機能である。この場合、機能F1において制約に指定できる型属性、または機能F3で変更できる型属性は、自分より前の(自分より基本的な)型属性とする。
これにより、新しく追加した型属性(機能)から先に実行され、同時に処理が済んだ基本的な型属性を変更することにより、既存の機能が動作することを抑制することができる。また、機能F2の制約による前処理のための制御戻り(無理やり変更した部分に戻って再処理すること)が不要になる。前述の姓名空白処理における文字コード系の制約のように、自分より前の(自分より基本的な)型属性を制約とする場合が多いので、機能F4は有効である。
<機能F5〜F7>
機能F5〜F7は、すべての型属性を制約として扱うための機能である。機能F4は、クレンジング処理の制約(前提条件)として、自分が扱う型属性より前方に定義されている(より基本的な)型属性に限定している。一般的にこの方が処理効率が良いので、この条件で十分なケースでは、機能F4で実装すべきである。一方、自分が扱う型属性より後方向に定義されている(より拡張的な)型属性も制約条件にする必要があるケースでは、機能F5により実現できる。
図57は、機能F5による変換例を示す説明図である。機能F5では、クレンジング処理の制約(前提条件)については、自分以外のすべての型属性を扱えるように拡張する。その上で、最後に実行した変換が扱う型属性から、順番に処理して、一巡するまでは、繰り返し変換処理を実行するように構成する。
図58は、機能F6の一例を示す説明図である。機能F5の処理する順番は、必ずしも後方向(より拡張的な型属性)から前方に向かう(逆順である)必要はない。したがって、機能F6のように、正順(より基本的な型属性から順に拡張的な型属性を処理する)でも処理は完結する。したがって、効率よい処理方向を選択することも可能になる。
以下に、実施の形態2の一実施例について説明する。ここでは、図55に示したクレンジング仕様定義ファイル301における人名データ型定義記述で定義されている姓名空白処理を例に挙げて説明する。
図59は、制約の導入例を示す説明図である。図59において、人名データ型定義記述で定義されている姓名空白処理では、「char_code=SJIS」の制約を宣言している。これにより、姓名空白処理は、担当する型属性:name_space(型属性ID=4)がFrom側とTo側で異なるときに実行されることと併せて、型属性:char_code(型属性ID=1)の型属性値がSJIS(型属性値ID=0)であるという前提のもとに実行される。したがって、追加実装したいときは、クレンジングルールにおいて制約を宣言するだけでよく、SJSI以外の文字コード系に対応する必要はなくなるので、クレンジング機能の実装を大幅に簡素化することができる。
制約を導入する場合、クレンジング仕様定義ファイル301の初期化時(図51)に、制約条件をクレンジングルールとともに変換ルールから参照できるように、制約条件テーブルを生成して、制約として展開する。具体的には、制約を宣言したクレンジング処理のクレンジングルールテーブル332と併せて参照できるような構造として、該当するクレンジング機能が設定されているFrom/Toの組み合わせと同一箇所に、コード化された制約を制約条件テーブルとして設定する。
図60は、制約条件テーブルの一例を示す説明図である。姓名空白処理が担当するname_space型属性用クレンジングルールテーブル332では、From/Toが(1,0)と(0,1)の場合に、姓名空白処理機能が呼び出される。したがって、姓名空白処理に関する制約条件は、クレンジングルールテーブル332と同じ構造で、同様に、From/Toが(1,0)と(0,1)の位置にコード化した制約条件『1(char_code)=0(SJIS)』を設定することにより、図60に示すname_space用制約条件テーブル6000を作成する。
図61は、制約が追加された場合の変換ルール群330を示す説明図である。図61の変換ルール群330は、図43に示した変換ルール群330に制約条件を展開した状態を示している。図61において、各データ型用変換ルールテーブル4301〜4304には、制約条件用のレコードが追加される。制約条件用のレコードにおいて、デフォルトは「NULL」である。図59のように制約が導入された場合、該当するデータ型用変換ルールテーブル4301〜4304の制約条件用のレコードにおいて、該当するクレンジングルールに対して制約条件テーブルへのポインタを設定する。
図61では、人名型用変換ルールテーブルの配列番号[4]に対して、name_space用クレンジングルールテーブル332の呼び出しポインタとともに、name_space用制約条件テーブルの呼び出しポインタが設定されている。これにより、人名型用変換ルールテーブルの配列番号[4]が指定されると、name_space用クレンジングルールテーブル332が呼び出されるとともに、name_space用制約条件テーブルも参照可能になる。つぎに、制約を導入した場合のデータ変換処理例について説明する。ここでは、機能F1,F2,F4を組み合わせた制御パターンP1を用いたデータ変換処理例について説明する。
図62〜図66は、図44に示した表Aおよび表Bの氏名に関するコード化メタ定義情報340を用いたデータ変換例2を示す説明図である。まず、初期化処理により、あらかじめデータ型や型属性、型属性値のコード化が行われ、各処理はコードの意味を認知している。つぎに、図62に示したコード化メタ定義340および値の情報がクレンジング制御部351に与えられ、変換処理が開始される。
クレンジング制御部では、まず、From側とTo側とのデータ型の比較をおこなう。具体的には、From側のコード化メタ定義情報340とTo側のコード化メタ定義情報340について、配列番号[0](データ型)の値が比較される。この場合は、ともに“2”(人名)で同じデータ型と認識される。
データ型が同じであるため、つぎに、From側とTo側との型属性の比較をおこなう。本例では、機能F4を採用するため、末尾の型属性である配列番号[4](name_space)の値どうしが比較される。図62では、From側が“0”(Yes)、To側が“1”(No)であるため、図61の変換ルール群330により変換処理を特定する。
具体的には、データ型ID:2(人名)であるため、データ型ID:2を配列番号として変換ルールテーブル4300を参照することにより、人名型用変換ルールテーブル4302を取得する。
つぎに、人名型用変換ルールテーブル4302において現在比較している配列番号[4]のname_space用クレンジングルールテーブル332(図39)を参照する。つぎに、図39のname_space用クレンジングルールテーブル332について、着目しているコード化メタ定義340の値であるFrom側が“1”(No)、To側が“0”(Yes)で参照することによって、姓名空白処理機能の呼び出しポインタを特定する。この姓名空白処理は、つぎの制約条件に対する処理の実行後に実行されることとなる。
また、人名型用変換ルールテーブル4302において現在比較している配列番号[4]の制約条件を参照すると、name_space用制約条件テーブル(図60)が設定されているので、name_space用制約条件テーブルを使用した制約条件に対する処理に移行する。図60のname_space用制約条件テーブル6000について、着目しているコード化メタ定義340の値であるFrom側が“1”(No)、To側が“0”(Yes)で参照することによって、制約条件『1(char_code)=0(SJIS)』を特定する。
つぎに、図63に示すように、特定された制約条件『1(char_code)=0(SJIS)』を遵守するため、name_space型属性に基づく姓名空白処理に先立って、型属性ID:1(文字コード系)をFrom側の値から制約条件に変換する処理を先に実行する。尚、図63〜図66は各処理の実行後の状態を示しており、網掛け部分は値の更新を示している。
具体的には、制約条件『1(char_code)=0(SJIS)』で指定された型属性ID:1について、From定義の値と、制約条件の値を比較して、制約条件に合っているかを確認する。この例では、図62に示すようにFrom定義の値“1”(JEF) ≠ 制約条件の値“0”(SJIS)であるので、From側を制約条件に合わせる処理が先に必要になる。From定義はデータ型ID:2であるため、データ型ID:2を配列番号として図61の変換ルールテーブル4300を参照して、人名型用変換ルールテーブル4302を参照する。
つぎに、人名型用変換ルールテーブル4302において現在比較している配列番号[1]のchar_code用クレンジングルールテーブル332(図37)を参照する。図62に示したように、From側が“1”(JEF)、To側(制約条件)が“0”(SJIS)であるため、図37のchar_code用クレンジングルールテーブル332をFrom[1]、To[0]で参照して文字コード系変換処理の呼び出しポインタを特定する。そして、特定された呼び出しポインタにより文字コード系変換処理を呼び出して、文字コード系変換処理を実行する。これにより、図63に示すように、文字コード系がJEFであるFrom値の対象文字列「山田 和夫」が制約条件であるSJISに変換されTo値に設定され、From定義の項目番号[1](char_code)の値が、”0”(SJIS)に更新される。
つぎに、図64に示すように、保留しておいた姓名空白処理を実行する。姓名空白処理では、図63に示すように、From側のコード化メタ定義情報340の配列番号[4](name_space)は“0”(Yes)、To側のコード化メタ定義情報340の配列番号[4]では“1”(No)であるため、図64に示すように、SJISに変換された対象文字列「山田 和夫」をFrom値として、姓名間の空白が削除され、SJISの「山田和夫」としてTo値に設定される。そして、From側のコード化メタ定義情報340の配列番号[4]の値を“0”(Yes)から“1”(No)に更新する。
つぎに、図65に示すように、一つ前の配列番号[3](max_length)の処理を実行する。具体的には、図64に示す配列番号[3](max_length)の値について、From定義とTo定義との比較をおこなう。この場合は、From側が“20”、To側が“14”であり、値が異なるため、図61の変換ルール群330により変換処理を特定する。
更に具体的には、データ型ID:2(人名)であるため、データ型ID:2を配列番号として変換ルールテーブル4300を参照することにより人名型用変換ルールテーブル4302を得る。
つぎに、取得した人名型用変換ルールテーブル4302において現在比較している配列番号[3]の変換ルールによりmax_length用クレンジングルールテーブル332(図41)を参照する。max_length型属性は任意の値をとるため、図41のmax_length用クレンジングルールテーブル332において、From/Toの値にかかわらず、From[0],To[0]のlength調整処理の呼び出しポインタを特定する。
また、図61において、配列番号[3]では、制約条件テーブルの呼び出しポインタが設定されておらず、NULLとなっているため、そのまま、length調整処理を実行する。図65に示すように、姓名間の空白を削除されたSJISのFrom値文字列「山田和夫」に対しては4の文字8バイトしかないため、length調整処理が実行されてもTo値はFrom値と同じ値となる。また、From定義[3](max_length)の値は変換後の状態である“14”(14バイト)に更新される。
つぎに、図66に示すように、一つ前の配列番号[2](char_excode)の処理を実行する。具体的には、図65に示す配列番号[2](char_excode)の値について、From定義とTo定義との型の比較をおこなう。この場合は、From定義が“0”(外字1)、To定義が“1”(外字2)であり、値が異なるため、図61の変換ルール群330により変換処理を特定する。
更に具体的には、データ型ID:2(人名)であるため、データ型ID:2を配列番号として変換ルールテーブル4300を参照することによって、人名型用変換ルールテーブル4302を取得する。
つぎに、取得した人名型用変換ルールテーブル4302において現在比較している配列番号[2]のchar_excode用クレンジングルールテーブル332(図38)を参照する。図65に示したように、From側が“0”(外字1)、To側が“1”(外字2)であるため、図38のchar_excode用クレンジングルールテーブル332をFrom[0],To[1]で参照して、文字コード系変換処理の呼び出しポインタを特定する。
そして、特定された呼び出しポインタにより文字コード系変換処理を呼び出して、文字コード系変換処理を実行する。なお、文字コード系変換処理では、char_excodeだけでなくchar_codeについても処理するが、char_codeについては制約条件により実行済みであるため、char_excodeのみの変換となる。図66に示すように、変換結果はTo値にSJIS、外字2による「山田和夫」が設定され、From定義の[2]の値は“1”(外字2)に更新される。
以上で、データ型およびすべての型属性が同じになったので、変換処理を終了する。このように、先頭のデータ型の次は、定義の値を右から順に順次比較して、異なる場合に処理を特定して実行する。また、制約条件が設定されている場合は、先に制約条件を守るための変換を行うことを繰り返す。これにより、柔軟性を損なうことなく、制約を遵守したデータ変換処理を最小限のコストで実現することができる。
また、型属性を後方(右側)から順に処理することにより、新しく追加された型属性が先に評価され、新変換機能が優先して実行される。また、新変換機能と競合する旧変換機能は、新変換機能が旧変換機能の型属性を変更することができる。したがって、新変換機能の制御下で動作を抑制することができる。
たとえば、図66に示したように、型属性を後方(右側)から順に処理することにより、新規追加型属性であるchar_excodeが旧型属性であるchar_codeよりも先に評価され、新変換機能(文字コード系変換処理)が優先して実行される。またこの場合、新変換機能と旧変換機能はともに文字コード系変換処理であるため、先に実行される文字コード系変換処理において、char_code型属性を変換することで、旧変換機能での文字コード系変換処理を抑制することが可能となる。すなわち、重複処理を回避することができる。
<データ変換処理手順>
つぎに、実施の形態2にかかるデータ変換装置300によるデータ変換処理手順について、図67〜図72を用いて説明する。
図67は、実施の形態2にかかるデータ変換装置300によるデータ変換処理手順を示すフローチャートである。まず、初期化部311により、初期化処理を実行する(ステップS6701)。初期化処理(ステップS6701)の詳細については、図68および図69において説明する。
つぎに、クレンジング処理部312により、データ変換処理を実行する(ステップS6702)。データ変換処理(ステップS6702)の詳細については、図71において説明する。このあと、データ変換を継続するか否かを判断する(ステップS6703)。判断基準は、ユーザによる操作入力でもよく、変換対象データの有無でもよい。
継続する場合(ステップS6703:Yes)、ステップS6702に戻って、データ変換処理を実行する。一方、継続しない場合(ステップS6703:No)、開放処理を実行する(ステップS6704)。開放処理では、初期化処理(ステップS6701)で獲得したメモリ上の資源を開放する。これにより、データ変換処理を終了する。
図68は、図67に示した初期化部311による初期化処理(ステップS6701)の詳細な処理手順(前半)を示すフローチャートである。図68において、まず、クレンジング仕様定義ファイル301を読み込んで解析する(ステップS6801)。つぎに、制御パターン選定処理を実行する(ステップS6802)。制御パターン選定処理(ステップS6802)とは、上述した制御パターンP1〜P6および実施の形態1に相当する制御パターンP0の中から該当する制御パターンを選定する。制御パターン選定処理(ステップS6802)の詳細については、図70において後述する。
制御パターン選定処理(ステップS6802)により制御パターンPが選定された場合、データ型コード表作成処理を実行する(ステップS6803)。具体的には、各データ型にデータ型IDを付与する。たとえば、図26に示したように、すべてのデータ型について、定義順に1から始まり隙間のない全体で一意な整数を、データ型IDとして付与する。
そして、型属性コード表作成処理を実行する(ステップS6804)。具体的には、各型属性に型属性IDを付与する。たとえば、図27〜図29に示したように、データ型毎に、すべての型属性について、祖先のデータ型から順に定義順に1から始まり、隙間のないデータ型内で一意な整数を、型属性IDとして付与する。ここで、継承関係にあるデータ型間においては、共通する型属性の型属性IDはシステム全体で一致するように制御する。
そして、型属性値コード表作成処理を実行する(ステップS6805)。具体的には、たとえば、図30〜図35に示したように、各型属性値に型属性値IDを付与する。型属性値コード表作成処理(ステップS6805)の詳細については、図53に示した処理内容と同一であるため説明を省略する。
型属性値コード表作成処理(ステップS6805)のあと、図36に示したように、データ型変換ルールテーブル331を生成する(ステップS6806)。そして、図37〜図42に示したように、クレンジングルールテーブル332を生成する(ステップS6807)。このあと、図69のステップS6901に移行する。
図69は、図67に示した初期化部311による初期化処理(ステップS6701)の詳細な処理手順(後半)を示すフローチャートである。クレンジングルールテーブル332が生成されたあと、図69において、選定された制御パターンを識別する(ステップS6901)。制御パターンPがP0,P2,P4,P6である場合(ステップS6901:P0,P2,P4,P6)、ステップS6903に移行する。一方、制御パターンPがP1,P3,P5である場合(ステップS6901:P1,P3,P5)、図60に示したように、制約条件テーブルを生成する(ステップS6902)。そして、ステップS6903に移行する。
ステップS6903では、図61に示したように、変換ルール群330としてまとめる(ステップS6903)。このあと、メタ定義ファイル304を読み込んで解析する(ステップS6904)。つぎに、解析された情報の種類を順次判断する(ステップS6905)。具体的には、データ型であるか、型属性であるか、型属性値であるかを判断する。ここでは、メタ定義ファイル304の記述順で判断することとなる。
データ型である場合(ステップS6905:データ型)、データ型のID化を実行する(ステップS6906)。具体的には、データ型コード表321(図26)を参照してデータ型IDに変換する。そして、ステップS6911に移行する。
また、情報の種類が型属性値である場合(ステップS6905:型属性値)、型属性のID化を実行する(ステップS6907)。具体的には、型属性コード表322(図27〜図29)を参照して型属性IDに変換する。そして、ステップS6911に移行する。
また、情報の種類が型属性値である場合(ステップS6905:型属性値)、コード化している型属性値であるか否かを判断する(ステップS6908)。コード化している型属性値である場合(ステップS6908:Yes)、型属性値コード表323(図30〜図35)を参照して、型属性値IDに変換する(ステップS6909)。そして、ステップS6911に移行する。
一方、コード化している型属性値ではない場合(ステップS6908:No)、整数値である型属性値をそのまま型属性値IDとする(ステップS6910)。そして、ステップS6911に移行する。
ステップS6911においては、図44に示したように、メタ定義ファイル304内のデータモデルの項目定義をコード化することによって項目メタ定義テーブルを作成する(ステップS6911)。具体的には、配列番号[0]にデータ型IDを設定し、配列番号[1]、[2]、[3]、…に、その配列番号を型属性IDとする型属性の型属性値IDや型属性値(コード化していない場合)を設定する。たとえば、データモデルが表Aの従業員項目に関する項目メタ定義テーブルを作成する場合、図44に示したように、配列番号[0]には従業員番号項目のデータ型である整数型を示すデータ型ID:4(図26を参照)を設定し、配列番号[1]には整数型の型属性ID:1であるmax_digit型属性(図29参照)の型属性値:12(図35参照)を設定する。ここで、max_digit型属性の型属性値はコード化していない型属性値なので、メタ定義ファイル304で指定されている型属性値:12をそのまま設定している。
このあと、メタ定義ファイル304内のすべてのデータモデルがコード化されたか否かを判断する(ステップS6912)。すべてコード化されていない場合(ステップS6912:No)、ステップS6905に戻って残りのコード化を行う。一方、すべてコード化された場合(ステップS6912:Yes)、図44に示したように、コード化された項目メタ定義の集合として、コード化メタ定義情報340を構成する(ステップS6913)。このあと、データ変換処理(ステップS6702)に移行する。
図70は、図68に示した制御パターン選定処理(ステップS6802)の詳細な処理手順を示すフローチャートである。まず、クレンジング仕様定義ファイル301に制約があるか否かを判断する(ステップS7001)。具体的には、たとえば、図55の人名データ型定義5501に示したように、制約が宣言されているか否かを判断する。
制約がある場合(ステップS7001:Yes)、制約の方向を判断する(ステップS7002)。制約の方向判断については、たとえば、制約の対象となる型属性がすべて自分(制約を宣言しているクレンジング定義がある型属性)より上位であるか、制約の対象となる型属性がすべて自分より下位であるか、制約の対象となる型属性が自分より上位の型属性と下位の型属性とが混在しているか、を基準とする。
たとえば、図55の例では、制約が「rule=“char_code=SJIS”」であるため、制約の対象となる型属性は“char_code”である。また、自分(の型属性)は、制約「rule=“char_code=SJIS”」が宣言されているクレンジングルール(<CL_RULE>タグ)を持つ型属性“name_space”である。この場合、図55において、“char_code”は“name_space”よりも上位に定義(同じデータ型定義内の上の行、または継承先のデータ型定義に記述)されているため、制約の方向は「上位」となる。
上位である場合(ステップS7002:上位)、制御パターンP1に決定して(ステップS7003)、ステップS6803に移行する。一方、下位または混在である場合(ステップS7002:下位または混在)、競合する変換機能があるか否かを判断する(ステップS7004)。ここで、競合する変換機能について説明する。
例えば、char_code型属性について文字コード系変換を行う一般的な文字コード系変換機能(ここでは文字コード系変換機能1と称する)が使用されている環境に、外字の違いを変換することができる(char_code型属性と併せてchar_excode型属性に対応することができる)文字コード系変換機能(ここでは文字コード系変換機能2と称する)を追加するときに、外字体系が同じデータの変換は効率的な文字コード系変換機能1を使用し、外字体系が異なるデータの変換は高機能な文字コード系変換機能2を使用したい場合がある。
このように同じ型属性値に対する変換機能を有する変換機能を同時に使用可能な状態にするとき、両者は「競合する変換機能」であるとする。一般的に文字コード系変換機能2のような高機能なクレンジング機能は後方の型属性に対する変換として設定するので、後方の型属性から先に処理する制御パターンとすることにより競合を解消して効率的な使い分けを実現することができる。
競合する変換機能がある場合(ステップS7004:Yes)、制御パターンP3に決定し(ステップS7005)、競合する変換機能がない場合(ステップS7004:No)、制御パターンP5に決定する(ステップS7006)。そして、ステップS6803に移行する。
一方、ステップS7001において、クレンジング仕様定義ファイル301に制約がない場合(ステップS7001:No)、制約を自ら実行する機能F3を持つ変換機能があるか否かを判断する(ステップS7007)。具体的には、<機能F3>で前述したように、クレンジング仕様定義ファイル301には制約を定義しないため、クレンジング機能の「制約を実行する機能の有無」は、例えばクレンジング仕様定義ファイルのクレンジング機能を定義する部分に、制約を実行する機能の有無と、具体的な制約対象の型属性を示す情報を記載しておき、その情報によって判断することになる。ここで、「具体的な制約対象の型属性」は後述するステップS7011の判断に必要となる情報である。
制約を実行する変換機能がない場合(ステップS7007:No)、競合する変換機能があるか否かを判断する(ステップS7008)。ステップS7008は、ステップS7004と同一処理である。競合する変換機能がある場合(ステップS7008:Yes)、制御パターンP2に決定する(ステップS7009)。一方、競合する変換機能がない場合(ステップS7008:No)、制御パターンP0に決定する(ステップS7010)。そして、ステップS6803に移行する。
また、ステップS7007において、制約を実行する変換機能がある場合(ステップS7007:Yes)、制約の方向を判断する(ステップS7011)。ステップS7011は、ステップS7002と同一処理であるが、制約対象の型属性はステップS7007で前述したように別途情報を得る手段を必要とする。下位である場合(ステップS7011:下位)、制御パターンP0に決定する(ステップS7012)。
また、上位である場合(ステップS7011:上位)、制御パターンP2に決定する(ステップS7013)。また、混在である場合(ステップS7011:混在)、競合する変換機能があるか否かを判断する(ステップS7014)。ステップS7014は、ステップS7004と同一処理である。競合する変換機能がある場合(ステップS7014:Yes)、制御パターンP4に決定する(ステップS7015)。一方、競合する変換機能がない場合(ステップS7014:No)、制御パターンP6に決定する(ステップS7016)。そして、ステップS6803に移行する。
図71は、図67に示したデータ変換処理(ステップS6702)の詳細な処理手順を示すフローチャート(その1)である。まず、未選択のコード化メタ定義情報340のペアがあるか否かを判断する(ステップS7101)。未選択のコード化メタ定義情報340のペアがない場合(ステップS7101:No)、ステップS6703に移行する。一方、未選択のコード化メタ定義情報340のペアがある場合(ステップS7101:Yes)、未選択のコード化メタ定義情報340のペアを選択する(ステップS7102)。
つぎに、制御パターンPを識別する(ステップS7103)。制御パターンPがP0〜P2である場合(ステップS7103:P0〜P2)、ステップS7105に移行する。一方、制御パターンPがP3〜P6である場合(ステップS7103:P3〜P6)、制約ポイントRをR=0に設定して(ステップS7104)、ステップS7105に移行する。
ステップS7105では、定義ポイントdをd=0に設定し、選択されたコード化メタ定義情報340のペアを参照して、定義ポイントdの最大値Dを取得する(ステップS7105)。
このあと、制御パターンPを識別する(ステップS7106)。制御パターンPがP0,P5,P6である場合(ステップS7106:P0,P5,P6)、ステップS7108に移行する。一方、制御パターンPがP1〜P4である場合(ステップS7106:P1〜P4)、定義ポイントdを最大値Dに設定して(ステップS7107)、ステップS7108に移行する。そして、指定されたFrom側のコード化メタ定義情報340およびTo側のコード化メタ定義情報340について、現在の定義ポイントdを配列番号として設定されている情報を参照する(ステップS7108)。つぎに、参照された情報が同じ値か否かを判断する(ステップS7109)。
同じ値である場合(ステップS7109:Yes)、制御パターンPを識別する(ステップS7110)。制御パターンPがP1〜P4である場合(ステップS7110:P1〜P4)、定義ポイントdをデクリメントして(ステップS7111)、ステップS7113に移行する。一方、制御パターンPがP0,P5,P6である場合(ステップS7110:P0,P5,P6)、定義ポイントdをインクリメントして(ステップS7112)、ステップS7113に移行する。
そして、ステップS7113において、再度制御パターンPを識別する(ステップS7113)。制御パターンPがP1,P2である場合(ステップS7113:P1,P2)、定義ポイントdがd=0であるか否かを判断する(ステップS7114)。そして、d=0でない場合(ステップS7114:No)、ステップS7108に戻り、d=0である場合(ステップS7114:Yes)、ステップS7101に戻る。
また、制御パターンPがP0である場合(ステップS7113:P0)、定義ポイントdがd=Dであるか否かを判断する(ステップS7115)。そして、d=Dでない場合(ステップS7115:No)、ステップS7108に戻り、d=Dである場合(ステップS7115:Yes)、ステップS7101に戻る。
また、制御パターンPがP3〜P6である場合(ステップS7113:P3〜P6)、定義ポイントdがd=Rであるか否かを判断する(ステップS7116)。そして、d=Rでない場合(ステップS7116:No)、ステップS7108に戻り、d=Rである場合(ステップS7116:Yes)、ステップS7101に戻る。
また、ステップS7109において、S7108で参照された情報が同じ値でない場合(ステップS7109:No)、図72のステップS7201に移行する。
図72は、図67に示したデータ変換処理(ステップS6702)の詳細な処理手順を示すフローチャート(その2)である。
まず、From側のコード化メタ定義情報340を配列番号[0]で参照することによりFrom側のデータ化IDを取得し、取得したデータ型IDを配列番号にして変換ルールテーブル4300を参照し、該当するデータ型用変換ルールテーブル4301〜4304を取得する(ステップS7201)。取得されたテーブルを「特定データ型用変換ルールテーブル」と称す。
このあと、制御パターンPを識別する(ステップS7202)。制御パターンPがP0,P2,P4,P6である場合(ステップS7202:P0,P2,P4,P6)、ステップS7207に移行する。一方、制御パターンPがP1,P3,P5である場合(ステップS7204:P1,P3,P5)、制約条件があるか否かを判断する(ステップS7203)。
この、ステップS7203の処理は、特定データ型用変換ルールテーブルについて定義ポイントdを配列番号として参照することによって、変換ルールテーブル(データ型変換ルールテーブル331またはクレンジングルールテーブル332)の取得を行い、その変換ルールテーブルについて、ステップS7108で参照したコード化メタ定義ペアの値をそれぞれ、From/Toの配列番号として制約条件の参照を行い、NULLであれば、制約条件がないと判断し、NULL以外であれば制約条件があると判断して、その制約条件テーブルへのポインタを記憶しておく。
このとき、ステップS7108で参照したコード化メタ定義ペアの値がコード化されない任意の値である場合は、From/Toの配列番号は共に[0]として変換ルールテーブルの参照を行い、制約条件を参照する。制約条件がない場合(ステップS7203:No)、ステップS7207に移行する。
一方、制約条件がある場合(ステップS7203:Yes)、制約条件を実行する(ステップS7204)。この制約条件の実行は、図62〜図64で説明したように、現在の値の状態をFrom定義とし、制約条件をTo定義とする他は通常のクレンジング処理に準じた処理である。つぎに、再度制御パターンPを識別する(ステップS7205)。制御パターンPがP1である場合(ステップS7205:P1)、ステップS7207に移行する。一方、制御パターンPがP3,P5である場合(ステップS7205:P3,P5)、制約ポイントRを現在の定義ポイントdに設定し(ステップS7206)、ステップS7207に移行する。
このあと、ステップS7207では、特定データ型用変換ルールテーブルについて定義ポイントdを配列番号として参照することによって、変換ルールテーブル(データ型変換ルールテーブル331またはクレンジングルールテーブル332)の取得を行い、その変換ルールテーブルについて、ステップS7108で参照したコード化メタ定義ペアの値をそれぞれ、From/Toの配列番号として実行すべき変換機能を取得する(ステップS7207)。このとき、ステップS7108で参照したコード化メタ定義ペアの値がコード化されない任意の値である場合は、From/Toの配列番号は共に[0]として変換ルールテーブルの参照を行い、実行すべき変換機能を取得する(ステップS7207)。
そして、取得された変換機能により変換処理を実行する(ステップS7208)。具体的には、たとえば、From値を変換してTo値に設定する。また、対処済みの定義内容をFrom定義に反映する(図45〜図49を参照。)。このあと、図71のステップS7110に戻る。
このように、実施の形態2では、多様な条件で動作するクレンジング機能を低負担で開発することができる。また、新たなクレンジング機能の追加においても、既存の機能への悪影響を与えることなく、柔軟に対応することができる。さらに、クレンジング機能がリアルタイム処理を含む様々な機能から実行される場合であっても、高性能化を図ることができる。
つぎに、上述した実施の形態1および実施の形態2で説明したデータ変換装置の機能的構成について説明する。
図73は、実施の形態にかかるデータ変換装置の詳細な機能的構成を示すブロック図である。図73では、図3−1に示した初期化部311とクレンジング処理部312の詳細な機能的構成を示している。まず、初期化部311の詳細な機能的構成について説明する。なお、記憶部7310には、クレンジング仕様定義ファイル301、型変換機能ライブラリ302、クレンジング機能ライブラリ303、メタ定義ファイル304が記憶されているものとする。
初期化部311は、仕様定義情報取得部7300と、第1の設定部7301と、第2の設定部7302と、構築部7303と、第3の設定部7304と、メタ定義情報取得部7305と、生成部7306と、補完部7307と、を有する。
仕様定義情報取得部7300は、変換元(From側)のメタデータおよび変換先(To側)のメタデータとして使用することができるデータ変換装置が扱うメタデータの仕様(データ型、型属性、型属性値など)と、それらの組み合わせとして実現できるデータ変換機能を定義した仕様定義情報を取得する機能を有する。
ここで、仕様定義情報とは、データ変換の仕様を定義した情報であり、たとえば、上述したクレンジング仕様定義ファイル301が挙げられる。また、メタデータとは、変換対象データそのものではなく、変換対象データの性質に関する情報と、対象データ間の関連情報である。上述したクレンジング仕様定義ファイル301では、データの性質を表すデータ型、型属性、型属性値、および、データの構造を表す表、カラム、マッピングなどがメタデータに相当する。
データ変換機能とは、変換元のメタデータ(From定義)で定義された性質を持つ変換元のデータ値(From値)を、変換先のメタデータ(To定義)で定義されたデータ値(To値)に変換する機能である。データ変換機能は、具体的には、たとえば、図3−1〜図3−3に示した型変換機能やクレンジング機能に相当する。また、上述したクレンジング仕様定義ファイル301においては、型変換機能の場合は、変換できるデータ型の組み合わせと併せてDTCV_RULEタグ411で定義されている。また、クレンジング機能の場合は、変換できる型属性および型属性値の組み合わせと併せて、クレンジングルール定義タグ(CL_RULEタグ)414で定義されている。
第1の設定部7301は、仕様定義情報取得部7300によって取得された仕様定義情報に基づいて、データ変換装置で使用できるメタデータの仕様を確定し、確定したメタデータの仕様について、外部表現で規定されているメタデータ仕様を可能な限りID化(数値化)してメタデータコードとすることによって、内部表現のメタデータ仕様を作成する機能を有する。ここで、メタデータコードとは、メタデータ仕様の外部表現に対応する数値コードである。また、メタデータ仕様の外部表現とメタデータコードを対応付けるために管理表としてメタデータコード化テーブルを作成する。
たとえば、図26に示したように、メタデータ仕様がデータ型である場合、メタデータコードは、データ型IDである。そして、第1の設定部7301は、メタデータコード化テーブルとして、データ型コード表321を設定する。
また、図27〜図29に示したように、メタデータ仕様が型属性である場合、メタデータコードは、型属性IDである。そして、第1の設定部7301は、メタデータコード化テーブルとして、型属性コード表322を設定する。また、図30〜図33に示したように、メタデータ仕様が型属性値である場合、メタデータコードは、型属性値IDである。そして、第1の設定部7301は、メタデータコード化テーブルとして、型属性値コード表323を設定する。
また、メタデータ仕様が任意の値を取ることができる場合、メタデータ仕様の外部表現をそのままメタデータコードにする。たとえば、図34に示したように、型属性:max_lengthの型属性値は任意の値をとるため、メタデータコード化テーブルとして、「そのまま値を使用する」という情報を記録した型属性値コード表323を設定する。
また、仕様定義情報において定義された第1のメタデータ仕様を、第2のメタデータ仕様が継承する記述が定義されている場合、仕様定義情報における第1のメタデータ仕様の下位階層のメタデータ仕様のメタデータコードを、第2のメタデータ仕様の下位階層のメタデータ仕様として取り込むようなメタデータコード化テーブルを設定することとしてもよい。
具体的には、図9に示したデータ型の継承を規定することができる。たとえば、第1のメタデータ仕様がchar型で、第2のメタデータ仕様が人名型である場合、人名型の下位階層となる型属性や型属性値は、char型の型属性や型属性値を引き継いで、図27に示したような型属性コード表322を設定することができる。
継承の機能によって下位階層のメタデータ仕様について共通部分が統一されるため、処理系全体の矛盾を解消し、重複するデータ変換を防止することができる。
また、第2の設定部7302は、第1の設定部7301によって設定されたメタデータコード化テーブルを参照することにより、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに応じてデータ変換機能を関連付けることにより、データ変換ルールテーブルを設定する機能を有する。ここで、データ変換ルールテーブルとは、変換元のメタデータコードと変換先のメタデータコードとの組み合わせによりデータ変換機能を特定するテーブルである。上述した実施の形態では、データ型変換ルールテーブルとクレンジングルールテーブルが該当する。
たとえば、メタデータ仕様がデータ型である場合、図36に示したように、データ変換ルールテーブルはデータ型変換ルールテーブルとなり、メタデータ仕様が型属性である場合、図37〜図42に示したように、その型属性値に基づいてデータ変換(クレンジング)するクレンジングルールテーブルとなる。
また、構築部7303は、第2の設定部7302によって設定された変換ルールテーブルごとに上位の変換ルールコードと関連付けることにより、変換ルールを構築する機能を有する。ここで、変換ルールコードとは、変換ルールテーブルが適用される上位のメタデータ仕様に割り当てられたコードである。
具体的には、たとえば、最上位のメタデータ仕様がデータ型である場合、図43に示したように、最上位の変換ルールコードはデータ型IDである。最上位であるデータ型変換ルールテーブルに対しては、直下の階層における変換ルールコードとして0が割り当てられる。また、メタデータ仕様が型属性である場合、図43に示したように、各型属性に適用されるクレンジングルールテーブル332に対し、型属性IDが割り当てられる。
そして、構築部7303は、これらをまとめあげることで、変換ルールとして、データ型用変換ルールテーブル4301〜4304を構築する。また、データ型が複数ある場合には、図43に示したように、データ型用変換ルールテーブル4301〜4304をまとめあげて、変換ルール群330を構築する。
また、第3の設定部7304は、データ変換機能に制約条件が設定されている場合、データ変換機能が設定されている変換ルールテーブルをコピーして、データ変換機能に代えて、制約条件を割り当てることにより、制約条件テーブルを設定する機能を有する。具体的には、たとえば、実施の形態2において、図60で説明したように、クレンジングルールテーブル332をコピーしてデータ変換機能に対応する制約条件を設定することによって制約条件テーブル6000を作成する。そして、構築部7303により、制約条件テーブル6000は、図61に示したように、データ変換機能と併せて参照できるように構成される。
また、メタ定義情報取得部7305は、変換元および変換先のメタデータが定義されたメタ定義情報を取得する機能を有する。ここで、メタ定義情報とは、変換元と変換先のデータについて、その性質および構造をあらわすメタデータを定義するとともに、どの変換元と変換先の関連を定義した情報である。たとえば、上述したメタ定義ファイル304が該当する。
また、生成部7306は、メタ定義情報取得部7305によって取得されたメタ定義情報内のメタデータごとに、当該メタデータの第一の設定部7301で割り当てられた変換ルールコードを使用してコード化することにより、コード化メタ定義情報を生成する機能を有する。具体的には、たとえば、メタ定義ファイル304内のデータ型や型属性、型属性値に、そのデータ型や型属性、型属性値に、データ型ID,型属性ID、型属性値IDによりコード化する(図44を参照。)。このように処理系全体で統一したコード化を行うことで、変換ルール群330との照合の効率化を実現することができる。
また、補完部7307は、メタ定義情報取得部7305によって取得されたメタ定義情報内に省略されているメタデータが有る場合に、仕様定義情報取得部から取得して補完部に記憶しているメタデータ仕様のデフォルト値指定を利用して省略されているメタデータを補完する機能を有する。具体的には、たとえば、図16に示したように、クレンジング仕様定義ファイル301において、型属性のデフォルト属性値として“char_code:JEF”、“max_length:20”、“name_space:Yes”のように指定されている場合に、図17の下段に示すように型属性が省略されたメタ定義ファイル304をメタ定義情報取得部が取得すると、記憶している型属性とそのデフォルト値を使用して補完することによって、図17上段のメタ定義ファイル304と等価なコード化メタ定義情報に補正することができる。
これにより、メタ定義ファイル304であは意味を保ったまま簡略化することができる。つぎに、クレンジング処理部321の詳細な機能的構成について説明する。
図73において、クレンジング処理部321は、入力部7311と、検出部7312と、判断部7313と、変換機能特定部7314と、テーブル特定部7315と、変換部7316と、更新部7317と、出力部7318とを有する。検出部7312、判断部7313、変換機能特定部7314、およびテーブル特定部7315は、図3−1に示したクレンジング制御部351を構成する機能である。
入力部7311は、変換対象データの入力を受け付ける機能を有する。具体的には、たとえば、メタ定義ファイル304で定義された変換元のメタデータを持つ変換対象データの入力を受け付ける。変換対象データの入力と併せて、変換元のメタデータを特定する情報も指定することにより、変換対象データの変換元のメタデータが特定されれば、メタ定義ファイル304にて変換先が定義されているため、メタ定義ファイル304に従ってデータ変換を実行することができる。ここで、変換先のメタデータを特定する情報も指定するように構成することもできる。
また、検出部7312は、コード化メタ定義情報340を参照することにより、変換元および変換先で変換ルールコードが一致する変換元および変換先のメタデータコードを検出する機能を有する。具体的には、たとえば、図44に示したように、変換元(表A)と変換先(表B)とで、変換ルールコードである配列番号が一致する変換元(表A)のデータ型ID/型属性値IDと変換先(表B)のデータ型ID/型属性値IDとを検出する。
たとえば、図44の(B)において、変換元(表Aの氏名)と変換先(表Bの氏名)とで一致する配列番号:0(データ型)について、変換元(表Aの氏名)のデータ型ID:2(人名型)と変換元(表Bの氏名)のデータ型ID:2(人名型)とを検出する。
また、コード化メタ定義情報340において、図44に示したように、変換ルールコード(配列番号)が、メタデータの優先順位順の連続番号として割り当てられている場合、優先順位の高い順から変換元(表A)と変換先(表B)とのメタデータコード(データ型ID/型属性値ID)を検出して、一致判断することとしてもよい。これにより、重要な型属性から順次クレンジングが実行されることになるため、無駄な処理の発生を防止でき、クレンジング処理の簡素化を図ることができる。
また、判断部7313は、検出部7312によって検出された変換元のメタデータコードと変換先のメタデータコードとが一致するか否かを判断する機能を有する。一致する場合は変換先として変換元と同じ性質を求めているので、変換元のメタデータコードで規定される性質から変換先のメタデータコードで規定される性質に変換する必要はない。したがって、メタデータコードの一致を検出して変換処理に渡さないことで、データ変換の効率化を図ることができる。
また、不一致である場合、テーブル特定部7315による変換ルールテーブルの特定をおこなう。テーブル特定部7315は、判断部7313によって不一致であると判断された場合、変換元の変換ルールコードに基づいて変換ルールを参照することにより、データ型変換ルールテーブル331(変換ルールコード=0である場合)またはクレンジングルールテーブル332(変換ルールコード≠0である場合)の中から該当する変換ルールテーブルを特定する機能を有する。
この変換ルールテーブルの特定は、図43に示した変換ルール群330を参照し、変換元のコード化メタ定義の項目番号[0]の値を項目番号として変換ルール4300を参照することによって該当するデータ型用変換ルールテーブル4301〜4304を特定し、不一致となった変換ルールコード(コード化メタ定義の項目番号)を項目番号として特定したデータ型用変換ルールテーブルを参照することによって変換ルールテーブル(データ型変換ルールテーブル331またはクレンジングルールテーブル332)を特定する。
たとえば、図44の(B)の変換ルールコード:1について考えると、配列番号[1](char_code)では、変換元(表Aの氏名)は型属性値ID:1(JEF)、変換先(Bの氏名)は型属性値ID:0(SJIS)となり、型属性値IDが不一致である。この場合、変換元(表Aの氏名)の配列番号[0](データ型)を配列番号として変換ルール4300を参照してChar型用のデータ型用変換ルールテーブル4301を特定し、処理対象の変換ルールコード:1を配列番号として特定したデータ型用変換ルールテーブル4301を参照することによりchar_code用クレンジングルールテーブル332を特定することとなる。ここで、処理対象の変換ルールコードが[1]である場合には、データ型用変換ルールテーブル4301を配列番号[0]で参照することによって、Char型用のデータ型変換ルールテーブル331と特定することになる。
また、変換機能特定部7314は、判断部7313によって判断された判断結果に基づいて、変換ルールテーブルを参照することにより、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに応じてデータ変換機能を特定する機能を有する。具体的には、変換元のメタデータコードをFrom側の配列番号として、変換先のメタデータコードをTo側の配列番号として、テーブル特定部7315によって特定された変換ルールテーブル(データ型変換ルールテーブル331またはクレンジングルールテーブル332)を参照することによって、変換元のメタデータコードと変換先のメタデータコードとの組み合わせに該当するデータ変換機能を特定する。
たとえば、上述した図44の(B)、変換ルールコード:1の例では、char_code用クレンジングルールテーブル332(図37参照)において、From側の配列番号を変換元(表Aの氏名)の型属性値ID:1(JEF)、To側の配列番号を変換先(表Bの氏名)の型属性値ID:0(SJIS)として参照する。これにより、データ変換機能として「文字コード系変換機能」を特定することができる。
また、変換ルールテーブル(データ型変換ルールテーブル331またはクレンジングルールテーブル332)では、変換元および変換先のメタデータコードが同一である場合、データ変換機能を割り当てていない(図36〜図40参照)。これは判断部7313において変換元および変換先のメタデータコードが一致する場合は、変換が不要と判断して以降の変換処理を行わないため使用されない組み合わせとなる。また、判断部に頼ることなく、変換ルールテーブルにデータ変換機能が割り当てられていない場合には変換部による変換が行われないように制御することもできる。したがって、無駄なデータ変換を防止することができる。
また、変換部7316は、変換機能特定部7314によって特定されたデータ変換機能を用いて、変換元のメタデータで規定される性質を有する変換元の対象データを、変換先のメタデータで規定される性質に変換する機能を有する。具体的には、たとえば、データ変換機能に、変換元のメタデータ、変換先のメタデータ、変換対象データをまとめて与えることで、変換対象データを変換する。
たとえば、上述した図44の(B)、変換ルールコード:1の例では、文字コード系変換機能に対し、変換元の型属性値:1(JEF)、変換先の型属性値:0(SJIS)、変換対象データ(たとえば、文字列)を与えることで、JEFで表現された変換対象データを、SJISで表現されたデータに変換する。
また、更新部7317は、変換部7316によって変換された場合、検出部7312による検出処理の次の実行に先立って、コード化メタ定義情報340のうち、変換部7316によって変換された変換元のメタデータコードを変換先のメタデータコードに更新する機能を有する。具体的には、たとえば、図45と図46において、変換元(表Aの氏名)の配列番号[1](char_code)の型属性値IDを比較すると、変換前である図45では、型属性値ID:1(JEF)であるが、変換後である図46では、変換前である図45の変換先(表Bの氏名)の配列番号[1]の型属性値ID:0(SJIS)に更新する。(図45、図46では変換機能が同時にChar_excodeの変換も行っている。)
これにより、後続ではこれまでの変換が反映されて、変換元(表Aの氏名)と変換先(表Bの氏名)とでは、ともに型属性値がSJISとなり、データ変換が不要となる。したがって、変換対象データ(変換元)は、最新状態のコード化メタ定義情報340で処理されることとなり、データ変換の効率化を図ることができる。
また、実施の形態2に示したように、制約条件テーブル6000がある場合、制約条件が設定されている変換ルールコードに対応するデータ変換機能に先立って、制約条件に従って制約条件に指定された変換ルールコードに対するデータ変換をおこなう。したがって、制約条件を設定したデータ変換機能では、制約条件の基で動作するよう実装するだけでよく、それ以外のメタデータについて対応する必要がなく、実装を大幅に簡素化することができる。
また、出力部7318は、変換後の変換対象データを出力する機能を有する。具体的には、たとえば、変換先となるコンピュータに送信したり、記憶部7310に記憶したりする。また、ディスプレイに表示したり、プリンタにより印刷することとしてもよい。
このように、実施の形態1および実施の形態2によれば、利便性の向上と開発者の開発負担を軽減とを図ることができ、処理効率も高いという効果を奏する。
なお、本実施の形態で説明したデータ変換方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ変換プログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本データ変換プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)変換元および変換先のデータに関する性質をあらわすメタデータが定義されたメタ定義情報内のメタデータを構成する要素に対して固有なコードとしてメタデータコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで性質が規定される変換元データを前記変換先のメタデータで規定される性質を持つ変換先のデータに変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに担当するメタデータコードを変換ルールコードとして関連付けた変換ルールと、を記憶する記憶手段と、
変換対象データの入力を受け付ける入力手段と、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段と、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段と、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換元のメタデータコードで規定される性質を有する前記変換対象データ(変換元データ)を、前記変換先のメタデータで規定される性質に変換する変換手段と、
を備えることを特徴とするデータ変換装置。
(付記2)前記変換機能特定手段は、
前記判断手段によってメタデータコードが一致すると判断された場合、前記データ変換機能を特定せず、
前記変換手段は、
前記変換対象データを変換しないことを特徴とする付記1に記載のデータ変換装置。
(付記3)前記判断手段によって不一致であると判断された場合、前記変換元の変換ルールコードに基づいて前記変換ルールを参照することにより、前記データ型変換ルールテーブルまたは前記クレンジングルールテーブルの中から該当する変換ルールテーブルを特定するテーブル特定手段を備え、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定することを特徴とする付記1に記載のデータ変換装置。
(付記4)前記変換ルールテーブルでは、前記変換元のメタデータが任意の値をとる場合、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせにかかわらず、共通のデータ変換機能が割り当てられており、
前記コード化メタ定義情報では、前記任意の値をとる前記変換元および前記変換先のメタデータを特定するメタデータコードとして前記メタデータをそのまま用いており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせにかかわらず、前記共通のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記共通のデータ変換機能を用いて、前記変換対象データのデータを変換することを特徴とする付記1〜3のいずれか1つに記載のデータ変換装置。
(付記5)前記変換ルールテーブルでは、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる組み合わせの場合に、前記変換元のメタデータで規定された性質を持つデータから前記変換先のメタデータで規定された性質を持つデータに変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記1〜4のいずれか1つに記載のデータ変換装置。
(付記6)前記変換ルールテーブルでは、前記変換元のメタデータが予め指定されたメタデータであり、前記変換先のメタデータが前記変換元のメタデータとは異なるメタデータとなる組み合わせの場合に、前記変換元のメタデータで規定される性質を有する変換元データから前記変換先のメタデータで規定される性質に変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記1〜4のいずれか1つに記載のデータ変換装置。
(付記7)前記変換ルールテーブルでは、前記変換先のメタデータが予め指定されたメタデータであり、前記変換元のメタデータが前記変換先のメタデータとは異なるメタデータとなる組み合わせの場合に、前記変換元のメタデータで規定される性質を有する変換元データから前記変換先のメタデータで規定される性質に変換する特定のデータ変換機能が割り当てられており、
前記変換機能特定手段は、
前記テーブル特定手段によって特定された変換ルールテーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとが異なる場合、前記特定のデータ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定された前記特定のデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記1〜4のいずれか1つに記載のデータ変換装置。
(付記8)前記コード化メタ定義情報では、前記変換ルールコードが、前記メタデータの優先順位順の連続番号として割り当てられており、
前記検出手段は、
前記コード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出処理を、優先順位が最も高い変換ルールコードから順次実行することを特徴とする付記1〜7のいずれか1つに記載のデータ変換装置。
(付記9)前記メタデータは、前記変換対象データのデータ型、当該データ型の型属性、当該型属性の値の中から選ばれた要素で記述されており、
前記コード化メタ定義情報では、前記変換ルールコードについて前記データ型、前記型属性の順に優先順位が設定されていることを特徴とする付記8に記載のデータ変換装置。
(付記10)前記検出手段は、
最初に前記データ型について前記検出処理を実行し、当該検出処理以降は、前記型属性の変換ルールコードの優先順位にしたがって前記検出処理を実行することを特徴とする付記9に記載のデータ変換装置。
(付記11)最初に前記データ型について前記検出処理を実行し、当該検出処理以降は、前記型属性の変換ルールコードの優先順位の逆順にしたがって前記検出処理を実行することを特徴とする付記9に記載のデータ変換装置。
(付記12)前記変換手段によって変換された場合、前記検出手段による前記検出処理の次の実行に先立って、前記コード化メタ定義情報のうち、前記変換手段によって変換された前記変換元のメタデータコードを前記変換先のメタデータコードに更新する更新手段を備えることを特徴とする付記8または9に記載のデータ変換装置。
(付記13)前記記憶手段は、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能による変換処理を制約する制約条件が設定された制約条件テーブルを記憶しており、
前記変換ルールは、さらに、前記制約条件により変換処理が制約されるデータ変換機能に関連付けられた変換ルールコードに前記制約条件テーブルが関連付けられており、
前記テーブル特定手段は、
前記判断手段によって不一致であると判断された場合、前記変換元の変換ルールコードに基づいて前記変換ルールを参照することにより、前記変換ルールテーブルの特定に先立って、前記変換ルールテーブルに関連付けされた制約条件テーブルを特定し、
前記検出手段は、
前記テーブル特定手段によって特定された制約条件テーブルを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記制約条件として定義されている前記変換元の変換ルールコードおよびメタデータコードを検出し、前記コード化メタ定義情報を参照することにより、前記制約条件として定義されている前記変換元の変換ルールコードと一致する前記変換先のメタデータコードを検出し、
前記判断手段は、
前記検出手段によって検出された前記制約条件として定義されている前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断し、
前記変換機能特定手段は、
前記判断手段によって判断された判断結果に基づいて、前記変換ルールを参照することにより、前記制約条件として定義されている前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定し、
前記変換手段は、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを変換することを特徴とする付記3に記載のデータ変換装置。
(付記14)変換元および変換先のメタデータに関する仕様および前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段と、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記メタデータを特定するメタデータコードを前記メタデータに関連付けたメタデータコード化テーブルを設定する第1の設定手段と、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第2の設定手段と、
前記第2の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段と、
を備えることを特徴とするデータ変換装置。
(付記15)前記第1の設定手段は、
前記メタデータが任意の値をとることができる特殊なメタデータである場合、前記メタデータを前記メタデータコードとしてそのまま用いた特殊なメタデータコード化テーブルを設定し、
前記第2の設定手段は、
前記特殊なメタデータについて、前記変換元の前記特殊なメタデータから前記変換先の前記特殊なメタデータに変換するデータ変換機能を関連付けた変換ルールテーブルを設定することを特徴とする付記14に記載のデータ変換装置。
(付記16)前記第1の設定手段は、
前記仕様定義情報において定義されている第1のメタデータと同階層の第2のメタデータについて、前記第1のメタデータを継承する記述が定義されている場合、前記仕様定義情報における前記第2のメタデータは、前記第1のメタデータに定義されている下位階層のメタデータそのまま包含するように構成されたメタデータコード化テーブルを設定することを特徴とする付記14または15に記載のデータ変換装置。
(付記17)前記第1の設定手段は、
前記第1のメタデータについて前記メタデータコード化テーブルを設定しないことを特徴とする付記16に記載のデータ変換装置。
(付記18)前記データ変換機能に制約条件が設定されている場合、前記データ変換機能が設定されている変換ルールテーブルをコピーして、前記データ変換機能に代えて、前記制約条件を割り当てることにより、制約条件テーブルを設定する第3の設定手段を備え、
前記構築手段は、
さらに、前記制約条件により変換処理が制約されるデータ変換機能に関連付けられた変換ルールコードに前記第3の設定手段によって設定された制約条件テーブルを関連付けることにより、前記変換ルールを構築することを特徴とする付記14〜17のいずれか1つに記載のデータ変換装置。
(付記19)前記変換元および前記変換先のメタデータが定義されたメタ定義情報を取得するメタ定義情報取得手段と、
前記メタ定義情報取得手段によって取得されたメタ定義情報内のメタデータごとに、当該メタデータに関する前記変換ルールテーブルに固有な変換ルールコードを割り当ててコード化することにより、コード化メタ定義情報を生成する生成手段と、
を備えることを特徴とする付記14〜18のいずれか1つに記載のデータ変換装置。
(付記20)前記仕様定義情報に定義されている特定のメタデータの下位階層のメタデータがデフォルト指定されている場合、前記メタ定義情報において省略されている当該デフォルト指定されたメタデータを補完する補完手段を備え、
前記生成手段は、
前記補完手段による補完後のメタ定義情報内のメタデータごとに、当該メタデータに関する前記変換ルールテーブルに固有な変換ルールコードを割り当ててコード化することにより、コード化メタ定義情報を生成することを特徴とする付記19に記載のデータ変換装置。
(付記21)変換対象データの入力を受け付ける入力手段と、
前記生成手段により生成されたコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段と、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記構築手段によって構築された変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段と、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを変換する変換手段と、
を備えることを特徴とする付記19または20に記載のデータ変換装置。
(付記22)変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶装置にアクセス可能なコンピュータが、
変換対象データの入力を受け付ける入力工程と、
前記記憶装置に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出工程と、
前記検出工程によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断工程と、
前記判断工程によって判断された判断結果に基づいて、前記記憶装置に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定工程と、
前記変換機能特定工程によって特定されたデータ変換機能を用いて、前記変換対象データを、前記変換元のメタデータで規定されている性質から前記変換先のメタデータで規定されている性質に変換する変換工程と、
を実行することを特徴とするデータ変換方法。
(付記23)コンピュータが、
変換元のメタデータおよび前記変換元のメタデータから変換先のメタデータに変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得工程と、
前記仕様定義情報取得工程によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第1の設定工程と、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第2の設定工程と、
前記第2の設定工程によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築工程と、
を実行することを特徴とするデータ変換方法。
(付記24)コンピュータを、
変換元および変換先のメタデータが定義されたメタ定義情報内の前記変換元および前記変換先のメタデータを特定するメタデータコードに対し固有な変換ルールコードを割り当てたコード化メタ定義情報と、前記変換元のメタデータで規定される性質を持つ変換元データを前記変換先のメタデータで規定される性質に変換するデータ変換機能と、前記変換元および前記変換先のメタデータコードの組み合わせに応じて前記データ変換機能を割り当てた変換ルールテーブルと、当該変換ルールテーブルごとに前記変換ルールコードを関連付けた変換ルールと、を記憶する記憶手段、
変換対象データの入力を受け付ける入力手段、
前記記憶手段に記憶されているコード化メタ定義情報を参照することにより、前記変換元および前記変換先で前記変換ルールコードが一致する前記変換元および前記変換先のメタデータコードを検出する検出手段、
前記検出手段によって検出された前記変換元のメタデータコードと前記変換先のメタデータコードとが一致するか否かを判断する判断手段、
前記判断手段によって判断された判断結果に基づいて、前記記憶手段に記憶されている変換ルールを参照することにより、前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を特定する変換機能特定手段、
前記変換機能特定手段によって特定されたデータ変換機能を用いて、前記変換対象データを、前記変換元のメタデータで規定される性質から前記変換先のメタデータで規定される性質に変換する変換手段、
として機能させることを特徴とするデータ変換プログラム。
(付記25)コンピュータを、
変換元および変換先のメタデータに関する仕様および前記変換元のメタデータで規定される性質を持つ変換元データを前記から変換先のメタデータで規定される性質に変換するデータ変換機能を定義した仕様定義情報を取得する仕様定義情報取得手段、
前記仕様定義情報取得手段によって取得された仕様定義情報における前記変換元のメタデータを特定するメタデータコードを前記変換元のメタデータに関連付けたメタデータコード化テーブルを設定する第1の設定手段、
前記変換元のメタデータコードと前記変換先のメタデータコードとの組み合わせに応じて前記データ変換機能を関連付けることにより、前記変換ルールテーブルを設定する第2の設定手段、
前記第2の設定手段によって設定された変換ルールテーブルごとに固有な変換ルールコードを関連付けることにより、変換ルールを構築する構築手段、
として機能させることを特徴とするデータ変換プログラム。