JPH09319629A - データベース設計支援ツール - Google Patents

Abstract

(57)【要約】 【課題】データベース設計支援ツールを使用することに
より、データモデルで記述されたデータ構造およびデー
タ一貫性制約を自動的にデータベースに生成する。 【解決手段】画面に表示された概念データモデルの実体
のシンボルをマウスなどのポインティングデバイスを使
用して画面上で任意の位置に移動し、複数の実体のシン
ボルの重なりを自動的に検知し、元の概念データモデル
の実体間の関連情報から、矛盾があるか否か判断し、矛
盾が無いならば、テーブルの定義、および、繰返しや推
移従属などの非正規化情報を生成し、非正規化されたデ
ータ構造を表わすデータモデルを作成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

【０００２】

【従来の技術】「データモデル」の作成には、ワークス
テーションやパーソナルコンピュータなど安価なコンピ
ュータで動作し、ＧＵＩを使用してビジュアルかつ対話
的にデータモデルを作成するデータモデリングツールが
使用されている。

【０００３】データモデリングツールを使用することに
より、データ構造とデータの意味を規定するデータ一貫
性制約をダイヤグラムで記述できる。また、このような
データモデリングツールは、特定のデータベースマネジ
メントシステム（以降、ＤＢＭＳと略す）を使用して実
データベースを生成するためのデータベース定義体を生
成し、また、データ一貫性制約を維持するための処理定
義を自動生成する機能を持つことが普通である。このよ
うなデータベース設計支援ツールを使用することによ
り、「データモデル」で記述されたデータ構造およびデ
ータ一貫性制約を自動的にデータベースに生成すること
ができ、データベース構築作業を効率良く行うことがで
きる。

【０００４】

【発明が解決しようとする課題】一般的なデータベース
設計の理論によれば、まず、アプリケーションシステム
のデータベースの要件を定義するためにデータベースの
モデル（概念データモデル）を作成し、その次に、アプ
リケーションプログラムの制約を考慮して、コストおよ
び性能の要件を満たすように「概念データモデル」で定
義したデータ構造を変換し、データベース上に生成する
データの構造（データベース構造）を決定するという過
程でデータベース設計を進めることが要求される。

【０００５】このデータベース設計の過程で、「概念デ
ータモデル」のデータ構造は、正規化されていることが
要求される。「概念データモデル」で表わされたデータ
構造と同じ構造でデータベースを生成したならば、デー
タベースのデータ一貫性の維持、および、データ構造の
変更（スキーマの変更）が容易となり、データベースの
構築と維持管理の点から望ましい。また、正規化された
データモデルには、更新異常や削除異常などを防止する
データ一貫性制約が記述されるので、データアプリケー
ションプログラムのモジュールの作成時に、データモデ
ルからデータの一貫性を保つための条件を読取り、プロ
グラムに記述することができる。

【０００６】従って、データベースの管理の点から極力
理想に近いデータベースを構築するために、まず、正規
化されたデータ構造を持つ「概念データモデル」を作成
し、次に、アプリケーションプログラムの制約を考慮
し、必要に応じて最小限のデータ構造の変更（非正規
化）で、「データベース構造」を決定することが理論上
望ましい。

【０００７】以上に述べた理論に基づいて、「概念デー
タモデル」から「データベース構造」に変換する過程
で、「概念データモデル」に比べ「データベース構造」
のデータ構造は要約（単純化）される。そのため、「概
念データモデル」の作成時に抽出した正規系リレーショ
ンおよび実体間の関連などのデータの意味に関する情報
は、データベース設計結果である「データベース構造」
から失われる。また、データベース設計の最終結果であ
る「データベース構造」と同時に途中結果である「概念
データモデル」を参照して「概念データモデル」の作成
時に抽出したデータの意味に関する情報を活用するため
には、「概念データモデル」と「データベース構造」の
両者の対応付けを再解釈する必要がある。このような
「概念データモデル」と「データベース構造」の両者の
対応付けを意識したデータベースの保守作業は、相当の
スキルが必要であり、また、非常に煩わしいため、実務
上、「概念データモデル」が持つデータの意味に関する
情報を活用することが困難である。

【０００８】さらに、このような背景があるため、実務
上は、「概念データモデル」を作成しないで、最初から
「データベース構造」を決定することも多い。このよう
な状況では、データベース設計の手法の標準化が困難で
ある。さらに、「概念データモデル」で表わすことので
きるデータの一貫性を保つための制約条件をプログラム
作成やテストの過程で改めて調査・分析することにな
り、また、それがアプリケーションプログラムを作成す
る担当者が個々に行われることになり、結果としてプロ
グラムの作成工数が増大する。仮に、データベース設計
の担当者が、先に述べたデータベース設計の理論に基づ
いて「概念データモデル」と「データベース構造」の両
者の対応付けを意識してデータベース設計を行っていた
としても、その過程を俗人的に行っていたのでは、設計
の途中過程の情報が共有されず、多数のアプリケーショ
ンプログラム作成者が関る大規模プロジェクトや、企業
情報システムの長期的な維持・管理において、破綻を招
く危険性が高い。

【０００９】そこで、従来の技術の節で記したＧＵＩを
使用してデータモデルを作成するデータベース設計支援
ツールにおいて、「概念データモデル」を元に、ＧＵＩ
を使用してビジュアルかつ対話的に、必要に応じてデー
タ構造を変更（非正規化）し、「データベース構造」を
作成する機能が必要となる。

【００１０】また、「概念データモデル」から「データ
ベース構造」へデータ構造を変更（非正規化）した過程
をツールの利用者（データベース設計者）に意識させる
ことなく自動的に管理し、かつ、データベース設計の途
中結果である「概念データモデル」と最終結果である
「データベース構造」の両方のモデルを区別して管理す
る機能が必要となる。

【００１１】さらに、「データベース構造」によって表
わされる“データベースに生成されるデータ構造につい
ての情報”と「概念データモデル」によって表わされる
“データ一貫性制約についての情報”をデータベース設
計の終了後に、効率良く有効に活用できる機能が必要と
なる。

【００１２】

【課題を解決するための手段】従来のデータベース設計
支援ツールに、「概念データモデル」に加えて、「デー
タベース構造」の情報を管理するリポジトリ（データベ
ース）を付加し、「概念データモデル」と「データベー
ス構造」の両方のモデルの情報を管理する。また、「概
念データモデル」の情報を「データベース構造」の情報
を格納するリポジトリに転送し、「データベース構造」
の初期状態を画面上に表示する機能を持たせる。

【００１３】さらに、従来のデータベース設計支援ツー
ルに、画面上で「データモデル」を作成する機能に加
え、ツールの利用者が、「データベース構造」に含まれ
る実体のシンボルを選択し、画面上で移動した際、実体
を表わすシンボルが重なったことを自動的に検知する機
能を付加する。また、「データベース構造」に含まれる
実体のシンボルが重なったことが検知された場合に、複
数のシンボルを削除し、かつ、新にひとつのシンボルを
画面上に表示し、表示された「データベース構造」の情
報と「データベース構造」の情報を管理するリポジトリ
に格納された情報を等価に保持する機能を持たせる。

【００１４】さらに、「データベース構造」の情報を管
理するリポジトリには、最終的に作成された「データベ
ース構造」の情報のみでなく、ツールの利用者がシンボ
ルを重ねた際のシンボルの組み合わせと、ツールが生成
した新たなシンボルの関連を格納する機能を持たせる。

【００１５】これらの機能により、ツールの利用者は、
ＧＵＩを使用してビジュアルかつ対話的に、必要に応じ
てデータ構造を変更（非正規化）し、「データベース構
造」を作成することができる。

【００１６】また、ツールの利用者に意識させることな
く「概念データモデル」と「データベース構造」の情報
を管理できる。

