Discussion :

[bad111]

Bonjour tout le monde je suis sur le projet ci-dessous et je voudrais savoir si mon analyse et mon mcd est correct merci.

Expression des besoins du client.

Le site ?????? de vente en ligne désire ajouter un système automatique de facturation par messagerie pour ses clients. Chaque client, recevra par messagerie la facture le concernant dès que sa commande sera en cours de livraison.


Analyse

Un client (customers) peut créer un carnet d’adresse (adresse_book) pour ce faire livré à une autre adresse donc nous avons une cardinalité de 0,1.
Un carnet d’adresse et lié à un seul client et le client ne peut en créer qu’un donc nous avons 1,1.

Un client peut passer une ou plusieurs commandes (orders) donc nous avons 0,n.
Une commande ne concerne qu’un seul client donc nous avons 1,1.

Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
Il doit y avoir une commande pour créer une facture et il peut y avoir plusieurs commande a facturé donc 1,n.

Une commande obtient un seul statut (orders_statuts) à la fois donc 1,1.
Un statut (en cours de livraison, etc..) peut être relié à une ou plusieurs commandes donc 0,n.

Une commande peut contenir un type de frais de port (orders_total) donc 0,1.
Un type de frais de port (ups, poste) ne concerne qu’une seul commande donc 1,1.

Une commande contient forcement un ou plusieurs produits (orders_products) donc 1,n.
Un produit concerne une seul commande donc 1,1.

MCD

http://www.esinger.fr/projetschema.jpg

Merci et désolé pour la longueru du message.

[CinePhil]

Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
Il doit y avoir une commande pour créer une facture et il peut y avoir plusieurs commande a facturé donc 1,n.

Ceci va entraîner le fait que la facture doit être créée en même temps que la commande or la facture ne sera envoyée que lorsque la commande sera livrée. je dirais donc plutôt :
Facture -1,1----Concerner----0,n- Commande

Remarque complémentaire : la cardinalité n du côté de la facture n'est due au fait qu'il y a plusieurs commandes à facturer mais signifie qu'une commande peut faire l'objet de plusieurs factures.

Une commande peut contenir un type de frais de port (orders_total) donc 0,1.
Un type de frais de port (ups, poste) ne concerne qu’une seul commande donc 1,1.

Vous n'enverrez qu'une seule commande par la poste, une seule autre par UPS ? Votre entreprise aura très vite des problèmes pour faire acheminer ses colis !
A mon avis un type de frais de port peut être choisi dans plusieurs commandes. Donc :
Commande -0,1----Ajouter----0,n- Type de frais de port

Une commande contient forcement un ou plusieurs produits (orders_products) donc 1,n.
Un produit concerne une seul commande donc 1,1.

Encore une fois, vous allez vendre une seule fois un produit et plus jamais ensuite ?
Vous allez devoir très vite diversifier votre catalogue de produits !
Donc :
Commande -1,n----Contenir----0,n- Produit

Je termine par la première en arrivant à la lecture de votre schéma...

Un client (customers) peut créer un carnet d’adresse (adresse_book) pour ce faire livré à une autre adresse donc nous avons une cardinalité de 0,1.
Un carnet d’adresse et lié à un seul client et le client ne peut en créer qu’un donc nous avons 1,1.

Contrairement à la manière dont vous l'avez écrit, un carnet d'adresses contient plusieurs adresses !
Si j'interprète correctement votre idée, un client peut avoir plusieurs adresses, lesquelles forment un carnet d'adresses.
Avez-vous réellement besoin de gérer le carnet d'adresses ou simplement les adresses du client ?
A mon avis, la gestion des seules adresses est suffisante, donc je reformule votre règle de gestion :
"Un client peut avoir plusieurs adresses et une adresse n'appartient qu'à un client"
Ce qui donne :
Client -1,n----Avoir----1,1- Adresse

Je vois que dans address_book' vous mélangez des caractéristiques d'entreprises (entry_company, entry_tva_intracom) et des caractéristiques de personnes (entry_firstname, entry_lastname).
A moins que vos clients soient tous des entreprises et que vous n'enregistriez pour chacune qu'une seule personne en tant que contact dans cette entreprise, il me semblerait plus judicieux de séparer ces deux notions.
Vous auriez ainsi :
- Une entité Company (ou Organisation qui est moins restrictif)
- Une entité Person
- Une entité Address
Si vous avez des clients individuels, vous pouvez associer les commandes et les addresses soit aux organismes, soit aux personnes.
Si vous n'avez que des clients organismes, vous associez les personnes aux organismes et les organismes aux adresses et aux commandes.

