Le thème de la normalisation est traité ici dans le cadre du Modèle Relationnel de Données, inventé par Ted Codd et qui continue à s'enrichir et évoluer harmonieusement sous la houlette de ses continuateurs, citons Chris Date, compagnon de route de toujours de Ted, Hugh Darwen, et pour certains points sensibles, avec la participation de David McGoveran ou Nikos Lorentzos. Le Modèle Relationnel a de nombreux points en commun avec le Modèle SQL qui s'en est inspiré, mais il y a des différences très marquées tant sur le fond que sur la forme. Concernant la structure des données ces différences seront signalées au fur et à mesure quand le besoin s'en fait sentir.

On trouvera en annexe (paragraphe A) la définition des concepts structurels fondamentaux propres au Modèle Relationnel et quelques notes concernant le langage Tutorial D, prototype relationnellement complet (cf. [Date 2006]). On y trouvera aussi (paragraphe B) quelques notes relatives à l'algèbre relationnelle, permettant de comprendre par exemple comment les opérations relationnelles sont exprimées en Tutorial D, avec au besoin, la traduction en SQL de ces opérations.

S'il n'est évidemment pas nécessaire que le lecteur sache tout du Modèle Relationnel, il est néanmoins préférable qu'il ait un minimum de connaissances en SQL :

Savoir ce qu'est une table (aspect structurel), comment l'exploiter (utilisation des opérateurs relationnels figurant plus ou moins explicitement dans le bloc SELECT-FROM-WHERE), et comment garantir un strict minimum d'intégrité des données (clés primaires et étrangères).

Même s'il ne connaît que très peu SQL, celui qui construit des diagrammes au niveau conceptuel (MCD selon l'approche Merise ou Entité/Relation, IEF, voire diagramme de classes), est très concerné, puisque les tables qui constitueront la base de données seront le résultat de la dérivation de ce qu'il aura construit.

La normalisation permettra de s'assurer que les fondations de la base de données sont saines et robustes.

