Discussion :

[SpaceX]

Bonjour,

J'ai une table Etudiant contenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
id_Etudiant (PK)
numeroEtudiant
numeroSecu
nomEtudiant
prenomEtudiant

L'énoncé dit que le numéro étudiant et de sécurité sociale sont uniques.

La 3ème forme normale est respecté si :
Tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.

J'imagine que numeroSecu et numeroEtudiant se dépendent entre eux car je peux à partir de numeroSecu en déduire numeroEtudiant .

Il faut que je créé une table comme cela?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Table Etudiant
id_Etudiant (PK)
nom_Etudiant (FK)
prenomEtudiant (FK)
numeroEtudiant (FK)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Table Etudiant
id_Etudiant(PK)
numeroSecu (FK)

Merci d'avance

[SQLpro]

Bonjour,

J'ai une table Etudiant contenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
id_Etudiant (PK)
numeroEtudiant
numeroSecu
nomEtudiant
prenomEtudiant

L'énoncé dit que le numéro étudiant et de sécurité sociale sont uniques.

La 3ème forme normale est respecté si :
Tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.

J'imagine que numeroSecu et numeroEtudiant se dépendent entre eux car je peux à partir de numeroSecu en déduire numeroEtudiant .

Non, car toute personne née ou travaillant en France est dotée d'un numero de sécu, mais n'est pas forcément étudiante...

A +

[SQLpro]

De plus votre numéro de sécurité sociale viole la première forme normale....

Devinez pourquoi !

https://fr.wikipedia.org/wiki/Forme_..._forme_normale

A +

[aieeeuuuuu]

Bonjour,

La 3ème forme normale est respecté si :
Tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.

Attention, dans cette définition, il faut considérer les clefs candidates, et non uniquement la clef primaire.
Dans votre cas, le numéro de sécurité sociale est une clef candidate, tout comme le numéro d'étudiant (qui devront par ailleurs tous deux faire l'objet d'une déclaration de contrainte d'unicité)
Donc, non, votre table ne viole pas la troisième forme normale dans son état initial.

De plus votre numéro de sécurité sociale viole la première forme normale....

ça se discute, la notion d'atomicité étant a considérer en fonction de ce que l'on modélise.
A mon sens, il n'y a pas non plus viol de la 1NF, puisque les différents informations en fait contenues dans le numéro de sécu n'ont a priori aucune signification/utilité dans le système en question, et que l'on peut donc considérer, dans ce cas, que le numéro de sécu est bien une valeur atomique.

[escartefigue]

Ca se discute, la notion d'atomicité étant a considérer en fonction de ce que l'on modélise.
A mon sens, il n'y a pas non plus viol de la 1NF, puisque les différents informations en fait contenues dans le numéro de sécu n'ont a priori aucune signification/utilité dans le système en question, et que l'on peut donc considérer, dans ce cas, que le numéro de sécu est bien une valeur atomique.

Tout à fait, sinon on pourrait appliquer la même logique avec les dates, les numéros de téléphones français (les deux premiers chiffres étant l'indicatif de région) etc...
Si le numéro de sécu est vu comme un tout, il est atomique

Attention aussi, il existe des S.I. dans lesquels le n° de sécu n'était pas unique. Typiquement le cas des mineurs rattachés au n° de sécu de l'un des parents. Autre cas : les n° de sécu non certifiés (cf. processus de certification des NNI par la PRC dans le monde de la retraite)

[fsmrel]

Je suis d’accord avec aieeeuuuuu et escartefigue.

Pour développer un peu, je rappelle la définition de la première forme normale (1NF), donnée par Chris Date qui est la référence en ce qui concerne la théorie de la normalisation (cf. Database Design and Relational Theory Normal Forms and All That Jazz :

Soit la relation r ayant les attributs A1, ..., An, respectivement de type T1, ..., Tn ; r est en première forme normale si et seulement si pour chaque tuple t appartenant à r, la valeur dans t de l’attribut Ai est du typeTi (i = 1, ..., n).

Par relation, on entend valeur prise par une variable relationnelle (relvar).
Voyez aussi ici.

Ainsi, par définition, toute relvar est en 1NF ! En d’autres termes, respecter la 1NF vaut dire que chaque tuple de la relation contient exactement une valeur, du type approprié, pour chaque attribut. Il n’y a pas de limitation arbitraire sur ce que peut être le type en question : les RVA en sont une illustration. Pour mémoire, les termes 1NF et normalisé sont interchangeables.

A propos de l’atomicité

Depuis une vingtaine d’années, la notion d’atomicité a été évacuée de la théorie relationnelle, car inappropriée : une relvar irréductible (disons en 6NF) est toujours atomique, alors qu’une relvar peut être atomique sans être irréductible (sans même être disons en BCNF).

Pour aller dans le sens de aieeeuuuuu et escartefigue, on est en droit de définir le type numeroSecu, encapsulant des notions ayant un sens pour nous : sexe, année de naissance, etc., mais légalement et légitimement considérer les numéros de sécu comme atomiques, car du type numeroSecu (cf. la définition donnée ci-dessus de la 1NF).

Sinon, pour faire un peu de pharisianisme, seuls les quarks sont atomiques (du moins pour le moment).

Voyez aussi ici.

Il est clair que la référence Wikipedia fournie par SQLpro est complètement à côté de la plaque, quand on y lit :

Une autre définition serait : un attribut est dit « atomique » si aucune subdivision de l‘information initiale n’apporte une information supplémentaire ou complémentaire.

=> Dans le contexte du modèle relationnel de données : poubelle.

La 3ème forme normale est respecté si :
Tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.

J'imagine que numeroSecu et numeroEtudiant se dépendent entre eux car je peux à partir de numeroSecu en déduire numeroEtudiant.

A la réserve près émise par escartefigue, les étudiants n’étant pas encore retraités et n’ayant pas leurs parents inscrits dans votre école, dans votre contexte, {numeroSecu} est clé candidate, tout comme {id_Etudiant} et {numeroEtudiant}. Les attributs n'appartenant pas à une clé sont nomEtudiant et prenomEtudiant et ils ne dépendent ni l’un de l’autre, mais seulement des clés candidates : la relvar {id_Etudiant, numeroEtudiant, numeroSecu, nomEtudiant, prenomEtudiant} respecte la troisième forme normale.

Cela dit votre définition de la troisième forme normale est trop vague, car si une clé comporte plus d’un attribut, disons les attributs A1, A2, A3, doit-on considérer {A1} comme clé ? (car appartenant à celle-ci), ou comme non clé ? (car à lui seul A1 ne constitue pas une clé)...

Pour des définitions correctes, voyez plutôt ici et là.

[fsmrel]

En fouillant dans mes archives, j’ai exhumé cette discussion où est évoquée l’atomicité :

Il est clair que la référence Wikipedia fournie par SQLpro est complètement à côté de la plaque, quand on y lit :

Une autre définition serait : un attribut est dit « atomique » si aucune subdivision de l‘information initiale n’apporte une information supplémentaire ou complémentaire.

=> Dans le contexte du modèle relationnel de données : poubelle.

Je cite encore Wikipédia :

Une relation (ayant par définition un identifiant) est en première forme normale si tous les attributs possèdent tous une valeur sémantiquement atomique.

Par contraste je cite C. J. Date dans Database Design and Relational Theory (Second Edition, Apress, 2020), à la page 70 :

« The one thing that “everybody knows” about relations in the relational model–namely, that attribute values within such relations are supposed to be atomic (right?). So what exactly does atomic mean in this context? Well, in his famous paper of 1970, Codd merely said it meant “nondecomposable.” And in later writings he went on to say that nondecomposable in turn meant “nondecomposable by the DBMS.” »  

L’erreur commise par Wikipédia est donc de confondre sémantique et théorie relationnelle. Il n’est pas le seul ! d’où la précision apportée par Codd : « by the DBMS ».

[fsmrel]

Bonsoir,

Toujours à propos de Wikipédia et de la normalisation :

4FN - quatrième forme normale
Pour être en 4FN, il faut respecter la 3FN (et non nécessairement la FNBC).

Encore un qui a tout compris ... de travers. 

Quand il affirme qu’il n’est pas nécessaire de respecter la BCNF pour être en 4NF, il est facile de prouver qu’il dit n’importe quoi.

A cet effet, je commence par rappeler les définitions de la BCNF et de la 4NF (cf. C. J. Date dans Database Design and Relational Theory (Second Edition, Apress, 2020), pages 105 et 248), où est en jeu l’omniprésente relvar (variable relationnelle) R :

La relvar R est en BCNF si et seulement si pour chaque DF non triviale X–>Y de R, X est une surclé de R.

La relvar R est en 4NF si et seulement si pour chaque DMV non triviale X–>–>Y de R, X est une surclé de R.

Supposons maintenant que la relvar R soit en 4NF mais pas en BCNF.
Si R n’est pas en BCNF c’est qu’il existe une DF non triviale X–>Y telle que X n’est pas clé.
Mais en vertu de la règle de réplication, la DF X–>Y est aussi une DMV (dépendance multivaluée) : X–>–>Y, auquel cas pour que R soit en 4NF, X doit être une clé, ce qui en l’occurrence n’est pas le cas, d’où contradiction.

En fait, le wikipediateur a manifestement confondu 3FN et (3,3)FN.

Pour tout savoir sur la (3,3)FN, il faut se reporter à l’article pondu en 1978 par John Miles Smith :

A normal form for abstract syntax.

Je cite une fois de plus C. J. Date dans Database Design and Relational Theory (Second Edition, Apress, 2020), à la page 312 cette fois-ci :

« In a paper by Smith, which discusses a normal form called (3,3)NF, Smith shows, first, that (3,3)NF implies BCNF; second, that a (3,3)NF relvar need not to be in 4NF, nor need a 4NF relvar be in (3,3)NF. As suggested above, therefore reduction to (3,3)NF is orthogonal to reduction to 4NF and 5NF). »

Pas de problème avec la (3,3)NF, tout va bien, mais de grâce, ne pas confondre avec la 3NF...

Bonsoir chez vous !