Envoyé par
haroun70
Une relation (Table) est en NF1 si tous ses attributs sont atomiques (Décomposable).
On a l’impression que selon vous les termes « atomique » et « décomposable » sont synonymes : il s’agit sans doute d’un lapsus...
Peu importe. S’intéresser à l’atomicité des attributs est louable en soi, mais ne concerne pas précisément la première forme normale, inventée en 1970 par Ted Codd, et dont l’objet était alors de contraindre les relations à être conformes à la logique du 1er ordre (voyez son article fondateur, A Relational Model of Data for Large Shared Data Banks). La définition que vous donnez est celle qui est recopiée consciencieusement par tous les étudiants depuis près de 40 ans, mais elle est trop vague, discutable (et donc discutaillée !) Elle est obsolète et a été ainsi reformulée par C. J. Date (reportez-vous par exemple à Database Design and Relational Theory - Normal Forms and All That Jazz) :
Soit une relation r d’attributs A1, ..., An, de types respectifs T1, ..., Tn. r est en première forme normale (1NF) si et seulement si, pour chaque tuple t appartenant à r, la valeur de Ai dans t est du type Ti (i = 1, ..., n).
Ainsi, chaque relation est en fait en 1NF ⁽¹⁾.
Peu importe le type de l’attribut Ai, qu’il s’agisse du type ENTIER, CARACTERE, DATE, TIMESTAMP, POLYGONE, voire RELATION (voyez ici), exemple :
1
2
3
4
5
6
7
8
| VAR F_EXT BASE RELATION
{
Four_No INTEGER,
Four_Nom CHAR,
Statut INTEGER,
Ville CHAR,
Piece_Qte RELATION { Piece_No INTEGER, Quantite INTEGER }
} KEY {Four_No} ; |
La variable relationnelle F_EXT respecte de facto la 1NF (et cela vaut pour chaque valeur prise par cette variable, c'est-à-dire chaque relation en l'occurrence).
Pour reprendre le cas de l’attribut DateduVol, supposons qu'il soit du type DATE : quel besoin de le décomposer ? En effet, pour accéder à l’année, au mois et au jour, il suffit d’utiliser les fonctions ad-hoc dont ce type est doté (et cela vaut pour tout type). Qui plus est, si on décomposait DateduVol en DateduVolAnnee, DateduVolMois, DateduVolJour, il faudrait programmer soi-même les contraintes garantissant que les résultats produits par la combinaison de ces attributs seront bien des dates, surcharge de travail pénible, mais rendue obligatoire suite à une atomisation malvenue (et étrangère à la 1NF...) 
___________
⁽¹⁾ Pour les tables SQL, ça n’est pas le cas, car elles ne sont pas assujetties à respecter les propriétés des relations :
— Contrairement aux relations, les tables peuvent contenir des lignes en double ;
— Contrairement aux relations, les tables peuvent contenir le marqueur NULL ;
— Au nom du principe de fermeture, le résultat d’une opération algébrique portant sur une relation est une relation. De même, le résultat d’une opération algébrique portant sur une table est une table.
Exemple : Si A1 est le nom d’une colonne de la table T1, le résultat de :
SELECT A1, A1 FROM T1
est une table d’en-tête (A1, A1), mais ça n’est pas une relation, parce que les doublons sont interdits dans l’en-tête d’une relation (la fermeture algébrique ne vaudrait plus) ;
— Etc.
Définition de la première forme normale (FN1)
Répondre avec citation
.
, 
ni 
, ne peuvent vous aider, mais nous oui, pensez à un pti 
et au 
! 
, on écrit xRy, et on dit que x et y sont en relation par R.
Partager