Migration vers la géodatabase fichier

Des différents types de géodatabases, les géodatabases fichier sont celles qui ressemblent le plus aux géodatabases personnelles, parce qu'elles sont conçues pour être mises à jour par un seul utilisateur et qu'elles ne prennent pas en charge le versionnement de géodatabase. Elles sont également utilisées de la même façon, qu'il s'agisse d'afficher, d'interroger, de mettre à jour ou de traiter des données, ou encore de développer des applications. Il existe néanmoins quelques différences. Par exemple, les géodatabases personnelles ont une limite de stockage de 2 Go, alors que les géodatabases fichier n'ont pas de limites, et la syntaxe SQL (Structured Query Language) est également légèrement différente pour les deux types de géodatabases. Si vous êtes habitué à utiliser des géodatabases personnelles et que vous souhaitez effectuer une migration vers une géodatabase fichier, utilisez cette rubrique pour prendre connaissance de ces différences et savoir comment commencer.

Pour obtenir une présentation des différences entre les géodatabases fichier et les géodatabases personnelles et ArcSDE, reportez-vous aux rubriques Types de géodatabase et Procédure de stockage des données raster dans une géodatabase.

Création d'une géodatabase fichier

Pour créer une géodatabase fichier vide, cliquez avec le bouton droit sur un dossier système de fichiers dans l'arborescence du catalogue, pointez sur Nouveau et sélectionnez Géodatabase fichier. Reportez-vous à la rubrique Création d'une géodatabase fichier pour plus d'informations.

Migration des données existantes

• La méthode la plus simple pour copier des données d'une géodatabase personnelle dans une géodatabase fichier consiste à utiliser les commandes Copier et Coller de l'arborescence du catalogue. La méthode Copie/Coller est souple parce que vous pouvez choisir exactement ce que vous voulez copier. Vous pouvez tout sélectionner dans la géodatabase personnelle ou juste certains éléments, tels qu'un ensemble de jeux de classes d'entités à migrer. Par exemple, pour copier un jeu de classes d'entités d'une géodatabase personnelle dans une géodatabase fichier, créez une géodatabase fichier vide dans l'arborescence du catalogue. Sélectionnez les éléments de votre choix dans la géodatabase personnelle, cliquez avec le bouton droit sur la sélection, sélectionnez Copier, puis cliquez avec le bouton droit sur la géodatabase fichier et sélectionnez Coller. Pour plus d'informations, reportez-vous à la rubrique Copie de jeux de classes d'entités, de classes et de tables vers une autre géodatabase.

  La méthode Copie/Coller peut migrer tout type de données dans la géodatabase sauf les domaines attributaires qui ne sont référencés par aucune classe d'entités ou table. Si vous avez de tels domaines et que vous voulez les faire migrer, utilisez la méthode d'exportation vers un document d'espace de travail XML décrite ci-après.

• Pour copier la totalité d'une géodatabase, utilisez la commande Exporter > Document d'espace de travail XML afin d'exporter l'ensemble de la base de données dans un fichier XML. Vous pouvez alors créer une nouvelle géodatabase fichier vide et utiliser Importer > Document d'espace de travail XML pour importer les données depuis le fichier XML vers la géodatabase fichier. Cette méthode est également flexible dans la mesure où vous pouvez choisir les jeux de données à exporter dans l'assistant d'exportation. Pour plus d'informations, reportez-vous aux rubriques suivantes :Exportation de jeux de classes d'entités, de classes et de tables dans un fichier d'export et Importation de jeux de classes d'entités, de classes et de tables à partir d'un document d'espace de travail XML.
• Si vous effectuez une migration de données de géodatabase à faible précision, les méthodes Copier/Coller et d'exportation vers un document d'espace de travail XML convertissent automatiquement les données en haute précision, en définissant la résolution sur 0,1 millimètre environ. Cette valeur par défaut est appropriée et fonctionne bien dans presque tous les cas. Cependant, si vous souhaitez que les données soient stockées à une résolution différente, utilisez l'outil Mettre à jour la référence spatiale avant d'effectuer une migration de données avec Copier/Coller ou une exportation vers un document d'espace de travail XML. Mettre à jour la référence spatiale convertit les données en haute précision, en vous permettant de choisir la résolution. Une autre méthode pour contrôler la résolution consiste à effectuer une migration avec les outils de géotraitement d'importation/exportation. Pour plus d'informations, reportez-vous à la rubrique Migration vers la haute précision.
• Pour transférer des fichiers de formes, des couvertures ou des données dans un autre format vers une géodatabase fichier, utilisez la même méthode que celle que vous utiliseriez pour déplacer les données dans une géodatabase personnelle. Sélectionnez le jeu de données dans l'arborescence du catalogue, cliquez avec le bouton droit et sélectionnez la commande Exporter > Vers une géodatabase ; utilisez la commande Géodatabase (multiple) pour exporter simultanément plusieurs jeux de données. Ces outils sont également disponibles dans ArcToolbox sous Conversion > Vers une géodatabase. Pour plus d'informations, reportez-vous aux rubriques suivantes : Importation d'entités, Importation de tables et Importation de jeux de données raster.

