Discussion :

[Aizen64]

Bonjour,

j'ai 2 points ou je ne suis pas sur de l'approche à avoir en matière de modélisation.

1 :
Pour un contrat donné, il y a un signataire et potentiellement une personne différente qui est en charge de payer, le comptable ou autre.

Actuellement, j'ai mis un booléen entre ma table utilisateurs et contrat avec un champ estPayeur (cardinalité N, N).

Seulement, je suis dubitatif sur mon approche, c'est une facture qui est payée qui est elle même associée à un contrat. Associer une table ROLE à un utilisateur est incorrect puisque lié au contrat.

Le 2ème problème en question est la définition d'un moyen de paiement par défaut dans un contrat. Pour l'instant, une facture peut avoir plusieurs moyens de paiement et un moyen de paiement peut être associé à plusieurs factures. La table d'association un champ mode_paiement_defaut (qui forcément doit correspondre à une valeur dans la table moyens_paiement. Pas méga fan de ma propre approche. Des choses à redire ?

Pour info, SGBDR : Postgre 9.4.

[fsmrel]

Bonjour Aizen,

Dans votre modèle, je suppose que vous avez une table UTILISATEUR, une table CONTRAT, une table FACTURE et une association entre CONTRAT et FACTURE. S’il en est ainsi, quelles sont les cardinalités minimales/maximales entre ces deux tables ?

[Aizen64]

Bonjour,

Un contrat peut avoir 1,N factures, une facture est rattachée à un seul contrat.

Là, j'ai mis 2 booléens dans l'association entre utilisateur et contrat pour déterminer leur statut, soit titulaire ou payeur.

[fsmrel]

Bonjour Aizen,


D’après vos règles de gestion des données, votre MCD devrait ressembler à ceci :





Si l’on veut savoir qui a réglé la facture F1 du contrat C1, pas de problème, puisqu’une facture détermine son payeur via l’association Regler et le contrat via l’association Referencer.

[Aizen64]

Bonjour Aizen,


D’après vos règles de gestion des données, votre MCD devrait ressembler à ceci :





Si l’on veut savoir qui a réglé la facture F1 du contrat C1, pas de problème, puisqu’une facture détermine son payeur via l’association Regler et le contrat via l’association Referencer.

Merci pour la réponse.

Ce schéma ne prend pas en compte le fait qu'une personne est soit titulaire d'un contrat ou seulement la personne en charge du paiement mais sinon oui, le modèle correspond.

Avec quel outil ce MCD a été créé ? Une ancienne version d'AMC designor ?

[fsmrel]

Bonjour Aizen,

Avec quel outil ce MCD a été créé ? Une ancienne version d'AMC designor ?

