Quelles sont les contraintes de base de données? [fermé]

Qu'est-ce qu'une définition claire de la contrainte de base de données? Pourquoi les contraintes sont-elles importantes pour une base de données? Quels sont les types de contraintes?

Les contraintes font partie d'une définition de schéma de base de données.

Une contrainte est généralement associée à une table et est créée avec une instruction CREATE CONSTRAINTou CREATE ASSERTIONSQL.

Ils définissent certaines propriétés que les données d'une base de données doivent respecter. Ils peuvent s'appliquer à une colonne, une table entière, plusieurs tables ou un schéma entier. Un système de base de données fiable garantit que les contraintes sont maintenues à tout moment (sauf éventuellement à l'intérieur d'une transaction, pour les contraintes dites différées).

Les types courants de contraintes sont:

• non nul - chaque valeur d'une colonne ne doit pas être NULL
• unique - la ou les valeurs dans la ou les colonnes spécifiées doivent être uniques pour chaque ligne d'une table
• clé primaire - la ou les valeurs de la ou des colonnes spécifiées doivent être uniques pour chaque ligne d'une table et ne pas être NULL ; normalement, chaque table d'une base de données doit avoir une clé primaire - elle est utilisée pour identifier des enregistrements individuels
• clé étrangère - la ou les valeurs dans la ou les colonnes spécifiées doivent référencer un enregistrement existant dans une autre table (via sa clé primaire ou une autre contrainte unique )
• check - une expression est spécifiée, qui doit être évaluée à vrai pour que la contrainte soit satisfaite

Pour comprendre pourquoi nous avons besoin de contraintes, vous devez d'abord comprendre la valeur de l'intégrité des données.

L'intégrité des données fait référence à la validité des données. Vos données sont-elles valides? Vos données représentent-elles ce à quoi vous les avez conçues?

Les questions étranges que je vous pose pourraient vous penser, mais malheureusement trop souvent, les bases de données sont remplies de données inutiles, de références invalides à des lignes dans d'autres tables, qui ont disparu depuis longtemps ... et des valeurs qui ne signifient rien pour la logique métier de votre solution plus longtemps.

Tous ces déchets ne sont pas seuls susceptibles de réduire vos performances, mais constituent également une bombe à retardement dans la logique de votre application qui finira par récupérer des données qu'elle n'est pas conçue pour comprendre.

Les contraintes sont des règles que vous créez au moment de la conception et qui protègent vos données contre la corruption. Il est essentiel pour la survie à long terme de votre cœur enfant d'une solution de base de données. Sans contraintes, votre solution se détériorera certainement avec le temps et une utilisation intensive.

Vous devez reconnaître que la conception de votre base de données n'est que la naissance de votre solution. Ici après, il doit vivre (espérons-le) longtemps et endurer toutes sortes de comportements (étranges) de la part de ses utilisateurs finaux (c'est-à-dire des applications clientes). Mais cette phase de conception en cours de développement est cruciale pour le succès à long terme de votre solution! Respectez-le et accordez-lui le temps et l'attention nécessaires.

Un homme sage a dit un jour: "Les données doivent se protéger!" . Et c'est ce que font les contraintes. Ce sont des règles qui maintiennent les données de votre base de données aussi valides que possible.

Il existe de nombreuses façons de le faire, mais elles se résument essentiellement à:

• Les contraintes de clé étrangère sont probablement la contrainte la plus utilisée et garantissent que les références à d'autres tables ne sont autorisées que s'il existe réellement une ligne cible à référencer. Cela rend également impossible de rompre une telle relation en supprimant la ligne référencée créant un lien mort.
• Les contraintes de vérification peuvent garantir que seules des valeurs spécifiques sont autorisées dans certaines colonnes. Vous pouvez créer une contrainte autorisant uniquement le mot «Jaune» ou «Bleu» dans une colonne VARCHAR. Toutes les autres valeurs entraîneraient une erreur. Obtenez des idées sur l'utilisation des contraintes de vérification vérifier la sys.check_constraintsvue dans l'exemple de base de données AdventureWorks
• Les règles dans SQL Server ne sont que des contraintes de vérification réutilisables (vous permet de conserver la syntaxe à partir d'un seul endroit et de faciliter le déploiement de vos contraintes sur d'autres bases de données)

Comme je l'ai indiqué ici, il faut des considérations approfondies pour construire la meilleure approche de contrainte et la plus défensive pour la conception de votre base de données. Vous devez d'abord connaître les possibilités et les limites des différents types de contraintes ci-dessus. D'autres lectures pourraient inclure:

Contraintes FOREIGN KEY - Microsoft

Contrainte de clé étrangère - W3schools

CHECK Contraintes

Bonne chance! ;)

Les contraintes ne sont rien d'autre que les règles sur les données. Les données valides et non valides peuvent être définies à l'aide de contraintes. Ainsi, cette intégrité des données peut être maintenue. Voici les contraintes largement utilisées:

1. Clé primaire : qui identifie de manière unique les données. Si cette contrainte a été spécifiée pour certaines colonnes, nous ne pouvons pas entrer de données en double dans cette colonne
2. Vérifier : comme NOT NULL. Ici, nous pouvons spécifier les données que nous pouvons entrer pour cette colonne particulière et ce qui n'est pas attendu pour cette colonne.
3. Clé étrangère : références de clé étrangère à la ligne d'une autre table. Ainsi, les données référencées dans une table à partir d'une autre table sont toujours disponibles pour la table de référencement.

Les contraintes peuvent être utilisées pour appliquer des propriétés spécifiques de données. Un exemple simple consiste à limiter une colonne int aux valeurs [0-100000]. Cette introduction semble bonne.

Les contraintes déterminent les valeurs valides pour les données de la base de données. Par exemple, vous pouvez imposer qu'une valeur n'est pas nulle (une NOT NULLcontrainte), ou qu'elle existe en tant que contrainte unique dans une autre table (une FOREIGN KEYcontrainte), ou qu'elle est unique dans cette table (une UNIQUEcontrainte ou peut-être une PRIMARY KEYcontrainte en fonction de vos besoins ). Des contraintes plus générales peuvent être implémentées à l'aide de CHECKcontraintes.

La documentation MSDN pour les contraintes SQL Server 2008 est probablement votre meilleur point de départ.

1. UNIQUEcontrainte (dont une PRIMARY KEYcontrainte est une variante). Vérifie que toutes les valeurs d'un champ donné sont uniques dans la table. C'est la Xcontrainte -axis (enregistrements)

2. CHECKcontrainte (dont une NOT NULLcontrainte est une variante). Vérifie qu'une certaine condition est valable pour l'expression sur les champs du même enregistrement. C'est la Ycontrainte -axis (champs)

3. FOREIGN KEYcontrainte. Vérifie que la valeur d'un champ se trouve parmi les valeurs d'un champ dans une autre table. C'est la Zcontrainte -axis (tables).

Une base de données est la représentation logique informatisée d'un modèle conceptuel (ou commercial), constitué d'un ensemble de règles commerciales informelles. Ces règles sont la signification des données comprise par l'utilisateur. Les ordinateurs ne comprenant que des représentations formelles, les règles métier ne peuvent pas être représentées directement dans une base de données. Ils doivent être mappés à une représentation formelle, un modèle logique, qui consiste en un ensemble de contraintes d'intégrité. Ces contraintes - le schéma de base de données - sont la représentation logique dans la base de données des règles métier et, par conséquent, sont la signification des données comprise dans le SGBD. Il s'ensuit que si le SGBD ne connaît pas et / ou n'applique pas l'ensemble complet des contraintes représentant les règles métier, il a une compréhension incomplète de la signification des données et, par conséquent,

Remarque: Le SGBD - sens «compris» - contraintes d'intégrité - n'est pas identique au sens compris par l'utilisateur - règles métier - mais, malgré la perte de sens, nous acquérons la capacité de mécaniser les inférences logiques à partir des données.

"Une vieille classe d'erreurs" par Fabian Pascal

Il existe essentiellement 4 types de contraintes principales en SQL:

• Contrainte de domaine: si l'une des valeurs d'attribut fournies pour un nouveau tuple n'est pas du domaine d'attribut spécifié

• Contrainte de clé: si la valeur d'un attribut clé dans un nouveau tuple existe déjà dans un autre tuple de la relation

• Intégrité référentielle: si une valeur de clé étrangère dans un nouveau tuple fait référence à une valeur de clé primaire qui n'existe pas dans la relation référencée

• Intégrité de l'entité: si la valeur de la clé primaire est nulle dans un nouveau tuple

les contraintes sont des conditions qui peuvent valider une condition spécifique. Les contraintes liées à la base de données sont l'intégrité du domaine, l'intégrité de l'entité, l'intégrité référentielle, les contraintes d'intégrité définie par l'utilisateur, etc.