エンティティ関係図（ERD）は、データベースアーキテクチャの設計図として機能します。しかし、経験豊富なデザイナーですら、ビジネスロジックをデータモデルに変換する際に困難を抱えることがあります。その曖昧さの多くは、用語の重複や構造要素間の微細な違いに起因します。このガイドでは、キー、基数、関係に関する最も根強い疑問に取り組みます。
これらの概念を理解することで、データの重複を防ぎ、クエリのパフォーマンスを確保できます。15の具体的な混乱点を順に解説し、明確で実行可能な定義に分解します。各セクションには実際の例と視覚的な説明が含まれており、背後にあるメカニズムを明確にします。
1. エンティティと属性の違いは何ですか？ 🏷️
あるエンティティは、データが格納される対象となる現実世界の物体または概念を表します。通常、長方形で表現されます。例として顧客, 製品、または注文.
ある属性はエンティティの性質を表します。エンティティに接続された楕円で表現されます。たとえば、顧客名、または製品価格は、上記のエンティティの属性です。
- エンティティ： 名詞（誰／何）。
- 属性： 形容詞（何を説明するか）。
属性に複数の情報が含まれる場合、混乱が生じることがあります。もし住所が属性である場合、それを通り名, 都市、および Zipより良い正規化のため。
2. 主キーと一意キーの違いは何ですか？ 🔑
両方ともデータの整合性を保証しますが、使用方法は異なります。
- 主キー： テーブル内のすべての行を一意に識別します。テーブルには主キーが1つしかありません。null値を含めることはできません。
- 一意キー： 列内のすべての値が異なることを保証します。テーブルには複数の一意キーを持つことができます。null値はしばしば許可されます（実装によって異なります）。
主キーをレコードの社会保障番号と考えてください。一意キーはパスポート番号のようなもので、やはり一意ですが、個人に対して複数の固有識別子が存在する可能性があります。
3. 外部キーとは何か、そしてテーブルをどのようにリンクするのか？ 🔗
A 外部キー は、あるテーブル内のフィールド（または複数のフィールドの集合）で、別のテーブルの主キーを参照します。これにより、2つのテーブルの間にリンクが確立されます。
以下のような 注文 テーブルを考えてみましょう。どの 顧客 が注文をしたかを把握する必要があります。顧客ID テーブル内の 注文 は外部キーです。
| テーブル | 列 | 役割 |
|---|---|---|
| 顧客 | 顧客ID | 主キー |
| 注文 | 顧客ID | 外部キー |
この関係により、データベースは参照整合性を維持でき、有効な顧客が存在しない注文は存在しないことを保証します。
4. 関係が1対1になるのはいつですか？ 🤝
1対1（1:1）の関係とは、Table Aの1つのレコードがTable Bの正確に1つのレコードに関連し、その逆もまた成り立つ場合を指します。
- 例： A Person と パスポート.
- 実装方法：通常、一方のテーブルの主キーをもう一方のテーブルの外部キーとして配置することで実装されます。
パフォーマンスやセキュリティを最適化するためにエンティティを分割する場合に、この方法は一般的です。たとえば、社会保障番号を1:1でリンクされた別テーブルに移動するなどです。
5. 1対多の関係はどのように機能するのですか？ 📦
これは最も一般的な関係タイプです。Table Aの1つのレコードがTable Bの複数のレコードに関連しますが、Table BのレコードはTable Aの1つのレコードにのみ関連します。
- 例： 部門 から 従業員.
- 方向：1つの部門には複数の従業員が所属します。
ERDでは、この関係は2つのエンティティを結ぶ線で描かれます。「多」の側に外部キーが配置されます。
6. 多対多の関係はなぜ問題になるのですか？ ⚖️
複数のレコードがTable Aと複数のレコードがTable Bに関連する場合、多対多（M:N）の関係が存在します。リレーショナルデータベースに直接実装するには、ブリッジが必要です。
- 問題点：1つの行に複数のIDを格納する必要があるため、単純に1つのテーブルに外部キーを追加することはできません。
- 解決策： 結合テーブル（関連エンティティ）を作成する。
に対して学生および授業に対して、登録テーブルを作成し、学生IDおよび授業IDこれにより、M:N関係が2つの1:Many関係に変換される。
7. カーディナリティとモダリティの違いは何ですか？ ⚖️
これらの用語は関係の制約を説明しており、類似した表記のため混同されがちである。
- カーディナリティ： 最大のインスタンス数。（例：1対多）
- モダリティ： 最小のインスタンス数。（例：必須または任意）
例：従業員は部署を持っている必要がある（モダリティ：必須/1）。部署は従業員がいなくても存在可能である（モダリティ：任意/0）。
8. 識別的関係と非識別的関係 🧩
その違いは、子エンティティの依存関係ににある。
- 識別関係： 子エンティティは親なしでは存在できない。外部キーは子の主キーの一部である。通常、実線で示される。
- 非識別関係： 子エンティティは独立して存在できる。外部キーは主キーの一部ではない。通常、破線で示される。
次のようなものを考える：請求書（親）と請求書明細行（子）。明細行は識別関係である。明細行は請求書がなければ意味を持たないからである。
9. 再帰的関係とは何か？ 🔄
再帰的関係とは、エンティティが自分自身と関係を持つときに発生する。これは階層データでよく見られる。
- 例：ある従業員テーブルで、1人の従業員が他の従業員のマネージャーであるもの。
- 実装： 同じテーブル内の外部キーで、同じテーブルの主キーを指すもの。
この構造は組織図やサブカテゴリを持つ製品カテゴリをサポートする。
10. 弱いエンティティと強いエンティティの違いは何か？ 🌱
ある強いエンティティは、他のエンティティに依存しない主キーを持つ。一方、弱いエンティティは、親エンティティの主キーなしでは一意に識別できない。
- 視覚的表現：弱いエンティティはしばしば二重の長方形で描かれる。
- 依存関係： これらは識別関係に依存している。
例：A 従属者 （配偶者／子供）を会社のシステム内で。従属者のレコードは通常、独自の固有IDを持たない。代わりに、EmployeeID によって識別される。
11. 組み合わせキーを使用すべきタイミングはいつですか？ 🧩
A 組み合わせキー は、2つ以上の列を組み合わせて1行を一意に識別するものである。単一の列では一意性が確保できない場合に使用される。
- シナリオ： A StudentCourse テーブル。
- キー： StudentID + CourseID.
この文脈では、どちらのIDも独自に一意ではないが、組み合わせると一意になる。組み合わせキーは他のテーブルの外部キー関係を複雑にする可能性があるため、注意が必要である。
12. サロゲートキー vs. ナチュラルキー：どちらを選ぶべきか？ 🔢
これは戦略的な設計上の決定である。
- ナチュラルキー： 実世界の属性（例：メールアドレス、社会保障番号）。利点：意味のあるもの。欠点：変更される可能性がある、長くなる可能性がある、または機密情報を含む可能性がある。
- サロゲートキー： システムが生成するID（例：自動増分整数）。利点：安定している、短い、高速。欠点：ビジネス上の意味がない。
ベストプラクティスでは、内部テーブル構造にはサロゲートキーを好む傾向がある一方で、ナチュラルキーは検索やレポート作成において依然として有用である。
13. 正規化はERDにどのように影響するか？ 📉
正規化とは、データの重複を減らすためにデータを整理するプロセスである。正規化するにつれてERDも進化する。
- 1NF：繰り返しグループを排除する。
- 2NF:部分的依存関係を削除する。
- 3NF:推移的依存関係を削除する。
より高い正規化は通常、テーブルと関係の数を増加させる。データ整合性を向上させる一方で、クエリを複雑にする可能性がある。正規化のレベルとクエリのパフォーマンスのニーズのバランスを取る必要がある。
14. クロウズフット記法 vs. チェン記法：どちらが標準か？ 👣
記法とは、関係が視覚的にどのように表現されるかを指す。
- クロウズフット：線の端に線、十字、円などの記号を使用する。現代のツールで非常に一般的である。
- チェン：関係には菱形、エンティティには長方形を使用する。より学術的である。
クロウズフット記法は、実装において一般的に好まれる。それはSQL制約により直接的に対応するためである。しかし、チェン記法は高レベルの概念的モデリングに非常に適している。
15. ERD vs. データフローダイアグラム（DFD） 📊
これらはシステム設計ライフサイクルにおいて異なる目的を果たす。
- ERD：注目する点はデータ構造および保存。関係の静的ビュー。
- DFD：注目する点はデータの移動およびプロセス。データがシステム内でどのように流れているかの動的ビュー。
これらを混同してはならない。ERDは、どのようなデータが存在するかを教えてくれる。DFDは、そのデータがどのように処理されるかを教えてくれる。完全なシステム仕様には両方が必要である。
主要なコンセプトの要約 📝
| コンセプト | 重要なポイント |
|---|---|
| プライマリキー | 行のための固有ID。nullは許可されない。 |
| 外部キー | 別のテーブルのプライマリキーへのリンク。 |
| 基数 | 最大関係数（1, 1..N）。 |
| 結合テーブル | 多対多関係を解決します。 |
これらの違いを習得することで、堅牢なデータベース設計が可能になります。目的は明確性、整合性、スケーラビリティです。モデルがビジネスの現実を正確に反映しているかを確認するために、これらの点をもとに図を確認してください。
これらの15の一般的な誤解を解消することで、保守・拡張が容易なシステムの基盤が築けます。データの意味論に注目すれば、技術的な実装は自然と導かれてきます。
