エンティティとリレーションシップ

はじめに

データモデルは，システム開発の対象となった組織体が業務を行うために必要なデータを表したものです．ここでは，データモデルの表現方法としてエンティティ・リレーションシップ図（以下ER図と略記）を使い，データモデルを作成するまでの手順を考察します．

概要でも述べましたが，重要な点は，データモデルはアプリケーションルールやユーザインタフェースから独立していなくてはならない，ということです．したがって，データモデル作成時にはアプリケーションルールやユーザインタフェースのことを考慮してはいけませんし，これらが未定義でもデータモデルは作成可能です．

この資料の順番は“業務概要の記述→ER図の作成”となっています．これは，“業務概要の完璧な記述がER図作成の前提である”ということではありません．“分かる範囲でまとめた業務概要を元に，ER図を書く．その結果，不明点が明らかになり，業務概要が詳しくなる．その結果，ER図の精度が上がる”という繰返しが大切です．“業務概要は記述し終えたのだから，ER図はそれに沿って書かなければならない．業務概要の記述が終わるまで，ER図は書いてはいけない”という手順の固定は無用です．

これは，業務概要とER図との間だけではなく，後述するDFDにも当てはまります．つまり，“業務概要とER図の完璧な記述がDFD作成の前提である”ということではありません．“分かる範囲でまとめた業務概要を元にER図とDFDを書く．その結果，不明点が明らかになり，業務概要が詳しくなる．その結果，ER図とDFDの精度が上がる”という繰返しが大切です．

業務概要の記述

簡単な例として「ソフトウェア管理システム」をあげて話を進めます．データモデル作成の第一歩は，対象となった業務の概要を記述することから始まります．

なお，データモデルはアプリケーションルールやユーザインタフェースからは独立していることを証明するため，保有するソフトウェアの一覧表や蓄積された情報を検索・更新する画面は未決とします．もちろん，実際のシステムには必要です．

ソフトウェアの管理システムです．保有しているソフトウェアや製造元・販売元・アップグレードの履歴を管理します．各ソフトウェアには管理者が存在し，アップグレードの手続きはこの管理者が行います．ソフトウェアの機器への導入は，管理者にライセンスの有無を確認した上で，各担当者が行います．使用しなくなったソフトウェアは各担当者が導入機器から削除し，管理者に連絡します．

最も重要なことは，業務概要の記述とシステム概要（業務概要の実現方法）の記述の違いを認識することです．ここでは業務概要の記述をすべきであり，システム概要（実現方法）を記述してはいけません．

例えば，上記業務概要を下記のように書いてはいけません．これはシステム概要（実現方法）の記述です．

ソフトウェアの管理システムです．保有ソフトウェア管理テーブルや製造元管理テーブル・販売元管理テーブル・アップグレード履歴管理テーブルに必要な情報を保存します．各ソフトウェアには管理者が存在し，ソフトウェア管理者テーブルに職番を登録します．アップグレードの手続きは，全てこの管理者が行い，結果をアップグレード管理画面からアップグレード履歴管理テーブルに登録します．手続きの終了したソフトウェアは，それぞれアップグレード履歴管理テーブルにシリアル番号を登録します．ソフトウェアの機器への導入は，管理者がライセンス使用状況確認画面からライセンス管理テーブルを検索して空ライセンスの有無を確認した後，各担当者が行います．使用しなくなったソフトウェアは各担当者が導入機器から削除し管理者に連絡します．管理者は，ライセンス使用状況確認画面からライセンス管理テーブルを検索し，ライセンス管理テーブルの使用状況フィールドを「使用中」から「空」に変更します．

業務概要とシステム概要は異なるものです．業務概要のつもりがシステム概要を記述したということは，業務概要からシステム概要への変換が担当者の頭の中で無意識に発生したか，システム概要を業務概要と曲解しているのかどちらかです．どちらも避けなくてはなりません．

業務概要としてシステム概要を記述すると，ここに挙げたテーブルや画面・一覧表が「業務の遂行に必須」であるかのような錯覚を引起こします．特に，システム開発の初期に，自分より偉い人の書いたものであればなおさらです．しかし，そのシステム概要は，その業務概要の実現方法方法の一つにすぎません．実現方法の一例を業務概要と同一視してはいけません．

業務概要は業務で使用するデータ（データモデル）とそれらを加工する手段（アプリケーションルール）と人間との接点（ユーザインタフェース）が一体となっています．一体となっていて問題はありません．そのような状態で，第一印象や過去の経験からシステム概要を導き出す，あるいは業務概要とシステム概要を一体にして表現することはあまりにも乱暴なやり方であり，変化に強いシステムの構築方法ではありません．

エンティティ

