Discussion :

[layeoumar]

Bonjour,
Je suis débutant, j'ai fait une analyse pour connaître l'état de mes stocks de produits, des dettes envers les fournisseurs et de mes créances.
Voici quelques règles de gestion:
-les commandes fournisseurs et les factures peuvent être l'objet de plusieurs réglementent.
-Chaque produit a un seul type de TVA et un seul type de produit
je voudrais ensuite travailler sous Access.
Est -ce un bonne analyse ? Merci de votre aide

[fsmrel]

Bonjour Oumar,

Est -ce un bonne analyse ?

Ça commence pas mal.

Un premier lot de remarques :

Selon votre MCD, un règlement fait en même temps référence à une commande d’un fournisseur et à une facture d’un client, hum...

Je suppose que le type d’entité (entité-type) ENTREE fait référence à l’entrée d’un produit dans le stock. Est-ce bien cela ? (même principe pour SORTIE).

Attention, comme dirait CinePhil, au niveau opérationnel on pourrait avoir un produit P1 cité dans la ligne de commande et par mégarde créer des lignes d’entrée pour des produits autres que P1 (même principe pour les sorties). Il y a vraisemblablement une contrainte de chemin à mettre en place (exercice pas toujours facile !)

En passant :

Utilisez le singulier pour nommer un type d’entité (CLIENT et non pas CLIENTS).

[fsmrel]

Chaque produit a un seul type de TVA et un seul type de produit

Alors il faut remplacer les cardinalités 0,1 par des cardinalités 1,1 :

[TYPE_PRODUIT]----0,N----(AVOIR_POUR_TYPE)----1,1----[PRODUIT]----1,1----(AVOIR_POUR_TVA)----0,N----[TVA]

Entité-type PRODUIT, propriété QteStockee :

Normalement la quantité stockée est calculable en fonction des données déjà stockées (entités-types ENTREE, SORTIE) : la présence de la propriété correspondrait alors à une redondance, auquel cas elle devrait disparaître (et renaître au besoin au niveau MLD, lors de l’étape d’optimisation, avec mise en œuvre d’une contrainte pour garantir que la redondance est correcte en valeur...)


Les entités-types FOURNISSEUR et CLIENT pourraient faire l’objet d’une généralisation en une entité-type PERSONNE, avec mise en commun des propriétés communes.

[layeoumar]

Selon votre MCD, un règlement fait en même temps référence à une commande d’un fournisseur et à une facture d’un client, hum...

Bonjour,
Là est ce que vous me suggérez un règlement par commande et règlement par fournisseur? voulez vous m'expliquer svp.

Attention, comme dirait CinePhil, au niveau opérationnel on pourrait avoir un produit P1 cité dans la ligne de commande et par mégarde créer des lignes d’entrée pour des produits autres que P1 (même principe pour les sorties). Il y a vraisemblablement une contrainte de chemin à mettre en place (exercice pas toujours facile !)

J'ai pas bien compris compris, je rappelle que je suis un débutant.
Par contre d’après votre suggestion j ai pu apporter quelques modifications, mais quels seraient les propriétés spécifiques à l'Entité Fournisseur et à l'Entité Clients.

[fsmrel]

Bonjour Oumar,


D’accord pour les modifications apportées.

Là est ce que vous me suggérez un règlement par commande et règlement par fournisseur?

Oui. Le terme « règlement » est piégeant... Un règlement de la part d’un fournisseur est indépendant d’un règlement de la part d’un client, ne serait-ce que comptablement parlant : ils ne font pas l’objet des mêmes comptes. Arithmétiquement parlant, vous n’additionnez pas le montant d'un règlement de commande avec celui d'un règlement de facture : il y a là une dimension sémantique qui doit faire réfléchir. Il faut éviter la salade de concepts indépendants : si vous fusionnez les deux concepts, autant fusionner ceux de commande et de facture. A mon sens, il est pertinent de mettre en oeuvre une entité-type REGLEMENT_COMMANDE et une entité-type REGLEMENT_FACTURE.

=>