Les géodatabases fichier ont des mots-clés de configuration qui permettent de personnaliser la manière dont chaque jeu de données est stocké. Vous pouvez spécifier un mot-clé quand vous copiez et collez, ou importez des données, bien que la valeur par défaut soit habituellement adéquate. Pour plus d'informations, reportez-vous à la rubrique Mots-clés de configuration pour les géodatabases fichier.

Création de jeux de données

Créez un jeu de classes d'entités, une classe d'entités, un catalogue d'images, un jeu de données raster et une table vides dans une géodatabase fichier de la même manière que dans une géodatabase personnelle : cliquez avec le bouton droit sur la géodatabase ou le jeu de classes d'entités, pointez sur Nouveau, puis sélectionnez l'élément que vous souhaitez créer. Pour plus d'informations, consultez les rubriques suivantes :

Création de nouveaux jeux de données à l'aide d'ArcCatalog

Création de jeux de données raster dans une géodatabase

Création de catalogue d'images dans une géodatabase

Une fois que vous avez créé une classe d'entités ou une table vide, vous y chargez des données depuis l'arborescence du catalogue. Pour plus d'informations, reportez-vous à la rubrique A propos du chargement de données dans des classes d'entités et des tables existantes et Importation de jeux de données raster.

A la différence des géodatabases personnelles, chaque fois que vous créez une classe d'entités, un catalogue d'images, un jeu de données raster ou une table de géodatabase fichier à l'aide de l'arborescence du catalogue ou d'un outil de géotraitement, vous pouvez éventuellement spécifier un mot-clé de configuration. Le mot-clé de configuration personnalise la manière dont les données sont stockées et la façon d'y accéder. Pour obtenir une description des mots-clés disponibles, reportez-vous à la rubrique Mots-clés de configuration pour les géodatabases fichier.

Mise à jour, affichage et interrogation des données

Une fois qu'il figure dans une géodatabase fichier, un jeu de données a un aspect est similaire dans ArcCatalog et ArcMap à que ce qu'il aurait dans une géodatabase personnelle. En outre, vous utilisez les jeux de données de la même manière, à l'exception des index spatiaux et des requêtes SQL qui sont présentés ci-après. Toutes les commandes et tous les outils qui acceptent les jeux de données de géodatabase personnelle en entrée acceptent également les jeux de données de géodatabase fichier.

L'index spatial d'une classe d'entités de géodatabase personnelle utilise une taille de grille unique qui ne peut pas être modifiée. L'index spatial d'une classe d'entités de géodatabase fichier utilise jusqu'à trois tailles de grille que vous pouvez modifier à tout moment. ArcGIS recrée automatiquement l'index spatial, à la fin de certaines opérations de mise à jour pour optimiser celui-ci, ainsi que ses tailles de grille. Cependant, vous pouvez avoir à recalculer l'index manuellement dans quelques rares cas. Pour plus d'informations, reportez-vous à la rubrique Définition des index spatiaux.

