Discussion :

[Nosselrahc]

Bonjour, je souhaite modéliser la topographie française et étrangère (une partie seulement pour l'étrangère).
Les notions topographiques à gérer sont : pays, région, département, collectivité d'outre mer, commune et voie.
Ce modèle doit s'insérer dans un modèle plus large avec notamment plusieurs relations vers cette topographie.
Voici mon MCD qui s'appuie sur la notion d'héritage. Qu'en penser vous ? Y-a-t'il une meilleur solution pour gérer les appartenances entre les notions topo ? Y-a-t'il une meilleur solution que l'héritage pour gérer un identifiant unique ?
Merci d'avance de vos aides. Cordialement.

[SQLpro]

ATTENTION : le portage vers un autre pays n'est pas simple :
1) en Allemagne LANDERS
2) aux USA états, county (comté)

Pour la France il vous manque la notion de canton qui est un autre découpage du département différent de cela de la commune. Certains cantons ont plusieurs communes et certaines communes plusieurs canton….

Le mieux est d'opter pour un SGBDR contenant un SIG et de déduire les relation topologique par des requêtes….

SQL Server ou PostgreSQL font très bien cela !

A lire : https://blog.developpez.com/sqlpro/p...on_geographiqu

A +

[Nosselrahc]

C'est exacte pour la topo étrangère, mais le client doit la gérer à minima sans vraiment suivre les règles topographiques de chaque pays. Cela doit être précis seulement pour la France. Doit-je scinder les entités ? par exemples commune devient commune française, commune collectivité et commune étrangère. Ou spécialiser l'entité commune ?
Concernant votre lien vers la gestion d'un SIG, le client va s'étouffer ! Tout cela doit tendre vers un modèle le plus simple possible permettant de gérer les codes topo et quelques attributs.
A noter que c'est une réécriture d'une appli déjà existante. La BDD est Oracle.
A+

[escartefigue]

Bonjour,

Difficile de vous aider sur un modèle pour lequel aucune règle de gestion n'est fournie, aucun attribut n'est communiqué et sans explication autre...

Celà étant, vu que le modèle est international, il faut banaliser les noms des types d'entité (cf. la remarque de SQLPro) et identifier les différents types d'entité relativement à celles auxquelles elles appartiennent, par exemple [PAYS]0,n --- (appartenir) ---(1,1)[REGION]

[Nosselrahc]

Merci beaucoup de vos réponses rapides. Il n'y a pas de règle de gestion particulière. Cette partie du modèle stocke la liste des pays, des régions françaises, des collectivités d'outre mer, des communes françaises et des capitales étrangères et des voies françaises. Est stocké quelques attributs tel que les libellé par exemple. Concernant votre lien identifiant entre pays et région, cela va créé dans la table région un index composé de id_topo_région et id_topo_pays. Peut-être ai-je oublié de préciser que l'id_topo est un identifiant technique (auto-incrément par exemple). Cette id sera migré dans chaque entité topographique par l'héritage et sera unique avec la contrainte d'exclusion. Mon choix d'un id technique pour les entités topographique devrait simplifier les nombreuses relations du reste du modèle vers la topo. Est-ce propre ou existe-t-il une manière plus correcte de le faire ou générant un modèle logique plus accessible ? Merci encore.
A+

[escartefigue]

C'est que je ne vois pas en quoi l'héritage est requis dans votre contexte, d'où dans mon esprit des types d'entité autonomes mais identifiés les uns relativement aux autres le cas échéant.
Si vous donniez la liste des attributs du surtype "topographie" et de quelques sous-types ("pays" ou "région" par exemple) peut-être que je comprendrai mieux le contexte.