Oui. La V4 d’AMC*Designor de 1993 (j'ai perdu la V3 ) !

Ce schéma ne prend pas en compte le fait qu'une personne est soit titulaire d'un contrat ou seulement la personne en charge du paiement mais sinon oui, le modèle correspond.

On va compléter en ajoutant une contrainte d’exclusion, telle que définie par la « norme » (journée Afcet du 15 novembre 1990) :




=>




Mais AMC ne permet de prendre formellement en compte ce genre de contrainte, j’ai donc surchargé à l’aide de PAINT. Par contre avec WinDesign, c’est possible.

Quoi qu’il en soit, cette contrainte devra faire l’objet d’une assertion (instruction CREATE ASSERTION de la norme SQL) ou d’un trigger quand le SGBD ne propose pas l‘instruction CREATE ASSERTION.

-- ---------------------------------------------------------------------------------------------------------------------------
-- La personne qui règle une facture ne peut pas être celle qui a signé le contrat auquel la facture fait référence  
-- ---------------------------------------------------------------------------------------------------------------------------

CREATE ASSERTION CX1 CHECK
    (NOT EXISTS
                (SELECT PersonneId 
                 FROM   FACTURE AS x 
                 WHERE  EXISTS (SELECT '' 
                                FROM CONTRAT AS y 
                                 WHERE x.PersonneId = y.PersonneId))) ;

[fsmrel]

J’ai oublié de joindre le script SQL de création des tables. Je comble :

CREATE TABLE PERSONNE 
(
   PersonneId           INT           NOT NULL,
   Nom                  VARCHAR(64)   NOT NULL,
   CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
) ;

CREATE TABLE CONTRAT 
(
   ContratId            INT           NOT NULL,
   PersonneId           INT           NOT NULL,
   Etc                  VARCHAR(64)   NOT NULL,
   CONSTRAINT CONTRAT_PK PRIMARY KEY (ContratId),
   CONSTRAINT CONTRAT_PERSONNE_FK FOREIGN KEY (PersonneId)
      REFERENCES PERSONNE (PersonneId)
) ;

CREATE TABLE FACTURE 
(
   FactureId            INT           NOT NULL,
   ContratId            INT           NOT NULL,
   PersonneId           INT           NOT NULL,
   FactureDate          DATE          NOT NULL,
   CONSTRAINT FACTURE_PK PRIMARY KEY (FactureId),
   CONSTRAINT FACTURE_PERSONNE_FK FOREIGN KEY (PersonneId)
      REFERENCES PERSONNE  (PersonneId),
   CONSTRAINT FACTURE_CONTRAT_FK FOREIGN KEY (ContratId)
      REFERENCES CONTRAT (ContratId)
) ;

[fsmrel]

En ce qui concerne les moyens de paiement :

Si un contrat a un moyen de paiement par défaut, et si la personne qui effectue le règlement peut choisir d’utiliser d’autres moyens, le MCD ressemble à ceci :





Remarque :

La patte d’association connectant FACTURE et Utiliser doit être porteuse d’une cardinalité 1,n. Si le moyen de paiement par défaut est utilisé, alors il devra faire partie des instances de l’association Utiliser. A contrario, s'il n’en fait pas partie, c'est qu’il n'aura pas été utilisé.

Si La patte d’association connectant FACTURE et Utiliser était porteuse d’une cardinalité 0,n et non pas 1,n cela voudrait dire que, si l’association Utiliser n’est pas instanciée pour une facture donnée, alors le moyen de paiement utilisé pour cette facture est celui qui a été défini par défaut pour le contrat auquel fait référence cette facture : d’accord jusqu’ici. Le problème est que si une facture a été réglée avec deux moyens de paiement, dont celui par défaut, on ne sait pas faire la différence avec le cas où la facture a été réglée avec un seul moyen de paiement qui n’est pas celui par défaut.

[Aizen64]

Grand merci pour la réponse.

J'avais oublié l'exclusion mutuelle, quand à son implémentation, je n'ai jamais eu à la faire jusqu'à présent.

Cette version d'AMC fonctionne sur une version récente de Windows ? Idéalement si elle pouvait fonctionner sous Linux.

Je vais essayer de mettre la main dessus et éviter de débourser 4 000 € chez SAP.

[fsmrel]

Cette version d'AMC fonctionne sur une version récente de Windows ?

Heu... A l’époque, l’installation se faisait à partir de disquettes ! Et comme les miennes ont plus de 20 ans, elles doivent être mal en point...

Mais il n’y a pas qu’AMC pour modéliser : j’utilise volontiers DB-MAIN, qui a l’avantage d’être gratuit, fonctionnellement complet et utilisable avec Linux. Il ne manque que le superflu, à savoir les rubans et les couleurs (voire des bricoles comme « undo »).

Allez, tiens, histoire de m’entraîner, je passe à DB-MAIN : je fais une rétro-conception à partir du code SQL pondu par AMC :





En passant, si des réponses ont pu vous aider, n’hésitez pas à voter (cela vaut pour les conversations ici ou là )

[Aizen64]

Une fois n'est pas coutume, j'ai voté positivement aux réponses fournies à mes posts.

Juste pour information, je n'utilise pas ces fonctionnalités en temps normal pour une raison simple que j'ai déjà évoquée :
- si j'ai un avis positif ou négatif, je l'écris en toutes lettres avec un argumentaire, les pouces verts et rouges sont des options binaires réductrices et impersonnelles qui ne permettent pas de savoir qui, ni même pourquoi tel ou tel commentaire est ou non apprécié.

Par conséquent, un merci bien formulé a pour moi plus de valeur que de nombreux +1/-1.

Bonne journée.