Discussion :

[fcka0001]

bonjour,

merci Escartefigue pour votre retour .

je consolide mes règles ci-dessous :


- REGLE 1 :

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.

Vous avez raison, j'utilise jusqu'ici indifféremment l'acronyme DIA pour désigner aussi bien un bien, un dossier, une procédure, etc. Je prends donc en compte votre remarque dans l'ensemble de mes règles en retenant le terme "bien":
R1) Un bien est caractérisé par un seul type (maison ou appartement ou terrain ou etc).
bien 1,1 -------- typer-------0,N type

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

- REGLES 3 et 4:

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

Je retiens votre formulation :
R3a : un bien est concerné par au plus une intervention ; R3b : une intervention concerne un et un seul bien
bien 0,1 ------intervenir ------ 1,1 INTERVENTION

R4a : une intervention est réalisée par un et un seul notaire; R4b : un notaire peut réaliser zéro à plusieurs interventions
INTERVENTION 1,1 -------identifier ------- 0,n NOTAIRE

Cette écriture permet effectivement de déduire qu’un notaire peut intervenir qu’une une et une seule fois sur l’instruction d’un bien.

ps.: j'adapte les attributs de l'entité 'Notaire' pour respecter les règles d’écriture de l’adresse postale française (cf norme évoquée ci-après).


- REGLE 5/6:

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

bien 1,1 ---- concerner-----0,N commune
je prends comme clé primaire un numéro à la place du code insee et je respecte, dans l'entité 'Commune', les règles d’écriture de l’adresse postale française (norme AFNOR NF Z 10-011).


- REGLE 7

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 ?

En fait, je me suis rendu compte que j'essayais de conceptualiser -avec difficulté- quelque chose de très imparfait*: l'affectation «*ex-ante*» des dossiers d'une commune donnée à un agent nominativement identifié, ne permet pas d'assurer que l'agent en question, a instruit réellement les dossiers (cf période de vacances, etc).

Je suis revenu à une description plus terre à terre et proche de la réalité : chaque dossier nécessite une localisation du bien concerné lors de l'instruction et cette localisation est matérialisée par la création d'un point dans une couche géoréférencée. Sur le principe, la récupération de l’identité de l’agent qui créé le point permet de savoir qui instruit le dossier. Cette couche présente par ailleurs un potentiel intéressant en termes de requêtes*: elle peut permettre de relier les points aux agents et les points aux informations de la base de données.

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

OK. je supprime l'entité 'Point' du MCD (ainsi que la règle7). Je garde cette couche et mon trigger pour la suite (le trigger est testé avec succès sur ces PC différents).

Attention aux changements éventuel d'instructeurs sur la durée : arrive-t-il qu'un agent prenne la succession d'une autre pour gérer une DIA (congé maladie, retraite...) ?

Sur le principe, l’existence de cette couche permet de ne plus se préoccuper de la répartition «*ex ante*» des dossiers et de la dénomination des agents, puisque les champs «*nom*» et «*prenom*» des agents sont associés automatiquement à la création du point. Je suis passé de l’ex ante à l’ex post.
Il me restera néanmoins à prendre le mieux possible les réserves : la non correspondance de l'année courante à l’année de réception; l'oubli de création d'un point; l'erreur d'écriture du numéro du dossier DIA. Je pense qu'il faudra admettre pour la couche point "quelques trous dans la raquette".

Je mets en ligne dès que possible la suite de mon projet.

[fcka0001]

bonjour,

je complète mon précédent post : l'entité notaire contient des attributs qui permettent d'identifier l'office notarial, il n'est pas utile de disposer d'une adresse postale complète comme dans l'entité commune.
ci-dessous la capture du mcd correspondant.

[fcka0001]

Bonjour,

Pour la 2ème partie, je souhaite modéliser les états possibles de l’analyse d’un bien, sachant que mon objectif est de pouvoir dire à l’instant T , quel est l’état d’avancement de la dite analyse.

