リレーショナルデータベース管理システム（RDBMS）とは？設計プロセスと正規化を徹底解説

リレーショナルデータベース設計（RDD）では、情報やデータを行と列で構成される一連のテーブル（表）としてモデル化します。テーブルの各行は1件のレコードを表し、各列はデータの属性（項目）を表します。リレーショナルデータベースの操作には、SQL（Structured Query Language：構造化照会言語）が使用されます。

リレーショナルデータベースの設計は、データを関連する一連のテーブルへモデル化する以下の4つの段階で構成されます。

• リレーション（属性）の定義
• 主キーの定義
• リレーションシップ（関係）の定義
• 正規化

リレーショナルデータベースが他のデータベースと異なるのは、データの整理方法とトランザクションの実行方法です。RDDでは、データはテーブル形式で整理され、あらゆるデータアクセスは制御されたトランザクションを通じて行われます。リレーショナルデータベース設計は、データベースに求められるACID特性（原子性・一貫性・分離性・耐久性）を満たします。また、データ管理の問題に対処するために、アプリケーションでのデータベースサーバーの利用が前提となります。

リレーショナルデータベースの設計プロセス

データベース設計は科学というより芸術に近いものです。多くの意思決定が必要となるためです。データベースは通常、特定のアプリケーションに合わせてカスタマイズされます。同じカスタマイズされたアプリケーションは二つと存在せず、したがって同じデータベースも存在しません。設計上の判断にはガイドライン（多くの場合、「何をすべきか」よりも「何をしてはいけないか」という形で示されます）が提供されますが、最終的な選択は設計者自身に委ねられます。

ステップ1：データベースの目的を定義する（要件分析）

• 要件を収集し、データベースの目的を明確に定義します。
• サンプルの入力フォーム、クエリ、レポートを下書きしておくと、目的の把握に役立ちます。

ステップ2：データを収集し、テーブルに整理して主キーを指定する

• データベースの目的が決まったら、格納すべきデータを収集し、主題ごとのテーブルに分割します。
• 各行を一意に識別できる列（または複数の列）を「主キー」として選択します。

ステップ3：テーブル間のリレーションシップを作成する

独立して互いに関係のないテーブルだけで構成されたデータベースには、ほとんど意味がありません（その場合はスプレッドシートを使った方がよいでしょう）。リレーショナルデータベースの真価は、テーブル間に定義できる関係性にあります。リレーショナルデータベース設計における最も重要なポイントは、テーブル間のリレーションシップを特定することです。リレーションシップには以下の種類があります。

• 1対多（one-to-many）
• 多対多（many-to-many）
• 1対1（one-to-one）

1対多（One-to-Many）

「時間割」データベースでは、1人の教師が0個以上のクラスを担当でき、一方、各クラスは必ず1人（かつ1人だけ）の教師が担当します。「会社」データベースでは、1人のマネージャーが0名以上の従業員を管理し、各従業員は必ず1人のマネージャーに管理されます。「商品販売」データベースでは、1人の顧客が複数の注文を行え、各注文は必ず特定の1人の顧客によるものです。この種の関係を「1対多」と呼びます。

1対多の関係は単一のテーブルでは表現できません。例えば「時間割」データベースで、教師情報（氏名、オフィス、電話番号、メールアドレスなど）を格納するTeachersテーブルから始めた場合、担当クラスを保存するためにclass1、class2、class3といった列を作成することになりますが、いくつの列を作ればよいかという問題にすぐ直面します。逆に、クラス情報を格納するClassesテーブルから始めて、担当教師の情報用の列を追加することもできますが、1人の教師が複数のクラスを担当する場合、その教師のデータがClassesテーブルの多くの行で重複してしまいます。

1対多の関係をサポートするには、2つのテーブルを設計する必要があります。例えば、classIDを主キーとするClassesテーブルと、teacherIDを主キーとするTeachersテーブルを作成します。そして、「1」側（親テーブル）であるTeachersテーブルの主キー（teacherID）を、「多」側（子テーブル）であるClassesテーブルに格納することで、1対多の関係を実現できます。

子テーブルClasses内のteacherID列は「外部キー」と呼ばれます。外部キーとは、親テーブルの主キーを子テーブル側に配置し、親テーブルを参照するための仕組みです。

