Discussion :

[fcka0001]

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

[fcka0001]

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

[fcka0001]

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

[fcka0001]

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

[fcka0001]

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

[fcka0001]

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.

[escartefigue]

Bonjour Fcka0001,

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 .

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

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é

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 ?

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 )

[fcka0001]

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;

[escartefigue]

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

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.

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

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

[fcka0001]

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.

[escartefigue]

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

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é :

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"

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

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

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

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

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

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

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

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

[fcka0001]

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.

[escartefigue]

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

[fcka0001]

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

[fcka0001]

Bonjour,

En espérant recevoir une aide de votre part (car j'en ai franchement besoin), je résume ci-dessous les 14 posts précédents en consolidant le mieux possible les échanges.

Le sujet concerne le suivi de l’instruction de déclarations d’intentions d’aliéner (documents établis en général par les notaires avant la vente d’un bien immobilier).

Le MCD projeté en l’état comprend 4 sous-ensembles fonctionnels*:
a) le sous-ensemble*‘DIA’
b) le sous-ensemble ‘notaire’
c) le sous-ensemble ‘agent/commune’
d) le sous-ensemble ‘suite donnée’ (sur lequel je n’ai eu aucun retour sur le forum...)

a) le sous-ensemble ‘DIA’*:
ce sous-ensemble est utile pour assurer la saisie les informations relatives à la vente d’un bien immobilier et extraites des DIA.
Les règles R1 envisagées sont les suivantes*:

DIA 1,1 -------attribuer---- 1,N BIEN
-Une DIA concerne un vendeur. Ce vendeur peut vendre plusieurs biens.

BIEN 1,1-------- typer------- 0,N TYPE DE BIEN
-Chaque DIA est typé (maison, terrain, …). Un type peut concerner plusieurs DIA.

DIA 1,N---------lister-------- 1,1 REF_CADASTRALE
-Une DIA concerne un bien cadastré par 1 ou plusieurs références cadastrales. Les références cadastrales données renvoient à une DIA.

b) Le sous-ensemble ‘notaire’*:
L’instruction des DIA nécessite un délai qui retarde d’autant la date de la vente prévue initialement par le vendeur et l‘acquéreur. Aussi, il arrive que des notaires interviennent ponctuellement sur une DIA pour demander d’accélérer le délai d’instruction. L’enjeu est de comptabiliser ces interventions.

Les règles R2 envisagées sont les suivantes :

DIA 0,1------intervenir- ----0,N NOTAIRE
-une DIA peut faire l’objet d’une intervention au plus par notaire et un notaire peut intervenir ou pas sur des DIA.

NOTAIRE 1,N----détailler-----1,1 OCCURRENCE
un notaire intervient une ou plusieurs fois et une date d’intervention concerne un notaire.

c) le sous-ensemble ‘DIA/agent/commune’*:
-doit permettre de relier les DIA aux communes,
-de distinguer les communes carencées de l’année t ,
-de comptabiliser les DIA affectées officiellement aux agents par commune sur une période donnée.
-de disposer des adresses postales des hôtels de ville des communes.

Les règles R3 envisagées sont les suivantes :

DIA 1,1----- localiser-----0,N COMMUNE
une DIA concerne un bien localisé dans une commune et une commune peut être (ou pas) concernée par une DIA (on considère que COMMUNE contient la liste des communes du département y compris des communes non carencées)

COMMUNE 0,N ---concerner----0,N CARENCE
Toutes les communes du département ne sont pas carencées.
Certaines communes sont ou pas carencées à l’année t (certaines communes peuvent donc être carencées plusieurs années consécutives).

COMMUNE 1,1----adresser---- 1,N CC_ADRESSE
chaque commune dispose d’un hôtel de ville et un hôtel de ville correspond à plusieurs fois à la même commune.

AGENTS 1,N----instruire -----1,N COMMUNE 0,N-----localiser----- 0,N DIA
1,N----------------------------------------------------------------0,N
└-------------------------intervenir--------------------------------┘

