Discussion :

[bigey3]

Salut,

en ce moment jai un MCD(fichier joint) que je fais pour une bd MYsql.
J'utilise la version 15 de PowerDesigner.

je voudrais avoir un coup de main pour gerer la partie facturation de mes commandes.

Un coup de main SVP.


MErci

[fsmrel]

Bonsoir,


1) Lorsqu’une entité-type A fait référence à une entité-type B, vous avez répété systématiquement dans A l’identifiant de B, en tant que propriété. Dans un MCD, cette référence est implicite et ne doit pas figurer nommément dans A. A titre d’exemple, idType n’a rien à faire dans l’entité-type Produit. C’est suite à dérivation du MCD en MLD que Power AMC fera figurer idType dans la table Produit et établira un lien d’intégrité référentielle entre les tables Produit et TypeProduit.


2) Qu’est-ce que l’entité-type AttributProduit ?


3) LigneCommande est une association entre Produit et Commande :




Vous pouvez aussi considérer LigneCommande comme étant une propriété multivaluée de Commande :



En passant, la taxe n’est-elle pas une propriété de Commande ?


4) Concernant l’identification relative :

Dans le diagramme précédent, LigneCommande est identifiée relativement à Commande. Au niveau logique, LigneCommande aura pour clé primaire le couple {IdCmde, IdLigne} (et une clé alternative {IdCmde, CodeProduit} à mettre en œuvre à la main, car Power AMC (version 11 en tout cas) ne permet pas de la dériver d’un MCD). IdLigne n’est qu’un banal séquenceur permettant de distinguer chaque ligne d’une commande.
Plus généralement, l’identification relative se justifie tant pour des raisons sémantiques que pour des raisons bassement matérielles, liées à la performance des requêtes (réduction du nombre de tables à joindre, effet cluster et I/O bound, sujet que j’ai évoqué un certain nombre de fois dans ce forum). On vous dira que le MCD n’est pas concerné par la performance, mais on ne va quand même pas faire deux MCD, un que l’on affichera au mur pour l’édification des amateurs, et un qui servira pour la production du MLD.

Bref, si un catalogue est la propriété d’un fournisseur, vous pouvez l’identifier relativement à ce dernier au moyen d’un banal séquenceur IdCatalogue. A son tour, la catégorie peut être identifiée relativement au catalogue et la sous-catégorie relativement à la catégorie. Évidemment, au niveau du MLD, la table SousCategorie aura pour clé primaire le quadruplet {CodeFour, IdCatalogue, IdCategorie, IdSousCategorie} et la clé étrangère dans la table Produit comportera le même quadruplet. Ça fait beaucoup d’attributs, mais rien ne vous empêchera de considérer une identification seulement relative à Fournisseur et de réduire la clé à un couple {CodeFour, IdSousCategorie}. En outre, cela simplifiera les requêtes SQL pour connaître par exemple le nom du fournisseur d’un produit donné, puisque vous en connaîtrez directement le code. Et l'exécution de ces requêtes sera plus rapide.

Tant qu’à faire, vous pouvez pousser le bouchon plus loin et identifier Produit relativement à SousCategorie, et au niveau du MLD réduire la clé à un couple {CodeFour, CodeProduit}. Cela sera profitable une fois de plus aux requêtes SQL quand on voudra connaître le nom du fournisseur pour une commande donnée, puisque le code du fournisseur figurera dans la table LigneCommande.


5) En l’état, l’entité-type Regler doit disparaître.


6) Concernant les factures, peut-être pouvez-vous partir sur un diagramme tel que le suivant. Si c’est le même participant qui passe commande et règle, le lien Regler peut disparaître. A voir.

[bigey3]

Bonjour ,

En effet j'ai utilisé la version 15 POWER DESIGNER et je ne le maitrisais pas vraiment. Alors voila le schema de mon MCD avec la version 11.

En j'ai pas gerer les identifaint relatif car mon application web dont la bd sera en mysql ne supporte pas les identifiants relatifs.
Alors je ne sais pas trop commnet gerer tout sa!!

Vous voudriez bien me donner votre opinion sur la validité de mon MCD.