多対多（Many-to-Many）

「商品販売」データベースでは、顧客の1つの注文に1つ以上の商品が含まれ、一方、1つの商品は複数の注文に現れる可能性があります。「書店」データベースでは、1冊の本に1人以上の著者がおり、1人の著者は0冊以上の本を執筆しています。この種の関係を「多対多」と呼びます。

「商品販売」データベースで具体例を見てみましょう。まずProductsテーブルとOrdersテーブルの2つを用意します。Productsテーブルには商品情報（商品名、説明、在庫数など）をproductIDを主キーとして格納します。Ordersテーブルには顧客の注文情報（customerID、注文日、希望日、ステータスなど）を格納します。しかし、注文された商品をOrdersテーブル内に直接保存することはできません。何個分の列を確保すればよいか分からないからです。同様に、注文情報をProductsテーブルに保存することもできません。

多対多の関係をサポートするには、第3のテーブル（「中間テーブル」または「接続テーブル」と呼ばれます）、例えばOrderDetails（またはOrderLines）を作成する必要があります。このテーブルの各行は、特定の注文における1つの商品項目を表します。OrderDetailsテーブルの主キーはorderIDとproductIDの2列で構成され、各行を一意に識別します。これらの列はOrdersテーブルとProductsテーブルを参照するため、OrderDetailsテーブルにおける外部キーでもあります。

実際には、多対多の関係は中間テーブルを導入することで、2つの1対多の関係として実装されます。

• 1つの注文は、OrderDetails内の複数の項目を持ちます。一方、OrderDetailsの各項目は、特定の1つの注文に属します。
• 1つの商品は、複数のOrderDetails項目に現れることがあります。一方、OrderDetailsの各項目は、1つの商品を指定します。

1対1（One-to-One）

「商品販売」データベースにおいて、商品には画像、詳細な説明、コメントなどの補足情報が任意で付随することがあります。これらをProductsテーブル内に保持すると、該当データを持たないレコードでは多くの空き領域が発生します。さらに、こうした大きなデータはデータベースのパフォーマンスを低下させる可能性があります。

代わりに、任意データを格納するための別のテーブル（ProductDetails、ProductLines、ProductExtrasなど）を作成できます。レコードは、補足データを持つ商品についてのみ作成されます。ProductsテーブルとProductDetailsテーブルは1対1の関係を示します。つまり、親テーブルの各行に対して、子テーブルには最大1行（0行の場合もある）が対応します。両方のテーブルで同じproductID列を主キーとして使用します。

一部のデータベースでは、テーブル内に作成できる列数に制限があります。そのような場合、1対1の関係を利用してデータを2つのテーブルに分割できます。また、機密性の高いデータをセキュアなテーブルに、それ以外のデータをメインのテーブルに分けて保存する際にも、1対1の関係が役立ちます。

列のデータ型

各列には適切なデータ型を選択する必要があります。一般的なデータ型には、整数型、浮動小数点数型、文字列型、日付/時刻型、バイナリ型、コレクション型（列挙型やセット型など）があります。

ステップ4：設計を洗練させ、正規化する

設計の改善には、例えば以下のような手法があります。

• 列を追加する
• 1対1の関係を利用して、任意データ用の新しいテーブルを作成する
• 大きなテーブルを2つの小さなテーブルに分割する
• その他の手法

正規化（Normalization）

いわゆる正規化ルールを適用し、データベースが構造的に正しく最適であるかを確認しましょう。

第一正規形（1NF）：すべてのセルが単一の値を持ち、値のリストを含まない場合、そのテーブルは1NFです。この特性は「原子性（atomic）」と呼ばれます。1NFでは、item1、item2、itemNのような繰り返しグループの列も禁止されています。代わりに、1対多の関係を利用して別のテーブルを作成すべきです。

第二正規形（2NF）：テーブルが1NFであり、かつすべての非キー列が主キーに完全に依存している場合、そのテーブルは2NFです。さらに、主キーが複数の列で構成されている場合、すべての非キー列はその全体セットに依存しなければならず、一部のみへの依存であってはなりません。

