この章では、以下の項目について説明します。

この章では、リレーショナル データベース設計の基本原則について概説します。開発プロセス全体にわたる完全なデータベース設計は、データベースの機能とパフォーマンスの成功に不可欠です。

サンプル データベースの DEMODATA は PSQL の一部として提供されており、データベースの概念と技法を図解するためにマニュアルで頻繁に使用されます。テーブル、行、列などの基本的なリレーショナル データベース概念の定義については、PSQL オンライン ヘルプの用語集を参照してください。

リレーショナル データベースの基本的な構造を理解すれば、データベース設計プロセスを開始することができます。データベースの設計は、ビジネスに応じたデータベース構造の開発と精製に関連するプロセスです。

データベースの設計には、以下の 3 つの段階があります。

データベース設計サイクルの最初のステップは、業務に必要なデータを定義することです。以下のような質問に答えることで、概念設計をより明確に定義できます。

業務の目標を明確に定め、データベースを使用することになるスタッフからの意見を収集することは不可欠なプロセスです。この情報で、テーブルと列を効率的に定義できます。

論理データベース設計により、以降のビジネスの情報要求の定義と評価を容易に行えます。論理データベース設計では、追跡しなければならない情報とこれらの各情報間の関係を記述します。

論理設計を終了すると、ユーザーと共にデータベースの設計が完全かつ正確であるかどうかを検証できます。ユーザーは、追跡しなければならないすべての情報が設計に含まれているかどうかを判断したり、設計が業務の流れに応じた情報の関係を反映しているかどうかを判断することができます。

論理データベース設計の作成は、以下の手順で行います。

リレーショナル データベースで、共通の列を共有することによってテーブルを相互に関連付けます。この列は複数のテーブルに存在し、テーブルの結合を可能にします。テーブルの関係には、1 対 1、1 対多、および多対多の 3 種類があります。

「1 対 1 の関係」は、あるテーブルの各行が第 2 テーブルの 1 つの行にのみ関連付けられる場合に生じます。たとえば、ある大学では 1 つの部屋に 1 人の教職員を割り当てることに決めています。したがって、1 つの部屋には一度に 1 人の教官しか割り当てることができません。またその大学では、1 つの学部に 1 人の学部長しか任命できないことに決めています。したがって、1 人しか学部長になれません。

「1 対多の関係」は、あるテーブルの各行が別のテーブルの多数の行に関連付けられる場合に生じます。たとえば、1 人の教官が多数のクラスを教えることができます。

「多対多の関係」は、あるテーブルの 1 つの行が第 2 テーブルの多数の行に関連付けられる場合に生じます。同様に、これらの関連付けられた行は第 1 テーブルの多数の行とも関連付けられます。たとえば、1 人の学生が多数の講座に登録できると同時に、それらの講座も多数の学生を受け入れることができます。

正規化は、データベース内の冗長性を低下させて安定性を高めるプロセスです。正規化は、特定のデータがどのテーブルに属しているか、また、ほかのデータとの関係はどうであるかを決定します。その結果、対象となるデータベースは、プロセスまたはアプリケーション駆動型でなく、さらに安定したデータベース実装を提供するデータ駆動型の設計になります。

データベースを正規化する場合、以下の列を排除します。

第 1 正規形の列には、以下の特性があります。

正規化の第 1 の規則は、「重複する列または複数の値を含む列を、新しいテーブルへ移動しなければならない」というものです。

第 1 正規形に正規化されたテーブルには、いくつかの利点があります。たとえば、サンプル データベースの Billing テーブルでは、第 1 正規形によって以下が実行されます。

第 1 正規形のテーブルで、そのテーブルのキーに関する情報を提供する列のみを含んでいるテーブルは、第 2 正規形です。

正規化の第 2 の規則を実施するには、現在のテーブルの主キーに依存しない列を新しいテーブルへ移動しなければなりません。

テーブルに冗長データが含まれている場合、そのテーブルは第 2 正規形に違反します。このため、一貫性のないデータが生じ、データベースの整合性を欠くことになります。たとえば、学生が住所を変更した場合には、新しい住所を反映させるよう、既存のすべての行を更新する必要があります。古い住所を含んでいる行は、一貫性のないデータとなってしまいます。

データが冗長であるかどうかを判断するには、トランザクションを追加しても変化しないデータを確認します。Student Name や Street のような列はトランザクションに関係なく、主キーの Student ID によって異なります。したがって、この情報は Student テーブルに格納し、トランザクション テーブルには格納しません。

第 2 正規形に正規化されたテーブルにも、いくつかの利点があります。たとえば、サンプル データベースの Billing テーブルでは、第 2 正規形によって以下が実行されます。

テーブルに独立した列だけが含まれているとき、そのテーブルは第 3 正規形です。

正規化の第 3 の規則は、「既存の列から派生できる列を除去しなければならない」というものです。たとえば、ある学生の場合、Date of Birth 列が既にあるならば、Age 列を含める必要はありません。年齢は誕生日から計算できるからです。

第 3 正規形のテーブルには必要な列だけが含まれており、不要なデータが格納されないことから、ディスク領域をさらに効率よく使用できます。

要約すると、第 1、第 2、および第 3 正規形の規則が示していることは、各列の値は主キー全体に関する事実でなければならない、つまり主キーにほかならないということです。

ODBC キーは、テーブルの参照整合性（RI）の制約が定義されている列または列のグループです。つまり、キーまたは複数のキーの組み合わせは、行に含まれるデータの識別子として機能します。

参照整合性とキーの詳細については、『Advanced Operations Guide』を参照してください。

物理データベース設計は、論理設計をより洗練されたものにすることです。物理データベース設計は、論理設計をリレーショナル データベース管理システムにマップします。この段階で、ユーザーがデータベースにアクセスする方法を調べます。データベース設計サイクルのこのステップでは、以下の種類の情報を決定します。