ホーム > 特許ランキング > 株式会社野村総合研究所
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023114419
(43)【公開日】2023-08-17
(54)【発明の名称】データ処理システム
(51)【国際特許分類】
G06F 16/242 20190101AFI20230809BHJP
G06F 16/21 20190101ALI20230809BHJP
【ＦＩ】
G06F16/242
G06F16/21
【審査請求】未請求
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2022122426
(22)【出願日】2022-08-01
(31)【優先権主張番号】P 2022016291
(32)【優先日】2022-02-04
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】000155469
【氏名又は名称】株式会社野村総合研究所
(74)【代理人】
【識別番号】100096002
【弁理士】
【氏名又は名称】奥田 弘之
(74)【代理人】
【識別番号】100091650
【弁理士】
【氏名又は名称】奥田 規之
(72)【発明者】
【氏名】石田 裕三
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175EA03
5B175HA04
(57)【要約】 （修正有）
【課題】テーブルを属性項目単位で細分化することによってＤＢ構造の簡素化を図ると共に、データ操作用プログラムの作成を省力化するデータ処理システムを提供する。
【解決手段】データ処理システム１０は、属性項目毎に独立した複数のテーブルと、各テーブルを関連付ける統合ＩＤを格納するテーブルの生成を指示するＳＱＬをＤＢに発行する手段と、統合ＩＤ毎に複数の属性項目の入力欄を備えたデータ登録画面を生成しディスプレイに表示する手段と、入力データを対応のテーブルに格納することを指示するＳＱＬをＤＢに発行する手段と、検索条件にマッチするデータの抽出を指示するＳＱＬをＤＢに発行する手段と、ＤＢから取得した複数の属性項目に係るデータを行として連結し、画面に出力する手段とｍを備える。
【選択図】図１
【解決手段】データ処理システム１０は、属性項目毎に独立した複数のテーブルと、各テーブルを関連付ける統合ＩＤを格納するテーブルの生成を指示するＳＱＬをＤＢに発行する手段と、統合ＩＤ毎に複数の属性項目の入力欄を備えたデータ登録画面を生成しディスプレイに表示する手段と、入力データを対応のテーブルに格納することを指示するＳＱＬをＤＢに発行する手段と、検索条件にマッチするデータの抽出を指示するＳＱＬをＤＢに発行する手段と、ＤＢから取得した複数の属性項目に係るデータを行として連結し、画面に出力する手段とｍを備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
一の名前空間を構成するための名前と、当該名前空間に属する少なくとも一つの実体的な属性項目の名前及びそのデータ型とを、それぞれクラスとして宣言する列定義プログラムと、
上記列定義プログラムの記述に従い、属性項目毎に独立した一または複数のテーブルと、各テーブルを関連付けるユニークな統合IDを格納するテーブルの生成を指示するSQLをデータベースに発行するテーブル生成指示手段と、
行を構成すべき複数の属性項目の名前と、各属性項目が継承する列定義プログラム中のクラスとを、それぞれクラスとして宣言する行定義プログラムと、
上記列定義プログラム及び行定義プログラムの記述に従い、統合ID毎に複数の属性項目の入力欄を備えたデータ登録画面を生成し、ディスプレイに表示するデータ登録画面生成手段と、
入力手段を介して上記入力欄にデータが入力された際に、各入力データを対応のテーブルに格納することを指示するSQLをデータベースに発行するデータ登録指示手段と、
検索画面を介して特定の名前空間が検索条件として入力された場合に、上記検索条件にマッチするデータの抽出を指示するSQLをデータベースに発行するデータ検索指示手段と、
データベースから取得した複数の属性項目に係るデータを行として連結し、画面またはファイルとして出力する検索結果出力手段とを備え、
上記テーブルの生成を指示するSQLによって生成される複数のテーブルが、それぞれ共通の統合IDを主キーまたは外部キーとして保持することにより、相互に同一の名前空間に属する関連データを保持するものであることが表現されていることを特徴とするデータ処理システム。
上記列定義プログラムの記述に従い、属性項目毎に独立した一または複数のテーブルと、各テーブルを関連付けるユニークな統合IDを格納するテーブルの生成を指示するSQLをデータベースに発行するテーブル生成指示手段と、
行を構成すべき複数の属性項目の名前と、各属性項目が継承する列定義プログラム中のクラスとを、それぞれクラスとして宣言する行定義プログラムと、
上記列定義プログラム及び行定義プログラムの記述に従い、統合ID毎に複数の属性項目の入力欄を備えたデータ登録画面を生成し、ディスプレイに表示するデータ登録画面生成手段と、
入力手段を介して上記入力欄にデータが入力された際に、各入力データを対応のテーブルに格納することを指示するSQLをデータベースに発行するデータ登録指示手段と、
検索画面を介して特定の名前空間が検索条件として入力された場合に、上記検索条件にマッチするデータの抽出を指示するSQLをデータベースに発行するデータ検索指示手段と、
データベースから取得した複数の属性項目に係るデータを行として連結し、画面またはファイルとして出力する検索結果出力手段とを備え、
上記テーブルの生成を指示するSQLによって生成される複数のテーブルが、それぞれ共通の統合IDを主キーまたは外部キーとして保持することにより、相互に同一の名前空間に属する関連データを保持するものであることが表現されていることを特徴とするデータ処理システム。
【請求項2】
上記行定義プログラムにおいて記述される各属性項目については、必須項目か任意項目かを指定するコードが付加されており、
上記データ登録画面を介してデータを登録する際に、任意項目の指定がなされた属性項目の入力欄についてはデータの入力がなくとも許容し、必須項目の指定がなされた属性項目の入力欄についてはデータの入力がない場合にエラーと認定する手段を備えたことを特徴とする請求項１に記載のデータ処理システム。
上記データ登録画面を介してデータを登録する際に、任意項目の指定がなされた属性項目の入力欄についてはデータの入力がなくとも許容し、必須項目の指定がなされた属性項目の入力欄についてはデータの入力がない場合にエラーと認定する手段を備えたことを特徴とする請求項１に記載のデータ処理システム。
【請求項3】
上記列定義プログラムにおいて記述される各属性項目については、ユニークな値のみが登録されるべきか、非ユニークな値の登録も許容されるのかを指定するコードが付加されており、
上記データ登録画面を介してデータを登録する際に、ユニークな値が登録されるべきとの指定がなされた属性項目の入力欄については、対応テーブルの登録例を参照し、入力されたデータが既存のデータと重複する場合にはエラーと認定する手段を備えたことを特徴とする請求項１または２に記載のデータ処理システム。
上記データ登録画面を介してデータを登録する際に、ユニークな値が登録されるべきとの指定がなされた属性項目の入力欄については、対応テーブルの登録例を参照し、入力されたデータが既存のデータと重複する場合にはエラーと認定する手段を備えたことを特徴とする請求項１または２に記載のデータ処理システム。
【請求項4】
上記列定義プログラムにおいて、特定の属性項目について他の名前空間に属するデータが参照先として指定されている場合に、上記テーブルの生成を指示するSQLによって生成される当該属性項目に係るテーブルが、参照先データの統合IDを外部キーとして保持することにより、その参照関係が表現されており、
上記データ登録画面生成手段は、参照先として指定された名前空間に属するテーブルを参照し、対応する属性項目の値を列挙した選択リストをディスプレイに表示し、当該選択リスト中から該当の値を選択させることを特徴とする請求項１または２に記載のデータ処理システム。
上記データ登録画面生成手段は、参照先として指定された名前空間に属するテーブルを参照し、対応する属性項目の値を列挙した選択リストをディスプレイに表示し、当該選択リスト中から該当の値を選択させることを特徴とする請求項１または２に記載のデータ処理システム。
【請求項5】
上記列定義プログラムにおいて、特定の属性項目について他の名前空間に属するデータが参照先として指定されている場合に、上記データ検索指示手段は参照先の名前空間に属するテーブルに格納されたデータの抽出を指示するSQLをデータベースに発行し、
上記検索結果出力手段は、異なる名前空間に属するテーブルから取得したデータを行として連結し、画面またはファイルとして出力することを特徴とする請求項４に記載のデータ処理システム。
上記検索結果出力手段は、異なる名前空間に属するテーブルから取得したデータを行として連結し、画面またはファイルとして出力することを特徴とする請求項４に記載のデータ処理システム。
【請求項6】
上記の各テーブルには、データの参照及び追加のみが許容され、データの削除及び更新を禁止する制約が課せられていることを特徴とする請求項１または２に記載のデータ処理システム。
【請求項7】
上記テーブル生成手段は、既存のデータを削除する必要がある場合に備え、削除の対象となるデータの統合IDをセットするデータ項目を備えた削除用テーブルの生成を指示するSQLをデータベースに発行し、
上記データ登録画面において特定のデータに係る削除ボタンが選択された場合に、上記データ登録指示手段は、当該データの統合IDを上記削除用テーブルに格納することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に削除することを特徴とする請求項６に記載のデータ処理システム。
上記データ登録画面において特定のデータに係る削除ボタンが選択された場合に、上記データ登録指示手段は、当該データの統合IDを上記削除用テーブルに格納することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に削除することを特徴とする請求項６に記載のデータ処理システム。
【請求項8】
上記の各データには、それぞれ登録時のタイムスタンプが刻印されており、
上記登録画面生成手段は、上記データ登録画面において特定のデータについて編集ボタンが選択された場合に、既存の属性項目の値を編集可能化し、
上記データ登録指示手段は、当該属性項目に新たな値が入力された際に、当該データと同じ統合IDを有すると共に、編集後の値及び編集時のタイムスタンプを備えた更新用データを新たに生成し、 この更新用データを上記データベースに設けられた対応のテーブルに追加登録することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に更新することを特徴とする請求項６に記載のデータ処理システム。
上記登録画面生成手段は、上記データ登録画面において特定のデータについて編集ボタンが選択された場合に、既存の属性項目の値を編集可能化し、
上記データ登録指示手段は、当該属性項目に新たな値が入力された際に、当該データと同じ統合IDを有すると共に、編集後の値及び編集時のタイムスタンプを備えた更新用データを新たに生成し、 この更新用データを上記データベースに設けられた対応のテーブルに追加登録することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に更新することを特徴とする請求項６に記載のデータ処理システム。
【請求項9】
上記列定義プログラムにおいて、特定の属性項目について値の変更を禁じるコードが付加されている場合、上記データ登録画面において編集ボタンが選択されても、当該属性項目については編集可能化されずに新たな値の入力が拒絶されることを特徴とする請求項８に記載のデータ処理システム。
【請求項10】
CSVファイルの行を構成する複数のデータ項目の名前と、当該名前の属する名前空間及び配置順を規定したCSV定義プログラムを備え、
上記データ登録指示手段は、CSVファイルが入力された際に、上記CSV定義プログラムの記述に従い、行を構成する各データ項目の名前及び名前空間を認識し、対応のテーブルに格納することを指示するSQLをデータベースに発行することを特徴とする請求項１または２に記載のデータ処理システム。
上記データ登録指示手段は、CSVファイルが入力された際に、上記CSV定義プログラムの記述に従い、行を構成する各データ項目の名前及び名前空間を認識し、対応のテーブルに格納することを指示するSQLをデータベースに発行することを特徴とする請求項１または２に記載のデータ処理システム。
【請求項11】
予め選択可能な複数の名前空間が規定されたCSV定義プログラムと、
上記CSV定義プログラムの記述に従い、選択可能な名前空間及び当該名前空間に属する実体的な属性項目の名前が選択肢として所定の順番に表示される抽出データ指定画面を生成し、ディスプレイに表示する手段と、
上記抽出データ指定画面を介して、抽出すべきデータの属する名前空間及び当該名前空間に含まれる特定の実体的な属性項目が順番に指定された際に、指定された属性項目に係るデータの抽出を指示するSQLをデータベースに発行するデータ抽出指示手段と、
データベースから取得した複数の属性項目に係るデータを、上記順番に配置したCSVファイルとして出力する抽出結果出力手段とを備えたことを特徴とする請求項１または２に記載のデータ処理システム。
上記CSV定義プログラムの記述に従い、選択可能な名前空間及び当該名前空間に属する実体的な属性項目の名前が選択肢として所定の順番に表示される抽出データ指定画面を生成し、ディスプレイに表示する手段と、
上記抽出データ指定画面を介して、抽出すべきデータの属する名前空間及び当該名前空間に含まれる特定の実体的な属性項目が順番に指定された際に、指定された属性項目に係るデータの抽出を指示するSQLをデータベースに発行するデータ抽出指示手段と、
データベースから取得した複数の属性項目に係るデータを、上記順番に配置したCSVファイルとして出力する抽出結果出力手段とを備えたことを特徴とする請求項１または２に記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明はデータ処理システムに係り、特に、テーブルをデータ項目単位で細分化することによってデータベース構造の簡素化を図ると共に、細分化されたデータを処理するためのプログラムの開発をも簡素化する技術に関する。
【背景技術】
【0002】
いわゆるIOT（Internet of Things）時代の到来により、企業内には日々様々なデータが蓄積されているが、これらの膨大かつ多様なデータを活用しきれていないのが現状である。
その一つの原因として、個々のデータを蓄積するためのテーブル構造が複雑であり、データを処理するためのプログラムも必然的に複雑化することが挙げられる。
もちろん、一つのテーブルに関連する複数のデータ項目を設けて「表」として管理することは人間の思考形態にマッチしており、特定の使用目的の下では効率的といえるが、蓄積されたデータを別の目的のために再利用する際には、表の解体や合成が必要となり、それを指示するためのプログラムの開発も煩雑とならざるを得ず、バグも生じやすくなる。
その一つの原因として、個々のデータを蓄積するためのテーブル構造が複雑であり、データを処理するためのプログラムも必然的に複雑化することが挙げられる。
もちろん、一つのテーブルに関連する複数のデータ項目を設けて「表」として管理することは人間の思考形態にマッチしており、特定の使用目的の下では効率的といえるが、蓄積されたデータを別の目的のために再利用する際には、表の解体や合成が必要となり、それを指示するためのプログラムの開発も煩雑とならざるを得ず、バグも生じやすくなる。
【0003】
これに対し、下記の特許文献１においては、テーブルの設定情報に基づいて、テーブル名、データ項目及び各データ項目のデータ型を定義したクラスを生成し、型格納部に格納しておくと共に、クラスを指定したコードが記述されたソースプログラムが入力された際には、コンパイラが型格納部内のクラスを参照して矛盾の存否を判定し、矛盾がある場合にはエラーメッセージを出力するアイディアが開示されている（同文献の図１０参照）。
【特許文献1】特開２０１２－１１３３７３
【0004】
データベースのテーブル操作に使用されるSQLにはコンパイルチェックが効かない問題が以前より指摘されていたが、同文献のようにデータベースに格納されたデータを操作する処理の多くをアプリケーションプログラム側に委ねると共に、操作の対象となるテーブル名やデータ項目等をクラス（型）として定義しておくことによってコンパイルチェックの恩恵を享受できるようにすることは、バグの抑制に資するといえる。
【0005】
また、この文献には、「商品ID」、「商品名」、「適用開始日」、「適用終了日」といった相互に関連するため従来であれば一つのテーブルで管理されていたデータを、「商品名」専用テーブル、「適用開始日」専用テーブル、「適用終了日」専用テーブルの三つに細分化し、共通の「商品ID」を主キーまたは外部キーとして持たせることにより、バラバラのデータを意味のある一纏めのデータとして統合するアイディアも開示されている（同文献の図１１参照）。
【発明の開示】
【発明が解決しようとする課題】
【0006】
しかしながら、特許文献１の場合には、これまで一纏めの表として管理されてきたデータを単純に細分化して個別のテーブルで管理するというだけのものであり、データベース構造の簡素化には資するものの、テーブルの数が増大すると共に、相互間の関連性を常に意識してコーディングする必要があるため、アプリケーションプログラムの開発は却って煩雑化していた。
【0007】
この発明は、このような現状に鑑みて案出されたものであり、テーブルをデータ項目単位で細分化することによってデータベース構造の簡素化を図ると共に、データ操作のためのアプリケーションプログラムの作成を省力化できる技術の実現を目的としている。
【課題を解決するための手段】
【0008】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、一の名前空間を構成するための名前と、当該名前空間に属する少なくとも一つの実体的な属性項目の名前及びそのデータ型とを、それぞれクラスとして宣言する列定義プログラムと、上記列定義プログラムの記述に従い、属性項目毎に独立した一または複数のテーブルと、各テーブルを関連付けるユニークな統合IDを格納するテーブルの生成を指示するSQLをデータベースに発行するテーブル生成指示手段と、行を構成すべき複数の属性項目の名前と、各属性項目が継承する列定義プログラム中のクラスとを、それぞれクラスとして宣言する行定義プログラムと、上記列定義プログラム及び行定義プログラムの記述に従い、統合ID毎に複数の属性項目の入力欄を備えたデータ登録画面を生成し、ディスプレイに表示するデータ登録画面生成手段と、入力手段を介して上記入力欄にデータが入力された際に、各入力データを対応のテーブルに格納することを指示するSQLをデータベースに発行するデータ登録指示手段と、検索画面を介して特定の名前空間が検索条件として入力された場合に、上記検索条件にマッチするデータの抽出を指示するSQLをデータベースに発行するデータ検索指示手段と、データベースから取得した複数の属性項目に係るデータを行として連結し、画面またはファイルとして出力する検索結果出力手段とを備え、上記テーブルの生成を指示するSQLによって生成される複数のテーブルが、それぞれ共通の統合IDを主キーまたは外部キーとして保持することにより、相互に同一の名前空間に属する関連データを保持するものであることが表現されていることを特徴としている。
【0009】
請求項２に記載したデータ処理システムは、請求項１のシステムであって、上記行定義プログラムにおいて記述される各属性項目については、必須項目か任意項目かを指定するコードが付加されており、上記データ登録画面を介してデータを登録する際に、任意項目の指定がなされた属性項目の入力欄についてはデータの入力がなくとも許容し、必須項目の指定がなされた属性項目の入力欄についてはデータの入力がない場合にエラーと認定する手段を備えたことを特徴としている。
【0010】
請求項３に記載したデータ処理システムは、請求項１または２のシステムであって、上記行定義プログラムにおいて記述される各属性項目については、必須項目か任意項目かを指定するコードが付加されており、上記データ登録画面を介してデータを登録する際に、任意項目の指定がなされた属性項目の入力欄についてはデータの入力がなくとも許容し、必須項目の指定がなされた属性項目の入力欄についてはデータの入力がない場合にエラーと認定する手段を備えたことを特徴としている。
【0011】
請求項４に記載したデータ処理システムは、請求項１または２のシステムであって、上記列定義プログラムにおいて特定の属性項目について他の名前空間に属するデータが参照先として指定されている場合に、上記テーブルの生成を指示するSQLによって生成される当該属性項目に係るテーブルが、参照先データの統合IDを外部キーとして保持することにより、その参照関係が表現されており、上記データ登録画面生成手段は、参照先として指定された名前空間に属するテーブルを参照し、対応する属性項目の値を列挙した選択リストをディスプレイに表示し、当該選択リスト中から該当の値を選択させることを特徴としている。
【0012】
請求項５に記載したデータ処理システムは、請求項４のシステムであって、上記列定義プログラムにおいて、特定の属性項目について他の名前空間に属するデータが参照先として指定されている場合に、上記データ検索指示手段は参照先の名前空間に属するテーブルに格納されたデータの抽出を指示するSQLをデータベースに発行し、上記検索結果出力手段は、異なる名前空間に属するテーブルから取得したデータを行として連結し、画面またはファイルとして出力することを特徴としている。
【0013】
請求項６に記載したデータ処理システムは、請求項１または２のシステムであって、上記の各テーブルには、データの参照及び追加のみが許容され、データの削除及び更新を禁止する制約が課せられていることを特徴としている。
【0014】
請求項７に記載したデータ処理システムは、請求項６のシステムであって、上記テーブル生成手段は、既存のデータを削除する必要がある場合に備え、削除の対象となるデータの統合IDをセットするデータ項目を備えた削除用テーブルの生成を指示するSQLをデータベースに発行し、上記データ登録画面において特定のデータに係る削除ボタンが選択された場合に、上記データ登録指示手段は、当該データの統合IDを上記削除用テーブルに格納することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に削除することを特徴としている。
【0015】
請求項８に記載したデータ処理システムは、請求項６のシステムであって、上記の各データには、それぞれ登録時のタイムスタンプが刻印されており、上記登録画面生成手段は、上記データ登録画面において特定のデータについて編集ボタンが選択された場合に、既存の属性項目の値を編集可能化し、上記データ登録指示手段は、当該属性項目に新たな値が入力された際に、当該データと同じ統合IDを有すると共に、編集後の値及び編集時のタイムスタンプを備えた更新用データを新たに生成し、 この更新用データを上記データベースに設けられた対応のテーブルに追加登録することを指示するSQLをデータベースに発行することにより、既存のデータを実質的に更新することを特徴としている。
【0016】
請求項９に記載したデータ処理システムは、請求項８のシステムであって、上記列定義プログラムにおいて、特定の属性項目について値の変更を禁じるコードが付加されている場合、上記データ登録画面において編集ボタンが選択されても、当該属性項目については編集可能化されずに新たな値の入力が拒絶されることを特徴としている。
【0017】
請求項１０に記載したデータ処理システムは、請求項１または２のシステムであって、CSVファイルの行を構成する複数のデータ項目の名前と、当該名前の属する名前空間及び配置順を規定したCSV定義プログラムを備え、上記データ登録指示手段は、CSVファイルが入力された際に、上記CSV定義プログラムの記述に従い、行を構成する各データ項目の名前及び名前空間を認識し、対応のテーブルに格納することを指示するSQLをデータベースに発行することを特徴としている。
【0018】
請求項１１に記載したデータ処理システムは、請求項１または２のシステムであって、予め選択可能な複数の名前空間が規定されたCSV定義プログラムと、上記CSV定義プログラムの記述に従い、選択可能な名前空間及び当該名前空間に属する実体的な属性項目の名前が選択肢として所定の順番に表示される抽出データ指定画面を生成し、ディスプレイに表示する手段と、上記抽出データ指定画面を介して、抽出すべきデータの属する名前空間及び当該名前空間に含まれる特定の実体的な属性項目が順番に指定された際に、指定された属性項目に係るデータの抽出を指示するSQLをデータベースに発行するデータ抽出指示手段と、データベースから取得した複数の属性項目に係るデータを、上記順番に配置したCSVファイルとして出力する抽出結果出力手段とを備えたことを特徴としている。
【発明の効果】
【0019】
この発明の場合、アプリケーションプログラムの開発者は、列定義プログラムの中で必要な属性項目の名前とデータ型をクラスとして宣言するだけで、SQLを書かなくても自動的に属性項目毎に独立したテーブルを生成することができる。
また、行定義プログラムの中で行を構成する複数の属性項目の名前と、各属性項目が継承する列定義プログラム中のクラスを宣言するだけで、自動的に複数の属性項目の入力欄を備えたデータ登録画面が生成され、当該画面を介したデータの登録が可能となり、検索画面を介したデータの参照も可能となる。
すなわち、この発明によれば、属性項目毎に細分化されたテーブル構造を前提としつつも、極めて少ないコーディングでデータの入出力処理が可能となり、その分、タイプミス等に基づくバグの発生を抑制することができる。
また、行定義プログラムの中で行を構成する複数の属性項目の名前と、各属性項目が継承する列定義プログラム中のクラスを宣言するだけで、自動的に複数の属性項目の入力欄を備えたデータ登録画面が生成され、当該画面を介したデータの登録が可能となり、検索画面を介したデータの参照も可能となる。
すなわち、この発明によれば、属性項目毎に細分化されたテーブル構造を前提としつつも、極めて少ないコーディングでデータの入出力処理が可能となり、その分、タイプミス等に基づくバグの発生を抑制することができる。
【図面の簡単な説明】
【0020】
【図1】この発明に係る第１のデータ処理システムの全体構成を示すブロック図である。
【図2】列定義コードの一例を示す図である。
【図3】APサーバにおける処理手順を示すフローチャートである。
【図4】部署データに係るテーブルの構成例を示す図である。
【図5】社員データに係るテーブルの構成例を示す図である。
【図6】部署データに係る行定義コードを示す図である。
【図7】部署データ登録画面を示す図である。
【図8】部署データの具体的な登録例を示す図である。
【図9】社員データに係る行定義コードを示す図である。
【図10】社員データ登録画面を示す図である。
【図11】社員データの具体的な登録例を示す図である。
【図12】検索画面を示す図である。
【図13】この発明に係る第２のデータ処理システムの全体構成を示すブロック図である。
【図14】第２のデータ処理システムにおいて用いられるテーブルを例示す図である。
【図15】注文データ登録画面を示す図である。
【図16】CSVファイルをテーブルに格納する様子を示す図である。
【図17】CSV定義コードを示す図である。
【図18】抽出データ指定画面を示す図である。
【図19】抽出データ指定画面を示す図である。
【図20】抽出データ指定画面を示す図である。
【図21】抽出結果画面を示す図である。
【図22】抽出データ指定画面を実現するためのソースコードを例示する図である。
【発明を実施するための最良の形態】
【0021】
図１に示すように、この発明に係る第１のデータ処理システム10は、AP（Application）サーバ12と、DB（Database）サーバ14と、開発者が操作する開発者端末16と、ユーザが操作するユーザ端末18を備えている。
APサーバ12は、ネットワークを介してDBサーバ14と接続されている。
また、開発者端末16とユーザ端末18も、ネットワークを介してAPサーバ12と接続されている。
ただし、APサーバ12及びDBサーバ14、は必ずしも物理的に独立したコンピュータによって構築される必要はない。
APサーバ12は、ネットワークを介してDBサーバ14と接続されている。
また、開発者端末16とユーザ端末18も、ネットワークを介してAPサーバ12と接続されている。
ただし、APサーバ12及びDBサーバ14、は必ずしも物理的に独立したコンピュータによって構築される必要はない。
【0022】
APサーバ12は、コンパイラ20と、列定義プログラム記憶部22と、行定義プログラム記憶部24と、テーブル生成指示部26と、データ処理部28を備えている。
コンパイラ20、テーブル生成指示部26及びデータ処理部28は、APサーバ12のCPUが、専用のアプリケーションプログラムに従って動作することにより、実現される機能構成部である。
また、列定義プログラム記憶部22及び行定義プログラム記憶部24は、APサーバ12の記憶装置内に設けられている。
コンパイラ20、テーブル生成指示部26及びデータ処理部28は、APサーバ12のCPUが、専用のアプリケーションプログラムに従って動作することにより、実現される機能構成部である。
また、列定義プログラム記憶部22及び行定義プログラム記憶部24は、APサーバ12の記憶装置内に設けられている。
【0023】
DBサーバ14は、DB管理システム32と、テーブル記憶部34を備えている。
また、開発者端末16及びユーザ端末18は、OSやWebブラウザ、テキストエディタ等のプログラムを搭載したPC等のコンピュータよりなる。
また、開発者端末16及びユーザ端末18は、OSやWebブラウザ、テキストエディタ等のプログラムを搭載したPC等のコンピュータよりなる。
【0024】
このシステム10の利用に際し、開発者は開発者端末16上のテキストエディタで列定義コード36を記述する。
この列定義コード36は、新たに生成する名前空間の名前と、上記名前空間に属する個々のテーブルの名前及びデータ型をクラス（型）として宣言するJAVA（登録商標）等のコードを意味している。
この列定義コード36は、新たに生成する名前空間の名前と、上記名前空間に属する個々のテーブルの名前及びデータ型をクラス（型）として宣言するJAVA（登録商標）等のコードを意味している。
【0025】
図２(a)は、以下の内容が規定された列定義コード36aを示すものである。
(1) 「Department（部署）」という名前の新たな名前空間を生成する。
(2) 「DEPARTMENT」というDBグループを生成する。
(3) このDBグループ内に、「Name（部署名）」という名前のテーブルを生成する。
(4) 「Name」のテーブルに格納されるデータは「Department」の名前空間に属し、そのデータ型は「String」である。
(1) 「Department（部署）」という名前の新たな名前空間を生成する。
(2) 「DEPARTMENT」というDBグループを生成する。
(3) このDBグループ内に、「Name（部署名）」という名前のテーブルを生成する。
(4) 「Name」のテーブルに格納されるデータは「Department」の名前空間に属し、そのデータ型は「String」である。
【0026】
また図２(b)は、以下の内容が規定された列定義コード36bを示すものである。
(1) 「Employee（社員）」という名前の新たな名前空間を生成する。
(2) 「EMPLOYEE」というDBグループを生成する。
(3) このDBグループ内に、「LoginId（ログインID）」、「Name（氏名）」、「BelongTo（所属）」という名前のテーブルを生成する。
(4) 「LoginId」のテーブルに格納されるデータは「Employee」の名前空間に属し、不変属性を備え（FixedAttributeEntity）、そのデータ型は「UniqueString（ユニークなString）」である。
(5) 「Name」のテーブルに格納されるデータは「Employee」の名前空間に属し、可変属性を備え（AttributeEntity）、そのデータ型は非ユニークな「String」である。
(6) 「BelongTo」のテーブルに格納されるデータは「Employee」の名前空間に属し、社員の所属する部署（Department）を特定する値が格納される。
(1) 「Employee（社員）」という名前の新たな名前空間を生成する。
(2) 「EMPLOYEE」というDBグループを生成する。
(3) このDBグループ内に、「LoginId（ログインID）」、「Name（氏名）」、「BelongTo（所属）」という名前のテーブルを生成する。
(4) 「LoginId」のテーブルに格納されるデータは「Employee」の名前空間に属し、不変属性を備え（FixedAttributeEntity）、そのデータ型は「UniqueString（ユニークなString）」である。
(5) 「Name」のテーブルに格納されるデータは「Employee」の名前空間に属し、可変属性を備え（AttributeEntity）、そのデータ型は非ユニークな「String」である。
(6) 「BelongTo」のテーブルに格納されるデータは「Employee」の名前空間に属し、社員の所属する部署（Department）を特定する値が格納される。
【0027】
作成された列定義コード36は、開発者端末16からAPサーバ12に送信される。
以下、図３のフローチャートに従い、APサーバ12における処理手順について説明する。
まず、列定義コード36を受け付けたAPサーバ12では（Ｓ10）、コンパイラ20が列定義プログラムにコンパイルする（Ｓ12）。
この際、列定義コード36中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
以下、図３のフローチャートに従い、APサーバ12における処理手順について説明する。
まず、列定義コード36を受け付けたAPサーバ12では（Ｓ10）、コンパイラ20が列定義プログラムにコンパイルする（Ｓ12）。
この際、列定義コード36中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
【0028】
列定義プログラム記憶部22に新たな列定義プログラムが格納されると（Ｓ14）、テーブル生成指示部26が起動し、列定義プログラムの定義内容に従い、必要な新規テーブルの生成を指示するSQLをDBサーバ14のDB管理システム32に送信する（Ｓ16）。
これを受けたDB管理システム32は、対応のテーブルを生成し、テーブル記憶部34に格納する。
これを受けたDB管理システム32は、対応のテーブルを生成し、テーブル記憶部34に格納する。
【0029】
図４は、図２(a)の列定義コード36aに対応して生成されたテーブルの例を示しており、名前空間の名前（Department）を反映した「DEPARTMENT」テーブル40と、「DEPARTMENT_NAME」テーブル42と、「DEPARTMENT_DELETE」テーブル44が生成される。
「DEPARTMENT」テーブル40は、図４(a)に示すように、主キー（PK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目のみを備えている。
また、「DEPARTMENT_NAME」テーブル42は、図４(b)に示すように、主キー（PK）としての「NAME_ID」と、外部キー（FK）としての「DEPARTMENT_ID」と、実体データ（部署名）が格納される「NAME」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「DEPARTMENT_DELETE」テーブル44は、図４(c)に示すように、主キー（PK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「DEPARTMENT」テーブル40は、図４(a)に示すように、主キー（PK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目のみを備えている。
また、「DEPARTMENT_NAME」テーブル42は、図４(b)に示すように、主キー（PK）としての「NAME_ID」と、外部キー（FK）としての「DEPARTMENT_ID」と、実体データ（部署名）が格納される「NAME」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「DEPARTMENT_DELETE」テーブル44は、図４(c)に示すように、主キー（PK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
【0030】
すなわち、各テーブルは主キーまたは外部キーとして「DEPARTMENT_ID」を統合IDとして共通に保有することにより、同一の名前空間に属する一連のデータとして相互に関連付けられている。また、各テーブルのテーブル名にも共通の「DEPARTMENT」が冠されることにより、他の名前空間に属するテーブルとの差別化が図られている。
【0031】
このシステム10においては、レコードの削除は認められないというルールが設けられているため、組織の統廃合等によって不要になった部署データを参照対象から外す必要が生じた際には、「DEPARTMENT_DELETE」テーブル44に目的の部署に係る「DEPARTMENT_ID」を追加登録することにより、実質的な削除が実現される（詳細は後述）。
【0032】
図５は、図２(b)の列定義コード36bに対応して生成されたテーブルの例を示しており、名前空間の名前（Employee）を反映した「EMPLOYEE」テーブル46と、「EMPLOYEE_LOGINID」テーブル48と、「EMPLOYEE_NAME」テーブル50と、「EMPLOYEE_BELONGTO」テーブル52と、「EMPLOYEE_DELETE」テーブル54が生成される。
「EMPLOYEE」テーブル46は、図５(a)に示すように、主キー（PK）としての「EMPLOYEE_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目のみを備えている。
また、「EMPLOYEE_LOGINID」テーブル48は、図５(b)に示すように、主キー及び外部キー（PK/FK）としての「EMPLOYEE_ID」と、「LOGINID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_NAME」テーブル50は、図５(c)に示すように、主キー（PK）としての「NAME_ID」と、外部キー（FK）としての「EMPLOYEE_ID」と、実体データ（氏名）が格納される「NAME」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_BELONGTO」テーブル52は、図５(d)に示すように、主キー（PK）としての「BELONGTO_ID」と、外部キー（FK）としての「EMPLOYEE_ID」と、第２外部キー（AFK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_DELETE」テーブル54は、図５(e)に示すように、主キー（PK）としての「EMPLOYEE_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE」テーブル46は、図５(a)に示すように、主キー（PK）としての「EMPLOYEE_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目のみを備えている。
また、「EMPLOYEE_LOGINID」テーブル48は、図５(b)に示すように、主キー及び外部キー（PK/FK）としての「EMPLOYEE_ID」と、「LOGINID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_NAME」テーブル50は、図５(c)に示すように、主キー（PK）としての「NAME_ID」と、外部キー（FK）としての「EMPLOYEE_ID」と、実体データ（氏名）が格納される「NAME」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_BELONGTO」テーブル52は、図５(d)に示すように、主キー（PK）としての「BELONGTO_ID」と、外部キー（FK）としての「EMPLOYEE_ID」と、第２外部キー（AFK）としての「DEPARTMENT_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
「EMPLOYEE_DELETE」テーブル54は、図５(e)に示すように、主キー（PK）としての「EMPLOYEE_ID」と、タイムスタンプとしての「REG_TIME」のデータ項目を備えている。
【0033】
この場合も、各テーブルに主キーまたは外部キーとして「EMPLOYEE_ID」の統合IDを共通に持たせることにより、同一の名前空間に属する一連のデータとして相互間が関連付けられている。また、各テーブルのテーブル名にも共通の「EMPLOYEE」が冠されることにより、他の名前空間に属するテーブルとの差別化が図られている。
【0034】
「EMPLOYEE_LOGINID」テーブル48の場合、上記のように列定義コード36bにおいて「不変属性（FixedAttributeEntity）」が規定されており、値の変更が許されないため、「LOGINID_ID」のような独自の主キーが設けられることなく、「EMPLOYEE_ID」が主キー及び外部キーとしての役割を兼ねている。
「EMPLOYEE_ BELONGTO」テーブル52においては、第２外部キー（AFK）として「DEPARTMENT_ID」を持たせることにより、異なる名前空間（DBグループ）に属するデータが参照先として指定されている。
退職等によって不要になった社員データを参照対象から外す際には、「EMPLOYEE_DELETE」テーブル54に目的の社員の「EMPLOYEE_ID」を追加登録することにより、実質的な削除が実現される。
「EMPLOYEE_ BELONGTO」テーブル52においては、第２外部キー（AFK）として「DEPARTMENT_ID」を持たせることにより、異なる名前空間（DBグループ）に属するデータが参照先として指定されている。
退職等によって不要になった社員データを参照対象から外す際には、「EMPLOYEE_DELETE」テーブル54に目的の社員の「EMPLOYEE_ID」を追加登録することにより、実質的な削除が実現される。
【0035】
つぎに開発者は、開発者端末16上のテキストエディタで行定義コード38を記述する。
この行定義コード38は、バラバラに生成された複数の列を、横方向への広がりを持った行として統合するために、行の名前空間と、行を構成する列の名前やデータ型等をクラス（型）として宣言するコードを意味している。
この行定義コード38は、バラバラに生成された複数の列を、横方向への広がりを持った行として統合するために、行の名前空間と、行を構成する列の名前やデータ型等をクラス（型）として宣言するコードを意味している。
【0036】
図６は、部署データに係る行定義コード38aを示すものであり、以下の内容が規定されている。
(1) 「DepartmentField」という新たな行の名前空間（行空間）を生成する。
(2) この名前空間内には、「DepartmentId」という名前のデータ項目を配置する。このデータ項目のデータ型は「Integer」であり、必須項目（Mandatory）である。
(3) この名前空間内には、「Name」という名前のデータ項目を配置する。このデータ項目のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Department型（Outerクラス）」に属する「Name型（Innerクラス）」を継承する。
(1) 「DepartmentField」という新たな行の名前空間（行空間）を生成する。
(2) この名前空間内には、「DepartmentId」という名前のデータ項目を配置する。このデータ項目のデータ型は「Integer」であり、必須項目（Mandatory）である。
(3) この名前空間内には、「Name」という名前のデータ項目を配置する。このデータ項目のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Department型（Outerクラス）」に属する「Name型（Innerクラス）」を継承する。
【0037】
作成された行定義コード38aは、開発者端末16からAPサーバ12に送信され、これを受け付けたAPサーバ12では（Ｓ18）、コンパイラ20が行定義プログラムにコンパイルする（Ｓ20）。
この際、行定義コード中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
この際、行定義コード中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
【0038】
行定義プログラム記憶部24に行定義プログラムが格納された時点で（Ｓ22）、データ処理部28を介したデータの登録が可能となる。
すなわち、データ処理部28は行定義プログラム及び列定義プログラムを参照してデータ登録画面を生成し、ユーザ端末18に送信する（Ｓ24）。
この結果、図７(a)に示すように、ユーザ端末18のWebブラウザ上に部署データ登録画面56が表示される。
すなわち、データ処理部28は行定義プログラム及び列定義プログラムを参照してデータ登録画面を生成し、ユーザ端末18に送信する（Ｓ24）。
この結果、図７(a)に示すように、ユーザ端末18のWebブラウザ上に部署データ登録画面56が表示される。
【0039】
この部署データ登録画面56の生成に際し、データ処理部28は「英語／日本語」のマッピングデータを参照することにより、「『DepartmentId』→『部署ID』」のようにデータ項目の表示を日本語化している。
「部署ID（DepartmentId）」の値はデータ処理部28によってユニークなIDが自動採番されるため、ユーザは「部署名（Name）」の入力欄に自社の実在部署名（例えば「製造部」）をタイプ入力し、登録ボタン58をクリックする。
「部署ID（DepartmentId）」の値はデータ処理部28によってユニークなIDが自動採番されるため、ユーザは「部署名（Name）」の入力欄に自社の実在部署名（例えば「製造部」）をタイプ入力し、登録ボタン58をクリックする。
【0040】
ユーザ端末18からの入力データをAPサーバ12が受け付けると（Ｓ26）、データ処理部28が入力データの適合性をチェックした上で（Ｓ28）、DB管理システム32にSQLを発行し、DBサーバ14の各テーブルに格納させる（Ｓ30）。適合性のチェックについては、後述する。
【0041】
図８は、部署データの具体的な登録例を示すものであり、図８(a)に示すように、DEPARTMENTテーブル40に「DEPARTMENT_ID：10」及び「REG_TIME：2021/05/18/12:43:51」のレコードが格納される。
同時に、図８(b)に示すように、DEPARTMENT_NAMEテーブル42に「NAME_ID：10」、「DEPARTMENT_ID：10」、「NAME：製造部」、「REG_TIME：2021/05/18/12:43:51」のレコードが格納される。
「NAME_ID」には、データ処理部28によってユニークなIDが自動採番される。
同時に、図８(b)に示すように、DEPARTMENT_NAMEテーブル42に「NAME_ID：10」、「DEPARTMENT_ID：10」、「NAME：製造部」、「REG_TIME：2021/05/18/12:43:51」のレコードが格納される。
「NAME_ID」には、データ処理部28によってユニークなIDが自動採番される。
【0042】
ユーザが図７(a)の行追加ボタン60をクリックすると、図７(b)に示すように次の入力行が追加される。これに対しユーザは、「部署名（Name）」の入力欄に自社の他の部署名（例えば「設計部」）を入力し、登録ボタン58をクリックする。
この結果、図８(a)に示すように、DEPARTMENTテーブル40に「DEPARTMENT_ID：20」及び「REG_TIME：2021/05/18/12:44:52」のレコードが格納される。
同時に、図８(b)に示すように、DEPARTMENT_NAMEテーブル42に「NAME_ID：20」、「DEPARTMENT_ID：20」、「NAME：設計部」、「REG_TIME：2021/05/18/12:44:52」のレコードが格納される。
なお、データの格納が完了した後、登録ボタン58は編集ボタン62に入れ替わり、この編集ボタン62をクリックすると登録ボタン58に変化する。
この結果、図８(a)に示すように、DEPARTMENTテーブル40に「DEPARTMENT_ID：20」及び「REG_TIME：2021/05/18/12:44:52」のレコードが格納される。
同時に、図８(b)に示すように、DEPARTMENT_NAMEテーブル42に「NAME_ID：20」、「DEPARTMENT_ID：20」、「NAME：設計部」、「REG_TIME：2021/05/18/12:44:52」のレコードが格納される。
なお、データの格納が完了した後、登録ボタン58は編集ボタン62に入れ替わり、この編集ボタン62をクリックすると登録ボタン58に変化する。
【0043】
図７(c)は、ユーザが上記の入力操作を繰り返すことによって、６件のデータが登録されたことを示している。
後日、一旦登録したデータを修正する場合、利用者は修正を希望するデータの編集ボタン62をクリックする。例えば、部署ID：40の現在の部署名である「全社」を変更する場合には、部署ID：40の編集ボタン62をクリックして部署名欄を編集可能化した上で、他の部署名を上書きし、登録ボタン58をクリックする。
この結果、図８(b)に示すように、「NAME_ID：70」、「DEPARTMENT_ID：40」、「NAME：東京本社」、「REG_TIME：2021/10/15/14:40:26」のレコードがDEPARTMENT_NAMEテーブル42に追加で登録される。
後日、一旦登録したデータを修正する場合、利用者は修正を希望するデータの編集ボタン62をクリックする。例えば、部署ID：40の現在の部署名である「全社」を変更する場合には、部署ID：40の編集ボタン62をクリックして部署名欄を編集可能化した上で、他の部署名を上書きし、登録ボタン58をクリックする。
この結果、図８(b)に示すように、「NAME_ID：70」、「DEPARTMENT_ID：40」、「NAME：東京本社」、「REG_TIME：2021/10/15/14:40:26」のレコードがDEPARTMENT_NAMEテーブル42に追加で登録される。
【0044】
このシステム10では、一旦登録したレコードの修正は禁止されるルールを採用しているため、ユーザが値の修正を希望する場合には、新たな値を備えたレコードを追加すると共に、対応する従前のレコードは参照対象外とすることで、実質的な修正を実現している。
具体的には、データ処理部28が部署データを参照するに際し、「DEPARTMENT_ID：40」のレコードが２件存在していることを認知した場合、両レコードのタイムスタンプを比較し、より若い「NAME_ID：70」のレコードを参照対象とする。
ただし、古い「NAME_ID：40」のレコードもDEPARTMENT_NAMEテーブル42には残されているため、後で部署名の変遷履歴を辿ることが可能となる。
具体的には、データ処理部28が部署データを参照するに際し、「DEPARTMENT_ID：40」のレコードが２件存在していることを認知した場合、両レコードのタイムスタンプを比較し、より若い「NAME_ID：70」のレコードを参照対象とする。
ただし、古い「NAME_ID：40」のレコードもDEPARTMENT_NAMEテーブル42には残されているため、後で部署名の変遷履歴を辿ることが可能となる。
【0045】
また、一旦登録した部署データを削除する場合、ユーザは削除を希望するデータ（例えば、「部署ID：30」）の削除ボタン64をクリックする。
この結果、図８(c)に示すように、「DEPARTMENT_ID：30」、「REG_TIME：2021/10/15/14:31:21」のレコードが、DEPARTMENT_DELETEテーブル44に登録される。
この結果、図８(c)に示すように、「DEPARTMENT_ID：30」、「REG_TIME：2021/10/15/14:31:21」のレコードが、DEPARTMENT_DELETEテーブル44に登録される。
【0046】
このシステム10においては上記の通り、一旦登録したレコードの削除は禁止されるルールを採用しているため、ユーザがレコードの削除を希望する場合には、対応レコードのDEPARTMENT_IDをDEPARTMENT_DELETEテーブル44に格納することで、データの実質的な削除を実現している。
データ処理部28が部署データを参照する際には、まずDEPARTMENT_DELETEテーブル44を参照し、ここに登録されたDEPARTMENT_IDのタイムスタンプよりも古いタイムスタンプを備えた同一IDの部署データを参照対象外とする。
この場合も、一旦DEPARTMENT_DELETEテーブル44に登録された古いレコードはそのままDEPARTMENT_NAMEテーブル42に残されているため、後で部署名の変遷履歴を辿ることが可能となる。
データ処理部28が部署データを参照する際には、まずDEPARTMENT_DELETEテーブル44を参照し、ここに登録されたDEPARTMENT_IDのタイムスタンプよりも古いタイムスタンプを備えた同一IDの部署データを参照対象外とする。
この場合も、一旦DEPARTMENT_DELETEテーブル44に登録された古いレコードはそのままDEPARTMENT_NAMEテーブル42に残されているため、後で部署名の変遷履歴を辿ることが可能となる。
【0047】
図９は、社員データに係る行定義コード38bを示すものであり、以下の内容が規定されている。
(1) 「EmployeeField」という新たな行の名前空間（行空間）を生成する。
(2) この名前空間内には、「EmployeeId」という名前のデータ項目と、「LoginId」という名前のデータ項目と、「Name」という名前のデータ項目と、「DepartmentId」という名前のデータ項目を配置する。
(3) 「EmployeeId」のデータ型は「Integer」であり、必須項目（Mandatory）である。
(4) 「LoginId」のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「LoginId型（Innerクラス）」を継承する。
(5) 「Name」のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「Name型（Innerクラス）」を継承する。
(6) 「DepartmentId」のデータ型は「Integer」であり、任意項目（Optional）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「BelongTo型（Innerクラス）」を継承する。
(1) 「EmployeeField」という新たな行の名前空間（行空間）を生成する。
(2) この名前空間内には、「EmployeeId」という名前のデータ項目と、「LoginId」という名前のデータ項目と、「Name」という名前のデータ項目と、「DepartmentId」という名前のデータ項目を配置する。
(3) 「EmployeeId」のデータ型は「Integer」であり、必須項目（Mandatory）である。
(4) 「LoginId」のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「LoginId型（Innerクラス）」を継承する。
(5) 「Name」のデータ型は「String」であり、必須項目（Mandatory）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「Name型（Innerクラス）」を継承する。
(6) 「DepartmentId」のデータ型は「Integer」であり、任意項目（Optional）である。このデータ項目は、列空間における「Employee型（Outerクラス）」に属する「BelongTo型（Innerクラス）」を継承する。
【0048】
作成された行定義コード38bは、開発者端末16からAPサーバ12に送信され、コンパイラ20を介して行定義プログラムにコンパイルされる。
この際、行定義コード中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
この際、行定義コード中の記述に矛盾が存在した場合、コンパイラ20の型チェック機能によって検知され、エラーメッセージが開発者端末16に出力される。
【0049】
行定義プログラム記憶部24に行定義プログラムが格納された時点で、データ処理部28を介した社員データの登録が可能となる。
すなわち、データ処理部28は行定義プログラム及び列定義プログラムを参照して社員データの登録画面を生成し、ユーザ端末18に送信する。
この結果、図１０(a)に示すように、ユーザ端末18のWebブラウザ上に社員データ登録画面66が表示される。
すなわち、データ処理部28は行定義プログラム及び列定義プログラムを参照して社員データの登録画面を生成し、ユーザ端末18に送信する。
この結果、図１０(a)に示すように、ユーザ端末18のWebブラウザ上に社員データ登録画面66が表示される。
【0050】
この社員登録画面66の生成に際し、データ処理部28は「英語／日本語」のマッピングデータを参照することにより、「『EmployeeId』→『社員ID』」のようにデータ項目の表示を日本語化している。
「社員ID（EmployeeId）」の値はデータ処理部28によってユニークなIDが自動採番されるため、ユーザはまず「社員ID：10」の社員について「ログインID（LoginId）」の入力欄に「reiwa」のログインIDを入力すると共に、「氏名（Name）」の入力欄に「山田 花子」を入力する。
「社員ID（EmployeeId）」の値はデータ処理部28によってユニークなIDが自動採番されるため、ユーザはまず「社員ID：10」の社員について「ログインID（LoginId）」の入力欄に「reiwa」のログインIDを入力すると共に、「氏名（Name）」の入力欄に「山田 花子」を入力する。
【0051】
つぎに、ユーザが「部署ID（DepartmentId）」の部署選択ボタン68をクリックすると、部署IDと部署名の組合せが記載された部署選択リスト70が展開するため、ユーザは必要な部署IDと部署名の組合せを選択した上で確定ボタン72をクリックする。
この部署選択リスト70は、データ処理部28が「Department（部署）」の名前空間に属する「DEPARTMENT_Name（部署名）」テーブル42（図８(b)）を参照することによって生成されたものであり、ユーザが間違った部署IDを選択することを有効に防止できる。
なお、部署ID（DepartmentId）については、図９の行定義コード38bにおいて「任意項目（Optional）」である旨が規定されているため、部署IDの選択をしなくてもデータの登録自体がエラーとなることはない。
この部署選択リスト70は、データ処理部28が「Department（部署）」の名前空間に属する「DEPARTMENT_Name（部署名）」テーブル42（図８(b)）を参照することによって生成されたものであり、ユーザが間違った部署IDを選択することを有効に防止できる。
なお、部署ID（DepartmentId）については、図９の行定義コード38bにおいて「任意項目（Optional）」である旨が規定されているため、部署IDの選択をしなくてもデータの登録自体がエラーとなることはない。
【0052】
以上の入力及び選択を済ませたユーザが登録ボタン58をクリックすると、図１１(a)に示すように、EMPLOYEEテーブル46に「EMPLOYEE_ID：10」及び「REG_TIME：2021/05/18/12:55:21」のレコードが格納される。
同時に、EMPLOYEE_LOGINIDテーブル48に「EMPLOYEE_ID：10」、「LOGIN_ID：reiwa」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(b)）。
また、EMPLOYEE_NAMEテーブル50に「NAME_ID：10」、「EMPLOYEE_ID：10」、「NAME：山田 花子」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(c)）。
さらに、EMPLOYEE_BELONGTOテーブル52に「BELONGTO_ID：10」、「EMPLOYEE_ID：10」、「DEPARTMENT_ID：20」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(d)）。
因みに、「NAME_ID」及び「BELONGTO_ID」には、データ処理部28によってユニークなIDが自動採番される。
同時に、EMPLOYEE_LOGINIDテーブル48に「EMPLOYEE_ID：10」、「LOGIN_ID：reiwa」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(b)）。
また、EMPLOYEE_NAMEテーブル50に「NAME_ID：10」、「EMPLOYEE_ID：10」、「NAME：山田 花子」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(c)）。
さらに、EMPLOYEE_BELONGTOテーブル52に「BELONGTO_ID：10」、「EMPLOYEE_ID：10」、「DEPARTMENT_ID：20」、「REG_TIME：2021/05/18/12:55:21」のレコードが格納される（図１１(d)）。
因みに、「NAME_ID」及び「BELONGTO_ID」には、データ処理部28によってユニークなIDが自動採番される。
【0053】
図１０(a)の行追加ボタン60をクリックすると次の入力行が追加されるため、ユーザは残りの社員についてログインID及び名前をタイプ入力すると共に、必要に応じて部署IDの選択入力を行う。
図１０(b)は、ユーザが上記の入力操作を繰り返すことによって４件の社員データを登録したことを示している。
図１０(b)は、ユーザが上記の入力操作を繰り返すことによって４件の社員データを登録したことを示している。
【0054】
一旦登録した社員データを修正する場合、ユーザは修正を希望する社員データの編集ボタン62をクリックする。
例えば、社員ID：10の名字を変更する場合、ユーザが編集ボタン62をクリックすると、氏名欄が編集可能化されるため、ユーザは名前を「山田 花子」から「佐藤 花子」に書き換えた後、登録ボタン58をクリックする。
この結果、図１１(c)に示すように、EMPLOYEE_NAMEテーブル50に「NAME_ID：50」、「EMPLOYEE_ID：10」、「NAME：佐藤 花子」、「REG_TIME：2021/07/03/14:29:51」の新たなレコードが追加される。
以後、データ処理部28は「EMPLOYEE_ID：10」の社員データを参照する際には、タイムスタンプの新しい「佐藤 花子」を現在の名前として適用する。
例えば、社員ID：10の名字を変更する場合、ユーザが編集ボタン62をクリックすると、氏名欄が編集可能化されるため、ユーザは名前を「山田 花子」から「佐藤 花子」に書き換えた後、登録ボタン58をクリックする。
この結果、図１１(c)に示すように、EMPLOYEE_NAMEテーブル50に「NAME_ID：50」、「EMPLOYEE_ID：10」、「NAME：佐藤 花子」、「REG_TIME：2021/07/03/14:29:51」の新たなレコードが追加される。
以後、データ処理部28は「EMPLOYEE_ID：10」の社員データを参照する際には、タイムスタンプの新しい「佐藤 花子」を現在の名前として適用する。
【0055】
なお、編集ボタン62をクリックした際には部署ID欄に部署選択ボタン68が表示されるため、所属部署の変更も可能となる。
これに対し、ログインIDについては列定義コード36bにおいて不変属性の設定（FixedAttributeEntity）がなされており（図２(b)）、行定義コード38bにおいても「LoginId」について「= attr(Employee.LoginId.class)」とあり（図９）、この設定が継承されているため、編集ボタン62をクリックしてもログインID欄については編集可能化はなされない。
これに対し、ログインIDについては列定義コード36bにおいて不変属性の設定（FixedAttributeEntity）がなされており（図２(b)）、行定義コード38bにおいても「LoginId」について「= attr(Employee.LoginId.class)」とあり（図９）、この設定が継承されているため、編集ボタン62をクリックしてもログインID欄については編集可能化はなされない。
【0056】
一旦登録した社員データを削除する場合、ユーザは削除を希望するデータ（例えば、「社員ID：20」）の削除ボタン64をクリックする。
この結果、図１１(e)に示すように、「EMPLOYEE_ID：20」、「REG_TIME：2021/07/03/14:40:56」のレコードが、EMPLOYEE_DELETEテーブル54に登録される。
この結果、図１１(e)に示すように、「EMPLOYEE_ID：20」、「REG_TIME：2021/07/03/14:40:56」のレコードが、EMPLOYEE_DELETEテーブル54に登録される。
【0057】
ログインIDについては、列定義コード36bにおいて「UniqueString」の型制約が設定されており、上記のように行定義コード38bにおいてもこの設定が継承されているため、例えば「reiwa」のLoginIdが重ねて入力された場合、データ処理部28はEMPLOYEE_LOGINIDテーブル48を参照して重複を検知し、ユーザ端末18にエラーメッセージを返す。これが、Ｓ28の「適合性チェック」に該当する。
【0058】
ユーザ端末18からAPサーバ12には、以下のようなJSON形式でデータが送信される。
{"employeeid" : "60",
"loginid" : "reiwa",
"name" : "加藤 恵子",
"departmentid" : "50"},
このJSON形式には名前空間という概念が存在しないが、JSONオブジェクト内のキー名"loginid"と、論理行空間（EmployeeField）のメンバーである「LoginId」と名前が一致している。このため、列空間（Employee.LoginId）定義から「UniqueString」の型制約が求まる結果、LoginIdの重複登録はデータ処理部28によって有効に排除される。
{"employeeid" : "60",
"loginid" : "reiwa",
"name" : "加藤 恵子",
"departmentid" : "50"},
このJSON形式には名前空間という概念が存在しないが、JSONオブジェクト内のキー名"loginid"と、論理行空間（EmployeeField）のメンバーである「LoginId」と名前が一致している。このため、列空間（Employee.LoginId）定義から「UniqueString」の型制約が求まる結果、LoginIdの重複登録はデータ処理部28によって有効に排除される。
【0059】
図１２は、ユーザが登録済みのデータを参照する際の検索画面74を示している。
まず、ユーザがマスタ一覧76の中から「社員」を選択すると、リンク表示エリア78の中央に社員アイコン80が表示されると共に、社員データの参照先である部署アイコン82が表示され、社員アイコン80から部署アイコン82に向かう矢印84が表示される。
このリンク表示エリア78を見ることにより、ユーザは社員データと部署データ間の関連性を視覚的に認識することができる。
まず、ユーザがマスタ一覧76の中から「社員」を選択すると、リンク表示エリア78の中央に社員アイコン80が表示されると共に、社員データの参照先である部署アイコン82が表示され、社員アイコン80から部署アイコン82に向かう矢印84が表示される。
このリンク表示エリア78を見ることにより、ユーザは社員データと部署データ間の関連性を視覚的に認識することができる。
【0060】
ここでユーザが検索ボタン86をクリックすると、データ処理部28からDBサーバ14に社員データ及び部署データの抽出を求めるSQLが発行されCUS、その結果が検索結果リスト88として表示される。
社員データと部署データは、社員データの「BelongTo」において関連性が定義されているため、行定義コード38において両データを結合するためのSQLコードが記述されていなくても、図示の通り、社員データ及びと部署データが連結された表が生成される。
ユーザがダウンロードボタン90をクリックすると、検索結果リストがCSV等のファイルとしてAPサーバ12からユーザ端末18に送信される。
社員データと部署データは、社員データの「BelongTo」において関連性が定義されているため、行定義コード38において両データを結合するためのSQLコードが記述されていなくても、図示の通り、社員データ及びと部署データが連結された表が生成される。
ユーザがダウンロードボタン90をクリックすると、検索結果リストがCSV等のファイルとしてAPサーバ12からユーザ端末18に送信される。
【0061】
このシステム10においては、行定義コード中の右辺に対応の列定義コードを記述することにより、その設定を行定義コードに継承させているため、列空間の名前が変更されたにもかかわらず行定義コードが変更されていない場合には、データ処理部28において名前の不一致が検出され、ユーザ端末18にエラーメッセージとして返される。
このように実行時における型チェック機能が働くため、名前の修正をしないまま放置されている行定義プログラムを検知することが可能となり、ユーザに対し早急な修正を促すことができる。
このように実行時における型チェック機能が働くため、名前の修正をしないまま放置されている行定義プログラムを検知することが可能となり、ユーザに対し早急な修正を促すことができる。
【0062】
上記においては、オペレータが専用の登録画面からキーボートやマウスを操作してデータの登録を行う例を示したが、汎用的なCSV（Comma Separated Values）形式のデータを読み込み、データベースの所定のテーブルに登録することもできる。
この機能は、他のシステムで管理されている既存のデータをこのシステムに移行させる際などに有益である。
この機能は、他のシステムで管理されている既存のデータをこのシステムに移行させる際などに有益である。
【0063】
図１３は、このCSVファイルの処理に対応させた第２のデータ処理システム100を示しており、第１のデータ処理システム10の構成を踏襲しつつ、APサーバ12の記憶装置内にCSV定義プログラム記憶部102が追加された点に特徴を有している。
このCSV定義プログラム記憶部102内には、CSV定義プログラムが格納されている。
このCSV定義プログラムは、開発者が開発者端末16上のテキストエディタで記述したCSV定義コード104を、コンパイラ20がコンパイルすることによって生成される。
このCSV定義プログラム記憶部102内には、CSV定義プログラムが格納されている。
このCSV定義プログラムは、開発者が開発者端末16上のテキストエディタで記述したCSV定義コード104を、コンパイラ20がコンパイルすることによって生成される。
【0064】
図１４は、DBサーバ14のテーブル記憶部34に格納されたテーブルを例示するものであり、ManufacturingField（「Manufacturing（工事）」の行空間）106に属するMANUFACTURING（工事）テーブル108及びMANUFACTURING_NUMBER（工事番号）テーブル110と、OrderField（「Order（注文）」の行空間）112に属するORDER_PRODUCT（注文製品）テーブル114及びORDER_CUSTOMER（注文顧客）テーブル116と、CustomerField（「Customer（顧客）」の行空間）118に属するCUSTOMER_CODE（顧客コード）テーブル120及びCUSTOMER_NAME（顧客名）テーブル122と、ProductField（「Product（製品）」の行空間）124に属するPRODUCT_CODE（製品コード）テーブル126が少なくとも格納されている。
【0065】
図示は省略したが、各テーブルは列定義プログラム記憶部22に格納された対応の列定義プログラムに基づき、テーブル生成指示部26及びDB管理システム32を介して生成されている。
また、各行空間（Field／行の名前空間）は、行定義プログラム記憶部24に格納された対応の行定義プログラムに基づいて形成されている。
また、各行空間（Field／行の名前空間）は、行定義プログラム記憶部24に格納された対応の行定義プログラムに基づいて形成されている。
【0066】
これらのテーブルは、顧客からの注文データを管理するためのものであり、例えば図１５に示す注文データ登録画面128を通じてユーザが顧客コード、製品コード及び工事種別（新規／修理／改造）を選択入力すると共に、工事番号を打鍵入力すると、データ処理部28によってORDER_PRODUCTテーブル114、ORDER_CUSTOMERテーブル116、MANUFACTURINGテーブル108及びMANUFACTURING_NUMBERテーブル110にレコードが追加される。
【0067】
因みに、注文ID（ORDER_ID）はデータ処理部28によって自動的に採番される人工キーである。
また、ORDER_PRODUCTテーブル114のPRODUCT_IDは、選択入力された製品コード（CODE）を基にPRODUCT_CODEテーブル126を参照することにより、取得される。
さらに、ORDER_CUSTOMERテーブル116のCUSTOMER_IDは、選択入力された顧客コード（CODE）を基にCUSTOMER_CODEテーブル120を参照することにより、取得される。
また、ORDER_PRODUCTテーブル114のPRODUCT_IDは、選択入力された製品コード（CODE）を基にPRODUCT_CODEテーブル126を参照することにより、取得される。
さらに、ORDER_CUSTOMERテーブル116のCUSTOMER_IDは、選択入力された顧客コード（CODE）を基にCUSTOMER_CODEテーブル120を参照することにより、取得される。
【0068】
以上のように、行定義プログラムに従って生成された専用の注文データ登録画面128を介して顧客コード、製品コード、工事番号、工事種別を特定する注文データが入力された場合、データ処理部28は入力された各値の属すべき名前空間を認識しているため、ORDER_PRODUCTテーブル114、ORDER_CUSTOMERテーブル116、MANUFACTURINGテーブル108及びMANUFACTURING_NUMBERテーブル110を正しく更新することができ、トランザクションデータである注文データの管理が可能となる。
【0069】
これに対し、図１６に示すように、「D0001,GD001,OD123,NEW」のようにカンマで区切られた文字列が複数行に亘って記述されたCSVファイル130がユーザ端末18から入力された場合、データ処理部28はCSV定義プログラム記憶部102に格納されたCSV定義プログラムを参照することにより、各行の１番目の文字列が「CUSTOMER CODE（顧客コード）」を表しており、２番目の文字列が「PRODUCT CODE（製品コード）」を、３番目の文字列が「MANUFACTURING NUMBER（工事番号）」を、４番目の文字列が「MANUFACTURING TYPE（工事種別）」をそれぞれ表していることを認識し、各文字列を対応のテーブルに正しく格納することができる。
【0070】
図１７は上記CSV定義プログラムの基になったCSV定義コード104を示しており、以下のことが定義されている。
(1) 入力されるCSVファイルに含まれるデータが、「CustomerField」、「ProductField」、「ManufacturingField」の行空間に属するものであること（104(a)）。
(2) 入力される各行の４つの文字列が、順に「customer.Code」、「product.Code」、「manufacturing.Number」、「manufacturing.Type」を意味するものであること（104(b)）。
(1) 入力されるCSVファイルに含まれるデータが、「CustomerField」、「ProductField」、「ManufacturingField」の行空間に属するものであること（104(a)）。
(2) 入力される各行の４つの文字列が、順に「customer.Code」、「product.Code」、「manufacturing.Number」、「manufacturing.Type」を意味するものであること（104(b)）。
【0071】
CSVファイルは本来的にデータの構造を表現することができず、手掛かりとなるのはカンマで区切られた文字列の順序のみとなるが、このCSV定義を参照することにより、データ処理部28は入力されたCSVファイルの各文字列を然るべきテーブルに格納することが可能となる。
【0072】
ユーザは、テーブル記憶部34に格納された各テーブルから必要なデータを抽出し、汎用的なCSVファイルとして取得することもできる。
すなわち、ユーザ端末18からCSVファイル形式でのデータ抽出リクエストが送信されると、図１８に示すように、データ処理部28から抽出データ指定画面140が送信され、ユーザ端末18のブラウザ上に表示される。
ここでユーザは、CSVの行の最初（１列目）に配置したいデータの属する行空間を指定する。
すなわち、ユーザ端末18からCSVファイル形式でのデータ抽出リクエストが送信されると、図１８に示すように、データ処理部28から抽出データ指定画面140が送信され、ユーザ端末18のブラウザ上に表示される。
ここでユーザは、CSVの行の最初（１列目）に配置したいデータの属する行空間を指定する。
【0073】
まず、図１８(a)に示すように、「left（ManufacturingField, OrderField, CustomerField）」及び「right（ProductField）」の選択肢が表示されるため、ユーザは「left」または「right」の何れかを選択する。
ここでユーザが「left」を選択すると、今度は図１８(b)に示すように、「left（ManufacturingField, OrderField）」及び「right（CustomerField）」の選択肢が表示される。つまり、前回の選択時に選択されなかった「right」の「ProductField」が選択肢から除外され、代わりに「CustomerField」が選択肢の集合体である「left」側から単独の選択肢として「right」側に移動されている。
ここでユーザが「left」を選択すると、今度は図１８(b)に示すように、「left（ManufacturingField, OrderField）」及び「right（CustomerField）」の選択肢が表示される。つまり、前回の選択時に選択されなかった「right」の「ProductField」が選択肢から除外され、代わりに「CustomerField」が選択肢の集合体である「left」側から単独の選択肢として「right」側に移動されている。
【0074】
ここでもユーザが「left」を選択すると、図１８(c)に示すように、「left（ManufacturingField）」及び「right（OrderField）」の選択肢が表示される。この段階に至ると、「right」及び「left」の各選択肢が共に単独の行空間のみを含むものとなる。
【0075】
ここでユーザが「left（ManufacturingField）」を選択すると、図１８(d)に示すように、「ManufacturingField」の行空間に属する即値（実体的な値）、すなわち「Number」と「Type」が選択肢として表示される。
これに対しユーザが「Number」を選択すると、データ処理部28はCSVの行の最初（１列目）に配置すべきデータが、「ManufacturingField」に属する「Number」であるものと認識する。
これに対しユーザが「Number」を選択すると、データ処理部28はCSVの行の最初（１列目）に配置すべきデータが、「ManufacturingField」に属する「Number」であるものと認識する。
【0076】
ユーザがCSVの行の２列目に「ManufacturingField」の「Type」を配置することを希望する場合、「次の列を選択」ボタン142をクリックする。
この結果、図１８(a)の選択肢が再度表示される。この後、ユーザは上記と同様に３回連続で「left」を選択して図１８(d) の選択肢を表示させた上で、「Type」の選択肢をクリックする。
この結果、図１８(a)の選択肢が再度表示される。この後、ユーザは上記と同様に３回連続で「left」を選択して図１８(d) の選択肢を表示させた上で、「Type」の選択肢をクリックする。
【0077】
つぎに、ユーザがCSVの行の３列目に「CustomerField」の「Code」を配置することを希望する場合、「次の列を選択」ボタン142をクリックする。
この結果、図１９(a)に示すように、「left（ManufacturingField, OrderField, CustomerField）」及び「right（ProductField）」の選択肢が再度表示されるため、ユーザは「left」を選択する。
これにより、図１９(b)に示すように、「left（ManufacturingField, OrderField）」及び「right（CustomerField）」の選択肢が表示されるので、ユーザは「right」を選択する。
すると、図１９(c)に示すように、「CustomerField」の行空間に属する即値である「Code」と「Name」が選択肢として表示される。
ここでユーザが「Code」を選択すると、データ処理部28はCSVの行の３列目に配置すべきデータが、「CustomerField」に属する「Code」であるものと認識する。
この結果、図１９(a)に示すように、「left（ManufacturingField, OrderField, CustomerField）」及び「right（ProductField）」の選択肢が再度表示されるため、ユーザは「left」を選択する。
これにより、図１９(b)に示すように、「left（ManufacturingField, OrderField）」及び「right（CustomerField）」の選択肢が表示されるので、ユーザは「right」を選択する。
すると、図１９(c)に示すように、「CustomerField」の行空間に属する即値である「Code」と「Name」が選択肢として表示される。
ここでユーザが「Code」を選択すると、データ処理部28はCSVの行の３列目に配置すべきデータが、「CustomerField」に属する「Code」であるものと認識する。
【0078】
ユーザが、CSVの行の４列目に「CustomerField」の「Name」を配置することを希望する場合、「次の列を選択」ボタン142をクリックする。
この結果、図１９(a)の選択肢が再度表示されるため、ユーザは上記と同様、「left」及び「right」を選択して図１９(c) の選択肢を表示させた上で、「Name」をクリックする。
この結果、図１９(a)の選択肢が再度表示されるため、ユーザは上記と同様、「left」及び「right」を選択して図１９(c) の選択肢を表示させた上で、「Name」をクリックする。
【0079】
つぎに、ユーザがCSVの行の５列目に「ProductField」の「Code」を配置することを希望する場合、「次の列を選択」ボタン142をクリックする。
この結果、図２０(a)に示すように、「left（ManufacturingField, OrderField, CustomerField）」及び「right（ProductField）」の選択肢が再度表示されるため、ユーザは「right」を選択する。
これにより、図２０(b)に示すように、「ProductField」の行空間に属する唯一の即値である「Code」が表示される。
ここでユーザが「Code」をクリックすると、データ処理部28はCSVの行の５列目に配置すべきデータが、「ProductField」に属する「Code」であるものと認識する。
この結果、図２０(a)に示すように、「left（ManufacturingField, OrderField, CustomerField）」及び「right（ProductField）」の選択肢が再度表示されるため、ユーザは「right」を選択する。
これにより、図２０(b)に示すように、「ProductField」の行空間に属する唯一の即値である「Code」が表示される。
ここでユーザが「Code」をクリックすると、データ処理部28はCSVの行の５列目に配置すべきデータが、「ProductField」に属する「Code」であるものと認識する。
【0080】
画面の上部には「選択済みの列」の表示欄144が設けられており、これまでユーザが選択してきた各データ項目の名前と所属する行空間（Field）及び順番が列記されている。
この「選択済みの列」を確認した上で、ユーザが「データの抽出」ボタン146をクリックすると、データ処理部28は該当のテーブルからユーザの指定したデータ項目の値を取り出し、抽出結果画面を生成する。
この「選択済みの列」を確認した上で、ユーザが「データの抽出」ボタン146をクリックすると、データ処理部28は該当のテーブルからユーザの指定したデータ項目の値を取り出し、抽出結果画面を生成する。
【0081】
図２１は、ユーザ端末18のブラウザ上に表示された抽出結果画面150を示すものであり、「Manufacturing Number（工事番号）」、「Manufacturing Type（工事種別）」、「Customer code（顧客コード）」、「Customer Name（顧客名）」、「Product Code（製品コード）」のデータ項目の値を一行に並べた注文データ152が列記されている。各値の間にはコンマが打たれており、各行の末尾は改行されている。
【0082】
各注文データ152は、データ処理部28により、以下の手順によって生成される。
(1) MANUFACTULINGテーブル108に格納された「TYPE」と、MANUFACTULING_NUMBERテーブル110に格納された「NUMBER」とを、それぞれのMANUFACTULING_IDを介して結び付ける。
(2) MANUFACTULINGテーブル108に格納された「ORDER_ID」に基づいてORDER_PRODUCTテーブル114及びORDER_CUSTOMERテーブル116を参照し、対応のPRODUCT_ID及びCUSTOMER_IDを特定する。
(3) 上記PRODUCT_IDに基づいてPRODUCT_CODEテーブル126から対応の「CODE」を取得すると共に、CUSTOMER_IDに基づいてCUSTOMER_CODEテーブル120から対応の「CODE」を取得する。
(4) CUSTOMER_IDに基づいてCUSTOMER_NAMEテーブル122から対応の「NAME」を取得する。
(1) MANUFACTULINGテーブル108に格納された「TYPE」と、MANUFACTULING_NUMBERテーブル110に格納された「NUMBER」とを、それぞれのMANUFACTULING_IDを介して結び付ける。
(2) MANUFACTULINGテーブル108に格納された「ORDER_ID」に基づいてORDER_PRODUCTテーブル114及びORDER_CUSTOMERテーブル116を参照し、対応のPRODUCT_ID及びCUSTOMER_IDを特定する。
(3) 上記PRODUCT_IDに基づいてPRODUCT_CODEテーブル126から対応の「CODE」を取得すると共に、CUSTOMER_IDに基づいてCUSTOMER_CODEテーブル120から対応の「CODE」を取得する。
(4) CUSTOMER_IDに基づいてCUSTOMER_NAMEテーブル122から対応の「NAME」を取得する。
【0083】
この注文データ152のリストを確認し、ユーザが「ダウンロード」ボタン154をクリックすると、データ処理部28から上記注文データのCSVファイルがユーザ端末18に送信され、ローカルの記憶装置内に格納される。
ユーザは、このCSVファイルを介することで、第２のデータ処理システム100が管理している注文データを外部のシステムに受け渡すことが可能となる。
ユーザは、このCSVファイルを介することで、第２のデータ処理システム100が管理している注文データを外部のシステムに受け渡すことが可能となる。
【0084】
上記のように抽出データ指定画面140において、抽出すべきデータが属している行空間を「一の行空間（right）」と「それ以外の行空間（left）」との二者択一を繰り返すことで段階的に絞り込んでいき、最終的に残った行空間内の即値を選択する方式を採用しているため、ユーザは希望するデータ項目を容易かつ正確に指定可能となる。
【0085】
また、ユーザが選択肢を選択する都度、データ処理部28は選択結果をメモリ上の異なる領域に格納していくため、複数の行空間から同一の名前のデータを抽出する際でも、混同が生じることがない。
例えば、ユーザが選択した「CODE」は「CustomerField」及び「ProductField」に存在しており、名前だけで管理していると混同が生じるが、ユーザの選択結果を異なるメモリ領域に格納する際、各データの属する行空間を特定する情報も格納されるため、両者は明確に区別され得る。
例えば、ユーザが選択した「CODE」は「CustomerField」及び「ProductField」に存在しており、名前だけで管理していると混同が生じるが、ユーザの選択結果を異なるメモリ領域に格納する際、各データの属する行空間を特定する情報も格納されるため、両者は明確に区別され得る。
【0086】
図２２は、抽出データ指定画面140を実現するためのソースコードを例示するものであり、選択可能な行空間名として「ManufacturingField」、「OrderField」、「CustomerField」、「ProductField」が予め定義されている。
なお、日付の指定として「Date Time.YMDHMS asOf」とあり、最新のマスタ情報を参照することが規定されているが、この設定を変更することにより、注文データ発生時点でのマスタ情報を参照するように変更することもできる。
この結果、注文後に顧客名が変更されている場合であっても、注文時点の顧客名を表示させることが可能となる。
なお、日付の指定として「Date Time.YMDHMS asOf」とあり、最新のマスタ情報を参照することが規定されているが、この設定を変更することにより、注文データ発生時点でのマスタ情報を参照するように変更することもできる。
この結果、注文後に顧客名が変更されている場合であっても、注文時点の顧客名を表示させることが可能となる。
【符号の説明】
【0087】
10 第１のデータ処理システム
12 APサーバ
14 DBサーバ
16 開発者端末
18 ユーザ端末
20 コンパイラ
22 列定義プログラム記憶部
24 行定義プログラム記憶部
26 テーブル生成指示部
28 データ処理部
32 DB管理システム
34 テーブル記憶部
36 列定義コード
38 行定義コード
40 DEPARTMENTテーブル
42 DEPARTMENT_NAMEテーブル
44 DEPARTMENT_DELETEテーブル
46 EMPLOYEEテーブル
48 EMPLOYEE_LOGINIDテーブル
50 EMPLOYEE_NAMEテーブル
52 EMPLOYEE_BELONGTOテーブル
54 EMPLOYEE_DELETEテーブル
56 部署登録画面
58 登録ボタン
60 行追加ボタン
62 編集ボタン
64 削除ボタン
66 社員登録画面
68 部署選択ボタン
70 部署選択リスト
74 検索画面
76 マスタ一覧
78 リンク表示エリア
80 社員アイコン
82 部署アイコン
84 矢印
86 検索ボタン
88 検索結果リスト
90 ダウンロードボタン
100 第２のデータ処理システム
102 CSV定義プログラム記憶部
104 CSV定義コード
106 ManufacturingField
108 MANUFACTULINGテーブル
110 MANUFACTULING_NUMBERテーブル
112 OrderField
114 ORDER_PRODUCTテーブル
116 ORDER_CUSTOMERテーブル
118 CustomerField
120 CUSTOMER_CODEテーブル
122 CUSTOMER_NAMEテーブル
124 ProductField
126 PRODUCT_CODEテーブル
128 注文データ登録画面
130 CSVファイル
140 抽出データ指定画面
142 「次の列を選択」ボタン
144 「選択済みの列」の表示欄
146 「データの抽出」ボタン
150 抽出結果画面
152 注文データ
154 「ダウンロード」ボタン
12 APサーバ
14 DBサーバ
16 開発者端末
18 ユーザ端末
20 コンパイラ
22 列定義プログラム記憶部
24 行定義プログラム記憶部
26 テーブル生成指示部
28 データ処理部
32 DB管理システム
34 テーブル記憶部
36 列定義コード
38 行定義コード
40 DEPARTMENTテーブル
42 DEPARTMENT_NAMEテーブル
44 DEPARTMENT_DELETEテーブル
46 EMPLOYEEテーブル
48 EMPLOYEE_LOGINIDテーブル
50 EMPLOYEE_NAMEテーブル
52 EMPLOYEE_BELONGTOテーブル
54 EMPLOYEE_DELETEテーブル
56 部署登録画面
58 登録ボタン
60 行追加ボタン
62 編集ボタン
64 削除ボタン
66 社員登録画面
68 部署選択ボタン
70 部署選択リスト
74 検索画面
76 マスタ一覧
78 リンク表示エリア
80 社員アイコン
82 部署アイコン
84 矢印
86 検索ボタン
88 検索結果リスト
90 ダウンロードボタン
100 第２のデータ処理システム
102 CSV定義プログラム記憶部
104 CSV定義コード
106 ManufacturingField
108 MANUFACTULINGテーブル
110 MANUFACTULING_NUMBERテーブル
112 OrderField
114 ORDER_PRODUCTテーブル
116 ORDER_CUSTOMERテーブル
118 CustomerField
120 CUSTOMER_CODEテーブル
122 CUSTOMER_NAMEテーブル
124 ProductField
126 PRODUCT_CODEテーブル
128 注文データ登録画面
130 CSVファイル
140 抽出データ指定画面
142 「次の列を選択」ボタン
144 「選択済みの列」の表示欄
146 「データの抽出」ボタン
150 抽出結果画面
152 注文データ
154 「ダウンロード」ボタン
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】