Quelle est la différence entre les déclencheurs, les assertions et les vérifications (dans la base de données)

Dans le standard SQL, les ASSERTIONS et les contraintes de vérification sont ce que la théorie relationnelle appelle des "contraintes": des règles auxquelles les données réellement contenues dans la base de données doivent se conformer.

La différence entre les deux est que les contraintes de vérification sont, dans un sens, beaucoup plus "simples" : ce sont des règles qui se rapportent à une seule ligne, tandis que les ASSERTIONs peuvent impliquer n'importe quel nombre d'autres tables, ou n'importe quel nombre d'autres lignes dans la même table. Cela rend évidemment (beaucoup !) plus complexe pour les constructeurs de SGBD pour le supporter, et c'est, à son tour, la raison pour laquelle ils ne le font pas : ils ne savent tout simplement pas comment le faire.

Les déclencheurs sont des morceaux de code exécutable dont il peut être déclaré au SGBD que ceux-ci doivent être exécutés chaque fois qu'un certain type d'opération de mise à jour (insert/delete/update) se fait sur une certaine table. Parce que les déclencheurs peuvent déclencher des exceptions, ils sont un moyen d'implémenter la même chose qu'une ASSERTION. Cependant, avec les déclencheurs, c'est toujours le programmeur qui doit faire tout le codage, et ne pas faire d'erreur.

Modifier

Onedaywhen commentaires re. ASSERTION / vérifier cnstr. sont corrects. La différence est beaucoup plus subtile (et déroutante). La norme autorise en effet les sous-requêtes dans les contraintes de contrôle. (La plupart des produits ne le supportent pas, donc mon "rapport à une seule ligne" est vrai pour la plupart des produits SQL, mais pas pour la norme.) Donc, il y a toujours une différence ? Oui, il l'est toujours. Plus d'un, même.

Premier cas: hommes de TABLE (ID:entier) et les femmes de la TABLE (ID: entier). Imaginez maintenant une règle selon laquelle "aucune valeur D'identification ne peut apparaître à la fois dans le tableau MEN et dans le tableau WOMEN". C'est une règle unique. L'intention de L'ASSERTION est précisément que le concepteur de base de données indiquerait cette règle unique [et en ferait usage], et le SGBD saurait comment gérer cela [efficacement, bien sûr] et comment appliquer cette règle, quelle que soit la mise à jour de la base de données. Dans l'exemple, le SGBD saurait qu'il doit faites une vérification de cette règle lors de L'insertion dans les hommes, et lors de L'insertion dans les femmes, mais pas lors de la suppression de MEN / WOMEN, ou de L'insertion dans .