un agent gère au moins une commune
une commune est gérée par au moins un agent
un agent n’intervient sur une DIA que si cette DIA concerne une commune qu’il gère (CIF).
(Je ne suis pas sûr d'avoir traduit cette notion dans mon MCD).

d) le sous-ensemble ‘suite donnée’*:
Les DIA enregistrées dans l’entité DIA sont analysées. Le processus est le suivant*:

soit la DIA est
. RETOURNEE (car non soumise à la procédure),
. PURGEE (car ne présente pas d’intérêt),
. PLUS ETUDIEE : (cette (ou ces) étude(s) approfondie(s) sont réalisée(s) successivement par un (ou des) partenaire(s). A l'issue, la DIA est soit :
- soit PURGE (si les études concluent à l'absence d'intérêt)
- soit PREEMPTEE (si une étude conclue à un intérêt)

sachant qu’avant d’être RETOURNEE, PURGE ou PREEMPTEE, une DIA peut être retirée (dans ce cas, la suite donnée est le RETRAIT).

Ci-dessous mon MCD sur ces 3 sous-ensembles fonctionnels. Je n’arrive pas à formaliser plus pour le moment le sous ensemble ‘suite donnée’.

En vous remerciant par avance pour vos avis.

[fcka0001]

Bonjour,

N'ayant pas eu de retour sur mon dernier post (je précise que ce dernier avait pour objet de synthétiser les posts antérieurs ).
Bien entendu ma base est très loin d'être terminée et je comprends à mes dépens toute la nécessité de bien poser les règles, ...

Du coup, j'en profite pour préciser que je m'interroge de plus en plus sur la nécessité de l'entité 'bien' (il me semble qu'elle vient compliquer les choses alors que la prise en compte de dénomination de vendeurs est très secondaire). Aussi, j'ai tendance à penser que les attributs de l'entité 'bien' sont à positionner dans l'entité 'dia'.

Concernant le reste, je ne sais pas si j'ai bien pris en compte les conseils d'Escartefigue...

merci pour vos conseils

[fcka0001]

bonjour,

suite à un échange hors forum, j'ai repris tout mon mcd.

Je remercie d'avance bien entendu pour vos nombreux avis, vos conseils éclairés, votre aide bienveillante et votre expertise ....


Le projet de base de données concerne la gestion des déclarations d’intention d’aliéner (DIA). Une DIA est un dossier remis aux communes par le vendeur d’un bien immobilier via les notaires le plus souvent. Les services de l’État instruisent les DIA des communes carencées au titre de l’art 55 de la SRU. L’objectif est de rechercher des biens pouvant être préempter afin de créer des logements locatifs sociaux.

R1) Les DIA déposées en mairie sont adressées puis sont enregistrées par nos soins. L’entité DIA contient les attributs de la vente (1 vente = 1 DIA*; 1 vente par lot donne lieu à plusieurs DIA).
Un bien est caractérisé par un seul type (maison ou appartement ou terrain ou etc).
DIA 1,1 -------- typer-------0,N type

R2) Un bien est cadastré (un bien peut être cadastré sur 1 ou plusieurs parcelles).
DIA 1,N ----lister----1,1 ref_cadas

R3) L’instruction des DIA est soumise à des délais. Les vendeurs (via les notaires) demandent un traitement accéléré. Il est nécessaire de comptabiliser le nombre d’intervention des notaires. Une DIA peut faire l’objet d’une seule intervention.
DIA 0,1----intervenir-----1,N notaire

R4) les notaires peuvent intervenir plusieurs fois sur des dia différentes.
notaire 1,N ---comptabiliser----1,N intervention

R5) Une DIA concerne un bien qui se situe sur une commune
Dia 1,1 ---- concerner-----0,N commune

R6) Chaque commune dispose d’un hôtel de ville lequel a une adresse postale (utile à connaître pour adresser les DIA instruites par courrier)
commune 1,1----adresser-----0,N adresse

R7) La liste des agents instruisant les DIA est notée dans l’entité agents.
Les agents sont en charge de commune pendant une période donnée et instruisent les dia de ces communes, plusieurs agents peuvent instruirent les dia d’une commune donnée.
Le but est d’appréhender le volume des dia par commune sur une période donnée et le volume qui en découle 'théoriquement' par agents.
commune 0,N ------charger------0,N agents