データモデルの表現方法としてエンティティ・リレーションシップ図（以下ER図と略記）を使用します．まず第一歩として，業務概要からエンティティを抽出します．まず，エンティティを以下のように定義します．

エンティティ

組織体が認識できるもの，および概念．

そして「組織体が認識できるもの・概念」は業務概要に名詞として現れます．

例としてあげたソフトウェア管理システムから以下の名詞をエンティティ候補として抜出します．

• ソフトウェア
• 製造元
• 販売元
• 管理者
• 導入機器
• アップグレード

名詞を抜き出す際には，一般名詞と固有名詞に注意します．例えば，ソフトウェア（一般名詞）はエンティティになりえますが，Windows（固有名詞）はエンティティにはなりえません．

「組織体が認識できるもの・概念そのもの「と，「それらを他者と区別するためのもの」との区別も必要です．例えば，会社はエンティティになりえますが，会社名は「会社」エンティティの属性です．

また，業務概要に現れる名詞である以上，実現方法の一つに過ぎない保有ソフトウェア管理テーブルや製造元管理テーブルはエンティティ候補にはなりません．

ここに上げたものはまだエンティティ候補です．リレーションシップやキーを考慮することで変化していきます．

リレーションシップとキー

ER図には様々な書式が存在しますが，ここではIDEF1Xを使用します．作図にはVisio2000を使用しました．

図1.エンティティとリレーションシップ（依存リレーションシップ）

これは，次のような関係をあらわしています．

• 製造元を一つ（例えばマイクロソフト）決めると，ソフトウェアが複数（ウィンドウズ, エクセル, ワード・・・）決まる．
• ソフトウェアを一つ（例えばノーツ）決めると，製造元は一つ（ロータス）決まる．
• 製造元は製造名称により，他の製造元とは区別できる．すなわち，製造元エンティティの主キーは製造元名称．
• ソフトウェアはソフトウェア名称と製造元名称により，他のソフトウェアとは区別できる．すなわち，ソフトウェアエンティティの主キーはソフトウェア名称と製造元名称で製造元名称は製造元エンティティからの外部キーとなる．

この例の場合，製造元とソフトウェアは1:nの関係（製造元を一つ決めるとソフトウェアは複数決まり，ソフトウェアを一つ決めると製造元は一つ決まる）にあります．1:nの1にあたるエンティティを親エンティティ，nにあたるエンティティを子エンティティと呼びます．子エンティティを一つ決めるためには，親エンティティのキーが必要となる場合，親エンティティと子エンティティの間を依存リレーションシップで結びます．

ソフトウェアを一つ決めるために製造元名称は不要な場合，複数の製造元を持つ同名のソフトウェアは存在しない場合，親エンティティと子エンティティの間は非依存リレーションシップで結び，次のように記述します．

図2.エンティティとリレーションシップ（非依存リレーションシップ）

製造元名称がなくてもソフトウェアを区別できるため，製造元名称は主キーから属性に変ります．

では，抜出したエンティティと２種類のリレーションシップを使い，ソフトウェア管理システムのデータモデルを作成します．

図3.ER図 第１案

1:nに整理できない場合

ソフトウェアと販売元はn:nの関係になります．すなわち，ソフトウェアを一つ決めるとそれを購入した販売元は複数決り（同じソフトウェアを異なる店で購入），販売元を一つ決めると，そこから購入したソフトウェアが複数決まります（同じ店から異なるソフトウェアを購入）．

このような場合には，ソフトウェアと販売会社の関係を 1:n にするため，両方の基本キーを外部キーとして持つエンティティ（ここでは「購入」）を作成します．

図4.n:nから1:nへの変換

管理者は，現在の管理者のみ把握していますが，過去の管理者も対象にします．そうすると，エンティティ「ソフトウェア」とエンティティ「管理者」との関係はn:n（一つのソフトウェアには購入以降複数の管理者が存在し，一人の管理者は複数のソフトウェアの管理を行う）となります．エンティティを追加します．追加したエンティティに付ける適当な名前を思いつかないときには，とりあえず親エンティティの名前をつなげておきます．この場合，親エンティティは「管理者」と「ソフトウェア」なので「管理者・ソフトウェア」と仮に名づけます．

この修正を加えたER図は以下のようになります．

図5.ER図 第２案

なお，n:n のリレーションシップが引き起こす問題については付録１を参照してください．

見直す

同じ店で同じソフトウェアを違う日に購入することもあります．エンティティ「購入」ではこれに対応できません．したがって，購入日時を主キーに含めます．

図6.ER図 第３案