Tout en étant incontournable, la normalisation peut être considérée comme un sujet indépendant (orthogonal comme dirait Date), au point que Codd — qui connaît mieux que quiconque la chose — n'en parle dans son ouvrage de référence [Codd 1990] que pour rappeler l'intérêt qu'il y a à normaliser afin d'éviter les anomalies de mise à jour (deux pages et c'est tout). Quoi qu'il en soit, j'ai constaté que nombreux sont les « spécialistes » qui traitent du sujet de façon imparfaite, n'ayant vraisemblablement pas eu l'occasion — sinon la curiosité — de mesurer les conséquences funestes de leur légèreté, au préjudice de la Production informatique.

Cela dit, l'objet de l'article est quelque part de faire en sorte que le lecteur intéressé dispose de définitions exactes des formes normales, pour mieux bétonner sa base de données. J'essaie en l'occurrence de rester lisible car il est facile d'écrire de façon très hermétique sur le sujet, mais là n'est certainement pas le but de la manoeuvre. En tout cas, la référence est pour longtemps encore Chris Date, il faut lire [Date 2012].

Le thème de l'« optimisation » des bases de données est aussi abordé, mais on sort alors carrément du cadre de la théorie relationnelle, ce qui fait que tous les administrateurs de bases de données (DBA) ne seront pas forcément convaincus par mon approche — basée quand même sur quarante années d'exercice du métier, dans les secteurs d'activité les plus variés, avec tous les types de SGBD, dans le contexte des très grandes bases de données et le plus souvent au fond de la soute — (cf. le paragraphe F en annexe, dont la rédaction fut provoquée par une réflexion sur ce thème de l'optimisation, en réaction à la confusion faite avec celui de la dénormalisation, confusion entretenue (sans doute bien involontairement) par certains auteurs et « experts » autoproclamés (se reporter au paragraphe 1.7, notamment à ce qui a trait à l'identification relative)).

Périodiquement, on relève chez Developpez.com (Mâtin, quel site !) des questions posées par des étudiants, questions ayant trait à la normalisation, mais sur des aspects plutôt théoriques et qui ne concernent que modérément les praticiens. A leur intention, quelques réponses sont fournies en annexe (cf. paragraphes E.6 et E.7).

Lorsqu'il a inventé le Modèle Relationnel de Données en 1969, l'objet de l'étude de Codd était celui des relations. En 1974-1976, en créant SEQUEL (ou SQL si vous préférez), Chamberlin a préféré remplacer « relation » par « table » (mot sans doute plus parlant). Mais il y a toujours intérêt à rechercher le mot le plus approprié pour un concept, par souci justement de précision. Ainsi, en 1994, Date et Darwen (D & D, que j'appelle encore affectueusement les Dupondt) en sont arrivés à définir le concept de variable relationnelle (relation variable, en abrégé relvar). Ils ont estimé — à l'instar des autres théoriciens du relationnel, du reste — qu'une relation étant une valeur, elle ne se situe ni dans le temps ni dans l'espace (Platon aurait approuvé), contrairement à la variable relationnelle, à laquelle on affecte, par le biais d'une requête (disons au sein d'un programme, d'une procédure ou de ce que vous voulez), des valeurs différentes (des relations) au fil du temps. Ainsi en va-t-il dans un programme, quand à la variable x on affecte les valeurs 1 ou 2, etc. qui, elles non plus, ne se situent ni dans le temps ni dans l'espace et dont nous ne représentons que des images.

Au contraire, en SQL on ne dispose que d'un concept unique, celui de table. Mais, quand une table est-elle une variable ? Une valeur ? L'ambiguïté peut devenir fort gênante.

J'aurais pu faire l'économie du terme relvar et me contenter de l'expression schéma de relation (comme l'on pratiquait du reste dans les années soixante-dix, quatre-vingts), mais un tel schéma (en-tête selon le Modèle Relationnel de Données) est en fait un des composants de la relvar, ça n'est qu'un ensemble d'attributs (au sens de la théorie des ensembles). Bref, quand on y a pris goût, on ne peut plus se passer de la relvar...

On pourrait encore poser la question : Mais pourquoi traiter de la normalisation en faisant appel au vocabulaire de Tutorial D (qui est celui du Modèle Relationnel) plutôt qu'à celui de SQL ? Je répondrai encore que c'est au nom de la précision dans la définition des concepts mis en jeu.

Par exemple, on pourrait énoncer ainsi la forme normale de Boyce-Codd (BCNF) :

Une relvar R est en forme normale de Boyce-Codd (BCNF) si et seulement si les seules dépendances fonctionnelles non triviales qu'elle doit vérifier sont de la forme X ➔ Y, où X représente une surclé et Y un sous-ensemble d'attributs de l'en-tête de R.

C'est du béton, même si à ce stade vous ne pouvez peut-être pas encore en juger. A la sauce SQL, on pourrait reformuler cela à peu près ainsi :

Un schéma de table T* est en forme normale de Boyce-Codd (BCNF) si et seulement si les seules dépendances fonctionnelles non triviales auxquelles il satisfait sont de la forme X ➔ Y, où X contient une clé candidate et Y représente un sous-ensemble de colonnes de T*.

Je ne suis pas sûr qu'il n'y aurait pas de grincheux pour dire que ça n'est pas une très bonne formulation, que cela manque de rigueur (par exemple, quel sens exact prend le verbe contenir dans l'expression « contient une clé candidate » ?)

Quoi qu'il en soit, je trouve plus difficile de dire les choses en termes SQL, aussi Tutorial D mérite-t-il qu'on s'y intéresse, même s'il ne s'agit pas ici de l'étudier pour lui-même.

Veuillez prendre note que je ne fournis pas toujours le texte original de certaines citations mais seulement leur traduction. On n'est jamais à l'abri d'une bévue, mais je pense en avoir respecté l'esprit.