Je vois d'ailleurs maintenant que vos personnes sont en fait les customers ! Vos clients sont donc tous des individus ?

Quel est le rôle de orders_status_sort ? Est-ce 'sort' dans le sens de 'trier' ? Le SGBD dispose de fonctions de tri et il est rarement utile de créer une colonne de tri.
Idem pour sort_order dans orders_total.

Bizarre comme nom 'orders_total' pour y stocker des types de frais de port ! On dirait plutôt qu'il s'agit d'un entête de commande d'après les attributs.

Votre commande contient des produits qui sont vendus pour cette commande un certain prix et en une certaine quantité. C'est ce qu'on appelle souvent les lignes de commande. Mais je vois que vous répétez le modèle et le nom du produit pour chaque commande !
Il vous faut une entité Products et l'associer à orders_products. Vous ne mettrez dans cette dernière que l'identifiant du produit.

Bon courage pour la suite.

[Jimalexp]

Salut,

Je ne fais que passer mais le sujet est très intéressant vu qu'il s'agit d'un cas pratique. Veuillez m'excuser donc si je semble poser des questions idiotes mais j'aimerais vraiment m'habituer à utiliser le merise sous toutes ses coutures.

@bad111, merci de partager cette analyse. J'aurais moi même obtenu une solution similaire avant qu'elle soit ajustée (assasinée ?) par mon prof.

En fait, je dois prendre l'habitude de travailler par étapes et élaborer les MCD selon une série de réflexions dans le genre que CinePhil a posté. Cette remise en question pose une difficulté car on sort du cadre logique et on fais en sorte de comprendre le système ainsi que tout ce qu'il impliquerais. Parfois, ca m'aide de réflêchir en terme de bases de données mais c'est une "béquille" dont je devrais me passer.

Au fait, tu utilise quel logiciel pour représenter ton schéma ?

@Cinephil, j'ai survolé ta réponse. Je n'ai pas trop compris la première remarque mais la deuxième et la troisième tiennent la route.

Concernant le dernière remarque, si j'ai bien compris, il faudrais une entité supplémentaire reprenant les addresses ? Dois t-on considérer des questions de confidentialité à ce niveau ou est-ce que SQL fournit suffisamment de sécurités une fois que la base de données est créée ?

Aussi, existe t-il des cas de figures où il est intéressant de dissocier produit et prix ? Il me semble que oui mais rien ne me viens à l'esprit pour l'instant.

[CinePhil]

@Cinephil, j'ai survolé ta réponse. Je n'ai pas trop compris la première remarque

Bad111 avait écrit, avant l'exposé de ses règles de gestion :

Chaque client, recevra par messagerie la facture le concernant dès que sa commande sera en cours de livraison.

Si on laisse des cardinalités minimales à 1, la commande et la facture devront être créées en même temps. Et comme c'est un envoi de facture par mel, Quel est l'intérêt de générer une facture sans l'envoyer ? Surtout que générer une facture entraîne en principe une écriture comptable. Imaginons que le produit commandé ne soit pas disponible et qu'il faille un certain délai pour réapprovisionner, il y aurait une facture pour une prestation non effectuée, ce qui frise l'illégalité !

Concernant la dernière remarque, si j'ai bien compris, il faudrait une entité supplémentaire reprenant les adresses ?

Il est parfois utile en effet de distinguer les adresses des personnes et/ou des oragnismes, justement quand une personne ou un organisme peut avoir plusieurs adresses, ce qui est assez fréquent.

Doit-on considérer des questions de confidentialité à ce niveau ou est-ce que SQL fournit suffisamment de sécurités une fois que la base de données est créée ?

C'est le SGBD qui fournit, ou pas, des mécanismes de sécurité plus ou moins complexes. Mais cette mécanique ne fait pas partie d'un MCD.

Aussi, existe t-il des cas de figures où il est intéressant de dissocier produit et prix ? Il me semble que oui mais rien ne me vient à l'esprit pour l'instant.

