Le blog SIG & URBA

Tous les métiers reposent aujourd’hui sur des applications, et donc des données. Les urbanistes n’en conçoivent que rarement mais ils en utilisent un grand nombre : par exemple en consultant le cadastre ou en utilisant des données extraites de différentes bases de données comme des éléments issus des permis.

Dans certains cas, et notamment pour certaines données SIG ce sont simplement des « couches », c’est à dire des données que l’on superpose les unes aux autres. Mais, de plus en plus, les informations saisies ou consultées sont intégrées et ensuite extraites de systèmes de gestion de base de données, ou SGBD.

Quel est l’intérêt de ces données organisées ?

• optimiser le stockage des données pour limiter éventuellement son poids et sécuriser cette donnée
• éviter la redondance des données et donc les saisies équivalentes à plusieurs endroits
• faciliter les mises à jour des données de référence, par exemple modifier un prix unitaire à un seul endroit
• et faciliter les diverses exploitations, statistiques en particulier.

Il existe plusieurs manières d’organiser ces données.

Je n’en citerai que 3 :

• hiérarchique : qui correspond souvent à l’organisation des pages web avec une page principale (mère) et des pages secondaires qui déclinent cette page principale (enfant)
• relationnelle : qui est l’organisation majoritaire pour organiser toutes les données métiers, et que nous allons expliciter plus en détail.
• en étoile : pour des analyses dites décisionnelles, qui correspond à un mode d’organisation facilitant les traitements statistiques à grande échelle.

Retenez que le mode d’organisation dépend de la donnée traitée mais également des usages attendus. Des statistiques, principalement fournies à l’échelle communale et intégrées annuellement, ne nécessitent pas la même organisation que des informations saisies pour instruire un dossier de subvention : dans le premier cas le principal lien entre toutes les tables est le code commune INSEE, dans le second cas il existera des liens plus complexes entre le dossier de subvention et les différentes phases comptables.

La méthode, notamment pour un modèle relationnel, consiste à dessiner un « modèle de donnée » c’est à dire une organisation de celles-ci sous forme de schéma :

• modèle conceptuel dans un premier temps qui présente les principales relations nécessaires pour répondre aux besoins,
• logique ensuite, en allant plus loin dans l’organisation des données, les différentes relations et tous les éléments sous-jacents utiles
• et enfin, physique, c’est à dire complètement adapté à l’outil final : format de la base de donnée et outil d’exploitation. En effet, selon le/les logiciels utilisés l’organisation ne sera pas la même. On peut visualiser ça avec certains formats SIG qui permettent la combinaison de différentes géométries (exemple du format Tab) ou d’autres qui ne le permettent pas comme le Shape.
  

  Modèle de donnée DDU

Quelques éléments de terminologie

Les termes utilisés sont importants pour bien comprendre les principes d’organisation des bases de données. Ils sont également nombreux et souvent équivalents, dépendant du domaine d’origine et des outils utilisés.

 

Identifiant unique, UID, IDU, clé primaire … atomique

Cette notion est importante. Il est conseillé, dans une base de données, de bien désigner chaque ligne d’information par un identificateur unique de manière à bien qualifier et distinguer chaque élément et de faciliter le tri et le filtrage des informations. Cela permet également de remonter à un utilisateur ou à une entité spécifique du système très facilement.
https://actualiteinformatique.fr/internet-of-things-iot/lidentifiant-unique-uid

 

Table, fichier

Dans un système relationnel, et quel que soit le « SGBD » utilisé, (Oracle, My SQL, PostGre, …), les différentes informations sont stockées dans des tables. Ces tables correspondent en quelque sorte aux différentes feuilles d’un tableur.

 

Entités, enregistrements, lignes, tuples

Les différents enregistrements d’une table correspondent à des lignes d’information cohérentes. Par exemple la liste des différents zonages dessinés dans un PLU avec ses informations associées.

 

Champs, variables, colonnes, attributs

Ce sont en quelque sorte les informations élémentaires. Par exemple, pour un enregistrement dans une table listant les communes l’information sur le code INSEE.

 

Domaines, listes de valeurs

Ce sont des éléments, stockés en règle générale dans des fichiers, utilisés pour saisir certaines informations de manière accompagnée et normée. Par exemple, ce peut être la liste des communes de manière à proposer celles correspondant au territoire d’intervention.

 

Pour aller + loin :

Vocabulaire base de données : https://fr.wikibooks.org/wiki/Les_bases_de_donn%C3%A9es/Le_vocabulaire_de_base_des_BDD

Wikipédia : https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es

Entité : https://www.base-de-donnees.com/entite/

Modèle relationnel/multidimensionnel (étoile) : https://maximilienandile.github.io/2016/10/12/Base-de-donnees-comprendre-les-differences-entre-le-modele-relationnel-et-le-modele-multidimensionnel/

Différents niveaux de modèle : https://louisvandevelde.be/index.php?dos=my&fic=meris

Commission règles et qualité du CNIG : http://cnig.gouv.fr/commission-regles-qualite-r21391.html

Qualité raisonnée

Dernière notion importante en matière de base de données, celle de qualité. Celle-ci est essentielle, y compris pour l’utilisateur final :

• Par exemple s’il existe plusieurs orthographes pour les noms de communes, la recherche pourra être incomplète.
• De la même manière si une information n’est pas bien classifiée, il sera difficile de produire des analyses pertinentes. Je pense là aux classifications d’occupation du sol qui posent la question du mélange entre morphologie du bâti et usage réel ? exemple d’une maison utilisée comme atelier artisanal
• On parle aussi de qualité en ce qui concerne les éléments géométriques, un sujet largement porté par le CEREMA et en lien avec la qualification des données, notion qui renvoit à sa description et son catalogage.

Néanmoins, comme dans tout domaine, le principe de réalité conduit à parfois relativiser la tendance à la normalisation qualitative. En effet, comme l’évoque Tetranos dans ses présentations sur la qualité :

• la qualité s’apprécie au regard d’un besoin
• ce besoin peut être différent d’un acteur à l’autre
• la modélisation est toujours un parti pris de représentation de la réalité (carto versus terrain) et de ses informations associées
• des adaptations sont parfois nécessaire suivant les caractéristiques du Système de Gestion de Base de Données, c’est pour ça que l’on décline le modèle de base, conceptuel, jusqu’au modèle physique, adapté aux outils.

Il peut donc être utile de dessiner un modèle, une organisation des données, moins contraint que ce que le concepteur imaginerait au départ. Les règles doivent répondre à des besoins et des utilisateurs et ne pas imposer des contraintes par simple orthodoxie informatique.

Qui n’a pas eu des formulaires à remplir avec des informations « obligatoires » qui ne nous paraissaient pas du tout essentielles au sujet ? Ou le dossier qui doit être complet pour passer à l’étape d’instruction avec des informations finalement pas si importantes et qui peuvent être demandées plus tard ? Il faut, en fait, trouver le juste milieu entre les contraintes qui assurent la « solidité » de la base et l’intérêt pour l’utilisateur.

Grand merci à Tétranos pour ses apports et à Elise pour sa relecture et ses questionnements