Discussion :

[imalys]

Bonsoir,
En fait, j'ai une erreur qui s'affiche quand je veux générer la base de données à partir du MPD .

voilà ce qui s'affiche:
catégorie :référence
Vérifier: référence réflexive et obligatoire.
objet:Référence 'APPARTENIR'
Emplacement:<modèle>

Je ne sais ce que cela veut dire !!
à savoir que 'appartenir 'est une association réflexive sur une table 'entitee'

Svp aidezz moi !!
Merci .

[fsmrel]

Bonsoir,


Quand vous demandez la vérification du MPD que se passe-t-il ?

Quand vous demandez la vérification du MCD que se passe-t-il ?

En tout cas, sans vision de vos modèles, on ne peut se prononcer.

[petitediablesse]

Bonjour Fsmrel,

j'essaye de vous envoyer un message en privée mais j'arrive pas vu le message d'erreur comme quoi vous avez depasser le quota de message privé , j'ai une problématique au niveau de mon projet actuel concernant la base de données et j'aimerai pas en discuter , est ce que je peux avoir une adresse mail ou je peux vous contacter parceque je suis nouvelle et je sais pas comment y faire depuis le site

[fsmrel]

Bonsoir,

Chez Developpez, l'usage n'est pas de résoudre les problèmes en privé : faites comme tout le monde, n'hésitez pas à exposer publiquement le vôtre, quitte à déguiser des données que vous estimez sensibles...

[petitediablesse]

Je suis actuellement sur un projet qui permet l’automatisation et l’optimisation du processus de calcul des commissions. Du coup je dois développer une application sous .net .

En ce moment je suis entrain d’établir un model de données pour la bases de données .


L’application doit comporter un module de paramétrage qui contiendra un onglet qui va permettre la gestion des client ( ajout , modification , suppression ) , un onglet qui listera les standards et un onglet de gestion de dérogation ( ajout , modification, suppression ).
Un module de calcul de commissions qui traitera trois calcul selon type de commission.
Pour effectuer les calculs , un autre service doit introduite un fichier externes qui contient les données nécessaires à ce calcul .
A chaque opération ( modification , suppression , erreur ) par rapport à chaque module , on doit garder un historique .
La base de données de l’applicatif possédera une base données sources et une base données calculés qui contiendra toutes les informations

J’ai établi un modèle de données qui est le suivant mais j’en suis pas sure surtout pour les historiques comment les modeliser et tout

Merci pour votre aide

[fsmrel]

Bonsoir,


Vous présentez un diagramme de classes, mais les multiplicités (cardinalités) y font défaut. Par exemple, on ne sait pas si une commission concerne un ou plusieurs apporteurs. Merci donc de faire figurer l’ensemble des multiplicités.

Bien qu’une classe ne soit pas astreinte à être dotée d’un quelconque attribut identifiant (contrairement aux entités-types merisiennes), si la base de données cible est de type SQL ou relationnel, pour éviter de faire du rapiéçage après coup, autant faire figurer et mettre en évidence au plus tôt ce genre d’attribut (qui donnera lieu a clé), invariant et dépourvu de toute signification.

La classe COMMISSION est dotée d’un attribut Type commission : si les valeurs possibles sont synonymes de "DDE", "DDG" et "OPCVM" il y a redondance du fait de la présence des sous-classes : n’oubliez pas que toute redondance est cause de bien des soucis et doit impérativement être éliminée.


Concernant l’historisation

Supposons que, concernant les apporteurs, vous gériez l’historique des informations suivantes : Nom de l'apporteur et RIB (au passage, qu’en est-il de l’attribut Domiciliation : s’agit-il de l’adresse de l'apporteur ? de sa domiciliation bancaire ?)

Par référence à la théorie relationnelle, la stratégie générale est la suivante :

Outre les attributs ne faisant pas l’objet de l’historisation, la classe APPORTEUR comporte :

— La valeur actuelle du nom de l’apporteur ainsi que la date depuis (since) laquelle cette valeur est effective,

— La valeur actuelle du RIB ainsi que la date depuis (since) laquelle il est effectif :

