1. #21
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour

    merci pour votre réponses mais je veux confirmer quelque point en repondant au mes question:

    Mais du point de vue de la théorie relationnelle, il n’y a pas de redondance (ou disons que c’est de la « bonne redondance ») : celle-ci n’existerait à tort que si l’on violait la 5e forme normale (ou plus modestement la forme normale de Boyce-Codd, voire la troisième forme normale), or toutes les tables présentes dans le MLD respectent la cinquième forme normale, elles sont donc saines.
    (Q4) voulez vous dire qu'il n'y a pas de redondance et les tables ne contiennent aucune redendance. et s'il existe, c'est parce que on a violé la 5FN ou FN de de Boyce-Codd et ce n'est pas grave car c'est la « bonne redondance ». c'est bien cela?


    quand j'ai met la remarque:

    Citation Envoyé par bensam1
    Moi personnellement je ne préfère pas les table volumineux à cause des répétitions de données surtout si un compte de charge spécial a affecté à un grande nombre de structures régional. C’est pour ça j’ai fait une relation d’héritage entre compte de charge et compte spécial et j’ai met une relation entre compte de charge spécial et structures régionales.
    (Q5) dans la théorie relationnelle, la répétition des données sur la table CC_STR_SPECIAL n'est pas une redondance. N'est ce pas ?

    j'ai posé une question dans la message #17

    Citation Envoyé par bensam1
    Quelle est la différence entre relation réflexive comme j’ai fait avec domaine et la relation hiérarchisé et vos deux relations parent et enfant avec l’entité domaine ?
    et vous avez répondu le suivant:

    Dans un 1er temps, étant donné que la patte de droite (c’est-à-dire enfant) connectant DOMAINE et HIÉRARCHISER est porteuse d’une cardinalité 1,1, cela veut dire qu’un domaine a toujours un domaine parent : la hiérarchie n’en est pas une, car si le domaine dom1 est au sommet de la hiérarchie, selon votre représentation il a malheureusement un parent.

    Dans un 2e temps, en supposant que vous remplaciez la cardinalité 1, par la cardinalité 0,1, au stade SQL le domaine dom1 n’aura pas de parent, ce qui est plus conforme, mais l’attribut Id_domaine_parent sera marqué NULL, or le bonhomme NULL est l’ennemi des bases de données relationnelles. En procédant comme j’ai fait, j’interdis à ce malfaisant de se manifester.
    j'ai lu ce tutorial sur MCD Paragraphe III-A-2-d. et je pense qu'on peut faire une relation réflexive comme ça:

    Nom : domainMCD.png
