Est-ce que la 3ème forme normale est ok pour les bases de données?

Question

Dois-je toujours viser la 4ème forme normale lors de la conception de bases de données? Je pense que la 3ème forme normale est plus proche de mon domaine d'activité.

Par exemple, j'ai un tableau avec PartNumber. Dans mon domaine d'activité, c'est la clé unique, aucune partie ne doit avoir le même nombre. Cependant, il s'agit d'un VARCHAR, mettre une clé primaire à un VARCHAR et ensuite le relier comme une clé étrangère à l'autre table est une énorme odeur pour moi.

Est-ce que je devrais mettre des identificateurs automatiques d'augmentations partout à la place? Je ne vois pas vraiment le problème tout de suite et cela complique énormément le code.

Answer 1

Cela dépend de la base de données; en utilisant des champs varchar car votre PK gaspille de l'espace dans votre stockage DB et des index dans MySQL (par exemple). Avoir une table et un identifiant entier unique pour vos numéros de pièces peut sembler moins pur, mais de telles choses sont parfois nécessaires face à la performance.

(Et plus loin, il ne vous permet de mettre à jour un numéro de produit si nécessaire dans un seul endroit, mais je soupçonne que cela est probablement pas probable dans votre logique métier.)

Answer 2

Alors que votre question porte sur 4NF, votre situation particulière ne l'est pas. L'utilisation d'un champ VARCHAR comme clé primaire n'est pas erronée, si elle est relativement petite, je préférerais l'utiliser plutôt qu'une clé de substitution.

Retour à 4NF - à partir de Wikipedia's example, cela semble être quelque chose qui, la plupart du temps, se met naturellement en place. Il ne peut certainement pas faire de mal à lutter pour 4NF - en même temps la dénormalisation a sa place.

Answer 3

Autorisez-vous vos utilisateurs à modifier les numéros de pièce? Si c'est le cas, c'est un bon argument contre l'utilisation comme clé primaire. En règle générale, les clés PK ne doivent pas être modifiables par l'utilisateur car la réplication d'un PK modifié via la base de données peut devenir très coûteuse.

Aussi - est-ce que deux parties ne doivent jamais avoir le même numéro, ou deux parties actives peuvent avoir le même numéro? Si c'est le dernier, avez-vous besoin de garder une histoire suffisamment longue pour que vous puissiez vous retrouver avec deux numéros de pièces identiques?

Answer 4

En règle générale, visez que votre base de données soit au moins dans la forme normale de Boyce-Codd ou, idéalement, dans la cinquième forme normale. Considérez 3NF seulement s'il y a des dépendances qu'il est important de préserver et qui ne seraient pas satisfaites par 5NF. 4NF n'a rien à voir avec si vous utilisez varchar ou des entiers dans vos clés et je ne sais pas pourquoi vous semblez le penser.

Answer 5

Il faut quelques semaines pour apprendre à normaliser les données. Il faut des mois, voire des années, pour apprendre à ignorer les règles de normalisation. Bien sûr, si vous ne tenez pas compte des règles de normalisation, il y aura des conséquences. Si vous apprenez la normalisation à fond, vous saurez que les conséquences sont. Parfois, les conséquences de ne pas adhérer à une forme normale donnée sont légères, par rapport à l'avantage de suivre un autre modèle de conception. Par exemple, lors de la création d'une base de données OLAP ou d'un entrepôt de données, le schéma en étoile ou le schéma en flocon de neige est souvent plus productif que normalisé.

Pour les bases de données OLTP, j'aurais tendance à viser la forme normale de Boyce-Codd, et à faire face à toute anomalie de modification due à la sortie de la 4ème ou 5ème forme normale. Mais cela dépend vraiment de l'affaire.