Microsoft 365 - Conseils pour la structuration d'une base de données -

En pj, la macro modifiée correspondant au post #15.
Les 3 feuilles contenant les Tableaux intermédiaires (Professeur, Salle et Groupe) ne sont plus nécessaires.
Pour ne pas faire la mise à jour supprimer ou mettre en commentaires les lignes suivantes dans la macro RegenererCoursDegroupe
La feuille à utiliser pour toutes les analyses : CoursPourAnalyse.
Je n'ai pas fait de tests avec des TCD, Graphiques.

Bonsoir à tous,

Merci CroCroCro pour vos retours.

Je dois avouer que je planche sur vos retours depuis ce matin. J'y ai passé tout mon samedi pour essayer de comprendre ce qui m'échappait. J'ai regardé pas mal de cours sur les Bases De Données Relationnelles pour comprendre leurs mécanismes et pouvoir faire le lien avec vos propos.

Je pense avoir saisi l'essentiel à présent sur le problème que je rencontrais, grâce à vous deux (CroCroCro et CousinHub). J'ai pris une bonne dose de savoir et une bonne migraine aussi au passage je dois l'avouer !

J'ai pu construire ma première BDD de type relationnelle sur Excel. C'est en faisant cet exercice que j'ai compris les notions de classes, d'objets, d'attributs, de valeurs, d'associations, de cardinalités, de diagrammes et leurs relations, d'unicité des valeurs, de principe d'atomicité, etc. C'est carrément plus clair maintenant

En conclusion :
Il y a plusieurs manières de présenter les données d'entrées, qui peuvent être liées comme Groupe, Professeur et/ou Salle, afin de les analyser finement ensuite. Il y a des avantages et des inconvénients sur ces solutions mais pas de grosse erreur de structuration des données finalement :

1. Je peux travailler sur la table initiale (celle qui contient toutes les données liées) mais j'aurais certaines entrées liées ce qui m'empêchera leur analyse fine.
2. Je peux créer une table intermédiaire avec toutes les données déliées en utilisant simplement l'attribut et la valeur de chaque classe. Cette approche permet l'analyse de chaque données déliées mais ne permet pas facilement l'analyse croisée des données car tout est sur le même plan (par exemple avoir le détail des heures pour un Professeur avec le Groupe et la Salle associée).
3. Je peux créer une table intermédiaire contenant à la fois les données initiales liées mais aussi les données déliées pour les champs Groupe, Professeur et Salle. Cette approche permet l'analyse de chaque données déliées et permet l'analyse croisée des données comme je le souhaite.

Merci vraiment beaucoup pour le temps que vous avez accordé à mon sujet. C'est super sympa à vous

Belle soirée.

Bonjour Sérieux et Cool,
Je profite de vos nouvelles connaissances sur les bases de données relationnelles pour vous faire part de quelques réflexions.
Un des avantages des BDR est d'assurer la cohérence des données, par exemple, entre les tables Cours et Salles si la relation (la jointure) est faite avec pour identifiant de la Salle (la clé), un n° d'ordre par exemple (identifiant non fonctionnel donc), si on change les informations d'une Salle, (Son nom, sa localisation ...) il n'y aura aucun impact sur les Tables Connexes, ici la Table Cours.
L'interrogation multi-tables de la BD par le jeu des relations est très performante avec un SGBDR (Système de Gestion de Base de Données Relationnelles) bien construit .
A noter qu'Excel n'est pas un vrai SGBDR qui, dans le cas de gros volumes de données, en attaquant des tables en cascade pourra se monter peu performant.

La BD Cours sera-t-elle modifiée souvent ?
Les données d'analyse doivent-elles être synchrones avec celles de la BD ?
Si ce n'est pas le cas, il peut être intéressant de dénormaliser la BD pour en améliorer les performances pour l'analyse (TCD, Graphiques ...).
C'est ce qui est fait lors de la génération du Tableau de la Feuille CoursPourAnalyse.
Cela vaut-il le coup ?
La réponse ne peut être apportée qu'en faisant des tests sur des volumes importants avec les 2 options.