APPORTEUR 
    {
     ApporteurId, 
     CodeApporteur, 
     NomApporteur, 
     NomApporteurDepuis, 
     MailApporteur, 
     Domiciliation, 
     NumeroCompte,
     CodeBanque,
     CodeAgence,
     CleRIB,
     RIBDepuis,
     Bareme,
     BaremeDebut, 
     BaremeFin
    } ; 

L’attribut ApporteurId est identifiant. L’attribut CodeApporteur est identifiant lui aussi (alternatif). Si un RIB fait référence à un seul apporteur, le triplet {NumeroCompte, CodeBanque, CodeAgence} est identifiant alternatif lui aussi.

La classe APPORTEUR est accompagnée d’une classe par information historisée, portant la période durant laquelle (during) cette information a eu cours par le passé :

APPORTEUR_NOM_HISTO
    {
     ApporteurId, 
     NomApporteurDurant,
     NomApporteur
    } ;

NomApporteurDurant est du type période : une date de début et une date de fin.

L’identifiant de la classe APPORTEUR_NOM_HISTO est composé de la paire {ApporteurId, NomApporteurDurant}.


Concernant le RIB :

APPORTEUR_RIB_HISTO
    {
     ApporteurId, 
     RIBApporteurDurant,
     NumeroCompte,
     CodeBanque,
     CodeAgence
    } ;

RIBApporteurDurant est lui aussi du type période.

L’identifiant de la classe APPORTEUR_RIB_HISTO est composé de la paire {ApporteurId, RIBApporteurDurant}.

Ainsi, chaque information à historiser (le nom et le RIB dans l’exemple) fait l’objet d’une classe ad-hoc. Si N informations d’une classe sont sujettes à historisation alors on aura droit à N classes à cet effet.

Attention aux conseilleurs trop superficiels en matière de gestion des historiques (ce ne sont pas les payeurs), qui prétendraient qu’une seule classe suffit largement... Quoi qu’il en soit, la stratégie que je vous ai proposée est celle qui permet de respecter la sixième forme normale (6NF).

La référence en matière d’historisation :

C. J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data and the Relational Model. (San Francisco, Calif.: Morgan Kaufmann (2003)).

Voyez aussi les PDF de Darwen, par exemple Temporal Data and The Relational Model.

[petitediablesse]

Bonjour Monsieur ,

Merci beaucoup pour les précisions

Au fait pour la base de données ca sera developpé sous Oracle.

Je vous envoie le diagramme corrigé avec les cardinalités mais j'ai pas pu voir commment preciser les clé primaires sous Visio mlheureusement , du coup je vous les transmets ainsi :

code apporteur -> pour la classe apporteur
id standard -> pour la classe standard
id statut -> pour la classe statut
code apporteur (clé etrangére ) -> classe Derogation apporteur
N° compte -> classe Dérogation COntrat
Code apporteur -> classe commission

Effectivement pour le Type commissions il s'agit bien des commissions ' DDE' 'DDG' et 'OPCVM' , mais le petit soucis , c'est que il y a des champs comme montant HT et TTC qui existent dans les commissions 'DDG' et qui n'existent pas dans les autres , c'est pour ca j'ai crée des sous classes .

Pour les informations qu'il faut historisés , par exemple , pour la table ' Apporteur ' ,faut garder une trace rs d'une modifications de l'un de ces informations : RIB , Bareme , Date debut bareme , date fin bareme

garder toujours une trace lors de la supression d'un apporteur ( la date de supression par rapport à cet apporteur )


pour la table derogation par exemple , faut garder une trace lors de la modification d'une derogation , garder une trace des ancien montant , ancien taux , ancien date debut/date fin et la nouvelle date deb/fin

Merci beaucoup d'avance pour votre aide

[petitediablesse]

qu'est ce que vous me conseiller alors :/ parce que j'ai aucune visibilité là dessus

merci bcp

[fsmrel]

Patience, vous êtes quand même quelques uns, pour des sujets parfois délicats...

[petitediablesse]