【００１７】さらに、「データベース構造」の情報を管
理するリポジトリのデータを検索することにより、「デ
ータベース構造」によって表わされる“データベースに
生成されるデータ構造についての情報”と「概念データ
モデル」によって表わされる“データ一貫性制約につい
ての情報”をデータベース設計の終了後に、効率良く有
効に活用できる。

【００１８】

【発明の実施の形態】以下、図面により本発明の実施の
形態を説明する。

【００１９】図１は、本発明のデータベース設計支援ツ
ールの機能構成図である。

【００２０】図２は、データベース設計における画面表
示の例である。本発明の実施の形態は、図２の画面表示
の例を用いて説明する。左上は「データベース構造」を
設計する元になる「概念データモデル」の画面表示であ
る。左下は「データベース構造」の設計の途中結果の画
面表示である。右下は「データベース構造」の設計結果
の画面表示である。

【００２１】図３に、本発明のデータベース設計支援ツ
ールを使用して、「概念データモデル」から「データベ
ース構造」を設計する流れ図を示す。

【００２２】以下、図３に示す流れ図に従い、「概念デ
ータモデル」から「データベース構造」の設計の途中結
果に至る過程を説明する。なお、この過程に先立って、
図１の機能ｄにより、対話的に、「概念データモデル」
が作成され、図１のｂに「概念データモデル」のデータ
が格納されているものとする。

【００２３】１ データベース構造設計事前準備 データベース構造設計の前に、下記の登録を行う。

【００２４】１．１ データベース更新処理生成パター
ン登録 例として、非正規化部分のカラムに対するデータ更新処
理のパターンを登録したものとして以降の説明を行う。

【００２５】１．２ 非正規形インディケータ付与ルー
ル登録（オプション） 非正規形インディケータ付与ルールの例として、非正規
化部分のカラム名称の左に統合元テーブルの名称を
“／”の記号で区切って連結するルールを登録するもの
として以降の説明を行う。

【００２６】１．３ 非正規化ルール登録（オプショ
ン） 重り合った２つの実体の間に、他の実体を介さずに関連
が張られている場合のみ非正規化を許すルールを登録し
たものとして以降の説明を行う。

【００２７】これらの登録内容がどのように機能する
か、後で具体的に説明する。

【００２８】１．４ データベース構造初期状態設定 図１の機能ｉにより、リポジトリ（データベース）ｂに
格納されている「概念データモデル」のデータをリポジ
トリ（データベース）ｃに転送する。

【００２９】下記の［テーブル］．［カラム］の対応の
通り、リポジトリｂのデータを、リポジトリｃに新規追
加する。

【００３０】実体．実体名 → テーブル．テーブル名 属性．属性名 → カラム．カラム名 属性．属性名 → カラム．実体名、 属性．キーＩＤ → カラム．キーＩＤ 関連．ＩＤ → 参照制約．ＩＤ 関連．参照元実体 → 参照制約．参照元テーブル 関連．参照元属性 → 参照制約．参照元カラム 関連．参照先実体 → 参照制約．参照先テーブル 図４に示す概念データモデルリポジトリのデータを新規
追加したデータベース構造リポジトリの状態を図５に示
す。

【００３１】図５のデータベース構造リポジトリのテー
ブル仕様を説明する。

【００３２】・「テーブル」テーブルの主キーは「テー
ブル名」である。

【００３３】・「テーブル」の主キーを表わす「主キ
ー」テーブルの主キーは「ＩＤ」である。テーブルの主
キーは「テーブル名」である。

【００３４】・「カラム」テーブルにおいて、主キーは
「カラム名」と「テーブル名」である。「テーブル名」
は「テーブル」テーブルの外部キーである。「キーＩ
Ｄ」は、「主キー」テーブルの外部キーである。「非正
規形」は、「非正規形情報」テーブルの外部キーであ
る。

【００３５】・テーブルのキーと他のテーブルの外部キ
ーの関係を表わす「参照制約」テーブルにおいて、「参
照制約」テーブルの主キーは、「ＩＤ」である。「参照
元テーブル」と「参照元カラム」は、「カラム」テーブ
ルの外部キーである。

【００３６】「参照先テーブル」は、「テーブル」テー
ブルの外部キーである。

【００３７】これらのテーブルは、主キーの値はユニー
クであり、また、外部キーの値は相手のテーブルの主キ
ーの値として存在する値でなければならないという制約
を持つ。

【００３８】２ データベース構造設計 ２．１ データモデリング（対話処理） 図１の機能ｄにより、対話的にデータベース構造設計を
行う。

【００３９】この機能は、通常のデータベース設計支援
ツールが有する機能である。この機能により、先ず、初
期設定後の概念データモデルリポジトリの内容が、図２
の「初期状態」の通り画面に表示される。

【００４０】ツールの使用者（データベース設計者）
は、データ構造を変更する場合、ポインティングデバイ
スなどを用いて、任意に実体（テーブル）のシンボルを
選択し、他の実体のシンボルの位置に重ね合わせるよう
に操作する。

【００４１】２．２ 実体シンボルの重り検知 図１の機能ｅにより、画面上に表示した実体（テーブ
ル）のシンボルの重なりを検知する。機能ｅは、シンボ
ルの重りを検知すると、直ちに、「非正規化ルールのチ
ェック」の処理を起動する。

【００４２】実体（テーブル）のシンボルの形状が長方
形である場合に、シンボルの重なりを検知するアルゴリ
ズムは次のとおりである。

【００４３】（１）機能ｄから、選択されたシンボルの
位置情報を選択対象位置情報テーブルに取得する。

【００４４】 選択対象位置情報テーブル 機能ｄ 実体名 ← 選択されたシンボルの実体名 上左端Ｘ座標座標 ← 〃 上左端のＸ座標 上左端Ｙ座標座標 ← 〃 上左端のＹ座標 上右端Ｘ座標座標 ← 〃 上右端のＸ座標 上右端Ｙ座標座標 ← 〃 上右端のＹ座標 下左端Ｘ座標座標 ← 〃 下左端のＸ座標 下左端Ｙ座標座標 ← 〃 下左端のＹ座標 下右端Ｘ座標座標 ← 〃 下右端のＸ座標 下右端Ｙ座標座標 ← 〃 下右端のＹ座標 （２）機能ｄから、画面上に表示されたシンボルのなか
で、選択されたシンボル以外の任意のシンボルの位置情
報を比較対象位置情報テーブルに取得する。

【００４５】 比較対象位置情報テーブル 機能ｄ 実体名 ← 任意のシンボルの実体名 上左端Ｘ座標座標 ← 〃 上左端のＸ座標 上左端Ｙ座標座標 ← 〃 上左端のＹ座標 上右端Ｘ座標座標 ← 〃 上右端のＸ座標 上右端Ｙ座標座標 ← 〃 上右端のＹ座標 下左端Ｘ座標座標 ← 〃 下左端のＸ座標 下左端Ｙ座標座標 ← 〃 下左端のＹ座標 下右端Ｘ座標座標 ← 〃 下右端のＸ座標 下右端Ｙ座標座標 ← 〃 下右端のＹ座標 （３）選択対象位置情報テーブルと比較対象位置情報テ
ーブルの位置情報を比較して選択対象と比較対象のシン
ボルの重なりを判断する。

【００４６】重なりを判断するアルゴリズムは次のとお
りである。

【００４７】１）下記の２つの条件を判断する。

【００４８】● 選択対象．上左端Ｙ座標 ＜ 比較対
象．下左端Ｙ座標 かつ、選択対象．下左端Ｙ座標 ＜ 比較対象．上左端
Ｙ座標 ● 選択対象．下左端Ｙ座標 ＜ 比較対象．上左端Ｙ
座標 かつ、選択対象．下左端Ｙ座標 ＜ 比較対象．上左端
Ｙ座標 ひとつでも満たせば下記の２つの条件を判断する。

