Mise à jour d'une base Oracle

[Olivier Eckmann]

Bonjour,

 

Je suis une bille en Oracle, mais mon client dispose d'une base Oracle avec une couche de polygone. Chaque polygone contient environ 20 attributs.

De mon côté je dispose de la même base de polygone (MPolygon avec seulement 3 infos) que je dois mettre à jour (découper / fusionner des polygones et mettre à jour les 3 attrbuts.

La base Oracle doit ensuite être mise à jour selon les nouvelles géométries et les infos fournies, les autres infos étant renseignées par l'utilisateur.

Actuellement, je livre la nouvelle couche avec la liste des polygones modifiés, puis le client récupère les nouvelles géométries et redécoupe sa base, et resaisit les infos que j'ai mises à jour. Le travail est donc fait 2 fois.

 

Quelle serait la meilleure méthode pour ne faire le travail qu'une seule fois? Est-ce possible sans développement? Sachant que les 17 autres données attributaires de la base Oracle ne doivent pas m'être transmises?

 

Merci pour toutes infos

 

Olivier

[lecrabe]

Hello Olivier

 

Je reformule ce que j'ai compris de ton probleme ...

 

Tu as par exemple en provenance de ton client N Polygones de Parcelles (Source Oracle Spatial) avec 3 champs / donnees attributaires publiques qui te sont fournies du genre: Identifiant Parcelle, Surface, Divers ...

mais dans la couche originale Oracle Spatial, il y a CES 3 champs publics + 17 autres champs NON publics (par exemple relatifs au proprietaire) !?

 

Q1) SVP on te fournit quoi : une vue Oracle sur les polygones avec seulement 3 champs

ou bien une extraction en SHP par exemple avec les 3 champs ?

 

Q2) De ton cote tu tripatouilles/modifies les Polygones (DONC la Geometrie !?) en ne touchant pas a l'identifiant ?

 

Q3) Est ce que tu ajoutes ou supprimes des Polygones ??

 

Bye, lecrabe

[Olivier Eckmann]

Salut Patrice,

 

J'ai de mon côté une base de MPolygones + OD que j'ai livré à partir de laquelle il a créé sa base Oracle et ajouter ses infos privées.

Régulièrement je mets à jour ma base de MPolygones par fusion / découpage. Je crée des nouveaux identifiants (pour le moment je ne garde pas trace des polygones parents, mais c'est possible si nécessaire)

Et je renvoie un DWG avec les MPolygones transformés en Polyligne + hachure.

De son côté, il copie/colle les nouvelles polylignes, puis met à jour la géométrie et / ou crée de nouveaux objets Oracle puis renseigne (recopie) à la main mes attributs et les siens.

 

Je pense que ce n'est pas spécifique à Oracle car on pourrait avoir la même problématique avec n'importe quelle Base de données connectée en FDO.

 

Voilà, j'espère avoir été plus clair.

 

Olivier

[GEGEMATIC]

salut,

pour moi,

la balle est dans les 2 camps:

ton client doit te fournir les polygones avec un identifiant unique, en fait la clef de sa table de données

de ton coté, tu dois conserver cette clef lorsque tu découpes

tu renvoies tes données avec cet identifiant

à partir de la, ton client n'aura plus qu'a faire une requete SQL (union il me semble) avec le champs identifiant comme pivot

ça doit se faire en 30 secondes une fois que c'est convenablement paramétré.

Gégé

[Olivier Eckmann]

Bonsoir,

 

Merci pour les explications, mais je ne comprends pas la démarche.

Est-ce qu'il doit effacer tous ses objets, rechargés les miens, puis faire la liaison avec les enregistrement de sa table? Sinon comment savoir quelle géométrie doit être mise à jour?

Mais lorsque tu effaces un objet, tu détruis aussi ses données, il me semble. Donc comment peut se faire l'union sur les nouveaux objets?

De plus une fois que un objet est découpé, chacun des 2 nouveaux objets devra recevoir les 3 champs que je lui fournis, puis les 17 autres champs de la base, en sachant que parmi ceux-ci, quelques uns seront être modifiés, donc il faut dupliquer l’enregistrement, une fois l'objet découpé pour pouvoir modifier les champs spécifiques à chaque objet.

Ça te semble tellement simple que je passe forcément à côté de quelque chose d'évident, mais franchement je ne vois pas.

 

Olivier

[lecrabe]

Hello

 

BEN moi cela ne me semble pas si simple que cela !

 

Je transpose en Shape ESRI ce que j'ai compris ...

 

1) Il faut raisonner comme si ton client avait simplement un fichier ESRI Shape (SHP, SHX, DBF, etc) de polygones avec environ 20 champs attributaires dont UN champ est UN Identifiant UNIQUE (on ne parle surtout pas du FeatId des Shapes) !

