fsmrel

_______________________________________

Je rappelle ce que sont les 12 règles de Codd (datées de 1985, cf. An Evaluation Scheme for Database Management Systems that are claimed to be Relational), énoncées par le père du modèle relationnel de données, extrêmement fâché quand Cullinet (IDMS/R) et ADR (Datacom/DB) prétendirent que leur SGBD pré-relationnel était relationnel, marketing oblige, alors que le vent était en train de tourner.

Ces règles datant de plus de 30 ans peuvent paraître aujourd’hui incomplètes, mais elles suffirent largement pour fustiger les coupables (vexé comme un dindon, John Cullinane, fondateur de Cullinet (1968-1989) déclara que l’article de Codd était « about the silliest » qu’il a pu lire), et elles furent la source des 333 fonctionnalités décrites cinq ans plus tard dans The Relational Model for Database Management, Version 2.

Je cite Codd :

« The table below indicates fidelity to the twelve rules by DB2, IDMS/R, and Datacom/DB, examples chosen for their wide differences :

Rule
    DB2
    IDMS/R
    Datacom/DB

1
information rule
    yes
      no
        no

2
guaranteed access rule
    par.
      no
        no

3
systematic treatment of nulls
    par.
      no
        no

4
active catalog based on RM
    yes
      no
        no

5
comprehensive data sublanguage
    yes
      no
        no

6
view updating rule
    no
      no
        no

7
high-level insert, update, delete
    yes
      no
        no

8
physical data independence
    yes
      par.
        par.

9
logical data independence
    par.
      no
        no

10
integrity independence
    no
      no
        no

11
distribution independence
    yes
      no
        no

12
non-subversion rule
    yes
      no
        no


Score (1 for yes, 0 otherwise)
     7
      0
        0

These scores are counts of compliance with the twelve rules (one for "yes" and 0 for either "partial" or "no"). Actually, the information rule is so fundamental to' the relational approach that a system's compliance with this rule should receive a much higher score than one (say 10 at least). However, I shall avoid assigning different points for different features, just as I avoided a fractional score for partial support of a feature - it is too easy to be subjective in these matters.

DB2 scores quite well here, when compared with its competitors. However, it is not an outstanding score considering that, well prior to release, the developers were advised on several occasions of the deficiencies. Very few other DBMS score higher on the twelve rules, although some others score equally well (for example, INGRES and ORACLE). »

Clairement, Codd reproche à Chamberlin de ne pas avoir été assez fidèle au modèle relationnel de données, et que le prototype System R (donc ses enfants légitimes, SQL/DS et eDB2) aurait pu mieux faire).

Je rappelle de façon succincte la signification des règles :


1. Information rule : dans une base de données relationnelle, toute l’information est représentée au niveau logique de façon unique, à savoir par des valeurs dans des tables (ceci vaut bien sûr pour le catalogue relationnel, la métabase). Il s’agissait pour Codd de disqualifier les pointeurs régnant en maîtres dans les systèmes non relationnels, et voilà qu’ils font leur réapparition avec le type REF de la norme SQL, mais on ne voit guère de fonctionnalité utile que cela apporte, qui ne puisse être mise en œuvre autrement, et plus efficacement qui plus est).


2. Guaranteed access rule : Chaque donnée élémentaire (valeur) doit être accessible au moyen du nom de la table, de la valeur de la clé primaire, et du nom de la colonne qui vont bien. A noter qu’en 1985, DB2 ne permettait pas de déclarer de clé primaire (a fortiori alternative), on se débrouillait avec des index de type UNIQUE : DB2 ne respectait donc pas la règle (ses concurrents non plus, bien entendu).


3. Systematic treatment of nulls : Que l’on puisse traiter de l’absence de l’information, soit, mais pour ma part, suite à C.J. Date, H. Darwen et D. McGoveran, j’inverserais la proposition de Codd : un bon point seulement si le bonhomme Null est mis hors la loi...


4. Active catalog based on RM : un trait de génie de la part de Codd. Pour celui qui a eu à utiliser IDMS et compagnie, et leur catalogue non dynamique (donc à gérer à l’aide de commandes spéciales, en mode différé), quel progrès ! Une révolution !


