Est-il encore normalisé db schéma? base de données

Question

J'ai le schéma db-suivant.

DOSSIER , GROUP et BLOC représentent la structure de l'objet du fichier XML. DOSSIER est la racine. GROUP a FK DOSSIER . BLOC a une FK à GROUP et l'autre FK à UNITÉ .

UNITÉ groupes "similaires" BLOCs diffrent Groupes dans le contexte de DOSSIER .

La base de données est actuellement en 3NF. Pourtant, je voudrais savoir qui UNITs appartiennent à DOSSIER .id = 1. Pour ce faire encore, je dois faire une requête qui joint les 4 tables. Pour optimiser ce schéma, je peux créer la nouvelle relation UNITÉ n - FK -> 1 DOSSIER . Pourtant, ma requête rejoint seulement deux tables sur le optimisé db-schéma. Et voici la question: est-ce DB (avec ce nouveau FK) encore en 3 NF? Ce que dit la théorie?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

ou

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

D'après les informations fournies, il semble que ce soit une vraie hiérarchie parallèle. Sur cette base, je crois que le schéma proposé modifié serait encore normalisé à 3NF.

Answer 2

On ne sait pas comment les ajustements de table UNITAIRE dans le schéma avant de faire des changements.

De toute évidence, une fois que vous apportez des modifications, tout ce que vous devez faire pour savoir quelles unités appartiennent à un fichier est joindre les tables de fichier et l'unité.

Puisque les tableaux sont en 3FN lorsque toutes les dépendances fonctionnelles sont déterminées par les touches, les touches entières, et rien que les clés (donc me aider Codd), vous devez regarder votre schéma dans cette lumière.

Compte tenu des informations disponibles, très probablement les tables sont en 3FN (et BCNF, et AFAICT dans 4NF et 5NF aussi).

Answer 3

Je ne pense pas que votre diagramme « corneilles pied » prend en charge les autres dépendances décrites dans votre question. Comment êtes-vous arrivé avec le 1: plusieurs entre FILE et UNITÉ

?

Ce sont les dépendances fonctionnelles que vous décrivez ...

• GROUP -> DOSSIER
• BLOC -> GROUP
• BLOC -> UNITÉ

En outre, je suppose que chacun des attributs ci-dessus déterminent fonctionnellement certains attributs supplémentaires qui ne figurent pas sur le côté gauche d'une autre dépendance fonctionnelle. Ceux-ci seraient:

• DOSSIER -> autre fichier-attributs
• GROUP -> autre groupe-attributs
• BLOC -> d'autres blocs-attributs
• UNITÉ -> d'autres unités-attributs

La construction d'un ensemble de relations 3NF de ce qui précède les dépendances fonctionnelles donne:

• FileRelation: ( DOSSIER , d'autres attributs-fichier-)
• GroupRelation: ( GROUP , DOSSIER , d'autres groupes-attributs)
• UnitRelation: ( UNITE , autre unité d'attributs)
• BlockRelation: ( BLOC , GROUPE , UNITÉ , d'autres blocs-attributs)

correspond assez bien à ce que vous avez décrit.

UNITÉ les instances se rapportent à une donnée DOSSIER exige une jointure de FileRelation à GroupRelation sur DOSSIER , puis à GroupRelation BlockRelation sur GROUP puis BlockRelation à UnitRelation sur UNITÉ .

Vous voulez éviter ce multi-table de jointure en insérant une nouvelle relation quelque part dans le modèle donne une cartographie directe à partir de UNITÉ DOSSIER . Une telle relation implique la fonctionnelle Dépendance:

• UNITÉ -> DOSSIER

Cela ressemble le bit que vous avez ajouté au diagramme « corneilles pieds ». L'ajout de cette logique introduit contradiction. Les supports de schéma original ayant une donnée UNITÉ relatif à plusieurs instances Fichier . comme dans:

• FileRelation (F1, ...)
• FileRelation (F2, ...)
• GroupRelation (G1, F1, ...)
• GroupRelation (G2, F2, ...)
• BlockRelation (B1, G1, U1, ...)
• BlockRelation (B2, G2, U1, ...)
• UnitRelation (U1, ...)

instance de l'unité U1 concerne les instances de FICHIER F1 et F2. Compte tenu de cette situation soit la UNITÉ -> DOSSIER dépendance fonctionnelle ne peut pas être pris en charge ou l'ensemble des dépendances fonctionnelles d'origine étaient incomplètes et le schéma n'est pas en 3FN.

À ce stade, vous devez résoudre si le monde réel soutient le DOSSIER -> UNITÉ la dépendance ou non. Dans le cas contraire, le modèle original est pas en 3NF et un peu plus retravaillant du schéma est en ordre. Si la dépendance est pas pris en charge alors le mieux que vous pouvez dire est:

• DOSSIER , UNITÉ -> rien

et la relation correspondante:

• FileUnit: ( DOSSIER , UNITÉ )

est un dénormalisation parce que son contenu peut être dérivée par les tables existantes fonctionnelles dépendances.

============================================ =====================================

EDIT

D'après un certain nombre de commentaires à cela et d'autres réponses, il apparaît que:

• UNITÉ -> DOSSIER

est une véritable dépendance fonctionnelle, la dépendance fonctionnelle:

• BLOC -> UNITÉ

sans incorrect, doit être redondant. Je crois que l'ensemble 3NF correcte relations pource modèle est maintenant:

• FileRelation: ( DOSSIER , d'autres attributs-fichier-)
• GroupRelation: ( GROUP , DOSSIER , d'autres groupes-attributs)
• UnitRelation: ( UNITÉ , DOSSIER , d'autres unités-attributs)
• BlockRelation: ( BLOC , GROUPE , d'autres blocs-attributs)

Notez que UNITÉ clé étrangère est passée de la BlockRelation. En effet, le UNITÉ -> DOSSIER FD fait redondant. le ( BLOCK , UNITE ) relation est maintenant formé en joignant UnitRelation à FileRelation sur fichier puis FileRelation à GroupRelation sur DOSSIER puis GroupRelation à BlockRelation sur GROUP .

Le schéma d'origine n'a pas été en 3FN en raison de la non déclarée dépendance fonctionnelle: UNITÉ -> DOSSIER . au-dessus de l'ensemble des relations est proposé en 3FN.

Remarque: Lors de la normalisation d'un schéma, chaque dépendance fonctionnelle doit être déclaré à l'avant. Manquant on peut changer l'image entier!