Affichages : 210
Taille : 8,0 Ko

    En MLD ça devient:

    Domaine (id_Dom, desi_dom, abrev_dom)
    hierarchiser par (id_dom_fils#, id_Dom_parent#)

    Légende :
    x : relation
    x : clef primaire
    x# : clef étrangère

    là j'ai pas un clé étranger id_dom null, mais j'ai créer une relation a part hiérarchiser par qui contient les deux clés étrangères de id_dom.

    (Q6)que pensez vous?

  2. #22
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir bensam1,


    Citation Envoyé par bensam1
    (Q4) Voulez vous dire qu'il n'y a pas de redondance et les tables ne contiennent aucune redondance. et s'il existe, c'est parce que on a violé la 5FN ou FN de de Boyce-Codd et ce n'est pas grave car c'est la « bonne redondance ». c'est bien cela?

    Je n’ai pas exactement dit ça. J’ai dit que la FN de de Boyce-Codd ne doit pas être violée, même chose concernant la 5FN. Pour autant, la 5FN peut être respectée tout en comportant des redondances, mais celles-ci sont contrôlées par le SGBD, c’est pourquoi c’est de la bonne redondance, permettant notamment de garantir à moindre frais les contraintes de chemin.
    Ceux qui critiquent la redondance oublient que, sans redondance, on ne pourrait pas mettre en œuvre des bases de données. Ainsi, l’opérateur JOIN permet de rapprocher des valeurs égales (donc redondantes !) mettant en jeu deux tables (voire une seule dans le cas des associations réflexives).

    Même dans les systèmes pré-relationnels prétendus non redondants, la redondance est en fait présente, mais implicite, invisible car sous le capot, prenant la forme d’adresses (pointeurs) au lieu de valeurs explicites telles que "cagad" ou "cerma".


    Prenons le cas de la table CC_AFFECTATION_CA

    
    domaine    compte_analytique    compte_charge
    -------    -----------------    -------------
    dcbr       cagad                cerma
    dcbr       capaut               cerma
    dcbr       cagad                cpdr
    dav        cagad                cfvm
    dcbr       capmr                cerma
    
    
    Le domaine dcbr est associé 3 fois au compte analytique "cagad", mais de la même façon, dans un système réseau Codasyl des années soixante, soixante-dix, la valeur "cagad" sera replacée par 3 adresses (pointeurs) ayant la même valeur, même chose pour le compte de charge "cerma" :






    Là ou la redondance est « mauvaise », c’est on viole la 2NF ou la 3NF, etc.

    Dans ce qui précède, que ce soit dans un contexte relationnel ou pré-relationnel,, les données sont redondantes, mais l’information ne l’est pas : la redondance permet d’obtenir de nouvelles informations.

    Maintenant, un exemple de mauvaise redondance.

    Dans l’exemple ci-dessous, dans la table CC_AFFECTATION_CA, on a fait figurer le libellé du compte de charge, ce qui provoque un viol le la 2NF :


    
    domaine    compte_analytique    compte_charge     libelle_compte_charge 
    -------    -----------------    -------------     ----------------------------------------
    dcbr       cagad                cerma             entretien et réparation de matériel auto
    dcbr       capaut               cerma             entretien et réparation de matériel auto
    dcbr       cagad                cpdr              pièces de rechange
    dav        cagad                cfvm              frais de visite médicale
    dcbr       capmr                cerma             entretien et réparation de matériel auto
    
    

    Dans cet exemple, trois fois l’attribut compte_charge prend la valeur "cerma", trois fois on doit donc faire figurer le libellé "entretien et réparation de matériel auto". La théorie de la normalisation nous montre que l’attribut libelle_compte_charge doit être expulsé (vers la table des comptes de charge), car au plan de vue de l’information, apprendre une fois que quelque chose est vrai suffit, à savoir que de compte de charge "cerma" a pour libellé "entretien et réparation de matériel auto". L’apprendre 3 fois ou mille fois est un bavardage parfaitement inutile, voire dangereux, on n’est pas sourd (et ça complique la programmation, ça consomme de la surface disque, ça encombre la mémoire, etc.)



    Citation Envoyé par bensam1
    (Q5) dans la théorie relationnelle, la répétition des données sur la table CC_STR_SPECIAL n'est pas une redondance. N'est ce pas ?
    C’est une redondance en termes de données, , mais pas en terme d’information, c’est correct, voyez ci-dessus. Par contre, apprendre plus d’une fois que le compte de charge "cerma", a pour nom "entretien et réparation de matériel auto" est non seulement une redondance de données, mais aussi en termes d’information, et là ça ne passe pas.



    Citation Envoyé par bensam1
    Moi personnellement je ne préfère pas les table volumineux à cause des répétitions de données surtout si un compte de charge spécial a affecté à un grande nombre de structures régional. C’est pour ça j’ai fait une relation d’héritage entre compte de charge et compte spécial et j’ai met une relation entre compte de charge spécial et structures régionales.
    Je ne peux que répéter ce que j’ai écrit dans le message #20 : votre modélisation ne viole pas les règles de la normalisation, mais en revanche vous ne pouvez pas garantir de façon simple les contraintes de chemin : ça nécessiterait la mise en place de triggers, et là il y a du travail en perspective et des surprises quand on n’a pas une très grande habitude.



    Citation Envoyé par bensam1
    j'ai lu ce tutorial sur MCD Paragraphe III-A-2-d. et je pense qu'on peut faire une relation réflexive comme ça:





    Oui. C’est que je vous avais déjà proposé dans le message #5 :






    Je vous renvoie maintenant au message #16, dans lequel je précise un peu plus les choses :

    Au stade MCD :





    Au stade relationnel :






    Citation Envoyé par bensam1
    (Q6)que pensez vous ?
    On est en phase.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #23
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    Bonjour
    Ça fait longtemps que je n’ai pas discuté sur mon conception et je vous remercie infiniment vous avez m'aidé boucoup
    J’ai préparé mon mcd et je vous le proposer par partie voici la 1er partie

    Nom : mcd_part1.png
Affichages : 203
Taille : 34,5 Ko

    J’ai met une relation entre compte de charge et domaine car il y a des compte de charges spécial qui sont en relation que avec certain domaine et n’ont aucune relation avec compte analytique.

    Voici la 2em partie

    Nom : mcd_part2.png
Affichages : 270
Taille : 33,8 Ko

    Pour la 3eme partie :

    Nom : mcd_part3.png
Affichages : 236
Taille : 37,4 Ko

    Si on supposant le cas que le structure fait référence an un seul et un seul compte de charge qui en relation avec un compte analytique. Et dans ce cas il y a une propagation par l'identification relative de domaine et compte analytique et compte de charge sera au niveau de structure qui une situation n’est pas favorisée. Veuillez svp de donner vos aides et vos propositions

    a bientôt

  4. #24
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Spécialisation des comptes de charge

    Bonsoir bensam1,


    Citation Envoyé par bensam1
    Ça fait longtemps que je n’ai pas discuté sur mon conception et je vous remercie infiniment vous m’avez beaucoup aidé
    Cela fait effectivement un bon moment qu’on n’a pas discuté

    Si vous estimez que j’ai pu vous aider, alors n’hésitez pas à voter pour les messages qui ont contribué à cette aide (pouce vert en bas à droite), et confirmer ici des médailles acquises sur différents terrains souvent difficiles...



    Citation Envoyé par bensam1
    Il y a des comptes de charges spécial qui ne sont en relation qu’avec certain domaine et n’ont aucune relation avec compte analytique.
    D’accord. Toutefois, selon votre MCD, rien n’empêche que le compte de charge cc1 atteigne le domaine d1 en suivant :

    (a) Le chemin Compte_charge > Cc_affect_ca > Cc_affectation_ca > Cc_affect_ca_dom > Ca_affectation_dom > Dom_affect > Domaine ;

    (b) Le chemin Compte_charge > Cc_affecter_dom > Domaine.

    Autrement dit, on retrouve une boucle piégeuse...

    Pour éviter cela, vos pourriez spécialiser les comptes de charge, d’une part en comptes de charge associés à des comptes analytiques et d’autre part ceux qui ne le sont pas :





    Question :

    Où sont passées les structures régionales ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  5. #25
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour
    Citation Envoyé par fsmrel Voir le message
    D’accord. Toutefois, selon votre MCD, rien n’empêche que le compte de charge cc1 atteigne le domaine d1 en suivant :

    (a) Le chemin Compte_charge > Cc_affect_ca > Cc_affectation_ca > Cc_affect_ca_dom > Ca_affectation_dom > Dom_affect > Domaine ;

    (b) Le chemin Compte_charge > Cc_affecter_dom > Domaine.

    Autrement dit, on retrouve une boucle piégeuse...

    Pour éviter cela, vos pourriez spécialiser les comptes de charge, d’une part en comptes de charge associés à des comptes analytiques et d’autre part ceux qui ne le sont pas :
    on peut pas prendre en compte le chemin (a) car ce compte de charge spécial en relation avec domaine n'est pas en relation avec le compte analytique. il y a que b dans ce cas alors il n'y a pas une boucle piégeuse sinon pourquoi c'est une boucle piégeuse?


    Citation Envoyé par fsmrel Voir le message
    Question :

    Où sont passées les structures régionales ?
    la structure_DRA c'est la spécialisation de structure régional voir le schema ici car une structure régionale peut avoir une caisse régie et peut ne pas l'avoir.


    a bientôt

  6. #26
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir bensam1,


    Citation Envoyé par bensam1
    on peut pas prendre en compte le chemin (a) car ce compte de charge spécial en relation avec domaine n'est pas en relation avec le compte analytique. il y a que b dans ce cas alors il n'y a pas une boucle piégeuse sinon pourquoi c'est une boucle piégeuse?
    Selon votre MCD, un compte de charge peut parfaitement être à la fois en relation avec un domaine (association Cc_affecter_dom) et en relation avec un compte analytique (association : Cc_Cc_affect_ca) :






    Le moins que vous puissiez faire est d’utiliser la convention de représentation de l’exclusion entre associations pour signifier qu’effectivement un compte de charge ne peut pas être à la fois en relation avec un domaine et un compte analytique :





    Cette convention est normalisée ainsi :





    Dans votre cas, le pivot de la contrainte est constitué de l’entité-type COMPTE_CHARGE et la portée est constituée de la paire d’associations {Cc_affecter_dom, Cc_Cc_affect_ca}.

    Cela dit, à cause de l’association 0,1 portée par la patte connectant l’entité-type COMPTE_CHARGE et l’association Cc_affecter_dom, la façon la plus saine de représenter les choses est d’en passer par la spécialisation comme je l’ai proposé dans le post #24.

    Je dis qu’il y a un piège parce que, comme je l’ai écrit, il y a une boucle, et donc en l’absence de la mise en oeuvre d’une contrainte ad-hoc, même si pour vous ça ne doit pas arriver, pour le SGBD rien n’interdit qu’un compte quel qu’il soit puisse à la fois être associé directement à un domaine D1, par exemple par le chemin :

    (a) Compte_charge > Cc_affect_ca > Cc_affectation_ca > Cc_affect_ca_dom > Ca_affectation_dom > Dom_affect > Domaine ;

    Et à un domaine D2 par le chemin :

    (b) Compte_charge > Cc_affecter_dom > Domaine.



    Citation Envoyé par bensam1
    Si on supposant le cas que le structure fait référence an un seul et un seul compte de charge qui en relation avec un compte analytique. Et dans ce cas il y a une propagation par l'identification relative de domaine et compte analytique et compte de charge sera au niveau de structure qui une situation n’est pas favorisée.
    Votre diagramme « 3e partie » est à l’image de celui qui figure dans le post #20, sinon que là où dans le post #20 on parle de structure, vous avez réduit à structure DRA. Considérez-vous le diagramme « 3e partie » comme bien valide ? Le remettez-vous en cause ? Quand vous écrivez qu’une structure fait référence à un seul et un seul compte de charge en relation avec un compte analytique, signifiez-vous qu’une structure DRA ne doit faire référence qu’à une seule paire {compte de charge, compte analytique} ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #27
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour


    Citation Envoyé par fsmrel Voir le message


    et donc en l’absence de la mise en oeuvre d’une contrainte ad-hoc
    ça veut dire quoi contrainte ad-hoc?



    Citation Envoyé par fsmrel Voir le message
    Considérez-vous le diagramme « 3e partie » comme bien valide ? Le remettez-vous en cause ?
    1. une structure DRA c'est une specialisation de structure régional parceque pas tout les structures régional ont une caisse regie donc pas tout les structure régional peut etablire une DRA C'est comme ca j'ai met la specialisation de structure régional en structure_DRA. S'il le schéma n'est pas valide a cause de cardinalité je vais le refaire avec cardinalité 1.1 sinon Ou n’est pas valide ? .
    2. cette structure est couvert par un et un seul domaine et un domaine peut couvrir une ou plusieurs structure même qui ont pas une caisse régie.
    3. une structure soit qui etablit une DRA ou non, et hierarchisé en plusieur niveaux et on a discuté sur l'hierarchie et je veux seulement sur cette point pourquoi vous préférer pas la modélisation en relation reflexive alors qu'il ya solution en mld pour eviter le clé etrangere nulle :
      Domaine (id_Dom, desi_dom, abrev_dom)
      hiérarchiser par (id_dom_fils#, id_Dom_parent#)

      Légende :
      x : relation
      x : clef primaire
      x# : clef étrangère

      et cette notation elle est proche de votre notation MLD

      là j'ai pas un clé étranger id_dom null, mais j'ai créer une relation a part hiérarchiser par qui contient les deux clés étrangères de id_dom..
    4. une DRA peut avoir une ou plusieur dépense. la DRA c'est achat ou prestation de service par caisse régie. et une dépense contient un et un seul couple {compte de charge , compte analytique} et pour exprimer ca je met une relation entre depense DRA et cc_affectation_ca.
    5. et je ajoute une dernière point une structure_DRA etablit une DRA selon un solde en caisse: avant d'etablire une DRA, le caissier ou l'agent doit toujours vérifier combien de solde en caisse et aussi il verifie le remboursement des DRA précédentes car une DRA est toujours remboursé et son remboursement est rajouté en caisse qui contient déjà le solde initial pour qu’ elle puisée établir la prochaine DRA. Si sa solde en caisse ne suffit pas la structure ne peut pas rétablir une DRA.
    6. Le solde se calcule comme ça:

      Solde final = solde initial + encaissement de remboursement des DRA précédente - le total des dépenses de cette DRA (décaissement).


      et Ainsi de suite


    voici le schema

    Nom : mcddra1.png
Affichages : 172
Taille : 37,2 Ko





    Citation Envoyé par fsmrel Voir le message
    Quand vous écrivez qu’une structure fait référence à un seul et un seul compte de charge en relation avec un compte analytique, signifiez-vous qu’une structure DRA ne doit faire référence qu’à une seule paire {compte de charge, compte analytique} ?
    La repense c'est oui c'est ca la signification.

  8. #28
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Dépenses DRA

    Bonsoir bensam1,


    Je suis désolé de répondre si tardivement, mais je cours dans tous les sens... Je vais faire passer votre discussion en priorité 1.



    Citation Envoyé par bensam1
    Ça veut dire quoi contrainte ad-hoc?
    Cela veut dire : contrainte adaptée au besoin d’empêcher que le compte de charge CC1 fasse à la fois référence aux domaines D1 et D2.



    Citation Envoyé par bensam1
    DRA c'est achat ou prestation de service.
    D’accord. Question quand même, de quoi "DRA" est-il l’acronyme (l’abréviation...) ?



    Dans votre dernier diagramme, les entités-types DRA et Depense_DRA sont connectée par une association Contenir :


    [DRA]--1,N------------(Contenir)------------1,N--[Depense_DRA]


    Pourquoi la patte connectant Depense_DRA et Contenir est-elle porteuse d’une cardinalité 1,N plutôt que 1,1 ? Les DRA pourraient donc être concernées par une même dépense ?


    A bientôt !
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #29
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour

    voici les repense :

    Citation Envoyé par fsmrel Voir le message


    D’accord. Question quand même, de quoi "DRA" est-il l’acronyme (l’abréviation...) ?
    DRA :Dépense Régie Accréditif

    Citation Envoyé par fsmrel Voir le message
    Bonsoir bensam1,

    Dans votre dernier diagramme, les entités-types DRA et Depense_DRA sont connectée par une association Contenir :




    [DRA]--1,N------------(Contenir)------------1,N--[Depense_DRA]


    Pourquoi la patte connectant Depense_DRA et Contenir est-elle porteuse d’une cardinalité 1,N plutôt que 1,1 ? Les DRA pourraient donc être concernées par une même dépense ?
    vous avez reaison pardon j'ai fait encore un erreur c'est 1.1 ou plutôt (1.1) et je vous explique pourquoi:

    Concernant l’entité DRA

    Une DRA est connu par les informations suivantes :
    1. N° DRA : qui contient 6 caractère les 3 premiers caractères présentent le code de structure dra et les 3 dernières présentent un numéro séquentiel de 3 chiffre démarré a 001 chaque nouvelle année.
    2. Nom de structure établissant la DRA.
    3. Période comptable (mm/aa)
    4. Date début de période et date fin de période.
    5. Structure qui effectue le remboursement soit finance central ou finance de chaque structure DRA.
    6. Montant total de dépenses (la somme des débits de toutes dépenses de cette DRA).
    7. Le solde initial et le solde final en caisse régie
    8. Remboursement des DRA précédentes s’il y a des DRA remboursé qui est rajouté au solde initial (j’ai parlé sur sujet de solde).
    Alors une DRA n’est identifié que par structure établissant cette DRA alors j’ai utilisé l’identification relative.

    Concernant dépenses DRA


    J’ai parlé si vous souvient qu’il existe deux comptes de charge : compte de charge général et compte de charge de caisse régie. Et il existe deux comptes analytiques : compte analytique générale et compte analytique de caisse régie. Une dépense DRA contient les informations qui illustré dans le table suivant :

    Nom : depense_dra_table.png
Affichages : 184
Taille : 65,8 Ko

    Voici les explications :
    1. N ° de la bon petite caisse c’est un numéro de document établit par chef de structure régional en instruisant ses agente d’Achter une fourniture ou demande d’un service il comporte la valeur de montant à utiliser pour pouvoir payer l’achat ou la prestation.
    2. Compte de charge c’est le compte de charge General jusqu’à la dernière dépense n-1 et sur la ligne n c’est le compte de charge de caisse régie d’une structure DRA établissant cette DRA.
    3. Les lignes 2,3 et n ne sont pas des dépenses mais il comporte des détails sur la facture comme le mont de TVA et mont du timbre fiscal pour les lignes 2 et 3 et pour la ligne n elle comporte des détails sur la DRA compte le compte de caisse régie de la structure.
    4. Toujours en dernier ligne dépenses de chaque DRA lorsque l’agent rempli tous les dépenses d’une DRA, il renseigne le compte de caisse régie avec le crédit. et le crédit c’est la somme des montants de chaque bon petite caisse.
    5. Une dépenses peut contenir une facture si le prix d’achat ou service > 6000 ou bon pour si le prix <6000. Et sur cette facture le fournisseur de fourniture ou le Prestataire pout être assujetti ou non à la TVA je veux dire là que ce n’est pas une règle que les informations de TVA se trouvant toujours sur les dépense DRA et ce n’est pas toujours dans les lignes 2 et 3 c’est Juste un exemple.
    6. Le compte analytique de chaque dépense contient 6 chiffres XXX XXX. Les 3 premier XXX présentent le compte analytique de caisse régie de structure établissant DRA et les dernier XXX présentent le compte analytique général.
    7. Le débit c’est le prix d’achat ou service il ne doit pas dépasse 20 000.
    8. Le crédit c’est la somme du montant de chaque bon petit caisse.
    9. L’identifiant fiscal, numéro d’article et si la TVA son des informations concernant la facture.

    Alors comme il y a l’information sur la caisse régie de structure DRA sur le compte analytique d’une dépense. Alors une dépense est aussi identifiée par la structure et j’ai aussi propagé la structure et domaine à la dépense DRA par l’identification relative.

    Nom : dra_mcd.png
Affichages : 178
Taille : 30,5 Ko

    Abientot

  10. #30
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Dépenses DRA

    Bonsoir bensam1,


    J’avoue ne pas avoir examiné en détail votre tableau très complet, mais j’ai très peu de temps, et il est possible que je ne comprenne pas tout.

    Quoi qu’il en soit, vous avez établi une association CONTENIR entre DEPENSE_DRA et CC_AFFECTATION_CA. Mais en procédant ainsi, rien n’interdit que la paire {compte analytique, compte de charge} à laquelle fait référence une dépense DRA ne soit pas référencée par la structure DRA à laquelle fait référence la DRA elle-même référencée par cette dépense (encore un problème de boucle, de chemin !)


    Je propose ceci :

    Etant donné que l’association CC_AFF_CA_STR sert à déterminer l’ensemble des paires {compte analytique, compte de charge} pour une structure régionale, on définit le sous-ensemble CC_AFF_CA_STR_DRA de ces paires qui sont pertinentes pour les structures DRA. Une dépense DRA fait alors nécessairement référence à ce sous-ensemble.

    MCD





    MLD (chaque table est débarrassée des attributs redondants, hérités de tous les côtés !)


    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #31
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    Bonjour
    Merci de votre proposition mais i y a des remarques :


    Citation Envoyé par fsmrel

    Quoi qu’il en soit, vous avez établi une association CONTENIR entre DEPENSE_DRA et CC_AFFECTATION_CA. Mais en procédant ainsi, rien n’interdit que la paire {compte analytique, compte de charge} à laquelle fait référence une dépense DRA ne soit pas référencée par la structure DRA à laquelle fait référence la DRA elle-même référencée par cette dépense (encore un problème de boucle, de chemin !)
    1. Si vous consultez la partie 3 de MCD DRA message #20 ici vous trouvez que CC_AFF_CA_STR est liée au structure DRA Pas la structure régional car j’ai modifié la conception et j’ai spécialisé structure régional en structure_DRA, c’est elle va occuper la mission de structure régional. Alors il n’y a pas un risque que la paire {compte analytique, compte de charge} à laquelle fait référence une dépense DRA ne soit pas référencée par la structure DRA à laquelle fait référence la DRA elle-même référencée par cette dépense (pas de problème de boucle, de chemin !)

    Citation Envoyé par fsmrel
    Je propose ceci :

    Etant donné que l’association CC_AFF_CA_STR sert à déterminer l’ensemble des paires {compte analytique, compte de charge} pour une structure régionale, on définit le sous-ensemble CC_AFF_CA_STR_DRA de ces paires qui sont pertinentes pour les structures DRA. Une dépense DRA fait alors nécessairement référence à ce sous-ensemble.
    2. Même si on mettre l’entité CC_AFF_CA_STR_DRA en relation avec dépenses DRA en va seulement propager que les compte de charge spécial qui font référence qu’au certain structure or que dépense_DRA doit être en relation avec tous les comptes de charge soit les spécial (en relation avec les qlq structure_dra ou les autre en relation avec les comptes analytique d’une façon standard a l’exception a ceux qui sont en relation avec les domaines qui sont apparu dans la dra dans des opérations spécial comme la tva…etc). Mais vous m’avez aidé sur le cas ou si les structures_dra fait references au un et un seul le compte de charge spécial qui en relation avec le compte analytique.

    Une question a posé: est-ce-que le MCD suivant fegure -1 est correct et quel est son MLD correspondant

    Nom : str_etablire solon solde_dra.png
Affichages : 154
Taille : 9,0 Ko

    figure -1

    le figure -2 est la conception compléte de DRA


    Nom : dra_mcd_full.png
Affichages : 159
Taille : 57,5 Ko



    Figuer -2

    a bientot

  12. #32
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Dépenses DRA : contrainte de chemin

    Bonsoir bensam1,


    Je réponds déjà à la 1re partie de votre message (la suite ne tardera pas).


    Citation Envoyé par bensam1
    J’ai modifié la conception et j’ai spécialisé structure régional en structure_DRA, c’est elle va occuper la mission de structure régional.
    D’accord.



    Citation Envoyé par bensam1
    Alors il n’y a pas un risque que la paire {compte analytique, compte de charge} à laquelle fait référence une dépense DRA ne soit pas référencée par la structure DRA à laquelle fait référence la DRA elle-même référencée par cette dépense (pas de problème de boucle, de chemin !)
    Hum... Examinons la partie concernée du MCD :





    Il y a deux chemins pour « naviguer » de DEPENSE_DRA vers STRUCTURE_DRA :

    (c1) DEPENSE_DRA > OPERATION_DRA > DRA > STRUCTURE_DRA

    (c2) DEPENSE_DRA > CC_AFFECTATION_CA > CC_AFF_CA_STR > STRUCTURE_DRA

    Il y a donc une boucle, avec les risques inhérents. Selon l’exemple ci-dessous, légalement il n’y a pas de problème à ce que par le chemin c1 on aboutisse à la structure s1 tandis que par le chemin c2 on aboutisse à la structure s2 :

    
    CC_AFFECTATION_CA
    
    id_domaine    id_ca    id_cc
    d1            ca1      cc1
    
    
     CC_AFF_CA_STR
    
    id_domaine    id_ca    id_cc    id_structure
    d1            ca1      cc1      s2
    
    
    STRUCTURE_DRA
    
    id_domaine    id_structure
    d1            s1
    d1            s2
    
    
    DRA
    
    id_domaine    id_structure    id_dra
    d1            s1              a1
    
    
    OPERATION_DRA
    
    id_domaine    id_structure    id_dra    id_operation
    d1            s1              a1        o1
    
    
    DEPENSE_DRA
    
    id_domaine    id_structure    id_dra    id_operation     id_ca    id_cc
    d1            s1              a1        o1               ca1      cc1
    
    

    Du point de vue du SGBD c’est légal, mais du point de vue de l’application c’est illégal... Pour que la structure atteinte (s1 dans l’exemple) soit strictement la même quel que soit le chemin :





    Il y a encore deux chemins pour « naviguer » de DEPENSE_DRA vers STRUCTURE_DRA :

    (c1) DEPENSE_DRA > OPERATION_DRA > DRA > STRUCTURE_DRA

    (c2) DEPENSE_DRA > CC_AFF_CA_STR > STRUCTURE_DRA

    Mais si l’on reprend à l’identique l’exemple précédent, il manque cette fois-ci le quadruplet <d1, ca1 c1, s1> référencé par DEPENSE_DRA :

    
    CC_AFFECTATION_CA
    
    id_domaine    id_ca    id_cc
    d1            ca1      cc1
    
    
    CC_AFF_CA_STR
    
    id_domaine    id_ca    id_cc    id_structure
    d1            ca1      cc1      s2
    
    
    STRUCTURE_DRA
    
    id_domaine    id_structure
    d1            s1
    d1            s2
    
    
    DRA
    
    id_domaine    id_structure    id_dra
    d1            s1              a1
    
    
    OPERATION_DRA
    
    id_domaine    id_structure    id_dra    id_operation
    d1            s1              a1        o1
    
    
    DEPENSE_DRA
    
    id_domaine    id_structure    id_dra    id_operation     id_ca    id_cc
    d1            s1              a1        o1               ca1      cc1
    
    

    Le quadruplet <d1, ca1 c1, s1> est absent de CC_AFF_CA_STR, mais le SGBD exige cette fois-ci sa présence à cause de l’intégrité référentielle : du coup le contrôle de la contrainte de chemin fonctionne.


    Je regarde la partie concernant le solde de la DRA.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  13. #33
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Solde de DRA

    Suite.


    Citation Envoyé par bensam1
    Est-ce-que le MCD suivant figure -1 est correct et quel est son MLD correspondant ?
    Les AGL réagissent différemment...

    Pour PowerAMC, l’association ETABLIR_SELON donne lieu à une table ETABLIR_SELON :

    ETABLIR_SELON {id_domaine, id_structure, id_dra, id_solde}

    Ayant pour clé le quadruplet {id_domaine, id_structure, id_dra, id_solde} : en réalité, du fait des cardinalité 1,1, il y a deux clés : {id_domaine, id_structure, id_dra} et {id_solde}.


    De son côté DB-MAIN refuse de créer la table ETABLIR_SELON...


    En fait, ce MCD se lit ainsi :


    Une structure participe N fois à l’association ETABLIR_SELON ;

    Une DRA participe au moins et plus une fois à l’association ;

    Un solde DRA participe au moins et plus une fois à l’association.


    Au niveau tabulaire, on pourrait très bien voir les choses ainsi (entre autres possibilités...) :


    
    STRUCTURE_DRA 
    
    id_domaine    id_structure
    d1            s1
    d2            s2
    
    
    DRA 
    
    id_domaine    id_structure    id_dra
    d1            s1              a1
    
    
    SOLDE_DRA 
    
    id_solde
    m1
    
    ETABLIR_SELON 
    
    id_domaine    id_structure    id_dra    id_solde    id_domaine2    id_structure2
    d1            s1              a1        m1          d2             s2
    
    
    Les attributs id_domaine, id_structure, id_dra sont la conséquence de la participation des tables STRUCTURE_DRA et DRA à l’association ETABLIR_SELON, tandis que les attributs id_domaine2 et id_structure2 sont la conséquence de la participation de SOLDE_DRA à cette association : manifestement il est nécessaire que id_domaine= id_domaine2 et id_structure= id_structure2.


    Bref, votre diagramme pose un problème pour la génération d’un MLD.

    Maintenant, un solde fait référence à une DRA et une seule, donc transitivement un solde fait référence à une structure et une seule : inutile de faire participer SOLDE_DRA à un lien quelconque avec STRUCTURE_DRA : la patte entre SOLDE_DRA et ETABLIR_SELON est à supprimer, il faut seulement établir une association entre SOLDE_DRA et DRA :


    [SOLDE_DRA]--(1,1)--------(AVOIR_SOLDE)--------1,1--[DRA]


    Cela dit, il y a une bijection entre SOLDE_DRA et DRA, en conséquence de quoi DRA devrait absorber SOLDE_DRA, ces deux entités-types ne devraient en faire qu'une.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #34
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour

    Citation Envoyé par fsmrel;

    Il y a deux chemins pour « naviguer » de DEPENSE_DRA vers STRUCTURE_DRA :

    (c1) DEPENSE_DRA > OPERATION_DRA > DRA > STRUCTURE_DRA

    (c2) DEPENSE_DRA > CC_AFFECTATION_CA > CC_AFF_CA_STR > STRUCTURE_DRA
    oui mais sur le chemin (c2) on peut s'arreter au niveau de CC_AFFECTATION_CA car même si la structure s1 est présente sur DEPENSE_DRA avec le compte de charge cc1 comme votre exemple indique:



    DEPENSE_DRA
    id_domaine id_structure id_dra id_operation id_ca id_cc
    d1 s1 a1 o1 ca1 cc1






    alors cc1 peut ne pas etre present en CC_AFF_CA_STR qui contient que le compte de charge spécial affecté au s2 sinon cc1 devrait être un compte de charge spécial et dans ce cas s1 devrait etre appartenire a CC_AFF_CA_STR comme s2. et ca ne viole pas les contrantes d'integrité réferentiels.


    CC_AFF_CA_STR
    id_domaine id_ca id_cc id_structure
    d1 ca1 cc1 s2
    d1 ca1 cc1 s1








    Citation Envoyé par fsmrel;

    Le quadruplet <d1, ca1 c1, s1> est absent de CC_AFF_CA_STR, mais le SGBD exige cette fois-ci sa présence à cause de l’intégrité référentielle : du coup le contrôle de la contrainte de chemin fonctionne.
    j'ai pas bien compris, [FONT=Verdana, sans-serif] en tout cas l'intégrité référentiel va exige que la présence des comptes de charges spécial avec s2 hors que DEPENSE_DRA peut contenire tout les comptes de charge en relation avec les comptes analytique y compris les comptes de charges spécial comme le comptes de frais de visite medical.

    [/FONT]par exemple si <d1, ca1 cc1, s1> est présent au CC_AFF_CA_STR alors cc1 est le compte de charge spéciale qui est compte de visite médical. par l'intégrité référentiel, une Dépense DRA doit toujours contenir {cc1 ca1} a cause de relation CC_AFF_CA_STR_DRA

    Citation Envoyé par fsmrel;


    Bref, votre diagramme pose un problème pour la génération d’un MLD.

    Maintenant, un solde fait référence à une DRA et une seule, donc transitivement un solde fait référence à une structure et une seule : inutile de faire participer SOLDE_DRA à un lien quelconque avec STRUCTURE_DRA : la patte entre SOLDE_DRA et ETABLIR_SELON est à supprimer, il faut seulement établir une association entre SOLDE_DRA et DRA :
    [SOLDE_DRA]--(1,1)--------(AVOIR_SOLDE)--------1,1--[DRA]


    Cela dit, il y a une bijection entre SOLDE_DRA et DRA, en conséquence de quoi DRA devrait absorber SOLDE_DRA, ces deux entités-types ne devraient en faire qu'une.
    c'est vrais et en faisant le MCD de message #27 j'ai arrivé a la même résultat au niveau de MLD

    Nom : mcd_dra_sold1.png
Affichages : 125
Taille : 13,6 Ko

    et cela que je veux éviter car je veux historier le solde : le solde finale devient automatiquement le solde initial de la prochaines DRA comme j'ai expliqué dans la message #27 c'est pour ca j'ai préferé d'etablire une entité SOLDE Est ce vous avez une proposition pour ca?

  15. #35
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut Contrainte de chemin, encore !

    Bonsoir bensam1,


    Citation Envoyé par fsmrel
    Le quadruplet <d1, ca1 c1, s1> est absent de CC_AFF_CA_STR, mais le SGBD exige cette fois-ci sa présence à cause de l’intégrité référentielle : du coup le contrôle de la contrainte de chemin fonctionne.
    Ma phrase est incomplète, il faut lire :

    Le quadruplet <d1, ca1 c1, s1> est absent de CC_AFF_CA_STR, mais du fait de la mise en oeuvre de CC_AFF_CA_STR_DRA, le SGBD exige cette fois-ci la présence du quadruplet à cause de l’intégrité référentielle : du coup le contrôle de la contrainte de chemin fonctionne.

    En l’absence de CC_AFF_CA_STR_DRA, c'est-à-dire si on utilise votre MCD, le quadruplet <d1, ca1 c1, s1> peut être absent à tort de CC_AFF_CA_STR :





    Légalement il n’y a pas de problème à ce que par le chemin (c1) on aboutisse à la structure s1 tandis que par le chemin (c2) on aboutisse à la structure s2 :

    
    CC_AFFECTATION_CA
    
    id_domaine    id_ca    id_cc
    d1            ca1      cc1
    
    
     CC_AFF_CA_STR
    
    id_domaine    id_ca    id_cc    id_structure
    d1            ca1      cc1      s2
    
    
    STRUCTURE_DRA
    
    id_domaine    id_structure
    d1            s1
    d1            s2
    
    
    DRA
    
    id_domaine    id_structure    id_dra
    d1            s1              a1
    
    
    OPERATION_DRA
    
    id_domaine    id_structure    id_dra    id_operation
    d1            s1              a1        o1
    
    
    DEPENSE_DRA
    
    id_domaine    id_structure    id_dra    id_operation     id_ca    id_cc
    d1            s1              a1        o1               ca1      cc1
    
    

    Ainsi, par le chemin (c1) DEPENSE_DRA > OPERATION_DRA > DRA > STRUCTURE_DRA, pour la dépense DRA <d1, a1, o1, s1> on atteint la structure DRA s1, tandis que par le chemin (c2) DEPENSE_DRA > CC_AFFECTATION_CA > CC_AFF_CA_STR > STRUCTURE_DRA, on atteint la structure DRA s2.

    Conclusion : la contrainte de chemin n’est pas garantie, aussi est-il nécessaire de remplacer l’association CONTENIR connectant DEPENSE_DRA et CC_AFFECTATION_CA, par l’association CC_AFF_CA_STR_DRA connectant DEPENSE_DRA et CC_AFF_CA_STR.

    Si on conserve l’association CONTENIR, la structure tabulaire est la suivante :

    
    CREATE TABLE DOMAINE 
    (
       Id_domaine           INT NOT NULL,
       code_domaine         VARCHAR(64) NOT NULL,
       CONSTRAINT DOMAINE_PK PRIMARY KEY (Id_domaine),
       CONSTRAINT DOMAINE_AK UNIQUE (code_domaine)
    ) ;
    
    CREATE TABLE COMPTE_ANALYTIQUE 
    (
       Id_domaine           INT NOT NULL,
       Id_compte_analytique INT NOT NULL,
       Compte_analytique    CHAR(16) NOT NULL,
       CONSTRAINT COMPTE_ANALYTIQUE_PK PRIMARY KEY (Id_domaine, Id_compte_analytique),
       CONSTRAINT COMPTE_ANALYTIQUE_AK UNIQUE (Compte_analytique),
       CONSTRAINT COMPTE_ANALYTIQUE_DOMAINE_FK FOREIGN KEY (Id_domaine)
          REFERENCES DOMAINE (Id_domaine)
    ) ;
    
    CREATE TABLE COMPTE_CHARGE 
    (
       Id_compte_charge     INT NOT NULL,
       Compte_charge        CHAR(10) NOT NULL,
       CONSTRAINT COMPTE_CHARGE_PK PRIMARY KEY (Id_compte_charge),
       CONSTRAINT COMPTE_CHARGE_AK UNIQUE (Compte_charge)
    ) ;
    
    CREATE TABLE COMPTE_CHARGE_AVEC_CA 
    (
       Id_compte_charge     INT NOT NULL,
       CONSTRAINT COMPTE_CHARGE_AVEC_CA_PK PRIMARY KEY (Id_compte_charge),
       CONSTRAINT COMPTE_CHARGE_AVEC_CA_COMPTE_CHARGE_FK FOREIGN KEY (Id_compte_charge)
          REFERENCES COMPTE_CHARGE (Id_compte_charge)
    ) ;
    
    CREATE TABLE CC_AFFECTATION_CA 
    (
       Id_domaine           INT NOT NULL,
       Id_compte_analytique INT NOT NULL,
       Id_compte_charge     INT NOT NULL,
       CONSTRAINT CC_AFFECTATION_CA_PK PRIMARY KEY (Id_domaine, Id_compte_analytique, Id_compte_charge),
       CONSTRAINT CC_AFFECTATION_CA_COMPTE_ANALYTIQUE_FK FOREIGN KEY (Id_domaine, Id_compte_analytique)
          REFERENCES COMPTE_ANALYTIQUE (Id_domaine, Id_compte_analytique),
       CONSTRAINT CC_AFFECTATION_CA_COMPTE_CHARGE_AVEC_CA_FK FOREIGN KEY (Id_compte_charge)
          REFERENCES COMPTE_CHARGE_AVEC_CA (Id_compte_charge)
    ) ;
    
    CREATE TABLE STRUCTURE_REGIONALE 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       code_structure       VARCHAR(64) NOT NULL,
       CONSTRAINT STRUCTURE_REGIONALE_PK PRIMARY KEY (Id_domaine, id_structure),
       CONSTRAINT STRUCTURE_REGIONALE_AK UNIQUE (code_structure),
       CONSTRAINT STRUCTURE_REGIONALE_DOMAINE_FK FOREIGN KEY (Id_domaine)
          REFERENCES DOMAINE (Id_domaine)
    ) ;
    
    CREATE TABLE STRUCTURE_DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       CONSTRAINT STRUCTURE_DRA_PK PRIMARY KEY (Id_domaine, id_structure),
       CONSTRAINT STRUCTURE_DRA_STRUCTURE_REGIONALE_FK FOREIGN KEY (Id_domaine, id_structure)
          REFERENCES STRUCTURE_REGIONALE (Id_domaine, id_structure)
    ) ;
    
    CREATE TABLE CC_AFF_CA_STR 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       Id_compte_analytique INT NOT NULL,
       Id_compte_charge     INT NOT NULL,
       CONSTRAINT CC_AFF_CA_STR_PK PRIMARY KEY (Id_domaine, id_structure, Id_compte_analytique, Id_compte_charge),
       CONSTRAINT CC_AFF_CA_STR_STRUCTURE_DRA_FK FOREIGN KEY (Id_domaine, id_structure)
          REFERENCES STRUCTURE_DRA (Id_domaine, id_structure),
       CONSTRAINT CC_AFF_CA_STR_CC_AFFECTATION_CA_FK FOREIGN KEY (Id_domaine, Id_compte_analytique, Id_compte_charge)
          REFERENCES CC_AFFECTATION_CA (Id_domaine, Id_compte_analytique, Id_compte_charge)
    ) ;
    
    CREATE TABLE COMPTE_CHARGE_SANS_CA 
    (
       Id_compte_charge     INT NOT NULL,
       Id_domaine           INT NOT NULL,
       CONSTRAINT COMPTE_CHARGE_SANS_CA_PK PRIMARY KEY (Id_compte_charge),
       CONSTRAINT COMPTE_CHARGE_SANS_CA_DOMAINE_FK FOREIGN KEY (Id_domaine)
          REFERENCES DOMAINE (Id_domaine),
       CONSTRAINT COMPTE_CHARGE_SANS_CA_COMPTE_CHARGE_FK FOREIGN KEY (Id_compte_charge)
          REFERENCES COMPTE_CHARGE (Id_compte_charge)
    ) ;
    
    CREATE TABLE DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       id_dra               INT NOT NULL,
       CONSTRAINT DRA_PK PRIMARY KEY (Id_domaine, id_structure, id_dra),
       CONSTRAINT DRA_STRUCTURE_DRA_FK FOREIGN KEY (Id_domaine, id_structure)
          REFERENCES STRUCTURE_DRA (Id_domaine, id_structure)
    ) ;
    
    CREATE TABLE OPERATION_DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       id_dra               INT NOT NULL,
       id_operation         INT NOT NULL,
       CONSTRAINT OPERATION_DRA_PK PRIMARY KEY (Id_domaine, id_structure, id_dra, id_operation),
       CONSTRAINT OPERATION_DRA_DRA_FK FOREIGN KEY (Id_domaine, id_structure, id_dra)
          REFERENCES DRA (Id_domaine, id_structure, id_dra)
    ) ;
    
    CREATE TABLE DEPENSE_DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       id_dra               INT NOT NULL,
       id_operation         INT NOT NULL,
       Id_compte_analytique INT NOT NULL,
       Id_compte_charge     INT NOT NULL,
       CONSTRAINT DEPENSE_DRA_PK PRIMARY KEY (Id_domaine, id_structure, id_dra, id_operation),
       CONSTRAINT DEPENSE_DRA_CC_AFFECTATION_CA_FK FOREIGN KEY (Id_domaine, Id_compte_analytique, Id_compte_charge)
          REFERENCES CC_AFFECTATION_CA (Id_domaine, Id_compte_analytique, Id_compte_charge),
       CONSTRAINT DEPENSE_DRA_OPERATION_DRA_FK FOREIGN KEY (Id_domaine, id_structure, id_dra, id_operation)
          REFERENCES OPERATION_DRA (Id_domaine, id_structure, id_dra, id_operation)
    ) ;
    
    CREATE TABLE OPER_SPEC_DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       id_dra               INT NOT NULL,
       id_operation         INT NOT NULL,
       CONSTRAINT OPER_SPEC_DRA_PK PRIMARY KEY (Id_domaine, id_structure, id_dra, id_operation),
       CONSTRAINT OPER_SPEC_DRA_OPERATION_DRA_FK FOREIGN KEY (Id_domaine, id_structure, id_dra, id_operation)
          REFERENCES OPERATION_DRA (Id_domaine, id_structure, id_dra, id_operation)
    ) ;
    
    

    Un début de jeu d’essai :

    
    INSERT INTO DOMAINE (Id_domaine, code_domaine) VALUES (1, 'd1') ;
    
    INSERT INTO COMPTE_ANALYTIQUE (Id_domaine, Id_compte_analytique, Compte_analytique) VALUES (1, 1, 'ca1') ;
    
    INSERT INTO COMPTE_CHARGE (Id_compte_charge, Compte_charge) VALUES (1, 'cc1') ;
    
    INSERT INTO COMPTE_CHARGE_AVEC_CA (Id_compte_charge) VALUES (1) ;
    
    INSERT INTO CC_AFFECTATION_CA (Id_domaine, Id_compte_analytique, Id_compte_charge) VALUES (1, 1, 1) ;
    
    INSERT INTO STRUCTURE_REGIONALE (Id_domaine, id_structure, code_structure) VALUES (1, 1, 's1'), (1, 2, 's2') ;
    
    INSERT INTO STRUCTURE_DRA (Id_domaine, id_structure) VALUES (1, 1), (1, 2) ;
    
    INSERT INTO CC_AFF_CA_STR (Id_domaine, id_structure, Id_compte_analytique, Id_compte_charge) VALUES (1, 2, 1, 1) ;
    
    INSERT INTO DRA (Id_domaine, id_structure, id_dra) VALUES (1, 1, 1) ;
    
    INSERT INTO OPERATION_DRA (Id_domaine, id_structure, id_dra, id_operation) VALUES (1, 1, 1, 1) ;
    
    INSERT INTO DEPENSE_DRA (Id_domaine, id_structure, id_dra, id_operation, Id_compte_analytique, Id_compte_charge) VALUES (1, 1, 1, 1, 1, 1) ;
    
    

    Quel est le nom de la structure pour chaque dépense DRA du domaine d1, pour le compte analytique ca1 et le compte de charge cc1 ?

    
    SELECT code_structure
    FROM   DEPENSE_DRA AS x JOIN CC_AFF_CA_STR AS y ON x.Id_domaine = y.Id_domaine AND x.id_structure = y.id_structure 
                                                    AND x.Id_compte_analytique = y.Id_compte_analytique
                                                    AND x.Id_compte_charge = y.Id_compte_charge   
                            JOIN STRUCTURE_REGIONALE AS z ON y.Id_domaine = z.Id_domaine AND y.id_structure = z.id_structure
    WHERE  x.Id_domaine = 1 AND x.Id_compte_analytique = 1 AND x.Id_compte_charge = 1 
    ; 
    
    Le résultat est vide, mais aucune erreur n’est signalée.


    Si pour la table DEPENSE_DRA on remplace l’association CONTENIR par l’association CC_AFF_CA_STR_DRA, cette fois-ci le SGBD déclenchera une erreur d’intégrité référentielle, au motif que le quadruplet <d1, s1, ca1, cc1> est absent de la table de référence CC_AFF_CA_STR :

    
    CREATE TABLE DEPENSE_DRA 
    (
       Id_domaine           INT NOT NULL,
       id_structure         INT NOT NULL,
       id_dra               INT NOT NULL,
       id_operation         INT NOT NULL,
       Id_compte_analytique INT NOT NULL,
       Id_compte_charge     INT NOT NULL,
       CONSTRAINT DEPENSE_DRA_PK PRIMARY KEY (Id_domaine, id_structure, id_dra, id_operation),
       CONSTRAINT DEPENSE_DRA_CC_AFFECTATION_CA_FK FOREIGN KEY (Id_domaine, Id_compte_analytique, Id_compte_charge)
          REFERENCES CC_AFFECTATION_CA (Id_domaine, Id_compte_analytique, Id_compte_charge),
       CONSTRAINT DEPENSE_DRA_OPERATION_DRA_FK FOREIGN KEY (Id_domaine, id_structure, id_dra, id_operation)
          REFERENCES OPERATION_DRA (Id_domaine, id_structure, id_dra, id_operation)
    ) ;
    
    
    Le SELECT => Boum !



    Citation Envoyé par bensam1
    Par exemple si <d1, ca1 cc1, s1> est présent au CC_AFF_CA_STR alors cc1 est le compte de charge spéciale qui est compte de visite médical. par l'intégrité référentiel, une Dépense DRA doit toujours contenir {cc1 ca1} a cause de la relation CC_AFF_CA_STR_DRA.
    L’association CC_AFF_CA_STR_DRA, connectant DEPENSE_DRA et CC_AFF_CA_STR, est bien là pour garantir la contrainte de chemin, et éviter le fâcheux résultat précédent, provoqué par l’association de DEPENSE_DRA directement avec CC_AFFECTATION_CA (via CONTENIR), faisant que dans ce cas-là aucune erreur n’est signalée, hélas !



    Citation Envoyé par bensam1
    et cela que je veux éviter car je veux historier le solde
    Qui dit historiser, dit prévoir la date dans la liste des attributs de la DRA. Cela dit, à quoi correspondent les attributs figurant dans l’association ETABLIR_SELON ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  16. #36
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour
    merci de votre patience et votre explication mais je ne sais pas est ce que vous m'avais compris ou non


    Citation Envoyé par fsmrel Voir le message


    Légalement il n’y a pas de problème à ce que par le chemin (c1) on aboutisse à la structure s1 tandis que par le chemin (c2) on aboutisse à la structure s2 :

    
    CC_AFFECTATION_CA
    
    id_domaine    id_ca    id_cc
    d1            ca1      cc1
    
    
     CC_AFF_CA_STR
    
    id_domaine    id_ca    id_cc    id_structure
    d1            ca1      cc1      s2
    
    
    STRUCTURE_DRA
    
    id_domaine    id_structure
    d1            s1
    d1            s2
    
    
    DRA
    
    id_domaine    id_structure    id_dra
    d1            s1              a1
    
    
    OPERATION_DRA
    
    id_domaine    id_structure    id_dra    id_operation
    d1            s1              a1        o1
    
    
    DEPENSE_DRA
    
    id_domaine    id_structure    id_dra    id_operation     id_ca    id_cc
    d1            s1              a1        o1               ca1      cc1
    
    

    Ainsi, par le chemin (c1) DEPENSE_DRA > OPERATION_DRA > DRA > STRUCTURE_DRA, pour la dépense DRA <d1, a1, o1, s1> on atteint la structure DRA s1, tandis que par le chemin (c2) DEPENSE_DRA > CC_AFFECTATION_CA > CC_AFF_CA_STR > STRUCTURE_DRA, on atteint la structure DRA s2.

    Conclusion : la contrainte de chemin n’est pas garantie, aussi est-il nécessaire de remplacer l’association CONTENIR connectant DEPENSE_DRA et CC_AFFECTATION_CA, par l’association CC_AFF_CA_STR_DRA connectant DEPENSE_DRA et CC_AFF_CA_STR.
    le cas que vous parlez au dessus n'existe pas car:

    1. même s’il y a que s2 dans la table CC_AFF_CA_STR, s2 doit etre présente en dépense DRA. car cette depense va contenir un compte de charge spécial cc1 qui n'est affecté qu'a certain structure comme s2 ca veut dire il y a que certaint structure comme s2 peuvent etablire une DRA contenant des depenses avec cc1 et on a discuté sur les compte de charge spécial dans les message #12,#13,#14. jusqu'a #19

    Citation Envoyé par fsmrel Voir le message

    En l’absence de CC_AFF_CA_STR_DRA, c'est-à-dire si on utilise votre MCD, le quadruplet <d1, ca1 c1, s1> peut être absent à tort de CC_AFF_CA_STR :
    2.s1 s'il n'existe pas dans la table CC_AFF_CA_STR alors il ne doit pas etre affecté a cc1 ca veut dire si {s1, cc1} est presente dans DEPENSE_DRA alors il doit pas etre presente dans la table CC_AFF_CA_STR alors <d1, ca1 cc1, s1> ne doit pas être présente dans la table CC_AFF_CA_STR si s1 n'est pas affecté au {cc1, ca1} sur CC_AFF_CA_STR , le chemin c2 peut s’arrêter au niveau de CC_AFFECTATION_CA


    Envoyé par bensam1

    Par exemple si <d1, ca1 cc1, s1> est présent au CC_AFF_CA_STR alors cc1 est le compte de charge spéciale qui est compte de visite médical. par l'intégrité référentiel, une Dépense DRA doit toujours contenir {cc1 ca1} a cause de la relation CC_AFF_CA_STR_DRA.




    3.la depense DRA doit contenire tout les compte de charge en relation avec compte analytique pas seulement les compte de charge spécial en relation avec les compte analytique et si j'ai établi cette relation CC_AFF_CA_STR_DRA, la depense DRA va contenir que les compte de charges spécial en relation avec les compte analytique qui sont dans la table CC_AFF_CA_STR.

    Citation Envoyé par fsmrel Voir le message
    Quel est le nom de la structure pour chaque dépense DRA du domaine d1, pour le compte analytique ca1 et le compte de charge cc1 ?

    
    SELECT code_structure
    FROM   DEPENSE_DRA AS x JOIN CC_AFF_CA_STR AS y ON x.Id_domaine = y.Id_domaine AND x.id_structure = y.id_structure 
                                                    AND x.Id_compte_analytique = y.Id_compte_analytique
                                                    AND x.Id_compte_charge = y.Id_compte_charge   
                            JOIN STRUCTURE_REGIONALE AS z ON y.Id_domaine = z.Id_domaine AND y.id_structure = z.id_structure
    WHERE  x.Id_domaine = 1 AND x.Id_compte_analytique = 1 AND x.Id_compte_charge = 1 
    ; 
    
    Le résultat est vide, mais aucune erreur n’est signalée.
    le resultat c'est s2 sinon ca doit être vide


    Citation Envoyé par fsmrel Voir le message
    Qui dit historiser, dit prévoir la date dans la liste des attributs de la DRA. Cela dit, à quoi correspondent les attributs figurant dans l’association ETABLIR_SELON ?
    oui vous a avez raison mais je veux ajouter la date dans la liste des attributs de l'entité solde. je veux mettre l'antité solde en relation avec l'entité espéce. ca veut dire que le solde est pésenté en espece (billets et ses valeures, les pieces de monnais et ses valeures).

    les attributs figurant dans l’association ETABLIR_SELON sont les clés etrangers des chacun de entites DRA, structure_DRA et solde.

    n'esitez pas a posé des question si j'arrive pas a bien expliqué.

    abientot

  17. #37
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir bensam1,


    J’ai dû m’absenter durant quelques jours, mais je ne vous oublie pas.


    Citation Envoyé par bensam1
    le cas que vous parlez au dessus n'existe pas
    Selon les règles de gestion des données énoncées dans le dossier de l’application je n’en doute pas, mais, à moins de programmer des triggers et autres contraintes lourdes, mais si on conserve l’association CONTENIR connectant DEPENSE_DRA et CC_AFFECTATION_CA, au stade SQL ces règles sont absentes de la base de données, et du point de vue du SGBD, la situation que j’ai décrite dans mon message précédent est parfaitement légale. Il suffit d’un petit loupé dans votre propre programmation (par exemple à l’occasion d’une opération de maintenance) pour que les bugs s’installent. J’ai eu à opérer des audits des bases de données dans des banques, des assurances et autres entreprises pour débusquer l’injection au fil du temps d’anomalies pouvant concerner jusqu’à 30% des données, alors que selon les DSI, ça ne pouvait pas dépasser 1%...

    Bref, je persiste : l’association CC_AFF_CA_STR_DRA est un gilet pare-bugs rassurant.


    A propos des soldes :

    L’attribut tot_dra de l’entité-type DRA représente le montant de la dépense ?

    L’entité-type DRA doit être dotée d’un attribut correspondant à la date de la dra.

    Concernant l’association ETABLIR_SELON :

    Quel est le type de l’attribut cheq_remb ? Est-ce un booléen ? Un montant ? Autre chose ? Quelle relation avec l’attribut tot_dra de l’entité-type DRA ? La valeur de l’attribut cheq_remb correspond-elle à une seule dépense ? si oui, l’attribut cheq_remb est à faire figurer dans l’entité-type DRA.

    Mêmes questions et remarques concernant l’attribut cheq_augm.

    Pourquoi un attribut remb_dra_prec ? Sa valeur doit être égale à la valeur de quel attribut de l’entité-type DRA (occurrence précédente) ?

    Par ailleurs, les attributs sold_init et sold_final sont propres à une structure DRA, ils n’ont donc pas à figurer dans l’association ETABLIR_SELON, mais dans l’entité-type STRUCTURE_DRA ou dans une entité-type SOLDE dépendant directement de celle-ci si vous voulez suivre les soldes dans le temps, donc gérer un historique. Par ailleurs, pour une structure, cet historique peut être produit à partir de l’ensemble des DRA de cette structure et d’un solde affecté à la structure avant sa 1re dépense : l’entité-type SOLDE ne correspondrait alors qu’à une optimisation technique.


    Pour les espèces, en principe c’est au niveau de la DRA que ça se passe :

    [DRA]--1,N-----------(DRA_ESPECE {montant})--------0,N--[TYPE_ESPECE]

    Ou, s’il n’y a que deux types d’espèces :

    DRA {id_dra, date_dra, montant_en_billets, montant_en_pieces, ...}
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  18. #38
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour et bonne reprise

    Citation Envoyé par fsmrel Voir le message
    Selon les règles de gestion des données énoncées dans le dossier de l’application je n’en doute pas, mais, à moins de programmer des triggers et autres contraintes lourdes, mais si on conserve l’association CONTENIR connectant DEPENSE_DRA et CC_AFFECTATION_CA, au stade SQL ces règles sont absentes de la base de données, et du point de vue du SGBD, la situation que j’ai décrite dans mon message précédent est parfaitement légale. Il suffit d’un petit loupé dans votre propre programmation (par exemple à l’occasion d’une opération de maintenance) pour que les bugs s’installent. J’ai eu à opérer des audits des bases de données dans des banques, des assurances et autres entreprises pour débusquer l’injection au fil du temps d’anomalies pouvant concerner jusqu’à 30% des données, alors que selon les DSI, ça ne pouvait pas dépasser 1%...

    Bref, je persiste : l’association CC_AFF_CA_STR_DRA est un gilet pare-bugs rassurant.
    en tout les cas je ne peux pas établir cette association. car si je lui établira les dépenses DRA va seulement contenir le compte de charges de médecine de travail or que la dépense doit faire référence a tout les comptes de charge en relation avec les comptes analytiques.

    Citation Envoyé par fsmrel Voir le message
    A propos des soldes :

    L’attribut tot_dra de l’entité-type DRA représente le montant de la dépense ?
    le tot_dra représente la somme des montants de chaque dépense de cette DRA.

    Citation Envoyé par fsmrel Voir le message
    L’entité-type DRA doit être dotée d’un attribut correspondant à la date de la dra.
    oui vous avez raison

    Citation Envoyé par fsmrel Voir le message
    Concernant l’association ETABLIR_SELON :
    Quel est le type de l’attribut cheq_remb ? Est-ce un booléen ? Un montant ? Autre chose ? Quelle relation avec l’attribut tot_dra de l’entité-type DRA ? La valeur de l’attribut cheq_remb correspond-elle à une seule dépense ? si oui, l’attribut cheq_remb est à faire figurer dans l’entité-type DRA.

    Mêmes questions et remarques concernant l’attribut cheq_augm.

    Pourquoi un attribut remb_dra_prec ? Sa valeur doit être égale à la valeur de quel attribut de l’entité-type DRA (occurrence précédente) ?
    l'attribut cheq_remb c'est le n° de chèque de remboursement d'une DRA je prefere qu'il soit chaine de caracteres. et celui de montant de remboursement de DRA qui represente l'attribut remb_dra_prec. la valeur de montant de remboursement DRA est égale a la valeur de montant de total de ses dépenses tot_dra. le montant de remboursement d'une DRA est designé lors d'établissement de DRA qui suite celle ci.

    par exemple: la DRA de numéro 001 avec un total dépense 10000 a été etablit le 14/01/2016 est elle est remboursé le la date 20/01/2016. le montant de remboursement est de valeur 10000 et il serait désigné en DRA 002 et il y a des cas ou le remboursement de DRA 001 est désigné en DRA 003 et peut être qui se suit je veut dir que le remboursement d'une DRA n'est obligatoirement désigné dans la DRA qui se suit directement il peut être désigné ultérieurement dans les prochaines DRA.

    pour le cheq_augm c'est le n° de chèque de l'augmentation: une augmentation c'est un montant additionnel qui est ajouté dans la caisse regié de la structure alors ca valeur est additionnée a la valeur de solde en caisse.
    une augmentation est caractérisée par:
    augment: qui est montant d'augmentation ,
    cheq_augm: n° Chèque de l'augmentation,
    num_deci : N° de décision d'ajouter cette augmentation


    Citation Envoyé par fsmrel Voir le message
    Par ailleurs, les attributs sold_init et sold_final sont propres à une structure DRA, ils n’ont donc pas à figurer dans l’association ETABLIR_SELON, mais dans l’entité-type STRUCTURE_DRA ou dans une entité-type SOLDE dépendant directement de celle-ci si vous voulez suivre les soldes dans le temps, donc gérer un historique. Par ailleurs, pour une structure, cet historique peut être produit à partir de l’ensemble des DRA de cette structure et d’un solde affecté à la structure avant sa 1re dépense : l’entité-type SOLDE ne correspondrait alors qu’à une optimisation technique.
    Voulez vous dire solde est associé au structure et que je dois établir une association entre l'entité sold et entité structure_dra et non plus entre solde et DRA?

    Citation Envoyé par fsmrel Voir le message
    Pour les espèces, en principe c’est au niveau de la DRA que ça se passe :

    [DRA]--1,N-----------(DRA_ESPECE {montant})--------0,N--[TYPE_ESPECE]

    Ou, s’il n’y a que deux types d’espèces :

    DRA {id_dra, date_dra, montant_en_billets, montant_en_pieces, ...}
    pourquoi l'espace c'est au niveau de l'entité DRA? C'est quoi DRA_ESPECE C'est quel montant ? le montant de billets et le montant de pièce représentent elles les type de l'espèce? Si oui elle doit existe en TYPE_ESPECE et en DRA_ESPECE

    DRA_ESPECE {id_dra, montant_en_billets, montant_en_pieces} n'est ce pas?

    Et en plus, si l'entité solde est établit on peut associer le solde a l'espèce. car chaque fin trimestre le solde en caisse en caisse, doit être représenté en billets et en pièces. je ne sait comment appeler cette représentation moi j'ai l'appeler espèce. excusez moi si j'ai vous trompé.

    abientot

  19. #39
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    bonjour ravit de vous rencontrer cette occasion encore

    après que j'ai montré ma conception que vous avez m'aidé pour la faire (je vous remercié infiniment. vous m'avez donné un grand aide, j'ai appris beaucoup de votre expérience), mes chef m'ont ordonné d'éliminer l'entité domaine car:

    le compte analytique: certain compte analytique sont utilisé pour tout les structure alors que certain ne sont utilisé que par certain structure par exemple:

    le compte analytique catm n'est utilisé que les structure département technique et maintenance.
    les comptes de charge qui sont en relation avec ce compte analytique peuvent être utilisé pour tout les structure

    le compte de charge sont généralement utilisé pour tout les structure mais il y a des compte de charge qui sont utilisé uniquement pour certain structure par exemple:
    le compte de charge médecine de travaille cfvm est n'est utilisé pour certaine structure alors qu'il est affecté a une compte analytique qui est utilisé par tout les structure

    Nom : mcd_dra_am.png
