Le modèle de stockage des géodatabases repose sur les principes du système de gestion de base de données et tire parti des concepts simples mais essentiels des bases de données relationnelles. Le système de gestion de base de données (et le système de fichiers pour les géodatabases fichier) fournit un modèle de données formel simple qui permet de stocker et d'utiliser des informations dans des tables.
Les concepts clés sont notamment les suivants :
- Les données sont organisées en tables.
- Les tables contiennent des lignes.
- Toutes les lignes d'une table possèdent les mêmes colonnes.
- Chaque colonne comporte un type, tel qu'un entier, un nombre décimal, un caractère ou une date.
- Les relations permettent d'associer les lignes d'une table aux lignes d'une autre table. Cette opération repose sur une colonne commune dans chaque table.
- Les tables comportent des règles d'intégrité relationnelle. Par exemple, chaque ligne partage toujours les mêmes colonnes, un domaine répertorie les valeurs ou les plages de valeurs valides pour une colonne, etc.
Pour les géodatabases d'entreprise stockées dans des bases de données relationnelles, certaines fonctionnalités supplémentaires s'appliquent également :
- Le langage SQL (Structured Query Language), série de fonctions relationnelles et d'opérateurs, fonctionne sur les tables et leurs éléments de données.
- Les opérateurs SQL sont conçus pour fonctionner avec les types de données relationnelles génériques, tels que des entiers, des nombres décimaux, des dates et des caractères.
Par exemple, une classe d'entités est stockée en tant que table de système de gestion de base de données. Chaque ligne représente une entité. Les colonnes dans chaque ligne représentent différentes caractéristiques ou propriétés de l'entité et une des colonnes comporte la géométrie de l'entité (par exemple des coordonnées de point, ligne ou polygone).
Le type de colonne utilisé pour stocker les données géométriques dans le champ de forme varie selon le système de gestion de base de données, mais il s'agit généralement d'un type spatial étendu. Par exemple, au moins un type spatial pour le stockage des entités est disponible pour tous les systèmes de gestion de bases de données dans lesquels ArcGIS prend en charge les géodatabases. L'utilisation des types spatiaux permet d'accéder aux entités avec SQL, qui est conforme aux normes ISO (International Organization for Standardization) et OGC (Open Geospatial Consortium, Inc.) pour les types spatiaux.
SQL fonctionne sur les lignes, colonnes et types dans les tables. La base de données gère ces tables et types de données simples, tandis qu'une logique d'application supplémentaire dans ArcGIS implémente un comportement d'objet plus complexe et des contraintes d'intégrité.
Implémentation d'un comportement et d'objets de niveau supérieur dans les systèmes de gestion de bases de données relationnelles
Les développeurs qui souhaitent implémenter des objets de niveau supérieur avec un comportement et une logique doivent écrire un code d'application. Une organisation peut par exemple implémenter une table des employés comme suit :
Nom | Prénom | Date d'embauche | Salaire |
---|---|---|---|
Marron | Ben | 10-10-2001 | 10 000,50 $ |
Jones | Betty | 06-14-1998 | 22 000,00 $ |
Smith | Jason | 08-23-1999 | 44 000,75 $ |
La table des employés est une table de données relationnelles simples contenant des lignes et des colonnes. Les données de chaque colonne respectent un type de données en particulier, tel qu'un caractère, une date et un nombre. Les bases de données utilisent des informations à ce niveau.
Toutefois, le simple ajout de ces informations à une table ne permet pas de transformer la base de données en système de gestion des paies ou des employés. L'ajout d'une colonne Salaire qui contient des nombres décimaux ne permet pas de transformer une base de données en système comptable. Une logique d'application de niveau supérieure est nécessaire.
Les embauches, la mise en place d'une augmentation de salaire, la démission des employés et la gestion des bénéfices sont des exemples de logique pouvant être implémentée en vue de soutenir les activités liées à l'emploi. Les objets commerciaux modélisés pour les employés, ainsi que leurs noms, salaires et dates d'embauche ne sont pas implémentés en tant qu'objets relationnels. Une logique d'application plus sophistiquée et plus ciblée est nécessaire pour implémenter un comportement et une intégrité sur ces objets commerciaux.
Des objets commerciaux similaires sont universellement appliqués dans les SIG. Par exemple, les topologies, réseaux, systèmes de référencement linéaire et MNT sont tous des exemples d'objets avancés qui permettent d'implémenter un comportement SIG en plus des simples représentations spatiales stockées dans la base de données.
Comme avec d'autres applications de systèmes de gestion de bases de données, les tables avec des types de colonnes spatiales ne sont pas nécessairement suffisantes par elles-mêmes pour les applications SIG. Les deux ensembles d'objets (les types de colonnes de bases de données simples et les objets d'application de géodatabase comme les topologies) sont nécessaires pour construire des systèmes d'informations géographiques complets.
A quel endroit la logique d'application appartient-elle ?
Un grand nombre d'implémentations de systèmes de gestion de bases de données ont démontré de manière radicale que l'utilisation d'un niveau d'application distinct qui fonctionne sur les lignes et types de colonnes dans les tables convient aux applications avancées. Par exemple, tous les systèmes d'informations clients (CIS), les systèmes ERP et les paquetages de comptabilité largement adoptés implémentent une logique d'application avancée au niveau de l'application, ce qui donne lieu à plus d'ouverture et d'extensibilité, des performances accrues, des jeux d'outils plus riches et une flexibilité optimisée.
Les utilisateurs réalisent et interagissent avec des transactions au sein de ces systèmes via la logique d'application pour la grande majorité des opérations et utilisent uniquement le langage SQL pour certaines activités ciblées (et appropriées).
Séparer la logique d'application au-dessus du niveau des données permet par ailleurs d'appliquer la même logique aux systèmes de gestion de bases de données, fichiers, langage XML et aux autres modes de stockage des données. Cette architecture est ainsi plus ouverte. Par exemple, la logique d'application de géodatabase dans ArcGIS permet également de lire et d'utiliser toutes les sources de données géographiques, telles que les données DAO, les fichiers de formes, les données MapInfo, les fichiers Intergraph et les fichiers GML (Geography Markup Language).
Les autres manières de préserver cette logique de niveau supérieur sont notamment les procédures stockées et les déclencheurs de bases de données dans le système de gestion de base de données ou les types étendus dans la base de données.