[BASE] un formulaire avec un nombre d'entrée variable

Bonjour,
désolé pour le titre, j'ai juste essayé d'être clair et précis (failed).

Je suis prof (pimaire) et je cherche à pouvoir faire une base de données pour l'élaboration de mes séquences (une séquence, c'est plusieurs séances de 30-40 min. ou moins qui visent à l'apprentissage d'une compétence, d'un savoir).

Bien sûr, une séquence de révision peut comporter 3 séances et une autre, sur un point du programme plus complexe, une dizaine de séances.

Ce que je sais faire :
- une table avec les champs qui vont bien pour les séquences et pour les séances
- je sais me servir (un peu) de la création de lien entre les champs de tables
- je sais ce qu'est un formulaire

Ce que je ne sais pas faire et qui est l'objet de mon message :
- Faire en sorte que dans un formulaire commun pour toutes les séquences, je puisse modifier aisément (c'est important) le nombre d'entrées de séances à remplir et les associant à la séquence en cours d'élaboration.

Pour simplifier : une table "séquences" (avec des champs "titre", "classe", "objectifs", etc.) et une table "séances" ( avec des champs "titre", "déroulement", durée, objectifs spécifiques, etc.)

Cordialement

Bonjour,
Si j'entends bien le problème posé, je pense que vos 2 tables "Séquences" et "Séances" peuvent être mises en relation de type 1 à plusieurs. (1 à n) On peut supposer que pour 1 Séquence il peut y avoir plusieurs séances. Votre clé primaire sera un champ : ref_séquence, qui sera bien évidemment présent dans les 2 tables et qui fera le lien entre ces 2 tables.. (votre table séances aura sa propre clé primaire: ID ... ,c'est strictement nécessaire). Vous pourrez ensuite faire un formulaire pour remplir les différents champs: plus exactement un formulaire principal : champs de la table "séquences" et un sous-formulaire donnant les champs de la table "séances". Vous aurez ainsi la possibilité de modifier à loisir les champs: titre, durée, déroulement, etc...
cordialement
claude

Bonjour,

Je pense si j'ai bien compris le problème de Sylvain que la solution de Claude ne va pas suffire !
Car je pense qu'une même séance peut aussi appartenir aussi à plusieurs séquences différentes... Je pense qu'il va falloir rajouter une table de jointure car cela me parait plutôt une relation de type n à n ...
Comme je suis TRÈS loin d'être un spécialiste en base de données, je préfère laisser à d'autres le soin de d’expliquer comment faire si Sylvain confirme le type de relation...

Cordialement
Bruno

Bruno,
Rien n'empêche dans l'organisation des tables proposée de définir une même séance pour plusieurs séquences différentes.
Cordialement
Claude

Claude,

Oui mais si "ref_séquence" est dans les 2 tables : En clé primaire dans la table séquence ce qui est logique, mais aussi dans la table Séance (pour créer le lien entre les 2 tables), comment pointer sur plusieurs séquences avec un seul champ dans la table séance???

