Discussion :

[spoonatte]

Je suis entrain de modéliser une base de donné d'un site e-commerce qui vend des produits d'artisanat.

et j'aimerai avoir si possible quelques conseils pour mon mcd.

[CinePhil]

1) Il y a des simplifications à faire. Par exemple...

Règles de gestion :
R1) Un client possède de une à plusieurs adresses et une adresse est possédée par un client.
R2) Une adresse peut être qualifié de plusieurs types (facturation, livraison, siège social...) et un type d'adresse peut qualifier plusieurs adresses.

MCD :
client -1,n----posséder----1,1- adresse -1,n----qualifier----0,n- type_adresse

2)
commande_colis -0,n----livrer----1,1- commande_methodeLivraison -0,n----utiliser----1,1- commande_commande

2a) Pourquoi donner des noms aussi compliqués aux entités types ?
Qu'est-ce qu'une "commande_commande" ?
Ces appellations vous conduisent à modéliser un raisonnement faux, par manque d'avoir écrit des règles de gestion claires !
Ici, vous dites qu'une commande utilise une seule méthode de livraison (OK) mais aussi qu'une méthode de livraison ne livre qu'un seul colis !
=> Quand vous aurez livré un colis par la poste, vous ne pourrez plus en livrer un autre !

Règles de gestion :
R3) Une commande utilise une méthode de livraison et une méthode de livraison peut être utilisée par plusieurs commandes.
R4) Une commande peut être livrée en plusieurs colis et un colis livre une seule commande.

MCD :
commande -1,1----utiliser----methodeLivraison
|------------------1,n----livrer----1,1- colis

3) Attention aux boucles !
Exemple...

client -0,1----posseder----1,1- carte_bancaire -0,n----regler----0,1- commande
|---------0,n----passer----1,1--------------------------------------------------------------|

Avec ce schéma, une commande peut être réglée par la carte bancaire d'un client qui n'est pas celui qui a passé la commande !

Il faut modéliser une contrainte d'inclusion pour empêcher cela.

Et si le client n'a pas de carte bancaire, comment sera payée la commande ?
Généralement, on modélise différents moyens de paiement et on associe la commande au moyen de paiement.



Bref, il y a pas mal de choses à revoir !
Repassez par l'étape d'écriture des règles de gestion, tout le monde y verra plus clair et ce sera plus facile de vous aider.


Sinon, avez-vous envisagé l'utilisation d'un logiciel de e-commerce tout fait ?

[spoonatte]

Salut, merci pour votre conseilles je suis entraine de modifier mon MCD.

Il faut modéliser une contrainte d'inclusion pour empêcher cela.

j'ai un question comment puis-je modéliser une contrainte d'inclusion.

Et si le client n'a pas de carte bancaire, comment sera payée la commande ?

le client a le choix de payer utilisant une méthode de paiement ( carte bancaire, chèque, paypal ...)

[fsmrel]

Bonsoir,

Avec ce schéma, une commande peut être réglée par la carte bancaire d'un client qui n'est pas celui qui a passé la commande !

Il faut modéliser une contrainte d'inclusion pour empêcher cela.

Ça se discute...

Si mes enfants veulent m'offrir "CinePhil, sa vie son oeuvre", ils se mettent au clavier avec moi, on utilise mon identifiant par exemple chez Dubicobit (entreprise de commerce électronique, spécialisée sans les bons auteurs), et ils se servent de leur propre carte pour régler (en notant qu’ils sont aussi clients chez Dubicobit)...

Supposons maintenant que Dubicobit interdise ce procédé : d'accord, va pour une contrainte d’inclusion.

La référence [1] n’est pas assez précise, mais on va conjecturer que la contrainte d’inclusion (I) ci-dessous a pour équivalent la contrainte SQL (laquelle est dépourvue de tchatche et d’ambiguïté) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE ASSERTION ASSERT_01
   CHECK 
      (
       NOT EXISTS
           (       
            SELECT *
            FROM   COMMANDE AS x JOIN CARTE_BANCAIRE AS y ON x.CbId = y.CbId
            WHERE  x.ClientId <> y.ClientId
           )
      ) ;

