Discussion :

[Patrice Henrio]

Bonjour,

après avoir lu plusieurs interventions sur ce sujet, je ne sais plus exactement où j'en suis. Le mieux est donc de vous exposer la situation. Je dispose de

1. une table POINTS comportant trois colonnes : identifiant, longitude et latitude
2. une table que j'ai appelé LIMES avec trois colonnes : un identifiant, un entier correspondant à l'identifiant d'un premier point et un entier pour l'identifiant du dernier point (chaque limes est composé des tous les points dont l'identifiant est compris entre le premier et le dernier)
3. une table appelée CONTOURS avec plusieurs colonnes : un identifiant et divers calculs
4. une table CONTOURS_LIMES avec trois colonnes : un identifiant de contours, un identifiant de LIMES, un rang du limes, un sens de parcours du limes. Chaque contours est donc composé d'un certain nombre de limes dans l'ordre indiqué par rang et parcouru du premier au dernier point ou du dernier au premier (sens).

Cette structure a pour but de ne pas avoir de doublons au niveau des points : si la même suite de points intervient dans deux contours, celle-ci détermine un limes. Cependant si deux limes ont un et un seul point commun, j'ai pris la décision (pour des raisons d'efficacité (?)) de répéter ce point plutôt que de créer un limes composé d'un seul point.
Un exemple sera peut-être plus parlant : soit un contours composé d'un limes correspondant aux points 25 à 52, un deuxième contours composé par exemple des points suivants : les points 113 à 127 (distincts des points précédents), le point 37, puis les points 129 à 135 (distincts des points précédents).
Avec une table POINTS acceptant les doublons, on a besoin de deux limes, un (25,52) pour le premier contours, et un (113,135) pour le deuxième. le point 128 étant identique au point d'identifiant 37.
Si la table POINTS n'accepte pas les doublons il faudra pour le deuxième contour trois limes : (113,127), (37,37), (129,135). Quand je parle de doublons il s'agit bien sûr de doublons relatifs : mêmes infos sauf l'identifiant.

Votre avis.

[StringBuilder]

Je suis un peu stupéfait par la conception de la table "LIMES".

Un ID est une donnée "anonyme" et "dénuée de sens".

Ainsi, dire qu'un LIME est composée de l'ensemble des POINT dont l'id est compris entre une valeur et une autre me semble extrêmement hasardeux.

Pour moi, il faut une table LIME_POINTS (id_lime, id_point, ordre) voir même LIME_SEGMENT (id_segment, id_lime, id_point1, id_point2, id_precedent) avec auto-jointure id_precedent = id_segment

Ainsi :
- plus de doublons de points
- plus de règle étrange de continuité des id des points dans un LIME
- pas de truc biscornu pour déterminer le nombre de points d'un LIME ou la somme des distances entre points.

En revanche, après pour la dénormalisation, il faut surtout connaître les besoins.

[Patrice Henrio]

Je suis un peu stupéfait par la conception de la table "LIMES".

Un ID est une donnée "anonyme" et "dénuée de sens".

Ainsi, dire qu'un LIME est composée de l'ensemble des POINT dont l'id est compris entre une valeur et une autre me semble extrêmement hasardeux.

Pour moi, il faut une table LIME_POINTS (id_lime, id_point, ordre) voir même LIME_SEGMENT (id_segment, id_lime, id_point1, id_point2, id_precedent) avec auto-jointure id_precedent = id_segment

Ainsi :
- plus de doublons de points
- plus de règle étrange de continuité des id des points dans un LIME
- pas de truc biscornu pour déterminer le nombre de points d'un LIME ou la somme des distances entre points.

En revanche, après pour la dénormalisation, il faut surtout connaître les besoins.