Mais bon, je suppose que je dois oublier quelque chose car je n'ai que des connaissances très théoriques des bases de données relationnelles...
La seule base de données que j'ai vraiment créée et utilisée a grande échelle est un programme de généalogie que je m'étais fait à la fin des années 80 sous DOS et DBASE III (que j'utilise toujours) et qui contient plus de 20.000 enregistrements, mais qui aurait en fait besoin d'être complètement réécrit...

Bonsoir,

Oui mais si "ref_séquence" est dans les 2 tables : En clé primaire dans
la table séquence ce qui est logique, mais aussi dans la table Séance
(pour créer le lien entre les 2 tables), comment pointer sur plusieurs
séquences avec un seul champ dans la table séance???

C'est ce qu'on appelle une relation de n à n. Ceci ne peut se réaliser
qu'au moyen d'une troisième table qui enregistre un identifiant de la
première table avec un identifiant de la deuxième.

Exemple :
Un auteur peut écrire plusieurs livres. Un livre peut avoir plusieurs
auteurs.

T_Livres
id_livre, isbn, editeur

T_Auteurs
id_auteur, nom

T_AuteursLivres
id_livre, id_auteur

-> Un livre qui aura plusieurs auteurs sera représenté par plusieurs
enregistrements dans T_AuteursLivres.

C'est ce que j'avais dit avec d'autres mots dans mon 1er message ...
Une relation n à n, nécessitant une 3eme table de jointure ... la 3eme de ta liste !

Bruno

Exact. Je n'ai parcouru ce fil qu'en diagonale. Désolé d'avoir omis de
le rappeler :slight_smile:

Bonjour,
Attention, si mes souvenirs sont exacts les identifiants de la table de jointure ne doivent être déclarés comme clé, ils servent juste à créer cette jointure.
Cordialement
Michel B.

Bonjour,
Ma compréhension du problème posé par Sylvain m'indique qu'une relation de 1 à n devrait être suffisante.
Quant à la situation de la gestion d'une bibliothèque, je ne pense pas qu'un livre, c'est-à-dire un titre puisse avoir plusieurs auteurs , ou c'est du plaggia ....un auteur, ou un groupe d'auteurs (2 frères D'Arvor par exemple) peut commettre un ouvrage, c'est à chaque fois une référence différentes dans la Table T_ AUTEURS. Maintenant je veux bien que l'on me donne un exemple qui infirme mon propos.
Une gestion de Tables en relations de type "n à n" n'est pas facile à gérer, alors bien réfléchir avant, de l'opportunité de cette organisation.
Cordialement
Claude

Pour citer un exemple:
La série de 32 romans mettant en scène le personnage de "Fantomas", repris au cinéma avec Louis de Funès et Jean Marais dans les années 60 a été co-écrite par 2 auteurs a savoir Pierre Souvestre et Marcel Allain !!!
cf : http://fr.wikipedia.org/wiki/Fantômas

Cordialement,
Bruno

Ok Bruno et merci pour l'exemple sur lequel je rebondis: ma table T_AUTEURS aura dans ce cas:1 ref avec NOM== SOUVESTRE&ALLAIN qui pointera dans la table T_OUVRAGES avec une ref à Fantomas ! ce qui n'empêchera pas d'avoir une autre ref NOM==SOUVESTRE qui pointe sur un autre ouvrage (si toutefois il n'a ps fait que du Fantomas !)
cordialement
Claude

Bonjour,

Et si, avec ta méthode, tu fais une recherche sur l'ensemble des ouvrages écrits par Pierre Souvestre, qu'il les ait écrits seul ou qu'il ait participé à l'écriture avec un ou plusieurs autres auteurs, est-ce que ta méthode te permettra de sortir cette information en une seule opération et avec la certitude que le Souvestre apparaissant comme co-auteur des romans de la série FANTOMAS est le même que le Pierre SOUVESTRE auteur en 1907 de "Histoire de l'Automobile" ?

Prenons un exemple plus proche de nous ; imaginons que tu doives entrer dans ta table des ouvrage, un livre paru en 2012 aux éditions Eyrolles et intitulé "De OpenOffice.org à LibreOffice 3.5" ; cette fois, ils s'y sont mis à 5 pour l'écrire, il y avait Sophie Gautier, Gilles Bignebat, Christian Hardy et Michel Pinquier et l'éditeur mentionne la contribution de Jean-François Nifenecker ; comment tu renseignes les auteurs dans ta table T_Auteurs ? Si j'ai bien compris ce que tu as écrit tu va mettre Gauthier&Bignebat&Hardy&Pinquier&Nifenecker.

Maintenant, tu dois aussi entrer un autre ouvrage, paru en Mars 2009 et intitulé "OpenOffice.org 3 efficace" écrit par Sophie Gauthier, Laurent Godard et Christian Hardy ; cette fois, si j'ai bien compris, tu vas créer un auteur appelé Gautier&Godard&Hardy ?

Le problème, c'est que Sophie Gauthier elle écrit souvent à plusieurs mains et pas toujours avec les mêmes mains ; ainsi, on lui trouve une collaboration avec un autre duo, composé de Christian Hardy et de Frédéric Labbé , puis un autre composé de Michel Pinquier et de Christian Hardy et avec un trio composé de Christian Hardy, de Fédéric Labbé et de Michel Pinquier.

Et en plus, il lui est arrivé des commettre des ouvrages toute seule.

Du coup, comment se comporte ta table à son égard ? Tu vas créer autant d'auteurs différents qu'il y aura de compositions différentes ? Mais si un jour tu veux identifier tous les ouvrages dont elle est l'auteur ou le co-auteur, est-ce que ta table le permettra en une seule requête ou est-ce que tu devras interroger ta table autant de fois qu'il existe de formes différentes sous laquelle elle apparaît parmi les auteurs ? Et que se passe-t-il s'il existe une autre Sophie Gauthier qui se met à écrire des ouvrages sur des sujets totalement différents (ou pas d'ailleurs) ?

De mon point de vue, une même personne ne doit apparaître qu'une seule fois dans la table Auteurs, de sorte que l'on ne puisse jamais avoir à se demander, par exemple, si le "Gauthier" qui apparaît au milieu de "Gauthier&Bignebat&Hardy&Pinquier&Nifenecker" comme auteur de "De OpenOffice.org à LibreOffice 3.5" est la Sophie Gauthier de "OpenOffice.org 2 efficace" ou si c'est une autre personne.

Sur ce principe :
- un ouvrage n'apparaît qu'une fois dans la table des ouvrages ;
- un auteur unique n'apparaît qu'une fois dans la table des auteurs ;
- la relation entre les uns et les autres apparaît dans une troisième table, l'id_ouvrage d'un ouvrage comptant 5 auteur apparaissant alors 5 fois dans cette table avec, à chaque ligne, une id_auteur différente.

De cette façon, la Sophie Gauthjier qui a écrit ou co-écrit les ouvrages évoqués ci-dessus se verra créditée de tous ses ouvrages en une seule fois lorsqu'on interrogera la base de données et s'il y a une autre Sophie Gauthier, plutôt spécialisée dans les livres de cuisine mais qui a commis elle aussi un ouvrage sur l'informatique, chaque Sophie Gauthier ne sera créditée QUE de ses ouvrages mais de TOUS ses ouvrages.

Donc oui, c'est probablement un peu plus fastidieux à mettre en oeuvre ; mais à mon avis, ce sera une base beaucoup plus facile à exploiter, à maintenir et même à faire évoluer au fil des besoins.

Pour ma part, je retiendrais la solution préconisée par Jean-François Nifenecker.

A+

Du point de vue base de données pure, logiquement on fait une table de jointure type "auteurs_ouvrages" (avec l'hypothèse qu'on a les tables "auteurs" et "ouvrages") dans laquelle chaque ligne comporte :
- id
- ouvrage_id
- auteur_id

Ceci permet la relation 1 à N de auteur à ouvrage.
Dans cette table, l'id s'auto-incrémente et on aura éventuellement plusieurs lignes avec le même ouvrage mais différents auteurs, se qui permet de retrouver tous les auteurs d'un ouvrage ou tous les ouvrages auquel un auteur a participé ...

----- Mail original -----

Bonjour,

Ok Bruno et merci pour l'exemple sur lequel je rebondis: ma table T_AUTEURS aura dans ce cas:1 ref avec NOM== SOUVESTRE&ALLAIN qui pointera dans la table T_OUVRAGES avec une ref à Fantomas ! ce qui n'empêchera pas d'avoir une autre ref NOM==SOUVESTRE qui pointe sur un autre ouvrage (si toutefois il n'a ps fait que du Fantomas !)
cordialement
Claude

Bonjour,

Et si, avec ta méthode, tu fais une recherche sur l'ensemble des ouvrages écrits par Pierre Souvestre, qu'il les ait écrits seul ou qu'il ait participé à l'écriture avec un ou plusieurs autres auteurs, est-ce que ta méthode te permettra de sortir cette information en une seule opération et avec la certitude que le Souvestre apparaissant comme co-auteur des romans de la série FANTOMAS est le même que le Pierre SOUVESTRE auteur en 1907 de "Histoire de l'Automobile" ?

Exact, ils n'ont pas toujours écrit à 2

Prenons un exemple plus proche de nous ; imaginons que tu doives entrer dans ta table des ouvrage, un livre paru en 2012 aux éditions Eyrolles et intitulé "De OpenOffice.org à LibreOffice 3.5" ; cette fois, ils s'y sont mis à 5 pour l'écrire, il y avait Sophie Gautier, Gilles Bignebat, Christian Hardy et Michel Pinquier et l'éditeur mentionne la contribution de Jean-François Nifenecker ; comment tu renseignes les auteurs dans ta table T_Auteurs ? Si j'ai bien compris ce que tu as écrit tu va mettre Gauthier&Bignebat&Hardy&Pinquier&Nifenecker.