La contrainte d’inclusion (I) a pour cible l’association CB_CLI, pour portée la paire {CDE_CLI, CDE_CB} et pour pivot CLIENT (s’il passe par là, merci à JPhi33 de donner son avis) :



MLD :




__________________________________

[1] afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information » (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.

Extrait de ce document :

[fsmrel]

Attention aux boucles !

Pour avoir affaire à une boucle c'est-à-dire un cycle, cela suppose que l’émetteur d’un stimulus initial de mise à jour (ON DELETE, ON UPDATE) — en l’occurrence le client —, se prenne en retour le boomerang en pleine figure, comme par exemple dans cette situation dans laquelle le client demande à la carte de disparaître, auquel cas celle-ci lui répond « d’accord, mais tu disparais aussi ! » (on est au niveau MLD, les flèches symbolisent les contraintes référentielles) :



Par contre, si la situation est la suivante, selon laquelle CARTE_BANCAIRE fait référence à CLIENT et c’est tout :



Alors il n’y a pas de cycle. On n'a pas affaire à une boucle (la suppression de la carte n’entraîne pas la suppression du client), mais plutôt au problème de l'accès à une donnée (la commande) par deux chemins différents (problème du conterminous path en relationnel), lequel a donné lieu il y a belle lurette à l'étude de la contrainte de chemin chez les merisiens bon teint (Flory A., Morejon J., Rochfeld A. : « Toward a new generation of design tools : some basic ideas ». First int conf. on TOOLS – Paris – 1989). Un moyen de résoudre le problème est de déclarer une contrainte d’inclusion dans le MCD, se traduisant par une assertion en SQL, voyez mon message précédent.

Une alternative :

Comme d’habitude, si l’identification relative me permet de résoudre mon problème, je fais appel à elle (cardinalités 1, 1 concernées mises entre parenthèses, selon les conventions PowerAMC) :



MLD correspondant :



La carte bancaire à laquelle une commande fait référence appartient nécessairement au client qui passe la commande.

Ainsi, on n’a pas besoin de déclarer d’assertion ou, si le SGBD ne permet pas les assertions, d’en passer par le palliatif des triggers, généralement assez pénibles à coder.


N.B. Dans mon message précédent, j'ai oublié de signaler que {CbNumero} est clé alternative de la table CARTE_BANCAIRE.

[JPhi33]

Bonsoir,

La contrainte d’inclusion (I) a pour cible l’association CB_CLI, pour portée la paire {CDE_CLI, CDE_CB} et pour pivot CLIENT (s’il passe par là, merci à JPhi33 de donner son avis) :

Pour moi, la contrainte d'inclusion est correctement modélisée -- à ceci près que CARTE_BANCAIRE est aussi pivot (cf. définition du pivot dans l'extrait des journées AFCET fourni par fsmrel). Elle traduit une règle qui, en langage naturel, peut s'exprimer :

Une COMMANDE passée par un CLIENT ne peut être réglée par une CARTE_BANCAIRE que si celle-ci appartient au client.

Concernant la pertinence de la contrainte d'inclusion, je rejoins l'avis de fsmrel. Les quelques sites de commerce en ligne que j'ai eu l'occasion d'utiliser ne demandent pas à ce que j'utilise ma propre CB pour payer. Et il m'est arrivé d'utiliser ma CB pour régler un achat effectué par quelqu'un d'autre sur son compte client. Donc, pour moi aussi :

Ça se discute...

@spoonatte
Un client peut posséder plusieurs cartes bancaires. Donc la cardinalité entre l'entité client_client et l'association posseder3 devrait être 0,n et non pas 0,1.

[fsmrel]

Bonsoir,

CARTE_BANCAIRE est aussi pivot

Exact, merci JPh.

[spoonatte]

c'est mon nouveau mcd :


http://npic.imagup.com/1/1178466303.jpg

si quelqu'un à des suggestions ou des choses à modifier. j'aimerais bien que vous me les proposer.

et merci.