Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Discussion: gestion de dossiers

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut gestion de dossiers

    Bonjour,

    Il faut bien qu'à un moment donné je me jette à l'eau (la chute risque d'être assez violente, mais je n'ai plus le choix).

    Mon défi consiste à réaliser une base de donnée relative à l'instruction administrative de dossiers nommés "dia".

    voici mes règles de gestion:
    1) les 1eres informations relatives aux dia sont saisies (cf dans l'entité 'saisie dia') de l'attribut "num_dia" à l'attribut "superficie bien en m²".
    Les autres infos en lien avec l'instruction sont saisies par la suite.

    2) Les suites données à une Dia sont:

    soit :
    -elle fait l’objet d’une analyse simple qui débouche
    #sur une réponse défavorable
    ou bien
    # la conduite d’une ou plusieurs analyses plus poussées qui débouche(nt) sur :
    - plusieurs réponses défavorables
    - une réponse favorable;
    #elle peut être retournée car non soumise (cela a pour effet de stopper l’analyse du dossier).
    #elle peut être annulée (cela a pour effet de stopper l’analyse du dossier).

    3) l’analyse simple
    -chaque Dia est liée à une commune (dite concernée).
    -chaque commune est affectée à un ou plusieurs agents.
    -les affectations évoluent dans le temps.

    4) les communes concernées:
    -elles appartiennent au même département
    -la liste des communes concernées est limitée mais évolue chaque année, voire à la marge au cours de l’année.
    -seules les adresses postales des communes concernées sont utiles.

    5) les interventions:
    -elles sont ponctuelles et ont pour objet l’accélération de l’analyse.
    -La réponse est favorable ou défavorable selon les cas (seul l'enregistrement de la demande, la réponse et un champ observation est utile).


    merci d'avance à ceux qui pourront m'aider.
    ps.: je ne précise pas ici les fonctionnalités attendues de la base de donnée. (si c'est utile, je le ferai).

    fcka

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut MCD gestion de dossiers

    Bonjour,

    Je précise une question :

    J'ai réalisé en 2 temps un premier MCD et pour l'heure 2 relations fonctionnent :

    saisie.dia --1,1-------- précise -------1,n -- type de bien
    saisie.dia --1,n-------- précise -------1,1 -- référence cadastrale

    je voudrai maintenant créer une relation saisie.dia avec office notarial.
    Le but est de faire un historique des interventions des notaires (réf notaire, date etc) .

    je ne sais pas comment représenter ce type de relation dans mon mcd:
    saisie.dia --0,1 ----intervention---- 1,n--- office notarial.

    si je relis de cette façon les 2 entités, je risque d'avoir plusieurs fois la même ligne dans office notarial.
    (j'avais pensé à une propriété portée -date d'intervention- par la relation intervention, mais cela ne marche pas).

    je remercie d'avance pour vos lumières.


    fcka

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut MCD gestion de dossiers

    bonjour,
    j'essaie de relier les dossiers, les notaires et les occurrences d'intervention.

    -un notaire peut intervenir 0 ou 1 fois sur un dossier (il y a un notaire max par dossier)
    -un dossier peut avoir 0 ou 1 intervention

    -le notaire qui intervient possède 1 adresse
    -la même adresse de notaire peut faire plusieurs interventions sur divers dossiers (plusieurs dates);

    est-ce que ma façon d'intégrer cela dans mon mcd vous parait correcte?

    merci pour vos conseils,
    fcka
    Images attachées Images attachées  

  4. #4
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut MCD gestion de dossiers

    bonjour,
    je voudrai relier les dossiers, les communes, les adresses des communes et les agents en charge des communes.

    la liste des communes concernées change chaque année,
    la tenue de l'historique de ces listes est nécessaire,
    les adresses postales des communes concernées sont nécessaires,
    les communes sont affectées aux agents pendant une période donnée (finie ou en cours).

    -il y a 0 ou n dossier(s) dans une commune concernée de l'année,
    -1 commune concernée peut avoir 0 ou n dossiers dans l'année,
    -1 ou n agent(s) gère 1 ou n communes,
    -1 commune peut être gérée par 1 ou n agents.

    comment puis-je faire pour avoir une entité des communes concernées de l'année x ?
    comment puis-je gérer l'affectation des communes à des agents pendant une période (finie ou en cours)?
    je suis preneur de toutes pistes ou exemples.
    merci
    fcka

  5. #5
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut MCD gestion de dossiers

    Bonsoir,

    j'essaie depuis plusieurs jours de faire une base de données relative à la gestion de dossiers administratifs nommés dia.

    j'ai avancé dans la définition des objectifs.

    Pour le volet enregistrement:
    (un dossier concerne un type de bien, peut avoir plusieurs réf cadastrales et peut faire l'objet ou pas d'une intervention).
    j'ai mis en relation les entités saisie, type de bien et réf cadastrale, notaire et occurrence.

    Pour l'affectation des dia :
    (un dossier porte sur une commune, la liste des communes concernées varie selon les années, chaque commune dispose d'une adresse postale)
    J'ai mis en relation les entités (année, adresse, commune et saisie) mais je n'arrive pas à formaliser l'affectation des communes aux agents .
    (un ou plusieurs agents instruisent des dia d'une ou plusieurs communes concernées et la liste des communes affectées aux agents varient dans le temps).

    pour la suite donnée :
    je ne sais pas comment formaliser la suite donnée à l'instruction des dossiers sachant qu'il y a 4 issues possibles : RETRAIT, NON RECEVABLE, FAVORABLE et RENONCE (mais RENONCE et FAVORABLE peut advenir immédiatement ou après étude).

    ci-joint mon mcd en l'état.
    merci d'avance à ceux qui pourront m'aider...

    fcka
    Images attachées Images attachées  

  6. #6
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut [MCD] gestion de dossiers

    Bonsoir à tous,

    Je n’ai pas eu jusqu’à présent beaucoup de retour du forum. J’en conclus que j’ai dû mal présenté mon sujet.

    Donc je recommence.

    Préambule:
    La base de donnée que je souhaite réaliser concerne la gestion de données liées à des dossiers administratifs nommés dia (déclaration d’intention d’aliéner).

    L’objectif est de doter notre équipe d’un outil unique pour remplacer de multiples fichiers calc (la base de données doit être implémentée sur postgresql avec une interface base à destination de plusieurs usagers).
    Si elle fonctionne correctement, nous pourrons la partager avec d’autres collègues.

    Pour ma part, je ne suis pas informaticien, j’ai découvert merise il y a quelques semaines avec les vidéos de Frédéric Bauran sur Youtube.

    Je travaille sur ce projet chez moi le plus souvent (car j’ai peu de temps au bureau) et j’utilise le logiciel JPmerise car sa licence m'est abordable et qu'il est pratique.

    ---

    Contexte:
    La dia (déclaration d’intention d’aliéner) est un dossier remis par les vendeurs de biens immobiliers aux communes (via les notaires le plus souvent).

    Ces dossiers sont instruits par les services concernés en vue ou pas, selon l’intérêt du bien, pour une préemption (je ne développe pas plus ce point).

    Les dia sont reçues en commune.

    Certaines communes doivent transférées les dia à l’autorité compétente.

    C’est là que nous intervenons.... Nous enregistrons les dia en vue de les instruire.

    Pendant le délai d'instruction (je ne développe pas), certaines sont retirées par les vendeurs (c’est une 1ère issue), d’autres sont retournées au notaire par nos soins car déposées à tord (c’est une 2nde issue).

    La grande majorité est instruite:
    Soit l’instruction rapide conclut à l’absence d’intérêt pour le bien, soit l’instruction conclut à un intérêt, soit elle considère qu’il est nécessaire d’approfondir l’analyse avant de se prononcer*(intérêt ou pas d’intérêt).

    Dans le 1er cas*: renonce (on purge dans le jargon). La vente initiale suit son cours.
    Dans le 2nd cas*: non recevable (la vente initiale suit son cours).
    Dans le 3ème cas, soit on purge, soit on préempte, soit on communique la dia à des partenaires qui approfondissent l’analyse (si l’issue est favorable, on préempte , sinon on purge).


    Concernant les règles de gestion
    :

    -L’entité saisie_dia (contient les informations descriptives de milliers de dia).

    -L’entité type de bien permet de préciser si le bien est une maison, un garage, …. (le type est unique*: un terrain c’est terrain, une maison avec jardin, c’est une maison).

    -L’entité réf cadastrales permet de lister les références cadastrales liées au bien (elles peuvent être multiples).

    - l’entité notaire sert à faire l’historique des interventions des notaires en vue d’accélérer les délais de traitement.

    -Les dia concernent une commune (dont la liste est définie chaque année).
    Les dia sont instruites par des agents*(les dia sont réparties par commune entre les agents).
    Cette répartition évolue dans le temps.
    Un agent peut instruire les dia de plusieurs communes à l’instant t et à l’instant t, plusieurs agents peuvent intervenir sur une commune donnée (il s’agit de répartition la charge de travail).

    - La suite donnée aux dia:
    il y a 4 issues: retrait, non recevable, favorable ou renonce

    . Dans un 1er temps, certaines dia peuvent être retirées ou retournées (non recevables)*;
    . Dans un 2er temps, les dia instruites peuvent avoir 3 issues possibles (dont 2 définitives):
    renonce
    favorable,
    étude(s) approfondie(s) (réalisée(s) par des partenaires*;
    . Dans le 3è temps, l’étude(s) approfondie(s) peu(ven)t avoir 2 issue(s) possible(s).
    renonce
    favorable.

    S'il peut y avoir plusieurs études menées par différents partenaires, dans le cas (d’école) où plusieurs avis sont favorables, un seul peut être pris en compte.


    En espérant avoir capté votre attention, je vous remercie de me faire part de vos remarques sur mon projet de MCD.
    Images attachées Images attachées  

  7. #7
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    Bonjour Fcka0001,


    Citation Envoyé par fcka0001 Voir le message
    Je n’ai pas eu jusqu’à présent beaucoup de retour du forum. J’en conclus que j’ai dû mal présenté mon sujet.
    Le souci en ce qui me concerne est surtout le manque de temps
    Celà étant, les précisions que vous avez apportées sont très utiles, avoir précisé le contexte est la bonne démarche, définir le vocabulaire et expliquer les acronymes également .


    Citation Envoyé par fcka0001 Voir le message
    Pour ma part, je ne suis pas informaticien, j’ai découvert merise il y a quelques semaines avec les vidéos de Frédéric Bauran sur Youtube.
    [...]j’utilise le logiciel JPmerise car sa licence m'est abordable et qu'il est pratique.
    L'ouvrage de Michel Diviné "parlez vous merise" est un très bon didacticiel que vous pouvez télécharger gratuitement.
    Il existe également quelques logiciels gratuits parmi lesquels DBMain et JMerise


    Citation Envoyé par fcka0001 Voir le message
    Concernant les règles de gestion[/U]: L’entité saisie_dia (contient les informations descriptives de milliers de dia).
    Il s'agit ici de l'entité-type "SAISIE_DIA", chaque occurrence de cette entité-type étant une entité


    Citation Envoyé par fcka0001 Voir le message
    Les dia concernent une commune (dont la liste est définie chaque année).
    Un même bien - ezt donc un même DIA - ne peut il être proposé à plusieurs communes ?


    Citation Envoyé par fcka0001 Voir le message
    Un agent peut instruire les dia de plusieurs communes à l’instant t et à l’instant t, plusieurs agents peuvent intervenir sur une commune donnée (il s’agit de répartition la charge de travail).
    Un agent est il un employé communal ?
    Dans la négative, à quel organisme est il rattaché, peut il travailler pour plusieurs communes ?


    Vous devriez numéroter vos règles de gestion, ça facilite les échanges

    Vous devriez aussi découper votre schéma en sous-ensembles fonctionnels, en l'état, j'ai du mal à déchiffrer le contenu, l'image est trop petite (ma vue n'est plus ce qu'elle était )

  8. #8
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut

    Bonjour,
    merci pour votre retour. Etant en congé aujourd'hui, j'en profite pour vous répondre rapidement.

    Un même bien - et donc un même DIA - ne peut il être proposé à plusieurs communes ?
    La vente d’un bien peut concerner plusieurs communes mais pas les DIA (les DIA à cheval sur plusieurs communes sont retournées à la commune car cela nous pose un problème juridique).

    Je précise un point: la vente d’un bien peut donner lieu au dépôt de plusieurs DIA (si le vendeur souhaite vendre son bien par lots par exemple). Ce cas de figure ne nous pose pas de problème car chaque DIA est traitée (si les deux DIA présentent un intérêt et nécessitent une étude approfondie, nous demanderons à l’un ou plusieurs de nos partenaires d’engager des études approfondies. Dans ce cas, il y a une étude par partenaire pour les deux DIA. Je n’ai pas pris en compte ce cas de figure. Dans mon MCD, il y a une étude par DIA (la même étude) pour chaque partenaire.

    Un agent est-il un employé communal ? Dans la négative, à quel organisme est il rattaché, peut il travailler pour plusieurs communes ?
    Les agents sont des fonctionnaires (État).
    Un agent est chargé effectivement d’instruire les DIA d’une ou plusieurs communes (uniquement les communes déclarées dites carencées. Cette liste évolue chaque année).
    Plusieurs agents peuvent travailler sur des communes identiques (afin de partager la charge de travail dans le cas de «grosses» communes).
    La répartition des communes par agent est modifiée en fonction de la charge globale par agent (le nombre de vente de bien n’est pas le même selon les communes, il évolue selon les périodes de l’année, il s’agit d’équilibrer en permanence la charge de travail de chaque agent).

    Vous devriez numéroter vos règles de gestion, ça facilite les échanges
    R1*: l’entité-type "SAISIE_DIA" contient les informations descriptives de milliers de DIA.

    R2*: l’entité "type de bien" est unique par DIA (un terrain est considéré comme un terrain, une maison avec jardin est considéré comme une maison).

    R3*: l’entité "références cadastrales" permet de lister les références cadastrales liées au bien (elles peuvent être multiples pour un bien donné).

    R4*: l’entité "notaire" recense la liste des notaires (avec cordonnées) ayant sollicité une faveur (accélération de la procédure...).

    R5*: l’entité "occurrence" permet de conserver un historique des interventions des notaires.
    Un notaire peut intervenir 0 ou 1 fois sur une DIA mais un notaire peut intervenir plusieurs fois sur des DIA différentes.

    R6*: Une DIA concerne une et une seule commune carencée (nous ne traitons pas les DIA des communes "non" carencés).
    La liste des communes carencées change chaque année.
    Les adresses postales des communes carencées sont utiles (nous retournons par voie postale les DIA non recevables et les DIA sur lesquelles nous renonçons à exercer un droit de préemption urbain).
    J’ai utilisé 3 entités*: com_cc, adresse_cc et annee_cc.

    R7*: un agent (fonctionnaire de l’Etat) peut instruire les DIA de plusieurs communes carencées.
    Plusieurs agents peuvent intervenir sur une même commune carencée.
    L’affectation des communes par agent change dans le temps (équilibrage de la charge de travail)*;

    R8*: la suite donnée aux DIA*:
    il y a 4 issues finales : retrait, non recevable, favorable ou renonce (purge).

    . certaines dia peuvent être retirées (annulation de la vente par exemple) ou retournées (car non recevables);

    . les autres DIA sont instruites peuvent avoir 3 issues possibles :
    renonce
    favorable,
    ou étude(s) approfondie(s) (réalisée(s) par des partenaires;

    . l’étude(s) approfondie(s) peu(ven)t avoir 2 issue(s) possible(s):
    renonce
    favorable.
    (Si plusieurs études menées par différents partenaires concluent à un avis favorable (cas d’école), un seul peut être pris en compte).


    Pour formaliser les issues définitives, j’ai utilisé 4 entités (retrait, non_recevable, renonce et favorable) et la notion d’héritage avec contrainte de partition.

    Pour formaliser les études approfondies j’ai utilisé 2 entités (saisie_etude et partenaire)
    J’ai hésité à faire porter une contrainte de partition aux associations ‘conclusion_neg’ et ‘conclusion_pos’ (conclusions des études approfondies) car je ne sais pas s’il faut prendre en compte les dia "en cours d’instruction" (celles pour lesquelles l'issue favorable ou renonce n'et pas tranchée).



    Vous devriez aussi découper votre schéma en sous-ensembles fonctionnels, en l'état, j'ai du mal à déchiffrer le contenu, l'image est trop petite
    je m'excuse par avance pour les éventuelles énormités;
    Images attachées Images attachées    

  9. #9
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par fcka0001 Voir le message
    La vente d’un bien peut concerner plusieurs communes mais pas les DIA (les DIA à cheval sur plusieurs communes sont retournées à la commune car cela nous pose un problème juridique).
    Vous devez donc être en capacité d'identifier qu'une DIA est multi-commune, vous devez le faire apparaitre dans vos règles de gestion et modéliser en conséquence (sauf si vous renvoyez la DIA concernée sans même l'enregistrer dans le système d'information !)
    Les règles de gestion entre l'entité-type "COMMUNE" et l'entité-type "DIA" sont donc :
    Rxxx : une DIA concerne au moins une commune
    Ryyy : une commune peut être concernée par plusieurs DIA

    Ce qui donne la modélisation suivante : COMMUNE 0,n --- concerner --- 1,n DIA



    Citation Envoyé par fcka0001 Voir le message
    Je précise un point: la vente d’un bien peut donner lieu au dépôt de plusieurs DIA (si le vendeur souhaite vendre son bien par lots par exemple). Ce cas de figure ne nous pose pas de problème car chaque DIA est traitée (si les deux DIA présentent un intérêt et nécessitent une étude approfondie, nous demanderons à l’un ou plusieurs de nos partenaires d’engager des études approfondies. Dans ce cas, il y a une étude par partenaire pour les deux DIA. Je n’ai pas pris en compte ce cas de figure. Dans mon MCD, il y a une étude par DIA (la même étude) pour chaque partenaire.
    Dans ce cas, certains attributs tels que le vendeur, la date de mise en vente etc... sont communs à ces différentes DIA.
    il faut donc rédiger les règles suivantes :
    Rxxx : un bien est attribué dans au moins une DIA
    Ryyy : dans une DIA un et un seul bien est attribué

    Ce qui donne la modélisation suivante : BIEN 1,n --- attribuer --- 1,1 DIA

    Les attributs liés au vendeur seront situés dans l'entité-type "BIEN", sauf si vous devez gérer également les vendeurs, auquel cas, une entité-type "VENDEUR" serait ajoutée, en relation avec l'entité-type "BIEN"
    Pour l'instant, rien ne laisse supposer que vous devez gérer les vendeurs.



    Citation Envoyé par fcka0001 Voir le message
    Les agents sont des fonctionnaires (État).
    Un agent est chargé effectivement d’instruire les DIA d’une ou plusieurs communes (uniquement les communes déclarées dites carencées. Cette liste évolue chaque année).
    Plusieurs agents peuvent travailler sur des communes identiques (afin de partager la charge de travail dans le cas de «grosses» communes).
    La répartition des communes par agent est modifiée en fonction de la charge globale par agent (le nombre de vente de bien n’est pas le même selon les communes, il évolue selon les périodes de l’année, il s’agit d’équilibrer en permanence la charge de travail de chaque agent).
    Voici les règles de gestion correspondantes
    Rxxx : un agent gère au moins une commune
    Ryyy : une commune est gérée par au moins un agent
    Rzzz : un agent n'intervient sur une DIA que si cette DIA concerne une commune qu'il gère
    La règle Rzzz étant ce qu'on appelle une Contrainte d'Intégrité Fonctionnelle (CIF)

    Ces règles se matérialisent par le MCD qui suit :
    AGENT 1,n --- gérer --- 1,n COMMUNE 0,n --- concerner --- 1,n DIA
    ....0,n.................................................................................0,n
    .....└--------------------------- intervenir ----------------------┘

    Ici, j'ai supposé qu'une DIA pouvait être gérée par plusieurs agents, vous ne l'aviez pas précisé



    Ce qui suit est utile, mais ce ne sont pas des règles de gestion. Les règles de gestion précisent les relations entre les acteurs.
    Prenez exemple sur ce qui précède pour compléter vos règles
    Citation Envoyé par fcka0001 Voir le message
    R1*: l’entité-type "SAISIE_DIA" contient les informations descriptives de milliers de DIA.

    R2*: l’entité "type de bien" est unique par DIA (un terrain est considéré comme un terrain, une maison avec jardin est considéré comme une maison).

    R3*: l’entité "références cadastrales" permet de lister les références cadastrales liées au bien (elles peuvent être multiples pour un bien donné).
    [. . .]


    Je n'ai pas regardé la suite de votre MCD, mais complétez d'abord les règles de gestion

    Et merci pour le schéma "XXL", j'y vois mieux à présent

  10. #10
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut

    bonjour,

    merci beaucoup pour votre aide.

    j'essaie de répondre point par point à vos observations :

    Vous devez donc être en capacité d'identifier qu'une DIA est multi-commune, vous devez le faire apparaitre dans vos règles de gestion et modéliser en conséquence (sauf si vous renvoyez la DIA concernée sans même l'enregistrer dans le système d'information !)
    Les règles de gestion entre l'entité-type "COMMUNE" et l'entité-type "DIA" sont donc :
    Rxxx : une DIA concerne au moins une commune
    Ryyy : une commune peut être concernée par plusieurs DIA
    Ce qui donne la modélisation suivante : COMMUNE 0,n --- concerner --- 1,n DIA
    Les DIA concernent dans l'immense majorité une seule commune carencée.

    Exceptionnellement, il arrive que des DIA réceptionnées au service par erreur concernent :
    -aucune commune carencée
    ou bien
    -une commune carencée et une commune non carencée
    ou bien
    -deux communes carencées (n'est jamais arrivé, car il faut que les communes carencées soient contigües, que les notaires omettent le principe d'une dia par commune et que les biens soient à cheval sur deux communes).

    De façon générale, les DIA qui ne concernent aucune commune carencée sont retournées sans être enregistrées.
    Les autres DIA sont enregistrées en pointant une commune carencée (s’il y en a deux, « l’une au hasard » car ces DIA n'ont plus un enjeu immédiat). En effet, l’agent qui enregistre la DIA sait pertinemment que la DIA sera retournée par l’instructeur car elle est non recevable en l’état. L’instructeur la renvoie après avoir enregistré les références cadastrales du bien dans une couche SIG (l’enregistrement de la DIA permet à l’instructeur de conserver une trace supplémentaire).

    Je propose de conserver la règle : COMMUNE 0,n --- concerner --- 1,1 DIA
    (à moins que mon explication ne vous convainc pas).


    Dans ce cas, certains attributs tels que le vendeur, la date de mise en vente etc... sont communs à ces différentes DIA.
    il faut donc rédiger les règles suivantes :
    Rxxx : un bien est attribué dans au moins une DIA
    Ryyy : dans une DIA un et un seul bien est attribué

    Ce qui donne la modélisation suivante : BIEN 1,n --- attribuer --- 1,1 DIA

    Les attributs liés au vendeur seront situés dans l'entité-type "BIEN", sauf si vous devez gérer également les vendeurs, auquel cas, une entité-type "VENDEUR" serait ajoutée, en relation avec l'entité-type "BIEN"
    Pour l'instant, rien ne laisse supposer que vous devez gérer les vendeurs.
    Je confirme que nous ne gérons pas les vendeurs.

    Pour le reste, quand un bien est vendu par lot, nous devons avoir plusieurs DIA.
    Chacune des DIA fait référence à un type de bien. Vous avez raison, certains attributs de l’entité "saisie_dia" seront communs (le nom du vendeur et certainement la date de dépôt en mairie).
    Le montant, les réf cadastrales, le type de bien etc ne seront pas identiques. Toutefois, je ne comprend pas bien l’intérêt de positionner l’attribut ‘vendeur’ et ‘date de réception en mairie’ dans l’entité "type du bien" sachant que ce dernier renvoie à un n° de DIA distinct dans l’entité "saisie_dia".
    En dehors de ce point, il me semble que votre modélisation (BIEN 1,n --- attribuer --- 1,1 DIA) correspond à celle que j’ai proposée.

    Voici les règles de gestion correspondantes
    Rxxx : un agent gère au moins une commune
    Ryyy : une commune est gérée par au moins un agent
    Rzzz : un agent n'intervient sur une DIA que si cette DIA concerne une commune qu'il gère
    La règle Rzzz étant ce qu'on appelle une Contrainte d'Intégrité Fonctionnelle (CIF)

    Ces règles se matérialisent par le MCD qui suit :
    AGENT 1,n --- gérer --- 1,n COMMUNE 0,n --- concerner --- 1,n DIA
    ....0,n.................................................................................0,n
    .....└--------------------------- intervenir ----------------------┘

    Ici, j'ai supposé qu'une DIA pouvait être gérée par plusieurs agents, vous ne l'aviez pas précisé

    Une DIA relève de l’instruction d’un seul agent. Notre répartition de charge de travail est fondée sur ce principe. Toutefois, si on entre dans le détail de notre fonctionnement interne, j'admets que ce principe ne prend pas en compte les absences des agents. En effet, lorsqu’un agent part en congé par exemple, « ses » DIA sont réparties entre les agents présents afin d'assurer la continuité de service.
    Cette pratique ne remet pas en compte toutefois le décompte des DIA par agent (qui découle de la répartition des communes par agent en vigueur).

    Concernant la règle : si je comprend bien, la CIF génère 3 relations dont l’une entre l’entité agents et l’entité DIA (c'est cela?).
    Par contre, comment sera gérée dans ce cas l'affectation des communes par agent dans le temps? (l’un des objectifs est de pouvoir faire au fil du temps, le bilan du nombre de DIA instruites par agent afin de rectifier le plan de charge de chacun si nécessaire).

    Je n'ai pas regardé la suite de votre MCD, mais complétez d'abord les règles de gestion
    Pour rappel :
    R1: l’entité-type "SAISIE_DIA" contient les informations descriptives de milliers de DIA.

    R2: l’entité "type de bien" est unique par DIA (un terrain est considéré comme un terrain, une maison avec jardin est considéré comme une maison).

    R3: l’entité "références cadastrales" permet de lister les références cadastrales liées au bien (elles peuvent être multiples pour un bien donné).

    Je tente de reprendre les règles R4 et suivantes :


    R4 : l’entité "notaire" permet de lister les coordonnées des notaires qui sollicitent une accélération de la procédure pour une DIA donnée.
    Un seul notaire peut intervenir sur une DIA donnée.
    Une DIA fait l’objet au maximum d’une intervention d'un notaire.

    Je l’ai modélisée :
    Notaire 0,1 — intervient ---0,1 DIA


    R5 : L’entité "occurrence" a pour objet de tenir à jour l’historique des interventions par notaire.
    Un notaire peut faire plusieurs interventions (toutes DIA confondues)
    Une occurrence est faite par un notaire donné.

    Je l’ai modélisée :
    Occurrence 1,1 — décompte interv ---1,N notaire.


    R6 à R8 : elles concernent la CiF évoquée ci-dessus. Dans mon projet de MCD, j’avais formalisé les choses ainsi :

    R6 : la règle a pour objet de définir la commune sur laquelle porte la DIA :

    1 DIA concerne 1 commune carencée
    1 commune carencée est concernée par 0 ou N DIA.
    Une commune peut être carencée l’année X , puis l’année Y ou ne plus l’être l’année Z.

    En relisant, je m’aperçois que mon MCD ne fonctionnera pas car l'attribut "année" fera apparaitre l’année en colonne.
    Je pense qu'il me faudrait une entité supplémentaire « année » pour la relier à l'entité "com_cc" afin de tenir compte de l’évolution de la liste des communes carencées, comme ceci :
    com_cc -- 1,N ---- actualise--- 1, N année ??

    Je l’ai modélisée :
    saisie dia 1,1 ---- localise — 0,N com_cc mais cela ne prend pas en compte l’entité "année".

    Faut-il utiliser la notion d’agrégation d’entité ? Si oui comment formaliser la chose entre les entités « saisie_dia », « com_cc » et « annee »?

    R7 : cette règle relie les communes carencées a une table adresse postale.
    1 commune carencée dispose d’une adresse postale.
    1 adresse postale existe pour N commune

    Je l’ai modélisée :
    saisie com_cc 1,1----domicilie— 1,N cc_adresse

    R8 : cette règle relie les agents et les communes dont ils ont la charge :
    de 0 à plusieurs agents ont en charge aucune ou plusieurs communes carencées
    aucune ou plusieurs communes sont gérées par aucun ou plusieurs agents.

    Je l’ai modélisée :
    agents 0,N ---- instruise -- 0,N com_cc

    A la relecture « 0 agents » peut se justifier le départ d’un agent ?

    Par contre, la cardinalité minimale 0 commune carencée ne se justifie plus si j’arrive à mettre en place le principe d’actualisation de liste des communes carencées (cf R6).

    R9 : Cette règle a pour objectif de tenir à jour les périodes de prise en charge des communes par agent :
    chaque agent a une ou plusieurs prises en charge
    1 prise en charge peut concerner un ou plusieurs agents.

    je l’ai formalisée :
    agent 1,N — détaille — 1,N période agent

    R10 : cette règle relie les périodes de prise en charge aux communes carencées.

    1 période de prise en charge peut concerner 0 ou N communes carencées.
    1 commune carencée peut être concernée par 0 ou N période de prise en charge.

    Je l’ai formalisée :

    période agent -- 0, N -------suivre---------0, N -- com_cc


    R11 : cette règle formalise le fait que l’instruction d’une DIA peut déboucher sur le lancement d’une (ou plusieurs) étude(s) approfondie(s) :
    S’il y a plusieurs études approfondies, cela signifie qu’une étude est menée par des partenaires distincts (ce cas est très rare).

    1 DIA peut faire l’objet d’une ou plusieurs études approfondies.
    1 étude approfondie concerne une DIA (cela ne tient pas compte des ventes par lots : il y a plusieurs DIA, mais une seule étude sera menée par partenaire).

    Je l’ai formalisée :
    saisie_dia-- 0,N ---- analyse_approf ---- 1,1-- saisie étude.


    R12 : cette règle permet d’associer le nom du partenaire à l’étude approfondie réalisée :
    1 étude est menée par 1 ou plusieurs partenaires ;
    1 partenaire réalise 1 ou plusieurs étude ;

    je l’ai formalisée :
    saisie etude — 1,N ----charge ----- 1,N partenaire.


    R13 : cette règle formalise la conclusion de l’étude approfondie :
    La conclusion est positive ou négative.
    Une conclusion négative conduit à renoncer à la DIA.
    Une conclusion positive conduit à préempter (si plusieurs études concluent de façon positive , la première réponse sera retenue car les partenaires sont sollicités successivement).

    Je l’ai formalisée ainsi :
    saisie étude 0,N — conclusion neg –-- 0,N renonce
    saisie étude 0,N ---conclusion pos ----0,N favorable


    R14 : cette règle permet de gérer la suite donnée aux DIA :
    il y a 4 suites données possibles :
    -non recevable,
    -retrait,
    -positive (préemption),
    -renonce (purge).

    .Le retrait peut arriver n’importe quand pendant la durée de l’instruction, cela interrompt toute procédure.
    .Une DIA est déclarée non recevable en début d’instruction
    .Une DIA peut être déclarée sans intérêt à deux moments :
    soit après une étude rapide (filtre)
    soit après une analyse approfondie
    .Une DIA peut donner lieu à une préemption après une étude approfondie (ou éventuellement sans étude approfondie: ce cas n'est jamais arrivé mais à mon avis doit être intégré).

    J’ai formalisé cela avec la notion d’héritage en reliant les entités renonce, favorable, non recevable et retrait à l’entité saisie_dia. (l’idée étant de récupérer l’identifiant ‘num’).

    J’ai ajouté une contrainte de partition XT (cela peut être problème pour les DIA qui sont "en cours d’instruction" (étude légère, étude approfondie).

    Merci encore pour l'attention que vous me portez.

  11. #11
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par fcka0001 Voir le message
    De façon générale, les DIA qui ne concernent aucune commune carencée sont retournées sans être enregistrées.[. . .]Je propose de conserver la règle : COMMUNE 0,n --- concerner --- 1,1 DIA
    En ce cas vous avez raison, inutile de compliquer le modèle



    Citation Envoyé par fcka0001 Voir le message
    Vous avez raison, certains attributs de l’entité "saisie_dia" seront communs (le nom du vendeur et certainement la date de dépôt en mairie).[. . .].
    Toutefois, je ne comprend pas bien l’intérêt de positionner l’attribut ‘vendeur’ et ‘date de réception en mairie’ dans l’entité "type du bien" sachant que ce dernier renvoie à un n° de DIA distinct dans l’entité "saisie_dia".
    Ce n'est pas ce que j'ai écrit, j'ai proposé :
    Citation Envoyé par escartefigue Voir le message
    Les attributs liés au vendeur seront situés dans l'entité-type "BIEN"
    Dans ma proposition, on a 3 types d'entité (ou entité-types) agencées comme suit :
    TYPE_BIEN 0,n --- typer --- 1,1 BIEN 1,n --- attribuer --- 1,1 DIA
    Nom du vendeur et date de dépôt en mairie sont des attributs de l'ET "BIEN" et non "DIA"



    Citation Envoyé par fcka0001 Voir le message
    Concernant la règle : si je comprend bien, la CIF génère 3 relations dont l’une entre l’entité agents et l’entité DIA (c'est cela?).
    Par contre, comment sera gérée dans ce cas l'affectation des communes par agent dans le temps? (l’un des objectifs est de pouvoir faire au fil du temps, le bilan du nombre de DIA instruites par agent afin de rectifier le plan de charge de chacun si nécessaire).
    Une CIF est une dépendance entre plusieurs relations, ici c'est la règle Rzzz qui est contrainte
    Le bilan dépend de ce qu'il faut compter, est-ce qu'une DIA qui a été traitée au départ par l'agent 007, mais finalisée par l'agent 123 doit être comptée comme traitée par 007, par 123, par les deux ?
    Selon le cas, un historique des agents intervenant sur la DIA est a mettre en place.



    Que représente l'entité-type "REF_CADAS_DIA", elle présente des attributs redondants avec "SAISIE_DIA" c'est donc suspect. A expliquer.
    Au passage, le nom "DIA" est préférable, la notion de saisie est liée au traitement et n'a donc rien à faire au niveau des données



    Citation Envoyé par fcka0001 Voir le message
    R4 : l’entité "notaire" permet de lister les coordonnées des notaires qui sollicitent une accélération de la procédure pour une DIA donnée.
    Un seul notaire peut intervenir sur une DIA donnée.
    Une DIA fait l’objet au maximum d’une intervention d'un notaire.

    Je l’ai modélisée :
    Notaire 0,1 — intervient ---0,1 DIA
    Votre modèle interdit à un notaire d'intervenir sur différentes DIA, ça ne va pas.
    Il faut modéliser NOTAIRE 0,n --- intervenir --- 0,1 DIA
    Au niveau tabulaire (MLD), l'identifiant du notaire se retrouvera en clef étrangère dans la table DIA et vous pourrez contrôler facilement l'unicité de l'intervention pour un notaire en vérifiant que cette FK est bien marquée "NULL" :
    si "NOT NULL" c'est qu'un notaire est déjà intervenu, ce que vous voulez interdire



    Citation Envoyé par fcka0001 Voir le message
    R5 : L’entité "occurrence" a pour objet de tenir à jour l’historique des interventions par notaire.
    Un notaire peut faire plusieurs interventions (toutes DIA confondues)
    Une occurrence est faite par un notaire donné.

    Je l’ai modélisée :
    Occurrence 1,1 — décompte interv ---1,N notaire.
    Ça ne va pas, c'est une redondance avec la relation "intervenir" (plutôt que "intervient", l'usage étant les verbes pour nommer les relations ).
    Si vous devez connaitre le nombre d'interventions d'un notaire, il suffit de compter le nombre d'occurrences de DIA dans lesquelles l'identifiant notaire est présent comme clef étrangère



    Citation Envoyé par fcka0001 Voir le message
    R6 à R8 : elles concernent la CiF évoquée ci-dessus. Dans mon projet de MCD, j’avais formalisé les choses ainsi :

    R6 : la règle a pour objet de définir la commune sur laquelle porte la DIA :

    1 DIA concerne 1 commune carencée
    1 commune carencée est concernée par 0 ou N DIA.
    Une commune peut être carencée l’année X , puis l’année Y ou ne plus l’être l’année Z.

    En relisant, je m’aperçois que mon MCD ne fonctionnera pas car l'attribut "année" fera apparaitre l’année en colonne.
    Il faudrait préciser selon quelle périodicité change la notion de carencement pour une commune (plusieurs fois par an, une seule, à date fixe?...)
    Il faudrait également préciser ce qui se passe si une DIA est reçue au titre d'une commune carencée, mais que son instruction dure longtemps et que dans l'intervalle, la commune n'est plus carencée.
    Dans le cas où le contrôle de carence n'est fait qu'à réception de la DIA et que le changement de statut (carencé oui/non) ne se fait qu'une fois par an à date fixe, alors il suffit d'avoir la liste exhaustive des communes et un booléen carencé O/N rafraichi une fois par an. Plus besoin de gérer une date de carencement



    Citation Envoyé par fcka0001 Voir le message
    R7 : cette règle relie les communes carencées a une table adresse postale.
    1 commune carencée dispose d’une adresse postale.
    1 adresse postale existe pour N commune

    Je l’ai modélisée :
    saisie com_cc 1,1----domicilie— 1,N cc_adresse
    comment une commune pourrait-elle être liée à une et une seule adresse ?
    A moins qu'il s'agisse d'une adresse d'un représentant particulier de la commune (le maire par exemple), sinon ça ne va pas



    Citation Envoyé par fcka0001 Voir le message
    R8 : cette règle relie les agents et les communes dont ils ont la charge :
    de 0 à plusieurs agents ont en charge aucune ou plusieurs communes carencées
    aucune ou plusieurs communes sont gérées par aucun ou plusieurs agents.

    Je l’ai modélisée :
    agents 0,N ---- instruise -- 0,N com_cc
    OK pour ça



    Citation Envoyé par fcka0001 Voir le message
    A la relecture « 0 agents » peut se justifier par le départ d’un agent ?
    Peut être, mais il s'agit d'une règle métier, seuls vos correspondants métier peuvent et doivent valider les règles de gestion



    Citation Envoyé par fcka0001 Voir le message
    R9 : Cette règle a pour objectif de tenir à jour les périodes de prise en charge des communes par agent :
    chaque agent a une ou plusieurs prises en charge
    1 prise en charge peut concerner un ou plusieurs agents.
    Cette partie est redondante avec la relation "instruire".
    En l'état rien n'interdit de créer des relations différentes entre communes et agent selon qu'on passe par "instruire" ou par "détail"+"suivre"
    Ajoutez des dates dans la relation "instruire" et supprimez cette partie.



    Je ne vais pas plus loin dans la relecture pour l'instant, il y a je pense déjà pas mal de matière pour que vous puissiez proposer une nouvelle version du MCD.
    Bon courage

  12. #12
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut

    Bonjour,

    Merci pour votre aide.

    Je réagis sur quelques points:

    Ce n'est pas ce que j'ai écrit, j'ai proposé :
    Les attributs liés au vendeur seront situés dans l'entité-type "BIEN"

    Dans ma proposition, on a 3 types d'entité (ou entité-types) agencées comme suit :
    TYPE_BIEN 0,n --- typer --- 1,1 BIEN 1,n --- attribuer --- 1,1 DIA
    Nom du vendeur et date de dépôt en mairie sont des attributs de l'ET "BIEN" et non "DIA"
    OK, autant pour moi. Par contre, une dia fait toujours référence à un type de bien (maison, appart, terrain,etc).
    ne faudrait-il pas écrire TYPE_BIEN 1,n --- typer --- 1,1 BIEN ?
    Pour le moment, je garde votre proposition.

    Une CIF est une dépendance entre plusieurs relations, ici c'est la règle Rzzz qui est contrainte
    Le bilan dépend de ce qu'il faut compter, est-ce qu'une DIA qui a été traitée au départ par l'agent 007, mais finalisée par l'agent 123 doit être comptée comme traitée par 007, par 123, par les deux ?
    Selon le cas, un historique des agents intervenant sur la DIA est a mettre en place.
    Il faut compter la DIA traitée par l’agent chargé de la commune (dans votre exemple l’agent 007), et cela qu'il commence ou pas l’instruction de la DIA.
    L’idée c’est que l’agent 123 partira lui aussi en congé et c’est l’agent 007 qui prendra le relais sur ses DIA.
    Cela n'interfère pas avec la réparation des dia via la répartition des communes.

    Que représente l'entité-type "REF_CADAS_DIA", elle présente des attributs redondants avec "SAISIE_DIA" c'est donc suspect. A expliquer.
    L’entité ref_cadas_dia liste les références cadastrales du bien correspondant à la DIA x (cf règle 3).

    Un bien (maison, terrain, etc) est cadastré sur 1 ou plusieurs références cadastrales.
    La (ou les) référence(s) cadastrale(s) d’un bien corresponde(nt) à une DIA.

    J’ai modélisée la règle ainsi:
    ref_cadas_dia — 1,1 ----- liste----1,N – DIA

    Les autres attributs de l’entité ‘réf_cadas_dia’ n’ont de redondance à mon sens avec les attributs de l’entité ‘DIA’ (l’attribut ‘ref_longue’ est par contre mal positionné et doit effectivement être placé dans l’entité DIA).

    Je passe ces attributs en revue rapidement:

    - Les attributs ‘section’ et ‘parcelle’ constitue ce que j’appelle la référence cadastrale (2 caractères pour la section & 4 caractères pour le n° de parcelle).

    - L’attribut ‘ind_partie’ (en booléen) permet de préciser si la parcelle est concernée par une division foncière (notée souvent p).
    Je m’explique: le propriétaire d’un terrain cadastré AA0001 de 2000m² peut en vendre qu’une partie (500m² par exemple). Dans ce cas, une division foncière est nécessaire. Les deux nouvelles parcelles (1500 m² et 500m²) devront être cadastrées. Dans la pratique si la dernière parcelle numérotée dans la section AA porte le n°2451, les deux nouvelles parcelles seront cadastrées AA2452 et AA2453.
    Or, au stade de la DIA, le renommage des parcelles n’est pas toujours réalisé. Les notaires soulignent la division foncière à venir en nommant la référence cadastrale AA0001p.

    -Les attributs ‘superf ha’, ‘superf a’, ‘superf ca’ font référence aux superficies de chaque parcelle en surface agraire (hectare, are, centiare).
    J’ai intégré ces attributs en anticipant sur une évolution possible de notre pratique interne.
    Pour l’heure, les superficies des parcelles cadastrées ne sont pas enregistrées à la parcelle (seule la superficie totale des parcelles en m² est enregistrée ainsi que la superficie du bien en m² (maison , local etc.) , d’où ces 2 attributs dans l’entité DIA.

    - L’attribut réf_longue*: il doit permettre d’importer dans la base de données notre colonne de références cadastrales actuelles (dans laquelle les références cadastrales sont enregistrées dans une seule cellule Calc). Je le déplace dans l’entité DIA.

    Au passage, le nom "DIA" est préférable, la notion de saisie est liée au traitement et n'a donc rien à faire au niveau des données*;
    OK. Je corrige.

    R4
    Votre modèle interdit à un notaire d'intervenir sur différentes DIA, ça ne va pas.
    Il faut modéliser NOTAIRE 0,n --- intervenir --- 0,1 DIA
    OK. Je corrige.

    R5
    Si vous devez connaître le nombre d'interventions d'un notaire, il suffit de compter le nombre d'occurrences de DIA dans lesquelles l'identifiant notaire est présent comme clef étrangère.
    Pas seulement, nous devons aussi tenir à jour l’historique détaillé des interventions des notaires car nous pouvons être appelés à éditer un bilan par exemple des interventions d’un notaire x avec les dates de leur intervention, les suites données (O/N), les observations faites.

    J’ajoute que si notre doctrine est effectivement de ne pas encourager cette pratique, la suite donnée à une intervention de notaire ne peut pas être traitée de façon automatisée car elle relève d’une appréciation au cas par cas, au regard des motifs exposés (ce sont souvent des cas sensibles où «l’humain» est très présent…) .

    En supprimant l’entité ‘occurrence’, il reste possible de comptabiliser les interventions des notaires avec une requête mais nous perdrons ?? les infos sur la date, les observations, les suites données (O/N).
    Aussi, je propose de garder dans l'attente de votre retour l’entité ‘occurrence’ en renommant la relation «decompte_inter» en «détailler».

    R6 à R8
    Il faudrait préciser selon quelle périodicité change la notion de carencement pour une commune (plusieurs fois par an, une seule, à date fixe?...)
    Il faudrait également préciser ce qui se passe si une DIA est reçue au titre d'une commune carencée, mais que son instruction dure longtemps et que dans l'intervalle, la commune n'est plus carencée.
    Dans le cas où le contrôle de carence n'est fait qu'à réception de la DIA et que le changement de statut (carencé oui/non) ne se fait qu'une fois par an à date fixe, alors il suffit d'avoir la liste exhaustive des communes et un booléen carencé O/N rafraichi une fois par an. Plus besoin de gérer une date de carencement
    La déclaration de carence ou de sortie de carence est faite tous les 3 ans avec possibilité de sortie si les objectifs assignés par la loi à la commune sont atteints (il s'agit de production de logements sociaux).

    L’impact de la sortie de carence sur les DIA ne pose de problème: l’instruction des DIA est stoppée et celles-ci sont transférées à la commune avec toutes les analyses menées. En ce qui nous concerne, les suites données à ces DIA sont enregistrées en «non recevable».

    Nous sommes effectivement en mesure d’actualiser en début d’année la liste exhaustive des communes carencées. Le problème c’est que nous devons pouvoir faire des calculs sur plusieurs années et conserver l’historique des communes carencées. J’essaie de trouver une solution en incluant une entité «*carence*»


    R7 :
    comment une commune pourrait-elle être liée à une et une seule adresse ?
    A moins qu'il s'agisse d'une adresse d'un représentant particulier de la commune (le maire par exemple), sinon ça ne va pas
    C’est l’adresse du maire. (nous avons besoin des adresses postales des mairies car les DIA non recevables ou purgées sont retournées à la commune concernée. C'est la mairie qui communique ensuite les DIA aux notaires).

    Cette partie est redondante avec la relation "instruire".
    En l'état rien n'interdit de créer des relations différentes entre communes et agent selon qu'on passe par "instruire" ou par "détail"+"suivre"
    Ajoutez des dates dans la relation "instruire" et supprimez cette partie.
    OK


    vous puissiez proposer une nouvelle version du MCD.
    OK (je ne suis pas sûr pour la matérialisation de la CIF).

    Merci encore pour vos conseils avisés.
    Images attachées Images attachées  

  13. #13
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par fcka0001 Voir le message
    OK, autant pour moi. Par contre, une dia fait toujours référence à un type de bien (maison, appart, terrain,etc).
    ne faudrait-il pas écrire TYPE_BIEN 1,n --- typer --- 1,1 BIEN ?
    Pour le moment, je garde votre proposition.
    La cardinalité mini de zéro coté "TYPE_BIEN" permet d'avoir des types de biens sans bien correspondant
    C'est ce que l'on fait en général pour les typologies (codes pays, codes devises, code catégorie socio-professionnelle etc...)
    En effet, ces tables référencent les typologies possibles , même si à un instant "t" vous n'en possédez pas.
    Par exemple, le code correspondant à un moulin sera renseigné dans la table des typologies, bien que vous n'ayez jamais eu un bien de ce type. Le jour où ce sera le cas, vous serez prêt

    Les autres points nécessitent un peu plus de temps, j'y reviendrai dès que possible

  14. #14
    Nouveau membre du Club
    Homme Profil pro
    chargé d'études
    Inscrit en
    janvier 2015
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : chargé d'études

    Informations forums :
    Inscription : janvier 2015
    Messages : 54
    Points : 36
    Points
    36

    Par défaut

    Bonjour,

    Citation Envoyé par fcka0001
    OK, autant pour moi. Par contre, une dia fait toujours référence à un type de bien (maison, appart, terrain,etc).
    ne faudrait-il pas écrire TYPE_BIEN 1,n --- typer --- 1,1 BIEN ?
    Pour le moment, je garde votre proposition.
    ces tables référencent les typologies possibles , même si à un instant "t" vous n'en possédez pas.
    D'accord.
    fcka

Discussions similaires

  1. MCD gestion dossier de cooperation
    Par elhou80 dans le forum Modélisation
    Réponses: 1
    Dernier message: 28/12/2008, 00h00
  2. [MCD]Gestion de dossier médical
    Par kawther dans le forum Schéma
    Réponses: 1
    Dernier message: 31/07/2007, 00h17
  3. [MCD] Gestion d'acces a des applications
    Par Tibler dans le forum Schéma
    Réponses: 12
    Dernier message: 25/04/2006, 19h10
  4. [BEST_PRACTICE][Merise] MCD & gestion de date
    Par Seb7 dans le forum Schéma
    Réponses: 5
    Dernier message: 10/01/2006, 06h49
  5. [MCD] [MCD] Gestion des dates
    Par brionne dans le forum Schéma
    Réponses: 3
    Dernier message: 30/05/2003, 14h01

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