5. Comprehensive data sublanguage : Codd demande que soient unifiées dans un langage unique et complet (SQL par exemple...) les commandes permettant de déclarer les données (tables), vues, de manipuler ces objets (SELECT, INSERT, UPDATE, DELETE), déclarer les contraintes d’intégrité (clé primaires et étrangères, assertions), les autorisations (GRANT, REVOKE), les frontières des transactions (BEGIN, COMMIT, ROLLBACK). On peut se poser la question de la nécessité d’introduire des concept qui n’ont rien à voir avec le modèle relationnel de données (autorisations, transactions), mais l’intention de Codd était d’éviter la foultitude des langages et dédiés et donc d’exécuter ces instructions sans devoir interrompre les tâches en cours.


6 View updating rule : Si une vue est théoriquement mise à jour mettable, alors le SGBD doit permettre qu’on puisse effectivement la mette à jour. Depuis 1985, le sujet a été abondamment traité par les chercheurs, et aujourd’hui l’ouvrage de référence est celui de C.J. Date (2013) : View Updating and Relational Theory - Solving the View Update Problem (les SGBD SQL ont encore du chemin à parcourir pour être à niveau...)


7. High-level insert, update, delete : Qu’une table de base ou dérivée puisse faire l’objet d’une variable en tant que telle, vaut non seulement en consultation, mais aussi en mise à jour. A mon sens, si les vues sont concernées, il faudrait déjà que la règle 5 soit respectée. En fait, Codd entend surtout que seul le système s’occupe du COMMENT, donc des accès aux enregistrements, pour notre part nous n’avons à manipuler que des tables. Ceci est un prérequis pour l’optimisation sous le capot, l’efficacité du système en général.


8. Physical data independence : Le SGBD doit garantir une totale séparation entre les aspects logiques, sémantiques d’une part, et d’autre part les aspects physiques, par conséquent la résolution des problèmes de performance (voir l’exemple des lots de remises de chèques). En 1985, DB2 ne respectait pas entièrement la règle : en l’absence de clé primaire, on garantissait l’unicité au moyen d’un index de type UNIQUE, et sa suppression pouvait avoir des conséquences dommageables. Codd lui a pourtant accordé un point. En tout cas, dès la V2 de DB2, il n’était plus possible de supprimer un tel index s’il était associé à une clé.


9. Logical data independence : Un changement de structure des données effectué sans qu’il y ait perte de données (lossless) doit être possible, de façon transparente pour les applications.

Par exemple, si on partage une table T horizontalement ou verticalement en deux tables T1 et T2, sans perte de données, T doit pouvoir être requalifiée en une vue de jointure ou d’union de T1 et T2. La règle 9 implique manifestement la règle 6. Se reporter à nouveau à l’ouvrage de Date traitant des vues.

10. Integrity independence : En plus de l’intégrité d’entité (clés primaires) et de référence (clés étrangères), des contraintes supplémentaires (par exemple exclusion, inclusion, respect des règles de gestion des données éliminées suite à la décomposition d’une table non BCNF, etc.) doivent pouvoir être déclarées (donc figurer dans le catalogue relationnel) et garanties par le SGBD (et certainement pas dans les programmes, leur objet est de produire). Disons que les triggers SQL servent à cela, même si en théorie on devrait pouvoir utiliser l’instruction CREATE ASSERTION, faite pour cela (et présente en 1976, dans le prototype SYSTEM R d’IBM).


11. distribution independence : Codd a donné un point à DB2 car les programmes SQL opérationnels avec SYSTEM R fonctionnaient aussi avec le prototype System R*. Par distribution, il s’agit bien sûr de celle des données et non pas des traitements.


12. non-subversion rule : On ne peut pas utiliser un langage de niveau inférieur qui permettrait de modifier les données à l’insu du système relationnel. En fait, avec un système non relationnel, sur lequel on a plaqué une couche relationnelle (système born-again comme disait Codd), rien de plus simple que de violer la règle (avec IDMS/R par exemple...)


Aujourd’hui, DB2 serait noté 10/12, en prenant un point quant aux règles 2, 3 10. Même chose pour les autres principaux SGBD SQL.

____________________________________________