Vous pouvez utiliser l'outil de géotraitement Migrer le stockage pour effectuer la migration des éléments binaires ou spatiaux ou des colonnes raster d'un type de stockage à un autre. Pour cela, vous devez indiquer un mot-clé de configuration qui contient un paramètre ATTRBUTE_BINARY, GEOMETRY_STORAGE ou RASTER_STORAGE défini sur le nouveau type de stockage vers lequel vous souhaitez convertir les données.
Il est important que le mot-clé de configuration créé contienne le paramètre et la valeur corrects. Si vous indiquez un mot clé avec des informations inexactes ou manquantes, les informations sont lues à partir du mot-clé DEFAULTS. Esri vous conseille de créer un mot-clé personnalisé spécialement pour la migration. Assurez-vous que le mot-clé contienne le paramètre et la valeur vers lesquels vous migrez les données, ainsi que le paramètre UI_TEXT. Le paramètre UI_TEXT rend le mot clé disponible pour les clients ArcGIS.
Voici les chemins de migration pris en charge pour chaque système de gestion de bases de données (SGBD) :
| SGBD | Paramètre de configuration | Migrer depuis/vers |
|---|---|---|
Oracle | ATTRIBUTE_BINARY | LONG RAW vers BLOB |
GEOMETRY_STORAGE | LONG RAW (SDEBINARY) vers BLOB (SDELOB) | |
LONG RAW (SDEBINARY) vers ST_GEOMETRY | ||
BLOB (SDELOB) vers ST_GEOMETRY | ||
SDO_GEOMETRY vers ST_GEOMETRY | ||
RASTER_STORAGE | LONG RAW vers BLOB | |
LONG RAW vers ST_RASTER * | ||
BLOB vers ST_RASTER * | ||
PostgreSQL | RASTER_STORAGE | BYTEA vers ST_RASTER * |
SQL Server | RASTER_STORAGE | IMAGE vers ST_RASTER * |
GEOMETRY_STORAGE | SDEBINARY vers GEOMETRY | |
SDEBINARY vers GEOGRAPHY | ||
OGCWKB vers GEOMETRY | ||
OGCWKB vers GEOGRAPHY |
*ST_Raster doit être installé dans la géodatabase. Reportez-vous aux rubriques Installer ST_Raster dans Oracle, Installer ST_Raster dans PostgreSQL ou Installer ST_Raster dans SQL Server pour plus d'informations.
Pourquoi migrer des données ?
Deux raisons peuvent vous pousser à migrer vos données :
- Pour accéder à vos données spatiales ou raster à l'aide de SQL (Structured Query Language)
- Pour passer d'un type de données qui peut ne plus être pris en charge à l'avenir à un type pris en charge
Accès aux données à l'aide de SQL
L'accès aux informations dans une géodatabase via SQL permet aux applications externes (celles qui ne sont pas développées dans un environnement ArcObjects) d'utiliser les données tabulaires gérées par la géodatabase. Si ces applications doivent accéder aux données spatiales ou raster dans la géodatabase, vous devez stocker vos données spatiales ou raster dans des types de données qui permettent un accès SQL. Par exemple, le type de stockage ST_Raster permet d'accéder aux données raster par SQL, ce qui n'est pas facile si les données raster sont stockées dans un champ BLOB, LONG RAW, IMAGE, BINARY ou BYTEA.
Migrer de types qui peuvent ne plus être pris en charge dans les versions futures
Oracle recommande l'utilisation des types de données BLOB ou BFILE au lieu des types de données LONG RAW dans ses bases de données. Même si les colonnes LONG RAW sont encore prises en charge, si vous avez des champs attribut, géométrie ou raster LONG RAW dans votre géodatabase actuelle dans Oracle, il est conseillé de migrer ces champs vers un format différent en préparation du moment où ils ne seront plus pris en charge.
Le stockage des colonnes attribut, géométrie et raster dans une géodatabase est contrôlé par les paramètres DBTUNE ATTRIBUTE_BINARY, GEOMETRY_STORAGE et RASTER_STORAGE. Les valeurs par défaut de ces paramètres sous le mot-clé de configuration DBTUNE DEFAULTS sont différentes selon la version d'ArcGIS que vous avez utilisée lors de la création de la géodatabase. Le tableau suivant présente le paramètre par défaut du mot-clé DEFAULTS de la table DBTUNE pour les géodatabases dans Oracle.
| Paramètre | Valeur par défaut pour la version 9.3 d'ArcGIS et les versions ultérieures | Valeur par défaut pour la version 9.2 d'ArcGIS | Valeur par défaut avant la version 9.2 d'ArcGIS |
|---|---|---|---|
ATTRIBUTE_BINARY | BLOB | BLOB | LONG RAW |
GEOMETRY_STORAGE | ST_GEOMETRY | LONG RAW (SDEBINARY) | LONG RAW (SDEBINARY) |
RASTER_STORAGE | BLOB | LONG RAW | LONG RAW |
Les données créées dans les nouvelles géodatabases (non mises à niveau) version 9.3 ou ultérieures avec les paramètres par défaut n'utilisent pas le type de stockage LONG RAW. Toutefois, toutes les données existantes créées avec un ou plusieurs paramètres définis sur LONG RAW, ou toutes nouvelles données dans les géodatabases mises à niveau ayant ces paramètres définis sur LONG RAW contiennent encore des colonnes de type LONG RAW. Pour changer les types de données de ces colonnes, modifiez vos paramètres DBTUNE et migrez les données.
Depuis ArcGIS 10.1, les classes d'entités créées dans les géodatabases, sur SQL Server, utilisent le type de géométrie Microsoft par défaut. Pour déplacer vos classes d'entités existantes vers le type de stockage de géométries, utilisez l'outil de géotraitement Migrer le stockage ou un script Python.
Avant d'effectuer une migration...
Les conditions suivantes doivent être vérifiées avant la conversion de vos données :
- Vous devez effectuer une sauvegarde des données avant d'effectuer leur migration.
- Si vous effectuez une conversion du type de données de colonne spatiale, les données doivent être stockées en haute précision. Si vos données sont actuellement stockées en précision de base, vous devez tout d'abord effectuer une migration vers la haute précision avant de migrer le type de stockage. Utilisez l'outil de géotraitement Mettre à jour une référence spatiale pour procéder à une mise à niveau vers la haute précision.
- La table ou la classe d'entités doit être inscrite auprès de la géodatabase.
- Le mot-clé de configuration spécifié lors de la migration du type de données doit contenir la valeur correcte pour les paramètres GEOMETRY_STORAGE, ATTRIBUTE_BINARY et RASTER_STORAGE. Par exemple, si vous voulez effectuer la migration d'une colonne de géométrie depuis le type LONG RAW vers le type ST_GEOMETRY, mais vous spécifiez un mot-clé ayant le paramètre GEOMETRY_STORAGE défini sur SDO_GEOMETRY, la migration échoue parce qu'il ne s'agit pas d'un chemin de migration pris en charge.
- Vous devez être connecté en tant que propriétaire de la table contenant la colonne à migrer.
- Pour effectuer la migration d'une classe d'entités vers le type SQL Server GEOGRAPHY, les données doivent être dans l'un des systèmes de coordonnées géographiques pris en charge par le type GEOGRAPHY.
- Si votre géodatabase est dans SQL Server 2008 ou 2008 R2, les classes d'entités migrées vers le type SQL Server GEOGRAPHY ne peuvent pas contenir de valeurs de coordonnées z ou m.