R8) Chaque agent instruit des dia et géo-référence sur Qgis par un point (pt) les dossiers réellement étudiées dans l’entité dia_pt. Un point correspond à une dia étudiée par un seul et unique agent.
(un agent peut instruire des dia dont il n’a pas la charge en théorie cf période de vacances)
agents 0,N--------instruit--------1,1 pt_dia

R9) Une dia enregistrée peut-être retirée par le vendeur à tout moment (cela annule la dia).
Dia---0,N --------retirer----0,N retrait

R10) Une dia enregistrée peut être retournée (car non soumise ou non recevable)
Dia---0,N --------retourner----0,N non_recevable

R11) Après étude , une dia enregistrée peut-être purgée (cela revient à renoncer à la Dia)
Dia---0,N --------decliner1----0,N renonce

R12) Après étude , une dia enregistrée peut-être soumise à étude approfondie 1 ou plusieurs partenaires
Dia---0,N --------saisir----0,N etude-approfondie
etude-approfondie 1,N ---mobiliser---1,N partenaire

R13) l’étude approfondie débouche soit sur une purge, soit sur une préemption
etude-approfondie 0,N ---preempter--0,N favorable
etude-approfondie 0,N ---decliner2----0,N renonce


Joyeuses fêtes

[escartefigue]

bonjour,

suite à un échange hors forum, j'ai repris tout mon mcd.

Je remercie d'avance bien entendu pour vos nombreux avis, vos conseils éclairés, votre aide bienveillante et votre expertise ....

Bonjour Fcka0001,
Désolé de n'être plus guère présent et de vous avoir ainsi abandonné au milieu du gué
Je suis très pris et le temps me manque.

Quelques remarques suite à votre dernier message :

R3) Une DIA peut faire l’objet d’une seule intervention.
DIA 0,1----intervenir-----1,N notaire

R4) les notaires peuvent intervenir plusieurs fois sur des dia différentes.
notaire 1,N ---comptabiliser----1,N intervention

Votre modèle perd le lien entre l'intervention et la DIA. Pour conserver ce lien il faut modéliser
DIA 0,1 --- relationx --- 1,1 INTERVENTION 1,1 --- relationy --- 0,n NOTAIRE
Le comptage des interventions pour un notaire sera du ressort du traitement, il ne nécessite pas d'association supplémentaire "comptabiliser" telle que vous l'avez modélisée.

R5) Une DIA concerne un bien qui se situe sur une commune
Dia 1,1 ---- concerner-----0,N commune

R6) Chaque commune dispose d’un hôtel de ville lequel a une adresse postale (utile à connaître pour adresser les DIA instruites par courrier)
commune 1,1----adresser-----0,N adresse

A priori, dans votre contexte, vous avez besoin de connaitre systématiquement la commune de rattachement de la DIA, commune pour laquelle vous avez besoin d'une et une seule adresse, celle de la mairie.
Si c'est bien le cas, vous pouvez simplifier en ne conservant qu'une seule entité-type qui aura pour attributs le code commune, son nom, et l'adresse de la mairie.

R7) La liste des agents instruisant les DIA est notée dans l’entité agents.
Les agents sont en charge de commune pendant une période donnée et instruisent les dia de ces communes, plusieurs agents peuvent instruirent les dia d’une commune donnée.
Le but est d’appréhender le volume des dia par commune sur une période donnée et le volume qui en découle 'théoriquement' par agents.
commune 0,N ------charger------0,N agents

Il est préférable de nommer les entité-type au singulier : l'ET "agent" plutôt qu'"agents", dont l'objet est de caractériser les attributs de toutes les occurrences d'agents
En l'état, votre modèle ne permet pas de connaitre les périodes d'affectation des agents. Il faut donc ajouter une entité-type date dans la relation pour permettre à un agent d'intervenir sur une même commune à des périodes différentes. On choisira lors de la génération du MLD de ne pas créer la table correspondante.

[fcka0001]

Bonjour,
Je reviens après une pause... Tout d’abord un grand . à Escartefigue pour ses précieux conseils.

Ci-dessous mes règles consolidées :

R1) Les DIA déposées en mairie sont adressées à notre service, puis sont enregistrées par nos soins. L’entité DIA contient les attributs de la vente (1 vente = 1 DIA; 1 vente par lot donne lieu à plusieurs DIA). Un bien est caractérisé par un seul type (maison ou appartement ou terrain ou etc).
DIA 1,1 -------- typer-------0,N type

R2) Un bien est cadastré (un bien peut être cadastré sur 1 ou plusieurs parcelles).
DIA 1,N --------lister-------1,1 ref_cadas

R3) Une DIA peut faire l’objet d’une seule ‘intervention’ d’un notaire.
DIA 0,1 ------intervenir ------ 1,1 INTERVENTION

R4) les notaires peuvent intervenir plusieurs fois sur des DIA différentes.
INTERVENTION 1,1 -------identifier ------- 0,n NOTAIRE

R5/R6) Une DIA concerne un bien qui se situe sur une commune
DIA 1,1 ---- concerner-----0,N commune
Je prends en compte le conseil de simplification: l’entité commune contient les communes de rattachement de chaque DIA et intègre désormais les attributs relatifs à l’adresse postale de l’hôtel de ville (je n’ai en effet besoin de connaître pour une commune donnée, qu’une et une seule adresse, celle de la mairie).

Concernant la règle R7, je souhaitais appréhender le volume des DIA par commune sur une période donnée et le volume qui en découle 'théoriquement' par agents….. Ma règle ne marchait pas.
J’ai peut-être trouvé une solution: les agents localisent les biens des DIA qu’ils instruisent et créent «*un point*» par DIA sur une (ou une des) parcelle(s) concernée(s), dans une couche géoréférencée stockée sur un serveur postgres.

Cette couche nommée POINT contient plusieurs attributs:
-le numéro de la DIA (noté par l’agent),
-le code insee, le libellé de la commune, l’année courante, le prénom et nom de l’agent, une clé composée du numéro de la DIA, du code insee et de l’année courante (remplies par un TRIGGER).

Cette couche permet de relier une DIA et l'instructeur (si l’année courante correspond à l’année de réception et si l’agent n’oublie pas de créer un point et s’il ne se trompe pas de numéro de DIA dans sa saisie)….

cela me permet d'écrire la règle suivante :
R7) une DIA est instruite par un agent qui créé un point (s’il n’oublie pas) et un point est créé par DIA (si l’agent ne l’oublie pas).
DIA 0,1 -------instruire-------------0,1 point


Je ne vais pas plus loin pour ce soir. Je vous remercie pour votre retour.

[escartefigue]

Bonjour Fcka0001,

Bonjour,
Je reviens après une pause... Tout d’abord un grand . à Escartefigue pour ses précieux conseils.

N'hésitez pas à marquer les réponses qui ont pu vous aider en utilisant le bouton prévu à cet effet, les encouragements sont toujours les bienvenus

R1) Les DIA déposées en mairie sont adressées à notre service, puis sont enregistrées par nos soins. L’entité DIA contient les attributs de la vente (1 vente = 1 DIA; 1 vente par lot donne lieu à plusieurs DIA).
Un bien est caractérisé par un seul type (maison ou appartement ou terrain ou etc).
DIA 1,1 -------- typer-------0,N type

Il est préférable d'évacuer les synonymes, DIA=BIEN donc choisissez l'un des deux termes et banissez l'autre, ça clarifie le propos.
Vous indiquerez uniquement cette synonymie dans votre dictionnaire de données.

R3) Une DIA peut faire l’objet d’une seule ‘intervention’ d’un notaire.
DIA 0,1 ------intervenir ------ 1,1 INTERVENTION

R4) les notaires peuvent intervenir plusieurs fois sur des DIA différentes.
INTERVENTION 1,1 -------identifier ------- 0,n NOTAIRE

