概念モデルの記述に使われる実体関連図（ERD）
初めにデータベースを作成する目的を決めておくこと。データモデルを作る過程では常に目的を意識して取捨選択しよう。
実世界の注目する部分を抽出して、データの纏まりや関連を整理し、簡潔なモデルを作成する。利用目的から見て抜けが無いことが必要である。
※関係ありそうなデータ項目を何でも入れたモデルにしようとすると、切りがない。データベースを作る目的に応じて判断しよう。
誰が見ても理解できることも重要。他者の理解を可能にするには、モデルをどの様に記述するか共通の枠組みが必要になる。ER図が良く使われる。
データは互いに関係を持っているので幾つかの纏まりに切り分けて整理したい。まずは、纏まりが明らかな部分を実体（Entity）として切り出す。
例えば履修管理システムを作ろうとしているのなら、「学生」や「科目」などが実体の有力候補となる。学生は学生名や住所などのデータの纏まり、科目は科目名や単位数、講師名などのデータの纏まりとして切り出すことができるだろう。
実体「学生」は個々の学生を要素とする集合（Set）である。要素の一意識別がデータ値のみでできるように、値の組が全て同じ要素は無いことにする。
※要素値に重複が無いことは集合の要件。
履修管理システムであれば、学生がどの科目を履修しているかこそが重要なデータである。例えば、（科目名、学生名、成績）のようなデータの組を要素とする集合を「履修」として切り出すことができる。ここで科目名や学生名は実体の科目や学生の要素に同じものがあるはずだ。このような制約から履修は2つの実体の関連を示すので関連(Relationship)と名前を付けて実体とは分けて扱うことにする。
このようにしてデータを実体とその間の様々な関連で切り分けて整理し、これを図にしたものを実体関連図：ER図と呼ぶ。ER図はデータ構造の概念モデルを表現するために良く使われる。
DBMSが用意したデータモデル（リレーショナルデータモデルなど）で概念データモデルを実装する論理データモデル（データベースの概念スキーマ）を作成する。
応答速度なども考慮してたDBMSに実装するモデルを作る。
提唱者ピーター・チェン（Peter P. Chen）による表記法 で、教科書で紹介されているもの。多対多の関連や関連の属性など表現はシンプルで分かりやすい。概念設計には向くと思う。
北川博之著「データベースシステム」（株）昭晃堂 の図2.8を元に教員の担当を加えたER図
実体名を四角の中に書き、属性は四角から引き出された線の先に楕円で囲んで記述する。これにより実体を構成する各要素がもつ属性を示す。実体の要素は各属性の値の組である。
実体は要素の集合である。従って、全属性値が同じ要素は存在しない。しかし、全属性値を比較して同じ値の要素を作らないようにするのは手間がかかる。そこで、概念モデルの時点で要素を一意に識別するための属性値を決めておくことにする。このような属性を主キー（primary key）と呼ぶ。
学生は属性：名前と住所の組とした。名前だけでは同姓同名の学生が存在するので住所まで加えれば区別がつく。従って2値の属性の組を主キーとすることが可能である。しかし、2つの属性をいちいちチェックするのは面倒なので人工的な属性「学籍番号」を実体「学生」に加え、学籍番号を学生の主キーとすることが多い。
主キー属性は下線を付けて示す。属性の集合で主キーを構成できる場合は通常実体集合とよび、できないものを弱実体集合と呼ぶ。二重の四角で表記。弱実体集合は他の実体集合との関連を通して識別される。
他との関係なしに独立した纏まりとして扱うことにしたデータ構造。
例えば履修管理システムを作ろうとし、科目と学生は予め存在する主要な実体と捉えたとしよう。学生は次の図のような実体としてモデル化できる。
※そのまま論理設計時のリレーションになる。
関連先の実体の属性を含めないと一意識別できない実体。
※論理設計時は識別可能とする関連先の主キーを外部キーとし、弱実体集合の主キーに含めることで識別可能なリレーションとする。この結果、弱実体集合は以下で出てくる依存エンティティーに対応し、識別親との関連は依存リレーションシップとなる。
関連名を菱形の中に書き、属性は菱形から引き出された線の先に楕円で囲んで記述する。菱形から関連する実体に対して線を引く。線の上に多重度を示すことができる。（min,max）を記述することで参加制約を示す。
概念モデルでは関連と実体の関係は線で示す。しかし、論理設計の段階では実体の要素とのつながりを示す属性が関連側に不可欠で、これを外部キー（foreign key、FK）と呼ぶ。外部キーの値は関連先の実体の主キーの値に一致することで繋がりをしめす。
科目と演習課題の関連「実習」は科目1に対して演習課題は多（0を含む）で １：Nの関連である。
より詳しく実体と関連の関係を見れば、科目から見た実習は(0,N) で0を含んで多数となり 参加は部分的で実習の無い科目もある。逆に演習課題から見た実習は(1,1) で1のみとなり 参加は全面的で演習課題は何らかの科目と必ず関連している。
論理設計時のリレーションへの変換は関連先の実体を参照する外部キーを主キーとし属性を非キー属性として構成できる。しかし、1対多の関連については多の側の実体のリレーションに属性として含めてしまうことも可能である。
※関連に属性がある場合はこれも多の側の含める
※1対1の関連も関連を示す外部キーをどちらかの実体に加えることで、同様になる
例：1対多
科目の場合は担当教官が居るのが通例であり科目に主担当教員番号を属性として追加しても無駄に科目リレーションを大きくすることにはならない。
例：1対1
TAが付く科目が例外的であればTAの側に担当科目の外部キーを入れるほうが、データの空欄を作らない意味では適当と思われる。ただ科目のデータから担当TAの有無は判断できないので、有無を調べるときはTAのデータを毎回検索する必要が生じる。
※1科目に複数のTAが付く可能性があるか？ TAが複数の科目を担当する可能性があるか？論理設計では考慮しておく必要がある。
論理設計において関連に対応したリレーションを作る必要がある。
学生がTAを行っているときTAのデータは学生を継承しているとしてモデル化できる。
継承関係は is a や kind of で表現される関係なので 分類と読み替えもできる。
二輪車、三輪車、四輪車は車の一種 ＜＝＝＞ 車は二輪車、三輪車、四輪車などに分類できる
２つの表記法はいずれもRDBの概念、論理の設計を一貫して支援するツールで採用されている表記法で、論理の設計の都合からか関連は属性を持たず、外部キーの形で表現されている。実体は独立と依存の2種類に分けられ、いずれもRDBの表に対応するものとなっている。 多対多の関連は関連に対応した実態を導入して1対多の関係に分解していく。以下に概要をまとめてみた。
※以下の図はhttp://astah.change-vision.com/ja/のastah*professional6.6.3を使って作成したER図です
米国標準技術研究所（NIST： National Institute of Standards and Technology）でFIPS 184として規格化。RDBの論理設計を前提にした制約事項が多い感じ。記号の意味がなれないと掴みにくい。
ER図（IDEF1X表記法）
蛇足：学生の履修への参加を全面的にしたが、この制約をいつの時点で適用するのかは、かなり問題があるかもしれない。
四角の中を上下に2分し属性を表記する。上段は主キー属性、下段は非キー属性。外部キーは（FK)の様な記述で示す。
関連は基本的には親エンティティーから子エンティティーに引かれた線で表記し子の側に黒丸●を付けて向きを示す。リレーションシップ名は「親は子を？？？？」の？？？？の 動詞句を用いる。例：「会社は社員を雇用する」。リレーションシップを付けると、自動的に子の側にリレーションシップ の親を指す外部キーが属性として挿入される。
基本となるのは親から子への1対多の関連である。
※多対多の関連は両端に黒丸の実線で示される。
教科書で紹介されたチェンの記法では関連が属性を持つ場合があるが、リレーションシップ が属性をもてないこの記法では、関連の属性を子の属性として格納することになる。多対多の関連では関連の属性を子の属性に入れることは不可能なので、アソシエーション・エンティティーを新しく作って属性を格納し、複数の1対多の関連に書き換えることが必要になる。3項関連なども同様にして新しいエンティティーを導入して1対多の2項関係に書き換えることになる。
関連の子に親の属性が外部キーとして含まれ、かつNULL値が許されないとき、子は依存エンティティー、関連は依存リレーションシップと呼ばれる。
子エンティティーの対応数を黒丸に併せて記述する。
P： 1以上 親のリレーションシップへの参加が全面的となる。
Z： ０または1
5： 5 固定された数
オプション記号
親の側の多重度は基本的には1である。しかし、非依存リレーションシップ の場合には対応する外部キーは子の主キー属性ではないので値にNULLを許すことが可能になる。オプション記号の中空の菱形を点線の親側の端につけることで、外部キーにNULL値が許されることを示す。子のリレーションシップへの参加は部分的になる。
親エンティティーを分類して子エンティティーを作ることができる。オブジェクトの継承に相当する。丸の下に引いた線が2本の場合は親が子に完全に分類されて居る場合で確定分類。線が1本の場合は親の一部が分類されただけの場合で未確定分類
俗に「鳥の足」 と呼ばれるもの。図の上で外部キーを省略したり、関連を示す線に依存/非依存の区別のために実線/点線を用いるものなどいくつかのタイプがあるようです。（IE:インフォメーション・エンジニアリング）
ER図（IE表記法）
四角形の上にエンティティー名、枠の上段に主キー属性枠の下段非キー属性。
全て実線で示され依存・非依存の区別は本来は無いらしいが現在は実線と点線で区別するツールもある。
カーディナリティは独自の記号で示される
○：０以上 子の側に○なら親の参加が部分的、親の側に○なら子の参加が部分的になる
線：１以上 子の側に引かれれば親の参加が全面的、親の側に引かれれば子の参加が全面的になる
鳥の足：多
IDEF1Xとは記号が異なるが対応している
前記のER図をツールの機能を利用してクラス図に書き換えてみました。
主キー(PK)や外部キーをステレオタイプや関連を用いて表現しています。
TAの主キーの学籍番号は継承を行っているのでTAの枠から消されています。
履修の主キーは学籍番号と科目番号で外部キーでしたが、ステレオタイプIdentifyingのコンポジションな集約関連に書き換えられました。
※変換結果では関連の誘導方向は示されませんでした。これは元のER図には情報が無いためと思われます。java言語などで実装する場合、履修側に科目と学生を参照するメンバを持ってもいいし、逆に学生や科目側に履修への参照リストを置いてもいいわけです。利用効率の為に、両方用意しても構わないでしょうが、その場合は関連情報を重複して持つことになります。
