JP2007213551A - データ管理システム - Google Patents

データ管理システム Download PDF

Info

Publication number
JP2007213551A
JP2007213551A JP2006228497A JP2006228497A JP2007213551A JP 2007213551 A JP2007213551 A JP 2007213551A JP 2006228497 A JP2006228497 A JP 2006228497A JP 2006228497 A JP2006228497 A JP 2006228497A JP 2007213551 A JP2007213551 A JP 2007213551A
Authority
JP
Japan
Prior art keywords
data
record
column
management table
item
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2006228497A
Other languages
English (en)
Other versions
JP4945196B2 (ja
Inventor
Hiroshi Sawake
博 佐分
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SYSTEM PRODUCE KK
Original Assignee
SYSTEM PRODUCE KK
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SYSTEM PRODUCE KK filed Critical SYSTEM PRODUCE KK
Priority to JP2006228497A priority Critical patent/JP4945196B2/ja
Publication of JP2007213551A publication Critical patent/JP2007213551A/ja
Application granted granted Critical
Publication of JP4945196B2 publication Critical patent/JP4945196B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】ＥＤＩ標準フォーマットデータ等の標準データ以外の任意のフォーマットのデータを交換する場合でも、多種多様なフォーマットのデータを互いに交換することができるデータ管理システムの提供
【解決手段】データ管理システムは、管理対象のレコードのデータ項目名と、データ項目名を一意に示す列ＩＤとを予め特定して静的に格納する列管理テーブルと、レコードを一意に示す行ＩＤを格納する行管理テーブルと、列管理テーブルと行管理テーブルとを結合することにより動的に作成される値管理テーブルとを備える。
【選択図】図１

Description

本発明は、データ管理システムに関し、特に、多種多様なフォーマットのデータを互いに交換するのに好適なデータ管理システムに関する。
従来、この種の技術として、例えば、特許文献１に記載の技術がある。
特開２００３−２０８３８２号公報
特許文献１には、ＥＤＩ利用ユーザ企業各々に、ＥＤＩ標準フォーマットデータのＥＤＩ利用ユーザ企業社内フォーマットデータへのデータフォーマット変換とその逆変換上での負担を負わせることなく、それらデータフォーマット変換がインターネット上の特定サイト上で行われるようにした、ＥＤＩ利用ユーザ企業間でのデータフォーマット変換方法とそのシステムが開示されている。このシステムは、ＥＤＩ利用ユーザ企業間でのデータ送受信を、それぞれの社内フォーマットデータを以って行う。具体的には、このシステムは、電子商取引サイトに、インターネットを介しあるユーザ企業からユーザ企業への社内フォーマットデータがあった場合、そのデータはそのユーザ企業対応の事前登録データ変換プロファイル情報に基づき、一旦、ＥＤＩ標準フォーマットデータに変換されるが、その後は、更に、ユーザ企業対応の事前登録データ変換プロファイル情報に基づき、ユーザ企業の社内フォーマットデータに変換された上、インターネットを介しユーザ企業に送信される。この技術は、既存マッピングツールをインターネット上で機能させる仕組みであり、各企業が自社の個別フォーマットを業界標準フォーマットとマッピングさせる事で利用可能となる。
しかし、特許文献１に記載の技術は、取引先企業が利用していない場合は、利用不可である。また、特許文献１には、具体的なデータ格納やデータ変換の記述は無く、外部設計に終始している。また、ＥＤＩ利用ユーザ企業間でのデータ送受信を対称にしたものであり、ＥＤＩ標準フォーマットデータ自体の利用が少ない現状では、利用できる企業が大幅に限定される。
そこで、本発明は、多種多様なフォーマットのデータを互いに交換することができると共に、管理対象データのデータフォーマットの追加、変更等にも容易に対処できるデータ管理システムの提供を課題とする。
請求項１に係るデータ管理システムは、少なくとも、管理対象のレコードを構成する各データ項目を一意に示す列ＩＤを予め定義して静的に格納する列管理ファイルと、前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理ファイルと、前記レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理ファイルに格納した行ＩＤと前記列管理ファイルに格納した列ＩＤとにより一意に特定して動的に格納する値管理ファイルとを備える。
請求項２に係るデータ管理システムは、少なくとも、管理対象のレコードを構成する各データ項目を一意に示す列ＩＤを予め定義して静的に格納する列管理テーブルと、前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理テーブルと、前記読込レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理テーブルに格納した行ＩＤと前記列管理テーブルに格納した列ＩＤとにより一意に特定して動的に格納する値管理テーブルとを備える。
請求項３に係るデータ管理システムは、請求項２の構成において、前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれについて、当該レコードを構成する各データ項目を一意に示す列ＩＤを予め特定して静的に格納することにより、前記複数種類のレコードを構成するデータ項目を予め定義し、前記行管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードから所定の識別子を取得して前記行ＩＤに対応付けて格納し、前記値管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードのデータ項目の項目値をデータ項目ごとに分割して格納する。
請求項４に係るデータ管理システムは、少なくとも、管理対象のレコードのデータフォーマットを一意に示すレコードＩＤ（テーブルＩＤ）を予め特定して静的に格納する列管理テーブルと、前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理テーブルと、前記読込レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理テーブルに格納した行ＩＤと前記列管理テーブルに格納したレコードＩＤとにより一意に特定して動的に格納する値管理テーブルとを備え、前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれについて、当該レコードのデータフォーマットを一意に示すレコードＩＤを予め特定して静的に格納することにより、前記複数種類のレコードのデータフォーマットを予め定義して異なるデータフォーマットのレコードを識別するようにし、前記行管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードから所定の識別子を取得して前記行ＩＤに対応付けて格納し、前記値管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードのデータフォーマットの定義部分を参照し、当該読込レコードの行ＩＤ及びレコードＩＤに対応付けて、当該読込レコードのデータ項目の項目値を格納する。
請求項５に係るデータ管理システムは、請求項２乃至４のいずれかの構成において、前記列管理テーブルをデータ管理センターのサーバに配置すると共に、前記行管理テーブル及び前記値管理テーブルをユーザのクライアントに配置し、前記列管理テーブルにおいて管理対象のレコードを構成するデータ項目の定義情報またはデータフォーマットの定義情報に更新（追加、削除、変更）があった場合、ユーザのクライアントからデータ管理センターのサーバに接続して、前記列管理テーブルにおいて更新（追加、削除、変更）があったデータ項目の定義情報部分またはデータフォーマットの定義情報部分を取得自在とした。この場合、ユーザのクライアントには列管理テーブルを備えず、レコードの読込時には、ユーザーのクライアントからデータ管理センタのサーバに接続して定義情報を取得し、実データを行管理テーブル及び値管理テーブルへ格納するようにしても良いし、ユーザーのクライアントにも列管理テーブルを備え、更新のあった定義情報部分だけダウンロードするようにしても良い。
請求項６に係るデータ管理システムは、請求項５の構成において、更に、異なるデータフォーマットの複数種類のレコードのデータ項目間におけるリンク情報を定義する項目関連定義テーブルを備え、当該項目関連テーブルを参照して、値管理テーブルに格納した所定データフォーマットの読込レコードのデータ項目値を、異なるデータフォーマットのレコードへと変換自在とし、前記項目関連定義テーブルにおいてリンク情報に更新（追加、削除、変更）があった場合、ユーザのクライアントからデータ管理センターのサーバに接続して、前記項目関連定義テーブルにおいて更新（追加、削除、変更）があったリンク情報部分を取得自在とした。
請求項７に係るデータ管理システムは、請求項３乃至６のいずれかの構成において、前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれの定義情報に加え、標準フォーマットのレコードの定義情報を格納し、更に、異なるデータフォーマットの複数種類のレコードのデータ項目と前記標準フォーマットのレコードのデータ項目との間におけるリンク情報を定義する項目関連定義テーブルを備え、当該項目関連テーブルを参照して、値管理テーブルに格納した所定データフォーマットの読込レコードのデータ項目値を、標準フォーマットのレコードを介して、異なるデータフォーマットのレコードへと変換自在とした。
請求項８に係るデータ管理システムは、請求項２乃至７のいずれかの構成において、前記列管理テーブルには、階層構造を有するレコードの当該階層構造を定義するレコード関連情報（枝番）を格納し、前記レコード関連情報を使用して、前記レコードの階層構造を維持するようにしたことを特徴とする請求項２乃至７のいずれか１項に記載のデータ管理システム。
請求項９に係るデータ管理システムは、請求項２乃至８のいずれかの構成において、更に、階層構造または親子関係を有するレコードの当該階層構造または親子関係を定義するレコード関連情報を格納する行関連管理テーブルを備え、前記レコード関連情報を使用して、前記レコードの階層構造または親子関係を維持するようにした。
請求項１０に係るデータ管理システムは、請求項２乃至９のいずれかの構成において、前記列管理テーブルには、管理対象のレコードのデータ種類を特定するデータ種類情報を格納し、複数種類のレコードを、その種類を特定して前記値管理テーブルに格納自在とした。
請求項１１に係るデータ管理システムは、少なくとも、管理対象のレコードのデータ項目のデータ項目名と、前記データ項目名を一意に特定する列ＩＤとを予め特定して静的に格納する列管理テーブルと、少なくとも、読込レコードを一意に特定する行ＩＤを読込レコードにそれぞれ割り付けて動的に格納する行管理テーブルと、前記列管理テーブルと前記行管理テーブルとを結合することにより動的に作成され、少なくとも、前記行管理テーブルに格納した行ＩＤと、前記列管理テーブルに格納した列ＩＤと、前記レコードの各データ項目の値とを格納する値管理テーブルとを備え、前記値管理テーブルの各データ項目の値を、前記各行ＩＤと前記各列ＩＤとにより特定して格納するようにした。
請求項１２に係るデータ管理システムは、請求項１１の構成において、前記管理対象のレコードとして、異なるデータフォーマットを有する複数種類のレコードを格納し、管理対象として読込み予定の全ての種類のレコードについて、各レコードに含まれるデータ項目名を特定して前記列管理テーブルに予め静的に格納すると共に、前記各列ＩＤに対応して、前記レコードのデータフォーマットを一意に示すテーブルＩＤを前記列管理テーブルに静的に格納し、実際に読込んだ管理対象のレコードについてテーブルＩＤを判断し、前記列管理テーブルのデータ項目名のうち、当該テーブルＩＤに対応するデータ項目名について、当該読込レコードから値を取得して前記値管理テーブルに動的に格納し、読込レコードが複数ある場合には、各読込レコードについて前記行ＩＤを割当てると共に、各読込レコードについてテーブルＩＤを判断する。
請求項１３に係るデータ管理システムは、請求項１２の構成において、前記テーブルＩＤにより示されるデータフォーマットと異なるデータフォーマットのレコードが管理対象となった場合、当該新規データフォーマットのレコードに含まれるデータ項目名を前記列管理テーブルのデータ項目名に追加すると共に、追加した各データ項目名に対応して列ＩＤを追加して、追加した各列ＩＤに対応して前記テーブルＩＤを追加することにより、新規データフォーマットのレコードに対応できるようにした。
請求項１４に係るデータ管理システムは、レコードを階層構造で保持するデータを格納するデータ管理システムであって、少なくとも、管理対象のレコードのデータ項目名と、前記データ項目名を一意に示す列ＩＤと、当該レコードの階層位置を示す枝番とを予め特定して静的に格納する列管理テーブルと、少なくとも、前記レコードを一意に示す行ＩＤを読込レコードに割り付けて動的に格納する行管理テーブルと、前記列管理テーブルと前記行管理テーブルとを結合することにより動的に作成され、少なくとも、前記行管理テーブルに格納した行ＩＤと、前記列管理テーブルに格納した列ＩＤと、前記レコードの各データ項目名の値とを格納する値管理テーブルとを備え、前記値管理テーブルの各データ項目名の値を、前記各行ＩＤと前記各列ＩＤとにより特定して格納するようにした。
請求項１５に係るデータ管理システムは、特定のデータフォーマットを有する標準データを予め定義し、前記管理対象としての読込予定の全ての一次データのデータフォーマットについて、前記標準データとの間でマッピングしてリンク情報を作成し、前記一次データを加工して得る予定の二次データのデータフォーマットついて、前記標準データとの間でマッピングしてリンク情報を作成し、前記リンク情報に基づき、実際に読込んだ一次データの各データ項目を前記標準データの対応するデータ項目を介して、加工すべき二次データの対応するデータ項目に割り当てて、前記一次データを二次データへ加工する。
請求項１６に係るデータ管理システムは、請求項１５の構成において、更に、前記一次データと前記標準データとのリンク情報、及び、前記標準データと前記二次データとのリンク情報を格納する項目関連定義テーブルを備え、前記一次データのみデータ格納領域に一次情報として保存し、前記標準データは、前記項目関連定義テーブルにおける前記一次データと前記標準データとのリンク情報に基づき、前記一次データから必要に応じて作成すると共に、前記二次データは、前記項目関連定義テーブルにおける前記標準データと前記一次データとのリンク情報及び前記一次と前記標準データとのリンク情報に基づき、前記一次データから必要に応じて作成する。
請求項１７に係るデータ管理システムは、請求項１乃至１６のいずれかの構成において、行管理テーブルにデータマッチング用ＩＤ（突合値）を格納し、一次データから二次データ加工時の特定のデータ項目名をマッチングして値を訂正する。
本発明のデータ管理システムは、階層型データベース、ネットワーク型データベース、リレーショナルデータベース（ＲＤＢ）等の任意のデータベースを使用するデータ管理システムに適用することができる。なお、請求項１のデータ管理システムを、リレーショナルデータベース（関係データベースとも呼ばれる）を利用したデータ管理システムに適用した場合、列管理ファイルは列管理テーブルとなり、行管理ファイルは行管理テーブルとなり、値管理ファイルは値管理テーブルとなる。このように、本発明は、特に、ＲＤＢを利用したデータベースシステムに具体化することが好ましいが、無論、その他のデータベース（ＤＢ）に具体化することも可能である。ここで、上記管理対象のレコードは、１レコードが、通常、複数のフィールド（複数のデータ項目）からなり、ＲＤＢの場合、１行のレコードをタプルと称することがある。また、通常、複数のレコードが１ファイルを構成し、ＲＤＢの場合、１ファイルが１テーブルとなる。そして、ファイルごとに固有のデータフォーマットがあり、ＲＤＢの場合、テーブルごとに固有のデータフォーマット（データ構造乃至スキーマ）がある。即ち、各テーブルは、固有のデータ項目（カラムまたは列と称することもあり、通常は複数である）を並べたデータフォーマットを有している。
また、本発明のデータ管理システムは、列ＩＤとして、通常のＲＤＢ等で使用されるコード体系（数字や英数字を使用したコード体系）にしたがったＩＤの他、ＸＭＬタグ等を利用したコード体系によるＩＤを使用することもできる。
本発明に係るデータ管理システムは、多種多様なフォーマットのデータを互いに交換することができると共に、管理対象データのデータフォーマットの追加、変更等にも容易に対処できる。また、例えば、ＥＤＩ標準フォーマットデータ等の標準データ以外の任意のフォーマットのデータを交換する場合でも、多種多様なフォーマットのデータを互いに交換することができる。特に、発注企業〜受注企業間で送受信される各種情報のフォーマット変換を効果的に行うことができる。即ち、従来のマッピング機能だけでは、発注企業各に独自対応システムが必要となり、基幹システムの保守・運用コストがかさむばかり。発注企業独自対応はすべて本データ管理システムが行う為、本データ管理システムとのインターフェースを取るのみでよい。
以下、本発明を実施するための最良の形態（以下、実施の形態という）を説明する。なお、各実施の形態を通じ、同一の部材、要素または部分には同一の符号を付して、その説明を省略する。
実施の形態１
図１は本発明の実施の形態１に係るデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。図２は本発明の実施の形態１に係るデータ管理システムのデータ構造を概略的に示す説明図である。なお、図７７は従来のデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。
従来の売上管理システム
従来のデータ管理システムは、取り扱うデータが異なるフォーマットまたは異なるデータ定義を有する場合、そのフォーマットまたはデータ定義の種類分だけ、データ定義（スキーマ定義）を行い、テーブルを作成して管理する。例えば、図７７に示す従来の売上管理システム５１０は、売上管理のために必要な異なるフォーマット乃至データ定義の各種データとして、商品データ、在庫データ、顧客データ、店舗データ、売上データ、請求データ等を取り扱う。よって、リレーショナルデータベース（ＲＤＢ）を使用する場合、従来の売上管理システム５１０は、各種データに対応する別個の格納領域として、それぞれ、商品テーブル５１１、在庫管理テーブル５１２、顧客テーブル５１３、店舗テーブル５１４、売上管理テーブル５１５、請求管理テーブル５１６等を準備して対応する各データを格納及び管理する。即ち、この場合、各テーブル５１１〜５１６等について、れぞれ、データ定義（スキーマ定義）を別個に作成する。また、従来のデータ管理システムは、データをモニタ画面１に表示または出力する場合、異なるフォーマットまたはデータ定義ごとに表示（出力）プログラムを用意する必要がある。例えば、図７７の売上管理システムの場合、商品テーブル５１１、在庫管理テーブル５１２、顧客テーブル５１３、店舗テーブル５１４、売上管理テーブル５１５、請求管理テーブル５１６等に格納した異なるフォーマット乃至データ定義の各データに対応して、それぞれ、商品明細表示（出力）プログラム（ＰＧ）５１７、在庫明細表示（出力）プログラム（ＰＧ）５１８、顧客明細表示（出力）プログラム（ＰＧ）５１９、店舗明細表示（出力）プログラム（ＰＧ）５２０、売上明細表示（出力）プログラム（ＰＧ）５２１、請求明細表示（出力）プログラム（ＰＧ）５２２等を用意し、当該異なる表示プログラムを使用して、当該異なるフォーマット乃至定義のデータをモニタ画面１にそれぞれ表示する必要がある。
本発明を適用した場合の売上管理システム
このように、従来のデータ管理システムでは、異なるデータ定義のデータごとに別個の格納領域及び表示プログラムを用意する必要があり、システムが使用するテーブルが増えるほど、データベースが大規模化し、プログラム開発に多大な労力を必要とする。そこで、本発明者は、鋭意研究を重ねた結果、かかる課題を解決する発明としてのデータ管理システムを発明した。本発明に係るデータ管理システムは、例えば、図１に示すように、実施の形態１の売上管理システム１０に具体化することができる。詳細には、実施の形態１の売上管理システム１０は、従来の売上管理システムで取り扱う全てのデータ（異なるフォーマット乃至データ定義のデータ）を取り扱うことができる一方、従来のように、データのフォーマット乃至定義ごとに別個のデータ定義（スキーマ定義）を作成して別個のテーブルを用意するのではなく、各データの定義情報を格納及び管理する列管理テーブル（データ項目乃至カラムを管理するマスタ系テーブル）１１をマスタテーブルとして用意して、異なる全てのデータフォーマット乃至データ定義に対応するようにしている。また、売上管理システム１０は、各データに含まれるデータ項目値のうち、識別子や検索キーとなる項目値（インデックスデータ）を順次格納する行管理テーブル（インデックスデータを管理するトランザクション系テーブル）１２と、前記列管理テーブル１１の定義情報の値と、行管理テーブル１２の識別子の値とを組み合わせることで、各データに含まれる全ての項目値を一意に特定できるように順次格納する値管理テーブル（項目値を格納するトランザクション系テーブル）１３とを備えている。更に、売上管理システム１０は、列管理テーブル１１の定義情報に基づき、行管理テーブル１２に格納した識別子を使用して、値管理テーブル１３に格納したデータ項目値のうちの必要な項目値を抽出し、所定のフォーマットでモニタ画面１に表示する表示（出力）プログラム（ＰＧ）１４を備えている。これにより、売上管理システム１０は、列管理テーブル１１、行管理テーブル１２及び値管理テーブル１３の３つのテーブルを用意するだけで、多種多様なデータ定義のデータを格納して管理することができ、各データ定義に対応して別個のテーブルを用意する必要がない。また、売上管理システム１０は、単一の表示（出力）プログラム１４により、多種多様なデータ定義のデータの任意の値を所定の形式でモニタ画面１に表示することができ、各データ定義に対応した別個のプログラムを用意する必要がない。即ち、本売上管理システム１０では、単一の表示プログラム１４を使用しながら、図１に示すように、モニタ画面１の表示上は、図７７の固有のデータ定義を有する各種テーブル（店舗テーブル、売上管理テーブル等）に対応する内容で同様のデータ（店舗データ、売上管理データ等）の表示が行われる。
データ分離格納のスキーマ（データ項目）
実施の形態１に係るデータ管理システムを売上管理システム以外のデータ管理システムについても当てはまるよう汎用的に説明すると、図２の中央に示すように、列管理テーブルは、管理対象の全てのデータ（テーブル）の各データ項目（フィールド）について一意に割り当てられる「列ＩＤ」と、当該列ＩＤが割り当てられたデータ項目が属するテーブルを示す「テーブル名」と、各テーブルのデータ項目の属性名（データ項目名）を示す「属性名」とからなるスキーマ（データ定義）を有する。即ち、列管理テーブルは、自身のデータ項目として、少なくとも、「列ＩＤ」、「テーブル名」及び「属性名」を備えている。例えば、取り扱うデータ（管理対象のデータ）が、甲、乙、丙、丁であり、甲データのスキーマが、属性Ｘ（ＩＤ）、属性Ａ、属性Ｂ、属性Ｃからなり、乙データのスキーマが、属性Ｘ（ＩＤ）、属性Ｃ、属性Ｂ、属性Ｄからなり、丙データのスキーマが、属性Ｙ（ＩＤ）、属性Ａ、属性Ｃ、属性Ｅからなり、丁データのスキーマが、属性Ｚ（ＩＤ）、属性Ｆ、属性Ｇ、属性Ｈからなる場合、従来のシステムでは、図２中の左側に示すように、各スキーマに対応して、甲テーブル、乙テーブル、丙テーブル及び丁テーブルが作成される。なお、各テーブルには、各データ項目（属性Ｘ等）について、項目値（ｘ１等）が格納される。これに対し、実施の形態１に係るデータ管理システムでは、列管理テーブル１１は、これらデータ定義（スキーマ）の異なる各データ（甲、乙、丙、丁）を管理対象とする場合、そのテーブル名と属性名（データ項目名）とを対応付けて各行に予め格納し、各行に列ＩＤを一意に割り当てる。具体的には、列管理テーブルは、甲データについては、その属するテーブル名（甲）と各属性名（属性Ｘ、属性Ａ、属性Ｂ、属性Ｃ）とを各行に対応付けて格納し、各行に一意の列ＩＤ（１〜）を対応付けている（乙データ、丙データ、丁データについても同様）。これにより、列管理テーブルの列ＩＤを参照することで、各データ（甲、乙、丙、丁）のデータ項目（属性名）を一意に特定することができる。このように、列管理テーブルは、管理対象の全てのデータやレコードのデータ項目を一意に特定できるよう、それらのデータ項目を（データ項目としてではなく）データ項目値として格納するマスタ系テーブルである。
また、データ管理システムでは、行管理テーブルは、前記管理対象データ（甲、乙、丙、丁）の各レコード（テーブルの各行）を読込むごとに自動的に付与される「行ＩＤ」と、各読込レコードを一意に示す「識別子」とからなるスキーマ（データ定義）を有する。そして、データ管理システムは、管理対象のレコードを読込むごとに、各読込レコードに対して行ＩＤを発番すると共に、当該読込レコード中の特定のデータ項目値を識別子として抽出し、行ＩＤに対応付けて格納する。例えば、行管理テーブルは、甲、乙、丙、丁の各テーブルについて、識別子として、属性Ｘの列のデータ項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）、属性Ｙの列のデータ項目値（ｙ１，ｙ２，ｙ３，ｙ４，ｙ５，ｙ６）、属性Ｚの列のデータ項目値（ｚ１，ｚ２，ｚ３，ｚ４，ｚ５，ｚ６）を格納する。具体的には、データ管理システムは、甲データについては、各行のレコードを読み込むごとに、各レコードのＩＤでもある属性Ｘの項目値（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５，ｘ６）を、順次、識別子の列に格納すると共に、各読込レコードの識別子に対応付けて行ＩＤを自動発番して格納する（乙データ、丙データ、丁データについても同様）。これにより、行管理テーブルの行ＩＤを参照することで、各読込レコード（及びその識別子）を一意に特定することができる。このように、行管理テーブルは、管理対象の全てのデータの読込レコードを一意に特定できるよう、それらのレコードに一意の行ＩＤを割り当てて格納するトランザクション系テーブルである。
データ分離格納のスキーマ（データ項目値）
更に、データ管理システムでは、値管理テーブルは、前記管理対象データ（甲、乙、丙、丁）の各レコード（テーブルの各行）を読込むごとに自動的に付与される「行ＩＤ」と、各読込レコードの各データ項目を一意に示す「列ＩＤ」と、行ＩＤ及び列ＩＤにより一意に特定される読込レコードの各データ項目の「値（データ項目値）」からなるスキーマ（データ定義）を有する。そして、データ管理システムは、上記のように、管理対象のレコードを読込むごとに、各読込レコードに対して行ＩＤを発番して行管理テーブルに格納すると共に、各読込レコードをそのデータ項目ごとに分解して各データ項目値を取得する。このとき、データ管理システムは、各読込レコードが属するテーブル名を判断し、列管理テーブルを参照して、当該テーブル名のデータ項目である属性名を特定し、前記抽出した読込レコードの各データ項目値に対して各属性名の列ＩＤを割り当てる。また、同一読込レコードについては、当然、同一行ＩＤが割り当てられる。具体的には、データ管理システムは、甲データについては、各行のレコードを読み込むごとに、当該読込レコードをデータ項目単位（Ｘ，Ａ，Ｂ，Ｃの単位）で分割して各データ項目値（ｘ１，ａ１，ｂ１，ｃ１、ｘ２，ａ２，ｂ２，ｃ２、・・・）を取得する。これと共に、データ管理システムは、当該読込レコードに割り当てた行ＩＤ（１、２、・・・）と、当該読込レコードの各属性名（属性Ｘ、属性Ａ、属性Ｂ、属性Ｃ）とを、取得した各データ項目値に対応付けて格納する。例えば、甲データの１行目のレコードについては、各データ項目値（ｘ１，ａ１，ｂ１，ｃ１）を取得すると共に、各データ項目値に対して、当該レコードの行ＩＤ（１）と各データ項目値の属性名に対応する列ＩＤ（１，２，３，４）とを割り当てて格納する。以降、甲データの各行のレコードについて、同様の処理により、各データ項目値が値管理テーブルに格納される。乙データ、丙データ、丁データの場合も同様である。これにより、値管理テーブルの行ＩＤ及び列ＩＤを参照することで、各読込レコードの各データ項目値を一意に特定することができる。このように、値管理テーブルは、管理対象の全てのデータの読込レコードの各データ項目値を一意に特定できるよう、それらのデータ項目値に行ＩＤ及び列ＩＤを割り当てて格納するトランザクション系テーブルである。
ここで、行管理テーブル１３の識別子としては、管理対象データ（甲データ等）自体のインデックスとなる項目値（ｘ１，ｘ２・・・）以外の項目値または複数の項目値の組合せを私用しても良い。また、前記列管理テーブル１１の列ＩＤ及び行管理テーブル１２の行ＩＤは、説明を単純化するために、単なる数字（連番）とされているが、一意となる限りにおいて、無論、任意の規則にしたがって列ＩＤ及び行ＩＤを作成することができる（例えば、後述の列管理テーブルの説明参照）。
データ分離格納を使用した売上管理システム
図３は本発明の実施の形態１に係るデータ管理システムを売上管理システムに具体化した場合のデータ構造を概略的に示す説明図である。実施の形態１に係る売上管理システム１０は、上記図２により説明した場合と同様のデータ構造を有し、同様のデータ処理により管理対象データを３つのテーブルに格納する。即ち、売上管理システムは、列管理テーブル１１に、予め、各管理対象データのスキーマ定義情報としての属性名（即ち、読込対象となる商品、在庫管理、顧客、売上管理、店舗、請求管理の各テーブルのデータ項目名）を、当該テーブル名及び一意の列ＩＤと共にマスタデータとして格納している。具体的には、列管理テーブル１１は、図１に示すデータを管理対象とする場合、商品テーブルのデータ項目（商品ＩＤ、商品名、価格、内容量）、在庫管理テーブルのデータ項目（商品ＩＤ、商品名、在庫数、場所）、顧客テーブルのデータ項目（顧客ＩＤ、顧客名、連絡先、担当者）、売上管理テーブルのデータ項目（商品ＩＤ、顧客ＩＤ、売上数、売上高）、店舗テーブルのデータ項目（顧客ＩＤ、店舗ＩＤ、店舗名、場所）及び請求管理テーブルのデータ項目（請求ＩＤ、顧客ＩＤ、請求額、締日）を一意の列ＩＤ（１，２，３，４・・・）に対応付けて格納している。なお、図３では、売上管理テーブル及び店舗テーブルについては、説明の便宜上、図示を省略している。また、図３の各テーブル中、属性名の右横のカッコ内の英字（アルファベット）が同一のものは、データ項目が同一であることを意味する。（例えば、商品テーブルの商品ＩＤ（Ｘ）と在庫テーブルの商品ＩＤ（Ｘ）は同一データ項目であり、商品テーブルの商品名（Ａ）と在庫テーブルの商品名（Ａ）は同一データ項目である等々。）これにより、列管理テーブル１１を参照することで、管理対象データのテーブル名に加えて、当該テーブルのデータ項目を判断することができる。例えば、商品テーブルについては、列ＩＤの「１〜４」に対応して、属性名として「商品ＩＤ、商品名、価格、内容量」が定義されているため、列ＩＤの「１〜４」を参照することで、管理対象データのテーブルが「商品テーブル」であると判断でき、かつ、商品テーブルのデータ項目が「商品ＩＤ、商品名、価格、内容量」であると判断することができる。
また、売上管理システムは、管理対象データの各レコードを読み込むごとに、行管理テーブル１２に一意の行ＩＤを割り当てて格納すると共に、当該読込レコードの特定のデータ項目値を識別子として格納する。例えば、商品テーブルのレコードを読み込む場合、行管理テーブル１２には、商品テーブルのレコード（一行）を読込むごとに行ＩＤ（１，２・・・）が発行され、行ＩＤに対応して読込レコードの特定の項目値が識別子として格納される。例えば、商品テーブルに関しては、商品ＩＤ（４９００１，４９００２・・・）を識別子として行管理テーブル１２に格納することができる。なお、在庫テーブル等の他のテーブルについても、同様に、各読込レコードに一意の行ＩＤが付与されると共に、各読込レコードの特定の項目値が識別子として取得され、行ＩＤと対応付けて格納される。
更に、売上管理システムは、管理対象データの各レコードを読み込むごとに、各読込レコードをデータ項目の項目値ごとに分割し、分割したデータ項目値の全てに同一の行ＩＤを割り当てると共に、分割したデータ項目値に対応する列ＩＤを順に割り当てて、行ＩＤ、列ＩＤ及び値のセットで格納する。例えば、商品テーブルのレコード（「４９００１，ガム，１００，１０」、「４９００２，飴，１００，１０」・・・）を読み込む場合、売上管理システムは、まず一行目のレコード（４９００１，ガム，１００，１０）のデータ項目値を分割し、それら４つのデータ項目値に行ＩＤ（１）を割り当てると共に、それら４つのデータ項目値に対して列ＩＤ（１〜４）を順に割り当て、それらのデータセット（「１，１，４９００１」、「１，２，ガム」、「１，３，１００」、「１，４，１０」）を値管理テーブル１３に格納する。なお、在庫テーブル等の他のテーブルについても、同様に、各読込レコードに一意の行ＩＤが付与される。２行目以降のレコードについても、各レコード読込時に、同様にして、行ＩＤ、列ＩＤ及び値の組が値管理テーブル１３に格納される。なお、在庫テーブル等の他のテーブルについても、同様に、読込レコードの各データ項目値が、行ＩＤ及び列ＩＤと対応付けて格納される。
図４〜図８は従来のデータ管理システムにおけるデータ定義の一例としての商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルをそれぞれ示す。
図４に示すように、従来の商品テーブルは、データ項目として、「商品ＩＤ」、「商品名」、「単価」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、たばこ、２００円等）を格納する。同様に、顧客テーブルは、データ項目として、「企業コード」、「企業名」、「電話番号」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（ア、山田商事、０５８−１１１−１１１１等）を格納する。同様に、顧客単価テーブルは、データ項目として、「商品ＩＤ」、「企業コード」、「単価」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、ア、２００円等）を格納する。同様に、在庫管理テーブルは、データ項目として、「商品ＩＤ」、「数量」、「場所」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、５００、倉庫Ａ等）を格納する。同様に、販売管理テーブルは、データ項目として、「商品ＩＤ」、「企業コード」、「販売数」等をデータベース設計時にデータベーススキーマにより定義し、そのデータ項目値として、対応する値（４９０１、ア、１００個等）を格納する。
売上管理システムに適用した列管理テーブル
図９は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における列管理テーブルを示す。
図９に示すように、実施の形態１に係るデータ管理システムを適用した列管理テーブルは、図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルのデータ定義をデータ項目としてではなく、データ項目値として格納するものであり、それら５つのテーブルのデータ項目を全てデータ項目値として予め定義し、マスタデータとして格納している。詳細には、列管理テーブルは、データ項目（カラム乃至属性とも呼ばれる）として、「列ＩＤ」、「データ種類」、「テーブルＩＤ」、「枝番」、「連番」、「データ項目名」、「データ型」、「位置」、「最大長」、「最小長」等を定義している。このうち、データ種類は、管理対象のデータの種類を一意に示すものであり、テーブルＩＤは、管理対象のデータが属するテーブルを一意に示すものである。データ種類は、テーブルＩＤより上位概念のデータ群を定義するＩＤであり、例えば、テーブルＩＤが「商品マスタ」の場合、当該商品マスタ（マスタデータ）を包括する（即ち、他の同類のデータを包括する）取引情報データの種類を一意に示すものとすることができる。この場合、例えば、図９の例では、データ種類「１２０１」の上位データ群にはテーブルＩＤ「商品マスタデータ」等の下位データ群が属し、データ種類「１２０２」の上位データ群にはテーブルＩＤ「顧客マスタデータ」等の下位データ群が属し、データ種類「１２０３」の上位データ群にはテーブルＩＤ「顧客単価マスタデータ」等の下位データ群が属し、データ種類「１２０４」の上位データ群にはテーブルＩＤ「在庫マスタデータ」等の下位データ群が属し、データ種類「１２０５」の上位データ群にはテーブルＩＤ「販売マスタデータ」等の下位データ群が属することになる。
ここで、図９の例では、テーブルＩＤは、説明の簡略化のため、「商品マスタ」、「顧客マスタ」等の文字列で表しているが、実際は、所定のコード体系（ＩＤ付与規則）にしたがってテーブルごとに付与される一意のＩＤ（英数字等）からなる。例えば、商品マスタデータは「１０」、顧客マスタデータは「２０」、顧客単価マスタデータは「３０」、在庫マスタデータは「４０」、販売マスタデータは「５０」等として、テーブルＩＤの値として格納することができる。このように、テーブルＩＤにより、読込対象のデータを格納する各テーブルのデータ定義（即ち、当該テーブルのデータ項目）が一意に特定される。即ち、テーブルＩＤは、管理対象データ（読込データ）を格納するテーブルのデータ定義（データフォーマット）を一意に示すものであり、各データフォーマットの管理対象データに対して一意に割り当てられるコードである。要するに、テーブルＩＤは、管理対象データのテーブルが異なるごとに、即ち、データフォーマットの異なるデータごとに、一意のコードとして割り当てられる。例えば、本事例のデータ管理システムのように、商品マスタテーブル、顧客マスタテーブル、顧客単価マスタテーブル、在庫マスタテーブル、販売マスタテーブル等の異なるデータフォーマットの管理対象データを読込んで格納及び管理する場合、それら複数のデータフォーマットに対応して、それぞれ、一意のテーブルＩＤを付与して列管理テーブルに格納することになる。
前記枝番は、あるテーブルＩＤのテーブルに関連付けた（同一階層、下位階層等の）別のテーブルが存在する場合に、それらのテーブル間の関係を示すためのコードである。例えば、商品マスタテーブルは、商品情報（商品の属性を表す各種データ）を格納して管理するものであるが、商品情報を管理するために、互いに関連する複数の商品情報関係のテーブル（商品情報テーブル群）を用意することも多い。この場合、狭義の「商品マスタテーブル」以外に、例えば、当該商品マスタテーブルと関連付けた「商品＊＊テーブル」といった１以上のテーブルが存在する。よって、枝番は、このような場合に、特定のテーブルＩＤにより示されるテーブルについて関連付けた別テーブルが存在することを示すための情報、或いは、テーブルをグループ分けするための情報として使用する。具体的には、枝番が「０」の場合（図９の場合）、対応するテーブルＩＤのテーブルに関連するテーブルは存在しないことを示す。なお、枝番が「０」以外の「１」等の場合、即ち、対応するテーブルＩＤのテーブルに関連付けたテーブルがある場合、そのテーブルＩＤ及び枝番（複合キー）により、読込対象のデータを格納する各テーブルのデータ定義（即ち、当該テーブルのデータ項目）が一意に特定される。この場合、テーブルＩＤは、それらの関連付けた複数のテーブル群を一意に示すＩＤとなる。或いは、枝番は、管理対象データのレコードが階層構造を有する場合に利用することもできる。例えば、受発注業務における発注データのように、「ファイルヘッダレコード（上位階層）」、「伝票ヘッダレコード（中位階層）」、「伝票明細行レコード（下位階層）」からなる３階層のデータ構造を有する場合、最上位階層の「ファイルヘッダレコード」の各データ項目（各フィールド）には最上位の値（例えば、「１」）を、その次の階層の「伝票ヘッダレコード（中位階層）」の各データ項目には最上位の値の下位であることを示す中位の値（例えば、「２」）を、その次の階層の「伝票明細行レコード（下位階層）」の格データ項目には中位の値の更に下位であることを示す最下位の値（例えば、「３」）を割り当てて格納し、データ内におけるレコードの階層を識別できるようにすることもできる。なお、２階層構造や４階層以上の構造の場合にも同様にして「階層」に値を格納することができるが、上記以外にも、各階層を識別する任意の値を割り当てて格納することができる。更に、全てのテーブルについて、関連付けてグループ化される他のテーブルがない場合は、枝番のデータ項目を省略してもよい。
図９の列ＩＤは、上記図１〜図３の列ＩＤに対応するものであり、前記データ種類、テーブルＩＤ及び枝番を複合したものの末尾に、各テーブルの各データ項目を一意に特定するコード（連番の数字やアルファベット等）を予め割り当てて構成されている。具体的には、図９の例では、テーブルＩＤ「商品マスタテーブル」のデータ項目名「商品ＩＤ」に割り当てた列ＩＤ「１２０１００１」の場合、データ種類「１２０１」、テーブルＩＤ「商品マスタ」及び枝番「０」を複合したもの（１２０１０）の末尾に、当該データ項目を一意に示す数字（０１）を付加して構成される（結果、１２０１＋０＋０１＝１２０１００１となる）。なお、上記のように、図９の列管理テーブルでは、説明の便宜上、テーブルＩＤは、実際のコードではなくテーブル名として例示されているため、列ＩＤにはテーブルＩＤ部分は反映（付加）されていない。しかし、実際には、例えば、商品マスタのテーブルＩＤを「１０」とした場合、列ＩＤは、１２０１（データ種類）＋１０（テーブルＩＤ）＋０（枝番）＋０１（連番）＝１２０１０１００１となる。また、連番は、管理対象データの各レコード（例えば、商品マスタテーブルの各レコード）について、当該レコード内におけるデータ項目（フィールド）の出力順序や表示順序を示すものである。例えば、商品マスタテーブルの場合、そのデータ項目である「商品ＩＤ」、「商品名」、「単価」・・・の項目値の出力順序に対応して、連番の値として「１」、「２」、「３」・・・（連続値）が格納される。ここで、図９の例では、列ＩＤの末尾の数字と連番の数字が一致しているが、これは、列ＩＤの末尾に連番の値を割り当てることを意味するものではない。即ち、列ＩＤの末尾の数字乃至コードは、同一のデータフォーマットを有するレコードの各データ項目に対して一意に割り当てられものであり、必ずしも、当該レコードのデータ項目値の出力順序と一致しない。例えば、当該レコードのデータ項目を追加、削除、変更した場合、これに対応して、列ＩＤも追加、削除、変更されることになるため、当該レコード内における列ＩＤの末尾の数字は、必ずしも、当該レコードのデータ項目の並び順を示すものではない。これに対し、連番は、当該レコードのデータ項目の並び順に完全に対応し、当該並び順でデータ項目値を出力するために使用される。ただし、列ＩＤの末尾に連番を自動的に付与して各読込レコードの項目値を特定することも無論可能であり、この場合、列ＩＤ自体の管理は容易となる。しかし、その後のデータ項目の追加、削除、変更等の保守を容易化する等の点から、各読込レコードの項目値を一意に特定するために列ＩＤの末尾には、連番と無関係なコードを付与することが好ましい。次に、「データ項目名」は各列ＩＤに対応付けたデータ項目の名称を、「データ型」は当該データ項目のデータ型を、「位置」は当該データ項目のレコード先頭からの位置（何バイト目か）を示す。また、「最大長」及び「最小長」は当該データ項目の最大バイト数及び最小バイト数を格納する。
このように、図９の列管理テーブルは、図４〜図８の各テーブルのデータ項目（カラム）の項目名（「商品ＩＤ」、「商品名」・・・）を、順番に、自身のデータ項目としてではなく、データ項目値として格納する。また、列管理テーブルは、各テーブルのデータ項目の各値（データ項目名）に対応して、データ種類の値（「１２０１」、「１２０１」・・・）、テーブルＩＤの値（「商品マスタ」・・・）、枝番の値、連番の値（「１」、「２」・・・）、列ＩＤの値（「１２０１００１」、「１２０１００２」・・・）等を格納する。即ち、本事例では、管理対象の全てのテーブルのデータ項目が、一つの列管理テーブル内にデータ項目値として定義して格納される。これにより、一つの列管理テーブルを使用して、全ての管理対象データのデータフォーマット（全テーブルのデータ定義乃至スキーマ）を解析、参照、判断等することができる。
図１０は本発明の実施の形態１に係るデータ管理システムの行管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで、行管理テーブルに所定のデータを格納した状態を示す。
図１０に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムでは、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに、当該読込レコードに一意のインデックス（行ＩＤ）を付与すると共に、当該読込レコードから識別子を取得して、それらを行管理テーブルに格納する。詳細には、行管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「識別子名」、「識別子値」等を定義している。このうち、行ＩＤは、上記のように、管理対象データの読込レコード（１レコード）ごとに自動生成される一意の（ユニークな）ＩＤであり、任意のコード（英数字等）から構成することができる。なお、図１０の例では、「行ＩＤ」の値として「ＳＹＳ００１」、「ＳＹＳ００２」・・・という英数字の組合せを使用しているが、行ＩＤの値は、各読込レコードを一意に識別可能であればよく、例えば、データの読込日時（年月日時分秒）等の任意のコードから構成することができる。また、図１０の行管理テーブルの「データ種類」及び「テーブルＩＤ」は、図９の列管理テーブルの「データ種類」及び「テーブルＩＤ」に対応する。即ち、行管理テーブルは、読込レコードに固有の（列管理テーブルにより定義された）データ種類の値及びテーブルＩＤの値を各行ＩＤに対応付けて格納している。更に、行管理テーブルの識別子名は、読込レコードから取得した識別子（商品ＩＤ等）の名称であり、識別子値は当該識別子の値である。例えば、行管理テーブルは、商品マスタデータを読込む場合、識別子として、各読込レコード内の商品ＩＤ、即ち、商品テーブルの各行に格納された一意の商品ＩＤ（「４９０１」、「４９０２」等）を格納する。商品ＩＤをこの識別氏は、行ＩＤに１対１の関係で対応付けられている。よって、行管理テーブルを参照することで、特定の識別子を有する各読込レコード（格納レコード）が、どの行ＩＤを有するかを容易に特定することができる。なお、読込レコードのインデックスが複合キーからなる場合（例えば、顧客単価テーブルのように、商品ＩＤ＋企業コードからなる場合)、行管理テーブルに格納する識別子も、当該複合キーからなる識別子とする。
ここで、図１０の例では、行管理テーブルは、読込レコードのデータ項目のうち、当該レコード自体の識別子でもある「インデックス名」（商品マスタデータの商品ＩＤ「４９０１」等）を格納している。しかし、行管理テーブルは、各読込レコードに対して一意に付与される行ＩＤを少なくとも格納すればよい。即ち、行管理テーブルは、識別子を格納しない構成とすることも可能である。一方、行管理テーブルは、読込レコードのデータ項目値（フィールド値）のうち、識別子として利用する項目値以外にも、代表的（基本的）なもの（基本項目値）を格納するようにしてもよい（例えば、商品マスタテーブルの商品名、単価等）。こうすると、これらの基本項目値を行管理テーブルから抽出し、出力情報として迅速に出力することができ、データ出力に活用することができる。即ち、この場合、行管理テーブルは、識別子に加えて、読込レコードの１以上の基本項目値を格納し、所望の基本項目値を行ＩＤや識別子等を検索キーとして抽出し、所望のフォーマット（表示形式）で出力（印刷、画面表示）等することにより、そのデータの活用を図ることができる。この場合、列管理テーブルにおいて、項目値として格納した各管理対象データのデータ項目のいずれか１以上を、「基本項目値」としてフラグ等により指定することにより、各データのレコード読込時に指定した基本項目値を自動抽出するようにすることができる。例えば、列管理テーブルに、基本項目値としての順番を指定する「基本項目値指定順序」をデータ項目として定義し、列管理テーブルに格納した管理対象データのデータ項目のうち、基本項目値として利用したいものに対し、「基本項目値指定順序」の値としての連番（「１」、「２」・・・）を付与する。
図１１は本発明の実施の形態１に係るデータ管理システムの第１の具体例の値管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで全ての値を格納した状態を示す。
図１１に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムは、値管理テーブルとして例えば図１１の構成を採用する。この第１の具体例の値管理テーブルによれば、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに（詳細には、１レコードの１フィールドずつ読込むごとに）、当該読込レコードに前記行ＩＤ及び前記列ＩＤ等が付与され、読込んだデータ項目値が、それら行ＩＤ及び列ＩＤに対応付けられて行管理テーブルに格納される。詳細には、図１１の値管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「列ＩＤ」、「値」等を定義している。「行ＩＤ」は、前記行管理テーブルの「行ＩＤ」に対応し、「データ種類」、「テーブルＩＤ」及び「列ＩＤ」は、前記列管理テーブルの「データ種類」、「テーブルＩＤ」及び「列ＩＤ」に対応する。そして、上記のように、管理対象データの各レコードを読込むごとに、当該レコードに一意の行ＩＤが発行付与されて行管理テーブルに順に格納されるが、これと同時に、各読込レコードの全フィールド値（全項目値）に対し、当該読込レコードの行ＩＤ（ＳＹＳ００１、ＳＹＳ００２・・・）が対応して格納される。なお、当然、同一読込レコードについては、全てのフィールド値（項目値）に対して同一の行ＩＤが付与される。
また、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列管理テーブルに定義した当該読込レコードのデータフォーマット（管理対象データのデータ定義）にしたがって、読込レコードのフィールド値（項目値）が、定義された当該管理対象データのデータ項目に１対１で対応付けられ、順番に値管理テーブルの値として格納される。そして、当該格納レコード（各行に格納された項目値乃至フィールド値）に対して、対応する列ＩＤの値が付与されて格納される。例えば、商品マスタデータのレコード読込時には、列管理テーブルの商品マスタ部分が参照され、当該部分の列ＩＤ（「１２０１００１」、「１２０１００２」、「１２０１００３」・・・）に基づき、読込レコードのフィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、列管理テーブルに定義したデータ項目（「商品ＩＤ」、「商品名」、「単価」・・・）と対応付けて分割され、行管理テーブルの各行の値として格納される。このように、図１１の第１の具体例に係る値管理テーブルでは、一行に一つの値（フィールド値）を格納するようにしている。一方、上記のように、列ＩＤの末尾に連番を自動的に付与して読込レコードの項目値を一意に識別するようにした場合、列管理テーブルの読込レコード対応部分が参照され、当該部分の列ＩＤの末尾の連番（「１」、「２」、「３」・・・）の順番で、（詳細には、当該列ＩＤを構成するデータ種類＋テーブルＩＤ＋枝番＋連番のうちの連番を参照してその連番の順番で）、読込レコードのフィールド値が、列管理テーブルに定義したデータ項目と対応付けて分割され、各行の値として格納される。このように、図１１の第１の具体例に係る値管理テーブルでは、一行に一つの値（フィールド値）を格納するようにしている。また、この第１の具体例は、行管理テーブルの行ＩＤと列管理テーブルの列ＩＤとにより一意に決定されるセル（一つの値セル）に、対応する読込レコードのフィールド値（データ項目値）を格納するものとして把握することもできる。なお、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列ＩＤ以外にも、上記データ種類やテーブルＩＤが対応付けて格納されるが、これらデータ種類やテーブルＩＤの格納は省略することもできる。
図１２は本発明の実施の形態１に係るデータ管理システムの第２の具体例の値管理テーブルに、図４〜図８の従来のテーブル格納データを読込んで全ての値を格納した状態を示す。
図１２に示すように、実施の形態１に係るデータ管理システムを適用した売上管理システムは、値管理テーブルとして例えば図１１の構成を採用する。この第１の具体例の値管理テーブルによれば、売上管理システムが図４〜図８に示す従来の商品テーブル、顧客テーブル、顧客単価テーブル、在庫管理テーブル、販売管理テーブルの各格納データを、各テーブルから１レコードずつ読込むごとに（詳細には、全フィールドからなる１レコードを読込むごとに）、当該読込レコードに前記行ＩＤと前記データ種類及びテーブルＩＤとを付与して、各読込レコードの全てのデータ項目値（フィールド値）を一行に格納するものである。詳細には、図１２の値管理テーブルは、データ項目（カラム乃至属性）として、「行ＩＤ」、「データ種類」、「テーブルＩＤ」、「列ＩＤ」、「値」等を定義している。「行ＩＤ」は、前記行管理テーブルの「行ＩＤ」に対応し、「データ種類」、「テーブルＩＤ」及び「列ＩＤ」は、前記列管理テーブルの「データ種類」、「テーブルＩＤ」及び「列ＩＤ」に対応する。そして、上記のように、管理対象データの各レコードを読込むごとに、当該レコードに一意の行ＩＤが発行付与されて行管理テーブルに順に格納されるが、これと同時に、各読込レコードに対し、当該読込レコードの行ＩＤ（ＳＹＳ００１、ＳＹＳ００２・・・）が対応して格納される。
また、管理対象データの各レコードの読込時には、列管理テーブルが参照され、列管理テーブルに定義した当該読込レコードのデータフォーマット（管理対象データのデータ定義）にしたがって、読込レコードのフィールド値（項目値）が、定義された当該管理対象データのデータ項目に１対１で対応付けられ、順番に値管理テーブルの値として格納される。そして、当該格納レコードの全ての項目値乃至フィールド値に対して、対応するデータ種類及びテーブルＩＤの値が付与されて格納される。例えば、商品マスタデータのレコード読込時には、列管理テーブルの商品マスタ部分が参照され、当該部分のデータ種類（「１２０１」）及びテーブルＩＤ（「商品マスタ」）に基づき、読込レコードの全フィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、行管理テーブルの値に一連で格納される。このとき、上記第１の具体例の値管理テーブルの場合のように、列管理テーブルの列ＩＤを参照して、読込レコードのフィールド値を分割して、値管理テーブルの一行の値の各格納部（分割区域）にそれぞれ格納することができる。また、このとき、列ＩＤを参照し、読込レコードのフィールド値（「４９０１」、「たばこ」、「２００円」・・・）が、列管理テーブルに定義したデータ項目（「商品ＩＤ」、「商品名」、「単価」・・・）と対応付けて格納される。このように、図１２の第２の具体例に係る値管理テーブルでは、一行に一つのレコード（全フィールド値）を格納するようにしている。また、この第２の具体例は、行管理テーブルの行ＩＤと列管理テーブルのデータ種類及びテーブルＩＤとにより一意に決定される一つのセル（「値」の各セル）に、対応する読込レコードの全フィールド値（全データ項目値）を格納するものとして把握することもできる。即ち、データ種類及びテーブルＩＤにより、各読込レコードのデータフォーマット（詳細には、各読込レコードの全データ項目）を特定することができ、データ種類及びテーブルＩＤを、各読込レコードのデータフォーマットを特定するためのＩＤ（複合キー）として使用することができる。なお、第２の具体例の値管理テーブルでは、一行に全てのフィールド値を格納するため、前記列テーブルの「連番」はデータ項目として不要である。また、値管理テーブルの列ＩＤは、各行の読込レコード単位では関連付けられていないため、値として「ＮＵＬＬ」が自動的に格納されている。
実施の形態２
図１３は本発明の実施の形態２に係るデータ管理システムとしての受発注管理システムの構成を概略的に示すブロック図である。図１４は本発明の実施の形態２に係るデータ管理システムを受発注管理システムに具体化した場合のデータ構造を概略的に示す説明図である。
実施の形態２に係るデータ管理システムは、上記実施の形態１に係るデータ管理システムを、受発注管理システム２０に具体化したものである。受発注管理システム２０は、前記列管理テーブル１１に相当する列管理テーブル２１と、前記行管理テーブル１２に相当する行管理テーブル２２と、前記値管理テーブル１３に相当する値管理テーブル２３とを備える。なお、受発注管理システム２０は、各発注企業について、発注企業が送信する発注データ、受領データ、支払いデータ等の送信データ（送信レコード）のデータフォーマットをマスタデータとして格納する企業別のテーブル管理テーブル（図１３では図示略）と、各発注企業の送信データを、標準データフォーマットまたは受注企業のデータフォーマットのデータに変換するためのリンク情報を格納するデータ交換管理テーブル（図１３では図示略）とを更に備える構成としても良い受発注管理システム２０は、発注企業の送信データ、例えば、データフォーマットが異なる複数企業の発注データ（図１３では甲社発注データ３１、乙社発注データ３２を例示）を取り込むと、列管理テーブル２１において該当する企業のデータ定義（データフォーマット）を参照し、行管理テーブル２２に当該発注データの各読込レコードの識別子を行ＩＤと共に格納すると共に、値管理テーブル２３に読込レコードの全項目値を行ＩＤ及び列ＩＤと共に格納する。即ち、受発注管理システム２０は、列管理テーブル２１に定義された該当企業の発注データの各レコードのデータフォーマットにしたがって、当該企業の発注データ（甲社発注データ３１、乙社発注データ３２）を整形（分割、並び替え等）する。そして、受発注管理システム２０は、発注データ３１〜３２の一レコードを読み込むごとに、当該読込レコードに行ＩＤを発行すると共に、当該読込レコードに含まれるインデックスデータ（例えば伝票ＮＯ．や伝票明細行ＮＯ．）を識別子として行管理テーブルに格納する。このとき、上記のように、受発注管理システム２０は、読込レコードのそれ以外の基本項目値（例えば、商品名、発注数量等）を行管理テーブル２２に格納してもよい。また、受発注管理システム２０は、発注データ３１〜３２の一レコードを読み込むごとに、列管理テーブルに定義した当該読込レコードのデータフォーマットにしたがって、当該読込レコードの全データ項目値を値管理テーブル２３に格納すると共に、当該読込レコードに行ＩＤ及び列ＩＤを付与する。このとき、上記のように、値管理テーブル２３の一行に各読込レコードの一項目値を格納する場合は、各行に一意の列ＩＤが割り当てられる。一方、値管理テーブル２３の一行に各読込レコードの全項目値を格納する場合は、各行に一意の列ＩＤは割り当てられず、当該読込レコードのデータフォーマットを特定できるコード情報（データ種類＋テーブルＩＤ等）が割り当てられる。
一方、受発注管理システム２０は、送信データとして、例えば、データフォーマットが異なる複数企業の納品予定データ（図１３では丙社納品予定データ３３、丁社納品予定データ３４を例示）を取り込むと、上記発注データの場合と同様にして、列管理テーブル２１において該当する企業のデータ定義（データフォーマット）を参照し、行管理テーブル２２に各読込レコードの識別子を行ＩＤと共に格納すると共に、値管理テーブル２３に読込レコードの全項目値を行ＩＤ及び列ＩＤと共に格納する。ここで、受発注管理システム２０は、前記行管理テーブル２２や値管理テーブル２３に格納した項目値を所望の複数の表示フォーマットで表示または出力する単一の表示（出力）プログラム（ＰＧ）を備えている。そして、受発注管理システム２０は、ユーザーの要求にしたがって、列管理テーブル２１の定義情報を参照して、行管理テーブル２２に格納した識別子をキーとして、行管理テーブル２２に格納した基本項目値（伝票ＩＤ、梱包ＩＤ等）を抽出し、所定のフォーマットで出力（モニタ画面１に表示等）する。また、受発注管理システム２０は、ユーザーの要求にしたがって、列管理テーブル２１の定義情報を参照して、値管理テーブル２３に格納したデータ項目値（伝票明細、梱包明細等）の必要な項目値を抽出し、所定のフォーマットでモ出力（モニタ画面１に表示等）する。
ここで、受発注管理システム２０の具体的なテーブル構造を説明すると、図１４に示すように、受発注管理システム２０は、上記図２及び図３により説明した実施の形態１の場合と同様のデータ処理により、送信データ（発注データ等）のデータフォーマットにしたがって、当該送信データの各データ項目（データ定義）を、列管理テーブル２１にデータ項目値として格納している。また、受発注管理システム２０は、トランザクションデータとして、行管理テーブル２２に、行ＩＤ、識別子等を格納し、値管理テーブル２３に、伝票明細ＩＤ、商品ＩＤ、商品名等の全データ項目値を格納している。そして、受発注管理システム２０は、表示（出力）プログラム２６により、列管理テーブル２１の定義情報を参照して、行管理テーブル２２に格納した基本項目値（伝票Ｎｏ．等）を所定フォーマットで出力したり、値管理テーブル２３に格納した全データ項目値のうちの必要な項目値（商品ＩＤ、商品名等）を出力したりする。即ち、このとき、受発注管理システム２０は、表示（出力）プログラム２６により、発注データの場合は、図１３に示す受注一覧テーブル３５、受注明細テーブル３６等に所定のフォーマットで所定の項目値を表示し、納品予定データの場合は、図１３に示す納品予定テーブル３７、梱包明細テーブル３８等に所定のフォーマットで所定の項目ちを表示する。なお、これ以外にも、受発注管理システム２０は、表示（出力）プログラム２６により、各種テーブルを表示することもできる。例えば、伝票一覧テーブル（図示略）は、行管理テーブル２２に格納した基本項目値（伝票ＮＯ．発注日等）のみを使用して、伝票一覧を迅速に表示する。また、伝票明細表示テーブル（図示略）は、伝票一覧テーブルの任意の行を選択実行することにより、その行の伝票ＩＤに対応する伝票明細行の各種項目値を値管理テーブル２３から抽出し、その行の伝票番号の伝票明細の詳細を表示する。ここで、行管理テーブル２２からのデータ項目値の抽出のためのキーとしては、識別子以外に、行ＩＤを使用することもできる。
詳細には、図１４に示すように、受発注管理システム２０において、列管理テーブル２１は、図１４に示すデータを管理対象とする場合、甲社発注データのデータ項目（伝票ＩＤ、ＧＴＩＮ、商品名、個数）、乙社発注データのデータ項目（伝票ＩＤ、ＧＴＩＮ、個数、納期）、丙社発注データのデータ項目（伝票ＩＤ、商品ＩＤ、個数、単価）、丁社発注データのデータ項目（伝票ＩＤ、商品名、商品ＩＤ、個数）を一意の列ＩＤ（１，２，３，４・・・）に対応付けて格納している。また、図１４の各テーブル中、属性名の右横のカッコ内の英字（アルファベット）が同一のものは、データ項目が同一であることを意味する。これにより、列管理テーブル２１を参照することで、管理対象データのテーブル名に加えて、当該テーブルのデータ項目を判断することができる。例えば、甲社発注データについては、列ＩＤの「１〜４」に対応して、属性名として「伝票ＩＤ、ＧＴＩＮ、商品名、個数」が定義されているため、列ＩＤの「１〜４」を参照することで、管理対象データのテーブルが「甲社発注データ」であると判断でき、かつ、甲社発注データのデータ項目が「伝票ＩＤ、ＧＴＩＮ、商品名、個数」であると判断することができる。
また、受発注管理システム２０は、管理対象データの各レコードを読み込むごとに、行管理テーブル２２に一意の行ＩＤを割り当てて格納すると共に、当該読込レコードの特定のデータ項目値を識別子として格納する。例えば、甲社発注データのレコード（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード）を読み込む場合、行管理テーブル２２には、甲社発注データのレコード（一行）を読込むごとに行ＩＤ（１，２・・・）が発行され、行ＩＤに対応して読込レコードの特定の項目値が識別子として格納される。例えば、商品テーブルに関しては、伝票ＩＤ（甲１，甲２・・・）を識別子として行管理テーブル２２に格納することができる。なお、他のデータについても、同様に、各読込レコードに一意の行ＩＤが付与されると共に、各読込レコードの特定の項目値が識別子として取得され、行ＩＤと対応付けて格納される。
更に、受発注管理システム２０は、管理対象データの各レコードを読み込むごとに、各読込レコードをデータ項目の項目値ごとに分割し、分割したデータ項目値の全てに同一の行ＩＤを割り当てると共に、分割したデータ項目値に対応する列ＩＤを順に割り当てて、行ＩＤ、列ＩＤ及び値のセットで格納する。例えば、甲社発注データのレコード（「甲１、４９００１，ガム，１００」、「甲２、４９００２，飴，２０」・・・）を読み込む場合、受発注管理システム２０は、まず一行目のレコード（甲１、４９００１，ガム，１００）のデータ項目値を分割し、それら４つのデータ項目値に行ＩＤ（１）を割り当てると共に、それら４つのデータ項目値に対して列ＩＤ（１〜４）を順に割り当て、それらのデータセット（「」１，１，甲１、「１，２，４９００１」、「１，３，ガム」、「１，４，１００」を値管理テーブル２３に格納する。なお、他のデータについても、同様に、各読込レコードに一意の行ＩＤが付与される。２行目以降のレコードについても、各レコード読込時に、同様にして、行ＩＤ、列ＩＤ及び値の組が値管理テーブル２３に格納される。なお、他のデータについても、同様に、読込レコードの各データ項目値が、行ＩＤ及び列ＩＤと対応付けて格納される。
図１５は本発明の実施の形態２に係るデータ管理システムでデータ交換される発注データのデータ構造を示す説明図である。図１６は本発明の実施の形態２に係るデータ管理システムで使用する列管理テーブルの概略を示す説明図である。図１７は本発明の実施の形態２に係るデータ管理システムにより、発注データのレコードと、列管理テーブルに定義した当該発注データの各データ項目の属性との対応関係を示す説明図である。
図１５に示すように、入力データのレコードは、基本的に、ファイルヘッダ、伝票ヘッダ、伝票明細の３階層、或いは、ファイルヘッダ、伝票ヘッダの２階層で構成されている。この階層構造の関連付けは、入力データ内のレコードシーケンスによって示される為、本データ管理システムでは、この情報を、伝票ヘッダ単位にロー（ＲＯＷ）レコード（行管理テーブルにおける一行単位のレコード）を作成し、後述する列管理テーブルに各レコードの階層や親子関係を定義することで確保している。
また、図１５に示すように、本データ管理システムは、入力データを、レコード単位（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細レコード）に区切りながら順番に読込み、読込んだレコード内のレコード識別子を、後述するテーブル管理テーブルの制御情報を参照して判別し、読込レコード単位で行管理テーブルのレコードを新しく作成している。なお、読込レコードが伝票ヘッダレコードである場合に、行管理テーブルのレコードを新しく作成（キーＲＯＷ＿IDをインクリメント）し、論理的な伝票データ１枚分を格納する基礎レコードとしてもよい。この場合、行管理テーブルの１レコードは、論理的な伝票単位に作成される。なお、入力データの構造は、1レコード＝１伝票という単純な構造ではなく、１レコード＝複数伝票、複数レコード＝１伝票という場合もある。
列管理テーブルの別の一例を参照して説明すると、図１６に示すように、各種データを構成する各々のレコードは、企業が定めた独自フォーマットで作成されている。本データ管理システムでは、企業ごとに異なる独自フォーマットの内容を、列ＩＤ、テーブルＩＤ、連番（シーケンスＮｏ．）、項目名称、データ型、長さ等、データ項目単位で定義を行い、レコード単位にまとめてデータベースに格納している。図１６において、テーブルＩＤは、１０桁等の所定桁の企業別のデータフォーマット（即ち、管理対象となるテーブルのデータ定義）を一意に示す番号である。例えば、テーブルＩＤ＝企業ＩＤ（６桁）＋データ種類（２桁）＋任意の番号（２桁）で構成される。なお、任意の番号としては、前記「枝番」等を使用することができる。また、列ＩＤは、例えば１２桁の企業別のデータフォーマットを有する一レコード内の各データ項目を一意に示す番号である。例えば、列ＩＤ＝テーブルＩＤ（１０桁）＋任意のＮｏ（２桁）とすることができる。この場合、任意の番号としては、各データ項目に一意に割り当てた数字やアルファベットを使用することができる。本データ管理システムでは、電子商取引のある発注企業と受注企業との間で送受信される各種データを、先ずレコード単位に区切って順番に読み込み、テーブル管理テーブルを参照して、この企業別のデータフォーマットの内容を判断し、特定企業のデータフォーマットに合致したレコードを、列管理テーブルを参照してデータ項目毎に分解し、その値を取得して、行管理テーブルや値管理テーブルに格納する。このように、データ管理システムは、各発注企業が使用する独自のデータフォーマットを列管理テーブルに定義するが、更に、受注企業別に異なる（受注企業が必要とする）独自データフォーマットの内容も列管理テーブルに定義する。更にまた、データ管理システムは、本データ管理システム独自の標準フォーマット（或いは、ｅｂＥＸＭＬ等で提唱される標準フォーマット）の内容を列管理テーブルに定義する。本データ管理システムには、上記のように、３種類のデータフォーマット、即ち、絵種類の企業別データプロファイル（発注企業データプロファイル、受注企業データプロファイル、標準データプロファイル）を列管理テーブルに定義している。
図１７に示すように、本データ管理システムは、発注企業との間での送受信データを対象として、当該データについて１レコードずつ格納するポイントを定めて値管理テーブルに格納し、一部の項目値は行管理テーブルにも格納するが、実際は、図１７のレコードを構成するデータ項目に示すように、１レコードのデータを構成するデータ項目値（フィールド値）に分割して格納している。この方法によれば、重要なデータを効率良く格納し、かつ正確に取得することを実現するものであり、企業別データプロファイルを利用したデータの再変換や、障害時の迅速な伝票単位のデータ抽出に対応ができるし、また、電子帳簿保存法にも対処が可能となる。
図１８は本発明の実施の形態２に係るデータ管理システムに外部から発注データを取り込んで、当該発注データを行管理テーブル及び値管理テーブルに格納するデータ格納手順におけるデータフローを示すブロック図である。
図１８に示すように、本データ管理システムにおけるデータ格納手段４０は、受信データをデータベースに格納するため、発注企業より受信した入力データ（順次アクセスファイル）を解析し、各レコードの各データ項目値を抽出後、リレーショナルデータベースの値管理テーブル２３に格納している（一部は行管理テーブル２２にも格納）。即ち、まず、図１６に示すように、管理対象となる全てのレコードのデータフォーマットは、それぞれ、列管理テーブル２１に定義されている。各レコードは複数のフィールド（データ項目）の集まりであり、レコードはテーブルＩＤで一意に識別され、レコードを構成する各フィールドは、列ＩＤ、または、テーブルＩＤ単位の連番（シーケンスＮＯ．）で一意に識別される。そして、本データ管理システムは、読込んだ物理レコードを、合致するデータフォーマットの定義（図１６の列管理テーブル参照）を参照して分割し、各読み込みレコードのフィールド値を格納する。このとき、上記のように、システムのパフォーマンス（主に処理速度）向上を図るため、本来１フィールド値を１レコード（値管理テーブルの各行）に格納する以外に、本データ管理システムでは、１フィールド単位ではなく、１フォーマット定義単位（列管理テーブルのテーブルＩＤ単位）で全フィールド値をまとめて格納できるようにすることもできる。即ち、本来、値管理テーブルにおいて、列ＩＤと行ＩＤとの組み合わせで一意に決定される一つのセルに１フィールド値を格納する処を、テーブルＩＤと行ＩＤ）との組み合わせで一意に決定されるセルに複数のフィールド値をまとめて格納することもできる。しかし、物理的には１レコードに格納できるフィールドは有限個（例えば、３０個）とする為、該当するデータフォーマットの定義を構成するフィールドが有限個（３１）以上の場合は、当該テーブルのレコードを新たにひとつ増やして格納する必要が生じる。この場合、本データ管理システムは、後述するようなセルシーケンスＮＯ．を設ける事でデータ分割に対処することができる。
図１８では、データ管理システムは、発注データ３１の受信時（読込時）に、まず、データ交換管理テーブル２５を参照し、その発注データ３１について発注企業と受注企業との間での取引（受発注業務）が予定されているかどうかを判断し、取引が予定されている場合のみ、発注データ３１の読込を実行する。次に、データ管理システムは、上記のようにして、テーブル管理テーブル２４において当該企業の発注データに関するテーブルＩＤを参照して、発注データ３１をレコード単位に分割して読込む。図１８のデータ格納手段４０内に読込まれた発注データ３１は、レコード単位、即ち、ファイルヘッダレコード（ＦＬ２０・・・）、伝票ヘッダレコード（ＤＨ２０・・・）、複数の伝票明細行レコード（ＤＤ２０ 砂糖 ・・・、ＤＤ２０チョコレート・・・）に分割されている。次に、データ管理システムは、列管理テーブル２１を参照し、当該発注企業のデータフォーマットに従って、発注データ３１の各読込レコードを項目値ごとに分割し、各読込レコードの識別子等を対応する一意の行ＩＤと共に行管理テーブル２１に格納する一方、各読込レコードの全項目値を対応する行ＩＤ及び列ＩＤ（またはテーブルＩＤ等の一レコードを特定するための情報）と共に値管理テーブル２３に格納する。なお、上記図１５の例では、読込レコードが伝票ヘッダレコードである場合に、行管理テーブルのレコードを新しく作成し、論理的な伝票データ１枚分を格納する基礎レコードとし、行管理テーブルの１レコードを、論理的な伝票単位に作成する事例を説明した。しかし、データ管理システムは、行ＩＤとして、管理対象データの各レコードを読込むごとに自動的に生成・付与されるインデックスを使用する場合、上記のように伝票ヘッダレコード単位ではなく、全てのレコード単位（ファイルヘッダレコード、各伝票ヘッダレコード、各伝票明細行レコード単位）で、行ＩＤを自動生成し、行管理テーブルの各行のインデックスとして格納する。一方、列ＩＤは、図１６及び図１７に示すように、１２桁の数字（０１２３・・・）により上記規則に則り作成され、管理対象データ（受発注データ）のレコード（ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード等）の各データ項目（ファイルヘッダレコードの場合、レコード区分、ファイル種別、データ作成日等、伝票ヘッダレコードの場合、レコード区分、店舗コード、部門コード等、伝票明細行レコードの場合、レコード区分、品名、規格等）に一意に割り当てて使用される。
図１９は本発明の実施の形態２に係るデータ管理システムにより発注企業データプロファイルと受注企業データプロファイルとを標準データプロファイルを介してデータ交換する場合の手順を概略的に示す説明図である。図２０は本発明の実施の形態２に係るデータ管理システムにより、発注企業データの所定の項目値を表す発注企業データプロファイルの所定の列ＩＤから、当該発注企業データの項目値に対応する標準データの項目値を表す標準データプロファイルの所定の列ＩＤを介して、当該標準データの項目値に対応する受注企業データの項目値を表す受注データプロファイルの所定の列ＩＤを取得する手順を概略的に示す説明図である。
データの変換方法について説明すると、図１９に示すように、本データ管理システムは、発注企業別データプロファイルと、受注企業別データプロファイルと、標準データプロファイルとの３種類の企業別データプロファイルを列管理テーブルに定義している。この企業別データプロファイルは、電子商取引で交換される各種データを構成するレコードの其々について、その最小要素であるデータ項目の属性を細かく定義したものであり、マッピング作業を行うためのものである。標準フォーマットを使用したＥＤＩは、フォーマット変換作業のコスト削減を図る上では理想的である。したがって、本データ管理システムにおいても、発注企業別データプロファイルと標準データプロファイルとの間でマッピング作業を行い、かつ、標準データプロファイルと受注企業別データプロファイルとの間でマッピング作業を行う。こうすることにより、図１９のデータ変換概要に示すように、発注企業別データプロファイルと受注企業別データプロファイルとの間のマッピング作業を行わずに、標準データプロファイルを介して、発注企業別データプロファイルと受注企業別データプロファイルとの間の各データ項目間の関連情報を取得し、データ変換を実現することができる。また、図２０は、企業別データプロファイルの各データ項目間の関連情報が実際に格納されているテーブル（項目関連定義テーブル）の内容を概略的に示す。ここで、列ＩＤは、所定桁（例えば、１２桁）のデータ項目レコードを一意に示す番号である。
図２０の例では、発注企業（企業コード＝１１１１１１）から受信した発注データ（データ種類コード＝２０）を構成するファイルヘッダ・レコード(テーブルＩＤコード＝１１１１１１２０１０)の３番目のデータ項目（列ＩＤ＝１１１１１１２０１００３）を、標準（企業コード＝００００００）データプロファイルの発注（データ種類コード＝２０）ファイルヘッダ・レコード（テーブルＩＤコード＝２０１０）の４番目のデータ項目（列ＩＤ＝２０１００４）を仲介して、受注企業（企業コード＝９９９９９９）の受注データ（データ種類コード＝２０）のファイルヘッダ・レコード（テーブルＩＤコード＝９９９９９９２０１０）の２番目のデータ項目（列ＩＤ＝９９９９９９２０１００２）にデータ交換する際の処理の流れが示されている。図２０の表の右端のデータ変換関数は、データ変換をする際に使用される変換関数であるが、本データ管理システムでは、あらゆるデータ変換に対応できるよう、多くの関数が用意されている。図２０では、関数コード「１」はデータ格納を示し、前記発注企業の読込データ（発注データ）において列ＩＤ「１１１１１１２０１００３」を有するデータ項目の値（値管理テーブルに実際に格納された格納値）を、標準プロファイルの列ＩＤ「２０１００４」に格納し、当該標準プロファイルの列ＩＤ「２０１００４」に格納した前記データ項目の値を、前記受注企業が指定した形式（プロファイル乃至フォーマット）のデータにおいて列ＩＤ「９９９９９９２０１００２」を有するデータ項目の値として取得するという処理が、前記関数コードを利用して実行される。
図２１は本発明の実施の形態２に係るデータ管理システムによりデータ交換を行う際に、各企業間で項目値の意味や使用方法が異なる場合の処理に使用する項目値管理の概略を示す説明図である。
図２１にしたがって、データ変換時の課題と解決方法について説明する。データ変換をする際には、解決しなければならない様々な課題がある。本データ管理システムでは、これらの課題を以下のように解決する。まず、項目名称（異名同義語）について、発注企業独自のフォーマットには、さまざまなデータ項目名称が付けられている。本データ管理システムでは、これらのデータ項目に実際に代入されている値を検証し、データ項目名称が違っていても、データ項目値が同様と判断されたデータ項目間の関連定義を行っている。例えば、発注番号⇔伝票番号、部門コード⇔分類コードとして関連定義を行う。また、項目内容（同名異義語）については、項目名称の場合とは逆に、同じデータ項目名称であっても、実際の値が違うと判断された場合は、データ項目間に関連定義を行っていない。更に、本データ管理システムでは、商品コードについてはＧＴＩＮ（ＪＡＮコード）を使用することを原則とし、企業コードについては、共通取引先コード、標準企業コード、グローバルロケーションナンバー（ＧｌｏｂａｌＬｏｃａｔｉｏｎＮｕｍｂｅｒ）のいずれかを使用することを原則としている。しかし、ローカルな商品コードと、ローカルな企業コードについては、その変換をすることも可能である。例えば、商品コード（ＪＡＮコード）⇔商品コード（インストア）、企業コード（共通取引先コード）⇔企業コード（インストア）等である。次に、属性（データ型）の違いについては、本データ管理システムでは、データ項目間の関連定義がされている場合、自動的にその属性変換が行われる。原則的に、テキストは左詰め、数値は右詰めで格納される。例えば、数値⇔日付、テキスト⇔数値、日付⇔テキスト等である。次に、表示方法の違い、即ち、データ項目の表示方法については、オプション機能を利用することにより、０（ゼロ）サプレスや小数点位置の表示、区切文字の代入などあらゆる表記方法が可能である。例えば、電話番号：０３（４３２１）１２５６⇔０３−４３２１−１２５６等である。次に、桁数（レングス）の違いについては、長さの違うデータ項目間の関連情報が定義されている場合、データ変換をする際にデータが桁落ちする場合が生じる。本データ管理システムは、データ変換の際、実際のデータ項目値が桁落ちする場合に、警告メッセージを表示する。利用者は、受側のデータ項目の長さを変更して対処することが可能である。
また、本データ管理システムではＧＴＩＮコードに対応しているので、ＪＡＮコードを使用している場合は、頭の１桁に０（ゼロ）を付加して格納する。例えば、ＪＡＮコード（１３桁）⇔ＧＴＩＮコード（１４桁）等である。次に、ドメイン値（項目値の意味）については、データ項目値にコードが代入されている場合、そのコード体系は企業毎に定められている。本データ管理システムでは、これらのコード体系の意味変換を行う為に、さまざまなデータ項目について、その内容のシステム標準を定め、システム標準プロファイルとして格納している。利用者はこの標準プロファイルを介して、データ変換同様、コードの意味変換を行うことが可能である。例えば、Ａ企業の支払方法：１＝翌月、２＝翌々月で、Ｂ企業の支払方法：０＝翌月、１＝翌々月の場合等である。図２１では、９９９９９９２０１００２の支払方法が、ａ：翌月、ｂ：翌々月、ｃ：翌々翌月で、００００００２０１００４の支払方法が、ア：翌月、イ：翌々月、ウ：翌々翌月であり、１１１１１１２０１００３の支払方法が、０：翌月、１：翌々月、２：翌々翌月であり、０⇒ア⇒ａ、１⇒イ⇒ｂ、２⇒ウ⇒ｃとなる。即ち、図２１の項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルでは、受注企業（企業コード＝９９９９９９）の受注データ（データ種類コード＝２０）のファイルヘッダ・レコード（テーブルＩＤ＝９９９９９９２０１０）の２番目のデータ項目（列ＩＤ＝９９９９９９２０１００２）が、当該受注企業の支払方法を表し、そのデータ項目の値として、「ａ」は翌月を、「ｂ」は翌々月を、「ｃ」は翌々翌月を意味する。また、発注企業（企業コード＝１１１１１１）から受信した発注データ（データ種類コード＝２０）を構成するファイルヘッダ・レコード(テーブルＩＤ＝１１１１１１２０１０)の３番目のデータ項目（列ＩＤ＝１１１１１１２０１００３）が、当該発注企業の支払方法を表し、そのデータ項目の値として、「０」は翌月を、「１」は翌々月を、「２」は翌々翌月を意味する。更に、標準（企業コード＝００００００）データプロファイルの発注（データ種類コード＝２０）ファイルヘッダ・レコード（テーブルＩＤ＝２０１０）の４番目のデータ項目（列ＩＤ＝２０１００４）が、当該標準データプロファイルの支払方法を表し、そのデータ項目の値として、「ア」は翌月を、「イ」は翌々月を、「ウ」は翌々翌月を意味する。この場合に、実施の形態２のデータ管理システムは、上記データ変換時に、図２１の項目値管理テーブルを参照して、発注企業プロファイルのデータ項目の値「０」を、標準データプロファイルのデータ項目の値「ア」を介して、受注企業プロファイルのデータ項目の値「ａ」に自動的に変換し、発注企業プロファイルのデータ項目の値「１」を、標準データプロファイルのデータ項目の値「イ」を介して、受注企業プロファイルのデータ項目の値「ｂ」に自動的に変換し、発注企業プロファイルのデータ項目の値「２」を、標準データプロファイルのデータ項目の値「ウ」を介して、受注企業プロファイルのデータ項目の値「ｃ」に自動的に変換する。このように、受注企業の指定した形式のデータのデータ項目値が、発注企業のデータ項目値と異なる意味や異なるコード体系を有する場合でも、標準データプロファイルを介してその相違を吸収することができる。
図２２は本発明の実施の形態２に係るデータ管理システムに新規な発注企業データプロファイル及び当該発注企業プロファイルと標準データプロファイルとのリンク情報を取り込んで、当該新規な発注企業データプロファイルに基づきデータを表示及び出力する場合のプロファイル取り込み・表示・出力手順におけるデータフローを示すブロック図である。
図２２に示すように、実施の形態２に係る受発注管理システム２０のプロファイル取り込み手段５０は、ネット上等に置かれたプロファイル管理システムで逐次作成した新たな企業のデータプロファイルを、ネットワークＮＴを介して、列管理テーブル２１に取得して、列管理テーブル２１を更新する。同時に、新たな企業の（独自の）データプロファイルと標準データプロファイルとの間のリンク情報も、ネットワークＮＴを介して、項目関連定義テーブル２７に取得して格納され、項目関連定義テーブル２７が更新される。即ち、受発注管理システム２０は、項目関連定義テーブル２７を更に備え、発注企業のデータプロファイルと標準データプロファイルとの間の定義リンク情報を格納すると共に、標準データプロファイルと受注企業のデータプロファイルとの間の定義リンク情報も格納する。そして、定義情報及びリンク情報に基づき、行管理テーブル２２や値管理テーブル２３からの項目値が、表示プログラム２６を介して、所定のフォーマットで、モニタ画面１や帳表２に出力される。なお、前記リンク情報５２が更新して格納される項目関連定義テーブル２７は、図２０の項目関連定義テーブルに相当する。即ち、前記リンク情報５２のトリガ列ＩＤは、図２０の企業別データプロファイルの列ＩＤに相当し、リンク情報５２の対象列ＩＤは、図２０の標準データプロファイルの列ＩＤに相当し、リンク情報５２の関数ＩＤは、図２０のデータ変換関数コードに相当する。よって、図２２の例でも、列管理テーブル２１のカラム定義（発注企業独自のデータプロファイル）に従って値管理テーブル２３に格納した発注データを、図２０の場合と同様にして、項目関連定義テーブル２７のリンク情報（発注企業データプロファイル、標準データプロファイル、受注企業データプロファイルの各データ項目間のリンク情報）を参照して、受注企業の指定するデータ形式のデータに変換し、帳票形式で出力したり、画面１に所定形式で画面表示したりすることができる。
図２３は本発明の実施の形態２に係るデータ管理システムにより各種データを出力するデータ出力手順におけるデータフローを示すブロック図である。
データ管理システムは、データ出力において、値管理テーブル２３（一部の出力では、行管理テーブル２２を利用）に格納されているレコードを読み込み、予め指示されている指定内容の出力データを作成する。データ管理システムは、指示内容として、発注企業伝票データ６１、業界標準データ（システム標準データ）６２、受注企業指定データ６３を指定可能である。また、データ管理システムにおけるデータ作成は、同様の処理を伝票枚数分繰り返した結果、その内容をまとめて指定されたファイル名で出力するものとすることもできる。ここで、出力データの作成の詳細について説明すると、データ管理システムは、値管理テーブル２３に格納されている（発注企業から受信した）各レコードの項目値から、指定された各種データを作成する。また、データ管理システムは、必要に応じて、行管理テーブル２２に格納されているレコードを読み込み、伝票一覧（データ種類別、発注企業別、日付範囲など）を画面上に出力し、更に、一枚の伝票が選択された際に、当該伝票の詳細内容の表示を行うようにすることもできる。この場合も、データ管理システムは、当該詳細表示内容としては、発注企業独自データ６１（デフォルト）、発注企業伝票データ、業界標準データ（システム標準データ）６２、受注企業指定データ６３を指定可能としている。そして、指定された表示内容から、データ管理システムは、列管理テーブル２１を参照し、表示すべきレコードのテーブルＩＤを判断して、テーブルＩＤにより特定したレコードに含まれる項目値の各々を、項目順に値管理テーブル２３から取得して、セットで表示する。なお、テーブルＩＤの判断は、テーブル管理テーブル２４により行うことも可能である。
ここで、値管理テーブル２３に格納されているのは、発注企業独自データ６１（デフォルトの発注企業オリジナルデータ）のみであるため、他の表示内容が選択された場合は、表示すべき各項目値を、図２０のテーブルに相当する項目関連定義テーブルを検索し、該当する発注企業独自データ６１の各値を取得して、表示指定されたテーブルＩＤのレコードの項目名称の各値として、セットで表示する。一方、発注企業独自データ６１（デフォルト）が指定された場合、データ管理システムは、テーブルＩＤで特定したレコードに含まれるデータ項目の項目順に従い、各々の値を値管理テーブル２３から取得して指定の表示態様で表示する。即ち、テーブルＩＤを検索キーとして値管理テーブル２３のレコード（該当行）を確定し、列ＩＤで示される順番に格納されている値をそれぞれ取得して、連番の表示順序でセットで表示する。詳細には、発注企業伝票データ、業界標準データ、受注企業指定データのいずれかが指定された場合、データ管理システムは、テーブルＩＤで特定したレコードに含まれる項目の項目順に従い、表示指定項目と発注企業独自データの対応する項目との間のリンク情報を項目関連定義テーブルから取得する。即ち、データ管理システムは、列ＩＤ（トリガ列ＩＤ）をキーとして項目関連定義テーブルのレコードを検索し、表示指定されたデータ項目に対応するオリジナルデータ（発注企業独自データ）のデータ項目が格納されている列ＩＤ（対象列ＩＤ）を取得する。具体的には、図２０で説明した方法で、表示指定された全てのデータ項目について、オリジナルデータの対応するデータ項目との間でのリンク情報を取得する。そして、データ管理システムは、表示指定されたデータ項目の全てを、それぞれ、取得したオリジナルデータのデータ項目に読替えた後、各々の読み替え後のデータ項目の項目値を値管理テーブル２３から取得する。即ち、データ管理システムは、テーブルＩＤ（列ＩＤでも可）を検索キーとして、表示指定されたデータのレコードについて値管理テーブル２３の格納行（セルレコード）を確定し、列ＩＤで示される順番に格納されている項目値を順次取得して、表示指定されたデータ項目の項目名称とセットで表示する。
実施の形態３
図２４は本発明の実施の形態３に係るデータ管理システムの構成をプロファイル管理システムと共に概略的に示すブロック図である。
図２４に示すように、実施の形態３に係るデータ管理システムは、上記実施の形態と同様のデータ交換システム１１０と、上記実施の形態２で述べたようなプロファイル管理システム１２０とを備える。データ交換システム１１０は、上記列管理テーブル１１，２１と同様の列管理テーブル１１１と、上記行管理テーブル１２，２２と同様の行管理テーブル１１２と、上記値管理テーブル１３，２３と同様の値管理テーブル１１３と、上記テーブル管理テーブル２４と同様のテーブル管理テーブル１１４と、上記項目関連定義テーブル２７と同様の項目関連定義テーブル１１７とを備える。一方、プロファイル管理システム１２０は、上記企業独自のデータフォーマット（企業別データプロファイル）を定義した列テーブルに相当する同様の＊社（Ａ社、Ｂ社・・・）データ項目定義テーブル１２２と、上記標準データフォーマット（標準データプロファイル）を定義する列管理テーブルに相当する標準データ項目定義テーブル１２１と、上記項目関連定義テーブル１１７と同様に、＊社独自データフォーマットと標準データフォーマットとの間のリンク情報を定義する項目関連定義テーブル１２３とを備えている。そして、実施の形態３に係るデータ管理システムは、ネットワークＮＴを介して各社から受信した各社独自フォーマットの一次データ（発注データ、商品データ等）について、テーブル管理テーブル１１４や列管理テーブルを参照して、全レコードの全項目値を行ＩＤ及び列ＩＤ（またはテーブルＩＤ）等と共に値管理テーブル１１３に格納すると共に、識別子等の一部の項目値を行ＩＤ等と共に行管理テーブル１１２に格納する。更に、新たな企業のデータプロファイルが追加された場合、プロファイル管理システム１２０が、かかる追加データプロファイルについて、＊社データ項目定義テーブル１２２を更新すると共に、当該更新されたデータフォーマットと標準データフォーマットとのリンク情報を、標準データ項目定義テーブル１２１を使用して作成し、項目関連定義テーブル１２３に格納する。そして、データ交換システム１１０が、かかる更新された企業独自のデータフォーマット定義及びリンク情報等をネットワークＮＴ経由で取得し、列管理テーブル１１１及び項目関連定義テーブル１１７を更新する。
実施の形態４
次に、本データ管理システムの開発コンセプトについて説明すると、ＤＩＹ業界に位置する受注企業のＥＤＩに対する投資は、益々増加するばかりである。電子商取引を前提条件とした商品の取引契約が年々増加するなか、消費者の求める商品を開発しているにも関わらず、ＥＤＩ環境への投資ができない中小企業は業界への参入を断念せざるを得ない。ＥＤＩの導入や運用に掛かるコスト削減を図ることは、受注企業の重要な課題なのである。この重要課題に対し、一つ一つの受注企業が個々に対処できるソリューションを提供するのではなく、業界全体としてのコスト削減を睨んだソリューションとして展開する事こそが、本電子データ変換システムの開発コンセプトである。ここで、ＤＩＹ業界全体に１０の発注（小売）企業と、１００の受注（卸や製造）企業が存在し、各企業間すべてにおいて電子商取引があると仮定する。まず、各企業間のＥＤＩすべてに標準フォーマットが使用された場合、発注企業は、フォーマット変換（独自⇔標準）プログラムが、１個×１０社＝１０個となり、受注企業は、フォーマット変換（独自⇔標準）プログラムが、１個×１００社＝１００個となり、業界全体に１１０個のフォーマット変換プログラムが存在することになる。次に、各企業間のＥＤＩすべてに独自フォーマットが使用された場合、発注企業は、フォーマット変換はしないので、０個×１０社＝０個となり、受注企業は、フォーマット変換（発注⇔受注）プログラムが、１０社分×１００社＝１，０００個となり、業界全体に１，０００個のフォーマット変換プログラムが存在することになる。このように、標準フォーマットを使用した場合は、独自フォーマットを使用した場合に比べ、必要となるフォーマット変換プログラムが、断然、少なくて済むことが分かる。
業界全体の実際の企業総数や電子商取引総数は正確には分からないが、マッピング作業に代表されるフォーマット変換プログラムの開発や運用に、ずいぶんとコストが掛かる事は、すでに説明した通りであるから、標準フォーマットを使用することにより、業界全体のＥＤＩに掛かるコストの大幅な経費削減が、できる事になる。例えば、発注企業：受注企業＝２００：２００ならば、４００：４０，０００で、実に９９％の削減。また、発注企業での独自⇔標準のフォーマット変換と、受注企業での標準⇔独自のフォーマット変換は、標準フォーマットさえ存在すれば、現在、電子商取引を行っている受注企業が取引のある複数の発注企業に対応してフォーマット変換を行っている事から鑑みれば、充分に実現が可能である。よって、例えば、ＣＩＩ標準フォーマットに現状に合ったカスタマイズを施し、上記二つのフォーマット変換を行う。特に、フォーマット変換を上記のように本データ管理システム（ＥＤＩＹ）により行うことにより、発注企業においては現状と全く変わるところがない。反対に、受注企業においては、取引のある複数の発注企業に対応した個々のフォーマット変換が無くなり、電子商取引を行う際に必要なＥＤＩ環境がデータの送受信のみに成っていることが分かる。本データ管理システムでは、業界に位置するすべての受注企業が現在持っている発注企業独自⇔受注企業独自のマッピング定義やフォーマット変換プログラムを移管してもらい、管理するわけではない。将来を睨んだＸＭＬ−ＥＤＩにも対応できる新たな業界標準フォーマットを策定し、この標準フォーマットを介してフォーマット変換を行うことで、発注企業の独自フォーマットの変更にも即座に対応可能な、業界全体の視点から無駄のないフォーマット変換システムを、全ての受注企業の代行として維持管理するものである。
図２５は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータを取引過程にしたがって示すデータフロー図である。図２６は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータの一覧及び構成を示す表である。図２７は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用する標準データのデータ構造を示すデータ構造図である。
図２５〜図２７にしたがって、本データ管理システムの管理対象データについて説明する。本データ管理システムの管理する主要対象データは、電子商取引のある発注企業と受注企業との間で送受信される各種データである。各種データは、１レコードの長さが定められた固定長テキストファイルであり、複数のレコードの集まりで構成されている。一般的に、レコードは、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの３種類がある。これは、電子商取引が、やはり伝票単位で行われている表れであり、発注（受注）情報、納品情報、受領情報は、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの３階層でデータが構成されている場合が多く、支払情報、請求情報は、ファイルヘッダ・レコード、伝票ヘッダ・レコードの２階層でデータが構成されている場合が多いようである。このレコードの階層構造の関連付けは、各種データ内のレコードシーケンスによって示される為、本データ管理システムでは、ファイルヘッダ・レコード、伝票ヘッダ・レコード、伝票明細行・レコードの階層関連を確保しながら、レコード単位に分けて、データベースに格納する。図２５に示すように、本データ管理システムでは、電子商取引のある発注企業と受注企業間での業務フローを上図に示すように想定し、各取引企業間で交換される対象データを定めている。図２６はデータの一覧と構成を示す。各種データのレコード構成は、図２７の通りである。ファイルヘッダレコードは、全データのヘッダとして共用するレコードである。入荷予定（梱包）データのみが４階層であるが、他は３階層で構成されている。
次に、電子データ変換システム（本データ管理システム）の各機能を、以下の３つの視点から、送受信されるデータの取扱、データ変換時の課題と解決方法、流通業務フローに準じたデータ履歴の確保について、順に説明する。まず、送受信されるデータの取扱については、本データ管理システムの管理する主要対象データは、電子商取引のある発注企業と受注企業との間で送受信される各種データである。このデータを、どのように取り扱うべきかという視点から分析すると、以下の５種類に分類することができる。１番目は、受注企業が取り込むべきデータであり、「商品コード」や「発注数量」等、受注企業が出荷業務などの作業に必要不可欠なデータを指す。なお、本データ管理システムでは、受注企業のシステムで利用できるように、発注企業から受信したデータを受注企業が指定するフォーマットに変換し、データファイルとして出力する。受注企業はこのファイルをインポート等して、システムに各種データを取り込む必要がある。次に、２番目は、伝票に印字すべきデータであり、受注企業が、商品を出荷する際に添付する納品伝票の印字データを指す。本データ管理システムは、統一伝票（ＴＡ１型、ＴＡ２型等）を印刷することができる。また、納品伝票の印字内容や印字位置、印字方法は、発注企業が細かく指定している場合が多く、本データ管理システムではこの詳細な内容に付いても、発注企業毎に企業別データプロファイルに定義してあるので、データ変換を行う際に、自動的に納品伝票を印字することができる。勿論、発注企業からの発注数量を、在庫引当後の納品予定数量や、ピッキング作業後の納品確定数量に変更することも可能であるし、変更後の印字内容も、発注企業毎の企業別データプロファイルに定義してあるので、発注企業毎に指定された修正イメージで印刷することができる。３番目は、発注企業のみで利用されるデータであり、上記１番目及び２番目で使用しない、発注企業独自のデータを指す。このデータは、発注企業独自のシステムで利用される場合が多く、受注企業から発注企業へ返信するデータ項目に指定される場合が多く、データを持ち回る必要がある。本データ管理システムでは、発注企業から受信したオリジナルデータをすべて格納しているので、発注企業が指定する独自ファーマットの返信データに指定されているデータを、事前に受信したデータから必要時に抽出して使用する。４番目は、データ送信あるいはデータ構成を制御するデータであり、「データ種別」や「ファイル区分」、「中継センターコード」等、データ種類やデータ構造、通信制御データなどの制御データを指す。本データ管理システムでは、これらの制御データを分析し、データ構成やデータ関連などの整合性を確保し、システム内のデータベースに必要なデータを格納する。これらのデータは、原則的にはシステム利用者には開放されないが、発注企業から受信したオリジナルデータをすべて格納しているので、参照することは可能である。５番目は、上記分類の複数に価するデータであり、本データ管理システムでは、其々に分けて対処（上記参照）する。
図２８は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するデータベースのデータ構造を示すテーブル関連図である。図２９は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するデータベースのテーブル一覧を示す表である。
本データ管理システムで使用するデータベース（ＲＤＢ）のデータ構造について説明する。まず、企業管理（ＣＵＳＴＯＭＥＲ）テーブルは、本データ管理システムが対象とする各企業の情報を管理し、発注企業及び受注企業の諸情報を管理する。通常、発注企業側の情報は本データ管理システムの担当者が入力し、受注企業側の情報は、利用企業である受注企業側の担当者が入力する。なお、セキュアリティ確保のため、担当者のユーザ登録により、入力が可能となるようにしている。次に、データ交換管理（ＥＸＣＨＡＮＧＥ）テーブルは、各利用企業間のデータ交換に関連する情報をデータ種類毎に管理するものであり、企業間で交換されるデータ種類の諸情報を管理する。通常、これらの情報は、各利用企業の担当者が入力する情報である。次に、データ種類管理（ＤＡＴＡ＿ＫＩＮＤ）テーブルは、本データ管理システムで取扱うデータ種類を管理するものであり、発注〜請求〜支払いまでのデータ種類を管理する。データ種類管理テーブルは、テーブルのまとまりを示す。通常、これらの情報は、本データ管理システムの担当者が入力する。
次に、テーブル管理（ＴＡＢＬＥ）テーブルは、企業毎のデータ種類別の各種テーブルやレコードを管理するものである。テーブル管理テーブルにおける発注企業側の情報はシステム担当者が入力し、受注企業側の情報は利用企業担当者が入力する。ここで、テーブル管理テーブルは、レコード間の階層関係を維持して格納・管理するための仕組み（レコードサブＩＤ）を備える構成とすることもできる。例えば、テーブル管理テーブルに定義するテーブルＩＤは、企業コード８桁＋データ種別２桁＋レコードサブＩＤとすることができる。また、テーブル管理テーブルは、読込データの各レコードを特定してレコード単位で分割するためのレコード制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）を定義して格納している。このレコード制御情報は、例えば、当該レコードであることを指し示す項目値について、読込レコードにおける位置と内容とを記述する情報である。一例として、制御情報を［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝ＡＡＡ］とすることができる。ここで、「ＭＡＴＣＨ＿ＳＰ＝数字；」は、（複数フィールドからなる）読込レコードの特定の位置（マッチングするフィールドの開始位置）を示す位置情報であり、レコードの先頭（０）からのバイト位置を示す。また、「ＭＡＴＣＨ＿ＣＯＤＥ＝値；」は、読込レコードの特定の位置のフィールドの内容（値）を示す情報で、チェックする文字列コードを示す。上記のように、位置とその値のセットで制御情報を記述し、必要ならば、複数のセットで制御情報を記述することが可能である。また、以下の拡張記述も可能である。即ち、ＭＡＴＣＨ＿ＣＯＤＥを複数指定する場合は、例えば、［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝｛ＡＡＡ，ＢＢＢ，ＣＣＣ｝；］となる。この場合、読込レコードにおいて指定位置のフィールド値のコードが、「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」のいずれかであれば制御情報と合致し、当該読込レコードを特定することができる。なお、ＭＡＴＣＨ＿ＣＯＤＥに否定情報を指定する場合は、例えば、［ＭＡＴＣＨ＿ＳＰ＝０；ＭＡＴＣＨ＿ＣＯＤＥ＝ＮＯＴ｛ＡＡＡ，ＢＢＢ，ＣＣＣ｝；］となる。この場合、読込レコードにおいて、指定位置のフィールド値のコードが、「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」以外であれば制御情報と合致し、当該読込レコードを特定することができる。
次に、列管理（ＣＯＬＵＭＮ）テーブルは、本データ管理システムが対象とする各企業における各種データ情報を管理するものであり、テーブル管理テーブルで特定する各管理対象テーブル（管理対象レコード）を構成する各データ項目の属性、位置、長さ等を管理する。即ち、列管理テーブルは、各管理対象データのデータフォーマットを定義する。通常、発注企業側の情報は、本データ管理システムの担当者が入力し、受注企業側の情報は利用企業担当者が入力する。項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルは、列管理テーブルで定義した各データ項目のなかで、値と内容の変換が必要な際に、各データ項目に格納される値と該当する意味内容を管理するものである。即ち、項目値管理テーブルは、各企業のドメイン値を定義する。通常、発注企業側の情報は本データ管理システムの担当者が入力し、受注企業側の情報は利用企業担当者が入力する。行管理（ＲＯＷ）テーブルは、本データ管理システムに格納されたレコードの基本的な管理（表計算システムにおける行に当たる）情報を格納するものであり、読込んだデータのレコード単位の識別子と基礎データとを、入力データの何番目のレコードであるかを示す行ＩＤをキー項目として格納する。即ち、行管理テーブルは、レコードの識別子（ＩＤＥＮＴＩＦＩＥＲ）やレコード関連情報等を格納する。また、行管理テーブルは、検索項目（発注データと納品データとの間での突合処理等で使用）について、５つまでデータ内容から複写した値（突合値）を当該テーブル内に格納する。行管理テーブルは、格納レコード単位で各行を作成する。
値管理（ＣＥＬＬ）テーブルは、入力されたデータをレコード単位で格納するものであり、行管理テーブルの行ＩＤと列管理テーブルの列ＩＤとにより一意に示されるセルにデータ項目値を格納する。上記のように、値管理テーブルは、１レコードの内容をまとめて格納することも可能である。即ち、値管理テーブルは、入力データの何番目のレコードであるかを示す行ＩＤとそのレコードを解析した際に参照したテーブル管理テーブルのキー項目であるテーブルＩＤまたは列ＩＤが基本のキー項目になる。表計算の行と列の交差するポイントのセルにデータを格納するイメージである。本来、ひとつのセルにひとつの値を格納すべきであるが、パフォーマンス向上を図る為に、本データ管理システムでは１セルに多数の項目を格納できるようにすることもできる。この場合、１レコード内の項目が予定項目数以上の場合を想定し、セルシーケンスＮＯ．を設け、予定項目数以上の項目の値からは、新しいセルレコードを作成して格納する。項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルは、列管理テーブルに定義されて管理されている（異なるデータプロファイルの）データ項目間の関連定義（リンク）情報を管理する。即ち、項目関連定義テーブルは、トリガーとなる項目（トリガー列ＩＤ、即ち、図２０の例では発注企業や受注企業のデータプロファイルの列ＩＤ）と対象となる項目（対象列ＩＤ、即ち、図２０の例では標準データプロファイルの列ＩＤ）を示し、項目間の値を変換する際に使用する関数（関数コード）およびそのパラメータを管理する。原則として、項目関連定義テーブルのトリガー列ＩＤとなるトリガー項目には、企業別データプロファイルの各項目を選択して格納し、対象列ＩＤとなる対象列項目には標準データプロファイルの各項目を選択して格納する。これにより、標準データプロファイルの各項目を介して、発注企業データプロファイルの各項目と受注企業データプロファイルの各項目との間でのデータ変換を実現することができる。通常、発注企業側データプロファイルの各項目と標準データプロファイルの各項目との間での項目間リンク情報は、本データ管理システムの担当者が入力し、受注企業側データプロファイルの各項目と標準データプロファイルの各項目との間での項目間リンク情報は、利用企業担当者が入力する。なお、標準データプロファイルを介することなく、発注企業側データプロファイルと受注企業側データプロファイルとの間で直接リンク情報を張ることも可能である。
次に、関数（ＦＵＮＣＴＩＯＮ）テーブルは、当該システムで使用する関数情報を管理するものであり、項目関連定義テーブルで利用されるシステム関数を管理する。当該情報は、本データ管理システム担当者が入力する。次に、ボリューム管理（ＶＯＬＵＭＥ）テーブルは、本データ管理システムを利用する場合のデータベース領域を管理するものであり、本データ管理システムが入出力する各種データを格納するデータベースの格納域を、対象企業別、年度別等で管理する。当該情報は、利用ユーザの指定内容により、本データ管理システムが自動更新する。次に、企業別格納域管理（ＶＯＬＵＭＥ＿ＣＵＳＴＯＭＥＲ）テーブルは、データベース領域単位に、データ変換対象とする発注企業を管理するものであり、作成ボリューム単位にデータ変換の対象とする発注企業を管理する。当該情報は、利用ユーザの指定内容により、本データ管理システムが自動更新する。次に、システム管理（ＳＹＳＴＥＭ）テーブルは、本データ管理システムが稼動する際のシステム情報を管理し、ユーザーキー等、利用ユーザのシステムを管理する。次に、作業管理（ＴＲＡＮＳＡＣＴＩＯＮ）テーブルは、本データ管理システム音データ変換作業の各種情報を一作業毎（トランザクション毎）に管理するものである。次に、対象管理（ＳＹＳＴＥＭ＿ＯＢＪＥＣＴ）テーブルは、本データ管理システムの管理対象である対象オブジェクトを定義するものであり、伝票、梱包、支払内容等を管理する。この管理対象は、テーブル管理テーブルに定義されるデータ情報が何を対象にしたデータであるかにより、一意に決定される。例えば、ある企業の発注データを構成するファイルヘッダレコードには「発注」、発注ヘッダレコードには「伝票」、伝票明細レコードには「伝票明細」が対象オブジェクトになり、「発注」には｛発注企業コード＋データ送信日時｝、「伝票」には｛発注企業コード＋店コード＋伝票番号｝、「伝票明細」には｛発注企業コード＋店コード＋伝票番号＋行番号｝で取得できる、それぞれの対象オブジェクトを一意に示す識別子を割り付けることができる。なお、図示はしないが、列管理テーブル等、全てのテーブルには、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」、「アクセス制御」、「登録者情報」のデータ項目が設けられ、当該データ項目の値が格納される。特に、「有効日時（自）」、「有効日時（自）」等の日時情報は、列管理テーブルの定義の有効期間（当該カラム定義を使用できる期間）等を限定できる情報を提供するため、カラム定義のバージョン管理等に活用することができる。
図３０は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムにより、発注データと出荷データとの間で相違が発生した場合のマッチング処理を概略的に示す説明図である。
図３０に示すように、発注企業の発注データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２について、発注は商品Ｂが１０個であるが、受注企業でピッキングした結果、在庫切れが発生している場合、出荷予定は商品Ｂが８個となる。ここで、本データ管理システムは、出荷予定データを作成する場合、まず、項目関連定義テーブルを使用して、値管理テーブルに格納した発注企業独自データ（オリジナルデータ）としての発注データを、発注企業データプロファイルから標準データプロファイルへとデータ変換して、（受注企業側）システム標準データとしての受注データを作成する。次に、本データ管理システムは、項目関連定義テーブルを使用して、受注企業側システム標準データとしての受注データを、受注企業データプロファイルへとデータ変換して、受注企業指定データとしての受注データを作成する。次に、受注企業は、自社システムを使用して、受注企業指定データ形式の受注データに在庫切れを反映し、受注企業指定形式の出荷予定データを作成する。次に、本データ管理システムは、項目関連定義テーブルを使用して、受注企業指定形式の出荷予定データを、受注企業データプロファイルから標準データプロファイルへとデータ変換して、システム標準データとしての出荷予定データを作成する。なお、自社システムを有しない受注企業は、本データ管理システムを使用して出荷予定データを作成するため、このデータ変換処理は不要となる。このとき、本データ管理システムは、列管理テーブルや対象管理テーブルを参照して、発注データと出荷予定データとの間でのデータ突合に必要な突合項目値（伝票Ｎｏ．や明細行Ｎｏ．等）を行管理テーブルに格納している。よって、ここで、データ管理システムは、突合対象の発注データ（＝受注データ）に関する突合項目値を行管理テーブルから取得し、当該発注データの伝票Ｎｏ．の値（伝票Ｎｏ．１００）と、明細行Ｎｏ．の値（明細行Ｎｏ．１〜５）とを、出荷予定データの伝票Ｎｏ．の値（伝票Ｎｏ．１００）と、明細行Ｎｏ．の値（明細行Ｎｏ．１〜５）と突合させ、受注データの発注数量と出荷予定データの出荷数量の比較を行い、相違がある場合は出荷数量に反映する（出荷訂正する）。即ち、上記の場合、本データ管理システムは、発注データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２の商品Ｂの個数と、出荷データの伝票Ｎｏ．１００の伝票明細行Ｎｏ．２の商品Ｂの個数とを自動的にマッチング（突合処理）して、出荷予定データを作成する。具体的には、本データ管理システムは、伝票明細行Ｎｏ．２については、商品Ｂの個数を、当初の（発注数である）１０個ではなく、（実際の納品数である）８個に設定（出荷訂正）する。このようにして、行管理テーブルに格納する突合項目値を、納品書の修正時に有効に活用することができる。最後に、本データ管理システムは、項目関連定義テーブルを使用して、システム標準データとしての出荷予定データを、標準データプロファイルから発注企業データプロファイルへとデータ変換して、発注企業独自データとしての（出荷訂正済みの）出荷予定データを作成する。このようにして、発注企業には、実際に出荷される値の入荷予定データが受信される。
ここで、かかるマッチング処理（突合処理）は、後述するように、列管理テーブルに定義した列サブＩＤ（対応する列ＩＤのデータ項目を突合処理で使用する場合に、対象管理テーブルで定義した当該データ項目のオブジェクトＩＤを示す）と、行管理テーブルに格納した突合項目値（当該突合処理で使用するデータ項目の項目値）と、対象管理テーブルのオブジェクトＩＤを使用して実現している。具体的には、データ管理システムは、レコードの読込時に行管理テーブルを作成するときに、列管理テーブルの列サブＩＤを参照し、読込レコードの特定のデータ項目（伝票ＮＯ．等）が突合処理で使用される項目となっているかどうか判断する。当該データ項目が突合処理で使用される突合項目となっている場合、当該データ項目は対象管理テーブルで予め定義され、対応するオブジェクトＩＤが格納されている。例えば、上記の場合、発注データの伝票ＮＯ．のデータ項目にオブジェクトＩＤ「２０２０１」が格納され、伝票明細行ＮＯ．のデータ項目にオブジェクトＩＤ「２０２０１１」が格納されている。また、列管理テーブルは、当該データ項目に対応する列サブＩＤの欄にオブジェクトＩＤが格納されている場合、そのオブジェクトＩＤに対応するデータ項目を対象管理テーブルから取得し、当該データ項目の項目値を行管理テーブルの対応する突合項目値の欄に格納する。例えば、上記の場合、オブジェクトＩＤ「２０２０１」のデータ項目「伝票ＮＯ．（伝票番号）」が対象管理テーブルから取得され、行管理テーブルの対応する突合項目値として格納され、また、オブジェクトＩＤ「２０２０１１」のデータ項目「伝票明細行ＮＯ．（行番号）」が対象管理テーブルから取得され、行管理テーブルの対応する突合項目値として格納される。これにより、データ管理システムは、上記突合処理において、突合項目値（伝票ＮＯ．及び明細行ＮＯ．）により、処理対象の発注データ（受注データ）と出荷予定データとの間で各伝票の各明細行を突合することができ、突合した明細行の数量等に相違がある場合（発注数量より出荷数量が少ない場合）、当該出荷数量を反映するよう、出荷予定データを訂正する。
実施の形態５
図３１は本発明の実施の形態５に係るデータ管理システムを適用して電子商取引データ交換を実現するネットワークシステムの全体構成を示す説明図である。
図３１の上部に示すように、発注企業と受注企業との間のデータ送受信は、既存の通信インフラを利用することが前提である。ＪＣＡあるいは全銀協、全銀ＴＣＰ／ＩＰ等の通信手順が使われる。図３１の左下は、データ管理センター乃至システムサポートセンター（「ｅＤＩＹ」サポートセンター）を示す。データ管理センターは、標準プロファイルと企業プロファイルとを管理し、本データ管理システム（「ｅＤＩＹ」システム）を利用するユーザの要求に応じて、標準プロファイルや企業プロファイルを配信し、その履歴状況に応じて課金を行う。図３１の右下は、本データ管理システム（「ｅＤＩＹ」システム）を示す。本データ管理システムは、必要なプロファイルをインストールする事で取引先との電子データ交換＆翻訳をする事ができる。
次に、図３１に示すデータ管理システムの簡単な処理の流れを以下に簡単に示す。まず、データ管理センター（「ｅＤＩＹ」サポートセンター）にて、業界標準のメッセージ・フォーマットに従い、標準プロファイルを定義する。次に、データ管理センター（「ｅＤＩＹ」サポートセンター）にて、業界に属する各発注企業のメッセージ・フォーマットを分析し、標準プロファイルとの関連と共に企業プロファイルとして定義する。次に、データ管理システム（「ｅＤＩＹ」システム）の利用企業は、電子商取引を行う取引先を決定し、データ管理センター（「ｅＤＩＹ」サポートセンター）に要求すると、必要な標準プロファイルと企業プロファイルがダウンロードされ、システムにインストールされる。次に、データ管理センターは、既存システムとのインタフェースに必要なメッセージ・フォーマットをユーザープロファイルとして定義する。次に、ユーザ企業のシステムにおいて、取引先企業独自データと利用企業指定データとの間でのデータ変換及び翻訳が相互に自動で行われる。ここで、現行のＶＡＮ企業を介して受信した取引先の各種データをデータ管理システム（「ｅＤＩＹ」システム）に入力することで、自社既存システムに必要な各種ファイルのインポートデータを作成する。また、既存システムで作成される各種ファイルをデータ管理システム（「ｅＤＩＹ」システム）に入力することで、現行ＶＡＮ企業を介して送信する各種データを作成する。
次に、データ変換及び翻訳の仕組みについて簡単に説明する。まず、データ管理システム（「ｅＤＩＹ」）のデータ変換及び翻訳は、前述のように、発注企業別データプロファイルと標準データプロファイルとの間で項目関連定義を行い、かつ、標準データプロファイルとユーザーデータプロファイル（受注企業データプロファイル）との間で項目関連定義を行う事で実現する。こうすることにより、発注企業別データプロファイルとユーザーデータプロファイルとの間の項目関連定義をする事なく、標準データプロファイルを介して、発注企業のデータと受注企業のデータとの間の各データ項目間の関連情報（リンク情報）を取得し、データ変換及び翻訳を実現することができる。なお、標準データプロファイルは、業界毎に作成可能である。
図３２は一般的なテーブル構造と本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルとの関係を示すブロック図である。
データ管理システム（図３１の「ｅＤＩＹ」）は、図３２に示すように一般的なテーブル構造とそれに格納されるデータとを３つの物理テーブルに分けて格納することでデータ変換及び翻訳を実現する。即ち、前述のように、データ管理システムは、インデックスを格納する行管理（ＲＯＷ）テーブルと、データ項目内容を格納する列管理（ＣＯＬＵＭＮ）テーブルと、データ（項目値）を格納する値管理（ＣＥＬＬ）テーブルの３つのテーブルを有する。３つに分けたテーブルの内、列管理テーブルが、各データプロファイルのデータ項目定義を格納するテーブルに該当する。この列管理テーブルの各レコード間の関連定義（図３２中では項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブル）を含めて企業プロファイルを作成する。
図３３は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルの概念を示す説明図である。
図３２の３つのテーブルの概念は、図３３に示すように、リレーショナルデータベースで扱う表の行（ロー）と列（カラム）とセルとで示す事ができる。即ち、前述のように、データ管理システムは、テーブルのデータ項目（カラム）をデータ設計作業が必要なデータ項目としてではなく、データ入力作業としての簡易入力・編集が可能な項目値として、列管理テーブルに格納し、各管理対象レコード（読込レコード）のインデックス（行ＩＤ）を行管理テーブルに格納し、当該データ項目（カラム）と行ＩＤとが交差するセルに格納される項目値を値管理テーブルに（列ＩＤと行ＩＤとにより特定して）格納する。
図３４は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルにおけるレコード階層構造の処理について説明するブロック図である。
ここで、上述のように、電子商取引で交換される各種データは図３４に示すように階層構造からなっている場合が多い（図１５参照）。なお、本データ管理システムは、行管理テーブルに格納されるデータ間に階層構造がある場合については、図３４に示すように、列管理テーブルのレコード階層を表すコードであるレコードサブＩＤ等を当該行管理テーブルに格納すると共に、行管理テーブルに親レコードシーケンスＮｏ．（当該レコードの親となるレコードの連番）を定義する等により、親子関係を確保することで対処することもできる。しかし、後述するように、当該階層関係や親子関係等のレコード間またはテーブル間の関連情報を行管理テーブルから外出しにして別個のテーブル（行関連管理テーブル）を用意し、レコード間の関連に対応するようにすることが好ましい。
図３５は本発明の実施の形態５に係るデータ管理システムを流通企業向け物流支援システムに適用した場合の業務の流れを示すフロー図である。
上述のデータ管理システム（「ｅＤＩＹ」）で交換されるデータをクライアント側のデータベースに格納し、それらのデータを有効に活用できる物流業務プロセスを支援するパッケージが改良版データ管理システム（「ｅＤＩＹｐｌｕｓ」）である。この改良版のデータ管理システムは、図３５の太線で囲んだ長方形で示す業務プロセスの支援を行う。即ち、同データ管理システムは、受注時の受注内容チェックや在庫仮引当、出庫時のロケーション指示や在庫本引当、梱包時の出荷検品及び出荷数量訂正、ＰＤラベル発行、訂正済み納品書発行等、利用企業の情報化レベルに合わせた導入に対応できる。
図３６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する企業管理（ＣＵＳＴＯＭＥＲ）テーブルを示す説明図である。
図３６に示すように、企業管理（ＣＵＳＴＯＭＥＲ）テーブルは、そのデータ項目（カラム）として、「企業コード」、「企業名」、「〒（郵便番号）」、「住所」、「ＴＥＬ（電話番号）」、「担当者」、「メール」、「企業分類」等を定義している。なお、図３６の企業管理テーブルは、図３６に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時」等）を定義している。そして、企業管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「００００００」、「情報センター」・・・等）。ここで、企業管理テーブルのデータ項目である企業コードの値「００００００」は、データ管理システムを管理する管理センター（図３１のｅＤＩＹサポートセンター、テーブルでは「情報センター」として表示）に対応し、標準データプロファイル等の各プロファイル情報を定義し、管理する。また、企業コードの値「１１１１１１」は、データ管理システムが管理するデータ（発注データ等）の発注企業（図３１の発注企業）に対応し、本データ管理システムが管理対象とするデータが属する全ての発注企業（ユーザ企業にとっての取引先企業）が登録されている。また、企業コードの値「９９９９９９」は、データ管理システムを利用するユーザ企業（図３１の受注企業）に対応する。企業が追加、削除されたり、登録企業の企業情報が内容変更されると、企業管理テーブルの対応するデータ項目の値が更新される。
図３７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ交換管理（ＥＸＣＨＡＮＧＥ）テーブルを示す説明図である。
図３７に示すように、データ交換管理（ＥＸＣＨＡＮＧＥ）テーブルは、そのデータ項目（カラム）として、「取引先企業（コード）」、「利用企業（コード）」、「データ種類（コード）」、「プロトコル」、「伝送方向」、「伝送サイズ」、「伝票様式」等を定義している。なお、図３７のデータ交換管理テーブルは、図３７に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時」、「商品コード変換ファイル名」、「取引先・自社コード」等）を定義している。そして、データ交換管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１１０１」、「９９９９９９０１」・・・等）。なお、データ交換管理テーブルのデータ項目中、「取引先企業（コード）」は、管理対象データ（発注データ、入荷予定データ等）の送信元（送信側）となる企業（例えば、発注データの場合は発注企業、入荷予定データの場合は受注企業）の企業コード（６桁）に当該管理対象データのデータプロファイル乃至カラム定義のバージョン（版）を示すバージョンコード（２桁）を付加したものである。また、データ交換管理テーブルのデータ項目中、「利用企業（コード）」は、管理対象データ（発注データ、納品データ等）の送信先（受信側）となる企業（例えば、発注データの場合は受注企業、入荷予定データの場合は発注企業）の企業コード（６桁）に当該管理対象データのデータプロファイル乃至カラム定義のバージョン（版）を示すバージョンコード（２桁）を付加したものである。なお、かかる「取引先企業（コード）」、「利用企業（コード）」は、発注企業や受注企業以外にも、標準データプロファイルを管理する管理センターにも割当てられ、この場合、管理センターコード（６桁）に当該管理センターが管理する標準データプロファイルのバージョン（版）を示すバージョンコード（２桁）を付加したものである。データ交換管理テーブルは、取引先企業のデータを利用企業のデータに変換（データ交換）する場合に、当該取引先企業と利用企業との間で実際に取引があるか（データ交換が存在するか）をチェックするために、データ交換時（発注データの読込時等）に参照され、データ読込時に実際に入力された取引先企業コードと利用企業コードとを判断することにより、それらの企業間での取引（データ交換）がデータ交換テーブルに存在するか否かを判断し、当該取引が存在する場合のみデータ交換を後述するテーブル管理テーブルを利用してデータ読込を実行し、当該取引が存在しない場合はエラー処理を実行する等の所定処理に使用される。
ここで、例えば、データ交換管理テーブルの１行目のレコードは、取引先企業コード「１１１１１１０１」の企業（発注企業）が、利用企業コード「９９９９９０１」の企業（受注企業）に、データ種類コード「２０」のデータ（発注データ）を、伝送プロトコル「２」にしたがって、送信した場合（伝送方向「Ｒ」）、即ち、発注企業の発注データを受注企業の指定形式（指定データフォーマット）の受注データへと変換する場合を示す。また、データ交換管理テーブルの２行目のレコードは、取引先企業コード「１１１１１１０１」の企業（発注企業）が、利用企業コード「０００００００１」の企業（管理センター）に、データ種類コード「２０」のデータ（発注データ）を、伝送プロトコル「２」にしたがって、送信（伝送方向「Ｒ」）、即ち、発注企業の発注データを管理センターの標準データプロファイル形式のデータへと変換する場合を示す。また、データ交換管理テーブルの３行目のレコードは、取引先企業コード「９９９９９９０１」の企業（ユーザ企業である受注企業）が、利用企業コード「１１１１１１０１」の企業（発注企業）に、データ種類コード「３０」のデータ（入荷予定データ）を、伝送プロトコル「２」にしたがって、送信（伝送方向「Ｓ」）、即ち、受注企業の入荷予定データを発注企業のデータプロファイル形式の入荷予定データへと変換する場合を示す。このように、全てのデータ種別について、取引（データ交換）が存在する全ての対の取引先企業と利用企業との関係が、データ交換管理テーブルに格納される。また、データ管理システムは、発注企業の指定形式（発注企業データプロファイル）と受注企業の指定形式（受注企業データプロファイル）との間でのデータ交換（データ読込）のみならず、発注企業の指定形式（発注企業データプロファイル）と標準データプロファイルとの間でのデータ交換や、受注企業の指定形式（受注企業データプロファイル）と標準データプロファイルとの間でのデータ交換も実行するため、データ交換管理テーブルには、取引（データ交換）が存在する全ての対の取引先企業と利用企業との関係が格納される。更に、データ交換管理テーブルの各行の取引（データ交換）について、使用される伝票様式（使用伝票名称）やＰＤラベル（使用ＰＤラベル名称）もデータ交換管理テーブルに格納され、データ変換後のデータ表示（印刷や画面表示）の際に、使用すべき伝票がデータ管理システムの表示プログラムにより参照されるようになっている。なお、データ交換の必要な企業間の関係が追加、削除されたり、登録された伝票様式等の情報が内容変更されると、データ交換管理テーブルの対応するデータ項目の値が更新される。
図３８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルを示す説明図である。
図３８に示すように、データ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルは、そのデータ項目（カラム）として、「データコード」、「データ種類（名称）」、「有効日時（自）」、「有効日時（至）」、「登録日時」、「更新日時」、「削除日時」、「アクセス制御」、「登録者情報」等を定義している。なお、図５７のデータ種類テーブルは、図３８に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「データ種類カナ」）を定義している。そして、データ種類テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「００」、「その他」・・・等）。ここで、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」からなる日時情報は、データ種類テーブルのみならず、本データ管理システムが使用する全てのテーブルのデータ項目として定義され、当該データ項目の値が格納されて、例えば、列管理テーブルの定義の有効期間（当該カラム定義を使用できる期間）等を限定できる情報を提供するため、カラム定義のバージョン管理等に活用される。また、本データ管理システムの全てのテーブルには、「有効日時（自）」、「有効日時（自）」、「登録日時」、「更新日時」、「削除日時」以外にも、「アクセス制御」、「登録者情報」のデータ項目が設けられ、当該データ項目の値が格納される。なお、データ交換管理テーブル等、データ種別をカラムに定義してその値を格納する他のテーブルの所定行の参照時に、データ種別コードをキーにしてデータ種類テーブルが参照され、当該他のテーブルの当該所定行に格納されたデータ種別の情報がデータ種類テーブルから取得される。
図３９は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル管理（ＴＡＢＬＥ）テーブルを示す説明図である。
図３９に示すように、テーブル管理（ＴＡＢＬＥ）テーブルは、そのデータ項目（カラム）として、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類コード）」、「枝番（＝レコード関連情報を表すコード）」、「レコード名称」、「制御情報（＝レコード制御情報）」、「サイズ（＝レコードサイズ）」、「対象（＝対象オブジェクト）」、「ヘッダ（＝ヘッダの有無）」、「前Ｒ（＝前レコード指定）」、「後Ｒ（＝後レコード指定）」等を定義している。なお、図３９のテーブル管理テーブルは、図３９８に図示のデータ項目以外にも、図示はしないが、図２９の表で説明したようなその他のデータ項目（「有効日時（自）」、「有効日時（至）」等）を定義している。そして、テーブル管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「０００００００１」、「２０」・・・等）。なお、テーブル管理テーブルのデータ項目中、「企業（版）」は、前記データ交換管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ管理システムが対象とするデータ種類を識別するものであり、データ種類テーブルのデータ種類に対応する。また、「枝番」は、親子関係や階層構造等の関係にあるレコード関連情報を示すものであり、発注データ等の管理対象データにおける階層等を一意に示すものである。前記「企業（版）」、「種類」、「枝番」によりテーブルＩＤが構成されている。なお、「枝番」は、その企業（版）コードを有する企業において同データ種別内でテーブルＩＤを一意に特定するサブＩＤであり、テーブル管理テーブルに格納される。
「制御情報」は、図２９の表に項で前述したレコード制御情報と同様のレコード分析情報であり、当該制御情報が属する行のレコードについて、当該レコードであることを識別するための情報（当該レコードの先頭（０）からのバイト位置及びチェックする文字列コード）を格納する。例えば、１行目のレコード（テーブルＩＤ「０００００００１２０１」の「標準−発注−ファイルヘッダ」レコード）の場合、データ管理システムは、データの読込時に、テーブル管理テーブルを参照し、読み込んだレコードの先頭からの位置が「０」の文字列コードが「ＦＨ２０」であれば、即ち、先頭の文字列コードが「ＦＨ２０」であれば、当該レコードを「標準−発注−ファイルヘッダ」レコードと判断する。「サイズ（レコードサイズ）」は、当該レコードのサイズ（バイト）を示す。データ管理システムは、データ読込時に、テーブル管理テーブルを参照し、前記「制御情報（レコード制御情報）」により判断したレコード（特定テーブルＩＤ）に応じて、当該テーブルＩＤの「レコード（サイズ）」に指定したレコードサイズで読込データを分割して当該テーブルＩＤの一レコードとする。「対象」は、当該テーブルＩＤのレコードの対象オブジェクト、即ち、当該レコードが伝票レコードや伝票明細行レコード等のいずれのレコードであるかを示し、後述する対象管理テーブルのオブジェクトＩＤに対応する。データ管理システムは、データ読込時に、テーブル管理テーブルを参照し、前記「制御情報」により判断したレコード（特定テーブルＩＤのレコード）の「対象」の値に基づき、当該読込レコードの対象オブジェクト（伝票、梱包等）を判断する。なお、テーブル管理テーブルは、データ管理システムが把握する（取り扱う）全ての企業のレコードを格納する。即ち、テーブル管理テーブルは、発注企業、ユーザ企業（受注企業）及びデータ管理センター（上記ｅＤＩＹに相当）について、全てのデータ種類のデータのレコード階層や親子関係等のレコード関連情報も含め、全てのテーブルＩＤの各々について上記のようなデータ定義情報を格納する。
図４０は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの標準データプロファイル部分を示す説明図である。図４１は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの発注企業データプロファイル部分を示す説明図である。図４２は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの受注企業データプロファイル部分を示す説明図である。
列管理（ＣＯＬＵＭＮ）テーブルは、上記実施の形態１〜４でも説明したように、標準データプロファイル、発注企業データプロファイル、受注企業データプロファイルを一つのテーブルとして格納したものであり、実際は、図４０〜図４２のテーブルは一つのテーブルを構成する（説明の便宜上、及び、紙面サイズの関係上３つに分けて図示する）。図４０〜図４２に示すように、列管理テーブルは、そのデータ項目（カラム）として、「列ＩＤ」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類コード）」、「枝番（＝レコード関連情報）」、「連番（＝シーケンスＮｏ）」、「名称（＝データ項目名）」、「データ型（＝データの属性）」、「変換（＝変換メソッド）」、「位置（＝ポジション）」、「最大長（＝レングス）」、「最小長（＝レングス（最小））」等を定義している。なお、図４０〜図４２の列管理テーブルは、図４０〜図４２に図示のデータ項目以外にも、図示はしないが、図２９の表の項で説明したように、その他のデータ項目（「関連フラグ」、「関連メソッド」、「関連項目」、「識別子作成順序」、「基本項目指定順序」、「カラムサブＩＤ」、その他、「有効日時（自）」、「有効日時（至）」等の日時情報等）を定義している。そして、列管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１２０１００１」、「０００００００１」・・・等）。なお、列管理テーブルのデータ項目中、「企業（版）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ種類テーブル及びテーブル管理テーブルのデータ種類に対応する。また、「枝番」は、テーブル管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成され、データ項目を一意に示すコードをテーブルＩＤの末尾に付加したものが列ＩＤとなる。
更に、「連番」は、上記のように、同一テーブルＩＤのレコード内における当該データ項目（レコード中のフィールド）の（好ましくは）出力順序を示すものとして構成されるが、格納順序を示すものとして構成しても良い。枝番が格納順序を示す場合、当該枝番が列ＩＤの末尾のコードとして使用される。この場合、例えば、あるテーブルＩＤのレコードが合計１６個のデータ項目（フィールド）からなる場合、「１」〜「１６」までの連番が「連番（シーケンスＮｏ）」の値として格納される。そして、テーブルＩＤと連番との組み合わせ（一連のコード）により、同一レコード内における各データ項目に１対１で対応するコードが構成される。ここで、前記列ＩＤも、同一レコード内における各データ項目に１対１で対応するコードであり、特定データフォーマットのレコードのデータ項目、即ち、同一テーブルＩＤのレコードのデータ項目を一意に特定するものであるが、前記テーブルＩＤと連番との組み合わせによっても特定データプロファイルのレコードのデータ項目一意に特定することができる。また、列ＩＤは、本実施の形態５では、テーブルＩＤとシーケンスＮｏとの組み合わせコードを統合・簡略化する作成規準により自動生成されたコードとなっている。例えば、１行目のレコードの場合、企業（版）コード「０００００００１」の「１」と、データ種類「２０」と、枝番「１」に対応する「１」と、連番「１」に対応する「００１」とから、列ＩＤ「１２０１００１」が生成される。なお、枝番が「２」の場合、列ＩＤの対応部分には「２」が、階層コードが「３」の場合、列ＩＤの対応部分には「３」が付与される。かかる列ＩＤに１対１で対応して、ファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード等の各レコードに特有の一連のデータ項目のデータ項目名が、その本来の並び順で、「連番」の順番に対応して、「名称」の項目値として格納されている（「レコード区分」、「データ種別」、「データ作成日」・・・）。
次に、列管理テーブルには、「関連フラグ」のデータ項目が設けられ、ある列ＩＤのデータ項目が、項目関連定義テーブルにおいて標準データプロファイルとの間で項目間リンク（チェーン）されている場合にＯＮされる。これにより、「関連フラグ」を介して、各データフォーマット（データプロファイル）のレコードのデータ項目について、必要なもののみ標準プロファイルの対応するデータ項目とリンクすることができ、標準データプロファイルを介した発注企業データプロファイルのレコードと受注企業データプロファイルのレコードとのデータ変換において、項目関連定義テーブルを参照する際に、全てのデータ項目間のリンクを参照することなく、必要なデータ項目間のリンクのみ参照して、処理負荷を削減することができる。また列管理テーブルには「変換メソッド」のデータ項目が設けられ、ある列ＩＤのデータ項目の項目値を値変換する必要がある場合に、利用するメソッド名（カラム値（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）等）を格納するものである。例えば、図２１の項目値管理テーブルを参照して述べたように、項目値の意味がデータフォーマットの異なる複数のデータ間で異なる場合、例えば、発注企業データプロファイルのカラム値が「０」で、これに対応する標準データプロファイルのカラム値が「ア」で、これに対応する受注企業データプロファイルのカラム値が「ａ」の場合に、当該発注企業データプロファイルの列ＩＤの「変換メソッド」、当該標準データプロファイルの列ＩＤの「変換メソッド」、及び、当該受注企業データプロファイルの列ＩＤの「変換メソッド」に、それぞれ「カラム値」または「ＣＯＬＵＭＮ＿ＶＡＬＵＥ」の文字列を格納する。例えば、データ管理システムが、発注企業データプロファイルの発注データを受注企業データプロファイルの受注企業指定データに変換する時に、列管理テーブルの当該受注企業指定データのレコードの「変換メソッド」にメソッド名が格納された列ＩＤについて、項目関連定義テーブルを参照し、当該列ＩＤ（トリガ列ＩＤ）と対応する（リンクする）標準データプロファイルの列ＩＤ（対象列ＩＤ）及び当該対象列ＩＤとリンクする発注企業データプロファイルの列ＩＤとを抽出したときに、項目値管理テーブルのそれら３つの列ＩＤの行をそれぞれ参照して、図２１で述べたようにして項目値の意味の変換処理を実行する。
次に、列管理テーブルいは、「識別子作成順序」のデータ項目が設けられ、あるテーブルＩＤを有するレコードを行管理テーブルに格納する場合において、行管理テーブルの「識別子」として当該テーブルＩＤの所定のデータ項目を格納する場合に、それらのデータ項目の順序（当該「識別子」を構成するデータ項目の順番）を格納する。また、列管理テーブルには「基本項目指定順序」のデータ項目が設けられ、ある列ＩＤのデータ項目の項目値を行管理テーブルの何番目の基本情報（基本項目値）に複写するかを示すコードが格納されている。即ち、行管理テーブルは、インデックスとしての行ＩＤや識別子以外にも、各読込レコードの基本情報（例えば、伝票ヘッダレコードの伝票番号、発注日、納品日、検収日等、伝票明細行レコードの商品コード、商品名、発注数量、検収数量等）を所定数の「基本項目値」（＝データ項目）の値として格納するが、かかる基本項目値に特定列ＩＤのデータ項目の値を複写して格納する場合に、当該列ＩＤのデータ項目の値を、「基本項目指定順序」に指定した順番で行管理テーブルの基本項目値に複写する。また、列管理テーブルには「列サブＩＤ」のデータ項目が設けられる。列サブＩＤは、上記列サブＩＤに対応するものであり、ある列ＩＤのデータ項目の項目値を行管理テーブルの「突合項目」（＝データ項目）の値として格納する場合に、当該列ＩＤの対象オブジェクトのオブジェクトＩＤの値を指定する。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードについて、例えば、発注データと入荷予定データとの間での数量の相違（数量不足）を判断して納品書等に訂正情報を記載するために、発注データ及び入荷予定データの対応レコードを突合する際の検索キーとなる「識別子」の値や、突合対象となる「突合項目」の値を格納するが、かかる場合に、当該列ＩＤの対象オブジェクトのオブジェクトＩＤの値を、行管理テーブルの「突合項目」の値として格納する。
図４３は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルを示す説明図である。
図４３に示すように、項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルは、そのデータ項目（カラム）として、「ＩＤ」、「列ＩＤ」、「カラム値」、「標準値」、「意味」等を定義している。なお、図４３の項目値管理テーブルは、図４３に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「備考」、「参照フラグ」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、項目値管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「２４５」、「１１１１１１０１２０２０１６００」・・・等）。なお、項目値管理テーブルは、図２１について説明したと同様にして、値変換処理に利用される。
図４４は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルを示す説明図である。
図４４に示すように、項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルは、そのデータ項目（カラム）として、「ＩＤ」、「トリガ列ＩＤ」、「連番（＝シーケンスＮｏ）」、「対象列ＩＤ」、「関数（＝関数コード）」、「パラメータ１」、「パラメータ２」、「パラメータ３」等を定義している。なお、図４４の項目関連定義テーブルは、図４４に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「パラメータ４〜１０」、「備考」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、項目関連定義テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「５４」、「１１１１１１０１２０１００３」・・・等）。なお、項目関連定義テーブルは、図２０について説明したと同様にして、標準データプロファイルを介して発注企業データプロファイルと受注企業プロファイルとの間でのデータ変換処理に利用される。即ち、図４４に囲み線で示したように、発注企業データプロファイルの発注データの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値を、標準データプロファイルの列ＩＤ「１２０１００３」を介して、受注企業が指定する受注データプロファイルの列ＩＤ「９９９９９９０１２０１００３」のデータ項目の値へと変換する場合、データ管理システムは、受注企業データプロファイルの列ＩＤ「９９９９９９０１２０１００３」をトリガとして、標準データプロファイルの対象ＩＤ「１２０１００３」に「関数コード」の「１（格納）」にしたがって格納した発注企業データプロファイルの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値を、「関数コード」の「２（取得）」にしたがって取得する。これにより、受注企業データプロファイルの列ＩＤ「９９９９９９０１２０１００３」のデータ項目の値に発注企業データプロファイルの列ＩＤ「１１１１１１０１２０１００３」のデータ項目の値が格納され、当該データ項目とセットで表示・出力される。なお、「パラメータ１〜１０」は、「関数コード」の関数内容に応じて、その関数のパラメータが必要となる場合に所定値が格納され、データ管理システムが、項目関連定義テーブルの「関数コード」の値にしたがて、関数管理テーブルの関数内容を参照し、当該パラメータの値により当該関数の処理を実行する。
図４５は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する関数管理（ＦＵＮＣＴＩＯＮ）テーブルを示す説明図である。
図４５に示すように、関数管理（ＦＵＮＣＴＩＯＮ）テーブルは、そのデータ項目（カラム）として、「関数（＝関数コード）」、「関数（＝関数内容）」、「詳細（＝ヘルプ）」等を定義している。なお、図４５の関数管理テーブルは、図４５に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「有効日時（自）」、「有効日時（至）」等）を定義している。そして、関数管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１」、「格納」・・・等）。関数管理テーブルに格納する関数は、データ管理システムが管理するデータについて要求される処理を考慮して必要なものがあらかじめ定義されデータ項目値として格納される。即ち、従来は、要求される処理に応じてプログラム内に定義されていた関数やパラメータが、本データ管理システムでは、関数管理テーブルのデータ項目値として外出しされ、関数管理テーブルを参照することで必要な処理が実行される。よって、要求される処理の内容が追加、削除、変更等された場合、従来のようにプログラム自体を変更するという面倒な作業を必要とすることなく、関数管理テーブルに項目値として格納した関数を追加、削除、変更したり、項目関連定義テーブルに項目値として格納したパラメータの値を追加、削除、変更したりすることにより、処理の変更に容易に対応することができる。
図４６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する対象管理（ＯＢＪＥＣＴ）テーブルを示す説明図である。
図４６に示すように、対象管理（ＯＢＪＥＣＴ）テーブルは、そのデータ項目（カラム）として、「ＩＤ（＝オブジェクトＩＤ）」、「オブジェクト名」、「位置（＝ポジション）」、「キー内容」等を定義している。なお、図４６の対象管理テーブルは、図４６に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「参照フラグ」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、対象管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「３」、「ＧＴＩＮコード」・・・等）。「ＩＤ（＝オブジェクトＩＤ）」は、テーブル管理テーブルの「対象（＝対象オブジェクト）」及び列管理テーブルの「列サブＩＤ」に対応する。「位置」は、当該オブジェクトＩＤのオブジェクトに該当するカラム項目（ＧＴＩＮコード、ｉｄ伝票、ｉｄ伝票明細行等）の項目値（「キー内容」に定義されたものであり、例えば、ｉｄ伝票の場合は発注企業コード＋（店コード）＋伝票ＮＯ）を、行管理テーブルの何番目の「突合項目」の値として格納するかを示す。例えば、オブジェクトＩＤ「１１」のオブジェクト「店コード」の項目値は、行管理テーブルの対応するオブジェクト（伝票ヘッダレコード及び伝票明細行レコード）の１番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「２０２０１」のオブジェクト「伝票番号」の項目値は、行管理テーブルの対応するオブジェクト（伝票ヘッダレコード及び伝票明細行レコード）の２番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「２０２０１１」のオブジェクト「行番号」の項目値は、行管理テーブルの対応するオブジェクト（伝票明細行レコード）の３番目の突合項目（突合項目値１）の項目値として格納され、オブジェクトＩＤ「３」のオブジェクト「ＧＴＩＮコード」の項目値は、行管理テーブルの対応するオブジェクト（伝票明細行レコード）の４番目の突合項目（突合項目値４）の項目値として格納される。これら行管理テーブルの「突合項目」の項目値として格納される「オブジェクトＩＤ」の項目値が、データ管理システムの管理対象であるファイルヘッダレコード、伝票ヘッダレコード、伝票明細行レコード、送り状ヘッダレコード、梱包レコード、梱包明細行レコード等の識別子として、それぞれの対象オブジェクト（レコード）を一意に識別する。そして、例えば、発注データのある伝票明細に指定された発注数量と、入荷予定データの伝票明細の実際の納品数量との間で数量に相違（欠品）がある場合に、行管理テーブルに格納した突合項目値を参照して両伝票明細を突合し、それらの数量（例えば、行管理テーブルの基本項目値として格納した発注数量と検収数量）をチェックすることで、入荷予定伝票の納品数量を自動的に訂正処理することができる。
ここで、システム管理対象としては、例えば、「１１，店コード，１」（オブジェクトＩＤ、オブジェクト名、位置の順）、「２０２０１，伝票番号，２」、「２０２０１１，行番号，３」、「３，ＧＴＩＮコード，４」、「４０２０１，梱包コード，５」、「２０１０１，発注日付，６」、「３０１０１，出荷日付，７」、「３０２０１，出荷指示書Ｎｏ，８」、「３０２０１１，出荷指示書行Ｎｏ，９」、「７０１１１，支払明細，１０」があり、各管理対象レコード（そのテーブルＩＤにより識別される所定カラム定義のレコード）に対応して、これらの各項目値のいずれか１以上（ゼロの場合もあり）が、その位置（ポジション）にしたがって、行管理テーブルの対応する突合項目の項目値として自動的に割り当てて格納される。また、これら以外に、システム管理対象としては、例えば、「１，発注企業コード（発注企業を示すコード）」（オブジェクトＩＤ、オブジェクト名、キー内容の順）、「２，受注企業コード（受注企業を示すコード）」、「１０，商品（商品情報の送信イベントを示す。１０＋発注企業コード＋受注企業コード＋送信日付）」、「２０，発注（発注情報の受信イベントを示す。２０＋発注企業コード＋受注企業コード＋発注日付）」、「３０，納品通知（ＡＳＮ）（納品通知の送信イベントを示す。３０＋発注企業コード＋受注企業コード＋納品予定日付）」、「４０，梱包明細（ＳＣＭ）（梱包明細の送信イベントを示す。４０＋発注企業コード＋受注企業コード＋出荷日付）」、「５０，受領（受領情報の受信イベントを示す。５０＋発注企業コード＋受注企業コード＋検収日付）」、「６０，請求（請求情報の送信イベントを示す。６０＋発注企業コード＋受注企業コード＋請求日付）」、「７０，支払（支払情報の受信イベントを示す。７０＋発注企業コード＋受注企業コード＋支払通知日付）」、「８０，返品（返品情報の受信イベントを示す。８０＋発注企業コード＋受注企業コード＋返品日付）」、「２０２０，ｉｄ伝票（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋伝票ＮＯ）」、「２０３０，ｉｄ伝票明細行（システム内で伝票明細を一意に示す。発注企業コード＋（店コード）＋伝票ＮＯ＋伝票行ＮＯ）」、「４０１０，ｉｄ出荷（システム内で出荷単位を一意に示す。発注企業コード＋店コード＋出荷日付）」、「４０２０，ｉｄ梱包（システム内で梱包を一意に示す。発注企業コード＋（店コード）＋梱包ＮＯ）」、「４０３０，ｉｄ梱包明細（システム内で梱包明細を一意に示す。発注企業コード＋（店コード）＋梱包ＮＯ＋伝票ＮＯ＋伝票行ＮＯ）」、「６０１１，請求（月ごとの請求総括を示す）」、「６０２０，iｄ請求（システム内で請求を一意に示す。発注企業コード＋（店コード）＋請求対象期間）」、「６０３０，ｉｄ請求明細（システム内で請求を一意に示す。発注企業コード＋（店コード）＋請求対象期間＋科目コード）」、「７０１１，支払（月ごとの支払総括を示す）」、「７０２０，ｉｄ支払（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋支払対象期間）」、「７０３０，ｉｄ支払明細（システム内で伝票を一意に示す。発注企業コード＋（店コード）＋支払対象期間＋科目コード）」、「６０１１１，請求明細（月ごとの請求明細を示す）」、「４０２０１１，梱包明細（梱包明細を示すコード）」があり、各管理対象レコード（そのテーブルＩＤにより識別される所定カラム定義のレコード）に対応して、これらの各項目値のいずれか一つが、行管理テーブルの対応する「識別子ＩＤ」の「識別値」の項目値として自動的に割り当てて格納される。
図４７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する行管理（ＲＯＷ）テーブルを示す説明図である。
図４７に示すように、行管理（ＲＯＷ）テーブルは、そのデータ項目（カラム）として、「行グループ」、「連番（＝シーケンスＮｏ」、「行タイトル」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種類）」、「枝番（＝レコード関連情報」、「親Ｓ（＝親レコードシーケンスＮｏ）」、「ＦＳ（＝同一レコード内シーケンスＮｏ）」、「識別子（＝識別子値）」、「突合値１（＝突合項目値１）」（〜「突合項目値ｎ（たとえば突合項目値１０」）、「基本値１（＝基本項目値１）」（〜「基本項目値ｎ（たとえば突合項目値５」）等を定義している。なお、図４７の行管理テーブルは、図４７に図示のデータ項目以外にも、図示はしないが、図２９の表の項で説明したようにその他のデータ項目（「識別子ＩＤ」、「識別子名称」、「関連メソッド」、「関連情報」、「備考」、「参照フラグ」、その他、「有効日時（自）」、「有効日時（至）」等の日時情報等）を定義している。そして、行管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１０１−９９９９９９−５０−０５１２０７−２０１９１４」、「１」・・・等）。なお、行管理テーブルのデータ項目中、「行グループ」は、所定の作成基準にしたがって、データ管理システムが一レコードを読込むごとに自動生成（発番）されるコードであり、格納データの管理グループを示す。行グループは、例えば、発注企業コード（＋版）の８桁＋受注企業コードの６桁＋データ種別の２桁＋データ読込日の６桁＋データ読込時刻（時分秒）の６桁から一意のコードとして自動生成することができる。そして、１回に読込んだデータ（発注データ等）の全てのレコードについて同一の行グループが付与される。なお、同一行グループを有するレコードが、本データ管理システムが格納データとして管理すべき１単位の管理グループとなる。次に、「連番」は、前記同一行グループ内での当該レコードの連番（レコードシーケンス）を示す。例えば、読込データが１００レコードからなる場合、「１」〜「１００」の連番が読込レコードの順番で「連番（シーケンスＮｏ）」の項目値として付与される。前記行グループ及び連番（シーケンスＮｏ）により行ＩＤが構成され、当該行ＩＤが、当該レコードが入力データ（読込データ）の何番目のデータであるかを示す。即ち、行ＩＤにより、各読込レコードに１対１で対応するコードが構成される。なお、「企業（版）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応する。また、「種類」は、データ種類テーブル及び列管理テーブルのデータ種類に対応する。また、「枝番」は、テーブル管理テーブル及び列管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成されている。行管理テーブルでは、データ読込時にテーブル管理テーブルを参照したときに、「レコード制御情報」の値に基づき、特定のテーブルＩＤのカラム定義とマッチ（照合）したレコードに対して、当該テーブルＩＤが自動的に付与される。また、このとき、当該テーブルＩＤに割り当てた「レコード名称」（テーブル管理テーブル参照）の項目値が、行管理テーブルの「行タイトル」の項目値として複写される。
次に、「親Ｓ（親レコードシーケンスＮｏ）」は、当該格納レコードが従属する親レコード（上位階層のレコード）の「連番（シーケンスＮｏ）」の値を示す。例えば、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であるため、親レコードは存在せず、「親Ｓ（親レコードシーケンスＮｏ）」は「０」となる。また、２行目のレコード（「連番（シーケンスＮｏ）」の値が「２」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、３行目のレコード（「連番（シーケンスＮｏ）」の値が「３」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「２」となる。同様に、９行目のレコード（「連番（シーケンスＮｏ）」の値が「９」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、１０行目のレコード（「連番（シーケンスＮｏ）」の値が「１０」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「９」となる。次に、「ＦＳ（同一レコード内シーケンスＮｏ）」は、当該格納レコードが属する同一グループ内でのシーケンス（順序）を示す。即ち、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であり、一読込データ（一管理グループの格納レコード群）について一つしか存在しないため、「ＦＳ（同一レコード内シーケンスＮｏ）」の値は「１」となる。また、２行目、９行目、１６行目のレコード（「連番（シーケンスＮｏ）」の値が「２」、「９」、「１６」）の場合、それぞれ伝票ヘッダレコード（ＤＨ）であり複数存在するため、同一グループ（即ち、伝票ヘッダグループ）内におけるシーケンス（順序）を示すべく、「連番（シーケンスＮｏ）」の値の小さい順に、「ＦＳ（同一レコード内シーケンスＮｏ）」の値が「１」、「２」、「３」というように連続して付与される。また、１０行目、１１行目・・・のレコード（「連番（シーケンスＮｏ）」の値が「１０」、「１１」・・・）の場合、伝票明細行レコード（ＤＤ）であり複数存在するため、同一グループ（即ち、伝票明細行グループ）内におけるシーケンス（順序）を示すべく、「連番（シーケンスＮｏ）」の値の小さい順に、「ＦＳ（同一レコード内シーケンスＮｏ）」の値が「１」、「２」・・・というように連続して付与される。
次に、「識別子（識別子値）」は、当該格納レコードの識別子の値を示す。そして、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、列管理テーブルの「識別子作成順序」を参照し、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）のテーブルＩＤに対応して、列管理テーブルの当該テーブルＩＤの「識別子作成順序」で指定した順序にしたがって、指定されたテーブルＩＤのデータ項目の値を順番に組み合わせて、行管理テーブルの「識別子」の値を自動生成する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「識別子作成順序」において「発注企業コード」、「データ種別」、「データ作成日」が、それぞれ、「１」、「２」、「３」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「５０」、「２００５０８１７」）を順に組み合わせて、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日」を、「識別値」に「１１１１１１−５０−２００５０８１７」をそれぞれ格納する（行管理テーブルの１行目のレコード参照）。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「識別子作成順序」において「伝票番号」が「１」として指定されているため、このデータ項目の値（「４９２１８３８９」）を前記ファイルヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０２０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９」」をそれぞれ格納する（行管理テーブルの２行目のレコード参照）。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１）については、「識別子作成順序」において「行番号」及び「ＧＴＩＮ］が「１」としてそれぞれ指定されているため、このデータ項目の値（「０２」及び「０４９３６０６８９２７２１７」）を前記伝票ヘッダレコードの識別値に追加して、行管理テーブルの識別子の値を生成し、当該テーブルＩＤの行（レコード）の「識別子ＩＤ」に「２０３０」（システム対象オブジェクトテーブルの「オブジェクトＩＤ」）を、「識別子名称」に「発注企業コード−データ種別−データ作成日−伝票番号−行番号−ＧＴＩＮ」を、「識別値」に「１１１１１１−５０−２００５０８１７−４９２１８３８９−０２−０４９３６０６８９２７２１７」をそれぞれ格納する（なお、図６６では、行番号については省略）。このように行管理テーブルの各レコードに付与した識別値は、例えば、発注データと入荷予定データの所定の項目値（発注数量と検収数量乃至納品予定数量等）同士を突合する際に、当該レコードの検索キーとして使用される。
次に、「突合値１（突合項目値１）」〜「突合項目値ｎ（例えば、突合項目値１０）」は、各行のレコードを上記のように突合する際に使用する突合項目値を格納する。即ち、データ管理システムは、行管理テーブルの作成時（データの各レコード読込時）に、テーブル管理テーブルの「レコード制御情報」を参照して判断した当該読込レコード（管理対象レコード）の列ＩＤに対応して、列管理テーブルにおいて当該列ＩＤのデータ項目について「カラムサブＩＤ」に格納したオブジェクトＩＤの値を参照し、当該オブジェクトＩＤについて対象管理テーブルの対応する「オブジェクトＩＤ」の「位置（ポジション）」を参照して、当該位置（ポジション）にある行管理テーブルの対応レコードの「突合値１」〜「突合値ｎ」のいずれかに、当該オブジェクトＩＤに対応するオブジェクトの値を格納する。このとき、列管理テーブルにおいて当該オブジェクトに対応する前記列ＩＤの値を、上記データ解析・読込時に読込レコードから取得（当該レコードの対応する項目値を取得）して、当該オブジェクトＩＤに対応するオブジェクトの値を行管理テーブルの「突合項目値」に格納する。例えば、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１）については、「カラムサブＩＤ」において発注店舗コード（店コード）のオブジェクトＩＤ「１１」が指定されているため、このデータ項目の値であるオブジェクトＩＤ「１１」についてシステム対象管理テーブルを参照し、当該オブジェクトＩＤ「１１」についての行管理テーブルの突合項目値としての「位置（ポジジョン）」を判断すると共に、当該オブジェクト（店コード）の列ＩＤの値（「１００」）を読込レコードから取得して、その値「１００」を行管理テーブルの１番目の突合値として「突合項目値１」に格納する（行管理テーブルの２行目のレコード参照）。また、「基本値１（基本項目値１）」〜「基本項目値ｎ（例えば、突合項目値５）」は、列管理テーブルの「基本項目指定順序」に指定した順序にしたがって、読込レコードから基本項目値を抽出して格納するものである。
次に、「基本項目指定順序」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの何番目の基本情報（基本項目値）に複写するかを示すものである。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードの基本情報（例えば、伝票ヘッダレコードの伝票番号、発注日、納品日、検収日等、伝票明細行レコードの商品コード、商品名、発注数量、検収数量等）を所定数の「基本項目値」（＝データ項目）の値として格納するが、かかる基本項目値に特定の列ＩＤのデータ項目の値を複写して格納する場合に、当該列ＩＤのデータ項目の値を、「基本項目指定順序」に指定した順番で行管理テーブルの基本項目値に複写する。また、「列サブＩＤ」は、当該列ＩＤのデータ項目の項目値を行管理テーブルの「突合項目」（＝データ項目）の値として格納する場合に、当該列ＩＤの「対象オブジェクト」のオブジェクトＩＤの値を指定する。即ち、行管理テーブルは、インデックスとしての行ＩＤ以外にも、各読込レコードについて、例えば、発注データと入荷予定データとの間での数量の相違（数量不足）を判断して納品書等に訂正情報を記載するために、発注データ及び入荷予定データの対応レコードを突合する際の検索キーとなる「突合項目」の値を格納するが、かかる場合に、当該列ＩＤの対象オブジェクトのオブジェ宇土ＩＤの値を、行管理テーブルの「突合項目」の値として格納する。例えば、列管理テーブルでは、ファイルヘッダレコード（テーブルＩＤ「９９９９９０１５０１」）については、「基本情報作成順序」において「発注企業コード」、「受注企業コード」、「データ種別」、「データ作成日」、「レコード件数」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「１１１１１１」、「９９９９９９」、「５０」、「２００５０８１７」、「６１」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。同様に、列管理テーブルでは、伝票ヘッダレコード（テーブルＩＤ「９９９９９０１５０１１」）については、「基本情報作成順序」において「伝票番号」、「発注日」、「納品日」、「検収日」が、それぞれ、「１」、「２」、「３」、「４」の順序で指定されているため、これらのデータ項目の値（「４９２１８３３９」、「２００５０１１３」、「２００５０１１９」、「２００５０１１９」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値４」にそれぞれ格納する。同様に、列管理テーブルでは、伝票明細行レコード（テーブルＩＤ「９９９９９０１５０１１１」）については、「基本情報作成順序」において「ＧＴＩＮ」、「規格カナ」、「品名カナ」、「発注数量」、「検収数量」が、それぞれ、「１」、「２」、「３」、「４」、「５」の順序で指定されているため、これらのデータ項目の値（「０４９３６０６８９２７２１７」、「＊＊＊（規格名）」、「＊＊＊（品名」、「３０」、「３０」）を、その順番で、行管理テーブルの当該レコードの「基本項目値１」〜「基本項目値５」にそれぞれ格納する。
図４８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する値管理（ＣＥＬＬ）テーブルを示す説明図である。
図４８に示すように、値管理（ＣＥＬＬ）テーブルは、そのデータ項目（カラム）として、「行グループ」、「行ＩＤ」、「企業（版）（＝企業コード＋版情報）」、「種類（＝データ種別）」、「枝番（＝レコード関連情報）」、「連番（＝セルシーケンスＮｏ」、「親Ｓ（＝親レコードシーケンスＮｏ）」、「ＦＳ（＝同一レコードレベル内シーケンスＮｏ）」、「値１」、「値２」、「値３」、「値４」、「値５」（〜「値ｎ（たとえば値３０」）等を定義している。なお、図４８の値管理テーブルは、図４８に図示のデータ項目以外にも、図示はしないが、図２９の表の項で述べたようにその他のデータ項目（「値０１−アクセス制御」・・・、「関連メソッド」、「関連項目」、「有効日時（自）」、「有効日時（至）」等）を定義している。そして、値管理テーブルは、各データ項目に対応する値（データ項目値）をテーブルの各行（各レコード）に格納している（「１１１１１０１−９９９９９９−５０−０５１２０７−２０１９１４」、「１」・・・等）。なお、行管理テーブルのデータ項目中、「行グループ」は、行管理グループの「行グループ」に対応し、「行ＩＤ」は、行管理テーブルの「連番（＝シーケンスＮｏ」に対応し、行グループと連番の複合キーにより、各読込レコード（格納レコード）が一意に示される（即ち、行グループ＋連番＝行ＩＤとなる）。また、「企業（版）（企業コード）」は、前記データ交換管理テーブル及びテーブル管理テーブルの企業コード（企業コード６桁＋バージョンコード２桁）に対応し、「種類」は、データ種類テーブル及びテーブル管理テーブルのデータ種類に対応し、「枝番」は、テーブル管理テーブルや列管理テーブルの「枝番」に対応する。テーブル管理テーブルについて述べたように、前記「企業（版）」、「種類」、「枝番」により、テーブルＩＤが構成されている。データ管理システムは、データ読込時に、行管理テーブルの行ＩＤを自動生成して各行のレコードを作成すると同時に、当該行ＩＤを構成する行グループ及び連番を、それぞれ、値管理テーブルの行グループ及び行ＩＤの欄に項目値として格納する。また、値管理テーブルでは、行管理テーブルについて取得した各読込レコードのテーブルＩＤ（企業（版）＋データ種別＋階層）が、各行に自動的に付与される。これにより、行ＩＤとテーブルＩＤとにより、値管理テーブルの各レコードを特定することができる。
次に、図４１について説明したように、データ管理システムは、読込レコードのデータ項目数が値管理テーブルの一行の値格納数（「値ｎ」）を超える場合、例えば、格納項目値数が３０個の場合、３１個目からの項目値を格納すべく、当該レコードの行の次の行に項目値格納用の行を用意して、当該レコードを２行にわたって格納する。よって、「連番（セルシーケンスＮｏ）」は、通常（項目値数が３０以下の場合）は、「１」であるが、項目値数が３１以上となり、次の行が用意される場合、当該追加行の「連番（セルシーケンスＮｏ）」が「２」に設定される。そして、３１以上のデータ項目の値からは、新しいセル（ＣＥＬＬ）レコードを作成して格納する。「親Ｓ（親レコードシーケンスＮｏ）」は、当該格納レコードが従属する親レコード（上位階層のレコード）の「連番（シーケンスＮｏ）」の値を示す。例えば、１行目（「連番（シーケンスＮｏ）」の値が「１」）のレコードの場合、ファイルヘッダレコード（ＦＨ）であるため、親レコードは存在せず、「親Ｓ（親レコードシーケンスＮｏ）」は「０」となる。また、２行目のレコード（「連番（シーケンスＮｏ）」の値が「２」）の場合、伝票ヘッダレコード（ＤＨ）であるため、親レコードとしてファイルヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は当該親レコードの「連番（シーケンスＮｏ）」の値である「１」となる。また、３行目のレコード（「連番（シーケンスＮｏ）」の値が「３」）の場合、伝票明細行レコード（ＤＤ）であるため、親レコードとして当該伝票明細行が属する伝票の伝票ヘッダレコードが存在し、「親Ｓ（親レコードシーケンスＮｏ）」は、行管理テーブルの「親Ｓ（親レコードシーケンスＮｏ）」に対応し、「ＦＳ（同一レコード内シーケンスＮｏ）」は、行管理テーブルの「ＦＳ（同一レコード内シーケンスＮｏ）」に対応する。「値１」〜「値ｎ」には、データ読込時に、列管理テーブルに定義した各データのカラム定義に従って、各データ項目が順番に特定され、読込レコードから分割された各フィールド値（データ項目値）が、列ＩＤの順番（テーブルＩＤ内の「連番」の順番）で格納される。
なお、実施の形態５に係るデータ管理システムは、図２９に示したように、上記した以外のテーブル（ボリュームテーブル、ボリューム管理テーブル、システム管理テーブル、作業管理テーブル）も含む。また、上記各テーブルの日時情報に関するデータ項目である「有効日時（自）」、「有効日時（至）」等の日時情報は、各テーブルのデータ項目値（企業管理テーブルの企業情報、列管理テーブルのカラム定義等）が更新される場合に、その版（バージョン）管理に活用することができる。
実施の形態６
図４９は本発明の実施の形態６に係るデータ管理システムをシステム開発支援ＣＡＳＥツールに適用する場合の概念を説明するブロック図である。図５０は本発明の実施の形態６に係るデータ管理システムのテーブル間の双方向のデータ変換の概念を説明するブロック図である。
図４９に示すように、実施の形態６に係るデータ管理システムは、上記各実施の形態のデータ交換機能のコアアーキテクチャを、異なるデータプロファイルの第１のデータ（例えば、発注データ）と第２のデータ（例えば、ユーザ指定データ）との間でのデータ変換（データ⇔データ交換）のみでなく、特定データプロファイルのデータと当該データについて指定された表示形式の画面表示との間でのデータ変換（データ⇔画面）や、特定データプロファイルのデータと当該データについて指定された印刷形式の帳票との間でのデータ変換（データ⇔帳票）等に派生させ、それを汎用的に制御するエンジンの開発を行い、実施の形態６に係るデータ管理システムとしてのＣＡＳＥツールとしている。なお、データ管理システムのスピードが問題になる場合はジェネレーション機能を加える事で対応する事とする。詳細には、データ管理システムのシステム仕様として、上記実施の形態１〜５におけるデータ変換アーキテクチャは、列管理テーブルに格納した第１のデータプロファイル（例えば、発注企業データプロファイル）のデータと、同列管理テーブルに格納した第２のデータプロファイル（例えば、受注企業データプロファイル）のデータとの間での双方向のデータ変換を実現するアーキテクチャである（テーブル⇔テーブル間データ変換）。即ち、テーブル間のデータ変換は、図５０に示すように、列管理テーブルに定義された定義情報（テーブルのデータ項目毎に作成されたレコード関連情報）のうちの所定の情報（列ＩＤ等）を、項目関連定義テーブルに定義することで実現する。
図５１は本発明の実施の形態６に係るデータ管理システムのテーブルと帳票との間での片方向（一方向）のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
図５１（ａ）に示すように、所定データプロファイル（カラム定義）のデータを対応する帳票のデータプロファイル（帳票形式乃至帳票フォーマット）に変換する場合（テーブル⇒帳票（片方向））、即ち、テーブル内容（所定形式のデータ）を出力イメージ（帳票イメージ）に変換する際のデータ変換についても、図５１に示すように、列管理テーブルに定義された（テーブルのデータ項目毎に作成された）レコード関連情報を項目関連定義テーブルに定義することで実現する。しかし、出力イメージを制御する各種パラメータ（位置、フォント、フォントサイズ、色など）が必要な為、列管理テーブルの項目と１対１に対応した帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ（ｏｕｔ））テーブルを追加する。詳細には、図５１（ｂ）に示すように、具体例１は、ある企業（企業コード「１１１９９９０１」）の受注（「２０」）データから、標準の納品書（ＴＡ１）「０００２０１０１−０９」を出力する場合を示す。また、図５１（ｃ）に示すように、具体例２は、標準「０００００００１」の入荷予定（梱包）「４０」データから、ある企業（企業コード「１１１９９９０１」のＰＤラベル（独自）「４９」を出力する場合を示す。上記実施の形態の列管理テーブルのデータ種別「２９」は、標準の納品書として列管理テーブルに定義したものであるが、一般的な帳票のフォーマットであるＴＡ１及びＴＡ２を明確に分けて定義することが好ましい。例えば、プロファイル列管理テーブルにおいて、帳票ＴＡ１のテーブルＩＤ識別子を「０００２０１０１−０９」とし、帳票ＴＡ２のテーブルＩＤ識別子を「０００２０２０１−０９」とする等により対応する。また、上記実施の形態では、第１のデータプロファイルのデータと第２のデータプロファイルのデータとの間でのデータ変換（テーブル⇔テーブル間のデータ交換）しか行っていないが、本実施の形態では、所定のデータプロファイルのデータと所定の表示形式の帳票との間で野データ変換（データ⇒帳票）を追加するため、上記実施の形態ではかかる帳票出力のために表示プログラムに直接記述されていた出力を制御する各種パラメータ値を、プログラムから外出しにして管理するテーブル（帳票データプロファイル管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブル）を本実施の形態のデータ管理システムは用意している。こうしないと、出力すべき帳票が発生する度にプログラムを作成する必要があるからである。
図５２は本発明の実施の形態６に係るデータ管理システムにおいて納品書の金額の表示方法が相違する場合の処理の概念を説明するブロック図である。
ここで、本データ管理システムを実施する際に注意すべきことは、例えば、納品書の金額の表示の方法である。例えば、データとしての「１０００」は「千円」を意味するが、その表示の方法は、「１，０００」もあれば「\１，０００」もあれば「１０００」もあり、その表示方法が企業毎に定められている点に注意する必要がある。即ち、図５２に示すように、データが「１０００」の場合で、納品書ＴＡ１を利用して、データ「１０００」について、Ａ企業では「１，０００」、Ｂ企業では「\１，０００」、Ｃ企業では「１０００」という表示方法が指定されている場合、企業毎に表示内容を変更する必要がある。この場合、項目関連定義テーブルによるデータ交換の際に、その表示方法に対応する必要がある。例えば、テーブルＩＤ「１１１９９９０１−２０」のデータ（テーブル格納データ）を、テーブルＩＤ「０００２０１０１−０９」のデータ（帳票表示フォーマットのデータ）にデータ変換する必要がある。つまり、帳票データプロファイル管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの出力フォーマットのパラメータ値は、同帳票データプロファイル管理テーブルには格納せず、単なる出力領域として扱い、「０００，０００，０００」、「＃＃＃，＃＃＃，＃＃０」、「\＃＃＃，＃＃＃，＃＃０」といったパラメータ値は、列管理テーブル或いは項目関連定義テーブルで実現する。また、ＰＤラベルの発行機能についても、当該変換機能を利用して実現する。この場合、バーコード作成関数を関数管理テーブルに追加する必要がある。
図５３は本発明の実施の形態６に係るデータ管理システムのテーブルと表示画面との間での双方向のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。
テーブル内容と表示画面の入出力データとを変換する際のデータ変換についても、本データ管理システムは、図５３に示すように、列管理テーブルに定義された（テーブルの項目毎に作成された）レコード関連情報を項目関連定義テーブルに定義することで実現する。しかし、この場合、表示画面の入出力データを制御する各種パラメータ（位置、フォント、フォントサイズ、色、ｉｎ／ｏｕｔ区分等）が必要な為、列管理テーブルの項目と１対１に対応した画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブル（上記帳票データプロファイル管理と同一構成）を追加している。具体例１は、表示された客注編集画面（識別子「０００９０１０１−０１」を使用し、入力されたデータから、ある企業（企業コード「１１１９９９０１」の受注（「２０」）データを登録・変更・削除する場合を示す。また、具体例２は、表示された在庫管理画面（識別子「０１０４０１０１−０１」）を使用し、在庫データを登録・変更・削除したり、当該画面より在庫一覧表の帳票を出力する場合を示す。なお、テーブルＩＤ識別子（テーブルＩＤ）については、現在の列管理テーブルにおけるテーブルＩＤの識別子は、企業コード（６桁）＋バージョン情報（２桁）＋データ種類（２桁）である（例えば、「１１１９９９０１２０」、「０００００００１３０」等）が、出力イメージのデータ格納域や画面に対応する入出力データ格納域のテーブルＩＤ識別子の命名ルールについても、同様に定めた所定規則の通りとする。
図５４は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルを概略的に示す説明図である。図５５は本発明の実施の形態６に係るデータ管理システムで使用する帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルを概略的に示す説明図である。図５６は本発明の実施の形態６に係るデータ管理システムで使用する帳票（ＦＯＲＭ）テーブルを概略的に示す説明図である。
図５４に示すように、列管理テーブルは、上記各実施の形態と同様の構成である。また、図５５に示すように、帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、上記列管理テーブルと１対１で対応する項目を有している。詳細には、帳票列管理テーブルは、そのデータ項目（カラム）として、「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」、「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」、「カラム名（ＣＯＬＵＭＮ＿ＮＡＭＥ）」、「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」、「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」を有している。「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」と「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」とは、１対１で対応している。「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」には、帳票に印刷するデータ項目の項目値の左端位置、上端位置、幅、高さ、フォントサイズがそれぞれ格納される。帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、帳票単位にレコードを作成する。フォームＩＤ（ＦＯＲＭ＿ＩＤ）は、テーブルＩＤと同じ命名ルールにすることができる。従って、フォームＩＤ（ＦＯＲＭ＿ＩＤ）は不要とすることもできる。また、企業別データプロファイル（ＥＸＣＨＡＮＧＥ＿ＤＡＴＡ）テーブルに格納する各社の納品書やＰＤラベルのフォーマットの指定欄にも、テーブルＩＤコードを指定する。従って、帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルのインデックス及びキー項目は、プロファイル項目管理（ＣＯＬＵＭＮ）テーブルと同様にする必要は無い。なお、図５６に示すように、帳票イメージは、前記「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」に対応して、帳票（ＦＯＲＭ）テーブルのデータ項目「イメージファイル（ＩＭＡＧＥ＿ＦＩＬＥ）」の値として格納され、また、その幅及び高さも「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」の値として格納されている。
図５７は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルの設定例を概略的に示す説明図である。図５８は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブルの設定例を概略的に示す説明図である。図５９は本発明の実施の形態６に係るデータ管理システムで使用する画面表示（Ｆｏｒｍ）テーブルの設定例を概略的に示す説明図である。図６０は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（Ｆｏｒｍ＿Ｃｏｌｕｍｎ）テーブルの設定例を説明するブロック図である。
図５７に示すように、列管理テーブルは、上記各実施の形態と同様の構成である。また、図７７に示すように、画面表示プロファイル項目管理（Ｆｏｒｍ＿ＣＯＬＵＭＮ）テーブル（帳票プロファイル項目管理テーブルと同一構成）は、上記列管理テーブルと１対１で対応する項目を有している。詳細には、画面表示列管理テーブルは、そのデータ項目（カラム）として、「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」、「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」、「カラム名（ＣＯＬＵＭＮ＿ＮＡＭＥ）」、「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」、「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」を有している。「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」と「列ＩＤ（ＣＯＬＵＭＮ＿ＩＤ）」とは、１対１で対応している。「左端位置（ＬＥＦＴ）」、「上端位置（ＴＯＰ）」、「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」、「フォントサイズ（ＦＯＮＴ＿ＳＩＺＥ）」には、表示画面に表示するデータ項目の項目値の左端位置、上端位置、幅、高さ、フォントサイズがそれぞれ格納される。画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルは、画面表示単位にレコードを作成する。フォームＩＤ（ＦＯＲＭ＿ＩＤ）は、テーブルＩＤと同じ命名ルールにすることができる。従って、フォームＩＤ（ＦＯＲＭ＿ＩＤ）は不要とすることもできる。また、企業別データプロファイル（ＥＸＣＨＡＮＧＥ＿ＤＡＴＡ）テーブルに格納する各社の納品書やＰＤラベルのフォーマットの指定欄にも、テーブルＩＤコードを指定する。従って、画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルのインデックス及びキー項目は、プロファイル項目管理（ＣＯＬＵＭＮ）テーブルと同様にする必要は無い。なお、図５８に示すように、画面表示イメージは、前記「フォームＩＤ（ＦＯＲＭ＿ＩＤ）」に対応して、画面表示（ＦＯＲＭ）テーブルのデータ項目「イメージファイル（ＩＭＡＧＥ＿ＦＩＬＥ）」の値として格納され、また、その幅及び高さも「幅（ＷＩＤＴＨ）」及び「高さ（ＨＥＩＧＨＴ）」の値として格納されている。図６０に示すように、本データ管理システムは、プロファイル列管理テーブルにテーブル内のコアデータに関する定義（カラム定義）を格納すると共に、画面表示プロファイル列管理テーブルに表示データに関する定義（フォーム定義）を格納し、更に、項目関連定義テーブルに表示データとコアデータとの変換内容を定義する。そして、特定の画面表示のデータ項目のフォームＩＤに、項目関連定義テーブルのリンク情報（データ関連情報）を介して、列管理テーブルの列ＩＤのデータ項目を１対１で対応付け、コアデータと表示データとのデータ変換を行う。なお、このようにしてデータ変換された表示データは、画面表示テーブルに格納した表示に関する定義（フォーム定義）に従って表示される。
ここで、画面表示テーブルと画面表示列管理テーブルとの間では、双方向のデータ変換が行われ、例えば、客注入力に対応できるようになっている。具体的には、例えば、所定の発注企業の指定納品書は、チェーンストア協会統一伝票（ＴＡ１）であるとする。この場合、以下に番号（１）〜（２１）を附した各項目（画面項目：[関連データ項目]）から入出力仕様を記述する。なお、入力項目は、下記番号（１）〜（３）及び（２３）、（２６）及び（２９）の項目である。また、下記番号（２１）、（２２）、（２４）、（２５）、（２７）の項目は、商品マスタあるいは過去データからの導出が可能であるため、キー項目入力時に取得することが好ましい。
伝票ヘッダ部
（１） A欄：[支払条件]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（２） B欄：[分割回数]⇒数値入力チェック、桁数1
（３） D欄：[ルートコード]⇒テキスト入力、フォーマットチェック（＊＊＊ ＴＡ９９ ＊＊）
（４） 訂正区分：[訂正有無]⇒＜客注入力では未使用？＞
（５） 実納品日：[出荷日]⇒日付入力チェック
（６） 社名：[発注企業名称]⇒デフォルト表示「デジタル」
（７） 取引先名：[受注企業名称]⇒デフォルト表示「ヤマダサンギョウ」
（８） 店名：[発注店舗名]⇒テキスト入力、桁数、半角カタカナチェック
（９） 社・店コード：[店コード]⇒数値チェック（※存在チェックはしない）
（１０） 分類コード：[部門コード]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（１１） 伝票区分：[伝票区分]⇒コード入力（ＣＯＬＵＭＮ＿ＶＡＬＵＥ値から選択）
（１２） 伝票番号：[伝票No]⇒数値入力チェック、桁数８
（１３） 取引先コード：[取引先コード]⇒デフォルト表示（EXCHANGEテーブル格納値）
（１４） 発注日：[発注日]⇒日付入力チェック
（１５） 納品日：[納品指定日]⇒日付入力チェック
（１６） 数量合計：[発注数量合計]⇒計算表示（明細数量を合計）
（１７） 原価金額合計：[原価金額合計]⇒計算表示（明細原価金額を合計）
（１８） 売価金額合計：[売価金額合計]⇒計算表示（明細売価金額を合計）
（１９） F欄：[島番号（−）台番]⇒テキスト入力、フォーマットチェック（９９−９９９９）
（２０） L欄：[（客注摘要内容等）]⇒＜※受注企業側で適宜入力＞
伝票明細×６
（２１） 品名：[品名]⇒テキスト入力、桁数、半角カタカナチェック
（２２） 規格：[規格]⇒テキスト入力、桁数、半角カタカナチェック
（２３） 商品コード：［ＪＡＮコード］⇒数値入力チェック、桁数１３
（２４） 入数：［入数］⇒数値入力チェック、桁数３
（２５） ケース：［ケース］⇒数値入力チェック、桁数３
（２６） 数量：［発注数量］⇒数値入力チェック、桁数４
（２７） 原単価：［単価］⇒数値入力チェック、桁数７
（２８） 原価金額：［原価金額］⇒計算表示（数量×原単価を計算）
（２９） 売単価：［売単価］⇒数値入力チェック、桁数７
（３０） 売価金額：［売価金額］⇒計算表示（数量×売単価を計算）
明細行の項目の下線（破線）で示した項目は、過去データからの導出が可能である為、導出した後に修正できるようにすることが望ましい。また、納品書発行、出庫指示書発行、客注入力、出荷数量訂正などの機能は、上記プログラムで対応可能とする。
データ管理システムの処理（実施の形態２〜６）
図６１は本発明の各実施の形態２〜６に係るデータ管理システムの発注企業データ読込・格納処理を示すフローチャートである。
図６１に示すように、発注企業データ読込・格納処理では、まず、ＳＴＥＰ１１で、ファイル名あるいは受信データの格納場所から、どの企業から受信したデータ（例えば、発注データ）かを判断し、データ交換の可否をチェックする。次に、ＳＴＥＰ１２で、テーブル管理テーブルのＣＯＮＴＲＯＬ＿ＩＮＩ(制御情報)に基づき、読込んだデータを順次分析しながら、レコード単位に分割する。次に、ＳＴＥＰ１３で、発注企業コード（＋版ＮＯ）＋データ種類＋枝番からなるテーブルＩＤを特定する。次に、ＳＴＥＰ１４で、特定したテーブルＩＤに基づき、列管理テーブルを参照し、データ項目のシーケンスＮｏ．(連番)に従って、各読込レコードの各データ項目値を分割する。次に、ＳＴＥＰ１５で、所定規則に基づき、行グループ（ＲＯＷ＿ＧＲＯＵＰ）及び行ＩＤ（ＲＯＷ＿ＩＤ＝ＲＯＷ＿ＧＲＯＵＰ＋ＲＯＷ＿ＩＤ＿ＳＥＱ）を発番する。次に、ＳＴＥＰ１６で、各読込レコードのデータ項目値から、識別子の値、突合項目値、基本項目値（伝票Ｎｏ．、発注日等）を抽出し、行ＩＤ、テーブルＩＤ等と共に行管理テーブルに格納する。次に、ＳＴＥＰ１７で、各読込レコードの全データ項目値（分割）を、テーブルＩＤ等と共に値管理テーブルの各行に順次格納し、発注企業から受信したオリジナルデータ（一次データ）のみを作成し、処理を終了する。
図６２は本発明の各実施の形態２〜６に係るデータ管理システムの伝票一覧表示処理を示すフローチャートである。
図６２に示すように、伝票一覧表示処理は、ＳＴＥＰ５１で、検索条件を入力すると、ＳＴＥＰ５２で、検索条件が判断される。ＳＴＥＰ６１で、表示種類が「データ種類別」の場合、ＳＴＥＰ６２で、行管理テーブルの該当レコード読込み、ＳＴＥＰ６３で、データ種類別伝票を一覧表示し、処理を終了する。また、ＳＴＥＰ７１で、表示種類が「発注企業別」の場合、ＳＴＥＰ７２で、行管理テーブルの該当レコードを読込み、ＳＴＥＰ７３で、発注企業別伝票を一覧表示し、処理を終了する。ＳＴＥＰ８１で、表示種類が日付範囲別の場合、ＳＴＥＰ８２で、行管理テーブルの該当レコードを読込み、ＳＴＥＰ８３で、日付範囲別伝票を一覧表示して、処理を終了する。
図６３は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理を示すフローチャートである。
図６３に示すように、伝票詳細表示処理は、ＳＴＥＰ１０１で、伝票の選択及び表示指定を行うと、ＳＴＥＰ１０２で、指定内容を判断し、ＳＴＥＰ１１０で指定内容が発注企業オリジナルデータの場合、ＳＴＥＰ１１１で発注企業オリジナルデータのテーブルＩＤで列管理テーブルを検索する。そして、ＳＴＥＰ１１２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１１３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１２０で、指定内容が発注企業伝票データの場合、ＳＴＥＰ１２１で、発注企業伝票データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１２２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１２３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１３０で、指定内容がシステム標準データの場合、ＳＴＥＰ１３１で、システム標準データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１３２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得し、ＳＴＥＰ１３３で、取得値をデータ項目順にセット表示する。ＳＴＥＰ１４０で、指定内容が受注企業指定データの場合、ＳＴＥＰ１４１で、受注企業指定データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１４２のモジュールで、列管理テーブルを参照し、データ項目順に各値を値管理テーブルから取得して、ＳＴＥＰ１４３で、取得値をデータ項目順にセット表示する。
図６４は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業オリジナルデータ取得処理を示すフローチャートである。
図６４に示すように、発注企業オリジナルデータ取得処理は、ＳＴＥＰ１１２Ａで、発注企業オリジナルデータのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値を格納するレコード群を確定する。次に、ＳＴＥＰ１１２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。
図６５は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業伝票データ取得処理を示すフローチャートである。
図６５に示すように、発注企業伝票データ取得処理は、ＳＴＥＰ１２２Ａで、発注企業伝票データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１２２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１２２Ｃで、項目関連定義テーブルを参照し、発注企業伝票データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤをキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。次に、ＳＴＥＰ１１２Ｄで、項目関連情報に基づき、発注企業伝票データの各データ項目に、対応するオリジナルデータの項目値を代入する。
図６６は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理におけるシステム標準データ取得処理を示すフローチャートである。
図６６に示すように、システム標準データ取得処理は、ＳＴＥＰ１３２Ａで、システム標準データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１３２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１３２Ｃで、項目関連定義テーブルを参照し、システム標準データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤ（標準データ用）をキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。そして、ＳＴＥＰ１３２Ｄで、項目関連情報に基づき、システム標準データの各項目に、対応するオリジナルデータの項目値を代入する。
図６７は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における受注企業指定データ取得処理を示すフローチャートである。
図６７に示すように、受注企業指定データ取得処理は、ＳＴＥＰ１４２Ａで、受注企業指定データのテーブルＩＤで値管理テーブルを検索し、同一レコード内のデータ項目値格納レコード群を確定する。次に、ＳＴＥＰ１４２Ｂで、列管理テーブルのデータ項目順に格納された各レコードの項目値を取得する。次に、ＳＴＥＰ１４２Ｃで、項目関連定義テーブルを参照し、受注企業指定データの項目順に各項目に関連するオリジナルデータ項目情報を取得する。このとき、トリガ列ＩＤ（指定データ用）をキーとして、対応する対象列ＩＤを介し、表示項目値を格納するトリガ列ＩＤ（オリジナルデータ用）を検索・取得する。そして、ＳＴＥＰ１４２Ｄで、項目関連情報に基づき、受注企業指定データの各項目に、対応するオリジナルデータの項目値を代入する。
図６８は本発明の各実施の形態２〜６に係るデータ管理システムのデータ出力処理を示すフローチャートである。
図６８に示すように、データ出力処理は、ＳＴＥＰ１５１で、出力指定が行われると、ＳＴＥＰ１５２で、指定内容を判断する。ＳＴＥＰ１６０で、指定内容が発注企業伝票データの場合、ＳＴＥＰ１６１で、発注企業伝票データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１６２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１６３で、取得値を発注企業伝票データ格納手段に格納する。ＳＴＥＰ１７０で、指定内容がシステム標準データの場合、ＳＴＥＰ１７１で、システム標準データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１７２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１７３で、取得値をシステム標準データ格納手段に格納する。ＳＴＥＰ１８０で、指定内容が受注企業指定データの場合、ＳＴＥＰ１８１で、受注企業指定データのテーブルＩＤで列管理テーブルを検索し、ＳＴＥＰ１８２のモジュールで、列管理テーブルを参照し、データ項目順に各値を行管理テーブルから取得し、ＳＴＥＰ１８３で、取得値を受注企業指定データ格納手段に格納する。なお、ＳＴＥＰ１６２，１７２，１８２の各モジュールは、前記ＳＴＥＰ１２２，１３２，１４２のモジュールと同様である。
図６９は本発明の各実施の形態２〜６に係るデータ管理システムの項目値変換処理を示すフローチャートである。
図６９に示すように、項目値変換処理は、ＳＴＥＰ２０１で、発注企業データを読込むと、ＳＴＥＰ２１０，２２０，２３０，２４０，２５０，２６０で、項目名称検証、項目内容検証、属性検証、表示方法検証、桁数検証、ドメイン値検証をそれぞれ実行する。ＳＴＥＰ２１０で、項目名称が検証され、ＳＴＥＰ２１１で、異名異義語と判断されると、ＳＴＥＰ２１２で、関連定義が行われる。ＳＴＥＰ２２０で、項目内容が検証され、ＳＴＥＰ２２１で、同名異議語と判断されると、ＳＴＥＰ２２２で、関連不定義が行われる。ＳＴＥＰ２３０で、属性（データ型）が検証され、ＳＴＥＰ２３１で、関連定義が有りと判断されると、ＳＴＥＰ２１２で、関連定義に基づき属性の変換が行われる。ＳＴＥＰ２４０で、表示方法が検証され、ＳＴＥＰ２４１で、変更オプション有りと判断されると、ＳＴＥＰ２４２で、表示方法の変更が行われる。ＳＴＥＰ２５０で、桁数が検証され、ＳＴＥＰ２５１で、桁落ちが有りと判断されると、ＳＴＥＰ２５２で、警告表示・修正処理が行われる。ＳＴＥＰ２６０で、ドメイン値が検証され、ＳＴＥＰ２６１で、コード代入が有りと判断されると、ＳＴＥＰ２６２で、コードの意味変換が行われる。これらの項目値変換の詳細は、上述のとおりである。
図７０は本発明の実施の形態１〜６に係るデータ管理システムのデータ変換処理及び表示処理の特徴を説明するブロック図である。図７１は図７０との比較のために従来のデータ管理システムのデータ変換処理の表示処理を説明するブロック図である。
図７１に示すように、従来のデータ管理システムとしての受発注管理システム６００は、Ａ社、Ｂ社，Ｃ社・・・等の各取引先（発注企業）に固有のデータプロファイルの発注データ（実データ）を、それぞれの発注企業用にカラム定義（リレーションスキーマ設計）をして、発注データテーブル６１１，６１２，６１３・・・を作成する。そして、それぞれの発注企業用の発注データテーブル６１１，６１２，６１３・・・用に作成した表示プログラム６２１，６２２，６２３・・・により、発注データテーブル６１１，６１２，６１３・・・の実データを画面１に表示する。また、従来の受発注管理システム６００は、各発注データテーブル６１１，６１２，６１３・・・用に作成した変換プログラム（ＰＧ）を利用して、各発注データテーブル６１１，６１２，６１３・・・からユーザ受注データ６１４を作成する。そして、ユーザ受注データ６１４用に作成した表示プログラム６２４により、ユーザ受注データテーブル６１４の実データを画面１に表示する。
一方、図７０に示すように、実施の形態１〜６に係るデータ管理システムは、前述したように、Ａ社、Ｂ社、Ｃ社等の各社の発注データ等（実データ）は、基本的に、トランザクションデータ系としての値管理テーブル２１３に、行ＩＤ、テーブルＩＤ（またはテーブルＩＤ）と共に、値１〜値ｎとして全て格納される。また、各レコードのインデックスとしての行ＩＤ、テーブルＩＤ、識別子、突合値等が、行管理テーブル２１２に格納される。また、各社の実データを上述した各種表示形式で表示する表示プログラム２６は、共通のものが一つのみ用意されている。そして、例えば、Ａ社の実データやＢ社の実データを表示プログラム２６を介して画面１にユーザ指定形式で表示する場合、マスタデータ系による変換処理として、列管理テーブル２１１のＡ社やＢ社のデータ項目定義（カラム定義）が参照されると共に、項目関連定義テーブル２１７の項目関連定義が参照されて、ユーザのカラム定義とＡ社やＢ社のカラム定義とのリンク情報が取得され、かかるリンク情報を介して、Ａ社やＢ社の実データがユーザ企業の指定形式の表示態様で、画面１に表示される。
具体的には、例えば、Ａ社の発注データのレコード（行ＩＤ「Ｒ１」）の項目値は、値管理テーブル２１３において、行管理テーブル２１２の行ＩＤ「Ｒ１」と列管理テーブル２１１の列ＩＤ「Ｃ１１，Ｃ１２，Ｃ１３，Ｃ１４」とで特定される各行に実データとして格納されている。表示プログラム２６は、この実データ（値管理テーブル２１３の４行分のデータ）を取得し、Ａ社発注（実）データとして画面１に所定フォーマットで表示する。Ｂ社、Ｃ社の発注データについても同様である。また、Ａ社発注データを標準フォーマットで表示する場合、項目関連定義テーブル２１７におけるＡ社フォーマットの発注データのデータ項目に対応する列ＩＤをトリガ列ＩＤとして、当該データ項目の値が標準フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。そして、表示プログラム２６は、当該標準フォーマットの発注データのデータ項目にセットしたＡ社の発注データの項目値（実データ）を取得し、Ａ社発注（標準フォーマット）データとして画面１に表示する。これと逆に、Ｂ社発注データ（実データ）を標準フォーマットを介してユーザ指定形式データで表示する場合、項目関連定義テーブル２１７におけるＢ社フォーマットの発注データのデータ項目に対応する列ＩＤをトリガ列ＩＤとして、当該データ項目の値が標準フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。次に、当該標準フォーマットの発注データの列ＩＤをトリガ列ＩＤとして、当該データ項目の値がユーザ指定フォーマットの発注データの対象列ＩＤのデータ項目にセットされる。そして、表示プログラム２６は、標準フォーマットを介して当該ユーザ指定フォーマットの発注データのデータ項目にセットしたＢ社の発注データの項目値（実データ）を取得し、ユーザ発注（ユーザフォーマット）データとして画面１に表示する。
実施の形態７
図７２は本発明の実施の形態７に係るデータ管理システムの列管理テーブルを示す説明図である。
図７２に示すように、実施の形態７に係るデータ管理システムは、管理対象データとして、医療機関で使用されるレセプトコンピュータデータ（レセコンデータ）を取り扱い、異なるデータプロファイル（カラム定義）を有する多数の医療機関（Ａ，Ｂ・・・）のレセコンデータを列管理テーブルにカラム定義すると共に、上記と同様にして、標準データプロファイル（標準レセコン）を介して、データ変換を行う。なお、図７２の列管理テーブルは、上記実施の形態の列管理テーブルと同様のものである。具体的には、列管理テーブルは、上記列管理テーブルと同様のデータ項目を有している。一方、列管理テーブルの「テーブルＩＤ」にはレセコンのテーブル種別を一意に示すデータが格納される。なお、図７２では、説明の便宜上、「標準レセコン」等の文字列を格納しているが、実際は、各テーブルを一意に示すコードが格納される。また、列管理テーブルのデータ項目名（項目名称）には、各テーブル（標準レセコンテーブル等）のデータ項目の項目名称が、列ＩＤに対応して順に格納されている。なお、列ＩＤ、企業ＩＤ、枝番、連番等のその他のデータ項目は、上記各実施の形態の列管理テーブルの列ＩＤ、企業ＩＤ、枝番、連番等と同様のものである。
実施の形態８
図７３は本発明の実施の形態８に係るデータ管理システムの関数管理テーブルを示す説明図である。
図７３に示すように、関数管理テーブル（第１の具体例）は、従来はプログラムの内部に定義されていた関数内容やパラメータや格納先を、プログラムから外出しして、その項目値として格納するものであり、加算、減算等の演算に加え、任意の演算処理をテーブル内に定義して実行することができる。これにより、実施の形態８に係る関数テーブルによれば、上記実施の形態で述べたように、プログラムの追加、削除、変更に用意に対処することができる。関数管理テーブルは、データ項目として、「関数ＩＤ」、「関数名」、「関数内容」、「パラメータ１」、「パラメータ２」、「パラメータ３」・・・「格納先」等を有している。「関数ＩＤ」は、関数ごとに一意に割り当てられるコードである。「関数名」は、各関数の名称を示す（加算、減算等）。「関数内容」は、各関数の内容（処理手順）を示す（例えば、加算の場合、Ａ＋Ｂ）。「パラメータ１」、「パラメータ２」、「パラメータ３」等のパラメータは、対応する関数内容の処理（演算等）でパラメータとして使用され、必要なパラメートをこれらのパラメータ１，２，３・・・に格納しておく。「格納先」は、対応する関数の戻り値を格納する記憶領域を示す。
実施の形態９
図７４は本発明の実施の形態９に係るデータ管理システムの関数テーブルを示す説明図である。
図７４に示すように、関数テーブル（第２の具体例）は、上記実施の形態と同様、従来はプログラムの内部に定義されていた関数内容や入力や出力を、プログラムから外出しして、その項目値として格納するものであり、上記実施の形態で述べたように、プログラムの追加、削除、変更に用意に対処することができる。関数テーブルは、データ項目として、「関数ＩＤ」、「出力」、「関数」、「入力」等を有している。「関数ＩＤ」は、関数ごとに一意に割り当てられるコードである。「出力」は、各関数の出力を示す。「関数」は、各関数の内容（処理手順）を示す（例えば、Ｆ１の場合、＊２）。「入力」は、各関数の入力を示す。例えば、図７４の関数「Ｆ１」は、入力Ａを２倍（＊２）した値を出力Ｃとして出力する関数を示す。
実施の形態１０
図７５は本発明の実施の形態１０に係るデータ管理システムの索引管理テーブルを示す説明図である。図７６は本発明の実施の形態１０に係るデータ管理システムの行関連管理テーブルを示す説明図である。
図７５に示す索引管理（ＩＮＤＥＸ）テーブルは、上記各実施の形態の行管理テーブルにおける突合値を外出しにして管理するものである。索引管理テーブルは、データ項目として、「ＩＤ」、「行ＩＤ」、「オブジェクトＩＤ」、「列ＩＤ」、「値」、「内容」を有している。「ＩＤ」は、行管理テーブルで使用するインデックス乃至検索キー（例えば、突合値）に対応して自動的に発行されるものである。「行ＩＤ」は、行管理テーブルの行ＩＤに対応する。「オブジェクトＩＤ」は、対象管理テーブルのオブジェクトＩＤに対応する。「列ＩＤ」は、列管理テーブルの列ＩＤに対応する。「値」は、対応するオブジェクトＩＤの値（データ項目値）を示す。「内容」は、対応するオブジェクトＩＤの値の内容（データ項目名）を示す。なお、前記「列ＩＤ」及び「内容」は、省略しても良い。このように、少なくとも、行ＩＤ、オブジェクトＩＤ及び値を索引管理テーブルに外出しにして格納することにより、それらを列管理テーブルや行管理テーブルに格納してインデックスを管理する場合と比べ、より柔軟にデータ管理を行うことができる。例えば、インデックスを追加、削除、変更等する場合、索引管理テーブル内のレコードを追加、削除、変更等するだけですみ、保守も容易となる。なお、索引管理テーブルに格納したインデックスの使用方法は、上記発注データと出荷予定データとの間での突合処理の説明で述べたものと同様であり、突合処理等の検索処理において、必要な項目値が索引管理テーブルから随時抽出される。
図７６に示す行関連管理（ＲＯＷ＿ＣＨＡＩＮ）テーブルは、上記各実施の形態の列管理テーブル等における枝番を外出しにして管理するものである。行関連管理テーブルは、データ項目として、「ＩＤ」、「行ＩＤ」、「親行ＩＤ」、「親数」、「関連値」、「内容」を有している。「ＩＤ」は、行管理テーブルに格納するレコード間に親子関係や階層構造等の関連がある場合に、その関連に対応して自動的に発行されるものである。「行ＩＤ」は、行管理テーブルの行ＩＤに対応する。「親行ＩＤ」は、対応する行ＩＤのレコード（またはテーブル）に親となるレコード（またはテーブル）がある場合に、その親となるレコード（またはテーブル）の行ＩＤを示す。「親数」は、対応する行ＩＤのレコード（またはテーブル）に親となるレコード（またはテーブル）がある場合に、その親となるレコード（またはテーブル）の数を示す。「関連値」は、対応する親行ＩＤのレコードの識別子の値を示す。「内容」は、対応する行ＩＤのレコードの内容（レコード名やテーブル名等）を示す。なお、前記「関連値」及び「内容」は、省略しても良い。このように、少なくとも、行ＩＤ、親行ＩＤ及び親数を行関連管理テーブルに外出しにして格納することにより、それらを列管理テーブル等に格納して親子関係や階層構造等のレコード関連情報を管理する場合と比べ、より柔軟にデータ管理を行うことができる。例えば、レコード関連情報を追加、削除、変更等する場合、行関連管理テーブル内のレコードを追加、削除、変更等するだけですみ、保守も容易となる。更に、図７６の表の下側に示すように、行関連管理テーブルにより、発注データのような階層構造を有するレコード（親が一つの場合）の管理が可能となるだけでなく、あるレコード（またはテーブル）が親を複数有する場合の管理も可能となる。
例えば、階層構造のレコードからなる発注データの場合、行ＩＤ「ＳＹＳ００１」のファイルヘッダの下位に、行ＩＤ「ＳＹＳ００２」の伝票ヘッダがリンクまたは従属し、行ＩＤ「ＳＹＳ００２」の伝票ヘッダの下位に、行ＩＤ「ＳＹＳ００３〜ＳＹＳ００７」の伝票明細（１〜５）がリンクまたは従属している。また、行ＩＤ「ＳＹＳ００１」のファイルヘッダには親レコードはないため、その親数は「０」となる。一方、行ＩＤ「ＳＹＳ００２」の伝票ヘッダには親レコードとしてファイルヘッダ（ＳＹＳ００１）があるため、その親数は「１」となる。更に、行ＩＤ「ＳＹＳ００３〜ＳＹＳ００７」の伝票明細には親レコードとして伝票ヘッダ（ＳＹＳ００２）があるため、その親数はそれぞれ「１」となる。一方、複数の親を有するレコードまたはテーブルを管理する場合について説明すると、例えば、顧客単価マスタテーブル（ＳＹＳ９０３）は、顧客マスタテーブル（ＳＹＳ９０１）と商品マスタテーブル（ＳＹＳ９０２）の２つを親として持つ。よって、顧客単価マスタテーブルの行ＩＤ（ＳＹＳ９０３）は、行関連管理テーブルの２行にわたって格納され（ＩＤ＝４７５２及び４７５３）、各行ＩＤの親行ＩＤに、顧客マスタテーブルの行ＩＤ（ＳＹＳ９０１）と商品マスタテーブルの行ＩＤ（ＳＹＳ９０２）とが格納されている。また、顧客単価マスタテーブルの行ＩＤ（ＳＹＳ９０３）は、親数に「２」を格納している。これにより、行関連管理テーブルを参照するだけで、行管理テーブルに格納して特定のレコードの親子関係や階層関係のレコード関連情報を取得することができ、また、その編集も容易となる。
以上のように詳述した本発明に係るデータ管理システムについて、その主要な特徴を以下に要約する。
特徴１：列管理テーブル、行管理テーブル及び値管理テーブルの３つの物理テーブルのみからなる基本的物理データ構造。これにより、従来の物理データ構造のテーブル（物理テーブル）がいくつあっても、その全てのデータ（項目内容及び項目値）を３つの物理テーブル（列管理テーブル、行管理テーブル及び値管理テーブル）で格納・管理できる。
１）列管理テーブルは、従来のテーブルのカラム（各ドメインの属性）を定義・管理するテーブルである。また、列管理テーブルは、従来の各種データ（例えば、図４〜８に示す商品マスタデータ、顧客マスタデータ、顧客単価マスタデータ、在庫マスタデータ、発注データ等）のデータフォーマット（プロファイル）を定義する。即ち、列管理テーブルは、これらのデータを格納する従来のデータの入れ物（物理テーブル）の設計情報（リレーションスキーマ）を定義する。具体的には、列管理テーブルは、データの入れ物（物理テーブル）の設計情報（リレーションスキーマ）である従来の物理テーブルのカラム（データ項目乃至属性とも呼ばれる）のカラム名（データ項目名）を格納する。また、列管理テーブルの各カラム名に対し一意の列ＩＤが付与される。更に、列管理テーブルで定義する管理対象レコードの各データ項目に対応して、列ＩＤの他、当該データ項目のデータ型や位置や長さ等、当該データ項目を定義するための他の情報を格納してもよい。なお、列ＩＤにより、従来の物理テーブルの各データ項目の属性情報（属性名、データ型、長さ等）を一意に識別・取得する。また、列管理テーブルに格納されるデータはマスタデータとなる。また、従来の物理テーブルのカラム名等（例えば、商品マスタテーブルの場合の「商品名」、「商品ＩＤ」）は、本発明の列管理テーブルのカラム（データ項目）としてではなく、データ項目値（各属性の値）として格納・定義される。そして、列管理テーブルのカラム（データ項目）には、データ項目値として格納される従来のカラム（データ項目）を識別する統括名称（「項目名」、「列ＩＤ」、「データ型」等）が定義される。また、例えば、従来の商品マスタテーブルは、カラム（データ項目）として「商品ＩＤ」、「商品名」、「単価」等を所定順序（所定の並び方）で定義し、それらのカラムに対応して、各レコードにおけるデータ項目値（フィールド値）として「００１」、「たばこ」、「２００円」等を格納する。一方、本発明の列管理テーブルは、カラム（「列ＩＤ」、「カラム名」等）のデータ項目値として、従来の商品マスタテーブルのフォーマットを定義する各フィールドの属性（従来のカラムである「商品ＩＤ」、「商品名」等）を格納する。
２）行管理テーブルは、基本的に、インデックス情報を格納するテーブルであり、特定データを読み込んで格納する場合に、読み込み（入力）データの各レコード（従来の物理テーブルの行単位のデータ）を読み込んだ順に、各行を一意に識別するためのインデックスとして行ＩＤを付与し、行ＩＤを行管理テーブルにその順番で格納する。また、行管理テーブルに格納されるデータはトランザクション系のデータとなる。また、例えば、カラムとして「商品ＩＤ」、「商品名」、「単価」等を所定順序（所定の並び方）で定義する商品マスタデータを読み込む場合に、各レコードの値（フィールド値）としての「００１」、「たばこ」、「２００円」（１番目のレコード）、「００２」、「チョコ」、「１００円」（２番目のレコード）・・・を読み込むごとに、行ＩＤを順番に自動生成して行管理テーブルに格納する（「Ｒ０１」、「Ｒ０２」・・・等）。
３）値管理テーブルは、データ項目値（ドメイン値ともいう）を格納するテーブルであり、特定データを読み込んで格納する場合において、読み込み（入力）データの各レコード（従来の物理テーブルの行単位のデータ）を読み込むごとに、当該レコードを構成する各フィールドの値を行ＩＤと対応させて格納する。このとき、当該読込レコードの種類（データ名・テーブル名等）に応じて、列管理テーブルを参照し、該当する種類のレコードのテーブルＩＤを判断・抽出する。これにより、当該テーブルＩＤによりデータ項目名と値とが対応する。或いは、当該レコードを構成する各フィールドの値（データ項目値）を値管理テーブルの一行に全て格納する。このとき、当該読込レコードの種類（データ名・テーブル名等）に応じて、列管理テーブルを参照し、該当する種類のレコードのテーブルＩＤを判断・抽出し、当該テーブルＩＤのデータ項目名の順番で値を格納する。これにより、対応する行のセルに一連のデータ（値）として格納する。各行は行ＩＤで識別され、各値は行ＩＤと列ＩＤとにより特定される。また、値管理テーブルに格納されるデータはトランザクション系のデータである。また、列ＩＤと行ＩＤとにより一意に決定される場所（各フィールド）にデータ項目の各値（各フィールドの値）を格納する。また、各レコードを読み込んだ際に、当該レコードに自動付与された行テーブルの行ＩＤと、当該レコードの設計情報（データ項目の属性情報）を識別する列テーブルの列ＩＤとによりセルを特定（列及び行を特定）し、特定されたセルにデータ項目の値を格納する。
特徴２：業務内容に応じてデータ項目内容（スキーマ）を動的に変更
１）列管理テーブルに、取り扱う全ての管理対象データ（既知のデータ）の定義（従来の物理構造のテーブルの定義）がデータ項目値として格納される。即ち、全てのデータの物理構造（フォーマット定義）が一つの列管理テーブル内に順に格納・定義される。また、列管理テーブルのみを変えることで、動的に項目内容を変更できる。また、データの物理構造と業務内容を分離して管理することができる。
２）いずれかのデータの物理構造（フォーマット定義）が変更された場合（例えば、項目追加・削除・修正）、列管理テーブルのデータ項目値を追加・削除・変更するという通常のデータ編集操作で、そのデータの物理構造の変更を列管理テーブルに反映し、データの物理構造を変更することができる。
３）従来は、入れ物そのものを業務に合わせて作成する。よって、業務内容に応じて、業務内容の数だけ、異なるスキーマ乃至物理データ構造（データフォーマット）を有する複数（多数）のテーブルが必要となる。即ち、従来のテーブルは、それぞれ、業務内容を反映したスキーマを有する。このため、各テーブルのカラムのデータ項目は、スキーマにより固定され、データ項目の修正（追加・削除・編集）には修正用の特殊な処理が必要になる（例えば、市販データベースソフトの場合、テーブルのカラムの各データ項目の追加・削除・編集は、裏でプログラムが処理している）。
４）本発明は、取り扱うデータの全ての情報（列情報、行情報及びセルの値）を上記３つのテーブル（列テーブル、行テーブル、値管理テーブル）に分けて格納する。即ち、全てのテーブルの物理データ構造（列のデータ項目の属性情報）を列テーブルにデータ項目値（マスタデータ）として格納して列ＩＤにより識別し、読み込んだレコードのインデックスを行テーブルに行ＩＤとして格納し、読み込んだレコードの各データ項目値を列ＩＤと行IDとにより決定した値管理テーブルのセルに格納する。よって、業務ルールをデータの物理構造（物理データ構造）に反映しなくてよい。
５）即ち、データを格納する際のテーブルの物理構造（入れ物の設計情報）を列管理テーブルにデータ項目値として格納し、定義している。よって、業務内容がどのようなものであろうと、常に、３つの物理構造のテーブル（列テーブル、行テーブル、値管理テーブル）で全てのデータを処理（格納、取得、加工、出力、表示等）することができる。
６）例えば、顧客テーブル、単価テーブル、顧客販売単価テーブルの３つのテーブルのフォーマットを一つの列管理テーブルに格納・定義する。１レコード入力ごとに行管理テーブルの行ＩＤをインクリメントし、その列ＩＤと行ＩＤとに対応するデータ項目値をセルに入力する。この列管理テーブル、行管理テーブルおよび値管理テーブルを利用して、顧客販売単価プログラムを容易に実現できる。
７）従来は、データを静的に定義している（業務に対応した物理構造のテーブルを定義・設計しており、設計内容にデータ項目が静的に定義されている）。即ち、データの項目内容は、テーブル作成時にテーブルのカラムとして固定されているため、容易に変更することはできない。変更するには、直接属性を追加・削除・変更するというテーブルの再定義が必要。したがって、物理テーブルを修正（項目追加・削除・内容変更）すると、その物理テーブルのテーブル構造（定義）自体が変わることになるため、その物理テーブル用の表示プログラムを修正して修正後のデータを画面表示する必要があった。
８）本発明は、項目追加・削除・変更の場合でも、列管理テーブルの項目値を修正（追加・削除・変更）することで反映できる。即ち、列管理テーブルの項目内容を修正する必要がない（テーブルの物理構造・定義を変更するわけではない）。列管理テーブルの物理構造は、従来のどの物理テーブルに対しても常に共通（同一）の構造となる。よって、表示プログラムを動的に変更することができる。具体的には、プログラムを外出しにしてテーブル化することで、テーブルのデータを変更することにより、プログラムを変更することができる。また、業務に特化した項目は、列管理テーブルの属性としてではなく、項目値として入れる。項目値を追加・削除・変更することは、定義を変更することと比較して容易である。
９）１ランク底の部分（プラグラムの部分）をデータで実行することができる。具体的には、プログラムを外出しにしてテーブル化することで、テーブルのデータを変更することにより、プログラムを変更することができる。
特徴３：列管理テーブルの構成
１）読込レコードのデータフォーマット（カラム定義）に１対１で対応してテーブルＩＤを割当てると共に、同一データフォーマット内でのカラムの順番で連番（シークエンスＮＯ）を割当てて、読込レコードのフィールドと１対１で対応付ける。
２）或いは、特定データフォーマットの読込レコードのフィールドの並び順に１対１で対応して列ＩＤを割り当てる。この場合、列ＩＤはテーブルＩＤ＋連番（シーケンスＮＯ）に１対１で対応する。ここで、前記列ＩＤは、テーブルＩＤ（企業コード＋版コード＋階層コード）と連番（シーケンスＮＯ）との組合せからなるコード（数字）を簡略化したコード体系とすることができる。
特徴４：列管理テーブルのみ分離管理（ネットの別場所）＆一つのビュー
１）列管理テーブルのみ（マスタ系データを取り扱うことから）別管理とすることができる。即ち、管理センターシステム（サーバー）に列管理テーブルをおいてプロファイル情報の管理（更新等）をし、ユーザ側のシステム（クライアント）には列管理テーブルを置かず、管理対象データを読込んで行管理テーブル及び値管理テーブルを作成するプログラムのみをおいて、ネットワークを介して管理センターシステムの列管理テーブルを参照して行管理テーブル及び値管理テーブルを作成するようにする。
２）或いは、管理センターシステムで管理する（最新バージョンの）列管理テーブルを更新（バージョンアップ）があるごとにユーザ側のシステムにダウンロードし、当該列管理テーブルを参照して行管理テーブル及び値管理テーブルを作成するようにする。
３）このように、本発明は、３つのテーブルを分離して（別のＰＣに）格納することができる。例えば、ネットワーク上に分散して格納することができる。
５）ネットワーク上で列管理テーブル（企業プロファイル）のみを管理することで、ユーザは最新のテーブル定義を使用することが可能。例えば、ネット上の企業プロファイルを遠隔で見に行ってもよいし、コピーしても良い。一方、管理者は、別場所で企業プロファイルを編集・管理し、ユーザの要求に応じて配信することができる。
６）別場所で管理しても、ネットワークでつないで一つのビューとして見せることができる。
７）配信するインフラとして、ネットワークが負荷なくつながっていれば、コピーではなく直接見に行ってもよいが、インターネットの場合はトラフィックの問題があるので、通常は自社格納領域にコピーして使用する。
特徴５：データの階層化に対応
１）列管理テーブルにレコードサブＩＤを定義して格納する。即ち、管理対象データが階層構造のレコードをからなる場合、テーブルＩＤに、当該階層構造に対応する階層コード（レコードサブＩＤ）を付加する。即ち、テーブルＩＤに連続するレコードサブＩＤで階層構造を管理する。こうすると、レコードに階層構造を有する管理対象データに対処可能となる。また、テーブルＩＤにレコードブＩＤを付加することで同一データ種別（例えば、ファイルヘッダ、伝票ヘッダ、伝票明細の３層からなる発注データ）内のテーブルＩＤを一意に識別（そのテーブルＩＤがファイルヘッダレコード、伝票ヘッダレコードまたは伝票明細レコードのいずれに属するのかを判別）することができる。また、階層構造については、列管理テーブルに格納されるデータ間に親子関係を確保することで対処することができる。また、行管理テーブルにデータを落とすときにも、列管理テーブルを見て親子関係を確保することができる。
２）テーブルは階層構造のものが多いが、本管理システムにより、システム構成を簡単にすることができる。
特徴６：（列管理テーブルにおける）カラム定義のバージョン管理
１）テーブルＩＤを、特定データフォーマットの管理対象データが属する企業ごとに割り当てた企業コードと、当該企業のデータフォーマットの版をあらわす版コードとにより構成する。こうすると、テーブルＩＤの版コードを参照することにより、データフォーマットのバージョン管理が可能になる。
２）列管理テーブルにプロファイルの利用期間乃至有効日（自）・有効日（至）等の日時情報を定義し、データ変換時には、当該データ項目の値を参照して、利用可能なバージョンのカラム定義を参照する。
３）旧バージョンのデータ変換が必要な場合は、旧バージョンの利用期間を有するカラム定義を利用する。
４）テーブルＩＤや列ＩＤを構成する企業コード（版）に版情報を付加し、当該版情報を参照する。
特徴７：項目関連定義テーブル
１）項目関連定義テーブルで異種フォーマット間の関係（データ項目間関連情報）を定義（項目関連定義）することができる。
２）標準フォーマットを介した異種フォーマット（Ａ⇔Ｂ）間のデータ変換賀可能になる。直接フォーマット変換する従来のマッピングと比較して、システム構成が大幅に簡易化される。
３）また、データ変換プログラム自体も関数管理テーブルに定義することができる（プログラムの演算内容及びパラメータの外出し）。そして、項目関連定義テーブルのデータ項目「関数」に格納した値（関数情報）を参照することで、当該列ＩＤの値について所定の演算処理を行うことができる。また、プログラム内容やパラメータの変更を、関数管理テーブルの内容を変更（データ入力処理）するだけで対処でき、プログラム自体を変更する必要がない。
４）例えば、フォーマットＡ（発注者独自）をフォーマットＢ（受注者独自）に変換する場合、標準フォーマットＳを介して、Ａ（発注者Ｆ）の各項目とＳ（標準Ｆ）の各項目間のチェーン（リンク情報）を予め定義すると共に（Ａ⇔Ｓ）、Ｓ（標準Ｆ）の各項目とＢ（受注者Ｆ）の各項目間のチェーン（リンク情報）を予め定義する（Ｓ⇔Ｂ）。これにより、Ｓ（標準Ｆ）を仲介にして、Ａ（発注者Ｆ）とＢ（受注者Ｆ）との間でのデータ変換を実行する。
５）標準フォーマット（標準プロファイル）は業界ごと（業務の種類ごと）に作成可能である。
６）カラムチェーンテーブルは、トリガとなるＡフォーマットのデータ項目（例えば発注者プロファイルのあるデータ項目）が入力されると、そのデータ項目に対応する標準フォーマットのデータ項目（標準プロファイルの対応するデータ項目）を仲介して、その標準フォーマットのデータ項目に対応するＢフォーマットのデータ項目（受注者プロファイルの対応するデータ項目）を取得する。
７）具体的には、以下のようにデータ変換処理される。まず、列管理テーブルに、特定業務（例えば、受発注業務）に対応する標準データフォーマットを定義する標準プロファイル（一つ）と、当該特定業務について特定の取引先企業・組織が使用する独自のデータフォーマットを定義する取引先プロファイル（取引先企業・組織の数だけ）と、当該特定業務について当該企業・組織と取引するユーザが使用するユーザ独自のデータフォーマットを定義するユーザプロファイル（通常は一つ）とをそれぞれ作成してマスタデータとして格納する。また、項目関連定義テーブルに、取引先プロファイルの特定のデータ項目と当該データ項目に対応する標準プロファイルのデータ項目との間のリンク情報を格納する。具体的には、取引先プロファイルのデータ項目の列ＩＤと当該データ項目に対応する標準プロファイルのデータ項目の列ＩＤとを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、取引先プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。同様に、項目関連定義テーブルに、標準プロファイルの当該データ項目と当該データ項目に対応するユーザプロファイルのデータ項目との間のリンク情報を格納する。具体的には、ユーザプロファイルのデータ項目の列ＩＤと当該データ項目に対応する標準プロファイルのデータ項目の列ＩＤとを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、ユーザプロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。したがって、例えば、取引先プロファイルのデータ（取引先データ）をユーザプロファイルのデータ（ユーザデータ）に変換する場合、項目関連定義テーブルを参照し、ユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする取引先プロファイルのデータ項目の列ＩＤを取得する。そして、値管理テーブルを参照し、当該取得した取引先プロファイルの列ＩＤのデータ項目の値を、ユーザプロファイルの対応する列ＩＤの値として取得する。これにより、標準プロファイルを介して、取引先プロファイルの取引先データからユーザプロファイルのユーザデータへのデータ変換が実現される。
８）次に、値管理テーブルに格納したデータの出力・表示（印刷・画面表示）については以下のように処理される。まず、値管理テーブルに格納されるデータは、データの一元性を維持する等の目的で、一次データ（読み込みデータ）としての取引先データのみである。 よって、当該取引先データに対応するユーザデータを出力・表示する場合、ユーザデータの各データ項目に対応する取引先データの各データ項目の値を、上記のように標準プロファイルの対応するデータ項目を介して値管理テーブルから取得し、取得した各々の値をユーザデータの対応するデータ項目の値として、ユーザプロファイルにしたがって（ユーザデータ独自のフォーマットで）、ユーザデータのデータ項目とセット（組）で出力・表示する。このとき、表示形式（出力イメージを制御するパラメータとしての表示枠の寸法、各データ項目の表示位置、フォント等）は、表示プログラムに定義されている。或いは、後述するように、表示形式を定義する帳票（画面）定義テーブル（ＦＯＲＭ＿ＣＯＬＵＭＮテーブル）を用意し、パラメータを外出ししても良い。こうすると、表示形式を変更するたびにプログラムを変更する必要がなく、表示形式の変更を簡単に行うことができる。
特徴８：項目値管理テーブル
１）項目値の意味の相違を自動変換（カラムバリュー）⇒テーブルに定義するため、プログラムで処理する場合と比較して、テーブルのデータ項目及びその値のみを変更すればよく、システム構成が簡単になる。また、データ項目値の標準化が可能となる。
特徴９：受発注システムのデータ構造（テーブル構造）
１）列管理テーブルの内容
テーブルＩＤ＝企業コード＋データ種類コード＋枝番とすることができる。各テーブルＩＤは、複数階層のレコードからなる一つのデータの各レコード種別を一意に表す（例えば、発注データの場合、ファイルヘッダレコード、伝票ヘッダレコード、伝票明細レコード）。また、列管理テーブルの連番（シーケンスＮＯ）は、同一テーブルＩＤ内のデータの順番を示す。また、列ＩＤは、企業コード、データ種類コード、枝番及び連番に基づき自動生成される一意のＩＤとしてもよい。また、各列ＩＤごとに項目名称、即ち、データ項目（フィールド）の名称が付与される。即ち、各列ＩＤが、複数のフィールドからなる一つのレコードの各フィールド種別や属性（定義内容）を一意に表す（例えば、ファイルヘッダレコードの場合、そのレコード区分、データ種別、データ作成日等のフィールド名、データ型、位置、最大・最小バイト数、識別子の連番、主要格納情報番号、列サブＩＤ等）である。また、上記のように、日付情報をバージョン管理に利用できる。また、企業コードの末尾２桁は当該企業のフォーマットのバージョンを表すため、やはり、バージョン管理に利用できる。主要データ項目として、列ＩＤ（企業（版））は、各データ項目（各フィールド）を一意に識別し、テーブルＩＤ＋シーケンスＮｏ．（連番）と１対１に対応（テーブルＩＤ＋シーケンスＮｏ．を加工して生成）する。また、変換メソッド（関数）は、当該列ＩＤのデータ項目値を変換する必要がある場合に、その変換に利用するメソッド名を定義する（例：ＣＯＬＵＭＮ＿ＶＡＬＵＥ）。ポジションは、当該データ項目のレコード先頭（０）からの位置を示す。レングスは、最大・最小レングスを示す。識別子作成順序は、当該レコードの識別子（検索キー）を構成するデータ項目の順番を指定する（例:発注データのファイルヘッダレコードの場合（１）発注企業コード（２）データ種別（３）データ作成日、伝票ヘッダレコードの場合（１）伝票番号、伝票明細行の場合（１）明細行番号（２）ＧＴＩＮコード）。また、基本項目指定順序は、当該レコードの全データ項目（全フィールド）のうち行テーブルに複写する基本データ項目について、当該主要データ項目の値を行テーブルの何番目の基本情報に複写するかを連番で指定する（例:発注データのファイルヘッダレコードの場合（１）発注企業コード（２）受注企業コード（３）データ種別（４）データ作成日（５）データの全レコード数、伝票ヘッダレコードの場合（１）伝票番号（２）伝票区分（発注日）（３）発注日（納品指定日）（４）納品先企業コード（店舗コード）（５）納品先店舗コード（取引先名称）、伝票明細行の場合（１）ＧＴＩＮコード（２）品名カナ（３）規格カナ（４）数量（５）原単価）。また、列サブＩＤは、当該データ項目の値を行テーブルの突合項目に格納する場合に、そのデータ項目のオブジェクトＩＤ（対象管理テーブル参照）を指定する（例：発注データのファイルヘッダレコードの場合⇒（１）、発注店舗コード伝票ヘッダレコードの場合（１）伝票番号（２）発注日（または、（１）伝票番号（２）発注日（３）店舗コード）、伝票明細行の場合（１）伝票番号（２）行番号（３）ＧＴＩＮコード）。また、有効日時（自）＆（至）は、バージョン管理に利用できる。
特徴１０：受発注システムのデータ入力（データ読み込み）処理⇒テーブル管理テーブルに制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）を定義し、データ入力するため、データフォーマットの変更に対しては、データ項目値としての同ＣＯＮＴＲ０ＯＬ＿ＩＮＩのみを変更すればよく、プログラム（内部のパラメータ）を変更する必要がない。
１）ユーザー企業のデータ管理システム（ｅＤＩＹ）のボリュームを企業（取引先企業である発注企業）ごとに分割し、システム起動時に、処理すべきデータ（読み込みデータ）の企業（発注企業）を指定させる。
２）データ交換前に、データ交換管理テーブル（発注企業コード、受注企業コード、データ種別等）を参照し、指定した企業（発注企業）が、当該取引（発注）を、ユーザー企業（受注企業）と行っているか否かをチェックする。
３）テーブル管理テーブルのレコードサイズ（例えば、１２８バイト、２５６バイト、５１２バイト等）を参照し、読み込んだデータを当該レコードサイズ単位（１２８バイト等の単位）に順番に切り分けて読み込む。
４）同時に、読み込んだ各レコードについて、テーブル管理テーブルにおいて当該（発注企業コードの）企業のデータプロファイル（データフォーマット）に関して定義したレコード制御情報（ＣＯＮＴＲＯＬ＿ＩＮＩ）（特定のレコードであることを示す項目値の位置と内容を記述したもの）を参照し、読み込んだレコードが合致したレコード制御情報を有するテーブルＩＤコードを特定して取得する。
５）列管理テーブルを参照し、列管理テーブルの当該テーブルＩＤコード相当部分をメモリに読み込む。
６）順番に切り分けて読み込んだレコードに対し、その順番で行ＩＤを付与（自動生成）して行管理（ＲＯＷ）テーブルを作成する（例：発注企業コード（版）＋受注企業コード（版）＋データ種別＋読み込み日＋読み込み時刻）。
７）同時に、列管理テーブルの列サブＩＤ（＝オブジェクトＩＤ）を参照し、当該テーブルＩＤを有するレコードのデータ項目値から、当該テーブルＩＤについて定義した突合項目の項目値を各行ＩＤに対して割当て格納する。例えば、伝票ヘッダレコードについて、納品店舗コード（列サブＩＤ＝１１）、伝票番号（列サブＩＤ＝２０２０１）、発注日（列サブＩＤ＝２０１０１）が突合項目として定義されている場合、その項目値である店舗コードの値（１００）、伝票番号の値（４９２１８＊＊＊）、発注日の値（２００５０１１３）を当該伝票ヘッダレコードの突合項目値として格納する。また、当該伝票ヘッダレコードに従属する伝票明細行レコードについて、納品店舗コード、伝票番号、明細行番号（２０２０１１）、ＧＴＩＮコード（列サブＩＤ＝３）、発注日が突合項目として定義されている場合、その項目値である店舗コードの値、伝票番号の値、明細行番号の値（０１等）、ＧＴＩＮコードの値（０４９＊＊＊＊＊＊＊＊＊＊＊＊＊）、発注日の値を当該伝票明細行レコードの突合項目値として格納する。このように、受発注データの突合作業において必要となるデータ項目値（例えば、店コード、伝票番号等）を突合項目値として列管理テーブルに予め定義する。これにより、例えば、ピッキング作業において特定の伝票番号の特定の明細行の製品の欠品（例：発注数量５０に対して検収数量３０）が判明した場合、ユーザ企業が（受注データを基に）作成する出荷データを作成する場合に、当該欠品数量を反映した出荷数量（検収数量）を入力することにより、両突合項目値間の突合を介して、当該欠品状況（発注数量を二重線で取り消し、その下側に検収数量を記入）を出荷伝票に自動記入すること（突合による修正の自動反映）が可能となる。
８）同時に、列管理テーブルの基本項目指定順序を参照し、当該テーブルＩＤを有するレコードのデータ項目値から、当該テーブルＩＤについて定義した基本項目値を各行ＩＤに対して割り当てて格納する。例えば、伝票ヘッダレコードについて、発注日、納品日、検収日が基本項目として指定されている場合、それらの項目値（及び属性）を格納し、伝票明細レコードについて、ＧＴＩＮコード、伝票番号、明細行番号、ＧＴＩＮコードが基本項目として定義されている場合、その項目値である店舗コードの値（及び属性）、伝票番号の値（及び属性）、明細行番号の値（及び属性）、ＧＴＩＮコードの値（及び属性）を当該伝票ヘッダレコードの基本項目値（及び属性）として格納する。これにより、データの表示出力時に、行管理（ＲＯＷ）テーブルの基本項目値のみ読み込んで、迅速に表示することができる。
９）更に、その他のデータ項目値（当該レコードのテーブルＩＤ、識別子ＩＤ、識別値等）を格納して行管理テーブルを作成することもできる。
１０）行管理テーブル作成と同時に、順番に切り分けて読み込んだレコードを、列管理テーブルを参照し、そのテーブルＩＤの連番または列ＩＤにしたがって、当該レコードを構成する全てのデータ項目（フィールド）の順に分割し、それぞれのデータ項目値を対応する値格納セル（値１〜３０）に格納して値管理テーブルを作成する。このとき、値格納セルは、各データ項目値（各フィールドの値）を格納する物理上のセル（値管理テーブルの「カラム（データ項目）」としての「値１・・・」と「行」としての「行ID」とが交差する欄乃至格納域）であるが、論理的には、（ＦＨ，ＤＨ，ＤＤの各フォーマット種類のレコードごとに割り当てられる）テーブルＩＤと（各レコードについて一意に割り当てられる）行ＩＤとにより一意に決定される論理セル（カラムとしての一連のテーブルＩＤと行IDとが交差する欄乃至格納域である論理上のセル）に一レコードの全フィールドが格納されるイメージである。こうすると、列ＩＤと行ＩＤとが交差する欄を一つの論理セルとし、当該一つの論理セルに各フィールドの値を格納する場合と比較して、処理速度を向上することができる。即ち、テーブルＩＤと行ＩＤとにより決定される一つの論理セルに一レコードの全フィールドが格納されると共に、それらのフィールドは当該一レコードに属する一連の値であるため、当該レコードに割り当てた検索キーを利用して、迅速な値の取得等が可能になる。
１１）値管理テーブルの各論理セルに格納するデータ項目値の数が３１以上の場合、当該論理セルの次に第２の論理セルを連続して設け、当該第２の論理セルのセルシーケンスＮＯを「１」から「２」にして、当該第２の論理セルの値格納セル（値１〜３０）に３１番目以降のデータ項目値を上記と同様にして順次格納する。
１２）発注データの全レコードの全ての値を値管理テーブルに格納したら、当該発注データが一次データとなる。よって、それ以降の統一伝票データ（２９）、入荷予定データ（伝票）（３０）、入荷予定データ（梱包）（４０）、受領データ（５０）、請求データ（６０）、支払いデータ（７０）の表示（帳票印刷・画面表示）や特定形式（特定伝票形式等）でのデータ出力は、項目関連定義テーブルを参照し、前記一次データのデータ項目と対応する各データのデータ項目とのリンク情報を取得して、当該一次データのデータ項目を各データのデータ項目に置き換える形で実行される。これにより、常に一次データを利用してデータの一元性を確保した上で、各種帳票や各種画面の表示（印刷・表示）やデータ出力を行うことができる。
１３）データ読み込みを全自動化する場合、以下のように処理する。但し、ＣＯＮＴＲＯＬ＿ＩＮＩにより一意にレコードを特定できる必要がある（ＣＯＮＴＲＯＬ＿ＩＮＩが重複して存在する場合は不可）。即ち、上記と同様にしてデータ読み込む。但し、読み込みデータの発注企業を指定することなく、全ての発注企業について上記と同様の処理を行う。この場合、完全自動化により手間は諸略できるが、その分、処理時間が長くなる。次に、テーブル管理テーブルを参照して入力データの種別（例えば、発注データ）を（例えば、データタイトル等から）判別及び解析し、そのデータを各レコードに分割する。その際、各レコードに対応するテーブルＩＤ（＋レコードサブＩＤ）を付与する。そして、列管理テーブルを参照し、対応するテーブルＩＤ（＋レコードサブＩＤ）のレコード定義を取得する。同時に、行管理テーブルと値管理テーブルを作成する。
特徴１１：異なるフォーマット間のデータ変換及び指定形式でのデータ表示（帳票の画面表示または印刷）・データ出力（ＣＳＶ等出力・保存）処理。これにより、データの一元管理（発注企業データ（一次データ）を利用した同等のビューによる表示）⇒ユーザ企業の納品データや請求データ等、発注企業データから数量等に変更のあるデータは、発注企業データの当該項目のみを変更した（発注企業データを基にした）出力データ（ＣＳＶ）を利用してデータ出力される。よって、データの一元性が保持される。
１）まず、列管理テーブルに、特定業務としての受発注業務の各データ種別（発注データ、統一伝票データ、入荷予定データ（ＡＳＰ）、受領データ、請求データ、支払データ、返品データ等）に対応する標準データフォーマットをデータ種別の数だけ定義する標準プロファイル（各データ種別に一つ）と、当該受発注業務についての発注企業（多数）独自のデータフォーマットを当該発注企業が使用するデータ種別（発注データ、統一伝票データ、受領データ、支払データ、返品データ等）の数だけ定義する発注企業プロファイル（各発注企業の各データ種別に一つ）と、当該受発注業務についてのユーザ企業独自のデータフォーマットを当該ユーザ企業が使用するデータ種別（発注データ、統一伝票データ、入荷予定データ（ＡＳＰ）、請求データ等）の数だけ定義するユーザ企業プロファイル（通常は一つ）とをそれぞれ作成してマスタデータとして格納する。
２）また、リンク間列管理テーブルに、発注企業プロファイルの特定のデータ項目と当該データ項目に対応する標準プロファイルのデータ項目との間のリンク情報を格納する。具体的には、発注企業プロファイルのデータ項目（例：データ作成日）の列ＩＤ（９９９９９９０１２０１００３）と当該データ項目に対応する標準プロファイルのデータ項目（データ作成日）の列ＩＤ（１２０１００３）とを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、発注企業プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。同様に、リンク間列管理テーブルに、標準プロファイルの当該データ項目と当該データ項目に対応するユーザ企業プロファイルのデータ項目との間のリンク情報を格納する。具体的には、ユーザ企業プロファイルのデータ項目（データ作成日）の列ＩＤ（１１１１１１０１２０１００３）と当該データ項目に対応する標準プロファイルのデータ項目（データ作成日）の列ＩＤ（１２０１００３）とを、リンク間列管理テーブルの同一行に格納して関連付け、１対１でリンクする。これにより、ユーザ企業プロファイルの全てのデータ項目と標準プロファイルの全てのデータ項目とが１対１で対応する（リンクする）。
３）したがって、例えば、発注企業プロファイルのデータ（例：発注データ）をユーザ企業プロファイルのデータ（ユーザ指定形式の受注データ）に変換する場合、まず、ユーザが指定したデータ内容（受注データ）に応じて、リンク間列管理テーブルを参照し、指定データ（表示すべきデータ）のユーザプロファイル（受注データ用プロファイル）のテーブルＩＤ（１１１１１１０１２０１等）を判断し、当該テーブルＩＤに属する全てのデータ項目の列ＩＤ（１１１１１１０１２０１００１等）を順に（当該プロファイルの全データ項目分）取得する。次に、リンク間列管理テーブルを参照し、取得したユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする発注企業プロファイルのデータ項目の列ＩＤを取得する。そして、発注企業プロファイルの発注データの値を格納する値管理テーブルを参照し、当該取得した発注企業プロファイルの列ＩＤのデータ項目の値を、項目順（列ＩＤ順）に、ユーザ企業プロファイルの対応する列ＩＤの値として取得する。これにより、標準プロファイルを介して、取引先企業プロファイルの取引先データからユーザ企業プロファイルのユーザデータへのデータ変換が実現される。
４）次に、値管理テーブルに格納したデータの表示（帳票印刷・画面表示）については以下のように処理される。ここで、値管理テーブルに格納されるデータは、データの一元性を保持する等の目的で、一次データ（読み込みデータ）としての発注企業プロファイル形式の発注企業データ（デフォルトデータ）のみである。標準プロファイル形式のデータ（標準データ）やユーザ企業プロファイル形式のデータ（ユーザ指定データ）は、実際に別個の（それらに固有の）値管理テーブルに格納されるわけではなく、発注企業データを実際に格納する値管理テーブルから当該発注企業データのデータ項目の値を取得して、その値を、標準プロファイルやユーザ企業プロファイルのデータ項目とセットで表示することにより、一般的な（従来の）物理構造のテーブルと同等のビューによる表示を実現する。そして、発注企業プロファイル形式の発注企業データをそのまま表示する場合、当然データ変換は不要であるため、まず、列管理テーブルを参照する。一方、ユーザ企業が指定する表示形式のデータ（ユーザ指定データ）を表示する場合、まず、ユーザプロファイル（受注データ用プロファイル）のテーブルＩＤ（１１１１１１０１２０１等）を判断し、当該テーブルＩＤに属する全てのデータ項目の列ＩＤ（１１１１１１０１２０１００１等）を順に（当該プロファイルの全データ項目分）取得する。次に、列管理テーブルを参照し、次に、リンク間列管理テーブルを参照し、そして、値管理テーブルを参照する。よって、当該取引先データに対応するユーザデータを表示する場合、ユーザ企業指定のユーザ企業プロファイルによる受注データの各データ項目に対応する発注企業データの各データ項目の値を、上記のように標準プロファイルの対応するデータ項目を介して値管理テーブルから取得し、取得した各々の値をユーザ企業指定の受注データの対応するデータ項目の値として、ユーザ企業プロファイルにしたがって（ユーザ企業指定の受注データ独自のフォーマットで）、ユーザ企業指定の受注データのデータ項目とセット（組）で出力・表示することができる。このとき、表示形式（出力イメージを制御するパラメータとしての表示枠の寸法、各データ項目の表示位置、フォント等）は、表示プログラムに定義されている。或いは、上記のように、表示形式を定義するテーブル（ＦＯＲＭ＿ＣＯＬＵＭＮテーブル）を用意し、パラメータを外出ししても良い。こうすると、表示形式を変更するたびにプログラムを変更する必要がなく、表示形式の変更を簡単に行うことができる。一方、取引先プロファイルのデータ（取引先データ）をユーザプロファイルのデータ（ユーザデータ）に変換して出力（印刷・表示）する場合、まず、ユーザプロファイルのデータ項目の列ＩＤとリンクする標準プロファイルのデータ項目の列ＩＤを取得し、次に、当該標準プロファイルのデータ項目の列ＩＤとリンクする取引先企業プロファイルのデータ項目の列ＩＤを取得する。
特徴１２：帳票カラム（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブル及び帳票（ＦＯＲＭ）テーブル
１）基本は、「テーブル⇔テーブル」間のデータ変換だが、追加仕様として、テーブル⇒帳票（ＦＯＲＭ）のデータ変換も可能。
２）従来はプログラムにパラメータとして定義していた帳票の印刷表示形式（帳票のイメージファイル、イメージの表示位置、文字列の表示位置、長さ、フォント、フォントサイズ等）をプログラムから外出しし、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルに定義した。よって、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルを更新するだけで（データ入力作業をするだけで）各種帳票のフォーマット変更に対応できる。なお、ＦＯＲＭ＿ＣＯＬＵＭＮテーブルは、カラムのデータ項目値と帳表のデータ項目値を１対１に紐付けるテーブルである。また、カラムのデータ項目を動的に変更するように、帳表もデータを追加・削除・変更することで動的に変更する。なお、従来は、プログラムで帳表を変更する必要があった。
特徴１３：表示画面カラム（ＦＯＲＭ_ＣＯＬＵＭＮ）テーブル及び表示画面（ＦＯＲＭ）テーブル
１）更に、テーブル⇔表示画面間でデータリンクが可能となる。
２）従来はプログラムにパラメータとして定義していた帳票の画面表示形式（帳票のイメージファイル、表示位置、文字列の表示位置、長さ、フォント、フォントサイズ等）をプログラムから外出しし、ＦＯＲＭ_ＣＯＬＵＭＮテーブルに定義した。よって、ＦＯＲＭ_ＣＯＬＵＭＮテーブルを更新するだけで（データ入力作業をするだけで）各種表示画面のフォーマット変更に対応できる。なお、画面⇔カラムが、データをいじるだけで一つのプログラムで（プログラムを修正することなく）全て可能となる。
３）また、画面表示された帳票の表示欄を入力域としてテーブルに定義した。よって、同画面を利用して客注入力が可能となる。また、画面表示した帳表を画面としてとらえて各枠を入力域とすることができる。また、データの内容チェックは列管理テーブルの定義（属性）を参照することもできる（例：日付（ｄａｔｅ）に数値（ｎｕｍｂｅｒ）を入れるとエラー処理）。また、列管理テーブルの属性を見て、ドロップダウンリスト等のリスト表示によりユーザに所望のデータ項目を選択させることも可能。データの互換は、カラムバリューを見てもってくる。チェーンを張ることで、入力のまま使用可能となる。
４）客注入力
ユーザシステム起動時に、ユーザーは、ボリューム定義を選択できる（どの取引先企業（発注企業）のボリュームを最初に出すか）。ボリュームを選択すると、ユーザーシステムが立ち上がり、「客注入力」メニューが表示される。同メニューには、入力欄がある。所定様式（フォーマット）の納品書をバックに、仕入伝票入力が可能である。従来の表示プログラムは、ＤＢのワーク領域に格納した（値管理テーブルのデータ項目値に相当する）データ項目値を、画面に表示した所定様式の帳票（納品伝票）の所定地位に出力して表示する。一方、本発明は、ＣＯＬＵＭＮテーブルとＦＯＲＭ＿ＣＯＩＬＵＭＮテーブルとを１対１に対応させ、ＦＯＲＭテーブルからＦＯＲＭ_ＣＯＬＵＭＮテーブルを介してＣＯＬＵＭＮテーブルのテーブルＩＤを有する値管理テーブルの対応するデータ項目に値を格納するため、実際に画面表示した帳票を利用して、その帳票の表示欄に、直接、必要な値を入力可能である。
５）属性も列管理テーブルに入れることができる。
６）ＦＯＲＭ_ＣＯＬＵＭＮテーブルは、入力に特化したデータ（表示場所、大きさ、フォント種類等）を取り扱う。
特徴１４：発注データと納品データの突合せ、訂正反映処理
１）納品店舗コード、伝票番号、ＧＴＩＮコード、発注日付等を突合項目（検索時のインデックス項目（検索キー））として指定できる。
特徴１５：上記データを配信してＡＳＰ実現がかのうとなる（例えば、図１７）。
１）同じデータ定義を参照して運用（カラム定義を外出し、管理団体が管理してユーザに配信）する。
２）応用として、電子カルテへの適用も可能である。例えば、岐阜県の定義（フォーマット）及び標準定義並びにそのチェーンをダウンロードして、自県（東京等）の定義とマッピングすることができる。
特徴１６：データ配布（初回配布、初回システム稼動時）
１）ユーザが配布データをＦＴＰでダウンロード（ダウンロード後自動削除）する。
２）ユーザー企業情報を顧客管理テーブルから取得する。
３）取引関係情報をデータ交換管理テーブルから取得する。
４）ユーザー企業が選択した標準プロファイルを列管理テーブルから取得し、カラム値を項目値管理テーブルから取得する。
５）取引先の企業プロファイルに関してテーブル管理テーブル、列管理テーブル、項目値管理テーブル、項目関連定義テーブルを利用する。
６）標準プロファイルを複写してユーザープロファイルとする場合、同ユーザープロファイルを列管理テーブル、項目関連定義テーブルから判断する。
７）システム稼動後、取引先の増減が発生した場合、（１）〜（６）までの同様の処理を繰り返す。そして、ユーザが電子商取引を行う取引先を再選択する。
特徴１７：プロファイルのバージョンアップ
１）企業プロファイルのバージョンアップ処理（共通）
システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在の企業プロファイルのバージョンをセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
１−１）ユーザーシステムの企業プロファイルのバージョンが古い場合、センターシステムは、その旨及びバージョンアップの内容をユーザーシステムに通知する。ユーザーが更新ボタンをクリックした場合のみ、センターシステムは企業プロファイルのバージョンアップを実行する。この際、ユーザーシステムが指定する1企業（バージョンアップされた１企業プロファイル）毎に、ユーザーに確認を促す。
１−２）ユーザーシステムは、バージョンアップ完了時、そのステータスをシステムサポートセンターに通知する。
２）企業プロファイルのバージョンアップ情報（共通）
２−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在利用している企業プロファイルの情報をセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
２−２）企業プロファイルのバージョンアップが予定されている場合、ユーザーシステムは、システムサポートセンターのＷＥＢにアクセスし、バージョンアップの内容を確認できるページを表示する。この際、バージョンアップが予定される１企業（バージョンアップされる１企業プロファイル）毎のＵＲＬ（バージョンアップ情報が格納されるページのＵＲＬ）を表示する。
２−３）バージョンが新旧入れ替わる場合の対処方法も同時に表示する。
２−４）テストモードでのシステム起動も可能とする。
２−５）新企業プロファイルでの運用は、ユーザーシステムが、新旧企業プロファイルを定義する新旧列管理テーブルの日付情報（新プロファイルの利用可能開始日・終了日等）を参照して、自動切替により実行する。この際、ユーザーシステムは、旧フォーマット（旧プロファイル形式）の蓄積データのバックアップ（及び削除）を促す。事故防止のため、ユーザーシステムは、旧バージョンの企業プロファイルは残す一方、列管理テーブルの日付情報（利用可能開始日や削除日等）を利用して、データ変換には利用できないようにする。
３）標準プロファイルのバージョンアップ処理（共通）
３−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在の標準プロファイルのバージョンをセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
３−２）ユーザーシステムの標準プロファイルのバージョンが古い場合、センターシステムは、その旨及びバージョンアップの内容をユーザーシステムに通知する。ユーザーが更新ボタンをクリックした場合のみ、センターシステムは標準プロファイルのバージョンアップを実行する。この際、ユーザーは、ユーザープロファイルと新標準プロファイルとの関連定義を指定する必要がある（新項目関連定義テーブル生成）が、ユーザーシステムは、（ユーザー企業が以前に指定した）旧標準プロファイルとユーザープロファイルの関連定義（項目関連定義テーブル）を参照し、旧ユーザープロファイルの生成を保障するものとする。
３−３）ユーザーシステムは、バージョンアップ完了時、そのステータスをシステムサポートセンターに通知する。
４）標準プロファイルのバージョンアップ情報（共通）
４−１）システム起動時に、或いは、起動後のタイマー監視により、ユーザーのシステムは、システムサポートセンターのシステムに自動的（またはユーザの確認後）アクセスし、現在利用している標準プロファイルの情報をセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
４−２）標準プロファイルのバージョンアップが予定されている場合、ユーザーシステムは、システムサポートセンターのＷＥＢにアクセスし、バージョンアップの内容を確認できるページを表示する。
４−３）企業プロファイルのバージョンアップ時とは異なり、標準プロファイルの切替前には、独自のユーザープロファイルを利用しているユーザー企業側での新標準プロファイルの十分なテスト（新標準プロファイルによる稼動試験）が必要であるが、標準プロファイルのバージョンアップ自体は、プログラムにより自動で行うようにする（以下の（５）参照）。
４−４）新標準プロファイルでの運用タイミング（標準プロファイルの切替タイミング）は、ユーザーが指定するが、新旧標準プロファイルの切替時には、ユーザーシステムが、列管理テーブルの日付情報（利用可能開始日・終了日や削除日等）を利用して自動切替を実行することが好ましい。
４−５）なお、標準プロファイルは、企業プロファイルのバージョンアップまたは新企業プロファイルの追加の場合にバージョンアップされるものではなく、システム自体のバージョンアップがあった場合（例えば、XML対応）に、バージョンアップする。
５）標準プロファイルのバージョンアップ処理プログラム
５−１）企業プロファイル⇔旧標準プロファイル、ユーザープロファイル⇔旧標準プロファイル、旧標準プロファイル⇔新標準プロファイルの３つの関係（項目関連定義テーブルの関連定義）を参照し、企業プロファイル⇔新標準プロファイルの関連定義、ユーザープロファイル⇔新標準プロファイルの関連定義を新しく作成する（項目関連定義テーブルに反映して項目関連定義テーブルをバージョンアップする）プログラム。
５−２）このとき、旧標準プロファイル⇔新標準プロファイルの関連定義、及び、企業プロファイル⇔新標準プロファイルの関連定義は、システムサポートセンター側で先に作成してユーザーシステムに配信する。この関連定義は、上記（１）のように、バージョンアップ処理プログラムで作成可能である。
５−３）ユーザープロファイル⇔新標準プロファイルの関連定義作成処理は、ユーザー側のシステムで実行する。
５−４）旧標準プロファイルは、当該旧標準プロファイルとチェーン（リンク）している全てのプロファイル（企業プロファイル及びユーザープロファイル）が無効になった場合に無効にする。
６）ユーザープロファイルのバージョンアップ（共通）
６−１）バージョンアップに関してはユーザー任意である。システムサポートセンターがユーザープロファイルをもサポートする場合、ユーザーシステムがサポートセンターにアクセスし、利用しているユーザープロファイルの情報をサポートセンターシステムに通知する。このとき、ユーザーＩＤを利用する。
６−２）すると、上記企業プロファイルのバージョンアップと同様の処理が実行される。
７）企業プロファイルの利用停止
７−１）ユーザ企業が、（今まで利用していた）特定の企業プロファイルを利用停止した場合、取り消された（利用停止された）企業プロファイルの定義情報（列管理テーブルの該当部分）は、過去の（当該企業プロファイルが使用されている）データを閲覧する際に必要なため、ユーザシステムのＤＢより削除せず残す設定とする。
７−２）但し、取り消し後は、ユーザー企業が当該企業プロファイルを利用してデータ変換できないように制御する。例えば、当該ユーザー企業のユーザキーの値と取り消された企業プロファイルの利用状況との整合性をチェックすることで対応する。
特徴１８：電子帳簿保存法への対応
ボリューム構成でＳＬＩＰ（伝票バックアップ領域）に伝票を納品書イメージとして、編集不可形式のデータフォーマットで格納する（例えば、ＪＰＥＧ等のイメージファイル）。
読み込みデータの自動入力
１）１企業単位にボリュームを設定するため、取引先企業が３００あると、ボリュームも３００存在する。ユーザーがこの中から読み込みデータに対応するボリュームを選択し、1企業単位で対応するボリュームにデータを格納する。データが毎日入ってくるような場合、そのたびにデータ格納対象のボリュームを選択し、データ入力するのは面倒。よって、自動実行プログラムを作成することにより対処する。
特徴１９：複数業界仕様への対応
１）Ａ業界、Ｂ業界・・・等、異なる業界（例えば、ホームセンター業界とドラッグストア業界）でシステムを運用する場合、Ａ業界用標準プロファイルとＢ業界用標準プロファイルとの間での関連定義を設ける（例えば、ホームセンター標準⇔ドラッグストア標準）。これにより、ユーザー企業が複数の業界に位置して商取引を行うことが可能となる。Ａ業界用としては、（Ａ業界の発注企業の）企業プロファイルとＡ業界用標準プロファイルとの関連定義（Ａ企業⇔Ａ標準）、Ａ業界用標準プロファイルとユーザープロファイルの関連定義（Ａ標準⇔ユーザ）が定義され、これら２つの関連定義（項目関連定義テーブル）を介して、Ａ業界の企業プロファイルとユーザープロファイルとの間でのデータ交換が実現する。また、Ｂ業界用としては、（Ｂ業界の発注企業の）企業プロファイルとＢ業界用標準プロファイルとの関連定義（Ｂ企業⇔Ｂ標準）、Ｂ業界用標準プロファイルとユーザープロファイルの関連定義（Ｂ標準⇔ユーザ）が定義され、これら２つの関連定義（項目関連定義テーブル）を介して、Ｂ業界の企業プロファイルとユーザープロファイルとの間でのデータ交換が実現する。
２）ユーザー企業は、複数の標準プロファイル（Ａ標準、Ｂ標準・・・）と自社ユーザープロファイルとの関連定義をする必要がある。この場合、システムサポートセンターが、Ａ業界、Ｂ業界・・・等、業界ごとの標準プロファイルの関連定義（旧標準プロファイル⇔新標準プロファイル）、異なる業界の標準プロファイル間の関連定義（Ａ業界標準プロファイル⇔Ｂ業界標準プロファイル・・・）を作成し、ユーザーシステムがこれらの関連定義をダウンロードする。そして、ユーザーシステムは、それらの関連定義を参照し、ユーザープロファイルを自動作成する。
図１は本発明の実施の形態１に係るデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。 図２は本発明の実施の形態１に係るデータ管理システムのデータ構造を概略的に示す説明図である。 図３は本発明の実施の形態１に係るデータ管理システムを売上管理システムに具体化した場合のデータ構造を概略的に示す説明図である。 図４は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての商品マスタテーブルを示す説明図である。 図５は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての顧客マスタテーブルを示す説明図である。 図６は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての顧客単価マスタテーブルを示す説明図である。 図７は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての在庫マスタテーブルを示す説明図である。 図８は従来のデータ管理システムにおけるデータ定義（物理テーブル構造）の一例としての販売マスタテーブルを示す説明図である。 図９は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における列管理テーブルを示す説明図である。 図１０は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における行管理テーブルを示す説明図である。 図１１は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における値管理テーブルの第１の具体例を示す説明図である。 図１２は本発明の実施の形態１に係るデータ管理システムにより図４〜図８の従来のデータ管理システムを置き換えた事例における値管理テーブルの第２の具体例を示す説明図である。 図１３は本発明の実施の形態２に係るデータ管理システムとしての受発注管理システムの構成を概略的に示すブロック図である。 図１４は本発明の実施の形態２に係るデータ管理システムを受発注管理システムに具体化した場合のデータ構造を概略的に示す説明図である。 図１５は本発明の実施の形態２に係るデータ管理システムでデータ交換される発注データのデータ構造を示す説明図である。 図１６は本発明の実施の形態２に係るデータ管理システムで使用する列管理テーブルの概略を示す説明図である。 図１７は本発明の実施の形態２に係るデータ管理システムにより、発注データのレコードと、列管理テーブルに定義した当該発注データの各データ項目の属性との対応関係を示す説明図である。 図１８は本発明の実施の形態２に係るデータ管理システムに外部から発注データを取り込んで、当該発注データを発注企業指定データ格納領域に格納すると共に、その伝票レコード及び伝票明細レコードをそれぞれ伝票格納及び伝票明細格納領域に格納する伝票基礎レコード・伝票項目値格納手順におけるデータフローを示すブロック図である。 図１９は本発明の実施の形態２に係るデータ管理システムにより発注企業データプロファイルと受注企業データプロファイルとを標準データプロファイルを介してデータ交換する場合の手順を概略的に示す説明図である。 図２０は本発明の実施の形態２に係るデータ管理システムにより、発注企業データの所定の項目値を表す発注企業データプロファイルの所定の列ＩＤから、当該発注企業データの項目値に対応する標準データの項目値を表す標準データプロファイルの所定の列ＩＤを介して、当該標準データの項目値に対応する受注企業データの項目値を表す受注データプロファイルの所定の列ＩＤを取得する手順を概略的に示す説明図である 図２１は本発明の実施の形態２に係るデータ管理システムによりデータ交換を行う際に、各企業間で項目値の意味や使用方法が異なる場合の処理に使用する項目値管理テーブルの概略を示す説明図である。 図２２は本発明の実施の形態２に係るデータ管理システムに新規な発注企業データプロファイル及び当該発注企業プロファイルと標準データプロファイルとのリンク情報を取り込んで、当該新規な発注企業データプロファイルに基づきデータを表示及び出力する場合のプロファイル取り込み・表示・出力手順におけるデータフローを示すブロック図である。 図２３は本発明の実施の形態２に係るデータ管理システムにより各種データを出力するデータ出力手順におけるデータフローを示すブロック図である。 図２４は本発明の実施の形態３に係るデータ管理システムの構成をプロファイル管理システムと共に概略的に示すブロック図である。 図２５は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータを取引過程にしたがって示すデータフロー図である。 図２６は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムでデータ交換の対象となるデータの一覧及び構成を示す表である。 図２７は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用する標準データのデータ構造を示すデータ構造図である。 図２８は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムのデータ構造を示すテーブル関連図である。 図２９は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル一覧を示す表である。 図３０は本発明の実施の形態４に係るデータ管理システムしての電子商取引データ交換システムにより、発注データと出荷データとの間で相違が発生した場合のマッチング処理を概略的に示す説明図である。 図３１は本発明の実施の形態５に係るデータ管理システムを適用して電子商取引データ交換を実現するネットワークシステムの全体構成を示す説明図である。 図３２は一般的なテーブル構造と本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルとの関係を示すブロック図である。 図３３は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルの概念を示す説明図である。 図３４は本発明の実施の形態５に係るデータ管理システムの３つの物理テーブルにおけるレコード階層構造の処理について説明するブロック図である。 図３５は本発明の実施の形態５に係るデータ管理システムを流通企業向け物流支援システムに適用した場合の業務の流れを示すフロー図である。 図３６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する企業管理（ＣＵＳＴＯＭＥＲ）テーブルを示す説明図である。 図３７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ交換管理（ＥＸＣＨＡＮＧＥ）テーブルを示す説明図である。 図３８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するデータ種類（ＤＡＴＡ＿ＫＩＮＤ）テーブルを示す説明図である。 図３９は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用するテーブル管理（ＴＡＢＬＥ）テーブルを示す説明図である。 図４０は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの標準データプロファイル部分を示す説明図である。 図４１は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの発注企業データプロファイル部分を示す説明図である。 図４２は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する列管理（ＣＯＬＵＭＮ）テーブルの受注企業データプロファイル部分を示す説明図である。 図４３４本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目値管理（ＣＯＬＵＭＮ＿ＶＡＬＵＥ）テーブルを示す説明図である。 図４４は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する項目関連定義（ＣＯＬＵＭＮ＿ＣＨＡＩＮ）テーブルを示す説明図である。 図４５は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する関数管理（ＦＵＮＣＴＩＯＮ）テーブルを示す説明図である。 図４６は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する対象管理（ＳＹＳＴＥＭ＿ＯＢＪＥＣＴ）テーブルを示す説明図である。 図４７は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する行管理（ＲＯＷ）テーブルを示す説明図である。 図４８は本発明の実施の形態５に係るデータ管理システムしての電子商取引データ交換システムで使用する値管理（ＣＥＬＬ）テーブルを示す説明図である。 図４９は本発明の実施の形態６に係るデータ管理システムをシステム開発支援ＣＡＳＥツールに適用する場合の概念を説明するブロック図である。 図５０は本発明の実施の形態６に係るデータ管理システムのテーブル間の双方向のデータ変換の概念を説明するブロック図である。 図５１は本発明の実施の形態６に係るデータ管理システムのテーブルと帳票との間での片方向（一方向）のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。 図５２は本発明の実施の形態６に係るデータ管理システムにおいて納品書の金額の表示方法が相違する場合の処理の概念を説明するブロック図である。 図５３は本発明の実施の形態６に係るデータ管理システムのテーブルと表示画面との間での双方向のデータ変換の概念を示し、（ａ）はデータ変換の概念を説明するブロック図、（ｂ）は具体例１を示すブロック図、（ｃ）は具体例２を示す部ブロック図である。 図５４は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルを概略的に示す説明図である。 図５５は本発明の実施の形態６に係るデータ管理システムで使用する帳票プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルを概略的に示す説明図である。 図５６は本発明の実施の形態６に係るデータ管理システムで使用する帳票（ＦＯＲＭ）テーブルを概略的に示す説明図である。 図５７は本発明の実施の形態６に係るデータ管理システムで使用する列管理テーブルの設定例を概略的に示す説明図である。 図５８は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの設定例を概略的に示す説明図である。 図５９は本発明の実施の形態６に係るデータ管理システムで使用する画面表示（ＦＯＲＭ）テーブルの設定例を概略的に示す説明図である。 図６０は本発明の実施の形態６に係るデータ管理システムで使用する画面表示プロファイル項目管理（ＦＯＲＭ＿ＣＯＬＵＭＮ）テーブルの設定例を説明するブロック図である。 図６１は本発明の各実施の形態２〜６に係るデータ管理システムの発注企業データ読込・格納処理を示すフローチャートである。 図６２は本発明の各実施の形態２〜６に係るデータ管理システムの伝票一覧表示処理を示すフローチャートである。 図６３は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理を示すフローチャートである。 図６４は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業オリジナルデータ取得処理を示すフローチャートである。 図６５は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における発注企業伝票データ取得処理を示すフローチャートである。 図６６は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理におけるシステム標準データ取得処理を示すフローチャートである。 図６７は本発明の各実施の形態２〜６に係るデータ管理システムの伝票詳細表示処理における受注企業指定データ取得処理を示すフローチャートである。 図６８は本発明の各実施の形態２〜６に係るデータ管理システムのデータ出力処理を示すフローチャートである。 図６９は本発明の各実施の形態２〜６に係るデータ管理システムの項目値変換処理を示すフローチャートである。 図７０は本発明の実施の形態１〜６に係るデータ管理システムのデータ変換処理及び表示処理の特徴を説明するブロック図である。 図７１は従来のデータ管理システムのデータ変換処理の表示処理を説明するブロック図である。 図７２は本発明の実施の形態７に係るデータ管理システムの列管理テーブルを示す説明図である。 図７３は本発明の実施の形態８に係るデータ管理システムの関数管理テーブルを示す説明図である。 図７４は本発明の実施の形態９に係るデータ管理システムの関数テーブルを示す説明図である。 図７５は本発明の実施の形態１０に係るデータ管理システムの索引管理テーブルを示す説明図である。 図７６は本発明の実施の形態１０に係るデータ管理システムの行関連管理テーブルを示す説明図である。 図７７は従来のデータ管理システムとしての売上管理システムの構成を概略的に示すブロック図である。
符号の説明
１０：売上管理システム（データ管理システム）
２０：受発注管理システム（データ管理システム）
１１０：データ交換システム（データ管理システム）
１２０：プロファイル管理システム（データ管理システム）