【００４９】● 選択対象．上左端Ｙ座標 ＜ 比較対
象．上右端Ｙ座標 ● 選択対象．上左端Ｙ座標 ＜ 比較対象．上左端Ｙ
座標 ２．３ 非正規化ルールのチェック 図１の機能ｆ２は、重りが検知されたテーブル（実体）
とリポジトリｃのデータを元に、非正規化ルールのチェ
ックを行う。ここでは、画面上でシンボルの重りが検知
されたテーブル同士をひとつのテーブルとしてデータベ
ース上に定義して良いか否か判定する。

【００５０】判定のアルゴリズムは次のとおりである。

【００５１】（１）重なったシンボルが表わすテーブル
の名称を取得する。仮に、テーブル名称ＡおよびＢが取
得されたものとする。

【００５２】（２）「参照制約」テーブルの「参照先テ
ーブル」をキーとして、テーブル名称Ａと一致するレコ
ードを検索する。

【００５３】（３）検索したレコードの参照元テーブル
のデータがテーブル名称Ｂと一致するならば、“非正規
化許可“と判定する。

【００５４】（４）「参照制約」テーブルの「参照先テ
ーブル」をキーとして、テーブル名称Ｂと一致するレコ
ードを検索する。

【００５５】（５）検索したレコードの参照元テーブル
のデータがテーブル名称Ａと一致するならば、“非正規
化許可“と判定する。

【００５６】（６）上記の過程を全て終了して、“非正
規化許可“と判定されなかったならば、“非正規化不可
“と判定する。

【００５７】機能ｆ１は、判断の結果、非正規化不可で
あれば、処理をデータモデリングに戻す。反対に、非正
規化許可であれば、次の「非正規形情報」の生成の処理
を起動する。

【００５８】２．４ 「非正規形情報」の生成 図１の機能ｆ３は、リポジトリｃに登録されている当該
実体のデータを元に、「非正規形情報」を生成し、その
データを「非正規形情報」テーブルに登録する。

【００５９】「非正規形情報」の生成プロセスは次のと
おり。

【００６０】（１）「非正規形情報」テーブルにレコー
ドを一件生成し、ＩＤを付番する。

【００６１】（２）前述の非正規化可否の判定の過程で
検索された「参照制約」テーブルのレコードのデータで
生成した「非正規形情報」テーブルのデータを更新す
る。

【００６２】テーブル間のデータ更新は次に記す対応で
行う。

【００６３】参照制約．参照先テーブル → 非正規形情
報．統合前実体名 参照制約．参照元テーブル→ 非正規形情報．統合先テ
ーブル名 機能ｆ３により「非正規形情報」が登録された後、続い
て、機能ｄによりデータベース構造リポジトリの最新デ
ータを元にデータベース構造のダイヤグラムを画面に表
示する。

【００６４】２．５ カラム名称変更 図１の機能ｇ２は、機能ｇ１によりあらかじめ設定した
非正規形インディケータ付与ルールに従って、非正規化
の対象となったカラムの名称を変更する。

【００６５】前述の非正規形インディケータ付与ルール
登録例によれば、当該のカラムについてデータベース構
造リポジトリの「カラム」テーブルの「カラム名」のデ
ータの左側に、記号“／”を間にはさんで「カラム」テ
ーブルの「テーブル名」を連結することにより、変更後
のカラム名称を得ることができる。機能ｇは、最後に、
「カラム」テーブルの変更前の「カラム名」を変更後の
カラム名称のデータで置き換える。変更後のカラム名称
は、図７のデータベース構造リポジトリの状態に示す通
りである。

【００６６】この非正規形インディケータ付与ルールで
は、記号“／”の左右の単語を比較して、単語が異なれ
ば、当該のカラムは所属するテーブルに対して非正規形
である。反対に、記号“／”の左右の単語を比較して、
単語が同じならば、当該のカラムは所属するテーブルに
対して正規形である。図７では、“受注明細／受注明細
番号”のようなカラムが、正規形の例である。このよう
に、機能ｇ２によりカラム名称を変更することで、カラ
ムの名称から直ちに非正規形であることを読み取ること
ができる。

