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
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
A voir également:
- Insérer les données d'un bouton dans la bdd
- Insérer signature word - Guide
- Insérer une vidéo dans powerpoint - Guide
- Insérer liste déroulante excel - Guide
- Insérer un sommaire word - Guide
- Effacer les données de navigation - Guide
2 réponses
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 461
26 oct. 2018 à 16:06
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.
- 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.
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
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...
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...