Voudrait comprendre 6NF avec un exemple

en fait, j'ai commencé à préparer une réponse, mais j'ai rencontré des complications, parce que vous (tout à fait compréhensible) voulez 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éelle en matière de bases de données relationnelles et de 5NF; Je n'ai pas de point de départ pour aborder et discuter ensuite des détails de 6NF,

Deuxièmement, comme tout autre NFs, il est panaché. Vous pouvez à peine l'étape en elle; vous pouvez mettre en œuvre 6NF pour certaines tables, vous pouvez aller le plein sur chaque table, etc. Bien sûr, il y a une explosion de tables, mais ensuite vous normalisez cela, et tuez l'explosion; c'est une implémentation avancée ou mature de 6NF. Aucun usage de fournir les niveaux complets ou partiels de 6NF, quand vous demandez l'exemple le plus simple, le plus simple.

j'espère que vous comprenez que certaines tables peuvent être "en 5NF" tandis que d'autres sont "en 6NF".

donc j'ai mis un ensemble pour vous. Mais même cela nécessite une explication.

maintenant SQL supporte à peine 5NF, il ne supporte pas 6NF du tout (je pense que dportas dit la même chose dans des mots différents). Maintenant j'implémente 6NF à un niveau profond, pour des raisons de performance, pivotement simplifié (de tables entières; n'importe quelles et toutes les colonnes, pas la fonction de PIVOT stupide dans MS), accès columnar, etc. Pour cela, vous avez besoin d'un catalogue complet, qui est une extension du catalogue SQL, pour prendre en charge le 6NF que SQL ne ne prend pas en charge, et maintenir L'intégrité des données et des règles commerciales. Donc, vous ne voulez vraiment pas implémenter 6NF pour le plaisir, vous ne le faites que si vous en avez besoin, parce que vous devez implémenter un catalogue. (C'est ce que la foule des 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 L'intégrité des données que SQL a.)

mais la plupart des gens qui mettent en œuvre le 6NF niveau plus profond, avec un catalogue complet. Ils ont des besoins plus simples, et donc mettre en œuvre un niveau plus faible de 6NF. Donc, prenons ça, pour vous donner un exemple simple. Commençons par une table de produit ordinaire qui est déclaré être dans 5NF (et ne nous disputons pas sur ce que 5NF est). La société vend différents types de produits, la moitié des colonnes sont obligatoires, et l'autre moitié sont optionnelles, ce qui signifie que, selon le type de produit, certaines colonnes peuvent être nulles. Alors qu'ils peuvent avoir fait un bon travail avec la base de données, les Nulls sont maintenant un gros problème: les colonnes qui ne devraient pas être nulles pour certains types de produits sont nulles, parce que la déclaration indique NULL, et leur code app est seulement aussi bon que le prochain gars.

donc ils décident D'aller avec 6NF pour corriger ce problème, parce que le sous-titre de 6NF indique qu'il élimine le problème nul . Sixième forme normale est la forme normale irréductible, il n'y aura plus de NFs après cela, parce que les données ne peuvent plus être normalisées. Les rangées ont été normalisées au plus haut degré. La définition de 6NF est:

une table est dans 6NF quand la rangée contient la clé primaire, et au plus un, attribut.

remarquez 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. tables de référence ou de recherche typiques, avec un PK et une Description.

D'accord. Eh bien, nos amis regardent leur table de produit, qui a huit attributs non-clés, donc s'ils font la table de produit 6NF, ils auront huit tableaux de sous-produit. Ensuite, il y a le problème que certaines colonnes sont des clés étrangères à d'autres tables, et qui conduit à plus de complications. Et ils remarquent le fait que SQL ne supporte pas ce qu'ils font, et ils doivent construire un petit catalogue. Huit tables sont correctes, mais pas sensées. Leur le but était de se débarrasser des Nulls, pas d'écrire un petit subsytem autour de chaque table.

Simple 6NF exemple

les lecteurs qui ne sont pas familiers avec la norme de modélisation des bases de données relationnelles peuvent trouver IDEF1X Notation utiles pour interpréter les symboles de l'exemple.

donc typiquement, la Table de produit conserve toutes les colonnes obligatoires, en particulier Les FK, et chaque colonne optionnelle, chaque colonne nulle, sont placées dans un tableau séparé des sous-produits. C'est la forme la plus simple que j'ai vu. Cinq tables au lieu de huit. Dans le modèle, les quatre tableaux de sous-produits sont "en 6NF"; le tableau de produit principal est "en 5NF".

maintenant nous n'avons vraiment pas besoin de chaque segment de code qui sélectionne du produit pour avoir à comprendre quelles colonnes il devrait construire, basé sur le type de produit, etc, Donc nous fournissons une vue, qui fournit essentiellement la "vue" 5NF du groupe de table de produit.

