AG InfoSol : Entrepôt de données Point sur l’avancée du projet

Objectifs du projet Amélioration du partage des données de l’unité : Amélioration de l’accès aux données des BDD : Donesol, BDAT, BDETM, etc. Automatisation du traitement des données : jointures spatiales, règles métier sur les données, etc. Historisation des données Assurer la qualité des données : Gestion des métadonnées Documentation de l’entrepôt et de ses services Cohérence données brutes / données élaborées Améliorer la visibilité des données du GIS Sol : Support de la publication des services web de l’unité Amélioration partage des données Faciliter l’accès aux données des BDD pour les membres de l’unité : DoneSol, BDAT, BDETM, etc. Automatiser le traitement de certaines données : jointures spatiales, règles métier sur les données, etc. Pouvoir historiser les données (sauvegarde et versionnement) Assurer la qualité des données Avoir une bonne gestion des métadonnées (dictionnaire de données, commentaires tables, etc.) Bien documenter l’entrepôt et ses services afin d’assurer sa pérennité et une utilisation optimale. Assurer la cohérence entre les données brutes et les données élaborées grâce à l’automatisation des flux de données (taches ETL) et des calculs Améliorer la visibilité des données du GIS Sol L’entrepôt de données devient le support de la publication des services web de l’unité (WMS, WFS, etc.).

Formation Systèmes d’Information Décisionnel (SID) Formateurs : Messan CHAKPALI, Nicolas DUPONT (CGI) Date : 13, 20, 27 Mars 2014 Participants : BTO, NSA, MMA, JPA, FMI. Durant la formation : Audit et conseils sur l’architecture décisionnelle déjà en place Présentation nouvelle méthode de modélisation : Inmon Présentation des différents outils de restitution BI disponibles Suite à la formation : Modification de l’architecture fonctionnelle de l’entrepôt (Kimball => Inmon) Amélioration de la documentation à produire avec l’entrepôt Nécessité de définition d’une nouvelle gouvernance de projet : stratégique, technique et fonctionnelle Durant la formation Audit et conseils sur l’architecture déjà en place : présentation des modèles de données, de nos choix logiciels, comment s’articulent les taches ETL (extraction, transformation et chargement des données dans l’entrepôt). Une fois que le formateur a pris connaissance des travaux déjà effectués il nous a présenter une autre méthode de modélisation que celle utilisée jusque là : la méthode Inmon (du nom de son auteur). Auparavant nous utilisions la méthode Kimball (sur la base d’un ouvrage de cet auteur disponible dans l’unité). Dernier jour : présentation des différents outils de restitution de Business Intelligence disponibles sur le marché. Outil de restitution BI : permet la restitution à l’utilisateur des données présentes dans l’entrepôt. Restitution sous différentes forme et par différents outils : - outils de reporting (rapports) et requêtes - outils d’analyse des données - outils de data mining Suite à la formation Modification de l’architecture fonctionnelle de l’entrepôt : on est passé d’une modélisation de type Kimball à une modélisation de type Inmon (comparaison des deux types de modélisation dans les diapos suivantes). Amélioration de la documentation à produire avec l’entrepôt : on a ajouté plusieurs documents à produire avec l’entrepôt (pour les utilisateurs mais aussi pour les gestionnaires de l’entrepôt) Nécessité de définition d’une nouvelle gouvernance de projet : Gouvernance : Stratégique : avis sur la pertinence et la stratégie de la demande d’information Technique : maitrise du projet, documentation, maintenance, industrialisation Fonctionnelle / métier : bien cerner le périmètre du projet (spécialistes métier) => Point a aborder durant la prochaine réunion de Copil du projet.

Architecture fonctionnelle (1/2) Ancienne architecture : Kimball + : facile à modéliser/créer - : difficile à faire évoluer/maintenir dela (mayari) Donesol BDAT BDETM autres sources de données… SI opérationnels Data Staging Data Warehouse Data Mart Data Mart Data Mart Kimball : le data warehouse est un conglomérat des différents data marts de l’entreprise, l’information est toujours stockée en format dimensionnel SI opérationnels : plusieurs sources de données hétérogènes (BDD relationnelles, fichiers plats CSV, SHP…) Data Staging : données centralisées mais pas encore de structure commune Data Warehouse : création de datamarts (marché de données) à partir des données du datastaging : datamart = table fait + tables dimensions Data Marts : données prêtes à l’emploi, répondant aux besoins de l’utilisateur. 1 datamart / tableau répond à 1 besoin , chaque datamart représente un processus seul, la somme des datamarts constitue le datawarehouse (liaison grâce aux dimensions conformes) Architecture en BUS de données : approche par le haut : on répond aux besoins unitaires par différents datamarts que l’on relie ensuite par leur dimensions communes afin de former le data warehouse. Avantages : plus facile à modéliser (par processus métier unitaire) Inconvénients : moins adapté au changement , passage direct de la donnée brute à la donnée élaborée/agrégée (ajout/suppression de donnée nécessite de tout recréer) + difficulté pour lier les datamart à partir de dimensions créées de manière unitaire.

