Quel genre de règle de normalisation que cela viole?

Question

Supposons que j'ai deux tables d'une base de données, T ₁₀ et T ₁₁ , ayant 10 et 11 colonnes, respectivement, où 10 des colonnes sont exactement les mêmes sur à la fois.

Qu'est-ce que (le cas échéant) règle de normalisation suis-je viole?

Answer 1

Edit: J'ai été informé qu'aucune forme normale sont violés ici en théorie. Comme ce fut la réponse acceptée, je le laisse ici pour référence, et parce que nous pensons 3NF peut en pratique aider à éviter des situations comme ça dans la question.

Vous violez le troisième forme normale (3NF) , parce que si la plupart du temps les mêmes données est maintenu dans les deux tables, puis tous les attributs de chaque table ne dépend pas directement sur la clé de sa table respective.

Answer 2

Croyez-le ou non, dupliquer des colonnes dans les tables ne viole aucune forme normale théorique en soi. À l'exception de domaine / clé forme normale (DKNF), les formes normales sont définies en termes de particuliers, non multiple, tables. DKNF est définie en termes de contraintes, dont il n'y en a pas dans le cas général. Ainsi, s'il y a une violation d'une forme normale:

• il doit être spécifique à l'une des tables et existe indépendamment d'avoir deux tables (à savoir la table serait contraire encore la forme normale, même si vous avez supprimé l'autre table), ou
• la relation a une contrainte qui porte atteinte DKNF, ce qui signifie qu'il est pas un exemple du cas général décrit dans la question, mais un cas plus spécifique. Ce ne sont pas les colonnes en double qui créent la violation, mais plutôt la contrainte supplémentaire sur la colonne supplémentaire.

Considérez , en utilisant les brèves définitions de l'article Wikipedia:

  

1FN

  

    

Le tableau représente fidèlement une relation et n'a pas de groupes répétitifs.

   

Celui-ci est assez simple. Le terme « répétition des groupes » a plusieurs significations dans la théorie, mais aucun d'entre eux ont rien à voir avec des colonnes ou des données en double.

  

  

2FN

  

    

Aucun attribut non-prime dans le tableau dépend fonctionnellement sur un sous-ensemble d'une clé candidate.

    

Ici, le terme est important d'examiner la « dépendance fonctionnelle ». Pour l'essentiel, une dépendance fonctionnelle est l'endroit où vous projetez une relation avec deux colonnes, X et Y, et le vent avec une fonction X → Y. Vous ne pouvez pas avoir une dépendance fonctionnelle entre deux tables (ou plus) ^* . De plus, les clés candidats ne peuvent pas couvrir plusieurs tables.

  

  

3NF

  

    

Chaque attribut non-prime dépend non transitive sur chaque clé candidate dans le tableau.

    

transitive dépendance est définie en termes de dépendance fonctionnelle: une dépendance est une dépendance transitive où X → Z seulement parce que X → Y et Y → Z. X, Y et Z doit être dans la même table parce que ce sont des dépendances fonctionnelles.

  

  

4NF

  

    

Chaque dépendance à plusieurs valeurs non négligeable dans le tableau est une dépendance sur un superkey.

    

de dépendance est un peu multivaluée plus délicat, mais il peut être illustré par un exemple: « chaque fois que les tuples (a, b, c) et (a, d, e) existent dans r, les tuples (a, b, e) et (a, d, c) doit également exister sous r »(où "r" est une table). Plus important encore pour la présente affaire, une dépendance à plusieurs valeurs applique uniquement à une seule table.

  

  

5NF

  

    

Chaque jointure dépendance non négligeable dans le tableau est sous-entendu par les super-clés de la table.

    

Une table a une rejoindre la dépendance si elle peut être exprimée comme la jointure naturelle des autres tables . Ces autres tables, cependant, ne doivent pas exister dans la base de données. Si la table T ₁₁ dans l'exemple avait une jointure dépendance, il aurait encore un même si vous avez retiré la table T ₁₀

  

  

6NF (C. Date)

  

    

Tableau comporte aucune dépendance jointure non-trivial du tout (en référence à généralisée opérateur de jointure).

    

Même raisonnement pour 5NF.

  

  

Forme normale clé primaire (EKNF)

  

    

Chaque dépendance fonctionnelle non négligeable dans le tableau est soit la dépendance d'un attribut clé élémentaire ou d'une dépendance à une superkey.

    

Même raisonnement pour 2FN.

  

  

forme normale Boyce-Codd (BCNF)

  

    

Chaque dépendance fonctionnelle non négligeable dans la table est une dépendance à une super-clé.

    

Même raisonnement pour 2FN.

  

  

Forme normale Domaine / clé (DKNF)

  

    

Chaque contrainte sur la table est une conséquence logique des contraintes de domaine et les principales contraintes de la table.

    

Si T ₁₁ a une contrainte qui dépend de T ₁₀ , alors il est soit une contrainte de clé ou une contrainte plus complexe qui fait toujours référence à T ₁₀ . Dans ce dernier cas n'est pas le cas général mentionné dans la question. En d'autres termes, alors il pourrait y avoir des schèmes spécifiques avec des colonnes en double qui violent DKNF, il est pas vrai en général. En outre, il est la contrainte (pas la forme normale) qui est définie en termes de multiples tables et la contrainte (pas la duplication de la colonne) qui provoque une violation DKNF.

  

---

Le but de la normalisation inclut la prévention des anomalies. Cependant, la normalisation est pas complète en ce qu'elle ne garantit pas une base de données relationnelle sera complètement libre d'anomalies. Ceci est un cas où la pratique diverge de la théorie.

Si cela ne vous convainc pas, considérer le schéma KM. De conseils de commentaire à, où T ₁₁ représente une version historique (ou versionné) de T ₁₀ . La clé primaire de T ₁₁ se compose des colonnes de clé primaire tenue en commun avec T ₁₀ , plus la colonne supplémentaire (la colonne date / version). Ce T ₁₁ a différentes clés candidats fait toute la différence entre une anomalie et sujette à une anomalie de conception libre, normalisée.

^* Quelqu'un pourrait penser que vous pouvez utiliser pour créer une joint dépendance entre deux tables. Alors qu'une jointure pourrait créer une table qui a une dépendance, la dépendance existe sur ce tableau, et non pas entre les constituants de la jointure. Dans le cas présent, cela signifie encore que l'une des tables serait une table jointe et souffriraient de la dépendance elle-même, indépendamment de l'autre table dans la base de données.

Answer 3

Peut-être la règle d'éviter les données redondantes? (À savoir les mêmes données dans deux tables)

Answer 4

si 10 des 11 colonnes sont les mêmes, pourquoi ne peut-être ce juste une table, où la colonne 11 est laissée en blanc (avec une 12e colonne possible pour indiquer quel type de données, il est, à savoir quelle table il aurait été à l'origine)?

Answer 5

Cela dépend de ce qui est dans les tableaux.

Si aucun enregistrement sont liés les uns aux autres (par exemple, si une table est simplement les enregistrements archivés originaires mais retirée de la première table) vous n'êtes pas violer aucune règle.

Mais si ce sont les mêmes enregistrements dans chaque table, vous avez un problème de dépendance - que onzième colonne ne dépend que de la valeur de clé de l'enregistrement, et non les colonnes supplémentaires. En supposant que toutes les dix colonnes ne sont pas impliqués dans la clé primaire, vous avez violé 3 NF.

Answer 6

Avoir deux relations identiques ou quasi identiques ne sont pas en soi une violation de l'une des formes normales habituelles. Outis a expliqué pourquoi de manière très complète. Il pourrait bien être une violation de la Principe de conception cependant Orthogonal, ce qui est un autre aspect de la théorie de la conception de base de données relationnelle.

Answer 7

Si toutes les 10 colonnes font partie de votre clé, puis deuxième forme normale: L'élimination des données redondantes. Plus précisément, cela tombe sous « Nonsurrogate Versus clés Surrogate primaire » __gVirt_NP_NN_NNPS<__ dilemme - pour être honnête, je ne me souviens pas non plus de ces deux choix pour être « violer » 2NF, mais la clé de substitution est certainement plus proche de l'esprit de 2FN

Answer 8

Seules les clés primaires peuvent être redondantes entre les tables. Avoir une somme de colonnes clés non primaires dans plusieurs tables viole troisième forme normale.