SQLで一般的に使用されるキーと制約

キーと制約とは何ですか?

データベースは、格納しているデータの整合性と品質を維持するために、特定のプロパティを遵守する必要があります。 キーと制約は、特定のデータ列で許可されるデータ値を定義するルールです。 これらは重要なデータベースの概念であり、データベースのスキーマ定義の一部です。 キーと制約を定義することは、データベース設計プロセスの一部であり、データベース内のデータが信頼性が高く、整合性が維持されるようにします。 制約は、特定の列、表全体、複数の表、またはスキーマ全体に適用できます。 信頼性の高いデータベースシステムは、制約が常に保持されることを保証します。 キーは、関係と一意性を確立するために使用される特別なタイプの制約です。

主キー

二つのエンティティまたは二つのデータの間の関係を確立するために必要な部分は、データを正しく識別することです。 SQLでは、データを一意に識別することが重要です。 主キーは、データ行の一意の識別子です。 これまで使用してきたスプレッドシートの類推では、常にid列がありました。 どの列も主キーとして使用できますが、idという名前の列を使用するのはニーモニックな理由から簡単であり、一般的な慣習です。 RDBMSでは、各テーブルには1つの主キーのみを持つことができます。

主キーは、テーブル内の行の保証された一意の識別子です。 このため、行の主キー値を使用して、他のテーブルからその行を参照できます。 前の章では、それに基づいて複数のテーブル間の関係を確立しましたが、リレーショナルデータベースは相互に関連する方法が必要であり、主キー列はこれを効率的に行う方法です。 PostgreSQLでは、主キーは、特に複数テーブルの検索でデータを検索するために頻繁に使用されることが知られているため、パフォーマンス上の利点も与えられます。

“id”という名前のすべての列が主キーであるわけではないことに注意してください。 また、主キーには任意の名前を付けることができます。

前の章では、列を主キー列として指定する構文をすでに見てきました。

主キーを理解する観点から、usersというテーブルを作成する上記のコマンドを見てみましょう。

  1. id columnは、このテーブルの主キーです。 また、Primary Key制約がid列に適用されているとも言えます。
  2. idは数値(int)のみを保持できます。
  3. テーブルに新しい行が追加されるたびに、idフィールドは自動的に1ずつ増加します。 多くのRDBMSでは、AUTO_INCREMENTキーワードが使用されます。 PostgreSQLでは、serialを使用してidを自動インクリメントし、そのタイプを整数として設定します。 データを挿入するたびに主キー値を手動で指定する必要はありません。idのタイプとしてserialを指定すると、PostgreSQLがそれを行います。

外部キー

外部キー列は、別のテーブル内の別のデータ行を参照するために使用されます。 別の行を参照するには、データベースにその行の一意の識別子が必要です。 したがって、外部キー列には、参照される行の主キーの値が含まれます。 たとえば、テーブルには、user_idという名前の列が外部キー列としてあり、これはusersテーブルのid列に対応します。 外部キーは、RDBMSが同じテーブル内またはテーブル間のデータ行間のリレーションシップを設定する方法です。

上記のSQLステートメントから、この関係を確立する行が次のようになることがわかります

FOREIGN KEY (book_id) REFERENCES books(id) ON DELETE CASCADE

上記の例では、idbooksテーブルの主キーであり、reviewsテーブルとの関係を確立するために使用されます。 idデータは、book_idフィールドのreviewsテーブルに格納され、書籍とレビューをマップします。 ON DELETE CASCADE句は、ブックが削除された場合、そのブックに関連付けられているすべてのレビューも削除されることを示します。

主キーとしての複合キー

前の章では、主キーが2つの列で構成された多対多の関係を作成しました。 SQL文の次の行に示すように、user_idbook_idは両方とも相互参照表の主キーを形成しています。

PRIMARY KEY (user_id, book_id)

primary_keyが一意のペアPRIMARY KEY (user_id, book_id)で構成されている場合、複合キーと呼ばれます。 これは通常、多対多の関係で発生し、この関係データを格納するために余分なテーブルを追加する必要があります。 複合キーは、テーブル内のデータがユーザーとブックの間の関係に対して一意になるようにします。 例:

|User_id | Book_id | | 1 | 1 | | 1 | 2 | | 2 | 1 | 

UNIQUE Constraints

データベースでは、主キーのほかに、データベース内の任意の列にUnique constraintsを適用することもできます。 たとえば、booksテーブルでは、一意の主キーとしてbook_idを持つだけでなく、本のISBN番号を格納する必要があることもあります。 ISBN、国際標準ブック番号は、本のための10桁の一意の番号です。 この列を一意にするためにデータベースを設計することを選択できます。 これは主キーではありませんが、Isbnの重複はbooksテーブルでは許可されず、データ品質は維持されます。

Unique制約により、isbnの列値に対してbooksテーブルへの重複エントリが許可されません。

NOT NULL制約

多くのSQLステートメントで”NOT NULL”を見てきました。 NOT NULL制約は、列がnull値を許可することを防ぎます(つまり、この列にはデータが含まれている必要があります)。 これは、キー項目にとって重要です。 例:データベースにユーザーを追加する場合は、ユーザー名を指定する必要があります。 この制約がなければ、データベースはnull値で満たされ、あまり有用ではなくなります。

SQLはこれらの関係をどのように処理しますか?

PostgreSQLでは、外部キーとJOINと呼ばれる操作を使用して、異なるテーブルのスキーマとデータの両方の関係を可能にします。 名前が示すように、目的はテーブルを結合することです。 このメカニズムを使用すると、たとえば、userテーブルに関連するフィールドuser_idがあるため、上に示したreviewsテーブルの作成者の完全な詳細を取得できます。 ここでは簡単な例です:

複数のテーブルを作成する方法と、リレーションシップを確立する際に役割キーが果たす方法を理解したので、さまざまな結合と、これらの結合を使用して複数のテーブルから必要なデータを取得するSQLクエリがどのように構築されているかをより深く見ていきます。

コメントを残す

メールアドレスが公開されることはありません。