Discussion :

[kap]

Bonjour,

Je dois mettre en place une base de données d'agglomérations. J'ai quelques notions en BDD mais je ne suis pas un expert. J'aurai besoin de votre avis sur mon modèle conceptuel de données. Voici le contexte :

j'ai différent niveaux administratifs de localisation géographique (continents, subcontinents, countries, regions, subregions, counties et subcounties) liés entre eux par une relation père-fils. Dans la réalité, les agglomérations appartiennent à une instance de chaque niveau administratif. Cependant dans ma bdd l'ensemble de ces données ne sera pas disponible. Seuls les niveaux continents, subcontinents et countries seront renseignés pour chaque agglomération. Pour les autres niveaux administratifs ca va être très variable d'une agglomération à une autre... J'ai donc pensé à mettre en place ce type de modèle (cf pièce jointe). Qu'en pensez-vous? Cela vous semble-t-il correct voire pertinent? Que puis-je améliorer?

Merci d'avance pour vos retours

ps : évidemment j'écris mon message la veille de partir en vacances donc je ne serai pas forcément très réactif à vos messages

[CinePhil]

Remarque préalable :
Tu mélanges le singulier et le pluriel dans les noms des entités. Normalement, une entité s'écrit au singulier.

Passons au schéma...

On va travailler avec un exemple : ma ville, Toulouse.

J'ai donc une localUnit appelée Toulouse qui is included in une country appelée France, laquelle est incluse dans un subcontinent appelé ?
- Europe inclus dans quel continent ? Eurasie ?
- Ou bien le continent est-il l'Europe sans subcontinent ?

Déjà sur ce point, la hiérarchie continent => subcontinent ne me semble pas systématique.

Revenons à Toulouse... Le modèle ne m'interdit pas de dire que Toulouse est capitale de l'Espagne, qu'elle est incluse dans la région Bavière (en Allemagne donc), qu'elle est capitale d'une autre région d'un autre pays...

Il faudrait au moins mettre une contrainte d'inclusion entre les associations 'is included in' et 'is capital of'.
Ensuite, l'exemple ci-dessus montre qu'il manque aussi d'autres hiérarchies :
- Une région est incluse dans un pays ;
- Une région peut avoir des sous-régions (cas des régions et des départements français) ;
- Une county est incluse dans une région, voire dans une subregion...

A noter qu'en France, c'est déjà pas mal compliqué.
Il existe la hiérarchie Commune ==> Département ==> Région ==> Pays (France)
Il existe aussi la hiérarchie Canton ==> Département ==> |

Mais un canton peut regrouper plusieurs communes et il peut y avoir plusieurs cantons dans une commune.

Il existe des arrondissements dans certaines villes.

Il peut y avoir des communautés de communes. A voir si certaines peuvent être à cheval sur plusieurs départements ou non.

Au fil du temps, certaines communes fusionnent ou se séparent. Idem au niveau département (Corse : 20 ==> 2A et 2B)

J'imagine que dans d'autres pays, il doit y avoir d'autres subtilités.

A toi de voir quel degré de précision tu souhaites avoir mais ton modèle ne doit pas permettre des incohérences comme celles que j'ai soulevées plus haut (Toulouse en Bavière et capitale de l'Espagne).

Tu utilises visiblement AnalyseSI pour faire ton MCD qui est malheureusement limité aux entités, associations et cardinalités. Je ne crois pas que les contraintes y soient représentables. Il faudra te tourner vers un autre modeleur ou triturer ça en image avec un logiciel de dessin.

Bon courage !

[kap]

Merci pour la rapidité de la réponse !!

Tu mélanges le singulier et le pluriel dans les noms des entités. Normalement, une entité s'écrit au singulier.

Petites erreurs d'inattention , je préfère mettre tout au pluriel parcequ'ensuite le logiciel (AnalyseSI) me génère le MLD et le SQL et je préfère avoir les tables au pluriel

Déjà sur ce point, la hiérarchie continent => subcontinent ne me semble pas systématique.

Alors pour le découpage en continent et sous-continent, je ne peux pas le remettre en question... Ceci m'est imposé. Le découpage a été réalisé par un chercheur-géographe. Pour l'exemple de l'Europe, j'ai les sous-continents Europe du Nord, Europe de l'Ouest, Europe de l'Est, Ex-Urss Caucase et Ex-Urss Europe. A ce niveau les hiérarchies continent => subcontinent => country sont systématiques et connues.