Au sujet de COMMANDE (idem pour FACTURE, toutes choses égales) : l'identifiant n'est pas du ressort de l’utilisateur, mais seulement du système, autrement dit il est non significatif et donc invariant. L’attribut identifiant CommandeId est artificiel, tandis que l’attribut NoAchat est naturel, l’utilisateur fait ce qu’il veut de ce dernier, avec pour seule contrainte qu’il s’agit d’un identifiant alternatif (voyez le mickey « <1> » dans le diagramme ci-dessus) : deux occurrences de COMMANDE ne peuvent pas avoir la même valeur pour NoAchat. Si vous avez des questions à ce propos, n’hésitez pas.

Notez l’identification relative (symbolisée par la cardinalité 1,1 portée par la patte connectant REGLER_CDE et REGLEMENT_COMMANDE) : une commande peut faire l’objet de plusieurs règlements, et un règlement de commande isolé, qui ne ferait pas référence à sa commande « mère » n’aurait pas de sens. REGLEMENT_COMMANDE est une entité-type faible (weak entity type) par rapport à COMMANDE, une propriété multivaluée de COMMANDE, ce que l’on traduit généralement par l’identification de l’une relativement à l’autre : pour la commande Cx, ses N règlements sont numérotés 1, 2, ..., N (attribut RegltCdeId), même chose pour chaque commande.

Code :

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

1
2
3
4
5
6
7
8
9
10
REGLEMENT_COMMANDE

CommandeId    RegltCdeId    ...         
----------    ----------    ---
         1             1
         1             2
         1             3
         2             1
         2             2
       ...           ...    ...

La réflexion concernant les attributs identifiants, artificiels d’une part et naturels d’autre part vaut bien sûr pour toutes les entités-types.

Je répète ici une histoire que je raconte de temps en temps dans ce forum :

L’excellentissime Yves Tabourier a énoncé il y a plus de 25 ans une recommandation que l’on peut élever au rang de règle d’or (De l’autre côté de MERISE page 80) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Autrement dit, identifier une entité-type telle qu’un véhicule automobile par un numéro d’immatriculation ou autres informations portées sur une carte grise est à éviter. De la même façon identifier une entreprise par son numéro Siren est à éviter dans un MCD. En effet, quand l’INSEE procède à la modification du numéro Siren d'une entreprise, ça peut être extrêmement pénalisant quant à la mise à jour de la base de données, conduire à monter des usines à gaz. Comme dit mon ami Chris Date : Better prevent than cure...

