主キーは、リレーショナル・データベースにおいて重要な役割を果たしており、データの整合性を維持し、データの正確な取得を可能にします。さらに、主キーは他の種類のキーから参照されることで、リレーショナル・データベース内のテーブル間の関係を定義することができます。
さまざまなデータベースでよく例として挙げられる主キーには、次のようなものがあります。
主キーの詳細を確認する前に、リレーショナル・データベース・システムと、データベース設計内で主キーなどのキーが果たす役割について理解しておくとよいでしょう。
リレーショナル・データベースは、複数のテーブルにまたがって構造化されたデータと、異なるテーブル間に関連するデータ点を格納します。このようなデータベースは、IBM Db2、Oracle Database、Microsoft SQL Serverなどのリレーショナル・データベース管理システム(RDBMS)、およびPostgreSQLやmySQLなどのオープンソース・データベース・システムによって管理されます。
構造化クエリ言語(SQL)は、データベースとのやり取りに広く使用されている一般的なプログラミング言語ですが、一部のデータベース管理システムでは他の言語もサポートされています。
データベースの文脈において、キーとは、テーブル内のデータ行を識別するために使用される1列または複数列の順序付きの集合です。キーは、関連するテーブル間の関係を示し、一意のレコードを識別し、データの正確性と整合性を保証することで、データベースの構造化に役立ちます。これらのメリットは、SQLデータベースにおけるクエリを正確かつ効率的に実行することが可能になります。
主キー(SQL主キーとも呼ばれます)は、主キー値に関連付けられた各レコードに対して一意の識別子を付与します。主キーの重要な特徴には、次のような点が含まれます。
主キーは1つのテーブル内の既存の列である場合もあり、その場合はナチュラル・キーと呼ばれます。しかし、主キー制約(値が一意であり、NULLであってはならないという主キーのルール)を満たす列がテーブル内に1つもないことがあります。
そのような場合、テーブル内の既存データに基づかない一意の値を持つ新しい列が生成され、主キーとして使用されることがあります。このように人工的に生成された主キーは、サロゲート・キー(代理キー)と呼ばれます。
リレーショナル・データベース管理システム(RDBMS)には、列に対して一意の値を自動生成する機能が一般的に備わっており、それをサロゲート・キーとして使用することができます。その1例が、MySQLの自動増分(auto-increment)機能です。
主キーは複合キーでもかまいません。つまり、複数の値の列で構成されます。
複合主キー(レコードを識別するために使用できる、複数の列の一意な組み合わせ)は、サロゲート・キーを生成する代替手段として利用できます。 たとえば、顧客の姓を含む列と生年月日を含む列を組み合わせて、複合主キーを構成することができます。
SQLは、タイムスタンプ (日付と時刻の表現)からvarchar(可変長文字列)まで、さまざまなデータ型をサポートしていますが、すべてのデータ型が主キーに適しているわけではありません。
数値(特に整数)を含む列は通常、リレーショナル・データベース管理システムにより迅速に処理されるため、主キーとして使用することが推奨されます。
データベース管理で使用されるその他のキーには、次のものがあります。
主キーは一意キーのサブセットです。一意キーはユニーク制約として知られるルールに従っており、そのキーの値が一意である場合にのみ有効と見なされます。すべての主キーは一意キーですが、すべての一意キーが主キーというわけではありません。それは、主キーと異なり、一意キーにはnull値を含めることができるためです。
候補キーは、一意の値を含み、NULL値がないため、主キーとして機能できるキーです。主キーと候補キーの違いは、既存のテーブルには複数の候補キーを含めることができますが、主キーは1つだけであることです。
スーパー・キーは複合主キーと似ており、複数の列を含み、レコードの識別に使用されます。ただし、スーパー・キーには、レコードを一意に識別するために厳密に必要な数よりも多くの列や情報が含まれるのに対し、複合主キーには必要以上の列やデータは含まれません。
あるテーブルの外部キーは、別のテーブルの特定の主キーを参照することで、両テーブル間の関係を定義します。たとえば、顧客の注文情報を格納したテーブルの外部キーが、別のテーブルにある顧客データの一部である一意な顧客IDの主キー列を参照することがあります。これにより、ある顧客による注文を、その顧客に関する重要な情報(Eメール・アドレスや生年月日など)と関連付けることができます。
主キーと外部キーがリレーショナル・データベース内のテーブル間の関係をどのように定義するかを理解するには、参照整合性制約について考えるとよいでしょう。
参照整合性制約(リファレンシャル制約または外部キー制約とも呼ばれる)とは、あるテーブルの外部キーの値が、別のテーブルの主キーの値と一致していなければならないというルールです。
たとえば、従業員データベースでは、EMPLOYEEテーブル内の各従業員が、DEPARTMENTテーブルに登録されている既存の部門に所属していなければならない、という参照整合性制約を設けることができます。
この場合、DEPARTMENTテーブルの主キーは、一意の部門番号を保管する列であり、EMPLOYEEテーブルの外部キーは、同じ一意の部門番号を保管する列です。これらの一致する列は、テーブルが外部キー制約に準拠していることを意味します。
DEPARTMENTテーブルはEMPLOYEEテーブルの外部キーによって参照される主キーのホームであるため、EMPLOYEEキーはDEPARTMENTテーブルに依存していると見なされます。一方、DEPARTMENTテーブルは、このテーブル・リレーションシップの「親テーブル」と見なされます。
参照整合性制約は、誤ったデータの挿入をデータベースで防ぐことができます。たとえば、以下に示すEMPLOYEEテーブルに対して、従業員レコードの中に存在しない部門番号が含まれている場合、参照整合性制約により、そのレコードを追加することはできません。
リレーショナル・データベース管理システムは、データベース内の各主キーに対応する一意のインデックスを作成するか、作成を要求することがあります。データベース設計におけるインデックスとは、テーブル内の行を指し示すポインターの集合を指します。インデックスは、データ検索の最適化など、パフォーマンスの向上に利用されます。
データ・モデリングは、データベース・スキーマ、すなわちデータベース内のテーブル間のデータ関係の設計図を視覚的に表現したものです。データ・モデルには、こうした関係性を維持するために使用される主キーや外部キーに関する情報が含まれることがあります。
SQLステートメントは、リレーショナル・データベースとやり取りするために使用されるコマンドです。SQL構文では、CREATE TABLEまたはALTRE TABLEステートメントを使用してテーブルの主キーを割り当てまたは追加できます。
例えば、IBMのDb2を使用する従業員名のテーブルEMPに対するCREATE TABLEステートメントを考えてみましょう。列名は、ID(従業員IDの場合)、FIRSTNMEおよびLASTNAME(それぞれ最大15文字)です。IDが主キーとして選択された場合、ステートメントは次のようになります。
Db2における既存テーブルに対するALTER TABLE文では、主キーを追加するための句はADD PRIMARY KEYであり、外部キーは親テーブルへの参照と組み合わせてADD CONSTRAINTを使用して追加されます。
IBMのデータベース・ソリューションを活用して、ハイブリッドクラウド全体のさまざまなワークロードのニーズに対応しましょう。
構造化データの保管と管理に高性能で拡張性と信頼性を備えたリレーショナル・データベースであるIBM Db2をご覧ください。IBM Cloud上でSaaSとして、もしくはセルフホスティングとしてご利用いただけます。
IBMコンサルティングと連携することで、企業データの価値を引き出し、ビジネス上の優位性をもたらす洞察を活用した組織を構築します。