実体関連図とは

データベース設計のリレーショナル・モデルにおいて、ERDはデータベース内のエントリがどのように接続されているかを確立します。ERDは、より高度なデータベース設計と分析の基盤となる高レベルの概念データ・モデルです。

また、実体関連モデリングは、一見関連性のないデータ・ポイント群から、ストーリーやインサイトを導き出すのに有効です。

ビジネス・アナリストやデータベース・エンジニアは、ER図をデータ・モデリング・ツールとして使用して、組織に必要なデータベースの範囲を評価し、データの保存方法を計画します。

ERDは、情報システム・アーキテクチャーとデータベース構造の要件を示すことにより、データベース・プロジェクトのソフトウェア・エンジニアリング部分に情報を提供します。データベース管理システム（DBMS）のソフトウェア・エンジニアリングにおける3層スキーマ・アプローチでは、ERDは概念スキーマに該当します。

データ統合は、多くの変動要素から成る、複雑なデータ・エンジニアリング・プロセスです。ERDは、データ・エンジニアがシステム全体を概念化し、エラーの発生可能性を低減するのに役立ちます。

既存のデータベースをERDと比較することで、問題の原因となりうるデータベースの設計ミスを明らかにすることができます。多数のテーブルを含む複雑なデータベースのデバッグ・プロセスでは、広範なSQL知識が必要です。データベースの要点を表現するERDで、エンジニアは潜在的なエラーを迅速に特定できます。

ビジネス・プロセス・リエンジニアリング・プロジェクトを推進する際、組織の情報システムに存在するすべてのデータを俯瞰できると便利です。ERDは、BPRプロセスの他の段階を円滑に進める、より新しくより効率的なデータ・アーキテクチャー・ソリューションを草案するために使用されます。

実体関連図、データベース・スキーマ、データ・フロー図はすべて、システム内のデータの配置を視覚的に表現します。

• 実体関連図は、データベース内のエンティティーとその相互関係を示します。ER図は多くの場合、データベースのスキーマを描いています。

• データベース・スキーマは、実世界におけるエンティティーが、リレーショナル・データベース内でどのようにモデル化されるかを確立します。これらには、テーブル名、フィールド、データ型など、データベースの構成を決定するルールとガイドラインが含まれています。

• データ・フロー図は、プロセスまたはシステムを介したデータの流れを表すフローチャートの一種です。これらは、データがプロセスから内部および外部のストレージの場所にどのように移動するかを示します。

実体関連図にはエンティティー、エンティティーの属性、およびエンティティー間の関係が含まれます。一部のERDは、2つのエンティティー間の関係を定量化するカーデイナリティーも表します。

ERDエンティティーは、人物、役割、イベント、概念、オブジェクトなどの定義可能なもので、エンティティーに関する情報をリレーショナル・データベースに保存できます。多くの実体関連図は、エンティティーを長方形で表します。

• 人や役割：学生、営業担当者、経営者、顧客など。
• イベント：トランザクション、サインアップ、または配信停止。
• コンセプト：プロフィールまたはペルソナ。
• オブジェクト：商品、請求書、Eメール。

エンティティーは、文法的な意味で名詞に似ています。これらはデータベースの中核となる項目であり、文中の名詞について形容詞や動詞がより多くの情報を提供するのと同様に、属性と関係がこれらのエンティティーに関する情報を伝えます。

エンティティー・タイプはエンティティーのカテゴリーです。エンティティーが名詞に類似している場合、エンティティー・タイプは名詞カテゴリー（食べ物、スポーツ、国）になります。エンティティー・タイプ内の個々のエンティティーはインスタンスと呼ばれます。エンティティー・タイプ内では、野菜はブロッコリー、ニンジン、アスパラガスなどのインスタンスかもしれません。

エンティティーは、強エンティティーまたは弱エンティティーのいずれかに分類されます。強エンティティーには、属性に十分な識別情報が含まれており、それ以上明確化する必要はありません。一方、弱エンティティーは、他のエンティティーの結果または派生としてのみ存在します。特定の弱エンティティーに関連付けられた強エンティティーは、その親エンティティーまたは所有者エンティティーと呼ばれます。

Eコマース・ビジネスにおける顧客の注文のデータベース・モデリングを考えてみましょう。各注文は、購入者、時刻、日付に基づいて一意のインスタンスとして定義できるため、強エンティティーです。ただし、各オーダー内の明細は弱エンティティーです。それらは、それぞれの注文内でのみ意味を持ちます。この依存関係は、存在従属性または参加制約と呼ばれます。

ERDでは、強エンティティーは実線の長方形で表現され、弱エンティティーは二重線の長方形で表現されます

関連エンティティーは、2つのエンティティー・セット間のインスタンスをリンクし、その関係に関する詳細情報を提供する独自の属性を持っています。大学で使用されるERDでは、エンティティーは学生と教授が相互に多くのつながりを持っているように設定されます。2つの橋渡しをする関連エンティティーは、どの教授が教えるコースをどの学生が受講しているかを示します。

リレーショナル・データベースは、関連エンティティーを使用して、他の複数のデータベース・テーブルのフィールドを結合する結合テーブルに情報を提供します。ER図では、関連エンティティーは長方形内のひし形で描かれます。

属性とは、エンティティーまたはエンティティー・タイプを定義する品質、プロパティー、および特性です。従来のERD設計では、属性は楕円形で表現され、ERD内の対応するエンティティーの隣に表示されます。

• 単純属性は、属性を単純化したりさらに分割したりすることはできません。郵便番号は単純属性の例です。

• 複合属性は、他の属性で構成され、構成する属性は単純属性のことも複合属性のこともあります。住所は、番地、町村、郵便番号、市区、およびその他の識別情報を含む複合属性です。

• 導出属性は、他の属性に基づいて計算されます。従業員の給与額は、労働時間、給与期間、および賃金から算出されます。ERDは、導出属性を破線の楕円で表現します。

• 複数値属性はレコードごとに複数の値を持つことができますが、単一値属性は持つことができません。

エンティティー・キーは、データ・セット内の各エンティティーを一意に定義する属性です。この役割を果たす属性は、キーとして指定できます。例えば、人間のエンティティー・セットでは、適切なキー属性は政府発行のID番号である場合があります。逆に、複数の人が同じ姓を持っている可能性があるため、姓はこの文脈ではキー属性として機能しません。

• スーパーキー：エンティティー・セット内でエンティティーを一意に定義できる1つ以上の属性。

• 候補キー：可能な限り最もシンプルなスーパーキーであり、候補キー内のいずれの属性も、それ自体がスーパーキーになることはありません。各属性がスーパーキーでない場合、候補キーは1つ以上の属性で構成される場合があります。

• 主キー：候補キーは、エンティティーセットを一意に定義するために選択されます。主キーは各エンティティーを区別するものであるため、データベース内のいかなる2つのレコードも同一の主キー値を持つことはできません。ER図では、各エンティティーの主キーには下線が引かれます。主キーを含むエンティティーはすべて強エンティティーとみなされます。

• 外部キー：あるエンティティーと他のエンティティーとの関係を識別する属性。弱エンティティーを識別するには、強エンティティーからの外部キーが必要です。例えば、弱エンティティーである銀行口座は、関連する銀行にリンクする外部キーが必要です。

リレーションとは、ERD内のエンティティー同士を結び付ける線です。リレーションは、ERD内のエンティティーが相互にどのように関連付けられているかを示します。エンティティーが名詞、属性が形容詞の場合、リレーションは動詞になります。

従来のERDではリレーションはダイヤモンドとして描かれます。弱いリレーションは、弱エンティティーとその所有者を結合し、二重のダイヤモンドで示されます。

エンティティーのリレーションへの参加は、全参加の場合もあれば部分参加の場合もあります。全参加の場合、エンティティー・セットの全体がそのリレーションに関与します。部分参加では、セット内のエンティティーの一部またはすべてが、ある特定の時点において、リレーションに関与する可能性があります。

カーデイナリティーとはリレーションの特性の一つで、あるエンティティーのインスタンスが別のエンティティーのインスタンスに関連づけられる数を定義するものです。

