Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 12 sur 12
  1. #1
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut Dénormalisation ?

    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.
    C'est en respectant les autres que l'on se fait respecter.

  2. #2
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 912
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 912
    Points : 2 993
    Points
    2 993

    Par défaut

    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.

  3. #3
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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.
    C'est en respectant les autres que l'on se fait respecter.

  4. #4
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par Patrice Henrio Voir le message
    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é.
    C'est en respectant les autres que l'on se fait respecter.

  5. #5
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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.
    C'est en respectant les autres que l'on se fait respecter.

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 808
    Points
    24 808

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #7
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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
    C'est en respectant les autres que l'on se fait respecter.

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 808
    Points
    24 808

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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.
    C'est en respectant les autres que l'on se fait respecter.

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 562
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 562
    Points : 30 061
    Points
    30 061

    Par défaut

    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 +
    Images attachées Images attachées
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  11. #11
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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.
    C'est en respectant les autres que l'on se fait respecter.

  12. #12
    Membre habitué
    Inscrit en
    janvier 2004
    Messages
    339
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 339
    Points : 110
    Points
    110

    Par défaut avec ou sans limes

    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.
    C'est en respectant les autres que l'on se fait respecter.

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •