2025-4I データベース工学 第06回 講義資料

2025年11月13日 (木) 3-4時限

1 連絡と準備

1.1 今回講義の達成目標

  1. データベースにおいて、概念設計、論理設計、物理設計がそれぞれどんな役割を持つのか、その全体像を説明できる。
  2. 概念設計の内容をもとに、IE記法で概念ER図が作成できる。
  3. RDB を前提とした論理設計をもとに、IE記法で論理ER図が作成できる。
    • 特に、多対多の関係を中間テーブルを用いて適切に分割できる。

2 データベースの設計

ここまでの講義では、既存のテーブルを対象とした CRUD操作 (＝INSERT、SELECT、UPDATE、DELETE) に関わる SQL について学んできました。これらは、SQL なかでも DML（＝Data Manipulation Language）に分類されるもので、いわば データ (レコード) をどう操作するか という視点での学びでした。

ここからは、次の段階として データベース設計、つまり データ (レコード) を格納するテーブルの設計に関する考え方 を学んでいきます。具体的には「システムの対象世界をどのようにモデル化し、どのようなテーブル構造として定義するか？」について学んでいきます。なお、このデータベース設計に関して扱う SQL は、DDL (＝Data Definition Language) という範疇のものになります。

2.0.1 定着確認

2.1 データベース設計の三層構造 (概念設計・論理設計・物理設計)

データベース設計は、①概念設計 (Conceptual Design)、②論理設計 (Logical Design)、③物理設計 (Physical Design) と、抽象度の高いモデルから具体的な実装に向けて段階的に詳細化しながら進めることが、教科書的・設計理論的な作法とされています。

以下、多数の専門用語が登場しますが、まずは細部にこだわらず、全体像を理解することを優先してください。その後、気になる用語について、ウェブや生成AIを利用して概要を掴んでください。

2.1.1 定着確認

2.2 概念設計

データベースにおける 概念設計 とは、現実世界の情報構造を理解・把握し データベースで管理すべき情報を関係者間で共有すること を目的とするプロセスとなります。このプロセスでは「リレーショナルモデル」や「ドキュメント指向モデル」といった特定のデータモデルに依存せず (＝データモデルを意識せずに) 情報構造そのものをモデル化します。こうして得られた成果物は 概念データモデル と総称され、具体的には 概念ER図 (Conceptual Entity Relationship Diagram)、拡張ER図 (Enhanced/Extended ERD)、JSON スキーマ、UMLクラス図 (UML Class Diagram)、ツリー構造図などがこれに含まれます。

概念データモデルの代表格である 概念ER図 (Conceptual Entity Relationship Diagram) の例を以下に示します。図の意味や表記の読み方については、あとでセクションで解説します。

img

概念設計を終えたら、そのアウトプットやシステム要件を踏まえて、具体的な データベースモデル を選定していきます。ここでの「データベースモデルの選定」とはPostgreSQLやMySQL、MongoDBといった具体的なソフトウェアの選定ではなく、「リレーショナルモデル」や「ドキュメント指向モデル」「キーバリューストアモデル」といった アーキテクチャの選定 を意味します。

なお、大規模なシステムにおいては「このデータは RDB で管理し、このデータは KVストア で管理し…」のように複数モデルを併用（＝ポリグロット永続化）することもあります。

(プロンプト例)

ソフトウェア開発の文脈において「ポリグロット永続化」とは何ですか。

データベースの概念設計に関する文脈で「概念ER図」とはなんですか。

データベースの概念設計に関する文脈で「UMLクラス図」とはなんですか。

2.2.1 定着確認

2.3 論理設計

論理設計では、概念設計で整理したモデルを 実際に利用するデータベースモデルに適合する構造 に落とし込むプロセス となります。

データベースとして、リレーショナルモデルを採用する場合には、テーブルやカラムの定義、主キー・外部キーの設定といった スキーマ設計 を行ない 論理ER図 を作成するプロセスとなります。この際、冗長性を排除しデータの整合性を保つために 正規化 (Normalization) と呼ばれる考え方が重要となってきます。テーブル (＝カラム構成) について、第1正規形 (1NF: 1st Normal Form) から 第3正規形 (3NF: 3rd Normal Form)、場合によってはボイス・コッド正規形 (BCNF) まで整理・検討し、重複や不整合を防ぐようなスキーマを構築していきます。

(リレーショナルモデルを前提とした場合の) 論理設計のアウトプットとしては、論理ER図 (Logical Entity Relationship Diagram) や ざっくりとした CREATE 文 (SQL) などがあります。

(プロンプト例)

データベースに関する文脈で「実装依存しない標準SQL」とはどういうことですか。具体的な例を含めて解説してください。ちなみに自分は PostgreSQL で DB の勉強をしています。

概念ER図と論理ER図の違い (目的や情報粒度の違い) について教えてください。

データベースに関する文脈で、単に「ER図」といった場合、概念ER図と論理ER図のどちらを指しますか。

2.4 物理設計

物理設計 では、PostgreSQL や MySQL などの具体的な実装 (ソフトウェア) と、その運用環境 (ハードウェア構成) を意識した設計を行ないます。この段階では、テーブルや制約、ビューなどの定義に関わる DDL (Data Definition Language) に加え、ユーザのアクセス権限やロール管理などを扱う DCL (Data Control Language) も検討します。

具体的には、インデックス定義 (CREATE INDEX)、外部キー制約や検査制約 (FOREIGN KEY、CHECK)、ストレージ構成・冗長化・バックアップ方針・負荷分散設計 など、性能・可用性・保守性を意識したチューニングを含みます。

3 データベースの概念設計

データベースの 概念設計 (Conceptual Design) では、対象世界 (現実世界) の情報構造を抽象化したモデルを作成します。具体的には、ヒアリングや資料分析などを通じて業務要件を把握し、データベースで管理すべき情報の全体像を概念データモデル図として描きます。

教科書的・設計論的には、概念設計はデータベースモデルに依存しない設計とされていますが、ここでは、リレーショナルデータベースを前提として、システムが対象とする世界の情報構造を 概念ER図 として表現する方法について学んでいきます。

3.1 概念ER図とは

概念ER図 (Conceptual Entity Relationship Diagram) とは、対象世界の情報構造を エンティティ (Entity、実体) と、リレーション (Relationship、関連) という2種の要素でモデル化した図になります。

例えば、ウェブの「ブログサービス」を対象としたとき、次のような概念ER図を作成することができます。

img

ここで、図内の四角形 (User や Article など) が「エンティティ」を表し、青色の線 (has や creates など) が「リレーション」を表します。特にリレーションの表現法 (表記法ルール) の違いにより、同じER図でも IE記法 (アイイー記法) や IDEF1X記法 (アイデフワンエックス記法)、Chen記法 (チェン記法) など様々な表現が存在しています。

実業務ではIE記法 (特に Crow’s Foot記法) がよく使用され、基本情報技術者試験やデータベーススペシャリスト試験などのIPAの試験では、IDEF1X記法に準拠した表記が使用されています。

参考 📖 教科書「達人に学ぶDB設計 徹底指南書 (第2版)」の pp.151-156「4-3 ER図の描き方 (IE記法・IDEFX1記法)」

IPA の各種試験が CBT 方式に変更

2026年度から応用情報技術者試験も、ペーパーテスト方式 から CBT方式 に変更されます (詳細 )。なお、既に「ITパスポート」と「基本情報技術者」は CBT方式 で実施されています。

以下、概念ER図を構成する「エンティティ」と「リレーション」という要素について解説していきます。

3.1.1 定着確認

img

3.2 エンティティとは

RDB において「テーブル」に相当するものが エンティティ (Entity) となります。日本語では「実体」と訳されますが、必ずしも物理的な存在を意味するわけではなく、イベント (出来事) や 抽象的な概念 もエンティティとしてモデル化されます。

例えば、ブログであれば、Article (記事)、Comment (コメント)、Category (カテゴリ)、User (ユーザ) といったものが「エンティティ」としてモデル化されます。概念設計の段階では細部までは詰めませんが、エンティティは、一般に複数の アトリビュート (属性) を持ちます。アトリビュートは、RDB で カラム に相当するものです。例えば、Article エンティティは、title (タイトル)、body (本文)、created_at (作成日) といったアトリビュートを持つと考えられます。

