Je ne connais que quelques rudiments.
Voici cependant ce que je souhaite faire avec de l'aide !
Sur ma page WEB, j'ai un espace réservé (à mes élèves). Il peuvent y accéder
en s'authentifiant (.htaccess). Quand ils se sont authentifier, je souhaite
mettre à leur disposition un formulaire dans lequel ils puissent reporter
leur notes. Je souhaite ensuite pouvoir récupérer la saisie (automatiquement
?) pour remplir un tableau global (notes de tous les élèves) qui donnerait
en plus la moyenne de chacun et le classement (au moment de la
consultation,).
Cela vous semble-t-il réalisable ? Si oui, qui peut me donner un schéma
général (ou une réalisation déjà faite à adapter) de ce qu'il faut faire ?
Merci pour toute aide.
Cordialement,
--
Serge Nazarian
Cliquez ci dessous pour une réponse personnelle :
http://cerbermail.com/?CBBJUUv0pN
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
dmetzler
Première chose à imaginer : les données. Tu vas avoir besoin d'une base de données avec les tables suivantes [Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P), Eleve_mot de passe,...) [Examen] (Examen_uid (P), Examen_description) [Notes] (Examen_uid, Eleve_login, Notes_note)
Tu vas avoir un module permettant aux élèves de rentrer leur notes dans la base. Tu utilise un .htaccess pour utiliser l'authentification d'Apache. Les élèves rentrent leurs notes pour chaque examen.
Un deuxième module permettra de faire du reporting (ton tableau global) qui reprendra le classement ainsi que la moyenne de chaque élève.
La réalisation d'une telle application est un très bon exercice de mise en oeuvre de PHP, même pour quelqu'un qui débute. Tu devrais pouvoir t'y retrouver facilement avec les tutoriels présents un peu partout.
Question pour John mainenant : J'ai ici fait une table [Examen]. A maintes et maintes reprises tu expliques qu'il ne faut pas faire d'auto-increment ou autre séquence. Comment ferais tu dans le cas de la table [Examen] pour générer une clé primaire. Ce genre de table existe dans beaucoup d'applications (Clé/Description) et il n'est pas toujours évident de générer un clé à partir de la description.
On peut demander à l'utilisateur de donner un code, ou on peut le générer à sa place, mais pour moi ça revient à faire de l'autoincrément... On peut aussi utiliser la description comme PK, mais je ne trouve ça pas très "joli" surtout quand on va venir la référencer dans d'autres tables...
Première chose à imaginer : les données.
Tu vas avoir besoin d'une base de données avec les tables suivantes
[Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P),
Eleve_mot de passe,...)
[Examen] (Examen_uid (P), Examen_description)
[Notes] (Examen_uid, Eleve_login, Notes_note)
Tu vas avoir un module permettant aux élèves de rentrer leur notes
dans la base. Tu utilise un .htaccess pour utiliser l'authentification
d'Apache. Les élèves rentrent leurs notes pour chaque examen.
Un deuxième module permettra de faire du reporting (ton tableau
global) qui reprendra le classement ainsi que la moyenne de chaque
élève.
La réalisation d'une telle application est un très bon exercice de
mise en oeuvre de PHP, même pour quelqu'un qui débute. Tu devrais
pouvoir t'y retrouver facilement avec les tutoriels présents un peu
partout.
Question pour John mainenant : J'ai ici fait une table [Examen]. A
maintes et maintes reprises tu expliques qu'il ne faut pas faire
d'auto-increment ou autre séquence. Comment ferais tu dans le cas de
la table [Examen] pour générer une clé primaire. Ce genre de table
existe dans beaucoup d'applications (Clé/Description) et il n'est pas
toujours évident de générer un clé à partir de la description.
On peut demander à l'utilisateur de donner un code, ou on peut le
générer à sa place, mais pour moi ça revient à faire de
l'autoincrément... On peut aussi utiliser la description comme PK,
mais je ne trouve ça pas très "joli" surtout quand on va venir la
référencer dans d'autres tables...
Première chose à imaginer : les données. Tu vas avoir besoin d'une base de données avec les tables suivantes [Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P), Eleve_mot de passe,...) [Examen] (Examen_uid (P), Examen_description) [Notes] (Examen_uid, Eleve_login, Notes_note)
Tu vas avoir un module permettant aux élèves de rentrer leur notes dans la base. Tu utilise un .htaccess pour utiliser l'authentification d'Apache. Les élèves rentrent leurs notes pour chaque examen.
Un deuxième module permettra de faire du reporting (ton tableau global) qui reprendra le classement ainsi que la moyenne de chaque élève.
La réalisation d'une telle application est un très bon exercice de mise en oeuvre de PHP, même pour quelqu'un qui débute. Tu devrais pouvoir t'y retrouver facilement avec les tutoriels présents un peu partout.
Question pour John mainenant : J'ai ici fait une table [Examen]. A maintes et maintes reprises tu expliques qu'il ne faut pas faire d'auto-increment ou autre séquence. Comment ferais tu dans le cas de la table [Examen] pour générer une clé primaire. Ce genre de table existe dans beaucoup d'applications (Clé/Description) et il n'est pas toujours évident de générer un clé à partir de la description.
On peut demander à l'utilisateur de donner un code, ou on peut le générer à sa place, mais pour moi ça revient à faire de l'autoincrément... On peut aussi utiliser la description comme PK, mais je ne trouve ça pas très "joli" surtout quand on va venir la référencer dans d'autres tables...
John GALLET
Bonjour,
Première chose à imaginer : les données. Moi perso la première chose que j'imaginerais, ce sont les **fausses**
données :-) Si j'étais encore élève et qu'on ME demande de rentrer mes notes, ça me démangerait sacrément de me tromper par inadvertance en frappant sur les touches du clavier :-)))
Tu vas avoir besoin d'une base de données avec les tables suivantes [Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P), Eleve_mot de passe,...) [Examen] (Examen_uid (P), Examen_description) [Notes] (Examen_uid, Eleve_login, Notes_note)
Probablement aussi une liste de matières/modules.
Question pour John mainenant : J'ai ici fait une table [Examen]. A maintes et maintes reprises tu expliques qu'il ne faut pas faire d'auto-increment ou autre séquence.
Soyons précis sur ma position là dessus sinon on va encore m'accuser de tous les maux de la Terre : il ne faut pas les employer à tour de bras. C'est un pis-aller, une solution de repli, et non pas la solution par défaut à appliquer connement et sans comprendre ce que l'on fait.
Dans la plupart des cas, il existe une clef primaire fonctionnelle réelle. Si on choisit de la coupler à une clef "muette" (par exemple autoinc/syb_identity) il est évident qu'il faut mettre une restriction unique sur la vraie clef fonctionnelle de la table.
Exemple pour les boursicoteurs : les positions d'un portefeuille. Une position, c'est une valeur (identifiée par son code valeur international) ouverte pour un compte titres (identifié dans le système interne du broker) sur une place de négociation (identifiée par un code ISO international, Paris 5, NYSE/NASDAQ5/067 etc...) à laquelle on associe une quantité de titres.
Il est très clair que la clef primaire de cette table est le triplet (numéro de compte titre, code valeur, place de négo) auquel on associe un attribut "quantité de titres" et il serait TOTALEMENT DEBILE de mettre une autre clef primaire sur cette table (dans la vraie vie, d'ailleurs, on a aussi un type de position : SRD, sous dossier, bloqué monep, nantie, etc..., on aura donc une PK à 4 colonnes, et c'est normal).
En revanche, on a déjà vu dans cet exemple que les trois clefs étrangères qui la composent sont des clefs muettes. C'est pas 1,2,3... mais ces clefs n'ont de signification que celle que des conventions (internes à l'application, ou internationales) veulent bien leur donner.
Noter qu'il existe aussi des entités pour lesquelles on est incapble de donner une clef primaire fonctionnelle, elle ne pourra être que muette, il suffit de lire son relevé de compte en banque du mois pour en avoir un exemple : rien n'empêche que le même compte, à la même date de valeur, fasse deux retraits de la même somme au même GAB. Donc à part l'identifiant interne à la banque de l'opération, qui est totalement muet, on a pas de clef sur cette table.
la table [Examen] pour générer une clé primaire. Pour moi un examen valide une période de temps scolaire pour une matière.
Donc en entités, on a surtout la notion de trimestres/semestres/etc et de matières enseignées (si multimatières). L'examen est une association entre ces entités, porteur de la note pour un élève.
On peut demander à l'utilisateur de donner un code, ou on peut le générer à sa place, mais pour moi ça revient à faire de l'autoincrément...
Sur le fond, comme tu les présentes, ce sont deux clefs muettes. Il te faudra une contrainte autre en unique pour éviter les doublons.
Prenons par exemple la notion de durée scolaire. Tu fais saisir à l'administrateur ses durées. Il va entrer : "Premier trimestre", "Deuxième trimestre", "Troisième trimestre" ou "Premier Bimestre", "deuxième bimestre", un truc de ce genre. La théorie des SGBDR te dit que tu as la clef primaire de l'entité : ce texte te suffit à identifier de manière unique une instance de l'entité, et comme il est composé d'un seul attribut, tu ne risque pas de trouver un plus petit sous ensemble. Maintenant dans la vraie vie, on va trop souvent voir une PK en autoincrement (jusque là tout va bien) mais sans la contrainte unique sur le texte (et là plouf, quand toto va cliquer 20 fois sur refresh, j'aurais 20 fois la même donnée dans la table, à tchao bon ménage).
On peut aussi utiliser la description comme PK, mais je ne trouve ça pas très "joli" surtout quand on va venir la référencer dans d'autres tables... La théorie au sens de Codd ne te l'interdit pas. Si tu préfère mettre un
entier tout aussi muet (cette chaîne 'Premier semestre' n'a pas plus de signification que 1 ou 5 si ce n'est la convention qu'on lui donne) tu peux, du moment que tu n'oublie pas le UNIQUE.
Pour rappel, la définition d'une clef primaire selon Codd : la clef primaire d'une entité est le plus petit (sous) ensemble d'attributs de cette entité permettant d'identifier une de ses instances de manière unique. Nulle part il est écrit qu'on était obligés de prendre un seul attribut, ni que son domain devait nécessairement être de type entier.
a++; JG
Bonjour,
Première chose à imaginer : les données.
Moi perso la première chose que j'imaginerais, ce sont les **fausses**
données :-)
Si j'étais encore élève et qu'on ME demande de rentrer mes notes, ça
me démangerait sacrément de me tromper par inadvertance en frappant sur
les touches du clavier :-)))
Tu vas avoir besoin d'une base de données avec les tables suivantes
[Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P),
Eleve_mot de passe,...)
[Examen] (Examen_uid (P), Examen_description)
[Notes] (Examen_uid, Eleve_login, Notes_note)
Probablement aussi une liste de matières/modules.
Question pour John mainenant : J'ai ici fait une table [Examen]. A
maintes et maintes reprises tu expliques qu'il ne faut pas faire
d'auto-increment ou autre séquence.
Soyons précis sur ma position là dessus sinon on va encore m'accuser de
tous les maux de la Terre : il ne faut pas les employer à tour de bras.
C'est un pis-aller, une solution de repli, et non pas la solution par
défaut à appliquer connement et sans comprendre ce que l'on fait.
Dans la plupart des cas, il existe une clef primaire fonctionnelle réelle.
Si on choisit de la coupler à une clef "muette" (par exemple
autoinc/syb_identity) il est évident qu'il faut mettre une restriction
unique sur la vraie clef fonctionnelle de la table.
Exemple pour les boursicoteurs : les positions d'un portefeuille. Une
position, c'est une valeur (identifiée par son code valeur international)
ouverte pour un compte titres (identifié dans le système interne du
broker) sur une place de négociation (identifiée par un code ISO
international, Paris 5, NYSE/NASDAQ5/067 etc...) à laquelle on
associe une quantité de titres.
Il est très clair que la clef primaire de cette table est le triplet
(numéro de compte titre, code valeur, place de négo) auquel on associe un
attribut "quantité de titres" et il serait TOTALEMENT DEBILE de mettre une
autre clef primaire sur cette table (dans la vraie vie, d'ailleurs, on a
aussi un type de position : SRD, sous dossier, bloqué monep, nantie,
etc..., on aura donc une PK à 4 colonnes, et c'est normal).
En revanche, on a déjà vu dans cet exemple que les trois clefs étrangères
qui la composent sont des clefs muettes. C'est pas 1,2,3... mais ces clefs
n'ont de signification que celle que des conventions (internes à
l'application, ou internationales) veulent bien leur donner.
Noter qu'il existe aussi des entités pour lesquelles on est incapble de
donner une clef primaire fonctionnelle, elle ne pourra être que muette, il
suffit de lire son relevé de compte en banque du mois pour en avoir un
exemple : rien n'empêche que le même compte, à la même date de valeur,
fasse deux retraits de la même somme au même GAB. Donc à part
l'identifiant interne à la banque de l'opération, qui est totalement muet,
on a pas de clef sur cette table.
la table [Examen] pour générer une clé primaire.
Pour moi un examen valide une période de temps scolaire pour une matière.
Donc en entités, on a surtout la notion de trimestres/semestres/etc et de
matières enseignées (si multimatières). L'examen est une association entre
ces entités, porteur de la note pour un élève.
On peut demander à l'utilisateur de donner un code, ou on peut le
générer à sa place, mais pour moi ça revient à faire de
l'autoincrément...
Sur le fond, comme tu les présentes, ce sont deux clefs muettes. Il te
faudra une contrainte autre en unique pour éviter les doublons.
Prenons par exemple la notion de durée scolaire. Tu fais saisir à
l'administrateur ses durées. Il va entrer : "Premier trimestre", "Deuxième
trimestre", "Troisième trimestre" ou "Premier Bimestre", "deuxième
bimestre", un truc de ce genre. La théorie des SGBDR te dit que tu as la
clef primaire de l'entité : ce texte te suffit à identifier de manière
unique une instance de l'entité, et comme il est composé d'un seul
attribut, tu ne risque pas de trouver un plus petit sous ensemble.
Maintenant dans la vraie vie, on va trop souvent voir une PK en
autoincrement (jusque là tout va bien) mais sans la contrainte unique sur
le texte (et là plouf, quand toto va cliquer 20 fois sur refresh, j'aurais
20 fois la même donnée dans la table, à tchao bon ménage).
On peut aussi utiliser la description comme PK,
mais je ne trouve ça pas très "joli" surtout quand on va venir la
référencer dans d'autres tables...
La théorie au sens de Codd ne te l'interdit pas. Si tu préfère mettre un
entier tout aussi muet (cette chaîne 'Premier semestre' n'a pas plus de
signification que 1 ou 5 si ce n'est la convention qu'on lui donne) tu
peux, du moment que tu n'oublie pas le UNIQUE.
Pour rappel, la définition d'une clef primaire selon Codd : la clef
primaire d'une entité est le plus petit (sous) ensemble d'attributs de
cette entité permettant d'identifier une de ses instances de manière
unique. Nulle part il est écrit qu'on était obligés de prendre un
seul attribut, ni que son domain devait nécessairement être de type
entier.
Première chose à imaginer : les données. Moi perso la première chose que j'imaginerais, ce sont les **fausses**
données :-) Si j'étais encore élève et qu'on ME demande de rentrer mes notes, ça me démangerait sacrément de me tromper par inadvertance en frappant sur les touches du clavier :-)))
Tu vas avoir besoin d'une base de données avec les tables suivantes [Eleve] (Eleve_Nom, Eleve_Prnom, Eleve_Promotion, Eleve_login (P), Eleve_mot de passe,...) [Examen] (Examen_uid (P), Examen_description) [Notes] (Examen_uid, Eleve_login, Notes_note)
Probablement aussi une liste de matières/modules.
Question pour John mainenant : J'ai ici fait une table [Examen]. A maintes et maintes reprises tu expliques qu'il ne faut pas faire d'auto-increment ou autre séquence.
Soyons précis sur ma position là dessus sinon on va encore m'accuser de tous les maux de la Terre : il ne faut pas les employer à tour de bras. C'est un pis-aller, une solution de repli, et non pas la solution par défaut à appliquer connement et sans comprendre ce que l'on fait.
Dans la plupart des cas, il existe une clef primaire fonctionnelle réelle. Si on choisit de la coupler à une clef "muette" (par exemple autoinc/syb_identity) il est évident qu'il faut mettre une restriction unique sur la vraie clef fonctionnelle de la table.
Exemple pour les boursicoteurs : les positions d'un portefeuille. Une position, c'est une valeur (identifiée par son code valeur international) ouverte pour un compte titres (identifié dans le système interne du broker) sur une place de négociation (identifiée par un code ISO international, Paris 5, NYSE/NASDAQ5/067 etc...) à laquelle on associe une quantité de titres.
Il est très clair que la clef primaire de cette table est le triplet (numéro de compte titre, code valeur, place de négo) auquel on associe un attribut "quantité de titres" et il serait TOTALEMENT DEBILE de mettre une autre clef primaire sur cette table (dans la vraie vie, d'ailleurs, on a aussi un type de position : SRD, sous dossier, bloqué monep, nantie, etc..., on aura donc une PK à 4 colonnes, et c'est normal).
En revanche, on a déjà vu dans cet exemple que les trois clefs étrangères qui la composent sont des clefs muettes. C'est pas 1,2,3... mais ces clefs n'ont de signification que celle que des conventions (internes à l'application, ou internationales) veulent bien leur donner.
Noter qu'il existe aussi des entités pour lesquelles on est incapble de donner une clef primaire fonctionnelle, elle ne pourra être que muette, il suffit de lire son relevé de compte en banque du mois pour en avoir un exemple : rien n'empêche que le même compte, à la même date de valeur, fasse deux retraits de la même somme au même GAB. Donc à part l'identifiant interne à la banque de l'opération, qui est totalement muet, on a pas de clef sur cette table.
la table [Examen] pour générer une clé primaire. Pour moi un examen valide une période de temps scolaire pour une matière.
Donc en entités, on a surtout la notion de trimestres/semestres/etc et de matières enseignées (si multimatières). L'examen est une association entre ces entités, porteur de la note pour un élève.
On peut demander à l'utilisateur de donner un code, ou on peut le générer à sa place, mais pour moi ça revient à faire de l'autoincrément...
Sur le fond, comme tu les présentes, ce sont deux clefs muettes. Il te faudra une contrainte autre en unique pour éviter les doublons.
Prenons par exemple la notion de durée scolaire. Tu fais saisir à l'administrateur ses durées. Il va entrer : "Premier trimestre", "Deuxième trimestre", "Troisième trimestre" ou "Premier Bimestre", "deuxième bimestre", un truc de ce genre. La théorie des SGBDR te dit que tu as la clef primaire de l'entité : ce texte te suffit à identifier de manière unique une instance de l'entité, et comme il est composé d'un seul attribut, tu ne risque pas de trouver un plus petit sous ensemble. Maintenant dans la vraie vie, on va trop souvent voir une PK en autoincrement (jusque là tout va bien) mais sans la contrainte unique sur le texte (et là plouf, quand toto va cliquer 20 fois sur refresh, j'aurais 20 fois la même donnée dans la table, à tchao bon ménage).
On peut aussi utiliser la description comme PK, mais je ne trouve ça pas très "joli" surtout quand on va venir la référencer dans d'autres tables... La théorie au sens de Codd ne te l'interdit pas. Si tu préfère mettre un
entier tout aussi muet (cette chaîne 'Premier semestre' n'a pas plus de signification que 1 ou 5 si ce n'est la convention qu'on lui donne) tu peux, du moment que tu n'oublie pas le UNIQUE.
Pour rappel, la définition d'une clef primaire selon Codd : la clef primaire d'une entité est le plus petit (sous) ensemble d'attributs de cette entité permettant d'identifier une de ses instances de manière unique. Nulle part il est écrit qu'on était obligés de prendre un seul attribut, ni que son domain devait nécessairement être de type entier.
