Les 12 règles d’Edgar Frank Codd

Les 12 règles de Codd ont été créées afin de standardiser ce qui est attendu d’un système de gestion de base de données pour qu’il puisse être considéré comme relationnel, c’est à dire que les 12 règles synthétisent les normes d’une base de données.

 

Liste des 12 règles de Codd

  1. L’Unicité
    Toute l’information présente au sein d’une base de données est représentée de la même façon.
  2. La Garantie d’accès
    On doit pouvoir accéder aux données sans ambiguïté. Cette règle est en fait un ajustement de la condition pour les clefs primaires. Elle met en avant le fait que toutes les valeurs scalaires individuelles dans la base de données doivent être accessibles en indiquant le nom de la table, de la colonne et la valeur primaire de la rangé.
  3. Traitement des valeurs nulles
    Le SGBD doit donner la possibilité à chaque champ de demeurer nul. Spécifiquement, il doit représenter l’information manquante et inapplicable de façon systématique et distinctement des valeurs régulières et ce indépendamment du type de données.
  4. Catalogue lui-même relationnel
    Le SGBD est obligé de supporter un catalogue dont les utilisateurs ont l’accès via leur langage d’interrogation régulier. Ils doivent pouvoir accéder à la structure de la base de données en se servant du même langage d’interrogation dont ils se servent pour accéder aux données.
  5. Sous-langage de données
    Le système est obligé d’avoir un langage relationnel qui a une syntaxe linéaire et utilisable dans des programmes d’application et de façon interactive. De plus, il doit supporter des manipulations de données, des contraintes de sécurité et d’intégrité, des opérations de gestion de transactions et des opérations de définition d’informations.
  6. Mise à jour des vues
    Toutes les vues pouvant éventuellement être mises à jour doivent être en mesure de pouvoir l’être par le système.
  7. Insertion, mise à jour, et effacement de haut niveau
    Le système est obligé d’être en capacité de supporter les opérations par lot de suppression, de mise à jour et d’insertion. Cette règle met en avant le fait que la mise à jour, l’insertion, et les opérations d’effacement devraient être supportées pour pour un tuple unique issu d’une table unique mais également pour des lots de tuples issues de plusieurs tables.
  8. Indépendance physique
    Les modifications physiques ne rendent pas obligé le changement d’une application basée sur les structures.
  9. Indépendance logique
    Au niveau logique, les changements ne doivent pas nécessiter un changement au sein de l’application fondée sur les structures.
  10. Indépendance d’intégrité
    Des contraintes d’intégrité doivent être indiquées indépendamment des programmes d’application puis stockées à l’intérieure du catalogue. Il est nécessaire d’avoir la possibilité de modifier de telles contraintes au fur et à mesure en n’affectant pas les applications existantes sans raisons.
  11. Indépendance de distribution
    L’invisibilité aux utilisateurs de la base de données de la distribution des parties de la base de données à de diverses localisations est nécessaire. Les applications déjà existantes ne doivent pas cesser de fonctionner normalement lorsqu’une version attribuée par le SGBD est présenté, mais également lorsque des données déjà existantes sont redistribuées au sein su système.
  12. Règle de non-subversion
    Dans les cas où le système fournis une interface de mauvaise qualité, cette ci ne doit en aucun cas donner la possibilité de contourner le système.

 

Soyez le premier à commenter

Laisser un commentaire