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 relationnelles
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Systèmes d’Information Géographique - Partie 1
105 notes
À partir de la leçon
Stockage - Organisation et structuration des géodonnées
Dans cette 4ème semaine, qui marque le début du second module du cours consacré au stockage, nous commençons par traiter des aspects fondamentaux du stockage des géodonnées et des divers types de fichiers susceptibles de les héberger, avant d’aborder le thème des bases de données relationnelles et de son corollaire qui est la modélisation des données. La semaine se conclu par une leçon portant sur la création de bases de données dans l’environnement QGIS et par un cas d’étude consacré au rôle des SIG dans un projet de planification des transports et d’aménagement urbain au Sénégal.
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]
[MUSIQUE] Bienvenue dans ce cours qui va porter sur les bases de données
relationnelles qui sont la forme la plus largement répandue de bases de données
et que l'on retrouve dans absolument tous les domaines de la vie courante.
Les objectifs de cette leçon consistent donc à découvrir les bases de données.
En particulier, les bases de données relationnelles.
Et la manière dont la dimension spatiale est intégrée dans ces bases de données.
Et au terme de cette leçon, vous devriez être capables de décrire le
concept qui fonde les bases de données relationnelles,
ainsi que les divers types d'objets qu'elle contient.
Dans la leçon précédente, nous avons vu plusieurs formes de stockage de
données sous forme de fichiers simples, de fichiers semi-structurés.
Aujourd'hui, nous allons passer en revue la suite des
possibilités de stockage de données.
A savoir les bases de données qui permettent un stockage plus structuré et
la plupart du temps un stockage centralisé dans une architecture client serveur.
Dans cette leçon, nous allons aborder la question de la définition d'une base de
données, les notions de fiabilité de ces bases de données.
Nous ferons un bref survol historique
de l'évolution des différents types de bases de données.
Puis, nous nous concentrerons sur le modèle relationnel que nous
verrons assez en détails.
Et puis, nous parlerons ensuite de la manière dont la composante spatiale est
gérée dans cette base de données.
Et pour finir, un premier bref aperçu des logiciels SGBD.
Donc, des logiciels systèmes de gestion de bases de données
que nous verrons aussi à plusieurs reprises dans les cours suivants.
[MUSIQUE] Une
base de données peut être définie comme une collection de données persistantes.
Éventuellement centratralisée,
utilisée par plusieurs applications et par plusieurs groupes d'utilisateurs qui
peuvent éventuellement travailler en parallèle.
On voit qu'avec cette définition très générale,
les fichiers d'hébergements de données que nous avons vus lors de la précédente
leçon peuvent aussi être considérés comme des bases de données, dans la mesure où
elles offrent une certaine persistance au stockage d'informations.
Les systèmes de gestion de bases de données sont par contre des logiciels
qui permettent de créer, de structurer, de documenter,
de consulter les bases de données.
Il s'agit en fait de l'interface qui existe entre base de données et les
utilisateurs ou les applications qui utilisent les bases de données.
Comme le montre cette image, il en existe un très grand nombre.
Autant dans le domaine commercial que dans le domaine du logiciel libre.
Les modifications d'une base de données sont le fruit de transactions.
Les transactions étant une suite d'opérations qui
font passer la base de données d'un état initial à un état final.
Et pour qu'une base de données passe d'un état
initial intègre et cohérent à un état final intègre et cohérent,
les transactions doivent respecter un certain nombre de critères,
qui sont l'atomicité, la cohérence, l'isolation et la durabilité.
Critères que l'on résume souvent sous le nom de propriétés ACID et
que nous allons voir un peu plus en détail à présent.
Le principe d'atomicité stipule que la transaction se fait
complètement ou pas du tout.
Dans le cas ici d'une transaction qui comprend deux opérations,
la première consistant à retrancher 10 à un ensemble A.
Et la seconde, à ajouter 10 à un ensemble B.
Avec pour condition de validité, que A + B = 100.
On voit que l'opération se fait en deux étapes pour
arriver à un résultat qui est ensuite enregistré dans la base de données,
par une opération qui s'appelle un Commit.
Une opération de validation.
Il peut arriver que l'une de ces deux opérations échoue.
Et dans ce cas-là, le principe d'atomicité veut que la première opération de la
transaction puisse être réversible et annulée.
Donc, on puisse retourner en fait à l'état initial de la base de données.
Les bases de données doivent vérifier des principes de cohérence.
Si nous avons ici l'exemple d'une transaction qui consiste à retrancher 5
d'un ensemble A et à ajouter 10 à un ensemble B, avec une condition de validité
A + B = 100 comme tout à l'heure, on voit bien qu'au terme de la transaction,
le résultat ne respecte plus la condition de validité.
Si bien que la validation doit être empêchée
et l'opération dans son ensemble annulée.
Le principe d'isolation.
On a ici le cas de deux transactions.
La première consistant à retrancher 10 d'un ensemble A,
à ajouter 10 à un ensemble B.
Avec toujours la même condition de validité.
Et une deuxième transaction qui fait à peu près la même opération.
On retranche 5 de l'ensemble B, on ajoute 5 à l'ensemble A.
Et en fait, le principe d'isolation veut que l'exécution
de ces transactions l'une après l'autre donne le même résultat que si les
transactions sont exécutées en même temps, c'est-à-dire en série.
Et on voit que si l'une de ces opérations échoue, la dernière par exemple,
il faut s'assurer que le principe d'annulation nous ramène
la base de données dans un état valide, ce qui est le cas dans le cas séquentiel.
Mais par contre, lorsque les opérations se font en série,
on voit qu'il faut qu'une procédure spéciale soit mise en place,
au niveau du système gestion de base de données, pour s'assurer que l'exécution en
série en cas de pépin remette la base dans un état valide et cohérent.
Finalement, le principe de durabilité stipule que l'enregistrement en mémoire de
la transaction au moment de la validation ne puisse pas
être empêché ou interrompu par un événement extérieur.
Par exemple, une coupure de courant, un tremblement de terre ou que sais-je.
Cela signifie techniquement en fait qu'il faut éviter de passer par une
mémoire tampon qui pourrait s'effacer en cas de coupure de courant,
avant la validation proprement dite.
En résumé, les principes ACID stipulent donc pour l'atomicité qu'une
transaction doit être effectuée complètement ou pas du tout.
Pour la cohérence,
que l'on va vérifier au niveau de la base de données, les conditions de validité.
Le principe d'isolation qu'une exécution en série donne le même résultat
qu'une exécution séquentielle, les différentes opérations d'une transaction.
Et finalement, le principe de durabilité stipule que des incidents externes,
type coupure de courant ou autre n'affectent pas la manière dont
l'information est stockée et validée dans la base de données.
[MUSIQUE] Nous passons donc
maintenant à la typologie historique des bases de données.
Dès les années 50 et 60 s'est développé le stockage sous forme de fichiers,
dont nous avons vu quelques exemples lors de la leçon précédente.
Puis, à partir des années 60-70,
se sont développées dans un premier temps les bases de données hiérarchiques,
où les enregistrements sont associés par des relations selon une arborescence
descendante et chaque élément a un et un seul parent.
Dans les domaines d'applications, eh bien, les structures d'organisations,
les systèmes de fichiers, les systèmes taxonomiques, etc, etc.
Par la suite, les bases de données réseau qui sont une variante de bases de données
hiérarchiques, avec simplement une multiplicité des parents possibles.
Donc, l'arborescence n'est plus strictement descendante.
Il peut y avoir des structures cycliques.
A partir des années 70-80, les bases de données relationnelles, qui reposent
sur le principe d'enregistrements hébergés dans des tables à deux dimensions.
Une relation étant une table,
un attribut se trouvant dans une colonne ou un champ et l'objet dans les lignes.
Et à partir des années 90,
les bases de données objet et les bases de données semi-structurées
dans lesquelles les données sont stockées sous formes d'objets qui peuvent avoir des
structures spécifiques et variables de différents types.
Nous parlerons dans cette leçon plus précisément des bases de données
relationnelles donc.
Et le thème des bases de données objet sera quant à lui abordé plus
spécifiquement dans un cours ultérieur.
[MUSIQUE] Le
modèle relationnel a donc été développé essentiellement pour répondre aux
principes ACID,
dans les transactions qui permettent de modifier une base de données.
De s'assurer d'avoir une bonne cohérence de l'information,
d'éviter la redondance des informations.
C'est un modèle qui est fondé sur des bases théoriques solides, puisque cela
s'appuie sur la théorie des ensembles dont est tirée l'algèbre relationnel.
C'est un modèle qui a été très largement utilisé par
tous les grands acteurs du domaine des bases de données.
Aujourd'hui, on peut dire qu'environ 80 % à 90 % des bases de données sont
construites sur le modèle relationnel.
C'est quelque chose qui change un petit peu avec le Big Data,
qui fait appel à d'autres types de modèles.
Mais le modèle relationnel reste largement le plus important.
C'est un modèle finalement qui a été développé à partir des années 70 chez IBM
par un ingénieur du nom de Ted Codd.
Dans le modèle relationnel,
les données sont donc organisées sous forme de tables également appelé relation.
Une relation est constituée de colonnes ou d'attributs,
caractérisés par un nom et un domaine, un domaine étant un ensemble de valeurs,
par exemple le domaine des valeurs entières,
le domaine des booléens, le domaine des disciplines sportives, etc.
Dans une table chaque ligne correspond à un enregistrement également appelé tuple,
et pour un tuple il peut arriver qu'un attribut ne soit pas valué,
donc qu'il n'ait pas de valeur.
Et dans ce cas-là, on indique ce fait par la valeur nulle, NULL.
Un ensemble ne peut contenir deux fois le même objet,
c'est pour cette raison que dans le modèle relationnel on doit absolument s'assurer
que chaque objet est unique.
La meilleure façon de s'assurer que cet objet est unique c'est de
définir un identifiant spécifiquement pour les besoins,
comme dans le cas de la première table que l'on voit ici,
où on a créé un numéro d'étudiant qui permet d'identifier sans
ambiguïté chaque étudiant.
Cet identifiant est également parfois appelé clé primaire,
peut être fabriqué pour les besoins de la cause,
mais peut aussi être construit à partir des attributs existants,
par exemple en associant le nom et le prénom des étudiants.
On voit bien que si on se contente que du nom et du prénom,
eh bien on peut être confronté au problème des homonymes et avoir plusieurs personnes
qui ne pourraient pas être distinguées par cet identifiant.
D'où la nécessité d'étendre le concept et puis d'intégrer l'adresse,
le nom de la rue, le numéro postal, etc.
En fait l'identifiant pourrait être constitué de l'ensemble des champs de la
table, avec évidemment, on l'imagine bien, un certain nombre d'inconvénients
lorsqu'il s'agit d'indexer les objets pour pouvoir les retrouver plus
vite lors d'une recherche, ou bien pouvoir faire des tris et des choses comme ça.
C'est pour cette raison en fait que l'utilisation d'un identifiant spécifique
est le cas de figure largement le plus souvent rencontré.
Les identifiants externes, également appelés clés étrangères,
décrivent des liens entre différentes relations.
Par exemple dans le cas de cours suivis par des étudiants,
on a une table d'étudiants, une table de cours, une table de professeurs,
et on voit qu'un cours est donné par un professeur et que ce professeur en fait
doit existé dans la table des professeurs pour que la base de données soit intègre.
Dans la relation Suivi de cours,
qui associe un numéro d'étudiant avec un titre de cours, donc qui est la liste
des cours suivis par les étudiants, ou la liste des étudiants qui suivent un cours,
on voit que le numéro d'étudiant référence un étudiant de la relation étudiant,
et titre cours référence un cours dans la table des cours.
La référence doit pointer sur un objet unique, évidemment, et il peut arriver que
cet objet soit nul si l'attribut est facultatif,
par exemple dans le cas de la salle de cours qui pourrait ne pas encore avoir été
attribuée au moment où on documente la table.
L'intégrité référentielle de la base de données est un principe vérifié
automatiquement par le système de gestion de bases de données.
Si par exemple un utilisateur veut insérer un nouveau cours de géologie dans la table
des cours suivis par les étudiants et que ce cours n'existe pas dans la table cours,
la transaction sera refusée.
De même si un utilisateur veut changer le nom d'un cours et que ce nom
n'existe pas dans la table de référence, la transaction sera également refusée.
De même si un utilisateur veut supprimer un cours qui est référencé par
d'autres relations, l'opération peut être refusée, on peut supprimer les
références dans l'autre relation, ou alternativement annuler ces références.
Pareillement si un utilisateur veut modifier le nom
d'un cours dans une table et que ce nom est référencé ailleurs,
on peut refuser l'opération ou mettre à jour l'autre table également.
Le modèle relationnel ne se prête pas à l'enregistrement d'attributs multivalués,
donc qui ont plusieurs valeurs ou d'attributs complexes,
composé de plusieurs éléments.
Il est de fait nécessaire de les modéliser autrement.
Dans le cas d'un attribut monovalué complexe, comme par
exemple une adresse qui est composée d'une rue, d'un numéro dans la rue, d'un numéro
postal d'une localité, une possibilité consiste à définir un attribut,
un champ par composant comme c'est illustré par la table qui se trouve
ici en haut à droite, et par la suite de construire dans la base de
données une vue, donc qui est une table virtuelle contenant en
fait l'agrégation de ces différents champs pour restituer l'idée d'adresse.
L'autre possibilité consiste à créer un attribut adresse globale qui serait
de type chaîne de caractères dans lequel on va enregistrer l'ensemble de l'adresse,
chemin, numéro, numéro postal, localité.
On voit que dans ces relations le numéro d'étudiant
est un identifiant de la relation étudiant.
Pour un attribut multivalué comme par exemple le cas de prénoms multiples,
une possibilité serait de définir plusieurs attributs pour chaque prénom,
prénom 1, prénom 2, etc.
C'est un mauvais choix parce qu'en fait on ne sait pas combien de prénoms il faut
prévoir, et si c'est pas des prénoms ça peut être un autre type
d'attribut qui pourrait avoir une succession innombrable d'éléments
donc on voit bien que ça ne fonctionne pas très bien.
D'autant plus que ça conduit à définir beaucoup de champs qui seront
remplis de valeurs nulles.
C'est pas quelque chose qui est très optimal du point de vue base de données.
Une solution alternative consiste à créer une table supplémentaire dans laquelle
vont être hébergés les prénoms en relation avec
l'identifiant des étudiants auxquels ces prénoms se rattache,
et donc on voit que le champ numéro étudiant qui est une clé primaire de la
table Etudiants devient une clé étrangère de la table EtudPrénoms.
Une autre possibilité, un peu plus subtile,
consiste à intégrer dans la table EtudPrénoms le numéro du prénom
de sorte à pouvoir restituer l'ordre dans lequel les prénoms apparaissent.
Premier prénom, second prénom, etc.
Et dans ce cas également numéro d'étudiant est une clé
primaire pour la table Etudiants et une clé étrangère pour la table EtudPrénoms,
qui elle n'a pas de clé primaire.
Nous avons donc passé en revue les principales notions de base
du modèle relationnel, à savoir le domaine de valeurs, l'attribut,
la relation, le tuple, l'identifiant, l'identifiant externe.
Il nous reste encore à évoquer les différents opérateurs de l'algèbre
relationnelle qui fonde les opérations que l'on va pouvoir ensuite faire sur ces
tables, opérations que nous verrons de manière assez détaillée dans la deuxième
semaine de ce module, avec tout ce qui est requête, langage SQL etc.
Ces opérateurs sont en premier lieu l'opérateur d'union, donc on est dans
une logique ensemble-liste, et pour l'exemple on prend ici
une série de photographies qui ont été réalisés par un auteur, une
certaine année dans une certaine ville, et on voit que l'union de deux tables
consiste en fait à agréger ces deux tables en une seule.
La différence entre deux tables est la soustraction de la seconde à la première,
donc l'élimination des objets redondants de la première.
Cette opération n'est pas commutative,
donc si on la fait dans l'autre sens le résultat va être différent.
Nous avons ensuite le produit croisé qui consiste à associer chaque élément,
chaque tuple de la première table à chaque tuple de la seconde.
Donc ici les versions couleur et noir blanc des photos qui donnent
donc deux fois trois six photos, et puis les opérations de sélection sur une table.
Sélection qui consiste à identifier, à extraire un certain nombre d'éléments.
Des opérations de projection qui consistent à extraire un certain nombre
d'attributs pour l'ensemble de la table, ce qui dans le cas précis
débouche sur quelque chose qui n'a pas grand, ou en tout cas qui est contraire au
principe de la théorie des ensembles puisque l'on a des objets identiques.
Donc c'est une opération qui ne serait pas valide.
Et finalement les opérations de jointure qui consistent à associer deux tables
par l'intermédiaire d'un champ qui leur serait commun, ici
la table des photographies couleurs avec une table qui associerait ville et pays.
Le champ commun étant évidemment la ville.
Ces opérations de jointure peuvent être assorties d'une condition.
Donc, on pourrait ne garder que les
éléments jointifs qui ont pour pays le Sénégal.
Et donc, une seule,
une seule photographie sur les trois qui étaient comprises dans
la jointure de départ.
[MUSIQUE] [MUSIQUE] Nous en venons maintenant aux
spécificités des bases de données qui possèdent une composante spatiale.
Spécificités qui sont au nombre de trois principalement.
Tout d'abord, le type de données.
Donc, les domaines concernant ces types de données.
On voit que dans la table ici en haut à droite, en haut à gauche, pardon.
Dans une base de données traditionnelle,
on a un certain nombre de types de données bien définis, varchar pour le texte,
les entiers pour le numérique, le réel, également pour les nombres, les dates.
Dans la base de données spatiale, on ajoute de nouveaux types de données,
de type point, ligne, polygone, etc.
Enfin, les géométries de base
qui sont gérées par les systèmes d'informations géographiques.
Le second domaine important, c'est celui de l'indexation.
L'indexation des objets spatiaux pour pouvoir, par la suite,
effectuer des requêtes et retrouver rapidement les objets.
Et finalement, un certain nombre de fonctions qui permettent
d'effectuer des opérations spécifiques sur les objets géométriques.
Il existe plusieurs formes d'indexation des données.
Dans le domaine des bases de données non spatiales,
on utilise souvent une structure appelée B-tree.
Donc, une arborescence hiérarchique qui permet en fait
de retrouver facilement les données.
On a dans cette illustration un exemple d'un arbre d'ordre 5 dans lequel un
nœud peut avoir au plus quatre clés et cinq enfants.
Chaque nœud ayant au moins deux clés et trois enfants.
Cette idée d'arborescence hiérarchique se retrouve dans le domaine des bases de
données spatiales sous la forme d'un R-tree, dans
lequel les objets les plus proches sont regroupés et représentés à l'échelle
supérieure par une enveloppe minimale, qui est le minimum bounding rectangle.
Et lorsque l'on fait ensuite une requête pour retrouver des objets,
en fait si la requête n'intersecte pas l'enveloppe minimale, on peut écarter
tous les objets de cette enveloppe et puis se concentrer sur ceux qui restent en jeu.
Dans l'illustration qui est ici, on voit à gauche le lien entre une approche
hiérarchique non spatiale et une approche hiérarchique spatiale.
Et puis, à droite, un exemple de structuration d'index spatial
qui concerne les bureaux de postes en Allemagne.
Le Quadtree est une autre méthode d'indexation spatiale qui est pas
mal utilisée dans les systèmes de tuilage de cartes géographiques type Google, etc.
Il s'agit d'une structure arborescente dans laquelle chaque nœud
possède exactement quatre enfants.
Donc chaque zone géographique est divisée en quatre.
Et à nouveau en quatre, chaque fois que l'on descend d'un niveau de zone.
Le mode d'indexation en grille
est similaire dans le sens qu'il s'agit aussi d'une tessellation régulière.
Simplement que la subdivision de chaque entité ne se fait pas nécessairement
en quatre, mais peut se faire en neuf, en seize, etc, etc.
Parmi les fonctions spécifiques aux bases de données spatiales,
on peut distinguer trois familles principales.
Tout d'abord, la famille des mesures spatiales qui donnent des indications de
longueur, de surface, de distance à propos des objets géométriques.
Des fonctions spatiales qui sont, qui créent de nouvelles entités.
Par exemple, on peut imaginer la création d'une zone tampon autour d'un objet
géométrique, l'intersection de deux objets qui crée un nouvel objet.
L'union de deux objets, etc, etc.
Et des opérateurs topologiques qui testent la véracité de relations de voisinage.
Est-ce que deux géométries se chevauchent?
Est-ce qu'elles se touchent?
Est-ce qu'elles sont contenues l'une dans l'autre ou vice versa, etc.
Tous ces différents types de fonctions sont de plus en plus
souvent implémentés dans les systèmes de gestion de base de données spatiales.
[MUSIQUE]
[MUSIQUE] Comme je l'ai dit au début de ce cours, il existe un très grand nombre de
systèmes de gestion de base de données consacrées au modèle relationnel.
Et non seulement il existe un très grand nombre de bases de données,
mais ces bases de données sont accessibles par l'intermédiaire de toute une série de
clients qui sont soient des logiciels commerciaux, soit des logiciels libres.
Tous ces clients offrant en fait une interface utilisateur
et permettent d'entrer en contact avec ces bases de données et de les manipuler.
Parmi les fonctionnalités que l'on souhaite trouver dans les systèmes
de gestion de base de données, il en est en fait de trois types.
Tout d'abord, celles qui permettent de gérer la structure des données.
Donc, de créer de nouveaux champs, de nouveaux attributs avec leurs domaines de
valeurs et de créer de nouveaux index clé primaire, clé externe, etc, etc.
De consulter les données enregistrées dans la base de données.
Donc, de consulter les tables de valeurs.
Éventuellement de pouvoir importer des données depuis l'extérieur pour
peupler ces différentes tables.
Et finalement, toutes les fonctionnalités qui sont liées à la construction et
à l'exécution de requêtes pour aller rechercher des objets
dans une base de données, sur la base d'un certain nombre de critères, etc.
Toutes choses que nous allons voir plus en détail, en particulier dans
les leçons du deuxième, de la deuxième semaine de ce module.
Dans l'immédiat, nous allons prendre un petit exemple qui est celui des districts
des Seychelles que l'on peut exporter dans un format base de données.
En l'occurrence, une base de données SpatiaLite.
Donc, on va appeler ce fichier mahe.sqlite.
Et l'enregistrer.
On peut préciser quelques paramètres.
La couche enregistrée va être ajoutée en fait.
Il demande de préciser le système de projection utilisé.
UTM Sud 40.
On peut masquer cette nouvelle couche.
Et dans un deuxième temps, on va enregistrer simplement les attributs de la
couche, donc sans la géométrie, sous la forme d'un fichier ASCII, fichier texte,
.csv, donc un fichier texte avec des valeurs séparées par les virgules.
Donc là, pareillement,
la table va être ajoutée dans la liste des objets disponibles.
Et si on passe maintenant à un logiciel de gestion de base de données,
donc il s'agit de SQLiteStudio, on peut importer.
On va commencer par créer une base données,
dans laquelle on va importer le fichier texte.
Donc, on va appeler cette base de données mahe_data.
Cette base de données, une fois créée,
on voit qu'elle, on va commencer par se connecter à cette base de données.
Et on voit qu'elle peut contenir des tables
et des vues qui sont en fait des résultats de requêtes, les vues.
Rendues un peu permanentes.
Dans les tables, on va importer des données dans une nouvelle table.
On va créer cette nouvelle table qu'on va appeler districts.
Et importer le fichier texte qui contient les
attributs de ces districts qu'on a sauvegardé précédemment.
On dit que la première ligne représente les entêtes des colonnes.
Et on voit que cette table apparaît maintenant dans l'arborescence.
Cette table districts qui contient un certain nombre de colonnes qui sont les
différents champs que nous avions dans la couche districts de QGIS.
On peut consulter également les données elles-mêmes.
Et modifier la structure de données si nécessaire.
Dans un deuxième temps, on va ajouter une autre base de données, qui est en fait la
base de données sauvegardée de QGIS avec les éléments de géométrie.
Et on voit que si on se connecte à cette base de données,
on a un nombre d'objets beaucoup plus considérable.
Puisqu'en fait pour gérer la dimension géométrique,
la base de données SQLite génère tout un tas d'objets qui sont nécessaires
et qui rendent la chose, quand on l'aborde comme cela de loin, un peu plus complexe.
Mais on retrouve aussi la table de données des districts de Mahé, avec les mêmes
colonnes, les mêmes valeurs que l'on peut consulter sous forme de tables.
On voit qu'il n'y a en plus pas encore d'index, mais des déclencheurs,
triggers en anglais, qui sont en fait les règles que le
système de gestion de base de données doit vérifier lors de chaque transaction.
Donc, on peut définir les règles de validation au cas par cas.
Voilà pour les logiciels,
pour cette introduction aux logiciels systèmes de gestion de bases de données,
que nous reverrons plus en détail dans d'autres leçons du cours.
[MUSIQUE] Nous
voilà donc au bout de cette leçon qui nous aura permis
d'aborder de manière assez détaillée le thème des bases de données relationnelles.
Et de faire une petite introduction aux systèmes de gestion de bases de données.
Tous ces éléments seront repris plus en détail par la suite.
En particulier par la prochaine leçon qui va porter sur la modélisation des données.
Et puis par la suite sur, dans les leçons qui vont porter sur les requêtes,
les langages de requêtes où on va beaucoup utiliser pour
illustrer le propos, des systèmes de gestion de bases de données.
[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.