La liste des états possibles est la suivante :
-analyse non engagée (cet état n'a pas d'attribut. On le déduit du fait que les autres états ne sont pas renseignés)
-bien retiré
-bien non soumis
-bien étudié (1 ou plusieurs études simultanées peuvent être menées. Elles conduisent soit à une préemption ou soit une purge)
-bien préempté
-bien purgé (étudié ou pas, il n’est pas préempté, ni retiré, ni non soumis)

Mes règles:

REGLE 8:
un bien peut faire l’objet de plusieurs études, chaque étude est menée par des partenaires différents (j’ajoute une propriété portée à l’association étudier) et chaque étude concerne un bien donné.

REGLE 9:
un bien peut être préempté et une préemption concerne un bien donné.

REGLE 10:
outre les règles 8 et 9, un bien peut être retiré ou renvoyé ou purgé et chaque état concerne un bien donné.

Merci d'avance pour vos avis sur cette partie .
ps.: je ne sais pas trop si je dois relier les entités 'Etude' et 'Préemption' à l’entité 'Etat' (et si comment).

[escartefigue]

Bonsoir fcka0001

Désolé pour cette réponse tardive, il y a eu de nombreux sujets ouverts sur la même période du coup votre fil est passé inaperçu

REGLE 8:
un bien peut faire l’objet de plusieurs études, chaque étude est menée par des partenaires différents (j’ajoute une propriété portée à l’association étudier) et chaque étude concerne un bien donné.

Que voulez-vous dire par "partenaire", les caractéristiques de ces partenaires sont elles à connaitre, faut il comprendre qu'une même étude est menée par plusieurs partenaires ou que chaque étude est réalisée par un et un seul partenaire ? A détailler

REGLE 9:
un bien peut être préempté et une préemption concerne un bien donné.

On a probablement affaire à une entité-type faible : la préemption n'existe que si le bien existe, vous pouvez donc l'identifier relativement au bien.
Ça se concrétise par des parenthèses autour des cardinalités coté préemption
selon le logiciel, la méthode utilisée pour y parvenir varie (case à cocher par exemple dans power AMC)

ps.: je ne sais pas trop si je dois relier les entités 'Etude' et 'Préemption' à l’entité 'Etat' (et si comment).

Si j'ai bien compris, l'état concerne le bien et non l'étude ou la préemption, auquel cas la réponse est non

[fcka0001]

Bonsoir,
Merci Escartefigue pour votre soutien.

J'essaie de répondre à vos questions

REGLE 8:

Que voulez-vous dire par "partenaire", les caractéristiques de ces partenaires sont elles à connaitre, faut il comprendre qu'une même étude est menée par plusieurs partenaires ou que chaque étude est réalisée par un et un seul partenaire ? A détailler

Les partenaires sont des services extérieurs que nous consultons pour compléter certaines analyses que nous réalisons, dans le but de décider de l’opportunité de préempter (ou pas) les biens.

Nos propres analyses constituent un 1er filtre vis-à-vis de nos partenaires.

Je précise que lorsque nous saisissons, à titre exceptionnel, plusieurs partenaires pour un même bien, chaque partenaire réalise «*son*» analyse de façon indépendante.

A l'issue, s'il n'est pas opportun de préempter le bien, on purge le dossier -autrement dit la mutation initiale envisagée par le vendeur se poursuit-.
Si au contraire, le partenaire conclut à l’opportunité de préempter, nous poursuivons la procédure dans ce sens. Dans le cas où plusieurs partenaires saisis pour l’analyse du même bien concluent chacun de leur côté à l’opportunité de préempter (ce cas n’est jamais arrivé), nous poursuivons la procédure de préemption avec le partenaire qui propose (de notre point de vue) le meilleur projet de création de logements.

Nous n'avons pas besoin de connaitre les caractéristiques de nos partenaires (uniquement le nom).

REGLE 9:

On a probablement affaire à une entité-type faible : la préemption n'existe que si le bien existe, vous pouvez donc l'identifier relativement au bien. Ça se concrétise par des parenthèses autour des cardinalités coté préemption