La syntaxe de la clause SQL WHERE que vous utilisez pour interroger les géodatabases fichier est la même que celle utilisée sur les couvertures, les fichiers de formes et les autres sources de données basées sur les fichiers, avec quelques fonctionnalités supplémentaires, telles que la prise en charge des sous-requêtes. Par conséquent, la syntaxe de la clause SQL WHERE est différente de celle des géodatabases personnelles. Les boîtes de dialogue permettant de créer des expressions SQL dans ArcGIS vous aident à utiliser la syntaxe de clause WHERE correcte pour les données que vous interrogez ; elles répertorient également les noms et les valeurs de champ avec les délimiteurs appropriés. De plus, elles sélectionnent automatiquement les mots-clés et les opérateurs pertinents. Cependant, si une clause WHERE est définie pour une couche d'une géodatabase personnelle, elle risque de ne pas fonctionner sur la même couche une fois que vous avez déplacé ses données source dans une géodatabase fichier. Les raisons possibles pour que la clause WHERE ne fonctionne pas sont les suivantes :

• Pour les géodatabases personnelles, les noms de champ sont placés entre crochets, alors que pour les géodatabases fichier, ils sont placés entre des guillemets doubles.
• Le caractère générique utilisé sur les géodatabases personnelles est * pour tout nombre de caractères et ? pour un seul caractère. Les géodatabases fichier utilisent % et _, respectivement.
• Les recherches de chaîne dans les géodatabases personnelles ne respectent pas la casse, alors qu'une distinction majuscules/minuscules est effectuée pour les géodatabases fichier.
• Les géodatabases personnelles utilisent UCASE et LCASE pour convertir la casse des chaînes, alors que les géodatabases fichier utilisent UPPER et LOWER.
• Les dates et les heures dans les géodatabases personnelles sont délimitées à l'aide du caractère #, alors que dans les géodatabases fichier, elles sont précédées par le mot date.