Q1) Suis je OK ?

 

2) Ton client te fournit TOUTE la couche avec seulement 3 champs attributaires publics !

Tu n'auras pas les 17 autres champs !

Q2) Suis je OK ?

 

3) Tu tripatouilles les Polygones :

- suppression Oui/Non ?

- modification de la geometrie (deplacer / supprimer / ajouter Vertex) Oui/Non ?

- creation de nouveaux polygones Oui/Non ? ---> Quid du Nouvel identifiant Oui/Non ?

- fusion de N polygones sur UN autre polygone DEJA existant ? Les N polygones sont effaces Oui/Non ?

- decoupage de UN polygone en 2 polygones Oui/Non ? QUID de l'Identifiant des 2 polygones ??

 

etc ...

 

4) En sortie, tu fournis :

- X polygones avec le meme Identifiant MAIS geometrie differente ?

Les 3 champs attributaires sont ils modifies ? (On ne touche pas a l'identifiant !) ?

- Y Nouveaux polygones avec un nouvel identifiant ?

- Z polygones supprimes - QUID de l'identifiant ?

 

Waiting ...

 

Bye, lecrabe

[Olivier Eckmann]

Salut Patrice,

 

1) oui

 

2) et 3) oui et non - car ma base est mise à jour régulièrement, selon les DMPC que je fais. Parfois je découpe 4 parcelles dans la journée, parfois rien pendant 1 mois, parfois je réunis des parcelles, parfois des parcelles disparaissent (passage en DP)..., parfois elles apparaissent (DP => parcelle) alors que la base du client n'évolue qu'une fois par an quand je lui la livre au 31 décembre. Il peux me relivrer sa base après modif, mais normalement elle doit être identique à celle que je lui ai livré l'année précédente, donc je ne vois pas trop l'intérêt qu'il me la redonne.

Je peux garder l'identifiant du polygone au jour de la livraison, mais il ne servirait qu'à savoir qu'il a été modifié??

 

4) effectivement, je ne sais pas quel traitement il peut/doit faire sur sa base Oracle. Pour moi la géométrie et les champs sont liés, donc la suppression d'un objet entraîne la perte des infos, c'est comme ça sur un SHP mais pas forcément sur Oracle??? A moins que la base soit coupée en 2, 1 partie la géométrie et une seconde partie pour les champs.

Si je lui relivre toute la base, il faut qu'il sorte(copie) ses enregistrements dans une autre base, qu'il recharge ma base (mes géométrie), puis lie à nouveau les enregistrements externes sur l'identifiant.

Mais comme il devra modifier certaines infos selon le découpage, je dois aussi lui indiquer tous les polygones modifiés.

Et comme tu dis QUID des nouveaux polygones (nouvel ID)? QUID des polygones supprimés?

 

Franchement, ça ne me parait pas simple.

 

Olivier

[GEGEMATIC]

salut a tous les 2,

j'ai un peu l'habitude de cette problématique avec les système APIC, c'est la même chose,

et le plus dur c'est de faire comprendre au client ce qu'il doit faire.

il s'agit d'un problème de consolidation de données, c'est la chose la moins bien documentée aussi bien sous excel que sous SQL, et pourtant la 1ère chose dont on a besoin lorsque l'on veut croiser des informations.

 

j'ai aussi ce problème lorsque je dois enrichir une base de données de regard avec leur position spatiale, qui est fournie dans un fichier excel par un géomètre.

 

 

pour schématiser, il y a chez ton client une table de x lignes et de 20 colonnes

il t'exporte n lignes et seulement 3 colonnes

 

parmis ces colonnes, il faut obligatoirement une colonne identifiant (code majic) qui servira de fil conducteur pour le lien avec les 17 autres colonnes de données et un autre, (qui chez ton client peut être son clone) qui fait le lien avec la géometrie: on pourra les appeler ID et HD

 

de ton coté:

- si tu découpe, les différentes parties conserveront l'ID du parent

- si tu supprime, ton export ne contiendra plus l'ID original

 

c'est tout ce qu'il y a a faire de ton coté.

 

chez ton client, il doit faire une manipe SQL pour supprimer les lignes dont l’identifiant ID faisait partie de son export mais n'est plus dans le tien (correspond à la suppression d'une parcelle suite à une fusion)

il lui faudra donc écrire le code correspondant à ce traitement, et pour ça il faut qu'il ait conservé la base qu'il ta exporté.

(pour lui simplifier le boulot, tu pourrai également lui fournir une liste des identifiants supprimés dans un autre table)

 

puis il doit faire une jonction entre tes nouvelles données et les siennes, en utilisant la colonne ID, qui reste le lien entre vos 2 bases.

(cette jonction se fait avec la syntaxe JOIN et non pas UNION comme je te l'avais dit:

JOIN fais des jonctions latérales, UNION empile des lignes)

 