Claims (17)

  1. 少なくとも、管理対象のレコードを構成する各データ項目を一意に示す列ＩＤを予め定義して静的に格納する列管理ファイルと、
    前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理ファイルと、
    前記レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理ファイルに格納した行ＩＤと前記列管理ファイルに格納した列ＩＤとにより一意に特定して動的に格納する値管理ファイルと
    を備えることを特徴とするデータ管理システム。
  2. 少なくとも、管理対象のレコードを構成する各データ項目を一意に示す列ＩＤを予め定義して静的に格納する列管理テーブルと、
    前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理テーブルと、
    前記読込レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理テーブルに格納した行ＩＤと前記列管理テーブルに格納した列ＩＤとにより一意に特定して動的に格納する値管理テーブルと
    を備えることを特徴とするデータ管理システム。
  3. 前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれについて、当該レコードを構成する各データ項目を一意に示す列ＩＤを予め特定して静的に格納することにより、前記複数種類のレコードを構成するデータ項目を予め定義し、
    前記行管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードから所定の識別子を取得して前記行ＩＤに対応付けて格納し、
    前記値管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードのデータ項目の項目値をデータ項目ごとに分割して格納することを特徴とする請求項２記載のデータ管理システム。
  4. 少なくとも、管理対象のレコードのデータフォーマットを一意に示すレコードＩＤ（テーブルＩＤ）を予め特定して静的に格納する列管理テーブルと、
    前記レコードの読込時に、当該読込レコードを一意に示す行ＩＤを当該読込レコードに対応して動的に格納する行管理テーブルと、
    前記読込レコードの読込時に、当該読込レコードのデータ項目の項目値を前記行管理テーブルに格納した行ＩＤと前記列管理テーブルに格納したレコードＩＤとにより一意に特定して動的に格納する値管理テーブルとを備え、
    前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれについて、当該レコードのデータフォーマットを一意に示すレコードＩＤを予め特定して静的に格納することにより、前記複数種類のレコードのデータフォーマットを予め定義して異なるデータフォーマットのレコードを識別するようにし、
    前記行管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードを構成するデータ項目の定義部分を参照して、当該読込レコードから所定の識別子を取得して前記行ＩＤに対応付けて格納し、
    前記値管理テーブルには、前記異なるデータフォーマットを有する複数種類のレコードのそれぞれの読込時に、前記列管理テーブルにおいて読込レコードのデータフォーマットの定義部分を参照し、当該読込レコードの行ＩＤ及びレコードＩＤに対応付けて、当該読込レコードのデータ項目の項目値を格納することを特徴とするデータ管理システム。
  5. 前記列管理テーブルをデータ管理センターのサーバに配置すると共に、前記行管理テーブル及び前記値管理テーブルをユーザのクライアントに配置し、
    前記列管理テーブルにおいて管理対象のレコードを構成するデータ項目の定義情報またはデータフォーマットの定義情報に更新（追加、削除、変更）があった場合、ユーザのクライアントからデータ管理センターのサーバに接続して、前記列管理テーブルにおいて更新（追加、削除、変更）があったデータ項目の定義情報部分またはデータフォーマットの定義情報部分を取得自在とした
    ことを特徴とする請求項２乃至４のいずれか１項に記載のデータ管理システム。
    この場合、ユーザのクライアントには列管理テーブルを備えず、レコードの読込時には、ユーザーのクライアントからデータ管理センタのサーバに接続して定義情報を取得し、実データを行管理テーブル及び値管理テーブルへ格納するようにしても良いし、ユーザーのクライアントにも列管理テーブルを備え、更新のあった定義情報部分だけダウンロードするようにしても良い。
  6. 更に、異なるデータフォーマットの複数種類のレコードのデータ項目間におけるリンク情報を定義する項目関連定義テーブルを備え、当該項目関連テーブルを参照して、値管理テーブルに格納した所定データフォーマットの読込レコードのデータ項目値を、異なるデータフォーマットのレコードへと変換自在とし、
    前記項目関連定義テーブルにおいてリンク情報に更新（追加、削除、変更）があった場合、ユーザのクライアントからデータ管理センターのサーバに接続して、前記項目関連定義テーブルにおいて更新（追加、削除、変更）があったリンク情報部分を取得自在としたことを特徴とする請求項５に記載のデータ管理システム。
  7. 前記列管理テーブルには、異なるデータフォーマットを有する複数種類のレコードのそれぞれの定義情報に加え、標準フォーマットのレコードの定義情報を格納し、
    更に、異なるデータフォーマットの複数種類のレコードのデータ項目と前記標準フォーマットのレコードのデータ項目との間におけるリンク情報を定義する項目関連定義テーブルを備え、当該項目関連テーブルを参照して、値管理テーブルに格納した所定データフォーマットの読込レコードのデータ項目値を、標準フォーマットのレコードを介して、異なるデータフォーマットのレコードへと変換自在としたことを特徴とする請求項３乃至６のいずれか１項に記載のデータ管理システム。
  8. 前記列管理テーブルには、階層構造を有するレコードの当該階層構造を定義するレコード関連情報（枝番）を格納し、
    前記レコード関連情報を使用して、前記レコードの階層構造を維持するようにしたことを特徴とする請求項２乃至７のいずれか１項に記載のデータ管理システム。
  9. 更に、階層構造または親子関係を有するレコードの当該階層構造または親子関係を定義するレコード関連情報を格納する行関連管理テーブルを備え、
    前記レコード関連情報を使用して、前記レコードの階層構造または親子関係を維持するようにしたことを特徴とする請求項２乃至８のいずれか１項に記載のデータ管理システム。
  10. 前記列管理テーブルには、管理対象のレコードのデータ種類を特定するデータ種類情報を格納し、
    複数種類のレコードを、その種類を特定して前記値管理テーブルに格納自在としたことを特徴とする請求項２乃至９のいずれか１項に記載のデータ管理システム。
  11. 少なくとも、管理対象のレコードのデータ項目のデータ項目名と、前記データ項目名を一意に特定する列ＩＤとを予め特定して静的に格納する列管理テーブルと、
    少なくとも、読込レコードを一意に特定する行ＩＤを読込レコードにそれぞれ割り付けて動的に格納する行管理テーブルと、
    前記列管理テーブルと前記行管理テーブルとを結合することにより動的に作成され、少なくとも、前記行管理テーブルに格納した行ＩＤと、前記列管理テーブルに格納した列ＩＤと、前記レコードの各データ項目の値とを格納する値管理テーブルとを備え、
    前記値管理テーブルの各データ項目の値を、前記各行ＩＤと前記各列ＩＤとにより特定して格納するようにしたことを特徴とするデータ管理システム。
  12. 前記管理対象のレコードとして、異なるデータフォーマットを有する複数種類のレコードを格納し、
    管理対象として読込み予定の全ての種類のレコードについて、各レコードに含まれるデータ項目名を特定して前記列管理テーブルに予め静的に格納すると共に、前記各列ＩＤに対応して、前記レコードのデータフォーマットを一意に示すテーブルＩＤを前記列管理テーブルに静的に格納し、
    実際に読込んだ管理対象のレコードについてテーブルＩＤを判断し、前記列管理テーブルのデータ項目名のうち、当該テーブルＩＤに対応するデータ項目名について、当該読込レコードから値を取得して前記値管理テーブルに動的に格納し、
    読込レコードが複数ある場合には、各読込レコードについて前記行ＩＤを割当てると共に、各読込レコードについてテーブルＩＤを判断することを特徴とする請求項１１記載のデータ管理システム。
  13. 前記テーブルＩＤにより示されるデータフォーマットと異なるデータフォーマットのレコードが管理対象となった場合、当該新規データフォーマットのレコードに含まれるデータ項目名を前記列管理テーブルのデータ項目名に追加すると共に、追加した各データ項目名に対応して列ＩＤを追加して、追加した各列ＩＤに対応して前記テーブルＩＤを追加することにより、新規データフォーマットのレコードに対応できるようにした請求項１２記載のデータ管理システム。
  14. レコードを階層構造で保持するデータを格納するデータ管理システムであって、
    少なくとも、管理対象のレコードのデータ項目名と、前記データ項目名を一意に示す列ＩＤと、当該レコードの階層位置を示す枝番とを予め特定して静的に格納する列管理テーブルと、
    少なくとも、前記レコードを一意に示す行ＩＤを読込レコードに割り付けて動的に格納する行管理テーブルと、
    前記列管理テーブルと前記行管理テーブルとを結合することにより動的に作成され、少なくとも、前記行管理テーブルに格納した行ＩＤと、前記列管理テーブルに格納した列ＩＤと、前記レコードの各データ項目名の値とを格納する値管理テーブルとを備え、
    前記値管理テーブルの各データ項目名の値を、前記各行ＩＤと前記各列ＩＤとにより特定して格納するようにしたことを特徴とするデータ管理システム。
  15. 特定のデータフォーマットを有する標準データを予め定義し、
    前記管理対象としての読込予定の全ての一次データのデータフォーマットについて、前記標準データとの間でマッピングしてリンク情報を作成し、
    前記一次データを加工して得る予定の二次データのデータフォーマットついて、前記標準データとの間でマッピングしてリンク情報を作成し、
    前記リンク情報に基づき、実際に読込んだ一次データの各データ項目を前記標準データの対応するデータ項目を介して、加工すべき二次データの対応するデータ項目に割り当てて、前記一次データを二次データへ加工することを特徴とするデータ管理システム。
  16. 更に、前記一次データと前記標準データとのリンク情報、及び、前記標準データと前記二次データとのリンク情報を格納する項目関連定義テーブルを備え、
    前記一次データのみデータ格納領域に一次情報として保存し、
    前記標準データは、前記項目関連定義テーブルにおける前記一次データと前記標準データとのリンク情報に基づき、前記一次データから必要に応じて作成すると共に、
    前記二次データは、前記項目関連定義テーブルにおける前記標準データと前記一次データとのリンク情報及び前記一次と前記標準データとのリンク情報に基づき、前記一次データから必要に応じて作成することを特徴とする請求項１５記載のデータ管理システム。
  17. 行管理テーブルにデータマッチング用ＩＤ（突合値）を格納し、一次データから二次データ加工時の特定のデータ項目名をマッチングして値を訂正することを特徴とする請求項１乃至１６のいずれか１項記載のデータ管理システム。
