(57)【特許請求の範囲】
【請求項１】
ＥＲモデルを用いたデータベース設計システムであって、
キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キーデータに対応するデータ項目とに分類して仮エンティティを作成する仮エンティティ作成手段と、
前記仮エンティティに共通するキー定義データを有する仮エンティティが存在する場合には１つのエンティティに集約して、正規化エンティティを作成する正規化エンティティ作成手段と、
前記正規化エンティティのエンティティタイプを設定する設定手段と、
前記正規化エンティティ作成手段により作成された正規化エンティティと前記情報との対応関係を示す第１のマトリックステーブルを作成する第１のテーブル作成手段と、
前記第１のテーブル作成手段により作成された第１のマトリックステーブルを記憶する第１のテーブル記憶手段と、
前記第１のテーブル記憶手段に記憶された前記第１のマトリックステーブルと、予め設定されているエンティティタイプ間の関係、及び前記設定手段により設定された正規化エンティティのエンティティタイプに基づいて規定される正規化エンティティ間の関係とに基づいて、前記情報毎に、該情報に属する前記正規化エンティティ間の関係を示す第２のマトリックステーブルを作成する第２のテーブル作成手段と、
前記第２のテーブル作成手段により作成された第２のマトリックステーブルを記憶する第２のテーブル記憶手段と、
前記第２のテーブル記憶手段に記憶された前記情報毎の第２のマトリックステーブルに基づいて、ＥＲモデル図を作成するＥＲモデル図作成手段と、
を有することを特徴とするデータベース設計システム。
【請求項２】
キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を入力する入力手段を更に有する、
ことを特徴とする請求項１に記載のデータベース設計システム。
【請求項３】
前記ＥＲモデル図作成手段が、前記複数の情報のうちの少なくとも１つの前記情報に基づくＥＲモデル図、或いは２つ以上の前記情報の組み合わせに基づくＥＲモデル図を作成する、
ことを特徴とする請求項１又は請求項２に記載のデータベース設計システム。
【請求項４】
前記正規化エンティティ作成手段が、前記ＥＲモデル図作成手段により作成された複数のＥＲモデル図を統合するコマンドが入力されたときに、各ＥＲモデル作成時の正規化エンティティに共通するキー定義データを有する正規化エンティティが存在する場合には１つに集約する、
ことを特徴とする請求項１乃至請求項３の何れか１項に記載のデータベース設計システム。
【請求項５】
前記第１のマトリックステーブルにおける正規化エンティティと前記情報との対応関係、前記第２のマトリックステーブルにおける前記正規化エンティティ間の関係、前記正規化エンティティのエンティティタイプ、及び前記正規化エンティティを構成するキー定義データとデータ項目との対応関係のうちの少なくとも１つを変更する変更手段を更に有する、
ことを特徴とする請求項１乃至請求項４の何れか１項に記載のデータベース設計システム。
【請求項６】
前記変更手段が、
前記情報を削除するためのコマンドが入力されたときに、削除対象の情報に含まれる正規化エンティティが削除可能か否かを判断する第１の判断手段と、
前記第１の判断手段によって削除不能と判断されたときは前記情報を削除し、削除可能と判断されたときは前記情報及び前記正規化エンティティを削除する第１の削除手段と、を有し
前記第１の削除手段によって前記情報、又は前記情報及び前記正規化エンティティが削除されたときに、前記第１のマトリックステーブルの正規化エンティティと前記情報との対応関係を変更する、
ことを特徴とする請求項５に記載のデータベース設計システム。
【請求項７】
前記第１の判断手段は、削除対象の情報に対応する正規化エンティティが、該削除対象の情報のみに対応している場合に、該正規化エンティティが削除可能と判断する、
ことを特徴とする請求項６に記載のデータベース設計システム。
【請求項８】
前記正規化エンティティが対応している前記情報の数を記憶する第１の記憶手段を更に有し、
前記第１の判断手段は、前記情報を追加入力するためのコマンドが入力されたときは、追加対象の前記情報に対応する前記正規化エンティティの前記第１の記憶手段に記憶されている前記数をインクリメントし、
前記情報を削除するためのコマンドが入力されたときは、削除対象の前記情報に対応する前記正規化エンティティの前記第１の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、該正規化エンティティが削除可能と判断する、
ことを特徴とする請求項７に記載のデータベース設計システム。
【請求項９】
前記変更手段が、
前記情報における前記エンティティ間の関係を削除するためのコマンドが入力されたときに、前記第２のマトリックステーブルにおいて当該エンティティ間の関係を削除する第２の削除手段を有し、
前記ＥＲモデル図作成手段が、
前記第２の削除手段により削除されたエンティティ間の関係を示す接続線が前記ＥＲモデル図から削除可能か否かを判断する第２の判断手段と、
前記第２の判断手段によって削除可能と判断されたときに、前記ＥＲモデル図から該エンティティ間の関係を示す接続線を削除する第３の削除手段とを有する、
ことを特徴とする請求項５乃至請求項８の何れか１項に記載のデータベース設計システム。
【請求項１０】
前記第２の判断手段は、前記第２の削除手段により削除されたエンティティ間の関係が、前記削除されたエンティティ間の関係に関連する前記情報のみに存在する場合に、前記ＥＲモデル図における該エンティティ間の関係を示す接続線が削除可能と判断する、
ことを特徴とする請求項９に記載のデータベース設計システム。
【請求項１１】
前記エンティティ間の関係が属している前記情報の数を記憶する第２の記憶手段を更に有し、
前記第２の判断手段は、前記エンティティ間の関係を追加するためのコマンドが入力されたときは、追加対象のエンティティ間の関係に対応する前記第２の記憶手段に記憶されている前記数をインクリメントし、
前記エンティティ間の関係を削除するためのコマンドが入力されたときは、削除対象のエンティティ間の関係に対応する前記第２の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、前記ＥＲモデル図における該エンティティ間の関係を示す接続線が削除可能と判断する、
ことを特徴とする請求項１０に記載のデータベース設計システム。
【請求項１２】
前記変更手段が、
前記正規化エンティティのエンティティタイプの変更のコマンドが入力されたときに、当該正規化エンティティのエンティティタイプを変更するとともに、前記第１のマトリックステーブルを参照して前記情報の中から該正規化エンティティが対応する情報を検索し、エンティティタイプの変更に基づいて、検索された情報に属する前記正規化エンティティ間の関係を変更する、
ことを特徴とする請求項５乃至請求項１１の何れか１項に記載のデータベース設計システム。
【請求項１３】
前記変更手段が、
前記情報を削除するためのコマンドが入力されたときに、前記正規化エンティティを構成するキー定義データ及びデータ項目から、削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つを削除可能か否かを判断する第３の判断手段と、
前記第３の判断手段によって削除可能と判断されたときに、前記削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つを削除する第４の削除手段と、
を有することを特徴とする請求項５乃至請求項１２の何れか１項に記載のデータベース設計システム。
【請求項１４】
前記第３の判断手段は、前記削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つが、削除対象の情報のみに含まれている場合に、該キー定義データ及びデータ項目のうちの少なくとも１つが削除可能と判断する、
ことを特徴とする請求項１３に記載のデータベース設計システム。
【請求項１５】
同じキー定義データを含む前記情報の数、及び同じデータ項目を含む前記情報の数を記憶する第３の記憶手段を更に有し、
前記第３の判断手段は、前記情報を追加入力するためのコマンドが入力されたときは、追加対象の前記情報に含まれるキー定義データ及びデータ項目の前記第３の記憶手段に記憶されている前記数をインクリメントし、
前記情報を削除するためのコマンドが入力されたときは、削除対象の前記情報に含まれるキー定義データ及びデータ項目の前記第３の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、該キー定義データ又はデータ項目が削除可能と判断する、
ことを特徴とする請求項１４に記載のデータベース設計システム。
【請求項１６】
前記ＥＲモデル図作成手段は、前記変更手段による変更結果に基づいて、ＥＲモデル図を修正するとともに、修正個所を報知する、
ことを特徴とする請求項１乃至請求項１５の何れか１項に記載のデータベース設計システム。
【請求項１７】
前記仮エンティティ作成手段が、
作成した仮エンティティを登録してマスターファイルを作成するマスターファイル作成手段と、
前記マスターファイルを参照して、キー定義データと対応付けられていないデータ項目を検索する検索手段と、
前記検索結果を報知する検索結果報知手段と、
を有することを特徴とする請求項１乃至請求項１６の何れか１項に記載のデータベース設計システム。
【請求項１８】
前記仮エンティティ作成手段は、
作成済みの前記正規化エンティティを参照して、未分類の前記情報をキー定義データと該キーデータに関連するデータ項目とに分類して仮エンティティを作成する、
ことを特徴とする請求項５乃至請求項１７の何れか１項に記載のデータベース設計システム。
【請求項１９】
前記正規化エンティティ作成手段が、
作成済みの前記正規化エンティティとキー定義データが同一の仮エンティティを、該作成済みの正規化エンティティに集約し、
作成済みの前記正規化エンティティとキー定義データが異なる仮エンティティを新規の正規化エンティティとする、
ことを特徴とする請求項１８に記載のデータベース設計システム。
【請求項２０】
作成済みの前記正規化エンティティを参照して自動分類された仮エンティティ、又は該仮エンティティが集約された正規化エンティティを報知する自動分類報知手段を更に有する、
ことを特徴とする請求項１８又は請求項１９に記載のデータベース設計システム。
【請求項２１】
前記キー定義データとデータ項目の対応関係をマニュアル修正するマニュアル修正手段と、
前記マニュアル修正手段による修正履歴を報知する履歴報知手段とを更に有する、
ことを特徴とする請求項１乃至請求項２０の何れか１項に記載のデータベース設計システム。
【請求項２２】
前記情報内の前記キー定義データ、前記データ項目、及び前記正規化エンティティの少なくとも１つをマニュアルで追加及び削除の少なくとも一方を行うマニュアル追加・削除手段と、
前記マニュアル追加・削除による追加又は削除後に、前記情報と前記正規化エンティティとの整合性が保たれているか否かを判断する整合性判断手段と、
前記整合性判断手段により非整合が検出された場合に、当該非整合を報知する非整合報知手段と、を更に有する、
ことを特徴とする請求項１乃至請求項２１の何れか１項に記載のデータベース設計システム。
【請求項２３】
前記正規化エンティティの分割及び統合の少なくとも一方を行う分割統合手段を更に有する、
ことを特徴とする請求項１乃至請求項２２に記載のデータベース設計システム。
【請求項２４】
前記第１のマトリックステーブル作成手段が、前記第１のマトリックステーブルとともに、前記正規化エンティティ毎に、該正規化エンティティを構成するキー定義データ及びデータ項目の各々と前記情報との対応関係を示す第３のマトリックステーブルを作成する、
ことを特徴とする請求項１乃至請求項２３の何れか１項に記載のデータベース設計システム。
【請求項２５】
前記第２のテーブル作成手段が、前記正規化エンティティをヘッダ部分の正規化エンティティと、前記情報内での繰り返し項目を示すディテール部分の正規化エンティティとに分割し、ヘッダ部分の正規化エンティティ間の関係、ディテール部分の正規化エンティティ間の関係、及びヘッダ部分とディテール部分との関係を求めて、第２のマトリックステーブルを作成する、
ことを特徴とする請求項１乃至請求項２４の何れか１項に記載のデータベース設計システム。
【請求項２６】
前記情報、前記正規化エンティティ、前記第１のマトリックステーブル、前記第２のマトリックステーブル、及び前記ＥＲモデル図の少なくとも１つを表示する表示制御手段を更に有する、
ことを特徴とする請求項１乃至請求項２５の何れか１項に記載のデータベース設計システム。
【請求項２７】
前記表示制御手段が、前記情報及び前記正規化エンティティとともに、前記第１のマトリックステーブル作成手段、前記第２のマトリックステーブル作成手段、前記ＥＲモデル図作成手段の少なくとも１つにより作成された前記第１のマトリックステーブル、前記第２のマトリックステーブル、及び前記ＥＲモデル図の少なくとも１つを表示する、
ことを特徴とする請求項２６に記載のデータベース設計システム。
【請求項２８】
前記表示制御手段が、
前記情報毎に付与された識別番号の順に、又は予め定められたグループ毎に区分して、前記情報を配置し、前記情報の中から、前記正規化エンティティ作成手段が処理対象とする情報を指定し、前記正規化エンティティ作成手段が当該指定された前記情報を処理して、新規に作成された正規化エンティティを該情報に隣接配置する、
ことを特徴とする請求項２６又は請求項２７に記載のデータベース設計システム。
【請求項２９】
前記表示制御手段が、前記情報を表示する際に、前記情報毎に定められた１つの表示枠内に、前記情報に含まれる前記キー定義データと前記データ項目を表示するとともに、該情報のタイトルを該表示枠に隣接して表示する、
ことを特徴とする請求項２６乃至請求項２８の何れか１項に記載のデータベース設計システム。
【請求項３０】
前記情報が、画面、又は帳票、又は機能仕様書のデータである、
ことを特徴とする請求項１乃至請求項２９の何れか１項に記載のデータベース設計システム。
【請求項３１】
前記仮エンティティ作成手段が、各前記情報において、同一のキー定義データ又はデータ項目を１つに集約してから仮エンティティを作成する、
ことを特徴とする請求項１乃至請求項３０の何れか１項に記載のデータベース設計システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データベース設計システムに係り、特にＥＲモデル図の自動作成するデータベース設計システムに関する。
【０００２】
【従来の技術】
ＥＲ(Entity Relationship)モデルデータベース作成作業は、基本設計、詳細設計、ＥＲモデル図作成の各段階を経て行われる。
【０００３】
そして、入出力画面（以下、単に「画面」という）、帳票を中心とする正規化データベース設計では、ＤＡ（Data Administrator）やＳＥ（System Engineer）が設計を担当するが、画面・帳票数が１００〜２００以上になる場合もあり、これらを全て手作業の設計で行っているのが実状である。なお、ＥＲモデルデータベースの設計については、例えば「クライアント／サーバデータベース設計テクニック」（ＳＲＣハンドブック、佐藤正美著、１９９４年１０月２０日第４版発行）に詳細に記載されている。
【０００４】
このように、手作業でＥＲモデル図作成を行う場合、画面・帳票数の増大にともなって作業時間が著しく増大して生産性効率が低下してしまう、あるいは作成されるＥＲモデル図の質が個々の設計者の習熟度に依存してしまうという問題があった。
【０００５】
また、ＥＲモデル図を作成した後に追加画面や追加帳票が発生した場合でも、ＤＡやＳＥが手作業で追加処理をしなければならないが、設計方法が明示されていないため追加処理が困難となり、設計者毎に異なる設計が行われてしまう問題があった。
【０００６】
これらの問題を解決するために、本出願人により、ＲＤＢ（Relational Database）のデータベース正規化設計開発作業で、コンピュータを用いて自動的にデータベースの正規化設計を行ってＥＲモデル図を作成するシステムが提案されている。
【０００７】
詳しくは、このシステムでは、画面・帳票のデータをキー定義データとデータ項目に分類し、仮エンティティを作成する。各仮エンティティのキー定義データを検索し、重複するエンティティについては１つにまとめ、正規化し（正規化エンティティを作成し）、各正規化エンティティのタイプを指定する。また、正規化したエンティティと各画面・帳票との対応関係を示すテーブルを作成し、このテーブル及び予めメモリに記憶された各エンティティ間の関係に基づいてＥＲモデルを作成する。
【０００８】
このシステムにより、設計者に依存せず正確なデータベースの正規化設計を行うことができ、生産効率及び品質を上げることができる。
【０００９】
【発明が解決しようとする課題】
しかしながら、従来技術では、業務或いは組織毎に作成された複数のＥＲモデル図を統合したり（統合ＥＲモデル作成）、作成されたＥＲモデル図から業務或いは組織毎に分割（抽出）する（抽出ＥＲモデル作成）場合や、プログラム仕様書を作成するために画面・帳票毎にＥＲモデル図を作成する場合には、過去にＥＲモデル図を作成しているにも関わらず、データベースの正規化設計の全ステップを初めから実行し直さなければならず、作業効率が悪いという問題があった。
【００１０】
また、従来技術では、画面・帳票の追加・削除、及び内容修正等により、ＥＲモデル図作成のために、ＥＲモデル図の作成過程で作成された各種情報を変更する必要が生じた場合、該情報の作成処理を初めから実行しなおさなければならず、作業効率が悪いという問題があった。
【００１１】
また、画面・帳票を削除する場合は、ユーザが削除する画面・帳票に使用しているエンティティの中から該画面・帳票のみに使用されているエンティティを指定し、この指定されたエンティティ及び該エンティティのリレーションシップを削除することによりＥＲモデル図を作成し直すようになっており、ユーザによって誤って他の画面にも使用されているエンティティを削除するように指定された場合、正確なデータベースの正規化設計が行えない、という問題もあった。
【００１２】
また、従来技術は、画面・帳票を処理対象としており、業務で頻繁に使われている機能仕様書（データ項目間の演算により他のデータ項目を定義するもの）に対応していなかった。さらに、従来技術では、ＥＲモデル作成過程において各種データを有効に表示することができず、ユーザフレンドリー性に欠けていた。
【００１３】
本発明は、上記問題点を解消するためになされたもので、画面・帳票とともに機能仕様書にも対応してＲＤＢの正規化設計作業を行うことができ、また、データベース正規化設計作業後の作成済みＥＲモデル図の統合・抽出、処理対象画面・帳票・機能仕様書の追加、削除を効率的且つ正確に行い、生産効率及び品質を上げることができるデータベース設計システムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するために請求項１に記載の発明は、ＥＲモデルを用いたデータベース設計システムであって、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キーデータに対応するデータ項目とに分類して仮エンティティを作成する仮エンティティ作成手段と、  前記仮エンティティに共通するキー定義データを有する仮エンティティが存在する場合には１つのエンティティに集約して、正規化エンティティを作成する正規化エンティティ作成手段と、前記正規化エンティティのエンティティタイプを設定する設定手段と、前記正規化エンティティ作成手段により作成された正規化エンティティと前記情報との対応関係を示す第１のマトリックステーブルを作成する第１のテーブル作成手段と、前記第１のテーブル作成手段により作成された第１のマトリックステーブルを記憶する第１のテーブル記憶手段と、前記第１のテーブル記憶手段に記憶された前記第１のマトリックステーブルと、予め設定されているエンティティタイプ間の関係、及び前記設定手段により設定された正規化エンティティのエンティティタイプに基づいて規定される正規化エンティティ間の関係とに基づいて、前記情報毎に、該情報に属する前記正規化エンティティ間の関係を示す第２のマトリックステーブルを作成する第２のテーブル作成手段と、前記第２のテーブル作成手段により作成された第２のマトリックステーブルを記憶する第２のテーブル記憶手段と、前記第２のテーブル記憶手段に記憶された前記情報毎の第２のマトリックステーブルに基づいて、ＥＲモデル図を作成するＥＲモデル図作成手段と、を有することを特徴としている。
【００１５】
請求項１に記載の発明によれば、仮エンティティ作成手段では、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キー定義データに対応するデータ項目とに分類することによって仮エンティティが作成される。
【００１６】
なお、請求項２に記載されているように、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を入力する入力手段を更に有するにし、入力手段によって、直接、又はネットワーク等を介して、データベース設計システムに情報が入力されるようにしてもよい。また、この情報は、請求項３０に記載されているように、画面、又は帳票、又は機能仕様書のデータとするとよい。また、例えば機能仕様書のように、同一の情報内に同一のキー定義データやデータ項目が複数含まれる場合は、請求項３１に記載されているように、仮エンティティ作成手段は、各前記情報において、同一のキー定義データ又はデータ項目を１つに集約して（重複を排除する）から仮エンティティを作成するようにするとよい。
【００１７】
正規化エンティティ作成手段では、作成された仮エンティティのうち、共通するキー定義データを有する仮エンティティが存在する場合には、それらを１つのエンティティに集約する処理（所謂正規化処理）を行って、正規化エンティティを作成し、設定手段によって、作成された正規化エンティティに対してエンティティタイプが設定される。
【００１８】
また、第１のテーブル作成手段では、正規化エンティティ作成手段によって作成された正規化エンティティと情報との対応関係を示す第１のマトリックステーブルが作成される。この第１のマトリックステーブルにより、各正規化エンエンティティが何れの情報に対応している（属している）のか、言換えると、各正規化エンティティが何れの情報に属していた仮エンティティを集約したものかを把握することができる。また、各画面に、何れの正規化エンティティが属しているのかを把握することもできる。
【００１９】
第２のテーブル作成手段では、この第１のマトリックステーブルと、エンティティタイプによるエンティティ間の関係（リレーションシップ）を予め定めたテーブルとに基づいて、情報毎に、正規化エンティティ間の関係を示す第２のマトリックステーブルが作成される。ＥＲモデル図作成手段は、この第２のマトリックステーブルに基づいて、ＥＲモデル図を作成する。これにより、所謂データベースの正規化設計を行い、正規化エンティティ間の関係を作成し、ＥＲモデル図を作成することができる。
【００２０】
このとき、第２のマトリックステーブルが、情報毎に作成されるので、ＥＲモデル図作成手段では、請求項３に記載されているように、前記複数の情報のうちの少なくとも１つの前記情報に基づくＥＲモデル図、或いは２つ以上の前記情報の組み合わせに基づくＥＲモデル図を容易に作成することができる。すなわち、全情報に基づくＥＲモデル図を作成することもできるし、情報毎にＥＲモデル図（部分ＥＲモデル図）を作成することもできるし、全情報のうちの任意の情報の組み合わせに基づくＥＲモデル図（抽出ＥＲモデル図）を作成することもできる。
【００２１】
また、請求項４に記載の発明は、請求項１乃至請求項３の何れか１項に記載の発明において、前記正規化エンティティ作成手段が、前記ＥＲモデル図作成手段により作成された複数のＥＲモデル図を統合するコマンドが入力されたときに、各ＥＲモデル作成時の正規化エンティティに共通するキー定義データを有する正規化エンティティが存在する場合には１つに集約する、ことを特徴としている。
【００２２】
請求項４に記載の発明によれば、ＥＲモデル図作成手段により作成された複数のＥＲモデル図を統合する場合に、正規化エンティティ作成手段によって、作成済みの複数のＥＲモデル図の正規化エンティティの中で共通のキー定義データを有する正規化エンティティが１つに集約される。すなわち、正規化エンティティ作成手段では、互いに異なるＥＲモデル図を作成した際の正規化エンティティを対象として正規化処理が行われ、正規化エンティティの重複が排除される。この結果に基づいて、第１のテーブル作成手段によって、第１のマトリックステーブルが作成され、作成された第１のマトリックステーブルに基づいて第２のテーブル作成手段によって第２のマトリックステーブルが作成される。ＥＲモデル図作成手段は、この第２のマトリックステーブルに基づいてＥＲモデル図を作成することにより、複数のＥＲモデル図を統合した統合ＥＲモデル図を作成することができる。
【００２３】
請求項５に記載の発明は、請求項１乃至請求項４の何れか１項に記載の発明において、前記第１のマトリックステーブルにおける正規化エンティティと前記情報との対応関係、前記第２のマトリックステーブルにおける前記正規化エンティティ間の関係、前記正規化エンティティのエンティティタイプ、及び前記正規化エンティティを構成するキー定義データとデータ項目との対応関係のうちの少なくとも１つを変更する変更手段を更に有する、ことを特徴としている。
【００２４】
請求項５に記載の発明によれば、変更手段によって、第１のマトリックステーブルにおける正規化エンティティと情報との対応関係、第２のマトリックステーブルにおける正規化エンティティ間の関係、正規化エンティティのエンティティタイプ、及び正規化エンティティを構成するキー定義データとデータ項目との対応関係の少なくとも１つを変更する。これにより、情報の追加、情報の削除、及び内容変更等に対応することができる。
【００２５】
例えば、変更手段によって、情報の追加、情報の削除、情報の内容変更等に基づいて、正規化エンティティと情報との対応関係（すなわち第１のテーブル作成手段により作成された第１のマトリックステーブル）を変更することができる。
【００２６】
また、変更手段によって、情報の追加、情報の削除、情報の内容変更、正規化エンティティのエンティティタイプの変更等に基づいて、正規化エンティティ間の関係（すなわち、第２のテーブル作成手段により作成された第２のマトリックステーブル）を変更することができる。
【００２７】
また、変更手段によって、正規化エンティティのエンティティタイプを変更することにより、設定手段により間違ったエンティティタイプを設定してしまった場合に、正しいエンティティタイプに容易に変更することができる。
【００２８】
また、変更手段によって、情報の追加、情報の削除、情報の内容変更等に基づいて、正規化エンティティを構成しているキー定義データとデータ項目との対応関係を変更することができる。
【００２９】
請求項６に記載の発明は、請求項５に記載の発明において、前記変更手段が、前記情報を削除するためのコマンドが入力されたときに、削除対象の情報に対応する正規化エンティティが削除可能か否かを判断する第１の判断手段と、前記第１の判断手段によって削除不能と判断されたときは前記情報を削除し、削除可能と判断されたときは前記情報及び前記正規化エンティティを削除する第１の削除手段と、を有し前記第１の削除手段によって前記情報、又は前記情報及び前記正規化エンティティが削除されたときに、前記第１のマトリックステーブルの正規化エンティティと前記情報との対応関係を変更する、ことを特徴としている。
【００３０】
請求項６に記載の発明によれば、変更手段は、第１の判断手段と、第１の削除手段とを備えている。変更手段では情報を削除するためのコマンドが入力されたときに、第１の判断手段によって、削除対象の情報（削除コマンドによって削除するように指示された情報）に対応する正規化エンティティを削除可能か否かを判断する。なお、削除対象の情報に対応する正規化エンティティは、第１のマトリックステーブルから抽出することができる。第１の削除手段では、正規化エンティティが削除不能な場合は削除対象の情報のみを削除し、削除可能な場合は削除対象の情報とともに正規化エンティティも削除する。変更手段は、この削除結果に基づいて、第１のマトリックステーブルの正規化エンティティと情報との対応関係を変更することにより、情報の削除に応じて、容易且つ効率的に第１のマトリックステーブルを変更（修正）することができる。
【００３１】
このとき、請求項７に記載されているように、前記第１の判断手段が、削除対象の情報に対応する正規化エンティティが、該削除対象の情報のみに対応している場合に、該正規化エンティティの情報を削除可能と判断するようにするとよい。これにより、第１のマトリックステーブルから削除対象の情報とともに、削除対象の情報のみに対応している正規化エンティティを削除することができる。
【００３２】
例えば、請求項８に記載されているように、前記正規化エンティティが対応している前記情報の数を記憶する第１の記憶手段を更に有し、前記第１の判断手段は、前記情報を追加入力するためのコマンドが入力されたときは、追加対象の前記情報に対応する前記正規化エンティティの前記第１の記憶手段に記憶されている前記数をインクリメントし、前記情報を削除するためのコマンドが入力されたときは、削除対象の前記情報に対応する前記正規化エンティティの前記第１の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、該正規化エンティティが削除可能と判断するようにするとよい。
【００３３】
すなわち、第１の記憶手段には、各正規化エンティティが対応している（利用されている）情報の数（以下、「利用数」という）が記憶されており、この利用数は、第１の判断手段によって、情報の追加又は削除に応じて、インクリメント又はデクリメントされ、常に最新の値に更新される。従って、第１の判断手段は、情報の削除に応じて、当該削除情報に対応する正規化エンティティの利用数をデクリメントした結果、その値が０になった場合に、当該正規化エンティティが、削除対象の情報のみに対応しているとして、該正規化エンティティが削除可能と判断することができる。
【００３４】
請求項９に記載の発明は、請求項５乃至請求項８の何れか１項に記載の発明において、前記変更手段が、前記情報における前記エンティティ間の関係を削除するコマンドが入力されたときに、前記第２のマトリックステーブルにおいて当該エンティティ間の関係を削除する第２の削除手段を有し、前記ＥＲモデル図作成手段が、前記第２の削除手段により削除されたエンティティ間の関係を示す接続線が前記ＥＲモデル図から削除可能か否かを判断する第２の判断手段と、前記第２の判断手段によって削除可能と判断されたときに、前記ＥＲモデル図から該エンティティ間の関係を示す接続線を削除する第３の削除手段とを有する、ことを特徴としている。
【００３５】
請求項９に記載の発明によれば、変更手段では、情報の削除や内容変更によって正規化エンティティを削除する必要がある場合や、不必要な正規化エンティティ間の関係が存在する場合等に、エンティティ間の関係を削除するようにコマンドが入力されたときに、第２の削除手段によって、第２のマトリックステーブルから当該正規化エンティティ間の関係を削除する。
【００３６】
ＥＲモデル図作成手段では、第２の削除手段による正規化エンティティ間の関係の削除を受けて、第２の判断手段によって、ＥＲモデル図から当該エンティティ間の接続線が削除可能か否かを判断し、削除可能と判断された場合には、第３の削除手段によって、当該エンティティ間の接続線をＥＲモデル図から削除する。これにより、情報の削除や内容変更、不必要な正規化エンティティ間の関係削除に応じて、容易且つ効率的に、第２のマトリックステーブルを変更（修正）して、ＥＲモデル図を変更（修正）することができる。
【００３７】
このとき、請求項１０に記載されているように、前記第２の判断手段は、前記第２の削除手段により削除されたエンティティ間の関係が、前記削除されたエンティティ間の関係に関連する前記情報のみに存在する場合に、前記ＥＲモデル図における該エンティティ間の関係を示す接続線を削除可能と判断するようにするとよい。
【００３８】
これにより、１つの情報のみに存在する正規化エンティティ間の関係が削除された場合にのみ、ＥＲモデル図から該正規化エンティティ間の関係を示す接続線を削除し、削除されたエンティティ間の関係が他の情報にも存在する場合には、ＥＲモデル図上の該正規化エンティティ間の関係を示す接続線を残すことができる。
【００３９】
例えば、請求項１１に記載されているように、前記エンティティ間の関係が属している前記情報の数を記憶する第２の記憶手段を更に有し、前記第２の判断手段は、前記エンティティ間の関係を追加するためのコマンドが入力されたときは、追加対象のエンティティ間の関係に対応する前記第２の記憶手段に記憶されている前記数をインクリメントし、前記エンティティ間の関係を削除するためのコマンドが入力されたときは、削除対象のエンティティ間の関係に対応する前記第２の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、前記ＥＲモデル図における該エンティティ間の関係を示す接続線が削除可能と判断するようにするとよい。
【００４０】
すなわち、第２の記憶手段には、各エンティティ間の関係が属している情報の数（以下、「リレーションシップ数」という）がそれぞれ記憶されており、このリレーションシップ数は、第２の判断手段によって、エンティティ間の関係の追加又は削除に応じて、インクリメント又はデクリメントされ、常に最新の値に更新される。従って、第２の判断手段は、エンティティ間の関係の削除に応じて、当該エンティティ間の関係のリレーションシップ数をデクリメントした結果、その値が０になった場合に、当該エンティティ間の関係が、削除対象のエンティティ間の関係に関連する前記情報のみに存在するとして、ＥＲモデル図における該エンティティ間の関係を示す接続線が削除可能と判断することができる。
【００４１】
請求項１２に記載の発明は、請求項５及び請求項１１に記載の発明において、前記変更手段が、前記正規化エンティティのエンティティタイプの変更のコマンドが入力されたときに、当該正規化エンティティのエンティティタイプを変更するとともに、前記第１のマトリックステーブルを参照して前記情報の中から該正規化エンティティが対応する情報を検索し、エンティティタイプの変更に基づいて、検索された情報に属する前記正規化エンティティ間の関係を変更する、ことを特徴としている。
【００４２】
請求項１２に記載の発明によれば、変更手段は、正規化エンティティのエンティティタイプを変更する際に、第１のマトリックステーブルを参照して、情報の中から該正規化エンティティが対応する情報を検索し、検索された情報に属する正規化エンティティ間の関係も変更する。これにより、エンティティタイプの変更による正規化エンティティ間の関係を正確に変更することができるとともに、正規化エンティティ間の関係の変更忘れを防止することができる。
【００４３】
請求項１３に記載の発明は、請求項５乃至請求項１２の何れか１項に記載の発明において、前記変更手段が、前記情報を削除するためのコマンドが入力されたときに、前記正規化エンティティを構成するキー定義データ及びデータ項目から、削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つを削除可能か否かを判断する第３の判断手段と、前記第３の判断手段によって削除可能と判断されたときに、前記削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つを削除する第４の削除手段と、を有することを特徴としている。
【００４４】
請求項１３に記載の発明によれば、変更手段は、第３の判断手段と、第４の削除手段とを備えている。変更手段では情報を削除するためのコマンドが入力されたときに、第３の判断手段によって、削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つを削除可能か否かを判断する。第３の判断手段によって削除可能と判断されたキー定義データやデータ項目は、第４の削除手段によって、正規化エンティティを構成するキー定義データ及びデータ項目の中から削除される。これにより、情報の削除に応じて、容易且つ効率的に正規化エンティティを構成しているキー定義データとデータ項目との対応関係を変更（修正）することができる。
【００４５】
このとき、請求項１４に記載されているように、前記第３の判断手段は、前記削除対象の情報に含まれるキー定義データ及びデータ項目のうちの少なくとも１つが、削除対象の情報のみに含まれている場合に、該キー定義データ及びデータ項目のうちの少なくとも１つが削除可能と判断するとよい。これにより、削除対象の情報のみに含まれているキー定義データやデータ項目のみを、正規化エンティティを構成しているキー定義データ及びデータ項目の中から削除することができる。
【００４６】
例えば、請求項１５に記載されているように、同じキー定義データを含む前記情報の数、及び同じデータ項目を含む前記情報の数を記憶する第３の記憶手段を更に有し、前記第３の判断手段は、前記情報を追加入力するためのコマンドが入力されたときは、追加対象の前記情報に含まれるキー定義データ及びデータ項目の前記第３の記憶手段に記憶されている前記数をインクリメントし、前記情報を削除するためのコマンドが入力されたときは、削除対象の前記情報に含まれるキー定義データ及びデータ項目の前記第３の記憶手段に記憶されている前記数をデクリメントし、前記数が０になった場合に、該キー定義データ又はデータ項目が削除可能と判断するようにするとよい。
【００４７】
すなわち、第３の記憶手段には、同じキー定義データを含む情報の数と、同じデータ項目を含む前記情報の数（すなわち各キー定義データの利用数と、各データ項目の利用数）が記憶されており、この利用数は、第３の判断手段によって、情報の追加又は削除に応じて、インクリメント又はデクリメントされ、常に最新の値に更新される。従って、第３の判断手段は、情報の削除に応じて、当該削除情報に含まれるキー定義データ及びデータ項目の利用数をデクリメントした結果、その値が０になったキー定義データやデータ項目を削除対象の情報のみに対応しているとして、削除可能と判断することができる。
【００４８】
請求項１６に記載の発明は、請求項５乃至請求項１５の何れか１項に記載の発明において、前記ＥＲモデル図作成手段は、前記変更手段による変更結果に基づいて、ＥＲモデル図を修正するとともに、修正個所を報知する、ことを特徴としている。
【００４９】
請求項１５に記載の発明によれば、ＥＲモデル図作成手段によって、変更手段による変更結果に基づいて、変更前に作成されたＥＲモデル図が修正され、その修正個所が報知されるので、ユーザは修正個所を容易に把握することができる。
特に、ＤＢＭＳ（Data Base Management System）を実際に構築するためのプログラム仕様書として用いられる部分ＥＲモデル図の場合、ユーザは、報知された修正個所から、プログラムの修正すべき個所やその修正内容を容易に把握することができ、プログラムの修正作業に係る時間を短縮することができる。
【００５０】
請求項１７に記載の発明は、請求項１乃至請求項１６の何れか１項に記載の発明において、前記仮エンティティ作成手段が、作成した仮エンティティのキー定義データと該キー定義データと対応するデータ項目とを登録してマスターファイルを作成するマスターファイル作成手段と、前記マスターファイルを参照して、前記マスターファイルにキー定義データとともに登録されているデータ項目と同一でありながら、キー定義データと対応付けられていないデータ項目を検索する検索手段と、前記検索結果を報知する検索結果報知手段と、を有することを特徴としている。
【００５１】
請求項１７に記載の発明によれば、仮エンティティ作成手段には、マスターファイル作成手段と、検索手段と、報知手段が備えられている。
【００５２】
仮エンティティ作成手段では、キー定義データと該キー定義データに対応するデータ項目とに分類して仮エンティティを作成するとともに、マスターファイル作成手段によって、作成した仮エンティティのキー定義データと該キー定義データと対応するデータ項目とをマスターファイルに登録する。
【００５３】
また、検索手段によって、マスターファイルにキー定義データとともに登録されているデータ項目と同一でありながら、キー定義データと対応付けられていないデータ項目を検索する。報知手段によって検索されたデータ項目は報知される。ユーザは、報知されたデータ項目を分類し忘れた（間違えた）データ項目と判断して、分類し直すことができるので、正確に仮エンティティを作成することができる。
【００５４】
請求項１８に記載の発明は、請求項１乃至請求項１７の何れか１項に記載の発明において、前記仮エンティティ作成手段が、作成済みの前記正規化エンティティを参照して、未分類の前記情報をキー定義データと該キーデータに関連するデータ項目とに分類して仮エンティティを作成する、ことを特徴としている。
【００５５】
請求項１８に記載の発明によれば、仮エンティティ作成手段では、既に作成済みの正規化エンティティを参照して、未分類の情報をキー定義データとデータ項目とに分類して仮エンティティを作成する。なお、未分類の情報には、正規化エンティティ作成手段により正規化エンティティを作成した後で、新規に追加された情報や、大量の情報を処理する際に、先に一部の情報について正規化エンティティの作成の処理までを行った後の残りの情報等が挙げられる。これにより、情報の追加に係る処理時間や、大量の情報を処理する場合に係る処理時間を短縮できる。
【００５６】
請求項１９に記載の発明は、請求項１８に記載の発明において、前記正規化エンティティ作成手段が、作成済みの前記正規化エンティティとキー定義データが同一の仮エンティティを該作成済みの正規化エンティティに集約し、作成済みの前記正規化エンティティとキー定義データが異なる仮エンティティを新規の正規化エンティティとする、ことを特徴としている。
【００５７】
請求項１９に記載の発明によれば、正規化エンティティ作成手段では、情報が追加された場合や、大量の情報を処理する際に、一部の情報の処理を先に行った後、残りの情報の処理を行う場合等には、追加された情報や残りの情報から新たに作成された仮エンティティのキー定義データと、作成済みの正規化エンティティのキー定義データとを比較して、キー定義データが同一の場合には、仮エンティティを作成済みの正規化エンティティに集約し、キー定義データが異なる場合にのみ、仮エンティティを新規の正規化エンティティとする。これにより、情報の追加に係る処理時間を短縮できる。
【００５８】
この場合、請求項２０に記載されているように、作成済みの前記正規化エンティティを参照して自動分類された仮エンティティ、又は該仮エンティティが集約された正規化エンティティを報知する自動分類報知手段を更に有するようにするとよい。
【００５９】
請求項２１に記載の発明は、請求項１乃至請求項２０の何れか１項に記載の発明において、前記キー定義データとデータ項目の対応関係をマニュアル修正するマニュアル修正手段と、前記マニュアル修正手段による修正履歴を報知する履歴報知手段とを更に有する、ことを特徴としている。
【００６０】
請求項２１に記載の発明によれば、マニュアル修正手段により、キー定義データとデータ項目の対応関係をマニュアル修正できる。また履歴報知手段により、この修正履歴が報知されるので、ユーザは修正個所を容易に把握することができる。
【００６１】
請求項２２に記載の発明は、請求項１乃至請求項２１の何れか１項に記載の発明において、前記情報内の前記キー定義データ、前記データ項目、及び前記正規化エンティティの少なくとも１つをマニュアルで追加及び削除の少なくとも一方を行うマニュアル追加・削除手段と、前記マニュアル追加・削除による追加又は削除後に、前記情報と前記正規化エンティティとの整合性が保たれているか否かを判断する整合性判断手段と、前記整合性判断手段により非整合が検出された場合に、当該非整合を報知する非整合報知手段と、を更に有する、ことを特徴としている。
【００６２】
請求項２２に記載の発明によれば、マニュアル追加・削除手段では、情報内にキー定義データやデータ項目をマニュアルで追加／削除できる。また、マニュアル追加・削除手段では、正規化エンティティをマニュアルで追加／削除できる。
このマニュアル追加・削除手段による追加／削除後は、整合性判断手段によって、該追加／削除後の情報と正規化エンティティとで整合性が保たれているかが判断され、非整合がある場合には非整合報知手段により報知される。これにより、ユーザは非整合を容易に把握でき、該非整合を無くすように、マニュアル追加・削除手段による追加・削除を行って、整合を図ることができる。
【００６３】
請求項２３に記載の発明は、請求項１乃至請求項２２に記載の発明において、前記正規化エンティティの分割及び統合の少なくとも一方を行う分割統合手段を更に有する、ことを特徴としている。
【００６４】
請求項２３に記載の発明によれば、分割統合手段により、正規化エンティティの分割／統合することができ、実際にDBMSを構築して運用する際の、データベースへのアクセス時間の短縮化を図ることができる。
【００６５】
請求項２４に記載の発明は、請求項１乃至請求項２３の何れか１項に記載の発明において、前記第１のマトリックステーブル作成手段が、前記第１のマトリックステーブルとともに、前記正規化エンティティ毎に、該正規化エンティティを構成するキー定義データ及びデータ項目の各々と前記情報との対応関係を示す第３のマトリックステーブルを作成する、ことを特徴としている。
【００６６】
請求項２４に記載の発明によれば、第１のテーブル作成手段では、正規化エンティティ毎に、該正規化エンティティを構成するキー定義データ及びデータ項目の各々と、前記情報との対応関係を示す第３のマトリックステーブルも作成される。この第３のマトリックステーブルにより、各エンティティを構成しているキー定義データやデータ項目の各々について、何れの情報に対応している（属している）のかを把握することができる。これにより、所謂データライフサイクル分析が容易になる。
【００６７】
請求項２５に記載の発明は、請求項１乃至請求項２４の何れか１項に記載の発明において、前記第２のテーブル作成手段が、前記正規化エンティティをヘッダ部分の正規化エンティティと、前記情報内での繰り返し項目を示すディテール部分の正規化エンティティとに分割し、ヘッダ部分の正規化エンティティ間の関係、ディテール部分の正規化エンティティ間の関係、及びヘッダ部分とディテール部分との関係を求めて、第２のマトリックステーブルを作成する、ことを特徴としている。
【００６８】
請求項２５に記載の発明によれば、正規化エンティティをヘッダ部分の正規化エンティティとディテール部分の正規化エンティティとに分割して、ヘッダ部分の正規化エンティティ間の関係、ディテール部分の正規化エンティティ間の関係、ヘッダ部分とディテール部分との関係を求めて、第２のマトリックステーブルを作成する。すなわち、ヘッダ部分の各正規化エンティティとディテール部分の各正規化エンティティとの間の関係を省略することができるので、第２のマトリックステーブル作成に係る処理時間を短縮することができる。
【００６９】
請求項２６に記載の発明は、請求項１乃至請求項２５の何れか１項に記載の発明において、前記情報、前記正規化エンティティ、前記第１のマトリックステーブル、前記第２のマトリックステーブル、及び前記ＥＲモデル図の少なくとも１つを表示する表示制御手段を更に有する、ことを特徴としている。
【００７０】
請求項２６に記載の発明によれば、表示制御手段によって、情報、正規化エンティティ、第１のマトリックステーブル、第２のマトリックステーブル、及びＥＲモデル図の少なくとも１つを表示することができ、ユーザが確認することができる。
【００７１】
例えば、請求項２７に記載されているように、前記表示制御手段が、前記情報及び前記正規化エンティティとともに、前記第１のマトリックステーブル作成手段、前記第２のマトリックステーブル作成手段、前記ＥＲモデル図作成手段の少なくとも１つにより作成された前記第１のマトリックステーブル、前記第２のマトリックステーブル、及び前記ＥＲモデル図の少なくとも１つを表示するとよい。これにより、第１のマトリックステーブル、第２のマトリックステーブル、ＥＲモデル図の作成結果が適切であるかを容易に確認することができる。
【００７２】
また、例えば、請求項２８に記載されているように、前記表示制御手段が、前記情報毎に付与された識別番号の順に、又は予め定められたグループ毎に区分して、前記情報を配置し、前記情報の中から、前記正規化エンティティ作成手段が処理対象とする情報を指定し、前記正規化エンティティ作成手段が、当該指定された前記情報を処理して、新規に作成された正規化エンティティを該情報に隣接配置する、ようにしてもよい。
【００７３】
なお、請求項２９に記載されているように、前記表示制御手段が、前記情報を表示する際に、前記情報毎に定められた１つの表示枠内に、前記情報に含まれる前記キー定義データと前記データ項目を表示するとともに、該情報のタイトルを該表示枠に隣接して表示するとよい。
【００７４】
請求項３２に記載の発明は、ＥＲモデルを用いたデータベース設計方法であって、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キーデータに対応するデータ項目とに分類して仮エンティティを作成し、前記仮エンティティに共通するキー定義データを有する仮エンティティが存在する場合には１つのエンティティに集約して、正規化エンティティを作成し、前記正規化エンティティのエンティティタイプを設定し、
前記正規化エンティティと前記情報との対応関係を示す第１のマトリックステーブルを作成し、前記第１のマトリックステーブルと、予め設定された前記エンティティタイプに基づく正規化エンティティ間の関係とに基づいて、前記情報毎に、該情報に属する前記正規化エンティティ間の関係を示す第２のマトリックステーブルを作成し、前記情報毎に作成された前記第２のマトリックステーブルに基づいて、ＥＲモデル図を作成する、ことを特徴としている。
【００７５】
請求項３２に記載の発明によれば、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キー定義データに対応するデータ項目とに分類することによって仮エンティティが作成される。作成された仮エンティティのうち、共通するキー定義データを有する仮エンティティが存在する場合にはそれらを１つのエンティティに集約する処理（所謂正規化処理）を行って、正規化エンティティを作成し、作成した正規化エンティティのエンティティタイプを設定する。また、作成した正規化エンティティと情報との対応関係を示す第１のマトリックステーブルを作成し、この第１のマトリックステーブルと、エンティティタイプによるエンティティ間の関係を予め定めたテーブルとに基づいて、作成された正規化エンティティ間の関係を示す第２のマトリックステーブルが作成される。この第２のマトリックステーブルに基づいて、ＥＲモデル図を作成する。これにより、データベースを正規化設計して、ＥＲモデル図を作成することができる。
【００７６】
また、情報毎に第２のマトリックステーブルを作成することにより、複数の情報のうちの少なくとも１つの情報に基づくＥＲモデル図、或いは２つ以上の情報の組み合わせに基づくＥＲモデル図を容易に作成することができる。
【００７７】
なお、請求項１と同様に、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報は、直接、又はネットワーク等を介して、入力されるようにするとよい。また、この情報は、画面、又は帳票、又は機能仕様書とするとよい。
【００７８】
また、請求項３３に記載されているように、前記第１のマトリックステーブルにおける正規化エンティティと前記情報との対応関係、前記第２のマトリックステーブルにおける前記正規化エンティティ間の関係、前記正規化エンティティのエンティティタイプ、及び前記正規化エンティティを構成するキー定義データとデータ項目との対応関係のうちの少なくとも１つを変更可能とするとよい。これにより、情報の追加、情報の削除、及び内容変更等に対応することができる。
【００７９】
請求項３４に記載の発明は、ＥＲモデルを用いたデータベースを設計するためのデータベース設計プログラムを記録したコンピュータ読取可能な記録媒体であって、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キーデータに対応するデータ項目とに分類して仮エンティティを作成し、前記仮エンティティに共通するキー定義データを有する仮エンティティが存在する場合には１つのエンティティに集約して、正規化エンティティを作成し、前記正規化エンティティのエンティティタイプを設定し、前記正規化エンティティと前記情報との対応関係を示す第１のマトリックステーブルを作成し、前記第１のマトリックステーブルと、予め設定された前記エンティティタイプに基づく正規化エンティティ間の関係とに基づいて、前記情報毎に、該情報に属する前記正規化エンティティ間の関係を示す第２のマトリックステーブルを作成し、前記情報毎に作成された前記第２のマトリックステーブルに基づいて、ＥＲモデル図を作成するデータベース設計プログラム記録していることを特徴としている。
【００８０】
請求項３４に記載の発明によれば、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報を、キー定義データと該キー定義データに対応するデータ項目とに分類することによって仮エンティティを作成する。作成された仮エンティティのうち、共通するキー定義データを有する仮エンティティが存在する場合にはそれらを１つのエンティティに集約する処理（所謂正規化処理）を行って、正規化エンティティを作成し、作成した正規化エンティティのエンティティタイプを設定し、作成した正規化エンティティと情報との対応関係を示す第１のマトリックステーブルを作成し、この第１のマトリックステーブルと、エンティティタイプによるエンティティ間の関係を予め定めたテーブルとに基づいて、作成された正規化エンティティ間の関係を示す第２のマトリックステーブルを作成し、この第２のマトリックステーブルに基づいて、ＥＲモデル図を作成するデータベース設計プログラムがコンピュータ読取可能な記録媒体に記録されている。したがって、コンピュータにこのデータベース設計プログラムに従ってデータベースを設計させることができる。
【００８１】
また、情報毎に第２のマトリックステーブルが作成されるので、コンピュータでは、複数の情報の少なくとも１つの前記情報に基づくＥＲモデル図、或いは２つ以上の情報の組み合わせに基づくＥＲモデル図を容易に作成することができる。
【００８２】
なお、請求項１と同様に、キー定義データと該キー定義データに対応するデータ項目とを含む複数の情報は、直接、又はネットワーク等を介して、入力されるようにするとよい。また、この情報は、画面、又は帳票、又は機能仕様書とするとよい。
【００８３】
また、請求項３５に記載されているように、前記データベース設計プログラムにおいて、前記第１のマトリックステーブルにおける正規化エンティティと前記情報との対応関係、前記第２のマトリックステーブルにおける前記正規化エンティティ間の関係、前記正規化エンティティのエンティティタイプ、及び前記正規化エンティティを構成するキー定義データとデータ項目との対応関係のうちの少なくとも１つを変更可能とするとよい。これにより、情報の追加、情報の削除、及び内容変更等に対応することができる。
【００８４】
請求項３６に記載の発明は、キー定義データと該キー定義データに対応するデータ項目とを含む情報に基づいてＥＲモデルを作成する際の表示方法であって、前記情報毎に定められた１つの表示枠内に、前記情報を表示すると共に、該情報のタイトルを該表示枠に隣接して表示する、ことを特徴としている。
【００８５】
請求項３６に記載の発明によれば、情報毎に表示枠が設けられて、各情報のキー定義データと該キー定義データに対応するデータ項目が、該情報に対応する表示枠内に表示され、該情報のタイトルが該表示枠に隣接して表示される。これにより、情報毎に、該情報に含まれているキー定義データやデータ項目を容易に確認することができる。
【００８６】
例えば、請求項３７に記載されているように、前記表示枠内に、前記キー定義データと前記データ項目をエンティティ毎に区分して表示するとよい（１コラム方式）。
【００８７】
また、請求項３８に記載されているように、前記表示枠内をキー定義データ表示用コラムとデータ項目表示用コラムとに分けて、前記キー定義データ表示用コラム及び前記データ項目表示用コラムに、前記キー定義データ及び前記データ項目をエンティティ毎に区分して表示するようにするとよい（２コラム方式）。
【００８８】
また、請求項３９に記載されているように、前記表示枠内に表示するキー定義データ及びデータ項目の少なくとも一方の、文字数及び個数の少なくとも一方に応じて、当該前記表示枠のサイズを調整するようにするとよい。
【００８９】
【発明の実施の形態】
次に、本発明に係る実施の形態を図面を参照して詳細に説明する。
【００９０】
（システムの全体構成）
図１には、データベース設計システムの全体構成図が示されている。図１に示されるように、データベース設計システム１０は、本システムを駆動させるための各種プログラムを格納する補助記憶装置１２と、補助記憶装置１２から各種プログラムを読み出して実行するＣＰＵ１４と、ＣＰＵ１４による各種処理実行結果を格納するデータベース１６とを含んで構成されている。
【００９１】
補助記憶装置１２には、メインシステムとしてのＥＲモデルデータベース設計ツールの起動プログラム１８とともに、データ抽出、仮エンティティ作成、正規化エンティティ登録、対応マトリックステーブル作成（エンティティと画面・帳票との対応関係を示すマトリックステーブルの作成）、リレーションシップ作成（エンティティ間のリレーションシップを示す関係マトリックステーブルの作成）、ＥＲモデル図作成等のデータベース正規化設計のための各サブシステムの起動プログラム２０、及びデータベース管理プログラム２２が格納されている。なお、これらのプログラムは、ＣＤ−ＲＯＭ、ＦＤ等の外部の記録媒体３５から読み出されて、補助記憶装置１２に記憶（インストール）される。また、対応マトリックステーブルが、本発明の第１のマトリックステーブルに対応し、関係マトリックステーブルが、本発明の第２のマトリックステーブルに対応する。
【００９２】
ＣＰＵ１４は、補助記憶装置１２からＥＲモデルデータベース設計ツールの起動プログラム１８を読み出し、このプログラムに従って各サブシステム起動プログラム２０を読み出すようになっている。また、ＣＰＵ１４は、読み出した各サブシステムの起動プログラム２０に従って、処理対象の画面・帳票からデータ項目を抽出して仮エンティティを作成し、それを正規化して正規化エンティティを作成するデータベース正規化処理（後述のようにエンティティタイプの設定も含まれる）や、対応マトリックステーブル作成処理、リレーションシップ作成処理（関係マトリックス作成）、ＥＲモデル図作成処理等を実行する。すなわち、ＣＰＵ１４が、本発明の入力手段、仮エンティティ作成手段、正規化エンティティ作成手段、設定手段、第１のテーブル作成手段、第２のテーブル作成手段、及びＥＲモデル図作成手段として機能する。
【００９３】
データベース１６は、各正規化エンティティのキー定義データとデータ項目の対応を含むアイデンティファイア・アトリビュート仕様２６、対応マトリックステーブル２８、関係マトリックステーブル３０、ＥＲモデル図３２等の情報を含んで構成され、ＣＰＵ１４による各処理実行により生成される結果が格納されるようになっている。なお、対応マトリックステーブル２８、関係マトリックステーブル３０、及びＥＲモデル図３２は、本実施形態では自動的に生成される。
【００９４】
また、補助記憶装置１２には、画面・帳票の追加・削除、ＥＲモデル図３２の統合・抽出、部分ＥＲモデル図化等の正規化設計の各処理結果を編集するための各種の編集プログラム２４も格納されている。なお、これらのプログラムもＣＤ−ＲＯＭ、ＦＤ等の外部の記録媒体３５から読み出されて、補助記憶装置１２に記憶（インストール）される。
【００９５】
ＣＰＵ１４は、補助記憶装置１２からＥＲモデルデータベース設計ツールの起動プログラム１８を読み出し、このプログラムに従って各編集プログラム２４を読み出すことができるようになっている。また、ＣＰＵ１４は、読み出した編集プログラム２４に従って、画面・帳票の追加・削除に基づいて対応マトリックステーブル２８や関係マトリックステーブル３０を修正（変更）してＥＲモデル図３２を作成する画面・帳票の追加・削除処理を行う。また、作成した複数のＥＲモデル図３２の統合処理、作成したＥＲモデル図３２から任意の画面・帳票に対応するＥＲモデル図３２の抽出処理、プログラム仕様書作成のために作成したＥＲモデル図３２を画面・帳票毎に切り出す部分ＥＲモデル生成処理等を実行する。すなわち、ＣＰＵ１４が、本発明の変更手段として機能する。
【００９６】
また、データベース設計システム１０には、ユーザがＣＰＵ１４に対して各種要求や設定を行うためのマウスやキーボード等の入力・操作装置３４と、入力・操作装置３４の操作に基づくＣＰＵ１４の処理結果を表示してユーザに報知するためのモニタ３６と、モニタ３６に表示される処理結果等をプリント出力するためのプリント出力装置３８が備えられている。
【００９７】
このモニタ３６による表示や、プリント出力装置３８によるプリント出力もＣＰＵ１４により制御されており、特に、モニタ３６の表示によって、各種のユーザへの報知も行われるようになっている。すなわち、モニタ３６が、本発明の各種の報知手段（検索結果報知手段、自動分類報知手段、履歴報知手段、非整合報知手段）の機能を担っており、ＣＰＵ１４が、本発明の表示制御手段とともに、前記報知のトリガーに関連する機能（マスターファイル作成手段、検索手段、整合性判断機能）を担っている。
【００９８】
モニタ３６の具体的な表示項目としては、データベースの正規化設計処理に用いられる各種画面（後述のフォーム・データ項目表示枠５０等）、ＥＲモデル図３２の表示、アイデンティファイア・アトリビュート仕様２６の表示（後述のエンティティ表示枠５３）、対応マトリックステーブル２８の表示（後述の対応マトリックステーブル画面５４）、関係マトリックステーブル３０の表示（後述の関係マトリックステーブル画面６４）等のデータベース設計システム１０による処理結果が挙げられる。
【００９９】
また、本実施の形態では、ユーザは、ＧＵＩ（Graphical User Interface）環境下で、処理結果のマニュアル修正や各種データのマニュアル追加・削除を行うことが可能となっており、これらはユーザが入力・操作装置３４を操作することによって行われる。すなわち、入力・操作装置３４が本発明のマニュアル修正手段、マニュアル追加・削除手段に対応する。
【０１００】
また、ユーザは、ＧＵＩ環境下で、各種要求や設定を行うことができるようになっている。具体的には、ユーザが入力・操作装置３４を操作することによって、ＥＲモデルデータベース設計ツールの起動が指示された場合には、ＣＰＵ１４によってＥＲモデルデータベース設計ツール起動プログラムに従ってＥＲモデルデータベース設計ツールが起動され、モニタ３６にメイン画面４０が表示されるようになっている。
【０１０１】
図２には、このメイン画面４０の一例が示されている。図２に示されるように、このメイン画面４０には、「正規化設計」メニューボタン４２と「編集」メニューボタン４４が設けられている。
【０１０２】
「正規化設計」メニューボタン４２はプルダウンメニュー形式となっており、ユーザが入力・操作装置３４を操作することによって、この画面から「正規化設計」メニューボタン４２を選択すると、データベースの正規化設計において実行される各処理に対応したメニューをその実行順に並べたプルダウンメニュー４６が表示されるようになっている。ユーザが入力・操作装置３４の操作によってこのプルダウンメニュー４６からメニューを選択することにより、該メニューに対応するサブシステムの起動プログラムが起動されるようになっている。すなわち、ユーザはこれらの各メニューを順次選択することで、データベースの正規化設計のための各処理を迷わず順次実行させることができるようになっている。なお、各処理については、本実施の形態の作用として後で詳しく説明する（後述「正規化設計処理」参照）。
【０１０３】
また、「編集」メニューボタン４４もプルダウンメニュー形式となっており、ユーザが入力・操作装置３４を操作することによって、この画面から「編集」メニューボタン４４を選択すると、本システムがサポートしている編集メニューを示すプルダウンメニュー４８が表示されるようになっている。ユーザが入力・操作装置３４の操作によってこのプルダウンメニュー４８からメニューを選択することにより、該メニューに対応する編集プログラムが起動されるようになっている。すなわち、ユーザは、これらのメニューの中から任意に編集メニューを選択することで、正規化設計の各処理結果に対して該メニューに対応する編集を行うことができるようになっている。なお、各編集処理については、本実施の形態の作用として後で詳しく説明する（後述「編集処理」参照）。
【０１０４】
（作用）
以下、本実施の形態の作用について説明する。
【０１０５】
ユーザ（設計者）によってＥＲモデルデータベース設計ツールの起動が指示されると、ＣＰＵ１４によってＥＲモデルデータベース設計ツールが起動され、メイン画面４０がモニタ３６に表示される。ユーザは入力・操作装置３４の操作によってメイン画面４０内の「正規化設計」メニューボタン４２を選択することにより、正規化設計処理を行うことができ、メイン画面４０内の「編集」メニューボタン４４を選択することにより、各種の編集処理を行うことができる。以下、正規化設計処理と編集処理についてそれぞれ詳細に説明する。
【０１０６】
（正規化設計処理）
まず、正規化設計処理、すなわちＥＲモデル図作成について説明する。なお、以下では、具体例として、図５２〜図６７に示される画面が正規化設計処理対象の画面に指示され、これらの画面に基づくＥＲモデル図３２を作成する場合について説明する。
【０１０７】
なお、図５２は「部門」画面、図５３は「担当者」画面、図５４は「得意先」画面、図５５は「設計事務所」画面、図５６は「発注者」画面、図５７は「施主」画面、図５８は「記載記事」画面、図５９は「営業案件」画面、図６０は「営業活動」画面、図６１は「設計見積」画面、図６２は「設計作業工数」画面、図６３は「見積作業工数」画面、図６４は「決済」画面、図６５は「入札」画面、図６６は「施工」画面、図６７は「作業所」画面の例である。
【０１０８】
（データ項目の抽出）
正規化設計処理では、図３に示されるように、まず、処理対象の画面・帳票から該画面・帳簿を構成するデータ項目（画面・帳票内データ項目）を抽出するデータ項目の抽出処理が行われる（ステップ１００）。なお、このデータ項目抽出処理は、ユーザによって、プルダウンメニュー４６の「画面・帳票の移動」（図２参照）が選択され、ＣＰＵ１４がデータ抽出サブシステムの起動プログラムを起動することにより開始される。
【０１０９】
データ項目の抽出処理では、処理対象の全画面・帳票をＥＲモデル図作成ツールに移動し（取り込み）、各画面・帳票にどのようなデータが含まれているか分析して、画面・帳票内データ項目が抽出され、この抽出結果がモニタ３６に画面・帳票単位で表示される。また、各画面・帳票毎には互いに異なる番号（以下、「フォームＩＤ」）が付与される。
【０１１０】
例えば、図５２に示される「部門」画面の場合は、「部門コード」、「部門名」が画面内データ項目として抽出され、図５３に示される「担当者」画面の場合は、「社員コード」、「社員名」、「部門コード」が画面内データ項目として抽出される。
【０１１１】
なお、本実施の形態では一例として、図４に示される各画面毎のフォーム・データ項目表示枠５０内に抽出された画面内データを表示し、各画面にはフォームＩＤとして３桁の数字「ＸＸＸ」が付与されるようになっている（なお、フォームＩＤの桁数はこれに限定されず、何桁でもよい）。
【０１１２】
図４（Ａ）には「部門」画面のフォーム・データ項目表示枠５０が示されており、図４（Ｂ）には「施工」画面のフォーム・データ項目表示枠５０が示されている。フォーム・データ項目表示枠５０の上部は、タイトル名として画面の名前が表示され、その下部領域が左右２分割され、当該画面から抽出された画面内データ項目が表示されるようになっている。また、フォーム・データ項目表示枠５０の上方には、当該画面に付与されたフォームＩＤが表示されるようになっている。なお、左領域は空欄であるが、この領域には後述するように右領域に表示されたデータのなかからキー定義データを移動させることになる。ユーザは、このフォーム・データ項目表示枠５０から当該画面にどのような画面内データ項目が属しているかを容易に把握することができる。
【０１１３】
具体的には、図４（Ａ）の「部門」画面のフォーム・データ項目表示枠５０から、「部門」画面には、「部門コード」と「部門名」の画面内データ項目が属していることを把握することができる。なお、「部門」画面には、フォームＩＤとして「１０１」が付与され、フォーム・データ項目表示枠５０の上方には「部門」画面のフォーム・データ項目表示枠であることを示す「フォームＩＤ：１０１」が表示されている。
【０１１４】
また、図４（Ｂ）の「施工」画面のフォーム・データ項目表示枠５０から、「施工」画面には、「工事番号」、「工事名」、「作業所コード」、「工期」、「純工事費」、「利益見込み」、「工事社員コード」、「電話番号」、及び「決済番号」の画面内データ項目が属していることを把握することができる。なお、「施工」画面には、フォームＩＤとして「１１５」が付与され、フォーム・データ項目表示枠５０の上方には「施工」画面のフォーム・データ項目表示枠であることを示す「フォームＩＤ：１１５」が表示されている。
【０１１５】
同様に各画面データから以下のように画面内データ項目が抽出され、画面毎にフォーム・データ項目表示枠５０に表示される。
【０１１６】
フォームＩＤ：１０１「部門」
部門コード、部門名
フォームＩＤ：１０２「担当者」
社員コード、社員名、部門コード
フォームＩＤ：１０３「得意先」
得意先コード、得意先名
フォームＩＤ：１０４「設計事務所」
設計事務所コード、設計事務所名
フォームＩＤ：１０５「発注者」
発注者コード、発注者名、企業イメージ
フォームＩＤ：１０６「施主」
施主コード、施主名
フォームＩＤ：１０７「掲載記事」
連番号、掲載日、掲載誌名、記事概要、案件番号
フォームＩＤ：１０８「営業案件」
案件番号、案件名、記入日、営業社員コード、得意先コード、案件成熟度、受注可能度、発注時期、予想工事費、施工場所、用途、建築概要、敷地面積、建物面積、掲載日、連番号
フォームＩＤ：１０９「営業活動」
営業社員コード、年月日、案件番号、作業時間
フォームＩＤ：１１０「設計見積」
設計番号、設計名称、案件番号、記入日、工期、要望事項、設計提出日、設計社員コード、見積精度、見積額、見積提出日、見積社員コード
フォームＩＤ：１１１「設計作業工数」
設計社員コード、年月日、設計番号、作業時間
フォームＩＤ：１１２「見積作業工数」
見積社員コード、年月日、設計番号、作業時間
フォームＩＤ：１１３「決済」
決済番号、工事名称、入札金額、利益見込み、支払条件、決済日、入札番号、共同事業体、決済者社員コード、設計番号、工事番号
フォームＩＤ：１１４「入礼」
入札番号、入札日、入札場所、入札他社、提出書類
フォームＩＤ：１１５「施工」
工事番号、工事名、作業所コード、工期、純工事費、利益見込み、工事社員コード、電話番号、決済番号
フォームＩＤ：１１６「作業所」
作業所コード、作業所住所、電話番号。
【０１１７】
なお、モニタ３６には、各画面毎のフォーム・データ項目表示枠５０を一つずつ表示してもよいし、或いは複数まとめて表示してもよい。いずれにしても、各画面毎に画面内データ項目を一つのフォーム・データ項目表示枠５０内に表示することが本質である。
【０１１８】
このようにして各画面・帳票から抽出した画面・帳票内データ項目を表示した後、次のステップ１０２では、ユーザにこれで良いか否かの確認を促す。ユーザは、必要であれば修正を施した後、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によって、ＯＫを示すコマンドを入力する。
ＯＫを示すコマンドが入力されると、ステップ１０４の仮エンティティの作成処理に移行する。
【０１１９】
（仮エンティティの作成）
仮エンティティの作成処理は、図３で示したように、ユーザがプルダウンメニュー４６の「仮エンティティ作成」を選択することで実行される。
【０１２０】
仮エンティティの作成処理では、抽出された画面・帳票内データ項目をキー定義データとそのデータ項目に区分（あるいは分類）することにより、画面・帳票毎に仮エンティティを作成する。
【０１２１】
具体的には、データの中でｘｘ番号（ＮＯ、但し電話番号は除く）やｘｘコード（ＣＤ）という名称が付されているデータについては「キー定義データ」に区分し、その他のデータについては「データ項目」に区分することで行われる。なお、場合によっては、ｘｘコード（ＣＤ）やｘｘ番号（ＮＯ）以外のもの（例えば年月日など）をエンティティのキー定義データとして用いることもできる。
【０１２２】
例えば、図５２の「部門」画面から抽出された「部門コード」と「部門名」の場合は、「部門コード」はキー定義データに区分され、「部門名」はデータ項目に区分される。また、図５３「担当者」画面については、「社員コード」及び「部門コード」がキー定義データに区分され、「社員名」がデータ項目に区分される。
【０１２３】
同様に、各画面は、以下のように区分される。
【０１２４】
フォームＩＤ：１０１「部門」
キー定義データ：部門コード、データ項目：部門名
フォームＩＤ：１０２「担当者」
キー定義データ：社員コード、データ項目：社員名
キー定義データ：部門コード
フォームＩＤ：１０３「得意先」
キー定義データ：得意先コード、データ項目：得意先名
フォームＩＤ：１０４「設計事務所」
キー定義データ：設計事務所コード、データ項目：設計事務所名
フォームＩＤ：１０５「発注者」
キー定義データ：発注者コード、データ項目：発注者名、企業イメージ
フォームＩＤ：１０６「施主」
キー定義データ：施主コード、データ項目：施主名
フォームＩＤ：１０７「記載記事」
キー定義データ：連番、データ項目：記載日、記載紙名、記事概要
キー定義データ：案件番号
フォームＩＤ：１０８「営業案件」
キー定義データ：案件番号、データ項目：案件名、記入日、案件成熟度、受注可能度、発注時期、予想工事費、施工場所、用途、建築概要、敷地面積、建物面積、掲載日
キー定義データ：営業社員ＳＢ、営業社員コード
キー定義データ：得意先コード
キー定義データ：連番号
フォームＩＤ：１０９「営業活動」
キー定義データ：年月日
キー定義データ：なし、データ項目：活動時間
キー定義データ：営業社員ＳＢ、営業社員コード
キー定義データ：案件番号
フォームＩＤ：１１０「設計見積」
キー定義データ：設計番号、データ項目：設計名称、記入日、工期、要望事項、設計提出日、見積精度、見積額、見積提出日
キー定義データ：設計社員ＳＢ、設計社員コード
キー定義データ：案件番号
キー定義データ：見積社員ＳＢ、見積社員コード
フォームＩＤ：１１１「設計作業工数」
キー定義データ：年月日
キー定義データ：なし、データ項目：作業時間
キー定義データ：設計社員ＳＢ、設計社員コード
キー定義データ：設計番号
フォームＩＤ：１１２「見積作業工数」
キー定義データ：年月日
キー定義データ：なし、データ項目、作業時間
キー定義データ：見積社員ＳＢ、見積社員コード
キー定義データ：設計番号
フォームＩＤ：１１３「決済」
キー定義データ：決済番号、データ項目：入札金額、利益見込み、
支払条件、決済日、共同企業体
キー定義データ：入札番号
キー定義データ：決済者社員ＳＢ、決済者社員コード
キー定義データ：設計番号
キー定義データ：工事番号、データ項目：工事名称
フォームＩＤ：１１４「入札」
キー定義データ：入札番号、データ項目：入札日、入札場所、入札他社、提出書類
フォームＩＤ：１１５「施工」
キー定義データ：工事番号、データ項目：工事名、工期、純工事費、利益見込み
キー定義データ：作業所コード、データ項目：電話番号
キー定義データ：工事社員ＳＢ、工事社員コード
キー定義データ：決済番号
フォームＩＤ：１１６「作業所」
キー定義データ：作業所コード、データ項目：作業所住所、電話番号。
【０１２５】
具体的なキー定義データとデータ項目との分類作業は、画面毎のフォーム・データ項目表示枠５０を用いて、下部右領域に表示されている画面内データ項目の中からキー定義データを下部左領域に移動させることにより行われる。
【０１２６】
例えば、「部門」画面では、画面内データ項目として図４に示すように「部門コード」と「部門名」が存在し、ｘｘコードやｘｘ番号という名称が付されている画面内データ項目として「部門コード」が存在しているので、ＣＰＵ１４によって自動的に、下部右領域に表示された「部門コード」が下部左領域に移動される。なおこの移動は、ユーザによる入力・操作装置３４の操作（マウスによるクリックやドラッグ操作等）によって、行われるようにしてもよい。
【０１２７】
これにより、フォーム・データ項目表示枠５０には、該画面を構成している画面内データ項目が、一つのキー定義データ及びそのデータ項目で構成される仮エンティティ毎に区分けされて表示される。このときのフォーム・データ項目表示枠５０の一例として、図５（Ａ）には「部門」画面のフォーム・データ項目表示枠５０、図５（Ｂ）には「施工」画面のフォーム・データ項目表示枠５０が示されている。
【０１２８】
なお、本発明はフォーム・データ項目表示枠の形態を特に限定するものではなく、前述のデータ項目の抽出処理時に、抽出された画面内データ項目を表示し、本仮エンティティの作成処理時に、仮エンティティ毎にキー定義データ及びそのデータ項目を区分けして表示することができれば如何なるものでもよい。
【０１２９】
すなわち、フォーム・データ項目表示枠の下部領域を左右２つの領域に分割する２コラム方式でなくてもよい。例えば、図６に示すように１コラム方式として、データ項目の抽出処理時に、抽出された画面内データ項目をフォーム・データ項目表示枠５０Ａの下部領域に表示し（図６（Ａ）参照）、仮エンティティの作成処理時に、フォーム・データ項目表示枠５０Ａの下部領域を作成された仮エンティティ毎に区分けし、区分けされた各仮エンティティ毎の領域において、当該仮エンティティのキー定義データを最上行に表示し、その下の行にキー定義データに対応するデータ項目を順に表示している（図６（Ｂ）参照）。なお、図６では、「施行」画面のフォーム・データ項目表示枠５０Ａを示している。
【０１３０】
以上の処理（画面内データ項目の区分）を最初の画面から最後の画面まで繰り返すことで、全画面について仮エンティティを作成することができる。なお、このとき、処理の済んだ画面からキー定義データとデータ項目との関係でエンティティタイプがリソースのもの（後述するように「〜する」という活用が有効でないもの）をマスターファイルとして記憶させていき、ある画面のキー定義データとデータ項目を分類する際に、このマスターファイルを参照することでデータ項目を適当なキー定義データに割り当てる処理を高速化するようにしてもよい。
【０１３１】
このようにして仮エンティティが作成されたら、すなわち画面内データ項目をキー定義データとデータ項目に区分し、各仮エンティティのタイプが指定されたら、ユーザにこれで良いか否かの確認を促す（ステップ１０６）。ユーザは、必要であれば修正を施した後、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によって、ＯＫを示すコマンドを入力する。ＯＫを示すコマンドが入力されると、次のステップ１０８に移行し、正規化エンティティの登録処理が行われる。
【０１３２】
（正規化エンティティの登録）
正規化エンティティの登録処理は、図３で示したように、ユーザがプルダウンメニュー１１０の「正規化エンティティ登録」を選択することで実行される。
【０１３３】
この正規化エンティティの登録処理では、最初の画面・帳票から順次仮エンティティの情報（エンティティ名、エンティティタイプ、キー定義データ項目とデータ項目）を正規化エンティティのエンティティ情報として、データベース１６のアイデンティファイア・アトリビュート仕様２６に登録していき、後の画面・帳票で、登録済みエンティティ情報のキー定義データと同一あるいは密接に関連しているキー定義データを持つ仮エンティティ（以下、「重複エンティティ」という）が存在する場合には、それらを一つのエンティティにまとめて重複を排除する処理がＣＰＵ１４により自動的に行われる。また、正規化エンティティとして登録された各エンティティには、エンティティタイプが割り当てられる。
【０１３４】
なお、このとき、後述の対応マトリックステーブル２８を作成するために、各正規化エンティティが属する画面・帳票（利用画面・帳票）とその個数もエンティティ情報としてアイデンティファイア・アトリビュート仕様２６に登録されるようになっている（すなわち、データベース１６が、本発明の第１の記憶手段として機能する）。
【０１３５】
詳しくは、正規化エンティティとして仮エンティティを登録する際に、該画面・帳票のフォームＩＤを該正規化エンティティの利用画面・帳票の情報として登録し、後の画面・帳票で重複エンティティが存在した場合には、該重複エンティティが存在する画面・帳票のフォームＩＤを利用画面・帳票の情報に追加登録する。また、利用画面・帳票の情報として登録されたフォームＩＤの個数をカウントし、該エンティティが属する画面・帳票データの個数（以下、「利用数」という）として登録（記憶）する。
【０１３６】
また、後述の詳細対応マトリックステーブル２９を作成するために、登録された正規化エンティティを構成しているキー定義データ項目とデータ項目についても、それぞれ利用画面・帳票と利用数がエンティティ情報としてアイデンティファイア・アトリビュート仕様２６に登録されるようになっている（すなわち、データベース１６が、本発明の第３の記憶手段として機能する）。
【０１３７】
すなわち、アイデンティファイア・アトリビュート仕様２６には、各正規化エンティティのエンティティ情報として、該エンティティのエンティティ名、エンティティタイプ、該エンティティの利用画面・帳票のフォームＩＤと利用数、該エンティティを構成しているキー定義データ項目とデータ項目、キー定義データ項目の利用画面・帳票のフォームＩＤと利用数、データ項目の利用画面・帳票のフォームＩＤと利用数の情報が登録される。
【０１３８】
具体的には、最初のフォームＩＤ：１０１の画面には、キー定義データの「部門コード」とデータ項目の「部門名」が存在し、次のフォームＩＤ：１０２の画面にも同一キー定義データが存在するため、そのデータ項目が既に存在する登録エンティティにまとめられて正規化エンティティとされ、エンティティ名として「部門」が登録される。また、この「部門」エンティティの利用画面・帳票として、１０１及び１０２（フォームＩＤ）が登録され、その利用数として「２」が登録される。さらに、「部門」エンティティを構成するキー定義データ及びデータ項目として、「部門コード」、「部門名」が登録され、「部門コード」の利用画面・帳票として、１０１及び１０２（フォームＩＤ）が登録され、その利用数として「２」が登録され、「部門名」の利用画面・帳票として、１０１（フォームＩＤ）が登録され、その利用数として「１」が登録される。
【０１３９】
次に、各正規化エンティティに対してそれぞれエンティティタイプを以下のリストの中から選択して設定する。
【０１４０】
リソース、リソース・エンティティ・ロール、リソースヘッダ（ＨＤＲ）、リソースディテール（ＤＴＬ）、リソースＶＥ、リソース再帰、イベント、イベント・エンティティ・ロール、イベントＨＤＲ、イベントＤＴＬ、イベントＶＥ、イベント再帰、対照表、対応表、リソース・サブタイプ、リソース・エンティティ・ロール・サブタイプ、リソースＨＤＲ・サブタイプ、リソースＤＴＬ・サブタイプ、リソースＶＥ・サブタイプ、リソース再帰・サブタイプ、イベント・サブタイプ、イベント・エンティティ・ロール・サブタイプ、イベントＨＤＲ・サブタイプ、イベントＤＴＬ・サブタイプ、イベントＶＥ・サブタイプ、イベント再帰・サブタイプ、対照表・サブタイプ、対応表・サブタイプ。
【０１４１】
なお、リソースとイベントの種別は、エンティティの名称に対して「〜する」という活用が有効であるものをイベント、有効でないものとリソースとしている。例えば、「入札」エンティティについては、「入札する」という活用が有効であるためイベントとして分類できるが、「発注者」エンティティについては、「発注者する」という活用は意味をなさないためリソースとして分類することができる。
【０１４２】
また、ＤＴＬ（Detail：ディテール）、ＨＤＲ（Header：ヘッダ）の種別は、画面・帳票内の繰り返し項目に対応するものをＤＴＬ、それ以外をＨＤＲとしている（後述の「ＨＤＲ、ＤＴＬ間におけるリレーションシップ作成」参照）。また、キー定義データのないエンティティをＶＥ（Virtual Entity：仮想エンティティ）、同質のデータ項目で構成されるエンティティ（所謂輪形構造を取るエンティティ）を再帰としている。また、他のエンティティ内に含まれるエンティティをサブタイプとし、例えば「営業社員」エンティティは「社員」エンティティに含まれるためサブタイプとされる。
【０１４３】
具体的なエンティティタイプの設定作業は、プルダウンメニュー４６の「正規化エンティティ登録」を選択すると、さらにプルダウンメニュー５２（図７参照）が表示され、選択可能な全エンティティタイプがリスト表示されるようになっており、ユーザはこのプルダウンメニュー５２から、所望のタイプをマウスで選択することにより各正規化エンティティのエンティティタイプを指定することにより行われる。
【０１４４】
なお、プルダウンメニュー５２では、タイプが強エンティティと弱エンティティに分類されているが、強エンティティとはキー定義データが存在する仮エンティティを意味し、弱エンティティとはキー定義データが存在しない仮エンティティを意味する。弱エンティティに関しては、図７に示されるように一律にイベントとして取り扱うようになっている。
【０１４５】
このように、最初の画面・帳票から順次最後の画面・帳票まで処理して仮エンティティをまとめると、上記のフォームＩＤ：１０１〜フォームＩＤ：１１６の画面は、以下の２２個のエンティティ（正規化エンティティ）に集約される（なお、以下では、エンティティタイプとしてリソースとイベントの種別のみ示す）。
【０１４６】
「部門」：リソース
「社員」：リソース
「得意先」：リソース
「設計事務所」：リソース
「発注者」：リソース
「施主」：リソース
「記載連」：イベント
「案件」：イベント
「営業社員」：リソース
「営業活動」：イベント
「年月日」：リソース
「設計」：イベント
「設計社員」：リソース
「見積社員」：リソース
「設計作業工数」：イベント
「見積作業工数」：イベント
「決済」：イベント
「入札」：イベント
「決済者社員」：リソース
「工事社員」：リソース
「作業所」：リソース
「工事」：イベント。
【０１４７】
以上のようにして正規化エンティティの登録が終了したら、まとめられた登録（正規化）エンティティをモニタ３６に表示してユーザの確認を求める（ステップ１１０）。なお、本実施の形態では、一例として、図８に示されるエンティティ表示枠５３内に、以上のようにしてまとめられた登録（正規化）エンティティが、そのキー定義データ及びデータ項目とともに各々表示されるようになっている。このエンティティ表示枠５３は、上段に名称（エンティティ名）、下段左欄にキー定義データ（アイデンティファイア）、下段右欄にデータ項目（アトリビュート）が表示されている。また、エンティティ名の右側には、該エンティティのリソース（Ｒ）とイベント（Ｅ）の種別が示されている。
【０１４８】
例えば、「部門」エンティティのエンティティ表示枠５３からは、「部門」エンティティがリソースに分類されており、部門コードがキー定義データであり、部門名がデータ項目であることが分かる。なお、「営業活動」エンティティや「設計作業工数」エンティティ、「見積作業工数」エンティティについては、キー定義データが存在しない弱エンティティであるため、イベントに分類される。
【０１４９】
ユーザは、必要であれば修正を施した後、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によって、ＯＫを示すコマンドを入力する。ＯＫを示すコマンドが入力されると、次のステップ１１２に移行し、対応マトリックステーブルの作成処理が行われる。
【０１５０】
（対応マトリックステーブルの作成）
対応マトリックステーブルの作成処理は、図２におけるプルダウンメニュー４６の「対応マトリックステーブル作成」を選択することで開始される。
【０１５１】
この対応マトリックステーブル作成処理では、後述する各エンティティ間のリレーションシップを決定するために、アイデンティファイア・アトリビュート仕様２６に登録されている各正規化エンティティのエンティティ情報に基づいて、正規化エンティティと各画面・帳票との対応関係を示す対応マトリックステーブル２８がＣＰＵ１４により自動的に作成され、その結果がモニタ３６に表示される。
【０１５２】
図９には、このときモニタ３６に表示される対応マトリックステーブル画面５４の一例が示されている。図９に示されるように、対応マトリックステーブル画面５４の上部には、作成された対応マトリックステーブル２８が表示されており、列は画面・帳票を示し、行は最上行に完了フラグ、その下の行からは正規化エンティティを示している。
【０１５３】
対応マトリックステーブル２８には、各正規化エンティティのエンティティ情報に登録されている利用画面・帳票の情報に基づいて、各正規化エンティティの行と、当該正規化エンティティが属している画面・帳票の列が交差する欄に「○」印が表示されている。
【０１５４】
これにより、ユーザは、各画面・帳票に何れの正規化エンティティが属しているのかを確認することができる。例えば、フォームＩＤ：１０１の（「部門」画面）には「部門」エンティティが属しており、フォームＩＤ：１０７の画面（「掲載記事」画面）には「記載連」エンティティと「案件」エンティティが属している。
【０１５５】
また、ユーザは各正規化エンティティが何れの画面・帳票に属するのかを確認することもできる。例えば、「部門」エンティティは、フォームＩＤ：１０１の画面とフォームＩＤ：１０２の画面に属し、「記事連」エンティティは、フォームＩＤ：１０６の画面とフォームＩＤ：１１５の画面に属している。
【０１５６】
なお、対応マトリックステーブル２８の完了フラグの欄は、後述する画面・帳票の削除処理のために設けられており、各画面・帳票を構成している正規化エンティティの個数（「○」印の個数）をカウントし、１つの正規化エンティティしか属していない画面・帳票の完了フラグの欄には「１」印が表示されるようになっている。
【０１５７】
また、対応マトリックステーブル画面５４の下部には、「ＯＫ」ボタン５６とともに、正規化エンティティ毎の詳細対応マトリックスを表示するための「詳細対応マトリックス」ボタン５８と、後述する関係マトリックステーブル３０を表示するための「関係マトリックス」ボタン６０が設けられている。なお、ここでは関係マトリックステーブル３０が未作成なので、「関係マトリックス」ボタン６０は押下不能となっている。
【０１５８】
ユーザは、エンティティ名の欄をクリックする等により任意の正規化エンティティを選択して、「詳細対応マトリックス」ボタン５８を押下することにより、該正規化エンティティの詳細対応マトリックステーブル２９をモニタ３６に表示させることができるようになっている。
【０１５９】
図１０には、このとき表示される詳細対応マトリックステーブル画面６２の例が示されている。図１０に示されるように、詳細対応マトリックステーブル画面６２の上部には、列が画面・帳票を示し、行が該正規化エンティティを構成しているデータ項目（キー定義データ項目とそれに属するデータ項目）を示す詳細対応マトリックステーブル２９が表示されている。
【０１６０】
詳細対応マトリックステーブル２９には、該正規化エンティティのエンティティ情報に登録されているデータ項目（キー定義データ項目とそれに属するデータ項目）の利用画面・帳票の情報に基づいて、当該データ項目が属している画面・帳票の行が交差する欄に「○」印が表示されている。なお、図１０では、「部門」エンティティの詳細対応マトリックステーブル画面６２を示している。
【０１６１】
ユーザはこの詳細対応マトリックステーブル画面６２から当該エンティティを構成しているデータ項目が何れの画面・帳票に用いられているのかを確認することができる。例えば、「部門」エンティティを構成している「部門コード」データ項目（キー定義項目）は、フォームＩＤ：１０１、１０２の画面に用いられ、「部門名」データ項目は、フォームＩＤ：１０１の画面に用いられている。
【０１６２】
なお、詳細対応マトリックステーブル２９が、本発明の第３のマトリックステーブルに対応し、ユーザはこの詳細対応マトリックステーブル２９の情報を用いることで、所謂データライフサイクル分析を容易に行うことも可能となる。
【０１６３】
ユーザは対応マトリックステーブル２８を確認し、必要であれば修正を施し、ＯＫである場合には「ＯＫ」ボタン５６が押下される。「ＯＫ」ボタン５６が押下されると、ユーザがこの対応マトリックステーブル２８でＯＫであると確認したと判断し（ステップ１１４）、ステップ１１６に移行し、リレーションシップの作成処理が行われる。
【０１６４】
（リレーションシップの作成）
リレーションシップの作成処理は、図２におけるプルダウンメニュー４６の「リレーションシップ作成」を選択することで開始される。
【０１６５】
リレーションシップの作成処理では、対応マトリックステーブル２８を基準として、画面・帳票毎にエンティティ間の関係（以下、「リレーションシップ」という）を示す関係マトリックステーブル３０がＣＰＵ１４により自動的に作成される。また、このとき、エンティティ間の種類ごとに、リレーションシップが作成された数（以下、「リレーションシップ数」という）をカウントする。このカウントされたリレーションシップ数は、関係マトリックステーブル３０とともにデータベース１６に格納（記憶）される（すなわち、データベース１６が、本発明の第２の記憶手段として機能する）。
【０１６６】
なお、１つのエンティティのみで構成されている画面・帳票、すなわち対応マトリックステーブルの完了フラグの欄に「１」が記されている画面・帳票については、当然ながらリレーションシップは作成されない。具体的には、フォームＩＤが１０１、１０３、１０４、１０５、１０６、１１４、１１６の画面については、リレーションシップが作成されず、フォームＩＤが１０２、１０７、１０８、１０９、１１０、１１１、１１２、１１３、１１５の各画面についてリレーションシップが作成される。
【０１６７】
このリレーションシップの作成は、詳しくは、まず、実際の業務の流れにおけるリソースの順序やイベント処理の実行順序より各エンティティの上流、下流の判定を行う。なお、実行順序の早いものが上流、実行の遅いものが下流とする。
次に、リソースとリソースのリレーションシップの場合は対照表を作成し、リソースとイベントの場合にはイベントにリソースの参照キーを代入する。イベントとイベントのリレーションシップの場合は、上流、下流の関係が１：１または１：Ｎの場合には下流のエンティティに参照キーを代入し、上流、下流の関係がＮ：１またはＮ：Ｎの場合には対応表を作成する。また、不必要なリレーションシップは全て削除する。
【０１６８】
このとき、繰り返し項目（所謂ディテール部分）が含まれる各画面・帳票については、処理時間短縮のために、該画面・帳票を構成しているエンティティをＨＤＲ（ヘッダ）エンティティ（ＨＤＲ部分）とＤＴＬ（ディテール）エンティティ（ＤＴＬ部分）に分割して、リレーションシップの作成処理を行っており、後述の「ＨＤＲ、ＤＴＬ間におけるリレーションシップ作成」で詳しく説明する。
【０１６９】
なお、より詳細なリレーションシップに関しては、特開平９−１４６８０５号公報の図２に記載されており、参考のため、図１１にこのリレーションを示す。
図１１に示されるようなエンティティの種類毎のリレーションシップの関係を予めテーブルとして記憶させておくことにより、ＣＰＵ１４では容易にエンティティ間のリレーションを規定することができ、処理時間の短縮を図ることができる。
【０１７０】
関係マトリックステーブル３０が作成されると、対応マトリックステーブル画面５４（図９参照）の「関係マトリックス」ボタン６０が押下可能となる。ユーザは、マトリックステーブル画面５４のフォームＩＤの欄をクリックする等により任意の画面・帳票を選択して、「関係マトリックス」ボタン６０を押下することにより、該画面・帳票の関係マトリックステーブル画面６４をモニタ３６に表示させることができる。これにより、ユーザは、作成されたリレーションシップ（関係マトリックステーブル３０）を確認することができる。
【０１７１】
図１２には、関係マトリックステーブル画面６４の一例が示されている。図１２に示されているように、関係マトリックステーブル画面６４の上部には、作成された関係マトリックステーブル３０が表示されており、列は下流エンティティを示し、行は上流エンティティを示している。また、関係マトリックステーブル画面６４の下部には、ＯＫボタン６６、削除ボタン６８、変更ボタン７０（後述するエンティティタイプの変更処理に用いられる）が設けられている。なお、図１２は、フォームＩＤ：１１３の画面の関係マトリックステーブル画面６４を示している。
【０１７２】
例えば、フォームＩＤ：１１３を構成しているエンティティは、「決済者社員」エンティティのみがリソースであり、その他の「決済」、「入札」、「設計」、「工事」の各エンティティはイベントであり、イベントの各エンティティ（「決済」、「入札」、「設計」、「工事」）にリソース「決済者社員」の参照キーの代入を示す「ＲＦ」が表示されている。また、イベントのエンティティはそれぞれ１対１対応であるので、下流エンティティ側（マトリックスの左上と右下を結ぶ対角線で２分割した右上部）にそれぞれ参照キーの代入を示す「ＲＦ」が表示されている。
【０１７３】
ユーザは、全画面の関係マトリックステーブル画面６４をモニタ３６に表示させて関係マトリックステーブル３０を確認し、不必要なリレーションシップがある場合は該リレーションシップを削除し（不必要と判断したリレーションシップの欄を選択して、削除ボタン６８を押下することにより行われる）、ＯＫである場合には「ＯＫ」ボタン６６を押下する。「ＯＫ」ボタン６６が押下されると、ユーザがこの関係マトリックステーブル３０でＯＫであると判断し（ステップ１１８）、ステップ１２０に移行し、ＥＲモデル図の作成処理が行われる。なお、リレーションシップが削除された際には、当然ながらこのリレーションシップに対応するリレーションシップ数を減じて更新記憶する。
【０１７４】
（ＥＲモデル図の作成）
ＥＲモデル図の作成処理は、図２におけるプルダウンメニュー４６の「ＥＲモデル図作成」を選択することで開始される。
【０１７５】
ＥＲモデル図の作成処理では、登録された正規化エンティティを各々作図し、関係マトリックステーブル３０に基づいて、作図された正規化エンティティ間の接続や参照キーの入り方を決定し、対照表及び対応表を作成することによって、最終的なＥＲモデル図３２がＣＰＵ１４により自動的に作成される。
【０１７６】
図１３には、このようにして作成されたＥＲモデル図３２が示されている。図１３に示されているように、ＥＲモデル図３２では、登録された各正規化エンティティとして、エンティティ表示枠５３が描かれ、リレーションシップが作成されたエンティティ間（エンティティ表示枠５３間）が接続線７２によって接続されている。なお、図１３では、各エンティティ間の接続線７２において、上流側のエンティティに黒点を付けることにより、エンティティ間の上流／下流の関係を区別している。
【０１７７】
また、例えば、リソースである「部門」エンティティと「社員」エンティティの間は上述したように対照表が作成されるため、図に示すように対照表７４が作成されている。また、イベントである「営業活動」エンティティや「設計作業工数」エンティティについては、リソースである「営業社員」エンティティ、「設計社員」エンティティと上流、下流の１：Ｎの関係にあるので上流の参照キーである営業社員コード、設計社員コードがそれぞれ代入される。
【０１７８】
以上のようにして、本実施の形態では、容易かつ確実にＥＲモデル図を自動生成することができる。
【０１７９】
なお、本実施形態では、図３に示した各処理を実行するに当たって、ユーザの確認を求めているが、正規化エンティティの切り出し処理を実行した後はＣＰＵ１４が自動的に処理するので、一部のリレーションシップ作成を除いて確認処理を省くことも可能である。
【０１８０】
また、仮エンティティの作成処理途中、或いは終了時にマスターファイルを用いてキー定義データが未定義の仮エンティティ（キー定義データがない弱仮エンティティ）を検索するようにしてもよい。
【０１８１】
例えば、図１４に示されるような「受注計上」画面から画面内データ項目を抽出し、図１５（Ａ）に示されるように抽出した画面内データ項目が区分され、マスターファイルに図１６に示される仮エンティティの情報が既に登録されている場合は、キー定義データ：なし、データ項目：規格、受注単価、単位、品名と区分された仮エンティティ（図１５（Ａ）参照）が検索される。
【０１８２】
一方、マスターファイルには、図１６に示されるように、キー定義データ：商品ＣＤ、データ項目：規格、受注単価、単位、品名と区分された「商品」仮エンティティが既に登録されている。
【０１８３】
ＣＰＵ１４は、弱エンティティとして検索された仮エンティティは、本来は弱エンティティではなく、「商品ＣＤ」キー定義データを入力し忘れた強エンティティであると判断し、アラームを鳴らす、フォーム・データ項目表示枠５０内の対応する仮エンティティの欄を反転させて表示する等してユーザに報知する。これを受けて、ユーザは検索された仮エンティティのキー定義データの欄（検索された弱エンティティの左側領域）に「商品ＣＤ」を入力する。これにより、以降の正規化エンティティの作成処理において、重複のないように仮エンティティを正確にまとめて正規化することができる。
【０１８４】
また、弱エンティティが検索された場合に、ユーザによるマニュアル入力ではなく、ＣＰＵ１４によって作成済みの正規化エンティティをマスターファイルに登録しておき、このマスターファイルを参照して、自動的に適切なキー定義データを入力して仮エンティティを作成するようにしてもよい。この場合、マスターファイルを用いた自動仮エンティティ作成の履歴情報を保持しておき、ユーザに報知するとよい。例えば、仮エンティティ作成処理後、その処理結果を表示する際に、マスターファイルを用いて作成された仮エンティティの欄を反転させたり、太線で囲む等すればよい（図１５（Ｂ）参照）。これを受けて、ユーザは、マスターファイルを用いて適切に仮エンティティが作成されたか否かを確認することができ、不適切な場合は、修正を施すことができるので、以降の処理の正確性を向上させることができる。
【０１８５】
また、ユーザによりフォーム・データ項目表示枠５０内に表示内容がマニュアル修正された場合も、その修正履歴を記憶しておき、報知するようにするとよい。例えば、本実施の形態では、ユーザによる入力・操作装置３４の操作（マウスによるクリックやドロップ操作）によって、フォーム・データ項目表示枠５０内に表示されているキー定義データやデータ項目の位置を変更することで、仮エンティティや正規化エンティティを修正することができるようになっており、このときの移動元から移動先へと、矢印を表示すれば（図１５（Ｂ）参照）、目視で修正内容を確認することができる。
【０１８６】
（ＨＤＲ、ＤＴＬ間におけるリレーションシップの作成）
本実施の形態では、リレーションシップを作成する際に、各画面・帳票を構成しているエンティティをＨＤＲ部分とＤＴＬ部分に分割して処理しており、この処理について詳細に説明する。
【０１８７】
なお、以下では、具体的に、図１４に示した「売上計上」画面を処理対象として、データ項目の抽出処理、仮エンティティの作成処理、正規化エンティティの登録処理を行った後、この結果に対してリレーションシップを作成する場合について説明する。
【０１８８】
図１７は、正規化エンティティの登録処理後の「売上計上」画面のフォーム・データ項目表示枠５０を示している。図１７では、フォーム・データ項目表示枠５０を二重線で枠形成しているが、これはフォーム・データ項目表示枠５０に表示しているデータが正規化処理後のものである、すなわち正規化エンティティによる区分であることを示している。
【０１８９】
図１４に示されるように、売上計上画面には繰り返し項目（受注明細ＮＯ、商品ＣＤ、品名、規格、単位、入数、ケース数、受注数量、受注単価、受注金額、備考）が含まれており、正規化エンティティは繰り返し項目に対応するＤＴＬ（ディテール）エンティティと、それ以外のＨＤＲ（ヘッダ）エンティティに分けることができる。すなわち、図１７において、キー定義項目が受注ＮＯ、倉庫ＣＤ、担当者ＣＤ、得意先ＣＤ、納品先ＣＤの各エンティティがＨＤＬエンティティ（ＨＤＬ部分）とされ、キー定義項目が受注明細ＮＯ、商品ＣＤの各エンティティがＤＴＬエンティティ（ＤＴＬ部分）とされる。
【０１９０】
本実施の形態では、ＨＤＲ部分とＤＴＬ部分に分割したら、図１８に示されるように、ＨＤＲ部分内（１〜５のエンティティ）でリレーションシップを作成し、ＤＴＬ部分内（６〜７のエンティティ）でリレーションシップを作成する。また、ＨＤＲ部分とＤＴＬ部分とをつなぐリレーションシップを作成する。なお、ＨＤＲ部分とＤＴＬ部分とをつなぐリレーションシップは、最上流ＨＤＲエンティティと最上流ＤＴＬエンティティに対応する欄に表示されている。
【０１９１】
図１９には、ＨＤＲ部分とＤＴＬ部分を考慮せずに売上計上画面のリレーションシップを作成した例が示されている。図１８と図１９を比較すると、ＨＤＲ部分とＤＴＬ部分に分割して処理することにより、ＨＤＲ部分の各エンティティとＤＴＲ部分の各エンティティとの間（図１８の斜線部分）のリレーションシップの作成を省略できることが分かる。
【０１９２】
このように、ＨＤＲ部分とＤＴＬ部分を考慮してリレーションシップを作成することにより、リレーションシップ作成処理を約１／２程度に簡略化することができ、処理時間を短縮できる。
【０１９３】
なお、ＨＤＲ部分とＤＴＬ部分の区分は、データ項目抽出時に行われるようになっている。これにより、仮エンティティの作成処理時には、ＨＤＲ部分の画面・帳票内データ項目内でキー定義データとそのデータ項目に区分し、ＤＴＬ部分の画面・帳票内データ項目内でキー定義データとそのデータ項目に区分すればよく、処理を簡略化することができる。
【０１９４】
また、データ項目抽出時に、ユーザが画面・帳票内データ項目のＨＤＲ部分／ＤＴＬ部分の種別を識別できるように、抽出した画面・帳票内データ項目をフォーム・データ項目表示枠５０に表示するようにするとよい。これにより、ユーザによる画面・帳票内データ項目内をキー定義データとそのデータ項目に区分する区分作業が行い易くなる。
【０１９５】
例えば、図３０（Ａ）に示されるように、フォーム・データ項目表示枠５０において、抽出された画面・帳票内データ項目が表示される下部領域を上下に２分割し、２分割された上部の領域にＨＤＲ部分、下部の領域にＤＴＬ部分の画面・帳票内データ項目を表示すれば、ユーザは画面・帳票内データ項目のＨＤＲ部分／ＤＴＬ部分の種別を容易に識別できる。これにより、ユーザは画面・帳票内データ項目内をキー定義データとそのデータ項目に区分する区分作業を容易に行うことができる。
【０１９６】
（エンティティタイプの変更）
前述の仮エンティティの作成処理時にユーザがエンティティタイプを間違って設定した等のために、正規化エンティティのエンティティタイプが間違っている場合には、正しいエンティティタイプに変更する必要がある。本実施の形態では、リレーションシップ作成時にエンティティタイプの変更を行うことができるようになっている。
【０１９７】
詳しくは、リレーションシップ作成時には対応マトリックステーブル画面５４がモニタ３６に表示されており、ユーザは入力・操作装置３４を操作することによって、対応マトリックステーブル画面５４上で、対応マトリックステーブル２８からエンティティタイプが間違っている正規化エンティティの行を選択する。
そして、「関係マトリックス」ボタン６０を押下し、該正規化エンティティが関係する画面の関係マトリックステーブル画面６４を表示させる。
【０１９８】
以下、具体的に、「決済」エンティティのエンティティタイプが、正しくはイベント（Ｅ）であるのに間違ってリソース（Ｒ）に設定されている場合（図２０参照）について説明する。
【０１９９】
ユーザは「決済」エンティティのエンティティタイプが間違って設定されていると判断した場合、対応マトリックステーブル画面５４上で、対応マトリックステーブル２８の「決済」エンティティの行を選択して「関係マトリックス」ボタン６０を押下する。「決済」エンティティは、図２０にも示されているように、フォームＩＤ：１１３と１１５の画面に属しており、ＣＰＵ１４は、これを受けて、フォームＩＤ：１１３と１１５の画面の関係マトリックステーブル画面６４（図２１参照）をモニタ３６に表示する。
【０２００】
このとき関係マトリックステーブル画面６４は、「決済」エンティティの行が選択されて表示（反転表示）されており、エンティティタイプ変更対象の正規化エンティティが「決済」エンティティであることを示している。
【０２０１】
ユーザは入力・操作装置３４を操作することによって、フォームＩＤ：１１３の画面の関係マトリックステーブル画面６４又はフォームＩＤ：１１５の画面の関係マトリックステーブル画面６４において、「決済」エンティティの行が選択されている状態で変更ボタン７０を押下する。ＣＰＵ１４はこれを受けて、「決済」正規化エンティティのエンティティタイプをリソースからイベントに変更するとともに、フォームＩＤ：１１３及び１１５の画面のリレーションシップを作成しなおし、その結果を関係マトリックステーブル３０に反映させて関係マトリックステーブル画面６４に表示させる。
【０２０２】
図２２には、エンティティタイプを変更（修正）後のフォームＩＤ：１１３及び１１５の画面の関係マトリックステーブル画面６４が示されている。図２２から、「決済」正規化エンティティのエンティティタイプに変更に伴って、「決済」正規化エンティティに関するリレーションシップが変更されていることが分かる。
【０２０３】
なお、上記では、エンティティタイプの変更に伴うリレーションシップの変更結果をユーザが確認できるように、関係マトリックステーブル画面６４を表示してからエンティティタイプを変更するようにしたが、対応マトリックステーブル画面５４上でエンティティタイプを直接変更するようにしてもよい。また、変更ボタン７０の押下により、プルダウンメニュー５２（図７参照）をモニタ３６表示させ、このプルダウンメニュー５２から、正しいエンティティタイプをマウス等で選択することにより、エンティティタイプが変更されるようにしてもよい。
【０２０４】
（編集処理）
次に、上記の正規化設計処理後、すなわちＥＲモデル図３２の作成後に、必要に応じて行われる各種の編集処理について説明する。
【０２０５】
（画面・帳票の追加）
ＥＲモデル図作成後に新たに画面・帳票を追加する必要が生じた場合には、図２３に示される画面・帳票の追加処理が行われる。なお、この画面・帳票の追加処理は、ユーザによって図２におけるメイン画面４０内の「編集」メニューボタン４４が選択され、プルダウンメニュー４８から「画面・帳票追加」が選択されることにより開始される。
【０２０６】
なお、以下では、図２５に示す「発注計上」画面を処理対象画面に指示して、前述の正規化設計処理の各処理を行なってＥＲモデル図３２（図２６参照）を作成した後に、図１４に示した「受注計上」画面が追加画面に指示された場合を例に説明する。
【０２０７】
前回の正規化設計処理（「発注計上」画面に対する正規化設計処理の各処理）によって、既に以下のエンティティが正規化エンティティとしてアイデンティファイア・アトリビュート仕様２６に登録（記憶）されている（図２７参照）。
【０２０８】
「発注」エンティティ
キー定義データ：発注ＮＯ、データ項目：備考１、発注納期、発注伝票合計、発注日付
「倉庫」エンティティ
キー定義データ：倉庫ＣＤ、データ項目：倉庫名
「担当者」エンティティ
キー定義データ：担当者ＣＤ、データ項目：担当者名
「メーカ」エンティティ
キー定義データ：メーカＣＤ、データ項目：メーカ名
「仕入先」エンティティ
キー定義データ：仕入先ＣＤ、データ項目：仕入先名
「発注明細」エンティティ
キー定義データ：発注明細ＮＯ、データ項目：ケース数、発注数量、入数、発注金額、備考
「商品」エンティティ
キー定義データ：商品ＣＤ、データ項目：品名、単位、発注単価、規格。
【０２０９】
また、前回の正規化設計処理によって、図２８に示される対応マトリックステーブル２８、図２９に示される関係マトリックステーブル３０も作成されている。なお、図２５〜図２９では、「発注計上」画面のフォームＩＤとして「１１７」が付与されている場合を例に示している。
【０２１０】
画面・帳票の追加処理では、図２３に示されるように、まず、ユーザによって新たに処理対象として追加するように指示された画面・帳票（以下、「追加画面・帳票」という）をＥＲモデル図作成ツールに移動し（取り込み）、追加画面・帳票にフォームＩＤを付与するとともに、各追加画面・帳票にどのようなデータが含まれているか分析し、画面・帳票内データ項目が抽出される（ステップ２００）。なお、以下では、「受注計上」画面のフォームＩＤとして「１１８」が付与された場合を例に説明する。
【０２１１】
「受注計上」画面（追加画面）が分析されると、画面内データ項目として、受注納期、受注日付、受注ＮＯ、倉庫ＣＤ、倉庫名、担当者ＣＤ、担当者名、受注伝票合計、得意先ＣＤ、得意先名、納品先ＣＤ、納品先名、備考１（以上ＨＤＲ部分）、ケース数、規格、受注金額、受注単価、受注明細ＮＯ、商品ＣＤ、受注数量、単位、入数、備考、品名（以上ＤＴＬ部分）が抽出される。この抽出結果は、図３０（Ａ）に示されるように、ＨＤＲ部分とＤＴＬ部分とで区分されてフォーム・データ項目表示枠５０に表示される。
【０２１２】
次のステップ２０２では、ユーザにこれで良いか否かの確認を促す。必要であれば修正を施した後、ユーザは、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によって、ＯＫを示すコマンドを入力する。ＯＫを示すコマンドが入力されると、ステップ２０４に移行する。
【０２１３】
ステップ２０４では、図２４（Ａ）に示される自動正規化処理が行われる。自動正規化処理では、まず、登録済みの正規化エンティティを参照して、追加画面・帳票から抽出された画面・帳票内データ項目を自動的にキー定義データとそのデータ項目に区分して仮エンティティが作成される（ステップ２２０）。具体的には、以下のように自動的に区分される（図３０（Ｂ）参照）。
【０２１４】
「倉庫」エンティティを参照して
キー定義データ：倉庫ＣＤ、データ項目：倉庫名
「担当者」エンティティを参照して
キー定義データ：担当者ＣＤ、データ項目：担当者名
「商品」エンティティを参照して
キー定義データ：商品ＣＤ、データ項目：規格、受注単価、単位、品名
と区分される。
【０２１５】
次に、上記の各正規化エンティティのエンティティ情報として、アイデンティファイア・アトリビュート仕様２６に登録されている正規化エンティティ、キー定義データ、データ項目の利用画面・帳票及び利用数の情報を更新する（ステップ２２２）。詳しくは、「受注計上」画面（追加画面）のフォームＩＤを利用画面・帳票の情報に追加し、また利用数をインクリメントして記憶する。具体的には、正規化エンティティの現利用数がｎ１であり、今回追加される画面・帳票のうち、ａ１個の画面・帳票に当該正規化エンティティが含まれている場合は、新利用数としてｎ１＝ｎ１＋ａ１が記憶される。また、キー定義データ又はデータ項目の現利用数がｎ２であり、今回追加される画面・帳票のうち、ａ２個の画面・帳票に当該キー定義データ又はデータ項目が含まれている場合は、新利用数としてｎ２＝ｎ２＋ａ２が記憶される。
【０２１６】
例えば、「倉庫」エンティティの場合、該エンティティの利用画面・帳票として「１１７」（「発注計上」画面のフォームＩＤ）が既に登録されているが、ここで、新たに「１１８」（「受注計上」画面のフォームＩＤ）が追加される。また、該エンティティの現利用数として「１」（すなわちｎ１＝１）が記憶されており、今回追加される「発注計上」画面にも「倉庫」エンティティが属しているので（すなわちａ１＝１）、「倉庫」エンティティの新利用数として「２」が記憶される。
【０２１７】
また、「倉庫」エンティティに属している「倉庫ＣＤ」キー定義データ、「倉庫名」データ項目についても同様に、利用画面・帳票として新たに「１１８」（「受注計上」画面のフォームＩＤ）が追加される。また、「倉庫ＣＤ」キー定義データの現利用数として「１」（すなわちｎ２＝１）が記憶されており、今回追加される「発注計上」画面にも「倉庫ＣＤ」キー定義データが属しているので（すなわちａ２＝１）、「倉庫ＣＤ」キー定義データの新利用数として「２」が記憶される。「倉庫名」データ項目についても同様に新利用数が記憶される。
【０２１８】
このとき、当然ながら、エンティティ情報に未登録のデータ項目も追加登録されるようになっている。例えば、「商品」エンティティに属するデータ項目として、「受注単価」が追加登録され、この「受注単価」データ項目の利用画面・帳票として「１１８」が登録され、その利用数（ｎ２）として「１」が記憶される。
【０２１９】
一方、対応する登録済みの正規化エンティティが存在せず、ステップ２２０で区分されなかった画面・帳票内データ項目がある場合（ステップ２２４で肯定判定）は、画面・帳票の追加によって新たに追加された画面・帳票内データ項目であると判断して、ステップ２２６に移行する。
【０２２０】
ステップ２２６では、この画面・帳票内データ項目が、キー定義データとデータ項目とにＣＰＵ１４によって自動的に区分され（仮エンティティ作成）及び正規化が行われる。なお、前述の仮エンティティの作成処理時と同様に、ユーザが画面・帳票内データ項目の中からキー定義データを指定することにより区分されるようにしてもよい。
【０２２１】
具体的には、受注ＮＯ、備考１、受注納期、受注日付、受注伝票合計、得意先ＣＤ、得意先名、納品先ＣＤ、納品先名、受注明細ＮＯ、ケース数、受注金額、受注数量、入数、備考の各画面内データ項目が、画面・帳票の追加によって新たに追加された画面内データ項目であると判断される。これらを、以下のように、名称にＣＤ又はＮＯが付いているものをキー定義データとし、その他をデータ項目に区分して、自動的に仮エンティティが作成される（図３０（Ｂ）参照）。
【０２２２】
キー定義データ：受注ＮＯ、データ項目：備考１、受注納期、受注日付、受注伝票合計
キー定義データ：得意先ＣＤ、データ項目：得意先名
キー定義データ：納品先ＣＤ、データ項目：納品先名
キー定義データ：受注明細ＮＯ、データ項目：ケース数、受注金額、受注数量、入数、備考。
【０２２３】
また、これらの仮エンティティを正規化エンティティとしてアイデンティファイア・アトリビュート仕様２６に登録する。すなわち、
「受注」エンティティ
キー定義データ：受注ＮＯ、データ項目：備考１、受注納期、受注日付、受注伝票合計
「得意先」エンティティ
キー定義データ：得意先ＣＤ、データ項目：得意先名
「納品先」エンティティ
キー定義データ：納品先ＣＤ、データ項目：納品先名
「受注明細」エンティティ
キー定義データ：受注明細ＮＯ、データ項目：ケース数、受注金額、受注数量、入数、備考
が新たな正規化エンティティとして登録される。
【０２２４】
このとき、アイデンティファイア・アトリビュート仕様２６には、各正規化エンティティ（「受注」、「得意先」、「納品先」、「受注明細」）の利用画面・帳票として「１１８」（追加画面である「受注計上」画面のフォームＩＤ）が記憶され、利用数（ｎ１）として１が記憶される。また、同様に、各正規化エンティティに属している各キー定義データ、及び各データ項目についても、利用画面・帳票として「１１８」が記憶され、利用数（ｎ２）として１が記憶される。
【０２２５】
なお、複数の画面・帳票が同時に追加される場合は、前述の正規化エンティティの登録処理と同様に重複が排除されて登録される。
【０２２６】
このようにして、追加画面・帳票から抽出した画面・帳票内データ項目について自動正規化処理が行われると、図２３に戻り、現在、アイデンティファイア・アトリビュート仕様２６に登録されている正規化エンティティのエンティティ情報に基づいて、対応マトリックステーブル２８が作成される（ステップ２０６）。
【０２２７】
これにより、図３１に示されるように、前回作成した対応マトリックステーブル２８（図２８参照）に対して、追加画面である「受注計上」画面に対応する列と、「受注」エンティティ、「得意先」エンティティ、「納品先」エンティティ、及び「受注明細」エンティティに対応する行が追加される。また、「受注計上」画面に属する正規化エンティティ（すなわち、「受注」「倉庫」「担当者」「得意先」「納品先」「受注明細」「商品」エンティティ）の欄に「○」印が表示される。
【０２２８】
このとき、各正規化エンティティに対して、詳細対応マトリックスも作成される。なお、「商品」エンティティのに対しては、前回作成した詳細対応マトリックステーブル２９に対して、「受注単価」の行が追加された詳細対応マトリックステーブル２９が作成される。
【０２２９】
続いて、この対応マトリックステーブル２８に基づいて、追加画面・帳票の関係マトリックステーブル３０が新たに作成される。このとき、不必要なリレーションシップは削除される。また、作成した追加画面・帳票の関係マトリックステーブル３０からリレーションシップが抽出される（ステップ２０８）。具体的には、図３２に示される追加画面・帳票の関係マトリックステーブル３０が作成された場合には、
「受注」エンティティ−「倉庫」エンティティ
「受注」エンティティ−「担当者」エンティティ
「受注」エンティティ−「得意先」エンティティ
「受注」エンティティ−「納品先」エンティティ
「受注」エンティティ−「受注明細」エンティティ
「担当者」エンティティ−「得意先」エンティティ
「担当者」エンティティ−「納品先」エンティティ
「得意先」エンティティ−「納品先」エンティティ
「受注明細」エンティティ−「商品」エンティティ
の９個のリレーションシップが抽出される。
【０２３０】
続いて、ステップ２１０では、画面図２４（Ｂ）に示されるリレーションシップ変更処理が行われる。
【０２３１】
リレーションシップ変更処理では、抽出されたリレーションシップが、前回ＥＲモデル図作成時から削除されたのか追加されたのかを判断する（ステップ２４０）。ここでは、画面・帳票の追加に伴って、抽出されたリレーションシップが追加されたので、ステップ２５０に進む。
【０２３２】
ステップ２５０では、該リレーションシップのリレーションシップ数をインクリメントして更新記憶する。例えば、「受注」エンティティ−「倉庫」エンティティの現リレーションシップ数がｋ（上記の例ではｋ＝０）と記憶されている場合は、新リレーションシップ数としてｋ＝ｋ＋１が記憶される。
【０２３３】
次のステップ２５２では、このリレーションシップ数を１と比較し、該エンティティ間のリレーションシップが前回ＥＲモデル図作成時にも存在しているか否かを判断する。
【０２３４】
リレーションシップ数が１の場合（ｋ＝１）は、前回ＥＲモデル図作成時には、該エンティティ間のリレーションシップがなかったと判断して、ステップ２５４に進む。ステップ２５４では、前回作成したＥＲモデル図３２に対して、該エンティティ間を接続する接続線を追加させ、図２３に戻る。
【０２３５】
一方、リレーションシップ数が１ではない場合（ｋ＞１）は、前回ＥＲモデル図作成時に該エンティティ間のリレーションシップが既に存在しており、前回作成したＥＲモデル図３２において、該エンティティ間が接続線で接続されていると判断し、そのまま図２３に戻る。
【０２３６】
図２３に戻ると、ステップ２０８で抽出した全リレーションシップに対してステップ２１０のリレーションシップ変更処理を行ったか否かを判断し（ステップ２１２）、未処理のリレーションシップがある場合には、ステップ２１０に戻り、次のリレーションシップに対して同様にリレーションシップ変更処理を行う。
【０２３７】
ステップ２０８で抽出した全リレーションシップに対してリレーションシップ変更処理が行われたら、画面・帳票の追加処理は終了される。
【０２３８】
これにより、「受注計上」画面の追加に基づいて修正されたＥＲモデル図３２を得ることができる（図３３参照）。このＥＲモデル図３２は、当然ながら、「発注計上」画面と「売上計上」画面を正規化設計処理対象の画面に指示して、前述の正規化設計処理を行って作成されるＥＲモデル図３２と同一である。
【０２３９】
（画面・帳票の削除）
一方、ＥＲモデル図作成後に一部の画面・帳票を削除する必要が生じた場合には、図３４に示される画面・帳票の削除処理がＣＰＵ１４により自動的に行われる。なお、この画面・帳票の削除処理は、ユーザによって図２におけるメイン画面４０内の「編集」メニューボタン４４が選択され、プルダウンメニュー４８から「画面・帳票削除」が選択されることにより開始される。
【０２４０】
なお、以下では、前述の画面・帳票の追加処理とは反対に、図１４、図２５に示した「受注計上」画面と「発注計上」画面に基づいてＥＲモデル図３２（図３３参照）を作成した後に、「受注計上」画面が削除画面に指示された場合を例に説明する。
【０２４１】
画面・帳票の追加処理では、図３４に示されるように、まず、対応マトリックステーブル２８（図３１参照）を参照して、ユーザによって削除するように指示された画面・帳票（以下、「削除画面・帳票」という）に属している正規化エンティティを抽出する（ステップ３００）。具体的には、「倉庫」、「担当者」、「商品」、「受注」、「得意先」、「納品先」、「受注明細」の各エンティティが抽出される。
【０２４２】
次のステップ３０２では、抽出した正規化エンティティに対応するアイデンティファイア・アトリビュート仕様２６に記憶されているエンティティ情報から、該エンティティの利用画面・帳票として記憶されている削除画面・帳票のフォームＩＤを削除するとともに、利用数の情報をデクリメントして更新記憶する。詳しくは、現利用数がｎ１であり、今回削除される画面・帳票のうち、ｄ１個（ここではｄ１＝１）の画面・帳票に該エンティティが含まれている場合は、新利用数としてｎ１＝ｎ１−ｄ１が記憶される。
【０２４３】
これにより、「倉庫」、「担当者」、「商品」、「受注」、「得意先」、「納品先」、「受注明細」の各正規化エンティティの利用画面・帳票の情報から、「１１８」（「受注計上」画面のフォームＩＤ）が削除される。また、「受注」、「得意先」、「納品先」、「受注明細」の各エンティティは、現利用数が１であるので、新利用数として０が記憶され、「倉庫」、「担当者」、「商品」の各エンティティは、現利用数が２であるので、新利用数として１が記憶される。
【０２４４】
次に、この利用数の情報が０と比較され、該正規化エンティティが削除画面・帳票以外の画面・帳票にも属している（利用されている）か否かが判断される（ステップ３０４）
利用数が０の場合（ｎ１＝０）場合は、該正規化エンティティが削除画面・帳票にのみ属する正規化エンティティであると判断されて、ステップ３０６に進む。具体的には、「受注」、「得意先」、「納品先」、「受注明細」の各エンティティの利用数が０であるので、「受注」、「得意先」、「納品先」、「受注明細」の各正規化エンティティの場合は、ステップ３０６に進む。
【０２４５】
ステップ３０６では、アイデンティファイア・アトリビュート仕様２６に記憶されている該正規化エンティティのエンティティ情報（エンティティ名、キー定義データ、データ項目、利用画面のフォームＩＤ、利用数）が全て削除されて、後述のステップ３１８に進む。
【０２４６】
利用数が０ではない場合（ｎ１＞０）場合は、該正規化エンティティが削除画面・帳票以外にも属する正規化エンティティであると判断されてステップ３０８に進む。具体的には、「倉庫」、「担当者」、「商品」の各正規化エンティティの利用数が１であるので、「倉庫」、「担当者」、「商品」の各正規化エンティティの場合は、ステップ３０８に進む。
【０２４７】
ステップ３０８では、この正規化エンティティを構成しているキー定義データ及びデータ項目が抽出される。次いでステップ３１０では、抽出されたキー定義データ及びデータ項目の利用画面・帳票、及び利用数の情報が更新される。
【０２４８】
詳しくは、利用画面・帳票として削除画面・帳票のフォームＩＤが記憶されているキー定義データ、データ項目については、削除画面・帳票のフォームＩＤを利用画面・帳票から削除し、削除したフォームＩＤの個数分だけ利用数の情報をデクリメントして更新記憶する。具体的には、現利用数がｎ２であり、今回削除される画面・帳票のうち、ｄ２個（ここではｄ２＝１）の画面・帳票に当該キー定義データ又はデータ項目が含まれている場合は、新利用数としてｎ２＝ｎ２−ｄ２が記憶される。
【０２４９】
例えば、「商品」エンティティには、キー定義データとして「商品ＣＤ」、データ項目として「品名」、「単位」、「受注単価」、「規格」、「発注単価」が含まれており（図３３参照）、このうち、「商品ＣＤ」、「品名」、「単位」、「受注単価」、「規格」の利用画面・帳票の情報に「１１８」（削除画面である「受注計上」画面のフォームＩＤ）が含まれており、「発注単価」の利用画面・帳票の情報には「１１８」は含まれていない。また、「商品ＣＤ」、「品名」、「単位」、「規格」の利用数として「２」が記憶されており、「受注単価」、「発注単価」の利用数として「１」が記憶されている。
【０２５０】
従って、ここでは、「商品ＣＤ」、「品名」、「単位」、「受注単価」、「規格」の利用画面・帳票の情報から「１１８」が削除される。また、これら「商品ＣＤ」、「品名」、「単位」、「受注単価」、「規格」の利用数がデクリメントされ、「商品ＣＤ」、「品名」、「単位」、「規格」の新利用数として「１」が記憶され、「受注単価」の新利用数として「０」が記憶される。なお、「発注単価」には利用画面・帳票の情報として「１１８」（削除画面である「受注計上」画面のフォームＩＤ）が含まれていないので、利用画面・帳票及び利用数の情報は変更されない。
【０２５１】
次のステップ３１２では、この利用数の情報が０と比較され、該正規化エンティティを構成しているキー定義データ及びデータ項目それぞれについて、削除画面・帳票以外の画面・帳票にも属しているか否かが判断される。利用数が０の場合（ｎ２＝０）場合は、該キー定義データ又はデータ項目が削除画面・帳票にのみ属していると判断されて、ステップ３１４に進む。
【０２５２】
ステップ３１４では、アイデンティファイア・アトリビュート仕様２６に記憶されている該正規化エンティティのエンティティ情報から、該キー定義データ又はデータ項目に関する情報が全て削除されて、ステップ３１６に進む。
【０２５３】
一方、利用数が０ではない場合（ｎ２＞０）場合は該キー定義データ又はデータ項目は削除画面・帳票以外にも属していると判断されて、そのままステップ３１６に進む。
【０２５４】
ステップ３１６では、ステップ３０８で抽出した全てのキー定義データ及びデータ項目に対して、上記の処理を行ったか否かが判断され、未処理のキー定義データ又はデータ項目がある場合は、ステップ３１０に戻る。
【０２５５】
これにより、例えば、「商品」エンティティの場合は、「受注単価」の利用数が０であるので、ステップ３１４において、「商品」エンティティのエンティティ情報から「受注単価」に関する情報が全て削除され、「商品ＣＤ」、「品名」、「単位」、「規格」、「発注単価」の利用数が１であるので、これらの情報はそのまま残される。
【０２５６】
ステップ３０８で抽出した全てのキー定義データ及びデータ項目に対して処理が行われたら、ステップ３１８に進む。
【０２５７】
ステップ３１８では、ステップ３００で抽出した全ての正規化エンティティに対して上記の処理が行われたかが判断され、未処理の正規化エンティティがある場合は、ステップ３０２に戻る。これにより、アイデンティファイア・アトリビュート仕様２６から、「受注」、「得意先」、「納品先」、「受注明細」エンティティに対応するエンティティ情報が削除される。また、「商品」エンティティのエンティティ情報から「受注単価」データ項目に関する情報が削除される。
【０２５８】
ステップ３００で抽出した全ての正規化エンティティに対して処理を行ったら、ステップ３２０に進み、現在アイデンティファイア・アトリビュート仕様２６に登録されている正規化エンティティのエンティティ情報に基づいて、対応マトリックステーブル２８が作成される。これにより、前回作成した対応マトリックステーブル２８（図３１参照）から、削除画面・帳票に対応する列と、エンティティ情報が削除された正規化エンティティの列が削除された対応マトリックステーブル２８が作成される（図２８参照）。また、各正規化エンティティに対して、詳細対応マトリックスも作成される。このとき、「商品」エンティティのに対しては、前回作成した詳細対応マトリックステーブル２９から「受注単価」の行が削除された詳細対応マトリックステーブル２９が作成される。
【０２５９】
次のステップ３２２では、削除画面・帳票の関係マトリックステーブル３０（図３２参照）からリレーションシップを抽出するとともに、この削除画面・帳票の関係マトリックステーブル３０が削除される。次いで、ステップ３２４では、画面図２４（Ｂ）に示されるリレーションシップの変更処理が行われる。
【０２６０】
リレーションシップ変更処理では、抽出されたリレーションシップが、前回ＥＲモデル図作成時から削除されたのか追加されたのかを判断する（ステップ２４０）。ここでは、画面・帳票の削除に伴って、抽出されたリレーションシップが削除されたので、ステップ２６０に進む。
【０２６１】
ステップ２６０では、該リレーションシップのリレーションシップ数をデクリメントして更新記憶する。具体的には、該リレーションシップのリレーションシップ数がｋと記憶されている場合は、新リレーションシップ数としてｋ＝ｋ−１が記憶される。
【０２６２】
次のステップ２６２では、このリレーションシップ数を０と比較し、該エンティティ間のリレーションシップが削除画面・帳票以外の画面・帳票にも存在しているか否かを判断する。
【０２６３】
リレーションシップ数が０の場合（ｋ＝０）は、該エンティティ間のリレーションシップが削除画面・帳票のみに存在すると判断して、ステップ２６４に進む。ステップ２６４では、前回作成したＥＲモデル図３２に対して、該エンティティ間を接続する接続線を削除させ、図２３に戻る。
【０２６４】
一方、リレーションシップ数が０ではない場合（ｋ＞０）は、該エンティティ間のリレーションシップが削除画面・帳票以外の画面・帳票にも存在していると判断し、そのまま図２３に戻る。
【０２６５】
図２３に戻ると、ステップ３２２で抽出した全リレーションシップに対してステップ３２４のリレーションシップ変更処理を行ったか否かを判断し（ステップ３２６）、未処理のリレーションシップがある場合には、ステップ３２４に戻り、次のリレーションシップに対してリレーションシップ変更処理を行う。
【０２６６】
ステップ３２２で抽出した全リレーションシップに対してリレーションシップ変更処理が行われると、画面・帳票の追加処理は終了される。
【０２６７】
このように画面・帳票の削除に伴って削除された該画面・帳票の全リレーションシップに対して、リレーションシップ変更処理（ステップ３２４）を繰り返し行うことにより、「売上計上」画面の削除に基づいて修正されたＥＲモデル図３２を得ることができる。このＥＲモデル図３２は、当然ながら、「発注計上」画面を正規化設計処理対象の画面に指示して、前述の正規化設計処理を行って作成されるたＥＲモデル図３２と同一になる（図２６参照）。
【０２６８】
上記のように、本実施の形態では、各正規化エンティティ、キー定義データ、データ項目について、利用画面・帳票の情報（フォームＩＤ）及び利用数の情報が記憶され、画面・帳票の追加や削除に度に、最新情報に更新されるようになっている。また、エンティティ間のリレーションシップ毎に、リレーションシップ数が記憶され、画面・帳票の追加や削除に度に、最新情報に更新されるようになっている。画面・帳票の削除が指示された場合には、記憶されている最新の利用数とリレーションシップ数の情報に基づいて、削除するエンティティやリレーションシップが自動的に決定されるので、画面・帳票の削除に係らず常に正確にＥＲモデル図を得ることができる。
【０２６９】
また、各正規化エンティティ、キー定義データ、データ項目の利用画面・帳票及び利用数の情報、及びエンティティ間のリレーションシップ数を記憶しておくことにより、画面・帳票の内容が変更された場合にも対応することができる。
【０２７０】
例えば、画面・帳票の内容が変更されて、新たに画面・帳票内データ項目が追加された場合には、該新画面・帳票内データ項目を抽出した後、この新画面・帳票内データ項目を処理対象として、また、追加画面・帳票を内容変更された画面・帳票に代えて、前述の画面・帳票の追加処理（図２３参照）のステップ２０４以降の処理を行えばよい。
【０２７１】
また、画面・帳票の内容が変更されて、画面・帳票内データ項目が削除された場合には、削除された画面・帳票内データ項目（キー定義データ又はデータ項目）と、この画面・帳票内データ項目が属する正規化エンティティを抽出し、この画面・帳票内データ項目の削除が、当該画面から抽出された正規化エンティティを削除するものである否かを判断する。
【０２７２】
詳しくは、抽出された正規化エンティティを構成しているキー定義データ及びデータ項目の利用画面・帳票の情報を参照して、当該正規化エンティティを構成しているキー定義データ及びデータ項目の中に、削除される画面・帳票内データ項目以外にも、内容変更された画面・帳票に属するキー定義データ又はデータ項目が存在するか否かを判断し、存在しない場合は、当該画面から抽出された正規化エンティティを削除するものであると判断する。なお、存在する場合は、当該画面からキー定義データ又はデータ項目を削除するものであると判断する。
【０２７３】
内容変更された画面・帳票から正規化エンティティを削除する場合は、当該正規化エンティティと、削除された画面・帳票内データを処理対象として、また、削除画面・帳票を内容変更された画面・帳票に代えて、前述の画面・帳票の削除処理（図３４参照）のステップ３０２以降の処理を行えばよい。
【０２７４】
内容変更された画面・帳票からキー定義データ又はデータ項目を削除する場合は、削除された画面・帳票内データを処理対象として、また、削除画面・帳票を内容変更された画面・帳票に代えて、前述の画面・帳票の削除処理（図３４参照）のステップ３１０、３１２、３１４、３１６の処理を行なった後、ステップ３２０以降の処理を行えばよい。
【０２７５】
これにより、画面・帳票の内容変更に基づいて、利用画面・帳票の情報（フォームＩＤ）及び利用数の情報が更新されて、対応マトリックスの修正、関係マトリックスの追加、削除、修正等が行われ、ＥＲモデル図３２を修正することができる。
【０２７６】
また、図２４（Ｂ）で示したリレーションシップの変更処理は、ユーザによって、関係マトリックステーブル画面６４の削除ボタン６８が押下されて、不要なリレーションシップが削除される場合にも、同様に実施される。
【０２７７】
なお、上記で説明した画面・帳票の追加処理は、一例として示したものであり、これに限定されるものではない。正規化エンティティ、キー定義データ、データ項目の利用数、及びエンティティ間のリレーションシップ数を用いて、画面・帳票の追加、削除に対応することが本質である。また、画面・帳票の内容変更に基づく処理についても同様である。
【０２７８】
（ＥＲモデル図の統合）
処理対象の画面・帳票数が膨大であるため、複数のユーザで処理対象の画面・帳票を分担して前述の正規化設計処理を行った後で、各ユーザが作成したＥＲモデル図３２を統合する等、複数のＥＲモデル図３２を統合する必要が生じた場合には、図３５に示されるＥＲモデル図の統合処理がＣＰＵ１４により自動的に行われる。
【０２７９】
このＥＲモデル図の統合処理は、ユーザによって図２におけるメイン画面４０内の「編集」メニューボタン４４が選択され、プルダウンメニュー４８から「ＥＲモデル図の統合」が選択されることにより開始される。
【０２８０】
なお、以下では、具体的に、前述の正規化設計処理で例に用いた図５２〜図６３（フォームＩＤ：１０１〜１１２）に示される画面に基づいて作成されたＥＲモデル図３２と、図６４〜図６７（フォームＩＤ：１１３〜１１６）に示される画面に基づいて作成されたＥＲモデル図３２とを統合するように指示された場合について説明する。
【０２８１】
図３６には、図５２〜図６３（フォームＩＤ：１０１〜１１２）に示される画面（計１２画面）に基づいて作成されたＥＲモデル図３２が示されており、図３７にはこのときの対応マトリックステーブル画面５４が示されている。また、図３８には、図６４〜図６７（フォームＩＤ：１１３〜１１６）に示される画面（計４画面）に基づいて作成されたＥＲモデル図３２が示されており、図３９にはこのときの対応マトリックステーブル画面５４が示されている。
【０２８２】
ＥＲモデル図の統合処理では、図３５に示されるように、まず、ユーザによって統合するように指示された各ＥＲモデル図３２の正規化エンティティを統合する（ステップ４００）。詳しくは、まず、一方のＥＲモデル図３２の正規化エンティティをアイデンティファイア・アトリビュート仕様２６に正規化エンティティとして登録し、次に他方のＥＲモデル図３２の正規化エンティティを順番に登録していき、登録済みの一方のＥＲモデル図３２の正規化エンティティと同一、或いは密接に関連しているキー定義データを持つ正規化エンティティが存在した場合には、それらを一つのエンティティにまとめて重複を排除する。このとき、該重複正規化エンティティの利用画面のフォームＩＤ、利用数等のエンティティ情報もまとめられる。
【０２８３】
例えば、「施主」エンティティは、図３７、図３９に示されるように、両方のＥＲモデル図３２の正規化エンティティ内に存在しており、図３６、図３８に示されているように、そのキー定義データが共に「施主コード」であるため、１つにまとめられる。また「設計」エンティティも両方のＥＲモデル図３２の正規化エンティティ内に存在しており、そのキー定義データが共に「設計番号」であるため、１つにまとめられる。
【０２８４】
すなわち、この正規化エンティティの統合処理によって、２個の正規化エンティティ（「施行」エンティティと「設計」エンティティ）の重複が排除されることにより、図３７の対応マトリックステーブル画面５４（対応マトリックステーブル２８）に示されている１６個の正規化エンティティと、図３９の対応マトリックステーブル画面５４（対応マトリックステーブル２８）に示されている８個の正規化エンティティは、２２個（１６＋８−２）の正規化エンティティに集約される。この正規化エンティティの統合処理により、前述の図９と同様の対応マトリックステーブル２８が作成される。
【０２８５】
次に、各ＥＲモデル図作成時のリレーションシップ（関係マトリックステーブル３０）を参照して、ステップ４００の統合処理により集約された正規化エンティティ間のリレーションシップを作成する（ステップ４０２）。このとき、各ＥＲモデル図作成時に画面・帳票毎にエンティティ間のリレーションシップが作成されているので、正規化エンティティの統合処理において１つにまとめられた「施主」エンティティと「設計」エンティティが関連する部分のリレーションシップだけ考慮し、他のエンティティ間のリレーションシップはそのままコピーすればよい。
【０２８６】
次に、作成されたリレーションシップに基づいて、統合ＥＲモデル図が作成される（ステップ４０４）。これにより、図３６のＥＲモデル図３２と図３８のＥＲモデル図３２を統合したＥＲモデル図３２（統合ＥＲモデル図）が作成される。なお、この統合ＥＲモデル図は、前述の図１３のＥＲモデル図３２と同様になる。
【０２８７】
このように、ＥＲモデル図３２を作成したときに、画面・帳票毎に関係マトリックステーブル３０（エンティティ間のリレーションシップ）をデータベース１６に各々格納（記憶）しておき、統合ＥＲモデル図を作成するときに、この情報を使用することにより、複数のＥＲモデル図を統合した統合ＥＲモデル図を簡単に作成することができる。
【０２８８】
なお、画面・帳票が追加、削除、或いは内容変更された場合は、前述のように、画面・帳票の追加、削除、或いは内容変更に基づいて、利用画面・帳票の情報（フォームＩＤ）及び利用数の情報が更新されて、対応マトリックステーブル２８の修正、関係マトリックステーブル３０の追加、削除、修正等が行われるので、上記のＥＲモデル図の統合処理によって、画面・帳票の追加、削除、或いは内容変更に基づいて修正された統合ＥＲモデル図を得ることができる。
【０２８９】
（ＥＲモデル図の抽出）
データベースを一括管理するために業務に携わる全部門を対象としてＥＲモデル図３２を作成後、部門毎にデータベースを管理することに変更になった等、作成したＥＲモデル図３２（以下、「全体ＥＲモデル図」という）から特定の画面・帳票の部分を抽出する（以下、抽出したＥＲモデル図のことを「抽出ＥＲモデル図」という）必要が生じた場合には、図４０に示されるＥＲモデル図の抽出処理がＣＰＵ１４により自動的に行われる。
【０２９０】
このＥＲモデル図の抽出処理は、ユーザによって図２におけるメイン画面４０内の「編集」メニューボタン４４が選択され、プルダウンメニュー４８から「ＥＲモデル図の抽出」が選択されることにより開始される。
【０２９１】
なお、以下では、具体的に、前述の正規化設計処理で例に用いた図５２〜図６７（フォームＩＤ：１０１〜１１６）に示される画面に基づいて作成したＥＲモデル図３２（全体ＥＲモデル図）から、図６４〜図６７（フォームＩＤ：１１３〜１１６）の画面に基づく部分を抽出し、抽出ＥＲモデル図を作成する場合について説明する。
【０２９２】
ＥＲモデル図の抽出処理では、図４０に示されるように、まず、ユーザによって抽出するように指示された各画面（以下、「抽出画面」という）の正規化エンティティを抽出する（ステップ５００）。詳しくは、全体ＥＲモデル作成時の対応マトリックステーブル２８を参照し（図９参照）、各抽出画面の列において「○」印が表示されている正規化エンティティが、該抽出画面に属する正規化エンティティと判断され、この正規化エンティティが抽出される。
【０２９３】
具体的には、
フォームＩＤ：１１３からは、設計、決済、入札、決裁者社員、工事
フォームＩＤ：１１４からは、入札
フォームＩＤ：１１５からは、施主、決済、工事、作業所、工事社員
フォームＩＤ：１１６からは、作業所
の正規化エンティティがそれぞれ抽出される。
【０２９４】
次に、この抽出した正規化エンティティを統合する（ステップ５０２）。詳しくは、抽出した正規化エンティティのエンティティ情報を順次登録してゆき、後の正規化エンティティに登録した正規化エンティティと同一の正規化エンティティが存在した場合には、それらを１つにまとめ重複を排除する。このとき、該エンティティの利用画面のフォームＩＤ、利用数等のエンティティ情報もまとめる。
【０２９５】
具体的には、フォームＩＤ：１１３とフォームＩＤ：１１４には「入札」エンティティが含まれるため、これらが１つにまとめられる。同様に、フォームＩＤ：１１３とフォームＩＤ：１１５の「決済」エンティティ、「工事」エンティティもそれぞれ１つにまとめられる。また、フォームＩＤ：１１５とフォームＩＤ：１１６の「作業所」エンティティも１つにまとめられる。抽出した正規化エンティティの統合結果に基づいて対応マトリックステーブル２８が作成される。なお、この対応マトリックステーブル２８は、図３９で示した対応マトリックステーブル画面５４の対応マトリックステーブル２８と同様になる。
【０２９６】
次に、各ＥＲモデル図作成時のリレーションシップ（関係マトリックステーブル３０）を参照して、ステップ５０２の統合処理により集約された正規化エンティティ間のリレーションシップを作成する（ステップ５０４）。続いて、作成されたリレーションシップに基づいて、統合ＥＲモデル図が作成される（ステップ５０６）。これにより、図１３の全体ＥＲモデル図から図６４〜図６７（フォームＩＤ：１１３〜１１６）の画面に基づく部分を抽出した抽出ＥＲモデル図が作成される。なお、この抽出ＥＲモデル図は、図３８で示したＥＲモデル図３２と同様になる。
【０２９７】
このように、全体ＥＲモデル図３２を作成したときに、画面・帳票毎に関係マトリックステーブル３０（エンティティ間のリレーションシップ）をデータベース１６に格納（記憶）しておき、抽出ＥＲモデル図を作成するときに、この情報を使用することにより、簡単に任意の画面・帳票に基づいて抽出した抽出ＥＲモデル図を簡単に作成することができる。
【０２９８】
なお、画面・帳票が追加、削除、或いは内容変更された場合は、前述のように、画面・帳票の追加、削除、或いは内容変更に基づいて、利用画面・帳票の情報（フォームＩＤ）及び利用数の情報が更新されて、対応マトリックステーブル２８の修正、関係マトリックステーブル３０の追加、削除、修正等が行われるので、上記のＥＲモデル図の抽出処理によって、画面・帳票の追加、削除、或いは内容変更に基づいて修正された抽出ＥＲモデル図を得ることができる。
【０２９９】
（部分ＥＲモデル図の作成）
正規化設計されたデータベースに基づいてＤＢＭＳ（Data Base Management System）を実際に構築する場合、一般に各画面・帳票毎にプログラム化される。全体ＥＲモデル図３２を各画面・帳票毎に切り出して（以下、切り出したＥＲモデル図のことを「部分ＥＲモデル図」という）、プログラム仕様書の代わりに用いる場合には、部分ＥＲモデル図の作成処理がＣＰＵ１４により自動的に行われる。
【０３００】
この部分ＥＲモデル図の作成処理は、ユーザによって図２におけるメイン画面４０内の「編集」メニューボタン４４が選択され、プルダウンメニュー４８から「部分ＥＲモデル図作成」が選択されることにより開始される。
【０３０１】
部分ＥＲモデル図の作成処理では、全体ＥＲモデル図作成時に画面・帳票毎に作成され、データベース１６に格納（記憶）された関係マトリックステーブル３０のうち、ユーザによって部分ＥＲモデル図を作成するように指示された画面・帳票の関係マトリックステーブル３０を読み出す。全体ＥＲモデル図３２から、読み出した関係マトリックステーブル３２で表示されているエンティティと、リレーションシップに対応する接続線とを切り出す（抽出する）。これにより、指示された画面・帳票の部分ＥＲモデル図が得られる。
【０３０２】
作成された部分ＥＲモデル図の一例として、図４１には、前述の正規化設計処理で例に用いた図５３の「担当者」画面（フォームＩＤ：１０２）に基づく部分ＥＲモデル図（Ａ）と、図６１「設計見積」画面（フォームＩＤ：１１０）に基づく部分ＥＲモデル図（Ｂ）が示されている。図４１からも分かるように、部分ＥＲモデル図からは、該画面・帳票に属するエンティティ、エンティティ間の関係、各エンティティのキー定義データとデータ項目等の情報を得ることができ、概念設計のプログラム仕様書として利用することができる。
【０３０３】
ユーザは、この部分ＥＲモデル図に基づいて、該画面・帳票におけるキー項目（キー定義データ、参照キー）にＣＲＵＤ（CREATE,READ,UPDATE,DELETE）条件、データ項目の機能条件（データ値、前提条件、セキュリティ、計算式等）を定義することにより、各画面・帳票のプログラム化することができる。
【０３０４】
このように、全体ＥＲモデル図３２を作成したときに、画面・帳票毎に関係マトリックステーブル３０（エンティティ間のリレーションシップ）をデータベース１６に格納（記憶）しておき、部分ＥＲモデル図を作成するときに、この情報を使用することにより、簡単に画面・帳票単位の部分ＥＲモデル図を作成することができる。
【０３０５】
また、全体ＥＲモデル図３２作成用の情報と同一の情報を用いることにより、全体ＥＲ図３２に変更があった場合、この変更に伴って、部分ＥＲモデル図も自動的に変更することができる。
【０３０６】
詳しくは、画面・帳票が追加、削除、或いは内容変更された場合は、前述のように、画面・帳票の追加、削除、或いは内容変更に基づいて、利用画面・帳票の情報（フォームＩＤ）及び利用数の情報が更新されて、対応マトリックステーブル２８が修正され、関係マトリックステーブル３０の追加、削除、修正等が行われてデータベース１６に格納（更新記憶）される。上記の部分ＥＲモデル図の作成処理では、この更新記憶された関係マトリックステーブル３０が用いられるので、画面・帳票の追加、削除、或いは内容変更に基づいて修正された部分ＥＲモデル図を得ることができる。
【０３０７】
（機能仕様書の場合）
上記では、画面・帳票を処理対象とした正規化設計処理や編集処理について説明したが、本発明はこれに限定されるものではなく、例えば機能仕様書を処理対象とすることもできる。以下、正規化設計処理の処理対象として機能仕様書が指示され、この機能仕様書を基にＥＲモデル図を作成する場合について、詳しく説明する。
【０３０８】
図４２には、機能仕様書の一例として、「信託報酬引落額」機能仕様書の例が示されている。図４２に示されるように、機能仕様書は業務で用いられる各種の項目を定義するためのものであり、データ項目間の演算式が記されている。
【０３０９】
このような機能仕様書が処理対象として指示されると、ＣＰＵ１４は自動的に、機能仕様書をＥＲモデルデータベース設計ツールに移動し（取り込み）、該機能仕様書内にどのようなデータが含まれているか分析し、データ項目と目される部分に下線を引いてモニタ３６に表示する。
【０３１０】
ユーザはこの表示結果を確認し、必要であればワープロ機能等を用いて下線を修正し、ＯＫである場合は、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によって、ＯＫを示すコマンドを入力する。ＯＫを示すコマンドが入力されると、ＣＰＵ１４は下線が引かれた部分を機能仕様書内データ項目として抽出するとともに、前述の画面・帳票を処理対象とした場合と同様に、各機能仕様書にフォームＩＤを付与し、抽出結果（抽出された機能仕様書内データ項目）をフォーム・データ項目表示枠５０に表示する。
【０３１１】
ここで、図４２に示されている「信託報酬引落額」機能仕様書の２行目と６行目に「解約口数（証券分）」が存在するように、１つの機能仕様書の中に、同一の機能仕様書内データ項目（以下、「重複データ項目」という）が存在することがある。ＣＰＵ１４は、機能仕様書内データ項目を抽出する際に、重複データ項目を１つにまとめて、フォーム・データ項目表示枠５０には重複がないように機能仕様書内データ項目を表示させるようになっている（例えば、機能仕様書の先頭部分から順次機能仕様書内データ項目をフォーム・データ項目表示枠５０に表示させていき、既に表示されている機能仕様書内データ項目と同一の機能仕様書内データ項目についてはその表示をキャンセルする）。また、このとき、機能仕様書の内容変更に対応するために、各機能仕様書内データ項目について、機能仕様書上での列番号、行番号とともに、重複個数（Ｎｋ）を記憶しておくようになっている。
【０３１２】
これにより、例えば「信託報酬引落額」機能仕様書の場合、図４３に示されるように、抽出された機能仕様書内データ項目がフォーム・データ項目表示枠５０に重複なく表示される。
【０３１３】
このようにして抽出した機能仕様書内データ項目をフォーム・データ項目表示枠５０に表示させると、次に、ユーザにこれで良いか否かの確認を促す。ユーザは必要であれば修正を施した後、入力・操作装置３４のキーボードに備えられているＥｎｔｅｒキーを押下する等によってＯＫを示すコマンドを入力する。ＯＫを示すコマンドが入力されると、前述の画面・帳票を処理対象とした場合と同様に、仮エンティティの作成処理、正規化エンティティの作成処理、対応マトリックスの作成処理、リレーションシップの作成処理を順番に行って、ＥＲモデル図３２を作成する。これにより、機能仕様書に基づいたＥＲモデル図３２を作成することができる。また、各種の編集処理についても、前述の画面・帳票を処理対象とした場合と同様に行うことができる。
【０３１４】
次に、ＥＲモデル図作成後、機能仕様書の内容が変更された場合について説明する。機能仕様書に新たに記述が追加された場合には、新規記述部分のデータ項目と目される部分に下線を引いてモニタ３６に表示する。必要に応じてユーザが下線を修正した後、下線部分を機能仕様書内データ項目として抽出し、該機能仕様書のフォーム・データ項目表示枠５０の表示を更新する。
【０３１５】
詳しくは、新たに抽出された機能仕様書内項目データが、前回データ項目抽出処理時に抽出された機能仕様書内データ項目と異なる場合は、新規機能仕様書内項目データとして、該機能仕様書内項目データをフォーム・データ項目表示枠５０に追加表示し、以降の処理（仮エンティティの作成処理以降の処理）では、この項目に対応する内容が追加される。新たに抽出された機能仕様書内データが、前回データ項目抽出処理時に抽出された機能仕様書内データ項目と同一である場合は、重複データ項目として処理する。すなわち、重複データ項目として機能仕様書上での該機能仕様書内データ項目の列番号、行番号を追加記憶し、新規の重複データ項目の個数（ｍ）を重複個数（Ｎｋ）に加算して（Ｎｋ＝Ｎｋ＋ｍ）更新記憶し、フォーム・データ項目表示枠５０には追加表示しない。
【０３１６】
一方、機能仕様書の一部内容が削除された場合には、削除部分に含まれる機能仕様書内データ項目が重複データ項目ではない場合（すなわち重複個数Ｎｋ＝１）は、この機能仕様書内データ項目のデータを削除し、該機能仕様書内データ項目をフォーム・データ項目表示枠５０から削除する。すなわち、以降の処理ではこの機能仕様書内データ項目に対応する内容が削除される。また、削除部分に含まれる機能仕様書内データ項目が重複データ項目である場合（すなわち重複個数Ｎｋ＞１）は、該機能仕様書内データ項目をフォーム・データ項目表示枠５０から削除せずに、削除する重複データ項目の個数（ｍ）を重複個数Ｎｋから減じて（Ｎｋ＝Ｎｋ―ｍ）更新記憶する。
【０３１７】
このように、各重複データ項目の情報（機能仕様書上での列番号、行番号、重複個数）を記憶しておくことにより、機能仕様書の内容変更についても簡単に対応することができる。
【０３１８】
（大量画面・帳票を扱うための機能）
ところで、実際にＥＲモデル図を作成する場合、１００〜２００以上にもなる大量の画面・帳票を処理する必要がある。このため、データベース設計システム１０には、画面・帳票数が大量になっても、ユーザが容易に作業できる環境を提供する機能が備えられている。次にこの機能について説明する。
【０３１９】
▲１▼  フォーム・データ項目表示枠及びエンティティ表示枠のサイズ自動調整機能
データベース設計システム１０には、フォーム・データ項目表示枠５０及びエンティティ表示枠５３のサイズ自動調整機能が設けられている。
【０３２０】
機能設定画面（図示省略）において、このサイズ自動調整機能がＯＦＦに設定されている場合は、モニタ３６に表示したり、プリント出力装置３８から出力する際のフォーム・データ項目表示枠５０又はエンティティ表示枠５３は、予め設定されている所定のサイズで固定される。このとき、当該所定のサイズのフォーム・データ項目表示枠５０又はエンティティ表示枠５３内に表示しきれない文字がある場合は記号、例えば「…」、データ項目がある場合は記号、例えば「▼」を表示して、ユーザに隠れ文字や隠れデータ項目があることを報知するようになっている（図４４（Ａ）参照）。
【０３２１】
ユーザは、必要に応じて、入力・操作装置３４を操作することによって、フォーム・データ項目表示枠５０又はエンティティ表示枠５３のサイズをマニュアルで変更したり、フォーム・データ項目表示枠５０又はエンティティ表示枠５３内の表示をスクロールさせる等して、隠れ文字や隠れデータ項目を表示させる。この場合、処理対象の画面・帳票数が大量になると、１つずつ隠れ文字や隠れ項目の有無を確認してマニュアルでサイズ変更作業を行ったり、スクロール作業を行うのは面倒である。
【０３２２】
これに対して、機能設定画面（図示省略）において、このサイズ自動調整機能がＯＮに設定されていると全ての文字が隠れることなく表示されるように、フォーム・データ項目表示枠５０又はエンティティ表示枠５３のサイズを自動調整する（図４４（Ｂ）参照）。
【０３２３】
詳しくは、フォーム・データ項目表示枠５０又はエンティティ表示枠５３に表示する画面・帳票又はエンティティの名称、キー定義データ、データ項目の文字数をカウントし、このカウント結果に基づいて、フォーム・データ項目表示枠５０又はエンティティ表示枠５３の横方向のサイズを決定して、フォーム・データ項目表示枠５０又はエンティティ表示枠５３の横方向のサイズを自動的に変更する。また、フォーム・データ項目表示枠５０又はエンティティ表示枠５３に表示するデータ項目数をカウントし、このカウント結果に基づいてフォーム・データ項目表示枠５０又はエンティティ表示枠５３の縦方向のサイズを決定し、フォーム・データ項目表示枠５０又はエンティティ表示枠５３の縦方向のサイズを自動的に変更する。
【０３２４】
このように、サイズ自動調整機能を設けることにより、ユーザがフォーム・データ項目表示枠５０又はエンティティ表示枠５３の内容を確認するために、１００〜２００以上にもなる画面・帳票のフォーム・データ項目表示枠５０又はエンティティ表示枠５３のサイズを１つずつ調整する作業が不要となる。
【０３２５】
▲２▼  部分ＥＲモデル図の自動集約機能
データベース設計システム１０には、部分ＥＲモデル図の自動集約機能が設けられている。機能設定画面（図示省略）において、この自動集約機能がＯＦＦに設定されていると、部分ＥＲモデル図は、全体ＥＲモデル図３２から切り出した（抽出した）状態でモニタ３６に表示されたり、プリント出力装置３８から出力される。図４５には、図１３で示した全体ＥＲモデル図３２から、フォームＩＤが１１０の画面の部分ＥＲモデル図を作成した例が示されている。図４５からも分かるように、空白部分、すなわち無駄なスペースが多い部分ＥＲモデル図となる。
【０３２６】
この場合、処理対象の画面・帳票数が１００〜２００以上と大量になって、全体ＥＲモデル図３２のサイズが大きくなると、益々無駄なスペースが増え、部分ＥＲモデル図のサイズが大きくなってしまう。部分ＥＲモデル図のサイズを小さくする場合は、入力・操作装置３４を操作することによって、部分ＥＲモデル図上のエンティティ（エンティティ表示枠５３）の配置位置をマニュアルで変更しなければならず面倒である。
【０３２７】
これに対して、機能設定画面（図示省略）において、この自動集約機能がＯＮに設定されていると、部分ＥＲモデル図を作成する際に、部分ＥＲモデル図を集約して表示する領域（以下、「表示領域」）を、マウス等の入力・操作装置３４を操作して所望のサイズに指定することができる。全体ＥＲモデル図３２から切り出した（抽出した）エンティティ（エンティティ表示枠５３）は、この指定された表示領域内に、自動的に詰めて配置される（図４６参照）。
【０３２８】
このように、自動集約機能を設けることにより、自動的に所望のサイズの表示領域内に部分ＥＲモデル図が収めることができる。これにより、例えば、部分ＥＲモデル図を他の情報と同時に並べて表示（又は出力）する（例えば、複数の部分ＥＲモデル図の同時表示、当該部分ＥＲモデル図と対応するフォーム・データ項目表示枠５０とを同時表示）ことも可能となる。
【０３２９】
▲３▼画面・帳票とエンティティの整合性検証機能
実際にＥＲモデル図を作成する場合、必要に応じて、マニュアルでエンティティを追加したり、画面・帳票に画面・帳票内データ項目を追加することがある。
例えば、正規化エンティティの登録後、登録したエンティティをモニタ３６に表示してユーザに確認を求めるが（図３のステップ１１０参照）、このとき必要であれば、ユーザは、入力・操作手段３４を操作することによって、新規のエンティティをマニュアルで追加し、当該マニュアル追加したエンティティに対応する画面・帳票内データ項目を、何れかの画面・帳票に追加する。
【０３３０】
このような場合、エンティティや画面・帳票内データ項目を追加した後、画面・帳票と登録した正規化エンティティが合っているか否かを確認する作業が必要とされるが、処理対象の画面・帳票数が１００〜２００以上にもなると、この確認作業は非常に手間がかかり、また確認ミスも起こし易い。このため、データベース設計システム１０には、画面・帳票と登録した正規化エンティティの整合性を検証する機能が設けられている。
【０３３１】
詳しくは、登録済みの正規化エンティティの情報をマスターファイルとして利用して、各画面・帳票毎に、仮エンティティの作成処理を実行し直す（再仕訳）とともに、対応する登録（正規化）エンティティがない画面・帳票内データ項目（以下、「未登録データ項目」という）を検索して、ユーザに報知する機能が設けられている。本実施の形態では、一例として、フォーム・データ項目表示枠５０をモニタ３６に表示する際に、検索された未登録データ項目を含む画面・帳票のフォーム・データ項目表示枠５０については、当該未登録データ項目をフォーム・データ項目表示枠５０の上位に表示することによって、未登録データ項目をユーザに報知するようになっている（図４７（Ａ）参照）。
【０３３２】
また、登録済みの正規化エンティティの中から、何れの画面・帳票でも使用されないデータ項目（以下、「未使用データ項目」という）を含む正規化エンティティを検索して、ユーザに報知する機能も設けられている。本実施の形態では、エンティティ表示枠５３をモニタ３６に表示する際に、検索された未使用データ項目を含む正規化エンティティのエンティティ表示枠５３については、当該未使用データ項目に未使用であることを示すマーク、例えば「×」印を付けて表示することによって、未使用データ項目をユーザに報知するようになっている（図４７（Ｂ）参照）。
【０３３３】
ユーザは、これらの報知結果に基づいて、未登録データ項目や未使用データ項目を容易に把握することができ、未登録データ項目を正規化エンティティに登録したり、未使用データ項目を画面・帳票に追加する等の作業を行って、未登録データ項目や未使用データ項目を無くし、画面・帳票と登録した正規化エンティティとを整合させることができる。
【０３３４】
▲４▼  データ項目の名称に対するキー定義データ識別情報の付加機能
データベース設計システム１０には、仮エンティティの作成処理（図３のステップ１０４）によって作成された仮エンティティのデータ項目に対して、当該データ項目に対応するキー定義データを識別するための情報（以下、「キー定義データ識別情報」という）を付加する機能が設けられている。
【０３３５】
本実施の形態では、一例として、仮エンティティの作成処理後、ユーザによりＯＫを示すコマンドが入力されたら（ステップ１０６）、各データ項目の名称に、キー定義データ識別情報として、キー定義データの名称或いはその一部が自動的に付加されるようになっている。例えば、キー定義データの名称が「××」、データ項目の名称が「△△」の場合は、データ項目の名称が「××・△△」に変更されるようになっている（図４８参照）。なお、既に、データ項目の名称にキー定義データの名称或いはその一部が含まれている場合は、データ項目の名称は変更しない。
【０３３６】
また、このデータ項目に対するキー定義データ識別情報の付加に伴って、当該データ項目が抽出された画面・帳票の対応する情報（画面・帳票内データ項目の名称）も同時に変更される。
【０３３７】
このように、データ項目の名称にキー定義データ識別情報を付加し、画面・帳票の対応する情報も変更しておくことにより、仮エンティティの作成処理を再度実行する場合に、前回の処理において作成した仮エンティティを自動的に作成する（キー定義データとデータ項目とに自動区分）ことができる。すなわち、２回目以降の仮エンティティの作成処理の処理（作業）時間を短縮することができる。これは、大量の画面・帳票を処理する場合に非常に有効である。
【０３３８】
▲５▼  非正規化機能
データベース１６には、正規化エンティティ単位でアイデンティファイア・アトリビュート仕様２６が格納されており、フォーム・データ項目表示枠５０をモニタ３６に表示する場合、このアイデンティファイア・アトリビュート仕様２６の情報が使用される。すなわち、データベース１６からアイデンティファイア・アトリビュート仕様２６の情報を読み出す場合、正規化エンティティ単位でアクセス可能となっている。
【０３３９】
したがって、画面・帳票を構成している正規化エンティティの個数が増えると、その分だけデータベース１６へのアクセス回数が増え、当該画面・帳票に対応するフォーム・データ項目表示枠５０の表示速度が遅くなってしまう（データベース１６から必要な情報を検索する検索時間が増える）。
【０３４０】
また、実際にＤＢＭＳを構築して運用する場合も、通常は、画面・帳票から入力された画面・帳票内データ項目の各種の情報を正規化エンティティ単位でデータベースに格納したり、読み出したりするため、画面・帳票を構成している正規化エンティティの個数が増えると、データベースへのアクセス回数が増えて処理速度が低下する。
【０３４１】
このため、データベース設計システム１０には、表示用に非正規化したアイデンティファイア・アトリビュート仕様２６を作成して、データベース１６に格納する機能が設けられている。機能設定画面（図示省略）において、この非正規化機能がＯＮに設定されている場合は、画面・帳票毎にＩＳＡＭ（Index Sequential Access Method：索引順次アクセス方式）ファイル的設計で非正規化したエンティティ（以下、「非正規化エンティティ」という）が作成される。
【０３４２】
本実施の形態では、一例として、図４９に示されるように、各画面・帳票を構成しているエンティティをＨＤＲ（ヘッダ）エンティティとＤＴＬ（ディテール）エンティティとに分け、各々キー定義データを１つだけ残し、残りのキー定義データをデータ項目とし、ＨＤＲエンティティを１つにまとめた非正規化エンティティ、及びＤＴＬエンティティを１つにまとめた非正規化エンティティを作成するようになっている。
【０３４３】
このとき、１つだけ残されたキー定義データの名称を変更して、本来の正規化エンティティの名称と作成した非正規化エンティティの名称とが一致しないようにしておく。なお、本実施の形態では、キー定義データ（及び非正規化エンティティ）の名称に「準」の文字が付加されて、自動的にキー定義データの名称が変更されるようになっている。
【０３４４】
この作成した非正規化エンティティのアイデンティファイア・アトリビュート仕様２６をデータベース１６に格納し、フォーム・データ項目表示枠５０をモニタ３６に表示する際には、この非正規化エンティティのアイデンティファイア・アトリビュート仕様２６を用いる。
【０３４５】
これにより、データベース１６へのアクセス回数が減らすことができ、画面・帳票を構成している正規化エンティティの個数が増えても、フォーム・データ項目表示枠５０の表示速度を損なうことがない。
【０３４６】
例えば、図４９に示した例では、「売上計上」画面のフォーム・データ項目表示枠５０を表示する場合、非正規化を行っていないと、正規化エンティティが７つあるので、データベース１６に７回アクセスする必要がある。これに対して、非正規化後は、７つの正規化エンティティが２つの非正規化エンティティにまとめられているので、データベース１６へのアクセス回数は２回で済む。
【０３４７】
このとき、非正規化エンティティのデータ項目を、当該非正規化エンティティにまとめられた正規化エンティティ毎に横線を引いて区分けして、フォーム・データ項目表示枠５０の下部左領域に表示する（図４９（Ｂ）参照）等して、当該非正規化エンティティに含まれる正規化エンティティを示すようになっている。
すなわち、非正規化を行っても、画面・帳票と正規化エンティティの関係を示すことができる。これにより、作成された非正規化エンティティに基づく対応マトリックステーブル２８を容易に作成することができるとともに、画面・帳票が追加、削除、或いは内容変更された場合にも対応できる。
【０３４８】
また、このとき、ユーザが、必要に応じて、作成された非正規化エンティティを分割したり、統合したりするようにしてもよい。このためにも、非正規化エンティティのデータ項目を正規化エンティティ毎に区分けしてフォーム・データ項目表示枠５０に表示すれば、ユーザが当該非正規化エンティティに含まれている正規化エンティティを把握することができ、非正規化エンティティの分割・統合作業が容易になるという効果もある。なお、図４９では、フォーム・データ項目表示枠５０の下部左領域に横線を引いて、非正規化エンティティのデータ項目を正規化エンティティ毎に区分けする例を示したが、当然ながらこれ以外の方法で非正規化エンティティのデータ項目を正規化エンティティ毎に区分けして表示してもよい。
【０３４９】
非正規化エンティティに基づいて、対応マトリックステーブル２８を作成したら、関係マトリックステーブル３０を作成して、ＥＲモデル図３２を作成する。
このＥＲモデル図３２に基づいて、ＤＢＭＳを構築すれば、非正規化エンティティ単位でデータベースにアクセスでき、実際にＤＢＭＳを構築して運用する場合の処理速度の向上を図ることもできる。
【０３５０】
なお、上記では、画面・帳票を構成している正規化エンティティをＨＤＲエンティティとＤＴＬエンティティとに分けて非正規化を行う例を示したが、これに限定されるものではない。複数の正規化エンティティを１つの非正規化エンティティにまとめることが本質である。例えば、１つの画面・帳票を構成している全ての正規化エンティティを１つの非正規化エンティティにまとめるようにしてもよい。また、図５０に示すように、ＤＴＬエンティティの繰返し回数を指定し（図５０は繰り返し回数を３回に指定）、当該指定した繰返し回数分だけデータ項目のセットを備えた非正規化エンティティを作成するようにしてもよい。
【０３５１】
▲６▼分割正規化機能
画面・帳票数が大量となると、１つの正規化エンティティに多数のデータ項目が含まれることが多くなる。実際のＤＢＭＳを構築して運用する場合、データベースに対する書込み・読出しは、前述のように、正規化エンティティ単位で行われるため、正規化エンティティのデータ量が多いと、それだけデータベースへのアクセス時間（特に読出しに要する時間）が長くなってしまう。例えば、「従業員」エンティティが、キー定義データが「従業員番号」であり、データ項目に「従業員名」、「生年月日」、「入社日」、「職務経歴」、「給料」等、従業員に関する多数の項目を含んでいる場合、これに基づいてＤＢＭＳを構築すると、「入社日」のデータのみが必要な場合でも、「従業員名」、「職務経歴」等、他のデータ項目のデータも一緒に読み出すことになる。
【０３５２】
このため、データベース設計システム１０には、正規化エンティティを分割する機能が設けられている。ユーザによりデータ量が多くなる正規化エンティティを指定して分割が指示された場合、当該分割指示された正規化エンティティを画面・帳票単位に分割する（以下、この分割して作成されたエンティティのことを「分割エンティティ」と称す）。このとき、各分割エンティティについて、キー定義データの名称とエンティティの名称とが互いに一致しないようにしておく。
【０３５３】
具体的には、「従業員番号１」、「従業員番号２」、「従業員番号３」のように、各分割エンティティのキー定義データの名称の末尾に、１、２、３…と順に数字番号を付加し、エンティティの名称に、当該分割エンティティが対応する画面・帳票の名称を用いるようになっている。
【０３５４】
従来より、キー定義データの名称に含まれる「番号」、「コード」等を削除して分割エンティティ化するものは存在したが、この場合、分割エンティティ間でキー定義データの名称が同一になるため、識別が困難であった。これに対して、上記のように、分割エンティティ間でキー定義データの名称を非同一にしておくことで、各画面・帳票のフォーム・データ項目表示枠５０を表示した場合に、各分割エンティティを容易に識別できる。
【０３５５】
上記▲５▼、▲６▼の機能は、ＣＰＵ１４によりプログラム的処理により実現される。
従って、ＣＰＵ１４が、本発明の分割・統合手段の機能を担っている。
【０３５６】
最後に、所謂第１乃至第５正規化との対応について述べると、データベース設計システム１０では、所謂第１、第２、第４、第５正規化の処理に対応可能である。
【０３５７】
なお、第１正規化とは、繰返し項目を排除することであり、データベース設計システム１０では、データ項目抽出時にＨＤＲ部分とＤＴＬ部分を区分する際に、自動的に実行される。
【０３５８】
第２正規化とは、キー定義データとそのデータ項目に区分することであり、データベース設計システム１０では、仮エンティティの作成処理時に自動的に実行される。第１、第２正規化の結果が図１７に示したように自動的に表現される。
【０３５９】
第３正規化とは、主キー以外の属性間（データ項目間）の関数従属性（推移関数従属）を排除することであり、データベース設計システム１０では、関数従属性を有するデータ項目を排除せずに、敢えて残すようにしている。
【０３６０】
第４正規化とは、データ項目のみでキー定義データが存在しないものをエンティティ化することであり、データベース設計システム１０では、図８に示したように、キー定義データの存在しないエンティティとして、「営業活動」エンティティ、「設計作業工数」エンティティ「見積作業工数」エンティティ作成する。
【０３６１】
第５正規化とは、結合従属性を含むエンティティ間の関係を３つ以上の射影に損失無く分解することである。上記説明で用いた例はこの第５正規化を実行せずに済む場合であったが、データベース設計システム１０では、リレーションシップの作成処理時に、リソースとリソースのエンティティ間に参照キーが代入されるので、第５正規化が実行可能な場合には自動的に実行される。
【０３６２】
なお、上記では、画面・帳票・機能仕様書が追加、削除、内容変更された場合に、画面・帳票・機能仕様書の追加、削除、内容変更に基づいてＥＲモデル図、統合ＥＲモデル図、抽出ＥＲモデル図、又は部分ＥＲモデル図を修正する場合について説明したが、本発明はこれに限定されるものではない。ＥＲモデル図、統合ＥＲモデル図、抽出ＥＲモデル図、又は部分ＥＲモデル図を修正するとともに、その修正個所の色を変える等によって、修正個所、すなわち修正前の（前回作成した）ＥＲモデル図、統合ＥＲモデル図、抽出ＥＲモデル図、又は部分ＥＲモデル図との差分をユーザに報知するようにしてもよい。
【０３６３】
特に、部分ＥＲモデル図の修正個所からは、ＤＢＭＳを構築するためのプログラムの修正すべき個所、及びその修正内容をユーザが容易に把握することができる。これも画面・帳票を処理する場合を扱う場合に有効である。
【０３６４】
また、上記では、関係マトリックステーブル画面６４の削除ボタン６８を用いて、不必要なリレーションシップを１つずつ削除する場合を例に説明したが、より使い勝手の良いシステムにするために、例えば、図５１に示されるように、列単位でまとめてリレーションシップを削除するための列削除ボタン８０や、行単位でまとめてリレーションシップを削除するための行削除ボタン８２を設け、行や列単位で複数のリレーションシップをまとめて削除できるようにしてもよい。
また、ＣＰＵ１４によって自動的に作成されたときの関係マトリックステーブル３０（初期状態）に戻すための初期化ボタン８４を設ける等によって、必要なリレーションシップを誤って削除してしまった場合に、初期状態に戻すことができるようにしてもよい。
【０３６５】
また、上記では、フォーム・データ項目表示枠５０、エンティティ表示枠５３、対応マトリックステーブル画面５４、詳細対応マトリックス画面６２、関係マトリックステーブル画面６４、ＥＲモデル図３２を各々独立に表示する場合を例に説明したが、本発明はこれに限定されるものではない。これらを組み合わせて同時に表示可能としてもよい。
【０３６６】
特に、フォーム・データ項目表示枠５０とエンティティ表示枠５３とを同時に表示した状態で、対応マトリックステーブル画面５４、関係マトリックステーブル画面６４、ＥＲモデル図３２（特に部分ＥＲモデル図）の何れかを表示するようにするとよい。これにより、ユーザによる対応マトリックステーブル２８、関係マトリックステーブル３０、ＥＲモデル図３２の作成結果が適切であるか否かの確認作業が容易になる。
【０３６７】
また、フォーム・データ項目表示枠５０とエンティティ表示枠５３とを同時表示する際に、マスター関連のものとトランザクション関連のものに分ける等、グループ分けして表示するようにするとよい。具体的には、データベース設計システム１０に、フォームＩＤの番号順又は指定された配置でフォーム・データ項目表示枠５０を整列表示し、正規化エンティティの登録処理を行うフォーム・データ項目表示枠５０を選択し、正規化エンティティの登録処理により新規に登録された正規化エンティティのエンティティ表示枠５３を、当該登録処理において、新規に処理対象としたフォーム・データ項目表示枠５０に隣接配置するようにすればよい。
【０３６８】
これにより、例えば、各フォーム・データ項目表示枠５０のフォームＩＤを付与する際に、マスター関連（リソースを多く含んでいるものをマスター登録）のフォーム・データ項目表示枠５０Mには０〜９９、受注管理に関連するフォーム・データ項目表示枠５０Ｊには１００番台、発注管理に関連するフォーム・データ項目表示枠５０Ｈには２００番台、在庫管理Ｚに関連するフォーム・データ項目表示枠５０には３００番台としておくと、図６８に示すように、自動的にグループ毎（マスター／受注管理／発注管理／在庫管理）に区分けされて、フォーム・データ項目表示枠５０（５０Ｍ／５０Ｊ／５０Ｈ／５０Ｚ）が整列表示される。
【０３６９】
なお、ＣＰＵ１４が自動的にフォーム・データ項目表示枠５０をグループ分けして、上記のようにフォームＩＤの番号を付与してもよいし、ユーザが各フォーム・データ項目表示枠５０に付与するフォームＩＤの番号を指示してもよい。或いは、ユーザがマウス等により各フォーム・データ項目表示枠５０の配置位置を指定することで整列表示されるようにしてもよい。
【０３７０】
このように表示することにより、正規化エンティティの登録処理を行うフォーム・データ項目表示枠５０をグループ単位に選択しやすくなり、ユーザはまずマスター関連のフォーム・データ項目表示枠５０Ｍを処理対象に選択して、正規化エンティティの登録処理を行う。次いで、マスター関連と受注管理関連のフォーム・データ項目表示枠５０Ｍ、５０Ｊを処理対象に選択して、正規化エンティティの登録処理を行う。なお、このとき、処理済のマスター関連のフォーム・データ項目表示枠５０Ｍから抽出された正規化エンティティがマスターとして利用される。
【０３７１】
次に、マスター関連と受注管理関連と発注管理関連のフォーム・データ項目表示枠５０Ｍ、５０Ｊ、５０Ｈを処理対象に選択し、最後に、マスター関連と受注管理関連と発注管理関連と在庫管理関連のフォーム・データ項目表示枠５０Ｍ、５０Ｊ、５０Ｈ、５０Ｚを選択して、同様に正規化エンティティの登録処理を行う。
【０３７２】
上記のような順番でフォーム・データ項目表示枠５０を選択して、正規化エンティティの登録処理を行うと、図６９に示すように、マスター関連のフォーム・データ項目表示枠５０Ｍから抽出された正規化エンティティのエンティティ表示枠５３Ｍが、当該フォーム・データ項目表示枠５０Ｍに隣接して整列表示される。同様に、受注管理関連、発注管理関連、在庫管理関連のフォーム・データ項目表示枠５０Ｊ、５０Ｈ、５０Ｚから抽出された正規化エンティティのエンティティ表示枠５３Ｊ、５３Ｈ、５３Ｚが、当該フォーム・データ項目表示枠５０Ｊ、５０Ｈ、５０Ｚに、各々隣接して整列表示される。
【０３７３】
なお、図６９では、エンティティ表示枠５３Ｊ、５３Ｈ、５３Ｚを整列表示する際に、エンティティタイプ（イベント／リソース）でも区分けするようになっている。また、当然ながら、正規化エンティティの登録処理の実行後は、フォーム・データ項目表示枠５０内の表示も正規化エンティティによる区分に更新されるので、二重線の枠となる。
【０３７４】
このように、グループ分けしてフォーム・データ項目表示枠５０とエンティティ表示枠５３と表示することにより、トランザクション毎に確認作業を行うことができる。また、以降の処理をトランザクション毎に行うことも容易になる。
【０３７５】
なお、本発明は、画面、帳票、機能仕様書の組み合わせを処理対象としてもよい。また、ＩＳＡＭや、ＶＳＡＭ（Virtual Storage Access Method：仮想記憶アクセス方式）のファイル形式のデータファイルを画面・帳票に対応させて、本発明を適用することもできる。
【０３７６】
また、画面・帳票のデータ項目の情報をリポジトリの情報資源管理のためのデータ保存領域に保存してもよい。リポジトリに情報を保存しておくことにより、後日この保存された情報を利用して同様の処理を行なうこともできる。
【０３７７】
また、上記では、データベース設計用の各種プログラム（プログラム１８、２０、２２、２４）をＦＤ、ＣＤ−ＲＯＭ等から読み出して補助記録装置１２にインストールしているが、本発明はこれに限定されるものではない。例えば、有線又は無線のネットワークや、電話回線等の伝送手段により伝送してプログラムをインストールしてもよい。すなわち上記プログラムは、有形の記憶媒体及び伝送手段の少なくとも一方により流通することができる。
【０３７８】
また、処理対象の画面・帳票は、データベース設計システムに直接入力してもよいし、有線又は無線のネットワークや、電話回線等の伝送手段により伝送して、入力するようにしてもよい。当然ながら、ユーザは、データベース設計システムを直接操作するようにしてもよいし、有線又は無線のネットワークや、電話回線等を介してデータベース設計システムと接続された端末側から操作するようにしてもよい。
【０３７９】
【発明の効果】
上記のように本発明は、画面・帳票とともに機能仕様書にも対応してＲＤＢのデータベース正規化設計作業を行うことができ、また、データベース正規化設計作業後の処理対象画面・帳票・機能仕様書の削除並びにＥＲモデル図の統合・削除を効率的且つ正確に行い、生産効率及び品質を上げることができるという優れた効果を有する。さらにＥＲモデル図を作成する際の各種データを有効に表示することもできる。
【図面の簡単な説明】
【図１】本発明の実施形態におけるデータベース設計システムの構成図である。
【図２】本発明の実施形態におけるＥＲモデル図作成ツールの起動時に表示されるメイン画面の一例を示す図である。
【図３】本発明の実施形態における正規化設計処理を示すフローチャートである。
【図４】本発明の実施形態におけるデータ項目抽出時に表示されるフォーム・データ項目表示枠の例であり、（Ａ）は「部門」画面、（Ｂ）は「施行」画面のフォーム・データ項目表示枠の例である。
【図５】本発明の実施形態における仮エンティティ作成時に表示されるフォーム・データ項目表示枠の例であり、（Ａ）は「部門」画面、（Ｂ）は「施行」画面のフォーム・データ項目表示枠の例である。
【図６】仮エンティティ作成時に表示されるフォーム・データ項目表示枠のその他の例であり、（Ａ）はデータ項目抽出時に表示される「施行」画面、（Ｂ）は仮エンティティ作成時に表示される「施行」画面のフォーム・データ項目表示枠の例である。
【図７】本発明の実施形態における仮エンティティ作成時に表示されるエンティティタイプを設定するためのプルダウンメニューの例である。
【図８】本発明の実施形態における正規化エンティティを表示するエンティティ表示枠の例である。
【図９】本発明の実施形態における対応マトリックスが表示される対応マトリックステーブル画面の例である。
【図１０】本発明の実施形態における詳細対応マトリックステーブルが表示される詳細対応マトリックステーブル画面の例であり、「部門」エンティティの詳細対応マトリックステーブル画面の例である。
【図１１】本発明の実施形態におけるリレーションを示すテーブル説明図である。
【図１２】本発明の実施形態における関係マトリックステーブルが表示される関係マトリックステーブル画面の例であり、フォームＩＤが１１３の画面（「決済」画面）の関係マトリックステーブル画面の例である。
【図１３】本発明の実施形態におけるデータベース設計システムで作成されるＥＲモデル図の例である。
【図１４】「売上計上」画面の例を示す図である。
【図１５】図１４の「売上計上」画面の仮エンティティ作成処理結果の例を示すフォーム・データ項目表示枠の例である。
【図１６】図１４の「売上計上」画面の仮エンティティ作成時にマスターファイルに登録されている仮エンティティの説明図である。
【図１７】正規化エンティティ登録処理後の図１４の「売上計上」画面に属している正規化エンティティ例を示すフォーム・データ項目表示枠の例である。
【図１８】ＨＤＲ部分、ＤＴＬ部分を考慮して、図１４の「売上計上」画面に属している正規化エンティティのリレーションシップ作成処理を行った場合の処理結果例を示す関係マトリックステーブル画面の例である。
【図１９】ＨＤＲ部分、ＤＴＬ部分を考慮しないで、図１４の「売上計上」画面に属している正規化エンティティのリレーションシップ作成処理を行った場合の処理結果例を示す関係マトリックステーブル画面の例である。
【図２０】「決済」エンティティのエンティティタイプが間違っている場合の対応マトリックステーブル画面例である。
【図２１】「決済」エンティティのエンティティタイプが間違っている場合の、当該エンティティが属するフォームＩＤが１１３の画面（Ａ）、フォームＩＤが１１５の画面（Ｂ）の関係マトリックステーブル画面の例である。
【図２２】「決済」エンティティのエンティティタイプが正しいタイプに変更された場合の、当該エンティティが属するフォームＩＤが１１３の画面（Ａ）、フォームＩＤが１１５の画面（Ｂ）の関係マトリックステーブル画面の例である。
【図２３】本発明の実施形態における画面・帳票の追加処理を示すフローチャートである。
【図２４】本発明の実施形態における自動正規化処理を示すフローチャート（Ａ）、リレーションシップ変更処理を示すフローチャート（Ｂ）である。
【図２５】「発注計上」画面の例を示す図である。
【図２６】「発注計上」画面を処理対象画面として、正規化処理設計を行って作成されたＥＲモデル図である。
【図２７】「発注計上」画面を処理対象画面として、正規化処理設計を行って作成された「発注計上」画面に属する正規化エンティティを示すフォーム・データ項目表示枠の例である。
【図２８】「発注計上」画面を処理対象画面として、正規化処理設計を行って作成された対応マトリックステーブルが表示された対応マトリックステーブル画面の例である。
【図２９】「発注計上」画面を処理対象画面として、正規化処理設計を行って作成された「発注計上」画面の関係マトリックステーブルが表示された関係マトリックステーブル画面の例である。
【図３０】本発明の実施形態における画面・帳票の追加処理を説明するための図であり、（Ａ）は「売上計上」画面（追加画面）の自動正規化処理前、（Ｂ）は自動正規化処理後のフォーム・データ項目表示枠の例である。
【図３１】「発注計上」画面を処理対象画面として正規化処理設計を行った後に、「売上計上」画面を追加対象画面として画面・帳票の追加処理を行ったとき、又は「売上計上」画面と「発注計上」画面を処理対象画面として、正規化処理設計を行ったときに、作成された対応マトリックステーブルが表示された対応マトリックステーブル画面の例である。
【図３２】「売上計上」画面を追加／削除対象画面として画面・帳票の追加／削除処理を行ったときに作成された「売上計上」画面の関係マトリックステーブルが表示された関係マトリックステーブル画面の例である。
【図３３】「発注計上」画面を処理対象画面として正規化処理設計を行った後に、「売上計上」画面を追加対象画面として画面・帳票の追加処理を行ったとき、又は「売上計上」画面と「発注計上」画面を処理対象画面として、正規化処理設計を行ったときに作成されたＥＲモデル図である。
【図３４】本発明の実施形態における画面・帳票の削除処理を示すフローチャートである。
【図３５】本発明の実施形態におけるＥＲモデル図の統合処理を示すフローチャートである。
【図３６】本発明の実施形態におけるＥＲモデル図の統合処理を説明するための図であり、処理対象のＥＲモデル図の例である。
【図３７】図３６のＥＲモデル図の対応マトリックステーブルを示す対応マトリックステーブル画面の例である。
【図３８】本発明の実施形態におけるＥＲモデル図の統合処理を説明するための図であり、処理対象のＥＲモデル図の例である。
【図３９】図３８のＥＲモデル図の対応マトリックステーブルを示す対応マトリックステーブル画面の例である。
【図４０】本発明の実施形態におけるＥＲモデル図の抽出処理を示すフローチャートである。
【図４１】本発明の実施形態における部分ＥＲモデル図の作成処理結果の例を示す図であり、（Ａ）はフォームＩＤが１０２の画面、（Ｂ）はフォームＩＤが１１０の画面の部分ＥＲモデル図である。
【図４２】本発明の実施形態における機能仕様書の例としての「信託報酬引落額」機能仕様書例を示す説明図である。
【図４３】「信託報酬引落額」機能仕様書から抽出された機能仕様書内データ項目を説明するための「信託報酬引落額」機能仕様書のフォーム・データ項目表示枠の例である。
【図４４】（Ａ）はサイズ自動調整機能がＯＦＦ、（Ｂ）はサイズ自動調整機能がＯＮに設定されている場合のフォーム・データ項目表示枠の例である。
【図４５】自動集約機能がＯＦＦに設定されている場合の部分ＥＲモデル図の例である。
【図４６】自動集約機能がＯＮに設定されている場合の部分ＥＲモデル図の例である。
【図４７】（Ａ）は未登録データ項目がある場合のフォーム・データ項目表示枠、（Ｂ）は未使用データ項目がある場合のエンティティ表示枠の例である。
【図４８】（Ａ）は仮エンティティの作成後、ユーザによってＯＫを示すコマンドが入力される前のフォーム・データ項目表示枠、（Ｂ）はＯＫを示すコマンドが入力された後のフォーム・データ項目表示枠の例であり、（Ｃ）はＯＫを示すコマンドが入力された後、登録される「見積」エンティティを示す。
【図４９】（Ａ）は非正規化前の「受注計上」画面におけるエンティティの構成を示し、（Ｂ）は非正規化機能がＯＮに設定された場合の「受注計上」画面における非正規化エンティティの構成を示し、（Ｃ）は登録された非正規化エンティティを示す。
【図５０】ＤＴＬエンティティの繰り返し回数を指定した場合の非正規化エンティティの例であり、（Ａ）は「受注計上」画面における非正規化エンティティの構成を示し、（Ｂ）は登録された非正規化エンティティを示す。
【図５１】関係マトリックステーブル画面のその他の例である。
【図５２】「部門」画面の例を示す図である。
【図５３】「担当者」画面の例を示す図である。
【図５４】「得意先」画面の例を示す図である。
【図５５】「設計事務所」画面の例を示す図である。
【図５６】「発注者」画面の例を示す図である。
【図５７】「施主」画面の例を示す図である。
【図５８】「記載記事」画面の例を示す図である。
【図５９】「営業案件」画面の例を示す図である。
【図６０】「営業活動」画面の例を示す図である。
【図６１】「設計見積」画面の例を示す図である。
【図６２】「設計作業工数」画面の例を示す図である。
【図６３】「見積作業工数」画面の例を示す図である。
【図６４】「決済」画面の例を示す図である。
【図６５】「入札」画面の例を示す図である。
【図６６】「施工」画面の例を示す図である。
【図６７】「作業所」画面の例を示す図である。
【図６８】フォーム・データ項目表示枠のグループ毎の区分け表示の例を示す図である。
【図６９】図６８の区分け表示に対応したエンティティ表示枠のグループ毎の区分け表示の例である。
【符号の説明】
１０ データベース設計システム
１２ 補助記憶装置
１４ ＣＰＵ
１６ データベース
１８ ＥＲモデル設計ツールの起動プログラム
２０ サブシステムの起動プログラム
２２ データベース管理プログラム
２４ 編集プログラム
２６ アイデンティファイア・アトリビュート仕様
２８ 対応マトリックステーブル
２９ 詳細対応マトリックステーブル
３０ 関係マトリックステーブル
３２ ＥＲモデル図
３４ 入力・操作装置
３５ 記録媒体
３６ モニタ
３８ プリント出力装置
４０ メイン画面
５０ フォーム・データ項目表示枠
５３ エンティティ表示枠
５４ 対応マトリックステーブル画面
６２ 詳細対応マトリックステーブル画面
６４ 関係マトリックステーブル画面
【図１】
0004580518.tif 000002
【図２】
0004580518.tif 000003
【図３】
0004580518.tif 000004
【図４】
0004580518.tif 000005
【図５】
0004580518.tif 000006
【図６】
0004580518.tif 000007
【図７】
0004580518.tif 000008
【図８】
0004580518.tif 000009
【図９】
0004580518.tif 000010
【図１０】
0004580518.tif 000011
【図１１】
0004580518.tif 000012
【図１２】
0004580518.tif 000013
【図１３】
0004580518.tif 000014
【図１４】
0004580518.tif 000015
【図１５】
0004580518.tif 000016
【図１６】
0004580518.tif 000017
【図１７】
0004580518.tif 000018
【図１８】
0004580518.tif 000019
【図１９】
0004580518.tif 000020
【図２０】
0004580518.tif 000021
【図２１】
0004580518.tif 000022
【図２２】
0004580518.tif 000023
【図２３】
0004580518.tif 000024
【図２４】
0004580518.tif 000025
【図２５】
0004580518.tif 000026
【図２６】
0004580518.tif 000027
【図２７】
0004580518.tif 000028
【図２８】
0004580518.tif 000029
【図２９】
0004580518.tif 000030
【図３０】
0004580518.tif 000031
【図３１】
0004580518.tif 000032
【図３２】
0004580518.tif 000033
【図３３】
0004580518.tif 000034
【図３４】
0004580518.tif 000035
【図３５】
0004580518.tif 000036
【図３６】
0004580518.tif 000037
【図３７】
0004580518.tif 000038
【図３８】
0004580518.tif 000039
【図３９】
0004580518.tif 000040
【図４０】
0004580518.tif 000041
【図４１】
0004580518.tif 000042
【図４２】
0004580518.tif 000043
【図４３】
0004580518.tif 000044
【図４４】
0004580518.tif 000045
【図４５】
0004580518.tif 000046
【図４６】
0004580518.tif 000047
【図４７】
0004580518.tif 000048
【図４８】
0004580518.tif 000049
【図４９】
0004580518.tif 000050
【図５０】
0004580518.tif 000051
【図５１】
0004580518.tif 000052
【図５２】
0004580518.tif 000053
【図５３】
0004580518.tif 000054
【図５４】
0004580518.tif 000055
【図５５】
0004580518.tif 000056
【図５６】
0004580518.tif 000057
【図５７】
0004580518.tif 000058
【図５８】
0004580518.tif 000059
【図５９】
0004580518.tif 000060
【図６０】
0004580518.tif 000061
【図６１】
0004580518.tif 000062
【図６２】
0004580518.tif 000063
【図６３】
0004580518.tif 000064
【図６４】
0004580518.tif 000065
【図６５】
0004580518.tif 000066
【図６６】
0004580518.tif 000067
【図６７】
0004580518.tif 000068
【図６８】
0004580518.tif 000069
【図６９】
0004580518.tif 000070