Rappels sur les bases de données relationnelles

Dans le cadre de la découverte de QGIS, qui n'est qu'une interface de visualisation/manipulation de données spatiales (GUI, Graphic User Interface), on peut revoir rapidement l'intérêt à passer des tableurs aux bases de données relationnelles.

Ci-dessous l'exemple d'un fichier Excel truffé d'erreur de conception (d'un point de vue BDD s'entend), nommé Mes beaux utilisateurs, contenant des humains, des métiers et des adresses. Celui-ci gagnerait à être divisé en au moins deux tables : users et address. En effet une base applicative doit considérer chaque ligne (chaque enregistrement) comme une occurence propre (une identification, un événement...). Or techniquement ou même dans la vraie vie, une adresse a-t-elle la même valeur qu'un nom ? Sont-ils intimement et éternellement liés ? Non.

Souvent, l'une des questions à se poser est : quelles sont les informations qualitatives réellement liées aux objets décrits ? Ainsi une adresse peut changer, un nom beaucoup moins.

Quelques intérêts du fonctionnement en bases de données relationnelles : amélioration des performances d'affichage, amélioration des performances de requêtage, minimisation/rationnalisation des doublons, minimisation des champs vides, mises-à-jour en cascade...

Ainsi une BDD applicative (sous-jacente à un site web, une application métier...) peut être vue non pas comme un gigantesque tableau, mais plutôt comme une constellation de petits tableaux reliés entre eux. Et pour les relier, on utilisera des jointures basées sur des champs contenant des valeurs communes (des identifiants, un champ id typiquement).

Profitez du passage à la dimension relationnelle pour acquérir de bonnes pratiques : pas d'espace ni de caractères spéciaux dans les noms d'objets BDD, des noms courts et évocateurs, 1^ère ligne contenant les noms de champs...

Exercice

À partir des informations déjà présentes dans ces données, dessinez une 3^ème puis une 4^ème table relationnelle¹.

Plus difficile : imaginez et dessinez une méthode relationnelle permettant de totalement évincer les doublons de la table address².

¹ Une table speciality par exemple, puis une table country.
² Il s'agit de passer par une table intermédiaire entre les users et les address.

Liens ou pièces jointes

Fichier SQL arrêts RATP pour PostGIS	[Fichier contenant un code SQL d'import dans PostGIS des arrêts RATP - modifier propriétaire]	2022 Ko
Fichier zippé d'un shape des pays du monde	[Fichier zippé d'un shape des pays du monde]	0 Ko
Fichier Excel de commandes clients	[Données clients brutes "export_commandes", série de commandes par clients, et leurs montants]	61 Ko
Fichier Excel clientèle	[Fichier clientèle d'exemple, "export_soft", fichier clients, utilisateurs]	857 Ko
Fichier zippé d\'un shape des communes françaises (2016)	[Communes française métropolitaine (base GeoFla - IGN - 2016) ]	24153 Ko
Fichier SQL Grande Muraille verte pour PostGIS	[Fichier contenant un code SQL d'import dans PostGIS d'une bande tampon de la partie sénégalaise du projet GMV - pensez à modifier le propriétaire avant d'importer]	26 Ko
Fichier SQL Île-de-France pour PostGIS	[Fichier contenant un code SQL d'import dans PostGIS des département d'Île-de-France - modifier owner avant import]	571 Ko
Fichier zippé d\'un shape de l'Île-de-France	[Shape départements d'Ile-De-France Lambert II Étendu]	96 Ko
Fichier zippé d'un shape des IRIS	[Fichier zippé d'un shape des IRIS]	0 Ko
Fichier zippé avec 3 KML de test	[KML de lignes, points et polygones, pour test Google Earth et API Google Maps]	4 Ko
Fichier zippé du projet Natural Earth Quickstart Kit	[Fichier de test QGGIStutorials, contenant les shapes et les projets QGIS (Arcmap également), avec une série de filtres, symbologies, étiquettes et légendes]	0 Ko
Fichier SQL d'import d'une table de points	[Fichier contenant un code SQL d'import dans PostGIS - modifier propriétaire]	2 Ko