En PJ, le fichier avec des TCD, Graphiques basiques basés sur le Tableau de la Feuille CoursPourAnalyse et quelques retouches (comme par exemple la ligne Total du Tableau de la Feuille CoursPourAnalyse qui s'actualise automatiquement en filtrant sur l'une et/ou l'autre colonne du Tableau)

Bonjour à tous,

@crocrocro : merci pour ton message privé

Merci également d'avoir pris le temps de proposer une amélioration du fichier Excel initial. C'est bien vers ce type d'analyse que j'aimerais aller plus tard. Peu importe la forme (TCD, tableur, SGBDR, etc.) mais c'est bien l'analyse des données croisées de manière générale.

Merci également d'avoir proposé des pistes de réflexions pour aller plus loin sur ma demande initiale. J'ai donc continué sur tes conseils sur la découverte des SGBDR. J'ai le cerveau en ébullition car j'ai l'impression de découvrir le vrai monde des SGBDR alors qu'avec mon approche initiale sur Excel...je n'étais pas du tout dans cette logique ! Comme toute découverte d'un outil, j'ai souvent plus de questions que de réponses. Je dois composer avec des hypothèses et des intuitions car la théorie arrive petit à petit. Je manque d'expérience et donc de savoir-faire. Qu'importe je progresse un peu plus encore dans la modélisation de mon problème.

Je partage quelques constats à ce stade :

1. Le classeur Excel que j'ai posté initialement et qui contenait des données liées (plus précisément des enregistrements, dont certains champs comportaient des valeurs multiples (des champs multivalués si on peut dire) que l'on pourrait d'ailleurs considérer comme une table dénormalisée) n'a rien d'une base de données au sens SGDBR. Ce n'est qu'une collection de données sans structure, présentées dans un tableur Excel. Ce n'est pas une base de données ! J'en ai conscience maintenant.
2. Le classeur Excel que j'ai posté s'apparenterai presque au résultat d'une requête. "Je cherche le nombre d'heures réalisé par un groupe d'étudiants." -> Pour y arriver : collection des données utiles dans Excel, bidouilles pour les arranger les données et analyse par TCD. C'est un peu le fonctionnement classique d'une majorité d'utilisateurs d'Excel en fait. C'est très rapide à produire tant que l'usage reste ponctuel, éphémère. On prend la valeur du TCD et on part avec faire autre chose. Ça fonctionne très bien dans cet usage "de consommation de l'information utile le plus rapidement possible". Mais dans mon cas, et pour la première fois de ma vie, je sens bien que je suis à la limite entre utiliser le tableur Excel et/ou le SGBDR d'Access.
3. Pourquoi ? Comme le souligne CroCroCro, mon idée est de faire vivre cette base de données avec des modifications, des ajouts et des suppressions régulières. Je sens bien qu'avec Excel, je vais arriver à construire la feuille comportant toutes les données comme je le souhaite...mais que dès lors que je devrais y apporter des modifications je vais stresser en me disant "est ce que je suis certain que ma modification s'est propagée de partout ?"Et forcément, le jour arrivera où à force de modifier les données...l'intégrité sera perdue. Je sens bien que sera très compliqué de retrouver les erreurs et de tout corriger.
   • A ce stade, j'ai le sentiment que si je reste sur Excel, ce sera plus confortable mais que ça ne tiendra pas la route dès que j'aurais acquis les nombreuses données des utilisateurs. N'ayant plus la confiance, les utilisateurs ne seront pas convaincus d'alimenter cet outil s'il n'est pas exempt d'erreur. Pour un utilisateur, soit l'information est "carrée", sinon on passe à autre chose.
   • Si je passe sur Access, je vais y passer des semaines, mais je pourrais peut-être obtenir un outil robuste qui servira dans le temps.
   • Là est mon dilemme : m'engager sur un terrain que je ne connais pas avec Access et dont je ne sais pas s'il pourra répondre à mes exigences ou bien rester sur un outil Excel qui pourrait faire le job comme on dit mais qui sera forcément limité.

Je partage quelques exemples concrets sur l'utilisation d'Access :

• L'ajout d'informations :
  • Dans Excel, je peux indiquer le nom de la salle (Salle1, Salle2, etc.). Cette salle se trouve dans une liste déroulante et c'est parfait pour la sélectionner dans d'autres feuilles. Sauf que si je souhaite compléter le niveau d'information d'une salle (comme sa localisation, sa capacité, etc.), c'est tout de suite plus délicat sur Excel. J'aurais une feuille qui va passer de quelques colonnes à beaucoup trop pour permettre un usage raisonnable.
  • Dans Access, j'ai une table salle dans laquelle je peux mettre autant d'informations que je souhaite pour décrire une salle. La propagation des données est immédiate et toutes les autres tables connectées disposent de l'information à jour.
• La structure logique des données :
  • Dans Excel, j'ajoute les données dans des colonnes sans me poser la moindre question du lien entre cette données et une autre. J'en ai besoin, je l'utilise à l'endroit que je veux. C'est simple, et adapté lorsque l'on a quelques colonnes affichées à l'écran. Après, on passe notre temps à scroller de gauche à droite et ce n'est plus efficace.
  • Dans Access, les diagrammes conceptuels de type MCD/MLD me forcent à regrouper les données dans des familles/classes. Et c'est tellement plus logique à la fin ! Par exemple, j'ai une table de salle :
    • Je peux ajouter un nouvel enregistrement de salle simplement
    • Je peux modifier les valeurs d'un champ de données d'une salle facilement
    • Je peux ajouter de nouveaux champs d'information pour toutes les salles
    • Je ne le fais qu'une fois, à 1 endroit évident, et tout se propage partout automatiquement, de manière logique et structurée
• La notion de clés primaires et/ou secondaires :
  • Dans Excel, j'ajoutais un ID de manière systématique pour un usage de tri des données. Je n'ajoutais qu'un seul ID car je n'avais qu'une seule "table" in fine. Je ne vérifiais jamais que les données étaient uniques et/ou orphelines. Par exemple si je supprime une salle existante dans ma liste déroulante, les feuilles Excel ayant utilisées cette salle comme valeur d'enregistrement seront toujours présentes dans les cellules. Même chose si je décide de corriger l'orthographe d'un Professeur dans ma liste déroulante, il faudra corriger partout dans les autres feuilles à la main. Il est facile de supprimer des données, difficile de se rendre compte de l'erreur que cela génère plus tard. Et pratiquement impossible à corriger une fois que l'on s'en est rendu compte. C'est pratiquement foutu. Les données se sont mélangées, ne sont pas actualisées, la base devient corrompue et inexploitable. Il est facile de tout casser et de perdre la confiance des données d'entrée.
  • Dans Access, la création d'une première table avec une clé primaire qui peut être reliée à une seconde table grâce à cette clé unique...est juste formidable. Toutes les données sont actualisées. Il est difficile de faire des bêtises pour tout casser car le système alerte systématiquement et empêche l'utilisateur de commettre des erreurs. C'est beaucoup plus robuste, c'est carré.

En conclusion, réaliser mes premiers pas avec Access n'a pas été chose facile comme je le prévoyais. Mais force est de constater, qu'en essayant de reproduire sur Access la même chose que je fais sur Excel est plus logique maintenant. J'obtiens le même résultat de présentation des données...mais avec un niveau de sécurité qui accompagne les SGBDR depuis des décennies.
Je suis venu demander des conseils sur la structuration d'une base de données. Au départ sur Excel, maintenant j'ai envie de poursuivre sur Access pour voir à quel endroit je vais être limité/bloqué par l'outil. Comme on dit, les fondations sont importantes avant de bâtir.

A noter : je ne suis pas persuadé qu'Access me permette de réaliser tout ce que j'ai en tête mais on verra bien.

J'espère que ce partage pourra donner envie à des lecteurs de franchir le même pas que moi : comprendre et avoir conscience de ce que sont les SGBDR et surtout de ce qu'ils font et comment ils le font en s'entrainant pour le découvrir. C'est comme ça que j'ai compris certaines choses même si je reste débutant/amateur.

J'ai quelques questions concernant Access. Du coup, comme c'est la suite de ce sujet, je vais donc continuer ici pour que ce soit plus logique pour les lecteurs intéressés. Sinon j'ouvrirais une nouvelle discussion dédiée Access.

[Lien de téléchargement du fichier Access : https://we.tl/t-sFZ7OELGQn]
[Valable pendant 7 jours]

Après un grand discours, une question simple et courte^^

Dans Access, j'ai découvert les champs multivalués. Ces champs me permettent nottament d'ajouter plusieurs groupes, ou bien plusieurs professeurs, ou encore plus salles pour un même enregistrement. J'ai bien compris que ce type de champ est adapté pour les novices qui auront plus de facilité à structurer les données de cette manière plutôt que de travailler avec des tables de jonctions. J'ai également compris qu'il y a des avantages et des inconvénients à utiliser les champs multivalués. Un désavantage notament est lié à la performance des requettes lorsque les données sont nombreuses. Pour le moment, je ne me souci pas la performance, mais de la simplicité pour moi d'obtenir un premier résultat. Les champs multivalués me plaisent bien pour le moment. Pour mémoire, c'est exactement ce que je cherchais à faire dans Excel avec des tables de tables (des tableaux imbriqués dans d'autres tableaux). Donc j'adopte cette manière pour le moment.

Le fichier que j'utilise pour exemple est disponible en pièce jointe (le fichier ne passe finalement pas car il n'est pas du type autorisé par le site. Si je change l’extension du fichier, il reste trop volumineux quand même pour être chargé. Je dois poster un lien WeTransfert à la place. Désolé, ça va être compliqué de continuer ici pour Access). Ce fichier modélise la base de données proposée par CroCroCro dans son dernier post. Je comparerai Excel vs Access ainsi et j'aurais toujours un repère via Excel^^

Voici une capture de l'ensemble des relations :


Une vue des tables :












Question :
La table des cours contient 3 champs multivalués (Groupes, Professeurs et Salles). La table Groupe propose une relation de 1 à 1 (ou peut-être une relation de rien à rien ? Je ne sais pas). Tandis que la table Professeur propose une relation de 1 à n. La relation 1 à 1 se fait naturellement par Access, après avoir créé le champ multivalué. La relation 1 à n s'obtient en supprimant la relation initiale proposée par Access après avoir créé le champ multivalué, puis en faisant glisser à la main la relation entre la clé primaire de la table Professeur avec la table des Cours.

Les 2 fonctionnent pareil d'après mes tests. Quelqu'un pourrait il m'expliquer pourquoi j'ai réussi à créer 2 types de relations différentes, qui donnent le même résultat in fine. Une approche est-elle meilleure que l'autre ? Si oui, pourquoi ?

J'aimerais jsute comprendre ce que je fais afin de choisir la bonne approche et évoluer dans le projet.

Bonjour Très sérieux, Très motivé et cool,
comme la discussion vire à l'Access, je te suggère de créer une nouvelle discussion dans Autres Applications - Access. Tu pourras mettre un lien dans ton dernier post vers la nouvelle discussion.
Pour ta question et si j'ai bien compris

Quelqu'un pourrait il m'expliquer pourquoi j'ai réussi à créer 2 types de relations différentes, qui donnent le même résultat in fine. Une approche est-elle meilleure que l'autre ? Si oui, pourquoi ?

Cliquez pour agrandir...

tu as utilisé 2 modes opératoires différents mais tu as réalisé la même chose (en passant par 2 chemins différents).
J'ai utilisé Access il y a très longtemps, et je ne me souviens pas de cette fonctionnalité "champ multivalué".
En interne j'imagine qu'Access créé ce qu'on appelle une table de liens (0,n - 1,n), transparente pour l'utilisateur par exemple (avec pour identifiant des Profs P1, P2 .... et des Cours C1, C2 ... avec pour contenu
P1 C1 (professeur 1 Cours 1)
P2 C1 (professeur 2 Cours 1)
P1 C2 (professeur 1 Cours 2)
P1 C3 (professeur 1 Cours 3)
P2 C4 (professeur 2 Cours 4)
...

Bonsoir CroCroCro,

Je continue de réfléchir sur mon problème de structuration des données. J'avance lentement malheureusement, mais je ne lâche rien J'ai essayé de peser le pour et le contre entre Excel et Access comme outil de travail pour continuer. Pas facile, mais je propose de poursuivre les échanges sur cette section du Forum, sur Excel donc. Idéalement avec toi si tu as encore un peu de patience, d'envie et de curiosité sur ce sujet...

Je propose en pièce jointe un fichier Excel, qui est calqué sur ta dernière proposition CroCroCro. Dans ce fichier, on peut retrouver une nouvelle présentation des données d'entrée sous forme de tables relationnelles (toutes les feuilles de couleur rouge). C'est toujours un fichier Excel, donc pas une base de données au sens puriste. Cependant je trouve qu'il y a là une forme de progression entre mon fichier initial du premier post (qui contenait des données balancées en vrac) et ce dernier fichier qui tente de structurer l'information.

Voici quelques questions :

1. Est-ce que cette proposition de structure des données est finalement plus intéressante, ou pas ?
   J'ai essayé de proposer des tables bien séparées,
   
   • Contenant chacune des données atomiques, quand je le pouvais, chaque donnée en lien avec sa table respective,
   • Des ID uniques contrôlés par validation des données,
   • Un principe de mise en relation entre les tables via l'ID pour faciliter l'intégrité des données et leurs mises à jour. Si je change le nom d'un groupe par exemple, le changement se propage de partout dans les tables grâce à l'ID,
   • J'ai également créé certains liens entre les tables via Power Pivot de sorte que je puisse réaliser plus tard des TCD (au moins sur les champs 1 à n),
2. Est-il possible d'avoir le fichier Excel mis à jour avec les éléments de cahier des charges suivants ?
   
   • Comme les tables se retrouvent maintenant éclatées dans des feuilles, je suppose qu'il faut mettre à jour le bouton "Récupérer la sélection pour le cours courant" sur chaque feuille.
   • La feuille "Table_Cours" doit permettre la sélection multiple des Groupes, des Professeurs et des Salles. Chaque item récupéré (l'ID pour le coup, c'est-à-dire un nombre) sera séparé par un séparateur bien identifié dans le code VBA (une variable publique ?) de sorte que l'on puisse changer simplement si besoin. Je propose de partir sur le séparateur suivant ", " (virgule + espace).
   • La sélection multiple des Groupes, des Professeurs et des Salles doit prendre en considération l'ordre dans lequel les items ont été sélectionnés. Par exemple, si je choisis Groupe2 puis Groupe1, je dois logiquement obtenir la liste suivante "Groupe2, Groupe1". Je parle de sélectionner l'ID bien sûr donc un nombre, mais je donne l'exemple ici sur une valeur plus parlante, la valeur texte. Cette contrainte d'ordre sera expliquée un peu plus tard.
   • Toujours dans la feuille "Table_Cours", les colonnes en orange (H, I, J, K et L)se basent sur l'ID d'une table pour en retourner une valeur "humainement lisible". Sinon, la Table_Cours ne contiendrait que des ID numériques et c'est franchement illisible. Cela permet une sorte de contrôle une fois qu'un cours est renseigné.
     • A noter : pour les champs uniques de type ID_Matiere et ID_Planning, on peut passer par un RecherchV. Pour les champs multiples de type ID_Groupes, ID_Professeurs et ID_Salles, on peut passer par du VBA pour faire la transcription je suppose.
     • Par conséquent, on peut probablement appliquer le même traitement VBA pour les ID, qu'ils soient uniques et/ou multiples.
   • La construction de la feuille "CoursPourAnalyse(2)" peut être reprise sur le même principe proposé par CroCroCro. Il n'est pas utile de créer les feuilles intermédiaires de type CoursSalles, CoursGroupes et CoursProfesseurs. Seule la feuille de synthèse servira pour les TCD et évitera de se mélanger les pinceaux entre toutes les feuilles, en plus de réduire les données stockées. Point suplémentaire, la dernière colonne qui contient le type d'enregistrement, contiendra la valeur "Matières" en lieu et place de la valeur "" lorsqu'il s'agit de la table dégroupée sur les matières (qui est déjà dégroupée de base). Comme ça, sur les TCD, on pourra choissir la vue Matières, Professeurs, Groupes ou Salles.
   • La construction de la feuille "TCD(2)" peut être reprise sur le même principe proposé par CroCroCro.
   • L'ensemble des feuilles de couleur violet, qui représentent la version précédente de la structure des données sera supprimé pour faciliter la compréhension du travail.

Ce fichier deviendra la nouvelle base de départ et facilitera les échanges je pense.

@crocrocro : je pourrais rentrer dans le code de ton fichier pour l'adapter au nouveau fichier Excel. Premièrement je vais y passer encore des heures avec mon niveau, mais en plus je risque de dégrader ton code initial pour la suite. Je préfère encore comprendre le code après mise à jour. Tu sais que je suis volontaire sur ce projet et pas "client consommateur".

Bonjour Sérieux et Cool,

A nouveau, quelques questions à se poser et dont les réponses vont influencer les choix :

Qui fait les mises à jour de la BD ?
Tu as écrit dans le post 20

mon idée est de faire vivre cette base de données avec des modifications, des ajouts et des suppressions régulières.

Cliquez pour agrandir...

Si une seule personne, un utilisateur averti, toi, on aura moins d'exigence sur le contrôle de la saisie. Tu sais ce que tu fais, tu connais l'impact d'une modification de données sensible (un identifiant par exemple). En fonction du nombre et du rythme des mises à jour, de qui les fait, de l'ergonomie souhaitée, elles peuvent être faites directement dans le tableau ou passer par un userform.

Volumétrie, Fréquence et Type de mise à jour ?
Combien de lignes Cours seront créées par année ? A quel rythme se font les mises à jour ? tous les jours ? une fois par mois ?
Les Créations
Voir remarques plus haut.
Les Modifications
Comme les créations.
A noter : La modification d'un identifiant correspond en fait à une suppression d'enregistrement puis d'une Création avec le nouvel enregistrement.
Les Suppressions
Pour quels motifs doit-on faire la suppression ? Quelles tables sont concernées ?

Qui consulte directement la BD (les différentes Tables) ?
Si d'autres personnes, il suffit par exemple, de protéger les feuilles concernées par mot de passe

Les Questions de ton précédent post

J'ai essayé de proposer des tables bien séparées,
Contenant chacune des données atomiques, quand je le pouvais, chaque donnée en lien avec sa table respective,
• Des ID uniques contrôlés par validation des données,
• Un principe de mise en relation entre les tables via l'ID pour faciliter l'intégrité des données et leurs mises à jour. Si je change le nom d'un groupe par exemple, le changement se propage de partout dans les tables grâce à l'ID,

Cliquez pour agrandir...

Oui, avec les remarques qui suivent
Pour les identifiants, là encore, il y a plusieurs possibilités avec toujours la même question, est-ce que cela vaut le coup ?
Avec un identifiant technique (n° d'ordre), facile à créer, unicité assurée, performant. Mais peu parlant (c'est un euphémisme) quand on regarde la feuille Cours
Avec un identifiant fonctionnel (nom du professeur par exemple), plus ou moins facile à créer, pour assurer son unicité, signifiant. Mais, pose des problèmes d'intégrité de données si on doit le modifier. A n'utiliser que s'il est stable, par exemple le n° d'insee.
Avec un identifiant semi-fonctionnel, un compromis entre les 2 options précédentes, plus ou moins facile à créer, unicité assurée (si bien pensé), signifiant (si bien pensé). Un code composite, par exemple pour la Table Professeurs, pour Jean Aymard, AymartJ et en cas d'homonymie AymartJ1, AymartJ2. Pour la table Salle, cela pourrait être un code (S suivi du n° de Salle suivi du n° de l'étage), S001-2 à condition que le n° de salle soit stable sinon on se retrouve dans le cas d'un identifiant fonctionnel.

