Discussion :

[emilie123]

bonjour, je bloque depuis un moment sur un probleme... peut être que vous allez pouvoir m'aider.

En fait je souhaite dans le cadre de vente par correspondance faire un systeme de parrain. En effet un client peut parrainé un ami et pour un parrainage il gagne un CD pour 5 il gagne un clé USB et pour 10 il gagne un téléphone, par exemple...

en fait je veux tracer le graphique des DF.

donc en fait j'ai:
numclient -> nomclient
numclient -> dateinscription
numclient -> email
numclient -> commande...

et je voulais créer une entité cadeau
avec numcadeau -> nomcadeau
numcadeau -> prixcadeau

mais je ne vois pas comment relier mon client à mon cadeau??

et apres je pensai le traduire comme ca ?



Merci d'avance.
Emilie

[Le Pharaon]

Il faut une entité typeCadeau pour catégoriser les différents cadeaux.

Je te mets le MLD directement
typeCadeau (#idTypeCadeau,TypeCadeau,nbClientCorrespondant )
Cadeau(#idCadeau,idClient,idTypeCadeau,....)

Client(#idClient1, idClient2,...)

#id.. : Clé primaire
id : Clé étrangère

[TheLeadingEdge]

Bonjour,

Je verrai bien ça comme ça.
l'attribut ''nbre'' de ''client'' est incrémenté à chaque parrainage, et décrémenté de la valeur en point de chaque cadeau choisi.

[Soutou]

Le plus simple est de faire une asso ternaire "Gagne" qui est reliée 2 fois à Client et une fois à Cadeau. Dans l'asso tu mets la propriété nombre qui désignera le nombre de cadeaux. Les cardinalités sont toutes à (O,N).

La relation obtenue sera :

Gagne(clientparrain#,clientfilleul#,cadeau#,nombre)

les # sont clés étrangères.

[davcha]

Le plus simple est de faire une asso ternaire "Gagne" qui est reliée 2 fois à Client et une fois à Cadeau. Dans l'asso tu mets la propriété nombre qui désignera le nombre de cadeaux. Les cardinalités sont toutes à (O,N).

La relation obtenue sera :

Gagne(clientparrain#,clientfilleul#,cadeau#,nombre)

les # sont clés étrangères.

Pas oublier de préciser dans l'entité cadeau le nombre de parrainages nécessaires pour obtenir le cadeau correspondant.

[TheLeadingEdge]

Emilie123, il faudrait préciser la règle, il y a 2 façons de voir.
Soit le nbre de parrainages est 1 rang, et atteindre ce rang déclenche automatiquement le gain d'1 et 1 seul cadeau, soit le client capitalise le nbre de points parrainages qu'il obtient et les utilise à sa guise.

Les cardinalités sont toutes à (O,N).

Mmmm. 1 filleul peut avoir plusieurs parrains ?

[fsmrel]

Bonsoir,

Il faut une entité typeCadeau pour catégoriser les différents cadeaux.

Je te mets le MLD directement
typeCadeau (#idTypeCadeau, TypeCadeau, nbClientCorrespondant)
Cadeau(#idCadeau, idClient, idTypeCadeau,....)

Client(#idClient1, idClient2,...)

C’est un peu laconique. Je suppose que nbClientCorrespondant représente le seuil (en nombre de filleuls) à partir duquel un cadeau est mérité ? S’il en est ainsi, c’est on ne peut plus pertinent.

Peut-on supposer encore que dans la table Client, #idclient1 représente un parrain et idClient2 un filleul ? Dans l’affirmative, il s’agit donc de la relation Parrainer de TLE, qui permet, entre autres, de compter les filleuls d’un parrain.

Dans l'asso tu mets la propriété nombre qui désignera le nombre de cadeaux.

1) La relation Gagne n’est pas pertinente, car les liens entre parrains et filleuls sont indépendants des cadeaux et les relations entre les parrains et les cadeaux sont indépendantes des filleuls. Si l’on vous suit, lorsqu’un client devient parrain pour la 1ère fois, il faut déjà lui affecter un cadeau, ce qui est pour le moins prématuré (surtout si le choix du cadeau est à l’initiative du client...) En outre, sémantiquement, vous énoncez qu’un nombre de cadeaux nc pour un parrain donné p est fonction d’un de ses filleuls f et d’un de ses cadeaux c, ce qui ne répond pas au problème posé.
La relation Gagne doit en fait être décomposée selon les relations Parrainer et Choisir définies par TLE.

2) Par ailleurs, vous permettez qu’un client parraine plus d’une fois le même filleul, ce qui ne paraît pas très raisonnable (sauf avis contraire d’Émilie).

3) Je pense que définir dans la relation Gagne une propriété pour le nombre de cadeaux est inutile car cela redonde avec un COUNT du nombre de fois où un parrain donné figure dans la table dérivée de la relation Parrainer.

@TLE :

La patte "parrain" est porteuse d’une cardinalité 1,1 : il serait préférable de transformer cette dernière en 0,1, sinon il ne peut y avoir de client qui ne soit pas filleul ce qui ne peut être le cas (au moins pour le tout premier parrain...)

Je n’ai pas très bien compris le rôle de l’entité Parrainage qui manifestement vaut pour tous les clients confondus.

En revanche, pour reprendre le point 3) ci-dessus, je verrais bien l’association Parrainer (faisant l’objet d’une table au niveau MLD) dotée d’une propriété CadeauFait, de type booléen, permettant de savoir si oui ou non un parrain a eu son cadeau : initialement, ce booléen vaut FALSE puis passe à TRUE quand on décide de faire le cadeau (autant de tuples à mettre à jour que nécessaire). On peut éviter ainsi de comptabiliser plus d’une fois les clients candidats à un cadeau.

Comme vous dites, à Émilie de préciser si le déclenchement de l’attribution d’un cadeau est automatique ou à l’initiative du client, cela conditionne pas mal de choses.

En tout état de cause, la tâche d’attribution de cadeau activera un trigger pour la mise à jour automatique de la propriété CadeauFait. Là, c’est à un champion du trigger de prendre le relais pour apporter une solution élégante...

[TheLeadingEdge]

Bonjour,

La patte "parrain" est porteuse d’une cardinalité 1,1 : il serait préférable de transformer cette dernière en 0,1, sinon il ne peut y avoir de client qui ne soit pas filleul ce qui ne peut être le cas (au moins pour le tout premier parrain...)

+1

]Je n’ai pas très bien compris le rôle de l’entité Parrainage qui manifestement vaut pour tous les clients confondus.

Oui tout à fait. Elle matérialise la règle 1 parrainage --> 1 CD, 5 --> 1 clef etc...
Que l'on considère la question d'1 point de vue DF, ou d'1 point de vue des ''responsabilité'', ce n'est pas la relation parrainer qui détermine le cadeau, c'est le nombre de parrainages.
Mais comme il peut ne pas exister de cadeau ''coutant'' le nbre de points obtenu, ou qu'à contrario il pourrait y avoir plusieurs cadeaux possibles, le nombre de points du client ne détermine pas directement le cadeau.
C'est le role de l'entite parrainage qui permet de connaitre si le nbre de parrainages obtenus par 1 client lui permet de prétendre à 1 cadeau.

[Le Pharaon]

C’est un peu laconique. Je suppose que nbClientCorrespondant représente le seuil (en nombre de filleuls) à partir duquel un cadeau est mérité ? S’il en est ainsi, c’est on ne peut plus pertinent.

Peut-on supposer encore que dans la table Client, #idclient1 représente un parrain et idClient2 un filleul ? Dans l’affirmative, il s’agit donc de la relation Parrainer de TLE, qui permet, entre autres, de compter les filleuls d’un parrain.

C'est ce que j'ai voulu dire, en attendant d'avoir plus de précisions.