Suite au succès des bases de données relationnelles, qui gèrent des données "traditionnelles" style chaine de caractère, entier, réel, décimal, double, etc. La communauté des chercheurs et les éditeurs de SGBD ont tenté de faire pareil en essayant de trouver un moyen simple de gérer les données spatiales avec la même élégance que celle faite dans les bases de données relationnels, c'est à dire Gérer en natif les données spatiales: ajouter un autre type géométrie aux autres types présents dans la BDR.
Sauf ceci n'est évident, et il ne suffit pas de rajouter un type géométrie et puis c'est tout. Il faut avoir un langage déclaratif de type SQL pour définir les données, ensuite pour les interroger, et il faut également trouver un moyen pour indexer ces volumes de données spatiales.
La tâche n'est pas facile, et les éditeurs ont mis du temps pour s'approprier ce problème, et les recherches ont mis du temps pour essayer soit de d'étendre le langage standard des bases de données relationnelles SQL, soit de proposer de nouveaux langages déclaratifs pour cet objectif. Je rappele que le succès des BDR était d'avoir pu proposer un langage déclaratif SQL. L'avantage avec un langage déclaratif c'est l'utilisateur exprime par le langage ce qu'il veut obtenir, et laisse le soin au moteur de la base de données de chercher comment il recherche l'information dans la base de données.
Pour schématiser les données spatiales à stocker, on peut citer les points, les lignes, les polylignes, les polygones, etc. L'idée des BDS est de proposer un type de données spatiales que l'on peut définir pour ces données là.
Exp:
CREATE TABLE "nom de table"
("colonne 1" "long",
"colonne 2" "chaine de caractère",
"colonne spatiale" "type spatiale",
... )
Dans le cas d'Oracle Locator ou Spatial, le type spatial utilisé s'appelle SDO_GEOMETRY.
Une fois ces données spatiales sont stockées dans des tables, il faut les exploiter par, si possible un langage encore une fois déclaratif comme SQL. La principale différence avec le cas des données standards, c'est le filtre "Where" qui doit tenir compte de la spécificité spatiale, qui doit proposer des opérations spatiales : - mesures spatiales: trouver la distance entre des points, le calcul de surface, etc
- fonctions spatiales: modifier les couches spatiales pour en créer de nouvelles, par exemple, en dessinant un buffer, calcul des intersections, etc.
- Prédicats spatiaux: permettre des requêtes de style Vrai/faux comme 'Existe -t-il une résidence localisé à moins d'un KM de la zone industrielle'
- autre fonction et requêtes: pour plus d'informations, se référer aux spécifications de l'Open Geospatial Consortium.
Tout ceci est bien, sauf que pour pouvoir optimiser ces requêtes et le stockage de ces données, il nous faut autre chose. Imaginer que ma base de données spatiales contient des millions d'objets spatiaux et je demande dans ma requête de me récuperer un fragment de ces données. Naïvement, je dois parcourir tout les éléments de ma base pour récupérer les données qui m'interessent. C'est possible sauf que ca peut être couteux en terme de temps de réponse. Une des solutions perfomantes pour répondre à ce sujet, il y a l'utilisation des indexes. Dans les BDR le sujet d'indexation des données a été largement débattu et ce depuis le premier sytème relationnel System-R (le premier noyau de ce qu'a ramené la révolution relationnelle). Des indexes de style arbre binaire ont été largement adoptée par les SGBD comme le Btree, Btree+, Btree *, Hashage, les index Bitmap pour les données multidimentionnelles (Datawarehouse). Tout ceci c'est bien mais ne répond pas trop aux spécificités des données spatiales, et il a fallut essayer de trouver de nouveaux types d'indexes qui organisent les données spatiales en tenant compte de leur géométrie. Ainsi des indexes ont vu le jour comme le Rtree (Region Tree), QuadTree, KD-Tree, ainsi que d'autres indexes. je rappele que la recherche continue toujours de trouver d'autres adaptations de ces indexes pour mieux cerner les types de requêtes possibles spatiales. Je rappelle ici que le type le plus utilisé est celui du Rtree (utilisé par Oracle Spatial). Dans de prochains posts j'essayerais de présenter en détail chacun de ces indexes spatiaux, montrer leur particularités, à quoi ils servent, et comment se font les insertions, les modifications et les suppressions dans ces indexes et avec quelle complexité algorithmique. Un domaine qui a contribué beaucoup à l'élaboration des indexes spatiaux est la géométrie algorithmique ou ce que l'on a habitude d'appeler en anglais Computational geometry: A Very Exciting Domain. Sinon en attendant mes prochains posts: voir l'excellent livre de Hanane Samet :Foundations of Multidimensional And Metric Data Structures
Pour terminer, je rappelle ici les quelques SGBD commerciaux et OpenSource qui propose la gestion en natif des données spatiales: Oracle Spatial, DB2 Spatial Extender, Informix Spatial Datablade, MySQL Spatial, PostGres/PostGIS, et le tout nouveau dans la famille SQL Server 2008.
Aucun commentaire:
Enregistrer un commentaire