【００６７】以上で、図２なかの途中結果の「データベ
ース構造」が画面に表示された状態となる。

【００６８】以降、ツールの使用者が、データベース構
造設計の終了を指示するまで、上記の「データベース構
造設計」の処理を繰り返す。図２に示した「データベー
ス構造」の最終結果が画面に表示るまでデータベース構
造設計を行ったとする。そのときの、データベース構造
リポジトリの状態を、図７に示す。

【００６９】３ コード生成 データベース構造設計の終了後、本発明によるデータベ
ース設計支援ツールは使用者からコード生成の指示を受
けることにより下記の処理を行う。

【００７０】ここでは、図２に示した「データベース構
造」の最終結果まで至ったとして、処理の説明を行う。

【００７１】３．１ データベース定義体生成 データベース設計支援ツールの公知の機能により、デー
タベースの定義体を生成する。

【００７２】３．２ データベース更新プログラム生成 図１の機能ｈ２により、プログラムのソースコードｊを
生成する。このソースコードは、プログラムのコーディ
ングの際に、データベース更新プログラムに書き込むこ
とができる。

【００７３】ここでは、ＳＱＬの構文を用いて「受注明
細」テーブルに含まれる顧客に関するデータを更新する
プログラムの生成例を示す。（カラム名称のなかに
“／”が許されるものとする） ＵＰＤＡＴＥ 受注明細 ＳＥＴ 受注明細／顧客名＝Ｒ１ 受注明細／顧
客業種コード＝Ｒ２ ＷＨＥＲＥ 受注明細／顧客コード＝Ｖ 上記の例の場合、顧客に関するカラム「受注明細／顧客
名」と「受注明細／顧客業種コード」がテーブル「受注
明細」の主キーに対して推移従属である。このような場
合に、データベースのデータ一貫性を保つためには、同
じ顧客を表わすレコードに全て同様の更新を行う必要が
ある。このため、上の例のようなテーブル更新処理を生
成する。この例の更新処理の記述のなかで、更新対象と
なる２つのカラムは、データベース構造リポジトリの
「カラム」テーブルの情報を元に決定している。この例
では、図１のリポジトリｃの「カラム」テーブルの「テ
ーブル名」と「実体名」の値が一致しないレコードを、
当該更新パターンで更新すべきカラムと判断し、更新処
理プログラムのなかにそれらのカラム名を展開してい
る。

【００７４】本発明によるデータベース設計支援ツール
を使用して、データベース構造設計を行った結果、出力
情報として、データベース構造リポジトリ（図１のｃ）
に登録されたデータとデータベース更新処理プログラム
（図１のｊ）が出力される。

【００７５】

【発明の効果】本発明のデータベース設計支援ツールを
使用することにより下記の効果が得られる。

【００７６】・データの一貫性制約が定義できるため、
データベース設計の品質が高まる。

【００７７】・データの一貫性が確保されるため、デー
タベース品質が高まる。

【００７８】・データベースおよびアプリケーションプ
ログラムの保守が容易になる。

【００７９】・非正規形インディケータをカラム名称に
付与することで、カラム名称から直ちにテーブル内の非
正規形部分を識別することができ、非定型の更新や照会
の際でも正確にデータを読み取ることができる。

【００８０】・データベス設計、特に物理設計が効率
化、標準化される。

【図面の簡単な説明】

【図１】本発明のデータベース設計支援ツールの機能構
成図である。図１のリポジトリ（データベース）ｂおよ
びｃの詳細仕様は、図４および図５に示す。

【図２】データベース設計における画面表示の例であ
る。

【図３】本発明のデータベース設計支援ツールにより、
「概念データモデル」から「データベース構造」を設計
する流れ図を示す。

【図４】「データベース構造」を設計する元になる「概
念データモデル」のデータが「概念データモデル」リポ
ジトリに登録されている状態を示す。

