JP2001306373A - データベース設計システム、データベース設計方法、記録媒体、及び表示方法 - Google Patents

データベース設計システム、データベース設計方法、記録媒体、及び表示方法

Info

Publication number
JP2001306373A
JP2001306373A JP2000234663A JP2000234663A JP2001306373A JP 2001306373 A JP2001306373 A JP 2001306373A JP 2000234663 A JP2000234663 A JP 2000234663A JP 2000234663 A JP2000234663 A JP 2000234663A JP 2001306373 A JP2001306373 A JP 2001306373A
Authority
JP
Japan
Prior art keywords
entity
information
normalization
data
screen
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2000234663A
Other languages
English (en)
Other versions
JP4580518B2 (ja
Inventor
Yoshikazu Shiraishi
慶和 白石
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to JP2000234663A priority Critical patent/JP4580518B2/ja
Priority to IL13781900A priority patent/IL137819A0/xx
Priority to US09/638,801 priority patent/US6678693B1/en
Priority to EP00402290A priority patent/EP1076303A1/en
Publication of JP2001306373A publication Critical patent/JP2001306373A/ja
Application granted granted Critical
Publication of JP4580518B2 publication Critical patent/JP4580518B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/288—Entity relationship models
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

(57)【要約】 【課題】 作成済みＥＲモデル図の統合・抽出、処理対
象画面・帳票・機能仕様書の追加、削除を効率的且つ正
確に行う。 【解決手段】 処理対象の画面・帳票から画面・帳票内
データ項目を抽出し、仮エンティティを作成し、作成し
た仮エンティティを集約して正規化エンティティを作成
する。この正規化エンティティと各画面・帳票との対応
関係を示す対応マトリックステーブルを作成する。この
対応マトリックステーブルに基づいて、正規化エンティ
ティ間のリレーションシップを示す関係マトリックステ
ーブル３０を画面・帳票毎に作成し、関係マトリックス
テーブル３０に基づいてＥＲモデル図を作成する。

Description

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

Claims (39)

    【特許請求の範囲】
  1. 【請求項１】 ＥＲモデルを用いたデータベース設計シ
    ステムであって、 キー定義データと該キー定義データに対応するデータ項
    目とを含む複数の情報を、キー定義データと該キーデー
    タに対応するデータ項目とに分類して仮エンティティを
    作成する仮エンティティ作成手段と、 前記仮エンティティに共通するキー定義データを有する
    仮エンティティが存在する場合には１つのエンティティ
    に集約して、正規化エンティティを作成する正規化エン
    ティティ作成手段と、 前記正規化エンティティのエンティティタイプを設定す
    る設定手段と、 前記正規化エンティティ作成手段により作成された正規
    化エンティティと前記情報との対応関係を示す第１のマ
    トリックステーブルを作成する第１のテーブル作成手段
    と、 前記第１のマトリックステーブルと、予め設定されてい
    る前記エンティティタイプに基づく正規化エンティティ
    間の関係とに基づいて、前記情報毎に、該情報に属する
    前記正規化エンティティ間の関係を示す第２のマトリッ
    クステーブルを作成する第２のテーブル作成手段と、 前記第２のテーブル作成手段により作成された前記情報
    毎の第２のマトリックステーブルに基づいて、ＥＲモデ
    ル図を作成するＥＲモデル図作成手段と、 を有することを特徴とするデータベース設計システム。
  2. 【請求項２】 キー定義データと該キー定義データに対
    応するデータ項目とを含む複数の情報を入力する入力手
    段を更に有する、 ことを特徴とする請求項１に記載のデータベース設計シ
    ステム。
  3. 【請求項３】 前記ＥＲモデル図作成手段が、前記複数
    の情報のうちの少なくとも１つの前記情報に基づくＥＲ
    モデル図、或いは２つ以上の前記情報の組み合わせに基
    づくＥＲモデル図を作成する、 ことを特徴とする請求項１又は請求項２に記載のデータ
    ベース設計システム。
  4. 【請求項４】 前記正規化エンティティ作成手段が、前
    記ＥＲモデル図作成手段により作成された複数のＥＲモ
    デル図を統合するコマンドが入力されたときに、各ＥＲ
    モデル作成時の正規化エンティティに共通するキー定義
    データを有する正規化エンティティが存在する場合には
    １つに集約する、 ことを特徴とする請求項１乃至請求項３の何れか１項に
    記載のデータベース設計システム。
  5. 【請求項５】 前記第１のマトリックステーブルにおけ
    る正規化エンティティと前記情報との対応関係、前記第
    ２のマトリックステーブルにおける前記正規化エンティ
    ティ間の関係、前記正規化エンティティのエンティティ
    タイプ、及び前記正規化エンティティを構成するキー定
    義データとデータ項目との対応関係のうちの少なくとも
    １つを変更する変更手段を更に有する、 ことを特徴とする請求項１乃至請求項４の何れか１項に
    記載のデータベース設計システム。
  6. 【請求項６】 前記変更手段が、 前記情報を削除するためのコマンドが入力されたとき
    に、削除対象の情報に含まれる正規化エンティティが削
    除可能か否かを判断する第１の判断手段と、 前記第１の判断手段によって削除不能と判断されたとき
    は前記情報を削除し、削除可能と判断されたときは前記
    情報及び前記正規化エンティティを削除する第１の削除
    手段と、を有し 前記第１の削除手段によって前記情報、又は前記情報及
    び前記正規化エンティティが削除されたときに、前記第
    １のマトリックステーブルの正規化エンティティと前記
    情報との対応関係を変更する、 ことを特徴とする請求項５に記載のデータベース設計シ
    ステム。
  7. 【請求項７】 前記第１の判断手段は、削除対象の情報
    に対応する正規化エンティティが、該削除対象の情報の
    みに対応している場合に、該正規化エンティティが削除
    可能と判断する、 ことを特徴とする請求項６に記載のデータベース設計シ
    ステム。
  8. 【請求項８】 前記正規化エンティティが対応している
    前記情報の数を記憶する第１の記憶手段を更に有し、 前記第１の判断手段は、前記情報を追加入力するための
    コマンドが入力されたときは、追加対象の前記情報に対
    応する前記正規化エンティティの前記第１の記憶手段に
    記憶されている前記数をインクリメントし、 前記情報を削除するためのコマンドが入力されたとき
    は、削除対象の前記情報に対応する前記正規化エンティ
    ティの前記第１の記憶手段に記憶されている前記数をデ
    クリメントし、前記数が０になった場合に、該正規化エ
    ンティティが削除可能と判断する、 ことを特徴とする請求項７に記載のデータベース設計シ
    ステム。
  9. 【請求項９】 前記変更手段が、 前記情報における前記エンティティ間の関係を削除する
    ためのコマンドが入力されたときに、前記第２のマトリ
    ックステーブルにおいて当該エンティティ間の関係を削
    除する第２の削除手段を有し、 前記ＥＲモデル図作成手段が、 前記第２の削除手段により削除されたエンティティ間の
    関係を示す接続線が前記ＥＲモデル図から削除可能か否
    かを判断する第２の判断手段と、 前記第２の判断手段によって削除可能と判断されたとき
    に、前記ＥＲモデル図から該エンティティ間の関係を示
    す接続線を削除する第３の削除手段とを有する、 ことを特徴とする請求項５乃至請求項８の何れか１項に
    記載のデータベース設計システム。
  10. 【請求項１０】 前記第２の判断手段は、前記第２の削
    除手段により削除されたエンティティ間の関係が、前記
    削除されたエンティティ間の関係に関連する前記情報の
    みに存在する場合に、前記ＥＲモデル図における該エン
    ティティ間の関係を示す接続線が削除可能と判断する、 ことを特徴とする請求項９に記載のデータベース設計シ
    ステム。
  11. 【請求項１１】 前記エンティティ間の関係が属してい
    る前記情報の数を記憶する第２の記憶手段を更に有し、 前記第２の判断手段は、前記エンティティ間の関係を追
    加するためのコマンドが入力されたときは、追加対象の
    エンティティ間の関係に対応する前記第２の記憶手段に
    記憶されている前記数をインクリメントし、 前記エンティティ間の関係を削除するためのコマンドが
    入力されたときは、削除対象のエンティティ間の関係に
    対応する前記第２の記憶手段に記憶されている前記数を
    デクリメントし、前記数が０になった場合に、前記ＥＲ
    モデル図における該エンティティ間の関係を示す接続線
    が削除可能と判断する、 ことを特徴とする請求項１０に記載のデータベース設計
    システム。
  12. 【請求項１２】 前記変更手段が、 前記正規化エンティティのエンティティタイプの変更の
    コマンドが入力されたときに、当該正規化エンティティ
    のエンティティタイプを変更するとともに、前記第１の
    マトリックステーブルを参照して前記情報の中から該正
    規化エンティティが対応する情報を検索し、エンティテ
    ィタイプの変更に基づいて、検索された情報に属する前
    記正規化エンティティ間の関係を変更する、 ことを特徴とする請求項５乃至請求項１１の何れか１項
    に記載のデータベース設計システム。
  13. 【請求項１３】 前記変更手段が、 前記情報を削除するためのコマンドが入力されたとき
    に、前記正規化エンティティを構成するキー定義データ
    及びデータ項目から、削除対象の情報に含まれるキー定
    義データ及びデータ項目のうちの少なくとも１つを削除
    可能か否かを判断する第３の判断手段と、 前記第３の判断手段によって削除可能と判断されたとき
    に、前記削除対象の情報に含まれるキー定義データ及び
    データ項目のうちの少なくとも１つを削除する第４の削
    除手段と、 を有することを特徴とする請求項５乃至請求項１２の何
    れか１項に記載のデータベース設計システム。
  14. 【請求項１４】 前記第３の判断手段は、前記削除対象
    の情報に含まれるキー定義データ及びデータ項目のうち
    の少なくとも１つが、削除対象の情報のみに含まれてい
    る場合に、該キー定義データ及びデータ項目のうちの少
    なくとも１つが削除可能と判断する、 ことを特徴とする請求項１３に記載のデータベース設計
    システム。
  15. 【請求項１５】 同じキー定義データを含む前記情報の
    数、及び同じデータ項目を含む前記情報の数を記憶する
    第３の記憶手段を更に有し、 前記第３の判断手段は、前記情報を追加入力するための
    コマンドが入力されたときは、追加対象の前記情報に含
    まれるキー定義データ及びデータ項目の前記第３の記憶
    手段に記憶されている前記数をインクリメントし、 前記情報を削除するためのコマンドが入力されたとき
    は、削除対象の前記情報に含まれるキー定義データ及び
    データ項目の前記第３の記憶手段に記憶されている前記
    数をデクリメントし、前記数が０になった場合に、該キ
    ー定義データ又はデータ項目が削除可能と判断する、 ことを特徴とする請求項１４に記載のデータベース設計
    システム。
  16. 【請求項１６】 前記ＥＲモデル図作成手段は、前記変
    更手段による変更結果に基づいて、ＥＲモデル図を修正
    するとともに、修正個所を報知する、 ことを特徴とする請求項１乃至請求項１５の何れか１項
    に記載のデータベース設計システム。
  17. 【請求項１７】 前記仮エンティティ作成手段が、 作成した仮エンティティを登録してマスターファイルを
    作成するマスターファイル作成手段と、 前記マスターファイルを参照して、キー定義データと対
    応付けられていないデータ項目を検索する検索手段と、 前記検索結果を報知する検索結果報知手段と、 を有することを特徴とする請求項１乃至請求項１６の何
    れか１項に記載のデータベース設計システム。
  18. 【請求項１８】 前記仮エンティティ作成手段は、 作成済みの前記正規化エンティティを参照して、未分類
    の前記情報をキー定義データと該キーデータに関連する
    データ項目とに分類して仮エンティティを作成する、 ことを特徴とする請求項５乃至請求項１７の何れか１項
    に記載のデータベース設計システム。
  19. 【請求項１９】 前記正規化エンティティ作成手段が、 作成済みの前記正規化エンティティとキー定義データが
    同一の仮エンティティを、該作成済みの正規化エンティ
    ティに集約し、 作成済みの前記正規化エンティティとキー定義データが
    異なる仮エンティティを新規の正規化エンティティとす
    る、 ことを特徴とする請求項１８に記載のデータベース設計
    システム。
  20. 【請求項２０】 作成済みの前記正規化エンティティを
    参照して自動分類された仮エンティティ、又は該仮エン
    ティティが集約された正規化エンティティを報知する自
    動分類報知手段を更に有する、 ことを特徴とする請求項１８又は請求項１９に記載のデ
    ータベース設計システム。
  21. 【請求項２１】 前記キー定義データとデータ項目の対
    応関係をマニュアル修正するマニュアル修正手段と、 前記マニュアル修正手段による修正履歴を報知する履歴
    報知手段とを更に有する、 ことを特徴とする請求項１乃至請求項２０の何れか１項
    に記載のデータベース設計システム。
  22. 【請求項２２】 前記情報内の前記キー定義データ、前
    記データ項目、及び前記正規化エンティティの少なくと
    も１つをマニュアルで追加及び削除の少なくとも一方を
    行うマニュアル追加・削除手段と、 前記マニュアル追加・削除による追加又は削除後に、前
    記情報と前記正規化エンティティとの整合性が保たれて
    いるか否かを判断する整合性判断手段と、 前記整合性判断手段により非整合が検出された場合に、
    当該非整合を報知する非整合報知手段と、を更に有す
    る、 ことを特徴とする請求項１乃至請求項２１の何れか１項
    に記載のデータベース設計システム。
  23. 【請求項２３】 前記正規化エンティティの分割及び統
    合の少なくとも一方を行う分割統合手段を更に有する、 ことを特徴とする請求項１乃至請求項２２に記載のデー
    タベース設計システム。
  24. 【請求項２４】 前記第１のマトリックステーブル作成
    手段が、前記第１のマトリックステーブルとともに、前
    記正規化エンティティ毎に、該正規化エンティティを構
    成するキー定義データ及びデータ項目の各々と前記情報
    との対応関係を示す第３のマトリックステーブルを作成
    する、 ことを特徴とする請求項１乃至請求項２３の何れか１項
    に記載のデータベース設計システム。
  25. 【請求項２５】 前記第２のテーブル作成手段が、前記
    正規化エンティティをヘッダ部分の正規化エンティティ
    と、前記情報内での繰り返し項目を示すディテール部分
    の正規化エンティティとに分割し、ヘッダ部分の正規化
    エンティティ間の関係、ディテール部分の正規化エンテ
    ィティ間の関係、及びヘッダ部分とディテール部分との
    関係を求めて、第２のマトリックステーブルを作成す
    る、 ことを特徴とする請求項１乃至請求項２４の何れか１項
    に記載のデータベース設計システム。
  26. 【請求項２６】 前記情報、前記正規化エンティティ、
    前記第１のマトリックステーブル、前記第２のマトリッ
    クステーブル、及び前記ＥＲモデル図の少なくとも１つ
    を表示する表示制御手段を更に有する、 ことを特徴とする請求項１乃至請求項２５の何れか１項
    に記載のデータベース設計システム。
  27. 【請求項２７】 前記表示制御手段が、前記情報及び前
    記正規化エンティティとともに、前記第１のマトリック
    ステーブル作成手段、前記第２のマトリックステーブル
    作成手段、前記ＥＲモデル図作成手段の少なくとも１つ
    により作成された前記第１のマトリックステーブル、前
    記第２のマトリックステーブル、及び前記ＥＲモデル図
    の少なくとも１つを表示する、 ことを特徴とする請求項２６に記載のデータベース設計
    システム。
  28. 【請求項２８】 前記表示制御手段が、 前記情報毎に付与された識別番号の順に、又は予め定め
    られたグループ毎に区分して、前記情報を配置し、前記
    情報の中から、前記正規化エンティティ作成手段が処理
    対象とする情報を指定し、前記正規化エンティティ作成
    手段が当該指定された前記情報を処理して、新規に作成
    された正規化エンティティを該情報に隣接配置する、 ことを特徴とする請求項２６又は請求項２７に記載のデ
    ータベース設計システム。
  29. 【請求項２９】 前記表示制御手段が、前記情報を表示
    する際に、前記情報毎に定められた１つの表示枠内に、
    前記情報に含まれる前記キー定義データと前記データ項
    目を表示するとともに、該情報のタイトルを該表示枠に
    隣接して表示する、 ことを特徴とする請求項２６乃至請求項２８の何れか１
    項に記載のデータベース設計システム。
  30. 【請求項３０】 前記情報が、画面、又は帳票、又は機
    能仕様書のデータである、 ことを特徴とする請求項１乃至請求項２９の何れか１項
    に記載のデータベース設計システム。
  31. 【請求項３１】 前記仮エンティティ作成手段が、各前
    記情報において、同一のキー定義データ又はデータ項目
    を１つに集約してから仮エンティティを作成する、 ことを特徴とする請求項１乃至請求項３０の何れか１項
    に記載のデータベース設計システム。
  32. 【請求項３２】 ＥＲモデルを用いたデータベース設計
    方法であって、 キー定義データと該キー定義データに対応するデータ項
    目とを含む複数の情報を、キー定義データと該キーデー
    タに対応するデータ項目とに分類して仮エンティティを
    作成し、 前記仮エンティティに共通するキー定義データを有する
    仮エンティティが存在する場合には１つのエンティティ
    に集約して、正規化エンティティを作成し、 前記正規化エンティティのエンティティタイプを設定
    し、 前記正規化エンティティと前記情報との対応関係を示す
    第１のマトリックステーブルを作成し、 前記第１のマトリックステーブルと、予め設定された前
    記エンティティタイプに基づく正規化エンティティ間の
    関係とに基づいて、前記情報毎に、該情報に属する前記
    正規化エンティティ間の関係を示す第２のマトリックス
    テーブルを作成し、 前記情報毎に作成された前記第２のマトリックステーブ
    ルに基づいて、ＥＲモデル図を作成する、 ことを特徴とするデータベース設計方法。
  33. 【請求項３３】 前記第１のマトリックステーブルにお
    ける正規化エンティティと前記情報との対応関係、前記
    第２のマトリックステーブルにおける前記正規化エンテ
    ィティ間の関係、前記正規化エンティティのエンティテ
    ィタイプ、及び前記正規化エンティティを構成するキー
    定義データとデータ項目との対応関係のうちの少なくと
    も１つを変更可能となっている、 ことを特徴とする請求項３２に記載のデータベース設計
    方法。
  34. 【請求項３４】 ＥＲモデルを用いたデータベースを設
    計するためのデータベース設計プログラムを記録したコ
    ンピュータ読取可能な記録媒体であって、 キー定義データと該キー定義データに対応するデータ項
    目とを含む複数の情報を、キー定義データと該キーデー
    タに対応するデータ項目とに分類して仮エンティティを
    作成し、 前記仮エンティティに共通するキー定義データを有する
    仮エンティティが存在する場合には１つのエンティティ
    に集約して、正規化エンティティを作成し、 前記正規化エンティティのエンティティタイプを設定
    し、 前記正規化エンティティと前記情報との対応関係を示す
    第１のマトリックステーブルを作成し、 前記第１のマトリックステーブルと、予め設定された前
    記エンティティタイプに基づく正規化エンティティ間の
    関係とに基づいて、前記情報毎に、該情報に属する前記
    正規化エンティティ間の関係を示す第２のマトリックス
    テーブルを作成し、 前記情報毎に作成された前記第２のマトリックステーブ
    ルに基づいて、ＥＲモデル図を作成する、データベース
    設計プログラムを記録したコンピュータ読取可能な記録
    媒体。
  35. 【請求項３５】 前記データベース設計プログラムにお
    いて、前記第１のマトリックステーブルにおける正規化
    エンティティと前記情報との対応関係、前記第２のマト
    リックステーブルにおける前記正規化エンティティ間の
    関係、前記正規化エンティティのエンティティタイプ、
    及び前記正規化エンティティを構成するキー定義データ
    とデータ項目との対応関係のうちの少なくとも１つを変
    更可能となっている、 ことを特徴とする請求項３４に記載の記録媒体。
  36. 【請求項３６】 キー定義データと該キー定義データに
    対応するデータ項目とを含む情報に基づいてＥＲモデル
    を作成する際の表示方法であって、 前記情報毎に定められた１つの表示枠内に、前記情報を
    表示すると共に、該情報のタイトルを該表示枠に隣接し
    て表示する、 ことを特徴とする表示方法。
  37. 【請求項３７】 前記表示枠内に、前記キー定義データ
    と前記データ項目をエンティティ毎に区分して表示す
    る、 ことを特徴とする請求項３６に記載の表示方法。
  38. 【請求項３８】 前記表示枠内をキー定義データ表示用
    コラムとデータ項目表示用コラムとに分けて、 前記キー定義データ表示用コラム及び前記データ項目表
    示用コラムに、前記キー定義データ及び前記データ項目
    をエンティティ毎に区分して表示することを特徴とする
    請求項３６に記載の表示方法。
  39. 【請求項３９】 前記表示枠内に表示するキー定義デー
    タ及びデータ項目の少なくとも一方の、文字数及び個数
    の少なくとも一方に応じて、当該前記表示枠のサイズを
    調整する、 ことを特徴とする請求項３６乃至請求項３８の何れか１
    項に記載の表示方法。
JP2000234663A 1999-08-12 2000-08-02 データベース設計システム Expired - Lifetime JP4580518B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2000234663A JP4580518B2 (ja) 1999-08-12 2000-08-02 データベース設計システム
IL13781900A IL137819A0 (en) 1999-08-12 2000-08-10 Database design system, database design method and record medium
US09/638,801 US6678693B1 (en) 1999-08-12 2000-08-10 Database design system, database design method and record medium
EP00402290A EP1076303A1 (en) 1999-08-12 2000-08-14 Database design system, database design method and record medium

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP22841999 1999-08-12
JP11-228419 2000-02-17
JP2000-40191 2000-02-17
JP2000040191 2000-02-17
JP2000234663A JP4580518B2 (ja) 1999-08-12 2000-08-02 データベース設計システム

Publications (2)

Publication Number Publication Date
JP2001306373A true JP2001306373A (ja) 2001-11-02
JP4580518B2 JP4580518B2 (ja) 2010-11-17

Family

ID=27331399

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000234663A Expired - Lifetime JP4580518B2 (ja) 1999-08-12 2000-08-02 データベース設計システム

Country Status (4)

Country Link
US (1) US6678693B1 (ja)
EP (1) EP1076303A1 (ja)
JP (1) JP4580518B2 (ja)
IL (1) IL137819A0 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009015455A (ja) * 2007-07-02 2009-01-22 Gct Kenkyusho:Kk 情報表示装置、情報表示方法および情報表示プログラム
JP2015165366A (ja) * 2014-03-03 2015-09-17 富士通株式会社 データベースの再構成方法、データベースの再構成プログラム、及び、データベースの再構成装置

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7167873B2 (en) * 2001-06-26 2007-01-23 Ncr Corp. Visual-modeling technique for use in implementing a database system
DE10206215A1 (de) * 2002-02-15 2003-09-11 Deutsche Telekom Ag Verfahren und Vorrichtung zum automatischen Erstellen eines Datawarehouse
US6826602B1 (en) * 2002-09-12 2004-11-30 Bellsouth Intellectual Property Corporation System and method for reverse content distribution
US20050289115A1 (en) * 2004-06-28 2005-12-29 Microsoft Corporation Integrating best practices into database design
US9646083B2 (en) * 2007-12-03 2017-05-09 International Business Machines Corporation Web 2.0 system and method for dynamic categorization of heterogeneous and regulated enterprise assets
US10417263B2 (en) 2011-06-03 2019-09-17 Robert Mack Method and apparatus for implementing a set of integrated data systems
WO2014134630A1 (en) 2013-03-01 2014-09-04 RedOwl Analytics, Inc. Modeling social behavior
US9665270B2 (en) 2013-06-28 2017-05-30 Sap Se Layout algorithm for entity relation model diagram
US11888859B2 (en) 2017-05-15 2024-01-30 Forcepoint Llc Associating a security risk persona with a phase of a cyber kill chain
US10999296B2 (en) 2017-05-15 2021-05-04 Forcepoint, LLC Generating adaptive trust profiles using information derived from similarly situated organizations
US10318729B2 (en) 2017-07-26 2019-06-11 Forcepoint, LLC Privacy protection during insider threat monitoring
US11314787B2 (en) * 2018-04-18 2022-04-26 Forcepoint, LLC Temporal resolution of an entity
US11755584B2 (en) 2018-07-12 2023-09-12 Forcepoint Llc Constructing distributions of interrelated event features
US11810012B2 (en) 2018-07-12 2023-11-07 Forcepoint Llc Identifying event distributions using interrelated events
US11436512B2 (en) 2018-07-12 2022-09-06 Forcepoint, LLC Generating extracted features from an event
US10949428B2 (en) 2018-07-12 2021-03-16 Forcepoint, LLC Constructing event distributions via a streaming scoring operation
US11811799B2 (en) 2018-08-31 2023-11-07 Forcepoint Llc Identifying security risks using distributions of characteristic features extracted from a plurality of events
US11025659B2 (en) 2018-10-23 2021-06-01 Forcepoint, LLC Security system using pseudonyms to anonymously identify entities and corresponding security risk related behaviors
US11171980B2 (en) 2018-11-02 2021-11-09 Forcepoint Llc Contagion risk detection, analysis and protection
CN111143354B (zh) * 2019-12-09 2023-07-25 北京五八信息技术有限公司 表单提交方法、装置、电子设备及存储介质
US11570197B2 (en) 2020-01-22 2023-01-31 Forcepoint Llc Human-centric risk modeling framework
US11630901B2 (en) 2020-02-03 2023-04-18 Forcepoint Llc External trigger induced behavioral analyses
US11429697B2 (en) 2020-03-02 2022-08-30 Forcepoint, LLC Eventually consistent entity resolution
US11836265B2 (en) 2020-03-02 2023-12-05 Forcepoint Llc Type-dependent event deduplication
US11568136B2 (en) 2020-04-15 2023-01-31 Forcepoint Llc Automatically constructing lexicons from unlabeled datasets
US11516206B2 (en) 2020-05-01 2022-11-29 Forcepoint Llc Cybersecurity system having digital certificate reputation system
US11544390B2 (en) 2020-05-05 2023-01-03 Forcepoint Llc Method, system, and apparatus for probabilistic identification of encrypted files
US11895158B2 (en) 2020-05-19 2024-02-06 Forcepoint Llc Cybersecurity system having security policy visualization
US11704387B2 (en) 2020-08-28 2023-07-18 Forcepoint Llc Method and system for fuzzy matching and alias matching for streaming data sets
US11190589B1 (en) 2020-10-27 2021-11-30 Forcepoint, LLC System and method for efficient fingerprinting in cloud multitenant data loss prevention

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09146805A (ja) * 1995-11-28 1997-06-06 Yoshikazu Shiraishi Ｔ字型ｅｒモデルデータベース設計システム
JP2000003297A (ja) * 1998-03-11 2000-01-07 Yoshikazu Shiraishi Ｅｒモデルデータベース設計システム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2260007A (en) 1991-09-20 1993-03-31 Hitachi Ltd Information storage/retrieval system and display method
US5615112A (en) 1993-01-29 1997-03-25 Arizona Board Of Regents Synthesized object-oriented entity-relationship (SOOER) model for coupled knowledge-base/database of image retrieval expert system (IRES)
JP3700884B2 (ja) * 1996-01-31 2005-09-28 富士写真フイルム株式会社 フイルム画像再生方法及び装置
JPH10126759A (ja) * 1996-10-16 1998-05-15 Sony Corp 受信装置及び表示制御方法
US5907831A (en) * 1997-04-04 1999-05-25 Lotvin; Mikhail Computer apparatus and methods supporting different categories of users
US6460043B1 (en) * 1998-02-04 2002-10-01 Microsoft Corporation Method and apparatus for operating on data with a conceptual data manipulation language
JP4982819B2 (ja) * 1998-07-10 2012-07-25 インタレクチュアル ヴェンチャーズ ファースト エルエルシー 情報管理装置および方法、記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09146805A (ja) * 1995-11-28 1997-06-06 Yoshikazu Shiraishi Ｔ字型ｅｒモデルデータベース設計システム
JP2000003297A (ja) * 1998-03-11 2000-01-07 Yoshikazu Shiraishi Ｅｒモデルデータベース設計システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009015455A (ja) * 2007-07-02 2009-01-22 Gct Kenkyusho:Kk 情報表示装置、情報表示方法および情報表示プログラム
JP2015165366A (ja) * 2014-03-03 2015-09-17 富士通株式会社 データベースの再構成方法、データベースの再構成プログラム、及び、データベースの再構成装置
US9881073B2 (en) 2014-03-03 2018-01-30 Fujitsu Limited Method for reconfiguration of database, recording medium, and reconfiguration device

Also Published As

Publication number Publication date
EP1076303A1 (en) 2001-02-14
US6678693B1 (en) 2004-01-13
JP4580518B2 (ja) 2010-11-17
IL137819A0 (en) 2001-10-31

Similar Documents

Publication Publication Date Title
JP4580518B2 (ja) データベース設計システム
JP3302522B2 (ja) データベースシステムおよびその情報活用支援装置
US7302444B1 (en) System for designating grid-based database reports
US7610258B2 (en) System and method for exposing a child list
US20030061225A1 (en) Hierarchical hybrid OLAP scenario management system
US7467122B2 (en) System for aiding the design of product configuration
US20020161765A1 (en) System and methods for standardizing data for design review comparisons
US20060190275A1 (en) Intellectual property management system
JP2005259135A (ja) 調達知識統合ツール
US20030061246A1 (en) Hierarchical hybrid online analytical processing services system
US9087053B2 (en) Computer-implemented document manager application enabler system and method
KR20050061597A (ko) 버저닝된 데이터베이스에 대한 리포트를 생성하기 위한시스템 및 방법
US7873607B1 (en) Model driven consolidator of database information
US20130290065A1 (en) Method and System to Analyze Processes
US20030061226A1 (en) Data loader for handling imperfect data and supporting multiple servers and data sources
JP3766854B2 (ja) データ処理装置
US20030110156A1 (en) Information collecting apparatus, information collecting method and information collecting program
JP2017083937A (ja) 情報処理装置、情報処理方法、及びプログラム
JPH10254979A (ja) データ処理システム及びデータベース設計システム
JP2005327136A (ja) 伝票管理システム及び伝票管理用ソフトウェア
US9710774B2 (en) Configuration of embedded intelligence
JP3656710B2 (ja) 議事録管理方法及び議事録管理システム
JP3521822B2 (ja) 電子報告書装置及びプログラムを記録した機械読み取り可能な記録媒体
JP3109331B2 (ja) 帳票出力装置
JPH10254980A (ja) ビジネス支援システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070723

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100420

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100621

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100810

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100830

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

Free format text: PAYMENT UNTIL: 20130903

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4580518

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term