初めてのデータベース設計

第2回 IDEF1XによるER図の記述

この記事を読むのに必要な時間:およそ 1.5 分

前回は,論理設計のデータモデリングにはERモデルを使用すると説明しましたが,ERモデルはER図を使用して表現することができます。ER図の記述方法にはいろいろなものがありますが,今回は,一般的に普及しているIDEF1XによってER図を記述する方法について説明します。

IDEF1Xとは

IDEF1Xは,IDEF(Integration Definition)と呼ばれる,システムをさまざまな側面から分析してモデリングを行うための方法の1つで,おもにデータベースの概念設計においてER図を記述する方法としてよく使用されます。

また,IDEF1Xは,米国のNIST(国立標準技術研究所)によってFIPS(連邦情報処理標準)として標準化されており,IE(Information Engineering)と並んでER図の記述方法として一般的なものです。

IDEF1Xでは,ERモデルにおける実体を四角形として記述し,四角形との間に線を引くことによって関連を表現します。たとえば,「社員が部署に所属する」ということは,図1のようにER図として記述することができます。

図1 社員と部署の関係をER図で描くと…

図1 社員と部署の関係をER図で描くと…

実体の記述

実体は四角形として表現され,四角形の上には実体名を記述します。また実体は,他の実体に依存せずに存在できる非依存実体(Identifier-IndependentEntity)と,依存して存在する依存実体(Identifier-Dependent Entity)に分けることができます。なお,依存実体は角の丸い四角形として記述されます。たとえば,社員はいずれかの部署に必ず所属するということであれば,「社員」は依存実体ということとなります。

図2 非依存実体と依存実体

図2 非依存実体と依存実体

属性の記述

実体を表現する四角形の中には属性を記述します。属性については,四角形を線で上下に分け,四角形の上には主キー(Primary Key)となる属性(主キー属性;Primary-Key Attributes),下には主キーでない属性を記述します。また,外部キー(Foreign Key)となる属性には属性名の後ろに「FK」という文字をカッコで括って記述します図3)。

図3 属性の表現例

図3 属性の表現例

主キーとなる属性は,その属性によって実体を一意に特定することができるものです。たとえば,「社員番号」を指定することにより,それに対応する「社員」が一人に特定できる場合,「社員番号」「社員」において主キーとなります。また,外部キーとなる属性は,他の実体において主キーとなっているものです。たとえば,「社員」では「部署」の主キーである「部署番号」が外部キーとなります。

関連の記述

実体間の関連は四角形の間に線を引くことによって記述し,依存実体との関連には実線,非依存実体との関連には破線を使用します。線の横には関連名を記述します。また,関連によってつながった実体間には親子関係が成り立ち,子となる実体に結び付けられた線の先には黒く塗り潰された円を記述します図4)。

図4 関連の記述法とその例

図4 関連の記述法とその例

なお,黒く塗り潰された円の横には関連の多重度(カーディナリティ)を記述することができます。多重度とは,実体間が何対何でつながっているかということを表現するものです。多重度には図5のようなものが定義されています。

図5 多重度の表現

図5 多重度の表現


今回は,ER図の記述方法としてIDEF1Xについて説明しました。これでひととおりER図を読み書きできるようになったと思います。ただし,IDEF1Xには今回説明できなかった記述方法も存在します。これらの詳細については以下のURLを参照してください。

http://www.idef.com/IDEF1X.html

また,ER図の記述方法を理解できたとしても,システムを分析してモデルを作成することはなかなか容易ではありません。まず,システムの業務フロー図などを作成して全体を把握し,そこから実体や関連を抽出して徐々にブラッシュアップしていくといいでしょう。

次回は,概念設計において作成したERモデルをリレーショナルモデルに変換する手順について説明します。また,その中では正規形と呼ばれる,リレーショナルモデルとして適切な形式についても紹介します。

著者プロフィール

佐藤友章(さとうともあき)

SRA OSS, Inc. 日本支社 チーフエンジニア。入社以来,オープンソースデータベースPostgreSQLに関する業務に携わり,現在,PostgreSQLのサポートやコンサルティング,トレーニングの講師を務める。

URLhttp://www.sraoss.co.jp/

コメント

  • 質問

    部員コード、部員名、月、部員売上、部署コード、部署名

    上の表は、部員それぞれの売上高を示すものである。
    上の表に関してデータベースを設計するための、ER図はどのようになるのですか?

    Commented : #3  ゆう (2010/04/22, 21:25)

  • ご質問へのコメント

    gihyo.jpのご利用ありがとうございます。
    遅くなりましたが,「図1は誤っていませんか?」のご質問に対して,著者の佐藤さんから回答をいただきましたので,以下にご紹介します。
    -----------------

    おっしゃるように図1は誤っておりました。たいへん申し訳ございません。「社員」は,「部署」と独立して存在できるため,非依存実体となります。

    依存実体の説明としては,「部署」と「社員」の間に「所属」という実体を記述し,その主キーとして「部署」の「部署番号」,「社員」の「社員番号」という外部キーの組み合わせを記述した場合,「所属」は依存実体となるという説明が正しいものとなります。

    また,図2~4においても「社員」が依存実体として記述されていますが,正しくは非依存実体となります。

    Commented : #2  gihyo.jp編集部 (2008/06/03, 10:01)

  • 図1は誤っていませんか?

    記事中の図1ですが、社員エンティティで部署番号がPKに入らないのであれば、非依存型のエンティティになりませんか?
    必ずあるなしはカーディナリティの話であって、依存非依存とは無関係ではないかと。

    Commented : #1  通りすがり (2008/05/22, 19:05)

コメントの記入