Merci pour le coup de pouce!

[fsmrel]

Bonjour bigey3,

1) Je repose ma question : Qu’est-ce que l’entité-type AttributProduit, quel est son rôle, pourriez-vous donner quelques exemples concrets de ses relations avec l’entité-type Produit ?

2) En principe, une facture correspond à une commande. Procédez-vous vraiment à des regroupements de commandes en relation avec une seule facture ? N'étant pas facturier, je me renseigne.

3) C'est quoi cette embrouille d'application web qui ne supporte pas les identifiants relatifs ? Au nom de l'indépendance des données et des traitements, une application n'a pas à se mêler de choses qui ne la concernent pas. Une application n’a accès qu’aux propriétés naturelles des entités. Un identifiant est une propriété artificielle, cachée à l’utilisateur et dont l’objet est de permettre de distinguer deux jumeaux parfaits. Prenons par exemple cas des produits. En toute rigueur, l’entité-type Produit est identifiée par un attribut artificiel, disons IdProduit, que ne connaît donc pas l’utilisateur, lequel n’a accès qu’aux propriétés naturelles telles que l’EAN13. L’attribut IdProduit n’est manipulable que par les requêtes SQL, notamment pour réaliser les jointures entre tables, mais n’est jamais présenté à l’utilisateur (clause SELECT).

Bon courage à vous,

fsmrel

[bigey3]

Bonjour,

1) L'entité AttributProduit permet en fait de gérer les propriétés variables de tous les produits. Tous les produits n'ont pas forcement les mêmes attributs(détails). Certains en ont moins d'autres plus. Par exemple certains auront une taxeF d'autres la taxeP. Ici TaxeF et TaxeP sont booléens
Lorsqu'un produit aura un nouvel attribut je souhaiterais pouvoir l'y rajouter dans ma BD sans trop de difficulté.

2) Effectivement le principe d'une facture correspond à une commande reste définie. Mais aussi un client peut faire plusieurs commandes et dans ce cas il faudra lui faire une facture qui récapitule l'ensemble de ses commandes

3)l'application en question c'est CakePHP il s'agit de Framework libre.
Alors je le maitrise pas trop encore mais on m'as assurer qu'il ne prenait pas en compte les identifiants relatifs alors j'en ai tenu compte dans mon MCD. pensez vous que non! Si vous l'avez deja utiliser vous voudriez bien me le confirmer aussi.


Merci et cordialement

[fsmrel]

1) L'entité AttributProduit permet en fait de gérer les propriétés variables de tous les produits. Tous les produits n'ont pas forcement les mêmes attributs(détails). Certains en ont moins d'autres plus. Par exemple certains auront une taxeF d'autres la taxeP. Ici TaxeF et TaxeP sont booléens
Lorsqu'un produit aura un nouvel attribut je souhaiterais pouvoir l'y rajouter dans ma BD sans trop de difficulté.

Dans ces conditions, les cardinalités ne sont-elles pas à inverser ?

3)l'application en question c'est CakePHP il s'agit de Framework libre.

La cata ! Ceux qui ont fait ce produit ne connaissent strictement rien au Modèle Relationnel de Données et prétendent transformer leur incompétence en fonctionnalité.
Voyez par exemple la discussion concernant les problèmes auxquels est confronté Avairet...

Je vous souhaire beaucoup de courage...

[bigey3]

salut,

Hormis les identifiants relatifs,mon MCD est il valide du point de vue logique en tenant compte de toute les entites?

Puis je considerer que les autres relations entre entites sont parfaites ou peu pres parfaite? bref puis gener mon modele physique?

Merci du coup de pouce!

[fsmrel]

Disons que la génération du MLD (appelé MPD par Power AMC) est jouable.

Puisqu'en réalité LigneCommande est une association entre Commande et Produit, n'oubliez pas d'ajouter la clé alternative {IdCmde, CodeProduit} dans la table LigneCommande (mickey <ak> dans le MLD) :



Vérifiez qu'il n'y a pas d'autres règles de gestion de ce genre à exprimer au niveau MLD.

Bonne route.