JP2006228497A 2005-08-24 2006-08-24 データ管理システム Active JP4945196B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006228497A JP4945196B2 (ja) 2005-08-24 2006-08-24 データ管理システム

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2005243492 2005-08-24
JP2005243492 2005-08-24
JP2006008086 2006-01-16
JP2006008086 2006-01-16
JP2006228497A JP4945196B2 (ja) 2005-08-24 2006-08-24 データ管理システム

Publications (2)

Publication Number Publication Date
JP2007213551A true JP2007213551A (ja) 2007-08-23
JP4945196B2 JP4945196B2 (ja) 2012-06-06

Family

ID=38491889

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006228497A Active JP4945196B2 (ja) 2005-08-24 2006-08-24 データ管理システム

Country Status (1)

Country Link
JP (1) JP4945196B2 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245373A (ja) * 2008-03-31 2009-10-22 Fujitsu Fip Corp 受発注データ変換方法、同方法を実行させるコンピュータプログラムおよび記憶媒体
JP2010026664A (ja) * 2008-07-16 2010-02-04 Nomura Research Institute Ltd 取引仲介装置
JP2010026900A (ja) * 2008-07-23 2010-02-04 Mitsubishi Electric Corp 設備維持管理装置
JP2010123095A (ja) * 2008-11-18 2010-06-03 Akihiro Kawauchi 企業間電子商取引の接続方法
JP5010749B1 (ja) * 2011-06-02 2012-08-29 株式会社行本会計事務所 会計仕訳ファイルデータ標準化システムとそれを用いた監査システムとそれらのプログラム
JP2012252696A (ja) * 2012-05-25 2012-12-20 Yukumoto Kaikei Jimusho Co Ltd 会計仕訳ファイルデータ標準化システムとそのプログラム
JP2014063247A (ja) * 2012-09-20 2014-04-10 Virtual N:Kk データベースシステム生成装置
JP2016539449A (ja) * 2013-11-22 2016-12-15 杰 盛 データベース実現方法
US10572457B2 (en) 2016-04-20 2020-02-25 Iwasaki Electric Mfg. Co., Ltd. Database construction device, database construction method, and database construction program
JP2021086479A (ja) * 2019-11-29 2021-06-03 株式会社リコー 情報処理システム、情報処理方法及びプログラム
WO2022230809A1 (ja) * 2021-04-30 2022-11-03 株式会社ソフトギア シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム
KR102715898B1 (ko) * 2022-12-09 2024-10-11 주식회사 하이퍼라운지 데이터 분석을 위한 테이블 분석 처리 방법 및 그를 위한 장치

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005098593A2 (en) * 2004-04-02 2005-10-20 Salesforce.Com, Inc. Custom entities and fields in a multi-tenant database system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005098593A2 (en) * 2004-04-02 2005-10-20 Salesforce.Com, Inc. Custom entities and fields in a multi-tenant database system
JP2007531941A (ja) * 2004-04-02 2007-11-08 セールスフォース ドット コム インコーポレイティッド マルチテナント・データベース・システムにおけるカスタム・エンティティおよびフィールド

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245373A (ja) * 2008-03-31 2009-10-22 Fujitsu Fip Corp 受発注データ変換方法、同方法を実行させるコンピュータプログラムおよび記憶媒体
JP2010026664A (ja) * 2008-07-16 2010-02-04 Nomura Research Institute Ltd 取引仲介装置
JP2010026900A (ja) * 2008-07-23 2010-02-04 Mitsubishi Electric Corp 設備維持管理装置
JP2010123095A (ja) * 2008-11-18 2010-06-03 Akihiro Kawauchi 企業間電子商取引の接続方法
JP5010749B1 (ja) * 2011-06-02 2012-08-29 株式会社行本会計事務所 会計仕訳ファイルデータ標準化システムとそれを用いた監査システムとそれらのプログラム
WO2012165600A1 (ja) * 2011-06-02 2012-12-06 株式会社Ｙｋプランニング 会計仕訳ファイルデータ標準化システム
JP2012252696A (ja) * 2012-05-25 2012-12-20 Yukumoto Kaikei Jimusho Co Ltd 会計仕訳ファイルデータ標準化システムとそのプログラム
JP2014063247A (ja) * 2012-09-20 2014-04-10 Virtual N:Kk データベースシステム生成装置
JP2016539449A (ja) * 2013-11-22 2016-12-15 杰 盛 データベース実現方法
US10572457B2 (en) 2016-04-20 2020-02-25 Iwasaki Electric Mfg. Co., Ltd. Database construction device, database construction method, and database construction program
JP2021086479A (ja) * 2019-11-29 2021-06-03 株式会社リコー 情報処理システム、情報処理方法及びプログラム
JP7456131B2 (ja) 2019-11-29 2024-03-27 株式会社リコー 情報処理システム、情報処理方法及びプログラム
WO2022230809A1 (ja) * 2021-04-30 2022-11-03 株式会社ソフトギア シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム
JP2022171464A (ja) * 2021-04-30 2022-11-11 株式会社ソフトギア シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム
JP7253172B2 (ja) 2021-04-30 2023-04-06 株式会社ソフトギア シリアル化方法、逆シリアル化方法、情報処理プログラム、情報処理装置及び通信システム
KR102715898B1 (ko) * 2022-12-09 2024-10-11 주식회사 하이퍼라운지 데이터 분석을 위한 테이블 분석 처리 방법 및 그를 위한 장치

Also Published As

Publication number Publication date
JP4945196B2 (ja) 2012-06-06

Similar Documents

Publication Publication Date Title
JP5324797B2 (ja) データ管理システム
JP4945196B2 (ja) データ管理システム
US8200539B2 (en) Product common object
US6901380B1 (en) Merchandising system method, and program product utilizing an intermittent network connection
US7870033B2 (en) Intelligent multimedia e-catalog
CN101266666B (zh) 贸易伙伴网络中的商务文档以及基于该文档的接口定义
US20020099735A1 (en) System and method for conducting electronic commerce
WO2006055579A2 (en) Accelerated system and methods for synchronizing, managing and publishing business information
CN101777057A (zh) 多租户数据库系统中为多个租户存储自定义字段的方法和系统
TW200534139A (en) Strategic sourcing for packaging material procurement using centralized packaging data management system
CN104395899A (zh) 基于云的主数据管理系统及其方法
US20050256798A1 (en) Object model for global trade applications
US6973639B2 (en) Automatic program generation technology using data structure resolution unit
WO2015198365A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
JP3188241B2 (ja) ネットワーク利用の知的データ処理方法及び装置及び記録媒体
US20150120355A1 (en) Mobile terminal management server and mobile terminal management program
US20150073856A1 (en) Mobile terminal management server and mobile terminal management program
WO2015198364A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
JPH06325059A (ja) 発注管理システム及び顧客管理システム
CN117435555B (zh) 主数据管理方法、平台、服务器及存储介质
WO2015198362A1 (ja) 連携サーバ、連携プログラム、およびｅｃシステム
JP5441602B2 (ja) データ変換装置、データ変換方法及びプログラム
JP2011096060A (ja) 貿易決済関連データ管理システムおよびその方法
JP4181330B2 (ja) 要約作成プログラム及びシステム並びにコンピュータによる要約作成方法
Subrahmanyam The Customer Vendor Integration (CVI)

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111018

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111219

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120206

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120305

R150 Certificate of patent or registration of utility model

Ref document number: 4945196

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150309

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250