Mais les SGBD ne sont pas assez intelligents pour faire tout cela. Donc, ce qui doit être fait ? Le concepteur de base de données doit ajouter deux contraintes de vérification à sa base de données, une à la table MEN (en vérifiant les identifiants MEN nouvellement insérés par rapport à la table WOMEN) et une à la table WOMAN (en vérifiant l'inverse). Il y a votre première différence : une règle, une ASSERTION, deux contraintes de vérification . Les contraintes de vérification sont un niveau d'abstraction inférieur aux ASSERTIONs, car elles exigent que le concepteur réfléchisse davantage à (a) tous les types de mise à jour qui pourraient potentiellement causer la violation de son affirmation, et (b) quelle vérification particulière devrait être effectuée pour l'un des "types de mise à jour" spécifiques qu'il a trouvé dans (a). (Bien que je n'aime pas vraiment faire des déclarations "absolues" sur ce qui est encore "quoi" et ce qui est "comment", je résumerais ces contraintes de vérification nécessitent plus de réflexion " comment "(procédurale) par le concepteur de base de données, alors que les ASSERTIONs permettent au concepteur de base de données de se concentrer exclusivement sur le" quoi " (déclaratif).)

Deuxième cas (bien que je ne sois pas tout à fait sûr de cela - alors prenez avec un grain de sel): juste votre règle moyenne RI. Bien sûr, vous êtes utilisé pour spécifier cela en utilisant une clause de références. Mais imaginez qu'une clause de références n'était pas disponible. Une règle comme " chaque commande doit être passée par un client connu" est-ce vraiment juste cela, une règle, donc: une seule ASSERTION. Cependant, nous savons tous qu'une telle règle peut toujours être violée de deux façons : insérer une commande (dans cet exemple) et supprimer un client. Maintenant, conformément à l'exemple Homme/Femme précédent, si nous voulions implémenter cette règle/ASSERTION unique en utilisant des contraintes de vérification, nous devrions écrire une contrainte de vérification qui vérifie l'existence du client lors des insertions dans L'ordre, mais quelle contrainte de vérification pourrions-nous écrire qui fait tout ce qui est nécessaire sur suppression du client ? Ils ne sont tout simplement pas conçus à cette fin, pour autant que je sache. Il y a votre deuxième différence : les contraintes de vérification sont liées exclusivement aux insertions, les ASSERTIONS peuvent définir des règles qui seront également vérifiées lors des suppressions.

Troisième cas: Imaginez une table COMPOS (componentID:... pourcentage: entier), et une règle selon laquelle "la somme de tous les pourcentages doit en tout temps être égale à 100". C'est une règle unique, et une ASSERTION est capable de précisant que. Mais essayez d'imaginer comment vous appliqueriez une telle règle avec des contraintes de contrôle ... Si vous avez une table valide avec, disons, trois lignes non nulles ajoutant jusqu'à une centaine, comment appliqueriez-vous toute modification à cette table qui pourrait survivre à votre contrainte de vérification ? Vous ne pouvez pas supprimer ou mettre à jour (diminuer) une ligne sans avoir à ajouter d'autres lignes de remplacement, ou mettre à jour les lignes restantes, qui totalisent le même pourcentage. De même pour insérer ou mettre à jour (augmenter). Vous auriez besoin de report la vérification des contraintes à tout le moins, et alors qu'allez-vous vérifier ? Il y a votre troisième différence : les contraintes de vérification sont ciblées sur des lignes individuelles, tandis que les ASSERTIONs peuvent également définir / exprimer des règles qui "couvrent" plusieurs lignes (c'est-à-dire des règles sur les agrégations de lignes).

Les Assertions ne modifient pas les données, elles vérifient seulement certaines conditions

Les déclencheurs sont plus puissants car ils peuvent vérifier les conditions et également modifier les données

--------------------------------------------------------------------------------

Les Assertions ne sont pas liées à des tables spécifiques dans la base de données et ne sont pas liées à des événements spécifiques

Les déclencheurs sont liés à des tables spécifiques et à des événements spécifiques

Une contrainte de base de données implique une condition qui doit être remplie lorsque la base de données est mise à jour. En SQL, si une condition de contrainte est évaluée à false, la mise à jour échoue, les données restent inchangées et le SGBD génère une erreur.

Les Deux CHECK et ASSERTION sont des contraintes de base de données définies par les standards SQL. Une distinction importante est qu'un CHECK est appliqué à une table de base spécifique, alors qu'un ASSERTION est appliqué à l'ensemble de la base de données. Considérons une contrainte qui limite le lignes combinées dans les tableaux T1 et T2 pour un total de 10 lignes, par exemple

CHECK (10 >= (
              SELECT COUNT(*)
                FROM (
                      SELECT *
                        FROM T1
                      UNION
                      SELECT * 
                        FROM T2
                     ) AS Tn
             ))

Supposons que les tables sont vides. Si cela était appliqué en tant que ASSERTION uniquement et qu'un utilisateur essayait d'insérer 11 lignes dans T1, la mise à jour échouerait. La même chose s'appliquerait si la contrainte était appliquée en tant que contrainte CHECK à T1 uniquement. Cependant, si la contrainte était appliquée en tant que contrainte CHECK à T2, seule la contrainte réussirait car une instruction ciblant T1 ne provoque pas les contraintes appliqué à T1 à tester.

Un ASSERTION et un CHECK peuvent être différés (s'ils sont déclarés DEFERRABLE), ce qui permet aux données de violer temporairement la condition de contrainte, mais uniquement dans une transaction.

ASSERTION et les contraintes CHECK impliquant des sous-requêtes sont des fonctionnalités en dehors du SQL standard de base et aucun des principaux produits SQL ne prend en charge ces fonctionnalités. MS Access (pas exactement un produit de résistance industrielle) prend en charge les contraintes CHECK impliquant des sous-requêtes mais non déferrables contraintes plus les tests de contraintes sont toujours effectués ligne par ligne, les conséquences pratiques étant que la fonctionnalité est très limitée.

En commun avec les contraintes CHECK, un déclencheur est appliqué à une table spécifique. Par conséquent, un déclencheur peut être utilisé pour implémenter la même logique qu'une contrainte CHECK mais pas un ASSERTION. Un déclencheur est un code procédural et, contrairement aux contraintes, l'utilisateur doit prendre beaucoup plus de responsabilité pour des problèmes tels que les performances et la gestion des erreurs. La plupart des les produits SQL commerciaux prennent en charge les déclencheurs (MS Access mentionné ci-dessus ne le fait pas).

L'expression doit être true pour que trigger se déclenche, mais check sera évalué partout où l'expression est fausse.