Syntaxe de clause WHERE pour une géodatabase personnelle	Syntaxe équivalente pour une géodatabase fichier
[STATE_NAME] = 'California'	"STATE_NAME" = 'California'
[OWNER_NAME] LIKE '?atherine smith'	"OWNER_NAME" LIKE '_atherine smith'
[STATE_NAME] = 'california' (lorsqu'une recherche sans distinction des majuscules et des minuscules est requise)	LOWER("STATE_NAME") = 'california'
UCASE([LAST_NAME]) = 'JONES'	UPPER("LAST_NAME") = 'JONES'
[DATE_OF_BIRTH] = #06-13-2001 19:30:00#	"DATE_OF_BIRTH" = date '2001-06-13 19:30:00'

Exemples de la façon dont SQL doit changer pour une géodatabase personnelle avant de pouvoir fonctionner dans une géodatabase fichier

Une autre raison pour laquelle une clause WHERE peut ne pas fonctionner est que les géodatabases fichier prennent en charge moins d'opérateurs et de fonctions que les géodatabases personnelles. De plus, les géodatabases fichier fournissent une prise en charge limitée pour les sous-requêtes. Cependant, il est peu probable que la clause WHERE ne fonctionne pas pour cette raison. Les géodatabases fichier prennent en charge la majorité des fonctionnalités de clause WHERE dont vous aurez vraisemblablement besoin.

Géotraitement

Il existe peu de différences entre la manière dont vous utilisez des outils de géotraitement sur les géodatabases fichier et sur les géodatabases personnelles :

• Les géodatabases fichier sont prises en charge dans tous les outils de géotraitement.
• Pour créer une géodatabase fichier, utilisez l'outil Créer une géodatabase fichier.
• Chaque fois que vous utilisez un outil qui crée une classe d'entités, un catalogue d'images, un jeu de données raster ou une table dans une géodatabase fichier, vous pouvez éventuellement spécifier un mot-clé de configuration pour personnaliser le mode de stockage des données. Cette option est disponible pour certains outils. Si l'option n'est pas disponible, vous pouvez spécifier le mot-clé de configuration dans la boîte de dialogue Environnements.

Compression des données vectorielles

Contrairement aux géodatabases personnelles et ArcSDE, les géodatabases fichier vous permettent d'éventuellement stocker les données vectorielles dans un format compressé en lecture seule afin de réduire les besoins de stockage. Les données compressées constituent un format d'accès direct. Vous n'avez pas à décompresser les données lorsque vous y accédez : ArcGIS et ArcReader les lisent directement. L'apparence des données est la même que lorsqu'elles étaient décompressées, et vous exécutez toutes les opérations en lecture seule de la même manière, à l'aide d'une commande de l'arborescence du catalogue, du géotraitement ou d'ArcObjects. Pour plus d'informations, reportez-vous à la rubrique A propos de la compression de données d'une géodatabase fichier.

Migration des applications

Si vous avez une application écrite dans ArcObjects et que vous aimeriez transférer les données auxquelles elle accède d'une géodatabase personnelle vers une géodatabase fichier, prenez en compte les points suivants :

• Mettez à jour le générateur d'espace de travail pour que l'application fonctionne sur la nouvelle source de données. Modifiez le générateur d'espace de travail d'AccessWorkspaceFactory en FileGDBWorkspaceFactory et changez l'extension de géodatabase de .mdb en .gdb.
• Si votre application utilise SQL, la syntaxe aura besoin vraisemblablement d'une mise à jour pour fonctionner sur une géodatabase fichier :
  • Comme expliqué précédemment dans cette rubrique, la syntaxe de la clause SQL WHERE varie entre les géodatabases fichier et personnelles. Si votre application utilise QueryFilter ou QueryDef, reportez-vous aux explications précédentes sur la clause WHERE pour connaître les modifications que vous aurez probablement à effectuer.
  • Les géodatabases fichier ne prennent pas en charge toutes les entités et toutes les fonctions disponibles pour les géodatabases personnelles. Pour ArcGIS 9.2, les fonctions les plus fréquemment utilisées non prises en charge par les géodatabases fichier incluent DISTINCT, GROUP BY et ORDER BY, et les fonctions de définition AVG, COUNT, MIN, MAX et SUM AVG ne sont pas prises en charge en dehors des sous-requêtes. La prise en charge de quelques-unes de ces fonctions sera vraisemblablement ajoutée dans les prochaines versions.
  • La prise en charge de jointure QueryDef pour les géodatabases fichier est limitée en ce sens que les sous-champs peuvent contenir des noms de colonnes simples uniquement ; les alias, les expressions et les fonctions ne sont pas pris en charge. La clause FROM peut contenir uniquement des noms de table simple.
  • La prise en charge d'ExecuteSQL pour INSERT et UPDATE dans les géodatabases fichier est limitée aux instructions simples ne contenant que des valeurs littérales. Les expressions composées telles que

    SET RENTAL_PRICE = (RENTAL_PRICE - 1.00)
    

    ainsi que les sous-requêtes, ne sont pas prises en charge dans les instructions INSERT et UPDATE. Les instructions DELETE, en revanche, ne sont pas limitées ; elles prennent en charge toutes les fonctionnalités de clause WHERE acceptées par la géodatabase fichier.
  • Si votre application contient des sous-requêtes, ces dernières risquent de ne pas fonctionner avec les géodatabases fichier car leur prise en charge est limitée. Pour plus d'informations, reportez-vous à la rubrique Référence SQL.
• Pour optimiser les performances de transfert de données, pensez à utiliser le mode chargement uniquement chaque fois qu'un grand nombre d'enregistrements est chargé. Pour plus d'informations, reportez-vous à la section "Conseils relatifs aux performances" ci-dessous.

Mis à part ces différences, ArcObjects fonctionne de la même manière sur les géodatabases fichier et les géodatabases personnelles.

Conseils relatifs aux performances

Les points suivants peuvent vous aider à améliorer et à gérer les performances de géodatabase fichier :

• La résolution par défaut quand vous créez une nouvelle classe d'entités est de 0,1 millimètre ou son équivalent dans les unités du système de coordonnées du jeu de données. La valeur par défaut pour la résolution x,y fonctionne dans presque tous les cas. Si vos données ne sont pas si précises, vous pouvez éventuellement définir une résolution x,y plus élevée lorsque vous créez la classe d'entités. Le stockage des coordonnées avec une résolution x,y plus élevée diminue les besoins en espace de stockage et améliore les performances. Cette règle ne s'applique pas uniquement aux géodatabases fichier, mais aussi aux géodatabases ArcSDE. Pour plus d'informations sur la résolution x,y, reportez-vous à la rubrique Principes de base des classes d'entités.
• Comme avec toute autre source de données, créez seulement les index attributaires dont vous avez vraiment besoin, car chaque index ajouté ralentit légèrement les mises à jour apportées à la classe d'entités ou à la table. Chaque fois vous modifiez un attribut indexé, ArcGIS doit aussi mettre à jour l'index. Si vous devez modifier fréquemment un champ, évitez de créer un index pour ce dernier dans la mesure du possible.
• Si vous envisagez d'ajouter, de modifier ou de supprimer un grand nombre d'entités ou d'enregistrements dans un jeu de données volumineux, à l'aide d'une session de mise à jour, d'un outil de géotraitement ou de l'arborescence du catalogue, vous pouvez gagner du temps en supprimant l'index spatial et tous les index attributaires affectés avant de commencer, puis en les recréant une fois les modifications effectuées.

  Chaque fois que vous ajoutez, modifiez ou supprimez une entité ou un enregistrement, ArcGIS doit mettre à jour les index. Si vous apportez les modifications sur un petit jeu de données, ou à seulement quelques enregistrements, par exemple, 10 enregistrements sur 1 million, le temps nécessaire à ArcGIS pour mettre à jour les index après chaque modification incrémentielle ne représentera pas un problème. Par contre, si vous effectuez les modifications sur un grand nombre d'enregistrements, par exemple, 300 000 sur 1 million, la mise à jour des index pour les nombreuses modifications incrémentielles peut prendre beaucoup plus de temps que si vous supprimez les index avant de commencer, puis ajoutez les index après les modifications. Décider s'il faut supprimer des index dans d'autres cas implique des compromis et peut ne pas être un choix évident. De la même manière, les développeurs qui écrivent des programmes de chargement ou des convertisseurs avec ArcObjects doivent envisager d'utiliser le mode chargement uniquement chaque fois qu'un grand nombre d'enregistrements est chargé. Le mode chargement uniquement suspend la mise à jour de tous les index attributaires et spatiaux jusqu'à ce que les entités aient été importées. Une fois que toutes les entités ont été importées, les index pour tous les enregistrements, existants et nouveaux, sont mis à jour automatiquement. Vous définissez ce mode à l'aide de l'interface IFeatureClassLoad.

• Comme avec les géodatabases personnelles, si vous ajoutez et supprimez fréquemment des données, vous devez compacter régulièrement votre géodatabase fichier. Il est également conseillé de compacter une géodatabase fichier après toute modification importante. Le compactage améliore les performances en réorganisant la manière dont les données sont stockées sur le disque. Pour plus d'informations, reportez-vous à la rubrique Compactage de géodatabases fichier et personnelles.
• Comme avec l'utilisation de tout autre type de fichier stocké dans le système de fichiers, faites en sorte que votre ordinateur soit en bon état et optimisé. Si vous exécutez Windows, lancez de temps en temps la défragmentation du disque pour assurer de bonnes performances globales du système de fichiers. La défragmentation du disque est une option du système d'exploitation Windows ; pour plus d'informations, consultez l'aide en ligne de votre système d'exploitation.
• Des tailles de grille d'index spatial trop faibles ou trop importantes peuvent entraîner des temps de chargement accrus et des performances de recherche spatiale médiocres. ArcGIS recrée automatiquement l'index spatial à la fin de la plupart des opérations pour optimiser les tailles de grille. Vous avez rarement besoin de recalculer l'index manuellement. Cependant, certaines situations où vous ajoutez de nombreuses entités dans une session de mise à jour peuvent exiger un nouveau calcul manuel. Pour plus d'informations, reportez-vous à la rubrique Définition des index spatiaux.