Je vais tester cette méthode (qui ressemble à ce que j'ai fait pour le passage des limes aux contours). D'ailleurs en y réfléchissant il doit être possible de se passer des limes et utiliser seulement une table CONTOURS_POINTS sur le même principe.

[Patrice Henrio]

Je vais tester cette méthode (qui ressemble à ce que j'ai fait pour le passage des limes aux contours). D'ailleurs en y réfléchissant il doit être possible de se passer des limes et utiliser seulement une table CONTOURS_POINTS sur le même principe.

J'ai continué mes recherches sur les id (ou les clés primaires, je pense que c'est la même chose). J'ai vu sur un site parlant de OWL qu'on lorsque l'on a une relation fonctionnelle (P(x,y) et P(x,z) alors y=z) on pouvait utiliser la deuxième composante comme clé primaire. Réciproquement une clé primaire dans une table induit une relation fonctionnelle. En ce cas pourquoi une clé primaire ou un identifiant ne pourrait-il pas avoir de signification, du moment que l'on veut s'assurer simplement de l'unicité des valeurs de cette clé ? Dans le cas qui m'intéresse j'ai une relation P(id,pt), celle-ci est bien fonctionnelle en id mais pas en pt, c'est à dire que je peux avoir P(id1,pt) et P(id2,pt) sans pour autant que id1=id2.
J'espère n'avoir pas tout mélangé.

[Patrice Henrio]

Je suis un peu stupéfait par la conception de la table "LIMES".

Un ID est une donnée "anonyme" et "dénuée de sens".

Ainsi, dire qu'un LIME est composée de l'ensemble des POINT dont l'id est compris entre une valeur et une autre me semble extrêmement hasardeux.

Pour moi, il faut une table LIME_POINTS (id_lime, id_point, ordre) voir même LIME_SEGMENT (id_segment, id_lime, id_point1, id_point2, id_precedent) avec auto-jointure id_precedent = id_segment

Ainsi :
- plus de doublons de points
- plus de règle étrange de continuité des id des points dans un LIME
- pas de truc biscornu pour déterminer le nombre de points d'un LIME ou la somme des distances entre points.

En revanche, après pour la dénormalisation, il faut surtout connaître les besoins.

Je ne comprends pas bien ta réponse. Finalement faut-il ou non une table LIMES_POINTS ?
Sinon je pense que LIMES_SEGMENT signifie qu'un limes (Limes est un bout de frontière fortifiée chez les romains, lime est un citron vert) est constitué de plusieurs segment. Mais un limes étant la frontière entre deux régions, il est parcouru dans un sens pour la première région et dans l'autre sens pour la deuxième région : faut-il doubler les infos en intervertissant id_point1 et id_point2 et id_precedent et id_segment ?
Je ne vois pas trop comment utiliser ce LIMES_SEGMENTS.

[CinePhil]

J'ai vu sur un site parlant de OWL qu'on lorsque l'on a une relation fonctionnelle (P(x,y) et P(x,z) alors y=z) on pouvait utiliser la deuxième composante comme clé primaire.

Attention ! Je ne crois pas que OWL soit basé sur la l'algèbre relationnelle. C'est un langage dérivé de XML et qui est plutôt à rapprocher du noSQL car de type clé=>valeur.

Sous réserve de confirmation par fsmrel et autres spécialistes de l'algèbre relationnelle, si je traduis "(P(x,y) et P(x,z) alors y=z)" en "x->y et x->z alors y->z", je pense que la proposition est fausse. Un simple exemple : Mon numéro de sécu "détermine" que je suis né en 1963 et au mois de juillet mais l'année est bien différente du mois !

une table POINTS comportant trois colonnes : identifiant, longitude et latitude

Selon moi, un point déterminé par une longitude et une latitude doit être unique dans la table. Pour en revenir au relationnel, on a bien dans cette table {identifiant} -> {longitude, latitude} il me semble, sans pour autant que l'identifiant du point n'ait une quelconque signification sémantique ni ne détermine un ordre a priori, autre que celui de l'insertion des points dans la table.

Limes est un bout de frontière fortifiée chez les romains

Il s'agit donc d'un ensemble de points ordonnés définissant une ligne brisée.

Mais un limes étant la frontière entre deux régions, il est parcouru dans un sens pour la première région et dans l'autre sens pour la deuxième région

une table CONTOURS_LIMES avec trois colonnes : un identifiant de contours, un identifiant de LIMES, un rang du limes, un sens de parcours du limes. Chaque contours est donc composé d'un certain nombre de limes dans l'ordre indiqué par rang et parcouru du premier au dernier point ou du dernier au premier (sens).

Qu'il y ait un ordre des points dans un LIMES est logique puisqu'il s'agit de dessiner une ligne brisée. Si je trace un trait des coordonnées (1,1) vers (2,4) puis vers (4,5), ce n'est pas la même chose que si je trace un trait de (1,1) vers (4,5) puis vers (2,4).

Par contre, pour dessiner un contour, peut importe l'ordre des LIMES qui le composent. Le LIMES allant de (1,1) vers (2,4) puis vers (4,5) aura toujours la même forme et sera toujours positionné au même endroit, que je le dessine en premier ou en 5ème dans le contour. Si je dessine le contour de la France, Je peux commencer par la frontière pyrénéenne puis dessiner la Bretagne puis le Golfe du Lion puis la frontière alsacienne avec l'Allemagne... Au final, j'aurais toujours le contour de la France.

Je pense donc que tu dois t'en sortir avec une table associative LIMES_POINTS (id_limes, id_point, ordre) et une table associative CONTOURS_LIMES (id_contour, id_limes).

Conclusion : Pas de dénormalisation nécessaire ici je pense !

[Patrice Henrio]

Attention ! Je ne crois pas que OWL soit basé sur la l'algèbre relationnelle. C'est un langage dérivé de XML et qui est plutôt à rapprocher du noSQL car de type clé=>valeur.

Sous réserve de confirmation par fsmrel et autres spécialistes de l'algèbre relationnelle, si je traduis "(P(x,y) et P(x,z) alors y=z)" en "x->y et x->z alors y->z", je pense que la proposition est fausse.

La relation x<y n'est pas fonctionnelle. Tu as confondu avec P(x,y) et P(x,z) alors P(y,z) ce qui ne correspond à aucune propriété particulière que je connaisse en algèbre relationnelle. J'y connais pas grand chose en base de données mais par contre en algèbre fonctionnelle j'ai quelques connaissance.

Un simple exemple : Mon numéro de sécu "détermine" que je suis né en 1963 et au mois de juillet mais l'année est bien différente du mois !

La relation entre le numéro de sécu et le mois et année de naissance est fonctionnelle : à un numéro de sécu correspond un et un seul couple mois/année. La relation n'est pas ici P(SS,mois) et P(SS,année) mais P(SS,mois) et Q(SS,année)
Par contre P(SS, (mois1,année1)) et P(SS, (mois2,année2)) alors nécessairement mois1=mois2 et année1 = année2.
Ce qui est l'expression que le numéro de sécu est fonctionnel pour le mois de naissance et aussi pour l'année de naissance.

[quote]
Selon moi, un point déterminé par une longitude et une latitude doit être unique dans la table. Pour en revenir au relationnel, on a bien dans cette table {identifiant} -> {longitude, latitude} il me semble, sans pour autant que l'identifiant du point n'ait une quelconque signification sémantique ni ne détermine un ordre a priori, autre que celui de l'insertion des points dans la table.


Il s'agit donc d'un ensemble de points ordonnés définissant une ligne brisée.
Il s'agit exactement de cela : ordre d'insertion dans la table.

Qu'il y ait un ordre des points dans un LIMES est logique puisqu'il s'agit de dessiner une ligne brisée. Si je trace un trait des coordonnées (1,1) vers (2,4) puis vers (4,5), ce n'est pas la même chose que si je trace un trait de (1,1) vers (4,5) puis vers (2,4).

Par contre, pour dessiner un contour, peut importe l'ordre des LIMES qui le composent. Le LIMES allant de (1,1) vers (2,4) puis vers (4,5) aura toujours la même forme et sera toujours positionné au même endroit, que je le dessine en premier ou en 5ème dans le contour. Si je dessine le contour de la France, Je peux commencer par la frontière pyrénéenne puis dessiner la Bretagne puis le Golfe du Lion puis la frontière alsacienne avec l'Allemagne... Au final, j'aurais toujours le contour de la France

Tout à fait. Sauf que je veux bénéficier des API toute faite de tracé de polygones. Ce qui permet en outre de tester très rapidement si un point est à l'intérieur ou non d'une région. De plus pour des raisons de cohérence mes pourtours sont toujours décrits dans le sens trigonométrique.

Je pense donc que tu dois t'en sortir avec une table associative LIMES_POINTS (id_limes, id_point, ordre) et une table associative CONTOURS_LIMES (id_contour, id_limes).
Conclusion : Pas de dénormalisation nécessaire ici je pense !

Je regarde de nouveau LIMES_POINTS. Par contre je garde ma structure CONTOURS_LIMES

[CinePhil]

Sauf que je veux bénéficier des API toute faite de tracé de polygones.

Attention à ne pas mélanger la modélisation des données (aspect statique et indépendant de ce l'on fait des données) du processus applicatif (aspect dynamique qui utilise les données) !

T'es-tu penché sur Postgis ou autres outils spécifiques à certains SGBD pour les données géométriques ? MySQL n'est pas recommandé pour ce genre de chose car sa partie géo est très en deçà de la concurrence !

[Patrice Henrio]

Attention à ne pas mélanger la modélisation des données (aspect statique et indépendant de ce l'on fait des données) du processus applicatif (aspect dynamique qui utilise les données) !

T'es-tu penché sur Postgis ou autres outils spécifiques à certains SGBD pour les données géométriques ? MySQL n'est pas recommandé pour ce genre de chose car sa partie géo est très en deçà de la concurrence !

Je voulais surtout un système avec un gestionnaire de base de données embarqué (J'ai choisi H2). J'ai jeté un oeil distrait sur les SIG, mais il semble que ce serait un marteau pour écraser une mouche.

Je reste persuadé qu'une étude approfondie ne peut (doit) pas faire l'impasse sur les outils qui mettront en oeuvre la solution. Ainsi ta solution de construction des pourtours sans ordre compliquera énormément le tracé de ceux-ci alors que ma solution où je me préoccupe dés la conception de la base de données du fait que ce pourtour est constitué de limes ordonné simplifie tout à fait ce tracé.
A la limite on pourrait dire qu'à la modélisation ta solution est tout à fait valable mais que je m'apercevrai lors du passage au processus applicatif que j'aurai du prendre une autre modélisation.
C'est d'ailleurs ce que j'ai du faire à un autre moment. Chaque pourtour est inclus dans un cercle de centre et rayon qui peuvent être calculés à chaque utilisation des données. J'ai préféré rajouter trois colonnes et calculer une fois pour toute ces données qui servaient uniquement lors de l'utilisation. En fait les données sont faites pour être utilisées dans un programme spécifique et c'est donc celui-ci qui détermine de quoi j'ai besoin et comment j'organise mes données.

[SQLpro]

Attention chaque ordonnancement de frontière est propre au pays. Il vous faut donc une entité POINT, une entité PAYS et une association n/m reliant les points et les pays que j’appellerais "délimite" et qui contiendra un attribut "ordre".

En PJ un MCD similaire que je donne à mes étudiants et stagiaire :
http://www.developpez.net/forums/att...1&d=1354714728

A +

[Patrice Henrio]

Attention chaque ordonnancement de frontière est propre au pays. Il vous faut donc une entité POINT, une entité PAYS et une association n/m reliant les points et les pays que j’appellerais "délimite" et qui contiendra un attribut "ordre".

En PJ un MCD similaire que je donne à mes étudiants et stagiaire :
http://www.developpez.net/forums/att...1&d=1354714728

A +

L'ordonnancement de frontière est bien en effet propre au pays, cependant la frontière entre deux pays sera composé de la même suite de points parcouru dans un sens et dans l'autre. On est obligé de fixer un sens de parcours pour ne pas se trouver piéger avec trois pays (problème connu avec des engrenages).
Donc je fixe le sens de parcours de la frontière, je définis des listes de points (bout de frontières), la frontière est composé de bouts de frontières orientés (parcourus dans un sens ou dans l'autre).

Je n'ai pas tout compris dans le schéma.
A priori la partie altitude ne me concerne pas ici, seuls les deux rectangles parcelle et point m'intéresse.
Pour le point il y a un identifiant qui est la clé primaire et les deux coordonnées (qui sont ici en radians) avec je pense une contrainte sur la longitude et une autre sur la latitude (à priori pas la même car la longitude prend ses valeurs sur un intervalle de 2*PI alors que la latitude c'est sur PI seulement.
Une parcelle a un identifiant et un numéro de parcelle (unique j'imagine et pourrait donc éventuellement servir de clé primaire). Pour la saisie point j'imagine aussi que c'est propre à cette construction.
Enfin la relation est "délimite" entre les points et les parcelles.
C'est le 0,n et le 1,n que je m'explique moins (je suis en auto-formation sur tout ce qui concerne les bases de données, il n'y a que l'algèbre relationnelle qui me vient de mes lointaines, mais entretenues, études de maths). Chaque point peut délimiter 0, 1 ou plusieurs parcelles (on peut éliminer le cas 0 car on peut décider de n'intégrer dans la table que des points servant à délimiter au moins une parcelle). Chaque parcelle est délimité nécessairement par plusieurs points (et même au moins 3).

En définitive peut-être que mon passage par les bouts de frontière ne simplifie rien du tout. J'hésite à mettre à bas une construction qui date de 10 ans. Au départ tout passe par des fichiers binaires avec une gestion perso des données, rien de compatible avec un quelconque format public, puis une structure plus proche des "standards" avec des tables pouvant être interrogées via SQL mais pour aller vite j'ai conservé une partie de la première structure.

[Patrice Henrio]

J'ai donc testé la base avec l'astuce des limes (morceaux de frontière) et sans : verdict avec limes la base est de 4,5 MO, sans 25 MO.
Même si ce n'est pas très propre je crois que je vais continuer avec mes limes.