Maintenant, tu dois aussi entrer un autre ouvrage, paru en Mars 2009 et intitulé "OpenOffice.org 3 efficace" écrit par Sophie Gauthier, Laurent Godard et Christian Hardy ; cette fois, si j'ai bien compris, tu vas créer un auteur appelé Gautier&Godard&Hardy ?

Le problème, c'est que Sophie Gauthier elle écrit souvent à plusieurs mains et pas toujours avec les mêmes mains ; ainsi, on lui trouve une collaboration avec un autre duo, composé de Christian Hardy et de Frédéric Labbé , puis un autre composé de Michel Pinquier et de Christian Hardy et avec un trio composé de Christian Hardy, de Fédéric Labbé et de Michel Pinquier.

Et en plus, il lui est arrivé des commettre des ouvrages toute seule.

Du coup, comment se comporte ta table à son égard ? Tu vas créer autant d'auteurs différents qu'il y aura de compositions différentes ? Mais si un jour tu veux identifier tous les ouvrages dont elle est l'auteur ou le co-auteur, est-ce que ta table le permettra en une seule requête ou est-ce que tu devras interroger ta table autant de fois qu'il existe de formes différentes sous laquelle elle apparaît parmi les auteurs ? Et que se passe-t-il s'il existe une autre Sophie Gauthier qui se met à écrire des ouvrages sur des sujets totalement différents (ou pas d'ailleurs) ?

Non seulement faire autant de requêtes qu'il y a de formes différentes, mais aussi retrouver toutes ces formes .. et le problème qui fait que, par exemple, "Gautier&Godard&Hardy" serait un auteur différent de "Godard&Hardy&Gautier" il faudrait donc rechercher toutes les combinaisons possibles.....
Je ne sais pas s'il existe une autre Sophie Gautier qui écrit, mais nous connaissons tous le 2 Alexandre Dumas (père et fils) (rien a voir avec ma famille je précise !! HI HI) et j'ai aussi été confronté à 2 auteurs portant le même nom mais l'un est américain et l'autre anglais... les exemples sont sûrement légions...

De mon point de vue, une même personne ne doit apparaître qu'une seule fois dans la table Auteurs, de sorte que l'on ne puisse jamais avoir à se demander, par exemple, si le "Gauthier" qui apparaît au milieu de "Gauthier&Bignebat&Hardy&Pinquier&Nifenecker" comme auteur de "De OpenOffice.org à LibreOffice 3.5" est la Sophie Gauthier de "OpenOffice.org 2 efficace" ou si c'est une autre personne.

Sur ce principe :
- un ouvrage n'apparaît qu'une fois dans la table des ouvrages ;
- un auteur unique n'apparaît qu'une fois dans la table des auteurs ;
- la relation entre les uns et les autres apparaît dans une troisième table, l'id_ouvrage d'un ouvrage comptant 5 auteur apparaissant alors 5 fois dans cette table avec, à chaque ligne, une id_auteur différente.

Je suis d'accord.
Je me souviens toujours de ce m'avait dit un prof d'informatique au sujet des bases de données : Dans une base de données, une information ne doit exister Q'UNE ET UNE SEULE FOIS et il ne doit jamais y avoir de données redondantes sous peine de risques d’incohérences lors d'éventuelles mises à jour même si cela impose parfois des requêtes plus complexes pour sortir les informations voulues. Si la majorité des requêtes sont exagérément complexes il faut alors revoir la structure de la base de données.

De cette façon, la Sophie Gauthjier qui a écrit ou co-écrit les ouvrages évoqués ci-dessus se verra créditée de tous ses ouvrages en une seule fois lorsqu'on interrogera la base de données et s'il y a une autre Sophie Gauthier, plutôt spécialisée dans les livres de cuisine mais qui a commis elle aussi un ouvrage sur l'informatique, chaque Sophie Gauthier ne sera créditée QUE de ses ouvrages mais de TOUS ses ouvrages.

Donc oui, c'est probablement un peu plus fastidieux à mettre en oeuvre ; mais à mon avis, ce sera une base beaucoup plus facile à exploiter, à maintenir et même à faire évoluer au fil des besoins.

Pour ma part, je retiendrais la solution préconisée par Jean-François Nifenecker.

Moi aussi

A+

Cordialement
Bruno

Bonjour,
De la simple question de Sylvain nous arrivons à une discussion, certes intéressante mais, je le crains dépasse le cadre de la demande initiale. J'admets qu'en théorie l'organisation des tables avec une mise en relation de type N à N tel que préconisé par certains intervenants est la réponse la plus complète à la question de la bibliothèque avec ces auteurs qui auraient écrits plusieurs ouvrages, (quoi de plus normal) et aussi des ouvrages portant même titre, qui auraient plusieurs auteurs ...Dans l'exemple de Jean-François relatif à ces ouvrages sur LibreOffice écrits par Sophie Gauthier, et autres pourquoi ne pas donner le nom "collectif libO" quitte à faire une info donnant la composition de ce collectif.
Par ailleurs, il est dit :

avec la certitude que le Souvestre apparaissant comme

co-auteur des romans de la série FANTOMAS est le même que le Pierre
SOUVESTRE auteur en 1907 de "Histoire de l'Automobile"

Ok, mais ceci est vrai pour beaucoup d'auteurs ...
J'ai proposé à "mes élèves" au club RIO, un exemple de création de BDD: Gestion de Bibliothèque, avec LibO , Je n'ai pas souhaité amener des complications en proposant une structure avec relations N à N. Il me semble que si la mise en place des tables et des relations puisse être relativement facile, où ça se complique c'est au moment de créer des requêtes, des formulaires, voire des rapports....D'ailleurs je suis preneur , à titre personnel, d'un exemple avec une telle organisation. Avec ACCESS il y a cet exemple connu: COMPTOIRS.mdb qui utilise la relation N à N , mais c'est ACCESS et il faut en convenir, LibO Base ne me parait pas au même niveau :wink:
Si je puis me permettre: Sylvain, qui semble débuter avec cette application, devrait pouvoir résoudre son problème avec des tables en relation 1 à n.
Cordialement
Claude

Bonjour,
Ci-joint une base de données exemple utilisant des relations variées.
Attention au démarrage, il faut attendre quelques secondes pour obtenir l'ouverture automatique plein écran.
Cordialement
Michel B.
http://www.inforbur.com/facturation.zip

Oupss ...
Erreur d'URL
http://inforbur.com/facturation.zip

Souci d'URL
http://www.inforbur.com/facturation.zip

Bonjour,

Petite incruste dans la conversation :slight_smile:

Du point de vue base de données pure, logiquement on fait une table de
jointure type "auteurs_ouvrages" (avec l'hypothèse qu'on a les tables
"auteurs" et "ouvrages") dans laquelle chaque ligne comporte :
- id
- ouvrage_id
- auteur_id

Je ne suis pas d'accord, id ne sert à rien, les champs auto généré ne
doivent être utilisé que lorsque cela est utile, or là ils ne le sont pas
car les deux Sophie n'ont pas le même id_auteur. Qui plus est en mettant
cette colonne la (en clé primaire composé de ce seul attribut) on peut
avoir plusieurs fois le même auteur sur le même bouquin, ce qui me parait
un peu déconcertant tout de même. Et en plus c'est pas en 2NF avec
l'attribut id. Donc selon moi :
- ouvrage_id*
- auteur_id*

Ceci permet la relation 1 à N de auteur à ouvrage.

Dans cette table, l'id s'auto-incrémente et on aura éventuellement
plusieurs lignes avec le même ouvrage mais différents auteurs, se qui
permet de retrouver tous les auteurs d'un ouvrage ou tous les ouvrages
auquel un auteur a participé ...

Dans tout les cas tu peux associer les auteurs à leurs bouquins ou les
livres à leurs auteurs, je ne vois pas en quoi la table de relation
rendrait cette tache plus complexe. Suffit simplement de joindre les trois
tables et de selectionner via soit l'id de l'auteur, soit l'id de l'ouvrage
en fonction du type de recherche.