Lorsque vous créez une table ou ajoutez une colonne à une table dans une base de données, vous définissez un type de données spécifique pour la colonne. Les types de données déterminent les éléments suivants :
- Les valeurs que vous pouvez stocker dans la colonne
- Les opérations que vous pouvez utiliser sur les données de cette colonne
- La manière dont les données de cette colonne sont stockées dans la base de données
ArcGIS utilise des types de données spécifiques. Lorsque vous accédez à une table de base de données via un nœud Connexions aux bases de données ou via une couche de requête, ArcGIS élimine tous types de données non pris en charge. ArcGIS n'affiche pas les types de données non pris en charge et vous ne pouvez pas les modifier via ArcGIS. De la même façon, lorsque vous utilisez ArcGIS pour copier et coller des tables qui contiennent des types de données non pris en charge d'une base de données vers une autre, ArcGIS colle uniquement les colonnes qui utilisent un type de données pris en charge.
La première colonne de la table suivante répertorie les types de données ArcGIS. La deuxième colonne répertorie le type de données Oracle qu'ArcGIS crée. La troisième colonne indique les autres types de données Oracle (le cas échéant) correspondant au type de données ArcGIS lorsque vous consultez une table créée en dehors d'ArcGIS. La dernière colonne fournit des informations supplémentaires lorsque cela est nécessaire.
| types de données ArcGIS | Types de données Oracle créés | Autres types de données Oracle pouvant être affichés | Remarques |
|---|---|---|---|
BLOB | BLOB | ||
Date | TIMESTAMP | ||
DOUBLE | NUMBER(38,8) | NUMBER(p,s) | La précision et l'échelle spécifiées dans ArcGIS peuvent affecter le type de données obtenu créé dans la base de données. Reportez-vous à la rubrique Types de données des champs ArcGIS pour plus d'informations. |
FLOAT | NUMBER(38,8) | NUMBER(p,s) | La précision et l'échelle spécifiées dans ArcGIS peuvent affecter le type de données obtenu créé dans la base de données. Reportez-vous à la rubrique Types de données des champs ArcGIS pour plus d'informations. |
GEOMETRY | ST_GEOMETRY, NUMBER(38), or SDO_GEOMETRY | Le type de données Oracle créé dépend du stockage de géométries spécifié lors de la création de la classe d'entités. Binaire compressé ou binaire connu (géodatabases uniquement) = NUMBER(38) ; Oracle Spatial = SDO_GEOMETRY ; type spatial = ST_GEOMETRY. Pour utiliser ST_Geometry dans une base de données, vous devez l'installer. | |
ID global | CHAR or NCHAR (UUID LEN) | Pris uniquement en charge dans les géodatabases. Le champ d'identifiant unique est créé au format NCHAR si le paramètre UNICODE_STRING du mot-clé de configuration avec lequel vous avez créé la table est défini sur TRUE. | |
GUID | CHAR or NCHAR (UUID LEN) | Le champ d'identifiant unique est créé en tant que NCHAR dans une géodatabase si le paramètre UNICODE_STRING du mot-clé de configuration avec lequel vous avez créé la table était défini sur TRUE. | |
LONG INTEGER | NUMBER(38) | NUMBER(n) | La valeur n peut être comprise entre 5 et 10. Si les données sont créées avec ArcGIS for Desktop ou ArcObjects et que la précision est définie sur 0, un type NUMBER(38) est créé dans la base de données, sinon la précision indiquée est utilisée. |
Identifiant d’objet | NUMBER(38) lorsqu'il est créé dans une géodatabase d'entreprise NUMBER(38) avec une séquence et un déclencheur lorsqu'il est créé dans les cas suivants :
NUMBER(38) est toujours généré en tant qu'identité lorsque vous utilisez ArcGIS pour créer une classe d'entité ou une table dans une base de données Oracle 12c ou utilisez l'outil de géotraitement Ajouter un champ d'ID d'incrémentation pour ajouter un champ d'ID à une table dans une base de données Oracle 12c. | L'identifiant d'objet de type ArcGIS est la colonne d'ID de ligne enregistrée pour la table (ou classe d'entités.) Une seule colonne par table. | |
RASTER | BLOB, LONG RAW, SDO_GEORASTER, or ST_RASTER | Les rasters sont uniquement pris en charge dans les géodatabases. Le type de données utilisé dans le champ raster dépend du mot-clé de configuration que vous spécifiez lors de la création du catalogue d'images, du jeu de données raster ou de la mosaïque. | |
SHORT INTEGER | NUMBER(5) | NUMBER(n) | La valeur n peut être comprise entre 1 et 5. Toutefois, les colonnes de nombres entiers courts peuvent uniquement stocker des valeurs comprises entre -32,768 et 32,767. Même si la précision du nombre est 5, vous ne pouvez pas stocker de nombre supérieur à 32 767 ou inférieur à - 32 768 dans une colonne de nombres entiers courts. Lors de la création avec ArcGIS for Desktop, n = 5. Cela permet de stocker des nombres entiers courts contenus dans la plage autorisée. |
TEXT | VARCHAR2, CLOB, NVARCHAR2 ou NCLOB |
Types de données texte
Lorsque vous insérez un champ de texte dans la table que vous créez dans ArcGIS, le type de données VARCHAR2 est utilisé si la base de données n'est pas paramétrée pour utiliser le codage Unicode. Si la taille du champ de texte que vous configurez est supérieure à 4 000 et que la base de données n'est pas définie pour utiliser le codage Unicode, le type de données Oracle sera CLOB.
Un champ de texte sera créé au format NVARCHAR2 si la base de données est paramétrée pour utiliser le codage Unicode. (Il s'agit du paramètre par défaut pour les géodatabases dans Oracle.) Si la taille du champ de texte que vous configurez est supérieure à 2 000 et si la base de données est définie pour utiliser le codage Unicode, le type de données Oracle sera NCLOB.
Types de géométrie
Comme cela est indiqué dans la table, ArcGIS crée et peut manipuler trois types de géométrie dans Oracle : Esri ST_Geometry, Oracle SDO_Geometry et binaire compressé. Le stockage de géométrie au format binaire compressé ne peut être utilisé que dans des géodatabases.
ST_Geometry
Voici une description générale du type de donnée spatiale ST_Geometry : Pour obtenir des informations propres à une implémentation Oracle, reportez-vous à la rubrique ST_Geometry dans Oracle.
Le type de données ST_Geometry implémente les spécifications SQL 3 pour les types de données définis par l'utilisateur (UDT), qui permettent de créer des colonnes capables de stocker des données spatiales telles que la localisation d'un point de repère, d'une rue ou d'une parcelle. Il permet un accès à la géodatabase et à la base de données en langage SQL (structured query language) conforme aux normes de l'ISO (International Organization for Standards) et de l'OGC (Open Geospatial Consortium). Ce stockage étend les capacités de la base de données en permettant le stockage d'objets qui représentent des entités géographiques (points, lignes et polygones). Il a été conçu pour utiliser de façon efficace les ressources de la base de données, pour être compatible avec les fonctions de la base de données, telles que la réplication et le partitionnement et pour permettre un accès rapide aux données spatiales.
Bien que vous puissiez définir une colonne en tant que type ST_Geometry, vous n'insérez pas de valeurs ST_Geometry dans la colonne puisqu'elle ne peut pas être instanciée. Vous insérez plutôt les valeurs de la sous-classe.
ST_Geometry est un résumé, une super classe non instanciée. Toutefois, ses sous-classes peuvent être instanciées. Un type de données instancié peut être défini comme une colonne de tableau pouvant accueillir des valeurs de son type.
Le diagramme suivant montre la hiérarchie du type de données ST_Geometry et de ses sous-classes.
Les sous-classe de ST_Geometry sont divisées en deux catégories : sous-classes de géométrie de base et sous-classe d'ensembles homogènes. Les géométries de base comprennent les objets ST_Point, ST_LineString et ST_Polygon, alors que les ensembles homogènes comprennent les objets ST_MultiPoint, ST_MultiLineString et ST_MultiPolygon. Comme ces noms l'indiquent, les ensembles homogènes sont des ensembles de géométries de base. En plus des propriétés communes aux géométries de base, les ensembles homogènes disposent également de quelques propriétés propres.
Chaque sous-classe stocke le type de géométrie que son nom indique ; par exemple, ST_MultiPoint stocke des multi-points. Le tableau suivant fournit une liste des sous-classes et leurs descriptions :
| Sous-type | Description |
|---|---|
| ST_Point |
|
| ST_LineString |
|
| ST_Polygon |
|
| ST_MultiPoint |
|
| ST_MultiLineString |
|
| ST_MultiPolygon |
|
SDO_Geometry
SDO_Geometry est mis en œuvre via le système de type relationnel orienté objet extensible d'Oracle. Le type SDO_Geometry est proposé par Oracle avec deux options principales :
- Oracle Spatial est un module optionnel du logiciel Oracle Database Enterprise Edition. En plus du type SDO_Geometry, Oracle Spatial offre de nombreuses fonctionnalités géospatiales supplémentaires.
- Oracle Locator offre un sous-ensemble des fonctionnalités d'Oracle Spatial. Il est compris dans les composants standard des éditions Standard et Enterprise de la base de données Oracle. Parmi ses fonctionnalités figurent le type de géométrie Oracle Spatial (connu sous le nom de SDO_Geometry) et une interface API SQL pour ce contenu.
ArcGIS prend en charge SDO_Geometry en tant que méthode facultative de stockage de données spatiales. En particulier, la géométrie Oracle Spatial ou Oracle Locator permet le stockage et la gestion de contenus d'entités et de raster de jeux de données figurant dans des géodatabases d'entreprise ou des bases de données Oracle.
Le type SDO_Geometry permet de stocker les informations sur une géométrie, y compris son type, son identifiant de référence spatiale, son type d'interpolation (droite ou courbe) et ses valeurs de coordonnées. Dans des géodatabases, le type SDO_Geometry prend en charge les points uniques et multi-parties, les lignes et les géométries surfaciques. Les géométries peuvent être décrites avec une interpolation linéaire entre les coordonnées, telle que mentionnée par la spécification d'OpenGIS relative aux entités simples. Les géométries peuvent également être construites à partir de courbes circulaires ou d'une combinaison des deux méthodes d'interpolation. Les applications procèdent à l'insertion, la mise à jour et la récupération du contenu du type SDO_Geometry à l'aide d'une interface SQL relationnelle orientée objet d'Oracle. Les applications sont également chargées d'assurer que le contenu de chaque géométrie respecte les règles définies dans la documentation d'Oracle Spatial. Oracle propose des routines de validation de la géométrie pouvant être exécutées après l'insertion des géométries. En outre, à partir d'Oracle 11.1.0.7, la géométrie est validée lors des insertions d'index.
Les informations sur chaque colonne SDO_Geometry doivent être enregistrées dans la structure de métadonnées d'Oracle Spatial, bien qu'Oracle Spatial ne s'en charge pas automatiquement. (La structure de métadonnées d'Oracle Spatial est présentée pour chaque structure comme étant la vue USER_SDO_GEOM_METADATA.) Le logiciel qui crée les colonnes SDO_Geometry doit insérer les métadonnées pour ces colonnes. ArcGIS s'en charge pour toutes les classes d'entités SDO_Geometry qu'il crée. Les métadonnées contiennent le nom de colonne spatiale, le nom de la table où elle figure et son propriétaire, l'identifiant de la référence spatiale (SRID) Oracle, le nombre de dimensions, la plage de chaque dimension et sa tolérance de coordonnées.
Les index spatiaux fournissent un accès rapide aux entités à partir de la localisation de leur géométrie. Pour SDO_Geometry, les index spatiaux d'arborescence R sont en général les plus efficaces et les plus faciles à créer, et Oracle conseille leur utilisation dans la plupart des situations. Oracle Spatial comprend l'utilitaire Spatial Index Advisor, permettant de déterminer le meilleur type d'index spatial pour une table donnée. Vous pouvez également vous reporter au Guide de l'utilisateur Oracle Spatial pour des informations détaillées sur les types d'index spatiaux pris en charge, sur leur procédure de création et les compromis des différentes méthodes d'indexation spatiale.
Oracle Spatial élargit la portée d'SQL par l'ajout de fonctions de recherche spatiale pour le filtrage primaire et secondaire. L'inclusion de la fonction SDO_FILTER dans une requête SQL lance une recherche spatiale primaire à l'aide de l'index spatial. Les prédicats spatiaux, tels que SDO_RELATE et SDO_CONTAINS, renvoient des relations secondaires entre paires d'objets SDO_Geometry. Oracle Spatial intègre des fonctions de transformation spatiale modifiant la forme d'une valeur SDO_Geometry. Par exemple, la fonction SDO_BUFFER calcule les coordonnées d'un nouvel objet SDO_Geometry formant une zone tampon à une distance donnée autour de la géométrie originale. Les fonctions de transformation spatiale comprennent également SDO_DIFFERENCE et SDO_INTERSECTION.
Oracle Spatial propose de nombreux systèmes de référentiels de coordonnées prédéfinis par l'intermédiaire d'une valeur SRID. La valeur SRID, stockée dans l'objet SDO_Geometry, indique la référence de coordonnée pour la géométrie stockée dans cet objet. Si elle n'est pas NULL, la valeur SRID dans l'objet SDO_Geometry est une clé étrangère d'une table contenant des détails sur chaque SRID. Cette table s'appelle MDSYS.CS_SRS. La fonction SDO_TRANSFORM définit des transformations de référentiel de coordonnées grâce à l'identifiant de référence spatiale. ArcGIS utilise également cette information pour créer des références spatiales.
Binaire compressé
Le type de stockage binaire compressé d'Esri utilise un mécanisme de stockage binaire pour stocker la géométrie des entités. Une classe d'entités binaire compressée est composée de trois tables : la table métier, la table des entités et la table d'index spatial.
Après avoir vérifié la géométrie, l'application cliente la compresse et l'envoie à la géodatabase, où elle est stockée dans un format binaire compressé dans une table d'entités, également appelée table F. La compression de la géométrie sur le client supprime la tâche du serveur de base de données et réduit le temps de transmission de la géométrie. Elle permet également d'améliorer l'efficacité du stockage et de l'extraction des données spatiales en réduisant de près de 40 pour cent l'espace disque nécessaire.
La table métier contient des attributs et une colonne spatiale. La colonne spatiale est une clé permettant d'accéder à la table d'entités et à la table d'index spatial.
La relation entre la table métier et la table des entités est gérée par la colonne spatiale et la colonne d'identifiant de l'entité (FID). Cette clé conservée par ArcGIS est unique.
Types de données raster
Vous pouvez utiliser les options BLOB, Long Raw, ST_Raster ou SDO_GeoRaster pour les colonnes raster de jeux de données raster, de catalogues d'images ou de mosaïques.
Reportez-vous à la section BLOB de cette rubrique pour en savoir plus sur les BLOB dans Oracle.
Oracle a déconseillé le type de données Long Raw. Evitez de l'utiliser, car il ne sera plus pris en charge. Bien que le type de données Long Raw fonctionne toujours, il est préférable de ne pas l'utiliser car vous devrez à l'avenir migrer vers un autre type de stockage.
Les deux sous-sections suivantes décrivent les autres types de données raster.
ST_Raster
ST_Raster est un type de données défini par l'utilisateur que vous pouvez installer dans des géodatabases d'entreprise pour permettre un accès SQL aux données raster.
Pour utiliser le type de données ST_Raster, vous devez le configurer dans la base de données. Reportez-vous à la rubrique Installer ST_Raster dans Oracle.
Pour obtenir davantage d'informations sur la définition d'un type d'objet ST_Raster, consultez la rubrique Type de données ST_Raster.
SDO_GeoRaster
Le type de données raster SDO_GeoRaster d'Oracle Spatial est implémenté à l'aide du système de type relationnel orienté objet extensible d'Oracle. Le type SDO_GeoRaster stocke des informations sur un raster, y compris son type de pixel, son ID de référence spatiale et ses valeurs de pixel.
Le type SDO_GeoRaster prend en charge tous les types de pixel Esri : 1 bit à 64 bits, signé, non signé et à virgule flottante. ArcGIS prend en charge le type de données SDO_GeoRaster d'Oracle Spatial en tant qu’option de stockage des données raster.
Dès la création d'une table contenant une colonne de type SDO_GeoRaster Oracle, ArcGIS remplit la structure de métadonnées Oracle nécessaire. Ces tâches reposent sur des applications telles qu'ArcGIS, car Oracle ne les exécute pas automatiquement. Si vous inscrivez une table contenant une colonne de type SDO_GEORASTER Oracle créée par un produit tiers, ce produit doit remplir correctement la structure de métadonnées Oracle pour la colonne SDO_GeoRaster.
Limites connues d'utilisation de SDO_GeoRaster avec une géodatabase
La liste suivante indique les limites à connaître lors du stockage de données raster au format SDO_GeoRaster dans votre géodatabase d’entreprise.
- Oracle ne prend pas en charge les mises à jour segmentées pour SDO_GeoRaster. Par conséquent, il est impossible de mosaïquer des fichiers image dans un jeu de données raster stocké au format SDO_GeoRaster.
- Les pyramides ne peuvent pas être construites pendant l'insertion de données. Après l'insertion de données d'image dans un type de données raster SDO_GeoRaster, une mise à jour distincte est nécessaire pour la construction de la pyramide. Il est donc conseillé de toujours désactiver la case à cocher Générer la structure pyramidale des boîtes de dialogue des outils de géotraitement ArcGIS qui assurent la création de jeux de données raster ou de catalogues d'images.
- Vous ne pouvez pas utiliser de stockage SDO_GeoRaster dans une base de données Oracle 11g R2 suite au bogue Oracle 12537431. Si vous utilisez le stockage SDO_GeoRaster, utilisez Oracle 11g R1 ou des versions ultérieures.
- Oracle implémente SDO_GeoRaster comme une architecture intégrée par canal. Par conséquent, il est impossible d'ajouter ou de supprimer des canaux individuels d'un jeu de données raster.
- ArcGIS ne prend pas en charge l'existence de plusieurs colonnes raster dans une même table. Pour accéder aux tables contenant plusieurs colonnes SDO_GeoRaster, il est conseillé d'utiliser les vues ne contenant qu'une seule colonne SDO_GeoRaster. Créez une vue de la table et n'ajoutez qu'une colonne SDO_GeoRaster dans la définition de la vue.
- Lorsque le stockage SDO_GeoRaster est utilisé dans une géodatabase, les masques binaires NoData ne sont pas pris en charge. Il n'est donc pas possible d'élaborer une pyramide sur des données normales non carrées.
BLOB
BLOB est un acronyme du secteur des systèmes de gestion de bases de données (SGBD), signifiant grand objet binaire. Les colonnes BLOB ont été implémentées il y a plusieurs années par Oracle Corporation en remplacement de la technologie LONG RAW pour le stockage des données binaires.
L'architecture du type de données BLOB est divisée en trois composants de base : colonne BLOB, segment LOB et index LOB. La colonne BLOB stocke le localisateur LOB (36 octets) et les données binaires dans la ligne si elles représentent moins de 3 965 octets et si le stockage dans la ligne n'a pas été désactivé pour la colonne.
Si les données binaires dépassent 3 964 octets, l'espace de stockage dans la ligne de la colonne BLOB n'est pas attribué et le localisateur LOB référence les données binaires stockées dans le segment LOB.
Par conséquent, une valeur stockée dans une colonne BLOB avec le stockage dans la ligne activé comporte toujours au moins 36 octets (l'espace attribué au localisateur LOB) et peut atteindre jusqu'à 4 000 octets (combinaison de l'espace attribué au localisateur LOB et de l'espace maximal pouvant être attribué aux données binaires stockées dans la ligne).
Le segment LOB est divisé en blocs. La taille des blocs doit être un multiple de la taille des blocs de données Oracle. Par exemple, si la taille de bloc de données est de 8 Ko, le segment LOB peut être créé avec une taille minimum de segment de 8 Ko. Si la longueur des données stockées dans le segment LOB est de 5 000 octets, ces dernières sont stockées dans le segment LOB car elles dépassent 3 964 octets et la taille de segment est de 8 Ko ou 8 192 octets. Dans ce cas, 3 192 octets du bloc de segment LOB restent inutilisés. Le transfert de données de LONG RAW à BLOB peut nécessiter un espace plus important, éventuellement jusqu'à 30 pour cent de plus, en raison de l'espace inutilisé dans le segment LOB. Cela est inévitable si vos données dépassent le seuil de stockage dans la ligne de la colonne BLOB, fixé à 3 964 octets.
Une taille de bloc égale à 8 Ko permet une performance E/S optimale et une perte d'espace minimale. Une taille de bloc égale à 16 Ko entraîne une perte d'espace plus importante qu'une taille de 8 Ko. Afin d'éviter la perte d'espace, il est donc conseillé de recréer la base de données dont la taille de bloc de données est actuellement de 16 Ko avec un bloc de données de 8 Ko. Si ce n'est pas possible, créez des segments LOB dans des tablespaces créés avec une taille de bloc de 8 Ko. Pour cela, vous devez attribuer un cache de tampon de 8 Ko dans le bloc SGA (Oracle System Global Area).
Les tailles de bloc de 4 Ko et 2 Ko permettent de limiter la perte d'espace mais l'augmentation en opérations E/S amène à déconseiller leur utilisation.
L'index LOB est utilisé uniquement si le localisateur LOB concerne plus de 12 blocs ; autrement, les 12 premiers blocs sont traités par le localisateur LOB.
Les trois figures ci-dessous illustrent les possibilités de stockage pour les données binaires stockées dans une colonne BLOB. Dans le premier cas, 3 000 octets de données binaires sont stockés dans une ligne, car ce volume correspond à une valeur inférieure au seuil de stockage dans la ligne, défini sur 3 965 octets. Si le stockage dans la ligne n'est pas désactivé pour la colonne BLOB, le segment et l'index LOB ne sont pas utilisés. En général, cela permet une extraction plus rapide des données BLOB en raison du nombre réduit d'opérations E/S, Oracle n'ayant besoin d'accéder ni au segment LOB ni à l'index LOB.
La figure suivante illustre le deuxième cas, dans lequel le volume de données binaires dépasse 3 964 octets (dans ce cas, les données représentent 81 920 octets) et ne peuvent pas être contenues dans la ligne. Par conséquent, le localisateur LOB référence les données binaires stockées dans le segment LOB. Puisque les données binaires n'occupent pas plus de 12 blocs dans le segment LOB, le localisateur LOB stocke les adresses correspondantes. Dans ce cas, l'index LOB n'est pas utilisé.
Dans la dernière illustration, les données binaires ont une taille telle (106 496 octets) que l'index LOB devient nécessaire. Dans ce cas, le stockage des données binaires nécessite un espace supérieur à celui disponible dans la ligne et plus de 12 blocs dans le segment LOB. Pour des données de cette taille, le localisateur LOB référence l'index LOB afin d'obtenir l'emplacement des blocs dans le segment LOB. Ce cas est extrêmement rare pour les données vectorielles et peut être évité pour les données raster.
Pour plus d'informations sur la définition du stockage BLOB, reportez-vous à la rubrique Paramètres de configuration Oracle.