Champs Numauto
Résolu/Fermé
domi6226
Messages postés
79
Date d'inscription
jeudi 12 juillet 2012
Statut
Membre
Dernière intervention
5 juin 2018
-
7 juil. 2013 à 18:28
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 14 juil. 2013 à 12:20
heliconius Messages postés 545 Date d'inscription mardi 1 juillet 2008 Statut Membre Dernière intervention 23 juin 2023 - 14 juil. 2013 à 12:20
3 réponses
Thorak83
Messages postés
1051
Date d'inscription
jeudi 20 juin 2013
Statut
Membre
Dernière intervention
22 décembre 2017
156
8 juil. 2013 à 11:21
8 juil. 2013 à 11:21
Bonjour,
Dans vos tables (sac, boule, repas...) avez vous mis le champ N°commande en NumAuto ?
Cordialement
Dans vos tables (sac, boule, repas...) avez vous mis le champ N°commande en NumAuto ?
Cordialement
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
Modifié par heliconius le 8/07/2013 à 12:50
Modifié par heliconius le 8/07/2013 à 12:50
Bonjour,
Je ne voudrais pas paraître grincheux mais pensez un peu à ce que disait Einstein : "Un problème sans solution est un problème mal posé." Comment voulez-vous qu'on puisse vous aider et en allant plus loin qu'on ait envie de vous aider, si l'on ne sait pas de quoi il s'agit ?
Vous commencez par : "J'ai une table suivi ... J'ai créé un formulaire en partant de ma table suivi ...etc...". On ne sait pas de quel suivi il s'agit (suivi du Tour de France, de la prise de poids, de la fabrication d'un produit ?...) on ne sait pas non plus la description des tables mises en causes.
Après prise de tête, il me semble (je dis bien : il me semble) avoir perçu la question. Vous me direz si c'est correct ou non.
Dans un milieu sportif, il s'agirait de suivre des commandes que pourraient effectuer des personnes (adhérente au club ou non), commandes qui seraient saisies dans un formulaire. Chaque personne pourrait commander plusieurs choses telles qu'un repas, un cours ou un tournoi.
Est-ce bien cela ? Si oui, il fallait peut-être commencer par là et ma réponse est fondée sur cette hypothèse.
Je ne connais pas la description des tables mises en cause mais je soupçonne une erreur dans la conception. Ma réponse risque d'être un peu longue mais j'espère qu'elle résoudra le problème.
Quand deux objets de gestion Merise sont en relation, il faut placer les cardinalités (minimales, maximales soit cmax et cmin) qui peuvent être 0, 1 ou n.
Exemple 1:
min: 0 => un client peut ne pas participer à la relation Acheter
max: n => un client peut participer plusieurs fois
Côté PRODUITS:
min: 0 => un type produit peut ne pas participer à la relation (ne pas être acheté)
max: n => un même type de produit peut être acheté plusierus fois
Exemple 2:
max: 1 => mais si elle participe, c'est une seule fois (bigamie non autorisée dans notre société)
Dans une société polygame cela pourrait donner
Exemple 3:
min: 1 => un élève est obligatoirement inscrit dans une classe sinon il ne serait pas élève
max: 1 => mais il n'est inscrit pour une année donnée que dans une seule classe
Côté CLASSES:
min: 1 => la classe participe au moins 1 fois à la relation (au moins pour 1 élève) sinon, elle ne serait pas ouverte pour l'année scolaire
max: n => mais elle peut participer plusieurs fois (plusieurs élèves)
Consctruction des tables:
1) En dehors de certains cas très particuliers non évoqués ici pour éviter de rallonger, tous les objets Merise donnent lieu à la création de table : PERSONNES, PRODUITS, ELEVES, CLASSES et doivent avoir leur identifiant qui seront clefs primaires.
2) En ce qui concerne les relations ("Acheter", "Marié à", "Inscrit en") :
a) si la relation est "n-aire" (toutes les cmax sont à n) : il y a création d'une table. C'est le cas de la relation "Acheter". Il y aura une table "Acheter" qui contiendra les identifiants des objets qui participent à la relation (PERSONNES, PRODUITS) et ces deux identifiants forment ensemble l'identifiant de la table acheter -clef primaire-
b) si la relation est "une-aire" (au moins l'une des cmax de la relation est à 1) : il n'y a pas de création de table mais migration ; c'est à dire que la table dont la cmax est à 1 recevra en plus de ses champs l'identifiant de l'autre. C'est le cas de l'exemple 3 ; ce champ migré sera une clef étrangère :
Les clef primaires numériques sont généralement auto_increment sous MySQL ou NuméroAuto sous Access
Les clefs étrangères sont généralement indexées sous MySQL et Index avec doublons sous Access
Si dans un formulaire/sous-formulaire de saisie on voulait faire la saisie des élèves, le formulaire serait basé sur la table CLASSES et le sous formulaire sur la table ELEVES. Le lien entre formulaire et sous-formulaire serait ID_classe.
Je ne suis pas en mesure d'en dire plus car je ne sais absolument rien sur la conception de votre base de données. Y a-til une table pour les cours, une pour les repas, une pour les tournois ou alors une seule pour tout cela (exemple: table PRESTATIONS) en partant du principe que ce sont différents articles d'une prestation ?
Mais il semblerait, a priori, que le formulaire pourrait être basé sur la table COMMANDES et le sous-formulaire sur une table PRESTATION et ID_commande serait clef primaire dans l'une et clef étrangère dans l'autre tel que :
ID_personne, ID_prestation, ID_commandes = clefs primaires, auto_increment (NuméroAuto)
Commander: ID_personne+ID_commande+ID_prestation = clef primaire
L'ensemble formulaire (PERSONNES, COMMANDES) / sous-formulaire (PRESTATIONS) ne viserait qu'à alimenter la table Commander sans NuméroAuto.
Je ne sais si j'ai répondu car c'est une réponse à l'estime étant donné que je ne sais rien de la conception sur la base de données. Mais de grâce, la prochaine fois, si vous souhaitez une réponse qui satisfasse la question, faites que celle-ci soit claire. Que l'on comprenne le problème, le contexte et qu'on ait les éléments pour pouvoir fournir la réponse attendue.
Bonne continuation.
Je ne voudrais pas paraître grincheux mais pensez un peu à ce que disait Einstein : "Un problème sans solution est un problème mal posé." Comment voulez-vous qu'on puisse vous aider et en allant plus loin qu'on ait envie de vous aider, si l'on ne sait pas de quoi il s'agit ?
Vous commencez par : "J'ai une table suivi ... J'ai créé un formulaire en partant de ma table suivi ...etc...". On ne sait pas de quel suivi il s'agit (suivi du Tour de France, de la prise de poids, de la fabrication d'un produit ?...) on ne sait pas non plus la description des tables mises en causes.
Après prise de tête, il me semble (je dis bien : il me semble) avoir perçu la question. Vous me direz si c'est correct ou non.
Dans un milieu sportif, il s'agirait de suivre des commandes que pourraient effectuer des personnes (adhérente au club ou non), commandes qui seraient saisies dans un formulaire. Chaque personne pourrait commander plusieurs choses telles qu'un repas, un cours ou un tournoi.
Est-ce bien cela ? Si oui, il fallait peut-être commencer par là et ma réponse est fondée sur cette hypothèse.
Je ne connais pas la description des tables mises en cause mais je soupçonne une erreur dans la conception. Ma réponse risque d'être un peu longue mais j'espère qu'elle résoudra le problème.
Quand deux objets de gestion Merise sont en relation, il faut placer les cardinalités (minimales, maximales soit cmax et cmin) qui peuvent être 0, 1 ou n.
Exemple 1:
[PERSONNES]-0,n-----(Acheter)-----0,n-[PRODUITS]Côté PERSONNES:
min: 0 => un client peut ne pas participer à la relation Acheter
max: n => un client peut participer plusieurs fois
Côté PRODUITS:
min: 0 => un type produit peut ne pas participer à la relation (ne pas être acheté)
max: n => un même type de produit peut être acheté plusierus fois
Exemple 2:
[PERSONNES]-0,1-----(Marié à)-----0,1-[PERSONNES]min: 0 => une personne peut ne pas participer à la relation (célibataire)
max: 1 => mais si elle participe, c'est une seule fois (bigamie non autorisée dans notre société)
Dans une société polygame cela pourrait donner
[PERSONNES]-0,n-----(Marié à)-----0,n-[PERSONNES]
Exemple 3:
[ELEVES]-1,1-----(Inscrit en)-----1,n-[CLASSES]Côté ELEVES:
min: 1 => un élève est obligatoirement inscrit dans une classe sinon il ne serait pas élève
max: 1 => mais il n'est inscrit pour une année donnée que dans une seule classe
Côté CLASSES:
min: 1 => la classe participe au moins 1 fois à la relation (au moins pour 1 élève) sinon, elle ne serait pas ouverte pour l'année scolaire
max: n => mais elle peut participer plusieurs fois (plusieurs élèves)
Consctruction des tables:
1) En dehors de certains cas très particuliers non évoqués ici pour éviter de rallonger, tous les objets Merise donnent lieu à la création de table : PERSONNES, PRODUITS, ELEVES, CLASSES et doivent avoir leur identifiant qui seront clefs primaires.
PERSONNES (ID_personne, nom, prenom, etc...) ELEVES (ID_eleve, nom, prenom, etc...) CLASSE (ID_classe, nom, lieu, etc...)
2) En ce qui concerne les relations ("Acheter", "Marié à", "Inscrit en") :
a) si la relation est "n-aire" (toutes les cmax sont à n) : il y a création d'une table. C'est le cas de la relation "Acheter". Il y aura une table "Acheter" qui contiendra les identifiants des objets qui participent à la relation (PERSONNES, PRODUITS) et ces deux identifiants forment ensemble l'identifiant de la table acheter -clef primaire-
PERSONNE (ID_personne, nom, prenom, etc...) Acheter (ID_personne, ID_produit) PRODUIT (ID_produit, libelle, prix, etc...)
b) si la relation est "une-aire" (au moins l'une des cmax de la relation est à 1) : il n'y a pas de création de table mais migration ; c'est à dire que la table dont la cmax est à 1 recevra en plus de ses champs l'identifiant de l'autre. C'est le cas de l'exemple 3 ; ce champ migré sera une clef étrangère :
CLASSE (ID_classe, nom, lieu, etc...) ELEVES (ID_eleve, nom, prenom, etc..., ID_classe)
Les clef primaires numériques sont généralement auto_increment sous MySQL ou NuméroAuto sous Access
Les clefs étrangères sont généralement indexées sous MySQL et Index avec doublons sous Access
Si dans un formulaire/sous-formulaire de saisie on voulait faire la saisie des élèves, le formulaire serait basé sur la table CLASSES et le sous formulaire sur la table ELEVES. Le lien entre formulaire et sous-formulaire serait ID_classe.
Je ne suis pas en mesure d'en dire plus car je ne sais absolument rien sur la conception de votre base de données. Y a-til une table pour les cours, une pour les repas, une pour les tournois ou alors une seule pour tout cela (exemple: table PRESTATIONS) en partant du principe que ce sont différents articles d'une prestation ?
Mais il semblerait, a priori, que le formulaire pourrait être basé sur la table COMMANDES et le sous-formulaire sur une table PRESTATION et ID_commande serait clef primaire dans l'une et clef étrangère dans l'autre tel que :
[PERSONNES]-0,n-----(Commander)-----0,n-[PRESTATION] '--------0,n-[COMMANDES] PERSONNES (ID_personne, nom, prenom, etc...) PRESTATIONS (ID_prestation, libelle, etc...) COMMANDES (ID_commande, date, etc...) Commander (ID_personne,ID_prestation,ID_commande)
ID_personne, ID_prestation, ID_commandes = clefs primaires, auto_increment (NuméroAuto)
Commander: ID_personne+ID_commande+ID_prestation = clef primaire
L'ensemble formulaire (PERSONNES, COMMANDES) / sous-formulaire (PRESTATIONS) ne viserait qu'à alimenter la table Commander sans NuméroAuto.
Je ne sais si j'ai répondu car c'est une réponse à l'estime étant donné que je ne sais rien de la conception sur la base de données. Mais de grâce, la prochaine fois, si vous souhaitez une réponse qui satisfasse la question, faites que celle-ci soit claire. Que l'on comprenne le problème, le contexte et qu'on ait les éléments pour pouvoir fournir la réponse attendue.
Bonne continuation.
domi6226
Messages postés
79
Date d'inscription
jeudi 12 juillet 2012
Statut
Membre
Dernière intervention
5 juin 2018
13 juil. 2013 à 22:59
13 juil. 2013 à 22:59
Le problème est résolu, j'ai trouvé la soluce en créant une table de transition.
Merci à tous pour votre aide.
Merci à tous pour votre aide.
heliconius
Messages postés
545
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
137
Modifié par heliconius le 14/07/2013 à 12:30
Modifié par heliconius le 14/07/2013 à 12:30
Si la table créée correspond à une relation (n-aire ; ex: [CLIENTS] (acheter) [PRODUITS]), ce n'est pas une table de transition mais une table de relation.
Par ailleurs, pour avoir passé un peu de temps sur le sujet, ce serait peut-être sympa de détailler un peu la solution trouvée. Cela inciterait à continuer à contribuer aux problèmes qui ne sont pas les nôtres et remplacerait avantageusement un laconique "Résolu. ciao, merci."
Par ailleurs, pour avoir passé un peu de temps sur le sujet, ce serait peut-être sympa de détailler un peu la solution trouvée. Cela inciterait à continuer à contribuer aux problèmes qui ne sont pas les nôtres et remplacerait avantageusement un laconique "Résolu. ciao, merci."