Relations InterTables

Bonjour,

Je pense avoir mal structuré mes tables, et avoir géré tout aussi mal les relations entre les tables.

Organi_PdT.odb (43.0 KB)

Je veux organiser l’apprentissage de mes élèves par Plan de Travail.

Un plan de travail se définit par une matière
(Exemple Maths)
Cette matière va donner lieu à un découpage en Domaines et leur identifiant (une lettre de l’alphabet)
(Exemple: A. Nombres et Calculs)
Ce domaine va donner lieu à des Sous domaines et leur abrégé
(Exemple: Nombres NUM)

Et donc, ce plan de travail va présenter une liste de leçons et des exercices associés (une leçon donnera lieue à plusieurs exercices, pas l’inverse).

C’est exactement dans la création des leçons, et par la suite, des exercices que je coince.

Tout ce beau monde a sa table:
Matière, domaine, sous-domaine, leçon, exercice.

J’ai pensé que, en terme de recherches, il était intéressant que les leçons aient les informations au sujet de la matière, du domaine et du sous domaine, alors que dans les faits, en terme d’organisation, la leçon n’a besoin que du sous domaine, car le sous domaine appartient à un domaine, qui lui même appartient à une matière, et qu’un sous domaine ne peut pas appartenir à deux domaines.

Ainsi, au niveau de mes relations et de mes tables dois-je bannir les appels systématiques aux parents des parents ?

Je suis le nez dedans, et la question me semble évidente, mais par expérience, je sais que notre problème, n’est pas celui d’un autre, et que les explications doivent être bien détaillées. Ainsi, par avance je m’excuse si je ne suis pas clairs, et je repasserai dans quelques minutes pour reformuler.

D’avance merci pour votre lecture.

La question importante, c’est "pour quoi faire ? ".
C’est à dire : que devra produire l’interface ?
Une aide à la construction du plan de travail ?
Tous les exercices d’une leçon doivent-ils faire partie du plan ?

En fait, il faudrait définir un cahier des charges plus précis, avec un exemple.
J’entrevois un choix avec des listes déroulantes liées entre elles…
Bonne journée…
JM

La question est la bonne: pour quoi faire… C’est justement pour ça que j’ai choisi de simplifier pour l’instant ma base de données en réalisant un seul lien entre chacune des tables, mais je risque de m’en mordre les doigts par la suite.

In fine, un élève aura un plan de travail avec un nombre d’exercices définis dans chacun des domaines. Ce plan de travail sera renouvelé tous les 15 jours.
Ainsi:

  • Les élèves doivent pouvoir saisir leurs scores obtenus à chacun des exercices.
  • Je dois pouvoir choisir 1 élève et obtenir la liste des exercices qu’il a fait et des scores qu’il a obtenu.
  • Je dois pouvoir ajouter/enlever/modifier des noms d’exercices et de leçons à tout moment.
  • Je dois pouvoir avoir ma liste complète d’exercices et de leçons liées.

Question de rapidité d’accès des données, je pense qu’il est plus malin d’avoir la donnée “code de l’exercice complet” dans la table exercices, plutôt que de devoir faire remonter les données de clés primaires en clés primaires. Mais j’aurais une plus grande souplesse dans mon ajout de données en faisant du ricochet de clés primaires.

Mais peut être me trompe-je…