Bonjour User,
Pardonnez-moi d’abuser de votre patience... Vous avez bien entendu tout à fait raison d’insister sur la normalisation des tables (ou plutôt des relations dans le cadre de la théorie relationnelle). Eu égard à la théorie, j’apporte quelques précisions à propos de la première forme normale (1NF), quitte à redonder avec ce que j’ai écrit dans mon précédent message (post #11).
Au vu de l’attribut Inscrits de la table T_Examen (cf. le post #1), vous êtes en phase avec E.F. Codd - père de la théorie relationnelle - pour qui cette table viole la 1NF. Je rappelle à ce propos la définition qu’il en donna en 1971 (cf. [Codd1971], page 31) :
A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets.
Codd précise ce qu’est une
relation (cf. [Codd1969], [Codd1970]) :
The term relation is used here in its accepted mathematical sense. Given sets S1,S2, ..., Sn (not necessarily distinct), R is a relation on these n sets if it is a set of n-tuples each of which has its first element from S1, its second element from S2, and so on. We shall refer to Sj as the jth domain of R.
Ainsi, une relation est bien un
ensemble, et Jeff Ullman ([Ullman1982] page 235) conclut que « relation » et « relation en 1NF » sont synonymes, donc autant faire l’économie du qualificatif « 1NF » : Ullman passe à juste titre un coup de rasoir d’Ockham. Il est en phase avec C. J. Date, qui dans son dictionnaire relationnel [Date2015] écrit ceci (je traduis) :
« Par définition, toutes les variables relationnelles sont en première forme normale, 1NF. Appliqués à une variable relationnelle les termes 1NF et normalisée veulent dire la même chose.
En passant, une variable relationnelle (
relvar) est une variable dont les valeurs sont des relations.
Quant à la table SQL (cf. [Date2019], page 69), elle doit respecter les contraintes suivantes pour mériter le label relation :
• elle ne doit pas contenir de lignes en double (ce qui est garanti par la déclaration d’une clé primaire, sinon la table n’est qu’un sac (bag)) ;
• les colonnes n’ont pas à être ordonnées (sous-entendu de gauche à droite) ;
• les lignes n’ont pas à être ordonnées (sous-entendu de haut en bas) ;
• les colonnes sont régulières, ce qui veut dire ceci :
(a) chaque colonne a un nom et deux colonnes de la table ne doivent pas avoir le même nom,
(b) une colonne ne peut être « cachée » :
=> Il ne peut y avoir d’identifiants autres que les clés déclarées, donc pas de
row id, d’
object id et
timestamps cachés,
(c) le bonhomme NULL n’a pas sa place dans le Relationland, les colonnes doivent donc être déclarées NOT NULL.
Il faut observer que Chris Date, collègue et compagnon de route dès l’origine de Codd, et qui est la référence en ce qui concerne la théorie de la normalisation, donne la définition suivante de la 1NF (cf. [Date2019], page 66), je traduis :
Soit la
relation r dont les attributs
A1, ...,
An, sont respectivement du type
T1, ...,
Tn. Alors
r est en première forme normale (1NF) si et seulement si, pour tous les tuples
t de
r, la valeur de l’attribut
Ai dans
t est du type
Ti (
i = 1, ...,
n).
Le type d’un attribut peut être le type
RELATION et cet attribut prend alors des valeurs qui sont des relations (
RVA).
Il va de soi que Date décrit les opérateurs permettant de replier/déplier les relations (Group/Ungroup), sans violer la 1NF. Mais il insiste sur le fait qu’au stade de la
modélisation, il faut éviter les
RVA (cf. [Date2019], page 67), ce qui veut dire que vous êtes toujours en phase avec lui quand vous recommandez d’« exploser façon puzzle »
la table T_Examen, même si selon les définitions de Date, cette table T_Examen est en 1NF, alors qu’elle ne l’est pas pour Codd...
Date dit bien que cela ne pose pas de problème que des résultats contiennent des RVA, mais,
bis repetita, qu’il faut toujours éviter celles-ci dans la modélisation des données, par exemple sous forme de
hiérarchies, comme cela se passe avec IMS, SGBD amiral d’IBM des années 70-80 (pour avoir beaucoup utilisé IMS, je plaide un peu coupable
, tout en ayant usé de tous les moyens techniques possibles pour respecter la symétrie, mais ceci est une autre histoire...) En effet, de par leur nature
asymétrique, les modèles hiérarchiques forcent à complexifier bien des requêtes a priori simples (cf. [Date2012] page 295). Pour l’anecdote, afin qu’en ces temps lointains IMS ne soit pas pénalisé, Date avait été contraint par IBM (chez qui il émargeait) d’attendre 1975 ans avant d’être autorisé à publier son fameux
An Introduction to Database Systems, écrit en 1972 (cf. [Haigh2007], pages 17-18).
---------------------------
[Codd1969]
Derivability, Redundancy and Consistency of Relations Stored in Large Data Banks.
[Codd1970]
A Relational Model for Large Shared Data Banks.
[Codd1971]
Further Normalization of the Data Base Relational Model.
[Date2012]
Date on Database Writings 2000-2006.
[Date2015]
The New Relational Database Dictionary.
[Date2019]
Database Design and Relational Theory Normal Forms and All That Jazz.
[Haigh2007]
Oral History of C. J. Date.
[Ullman1982]
Principles of Database Systems Second Edition (Computer Science Press. 1982
1 |
0 |
Bonjour,
:
)
Envoyé par User
si après ça ils n'ont pas compris 
Attention, une relation est bien ici une valeur de relvar.