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?
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?
Réponses:
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 CONSTRAINT
ou CREATE ASSERTION
SQL.
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:
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 à:
sys.check_constraints
vue dans l'exemple de base de données AdventureWorksComme 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
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:
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.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 NULL
contrainte), ou qu'elle existe en tant que contrainte unique dans une autre table (une FOREIGN KEY
contrainte), ou qu'elle est unique dans cette table (une UNIQUE
contrainte ou peut-être une PRIMARY KEY
contrainte en fonction de vos besoins ). Des contraintes plus générales peuvent être implémentées à l'aide de CHECK
contraintes.
La documentation MSDN pour les contraintes SQL Server 2008 est probablement votre meilleur point de départ.
UNIQUE
contrainte (dont une PRIMARY KEY
contrainte est une variante). Vérifie que toutes les valeurs d'un champ donné sont uniques dans la table. C'est la X
contrainte -axis (enregistrements)
CHECK
contrainte (dont une NOT NULL
contrainte est une variante). Vérifie qu'une certaine condition est valable pour l'expression sur les champs du même enregistrement. C'est la Y
contrainte -axis (champs)
FOREIGN KEY
contrainte. Vérifie que la valeur d'un champ se trouve parmi les valeurs d'un champ dans une autre table. C'est la Z
contrainte -axis (tables).
CHECK
contraintes, alors pourquoi les classer différemment? c'est-à-dire " Y
-axis" (quoi que cela signifie).
FOREIGN KEY
utilisant une CHECK
contrainte?
SELECT
question. Vous ne pouvez pas utiliser de sous-requêtes (ou toute autre construction faisant référence à des valeurs en dehors de l'enregistrement actuel) dans les CHECK
contraintes dans SQL Server
.
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.