Oui, la préemption n'existe que si le bien existe, mais je ne suis pas sûr de comprendre la remarque car tous les biens existent.. qu’on les préempte ou pas.

Si j'ai bien compris, l'état concerne le bien et non l'étude ou la préemption, auquel cas la réponse est non

Ma «* liste des états possibles » désigne les stades ou issues possibles de l’instruction d’un dossier de déclaration d’intention d’aliéner (DIA) à l’instant t , sachant que chaque DIA porte sur la vente d’un bien.

Je déduis de votre remarque que je peux relier les entités 'Etude' et 'Préemption' à l’entité 'Etat'. Ai-je bien compris?? et si oui, comment formalise-t-on cela ?
(sachant que l'objectif serait de permettre de lister les biens ayant fait l'objet d'étude et d'une préemption par exemple ou encore les biens ayant fait l'objet d'une analyse et d'une purge ?

Merci pour votre retour.

[escartefigue]

REGLE 8:
Les partenaires sont des services extérieurs que nous consultons pour compléter certaines analyses que nous réalisons, dans le but de décider de l’opportunité de préempter (ou pas) les biens.
[. . .]
Nous n'avons pas besoin de connaitre les caractéristiques de nos partenaires (uniquement le nom).

Ces services exterieurs font certainement l'objet d'échanges par courriel, téléphone, courrier postal... autant d'éléments qu'il faut avoir à disposition et donc stocker quelque part, le nom ne suffit donc probablement pas, à confirmer.

D'après ce que je comprends, la règle 8 doit être précisée et éclatée en plusieurs règles
R008a : un bien peut être concerné par plusieurs études
R008b : une étude concerne un et un seul bien

R018a : une étude est menée par un et un seul partenaire
R018b : un partenaire peut mener plusieurs études

Il est important d'avoir une règle de gestion pour chaque sens de la relation, par exemple de bien vers étude (R008a) et de étude vers bien (R008b)
Comme il y a deux relations indépendantes, celle entre bien et étude d'une part et celle entre étude et partenaire d'autre part, il faut 2 x 2 règles

Nos propres analyses constituent un 1er filtre vis-à-vis de nos partenaires.
[. . .]
Je précise que lorsque nous saisissons, à titre exceptionnel, plusieurs partenaires pour un même bien, chaque partenaire réalise «*son*» analyse de façon indépendante.

Vos propres analyses sont elles de même nature que les études faites par les partenaires ? Si etude et analyse sont synonymes, il faut ne conserver qu'un seul terme pour éviter toute équivoque

REGLE 9: Oui, la préemption n'existe que si le bien existe, mais je ne suis pas sûr de comprendre la remarque car tous les biens existent.. qu’on les préempte ou pas.

Ma remarque concerne la préemption et non le bien. Identifier la préemption relativement au bien (c'est à dire que l'id primaire de la préemption sera id_bien + id_préemption) ne remet pas en cause l'existence du bien qu'il soit ou non préempté .

Ma «* liste des états possibles » désigne les stades ou issues possibles de l’instruction d’un dossier de déclaration d’intention d’aliéner (DIA) à l’instant t , sachant que chaque DIA porte sur la vente d’un bien.

Cette remarque n'est pas conforme à votre règle de gestion 10, dans la R010 l'état se rapporte au bien et ici il se rapporte au DIA
Il me semble avoir noté lors des échanges précédents qu'un bien pouvait faire l'objet de plusieurs DIA, il faut donc savoir si l'état est une propriété du bien ou du DIA et reformuler la règle 10 si nécessaire.

[fcka0001]

Bonjour,

Merci Escartefigue pour votre aide .

J'essaie de répondre à vos remarques.

REGLE 8:

Ces services extérieurs font certainement l'objet d'échanges par courriel, téléphone, courrier postal... autant d'éléments qu'il faut avoir à disposition et donc stocker quelque part, le nom ne suffit donc probablement pas, à confirmer.

Par ‘partenaires’, j'évoquais des 'services extérieurs' tel qu'un établissement public x ou un bailleur y.
Je n'ai pas intégré les emails et téléphone des contacts au sein de ces services car nous les connaissons par cœur. Mais vous avez raison. il suffirait qu'une nouvelle recrue prenne un poste dans notre bureau pour qu'elle ait besoin de ces éléments. J'intègre les attributs utiles dans le mcd.

D'après ce que je comprends, la règle 8 doit être précisée et éclatée en plusieurs règles
R008a : un bien peut être concerné par plusieurs études
R008b : une étude concerne un et un seul bien

R018a : une étude est menée par un et un seul partenaire
R018b : un partenaire peut mener plusieurs études

Il est important d'avoir une règle de gestion pour chaque sens de la relation, par exemple de bien vers étude (R008a) et de étude vers bien (R008b)
Comme il y a deux relations indépendantes, celle entre bien et étude d'une part et celle entre étude et partenaire d'autre part, il faut 2 x 2 règles

Je déduis des règles R008a, R008b, R018a, R018b qu'il faut créer une entité 'partenaire' (cf capture écran mcd actualisé) en pj.

Vos propres analyses sont elles de même nature que les études faites par les partenaires ? Si étude et analyse sont synonymes, il faut ne conserver qu'un seul terme pour éviter toute équivoque

Oui, elles sont de même nature. L’étude menée par les partenaires vérifient les éléments que nous communiquons (règles d’urbanisme, analyse foncière, analyse des pièces) et approfondit certains points (par exemple en réalisant une étude de capacité pour affiner nos premiers calculs, en analysant les servitudes, etc). Lors de cette phase, nous pouvons être amenés à recueillir (et à leur communiquer) des pièces complémentaires et/ou faire une visite du bien afin là aussi d'approfondir certains points.
J’emploierai désormais le seul mot ‘étude’.

REGLE 9:

Ma remarque concerne la préemption et non le bien. Identifier la préemption relativement au bien (c'est à dire que l'id primaire de la préemption sera id_bien + id_préemption) ne remet pas en cause l'existence du bien qu'il soit ou non préempté .

Oui c'est cela : si le bien n'est pas préempté, son existence n'est pas remise en cause. En effet, à partir du moment où un bien est enregistré dans l’entité ‘bien, le bien existe (il ne sort plus de la base de données).

S’il est préempté le bien existe; s’il n’est pas préempté, il existe aussi (mais a un autre «*état*»).
Le seul «*état*» non définitif , c’est l’étude menée chez les partenaires car son issue est soit la purge, soit la préemption, sachant qu'un retrait de la vente d'un bien ne peut pas intervenir après la purge ou la préemption.

REGLE 10:

Cette remarque n'est pas conforme à votre règle de gestion 10, dans la R010 l'état se rapporte au bien et ici il se rapporte au DIA

Autant pour moi (vous m’aviez demandé de choisir entre le terme 'bien' et l'acronyme 'DIA' et j'ai effectivement choisi dans les posts précédents le terme de «*bien*» car l'analyse porte sur le bien.

Il me semble avoir noté lors des échanges précédents qu'un bien pouvait faire l'objet de plusieurs DIA, il faut donc savoir si l'état est une propriété du bien ou du DIA et reformuler la règle 10 si nécessaire.

L'état découle de l'analyse du bien physique (maison, terrain, etc) et cette analyse affecte la DIA correspondante dans son traitement administratif.

Je rappelle que le seul cas où la vente d’un bien peut donner lieu au dépôt de plusieurs DIA, est celui où le bien est à cheval sur des communes différentes.

Dans ce cas, seules les DIA concernant les communes soumises à notre procédure sont enregistrées et sont instruites une à une d'un point de vue administratif.

En effet, si le bien n’a pas d’intérêt, nous purgerons 'toutes' les DIA relatives au bien.
Inversement, si le bien est préempté, nous ferons autant d’arrêté de préemption que de DIA concernées...

En résumé, ce cas particulier est traité administrativement comme le cas général.

Merci pour votre retour.

[fcka0001]

bonjour,

la capture d'écran de la 2nde partie de mon mcd n'est pas cohérente avec la règle 9 que j'ai notée le 23/03/2019, 17h22
ce n'est pas "bien 0,N ----préempter----1,1 preemption qu'il faut lire
mais "bien 0,1----préempter----1,1 preemption.

Du coup, les cardinalités de relation entre les entités 'bien' et 'etat' et 'bien' et 'preemtion' étant identique de côté l'entité 'bien', je simplifie mon mcd en fusionnant mes règles 9 et 10.
il en découle les règles suivantes :

REGLE 8 (8 et 18):

R008a : un bien peut être concerné par plusieurs études
R008b : une étude concerne un et un seul bien

R018a : une étude est menée par un et un seul partenaire
R018b : un partenaire peut mener plusieurs études

REGLE 9 (9+10):
un bien 'peut être' retiré ou renvoyé ou purgé ou préempté.
Inversement si un bien n'est rien de tout cela : cela signifie que le bien est en étude (soit en interne, soit chez l'un ou plusieurs de nos partenaires).

cette formalisation me permettra il me semble de lister plus facilement tous les biens et d'obtenir "facilement' les nombres de biens purgés, retirés, préemptés, retournés (et par différence avec le nombre de total de bien, le nombre de bien en étude).

ci-joint la 2dne partie de mon MCD actualisée

[escartefigue]

REGLE 9 (9+10):
un bien 'peut être' retiré ou renvoyé ou purgé ou préempté.
Inversement si un bien n'est rien de tout cela : cela signifie que le bien est en étude (soit en interne, soit chez l'un ou plusieurs de nos partenaires).

