(57)【要約】【課題】レガシーアプリが利用していたUnixファイルを、新システムのリレーショナルデータベースに仮想テーブルや仮想カラムとして統合することにより、レガシーアプリを改変せずとも新システムで稼動可能とし、アプリケーション作成の工数を低減し生産性を向上させること。【解決手段】定義情報に基づいて、仮想カラムに他のテーブルのカラムの実体データを割り当て、また、Unixファイルを改変せずにファイルオープンしその全体又は一部について、仮想テーブル、仮想カラム、もしくは仮想カラムのセルの、全体又は一部の実体として割り付けるとともに該当する読書き要求に応じてアクセスすることにより、リレーショナルデータベースの内部にテーブルないしはテーブルの一部として包含するように取り込む。【選択図】図１
2009223512.tif 000002
【特許請求の範囲】
【請求項１】
Unixファイルと、リレーショナルデータベースと、を有する情報処理システムであって、
前記リレーショナルデータベースは、
リレーショナルデータベースのテーブルを構成するカラムであって、カラムとしての実体を持たず他のカラム、他のテーブルのカラムもしくはファイルの実体データを自らのデータとする仮想カラムと、
テーブルの全部又は一部について実体を持たず、前記仮想カラムを列の一部とし、又は他のテーブルもしくはファイルのデータを自らのデータとする、仮想テーブルと、
前記各仮想カラム及び仮想テーブルの少なくとも一方について、他のどのテーブル、カラムもしくはファイルの実体データを割り付けるかを定義する定義情報を記憶した定義記憶手段と、
前記定義情報に基づいて、前記仮想カラムに他のテーブルのカラムの実体データを割り当て、また、前記Unixファイルを改変せずにファイルオープンしその全体又は一部について、前記仮想テーブル、前記仮想カラム、もしくは仮想カラムのセルの、全体又は一部の実体として割り付けるとともに該当する読書き要求に応じてアクセスすることにより、リレーショナルデータベースの内部にテーブルないしはテーブルの一部として包含するように取り込む、割り当て手段と、
を有することを特徴とする情報処理システム。
【請求項２】
前記定義情報は、仮想カラムに割り当てる実体データの所在を示すアドレスデータを逆ポーランド記法で記載した計算式を有し、
前記割り当て手段は、前記定義情報の前記計算式に基づいて、該当するアドレスデータの実体データを、前記仮想カラムとしての表現形式に変換することによりテーブルの行と列として割り当てるように構成した
ことを特徴とする請求項１記載の情報処理システム。
【請求項３】
前記割り当て手段は、
前記逆ポーランド記法を用いた前記計算式を用いて、実体データの所在を示すアドレスデータを予め計算しその計算結果をテーブルのセル単位に記憶保持しておき、
仮想カラムへの割り当ての際に、前記記憶保持している前記計算結果を読み出して利用する
ように構成したことを特徴とする請求項２記載の情報処理システム。
【請求項４】
前記定義情報は、仮想カラムに割り当てる実体データについて、ビット単位に構成された各フィールドごとに、テーブルの行と列にどのように割り当てるかを表し、
前記割り当て手段は、前記定義情報に基づいて、該当する実体データをビット単位のフィールドごとに区分したうえ、該当するテーブルの行と列に割り当てるように構成した
ことを特徴とする請求項１から３のいずれか一項に記載の情報処理システム。
【請求項５】
前記定義情報は、任意のビット長で構成された配列を利用した実体データを、テーブルの行と列にどのように割り当てるかを表し、
前記割り当て手段は、前記定義情報に基づいて、前記実体データに対応する前記ビット長の配列又はその各要素を、テーブルの行と列に割り当てるように構成した
ことを特徴とする請求項１から４のいずれか一項に記載の情報処理システム。
【請求項６】
前記リレーショナルデータベースは、Unixファイル内部のデータに対して、符号誤りを検出するデータ改変検出コードを周期的に生成して保存するとともに、次回周期において前回のデータ改変検出コードとの比較を行うことによりUnixファイルの更新を検出する、更新検出手段を有する
ことを特徴とする請求項１から５のいずれか一項に記載の情報処理システム。
【請求項７】
それぞれUnixファイルの内部データを割り当てられている仮想テーブル又は仮想カラムを含む複数のテーブル内のデータを結合することにより、単一のテーブルとしてアクセス要求に応えるテーブル結合手段を有する
ことを特徴とする請求項１から６のいずれか一項に記載の情報処理システム。
【請求項８】
テーブルを格納し請求項１から７のいずれか一項に記載の情報処理システムである計算機を複数、通信ネットワークを介して相互に接続するとともに、
少なくとも一の前記計算機に、自計算機に格納されているテーブルに割り当てられているUnixファイル内部のデータに対して、符号誤りを検出するデータ改変検出コードを周期的に生成して保存するとともに、次回周期において前回のデータ改変検出コードとの比較を行うことによりUnixファイルの更新を検出する、更新検出手段を設け、
前記更新検出手段で前記内部のデータの更新を検出したときは、その検出内容を表す更新情報を他の計算機に通知するとともに、他の計算機から通知された更新情報については、自計算機に格納されているテーブルに割り当てられているUnixファイルに反映させる、データ複製手段を各計算機に設けた
ことを特徴とする情報処理システム。
【請求項９】
Unixファイルと、リレーショナルデータベースと、を有する情報処理システムの制御方法であって、
前記リレーショナルデータベースにおいて、
リレーショナルデータベースのテーブルを構成するカラムであって、カラムとしての実体を持たず他のカラム、他のテーブルのカラムもしくはファイルの実体データを自らのデータとする仮想カラムと、
テーブルの全部又は一部について実体を持たず、前記仮想カラムを列の一部とし、又は他のテーブルもしくはファイルのデータを自らのデータとする、仮想テーブルと、
を実現するとともに、
前記各仮想カラム及び仮想テーブルの少なくとも一方について、他のどのテーブル、カラムもしくはファイルの実体データを割り付けるかを定義する定義情報を所定の定義記憶手段に予め記憶させておき、
前記定義情報に基づいて、前記仮想カラムに他のテーブルのカラムの実体データを割り当て、また、前記Unixファイルを改変せずにファイルオープンしその全体又は一部について、前記仮想テーブル、前記仮想カラム、もしくは仮想カラムのセルの、全体又は一部の実体として割り付けるとともに該当する読書き要求に応じてアクセスすることにより、リレーショナルデータベースの内部にテーブルないしはテーブルの一部として包含するように取り込む、割り当て処理
を実行することを特徴とする情報処理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リレーショナルデータベースとUnix（登録商標）ファイルを統合利用する情報処理の技術に関する。
【背景技術】
【０００２】
長年利用してきた計算機システムを、その老朽化に伴って新しいシステムに更新する場合、旧システムで利用してきたデータベースを新しいシステムのデータベースに移行する必要がある。その際、旧システムのデータベースに蓄積されたデータを抽出（Extract）し、データウェアハウスをはじめとするソフトウェアで、リレーショナルデータベースが利用しやすい形に加工（Transform）し、データベースに書き出す（Load）という一連の処理を実行するが、この一連の処理をＥＴＬ処理と呼ぶ（例えば、非特許文献１参照）。
【０００３】
このようなＥＴＬ処理を実行するには専用のプログラムを必要とするが、そのプログラムは、旧システムと新システムのデータの互換性を維持するために、データ形式の違いやインターフェースの違いなどを吸収する必要があり、それらに関連する要素が、システム開発の工数の大勢を占めることもあるほど、プログラム開発に多大な労力を要していた（例えば、非特許文献２、４参照）。
【０００４】
そのため最近では、ＥＴＬ処理を機械的に実行するＥＴＬツールが広く用いられるようになっている。ＥＴＬツールは、グラフィックユーザインタフェース（ＧＵＩ）を装備してデータベースからデータベースへの流れを判りやすく表示したり、データ形式やカラム型を変換したり、不要データを削除したり形式を統一したりする機能を有している（例えば、非特許文献３参照）。
【０００５】
そのようなＥＴＬツールは、商用データベースに適応したものがほとんどであるが、オープンソースデータベースに対するＥＴＬツールも登場している（例えば、非特許文献４参照）。
【０００６】
Unixファイルをシステムのデータとして利用する旧システムを、リレーショナルデータベースを利用する新システムに移行する場合にも、前記のようなＥＴＬツールにUnixファイルへのアクセス方法を設定してＥＴＬツールを実行することで、リレーショナルデータベース内部にUnixファイルのデータを移行させることができる（例えば、非特許文献３、４参照）。
【０００７】
また、複数のデータベースを透過的に処理して一つの仮想的なデータベースとして扱う機能（データフェデレーション）を有したデータベースでも、データフェデレーション機能をUnixファイルに適用することで、単純な表形式で構成されたUnixファイルであればアクセスすることが可能である（例えば、非特許文献５参照）。
【非特許文献１】分析ポータル作成とETLツールの実践活用法 - @IT、アイティメディア株式会社  江口 陽子／内山 英樹（日本ユニシス株式会社）、  http://www.atmarkit.co.jp/fdb/rensai/sqls_analysis05/sqls_analysis05_01.html
【非特許文献２】Oracleシステム設計、Dave Ensor/Ian Stevenson 著、宮原 徹 監訳 オライリージャパン、ISBN4-900900-46-X
【非特許文献３】インフォマティカ社  インフォマティカ：製品 - PowerExchange、http://www.informatica.jp/products/powerexchange/default.htm
【非特許文献４】オープンソースRDBMSを対象としたオープンソースETLツールの開発、独立行政法人 情報処理推進機構  平井 明夫（株式会社アイエイエフコンサルティング）、http://www.ipa.go.jp/about/jigyoseika/05fy-pro/open/2005-456d.pdf
【非特許文献５】WebSphere Federation Server、IBM社、http://www-06.ibm.com/jp/software/websphere/ii/pdf/fs_rs_dep.pdf
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述したＥＴＬツールにおいては、Unixファイルのデータを抽出して、リレーショナルデータベースに含まれるテーブルの一部に書き出すことは可能である。しかし、旧システムで稼動していたUnixファイル内部のデータを利用しているアプリケーション（以下「レガシーアプリ」と呼ぶ）を、リレーショナルデータベースを使用する新システムで稼動させるためには、レガシーアプリを改変してリレーショナルデータベースを利用するように作り直す必要があった。
【０００９】
特に１９８０年代〜１９９０年代初頭に運用を開始したシステムで利用されているレガシーアプリは、オブジェクト指向手法が確立される以前に作成されたものであり、新システムにおいて再利用が難しいロジック構成となっている場合が多い。また、Unixファイルにアクセスするレガシーアプリは、Unixファイル内部のデータ構造に特化した形で作成されていることが多く、データ構造が変化した場合はレガシーアプリも変更する必要があった。
【００１０】
少なくとも、リレーショナルデータベースを用いる新システムにおいて、Unixファイルについて旧システムと同一の機能を実現するためには、ＥＴＬツールを利用して旧システムのUnixファイルを新システムのリレーショナルデータベース内部に変換・移行してから、もとのUnixファイルにアクセスするレガシーアプリが実現していた機能と同じ機能を実行するアプリケーションを、新システムのリレーショナルデータベースをアクセスできるような形で再度新たに作成する必要があった。
【００１１】
逆に、レガシーアプリをそのまま稼動させることを前提とすると、Unixファイルを使うレガシーアプリと、リレーショナルデータベースを使う新システムのアプリケーションの同期を考慮する必要があるため、ＥＴＬツールを動作させて都度変換してリレーショナルデータベースに格納する機能や、リレーショナルデータベースからUnixファイルへ逆移行するためのツールなどが必要となり、双方に書き換えが発生する場合の同期は困難であるなどの問題があった。
【００１２】
また、上述したデータフェデレーション機能を持つリレーショナルデータベースにおいては、読み込む対象のUnixファイルがカンマ区切りの表形式のような単純な構造となっている必要がある。したがって、レガシーアプリが利用していたようなＣ言語の構造体配列やビットフィールドで構成されたUnixファイルを読み込むためには、専用のUnixファイルアクセス用プログラムを追加投入する必要があり、このような負担の軽減も希求されていた。
【００１３】
本発明は、上記のような従来技術の課題を解決するもので、その目的は、レガシーアプリが利用していたUnixファイルを、新システムのリレーショナルデータベースに仮想テーブルや仮想カラムとして統合することにより、レガシーアプリを改変せずとも新システムで稼動可能とし、アプリケーション作成の工数を低減し生産性を向上させるとともに、旧システムで利用され運用され続けた質の良いアプリケーションを再利用することで、新システムの品質を向上させることである。
【００１４】
また、本発明の他の目的は、レガシーアプリが利用していたUnixファイルがＣ言語の構造体配列やビットフィールドのような複雑な形式となっていても、カラムと行の特定に逆ポーランド記法を利用した計算式を利用して、専用のUnixファイルアクセス用プログラムを作成せずに、Unixファイル内部のデータにリレーショナルデータベースからアクセス可能とすることにより、Unixファイル内部のデータ構造に特化しない形でアプリケーションを作成可能として、生産性の向上に寄与することである。
【課題を解決するための手段】
【００１５】
上記の目的を達成するため、本発明の一態様は、Unixファイルと、リレーショナルデータベースと、を有する情報処理システムであって、前記リレーショナルデータベースは、カラムとしての実体を持たず他のカラム、他のテーブルのカラムもしくはファイルの実体データを自らのデータとする仮想カラムと、テーブルの全部又は一部について実体を持たず、前記仮想カラムを列の一部とし、もしくは他のテーブルもしくはファイルのデータを自らのデータとする、仮想テーブルと、前記各仮想カラム及び仮想テーブルの少なくとも一方について、他のどのテーブル、カラムもしくはファイルの実体データを割り付けるかを定義する定義情報を記憶した定義記憶手段と、前記定義情報に基づいて、前記仮想カラムに他のテーブルのカラムの実体データを割り当て、また、前記Unixファイルを改変せずにファイルオープンしその全体又は一部について、前記仮想テーブル、前記仮想カラム、もしくは仮想カラムのセルの、全体又は一部の実体として割り付けるとともに該当する読書き要求に応じてアクセスすることにより、リレーショナルデータベースの内部にテーブルないしはテーブルの一部として包含するように取り込む、割り当て手段と、を有することを特徴とする。
【００１６】
このように、Unixファイルの内容を、リレーショナルデータベースにおける仮想カラム等に割り付けてアクセスすることにより、レガシーアプリからUnixファイルへの読み書きなどの操作は、対応するリレーショナルデータベースでの仮想カラム等に反映し、逆にそれらリレーショナルデータベースでの仮想カラム等についても、新システムのアプリ（「新アプリ」とも呼ぶこととする）から参照するだけでなく、変更などの操作を行えば対応するUnixファイルへも反映される。このため、割り付けにかかるUnixファイルのデータを新旧両アプリで共有可能となるうえ、レガシーアプリを改変無く利用可能となり、さらに、リレーショナルデータベースからアクセス可能となることで既存のUnixファイルが物理的なデータ構造の制約から脱却できて用途が拡大し、アプリケーションの生産性向上にも寄与できる。
【発明の効果】
【００１７】
以上のように、本発明では、レガシーアプリが利用していたUnixファイルを、新システムのリレーショナルデータベースに仮想テーブルや仮想カラムとして統合することにより、レガシーアプリを改変せずとも新システムで稼動可能とし、アプリケーション作成の工数を低減し生産性を向上させることが可能となる。
【発明を実施するための最良の形態】
【００１８】
以下、リレーショナルデータベースとUnixファイルを統合する本発明を実施するための複数の最良の実施形態について図に沿って説明する。なお、背景技術や課題での説明と共通の前提事項については適宜省略する。
【００１９】
まず、本出願で用いる用語について説明する。
（１）Unixファイル
木構造となっているUnixファイルシステム上のディレクトリに格納されているファイルであり、本出願では、配列や構造体配列やビットフィールドで内部データが構成され、レガシーアプリからアクセスされていたファイルを指す。
（２）レガシーアプリケーション（レガシーアプリ）
１９８０年代〜１９９０年代初頭に作成された、Ｃ言語やfortranで書かれたプログラムであり、オブジェクト指向が確立する以前に作成されているため、再利用が難しい構成やロジックとなっている場合が多い。
（３）仮想カラム
データの実体を持たないカラムであり、データの実体には、他のテーブルのカラムなどのデータやUnixファイルのデータが割り当てられる。
（４）仮想テーブル
テーブルとしての実体を持たず、仮想カラムを内部に持つテーブルである。
（５）ビットフィールド
処理系で定義される単一の記憶単位（全語、３２ビット）の中を複数に分割した、隣接するビットの集合であり、数ビットで表現できる数値をビットフィールドで表現することで、主メモリや共有メモリの容量を節約することができる。
【００２０】
〔１．第１実施形態〕
第１実施形態は、Unixファイルについて、リレーショナルデータベース内部に統合することで、インポートや言語変換を伴わずにUnixファイルをそのまま利用可能とし、仮想カラムを扱う機能によりテーブル内部の列として統合できる基本的な例である。
【００２１】
〔１−１．第１実施形態の構成〕
図１は、リレーショナルデータベースとUnixファイルを統合する、本発明の第１実施形態の構成を示す図である。この図に示すように、第１実施形態は、リレーショナルデータベース１と、Unixファイル（Unixファイル群）２と、アプリケーション（アプリケーション群）３と、を有する情報処理システム（以下「本システム」と呼ぶ）である。
【００２２】
このうち、リレーショナルデータベース１は、通常テーブル１１と、仮想テーブルと、を有する。仮想テーブルは、仮想テーブルでない通常テーブル１１を割り当て先とする第一の仮想テーブル１２と、Unixファイルを割り当て先とする第二の仮想テーブルがある。Unixファイルを割り当て先とする第二の仮想テーブルには、Unixファイル全体を割り当て先とする仮想テーブル１３と、Unixファイルを列の割り当て先とする仮想テーブル１４と、Unixファイルをセルの割り当て先とする仮想テーブル１５と、がある
【００２３】
Unixファイル２には、内部データ全体が行と列を表現しているUnixファイル２５と、内部データが列を表現しているUnixファイル２６と、内部データが行と列の一部のデータを表現しているUnixファイル２７と、がある。
【００２４】
アプリケーション３には、旧システムで稼動していたUnixファイルを利用するアプリケーションすなわちレガシーアプリ１８と、新システムで稼動するリレーショナルデータベース１を利用するアプリケーションすなわち新アプリ１９と、がある。このうち、レガシーアプリ１８は、Unixファイルアクセス処理部１８１を利用してUnixファイル内部の構造化されたデータにアクセスするものである。
【００２５】
他方、新アプリ１９は、リレーショナルデータベース１のテーブルデータ操作処理部２０を利用して、リレーショナルデータベース１内部のテーブルを操作でき、仮想カラム割り当て処理部２１を利用して仮想テーブル内部のデータを操作することができる。
続いて、図１の各部について、より詳細に説明する。
【００２６】
〔１−１−１．データベースの詳細〕
リレーショナルデータベース１は、図２に例示するようなテーブルを複数格納している。テーブルは、行と列からなる表形式データであり、リレーショナルデータベース内に一つ又は複数格納されている。各テーブルには、リレーショナルデータベース内で一意に識別する名称（例えば[TABLE-A] ）が与えられており、これにより個々のテーブルの識別を行なう。これらの名称は、リレーショナルデータベース内部でテーブルを一意に識別できるものであればよく、番号を与えることでも良い。
〔１−１−２．通常のテーブル〕
リレーショナルデータベース１における通常のテーブルは、図２（１）に示すように複数のカラムを格納しているが、各カラムは、テーブルにおける列の役割を果たすもので、テーブル内に一又は二以上格納されている。各カラムには、テーブル内で一意に識別する為の名称（例えば[COL-A] ）が与えられており、これにより個々のカラムの識別を行なう。この名称は、カラムをテーブル内部で一意に識別できるものであればよく、番号を与えることでも良い。
【００２７】
〔１−１−３．仮想テーブル〕
また、リレーショナルデータベース１における仮想テーブルは、図２（２）に示すように、一つ又は複数の仮想カラムを格納している。このような仮想テーブルもテーブルの一種であり、リレーショナルデータベース内に一つ又は複数格納され、一意に識別する名称（例えば[VTABLE-B]）を与えられている。仮想テーブルにも、通常のテーブルと同様にリレーショナルデータベース内部のテーブルとしてアクセスすることが可能であるが、各仮想テーブルには、仮想カラムの割り当て先を記載するカラム属性表が付属する。
【００２８】
このような仮想カラムのデータの割り当て先を例示したものが、図３の概念図である。すなわち、仮想カラムは、通常のカラムとは異なり、テーブル内部に自らのデータを持たない。例えば、仮想テーブル３１に含まれる仮想カラム３２は、同じテーブル内の他のカラム[COL-C] のデータを自らのデータとして割り当て、仮想カラム３３は、自らが所属していないテーブル３６のカラム[VCOL-B]のデータを割り当て、仮想カラム３４は、Unixファイル４２のデータの配列を自らのデータとして割り当て、仮想カラム３５はUnixファイル４３、Unixファイル４４、Unixファイル４５、Unixファイル４６内の所定のデータ値を、自らの各セルのデータとして割り当てる。
【００２９】
また、例えば、仮想テーブル３６に含まれている各仮想カラムには、Unixファイル４１に含まれる各データ値を、行と列として割り当てる。
【００３０】
〔１−１−４．カラム属性表〕
以上のような仮想カラムの割り当て先情報は、仮想テーブルに付属しているカラム属性表（例えば３７）に記載されており、このカラム属性表に従って、仮想カラム割り当て処理部２１が割り当て先のデータを仮想カラムに割り当てる。すなわち、カラム属性表は、各仮想カラムについて他のどのカラムの実体データを割り付けるかを定義する定義情報を記憶した定義記憶手段である。
【００３１】
テーブルが通常のテーブルであるのか、仮想カラムを含む仮想テーブルであるのかを示す情報は、図４に例示するように、カラム属性表に保存する。このようなカラム属性表には、カラム名（例えば「仮想カラム［VCOL-D］」）、カラムの変数型（図４の表に示す「カラム型」）および、仮想カラムの割り当て先のテーブル名（図４の表に示す「割り当て先名称」）、カラム名、およびUnixファイル名（図４の表に示す「割り当て先カラム/ファイル名」）が記載される。
【００３２】
ここで、図１に示したUnixファイル２は、木構造となっているUnixファイルシステム上のディレクトリに格納されているファイルである。第１実施形態では、Unixファイル２は、レガシーアプリ１８から読み・書き・追加・削除されるデータを内部に格納している。このようなUnixファイル２内部にあるデータは、行と列、又は行もしくはデータ単独で構成されており、一種のテーブルのような形態となっている。
【００３３】
そして、レガシーアプリ１８が上記のようなUnixファイル内部のデータにアクセスする際は、Unixファイルアクセス処理部１８１を利用してアクセスし、Ｃ言語の配列などを利用して行と列、または行もしくはデータを指定し、データの操作を実行する。そして、仮想カラムの割り当て先となったUnixファイル２については、Unixファイルをオープンして取り込んだファイルの内容が仮想カラムの実際のデータとなり、仮想カラムに対するデータの読み・書き・追加・削除が、Unixファイル内部の該当データに対しても行われる。
【００３４】
旧システムで稼動していた、Unixファイルを利用するレガシーアプリ１８は、データを内部に持つUnixファイルへアクセスするUnixファイルアクセス処理部１８１を有しており、Unixファイルアクセス処理部１８１により、Unixファイル内部のデータの読み・書き・追加・削除を実施する。このUnixファイルアクセス処理部１８１は、ＯＳ（オペレーティングシステム）に代表される基本ソフトなどの備えるファイルアクセス機能を利用して実装する例も考えられる。
【００３５】
リレーショナルデータベース１にアクセスする新アプリ１９は、リレーショナルデータベースへアクセスするデータベースアクセス処理部１９１を有している。このデータベースアクセス処理部１９１は、リレーショナルデータベースのテーブルデータ操作処理部２０を使用してリレーショナルデータベースに格納されているテーブルの操作を実施し、仮想カラム割り当て処理部２１を使用して仮想テーブルのデータに対して読み・書き・追加・削除を実行できる。
【００３６】
〔１−２．第１実施形態の作用〕
上記のように構成された第１実施形態は、以下のように作用する。まず、概要としては、仮想カラム割り当て処理部２１が、属性表に基づいて、仮想カラムに他のカラムの実体データを割り当て、また、Unixファイルを改変せずにファイルオープンしその全体又は一部について、仮想テーブル、仮想カラム、もしくは仮想カラムのセルの、全体又は一部の実体として割り付けるとともに、該当する読書き要求に応じてアクセスすることにより、リレーショナルデータベースの内部にテーブルないしはテーブルの一部として包含するように取り込む。
より具体的には、以下のような処理となる。
【００３７】
〔１−２−１．新アプリ１９からの操作〕
まず、図５は、テーブルデータ操作処理部２０にて、Unixファイル２を割当先とした仮想カラムを持つ仮想テーブルに対して、その仮想カラム内部のデータを、新システムで稼動する新アプリ１９から操作する際のフローチャートである。
【００３８】
この処理手順では、まず、新アプリ１９よりテーブルデータの操作要求を受けると、テーブルに仮想カラムが含まれているか否かカラム属性表より判断する（Ｓ１０１）。仮想カラムが含まれている場合（Ｓ１０１）、仮想カラムの割り当て先がUnixファイルであるか否かをカラム属性表より判断する（Ｓ１０２）。
【００３９】
仮想カラムの割り当て先がUnixファイルの場合は（Ｓ１０２）、そのUnixファイルがオープン済みか否かを判断する（Ｓ１０３）。そのUnixファイルが未オープンの場合は（Ｓ１０３）、カラム属性表よりそのUnixファイルのファイル名を取得し、Unixファイルをオープンする（Ｓ１０４）。この際、オープンの方法は、ファイルディスクリプタを利用する方法や、メモリにファイルを割り当てるファイルマッピングのいずれでも良い。Unixファイルをオープンしたら、Unixファイルの仮想テーブルへの割り当て方を判断する（Ｓ１０５、Ｓ１０６）。
【００４０】
すなわち、Unixファイルが、仮想テーブル全体に割り当てられている場合は（Ｓ１０５）、アプリケーションより渡された行と列に該当するUnixファイル内部のデータを特定する（Ｓ１０７）。典型的には、仮想テーブルを構成するカラムの変数型のサイズを列挙して１行分のカラムサイズとすることにより、Unixファイル内部の行と列を特定する。このように特定に利用した行と列は、レガシーアプリ１８でUnixファイルアクセス時に利用する行及び列と同じサイズとなっている。以上のように特定したデータに対して、アプリケーションより要求された操作を実行する（Ｓ１１０）。
【００４１】
また、Unixファイルが仮想カラムの１つすなわち１列に割り当てられている場合は（Ｓ１０６）、アプリケーションより指定された行に該当するUnixファイル内部のデータを特定する（Ｓ１０８）。仮想テーブルを構成するカラムの変数型の配列をUnixファイル内部のデータ全体に適用することでデータを特定する。特定したデータのサイズは、レガシーアプリ１８でUnixファイルアクセス時に利用した変数とサイズとなっている。そして、このように特定したデータに対して、アプリケーションより要求された操作を実行する（Ｓ１１０）。
【００４２】
Unixファイルが仮想カラムの１つのセルに割り当てられている場合は、Unixファイル内部データ全体をデータとして特定する（Ｓ１０９）。特定したデータは、レガシーアプリ１８でUnixファイルアクセス時に利用するデータと同一となっている。そして、このように特定したデータに対して、アプリケーションより要求された操作を実行する（Ｓ１１０）。
【００４３】
〔１−２−２．レガシーアプリ１８からの操作〕
次に、図６は、レガシーアプリ１８からUnixファイルを操作するフローチャートである。この処理手順では、Unixファイルがオープン済みか否かを調べ（Ｓ１２１）、未オープンの場合は（Ｓ１２１）Unixファイルをオープンし（Ｓ１２２）、Unixファイル内部で行と列に該当する箇所のデータを特定して（Ｓ１２３）、データに対する操作を実施する（Ｓ１２４）。
【００４４】
特定に利用した行と列は、前述した新アプリ１９で仮想テーブルにアクセスした時に利用する行と列と同じサイズとなっており、レガシーアプリ１８で指定した行と列が指すデータと、新アプリ１９で指定した行と列が指すデータは同一となる。なおこの処理は、旧システムで稼動していた時点の処理から改変せず利用できる。
【００４５】
〔１−３．第１実施形態の効果〕
以上のような第１実施形態によれば、レガシーアプリ１８にてUnixファイルに対して読み・書き・追加・削除の操作を実施すると、Unixファイルを割り当て先とする仮想カラムの内容も操作されるので、リレーショナルデータベース内部の仮想テーブルのデータが変更され、リレーショナルデータベースにアクセスするアプリケーションからも変更内容を参照できる。そして、リレーショナルデータベースにアクセスする新アプリ１９がUnixファイルを割り当て先とする仮想カラムのデータに対して読み・書き・追加・削除の操作を実施すると、Unixファイルの内容も操作されるので、変更した内容をレガシーアプリ１８でも参照できる。
【００４６】
以上のように、レガシーアプリ１８と新アプリ１９でUnixファイルのデータを共有することができることにより、レガシーアプリ１８を改変無く利用可能となり、また、Unixファイルのデータについては、リレーショナルデータベースからアクセス可能となり物理的なデータ構造から脱却できるため、アプリケーションの生産性向上に寄与できる。
【００４７】
すなわち、リレーショナルデータベースにアクセスする新システム用のアプリケーションからも、Unixファイル内部のデータにアクセスすることができるため、新システムのアプリケーションとレガシーアプリケーションとの間でのデータを共有することができ、システムの拡張も行うことができる。
【００４８】
〔２．第２実施形態〕
第２実施形態は、仮想カラムの割り当て方法として、逆ポーランドによる割り当て、動的カラムを扱うもので、図１、図３、図７〜図９を用いて説明するが、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００４９】
第２実施形態の概要としては、定義情報は、仮想カラムに割り当てる実体データの所在を示すアドレスデータを逆ポーランド記法で記載した計算式を有し、仮想カラム割り当て処理部２１は、そのような定義情報の計算式に基づいて、該当するアドレスデータの実体データを、仮想カラムとしての表現形式に変換することによりテーブルの行と列として割り当てる。
【００５０】
〔２−１．第２実施形態の構成〕
第２実施形態の構成は、第１実施形態（図１、図３）に準じるが、第１実施形態との相違点として、カラム属性表３７、３８（図３）において、仮想カラムにデータを割り当てるために逆ポーランド記法で表現された計算式を記載している。
【００５１】
すなわち、図７は、第２実施形態でのカラム属性表を例示するもので、第１実施形態とは異なり、逆ポーランド記法で表現された計算式を記載している。このような第２実施形態では、行番号に対して計算式に記載された逆ポーランド記法の四則演算を実施し、割り当て元のデータの相対アドレスを求め、仮想カラムの各行に該当する相対アドレスを割り当て元のデータに適用して、仮想カラムのデータを取得する。
【００５２】
〔２−２．第２実施形態の作用〕
上記のように構成された第２実施形態において、図８は、仮想カラムを持つ仮想テーブルに対して、逆ポーランド記法で記載された演算を利用してデータを仮想カラムに割り当てる際のフローチャートである。
【００５３】
すなわち、まず、カラム属性表から計算式を取得し（Ｓ１３１）、その計算式が逆ポーランド記法で記載されていない場合は（ステップＳ１３２）、逆ポーランド記法に変換する（Ｓ１３３）。そして、逆ポーランド記法を用いて行数から相対アドレスを計算し（Ｓ１３４）、得られた相対アドレスを元のデータに割り当てて、仮想カラムのデータとする（Ｓ１３５）。
【００５４】
具体例として、図９に示すように、Ｃ言語の構造体配列で記載され１配列が１レコードに当たるようなデータ６１に対し、構造体配列の構造体のメンバ毎に仮想カラムを割り当てる計算式を、例えばカラム属性表６２に設定することにより、構造体配列で記載されていたデータを仮想テーブル６３のデータとすることができる。
【００５５】
〔２−３．第２実施形態の効果〕
以上のように、第２実施形態によれば、Ｃ言語の構造体配列で記載され１配列が１レコードに当たるようなデータに対しても、構造体配列の構造体のメンバ毎に仮想カラムを割り当てる計算式をカラム属性表に設定することにより、構造体配列で記載されていたデータを仮想テーブルのデータとすることができる。このため、Ｃ言語の構造体配列でのみアクセス可能であったUnixファイル内部の構造体配列データも、リレーショナルデータベース内部のテーブルの一つとして参照することが可能となり、余分な工数無しで旧システム時代のデータも活用容易になる。
【００５６】
〔３．第３実施形態〕
次に、本発明に係る第３実施形態は、仮想カラムの割り当て方法として、静的カラムを採用するもので、図１、図３、図１０〜図１２を用いて説明する。なお、第１実施形態、第２実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００５７】
第３実施形態の概要としては、仮想カラム割り当て処理部２１が、第２実施形態に示したような逆ポーランド記法を用いた計算式を用いて、実体データの所在を示すアドレスデータを予め計算しその計算結果をテーブルのセル単位に記憶保持しておき、仮想カラムへの割り当ての際に、前記のように記憶保持している計算結果を読み出して利用する。
【００５８】
〔３−１．第３実施形態の構成〕
第３実施形態の構成は、第２実施形態（図１、図３）に準じるが、第２実施形態との相違点として、仮想テーブルのカラム属性表もしくは仮想テーブルに、各行毎に計算式を用いて計算した割り当て元データの相対アドレスを保存しておく項目を追加する。
【００５９】
このように、相対アドレスの保存先をカラム属性表とした場合のカラム属性表を図１０に示す。この図１０は、第２実施形態の図９の仮想テーブル６３を、第３実施形態に適用した場合の仮想テーブルのカラム属性表である。計算結果を保存しておく項目は「相対アドレス」と題するフィールドで、各行毎に計算した相対アドレスを保存する。
【００６０】
一方、相対アドレスの保存先を仮想テーブル内部とした場合の仮想テーブルを図１１に例示する。この場合は、仮想カラムに対応する相対アドレスの保存カラムを設定し、仮想カラムの割り当て先データを取得する際に利用する。
【００６１】
〔３−２．第３実施形態の作用〕
上記のように構成された第３実施形態において、仮想カラムを持つ仮想テーブルに対して、カラム属性表ないしは仮想テーブル内部に記載された相対アドレスを利用してデータを仮想カラムに割り当てる際の処理手順を、図１２のフローチャートに示す。すなわち、カラム属性表ないしは仮想テーブル内部からデータを取得する行の相対アドレスを取得したうえ（Ｓ１５１）、割り当て先のデータからその相対アドレスを使って仮想カラムに割り当てる（Ｓ１５２）。
【００６２】
〔３−３．第３実施形態の効果〕
このような第３実施形態によれば、第２実施形態と比較して、相対アドレスを保存する記憶容量は要するが、相対アドレスをあらかじめ計算してカラム属性表や仮想テーブルに保存しておくことで、相対アドレスの計算にその都度時間を費やすオーバーヘッドが削減でき、リレーショナルデータベースを利用するアプリケーションから仮想テーブルにアクセスする際の速度を向上させることができる。
【００６３】
〔４．第４実施形態〕
次に、本発明に係る第４実施形態は、仮想カラムの割り当て方法として、ビットフィールドを用いるもので、図１、図３、図１３〜図１５を用いて説明する。なお、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００６４】
第４実施形態の概要としては、定義情報は、仮想カラムに割り当てる実体データについて、ビット単位に構成された各フィールドごとに、テーブルの行と列にどのように割り当てるかを表し、仮想カラム割り当て処理部２１は、そのような定義情報に基づいて、該当する実体データをビット単位のフィールドごとに区分したうえ、該当するテーブルの行と列に割り当てる。
【００６５】
〔４−１．第４実施形態の構成〕
このような第４実施形態の構成は、第２実施形態（図１、図３）に準じるが、第２実施形態との相違点として、割り当て元のデータが図１３に示すようなＣ言語のビットフィールドを含む構造体で構成されており、ビットフィールドを構成しているビット一つ一つを仮想カラムに割り当てていることである。
【００６６】
そして、第４実施形態におけるカラム属性表を図１４に例示する。すなわち、第２実施形態とは異なり、カラム属性表にビット位置とビットサイズの項目が追加されている。このような第４実施形態では、計算式に記載された四則演算を実施して求めた相対アドレスのデータに対して、カラム属性表に記載されたビット位置とビットサイズのビットを仮想カラムの割り当て先データとする。
【００６７】
〔４−２．第４実施形態の作用〕
上記のように構成された第４実施形態において、ビットフィールドで構成されたデータを仮想カラムの割り当て元とした場合について、データを仮想カラムに割り当てる際の処理手順を、図１５のフローチャートに示す。
【００６８】
すなわち、まず、カラム属性表から計算式を取得し（Ｓ１６１）、その計算式が逆ポーランド記法で記載されていない場合は（ステップＳ１６２）、逆ポーランド記法に変換する（Ｓ１６３）。そして、逆ポーランド記法を用いて行数から相対アドレスを計算し（Ｓ１６４）、続いて、カラム属性表からビット位置とビットサイズを取得し（Ｓ１６５）、これらの計算により求めた相対アドレスに存在するデータのビット位置・ビットサイズのデータを取得して、仮想カラムのデータとする（Ｓ１６６）。
【００６９】
〔４−３．第４実施形態の効果〕
このような第４実施形態によれば、ビットフィールドで構成されたデータに対して、各ビット毎に仮想カラムを割り当てることで、ビットフィールドを構成していたデータを仮想テーブルのデータとすることができる。これにより、例えばＣ言語のビットフィールドのみでアクセス可能であったUnixファイル内部のビットフィールドデータも、リレーショナルデータベース内部のテーブルの一つとして参照でき、無駄な工数無しで旧システム時代からのデータ資源の活用も容易になる。
【００７０】
〔５．第５実施形態〕
次に、本発明に係る第５実施形態は、仮想カラムの割り当て方法を、任意ビット長としたもので、図１、図３、図１６、図１７を用いて説明する。なお、第２実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００７１】
この第５実施形態の概要としては、前記定義情報は、任意のビット長で構成された配列を利用した実体データを、テーブルの行と列にどのように割り当てるかを表し、仮想カラム割り当て処理部２１は、前記定義情報に基づいて、実体データに対応するビット長の配列又はその各要素を、テーブルの行と列に割り当てる。
【００７２】
〔５−１．第５実施形態の構成〕
この第５実施形態の構成は、第２実施形態（図１、図３）に準じるが、第２実施形態との相違点として、割り当て元のデータが複数の任意長のビットで構成され、任意長のビットデータを仮想カラムに割り当てていることと、逆ポーランド記法で表現された計算式が相対アドレスではなく割り当て先データの相対ビット位置を、結果として返すことである。
【００７３】
ここで、図１６は、第５実施形態でのカラム属性表である。すなわち、第２実施形態とは違い、カラム属性表にビットサイズの項目が設けられている。また、第５実施形態では、逆ポーランド式表記の計算式が返す結果はビット位置であり、記載された四則演算を実施して求めた相対ビット位置に存在するビットサイズ分のデータを仮想カラムの割り当て先データとする。
【００７４】
〔５−２．第５実施形態の作用〕
上記のように構成された第５実施形態において、任意ビット長で構成されたデータを仮想カラムの割り当て元とした場合について、データを仮想カラムに割り当てる際の処理手順を、図１７のフローチャートに示す。
【００７５】
すなわち、まず、カラム属性表から計算式を取得し（Ｓ１７１）、計算式が逆ポーランド記法で記載されているかどうかを判断し（Ｓ１７２）、逆ポーランド記法で記載されていない場合は逆ポーランド記法に変換する（Ｓ１７３）。そして、逆ポーランド記法を用いて行数から相対ビット位置を計算し（Ｓ１７４）、カラム属性表からビットサイズを取得し、計算により求めた相対ビットに存在するビットサイズ分のデータを取得して、仮想カラムのデータとする（Ｓ１７５）。
【００７６】
〔５−３．第５実施形態の効果〕
このような第５実施形態によれば、任意ビット長で構成されたデータに対して、各ビット毎に仮想カラムを割り当てることで、任意ビット長で構成されるデータについても仮想テーブルのデータとすることができ、Ｃ言語のみでアクセス可能であったUnixファイル内部の任意ビット長のデータを、リレーショナルデータベース内部のテーブルの一つとして参照可能となる。このため、無駄な工数無しで旧システム時代からのデータ資源の活用も容易になる。
【００７７】
〔６．第６実施形態〕
次に、本発明の第６実施形態は、メッセージダイジェストや巡回冗長検出を利用した更新検出機能を備えたもので、図１８〜図２０を用いて説明する。なお、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００７８】
第６実施形態の概要は、リレーショナルデータベースにおいて、Unixファイル内部のデータに対して、符号誤りを検出するデータ改変検出コードを周期的に生成して保存するとともに、次回周期において前回のデータ改変検出コードとの比較を行うことによりUnixファイルの更新を検出する、更新検出手段を設けたことである。
【００７９】
〔６−１．第６実施形態の構成〕
そして、第６実施形態の構成は、第１実施形態の構成（図１）に、第６実施形態の特徴となる構成を追加した、図１８に示すとおりで、第１実施形態との相違点は、上記の更新検出手段であるUnixファイル更新検出処理部７１を追加した点である。
【００８０】
このUnixファイル更新検出処理部７１は、定期的に仮想テーブルの割り当て先のUnixファイル２をオープンし、仮想カラムの割り当て先となるUnixファイル内部のデータに対してデータ改変検出コードを作成し保存する機能を備えている。
【００８１】
そして、データ改変検出コードとして、インターネットにてセキュリティを付加したファイル流通に利用されているメッセージダイジェストや、巡回冗長検出による符号誤りコードなどを、適宜選択利用可能である。また、Unixファイル更新検出処理部７１は、前回保存したコードと値が変わっているようであれば、データが更新されたと判断してリレーショナルデータベース１とリレーショナルデータベースを利用する新アプリ１９に、データの更新を通知する機能を備えている。
【００８２】
ここで、第６実施形態でのカラム属性表は、図１９に例示するようなものであり、この例では、第１実施形態とは異なり、データ改変検出コード（データ改変コード）のフィールドが含まれている。そして、第６実施形態では、Unixファイル更新検出処理部７１が、定期的にデータ改変検出コードを、上記のようなカラム属性表に保存する。
【００８３】
〔６−２．第６実施形態の作用〕
上記のように構成された第６実施形態において、Unixファイル更新検出処理部７１がUnixファイル２のデータ改変検出コードを生成し更新を検出する際のフローチャートを図２０に示す。
【００８４】
すなわち、Unixファイル更新検出処理部７１がデータ更新検出の周期に達すると（Ｓ１８１）、カラム属性表から仮想カラムを有した仮想テーブルを検索する（Ｓ１８２）。仮想テーブルが見つかると仮想テーブルの割り当て先を判断し（Ｓ１８３）、その割り当て先がUnixファイルであれば（Ｓ１８３）、そのUnixファイルがオープン済か否かを調べ（Ｓ１８４）、Unixファイルが未オープンであれば（Ｓ１８４）オープンする（Ｓ１８５）。
【００８５】
そして、オープンしたUnixファイル内部のデータから、メッセージダイジェストや巡回冗長検出を利用して誤り符号検出コードを生成し、データ改変検出コードとする（Ｓ１８６）。また、カラム属性表から前回のデータ改変検出コードを取得し（Ｓ１８７）、今回生成したデータ改変検出コードと比較する（Ｓ１８８）。その結果、もし前回と今回でデータ改変検出コードの値が変わっていたら（Ｓ１８８）、更新を検出したデータをリレーショナルデータベース１と、リレーショナルデータベースを利用する新アプリ１９に通知する（Ｓ１８９）。そして、このような更新を通知した場合でもしなかった場合でも、今回生成したデータ改変コードは、カラム属性表に上書き保存する（Ｓ１９０）。
【００８６】
〔６−３．第６実施形態の効果〕
このような第６実施形態によれば、レガシーアプリ１８がUnixファイルを更新してデータに変化があった場合に、Unixファイル更新検出処理部７１がデータ改変検出コードから変化を検出することにより、Unixファイル内部でのデータ変更内容を新アプリ１９やリレーショナルデータベースに通知することができる。このため、旧アプリと新アプリの連携などシステムの構成や応用の自由度が向上する。
【００８７】
〔７．第７実施形態〕
次に、本発明に係る第７実施形態は、テーブルの結合（Ｊｏｉｎ）を可能とするもので、図２１〜図２３を用いて説明する。なお、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００８８】
第７実施形態の概要は、それぞれUnixファイルの内部データを割り当てられている仮想テーブル又は仮想カラムを含む複数のテーブル内のデータを結合することにより、単一のテーブルとしてアクセス要求に応えるテーブル結合手段を設けた点にある。
【００８９】
〔７−１．第７実施形態の構成〕
この第７実施形態の構成は、第１実施形態（図１）の構成に、第７実施形態での特徴的な構成を付け加えた図２１に示すとおりで、第１実施形態との相違点として、複数のテーブルのカラム同士を結合する前記テーブル結合手段であるテーブル結合処理部８１が加えられている。
【００９０】
このテーブル結合処理部８１は、ビュー設定データ８２から設定項目を取得して、複数のテーブルの任意のデータ同士を選択して結合し、表の形式（以下「ビュー」と呼ぶ）で表して新アプリ１９に返す機能を有している。
【００９１】
ここで、ビューの構成を図２２に示す。すなわち、ビューは、テーブルと同様に行と列で構成されているが、仮想カラムと同様にデータそのものを含んでおらず、ビューのデータとして選択できるデータは通常のテーブル及び仮想テーブル及び他のビューである。また、ビューのデータとして、Unixファイルを割り当て先とする仮想カラムも選択できる。このようなビューを用いることにより、複数のテーブルの内容を一つの表で表すことができる。
【００９２】
〔７−２．第７実施形態の作用〕
上記のように構成された第７実施形態において、テーブル結合処理部８１が複数のテーブルを結合しビューを作成する際のフローチャートを図２３に示す。すなわち、新アプリ１９からビューの作成を要求されると、テーブル結合処理部８１はビュー設定データ８２からビューの設定内容を取得する（Ｓ１９１）。そして、ビューの対象となるデータが通常テーブルのデータである場合は（Ｓ１９２）、第１実施形態で述べたテーブルデータ取得処理部２０にテーブルデータ操作処理（図５）を行わせるが（Ｓ１９３）、この際、テーブルがUnixファイルを割り当て先とする仮想テーブルの場合は、第１実施形態と同様に仮想テーブル割り当てを実施する（図５）。
【００９３】
そして、ビューの対象となるデータが、さらにビューの場合は（Ｓ１９２）、テーブル結合処理を再帰的に実施する（Ｓ１９４）。以上のように取得できたデータを表形式に編集して（Ｓ１９５）、ビューの作成を要求したアプリケーションにビューを返却する（Ｓ１９６）。
【００９４】
〔７−３．第７実施形態の効果〕
このような第７実施形態によれば、割り当て先をUnixファイルとする仮想テーブルを複数組み合わせたビューを利用することで、リレーショナルデータベースを利用する新アプリ１９からは複数のUnixファイルを横断する形でデータを参照することができる。特に、複数のUnixファイルを仮想テーブルとして割り当ててビューを作成することで、旧システムで利用していたデータを集約して表示することができる。すなわち、レガシーアプリ１８では複数のUnixファイル内部データの集約内容をプログラムロジックで実現したが、上記のようなビューを利用することで、アプリケーション作成・改変の工数を減らし、生産性を一層向上させることが可能となる。
【００９５】
〔８．第８実施形態〕
次に、本発明に係る第８実施形態は、データ等価・レプリケーションの処理を加えたもので、図２４〜図２６を用いて説明する。なお、第１実施形態と同一の構成には同一の符号を付し、重複する説明は省略する。
【００９６】
第８実施形態の概要としては、テーブルを格納した情報処理システムである計算機を複数、通信ネットワークを介して相互に接続するとともに、少なくとも一の計算機に、自計算機に格納されているテーブルに割り当てられているUnixファイル内部のデータに対して、符号誤りを検出するデータ改変検出コードを周期的に生成して保存するとともに、次回周期において前回のデータ改変検出コードとの比較を行うことによりUnixファイルの更新を検出する、更新検出手段を設ける。また、各計算機に、前記更新検出手段で前記内部のデータの更新を検出したときは、その検出内容を表す更新情報を他の計算機に通知するとともに、他の計算機から通知された更新情報については、自計算機に格納されているテーブルに割り当てられているUnixファイルに反映させる、データ複製手段を設ける。
【００９７】
〔８−１．第８実施形態の構成〕
この第８実施形態の構成は、第１実施形態の構成（図１）に、第６実施形態に示したUnixファイル更新検出処理部７１と、第８実施形態に固有の単構成を加えたもので、図２４に示す通りである。すなわち、第１実施形態との相違点として、計算機Ａ（９１）と計算機Ｂ（９２）それぞれに、リレーショナルデータベース１と、Unixファイル２と、アプリケーション３と、セットが配置されており、計算機Ａと計算機Ｂはネットワーク９３で接続されており、各計算機Ａ９１とＢ９２の各リレーショナルデータベース１に、データ複製処理部９４、データ複製処理部９５が追加されている。
【００９８】
また、計算機Ａのリレーショナルデータベース１は、上記更新手段として、第６実施形態で示したものに準じたUnixファイル更新検出処理部７１を有し、計算機Ａのリレーショナルデータベースにて更新されたデータはネットワークを経由して計算機Ｂのリレーショナルデータベースに伝達される。
【００９９】
すなわち、計算機Ａのデータ複製処理部９４は、テーブルデータ操作処理部２２からテーブル更新内容を受け取り、ＬＡＮなどの通信ネットワーク９３を通じて計算機Ｂのデータ複製処理部９５に伝達する。計算機Ｂのデータ複製処理部９５は、ネットワーク９３を経由して計算機Ａのデータ複製処理部９４から受け取ったテーブル更新内容を、テーブルデータ操作処理部２２に伝えてテーブルの内容を更新する。
【０１００】
また、計算機Ａで更新した対象がUnixファイルである場合も、Unixファイル更新検出処理部７１が更新を検出し仮想テーブルの更新内容を計算機Ａのデータ複製処理部９４に伝達し、計算機Ａのデータ複製処理部９４はネットワーク９３を通じて計算機Ｂのデータ複製処理部９５に伝達する。計算機Ｂのデータ複製処理部９５は、受け取った仮想テーブル更新内容をテーブルデータ操作処理部２２に伝えてUnixファイルの内容を更新する。
【０１０１】
〔８−２．第８実施形態の作用〕
続いて、第８実施形態における処理手順のうち、図２５は、テーブルの更新内容を他の計算機に伝える計算機Ａのデータ複製処理のフローチャートである。すなわち、テーブルデータの内容が更新された時、計算機Ａのデータ複製処理部９４は更新データをテーブルデータ操作処理部２２から渡される（Ｓ２０１）。同様に仮想テーブルの割り当て元となっているUnixファイルの内容が更新された時には、計算機Ａのデータ複製処理部９４は、更新データをテーブルデータ操作処理から渡される（Ｓ２０１）。
【０１０２】
いずれの場合も、計算機Ａのデータ複製処理部９４は、通信ネットワーク９３を経由して計算機Ｂのデータ複製処理部９５に接続し（Ｓ２０２）、この接続が受諾されると、計算機Ｂのデータ複製処理部９５に更新データを送信する（Ｓ２０３）。
【０１０３】
また、図２６は、以上のようなテーブルの更新データを受け取った際の計算機Ｂにおけるデータ複製処理のフローチャートである。すなわち、計算機Ｂのデータ複製処理部９５は、通信ネットワーク９３を経由して計算機Ａのデータ複製処理部９４から接続要求が来たら、その接続を受諾し（Ｓ２０４）、続いて、計算機Ａのデータ複製処理部９４から更新データが送信されてきたら、その更新データを受信する（Ｓ２０５）。
【０１０４】
そして、このように受信した更新データをテーブルデータ操作処理部２２に渡し、テーブルのデータを更新する（Ｓ２０６）。この際、仮想テーブルの割り当て先がUnixファイルの場合は、テーブルデータ操作処理部２２は、UnixファイルをオープンしてUnixファイルを更新することになる。
【０１０５】
〔８−３．第８実施形態の効果〕
このように、第８実施形態によれば、仮想テーブルの割り当て先にUnixファイルを指定したリレーショナルデータベースを複数の計算機に配置することにより、Unixファイル内部の更新を検出して更新した内容を他の計算機に送信し、受信した計算機のリレーショナルデータベースで仮想テーブルを更新することで、Unixファイルの内容を計算機間で複製することができる。
【０１０６】
すなわち、レガシーアプリ１８が稼動していた旧システムでは、ディスクやメモリを計算機と計算機との間で共有する機能を有していたものがある場合でも、第８実施形態を適用すれば、旧システムで稼動していた共有のメモリや共有のディスクを模擬することができ、レガシーアプリ１８の改変が不要となるので、改変のための工数を大幅に削減可能となる。
【０１０７】
〔９．他の実施形態〕
なお、本発明は、上記実施形態に限定されるものではなく、以下に例示するもの及びそれ以外の他の実施形態も含むものである。例えば、各図に示した構成、処理手順のフローチャート、データ構造などは例示に過ぎないので、適宜変更実施することが可能であり、そのように変更した例についても本発明の範囲に属するものである。
【０１０８】
例えば、第８実施形態（図２４）では、計算機Ａのレガシーアプリ１８によるUnixファイルへの変更をUnixファイル更新検出処理部７１で検出し、計算機Ｂへ反映させる例を示したが、Unixファイル更新検出処理部を計算機Ｂに設けることにより、逆に、計算機Ｂのレガシーアプリ１８によるUnixファイルへの変更を計算機Ａへ反映させることも可能である。
【図面の簡単な説明】
【０１０９】
【図１】本発明の第１実施形態の構成を示す図。
【図２】本発明の第１実施形態において、テーブルデータのデータ構造の一例を示す図。
【図３】本発明の第１実施形態において、仮想テーブルと割り当て先の関係と構造の一例を示す図。
【図４】本発明の第１実施形態において、カラム属性表のデータ構造の一例を示す図。
【図５】本発明の第１実施形態において、テーブルデータ操作処理手順の概要を示すフローチャート。
【図６】本発明の第１実施形態において、Unixファイルデータ操作処理手順の概要を示すフローチャート。
【図７】本発明の第２実施形態において、計算式の項目を付加したカラム属性表のデータ構造の一例を示す図。
【図８】本発明の第２実施形態において、計算式を使用した仮想カラム割当て処理手順の概要を示すフローチャート。
【図９】本発明の第２実施形態において、Ｃ言語構造体配列のデータから仮想テーブルに割り当てる一例を示す図。
【図１０】本発明の第３実施形態において、割り当て先の相対アドレス項目を追加したカラム属性表のデータ構造の一例を示す図。
【図１１】本発明の第３実施形態において、割り当て先の相対アドレス項目を追加した仮想テーブルのデータ構造の一例を示す図。
【図１２】本発明の第３実施形態において、カラム属性表に保存した相対アドレスを使用する仮想カラム割り当て処理手順の概要を示すフローチャート。
【図１３】本発明の第４実施形態において、ビットフィールドを含むＣ言語の構造体の一例を示す図。
【図１４】本発明の第４実施形態において、ビットフィールドを含む構造体を割り当て先としたカラム属性表のデータ構造の一例を示す図。
【図１５】本発明の第４実施形態において、ビットフィールドを含む構造体を割り当て先とした仮想カラム割り当て処理手順の概要を示すフローチャート。
【図１６】本発明の第５実施形態において、任意ビット長データを含む構造体を割り当て先としたカラム属性表のデータ構造の一例を示す図。
【図１７】本発明の第５実施形態において、任意ビット長データ含む構造体を割り当て先とした仮想カラム割り当て処理手順の概要を示すフローチャート。
【図１８】本発明の第６実施形態において、Unixファイル更新検出処理を追加したリレーショナルデータベースとUnixファイルの統合手法を示す構成図。
【図１９】本発明の第６実施形態において、Unixファイルのデータ改変コードを付加したカラム属性表のデータ構造の一例を示す図。
【図２０】本発明の第６実施形態において、Unixファイル更新検出処理手順の概要を示すフローチャート。
【図２１】本発明の第７実施形態において、テーブル結合処理を追加したリレーショナルデータベースとUnixファイルの統合手法を示す構成図。
【図２２】本発明の第７実施形態において、テーブル結合の一例を示す図。
【図２３】本発明の第７実施形態において、テーブル結合処理手順の概要を示すフローチャート。
【図２４】本発明の第８実施形態において、データ複製処理を装備したリレーショナルデータベースとUnixファイルの統合手法を示す構成図。
【図２５】本発明の第８実施形態において、データ送信側のデータ複製処理手順の概要を示すフローチャート。
【図２６】本発明の第８実施形態において、データ受信側のデータ複製処理手順の概要を示すフローチャート。
【符号の説明】
【０１１０】
１…リレーショナルデータベース
２…Unixファイル
３…アプリケーション
１１…通常テーブル
１２…仮想テーブル
１８…レガシーアプリケーション（レガシーアプリ）
１９…新システムのアプリケーション（新アプリ）
２０…テーブルデータ操作処理部
２１…仮想カラム割り当て処理部
７１…Unixファイル更新検出処理部
８１…テーブル結合処理部
９４，９５…データ複製処理部
【図１】
2009223512.tif 000003
【図２】
2009223512.tif 000004
【図３】
2009223512.tif 000005
【図４】
2009223512.tif 000006
【図５】
2009223512.tif 000007
【図６】
2009223512.tif 000008
【図７】
2009223512.tif 000009
【図８】
2009223512.tif 000010
【図９】
2009223512.tif 000011
【図１０】
2009223512.tif 000012
【図１１】
2009223512.tif 000013
【図１２】
2009223512.tif 000014
【図１３】
2009223512.tif 000015
【図１４】
2009223512.tif 000016
【図１５】
2009223512.tif 000017
【図１６】
2009223512.tif 000018
【図１７】
2009223512.tif 000019
【図１８】
2009223512.tif 000020
【図１９】
2009223512.tif 000021
【図２０】
2009223512.tif 000022
【図２１】
2009223512.tif 000023
【図２２】
2009223512.tif 000024
【図２３】
2009223512.tif 000025
【図２４】
2009223512.tif 000026
【図２５】
2009223512.tif 000027
【図２６】
2009223512.tif 000028