Discussion :

[HABITB0L]

Bonjour,

Je vous demande de l'aide dans l'élaboration d'une base de données. Voici un lien pour vous montrer ce que j'ai fait : http://www.developpez.net/forums/att...1&d=1337823387 ! Le problème, c'est que ceci n'est pas cohérent avec ce que je veux faire.

En effet, un fournisseur peut avoir plusieurs produits. Un produit peut être livré par plusieurs fournisseurs. Jusque là, tout fonctionne ! Le problème, c'est qu'une commande doit contenir plusieurs produits venant d'un SEUL ET UNIQUE fournisseur. Alors que dans le schéma que je vous ai envoyé, une commande peut contenir plusieurs produits de fournisseurs différents ...

Merci d'avance

PS 1 : pouvez-vous m'indiquer si les nommages de mes identifiants sont clairs. Si ce n'est pas le cas, quelles règles de nommage me conseillez-vous ?

PS 2 : ne faites pas attention aux types des données, je les ai saisis vite fait

[Richard_35]

Bonjour HABITB0L,

Le problème, c'est qu'une commande doit contenir plusieurs produits venant d'un SEUL ET UNIQUE fournisseur.

==> il faut stocker "id_fournisseur" dans "commande" (ne surtout pas le stocker dans "commande_produit_fournisseur", qu'il faudrait nommer "commande_detail" ou "commande _produit").

PS 1 : pouvez-vous m'indiquer si les nommages de mes identifiants sont clairs. Si ce n'est pas le cas, quelles règles de nommage me conseillez-vous ?

==> tu auras autant de réponses que de forumeurs !... ou à peu près : fais un tour dans les FAQ et tutos, il me semble que tu pourras trouver des bases. Sinon, Google te les trouvera également.

[CinePhil]

==> il faut stocker "id_fournisseur" dans "commande" (ne surtout pas le stocker dans "commande_produit_fournisseur", qu'il faudrait nommer "commande_detail" ou "commande _produit").

Sauf qu'avec ce modèle simple, on peut commander à un fournisseur des produits qu'il ne fournit pas.

J'avais commencé à y réfléchir ce matin chez moi mais pas eu le temps d'aller au bout de la réflexion et de la rédaction.
J'y reviendrai plus tard.
HABITB0L, tu trouveras sûrement des exemples similaires dans les discussions de ce forum.
Tu verras ainsi qu'il vaut mieux donner un titre plus explicite pour faciliter la recherche !

==> tu auras autant de réponses que de forumeurs !

Un premier article à lire qui donne un standard de nommage des objets d'une BDD.

Je l'ai un peu adapté de cette manière concernant les identifiants :
- code_id pour les identifiants des tables issues des entités du MCD, avec 'code' = le code mnémotechnique de 3 lettres rappelant le nom de la table où se trouve la colonne.
- code_id_autre_table ou code_id_nom_clair pour les portant une clé étrangère.

Exemple :
personne -0,n----diriger----1,1- projet -1,1----concerner----0,n- client

te_personne_prs (prs_id, prs_nom...)
te_projet_prj (prj_id, prj_id_chef, prj_id_client, prj_nom...)

Ce standard peut sembler rébarbatif au début mais on s'aperçois vite qu'on n'a même plus besoin de regarder son MCD ou MLD pour écrire les requêtes quand on a bien son schéma en tête.

J'écrirais un billet de blog un de ces 4 sur les raisons qui m'ont poussé aux adaptations que j'ai faites du standard de SQLPro.

[Richard_35]

Bonjour Philippe,

Sauf qu'avec ce modèle simple, on peut commander à un fournisseur des produits qu'il ne fournit pas.

==> ma réponse n'était, effectivement, pas complète. HABITB0L aura, sans doute, pris soin de la compléter :

==> il faut stocker "id_fournisseur" dans "commande" (ne surtout pas le stocker dans "commande_produit_fournisseur", qu'il faudrait nommer "commande_detail" ou "commande _produit")...

... et modifier les relations en conséquence.

[fsmrel]

Pauvre HABITB0L, confronté à un p... de problème !


En réalité, du fait de la contrainte qui veut que pour une commande le fournisseur soit unique quels que soient les produits, la prétendue clé (candidate) de la table commande_produit_fournisseur est seulement une surclé réductible à une paire :




Pour la suite, pour éviter les maux de tête, permettez-moi d’utiliser des noms moins chargés :



Le problème est qu’après avoir défini la clé authentique (irréductible) de la table, il y a maintenant viol de la deuxième forme normale (2NF). En effet, la contrainte initiale donne lieu à la dépendance fonctionnelle :

DF1 : CommandeId -> FournisseurId

La solution consiste à appliquer le théorème de Heath, en décomposant la table CDE_PROD_FOUR peccamineuse selon :

CPF1 {CommandeId, FournisseurId}, laquelle peut être absorbée par la table COMMANDE ;

CPF2 {CommandeId, ProduitId, Quantite, Montant}.

Malheureusement, comme dit CinePhil, on peut désormais commander des produits non fournis par le fournisseur concerné...
Pour éviter cela, au stade opérationnel il faudra en passer par la mise en œuvre d’un trigger veillant au grain.

Il en va de même si on préfère ne pas décomposer la table : mettre en œuvre un trigger veillant à ce que la dépendance fonctionnelle DF1 soit respectée.

[Richard_35]

Bonjour Fsmrel,

Il me semble préférable de stocker le fournisseur dans l'entête de la commande, puis développer un trigger de contrôle qui vérifie que le couple {Fournisseur(entête), Produit(détail)} existe dans le catalogue fournisseur.

Soit :

Code :

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

1
2
3
Fournisseur ---0,n---[Commander]---1,1--- Commande_Fournisseur ---1,n---[Composer]---1,n--- Produit
    |                                                                                          |
    +------------------------------0,n---[Fournir]---1,n---------------------------------------+

donnant :

Fournisseur(Id_Fournisseur, Nom,...) ;
Produit(Id_Produit, Libellé, ...) ;
Prod_Four(#Id_Fournisseur, #IdProduit, ...) ;
Commande(Id_Commande, #Id_Fournisseur, Date_Commande, ...) ;
Commande_Détail(#Id_Commande, #Id_Produit, Quantité, ...).

Non ?