Cette structure de base de données est-elle saine, correcte et normalisée?

Question

Donc, hier, j'ai posé 2 questions qui tournaient autour de la même idée: Réorganiser une base de données qui A- n'était pas normalisée et B- était un gâchis en vertu de mon ignorance. J'ai passé la plus grande partie de la journée à organiser mes pensées, à lire et à passer quelques tests. Aujourd'hui, je pense avoir une meilleure idée de la façon dont ma base de données devrait se comporter et agir, mais je voulais m'assurer que je comprenais les idées fondamentales des processus de conception et de normalisation de bases de données SQL. À l'origine, j'avais une table appelée "Fichiers" qui contenait des données sur un fichier (URL, date de téléchargement, identifiant de quiconque l'a téléchargé, etc.) ainsi qu'une colonne appelée "grades" qui représentait le niveau de qualité pourrait utiliser ce fichier pour. (FYI: Ces fichiers sont des plans de cours pour les écoles) Je me suis rendu compte que j'avais enfreint la Règle n ° 1 sur la normalisation - Je stockais mes "notes" comme ceci "1,2" ou "2,6" ou "3,5,6 "dans une colonne. Cela a causé d'importants maux de tête en essayant d'analyser ces données si je voulais voir des leçons de 3e année ou des leçons de 5e année.

Ce qui a été suggéré pour moi, et ce qui est devenu évident plus tard, était que j'ai 3 tables:.

fichiers (données sur les fichiers, URL, etc.) notes (un tableau des niveaux de qualité disponibles probable 1 -6 pour commencer) files_grades (une table de jonction)

Cela a du sens. Je veux juste m'assurer de comprendre ce que je fais avant de le faire. Supposons que l'utilisateur A télécharge le fichier xyz et décide qu'il est bon pour les classes 2 et 3.

J'écrirais un enregistrement dans la table "files" avec des données sur ce fichier (taille de kb, url, description, nom, primaire key files_id). Disons qu'il obtient id 345.

En raison du nombre limité d'options de qualité, les notes seront probablement équivalent à leur carte d'identité (c.-à-grade 1 est grades_id 1, 2 e année est grades_id 2)

I'D puis écrire deux enregistrements à la table de jonction "de files_grade" contenant

files_grade_id, files_id et grades_id-à-dire

1,345,2

1,345,3

Pour représenter les 2 notes pour lesquelles files_id 345 est bon. Ensuite, j'agite ma magie SELECT et JOIN baguettes et tirer les données dont j'ai besoin.

Est-ce que cela a du sens? Ai-je, encore une fois, mal compris la structure appropriée d'une base de données relationnelle plusieurs-à-plusieurs?

Problème 2 qui me vient à l'esprit: Ainsi, une leçon peut avoir plusieurs «notes». Pas de problème, nous venons de résoudre ça (j'espère!). Mais il pourrait, en théorie, avoir de multiples «écoles»: élémentaire, moyen, élevé. Que faisons-nous si une entrée de fichiers a des notes de 1,2 pour Middle, High? Cela pourrait très facilement être résolu en disant "Une école par fichier, les utilisateurs!", Mais j'aime bien le dire.

Answer 1

Du son, ça sonne plutôt bien. Juste une chose, cependant: vous n'avez pas vraiment besoin d'avoir un ID pour la table de pont (FILES_GRADES), et si vous le faites, vous devez incrémenter l'ID.

Vous auriez une clé primaire en deux parties: grade_id et file_id, le files_grade_id ne fait que compliquer les choses, et ferait un mauvais index, puisque vous ne l'utiliseriez jamais dans un select.

Answer 2

je puis écrire deux enregistrements à la "files_grade" table de jonction contenant

files_grade_id, files_id et grades_id-à-dire

files_grade_id ici est redondant, car la combinaison de files_id et grades_id est déjà unique (il peut donc être défini comme clé primaire).

Mais il pourrait, en théorie, avoir plusieurs "écoles" aussi bien: élémentaire, moyen, élevé. Que faisons-nous si une entrée de fichiers a des notes de 1,2 pour Middle, High?

En fonction de vos besoins, vous pouvez éventuellement stocker ceux-ci en tant que "suites" des grades précédents, par ex. 1-6 élémentaire, 7-9 moyen, 10-12 élevé. Ensuite, vous pouvez faire sans la table grades complètement (puisque vous pouvez simplement stocker ces numéros dans le tableau files_grade).

Answer 3

Depuis que vous avez déjà répondu à la première question, je vais prendre un coup à la deuxième question.

Il y a plusieurs façons de le faire, mais une possibilité est d'ajouter une autre table pour les "écoles" et de l'inclure dans la table de jonction - renommer la table de jonction pour correspondre au nouveau design. Ainsi, vous pourriez avoir:

School Table: 

------------------------- 
    SchoolId | School 
------------------------- 
    1  | Elementary 
    2  | Middle 
    3  | High 
------------------------- 

Files_grades_school 

------------------------------------ 
    FileId | GradeId | SchoolId 
------------------------------------ 
    345 |  1  |  1 
    345 |  1  |  2 

Vous voudrez probablement créer plusieurs index en fonction de vos habitudes d'utilisation.