Bonjour,
 
je voudrais savoir comment je pourrais organiser ma base de données.
Alors un contact peut effectuer plusieurs demandes (PH, EDEN,GFA, FGIF et IDECLIC) dans chaque demande, on doit savoir le montant demandé, le montant accordé, le montant refusé, la date de mise en place et la date d'abandon.
 
merci

http://forum.hardware.fr/hfr/Progr [...] 4544_1.htm
 
Article 0C.
 
Sinon, un indice : une table contact, et une table demande.

Je ne demandais pas de faire mon boulot . . .
Je voulais juste un conseil.
 
Merci pour votre réponse

Par la suite, sur le formulaire de saisie d'un nouveau contact que je ferais, sera-t-il possible d'entrer toutes les demandes à l'aide d'une liste déroulante ?
sachant qu'un contact peut effectuer une ou plusieurs demandes.

 
un contact ne peut pas faire plusieurs demande dans se cas là si ?

Ben si, justement...

Ah bon . . .
 
il faut faire une CIM non ?
http://www.zimagez.com/zimage/relations0.php
 

Non, une simple CIF.
 
La CIM impose de créer une table supplémentaire, et ça ne sert que dans le cas où X contacts peuvent créer Y demandes, avec X et Y arbitraires.
 
Toi c'est une CIF : 0,n d'un côté et 1,1 de l'autre.

petite précision :
un contact 1 peut faire une demande de type A et une demande de type B
Le contact 2 peut faire seulement une demande de type B
Le contact 3 fera une demande de type A, une autre de type B et une autre de type C . . .
 
 
Avec une CIF, comment l'on va pouvoir procéder pour faire cela ?

Mais puisque je te dis que c'est le comportement de base d'une CIF
 
Documente toi sur Merise un minimum, parceque là ça ne mérite même pas d'explication tellement c'est évident... (c'est juste la définition d'une CIF quand même, à toi de regarder comment traduire une CIF (MCD) en foreign key (MPD)

Mais je ne comprend pas tes cardinalités . . .
0,n et 1,1
 
un contact peut faire aucune ou plusieurs demandes (j'suis ok avec la première)
mais une demande de type A peut être fait par aucun plusieurs contact (la 2ème cardinalité ne le traduit pas)

ben il te manque une table "type_demande", mais fait ça proprement.
 
une demande type A, c'est pas une demande, c'est une demande... de type A.
 
rien n'empêche, d'un point de vue purement logique qu'un contact fasse X demandes de type A.
 
donc y'a une CIF entre contact et demande.
et éventuellement une table type_demande, avec une CIF vers demande.

faut travailler par analogie...
 
une personne peut acheter une VOITURE.
cette voiture peut être une RENAULT, une PEUGEOT, ou n'importe quoi.
et rien n'empêche, avec le temps, l'utilisateur d'acheter deux voitures de la même marque.
 
donc tu ne lies pas la personne à la marque, mais à sa voiture, et c'est sa voiture qui est liée à une marque.
 
après, si t'as des contraintes supplémentaires, ce sera des règles supplémentaires à ajouter (clés uniques, triggers, etc.) mais ne commence pas à exploser ton modèle en mélangeant structure et contraintes.

ok ok, je vais voir tout ca.
Merci bien

Arf, je te suis pas.
 
je reviens a l'exemple de tes voitures, si une personne achète une peugeot 206 et une 406, nous avons pour cela une cardinalité 0,n où une personne peut acheter aucune ou plusieurs voitures.
 
Ensuite une peugeot 206 peut être acheté par aucune ou plusieurs personnes ce qui ferait une cardinalité 0,n également.  
 
ces deux cardinalités appel une CIM.
 
J'ai loupé quelque chose

c'est pas la même voiture
 
à moins que tes contacts reprennent le bout de papier d'un autre contact pour refaire la même demande, même si c'est deux demandes de types A, ce sera toujours DEUX demandes, qui sont toutes les deux de type A
 
c'est pourtant pas compliqué, je vois pas ce qui te pose problème...
 
ton identifiant dans la table DEMANDE, c'est pas "typea", mais un compteur 1, 2, 3, etc.
 
le type, c'est bêtement une propriété comme une autre, comme le nombre de dents de ton contact : on n'en a rien à foutre.
 
c'est ta table type_demande qui va utiliser A, B, C comme clé. et demande va y vaire référence. mais une bête référence comme une autre.

Ca fait deux semaines de 8h30 à 17h30 que je suis sur la meme base de données.
J'suis perdu lol
faut tout que je reprenne pour savoir où j'en suis là.
 
Bref, je garde tes informations et je vais tout revoir.
 
merci

une petite question :
J'ai une table voiture et une table pilote par exemple
cela change quelque chose si je met code_pilote en clef étrangère dans la voiture ou plutot num_voiture en clef étrangère dans pilote ?

oui.
 
Si "code_pilote" est une clé étrangère dans la table "voiture", cela implique qu'un pilote peut avoir 0,n voitures, mais une voiture a 0,1 pilote.
 
Si "num_voiture" est une clé étrangère dans la table "pilote", cela implique qu'une voiture peut avoir 0,n pilotes, mais qu'un pilote a 0,1 voiture.
 
En outre si une voiture peut avoir 0,1 pilote et un pilote peut avoir 0,1 voiture, alors il ne faut qu'une table générale.
 
Et si une voiture peut avoir 0,n pilotes et un pilote peut avoir 0,n voitures, alors il te faut une table supplémentaire "conduire" avec deux fk, une vers voiture et une vers pilote (le cas du truc que tu avais cité http://www.zimagez.com/zimage/relations0.php )

merci bien pour cette réponse claire :-)

cela est bien clair avec les voitures mais avec ma base j'ai un peu plus de mal :-s
 
Je vous explique la situation :
 
J'ai trois tables, CONTACT, CE et ENTREPRISE
 
Un contact peut participer à aucun ou plusieurs Comité d'Engagement
donc j'ai code_contact en clef étrangère dans CE (si j'ai bien compris).
Si le contact est ajourné au CE, il peut revenir et si il est accepté a ce moment là, cela donnera une seule entreprise.
 
ensuite un CE peut donner lieu à aucune ou une seule ENTREPRISE
et une entreprise est donnée lieu par un seul CE.
 
Nous avons ici 0,1 d'un coté et 1,1 de l'autre ce qui donne, si j'ai compris, UNE SEULE table.
 
Le problème c'est que pour créer une entreprise, un contact doit obligatoirement passer par un comité.
 
Comment organiser ca ?
 
pas facile a expliquer, j'sais pas si vous avez tout compris

nan
(pis cherche un peu )
 
ps : dans ton CE tu peux avoir qu'un seul contact ? je trouve ça chelou moi

Dans un CE on enregistre le nom du créateur, la date puis la décision du CE par rapport au contact.
 
un CE concerne un seul contact oui mais il peut avoir plusieurs CE