Structuration d`une base de données sur l`agriculture en

Université Jean Monnet
de Saint-Etienne
Ecole Nationale d’Ingénieurs
de Saint-Etienne
MASTER SIG ET GESTION DE L’ESPACE
Mémoire de fin d’études, parcours professionnel
Structuration d'une base de données
sur l’agriculture en Rhône-Alpes
Préparé par :
Khalid OUBENNACEUR
Maître de stage :
Ahmed CHAFCHAFI, Chambre Régionale d'Agriculture de Rhône-Alpes
Coordinateur du master :
Thierry JOLIVEAU, Université Jean Monnet de Saint-Etienne
Septembre 2011
-0Structuration d’une base de données sur l’agriculture en Rhône-alpes
REMERCIEMENTS
Au terme de ce stage, je tiens à remercier très sincèrement, Ahmed
CHAFCHAFI, mon maître de stage pour son accompagnement dans la réalisation
de ce stage. Je le remercie pour son implication, sa disponibilité et l’autonomie
qu’il m’a accordées durant ce stage. Je remercie également Harshit COWLESSUR
(Désirade Rhône-Alpes) toujours présent pour répondre à mes questions
concernant la modélisation UML.
Je tiens à remercier aussi, Josselin EDOUARD, chef de projet informatique
pour ses conseils avisés lors du stage.
Mes remerciements se tournent également vers toute l’équipe enseignante du
Master SIG et gestion de l'Espace, en particulier Thierry JOLIVEAU, pour les
renseignements qu’il m’a apportés tout au long du stage.
Je remercie aussi l’ensemble du personnel de la Chambre d’agriculture
Rhône-Alpes, qui ont participé, plus ou moins directement à ce travail, pour le
temps qu’ils m’ont consacré et pour les informations qu’ils m’ont fournies.
J’adresse une pensée amicale à Capucine, Cyrielle, Leah, Julie avec qui j’ai
partagé ces six mois de stage, et qui par leur bonne humeur, ont été d’excellentes
collègues. Les différents échanges que nous avons pu avoir ont été très prenants et
enrichissants.
Enfin, merci à toutes les personnes que je n’ai pas citées et qui ont contribués
à cette étude.
-1Structuration d’une base de données sur l’agriculture en Rhône-alpes
RESUME
Mots-clés : Base de données, Conceptualisation, Mapserver, cartographie, référentiels
géographiques, ETL, Géo services.
Ce
document
présente
le
stage
professionnel
réalisé
par
Khalid
OUBENNACEUR au sein de la chambre régionale d’agriculture Rhône-Alpes
pour l’obtention du Master 2 professionnel SIG et Gestion de l’espace. Il présente
une synthèse des méthodes et solutions de structuration, de déploiement,
d'administration, de gestion et d’alimentation d’une base de données sur
l’agriculture en Rhône-alpes.
Après, un état des lieux sur les utilisations des données et référentiels dans
les différents pôles de la CRARA, nous avons engagé ce travail de structuration
que nous avons orienté selon quatre axes :
Conceptualisation
et
construction
de
la
base
de
données
Postgresql/Postgis.
Valorisation de la base en lien entre autres avec l'Obsagri Rhône-Alpes
avec l’outil Qgis (études, analyses, simulation pour la filière lait).
Tests des outils et solutions d’échange, d’extraction et d’alimentation
de la base de données (ETL).
Test de déploiement des Géoservices pour la diffusion et l’accès aux
données de la base.
Ce travail par ses différents aspects en matière de gestion et d’administration
d’une
base
de
données
(conceptualisation,
structuration,
déploiement,
alimentation, valorisation, etc.) m’a permis de suivre le cheminement de
l’information géographique, de l’acquisition à la finalisation de la base de
données.
-2Structuration d’une base de données sur l’agriculture en Rhône-alpes
ABSTRACT
Keywords: Database, Conceptualization, Mapserver, mapping, geographic references, ETL, Geo
Services.
This document presents the internship directed of Khalid OUBENNACEUR
at Rhône-Alpes regional chamber of agriculture in order to obtain the Professional
GIS and Space Management Master 2. It summarizes the methods and solutions
for structuring, deploying, administrating, managing and expanding an
agricultural database in the Rhone-Alpes region.
After an inventory of the uses of data repositories in different poles of the
CRARA, the work was focused on four areas:
The conceptualization and construction of the database PostgreSQL /
PostGIS.
Valuation of the Database link with the other Obsagri Rhône-Alpes
with the tool QGIS (studies, analysis, simulation for the milk pole).
Testing tools and solutions for the exchange, extraction and power of
the database (ETL)
Test deployment Geoservices for dissemination and access to data
from the database
This work in various aspects of management and administration of a database
(conceptualisation, structuring, deployment, power, recovery, etc.) allowed me to
follow the progress of geographic information, the acquisition to finalize the
database.
-3Structuration d’une base de données sur l’agriculture en Rhône-alpes
SOMMAIRE
Remerciements……………………………………………………………………………..…1
Résumé…………………………………………………………………………………………2
Abstract………………………………………………………………………………………...3
Sommaire………………………………………………………………………………………4
Introduction……………………………………………………………………………………6
PARTIE I
1. Contexte général du stage………………………………………………………………...8
1.1. Structure d’accueil…………………………………………………………….............8
1.1.1. Les missions………………………………………………………………….…..8
1.1.2. Organisation de la CRARA……………………………………………………9
1.2. Objectifs du stage.……………………………………………………………………10
1.3. Méthodologie du projet………………………………………………………..…....10
1.4. Planning de réalisation……………………………….………………………..……12
PARTIE II
2. Etude conceptuelle des bases de données……………....………………….……….……14
2.1. Méthodes utilisées de modélisation des bases de données..................................14
2.1.1. UML2… ……………………............................................................................14
2.1.1.1. Le modèle fonctionnel……………...……………………………..…16
2.1.1.2. Le modèle structurel……………………………...….........................16
2.1.2. Merise...............................................................................................................17
2.1.3. Choix de système de gestion de bases de données.....................................18
2.1.4. Choix d’outils de modélisation.....................................................................19
2.2. Etude de l’existant et recueil des besoins et attentes des acteurs…………..… 21
3. Modélisation de la base de données Sig_crara.……………………….……………..…..21
3.1. Cas d’utilisation résultant de l’analyse de l’enquête............................................22
3.1.1. Identification des cas d’utilisation (Use Case) et des acteurs.............…...23
3.1.2. Description des cas d’utilisation...................................................................23
3.1.3. Diagramme de cas d’utilisation global (Use Case).....................................24
3.2. Modèle Structurel......................................................................................................25
3.2.1. Diagrammes de classe associés aux paquetages.........................................27
3.2.2. Description détaillée du modèle de classe...................................................28
3.3. Niveau physique : Passage au modèle relationnel (MPD)...................................29
-4Structuration d’une base de données sur l’agriculture en Rhône-alpes
PARTIE III
4. Mise en œuvre et déploiement de la base de données…………………………………30
4.1. Choix de système de gestion de bases de données...............................................30
4.2. Création et structuration de la base de données………………………………….30
4.2.1. Création de la base de données.....................................................................30
4.2.2. Gestion des multi utilisateurs........................................................................31
4.2.3. Structuration de la base de données………………………………………...32
4.3. ETL(Extract Transform Load)……………………………………...……………….33
4.3.1. Définition d'un outil ETL...............................................................................34
4.3.2. Choix des ETL Open Source………………………………………………...34
4.3.2.1. Talend Open Studio/(SDI)…………………...………………….............35
4.3.2.2. PDI……………………………………………………………………….…37
4.3.2.3. Liste de scénarios SDI vers la base de données PostgreSQL………...38
- Extraction des données spatiales SHP vers PostgreSQL………....................39
- Fichiers CSV vers base de données PostgreSQL…………..............................40
- Fichiers ACCES vers base de données PostgreSQL………………………….41
- Extraction des champs vers une table Excel, PostgreSQL avec requêtes….42
- Le mappage..........…………………………………………………………….….44
4.3.2.4. Bilan de l’outil : justification de choix de SDI........................................45
4.4. Problèmes rencontrés................................................................................................46
PARTIE IV
5. Valorisation de la base de données................................………………………..………....47
5.1. Mapserver : solution de webmapping libre et gratuite........................................47
5.2. Les géowebservices………………………………………………………………......48
Conclusions et perspectives...............................................................................................52
Liste des tableaux.................................................................................................................54
Liste des figures....................................................................................................................55
Glossaire et Acronymes.......................................................................................................56
Bibliographie/Webographie...............................................................................................57
Annexes..................................................................................................................................59
-5Structuration d’une base de données sur l’agriculture en Rhône-alpes
INTRODUCTION
Dans le cadre de ses missions d'animation, de veille et de prospective sur
l'agriculture et les territoires, la Chambre Régionale d'Agriculture est amenée au
sein des différents pôles environnement/territoires, et prospective, à utiliser des
données spatiales à différents échelles. Ces données ne sont, jusqu’à présent, pas
centralisées ni harmonisées. Pour une meilleure utilisation et valorisation aussi
bien par les acteurs de la chambre que par les partenaires extérieurs, la chambre
régionale d’agriculture a voulu, dans le cadre de ce travail de fin d’étude, entamer
une réflexion sur une meilleure structuration des données sur l’agriculture en
Rhône-alpes, qui facilite cet accès et cette valorisation des données.
Dans ce contexte, la structuration, et la centralisation des données
apparaissent comme un des enjeux majeurs pour le SI des chambres d’agriculture
de RA. C’est pourquoi on m’a confié la réalisation d’une base de données
exhaustive capable de gérer des données diverses et variées, constituant ainsi un
réceptacle commun et de travail pour tout traitement et valorisation (études,
analyses, diagnostics, pronostique, création d'indicateurs...) en lien entre autres
avec l'Obsagri Rhône-Alpes (Observatoire de l'agriculture en Rhône-Alpes).
L’enjeu du stage repose alors sur une forte sensibilisation de l’ensemble du
personnel de la division à l’importance de la gestion des données, à un
apprentissage des outils d’intégration des données issues de différents formats
(spatiales, sémantiques) et à de nouvelles méthodes de travail.
Cette étude doit à terme susciter chez les acteurs de la CRARA la volonté de
mutualiser leurs données afin de permettre une meilleure gestion des données,
faciliter le stockage, la consultation et l’exploitation de ces données dans des
projets cartographiques.
Afin de présenter l’ensemble du travail réalisé au cours des six mois de stage,
ce rapport s’articule autour de quatre parties. La première décrit le cadre dans
lequel le stage s’est déroulé, ainsi que les objectifs qui lui sont assignés. Il s’agit de
présenter de façon brève la structure d’accueil. La deuxième partie est composée
de deux volets. Le premier évalue les besoins en données géographiques à la
CRARA, et dresse un aperçu sur les méthodes utilisées lors de la conception des
données et plus particulièrement le langage UML. Ce dernier a été choisi pour ses
capacités à exprimer et à élaborer, de manière normalisée, des modèles objet,
indépendamment de toute plate-forme de réalisation (langage ou SGBD, etc.).
-6Structuration d’une base de données sur l’agriculture en Rhône-alpes
Dans le deuxième volet, je vous exposerai, les différents diagrammes UML
résultants de l’analyse préliminaire.
La troisième partie est consacrée à la procédure de mise en en œuvre de la
base de données sur Postgresql muni de sa cartouche spatiale Postgis. Le logiciel
cartographique Qgis est utilisé pour procéder aux tests de vérification et de
manipulation des données géographiques de la base.
La quatrième partie est axée, d’une part sur l’intégration des données de la
base de données de la CRA via des outils ETL (Extract Transform Load) Open
Source, notamment les deux leaders : SDI (Spatial Data Integrator) de C2S porté
sur Talend et PDI (Pentaho Data Integrator), et sur le déploiement des services
web pour l’accès aux données concernant les futurs utilisateurs de la base de
données (stagiaires...).
En dernier lieu, une synthèse est proposée sur le travail réalisé, les apports et
les difficultés ainsi que sur les enseignements que j’ai pu tirer de cette expérience
professionnelle.
-7Structuration d’une base de données sur l’agriculture en Rhône-alpes
- PARTIE I 1. CONTEXTE GENERAL DU STAGE
1.1. Structure d’accueil
Au même titre que les chambres départementales, la Chambre Régionale
d'Agriculture de Rhône-Alpes est un établissement public. Elle est actuellement
présidée par Gérard Seigle Vatte, également président de la Chambre
Départementale d’Agriculture de l’Isère. La structure totalise 18 employés et s’est
fixée trois objectifs :
Objectif 1 : L’économie, la qualité et la sécurité pour une agriculture
rentable et fiable.
Objectif 2 : L’adaptation aux attentes de la société pour une agriculture
viable et renouvelable.
Objectif 3 : Le renforcement de la cohésion sociale et territoriale pour une
agriculture durable et vivable.
Pour assurer ces grandes orientations, la Chambre Régionale est organisée
autour de huit pôles. Nous retrouvons donc quatre pôles opérationnels que sont
les pôles Qualité et filière ; Emploi et formation des agriculteurs et des salariés,
Recherche et développement ainsi que le pôle Territoire. Il existe également des
pôles transversaux : le pôle Environnement, Communication, Observatoire &
analyse et Organisation & méthode (SYNAGRI, 2010).
1.1.1. Les missions
La mission principale de la Chambre Régionale est d’assurer un rôle
consultatif et défenseur des intérêts agricoles de la région. Précisément, elle met en
place des commissions de réflexions stratégiques et de coordination des
programmes et projets.
Elle vise à conforter les partenariats avec les acteurs concernés par
l’évolution de l’agriculture. Elle aspire à renforcer la qualité des services aux
agriculteurs et aux collectivités. Enfin, la Chambre Régionale d’Agriculture
recherche à améliorer l’efficacité du travail et de la gestion des Chambres
Départementales (Figure 1).
De plus, la Chambre Régionale vise à faciliter la création et le fonctionnement
de réseaux de compétences en Rhône-Alpes. Cette mission a pour vocation finale
l’émergence d’une politique agricole cohérente sur la région (SYNAGRI, 2010).
-8Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 1 : Missions et organisation la CRARA
1.1.2. Organisation de la Chambre Régionale d'Agriculture de Rhône-Alpes
C’est au sein de la branche SGBD et observatoires, que j’ai effectué mon stage
pendant ces six mois.
Figure 2 : Organigramme de la CRARA - 2011
-9Structuration d’une base de données sur l’agriculture en Rhône-alpes
1.2. Objectifs du stage
L’objectif de ce travail est de centraliser les données géographiques et
sémantiques des différents pôles au sein d’une base de données exhaustive
permettant de répondre aux besoins de différents acteurs de la CRARA. Il s’agit
donc de:
Faire un état des lieux des utilisations des données géographiques, ainsi
que les besoins et attentes dans les différents pôles de la CRARA.
Conceptualiser la base de données, à cet effet le langage UML2 a été choisi
pour ses capacités à élaborer, de manière normalisée des modèles objet.
Etudier des possibilités techniques de mise en œuvre de la BD, dont
notamment Postgresql/Postgis et Qgis pour la consultation.
Initialiser la base de données en données géographiques et non
géographiques (attributaires et sémantiques).
Formuler des propositions en matière de solutions d’échange et
d’alimentation de la base de données en cohérence avec SIRCA en utilisant
des outils ETL.
Traitement et valorisation.
1.3. Méthodologie du projet
La conduite d’un projet informatique, tel que le développement d’un
système d’information, fait appel à des méthodes formalisées dont les principales
sont : Les méthodes séquentielles dites en cascade et les méthodes itératives
(évolutive, objet).
Depuis des décennies, les projets sont gérés avec une approche classique, le
plus fréquemment « en cascade » ou son adaptation « en V », basée sur des
activités séquentielles : on recueille les besoins, on définit le produit, puis on le
développe, ensuite on le teste avant de le livrer au client.
Vu que les besoins évoluent en permanence pour répondre aux changements
du marché, ces approches prédictives se sont révélées trop « rigides »parfois, sont
alors apparues, dans les années 1990, des méthodes moins prédictives ; ce sont les
méthodes dites « agiles».
-10Structuration d’une base de données sur l’agriculture en Rhône-alpes
Séquentielle
Cascade
Principe de découper le projet
en phases distinctes sur le
principe
du
non-retour
développé dans les années 1970
par W.ROYCE
Itératives
Evolutive
Principe basé sur la polyvalence
et
une
approche
pluridisciplinaire, qui tendent à
minimiser
l’impact
de
l’évolution des besoins en cours
de projets
Objet
Principe basé sur la séparation de
l’étude d’architecture de celle de
l’étude
fonctionnelle
afin
de
paralléliser au maximum les tâches.
Procède par itération comme pour
l’évolution
Figure 3 : Description des principales méthodes de conduite d’un projet (Hencoque;
2004)
Après une étude exploratoire des méthodes de conduite de projet et pour
répondre aux objectifs fixés en début de stage, l’approche « cascade » et plus
particulièrement le cycle de développement en V s’est révélé le plus approprié
pour ce travail.
C’est donc , ce modèle de développement en V, qui a été choisi d’une part,
pour sa fiabilité, en proposant au fur et à mesure une démarche de réduction des
risques et en minimisant au fur et à mesure l’impact du doute. Cette démarche
consiste en fait à découper le modèle en phases ou étapes séparées par des points
de contrôle (phase de vérification et de validation), et d’autres part, parce que le
cycle V est moins compliqué et mieux adaptée concernant aux ressources et à la
mise en œuvre du projet de notre projet destructuration d’une base de données.
Figure 4 : Prototype d’un modèle de développement en V (Marc Collin, 2009)
Les étapes du modèle de développement en V (variante de l’approche
cascade) résument de façon synoptique les différentes phases du projet.
-11Structuration d’une base de données sur l’agriculture en Rhône-alpes
Les étapes du modèle, de développement en V (variante de l’approche
cascade), que représente le schéma ci-dessous, résument de façon synoptique les
différentes phases de notre travail.
Figure 5 : Processus de développement du projet tiré du modèle en V
1.4. Planning de réalisation
La figure ci-dessous illustre le planning de déroulement du stage (les
objectifs initiaux à réaliser durant mon stage ainsi que le temps consacré à chacune
des tâches). Celui-ci a été établi au début du stage, il a été modifié tout le long du
stage en fonction des contraintes rencontrées.
Il convient toutefois, de noter que certaines tâches ont été sous estimées dans le
planning initial des réalisations :
La définition des besoins a été plus longue que prévu.
La modélisation de la base de données a pris beaucoup plus de temps que
prévu étant donné la complexité en termes de besoins de la part des
acteurs.
Certaines tâches imprévues sont venues s’ajouter comme l’intégration des
données à la base de données ainsi que sa maintenance.
-12Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 6 : Planning organisationnel du stage
-13Structuration d’une base de données sur l’agriculture en Rhône-alpes
- PARTIE II 2. ETUDE CONCEPTUELLE DES BASES DE DONNEES
2.1. Méthodes utilisées de conception de systèmes d’information
La conception d'un système d'information n'est pas évidente car il faut
réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de
conception nécessite des méthodes permettant de mettre en place un modèle sur
lequel on va s'appuyer. Aujourd’hui, les deux principales méthodes d'analyse
utilisées sont : Merise et UML.
Certes, nous savons bien que Merise est une méthode qui est déjà ancienne
avec plus d’une vingtaine d’années de pratiques en entreprise, donc plutôt en fin
de cycle de vie, et par contre UML est une norme récente de langage de
modélisation objet qui connaît une diffusion de plus en plus large dans les
entreprises. Pour plus de clarté, nous établissons un petit comparatif de ces deux
approches les plus pratiquées aujourd’hui dans le domaine de la modélisation des
données.
2.1.1. UML 2
UML se définit comme un langage de modélisation graphique et textuel
destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer des
points de vue. UML unifie à la fois les notations et les concepts orientés objet. Il ne
s’agit pas d’une simple notation graphique, car les concepts transmis par un
diagramme ont une sémantique précise et sont porteurs de sens au même titre que
les mots d’un langage.
UML unifie également les notations nécessaires aux différentes activités d’un
processus de développement et offre, par ce biais, le moyen d’établir le suivi des
décisions prises, depuis l’expression de besoin jusqu’au codage.
Très utilisé depuis de nombreuses années dans le monde technique et
industriel, le langage UML trouve sa place dans des grands projets informatiques
(projets de gestions, projets orientés vers l’Internet...).
-14Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 7 : Historique d’UML (Pascal Roques, 2005)
UML 2 s’articule autour de treize types de diagrammes, chacun d’eux étant
dédié à la représentation des concepts particuliers d’un système logiciel. Ces types
de diagrammes sont découpés selon trois points de vue classiques : fonctionnel,
statique et dynamique.
Figure 8 : Les trois points de vue de la modélisation UML (Pascal Roques, 2005)
-15Structuration d’une base de données sur l’agriculture en Rhône-alpes
Dans ce travail, nous utiliserons principalement, le modèle statique
(diagramme de classe, diagramme de package) et le modèle fonctionnel pour la
conception de la base de données1.
2.1.1.1. Le modèle fonctionnel
Parlons à présent d’UML et voyons quelle aide il peut apporter lors du
recueil des besoins. UML n’est qu’un langage et il ne sert ici qu’à formaliser les
besoins, c’est-à-dire à les représenter sous une forme graphique suffisamment
simple pour être compréhensible par toutes les personnes impliquées dans le
projet.
Un cas d’utilisation (Use Case) représente un ensemble de séquences
d’actions qui sont réalisées par le système et qui produisent un résultat observable
intéressant pour un acteur particulier. Chaque cas est décrit par un verbe à
l’infinitif suivi d’un complément de point de vue de l’acteur.
Le diagramme de cas d’utilisation est un schéma qui montre les cas
d’utilisation (représenté par des ovales), reliés par des associations (lignes) à leurs
acteurs (icône appelé « stick man » pour les acteurs humains et une représentation
rectangulaire pour les systèmes connexes). Chaque association signifie simplement
« participe à ».
Figure 9 : Concepts de base de diagramme de cas d’utilisation (khalid, 2011)
1
Vous pouvez retrouver toutes les explicatives détaillées des treize
diagrammes UML au livre les cahiers du programmeur UML, 4 éditions Pascal
Roques).
-16Structuration d’une base de données sur l’agriculture en Rhône-alpes
2.1.1.2. Le modèle structurel
Le modèle structurel ou statique s’exprime par des diagrammes composés de
classes, de catégories ou paquetages et de relations entre les classes et les
paquetages.
Le diagramme de classes est considéré comme le plus important de la
modélisation orientée objet. Il contient principalement des classes, une classe
contient des attributs et des opérations. Le diagramme de classes n’indique pas
comment utiliser les opérations.
Pour créer un diagramme de classes, vous avez besoin d’abord de définir les
classes et leurs attributs, les paquetages ainsi que les relations possibles entre ces
éléments. Il peut également décrire les regroupements de classes en paquetages,
les interfaces et les objets, les classes qui participent à une collaboration ou qui
réalisent un cas d’utilisation, etc.
2.1.2. MERISE :
La méthode MERISE(Méthode d'Etude et de Réalisation Informatique par
Sous Ensemble) est une méthode d’analyse, de conception et de gestion de projets
informatiques, elle est le résultat des travaux menés par Hubert Tardieu dans les
années 1970 et qui s'inséraient dans le cadre d'une réflexion internationale, autour
notamment du modèle relationnel d'Edgar Frank Codd2.
La méthode Merise se caractérise par :
une approche systémique en ayant une vue de l’entreprise en terme de
systèmes.
une séparation des données (le côté statique) et des traitements (le côté
dynamique).
une approche par niveau (Merise propose de décrire un SI suivant quatre
niveaux d’abstraction allant de l’abstrait vers le concret).
2
Edgar Frank Codd (23 août 1923 - 18 avril 2003) fut un informaticien
britannique. Il est considéré comme l'inventeur du modèle relationnel des SGBDR
-17Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 10 : Niveaux d’abstraction Merise (Hencoque, 2004)
La force de la méthode Merise est de structurer les besoins des décideurs de
façon simple et compréhensible. Merise améliore la communication entre les
différents acteurs du processus de développement.
2.1.3. Choix de méthode pour la modélisation des données
Après avoir récapitulé les principes de base des deux approches, nous avons
préféré le choix de la méthode objet UML pour la modélisation des données. Ce
dernier a été choisi pour ses capacités à exprimer et à élaborer, de manière
normalisée, des modèles objets, indépendamment de toute plate forme de
réalisation. C’est ainsi, qu’il répond mieux au contexte du projet (objectifs
prédéfinis du stage).
La modélisation UML présente de nombreux avantages à travers un
ensemble de propriétés (classe, encapsulation, héritage et abstraction, paquetage,
modularité, extensibilité, adaptabilité, réutilisation), et présente une diversité des
diagrammes produits (diagramme de components..), qui lui confère toute sa
puissance et son intérêt. UML présente actuellement un outil incontournable pour
la conception des SI.
Le langage UML est un support de communication performant : il cadre
l'analyse; il facilite la compréhension de représentations abstraites complexes; son
caractère polyvalent et sa souplesse en font un langage universel.
Certes, l’apprentissage de langage UML nécessite une formation plus poussée, en
effet, j’ai consacré assez de temps pour la mise en main et l’appropriation d’UML à
travers différents outils de modélisation.
-18Structuration d’une base de données sur l’agriculture en Rhône-alpes
2.1.4. Choix d’outils de modélisation :
Aujourd’hui, il existe une pléthore d’outils disponibles (propriétaires ou
libres) pour réaliser des modèles de données. : Enterprise Architect, MagicDraw,
MEGA Designer, ModelSphere, MyEclipse, Objecteering, Agro UML, BOUDL,
AnalyseSI, Poseidon for UML, PowerAMC, Rational Rose Data Modeler, Together,
Visio, Visual Paradigm.
Visual UML et Win’Design. Certes, il y a des outils qui ne prennent pas en compte
la notation UML pour l’instant (Database Design Studio, DeZign, AllFusion
ERWin, xCase, CASE Studio).
Nous ne tenterons pas de faire ici un comparatif exhaustif des outils
disponibles. Notre choix s’est arrêté sur deux outils qui répondent à nos critères
suivants :
supporter la notation UML2 en permettant de réaliser des modèles de
données (niveaux conceptuel au niveau physique) et des modèles de cas
d’utilisation.
automatiser la dérivation des modèles physiques.
générer le code en différents langages, dont notamment SQL (norme SQL2
compatible avec SGBD Postgesql).
réaliser un modèle de cas d’utilisation à l’aide de la notation UML.
La qualité d’implémentation des différents diagrammes de classes incluant
les critères suivants :
associations binaires et n-aires, classes-associations et agrégations ;
héritage (décomposition au niveau logique et héritage multiple) ;
Les deux outils retenus sont ainsi : PowerAMC de Sybase et SDE
PARADIGM (éclipse) à travers la version standard offerte aux enseignants et qui
inclut suffisamment de fonctionnalités utilisables, ces logiciels ont ainsi répondu à
nos critères énoncés plus haut.
-19Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 11 : Logiciel SDE pour éclipse
Quelques points forts : un grand choix de SGBD est pris en compte ; la
réactivité et l’efficacité du support. Les points faibles concernent le déplacement
des objets et des liens sur un graphique du niveau logique (Entity-Relationship)
qui n’est pas toujours réussi et la non-prise en compte des identifiants et des
associations n-aires.
PowerAMC (anciennement AMC*Designor) est la version française de l’outil
de modélisation. L’ergonomie de l’outil est très réussie : il est très intuitif de créer
différents diagrammes, de les transformer entre eux, de générer le script SQL ou
de rétroconcevoir une base de données (à partir des tables ou d’un script). Les
seuls points faibles se réduisent à la non prise en compte des contraintes et des
associations n-aires avec la notation UML.
-20Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 12 : Logiciel Power AMC
2.2. Etude de l’existant et recueil des besoins et attentes des acteurs
L’objectif, comme décrit succinctement au début du rapport, est le recueil des
besoins auprès des agents de la chambre régionale et l’évaluation des données
existantes, qu’elles soient thématiques ou spatiales. Ce recueil est indispensable et
doit précéder la modélisation du système d’information.
Un questionnaire a été élaboré à cet effet (cf. Annexe 1) et a été soumis aux
agents des différents pôles (chefs de projets, ingénieurs, techniciens, etc.) de la
CRARA.
Le but de cette enquête étant de délimiter les besoins en termes de données
sémantiques et géographiques pour modéliser la base de données:
Faire un état des lieux des utilisations des données et référentiels dans les
différents pôles de la CRARA.
Identifier et inventorier les besoins et attentes des acteurs des différentes
pôles et filières (végétale, animale, vin, apiculture, etc.) de la Chambre
Régionale d’Agriculture.
Notons qu’il est primordial d’indiquer les ressources et les données qui
peuvent être ou déjà mobilisées pour répondre à ces besoins.
Les résultats de cette enquête ont servi de base pour la conception et la
structuration de la base de données exhaustive sur l’agriculture en Rhône-alpes
-21Structuration d’une base de données sur l’agriculture en Rhône-alpes
Les pôles de la CRARA enquêtés sont:
Pôle : Filière apicole
Pôle : Filière Vin
Pôle : Filière Diversification et circuits courts
Pôle : Filière Installation-Trasnmission
Pôle : Filières végétales, Avertissement agricole.
3. CONCEPTION DE LA BASE DE DONNEES SIG-CRARA
3.1. Cas d’utilisation résultant de l’analyse de l’enquête
C’est la modélisation résultant de l’analyse de l’existant et des besoins des
différents pôles.
Après consultation, nous avons catalogué les informations fournies par
chacun des agents. La nature des renseignements récoltés étant très variable, nous
avons procédé à une catégorisation de différents ensembles de projets qui
semblaient se dégager. Appartenant à des domaines d’activités variés, les
différents acteurs consultés ont chacun apporté le regard personnel qu’il portait
sur l’utilisation des données géographiques.
La démarche que nous avons adopté afin d’aboutir au modèle des cas
d’utilisation consisterait à :
Identifier les acteurs,
Identifier les cas d’utilisation,
Structurer les cas d’utilisation en packages,
Ajouter les relations entre cas d’utilisation,
Finaliser les diagrammes de cas d’utilisation par package.
-22Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 13 : Démarche de construction du modèle des cas d’utilisation (UML2 pratique
de la modélisation, 2008)
3.1.1. Identification des cas d’utilisation et des acteurs
L’annexe 3 liste les différents acteurs interrogés avec leur cas d’utilisation.
Nous nous sommes basés sur deux types d’acteurs :
les acteurs humains principaux directs décrits par leur profil : chef de
projet, stagiaire (mobilisant des données), etc.
les acteurs secondaires : ce sont des entités externes tels que les structures
(DRAAF, organismes externes, etc.) et qui interagissent aussi dans les cas
d’utilisations.
On pourrait également organiser les cas d’utilisation et les regrouper en
ensembles fonctionnels cohérents que sont les packages.
3.1.2. Description des cas d’utilisation
Pour décrire la dynamique du cas d'utilisation, nous avons recensé toutes les
interactions de façon textuelle sous forme de fiches descriptives, car c’est une
forme souple qui convient dans bien des situations. La fiche de description (cf.
Annexe 2) utilisée se compose de trois parties :
La première partie permet d’identifier le cas. Elle doit contenir le nom du
UC; résumé de son objectif, les acteurs impliqués…, la deuxième partie contient la
-23Structuration d’une base de données sur l’agriculture en Rhône-alpes
description du fonctionnement du UC sous la forme d’une séquence de messages
échangés entre les acteurs et le système, les pré-conditions…
La dernière partie de la description d’un cas d’utilisation est une rubrique
optionnelle, elle contient généralement les spécifications techniques et les
contraintes liées.
3.1.3. Diagramme de cas d’utilisation global (Use Case: UC)
Suite aux enquêtes menées, nous avons donc élaboré le diagramme des cas
d’utilisation plus sophistiqué répondant aux cas d’utilisation des acteurs.
Nous avons donc, dans ce diagramme représenté les acteurs principaux disposés à
gauche des cas d’utilisation, et les acteurs secondaires à droite. Il existe en effet
certains cas d’utilisation ayant un appui commun, ce qui permet d’organiser ces
cas d’utilisations en ajoutant des relations d’inclusion, d’extension et de
généralisation.
Figure 14 : Exemple de Généralisation/ spécialisation entre cas d’utilisation : Diagnostic
CDRA/PSADER et Suivi PSADER
Nous présenterons un extrait de cas d’utilisation final :
Figure 15 : Extrait du diagramme de cas d’utilisation
-24Structuration d’une base de données sur l’agriculture en Rhône-alpes
3.2. Modèle Structurel
Dans cette partie, nous avons procédé à la modélisation des diagrammes de
classes sous PowerAMC. L’étude préliminaire des utilisations des données
géographiques au sein de la chambre régionale montre que certains pôles
mobilisent des données géographiques et d’autres non. Les diagrammes de
classes, n’ont été par conséquent proposés que pour les pôles ayant déjà des
mobilisés des données.
Pôles
Besoins
Echelle
Données mobilisées
d’étude
Observatoire
des
- Réaliser une
- Cantonale
circuits base de
courts
- Base Bali de la CRARA
- Bienvenue à la ferme :
données
contenant les
http://www.bienvenue-a-laferme.com
informations
-ADPM : www.geomarches.com
que les
-Terres d’envie : site Internet
partenaires
auront voulu
- Association des producteurs fermiers
mutualiser
de la Loire
http://www.produitsfermiersloire.com/
- Association des producteurs fermiers
du Rhône
http://www.producteurs-fermiersrhone.com/
Pôle territoire
- Inventorier et
- Données sémantiques souvent sous
structurer les
format *.xls
données de
CDRA et
PSADER dans
- Régionale
-
Données
spatiales
sous
vecteur *.mif, ou *.shp
le cadre d’un
projet.
-25Structuration d’une base de données sur l’agriculture en Rhône-alpes
format
Filière laitière
Organiser et
centraliser les
données,
indicateurs
- Cantonale
- Données sémantiques en *.xls
- Régionale
-Départemental
laitières au
sein d’un
réceptacle
unique
Tableau 1 : Besoins et données mobilisées des acteurs
Au début de l’analyse, on doit représenter les classes et exprimer les liens
entre classes en n’utilisant que des associations. Puis dans chaque classe, on définit
les attributs avec leurs types.
La liste des propriétés est ainsi définie en nous basant sur des données déjà
existantes ou des propriétés conçues suite aux besoins des acteurs concernés.
Ensuite, on procède par le développement du modèle statique, il constitue la
deuxième activité de l'étape d'analyse. Nous allons désormais examiner quelques
classes en détail, en éliminant certaines (en fonction d’échange avec des acteurs),
ou au contraire en ajoutant d'autres. Cette phase de validation est itérative;
l'affinement des associations, ainsi que l'ajout des attributs, vont nous fournir de
précieuses informations. Voici les principales modifications :
- Affiner les associations : UML permet de renforcer la sémantique des
associations par le biais d'agrégations ou de décompositions, la généralisation.
La généralisation c’est de découvrir les classes possédant des caractéristiques
communes: attributs, associations, opérations. Les propriétés communes seront
rassemblées dans une superclasse, et les propriétés spécifiques resteront dans les
sous-classes.
- Exemple de généralisation
La classe « structure CC » a été spécialisée en 4 sous classes : « PVC », « Marché »,
« Vente_ferme », « AMAP ». Chacune de ses sous classes hérite des propriétaires
des propriétés de leur super classe « structure CC » et peut comporter des
propriétés spécifiques complémentaire selon le type de structure de vente.
-26Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 16 : Exemple d’héritage issu de modèle ‘observatoire des circuits courts’
- Affiner les attributs: Il s'agit donc de raffiner les classes en leur rajoutant ou en
leur enlevant des attributs.
- Classes d'association et discussion sur les multiplicités: Une association entre
deux classes peut elle-même comporter des attributs. Il convient donc de placer les
propriétés de cette association dans une nouvelle classe appelée classe
d'association.
La visibilité des attributs (public, privé, protégé) est exprimée à ce niveau. Le
modèle classe/ association doit être suffisamment simple pour pouvoir être validé
par le maître de stage.
Une fois apportés ces modifications, nous aurons le diagramme de classes final.
3.2.1. Diagrammes de classe associés aux paquetages
Notre modèle statique est presque finalisé. Pour rendre son emploi plus aisé
et afin de préparer l’activité de conception objet, nous allons le structurer en trois
packages : package des circuits courts, package lait, package territoire.
Chaque package contient bien un ensemble de classes fortement reliées, mais les
classes du dernier package lait sont presque indépendantes.
-27Structuration d’une base de données sur l’agriculture en Rhône-alpes
La structuration d’un modèle en package est une tâche délicate. Elle doit
s’appuyer sur deux principes fondamentaux : cohérence et indépendance.
3.2.2. Description détaillé du modèle de classe.
Cette phase de conception détaillée consiste à déterminer les éléments qui
interviennent dans le fonctionnement du système, et de définir leurs structures
ainsi que leurs relations.
Nous avons établi un dictionnaire de donnée qui décrit de manière détaillée les
éléments suivants :
La liste des classes du modèle, et des classes d’associations.
Les attributs des classes d’objets.
Les attributs des classes d’associations.
Le dictionnaire de données de la base de donnée sig_crara a été lancé pour
répondre à la nécessité de disposer de définitions uniformes dans l’ensemble de la
base de données afin d’éliminer les ambiguïtés et les concepts multiples rattachés
à un élément de données.
Les principales thématiques traitées dans ce dictionnaire sont celles :
Territoire et environnement : Mesures européennes, Projets de territoire
(CDRA, PSADER, etc.).
Circuits Courts : Type de vente, exploitations agricoles, personnes, etc.
Filière laitière : Indicateurs et statistiques de production laitière en Rhônealpes, etc.
Territoire
Circuits Courts
Filière laitière
Figure 17 : Les trois grands axes de dictionnaire de donnée sig_crara
-28Structuration d’une base de données sur l’agriculture en Rhône-alpes
Le dictionnaire de donnée est issu d’un travail collectif avec de très
nombreux acteurs de la chambre régionale d’agriculture.
3.3. Niveau physique : Passage au modèle relationnel (MPD)
A cette étape le modèle physique de données MPD, a été généré à partir du
modèle conceptuel de données (MCD). Le niveau physique que nous décrivons ici
correspond à la définition des structures de données et à la programmation SQL
nécessaires à mettre en œuvre.
Nous utiliserons une syntaxe SQL2 (PostgreSQL, et MySQL) pour les scripts
s’appliquant aux bases de données relationnelles.
Le MPD permet de déclarer tous les éléments d’une base de données, en
particulier les tables, qui sont les conteneurs d’informations.
Power AMC a la capacité à représenter, avec la notation UML, des
associations binaires, de les transformer au niveau logique puis de générer un
script SQL. La prise en compte des identifiants de classes, multiplicités, rôles, etc.
est également étudiée3.
3
Pour en savoir plus sur les règles de passage de la notation UML
(agrégation, composition, héritage) au script SQL, référez vous au livre UML2
pour les bases de données avec 20 exercices corrigés de Christian Soutou
-29Structuration d’une base de données sur l’agriculture en Rhône-alpes
PARTIE III
4. MISE EN ŒUVRE ET DEPLOIEMENT DE LA BASE DE DONNEES
4.1. Choix de système de gestion de bases de données
Le système de gestion de bases de données relationnelles (SGBDR) retenu
pour la mise en place de ce projet est Postgresql 8.4, complété par sa cartouche
spatial Postgis.
Cette solution est de plus en plus utilisée dans de nombreux SI et a fait ses
preuves. Elle est conforme aux spécifications OGC (Open Geospatial Consortium)
et est très respectueuse du standard SQL.
Postgresql et Postgis sont des outils libres et gratuits, ce qui ne présente pas
une petite économie pour ce genre d’application.
Elle permet dans un contexte client/serveur transactionnel de travailler de
manières transparentes sur les données attributaires et spatiales. Il dispose d’une
interface graphique sous Windows, pgAdmin, qui rend plus aisée son utilisation.
De plus, son support ODBC (Open DataBase Connectivity) permet de définir et de
disposer d'une interface alternative à celle fournie par PostgreSQL, il est
compatible à SQL 92 et ceci, lui confère de nombreux avantages.
PostGIS (contraction de PostgreSQL et de GIS) est le module spatial qui
confère à PostgreSQL le statut de SGBDRO spatial. Il dispose de fonctionnalités
avancées et permettra de gérer sans problème les données géographiques
recueillies. De point de vue pratique, la géométrie des objets de la base de données
est stockée dans l’attribut ‘’géométrie ‘’. Cet objet est identifié de manière unique
par le champ Geom.
4.2. Création et structuration de la base de données
4.2.1. Création de la base de données sig_crara
La base de données géographique, baptisée sig_crara, a été crée sur le
serveur distant mis en place par la chambre régionale d’agriculture. Pour créer
une base de données spatiale, il existe plusieurs de méthodes :
Par commande SQL à partir de la console psql (exécution des scripts
lwpostgis.sql et spatial_ref_sys sur la base de données Postgresql).
Manuellement via pgadminIII avec choix du template Postgis
-30Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 18 : Template de Postgis Raster
4.2.2. Gestion des multi utilisateurs
L’accès et la connexion distante à la base de données sont organisés selon des
différents types d’utilisateurs. PostreSQL gère les droits d'accès aux bases de
données en utilisant le concept de rôles et les commandes Grant.
Un rôle correspond à un utilisateur et/ou à un groupe. Il a des droits et il
peut être membre d'un ou plusieurs autres rôles.
La gestion des rôles de la base de données sig_crara est définie autour d’un
administrateur central, chargé de la création des bases de données et des rôles (le
propriétaire accorde directement ou indirectement avec l’option Grant option des
privilèges aux utilisateurs).
Il y a deux sortes de privilèges :
les privilèges objet (table, vue, sous-programme, …) permettent de
manipuler des objets existant : consultation et modification d’une table ou
vue, exécution d’un sous-programme stocké
-31Structuration d’une base de données sur l’agriculture en Rhône-alpes
privilèges
types d’objet
select
table, view et sequence
update, delete, insert
table et view
alter
table et sequence
references (possibilité de définir une clé table
étrangère)
Tableau 2 : Liste de certains privilèges objet
les privilèges système permettent de modifier la structure de la base de
données en créant ou détruisant des objets,
privilèges
Types d’action
Create
Index pour optimiser des requêtes
Alter
Session connexion au SGBD table
Drop
trigger
type
user
view
database,
Tableau 3 : Privilèges système non exhaustifs
Un rôle est un assemblage de privilèges nécessaires pour assumer une
fonction. C’est ainsi que des utilisateurs définis accédant et mettent à jour à une
partie de la base de données sig_crara. Souvent, il existe un rôle « postgres » à qui
est attribué le droit « superutilisateur ».
4.2.3. Structuration de la base de données sig_crara :
Pour mieux organiser la base de données sig_crara, notre réflexion s’est
portée plus largement sur une base de données intégrant de manière modulaire
l’ensemble des données.
En effet, nous avons créé plusieurs schémas, un schéma par thématique. Les
différents modules ou schémas sont les suivants :
- Lait
-32Structuration d’une base de données sur l’agriculture en Rhône-alpes
- Circuits courts
- Référentiels classiques (périmètres d’inventaire, statuts de gestion, etc.)
- Rèf_IGN (Collectivités territoriales)
- Territoire
- IFEN
- etc.
L’introduction des schémas est effectué en rajoutant des commandes de
création de schéma (create schema) au script SQL résultant de la base de données
(la notion des schémas n’est pas paramétrée encore sur cette version Power AMC
lors de génération de MPD).
En effet, l’utilisation des schémas optimisera l’ensemble de la base de
données lors des requêtes de la base de données sig_crara par exemple sans avoir
utiliser le nom qualifié "schema.table" dans la requête.
4.3. ETL(Extract Transform Load)
Comme nous l’avons mentionné au début stage, l’intégration des données est
une étape clé dans la mise en œuvre de ce projet. En effet, l’objectif de cette partie
est de mener une réflexion sur des solutions et outils afin alimenter les tables de la
base de données sig_crara. Parmi ces outils, on notera les ETL (Extract, Transform,
Load).
4.3.1. Définition d'un outil ETL :
Un ETL est une boite à outil (prologiciel) qui permet ainsi l’Extraction, la
Transformation et le chargement (Load) de données depuis des sources diverses
(bases de données, fichiers) vers des cibles préalablement définies. Les ETL sont
communément utilisés dans l'informatique décisionnelle afin de permettre
l'alimentation des datawarehouses (entrepôts de données).
Concrètement, les sources d’alimentation de la base de données sig_crara
peuvent être variées : des bases de données (serveur des bases de données
Postgresql, et de n’importe quel SGBD), des fichiers sémantiques (CSV, Excel,
XML) et spatiales (SHP et MIF). Les ETL s'occupent de transformer ces sources,
via de nombreuses composants, en une ou plusieurs cibles qui peuvent être, là
aussi, de n'importe quels formats.
Les ETL servent à des fins décisionnelles, en étant des supports pour
l'analyse des données sous plusieurs formes :
Génération rapports et états
-33Structuration d’une base de données sur l’agriculture en Rhône-alpes
Tableaux de bords (dashboards, balanced scorecard),
Indicateurs de performance (« KPIs »),
Analyse multi-dimensionnelle (OLAP),
Analyse exploratoire (Data-Mining).
Le schéma suivant résume les principales applications des ETL envisagés
dans le cadre de stage, ainsi d’autres fonctionnalités (migration de données,
synchronisation des données).
Figure 19 : Schéma explicatif de l'utilisation d'outils ETL dans le cadre de stage (khalid,
2011)
4.3.2. Choix des ETL Open Source
Avant de commencer les scénarios d’intégration des données, il a tout
d’abord fallu déterminer quel logiciel utiliser. Le choix est ainsi limité alors à
l’utilisation des logiciels Open Source.
Ce choix semble intéressant, car il combine deux principaux avantages : des
fonctionnalités complètes et du coût moins cher. Il ne faut pas oublier que l'Open
Source donne accès au code source (procédures SQL, code Java ou autre), le
développeur peut donc le modifier pour ajouter des fonctionnalités. En outre, ETL
open source regroupe une communauté très active à travers du monde.
Certains ETL open source sont très répandus et donc, faciles à référencer
pendant que d'autres se font beaucoup plus discrets sur la toile. Le choix de l’ETL
à utiliser est un petit peu fastidieux, vu la diversité des ETL.
-34Structuration d’une base de données sur l’agriculture en Rhône-alpes
Cependant, Après avoir référencé et inventorier certains ETL Open Source
(Clover, Pentaho, open ESB, KETL, APATAR, etc.) à travers de nombreux sites
Internet (forums, sites, blogs, articles, etc.) et de la consultation de mon maître de
stage, ainsi d’autres experts que se positionnent les deux ETL les plus promoteurs,
et les plus connus « Talend Open Studio » et « kettle »
« Spatial Data Integration » et « Pentaho Data Integration » les deux
composantes spatiales des deux ETL ont été choisies en se basant sur plusieurs
critères reliés au contexte de nos objectifs :
Intégration d’une composante spatiale.
accessibilités (langues, licences)
compatibilités (support de base de données, fichiers plats supportés, plate
forme, etc.)
Organisation et communauté
Infrastructures (nombre d’employés, etc.)
Performances (vitesse, temps d’exécution, etc.)
Ces deux produits ont des approches techniques différentes, Kettle est un
moteur ETL, Talend est un ETL générateur de code. De par leur conception et leur
approche, ces deux ETL sont en fait plus complémentaires que concurrents.
4.3.2.1. Spatial Data Integrator (SDI)/TOS (Talend):
SDI (Spatial Data Integrator) est une évolution spatiale de l’ETL open source
TOS (Talend Open Studio), développé par Camp to Camp. Distribué sous la
licence GPL, SDI permet la lecture et l’écriture de formats spatiales SIG, ainsi
d’assurer plusieurs transformations géo-spatiaux et la publication de méta
données. Avec la diversité des ses composantes 50 composants/connecteurs, il
reste le principal outil spatial Open Source concurrent de l’ETL FME (ETL
propriétaire).
-35Structuration d’une base de données sur l’agriculture en Rhône-alpes
Figure 20 : Les composantes géographiques de SDI
Cet ETL spatial open-source est fondé sur Talend Open Studio, premier
logiciel open source spécialisé dans l’intégration de donnée avec plus de 300
composants/connecteurs et de 300 000 utilisateurs.
Talend Open Studio est un ETL du type « générateur de code », c’est à dire
que, pour chaque job créé, un moteur va s'occuper de générer du code Java ou
Perl. Les transformations sur TOS s'appellent des Jobs (tâches en français).
La première version de « Talend Open Studio » que nous avons utilisé est
V4.0.1 parue au 2 juin 2010.
L’outil contient trois composantes principales :
Business Modeler
Cet espace permet de modéliser les processus métier et l’avancement des
développements en cours au sein de dos jobs créés.
Référentiel
Cette fenêtre contient plusieurs onglets : Référentiel, Job Designs, contextes,
modèles SQL, metadata, documentation.
-36Structuration d’une base de données sur l’agriculture en Rhône-alpes
La palette des composantes
C’est dans cette partie que l’on pioche les composantes qui nous intéressent.
Spatial Data intégrator y ajoute la partie géo.
4.3.2.2. Pentaho Data Integration (PDI)
Pentaho Data Integration est un ETL Open Source du Produit Pentaho. Cet
ETL, (anciennement K.E.T.T.L.E – Kettle ETTL Environment), est le fruit du travail
de Matt Casters, un consultant BI qui l'a développé à l'origine pour ses propres
besoins au début des années 2000.
Contrairement à Talend Open Studio, Pentaho Data Integration est un «
moteur de transformation » ETL : les données traitées et les traitements à effectuer
sont parfaitement séparés. Il permet de connecter à un grand nombre de bases de
données de nombreux types de SGBD (une trentaine) ainsi que tous les types de
fichiers plats (Csv, délimité, Excel, XML).
Figure 21: PDI (Pentaho Data Integrator)( Samatar HASSAN, 2006)
PDI est constitué de trois principales composantes : Pan, Kitchen, et
l'interface graphique « Spoon ». Cette interface graphique, faite avec SWT
(Standard Widget Toolkit, bibliothèque graphique Java) peut créer deux types de
traitements :
Des transformations : celles-ci constituent les traitements de base
d'intégration de données avec toutes les étapes (steps) nécessaires à
l'extraction, la transformation, et le chargement des données.
Figure 22 : Transformations
-37Structuration d’une base de données sur l’agriculture en Rhône-alpes
Des tâches (jobs) : ceux-ci permettent le séquencement de plusieurs
transformations complexes avec des fonctionnalités plus orientés « EAI » :
gestion des erreurs, envoi de mails de notification, transferts FTP/SFTP,
exécution de scripts shell ou SQL, etc.
Figure 23 : Jobs dans SDI
La version utilisée de PDI est : Pentaho Data Integration v4.2.0, Afin d’accéder
directement à l’interface de travail.
4.3.2.3. Scénarios d’intégration des données vers la base de données
Postgresql/Postgis
La plupart des données que nous avons recueilli lors de la conception de la
base de données sig_crara, englobe à la fois des fichiers plats (Excel, Acces), et des
fichiers géographiques sous format *.shp et *.mif.
En effet, le but de ce volet est concevoir des scénarios d’intégration qui
alimentent la base de données sig_crara d’une part, d’autre part répondre ainsi
aux orientations de mon maître de stage. Ces essais ont été réalisés par les deux
ETL, afin qu’on puisse les comparer, et de choisir l'ETL le plus approprié pour ce
projet.
-38Structuration d’une base de données sur l’agriculture en Rhône-alpes
Pentaho Data Integration (Pentaho)
Spatial Data Integrator (Talend Open Studio)
Extraction des données spatiales (SHP) vers Postgis :
Descriptif
Modélisation
1. Le Job contient deux éléments :
Détails
1. Cette transformation comporte deux composantes :
-
sShapefileInput à partir de la paletteGeo/Fichier/Lecture. -
-
sPostgisOutput dans la palette Geo/Database :
-
Extraction depuis un fichier ESRI
Insertion dans une table.
Remplir les paramètres de connexion de la base de données :
nom de base de données, utilisateur, mot de passe, schéma,
Configurer à nouveau la connexion en utilisant un assistant de
etc.)
création de requêtes SQL
Créer un schéma générique à partir de shapefile à partir de
l’onglet metadata de la fenêtre Référentiel (sShapefileInput).
2. Effectuer une liaison principale de type row main entre les
La récupération des schémas est automatique
2. Etablir un lien entre les deux actions
3. Exécuter le module
deux composantes.
3. Exécuter le module par Run ou F6
Tableau 4 - Test 1 : Extraction des données spatiales (SHP) vers Postgis
-39Structuration d’une base de données sur l’agriculture en Rhône-alpes
Pentaho Data Integration (Pentaho)
Descriptif
Spatial Data Integrator (Talend Open Studio)
Fichiers CSV vers base de données Postgresql
Modélisation
Détails
Le scénario suivant est un Job de deux composants :
Le Test comporte deux composantes :
-
tFileInputDelimited,
-
Extraction depuis fichier CSV
-
tPostgesqlOutput.
-
Insertion dans table
Les métadonnées de type File Delimited peuvent être Définir toutes les informations concernant le fichier CSV : le nom
utilisées pour définir les propriétés des composantes de table, séparateur de champs, type d’encodage.
InputFileDelimited (création du schéma CSV).
Le séparateur «,» du fichier initial est remplacé par le séparateur
Différents opérations effectué sur les tables : Insertion, «;»
Insertion et Mise à jour, Mise à jour, etc.
Tableau 5 - Test 2 : Fichiers CSV vers base de données Postgresql
-40Structuration d’une base de données sur l’agriculture en Rhône-alpes
Pentaho Data Integration (Pentaho)
Descriptif
Spatial Data Integrator (Talend Open Studio)
Fichiers ACCES vers base de données Postgresql
Modélisation
Détails
Le scénario suivant est un Job de deux composants :
Le Test contient deux composantes :
-
tAccessInput_1
-
Extraction depuis une base de données MS Access
-
tPostgesqlOutput.
-
Insertion dans table
Définir toutes les informations concernant la base de Définir toutes les informations concernant le fichier CSV : le nom
données Access y compris le nom de table, nom de table, séparateur de champs, type d’encodage.
d’utilisateur, mot de passe.
Tableau 6 - Test 3 : Fichiers ACCES vers base de données Postgresql
-41Structuration d’une base de données sur l’agriculture en Rhône-alpes
Pentaho Data Integration (Pentaho)
Descriptif
Spatial Data Integrator (Talend Open Studio)
Extraction des champs (requêtes) vers une table Excel, Postgresql
Modélisation
Détails
Le scénario suivant est un Job de deux composants :
Le test comporte deux composantes :
-
tPostgresqInput
-
Extraction depuis une table
-
tFileOutputExcel_1 et TfileOutputExcel_1 (2 ème cas)
-
Alimentation fichier Excel et Insertion dans table (2 ème cas)
Procéder à des requêtes d’extraction des champs via le Le filtrage des champs ou des requêtes attributaires se fait via le
bouton obtenir script SQL.
composant tPostgresqlInput.
Tableau 7 - Test 4 : Extraction des champs (requêtes) vers une table Excel, Postgresql
-42Structuration d’une base de données sur l’agriculture en Rhône-alpes
Spatial Data Integrator (Talend Open Studio)
Mappage : tMap est un composant avancé qui s’intègre à Talend Open Studio, Il dispose plusieurs avantages qui le
Descriptif
permettent d’être la composante la plus renforcée et utilisée, le tMap transforme et dirige les données à partir d’une
ou plusieurs source(s) et vers une ou plusieurs destination(s).
- Scénario1 : Mapping de données
Modélisation
-43Structuration d’une base de données sur l’agriculture en Rhône-alpes
- Scénario 2 : Mapping multiple avec des tables de sortie
Détails
Le scénario 1:
Le scénario 2 :
-
tFileInputDelimited
-
tFileInputDelimited
-
tPostgresql_output1.
-
Plusieurs sorties de table Postgresql
Correspondre les lignes du flux principal que vous voulez Le Job Java ci-dessous a pour objectif de lire des données d’un
fichier .csv stocké dans le Référentiel, puis d’extraire des
correspondre en sortie via l’interface graphique tMap
Connexion de la base de données est établi via Db
Connections dans le Référentiel de l’éditeur graphique
(tPostgresqlConnection)
données et d’envoyer ces données vers les fichiers de sortie
(tables Postgresql) et dont les schémas sont également stockés
dans le Référentiel
Tableau 8 - Test 5 : Le mappage
-44Structuration d’une base de données sur l’agriculture en Rhône-alpes
4.3.2.4. Bilan de l’outil : justification de choix de SDI
Après avoir décrit chacun des scénarios d’intégration de données sous les deux
principaux ETL, nous nous sommes fait une idée claire et fondée sur chacun d’eux.
Talend Open Studio, même s'il est plus récent que Pentaho Data Integration,
possède une plus grande communauté française. Talend est une société, notamment
basée en France, qui effectue de nombreux séminaires affichant toujours complet et
suscitant un très grand engouement de la part de la communauté BI.
PDI semble moins performant que TOS dans les calculs d'agrégations, en effet
parmi les composantes fortes dont on a eu besoin lors du stage et dont disposait
Talend : le composant tMap est très puissant. Il permet de faire facilement de
nombreux traitements.
Le référentiel de métadonnées de Talend Open Studio est très complet, il
permet de réutiliser des schémas de fichiers, de connections, de Web services et
autres et de gagner ainsi beaucoup de temps. On peut aussi ajouter ou créer de
nouvelles spécifités métiers (en Java ou Perl) en ajoutant de nouvelles routines.
De nombreux outils pour corriger des erreurs, de vérifier les statistiques, les
logs et de commenter les développements ou d'ajouter de la documentation sont mis
à disposition par Talend Open Studio.
Enfin, la cartouche spatiale SDI de Talend renferme une diversité de
composantes spatiales (manipulation de données géographiques, gestion de
plusieurs formats *.shp ou *.mif) par rapport au PDI.
Le choix de l'ETL, dépend donc de la nature du projet mais aussi, des
préférences des développeurs tant ces deux ETL sont différents d'utilisation.
Après l’analyse des performances des deux ETL, Il nous semble alors, que
Talend est plus adapté au contexte de notre projet, même si il est très difficile de les
départager et qu’ils se complètent d'avantage qu'ils ne sont concurrents.
4.4. Problèmes rencontrés
L’apprentissage de mappage présente l’un des principales difficultés
rencontrées. Le mappage des données est un concept très avancé qui s’intègre à
Talend Open Studio, il présente plusieurs utilisations, de la simple réorganisation
des champs de données aux transformations les plus complexes.
-45Structuration d’une base de données sur l’agriculture en Rhône-alpes
En plus, l’utilisation du composant tMap requiert un niveau moyen de
connaissances Perl ou Java afin d’exploiter au mieux ses fonctionnalités. Il nous a
fallu passer du temps pour l’apprentissage de certaines utilisations de ce composant.
Le choix de la version de l’ETL semble très pertinent, car certaines versions ne
gèrent pas correctement d’une bonne manière au cours de l’exécution des jobs, ou la
création de schémas par exemple. (Bugs, erreurs, etc.)
-46Structuration d’une base de données sur l’agriculture en Rhône-alpes
- PARTIE IV 5. VALORISATION DE LA BASE DE DONNEES :
Dans le cadre de la valorisation et la modernisation de la base de données, nous
avons mis une réflexion sur l’utilisation des géo services W*S, permettent de manière
limitée l’accès aux données (via le Web ou un client cartographique) à travers la mise
en place d'un serveur cartographique (Mapserver, ou Geoserver).
Ces possibilités techniques permettent d’envisager dans un futur proche
l’ouverture de la base de données aux partenaires.
5.1. Mapserver : solution de webmapping libre et gratuite
Nous avons opté le choix sur l’utilisation de Mapserver, parmi le monde des
serveurs cartographiques, celui-ci est déjà mis en place par la CRA pour d’autres
projets.
Mapserver est caractérisé non seulement par ses performances et sa fiabilité
reconnues, mais également par la diversité de ses fonctionnalités. Son statut de
logiciel libre (qui se traduit entre autres par un code source ouvert) lui confère une
certaine richesse de ce point de vue grâce à une communauté active
d’utilisateurs/développeurs. En outre, MapServer s’appui sur des librairies qui
s’enrichissent également en fonctionnalités avec le temps.
Nous recensons ici quelques caractéristiques importantes de MapServer :
Une diversité de formats raster en entrée.
Une diversité de formats vectoriels en entrée.
Formats d’images en sortie.
Compatibilité WMS, WFS, WCS et SFS, GML.
Connexion à des bases de données spatiales.
Une compatibilité avec divers langages de développement.
MS4W : est un paquetage fourni gratuitement par DM-solutions. Il regroupe les
binaires précompilés de l’ensemble des composants nécessaire pour installer un
service web basé sur le serveur Apache, le langage PHP ainsi que MapServer. Son
installation est vraiment très simple.
Mapfile : est le fichier de configuration de la carte lisible par MapServer. Il
possède une structure en sections et une syntaxe spécifique. Il s’ouvre, se créé et se
modifie avec le Notepad++.
L’architecture est de type client/serveur, c'est-à-dire qu’un ordinateur dit
serveur répond aux requêtes d’une série d’ordinateurs dits clients.
-47Structuration d’une base de données sur l’agriculture en Rhône-alpes
Alors, l’utilisateur (soit un client cartographique, ou un browser web), à partir
de son terminal effectue des requêtes pour demander l’affichage d’une carte
spécifique; Mapserver interprète cette requête et renvoie la carte sous la forme d’une
image matricielle (png, jpg,…) ou vectorielle (svg, swf,…). Il s’appuie sur ces
éléments pour recevoir des requêtes et renvoyer des images et des données. Côté
client, un navigateur web suffit, accompagné éventuellement par un client
cartographique pour l’affichage.
Internet
TCP/IP
Logiciels FTP
FileZILLA
Serveur de données
PostgreSQL/PostGIS
SQLite
MySQL
Transfert de fichiers
Connexion PostGIS
Connexion PostGIS
Logiciels SIG
QGIS
GvGIS
Serveur cartographique
Mapserver
Geoserver
Png, svg, xml, geojson…
Requête WMS/WFS
Navigateur internet
Chrome
Client cartographique
openlayers
Requête WMS/WFS
Pages HTML
Requête HTTP
SERVEUR APACHE/IIS
CLIENT
Figure 24 : Relations Client/Serveur ( Khalid, 2011)
Dans notre contexte, Les données géométriques sont gérées par, le système de
gestion de base de données PostgreSQL/PostGIS
5.2. Les Géowebservices :
Les
services
web
géographiques sont
des
services
web
permettant
d’effectuer des traitements géomatiques ou géographiques (géocodage…), de
renvoyer des cartes ou de donner accès à des données géographiques (débit d’un
fleuve, altitude, nom d’une zone géographique…)[Henri Pornon et al.2008].
Dans le cadre de ce travail, les web services accessibles sont principalement sont
le Web Map Service (WMS). Ces services répondent à des normes d'interopérabilité
édictées par l'Open Geospatial Consortium (OGC).
-48Structuration d’une base de données sur l’agriculture en Rhône-alpes
Ces géoservices mis en place permettent aux clients SIG et non SIG d'envoyer
des
requêtes au serveur cartographique Mapserver et d'obtenir en retour des
données géographiques soit sous forme d'images soit sous forme de flux XML.
Pour consulter l’ensemble des données disponibles, Il vous suffit de disposer
d'un logiciel cartographique capable d'utiliser des géowebservices (Qgis, par
exemple).
Le Web Map Service est un protocole permettant au moyen d'une URL
formatée d'interroger des serveurs cartographiques et d'obtenir ainsi des cartes géoréférencées
Le WMS permet par le biais d’une requête http de visualiser des données
géoréférencées situées sur un serveur cartographique d’une zone définie. La réponse
est donnée sous forme d’une ou plusieurs images (png, jpg, etc.).
Avec le WMS trois types de requête sont possibles :
GetCapabilities retourne les métadonnées qui décrivent le contenu du service
et les paramètres acceptés,
GetMap retourne une image d'une carte dont les paramètres géospatiaux et
dimensionnels sont correctement représentés,
GetFeatureInfo (optionnelle)
retourne
des
informations
sur
un
objet
représenté sur la carte.
http://...GetMAP
Navigateur
Logiciel SIG
Client
Internet
TCP/IP
Serveur
Cartographique
WMS
Données
PNG, JPEG, etc.
Figure 25 : Protocole WMS
Parmi les autres protocoles, les plus utilisées en géomatique :
Le Web Feature Service (WFS) qui permet d’interconnecter des sites
cartographiques par l’échange de fichiers vecteur grâce au format GML.
-49Structuration d’une base de données sur l’agriculture en Rhône-alpes
http://...GetFeature
Navigateur
Logiciel SIG
Client
Internet
TCP/IP
Serveur
Cartographique
WFS
Données
XML, GML
Figure 26 : Protocole WFS
Le Web Feature Service Transactional (WFS-T) « extension » du WFS, qui
permet l’ajout, la suppression et la mise à jour d’entités géographiques.
Le Web Processing Service (WPS) qui permet de réaliser des traitements de
données à distance (union, intersection...).
Parmi les formats SIG Web vecteurs les plus courants dans les services web
geographiques :
SVG (Scalable vector Graphics)
GML (Geographic Markup Language)
KML (KeyHole Markup Language)
Parmi les formats SIG Web Raster, on cite :
PNG (Portable Network Graphics)
GIF (Graphics Interchange Format)
JPEG (Joint Photographic Experts Group)
Concernant les géowebservices, nous allons montrer la manière de se connecter,
rajouter une couche spatiale postgis provenant d'un service WMS à travers le logiciel
cartographique.
Nous avons donc opté pour cette architecture client/serveur, de mettre en jeu
des clients et des serveurs de bases de données, et qui sont décrit comme suivent:
-50Structuration d’une base de données sur l’agriculture en Rhône-alpes
Le
stockage
de
données
sera
centralisé
sur
la
base
de
données
Postgresql/Postgsis
Le serveur Mapserver du coté cartographique, et Apache du coté web.
Client cartographie QGis ou le Browser web
La configuration choisie solution client/serveur est schématisée par le diagramme de
déploiement UML suivant:
Figure 27 : Diagramme de déploiement UML (khalid, 2011)
-51Structuration d’une base de données sur l’agriculture en Rhône-alpes
CONCLUSIONS ET PERSPECTIVES
La structuration, et la centralisation des données géographiques apparaissent
comme un des enjeux majeurs pour une meilleure gestion et maintenance d’un SI
dans les chambres d’agriculture de RA. Ce travail de conception et de modélisation
d’une base de données exhaustive sur l’agriculture en Rhône-Alpes a été engagé
dans ce sens. L’objectif pour la Chambre Régionale d'Agriculture est de constituer
une base centrale, homogène, sur l’agriculture et l’environnement au service aussi
bien des différents pôles et filières en interne que de ces partenaires externes.
Pour ce faire, une enquête a été menée afin de délimiter les besoins en termes de
données sémantiques et géographiques au sein des différents pôles de la CRARA., le
travail de conception qui s’en est suivi a permit :
de définir les composantes spatiales et sémantiques de la base.
de structurer les données de manière modulaire (lait, territoire, circuits courts,
etc.).
d’intégrer les couches d’information (IGN, IFEN, DREAL, etc.)
La plateforme logicielle – couple Postgresql /Postgis – utilisée pour mettre en
œuvre ce système d’information a permis de mettre en place des services d’accès aux
données. Ce travail s’est aussi porté sur les solutions d’intégration des données
géographiques dans la base. La composante SDI de l’ETL Talend a été choisie pour
cet effet.
La mise en œuvre de cette base de données permettra d’envisager
ultérieurement des solutions de valorisation et de porter à connaissance comme par
exemple le :
Création de tableau de bord (Reporting), diagnostic, etc
Webmapping (SIGA Territoire, Intranet, Extranet...).
Utilisation des protocoles standard de communication entre la base de
données et les applications associées.
Pour le maintien de cette base, un travail conséquent de développement de
partenariats avec des organismes détenteurs de données est à engager
L’une des évolutions et perspectives éventuelles de la base est l’intégration de
données matricielles avec PostGIS Raster.
-52Structuration d’une base de données sur l’agriculture en Rhône-alpes
D’un point de vue personnel, le bilan de ce stage reste pour moi très positif et
très encouragent. Les 6 mois passés au sein de la chambre régionale d’agriculture
m’ont permis de suivre un projet dans sa (quasi) totalité: de la définition et
formalisation des besoins à la conception de la base de données et à l’alimentation de
la base de données en passant par le choix des stratégies et des techniques à
employer.
Mon choix s’est rapidement trouvé conforté car je me suis bien adapté et je suis
entré en contact avec de nombreux acteurs dans ce monde professionnel. J’ai agi avec
une grande autonomie dans mon travail et j’ai bien été intégré dans la chambre. Mon
maître de stage a parfaitement rempli son rôle en étant là pour m’épauler et me
conseiller dans certains choix et de me former sur plusieurs outils mis en place par SI,
il a participé à mon adaptation au monde professionnel.
Enfin, je conclurai que ma formation technique obtenue lors du Master SIG et
gestion de l’espace a parfaitement été complétée par ce stage pratique. Elle m’a
réellement apporté les compétences techniques que j’étais venue chercher en
complément de ma formation en aménagement de territoire.
-53Structuration d’une base de données sur l’agriculture en Rhône-alpes
LISTES DES TABLEAUX
Tableau 1 : Les données mobilisées selon les acteurs et les besoins…………………………...25
Tableau 2 : Liste de certains privilèges objet.......………………………………………………...31
Tableau 3 : Les privilèges système non exhaustifs ………………………………….…………..31
Tableau 4 : Test 1 : Extraction des données spatiales (SHP) vers Postgis....................………..38
Tableau 5 : Test 2 : Fichiers CSV vers base de données Postgresql……………………………39
Tableau 6 : Test 3 : Fichiers ACCES vers base de données Postgresql………………………...40
Tableau 7 : Test 4 : Extraction des champs vers une table Excel, Postgresql avec requêtes....41
Tableau 8 : Test 5 : Le mappage…………………………………………………………………...43
-54Structuration d’une base de données sur l’agriculture en Rhône-alpes
LISTES DES FIGURES
Figure 1 : Missions et organisation la CRARA……………………………………………………9
Figure 2 : Organigramme de la CRARA – 2011…………………………………………………...9
Figure 3 : Description des principales méthodes de conduite d’un projet……………………11
Figure 4 : Prototype d’un modèle de développement en V…………………………………….11
Figure 5 : Processus de développement du projet tiré du modèle en V………………………12
Figure 6 : Planning organisationnel du stage……………………………………………………13
Figure 7 : Historique d’UML………………………………………………………………………15
Figure 8 : Les trois points de vue de la modélisation UML…………………………………….15
Figure 9 : Concepts de base de diagramme cas d’utilisation…………………………………...16
Figure 10 : Niveaux d’abstraction UML…………………………………………………………...17
Figure 11 : Logiciel SDE for éclipse………………………………………………………………...19
Figure 12 : Logiciel Power AMC……………………………………………………………………20
Figure 13 : Démarche de construction du modèle des utilisations……………………………...22
Figure 14 : Exemple de Généralisation/ spécialisation entre cas d’utilisation : Diagnostic
CDRA/PSADER et Suivi PSADER…………………………………………………………………23
Figure 15 : Extrait du diagramme de cas d’utilisation……………………………………………23
Figure 16 : Exemple d’héritage issu de modèle observatoire des circuits courts……………...26
Figure 17 : Les trois grands axes de dictionnaire de donnée sig_crara………………………...27
Figure 18 : Template de Postgis Raster…….………………………………………………………30
Figure 19 : Schéma explicatif de l'utilisation d'outils ETL dans le cadre de stage…………….33
Figure 20 : Les composantes géographiques de SDI……………………………………………...35
Figure 21: PDI (Pentaho Data Integrator)…………………………………………………………36
Figure 22 : Transformations…………………………………………………………………………36
Figure 23 : Jobs dans SDI……………………………………………………………………………37
Figure 24 : Relations Client/Serveur………………………………………………………………..47
Figure 25 : Protocole WMS………………………………………………………………………….49
Figure 26 : Protocole WFS…………………………………………………………………………...49
Figure 27 : Solution retenue schéma par le diagramme de déploiement UML………………..50
-55Structuration d’une base de données sur l’agriculture en Rhône-alpes
GLOSSAIRE ET ACRONYMES
A.D.P.M : Association pour le Développement et la Promotion des Marchés
A.M.A.P : Association pour le Maintien d'une Agriculture Paysanne
C.R.A : Chambre régionale d’agriculture
C .S.V: Comma-separated values
D.A.C : Diagramme de classe
E.T.L: Extract, Transform Load
G.D.A.L: Geospatial Data Abstraction Library
G.N.U ou GPL : General Public License
I.F.E.N : Institut Français de l'Environnement
K.E.T.L.L.E: Pentaho Data Integration Community Edition
M.C.D : Modèle conceptuel des données
M.P.D : Modèle physiques des données
M.S.4.W: MapServer for Windows
O.G.C: Open Geospatial Consortium
P.D.I: Pentaho Data Integrator
P.V.C : Point de vente collectif
S.D.I: Spatial Data Integrator
S.F.S: Simple Feature -SQL
S.G.B.D : Système de Gestion de Base de Données
S.G.B.D.R : Système de Gestion de Base de Données Relationnelles
S.I.G : Système d’Information Géographique.
S.I: Système d’Information
S.Q.L: Structured Query Language
T.O.S: Talend Open Studio
U.C: Use Case
U.M.L: Unified Modeling Language
W.C.S: Web Coverage Services
W.F. S: Web Feature Services
W.M.S: Web Map Services
B.U : Business Intelligence
-56Structuration d’une base de données sur l’agriculture en Rhône-alpes
BIBLIOGRAPHIE/WEBOGRAPHIE
Ouvrages généraux :
Pascal Roques, Les Cahiers du Programmeur UML2, Modéliser une application web,
4e édition ; EYROLLES, Paris ; p 4, 5, 40, 41
GILLES ROY, Conception de bases de données avec UML, Presses de L’Université
du Québec, 2009, Québec Canada G1V 2M2 ; p 447-450
Christian Soutou, UML2 pour les bases de données Avec 20 exercices corrigés,
Éditions Eyrolles, 2009 ; p 289, p189, p178, p 52
Christian Soutou, UML par la pratique, Éditions Eyrolles, 2009
Xavier Blanc, Isabelle Mounier et avec la contribution de Cédric Besse, UML2 pour
les développeurs, cours avec exercices corrigés, Eyrolles, Paris p14, p15, p16
Benoît CHARROUX, Aomar OSMANI et Yann THIERRY-MIEG ; UML 2 ; Pratique
de la modélisation, 2e édition, 2010, collection Synthex PEARSON Education, p2-9,
p35-45
Sylvain DECLOIX - Responsable Pôle OSBI Atol Conseils et Développements LIVRE
BLANC, Les ETL Open Source, une réelle alternative aux solutions propriétaires
Joseph Gabay, MERISE ET UML Pour la modélisation des systèmes d’information, 5
édition; 2004 ; p4, 5, 276-280
Sébastien LARDIERE, PostgreSQL Administration et exploitation d’une base de
données, seconde édition, collection Ressources Informatiques
Jean-Luc Baptiste, Merise: guide pratique, modélisation des données et des
traitements, langage SQL ; Ressources Informatiques, Edition ENI
Articles et documents:
Samatar HASSAN, Présentation de pentaho data intégration, Août 2006 – Version:
1.0
Odile THIERY, Projet bibliographique : guides d’utilisations des outils décisionnels,
2007
Henri Pornon Pierrick Yalamas Elise Pelegris, Services web géographiques, état de
l’art et perspectives, Géomatique Expert - N° 65 - Octobre-Novembre 2008
Talend Open Studio Composants Guide de référence 4.X
Talend Open Studio, Guide Utilisateur, Guide de référence 4.X
Thèses, mémoires et cours:
BALIZET Boris, Structuration d’une base de données et d’un SIG au sein de la
fédération départementale de pêche du GERS, Septembre 2010, Université de
Toulouse, MASTER 2 PROFESSIONNEL GEOMATIQUE
ANCELET, Estelle Elaboration d’un outil d’aide à la réalisation de diagnostic
territoriaux, septembre 2010, Université de Toulouse, MASTER 2 PROFESSIONNEL
GEOMATIQUE
Michel Passouant, Système d’Information Géographique (SIG) et WEB, Michel
Passouant, DESS IAO, Université MONTPELLIER II, Mai 2002.
-57Structuration d’une base de données sur l’agriculture en Rhône-alpes
Martine Elisabeth MATHIEU, Création d’un Système d’Information Spatialisé dans
le cadre d’un projet de recherche interdisciplinaire, Septembre 2009, Mémoire de fin
d’études , MASTER SIG ET GESTION DE L’ESPACE, Université Jean Monnet
SAINT-ÉTIENNE
Bouchet Mathilde, Les données liées aux espaces naturels : Etude et propositions
pour une meilleure gestion, Septembre 2007 Mémoire de fin d’études, MASTER SIG
ET GESTION DE L’ESPACE, Université Jean Monnet SAINT-ÉTIENNE
Gael TCHIOFFO KODJO, Conception et réalisation d'une application de
Webmapping d'analyse territoriale sur des SIG et bases de données open source : cas
du territoire camerounais, ESIG PARIS - Complexe Universitaire SIANTOU
Yaoundé - Master en Informatique Approfondie à la Gestion 2008
Florian FRANCHETEAU, Master Professionnel ALMA, 2007/2008, Université de
Nantes, Rapport de stage Étude des ETL Open Source
Cheikh DIOP, Nawel BOUARD, Simeon STANCIOFF, François VAN DER BIEST,
MapServer, solution de SIG libre en ligne, Un état des lieux de son utilisation en
France Mastère SILAT, PARIS, Mai 2006
Personnalisation et extension de PowerAMC, Guide utilisateurs
Pierre Racine Stockage, manipulation et analyse de données matricielles avec
PostGIS Raster, Session PostgreSQL, Paris, juin 2011
Jorgé Arévalo, Postgis_paris_raster_racine , 2011
,
Henocque Cours de SI. Bordeaux I 2004. Principales méthodes de conduite de
projet. Conduite de projet informatique.
__ _____
Sites officiels et documentation :
www.postgres.org
http://www.osbi.fr
http://fr.talend.com/index.php
www.commencamarche.net
www.developpez.com
http://trac.osgeo.org/postgis/wiki/WKTRaster
http://georezo.net
http://uml.free.fr
http://www.forumsig.org
http://www.talendforge.org
http://www.gnu.org/philosophy/categories.fr.html
-58Structuration d’une base de données sur l’agriculture en Rhône-alpes
ANNEXES
Annexe 1 : Enquête sur les besoins en données géographiques à la CRARA……….....…....…60
Annexe 2 : Liste des cas d’utilisation....................................................................................………62
Annexe 3 : Fiche description d’un cas d’utilisation des données géographiques et
sémantiques..............................................................................................................................………63
Annexe 4 : Comparatif des outils de modélisation UML 9.......................................................... 64
Annexe 5 : Principe de base des deux modèles UML utilisés ………………….................……65
Annexe 6 : Les treize diagrammes UML......................................................................................... 65
Annexe 7 : Détails sur le raster géoréferencé.................................................................................. 66
Annexe 8 : Type raster de Postgis Raster........................................................................................ 66
Annexe 9 : Composantes de Postgis Raster.................................................................................... 67
Annexe 10 : PDI (Pentaho Data Intégration)................................................................................... 67
Annexe 11 : Liste non exhaustive des composantes PDI............................................................. 68
Annexe 12 : l’interface du composant tMap.................................................................................. 68
Annexe 13 : Besoins de la filière Circuits courts............................................................................. 69
Annexe 14 : Besoins de la filière circuits courts.............................................................................. 70
-59Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 1 : Enquête sur les besoins
en données géographiques à la CRARA
Ce questionnaire s’inscrit dans le cadre du projet Master 2 SIG Pro sur la
structuration des données géographiques à la Chambre Régionale d’Agriculture. L’objectif
du projet est de centraliser les données des différents pôles au sein d’une base de données
exhaustive. Celle-ci servira de base de travail pour toute valorisation (études, prospection,
analyse) et notamment dans l’Obsagri Rhône-Alpes.
Le but de cette enquête est de délimiter les besoins en termes de données sémantiques
et géographiques pour alimenter la base de données :
-
Faire un état des lieux des utilisations des données et référentiels dans les différents pôles
de la CRARA (données sémantiques, spatiales, IGN …).
-
Identifier et inventorier les besoins et attentes des acteurs des différentes pôles et filières
(végétale, animale, vin, apiculture, etc.) de la Chambre Régionale d’Agriculture
Les résultats de cette enquête serviront de base pour la conception et la structuration
d’une base de données exhaustive sur l’agriculture en Rhône-alpes.
QUESTIONNAIRE :
-
Nom-Prénom :
-
Pôle :
-
Missions au sein de votre pôle :
-
Avez-vous déjà eu recours à l’utilisation des données géographiques ?
-
Si oui, les quelles ?
 Données sémantiques
 Données spatiales
