J'ai en fait commencé à élaborer une réponse, mais je me suis heurté à des complications, car vous voulez (et c'est bien compréhensible) un exemple simple. Le problème est multiple.
Tout d'abord, je n'ai pas une bonne idée de votre niveau d'expertise réel en matière de bases de données relationnelles et de 5NF ; je n'ai pas de point de départ pour reprendre et discuter ensuite des spécificités de 6NF,
Deuxièmement, comme toutes les autres FN, elle est bigarrée. Vous pouvez à peine vous y aventurer ; vous pouvez mettre en œuvre la 6NF pour certaines tables ; vous pouvez vous lancer à fond dans toutes les tables, etc. Bien sûr, il y a une explosion de tables, mais ensuite vous les normalisez, et tuez l'explosion ; c'est une implémentation avancée ou mature de la 6NF. Il est inutile de fournir les niveaux complets ou partiels de la 6NF, alors que vous demandez l'exemple le plus simple et le plus direct.
J'espère que vous comprenez que certaines tables peuvent être "en 5NF" alors que d'autres sont "en 6NF".
Alors j'en ai fait un pour toi. Mais même cela nécessite une explication.
Maintenant, SQL supporte à peine 5NF, il ne supporte pas du tout 6NF (je pense que dportas dit la même chose avec des mots différents). J'implémente maintenant 6NF à un niveau profond, pour des raisons de performance, de pivotement simplifié (de tables entières ; toutes les colonnes et n'importe lesquelles, pas la stupide fonction PIVOT de MS), d'accès en colonnes, etc. Pour cela, vous avez besoin d'un catalogue complet, qui est une extension du catalogue SQL, pour prendre en charge la 6NF que SQL ne prend pas en charge, et maintenir l'intégrité des données et les règles commerciales. Donc, vous ne voulez vraiment pas mettre en œuvre 6NF pour le plaisir, vous ne le faites que si vous en avez besoin, parce que vous devez mettre en œuvre un catalogue. (C'est ce que la foule EAV ne fait pas, et c'est pourquoi la plupart des systèmes EAV ont des problèmes d'intégrité des données. La plupart d'entre eux n'utilisent pas le déclaratif Référentiel et intégrité des données que SQL possède).
Mais la plupart des personnes qui mettent en œuvre le 6NF ne mettent pas en œuvre le niveau le plus profond, avec un catalogue complet. Ils ont des besoins plus simples, et mettent donc en œuvre un niveau moins profond de 6NF. Prenons donc ce cas de figure, pour vous donner un exemple simple. Commençons par une table de produits ordinaire qui est déclarée être en 5NF (et ne discutons pas de ce qu'est la 5NF). L'entreprise vend différents types de produits, la moitié des colonnes sont obligatoires, et l'autre moitié est facultative, ce qui signifie que, selon le type de produit, certaines colonnes peuvent être nulles. Bien qu'ils aient fait un bon travail avec la base de données, les Nuls sont maintenant un gros problème : les colonnes qui ne devraient pas être Nuls pour certains ProductTypes sont Nuls, parce que la déclaration indique NULL, et leur code d'application est aussi bon que celui du voisin.
Ils décident donc d'opter pour 6NF pour résoudre ce problème, car le sous-titre de 6NF indique qu'elle élimine le problème de la nullité . La sixième forme normale est la forme normale irréductible, il n'y aura pas d'autres formes normales après celle-ci, car les données ne peuvent pas être normalisées davantage. Les lignes ont été normalisées au plus haut degré. La définition de 6NF est :
une table est en 6NF lorsque la ligne contient la clé primaire et au maximum un attribut.
Notez que par cette définition, des millions de tables à travers la planète sont déjà en 6NF, sans avoir eu cette intention. Par exemple, les tables de référence ou de consultation typiques, avec juste un PK et une description.
Bien. Eh bien, nos amis regardent leur table Produit, qui a huit attributs non clés, donc s'ils font la table Produit 6NF, ils auront huit tables sous-Produit. Ensuite, il y a le problème que certaines colonnes sont des clés étrangères pour d'autres tables, ce qui entraîne d'autres complications. Enfin, ils constatent que SQL ne prend pas en charge ce qu'ils font, et ils doivent construire un petit catalogue. Huit tables, c'est correct, mais ce n'est pas raisonnable. Leur but était de se débarrasser des Nulls, pas d'écrire un petit sous-système autour de chaque table.
Exemple simple de 6NF
Les lecteurs qui ne sont pas familiers avec la norme de modélisation des bases de données relationnelles peuvent trouver que Notation IDEF1X utile afin d'interpréter les symboles de l'exemple.
Donc, typiquement, la table des produits conserve toutes les colonnes obligatoires, en particulier les FK, et chaque colonne optionnelle, chaque colonne annulable, est placée dans une table de sous-produits distincte. C'est la forme la plus simple que j'ai vue. Cinq tables au lieu de huit. Dans le modèle, les quatre tables de sous-produits sont "en 6NF" ; la table principale du produit est "en 5NF".
Maintenant, nous n'avons vraiment pas besoin que chaque segment de code qui SELECT à partir de Product doive comprendre quelles colonnes il doit construire, sur la base du ProductType, etc., donc nous fournissons une vue, qui fournit essentiellement la "vue" 5NF du cluster de table Product.
Nous avons ensuite besoin des rudiments d'une extension du catalogue SQL, afin de garantir que les règles (intégrité des données) pour les différents types de produits sont maintenues en un seul endroit, dans la base de données, et ne dépendent pas du code de l'application. Le catalogue le plus simple possible. Il est piloté par ProductType, et ProductType fait maintenant partie de ces métadonnées. Vous pouvez consulter le site peut mettre en œuvre cette structure simple sans catalogue, mais je ne le recommanderais pas.
Mise à jour
Il est important de noter que je mets en œuvre todo Règles commerciales dans la base de données. Sinon, ce n'est pas une base de données (la notion d'implémentation des règles "dans le code de l'application" est hilarante à l'extrême, surtout de nos jours, où des fleuristes travaillent comme "développeurs"). Par conséquent, toutes les règles, etc. sont d'abord et avant tout mises en œuvre en tant que déclarations SQL, contraintes CHECK, fonctions, etc. Cela préserve toute l'intégrité référentielle déclarative, et l'intégrité déclarative des données. L'extension au catalogue SQL couvre le domaine que SQL n'a pas déclarations et ils sont ensuite implémentés en tant que SQL. Etant un bon dictionnaire de données, il fait beaucoup plus. Par exemple, je n'écris pas de vues à chaque fois que je modifie les tables ou que j'ajoute ou modifie des colonnes ou leurs caractéristiques, elles sont créées directement à partir du catalogue+extension en utilisant un simple générateur de code.
Une autre note très importante. Vous ne pouvez pas mettre en œuvre 6NF (ou EAV correctement, d'ailleurs), sans effectuer un exercice de normalisation complet et fidèle à 5NF. Le problème que je vois sur tous les sites est qu'ils n'ont pas un véritable état 5NF, ils ont un mélange de normalisation partielle ou pas de normalisation du tout, mais ils sont très attachés à cela. Créer 6NF ou EAV à partir de ça est un désastre. Créer EAV ou 6NF à partir de cela sans toutes les règles de gestion implémentées en SQL déclaratif est une catastrophe nucléaire, qui brûle depuis des années. Vous obtenez ce pour quoi vous payez.
Mise à jour de la fin.
Enfin, oui, il existe au moins quatre autres niveaux de normalisation (la normalisation est un principe, et non une simple référence à une forme normale), qui peuvent être appliqués à ce simple groupe de produits 6NF, fournissant plus de contrôle, moins de tableaux, etc. Plus nous allons en profondeur, plus le catalogue est étendu. Et des niveaux de performance plus élevés. Lorsque vous êtes prêt, il suffit de demander, j'ai déjà érigé les modèles et posté les détails dans d'autres réponses.
