Discussion :

[shinrei]

Bonjour,

J'ai souci sur les relations entre les differents table d'une bdd.
Je m'explique:

Un groupe d'utilisateur "fournisseurs" (ou une table spéciale fournisseurs?) va créer des fiches produits. Ses fiches pourront être sélectionner pour une collection par le grp "managers" . Ses fiches selectionnées seront ensuite choisies par "vendeurs" pour ainsi afficher les meilleurs produits aux groupes "acheteurs".

mon idée:

Un groupe d'utilisateur a sa propre table.

1) J'ai une table "produits" qui est relié avec la table "managers" en cardinalité multiples, ce qui va créer une table intermédiaire qu'on appelle "chx_manages" (choix des managers) qui aura comme clé primaire l'association de id_prod et id_manage. Jusqu'a la je sais faire. (peux-t-on donner un nom a cet assoc?).

2) Je mets en relation cette table "chx_manage" avec la table "vendeurs" en cardinalité multiples qui va donc avoir une table appelé "chx_vendeurs" qui aura comme cle primaire l'assoc de id_prod_manage et id_vendeur.

3) voila, ici les acheteurs pourront seulement lister les choix du vendeur pour une collection donnée.

J'espere que vous m'avez compris. Le cheminement doit rester tel quel.

J'aimerai avoir votre idée sur ca.

Merci,

[chrifo]

Bonjour,
Ca me parait très correct

[Le Pharaon]

Les règles de gestion ne sont pas très claires dans ma tête

Un groupe d'utilisateur a sa propre table.

Je te conseille de créer une table T_Groupe où tu mettras tous les groupes
T_Groupe (idGroupe,NomGroupe,...)

[chrifo]

Je te conseille de créer une table T_Groupe où tu mettras tous les groupes
T_Groupe (idGroupe,NomGroupe,...)

J'avais cru comprendre que "managers" était un groupe, "vendeurs" un autre, etc. C'est pas ça ?

[shinrei]

Bonjour,

J'avais cru comprendre que "managers" était un groupe, "vendeurs" un autre, etc. C'est pas ça ?

eh bien c'est qu'ils ont les memes caractéristiques (nom, prenom...) mais pas le meme type de groupes.

Alors comme l'a conseillé Bujuman, il serait aussi intéressant de créer une table "groupe" qui sera en relation avec la table "users"

....MAIS comme le montre le dessin, je suis obligé (autre solution???) de les distinguer (séparer).

Questions:
- peux-t-on donner un nom a une association qui a 2 clés, si oui comment?
- un fournisseur a 1 ou n usine mais une usine peut etre lui-meme fournisseur, comment le modéliser?

[chrifo]

eh bien c'est qu'ils ont les memes caractéristiques (nom, prenom...) mais pas le meme type de groupes.

Alors tu peux par exemple garder des tables distinctes, et toutes les faire pointer (FK) sur une table "intervenant" qui présente les caractéristiques communes.

Questions:

- peux-t-on donner un nom a une association qui a 2 clés, si oui comment?

Je ne comprends pas bien la question. Une association du MCD peut générer une table avec une clé primaire composée dans le MLD. Ca répond à ta question ?

- un fournisseur a 1 ou n usine mais une usine peut etre lui-meme fournisseur, comment le modéliser?

Tu aura certainement une table "fournisseur" avec un id_fournisseur, et une table "usine", avec 2 FK pointant chacune sur un id_fournisseur.

[shinrei]

Je ne comprends pas bien la question. Une association du MCD peut générer une table avec une clé primaire composée dans le MLD. Ca répond à ta question ?

Je voulais la syntaxe sql au faite. c'est juste ça?:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
create table chx_manage ( chx_man int not null, man_id int not null, prod_id int not null, 
CONSTRAINT nom_contrainte FOREIGN KEY (man_id,prod_id) REFERENCES manage (man_id) and references products (prod_id) )

Je sais pas si le "and" passe??

Tu aura certainement une table "fournisseur" avec un id_fournisseur, et une table "usine", avec 2 FK pointant chacune sur un id_fournisseur.

J'ai vu que c'est une association reflexive mais je sais pas comment le creer sous forme de requete...

[shinrei]

J'ai refais mon mcd.

Les grandes fleches symbolisent l'héritage de ta table Users vers les autres mais je sais pas si en visio c'est la bonne fleche.

Qu'en pensez vous?

[Xo]

Cela n'a rien à voir avec le Langage SQL, je déplace dans le forum Conception.

[shinrei]

Voila la version finale (j'espere):

-Une banque a 1 ou n fournisseur et vice-versa.
- un fournisseur a 1 ou usine et une usine peut avoir plusieurs fournisseurs (a confirmer).
- si une usine est aussi fournisseur, bah c pas grave il inscrit sur fournisseur puis sur usine ( c'est correct?).
- un fournisseur a 1 ou n produits et un produit est produit par un seul fournisseur.

deroulement coté utilisateurs:
- user bs selectionne les produits des fournisseurs.
- puis user bi choisis parmis la selection faite par user bs.
- pour finir user client regarde les choix de user bi.

question table:
- table chx_bs qui a une cle primaire en incrementation et en etrangeres la cle produit et la cle user.
- table chx_bi qui a une primaire en auto avec comme cle etrangere la cle chx_bs et la cle user.
- pour le client pas besoin d'avoir une table ici. Sa selection s'effectue ailleurs.

Sur l'image, user_id est primaire mais je sais pas pourquoi elle est aussi etrangere.

Vous en pensez quoi svp