Discussion :

[SpaceX]

Bonjour,

On dit qu'un système est en 1 NF lorsque :

• Toutes les données sont atomiques c'est à dire qu'une info initiale ne peut pas être divisé si elle n'apporte pas plus d'info
• Contiennent des valeurs non répétitives
• Constante dans le temps (ex :l'âge)

Jusque la j'ai pigé.

Ensuite, on dit qu'un système est en 2 NF lorsque :

• 1NF est validé
• Un attribut non clé dépend totalement (et pas partiellement ) de la clé ?

Je n'arrive pas à comprendre comment un attribut dépend de la clé ?

j'ai besoin d'un exemple pour comprendre ? pouvez vous m'aider svp ?

Merci.

[CinePhil]

Je vous renvoie à la bible de fsmrel : https://fsmrel.developpez.com/basesr...normalisation/
Notamment, pour ce qui concerne votre question, à la partie où est présentée la deuxième forme normale : https://fsmrel.developpez.com/basesr...n/?page=3#L3.4

Je pense d'ailleurs qu'il va vous répondre incessamment sous peu...

[SpaceX]

Bonjour,

Je fais l'effort de comprendre honnêtement, mais cela revient toujours à la même définition :

Une relation R est en deuxième forme normale si elle est en première forme normale et si chaque attribut n'appartenant à aucune clé candidate est en dépendance totale de chaque clé candidate de R.

ou

Une relation R est en deuxième forme normale si elle est en première forme normale et si chaque attribut n'appartenant pas à la clé primaire de R est en dépendance totale de celle-ci.

Si je prend un exemple :

Nom ; Prénom ; date de naissance avec Nom en clé primaire

prénom dépend de Nom
date de naissance dépend de Nom

On à une dépendance fonctionnel donc le système est en 2NF ?

[CinePhil]

Si Nom est en clé primaire, cela veut dire qu'il ne peut y avoir deux fois le même nom. Et donc, la personne nommée Dupont n'a bien qu'un seul prénom et qu'une seule date de naissance.
Nous sommes bien en 2NF, il me semble.

Ceci ne voulant pas dire que si je cherche le prénom Philippe, il n'y aura qu'un seul nom et une seule date de naissance puisque Philippe n'est pas clé de la relvar.

Ce qui est important, c'est la définition de chaque ligne de manière unique.

Si j'ai deux Philippe Leménager nés tous deux le 24/07/1963, je ne peux pas les distinguer autrement qu'en ajoutant un identifiant unique à chaque personne.

Si j'ai la relation suivante {id, nom, prénom, date_naissance}, ma clé primaire étant id (au niveau table de BDD, qui sera de type entier et auto-incrémentée, par exemple), Chaque personne ayant les trois mêmes informations sémantiques (nom, prénom, date_naissance) aura un identifiant unique dans toute la relation et je pourrai associer différemment chaque homonyme avec d'autres relations.


Mais revenons un instant sur votre message d'origine...

On dit qu'un système est en 1 NF lorsque :

Toutes les données sont atomiques c'est à dire qu'une info initiale ne peut pas être divisé si elle n'apporte pas plus d'info
Contiennent des valeurs non répétitives
Constante dans le temps (ex :l'âge)

Où avez-vous trouvé cette définition ?

Admettons pour l'atomicité mais :
- Que voulez-vous dire par "valeurs non répétitives" ?

- Que voulez-vous dire par "Constante dans le temps" ?

[SpaceX]

- Où avez-vous trouvé cette définition ?

La définition provient d'un cours en base de donnée que j'ai obtenu en cours du soir.

- Que voulez-vous dire par "valeurs non répétitives" ?

Une valeur qui sera déclarer qu'une seul fois en attribut et qu'on ne retrouva plus.

- Que voulez-vous dire par "Constante dans le temps" ?

Une variable qui varie dans le temps, comme par exemple l'âge d'une personne.

J'ai une série d'exercice à faire et j'aimerai trouver une méthode pour reconnaitre si un système est en 1NF, 2NF et 3 NF, mais c'est mal parti pour moi ...

[CinePhil]

La définition provient d'un cours en base de donnée que j'ai obtenu en cours du soir.

J'ai l'impression que cette définition est alors sujette à critiques...

- Que voulez-vous dire par "valeurs non répétitives" ?

Une valeur qui sera déclarer qu'une seul fois en attribut et qu'on ne retrouva plus.

Soit une relation (ou table) Personne (id, nom, prenom, date_naissance).
Chaque colonne porte bien une information atomique.
Il est pourtant probable qu'il y aura dans la table issue de cette relation plusieurs personnes portant le même nom et plusieurs personnes portant le même prénom.
Et cette relation ne serait pas en 1NF ?

- Que voulez-vous dire par "Constante dans le temps" ?

Une variable qui varie dans le temps, comme par exemple l'âge d'une personne.

Une valeur constante, c'est une valeur qui varie ?

Je vous renvoie à la bible de fsmrel de nouveau : https://fsmrel.developpez.com/basesr...sation/?page=2
À la fin du chapitre, il donne cette définition de la 1NF :

Si l'on reprend les définitions formelles données par Chris Date dans [Date 2004] au chapitre 6, « Relations », et reprises ici en annexe (paragraphe A), le bilan concernant les relations est le suivant :

Tout tuple contient exactement une valeur pour chacun de ses attributs.

Il s'ensuit que dans chaque relation, chaque tuple contient exactement une valeur pour chacun de ses attributs.

Une relation qui vérifie cette propriété est dite normalisée, ou de façon équivalente, est en première forme normale (1NF).

Il s'ensuit que toutes les relations en conformité avec (a) sont en 1NF.

Il parle de tuple, c'est à dire, si on transpose ça dans l'univers de la table d'une base de données, une ligne de cette table.

Soit les 2 tuples suivants, dans la relation R définie plus haut :
{1, 'Dupont', 'Jean', '1975-12-07'}
{2, 'Dupont', 'Jean', '1975-12-07'}

Il y a là deux personnes portant le même nom, le même prénom et étant nés le même jour mais ayant un identifiant différent. Peut-être que l'un est né à Paris et l'autre à Toulouse ; l'information ne figure pas ici mais ce sont a priori deux personnes différentes.

Chaque attribut contient bel et bien une seule valeur pour chaque tuple donc la relation est en 1NF.

[escartefigue]

Outre les réponses qui précèdent, vous pouvez aussi consulter l'article de Wikipédia sur ce sujet, dans lequel on trouve des exemples clairs de conformité et de non conformité aux différentes NF

[fsmrel]

Capitaine, tu fais référence à Wikipedia, où l’on trouve par exemple l’affirmation vieille comme la littérature de vulgarisation portant sur le modèle relationnel de données :

« Une relation ayant une clé formée d'un seul attribut est donc en deuxième forme normale »

Est-ce bien toujours vrai ? Je francise un exemple donné par Chris Date dans Database Design & Relational Theory, Normal Forms and All That Jazz.

Prenons le cas de la table FRANCE, comportant seulement les colonnes PAYS et DEPARTEMENT.

Son prédicat est le suivant :

DEPARTEMENT fait partie de PAYS.

En observant que la colonne PAYS prend la valeur "France" pour chaque ligne de la table. Autrement dit, {DEPARTEMENT} est la seule clé pour la table et l’on a bien :

{DEPARTEMENT} -> {PAYS}, mais il existe aussi la DF {} -> {PAYS} !

Ainsi, la DF {DEPARTEMENT} -> {PAYS} est réductible, en conséquence de quoi la 2NF est violée, bien que la clé {DEPARTEMENT} soit singleton...

Indépendamment de cela, la définition donnée par Wiki de la 2NF n’est pas la bonne, puisqu’il parle de « la clé », mais une relvar peut comporter plus d’une clé, je pense avoir assez tartiné à ce sujet. Toutes choses égales, ceci vaut pour sa 3NF, et devient absurde au stade de sa BCNF, pour ne pas parler de sa 4NF où l’erreur est criante : « Pour être en 4FN, il faut respecter la 3FN (et pas forcément en FNBC) » : celle-là je ne la connaissais pas, décidemment les farfelus ça ose tout.
Pour sa 5NF, ça devient franchement nébuleux et on peut appliquer la proposition 7 du Tractatus de Wittgenstein (« Sur ce dont on ne peut pas parler, il faut garder le silence »).

Désolé, je n’ai pas le temps de poursuivre, mais heureusement CinePhil a fait le boulot, merci à toi...

Quant à SpaceX, il va devoir éplucher ma prose.

[informer]

Bonjour spaceX

Un autre exemple pour illustrer

2FN : Deuxième forme normale
« Une relation est en deuxième forme normale si et seulement si :
- elle satisfait à la première forme normale
- tout attribut de l'entité n'appartenant pas à la clé ne dépend pas que d'une partie de la clé. »

Exemple
Soit la table t_cours(enseignant_id, enseignant_nom, enseignant_telephone, matiere_nom, matiere_syllabus_numero)
La clé est composée des attributs {enseignant_id, matiere_nom}.

Cette table satisfait à la première forme normale (une clé unique, et chaque attribut est atomique), mais pas à la deuxième forme normale car les attributs enseignant_nom et enseignant_telephone ne dépendent que de enseignant_id, et matiere_syllabus_numero ne dépend que de matiere_nom.

Pour satisfaire à la 2è forme normale, il faut décomposer la table de la manière suivante :

• t_cours(enseignant_fk, matiere_nom)
• t_enseignant(enseignant_pk, enseignant_nom, enseignant_telephone)
• t_matiere(matiere_nom, matiere_syllabus_numero)

Source ici

[fsmrel]

Informer, vous fournissez une définition de la deuxième forme normale que je viens de dénoncer dans mon précédent message, définition erronée, puisque ne mentionnant que « la clé », alors que la définition n’est valide que si chaque clé est partie prenante ; en effet, une variable relationnelle peut comporter plus d’une clé (tout comme du reste une table SQL). Il existe quand même des définitions valides, toutes équivalentes, par exemple celle-ci (cf. à nouveau Database Design & Relational Theory, Normal Forms and All That Jazz, page 44 en l’occurrence) :

Une variable relationnelle R est en deuxième forme normale si et seulement si pour chaque clé K de R et chaque attribut A non-clé de R, la dépendance fonctionnelle K → {A} est irréductible.

Ou celle-là, pour varier un peu :

Une variable relationnelle R est en deuxième forme normale si et seulement si pour chaque dépendance fonctionnelle non triviale X → Y de R, au moins une des 3 conditions suivantes est vérifiée :

(a) X est surclé ;

(b) Y est sous-clé ;

(c) X n’est pas sous-clé.

Je fais remarquer à cette occasion qu’il n’est pas fait mention de la 1NF (première forme normale), car par définition, une variable relationnelle est en 1NF : ajouter l’expression « est en 1NF et » dans la définition constituerait un pléonasme. CinePhil a pris la peine de rappeler l’équivalence, voir ici.

La référence que vous fournissez commet bien entendu la même erreur.


Maintenant, j’attends toujours votre réponse suite à ma remarque à propos de votre façon de botter en touche :

Pour répondre à ces questions voir tous les tutos et posts sur MERISE qui ont été déjà écrits sur se site.

Vous vous défaussez. Je vous demande des réponses précises quant à votre position, et il faudrait l’inférer de la liste des opinions plus ou moins pertinentes exprimées dans le forum Merise depuis 2002 ! Je réitère donc mes questions, merci d’étayer votre position.

Il va falloir que vous étudiiez Database Design & Relational Theory et/ou que vous épluchiez mon article.

[informer]

Je pense qu’en précisant clé primaire, cela devrait éviter toute confusion.

La deuxième forme normale (2FN) exige que chacun des attributs dépende entièrement de la clé primaire.

[fsmrel]

En matière de théorie relationnelle, il ne s’agit pas de penser, mais de démontrer.

Prenons le cas de la relvar (variable relationnelle) FPV dont le prédicat est le suivant :

Le fournisseur Four_No fournit la pièce Piece_No en quantité Quantité et il est localisé dans la villeVille.

Les règles de gestion des données correspondent au prédicat, et on met en évidence les dépendances fonctionnelles suivantes :

(DF01) {Four_No, Piece_No} → {Quantité}
(DF02) {Four_No} → {Ville}

Une extension à titre d’exemple :

FPV  Four_No    Piece_No    Quantité    Ville
     S1         P1               300    Lille
     S1         P2               200    Lille
     S1         P3               400    Lille
     S1         P4               200    Lille
     S1         P5               100    Lille
     S1         P6               100    Lille
     S2         P1               300    Paris
     S2         P2               400    Paris
     S3         P2               200    Lyon
     S4         P2               200    Lille
     S4         P4               300    Lille
     S4         P5               400    Lille

Vous noterez les redondances, on apprend 6 fois que le fournisseur S1 est localisé à Lille, une fois suffit...

Passons aux axiomes d’Armstrong.

En appliquant l’axiome d’augmentation à DF02, on infère la DF :

(DF03) {Four_No, Piece_No} → {Ville, Piece_No}

Et en appliquant l’axiome de décomposition à DF03, on produit les dépendances fonctionnelles :

(DF04) {Four_No, Piece_No} → {Ville}
(DF05) {Four_No, Piece_No} → {Piece_No}

Pour faire bonne mesure, en appliquant l’axiome de réflexivité et celui d’augmentation, on produit la DF :

(DF06) {Four_No, Piece_No} → {Four_No}

Le constat est que la paire {Four_No, Piece_No} est clé candidate de FPV (primaire si ça vous fait plaisir...) car, on vient de le prouver, elle détermine chaque attribut de FPV. Mais selon DF02, une partie de la clé, à savoir {Four_No}, détermine {Ville}, donc la deuxième forme normale est violée.

Ainsi, chaque attribut dépend de la clé (qualifions-la de primaire), et pourtant la deuxième forme normale est violée : votre définition est donc à évacuer.
∎

Encore une fois, au lieu de l’éviter vous n’avez fait qu’ajouter à la confusion en allant on ne sait où à la pêche à des définitions qui ne sont que des billevesées.

N’utilisez que les définitions fournies par les théoriciens du relationnel, Codd, Date, Fagin, Ullman, Zaniolo, Delobel, Adiba, sans oublier bien sûr des gens sérieux comme G. Gardarin... Les définitions que j’ai pris la peine de fournir viennent de ces gens-là, qui ont établi l’axiomatisation et les théorèmes ad-hoc.

Pour mémoire, ça fait plus de 20 ans que le qualificatif de "primaire" pour une clé candidate a été rendu inutile, obsolète, passé au rasoir d’Ockham, ventilé façon puzzle (la clé primaire serait plus égale que les autres, c’est tout ce qu’on peut en dire, elle figure évidemment encore dans la grammaire SQL, mais SQL n’est à confondre avec le modèle relationnel de données, il ne faudrait quand même pas prendre une vessie pour une lanterne...)

[informer]

le constat est que la paire {Four_No, Piece_No} est clé candidate de FPV (primaire si ça vous fait plaisir...) car, on vient de le prouver, elle détermine chaque attribut de FPV

Cela signifie que le système ne peut stocker qu’un enregistrement pour ce binôme. Une telle règle de gestion ferait interpréter l’attribut {quantité} comme une somme calculée (cumul) ce qui viole le principe de toute normalisation.
Donc pour moi, en aucun cas la paire {Four_No, Piece_No} ne pourrait être une clé candidate.

Mais soit, considérons cette règle de gestion comme une exigence fonctionnelle du métier mais encore une fois irréaliste, et dans ce contexte la paire {Four_No, Piece_No} comme clé primaire.

Puisque dans votre exemple l’attribut {ville} dépend de {four_no} , (four_no} n’étant qu’une partie de clé primaire et non la clé primaire, j’en arrive également à la conclusion du non respect de la 2NF.

[fsmrel]

Cela signifie que le système ne peut stocker qu’un enregistrement pour ce binôme.

On traite de la deuxième forme normale, on est donc dans le contexte de la théorie relationnelle, laquelle relève de la logique du 1er ordre. Je ne sache pas que Frege a été concerné par le stockage d’enregistrements, veillez à utiliser des termes appropriés. Par ailleurs, en relationnel on ne parle pas de binôme, mais de paire : {Four_No, Piece_No} est un ensemble, d’où l’emploi des accolades.

Une telle règle de gestion ferait interpréter l’attribut {quantité} comme une somme calculée (cumul) ce qui viole le principe de toute normalisation.

Je sais ce qu’est violer telle ou telle forme normale, mais violer un principe, non ; Il faudra nous expliquer. En tout cas, à vous suivre, on peut déjà comprendre que le père du modèle relationnel de données et inventeur de la normalisation des données, E.F. Codd (RIP) aurait tout faux !

En attendant, quelques remarques : du fait de la présence des accolades, {quantité} est un ensemble, singleton certes, mais néanmoins ensemble.
Un attribut n’étant pas un ensemble, mais seulement un élément d’un ensemble, dans votre phrase vous devrez supprimer les accolades, sinon vous rendez équivalents l’attribut Quantité et l’ensemble {Quantité}, ce qui conduit au paradoxe de l’ensemble de tous les ensembles, auquel cas je vous renvoie au paradoxe du barbier de Russel.

Vous parlez de somme calculée : la relvar FPV exprime simplement ce que les fournisseurs sont capables de fournir en pièces, on doit pouvoir répondre à des questions du genre « Quels fournisseurs peuvent fournir la pièce P2 en quantité 250 ? » Je vous renvoie à ce propos à l’ouvrage du père du modèle relationnel de données, E.F. Codd The Relational Model for Database Management, Version 2 (voyez par exemple à la page 24, où si l’on vous suit, Codd violerait le principe de toute normalisation ! ) Je vous renvoie également à son article fondateur de 1970 (The seminal paper), A Relational Model of Data for Large Shared Data Banks, selon lequel FPV n’est qu’une projection de sa relation Supply, laquelle est dotée d’un attribut supplémentaire Project. Selon vous, Codd une fois de plus « viole le principe de toute normalisation » Vous mettez dans le même sac C.J. Date, référence mondiale s’il en est en matière de théorie relationnelle : FPV n’est jamais qu’une extension de sa grande sœur FP, elle-même reprise de la version originale SP que Date utilise depuis 1974 dans An Introduction to Database Systems (l’ouvrage de référence, vendu à près d’un million d’exemplaires à ce jour !)

Et quand bien même la relvar FPV pourrait être considérée comme « une somme », elle serait le résultat d’une opération algébrique (c'est-à-dire de l’application des opérateurs de l’algèbre relationnelle ou du calcul relationnel), elle serait donc une relvar tout à fait respectable à son tour en vertu de la propriété de fermeture. Et toute relvar est sujette à normalisation. Quant à violer des principes...

Vous avez une vision très personnelle des choses.

Donc pour moi, en aucun cas la paire {Four_No, Piece_No} ne pourrait être une clé candidate.

Pour vous peut-être, mais seul contre Codd, Date, Fagin et compagnie, vous serez laminé. A nouveau, dans leurs écrits, la paire {Four_No, Piece_No} est bien clé candidate.

Mais soit, considérons cette règle de gestion comme une exigence fonctionnelle du métier mais encore une fois irréaliste

Pour être en phase avec les théoriciens que je viens de citer, je rappelle que la relvar FPV exprime simplement ce que les fournisseurs sont capables de fournir en pièces, on doit pouvoir répondre à des questions du genre « Quels fournisseurs peuvent fournir la pièce P2 en quantité 250 ? », ce qui ne semble pas irréaliste...

Cela dit, l’objet de la discussion n’est pas l’élaboration d’un MCD, mais seulement la deuxième forme normale, ne mélangez pas les genres.

[informer]

Un modèle normalisé ne stocke pas de valeurs calculées type sommation de données unitaires sauf bien sur à dénormaliser mais si on fait de la théorie alors partons d'un cas théorique valide.

Et un fine avec la définition que je donne, je conclue que la 2NF n'est pas respectée.

[fsmrel]

Un modèle normalisé

De quoi parlez-vous ? d’un modèle conceptuel des données à la Merise ? A la Chen ? D’un modèle logique des données à la Merise ? D’un modèle physique des données ?

Si vous parlez du modèle relationnel de données, je rappelle une dernière fois ce dont il s’agit.

Le modèle relationnel de données (qui relève de la logique et des mathématiques appliquées) est défini par les cinq composants suivants (pour plus de détails, voyez par exemple l’ouvrage de C. J. Date Database in depth: relational theory for practitioners) :

1. Une collection non limitée de types scalaires (dont notamment le type booléen (valeur de vérité)),
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen,
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu,
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs de relations à ces variables,
5. Une collection non limitée d’opérateurs relationnels génériques (« l’algèbre relationnelle »), pour produire des valeurs de relations à partir d’autres valeurs de relations.

Bien entendu, la théorie de la normalisation est orthogonale au modèle relationnel de données, c'est-à-dire que celui-ci n’a pas à traiter de la normalisation, il reste muet à son sujet, mais ce sont bien entendu des compagnons inséparables, tels un bon vin et un bon fromage.

Maintenant, si vous avez une définition (sérieuse) autre du modèle relationnel de données, merci de la fournir.

Un modèle normalisé ne stocke pas de valeurs calculées type sommation de données unitaires

Vous tenez absolument à ce que les valeurs prises par l’attribut Quantité de la relvar FPV résultent d’un calcul : je répète que tel n’est pas le cas, et même s’il en était ainsi, cela n’a rien à voir avec la normalisation au sens de la théorie, pour la nième fois, je vous renvoie à Database Design & Relational Theory, Normal Forms and All That Jazz.

Je pense que nous n’avons pas les mêmes sources, merci de fournir les vôtres (à condition bien sûr qu’elles soient sérieuses, ne nous resservez pas les définitions foireuses auxquelles vous avez déjà fait référence).

Quand je lis ceci :

« Les formes normales (FN) désignent certains types de relations entre les entités »

Je constate qu’il s’agit des relations merisiennes. Si l’auteur raisonne MCD merisien, alors de toute façon il a tout faux, car en toute logique les formes normales doivent aussi s’appliquer aux entités-types ! (Sinon il faudra qu’on s’assure de la normalisation au stade du MLD).

sauf bien sur à dénormaliser

Quel degré de normalisation accordez-vous à FP ? à FPV ? 1NF ? 0NF ? Ayez l’amabilité de démontrer formellement ce que vous avancez (au moyen des axiomes d’Armstrong par exemple).

si on fait de la théorie alors partons d'un cas théorique valide.

Je vous l’ai déjà fourni, voyez ici avec le trio F, P, FP (sans parler des exemples fournis par Codd et Date auxquels je vous ai déjà renvoyé).

Maintenant, si vous voulez vous situer au plan du MCD merisien, voici un point de départ (extrait de l’ouvrage d’Arnold Rochfeld et José Moréjon, La Méthode Merise, Tome 3 Gamme opératoire), où la relvar FP correspond à l’association Stocker du MCD, dans laquelle on retrouve l’attribut Quantité :

Aux attributs Qté stock réservée, Seuil critique et Seuil minimum près, lors du passage du MCD au MLD, la relvar Stocker équivaudra à la relvar FP.

Et un fine avec la définition que je donne, je conclue que la 2NF n'est pas respectée.

Avec des définitions comme les vôtres, in fine on peut concluer ce qu’on veut.

Pour terminer, le rappelle que la normalisation proposée par Codd date de 1970 (revoyez A Relational Model of Data for Large Shared Data Banks). La normalisation merisienne (cf. La Méthode Merise, Tome 1, principes et outils) a été formulée à peu de choses près 10 ans plus tard et n’est qu’un vague reflet de celle de Codd, sans l’axiomatique, d’où une faiblesse évidente. Les axiomes d'Armstrong datent de 1974 (déjà formulés par Delobel et Casey en 1973) : avec ces axiomes, plus ceux qui ont été établis pour les dépendances multivaluées, on contrôle totalement la normalisation jusqu’à la quatrième forme normale. Etant dépourvue de l’axiomatique, Merise ne peut que s’appliquer la 7e proposition du Tractatus logico-philosophicus de Wittgenstein : « Sur ce dont on ne peut pas parler, il faut garder le silence ».