Discussion :

[Iss40]

Bonjour,
Aidez moi SVP à créer une requête à partir d'une table "tab1" contenant des colonnes relatifs aux identités des étudiants et des matières (M1, M2, ..., M20). Les enregistrements correspondants aux étudiants et leurs notes pour chaque matières. J'aime bien créer une requête (en mode création si possible ou en utilisant un code vba) qui contient l'identité et une matière renseignée dans le champ "mat" d'un formulaire "form1". Donc à travers une seule requête + un formulaire je peux voir uniquement les notes de la matière choisie dans "mat" et cette requête sera reliée à un état pour imprimer la feuille d'émargement de la matière. Je dispose l'access 2010.
Merci

[marot_r]

Bonjour.

Peux-tu poster la liste des champs de ta table ?

A+

[Iss40]

Bonjour,
La table contient les champs suivants : nom, prénom, id, puis les noms des matières, pour vous simplifier la tâche je les ai nomé m1, m2, m3, .... , m20 (donc au total 23 champs).

[marot_r]

Bonjour.

C'est ce que je craignais, c'est une structure "À la Excel" qui n'est pas du tout adaptée à Access.
Access marche avec des listes, des listes de listes, des listes de listes de listes ... mais pas avec des tableaux à 2 dimensions.
Voici la structure la mieux adaptée à Access :

tblEleve
ClefEleve
Autres infos sur eleve (ex : nom et prénom de l'élève)

un enregistrement (ligne) par élève.

tblMatiere
ClefMatiere
Autres infos sur la matiere (ex : nom de la matière)

un enregistrement par matière.

tblMatiereEleve
ClefMatiereEleve
ClefEleve
ClefMatiere
Note
AnneeScolaire (peut-être ?)

en relation avec :

• tblMatiere sur ClefMatiere
• tblEleve sur ClefEleve

un enregistrement par matière et élève donc dans ton cas un élève pourrait avoir 20 enregistrements en supposant qu'il prenne toutes les matières.

À partir de cette architecture tu peux assez facilement créer (requête croisée dynamique) un tableau des élèves et des matières qu'ils étudient et ses notes.

A+

[marot_r]

En complément :

Note que si pour des raisons de saisie il est absolument nécessaire (demande des utilisateurs) de faire une table telle que la tienne alors il faut prévoir du code pour passer de la table de saisie à la table définitive en "liste" et vice-versa.

A+

[Iss40]

Bonsoir
Je suis tout à fait d'accord avec vous concernant la structure du tableau, mais malheureusement cette structure est imposée car il s'agit d'un tableau Excel importé d'une application d'examen. J'espère trouver une solution pour créer cette requête
Cordialement

[escartefigue]

Bonjour,

Le fait que les informations arrivent dans une feuille excel unique n'implique nullement de modéliser une seule table.
Un SGBD, même aussi rudimentaire que Access, n'est pas un tableur.

Comme un élève peut suivre plusieurs matières et qu'une matière peut être suivie par plusieurs élèves, vous devez avoir à minima 3 tables : elève, matière et lien elève/matière

Leur structure devrait être comme suit (PK soulignées, FK suffixées par #)

EL_eleve(EL_ident, EL_nom, EL_prenom, EL_date_nais etc.)
MA_matiere(MA_ident, MA_code, MA_nom)
SV_suivre(EL_ident#, MA_ident#, MA_date_deb, MA_date_fin).

@marot_r : la table associative (que j'ai appellée SV_suivre ci-dessus) ne doit pas avoir d'identifiant propre
Au niveau conceptuel, un identifiant n'existe que pour les types d'entité, ils sont hérités au niveau tabulaire dans les associations qui deviennent des tables.
La PK de la table associative est donc le couple de FK {EL_ident, MA_ident}, l'ajout d'un identifiant artificiel "ClefMatiereEleve" est une redondance et un risque d'erreur !

De plus, dans une base de données relationnelle, il n'y a pas de champs, mais des colonnes.
Les champs sont les zones de saisie des formulaires ou les zones d'édition d'un état.
Access mélange les notions de champs et de colonnes à cause de son interface graphique qui propose des champs de saisie en bijection avec les colonnes des tables.
Pour autant, ce n'est pas la même chose.

[micniv]

bonjour,
voir le fil https://www.developpez.net/forums/d2.../#post11710688 s'il peut être d'une utilité ...

[marot_r]

Bonjour.

La table associative (que j'ai appellée SV_suivre ci-dessus) ne doit pas avoir d'identifiant propre
Au niveau conceptuel, un identifiant n'existe que pour les types d'entité, ils sont hérités au niveau tabulaire dans les associations qui deviennent des tables.
La PK de la table associative est donc le couple de FK {EL_ident, MA_ident}, l'ajout d'un identifiant artificiel "ClefMatiereEleve" est une redondance et un risque d'erreur !

En théorie oui, en pratique non.

A+

[marot_r]

En complément de ma réponse brève, en fait ClefMatiereEleve est plus un numéro séquentiel d'enregistrement qu'une vraie clef primaire. Fraudait que je pense à changer le nom.
J'ajoute toujours un index unique composé des 2 champs joints qui lui assure la clef primaire. Cela permet aussi d'avoir un enregistrement d'association même si un des éléments est manquant ce que ne permet pas une clef primaire.
Attention avec des Null dans les champs, Access ne garantie plus l'unicité :-(. Il faut que les 2 champs soient remplis pour être sûr de ne pas avoir de doublons. Le non test des doublons avec des Null est un peu agaçant mais en pratique pas si génant.

A+

[marot_r]

En passant :

De plus, dans une base de données relationnelle, il n'y a pas de champs, mais des colonnes.

Quand j'ai appris les BD on parlait de champ (ou d'attribut) et pas de colonne, les colonnes c'étaient pour les tableurs :-) ... un histoire de génération sans doute :-).

A+