L'identifiant semi-fonctionnel me parait ici le meilleur choix :
Plus besoin des colonnes Noms de la feuille Table_Cours actuelle, ce qui évite de rafraichir leurs valeurs à chaque mise à jour des tables de référence.

• Comme les tables se retrouvent maintenant éclatées dans des feuilles, je suppose qu'il faut mettre à jour le bouton "Récupérer la sélection pour le cours courant" sur chaque feuille.
Oui
• La feuille "Table_Cours" doit permettre la sélection multiple des Groupes, des Professeurs et des Salles. Chaque item récupéré (l'ID pour le coup, c'est-à-dire un nombre) sera séparé par un séparateur bien identifié dans le code VBA (une variable publique ?) de sorte que l'on puisse changer simplement si besoin. Je propose de partir sur le séparateur suivant ", " (virgule + espace).
oui
Toujours dans la feuille "Table_Cours", les colonnes en orange (H, I, J, K et L)se basent sur l'ID d'une table pour en retourner une valeur "humainement lisible". Sinon, la Table_Cours ne contiendrait que des ID numériques et c'est franchement illisible. Cela permet une sorte de contrôle une fois qu'un cours est renseigné.
• A noter : pour les champs uniques de type ID_Matiere et ID_Planning, on peut passer par un RecherchV. Pour les champs multiples de type ID_Groupes, ID_Professeurs et ID_Salles, on peut passer par du VBA pour faire la transcription je suppose.
• Par conséquent, on peut probablement appliquer le même traitement VBA pour les ID, qu'ils soient uniques et/ou multiples.

Cliquez pour agrandir...

Avec ma proposition sur les identifiants semi-fonctionnels, ce point-là serait réglé.

La sélection multiple des Groupes, des Professeurs et des Salles doit prendre en considération l'ordre dans lequel les items ont été sélectionnés. Par exemple, si je choisis Groupe2 puis Groupe1, je dois logiquement obtenir la liste suivante "Groupe2, Groupe1".

Cliquez pour agrandir...

Le Code VBA de la macro RecupGroupeProfSalle devra être modifié en conséquence.

En attendant ton retour avant d'aller plus loin ...

Bonsoir CroCroCro,

Merci pour ton retour à nouveau !

Je réponds à tes questions ici :

• Qui fait les mises à jour de la BD ?
  • Je prends rendez-vous avec une personne, je pose des questions, je saisie les réponses dans Excel. La saisie des données se fera par moi, et uniquement par moi. Seule façon pour moi de garder la confiance sur les données. Je ne pense pas avoir l'usage d'un userform (sauf si ça me fait gagner du temps pour la saisie).
• Combien de lignes Cours seront créées par année ?
  • Sans outil efficace à ce jour pour l'affirmer, je peux estimer une fourchette de lignes saisies de cours de 5 000 à 10 000 lignes de cours/année environ (ça fait beaucoup, d’où le fait que je cherche à poser de solides fondations au préalable).
• A quel rythme se font les mises à jour ? tous les jours ? une fois par mois ?
  • Le premier tour de remplissage passera forcément par un entretien avec chaque personne pour récolter les données les plus justes.
  • Ensuite, le document sera mis à disposition en lecture seule pour consultation. Chaque année, de nombreuses personnes ajustent leurs cours (elles peuvent demander un peu plus d'heures dans la matière, un peu moins, donner le cours avec plus ou moins de groupes d'étudiants, ajuster le nom de la matière, modifier l'enchainement des séquences de cours, changer de matière, quitter l'établissement, s'absenter en congés maternité, il peut y avoir plus de groupes d'étudiants, etc.). Les mises à jour sont donc ponctuelles, mais régulières en fonction de la demande des personnes. Je dirais au moins 1 fois/mois. En tout cas, rien n'est statique bien longtemps ce qui pose bien des soucis de traçabilité, suivi, pilotage et comptage !