d'accord ..merci pour votre aide

[fsmrel]

Bonsoir,

je n'ai pas pu voir comment préciser les clés primaires sous Visio.

D’accord. Cela dit, le terme clé primaire ne fait pas partie du vocabulaire UML dans le contexte des diagrammes de classes, mais du vocabulaire SQL. On parlera plutôt d’identifiant. Toutefois, comme vous évoquez le SGBD Oracle, on parlera de tables et de clés au moment opportun.

Bien qu’une classe ne soit pas astreinte à être dotée d’un quelconque attribut identifiant (contrairement aux entités-types merisiennes), si la base de données cible est de type SQL ou relationnel, pour éviter de faire du rapiéçage après coup, autant faire figurer et mettre en évidence au plus tôt ce genre d’attribut (qui donnera lieu a clé), invariant et dépourvu de toute signification.

Dans cette partie j’ai précisé (en gras) qu’un identifiant est invariant et dépourvu de toute signification. Le code apporteur, le RIB sont des données qui n’offrent pas ces garanties dans la mesure où ils ont été conçus indépendamment de votre système, c'est-à-dire inventés par l’utilisateur (code apporteur) où issus d’un système externe à l’entreprise (RIB). Lisez avec attention ce qui est écrit ici. Le code apporteur et le RIB sont des identifiants naturels, non artificiels, ils conservent leur propriété d’unicité et restent bien sûr les points d’entrée dans le système pour l’utilisateur, mais en vertu de ce que j’appelle le principe Tabourier, les associations entre classes se font uniquement par le canal des identifiants artificiels ({ApporteurId} par exemple).

Pour les informations qu'il faut historiser, par exemple pour la table ' Apporteur ', il faut garder une trace d'une modification de l'une de ces informations : RIB , Bareme , Date debut bareme , date fin bareme.

Puisque vous utilisez le terme « table » au lieu de « classe », on va le conserver, ça sera peut-être plus simple.

Pour le RIB, je vous renvoie à mon message précédent. Pour les autres attributs, le principe est le même (notez l’ajout entre autres de l’attribut ApporteurDepuis, permettant de savoir depuis quand une personne est apporteur) :

La table APPORTEUR caractérise l’état actuel d’un apporteur :

APPORTEUR 
    {
     ApporteurId, 
     ApporteurDepuis,
     CodeApporteur, 
     NomApporteur, 
     MailApporteur, 
     Domiciliation, 
     NumeroCompte,
     CodeBanque,
     CodeAgence,
     CleRIB,
     RIBDepuis,
     Bareme,
     BaremeDepuis,
     BaremeDebut, 
     BaremeDebutDepuis,
     BaremeFin
     BaremeFinDepuis
    } ; 

La table APPORTEUR_HISTO caractérise le passé d’un apporteur juste avant sa suppression. Les données non nommément historisées y seront accessibles, alors que les données nommément historisées (RIB, barème, dates du barème seront accessibles par le canal des tables APPORTEUR_RIB_HISTO, APPORTEUR_BAREME_HISTO, APPORTEUR_DEBUT_BAREME_HISTO, APPORTEUR_FIN_BAREME_HISTO). L’attribut ApporteurDurant caractérise la période pendant laquelle l’apporteur a été actif avant d’être supprimé :

APPORTEUR_HISTO
    {
     ApporteurId, 
     ApporteurDurant,
     CodeApporteur, 
     NomApporteur, 
     MailApporteur, 
     Domiciliation
    } ;

La table APPORTEUR_RIB_HISTO permet de conserver l’historique de chaque RIB de chaque apporteur dans les conditions suivantes : modification du RIB ou suppression de l’apporteur :

APPORTEUR_RIB_HISTO
    {
     ApporteurId, 
     RIBDurant,
     NumeroCompte,
     CodeBanque,
     CodeAgence
    } ;

La table APPORTEUR_BAREME_HISTO permet de conserver l’historique de chaque barème de chaque apporteur dans les conditions suivantes : changement du barème ou suppression de l’apporteur :

APPORTEUR_BAREME_HISTO
    {
     ApporteurId, 
     BaremeDurant,
     Bareme
    } ;

La table APPORTEUR_DEBUT_BAREME_HISTO permet de conserver l’historique de la date de début de chaque barème de chaque apporteur dans les conditions suivantes : changement de la date de début du barème en cours ou suppression de l’apporteur :

APPORTEUR_DEBUT_BAREME_HISTO
    {
     ApporteurId, 
     BaremeDebutDurant,
     BaremeDebut
    } ;

La table APPORTEUR_FIN_BAREME_HISTO permet de conserver l’historique de la date de fin de chaque barème de chaque apporteur dans les conditions suivantes : changement de la date de fin du barème en cours ou suppression de l’apporteur :

APPORTEUR_FIN_BAREME_HISTO
    {
     ApporteurId, 
     BaremeFinDurant,
     BaremeFin
    } ;

Concernant les barèmes, j’ai supposé que :

(R1) La date de début d’un barème en cours d’utilisation pour un apporteur peut être modifiée indépendamment de la date de fin, ce qui justifie la table APPORTEUR_DEBUT_BAREME_HISTO ;

(R2) La date de fin d’un barème en cours d’utilisation pour un apporteur peut être modifiée indépendamment de la date de début, ce qui justifie la table APPORTEUR_FIN_BAREME_HISTO ;

(R3) Le barème utilisé pour un apporteur peut être remplacé par un autre barème, ce qui justifie la table APPORTEUR_BAREME_HISTO.

A noter que les en-têtes des tables sont en fait des prédicats. Par exemple pour la table APPORTEUR :

Depuis le ApporteurDepuis, l’apporteur ApporteurId a pour code CodeApporteur, il a pour nom NomApporteur, pour adresse de courrier électronique MailApporteur, pour domicile Domiciliation, pour numéro de compte NumeroCompte, au guichet CodeAgence de la banque CodeBanque, la clé du RIB est CleRIB, son RIB est en cours depuis le RIBDepuis, son barème en cours est Bareme depuis le BaremeDepuis, la date BaremeDebut de début du barème vaut depuis le BaremeDebutDepuis, la date BaremeFin de fin du barème vaut depuis le BaremeFinDepuis.

N.B. Dans ce prédicat, j’ai utilisé le mot « domicile », mais je pose à nouveau la question : qu’en est-il de l’attribut Domiciliation : s’agit-il de l’adresse de l'apporteur ? de sa domiciliation bancaire ?

Prédicat de la table APPORTEUR_HISTO :

Durant la période ApporteurDurant, l’apporteur ApporteurId avait pour nom NomApporteur, pour adresse de courrier électronique MailApporteur et pour domicile Domiciliation.

Prédicat de la table APPORTEUR_RIB_HISTO :

Durant la période RIBDurant, l’apporteur ApporteurId avait pour numéro de compte NumeroCompte, au guichet CodeAgence de la banque CodeBanque.

Prédicat de la table APPORTEUR_BAREME_HISTO :

Durant la période BaremeDurant, le barème utilisé par l’apporteur ApporteurId avait été le barème Bareme.

Prédicat de la table APPORTEUR_DEBUT_BAREME_HISTO :

Durant la période BaremeDebutDurant, la date de début du barème utilisé par l’apporteur ApporteurId avait été BaremeDebut.

Prédicat de la table APPORTEUR_FIN_BAREME_HISTO :

Durant la période BaremeFinDurant, la date de fin du barème utilisé par l’apporteur ApporteurId avait été BaremeFin.

garder toujours une trace lors de la suppression d'un apporteur ( la date de suppression par rapport à cet apporteur.)

La table APPORTEUR_HISTO sert à cela, ainsi que les tables APPORTEUR_RIB_HISTO, APPORTEUR_BAREME_HISTO, APPORTEUR_DEBUT_BAREME_HISTO, APPORTEUR_FIN_BAREME_HISTO :