エンティティとして扱うか、アトリビュートとして扱うかの判断

ある要素をエンティティとアトリビュート (属性) のどちらで扱うかは 設計目的や運用文脈に左右されるもので、一般的な指針はあるものの、絶対的な正解は存在しません。とはいえ、この選択を誤ると、ビジネスロジックやデータ処理の実装に支障をきたし、大きな技術的負債となります (あとから修正するときのコストは非常に大きいです)。

エンティティにするかアトリビュートにするかの判断は、システム全体の設計意図を踏まえ、要件の本質に基づいて決定することが求められます。

たとえば「住所」は単なる文字列のアトリビュートとして扱えますが、顧客・店舗・倉庫など複数のエンティティから参照されるなら、エンティティとして独立させた方が一貫性維持の観点で有利になってきます。また「所持金」もアトリビュートにできますが、履歴を管理したい場合はエンティティ化することが正解となります。

概念設計でアトリビュート (属性) を表現したい場合は？

エンティティに持たせる アトリビュート (属性) を詳細に検討・設計するのは 論理設計段階の作業 となります。そのため、概念設計のアウトプットである「概念ER図」には、通常、アトリビュートを記載しません。ただし、情報構造の理解を補うために 代表的なアトリビュート を Character (name, level, job) のように括弧書きで添えることもあります。

img

または、概念ER図とは別に、以下のような簡易ドキュメントを作成することもあります。

- Character
  - name
  - level
  - job

- Guild
  - name
  - rank

ただし、概念設計の目的が、全体的な情報構造の共有であるため、代表的なアトリビュートに限って記載すること が推奨されます。

(プロンプト例)

データベースの概念設計において、ある要素を「エンティティ」にすべきか、「アトリビュート」にすべきか、一般的な指針や考え方について様々な観点から解説してください。

3.2.1 定着確認

3.3 リレーションとは (多重度のみの表現)

ER図において リレーション とは「エンティティ同士の関連 (結びつき) を表現するもの」となります。例えば、ブログシステムにおいて…

…のようなエンティティ間の関連があるとき、ER図では次のような線 と Crow’s Foot (カラス足) という先端記号でリレーションを表現します。

img

Crow’s Foot は、カーディナリティ (多重度) と呼ばれる エンティティ同士の 数量的な範囲や制約 を表現したものになります。

例えば、下図の ❶ のようなカラスの足マーク (多 の記号表現) は「1つの Article は、複数の Comment を持つことができる」という数量的性質を表しています。

img

一方、❷ のような縦棒 (数字の 1 の記号表現) は、 「1つの Comment は、1件の Article に属する」という数量的性質を表しています。

このようなエンティティ同士の関係を、文字では「Article と Comment に 1対多 や 1:多、1:N の関係がある」のように表現します。

別な例で考えてみます。例えば、ER図で Student (学生) と Subject (科目) というエンティティが、以下の図ように表現されている (＝リレーションの 両端 が 多 となっている) とします。

img

このとき、このER図は次のことを表現しています。

ER図の関連名 (Relationship Name) について

IE記法のER図では、下図の has のように、リレーションを表す線上に関連名 (Relationship Name) を付けることがあります。これは 動詞句 (Verb Phrase) とも呼ばれ、関係性を自然言語的に表現するためにつけられます。補助表現であるため、関係が明らかな場合には省略 されることもあります。

img

なお、関連名/動詞句は「どちらのエンティティを基準にするか」によって表現が変わります。上記の例は、Comment を基準に関連名/動詞句を記述すれば belongs to という表現になります。

img

どちらを基準 (主語) に表現するかについて明確なルールはありませんが、一般には「より中心的なエンティティ」または「動作・行為を起こす側」を基準 (主語) にすることが多いです。

ER図でよく使用される関連名 (動詞句) としては、次のようなものがあります。

3.3.1 定着確認

img

3.4 リレーションとは (多重度と任意性の表現)

前のセクションでは、カーディナリティ (多重度) のみに着目してリレーションを表現しました。しかし実際の ER図では、そのリレーションが 必ず存在するのか、それとも存在しない場合もあるのか を示す オプショナリティ (任意性) についても明示することが推奨されます。