la prochaine chose dont nous avons besoin est les rudiments de base d'une extension au catalogue SQL, afin que nous puissions nous assurer que les règles (intégrité des données) pour les différents types de produits sont maintenus en un seul endroit, dans la base de données, et ne dépend pas du code app. Le plus simple catalogue, vous pouvez vous en sortir avec. Qui est chassé de ProductType, donc ProductType fait maintenant partie de cette métadonnées. Vous can mettre en œuvre cette structure simple sans catalogue, mais je ne le recommande pas.

mise à Jour

Il est important de noter que j'ai mise en oeuvre de tous Règles de gestion dans la base de données. Sinon, ce n'est pas une base de données (la notion de mise en œuvre de règles "en code d'application" est hilarante à l'extrême, surtout de nos jours, quand nous avons des fleuristes qui travaillent comme des "développeurs"). Par conséquent, tous les les règles, etc sont avant tout mises en œuvre sous forme de déclarations SQL, de contraintes de contrôle, de fonctions, etc. Qui préserve toute L'intégrité référentielle déclarative, et L'intégrité des données déclaratives. L'extension au catalogue SQL couvre la zone pour laquelle SQL n'a pas de déclarations , et ils sont alors implémentés en tant que SQL. Être un bon dictionnaire de données, il fait beaucoup plus. Par exemple. Je n'écris pas Vues chaque fois que je change les tables ou ajouter ou modifier les colonnes ou leurs caractéristiques, ils sont créés directement à partir de l'extension catalog+en utilisant un générateur de code simple.

encore une note très importante. Vous ne pouvez pas mettre en œuvre 6NF (ou EAV correctement, d'ailleurs), sans avoir terminé un exercice complet et fidèle de Normalisation, à 5NF. Le problème que je vois à chaque site est, ils n'ont pas un véritable état 5NF, ils ont un mash de normalisation partielle ou aucune normalisation du tout, mais ils sont très attachés à cela. Création soit de 6NF ou VAE est une catastrophe. Créer EAV ou 6NF à partir de ce sans toutes les règles commerciales mises en œuvre dans la déclaration SQL est une catastrophe nucléaire, brûlant pendant des années. Vous obtenez ce que vous payez.

fin de la mise à jour.

enfin, oui, il y a au moins quatre autres niveaux de Normalisation (la Normalisation est un principe, pas une simple référence à une forme normale), qui peuvent être appliqués à ce simple groupe de produits 6NF, fournissant plus de de contrôle, moins de tables, etc. Plus on va loin, plus le catalogue est vaste. Et de plus hauts niveaux de performance. Quand vous êtes prêt, demandez simplement, j'ai déjà érigé les modèles et posté des détails dans d'autres réponses.

j'avais été auparavant sceptique de 6NF comme il a été présenté comme "simplement" coller quelques colonnes timestamp sur table.

Je ne sais pas d'où vient cette fausse idée. Peut-être le fait que 6NF a été introduit pour le livre "Temporal Data and The Relational Mode" par Date, Darwen et Lorentzos? Quoi qu'il en soit, j'espère que les autres réponses ici ont clarifié que 6NF n'est pas limité aux bases de données temporelles.

le point que je voulais faire valoir est, bien que 6NF soit" académiquement respectable " et toujours réalisable, il ne peut pas nécessairement conduire à la conception optimale dans tous les cas (et pas seulement lorsque L'on envisage la mise en œuvre en utilisant SQL soit). Même les découvreurs susmentionnés et les partisans du 6NF semblent être d'accord, par exemple

Chris Date : "Pour des raisons pratiques, s'en tenir à 5NF (et 6NF)."

Hugh Darwen : "la 6NF décomposition autour de la Date [pas de la personne!] serait exagéré... un design optimal pour le club de football est... 5-et-un-peu-NF!"

Hugh Darwen : "nous sommes en 5NF, mais pas dans 6NF, et encore 5NF est suffisant" (plusieurs exemples).

encore une fois, je peux aussi trouver des preuves du contraire:

Chris Date : "Darwen et j'ai senti depuis quelque temps que l'ensemble de la base de les relvars doivent être en 6NF".

sur une note pratique, j'ai récemment étendu le schéma SQL d'un de nos produits pour ajouter une caractéristique mineure. J'ai adopté un 6NF pour éviter les colonnes nullables et j'ai fini avec six nouveaux tableaux où la plupart (tous?) de mes collègues auraient utilisé un tableau (ou peut-être étendu un tableau existant) avec des colonnes nulles. Bien que j'ai prouvé plusieurs procs' helper 'stockés et un 'denormalized ' VIEW avec un INSTEAD OF déclencheurs, chaque codeur qui a dû travailler avec cette fonctionnalité au niveau SQL est allé hors de leur chemin pour me maudire:)

Ces gars-là ont vers le bas: Modélisation d'Ancrage . De grands documents académiques sur le sujet, combinés avec des exemples pratiques. Leurs écrits m'ont finalement poussé au-dessus du bord pour envisager de construire un DW en 6nf sur un projet à venir. Le POC travail que j'ai fait a validé (pour moi, au moins) que les énormes avantages de 6nf ne dépassent pas les coûts.