Dans une discussion récente est exposé le cas d'un grossiste qui fournit à des prix différents selon le type de client.
Un autre exemple pourrait être celui de produits différents selon la période : les locations de vacances, les voyages...

[bad111]

Bonjour à tous et merci à Philippe Leménager.

Suite à vos conseils j'ai procédé à quelques modifications.

Ceci va entraîner le fait que la facture doit être créée en même temps que la commande or la facture ne sera envoyée que lorsque la commande sera livrée. je dirais donc plutôt :
Facture -1,1----Concerner----0,n- Commande

Effectivement j'avais oublié que la facture ne devait être envoyée
que lorsque la commande est en cours de livraison.
Donc nous avons
Facture -1,1----Concerner----0,n- Commande.


Pour le carnet d'adresse et client j'ai

1. séparé les occurrences personnelle et professionnelle en créant l'entité adresses_compagny
2. j'ai changé la cardinalité en Client -1,n----créer----1,1- Adresse

Quel est le rôle de orders_status_sort ? Est-ce 'sort' dans le sens de 'trier' ? Le SGBD dispose de fonctions de tri et il est rarement utile de créer une colonne de tri.
Idem pour sort_order dans orders_total.

En ce qui concerne orders_status_sort et sort_order oui en effet c'est une erreur donc je l'ai supprimé.


Par contre, j'ai quelques problèmes pour les entités orders_total______orders et orders_product________orders

C’est deux tables sont déjà existantes dans ma base de donnée et les cardinalités ont été indiqués suivant ces tables.

Pour orders_product 1,1___contient_____1,n orders
la cardinalité est de 1,1 et 1,n car oders est une clé étrangère dans orders_product.

Nom Code Type de données Primaire Clé étrangère Obligatoire

`orders_products_id` `orders_products_id` int(11)
`orders_id` `orders_id` int(11)
`products_id` `products_id` int(11)
`products_model` `products_model` varchar(12)
`products_name` `products_name` varchar(64)


J’ai aussi rajouté l’entité product.


En ce qui concerne orders_total
Cette table regroupe en fait le sous total, les frais de port et le total voici un exemple d’insertion

25747 8634 Total: <b>40,55€</b> 40.5500 ot_total 900
25746 8634 LA POSTE (Par Colissimo ): 5,60€ 5.6000 ot_shipping 15
25745 8634 Sous Total: 34,95€ 34.9500 ot_subtotal 10

Les cardinalités ont été elles aussi fixées par rapport à la table et comme précédemment on s’aperçoit que orders et une clé étrangère dans orders_total.

Nom Code Type de données Primaire Clé étrangère Obligatoire
`orders_total_id` `orders_total_id` int(10) unsigned
`orders_id` `orders_id` int(11)
`title` `title` varchar(255)

voici ce que ca donne

http://www.esinger.fr/projetschema1.jpg
Merci et désolé de la longueur du message.

[bad111]

Bonsoir tout le monde

j'ai travaillé sur mes règles de gestion mais j'ai toujour des problème avec les entitées orders_total, orders_products et product car c'est table existe déja d'ou la difficultée d'intégation.

Règles de gestion.


Un client (customers) peut avoir plusieurs adresse (adresse_book) donc nous avons une cardinalité de 1,n.
Un carnet d’adresses est lié à un seul client donc nous avons 1,1.

Un carnet d’adresses peut contenir plusieurs adresses professionnelles donc 1,n
Une adresse professionnelle est liée à un seul carnet d’adresse.

Un client peut passer une ou plusieurs commandes (orders) donc nous avons 0,n.
Une commande ne concerne qu’un seul client donc nous avons 1,1.

Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
Il doit y avoir une commande pour créer une facture et il peut y avoir plusieurs commande a facturé donc 0,n.

Une commande est relié à un ou plusieurs historiques de statut (orders_statuts_history) donc 1,n.
L’historique de statut peut être lié à une seule commandes donc 0,1.

L’historique de statut peut obtienir un seul statut (orders_statuts) à la fois donc 0,1.
Un statut (en cours de livraison, etc..) peut être relié à un ou plusieurs historiques de statut donc 0,n.

Une commande contient un ou plusieurs frais de commande (orders_total) donc 1,n.
Les frais de commande ne concerne qu’une seul commande donc 1,1.??