オプショナリティは、以下のように「必須」を 1 を模した記号で表現し、「任意 (存在しないこともある)」を 0 に模した記号を使って表現します。

img

上記の例では、右側の Comment エンティティに接する記号が、多 を示すカーディナリティ記号と、0 (＝任意) を示すオプショナリティ記号 の組み合わせになっています。これは「1つの Article は、0 個以上の複数の Comment を持つことができる (＝Article は Comment を持たない場合もある)」ということを表現しています。

一方で、Article エンティティに接する記号は、1 を示すカーディナリティ記号と、1 を示すオプショナリティ記号の組み合わせであり、「1つの Commente は、必ず1つの Article に属さなければならない (＝Article に属さない Comment は存在し得ない)」ということを表現しています。

少し視点を変えれば、オプショナリティはエンティティ同士の数量的な範囲の 下限 (0 または 1) を表し、カーディナリティは数量的範囲の 上限 (1 または 多) を表しているとも言えます。データベース設計では 1..* や 0..1 のように範囲表現することがありますが、この下限が オプショナリティ、上限が カーディナリティ に対応します。

カーディナリティとオプショナリティを組み合わせてリレーションを表現するとき、Crow’s Foot記法では以下の4パターンが存在します。

img

以降、(試験や小テストを含めて) 特に指示の無い限り、ER図はカーディナリティとオプショナリティの両方を考慮した表現を利用するようにしてください。

リレーションの具体的な上限数は考慮しないのか?

概念設計や論理設計では、リレーションの数量関係を 0、1、多 の3区分で扱います (多 については、* や N のように表記することもあります)。

これは、概念設計/論理設計が「データ構造を定義するプロセス」であり、「3つまで」や「5件まで」といった 具体的な数値制約は構造そのものには影響しないため です。RDB のテーブル構造に影響するのは「単数」か「複数」かの区別だけになります。

そのため「キャラクタは最大3つのギルドに所属できる」というルールが存在あったとしても、ER図 においては単に 1:多 のリレーションとして表現します。

具体的な数値をともなう上限制約は、物理設計やアプリケーション側の制御ロジックで扱う領域となります。

3.4.1 定着確認

img
img
img

3.5 概念ER図を作成することの意義

概念ER図 (概念データモデル) を作成・共有することで、自然言語での説明では曖昧になりやすい関係性 を 明示的かつ一貫した形式で表現して共有 することができます。図による共有は、モデルの構造的理解を助け、結果としてチーム開発におけるメンバー間の理解の齟齬や、それによる手戻りを防ぐことにつながります。

また、適切なツールを用いて作成すれば、文章を記述するよりも効率的かつ短時間でER図を作成することができます。たとえば、以下の概念ER図に相当する情報を文章で記述すると…

img

以下のようになります。エンティティの数が増え、それにともないリレーションが増えたとき、自然言語による説明ではとんでもない文章量になることが分かると思います。

また、個々の説明から分かるように、誤解や認識の齟齬を避けようと丁寧に記述すると、どうしても説明が冗長になりがちで、その作成や校正は非常に煩雑なものとなります。さらに、文章の列挙では リレーションの漏れ が生じやすく (また、それに気づきにくく)、全体像を把握することも困難となります。

以上のようなことから、データベース設計では ER図 などが活用されます。ジュニアレベルの新米エンジニアでも、現場ではER図を正しく読み解くことが求められるので、次のセクションの論理ER図を含めて、しっかりと学ぶようにしてください。

3.6 概念設計からモデル選定へ

概念設計が完了したら、次は データベースモデルの選定 を行ないます。ここでは、作成された概念ER図 (概念データモデル) をもとに、代表的なユースケースを具体的に想定しながら、次のような観点から検討します。

このような観点を総合して、要件に対して最も適切なデータベースモデルを選択します。上記で RDB は リレーショナルデータベース、DocDB は JSONドキュメント指向データベース、KVS は キーバリューストア型DB の略です。

なお、このモデルの選定について、本科目では詳しく扱わないので、興味がある学生は、次のようなプロンプトを使って学んでみてください。

(プロンプト例)

データベース設計に関する質問です。データベースの概念設計が完了し、次にデータベースモデルの選定 (リレーショナルモデル、ドキュメント指向モデル、KVS など) を進めていきたいと考えています。一般的には、どのような設計観点や判断基準からモデルを選ぶのか教えてください。

データベース設計に関する質問です。リレーショナルモデル、ドキュメント指向モデル、KVS などがありますが、各モデルについて、どのような要件・設計思想に向いているかを解説してください。

以降は、データベースとして「リレーショナルモデル」が採用されたことを前提に解説を進めます。

3.6.1 定着確認

4 論理設計

論理設計では、概念ER図をリレーショナルデータベースの構造に合わせた形に整理し、次のような 論理ER図 (Logical Entity Relationship Diagram) を作成していきます。

img

具体的には、概念ER図を次のような要件 (＝RDBで効果的・効率的に管理するための条件) を満たすように整え、テーブルやカラム、キーといった RDB での実装を意識した構造に近づけていきます。

なお、この論理設計では、RDB での管理は意識するものの、PostgreSQL や SQLite のような 個別製品の仕様や制約 については考慮しません。それらは、論理設計につづく物理設計での検討となります。

4.0.1 定着確認

4.1 テーブルとカラムの設計

論理設計では、概念ER図の「エンティティ」を RDB の テーブル に対応づけ、また「アトリビュート (属性)」を RDB の カラム に対応づけて情報を整理し、それに基づいて「論理ER図」を作成していきます。

4.1.1 「概念ER図」と「論理ER図」の対応

以下に「概念ER図」と「論理ER図」の一例を示します。2つを見比べて、それぞれの対応関係や、論理ER図で新たに追加されている要素を読み解いてください。

概念ER図の例

img

論理ER図の例

img

論理設計は、実際の RDB 設計にかなり近づくため、実務では「エンティティ」や「アトリビュート」よりも、「テーブル」や「カラム」 という表現が使われることが多くなります。設計論的には論理ER図では前者の呼称のほうが適切ですが、本講義では実務での一般的な表現にそろえて「テーブル」と「カラム」という呼び方を用いていきます。

4.1.2 テーブルとカラムの洗い出し

論理設計では、はじめに概念ER図に表したエンティティを「テーブル」として捉え、そのテーブルのカラム構成を検討していきます。この際、一般的な RDB の慣習にあわせて、テーブル名は 可算名詞の複数形・集合名詞のスネークケース、カラム名は 単数形のスネークケース で表記していきます。

また、各カラムの「型」については、文字列型、数値型、日時型といったおおまかな粒度で検討しておきます (VAECHAR(16)、INTEGER、TIMESTAMP などの実装依存を含めた具体的な型の決定は物理設計で行ないます)。

以下、概念ER図から、テーブルとカラムを洗い出して整理した一例です (特定の書式があるわけではありません)。

- `users` テーブル (User エンティティ)
  - `name`       文字列型
  - `email`      文字列型
  - `created_at` 日時型
  - `updated_at` 日時型

- `articles` テーブル (Article エンティティ)
  - `title`      文字列型
  - `content`    文字列型
  - `created_at` 日時型
  - `updated_at` 日時型

(以下、略)

この際、テーブルのフィールド (セル) には「スカラー値」つまり 構造を持たない1つの値 が格納されるようにカラムを設計してください。

たとえば、position というカラムに [10,20] のような「配列」を直接格納したり、class というカラムに {"grade":4, "course":"I"} のような「辞書 (オブジェクト)」を格納するような設計はアンチパターン (＝第1正規化 (1NF) を満たしていないテーブル) となります。

🚨「アンチパターン」とは、やってはいけない設計の典型例 (特に過去に多くの人が失敗している例) のことです。

(プロンプト例)

RDB の設計に関する質問です。キャラクターの位置情報を管理するために、あるテーブルの position カラムに [10, 20] のような配列を直接格納しようと思いました。しかし、「それはアンチパターンで、pos_x と pos_y のように別のカラムに分けてスカラー値 (単一の数値) を入れるべき」と言われました。どうして配列をそのまま格納すると良くないのでしょうか。また、実際に配列で格納すると、どんな SQL を書くときに困るのか、初学者向けに例を挙げて説明してください。