• Type de mise à jour ?
  • La création d'enregistrements
    • Uniquement moi aux manettes
    • Par exemple : une nouvelle matière doit être enseignée, un nouveau professeur vient d'arriver, un nouveau groupe d'étudiants doit être créé, etc.
  • La modification d'enregistrements
    • Uniquement moi aux manettes
    • Par exemple : le nom d'une matière a légèrement changé, le volume d'heures doit être ajusté, etc.
    • J'attends de voir l'évolution du fichier Excel, mais je ne pensais pas toucher aux clés primaires. Elles sont déterminées, figées, uniques et ne sont normalement pas/peu modifiées.
    • J'ai bien compris que modifier le nom d'un professeur devrait normalement propager la modification à tout le classeur Excel grâce à l'ID. C'est le comportement attendu.
    • Un nouveau professeur remplace l'ancien ? On peut soit créer un nouveau ID et recommencer de zéro pour lui attribuer les matières, soit inscrire la nouvelle personne en lieu et place de l'ancienne pour lui attribuer les mêmes matières d'un coup.
    • En revanche, modifier l'ID d'une personne par un ancien, pourrait conduire à le re-router sur le profil d'un autre professeur (autres cours, autres salles, etc.).
  • La suppression d'enregistrements
    • Uniquement moi aux manettes
    • Par exemple :
      • Dans la Table_Matiere, il est possible qu'une matière ne soit plus enseignée. On peut soit laisser l'enregistrement inutilisée, soit le supprimer, soit utiliser l'ID pour faire autre chose en lieu et place.
      • Dans la Table_Groupe, même chose, il est possible qu'un groupe ne soit plus utilisé.
      • Pareil pour Table_Professeur si une personne quitte l'établissement.
      • Pareil pour Table_Salle si une salle est réutilisée pour un autre usage.
      • A noter : j'ai placé un champ "Statut" dans chaque table pour se laisser la possibilté de filtrer les données selon le statut. Par exemple, une personne en arrêt maladie conservera son ID mais s'il est "désactivé" alors il ne pourra plus donner de cours en attendant son retour (pareil pour Matiere, Groupe et Salle). Tu proposais d'utiliser un booléen, à voir ce qui est plus pratique. Le booléen fonctionnera pareil pour toutes les tables j'avoue, mais sera moins parlant pour les utilisateurs qui devront trier, filtrer les TCD.

crocrocro à dit:

Je crois me souvenir que dans Access, il y a une option "Mise à jour en cascade" dans la conception du modèle de données qui effectue ce travail automatiquement.

Cliquez pour agrandir...

En effet, il est possible de laisser des enregistrements sans lien avec la table de donnée source (orphelins) soit de supprimer les enregistrements de sorte qu'il existe 100% de correspondance, d'équivalence.

Dans mon cas, je me disais que dans une des tables, comme Table_Matiere, dès lors que je supprime une clé primaire de "ID_Matière" j'ai une boite de dialogue qui me préviens que je suis sur le point de supprimer tous les enregistrements de la Table_Cours sans retour possible. Avec la possibilité d'annuler la suppression de l'ID pour ne pas tout perdre donc^^. Si je décide de valider la suppression de l'ID, j'imaginais me rendre dans la Table_Cours, sélectionner la colonne du tableau qui va bien, et lancer une recherche de l'ID, pour le remplacer par "".

Dans le cas de la Table_Cours, si j'inscris un ID de Matiere non valide (qui n'existe pas dans Table_Matiere), alors une fenêtre m'indique que je ne peux pas utiliser cet ID. De toute manière, la sélection se fera via ta proposition qui consiste à double cliquer et sélectionner les bonnes valeurs. Je ne devrais pas inscrire les valeurs à la main, sauf dans certains cas où ça ira plus vite si je connais par coeur l'ID que je veux utiliser. Un peu de contrôle de validation primaire ne ferait pas de mal tant les erreurs sont vites arrivées.

• Qui consulte directement la BD (les différentes Tables)?
  • Tout le monde pourra consulter le fichier qui pourra être disponible sur l'intranet, en lecture seule, protégé par MDP, verrouillée, etc.
• Quel identifiant : technique, fonctionnel ou semi-fonctionnel ?
  • J'ai essayé avec un identifiant semi-fonctionnel comme tu le proposes, mais toujours peu lisible. Il ne faut pas oublier qu'il y aura régulièrement 10 Groupes, 4 Professeurs, 20 Salles. Quoi qu'on choisisse, la Table_Cours semble vouée à rester peu-lisible, peu exploitable en l'état. Ce n'est d'ailleurs pas son rôle.
  • Je propose donc de rester sur un ID numérique classique pour chaque table. Le fichier que je propose en pièce jointe vérifie le plus possible les critères d'une clé primaire (validation de données + MFC).
  • J'ai supprimé les colonnes de couleur orange dans Table_Cours car comme je le disais, c'était illisible de toute les manières. J'espère pouvoir faire le lien à l'aide des TCD qui m'indiqueront le rapport précis et lisible de ce que j'aurais entré comme cours. Je ferai rapidement le lien avec des ID numériques. Pas de souci pour moi si je m'en sors avec les TCD.

J'espère avoir répondu de manière assez pertinente pour te permettre d'y voir plus clair. Parce que pour moi, je me casse la tête à essayer d'innombrables combinaisons pour la structure de mes données. Je pensais avoir fait un bond en avant avec la notion de Tables, ID, attributs, valeurs...et malgré le côté séduisant de la chose, je ne parviens pas à voir où cela va aller. Je sens que les Table amènent d'autres effets de bord que je n'avais pas vu. C'est toujours le problème des données liées Groupe, Professeur et Salle qui me bloque. Je sens que je n'arriverai pas à relier toutes mes tables pour permettre une analyse croisée par TCD avec tout type de champs présent dans toutes les tables. Peut-être que ton prochain fichier m'aidera à y voir plus clair.

Je suis fatigué, une bonne nuit de sommeil et je m'y remets demain CroCroCro

Bonjour Sérieux et Cool,

5 000 à 10 000 lignes de cours par an, consultation du fichier par toute le monde (les enseignants et les étudiants je suppose) sur l'intranet, des centaines d'utilisateurs potentiels si j'ai bien compris, c'est donc un niveau d'exigences plus élevé (fiabilité, disponibilité, sécurité, rapidité …), avec pour toi, des situations plus ou moins pénibles à gérer à en cas de défaillance de l'application.
Je n'ai pas d'expérience sur des accès en simultané d'un fichier Excel. A voir les problèmes éventuels.

La BD doit-elle contenir uniquement les données de l'année scolaire ? Ce serait préférable au niveau volume de données.

Sauvegarde des fichiers.
Il sera nécessaire de mettre en place une gestion de sauvegarde régulière du (des) fichier(s) particulièrement dans la période de saisie intensive. Il y a des outils pour. Sinon, manuellement je te suggère une sauvegarde par simple copie en suffixant le nom du fichier la date de sauvegarde au format ssaammjj. Et bien sûr, de ne pas mettre tous les œufs dans le même panier, un PC HS avec toutes les sauvegardes sur le disque dur ne sera pas très utile.

Dans mon cas, je me disais que dans une des tables, comme Table_Matiere, dès lors que je supprime une clé primaire de "ID_Matière" j'ai une boite de dialogue qui me préviens que je suis sur le point de supprimer tous les enregistrements de la Table_Cours sans retour possible. Avec la possibilité d'annuler la suppression de l'ID pour ne pas tout perdre donc^^. Si je décide de valaider la suppression de l'ID, j'imaginais me rendre dans la Table_Cours, sélectionner la colonne du tableau qui va bien, et lancer une recherche de l'ID, pour le remplacer par "".

Cliquez pour agrandir...