【図５】「データベース構造」の初期設定時のデータが
「データベース構造」リポジトリに登録されている状態
を示す。

【図６】「データベース構造」の途中過程のデータが
「データベース構造」リポジトリに登録されている状態
を示す。

【図７】「データベース構造」の途中過程のデータが
「データベース構造」リポジトリに登録されている状態
を示す。

【符号の説明】 ａ…ＧＵＩ端末、 ｂ…「概念データモデル」リ
ポジトリ、ｂ１…「実体」テーブル、ｂ２…「属性」テ
ーブル、ｂ３…「関連」テーブル、ｂ４…「主キー」テ
ーブル、ｃ…「データベース構造」リポジトリ、ｃ１…
「テーブル」テーブル、 ｃ２…「カラム」テーブ
ル、ｃ３…「参照制約」テーブル、 ｃ４…「主キ
ー」テーブル、ｃ５…「非正規形情報」テーブル、ｄ…
データモデリング機能、ｅ…実体シンボル重り検出機
能、 ｆ…非正規化支援機能、ｆ１…非正規化ルール登
録機能、ｆ２…非正規化ルールチェック機能、ｆ３…非
正規形情報生成機能、 ｇ…カラム名称標準化機能、
ｇ１…非正規形インディケータ付与ルール登録機能、ｇ
２…非正規形インディケータ付与機能、ｈ…データベー
ス更新処理生成機能、ｈ１…データベース更新処理生成
パターン登録機能、ｈ２…データベース更新処理生成機
能、ｉ…「データベース構造」初期設定機能、ｊ…デー
タベース更新処理プログラム（ソースコード）。

Claims (3)

【特許請求の範囲】
1. 【請求項１】グラフィカルユーザインタフェース（以
   下、ＧＵＩと略す）を使用して対話的にアプリケーショ
   ンシステムのデータ構造を表わすダイヤグラム（以下、
   「データモデル」と呼ぶ）を作成するデータベース設計
   支援ツールにおいて、 実体（エンティティと呼ばれることもある）と実体間の
   関連（リレーションシップと呼ばれることもある）を表
   わすシンボルを画面に表示することにより正規化された
   データ構造を表わすダイヤグラム（以下、「概念データ
   モデル」と呼ぶ）を作成し、 次に、画面に表示された「概念データモデル」の実体の
   シンボルをマウスなどのポインティングデバイスを使用
   して画面上で任意の位置に移動し、複数の実体のシンボ
   ルの重なりを自動的に検知し、元の「概念データモデ
   ル」の実体間の関連（リレーションシップと呼ばれるこ
   ともある）情報から、重なった実体をデータベース上の
   同一のテーブルとして生成することに矛盾があるか否か
   判断し、重なった複数の実体をデータベースの同一のテ
   ーブルとして生成することに矛盾が無いならば、直ち
   に、テーブルの定義、および、繰返しや推移従属などの
   非正規化情報を生成し、 かつ、重なった実体のシンボルをデータベースのテーブ
   ルを表わすひとつのシンボルに置き換えることにより、
   データベースをアクセスするアプリケーションプログラ
   ム作成上の制約などを考慮して非正規化されたデータ構
   造を表わすデータモデル（以下、「データベース構造」
   と呼ぶ）を作成し、 データベース設計の対象となるひとつのアプリケーショ
   ンシステムについて、「概念データモデル」と「データ
   ベース構造」の両方のデータモデルと両者の関連を管理
   する機能。
2. 【請求項２】請求項１の機能を有するデータベース設計
   支援ツールにおいて、 データ一貫性チェック処理やデータ更新処理のプログラ
   ムを自動生成する機能。
3. 【請求項３】請求項１の機能を有するデータベース設計
   支援ツールにおいて、 「データベース構造」を設計する前に、あらかじめ、画
   面上で重なった複数の実体をデータベース上の同一のテ
   ーブルとして定義して良いか否かについてルールを登録
   し、「データベース構造」の決定方法を標準化する機
   能。