-
A quelle échelle :
Communale
-
Nationale
Départementale
Régionale
Avez-vous mobilisé facilement et rapidement ces données ? Sinon, quels
étaient les freins ?
-60Structuration d’une base de données sur l’agriculture en Rhône-alpes
-
Pour quel usage (s) ? (décrivez brièvement les cas d’utilisation)
-
Les données que vous utilisez remplissent-elles toutes vos attentes ? Sinon,
pourquoi ?
De quels types d’informations aimeriez-vous disposer (cf. : tableau ci-dessous :
-
recensement, statistiques, inventaires …, Nature (géographique ou non),
usages, Fournisseurs.
Données
Nature de la donnée
.
Usages
.
-
Autres données spécifiques (photos, croquis …)
-
Avez-vous des suggestions sur le mode de gestion et d’organisation des données au
niveau régional ?
Merci pour votre participation
-61Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 2 : Liste non exhaustive des cas d’utilisation
Cas d’utilisation
Acteur principal
Objectif de cas d’utilisation
Acteurs secondaires
Evaluation CDRA /PSADER
Chef projet Territoire
Stagiaire
Suivi des politiques FEADER
Chef projet Territoire
Evaluation du volet agricole
des
contrats
de
développement de Rhône
Alpes
Aides ou actions prioritaires
par secteurs.
Chef projet Territoire
Evaluation MAET
DREAL, CDAO
Cartographie de diversité des
modes d’occupation
Note de suivi Ecophyto
Stagiaire
Chef projet Prospective
DRAAF
Coordination INTER PEP
Chef projet Prospective
Evaluation des MAET
Identifier
les
biologiques.
corridors
Suivre les indicateurs des
plans Ecophyto sur un an
Extraction à travers
informations PEP
des
Stagiaire
Réaliser des fiches techniques
à partir d’un inventaire des
pratiques en pesticides
Chef projet Qualité
Localisation des ruches dans
RA.
Chef projet Qualité
Favoriser la prise de contact
entre un acheteur et un
fournisseur local.
Responsable Qualité
Mobilisation
de
données
géographiques pour la carte
des routes des vins
Veille oenotouristique
Responsable Qualité
Analyser
les
oenotouristiques
Analyser et observer
l’évolution des circuits courts
Responsable Circuits
courts, Diversification
Suivre l’évolution des circuits
courts en RhA
Inventaire des dispositifs
d’expérimentation
Cartographie des ruches
Identifier l’offre locale pour
l’approvisionnement de la
restauration collective
Mise en page
cartographique
du
site
-62Structuration d’une base de données sur l’agriculture en Rhône-alpes
évolutions
Annexe 3
Fiche description d’un cas d’utilisation des données
géographiques et sémantiques
Cas d’utilisation :
1. Identification
Résumé
Type (étude,
diagnostic, etc.)
Acteurs
Fréquence de
réalisation
Responsable
Echelle d’approche
2. Séquencement
Données mobilisées
Pré conditions
Scénario nominal
Résultats
3. Besoins pour
Réalisation :
Valorisation et
diffusion
Remarques
-63Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 4 : Comparatif des outils de la modélisation UML
-64Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 5 : Principe de base des deux modèles UML utilisés
Annexe 6 : Les treize diagramme UML
-65Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 7 : Détails sur le raster géoréferencé
Annexe 8 : Type raster de Postgis Raster
-66Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 9 : Composantes de Postgis Raster
Annexe 10 : PDI (Pentaho Data Intégration)
-67Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 11 : Liste non exhaustive des composantes PDI
Annexe 12 : l’interface du composant tMap
-68Structuration d’une base de données sur l’agriculture en Rhône-alpes
Annexe 13 : Besoins de la filière circuits courts
-69Structuration d’une base de données sur l’agriculture en Rhône-alpes