NON, on ne supprime pas un enregistrement d'une table de référence ni ne modifie la Clé Primaire (sauf en phase d'initialisation), dès lors qu'il y a des enregistrements de tables connexes qui pointent sur cette Clé.
Oui, on peut vérifier par du code VBA et bloquer la mise à jour.
Mais, si comme tu l'as dit, c'est toi seul qui fait la mise à jour, on peut s'en affranchir car çà peut devenir complexe à gérer (rien ne t'empêche de supprimer la feuille, de supprimer toutes les lignes …)

Pour l'application en consultation sur l'intranet
Cela signifie : 2 fichiers Excel, ta version pour mise à jour, la version en consultation sur L'intranet.
La version intranet doit-elle être la même que la tienne ?
Ce serait plus facile à gérer. Uniquement des protections par mot de passe pour la mise à jour.
A quel rythme la version intranet doit-elle être actualisée ? J'espère qu'elles peuvent être désynchronisées.
Les feuilles Table_Cours et Analyse_Cours ne présentent aucun intérêt sur l'intranet et même amèneront des remarques négatives. Une suggestion, les masquer.
Autre suggestion pour Analyse_Cours : comme cette table doit être regénérée à partir de la Table_Cours, y inclure les identifiants fonctionnels en masquant les identifiants non fonctionnels.
Pas compliqué à mettre en œuvre : Une macro à exécuter quand les mises à jour sont prêtes à être diffusées sur l'intranet qui protège les feuilles avec mot de passe, masque les feuilles inutiles, masque les colonnes inutiles.

C'est toujours le problème des données liées Groupe, Professeur et Salle qui me bloque. Je sens que je n'arriverai pas à relier toutes mes tables pour permettre une analyse croisée par TCD avec tout type de champs présent dans toutes les tables.

Cliquez pour agrandir...

Je pensais que tu avais déjà mis en place des TCD basés sur des relations entre tables et que donc, cela ne posait pas de problèmes. C'est un point à voir rapidement, les TCDs et Graphiques à produire doivent être réalisables (facilement) avec la structure de la BD que tu as prévue. En attaquant le tableau de la feuille Analyse_Cours et par le jeu des relations, les tables de référence associées. Éventuellement à partir du tableau de la feuille Table_Cours.
Connais-tu en détail les différents TCD et Graphiques que tu dois produire ? je suppose que tu as enquêté auprès des utilisateurs. Ce serait dommage de te retrouver coincé avec un modèle de données qui ne répond que partiellement au besoin, juste à cause d'un élément non prévu à la conception.


Pour te proposer un nouveau fichier avec les modifications de code, je préfère attendre ton retour sur mes remarques.

Bonsoir CroCroCro,

Je réponds avec plaisir à tes nouvelles questions/remarques. N'hésite surtout pas si je ne suis pas assez clair, ou si tu as d'autres questions.

La BD doit-elle contenir uniquement les données de l'année scolaire ? Ce serait préférable au niveau volume de données.

Sauvegarde des fichiers :

NON, on ne supprime pas un enregistrement d'une table de référence ni ne modifie la Clé Primaire (sauf en phase d'initialisation), dès lors qu'il y a des enregistrements de tables connexes qui pointent sur cette Clé.

Application en consultation sur l'intranet - La version intranet doit-elle être la même que la tienne ?

Je pensais que tu avais déjà mis en place des TCD basés sur des relations entre tables et que donc, cela ne posait pas de problèmes.

crocrocro à dit:

Connais-tu en détail les différents TCD et Graphiques que tu dois produire ? je suppose que tu as enquêté auprès des utilisateurs. Ce serait dommage de te retrouver coincé avec un modèle de données qui ne répond que partiellement au besoin, juste à cause d'un élément non prévu à la conception.

Cliquez pour agrandir...

Oui j'ai une vue assez détaillée et précise de l'ensemble des classes, attributs/classe et liens entres les classes. Je n'arrive pas encore à relier toutes les classes entre elles de manière logique mais j'y travaille. Le modèle conceptuel est un peu plus complexe que celui que j'ai présenté ici (Matiere, Groupe, Professeur et Salle), mais reste sensiblement le même. Il est plus détaillé et représente la réalité. Je ne l'ai pas présenté ici encore car je ne voulais pas complexifier davantage le problème. Maintenant que tu m'as fait comprendre qu'il faut passer par tables relationnelles car mes données sont reliées entre elles, souhaites-tu que je présente le modèle le plus complet que j'ai ? Peut-être que ça facilitera les choses maintenant que l'on connait le contexte tous les deux.

Je pourrais mieux exposer mon besoin et mon plan d'action : (décrire quelques rapports TCD type que j'aimerais par exemple) et surtout exposer le sens que je veux donner à ce projet (création automatique des plannings annuels in fine).

N'hésite pas à me dire si tu souhaites passer à la version détaillée pour être tout de suite le plus réaliste possible. J'ai le sentiment que c'est le moment de le faire au risque de repartir un peu en arrière mais de viser juste du premier coup.

Belle soirée à toi

Bonjour Sérieux et Cool,

Un petit préambule.
Je crois qu'on a fait à peu-près le tour du sujet de départ "Conseils pour la structuration d'une base de données".
On a pas mal élargi pour arriver à ce que je qualifierai de "Mise en œuvre d'une application de gestion de planning de cours".
On atteint là les limites de l'objectif de ce forum, apporter des conseils et ou solutions à des questions techniques mais pas de créer des applications.

Il faudrait assez rapidement, effectuer un test de performance pour les TCD avec un gros volume de données, pour vérifier que c'est acceptable. Je peux t'aider à constituer le jeu d'essai.
Et, si les performances sont mauvaises, envisager de compléter la table TabCoursPourAnalyse avec toutes les infos utilisées dans le TCD pour éviter de mettre en jeu les relations (dénormaliser) :
- On va peut-être gagner en temps mais aussi prendre beaucoup de poids de fichier puisqu'on va dupliquer beaucoup d'infos que l'on récupère normalement en direct par la relation. Seul un test pourra dire si on gagne du temps.

Un point dont on n'a pas parlé, les utilisateurs vont-ils pouvoir jouer avec les TCD, les graphiques (filtrer ...) ou bien auront-ils des données statiques ?

Je reviens sur ton choix d'utiliser des identifiants purement techniques.
Je reste convaincu qu'il est préférable ici d'utiliser des identifiants semi-fonctionnels :
Dans la feuille Cours ou la feuille d'analyse de Cours, tu n'as aucun moyen de vérifier directement sur la feuille si les valeurs saisies (plutôt sélectionnées) correspondent bien à ton choix. C'est d'autant plus vrai pour les multi-sélections où l'ordre doit être respecté.