参考 📖 教科書「達人に学ぶDB設計 徹底指南書 (第2版)」の pp.228-232「7-2 非スカラ値 (第1正規形未満)」

4.1.3 定着確認

4.2 繰り返しカラムは別テーブルで管理

テーブルのなかに「同種の情報が繰り返し出現するようなカラム構成」が存在する場合は、その部分を別テーブルとして分離し、それを参照する形 (＝リレーションで関連づける形) にします。例えば、characters テーブルに、以下のように skill_1、skill_2、skill_3、skill_4 というカラムを設けるような設計は、RDBにおける典型的なアンチパターン (＝第1正規化 (1NF) を満たしていないテーブル) となります。

name job skill_1 skill_2 skill_3 skill_4
Alice Priest Heal Resurrection NULL NULL
Bob Monk DragonKick NULL NULL NULL

上記テーブルのように、同種の情報の繰り返し構造を持つ場合は、それを以下のような別テーブル (ここでは skills テーブルを新たに作成) に切り出し、縦方向に保持する形式 (＝「縦持ち」「行持ち」「long format」の形式) にすることが求められます。

character_name skill slot_no
Alice Heal 1
Alice Resurrection 2
Bob DragonKick 1

このように情報を分離したとき、概念ER図は次のようになります。

img

また、論理ER図では次のようになります。

img

4.3 主キー (Primary Key)

テーブルを構成するカラムが整理できたら、各テーブルの 主キー (PK: Primary Key) を決めていきます。主キーは、そのテーブル内のレコード (行) を 一意に識別できる値を持つカラムに対して設定するもので、他のテーブルから参照される際の 外部キー (FK: Foreign Key) としても使われます。

たとえば、次のようなテーブルがあるとします。name、nickname、age のうち、主キーにすることができるカラムはどれなのかを検討していきます。

name nickname age
Alice Ali 20
Bob Bobby 25
Carol NULL 20
David Dave 23

4.3.1 ageカラムを主キーにできるか?

age カラムは、20 という値を持つレコードが複数存在するので (また、今後、同年齢のレコードが挿入されることが十分に考えられるので)、age を主キーにすることはできません。

4.3.2 nicknameカラムを主キーにできるか?

nickname カラムには重複する値がないので、カラムは重複のない値を持つため、理論上はレコードを一意に識別できます。しかし、RDBMS には NULL を許容するカラムを主キーに設定できない決まり があり、nickname を主キーにすることはできません。

4.3.3 nameカラムを主キーにできるか?

name カラムは NULL を含まず、その値 (Alice や Bob など) によって一意にレコードを識別できるため、理論上は name を主キーにすることができます。

ただし、name を主キーに設定すると (RDBMSにより、自動でUNIQUE制約が付与されるため)、同名の別人を追加できなくなるという運用上の制約 が生じます。実際のシステムでは人名の重複は一般的に起こりうるため、name を主キーとするのは現実的ではありません。

このような問題を避けるには id や character_id のような人工的なカラムを追加し、連番 や UUID を割り当てて主キーとするのが一般的です。こうしたカラムを サロゲートキー (代理キー、Surrogate Key) といいます。サロゲートキー (整数値の連番) を追加した例を以下に示します。

id name nickname age
1 Alice Ali 20
2 Bob Bobby 25
3 Carol NULL 20
4 David Dave 23

なお、「学籍番号」や「メールアドレス」のように、現実世界で意味を持ちつつデータを一意に識別可能なカラム (アトリビュート) を ナチュラルキー (自然キー、Natural Key) といいます。

サロゲートキーとして連番を使うべきか、UUID などを使うべきか

サロゲートキーには、整数の連番を使う方法と、UUID (主に v4) や Nano ID などのランダムな識別子を使う方法があります。

(プロンプト例)

UUID v4 と Nano ID をRDBのサロゲートキーとして使用する観点から比較してください。

ウェブアプリのバックエンドとして使用する RDB において、整数値の連番をサロゲートキーとして使用するときのリスクについて具体的に解説してください。

参考 📖 教科書「達人に学ぶDB設計 徹底指南書 (第2版)」の pp.266-280「8-2 代理キー ～主キーが役に立たないとき～」

