Discussion :

[ambact]

Bonjour,

J'ai un doute sur la façon d'écrire cette relation en table :

Un client payeur peut offrir un ou plusieurs abonnements à un ou plusieurs client.

C'est à dire que celui qui paie un magazine peut l'offrir à lui-même ou à toute sa famille un ou plusieurs abonnements.

Ce n'est que du 1,n, il faudrait donc créer une table intermédiaire qui récupère les clés des 3 tables ? Ou alors y-t'il une autre façon de créer cette relation ?

[f-leb]

bonjour,

Supposons la table Offrir(#idClientPayeur, #idClient, #idAbonnement), clé primaire sur les 3 champs.

Un client payeur peut offrir à un même client plusieurs abonnements:

idClientPayeur    idClient    idAbonnement
    c1               c2           a1
    c1               c2           a2
    c1               c2           a3

Un client payeur peut offrir un même abonnement à plusieurs clients:

idClientPayeur    idClient    idAbonnement
    c1               c2           a1
    c1               c3           a1
    c1               c4           a1

Pour un abonnement et un client donné, il peut y avoir plusieurs clients payeurs:

idClientPayeur    idClient    idAbonnement
    c6               c5           a9
    c7               c5           a9
    c8               c5           a9

Si au moins un des 3 cas précédents est impossible, alors il faut que tu reviennes, le schéma de départ n'est pas bon

[ambact]

Bonjour f-leb,

Merci pour ta réponse.

La dernière possibilité est surement impossible à arriver. Je ne vois pas recevoir le même n abonnement par différentes personnes.

un moment donné, j'ai pensé mettre la clé étrangère du payeur dans la table client car un client a un et un seul payeur, mais il peut avoir n magazines de différents payeurs par contre.

la table avec les 3 clés étrangères est donc impossible.

un payeur a 1 ou n client
un client peut avoir un ou plusieurs plusieurs payeur mais pas sur le même magazine
un payeur peut acheter pour lui-même, 1 ou n abonnement

[f-leb]

bonjour,

s'il n'y a que le dernier cas à éviter, il suffit de mettre la clé primaire uniquement sur le couple (idclient, idabonnement):

Offrir(#idClientPayeur, #idClient, #idAbonnement)

idClientPayeur    idClient    idAbonnement
    c6               c5           a9
    c7               c5           a9 <-- doublon impossible sur (idClient, idAbonnement)

les deux premiers cas restant possibles.

[Thierry_PALLIER]

Bonjour ambact et f-leb.
Sans vouloir répondre à la place de f-leb ,j'ai un peu suivi l'activité d'ambact sur une discussion vba portant sur le mailing.ici
ambact ayant pris la suite sur une base mal conçue ,tu vas te trouver dans l'impossibilité de faire évoluer cette base .
Et ici, tu ne donnes qu'une (très) petite partie des infos .
Je propose ici un modèle de départ qui me semble adapté à ton activité à travers ce que j'ai compris dans l'autre post.

Est-ce que cela convient ?
A+

[f-leb]

Bonjour,

bon, je n'ai pas eu le loisir de lire l'autre discussion, 3 pages et 50 messages

C'est à dire que celui qui paie un magazine peut l'offrir à lui-même ou à toute sa famille un ou plusieurs abonnements

un payeur peut acheter pour lui-même, 1 ou n abonnement

Le fait d'avoir une table Client et une table Payeur ne va pas faciliter les choses si le payeur peut aussi être le client, non ?

[Thierry_PALLIER]

Bonsoir f_leb.
Dans la table payeur ,si on dédit le 1 (p.e) ,nom = vide ou lui memme, cela doit résoudre le problème .
En ce qui concerne les familles ,j'ai scindé en 2 tables ,plus une table de jonction.
A+

[ambact]

Bonsoir a vous !

Je vois que la discussion est suivi.

Alors oui, tout d'abord, il est vrai que je travaille actuellement sur une base de donnée qui n'a pas été monté dans le sens que je pense mais a force de travailler dessus, je comprend pourquoi ca a été écrit comme ca.

Les données des commandes, se transfèrent de base en base de données. Le moyen le plus simple a été de créer une seule table des commandes, et une ligne de données est écrite par titre de magazine et non par client, ce qui signifie qu'il y autant de fiche par magazine et si un client prend 10 magazines, il faut créer 10 lignes et on récupère a chaque fois les infos du client. Pour moi, la meilleure solution a été de proposer une fiche par client, 1 ligne créée pour 10 magazines.

Il faut donc créer plusieurs tables qui fassent les relations. Le problème est que lors de transfert pour traiter les commandes, ça fait autant de table qu'il faut transférer pour ne pas perdre les liens entre elles. Ca risque de porter a confusion a force.

J'essaie de proposer une nouvelle base de données simple a l'usage.
Celle de 3 tables avec 1 table qui fait le lien peut être interressant. Je vais tester les différents modèles pour voir ce que ca peut donner.

[Thierry_PALLIER]

Bonjour ambact.
Si çà t'interesses ,j'ai fait une base suivant l'image proposée plus haut.
Le plus simple (selon moi) , c'est un formulaire et un sous formulaire .
Donc 1 table Commande-detail.
Je suis en train de finaliser avec outlook.
Je peut eventuelement t'envoyer cette base.
ci-joint le form (sans effort esthetique !)
Cdlt

ps:certains champs (publication) sont grisés car désactivés ,et on ne les voit pas bien sur l'image

[ambact]

Bonjour,

J'ai repensé au lien entre les tables et je veux m'assurer qu'une table intermédiaire est obligatoire et contiendrait donc les 3 clés des 3 tables.

Voici les relations à écrire sur 3 tables différentes
Table CLIENT_PAYEUR
Table CLIENT_LIVREUR
Table PUBLICATION

avec une table qui regroupe les 3 tables TABLE COMMANDE

- un payeur peut offrir un ou plusieurs abonnements à un ou plusieurs clients et à lui-même.
-un client peut avoir un ou plusieurs abonnements de un ou plusieurs client payeur
- une publication peut être offrir par un ou plusieurs payeur pour un ou plusieurs client livreur.

En sachant que le plus important ensuite, sont les données du client livré pour les éditeurs, donc il faut pouvoir lister la liste des publications à livrer à l'adresse du client qui reçoit et pas celui qui paie (sauf s'il achète pour lui-même)