エンティティ「ソフトウェア」のキーは「ソフトウェア名」となっています．しかし，物理的なもの（箱に入ったCDやマニュアル）とライセンスとは別物です．ソフトウェアの箱は一つしかなくても，ライセンスを複数購入すれば複数の機器に導入できます．第２案のER図ではライセンスの管理ができません．そこで，「ソフトウェア」のキーをライセンス番号とします．

図7.ER図 第４案

エンティティ「購入」に注目します．これは，複数のソフトウェアを複数の販売元から購入することがあるために作成したエンティティでした．しかし，エンティティ「ライセンス」の導入により，ソフトウェアの購入単位はソフトウェア名で認識できるものからライセンス番号で認識できるものに変化しました．こう考えると，一つの販売元から複数のライセンスを購入することはあっても，一つのライセンスを複数の販売元から購入することはありえません．ライセンスと販売元は1:nの関係に変化します．したがって，販売元と購入日時をエンティティ「ライセンス」の属性に移し，エンティティ「購入」はなくします．

図8.ER図 第５案

属性間の依存関係の解消

エンティティ「ソフトウェア」の属性を注意してみると，ライセンス番号が異なってもソフトウェア名が同じならば製造元名称は同じであることに気が付きます．つまり，エンティティ「ソフトウェア」の属性「製造元名称」は主キーである「ライセンス番号」ではなく，「ソフトウェア名」に依存しています．主キー項目以外の属性間に依存関係のある場合は，エンティティを複数に分割し，依存関係を解消します．

エンティティ「ソフトウェア」をソフトウェア名を主キーとするものとライセンス番号を主キーとするものに分割します．ソフトウェア名を主キーとするエンティティを「ソフトウェア」，ライセンス番号を主キーとするエンティティを「ライセンス」とします．なお，属性間にある依存関係が引き起こす問題については付録２に記述しました．

図9.ER図 第６案

さらに見直す

できあがったER図をもう一度見直します．更に以下の修正を加え，最終案とします．

• 製造元と販売元はどちらも同じ属性を持ち，どちらも「取引先」をさしている．そこでこの二つエンティティをエンティティ「取引先」として統一し，「製造元」はエンティティ「ソフトウェア」にある「製造元名称」，「販売元」はエンティティ「ライセンス」の「販売元名称」として区別する．
• エンティティ「管理者」はエンティティ「社員」としたほうが一般的である．
• エンティティ「管理者・ライセンス」をエンティティ「管理者」とする．

図10.ER図 最終案

まとめ

これまでの内容をまとめます．まず，最も大切なことです．

• データモデルはアプリケーションルールやユーザインタフェースから独立している．

この文章では，データモデルの表現方法としてER図を使用し，以下の手順で作成しました．

1. 業務概要を文章にまとめる．この際，システム概要を記述してはならない．
2. 業務概要から名詞を抜き出し，これらをエンティティとする．
3. エンティティとは「組織体が認識できるもの，および概念」である．
4. エンティティとエンティティとの依存関係を 1:n に整理する．
5. 主キー以外の属性同士の依存関係を解消する．

付録１ n:n のリレーションシップが引き起こす問題

図3. ER図 第１案の，エンティティ「ソフトウェア」とエンティティ「販売元」は n:n の関係にあります．すなわち，ソフトウェアを一つ決めるとその販売元は複数決まり（例えば，同じソフトウェアを違う店で購入），販売元を一つ決めるとそこから購入したソフトウェアも複数決まります（例えば，同じ店で違うソフトウェアを購入）．

n;nのリレーションシップは両エンティティのキー項目にお互いのキー項目を持たせて表現します．エンティティ「ソフトウェア」にはそのソフトウェアを購入した販売元名称を，エンティティ「販売元」にはその販売元で購入したソフトウェア名称を持ちます．

図11.n:nのリレーションシップ

エンティティ「ソフトウェア」を例に，具体的な値を入れて問題点を検証します．まず思いつくのはこのようなものです．

この状態では，特に問題があるとは思えません．しかし，ここでちょっとひねくれて考えてみましょう．エンティティ「ソフトウェア」の主キーはソフトウェア名称と販売元名称です．ここが異なっていれば別のデータです．つまり，このように値が入っていても何の問題もありません．

つまり，n:nのリレーションシップでエンティティに不要な主キーを持った状態では，「ソフトウェア名称が同じなら製造元も同じ」という事実を表現できません．

でも，これってバグですよね．

その通り，これはバグです．「ソフトウェア名称が同じなら製造元も同じ」でなければならないにもかかわらず，「ソフトウェア名称が同じなのに異なる製造元が入っている」のですから確かにバグです．

しかし，ソフトウェア名称が同じなのに異なる製造元が入る「プログラムのバグ」ではなく，ソフトウェア名称が同じなのに異なる製造元が入る「データモデルのバグ」です．ソフトウェア名称が同じなら同じ製造元が入るように「プログラムを作る」のではなく，ソフトウェア名称が同じなら同じ製造元が入るように「データモデルを作る」必要があるのです．

次のようなデータモデルを思いつく方もいるかもしれません．

図12.n:n修正案

「製造元が重複する原因は，エンティティ「ソフトウェア」の主キーに販売元名称があるから．だったら，エンティティ「ソフトウェア」の主キーから販売元名称を外せばどうだろう」と言うわけです．

これなら「ソフトウェア名称が同じなのに異なる製造元が存在する」ことはなくなります．しかし，エンティティ「販売元」には，これまで述べたことと同じ問題が発生します．すなわち，「同じ店で買ったのに，買ったソフトウェアが違うと住所が違う」という問題です．具体的な値を入れると，このようになります．

つまり，このデータモデルでは，「ソフトウェア名称が同じなら製造元名称も同じ」という事実は表現できても，「販売元名称が同じなら住所も同じ」という事実は表現できていません．

1:nのリレーションシップにした場合も同様に，具体的な値を入れて検証します．

図13.1:nのリレーションシップ

エンティティ「ソフトウェア」の主キーはソフトウェア名称のみとなるため，ソフトウェア名称に対応する製造元は一つです．販売元によりソフトウェアの製造元が異なる不具合はなくなります．

エンティティ「販売元」の主キーは販売元名称となるため，販売元名称に対応する住所は一つです．ソフトウェアにより販売元の住所が異なる不具合はなくなります．

• ソフトウェア名称が同じでも販売元が異なると異なる製造元が入るが，ソフトウェア名称が同じなら同じ製造元を入れるように気をつける．
• 販売元名称が同じでもソフトウェア名称が異なると異なる住所が入るが，販売元名称が同じなら同じ住所を入れるように気をつける．

• ソフトウェア名称が同じなら同じ製造元名称しか入らない．
• 販売元名称が同じなら同じ住所しか入らない．

どちらが安全で信頼できるかは言うまでもありません．

付録２ 属性間の依存関係が引き起こす問題

「図8.ER図 第５案」の中のエンティティ「ソフトウェア」の属性には，主キーである「シリアル番号」に依存して決まるもの「ソフトウェア名・販売元名称」と，主キー以外の属性である「ソフトウェア名」に依存して決まるもの「製造元名称」が混在しています．このような構造のエンティティが持つ問題点を具体的な値を入れて考えます．

この状態では，特に問題があるとは思えません．しかし，ここでちょっとひねくれて考えてみましょう．エンティティ「ソフトウェア」の主キーはライセンス番号です．ここが異なっていれば別のデータです．つまり，このように値が入っていても何の問題もありません．

つまり，主キー（ライセンス番号）以外の属性（ソフトウェア名称）に依存して決まる項目を持つ状態では，「ソフトウェア名称が同じなら製造元も同じ」という事実を表現できません．

エンティティをソフトウェアとライセンスに分けた場合も，同様に具体的な値を入れて検証します．

エンティティ「ソフトウェア」は主キーがソフトウェア名称であるため，ソフトウェア名称が同じなら製造元名称も同一です．同じソフトウェアでもライセンス番号が違うと製造元が異なる不具合はなくなります．

• ソフトウェア名称が同じでもライセンス番号が異なると異なる製造元名称が入るが，ソフトウェア名称が同じなら同じ製造元名称を入れるように気をつける．
• ソフトウェア名称が同じなら同じ製造元名称しか入らない．

どちらが安全で信頼できるかは言うまでもありません．

参考文献

林衛 "データ中心設計のためのERモデル・システム分析／設計法" ソフトリサーチセンター 1993

Audrey M. Weaver "USING THE STRUCTUAED TECHNIQUES A Case Study" Prentice-Hall, Inc 1987（神間清展 "構造化技法を使いこなす" 総研出版 1989）

James Martin, Joe Leben "Strategic Information Planning Methodologies 2nd Edition" Prentice-Hall, Inc 1989 （坂本広，山崎五郎 "Ｊ．マーチンの情報システム計画方法論" 日経BP社）

Arthur Young Information Technology Group "The Arthur Young practical guide to information engineering" Arthur Young & Company 1987 （高梨智弘，竹本則彦 "管理職のためのインフォメーションエンジニアリング" 日経BP社）

C J. Date "An Introduction to Database System 3rd Edition" Addison-Wesley 1975 （藤原譲 "データベースシステム概論" 丸善 1985）

日経オープンシステム 1994年10月号 no.19 p.285-296 "AccessとVBユーザのためのDB設計入門（Ｉ）"

日経オープンシステム 1994年11月号 no.20 p.249-260 "AccessとVBユーザのためのDB設計入門（II）"