Organisé en deux parties, ce cours présente les bases théoriques et pratiques des systèmes d’information géographique. - Il propose une introduction aux systèmes d’information géographique qui ne requiert pas de connaissances préalables en informatique - Il donne la possibilité d’acquérir rapidement les notions de base qui vous permettent de créer des bases de données spatiales et de fabriquer des cartes géographiques - Il s’agit d’un cours pratique qui repose sur l’utilisation de logiciels libres, notamment QGIS En somme, si vos études ou votre profession comprennent des activités liées à la gestion de territoires, à l’analyse d’objets distribués dans l’espace géographique (aménagement du territoire, biologie, santé publique, écologie, énergie, etc.), ce cours est fait pour vous! En suivant cette première partie du cours, vous explorerez les principes de base de la numérisation du territoire et du stockage des géodonnées. Vous apprendrez notamment à : - Caractériser des objets et/ou phénomènes spatiaux (modélisation du territoire) du point de vue de leur positionnement dans l’espace (systèmes de coordonnées et projections, relations spatiales) et en fonction de leur nature intrinsèque (mode objet ou vecteur vs. mode image ou raster), - Utiliser les diverses méthodes d’acquisition de données (mesure directe, géoréférencement d’images, digitalisation, source de données existantes, etc.) - Utiliser les divers modes de stockage des géodonnées – Fichiers simples et/ou bases de données relationnelles - Utiliser des outils de modélisation des données pour décrire et implémenter une base de données - Créer des requêtes dans le langage d’interrogation et de manipulation des données La seconde partie du cours portera sur les méthodes d'analyse spatiale et les techniques de représentation des géo-données. Vous apprendrez notamment à: - Analyser les propriétés spatiales de variables discrètes, par exemple en quantifiant l’autocorrélation spatiale - Travailler avec les variables continues (échantillonnage, construction de courbes d’isovaleurs, méthodes d’interpolation) - Utiliser les modèles numériques d'altitude et leurs dérivées (pente, orientation, etc.) - Utiliser les techniques de superposition de géodonnées et d'interaction entre elles - Produire des documents cartographiques selon les règles de la sémiologie graphique - Explorer d’autres formes de représentation spatiale (cartographie interactive sur internet, représentations 3D, etc.) La page https://www.facebook.com/moocsig fournit un forum interactif pour les participants à ce cours.
Bases de données noSQL
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Systèmes d’Information Géographique - Partie 1
99 notes
À partir de la leçon
Stockage - SQL spatial et bases de données NoSQL
Alors que les leçons de la semaine précédente traitaient des divers aspects généraux du langage SQL, celles du début de cette dernière semaine couvrent le thème des requêtes SQL spécifiquement liées aux dimensions et relations spatiales caractérisant les géodonnées (requêtes spatiales géométriques et topologiques).Une brève incursion dans le domaine en pleine expansion des bases de données NoSQL et un cas d’étude consacré à la gestion des feux de brousse en Afrique sub-saharienne viennent conclure cette première partie du MOOC d’introduction aux systèmes d’information géographique, qui se termine par un second test de connaissances
Rencontrer les enseignants
Stéphane Joost
Laboratoire de systèmes d'information géographique
Marc Soutter
Laboratoire de Systèmes d'Information Géographique
Fernand Koffi KouaméProfesseur
Centre Universitaire de Recherche et d'Application en Télédétection (CURAT) - Université Félix HOUPHOUET-BOIGNY d'Abidjan-Cocody (Côte d'Ivoire)
Amadou Sall
Département de Géomatique - Centre de Suivi Ecologique (CSE), Sénégal
[MUSIQUE]
[MUSIQUE]
[MUSIQUE] Cette
leçon va donc
porter sur les bases de données NoSQL qui sont une vaste famille regroupant un
grand nombre de types de bases de données différentes, et qui se distinguent en
fait des bases de données relationnelles classiques que nous avons vu jusqu'à
présent par le fait qu'à l'origine elles n'implémentaient pas le langage SQL.
Donc la logique de stockage de l'information est un peu différente,
et les règles d'utilisation également.
Nous aborderons toutes ces questions au cours de la leçon.
L'objectif de cette leçon est donc de compléter un petit peu ce que nous avons
appris des bases de données relationnelles en ouvrant le champ à l'exploration
des bases de données NoSQL, et peut-être plus
particulièrement à l'une d'entre-elles qui est la base de données Mongo.
Au terme de cette leçon vous devriez être en mesure d'expliquer en quoi le
monde NoSQL se différencie du monde des bases de données relationnelles, et
vous devriez être capables d'utiliser un petit peu l'une de ces bases de données.
Dans cette leçon nous parlerons tout d'abord des origines du NoSQL,
puis nous passerons en revue les différents types de bases de données NoSQL
et les systèmes de gestion de bases de données qui leurs sont associés,
avant de concentrer notre attention plus particulièrement sur MongoDB qui est
un type de base de données NoSQL, et pour terminer
nous verrons comment les fonctions CRUD, donc Create,
Read, Update, Delete, sont implémentées dans un système comme MongoDB.
[MUSIQUE] Nous avons
vu dans le leçon portant sur les bases de données relationnelles que ce type de base
de données stocke les données dans des tables dont les colonnes ont des types
bien définis, que ces tables peuvent être liées entre elles par des relations,
que l'interrogation des données repose sur un langage standardisé,
le SQL, et finalement que les transactions effectuées dans ces tables
répondent en général au principe ACID,
à savoir atomicité, cohérence, isolation et durabilité.
Atomicité signifiant que toutes les modifications
d'une transaction doivent être effectuées avec succès,
faute de quoi l'ensemble de ces modifications doit être invalidé.
Cohérence qu'une transaction n'est validée que si toutes les règles en vigueur sont
respectées, sur le type de données, les contraintes, les primaires,
valeurs nulles possibles ou pas, etc.
Isolation signifie que l'exécution simultanée de deux transactions
est équivalente à leur exécution séquentielle,
donc une transaction n'affecte pas d'autres transactions.
Et la durabilité signifie qu'après validation les données sont
enregistrées de manière durable, indépendamment d'erreurs,
de crashs ou d'autres dysfonctionnements qui peuvent survenir.
La seconde génération Web a vu apparaître des services qui gèrent
des très gros volumes de données comme Google, Amazon, Facebook, LinkedIn, etc.
Et qui doivent faire face à de brusques afflux de trafic ponctuels.
Afflux de trafic signifie généralement diminution du temps de réponse,
diminution de l'enthousiasme des utilisateurs et perte de rentabilité,
d'où la nécessité de maintenir les fonctionnalités et les performances en cas
de forte demande, caractéristique que l'on appelle la scalabilité ou l'évolutivité.
Ce maintien des fonctionnalités et des performances peut être obtenu
par accroissement de puissance, et l'on parle alors de scalabilité verticale,
ou par démultiplication des noeuds et distribution des services sur
les noeuds du réseau, et l'on parle alors de scalabilité horizontale.
Un meilleur ajustement des logiciels aux types de données gérées permet également
d'accélérer le traitement des données et de maintenir la performance.
On voit donc que les bases de données NoSQL regroupe un ensemble d'alternatives
aux bases de données relationnelles, qui ont été développées dès la fin des années
90 pour répondre au besoin de maintien des performances de certains
gros acteurs du Web qui gèrent de très grosses bases de données,
de complexité faible à modéré.
Les principales différences,
caractéristiques des bases de données NoSQL se trouvent tout d'abord dans la
forme de stockage des données, qui diffère pas mal de ce à quoi
l'on est habitué dans le monde des bases de données relationnelles.
Dans le fait de ne pas fournir,
en tout cas à l'origine, d'implémentation du langage SQL.
Dans le fait de ne pas apporter de support aux jointures,
donc on ne peut pas faire de jointures dans les bases de données NoSQL.
De fonctionner en système distribué, c'est-à-dire de distribuer les données
sur plusieurs serveurs, et finalement une
tendance à ne pas implémenter les règles, les principes ACID.
Le principe de la scalabilité horizontale est donc de vouloir distribuer
le service ou les données sur les nombreuses machines constituant un réseau,
donc sur un ensemble de noeuds, conduit tout droit à ce théorème dit théorème CAP,
qui stipule que seuls deux des trois critères de cohérence, de disponibilité,
et de tolérance au partitionnement peuvent être satisfaits simultanément.
Cohérence signifiant que tous les noeuds d'un système voient exactement les mêmes
données au même moment.
Disponibilité que chaque fois que l'on envoie une requête vers
l'un des noeuds du système on est certain de recevoir une réponse.
Soit en terme de succès ou d'échec de la requête, mais on reçoit une réponse.
Et la notion de tolérance au partitionnement
qui exprime l'idée en fait que dans un système distribué il arrive
fréquemment que les différents nœuds puissent être isolés les uns des autres,
soit parce qu'un nœud ne fonctionne plus, il a été victime d'un crash, une coupure
de courant, des ruptures de communication, la communication en passe plus, etc.
Dans le cas des systèmes NoSQL où on essaye de
répartir la charge et l'information sur les nombreux nœuds d'un réseau,
le partitionnement est une réalité, si bien que en fait
il faut choisir de privilégier la cohérence ou la disponibilité.
Dans le premier cas les systèmes que l'on appelle CP, donc plutôt cohérence et
partitionnement, cela signifie que l'on attend une synchronisation des nœuds,
avant d'assurer la réponse avec le risque d'avoir de temps en temps des timeout ou
des messages d'erreur, et donc le critère de disponibilité n'est pas respecté,
ou alors on va vers des solutions AP, donc où l'on privilégie la disponibilité.
Dans ce cas-là le noeud que l'on interroge va renvoyer la dernière version disponible
d'une donnée au niveau d'un nœud, ce qui veut dire qu'on accepte que tous les nœuds
puissent ne pas être toujours à jour et des fois renvoyer des valeurs différentes.
Après toute la question est de savoir
quelle est la durée de mise à jour tolérable.
On voit que les bases de données relationnelles,
qui de par leur nature même, de par l'existence de relations entre les tables,
se prêtent mal en fait à une distribution des données sur plusieurs machines
différentes, se trouvent en général dans le registre CA,
donc cohérence et disponibilité, mais ne se prêtent pas du tout à
une scalabilité horizontale par répartition sur un réseau.
[MUSIQUE]
[MUSIQUE] Si l'on regarde d'un peu plus près le monde des bases de données NoSQL,
on s'aperçoit qu'on peut distinguer quatre grandes familles de bases de
données NoSQL, qui se distinguent par la manière dont elles stockent l'information.
La première de ces familles est constituée par les bases de données de type
clé-valeur, qui sont donc basées sur des dictionnaires, permettant d'accéder
à la valeur d'un objet par l'intermédiaire d'une clé qui doit être unique.
Comme exemple on peut voir ici que la clé peut être représentée par un prénom,
Pierre ou Henri, qui donne accès à une série de valeurs,
le type d'activité, l'âge, le type d'activité sportive, etc.
Les principaux systèmes de gestion de bases de données qui implémentent ce type
clé-valeur sont Redis et Voldemort,
qui a donc été développé par LinkedIn pour gérer ses bases de données.
Le second type de bases de données NoSQL est le type orienté colonne,
qui s'apparente un petit peu au modèle relationnel,
puisque les données en fait peuvent être représentées par des tables.
Simplement le stockage est organisé par colonne, sur une base clé-valeur où
on associe pour chaque colonne la clé avec la valeur de cette clé dans cette colonne.
L'avantage de ce système est de permettre une gestion très dynamique
d'un nombre très élevé de colonnes.
Les principaux systèmes de gestion de bases de données qui implémentent ce
modèle sont Cassandra, Hbase, BigTable et Vertica.
Le troisème type de base de données NoSQL que l'on appelle orientée document
propose également sur un paradigme clé-valeur en associant à
la clé des documents qui sont de type JSON ou XML.
Donc on a ici toujours le même exemple de Pierre et de Henri,
avec Etudiant1 et Etudiant2 qui sont les clés, et derrière une
syntaxe JSON qui donne les attributs de l'objet.
Les systèmes de gestion de bases de données qui implémentent ce modèle
sont principalement CouchDB, SimpleDB et MongoDB.
Et finalement les bases de données
NoSQL de type orienté graphe, qui se basent sur la théorie des graphes,
sur les notions de noeuds, de relations et de propriétés pour stocker
l'information ici relative aux étudiants Pierre et Henri.
Le principal et seul, quasiment, système de gestion de bases de données,
seul système un peu abouti, est Neo4J.
Dans cette figure qui reprend les idées du théorème CAP, on a représenté en fait les
différents types de systèmes de gestion de bases de données en fonction
de leurs caractéristiques, de leur positionnement dans ce diagramme,
en représentant en rouge orangé les systèmes gestion de bases de données
relationnelles, notamment Postgres, MySQL etc.
Les systèmes en vert de type clé-valeur, comme Voldemort et Redis,
les systèmes orientés colonne en jaune, avec Cassandra du côté CP,
Hbase et BigTable du côté AP, et finalement en bleu les systèmes
SGBD orientés document, où l'on voit que MongoDB est
un système qui est du côté de la disponibilité, alors que
ses alter egos SimpleDB et CouchDB sont plutôt du côté de la cohérence.
[MUSIQUE] [MUSIQUE]
MongoDB est donc une base de données NoSQL libre de type orienté document.
Dans cette base de données la notion de table qu'on avait dans les bases de
données relationnelles est remplacée par la notion de collections.
On a donc ici l'exemple de la table 'iii' des hôtels des Seychelles,
et si l'on regarde comment ces données sont gérées dans Mongo on a ici un
interface-utilisateur qui permet de voir cette collection d'objets,
donc les hôtels, 124 objets dans la collection, et puis pour chaque
objet une structure arborescente, l'identifiant et le type d'objet, la
collection de ses propriétés, la géométrie et dans la géométrie les coordonnées.
Cette représentation arborescente peut être transformée en
représentation au format JSON, où on retrouve
cette idée de collection dans la syntaxe propre au format JSON.
Elle peut également être représentée dans une vue tabulaire,
simplement avec des étages successifs que l'on peut parcourir
pour accéder aux coordonnées ou aux propriétés des objets.
Second élément important la notion de schéma de données, qui dans une base de
données relationnelles est très importante, incontournable.
Dans un système comme Mongo on est libre de stocker les données absoluement comme
on veut, de mettre tout ce qu'on veut dans une collection.
Par contre si l'on veut pouvoir utiliser les données stockées dans une base de
données Mongo pour représenter des objets dans une carte,
on a intérêt à ce que ces objets suivent une certaine structure
pour retrouver en fait les coordonnées du point et les propriétés de l'objet.
La meilleure manière de retrouver cette structure c'est de
stocker au départ des objets qui ont cette structure.
En d'autres termes la base de données Mongo n'est pas contraignante
du point de vue schématisation des données,
par contre de négliger la schématisation rend la vie beaucoup plus compliquée.
Dénormalisation et jointure,
dans un système de base de données relationnelles lorsque l'on veut
ajouter un élément d'information, comme dans le cadre des hôtels des Seychelles si
on souhaite ajouter l'information relative au propriétaire de ces hôtels.
Comme plusieurs hôtels peuvent avoir le même propriétaire,
pour éviter la redondance de données on créerait une table séparée, indirecte,
qui recense les propriétaires,
et on ajouterait dans la table d'origine une colonne avec l'identifiant des
propriétaires, et l'on établirait ainsi une jointure entre ces deux tables.
Ce processus de séparation de données c'est ce qu'on appelle,
dans le monde base de données relationnelles, la normalisation.
Notons au passage que l'une des faiblesses du monde relationnel, qui a déjà été
évoquée lorsqu'on a présenté ce domaine, la difficulté qu'il y aurait
ici à stocker l'information dans le cas où un hôtel aurait plusieurs propriétaires.
Dans le cas de Mongo on pourrait bien entendu procéder d'une manière analogue en
ajoutant dans le document JSON un champ ID du propriétaire, et
puis en ayant une liste toujours au format JSON de propriétaires avec leur adresse.
Notons au passage que la syntaxe JSON permet facilement de
représenter le cas de plusieurs propriétaires.
En réalité dans le monde NoSQL, comme on n'implémente pas les jointures,
on préfère lister explicitement les éléments d'informations
liés aux propriétaires, quite à vivre avec une certaine redondance.
C'est pour cette raison que les systèmes NoSQL se prêtent particulièrement bien
à gérer des grands volumes de données, mais des données qui ont une
faible complexité avec peu de relations tabulaires.
Dans le cas où on a des systèmes de données complexes, avec des tables qui
sont liées les unes aux autres, le système base de données relationnelles reste plus
intéressant en général.
[MUSIQUE] Pour terminer
nous allons voir quelques exemples d'implémentation des fonctions de base
des bases de données, donc les fonctions de création, de lecture, de mise à jour
et de suppression de données que l'on regroupe sous l'acronyme CRUD.
On commence avec l'insertion de données.
On va systématiquement comparer la
syntaxe SQL avec la syntaxe que l'on retrouve dans Mongo.
Donc dans le SQL, l'introduction d'un nouveau
jeu de données dans la table des hôtels implique les mots clés INSERT INTO,
la liste des colonnes et puis la liste des valeurs correspondant à ces colonnes.
Dans le cas de Mongo on a quelque chose un peu d'équivalent
avec simplement les mots-clés db qui réfèrent à la base de données en cours,
hôtels c'est la collection visée, puis on insère dans cette collection un
nouvel objet qui a quatre attributs, le nom, le nombre de chambres,
le nombre de lits et le statut avec les valeurs de ces quatre attributs.
Mise à jour de données, dans le cas SQL le mot-clé UPDATE,
la table hôtels et puis le mot-clé SET, la variable que l'on souhaite changer,
donc la variable chambres qui passe à 6, et puis la clause conditionnelle
pour identifier l'hôtel sur lequel le nombre de chambres a augmenté à six.
L'équivalent du côté Mongo avec le mot clé update également qui s'applique sur
la collection hôtels, et puis simplement la référence à l'objet qui va changer,
donc les objets dont le nom correspond à Beach Bungalows,
et on va appliquer un set sur la variable chambre qui prend la valeur 6.
Donc dans l'esprit quelque chose assez similaire au langage SQL.
Pour la suppression de données, le DELETE FROM du langage SQL suivi du
nom de la table, et puis de la clause conditionnelle que l'on
retrouve à peu près à l'identique dans Mongo avec la fonction remove
appliquée à la collection hôtels et puis on supprime le document qui
a pour attribut nom Beach Bungalows.
Enfin quelques exemples de requêtes plus générales, à commencer par
la requête de sélection des hôtels dont le nombre de chambres est supérieur à 10,
donc dans le SQL SELECT FROM classique avec une clause conditionnelle.
Dans Mongo on retrouve le mot-clé find qui permet de rechercher des objets,
le critère de recherche dans la première ligne, donc le champ chambres,
et puis l'opérateur plus grand que caractérisé par
l'esperluète qui précède le mot-clé gt, puis le critère 10,
et dans la deuxième ligne les choses que l'on souhaite renvoyer.
Comme l'identifiant de l'objet est renvoyé par défaut,
on doit mettre un 0 si on peut pas avoir l'identifiant,
et puis un 1 pour renvoyer le nom, donc c'est 0, 1, true, false.
Un second exemple de requête basique similaire,
donc compter le nombre d'objets renvoyés par la requête de sélection
des hôtels dont le nombre de chambres est supérieur à 10, avec quelque chose d'assez
équivalent dans Mongo, une fonction count, appliqué à la collection des hôtels,
et portant sur le fait que le nombre des chambres est égal à dix.
Dernier exemple de requête un peu plus élaborée où l'on cherche à lister
le nombre d'hôtels qu'il y a dans chaque statut, pour chaque statut.
Donc dans le SQL une requête classique avec un groupement par statut,
et on compte dans chaque statut le nombre de candidats.
Dans le cas de MongoBD on utilise le mot clé de la fonction
d'agrégation portant sur la collection des hôtels avec comme règle de groupement
le statut, et comme règle de calcul la somme.
Ces quelques exemples montrent donc que dans un logiciel non SQL comme Mongo
qui n'implémente pas le langage SQL, on dispose quand-même d'un
langage de requête qui permet d'interroger les données de manière efficace,
langage qui est d'ailleurs implémenté dans l'interface graphique.
Mais avant de passer à l'interface graphique, regardons déjà comment se
présentent les choses en ligne de commande qui est quand-même le mode d'utilisation
initial et principal de Mongo, donc avec Mongo, la commande Mongo,
on accède aux iii de Mongo, use Seychelles pour dire qu'on veut utiliser la
base de données Seychelles, qui va s'appeler maintenant DB, et DB hotels,
donc en référence la collection des hôtels et on cherche le premier objet de la
collection qui est l'hôtel Beach Bungalow donc affiché en format JSON.
Dans le cas d'un interface utilisateur graphique un peu plus élaboré,
on a un petit outil de création de requêtes.
On peut par exemple glisser le champ nom,
et rechercher tous les hôtels dont le nom commence par b.
Et on en trouve eh bien toute une série, série
habituelle.
Voilà.
[MUSIQUE]
[MUSIQUE] [MUSIQUE] Dans cette
leçon nous avons donc exploré un petit peu le monde des bases données non SQL,
nous avons notamment vu un petit peu pour quelles raisons ces bases
de données avaient été développées comme alternatives aux modèles relationnels.
Nous avons vu qu'il existait quatre types principaux de bases de données non SQL,
caractérisées par la manière dont elles gèrent le stockage de l'information,
nous avons ensuite approfondi un petit peu les caractéristiques de MongoBD,
qui est donc une base de données de type orienté document.
et nous avons vu comment la donnée était gérée, comment on gère la schématisation,
la structuration de l'information,
nous avons vu comment on gère les jointures et ce genre de choses.
Et pour conclure, nous avons pris quelques exemples de l'implémentation des
fonctionnalités principales d'interrogation de données,
d'insertion de données, de mises à jour, de requêtes, en comparant
la syntaxe du monde SQL avec la syntaxe utilisée dans un logiciel comme Mongo,
pour arriver à la conclusion que, même si dans la forme les choses sont assez
différentes, dans l'esprit, on fait assez facilement le passage de l'un à l'autre.
Voilà c'était donc la dernière leçon de cette première partie du cours,
alors j'en profite pour féliciter à l'avance tous ceux d'entre vous qui
m'auront suivi jusque là [APPLAUDISSEMENT] bravo!
[MUSIQUE] [MUSIQUE]
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