4.3.4 定着確認

4.4 複合主キー

テーブルの主キーは、1つのカラムだけでなく、複数のカラムを組み合わせて設定することもできます。このような主キーを、特に複合主キー (Composite Primary Key) といいます。複合主キーは、多対多 のリレーションを 1対多 に変換するための中間テーブル (詳細は後述) などで頻繁に使われます。

たとえば、以下のようにキャラクタとアイテムの対応関係を管理する中間テーブル character_items があるとします。このとき character_id と item_id の2つを組み合わせて、このテーブルの主キー (複合主キー) とすることができます。

character_id item_id quantity
1 38 3
1 46 1
2 10 5
2 11 2
2 46 1

複合キーを主キーに設定したとき、その組み合わせに対して UNIQUE制約 が自動的に働きます。そのため、同じキャラクタが同じアイテムを重複して所持するような不整合 (例えば、テーブルのなかに (character_id,item_id,quantity)=(1,38,3) と (character_id,item_id,quantity)=(1,38,4) というレコードが存在ような状況) が抑制され、テーブル内の整合性が保たれます。

また、複合主キーを構成する各カラムについては、NOT NULL制約 が自動的に適用されます。

複合主キー v.s. サロゲートキー

中間テーブルの主キー設計、つまり「複合主キーとすべきか」あるいは「サロゲートキーを導入すべきか」は、設計者によって意見が分かれるテーマとなっています。どちらにも一貫した理論的正当性があり、現在のところ明確な定石はありません。興味があれば、複合主キー アンチパターン などのキーワードで検索したり、生成AIで深掘りしてみてください。

(プロンプト例)

RDBの設計に関する質問です。中間テーブルは、複合主キーにすべきか、サロゲートキーを導入すべきかという主キー設計は、よく議論になると聞きました。双方の主張について詳しく解説してください。

4.4.1 定着確認

4.5 論理ER図における主キーの表記

論理ER図において、主キー (PK) となるカラムを示す表記には、いくつかの方法があります。代表的なものとしては、❶ カラムに下線を引く、❷ id (PK) のように明示する、あるいは ❸ 四角形の上部を区切って配置する などがあります。

img

本講義資料では、上図の右端のように四角形の上部を区切ってPKカラムを配置する表記を主に使用します。

4.6 外部キーを使用した「1対多」のリレーションの表現

概念ER図で 1対多 の関係を持つリレーションは、論理ER図では、1 側のテーブルの主キー (PK) を、多 側のテーブルに 外部キー (FK: Foreign Key) として保持することで表現します。このようにすると、RDB では SQL の結合操作 JOIN により、テーブル間の関係を正しく関連づけて扱うことができます。

たとえば、ブログシステムの「概念ER図」では、以下のように「Userエンティティ」と「Commentエンティティ」が 1対多 の関係となっています。つまり、1人のユーザーは、0個以上の複数のコメントを作成できる という関係を表現しています。

img

この関係を「論理ER図」で表す場合は、以下の図のように comments テーブルのなかに、users テーブルの 主キー (user_id) を追加します。このように他のテーブルの主キーを参照するカラムを「外部キー (FK)」と呼び、論理ER図ではFK という略称で表記します。

img

論理ER図では、外部キーを以下のようにカラム名のあとに括弧付きで user_id (FK) のように示すこともあります。

img

なお、リレーションはテーブルを表す四角形の任意の位置を端点にできますが、上図のように 「主キー」と「外部キー」を端点 として描くのが最も直感的に理解しやすく推奨されます。

4.6.1 定着確認

▼ characters テーブル

character_id name job_id
1 Alice J5
2 Bob J2
3 Charlie J6
4 Ellen J6

▼ jobs テーブル

job_id name
J1 Fighter
J2 Monk
J3 Ninja
J4 Samurai
J5 Priest
J6 Wizard

4.6.2 演習

次に示す概念ER図を参考に、User、Character、Guild、Job エンティティに直接関係する範囲の「論理ER図」を作成せよ (Item および GuildStorage エンティティは対象としなくてよい)。なお、論理ER図のテーブルとカラムの名前は英語で適切に設定すること (必要に応じて生成AIを活用すること)。また、各エンティティは、少なくとも次のアトリビュート (属性) を持たせること。