Ensuite, l'exemple ci-dessus montre qu'il manque aussi d'autres hiérarchies :
- Une région est incluse dans un pays ;
- Une région peut avoir des sous-régions (cas des régions et des départements français) ;
- Une county est incluse dans une région, voire dans une subregion...

En fait j'avais fait un premier jet avec toutes ces hiérarchies et j'avais relié mes localunits au niveau administratif subcounty. Donc à partir du subcounty on pouvait tout remonter jusqu'au continent. Le problème c'est que dans les données que je vais avoir, je ne pense pas que je vais automatiquement avoir ces relations... Autant au niveau countries, subcontinents et continents je peux "facilement" le faire moi-même, autant pour les niveaux inférieurs ca va être fastidieux à l'échelle mondiale...

Le modèle ne m'interdit pas de dire que Toulouse est capitale de l'Espagne, qu'elle est incluse dans la région Bavière

Effectivement... les capitales sont très mal gérées et je sèche un peu la-dessus Je vais me repencher la-dessus...

Il existe des arrondissements dans certaines villes.

Le niveau le plus bas que j'ai à considérer est l'agglomération, je n'ai pas besoin des arrondissements.

Tu utilises visiblement AnalyseSI pour faire ton MCD qui est malheureusement limité aux entités, associations et cardinalités. Je ne crois pas que les contraintes y soient représentables. Il faudra te tourner vers un autre modeleur

C'est effectivement le cas, je vais chercher un autre modeleur...

Merci pour ces premières remarques

[CinePhil]

Sinon, il y a une autre manière de procéder qui a été employée dans un logiciel de l'INRA où je travaillais avant.
Ce n'est peut-être pas très propre au niveau modèle de données mais ça marche.

Nous avions une table de hiérarchie des niveaux géographiques.

Ci-dessous le code MySQL.

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
-- 
-- Structure de la table 'fondscartes'
-- 
 
