normalisation 2NF quel intérêt

Yo les mecs,

ok pour le 1NF, il est important qu'un tableau ne ressemble pas à un gros pâté où on a fourré toutes les infos.
en respectant une normalisation 1NF on a déjà qqch qui ressemble très fortement à une vraie BDD
par contre 2NF j'ai pas trop compris. Déjà qui est assez bête pour mettre 2 colonnes composite key au lieu d'une seule colonne primary key dont on sait que c'est généralement la colonne ID.
à partir du moment où on a une seule colonne ID primary key pour un tableau la question ne se pose plus de savoir si un attribut non candidat deprendra partiellement ou complètement d'une composite key. si vous avez des exemples où 2 colonnes composite key sont obligatoires et preferable à une colonne primary key jveux bien entendre l'exemple.
et si un gars omettait de lier une colonne non candidate complètement aux 2 colonnes composite key à quel moment ça génère une anomalie ?
si je lance une requete de recherche en joignant les 2 colonnes, l'attribut non lié aux 2 colonnes ne sortira pas dans les resultats, right ? mais que dire si je modifie cette colonne ? il ny aura aucune anomalie. enfin bref jvois pas en quoi c'est critique de respecter le 2NF

Bonjour,

Je ne suis pas sûr d'avoir tout compris votre problème. Mais en exemple si vous avez une clé primaire composé de deux attributs, un nom et un prénom par exemple, cela évitera d'avoir des doublons de personnes car vous ne pouvez avoir qu'une unique personne avec ce nom et prénom. Par contre si vous utilisez des id qui sont des chiffres en clé primaire, rien ne vous empeches d'avoir deux fois les mêmes données.

Bonjour,

Citation:

Envoyé par Yuseph

Yo les mecs,
ok pour le 1NF, il est important qu'un tableau ne ressemble pas à un gros pâté où on a fourré toutes les infos.
en respectant une normalisation 1NF on a déjà qqch qui ressemble très fortement à une vraie BDD

Une table n'est pas un tableau, dans un tableau, les formes normales, on s'en fiche.

Citation:

Envoyé par Yuseph

par contre 2NF j'ai pas trop compris. Déjà qui est assez bête pour mettre 2 colonnes composite key au lieu d'une seule colonne primary key dont on sait que c'est généralement la colonne ID.
à partir du moment où on a une seule colonne ID primary key pour un tableau la question ne se pose plus de savoir si un attribut non candidat deprendra partiellement ou complètement d'une composite key. si vous avez des exemples où 2 colonnes composite key sont obligatoires et preferable à une colonne primary key jveux bien entendre l'exemple.

Les exemples sont légion :

Cas des tables associatives : l'identifiant d'une table associative est composé des identifiants de chaque type d'entité participant à l'association, soit à minima deux colonnes
Cas de l'identification relative : la table issue de l'entité-type faible a pour identifiant celui de l'entité-type forte complété d'un identifiant propre.
par exemple, la table "ligne de commande" aura pour identifiant l'identifiant commande + un chrono

Citation:

Envoyé par Yuseph

et si un gars omettait de lier une colonne non candidate complètement aux 2 colonnes composite key à quel moment ça génère une anomalie ?
si je lance une requete de recherche en joignant les 2 colonnes, l'attribut non lié aux 2 colonnes ne sortira pas dans les resultats, right ? mais que dire si je modifie cette colonne ? il ny aura aucune anomalie. enfin bref jvois pas en quoi c'est critique de respecter le 2NF

"Les mecs", "un gars" :weird:, disons plutôt quelqu'un ce sera plus correct et plus réaliste. Les femmes aussi ont le droit, fort heureusement, de modéliser des bases de données et de les utiliser...
Cela étant dit, si un attribut non candidat ne dépend que d'une partie de l'identifiant, c'est qu'il y a redondance.
Ce faisant, toute modification de la valeur de cet attribut devra être répétée autant de fois qu'il est redondant. C'est un risque d'oubli, un coût de stockage et un coût de mise à jour inutiles.

Citation:

Envoyé par bbsebb

Bonjour,

Je ne suis pas sûr d'avoir tout compris votre problème. Mais en exemple si vous avez une clé primaire composé de deux attributs, un nom et un prénom par exemple, cela évitera d'avoir des doublons de personnes car vous ne pouvez avoir qu'une unique personne avec ce nom et prénom. Par contre si vous utilisez des id qui sont des chiffres en clé primaire, rien ne vous empeche d'avoir deux fois les mêmes données.

C'est différent : le doublon fonctionnel vrai sera évité par l'ajout d'une contrainte UNIQUE sur le ou les attributs permettant de vérifier l'unicité.
Dans votre exemple, la contrainte UNIQUE posée sur nom+prenom évite les doublons, pour autant, ce binôme n'a pas vocation a être l'identifiant primaire, c'est même à éviter : les colonnes dont le contenu peut changer (modification de l'orthographe du nom suite à erreur de saisie par exemple) ne doivent pas être retenues comme identifiants primaires. Les identifiants primaires se propagent dans les tables liées c'est pourquoi ils doivent être stables pour éviter les mises à jour en cascade.
Dans la vraie vie, on posera plutôt une contrainte unique sur une colonne fiable telle que le numéro national d'identité (NNI ou NIR) car le couple nom+prénom ne saurait être unique, homonymes oblige.

Cest vrai, l'exemple n'était pas probant.