il faut bien comprendre que dans ton export, tu risque d'avoir plusieurs fois le même ID, ce qui veut dire que l'ID de la parcelle doit être différent du Handle de l'entité représentant une parcelle (HD).

par contre dans la base finale de ton client, chaque ID et chaque HD sera au final unique.

 

 

donc en gros 90% du boulot est à faire chez ton client, mais une fois que les choses seront bien paramétrées, l'import de tes données ne devrait pas lui prendre plus de 2mn.

 

Gégé

[GEGEMATIC]

j'ne rajoute ,

car je passe peut être à coté de qq chose :

pour moi ta BD est parcellaire, donc on ne crée pas de nouvelle surface, mais on en divise ou on en fusionne.

 

pour être plus précis

4) effectivement, je ne sais pas quel traitement il peut/doit faire sur sa base Oracle. Pour moi la géométrie et les champs sont liés, donc la suppression d'un objet entraîne la perte des infos, c'est comme ça sur un SHP mais pas forcément sur Oracle??? A moins que la base soit coupée en 2, 1 partie la géométrie et une seconde partie pour les champs.

c'est ce que je veux dire avec ID et HD.

 

Si je lui relivre toute la base, il faut qu'il sorte(copie) ses enregistrements dans une autre base, qu'il recharge ma base (mes géométrie), puis lie à nouveau les enregistrements externes sur l'identifiant.

l'identifiant ID

 

Mais comme il devra modifier certaines infos selon le découpage, je dois aussi lui indiquer tous les polygones modifiés.

effectivement, mais ça ne présente pas de difficultés.

 

 

Et comme tu dis QUID des nouveaux polygones (nouvel ID)?

les nouveaux polygones provenant d'un division auront un ID existant, et un HD nouveau

 

QUID des polygones supprimés?

Pour moi, les polygones supprimés le sont par fusion, donc on les supprime et c'est tout.

après, s'il faut qu'un polygone créé par fusion conserve l'ID de tous ceux qui l'ont composé, il faut qu'ID deviennent la clef d'une autre table qui contiendra la liste des ID

la non plus, pour toi ce ne sera pas si compliqué.

 

Franchement, ça ne me parait pas simple.

Moins simple chez ton client que chez toi, c'est sur ...

 

gégé

[Olivier Eckmann]

Salut Gégé,

 

Je résume si j'ai tout bien compris.

 

Dans Oracle une couche Géospatiale est coupé en 2 tables distinctes, 1 table avec la géométrie et un identifiant unique et 1 autre table avec les données alpha et cet identifiant unique pour faire la liaison.

Je livre à mon client une nouvelle couche graphique avec cet identifiant "historique" sur chaque objet et mes nouvelles infos.

Le client détruit sa table géométrie, puis recharge la mienne et ensuite il y a un enchaînement de commande à exécuter sous Oracle (SQL) qui réalise les 5 étapes suivantes:

1. Si un enregistrement de la table alpha ne trouve pas de géométrie avec son identifiant alors il le supprime

2. Si l'enregistrement trouve une et une seule géométrie portant cet id alors il fait l'association

3. Si l'enregistrement trouve plusieurs géométries avec cet id, alors il duplique autant que nécessaire l'enregistrement puis relie 1 à 1 avec chaque géométrie, puis crée un nouvel ID unique

4. Si il reste des géométries avec des id non trouvés alors il crée autant d'enregistrement que nécessaire, puis fait la liaison 1 à 1 et crée autant de nouveaux ID unique

5. Il recopie les infos de ma couche pour mettre à jours les infos correspondantes dans sa table alpha.

 

Effectivement de mon côté c'est simple, reste plus qu'à espérer que leur admin Oracle tient la route :)

 

Olivier

[GEGEMATIC]

Salut Olivier et bonnes fêtes !

pour moi c'est correct, mais sachant que je ne connais pas plus oracle que toi,

mais une base est une base, et le principe sera le même.

 

ce genre de manip, je la fais en interne avec une base access et un DWG

et en externe avec un import d'apic FEA, traitement et export pour qu'ils l'intègrent à leur base.

 

dans les 2 cas la logique est la même, pour APIC je ne sais pas comment ils font, mais de mon coté je sais quel flux de données je dois respecter.

 

Le travail à faire la 1ère fois chez ton client est plus un travail de programmation qu'un travail d'administrateur de base: une fois que les outils seront en place, un admln pourra le faire.

 

pour faire ça sous access, j'ai souffert le martyr, parceque l'editeur sql est pourri, et que du coup il est très fastidieux de faire des tests avant de programmer la génération du code sql via VBA.

 

Mais bon, il y a des spécialistes qui font ça facilement ...

 

a+

Gégé