A propos de l’INSEE et de l’usine à gaz, je fais référence au système préconisé par les concepteurs dans une très grande banque pour identifier les entreprises : le numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Ce Siren était propagé dans toute la base de données par le jeu des liens inter-tables (clé primaire - clé étrangère). Les concepteurs avaient prévu une usine à gaz pour maintenir la cohérence du système, parce que l’INSEE envoyait tous les mois les nombreux correctifs modifiant les numéros de Siren erronés. Je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle, invariante et sans signification , appelons-la EntrepriseId, le numéro Siren devenant pour sa part une propriété comme les autres (c'est-à-dire accessible et modifiable), mais conservant toutefois sa spécificité fonctionnelle : être unique donc à élever au rang d’identifiant alternatif. Du point de vue de l’utilisateur et des règles fonctionnelles, pas de changement, mais le Siren ne figurait plus qu'à un seul endroit au lieu de cinquante, en conséquence de quoi l’usine à gaz disparut à temps en fumée et tout le monde s’en trouva satisfait.

Cardinalités 1,N vs 0,N

Selon votre MCD, une commande peut ne pas avoir de ligne de commande : est-ce bien raisonnable ? N’oubliez pas qu’au niveau conceptuel on modélise la finalité. En revanche, au niveau opérationnel on peut être amené à procéder autrement, par exemple parce que le SGBD ne permet pas de traiter l’INSERT d’une commande et celui d’une ligne de commande dans la même instruction, mais on verra cela plus tard, quand il faudra descendre dans la soute. Pour le moment on en reste au niveau conceptuel.

Cette réflexion sur la mise à niveau des cardinalités minima vaut pour la relation entre COMMANDE et LIGNE_ENTREE, etc.


Sous-types FOURNISSEUR et CLIENT

Lors de l'étape de vérification de l'intégrité, OMS affiche des warnings qui font loucher, tout ça parce que les sous-types n’ont pas d’attributs en propre... Pour lui faire plaisir, vous pouvez en fournir : par exemple, le taux de remise pour les fournisseurs et les conditions tarifaires pour les clients.


N.B.

Je prépare un message concernant ce qui vous échappe pour le moment (contrainte de chemin).

[fsmrel]

Bonsoir Oumar,


Pour reprendre l’histoire de la contrainte de chemin.

PRODUIT et COMMANDE sont en relation via deux chemins :

Chemin 1

[PRODUIT]----0,N----(LIGNE_COMMANDE)----1,N----[COMMANDE]

Chemin 2

[PRODUIT]----0,N----(STOCKER)----1,1----[ENTREE_STOCK]----1,N----(LIGNE_ENTREE)----0,N----[COMMANDE]

Supposons que la commande C1 porte seulement sur le produit P1, information portée par la relation LIGNE_COMMANDE :

Code :

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

1
2
3
4
5
PRODUIT      LIGNE_COMMANDE           COMMANDE

ProduitId    ProduitId  CommandeId    CommandeId 
---------    ---------  ----------    ----------
       P1           P1          C1            C1

Rien n’interdit (suite par exemple à une erreur de saisie) d’avoir la situation suivante :

Code :

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

1
2
3
4
5
PRODUIT          ENTREE_STOCK               LIGNE_ENTREE                          COMMANDE

ProduitId        ProduitId  EntreeId        LigneId  EntreeId  CommandeId         CommandeId
---------        ---------  --------        -------  --------  ----------         ----------
       P2               P2        E1             L1        E1          C1                 C1

C'est-à-dire que, suite à la commande C1, au lieu d’avoir procédé à une entrée pour le produit P1, on l’a fait pour le produit P2, ce qui en l’occurrence est une erreur. Comment se prémunir contre cela ? Bien sûr, on peut le contrôler par programme, mais on sait ce qu’il advient de la qualité du code au fil des ans et des maintenances.... Une autre façon de procéder consiste à s’arranger pour que le produit commandé et le produit faisant l'objet d'une entrée en stock soient le même, ce qui implique la mise en œuvre de l’identification relative et un zest de bricolage au niveau MLD (Je rabâche un peu, mais bon) :



Ceci n’est qu’une ébauche, je ne suis pas sûr des cardinalités pour l’association-type LELC, car je ne connais pas vos règles de gestion, mais avec la participation de CinePhil, Richard_35 et JPhi33 , on arrivera à quelque chose.

Je reprendrai un peu plus tard, car ... il est tard...

[CinePhil]

Bonjour François,
On retrouve là un schéma similaire à celui d'une récente discussion, établi par l'approche inverse, à partir du modèle relationnel.

LIGNE_ENTREE est identifiée relativement d'une part à LIGNE_CDE et d'autre part à ENTREE.

LIGNE_CDE est identifiée relativement à COMMANDE et à PRODUIT.

ENTREE est identifiée relativement à PRODUIT.

Quand on va générer le MLD avec les clés étrangères à partir de ce MCD, Open Modelsphere va mettre deux fois l'identifiant du produit dans la table LIGNE_ENTREE.
Il conviendra alors de supprimer manuellement l'une de ces deux colonnes ProduitId, tout en conservant les contraintes de clé étrangère, ce qui obligera bien le produit de la ligne d'entrée à être le même que celui de la ligne de commande. Je n'ai pas testé ce que ça donne ensuite lors de la génération du code SQL et l'implémentation dans le SGBD.

Au niveau MLD, pas d'ambiguïté possible, par contre, au niveau MCD, on peut toujours soupçonner la possibilité d'une différence entre le produit de la ligne de commande et le produit de la ligne d'entrée en stock. Il faut quand même faire une petite gymnastique intellectuelle pour s'assurer que ça fonctionne (c'est bon pour la santé ; un ami aimait à dire, quand nous étions jeunes, que le cerveau est le contraire des piles Wonder, il ne s'use que si l'on ne s'en sert pas !) et l'ajout d'une contrainte d'égalité dans le MCD ne serait pas superflue pour clarifier celui-ci.

[fsmrel]

Bonsoir,


Dans le MCD que j’ai proposé, il y a une bijection entre les entités-types LIGNE_CDE et LIGNE_ENTREE, cas de figure déjà traité, notamment ici. Pour ne pas tout mélanger, je vais partir du principe qu’une ligne d’entrée n’est créee que lorsque la commande a été satisfaite, c'est-à-dire peut-être jamais, auquel cas la bijection se transforme en injection :

On retrouve là un schéma similaire à celui d'une récente discussion, établi par l'approche inverse, à partir du modèle relationnel.

Oui. Il est évident que j’avais cet exemple en tête parmi d’autres. La partie de MCD que je propose ci-dessus correspond à la rétro-conception du modèle SQL suivant :

Concernant PRODUIT, ENTREE et COMMANDE :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
PRODUIT (ProduitId, ...)
    PRIMARY KEY (ProduitId) ; 

ENTREE (ProduitId, EntreeId, ...)
    PRIMARY KEY (ProduitId, EntreeId)
    FOREIGN KEY (ProduitId) REFERENCES PRODUIT ;

COMMANDE (CommandeId, ...)
    PRIMARY KEY (CommandeId) ;

Concernant LIGNE_CDE et LIGNE_ENTREE :

Code :

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

1
2
3
4
5
6
7
8
9
LIGNE_CDE (CommandeId, ProduitId, Quantite)
    PRIMARY KEY (CommandeId, ProduitId)
    FOREIGN KEY (CommandeId) REFERENCES COMMANDE 
    FOREIGN KEY (ProduitId) REFERENCES PRODUIT ; 

LIGNE_ENTREE (CommandeId, ProduitId, EntreeId)
    PRIMARY KEY (CommandeId, ProduitId)
    FOREIGN KEY (ProduitId, EntreeId) REFERENCES ENTREE 
    FOREIGN KEY (CommandeId, ProduitId) REFERENCES LIGNE_CDE ;

Où l’on observe que la colonne ProduitId ne figure qu’une fois dans l’en-tête de la table LIGNE_ENTREE.

Le MLD correspondant est le suivant (réalisé avec PowerAMC, car je n’ai pas trouvé comment faire avec OMS pour qu’un attribut participe simultanément à deux clés étrangères) :




L’AGL a produit deux colonnes ProduitId pour la table LIGNE_ENTREE (ce qui est normal) : pour résoudre la contrainte de chemin, il suffit d’en éliminer une des deux et faire participer celle qui reste aux deux clés étrangères notées <fk1> et <fk2> dans le MLD : dans ces conditions l’AGL produit un code SQL identique à celui que j’ai proposé.

Si on préfère modéliser la bijection, le code SQL devient :

CREATE TABLE :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
CREATE TABLE PRODUIT (
        ProduitId          CHAR(8)          NOT NULL,
        ...,
    CONSTRAINT PRODUIT_PK PRIMARY KEY (ProduitId)        
) ;
CREATE TABLE COMMANDE (
        CommandeId         CHAR(8)          NOT NULL,
        ...,
    CONSTRAINT COMMANDE_PK PRIMARY KEY (CommandeId)
) ;
CREATE TABLE LIGNE_CDE (
        CommandeId         CHAR(8)          NOT NULL,
        ProduitId          CHAR(8)          NOT NULL,
        Quantite           INT              NOT NULL,
    CONSTRAINT LIGNE_CDE_PK PRIMARY KEY (CommandeId, ProduitId)
  , CONSTRAINT LIGNE_CDE_COMMANDE_FK FOREIGN KEY (CommandeId) REFERENCES COMMANDE         
  , CONSTRAINT LIGNE_CDE_PRODUIT_FK FOREIGN KEY (ProduitId) REFERENCES PRODUIT         
) ;
CREATE TABLE ENTREE (
        ProduitId          CHAR(8)          NOT NULL,
        EntreeId           INT              NOT NULL,
        ...,
    CONSTRAINT ENTREE_PK PRIMARY KEY (ProduitId, EntreeId)
  , CONSTRAINT ENTREE_PROD_FK FOREIGN KEY (ProduitId) REFERENCES PRODUIT         
) ;
CREATE TABLE LIGNE_ENTREE (
        CommandeId         CHAR(8)          NOT NULL,
        ProduitId          CHAR(8)          NOT NULL,
        EntreeId           INT              NOT NULL,
    CONSTRAINT LIGNE_ENTREE_PK PRIMARY KEY (CommandeId, ProduitId)
  , CONSTRAINT LIGNE_ENTREE_ENTREE_FK FOREIGN KEY (ProduitId, EntreeId) REFERENCES ENTREE         
) ;

CREATE VIEW :

Code SQL :

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

1
2
3
4
5
6
CREATE VIEW LELC (CommandeId, ProduitId, EntreeId, Quantite)
AS 
    SELECT x.CommandeId, x.ProduitId, y.EntreeId, x.Quantite
    FROM   LIGNE_CDE AS x JOIN LIGNE_ENTREE AS y
           ON  x.ProduitId = y.ProduitId 
           AND x.CommandeId = y.CommandeId ;

CREATE TRIGGER (insert) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
 CREATE TRIGGER LELC_INSERT_TR ON LELC INSTEAD OF INSERT AS
 
select '' as 'INSERTED', *  from INSERTED ;
 
INSERT INTO LIGNE_CDE (CommandeId, ProduitId, Quantite)
       SELECT CommandeId, ProduitId, Quantite
       FROM   INSERTED ;
 
INSERT INTO LIGNE_ENTREE (ProduitId, EntreeId, CommandeId)
       SELECT ProduitId, EntreeId, CommandeId
       FROM   INSERTED ;

Un début de jeu d’essai (on n'insère pas directement dans les tables LIGNE_CDE et LIGNE_ENTREE, mais via la vue) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
INSERT INTO PRODUIT (ProduitId) VALUES ('P1') ;
INSERT INTO PRODUIT (ProduitId) VALUES ('P2') ;
INSERT INTO PRODUIT (ProduitId) VALUES ('P3') ;
 
SELECT '' as 'PRODUIT', * FROM PRODUIT ;
 
INSERT INTO COMMANDE (CommandeId) VALUES ('C1') ;
INSERT INTO COMMANDE (CommandeId) VALUES ('C2') ;
INSERT INTO COMMANDE (CommandeId) VALUES ('C3') ;
 
SELECT '' as 'COMMANDE', * FROM COMMANDE ;
 
INSERT INTO ENTREE (ProduitId, EntreeId) VALUES ('P1', 1) ;
INSERT INTO ENTREE (ProduitId, EntreeId) VALUES ('P1', 2) ;
INSERT INTO ENTREE (ProduitId, EntreeId) VALUES ('P2', 1) ;
INSERT INTO ENTREE (ProduitId, EntreeId) VALUES ('P3', 1) ;
INSERT INTO ENTREE (ProduitId, EntreeId) VALUES ('P3', 2) ;
 
SELECT '' as 'ENTREE', * FROM ENTREE ;
 
INSERT INTO LELC (CommandeId, ProduitId, EntreeId, Quantite) VALUES ('C1', 'P3', 1, 10) ;
INSERT INTO LELC (CommandeId, ProduitId, EntreeId, Quantite) VALUES ('C3', 'P3', 2, 50) ;
 
SELECT '' as 'LELC', * FROM LELC ;
 
SELECT '' as 'LIGNE_CDE', * FROM LIGNE_CDE ;
 
SELECT '' as 'LIGNE_ENTREE', * FROM LIGNE_ENTREE ;

Je crois, CinePhil, qu'on est en phase.

[layeoumar]

Bonjour,
Je vous remercie très sincèrement pour vos contributions claires que vous avez voulues apporter.
J'ai essayé de faire le MLD avec OMS, c'est très difficile à mon niveau. Je me contente de faire manuellement tout en respectant les contraintes.
A bientôt pour une autre discussion sur le forum