Affichages : 56
Taille : 30,4 Ko

    que pensez vous? avez vous des propositions mieux que ca?

  20. #40
    Membre à l'essai
    Inscrit en
    juillet 2012
    Messages
    52
    Détails du profil
    Informations forums :
    Inscription : juillet 2012
    Messages : 52
    Points : 22
    Points
    22

    Par défaut

    il y a aussi une point:

    lorsque l'utilisateur remplier une dépense dans une DRA, il indique le nom de fournisseur, numéro de facture si il y a une facture, et il indique qu'il est assujetti ou non a la TVA.
    Si le fournisseur est assujetti a la TVA, l'utilisateur indique juste en dessous de la dépense concerné:
    1. le compte TVA dans la case ou est renseigné le compte charge.
    2. le mentant TVA dans le case ou est renseigné le débit.

    et juste en dessous de la ligne TVA, l'utilisateur indique :
    1. le compte timbre dans la case ou est renseigné le compte charge.
    2. le mentant timbre dans le case ou est renseigné le débit.


    comment modélise l'entité Dépense DRA en MCD de telle sort les information concernant la TVA et timbre soient enregistré en base de données?

    A bientot

Discussions similaires

  1. Boucle fermée en mcd
    Par jamyong dans le forum Merise
    Réponses: 13
    Dernier message: 04/07/2014, 02h44
  2. MCD et boucle fermée
    Par gwadaboug dans le forum Schéma
    Réponses: 9
    Dernier message: 09/01/2012, 03h08
  3. [MCD] Boucle fermée dans le MCD.
    Par skatah dans le forum Schéma
    Réponses: 10
    Dernier message: 25/08/2010, 09h20
  4. [FLASH 8] boucle fonction sur bouton
    Par bractar dans le forum Flash
    Réponses: 2
    Dernier message: 31/01/2006, 18h34
  5. [Eval] Problème de boucle for sur des tableaux
    Par battle_benny dans le forum JavaScript
    Réponses: 3
    Dernier message: 12/01/2006, 23h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo