(57)【要約】【課題】異種システム間、異種パッケージソフト間及び異種インフラ間でのデータ交換・データ変換を汎用的に行えるようにしたデータ管理システムの提供【解決手段】データ管理システムは、異なるシステムのデータ項目のプロファイルをそれぞれ定義するシステム用項目定義情報と、管理対象の全てのシステムの項目定義情報を網羅する標準プロファイル用項目定義情報と、前記システム用項目定義情報と前記標準プロファイル用項目定義情報との対応関係を定義する項目関連定義情報とを格納し、前記システム用項目定義情報、前記標準プロファイル用項目定義情報及び前記項目関連定義情報を利用して、異なる２つのシステムのうちの一方のシステムのプロファイルにしたがったエクスポートデータのデータ項目を、他方のシステムのプロファイルにしたがったデータ項目に自動的に変換する。【選択図】図８５
2008243193.tif 000002
【特許請求の範囲】
【請求項１】
異なるシステムのデータフォーマットをそれぞれ定義するシステムプロファイル用の項目定義情報と、
管理対象の全てのシステムの項目定義情報を網羅する標準プロファイル用の項目定義情報と、
前記システムプロファイル用の項目定義情報と前記標準プロファイル用の項目定義情報との対応関係を定義する項目関連定義情報とを格納し、
前記システムプロファイル用の項目定義情報、前記標準プロファイル用の項目定義情報及び前記項目関連定義情報を利用して、異なる２つのシステムのうちの一方のシステムのプロファイルにしたがったエクスポートデータのデータ項目を、他方のシステムのプロファイルにしたがったインポートデータのデータ項目に自動的に変換することを特徴とするデータ管理システム。
【請求項２】
少なくとも、前記システムの各データ項目を一意に示す列ＩＤと、前記標準プロファイルの各データ項目を一意に示す列ＩＤとを予め定義して静的に格納する列管理ファイルを備え、前記列管理ファイルに前記システムプロファイル用の項目定義情報及び前記標準プロファイル用の項目定義情報を格納し、
前記システムの各データ項目を一意に示す列ＩＤと前記標準プロファイルの各データ項目を一意に示す列ＩＤとの対応関係を予め定義して静的に格納する項目関連定義ファイルを備え、前記項目関連定義ファイルに前記項目関連定義情報を格納したことを特徴とする請求項１記載のデータ管理システム。
【請求項３】
前記システムプロファイル用の項目定義情報及び当該システムプロファイル用の項目定義情報と、前記標準プロファイル用の項目定義情報との対応関係を定義する当該システムプロファイル用の前記項目関連定義情報とを、対として、ネットワーク上に格納し、利用者の要求に応じて、任意の少なくとも２つのシステムの前記システムプロファイル用の項目定義情報と当該システムプロファイル用の前記項目関連定義情報とをダウンロードして、ダウンロードした前記システムプロファイル用の項目定義情報及び当該システムプロファイル用の前記項目関連定義情報の対と、前記標準プロファイル用の項目定義情報とを利用して、当該少なくとも２つのシステムのうちの一方のシステムのデータフォーマットにしたがったエクスポートデータのデータ項目を、他方のシステムのデータフォーマットにしたがったインポートデータのデータ項目に自動的に変換することを特徴とする請求項１記載のデータ管理システム。
【請求項４】
異なるデータフォーマットを有する対象データ間でデータ変換を行うデータ管理システムであって、
データ変換対象となる対象データの各々について作成され、各対象データのレコードを構成するデータ項目を一意に示す列ＩＤを格納し、各対象データのデータフォーマットを定義するシステムプロファイルと、
全ての前記対象データの全データ項目を網羅するデータ項目を、当該データ項目を一意に示す列ＩＤと共に格納し、前記対象データの標準データフォーマットを定義する標準プロファイルと、
前記各システムプロファイルのデータ項目と、前記標準プロファイルにおける当該システムプロファイルのデータ項目との間の対応関係と変換処理とを定義する項目関連定義情報と、
前記対象データのレコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して格納する行管理ファイルと、
前記対象データのレコードの読込時に、当該読込レコードのデータ項目の項目値を、当該読込レコードを一意に示す行ＩＤと、前記列管理ファイルに格納した当該読込レコードにおける当該データ項目値のデータ項目に対応する列ＩＤとにより、一意に特定して格納する値管理ファイルとを備え、
変換元となる対象データのデータフォーマットを、当該対象データに対応する前記システムプロファイルに基づいて判断し、当該対象データに対応する前記項目関連定義情報により、当該対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換し、
変換先となる対象データのデータフォーマットを、当該対象データに対応する前記システムプロファイルに基づいて判断し、当該対象データに対応する前記項目関連定義情報により、前記変換元となる対象データから変換された前記標準データを当該変換先の対象データのデータフォーマットにしたがったデータへと変換することを特徴とするデータ管理システム。
【請求項５】
更に、前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記変換元の対象データから一部のデータ項目値を別個に抽出し、当該抽出したデータ項目値を所定のデータフォーマットにしたがって変換して追加データを作成及び格納し、その後の前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記格納済みの追加データと、その後のデータ変換時に新たに作成した追加データとを比較して、それらの間の整合性を判断することを特徴とする請求項４記載のデータ管理システム。
【請求項６】
更に、前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記変換元の対象データからマスタデータを構成する一部のデータ項目値を別個に抽出し、当該抽出したデータ項目値を所定のデータフォーマットにしたがって変換してマスタデータを作成及び格納し、その後の前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記格納済みのマスタデータと、その後のデータ変換時に新たに作成したマスタデータとを比較して、それらの間の整合性を判断することを特徴とする請求項４記載のデータ管理システム。
【請求項７】
前記対象データの各々に対して、当該対象データに対応する前記システムプロファイルを一意に示すシステムプロファイル特定情報と、当該対象データに対応する前記項目関連定義情報を一意に示す項目関連定義特定情報とを少なくとも有する共通フォーマットの共用情報を付加し、変換元の対象データの読み込み時に、前記共用情報に基づいて、当該変換元の対象データに対応する前記システムプロファイル及び前記項目定義情報を判断して、当該対応する前記システムプロファイル及び前記項目定義情報を使用して当該変換元の対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換することを特徴とする請求項４記載のデータ管理システム。
【請求項８】
前記対象データの各々に対して、当該対象データの送信元を一意に示す送信元情報と、当該送信元の対象データに対応する前記システムプロファイルを一意に示す送信元システムプロファイル特定情報と、当該送信元の対象データに対応する前記項目関連定義情報を一意に示す送信元項目関連定義特定情報と、当該対象データの送信先を一意に示す送信先情報と、当該送信先の対象データに対応する前記システムプロファイルを一意に示す送信先システムプロファイル特定情報と、当該送信先の対象データに対応する前記項目関連定義情報を一意に示す送信先項目関連定義特定情報とを有する共通フォーマットの共用情報からなるヘッダ情報を付加し、
変換元の対象データの送信時に、
当該変換元の対象データの前記ヘッダ情報の送信元情報に基づいて、当該変換元の対象データの格納先を判断し、その判断に基づいて選択した格納先に当該変換元の対象データを格納し、
当該変換元の対象データの前記ヘッダ情報の送信元システムプロファイル特定情報及び送信元項目関連定義特定情報に基づいて、当該変換元の対象データに対応する前記システムプロファイル及び項目関連定義情報を判断し、その判断に基づいて選択した前記システムプロファイル及び前記項目定義情報を使用して、前記格納先に格納した前記変換元の対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換し、
当該変換元の対象データの前記ヘッダ情報の送信先システムプロファイル特定情報及び送信先項目関連定義特定情報に基づいて、当該変換先の対象データに対応する前記システムプロファイル及び項目関連定義情報を判断し、その判断に基づいて選択した前記システムプロファイル及び前記項目定義情報を使用して、前記標準データを前記送信先の対象データのデータフォーマットにしたがった送信先データへと変換し、
当該変換元の対象データの前記ヘッダ情報の送信先情報に基づいて、前記送信先データの格納場所を判断し、その判断に基づいて選択した格納先に当該送信先データを格納することを特徴とする請求項４記載のデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理システムに関し、特に、多種多様なフォーマットのデータを互いに交換するのに好適なデータ管理システムに関する。
【背景技術】
【０００２】
従来、この種の技術として、例えば、特許文献１に記載の技術がある。
【特許文献１】特開２００３−２０８３８２号公報
【０００３】
特許文献１には、ＥＤＩ利用ユーザ企業各々に、ＥＤＩ標準フォーマットデータのＥＤＩ利用ユーザ企業社内フォーマットデータへのデータフォーマット変換とその逆変換上での負担を負わせることなく、それらデータフォーマット変換がインターネット上の特定サイト上で行われるようにした、ＥＤＩ利用ユーザ企業間でのデータフォーマット変換方法とそのシステムが開示されている。このシステムは、ＥＤＩ利用ユーザ企業間でのデータ送受信を、それぞれの社内フォーマットデータを以って行う。具体的には、このシステムは、電子商取引サイトに、インターネットを介しあるユーザ企業からユーザ企業への社内フォーマットデータがあった場合、そのデータはそのユーザ企業対応の事前登録データ変換プロファイル情報に基づき、一旦、ＥＤＩ標準フォーマットデータに変換されるが、その後は、更に、ユーザ企業対応の事前登録データ変換プロファイル情報に基づき、ユーザ企業の社内フォーマットデータに変換された上、インターネットを介しユーザ企業に送信される。この技術は、既存マッピングツールをインターネット上で機能させる仕組みであり、各企業が自社の個別フォーマットを業界標準フォーマットとマッピングさせる事で利用可能となる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に記載の技術は、取引先企業が利用していない場合は、利用不可である。また、特許文献１には、具体的なデータ格納やデータ変換の記述は無く、外部設計に終始している。また、ＥＤＩ利用ユーザ企業間でのデータ送受信を対称にしたものであり、ＥＤＩ標準フォーマットデータ自体の利用が少ない現状では、利用できる企業が大幅に限定される。
【０００５】
そこで、本発明は、多種多様なフォーマットのデータを互いに交換することができると共に、管理対象データのデータフォーマットの追加、変更等にも容易に対処できるデータ管理システムの提供を課題とする。
【課題を解決するための手段】
【０００６】
請求項１に係るデータ管理システムは、異なるシステムのデータフォーマットをそれぞれ定義するシステムプロファイル用の項目定義情報（例えば、後述する列管理テーブルの対応部分により構成される）と、管理対象の全てのシステムの項目定義情報を網羅する標準プロファイル用の項目定義情報（例えば、後述する列管理テーブルの対応部分により構成される）と、前記システムプロファイル用の項目定義情報と前記標準プロファイル用の項目定義情報との対応関係を定義する項目関連定義情報（例えば、後述する項目関連定義テーブルの対応部分により構成される）とを格納し、前記システムプロファイル用の項目定義情報、前記標準プロファイル用の項目定義情報及び前記項目関連定義情報を利用して、異なる２つのシステムのうちの一方のシステムのプロファイルにしたがったエクスポートデータのデータ項目を、他方のシステムのプロファイルにしたがったインポートデータのデータ項目に自動的に変換する。
【０００７】
請求項２に係るデータ管理システムは、請求項１の構成において、少なくとも、前記システムの各データ項目を一意に示す列ＩＤと、前記標準プロファイルの各データ項目を一意に示す列ＩＤとを予め定義して静的に格納する列管理ファイルを備え、前記列管理ファイルに前記システムプロファイル用の項目定義情報及び前記標準プロファイル用の項目定義情報を格納し、前記システムの各データ項目を一意に示す列ＩＤと前記標準プロファイルの各データ項目を一意に示す列ＩＤとの対応関係を予め定義して静的に格納する項目関連定義ファイルを備え、前記項目関連定義ファイルに前記項目関連定義情報を格納した。
【０００８】
請求項３に係るデータ管理システムは、請求項１の構成において、前記システムプロファイル用の項目定義情報及び当該システムプロファイル用の項目定義情報と、前記標準プロファイル用の項目定義情報との対応関係を定義する当該システムプロファイル用の前記項目関連定義情報とを、対として、ネットワーク上に格納し、利用者の要求に応じて、任意の少なくとも２つのシステムの前記システムプロファイル用の項目定義情報と当該システムプロファイル用の前記項目関連定義情報とをダウンロードして、ダウンロードした前記システムプロファイル用の項目定義情報及び当該システムプロファイル用の前記項目関連定義情報の対と、前記標準プロファイル用の項目定義情報とを利用して、当該少なくとも２つのシステムのうちの一方のシステムのデータフォーマットにしたがったエクスポートデータのデータ項目を、他方のシステムのデータフォーマットにしたがったインポートデータのデータ項目に自動的に変換する。
【０００９】
請求項４に係るデータ管理システムは、異なるデータフォーマットを有する対象データ間でデータ変換を行うデータ管理システム、例えば、第１のデータフォーマットを有する第１の対象データ（変換前データ乃至エクスポートデータ）から、前記第１のデータフォーマットと異なる第２のデータフォーマットを有する第２のデータ（変換後データ乃至インポートデータ）へとデータ変換を行うデータ管理システムである。このデータ管理システムは、システムプロファイル、標準プロファイル、項目関連定義情報、行管理ファイル、値管理ファイルを備える。システムプロファイルは、データ変換対象となる対象データの各々について作成され、各対象データのレコードを構成するデータ項目を一意に示す（または、一意に識別する）列ＩＤを格納し、各対象データのデータフォーマットを定義する。例えば、システムプロファイルは、後述する列管理テーブルの対応部分に相当し、例えば、図８５の独自データプロファイル１２５２，１２６２として具体化することができる。また、標準プロファイルは、全ての前記対象データの全データ項目を網羅するデータ項目を、当該データ項目を一意に示す列ＩＤと共に格納し、前記対象データの標準データフォーマットを定義する。標準プロファイルは、例えば、後述する図８５のＳＸＰ標準プロファイル１２５０として具体化することができる。項目関連定義情報は、前記各システムプロファイルのデータ項目と、前記標準プロファイルにおける当該システムプロファイルのデータ項目との間の対応関係と変換処理（例えば、後述する関数管理テーブルに定義するシステム関数にしたがった処理）とを定義する。項目関連定義情報は、例えば、後述する図８５の変換定義１２５１，１２６１として具体化することができる。行管理ファイルは、前記対象データのレコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して格納する。行管理ファイルは、例えば、後述する行管理テーブルとして具体化することができる。値管理ファイルは、前記対象データのレコードの読込時に、当該読込レコードのデータ項目の項目値を、当該読込レコードを一意に示す行ＩＤと、前記列管理ファイルに格納した当該読込レコードにおける当該データ項目値のデータ項目に対応する列ＩＤとにより、一意に特定して格納する。値管理ファイルは、例えば、後述する値管理テーブルとして具体化することができる。そして、本データ管理システムは、変換元となる（例えば、データを送信する場合には、送信データ乃至変換前データとなる）対象データのデータフォーマットを、当該対象データに対応する前記システムプロファイルに基づいて判断し、当該対象データに対応する前記項目関連定義情報により、当該対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換する。また、本データ管理システムは、変換先となる対象データのデータフォーマットを、当該対象データに対応する前記システムプロファイルに基づいて判断し、当該対象データに対応する前記項目関連定義情報により、前記変換元となる対象データから変換された前記標準データを当該変換先の対象データのデータフォーマットにしたがったデータへと変換する。この処理は、例えば、後述する図８５のＳＸＰサービスシステムによる処理として具体化することができる。
【００１０】
請求項５に係るデータ管理システムは、請求項４の構成において、更に、前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記変換元の対象データから一部のデータ項目値を別個に抽出し、当該抽出したデータ項目値を所定のデータフォーマットにしたがって変換して追加データを作成及び格納し、その後の前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記格納済みの追加データと、その後のデータ変換時に新たに作成した追加データとを比較して、それらの間の整合性を判断する。例えば、かかるデータ管理システムは、後述する図１０８のＳＸＰサービスシステムとして具体化することができる。
【００１１】
請求項６に係るデータ管理システムは、請求項４の構成において、更に、前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記変換元の対象データからマスタデータを構成する一部のデータ項目値を別個に抽出し、当該抽出したデータ項目値を所定のデータフォーマットにしたがって変換してマスタデータを作成及び格納し、その後の前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記格納済みのマスタデータと、その後のデータ変換時に新たに作成したマスタデータとを比較して、それらの間の整合性を判断する。例えば、かかるデータ管理システムは、後述する図１０８のＳＸＰサービスシステム（特にマスタ系データの自動構築用）として具体化することができる。
【００１２】
請求項７に係るデータ管理システムは、請求項４の構成において、前記対象データの各々に対して、当該対象データに対応する前記システムプロファイルを一意に示すシステムプロファイル特定情報と、当該対象データに対応する前記項目関連定義情報を一意に示す項目関連定義特定情報とを少なくとも有する共通フォーマットの共用情報を付加し、変換元の対象データの読み込み時（例えば、ネットワーク送信を行う場合は、読み込みに伴う送信時等）に、前記共用情報に基づいて、当該変換元の対象データに対応する前記システムプロファイル及び前記項目定義情報を判断して、当該対応する前記システムプロファイル及び前記項目定義情報を使用して当該変換元の対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換する。例えば、かかるデータ管理システムは、後述する図１１２のＳＸＰサービスシステムとして具体化することができる。
【００１３】
請求項８に係るデータ管理システムは、請求項４の構成において、前記対象データの各々に対して、当該対象データの送信元を一意に示す送信元情報と、当該送信元の対象データに対応する前記システムプロファイルを一意に示す送信元システムプロファイル特定情報と、当該送信元の対象データに対応する前記項目関連定義情報を一意に示す送信元項目関連定義特定情報と、当該対象データの送信先を一意に示す送信先情報と、当該送信先の対象データに対応する前記システムプロファイルを一意に示す送信先システムプロファイル特定情報と、当該送信先の対象データに対応する前記項目関連定義情報を一意に示す送信先項目関連定義特定情報とを有する共通フォーマットの共用情報からなるヘッダ情報を付加する。そして、本データ管理システムは、変換元の対象データの送信時に、以下の処理を実行する。即ち、本データ管理システムは、まず、当該変換元の対象データの前記ヘッダ情報の送信元情報に基づいて、当該変換元の対象データの格納先を判断し、その判断に基づいて選択した格納先に当該変換元の対象データを格納し、次に、当該変換元の対象データの前記ヘッダ情報の送信元システムプロファイル特定情報及び送信元項目関連定義特定情報に基づいて、当該変換元の対象データに対応する前記システムプロファイル及び項目関連定義情報を判断し、その判断に基づいて選択した前記システムプロファイル及び前記項目定義情報を使用して、前記格納先に格納した前記変換元の対象データを前記標準プロファイルの標準データフォーマットにしたがった標準データへと変換し、次に、当該変換元の対象データの前記ヘッダ情報の送信先システムプロファイル特定情報及び送信先項目関連定義特定情報に基づいて、当該変換先の対象データに対応する前記システムプロファイル及び項目関連定義情報を判断し、その判断に基づいて選択した前記システムプロファイル及び前記項目定義情報を使用して、前記標準データを前記送信先の対象データのデータフォーマットにしたがった送信先データへと変換し、次に、当該変換元の対象データの前記ヘッダ情報の送信先情報に基づいて、前記送信先データの格納場所を判断し、その判断に基づいて選択した格納先に当該送信先データを格納する。例えば、かかるデータ管理システムは、後述する図１１２のＳＸＰサービスシステムとして具体化することができる。
【００１４】
本発明のデータ管理システムは、階層型データベース、ネットワーク型データベース、リレーショナルデータベース（ＲＤＢ）等の任意のデータベースを使用するデータ管理システムに適用することができる。なお、請求項１のデータ管理システムを、リレーショナルデータベース（関係データベースとも呼ばれる）を利用したデータ管理システムに適用した場合、列管理ファイルは列管理テーブルとなり、行管理ファイルは行管理テーブルとなり、値管理ファイルは値管理テーブルとなる。このように、本発明は、特に、ＲＤＢを利用したデータベースシステムに具体化することが好ましいが、無論、その他のデータベース（ＤＢ）に具体化することも可能である。ここで、上記管理対象のレコードは、１レコードが、通常、複数のフィールド（複数のデータ項目）からなり、ＲＤＢの場合、１行のレコードをタプルと称することがある。また、通常、複数のレコードが１ファイルを構成し、ＲＤＢの場合、１ファイルが１テーブルとなる。そして、ファイルごとに固有のデータフォーマットがあり、ＲＤＢの場合、テーブルごとに固有のデータフォーマット（データ構造乃至スキーマ）がある。即ち、各テーブルは、固有のデータ項目（カラムまたは列と称することもあり、通常は複数である）を並べたデータフォーマットを有している。
また、本発明のデータ管理システムは、列ＩＤとして、通常のＲＤＢ等で使用されるコード体系（数字や英数字を使用したコード体系）にしたがったＩＤの他、ＸＭＬタグ等を利用したコード体系によるＩＤを使用することもできる。
【発明の効果】
【００１５】
本発明に係るデータ管理システムは、多種多様なフォーマットのデータを互いに交換することができると共に、管理対象データのデータフォーマットの追加、変更等にも容易に対処できる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明を実施するための最良の形態（以下、実施の形態という）を説明する。なお、各実施の形態を通じ、同一の部材、要素または部分には同一の符号を付して、その説明を省略する。
【００１７】
実施の形態１
図１は本発明の実施の形態１に係るデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。図２は本発明の実施の形態１に係るデータ管理システムのデータ構造を概略的に示す説明図である。なお、図７７は従来のデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。
【００１８】
従来の売上管理システム
従来のデータ管理システムは、取り扱うデータが異なるフォーマットまたは異なるデータ定義を有する場合、そのフォーマットまたはデータ定義の種類分だけ、データ定義（スキーマ定義）を行い、テーブルを作成して管理する。例えば、図７７に示す従来の売上管理システム５１０は、売上管理のために必要な異なるフォーマット乃至データ定義の各種データとして、商品データ、在庫データ、顧客データ、店舗データ、売上データ、請求データ等を取り扱う。よって、リレーショナルデータベース（ＲＤＢ）を使用する場合、従来の売上管理システム５１０は、各種データに対応する別個の格納領域として、それぞれ、商品テーブル５１１、在庫管理テーブル５１２、顧客テーブル５１３、店舗テーブル５１４、売上管理テーブル５１５、請求管理テーブル５１６等を準備して対応する各データを格納及び管理する。即ち、この場合、各テーブル５１１〜５１６等について、れぞれ、データ定義（スキーマ定義）を別個に作成する。また、従来のデータ管理システムは、データをモニタ画面１に表示または出力する場合、異なるフォーマットまたはデータ定義ごとに表示（出力）プログラムを用意する必要がある。例えば、図７７の売上管理システムの場合、商品テーブル５１１、在庫管理テーブル５１２、顧客テーブル５１３、店舗テーブル５１４、売上管理テーブル５１５、請求管理テーブル５１６等に格納した異なるフォーマット乃至データ定義の各データに対応して、それぞれ、商品明細表示（出力）プログラム（ＰＧ）５１７、在庫明細表示（出力）プログラム（ＰＧ）５１８、顧客明細表示（出力）プログラム（ＰＧ）５１９、店舗明細表示（出力）プログラム（ＰＧ）５２０、売上明細表示（出力）プログラム（ＰＧ）５２１、請求明細表示（出力）プログラム（ＰＧ）５２２等を用意し、当該異なる表示プログラムを使用して、当該異なるフォーマット乃至定義のデータをモニタ画面１にそれぞれ表示する必要がある。
【００１９】
本発明を適用した場合の売上管理システム
このように、従来のデータ管理システムでは、異なるデータ定義のデータごとに別個の格納領域及び表示プログラムを用意する必要があり、システムが使用するテーブルが増えるほど、データベースが大規模化し、プログラム開発に多大な労力を必要とする。そこで、本発明者は、鋭意研究を重ねた結果、かかる課題を解決する発明としてのデータ管理システムを発明した。本発明に係るデータ管理システムは、例えば、図１に示すように、実施の形態１の売上管理システム１０に具体化することができる。詳細には、実施の形態１の売上管理システム１０は、従来の売上管理システムで取り扱う全てのデータ（異なるフォーマット乃至データ定義のデータ）を取り扱うことができる一方、従来のように、データのフォーマット乃至定義ごとに別個のデータ定義（スキーマ定義）を作成して別個のテーブルを用意するのではなく、各データの定義情報を格納及び管理する列管理テーブル（データ項目乃至カラムを管理するマスタ系テーブル）１１をマスタテーブルとして用意して、異なる全てのデータフォーマット乃至データ定義に対応するようにしている。また、売上管理システム１０は、各データに含まれるデータ項目値のうち、識別子や検索キーとなる項目値（インデックスデータ）を順次格納する行管理テーブル（インデックスデータを管理するトランザクション系テーブル）１２と、前記列管理テーブル１１の定義情報の値と、行管理テーブル１２の識別子の値とを組み合わせることで、各データに含まれる全ての項目値を一意に特定できるように順次格納する値管理テーブル（項目値を格納するトランザクション系テーブル）１３とを備えている。更に、売上管理システム１０は、列管理テーブル１１の定義情報に基づき、行管理テーブル１２に格納した識別子を使用して、値管理テーブル１３に格納したデータ項目値のうちの必要な項目値を抽出し、所定のフォーマットでモニタ画面１に表示する表示（出力）プログラム（ＰＧ）１４を備えている。これにより、売上管理システム１０は、列管理テーブル１１、行管理テーブル１２及び値管理テーブル１３の３つのテーブルを用意するだけで、多種多様なデータ定義のデータを格納して管理することができ、各データ定義に対応して別個のテーブルを用意する必要がない。また、売上管理システム１０は、単一の表示（出力）プログラム１４により、多種多様なデータ定義のデータの任意の値を所定の形式でモニタ画面１に表示することができ、各データ定義に対応した別個のプログラムを用意する必要がない。即ち、本売上管理システム１０では、単一の表示プログラム１４を使用しながら、図１に示すように、モニタ画面１の表示上は、図７７の固有のデータ定義を有す各種テーブル（店舗テーブル、売
上管理テーブル等）に対応する内容で同様のデータ（店舗データ、売上管理データ等）の表示が行われる。
【００２０】
データ分離格納のスキーマ（データ項目）
実施の形態１に係るデータ管理システムを売上管理システム以外のデータ管理システムについても当てはまるよう汎用的に説明すると、図２の中央に示すように、列管理テーブルは、管理対象の全てのデータ（テーブル）の各データ項目（フィールド）について一意に割り当てられる「列ＩＤ」と、当該列ＩＤが割り当てられたデータ項目が属するテーブルを示す「テーブル名」と、各テーブルのデータ項目の属性名（データ項目名）を示す「属性名」とからなるスキーマ（データ定義）を有する。即ち、列管理テーブルは、自身のデータ項目として、少なくとも、「列ＩＤ」、「テーブル名」及び「属性名」を備えている。例えば、取り扱うデータ（管理対象のデータ）が、甲、乙、丙、丁であり、甲データのスキーマが、属性Ｘ（ＩＤ）、属性Ａ、属性Ｂ、属性Ｃからなり、乙データのスキーマが、属性Ｘ（ＩＤ）、属性Ｃ、属性Ｂ、属性Ｄからなり、丙データのスキーマが、属性Ｙ（ＩＤ）、属性Ａ、属性Ｃ、属性Ｅからなり、丁データのスキーマが、属性Ｚ（ＩＤ）、属性Ｆ、属性Ｇ、属性Ｈからなる場合、従来のシステムでは、図２中の左側に示すように、各スキーマに対応して、甲テーブル、乙テーブル、丙テーブル及び丁テーブルが作成される。なお、各テーブルには、各データ項目（属性Ｘ等）について、項目値（ｘ１等）が格納される。これに対し、実施の形態１に係るデータ管理システムでは、列管理テーブル１１は、これらデータ定義（スキーマ）の異なる各データ（甲、乙、丙、丁）を管理対象とする場合、そのテーブル名と属性名（データ項目名）とを対応付けて各行に予め格納し、各行に列ＩＤを一意に割り当てる。具体的には、列管理テーブルは、甲データについては、その属するテーブル名（甲）と各属性名（属性Ｘ、属性Ａ、属性Ｂ、属性Ｃ）とを各行に対応付けて格納し、各行に一意の列ＩＤ（１〜）を対応付けている（乙データ、丙データ、丁データについても同様）。これにより、列管理テーブルの列ＩＤを参照することで、各データ（甲、乙、丙、丁）のデータ項目（属性名）を一意に特定することができる。このように、列管理テーブルは、管理対象の全てのデータやレコードのデータ項目を一意に特定できるよう、それらのデータ項目を（データ項目としてではなく）データ項目値として格納するマスタ系テーブルである。
【００２１】
また、データ管理システムでは、行管理テーブルは、前記管理対象データ（甲、乙、丙、丁）の各レコード（テーブルの各行）を読込むごとに自動的に付与される「行ＩＤ」と、各読込レコードを一意に示す「識別子」とからなるスキーマ（データ定義）を有する。そして、データ管理システムは、管理対象のレコードを読込むごとに、各読込レコードに対して行ＩＤを発番すると共に、当該読込レコード中の特定のデータ項目値を識別子として抽出し、行ＩＤに対応付けて格納する。例えば、行管理テーブルは、甲、乙、丙、丁の各テーブルについて、識別子として、属性Ｘの列のデータ項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）、属性Ｙの列のデータ項目値（ｙ１，ｙ２，ｙ３，ｙ４，ｙ５，ｙ６）、属性Ｚの列のデータ項目値（ｚ１，ｚ２，ｚ３，ｚ４，ｚ５，ｚ６）を格納する。具体的には、データ管理システムは、甲データについては、各行のレコードを読み込むごとに、各レコードのＩＤでもある属性Ｘの項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）を、順次、識別子の列に格納すると共に、各読込レコードの識別子に対応付けて行ＩＤを自動発番して格納する（乙データ、丙データ、丁データについても同様）。これにより、行管理テーブルの行ＩＤを参照することで、各読込レコード（及びその識別子）を一意に特定することができる。このように、行管理テーブルは、管理対象の全てのデータの読込レコードを一意に特定できるよう、それらのレコードに一意の行ＩＤを割り当てて格納するトランザクション系テーブルである。
【００２２】
データ分離格納のスキーマ（データ項目値）
更に、データ管理システムでは、値管理テーブルは、前記管理対象データ（甲、乙、丙、丁）の各レコード（テーブルの各行）を読込むごとに自動的に付与される「行ＩＤ」と、各読込レコードの各データ項目を一意に示す「列ＩＤ」と、行ＩＤ及び列ＩＤにより一意に特定される読込レコードの各データ項目の「値（データ項目値）」からなるスキーマ（データ定義）を有する。そして、データ管理システムは、上記のように、管理対象のレコードを読込むごとに、各読込レコードに対して行ＩＤを発番して行管理テーブルに格納すると共に、各読込レコードをそのデータ項目ごとに分解して各データ項目値を取得する。このとき、データ管理システムは、各読込レコードが属するテーブル名を判断し、列管理テーブルを参照して、当該テーブル名のデータ項目である属性名を特定し、前記抽出した読込レコードの各データ項目値に対して各属性名の列ＩＤを割り当てる。また、同一読込レコードについては、当然、同一行ＩＤが割り当てられる。具体的には、データ管理システムは、甲データについては、各行のレコードを読み込むごとに、当該読込レコードをデータ項目単位（Ｘ，Ａ，Ｂ，Ｃの単位）で分割して各データ項目値（ｘ１，ａ１，ｂ１，ｃ１、ｘ２，ａ２，ｂ２，ｃ２、・・・）を取得する。これと共に、データ管理システムは、当該読込レコードに割り当てた行ＩＤ（１、２、・・・）と、当該読込レコードの各属性名（属性Ｘ、属性Ａ、属性Ｂ、属性Ｃ）とを、取得した各データ項目値に対応付けて格納する。例えば、甲データの１行目のレコードについては、各データ項目値（ｘ１，ａ１，ｂ１，ｃ１）を取得すると共に、各データ項目値に対して、当該レコードの行ＩＤ（１）と各データ項目値の属性名に対応する列ＩＤ（１，２，３，４）とを割り当てて格納する。以降、甲データの各行のレコードについて、同様の処理により、各データ項目値が値管理テーブルに格納される。乙データ、丙データ、丁データの場合も同様である。これにより、値管理テーブルの行ＩＤ及び列ＩＤを参照することで、各読込レコードの各データ項目値を一意に特定することができる。このように、値管理テーブルは、管理対象の全てのデータの読込レコードの各データ項目値を一意に特定できるよう、それらのデータ項目値に行ＩＤ及び列ＩＤを割り当てて格納するトランザクション系テーブルである。
【００２３】
ここで、行管理テーブル１３の識別子としては、管理対象データ（甲データ等）自体のインデックスとなる項目値（ｘ１，ｘ２・・・）以外の項目値または複数の項目値の組合せを私用しても良い。また、前記列管理テーブル１１の列ＩＤ及び行管理テーブル１２の行ＩＤは、説明を単純化するために、単なる数字（連番）とされているが、一意となる限りにおいて、無論、任意の規則にしたがって列ＩＤ及び行ＩＤを作成することができる（例えば、後述の列管理テーブルの説明参照）。
【００２４】
データ分離格納を使用した売上管理システム
図３は本発明の実施の形態１に係るデータ管理システムを売上管理システムに具体化した場合のデータ構造を概略的に示す説明図である。実施の形態１に係る売上管理システム１０は、上記図２により説明した場合と同様のデータ構造を有し、同様のデータ処理により管理対象データを３つのテーブルに格納する。即ち、売上管理システムは、列管理テーブル１１に、予め、各管理対象データのスキーマ定義情報としての属性名（即ち、読込対象となる商品、在庫管理、顧客、売上管理、店舗、請求管理の各テーブルのデータ項目名）を、当該テーブル名及び一意の列ＩＤと共にマスタデータとして格納している。具体的には、列管理テーブル１１は、図１に示すデータを管理対象とする場合、商品テーブルのデータ項目（商品ＩＤ、商品名、価格、内容量）、在庫管理テーブルのデータ項目（商品ＩＤ、商品名、在庫数、場所）、顧客テーブルのデータ項目（顧客ＩＤ、顧客名、連絡先、担当者）、売上管理テーブルのデータ項目（商品ＩＤ、顧客ＩＤ、売上数、売上高）、店舗テーブルのデータ項目（顧客ＩＤ、店舗ＩＤ、店舗名、場所）及び請求管理テーブルのデータ項目（請求ＩＤ、顧客ＩＤ、請求額、締日）を一意の列ＩＤ（１，２，３，４・・・）に対応付けて格納している。なお、図３では、売上管理テーブル及び店舗テーブルについては、説明の便宜上、図示を省略している。また、図３の各テーブル中、属性名の右横のカッコ内の英字（アルファベット）が同一のものは、データ項目が同一であることを意味する。（例えば、商品テーブルの商品ＩＤ（Ｘ）と在庫テーブルの商品ＩＤ（Ｘ）は同一データ項目であり、商品テーブルの商品名（Ａ）と在庫テーブルの商品名（Ａ）は同一データ項目である等々。）これにより、列管理テーブル１１を参照することで、管理対象データのテーブル名に加えて、当該テーブルのデータ項目を判断することができる。例えば、商品テーブルについては、列ＩＤの「１〜４」に対応して、属性名として「商品ＩＤ、商品名、価格、内容量」が定義されているため、列ＩＤの「１〜４」を参照することで、管理対象データのテーブルが「商品テーブル」であると判断でき、かつ、商品テーブルのデータ項目が「商品ＩＤ、商品名、価格、内容量」であると判断することができる。
【００２５】
また、売上管理システムは、管理対象データの各レコードを読み込むごとに、行管理テーブル１２に一意の行ＩＤを割り当てて格納すると共に、当該読込レコードの特定のデータ項目値を識別子として格納する。例えば、商品テーブルのレコードを読み込む場合、行管理テーブル１２には、商品テーブルのレコード（一行）を読込むごとに行ＩＤ（１，２・・・）が発行され、行ＩＤに対応して読込レコードの特定の項目値が識別子として格納される。例えば、商品テーブルに関しては、商品ＩＤ（４９００１，４９００２・・・）を識別子として行管理テーブル１２に格納することができる。なお、在庫テーブル等の他のテーブルについても、同様に、各読込レコードに一意の行ＩＤが付与されると共に、各読込レコードの特定の項目値が識別子として取得され、行ＩＤと対応付けて格納される。
【００２６】
更に、売上管理システムは、管理対象データの各レコードを読み込むごとに、各読込レコードをデータ項目の項目値ごとに分割し、分割したデータ項目値の全てに同一の行ＩＤを割り当てると共に、分割したデータ項目値に対応する列ＩＤを順に割り当てて、行ＩＤ、列ＩＤ及び値のセットで格納する。例えば、商品テーブルのレコード（「４９００１，ガム，１００，１０」、「４９００２，飴，１００，１０」・・・）を読み込む場合、売上管理システムは、まず一行目のレコード（４９００１，ガム，１００，１０）のデータ項目値を分割し、それら４つのデータ項目値に行ＩＤ（１）を割り当てると共に、それら４つのデータ項目値に対して列ＩＤ（１〜４）を順に割り当て、それらのデータセット（「１，１，４９００１」、「１，２，ガム」、「１，３，１００」、「１，４，１０」）を値管理テーブル１３に格納する。なお、在庫テーブル等の他のテーブルについても、同様に、各読込レコードに一意の行ＩＤが付与される。２行目以降のレコードについても、各レコード読込時に、同様にして、行ＩＤ、列ＩＤ及び値の組が値管理テーブル１３に格納される。なお、在庫テーブル等の他のテーブルについても、同様に、読込レコードの各データ項目値が、行ＩＤ及び列ＩＤと対応付けて格納される。
【００２７】
図４〜図８は従来のデータ管理システムにおけるデータ定義の一例としての商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルをそれぞれ示す。
【００２８】
図４に示すように、従来の商品テーブルは、データ項目として、「商品ＩＤ」、「商品名」、「単価」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、たばこ、２００円等）を格納する。同様に、顧客テーブルは、データ項目として、「企業コード」、「企業名」、「電話番号」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（ア、山田商事、０５８−１１１−１１１１等）を格納する。同様に、顧客単価テーブルは、データ項目として、「商品ＩＤ」、「企業コード」、「単価」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、ア、２００円等）を格納する。同様に、在庫管理テーブルは、データ項目として、「商品ＩＤ」、「数量」、「場所」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、５００、倉庫Ａ等）を格納する。同様に、販売管理テーブルは、データ項目として、「商品ＩＤ」、「企業コード」、「販売数」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、ア、１００個等）を格納する。
【００２９】
売上管理システムに適用した列管理テーブル
図９は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における列管理テーブルを示す。
図９に示すように、実施の形態１に係るデータ管理システムを適用した列管理テーブルは、図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルのデータ定義をデータ項目としてではなく、データ項目値として格納するものであり、それら５つのテーブルのデータ項目を全てデータ項目値として予め定義し、マスタデータとして格納している。詳細には、列管理テーブルは、データ項目（カラム乃至属性とも呼ばれる）として、「列ＩＤ」、「データ種類」、「テーブルＩＤ」、「枝番」、「連番」、「データ項目名」、「データ型」、「位置」、「最大長」、「最小長」等を定義している。このうち、データ種類は、管理対象のデータの種類を一意に示すものであり、テーブルＩＤは、管理対象のデータが属するテーブルを一意に示すものである。データ種類は、テーブルＩＤより上位概念のデータ群を定義するＩＤであり、例えば、テーブルＩＤが「商品マスタ」の場合、当該商品マスタ（マスタデータ）を包括する（即ち、他の同類のデータを包括する）取引情報データの種類を一意に示すものとすることができる。この場合、例えば、図９の例では、データ種類「１２０１」の上位データ群にはテーブルＩＤ「商品マスタデータ」等の下位データ群が属し、データ種類「１２０２」の上位データ群にはテーブルＩＤ「顧客マスタデータ」等の下位データ群が属し、データ種類「１２０３」の上位データ群にはテーブルＩＤ「顧客単価マスタデータ」等の下位データ群が属し、データ種類「１２０４」の上位データ群にはテーブルＩＤ「在庫マスタデータ」等の下位データ群が属し、データ種類「１２０５」の上位データ群にはテーブルＩＤ「販売マスタデータ」等の下位データ群が属することになる。
【００３０】
ここで、図９の例では、テーブルＩＤは、説明の簡略化のため、「商品マスタ」、「顧客マスタ」等の文字列で表しているが、実際は、所定のコード体系（ＩＤ付与規則）にしたがってテーブルごとに付与される一意のＩＤ（英数字等）からなる。例えば、商品マスタデータは「１０」、顧客マスタデータは「２０」、顧客単価マスタデータは「３０」、在庫マスタデータは「４０」、販売マスタデータは「５０」等として、テーブルＩＤの値として格納することができる。このように、テーブルＩＤにより、読込対象のデータを格納する各テーブルのデータ定義（即ち、当該テーブルのデータ項目）が一意に特定される。即ち、テーブルＩＤは、管理対象データ（読込データ）を格納するテーブルのデータ定義（データフォーマット）を一意に示すものであり、各データフォーマットの管理対象データに対して一意に割り当てられるコードである。要するに、テーブルＩＤは、管理対象データのテーブルが異なるごとに、即ち、データフォーマットの異なるデータごとに、一意のコードとして割り当てられる。例えば、本事例のデータ管理システムのように、商品マスタテーブル、顧客マスタテーブル、顧客単価マスタテーブル、在庫マスタテーブル、販売マスタテーブル等の異なるデータフォーマットの管理対象データを読込んで格納及び管理する場合、それら複数のデータフォーマットに対応して、それぞれ、一意のテーブルＩＤを付与して列管理テーブルに格納することになる。
【００３１】
前記枝番は、あるテーブルＩＤのテーブルに関連付けた（同一階層、下位階層等の）別のテーブルが存在する場合に、それらのテーブル間の関係を示すためのコードである。例えば、商品マスタテーブルは、商品情報（商品の属性を表す各種データ）を格納して管理するものであるが、商品情報を管理するために、互いに関連する複数の商品情報関係のテーブル（商品情報テーブル群）を用意することも多い。この場合、狭義の「商品マスタテーブル」以外に、例えば、当該商品マスタテーブルと関連付けた「商品＊＊テーブル」といった１以上のテーブルが存在する。よって、枝番は、このような場合に、特定のテーブルＩＤにより示されるテーブルについて関連付けた別テーブルが存在することを示すための情報、或いは、テーブルをグループ分けするための情報として使用する。具体的には、枝番が「０」の場合（図９の場合）、対応するテーブルＩＤのテーブルに関連するテーブルは存在しないことを示す。なお、枝番が「０」以外の「１」等の場合、即ち、対応するテーブルＩＤのテーブルに関連付けたテーブルがある場合、そのテーブルＩＤ及び枝番（複合キー）により、読込対象のデータを格納する各テーブルのデータ定義（即ち、当該テーブルのデータ項目）が一意に特定される。この場合、テーブルＩＤは、それらの関連付けた複数のテーブル群を一意に示すＩＤとなる。或いは、枝番は、管理対象データのレコードが階層構造を有する場合に利用することもできる。例えば、受発注業務における発注データのように、「ファイルヘッダレコード（上位階層）」、「伝票ヘッダレコード（中位階層）」、「伝票明細行レコード（下位階層）」からなる３階層のデータ構造を有する場合、最上位階層の「ファイルヘッダレコード」の各データ項目（各フィールド）には最上位の値（例えば、「１」）を、その次の階層の「伝票ヘッダレコード（中位階層）」の各データ項目には最上位の値の下位であることを示す中位の値（例えば、「２」）を、その次の階層の「伝票明細行レコード（下位階層）」の格データ項目には中位の値の更に下位であることを示す最下位の値（例えば、「３」）を割り当てて格納し、データ内におけるレコードの階層を識別できるようにすることもできる。なお、２階層構造や４階層以上の構造の場合にも同様にして「階層」に値を格納することができるが、上記以外にも、各階層を識別する任意の値を割り当てて格納することができる。更に、全てのテーブルについて、関連付けてグループ化される他のテーブルがない場合は、枝番のデータ項目を省略してもよい。
【００３２】
図９の列ＩＤは、上記図１〜図３の列ＩＤに対応するものであり、前記データ種類、テーブルＩＤ及び枝番を複合したものの末尾に、各テーブルの各データ項目を一意に特定するコード（連番の数字やアルファベット等）を予め割り当てて構成されている。具体的には、図９の例では、テーブルＩＤ「商品マスタテーブル」のデータ項目名「商品ＩＤ」に割り当てた列ＩＤ「１２０１００１」の場合、データ種類「１２０１」、テーブルＩＤ「商品マスタ」及び枝番「０」を複合したもの（１２０１０）の末尾に、当該データ項目を一意に示す数字（０１）を付加して構成される（結果、１２０１＋０＋０１＝１２０１００１となる）。なお、上記のように、図９の列管理テーブルでは、説明の便宜上、テーブルＩＤは、実際のコードではなくテーブル名として例示されているため、列ＩＤにはテーブルＩＤ部分は反映（付加）されていない。しかし、実際には、例えば、商品マスタのテーブルＩＤを「１０」とした場合、列ＩＤは、１２０１（データ種類）＋１０（テーブルＩＤ）＋０（枝番）＋０１（連番）＝１２０１０１００１となる。また、連番は、管理対象データの各レコード（例えば、商品マスタテーブルの各レコード）について、当該レコード内におけるデータ項目（フィールド）の出力順序や表示順序を示すものである。例えば、商品マスタテーブルの場合、そのデータ項目である「商品ＩＤ」、「商品名」、「単価」・・・の項目値の出力順序に対応して、連番の値として「１」、「２」、「３」・・・（連続値）が格納される。ここで、図９の例では、列ＩＤの末尾の数字と連番の数字が一致しているが、これは、列ＩＤの末尾に連番の値を割り当てることを意味するものではない。即ち、列ＩＤの末尾の数字乃至コードは、同一のデータフォーマットを有するレコードの各データ項目に対して一意に割り当てられものであり、必ずしも、当該レコードのデータ項目値の出力順序と一致しない。例えば、当該レコードのデータ項目を追加、削除、変更した場合、これに対応して、列ＩＤも追加、削除、変更されることになるため、当該レコード内における列ＩＤの末尾の数字は、必ずしも、当該レコードのデータ項目の並び順を示すものではない。これに対し、連番は、当該レコードのデータ項目の並び順に完全に対応し、当該並び順でデータ項目値を出力するために使用される。ただし、列ＩＤの末尾に連番を自動的に付与して各読込レコードの項目値を特定することも無論可能であり、この場合、列ＩＤ自体の管理は容易となる。しかし、その後のデータ項目の追加、削除、変更等の保守を容易化する等の点から、各読込レコードの項目値を一意に特定するために列ＩＤの末尾には、連番と無関係なコードを付与することが好ましい。次に、「データ項目名」は各列ＩＤに対応付けたデータ項目の名称を、「データ型」は当該データ項目のデータ型を、「位置」は当該データ項目のレコード先頭からの位置（何バイト目か）を示す。また、「最大長」及び「最小長」は当該データ項目の最大バイト数及び最小バイト数を格納する。
【００３３】
このように、図９の列管理テーブルは、図４〜図８の各テーブルのデータ項目（カラム）の項目名（「商品ＩＤ」、「商品名」・・・）を、順番に、自身のデータ項目としてではなく、データ項目値として格納する。また、列管理テーブルは、各テーブルのデータ項目の各値（データ項目名）に対応して、データ種類の値（「１２０１」、「１２０１」・・・）、テーブルＩＤの値（「商品マスタ」・・・）、枝番の値、連番の値（「１」、「２」・・・）、列ＩＤの値（「１２０１００１」、「１２０１００２」・・・）等を格納する。即ち、本事例では、管理対象の全てのテーブルのデータ項目が、一つの列管理テーブル内にデータ項目値として定義して格納される。これにより、一つの列管理テーブルを使用して、全ての管理対象データのデータフォーマット（全テーブルのデータ定義乃至スキーマ）を解析、参照、判断等することができる。
【００３４】
図１０は本発明の実施の形態１に係るデータ管理システムの行管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで、行管理テーブルに所定のデータを格納した状態を示す。
図１０に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムでは、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに、当該読込レコードに一意のインデックス（行ＩＤ）を付与すると共に、当該読込レコードから識別子を取得して、それらを行管理テーブルに格納する。詳細には、行管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「識別子名」、「識別子値」等を定義している。このうち、行ＩＤは、上記のように、管理対象データの読込レコード（１レコード）ごとに自動生成される一意の（ユニークな）ＩＤであり、任意のコード（英数字等）から構成することができる。なお、図１０の例では、「行ＩＤ」の値として「ＳＹＳ００１」、「ＳＹＳ００２」・・・という英数字の組合せを使用しているが、行ＩＤの値は、各読込レコードを一意に識別可能であればよく、例えば、データの読込日時（年月日時分秒）等の任意のコードから構成することができる。また、図１０の行管理テーブルの「データ種類」及び「テーブルＩＤ」は、図９の列管理テーブルの「データ種類」及び「テーブルＩＤ」に対応する。即ち、行管理テーブルは、読込レコードに固有の（列管理テーブルにより定義された）データ種類の値及びテーブルＩＤの値を各行ＩＤに対応付けて格納している。更に、行管理テーブルの識別子名は、読込レコードから取得した識別子（商品ＩＤ等）の名称であり、識別子値は当該識別子の値である。例えば、行管理テーブルは、商品マスタデータを読込む場合、識別子として、各読込レコード内の商品ＩＤ、即ち、商品テーブルの各行に格納された一意の商品ＩＤ（「４９０１」、「４９０２」等）を格納する。商品ＩＤをこの識別氏は、行ＩＤに１対１の関係で対応付けられている。よって、行管理テーブルを参照することで、特定の識別子を有する各読込レコード（格納レコード）が、どの行ＩＤを有するかを容易に特定することができる。なお、読込レコードのインデックスが複合キーからなる場合（例えば、顧客単価テーブルのように、商品ＩＤ＋企業コードからなる場合)、行管理テーブルに格納する識別子も、当該複合キーからなる識別子とする。
【００３５】
ここで、図１０の例では、行管理テーブルは、読込レコードのデータ項目のうち、当該レコード自体の識別子でもある「インデックス名」（商品マスタデータの商品ＩＤ「４９０１」等）を格納している。しかし、行管理テーブルは、各読込レコードに対して一意に付与される行ＩＤを少なくとも格納すればよい。即ち、行管理テーブルは、識別子を格納しない構成とすることも可能である。一方、行管理テーブルは、読込レコードのデータ項目値（フィールド値）のうち、識別子として利用する項目値以外にも、代表的（基本的）なもの（基本項目値）を格納するようにしてもよい（例えば、商品マスタテーブルの商品名、単価等）。こうすると、これらの基本項目値を行管理テーブルから抽出し、出力情報として迅速に出力することができ、データ出力に活用することができる。即ち、この場合、行管理テーブルは、識別子に加えて、読込レコードの１以上の基本項目値を格納し、所望の基本項目値を行ＩＤや識別子等を検索キーとして抽出し、所望のフォーマット（表示形式）で出力（印刷、画面表示）等することにより、そのデータの活用を図ることができる。この場合、列管理テーブルにおいて、項目値として格納した各管理対象データのデータ項目のいずれか１以上を、「基本項目値」としてフラグ等により指定することにより、各データのレコード読込時に指定した基本項目値を自動抽出するようにすることができる。例えば、列管理テーブルに、基本項目値としての順番を指定する「基本項目値指定順序」をデータ項目として定義し、列管理テーブルに格納した管理対象データのデータ項目のうち、基本項目値として利用したいものに対し、「基本項目値指定順序」の値としての連番（「１」、「２」・・・）を付与する。
【００３６】
図１１は本発明の実施の形態１に係るデータ管理システムの第１の具体例の値管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで全ての値を格納した状態を示す。
図１１に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムは、値管理テーブルとして例えば図１１の構成を採用する。この第１の具体例の値管理テーブルによれば、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに（詳細には、１レコードの１フィールドずつ読込むごとに）、当該読込レコードに前記行ＩＤ及び前記列ＩＤ等が付与され、読込んだデータ項目値が、それら行ＩＤ及び列ＩＤに対応付けられて行管理テーブルに格納される。詳細には、図１１の値管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「列ＩＤ」、「値」等を定義している。「行ＩＤ」は、前記行管理テーブルの「行ＩＤ」に対応し、「データ種類」、「テーブルＩＤ」及び「列ＩＤ」は、前記列管理テーブルの「データ種類」、「テーブルＩＤ」及び「列ＩＤ」に対応する。そして、上記のように、管理対象データの各レコードを読込むごとに、当該レコードに一意の行ＩＤが発行付与されて行管理テーブルに順に格納されるが、これと同時に、各読込レコードの全フィールド値（全項目値）に対し、当該読込レコードの行ＩＤ（ＳＹＳ００１、ＳＹＳ００２・・・）が対応して格納される。なお、当然、同一読込レコードについては、全てのフィールド値（項目値）に対して同一の行ＩＤが付与される。
【００３７】
また、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列管理テーブルに定義した当該読込レコードのデータフォーマット（管理対象データのデータ定義）にしたがって、読込レコードのフィールド値（項目値）が、定義された当該管理対象データのデータ項目に１対１で対応付けられ、順番に値管理テーブルの値として格納される。そして、当該格納レコード（各行に格納された項目値乃至フィールド値）に対して、対応する列ＩＤの値が付与されて格納される。例えば、商品マスタデータのレコード読込時には、列管理テーブルの商品マスタ部分が参照され、当該部分の列ＩＤ（「１２０１００１」、「１２０１００２」、「１２０１００３」・・・）に基づき、読込レコードのフィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、列管理テーブルに定義したデータ項目（「商品ＩＤ」、「商品名」、「単価」・・・）と対応付けて分割され、行管理テーブルの各行の値として格納される。このように、図１１の第１の具体例に係る値管理テーブルでは、一行に一つの値（フィールド値）を格納するようにしている。一方、上記のように、列ＩＤの末尾に連番を自動的に付与して読込レコードの項目値を一意に識別するようにした場合、列管理テーブルの読込レコード対応部分が参照され、当該部分の列ＩＤの末尾の連番（「１」、「２」、「３」・・・）の順番で、（詳細には、当該列ＩＤを構成するデータ種類＋テーブルＩＤ＋枝番＋連番のうちの連番を参照してその連番の順番で）、読込レコードのフィールド値が、列管理テーブルに定義したデータ項目と対応付けて分割され、各行の値として格納される。このように、図１１の第１の具体例に係る値管理テーブルでは、一行に一つの値（フィールド値）を格納するようにしている。また、この第１の具体例は、行管理テーブルの行ＩＤと列管理テーブルの列ＩＤとにより一意に決定されるセル（一つの値セル）に、対応する読込レコードのフィールド値（データ項目値）を格納するものとして把握することもできる。なお、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列ＩＤ以外にも、上記データ種類やテーブルＩＤが対応付けて格納されるが、これらデータ種類やテーブルＩＤの格納は省略することもできる。
【００３８】
図１２は本発明の実施の形態１に係るデータ管理システムの第２の具体例の値管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで全ての値を格納した状態を示す。
図１２に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムは、値管理テーブルとして例えば図１１の構成を採用する。この第１の具体例の値管理テーブルによれば、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに（詳細には、全フィールドからなる１レコードを読込むごとに）、当該読込レコードに前記行ＩＤと前記データ種類及びテーブルＩＤとを付与して、各読込レコードの全てのデータ項目値（フィールド値）を一行に格納するものである。詳細には、図１２の値管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「列ＩＤ」、「値」等を定義している。「行ＩＤ」は、前記行管理テーブルの「行ＩＤ」に対応し、「データ種類」、「テーブルＩＤ」及び「列ＩＤ」は、前記列管理テーブルの「データ種類」、「テーブルＩＤ」及び「列ＩＤ」に対応する。そして、上記のように、管理対象データの各レコードを読込むごとに、当該レコードに一意の行ＩＤが発行付与されて行管理テーブルに順に格納されるが、これと同時に、各読込レコードに対し、当該読込レコードの行ＩＤ（ＳＹＳ００１、ＳＹＳ００２・・・）が対応して格納される。
【００３９】
また、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列管理テーブルに定義した当該読込レコードのデータフォーマット（管理対象データのデータ定義）にしたがって、読込レコードのフィールド値（項目値）が、定義された当該管理対象データのデータ項目に１対１で対応付けられ、順番に値管理テーブルの値として格納される。そして、当該格納レコードの全ての項目値乃至フィールド値に対して、対応するデータ種類及びテーブルＩＤの値が付与されて格納される。例えば、商品マスタデータのレコード読込時には、列管理テーブルの商品マスタ部分が参照され、当該部分のデータ種類（「１２０１」）及びテーブルＩＤ（「商品マスタ」）に基づき、読込レコードの全フィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、行管理テーブルの値に一連で格納される。このとき、上記第１の具体例の値管理テーブルの場合のように、列管理テーブルの列ＩＤを参照して、読込レコードのフィールド値を分割して、値管理テーブルの一行の値の各格納部（分割区域）にそれぞれ格納することができる。また、このとき、列ＩＤを参照し、読込レコードのフィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、列管理テーブルに定義したデータ項目（「商品ＩＤ」、「商品名」、「単価」・・・）と対応付けて格納される。このように、図１２の第２の具体例に係る値管理テーブルでは、一行に一つのレコード（全フィールド値）を格納するようにしている。また、この第２の具体例は、行管理テーブルの行ＩＤと列管理テーブルのデータ種類及びテーブルＩＤとにより一意に決定される一つのセル（「値」の各セル）に、対応する読込レコードの全フィールド値（全データ項目値）を格納するものとして把握することもできる。即ち、データ種類及びテーブルＩＤにより、各読込レコードのデータフォーマット（詳細には、各読込レコードの全データ項目）を特定することができ、データ種類及びテーブルＩＤを、各読込レコードのデータフォーマットを特定するためのＩＤ（複合キー）として使用することができる。なお、第２の具体例の値管理テーブルでは、一行に全てのフィールド値を格納するため、前記列テーブルの「連番」はデータ項目として不要である。また、値管理テーブルの列ＩＤは、各行の読込レコード単位では関連付けられていないため、値として「ＮＵＬＬ」が自動的に格納されている。
【００４０】
実施の形態２
図１３は本発明の実施の形態２に係るデータ管理システムとしての受発注管理システムの構成を概略的に示すブロック図である。図１４は本発明の実施の形態２に係るデータ管理システムを受発注管理システムに具体化した場合のデータ構造を概略的に示す説明図である。
【００４１】
実施の形態２に係るデータ管理システムは、上記実施の形態１に係るデータ管理システムを、受発注管理システム２０に具体化したものである。受発注管理システム２０は、前記列管理テーブル１１に相当する列管理テーブル２１と、前記行管理テーブル１２に相当する行管理テーブル２２と、前記値管理テーブル１３に相当する値管理テーブル２３とを備える。なお、受発注管理システム２０は、各発注企業について、発注企業が送信する発注データ、受領データ、支払いデータ等の送信データ（送信レコード）のデータフォーマットをマスタデータとして格納する企業別のテーブル管理テーブル（図１３では図示略）と、各発注企業の送信データを、標準データフォーマットまたは受注企業のデータフォーマットのデータに変換するためのリンク情報を格納するデータ交換管理テーブル（図１３では図示略）とを更に備える構成としても良い受発注管理システム２０は、発注企業の送信データ、例えば、データフォーマットが異なる複数企業の発注データ（図１３では甲社発注データ３１、乙社発注データ３２を例示）を取り込むと、列管理テーブル２１において該当する企業のデータ定義（データフォーマット）を参照し、行管理テーブル２２に当該発注データの各読込レコードの識別子を行ＩＤと共に格納すると共に、値管理テーブル２３に読込レコードの全項目値を行ＩＤ及び列ＩＤと共に格納する。即ち、受発注管理システム２０は、列管理テーブル２１に定義された該当企業の発注データの各レコードのデータフォーマットにしたがって、当該企業の発注データ（甲社発注データ３１、乙社発注データ３２）を整形（分割、並び替え等）する。そして、受発注管理システム２０は、発注データ３１〜３２の一レコードを読み込むごとに、当該読込レコードに行ＩＤを発行すると共に、当該読込レコードに含まれるインデックスデータ（例えば伝票ＮＯ．や伝票明細行ＮＯ．）を識別子として行管理テーブルに格納する。このとき、上記のように、受発注管理システム２０は、読込レコードのそれ以外の基本項目値（例えば、商品名、発注数量等）を行管理テーブル２２に格納してもよい。また、受発注管理システム２０は、発注データ３１〜３２の一レコードを読み込むごとに、列管理テーブルに定義した当該読込レコードのデータフォーマットにしたがって、当該読込レコードの全データ項目値を値管理テーブル２３に格納すると共に、当該読込レコードに行ＩＤ及び列ＩＤを付与する。このとき、上記のように、値管理テーブル２３の一行に各読込レコードの一項目値を格納する場合は、各行に一意の列ＩＤが割り当てられる。一方、値管理テーブル２３の一行に各読込レコードの全項目値を格納する場合は、各行に一意の列ＩＤは割り当てられず、当該読込レコードのデータフォーマットを特定できるコード情報（データ種類＋テーブルＩＤ等）が割り当てられる。
【００４２】
一方、受発注管理システム２０は、送信データとして、例えば、データフォーマットが異なる複数企業の納品予定データ（図１３では丙社納品予定データ３３、丁社納品予定データ３４を例示）を取り込むと、上記発注データの場合と同様にして、列管理テーブル２１において該当する企業のデータ定義（データフォーマット）を参照し、行管理テーブル２２に各読込レコードの識別子を行ＩＤと共に格納すると共に、値管理テーブル２３に読込レコードの全項目値を行ＩＤ及び列ＩＤと共に格納する。ここで、受発注管理システム２０は、前記行管理テーブル２２や値管理テーブル２３に格納した項目値を所望の複数の表示フォーマットで表示または出力する単一の表示（出力）プログラム（ＰＧ）を備えている。そして、受発注管理システム２０は、ユーザーの要求にしたがって、列管理テーブル２１の定義情報を参照して、行管理テーブル２２に格納した識別子をキーとして、行管理テーブル２２に格納した基本項目値（伝票ＩＤ、梱包ＩＤ等）を抽出し、所定のフォーマットで出力（モニタ画面１に表示等）する。また、受発注管理システム２０は、ユーザーの要求にしたがって、列管理テーブル２１の定義情報を参照して、値管理テーブル２３に格納したデータ項目値（伝票明細、梱包明細等）の必要な項目値を抽出し、所定のフォーマットでモ出力（モニタ画面１に表示等）する。
【００４３】
ここで、受発注管理システム２０の具体的なテーブル構造を説明すると、図１４に示すように、受発注管理システム２０は、上記図２及び図３により説明した実施の形態１の場合と同様のデータ処理により、送信データ（発注データ等）のデータフォーマットにしたがって、当該送信データの各データ項目（データ定義）を、列管理テーブル２１にデータ項目値として格納している。また、受発注管理システム２０は、トランザクションデータとして、行管理テーブル２２に、行ＩＤ、識別子等を格納し、値管理テーブル２３に、伝票明細ＩＤ、商品ＩＤ、商品名等の全データ項目値を格納している。そして、受発注管理システム２０は、表示（出力）プログラム２６により、列管理テーブル２１の定義情報を参照して、行管理テーブル２２に格納した基本項目値（伝票Ｎｏ．等）を所定フォーマットで出力したり、値管理テーブル２３に格納した全データ項目値のうちの必要な項目値（商品ＩＤ、商品名等）を出力したりする。即ち、このとき、受発注管理システム２０は、表示（出力）プログラム２６により、発注データの場合は、図１３に示す受注一覧テーブル３５、受注明細テーブル３６等に所定のフォーマットで所定の項目値を表示し、納品予定データの場合は、図１３に示す納品予定テーブル３７、梱包明細テーブル３８等に所定のフォーマットで所定の項目ちを表示する。なお、これ以外にも、受発注管理システム２０は、表示（出力）プログラム２６により、各種テーブルを表示することもできる。例えば、伝票一覧テーブル（図示略）は、行管理テーブル２２に格納した基本項目値（伝票ＮＯ．発注日等）のみを使用して、伝票一覧を迅速に表示する。また、伝票明細表示テーブル（図示略）は、伝票一覧テーブルの任意の行を選択実行することにより、その行の伝票ＩＤに対応する伝票明細行の各種項目値を値管理テーブル２３から抽出し、その行の伝票番号の伝票明細の詳細を表示する。ここで、行管理テーブル２２からのデータ項目値の抽出のためのキーとしては、識別子以外に、行ＩＤを使用することもできる。
【００４４】
詳細には、図１４に示すように、受発注管理システム２０において、列管理テーブル２１は、図１４に示すデータを管理対象とする場合、甲社発注データのデータ項目（伝票ＩＤ、ＧＴＩＮ、商品名、個数）、乙社発注データのデータ項目（伝票ＩＤ、ＧＴＩＮ、個数、納期）、丙社発注データのデータ項目（伝票ＩＤ、商品ＩＤ、個数、単価）、丁社発注データのデータ項目（伝票ＩＤ、商品名、商品ＩＤ、個数）を一意の列ＩＤ（１，２，３，４・・・）に対応付けて格納している。また、図１４の各テーブル中、属性名の右横のカッコ内の英字（アルファベット）が同一のものは、データ項目が同一であることを意味する。これにより、列管理テーブル２１を参照することで、管理対象データのテーブル名に加えて、当該テーブルのデータ項目を判断することができる。例えば、甲社発注データについては、列ＩＤの「１〜４」に対応して、属性名として「伝票ＩＤ、ＧＴＩＮ、商品名、個数」が定義されているため、列ＩＤの「１〜４」を参照することで、管理対象データのテーブルが「甲社発注データ」であると判断でき、かつ、甲社発注データのデータ項目が「伝票ＩＤ、ＧＴＩＮ、商品名、個数」であると判断することができる。
【００４５】
また、受発注管理システム２０は、管理対象データの各レコードを読み込むごとに、行管理テーブル２２に一意の行ＩＤを割り当てて格納すると共に、当該読込レコードの特定のデータ項目値を識別子として格納する。例えば、甲社発注データのレコード（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード）を読み込む場合、行管理テーブル２２には、甲社発注データのレコード（一行）を読込むごとに行ＩＤ（１，２・・・）が発行され、行ＩＤに対応して読込レコードの特定の項目値が識別子として格納される。例えば、商品テーブルに関しては、伝票ＩＤ（甲１，甲２・・・）を識別子として行管理テーブル２２に格納することができる。なお、他のデータについても、同様に、各読込レコードに一意の行ＩＤが付与されると共に、各読込レコードの特定の項目値が識別子として取得され、行ＩＤと対応付けて格納される。
【００４６】
更に、受発注管理システム２０は、管理対象データの各レコードを読み込むごとに、各読込レコードをデータ項目の項目値ごとに分割し、分割したデータ項目値の全てに同一の行ＩＤを割り当てると共に、分割したデータ項目値に対応する列ＩＤを順に割り当てて、行ＩＤ、列ＩＤ及び値のセットで格納する。例えば、甲社発注データのレコード（「甲１、４９００１，ガム，１００」、「甲２、４９００２，飴，２０」・・・）を読み込む場合、受発注管理システム２０は、まず一行目のレコード（甲１、４９００１，ガム，１００）のデータ項目値を分割し、それら４つのデータ項目値に行ＩＤ（１）を割り当てると共に、それら４つのデータ項目値に対して列ＩＤ（１〜４）を順に割り当て、それらのデータセット（「」１，１，甲１、「１，２，４９００１」、「１，３，ガム」、「１，４，１００」を値管理テーブル２３に格納する。なお、他のデータについても、同様に、各読込レコードに一意の行ＩＤが付与される。２行目以降のレコードについても、各レコード読込時に、同様にして、行ＩＤ、列ＩＤ及び値の組が値管理テーブル２３に格納される。なお、他のデータについても、同様に、読込レコードの各データ項目値が、行ＩＤ及び列ＩＤと対応付けて格納される。
【００４７】
図１５は本発明の実施の形態２に係るデータ管理システムでデータ交換される発注データのデータ構造を示す説明図である。図１６は本発明の実施の形態２に係るデータ管理システムで使用する列管理テーブルの概略を示す説明図である。図１７は本発明の実施の形態２に係るデータ管理システムにより、発注データのレコードと、列管理テーブルに定義した当該発注データの各データ項目の属性との対応関係を示す説明図である。
【００４８】
図１５に示すように、入力データのレコードは、基本的に、ファイルヘッダ、伝票ヘッダ、伝票明細の３階層、或いは、ファイルヘッダ、伝票ヘッダの２階層で構成されている。この階層構造の関連付けは、入力データ内のレコードシーケンスによって示される為、本データ管理システムでは、この情報を、伝票ヘッダ単位にロー（ＲＯＷ）レコード（行管理テーブルにおける一行単位のレコード）を作成し、後述する列管理テーブルに各レコードの階層や親子関係を定義することで確保している。
【００４９】
また、図１５に示すように、本データ管理システムは、入力データを、レコード単位（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細レコード）に区切りながら順番に読込み、読込んだレコード内のレコード識別子を、後述するテーブル管理テーブルの制御情報を参照して判別し、読込レコード単位で行管理テーブルのレコードを新しく作成している。なお、読込レコードが伝票ヘッダレコードである場合に、行管理テーブルのレコードを新しく作成（キーＲＯＷ＿IDをインクリメント）し、論理的な伝票データ１枚分を格納する基礎レコードとしてもよい。この場合、行管理テーブルの１レコードは、論理的な伝票単位に作成される。なお、入力データの構造は、1レコード＝１伝票という単純な構造ではなく、１レコード＝複数伝票、複数レコード＝１伝票という場合もある。
【００５０】
列管理テーブルの別の一例を参照して説明すると、図１６に示すように、各種データを構成する各々のレコードは、企業が定めた独自フォーマットで作成されている。本データ管理システムでは、企業ごとに異なる独自フォーマットの内容を、列ＩＤ、テーブルＩＤ、連番（シーケンスＮｏ．）、項目名称、データ型、長さ等、データ項目単位で定義を行い、レコード単位にまとめてデータベースに格納している。図１６において、テーブルＩＤは、１０桁等の所定桁の企業別のデータフォーマット（即ち、管理対象となるテーブルのデータ定義）を一意に示す番号である。例えば、テーブルＩＤ＝企業ＩＤ（６桁）＋データ種類（２桁）＋任意の番号（２桁）で構成される。なお、任意の番号としては、前記「枝番」等を使用することができる。また、列ＩＤは、例えば１２桁の企業別のデータフォーマットを有する一レコード内の各データ項目を一意に示す番号である。例えば、列ＩＤ＝テーブルＩＤ（１０桁）＋任意のＮｏ（２桁）とすることができる。この場合、任意の番号としては、各データ項目に一意に割り当てた数字やアルファベットを使用することができる。本データ管理システムでは、電子商取引のある発注企業と受注企業との間で送受信される各種データを、先ずレコード単位に区切って順番に読み込み、テーブル管理テーブルを参照して、この企業別のデータフォーマットの内容を判断し、特定企業のデータフォーマットに合致したレコードを、列管理テーブルを参照してデータ項目毎に分解し、その値を取得して、行管理テーブルや値管理テーブルに格納する。このように、データ管理システムは、各発注企業が使用する独自のデータフォーマットを列管理テーブルに定義するが、更に、受注企業別に異なる（受注企業が必要とする）独自データフォーマットの内容も列管理テーブルに定義する。更にまた、データ管理システムは、本データ管理システム独自の標準フォーマット（或いは、ｅｂＥＸＭＬ等で提唱される標準フォーマット）の内容を列管理テーブルに定義する。本データ管理システムには、上記のように、３種類のデータフォーマット、即ち、絵種類の企業別データプロファイル（発注企業データプロファイル、受注企業データプロファイル、標準データプロファイル）を列管理テーブルに定義している。
【００５１】
図１７に示すように、本データ管理システムは、発注企業との間での送受信データを対象として、当該データについて１レコードずつ格納するポイントを定めて値管理テーブルに格納し、一部の項目値は行管理テーブルにも格納するが、実際は、図１７のレコードを構成するデータ項目に示すように、１レコードのデータを構成するデータ項目値（フィールド値）に分割して格納している。この方法によれば、重要なデータを効率良く格納し、かつ正確に取得することを実現するものであり、企業別データプロファイルを利用したデータの再変換や、障害時の迅速な伝票単位のデータ抽出に対応ができるし、また、電子帳簿保存法にも対処が可能となる。
【００５２】
図１８は本発明の実施の形態２に係るデータ管理システムに外部から発注データを取り込んで、当該発注データを行管理テーブル及び値管理テーブルに格納するデータ格納手順におけるデータフローを示すブロック図である。
【００５３】
図１８に示すように、本データ管理システムにおけるデータ格納手段４０は、受信データをデータベースに格納するため、発注企業より受信した入力データ（順次アクセスファイル）を解析し、各レコードの各データ項目値を抽出後、リレーショナルデータベースの値管理テーブル２３に格納している（一部は行管理テーブル２２にも格納）。即ち、まず、図１６に示すように、管理対象となる全てのレコードのデータフォーマットは、それぞれ、列管理テーブル２１に定義されている。各レコードは複数のフィールド（データ項目）の集まりであり、レコードはテーブルＩＤで一意に識別され、レコードを構成する各フィールドは、列ＩＤ、または、テーブルＩＤ単位の連番（シーケンスＮＯ．）で一意に識別される。そして、本データ管理システムは、読込んだ物理レコードを、合致するデータフォーマットの定義（図１６の列管理テーブル参照）を参照して分割し、各読み込みレコードのフィールド値を格納する。このとき、上記のように、システムのパフォーマンス（主に処理速度）向上を図るため、本来１フィールド値を１レコード（値管理テーブルの各行）に格納する以外に、本データ管理システムでは、１フィールド単位ではなく、１フォーマット定義単位（列管理テーブルのテーブルＩＤ単位）で全フィールド値をまとめて格納できるようにすることもできる。即ち、本来、値管理テーブルにおいて、列ＩＤと行ＩＤとの組み合わせで一意に決定される一つのセルに１フィールド値を格納する処を、テーブルＩＤと行ＩＤ）との組み合わせで一意に決定されるセルに複数のフィールド値をまとめて格納することもできる。しかし、物理的には１レコードに格納できるフィールドは有限個（例えば、３０個）とする為、該当するデータフォーマットの定義を構成するフィールドが有限個（３１）以上の場合は、当該テーブルのレコードを新たにひとつ増やして格納する必要が生じる。この場合、本データ管理システムは、後述するようなセルシーケンスＮＯ．を設ける事でデータ分割に対処することができる。
【００５４】
図１８では、データ管理システムは、発注データ３１の受信時（読込時）に、まず、データ交換管理テーブル２５を参照し、その発注データ３１について発注企業と受注企業との間での取引（受発注業務）が予定されているかどうかを判断し、取引が予定されている場合のみ、発注データ３１の読込を実行する。次に、データ管理システムは、上記のようにして、テーブル管理テーブル２４において当該企業の発注データに関するテーブルＩＤを参照して、発注データ３１をレコード単位に分割して読込む。図１８のデータ格納手段４０内に読込まれた発注データ３１は、レコード単位、即ち、ファイルヘッダレコード（ＦＬ２０・・・）、伝票ヘッダレコード（ＤＨ２０・・・）、複数の伝票明細行レコード（ＤＤ２０  砂糖  ・・・、ＤＤ２０チョコレート・・・）に分割されている。次に、データ管理システムは、列管理テーブル２１を参照し、当該発注企業のデータフォーマットに従って、発注データ３１の各読込レコードを項目値ごとに分割し、各読込レコードの識別子等を対応する一意の行ＩＤと共に行管理テーブル２１に格納する一方、各読込レコードの全項目値を対応する行ＩＤ及び列ＩＤ（またはテーブルＩＤ等の一レコードを特定するための情報）と共に値管理テーブル２３に格納する。なお、上記図１５の例では、読込レコードが伝票ヘッダレコードである場合に、行管理テーブルのレコードを新しく作成し、論理的な伝票データ１枚分を格納する基礎レコードとし、行管理テーブルの１レコードを、論理的な伝票単位に作成する事例を説明した。しかし、データ管理システムは、行ＩＤとして、管理対象データの各レコードを読込むごとに自動的に生成・付与されるインデックスを使用する場合、上記のように伝票ヘッダレコード単位ではなく、全てのレコード単位（ファイルヘッダレコード、各伝票ヘッダレコード、各伝票明細行レコード単位）で、行ＩＤを自動生成し、行管理テーブルの各行のインデックスとして格納する。一方、列ＩＤは、図１６及び図１７に示すように、１２桁の数字（０１２３・・・）により上記規則に則り作成され、管理対象データ（受発注データ）のレコード（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード等）の各データ項目（ファイルヘッダレコードの場合、レコード区分、ファイル種別、データ作成日等、伝票ヘッダレコードの場合、レコード区分、店舗コード、部門コード等、伝票明細行レコードの場合、レコード区分、品名、規格等）に一意に割り当てて使用される。
【００５５】
図１９は本発明の実施の形態２に係るデータ管理システムにより発注企業データプロファイルと受注企業データプロファイルとを標準データプロファイルを介してデータ交換する場合の手順を概略的に示す説明図である。図２０は本発明の実施の形態２に係るデータ管理システムにより、発注企業データの所定の項目値を表す発注企業データプロファイルの所定の列ＩＤから、当該発注企業データの項目値に対応する標準データの項目値を表す標準データプロファイルの所定の列ＩＤを介して、当該標準データの項目値に対応する受注企業データの項目値を表す受注データプロファイルの所定の列ＩＤを取得する手順を概略的に示す説明図である。
【００５６】
データの変換方法について説明すると、図１９に示すように、本データ管理システムは、発注企業別データプロファイルと、受注企業別データプロファイルと、標準データプロファイルとの３種類の企業別データプロファイルを列管理テーブルに定義している。この企業別データプロファイルは、電子商取引で交換される各種データを構成するレコードの其々について、その最小要素であるデータ項目の属性を細かく定義したものであり、マッピング作業を行うためのものである。標準フォーマットを使用したＥＤＩは、フォーマット変換作業のコスト削減を図る上では理想的である。したがって、本データ管理システムにおいても、発注企業別データプロファイルと標準データプロファイルとの間でマッピング作業を行い、かつ、標準データプロファイルと受注企業別データプロファイルとの間でマッピング作業を行う。こうすることにより、図１９のデータ変換概要に示すように、発注企業別データプロファイルと受注企業別データプロファイルとの間のマッピング作業を行わずに、標準データプロファイルを介して、発注企業別データプロファイルと受注企業別データプロファイルとの間の各データ項目間の関連情報を取得し、データ変換を実現することができる。また、図２０は、企業別データプロファイルの各データ項目間の関連情報が実際に格納されているテーブル（項目関連定義テーブル）の内容を概略的に示す。ここで、列ＩＤは、所定桁（例えば、１２桁）のデータ項目レコードを一意に示す番号である。
【００５７】
図２０の例では、発注企業（企業コード＝１１１１１１）から受信した発注データ（データ種類コード＝２０）を構成するファイルヘッダ・レコード(テーブルＩＤコード＝１１１１１１２０１０)の３番目のデータ項目（列ＩＤ＝１１１１１１２０１００３）を、標準（企業コード＝００００００）データプロファイルの発注（データ種類コード＝２０）ファイルヘッダ・レコード（テーブルＩＤコード＝２０１０）の４番目のデータ項目（列ＩＤ＝２０１００４）を仲介して、受注企業（企業コード＝９９９９９９）の受注データ（データ種類コード＝２０）のファイルヘッダ・レコード（テーブルＩＤコード＝９９９９９９２０１０）の２番目のデータ項目（列ＩＤ＝９９９９９９２０１００２）にデータ交換する際の処理の流れが示されている。図２０の表の右端のデータ変換関数は、データ変換をする際に使用される変換関数であるが、本データ管理システムでは、あらゆるデータ変換に対応できるよう、多くの関数が用意されている。図２０では、関数コード「１」はデータ格納を示し、前記発注企業の読込データ（発注データ）において列ＩＤ「１１１１１１２０１００３」を有するデータ項目の値（値管理テーブルに実際に格納された格納値）を、標準プロファイルの列ＩＤ「２０１００４」に格納し、当該標準プロファイルの列ＩＤ「２０１００４」に格納した前記データ項目の値を、前記受注企業が指定した形式（プロファイル乃至フォーマット）のデータにおいて列ＩＤ「９９９９９９２０１００２」を有するデータ項目の値として取得するという処理が、前記関数コードを利用して実行される。
【００５８】
図２１は本発明の実施の形態２に係るデータ管理システムによりデータ交換を行う際に、各企業間で項目値の意味や使用方法が異なる場合の処理に使用する項目値管理の概略を示す説明図である。
【００５９】
図２１にしたがって、データ変換時の課題と解決方法について説明する。データ変換をする際には、解決しなければならない様々な課題がある。本データ管理システムでは、これらの課題を以下のように解決する。まず、項目名称（異名同義語）について、発注企業独自のフォーマットには、さまざまなデータ項目名称が付けられている。本データ管理システムでは、これらのデータ項目に実際に代入されている値を検証し、データ項目名称が違っていても、データ項目値が同様と判断されたデータ項目間の関連定義を行っている。例えば、発注番号⇔伝票番号、部門コード⇔分類コードとして関連定義を行う。また、項目内容（同名異義語）については、項目名称の場合とは逆に、同じデータ項目名称であっても、実際の値が違うと判断された場合は、データ項目間に関連定義を行っていない。更に、本データ管理システムでは、商品コードについてはＧＴＩＮ（ＪＡＮコード）を使用することを原則とし、企業コードについては、共通取引先コード、標準企業コード、グローバルロケーションナンバー（ＧｌｏｂａｌＬｏｃａｔｉｏｎＮｕｍｂｅｒ）のいずれかを使用することを原則としている。しかし、ローカルな商品コードと、ローカルな企業コードについては、その変換をすることも可能である。例えば、商品コード（ＪＡＮコード）⇔商品コード（インストア）、企業コード（共通取引先コード）⇔企業コード（インストア）等である。次に、属性（データ型）の違いについては、本データ管理システムでは、データ項目間の関連定義がされている場合、自動的にその属性変換が行われる。原則的に、テキストは左詰め、数値は右詰めで格納される。例えば、数値⇔日付、テキスト⇔数値、日付⇔テキスト等である。次に、表示方法の違い、即ち、データ項目の表示方法については、オプション機能を利用することにより、０（ゼロ）サプレスや小数点位置の表示、区切文字の代入などあらゆる表記方法が可能である。例えば、電話番号：０３（４３２１）１２５６⇔０３−４３２１−１２５６等である。次に、桁数（レングス）の違いについては、長さの違うデータ項目間の関連情報が定義されている場合、データ変換をする際にデータが桁落ちする場合が生じる。本データ管理システムは、データ変換の際、実際のデータ項目値が桁落ちする場合に、警告メッセージを表示する。利用者は、受側のデータ項目の長さを変更して対処することが可能である。
【００６０】
また、本データ管理システムではＧＴＩＮコードに対応しているので、ＪＡＮコードを使用している場合は、頭の１桁に０（ゼロ）を付加して格納する。例えば、ＪＡＮコード（１３桁）⇔ＧＴＩＮコード（１４桁）等である。次に、ドメイン値（項目値の意味）については、データ項目値にコードが代入されている場合、そのコード体系は企業毎に定められている。本データ管理システムでは、これらのコード体系の意味変換を行う為に、さまざまなデータ項目について、その内容のシステム標準を定め、システム標準プロファイルとして格納している。利用者はこの標準プロファイルを介して、データ変換同様、コードの意味変換を行うことが可能である。例えば、Ａ企業の支払方法：１＝翌月、２＝翌々月で、Ｂ企業の支払方法：０＝翌月、１＝翌々月の場合等である。図２１では、９９９９９９２０１００２の支払方法が、ａ：翌月、ｂ：翌々月、ｃ：翌々翌月で、００００００２０１００４の支払方法が、ア：翌月、イ：翌々月、ウ：翌々翌月であり、１１１１１１２０１００３の支払方法が、０：翌月、１：翌々月、２：翌々翌月であり、０⇒ア⇒ａ、１⇒イ⇒ｂ、２⇒ウ⇒ｃとなる。即ち、図２１の項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルでは、受注企業（企業コード＝９９９９９９）の受注データ（データ種類コード＝２０）のファイルヘッダ・レコード（テーブルＩＤ＝９９９９９９２０１０）の２番目のデータ項目（列ＩＤ＝９９９９９９２０１００２）が、当該受注企業の支払方法を表し、そのデータ項目の値として、「ａ」は翌月を、「ｂ」は翌々月を、「ｃ」は翌々翌月を意味する。また、発注企業（企業コード＝１１１１１１）から受信した発注データ（データ種類コード＝２０）を構成するファイルヘッダ・レコード(テーブルＩＤ＝１１１１１１２０１０)の３番目のデータ項目（列ＩＤ＝１１１１１１２０１００３）が、当該発注企業の支払方法を表し、そのデータ項目の値として、「０」は翌月を、「１」は翌々月を、「２」は翌々翌月を意味する。更に、標準（企業コード＝００００００）データプロファイルの発注（データ種類コード＝２０）ファイルヘッダ・レコード（テーブルＩＤ＝２０１０）の４番目のデータ項目（列ＩＤ＝２０１００４）が、当該標準データプロファイルの支払方法を表し、そのデータ項目の値として、「ア」は翌月を、「イ」は翌々月を、「ウ」は翌々翌月を意味する。この場合に、実施の形態２のデータ管理システムは、上記データ変換時に、図２１の項目値管理テーブルを参照して、発注企業プロファイルのデータ項目の値「０」を、標準データプロファイルのデータ項目の値「ア」を介して、受注企業プロファイルのデータ項目の値「ａ」に自動的に変換し、発注企業プロファイルのデータ項目の値「１」を、標準データプロファイルのデータ項目の値「イ」を介して、受注企業プロファイルのデータ項目の値「ｂ」に自動的に変換し、発注企業プロファイルのデータ項目の値「２」を、標準データプロファイルのデータ項目の値「ウ」を介して、受注企業プロファイルのデータ項目の値「ｃ」に自動的に変換する。このように、受注企業の指定した形式のデータのデータ項目値が、発注企業のデータ項目値と異なる意味や異なるコード体系を有���る場合でも、標準データプロファイルを介してその相違を吸収することができる。
【００６１】
図２２は本発明の実施の形態２に係るデータ管理システムに新規な発注企業データプロファイル及び当該発注企業プロファイルと標準データプロファイルとのリンク情報を取り込んで、当該新規な発注企業データプロファイルに基づきデータを表示及び出力する場合のプロファイル取り込み・表示・出力手順におけるデータフローを示すブロック図である。
【００６２】
図２２に示すように、実施の形態２に係る受発注管理システム２０のプロファイル取り込み手段５０は、ネット上等に置かれたプロファイル管理システムで逐次作成した新たな企業のデータプロファイルを、ネットワークＮＴを介して、列管理テーブル２１に取得して、列管理テーブル２１を更新する。同時に、新たな企業の（独自の）データプロファイルと標準データプロファイルとの間のリンク情報も、ネットワークＮＴを介して、項目関連定義テーブル２７に取得して格納され、項目関連定義テーブル２７が更新される。即ち、受発注管理システム２０は、項目関連定義テーブル２７を更に備え、発注企業のデータプロファイルと標準データプロファイルとの間の定義リンク情報を格納すると共に、標準データプロファイルと受注企業のデータプロファイルとの間の定義リンク情報も格納する。そして、定義情報及びリンク情報に基づき、行管理テーブル２２や値管理テーブル２３からの項目値が、表示プログラム２６を介して、所定のフォーマットで、モニタ画面１や帳表２に出力される。なお、前記リンク情報５２が更新して格納される項目関連定義テーブル２７は、図２０の項目関連定義テーブルに相当する。即ち、前記リンク情報５２のトリガ列ＩＤは、図２０の企業別データプロファイルの列ＩＤに相当し、リンク情報５２の対象列ＩＤは、図２０の標準データプロファイルの列ＩＤに相当し、リンク情報５２の関数ＩＤは、図２０のデータ変換関数コードに相当する。よって、図２２の例でも、列管理テーブル２１のカラム定義（発注企業独自のデータプロファイル）に従って値管理テーブル２３に格納した発注データを、図２０の場合と同様にして、項目関連定義テーブル２７のリンク情報（発注企業データプロファイル、標準データプロファイル、受注企業データプロファイルの各データ項目間のリンク情報）を参照して、受注企業の指定するデータ形式のデータに変換し、帳票形式で出力したり、画面１に所定形式で画面表示したりすることができる。
【００６３】
図２３は本発明の実施の形態２に係るデータ管理システムにより各種データを出力するデータ出力手順におけるデータフローを示すブロック図である。
データ管理システムは、データ出力において、値管理テーブル２３（一部の出力では、行管理テーブル２２を利用）に格納されているレコードを読み込み、予め指示されている指定内容の出力データを作成する。データ管理システムは、指示内容として、発注企業伝票データ６１、業界標準データ（システム標準データ）６２、受注企業指定データ６３を指定可能である。また、データ管理システムにおけるデータ作成は、同様の処理を伝票枚数分繰り返した結果、その内容をまとめて指定されたファイル名で出力するものとすることもできる。ここで、出力データの作成の詳細について説明すると、データ管理システムは、値管理テーブル２３に格納されている（発注企業から受信した）各レコードの項目値から、指定された各種データを作成する。また、データ管理システムは、必要に応じて、行管理テーブル２２に格納されているレコードを読み込み、伝票一覧（データ種類別、発注企業別、日付範囲など）を画面上に出力し、更に、一枚の伝票が選択された際に、当該伝票の詳細内容の表示を行うようにすることもできる。この場合も、データ管理システムは、当該詳細表示内容としては、発注企業独自データ６１（デフォルト）、発注企業伝票データ、業界標準データ（システム標準データ）６２、受注企業指定データ６３を指定可能としている。そして、指定された表示内容から、データ管理システムは、列管理テーブル２１を参照し、表示すべきレコードのテーブルＩＤを判断して、テーブルＩＤにより特定したレコードに含まれる項目値の各々を、項目順に値管理テーブル２３から取得して、セットで表示する。なお、テーブルＩＤの判断は、テーブル管理テーブル２４により行うことも可能である。
【００６４】
ここで、値管理テーブル２３に格納されているのは、発注企業独自データ６１（デフォルトの発注企業オリジナルデータ）のみであるため、他の表示内容が選択された場合は、表示すべき各項目値を、図２０のテーブルに相当する項目関連定義テーブルを検索し、該当する発注企業独自データ６１の各値を取得して、表示指定されたテーブルＩＤのレコードの項目名称の各値として、セットで表示する。一方、発注企業独自データ６１（デフォルト）が指定された場合、データ管理システムは、テーブルＩＤで特定したレコードに含まれるデータ項目の項目順に従い、各々の値を値管理テーブル２３から取得して指定の表示態様で表示する。即ち、テーブルＩＤを検索キーとして値管理テーブル２３のレコード（該当行）を確定し、列ＩＤで示される順番に格納されている値をそれぞれ取得して、連番の表示順序でセットで表示する。詳細には、発注企業伝票データ、業界標準データ、受注企業指定データのいずれかが指定された場合、データ管理システムは、テーブルＩＤで特定したレコードに含まれる項目の項目順に従い、表示指定項目と発注企業独自データの対応する項目との間のリンク情報を項目関連定義テーブルから取得する。即ち、データ管理システムは、列ＩＤ（トリガ列ＩＤ）をキーとして項目関連定義テーブルのレコードを検索し、表示指定されたデータ項目に対応するオリジナルデータ（発注企業独自データ）のデータ項目が格納されている列ＩＤ（対象列ＩＤ）を取得する。具体的には、図２０で説明した方法で、表示指定された全てのデータ項目について、オリジナルデータの対応するデータ項目との間でのリンク情報を取得する。そして、データ管理システムは、表示指定されたデータ項目の全てを、それぞれ、取得したオリジナルデータのデータ項目に読替えた後、各々の読み替え後のデータ項目の項目値を値管理テーブル２３から取得する。即ち、データ管理システムは、テーブルＩＤ（列ＩＤでも可）を検索キーとして、表示指定されたデータのレコードについて値管理テーブル２３の格納行（セルレコード）を確定し、列ＩＤで示される順番に格納されている項目値を順次取得して、表示指定されたデータ項目の項目名称とセットで表示する。
【００６５】
実施の形態３
図２４は本発明の実施の形態３に係るデータ管理システムの構成をプロファイル管理システムと共に概略的に示すブロック図である。
【００６６】
図２４に示すように、実施の形態３に係るデータ管理システムは、上記実施の形態と同様のデータ交換システム１１０と、上記実施の形態２で述べたようなプロファイル管理システム１２０とを備える。データ交換システム１１０は、上記列管理テーブル１１，２１と同様の列管理テーブル１１１と、上記行管理テーブル１２，２２と同様の行管理テーブル１１２と、上記値管理テーブル１３，２３と同様の値管理テーブル１１３と、上記テーブル管理テーブル２４と同様のテーブル管理テーブル１１４と、上記項目関連定義テーブル２７と同様の項目関連定義テーブル１１７とを備える。一方、プロファイル管理システム１２０は、上記企業独自のデータフォーマット（企業別データプロファイル）を定義した列テーブルに相当する同様の＊社（Ａ社、Ｂ社・・・）データ項目定義テーブル１２２と、上記標準データフォーマット（標準データプロファイル）を定義する列管理テーブルに相当する標準データ項目定義テーブル１２１と、上記項目関連定義テーブル１１７と同様に、＊社独自データフォーマットと標準データフォーマットとの間のリンク情報を定義する項目関連定義テーブル１２３とを備えている。そして、実施の形態３に係るデータ管理システムは、ネットワークＮＴを介して各社から受信した各社独自フォーマットの一次データ（発注データ、商品データ等）について、テーブル管理テーブル１１４や列管理テーブルを参照して、全レコードの全項目値を行ＩＤ及び列ＩＤ（またはテーブルＩＤ）等と共に値管理テーブル１１３に格納すると共に、識別子等の一部の項目値を行ＩＤ等と共に行管理テーブル１１２に格納する。更に、新たな企業のデータプロファイルが追加された場合、プロファイル管理システム１２０が、かかる追加データプロファイルについて、＊社データ項目定義テーブル１２２を更新すると共に、当該更新されたデータフォーマットと標準データフォーマットとのリンク情報を、標準データ項目定義テーブル１２１を使用して作成し、項目関連定義テーブル１２３に格納する。そして、データ交換システム１１０が、かかる更新された企業独自のデータフォーマット定義及びリンク情報等をネットワークＮＴ経由で取得し、列管理テーブル１１１及び項目関連定義テーブル１１７を更新する。
【００６７】
実施の形態４
次に、本データ管理システムの開発コンセプトについて説明すると、ＤＩＹ業界に位置する受注企業のＥＤＩに対する投資は、益々増加するばかりである。電子商取引を前提条件とした商品の取引契約が年々増加するなか、消費者の求める商品を開発しているにも関わらず、ＥＤＩ環境への投資ができない中小企業は業界への参入を断念せざるを得ない。ＥＤＩの導入や運用に掛かるコスト削減を図ることは、受注企業の重要な課題なのである。この重要課題に対し、一つ一つの受注企業が個々に対処できるソリューションを提供するのではなく、業界全体としてのコスト削減を睨んだソリューションとして展開する事こそが、本電子データ変換システムの開発コンセプトである。ここで、ＤＩＹ業界全体に１０の発注（小売）企業と、１００の受注（卸や製造）企業が存在し、各企業間すべてにおいて電子商取引があると仮定する。まず、各企業間のＥＤＩすべてに標準フォーマットが使用された場合、発注企業は、フォーマット変換（独自⇔標準）プログラムが、１個×１０社＝１０個となり、受注企業は、フォーマット変換（独自⇔標準）プログラムが、１個×１００社＝１００個となり、業界全体に１１０個のフォーマット変換プログラムが存在することになる。次に、各企業間のＥＤＩすべてに独自フォーマットが使用された場合、発注企業は、フォーマット変換はしないので、０個×１０社＝０個となり、受注企業は、フォーマット変換（発注⇔受注）プログラムが、１０社分×１００社＝１，０００個となり、業界全体に１，０００個のフォーマット変換プログラムが存在することになる。このように、標準フォーマットを使用した場合は、独自フォーマットを使用した場合に比べ、必要となるフォーマット変換プログラムが、断然、少なくて済むことが分かる。
【００６８】
業界全体の実際の企業総数や電子商取引総数は正確には分からないが、マッピング作業に代表されるフォーマット変換プログラムの開発や運用に、ずいぶんとコストが掛かる事は、すでに説明した通りであるから、標準フォーマットを使用することにより、業界全体のＥＤＩに掛かるコストの大幅な経費削減が、できる事になる。例えば、発注企業：受注企業＝２００：２００ならば、４００：４０，０００で、実に９９％の削減。また、発注企業での独自⇔標準のフォーマット変換と、受注企業での標準⇔独自のフォーマット変換は、標準フォーマットさえ存在すれば、現在、電子商取引を行っている受注企業が取引のある複数の発注企業に対応してフォーマット変換を行っている事から鑑みれば、充分に実現が可能である。よって、例えば、ＣＩＩ標準フォーマットに現状に合ったカスタマイズを施し、上記二つのフォーマット変換を行う。特に、フォーマット変換を上記のように本データ管理システム（ＥＤＩＹ）により行うことにより、発注企業においては現状と全く変わるところがない。反対に、受注企業においては、取引のある複数の発注企業に対応した個々のフォーマット変換が無くなり、電子商取引を行う際に必要なＥＤＩ環境がデータの送受信のみに成っていることが分かる。本データ管理システムでは、業界に位置するすべての受注企業が現在持っている発注企業独自⇔受注企業独自のマッピング定義やフォーマット変換プログラムを移管してもらい、管理するわけではない。将来を睨んだＸＭＬ−ＥＤＩにも対応できる新たな業界標準フォーマットを策定し、この標準フォーマットを介してフォーマット変換を行うことで、発注企業の独自フォーマットの変更にも即座に対応可能な、業界全体の視点から無駄のないフォーマット変換システムを、全ての受注企業の代行として維持管理するものである。
【００６９】
図２５は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータを取引過程にしたがって示すデータフロー図である。図２６は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータの一覧及び構成を示す表である。図２７は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用する標準データのデータ構造を示すデータ構造図である。
【００７０】
図２５〜図２７にしたがって、本データ管理システムの管理対象データについて説明する。本データ管理システムの管理する主要対象データは、電子商取引のある発注企業と受注企業との間で送受信される各種データである。各種データは、１レコードの長さが定められた固定長テキストファイルであり、複数のレコードの集まりで構成されている。一般的に、レコードは、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの３種類がある。これは、電子商取引が、やはり伝票単位で行われている表れであり、発注（受注）情報、納品情報、受領情報は、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの３階層でデータが構成されている場合が多く、支払情報、請求情報は、ファイルヘッダ・レコード、伝票ヘッダ・レコードの２階層でデータが構成されている場合が多いようである。このレコードの階層構造の関連付けは、各種データ内のレコードシーケンスによって示される為、本データ管理システムでは、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの階層関連を確保しながら、レコード単位に分けて、データベースに格納する。図２５に示すように、本データ管理システムでは、電子商取引のある発注企業と受注企業間での業務フローを上図に示すように想定し、各取引企業間で交換される対象データを定めている。図２６はデータの一覧と構成を示す。各種データのレコード構成は、図２７の通りである。ファイルヘッダレコードは、全データのヘッダとして共用するレコードである。入荷予定（梱包）データのみが４階層であるが、他は３階層で構成されている。
【００７１】
次に、電子データ変換システム（本データ管理システム）の各機能を、以下の３つの視点から、送受信されるデータの取扱、データ変換時の課題と解決方法、流通業務フローに準じたデータ履歴の確保について、順に説明する。まず、送受信されるデータの取扱については、本データ管理システムの管理する主要対象データは、電子商取引のある発注企業と受注企業との間で送受信される各種データである。このデータを、どのように取り扱うべきかという視点から分析すると、以下の５種類に分類することができる。１番目は、受注企業が取り込むべきデータであり、「商品コード」や「発注数量」等、受注企業が出荷業務などの作業に必要不可欠なデータを指す。なお、本データ管理システムでは、受注企業のシステムで利用できるように、発注企業から受信したデータを受注企業が指定するフォーマットに変換し、データファイルとして出力する。受注企業はこのファイルをインポート等して、システムに各種データを取り込む必要がある。次に、２番目は、伝票に印字すべきデータであり、受注企業が、商品を出荷する際に添付する納品伝票の印字データを指す。本データ管理システムは、統一伝票（ＴＡ１型、ＴＡ２型等）を印刷することができる。また、納品伝票の印字内容や印字位置、印字方法は、発注企業が細かく指定している場合が多く、本データ管理システムではこの詳細な内容に付いても、発注企業毎に企業別データプロファイルに定義してあるので、データ変換を行う際に、自動的に納品伝票を印字することができる。勿論、発注企業からの発注数量を、在庫引当後の納品予定数量や、ピッキング作業後の納品確定数量に変更することも可能であるし、変更後の印字内容も、発注企業毎の企業別データプロファイルに定義してあるので、発注企業毎に指定された修正イメージで印刷することができる。３番目は、発注企業のみで利用されるデータであり、上記１番目及び２番目で使用しない、発注企業独自のデータを指す。このデータは、発注企業独自のシステムで利用される場合が多く、受注企業から発注企業へ返信するデータ項目に指定される場合が多く、データを持ち回る必要がある。本データ管理システムでは、発注企業から受信したオリジナルデータをすべて格納しているので、発注企業が指定する独自ファーマットの返信データに指定されているデータを、事前に受信したデータから必要時に抽出して使用する。４番目は、データ送信あるいはデータ構成を制御するデータであり、「データ種別」や「ファイル区分」、「中継センターコード」等、データ種類やデータ構造、通信制御データなどの制御データを指す。本データ管理システムでは、これらの制御データを分析し、データ構成やデータ関連などの整合性を確保し、システム内のデータベースに必要なデータを格納する。これらのデータは、原則的にはシステム利用者には開放されないが、発注企業から受信したオリジナルデータをすべて格納しているので、参照することは可能である。５番目は、上記分類の複数に価するデータであり、本データ管理システムでは、其々に分けて対処（上記参照）する。
【００７２】
図２８は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するデータベースのデータ構造を示すテーブル関連図である。図２９は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するデータベースのテーブル一覧を示す表である。
【００７３】
本データ管理システムで使用するデータベース（ＲＤＢ）のデータ構造について説明する。まず、企業管理（ＣＵＳＴＯＭＥＲ）テーブルは、本データ管理システムが対象とする各企業の情報を管理し、発注企業及び受注企業の諸情報を管理する。通常、発注企業側の情報は本データ管理システムの担当者が入力し、受注企業側の情報は、利用企業である受注企業側の担当者が入力する。なお、セキュアリティ確保のため、担当者のユーザ登録により、入力が可能となるようにしている。次に、データ交換管理（ＥＸＣＨＡＮＧＥ）テーブルは、各利用企業間のデータ交換に関連する情報をデータ種類毎に管理するものであり、企業間で交換されるデータ種類の諸情報を管理する。通常、これらの情報は、各利用企業の担当者が入力する情報である。次に、データ種類管理（ＤＡＴＡ＿ＫＩＮＤ）テーブルは、本データ管理システムで取扱うデータ種類を管理するものであり、発注〜請求〜支払いまでのデータ種類を管理する。データ種類管理テーブルは、テーブルのまとまりを示す。通常、これらの情報は、本データ管理システムの担当者が入力する。
【００７４】
次に、テーブル管理（ＴＡＢＬＥ）テーブルは、企業毎のデータ種類別の各種テーブルやレコードを管理するものである。テーブル管理テーブルにおける発注企業側の情報はシステム担当者が入力し、受注企業側の情報は利用企業担当者が入力する。ここで、テーブル管理テーブルは、レコード間の階層関係を維持して格納・管理するための仕組み（レコードサブＩＤ）を備える構成とすることもできる。例えば、テーブル管理テーブルに定義するテーブルＩＤは、企業コード８桁＋データ種別２桁＋レコードサブＩＤとすることができる。また、テーブル管理テーブルは、読込データの各レコードを特定してレコード単位で分割するためのレコード制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）を定義して格納している。このレコード制御情報は、例えば、当該レコードであることを指し示す項目値について、読込レコードにおける位置と内容とを記述する情報である。一例として、制御情報を［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝ＡＡＡ］とすることができる。ここで、「ＭＡＴＣＨ＿ＳＰ＝数字；」は、（複数フィールドからなる）読込レコードの特定の位置（マッチングするフィールドの開始位置）を示す位置情報であり、レコードの先頭（０）からのバイト位置を示す。また、「ＭＡＴＣＨ＿ＣＯＤＥ＝値；」は、読込レコードの特定の位置のフィールドの内容（値）を示す情報で、チェックする文字列コードを示す。上記のように、位置とその値のセットで制御情報を記述し、必要ならば、複数のセットで制御情報を記述することが可能である。また、以下の拡張記述も可能である。即ち、ＭＡＴＣＨ＿ＣＯＤＥを複数指定する場合は、例えば、［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝｛ＡＡＡ，ＢＢＢ，ＣＣＣ｝；］となる。この場合、読込レコードにおいて指定位置のフィールド値のコードが、「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」のいずれかであれば制御情報と合致し、当該読込レコードを特定することができる。なお、ＭＡＴＣＨ＿ＣＯＤＥに否定情報を指定する場合は、例えば、［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝ＮＯＴ｛ＡＡＡ，ＢＢＢ，ＣＣＣ｝；］となる。この場合、読込レコードにおいて、指定位置のフィールド値のコードが、「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」以外であれば制御情報と合致し、当該読込レコードを特定することができる。
【００７５】
次に、列管理（ＣＯＬＵＭＮ）テーブルは、本データ管理システムが対象とする各企業における各種データ情報を管理するものであり、テーブル管理テーブルで特定する各管理対象テーブル（管理対象レコード）を構成する各データ項目の属性、位置、長さ等を管理する。即ち、列管理テーブルは、各管理対象データのデータフォーマットを定義する。通常、発注企業側の情報は、本データ管理システムの担当者が入力し、受注企業側の情報は利用企業担当者が入力する。項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルは、列管理テーブルで定義した各データ項目のなかで、値と内容の変換が必要な際に、各データ項目に格納される値と該当する意味内容を管理するものである。即ち、項目値管理テーブルは、各企業のドメイン値を定義する。通常、発注企業側の情報は本データ管理システムの担当者が入力し、受注企業側の情報は利用企業担当者が入力する。行管理（ＲＯＷ）テーブルは、本データ管理システムに格納されたレコードの基本的な管理（表計算システムにおける行に当たる）情報を格納するものであり、読込んだデータのレコード単位の識別子と基礎データとを、入力データの何番目のレコードであるかを示す行ＩＤをキー項目として格納する。即ち、行管理テーブルは、レコードの識別子（ＩＤＥＮＴＩＦＩＥＲ）やレコード関連情報等を格納する。また、行管理テーブルは、検索項目（発注データと納品データとの間での突合処理等で使用）について、５つまでデータ内容から複写した値（突合値）を当該テーブル内に格納する。行管理テーブルは、格納レコード単位で各行を作成する。
【００７６】
値管理（ＣＥＬＬ）テーブルは、入力されたデータをレコード単位で格納するものであり、行管理テーブルの行ＩＤと列管理テーブルの列ＩＤとにより一意に示されるセルにデータ項目値を格納する。上記のように、値管理テーブルは、１レコードの内容をまとめて格納することも可能である。即ち、値管理テーブルは、入力データの何番目のレコードであるかを示す行ＩＤとそのレコードを解析した際に参照したテーブル管理テーブルのキー項目であるテーブルＩＤまたは列ＩＤが基本のキー項目になる。表計算の行と列の交差するポイントのセルにデータを格納するイメージである。本来、ひとつのセルにひとつの値を格納すべきであるが、パフォーマンス向上を図る為に、本データ管理システムでは１セルに多数の項目を格納できるようにすることもできる。この場合、１レコード内の項目が予定項目数以上の場合を想定し、セルシーケンスＮＯ．を設け、予定項目数以上の項目の値からは、新しいセルレコードを作成して格納する。項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルは、列管理テーブルに定義されて管理されている（異なるデータプロファイルの）データ項目間の関連定義（リンク）情報を管理する。即ち、項目関連定義テーブルは、トリガーとなる項目（トリガー列ＩＤ、即ち、図２０の例では発注企業や受注企業のデータプロファイルの列ＩＤ）と対象となる項目（対象列ＩＤ、即ち、図２０の例では標準データプロファイルの列ＩＤ）を示し、項目間の値を変換する際に使用する関数（関数コード）およびそのパラメータを管理する。原則として、項目関連定義テーブルのトリガー列ＩＤとなるトリガー項目には、企業別データプロファイルの各項目を選択して格納し、対象列ＩＤとなる対象列項目には標準データプロファイルの各項目を選択して格納する。これにより、標準データプロファイルの各項目を介して、発注企業データプロファイルの各項目と受注企業データプロファイルの各項目との間でのデータ変換を実現することができる。通常、発注企業側データプロファイルの各項目と標準データプロファイルの各項目との間での項目間リンク情報は、本データ管理システムの担当者が入力し、受注企業側データプロファイルの各項目と標準データプロファイルの各項目との間での項目間リンク情報は、利用企業担当者が入力する。なお、標準データプロファイルを介することなく、発注企業側データプロファイルと受注企業側データプロファイルとの間で直接リンク情報を張ることも可能である。
【００７７】
次に、関数（ＦＵＮＣＴＩＯＮ）テーブルは、当該システムで使用する関数情報を管理するものであり、項目関連定義テーブルで利用されるシステム関数を管理する。当該情報は、本データ管理システム担当者が入力する。次に、ボリューム管理（ＶＯＬＵＭＥ）テーブルは、本データ管理システムを利用する場合のデータベース領域を管理するものであり、本データ管理システムが入出力する各種データを格納するデータベースの格納域を、対象企業別、年度別等で管理する。当該情報は、利用ユーザの指定内容により、本データ管理システムが自動更新する。次に、企業別格納域管理（ＶＯＬＵＭＥ＿ＣＵＳＴＯＭＥＲ）テーブルは、データベース領域単位に、データ変換対象とする発注企業を管理するものであり、作成ボリューム単位にデータ変換の対象とする発注企業を管理する。当該情報は、利用ユーザの指定内容により、本データ管理システムが自動更新する。次に、システム管理（ＳＹＳＴＥＭ）テーブルは、本データ管理システムが稼動する際のシステム情報を管理し、ユーザーキー等、利用ユーザのシステムを管理する。次に、作業管理（ＴＲＡＮＳＡＣＴＩＯＮ）テーブルは、本データ管理システム音データ変換作業の各種情報を一作業毎（トランザクション毎）に管理するものである。次に、対象管理（ＳＹＳＴＥＭ＿ＯＢＪＥＣＴ）テーブルは、本データ管理システムの管理対象である対象オブジェクトを定義するものであり、伝票、梱包、支払内容等を管理する。この管理対象は、テーブル管理テーブルに定義されるデータ情報が何を対象にしたデータであるかにより、一意に決定される。例えば、ある企業の発注データを構成するファイルヘッダレコードには「発注」、発注ヘッダレコードには「伝票」、伝票明細レコードには「伝票明細」が対象オブジェクトになり、「発注」には｛発注企業コード＋データ送信日時｝、「伝票」には｛発注企業コード＋店コード＋伝票番号｝、「伝票明細」には｛発注企業コード＋店コード＋伝票番号＋行番号｝で取得できる、それぞれの対象オブジェクトを一意に示す識別子を割り付けることができる。なお、図示はしないが、列管理テーブル等、全てのテーブルには、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」、「アクセス制御」、「登録者情報」のデータ項目が設けられ、当該データ項目の値が格納される。特に、「有効日時（自）」、「有効日時（自）」等の日時情報は、列管理テーブルの定義の有効期間（当該カラム定義を使用できる期間）等を限定できる情報を提供するため、カラム定義のバージョン管理等に活用することができる。
【００７８】
図３０は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムにより、発注データと出荷データとの間で相違が発生した場合のマッチング処理を概略的に示す説明図である。
図３０に示すように、発注企業の発注データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２について、発注は商品Ｂが１０個であるが、受注企業でピッキングした結果、在庫切れが発生している場合、出荷予定は商品Ｂが８個となる。ここで、本データ管理システムは、出荷予定データを作成する場合、まず、項目関連定義テーブルを使用して、値管理テーブルに格納した発注企業独自データ（オリジナルデータ）としての発注データを、発注企業データプロファイルから標準データプロファイルへとデータ変換して、（受注企業側）システム標準データとしての受注データを作成する。次に、本データ管理システムは、項目関連定義テーブルを使用して、受注企業側システム標準データとしての受注データを、受注企業データプロファイルへとデータ変換して、受注企業指定データとしての受注データを作成する。次に、受注企業は、自社システムを使用して、受注企業指定データ形式の受注データに在庫切れを反映し、受注企業指定形式の出荷予定データを作成する。次に、本データ管理システムは、項目関連定義テーブルを使用して、受注企業指定形式の出荷予定データを、受注企業データプロファイルから標準データプロファイルへとデータ変換して、システム標準データとしての出荷予定データを作成する。なお、自社システムを有しない受注企業は、本データ管理システムを使用して出荷予定データを作成するため、このデータ変換処理は不要となる。このとき、本データ管理システムは、列管理テーブルや対象管理テーブルを参照して、発注データと出荷予定データとの間でのデータ突合に必要な突合項目値（伝票Ｎｏ．や明細行Ｎｏ．等）を行管理テーブルに格納している。よって、ここで、データ管理システムは、突合対象の発注データ（＝受注データ）に関する突合項目値を行管理テーブルから取得し、当該発注データの伝票Ｎｏ．の値（伝票Ｎｏ．１００）と、明細行Ｎｏ．の値（明細行Ｎｏ．１〜５）とを、出荷予定データの伝票Ｎｏ．の値（伝票Ｎｏ．１００）と、明細行Ｎｏ．の値（明細行Ｎｏ．１〜５）と突合させ、受注データの発注数量と出荷予定データの出荷数量の比較を行い、相違がある場合は出荷数量に反映する（出荷訂正する）。即ち、上記の場合、本データ管理システムは、発注データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２の商品Ｂの個数と、出荷データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２の商品Ｂの個数とを自動的にマッチング（突合処理）して、出荷予定データを作成する。具体的には、本データ管理システムは、伝票明細行Ｎｏ．２については、商品Ｂの個数を、当初の（発注数である）１０個ではなく、（実際の納品数である）８個に設定（出荷訂正）する。このようにして、行管理テーブルに格納する突合項目値を、納品書の修正時に有効に活用することができる。最後に、本データ管理システムは、項目関連定義テーブルを使用して、システム標準データとしての出荷予定データを、標準データプロファイルから発注企業データプロファイルへとデータ変換して、発注企業独自データとしての（出荷訂正済みの）出荷予定データを作成する。このようにして、発注企業には、実際に出荷される値の入荷予定データが受信される。
【００７９】
ここで、かかるマッチング処理（突合処理）は、後述するように、列管理テーブルに定義した列サブＩＤ（対応する列ＩＤのデータ項目を突合処理で使用する場合に、対象管理テーブルで定義した当該データ項目のオブジェクトＩＤを示す）と、行管理テーブルに格納した突合項目値（当該突合処理で使用するデータ項目の項目値）と、対象管理テーブルのオブジェクトＩＤを使用して実現している。具体的には、データ管理システムは、レコードの読込時に行管理テーブルを作成するときに、列管理テーブルの列サブＩＤを参照し、読込レコードの特定のデータ項目（伝票ＮＯ．等）が突合処理で使用される項目となっているかどうか判断する。当該データ項目が突合処理で使用される突合項目となっている場合、当該データ項目は対象管理テーブルで予め定義され、対応するオブジェクトＩＤが格納されている。例えば、上記の場合、発注データの伝票ＮＯ．のデータ項目にオブジェクトＩＤ「２０２０１」が格納され、伝票明細行ＮＯ．のデータ項目にオブジェクトＩＤ「２０２０１１」が格納されている。また、列管理テーブルは、当該データ項目に対応する列サブＩＤの欄にオブジェクトＩＤが格納されている場合、そのオブジェクトＩＤに対応するデータ項目を対象管理テーブルから取得し、当該データ項目の項目値を行管理テーブルの対応する突合項目値の欄に格納する。例えば、上記の場合、オブジェクトＩＤ「２０２０１」のデータ項目「伝票ＮＯ．（伝票番号）」が対象管理テーブルから取得され、行管理テーブルの対応する突合項目値として格納され、また、オブジェクトＩＤ「２０２０１１」のデータ項目「伝票明細行ＮＯ．（行番号）」が対象管理テーブルから取得され、行管理テーブルの対応する突合項目値として格納される。これにより、データ管理システムは、上記突合処理において、突合項目値（伝票ＮＯ．及び明細行ＮＯ．）により、処理対象の発注データ（受注データ）と出荷予定データとの間で各伝票の各明細行を突合することができ、突合した明細行の数量等に相違がある場合（発注数量より出荷数量が少ない場合）、当該出荷数量を反映するよう、出荷予定データを訂正する。
【００８０】
実施の形態５
図３１は本発明の実施の形態５に係るデータ管理システムを適用して電子商取引データ交換を実現するネットワークシステムの全体構成を示す説明図である。
図３１の上部に示すように、発注企業と受注企業との間のデータ送受信は、既存の通信インフラを利用することが前提である。ＪＣＡあるいは全銀協、全銀ＴＣＰ／ＩＰ等の通信手順が使われる。図３１の左下は、データ管理センター乃至システムサポートセンター（「ｅＤＩＹ」サポートセンター）を示す。データ管理センターは、標準プロファイルと企業プロファイルとを管理し、本データ管理システム（「ｅＤＩＹ」システム）を利用するユーザの要求に応じて、標準プロファイルや企業プロファイルを配信し、その履歴状況に応じて課金を行う。図３１の右下は、本データ管理システム（「ｅＤＩＹ」システム）を示す。本データ管理システムは、必要なプロファイルをインストールする事で取引先との電子データ交換＆翻訳をする事ができる。
【００８１】
次に、図３１に示すデータ管理システムの簡単な処理の流れを以下に簡単に示す。まず、データ管理センター（「ｅＤＩＹ」サポートセンター）にて、業界標準のメッセージ・フォーマットに従い、標準プロファイルを定義する。次に、データ管理センター（「ｅＤＩＹ」サポートセンター）にて、業界に属する各発注企業のメッセージ・フォーマットを分析し、標準プロファイルとの関連と共に企業プロファイルとして定義する。次に、データ管理システム（「ｅＤＩＹ」システム）の利用企業は、電子商取引を行う取引先を決定し、データ管理センター（「ｅＤＩＹ」サポートセンター）に要求すると、必要な標準プロファイルと企業プロファイルがダウンロードされ、システムにインストールされる。次に、データ管理センターは、既存システムとのインタフェースに必要なメッセージ・フォーマットをユーザープロファイルとして定義する。次に、ユーザ企業のシステムにおいて、取引先企業独自データと利用企業指定データとの間でのデータ変換及び翻訳が相互に自動で行われる。ここで、現行のＶＡＮ企業を介して受信した取引先の各種データをデータ管理システム（「ｅＤＩＹ」システム）に入力することで、自社既存システムに必要な各種ファイルのインポートデータを作成する。また、既存システムで作成される各種ファイルをデータ管理システム（「ｅＤＩＹ」システム）に入力することで、現行ＶＡＮ企業を介して送信する各種データを作成する。
【００８２】
次に、データ変換及び翻訳の仕組みについて簡単に説明する。まず、データ管理システム（「ｅＤＩＹ」）のデータ変換及び翻訳は、前述のように、発注企業別データプロファイルと標準データプロファイルとの間で項目関連定義を行い、かつ、標準データプロファイルとユーザーデータプロファイル（受注企業データプロファイル）との間で項目関連定義を行う事で実現する。こうすることにより、発注企業別データプロファイルとユーザーデータプロファイルとの間の項目関連定義をする事なく、標準データプロファイルを介して、発注企業のデータと受注企業のデータとの間の各データ項目間の関連情報（リンク情報）を取得し、データ変換及び翻訳を実現することができる。なお、標準データプロファイルは、業界毎に作成可能である。
【００８３】
図３２は一般的なテーブル構造と本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルとの関係を示すブロック図である。
データ管理システム（図３１の「ｅＤＩＹ」）は、図３２に示すように一般的なテーブル構造とそれに格納されるデータとを３つの物理テーブルに分けて格納することでデータ変換及び翻訳を実現する。即ち、前述のように、データ管理システムは、インデックスを格納する行管理（ＲＯＷ）テーブルと、データ項目内容を格納する列管理（ＣＯＬＵＭＮ）テーブルと、データ（項目値）を格納する値管理（ＣＥＬＬ）テーブルの３つのテーブルを有する。３つに分けたテーブルの内、列管理テーブルが、各データプロファイルのデータ項目定義を格納するテーブルに該当する。この列管理テーブルの各レコード間の関連定義（図３２中では項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブル）を含めて企業プロファイルを作成する。
【００８４】
図３３は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルの概念を示す説明図である。
図３２の３つのテーブルの概念は、図３３に示すように、リレーショナルデータベースで扱う表の行（ロー）と列（カラム）とセルとで示す事ができる。即ち、前述のように、データ管理システムは、テーブルのデータ項目（カラム）をデータ設計作業が必要なデータ項目としてではなく、データ入力作業としての簡易入力・編集が可能な項目値として、列管理テーブルに格納し、各管理対象レコード（読込レコード）のインデックス（行ＩＤ）を行管理テーブルに格納し、当該データ項目（カラム）と行ＩＤとが交差するセルに格納される項目値を値管理テーブルに（列ＩＤと行ＩＤとにより特定して）格納する。
【００８５】
図３４は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルにおけるレコード階層構造の処理について説明するブロック図である。
ここで、上述のように、電子商取引で交換される各種データは図３４に示すように階層構造からなっている場合が多い（図１５参照）。なお、本データ管理システムは、行管理テーブルに格納されるデータ間に階層構造がある場合については、図３４に示すように、列管理テーブルのレコード階層を表すコードであるレコードサブＩＤ等を当該行管理テーブルに格納すると共に、行管理テーブルに親レコードシーケンスＮｏ．（当該レコードの親となるレコードの連番）を定義する等により、親子関係を確保することで対処することもできる。しかし、後述するように、当該階層関係や親子関係等のレコード間またはテーブル間の関連情報を行管理テーブルから外出しにして別個のテーブル（行関連管理テーブル）を用意し、レコード間の関連に対応するようにすることが好ましい。
【００８６】
図３５は本発明の実施の形態５に係るデータ管理システムを流通企業向け物流支援システムに適用した場合の業務の流れを示すフロー図である。
上述のデータ管理システム（「ｅＤＩＹ」）で交換されるデータをクライアント側のデータベースに格納し、それらのデータを有効に活用できる物流業務プロセスを支援するパッケージが改良版データ管理システム（「ｅＤＩＹｐｌｕｓ」）である。この改良版のデータ管理システムは、図３５の太線で囲んだ長方形で示す業務プロセスの支援を行う。即ち、同データ管理システムは、受注時の受注内容チェックや在庫仮引当、出庫時のロケーション指示や在庫本引当、梱包時の出荷検品及び出荷数量訂正、ＰＤラベル発行、訂正済み納品書発行等、利用企業の情報化レベルに合わせた導入に対応できる。
【００８７】
図３６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する企業管理（ＣＵＳＴＯＭＥＲ）テーブルを示す説明図である。
図３６に示すように、企業管理（ＣＵＳＴＯＭＥＲ）テーブルは、そのデータ項目（カラム）として、「企業コード」、「企業名」、「〒（郵便番号）」、「住所」、「ＴＥＬ（電話番号）」、「担当者」、「メール」、「企業分類」等を定義している。なお、図３６の企業管理テーブルは、図３６に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時」等）を定義している。そして、企業管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「００００００」、「情報センター」・・・等）。ここで、企業管理テーブルのデータ項目である企業コードの値「００００００」は、データ管理システムを管理する管理センター（図３１のｅＤＩＹサポートセンター、テーブルでは「情報センター」として表示）に対応し、標準データプロファイル等の各プロファイル情報を定義し、管理する。また、企業コードの値「１１１１１１」は、データ管理システムが管理するデータ（発注データ等）の発注企業（図３１の発注企業）に対応し、本データ管理システムが管理対象とするデータが属する全ての発注企業（ユーザ企業にとっての取引先企業）が登録されている。また、企業コードの値「９９９９９９」は、データ管理システムを利用するユーザ企業（図３１の受注企業）に対応する。企業が追加、削除されたり、登録企業の企業情報が内容変更されると、企業管理テーブルの対応するデータ項目の値が更新される。
【００８８】
図３７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ交換管理（ＥＸＣＨＡＮＧＥ）テーブルを示す説明図である。
図３７に示すように、データ交換管理（ＥＸＣＨＡＮＧＥ）テーブルは、そのデータ項目（カラム）として、「取引先企業（コード）」、「利用企業（コード）」、「データ種類（コード）」、「プロトコル」、「伝送方向」、「伝送サイズ」、「伝票様式」等を定義している。なお、図３７のデータ交換管理テーブルは、図３７に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時」、「商品コード変換ファイル名」、「取引先・自社コード」等）を定義している。そして、データ交換管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１１０１」、「９９９９９９０１」・・・等）。なお、データ交換管理テーブルのデータ項目中、「取引先企業（コード）」は、管理対象データ（発注データ、入荷予定データ等）の送信元（送信側）となる企業（例えば、発注データの場合は発注企業、入荷予定データの場合は受注企業）の企業コード（６桁）に当該管理対象データのデータプロファイル乃至カラム定義のバージョン（版）を示すバージョンコード（２桁）を付加したものである。また、データ交換管理テーブルのデータ項目中、「利用企業（コード）」は、管理対象データ（発注データ、納品データ等）の送信先（受信側）となる企業（例えば、発注データの場合は受注企業、入荷予定データの場合は発注企業）の企業コード（６桁）に当該管理対象データのデータプロファイル乃至カラム定義のバージョン（版）を示すバージョンコード（２桁）を付加したものである。なお、かかる「取引先企業（コード）」、「利用企業（コード）」は、発注企業や受注企業以外にも、標準データプロファイルを管理する管理センターにも割当てられ、この場合、管理センターコード（６桁）に当該管理センターが管理する標準データプロファイルのバージョン（版）を示すバージョンコード（２桁）を付加したものである。データ交換管理テーブルは、取引先企業のデータを利用企業のデータに変換（データ交換）する場合に、当該取引先企業と利用企業との間で実際に取引があるか（データ交換が存在するか）をチェックするために、データ交換時（発注データの読込時等）に参照され、データ読込時に実際に入力された取引先企業コードと利用企業コードとを判断することにより、それらの企業間での取引（データ交換）がデータ交換テーブルに存在するか否かを判断し、当該取引が存在する場合のみデータ交換を後述するテーブル管理テーブルを利用してデータ読込を実行し、当該取引が存在しない場合はエラー処理を実行する等の所定処理に使用される。
【００８９】
ここで、例えば、データ交換管理テーブルの１行目のレコードは、取引先企業コード「１１１１１１０１」の企業（発注企業）が、利用企業コード「９９９９９０１」の企業（受注企業）に、データ種類コード「２０」のデータ（発注データ）を、伝送プロトコル「２」にしたがって、送信した場合（伝送方向「Ｒ」）、即ち、発注企業の発注データを受注企業の指定形式（指定データフォーマット）の受注データへと変換する場合を示す。また、データ交換管理テーブルの２行目のレコードは、取引先企業コード「１１１１１１０１」の企業（発注企業）が、利用企業コード「０００００００１」の企業（管理センター）に、データ種類コード「２０」のデータ（発注データ）を、伝送プロトコル「２」にしたがって、送信（伝送方向「Ｒ」）、即ち、発注企業の発注データを管理センターの標準データプロファイル形式のデータへと変換する場合を示す。また、データ交換管理テーブルの３行目のレコードは、取引先企業コード「９９９９９９０１」の企業（ユーザ企業である受注企業）が、利用企業コード「１１１１１１０１」の企業（発注企業）に、データ種類コード「３０」のデータ（入荷予定データ）を、伝送プロトコル「２」にしたがって、送信（伝送方向「Ｓ」）、即ち、受注企業の入荷予定データを発注企業のデータプロファイル形式の入荷予定データへと変換する場合を示す。このように、全てのデータ種別について、取引（データ交換）が存在する全ての対の取引先企業と利用企業との関係が、データ交換管理テーブルに格納される。また、データ管理システムは、発注企業の指定形式（発注企業データプロファイル）と受注企業の指定形式（受注企業データプロファイル）との間でのデータ交換（データ読込）のみならず、発注企業の指定形式（発注企業データプロファイル）と標準データプロファイルとの間でのデータ交換や、受注企業の指定形式（受注企業データプロファイル）と標準データプロファイルとの間でのデータ交換も実行するため、データ交換管理テーブルには、取引（データ交換）が存在する全ての対の取引先企業と利用企業との関係が格納される。更に、データ交換管理テーブルの各行の取引（データ交換）について、使用される伝票様式（使用伝票名称）やＰＤラベル（使用ＰＤラベル名称）もデータ交換管理テーブルに格納され、データ変換後のデータ表示（印刷や画面表示）の際に、使用すべき伝票がデータ管理システムの表示プログラムにより参照されるようになっている。なお、データ交換の必要な企業間の関係が追加、削除されたり、登録された伝票様式等の情報が内容変更されると、データ交換管理テーブルの対応するデータ項目の値が更新される。
【００９０】
図３８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルを示す説明図である。
図３８に示すように、データ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルは、そのデータ項目（カラム）として、「データコード」、「データ種類（名称）」、「有効日時（自）」、「有効日時（至）」、「登録日時」、「更新日時」、「削除日時」、「アクセス制御」、「登録者情報」等を定義している。なお、図５７のデータ種類テーブルは、図３８に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「データ種類カナ」）を定義している。そして、データ種類テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「００」、「その他」・・・等）。ここで、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」からなる日時情報は、データ種類テーブルのみならず、本データ管理システムが使用する全てのテーブルのデータ項目として定義され、当該データ項目の値が格納されて、例えば、列管理テーブルの定義の有効期間（当該カラム定義を使用できる期間）等を限定できる情報を提供するため、カラム定義のバージョン管理等に活用される。また、本データ管理システムの全てのテーブルには、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」以外にも、「アクセス制御」、「登録者情報」のデータ項目が設けられ、当該データ項目の値が格納される。なお、データ交換管理テーブル等、データ種別をカラムに定義してその値を格納する他のテーブルの所定行の参照時に、データ種別コードをキーにしてデータ種類テーブルが参照され、当該他のテーブルの当該所定行に格納されたデータ種別の情報がデータ種類テーブルから取得される。
【００９１】
図３９は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル管理（ＴＡＢＬＥ）テーブルを示す説明図である。
図３９に示すように、テーブル管理（ＴＡＢＬＥ）テーブルは、そのデータ項目（カラム）として、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類コード）」、「枝番（＝レコード関連情報を表すコード）」、「レコード名称」、「制御情報（＝レコード制御情報）」、「サイズ（＝レコードサイズ）」、「対象（＝対象オブジェクト）」、「ヘッダ（＝ヘッダの有無）」、「前Ｒ（＝前レコード指定）」、「後Ｒ（＝後レコード指定）」等を定義している。なお、図３９のテーブル管理テーブルは、図３９８に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時（自）」、「有効日時（至）」等）を定義している。そして、テーブル管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「０００００００１」、「２０」・・・等）。なお、テーブル管理テーブルのデータ項目中、「企業（版）」は、前記データ交換管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ管理システムが対象とするデータ種類を識別するものであり、データ種類テーブルのデータ種類に対応する。また、「枝番」は、親子関係や階層構造等の関係にあるレコード関連情報を示すものであり、発注データ等の管理対象データにおける階層等を一意に示すものである。前記「企業（版）」、「種類」、「枝番」によりテーブルＩＤが構成されている。なお、「枝番」は、その企業（版）コードを有する企業において同データ種別内でテーブルＩＤを一意に特定するサブＩＤであり、テーブル管理テーブルに格納される。
【００９２】
「制御情報」は、図２９の表に項で前述したレコード制御情報と同様のレコード分析情報であり、当該制御情報が属する行のレコードについて、当該レコードであることを識別するための情報（当該レコードの先頭（０）からのバイト位置及びチェックする文字列コード）を格納する。例えば、１行目のレコード（テーブルＩＤ「０００００００１２０１」の「標準−発注−ファイルヘッダ」レコード）の場合、データ管理システムは、データの読込時に、テーブル管理テーブルを参照し、読み込んだレコードの先頭からの位置が「０」の文字列コードが「ＦＨ２０」であれば、即ち、先頭の文字列コードが「ＦＨ２０」であれば、当該レコードを「標準−発注−ファイルヘッダ」レコードと判断する。「サイズ（レコードサイズ）」は、当該レコードのサイズ（バイト）を示す。データ管理システムは、データ読込時に、テーブル管理テーブルを参照し、前記「制御情報（レコード制御情報）」により判断したレコード（特定テーブルＩＤ）に応じて、当該テーブルＩＤの「レコード（サイズ）」に指定したレコードサイズで読込データを分割して当該テーブルＩＤの一レコードとする。「対象」は、当該テーブルＩＤのレコードの対象オブジェクト、即ち、当該レコードが伝票レコードや伝票明細行レコード等のいずれのレコードであるかを示し、後述する対象管理テーブルのオブジェクトＩＤに対応する。データ管理システムは、データ読込時に、テーブル管理テーブルを参照し、前記「制御情報」により判断したレコード（特定テーブルＩＤのレコード）の「対象」の値に基づき、当該読込レコードの対象オブジェクト（伝票、梱包等）を判断する。なお、テーブル管理テーブルは、データ管理システムが把握する（取り扱う）全ての企業のレコードを格納する。即ち、テーブル管理テーブルは、発注企業、ユーザ企業（受注企業）及びデータ管理センター（上記ｅＤＩＹに相当）について、全てのデータ種類のデータのレコード階層や親子関係等のレコード関連情報も含め、全てのテーブルＩＤの各々について上記のようなデータ定義情報を格納する。
【００９３】
図４０は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの標準データプロファイル部分を示す説明図である。図４１は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの発注企業データプロファイル部分を示す説明図である。図４２は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの受注企業データプロファイル部分を示す説明図である。
【００９４】
列管理（ＣＯＬＵＭＮ）テーブルは、上記実施の形態１〜４でも説明したように、標準データプロファイル、発注企業データプロファイル、受注企業データプロファイルを一つのテーブルとして格納したものであり、実際は、図４０〜図４２のテーブルは一つのテーブルを構成する（説明の便宜上、及び、紙面サイズの関係上３つに分けて図示する）。図４０〜図４２に示すように、列管理テーブルは、そのデータ項目（カラム）として、「列ＩＤ」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類コード）」、「枝番（＝レコード関連情報）」、「連番（＝シーケンスＮｏ）」、「名称（＝データ項目名）」、「データ型（＝データの属性）」、「変換（＝変換メソッド）」、「位置（＝ポジション）」、「最大長（＝レングス）」、「最小長（＝レングス（最小））」等を定義している。なお、図４０〜図４２の列管理テーブルは、図４０〜図４２に図示のデータ項目以外にも、図示はしないが、図２９の表の項で説明したように、その他のデータ項目（「関連フラグ」、「関連メソッド」、「関連項目」、「識別子作成順序」、「基本項目指定順序」、「カラムサブＩＤ」、その他、「有効日時（自）」、「有効日時（至）」等の日時情報等）を定義している。そして、列管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１２０１００１」、「０００００００１」・・・等）。なお、列管理テーブルのデータ項目中、「企業（版）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ種類テーブル及びテーブル管理テーブルのデータ種類に対応する。また、「枝番」は、テーブル管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成され、データ項目を一意に示すコードをテーブルＩＤの末尾に付加したものが列ＩＤとなる。
【００９５】
更に、「連番」は、上記のように、同一テーブルＩＤのレコード内における当該データ項目（レコード中のフィールド）の（好ましくは）出力順序を示すものとして構成されるが、格納順序を示すものとして構成しても良い。枝番が格納順序を示す場合、当該枝番が列ＩＤの末尾のコードとして使用される。この場合、例えば、あるテーブルＩＤのレコードが合計１６個のデータ項目（フィールド）からなる場合、「１」〜「１６」までの連番が「連番（シーケンスＮｏ）」の値として格納される。そして、テーブルＩＤと連番との組み合わせ（一連のコード）により、同一レコード内における各データ項目に１対１で対応するコードが構成される。ここで、前記列ＩＤも、同一レコード内における各データ項目に１対１で対応するコードであり、特定データフォーマットのレコードのデータ項目、即ち、同一テーブルＩＤのレコードのデータ項目を一意に特定するものであるが、前記テーブルＩＤと連番との組み合わせによっても特定データプロファイルのレコードのデータ項目一意に特定することができる。また、列ＩＤは、本実施の形態５では、テーブルＩＤとシーケンスＮｏとの組み合わせコードを統合・簡略化する作成規準により自動生成されたコードとなっている。例えば、１行目のレコードの場合、企業（版）コード「０００００００１」の「１」と、データ種類「２０」と、枝番「１」に対応する「１」と、連番「１」に対応する「００１」とから、列ＩＤ「１２０１００１」が生成される。なお、枝番が「２」の場合、列ＩＤの対応部分には「２」が、階層コードが「３」の場合、列ＩＤの対応部分には「３」が付与される。かかる列ＩＤに１対１で対応して、ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード等の各レコードに特有の一連のデータ項目のデータ項目名が、その本来の並び順で、「連番」の順番に対応して、「名称」の項目値として格納されている（「レコード区分」、「データ種別」、「データ作成日」・・・）。
【００９６】
次に、列管理テーブルには、「関連フラグ」のデータ項目が設けられ、ある列ＩＤのデータ項目が、項目関連定義テーブルにおいて標準データプロファイルとの間で項目間リンク（チェーン）されている場合にＯＮされる。これにより、「関連フラグ」を介して、各データフォーマット（データプロファイル）のレコードのデータ項目について、必要なもののみ標準プロファイルの対応するデータ項目とリンクすることができ、標準データプロファイルを介した発注企業データプロファイルのレコードと受注企業データプロファイルのレコードとのデータ変換において、項目関連定義テーブルを参照する際に、全てのデータ項目間のリンクを参照することなく、必要なデータ項目間のリンクのみ参照して、処理負荷を削減することができる。また列管理テーブルには「変換メソッド」のデータ項目が設けられ、ある列ＩＤのデータ項目の項目値を値変換する必要がある場合に、利用するメソッド名（カラム値（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）等）を格納するものである。例えば、図２１の項目値管理テーブルを参照して述べたように、項目値の意味がデータフォーマットの異なる複数のデータ間で異なる場合、例えば、発注企業データプロファイルのカラム値が「０」で、これに対応する標準データプロファイルのカラム値が「ア」で、これに対応する受注企業データプロファイルのカラム値が「ａ」の場合に、当該発注企業データプロファイルの列ＩＤの「変換メソッド」、当該標準データプロファイルの列ＩＤの「変換メソッド」、及び、当該受注企業データプロファイルの列ＩＤの「変換メソッド」に、それぞれ「カラム値」または「ＣＯＬＵＭＮ＿ＶＡＬＵＥ」の文字列を格納する。例えば、データ管理システムが、発注企業データプロファイルの発注データを受注企業データプロファイルの受注企業指定データに変換する時に、列管理テーブルの当該受注企業指定データのレコードの「変換メソッド」にメソッド名が格納された列ＩＤについて、項目関連定義テーブルを参照し、当該列ＩＤ（トリガ列ＩＤ）と対応する（リンクする）標準データプロファイルの列ＩＤ（対象列ＩＤ）及び当該対象列ＩＤとリンクする発注企業データプロファイルの列ＩＤとを抽出したときに、項目値管理テーブルのそれら３つの列ＩＤの行をそれぞれ参照して、図２１で述べたようにして項目値の意味の変換処理を実行する。
【００９７】
次に、列管理テーブルいは、「識別子作成順序」のデータ項目が設けられ、あるテーブルＩＤを有するレコードを行管理テーブルに格納する場合において、行管理テーブルの「識別子」として当該テーブルＩＤの所定のデータ項目を格納する場合に、それらのデータ項目の順序（当該「識別子」を構成するデータ項目の順番）を格納する。また、列管理テーブルには「基本項目指定順序」のデータ項目が設けられ、ある列ＩＤのデータ項目の項目値を行管理テーブルの何番目の基本情報（基本項目値）に複写するかを示すコードが格納されている。即ち、行管理テーブルは、インデックスとしての行ＩＤや識別子以外にも、各読込レコードの基本情報（例えば、伝票ヘッダレコードの伝票番号、発注日、納品日、検収日等、伝票明細行レコードの商品コード、商品名、発注数量、検収数量等）を所定数の「基本項目値」（＝データ項目）の値として格納するが、かかる基本項目値に特定列ＩＤのデータ項目の値を複写して格納する場合に、当該列ＩＤのデータ項目の値を、「基本項目指定順序」に指定した順番で行管理テーブルの基本項目値に複写する。また、列管理テーブルには「列サブＩＤ」のデータ項目が設けられる。列サブＩＤは、上記列サブＩＤに対応するものであり、ある列ＩＤのデータ項目の項目値を行管理テーブルの「突合項目」（＝データ項目）の値として格納する場合に、当該列ＩＤの対象オブジェクトのオブジェクトＩＤの値を指定する。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードについて、例えば、発注データと入荷予定データとの間での数量の相違（数量不足）を判断して納品書等に訂正情報を記載するために、発注データ及び入荷予定データの対応レコードを突合する際の検索キーとなる「識別子」の値や、突合対象となる「突合項目」の値を格納するが、かかる場合に、当該列ＩＤの対象オブジェクトのオブジェクトＩＤの値を、行管理テーブルの「突合項目」の値として格納する。
【００９８】
図４３は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルを示す説明図である。
図４３に示すように、項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルは、そのデータ項目（カラム）として、「ＩＤ」、「列ＩＤ」、「カラム値」、「標準値」、「意味」等を定義している。なお、図４３の項目値管理テーブルは、図４３に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「備考」、「参照フラグ」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、項目値管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「２４５」、「１１１１１１０１２０２０１６００」・・・等）。なお、項目値管理テーブルは、図２１について説明したと同様にして、値変換処理に利用される。
【００９９】
図４４は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルを示す説明図である。
図４４に示すように、項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルは、そのデータ項目（カラム）として、「ＩＤ」、「トリガ列ＩＤ」、「連番（＝シーケンスＮｏ）」、「対象列ＩＤ」、「関数（＝関数コード）」、「パラメータ１」、「パラメータ２」、「パラメータ３」等を定義している。なお、図４４の項目関連定義テーブルは、図４４に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「パラメータ４〜１０」、「備考」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、項目関連定義テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「５４」、「１１１１１１０１２０１００３」・・・等）。なお、項目関連定義テーブルは、図２０について説明したと同様にして、標準データプロファイルを介して発注企業データプロファイルと受注企業プロファイルとの間でのデータ変換処理に利用される。即ち、図４４に囲み線で示したように、発注企業データプロファイルの発注データの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値を、標準データプロファイルの列ＩＤ「１２０１００３」を介して、受注企業が指定する受注データプロファイルの列ＩＤ「９９９９９９０１２０１００３」のデータ項目の値へと変換する場合、データ管理システムは、受注企業データプロファイルの列ＩＤ「９９９９９９０１２０１００３」をトリガとして、標準データプロファイルの対象ＩＤ「１２０１００３」に「関数コード」の「１（格納）」にしたがって格納した発注企業データプロファイルの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値を、「関数コード」の「２（取得）」にしたがって取得する。これにより、受注企業データプロファイルの列ＩＤ「９９９９９９０１２０１００３」のデータ項目の値に発注企業データプロファイルの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値が格納され、当該データ項目とセットで表示・出力される。なお、「パラメータ１〜１０」は、「関数コード」の関数内容に応じて、その関数のパラメータが必要となる場合に所定値が格納され、データ管理システムが、項目関連定義テーブルの「関数コード」の値にしたがて、関数管理テーブルの関数内容を参照し、当該パラメータの値により当該関数の処理を実行する。
【０１００】
図４５は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する関数管理（ＦＵＮＣＴＩＯＮ）テーブルを示す説明図である。
図４５に示すように、関数管理（ＦＵＮＣＴＩＯＮ）テーブルは、そのデータ項目（カラム）として、「関数（＝関数コード）」、「関数（＝関数内容）」、「詳細（＝ヘルプ）」等を定義している。なお、図４５の関数管理テーブルは、図４５に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「有効日時（自）」、「有効日時（至）」等）を定義している。そして、関数管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１」、「格納」・・・等）。関数管理テーブルに格納する関数は、データ管理システムが管理するデータについて要求される処理を考慮して必要なものがあらかじめ定義されデータ項目値として格納される。即ち、従来は、要求される処理に応じてプログラム内に定義されていた関数やパラメータが、本データ管理システムでは、関数管理テーブルのデータ項目値として外出しされ、関数管理テーブルを参照することで必要な処理が実行される。よって、要求される処理の内容が追加、削除、変更等された場合、従来のようにプログラム自体を変更するという面倒な作業を必要とすることなく、関数管理テーブルに項目値として格納した関数を追加、削除、変更したり、項目関連定義テーブルに項目値として格納したパラメータの値を追加、削除、変更したりすることにより、処理の変更に容易に対応することができる。
【０１０１】
図４６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する対象管理（ＯＢＪＥＣＴ）テーブルを示す説明図である。
図４６に示すように、対象管理（ＯＢＪＥＣＴ）テーブルは、そのデータ項目（カラム）として、「ＩＤ（＝オブジェクトＩＤ）」、「オブジェクト名」、「位置（＝ポジション）」、「キー内容」等を定義している。なお、図４６の対象管理テーブルは、図４６に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「参照フラグ」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、対象管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「３」、「ＧＴＩＮコード」・・・等）。「ＩＤ（＝オブジェクトＩＤ）」は、テーブル管理テーブルの「対象（＝対象オブジェクト）」及び列管理テーブルの「列サブＩＤ」に対応する。「位置」は、当該オブジェクトＩＤのオブジェクトに該当するカラム項目（ＧＴＩＮコード、ｉｄ伝票、ｉｄ伝票明細行等）の項目値（「キー内容」に定義されたものであり、例えば、ｉｄ伝票の場合は発注企業コード＋（店コード）＋伝票ＮＯ）を、行管理テーブルの何番目の「突合項目」の値として格納するかを示す。例えば、オブジェクトＩＤ「１１」のオブジェクト「店コード」の項目値は、行管理テーブルの対応するオブジェクト（伝票ヘッダレコード及び伝票明細行レコード）の１番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「２０２０１」のオブジェクト「伝票番号」の項目値は、行管理テーブルの対応するオブジェクト（伝票ヘッダレコード及び伝票明細行レコード）の２番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「２０２０１１」のオブジェクト「行番号」の項目値は、行管理テーブルの対応するオブジェクト（伝票明細行レコード）の３番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「３」のオブジェクト「ＧＴＩＮコード」の項目値は、行管理テーブルの対応するオブジェクト（伝票明細行レコード）の４番目の突合項目（突合項目値４）の項目値として格納される。これら行管理テーブルの「突合項目」の項目値として格納される「オブジェクトＩＤ」の項目値が、データ管理システムの管理対象であるファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード、送り状ヘッダレコード、梱包レコード、梱包明細行レコード等の識別子として、それぞれの対象オブジェクト（レコード）を一意に識別する。そして、例えば、発注データのある伝票明細に指定された発注数量と、入荷予定データの伝票明細の実際の納品数量との間で数量に相違（欠品）がある場合に、行管理テーブルに格納した突合項目値を参照して両伝票明細を突合し、それらの数量（例えば、行管理テーブルの基本項目値として格納した発注数量と検収数量）をチェックすることで、入荷予定伝票の納品数量を自動的に訂正処理することができる。
【０１０２】
ここで、システム管理対象としては、例えば、「１１，店コード，１」（オブジェクトＩＤ、オブジェクト名、位置の順）、「２０２０１，伝票番号，２」、「２０２０１１，行番号，３」、「３，ＧＴＩＮコード，４」、「４０２０１，梱包コード，５」、「２０１０１，発注日付，６」、「３０１０１，出荷日付，７」、「３０２０１，出荷指示書Ｎｏ，８」、「３０２０１１，出荷指示書行Ｎｏ，９」、「７０１１１，支払明細，１０」があり、各管理対象レコード（そのテーブルＩＤにより識別される所定カラム定義のレコード）に対応して、これらの各項目値のいずれか１以上（ゼロの場合もあり）が、その位置（ポジション）にしたがって、行管理テーブルの対応する突合項目の項目値として自動的に割り当てて格納される。また、これら以外に、システム管理対象としては、例えば、「１，発注企業コード（発注企業を示すコード）」（オブジェクトＩＤ、オブジェクト名、キー内容の順）、「２，受注企業コード（受注企業を示すコード）」、「１０，商品（商品情報の送信イベントを示す。１０＋発注企業コード＋受注企業コード＋送信日付）」、「２０，発注（発注情報の受信イベントを示す。２０＋発注企業コード＋受注企業コード＋発注日付）」、「３０，納品通知（ＡＳＮ）（納品通知の送信イベントを示す。３０＋発注企業コード＋受注企業コード＋納品予定日付）」、「４０，梱包明細（ＳＣＭ）（梱包明細の送信イベントを示す。４０＋発注企業コード＋受注企業コード＋出荷日付）」、「５０，受領（受領情報の受信イベントを示す。５０＋発注企業コード＋受注企業コード＋検収日付）」、「６０，請求（請求情報の送信イベントを示す。６０＋発注企業コード＋受注企業コード＋請求日付）」、「７０，支払（支払情報の受信イベントを示す。７０＋発注企業コード＋受注企業コード＋支払通知日付）」、「８０，返品（返品情報の受信イベントを示す。８０＋発注企業コード＋受注企業コード＋返品日付）」、「２０２０，ｉｄ伝票（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋伝票ＮＯ）」、「２０３０，ｉｄ伝票明細行（システム内で伝票明細を一意に示す。発注企業コード＋（店コード）＋伝票ＮＯ＋伝票行ＮＯ）」、「４０１０，ｉｄ出荷（システム内で出荷単位を一意に示す。発注企業コード＋店コード＋出荷日付）」、「４０２０，ｉｄ梱包（システム内で梱包を一意に示す。発注企業コード＋（店コード）＋梱包ＮＯ）」、「４０３０，ｉｄ梱包明細（システム内で梱包明細を一意に示す。発注企業コード＋（店コード）＋梱包ＮＯ＋伝票ＮＯ＋伝票行ＮＯ）」、「６０１１，請求（月ごとの請求総括を示す）」、「６０２０，iｄ請求（システム内で請求を一意に示す。発注企業コード＋（店コード）＋請求対象期間）」、「６０３０，ｉｄ請求明細（システム内で請求を一意に示す。発注企業コード＋（店コード）＋請求対象期間＋科目コード）」、「７０１１，支払（月ごとの支払総括を示す）」、「７０２０，ｉｄ支払（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋支払対象期間）」、「７０３０，ｉｄ支払明細（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋支払対象期間＋科目コード）」、「６０��１１，請求明細（月ごとの請求明細を示す）」、「４０２０１１，梱包明細（梱包明細を示すコード）」があり、各管理対象レコード（そのテーブルＩＤにより識別される所定カラム定義のレコード）に対応して、これらの各項目値のいずれか一つが、行管理テーブルの対応する「識別子ＩＤ」の「識別値」の項目値として自動的に割り当てて格納される。
【０１０３】
図４７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する行管理（ＲＯＷ）テーブルを示す説明図である。
図４７に示すように、行管理（ＲＯＷ）テーブルは、そのデータ項目（カラム）として、「行グループ」、「連番（＝シーケンスＮｏ」、「行タイトル」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類）」、「枝番（＝レコード関連情報」、「親Ｓ（＝親レコードシーケンスＮｏ）」、「ＦＳ（＝同一レコード内シーケンスＮｏ）」、「識別子（＝識別子値）」、「突合値１（＝突合項目値１）」（〜「突合項目値ｎ（たとえば突合項目値１０」）、「基本値１（＝基本項目値１）」（〜「基本項目値ｎ（たとえば突合項目値５」）等を定義している。なお、図４７の行管理テーブルは、図４７に図示のデータ項目以外にも、図示はしないが、図２９の表の項で説明したようにその他のデータ項目（「識別子ＩＤ」、「識別子名称」、「関連メソッド」、「関連情報」、「備考」、「参照フラグ」、その他、「有効日時（自）」、「有効日時（至）」等の日時情報等）を定義している。そして、行管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１０１−９９９９９９−５０−０５１２０７−２０１９１４」、「１」・・・等）。なお、行管理テーブルのデータ項目中、「行グループ」は、所定の作成基準にしたがって、データ管理システムが一レコードを読込むごとに自動生成（発番）されるコードであり、格納データの管理グループを示す。行グループは、例えば、発注企業コード（＋版）の８桁＋受注企業コードの６桁＋データ種別の２桁＋データ読込日の６桁＋データ読込時刻（時分秒）の６桁から一意のコードとして自動生成することができる。そして、１回に読込んだデータ（発注データ等）の全てのレコードについて同一の行グループが付与される。なお、同一行グループを有するレコードが、本データ管理システムが格納データとして管理すべき１単位の管理グループとなる。次に、「連番」は、前記同一行グループ内での当該レコードの連番（レコードシーケンス）を示す。例えば、読込データが１００レコードからなる場合、「１」〜「１００」の連番が読込レコードの順番で「連番（シーケンスＮｏ）」の項目値として付与される。前記行グループ及び連番（シーケンスＮｏ）により行ＩＤが構成され、当該行ＩＤが、当該レコードが入力データ（読込データ）の何番目のデータであるかを示す。即ち、行ＩＤにより、各読込レコードに１対１で対応するコードが構成される。なお、「企業（版）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ種類テーブル及び列管理テーブルのデータ種類に対応する。また、「枝番」は、テーブル管理テーブル及び列管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成されている。行管理テーブルでは、データ読込時にテーブル管理テーブルを参照したときに、「レコード制御情報」の値に基づき、特定のテーブルＩＤのカラム定義とマッチ（照合）したレコードに対して、当該テーブルＩＤが自動的に付与される。また、このとき、当該テーブルＩＤに割り当てた「レコード名称」（テーブル管理テーブル参照）の項目値が、行管理テーブルの「行タイトル」の項目値として複写される。
【０１０４】
次に、「親Ｓ（親レコードシーケンスＮｏ）」は、当該格納レコードが従属する親レコード（上位階層のレコード）の「連番（シーケンスＮｏ）」の値を示す。例えば、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であるため、親レコードは存在せず、「親Ｓ（親レコードシーケンスＮｏ）」は「０」となる。また、２行目のレコード（「連番（シーケンスＮｏ）」の値が「２」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、３行目のレコード（「連番（シーケンスＮｏ）」の値が「３」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「２」となる。同様に、９行目のレコード（「連番（シーケンスＮｏ）」の値が「９」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、１０行目のレコード（「連番（シーケンスＮｏ）」の値が「１０」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「９」となる。次に、「ＦＳ（同一レコード内シーケンスＮｏ）」は、当該格納レコードが属する同一グループ内でのシーケンス（順序）を示す。即ち、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であり、一読込データ（一管理グループの格納レコード群）について一つしか存在しないため、「ＦＳ（同一レコード内シーケンスＮｏ）」の値は「１」となる。また、２行目、９行目、１６行目のレコード（「連番（シーケンスＮｏ）」の値が「２」、「９」、「１６」）の場合、それぞれ伝票ヘッダレコード（ＤＨ）であり複数存在するため、同一グループ（即ち、伝票ヘッダグループ）内におけるシーケンス（順序）を示すべく、「連番（シーケンスＮｏ）」の値の小さい順に、「ＦＳ（同一レコード内シーケンスＮｏ）」の値が「１」、「２」、「３」というように連続して付与される。また、１０行目、１１行目・・・のレコード（「連番（シーケンスＮｏ）」の値が「１０」、「１１」・・・）の場合、伝票明細行レコード（ＤＤ）であり複数存在するため、同一グループ（即ち、伝票明細行グループ）内におけるシーケンス（順序）を示すべく、「連番（シーケンスＮｏ）」の値の小さい順に、「ＦＳ（同一レコード内シーケンスＮｏ）」の値が「１」、「２」・・・というように連続して付与される。
【０１０５】
次に、「識別子（識別子値）」は、当該格納レコードの識別子の値を示す。そして、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、列管理テーブルの「識別子作成順序」を参照し、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）のテーブルＩＤに対応して、列管理テーブルの当該テーブルＩＤの「識別子作成順序」で指定した順序にしたがって、指定されたテーブルＩＤのデータ項目の値を順番に組み合わせて、行管理テーブルの「識別子」の値を自動生成する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「識別子作成順序」において「発注企業コード」、「データ種別」、「データ作成日」が、それぞれ、「１」、「２」、「３」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「５０」、「２００５０８１７」）を順に組み合わせて、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日」を、「識別値」に「１１１１１１−５０−２００５０８１７」をそれぞれ格納する（行管理テーブルの１行目のレコード参照）。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「識別子作成順序」において「伝票番号」が「１」として指定されているため、このデータ項目の値（「４９２１８３８９」）を前記ファイルヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０２０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９」」をそれぞれ格納する（行管理テーブルの２行目のレコード参照）。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１）については、「識別子作成順序」において「行番号」及び「ＧＴＩＮ］が「１」としてそれぞれ指定されているため、このデータ項目の値（「０２」及び「０４９３６０６８９２７２１７」）を前記伝票ヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０３０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号−行番号−ＧＴＩＮ」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９−０２−０４９３６０６８９２７２１７」をそれぞれ格納する（なお、図６６では、行番号については省略）。このように行管理テーブルの各レコードに付与した識別値は、例えば、発注データと入荷予定データの所定の項目値（発注数量と検収数量乃至納品予定数量等）同士を突合する際に、当該レコードの検索キーとして使用される。
【０１０６】
次に、「突合値１（突合項目値１）」〜「突合項目値ｎ（例えば、突合項目値１０）」は、各行のレコードを上記のように突合する際に使用する突合項目値を格納する。即ち、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）の列ＩＤに対応して、列管理テーブルにおいて当該列ＩＤのデータ項目について「カラムサブＩＤ」に格納したオブジェクトＩＤの値を参照し、当該オブジェクトＩＤについて対象管理テーブルの対応する「オブジェクトＩＤ」の「位置（ポジション）」を参照して、当該位置（ポジション）にある行管理テーブルの対応レコードの「突合値１」〜「突合値ｎ」のいずれかに、当該オブジェクトＩＤに対応するオブジェクトの値を格納する。このとき、列管理テーブルにおいて当該オブジェクトに対応する前記列ＩＤの値を、上記データ解析・読込時に読込レコードから取得（当該レコードの対応する項目値を取得）して、当該オブジェクトＩＤに対応するオブジェクトの値を行管理テーブルの「突合項目値」に格納する。例えば、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「カラムサブＩＤ」において発注店舗コード（店コード）のオブジェクトＩＤ「１１」が指定されているため、このデータ項目の値であるオブジェクトＩＤ「１１」についてシステム対象管理テーブルを参照し、当該オブジェクトＩＤ「１１」についての行管理テーブルの突合項目値としての「位置（ポジジョン）」を判断すると共に、当該オブジェクト（店コード）の列ＩＤの値（「１００」）を読込レコードから取得して、その値「１００」を行管理テーブルの１番目の突合値として「突合項目値１」に格納する（行管理テーブルの２行目のレコード参照）。また、「基本値１（基本項目値１）」〜「基本項目値ｎ（例えば、突合項目値５）」は、列管理テーブルの「基本項目指定順序」に指定した順序にしたがって、読込レコードから基本項目値を抽出して格納するものである。
【０１０７】
次に、「基本項目指定順序」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの何番目の基本情報（基本項目値）に複写するかを示すものである。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードの基本情報（例えば、伝票ヘッダレコードの伝票番号、発注日、納品日、検収日等、伝票明細行レコードの商品コード、商品名、発注数量、検収数量等）を所定数の「基本項目値」（＝データ項目）の値として格納するが、かかる基本項目値に特定の列ＩＤのデータ項目の値を複写して格納する場合に、当該列ＩＤのデータ項目の値を、「基本項目指定順序」に指定した順番で行管理テーブルの基本項目値に複写する。また、「列サブＩＤ」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの「突合項目」（＝データ項目）の値として格納する場合に、当該列ＩＤの「対象オブジェクト」のオブジェクトＩＤの値を指定する。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードについて、例えば、発注データと入荷予定データとの間での数量の相違（数量不足）を判断して納品書等に訂正情報を記載するために、発注データ及び入荷予定データの対応レコードを突合する際の検索キーとなる「突合項目」の値を格納するが、かかる場合に、当該列ＩＤの対象オブジェクトのオブジェ宇土ＩＤの値を、行管理テーブルの「突合項目」の値として格納する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「基本情報作成順序」において「発注企業コード」、「受注企業コード」、「データ種別」、「データ作成日」、「レコード件数」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「９９９９９９」、「５０」、「２００５０８１７」、「６１」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１」）については、「基本情報作成順序」において「伝票番号」、「発注日」、「納品日」、「検収日」が、それぞれ、「１」、「２」、「３」、「４」の順序で指定されているため、これらのデータ項目の値（「４９２１８３３９」、「２００５０１１３」、「２００５０１１９」、「２００５０１１９」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値４」にそれぞれ格納する。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１」）については、「基本情報作成順序」において「ＧＴＩＮ」、「規格カナ」、「品名カナ」、「発注数量」、「検収数量」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「０４９３６０６８９２７２１７」、「＊＊＊（規格名）」、「＊＊＊（品名」、「３０」、「３０」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。
【０１０８】
図４８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する値管理（ＣＥＬＬ）テーブルを示す説明図である。
図４８に示すように、値管理（ＣＥＬＬ）テーブルは、そのデータ項目（カラム）として、「行グループ」、「行ＩＤ」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種別）」、「枝番（＝レコード関連情報）」、「連番（＝セルシーケンスＮｏ」、「親Ｓ（＝親レコードシーケンスＮｏ）」、「ＦＳ（＝同一レコードレベル内シーケンスＮｏ）」、「値１」、「値２」、「値３」、「値４」、「値５」（〜「値ｎ（たとえば値３０」）等を定義している。なお、図４８の値管理テーブルは、図４８に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「値０１−アクセス制御」・・・、「関連メソッド」、「関連項目」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、値管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１０１−９９９９９９−５０−０５１２０７−２０１９１４」、「１」・・・等）。なお、行管理テーブルのデータ項目中、「行グループ」は、行管理グループの「行グループ」に対応し、「行ＩＤ」は、行管理テーブルの「連番（＝シーケンスＮｏ」に対応し、行グループと連番の複合キーにより、各読込レコード（格納レコード）が一意に示される（即ち、行グループ＋連番＝行ＩＤとなる）。また、「企業（版）（企業コード）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応し、「種類」は、データ種類テーブル及びテーブル管理テーブルのデータ種類に対応し、「枝番」は、テーブル管理テーブルや列管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成されている。データ管理システムは、データ読込時に、行管理テーブルの行ＩＤを自動生成して各行のレコードを作成すると同時に、当該行ＩＤを構成する行グループ及び連番を、それぞれ、値管理テーブルの行グループ及び行ＩＤの欄に項目値として格納する。また、値管理テーブルでは、行管理テーブルについて取得した各読込レコードのテーブルＩＤ（企業（版）＋データ種別＋階層）が、各行に自動的に付与される。これにより、行ＩＤとテーブルＩＤとにより、値管理テーブルの各レコードを特定することができる。
【０１０９】
次に、図４１について説明したように、データ管理システムは、読込レコードのデータ項目数が値管理テーブルの一行の値格納数（「値ｎ」）を超える場合、例えば、格納項目値数が３０個の場合、３１個目からの項目値を格納すべく、当該レコードの行の次の行に項目値格納用の行を用意して、当該レコードを２行にわたって格納する。よって、「連番（セルシーケンスＮｏ）」は、通常（項目値数が３０以下の場合）は、「１」であるが、項目値数が３１以上となり、次の行が用意される場合、当該追加行の「連番（セルシーケンスＮｏ）」が「２」に設定される。そして、３１以上のデータ項目の値からは、新しいセル（ＣＥＬＬ）レコードを作成して格納する。「親Ｓ（親レコードシーケンスＮｏ）」は、当該格納レコードが従属する親レコード（上位階層のレコード）の「連番（シーケンスＮｏ）」の値を示す。例えば、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であるため、親レコードは存在せず、「親Ｓ（親レコードシーケンスＮｏ）」は「０」となる。また、２行目のレコード（「連番（シーケンスＮｏ）」の値が「２」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、３行目のレコード（「連番（シーケンスＮｏ）」の値が「３」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は、行管理テーブルの「親Ｓ（親レコードシーケンスＮｏ）」に対応し、「ＦＳ（同一レコード内シーケンスＮｏ）」は、行管理テーブルの「ＦＳ（同一レコード内シーケンスＮｏ）」に対応する。「値１」〜「値ｎ」には、データ読込時に、列管理テーブルに定義した各データのカラム定義に従って、各データ項目が順番に特定され、読込レコードから分割された各フィールド値（データ項目値）が、列ＩＤの順番（テーブルＩＤ内の「連番」の順番）で格納される。
【０１１０】
なお、実施の形態５に係るデータ管理システムは、図２９に示したように、上記した以外のテーブル（ボリュームテーブル、ボリューム管理テーブル、システム管理テーブル、作業管理テーブル）も含む。また、上記各テーブルの日時情報に関するデータ項目である「有効日時（自）」、「有効日時（至）」等の日時情報は、各テーブルのデータ項目値（企業管理テーブルの企業情報、列管理テーブルのカラム定義等）が更新される場合に、その版（バージョン）管理に活用することができる。
【０１１１】
実施の形態６
図４９は本発明の実施の形態６に係るデータ管理システムをシステム開発支援ＣＡＳＥツールに適用する場合の概念を説明するブロック図である。図５０は本発明の実施の形態６に係るデータ管理システムのテーブル間の双方向のデータ変換の概念を説明するブロック図である。
図４９に示すように、実施の形態６に係るデータ管理システムは、上記各実施の形態のデータ交換機能のコアアーキテクチャを、異なるデータプロファイルの第１のデータ（例えば、発注データ）と第２のデータ（例えば、ユーザ指定データ）との間でのデータ変換（データ⇔データ交換）のみでなく、特定データプロファイルのデータと当該データについて指定された表示形式の画面表示との間でのデータ変換（データ⇔画面）や、特定データプロファイルのデータと当該データについて指定された印刷形式の帳票との間でのデータ変換（データ⇔帳票）等に派生させ、それを汎用的に制御するエンジンの開発を行い、実施の形態６に係るデータ管理システムとしてのＣＡＳＥツールとしている。なお、データ管理システムのスピードが問題になる場合はジェネレーション機能を加える事で対応する事とする。詳細には、データ管理システムのシステム仕様として、上記実施の形態１〜５におけるデータ変換アーキテクチャは、列管理テーブルに格納した第１のデータプロファイル（例えば、発注企業データプロファイル）のデータと、同列管理テーブルに格納した第２のデータプロファイル（例えば、受注企業データプロファイル）のデータとの間での双方向のデータ変換を実現するアーキテクチャである（テーブル⇔テーブル間データ変換）。即ち、テーブル間のデータ変換は、図５０に示すように、列管理テーブルに定義された定義情報（テーブルのデータ項目毎に作成されたレコード関連情報）のうちの所定の情報（列ＩＤ等）を、項目関連定義テーブルに定義することで実現する。
【０１１２】
図５１は本発明の実施の形態６に係るデータ管理システムのテーブルと帳票との間での片方向（一方向）のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
図５１（ａ）に示すように、所定データプロファイル（カラム定義）のデータを対応する帳票のデータプロファイル（帳票形式乃至帳票フォーマット）に変換する場合（テーブル⇒帳票（片方向））、即ち、テーブル内容（所定形式のデータ）を出力イメージ（帳票イメージ）に変換する際のデータ変換についても、図５１に示すように、列管理テーブルに定義された（テーブルのデータ項目毎に作成された）レコード関連情報を項目関連定義テーブルに定義することで実現する。しかし、出力イメージを制御する各種パラメータ（位置、フォント、フォントサイズ、色など）が必要な為、列管理テーブルの項目と１対１に対応した帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ（ｏｕｔ））テーブルを追加する。詳細には、図５１（ｂ）に示すように、具体例１は、ある企業（企業コード「１１１９９９０１」）の受注（「２０」）データから、標準の納品書（ＴＡ１）「０００２０１０１−０９」を出力する場合を示す。また、図５１（ｃ）に示すように、具体例２は、標準「０００００００１」の入荷予定（梱包）「４０」データから、ある企業（企業コード「１１１９９９０１」のＰＤラベル（独自）「４９」を出力する場合を示す。上記実施の形態の列管理テーブルのデータ種別「２９」は、標準の納品書として列管理テーブルに定義したものであるが、一般的な帳票のフォーマットであるＴＡ１及びＴＡ２を明確に分けて定義することが好ましい。例えば、プロファイル列管理テーブルにおいて、帳票ＴＡ１のテーブルＩＤ識別子を「０００２０１０１−０９」とし、帳票ＴＡ２のテーブルＩＤ識別子を「０００２０２０１−０９」とする等により対応する。また、上記実施の形態では、第１のデータプロファイルのデータと第２のデータプロファイルのデータとの間でのデータ変換（テーブル⇔テーブル間のデータ交換）しか行っていないが、本実施の形態では、所定のデータプロファイルのデータと所定の表示形式の帳票との間で野データ変換（データ⇒帳票）を追加するため、上記実施の形態ではかかる帳票出力のために表示プログラムに直接記述されていた出力を制御する各種パラメータ値を、プログラムから外出しにして管理するテーブル（帳票データプロファイル管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブル）を本実施の形態のデータ管理システムは用意している。こうしないと、出力すべき帳票が発生する度にプログラムを作成する必要があるからである。
【０１１３】
図５２は本発明の実施の形態６に係るデータ管理システムにおいて納品書の金額の表示方法が相違する場合の処理の概念を説明するブロック図である。
ここで、本データ管理システムを実施する際に注意すべきことは、例えば、納品書の金額の表示の方法である。例えば、データとしての「１０００」は「千円」を意味するが、その表示の方法は、「１，０００」もあれば「\１，０００」もあれば「１０００」もあり、その表示方法が企業毎に定められている点に注意する必要がある。即ち、図５２に示すように、データが「１０００」の場合で、納品書ＴＡ１を利用して、データ「１０００」について、Ａ企業では「１，０００」、Ｂ企業では「\１，０００」、Ｃ企業では「１０００」という表示方法が指定されている場合、企業毎に表示内容を変更する必要がある。この場合、項目関連定義テーブルによるデータ交換の際に、その表示方法に対応する必要がある。例えば、テーブルＩＤ「１１１９９９０１−２０」のデータ（テーブル格納データ）を、テーブルＩＤ「０００２０１０１−０９」のデータ（帳票表示フォーマットのデータ）にデータ変換する必要がある。つまり、帳票データプロファイル管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの出力フォーマットのパラメータ値は、同帳票データプロファイル管理テーブルには格納せず、単なる出力領域として扱い、「０００，０００，０００」、「＃＃＃，＃＃＃，＃＃０」、「\＃＃＃，＃＃＃，＃＃０」といったパラメータ値は、列管理テーブル或いは項目関連定義テーブルで実現する。また、ＰＤラベルの発行機能についても、当該変換機能を利用して実現する。この場合、バーコード作成関数を関数管理テーブルに追加する必要がある。
【０１１４】
図５３は本発明の実施の形態６に係るデータ管理システムのテーブルと表示画面との間での双方向のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
テーブル内容と表示画面の入出力データとを変換する際のデータ変換についても、本データ管理システムは、図５３に示すように、列管理テーブルに定義された（テーブルの項目毎に作成された）レコード関連情報を項目関連定義テーブルに定義することで実現する。しかし、この場合、表示画面の入出力データを制御する各種パラメータ（位置、フォント、フォントサイズ、色、ｉｎ／ｏｕｔ区分等）が必要な為、列管理テーブルの項目と１対１に対応した画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブル（上記帳票データプロファイル管理と同一構成）を追加している。具体例１は、表示された客注編集画面（識別子「０００９０１０１−０１」を使用し、入力されたデータから、ある企業（企業コード「１１１９９９０１」の受注（「２０」）データを登録・変更・削除する場合を示す。また、具体例２は、表示された在庫管理画面（識別子「０１０４０１０１−０１」）を使用し、在庫データを登録・変更・削除したり、当該画面より在庫一覧表の帳票を出力する場合を示す。なお、テーブルＩＤ識別子（テーブルＩＤ）については、現在の列管理テーブルにおけるテーブルＩＤの識別子は、企業コード（６桁）＋バージョン情報（２桁）＋データ種類（２桁）である（例えば、「１１１９９９０１２０」、「０００００００１３０」等）が、出力イメージのデータ格納域や画面に対応する入出力データ格納域のテーブルＩＤ識別子の命名ルールについても、同様に定めた所定規則の通りとする。
【０１１５】
図５４は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルを概略的に示す説明図である。図５５は本発明の実施の形態６に係るデータ管理システムで使用する帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルを概略的に示す説明図である。図５６は本発明の実施の形態６に係るデータ管理システムで使用する帳票（ＦＯＲＭ）テーブルを概略的に示す説明図である。
図５４に示すように、列管理テーブルは、上記各実施の形態と同様の構成である。また、図５５に示すように、帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、上記列管理テーブルと１対１で対応する項目を有している。詳細には、帳票列管理テーブルは、そのデータ項目（カラム）として、「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」、「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」、「カラム名（ＣＯＬＵＭＮ＿ＮＡＭＥ）」、「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」、「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」を有している。「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」と「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」とは、１対１で対応している。「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」には、帳票に印刷するデータ項目の項目値の左端位置、上端位置、幅、高さ、フォントサイズがそれぞれ格納される。帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、帳票単位にレコードを作成する。フォームＩＤ（ＦＯＲＭ＿ＩＤ）は、テーブルＩＤと同じ命名ルールにすることができる。従って、フォームＩＤ（ＦＯＲＭ＿ＩＤ）は不要とすることもできる。また、企業別データプロファイル（ＥＸＣＨＡＮＧＥ＿ＤＡＴＡ）テーブルに格納する各社の納品書やＰＤラベルのフォーマットの指定欄にも、テーブルＩＤコードを指定する。従って、帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルのインデックス及びキー項目は、プロファイル項目管理（ＣＯＬＵＭＮ）テーブルと同様にする必要は無い。なお、図５６に示すように、帳票イメージは、前記「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」に対応して、帳票（ＦＯＲＭ）テーブルのデータ項目「イメージファイル（ＩＭＡＧＥ＿ＦＩＬＥ）」の値として格納され、また、その幅及び高さも「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」の値として格納されている。
【０１１６】
図５７は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルの設定例を概略的に示す説明図である。図５８は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブルの設定例を概略的に示す説明図である。図５９は本発明の実施の形態６に係るデータ管理システムで使用する画面表示（Ｆｏｒｍ）テーブルの設定例を概略的に示す説明図である。図６０は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブルの設定例を説明するブロック図である。
図５７に示すように、列管理テーブルは、上記各実施の形態と同様の構成である。また、図７７に示すように、画面表示プロファイル項目管理（Ｆｏｒｍ＿ＣＯＬＵＭＮ）テーブル（帳票プロファイル項目管理テーブルと同一構成）は、上記列管理テーブルと１対１で対応する項目を有している。詳細には、画面表示列管理テーブルは、そのデータ項目（カラム）として、「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」、「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」、「カラム名（ＣＯＬＵＭＮ＿ＮＡＭＥ）」、「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」、「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」を有している。「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」と「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」とは、１対１で対応している。「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」には、表示画面に表示するデータ項目の項目値の左端位置、上端位置、幅、高さ、フォントサイズがそれぞれ格納される。画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、画面表示単位にレコードを作成する。フォームＩＤ（ＦＯＲＭ＿ＩＤ）は、テーブルＩＤと同じ命名ルールにすることができる。従って、フォームＩＤ（ＦＯＲＭ＿ＩＤ）は不要とすることもできる。また、企業別データプロファイル（ＥＸＣＨＡＮＧＥ＿ＤＡＴＡ）テーブルに格納する各社の納品書やＰＤラベルのフォーマットの指定欄にも、テーブルＩＤコードを指定する。従って、画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルのインデックス及びキー項目は、プロファイル項目管理（ＣＯＬＵＭＮ）テーブルと同様にする必要は無い。なお、図５８に示すように、画面表示イメージは、前記「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」に対応して、画面表示（ＦＯＲＭ）テーブルのデータ項目「イメージファイル（ＩＭＡＧＥ＿ＦＩＬＥ）」の値として格納され、また、その幅及び高さも「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」の値として格納されている。図６０に示すように、本データ管理システムは、プロファイル列管理テーブルにテーブル内のコアデータに関する定義（カラム定義）を格納すると共に、画面表示プロファイル列管理テーブルに表示データに関する定義（フォーム定義）を格納し、更に、項目関連定義テーブルに表示データとコアデータとの変換内容を定義する。そして、特定の画面表示のデータ項目のフォームＩＤに、項目関連定義テーブルのリンク情報（データ関連情報）を介して、列管理テーブルの列ＩＤのデータ項目を１対１で対応付け、コアデータと表示データとのデータ変換を行う。なお、このようにしてデータ変換された表示データは、画面表示テーブルに格納した表示に関する定義（フォーム定義）に従って表示される。
【０１１７】
ここで、画面表示テーブルと画面表示列管理テーブルとの間では、双方向のデータ変換が行われ、例えば、客注入力に対応できるようになっている。具体的には、例えば、所定の発注企業の指定納品書は、チェーンストア協会統一伝票（ＴＡ１）であるとする。この場合、以下に番号（１）〜（２１）を附した各項目（画面項目：[関連データ項目]）から入出力仕様を記述する。なお、入力項目は、下記番号（１）〜（３）及び（２３）、（２６）及び（２９）の項目である。また、下記番号（２１）、（２２）、（２４）、（２５）、（２７）の項目は、商品マスタあるいは過去データからの導出が可能であるため、キー項目入力時に取得することが好ましい。
伝票ヘッダ部
（１）  A欄：[支払条件]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（２）  B欄：[分割回数]⇒数値入力チェック、桁数1
（３）  D欄：[ルートコード]⇒テキスト入力、フォーマットチェック（＊＊＊  ＴＡ９９  ＊＊）
（４）  訂正区分：[訂正有無]⇒＜客注入力では未使用？＞
（５）  実納品日：[出荷日]⇒日付入力チェック
（６）  社名：[発注企業名称]⇒デフォルト表示「デジタル」
（７）  取引先名：[受注企業名称]⇒デフォルト表示「ヤマダサンギョウ」
（８）  店名：[発注店舗名]⇒テキスト入力、桁数、半角カタカナチェック
（９）  社・店コード：[店コード]⇒数値チェック（※存在チェックはしない）
（１０）  分類コード：[部門コード]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（１１）  伝票区分：[伝票区分]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（１２）  伝票番号：[伝票No]⇒数値入力チェック、桁数８
（１３）  取引先コード：[取引先コード]⇒デフォルト表示（EXCHANGEテーブル格納値）
（１４）  発注日：[発注日]⇒日付入力チェック
（１５）  納品日：[納品指定日]⇒日付入力チェック
（１６）  数量合計：[発注数量合計]⇒計算表示（明細数量を合計）
（１７）  原価金額合計：[原価金額合計]⇒計算表示（明細原価金額を合計）
（１８）  売価金額合計：[売価金額合計]⇒計算表示（明細売価金額を合計）
（１９）  F欄：[島番号（−）台番]⇒テキスト入力、フォーマットチェック（９９−９９９９）
（２０）  L欄：[（客注摘要内容等）]⇒＜※受注企業側で適宜入力＞伝票明細×６
（２１）  品名：[品名]⇒テキスト入力、桁数、半角カタカナチェック
（２２）  規格：[規格]⇒テキスト入力、桁数、半角カタカナチェック
（２３）  商品コード：［ＪＡＮコード］⇒数値入力チェック、桁数１３
（２４）  入数：［入数］⇒数値入力チェック、桁数３
（２５）  ケース：［ケース］⇒数値入力チェック、桁数３
（２６）  数量：［発注数量］⇒数値入力チェック、桁数４
（２７）  原単価：［単価］⇒数値入力チェック、桁数７
（２８）  原価金額：［原価金額］⇒計算表示（数量×原単価を計算）
（２９）  売単価：［売単価］⇒数値入力チェック、桁数７
（３０）  売価金額：［売価金額］⇒計算表示（数量×売単価を計算）
明細行の項目の下線（破線）で示した項目は、過去データからの導出が可能である為、導出した後に修正できるようにすることが望ましい。また、納品書発行、出庫指示書発行、客注入力、出荷数量訂正などの機能は、上記プログラムで対応可能とする。  
【０１１８】
データ管理システムの処理（実施の形態２〜６）
図６１は本発明の各実施の形態２〜６に係るデータ管理システムの発注企業データ読込・格納処理を示すフローチャートである。
図６１に示すように、発注企業データ読込・格納処理では、まず、ＳＴＥＰ１１で、ファイル名あるいは受信データの格納場所から、どの企業から受信したデータ（例えば、発注データ）かを判断し、データ交換の可否をチェックする。次に、ＳＴＥＰ１２で、テーブル管理テーブルのＣＯＮＴＲＯＬ＿ＩＮＩ(制御情報)に基づき、読込んだデータを順次分析しながら、レコード単位に分割する。次に、ＳＴＥＰ１３で、発注企業コード（＋版ＮＯ）＋データ種類＋枝番からなるテーブルＩＤを特定する。次に、ＳＴＥＰ１４で、特定したテーブルＩＤに基づき、列管理テーブルを参照し、データ項目のシーケンスＮｏ．(連番)に従って、各読込レコードの各データ項目値を分割する。次に、ＳＴＥＰ１５で、所定規則に基づき、行グループ（ＲＯＷ＿ＧＲＯＵＰ）及び行ＩＤ（ＲＯＷ＿ＩＤ＝ＲＯＷ＿ＧＲＯＵＰ＋ＲＯＷ＿ＩＤ＿ＳＥＱ）を発番する。次に、ＳＴＥＰ１６で、各読込レコードのデータ項目値から、識別子の値、突合項目値、基本項目値（伝票Ｎｏ．、発注日等）を抽出し、行ＩＤ、テーブルＩＤ等と共に行管理テーブルに格納する。次に、ＳＴＥＰ１７で、各読込レコードの全データ項目値（分割）を、テーブルＩＤ等と共に値管理テーブルの各行に順次格納し、発注企業から受信したオリジナルデータ（一次データ）のみを作成し、処理を終了する。
【０１１９】
図６２は本発明の各実施の形態２〜６に係るデータ管理システムの伝票一覧表示処理を示すフローチャートである。
図６２に示すように、伝票一覧表示処理は、ＳＴＥＰ５１で、検索条件を入力すると、ＳＴＥＰ５２で、検索条件が判断される。ＳＴＥＰ６１で、表示種類が「データ種類別」の場合、ＳＴＥＰ６２で、行管理テーブルの該当レコード読込み、ＳＴＥＰ６３で、データ種類別伝票を一覧表示し、処理を終了する。また、ＳＴＥＰ７１で、表示種類が「発注企業別」の場合、ＳＴＥＰ７２で、行管理テーブルの該当レコードを読込み、ＳＴＥＰ７３で、発注企業別伝票を一覧表示し、処理を終了する。ＳＴＥＰ８１で、表示種類が日付範囲別の場合、ＳＴＥＰ８２で、行管理テーブルの該当レコードを読込み、ＳＴＥＰ８３で、日付範囲別伝票を一覧表示して、処理を終了する。
【０１２０】
図６３は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理を示すフローチャートである。
図６３に示すように、伝票詳細表示処理は、ＳＴＥＰ１０１で、伝票の選択及び表示指定を行うと、ＳＴＥＰ１０２で、指定内容を判断し、ＳＴＥＰ１１０で指定内容が発注企業オリジナルデータの場合、ＳＴＥＰ１１１で発注企業オリジナルデータのテーブルＩＤで列管理テーブルを検索する。そして、ＳＴＥＰ１１２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１１３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１２０で、指定内容が発注企業伝票データの場合、ＳＴＥＰ１２１で、発注企業伝票データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１２２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１２３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１３０で、指定内容がシステム標準データの場合、ＳＴＥＰ１３１で、システム標準データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１３２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１３３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１４０で、指定内容が受注企業指定データの場合、ＳＴＥＰ１４１で、受注企業指定データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１４２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得して、ＳＴＥＰ１４３で、取得値をデータ項目順にセット表示する。
【０１２１】
図６４は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業オリジナルデータ取得処理を示すフローチャートである。
図６４に示すように、発注企業オリジナルデータ取得処理は、ＳＴＥＰ１１２Ａで、発注企業オリジナルデータのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値を格納するレコード群を確定する。次に、ＳＴＥＰ１１２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。
【０１２２】
図６５は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業伝票データ取得処理を示すフローチャートである。
図６５に示すように、発注企業伝票データ取得処理は、ＳＴＥＰ１２２Ａで、発注企業伝票データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１２２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１２２Ｃで、項目関連定義テーブルを参照し、発注企業伝票データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤをキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。次に、ＳＴＥＰ１１２Ｄで、項目関連情報に基づき、発注企業伝票データの各データ項目に、対応するオリジナルデータの項目値を代入する。
【０１２３】
図６６は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理におけるシステム標準データ取得処理を示すフローチャートである。
図６６に示すように、システム標準データ取得処理は、ＳＴＥＰ１３２Ａで、システム標準データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１３２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１３２Ｃで、項目関連定義テーブルを参照し、システム標準データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤ（標準データ用）をキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。そして、ＳＴＥＰ１３２Ｄで、項目関連情報に基づき、システム標準データの各項目に、対応するオリジナルデータの項目値を代入する。
【０１２４】
図６７は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における受注企業指定データ取得処理を示すフローチャートである。
図６７に示すように、受注企業指定データ取得処理は、ＳＴＥＰ１４２Ａで、受注企業指定データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１４２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１４２Ｃで、項目関連定義テーブルを参照し、受注企業指定データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤ（指定データ用）をキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。そして、ＳＴＥＰ１４２Ｄで、項目関連情報に基づき、受注企業指定データの各項目に、対応するオリジナルデータの項目値を代入する。
【０１２５】
図６８は本発明の各実施の形態２〜６に係るデータ管理システムのデータ出力処理を示すフローチャートである。
図６８に示すように、データ出力処理は、ＳＴＥＰ１５１で、出力指定が行われると、ＳＴＥＰ１５２で、指定内容を判断する。ＳＴＥＰ１６０で、指定内容が発注企業伝票データの場合、ＳＴＥＰ１６１で、発注企業伝票データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１６２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１６３で、取得値を発注企業伝票データ格納手段に格納する。ＳＴＥＰ１７０で、指定内容がシステム標準データの場合、ＳＴＥＰ１７１で、システム標準データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１７２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１７３で、取得値をシステム標準データ格納手段に格納する。ＳＴＥＰ１８０で、指定内容が受注企業指定データの場合、ＳＴＥＰ１８１で、受注企業指定データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１８２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１８３で、取得値を受注企業指定データ格納手段に格納する。なお、ＳＴＥＰ１６２，１７２，１８２の各モジュールは、前記ＳＴＥＰ１２２，１３２，１４２のモジュールと同様である。
【０１２６】
図６９は本発明の各実施の形態２〜６に係るデータ管理システムの項目値変換処理を示すフローチャートである。
図６９に示すように、項目値変換処理は、ＳＴＥＰ２０１で、発注企業データを読込むと、ＳＴＥＰ２１０，２２０，２３０，２４０，２５０，２６０で、項目名称検証、項目内容検証、属性検証、表示方法検証、桁数検証、ドメイン値検証をそれぞれ実行する。ＳＴＥＰ２１０で、項目名称が検証され、ＳＴＥＰ２１１で、異名異義語と判断されると、ＳＴＥＰ２１２で、関連定義が行われる。ＳＴＥＰ２２０で、項目内容が検証され、ＳＴＥＰ２２１で、同名異議語と判断されると、ＳＴＥＰ２２２で、関連不定義が行われる。ＳＴＥＰ２３０で、属性（データ型）が検証され、ＳＴＥＰ２３１で、関連定義が有りと判断されると、ＳＴＥＰ２１２で、関連定義に基づき属性の変換が行われる。ＳＴＥＰ２４０で、表示方法が検証され、ＳＴＥＰ２４１で、変更オプション有りと判断されると、ＳＴＥＰ２４２で、表示方法の変更が行われる。ＳＴＥＰ２５０で、桁数が検証され、ＳＴＥＰ２５１で、桁落ちが有りと判断されると、ＳＴＥＰ２５２で、警告表示・修正処理が行われる。ＳＴＥＰ２６０で、ドメイン値が検証され、ＳＴＥＰ２６１で、コード代入が有りと判断されると、ＳＴＥＰ２６２で、コードの意味変換が行われる。これらの項目値変換の詳細は、上述のとおりである。
【０１２７】
図７０は本発明の実施の形態１〜６に係るデータ管理システムのデータ変換処理及び表示処理の特徴を説明するブロック図である。図７１は図７０との比較のために従来のデータ管理システムのデータ変換処理の表示処理を説明するブロック図である。
図７１に示すように、従来のデータ管理システムとしての受発注管理システム６００は、Ａ社、Ｂ社，Ｃ社・・・等の各取引先（発注企業）に固有のデータプロファイルの発注データ（実データ）を、それぞれの発注企業用にカラム定義（リレーションスキーマ設計）をして、発注データテーブル６１１，６１２，６１３・・・を作成する。そして、それぞれの発注企業用の発注データテーブル６１１，６１２，６１３・・・用に作成した表示プログラム６２１，６２２，６２３・・・により、発注データテーブル６１１，６１２，６１３・・・の実データを画面１に表示する。また、従来の受発注管理システム６００は、各発注データテーブル６１１，６１２，６１３・・・用に作成した変換プログラム（ＰＧ）を利用して、各発注データテーブル６１１，６１２，６１３・・・からユーザ受注データ６１４を作成する。そして、ユーザ受注データ６１４用に作成した表示プログラム６２４により、ユーザ受注データテーブル６１４の実データを画面１に表示する。
【０１２８】
一方、図７０に示すように、実施の形態１〜６に係るデータ管理システムは、前述したように、Ａ社、Ｂ社、Ｃ社等の各社の発注データ等（実データ）は、基本的に、トランザクションデータ系としての値管理テーブル２１３に、行ＩＤ、テーブルＩＤ（またはテーブルＩＤ）と共に、値１〜値ｎとして全て格納される。また、各レコードのインデックスとしての行ＩＤ、テーブルＩＤ、識別子、突合値等が、行管理テーブル２１２に格納される。また、各社の実データを上述した各種表示形式で表示する表示プログラム２６は、共通のものが一つのみ用意されている。そして、例えば、Ａ社の実データやＢ社の実データを表示プログラム２６を介して画面１にユーザ指定形式で表示する場合、マスタデータ系による変換処理として、列管理テーブル２１１のＡ社やＢ社のデータ項目定義（カラム定義）が参照されると共に、項目関連定義テーブル２１７の項目関連定義が参照されて、ユーザのカラム定義とＡ社やＢ社のカラム定義とのリンク情報が取得され、かかるリンク情報を介して、Ａ社やＢ社の実データがユーザ企業の指定形式の表示態様で、画面１に表示される。
【０１２９】
具体的には、例えば、Ａ社の発注データのレコード（行ＩＤ「Ｒ１」）の項目値は、値管理テーブル２１３において、行管理テーブル２１２の行ＩＤ「Ｒ１」と列管理テーブル２１１の列ＩＤ「Ｃ１１，Ｃ１２，Ｃ１３，Ｃ１４」とで特定される各行に実データとして格納されている。表示プログラム２６は、この実データ（値管理テーブル２１３の４行分のデータ）を取得し、Ａ社発注（実）データとして画面１に所定フォーマットで表示する。Ｂ社、Ｃ社の発注データについても同様である。また、Ａ社発注データを標準フォーマットで表示する場合、項目関連定義テーブル２１７におけるＡ社フォーマットの発注データのデータ項目に対応する列ＩＤをトリガ列ＩＤとして、当該データ項目の値が標準フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。そして、表示プログラム２６は、当該標準フォーマットの発注データのデータ項目にセットしたＡ社の発注データの項目値（実データ）を取得し、Ａ社発注（標準フォーマット）データとして画面１に表示する。これと逆に、Ｂ社発注データ（実データ）を標準フォーマットを介してユーザ指定形式データで表示する場合、項目関連定義テーブル２１７におけるＢ社フォーマットの発注データのデータ項目に対応する列ＩＤをトリガ列ＩＤとして、当該データ項目の値が標準フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。次に、当該標準フォーマットの発注データの列ＩＤをトリガ列ＩＤとして、当該データ項目の値がユーザ指定フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。そして、表示プログラム２６は、標準フォーマットを介して当該ユーザ指定フォーマットの発注データのデータ項目にセットしたＢ社の発注データの項目値（実データ）を取得し、ユーザ発注（ユーザフォーマット）データとして画面１に表示する。
【０１３０】
実施の形態７
図７２は本発明の実施の形態７に係るデータ管理システムの列管理テーブルを示す説明図である。
図７２に示すように、実施の形態７に係るデータ管理システムは、管理対象データとして、医療機関で使用されるレセプトコンピュータデータ（レセコンデータ）を取り扱い、異なるデータプロファイル（カラム定義）を有する多数の医療機関（Ａ，Ｂ・・・）のレセコンデータを列管理テーブルにカラム定義すると共に、上記と同様にして、標準データプロファイル（標準レセコン）を介して、データ変換を行う。なお、図７２の列管理テーブルは、上記実施の形態の列管理テーブルと同様のものである。具体的には、列管理テーブルは、上記列管理テーブルと同様のデータ項目を有している。一方、列管理テーブルの「テーブルＩＤ」にはレセコンのテーブル種別を一意に示すデータが格納される。なお、図７２では、説明の便宜上、「標準レセコン」等の文字列を格納しているが、実際は、各テーブルを一意に示すコードが格納される。また、列管理テーブルのデータ項目名（項目名称）には、各テーブル（標準レセコンテーブル等）のデータ項目の項目名称が、列ＩＤに対応して順に格納されている。なお、列ＩＤ、企業ＩＤ、枝番、連番等のその他のデータ項目は、上記各実施の形態の列管理テーブルの列ＩＤ、企業ＩＤ、枝番、連番等と同様のものである。
【０１３１】
実施の形態８
図７３は本発明の実施の形態８に係るデータ管理システムの関数管理テーブルを示す説明図である。
図７３に示すように、関数管理テーブル（第１の具体例）は、従来はプログラムの内部に定義されていた関数内容やパラメータや格納先を、プログラムから外出しして、その項目値として格納するものであり、加算、減算等の演算に加え、任意の演算処理をテーブル内に定義して実行することができる。これにより、実施の形態８に係る関数テーブルによれば、上記実施の形態で述べたように、プログラムの追加、削除、変更に用意に対処することができる。関数管理テーブルは、データ項目として、「関数ＩＤ」、「関数名」、「関数内容」、「パラメータ１」、「パラメータ２」、「パラメータ３」・・・「格納先」等を有している。「関数ＩＤ」は、関数ごとに一意に割り当てられるコードである。「関数名」は、各関数の名称を示す（加算、減算等）。「関数内容」は、各関数の内容（処理手順）を示す（例えば、加算の場合、Ａ＋Ｂ）。「パラメータ１」、「パラメータ２」、「パラメータ３」等のパラメータは、対応する関数内容の処理（演算等）でパラメータとして使用され、必要なパラメートをこれらのパラメータ１，２，３・・・に格納しておく。「格納先」は、対応する関数の戻り値を格納する記憶領域を示す。
【０１３２】
実施の形態９
図７４は本発明の実施の形態９に係るデータ管理システムの関数テーブルを示す説明図である。
図７４に示すように、関数テーブル（第２の具体例）は、上記実施の形態と同様、従来はプログラムの内部に定義されていた関数内容や入力や出力を、プログラムから外出しして、その項目値として格納するものであり、上記実施の形態で述べたように、プログラムの追加、削除、変更に用意に対処することができる。関数テーブルは、データ項目として、「関数ＩＤ」、「出力」、「関数」、「入力」等を有している。「関数ＩＤ」は、関数ごとに一意に割り当てられるコードである。「出力」は、各関数の出力を示す。「関数」は、各関数の内容（処理手順）を示す（例えば、Ｆ１の場合、＊２）。「入力」は、各関数の入力を示す。例えば、図７４の関数「Ｆ１」は、入力Ａを２倍（＊２）した値を出力Ｃとして出力する関数を示す。
【０１３３】
実施の形態１０
図７５は本発明の実施の形態１０に係るデータ管理システムの索引管理テーブルを示す説明図である。図７６は本発明の実施の形態１０に係るデータ管理システムの行関連管理テーブルを示す説明図である。
図７５に示す索引管理（ＩＮＤＥＸ）テーブルは、上記各実施の形態の行管理テーブルにおける突合値を外出しにして管理するものである。索引管理テーブルは、データ項目として、「ＩＤ」、「行ＩＤ」、「オブジェクトＩＤ」、「列ＩＤ」、「値」、「内容」を有している。「ＩＤ」は、行管理テーブルで使用するインデックス乃至検索キー（例えば、突合値）に対応して自動的に発行されるものである。「行ＩＤ」は、行管理テーブルの行ＩＤに対応する。「オブジェクトＩＤ」は、対象管理テーブルのオブジェクトＩＤに対応する。「列ＩＤ」は、列管理テーブルの列ＩＤに対応する。「値」は、対応するオブジェクトＩＤの値（データ項目値）を示す。「内容」は、対応するオブジェクトＩＤの値の内容（データ項目名）を示す。なお、前記「列ＩＤ」及び「内容」は、省略しても良い。このように、少なくとも、行ＩＤ、オブジェクトＩＤ及び値を索引管理テーブルに外出しにして格納することにより、それらを列管理テーブルや行管理テーブルに格納してインデックスを管理する場合と比べ、より柔軟にデータ管理を行うことができる。例えば、インデックスを追加、削除、変更等する場合、索引管理テーブル内のレコードを追加、削除、変更等するだけですみ、保守も容易となる。なお、索引管理テーブルに格納したインデックスの使用方法は、上記発注データと出荷予定データとの間での突合処理の説明で述べたものと同様であり、突合処理等の検索処理において、必要な項目値が索引管理テーブルから随時抽出される。
【０１３４】
図７６に示す行関連管理（ＲＯＷ＿ＣＨＡＩＮ）テーブルは、上記各実施の形態の列管理テーブル等における枝番を外出しにして管理するものである。行関連管理テーブルは、データ項目として、「ＩＤ」、「行ＩＤ」、「親行ＩＤ」、「親数」、「関連値」、「内容」を有している。「ＩＤ」は、行管理テーブルに格納するレコード間に親子関係や階層構造等の関連がある場合に、その関連に対応して自動的に発行されるものである。「行ＩＤ」は、行管理テーブルの行ＩＤに対応する。「親行ＩＤ」は、対応する行ＩＤのレコード（またはテーブル）に親となるレコード（またはテーブル）がある場合に、その親となるレコード（またはテーブル）の行ＩＤを示す。「親数」は、対応する行ＩＤのレコード（またはテーブル）に親となるレコード（またはテーブル）がある場合に、その親となるレコード（またはテーブル）の数を示す。「関連値」は、対応する親行ＩＤのレコードの識別子の値を示す。「内容」は、対応する行ＩＤのレコードの内容（レコード名やテーブル名等）を示す。なお、前記「関連値」及び「内容」は、省略しても良い。このように、少なくとも、行ＩＤ、親行ＩＤ及び親数を行関連管理テーブルに外出しにして格納することにより、それらを列管理テーブル等に格納して親子関係や階層構造等のレコード関連情報を管理する場合と比べ、より柔軟にデータ管理を行うことができる。例えば、レコード関連情報を追加、削除、変更等する場合、行関連管理テーブル内のレコードを追加、削除、変更等するだけですみ、保守も容易となる。更に、図７６の表の下側に示すように、行関連管理テーブルにより、発注データのような階層構造を有するレコード（親が一つの場合）の管理が可能となるだけでなく、あるレコード（またはテーブル）が親を複数有する場合の管理も可能となる。
【０１３５】
例えば、階層構造のレコードからなる発注データの場合、行ＩＤ「ＳＹＳ００１」のファイルヘッダの下位に、行ＩＤ「ＳＹＳ００２」の伝票ヘッダがリンクまたは従属し、行ＩＤ「ＳＹＳ００２」の伝票ヘッダの下位に、行ＩＤ「ＳＹＳ００３〜ＳＹＳ００７」の伝票明細（１〜５）がリンクまたは従属している。また、行ＩＤ「ＳＹＳ００１」のファイルヘッダには親レコードはないため、その親数は「０」となる。一方、行ＩＤ「ＳＹＳ００２」の伝票ヘッダには親レコードとしてファイルヘッダ（ＳＹＳ００１）があるため、その親数は「１」となる。更に、行ＩＤ「ＳＹＳ００３〜ＳＹＳ００７」の伝票明細には親レコードとして伝票ヘッダ（ＳＹＳ００２）があるため、その親数はそれぞれ「１」となる。一方、複数の親を有するレコードまたはテーブルを管理する場合について説明すると、例えば、顧客単価マスタテーブル（ＳＹＳ９０３）は、顧客マスタテーブル（ＳＹＳ９０１）と商品マスタテーブル（ＳＹＳ９０２）の２つを親として持つ。よって、顧客単価マスタテーブルの行ＩＤ（ＳＹＳ９０３）は、行関連管理テーブルの２行にわたって格納され（ＩＤ＝４７５２及び４７５３）、各行ＩＤの親行ＩＤに、顧客マスタテーブルの行ＩＤ（ＳＹＳ９０１）と商品マスタテーブルの行ＩＤ（ＳＹＳ９０２）とが格納されている。また、顧客単価マスタテーブルの行ＩＤ（ＳＹＳ９０３）は、親数に「２」を格納している。これにより、行関連管理テーブルを参照するだけで、行管理テーブルに格納して特定のレコードの親子関係や階層関係のレコード関連情報を取得することができ、また、その編集も容易となる。
【０１３６】
以上のように詳述した本発明に係るデータ管理システムについて、その主要な特徴を以下に要約する。
特徴１：列管理テーブル、行管理テーブル及び値管理テーブルの３つの物理テーブルのみからなる基本的物理データ構造。これにより、従来の物理データ構造のテーブル（物理テーブル）がいくつあっても、その全てのデータ（項目内容及び項目値）を３つの物理テーブル（列管理テーブル、行管理テーブル及び値管理テーブル）で格納・管理できる。
１）列管理テーブルは、従来のテーブルのカラム（各ドメインの属性）を定義・管理するテーブルである。また、列管理テーブルは、従来の各種データ（例えば、図４〜８に示す商品マスタデータ、顧客マスタデータ、顧客単価マスタデータ、在庫マスタデータ、発注データ等）のデータフォーマット（プロファイル）を定義する。即ち、列管理テーブルは、これらのデータを格納する従来のデータの入れ物（物理テーブル）の設計情報（リレーションスキーマ）を定義する。具体的には、列管理テーブルは、データの入れ物（物理テーブル）の設計情報（リレーションスキーマ）である従来の物理テーブルのカラム（データ項目乃至属性とも呼ばれる）のカラム名（データ項目名）を格納する。また、列管理テーブルの各カラム名に対し一意の列ＩＤが付与される。更に、列管理テーブルで定義する管理対象レコードの各データ項目に対応して、列ＩＤの他、当該データ項目のデータ型や位置や長さ等、当該データ項目を定義するための他の情報を格納してもよい。なお、列ＩＤにより、従来の物理テーブルの各データ項目の属性情報（属性名、データ型、長さ等）を一意に識別・取得する。また、列管理テーブルに格納されるデータはマスタデータとなる。また、従来の物理テーブルのカラム名等（例えば、商品マスタテーブルの場合の「商品名」、「商品ＩＤ」）は、本発明の列管理テーブルのカラム（データ項目）としてではなく、データ項目値（各属性の値）として格納・定義される。そして、列管理テーブルのカラム（データ項目）には、データ項目値として格納される従来のカラム（データ項目）を識別する統括名称（「項目名」、「列ＩＤ」、「データ型」等）が定義される。また、例えば、従来の商品マスタテーブルは、カラム（データ項目）として「商品ＩＤ」、「商品名」、「単価」等を所定順序（所定の並び方）で定義し、それらのカラムに対応して、各レコードにおけるデータ項目値（フィールド値）として「００１」、「たばこ」、「２００円」等を格納する。一方、本発明の列管理テーブルは、カラム（「列ＩＤ」、「カラム名」等）のデータ項目値として、従来の商品マスタテーブルのフォーマットを定義する各フィールドの属性（従来のカラムである「商品ＩＤ」、「商品名」等）を格納する。
２）行管理テーブルは、基本的に、インデックス情報を格納するテーブルであり、特定データを読み込んで格納する場合に、読み込み（入力）データの各レコード（従来の物理テーブルの行単位のデータ）を読み込んだ順に、各行を一意に識別するためのインデックスとして行ＩＤを付与し、行ＩＤを行管理テーブルにその順番で格納する。また、行管理テーブルに格納されるデータはトランザクション系のデータとなる。また、例えば、カラムとして「商品ＩＤ」、「商品名」、「単価」等を所定順序（所定の並び方）で定義する商品マスタデータを読み込む場合に、各レコードの値（フィールド値）としての「００１」、「たばこ」、「２００円」（１番目のレコード）、「００２」、「チョコ」、「１００円」（２番目のレコード）・・・を読み込むごとに、行ＩＤを順番に自動生成して行管理テーブルに格納する（「Ｒ０１」、「Ｒ０２」・・・等）。
３）値管理テーブルは、データ項目値（ドメイン値ともいう）を格納するテーブルであり、特定データを読み込んで格納する場合において、読み込み（入力）データの各レコード（従来の物理テーブルの行単位のデータ）を読み込むごとに、当該レコードを構成する各フィールドの値を行ＩＤと対応させて格納する。このとき、当該読込レコードの種類（データ名・テーブル名等）に応じて、列管理テーブルを参照し、該当する種類のレコードのテーブルＩＤを判断・抽出する。これにより、当該テーブルＩＤによりデータ項目名と値とが対応する。或いは、当該レコードを構成する各フィールドの値（データ項目値）を値管理テーブルの一行に全て格納する。このとき、当該読込レコードの種類（データ名・テーブル名等）に応じて、列管理テーブルを参照し、該当する種類のレコードのテーブルＩＤを判断・抽出し、当該テーブルＩＤのデータ項目名の順番で値を格納する。これにより、対応する行のセルに一連のデータ（値）として格納する。各行は行ＩＤで識別され、各値は行ＩＤと列ＩＤとにより特定される。また、値管理テーブルに格納されるデータはトランザクション系のデータである。また、列ＩＤと行ＩＤとにより一意に決定される場所（各フィールド）にデータ項目の各値（各フィールドの値）を格納する。また、各レコードを読み込んだ際に、当該レコードに自動付与された行テーブルの行ＩＤと、当該レコードの設計情報（データ項目の属性情報）を識別する列テーブルの列ＩＤとによりセルを特定（列及び行を特定）し、特定されたセルにデータ項目の値を格納する。
【０１３７】
特徴２：業務内容に応じてデータ項目内容（スキーマ）を動的に変更
１）列管理テーブルに、取り扱う全ての管理対象データ（既知のデータ）の定義（従来の物理構造のテーブルの定義）がデータ項目値として格納される。即ち、全てのデータの物理構造（フォーマット定義）が一つの列管理テーブル内に順に格納・定義される。また、列管理テーブルのみを変えることで、動的に項目内容を変更できる。また、データの物理構造と業務内容を分離して管理することができる。
２）いずれかのデータの物理構造（フォーマット定義）が変更された場合（例えば、項目追加・削除・修正）、列管理テーブルのデータ項目値を追加・削除・変更するという通常のデータ編集操作で、そのデータの物理構造の変更を列管理テーブルに反映し、データの物理構造を変更することができる。
３）従来は、入れ物そのものを業務に合わせて作成する。よって、業務内容に応じて、業務内容の数だけ、異なるスキーマ乃至物理データ構造（データフォーマット）を有する複数（多数）のテーブルが必要となる。即ち、従来のテーブルは、それぞれ、業務内容を反映したスキーマを有する。このため、各テーブルのカラムのデータ項目は、スキーマにより固定され、データ項目の修正（追加・削除・編集）には修正用の特殊な処理が必要になる（例えば、市販データベースソフトの場合、テーブルのカラムの各データ項目の追加・削除・編集は、裏でプログラムが処理している）。
４）本発明は、取り扱うデータの全ての情報（列情報、行情報及びセルの値）を上記３つのテーブル（列テーブル、行テーブル、値管理テーブル）に分けて格納する。即ち、全てのテーブルの物理データ構造（列のデータ項目の属性情報）を列テーブルにデータ項目値（マスタデータ）として格納して列ＩＤにより識別し、読み込んだレコードのインデックスを行テーブルに行ＩＤとして格納し、読み込んだレコードの各データ項目値を列ＩＤと行IDとにより決定した値管理テーブルのセルに格納する。よって、業務ルールをデータの物理構造（物理データ構造）に反映しなくてよい。
５）即ち、データを格納する際のテーブルの物理構造（入れ物の設計情報）を列管理テーブルにデータ項目値として格納し、定義している。よって、業務内容がどのようなものであろうと、常に、３つの物理構造のテーブル（列テーブル、行テーブル、値管理テーブル）で全てのデータを処理（格納、取得、加工、出力、表示等）することができる。
６）例えば、顧客テーブル、単価テーブル、顧客販売単価テーブルの３つのテーブルのフォーマットを一つの列管理テーブルに格納・定義する。１レコード入力ごとに行管理テーブルの行ＩＤをインクリメントし、その列ＩＤと行ＩＤとに対応するデータ項目値をセルに入力する。この列管理テーブル、行管理テーブルおよび値管理テーブルを利用して、顧客販売単価プログラムを容易に実現できる。
７）従来は、データを静的に定義している（業務に対応した物理構造のテーブルを定義・設計しており、設計内容にデータ項目が静的に定義されている）。即ち、データの項目内容は、テーブル作成時にテーブルのカラムとして固定されているため、容易に変更することはできない。変更するには、直接属性を追加・削除・変更するというテーブルの再定義が必要。したがって、物理テーブルを修正（項目追加・削除・内容変更）すると、その物理テーブルのテーブル構造（定義）自体が変わることになるため、その物理テーブル用の表示プログラムを修正して修正後のデータを画面表示する必要があった。
８）本発明は、項目追加・削除・変更の場合でも、列管理テーブルの項目値を修正（追加・削除・変更）することで反映できる。即ち、列管理テーブルの項目内容を修正する必要がない（テーブルの物理構造・定義を変更するわけではない）。列管理テーブルの物理構造は、従来のどの物理テーブルに対しても常に共通（同一）の構造となる。よって、表示プログラムを動的に変更することができる。具体的には、プログラムを外出しにしてテーブル化することで、テーブルのデータを変更することにより、プログラムを変更することができる。また、業務に特化した項目は、列管理テーブルの属性としてではなく、項目値として入れる。項目値を追加・削除・変更することは、定義を変更することと比較して容易である。
９）１ランク底の部分（プラグラムの部分）をデータで実行することができる。具体的には、プログラムを外出しにしてテーブル化することで、テーブルのデータを変更することにより、プログラムを変更することができる。
【０１３８】
特徴３：列管理テーブルの構成
１）読込レコードのデータフォーマット（カラム定義）に１対１で対応してテーブルＩＤを割当てると共に、同一データフォーマット内でのカラムの順番で連番（シークエンスＮＯ）を割当てて、読込レコードのフィールドと１対１で対応付ける。
２）或いは、特定データフォーマットの読込レコードのフィールドの並び順に１対１で対応して列ＩＤを割り当てる。この場合、列ＩＤはテーブルＩＤ＋連番（シーケンスＮＯ）に１対１で対応する。ここで、前記列ＩＤは、テーブルＩＤ（企業コード＋版コード＋階層コード）と連番（シーケンスＮＯ）との組合せからなるコード（数字）を簡略化したコード体系とすることができる。
【０１３９】
特徴４：列管理テーブルのみ分離管理（ネットの別場所）＆一つのビュー
１）列管理テーブルのみ（マスタ系データを取り扱うことから）別管理とすることができる。即ち、管理センターシステム（サーバー）に列管理テーブルをおいてプロファイル情報の管理（更新等）をし、ユーザ側のシステム（クライアント）には列管理テーブルを置かず、管理対象データを読込んで行管理テーブル及び値管理テーブルを作成するプログラムのみをおいて、ネットワークを介して管理センターシステムの列管理テーブルを参照して行管理テーブル及び値管理テーブルを作成するようにする。
２）或いは、管理センターシステムで管理する（最新バージョンの）列管理テーブルを更新（バージョンアップ）があるごとにユーザ側のシステムにダウンロードし、当該列管理テーブルを参照して行管理テーブル及び値管理テーブルを作成するようにする。
３）このように、本発明は、３つのテーブルを分離して（別のＰＣに）格納することができる。例えば、ネットワーク上に分散して格納することができる。
５）ネットワーク上で列管理テーブル（企業プロファイル）のみを管理することで、ユーザは最新のテーブル定義を使用することが可能。例えば、ネット上の企業プロファイルを遠隔で見に行ってもよいし、コピーしても良い。一方、管理者は、別場所で企業プロファイルを編集・管理し、ユーザの要求に応じて配信することができる。
６）別場所で管理しても、ネットワークでつないで一つのビューとして見せることができる。
７）配信するインフラとして、ネットワークが負荷なくつながっていれば、コピーではなく直接見に行ってもよいが、インターネットの場合はトラフィックの問題があるので、通常は自社格納領域にコピーして使用する。
【０１４０】
特徴５：データの階層化に対応
１）列管理テーブルにレコードサブＩＤを定義して格納する。即ち、管理対象データが階層構造のレコードをからなる場合、テーブルＩＤに、当該階層構造に対応する階層コード（レコードサブＩＤ）を付加する。即ち、テーブルＩＤに連続するレコードサブＩＤで階層構造を管理する。こうすると、レコードに階層構造を有する管理対象データに対処可能となる。また、テーブルＩＤにレコードブＩＤを付加することで同一データ種別（例えば、ファイルヘッダ、伝票ヘッダ、伝票明細の３層からなる発注データ）内のテーブルＩＤを一意に識別（そのテーブルＩＤがファイルヘッダレコード、伝票ヘッダレコードまたは伝票明細レコードのいずれに属するのかを判別）することができる。また、階層構造については、列管理テーブルに格納されるデータ間に親子関係を確保することで対処することができる。また、行管理テーブルにデータを落とすときにも、列管理テーブルを見て親子関係を確保することができる。
２）テーブルは階層構造のものが多いが、本管理システムにより、システム構成を簡単にすることができる。
【０１４１】
特徴６：（列管理テーブルにおける）カラム定義のバージョン管理
１）テーブルＩＤを、特定データフォーマットの管理対象データが属する企業ごとに割り当てた企業コードと、当該企業のデータフォーマットの版をあらわす版コードとにより構成する。こうすると、テーブルＩＤの版コードを参照することにより、データフォーマットのバージョン管理が可能になる。
２）列管理テーブルにプロファイルの利用期間乃至有効日（自）・有効日（至）等の日時情報を定義し、データ変換時には、当該データ項目の値を参照して、利用可能なバージョンのカラム定義を参照する。
３）旧バージョンのデータ変換が必要な場合は、旧バージョンの利用期間を有するカラム定義を利用する。
４）テーブルＩＤや列ＩＤを構成する企業コード（版）に版情報を付加し、当該版情報を参照する。
【０１４２】
特徴７：項目関連定義テーブル
１）項目関連定義テーブルで異種フォーマット間の関係（データ項目間関連情報）を定義（項目関連定義）することができる。
２）標準フォーマットを介した異種フォーマット（Ａ⇔Ｂ）間のデータ変換賀可能になる。直接フォーマット変換する従来のマッピングと比較して、システム構成が大幅に簡易化される。
３）また、データ変換プログラム自体も関数管理テーブルに定義することができる（プログラムの演算内容及びパラメータの外出し）。そして、項目関連定義テーブルのデータ項目「関数」に格納した値（関数情報）を参照することで、当該列ＩＤの値について所定の演算処理を行うことができる。また、プログラム内容やパラメータの変更を、関数管理テーブルの内容を変更（データ入力処理）するだけで対処でき、プログラム自体を変更する必要がない。
４）例えば、フォーマットＡ（発注者独自）をフォーマットＢ（受注者独自）に変換する場合、標準フォーマットＳを介して、Ａ（発注者Ｆ）の各項目とＳ（標準Ｆ）の各項目間のチェーン（リンク情報）を予め定義すると共に（Ａ⇔Ｓ）、Ｓ（標準Ｆ）の各項目とＢ（受注者Ｆ）の各項目間のチェーン（リンク情報）を予め定義する（Ｓ⇔Ｂ）。これにより、Ｓ（標準Ｆ）を仲介にして、Ａ（発注者Ｆ）とＢ（受注者Ｆ）との間でのデータ変換を実行する。
５）標準フォーマット（標準プロファイル）は業界ごと（業務の種類ごと）に作成可能である。
６）カラムチェーンテーブルは、トリガとなるＡフォーマットのデータ項目（例えば発注者プロファイルのあるデータ項目）が入力されると、そのデータ項目に対応する標準フォーマットのデータ項目（標準プロファイルの対応するデータ項目）を仲介して、その標準フォーマットのデータ項目に対応するＢフォーマットのデータ項目（受注者プロファイルの対応するデータ項目）を取得する。
７）具体的には、以下のようにデータ変換処理される。まず、列管理テーブルに、特定業務（例えば、受発注業務）に対応する標準データフォーマットを定義する標準プロファイル（一つ）と、当該特定業務について特定の取引先企業・組織が使用する独自のデータフォーマットを定義する取引先プロファイル（取引先企業・組織の数だけ）と、当該特定業務について当該企業・組織と取引するユーザが使用するユーザ独自のデータフォーマットを定義するユーザプロファイル（通常は一つ）とをそれぞれ作成してマスタデータとして格納する。また、項目関連定義テーブルに、取引先プロファイルの特定のデータ項目と当該データ項目に対応する標準プロファイルのデータ項目との間のリンク情報を格納する。具体的には、取引先プロファイルのデータ項目の列ＩＤと当該データ項目に対応する標準プロファイルのデータ項目の列ＩＤとを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、取引先プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。同様に、項目関連定義テーブルに、標準プロファイルの当該データ項目と当該データ項目に対応するユーザプロファイルのデータ項目との間のリンク情報を格納する。具体的には、ユーザプロファイルのデータ項目の列ＩＤと当該データ項目に対応する標準プロファイルのデータ項目の列ＩＤとを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、ユーザプロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。したがって、例えば、取引先プロファイルのデータ（取引先データ）をユーザプロファイルのデータ（ユーザデータ）に変換する場合、項目関連定義テーブルを参照し、ユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする取引先プロファイルのデータ項目の列ＩＤを取得する。そして、値管理テーブルを参照し、当該取得した取引先プロファイルの列ＩＤのデータ項目の値を、ユーザプロファイルの対応する列ＩＤの値として取得する。これにより、標準プロファイルを介して、取引先プロファイルの取引先データからユーザプロファイルのユーザデータへのデータ変換が実現される。
８）次に、値管理テーブルに格納したデータの出力・表示（印刷・画面表示）については以下のように処理される。まず、値管理テーブルに格納されるデータは、データの一元性を維持する等の目的で、一次データ（読み込みデータ）としての取引先データのみである。    よって、当該取引先データに対応するユーザデータを出力・表示する場合、ユーザデータの各データ項目に対応する取引先データの各データ項目の値を、上記のように標準プロファイルの対応するデータ項目を介して値管理テーブルから取得し、取得した各々の値をユーザデータの対応するデータ項目の値として、ユーザプロファイルにしたがって（ユーザデータ独自のフォーマットで）、ユーザデータのデータ項目とセット（組）で出力・表示する。このとき、表示形式（出力イメージを制御するパラメータとしての表示枠の寸法、各データ項目の表示位置、フォント等）は、表示プログラムに定義されている。或いは、後述するように、表示形式を定義する帳票（画面）定義テーブル（ＦＯＲＭ＿ＣＯＬＵＭＮテーブル）を用意し、パラメータを外出ししても良い。こうすると、表示形式を変更するたびにプログラムを変更する必要がなく、表示形式の変更を簡単に行うことができる。
【０１４３】
特徴８：項目値管理テーブル
１）項目値の意味の相違を自動変換（カラムバリュー）⇒テーブルに定義するため、プログラムで処理する場合と比較して、テーブルのデータ項目及びその値のみを変更すればよく、システム構成が簡単になる。また、データ項目値の標準化が可能となる。
【０１４４】
特徴９：受発注システムのデータ構造（テーブル構造）
１）列管理テーブルの内容
テーブルＩＤ＝企業コード＋データ種類コード＋枝番とすることができる。各テーブルＩＤは、複数階層のレコードからなる一つのデータの各レコード種別を一意に表す（例えば、発注データの場合、ファイルヘッダレコード、伝票ヘッダレコード、伝票明細レコード）。また、列管理テーブルの連番（シーケンスＮＯ）は、同一テーブルＩＤ内のデータの順番を示す。また、列ＩＤは、企業コード、データ種類コード、枝番及び連番に基づき自動生成される一意のＩＤとしてもよい。また、各列ＩＤごとに項目名称、即ち、データ項目（フィールド）の名称が付与される。即ち、各列ＩＤが、複数のフィールドからなる一つのレコードの各フィールド種別や属性（定義内容）を一意に表す（例えば、ファイルヘッダレコードの場合、そのレコード区分、データ種別、データ作成日等のフィールド名、データ型、位置、最大・最小バイト数、識別子の連番、主要格納情報番号、列サブＩＤ等）である。また、上記のように、日付情報をバージョン管理に利用できる。また、企業コードの末尾２桁は当該企業のフォーマットのバージョンを表すため、やはり、バージョン管理に利用できる。主要データ項目として、列ＩＤ（企業（版））は、各データ項目（各フィールド）を一意に識別し、テーブルＩＤ＋シーケンスＮｏ．（連番）と１対１に対応（テーブルＩＤ＋シーケンスＮｏ．を加工して生成）する。また、変換メソッド（関数）は、当該列ＩＤのデータ項目値を変換する必要がある場合に、その変換に利用するメソッド名を定義する（例：ＣＯＬＵＭＮ＿ＶＡＬＵＥ）。ポジションは、当該データ項目のレコード先頭（０）からの位置を示す。レングスは、最大・最小レングスを示す。識別子作成順序は、当該レコードの識別子（検索キー）を構成するデータ項目の順番を指定する（例:発注データのファイルヘッダレコードの場合（１）発注企業コード（２）データ種別（３）データ作成日、伝票ヘッダレコードの場合（１）伝票番号、伝票明細行の場合（１）明細行番号（２）ＧＴＩＮコード）。また、基本項目指定順序は、当該レコードの全データ項目（全フィールド）のうち行テーブルに複写する基本データ項目について、当該主要データ項目の値を行テーブルの何番目の基本情報に複写するかを連番で指定する（例:発注データのファイルヘッダレコードの場合（１）発注企業コード（２）受注企業コード（３）データ種別（４）データ作成日（５）データの全レコード数、伝票ヘッダレコードの場合（１）伝票番号（２）伝票区分（発注日）（３）発注日（納品指定日）（４）納品先企業コード（店舗コード）（５）納品先店舗コード（取引先名称）、伝票明細行の場合（１）ＧＴＩＮコード（２）品名カナ（３）規格カナ（４）数量（５）原単価）。また、列サブＩＤは、当該データ項目の値を行テーブルの突合項目に格納する場合に、そのデータ項目のオブジェクトＩＤ（対象管理テーブル参照）を指定する（例：発注データのファイルヘッダレコードの場合⇒（１）、発注店舗コード伝票ヘッダレコードの場合（１）伝票番号（２）発注日（または、（１）伝票番号（２）発注日（３）店舗コード）、伝票明細行の場合（１）伝票番号（２）行番号（３）ＧＴＩＮコード）。また、有効日時（自）＆（至）は、���ージョン管理に利用できる。
【０１４５】
特徴１０：受発注システムのデータ入力（データ読み込み）処理⇒テーブル管理テーブルに制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）を定義し、データ入力するため、データフォーマットの変更に対しては、データ項目値としての同ＣＯＮＴＲ０ＯＬ＿ＩＮＩのみを変更すればよく、プログラム（内部のパラメータ）を変更する必要がない。
１）ユーザー企業のデータ管理システム（ｅＤＩＹ）のボリュームを企業（取引先企業である発注企業）ごとに分割し、システム起動時に、処理すべきデータ（読み込みデータ）の企業（発注企業）を指定させる。
２）データ交換前に、データ交換管理テーブル（発注企業コード、受注企業コード、データ種別等）を参照し、指定した企業（発注企業）が、当該取引（発注）を、ユーザー企業（受注企業）と行っているか否かをチェックする。
３）テーブル管理テーブルのレコードサイズ（例えば、１２８バイト、２５６バイト、５１２バイト等）を参照し、読み込んだデータを当該レコードサイズ単位（１２８バイト等の単位）に順番に切り分けて読み込む。
４）同時に、読み込んだ各レコードについて、テーブル管理テーブルにおいて当該（発注企業コードの）企業のデータプロファイル（データフォーマット）に関して定義したレコード制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）（特定のレコードであることを示す項目値の位置と内容を記述したもの）を参照し、読み込んだレコードが合致したレコード制御情報を有するテーブルＩＤコードを特定して取得する。
５）列管理テーブルを参照し、列管理テーブルの当該テーブルＩＤコード相当部分をメモリに読み込む。
６）順番に切り分けて読み込んだレコードに対し、その順番で行ＩＤを付与（自動生成）して行管理（ＲＯＷ）テーブルを作成する（例：発注企業コード（版）＋受注企業コード（版）＋データ種別＋読み込み日＋読み込み時刻）。
７）同時に、列管理テーブルの列サブＩＤ（＝オブジェクトＩＤ）を参照し、当該テーブルＩＤを有するレコードのデータ項目値から、当該テーブルＩＤについて定義した突合項目の項目値を各行ＩＤに対して割当て格納する。例えば、伝票ヘッダレコードについて、納品店舗コード（列サブＩＤ＝１１）、伝票番号（列サブＩＤ＝２０２０１）、発注日（列サブＩＤ＝２０１０１）が突合項目として定義されている場合、その項目値である店舗コードの値（１００）、伝票番号の値（４９２１８＊＊＊）、発注日の値（２００５０１１３）を当該伝票ヘッダレコードの突合項目値として格納する。また、当該伝票ヘッダレコードに従属する伝票明細行レコードについて、納品店舗コード、伝票番号、明細行番号（２０２０１１）、ＧＴＩＮコード（列サブＩＤ＝３）、発注日が突合項目として定義されている場合、その項目値である店舗コードの値、伝票番号の値、明細行番号の値（０１等）、ＧＴＩＮコードの値（０４９＊＊＊＊＊＊＊＊＊＊＊＊＊）、発注日の値を当該伝票明細行レコードの突合項目値として格納する。このように、受発注データの突合作業において必要となるデータ項目値（例えば、店コード、伝票番号等）を突合項目値として列管理テーブルに予め定義する。これにより、例えば、ピッキング作業において特定の伝票番号の特定の明細行の製品の欠品（例：発注数量５０に対して検収数量３０）が判明した場合、ユーザ企業が（受注データを基に）作成する出荷データを作成する場合に、当該欠品数量を反映した出荷数量（検収数量）を入力することにより、両突合項目値間の突合を介して、当該欠品状況（発注数量を二重線で取り消し、その下側に検収数量を記入）を出荷伝票に自動記入すること（突合による修正の自動反映）が可能となる。
８）同時に、列管理テーブルの基本項目指定順序を参照し、当該テーブルＩＤを有するレコードのデータ項目値から、当該テーブルＩＤについて定義した基本項目値を各行ＩＤに対して割り当てて格納する。例えば、伝票ヘッダレコードについて、発注日、納品日、検収日が基本項目として指定されている場合、それらの項目値（及び属性）を格納し、伝票明細レコードについて、ＧＴＩＮコード、伝票番号、明細行番号、ＧＴＩＮコードが基本項目として定義されている場合、その項目値である店舗コードの値（及び属性）、伝票番号の値（及び属性）、明細行番号の値（及び属性）、ＧＴＩＮコードの値（及び属性）を当該伝票ヘッダレコードの基本項目値（及び属性）として格納する。これにより、データの表示出力時に、行管理（ＲＯＷ）テーブルの基本項目値のみ読み込んで、迅速に表示することができる。
９）更に、その他のデータ項目値（当該レコードのテーブルＩＤ、識別子ＩＤ、識別値等）を格納して行管理テーブルを作成することもできる。
１０）行管理テーブル作成と同時に、順番に切り分けて読み込んだレコードを、列管理テーブルを参照し、そのテーブルＩＤの連番または列ＩＤにしたがって、当該レコードを構成する全てのデータ項目（フィールド）の順に分割し、それぞれのデータ項目値を対応する値格納セル（値１〜３０）に格納して値管理テーブルを作成する。このとき、値格納セルは、各データ項目値（各フィールドの値）を格納する物理上のセル（値管理テーブルの「カラム（データ項目）」としての「値１・・・」と「行」としての「行ID」とが交差する欄乃至格納域）であるが、論理的には、（ＦＨ，ＤＨ，ＤＤの各フォーマット種類のレコードごとに割り当てられる）テーブルＩＤと（各レコードについて一意に割り当てられる）行ＩＤとにより一意に決定される論理セル（カラムとしての一連のテーブルＩＤと行IDとが交差する欄乃至格納域である論理上のセル）に一レコードの全フィールドが格納されるイメージである。こうすると、列ＩＤと行ＩＤとが交差する欄を一つの論理セルとし、当該一つの論理セルに各フィールドの値を格納する場合と比較して、処理速度を向上することができる。即ち、テーブルＩＤと行ＩＤとにより決定される一つの論理セルに一レコードの全フィールドが格納されると共に、それらのフィールドは当該一レコードに属する一連の値であるため、当該レコードに割り当てた検索キーを利用して、迅速な値の取得等が可能になる。
１１）値管理テーブルの各論理セルに格納するデータ項目値の数が３１以上の場合、当該論理セルの次に第２の論理セルを連続して設け、当該第２の論理セルのセルシーケンスＮＯを「１」から「２」にして、当該第２の論理セルの値格納セル（値１〜３０）に３１番目以降のデータ項目値を上記と同様にして順次格納する。
１２）発注データの全レコードの全ての値を値管理テーブルに格納したら、当該発注データが一次データとなる。よって、それ以降の統一伝票データ（２９）、入荷予定データ（伝票）（３０）、入荷予定データ（梱包）（４０）、受領データ（５０）、請求データ（６０）、支払いデータ（７０）の表示（帳票印刷・画面表示）や特定形式（特定伝票形式等）でのデータ出力は、項目関連定義テーブルを参照し、前記一次データのデータ項目と対応する各データのデータ項目とのリンク情報を取得して、当該一次データのデータ項目を各データのデータ項目に置き換える形で実行される。これにより、常に一次データを利用してデータの一元性を確保した上で、各種帳票や各種画面の表示（印刷・表示）やデータ出力を行うことができる。
１３）データ読み込みを全自動化する場合、以下のように処理する。但し、ＣＯＮＴＲＯＬ＿ＩＮＩにより一意にレコードを特定できる必要がある（ＣＯＮＴＲＯＬ＿ＩＮＩが重複して存在する場合は不可）。即ち、上記と同様にしてデータ読み込む。但し、読み込みデータの発注企業を指定することなく、全ての発注企業について上記と同様の処理を行う。この場合、完全自動化により手間は諸略できるが、その分、処理時間が長くなる。次に、テーブル管理テーブルを参照して入力データの種別（例えば、発注データ）を（例えば、データタイトル等から）判別及び解析し、そのデータを各レコードに分割する。その際、各レコードに対応するテーブルＩＤ（＋レコードサブＩＤ）を付与する。そして、列管理テーブルを参照し、対応するテーブルＩＤ（＋レコードサブＩＤ）のレコード定義を取得する。同時に、行管理テーブルと値管理テーブルを作成する。
【０１４６】
特徴１１：異なるフォーマット間のデータ変換及び指定形式でのデータ表示（帳票の画面表示または印刷）・データ出力（ＣＳＶ等出力・保存）処理。これにより、データの一元管理（発注企業データ（一次データ）を利用した同等のビューによる表示）⇒ユーザ企業の納品データや請求データ等、発注企業データから数量等に変更のあるデータは、発注企業データの当該項目のみを変更した（発注企業データを基にした）出力データ（ＣＳＶ）を利用してデータ出力される。よって、データの一元性が保持される。
１）まず、列管理テーブルに、特定業務としての受発注業務の各データ種別（発注データ、統一伝票データ、入荷予定データ（ＡＳＰ）、受領データ、請求データ、支払データ、返品データ等）に対応する標準データフォーマットをデータ種別の数だけ定義する標準プロファイル（各データ種別に一つ）と、当該受発注業務についての発注企業（多数）独自のデータフォーマットを当該発注企業が使用するデータ種別（発注データ、統一伝票データ、受領データ、支払データ、返品データ等）の数だけ定義する発注企業プロファイル（各発注企業の各データ種別に一つ）と、当該受発注業務についてのユーザ企業独自のデータフォーマットを当該ユーザ企業が使用するデータ種別（発注データ、統一伝票データ、入荷予定データ（ＡＳＰ）、請求データ等）の数だけ定義するユーザ企業プロファイル（通常は一つ）とをそれぞれ作成してマスタデータとして格納する。
２）また、リンク間列管理テーブルに、発注企業プロファイルの特定のデータ項目と当該データ項目に対応する標準プロファイルのデータ項目との間のリンク情報を格納する。具体的には、発注企業プロファイルのデータ項目（例：データ作成日）の列ＩＤ（９９９９９９０１２０１００３）と当該データ項目に対応する標準プロファイルのデータ項目（データ作成日）の列ＩＤ（１２０１００３）とを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、発注企業プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。同様に、リンク間列管理テーブルに、標準プロファイルの当該データ項目と当該データ項目に対応するユーザ企業プロファイルのデータ項目との間のリンク情報を格納する。具体的には、ユーザ企業プロファイルのデータ項目（データ作成日）の列ＩＤ（１１１１１１０１２０１００３）と当該データ項目に対応する標準プロファイルのデータ項目（データ作成日）の列ＩＤ（１２０１００３）とを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、ユーザ企業プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。
３）したがって、例えば、発注企業プロファイルのデータ（例：発注データ）をユーザ企業プロファイルのデータ（ユーザ指定形式の受注データ）に変換する場合、まず、ユーザが指定したデータ内容（受注データ）に応じて、リンク間列管理テーブルを参照し、指定データ（表示すべきデータ）のユーザプロファイル（受注データ用プロファイル）のテーブルＩＤ（１１１１１１０１２０１等）を判断し、当該テーブルＩＤに属する全てのデータ項目の列ＩＤ（１１１１１１０１２０１００１等）を順に（当該プロファイルの全データ項目分）取得する。次に、リンク間列管理テーブルを参照し、取得したユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする発注企業プロファイルのデータ項目の列ＩＤを取得する。そして、発注企業プロファイルの発注データの値を格納する値管理テーブルを参照し、当該取得した発注企業プロファイルの列ＩＤのデータ項目の値を、項目順（列ＩＤ順）に、ユーザ企業プロファイルの対応する列ＩＤの値として取得する。これにより、標準プロファイルを介して、取引先企業プロファイルの取引先データからユーザ企業プロファイルのユーザデータへのデータ変換が実現される。
４）次に、値管理テーブルに格納したデータの表示（帳票印刷・画面表示）については以下のように処理される。ここで、値管理テーブルに格納されるデータは、データの一元性を保持する等の目的で、一次データ（読み込みデータ）としての発注企業プロファイル形式の発注企業データ（デフォルトデータ）のみである。標準プロファイル形式のデータ（標準データ）やユーザ企業プロファイル形式のデータ（ユーザ指定データ）は、実際に別個の（それらに固有の）値管理テーブルに格納されるわけではなく、発注企業データを実際に格納する値管理テーブルから当該発注企業データのデータ項目の値を取得して、その値を、標準プロファイルやユーザ企業プロファイルのデータ項目とセットで表示することにより、一般的な（従来の）物理構造のテーブルと同等のビューによる表示を実現する。そして、発注企業プロファイル形式の発注企業データをそのまま表示する場合、当然データ変換は不要であるため、まず、列管理テーブルを参照する。一方、ユーザ企業が指定する表示形式のデータ（ユーザ指定データ）を表示する場合、まず、ユーザプロファイル（受注データ用プロファイル）のテーブルＩＤ（１１１１１１０１２０１等）を判断し、当該テーブルＩＤに属する全てのデータ項目の列ＩＤ（１１１１１１０１２０１００１等）を順に（当該プロファイルの全データ項目分）取得する。次に、列管理テーブルを参照し、次に、リンク間列管理テーブルを参照し、そして、値管理テーブルを参照する。よって、当該取引先データに対応するユーザデータを表示する場合、ユーザ企業指定のユーザ企業プロファイルによる受注データの各データ項目に対応する発注企業データの各データ項目の値を、上記のように標準プロファイルの対応するデータ項目を介して値管理テーブルから取得し、取得した各々の値をユーザ企業指定の受注データの対応するデータ項目の値として、ユーザ企業プロファイルにしたがって（ユーザ企業指定の受注データ独自のフォーマットで）、ユーザ企業指定の受注データのデータ項目とセット（組）で出力・表示することができる。このとき、表示形式（出力イメージを制御するパラメータとしての表示枠の寸法、各データ項目の表示位置、フォント等）は、表示プログラムに定義されている。或いは、上記のように、表示形式を定義するテーブル（ＦＯＲＭ＿ＣＯＬＵＭＮテーブル）を用意し、パラメータを外出ししても良い。こうすると、表示形式を変更するたびにプログラムを変更する必要がなく、表示形式の変更を簡単に行うことができる。一方、取引先プロファイルのデータ（取引先データ）をユーザプロファイルのデータ（ユーザデータ）に変換して出力（印刷・表示）する場合、まず、ユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする取引先企業プロファイルのデータ項目の列ＩＤを取得する。
【０１４７】
特徴１２：帳票カラム（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブル及び帳票（ＦＯＲＭ）テーブル
１）基本は、「テーブル⇔テーブル」間のデータ変換だが、追加仕様として、テーブル⇒帳票（ＦＯＲＭ）のデータ変換も可能。
２）従来はプログラムにパラメータとして定義していた帳票の印刷表示形式（帳票のイメージファイル、イメージの表示位置、文字列の表示位置、長さ、フォント、フォントサイズ等）をプログラムから外出しし、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルに定義した。よって、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルを更新するだけで（データ入力作業をするだけで）各種帳票のフォーマット変更に対応できる。なお、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルは、カラムのデータ項目値と帳表のデータ項目値を１対１に紐付けるテーブルである。また、カラムのデータ項目を動的に変更するように、帳表もデータを追加・削除・変更することで動的に変更する。なお、従来は、プログラムで帳表を変更する必要があった。
【０１４８】
特徴１３：表示画面カラム（ＦＯＲＭ_ＣＯＬＵＭＮ）テーブル及び表示画面（ＦＯＲＭ）テーブル
１）更に、テーブル⇔表示画面間でデータリンクが可能となる。
２）従来はプログラムにパラメータとして定義していた帳票の画面表示形式（帳票のイメージファイル、表示位置、文字列の表示位置、長さ、フォント、フォントサイズ等）をプログラムから外出しし、ＦＯＲＭ_ＣＯＬＵＭＮテーブルに定義した。よって、ＦＯＲＭ_ＣＯＬＵＭＮテーブルを更新するだけで（データ入力作業をするだけで）各種表示画面のフォーマット変更に対応できる。なお、画面⇔カラムが、データをいじるだけで一つのプログラムで（プログラムを修正することなく）全て可能となる。
３）また、画面表示された帳票の表示欄を入力域としてテーブルに定義した。よって、同画面を利用して客注入力が可能となる。また、画面表示した帳表を画面としてとらえて各枠を入力域とすることができる。また、データの内容チェックは列管理テーブルの定義（属性）を参照することもできる（例：日付（ｄａｔｅ）に数値（ｎｕｍｂｅｒ）を入れるとエラー処理）。また、列管理テーブルの属性を見て、ドロップダウンリスト等のリスト表示によりユーザに所望のデータ項目を選択させることも可能。データの互換は、カラムバリューを見てもってくる。チェーンを張ることで、入力のまま使用可能となる。
４）客注入力
ユーザシステム起動時に、ユーザーは、ボリューム定義を選択できる（どの取引先企業（発注企業）のボリュームを最初に出すか）。ボリュームを選択すると、ユーザーシステムが立ち上がり、「客注入力」メニューが表示される。同メニューには、入力欄がある。所定様式（フォーマット）の納品書をバックに、仕入伝票入力が可能である。従来の表示プログラムは、ＤＢのワーク領域に格納した（値管理テーブルのデータ項目値に相当する）データ項目値を、画面に表示した所定様式の帳票（納品伝票）の所定地位に出力して表示する。一方、本発明は、ＣＯＬＵＭＮテーブルとＦＯＲＭ＿ＣＯＩＬＵＭＮテーブルとを１対１に対応させ、ＦＯＲＭテーブルからＦＯＲＭ_ＣＯＬＵＭＮテーブルを介してＣＯＬＵＭＮテーブルのテーブルＩＤを有する値管理テーブルの対応するデータ項目に値を格納するため、実際に画面表示した帳票を利用して、その帳票の表示欄に、直接、必要な値を入力可能である。
５）属性も列管理テーブルに入れることができる。
６）ＦＯＲＭ_ＣＯＬＵＭＮテーブルは、入力に特化したデータ（表示場所、大きさ、フォント種類等）を取り扱う。
【０１４９】
特徴１４：発注データと納品データの突合せ、訂正反映処理
１）納品店舗コード、伝票番号、ＧＴＩＮコード、発注日付等を突合項目（検索時のインデックス項目（検索キー））として指定できる。
【０１５０】
特徴１５：上記データを配信してＡＳＰ実現がかのうとなる（例えば、図１７）。
１）同じデータ定義を参照して運用（カラム定義を外出し、管理団体が管理してユーザに配信）する。
２）応用として、電子カルテへの適用も可能である。例えば、岐阜県の定義（フォーマット）及び標準定義並びにそのチェーンをダウンロードして、自県（東京等）の定義とマッピングすることができる。
【０１５１】
特徴１６：データ配布（初回配布、初回システム稼動時）
１）ユーザが配布データをＦＴＰでダウンロード（ダウンロード後自動削除）する。
２）ユーザー企業情報を顧客管理テーブルから取得する。
３）取引関係情報をデータ交換管理テーブルから取得する。
４）ユーザー企業が選択した標準プロファイルを列管理テーブルから取得し、カラム値を項目値管理テーブルから取得する。
５）取引先の企業プロファイルに関してテーブル管理テーブル、列管理テーブル、項目値管理テーブル、項目関連定義テーブルを利用する。
６）標準プロファイルを複写してユーザープロファイルとする場合、同ユーザープロファイルを列管理テーブル、項目関連定義テーブルから判断する。
７）システム稼動後、取引先の増減が発生した場合、（１）〜（６）までの同様の処理を繰り返す。そして、ユーザが電子商取引を行う取引先を再選択する。
【０１５２】
特徴１７：プロファイルのバージョンアップ
１）企業プロファイルのバージョンアップ処理（共通）
システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在の企業プロファイルのバージョンをセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
１−１）ユーザーシステムの企業プロファイルのバージョンが古い場合、センターシステムは、その旨及びバージョンアップの内容をユーザーシステムに通知する。ユーザーが更新ボタンをクリックした場合のみ、センターシステムは企業プロファイルのバージョンアップを実行する。この際、ユーザーシステムが指定する1企業（バージョンアップされた１企業プロファイル）毎に、ユーザーに確認を促す。
１−２）ユーザーシステムは、バージョンアップ完了時、そのステータスをシステムサポートセンターに通知する。
２）企業プロファイルのバージョンアップ情報（共通）
２−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在利用している企業プロファイルの情報をセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
２−２）企業プロファイルのバージョンアップが予定されている場合、ユーザーシステムは、システムサポートセンターのＷＥＢにアクセスし、バージョンアップの内容を確認できるページを表示する。この際、バージョンアップが予定される１企業（バージョンアップされる１企業プロファイル）毎のＵＲＬ（バージョンアップ情報が格納されるページのＵＲＬ）を表示する。
２−３）バージョンが新旧入れ替わる場合の対処方法も同時に表示する。
２−４）テストモードでのシステム起動も可能とする。
２−５）新企業プロファイルでの運用は、ユーザーシステムが、新旧企業プロファイルを定義する新旧列管理テーブルの日付情報（新プロファイルの利用可能開始日・終了日等）を参照して、自動切替により実行する。この際、ユーザーシステムは、旧フォーマット（旧プロファイル形式）の蓄積データのバックアップ（及び削除）を促す。事故防止のため、ユーザーシステムは、旧バージョンの企業プロファイルは残す一方、列管理テーブルの日付情報（利用可能開始日や削除日等）を利用して、データ変換には利用できないようにする。
３）標準プロファイルのバージョンアップ処理（共通）
３−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在の標準プロファイルのバージョンをセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
３−２）ユーザーシステムの標準プロファイルのバージョンが古い場合、センターシステムは、その旨及びバージョンアップの内容をユーザーシステムに通知する。ユーザーが更新ボタンをクリックした場合のみ、センターシステムは標準プロファイルのバージョンアップを実行する。この際、ユーザーは、ユーザープロファイルと新標準プロファイルとの関連定義を指定する必要がある（新項目関連定義テーブル生成）が、ユーザーシステムは、（ユーザー企業が以前に指定した）旧標準プロファイルとユーザープロファイルの関連定義（項目関連定義テーブル）を参照し、旧ユーザープロファイルの生成を保障するものとする。
３−３）ユーザーシステムは、バージョンアップ完了時、そのステータスをシステムサポートセンターに通知する。
４）標準プロファイルのバージョンアップ情報（共通）
４−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在利用している標準プロファイルの情報をセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
４−２）標準プロファイルのバージョンアップが予定されている場合、ユーザーシステムは、システムサポートセンターのＷＥＢにアクセスし、バージョンアップの内容を確認できるページを表示する。
４−３）企業プロファイルのバージョンアップ時とは異なり、標準プロファイルの切替前には、独自のユーザープロファイルを利用しているユーザー企業側での新標準プロファイルの十分なテスト（新標準プロファイルによる稼動試験）が必要であるが、標準プロファイルのバージョンアップ自体は、プログラムにより自動で行うようにする（以下の（５）参照）。
４−４）新標準プロファイルでの運用タイミング（標準プロファイルの切替タイミング）は、ユーザーが指定するが、新旧標準プロファイルの切替時には、ユーザーシステムが、列管理テーブルの日付情報（利用可能開始日・終了日や削除日等）を利用して自動切替を実行することが好ましい。
４−５）なお、標準プロファイルは、企業プロファイルのバージョンアップまたは新企業プロファイルの追加の場合にバージョンアップされるものではなく、システム自体のバージョンアップがあった場合（例えば、XML対応）に、バージョンアップする。
５）標準プロファイルのバージョンアップ処理プログラム
５−１）企業プロファイル⇔旧標準プロファイル、ユーザープロファイル⇔旧標準プロファイル、旧標準プロファイル⇔新標準プロファイルの３つの関係（項目関連定義テーブルの関連定義）を参照し、企業プロファイル⇔新標準プロファイルの関連定義、ユーザープロファイル⇔新標準プロファイルの関連定義を新しく作成する（項目関連定義テーブルに反映して項目関連定義テーブルをバージョンアップする）プログラム。
５−２）このとき、旧標準プロファイル⇔新標準プロファイルの関連定義、及び、企業プロファイル⇔新標準プロファイルの関連定義は、システムサポートセンター側で先に作成してユーザーシステムに配信する。この関連定義は、上記（１）のように、バージョンアップ処理プログラムで作成可能である。
５−３）ユーザープロファイル⇔新標準プロファイルの関連定義作成処理は、ユーザー側のシステムで実行する。
５−４）旧標準プロファイルは、当該旧標準プロファイルとチェーン（リンク）している全てのプロファイル（企業プロファイル及びユーザープロファイル）が無効になった場合に無効にする。
６）ユーザープロファイルのバージョンアップ（共通）
６−１）バージョンアップに関してはユーザー任意である。システムサポートセンターがユーザープロファイルをもサポートする場合、ユーザーシステムがサポートセンターにアクセスし、利用しているユーザープロファイルの情報をサポートセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
６−２）すると、上記企業プロファイルのバージョンアップと同様の処理が実行される。
７）企業プロファイルの利用停止
７−１）ユーザ企業が、（今まで利用していた）特定の企業プロファイルを利用停止した場合、取り消された（利用停止された）企業プロファイルの定義情報（列管理テーブルの該当部分）は、過去の（当該企業プロファイルが使用されている）データを閲覧する際に必要なため、ユーザシステムのＤＢより削除せず残す設定とする。
７−２）但し、取り消し後は、ユーザー企業が当該企業プロファイルを利用してデータ変換できないように制御する。例えば、当該ユーザー企業のユーザキーの値と取り消された企業プロファイルの利用状況との整合性をチェックすることで対応する。
【０１５３】
特徴１８：電子帳簿保存法への対応
ボリューム構成でＳＬＩＰ（伝票バックアップ領域）に伝票を納品書イメージとして、編集不可形式のデータフォーマットで格納する（例えば、ＪＰＥＧ等のイメージファイル）。
読み込みデータの自動入力
１）１企業単位にボリュームを設定するため、取引先企業が３００あると、ボリュームも３００存在する。ユーザーがこの中から読み込みデータに対応するボリュームを選択し、1企業単位で対応するボリュームにデータを格納する。データが毎日入ってくるような場合、そのたびにデータ格納対象のボリュームを選択し、データ入力するのは面倒。よって、自動実行プログラムを作成することにより対処する。
【０１５４】
特徴１９：複数業界仕様への対応
１）Ａ業界、Ｂ業界・・・等、異なる業界（例えば、ホームセンター業界とドラッグストア業界）でシステムを運用する場合、Ａ業界用標準プロファイルとＢ業界用標準プロファイルとの間での関連定義を設ける（例えば、ホームセンター標準⇔ドラッグストア標準）。これにより、ユーザー企業が複数の業界に位置して商取引を行うことが可能となる。Ａ業界用としては、（Ａ業界の発注企業の）企業プロファイルとＡ業界用標準プロファイルとの関連定義（Ａ企業⇔Ａ標準）、Ａ業界用標準プロファイルとユーザープロファイルの関連定義（Ａ標準⇔ユーザ）が定義され、これら２つの関連定義（項目関連定義テーブル）を介して、Ａ業界の企業プロファイルとユーザープロファイルとの間でのデータ交換が実現する。また、Ｂ業界用としては、（Ｂ業界の発注企業の）企業プロファイルとＢ業界用標準プロファイルとの関連定義（Ｂ企業⇔Ｂ標準）、Ｂ業界用標準プロファイルとユーザープロファイルの関連定義（Ｂ標準⇔ユーザ）が定義され、これら２つの関連定義（項目関連定義テーブル）を介して、Ｂ業界の企業プロファイルとユーザープロファイルとの間でのデータ交換が実現する。
２）ユーザー企業は、複数の標準プロファイル（Ａ標準、Ｂ標準・・・）と自社ユーザープロファイルとの関連定義をする必要がある。この場合、システムサポートセンターが、Ａ業界、Ｂ業界・・・等、業界ごとの標準プロファイルの関連定義（旧標準プロファイル⇔新標準プロファイル）、異なる業界の標準プロファイル間の関連定義（Ａ業界標準プロファイル⇔Ｂ業界標準プロファイル・・・）を作成し、ユーザーシステムがこれらの関連定義をダウンロードする。そして、ユーザーシステムは、それらの関連定義を参照し、ユーザープロファイルを自動作成する。
【０１５５】
次に、上記実施の形態１〜１０で詳述した３つのテーブル（列管理テーブル、行管理テーブル、値管理テーブル）によるデータ管理システムを応用して、異種システム間、異種パッケージソフト間及び異種インフラ間でのデータ交換・データ変換を汎用的に行えるようにしたデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムについて各種実施の形態を説明する。本発明に係るシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムは、システム間のデータ交換を実現する為、各システムが保守するデータを上記列管理テーブルを利用して定義する。そして、本発明に係るシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムは、その定義情報をシステムエクスチェンジプロファイル（Ｓｙｓｔｅｍ  ｅＸｃｈａｎｇｅ  Ｐｒｏｆｉｌｅ：略称ＳＸＰ）と称し、このＳＸＰを配信するサービスをＳＸＰサービスと、このＳＸＰサービスを提供するプロバイダをＳＸＰサービスプロバイダとそれぞれ称し、このサービス形態を社会に普及させることにより中小企業における情報の有効活用を推進することを企図するものである。
【０１５６】
ここで、本発明の背景技術について述べると、近年、ＸＭＬやＷｅｂ２．０を利用したシステムが続々と生まれ、企業における経営戦略の４つ目の柱を示すキーワードも、「ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）」から「ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ  ＆  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）」に変遷しつつある。即ち、これまで企業等の組織内で管理されていた情報を他の組織内で管理されている情報と交換あるいは融合させ、新たな付加価値を持った情報として活用する時代が到来しつつあるといえる。しかし、ウエブ（Ｗｅｂ）上で交換あるいは融合される技術は進歩の一途を辿っているのに反し、特に中小企業において管理されているデータを有効に活用できる技術は余り存在しないのが実情である。そこで、本発明者は、上記のような課題の解決を図るべく、以下に述べるようなシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムを提供する。即ち、健全なシステムは、検証されたプログラミングにより定型化された手順を履行すれば絶えず同じアウトプットを出力しなければならない。本システムエクスチェンジプロファイル（ＳＸＰ）サービスシステム及び当該システムエクスチェンジプロファイル（ＳＸＰ）サービスシステムを利用したビジネスモデルは、あらゆる健全なシステムで管理保守されているデータの変換＆交換を実現する、または、データの融合を実現するものであり、そのデータ交換は企業間、システム間、インフラ間の壁を越え、データの有効活用を革新的に拡大するものである。
【０１５７】
本発明に係るシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムは、各企業・団体等の各組織で管理されているあらゆるデータの交換或いは融合を可能にする汎用共用ＡＳＰ（アプリケーションサービスプロバイダ）またはＳＡＡＳ（サーズ：Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）に適用することができる。一方、そのデータ交換のうち、企業間のデータ交換に関しては、電子商取引（ＥＣ）や電子データ交換（ＥＤＩ）等で交換される商品情報、発注情報、在庫情報、会計情報の各種情報の交換・融合を実現する。このデータ交換・融合は、上記実施の形態１〜１０で説明した実施の形態におけるデータ交換・融合も無論含まれる。また、システム間のデータ交換に関しては、システム間のデータフォーマットの相違を解消し、例えば、異なる２つの業務システム間や、異なる２つの市販パッケージソフト（例えば販売管理ソフトと仕入管理ソフト）間でデータのエクスポートやインポートをする際に必要となるデータ変換やデータ融合を実現する。更に、情報インフラ間のデータ交換に関しては、データベースに格納されているデータとＸＭＬデータ間の相互変換を実現し、情報インフラとして広範囲に活用されるリレーショナルデータベース（ＲＤＢ）等の各種データベースシステムと、今後の活用がますます期待されるＸＭＬ利用システム（ＸＭＬデータベースを含む）との間でのデータ交換・融合を実現する。
【０１５８】
この課題を解決するため、本発明に係るシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムは、以下のような解決手段を提供する。ここで、従来のデータ交換について先に説明すると、システム間のデータ交換を実現するために、一般的にはまず、移行元システムからエクスポートファイルを出力し、その後、移行先システムのインポートファイルを参照し、表計算ソフト等を使用した加工作業が必要となる。この作業は多少のＩＴ知識を習得していれば、それほど困難な作業ではない。しかし、その作業にはやはり貴重な勤務時間が費やされ、そのノウハウは表計算のマクロや作業者の記憶に包み隠された状態で格納され、仕様書などを作成して第三者に開示されている例は極稀である。つまり、システム間のデータ交換を実現するためには実際には相当の時間が費やされているにも関わらず、一担当者にその手法は委ねられ、そのデータの妥当性を第三者がチェックすることも無く、またその加工作業の仕組みは恒常的に一貫した作業として保障されることも無く、健全に保守される確証も無いのが実情である。また、パッケージソフト等のシステムが管理するデータは、その使用方法が正しければ、データの正当性や一貫性は確保され保証されるにも拘らず、そのデータの移行作業については健全なシステムを介して、或いは、一貫した移行ルールを守って遂行されることは少ない。したがって、データの移行作業において、データの正当性や一貫性が損なわれている場合が大変多いのが実情である。
【０１５９】
そこで、本発明は、中小企業の経営革新にはＩＴ技術乃至ＩＣＴ技術の導入が欠かせない現代において、ＩＴ技術の専門知識を必要とせず、かつ、安価に安心して利用できると共に、システム間のデータの一貫性を保守することができ、或いは、同一管理対象に関する情報を一元的に管理することができる第１の仕組み（システム）を提供し、中小企業のＩＣＴ導入を革新的に促進する。かかる第１の仕組み（システム）として、以下の仕組み（システム）及び各システムを適用したビジネスモデル（便宜上、「ＳＸＰ特徴１、ＳＸＰ特徴２・・・という」）を提供する。
【０１６０】
ＳＸＰ特徴１．あるシステム（パッケージソフト等）のエクスポートファイルを加工して、ある別の種類のシステム（パッケージソフト等）のインポートファイルを加工する作業を自動化する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、当該システムを利用したシステム及びビジネスモデルでは、そのデータの移行作業に必須と思われる移行元システムエクスポートファイルから移行先インポートファイルを加工する作業の自動化を実現する。
【０１６１】
ＳＸＰ特徴２．パッケージソフト等の安定したシステムの出力データを定義し、その定義情報（システムプロファイル）を保守管理する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記自動化をするための核として、あらゆるシステムが管理するデータの定義情報をシステムエクスチェンジプロファイル（ＳＸＰ）として定義し、そのＳＸＰの格納と保守を実現する。
【０１６２】
ＳＸＰ特徴３．システムプロファイルをＷｅｂサイトよりダウンロードして配信する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記保守管理されたＳＸＰをＷｅｂサイトよりダウンロードし、ユーザに配信することを実現する。
【０１６３】
ＳＸＰ特徴４．２つのシステムプロファイルを利用し、標準プロファイルを介して２つのシステム間のデータ交換を相互に実現する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記システムを利用し、２つのシステムのＳＸＰを取得することでデータ移行に必要な加工作業の自動化を実現するが、データの変換＆交換は標準プロファイルを介して実現する。この標準プロファイルを利用する手法により、システム投資の大幅な削減を図る。
【０１６４】
ＳＸＰ特徴５．複数のシステムプロファイルを利用し、複数のシステムに格納された各種情報を適材適所に参照して活用する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記システムを利用し、複数のＳＸＰを取得することで複数のシステムに格納されている各種データを全て融合させて格納し、各システム間のデータの不整合を精査することを実現する。
【０１６５】
ＳＸＰ特徴６．格納されたデータを、固定長テキスト、可変長テキスト、ＣＳＶファイル、ＸＭＬファイルなどの様々なデータ形式に簡単に変換する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記格納データを参照し、必要に応じて指定された様々なフォーマットに変換してデータを出力し、データの二次利用を推進することを実現する。
【０１６６】
次に、本発明は、上記ＳＸＰ特徴１〜６までの一連のシステム及びビジネスモデルを、他の業界あるいは企業グループ間で利用できるように横展開を図り更に拡充することを企図する。即ち、本発明は、上記企業間或いはシステム間のデータ交換及びデータ交換業務を簡単に行えるようにするインフラを各業界に横展開し、拡大を図るべく、以下の第２の仕組み（システム）を提供する（上記ＳＸＰ特徴１〜ＳＸＰ特徴６に続く連番で表示）。
【０１６７】
ＳＸＰ特徴７．システムプロファイルをＷｅｂサイトにアップロードして格納する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、ＳＸＰをＷｅｂサイトを通してアップロードし、格納することを実現する。
【０１６８】
ＳＸＰ特徴８．各業界単位あるいは各管理対象物単位の標準プロファイルを定義する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記システムを利用し、標準プロファイルを業界単位あるいは管理対象物単位に策定し、Ｗｅｂサイトにアップロードすることを実現する。
【０１６９】
ＳＸＰ特徴９．システムプロファイルを定義し、標準プロファイルとの関連を定義する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記標準プロファイルを参照し、システム開発ベンダーが、開発したシステムの関連標準プロファイルを選択し、自ら開発システムに対応するＳＸＰを定義し、Ｗｅｂサイトにアップロードすることを実現する。
【０１７０】
ＳＸＰ特徴１０．システムプロファイルを識別するヘッダ（各データのヘッダ）部分の共有化を推進し、企業間やシステム間のデータ移行を自動化する仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記ＳＸＰプロファイルのヘッダ部分を共通化し、その共通フォーマットを普及させ、データの本体である詳細情報を判別する為のＳＸＰをデータ取得エリアで参照し、データを直ぐに変換＆交換することを実現する。
【０１７１】
ＳＸＰ特徴１１．データを送信するのみで対応するアプリケーションが自動で起動しデータを変換及び交換して取得できる仕組み（システム）及び各システムを適用したビジネスモデルの提供。これにより、上記ＳＸＰを参照したデータ変換＆交換を自動で起動し、指定された変換前フォルダに送信された入力データを変換＆交換した後、指定された変換後フォルダに転送することを実現する。
【０１７２】
以下、上記ＳＸＰサービスシステム及び同システムを利用したビジネスモデルの具体的な各実施の形態について説明する。
【０１７３】
実施の形態１１
まず、実施の形態１１に係るＳＸＰサービスシステムの背景技術について説明する。図７８は従来の複数の企業システム間のデータ変換の態様を概略的に示すデータフロー図である。
図７８に示すように、取引のある企業間では各々の企業独自のシステムが稼動している。例えば、企業Ａ（企業Ａのシステム）７００は、商品データ７０１、取引先データ７０２、売上データ７０３、仕入データ７０３、その他のデータ７０５を管理する。また、企業Ｂ（企業Ｂのシステム）７１０は、企業Ａ７００と同様、商品データ７１１、取引先データ７１２、売上データ７１３、仕入データ７１３、その他のデータ７１５を管理する。通常、企業Ａ７００及び企業Ｂ７１０のプロファイル（データフォーマット）は各社独自のものであり、異なるものである。そして、２つのシステム７００及び７１０が管理するデータは、両者間で取引があるからこそ同様なテーブルやデータ項目が多い。そして、例えば、企業Ａ７００と企業Ｂ７１０との間のデータ交換は、商品データ７０１及び商品データ７１１間、取引先データ７０２及び取引先データ７１２間、仕入データ７０４及び売上データ７１３というように、両社間の取引（受発注業務）に応じたデータ交換となる。なお、両システム７００及び７１０は、便宜上、同一のデータを取り扱うよう図示しているが、実際は、一致しないデータ項目も存在する。これらのデータは、ＥＣやＥＤＩなどでデータ交換され、取引企業間で有効に活用すべきものである。しかし、実際のデータ交換はファイルｔｏファイルで行なわれるため、データ交換システムの開発や運用に多大なコストがかかる。よって、最近では、ＸＭＬを利用した共用ＥＤＩプラットフォームが構築され、普及活動が実施されている（ＣＯＸＥＣ、ＸＢＲＬ等）。
【０１７４】
図７９は従来の複数の企業システム間のデータ変換におけるデータマッピングの態様を概略的に示すデータフロー図である。
図７９に示すように、２社間での受発注業務の場合、発注企業（取引先）側の発注データ８００と受注企業側の受注データ８１０との間では、所定の変換規則（データマッピング）にしたがって、例えば、発注企業側の店舗コード８０１が受注企業側では店舗名称８１１に変換されると共に、商品の届け先の住所や電話番号に変換されている。また、発注データ８００の発注日８０２は、受注データ８１０では受注日８１２に変換されるが、このとき、例えば、発注企業では発注日を西暦で管理しているが、受注企業では和暦で管理していることもあり、その変換も必要となる場合がある。また、発注企業では商品コード８０３がインストアコードで管理される場合、受注企業では商品コード８０３を統一コードとしてのＪＡＮコード８１３に変換する必要がある。なお、発注データ８００の商品名８０４は受注データ８１０では商品名称８１４として変換され、発注データ８００の発注数量８０５は受注データ８１０では受注数量８１５として取得している。
【０１７５】
図８０は従来のアプリケーションシステム（パッケージソフト）の格納データの態様を概略的に示すデータフロー図である。
図８０に示すように、パッケージソフトとしてのパッケージＡ９００は、商品データ９１０、顧客データ９２０、売上データ９３０、仕入データ９４０、その他のデータ９５０等の各種データを格納している。パッケージＡ９００は、各種データの内、全部または一部をエクスポートすることで、ＣＳＶファイル等に出力することができる。これは、パッケージＡ９００に格納されているデータを、他のシステムで再利用する場合に利用されることが多い。また、パッケージＡ９００は、各種データの内、全部または一部をインポートすることで、ＣＳＶファイル等から入力することができる。これは、パッケージＡ９００が取り扱うデータを、他のシステムから取得して取り込む場合に利用される事が多い。
【０１７６】
図８１は従来の複数のアプリケーションシステム（パッケージソフト）間でのデータ変換の態様を概略的に示すデータフロー図である。
図８１に示すように、パッケージＡ９００からエクスポートしたＣＳＶファイル等は、表計算ソフト等で利用されることが多い。しかし、パッケージＡ９００から出力されたファイルを、そのまま他の種類のパッケージソフト、例えば、パッケージＢに入力することは、ほとんどできない。即ち、パッケージＢ１０００が、パッケージＡ９００と同様のデータである商品データ１０１０、顧客データ１０２０、売上データ１０３０、仕入データ１０４０、その他のデータ１０５０等の各種データを格納して取り扱う場合でも、通常はデータフォーマットが異なるため、パッケージＡ９００からエクスポートしたＣＳＶファイル等のデータを、そのままの形（データフォーマット）でパッケージＢにインポートすることはできない。したがって、通常は、パッケージＡ９００の出力ファイルを表計算ソフトに一旦取込んだ後、仕様書を見ながらパッケージＢ１０００のデータフォーマットに対応するよう加工する作業が必要となる。この加工作業が単純な加工であれば簡単ではあるが、１対Ｎ、Ｎ対Ｎの対応関係となる場合、加工作業は煩雑になり中間ファイルの管理も非常に面倒となる。特に、ＩＴ導入の遅れている中小企業では、上記の加工作業を実施することも困難な企業が少なくない。
【０１７７】
図８２は従来の複数のアプリケーションシステム（パッケージソフト）間でのデータ変換におけるエクスポート／インポートの際の人手によるデータ加工作業を概略的に示すデータフロー図である。
図８１の問題に関し、商品データ９１０を例にとって説明する。図８２に示すように、パッケージＡ９００の商品データ９１０は、商品コード９１１、品名９１２、規格名９１３、単価９１４、仕入先コード９１５からなり、パッケージＢ１０００の商品データ１０１０は、商品コード１０１１、商品名１０１２、商品名カナ１０１３、下代１０１４、上代１０１５からなるとする。この場合、商品データ９１０の商品コード９１１は、商品コード体系が同一の場合、そのまま商品コード１０１０のキー項目である商品コード１０１１として利用できるが、ＪＡＮコードやＧＴＩＮコート等の統一コードに変換する場合もある。また、商品コード９００では商品名称を品名９１２と規格名９１３とで管理するのに対し、商品コード１０１０では商品名称を商品名（漢字表記）１０１２と商品名カナ（カタカナ表記）１０１３で管理するため、商品コード１０１０用の商品名を作成する場合に、商品コード９１０の品名９１２と規格名を９１３とを足して商品コード１０１０の商品名１０１２を作成する。また、商品コード１０１０の商品名カナ１０１３を作成する場合、商品コード９００の品名９１２と規格名９１３とを足した後、全角のカナに変換する。更に、商品データ９００では商品の価格を単価（商品の一個（一単位）あたりの価格）９１４で管理するのに対し、商品データ１０１０では商品の価格を下代（原価に相当 ）１０１４と上代（単価に相当）１０５とに分けて管理するため、商品データ１０１０の上代１０１５を作成する場合に、商品データ９１０の単価９１４の内容を使用する。即ち、単価９１４と上代１０１５とは異音同義語として取り扱う。なお、商品データ９１０の仕入先コード０１５や、商品データ１０１０の下代９１４のように、交換先に存在しないデータは消失し、交換元に存在しないデータは手入力作業で補う必要がある。
【０１７８】
図８３は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる複数のアプリケーションシステム（パッケージソフト）間でのデータ変換におけるエクスポート／インポートの際の自動データ加工処理を概略的に示すデータフロー図である。
上記従来技術に対し、本発明の実施の形態１１に係るＳＸＰサービスシステムでは、あらゆる種類のパッケージソフトの各プロファイルについて、上記実施の形態１〜１０で説明したような項目定義（列管理テーブルの作成）を行うと共に、それらのプロファイル間の関連定義を行うために上記実施の形態１〜１０で説明したような標準プロファイル（図８２の場合は、全ての商品管理用のパッケージソフトのプロファイル（データ項目）を網羅する標準プロファイル）を用意する。そして、この標準プロファイルを使用して、異なるパッケージソフト間のデータ交換を人手による加工作業を要さずに自動的に行う（自動加工する）。この自動加工システムの内容としては、図８３に示すように、例えば、図８２の商品データ９１０，１０１０のデータ交換の場合、あらゆるパッケージソフトの商品データのデータ項目を網羅する商品管理用標準プロファイル（図８３中の中央列のデータ群に対応）を使用して、商品データ９１０の各種データを商品データ１０１０の各種データに変換する。例えば、商品データ９１０の商品コード９１１を標準プロファイルの商品コード１１１１を介して商品データ１０１０の商品コード１０１１に変換する。また、商品データ９１０の品名９１２を標準プロファイルの品名１１１２及び品名カナ１１１３を介して漢字及びカタカナに分解して漢字部分及びカタカナ部分をそれぞれ抽出すると共に、商品データ９１０の規格名９１３を標準プロファイルの規格名１１１４及び規格名カナ１１１５を介して漢字及びカタカナに分解して漢字部分及びカタカナ部分をそれぞれ抽出し、品名カナ１１１３と規格名カナ１１１５（共にカタカナ表記となっている）とを足して商品データ１０１０の商品名カナ１０１３に変換する。また、商品データ９１０の単価９１４を標準プロファイルの単価１１１６を介して商品データ１０１０の上代１０１５に変換する。なお、商品データ９１０の仕入先コード９１５は標準プロファイルの仕入先コード１１１９に対応するが、商品データ１０１０には対応するデータ項目がないため、削除する。また、商品データ１０１０の下代１０１４は標準プロファイルの原価１１１６に対応するが、商品データ９１０には対応するデータ項目がないため、空欄（ＮＵＬＬ）とする。なお、商品管理用標準プロファイル１１１１〜１１２０には、上記標準データ項目１１１１等以外にも、定価１１１８等、あらゆる商品管理パッケージソフトの商品データのデータ項目を網羅している。なお、図７８〜図８３の説明は、上記ＳＸＰ特徴１に対応するものである。
【０１７９】
図８４は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる標準プロファイルを使用したデータ交換の場合の必要システム数（必要マッピング数）を、従来のシステム構成によるデータ交換の場合の必要システム数（必要マッピング数）と比較して示すデータフロー図である。
図８４（ａ）に示すように、従来のシステム構成によるデータ交換の場合、例えば、発注企業５社１２０１，１２０２，１２０３，１２０４，１２０５と受注企業５社１２１１，１２１２，１２１３，１２１４，１２１５とが相互に電子商取引をする場合、各発注企業につき対応する受注企業５社分のシステムが必要となり、結果、５×５＝２５通りのシステムが必要となる（掛け算の法則）。これに対し、図８３で説明した実施の形態１１に係るＳＸＰサービスシステムを利用する場合、図８４（ｂ）に示すように、発注企業５社１２０１，１２０２，１２０３，１２０４，１２０５がそれぞれ受注企業５社１２１１，１２１２，１２１３，１２１４，１２１５に対して標準プロファイル１２２０を介して相互に電子商取引をすると、５＋５＝１０通りのシステムで良い（足し算の法則）。即ち、上記の例では、２５−１０＝１５のシステムが従来に比して不要となり、１５／２５＝６０％のシステム投資が不要となる。発注企業１００社、受注企業１００社の取引を想定した場合、従来のシステム利用による１００×１００＝１０，０００に比較し、本発明のシステム利用による場合は１００社＋１００社＝２００社となり、実に、９８００／１０，０００＝９８％のシステム投資が削減可能となり、相互取引の企業が増える程、その削減効果は増大する。この削減効果は、企業間あるいはシステム間のデータ交換を行う場合、独自フォーマットのままのデータ交換に比較し、標準フォーマットを介したデータ交換を行う場合の長所として言及されることが一般的である。しかし、本ＳＸＰサービスシステムは、標準フォーマットを標準プロファイルとして定義すると共に、各種の独自フォーマットをそれぞれシステムプロファイルとして定義し、かつ、標準プロファイルと各システムプロファイルとの間の各データ項目間の関連情報や変換方法も含めた変換情報を定義し、これら標準プロファイル、システムプロファイル及び変換定義をＳＸＰとして提供する点を大きな特徴とし、かつ、この点を上記の単なる標準フォーマットを介したデータ交換と比較して大きな相違点としている。本ＳＸＰサービスシステムは、かかる構成（ＳＸＰ）を利用して、標準プロファイルにアクセスするためのプログラムやシステムを開発することなくデータ交換を実現する手段を提供することができ、特にパッケージソフトウエアを利用することの多い中小企業にとっては、革新的な仕組みとなる。なお、この図８４を参照した説明は、上記ＳＸＰ特徴４に対応するものである。
【０１８０】
次に、上記図８４に関連して説明したＳＸＰサービスシステムの特徴について、図８５にしたがって更に詳細に説明する。図８５は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる複数の企業システム間でのデータ変換の仕組みを従来の標準ＸＭＬデータを介したデータ変換の仕組みと比較して説明する説明図である。
現在、業界内でのデータ管理やデータ利用を円滑化または効率化等する目的で、各種の業界標準ＸＭＬが提案されている。例えば、財務情報に関する標準ＸＭＬデータとしてのＸＢＲＬ（ｅＸｔｅｎｓｉｖｅ  Ｂｕｓｉｎｅｓｓ  Ｒｅｐｏｒｔｉｎｇ  Ｌａｎｇｕａｇｅ）データ、電子商取引に関する標準ＸＭＬデータとしてのｅｂＸＭＬ（ｅｌｅｃｔｒｉｃ  ｂｕｓｉｎｅｓｓ  ＸＭＬ）データ、医療情報に関する標準ＸＭＬデータとしてのＭＭＬ（Ｍｅｄｉｃａｌ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）データ等が提案されている。そして、業界標準ＸＭＬデータ１２２０を利用して、例えば、ある会社の独自データを他の会社の独自データへと変換するには、図８５（ａ）に示すように、独自フォーマットの独自データを業界標準ＸＭＬ１２２０へとデータ変換する変換システムを利用する。即ち、Ａ社１２３０とＢ社１２４０との間でデータ交換を行う場合、まず、Ａ社１２３０及びＢ社は、自社用の変換システム１２３１及び変換システム１２４１により、自社の独自フォーマットにしたがった独自データであるＡ社独自データ１２３２及びＢ社独自データ１２４２を、業界標準ＸＭＬの仕様や規則（ＤＴＤやＸＭＬスキーマ等）にしたがった標準ＸＭＬデータであるＡ社変換標準ＸＭＬデータ１２３３及びＢ社変換標準ＸＭＬデータ１２４３へとそれぞれ変換する。そして、Ａ社１２３０及びＢ社１２４０は、Ａ社変換標準ＸＭＬデータ１２３３及びＢ社変換標準ＸＭＬデータ１２４３を使用してデータ交換を行う。なお、Ａ社１２３０及びＢ社１２４０は、データ交換した相手側のＸＭＬ標準データであるＢ社変換標準ＸＭＬデータ１２４３及びＡ社変換標準ＸＭＬデータ１２３３を、前記自社用の変換システム１２３１及び変換システム１２４１を使用して、自社の独自データであるＡ社独自データ１２３２及びＢ社独自データ１２４２へと変換する。このように、各社は、自社独自フォーマットによる独自データと標準フォーマットによる標準ＸＭＬデータとの間でのデータ交換に、独自の変換プログラムや変換システムを開発等して用意する必要がある。
【０１８１】
これに対し、図８５（ｂ）に示すように、ＳＸＰサービスシステムは、業界ごとに標準フォーマットを定義する標準プロファイル（ＳＸＰ標準プロファイル）１２５０と、その業界に属する会社ごとの独自フォーマットを定義する独自データプロファイル（Ａ社独自データプロファイル１２５２、Ｂ社独自データプロファイル１２６２、・・・）と、ＳＸＰ標準プロファイル１２５０と各社の独自データプロファイル１２５２，１２６２・・・との間の変換規則を定義する変換定義１２５１，１２６１・・・と、ＳＸＰ標準プロファイル１２５０と各社の独自データプロファイル１２５２，１２６２・・・と変換定義１２５１，１２６１・・・とを参照して各社の独自データ間でのデータ交換を実行するＰＸＥ（Ｐｒｏｆｉｌｅ  ｅＸｃｈａｎｇｅ  Ｅｎｇｉｎｅ）データ変換システム１２５３とを備えている。なお、前記ＳＸＰ標準プロファイル１２５０は、上記実施の形態のＥＤＩ用の標準データプロファイル（列管理テーブルの標準データ項目定義部分）に対応し、各種業務システムのデータ交換用となるよう各種業界標準データフォーマットに対応する定義情報を格納する。また、各社の独自データプロファイル１２５２，１２６２・・・は、上記実施の形態のＥＤＩ用の企業別データプロファイル（列管理テーブルの企業別データ項目定義部分）に対応し、各種業界に属する企業ごとの独自データフォーマットに対応する定義情報を格納する。更に、変換定義１２５１，１２６１・・・は、上記実施の形態のＥＤＩ用の項目関連定義に対応する。そして、ＳＸＰサービスシステムでは、例えば、Ａ社１２３０とＢ社１２４０との間でデータ交換を行う場合、ＰＸＥデータ変換システム１２５３が、Ａ社独自データ１２３２及びＢ社独自データ１２４２から、対応するＡ社独自データプロファイル１２５２及びＢ社独自データプロファイル１２６２をそれぞれ判断し、そのＡ社独自データプロファイル１２５２及びＢ社独自データプロファイル１２６２と対応する変換定義１２５１及び変換定義１２６１をそれぞれ使用して、Ａ社独自データ１２３２及びＢ社独自データ１２４２をＳＸＰ標準プロファイルにしたがったＳＸＰ標準フォーマットデータへとそれぞれ変換し、Ａ社１２３０及びＢ社１２４０間でのＳＸＰ標準フォーマットデータによるデータ交換を可能にする。また、ＳＸＰサービスシステムでは、ＰＸＥデータ変換システム１２５３が、Ａ社独自データプロファイル１２５２及びＢ社独自データプロファイル１２６２並びに変換定義１２５１及び変換定義１２６１をそれぞれ利用して、Ｂ社１２４０及びＡ社１２３０から受信したＳＸＰ標準フォーマットデータを、Ａ社独自データ１２３２及びＢ社独自データ１２４２にそれぞれ変換する。このように、ＳＸＰサービスシステムによれば、各社は、自社独自フォーマットによる独自データと標準フォーマットによる標準ＸＭＬデータとの間でのデータ交換に、独自の変換プログラムや変換システムを開発等して用意する必要はなく、パッケージソフト等の既存の簡便なシステムにより自社独自データさえ用意すれば、そのデータフォーマットに対応した独自データプロファイル及び変換定義を利用して、ＳＸＰ標準プロファイルデータへのデータ変換を行い、��のＳＸＰ標準プロファイルデータによる他社とのデータ交換を容易かつ低コストでに実現することができ、また、そのＳＸＰ標準プロファイルデータを利用して自社独自フォーマットや他社独自フォーマットのデータへのデータ変換を容易かつ低コストで実現することができる。
【０１８２】
図８６は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで使用する各種業界・各種システム・各種パッケージソフトのデータ構造乃至ファイル構成（テーブル関連）を例示するデータ構造図である。
ＳＸＰサービスシステムの管理対象データは、あらゆる任意のデータフォーマットのデータであり、例えば、図８６の左列から右列に示すように、会社マスターデータ（最左列）、商品マスターデータ（左から２番目の列）等、任意の業務の任意のシステムで使用される任意のマスター系データや、販売データ（中央列）、仕入データ（右から２番目の列）、会計データ（最右列）等、任意の業務の任意のシステムで使用される任意のトランザクション系データが管理対象となる。このように、ＳＸＰサービスシステムは、上記電子商取引用のデータ管理システム（実施の形態４、実施の形態５）と基本的には同一の構成を有する一方で、管理対象データがあらゆる業務内容に関するあらゆるデータフォーマットに及ぶ汎用データ管理システムとなる。よって、実施の形態１１に係るデータ管理システムしてのＳＸＰサービスシステムは、管理対象の業務やシステム（データフォーマットを含む）の構成の相違や変更に柔軟に対応できるよう、上記データ管理システム（実施の形態４または実施の形態５等）のシステム構成を変更し、例えば、一部のテーブルをＸＭＬするとともに、業務やシステムへの対応度を高めている。また、本ＳＸＰサービスシステムは、対象システム、同対象システム内の各テーブル（ＲＤＢの場合）や各ファイル（他ＤＢの場合）、同テーブル・ファイル内の各レコードといった階層構造でデータを管理する。
【０１８３】
図８７は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで使用するデータベースのテーブル一覧を示す表である。
本ＳＸＰシステムで使用するデータベースのテーブル構造について説明する。本ＳＸＰシステムで使用するデータベースは、リレーショナルデータベース（ＲＤＢ）の本来のテーブルと、ＲＤＢのテーブル（ＲＤＢテーブル）をＸＭＬ化したテーブル（ＸＭＬ化テーブル）とを組み合わせて使用し、図８７に示すような各種ＲＤＢテーブル及び各種ＸＭＬ化テーブルをデータ構造・定義構造として備えている。詳細には、まず、企業管理（ＣＵＳＴＯＭＥＲ）テーブルは、本ＳＸＰサービスシステムが対象とするシステム（パッケージを含む）を利用する企業や本ＳＸＰサービスシステムのユーザー企業の各種情報、例えば、図８７の最左列に示す会社情報等の企業情報を管理するＲＤＢのテーブルである。企業管理テーブルは、上記実施の形態５のデータ管理システムにおける図３６の企業管理テーブルに相当する構成を有している。次に、イベント管理（ＥＶＥＮＴ）テーブルは、企業間で交換されるデータ種類のイベント、即ち、システム間のデータ連携のイベントを管理するＸＭＬ化テーブルである。イベント管理テーブルは、上記実施の形態５のデータ管理システムにおける図３７のデータ交換管理（ＥＸＣＨＡＮＧＥ）テーブルに相当する構成を有し、更に、データ交換における送信側システム及び受信側システムを特定するための送信側システムタグ名称及び受信側システムタグ名称、対象イベントを特定するためのイベントタグ名称等、ＸＭＬ化のためのデータ項目を追加して、対応するデータ項目値を格納している。また、イベント管理テーブルは、更に、データ変換の種別を示すデータ項目（「イベント属性」）を追加して、対応するデータ項目値を格納している。ここで、イベント管理テーブルは、本ＳＸＰサービスシステム１２５０のコアエンジンであるＰＸＥデータ変換システム１２５３が、実施の形態４のデータ管理システムのように受発注データに限定したデータ変換だけではなく、あらゆるデータのデータ変換及びあらゆるシステム間でのデータ交換に対応するため、上記データ交換管理（ＥＸＣＨＡＮＧＥ）テーブルを置き換える形で本ＳＸＰサービスシステムに追加されたものである。また、イベント管理テーブルは、本ＳＸＰサービスシステムが、交換されるデータをメッセージとして取扱い、メッセージを受け取ることで起動するいわゆるメッセージドリブン型のシステムであることに対応して、想定される全てのイベントの定義（データ項目）を設定している。通常、本ＳＸＰサービスシステムにおけるデータ連携の基本は、メッセージドリブンの単一テーブルの所定データフォーマットのデータを、他のデータフォーマットのデータへと変換して他の単一テーブルへと格納すべく構成されるイベントである。しかし、本ＳＸＰサービスシステムにおけるデータ連携において、複数のテーブル（変換前テーブル群）のデータを、同時に、他の複数のテーブル（変換先テーブル群）のデータへと変換する場合もある。よって、本ＳＸＰサービスシステムでは、かかる場合の各種のイベントに関し、変換前テーブル群をどのように変換先テーブル群にデータ連携するかについて、イベント管理テーブルにそれぞれ定義している。例えば、実施の形態５のデータ交換管理テーブルの定義に則して説明すると、例えば、受発注業務において、ファイルヘッダ情報を格納するファイルヘッダテーブル、伝票ヘッダ情報を格納する伝票ヘッダテーブル、伝票明細を格納する伝票明細テーブル等、複数のテーブルを同時にデータ変換する場合において、その変換処理を「受注」イベントとしてイベント定義テーブルに定義する。
【０１８４】
次に、テーブル管理（ＴＡＢＬＥ）テーブルは、企業毎及びシステム毎のデータ種類別の各種テーブルやレコードを管理するＸＭＬ化テーブルである。テーブル管理テーブルは、上記実施の形態５のデータ管理システムにおける図３９のテーブル管理（ＴＡＢＥＬ）テーブルに相当する構成を有し、更に、上記システムタグ名称、同対象システム内のテーブルを特定する（或いは、更に、そのテーブルの入出力区分やそのテーブルのテーブル構造を特定する）ためのテーブルタグ名称等、ＸＭＬ化のためのデータ項目を追加して、対応するデータ項目値を格納している。テーブル管理テーブルは、本ＳＸＰサービスシステムが対象とするあらゆるシステム（パッケージソフトを含む）内の各テーブルの情報やデータを、各システム単位で管理する。また、テーブル管理テーブルは、データ変換の対象テーブルが複数で構成される場合に、その順番を示すデータ項目（「テーブル枝番」等）を更に追加して、対応するデータ項目値を格納している。なお、テーブル管理テーブルは、上記テーブルタグ名称の構成等に対応して、テーブル構造を特定するための情報を定義するデータ項目（「テーブル構造」等)や、テーブルの入出力区分（インポート用、エクスポート用、共用等）を特定するための情報を定義するデータ項目（「テーブル属性」等）を更に追加して、対応するデータ項目値を格納してもよい。
【０１８５】
次に、列管理（ＣＯＬＵＭＮ）テーブルは、前記テーブル管理テーブルが対象とする各テーブル（各レコード）を構成する各データ項目の属性、位置、長さ等を管理するＸＭＬ化テーブルである。列管理テーブルは、実施の形態５のデータ管理システムにおける図４０〜図４２の列管理テーブルに相当する構成を有し、更に、上記システムタグ名称、上記テーブルタグ名称、上記テーブル枝番に加え、各レコードのデータ項目を特定するための項目タグ名称等、ＸＭＬ化のためのデータ項目を追加して、対応するデータ項目値を格納している。即ち、列管理テーブルは、各管理対象データのデータフォーマットを定義する。次に、項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルは、列管理テーブルで定義した各データ項目のなかで、値と内容の変換が必要な際に、各データ項目に格納される値と該当する意味内容を管理するＸＭＬ化テーブルである。項目値管理テーブルは、上記実施の形態５のデータ管理システムにおける図４３の項目値管理テーブルに相当する構成を有し、更に、上記システムタグ名称、上記テーブルタグ名称、上記テーブル枝番、上記項目タグ名称等、ＸＭＬ化のためのデータ項目を追加して、対応するデータ項目値を格納しているいる。
【０１８６】
次に、行管理（ＲＯＷ）テーブルは、データ交換用に読み込んだデータのレコード単位の識別子と所定の基礎データとを格納するＲＤＢのテーブルである。行管理テーブルでは、読み込んだ（格納する）レコード単位で、新たなレコード（前記識別子等からなる行管理テーブル自体のレコード）が作成される。行管理テーブルは、実施の形態５のデータ管理システムにおける図４７の行管理テーブルに相当する構成を有している。また、行管理テーブルは、上記ＸＭＬ化したテーブル管理テーブル等の構成に対応して、上記システムタグ名称やテーブルタグ名称等のデータ項目を追加し、更に、格納する各識別子似対応して識別子タグ名称をデータ項目として追加して、それぞれ、対応するデータ項目値を格納している。なお、行管理テーブルに格納する基礎データ（データ項目）としては、このほかに、送信企業コード、受信企業コード等とすることができる。行管理テーブルは、本ＳＸＰサービスシステムに格納された識別子（表計算システムにおける行に当たる情報）を格納するものであり、読込んだデータのレコード単位の識別子と基礎データとを、入力データの何番目のレコードであるかを示す行ＩＤ（ＲＯＷ＿ＩＤ）をキー項目として格納する。
【０１８７】
次に、値管理（ＣＥＬＬ）テーブルは、前記行管理テーブルの行ＩＤと前記列管理テーブルの列ＩＤとにより一意に示されるセルに、データ交換時の入力データのデータ項目値を格納するＲＤＢのテーブルである。値管理テーブルは、実施の形態５のデータ管理システムにおける図４８の値管理テーブルに相当する構成を有している。また、値管理テーブルは、本ＳＸＰサービスシステムのＸＭＬ化に対応して、格納するデータ項目値に対応する項目タグ名称等のデータ項目を追加して、対応するデータ項目値を格納している。上記実施の形態で述べたように、値管理テーブルは、１レコードの内容をまとめて格納することも可能である。
【０１８８】
次に、項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルは、列管理テーブルに定義されて管理されている（異なるデータプロファイルの）データ項目間の関連定義（リンク）情報を管理するＸＭＬ化テーブルである。項目関連定義テーブルは、実施の形態５のデータ管理システムにおける図４４の項目関連定義テーブルに基本的に対応する構成を有しているが、上記テーブル管理テーブルや列管理テーブルのＸＭＬ化、及び、ＸＭＬ化したイベント管理テーブルの構成に対応した構成となっている。即ち、項目関連定義テーブルは、データ項目として、各項目関連情報を一意に示す管理番号であるチェーンＩＤ（ＣＨＡＩＮ＿ＩＤ）、上記送信側システムタグ名称、上記受信側システムタグ名称、上記イベントタグ名称、上記イベント属性、イベント内の複数の処理グループの処理順序を示す処理グループ（ＥＶＥＮＴ＿ＧＲＯＵＰ）、イベント内の複数のサブグループの処理順序を示す処理順序（ＥＶＥＮＴ＿ＳＥＱ）、トリガー（変換元）となるテーブルを示すＸＭＬタグ名称であるトリガーテーブルタグ（ＴＲＩＧＧＥＲ＿ＴＡＢＬＥ＿ＴＡＧ）、トリガーとなるデータ項目を示すＸＭＬタグ名称であるトリガー項目タグ（ＴＲＩＧＧＥＲ＿ＣＯＬＵＭＮ＿ＴＡＧ）、変換対象（変換先）となるテーブルを示すＸＭＬタグ名称である対象テーブルタグ（ＭＡＩＮ＿ＴＡＢＬＥ＿ＴＡＧ）、変換対象となるデータ項目を示すＸＭＬタグ名称である対象項目タグ（ＭＡＩＮ＿ＣＯＬＵＭＮ＿ＴＡＧ）、項目関連情報について使用する関数を示すコード（ＦＵＮＣＴＩＯＮ＿ＣＯＤＥ：後述の関数テーブル参照）、その関数で使用するパラメータ領域を示すパラメータ（ＰＡＲＡＭ）等を有し、対応するデータ項目値を格納している。このように、項目関連定義テーブルは、列管理テーブルに定義した各データ項目間の関連情報を管理する。即ち、項目管理テーブルは、トリガーとなるデータ項目と変換対象となるデータ項目とを互いに対応付けて格納すると共に、データ項目間でデータ項目値を変換する再に使用する関数及びそのパラメータを管理している。原則として、上記実施の形態と同様、トリガー項目にはシステムプロファイルの各データ項目を選択して格納し、対象項目には標準プロファイルの各データ項目を選択して格納する。これにより、前記イベント管理テーブルで定義されたイベントごとに、標準プロファイルの各データ項目を介して、変換元システムプロファイルの各データ項目と変換先システムプロファイルのデータ項目との間で、データ変換を実現する。
【０１８９】
次に、関数管理（ＦＵＮＣＴＩＯＮ）テーブルは、項目関連定義テーブルで使用するシステム関数を管理するＸＭＬ化テーブルである。関数管理テーブルは、実施の形態５のデータ管理システムにおける図４５の関数管理テーブルに相当する構成を有している。次に、納域管理（ＶＯＬＵＭＥ）テーブルは、ＳＸＰサービスシステムが入出力する各種データを格納するデータベースの格納域を管理するＲＤＢのテーブルである。格納息管理テーブルは、対象企業別、年度等により格納域を管理する。次に、企業別格納域管理（ＶＯＬＵＭＥ＿ＣＵＳＴＯＭＥＲ）テーブルは、作成ボリューム単位にデータ変換の対象とする企業を管理するＲＤＢのテーブルである。次に、システム管理（ＳＹＳＴＥＭ）テーブルは、本ＳＸＰサービスシステムのユーザ毎にシステム情報を管理するＲＤＢのテーブルであり、ユーザキー等を管理する。次に、作業管理（ＴＲＡＮＳＡＣＴＩＯＮ）テーブルは、本ＳＸＰサービスシステムのデータ変換作業をトランザクション毎に管理するＲＤＢのテーブルであり、１トランザクションを１入力ファイルとして管理する。次に、対象管理（ＳＹＳＴＥＭ＿ＯＢＪＥＣＴ）テーブルは、本ＳＸＰサービスシステムが対象とするオブジェクトを管理するＲＤＢのテーブルであり、例えば、伝票、梱包、支払内容等のオブジェクトを管理する。対象管理テーブルは、実施の形態５のデータ管理システムにおける図４６の対象管理テーブルに相当する構成を有している。次に、入出力管理（ＦＯＲＭ）テーブルは、画面や帳票を管理するＸＭＬ化テーブルである。入出力管理テーブルは、実施の形態５のデータ管理システムにおける図５６及び図５９の入出力管理テーブルに相当する構成を有している。次に、入出力項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、画面や帳票に入出力するデータ項目のサイズや位置を管理するＸＭＬ化テーブルである。入出力項目管理テーブルは、実施の形態５のデータ管理システムにおける図５５及び図５８の入出力項目管理テーブルに相当する構成を有している。次に、キー管理（ＫＥＹ）テーブルは、格納レコードのキーとなる値を格納するＲＤＢのテーブルである。キー管理テーブルは、対象管理テーブルとの対照表となっている。キー管理テーブルは、本ＳＸＰサービスシステムに格納されたレコードの索引キーや外部参照キーや識別子に当たる情報を格納し、格納されたレコード間のリレーションを検索したり、保全したりするために利用される。
【０１９０】
なお、上記各テーブルの構成（データ項目）は、本ＳＸＰサービスシステムの趣旨を損なわない範囲で適宜変更することができる。
【０１９１】
図８８は本発明の実施の形態１１に係るデータ管理システムしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる標準プロファイル（汎用商品プロファイル）を使用した異なるアプリケーションシステム（パッケージソフト）間のデータ交換処理の概要を示すデータフロー図である。
図８８は図８３のシステム構成をより詳細に説明するものである。図８８に示すように、パッケージＡの商品データ９１０は、前述のように、商品コード９１１、品名９１２、規格名９１３、単価９１４、仕入先コード９１５からなる固有のデータ項目定義１３１０を有している。また、パッケージＢの商品データ１０１０は、商品コード１０１１、商品名１０１２、商品名カナ１０１３、下代１０１４、上代１０１５からなる固有のデータ項目定義１３１０を有している（便宜上、両パッケージのデータ項目定義を同一部材番号で表示しているが、各パッケージはそれぞれ固有のデータ項目定義を有する）。そして、これらパッケージＡに固有のデータ項目定義１３１０とパッケージＢに固有のデータ項目定義１３１０とは、それぞれ、上記実施の形態１〜１０と同様、商品管理用の列管理テーブル（図示略）に項目定義情報の一部として格納されている。なお、図示しないその他の（全ての）パッケージソフトに固有のデータ項目定義も、それぞれ、商品管理用の列管理テーブルに項目定義情報の一部として全て格納されている。即ち、本実施の形態のデータ項目定義（単に「項目定義」という場合もある）とは、企業システム＞パッケージソフト＞ファイル毎に含まれるデータ項目を定義した情報のことをいう。更に、商品管理用標準プロファイルとしての汎用商品プロファイル１３３０は、上記のように、商品コード１１１１、品名１１１２、品名カナ１１１３、規格名１１１４、規格名カナ１１１５、原価１１１６、単価１１１７、定価１１１８、仕入先コード１１１９、・・・１１２０等、存在する全てのパッケージソフトの項目定義を網羅するデータ項目を定義している。そして、この汎用商品プロファイルも、上記実施の形態１〜１０の場合と同様、列管理テーブルに格納されている。なお、汎用商品プロファイルは、企業で扱う商品情報の汎用データを定義するものであるが、標準プロファイルであるので関連定義情報は持たない。関連定義情報は、当該汎用商品プロファイル等の標準プロファイルと関連する各システムプロファイルの定義に含め、ＳＸＰとする。
【０１９２】
一方、本ＳＸＰサービスシステムは、上記実施の形態１〜１０の項目関連定義テーブルを利用したデータ交換の場合と同様にして、列管理定義テーブルに項目定義したパッケージＡのデータ項目（項目定義１３１０の各データ項目）と汎用商品プロファイル１３３０のデータ項目との間の関連定義情報（マッピング情報）１３２０を予め定義すると共に、列管理定義テーブル１３３０に項目定義したパッケージＢのデータ項目（項目定義１３１０の各データ項目）と汎用商品プロファイル１３３０のデータ項目との間の関連定義情報（マッピング情報）１３２０を予め定義している。即ち、本実施の形態では、各パッケージソフト固有のデータ項目と汎用商品プロファイルのデータ項目との間の関連定義は、上記実施の形態１〜１０と同様、商品管理用の項目関連定義テーブル（図示略）に項目関連定義情報として格納されている。このように、本実施の形態の関連定義情報を管理する項目関連定義テーブルは、列定義テーブルに定義した各パッケージソフトのデータ項目と汎用商品プロファイルの標準データ項目との関連を定義するものである。なお、本実施の形態では、上記項目定義及び関連定義の二つの定義情報を合わせてシステムプロファイルと称する。これにより、汎用商品プロファイル１３３０を介して、パッケージＡの商品データ９１０のデータ項目定義１３１０の各データ項目とパッケージＢの商品データ１０１０のデータ項目定義１３１０の各データ項目との間でのデータ交換が可能になる。なお、この図８５を参照した説明は、上記ＳＸＰ特徴２に対応するものである。
【０１９３】
実施の形態１２
図８９は本発明の実施の形態１２に係るデータ管理システムしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるシステムプロファイルの配信サービスシステムの概要を示すデータフロー図である。
図８９に示すように、ＳＸＰサポートセンター（センター側サーバーシステム）１４００は、Ａパッケージ固有のシステムプロファイル（項目定義と関連定義）であるＳＸＰ（システムエクスチェンジプロファイル）１４０１、Ｂパッケージ固有のシステムプロファイル（項目定義と関連定義）であるＳＸＰ（システムエクスチェンジプロファイル）１４０２、Ｃパッケージ固有のシステムプロファイル（項目定義と関連定義）であるＳＸＰ（システムエクスチェンジプロファイル）１４０３、Ｄパッケージ固有のシステムプロファイル（項目定義と関連定義）であるＳＸＰ（システムエクスチェンジプロファイル）１４０４、Ｅパッケージ固有のシステムプロファイル（項目定義と関連定義）であるＳＸＰ（システムエクスチェンジプロファイル）１４０５・・・等の異なる種類のパッケージのＳＸＰを格納・管理している。また、ＳＸＰサポートセンター１４００は、各パッケージのＳＸＰ間でのデータ交換を実行するエンジンとなるＰＸＥ（Ｐｒｏｆｉｌｅ  Ｅｘｃｈａｎｇｅ  Ｅｎｇｉｎｅ：プロファイルエクスチェンジエンジン）１４０６を備えている。一方、ＳＸＰ利用ユーザー（ユーザー側クライアントシステム）１４１０は、ＳＸＰサポートセンター１４００と同様のＰＸＥ１４０６を備えている。そして、ＳＸＰ利用ユーザー１４１０は、ＳＸＰサポートセンター１４００から、自社が使用中でデータ交換を必要とする任意の複数のパッケージソフトのＳＸＰをインターネット等のネットワークＮＴを介してダウンロードし、ＰＸＥ１４０６によりパッケージソフト間でデータ交換（エクスポートデータをインポート処理）する。例えば、ＳＸＰ利用ユーザー１４１０は、所望のパッケージ間、例えば、パッケージＡ９００とパッケージＢ１０００との間でデータ交換をする場合、ＡパッケージのＳＸＰ１４０１とＢパッケージのＳＸＰ１４０２とをＳＸＰサポートセンター１４００からダウンロードし、ＰＸＥ１４０６により、ＳＸＰ１４０１の項目定義及び関連定義とＳＸＰ１４０２の項目定義及び関連定義とを利用して、パッケージＡ９００とパッケージＢ１０００との間でエクスポートデータをインポート処理するデータ交換処理を実行する。このように、本実施の形態のＳＸＰサービスシステムは、各パッケージのシステムプロファイル（ＳＸＰ）の配信サービスシステムとしての機能を実現する。なお、この図８６を参照した説明は、上記ＳＸＰ特徴３に対応するものである。
【０１９４】
実施の形態１３
図９０は本発明の実施の形態１３に係るデータ管理システムしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる業界システムプロファイルの作成及び配信処理と、当該業界のパッケージ開発ベンダーによるパッケージのシステムプロファイルの作成及び配信処理と、当該業界システムプロファイルとパッケージのシステムプロファイルとの関連定義処理との概要を示すデータフロー図である。
図９０に示すように、ＳＸＰサポートセンター１４００は、上記各パッケージのＳＸＰ１４０１〜１４０５に加え、各業界に固有の取扱データ項目やフォーマット（プロファイル）情報に対応して、上記実施の形態１１と同様にして、業界各社の異なるシステム間でのデータ交換を可能にすべく作成された固有のシステムプロファイル（項目定義及び関連定義）として、業界標準ＳＸＰ（システムエクスチェンジプロファイル）を格納・管理している。例えば、ＳＸＰサポートセンター１４００は、ａ業界標準ＳＸＰ１４０９、ｂ業界標準ＳＸＰ１４０８、ｃ業界標準ＳＸＰ１４０７・・・を格納・管理する。この業界標準システムプロファイルは、各社のシステム固有のデータ項目を定義する各社プロファイル情報と、業界で取扱う全てのデータ項目を網羅する標準プロファイルとを列管理テーブルに定義した項目定義情報と、各社プロファイルと標準プロファイルとの間での項目関連定義を項目関連定義テーブルに定義した項目関連定義情報とを備え、当業界団体１４２０等により作成される。例えば、ａ業界団体１４２０が、自ら策定したａ業界標準メッセージ１４２１に基づき、図９０中の丸数字１の矢印で示すように、ａ業界標準ＳＸＰ１４０９を作成する。そして、ａ業界団体１４２０は、図９０中の丸数字２の矢印で示すように、作成したａ業界標準ＳＸＰ１４０９をインターネットＮＴ等のネットワークを介してＳＸＰサポートセンター１４００にアップロードする。他業界（ｂ業界、ｃ業界・・・）についても、業界団体（ｂ業界団体、ｃ業界団体・・・）１４２０が、同様にして、自業界の標準メッセージに基づいて業界標準ＳＸＰ（ｂ業界標準ＳＸＰ１４０８、ｃ業界標準ＳＸＰ１４０７・・・）を作成し、ＳＸＰサポートセンター１４００にアップロードする。
【０１９５】
一方、各業界に対応したパッケージソフトを開発するパッケージベンダーが、自らが開発するパッケージソフト固有のパッケージＳＸＰ（上記実施の形態１１で説明したものと同様のもの）を作成すると共に、所望の業界向けのパッケージソフトを開発する場合等に、当該業界の業界標準ＳＸＰと自社パッケージソフト固有のパッケージＳＸＰとの間で項目関連定義をし、同じく、ＳＸＰサポートセンター１４００にアップロードする。例えば、Ｅパッケージ１４３１を開発したＥパッケージ開発ベンダー１４３０は、図９０中の丸数字３の矢印で示すように、ＳＸＰサポートセンター１４００から、開発したＥパッケージ１４３１の想定ユーザが属するａ業界のａ業界標準ＳＸＰ１４０９をダウンロードする。次に、Ｅパッケージ開発ベンダー１４３０は、図９０中の丸数字４の矢印で示すように、開発したＥパッケージ１４３１のエクスポート／インポートフォーマット（ＥＸ／ＩＮフォーマット）からＥパッケージ１４３１のＳＸＰ１４０５の項目定義を行い、次に、図９０中の丸数字５の矢印で示すように、Ｅパッケージ１４３１のＳＸＰ１４０５の項目定義とダウンロードしたａ業界標準ＳＸＰ１４０９の項目定義との間の項目関連定義を行う。次に、Ｅパッケージ開発ベンダー１４３０は、図９０中の丸数字６の矢印で示すように、作成完了したＥパッケージ１４３１のＳＸＰ１４０５をＳＸＰサポートセンター１４００にアップロードする。このようにして、ＳＸＰサポートセンター１４００には、各業界自身により、各業界の業界標準ＳＸＰが格納され、必要に応じて（各業界自身等により）更新等して管理されると共に、各業界に対応したパッケージソフトを開発するパッケージベンダー自身により、当該業界の業界標準ＳＸＰとの間での項目関連定義が完了した開発パッケージソフト固有のパッケージＳＸＰ（上記実施の形態１１で説明したものと同様のもの）が格納され、必要に応じて（各開発ベンダー自身等により）更新等して管理される。なお、この図９０を参照した説明は、上記ＳＸＰ特徴７，８，９に対応するものである。
【０１９６】
実施の形態１４
以下、本発明の実施の形態１４に係るＳＸＰサービスシステムについて説明する。まず、実施の形態１４に係るＳＸＰサービスシステムの背景技術について図９１〜図９４にしたがって説明する。図９１は従来の中小企業の業務フローと電子データ交換（ＥＤＩ）との関係を概略的に示すデータフロー図である。
図９１は、中小企業の業務フローとＥＤＩ（電子データ交換）との関係を示すものである。図９１に示すように、例えば、ある会社では、販売管理ソフト１５００、物流・生産管理ソフト１５１０、仕入管理ソフト１５２０、会計管理ソフト１５３０を利用して管理を行っているとする。この場合、商品の見積もり依頼を経て受注業務が発生すると、まず、販売管理担当者（営業部等）が、販売管理ソフト１５００を利用して見積データ１５０１を入力する。すると、受注に伴って、見積データ１５０１から受注データ１５０２が作成される。次に、この受注データ１５０２は、物流・生産管理担当者（生産部等）により、物流・生産管理ソフト１５１０に入力される。このとき、担当者は、受注データ１５０２を受注管理ソフト１５００からエクスポートしてＣＳＶファイル等に変換し、上記のようにこのＣＳＶファイル等に所定のデータ加工作業を行ったうえで、加工後のデータを物流・生産管理ソフト１５１０にインポートする。すると、物流・生産管理ソフト１５１０が、入力データに基づき、納期回答データ１５１１、出荷指示・生産指示データ１５１２を順次作成する。また、物流・生産管理ソフト１５１０は、受注商品の生産が必要ない場合（商品を外部から仕入れる場合）は、出荷指示・生産指示データ１５１２から、出庫データ１５１３及び梱包・出荷データ１５１４を順次を作成する。一方、物流・生産管理ソフト１５１０は、受注商品の生産が必要な場合は、出荷指示・生産指示データ１５１２から、部品調達データ１５１５及び生産データ１５１６を順次作成し、その後、前記出庫データ１５１３及び梱包・出荷データ１５１４を順次を作成する。なお、これらのデータ入力において、一部人手が介在する場合（一部手入力を必要とする場合）もある。
【０１９７】
ここで、商品を外部から仕入れる場合は、出庫データ１５１３が、仕入担当者（購買部等）により、仕入管理ソフト１５２０に入力される。このとき、担当者は、出庫データ１５１３を物流・生産管理ソフト１５１０からエクスポートしてＣＳＶファイル等に変換し、上記のようにこのＣＳＶファイル等に所定のデータ加工作業を行ったうえで、加工後のデータを仕入管理ソフト１５２０にインポートする。すると、仕入管理ソフト１５２０が、入力データに基づき、発注データ１５２１、入荷データ１５２２、入庫データ１５２３、支払データ１５２４、出金データ１５２５を順次作成する。なお、これらのデータ入力において、一部人手が介在する場合（一部手入力を必要とする場合）もある。一方、物流・生産管理ソフト１５１０からの梱包・出荷データ１５１４は、担当者により、再度、販売管理ソフト１５００に入力される。このとき、担当者は、梱包・出荷データ１５１４を物流・生産管理ソフト１５１０からエクスポートしてＣＳＶファイル等に変換し、上記のようにこのＣＳＶファイル等に所定のデータ加工作業を行ったうえで、加工後のデータを販売管理管理ソフト１５００にインポートする。すると、販売管理ソフトが、入力データに基づき、売上データ１５０３、月締処理データ１５０４、請求データ１５０５、入金データ１５０６を順次作成する。なお、これらのデータ入力において、一部人手が介在する場合（一部手入力を必要とする場合）もある。また、通常、会計管理ソフト１５３０は、上記各ソフト１５００，１５１０，１５２０の入出力とは別個独立して、会計担当者（経理部等）が、必要な会計データを入力し、財務管理データ１５３１や入出金管理データ１５３２等を作成する。
【０１９８】
上記会計データに関連する従来の課題について説明する。図９２は従来の中小企業の導入パッケージソフトによるデータ管理の態様を概略的に示すデータフロー図である。
図９２に示すように、中小企業の導入するパッケージソフトとしては、図９１で説明したような販売管理ソフト１５００と、仕入管理ソフト１５２０と、会見管理ソフト１５３０とが代表的である。この場合、販売管理担当者１５０７が、販売管理ソフト１５００を操作して入出力を行い、会計データとしての売掛データ１５０８を出力する。また、仕入管理担当者１５２６が、しいれ管理ソフト１５２０を操作して入出力を行い、会計データとしての買掛データ１５２７を出力する。そして、経理部門の会計管理担当者１５５０が、売掛データ１５０８から伝票（入金伝票）を手作業で作成すると共に、買掛データ１５２８から伝票（出金伝票）を手作業で作成し、これらの伝票データ（入出金データ）を会計管理ソフト１５３０に手入力する。すると、会計管理ソフト１５３０が、入力データから、前記財務データ１５３０等を作成して、貸借対照表や損益計算書等の財務諸表等を出力し、対外的な財務・会計報告や経営情報等の用に供する。このときの第１の課題として、経理部門で扱う売掛データ１５０８が、人手により再入力されている為、実際の売掛データ１５０８（販売データ）と必ずしも一致しない可能性がある。また、第２の課題として、経理部門で扱う買掛データが、やはり、人手により再入力されている為、実際の買掛データ（仕入データ）と必ずしも一致しない可能性がある。更に、第３の課題として、経理部門で扱う売掛／買掛データは、経理業務として丸められ（調整）ており、元と成っている詳細の販売／仕入データとの関連が分断されている可能性がある。従って、関係管理ソフト１５３０から得られるデータは、決算業務はできるが経営分析の有効なデータに成り得ない可能性がある。
【０１９９】
図９３は従来の電子データ交換（ＥＤＩ）と既存システムとの関係を受注処理業務の場合を例にとって概略的に示すデータフロー図である。
図９３は図９２のデータ交換作業を、受注業務に固有の情報、即ち、販売管理ソフト１５００の情報処理と物流・生産管理ソフト１５１０の情報処理の場合に限って示すものである。図９３に示すように、販売管理ソフト１５００の見積データ１５０１の作成に伴って、見積書１５０１ａが発行され、売上データ１５０３の作成に伴って、納品書１５０３ａが発行される。また、物流・生産管理ソフト１５１０の出荷指示・生産指示データ１５１２の作成に伴って、指示書１５１２ａが発行され、梱包／出荷データ１５１４の作成に伴って、梱包ラベル１５１４ａ及び送り状１５１４ｂが発行される。
【０２００】
図９４は従来の中小企業の導入パッケージソフトによるデータ交換処理の利用形態の概要を示すデータフロー図である。
従来の中小企業の導入パッケージソフトによるデータ交換処理の利用形態（利用シーン）としては、図９４に示すように、電子商取引担当者１５６１が、ウエブショップや電子市場（ＥＣ）１５６０での顧客情報や商品情報をカートデータ（お買い上げデータ）１７１１，１７１２，１７１３，１７１４，１７１５・・・から収集し、蓄積・活用することが考えられる。また、販売管理担当者１５０７が、販売管理ソフト１５００を利用して、外部企業（取引先）１７０１，１７０２，１７０３，１７０４・・・との取引情報（販売管理情報）を収集し、蓄積・活用することが考えられる。同様に、仕入管理担当者１５２６が、仕入管理ソフト１５２０を利用して、外部企業（仕入先）１７０１，１７０２，１７０３，１７０４・・・との取引情報（仕入管理情報）を収集し、蓄積・活用することが考えられる。また、販売管理担当者１５０７や仕入管理担当者１５２６が、販売管理ソフト１５００や仕入管理ソフト１５２０を利用して、電子商取引担当者１５６１が収集・蓄積した情報から関連する情報（販売関連情報や仕入関連情報）を抽出し、活用することも考えられる。一方、会計管理担当者１５３５が、会計管理ソフト１５３０を利用して、独自に収集した会計データや、販売管理担当者１５０７や仕入管理担当者１５２６が販売管理ソフト１５００や仕入管理ソフト１５２０を利用して収集・蓄積した情報から関連する情報（会計関連情報）を抽出し、活用することも考えられる。なお、販売管理ソフト１５００や仕入管理ソフト１５２０の入出力に際しては、商品管理データ１６００、出荷管理データ１６１０、在庫管理データ１６３０、取引先データ１６４０、入荷管理データ１６５０が参照される。これら各種データ交換に伴う従来の課題としては、まず第１の課題として、販売管理における取引先や仕入管理における仕入先等、外部企業とのデータ交換には、オリジナルデータ（一元管理されたデータ）の蓄積が必要となる。また、第２の課題として、既導入パッケージとのデータ交換には、オリジナルデータの蓄積は不必要ともいえるが、この場合、上記のように、データ参照の分断やデータ交換元とデータ交換先との間でのデータ不整合等の不具合がおきる可能性がある。更に、第３の課題としては、これらのデータ交換に上記実施の形態１〜１０のようなデータ管理システムを利用すれば、上記のような問題は解決できるが、この場合、同データ管理システムのネイティブデータ（一次データ）を利用することになり、データのマッチングにおける処理能力を相当必要とする可能性がある。よって、これらのデータ交換に上記実施の形態１〜１０のようなデータ管理システムを利用する場合、データをＸＭＬ形式で保存することにより対応することが好ましいと考えられる。これらの観点から、本発明は、下記実施の形態１４にて詳述するように、上記実施の形態１〜１０のデータ管理システムを更に改良して汎用性を持たせたＳＸＰサービスシステムを提供するものである。なお、図９１〜図９４の説明は、上記ＳＸＰ特徴１に対応するものである。
【０２０１】
図９５は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムの全体構成の概要を示す説明図である。
図９５に示すように、実施の形態１４に係るＳＸＰサービスシステムは、ＳＸＰセンター１８１０（上記実施の形態１３のＳＸＰサポートセンター１４００と同様の構成）を中心にして、標準プロファイルシステム１８００、企業プロファイルシステム１８２０及びプロファイル利用者システム１８３０からなるパッケージ展開構想を有している。詳細には、ＳＸＰセンター１８１０は、列管理テーブルや項目関連定義テーブル及びデータ変換エンジン（ＰＸＥ）等を利用して、プロファイル管理機能、データ変換機能、データ蓄積機能等の各機能を実現する。また、標準プロファイルシステム１８００は、上記汎用商品プロファイル、業界標準プロファイル（業界標準ＳＸＰ）等の各種標準プロファイルを管理するシステムであり、電子商取引（ＥＣ）機能、通信環境提供機能、受発注管理機能等の各機能を実現する。一方、企業プロファイルシステム１８２０は、企業独自のプロファイルによる商品管理機能、顧客管理機能、在庫管理機能等の各機能を実現するシステムである。なお、標準プロファイルシステム１８００の各標準プロファイル及び企業プロファイルシステム１８２０の各企業プロファイルは、ＳＸＰセンター１８１０のプロファイル管理機能実現手段（列管理テーブル、項目関連定義テーブル等）により管理される。また、プロファイル利用者システム１８３０は、各種のパッケージソフトにより売上管理、支払管理、財務管理等の管理を行う中小企業等の利用者が、ＳＸＰセンター１８１０を介して、前記企業プロファイルシステム１８２０の企業プロファイルと標準プロファイルシステム１８００の対応する標準プロファイルとを利用して、自社で使用するパッケージソフト間でのデータ交換機能を手作業による加工作業を要することなく実現するシステムである。なお、図９２の説明は、上記ＳＸＰ特徴２に対応するものである。
【０２０２】
図９６は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムのシステムプロファイルを処理するクラスの構成概要図である。
実施の形態１４のＳＸＰサービスシステムは、システムプロファイル（項目定義及び項目関連定義）の定義を、図９６に示すクラスに格納して処理を行う。詳細には、実施の形態１４のシステムプロファイル１９００は、テーブル（Ｔａｂｌｅ）クラス１９１０、テーブルジョイン（ＴａｂｌｅＪｏｉｎ）クラス１９２０、イベント（Ｅｖｅｎｔ）クラス１９３０、チェイン（Ｃｈａｉｎ）クラス１９４０を有している。テーブル（Ｔａｂｌｅ）クラス１９１０は、各テーブルの定義を行うものであり、サブクラスとして、カラム定義（Ｃｏｌｕｍｎ）クラス１９１０、インデックス定義（Ｉｎｄｅｘ）クラス１９２０を有している。カラム定義クラス１９１１に基づき、上記実施の形態１〜１０の列管理テーブルからインデックス定義を除いた列管理テーブルが作成される。また、インデックス定義クラス１９１２に基づき、上記実施の形態１〜１０の列管理テーブルのインデックス（ＴｒａｎＩＤ、伝票Ｎｏ．商品ＩＤ、取引先ＩＤ等）を抽出して別個に定義したインデックステーブルが作成される。また、テーブルジョイン（ＴａｂｌｅＪｏｉｎ）クラス１９２０は、テーブル間の関連定義をするものであり、サブクラスとして、連結カラム定義（ＪｏｉｎＣｏｌｕｍｎ）クラス１９２１、連結種別（ＪｏｉｎＫｉｎｄ）クラス１９２２を有している。連結カラム定義クラス１９２１に基づき、テーブル間の連結関係または階層関係を定義する情報（上記実施の形態１〜１０の列管理テーブルにおける階層関係の定義情報である枝番に対応する情報）を格納する連結カラム定義テーブルが作成される。また、イベント（Ｅｖｅｎｔ）クラス１９３０は、入力と出力で決定されるイベントを定義するものであり、サブクラスとして、データソース定義（ＤａｔａＳｏｕｒｃｅ）クラス１９３１、プロシージャ定義（Ｐｒｏｃｅｄｕｒｅ）クラス１９３２を有している。また、チェイン（Ｃｈａｉｎ）クラス１９４０は、項目間の関連を定義すると共に各関連定義について実行される変換処理を定義するものであり、サブクラスとして、項目関連定義（Ｃｈａｉｎ）クラス１９４１、ファンクション定義（Ｆｕｎｃｔｉｏｎ）クラス１９４２を有している。項目関連定義クラス１９４１に基づき、上記実施の形態１〜１０の項目関連定義テーブルと同様の項目関連定義テーブルが作成される。また、ファンクション定義クラス１９４２に基づき、上記実施の形態１〜１０の関数管理テーブルと同様のファンクション定義テーブルが作成される。なお、プロシージャ定義（Ｐｒｏｃｅｄｕｒｅ）クラス１９３２に関連するクラス（プロシージャで利用するクラス）として、プロシージャタイプ（ＰｒｏｃｅｄｕｒｅＴｙｐｅ）クラス１９３３、入力データソース（ＩｎｐｕｔＤａｔａＳｏｕｒｃｅ）クラス１９３４、出力データソース（ＯｕｔｐｕｔＤａｔａＳｏｕｒｃｅ）クラス１９３５、チェーン定義（Ｃｈａｉｎ）クラス１９３６、入力データ作業領域（ＩｎｐｕｔＤａｔａＷｏｒｋｓｐａｃｅ）クラス１９３７、出力データ作業領域（ＯｕｔｐｕｔＤａｔａＷｏｒｋｓｐａｃｅ）クラス１９３８を有している。
【０２０３】
図９７は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ変換処理の概要を示すデータフロー図である。
図９７に示すように、実施の形態１４のＳＸＰサービスシステムの変換システム２００００（システムプロファイル１９００を有するデータ交換エンジン（ＰＸＥ））は、変換及び交換手順として、以下の手順（処理）を実行する。まず、第１の手順（ＳＴＥＰ１）として、図９７中の丸付数字１に示すように、入力データ２００１の入力をイベントとして処理フロー２１００を起動する。次に、第２の手順（ＳＴＥＰ２）として、図９７中の丸付数字２に示すように、プロシージャ実行前処理として、入力データソース１９３４を分析して合致する入力プロファイルを参照し、データチェックを行なう。次に、第３の手順（ＳＴＥＰ３）として、入力データソース１９３４から変換できるデータソースを判断し、イベント１９３０のイベント名を決定し、決定したイベント１９３０のプロシージャ１９３２群の処理を実行する。また、このとき、変換及び交換できる出力データソース１９３５を判断し、変換及び交換できる出力データソース１９３５が複数ある場合は、並行処理を行なう。次に、第４の手順（ＳＴＥＰ４）として、図９７中の丸付数字３に示すように、入力プロファイル定義に従い、入力データソース９３４のデータを取り込み、入力用ワークスペース２１２０に読み込む。次に、第５の手順（ＳＴＥＰ５）として、図９７中の丸付数字４に示すように、チェインクラス１９４０を利用したチェイン（Ｃｈａｉｎ）処理の実行モジュール２２３０により、データ変換及び交換を実行し、出力用ワークスペース２２４０にデータを作成する。ここで、入出力データソース以外のデータ作成が発生する場合は、一時ワークスペース２２３にデータを格納する。次に、第６の手順（ＳＴＥＰ６）として、図９７中の丸付数字５に示すように、出力用ワークスペース２２４０のデータを出力プロファイル定義に従い、出力データソース１９３５として書き出す。これにより、入力データに応じた行管理テーブル（上記実施の形態の行管理テーブルに相当）２２４と項目値管理テーブル（上記実施の形態の項目値管理テーブルに相当）２２４並びに行管理テーブル２１２及び項目値管理テーブル２１２が作成される。次に、第７の手順（ＳＴＥＰ７）として、図９７中の丸付数字６に示すように、入力データソース１９３４の全レコード終了まで上記ＳＴＥＰ４〜ＳＴＥＰ６の処理（丸付数字３〜５の処理）を繰り返す。次に、第８の手順（ＳＴＥＰ８）として、図９７中の丸付数字７に示すように、変換及び交換処理の結果の格納処理、入出力ワークスペースのイニシャル処理等、プロシージャー実行後処理を実行して、最終的に、出力データ２００２を得る。
【０２０４】
実施の形態１４に係るＳＸＰサービスシステムは、詳細には、クラス定義として以下のクラスを有する。
Ｏｂｊｅｃｔ：ＥＤＩＹオブジェクトのインスタンスを管理するクラス
ＯｂｊｅｃｔＴｙｐｅ：オブジェクトのタイプ
Ｓｏｕｒｃｅ  Ｔｙｐｅ：データソースのタイプ
Ｄａｔａ  Ｔｙｐｅ：カラムのデータタイプ
Ｐｒｏｃｅｄｕｒｅ  Ｔｙｐｅ：プロシージャーのタイプ
Ｆｕｎｃｔｉｏｎ  Ｔｙｐｅ：ファンクションのタイプ
Ｏｂｊｅｃｔ  Ｌｉｓｔ：全てのオブジェクトを管理し、タグ名によるオブジェクトアクセスを可能にする
Ｐｒｏｆｉｌｅ：プロファイルを構成するクラス
Ｔａｂｌｅ：テーブル定義を構成するクラス
Ｃｏｌｕｍｎ：テーブルのカラム定義を構成するクラス
Ｃｏｍｐｌｅｘ  Ｃｏｌｕｍｎ：テーブルの複合カラム定義を構成するクラス
Ｉｎｄｅｘ：テーブルのインデックス、主キーの定義を構成するクラス
Ｔａｂｌｅ  Ｊｏｉｎ：テーブル間の連結情報定義構成するクラス
Ｅｖｅｎｔ：イベントの定義を構成するクラス
Ｐｒｏｃｅｄｕｒｅ：入出力・チェーン手抜きを構成するクラス
Ｃｈａｉｎ：テーブル間のデータチェーンを構成するクラス
Ｆｕｎｃｔｉｏｎ：データチェーンの１処理単位を構成するクラス
Ｄａｔａ  Ｓｏｕｒｃｅ：入出力データとの接続情報を定義するクラス
Ｗｏｒｋｓｐａｃｅ：プロシャージャー実行時の入力データの一時格納クラス
Ｒｏｗ：ＷｏｒｋｓｐａｃｅでのＴａｂｌｅの１レコードデータを保持するクラス
Ｃｅｌｌ：Ｒｏｗの１カラムのデータを保持するクラス
Ｓｙｓ：すべてのオブジェクトを保持するクラス
Ｅｎｇｉｎｅ：リソースを提供するための外部とのインターフェースを実現するクラス
【０２０５】
また、実施の形態１４に係るＳＸＰサービスシステムは、詳細には、以下の関数を提供する。
ＮＯＰ：ＮＯＰ
Ｌｅｔ：代入  Ａ＝Ｂ；
ＰＬｅｔ：パラメータ代入  Ａ＝Ｐ１；
Ｆｏｒｍａｔ：フォーマット  Ａ＝Ｆｏｒｍａｔ（Ｂ，Ｐ１）；  ＢをＰ１の形式に変換し、出力
Ａｄｄ：加算  Ａ＝Ｂ＋Ｐ１；
Ｓｕｂ：減算  Ａ＝Ｂ−Ｐ１；
Ｍｕｌ：乗算  Ａ＝Ｂ＊Ｐ１；
Ｄｉｖ：除算  Ａ＝Ｂ／Ｐ１
Ｉｎｓｅｒｔ：文字列挿入  Ａ＝Ｉｎｓｅｒｔ（Ｂ，Ｐ１，Ｐ２）；  ＢのＰ１の位置にＰ２を挿入
Ｃｏｎｃａｔ：文字列連結  Ａ＝Ｃｏｎｃａｔ（Ｂ，Ｐ１，Ｐ２・・）；  Ｂ，Ｐ１，Ｐ・・を連結
Ｒｅｍｏｖｅ：文字列削除  Ａ＝Ｒｅｍｏｖｅ（Ｂ，Ｐ１，Ｐ２）；ＢのＰ１の位置からＰ２の文字数を削除
Ｓｕｂｓｔｒｉｎｇ：部分文字列取得  Ａ＝Ｓｕｂｓｔｒｉｎｇ（Ｂ，Ｐ１，Ｐ２）；ＢのＰ１の位置からＰ２の文字数を取得
Ｓｕｍ：合計  Ａ＝Ｓｕｍ（Ｂ）；  Ｂの合計値
Ｍａｘ：最大  Ａ＝Ｍａｘ（Ｂ）；  Ｂの最大値
Ｍｉｎ：最小  Ａ＝Ｍｉｎ（Ｂ）；  Ｂの最小値
Ａｖｇ：平均  Ａ＝Ａｖｇ（Ｂ）；  Ｂの平均値
Ｃｏｕｎｔ：カウント  Ａ＝Ｃｏｕｎｔ（Ｂ）；  Ｂのデータのカウント数
Ｓｅｑｕｅｎｃｅ：シーケンス  Ａ＝Ｓｅｑｕｅｎｃｅ（Ｂ）；レコードの連番
Ｉｉｆ：条件式ＩＦ  Ａ＝Ｉｉｆ（Ｂ，Ｐ１，Ｐ２，Ｐ３，Ｐ４）；  ＢとＰ１との値をＰ２の条件式で比較し、真の場合はＰ３、偽の場合はＰ４を出力
Ｃａｓｅ：条件式ＣＡＳＥ  Ａ＝Ｃａｓｅ（Ｂ，Ｐ１）；  Ｐ１のデータ列（比較値、出力値）からＢと一致する  比較値の出力値を出力
ＩｓＮｕｌｌ：Ｎｕｌｌデータ判定  Ａ＝ＩｓＮｕｌｌ（Ｂ）；  Ｎｕｌｌデータの場合「真」を出力
ＩｓＮｕｍｅｒｉｃ：数値データ判定  Ａ＝ＩｓＮｕｍｅｒｉｃ（Ｂ）；  数値データの場合「真」を出力
ＩｓＤａｔｅ：日付データ判定  Ａ＝ＩｓＤａｔｅ（Ｂ）；  日付データの場合「真」を出力
Ｇｏｔｏ：条件分岐  Ａ＝Ｇｏｔｏ（Ｂ，Ｐ１，Ｐ２，Ｐ３）；  ＢとＰ１との値をＰ２の条件式で比較し、その結果を出力する。
Ｃａｌｌ：呼び出し  Ａ＝Ｃａｌｌ（Ｐ１）；  Ｐ１で指定されているチェーンを呼び出し、その結果を出力する。
Ｅｎｄ：終了処理  Ａ＝Ｅｎｄ（Ｂ，Ｐ１）；  Ｂを終了結果、Ｐ１を終了内容としてチェーンする。
Ｏｂｊｅｃｔ：ディフォルトオブジェクトを設定
【０２０６】
図９８は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるテーブル間の連結・対応関係の概要を示す説明図である。
実施の形態１４に係るＳＸＰサービスシステムは、前記連結カラム定義クラス１９２１の連結カラム定義テーブル及び連結種別定義クラス１９２２の連結種別定義テーブルとを利用して、複数のテーブル間の連結対応関係（連結構造や階層構造）について定義する。即ち、テーブルのリレーションを示す手法としてＥＲ図があるが、ＥＲ図などで表現されるテーブルの従属関係については、連結カラム定義（ＪｏｉｎＣｏｌｕｍｎ）クラス１９２１と連結種別（ＪｏｉｎＫｉｎｄ）クラス１９２２で対応する。具体的には、図９８に示すように、例えば受注処理において、テーブルＡ２２０１（インデックス：ＴｒａｎＩＤ）、テーブルＢ２２０２（インデックス：伝票Ｎｏ）、テーブルＣ２２０３（インデックス：明細行Ｎｏ及び商品コード）が階層構造（親子関係）にある場合、親子関係を表すテーブル（連結カラム定義テーブル）の一例は、図９８（ａ）に示すように、データ項目（列）として、「管理内容」、「従属テーブル（ＴＢＬ）」、「識別子」、「従属種類」を有している。また、最上位（ルート）テーブルであるテーブルＡ２２０１の行（レコード）には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「Ｒｏｏｔ」（従属ＴＢＬがないことを意味）を、「識別子」の項目値として「ＮＵＬＬ」（従属ＴＢＬがないため）を、「従属種類」の項目値として「０」を（従属ＴＢＬがないことを意味）、それぞれ、格納する。また、中位（ルートテーブルの子）テーブルであるテーブルＢ２２０２の行（レコード）には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「Ａ」（従属ＴＢＬがテーブルＡであることを意味）を、「識別子」の項目値として「ＴｒａｎＩＤ」（従属ＴＢＬの識別子）を、「従属種類」の項目値として「１」を（従属ＴＢＬが１つであることを意味）、それぞれ、格納する。更に、最下位（子テーブルＢの子）テーブルであるテーブルＣ２２０３の行（レコード）には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「Ｂ」（従属ＴＢＬがテーブルＢであることを意味）を、「識別子」の項目値として「伝票Ｎｏ」（従属ＴＢＬの識別子）を、「従属種類」の項目値として「１」を（従属ＴＢＬが１つであることを意味）、それぞれ、格納する。
【０２０７】
一方、例えば取引先単価マスタにおいて、テーブルａ２２１１（インデックス：商品ＩＤ）、テーブルｂ２２１２（インデックス：取引先ＩＤ）、テーブルｃ２２１３（インデックス：商品ＩＤ及び取引先ＩＤ）が連結構造にある場合、連結構造を表すテーブル（連結カラム定義テーブル）の一例は、図９８（ｂ）に示すように、データ項目（列）として、「管理内容」、「従属テーブル（ＴＢＬ）」、「識別子」、「従属種類」を有している。また、連結元テーブルの一方であるテーブルａ２２１１の行（レコード）には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「Ｒｏｏｔ」（従属ＴＢＬがないことを意味）を、「識別子」の項目値として「ＮＵＬＬ」（従属ＴＢＬがないため）を、「従属種類」の項目値として「０」を（従属ＴＢＬがないことを意味）、それぞれ、格納する。同様に、連結元テーブルの他方であるテーブルｂ２２１２の行（レコード）には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「Ｒｏｏｔ」（従属ＴＢＬがないことを意味）を、「識別子」の項目値として「ＮＵＬＬ」（従属ＴＢＬがないため）を、「従属種類」の項目値として「０」を（従属ＴＢＬがないことを意味）、それぞれ、格納する。一方、連結先テーブルであるテーブルｃ２２１３の行（レコード）は、２つの連結元テーブルに対応して２行用意され、上の行には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「ａ」（一方の従属ＴＢＬがテーブルａであることを意味）を、「識別子」の項目値として「商品ＩＤ」（一方の従属ＴＢＬの識別子）を、「従属種類」の項目値として「２」を（従属ＴＢＬの数が２つであることを意味）、それぞれ、格納する共に、下の行には、「管理内容」の項目値として「テーブル」を、「従属ＴＢＬ」の項目値として「ｂ」（他方の従属ＴＢＬがテーブルｂであることを意味）を、「識別子」の項目値として「取引先ＩＤ」（他方の従属ＴＢＬの識別子）を、「従属種類」の項目値として「２」を（従属ＴＢＬの数が２つであることを意味）、それぞれ、格納する。なお、図９６〜図９８の説明は、上記ＳＸＰ特徴１に対応するものである。
【０２０８】
図９９は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける連結カラム定義（ＪＯＩＮ＿ＣＯＬＵＭＮ）テーブルの一例を示す説明図である。図１００は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける連結種別定義（ＪＯＩＮ＿ＫＩＮＤ）テーブルの一例を示す説明図である。
図９９に示すように、連結カラム定義テーブルは、データ項目として、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」を有している。そして、例えば、上記テーブルＡ２２０１、テーブルＢ２２０２、テーブルＣ２２０３の親子関係を定義する場合、連結カラム定義テーブルは、その上半分に示すように３行を使用し、１行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「Ａ」（管理内容がテーブルＡであることを意味）、「ＴｒａｎＩＤ」、「Ｂ」（対応内容（子）がテーブルＢであることを意味）、「ＴｒａｎＩＤ」、「＞」を格納する。なお、「識別子」には、共に、親テーブルであるテーブルＡの識別子が格納される。また、２行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「Ｂ」（管理内容がテーブルＢであることを意味）、「ＴｒａｎＩＤ」、「Ｃ」（対応内容（子）がテーブルＣであることを意味）、「ＴｒａｎＩＤ」、「＞」を格納する。なお、「識別子」には、共に、親テーブルであるテーブルＡの識別子が格納される。更に、３行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「Ｂ」（管理内容がテーブルＢであることを意味）、「伝票Ｎｏ」、「Ｃ」（対応内容（子）がテーブルＣであることを意味）、「伝票Ｎｏ」、「＞」を格納する。なお、「識別子」には、共に、親テーブルＡの子であり、かつ、子テーブルＣの親であるテーブルＢの識別子が格納される。一方、例えば、上記テーブルａ２２１１、テーブルｂ２２１２、テーブルｃ２２１３の連結構造を定義する場合、連結カラム定義テーブルは、その下半分に示すように３行を使用し、１行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「ａ」（管理内容がテーブルａであることを意味）、「商品ＩＤ」、「ｃ」（対応内容（連結先）がテーブルｃであることを意味）、「商品ＩＤ」、「＞」を格納する。なお、「識別子」には、共に、一方の連結元テーブルであるテーブルａの識別子が格納される。また、２行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「ｂ」（管理内容がテーブルｂであることを意味）、「取引先ＩＤ」、「ｃ」（対応内容（連結先）がテーブルｃであることを意味）、「取引先ＩＤ」、「＞」を格納する。なお、「識別子」には、共に、他方の連結元テーブルであるテーブルｂの識別子が格納される。更に、３行目には、「管理内容」、「識別子」、「対応内容」、「識別子」、「従属関係（連結種別定義）」の項目値として、それぞれ、「ａ」（管理内容がテーブルａであることを意味）、「商品ＩＤ」、「ｂ」（対応内容（同一階層の連結元）がテーブルｂであることを意味）、「取引先ＩＤ」、「＞」を格納する。なお、「識別子」には、一方の連結元テーブルであるテーブルａ及び他方の連結元テーブルであるテーブルｂの識別子がそれぞれ格納される。
【０２０９】
図１０１は本発明の実施の形態１４に係るデータ管理システムにおけるイベント定義（ＥＶＥＮＴ）テーブルの一例を示す説明図である。図１０２は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおけるプロシージャ定義（ＰＲＯＣＥＤＵＲＥ）テーブルの一例を示す説明図である。図１０３は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルの一例を示す説明図である。
図１０１に示すように、イベントテーブルは、データ項目として、「イベント名（ｅｖｅｎｔ＿ｎａｍｅ）」、「プロシージャ番号（ｐ＿ｓｅｑ）」、「プロシージャ名（ｐｒｏｃｅｄｕｒｅ＿ｎａｍｅ）」、「条件コード（ｃｏｎｄｉｔｉｏｎ＿ｃｏｄｅ）」を有し、使用する各イベントについて対応する項目値を格納する。例えば、イベントａについて３つのプロシージャ（ｐ−１，ｐ−２，ｐ−３）が実行される場合、図１０１のような内容で項目値を格納する。また、図１０２に示すように、プロシージャ定義テーブルは、データ項目として、「プロシージャ名（ｐｒｏｃｅｄｕｒｅ）」、「入力データ（ｉｎｐｕｔ＿ｄａｔａ）」、「出力データ（ｏｕｔｐｕｔ＿ｄａｔａ）」、「前処理（ｂｅｆｏｒｅ＿ｐｒｏｃｅｄｕｒｅ）」、「後処理（ａｆｔｅｒ＿ｐｒｏｃｅｄｕｒｅ）」、「チェイン（ｃｈａｉｎ）」を有し、各プロシージャについて対応する項目値を格納する。例えば、プロシージャｐ−１〜ｐ−７については、図１０３のような内容で項目値を格納する。更に、図１０３に示すように、項目関連定義テーブルは、「アドレス（項目関連定義レコードのＩＤ）」、「対象カラム（上記実施の形態１〜１０の対象列ＩＤに相当）」、「主カラム（上記実施の形態１〜１０のトリガ列ＩＤに相当）」、「関数」、「パラメータ１」、「パラメータ２」・・・等を有し、各アドレスの項目関連定義データについて、対応する項目値を格納する。即ち、実施の形態１４のＳＸＰサービスシステムで利用する項目関連定義テーブルは、項目関連定義データのアドレスごとに、上記実施の形態１〜１０の処理と同様にして、主カラムＩＤと対象カラムＩＤとの間でのデータ交換を実行することができる。これにより、上記各イベント発生時に、必要となるアドレスの項目関連定義データのみを解析し、必要な項目関連定義データのみを利用して主カラムＩＤと対象カラムＩＤとの間でのデータ交換を実行することができる。
【０２１０】
図１０４は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムを利用したＸＭＬ各種データの自動生成の概念を示す説明図である。
図１０４（ａ）に示すように、実施の形態１４に係るＳＸＰサービスシステムを利用すると、各システムや各パッケージソフトのプロファイルの項目定義及び項目関連定義の定義情報を格納するＳＸＰ（システムエクスチェンジプロファイル）２３０１を参照して、テキストファイルのようなや非構造化データ（意味不明なデータ）２３００やＣＳＶファイル等の入力データを項目定義及び項目関連定義等を利用して分割及び分析し、各属性のタグ名と属性値を生成してＸＭＬデータ（データ項目及び項目値）２３１０を自動生成したり、ＸＭＬデータのスキーマ定義であるＸＳＤ２３１１を自動生成したり、ＸＭＬデータの表示態様を定義するスタイルシート定義としてのＸＳＬ２３１２を自動生成したりすることが可能となる。例えば、図１０４（ｂ）の表２３２０に示すように、ＳＸＰの各クラスを利用して、対応するＸＭＬデータを分析して出力することができ、また、データ関連の行管理テーブルや項目値管理テーブルを利用して、対応するＸＭＬデータを分析して出力することができる。なお、図１０４の説明は、上記ＳＸＰ特徴６に対応するものである。
【０２１１】
図１０５は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ一元管理の第１の事例を示す説明図である。
実施の形態１４に係るＳＸＰサービスシステムは、各種態様でデータ一元管理に利用することができる。例えば、図１０５に示すように、ユーザーが対象とするシステムを選択すると（データ整合性チェックのための選択支援はシステムとする）、ＳＸＰサービスシステムが、各システムに格納されているデータを統合して表示し、データ不整合の疑いがある箇所には警告を発する。例えば、Ａパッケージ、Ｂパッケージ、Ｃパッケージの各データ（商品管理データ等）を格納・管理する場合において、利用者が特定の商品コード（４９ＸＸＸＸＸＸ００１等）を入力すると、ＳＸＰサービスシステムは、当該商品コードに対応するＡパッケージ、Ｂパッケージ、Ｃパッケージの商品管理データをそれぞれ抽出し、対照表形式で一覧表示する。同対照表の最上欄左側には、当該抽出に利用した商品コードが表示され、最上欄右側には表示方法が表示される。また、各パッケージのデータ項目に対応して、左側には、標準プロファイルのデータ項目が表示される。各パッケージの項目値は、データ項目に対応して表示される。そして、ＳＸＰシステムは、表示した各パッケージの対応するデータ項目の項目値に相違がある場合、相違するデータ項目の欄を赤色点灯・点滅等で警告表示する。例えば、図１０５の例では、Ａパッケージの単価（１９，８００）とＢパッケージの上代（２０，０００）とは同一値である必要があるが、入力ミス等によりそれらの値が異なるため、ＳＸＰシステムは、標準小売単価の欄を警告表示する。なお、これ以外にも、利用者は、対照表を見ることにより、各パッケージのデータについて容易に対照確認することができる。なお、図１０５の説明は、上記ＳＸＰ特徴５に対応するものである。
【０２１２】
図１０６は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ一元管理の第２の事例を示す説明図である。
第２の事例のデータ一元管理の態様として、実施の形態１４に係るＳＸＰサービスシステムは、ユーザーが分析対象とする各システムの項目を選択する（分析のための選択支援はシステムとする）と、各システムに格納されているデータを統合して表示し、グラフ表示などを利用して分析情報を画面に表示する。例えば、Ａパッケージ、Ｂパッケージ、Ｃパッケージの各データ（商品管理データ等）を格納・管理する場合において、利用者が特定の商品コード（４９ＸＸＸＸＸＸ００１等）を入力すると、ＳＸＰサービスシステムは、当該商品コードに対応するＡパッケージ、Ｂパッケージ、Ｃパッケージの商品管理データのうちから所望のデータ項目の項目値をそれぞれ抽出し、対照表形式で一覧表示する。同対照表の最上欄左側には、当該抽出に利用した商品コードが表示され、最上欄右側には表示方法が表示される。また、左側には、各パッケージの表示データ項目（受注数量、納品数量、返品数量等）が表示され、各表示データ項目に対応して、その項目値が月別等の所定の態様で表示される。これにより、利用者は、この分析表を見ることにより、各パッケージのデータについて容易に分析結果を確認することができる。なお、図１０６の説明は、上記ＳＸＰ特徴５に対応するものである。
【０２１３】
図１０７は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ変換の一例を概略的に示す説明図である。図１０８は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ整合性を考慮したデータ変換の一例を概略的に示す説明図である。
図１０７に示すように、ＳＸＰサービスシステムによる通常のデータ変換の場合、ＳＸＰサービスシステム２３５０は、前記列管理テーブルから変換前データ及び変換後データのシステムプロファイル（図８５の独自データプロファイルに相当）をそれぞれ判断すると共に、前記項目関連定義テーブルにおける当該システムプロファイルに対応する変換定義（図８５の変換定義に相当）を利用して、当該変換前データを変換後データへとデータ変換する。このとき、ＳＸＰサービスシステムは、前記列管理テーブル等を利用して、変換データに階層構造や連結構造等の所定のデータ構造があるか否か判断し、所定のデータ構造がある場合、そのデータ構造の内容に応じて変換データを別個に格納する。例えば、受発注業務で使用する伝票データ２３６０は、図１０７に示すように、ヘッダ情報としての伝票ヘッダデータ２３６１、本体情報としての（通常は複数行の）伝票明細データ２３６２及びフッタ情報としての伝票フッタデータ２３６３からなるデータ構造を有している。よって、ＳＸＰサービスシステム２３５０は、あるデータフォーマットの伝票データ２３６０を、他のデータフォーマットの伝票データに変換すると共に、伝票データ２３６０の伝票ヘッダデータ２３６１、伝票明細データ２３６２及び伝票フッタデータ２３６３を、それぞれ、別個の伝票ヘッダデータ２３７１、伝票明細データ２３７２及び伝票フッタデータ２３７３として格納する。なお、伝票フッタデータを伝票ヘッダデータにまとめて格納する場合もある。
【０２１４】
一方、図１０８に示すように、ＳＸＰサービスシステム２３５０は、図１０７に示すような変換前データから変換後データへの通常のデータ変換を実行することに加え、同変換前データから、特定のデータ項目のデータ項目値を抽出して、変換データとは別個の有用なデータを加工することができる。具体的には、図１０８に示すように、ＳＸＰサービスシステム２３５０は、変換前データフォーマットによる伝票データ２３６０（伝票ヘッダデータ２３６１、伝票明細データ２３６２、伝票フッタデータ２３６３）を、変換後データフォーマットによる伝票データ（伝票ヘッダデータ２３７１、伝票明細データ２３７２、伝票フッタデータ２３７３）へと変換することに加え、伝票データ２３６０の伝票ヘッダデータ２３６１の取引先情報部分(発注企業コード、発注企業名称）を別個に抽出して、変換後データフォーマットによる取引先マスタデータ２３８１を作成する。同様に、ＳＸＰサービスシステム２３５０は、通常のデータ変換と共に、伝票データ２３６０の各行の伝票明細データ２３６２の商品情報部分（商品コード、商品名、単価）を別個に抽出して、変換後データフォーマットによる商品マスタデータ２３８２を作成する。これ以外にも、ＳＸＰサービスシステム２３５０は、例えば、伝票データ２３６０の伝票ヘッダデータ２３６１から取引先情報を抽出すると共に、伝票フッタデータ２３６３から売上情報（金額情報）を抽出して所定期間ごとに集計することで、所定の取引先の毎週・毎月・毎年の取引高を示す取引高テーブルを作成することもできる。このように、ＳＸＰサービスシステム２３５０は、変換前データ（エクスポートデータ）から通常の変換後データ（インポートデータ）を取得できることに加え、他の形式のデータも取得して所望のテーブルを下降することができる。これにより、データのインポート側では、通常の変換データである伝票データに加え、取引先マスタデータ２３８１や商品マスタデータ２３８２等の他のインポート情報も出力することが可能となる。
【０２１５】
また、ＳＸＰサービスシステム２３５０の上記機能によれば、データの整合性を保持したデータ交換を行うことが容易となる。即ち、本ＳＸＰサービスシステム２３５０は、上記のように、変換対象のデータをレコード毎に読み込むと共に各レコードの行ＩＤ情報（各レコードを特定するためのデータ）を行管理テーブルに格納し、一方、列管理テーブルの項目定義（列ＩＤ等）にしたがって、読み込んだデータの各レコードをデータ項目（フィールド）ごとに分割して値管理テーブルに格納している。なお、この際、項目関連定義テーブルを使用して、標準プロファイルを介したデータ変換が実行される。そして、変換後のデータについては、必要に応じて、行管理テーブルの行ＩＤと列管理テーブルの列ＩＤとを参照して、値管理テーブルからデータ項目値を取得し、所望の形式（ビュー）のデータを出力（表示、印刷等）することができる。このように、ＳＸＰサービスシステム２３５９によれば、上述したように、基本的に、任意のデータフォーマットのデータについて、列管理テーブルの対応するデータプロファイル（システムプロファイル）及び項目関連定義テーブルの対応する変換定義を使用して、別の任意のデータフォーマットのデータへと変換することができ、非常にシンプルな構成でのデータ変換が可能となる。これに加え、本ＳＸＰサービスシステムによれば、行管理テーブル及び値管理テーブルという非常に独特でシンプルな２つのテーブルを使用して、データ変換後のデータを（レコード特定用の情報と値関連情報とに区別して）全て格納して保存することができる。即ち、ＳＸＰサービスシステムによれば、基本的に、列管理テーブル、項目関連定義テーブル、行管理テーブル及び値管理テーブルからなる非常にシンプルなテーブル構成を使用して、任意のデータのデータ変換、格納、取得、加工、出力等を実現することができる。
【０２１６】
ここで、ＳＸＰサービスシステム２３５０は、上記のようにデータ変換した全てのデータ（レコード）のデータ項目値を値管理テーブルに（データ項目値ごとに分割して）格納している。したがって、値管理テーブルに格納したデータを利用して、新たに読み込んだデータが以前の読み込みデータ（格納データ）と整合するか否かの判断を行うことができ、データの整合性を維持しながらデータ変換及びデータインポートを実現することができる。例えば、格納データ中の特定の伝票データの特定の商品ＩＤ（例えば、「００１」）の商品名が「ぱりぱりせんべい」であり、単価が「１００円」であるときに、新たに読み込んだ伝票データの当該商品ＩＤ（００１）の商品名が「ばりばりせんべい」であったり、単価が「１１０円」であったりした場合（格納データと相違する場合）、ＳＸＰサービスシステム２３５０は、格納伝票データとの整合性チェックによりかかる不整合を認識し、エラー表示や警告表示等をユーザーに対して行うことができる。そして、不整合データを逐一確認したり修正したりしてデータ変換を行うことにより、完全に整合性を確保したデータ格納が可能となる。これにより、ＳＸＰサービスシステム２３５０は、特に、中小企業等のように、システムに十分な人材及び費用を投資することが困難であったり、システムの取扱いに不慣れであるユーザーにとっては、常にデータの整合性を確保したデータ変換及びデータ格納が可能となり、非常に活用度の高いシステムとなる。また、ＳＸＰサービスシステム２３５０は、上記のように、本来のデータ（例えば、伝票データ）のデータ変換と共に、取引先マスタデータや商品マスタデータ等の他の任意のデータ（マスタ系データやトランザクション系データ）作成することができるため、やはり、十分なシステム環境を整えることが困難な中小企業等に対しても、自動的に全てのマスタデータやトランザクションデータを自動生成して対応するテーブルに格納することができ、いわゆる、ＳＡＡＳとして非常に好適なシステムとなる。
【０２１７】
換言すれば、本ＳＸＰサービスシステム２３５０は、あらゆる会社やあらゆるシステムの全てのマスタデータやトランザクションデータを、同一フォーマットからなる行管理テーブル及び値管理テーブルという２つのシンプルなテーブルに格納して管理することができ、必要に応じて、列管理テーブル及び項目関連定義テーブルを使用して任意のデータフォーマットのデータとして出力し、任意の形式のビューを提供することができる。
【０２１８】
上記のように、図１０８で説明したＳＸＰサービスシステムは、前記変換元の対象データ（伝票データ２３６０）から前記変換先の対象データ（伝票データ２３７１〜２３７３）へのデータ変換時に、前記変換元の対象データ（伝票データ２３６０）からマスタデータ（取引先マスタデータ２３８１、商品マスタデータ２３８２等）を構成する一部のデータ項目値（伝票ヘッダデータ２３６１の発注企業コード等、及び、伝票明細データ２３６２の商品コード等）を別個に抽出し、当該抽出したデータ項目値を所定のデータフォーマット（取引先マスターデータや商品マスターデータのデータフォーマット）にしたがって変換してマスタデータ（取引先マスタデータ２３８１、商品マスタデータ２３８２等）を作成及び格納し、その後の前記変換元の対象データから前記変換先の対象データへのデータ変換時に、前記格納済みのマスタデータ（取引先マスタデータ２３８１、商品マスタデータ２３８２等）と、その後のデータ変換時に新たに作成したマスタデータ（新たに読み込んだ取引先マスタデータや商品マスタデータ等）とを比較して、それらの間の整合性を判断する。
【０２１９】
図１０９は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで利用されるバーコードや電子タグ等のフォーマット共有化の概念を示す説明図である。図１１０は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるバーコードや電子タグ等のデータ識別フォーマット（共有化フォーマット）を活用したアプリケーションの概念を示す説明図である。
商取引の流通の中で、商品或いは荷札等に貼り付けられたバーコードや電子タグの利用シーンが益々盛んに提案されてきている。しかし、バーコードのフォーマットは発注企業の指定があったり、運送業者独自であったりして様々である。一方、バーコードのフォーマットのヘッダ部（例えば図１０９の帯状コードで示すようなもの）を共用することで、そのバーコードが付されたデータが、どの企業のどのフォーマットであるかを判別することができる。こうすれば、それ以降の詳細情報は、本実施の形態のＳＸＰのデータ変換及び交換技術を利用して判別することが可能となる。なお、ヘッダ以降の詳細情報（ボディ部分の情報）は、業界や取扱商品ごとの情報である為、データ全てのフォーマットを共用するのは困難である。そこで、図１０９に示すように、実施の形態１４のＳＸＰサービスシステムは、商品・梱包２４００に付されたバーコード２４０１や商品・梱包２４１０に付された電子タグ２４１１のデータフォーマットのうち、ヘッダ部分のフォーマットのみを共通化（共有化）する。例えば、バーコードや電子タグ等のデータヘッダ（ファイルヘッダ）の共通フォーマットとして、企業コード６桁＋テーブル識別子４桁＋バージョンＩＤ２桁＋取引先コード６桁＋セキュリティ識別子１６桁とする。すると、図１１０に示すように、この共通フォーマットをデータ識別フォーマットとして有効活用するアプリケーションの実施が可能となる。例えば、バーコード用のアプリケーション２５００は、読み込んだバーコードのヘッダ情報の内容から、梱包明細情報の格納エリアであるウエブページのＵＲＬを判断し、そのＷｅｂサイトのウエブページから梱包明細情報をダウンロード後、その梱包明細内容を画面に表示する。一方、電子タグ用のアプリケーション２５１０は、予め取引先のＳＸＰを参照して、Ｗｅｂサイト（ＳＸＰサービスプロバイダ）から梱包明細情報を自らのローカルＰＣにダウンロードして格納しておく。そして、読み込んだ電子タグのヘッダの内容から使用するＳＸＰを判断し、ローカルＰＣ上のアプリケーションで電子タグの詳細情報である梱包明細を画面に表示する。いずれのアプリケーション２５００，２５１０の場合も、画面に表示された内容をチェックあるいは編集すると、ＳＸＰを参照して、その結果がユーザが予め指定したフォーマットでローカルＰＣ上の指定フォルダに出力される。必要であれば、ローカルプリンタに作業ログファイルや受領書がプリンタから出力されたり、受領データを納品企業に直ぐに返信することも可能である。なお、図１０９及び図１１０の説明は、上記ＳＸＰ特徴１０に対応するものである。
【０２２０】
図１１１は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおけるデータアップロードによる自動変換処理の概念を示す説明図である。
実施の形態１４に係るＳＸＰサービスシステムによるデータアップロードによる自動変換処理では、図１１１に示すように、まず、データ発信企業２６００が、データ変換方法を指定あるいは予め定めてあるインターネット上の変換前データ送信先フォルダ２６２０に、端末ＩＤ、ログインＩＤ、パスワード等の認証情報２６５０を入力してログインし、データ送信先を指定あるいは予め定めて変換前データ２６０１を送信すると、ＳＸＰエンジン２６３０が、その変換前データ２６０１を変換・交換（暗号化／複合化も含む）し、その結果としての出力データ（変換後データ）を、インターネット上に定められた変換後データ受信先フォルダ２６４０に出力して生成し、変換前データ送信先フォルダ２６２０から変換前データ２６０１を削除する。これにより、実施の形態１４に係るＳＸＰサービスシステムは、取引のある企業間で定めたデータ送受信インフラとして利用できる。即ち、データ発信企業２６００が発注者で、データ受信企業２６１０が受注者の場合、データ発信企業２６００が発注データを変換前データ送信先２６２０に送信すると、ＳＸＰエンジン２６３０が発注データを変換して変換後データ受信先フォルダ２６４０に送信・格納すると共に、変換前データ送信先２６２０の発注データは削除する。これにより、受注者であるデータ受信企業２６１０は、変換後データ受信先フォルダ２６４０に、端末ＩＤ、ログインＩＤ、パスワード等の認証情報２６５０を入力してログインし、変換後データ（変換後の発注データ）２６１１を取得して受注処理を行うことができる。また、発注者であるデータ発信企業２６００も、変換後データ受信先フォルダ２６４０に、端末ＩＤ、ログインＩＤ、パスワード等の認証情報２６５０を入力してログインし、変換後データ（変換後の発注データ）２６１１を取得することができる。なお、便宜上、データ発信企業の認証情報２６５０とデータ受信企業の認証情報２６５０を同一番号２６５０で表示しているが、通常は、ユーザごとに一意の認証情報が割り当てられる。
【０２２１】
図１１２は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける共用ヘッダ情報読み取りによる自動変換処理の概念を示す説明図である。
実施の形態１４に係るデータ管理システムとしてのＳＸＰサービスシステム２３５０における共用ヘッダ情報読み取りによる自動変換処理では、図１０９及び図１１０に基づいて説明した共用化フォーマットと同様の概念で、バーコードやＲＦＩＤのヘッダ情報を共用化（共通化）し、その共用化データに基づいて自動変換処理を行う。具体的には、図１１２に示すように、まず、商品・梱包２４００に付されたバーコード２４０１を読み込むと、ＳＸＰサービスシステム２３５０は、読み込んだバーコード情報のうち、共用化情報としてのヘッダ情報を抽出し、当該ヘッダ情報に基づいて、読み込んだバーコード情報の本体部のデータ（伝票データ、梱包データ等）が、どの会社（送信元）からどの会社（送信先）へ送信したどの種類のデータ（変換前の送信元独自データ）であるかを判断し、この判断に基づき、バーコード２４０１に紐付けした前記本体部のデータの格納先と、当該本体部のデータのシステムプロファイルとを判断する。このとき、ＳＸＰサービスシステム２３５０は、共用化フォーマット用の共用システムを利用して、モニター画面２７５０のヘッダ情報表示領域２７５１に、読み込んだバーコード２４０１のヘッダ情報を確認可能な形式で（バーコード情報のままではなく、読み込みデータの種類、送信元、送信先等へと文字列変換して）表示する。こうすれば、ユーザーが、読み込んだバーコード情報のヘッダ情報（共用情報）を確認して、その後の作業の便宜に供することができる。次に、ＳＸＰサービスシステム２３５０は、前記判断に基づいて、前記本体部のデータを送信元独自処理前データ２７１１として所定の格納先２７１０に格納すると共に、格納した送信元独自処理前データ２７１１を、選択した固有のシステムプロファイルである変換定義２７２１（項目関連定義テーブルにおける送信元独自処理前データ２７１１用の変換定義）にしたがって、ＳＸＰ標準プロファイル１２５０へと変換する。このとき、ＳＸＰサービスシステム２３５０は、共用化フォーマット用の共用システムを利用して、モニタ画面２２７５０の本体部データ表示領域２７５２に、変換した標準データフォーマットの本体部のデータを確認可能な形式で（バーコード情報のままではなく、読み込みデータの内容を文字列変換して）表示する。こうすれば、ユーザーが、読み込んだバーコード情報の本体部データの内容を確認して、その後の作業の便宜に供することができる。なお、前記ヘッダ情報は、前記ヘッダ情報の読み取り直後のタイミングではなく、この本体部データの表示と同時に表示してもよい。更に、ＳＸＰシステムは、前記判断に基づき、変換後の標準フォーマットデータ（送信元データ）を、選択した固有のシステムプロファイルである変換定義２７２２（項目関連定義テーブルにおける返信先処理後データ２７１２用の変換定義）にしたがって、返信先処理後データ２７１２へと変換して前記格納先２７１０に格納する。なお、商品・梱包２４１０に付された電子タグ２４１１を使用する場合も、同様の処理とすることができる。
【０２２２】
なお、上記共用ヘッダ情報を利用した自動変換処理は、上記のような処理以外にも、共用ヘッダ情報について任意のアプリケーションを関連付けて（必要な場合は同時に転送し）、共用ヘッダ情報の読み取り等による入力により、当該アプリケーションを自動で起動して、当該アプリケーションの機能に応じた動作を自動実行するような処理とすることも可能である。こうすれば、共通のシステムやソフトウエアを所有していない中小企業等のユーザーが、（自らが所有していない）同一のアプリケーションを使用して、共用ヘッダ情報に基づく処理を自動実行することができ、同一の作業を容易に行うことができる。例えば、上記共用ヘッダ情報を利用した自動変換処理は、共用ヘッダ情報の入力と同時に検品用のアプリケーションを起動して、所定の検品処理を実行する機能を実行する処理とすることも可能である。こうすれば、本ＳＸＰサービスシステムにより、検品ソフトを所有していないユーザー間であっても、同一の処理による検品結果を相互に自動的に送信してデータ変換することができ、作業効率を飛躍的に向上することができる。
【０２２３】
上記のように、図１１２で説明したＳＸＰサービスシステムは、前記対象データの各々に対して、当該対象データの送信元を一意に示す送信元情報と、当該送信元の対象データに対応する前記システムプロファイルを一意に示す送信元システムプロファイル特定情報と、当該送信元の対象データに対応する前記項目関連定義情報を一意に示す送信元項目関連定義特定情報と、当該対象データの送信先を一意に示す送信先情報と、当該送信先の対象データに対応する前記システムプロファイルを一意に示す送信先システムプロファイル特定情報と、当該送信先の対象データに対応する前記項目関連定義情報を一意に示す送信先項目関連定義特定情報とを有する共通フォーマットの共用情報からなるヘッダ情報（バーコード２４０１のヘッダ情報）を付加する。そして、本ＳＸＰサービスシステムは、変換元の対象データの送信時に、以下の処理を実行する。即ち、本ＳＸＰサービスシステムは、まず、当該変換元の対象データ２７１１の前記ヘッダ情報の送信元情報に基づいて、当該変換元の対象データ２７１１の格納先２７１０を判断し、その判断に基づいて選択した格納先２７１０に当該変換元の対象データ２７１１を格納し、次に、当該変換元の対象データ２７１１の前記ヘッダ情報の送信元システムプロファイル特定情報及び送信元項目関連定義特定情報に基づいて、当該変換元の対象データ２７１１に対応する前記システムプロファイル（図１１２では図示は省略するが、例えば、図８５の独自データプロファイル１２５２に対応）及び項目関連定義情報（変換定義２７２１）を判断し、その判断に基づいて選択した前記システムプロファイル及び前記項目定義情報を使用して、前記格納先２７１０に格納した前記変換元の対象データ２７１１を前記ＳＸＰ標準プロファイル１２５０の標準データフォーマットにしたがった標準データへと変換し、次に、当該変換元の対象データ２７１１の前記ヘッダ情報の送信先システムプロファイル特定情報及び送信先項目関連定義特定情報に基づいて、当該変換先の対象データ２７１２に対応する前記システムプロファイル及び項目関連定義情報を判断し、その判断に基づいて選択した前記システムプロファイル（図１１２では図示は省略するが、例えば、図８５の独自データプロファイル１２６２に対応）及び前記項目定義情報（変換定義２７２２）を使用して、前記標準データを前記送信先の対象データ２７１２のデータフォーマットにしたがった送信先データ２７１２へと変換し、次に、当該変換元の対象データ２７１１の前記ヘッダ情報の送信先情報に基づいて、前記送信先データ２７１２の格納場所２７１０を判断し、その判断に基づいて選択した格納先２７１０に当該送信先データ２７１２を格納する。
【０２２４】
図１１３は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける共用ヘッダ情報読み取りによる自動変換処理の概念を示す説明図である。
上記のように、本ＳＸＰサービスシステムは、あらゆるシステム間のデータ交換に対応でき、また、交換されるデータをメッセージとして取扱い、メッセージを受け取る事で起動するいわゆるメッセージドリブン型のシステムとすることができる。この場合、交換されるデータは、例えば、図１１３に示すように、メッセージ番号（Ｍｅｓｓａｇｅ＿Ｎｏ）、送信元企業（Ｓｅｎｄ＿Ｃｕｓｔｏｍｅｒ＿ＩＤ）、送信先企業（Ｒｅｃｅｉｖｅ＿Ｃｕｓｔｏｍｅｒ＿ＩＤ）、メッセージ種類（Ｍｅｓｓａｇｅ＿ＩＤ）からなるヘッダ情報と、データホン大部としての内容情報とから構成される。このうち、メッセージ種類は、システムＸＭＬタグ名称（Ｓｙｓｔｅｍ＿ＸＭＬ＿Ｔａｇ）及びテーブルＸＭＬタグ名称（Ｔａｂｌｅ＿ＸＭＬ＿Ｔａｇ）から構成することができる。なお、システムＸＭＬタグ名称は、システムの種類を一意に示し、テーブルＸＭＬタグ名称は、システム内のテーブルを一意に示す。このように、本ＳＸＰサービスシステム２３５０は、メッセージ種類をシステムＸＭＬタグ名称及びテーブルＸＭＬタグ名称という２項目でユニークに定義することで、あらゆるメッセージを管理することができる。
【図面の簡単な説明】
【０２２５】
【図１】図１は本発明の実施の形態１に係るデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。
【図２】図２は本発明の実施の形態１に係るデータ管理システムのデータ構造を概略的に示す説明図である。
【図３】図３は本発明の実施の形態１に係るデータ管理システムを売上管理システムに具体化した場合のデータ構造を概略的に示す説明図である。
【図４】図４は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての商品マスタテーブルを示す説明図である。
【図５】図５は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての顧客マスタテーブルを示す説明図である。
【図６】図６は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての顧客単価マスタテーブルを示す説明図である。
【図７】図７は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての在庫マスタテーブルを示す説明図である。
【図８】図８は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての販売マスタテーブルを示す説明図である。
【図９】図９は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における列管理テーブルを示す説明図である。
【図１０】図１０は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における行管理テーブルを示す説明図である。
【図１１】図１１は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における値管理テーブルの第１の具体例を示す説明図である。
【図１２】図１２は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における値管理テーブルの第２の具体例を示す説明図である。
【図１３】図１３は本発明の実施の形態２に係るデータ管理システムとしての受発注管理システムの構成を概略的に示すブロック図である。
【図１４】図１４は本発明の実施の形態２に係るデータ管理システムを受発注管理システムに具体化した場合のデータ構造を概略的に示す説明図である。
【図１５】図１５は本発明の実施の形態２に係るデータ管理システムでデータ交換される発注データのデータ構造を示す説明図である。
【図１６】図１６は本発明の実施の形態２に係るデータ管理システムで使用する列管理テーブルの概略を示す説明図である。
【図１７】図１７は本発明の実施の形態２に係るデータ管理システムにより、発注データのレコードと、列管理テーブルに定義した当該発注データの各データ項目の属性との対応関係を示す説明図である。
【図１８】図１８は本発明の実施の形態２に係るデータ管理システムに外部から発注データを取り込んで、当該発注データを発注企業指定データ格納領域に格納すると共に、その伝票レコード及び伝票明細レコードをそれぞれ伝票格納及び伝票明細格納領域に格納する伝票基礎レコード・伝票項目値格納手順におけるデータフローを示すブロック図である。
【図１９】図１９は本発明の実施の形態２に係るデータ管理システムにより発注企業データプロファイルと受注企業データプロファイルとを標準データプロファイルを介してデータ交換する場合の手順を概略的に示す説明図である。
【図２０】図２０は本発明の実施の形態２に係るデータ管理システムにより、発注企業データの所定の項目値を表す発注企業データプロファイルの所定の列ＩＤから、当該発注企業データの項目値に対応する標準データの項目値を表す標準データプロファイルの所定の列ＩＤを介して、当該標準データの項目値に対応する受注企業データの項目値を表す受注データプロファイルの所定の列ＩＤを取得する手順を概略的に示す説明図である
【図２１】図２１は本発明の実施の形態２に係るデータ管理システムによりデータ交換を行う際に、各企業間で項目値の意味や使用方法が異なる場合の処理に使用する項目値管理テーブルの概略を示す説明図である。
【図２２】図２２は本発明の実施の形態２に係るデータ管理システムに新規な発注企業データプロファイル及び当該発注企業プロファイルと標準データプロファイルとのリンク情報を取り込んで、当該新規な発注企業データプロファイルに基づきデータを表示及び出力する場合のプロファイル取り込み・表示・出力手順におけるデータフローを示すブロック図である。
【図２３】図２３は本発明の実施の形態２に係るデータ管理システムにより各種データを出力するデータ出力手順におけるデータフローを示すブロック図である。
【図２４】図２４は本発明の実施の形態３に係るデータ管理システムの構成をプロファイル管理システムと共に概略的に示すブロック図である。
【図２５】図２５は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータを取引過程にしたがって示すデータフロー図である。
【図２６】図２６は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータの一覧及び構成を示す表である。
【図２７】図２７は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用する標準データのデータ構造を示すデータ構造図である。
【図２８】図２８は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムのデータ構造を示すテーブル関連図である。
【図２９】図２９は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル一覧を示す表である。
【図３０】図３０は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムにより、発注データと出荷データとの間で相違が発生した場合のマッチング処理を概略的に示す説明図である。
【図３１】図３１は本発明の実施の形態５に係るデータ管理システムを適用して電子商取引データ交換を実現するネットワークシステムの全体構成を示す説明図である。
【図３２】図３２は一般的なテーブル構造と本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルとの関係を示すブロック図である。
【図３３】図３３は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルの概念を示す説明図である。
【図３４】図３４は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルにおけるレコード階層構造の処理について説明するブロック図である。
【図３５】図３５は本発明の実施の形態５に係るデータ管理システムを流通企業向け物流支援システムに適用した場合の業務の流れを示すフロー図である。
【図３６】図３６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する企業管理（ＣＵＳＴＯＭＥＲ）テーブルを示す説明図である。
【図３７】図３７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ交換管理（ＥＸＣＨＡＮＧＥ）テーブルを示す説明図である。
【図３８】図３８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルを示す説明図である。
【図３９】図３９は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル管理（ＴＡＢＬＥ）テーブルを示す説明図である。
【図４０】図４０は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの標準データプロファイル部分を示す説明図である。
【図４１】図４１は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの発注企業データプロファイル部分を示す説明図である。
【図４２】図４２は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの受注企業データプロファイル部分を示す説明図である。
【図４３】図４３４本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルを示す説明図である。
【図４４】図４４は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルを示す説明図である。
【図４５】図４５は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する関数管理（ＦＵＮＣＴＩＯＮ）テーブルを示す説明図である。
【図４６】図４６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する対象管理（ＳＹＳＴＥＭ＿ＯＢＪＥＣＴ）テーブルを示す説明図である。
【図４７】図４７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する行管理（ＲＯＷ）テーブルを示す説明図である。
【図４８】図４８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する値管理（ＣＥＬＬ）テーブルを示す説明図である。
【図４９】図４９は本発明の実施の形態６に係るデータ管理システムをシステム開発支援ＣＡＳＥツールに適用する場合の概念を説明するブロック図である。
【図５０】図５０は本発明の実施の形態６に係るデータ管理システムのテーブル間の双方向のデータ変換の概念を説明するブロック図である。
【図５１】図５１は本発明の実施の形態６に係るデータ管理システムのテーブルと帳票との間での片方向（一方向）のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
【図５２】図５２は本発明の実施の形態６に係るデータ管理システムにおいて納品書の金額の表示方法が相違する場合の処理の概念を説明するブロック図である。
【図５３】図５３は本発明の実施の形態６に係るデータ管理システムのテーブルと表示画面との間での双方向のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
【図５４】図５４は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルを概略的に示す説明図である。
【図５５】図５５は本発明の実施の形態６に係るデータ管理システムで使用する帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルを概略的に示す説明図である。
【図５６】図５６は本発明の実施の形態６に係るデータ管理システムで使用する帳票（ＦＯＲＭ）テーブルを概略的に示す説明図である。
【図５７】図５７は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルの設定例を概略的に示す説明図である。
【図５８】図５８は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの設定例を概略的に示す説明図である。
【図５９】図５９は本発明の実施の形態６に係るデータ管理システムで使用する画面表示（ＦＯＲＭ）テーブルの設定例を概略的に示す説明図である。
【図６０】図６０は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの設定例を説明するブロック図である。
【図６１】図６１は本発明の各実施の形態２〜６に係るデータ管理システムの発注企業データ読込・格納処理を示すフローチャートである。
【図６２】図６２は本発明の各実施の形態２〜６に係るデータ管理システムの伝票一覧表示処理を示すフローチャートである。
【図６３】図６３は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理を示すフローチャートである。
【図６４】図６４は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業オリジナルデータ取得処理を示すフローチャートである。
【図６５】図６５は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業伝票データ取得処理を示すフローチャートである。
【図６６】図６６は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理におけるシステム標準データ取得処理を示すフローチャートである。
【図６７】図６７は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における受注企業指定データ取得処理を示すフローチャートである。
【図６８】図６８は本発明の各実施の形態２〜６に係るデータ管理システムのデータ出力処理を示すフローチャートである。
【図６９】図６９は本発明の各実施の形態２〜６に係るデータ管理システムの項目値変換処理を示すフローチャートである。
【図７０】図７０は本発明の実施の形態１〜６に係るデータ管理システムのデータ変換処理及び表示処理の特徴を説明するブロック図である。
【図７１】図７１は従来のデータ管理システムのデータ変換処理の表示処理を説明するブロック図である。
【図７２】図７２は本発明の実施の形態７に係るデータ管理システムの列管理テーブルを示す説明図である。
【図７３】図７３は本発明の実施の形態８に係るデータ管理システムの関数管理テーブルを示す説明図である。
【図７４】図７４は本発明の実施の形態９に係るデータ管理システムの関数テーブルを示す説明図である。
【図７５】図７５は本発明の実施の形態１０に係るデータ管理システムの索引管理テーブルを示す説明図である。
【図７６】図７６は本発明の実施の形態１０に係るデータ管理システムの行関連管理テーブルを示す説明図である。
【図７７】図７７は従来のデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。
【図７８】図７８は従来の複数の企業システム間のデータ変換の態様を概略的に示すデータフロー図である。
【図７９】図７９は従来の複数の企業システム間のデータ変換におけるデータマッピングの態様を概略的に示すデータフロー図である。
【図８０】図８０は従来のアプリケーションシステム（パッケージソフト）の格納データの態様を概略的に示すデータフロー図である。
【図８１】図８１は従来の複数のアプリケーションシステム（パッケージソフト）間でのデータ変換の態様を概略的に示すデータフロー図である。
【図８２】図８２は従来の複数のアプリケーションシステム（パッケージソフト）間でのデータ変換におけるエクスポート／インポートの際の人手によるデータ加工作業を概略的に示すデータフロー図である。
【図８３】図８３は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる複数のアプリケーションシステム（パッケージソフト）間でのデータ変換におけるエクスポート／インポートの際の自動データ加工処理を概略的に示すデータフロー図である。
【図８４】図８４は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる標準プロファイルを使用したデータ交換の場合の必要システム数（必要マッピング数）を、従来のシステム構成によるデータ交換の場合の必要システム数（必要マッピング数）と比較して示すデータフロー図である。
【図８５】図８５は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる複数の企業システム間でのデータ変換の仕組みを従来の標準ＸＭＬデータを介したデータ変換の仕組みと比較して説明する説明図である。
【図８６】図８６は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで使用する各種業界・各種システム・各種パッケージソフトのデータ構造乃至ファイル構成（テーブル関連）を例示するデータ構造図である。
【図８７】図８７は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで使用するデータベースのテーブル一覧を示す表である。
【図８８】図８８は本発明の実施の形態１１に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる標準プロファイル（汎用商品プロファイル）を使用した異なるアプリケーションシステム（パッケージソフト）間のデータ交換処理の概要を示すデータフロー図である。
【図８９】図８９は本発明の実施の形態１２に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるシステムプロファイルの配信サービスシステムの概要を示すデータフロー図である。
【図９０】図９０は本発明の実施の形態１３に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによる業界システムプロファイルの作成及び配信処理と、当該業界のパッケージ開発ベンダーによるパッケージのシステムプロファイルの作成及び配信処理と、当該業界システムプロファイルとパッケージのシステムプロファイルとの関連定義処理との概要を示すデータフロー図である。
【図９１】図９１は従来の中小企業の業務フローと電子データ交換（ＥＤＩ）との関係を概略的に示すデータフロー図である。
【図９２】図９２は従来の中小企業の導入パッケージソフトによるデータ管理の態様を概略的に示すデータフロー図である。
【図９３】図９３は従来の電子データ交換（ＥＤＩ）と既存システムとの関係を受注処理業務の場合を例にとって概略的に示すデータフロー図である。
【図９４】図９４は従来の中小企業の導入パッケージソフトによるデータ交換処理の利用形態の概要を示すデータフロー図である。
【図９５】図９５は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムの全体構成の概要を示す説明図である。
【図９６】図９６は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムのシステムプロファイルを処理するクラスの構成概要図である。
【図９７】図９７は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ変換処理の概要を示すデータフロー図である。
【図９８】図９８は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるテーブル間の連結・対応関係の概要を示す説明図である。
【図９９】図９９は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける連結カラム定義（ＪＯＩＮ＿ＣＯＬＵＭＮ）テーブルの一例を示す説明図である。
【図１００】図１００は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける連結種別定義（ＪＯＩＮ＿ＫＩＮＤ）テーブルの一例を示す説明図である。
【図１０１】図１０１は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおけるイベント定義（ＥＶＥＮＴ）テーブルの一例を示す説明図である。
【図１０２】図１０２は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおけるプロシージャ定義（ＰＲＯＣＥＤＵＲＥ）テーブルの一例を示す説明図である。
【図１０３】図１０３は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルの一例を示す説明図である。
【図１０４】図１０４は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムを利用したＸＭＬ各種データの自動生成の概念を示す説明図である。
【図１０５】図１０５は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ一元管理の第１の事例を示す説明図である。
【図１０６】図１０６は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ一元管理の第２の事例を示す説明図である。
【図１０７】図１０７は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ変換の一例を概略的に示す説明図である。
【図１０８】図１０８は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるデータ整合性を考慮したデータ変換の一例を概略的に示す説明図である。
【図１０９】図１０９は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムで利用されるバーコードや電子タグ等のフォーマット共有化の概念を示す説明図である。
【図１１０】図１１０は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムによるバーコードや電子タグ等のデータ識別フォーマット（共有化フォーマット）を活用したアプリケーションの概念を示す説明図である。
【図１１１】図１１１はは本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおけるデータアップロードによる自動変換処理の概念を示す説明図である。
【図１１２】図１１２は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける共用ヘッダ情報読み取りによる自動変換処理の概念を示す説明図である。
【図１１３】図１１３は本発明の実施の形態１４に係るデータ管理システムとしてのシステムエクスチェンジプロファイル（ＳＸＰ）サービスシステムにおける共用ヘッダ情報読み取りによる自動変換処理の概念を示す説明図である。
【符号の説明】
【０２２６】
１３１０：システム用項目定義情報
１３２０：項目関連定義情報
１３３０：標準プロファイル用項目定義情報
【図１】
2008243193.tif 000003
【図２】
2008243193.tif 000004
【図３】
2008243193.tif 000005
【図４】
2008243193.tif 000006
【図５】
2008243193.tif 000007
【図６】
2008243193.tif 000008
【図７】
2008243193.tif 000009
【図８】
2008243193.tif 000010
【図９】
2008243193.tif 000011
【図１０】
2008243193.tif 000012
【図１１】
2008243193.tif 000013
【図１２】
2008243193.tif 000014
【図１３】
2008243193.tif 000015
【図１４】
2008243193.tif 000016
【図１５】
2008243193.tif 000017
【図１６】
2008243193.tif 000018
【図１７】
2008243193.tif 000019
【図１８】
2008243193.tif 000020
【図１９】
2008243193.tif 000021
【図２０】
2008243193.tif 000022
【図２１】
2008243193.tif 000023
【図２２】
2008243193.tif 000024
【図２３】
2008243193.tif 000025
【図２４】
2008243193.tif 000026
【図２５】
2008243193.tif 000027
【図２６】
2008243193.tif 000028
【図２７】
2008243193.tif 000029
【図２８】
2008243193.tif 000030
【図２９】
2008243193.tif 000031
【図３０】
2008243193.tif 000032
【図３１】
2008243193.tif 000033
【図３２】
2008243193.tif 000034
【図３３】
2008243193.tif 000035
【図３４】
2008243193.tif 000036
【図３５】
2008243193.tif 000037
【図３６】
2008243193.tif 000038
【図３７】
2008243193.tif 000039
【図３８】
2008243193.tif 000040
【図３９】
2008243193.tif 000041
【図４０】
2008243193.tif 000042
【図４１】
2008243193.tif 000043
【図４２】
2008243193.tif 000044
【図４３】
2008243193.tif 000045
【図４４】
2008243193.tif 000046
【図４５】
2008243193.tif 000047
【図４６】
2008243193.tif 000048
【図４７】
2008243193.tif 000049
【図４８】
2008243193.tif 000050
【図４９】
2008243193.tif 000051
【図５０】
2008243193.tif 000052
【図５１】
2008243193.tif 000053
【図５２】
2008243193.tif 000054
【図５３】
2008243193.tif 000055
【図５４】
2008243193.tif 000056
【図５５】
2008243193.tif 000057
【図５６】
2008243193.tif 000058
【図５７】
2008243193.tif 000059
【図５８】
2008243193.tif 000060
【図５９】
2008243193.tif 000061
【図６０】
2008243193.tif 000062
【図６１】
2008243193.tif 000063
【図６２】
2008243193.tif 000064
【図６３】
2008243193.tif 000065
【図６４】
2008243193.tif 000066
【図６５】
2008243193.tif 000067
【図６６】
2008243193.tif 000068
【図６７】
2008243193.tif 000069
【図６８】
2008243193.tif 000070
【図６９】
2008243193.tif 000071
【図７０】
2008243193.tif 000072
【図７１】
2008243193.tif 000073
【図７２】
2008243193.tif 000074
【図７３】
2008243193.tif 000075
【図７４】
2008243193.tif 000076
【図７５】
2008243193.tif 000077
【図７６】
2008243193.tif 000078
【図７７】
2008243193.tif 000079
【図７８】
2008243193.tif 000080
【図７９】
2008243193.tif 000081
【図８０】
2008243193.tif 000082
【図８１】
2008243193.tif 000083
【図８２】
2008243193.tif 000084
【図８３】
2008243193.tif 000085
【図８４】
2008243193.tif 000086
【図８５】
2008243193.tif 000087
【図８６】
2008243193.tif 000088
【図８７】
2008243193.tif 000089
【図８８】
2008243193.tif 000090
【図８９】
2008243193.tif 000091
【図９０】
2008243193.tif 000092
【図９１】
2008243193.tif 000093
【図９２】
2008243193.tif 000094
【図９３】
2008243193.tif 000095
【図９４】
2008243193.tif 000096
【図９５】
2008243193.tif 000097
【図９６】
2008243193.tif 000098
【図９７】
2008243193.tif 000099
【図９８】
2008243193.tif 000100
【図９９】
2008243193.tif 000101
【図１００】
2008243193.tif 000102
【図１０１】
2008243193.tif 000103
【図１０２】
2008243193.tif 000104
【図１０３】
2008243193.tif 000105
【図１０４】
2008243193.tif 000106
【図１０５】
2008243193.tif 000107
【図１０６】
2008243193.tif 000108
【図１０７】
2008243193.tif 000109
【図１０８】
2008243193.tif 000110
【図１０９】
2008243193.tif 000111
【図１１０】
2008243193.tif 000112
【図１１１】
2008243193.tif 000113
【図１１２】
2008243193.tif 000114
【図１１３】
2008243193.tif 000115