cette formalisation me permettra il me semble de lister plus facilement tous les biens et d'obtenir "facilement' les nombres de biens purgés, retirés, préemptés, retournés (et par différence avec le nombre de total de bien, le nombre de bien en étude).

Je suppose qu'un bien peut changer d'état, si vous devez en conserver l'historique, il faut une relation à date
De plus, il ne faut pas un booléen par état possible, mais une seule colonne dont la valeur permettra de connaitre l'état (sauf si un même bien peut avoir plusieurs états à un instant "t", peu probable...)

[fcka0001]

Bonjour,
Merci Escartefigue pour votre retour.

Je réagis rapidement à vos observations.

Je suppose qu'un bien peut changer d'état....

. Comme j'ai séparé la partie "étude" (partenaire) de la partie 'état' (retrait, retourné, préempté, purgé), l'état du bien (partie 'etat') ne change pas. Dans ma construction, je peux lister d'une part les biens en "étude" (chez nos partenaires) et d'autre part les biens dont on connait la suite donnée (partie 'état'). Les biens n'apparaissant dans aucune des listes sont des biens enregistrés en cours d'étude interne.

...., si vous devez en conserver l'historique, il faut une relation à date

Il est en effet important de conserver la date à laquelle le bien est déclaré dans un état ou un autre.

Pour prendre en compte vos remarques, j'intègre une propriété portée 'date' à l'association 'suite_donner'.
Je supprime les booléens de l'entité 'etat' et je créé une nouvelle entité 'type_état'.
J'en profite pour revoir les cardinalités de certaines associations.

Les règles de gestion deviennent :

-R9a : un bien peut avoir ou pas une suite donnée (s'il n'a pas de suite donnée cela signifie que le bien est en étude.
-R9b: un état donné concerne 0 ou plusieurs biens.

bien 0,1----suite_donner---0,n etat.

-R9c: l'état d'un bien appartient forcément à un type donné (la liste des possibilités n'est pas évolutive: purgé, retourné, retiré, préempté).
-R9d: un type d'état désigne 0 ou plusieurs états.

etat 1,1-----typer_etat-----1,n type_etat

ci-joint la capture du mcd ainsi modifié.

Si ce qui précède est correct, je présenterai dans mon prochain post une synthèse générale de mes règles et de mon mcd.
Je pourrai ainsi passer à la phase suivante .

[fcka0001]

Bonjour à tous,

Ci-dessous une consolidation de tous les posts précédents sur laquelle je vous remercie de bien vouloir me faire part de vos remarques et conseils tant que les règles de gestion de mon MCD que sur la façon d'amender le MLD qui en découle (je joins une capture brute). :

Je rappelle rapidement mon sujet:

mon projet de base de données concerne l’instruction de dossiers liés à la vente de biens immobiliers en vue de la mise en œuvre d’une politique publique liée à l’habitat.

La vente d’un bien immobilier donne lieu au dépôt d’un dossier, suivi d’une instruction qui peut engendrer une ou plusieurs études, mais qui au-delà, débouche sur*:
-le renvoi du dossier (le bien n’est pas soumis à la procédure),
- ou le retrait du dossier (le bien n’est plus à la vente),
- ou la préemption du bien (le bien a un intérêt du point de vue de l’objectif de la politique publique),
- ou la purge du dossier (le bien n’a pas d’intérêt du point de vue de l’objectif de la politique publique).

‘Bien’ et ‘dossier’ sont des termes intimement liés car le dossier -en l’occurrence nommé «*déclaration d’intention d’aliéner*»- désigne un bien faisaint référence forcément à un dossier.

Dans la suite, je retiens le terme de ‘bien’.

Ci-dessous les règles de gestion:

- REGLE 1 : caractéristiques du bien
Les caractéristiques du bien sont insérées dans l’entité ‘bien’ et un bien se caractérise par un seul type (maison ou appartement ou terrain ou etc).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 1,1 -------- typer-------0,N type

- REGLE 2 : localisation du bien
Un bien est nécessairement situé au sein d’une commune et une commune peut contenir aucun ou plusieurs biens (si un bien est à cheval sur plusieurs communes, il y a un dossier par commune et la procédure de chaque dossier est indépendante)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 1,1 ---- concerner-----0,N commune

-REGLE 3 : référence(s) cadastrale(s) du bien
Un bien est cadastré sur 1 ou plusieurs parcelles.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 1,N --------lister-------1,1 ref_cadas

-REGLE 4: transmission à la préf
Les communes réceptionnent les dossiers et doivent les communiquer à la préfecture. La date de réception en préf «*doit pouvoir être*» conservée.

Une date donnée correspond à la réception d’un ou plusieurs biens (en l’occurrence dossiers).
Inversement, un bien (dossier en l’occurrence) peut-être réceptionné qu’à une date donnée.
La cardinalité minimale à zéro permet de ne pas imposer d’enregistrer la date de réception.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

date_pref 1,N ------réceptionner------0,1 bien

- REGLES 5 et 6 : interventions des notaires
Pour X raisons, les notaires peuvent être amenés à solliciter une accélération de la procédure d’instruction concernant un bien donné. Il est nécessaire de conserver l’historique de ce type d’intervention.

R3a : un bien est concerné par au plus une intervention ;
R3b : une intervention concerne un et un seul bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 0,1 ------intervenir ------ 1,1 INTERVENTION

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

intervention 1,1 -------identifier ------- 0,N notaire

REGLES 7 et 8 : suivi des études

R6a : un bien peut être concerné au plus par plusieurs études.
R6b : une étude concerne un et un seul bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien  0,N -------étudier-------1,1 etude

R7a : une étude est menée par un et un seul partenaire.
R7b : un partenaire peut mener plusieurs études.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

étude 1,1 ------réaliser-------1,N partenaire

REGLE 9 : suite donnée à l’instruction d’un bien
Un bien 'peut être' retiré ou renvoyé ou purgé ou préempté et si un bien n'est rien de tout cela : cela signifie que le bien est en phase d’étude (soit en interne, soit chez l'un ou plusieurs de nos partenaires).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 0,1----- suite_donner-----0,1 état

J’apporte quelques précisions:

- Les partenaires sont des services extérieurs avec qui nous travaillons. Ils n’auront aucun accès à la bdd (cela constitue une contrainte mais je n'ai aucun moyen de la contourner).
Dans la pratique nous leurs communiquerons des informations extraites de notre bdd et leurs infos devront impérativement être intégrées à notre bdd (les champs correspondants sont notées en "bleu").

-j’ai prévu d’utiliser plusieurs variables calculées (concernant les dates/délai) et plusieurs données géométriques en interaction avec la bdd via des triggers (ex géométrie des parcelles).

[escartefigue]

Bonjour,

C'est une bonne chose de récapituler ce qui est éparpillé dans les différents échanges, mais certaines règles sont incomplètes, par exemple la règle 1 ci-dessous est à compléter pour expliquer ce qu'il en est de type vers bien et justifier ainsi le "0,n" coté type

- REGLE 1 : caractéristiques du bien
Les caractéristiques du bien sont insérées dans l’entité ‘bien’ et un bien se caractérise par un seul type (maison ou appartement ou terrain ou etc).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 1,1 -------- typer-------0,N type

Et là c'est plus embétant, vous parlez de règles 5 et 6, mais vous les numérotez R3a et R3b voila qui va semer la confusion dans les échanges...

- REGLES 5 et 6 : interventions des notaires
Pour X raisons, les notaires peuvent être amenés à solliciter une accélération de la procédure d’instruction concernant un bien donné. Il est nécessaire de conserver l’historique de ce type d’intervention.

R3a : un bien est concerné par au plus une intervention ;
R3b : une intervention concerne un et un seul bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 0,1 ------intervenir ------ 1,1 INTERVENTION

Donc la démarche est la bonne, mais les finitions sont à revoir


Au sujet de cette remarque :

- Les partenaires sont des services extérieurs avec qui nous travaillons. Ils n’auront aucun accès à la bdd (cela constitue une contrainte mais je n'ai aucun moyen de la contourner).
Dans la pratique nous leurs communiquerons des informations extraites de notre bdd et leurs infos devront impérativement être intégrées à notre bdd (les champs correspondants sont notées en "bleu").

Pas d'impact sur la modélisation, plusieurs solutions possibles en fonction du besoin.


Et concernant celle-ci :

-j’ai prévu d’utiliser plusieurs variables calculées (concernant les dates/délai) et plusieurs données géométriques en interaction avec la bdd via des triggers (ex géométrie des parcelles).

Il faut stocker les coordonnées géométriques dans la BDD

[fcka0001]

Bonjour et merci Escartefigues pour votre retour.

Je réponds point par point (je ferai un nouveau récapitulatif général par la suite):

1er remarque :

certaines règles sont incomplètes, par exemple la règle 1 ...

Je complète la règle 1 : caractéristiques du bien
Les caractéristiques du bien sont insérées dans l’entité ‘bien’ et un bien se caractérise par un seul type (maison ou appartement ou terrain ou etc).
Un type de bien (liste prédéfinie) peut décrire 0, 1 ou plusieurs biens. La cardinalité minimale de 0 permet d'avoir des types de biens sans bien correspondant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bien 1,1 -------- typer-------0,N type

2nde remarque :

Et là c'est plus embêtant, vous parlez de règles 5 et 6, mais vous les numérotez R3a et R3b voila qui va semer la confusion dans les échanges...

J'ai omis de mettre en cohérence certains n° de règles à l'intérieur des paragraphes règles 5 et 6 (interventions des notaires) et 7 et 8 (suivi des études).
Je corrige dans le prochain récapitulatif général.

3ème remarque:
concernant ma remarque " Les partenaires sont des services extérieurs ...", vous indiquez

Pas d'impact sur la modélisation, plusieurs solutions possibles en fonction du besoin.

Pourriez-vous s'il vous plait m'indiquer de façon synthétique les solutions possibles dans mon cas de figure (afin que je creuse la question) ?
Je précise notre besoin :
Nos partenaires n'ont pas d'accès à notre base de données, ni à aucun autre moyen d'échange en dehors de la messagerie électronique (il n'y aucune évolution envisageable sur ce point).
Pour l'heure, nos échanges avec les partenaires se traduisent par une incrémentation d'un fichier calc (chaque nouvelle ligne correspond à une nouvelle consultation et chaque ligne contient des cellules que les partenaires complètent).
Le nom du fichier calc contient le nom du partenaire et la date (en pratique la date nécessite d'être indicée quand il y a plusieurs échanges par jour).
Nous devrons être en mesure d'extraire les informations utiles et d'intégrer les informations recueillies.
La commande impose que la solution "soit pratique et rapide à l'usage" (bref le plus automatique possible).

4ème remarque:
concernant ma remarque " j’ai prévu d’utiliser plusieurs variables calculées ...", vous indiquez

Il faut stocker les coordonnées géométriques dans la BDD

Sur ce point, j'ai besoin de précisions car j'envisage 2 géométries :
Les points :
Un instructeur aura la possibilité de créer dans une couche géoréférencée un localisant du bien étudié.
Il s'agit d'un traitement extérieur à la bdd.
Cette possibilité apporte "un plus" car le trigger associé à la couche permet de récupérer l'identité de celui qui a créé le point et de relier qui plus est le point aux informations de la bdd...
L'absence du point (oubli, ...) n'interfèrera pas sur le fonctionnement de la bdd. "Il est ici accepter d'avoir quelques trous dans la raquette".
Suite à notre échange (cf votre post 11/03/2019, 13h43) , je n'ai pas fait apparaître dans le MCD l'entité liée au point. Confirmez-vous?

Les polygones:
La saisie des références cadastrales permettra via un trigger de récupérer à 99% la géométrie de la parcelles (d'après notre expérience, il y aura 1% des parcelles sans géométrie).
Les géométries récupérées devront effectivement être stockées. J'ai prévu de les stocker dans "ref_cadas" afin de permettre de faire des tests -via des triggers en cours d'écriture- de surface, d'intersection, etc
Le résultat des tests devra être aussi stocké (pour partie dans ref_cadas et pour partie dans bien).
Ces attributs (géométrie, résultats tests 1, ...) doivent-ils aussi apparaître au stade du MCD ?

Merci

[escartefigue]

3ème remarque:
concernant ma remarque " Les partenaires sont des services extérieurs ...", vous indiquez
Pourriez-vous s'il vous plait m'indiquer de façon synthétique les solutions possibles dans mon cas de figure (afin que je creuse la question) ?
Je précise notre besoin :
Nos partenaires n'ont pas d'accès à notre base de données, ni à aucun autre moyen d'échange en dehors de la messagerie électronique (il n'y aucune évolution envisageable sur ce point).
Pour l'heure, nos échanges avec les partenaires se traduisent par une incrémentation d'un fichier calc (chaque nouvelle ligne correspond à une nouvelle consultation et chaque ligne contient des cellules que les partenaires complètent).
Le nom du fichier calc contient le nom du partenaire et la date (en pratique la date nécessite d'être indicée quand il y a plusieurs échanges par jour).
Nous devrons être en mesure d'extraire les informations utiles et d'intégrer les informations recueillies.
La commande impose que la solution "soit pratique et rapide à l'usage" (bref le plus automatique possible).

Donc, vous faites une extraction des données de votre BDD sous forme d'un tableur horodaté, ce tableur est envoyé par courriel au prestataire qui le complète et vous le renvoie par courriel c'est bien ça ? Comme mentionné, pas d'impact sur le MCD, par contre, en terme de traitement, c'est pas top (risque d'erreur, contrôles difficiles...)

4ème remarque:
concernant ma remarque " j’ai prévu d’utiliser plusieurs variables calculées ...", vous indiquez
Sur ce point, j'ai besoin de précisions car j'envisage 2 géométries :

Je mentionnais seulement que vous n'aviez pas modélisé les attributs de type geometry dans votre modèle
N'ayant pas d'expérience personnelle sur les BDD géographiques, je ne m'étendrai pas plus sur ce chapitre