En pj, mon fichier sur lequel j'ai apporté les adaptations du code pour coller à tes dernières demandes.
Je n'ai pas repris le tien. Je te propose de faire toi-même les adaptations, ce qui va te permettre, et c'est nécessaire, de bien comprendre et t'approprier le code.
Pour cela tu pourras utiliser toutes les fonctionnalités de l'éditeur VBA, le débogueur, en exécutant le code en pas à pas, les fenêtres d'Espionnage et d'Exécution.
J'ai ajouté quelques commentaires au niveau des adaptations de code à faire pour adapter le code à ton nouveau fichier.
J'ai masqué les feuilles intermédiaires et mis en commentaires le code qui les mettaient à jour lors de la regénération.
Dans la feuille TCD, j'ai ajouté 1 TCD en bas, basé sur la feuille Analyse et la table Salles à laquelle j'ai ajouté une info (type de salle).
Il utilise la relation entre les 2 tables (voir copie d'écran à coté des TCD pour la création de la relation, attention à l'ordre dans la création de la relation (Colonne Externe et Principale).
Je reste à l'écoute

J'ai vu que sur Excel, on peut lier les tables entre elles via des relations comme le fait Access. Avec 3 tables, j'aimerais pouvoir analyser des données de la table 1, avec celles de la table 3 en passant par le lien de la table 1 à 2 et 2 à 3. Mais je dois louper quelque chose car j'ai du mal à obtenir ces TCD. J'ai mis un exemple en pièce jointe (boite, gelule, poudre : je n'arrive pas à obtenir des données de boite contenant des types de poudre).

Cliquez pour agrandir...

Pour ton problème de TCD sur 3 tables, ton fichier joint n'est pas le bon, pas de trace de gélule …
En pj un fichier exemple (Exemple TCD 2 relations crocrocro.xlsx) qui fonctionne.

Bonjour CroCroCro,

Merci à nouveau pour tes explications toujours appréciées !

crocrocro à dit:

En pj un fichier exemple (Exemple TCD 2 relations crocrocro.xlsx) qui fonctionne.

Cliquez pour agrandir...

Cet exemple m'a permis de bien comprendre pourquoi je n'y arrivais pas. J'appliquais des relations qui n'avaient pas de sens logique. C'était normal que mon TCD ne produise pas le résultat escompté. Merci CroCroCro pour m'avoir permis de comprendre.

crocrocro à dit:

Dans la feuille TCD, j'ai ajouté 1 TCD en bas, basé sur la feuille Analyse et la table Salles à laquelle j'ai ajouté une info (type de salle).

Cliquez pour agrandir...

Là encore, merci pour avoir ajouté ce TCD supplémentaire. C'est le seul TCD de la feuille qui va chercher une info dans une table principale, sur une colonne qui n'est pas l'ID principal. Du coup, j'ai aussi pu comprendre comment tout ça fonctionnait. Merci CroCroCro pour m'avoir permis de comprendre.

Fort de ces 2 exemples...si je ne me trompe pas, je reviens sur le même problème que j'évoquais dans mon post précédent :

SERIEUXETCOOL à dit:

• Dans ton dernier fichier Excel, ton TCD pouvait afficher la matière Méca, et m'indiquer que (Groupe1, Groupe2) suivaient ce cours. Or avec la notion de table et d'ID, la matière Méca indique maintenant que le groupe (2, 1) suit ce cours de Méca. 2 et 1 étant l'ID des groupes. Mon TCD ne rentre pas dans les détails comme je pensais. Puisque l'ID (2, 1) n'existe pas comme groupe d'étudiants.

Cliquez pour agrandir...

Pour mieux expliquer, j'ai mis ton fichier en pièce jointe, dans lequel j'ai ajouté une colonne de plus aux tables principales. Je peux analyser les heures pour la salle1 de plusieurs manières via les TCD de la dernière feuille. Elles donnent toutes le même résultat en heure (ce qui est logique et correct surtout) mais pas le même détail (ce qui est logique là aussi et correct) en fonction de la relation entre les tables que l'on choisit :


Les deux TCD sont justes ici. Le souci, d'après moi, c'est que si je raisonne en ID de type Numérique, alors j'aurais le TCD présenté de la manière suivante :


Dans les deux cas (ID semi-fonctionnel ou ID technique) j'arrive à avoir le nombre d'heures correct (ce qui est super), mais pas le sexe (Masculin ou Féminin) du professeur. Ce n'est juste pas possible sur des champs qui sont liés comme ici (Salle et Professeur).

Donc la question sous-jacente que je pose :
Quel intérêt d'utiliser l'approche par table, en détaillant les tables avec des informations précises (comme le sexe d'un professeur par exemple) si je ne peux pas l’analyser par croisement des données à la fin. Autant utiliser des tables, ne contenant qu'une seule colonne ?

D’où la remarque dans mon précédent post :

SERIEUXETCOOL à dit:

A mon avis, soit je loupe un passage que je ne comprends pas, soit il ne faut vraiment pas partir sur la notion de données liées (Groupe, Professeur, Salle) qui cause tous ces soucis. Il va probablement falloir essayer de transformer les relations (n, n) à (1, n) avec table intermédiaire de jonction pour s'en sortir de façon propre.

Cliquez pour agrandir...

Et si je ne me trompe pas, partir sur des données normalisées...provoquera un comptage erroné du nombre d'heures (on comptabilisera plus d'heures qu'en réalité). Nous avions fait ce constat me semble-t-il, il faut que je vérifie pour être certain.

Si mes propos sont corrects, voici la conclusion que j'en tire :

• Solution n°1 :
  • Partir sur des tables principales distinctes pour faciliter la compréhension du modèle relationnel, où chaque table contient une seule colonne, avec un identifiant fonctionnel unique. Je n'aurais qu'un niveau de lecture mais il sera 100% réaliste et tout sera correct au niveau des heures. Par contre, je ne rentre pas les détails comme le sexe d'un professeur, etc.
• Solution n°2 :
  • Partir sur des tables principales distinctes pour faciliter la compréhension du modèle relationnel, où chaque table peut contenir plusieurs colonnes, avec un identifiant technique unique (ou semi-fonctionnel pour l'exemple mais peu importe). Je construis ma feuille cours de la même façon que celle de ton dernier fichier. Par contre, quand je clique sur le bouton "Regénérer les Tableaux de Cours degroupés", alors il me créé la feuille "CoursPourAnalyse" de la manière suivante :
  • Il faudra faire la même chose pour la table Groupe et Professeur bien sûr.
  • Dans ce cas, j'aurais accès à tous les niveaux de lecture par TCD sans jamais avoir de "Vide". Le TCD sera 100% réaliste et tout sera correct au niveau des heures. Par contre, je complexifie un peu le code VBA et je multiplie les données et donc le poids du fichier Excel.
    • Avec cette solution, il faut veiller à prendre en compte le nombre de colonne de chaque table principale de sorte que si j'ajoute/supprime une colonne pour la table salle par exemple, alors le bouton "Regénérer les Tableaux de Cours degroupés" ajoutera cette colonne (ou supprimera).
    • Même surveillance pour la table Groupe et Professeur bien sûr
• Toute autre solution provoquera :
  • Ou bien des erreurs de comptage des heures
  • Ou bien des TCD qui afficheront "Vide" dès lors que je croise les données avec un (Groupe, Salle et/ou Professeur) ce qui ne permettra pas l'analyse souhaitée par les utilisateurs

crocrocro à dit:

Si les performances sont mauvaises, envisager de compléter la table TabCoursPourAnalyse avec toutes les infos utilisées dans le TCD

Cliquez pour agrandir...

On dirait le même principe que je viens d'évoquer ? Mais pour des motifs différents : toi la performance, et moi l’analyse des données. Qu'importe, on pourrait cumuler 3 avantages (allier performance, analyse détaillée des données en profondeur, utiliser des identifiants techniques de type numérique sur les tables principales car tout serait "humainement lisible" dans la table "TabCoursPourAnalyse").

crocrocro à dit:

Les utilisateurs vont-ils pouvoir jouer avec les TCD, les graphiques (filtrer ...) ou bien auront-ils des données statiques ?

Cliquez pour agrandir...

Les utilisateurs pourront jouer avec les TCD, les filtres, etc. selon leurs besoins respectifs. Par exemple, un professeur voudra connaitre le détail de ses heures, puis le détail des heures pour son collègue et lui-même, etc.

crocrocro à dit:

Il faudrait assez rapidement, effectuer un test de performance pour les TCD avec un gros volume de données, pour vérifier que c'est acceptable.

Cliquez pour agrandir...

Je suis d'accord avec toi. C'est un point qui n'a pas été testé à ce stade. Si les TCD encaissent mal des milliers de lignes, ça risque de coincer.

En espérant que mes propos soient clairs, cohérents et qu'ils permettent d'affiner ce fichu modèle de structuration des données

Bonsoir Sérieux et Cool,
un premier retour rapide et donc incomplet sur 1 ou 2 points :
Le bricolage qu'on a fait pour permettre d'affecter à 1 cours, n1 professeurs, n2 salles, n3 groupes (l'objectif initial était d'avoir une durée de cours juste) a eu pour conséquence :
- La tables Cours est hors modèle Relationnel (plusieurs infos dans la même cellule)
- La table CoursPourAnalyse est également hors modèle Relationnel puisqu'on ne dégroupe qu'une colonne par type d'enregistrement (par exemple Salles pour le Type d'enregistrement Salles)
Les TCD basés sur les Relations renvoient la valeur vide pour les valeurs multiples (par exemple pour le 1er TCD, vides durée 0.5 pour le cours donné conjointement par Marc et Anne.

Pour avoir une BD qui respecte le modèle, il faudrait avoir (voir le post 22), un Table Cours, les tables Professeurs, Salles, Matières, Groupes, et les "fameuses" tables de lien" d'identifiants Id Cours - Id Prof + durée, Id Cours - Id Salles + durée ...
Et donc au niveau de ta saisie des Cours, alimenter également ces tables de lien. Je propose (voir plus loin) de le désynchroniser. Là encore on déroge à la règle mais ce n'est ici pas grave puisqu'elles seront utilisées seulement dans un 2ème temps.
Visuellement sur ta feuille Cours, cela pourrait ne rien changer mais il faudrait stocker ailleurs les infos de la table Cours (Id Cours, Date, Durée), les infos de chaque table de lien.
Et bien sûr, à chaque modification d'un Cours (ajout suppression d'un prof ...) modifier les tables de lien concernées par la modification.
Sur la feuille Cours, aucun changement.
Il faudrait stocker ailleurs les infos de chaque table de lien.
Dans ce cas, plus besoin de dégroupage, pas de problème de valeurs de TCD vide.
Les TCDs basés sur la table Cours, la (les) table(s) de lien concernée(s), la (les) tables de référence concernées.
D'un côté, une prise en compte de la saisie plus délicate, encore plus si tu souhaites utiliser les possibilités de copie d'une ligne (ou d'un paquet de lignes) de cours par exemple d'une journée sur l'autre.
De l'autre un modèle plus respectueux des règles avec une exploitation des données facilitée et sans artefact (les vides).
Cela reste théorique (je n'ai fait aucun test) et sans doute pas très clair.
Je complète ici après avoir barré ce qui doit être rectifié.
Il y aurait bien une phase après saisie des cours, non pas de dégroupage par le bouton dédié mais, par de reconstitution des tables de liens : au lieu de créer la table CoursPourAnalyse, on (re)génère les 3 tables de liens, le code vba devra bouger en conséquence mais finalement peu.
A noter :
si tu bâtis ton TCD pour aller au niveau complètement dégroupé, pas de ligne vide, mais le total général sera faux (donc à ne pas afficher) et tu perds (au niveau du TCD) les infos de groupe. Dans l'exemple de la Salle1 de ton fichier, tu aurais au lieu de vides (ou Marc, Anne), 2 lignes supplémentaires, 1 ligne Marc avec durée 0.5 et une ligne Anne avec également durée 0.5.
C'est pourquoi le total général serait faux (4 au lieu de 3.5).
Pour avoir un résultat non dégroupé, il faudrait utiliser en complément un autre TCD qui, dans l'exemple pour les professeurs n'utiliserait pas la table de lien Professeur ni la table de référence Professeurs mais uniquement l'info présente dans la table Cours, l'id Professeurs, ce qui dans ce cas ne présenterait d'intérêt que si c'est un identifiant semi-fonctionnel ou fonctionnel qui devra comme je l'ai dit par ailleurs, respecter la règle suivante : être unique et stable. Unique pour pouvoir pointer sur le bon enregistrement de la table Professeurs. Stable pour ne pas avoir du n'importe quoi dans la Table Cours.
Je sais, pas évident de comprendre sans fichier avec l'exemple.

Dans les deux cas (ID semi-fonctionnel ou ID technique) j'arrive à avoir le nombre d'heures correct (ce qui est super), mais pas le sexe (Masculin ou Féminin) du professeur. Ce n'est juste pas possible sur des champs qui sont liés comme ici (Salle et Professeur).

Cliquez pour agrandir...

Tu veux dire pour le valeurs multiples ? Pour les unitaires le sexe apparait.
Mais selon moi, cette information n'est pas à utiliser dans le TCD, c'est un contre-sens, tu créés un niveau hiérarchique (dans le TCD) où il n'y en a pas. Au niveau Lignes (voir copie d'écran), tu dois avoir une seule information par Table,
Avec des champs calculés, tu aurais pu créer une information Nom Prénom Sexe par exemple, mais on ne peut pas en créer quand on utilise des relations dans un TCD.


On revient là à ce que je disais plus haut.

Donc la question sous-jacente que je pose :
Quel intérêt d'utiliser l'approche par table, en détaillant les tables avec des informations précises (comme le sexe d'un professeur par exemple) si je ne peux pas l’analyser par croisement des données à la fin. Autant utiliser des tables, ne contenant qu'une seule colonne ?

Cliquez pour agrandir...

Les TCD sont intéressants pour analyser des données globales (nombres de valeurs, somme, ...).
Et je te renouvelle une remarque précédente, il faut que tu connaisses au préalable les types de TCD (pas le détail) que tu devras produire pour être sûr de ne pas être coincé.
Si tu veux avoir un aperçu de niveau détail, par exemple connaitre pour un professeur, les infos de la table Professeurs, la liste des cours qu'il a donnés, il vaut mieux (selon moi) procéder différemment. Le principe :
Une feuille ou un userform avec une liste déroulante où tu sélectionnes le professeur et tu affiches ses informations (table Professeurs) et la liste des cours qu'il a donnés (table CoursPourAnalyse avec éventuellement des informations des tables liées (type de Salle ...)

La suite plus tard