Restructuring database
From ClaroDevel
| Table of contents |
Foreword/Avant propos
- The goal of this document is not show the future structure of the database of Claroline. There is no way to guarantee that the future database will actually be like that. I am currently working on the restructuration of the database for my thesis, and my work is not yet over. I post it today on the wiki as a work basis for the main development team (IPM and Cerdecam), and for critics.
The following document will be in French, simply because it is easier for me, so please accept my apologies.
Thank you for your comprehension.
- Le but de ce document n'est pas de montrer la future structure de la base de données de Claroline. Je ne peux pas garantir que la future base de données sera reprise ainsi. Je suis en train de travailler sur la restructuration de la base de données dans le cadre de mon mémoire, et mon travail n'est pas fini. Si j'écris ce document sur le wiki aujourd'hui, c'est pour donner à l'équipe de développement principale (IPM et Cerdecam) une base de travail et pour les critiques de mon travail jusqu'à présent.
La suite sera en Français, pour des raisons de facilité. J'utilise la structure mono-DB pour mes explications, avec le préfixe cl_ pour les tables principales, et c_xx_ pour les tables de cours où xx est le code du cours.
Merci de votre compréhension.
Normalisation de la base de données
Respect des formes normales
Les formes normales sont les étapes, les états qui doivent être vérifiés par les tables de la base de données afin d’obtenir une base de données avec des relations simple et dans une forme permettant de limiter les pertes, les redondances d’information et les incohérences, et d’augmenter les performances de traitement. Afin qu’une base de données puisse être considérée comme normale, il faut qu’elle respecte au moins les 3 premières formes normales. D’autres formes normales supplémentaires existent, telles que celle de Boyce-Codd, la 4ème et 5ème forme normale.
1ère forme normale
Chaque entrée de la table doit être atomique, c'est-à-dire qu’elle ne peut pas être multivaluée ou répétitive. De plus, chacune des tables doit avoir une clé primaire ou unique identifiant chaque tuple indépendamment.
Le respect de cette forme normale permet d’avoir des données plus facilement et plus rapidement accessibles, car cela évite de devoir faire des recherche à l’intérieur même des entrées.
Pour bien faire, chacune des tables ayant des entrées dates ou heures devraient être décomposées en jour/mois/année, heure/minutes/secondes, mais ce ne devrait être fait que si cela peut conduire à une fonctionnalité désirée, car cela augmenterait la taille du code.
Tables qui ne sont pas de la première forme normale
La table c_xx_wiki_acls n’a aucune clé.
Solution possible: faire un clé primaire composée depuis les attributs wiki_id et flag. Cela permettrai d'atteindre également la 3ème forme normale, alors que si on rajoute un champ id, cela ne serait pas le cas. Par contre, avec le champ id, on dispose toujours d'un champ auto-incrémental, ce qui permet de garder l'ordre d'apparition dans PhpMyAdmin.
Les entrées authors de la table c_xx_wrk_submission sont parfois multivaluées.
Solution possible : pas de solution possible pour l’instant (pas désirée ?), car lors de la soumission d’un travail, l’utilisateur doit rentrer tous les auteurs dans un seul champ de texte.
Le domaine titulaires de la table cl_cours n’est pas simple (il est composé d’entrées multivaluées). Même chose pour les e-mails.
Solution possible : pas de solution possible pour l’instant (pas désirée ?), lors de la création d’un cours, le créateur du cours doit entrer le nom du gestionnaire de cours en un seul champ de texte.
Les entrées ressource_id de la table cl_notify sont parfois multivaluées.
Solution possible : pas de solution possible pour l’instant. On pourrait imaginer d'utiliser le linker. Il suffirait alors de se baser sur le course_code (ou un course_id) et l’id de la ressource dans c_ xx_lnk_resources.
2ème forme normale
Afin d’atteindre la seconde forme normale, il faut que les tables soient de la première forme normale, et aucun attribut ne peut être déterminé par seulement une partie de la clé identifiant les tuples. La vérification du respect de la seconde forme normale ne se fait donc que pour les tables possédant des clés composées.
Les tables concernées sont c_xx_quiz_answer, c_xx_quiz_rel_test_question et cl_cours_user, et c_xx_wiki_acls si la solution pour la rendre de la première forme normale est appliquée.
Toutes ces tables respectent la seconde forme normale.
Le respect de cette forme normale permet de prendre en compte certaines dépendances fonctionnelles.
3ème forme normale
Afin d’atteindre la troisième forme normale, les tables doivent être dans la seconde forme normale, et aucun élément ne faisant pas partie de la clé ne peut être déterminé par un élément non clé.
Le respect de la troisième forme normale permet de retirer les anomalies d’insertion, de suppression et de mise à jour dues aux dépendances transitives (dépendances indirectes par rapport à la clé primaire) et dépendances fonctionnelles entre éléments non clés.
Tables qui ne sont pas de la troisième forme normale
Les attributs nom et prenom devraient provenir de la table user. Or ce n'est pas le cas. Dans le forum PhpBB de Claroline, le poster_id vaut soit 1 (loggué), soit -1 (non loggué). Ce problème se retrouve aussi dans la table topic_poster.
Solution possible : on pourrait se contenter du champ poster_id, qui mène au champ user_id de la table cl_user pour retrouver les informations sur le nom et le prénom. Il faudrait cependant modifier le code de phpbb pour qu’il aille chercher les informations dans la table cl_user plutôt que dans la table c_xx_bb_posts. Par contre, cela provoquerai des erreurs en cas de suppression de l'utilisateur. Son nom et prénom seraient du coup perdus pour le forum. Ce problème de 1 et -1 n'apparaît pas dans PhpBB 2.0.17 par exemple. Dans PhpBB 2.0.17, le poster_id apparaît dans la table post et la table topic, et si le poster_username apparaît bien dans la table post, ce n'est apparemment que pour les invités. Par contre, si l'on supprime un user de la table de données, tout ses messages disparaîtront du forum, même si ils sont toujours présents dans la base de données.
Les attributs status et role de la table c_xx_group_rel_team_user dépendent des attributs non clés user et team, qui eux dépendent de id. Donc status et role dépendent transitivement de la clé.
Solution possible : Enlever si possible la clé id, et créer une nouvelle clé primaire composée par les attributs user et team
Les attributs lock et visibility se rapportent aux attributs module_id et learnpath_id, qui eux dépendent de learnpath_module_id, ce qui provoque de la dépendance transitive dans la table c_xx_lp_rel_learnpath_module.
Solution possible : le champ learnpath_module_id est utilisé comme clé étrangère dans la table c_xx_lp_user_module_progress, en même temps que learnpath_id. On pourrait envisager d'enlever la clé learnpath_module_id et la remplacer par une clé composée de module_id et learnpath_id.
Dans la table c_xx_lp_user_module_progress (dont le nom est peut-être mal choisi, vu que le module_id n’apparaît pas). La clé user_module_progress_id n'est pas nécessaire, sauf éventuellement si l'on souhaite un champ auto-incrémental. La plupart des attributs (lesson_status, entry, raw, scoreMin, scoreMax, total_time, session_time et credit) semblent dépendre de user_id, et également de module_id. ScoreMin et ScoreMax se trouvent dans cette table et non dans la table c_xx_lp_rel_learnpath_module_id apparemment pour respecter la norme SCORM. Seuls les attributs lesson_location et suspend_data semble dépendre directement de la clé primaire.
Solution possible : on pourrait envisager de supprimer lp_module_id et de créer une clé composée de user_id, module_id et learnpath_id. Vérifier dans les documents sur SCORM si tous les éléments dépendent bien de l'entièreté de la clé, donc si la seconde forme normale est bien respectée.
Dans la table c_xx_track_e_access, les éléments acess_tid et access_tlabel sont redondants.
Solution possible : n’en garder qu’un des 2.
Tables où j’ai des doutes
- c_xx_track_e_exercices : exe_result dépend-t-il de exe_user_id et exe_exo_id, exe_weighting dépend-t-il de exe_exo_id ?
- cl_admin: probablement supprimable si l'on insère le concept de profil.
- c_xx_group_property: 1 seul enregistrement par cours. Cela donne les outils à mettre en place par défaut lors de la création d'un groupe. Pas de solution envisagée pour le moment. Peut-être une table principale contenant un identifiant de cours puis tous les outils à mettre en place lors de la création d'un cours, mais est-ce que les créateurs de cours y auront accès?
Note à propos des champs incrémentaux:
Normalisation des noms et anglicisation
Voir ici: http://www.claroline.net/wiki/index.php/Projet_de_restructuration_de_la_base_centrale
Normalisation des types de valeurs de champs
PS: Je n'ai regardé pratiquement que les clés primaires et étrangères.
- c_xx_lp_user_module_progress:
- user_id= mediumint(9), or dans cl_user: user_id= int(11)
- c_xx_track_e_access:
- user_id= int(10)
- tid (tool du cours)= int(10), or dans c_xx_tool_list, l'id est un int(11)
- c_xx_track_e_downloads:
- user_id= int(10)
- c_xx_track_e_exe_details:
- question_id= int(10), dans c_xx_quizz_question, c'est mediumint(8)
- c_xx_track_e_exercices:
- user_id= int(10)
- exe_exo= tinyint(4), dans c_xx_quizz_test, l'id est un mediumint (8)
- c_xx_track_e_uploads:
- user_id= int(10)
- c_xx_userinfo_content:
- user_id= mediumint(8)
- cl_config_file:
- config_code= varchar(30), et claro_label vaut varchar(8) ailleurs, à moins que config_code et claro_label ne soient pas en lien.
- cl_notify:
- ressource_id est un varchar(255). Il faut dire aussi que les ressource_id varient selon les outils, et que les notification pour l'outil document se fait à partir d'un url.
Propositions de modifications
Partage et instanciation des cours
Afin de pouvoir partager un outil entre les cours, on pourrait procéder comme suit. Par contre, les ressources dans leur état actuel ne permettent pas le partage des ressources.
On passe également à un mode mono-db vrai.
Ajout des modules
Rajout au schéma précédent des modules.
Ajout des profils
Rajout au schéma précédent des profils utilisateurs. Attention, c'est encore l'ancienne version des droits d'utilisateurs. La nouvelle se trouve ici: http://www.claroline.net/wiki/index.php/Claroline_18_right_profile
