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
Partager