img

(プロンプト例)

RDBのDB設計をしています。テーブルのカラム名 (英語・スネークケース) を検討する手伝いをしてください。MMORPGの世界観において、jobs テーブルのカラム (属性) として「攻撃補正」「防御補正」「魔法補正」の命名案を複数提案してください。

4.7 多対多のリレーションの分割 (中間テーブル化)

RDB では、2つのテーブル間の 多対多 となる関係を 直接的に定義すること ができません。そのため、両者を仲介する中間テーブル (関連エンティティ) を設け、1対多 と 多対1 の関係に分解して扱います。

たとえば、ブログシステムでは「Articleエンティティ」と「Categoryエンティティ」が 多対多 の関係となります。つまり、1つの記事は「1つ以上の複数のカテゴリ」に属することができ、同時に、1つのカテゴリは「0個以上の複数の記事」を持つことができるという関係になります。

この関係を概念ER図では以下のように表現しました。

img

これを論理ER図に落とし込むときには、article_categories という中間テーブルを設けて、以下のように変換します (RDB でも同様にこの構造で実装します)。なお、中間テーブルの名前は任意ですが、一般に 両側のエンティティ名を組み合わせる方法 がよく用いられます。

img

参考 📖 教科書「達人に学ぶDB設計 徹底指南書 (第2版)」の pp.157-158「4-4 「多対多」と関連実体」

4.7.1 定着確認

img

5 課題1

本課題には、ER図を作成するための適切なツールを選定すること、ツールの使い方を自分で学ぶこと、実務水準の見やすく整った正確なER図を作成・出力することも学習内容として含んでいます。

5.1 提出ファイル作成に関する注意事項

雛形のWordファイルは、ダウンロードして、必ず デスクトップアプリ版の Word を使って編集 してください。

img

ブラウザ版 (Word for the Web) や Teams版 で閲覧・編集すると、体裁や設定が崩れることがあります（減点対象）。ブラウザで開いてしまった場合は、次の手順でデスクトップアプリで開き直してください。

img

Word のオプションから「画像が自動圧縮されない設定になっていること」を確認してください。

img

🚨 ER図をラスタ形式 (PNG など) で貼り付ける場合は、印刷時の出力解像度が 300dpi 以上 となるようにしてください。A4 用紙に貼り付けた際の実寸が 約16cm (≒6.3インチ) であれば、6.3 inch × 300 dpi = 1,890 px となるため、図の横幅は少なくとも 1,890 ピクセル以上 としてください。

🚨 ER図をベクタ形式 (SVG や WMF など) で貼り付ける場合は、解像度を意識する必要はありません。ただし、フォントをアウトライン化するなどして、どの環境でも文字化けや崩れが起きないよう配慮してください。

提出された課題は、カラー印刷して紙面上で評価します。提出前には実際に印刷して内容や仕上がりを確認するようにしてください。

(プロンプト例)

学校の課題で次のような指示を受けました。フォントのアウトライン化とは何ですか？👉「ER図をベクタ形式 (SVG や WMF など) で貼り付ける場合は、フォントをアウトライン化するなどして、どの環境でも文字化けや崩れが起きないよう配慮してください。」

5.2 課題内容

次の「演習1」から「演習3」について取り組んでください。演習 (＝ER図の作成) には すべて同じツールを使用して取り組んでください。

5.2.1 演習1

次に示す「概念ER図」と同じ情報＆論理構造の概念ER図を作成して、それを雛形ファイルに貼り付けてください。

img

5.2.2 演習2

次に示す「論理ER図」と同じ情報＆論理構造の論理ER図を作成して、それを雛形ファイルに貼り付けてください。

img

5.2.3 演習3

本校の 本科4年生 を利用者とした 提出物管理システム (ウェブアプリ) を題材としてデータベース設計を行い、「論理ER図」を作成して、それを雛形ファイルに貼り付けてください。

img

5.2.4 共通の指示事項

6 授業時間外学習の指示 (宿題)

🚨本科目は「学修単位科目」であり、1回の講義あたり「4時間相当」の授業時間外学習が求められる科目です🏃