Architecture fonctionnelle (2/2) Nouvelle architecture : Inmon + : facile à faire évoluer/maintenir - : difficile à modéliser/créer entrepot_donnees (mayari) dela (mayari) Donesol BDAT BDETM autres sources de données… SI opérationnels Data Staging Référentiels Data Warehouse Data Marts Data Mart Data Mart Inmon : SI opérationnels : plusieurs sources de données hétérogènes (BDD relationnelles, fichiers plats CSV, SHP…) Data Staging : données centralisées mais pas encore de structure commune Data Warehouse : centralisation des données issues de plusieurs sources, avec une structure et un référentiel commun (structure dimensionnelle) Mais pas de transformation/agrégation sur la donnée (proche de la donnée source). On garde les éléments factuels (niveau de détail le plus fin) mais on identifie des faits et dimensions. Data Marts : données prêtes à l’emploi, répondant aux besoins de l’utilisateur. 1 datamart / tableau répond à 1 besoin Avantages face à la méthode Kimball : meilleure adaptation au changement avec la séparation data warehouse (données brutes mais avec une structure et référenciel commun) et data mart (données transformées/agrégées et répondant à un besoin précis de l’utilisateur). Désavantage : architecture plus lourde, modélisation plus complexe. Réflexion plus poussée autours des référentiels car ils doivent s’adapter au maximum de données, et pouvoir accueillir de nouvelles données. Tableaux BTO 2014

Réalisation : datamart analyses RMQS (1/3) Données Sources => Data Staging Corine Land Cover MNT Geofla Grilles météo… Besoins : Rassemblement des analyses du programme RMQS Possibilité d’extraire les analyses selon plusieurs composantes (date, projet RMQS, type de profil, etc.) Jointure spatiale des sites RMQS avec d’autres variables (occupation, altitude, etc.) DONESOL Caractéristiques pédologiques profil Horizon… Résultats d’analyse resultat_analyse resultat_densite_apparente Données RMQS intervention site… Data Staging Donesol Données externes

Réalisation : datamart analyses RMQS (2/3) Data Staging => Data Warehouse Corine Land Cover MNT Geofla Grilles météo… Data Staging Data Warehouse

Réalisation : datamart analyses RMQS (2/3) Data Warehouse => Data Mart Data Warehouse Corine Land Cover MNT Geofla Grilles météo… Data Staging Agrégation/transformation Filtre/sélection Tableau analyses du projet ANDRA Data Mart analyses RMQS

L’entrepôt : support des services web Projet dans le cadre d’un contrat ADEME Moi : gestion entrepôt de données J-B : gestion diffusion des services web Autre exemple : support de GeoSol Contrat ADEME : Conception de web services et de traitements statistiques pour améliorer la visibilité et l’accessibilité des données sols du GIS Sol (RMQS et BDETM) Entrepôt de données est le support pour l’enregistrement des couches diffusées par les services web. Deux personnes sur le projet : moi & J-B 3 Serveurs utilisés Acklins : Serveur subversion, permet le stockage et le versionnement des scripts du projet Différents fichiers sont enregistrés : Les fonctions (scripts) : construction sld, construction fiches INSPIRE, etc. La documentation de l’architecture de diffusion des services web : procédure, mode opératoire, suivi, etc. Les différents catalogages : données à diffuser, métadonnées, etc. Rodas : Serveur de calcul scientifique de l’unité, utilisé pour la préparation et le traitement des scripts de création des couches de données à diffuser. Préparation des données =>Traitements R & Bash (geostatistiques, modélisation, construction fichiers de style, fiches INPIRE) => Stockage des couches raster/vecteur dans l’entrepôt ET publication des couches sur un Geoserver Mayari : Serveur de base de données contenant l’entrepôt de données ET serveur de publication des webservices (utilisation de Geoserver) L’entrepôt est aussi lié au serveur subversion pour le stockage et le versionnement des scripts d’alimentation de l’entrepôt et pour le stockage de la documentation liée à l’entrepôt. JPA 2014

Documentation de l’entrepôt (1/2) Document de cadrage Document de conception générale de l’entrepôt. Objectifs et périmètres du projet Description référentiels (dimensions) & indicateurs (faits) Explication règles de gestion des données Modèles de données Fiches d’indicateur Document unitaire de description du besoin utilisateur et de la mise en œuvre de la réponse. Problématique et traduction du besoin Règles métiers de transformation et d’intégration des données Contrôles qualité attendus. Document de validation lors du développement & document final une fois le service opérationnel. Document de cadrage de l’entrepôt Décrit l’organisation générale de l’entrepôt, c’est le document de conception général, on y trouve une description des tables de référence (dimensions) et des tables d’indicateurs (faits), les régles de gestion des données au sein du data warehouse, le modèle de données. Fiches d’indicateur Document unitaire (1 besoin = 1 fiche) décrivant le besoin de l’utilisateur et la mise en œuvre de la réponse au besoin. Contient en particulier la description des règles métiers de transformation et d’intégration des données ainsi que les contrôles qualité attendus. Il sert à la fois de document de validation lors du développement ET de document final une fois le service opérationnel Dictionnaire de données Donne la signification de chaque champs des tableaux de données ou des tables constituant un datamart. Outil PG DaDi. Document de gestion de l’entrepôt

Documentation de l’entrepôt (2/2) Dictionnaire de données Donne la signification de chaque champs des tableaux de données ou des tables constituant un datamart. Outil PG DaDi. Document de gestion de l’entrepôt Description des procédures de gestion de l’entrepôt, instructions pour chaque cas d’utilisation. alimentation interrogation modification

Et ensuite… Mercredi 25 Juin - réunion CoPIL Projet : documentation, gouvernance de projet, etc. Finalisation insertion données ponctuelles de DoneSol & BDAT dans le data warehouse. Re-création data mart déjà opérationels : synthèse analyses RMQS, analyses ANDRA, analyses agrinov, etc. Nouvelle itération (données BDETM par ex.) Jeudi 10 Juillet : présentation sur les systèmes d’information décisionnels (SID)

Merci de votre attention…