Bonsoir,
Envoyé par
aieeeuuuuu
Bonjour,
Puisque visiblement vous en êtes à la conception, une première remarque : Votre table PROFIL ne respecte pas la première forme normale : la colonne age n'est pas constante dans le temps : dans un an vos données seront incorrectes ! stockez plutôt une date de naissance, vous pourrez facilement en déduire l'age.
Le conseil que vous donnez de préférer une colonne de type Date plutôt que de type Âge est le bon. En revanche, la première forme normale est parfaitement étrangère à cette histoire. Prenons la définition qui en est donnée par C.J. Date — la référence mondiale incontestée sur ce sujet — dans Database Design & Relational Theory, je cite et traduis :
Définition : Soit une
relation r ayant pour
attributs A1, ...,
An, respectivement de type
T1, ...,
Tn. Alors
r est en
première forme normale (1NF) si et seulement si pour tous les
tuples t appartenant à
r, la valeur de l’attribut
Ai dans
t est du type
Ti (
i = 1, ...,
n).
En d’autres termes, par définition chaque relation est en 1NF ! Pour dire les choses autrement, la 1NF signifie seulement que chaque tuple de la relation contient exactement une valeur du type approprié, pour chaque attribut.
Maintenant, une valeur de table SQL n’est pas forcément une relation et pour en être une et donc respecter la 1NF, elle doit respecter les contraintes suivantes :
1. Pas d’ordre de rangement quel qu’il soit pour les lignes de la table.
2. Pas d’ordre de rangement quel qu’il soit pour les colonnes de la table.
3. Pas de lignes en double.
4. Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du type applicable, et rien d’autre.
5. Toutes les colonnes sont régulières.
En particulier, le point 4 signifie qu’une colonne donnée ne peut pas contenir une liste ou un tableau de valeurs, c'est-à-dire un groupe répétitif de valeurs. De même, NULL n’est pas une valeur et provoque donc un viol de la 1NF.
Pour sa part, le point 5 signifie que chaque colonne a un nom et ce nom est unique dans l’en-tête de la table (sont évidemment visés les résultats des requêtes SQL, au nom du principe de fermeture : le mariage d’une table et d’une table est aussi une table et pas un machin ne ressemblant ni à son père ni à sa mère). Par ailleurs, une table ne peut pas héberger de colonne cachée, du genre Object ID, timestamp, etc.
Une dernière remarque :
Au niveau sémantique (MCD Merise, diagramme de classes UML), la structure présentée par Jejeman est caractéristique de la généralisation/spécialisation :
MCD Merise (avec Power AMC)
MLD dérivé
Avec MySQL Workbench (gratuit, pourvu que ça dure...)
Partager