Quand on supprime un apporteur, les données actives CodeApporteur, NomApporteur, MailApporteur, Domiciliation sont hébergées par la table APPORTEUR_HISTO et les autres données actives sont hébergées dans les tables dédiées APPORTEUR_RIB_HISTO, APPORTEUR_BAREME_HISTO, APPORTEUR_DEBUT_BAREME_HISTO, APPORTEUR_FIN_BAREME_HISTO.

Cela dit, si votre règle de gestion de suppression est claire et simple, elle est dévastatrice ! En effet, les données actives ne sont pas limitées à celles dont je viens de parler, les commissions et les dérogations sont elles aussi à historiser dans leurs propres tables d'historisation...


Dans ce système, conforme à la théorie développée dans les ouvrages dont j’ai fait mention le 15 dernier, l’intégrité référentielle n’est pas implantable par le mécanisme des clés étrangères, mais en échange on développe les contraintes nécessaires et suffisantes, décrites dans ces ouvrages. En langage D ceci n’est pas un problème, mais avec SQL c’est une gageure (pour rester poli), avec à la clé des paquets de triggers. Aussi je propose de faire une entorse à la théorie : Quand on supprime un apporteur, on met à jour comme il se doit les tables d’historisation que je viens d’énumérer (sans oublier bien sûr les commissions et dérogations), mais au lieu de supprimer « physiquement » l’apporteur, on le supprimera « logiquement » en faisant passer un indicateur de la valeur « actif » à la valeur « supprimé » dans la table APPORTEUR, tandis que l’attribut ApporteurDepuis prendra comme valeur la date de suppression. On peut nommer StatutApporteur cet indicateur, et la structure devient :

APPORTEUR 
    {
     ApporteurId, 
     ApporteurDepuis,
     StatutApporteur,
     CodeApporteur, 
     NomApporteur, 
     MailApporteur, 
     Domiciliation, 
     NumeroCompte,
     CodeBanque,
     CodeAgence,
     CleRIB,
     RIBDepuis,
     Bareme,
     BaremeDepuis,
     BaremeDebut, 
     BaremeDebutDepuis,
     BaremeFin,
     BaremeFinDepuis
    } ; 

Et au lieu de développer des triggers SQL pour garantir l’intégrité référentielle, on sous-traite celle-ci au SGBD au moyen des clés étrangères :

Exemple, en Tutorial D :

VAR APPORTEUR BASE RELATION
    {
     ApporteurId, 
     ApporteurDepuis,
     StatutApporteur,
     CodeApporteur, 
     NomApporteur, 
     MailApporteur, 
     Domiciliation, 
     NumeroCompte,
     CodeBanque,
     CodeAgence,
     CleRIB,
     RIBDepuis,
     Bareme,
     BaremeDepuis,
     BaremeDebut, 
     BaremeDebutDepuis,
     BaremeFin,
     BaremeFinDepuis
    } 
    KEY {ApporteurId} 
    KEY {CodeApporteur} ; 

VAR APPORTEUR_HISTO BASE RELATION
    {
     ApporteurId, 
     ApporteurDurant,
     CodeApporteur, 
     NomApporteur, 
     MailApporteur, 
     Domiciliation
    } 
    KEY {ApporteurId, ApporteurDurant} 
    KEY {CodeApporteur, ApporteurDurant} 
    FOREIGN KEY {ApporteurId} REFERENCES APPORTEUR ;

Etc.

Il y a des représentations alternatives (et préférables) pour ce système, mais je ne voudrais pas vous traumatiser (si ce n’est déjà fait)...

J’ai encore des choses à dire, notamment au sujet des redondances, mais pour ce soir on en restera là.

merci bcp

Eu égard à la charte DVP, il est préférable que vous écriviez en français (ils pourraient vous coller un mauvais point ).

[fsmrel]

Une question complémentaire :

Je perçois mal les multiplicités (cardinalités) du lien connectant COMMISSION et DEROGATION dans votre diagramme. Quelles sont exactement les règles de gestion concernant cette connexion ?

[petitediablesse]

Bonjour ,

merci pour votre retour,

Concernant votre premiére question : il s'agit bien d'une domiciliation bancaire .