Une commande contient un ou plusieurs produits (orders_products) donc 1,n.
Un produit concerne une seul commande donc 1,1. ??

Un produit (product) est relié à une ou plusieurs commande de produit donc 1,1.
Une commande de produit ??

je suis désolé d'insisté mais c'est très important.

[CinePhil]

Un client (customers) peut avoir plusieurs adresse (adresse_book) donc nous avons une cardinalité de 1,n.
Un carnet d’adresses est lié à un seul client donc nous avons 1,1.

Un carnet d’adresses peut contenir plusieurs adresses professionnelles donc 1,n
Une adresse professionnelle est liée à un seul carnet d’adresse.

Ce n'est toujours pas très clair !
Votre table 'address_book' contient non pas des carnets d'adresses mais des adresses. Vous devriez la renommer en 'Addresses'.

N'avez-vous que des organismes professionnels en tant que clients, représentés par des personnes ou à la fois des clients professionnels et individuels (des particuliers) ?

Dans votre dernier MCD, les deux sont toujours mélangés dans la table 'customers'.

Je dirais aussi qu'un client peut avoir plusieurs adresses mais qu'une adresse peut être celle de plusieurs clients (cas des immeubles d'habitation ou de bureaux).

Si on s'en tient seulement à la notion de client :
Client -1,n----Avoir----1,n- Adresse

Si on veut spécialiser les clients en deux sous-catégories et considérer que votre système ne gère que des clients (par d'autres organismes professionnels tels que des fournisseurs ou des services sociaux ou publiques, pas d'autres personnes comme des salariés...) :
Personne -1,1----Etre----0,1- Client
Organisme -1,1----Etre----0,1- Client

Ce qui donnerait les tables :
Clients(C_Id, ...)
Personnes(P_IdClient, P_Nom, P_Prenom, P_DateNaissance, ...)
Organismes(O_IdClient, O_Nom, O_TVAintracom, ...)
Adresses(A_Id, A_Rue, A_CodePostal, A_Ville...)
AdressesClients(AC_IdClient, AC_IdAdresse)

Si par contre vous gérez aussi d'autres organismes et d'autres personnes, il faut typer le client :
Client -1,1----Typer----1,n- TypeClient
Personne -0,1----Etre----0,1- Client
Organisme -0,1----Etre----0,1- Client

Ce qui donnerait les tables :
Personnes(P_Id, P_Nom, P_Prenom, P_DateNaissance, ...)
Organismes(O_Id, O_Nom, O_TVAIntracom, ...)
TypesClients(TC_Id, TC_Libelle
Clients(C_Id, C_IdType, C_IdPersOuOrg, ...)
AdressesPersonnes(AP_IdPersonne, AP_IdAdresse)
AdressesOrganismes(AO_IdOrganisme, AO_IdAdresse)

A noter qu'on peut faire pareil avec les numéros de téléphone et qu'ont peut aussi externaliser :
- de l'adresse les villes et pays ;
- des personnes les civilités ;
- des organismes les formes juridiques...

Un client peut passer une ou plusieurs commandes (orders) donc nous avons 0,n.
Une commande ne concerne qu’un seul client donc nous avons 1,1.

Oui !
Client -0,n----Passer----1,1- Commande

Une facture (orders_invoice) ne concerne qu’une seule commande donc 1,1.
Il doit y avoir une commande pour créer une facture et il peut y avoir plusieurs commande a facturé donc 0,n.

Je dirais plutôt :
" Une facture ne concerne qu'une seule commande et un commande peut faire l'objet de plusieurs factures".
Facture -1,1----Concerner----0,n- Commande

Une commande est relié à un ou plusieurs historiques de statut (orders_statuts_history) donc 1,n.
L’historique de statut peut être lié à une seule commandes donc 0,1.

L’historique de statut peut obtienir un seul statut (orders_statuts) à la fois donc 0,1.
Un statut (en cours de livraison, etc..) peut être relié à un ou plusieurs historiques de statut donc 0,n.

Si j'ai bien compris, une commande va passer successivement par un certain nombre de statuts qui vont être notifiés au client et dont vous conserverez l'historique.

Je dirais donc plutôt :
"Une commande a de un à plusieurs statuts et un statut est attribué à zéro ou plusieurs commandes"
Commande -1,n----Attribuer----0,n- Statut

Ce qui donne la table associative :
HistoriqueStatutsCommandes (HSC_IdCommande, HSC_IdStatut, HSC_DateNotification, HSC_Commentaire)

En ce qui concerne orders_total
Cette table regroupe en fait le sous total, les frais de port et le total voici un exemple d’insertion

25747 8634 Total: <b>40,55€</b> 40.5500 ot_total 900
25746 8634 LA POSTE (Par Colissimo ): 5,60€ 5.6000 ot_shipping 15
25745 8634 Sous Total: 34,95€ 34.9500 ot_subtotal 10

Les cardinalités ont été elles aussi fixées par rapport à la table et comme précédemment on s’aperçoit que orders et une clé étrangère dans orders_total.

Nom Code Type de données Primaire Clé étrangère Obligatoire
`orders_total_id` `orders_total_id` int(10) unsigned
`orders_id` `orders_id` int(11)
`title` `title` varchar(255)

Une commande contient un ou plusieurs frais de commande (orders_total) donc 1,n.
Les frais de commande ne concerne qu’une seul commande donc 1,1.??

Je pense que c'est bon, même si je ne suis pas sûr de tout comprendre.
FraisCommande -1,1----Concerner----1,n- Commande

Une commande contient un ou plusieurs produits (orders_products) donc 1,n.
Un produit concerne une seul commande donc 1,1. ??

Un produit (product) est relié à une ou plusieurs commande de produit donc 1,1.
Une commande de produit ??

Là encore, vous avez une table associative car :
"Une commande comprend de 1 à plusieurs produits et un produit peut être compris dans plusieurs commandes"
CommandesProduits(CP_IdCommande, CP_IdProduit, CP_Quantite, CP_PrixHT, ...)

Bon courage pour la suite.

[bad111]

Bonjour et merci énormément

Suite à vos conseils j'ai effectué de profondes modifications sur le mcd et les règles de gestions.

Règles de gestion.

• Un client (customers) peut faire parti d’un organisme nous avons une cardinalité de 0,1.
• Un organisme (organism) est un client donc nous avons une cardinalité de 1,1 .

• Un client peut être un particulier donc 0,1.
• Un particulier (personal) est un client donc 1,1 .

• Un client peut avoir plusieurs adresse (address) donc 1,n.
• Une adresses est lié à plusieurs client (cas des immeubles) donc nous avons 1,n.

• Une adresse ne contient qu’un seul pays donc 1,1.
• Un pays (Countries) appartient à plusieurs adresses donc nous avons 1,n.

• Un pays ne dispose que d’un seul format d’adresse donc nous avons 1,1.
• Un format d’adresse contient un ou plusieurs pays donc 1,n.

• Un format d’adresse est reliée à une ou plusieurs commande donc 1,n.
• Une commande (orders) ne contient qu’un seul format d’adresse donc 1,1.

• Un client peut passer une ou plusieurs commandes donc nous avons 0,n.
• Une commande ne concerne qu’un seul client donc nous avons 1,1.

• Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
• Une commande peut faire l'objet de plusieurs factures donc 0,n.

• Une commande obtient un ou plusieurs statut (orders_status) donc 1,n.
• Un statut peut être lié à une ou plusieurs commandes donc 0,n.

• Une commande possède un ou plusieurs total (orders_total) donc 1,n.
• Un total appartient à une et une seul commande donc 1,1.

• Une commande contient un ou plusieurs produits (products) donc 1,n.
• Un produit peut être affecté à un ou plusieurs commandes donc 0,n.

et voici le mcd

http://www.esinger.fr/projetschema1.jpg

Comme vous pouvez le constater mon mcd composé d'entités en anglais et de relations en français et je me demande ce qui est le plus judicieux :

soit tous traduire en français et remettre en anglais lors de la création mpd.

soit tous traduire en anglais dès le départ.

Je voudrais savoir ce que vous en pensez et encore merci.

[CinePhil]

Je ne sais pas ce que vous entendez par 'organisme' mais quand je parlais précédemment d'organismes professionnels, je voulais dire entreprises, associations, services publics, administrations publiques... bref, tout ce qui n'est pas un individu humain mais une entité juridique composée d'une ou plusieurs personnes.
Dans votre entité Customers, vous avez toujours firstname et lastname. C'est quoi le prénom d'EDF, de la Société Générale, du Trésor Public... ?

Organisme et Personne héritent de Client donc effectivement :

• Un organisme (organism) est un client donc nous avons une cardinalité de 1,1 .

Mais par contre, je dis non à ça :

• Un client (customers) peut faire parti d’un organisme nous avons une cardinalité de 0,1.

Gardons le même verbe qui désigne l'association : Etre.
" Un organisme est un client et un client peut être un organisme."
En MCD, nous avons bien :
Organisme -1,1----Etre----0,1- Client

Idem pour la personne :
Personne -1,1----Etre----0,1- Client

Dans votre entité mère Clients ne doivent pas figurer des attributs qui sont spécifiques aux personnes ou aux organismes mais seulement ceux qui sont communs aux deux. default_address_id peut en être un.

• Un client peut avoir plusieurs adresse (address) donc 1,n.
• Une adresses est lié à plusieurs client (cas des immeubles) donc nous avons 1,n.

Oui !

• Une adresse ne contient qu’un seul pays donc 1,1.
• Un pays (Countries) appartient à plusieurs adresses donc nous avons 1,n.

Je dirais plutôt : "Une adresse ne contient qu'un seul pays et un pays peut contenir plusieurs adresses." Pourquoi changer de verbe ? Oui pour les cardinalités.

• Un pays ne dispose que d’un seul format d’adresse donc nous avons 1,1.
• Un format d’adresse contient un ou plusieurs pays donc 1,n.

Oui ! Mais encore un changement de verbe qui pourrait induire en erreur.

• Un format d’adresse est reliée à une ou plusieurs commande donc 1,n.
• Une commande (orders) ne contient qu’un seul format d’adresse donc 1,1.

Association en principe inutile puisqu'on retrouve le bon format d'adresse de la commande via le client qui à une adresse d'un certain format.

• Un client peut passer une ou plusieurs commandes donc nous avons 0,n.
• Une commande ne concerne qu’un seul client donc nous avons 1,1.

Oui mais je ne dirais pas 'peut passer une ou plusieurs' mais plus simplement 'peut passer plusieurs'. Le verbe pouvoir donne la possibilité qu'il y a ait zéro donc la cardinalité minimale et 'plusieurs' donne la cardinalité maximale.

• Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
• Une commande peut faire l'objet de plusieurs factures donc 0,n.

Oui

• Une commande obtient un ou plusieurs statut (orders_status) donc 1,n.
• Un statut peut être lié à une ou plusieurs commandes donc 0,n.

Oui !

• Une commande possède un ou plusieurs total (orders_total) donc 1,n.
• Un total appartient à une et une seul commande donc 1,1.

OK.

• Une commande contient un ou plusieurs produits (products) donc 1,n.
• Un produit peut être affecté à un ou plusieurs commandes donc 0,n.

Oui !

Passons au MCD...
Un petit détail sur l'association Adresse client...
L'entité 'customers' a un attribut 'customers_default_address_id', ce qui sous entend qu'il existe une association (non représentée ici donc le MCD est faux, il mélange du MCD et du MLD au moins à cet endroit) entre 'customers' et 'address' :
Customers -1,1----Avoir par défaut----0,n- Address

Dès lors, l'association Adresse client matérialise plutôt les autres adresses supplémentaires du client avec une règle de gestion qui serait :
"Un client peut avoir des adresses supplémentaires et une adresse peut être supplémentaire pour plusieurs clients".
Ce qui donnerait le MCD :
Client -0,n----Avoir supplémentairement----0,n- Adresse

D'une manière générale, éviter quand c'est possible les associations à cardinalités minimales à 1 de chaque côté car c'est plus embêtant à implémenter en base de données ensuite. C'est le cas par exemple pour l'association 'Appartient' entre 'address' et 'countries'. Il est possible que vous téléchargiez l'ensemble des pays dans votre BDD avant même d'avoir enregistré la moindre adresse. Votre modèle ne le permet pas !

Je ne sais pas si vous pouvez toucher à cette partie du modèle mais votre entité 'products' ne devrait pas contenir plusieurs colonnes pour les images. Il devrait y avoir une association entre 'products' et une entité pour les images.

De même, je le vois seulement maintenant, votre entité 'orders' ne devrait pas contenir d'attributs qui viennent de Customers, de address...

Courage ! Vous approchez du but !

Pour ce qui est de l'anglais et du français, je suppose que si vous écrivez les entités et les attributs en anglais, c'est par une contrainte de votre donneur d'ordre ?

Si vous êtes amené à générer automatiquement la BDD à partir du modèle, vous risquez d'avoir des tables associatives avec des mots français alors faites tout dans une seule langue, c'est mieux.

[bad111]

Bonjour à tout le monde et encore merci à toi CinePhil

J'ai arrangé mes règles et il est vrai que je cherche compliqué là où c'est simple. Voici ce que ca donne.

Règles de gestion.

• Un client (customers) peut être un organisme nous avons une cardinalité de 0,1.
• Un organisme (organism) est un client donc nous avons une cardinalité de 1,1 .

• Un client peut être un particulier donc 0,1.
• Un particulier (personal) est un client donc 1,1 .

• Un client peut avoir plusieurs adresse (address) donc 1,n.
• Une adresses est lié à plusieurs client (cas des immeubles) donc nous avons 1,n.

• Une adresse ne contient qu’un seul pays donc 1,1.
• Un pays (Countries) peut contenir plusieurs adresses donc nous avons 1,n.

• Un pays ne contient qu’un seul format d’adresse donc nous avons 1,1.
• Un format d’adresse contient plusieurs pays donc 1,n.

• Un client peut passer plusieurs commandes donc nous avons 0,n.
• Une commande ne concerne qu’un seul client donc nous avons 1,1.

• Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
• Une commande peut faire l'objet de plusieurs factures donc 0,n.

• Une commande obtient un ou plusieurs statut (orders_status) donc 1,n.
• Un statut peut être lié à une ou plusieurs commandes donc 0,n.

• Une commande possède un ou plusieurs total (orders_total) donc 1,n.
• Un total appartient à une et une seul commande donc 1,1.

• Une commande contient un ou plusieurs produits (products) donc 1,n.
• Un produit peut être affecté à un ou plusieurs commandes donc 0,n.

Pour le mcd je l'ai épuré. Il est vrai qu'il comportait trop de rodondance et de répétition.

voici ce que ca donne (voir lien)
http://www.esinger.fr/projetschema2.jpg



Par contre je n'ai pas bien compris ce que tu voulais dire

D'une manière générale, éviter quand c'est possible les associations à cardinalités minimales à 1 de chaque côté car c'est plus embêtant à implémenter en base de données ensuite. C'est le cas par exemple pour l'association 'Appartient' entre 'address' et 'countries'. Il est possible que vous téléchargiez l'ensemble des pays dans votre BDD avant même d'avoir enregistré la moindre adresse. Votre modèle ne le permet pas !

merci à toi c'est très gentil.

[CinePhil]

Si tu pouvais réduire l'image, ce ne serait pas plus mal !

Pour répondre à ta question, prenons le cas de l'association 'Appartient' entre Address et Countries.

Je crée un pays parce que je sais que je vais avoir des clients dans ce pays.
Comme la cardinalité mini côté Countries est à 1, le pays doit déjà figurer dans au moins une ligne de la table associative 'Appartient'.
Mais pour qu'une telle ligne existe, il faut que le pays existe déjà !

C'est le serpent qui se mord la queue à force de se demander qui de l'oeuf ou de la poule à engendré l'autre !

Il existe des mécanismes pour gérer ce genre de chose mais c'est à éviter quand ce n'est pas indispensable à la solidité de la base de données.

Ici, tu peux importer d'abord la table des pays, par exemple d'un fichier téléchargé sur Internet, avant de créer des clients donc des adresses qui figurent dans un pays de la table Countries.

Une autre petite chose :
Essaie d'adopter une méthode et de t'y tenir. Tu as des associations avec des verbes conjugués et d'autres avec des groupes de noms.
Et l'association entre Customers et Organism n'est pas 'Peut faire partie' (et encore moins 'Peut faire parti') mais 'peut être' ou plus exactement tout simplement le verbe 'Etre'. Personnellement, j'utilise les verbes à l'infinitif pour les associations, éventuellement avec un complément mais c'est rare.
Et si le verbe n'est pas clair pour un sens de lecture, tu peux ajouter un rôle à côté de la cardinalité concernée.

[Jimalexp]

Si tu pouvais réduire l'image, ce ne serait pas plus mal !

Hors sujet : Il y a la possibilité d'ajouter des pièces jointes ou d'encadrer des onglets avec des liens.

[url=http://www.monsite.com/blah.jpg][img]http://www.monsite.com/miniblah.jpg[./img][/url]

Pour réduire les images (attention à les sauvegarder sous un autre nom), il existe Irfanview : http://www.irfanview.com/

[bad111]

bonjour tout le monde.

Si tu pouvais réduire l'image, ce ne serait pas plus mal !

Oui c’est vrai quelles sont trop grandes, mais si je les réduis (même avec IrfanView) on ne voit plus les propriétés donc je les ai mis en lien. Je m’excuse pour la gêne occasionnée.

Ici, tu peux importer d'abord la table des pays,

Oui, en fait les pays sont déjà présents dans la table countries d’où ma cardinalité.

Essaie d'adopter une méthode et de t'y tenir.

Oui il est vrai que je saute parfois les étapes rien qu’au début j’aurai pu éviter pas mal d’erreurs en épurant mon model de toutes ces redondances et synonymes, mais c’est la qu’on se rend compte qu’il y a un pont entre la théorie et la pratique. Bref je voulais te remercier car sans toi Cinephil je ni serait jamais arrivé, merci.

alors faites tout dans une seule langue, c'est mieux.

Donc pour en revenir au mcd j’ai modifié les relations. Non seulement elles sont désormais en anglais mais en plus elles sont représentées par des mots simples (voir lien)http://www.esinger.fr/projetschema2.jpg.

Comme on peut aussi le constater j’ai modifié la cardinalité de ‘orders_invoice’ car après réflexion je me suis aperçu que mon plan ne prenait pas en compte le système déjà existant.

Pour m’explique voici l’expression des besoins client modifié.

Le site tatati.fr de vente en ligne désire ajouter à son système déjà existant, un système automatique de facturation par messagerie pour ses clients.

Chaque client pouvant consulter sa facture via son compte après son achat.
Il pourra désormais recevoir par messagerie, la facture le concernant au moment de la livraison de sa commande.

Vu que le client peut consulter sa facture immédiatement après achat la cardinalité 0.n devient 1.n.

Et voici les règles de gestions

Règles de gestion.

• Un client (customers) peut être un organisme nous avons une cardinalité de 0,1.
• Un organisme (organism) est un client donc nous avons une cardinalité de 1,1 .

• Un client peut être un particulier donc 0,1.
• Un particulier (personal) est un client donc 1,1 .

• Un client peut avoir plusieurs adresses (address) donc 1,n.
• Une adresse est lié à plusieurs clients (cas des immeubles) donc nous avons 1,n.

• Une adresse ne contient qu’un seul pays donc 1,1.
• Un pays (Countries) peut contenir plusieurs adresses donc nous avons 1,n.

• Un pays ne contient qu’un seul format d’adresse donc nous avons 1,1.
• Un format d’adresse contient plusieurs pays donc 1,n.

• Un client peut passer plusieurs commandes donc nous avons 0,n.
• Une commande ne concerne qu’un seul client donc nous avons 1,1.

• Une facture (orders_invoice) ne concerne qu’une seul commande donc 1,1.
• Une commande peut faire l'objet de plusieurs factures donc 1,n.

• Une commande obtient plusieurs statuts (orders_status) donc 1,n.
• Un statut peut être lié à plusieurs commandes donc 0,n.

• Une commande possède plusieurs total (orders_total) donc 1,n.
• Un total appartient à une et une seul commande donc 1,1.

• Une commande contient un ou plusieurs produits (products) donc 1,n.
• Un produit peut être affecté à plusieurs commandes donc 0,n.

Je pense que cette fois il n’y a pas d’erreur mais pourriez-vous me donner confirmation.
Et désolé encore pour la longueur du message.

[bad111]

Bonjour à tous bon j'ai beaucoup avancé

je suis obligé d'ouvrir un autre topic ( du mcd au mpd) car ça ne correspond plus à la question d'origine.

merci à vous