• 1対1のリレーション（1：1）は1つのエンティティー内にあるレコードが、他のエンティティー内にある1つのレコードによってのみ参照されていることを示します。各大学には学長が一人しかいないため、大学と学長の関係は1対1のリレーションです。逆に、各学長はまさに1つの大学のみを担当します。

• 1対多の関係（1：M）は、あるエンティティー内の各レコードが、他のエンティティーの複数のレコードに関連づけられている状況を表します。大学と学部の間には、1対多の関係があります。大学には複数の学部があるものですが、各学部はある1つの大学にのみ属しています。

• 多対多のリレーション（M：M）は、双方のエンティティー内に存在する1つ以上のレコードと接続できることを示します。学生と教授は、1人の教授が1つのクラスで多くの学生に教えるのと同様に、各学生も他の教授のクラスに登録する可能性があるため、多対多の関係にあります。

ERDは、エンティティー間の接続線の変化を通じてカーデイナリティーを表します。カーディナリティーの表示方法は、使用するERDのスタイルによって異なります。

ほとんどのERDは、概念、論理、物理の3つの実体関連モデルのいずれかで作成されます。3つはいずれもエンティティーとその属性、および関係性を表していますが、ユースケースと想定されるユーザーは異なります。概念ERモデルは最も詳細度が低く、物理ERDは最も詳細な情報を提供します。

• 概念ERモデルは、ERD内のデータについてハイレベルのビューを提供します。ビジネス・アナリストは、データウェアハウスなどの大規模なデータベース設計プロジェクトに概念ERモデルを使用します。概念データ・モデルでは通常、データベース・テーブルとカーデイナリティーについては深く掘り下げず、エンティティーと関係性のみを含みます。

• 論理ERモデルは概念モデルと似ていますが、若干詳細度が高くなっています。論理データ・モデルでは、各エンティティー内の列または属性が、運用エンティティーおよびトランザクション・エンティティーと同様に定義されます。ビジネス・アナリストは、小規模なデータベース設計プロジェクトに論理データ・モデルを使用します。

• 物理ERモデルはデータベース設計プロジェクトの具体的な青写真です。カーデイナリティーや主キーと外部キーなどが含まれ、最も詳細です。データベース設計者とエンジニアは、ビジネス・アナリストが提供した概念モデルと論理モデルから物理データ・モデルを作成します。

コンピューター科学者でデータベース理論家のPeter Chenが1970年代にERDを導入して以来、増え続けるユースケースに対応するために複数の種類の図が登場してきました。

Chen ERDは古典的なフローチャートに似ており、さまざまな図形が線で結ばれています。カーデイナリティーは、接続線に沿って文字1、M、Nで表されますMとNはどちらも1対多または多対多の関係における「多さ」を表します。後者をM:NまたはN:Mの表記で描くことは、関係性の両側にあるエンティティー数必ずしも等しくなくて良いことを示しています。

Chen記法は、単一の接続線で全部関与を示し、二重の接続線で部分関与を示します。

多くの関係性を示す3本の枝分かれした接続線にちなんで名付けられたCrow’s foot記法は、Chen記法のシンボルをテーブルに置き換えています。各テーブルはエンティティーを表し、すべての属性が含まれます。Crow’s foot記法を使用することで、作成者は関係性のカーデイナリティーに関する情報を表せます。

Charles Bachmanのデータ構造図は、ChenがERDを作成する際に直接インスピレーションを与えました。Bachmanは関係性のカーデイナリティーを示すために、矢印付きの線を使用しました。

米国空軍は、セマンティック・データ・モデルの開発を支援するために、1980年代に情報モデリングの統合定義（IDEF1X）言語を導入しました。IDEF1XはChenの手法を一歩前進させ、共有テーブル内に属性を表示し、カーデイナリティーにより多くのオプションを導入しました。

1981年にRichard Barker氏が考案したBarker記法は、Oracleでの使用において標準となっています。バーカー記法は、線の接続についてCrow’s foot記法を採用するのと同時に、破線を使用して部分関与または任意の関与を表現します。