Pour le deuxiéme point concernant les cardinalités entre les derogations et commissions , merci de me poser la question , çela m'a permis de voir que je me suis trompé parceque en fait la liaison est plutot entre Derogations et apporteur et non entre derogation et commission .
les regles de gestion sont :
- une derogation peut etre appliqué à un apporteur
- un apporteur peut avoir plusieurs derogations ( vu qu'il peut posseder plusieurs contrats )

[fsmrel]

Bonsoir,

il s'agit bien d'une domiciliation bancaire.

D’accord. J’ai donc des observations à faire quant à la présence de l’attribut Domiciliation dans l’en-tête de la classe APPORTEUR. Au préalable, quelle est votre position quant aux règles de gestion suivantes :

(R1) Un apporteur (identifié par CodeApporteur du point de vue de l’utilisateur) a un seul compte (identifié par le triplet {CodeBanque, CodeAgence, NumeroCompte}) ;

(R2) Pour un compte (identifié par le triplet {CodeBanque, CodeAgence, NumeroCompte}) il n’y a qu’un seul apporteur.

(R3) La relation entre {Domiciliation} et {CodeBanque, CodeAgence} est bijective : une domiciliation est l’adresse d’une agence d’une banque et cette agence n’a qu’une adresse.

Concernant les cardinalités entre les dérogations et commissions , merci de me poser la question , cela m'a permis de voir que je me suis trompé parce que en fait la liaison est plutôt entre Dérogations et apporteur et non entre dérogation et commission.
les règles de gestion sont :
- une dérogation peut être appliquée à un apporteur
- un apporteur peut avoir plusieurs dérogations (vu qu'il peut posséder plusieurs contrats )

Si une dérogation existe, c’est qu’elle vaut pour exactement (c'est-à-dire au moins et au plus) un apporteur. Dans ces conditions, l’énoncé « une dérogation peut être appliquée à un apporteur » est à remplacer par celui-ci : « une dérogation est appliquée à exactement un apporteur ».

Par ailleurs, vous évoquez les contrats : leur implication dans les dérogations rend leur présence nécessaire dans le diagramme de classes.


Règles à confirmer ou infirmer (en justifiant) :

(R4) Un apporteur détient au moins un contrat.

(R5) Un contrat appartient exactement à un apporteur.

(R6) Un contrat peut ne pas faire l’objet de dérogation.

(R7) Un contrat fait l’objet au plus d’une dérogation.

Merci de préciser exactement votre position par rapport aux règles que j’ai proposées, R1 à R8, corrigez-les au besoin.

[petitediablesse]

Bonjour ,

Pour les régles de gestion évoquées , elles sont correctes sauf la R7

R7: un contrat peut avoir une seule dérogation et pas plusieurs .


pour les informations concernant les contrats ainsi les apporteurs seront exportées d'une base de données externe qui seront appelé dans une zone tampon lors des calculs , donc est ce que faut quand meme malgré cela , les intégrer dans mon modéle de données sinon comment je pourrai procéder ?

Lors de cette modification donc mon application n'aura plus un onglet qui gerera ' l'ajout / modification / suppression d'un apporteur ' mais en l'occurence on me demande lors des calculs de commissions quand on fait appel aux informations apporteurs je garde un historique juste des deux élements suivant à savoir : ' le RIB de l'apporteur ainsi le baréme appliqué '.

Merci beaucoup

Cdlt

[fsmrel]

Bonsoir,

Pour les règles de gestion évoquées, elles sont correctes sauf la R7.

(R7) Un contrat fait l’objet au plus d’une dérogation.

R7: un contrat peut avoir une seule dérogation et pas plusieurs.

Heu... Manifestement je n’ai pas écrit autre chose...

En ce qui concerne la classe DEROGATION, vous avez défini deux sous-classes : DEROGATION CONTRAT et DEROGATION APPORTEUR. On est d’accord qu’un contrat peut faire l’objet d’une seule dérogation, mais un apporteur peut-il avoir plusieurs dérogations de type DEROGATION APPORTEUR ?

pour les informations concernant les contrats ainsi les apporteurs seront exportées d'une base de données externe qui seront appelé dans une zone tampon lors des calculs

Ici on modélise le « Quoi » et pas le « Comment », donc les mouvements entre la base de données et la zone tampon ne sont pas à prendre en considération. En revanche si vous manipulez des données non modélisées jusqu’ici, votre diagramme est à compléter en conséquence car la magie ou la boule de cristal ne sont d'aucun secours pour mettre à jour et interroger les bases de données.

mon application n'aura plus un onglet qui gérera ' l'ajout / modification / suppression d'un apporteur '

Rebelote en ce qui concerne le « Quoi » : que viennent faire les onglets dans la modélisation des données ? Quelque chose m’échappe... Voulez-vous dire que vous n’avez plus à traiter de la suppression des apporteurs ? Est-ce devenu hors sujet ?

on me demande lors des calculs de commissions quand on fait appel aux informations apporteurs je garde un historique juste des deux éléments suivant à savoir : ' le RIB de l'apporteur ainsi le barème appliqué '

J’ai précédemment exposé la méthode à suivre pour modéliser les historiques des RIB et des barèmes. Il est temps que vous mettiez votre diagramme à jour.

[petitediablesse]

Bonjour ,


''En ce qui concerne la classe DEROGATION, vous avez défini deux sous-classes : DEROGATION CONTRAT et DEROGATION APPORTEUR. On est d’accord qu’un contrat peut faire l’objet d’une seule dérogation, mais un apporteur peut-il avoir plusieurs dérogations de type DEROGATION APPORTEUR ? ''

Pour votre question , on a une seule dérogation soit par apporteur soit par contrat ( une dérogation pour un apporteur ou pour un contrat )




''Rebelote en ce qui concerne le « Quoi » : que viennent faire les onglets dans la modélisation des données ? Quelque chose m’échappe... Voulez-vous dire que vous n’avez plus à traiter de la suppression des apporteurs ? Est-ce devenu hors sujet ?''

Normalement , on allait définir une partie dans la base de données qui regroupent tous les informations des apporteurs propre à la nouvelle application , mais le chef a décidé autrement et veut qu'on traite plus ça dans l'applicatif et qu'on se sert de faire une liaison entre une base de données externe d'un autre applicatif pour avoir les données necessaires
QUOTE]

[petitediablesse]

je rebondis aussi sur un autre point qu'on a évoqué précedement , vous m'avez bien posé la problématique suivante :

'' La classe COMMISSION est dotée d’un attribut Type commission : si les valeurs possibles sont synonymes de "DDE", "DDG" et "OPCVM" il y a redondance du fait de la présence des sous-classes : n’oubliez pas que toute redondance est cause de bien des soucis et doit impérativement être éliminée.''

donc , Effectivement pour le Type commissions il s'agit bien des commissions ' DDE' 'DDG' et 'OPCVM' , mais le petit soucis , c'est que il y a des champs comme montant HT et TTC qui existent dans les commissions 'DDG' et qui n'existent pas dans les autres , c'est pour ca j'ai crée des sous classes .

est ce que, dans ce cas , je garde les deux sous classes ou bien vous voyez toujours qu'il y a une redondance de données .

Merci d'avance

[fsmrel]

Bonsoir,

D’une part vous écrivez :

un apporteur peut avoir plusieurs dérogations (vu qu'il peut posséder plusieurs contrats)

D’autre part :

On a une seule dérogation, soit par apporteur soit par contrat.

Il reste quand même une part d’ambiguïté dans votre formulation. Pour le moment, J’interprète ainsi les règles en les appliquant à l'apporteur Raoul :

— L’apporteur Raoul peut avoir une (et au maximum une) dérogation de niveau apporteur, mais alors il ne peut pas avoir de dérogation de niveau contrat.

— A condition de ne pas avoir de dérogation de niveau apporteur, ce même Raoul peut avoir des dérogations de niveau contrat, au maximum une dérogation par contrat.

Est-ce ainsi que vous voyez les choses ?


Par ailleurs, pourquoi avoir fait figurer l’attribut NoCompte dans la sous-classe DEROGATION_CONTRAT ? En toute logique c’est le numéro de contrat qui devrait figurer. Je rappelle que vous avez confirmé qu’un apporteur a un seul compte (règle R1), donc si deux des contrats de l’apporteur Raoul font l’objet chacun d’une dérogation, en l'absence de référence à ces contrats, comment pouvez-vous savoir de quels contrats il s’agit ?

Mon application n'aura plus un onglet qui gérera 'l'ajout / modification / suppression d'un apporteur'

Donc vous ne supprimerez jamais un apporteur. Est-ce d’accord ?

il y a des champs comme montant HT et TTC qui existent dans les commissions 'DDG' et qui n'existent pas dans les autres , c'est pour ca j'ai crée des sous classes.

Vous pouvez utiliser les sous-classes, mais alors l’attribut TypeCommission est de trop et doit dégager (au fait, que fait-il dans la classe DEROGATION ?). Reste le cas de la présence de l’attribut TypeCommission dans la classe STANDARD : une contrainte devra assurer la cohérence des sous-classes avec la valeur prise par l’attribut TypeCommission de la classe STANDARD.

Si vous n’utilisez pas les sous-classes, la classe COMMISSION devra comporter les attributs MontantHT, TVA et MontantTTC : si vous savez quelle est le type du montant pour les commissions OPCVM et DDE, par exemple TTC, vous renseignez MontantTTC et laissez le reste à 0, mais ça n’est pas de la bonne cuisine. Une fois de plus, l’attribut TypeCommission ne devrait pas être présent pour la classe COMMISSION, puisqu’il figure déjà dans la classe STANDARD. Et bien sûr, une contrainte devra alors assurer la cohérence entre les valeurs prises par les montants et le type de commission figurant dans STANDARD. Maintenant, si vous tenez à la présence de l'attribut TypeCommission dans la classe COMMISSION, alors il est doit être évacué de la classe STANDARD. Difficile d’en dire plus en l’absence d’une connaissance approfondie de l’application...

[petitediablesse]

Bonjour ,

Oui tout à fait en ce qui concerne les derogations ,
j'ajoute que une dérogation peut etre appliqué à l'ensemble du portfeuille d'un apporteur ( donc tous les contrats qui les constituent ) et dans ce cas on parle de dérogation Apporteur ( ou derogation par apporteur )
sinon une dérogation est appliqué à un contrat spécifique d'un apporteur et dans ce cas on parle de dérogation contrat ( ou dérogation par contrat ).
et pour l'attribut NoCompte = N° contrat bien sure .

// Citation:
Envoyé par petitediablesse
Mon application n'aura plus un onglet qui gérera 'l'ajout / modification / suppression d'un apporteur'

Donc vous ne supprimerez jamais un apporteur. Est-ce d’accord ? //

Toutes les informations seront remportées depuis une autre base de données avec qui on fera le lien avec notre applicatif donc les opérations suppression ou autre sur la classe apporteur seront faites ailleurs ( on aura pas la main dessus )


[COLOR="red"]//Vous pouvez utiliser les sous-classes, mais alors l’attribut TypeCommission est de trop et doit dégager (au fait, que fait-il dans la classe DEROGATION ?).
Pour le type de commission , il apparait dans la classe Derogation parceque la dérogation appliqué différe selon le type de commission

// Reste le cas de la présence de l’attribut TypeCommission dans la classe STANDARD : une contrainte devra assurer la cohérence des sous-classes avec la valeur prise par l’attribut TypeCommission de la classe STANDARD.
//

Pour le type de commission dans standard ( ou ce qu'on appelle aussi par Régle de commissionnement ) parceque il existe deux standard de calcul selon le type de commission ce qui justifie la présence de cet attribut dans la classe standart

Pour la contrainte qui peut les relier est ce que on peut définir type de commission etant une clé étrangére ?


c'est comme ca que j'ai compris les choses , peut etre c'est pas juste

Merci d'avance