データベースの制約とは何ですか？[閉まっている]

データベース制約の明確な定義は何ですか？データベースにとって制約が重要なのはなぜですか？制約のタイプは何ですか？

制約はデータベーススキーマ定義の一部です。

制約は通常、テーブルに関連付けられており、CREATE CONSTRAINTまたはCREATE ASSERTIONSQLステートメントで作成されます。

データベースのデータが従わなければならない特定のプロパティを定義します。列、テーブル全体、複数のテーブル、またはスキーマ全体に適用できます。信頼性の高いデータベースシステムは、制約が常に保持されることを保証します（いわゆる遅延制約の場合、トランザクション内を除く）。

一般的な種類の制約は次のとおりです。

• 非null-列の各値はNULLであってはなりません
• unique- 指定された列の値は、テーブルの各行で一意である必要があります
• 主キー -指定された列の値は、テーブルの各行で一意であり、NULLであってはなりません。通常、データベースの各テーブルには主キーが必要です-個々のレコードを識別するために使用されます
• 外部キー -指定された列の値は、（主キーを介して）別のテーブルの既存のレコードを参照する必要がありますまたはその他の一意の制約を）
• チェック -式が指定され、制約が満たされるにはtrueと評価される必要があります

制約が必要な理由を理解するには、まずデータの整合性の価値を理解する必要があります。

データの整合性とは、データの有効性を指します。データは有効ですか？あなたのデータはあなたがそれらを設計したものを表していますか？

私があなたに尋ねる奇妙な質問は何だと思うかもしれませんが、残念なことに、データベースはガベージデータ、他のテーブルの行への無効な参照、長い間存在していません...そしてビジネスロジックにとって何の意味もない値でいっぱいですあなたのソリューションのもう。

このすべてのゴミは、パフォーマンスを低下させる傾向があるだけでなく、アプリケーションロジックの下の時限爆弾であり、最終的には理解するように設計されていないデータを取得します。

制約は、データが破損するのを防ぐために設計時に作成するルールです。それは、データベースソリューションの心臓の子供が長生きするために不可欠です。制約がなければ、あなたのソリューションは間違いなく時間と負荷の高い使用によって減衰します。

データベース設計の設計は、ソリューションの誕生にすぎないことを認めなければなりません。その後、それは（うまくいけば）長い間存続し、エンドユーザー（つまり、クライアントアプリケーション）によるあらゆる種類の（奇妙な）動作に耐えなければなりません。しかし、開発におけるこの設計フェーズは、ソリューションの長期的な成功にとって重要です。それを尊重し、必要な時間と注意を払ってください。

賢者はかつて「データは自分自身を守らなければならない！」と言っていました。。そして、これは制約が行うことです。データベース内のデータを可能な限り有効に保つのはルールです。

これには多くの方法がありますが、基本的には次のように要約されます。

• 外部キー制約はおそらく最もよく使用される制約であり、参照するターゲット行が実際に存在する場合にのみ他のテーブルへの参照が許可されるようにします。これにより、参照された行を削除して無効なリンクを作成することで、このような関係を解除することもできなくなります。
• チェック制約により、特定の列で特定の値のみが許可されるようにすることができます。VARCHAR列で「黄色」または「青」という単語のみを許可する制約を作成できます。他のすべての値はエラーになります。チェック制約の使用に関するアイデアを得るsys.check_constraintsAdventureWorksサンプルデータベースのビューを確認してください
• SQL Serverのルールは再利用可能なチェック制約にすぎません（単一の場所から構文を維持できるため、制約を他のデータベースに簡単に展開できます）

ここでほのめかしたように、データベース設計に最適で最も防御的な制約アプローチを構築するには、いくつかの徹底的な考慮が必要です。まず、上記のさまざまな制約タイプの可能性と制限を知る必要があります。さらに読むことができます：

FOREIGN KEY制約-Microsoft

外部キー制約-w3schools

チェック制約

幸運を！;）

制約は、データに関するルールにすぎません。有効なデータと無効なデータは、制約を使用して定義できます。したがって、そのデータの整合性を維持できます。以下は、広く使用されている制約です。

1. 主キー：データを一意に識別します。この制約が特定の列に指定されている場合、その列に重複データを入力することはできません
2. チェック：などNOT NULL。ここでは、特定の列に入力できるデータと、その列に予期されないデータを指定できます。
3. 外部キー：他のテーブルの行への外部キー参照。そのため、あるテーブルから別のテーブルで参照されるデータは、参照元のテーブルで常に利用できます。

制約を使用して、データの特定のプロパティを適用できます。簡単な例は、int列を値[0-100000]に制限することです。この紹介は良さそうです。

制約により、データベース内のデータに有効な値が決まります。たとえば、値がnullではない（NOT NULL制約）か、別のテーブルに一意の制約として存在する（FOREIGN KEY制約）か、またはこのテーブル内で一意である（UNIQUE制約またはPRIMARY KEY要件に応じた制約）かを強制できます。 ）。より一般的な制約は、制約を使用して実装できCHECKます。

の SQL Server 2008個の制約のためのMSDNドキュメントは、おそらくあなたの最高の出発点です。

1. UNIQUE制約（そのPRIMARY KEY制約はバリアントです）。特定のフィールドのすべての値がテーブル全体で一意であることを確認します。これはX-axis制約です（レコード）

2. CHECK制約（そのNOT NULL制約はバリアントです）。同じレコードのフィールドで式の特定の条件が満たされていることを確認します。これはY-axis制約です（フィールド）

3. FOREIGN KEY制約。フィールドの値が別のテーブルのフィールドの値の中にあることを確認します。これはZ-axis制約（テーブル）です。

データベースは、一連の非公式なビジネスルールで構成される、概念（またはビジネス）モデルのコンピューター化された論理表現です。これらのルールは、ユーザーが理解するデータの意味です。コンピュータは正式な表現しか理解しないため、ビジネスルールをデータベースで直接表現することはできません。それらは、一連の整合性制約で構成される論理モデルである正式な表現にマップする必要があります。これらの制約（データベーススキーマ）は、ビジネスルールのデータベース内の論理表現であり、したがって、DBMSが理解しているデータの意味です。したがって、DBMSがビジネスルールを表す制約の完全なセットを認識していない、または適用していない場合、DBMSはデータの意味を完全に理解していないため、

注：DBMSの「理解された」意味—整合性の制約—はユーザーが理解した意味—ビジネスルールと同じではありませんが、一部の意味が失われているにもかかわらず、データからの論理的な推論を機械化する能力が得られます。

Fabian Pascalによる「古いクラスのエラー」

SQLの基本的な制約には、基本的に4つのタイプがあります。

• ドメイン制約：新しいタプルに提供された属性値の1つが指定された属性ドメインのものではない場合

• キー制約：新しいタプルのキー属性の値が関係の別のタプルにすでに存在する場合

• 参照整合性：新しいタプルの外部キー値が、参照される関係に存在しない主キー値を参照する場合

• エンティティの整合性：新しいタプルの主キー値がnullの場合

制約は特定の条件を検証できる条件です。データベースに関連する制約は、ドメインの整合性、エンティティの整合性、参照整合性、ユーザー定義の整合性制約などです。