例えば、OrderDetailsテーブルの主キーがorderIDとproductIDで構成されているとします。unitPrice（単価）がproductIDのみに依存しているなら、それはOrderDetailsテーブルではなくProductsテーブルに保持すべきです。逆に、単価が商品と特定の注文の両方に依存しているのであれば、OrderDetailsテーブルに保持するのが正しいと言えます。

第三正規形（3NF）：テーブルが2NFであり、かつ非キー列同士が互いに独立している場合、そのテーブルは3NFです。言い換えると、非キー列は主キーのみに依存し、それ以外の何ものにも依存してはなりません。例えば、productID（主キー）、name、unitPriceの列を持つProductsテーブルがあるとします。discountRate（割引率）がunitPriceにも依存している場合、unitPriceは主キーの一部ではないため、discountRateはProductsテーブルに属すべきではありません。

より高度な正規形：3NFには不十分な点があり、そこからボイス・コッド正規形（BCNF）、第四正規形（4NF）、第五正規形（5NF）といったより高度な正規形につながります。これらは本チュートリアルの範囲外となります。

時には、パフォーマンス上の理由（例えば、OrderDetailsのレコードから導出可能なtotalPrice列をOrdersテーブルに作成するなど）や、エンドユーザーの要望により、正規化ルールの一部を意図的に破る判断をすることもあります。その場合は、その決定を十分に認識し、対応するプログラミングロジックを開発し、決定内容を適切にドキュメント化することが重要です。

整合性ルール（Integrity Rules）

設計の整合性を確認するために、以下の整合性ルールも適用しましょう。

1. 実体整合性ルール：主キーにはNULLを含めることはできません。NULLを含むと行を一意に識別できなくなるためです。複数の列で構成される複合キーの場合も、どの列にもNULLを含めてはなりません。ほとんどのRDBMSはこのルールをチェックし、強制します。

2. 参照整合性ルール：外部キーの値は、参照先のテーブル（親テーブル）の主キー値と必ず一致しなければなりません。

子テーブルに外部キーを持つ行を挿入できるのは、その値が親テーブルに存在する場合のみです。

親テーブルでキーの値が変更された場合（行の更新や削除など）、子テーブル内のこの外部キーを持つすべての行を適切に処理する必要があります。対応方法としては、(a) 変更を禁止する、(b) 子テーブル側に変更（または削除）を連鎖させる、(c) 子テーブルのキー値をNULLに設定する、の3つがあります。

ほとんどのRDBMSでは、指定された方式で参照整合性のチェックと保証を行うよう設定できます。

3. ビジネスロジック整合性：上記の2つの一般的な整合性ルールに加えて、ビジネスロジックに関する整合性（バリデーション）が存在する場合があります。例えば、郵便番号は5桁で特定の範囲内であること、配達日時は営業時間内であること、注文数量は在庫数量以下であることなどです。これらは、特定の列に対するバリデーションルールまたはプログラミングロジックによって実装できます。

列のインデックス（索引）

データの検索と取得を高速化するために、選択した列にインデックスを作成できます。インデックスは構造化されたファイルであり、SELECT文のデータアクセスを高速化しますが、INSERT、UPDATE、DELETEの処理速度を低下させる可能性があります。インデックス構造がない場合、一致条件を含むSELECTクエリ（例：SELECT * FROM Customers WHERE name='Tan Ah Teck'）を処理する際、データベースエンジンはテーブル内のすべてのレコードを比較する必要があります。しかし、BTREE構造のような特殊なインデックスを使用すれば、全レコードを比較することなく対象レコードに到達できます。ただし、レコードが変更されるたびにインデックスの再構築が必要となるため、インデックスの使用にはオーバーヘッドが伴います。

インデックスは、単一の列、複数の列のセット（「連結インデックス」と呼ばれます）、または列の一部（例：VARCHAR(100)の最初の10文字）（「部分インデックス」と呼ばれます）に対して定義できます。1つのテーブルに複数のインデックスを作成することも可能です。例えば、customerNameまたは電話番号で顧客を検索することが多い場合は、customerName列とphoneNumber列の両方にインデックスを作成することで検索を高速化できます。ほとんどのRDBMSは、主キーに対して自動的にインデックスを作成します。