CREATE TABLE fondscartes (
  FondIndex int(10) unsigned NOT NULL auto_increment,
  FondNumOrdre char(2) NOT NULL default '',
  FondLibelle varchar(100) NOT NULL default '',
  FondNivGeo varchar(20) NOT NULL default '',
  FondNomTable varchar(100) NOT NULL default '',
  FondType varchar(10) NOT NULL default '',
  FondProfondeur varchar(5) default NULL,
  FondHierarchique binary(1) NOT NULL default '1',
  FondMaillage binary(1) NOT NULL default '1',
  FondProgramme varchar(50) default NULL,
  PRIMARY KEY  (FondIndex),
  UNIQUE KEY I_FondNivGeo (FondNivGeo),
  KEY I_FondNumOrdre (FondNumOrdre),
  KEY I_FondLibelle (FondLibelle),
  KEY I_FondProfondeur (FondProfondeur)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Fonds de cartes disponibles avec leur hiérarchie';
 
-- 
-- Contenu de la table 'fondscartes'
-- 
 
INSERT INTO fondscartes (FondIndex, FondNumOrdre, FondLibelle, FondNivGeo, FondNomTable, FondType, FondProfondeur, FondHierarchique, FondMaillage, FondProgramme) VALUES 
(1, '1', 'canton', 'c', 'mifc', 'corr', '30', 0x31, 0x31, ''),
(2, '3', 'code 27 initial', 'c27a', 'mifc27a', 'corr', '20', 0x31, 0x30, ''),
(3, '11', 'grande région', 'gr', 'mifgr', 'corr', '80', 0x31, 0x30, ''),
(4, '10', 'région', 'r', 'mifr', 'corr', '70', 0x31, 0x31, ''),
(5, '5', 'arrondissement', 'a', 'mifa', 'corr', '40', 0x31, 0x30, ''),
(6, '8', 'département', 'd', 'mifd', 'corr', '60', 0x31, 0x31, ''),
(7, '0', 'commune', 'm', 'mifm', 'base', '10', 0x31, 0x31, ''),
(8, '4', 'code 27', 'c27', 'mifc27', 'calc', '25', 0x31, 0x31, 'fdsinfos_c27.php'),
(9, '17', 'CAD', 'cad', 'mifcad', 'corr', '55', 0x30, 0x31, ''),
(10, '19', 'PRA', 'pra', 'mifpra', 'corr', '55', 0x30, 0x31, ''),
(11, '21', 'PRA Département', 'prad', 'mifprad', 'corr', '50', 0x30, 0x31, ''),
(12, '23', 'Parc Naturel', 'pnr', 'mifpnr', 'corr', '55', 0x30, 0x31, ''),
(13, '25', 'PNR Département', 'pnrdep', 'mifpnrdep', 'corr', '50', 0x30, 0x31, ''),
(14, '27', 'Pays', 'pays', 'mifpays', 'corr', '55', 0x30, 0x31, ''),
(15, '29', 'INAT Département', 'inatdep', 'mifinatdep', 'corr', '50', 0x30, 0x31, ''),
(16, '31', 'DOCUP Département', 'docupdep', 'mifdocupdep', 'corr', '50', 0x30, 0x31, ''),
(17, '33', 'Bassin de vie', 'bv', 'mifbv', 'corr', '55', 0x30, 0x31, ''),
(18, '35', 'Zone emploi', 'ze', 'mifze', 'corr', '55', 0x30, 0x31, ''),
(19, '20', 'France', 'f', 'miff', 'corr', '90', 0x31, 0x31, ''),
(20, '37', 'Zone défavorisée', 'def', 'mifdef', 'corr', '55', 0x30, 0x31, ''),
(21, '39', 'bassin de vie Etic', 'bv2', 'mifbv2', 'corr', '55', 0x30, 0x31, ''),
(22, '45', 'Zone Vulnérable reg', 'zvr', 'mifzvr', 'corr', '65', 0x30, 0x31, ''),
(23, '43', 'Zone Vulnérable depa', 'zvd', 'mifzvd', 'corr', '50', 0x30, 0x31, ''),
(24, '47', 'Unités Urbaines', 'ua', 'mifua', 'corr', '55', 0x30, 0x31, ''),
(25, '49', 'SPIDE', 'spi', 'mifspi', 'corr', '45', 0x30, 0x31, ''),
(26, '51', 'bassin versant sud du Gers', 'bvgers', 'mifbvgers', 'corr', '45', 0x30, 0x31, ''),
(27, '53', 'cte aude tarn', 'cat', 'mifcat', 'corr', '55', 0x30, 0x31, ''),
(28, '55', 'INAT4 Département', 'inat4dep', 'mifinat4dep', 'corr', '50', 0x30, 0x31, ''),
(29, '57', 'Massif', 'massif', 'mifmassif', 'corr', '50', 0x30, 0x31, ''),
(30, '59', 'inter_région forestière', 'irf', 'mifirf', 'corr', '80', 0x31, 0x30, ''),
(31, '61', 'bassins laitiers', 'bl', 'mifbl', 'corr', '60', 0x31, 0x30, ''),
(32, '63', 'littoral', 'litto', 'miflitto', 'corr', '', 0x31, 0x31, ''),
(33, '65', 'Zone laitière', 'zl', 'mifzl', 'corr', '55', 0x30, 0x31, '');

On y voit, grâce à la colonne FondProfondeur, la description de la hiérarchie
Commune (10) ==> Département (60) ==> Région (70) ==> Grande région (80) ==> France (90)

Il s'agissait de pouvoir agréger des données communales au niveau cantonal, départemental, régional... ou dans un autre découpage tel que les petites régions agricoles (PRA).

[kap]

Bonne année à tous pour commencer

Je reviens à la charge avec mon modèle... Finalement j'ai changé de logiciel de modélisation, j'ai opté pour MySQL Workbench. Comme je suis un peu parti dans plein de directions à la fois dans mon premier post, je vais reprendre depuis le début et on va complexifier le modèle au fur et à mesure...
Je dois modéliser des agglomérations. Leur localisation est représentée par différents niveaux "administratifs" (continents, sous-continents, ..., subcounties). Ces niveaux sont hiérarchisés entre eux. Au niveau application derrière, mes requêtes devront toujours me renvoyer des agglomérations. Les niveaux administratifs seront utilisés comme critère de recherche (ex: sélectionner les agglos de l'Europe de l'Est).
Voici donc mon nouveau modèle (cf pièce jointe). Est-ce que c'est une bonne base de départ d'après vous?

[CinePhil]

Ton modèle suppose que toute entité géographique s'inscrit dans une autre, jusqu'au continent.

Tout dépend donc de ce que tu mets derrière ces appellations anglaises.
Si subregions, conties ou subcounties sont censées accueillir les cantons administratifs français et localunit les communes françaises, ça ne fonctionnera pas systématiquement parce qu'il peut exister plusieurs cantons à l'intérieur d'une seule commune.

A toi de déterminer ce que tu vas mettre dans tes tables.

Si je prends Toulouse :
- Continent = Europe
- Subcontinent = Europe de l'ouest ?
- Country = France
- Region = Midi-Pyrénées
- Subregion = Haute-Garonne
- County = ?
- Subcounty = Grand Toulouse ?
- Localunit = Toulouse

[kap]

A toi de déterminer ce que tu vas mettre dans tes tables.

En fait c'est plutôt à mes géographes de faire ça mais quand je leur pose la question, ils répondent à côté et je suis pas plus avancé
Les niveaux administratifs "continent", "subcontinent" et country sont bien définis quelque soit les pays... Après de ce que j'ai compris, la totalité des niveaux inférieurs n'est pas utilisé pour tous les pays. Ils m'ont fixé un nombre précis de niveaux mais je pense plus que c'est parce qu'ils avaient commencé à faire une feuille excel et donc ils ont juste compté le nombre de cases... Du coup je vais peut être plus me rapprocher d un truc du style : piece jointe

[CinePhil]

Voilà une solution qui me semble plus jouable pour prendre en compte tous les cas de figure.

Le seul "défaut" est que tu vas être obligé d'enregistrer toutes les correspondances pour une localunit, même si les localisations peuvent être hiérarchisées.

En clair, tu vas être obligé d'enregistrer les correspondances (Toulouse, Haute-Garonne) et (Toulouse, Midi-Pyrénées) alors que Haute-Garonne est incluse dans Midi-Pyrénées.

En faisant une table de hiérarchisation des niveaux comme ce que j'ai donné précédemment, tu peux peut-être éviter cette "redondance" d'information.

En fait ce nouveau modèle que tu proposes n'empèche nullement Toulouse d'être affectée à la Bavière ou à la Galice. Il manque donc encore des relations entre les localisations et les countries pour contrôler la cohérence des données.

[kap]

Salut !!

J'ai apporté quelques modifications pour ne pas perdre les inclusions des niveaux inférieurs (cf pièce jointe).

Problèmes qui se posent toujours :

• l'entité administratifzone est réflexive. Comment modéliserle fait que l'attribut zone_sup doit référencé un objet du même type mais de niveau supérieur?
• je ne suis pas sur que la gestion du contrôle de cohérence pour les pays soit correcte..

Voila, en tout cas j'ai l'impression d'avancer, donc merci à toi pour toute cette aide

[CinePhil]

Si j'interprète correctement ton schéma :
- Une supzone_country est dans une country et dans une administrativezone ;
- Une supzone_country peut avoir des localunits

Par contre j'ai l'impression que tu as mis l'identifiant de supzone_country en tant que clé étrangère dans administrativezone alors j'ai du mal à comprendre.

Tu pourrais donner un exemple concret Français de ce que tu mets dans chaque table ?

[kap]

Alors pour le petit exemple, on va prendre Toulouse

countries
FRA ; France ; ...

Localunit
1 ; Toulouse ; FRA

administratifzone
a ; Haute Garonne ; niveau n ; b
b ; Midi-Pyrhenees ; niveau n+1 ; null

infzone_localunit
1 ; a

supzone_country
b ; FRA

J'espère que ça t'éclaire un peu plus

Par contre j'ai l'impression que tu as mis l'identifiant de supzone_country en tant que clé étrangère dans administrativezone alors j'ai du mal à comprendre.

En fait c'est pour assurer le fait qu'une supzone n'apparaisse qu'une seule fois dans supzone_country. Je ne veux associer qu un seul pays a une supzone.... Bon j'ai changé et j'ai mis une relation 1-1 au lieu d'une relation 1-N

[CinePhil]

countries
FRA ; France ; ...

Localunit
1 ; Toulouse ; FRA

Donc la colonne country dans la table localunit est une clé étrangère référençant la country à laquelle appartient la localunit. Il manque une relation dans ton schéma entre countries et localunits, sauf si tu utilises une identification relative (iditenfying relationship) entre localunit et supzone_country et entre supzone_country et countries.
Je te laisse observer l'effet que ça donne. Ca peut faire peur mais ça peut aussi être plus pratique à l'exploitation en évitant des jointures intermédiaires.

administratifzone

a ; Haute Garonne ; niveau n ; b
b ; Midi-Pyrhenees ; niveau n+1 ; null

fsmrel hurlerait contre le bonhomme null et j'essaie désormais de l'éviter aussi mais bon.
Si tu veux être plus normatif, le schéma (MCD) devrait être le suivant :
administratifzone -0,n----intégrer----(0,1)---- administratifzone

Ce qui donnerait en fait une table associative pour l'association intégrer :
administratifzone (id_administratifzone, level, name_administratifzone)
integrer_adm_zones (id_zone_integree, id_zone_integrante)

Il y a d'ailleurs ici un exemple d'identification relative (cardinalité 0,1 entre parenthèses) qui a pour conséquence que la clé primaire de la table associative n'est pas composée des identifiants des deux tables (comme dans le cas d'une association 0,n - 0,n) mais seulement de l'identifiant de la zone intégrée qui ne peut être intégrée qu'une fois.

