データベースで制約を使用する方法

著者：Eve Cole 更新時間：2024-12-23 15:24:02

Downcodes のエディターを使用すると、データベースの制約を深く理解できます。データベース制約は、データの整合性と一貫性を維持するための基礎であり、データの正確性と信頼性を確保するためにデータベーステーブル内のデータが従う必要があるルールを定義します。この記事では、データベース制約の外部キー制約の種類、作成、変更、削除、使用について詳しく紹介し、データベースのパフォーマンスに対する制約の影響を分析し、最終的にはデータベース制約をより深く理解して適用するのに役立ちます。

データベース内の制約 (constrAInt) は、データの整合性、正確性、信頼性を確保するために使用されます。これらは、データベーステーブル内のデータが満たさなければならないルールを定義します。主なデータベース制約タイプには、一意制約 (UNIQUE)、主キー制約 (PRIMARY KEY)、外部キー制約 (FOREIGN KEY)、チェック制約 (CHECK)、および非 null 制約 (NOT NULL) があります。実際には、たとえばテーブルを作成するときに、テーブル内の各行が一意の識別子を持つことを確認するために主キー制約を指定することがあります。2 つの行が同じ主キー値を挿入しようとすると、データベースはその挿入を拒否します。 2列目。

1. 制約を作成する

制約の作成は通常、テーブルの作成時に行われますが、テーブルの作成後に追加することもできます。

たとえば、employees テーブルを作成する場合は、次のように設計します。

CREATE TABLE 従業員 (

従業員ID int NOT NULL、

LastName varchar(255) NOT NULL、

FirstName varchar(255)、

BirthDate 日付 CHECK (BirthDate > '1900-01-01')、

一意(従業員ID)、

主キー (従業員ID)

);

ここで、EmployeeID フィールドは、各従業員が反復不可能な識別子を持つことを保証するために、非 null 制約と一意制約の両方を設定します。 LastName フィールドには、新しいレコードを挿入するときにデータを指定する必要があることを保証する非 null 制約が含まれています。 BirthDate フィールドには、入力された日付が 1900 年 1 月 1 日以降であることを確認するためのチェック制約があります。

2. 制約の変更と削除

テーブルの作成後に制約を追加、削除、または変更する必要がある場合は、ALTER TABLE ステートメントを使用できます。

新しい CHECK 制約を追加すると、次のようになります。

ALTER TABLEの従業員

ADD CONSTRAINT CHK_BirthDate CHECK (BirthDate < GETDATE());

制約を削除するには:

ALTER TABLEの従業員

DROP CONSTRAINT CHK_BirthDate;

制約を変更するには、通常、最初に制約を削除し、次に新しい制約を追加する必要があります。

3. 外部キー制約の使用

外部キーは、テーブル間のリンクを作成するための鍵です。たとえば、部門テーブルと従業員テーブルがある場合、従業員テーブルに部門テーブルを指す外部キーを作成して、従業員が所属する部門が実際に存在することを確認できます。

従業員テーブルを作成するときは、次のように外部キー制約を設定します。

CREATE TABLE 部門 (

部門ID int 主キー、

部門名 varchar(255) NOT NULL

);

CREATE TABLE 従業員 (

従業員ID int主キー、

LastName varchar(255) NOT NULL、

FirstName varchar(255)、

部門ID int、

FOREIGN KEY (DepartmentID) REFERENCES 部門(DepartmentID)

);

4. 制約を使用してデータの一貫性を維持する

制約はデータの作成時に機能するだけでなく、データの更新および削除時にも一貫性を維持します。たとえば、外部キーが設定されているときに部門を削除しようとしたときに、その部門を参照している従業員がまだいる場合、データベースは操作を許可するかどうか、および外部キーの設定に基づいて操作を処理する方法を決定します( CASCADE、SET NULL、NO ACTION など) 既存の従業員レコード。

制約により、データベースの参照整合性が保証されます。たとえば、新しい従業員を追加するときに、その従業員の部門 ID が部門テーブルに存在しない場合、操作は失敗します。

5. 制約のパフォーマンスに関する考慮事項

制約を使用すると、データベースレベルでデータの精度と整合性を強制でき、アプリケーション層の制御よりも信頼性が高くなります。ただし、制約によってパフォーマンスのオーバーヘッドも発生します。データが挿入、更新、または削除されるたびに、データベースは関連するすべての制約をチェックする必要があるため、処理時間がさらにかかります。制約を設計するときは、データの整合性とシステムのパフォーマンスの間にトレードオフがあります。追加のパフォーマンスのオーバーヘッドにもかかわらず、ほとんどの場合、制約による利点がコストをはるかに上回ります。

6. まとめ

制約はデータベース設計に不可欠な部分であり、正しく使用すると、アプリケーションロジックを大幅に簡素化し、データの正確性と一貫性を確保できます。一般に、アプリケーションロジックで制約を実装するよりも、データベースレベルで制約を実装する方が信頼性が高くなります。制約を適切に設計すると、データベースが強力かつ柔軟になります。データベーススキーマを設計するときは、各テーブルに必要な制約を慎重に検討し、これらの制約が事後的にパフォーマンスに与える影響に注意を払う必要があります。監視とチューニングを行うことで、データベースがデータの一貫性を適切に維持しているだけでなく、効率的に実行されていることを確認できます。