J'ai un problème avec la deuxième forme normale (2NF) et je n'ai pas pu le résoudre en utilisant Google. Ça me rend fou parce que je suis professeur et je ne veux pas enseigner de mauvaises choses à mes élèves.

Ayons une table avec 5 champs.

Gradations = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Les dépendances sont de cette façon:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Par conséquent, la clé candidate 1 est {StudentName, SubjectCode, #Exam} et la clé candidate 2 est {StudentName, SubjectName, #Exam} .

Les attributs principaux sont {StudentName, SubjectCode, SubjectName, #Exam} et les attributs non premiers sont Grade

Selon la définition de la deuxième forme normale, un attribut non premier ne peut pas dépendre d'une partie d'une clé candidate. Le seul attribut non premier (Grade) ne dépend pas d'une partie d'une clé candidate, ce tableau semble donc en 2NF.

Le problème est que je pense que quelque chose ne va pas (et je peux me tromper). Je pense que les sujets devraient avoir leur propre table.

Notes = {StudentName, Subject Code, #Exam, Grade}

Subjects = {Subject Code, SubjectName}

Mais 2NF ne produit pas cela. 3NF concerne les dépendances entre les attributs non premiers, il ne produit donc pas cela non plus. Mais il me semble que c'est le bon résultat, car il n'y a pas de redondance.

Je suppose que si l'attribut non premier était défini comme "attribut qui n'est pas une clé candidate", 2NF produirait le résultat souhaité. Mais j'ai vérifié cela encore et encore et l'attribut non premier est défini comme "attribut qui n'appartient pas à une clé candidate".

Qu'est-ce que je fais mal?

Votre relation est en 3NF, (et pas seulement en 2NF), car comme vous le dites, le seul attribut non premier est Grade , qui n'apparaît que sur le côté droit de vos FD.

La relation n'est pas dans BCNF, car le côté gauche des deux petits FD n'est pas une super-clé.

Vous pouvez cependant décomposer sans perte la relation avec ( SubjectCode , SubjectName ) et soit ( StudentName, SubjectCode, #Exam, Grade ) ou ( StudentName, SubjectName, #Exam, Grade )

Cette décomposition vous donne deux relations BCNF et préserve toutes les dépendances fonctionnelles. Ce n'est pas toujours possible (vous pouvez toujours décomposer une relation à 3NF, mais pas nécessairement à BCNF).

2NF

Si vous voulez un exemple de 2NF (et non de 3NF), votre relation doit contenir des dépendances transitives.

Par exemple, supposons que vous ayez une colonne Score. Score intuitif -> Note car tous les examens avec le même score devraient obtenir la même note (ce serait plutôt injuste sinon), mais notez que nous ne pouvons pas dire Grade-> Score car plusieurs scores peuvent avoir la même note (11% et 12% serait probablement "Échec", par exemple).

Maintenant, votre relation est:

Notes ( StudentName, SubjectCode, SubjectName, #Exam, Score, Grade )

et vous avez une nouvelle forme de redondance puisque chaque fois que vous entrez un résultat avec le même score qu'un autre enregistrement de notes, vous devez également répéter la note correspondante. Pour arriver à 3NF vous pourriez donc vous décomposer en

ScoreGrades ( Score, Grade )

avec Score comme clé, et

Scores ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Vous avez raison dans tout ce que vous dites. Subject Code, SubjectName doivent aller dans leur propre table afin d'appliquer les dépendances souhaitées. C'est un bon exemple de la raison pour laquelle 2NF et 3NF ne sont pas suffisants pour produire de bonnes conceptions de base de données - vous avez plutôt besoin de Boyce Codd Normal Form (BCNF).

2NF et 3NF sont remplacés par BCNF, ce qui rend pratiquement obsolètes ces NF moins importantes *. BCNF est le plus important et sans doute le plus simple à expliquer et à appliquer. En tant que professeur, je vous suggère de passer plus de temps sur BCNF et moins sur 2NF et 3NF. Si une table satisfait aux exigences de BCNF, elle satisfait également 2NF et 3NF également.

* 3NF n'est pas la forme normale préservant les dépendances la plus élevée. La forme normale de la clé élémentaire (EKNF) est. À proprement parler, c'est EKNF, et non BCNF, qui rend le 3NF obsolète, mais EKNF est injustement négligé et la plupart des manuels et des cours ne le mentionnent même pas. Ce qui revient à la même chose, c'est de concevoir en BCNF puis de vérifier que toutes les dépendances souhaitées et toutes les autres règles d'intégrité peuvent être correctement appliquées - sinon, modifiez la conception. Aucune des NF n'est une solution complète à l'intégrité des données, mais BCNF est généralement le plus proche et est le plus facile à expliquer et à utiliser.

Je ne dirai pas combien de temps s'est écoulé depuis que j'ai appris tout cela pour la première fois. Mais je me souviens que j'avais un prof qui, après nous avoir consciencieusement enseigné le sens propre de "dépendance fonctionnelle" et "attribut non premier" et tous les autres mots à la mode, nous a posé une série de questions simples à poser pour voir si une normale particulière formulaire a été atteint. Voyons si je me souviens aussi loin ...

Nous avons identifié la ou les clés candidates. Nous posons donc cette question sur les attributs non premiers restants. Dans ce cas, il n'y en a qu'un: grade.

Quelles sont les informations minimales absolues dont nous avons besoin pour identifier de façon unique la note? Nous devons connaître l'étudiant, le sujet et l'examen qui sont passés. Très bien, c'est l'une des clés candidates.

EDIT: VVV

Mais la réponse aurait tout aussi bien pu être le nom de l'étudiant, le nom du sujet et l'examen. Cela correspondrait à la deuxième clé candidate.

En supposant que SubjectCode et SubjectName sont les deux clés candidates pour l'entité Subject, il n'y a aucune raison d'avoir ces deux champs ici. Une référence unique à une ligne du tableau Sujets suffit amplement. Nous pouvons donc nous débarrasser du champ SubjectName en toute sécurité sans sacrifier l'intégrité du modèle.

Cependant, dans ma réponse d'origine, dans mon désir de montrer un autre niveau de normalisation, j'ai ignoré que SubjectName avait été utilisé dans une clé candidate et l'ai considéré comme un autre attribut non premier. Je suppose que c'était tellement évident pour moi que c'était un domaine inutile, je pensais que ce serait tout aussi évident pour tout le monde et puisque de toute façon nous nous sommes débarrassés du champ, qu'importe?

Mais au lieu de supprimer cette partie de la réponse, je vais la conserver pour comparaison.

FIN DE LA MODIFICATION: ^ ^ ^

Quelles sont les informations minimales absolues dont nous avons besoin pour identifier de manière unique le nom du sujet?

SubjectName dépend uniquement de SubjectCode - un sous-ensemble de la clé candidate. Ce tuple n'est donc pas en 2nf. SubjectCode doit être la clé primaire d'une table Subjects, c'est donc l'emplacement approprié pour placer SubjectName. Supprimez-le de ce tuple et il est maintenant en 2nf.

Si nous posons la question d'un attribut et que la réponse n'est pas tout ou partie de la clé candidate, alors le tuple n'est pas en 3nf. Mais ce tuple est également trivialement en 3nf et au-delà, car nous n'avons plus de champs pour poser des questions. ;)

Remarque: lorsque nous disons "normaliser", nous faisons référence à un processus qui est appliqué à une entité logique. Comme le tuple fourni semble être la définition d'une entité appelée "grade", nous pouvons alors le normaliser. Cependant, à un moment donné, j'ai dit «ce tuple n'est pas en 2nf», ce qui aurait dû être plus correctement, «cette entité n'est pas en 2nf». Je m'excuse si cela a causé de la confusion.

Le seul attribut non premier (Grade) ne dépend pas d'une partie d'une clé candidate, ce tableau semble donc en 2NF.

C'est en 2NF.

Le problème est que je pense que quelque chose ne va pas (et je peux me tromper). Je pense que les sujets devraient avoir leur propre table.

Il n'y a aucune raison de s'attendre à ce que les sujets aient leur propre tableau pour une décomposition du tableau original en 2NF . Vous confondez une vague notion de «devrait» avec ce que vous donne réellement une forme normale particulière.

3NF concerne les dépendances entre les attributs non premiers, il ne produit donc pas cela non plus.

"3NF concerne les dépendances entre des attributs non premiers" n'est pas une définition correcte de 3NF donc "donc il ne produit pas cela non plus" n'est pas une bonne conclusion. Bien que l'application d'une définition réelle montre que la table est en 3NF, aucune table d'élève n'est nécessaire. Mais encore une fois, il n'y a aucune raison de s'attendre à ce qu'il y en ait.

Mais il me semble que c'est le bon résultat, car il n'y a pas de redondance.

Encore une fois, la «redondance» est d'une vague inutile, donc votre «parce que» et les attentes de la table des étudiants ne sont pas valables. Différentes formes normales sont exemptes et sujettes à des types particuliers d' anomalies et de "redondance" associée. Mais d'autres «redondances» non traitées par la normalisation peuvent subsister.

Cette table n'est pas en BCNF, car elle contient des FD qui ne sont pas en dehors des CK. La décomposer par BCNF conduit à avoir la table des étudiants. BCNF est la forme normale la plus élevée pour traiter les JD (joint dependencies) qui accompagnent les FD. Cependant, d'autres JD peuvent être problématiques (c'est-à-dire non "impliqués par les CK") et doivent être supprimés par normalisation à 5NF.

PS Le tableau d'origine satisfait également le FD {StudentName, SubjectName, #Exam} -> Grade.

Les dépendances sont de cette façon:

Qu'est-ce que cela signifie? Ce n'est pas clair.

Voulez-vous dire, "Ce sont tous les FD non triviaux qui détiennent"? Non, car ils impliquent le quatrième. "Voici quelques FD qui tiennent"? Non, cela signifie que les FD dans la fermeture transitive tiennent, mais cela ne dit pas que d'autres ne tiennent pas , pourtant vous avez pu déterminer les CK. "Les FD qui tiennent sont exactement ceux de la fermeture transitive de ceux-ci"? Si vous vouliez dire cela, vous ne le sauriez que si vous l'aviez montré , c'est-à-dire que vous auriez dû trouver cette fermeture (généralement, via une couverture minimale / canonique) et montrer ensuite qu'il n'y a pas d'autres FD; as tu? Quoi qu'il en soit, ce que vous avez écrit ne signifie pas cela. J'espère donc que vous ne raisonnez pas à fond sur la situation FD & CK.

Vous avez raison, le sujet nécessite sa propre table. Si vous choisissez l'une de vos clés candidates, l'une subject_codeou l' autre subject_namedevient ou devient une clé candidate non principale. Vous supprimez ensuite le champ des sujets non principaux du tableau des notes.

Vous avez une dépendance fonctionnelle sur le sujet pour lequel vous avez deux identifiants uniques. Ceci est démontré par la dépendance transitive entre subject_codeet subject_name. Cela indique la nécessité de créer une table contenant ces deux champs et de supprimer l'un de ces champs de toutes les autres tables. Cette table pourrait bien avoir des colonnes dépendantes supplémentaires, bien que je n'en vois aucune dans cet exemple. En 3ème forme normale que vous avez sélectionnée.

la note dépend des trois autres champs (clé candidate) dans le nouveau tableau de notation. Comme indiqué ci-dessus, vous devez sélectionner l'un des champs candidats pour le tableau des sujets. Normalement, ce serait une valeur de code si disponible car ils ont tendance à être plus stables. Le modèle résultant est en 3nf car tous les champs non clés dépendent entièrement des champs de la clé primaire.

Une analyse plus approfondie du problème (exigences) est susceptible de produire un tableau de sessions sur lequel les notes sont appliquées. Il est peu probable que le modèle actuel couvre un étudiant qui répète un cours. Cela serait abordé dans une leçon ultérieure.

Les étudiants sont également susceptibles de devenir une table séparée car il est possible d'avoir plusieurs étudiants avec le même nom. Ce problème serait probablement résolu par l'ajout d'une clé primaire synthétique (numéro d'étudiant?).

subjects --->  sessions ---+--> grades
students  -----------------+

Je me prépare à le supprimer car il est considéré comme incorrect

Le nom de sujet est également un attribut non principal et il dépend d'une partie du code de sujet de la clé primaire (rompt la règle - il ne doit pas y avoir de dépendance partielle d'une colonne sur la clé primaire).

Ceci est interdit dans la 2ème forme normale et doit donc être placé dans sa propre table comme vous l'avez suspecté.

Je pense que là où vous avez décollé, c'est en identifiant deux ensembles de clés candidates, lorsque vous créez la table, vous devez choisir un ensemble de clés candidates pour créer la clé primaire. Les colonnes restantes deviennent des attributs non premiers, c'est-à-dire que si vous choisissez votre deuxième clé candidate, le code sujet devient un attribut non premier dépendant d'une partie de la clé primaire (nom du sujet) et doit être placé dans sa propre table.

Il est important d'enseigner les 1re, 2e et 3e formes normales dans l'ordre où elles s'appuient les unes sur les autres. Le BCNF est également essentiellement une extension à la 3ème forme normale, donc une bonne compréhension des niveaux inférieurs est essentielle.

Plus loin; un développeur expérimenté ne considérera pas les niveaux indépendants de normalisation car de nombreuses règles deviennent intuitives.

Ils sauront également quand enfreindre les règles de normalisation pour résoudre certains problèmes de conception et d'optimisation. La normalisation devrait être considérée comme un guide pour une bonne conception et non comme une règle stricte, je pense que ce serait également un bon point d'enseignement.