Insérer les données d'un bouton dans la bdd

Fermé
ouaksad Messages postés 1 Date d'inscription vendredi 26 octobre 2018 Statut Membre Dernière intervention 26 octobre 2018 - 26 oct. 2018 à 10:14
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 7 déc. 2018 à 19:10
Bonjour tout le monde,

je suis entrain de développer une application pour la gestion des absents dans une classe avec le plan de la salle de cours.

j'ai commencé par schématisé le plan de la salle en html, les places sont représente par des boutons au clique il change de couleur

le but c'est que lorsque l’élève se connecte avec son E-mail et son mdp il choisi la salle dont il à cours puis il clique sur la place qu'il vas occupé (le bouton) ce dernier insère le nom du bouton dans la bdd
ensuite le prof quand il vas se connecté, il sélectionne la salle et la classe avec qui il a cours pour récupérer le plan de cette salle avec les tout les boutons rouge pour les places occupé et pas de couleur pour les places non occupé

ma question est comment faire la base de données

voici sur quoi je suis partie:

Table eleves: id/ nom / prenom / email / mdp
table salles: id/ nom
Table places: id /id_eleves / id_salles / zone/ statut

vous en pensez quoi ?
A voir également:

2 réponses

yg_be Messages postés 22696 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 17 avril 2024 1 471
26 oct. 2018 à 16:06
bonjour, moi, au lieu de la table places que tu proposes, je ferais deux tables:
- une table places, avec les données permanentes de la place (id / id_salle / zone)
- une table presences, avec id, id_place, id-eleve

au départ, cela ne fait pas de différence, mais cela aidera peut-être ensuite, par exemple si tu veux garder un historique des présences.
0
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 137
7 déc. 2018 à 19:10
Je t'invite avant tout à rédiger avec Word un texte décrivant le plus précisement possible le problème. Relis-le, corrige-le et quand il correspondra exactement à la sitation, ce texte sera ta référence, ton "cahier des charges". Dans ce texte il y aura des mots et des verbes. Les mots t'orienteront vers des objets de gestion (qui deviendront en général des tables) et les verbes t'orienteront vers les relations qui existent entre ces objets. Dans certains cas (relations n-aires) les verbes deviendront des tables, dans d'autres cas (relations une-aires) il y aura migration de l'identifiant d'une table vers l'autre table. Exemple très sommaire :

Les salles contiennent des tables ; des élèves s'assoient à des tables.

mots : salles, tables, élèves. => trois objets => trois tables
verbes : contenir, s'asseoir. Tout dépend du type de relation.

salle--1,n----contenir----1,1--table :
relation une-aire => migration (la table 'Table' contiendra outre ses champs, l'ID de la salle)

elève--1,n----s'asseoir----0,n--table :
relation n-aire => création d'une table asseoir (qui contiendra les ID des deux tables et formera l'ID de la relation)

Tables :

Salle(IDs, nom, étage, etc...)
Table(IDt, IDs, etc...)
Eleve(IDe, nom, prenom, email, mdp, etc...)
Asseoir(IDe, IDt, date_heure, etc...)

NB les identifiants (clefs primaires) sont soulignés. Les clefs étrangères en italiques.

La table Asseoir a comme identifiant (clef primaire) les identifiants de tous les objets qui participent à la relation (Elève, Table) et en tant qu'identifiant, il ne pourra apparaître qu'une seule fois. Ceci veut dire que si l'élève 12 s'asseoit à la table 47, l'identifiant sera "12 47" et n'apparaîtra pas une seconde fois. Le SGBD refusera. En clair l'élève ne pourra plus jamais s'asseoir sur une place qu'il a déjà occupée. Il faut donc un autre élément à inclure pour avoir un autre dentifiant tel que "12 47 2018-12-07 10:00:00". (tel élève sur telle table à tel moment)

Je te conseille d'utiliser les mêmes mots ou mêmes verbes pour dénommer tes tables. Au moins, au premier coup d'oeil, tu vois à quoi elles servent.

Il est fort possible que cet exemple ne corresponde pas exactement à ton besoin car celui-ci n'est pas particulièrement détaillé et les cardinalités (1,n ; 0,n ; 1,1) dépendent de la gestion à affectuer.
C'est juste un exemple pour dire que la description précise du problème dans un texte servant de référence est indispensable et aide à la construction de la BDD.

Les cardinalités peuvent être :
0 = 0 fois
1 = une fois
n = plusieurs fois
Il y a cardinalité minimale et cardinalité maximale (nombres de fois que l'objet participe à la relation. Exemples: salle--1,n----contenir----1,1--table
- Salle. Combien de fois au minimum une salle participe à la relation contenir => 1 fois (au minimum une table dans une salle). Et au maximum ? => plusieurs fois (plusieurs tables dans la même salle). donc cmin,cmax = 1,n (salle : une fois ou plusieurs)
- Table. Combien de fois au minimum une table participe à la relation contenir => 1 fois. Et au maximum => 1 fois. Une table est dans une salle et une seule. (table : une fois et une seule)
etc...

relation n-aire : toutes les cmax sont à n (=> creation table)
relation une-aire : au moins 1 cmax est à 1 (=> migration. L'objet cmax=1 reçoit l'identifiant de l'autre)

Donc l'exemple illuste un peu j'espère ce que je veux dire mais il faut déterminer avec exactitude ta gestion. J'espère avoir été clair...
0