Pour chaque association de votre modèle, il faut à minima deux règles de gestion : une pour chaque patte de la relation (soit 3 règles si association ternaire, éventuellement plus s'il existe des contraintes CIF)
De plus il ne faut mentionner que les types d'entité qui participent à la règle : dans R3 le notaire n'est pas concerné, c'est R4 qui intéresse les notaires
Par exemple
R3a : une DIA est concerné par au plus une intervention
R3b : une intervention concerne une et une seule DIA

R4a : une intervention est réalisée par un et un seul notaire
R4b : un notaire peut réaliser zéro à plusieurs interventions

C'est par transitivité qu'on en déduit qu'un notaire n'intervient qu'une seule fois sur une même DIA

R5/R6) Une DIA concerne un bien qui se situe sur une commune
DIA 1,1 ---- concerner-----0,N commune
Je prends en compte le conseil de simplification: l’entité commune contient les communes de rattachement de chaque DIA et intègre désormais les attributs relatifs à l’adresse postale de l’hôtel de ville (je n’ai en effet besoin de connaître pour une commune donnée, qu’une et une seule adresse, celle de la mairie).

Très bien, mais attention, la gestion des adresses est soumise à des normes, il est préférable de s'y conformer.
Pour la France, c'est la norme postale qu'on peut trouver en quelques clics sur la toile. Il s'agit de 6 lignes de 38 caractères maxi, dont la dernière consacrée au code postal (char(5)) et au libellé de la commune
Attention : utiliser le code INSEE de la commune comme identifiant primaire est dangereux. Ce code INSEE peut changer à tout moment (apparition de villes nouvelles, fusion de communes...). Or un identifiant primaire doit être stable.
Utilisez de préférence un identifiant technique attribué par le SGBD, le code INSEE sera un identifiant alternatif qui peut aussi être unique, mais non primaire

Concernant la règle R7, je souhaitais appréhender le volume des DIA par commune sur une période donnée et le volume qui en découle 'théoriquement' par agents….. Ma règle ne marchait pas.
J’ai peut-être trouvé une solution: les agents localisent les biens des DIA qu’ils instruisent et créent «*un point*» par DIA sur une (ou une des) parcelle(s) concernée(s), dans une couche géoréférencée stockée sur un serveur postgres.

Ce n'est pas clair pour moi. La phrase qui suit "J’ai peut-être trouvé une solution :" décrit elle ce qui correspond à la réalité ou bien une solution de contournement ?
Au niveau conceptuel, il s'agit de décrire fidèlement les relation entre les différents acteurs, pas de les modifier pour contourner les difficultés. Qu'en est-il ?

Cette couche nommée POINT contient plusieurs attributs:
-le numéro de la DIA (noté par l’agent),
-le code insee, le libellé de la commune, l’année courante, le prénom et nom de l’agent, une clé composée du numéro de la DIA, du code insee et de l’année courante (remplies par un TRIGGER).

Décrit ainsi, le "POINT" n'est pas un "individu" du modèle conceptuel, il ne sera donc pas modélisé en tant que type d'entité. Le point serait le résultat d'une action d'un agent. On se situe donc dans les traitements.
D'ailleurs vous avez eu des difficultés pour identifier cette pseudo entité-type, c'est la raison pour laquelle vous y avez mis des attributs qui n'ont rien à y faire : les identifiants d'autres entités-type tels que num_dia et INSEE
Supprimez cette pseudo entité-type de votre modèle

cela me permet d'écrire la règle suivante :
R7) une DIA est instruite par un agent qui créé un point (s’il n’oublie pas) et un point est créé par DIA (si l’agent ne l’oublie pas).
DIA 0,1 -------instruire-------------0,1 point

La relation serait plutôt la suivante
AGENT 0,n --- instuire --- 0,1 DIA
Ce qui correspond aux règles
Rxx : un agent peut instruire zéro à plusieurs DIA
Ryy : une DIA ne peut être instruite que par un seul agent
Attention aux changements éventuel d'instructeurs sur la durée : arrive-t-il qu'un agent prenne la succession d'un autre pour gérer une DIA (congé maladie, retraite...) ?