Au fait, du coup ça ne marche pas pour les cantons ce modèle !
Un canton peut être intégré à un département mais aussi à une localunit (une ville). Il faudrait donc une association 1,n - 0,n et obligatoirement une table associative.

infzone_localunit

1 ; a

supzone_country
b ; FRA

La relation entre supzone_country et localunit suppose une clé étrangère dans localunit. En fait cette relation est plutôt celle que je mentionnais absente plus haut entre countries et localunit.

En fait c'est pour assurer le fait qu'une supzone n'apparaisse qu'une seule fois dans supzone_country. Je ne veux associer qu un seul pays a une supzone.... Bon j'ai changé et j'ai mis une relation 1-1 au lieu d'une relation 1-N

Si je comprends bien, d'après ton exemple de données et d'après le schéma, supzone_country est en fait une table associative issue de l'association suivante :
countries -1,n----supzone_country----(0,1)- administratifzone

Tu as mis en oeuvre l'identification relative !

Pour la France, seules les régions figureront dans cette table, c'est ça ?

Ca me semble commencer à prendre une tournure sympathique ton schéma. Vérifie-le avec des exemples concrets et un peu tarabiscotés et avec tes géographes.

[kap]

Il y a d'ailleurs ici un exemple d'identification relative (cardinalité 0,1 entre parenthèses) qui a pour conséquence que la clé primaire de la table associative n'est pas composée des identifiants des deux tables (comme dans le cas d'une association 0,n - 0,n) mais seulement de l'identifiant de la zone intégrée qui ne peut être intégrée qu'une fois.

J'ai mis en place la table associative. Pour le moment je suis resté dans une optique ou une zone inférieure est intégré à une seule zone supérieure (donc les cantons ne sont pas gérés)

Tu as mis en oeuvre l'identification relative !

Yeahh !!!

Pour la France, seules les régions figureront dans cette table, c'est ça ?

Oui c'est l'idée.

Par contre je sais pas comment gérer la cohérence des données :

• vérifier que les capitales d'une zone appartiennent bien à cette zone
• vérifier la hiérarchie entre les zones (zone inf liée à une zone de niveau supérieure)
• vérifier que la zone supérieure d'un localunit référence bien le meme pays que le localunit

Ca me semble commencer à prendre une tournure sympathique ton schéma.

Moi aussi ça me commence à me plaire Encore un grand merci d'avoir pris le temps de me poser les bonnes questions et de me faire réfléchir là où il fallait. C'est agréable d'avancer comme ca !!

[CinePhil]

J'analyse ton nouveau MCD...

1) Table supzone_country
1.a) C'est une table associative entre countries et administratifzone (au fait, in english on dit plutôt administrative_zone ; en français aussi on dirait zone_administrative !) qui correspond à ce MCD :
countries -1,n----supzone_country----(0,1)- administratifzone

1.b) Tu indiques une contrainte sur les country référencées. Que veux-tu dire par là ?
Une administratifzone n'étant référencée au maximum qu'une seule fois dans supzone_country, elle ne sera associée qu'à une seule country

1.c) Tu établis ensuite une relation entre supzone_country et localunit selon ce MCD :
supzone_country -1,n----comprendre----1,1- localunit

Au passage, au niveau MCD, cela transforme l'association supzone_country en entité. Le MCD devient :
localunit -1,1----situer----------------------------|
countries -1,n----comprendre----1,1- supzone_country -(1,1)----associer----0,1- administratifzone

Localunit devrait avoir pour clé étrangère l'identifiant de supzone_country, c'est à dire l'identifiant de administratifzone et non pas celui de countries.

2) capitale
Tu as créé cette nouvelle association entre localunit et administratfzone qui permet à une localunit d'être capitale de plusieurs administratifzone. Toulouse est "capitale" de la région Midi_Pyrénées et du département de Haute-Garonne donc c'est cohérent.

Mais en créant cette table associative, tu autorise effectivement Toulouse a être capitale d'un département qui n'est pas en région Midi-Pyrénées.

C'est à vérifier pour les administratifzone étrangères mais en France toutes les régions et tous les départements ont une "capitale". Il vaudrait donc mieux établir directement l'association suivante :
localunit -0,1----etre_capitale----1,1- administratifzone

Comme tu n'enregistreras pas les cantons dans les administratifzone, ça ne pose pas de problème.

Ce qui donnerait une clé étrangère référençant la localunit capitale dans administratifzone. Tu n'as plus besoin de la table capitale ni de la colonne booléenne capitale dans localunit.

Par contre, il te manque les capitales des countries :
localunit -0,1----etre_capitale----1,1- countries

3) infzone_localunit
C'est par contre ici qu'il peut y avoir un problème de cohérence !

Le modèle n'interdit pas que Toulouse soit associé :
- à Midi-Pyrénées dans supzone_country ;
- à une autre région dans infzone_localunit ;
- à un département n'appartenant pas à la région dans infzone_localunit.

4) hierarchie_zone
Ta contrainte est juste et devra être vérifiée par un trigger je pense.

5) Modifications à apporter
Au final, pour résoudre les problèmes évoqués ci-dessus, je ferais plutôt comme ça :

5.a) Une localunit est située dans une seule administrativezone de niveau 0 et une administrative zone peut comprendre plusieurs localunit

localunit -1,1----situer----0,n- administratifzone

==> clé étrangère de administratifzone dans localunit

5.b) Une localunit peut être capitale de plusieurs administratifzone et une administratifzone n'a qu'une capitale (à vérifier hors France).

localunit -0,n----etre_capitale---1,1- administratifzone

==> clé étrangère de localunit dans administratifzone

Nota : Il faudra utiliser une procédure spéciale pour créer en même temps l'administratifzone et sa capitale car les deux clés étrangères imposent chacune l'existence de l'autre. Ainsi qu'un trigger ON UPDATE pour gérer le changement d'administratifzone d'une localunit capitale.

5.c) Une country comporte de une à plusieurs administratifzone et une administratifzone est située dans une seule country.

C'est plus délicat à gérer.
I. Soit on reste sur ton schéma en n'associant que les administratifzone de niveau supérieur :

administratifzone -(0,1)----situer----1,n- countries

Mais il faut alors vérifier que toutes les administratifzone de niveau supérieur pour une country sont bien associées à cette country.

II. Soit on situe toutes les administratifzone dans une country :
administratifzone -1,1----situer----1,n- countries

Et il faut vérifier qu'une administratifzone d'une country de niveau inférieur est bien située dans la même country que l'administratifzone de niveau n+1.

Le second cas me semble plus simple d'un point de vue pratique :
- Demande de création d'une administratifzone.
==> Affichage du formulaire.
- Choix de la country.
==> Proposition des administraifzone de la country pour rattachement éventuel à une administratifzone de niveau supérieur.
- Choix de l'administratifzone de niveau supérieur dans la liste proposée qui est forcément celle de la country.
- Si changement du choix de la country, on réinitialise le formulaire.

Voilà mes dernières réflexions. Ca ne doit pas être loin de la solution, pour autant que tu n'aies pas à gérer des cas similaires aux cantons français.

[kap]

Voilà j'ai pris tes dernières remarques en considération. J'ai un peu hésité pour la gestion des country et des administrativezone (5.c) et finalement j'ai opté pour ta solution. Ca fait un peu de redondance mais ça peut permettre de faciliter le contrôle de cohérence des données. Voici le nouveau modèle (cf pièce jointe).
En revanche je vais devoir gérer l'ajout dans les tables countries, administrativezone et localunit à cause de toutes les clés étrangères... Par "procédure spéciale" tu veux dire procédure stockée sur le serveur?

Merci encore !!

[CinePhil]

Par "procédure spéciale" tu veux dire procédure stockée sur le serveur ?

Voir un exemple concret très bien expliqué par fsmrel sur un débat un peu chaud en cours actuellement.
Lire également le message de SQLPro juste après. Il doit exister aussi quelque chose sur le sujet sur son blog mais je ne retrouve pas.