Mise en place d`un SGBD pour la saisie de données des états

ROLLINGER Romain
Master
Territoire, Patrimoine et Environnement
Spécialité Système d’Information
Géographique et gestion de l’espace
Mise en place d’un SGBD pour la saisie de données des
états des lieux, des diagnostics et des interventions des
éléments des milieux naturels
Maîtres de stage :
Rémy MARTIN, Directeur
Département Système d’Information Géographique
Sylvain WILLIG, Directeur
Département Biodiversité et Gestion des milieux
2011
1
Sommaire
Remerciements ........................................................................................................................... 6
Introduction ................................................................................................................................ 8
I – Le bureau d’étude ASCONIT Consultants ......................................................................... 10
I.1 – L’organisme ................................................................................................................. 10
I.1.1 – La situation............................................................................................................ 10
I.1.2 – Asconit Consultants de manière générale ............................................................. 11
I.2 – Le département D4 de façon plus détaillé .................................................................... 15
I.2.1 – Le savoir-faire du service...................................................................................... 15
I.2.2 – Les missions du service ........................................................................................ 16
I.3 – Présentation du projet de gestion de base de données ................................................. 17
I.3.1 – Le cadre du projet ................................................................................................. 17
I.3.2 – Les attentes du stage et la gestion de projet .......................................................... 18
II – L’outil de saisie, de traitement et de restitution des données terrain ................................. 22
II.1 – Le travail préliminaire ................................................................................................ 22
II.1.1 – La sélection de l’existant ..................................................................................... 23
II.1.2 – Les données à intégrer ......................................................................................... 26
II.1.3 – Choix des outils ................................................................................................... 35
II.1.4 – L’interface graphique de l’outil ........................................................................... 37
II.2 – La phase de conception du nouvel outil ..................................................................... 47
II.2.1 – La méthode MERISE ........................................................................................... 47
II.2.2 – La conception de la base de données ................................................................... 51
2
II.3 – La partie développement............................................................................................. 63
II.3.1 – La création de l’interface graphique : les formulaires ......................................... 63
II.3.2 – La programmation des formulaires de manière générale .................................... 65
II.3.3 – La programmation de codes plus spécifiques sur les formulaires ....................... 74
II.3.4 – La programmation sur les Etats : l’affichage des photographies ......................... 82
III – Les outils de production automatique de cartes ............................................................... 86
III.1 – Les besoins ................................................................................................................ 86
III.1.1 – Le processus de création actuel .......................................................................... 86
III.1.2 – Mon objectif ....................................................................................................... 88
III.2 – La partie développement ........................................................................................... 88
III.2.1 – Choix du langage de programmation ................................................................. 88
III.2.2 – Les outils ............................................................................................................ 89
Conclusion ................................................................................................................................ 92
Lexique ..................................................................................................................................... 94
Références ................................................................................................................................ 96
Table des illustrations............................................................................................................... 98
Annexes .................................................................................................................................. 102
Annexe 1 : Planning de stage ............................................................................................. 103
Annexe 2 : Modèle Conceptuel et Physique de Données ................................................... 104
Annexe 3 : Guide d’utilisation ........................................................................................... 106
Annexe 4 : Guide d’administration .................................................................................... 130
3
4
5
REMERCIEMENTS
Au terme de ce stage, au sein du service D4 du bureau d’études ASCONIT Consultants à
Lyon, je voudrais remercier en premier lieu Rémy MARTIN, Directeur du département
« Système d’Information Géographique » et maître de stage, de m’avoir accueilli dans son
équipe et de la confiance qu’il m’a accordée afin de réaliser mon stage ; activité
professionnelle nécessaire à la validation de mon master professionnel. Ses conseils, sa
disponibilité et l’attention qu’il a su me porter tout au long de ces six mois m’ont permis de
réaliser ce stage dans de très bonnes conditions.
Je tiens également à exprimer ma gratitude à Sylvain WILLIG, Directeur du département
« Biodiversité et Gestion des milieux » ingénieur écologue et SIG, pour avoir suivi l’évolution
de ce projet, dont il est à l’origine, malgré sa localisation (Nancy) et son emploi du temps
chargé, afin de m’orienter dans la marche à suivre.
Pareillement, je souhaiterais remercier Florence BARANGE et Céline THYRIOT, les deux
géomaticiennes du service SIG sur Lyon pour m’avoir aidé dans l’orientation de la conception
de l’outil SIG, même si celui-ci n’a pu être développé.
Je voudrais aussi exprimer ma reconnaissance envers les autres membres du bureau : Sylvie
TORTILLIER, Néna HENDRICK, Cédric BORNUAT et Étienne GUILLOY pour leur
accessibilité et leur bonne humeur.
Plus généralement je remercie toutes les personnes qui ont participé à mon intégration, et qui
ont contribué, de près ou de loin, au bon déroulement de ce stage.
6
7
INTRODUCTION
Ce compte rendu d’activités professionnelles s’inscrit dans le cadre d’un stage étudiant effectué en fin
d’année du Master professionnel « Territoire, Patrimoine, Environnement – Spécialité : Système
d’Information Géographique et gestion de l’espace », dispensé à l’Université Jean Monnet de Saint
Etienne en partenariat avec l’ENISE (École Nationale d’Ingénieurs de Saint Etienne). Le stage, d’une
durée de six mois, fait partie intégrante du deuxième semestre et n’est autre qu’une application de la
formation reçue dans une mise en situation professionnelle. Il a pour but, non seulement
l’approfondissement des connaissances enseignées et l’utilisation des outils informatiques, mais il
permet aussi de nous rendre autonomes et de nous intégrer dans la vie active.
Réalisé au sein du bureau d’études ASCONIT Consultants de Lyon, ce stage a porté sur la
problématique de l’Élaboration d’outils pour la gestion des données des études de milieux naturels.
Bureau d’études indépendant, spécialisé en aménagement du territoire, environnement, gestion des
ressources aquatiques et système d’information, ASCONIT met ses compétences au service de la
gestion durable des ressources et des milieux. Le SIG permet ici de réaliser toute production
cartographique mais aussi des outils métiers pour faciliter et augmenter la productivité. C’est dans ce
cadre que je suis intervenu pendant la durée du stage.
Le contenu du présent compte-rendu d’activités professionnelles est divisé en trois parties.
La première nous présentera la société dans laquelle j’ai évoluée à travers ses origines, sa structure et
ses missions.
La partie centrale de ce rapport est ensuite abordée en trois points. L’un portant sur tout le travail
préliminaire que le projet nécessitait. Un deuxième traitant la phase de conception du stage avec la
refonte et l’amélioration de l’outil de saisie des données terrain et de leur synthèse. Le troisième point
détaille évidemment le processus de développement, qui permet l’automatisation d’un grand nombre
d’opérations pour les utilisateurs.
La troisième partie abordera une partie du stage qui n’a pas pu être concrétisé mais dont la réflexion
avait déjà débuté.
Ce rapport de stage, traitant d’un projet précisément défini, présentera tout au long des différentes
phases abordées : les raisons du travail demandé, les méthodologies appliquées pour la réalisation de
ces différentes étapes, mais aussi les résultats obtenus avec si possible une analyse critique de ces
derniers.
8
9
I – LE BUREAU D’ETUDE ASCONIT CONSULTANTS
I.1 – L’ORGANISME
I.1.1 – LA SITUATION
Mon stage s’est déroulé dans la région Rhône-Alpes, deuxième région de France en superficie
et en population, au siège du bureau d’études ASCONIT Consultants. Bien que le siège soit à
Lyon, cette société a un champ d’action qui s’étend sur tout le pays mais également à
l’international grâce aux agences qui la constituent et à la renommé qu’elle a su acquérir avec
l’expérience des différentes études réalisées.
Figure 1: Carte de situation [Plaquette ASCONIT Consultants –Mieux nous connaître, Décembre 2008]
10
I.1.2 – ASCONIT CONSULTANTS DE MANIERE GENERALE
Créée comme Société par Actions Simplifiées le 8 Juin 2001, ce bureau d’études en
Environnement est spécialisé dans la gestion de la ressource en eaux et milieux aquatiques
(hydrobiologie et hydrogéologie), l’aménagement et le développement durable des territoires
ainsi qu’en systèmes d’information (SGBD, SIG, NTIC [Nouvelles Technologies de
l’Information et de la Communication]) dédiés à ces métiers. Cette société indépendante se
compose de plus de 130 personnes réparties sur 9 sites en France métropolitaine (Lyon, SaintEtienne, Clermont-Ferrand, Nancy, Paris, Nantes, Toulouse, Boulogne-sur-Gesse et
Perpignan) et 6 agences à l’international (Guadeloupe, Martinique, Tunisie, Réunion,
Vietnam et Chine). Au niveau de leurs qualifications, la plupart des employés d’ASCONIT
Consultants sont soit Ingénieurs agronomes, hydrogéologues ou chimistes soit Universitaires
en biologie, écologie, géographie ou économie.
Les agents, suivant leur domaine de compétence, sont répartis dans les 9 départements qui
composent la société :
-
DA/D0 : Département Administratif et Financier
C’est tout naturellement dans cette unité qu’on trouve la comptabilité. Celle-ci régit la
comptabilité générale, celle dédiée aux clients/fournisseurs ainsi que les frais de mission et les
facturations. C’est également dans ce département que sont gérés les aspects financiers des
études d’ASCONIT Consultants, comme les appels d’offres et la gestion des études, la
logistique qui s’occupe de la maintenance, du parc véhicule, de la téléphonie, des
déplacement et de la reprographie. Tout ce qui est du domaine de la qualité est également
traité dans ce service (procédures qualité, gestion de production et sécurité, dossiers
d’accréditation et certification, communication interne et externe).
-
D1 : Aménagement, Environnement et Développement Durable
Il regroupe les personnes compétentes pour résoudre les problématiques liées à
l’aménagement et au développement d’un territoire, tout en intégrant les composantes
environnementales. C’est dans cette sphère que sont réalisés les documents comme le SCOT,
11
l’Agenda 21 ou encore des profils environnementaux pour les clients. Les études d’impacts
des aménagements et des infrastructures ainsi que la prévention des risques, naturels ou
technologiques, font partie intégrante du travail qui est réalisé au sein de cette unité.
-
D2 : Hydrobiologie, Expertise des eaux superficielles
Les études relatives aux rivières, fleuves, canaux, lacs et zones humides sont le quotidien de
ce service, à commencer par les études de la qualité des milieux et habitats (avec
identification et connaissance des préférences écologiques des espèces végétales et animales
présentes). Des prélèvements et mesures in situ de la qualité de l’eau et des sédiments dans le
cadre de réseaux de contrôle, de surveillance et d’observatoires peuvent aussi être effectués.
Travaillant sur les cours d’eau il est logique que ce département s’emploie aussi à déterminer
des débits biologiques minimum, caractériser la qualité des eaux superficielles (par calculs,
interprétations ou diagnostics). Il est à noter que la mise en place d’études d’impacts
d’aménagement ou de dossiers réglementaires portant sur la loi sur l’eau ne leur est pas
inconnue non plus.
-
D3 : Hydrogéologie, Expertise des eaux souterraines
L’attention se porte ici sur la qualité et la quantité de l’eau souterraine sur des zones précises
ou à l’échelle d’un territoire. Elle se traduit par des suivis réguliers de ces eaux (sites
d’alimentation en eau potable, sites potentiellement pollués, réseaux RCS [Réseau de
Contrôle de Surveillance], RCO [Réseau de Contrôles Optionnel] et départementaux) et par
des études diverses nécessaires à la définition des périmètres de protection des captages d’eau
potable et de délimitation des bassins d’alimentation des captages. Le service réalise
également le volet hydrogéologique des études d’impacts.
-
D4 : Système d’Information Géographique
Ce service est un peu atypique dans la société. En effet les collaborateurs de ce département
ont une double compétence : système d’information et métier. Ils ont également la
particularité de travailler en prestation de service interne à ASCONIT Consultants, pour les
12
études gérées par d’autres départements et en externe pour leurs clients sur différentes
thématiques : Cartographie, SIG, Web, Base de données, Informatique générale. C’est dans ce
département que j’ai travaillé durant ces 6 derniers mois sur un outil interne.
-
D5 : Energies, Milieux et Territoires
Avec ses partenaires, ASCONIT Consultants tente de résoudre les problématiques liées aux
énergies via des évaluations de potentiels énergétiques et de territoires, et par des
prescriptions d’aménagement pour le développement de sites de production d’énergie. Le
service accompagne aussi les collectivités locales dans l’aide à la concertation et à la décision
pour le développement des énergies renouvelables. Tout cela passe donc par des études
réglementaires et des études d’impacts sur les milieux et les territoires des installations
énergétiques, sans oublier les études concernant la vulnérabilité aux risques, avant toute
insertion dans leur environnement naturel et humain de réseaux de transport d’énergie
-
D6 : Milieux littoraux et marins
Les études réalisées par ce département, concernent le suivi de la qualité des eaux, la
réalisation de diagnostics environnementaux, l’évaluation d’impacts, tels que ceux des
aménagements littoraux ou encore des rejets en milieu marin (urbains, industriels, eaux de
ruissellement). Ce service intervient aussi dans la restauration des milieux naturels/dégradés
et la gestion intégrée des zones côtières.
-
D7 : International & DOM-TOM
Ce département mobilise une équipe transversale qui représente la société à l’étranger et dans
les DOM-TOM afin de permettre des évaluations de politiques publiques, de programmes et
de projets de coopération. Du fait de sa décentralisation, cette cellule renforce la coopération
internationale pour le développement par l’assistance aux collectivités pour la conception, la
mise en œuvre et l’évaluation de projets, d’évènements ou de mission d’accompagnement.
Cette unité réalise aussi des études socio-économiques et des études de marché
environnementales. Certains agents ayant les compétences techniques des autres
13
départements, D7 peut tout aussi bien participer au suivi-qualité des milieux naturels et mettre
en place des dispositifs d’observation des changements climatiques et des problématiques
énergétiques.
-
D8 : Biodiversité et Gestion des milieux
Récemment créé (courant Février 2011), ce département a été dissocié de D1 et de D2, pour
décharger les services d’une partie de la masse de travail à traiter, au-vu de l’augmentation
importante des activités de ce domaine et pour permettre une meilleure coordination et
lisibilité des domaines concernés au sein de la société. Il a pour vocation la définition
concertée, la mise en œuvre et le suivi de stratégies de protections des espèces, de
préservation, de gestion et de restauration des milieux. Les principales missions qui lui sont
confiées concernent :
-
La prise en compte de la biodiversité dans l’aménagement du territoire,
-
La valorisation et gestion des territoires de manière durable,
-
La communication, sensibilisation et formation au sujet de la biodiversité,
-
Les inventaires et diagnostics écologiques de milieux,
-
Les expertises et inventaires faune/flore/habitats (dossiers réglementaires : études
d’impact, délimitation de zones humides, dossier d’incidence Natura 2000…),
-
Les inventaires de zones humides,
-
Les études préalables et programmes d’actions de restauration/entretien de cours d’eau,
-
Les études globales hydrauliques et environnementales,
-
La maîtrise d’œuvre complète des travaux de restauration écologique,
-
L’évaluation globale de programmes d’actions.
Ces différents départements ne sont pas forcément représentés sur tous les sites de la société
en France métropolitaine. Par contre les membres d’un même département sont pour la
plupart dispatcher dans plusieurs agences.
14
Pour récapituler, ASCONIT Consultants est une société de services indépendante dans le
domaine de l’aménagement du territoire et de l’environnement, avec un intérêt particulier
pour les milieux aquatiques. Les compétences pluridisciplinaires des salariés de ce bureau
d’études (plus de 130 personnes) permettent de réaliser les missions des 9 départements qui
composent l’entreprise.
À l’heure actuelle cette société par actions simplifiée compte un capital de plus de 80 000 €
avec un chiffre d’affaire en 2010 supérieur à 10 000 000 €.
I.2 – LE DEPARTEMENT D4 DE FAÇON PLUS DETAILLE
I.2.1 – LE SAVOIR-FAIRE DU SERVICE
Ce service possède toutes les compétences qu’un Géomaticien peut être amené à utiliser :
-
La cartographie (DAO) est utilisée dans le cadre des cartes de communication, les
plaquettes et les atlas thématiques ou géographiques. La société utilise des logiciels
divers, propriétaires ou libres : Adobe Illustrator, Adobe Photoshop, Mappublisher,
Gimp et Inskscape.
-
Le
SIG
est
utilisé
dans
les
phases
de
conceptualisation,
d’acquisition,
d’administration, de gestion et d’exploitation des données géographiques. Il sert bien
évidemment pour réaliser des analyses spatiales et multicritères, des visualisations en
trois dimensions et de la télédétection. De par la variété du travail et les exigences des
clients, ASCONIT travaille sur un large panel de logiciel SIG : ArcGIS, MapInfo,
Géoconcept, SAGA, GRASS, PostGIS, Idrisi, Envi, Landsef…
-
Le web est lui aussi utilisé pour la conceptualisation, le développement, la gestion et
l’administration de sites web et permet dans un deuxième temps de réaliser des cartes
dynamiques (Webmapping). Pour les mettre en place les agents du service
programment en HTML, XML, PHP, CSS2, SQL et Javascript et peuvent être amenés
15
à exploiter des outils comme Google Maps, Google Earth, OpenLayers, Mapserver,
CartoWeb…
-
En rapport avec les deux thématiques précédentes, le service est aussi compétent en
bases de données, qui sont mises en relation avec des SIG et des sites internet. Elles
sont aussi exploitées pour développer des Systèmes de Gestion de Base de Données
(SGBD), à partir de la méthode MERISE, de type Access, Oracle, PostgreSQL ou
encore MySQL et développer également des Interfaces dans des applications métiers.
-
Les connaissances des langages de développement VisualBasic (Access, Excel,
ArcGIS), Python et Mapbasic en informatique générale permettent, quant à elles, la
gestion du parc informatique du groupe ASCONIT, tout comme le développement de
macros et de scripts pour des outils.
I.2.2 – LES MISSIONS DU SERVICE
Ce département a triple vocation chez ASCONIT Consultants.
Il est tout d’abord un appui technique important dans de nombreuses études pilotées par les
autres départements en assurant toutes les prestations informatiques, notamment
cartographiques. Il réalise ainsi des cartes et des atlas, manipule les données géographiques en
réalisant les phases de numérisation, d’analyse spatiale et multicritères, d’analyse d’images,
de photo-interprétation…) et met en place des bases de données dans les études que peuvent
réaliser les autres départements.
Ce service développe ensuite ses propres activités en France et à l’international sur des
aspects essentiellement techniques en géomatique, mais toujours dans les domaines de
compétence de la société, à savoir l’aménagement, l’environnement et la ressource des
milieux aquatiques : mise en place et gestion d’un SIG, applications métiers, méthodes
d’analyse spatiale, modélisation 3D, formation sur les concepts en géomatique.
Enfin D4 réalise les prestations internes. Elles peuvent porter sur la gestion du parc
informatique, ou, comme c’est le cas dans le cadre de mon stage, sur le développement
d’outils internes, l’élaboration et la mise en œuvre de méthodes de travail et d’analyse
16
apportant certaines solutions. Nous verrons en quoi cela consiste dans le cadre du stage dans
la suite du rapport.
C’est pourquoi le département D4 est composé de salariés aux profils variés mais qui ont tous
une culture informatique ou SIG assez forte, à travers leur formation universitaire ou leur
expérience
dans
le
monde
professionnel.
De
plus,
la
double
compétence
« environnement/SIG » permet à cette équipe d’intervenir à différentes phases sur les études
confiées à la société, comme nous allons le voir à travers les compétences du service dans la
partie précédente (I.2.2 – LES MISSIONS DU SERVICE).
I.3 – PRESENTATION DU PROJET DE GESTION DE BASE DE DONNEES
I.3.1 – LE CADRE DU PROJET
L’objectif du stage était d’améliorer et de formaliser les outils existants, d’automatiser les
opérations de saisie, de traitement et de restitution des données mais aussi de productions
cartographiques sur des études spécifiques à la gestion de milieux naturels : cours d’eau,
espaces naturels. La vocation de ces outils à améliorer est de permettre l’élaboration de l’état
des lieux, du diagnostic et du programme d’actions des différents types de milieux en tenant
compte de leurs spécificités propres.
Pour réaliser ce projet, un travail en binôme avec une stagiaire écologue devait être fait au
départ :
-
Elle, menant une réflexion méthodologique au niveau thématique : données sur
lesquelles l’outil serait développé (bilan-synthèse des méthodes de diagnostics).
-
Moi, adaptant cette méthodologie sous un angle technique : solutions permises par les
outils et les logiciels adaptés, tout en tenant compte de certaines contraintes imposées.
Or Dans le cadre de mon travail, je ne commençais pas à partir de rien puisque des outils
internes existaient déjà. Ceux-ci, permettaient une base de réflexion sur les fonctionnalités à
17
renouveler, celles à améliorer et celles à mettre en place, avant une conceptualisation et un
développement de l’outil d’automatisation des procédures de traitements/restitution à créer.
I.3.2 – LES ATTENTES DU STAGE ET LA GESTION DE PROJET
Dès mon arrivée dans les locaux d’ASCONIT Consultants, une réunion a été organisée pour
préciser les attentes du stage que j’allais effectuer sur la mise en place d’outils, axé sur le
thème de la restauration de cours d’eau. Il en est ressorti que le stage se divisait en deux
parties.
-
L’une consacrée à la construction d’un outil de saisie automatique de certaines
informations récurrentes sur des entités géographiques, permettant par la suite, leur
traitement et leur restitution.
-
Une deuxième partie dédiée à la mise en place de fonctionnalités permettant la
production automatique de cartes faisant apparaître les informations levées sur le
terrain grâce à l’outil précédent.
Le premier volet du stage, grâce à une base de données, devait être une description exhaustive
des données relevées, toutes relatives aux éléments de cours d’eau. Pour une meilleure
analyse de ces informations, les cours d’eau qui font l’objet d’une restauration sont segmentés
en tronçons, eux-mêmes divisés en secteurs. Ces derniers sont déterminés en fonction de
l’homogénéité des paramètres qui caractérise le linéaire du cours d’eau. C’est pourquoi, de
manière générale, les données sont levées à l’échelle du secteur.
18
Sur le fond, l’outil à réaliser, devait se baser sur les modèles existants, adaptés pour les cours
d’eau, et être optimisé pour des entités liées au terrestre, à l’image des zones humides.
Toutefois, seuls les critères récurrents pour Asconit seraient repris dans un premier temps,
sous réserve de validation par Sylvain WILLIG, directeur du département D8 Biodiversité et
Gestion des milieux.
Dans la forme, il fallait que ce soit un formulaire dans lequel les informations seraient
renseignées à travers de la saisie, à limiter au maximum, et des menus déroulants qui
proposeraient un certain nombre de choix suivant le paramètre. Tout devait être mis en place
pour faciliter la saisie des informations sur le terrain pour les utilisateurs. Concernant les
résultats statistiques des données enregistrées lors de la prospection, il fallait mettre en place
une interface permettant de réaliser les requêtes appropriées.
Au niveau des plateformes logicielles, Asconit semblait privilégier Access de Microsoft
Office, car le bureau d’étude possède plusieurs licences du logiciel, mais restait ouvert à des
solutions plutôt Open Source.
Le deuxième volet du stage devait porter sur un développement du logiciel ArcGIS pour
permettre d’automatiser l’atlas cartographique à l’échelle du 1/10 000 ème et les vignettes
(mini-cartes synthétiques de description à l’échelle du bassin versant), tous deux produit à
partir des informations levées en prospection. Seules les couches SIG des cours d’eau et des
bassins versants sont fournies au Géomaticien pour réaliser les cartes demandées. Les autres
couches devraient être créées et associées aux tables homologues dans la base de données.
19
Dès le début du projet, un planning a été mis au point pour le bon déroulement de ce dernier
afin que les différentes parties du stage puissent être abordées et mises au point. Cela
permettait de situer l’avancement du planning par rapport à ce qui avait été prévu.
Malheureusement, quelques aléas sont survenus tout au long du projet menant à un glissement
du planning (problèmes de communication, temps de réponse et de validation, difficultés
techniques rencontrées...). Le retard accumulé rendait la programmation trop juste, il a été
décidé mi-juillet de mettre l’accent sur le SGBD, soit le premier volet du stage, de manière à
être totalement opérationnel à la fin du stage.
Figure 2: Planning de stage
(Annexe 1 : Planning de stage)
20
21
II – L’OUTIL DE SAISIE, DE TRAITEMENT ET DE RESTITUTION
DES DONNEES TERRAIN
II.1 – LE TRAVAIL PRELIMINAIRE
La vocation de cet outil est de permettre l’élaboration de l’état des lieux, du diagnostic et du
programme d’action des différents types de milieux en tenant compte de leurs spécificités
propres.
Or, plusieurs outils ont déjà été développés dans cette optique par ou pour les personnes allant
sur le terrain afin d’optimiser le recueil d’informations en un minimum de temps possible,
dans un souci d’efficacité et de productivité. Il n’y avait donc pas d’outil unique, mais
plusieurs outils similaires. En raison d’une masse de travail importante dans les agences, ces
dernières n’ont pas pu prendre le temps de se pencher sur le développement d’un outil unique
qui répondrait aux attentes des différents utilisateurs à travers les neufs agences en France
métropolitaines. C’est pourquoi le bureau d’étude se retrouvait avec plusieurs Systèmes de
Gestion de Base de Données (SGBD), créés souvent dans l’urgence pour satisfaire un projet
particulier. Bien que fonctionnels, ces outils n’étaient pas « bien architecturés » (d’un point de
vue base de données), ce qui ne facilitait pas toujours les traitements qui s’en suivaient, dont
fait partie la production cartographique, traitée en troisième partie de ce rapport.
C’est pourquoi dans le cadre de mon stage, il m’a été demandé d’analyser les outils existants
(structures de la base et données utilisées) pour en réaliser un nouveau, mieux construit, qui
réponde aux attentes de chacun et qui faciliterait plus encore la saisie des données terrain et
leur synthèse, mais aussi la production cartographique qui en découle, pour les cartes
redondantes. L’objectif de ce remodelage est donc d’être plus efficace et productif, mais aussi
d’améliorer la qualité des rendus par l’intégration des attentes d’un maximum d’opérateurs au
niveau national. Cette homogénéisation devrait également favoriser le retour et le partage
d’expériences entre différents chargés d’études et chefs de projet impliqués.
22
II.1.1 – LA SELECTION DE L’EXISTANT
Comme nous venons de le voir en introduction de cette partie, plusieurs bases de données
existent au sein de cette société. Certaines datent des débuts d’ASCONIT tandis que d’autres
n’ont que quelques mois avant ma venue, ce qui représente au total 8 ans de bases de données.
C’est pourquoi deux tris ont été effectués afin de ne garder que les plus pertinentes :
-
Un premier tri a été effectué par Sylvain WILLIG (Directeur du Département
Biodiversité et Gestion des milieux) pour ne garder que les bases traitant les cours
d’eau. Ces bases de données restantes devaient me permettre de me faire une idée des
informations essentielles, dominantes à prendre en compte dans l’outil qu’il me fallait
créer et de la manière dont elles devaient être saisies.
-
Le deuxième tri, celui-ci réalisé par Rémy MARTIN (Directeur du Département
Système d’Information Géographique), portait sur des outils présentant une certaine
structuration entre les différentes données et qui s’appuyaient toutes sur la méthode
MERISE, une des méthodes de conception de base de données. Cette deuxième
sélection devait me servir de base pour la conception du nouvel outil une fois les
données à prendre en compte validées.
Un premier constat peut alors être fait : toutes les bases de données ont été produites sous
Microsoft Office Access 2003 ou 2007. On peut donc penser que les personnes ayant
développées ces applications connaissent les langages de programmation associés et seraient
capables de mettre à jour le futur outil s’il devait être développé avec le logiciel Microsoft
Office Access.
Ensuite, en ouvrant ces bases de données, on peut observer les relations qui existent entre les
tables en cliquant sur la commande Relations de l’onglet Outils de base de données. Cela
nous permet d’avoir un aperçu des données et de savoir comment elles ont étés structurées
entre elles. Les bases de données résultant du premier tri mettent en valeur une table Secteur
ou Tronçon sur laquelle s’articulent différentes entités, dont certaines qui reviennent sur la
majorité des modèles : lit mineur, lit majeur, berge, ripisylve et ouvrage. Il faut donc
comprendre ici que ces entités caractérisent les secteurs, comme on peut le constater sur la
figure suivante.
23
Figure 3: Exemple de données et de leurs relations à travers trois bases de données existantes [ASCONIT]
24
Pour bien comprendre l’interaction qu’il y a entre les tables, il faut expliquer les différentes
échelles d’une étude sur les milieux aquatiques. Il faut savoir qu’une étude porte souvent sur
un bassin versant (BV). Ce dernier comprend plusieurs cours d’eau (CE). Or ces cours d’eau
sont caractérisés par une multitude de facteurs multicritères comme le lit mineur, le lit majeur,
les berges et les ripisylves sur chacune des rives du cours d’eau. Il se trouve que les cours
d’eau ne sont pas homogènes sur l’ensemble de leur linéaire, c’est pourquoi ils sont découpés
en tronçons, suivant des zones hydrauliques de la BD CARTHAGE, puis divisés en secteur
sur le terrain, en fonction du gabarit ou relativement à la localisation d’un ouvrage. Secteurs et
Tronçon peuvent toutefois être confondus dans certaines méthodologies.
Figure 4: Schéma de rivière type [site internet de la campagne "La Rivière m’a dit…"]
C’est pourquoi dans toutes les bases de données fournies par Sylvain WILLIG, les tables
représentant les différentes entités s’articulent autour de la table Secteur, ou Tronçon lorsque
celle-ci n’existe pas.
25
II.1.2 – LES DONNEES A INTEGRER
II.1.2.A – ANALYSE DES DONNEES EXISTANTES
Mais pour savoir quels facteurs devaient être intégrés dans la future base de données, il me
fallait dans un premier temps analyser et inventorier les données existantes du premier tri.
Ce premier travail, bien que long et fastidieux, m’a permis de me familiariser avec les
informations que doivent lever les chargés d’études sur le terrain. En effet, le seul parcours
des bases de données fournies, permet de faire ressortir les informations les plus importantes
dans la mesure où elles sont présentes sur toutes ou une majorité des bases de données
sélectionnées par Sylvain WILLIG., comme on peut aussi le constater au travers de la Figure
3. Pour avoir une idée des tables pertinentes, de celles qui pourraient le devenir et de celles à
ajouter dans la future base de données, je devais répertorier les données de chacune de ces
bases existantes, les analyser et réaliser des comparatifs avec les données équivalentes des
autres bases de données.
C’est pourquoi, j’ai réalisé dans un premier temps un dictionnaire des données pour reporter
l’intégralité des champs présents dans les trois bases analysées. Tous les champs de chacune
des tables des différentes bases ont été saisis sur un fichier Excel en prenant soin de préciser :
-
Le nom exact du champ, qui est le plus souvent explicite sur la nature de la donnée
qu’il caractérise. Exemple : le nom d’un champ LARGRIP pour définir le paramètre
relatif à la largeur de la ripisylve.
-
La description du champ, au cas où le nom du champ ne serait pas clair sur la nature
des données enregistrées, et pour permettre une comparaison postérieure de champs
similaires issus des autres bases de données.
-
Le type de donnée à renseigner. Cela permet de savoir s’il s’agit d’un champ de type
Texte, Numérique, NuméroAuto, de type Date/Heure, Oui/Non (case à cocher) ou
autre…
-
La longueur / Le format du champ, qui permet d’apporter une précision au type de
donnée en nous donnant une information sur la taille du champ. Cette colonne du
dictionnaire de données nous renseigne donc sur le nombre de caractères autorisés
26
pour le champ lorsqu’il s’agit d’un champ de type Texte, ou sur le format du champ
Numérique (entier, réel ou décimal).
-
La nature du champ, à savoir s’il s’agit d’une donnée élémentaire, issue d’un calcul
ou bien encore d’un traitement SIG
-
La liste de choix associée au champ, lorsque celle-ci existe. Auquel cas, on en déduit
que le champ se traduit dans les formulaires, ou les feuilles de données, par des listes
déroulantes. Ce renseignement nous permet de nous faire une idée des informations
qui sont attendues lors de la saisie sur le terrain.
-
Le nom exact de la table dont est issu le champ, de manière à pouvoir authentifier le
champ lors de la comparaison avec ses pairs.
-
Le nom exact de la base dont est tiré le champ, de manière à pouvoir authentifier le
champ lors de la comparaison avec ses pairs.
Figure 5: Extrait du dictionnaire de données créé
27
Pas moins de 1106 champs (à travers les trois bases de données étudiées) ont été inscrits dans
le dictionnaire des données existantes. Ce travail, bien que fastidieux, était nécessaire pour
plusieurs raisons.
D’une part il me permettait de me faire une idée plus précise encore des paramètres que les
chargés d’études ont à lever de manière régulière ou systématique lors des prospections et
ainsi de me familiariser avec eux. Le fait de les reporter autant de fois qu’ils apparaissaient
dans les bases me donnait la possibilité d’évaluer grossièrement leur importance suivant la
redondance de leur report dans le fichier Excel.
D’autre part, du fait du nombre important de données, l’établissement de ce registre offrait de
nouvelles possibilités. Excel permet notamment de faire des calculs lorsqu’il s’agit
d’information numérique, mais le logiciel peut aussi réaliser des opérations de tri et de filtrage
en fonction de certains paramètres. Ce sont ces traitements qui nous intéressaient
particulièrement pour établir un document synthétique des paramètres existants à reconduire
dans l’outil à mettre en place suivant leur importance (présence du paramètre dans les
différentes bases) et de leur pertinence.
Ces traitements sont rendues possibles grâce à la fonction Trier (Onglet Accueil / Edition /
Trier et Filtrer) qui fait apparaître en coin de chaque entête de colonne la flèche
caractéristique d’un menu déroulant, permettant ainsi de réaliser des filtres textuels, en
l’occurrence les filtres textuels Est égal à… et Contient…
28
Figure 6: Filtres textuels dans Microsoft Office Excel 2007
À partir de là, on peut alors comparer des champs de même description contenus dans
différentes tables, d’une même base ou d’une autre.
Figure 7: Résultat du filtre textuel visible en Figure 4
Il est alors facile de savoir si les champs répertoriés sont présents dans la plupart des bases de
données, si les informations sont représentées de la même manière (saisie ou liste de choix,
champ numérique ou texte, appartenance à une table analogue dans les autres bases etc…) et
établir un fichier de synthèse des informations. Comme le mot d’ordre était de limiter au
maximum la saisie dans l’outil à créer, les paramètres représentés différemment suivant les
bases ont été synthétisés à partir de ceux munis d’une liste de choix.
29
La synthèse s’est faite dans une nouvelle feuille de données à partir de plusieurs constituants :
-
La description du champ, afin d’identifier le paramètre.
-
La liste de choix associé au champ, lorsque celle-ci existe.
-
Le nombre de bases dans lesquelles le champ est présent, de manière à pouvoir
hiérarchiser le champ et définir ainsi…
-
La pertinence du champ à entrer dans la future base de données d’après mon
appréciation.
-
L’entité du cours d’eau que le champ concerne (secteur, lit mineur, berge…)
Figure 8: Fichier de synthèse des informations contenues dans le dictionnaire des données existantes
Grâce à ce travail, il en est ressorti une première sélection de critères, soit près d’une centaine
de champs qui a fait l’objet d’une première validation. En effet, les bases ont présenté un
grand nombre de données, cependant, il ne fallait pas oublier que l’outil devait permettre la
lever d’informations qu’il fallait ensuite cartographier. C’est pourquoi après ce premier
calibrage, ce fut au tour des données représentées sur des atlas cartographiques type de l’état
des lieux, des diagnostics et des actions de faire l’objet d’une validation afin d’être intégrées.
Toutefois le travail fut beaucoup moins pénible du fait que la plupart des informations
symbolisées sont issues des bases de données et ont déjà été examinées.
30
Au final, plus d’une centaine de paramètres à lever ont été retenu caractérisant plus d’une
dizaine d’entités réparties en deux catégories :
-
les entités linéaires, éléments d’un secteur de cours d’eau : lit mineur, lit majeur,
berge, ripisylve et action,
-
les autres entités, ponctuelles et zonales : ouvrage, encombre, déchet, rejet, pompage,
zone humide et action.
Parallèlement, une stagiaire écologue devait s’entretenir avec les utilisateurs de l’outil et
définir les paramètres relatifs aux éléments d’un secteur à lever sur le terrain en croisant les
différentes méthodologies plus ou moins standardisées de différents opérateurs publics
(Agence de l’Eau, ONEMA…) et les besoins particuliers d’un maximum d’opérateurs
d’ASCONIT. Ainsi nos sélections respectives concernant les éléments de cours d’eau (lit
mineur, lit majeur, berge et ripisylve) ont pu être confrontées afin d’en ressortir une
méthodologie pour lever les différents paramètres de ces entités linéaires. Les entités
associées n’ayant pas été abordées par la stagiaire écologue, j’ai du à m’entretenir directement
avec les utilisateurs pour connaître leurs besoins sur ces données.
II.1.2.B – ENTRETIENS AVEC LES UTILISATEURS DE L’OUTIL
Ayant tiré le maximum d’informations des bases existantes, je devais ensuite m’entretenir
avec les utilisateurs de l’outil de toutes les agences métropolitaines d’ASCONIT suivant leurs
disponibilités. Ces entrevues avaient plusieurs objectifs :
Le premier était de parcourir ensemble les paramètres validés précédemment afin de faire le
point. Cette étape était importante car elle permettait aux utilisateurs de me faire part de leurs
remarques sur les données déjà répertoriées, mais aussi d’ajouter d’autres paramètres
nécessaires à leurs études qui n’avaient jamais été pris en compte, ou de façon mal adaptée à
leurs besoins.
La deuxième finalité de ces entretiens portait sur l’outil à proprement parler. Les discussions
traitaient ici de l’interface graphique que devrait arborer le programme ainsi que de son
31
fonctionnement, suivant les expériences des utilisateurs sur les outils précédents. Ce deuxième
point sera repris dans la partie suivante.
Pour en revenir au premier objectif, concernant la validation des données, tous les utilisateurs
sont tombés d’accord pour dire que les paramètres des entités du secteur avaient bien tous été
pris en compte.
Par contre ce n’était pas le cas de toutes les entités ponctuelles et zonales qui avaient été
retenues.
Il existait différentes manières de lever ces entités dans les outils existants. Certaines bases
n’avaient qu’une table générique pour lever les divers objets ponctuels et zonaux alors que
d’autres avaient une table par entité avec des champs différents pour chaque objet. Les
utilisateurs eux aussi étaient partagés sur l’acquisition de ces données. Une partie des
utilisateurs préférait le levé d’entités via la table générique, plus pratique pour lever un grand
nombre d’éléments, tandis que l’autre optait pour une approche par entité, permettant un levé
plus spécifique et détaillé de l’objet. Or l’outil se devait de posséder le plus d’informations à
lever possible, c’est pourquoi le levé par entité fut validé en distinguant : les travaux
hydrauliques, les encombres, les rejets, les déchets, les piétinements, les pompages, les buses,
les plans d’eau et les zones humides, en plus des ouvrages.
Cette table, un peu particulière car importante, a toujours été une table à part entière. Bien
qu’elle ait évolué pour s’adapter aux besoins de chacun à travers le temps, elle suscitait
encore beaucoup d’intérêt de la part des utilisateurs qui souhaitaient la perfectionner toujours
plus. Déjà bien complète, voire même trop pour certains utilisateurs qui ne renseignaient pas
cette entité à ce niveau de détail, elle restait imparfaite. Après avoir entendu tous les
utilisateurs et avoir débattu sur les changements et les ajouts des données à effectuer, les
modifications à apporter ont été prises en compte.
Certains renseignements ont également été totalement repensés pour éviter au maximum aux
utilisateurs d’enregistrer des valeurs à partir de listes déroulantes jugées trop suggestives.
32
Suite à cela un dictionnaire des données du nouvel outil a été mis en place afin de valider les
informations à exploiter, bien qu’il doive être amené à évoluer avec la programmation,
suivant les difficultés.
Figure 9: Extrait du dictionnaire de données de l'outil mis en place
33
Remarques :
À l’image de la Figure 7, on observe que la plupart des champs des différentes tables ont un
champ homologue dans une table de listing. À première vue, on pourrait penser à une
duplication des données, cependant il n’en est rien. En effet, en étudiant les bases qui
possèdent une table « listing », on observe que ces dernières possèdent des champs
équivalents aux champs de type « liste déroulante » des autres tables de la base. Cela
s’explique par le fait que les listes déroulantes des champs des diverses tables de la base font
appel aux valeurs contenues dans leur champ homologue des enregistrements de la table
« listing » via une requête. Ainsi l’ajout d’une nouvelle valeur dans un champ de la table
« listing » permet de mettre à jour de manière automatique toutes les listes déroulantes des
champs des autres tables qui lui sont associés. Ces explications sont étayées par la figure
suivante et permettent une meilleure compréhension.
Figure 10: Lien existant entre le champ d'une table et son homologue dans une table de listes
34
II.1.3 – CHOIX DES OUTILS
II.1.3.A – L’OUTIL DE DEVELOPPEMENT
Après avoir passé du temps à tester différents outils libres de SGBD (Système de Gestion de
Base de Données) et le logiciel propriétaire Access 2007 de Microsoft Office, nous nous
sommes orientés sur un développement de l’outil sur le logiciel de Microsoft pour plusieurs
raisons.
Tout d’abord ASCONIT Consultants possède un certain nombre de licences de ce programme
en version 2003 et 2007. Le développement de la base sur ce support permettrait de
rentabiliser leur achat. D’autant plus que la société bénéficie de toute l’assistance dont elle
peut avoir besoin pour construire des bases de données sur ce produit, au sein de son
Département D4 notamment.
Ensuite, Access ne trouve pas vraiment d’équivalence dans le domaine des logiciels libres.
Bien que le logiciel Base d’Open Office s’en rapproche fortement pour ce qui est de la base
de données, il ne permet pas encore de configurer des liens complexes entre les tables ou de
construire des interfaces utilisateurs de type formulaire continu, comme utilisé dans notre
projet. Il en va de même pour les SGBD MySQL et PostGreSQL : ces outils Open Source
sont très populaires pour l’aspect base de données, mais ils n’offrent pas les mêmes
vérifications de données ou de requêtes qu’offre Access, ni d’interface utilisateur, ce qui
nécessite d’en créer une via un autre outil libre, à l’image de GAMBAS ou via une
programmation PHP par exemple.
Toutefois, il existe des logiciels libres tels que Kexi Project ou Glom qui allient les
fonctionnalités base de données à des fonctionnalités d’interface utilisateur. Mais que ce soit
d’un côté ou de l’autre aucun de ces outils n’offre un environnement de SGBD aussi complet
que celui d’Access, qui plus est en relation directe avec une interface utilisateur aussi aisément
développable, grâce à une programmation facile et rapide sous Access et/ou Visual Basic for
Applications.
De plus, une partie des utilisateurs ont appris au fil des années à programmer dans ces
langages pour améliorer leur outil de saisie de manière à répondre à leurs besoins.
Programmer le nouvel outil sous Access et Visual Basic for Applications permettrait après
35
mon départ de mettre à jour plus facilement la base si les utilisateurs et administrateurs
connaissent déjà le logiciel de création.
N’oublions pas non plus que la base de données est censée être reliée ensuite au SIG pour
réaliser les atlas cartographiques. Or ce lien se fait très simplement et sans aucun problème de
compatibilité (ouverture des tables en mode natif sous ArcGIS notamment).
Mais l’une des raisons principales qui a motivé le choix de ce logiciel est la suivante. L’outil
pourrait être amené à être externalisé pour les clients des études sur lesquelles le programme
sera utilisé. En effet les clients possèdent tous une suite bureautique, pour la plupart Microsoft
Office. Il est donc plus facile de fournir un produit que le client pourra utiliser directement. En
plus, pour ceux qui n’auraient pas Microsoft Office Access, la compilation de l’outil, incluant
un runtime (gratuit) leur donnerait la possibilité d’utiliser l’outil s’ils le souhaitent sans avoir
à acheter le logiciel ou à installer un autre programme pour faire fonctionner l’outil fourni.
II.1.3.B – L’OUTIL DE CONCEPTION
Toutefois avant de pouvoir développer l’outil demandé sous Microsoft Office Access 2007, il
faut d’abord concevoir la base de données sur laquelle il sera construit.
Afin de mettre en place les éléments qui la caractérisent, j’ai choisi d’utiliser l’outil Open
Source DBDesigner. Ce logiciel a l’avantage de permettre une conception visuelle des bases
de données, ce qui le rend plus intuitif. Avec ce programme, il est possible de réaliser
directement un Modèle Conceptuel de Données (MCD) pour décrire sous forme schématique
les données à traiter (soit les différentes entités avec leurs paramètres ainsi que les relations
qui peuvent exister entre elles). Le MPD peut lui aussi être créé instantanément si le système
de stockage de chaque paramètre a été renseigné.
De plus DBDesigner possède un module de script qui lui permet de traduire en langage SQL
différents éléments de la base créée dans le logiciel. Le fichier obtenu liste les différentes
tables, leurs champs, le type de données (texte, numérique…) avec le nombre de caractères
maximal autorisés ainsi que les clés (primaires et étrangère de chaque table), sans oublier les
cardinalité. L’importation de ce fichier dans Access permet une création immédiate des
données créées sous DBDesigner, argument de taille qui a favorisé la sélection de cet outil.
36
II.1.4 – L’INTERFACE GRAPHIQUE DE L’OUTIL
II.1.4.A – ENTRETIENS AVEC LES UTILISATEURS DE L’OUTIL
Pour ce qui concerne l’interface graphique, plusieurs modèles existaient pour la saisie des
informations :
-
des modes de saisie sur un unique formulaire, regroupant l’ensemble des informations
à lever ; classées par entité avec un code couleur (bleu pour le lit mineur, vert pour la
ripisylve…). Cette méthode avait l’avantage pour l’utilisateur de pouvoir saisir tous
les paramètres les uns à la suite des autres. Cependant, étant donné la quantité
importante d’éléments à saisir, des barres de défilements horizontales ou/et verticales
(couramment appelées scrolls) apparaissent sur le formulaire pour accéder à ceux qui
ne seraient pas visibles à l’écran du fait de la taille imposante du formulaire. Les
informations étant rentrées sur le terrain, les utilisateurs sont obligés d’utiliser le pad
de leur laptop (ordinateur portable) pour accéder aux scrolls, ce qui restreint l’intérêt
pratique du formulaire unique.
Figure 11: Mode de saisie sur formulaire unique
37
-
des modes de saisies basés sur un système d’onglets, où chaque onglet représente une
entité qu’il faut caractériser. Cette solution permet de corriger le désagrément des
scrolls dans la méthode de levé précédente. Le fait de limiter les données à une entité
par onglet permet de visualiser l’ensemble des critères la caractérisant sur une même
page, visible en intégralité sur les écrans, y compris ceux des ordinateurs portables les
plus petits utilisés pour des levés terrain. Bien que cette approche apporte une
meilleure visibilité des données, elle est aussi la source d’un défaut jugé majeur par les
utilisateurs. En effet lors d’une saisie sur le terrain, les opérateurs n’ont pas de souris
pour passer facilement d’un onglet à l’autre et pointer le curseur sur le premier
paramètre à lever ce qui entraîne une gêne pour la saisie et une perte de
temps/productivité.
Figure 12: Mode de saisie sur formulaire à onglets
C’est pourquoi il fallait trouver une interface graphique pour la saisie qui permettrait de
concilier les avantages de ces méthodes (facilité de la saisie, vue d’ensemble des différents
critères) tout en bannissant leurs aspects négatifs (barres de défilement, utilisation forcée du
pad).
38
Néanmoins, l’outil ne se constitue pas uniquement de la partie saisie. Les utilisateurs ont aussi
besoin de pouvoir modifier (écriture et lecture) et consulter (lecture seule) des données
déterminées. Par conséquent un questionnaire a été mis en place pour interroger séparément
chaque utilisateur de l’outil sur ses besoins (qu’est-ce que l’outil doit-il lui permettre de
réaliser ?) et ses préférences (comment peut-il le réaliser ?), tout en tenant compte de l’aspect
facile et pratique des différentes manipulations que l’utilisateur aura à effectuer.
Figure 13: Questionnaire définissant les besoins utilisateurs
Suite à cette dizaine d’entretiens d’une durée moyenne de 45 minutes, il est ressorti les
résultats suivant :
Description du terrain
-
Les opérateurs ne font aucun pré-traitement avant de partir pour la prospection si ce
n’est parfois le découpage des tronçons du cours d’eau sur des fonds de carte papier.
-
Les points levés au GPS correspondent aux entités ponctuelles et zonales. À chaque
point levé correspondent une à deux photos suivant l’importance de l’objet.
39
-
La saisie multi-utilisateur n’a jusqu’à présent été utilisée que par deux chargés
d’études et ne semble pas intéresser les autres dans la mesure où chaque opérateur a
son étude. La prospection des informations sur le terrain étant faite le plus souvent par
un seul binôme par étude, composé du chargé d’affaire et d’un stagiaire.
-
Seuls les calculs de synthèse sont réalisés par les utilisateurs, et souvent pour partie via
Microsoft Office Excel et non directement dans Microsoft Office Access. Les autres
opérations de post-traitement, liées à la cartographie, sont réalisées soit par les
opérateurs eux-mêmes, soit par le Département SIG d’ASCONIT (D4).
L’interface de l’outil
-
Sur certains outils, l’interface générale se divisait en quatre modules :
o un module permettant d’accéder à un formulaire de saisie vierge, pour
enregistrer les données d’un nouvel objet (secteur, ouvrage ou autre).
o un module permettant d’accéder à un formulaire pour modifier des
informations relatives à des objets déjà saisis préalablement.
o Un module permettant de consulter/d’imprimer ces données.
o Un module d’exportation des données vers un fichier Microsoft Office Excel,
variable d’une base de données à l’autre permettant de réaliser des requêtes
statistiques, requêtes de synthèse, à différentes échelles de l’étude.
-
Sur d’autres, l’interface ne possède pas tous les modules ou les possède mais pas sur
tous les objets.
-
Pour les derniers, cette interface est inexistante. Les utilisateurs n’ont qu’un formulaire
de saisie qui leur permet d’enregistrer les différentes informations des paramètres
rencontrés, les opérations de post-traitement étant exécutées directement à partir du
menu de navigation des objets Access. Ces outils sont ceux des utilisateurs qui
possèdent au moins les bases de Microsoft Office Access. Ce sont d’ailleurs ces mêmes
utilisateurs qui ont amélioré leurs outils de base au fur et à mesure de leurs besoins.
L’outil devant être le plus complet possible, il se devait de permettre l’exécution de ces
différentes fonctionnalités.
40
Le futur formulaire de saisie
-
Présentation du formulaire de saisie sous la forme d’un formulaire par onglets, où
chaque page représente un objet. Afin de faciliter la saisie des informations sur les
mini-PC de terrain, des raccourcis claviers ont été suggérés pour passer d’un onglet à
l’autre, amélioration inédite par rapport aux versions précédentes.
-
Pour les entités Lit majeur, Berge et Ripisylve, les informations de rive, en rive gauche
et en rive droite, doivent être saisies, l’une après l’autre, paramètre par paramètre.
-
La touche tabulation doit permettre de passer du paramètre saisi au paramètre suivant.
En d’autres termes la tabulation doit être organisée pour passer d’un champ à un autre
dans le bon ordre, en priorité pour chacune des rives pour un même paramètre.
-
Certaines informations ne doivent être saisies qu’une fois, puis automatiser dans les
autres champs où cette information est nécessaire. Le choix de certaines valeurs dans
les listes déroulantes de paramètres doit ainsi entraîner des valeurs par défaut bien
précises dans d’autres paramètres spécifiques.
II.1.4.B – PROPOSITION D’ASPECTS GRAPHIQUES DE L’OUTIL
Pour savoir si je répondrais graphiquement aux attentes des utilisateurs de l’outil, je devais
leur présenter ce que je comptais mettre en place pour l’aspect visuel, au moins
conceptuellement, à propos de l’interface, mais surtout du formulaire de saisie. Pour ce faire,
j’ai utilisé le logiciel Microsoft Expression Blend 3, dans sa version d’évaluation d’un mois.
J’ai utilisé ce logiciel car il me permettait de réaliser rapidement un prototype de l’outil tel
que je le voyais. En effet à partir de ce programme je pouvais exposer aux usagers mes idées
de conceptions de l’outil avec ses fonctionnalités, tout en tenant compte de la résolution des
mini-PC (7 et 9 pouces) et leur montrer quel rendu cela donnerait en cas d’utilisation de
l’outil lors d’un levé de terrain.
Plusieurs versions de l’outil ont été proposées. Même si les interfaces permettant d’accéder
aux différentes fonctions présentaient la même forme dans les différentes versions, la
différence se faisait surtout au niveau du formulaire de saisie.
41
Figure 14: Interface générale et modules qui en découlent
Pour être plus précis, les onglets Lit mineur, Lit majeur et Berge étaient identiques d’une
version à l’autre. Les consignes de levé de ces entités étaient très précises, je savais donc
exactement comment les représenter.
Figure 15: Formulaire de saisie (onglet Lit majeur)
42
La saisie de ces éléments ne varie pas car il n’y a qu’un objet par secteur. De ce fait un
formulaire unique pour les entités citées semblait être la solution la plus adaptée avec, pour
chaque paramètre, l’information à renseigner en rive gauche, puis l’information en rive droite.
L’onglet Ripisylve, quant à lui, serait également entré dans cette catégorie, mais il a une
particularité. En effet, il existe deux méthodes pour lever les informations exigées.
-
Dans le premier cas, la ripisylve est unique sur chacune des rives d’un secteur du
cours d’eau, à la manière des entités Lit majeur et Berge, comme nous l’avons vu à
l’instant. Cette méthode de saisie est utilisée par la plupart des agents.
-
Dans le deuxième cas, la ripisylve n’est pas singulière. Certains utilisateurs peuvent
lever plusieurs « sous-secteur » de ripisylves en rive gauche et en rive droite pour un
même secteur. C’est le cas des chargés d’étude des agences de Nantes et Toulouse.
Il a donc fallu proposer une solution pour permettre à chaque usager d’utiliser la méthode qui
lui convient. Celle qui fut soumise au département D8 reprend le principe de saisie des autres
entités caractéristiques d’un secteur : il s’agit de permettre la saisie de deux ripisylves sur un
même formulaire unique, en ajoutant une barre de navigation. Ainsi les utilisateurs de la
première méthode peuvent remplir leur ripisylve unique sur la rive gauche et sur la rive droite,
et les partisans de la deuxième méthode peuvent, grâce à la barre de navigation, accéder à une
nouvelle page pour renseigner de nouvelles ripisylves.
Figure 16: Formulaire de saisie (onglet Ripisylve)
43
Pour les entités ponctuelles et zonales, elles peuvent apparaître de nombreuses fois sur un
secteur. Il fallait donc mettre en place une interface visuelle qui permette de lever ces entités
tout en pouvant voir les autres éléments de même nature levés antérieurement. Plusieurs
solutions ont donc été proposées :
-
Le levé de chaque entité sur un formulaire unique muni d’une barre de navigation.
Ainsi une seule entité est visible sur la page mais la barre de navigation permet à
l’usager qui le souhaite de revoir les entités qu’il a déjà levé, d’en rechercher une en
particulier, ou d’accéder à une nouvelle entité à renseigner. Comme les entités
ponctuelles ont moins de paramètres à renseigner que les objets précédents, il est
possible de mettre sur une même page plusieurs entités pour optimiser la place. On
peut ainsi saisir plusieurs entités différentes sans avoir à changer d’onglet.
Figure 17:Première version de la saisie d'objets ponctuels et zonaux
-
Le levé des différents objets peut aussi se faire en mode feuille de données. Dans ce
cas, chaque colonne correspond à un paramètre à renseigner, et chaque ligne à un
enregistrement, à un objet levé (mais du même type d’entité). L’avantage de cette
méthode est qu’elle permet de saisir un objet tout en permettant de voir les autres
objets (de même nature) levés précédemment sur une seule et unique page.
44
L’inconvénient est que suivant le nombre de champs à renseigner, et suivant leur
largeur sur la feuille, il n’est pas exclu que le formulaire ne puisse tout afficher à
l’écran, créant du même coup une barre de défilement horizontale pour accéder aux
derniers paramètres à saisir, ce que nous cherchons justement à éviter : cependant la
largeur des colonnes est redimensionnable en direct par l’utilisateur.
Figure 18: Deuxième version de la saisie d'objets ponctuels et zonaux
-
Enfin, pour pallier aux défauts des versions précédentes (entité unique sur la page ou
scroll horizontal) les objets d’une même nature peuvent être collectés sur un
formulaire continu. Ce type de formulaire permet d’afficher les différents
enregistrements, ici nos objets levés, dans une même page mais avec une présentation
de type formulaire unique. L’avantage de ce visuel, c’est qu’il permet d’afficher sur
une même page différents objets saisis d’une même entité mais en évitant la barre de
défilement en plaçant judicieusement les contrôles du formulaire dans l’espace visible
de la page. La figure suivante vous en montre un aperçu.
45
Figure 19: Troisième version de la saisie d'objets ponctuels et zonaux
Ainsi à travers une présentation conceptuelle de l’aspect graphique de l’outil, les utilisateurs
pouvaient m’indiquer la meilleure interface à mettre en place pour eux et me proposer
d’autres solutions lorsque les miennes n’étaient pas assez adaptées, afin que je puisse les
peaufiner et voir par la suite si leur développement était réalisable.
46
II.2 – LA PHASE DE CONCEPTION DU NOUVEL OUTIL
Après avoir mis en place le dictionnaire de données du programme à créer, je me suis appuyé
sur celui-ci pour monter la base de données avec le logiciel DBDesigner. Rappelons que
DBDesigner permet la conception d’une base de données suivant une approche graphique.
Pour la réaliser, nous avons utilisé la Méthode MERISE, outil conceptuel et organisationnel
des bases de données.
II.2.1 – LA METHODE MERISE
Cette méthode a pour objectif de mettre en place les données et de les organiser via un modèle
sur lequel le développeur peut s’appuyer. Cette méthode, dite d’analyse, est la plus utilisée en
France depuis sa création à la fin des années 70. Elle a pour finalité la création d’un système
d’information (SI) fonctionnel. Pour aboutir à ce résultat, MERISE adopte une approche par
étapes qui est couramment appelé Cycle d’abstraction de conception des SI. Les différents
niveau qui la caractérisent sont illustrés sur l’image qui suit et sont décrites dans les
différentes sous-parties de cette section.
Figure 20: Cycle d'abstraction de conception des systèmes d'information
[www.commentcamarche.net/contents/merise/concintro.php3]
47
II.2.1.A – L’EXPRESSION DES BESOINS
Cette première étape peut être assimilée au travail décrit dans la partie II.1 – LE TRAVAIL
PRELIMINAIRE. La formalisation des données et des traitements que l’outil devra
comprendre est un des objectifs de cette phase. Il s’agit donc de faire l’inventaire des
éléments nécessaires au système d’information, à savoir :
-
cataloguer les orientations du projet et les objectifs à atteindre tout en tenant compte
de la politique de la société,
-
lister les objets (les tables), leurs caractéristiques (leurs champs) et les relations qui
existent entre eux,
-
essayer de cerner les « dysfonctionnements » du système actuel, tant sur un plan
technique qu’organisationnel. Sur notre projet, cela se traduit par un réagencement des
données existantes et l’apparition de nouvelles pour éviter une certaines redondance
des informations et permettre également des traitements qui n’étaient pas
envisageables sur les outils précédents du fait de leur structuration,
-
découlant du point précédent, il faut bien entendu répertorier l’ensemble des processus
et les opérations que l’outil devra pouvoir exécuter.
Pour résumer de manière simplifiée, retranscrire l’expression des besoins revient à déterminer
le cahier des charges de l’outil à développer.
II.2.1.B – LE MODELE CONCEPTUEL DE DONNEES
Il s’agit là de la première étape de la création d’une base de données. De son abréviation
MCD, le Modèle Conceptuel de Données est utilisé pour décrire de façon formelle,
standardisée et schématique les données de la base (tables, champs et relations) nécessaires à
la résolution du problème de départ, sans tenir compte de la plateforme logicielle ni du
langage de programmation qui se grefferont autour par la suite (aspect technique).
48
On peut distinguer 5 paliers pour réaliser un MCD :
-
Le premier palier correspond à l’édition du dictionnaire de données ou tout du moins à
sa vérification s’il a déjà été réalisé dans l’expression des besoins. Il est important de
vérifier qu’il n’y ait pas de synonymes, de doublons pour éviter de se retrouver avec
une même donnée présente plusieurs fois dans la base mais sous un nom différent. Il
en est de même pour les homonymes qui sont à proscrire pour empêcher d’avoir des
données différentes sous un même nom.
-
Le deuxième palier doit identifier les différentes entités de la base de données. Dans le
cadre de notre projet les entités correspondraient aux objets que l’on peut rencontrer
sur les cours d’eau, à l’image des observations relatives au secteur (lit mineur, lit
majeur, berge et ripisylve) et des observations ponctuelles et zonales (ouvrages,
travaux hydrauliques, encombres, déchets, pompage, rejets, piétinements, plans d’eau,
zones humides).
-
Le troisième palier correspond au regroupement des données par entité, tout en
s’assurant qu’elles ne sont pas présentes plusieurs fois dans celle-ci. Ainsi les données
regroupées forment les attributs de l’entité à laquelle elles sont associées. L’entité doit
obligatoirement posséder un identifiant. Ce dernier correspond à l’un de ces attributs
dont la valeur à renseigner est unique pour chaque enregistrement, c’est-à-dire pour
chaque objet d’une entité.
-
Le quatrième palier doit mettre en évidence les relations qui existent entre les
différentes entités. Pour chaque entité, il faut vérifier s’il existe ou non un lien avec
chacune des autres entités.
-
Le cinquième et dernier palier définit les cardinalités qui expliquent la nature de
chaque relation établie précédemment. Il faut donc se demander :
o À combien d’objets d’une deuxième entité un objet d’une première entité peut
être lié ?
o À combien d’objets de la première entité un objet de la deuxième peut être lié ?
49
II.2.1.C – LE MODELE LOGIQUE DE DONNEES
Le MLD correspond à une représentation plus informatique des éléments du MCD de manière
à rendre ces informations compréhensibles par un SGBD. C’est une transcription. Les entités
du MCD correspondent alors à des tables dans le MLD, les attributs à des champs, dont il faut
renseigner le type de données (texte, numérique, date/heure…) et la longueur (nombre de
caractère maximum autorisé pour la valeur à inscrire dans le champ), et les identifiants à des
clés primaires. Ce modèle décrit donc la structure de données.
II.2.1.D – LE MODELE PHYSIQUE DE DONNEES
Le MPD, quant à lui, correspond à l’implémentation du modèle créé dans le SGBD. On
traduit donc le schéma réalisé dans un langage de définition de données. Généralement ce
langage est le langage SQL (Structured Query Language) du fait qu’il soit reconnu en tant
que norme officielle de langage de requête relationnelle par l’ANSI (American National
Standards Institute) et l’ISO (International Standards Organization)
II.2.1.E – LE SYSTEME D’INFORMATION AUTOMATISE
Comme nous venons de le voir, le système d’information automatisé n’est autre qu’un
Système de Gestion de Base de Données. C’est un logiciel qui sert à manipuler les bases de
données, que ce soit pour saisir, modifier ou consulter des objets de la base de données. Dans
le cadre de notre projet il s’agit du logiciel Microsoft Office Access 2007.
50
II.2.2 – LA CONCEPTION DE LA BASE DE DONNEES
Comme nous l’avons vu dans la partie II.1.3 – Choix des outils, nous avons utilisé l’outil
libre DBDesigner 4 pour réaliser la base de donnée par une approche schématique et visuelle.
II.2.2.A – L’INTERFACE DU LOGICIEL
Ce logiciel de conception visuelle de base de données est d’une utilisation très simple et
possède une interface utilisateur tout aussi accessible, qui ressemble beaucoup à certains
logiciels de dessin dans la disposition des outils (Adobe Illustrator, Adobe Photoshop)
Figure 21:Interface utilisateur du logiciel DBDesigner 4
Comme nous pouvons le voir sur la figure ci-dessus un large espace est réservé à la réalisation
du Modèle Conceptuel de Données.
51
À gauche de celui-ci se trouve la barre des outils d’édition où l’on a entre autre les boutons
permettant de créer les différents objets de la base (tables, champs et relations) et de les
renseigner.
Figure 22: Barre d'édition sous DBDesigner 4
À droite de la zone de dessin, le long de la largeur, sont situés trois autres modules :
-
En haut, nous avons un volet de navigation et d’information.
o L’onglet Navigation permet de déplacer la vue de la région de conception, de
zoomer ou dézoomer sur une partie de l’espace de travail avec la barre ou en
entrant une valeur numérique, très pratique pour cibler un élément particulier.
o L’onglet Information indique le nom de l’objet sélectionné ainsi que sa
position sur la zone de travail, ainsi que ses dimensions.
Figure 23: Volet Navigateur & infos sous DBDesigner 4
-
En bas est placé le modèle de base de données. Dans cette fenêtre sont répertoriées
toutes les tables que présente le modèle, avec la liste des champs qui leur sont associés
ainsi que les relations auxquelles elles sont rattachées. Deux autres boutons sont aussi
présents dans le bandeau de ce module pour créer une nouvelle table ou en supprimer
une déjà existante. Dans le cas d’une suppression, tout objet associé à la table est
également perdu.
52
Figure 24: Volet Modèle de BD sous DBDesigner 4
-
Un module pour le type de données est calé entre les deux volets précédents. Il permet
à l’utilisateur d’éditer le type de données en lui ajoutant des paramètres, en modifiant
les options, ou en configurant d’autres options.
Figure 25: Volet Type de données sous DBDesigner 4
53
II.2.2.B – LA CREATION DE LA BASE DE DONNEES
Grâce à ces outils, il est très facile de mettre en place les différentes tables de la base de
données avec les champs correspondants, via la fonction Table Editor (
mettre en place les relations (
ou
) puis de
). Lors de la création des champs, on
peut aussi définir leurs types de données, le nombre maximum de caractères et les légender.
Figure 26: Edition de la table t_Secteur et t_Lmajeur sous DBDesigner 4
54
Figure 27: Edition de la relation entre les tables t_Secteur et t_Lmajeur sous DBDesigner 4
On peut donc créer directement à partir du MCD le MPD, ce dernier intégrant le MLD.
Une fois le modèle entièrement validé, on peut procéder à son exportation sous SGBD.
(Annexe 2 : Modèles Conceptuel et Physique de Données)
55
II.2.2.C – L’IMPLANTATION DE LA BASE DANS MICROSOFT OFFICE ACCESS
Pour ce faire, une fois arrivé à cette étape, le modèle peut alors être transcrit en langage SQL
via la commande Fichier/Exporter/Script de création SQL… ou en cliquant sur le bouton
correspondant
de la barre d’édition. La fenêtre Export SQL Script s’ouvre alors pour
sélectionner ou non certains réglages avant que le modèle ne soit traduit dans le langage de
définition de données.
Figure 28: Module d'exportation du modèle en script SQL
Une fois les options validées, DBDesigner crée un fichier SQL des différents éléments qui
constitue la base de données, dont la figure suivante nous montre un extrait. Comme on peut
l’observer le fichier à importer dans Microsoft Office Access est constitué de requêtes basées
sur les instructions du langage SQL et qui permettent de créer les différentes tables avec les
champs associés. On peut également voir que les relations ne sont pas traduites dans le fichier
56
Figure 29: Extrait du fichier d'exportation du modèle en SQL créé sous DBDesigner 4
Cette opération effectuée, tout le reste de la conception et du développement de l’outil se font
sous Microsoft Office Access 2007. C’est d’ailleurs à partir de la commande Créer/Création
de requête de ce logiciel propriétaire que sont importées les tables du modèle.
57
Une fois dans l’interface de création de requêtes, il faut changer l’affichage et basculer du
Mode création au Mode SQL. Des instructions SQL peuvent alors être tapées. Dans notre cas
il suffit de copier les différentes instructions du fichier SQL réalisé sous DBDesigner et de les
exécuter pour créer de manière automatique l’ensemble des tables de la base.
Figure 30: Importations des tables sous Access
58
Cette méthode peut avoir l’inconvénient d’être un peu lourde du fait qu’il faille Copier/Coller
l’instruction d’une table dans Access, l’Exécuter, puis recommencer l’opération tour à tour
pour chacune des tables de la base. Toutefois cette méthode reste bien plus rapide que de créer
une table avec toutes ces caractéristiques via la commande Créer/Table. Par contre, le gros
avantage de cette méthode est qu’elle permet de créer des tables parfaitement identiques à
celles présentées sur les modèles conceptuel et physique de données réalisées sur DBDesigner
4, avec un risque d’erreur fortement réduit.
II.2.2.D – L’APPLICATION DES RELATIONS
Les tables importées, la base n’est toujours pas prête à être exploitée. Il reste encore à ajouter
les relations entre les tables comme elles apparaissent sur les modèles cités précédemment.
Cette manœuvre s’effectue à partir de l’item Relation, situé dans l’onglet Créer du ruban
Access.
On ajoute alors sur la page vierge les différentes tables de la base et on les relie suivant le
modèle validé. Toutefois il faut faire attention de créer les relations dans le bon sens, en
tâchant de partir du champ de la table principale vers le champ de la table secondaire ; champ
qui constitue la clé étrangère.
Une relation est alors créée entre les deux tables mais sans cardinalité. Pour qu’Access puisse
les prendre en compte de manière à gérer efficacement les relations entre les tables et éviter
ainsi toutes incohérences, il faut cocher la case correspondant à l’intégrité référentielle, dans
la fenêtre Modifications des relations (accessible en double-cliquant sur la relation à
modifier). Si le modèle a été construit correctement, Access met automatiquement les
cardinalités logiques qui devraient s’appliquer entre les tables de la base de données.
Il est également possible de choisir deux autres options dans les Modifications des relations :
-
L’option Mettre à jour en cascade, qui permet de changer automatiquement la valeur
d’un champ en cascade. Concrètement, le changement de valeur d’un champ dans la
table principale entraînera le changement de la valeur du champ associé (clé étrangère)
dans la table avec laquelle elle est liée.
59
-
De la même manière que l’option précédente, Effacer en cascade permet d’effacer
tous les enregistrements d’une table secondaire si un enregistrement de la table
principale à laquelle ils sont rattachés venait à être supprimé.
Figure 31: Relations entre les tables dans Microsoft Office Access
60
II.2.2.E – LA MISE EN PLACE DE LISTES DEROULANTES
Suite à cela, et avant de partir dans le développement de l’outil, j’ai également créé de
nouvelles tables. Ces tables comprennent des champs qui sont mis en correspondance avec les
champs des tables d’entités dont les contrôles (zone de texte, liste de choix ou liste
déroulante) seront des listes déroulantes. En effet les tables d’entités comprennent toutes un
certains nombre de champs qui doivent être renseignés d’après des listes déroulantes qui
proposent plusieurs valeurs. Ces listes de choix sont en fait les différents enregistrements d’un
champ d’une table construite spécifiquement à cet effet que j’appelle des « tables listing ».
Pour cette base de données, j’ai opté pour la création de plusieurs tables de liste en fonction
des entités :
-
une pour chacune des entités caractéristiques d’un secteur,
-
une pour les ouvrages,
-
une pour les actions,
-
une dernière pour l’ensemble des autres entités ponctuelles et zonales.
Il est plus pratique de multiplier les tables listing pour retrouver certaines informations
lorsqu’il faut les modifier. De plus, associer une table de liste à une table d’entité renforce la
logique de la base.
Ainsi, comme l’explique d’une manière plus compréhensible la figure suivante, le champ
« Style_fluvial » de la table « t_Lmineur » a pour contrôle une liste déroulante qui contient les
valeurs non nulles du champ « Style_fluvial » de la table listing « t_liste_Lmin » qui lui est
associée.
Il est également possible que plusieurs champs fassent appel à une même liste déroulante,
comme
c’est
le
cas
des
champs
« Ecoulement_Rupture »,
« Microsinuosite »,
« Aterrissements_Nb », « Facies_Div » et « Colmatage_Degre » (table t_Lmineur) qui ont
pour
contrôle
des
listes
déroulantes
dont
« Liste_FMF_feminin » (table t_liste_Lmin).
61
le
contenu
est
celui
du
champ
Figure 32: Définition de tables listing pour les listes déroulantes des champs des tables d'entités
62
II.3 – LA PARTIE DEVELOPPEMENT
II.3.1 – LA CREATION DE L’INTERFACE GRAPHIQUE : LES FORMULAIRES
Pour que les utilisateurs puissent interagir avec l’outil, il fallait avant tout créer l’interface
graphique qui puisse leur permettre d’effectuer les opérations de saisie et de traitement que
cette application était censée réaliser. Pour mettre en place les propositions retenues (II.1.4.B
- Proposition d’aspects graphiques de l’outil), il fallait créer des formulaires à partir de la
fonction du menu déroulant Access : Créer / Création de formulaire.
Pour commencer j’ai créé le formulaire permettant la saisie et la modification des
informations qui doivent être levées lors des prospections terrain et l’ai programmé. Les
autres formulaires créés par la suite se sont alors articulés autour de celui-ci. Certains
formulaires ne sont que des menus programmés pour permettre aux utilisateurs d’accéder à
d’autres formulaires par le biais de boutons, tandis que d’autres sont aussi étroitement liés aux
tables de la base de données, autorisant ou non certaines actions susceptibles d’avoir des
répercutions sur les informations des enregistrements de ces tables.
Ce dernier cas correspond à ce qui a été réalisé sur le formulaire de saisie des informations
terrain (entre autres). Ce type de formulaire a pour source une à plusieurs tables, voire des
requêtes basées sur des tables (pour n’afficher que certains enregistrements par exemple). Les
champs que l’on veut voir apparaître dans le formulaire sont alors liés à des contrôles (zones
de texte et listes déroulantes) que l’on place sur le formulaire.
Pour le formulaire de saisie et de modification des informations terrain, la partie supérieure
correspond aux champs de la table t_Secteur. Concernant les onglets, chacun d’eux
correspond à une entité, et donc une table, qui est représentée par un sous-formulaire. Ici
aussi, tous les contrôles sont liés à un champ de la table d’entité auquel il appartient. Il est à
noter également que tous les champs ne sont pas obligatoirement présents sur le formulaire :
-
soit parce que le contrôle a été masqué à l’utilisateur, comme les contrôles associés
aux champs attribuant un numéro automatique à chaque enregistrement
-
soit parce qu’il n’a tout simplement pas été ajouté.
63
Toutefois l’interface graphique ne se limite pas à cela. En effet, pour chaque objet graphique,
et suivant sa nature, un grand nombre de propriétés (basiques) peuvent être paramétrées
(couleur de texte, type de texte, couleur de fond, mise en place d’une image, visibilité, infobulle, évènement…)
Figure 33: Interface graphique du formulaire de saisie et de modification
Bien évidemment l’interface graphique a été amenée à évoluer au cours du temps suivant les
contraintes du projet et les améliorations apportées. Je vous invite donc à naviguer à travers
les formulaires qui composent le projet final pour évaluer son ergonomie et sa dimension
« esthétique ».
Ainsi, on peut remarquer à titre d’exemple que l’emplacement réservé pour l’affichage des
photos, prévu lors des propositions, a été supprimé, pour rendre le module de saisie et de
modification moins lourd et maximiser l’espace prévu pour renseigner les entités. Néanmoins
leur visualisation a été repensée et les photos des entités ont été intégrées dans les États
Access, outils d’analyse qui s’apparentent dans notre cas à la version imprimable des
informations levées dans nos formulaires. Les états feront l’objet d’une autre partie.
Même si leur utilisation n’est pas la même, la mise en place de l’interface graphique des états
Access se fait de la même manière que pour les formulaires.
64
II.3.2 – LA PROGRAMMATION DES FORMULAIRES DE MANIERE GENERALE
Une fois les objets graphiques placés sur le formulaire, on peut programmer certains
évènements, comme le clic sur un bouton, ou le remplissage automatique de certains contrôles
suite à certaines actions. La programmation des éléments d’un formulaire, ou d’un état, sous
Microsoft Office Access se code dans un environnement de développement intégré au logiciel,
dans une fenêtre spécifique, en langage Visual Basic for Applications (VBA).
Il est l’un des langages de programmation les plus utilisés pour le développement rapide, car
il ne nécessite pas de performances critiques pour pouvoir faire fonctionner un programme, ni
d’avoir des connaissances très poussées pour réussir à le créer. Toutefois, il est préférable
d’avoir quelques connaissances en programmation afin de créer un outil opérationnel
facilement maintenable.
Ce langage de programmation événementielle permet ainsi de configurer les actions des
composants d’un formulaire mais aussi d’en définir les propriétés. Ces propriétés qui sont les
mêmes que dans la partie précédente ont l’avantage ici de pouvoir changer en fonction de
certains évènement. Ainsi les propriétés statiques mise en place dans les propriétés du
formulaire peuvent devenir dynamiques grâce à la programmation en VBA.
Au sein de ce programme, la plupart du codage est assez redondant et souvent de l’ordre des
exécutions simplistes, mais nécessaire à la bonne utilisation de l’outil.
II.3.2.A – LE GESTIONNAIRE D’ERREURS
Cette instruction est généralement utilisée dans les phases de programmation pour déceler les
erreurs inattendues des instructions comprises dans un évènement, une procédure, mais aussi
dans les phases d’utilisation pour éviter que l’application ne se ferme.
Placé automatiquement sur l’évènement clic lors de la création de boutons via l’assistant, le
gestionnaire d’erreurs permet, en cas d’erreur des instructions réalisées dans la procédure
(quelle qu’elle soit), d’indiquer où elle se situe dans le code et de quel type d’erreur il s’agit,
sans pour autant fermer l’application. Sans ce gestionnaire, une erreur d’instruction est
irrécupérable : le programme affiche un message avec le code erreur et ferme l’application.
65
Au niveau du gestionnaire d’erreurs, il s’agit de l’instruction On Error GoTo.
Habituellement, on place la balise d’ouverture de cette instruction juste après la balise
d’ouverture de la procédure, de manière à rendre le gestionnaire d’erreur actif sur l’ensemble
du code que contient la procédure évènementielle. Suite au code, on place une ligne Exit Sub,
qui permet d’arrêter la procédure si le code s’est exécuté normalement. Mais si cela n’était
pas le cas, un message d’erreur devrait être retourné à l’utilisateur. C’est pourquoi les
étiquettes de gestion d’erreurs sont souvent situées à la fin de la procédure, après le Exit Sub.
Ainsi la programmation du gestionnaire d’erreur donne ceci :
Figure 34: Programmation du gestionnaire d'erreurs
II.3.2.B – LES ACTIONS DE MENUS
Dans le langage VBA, les actions de menus servent à effectuer des actions. Dans le cadre de ce
projet le codage de ces instructions nous a permis d’effectuer facilement des tâches telles que
l’ouverture ou la fermeture d’un formulaire ainsi que l’enregistrement ou la suppression d’un
enregistrement dans les formulaires de saisie de données. Toutefois, les actions de menus ne
se limitent pas à cela. Il est possible de réaliser les actions suivantes :
-
Ajouter un menu
-
Utiliser une fenêtre de message (MsgBox)
-
Exécuter une application
-
Exécuter du code
-
Envoyer des touches
-
Définir une valeur
-
Arrêter des macros
66
Toutes ces actions s’exécutent à partir de l’objet DoCmd, suivi d’un point "." puis du nom de
l’action à exécuter. Par défaut, l’interface Visual Basic for Applications déroule la liste des
actions relatives à l’objet après avoir tapé l’objet suivi du point ".".
La plupart de ces actions possèdent des arguments à renseigner. Certains sont obligatoires et
d’autres facultatifs.
Par exemple, pour ouvrir un formulaire, seul l’argument FormName (nom du formulaire) est
obligatoire pour exécuter cette instruction. Les autres arguments, facultatifs, prendront la
valeur par défaut s’ils ne sont pas renseignés.
Figure 35: Exemple de l'instruction d'ouverture d'un formulaire en Visual Basic
Une autre ligne de code peut aussi être ajoutée à la suite de la ligne DoCmd.OpenForm dans
le cadre d’un formulaire de saisie pour ouvrir un formulaire sur un enregistrement particulier :
Figure 36: Les différentes options d'ouverture d'un formulaire sur un enregistrement
Les autres instructions permettant de fermer un formulaire, de sauvegarder un enregistrement
ou de le supprimer se codent tout aussi simplement et sont décrites sur la figure suivante :
Figure 37: Code planifiant la fermeture d'un formulaire, la sauvegarde ou la suppression d'un enregistrement
67
II.3.2.C – LA VISIBILITE DES ELEMENTS D’UN FORMULAIRE
Cette instruction peut s’avérer utile lorsqu’on veut faire apparaître, ou rendre invisible, un
élément du formulaire suite à un évènement.
Nous nous trouvons exactement dans ce cas précis dans le formulaire de saisie des
informations liées à un secteur de cours d’eau. Lorsque l’on ouvre ce formulaire pour saisir un
nouveau secteur, ce dernier ne laisse paraître que les informations générales du secteur, les
onglets des formulaires des différentes entités étant masqués. Ils ne deviennent visibles
qu’une fois l’identifiant du secteur de cours d’eau renseigné.
Cela permet d’ordonner la saisie de l’utilisateur qui doit d’abord renseigner le numéro du
secteur avant de pouvoir saisir les informations des entités qui le caractérisent afin d’éviter les
erreurs du programme. Dans le cas présent l’erreur serait de renseigner les informations du
sous-formulaire avant d’avoir renseigné le contrôle de l’identifiant du champ commun au
formulaire et à son sous-formulaire (champs père et fils), ici l’identifiant secteur.
On notera également à travers le code dévoilé dans la figure suivante que cette instruction
dépend d’une autre instruction : If Then.
II.3.2.D – L’INSTRUCTION IF…THEN…ELSE
Cette instruction fait partie des structures conditionnelles, qui permettent de tester si une
condition est vraie ou non. L’instruction If …Then, forme la plus basique, permet de tester une
condition. Si elle est remplie, alors le programme exécute la liste d’instruction définie après le
Then. Dans le cas contraire, aucune instruction après le Then n’est réalisée
Ici l’ajout du Else permet d’exécuter d’autres instructions dans le cas où la condition ne serait
pas remplie, comme nous l’avons vu dans la partie précédente avec la visibilité des entités
d’un secteur, expliqué sur la figure qui suit. Toutefois dans ce cas présent, une simple
instruction If…Then aurait suffit.
68
Figure 38: Visibilité ou non des entités du secteur à l'ouverture du formulaire secteur
L’instruction If…Then…Else a beaucoup été utilisée pour réaliser l’outil interne du
département D8 d’ASCONIT, allant même parfois jusqu’à imbriquer plusieurs instructions If.
69
Avec du recul, et avec l’expérience que m’a apporté ce stage, j’utiliserais à l’heure actuelle
une instruction If…ElseIf…Else pour tester plusieurs conditions de façon exclusive, sans avoir
à imbriquer plusieurs instructions d’affilé.
II.3.2.E – LE DEROULEMENT AUTOMATIQUE DES LISTES DEROULANTES
Cette instruction a été développée pour tous les contrôles de type « liste déroulante » des
différents formulaires de saisie et de modification des données. Le déroulement automatique
de la liste déroulante, programmé sur la réception du focus par le contrôle, était une astuce
pour rendre la saisie des informations sur le terrain plus pratique et facile lorsqu’elle devrait
se faire sur un mini-PC, limitant ainsi les pertes de temps.
Figure 39: Instruction de déroulement automatique de liste déroulante
Cependant, il m’a fallu répéter le code suivant sur une centaine de contrôle. Même si
l’instruction ne prend qu’une seule ligne, il aurait mieux valu procéder différemment de
manière à n’avoir cette instruction qu’une fois, mais qui soit valable pour tous les contrôles de
type « liste déroulante » du projet, ou à défaut sur chaque formulaire où cette instruction était
nécessaire. De cette manière le code aurait été constitué de quelques lignes de code pour
l’ensemble des contrôles au lieu d’une ligne, mais pour chacun des contrôles, soit plus d’une
centaine au totale. Cela aurait été plus ergonomique.
70
II.3.2.F – AUTOMATISATION DES IDENTIFIANTS DES OBSERVATIONS TERRAIN
J’ai suggéré cette amélioration pour optimiser la saisie et éviter à l’utilisateur de taper des
doublons, l’identifiant des entités devant être unique (et clé primaire de chaque table).Cette
instruction était donc importante car elle permettrait à l’utilisateur de gagner du temps lors de
la saisie, sans avoir à se préoccuper de l’unicité de l’identifiant et à se rappeler s’il avait déjà
été attribué. Les identifiants des observations terrain sont constitués de deux lettres pour
désigner l’entité (exemple : OH pour Ouvrage Hydraulique, PE pour Plan d’Eau ou encore
ZH pour Zone Humide) suivi d’un numéro unique.
Le contrôle devant être renseigné après le renseignement de n’importe quel champ du
formulaire de l’entité en question, le code a été créé sur la procédure évènementielle Après
mise à jour (After_Update) de chacun des contrôles du formulaire.
Ici aussi, tout comme pour le déroulement automatique des listes déroulantes, le codage aurait
pu être retravaillé pour éviter de multiplier les lignes de code pour chaque contrôle.
Pour réussir cette amélioration, il a fallu, dans un premier temps, ajouter un champ de type
NuméroAuto dans chaque table des observations ponctuelles et zonales observables sur un
cours d’eau. Insérer un champ NuméroAuto dans une table permet de générer un numéro
unique pour chaque enregistrement de celle-ci.
C’est à partir de ce NuméroAuto, généré dans un contrôle de chaque formulaire
d’observations, que sont créés les identifiants des entités. Bien entendu le contrôle affichant le
NuméroAuto est masqué de manière à ce qu’il n’apparaisse pas à l’écran.
Ainsi, après la saisie de n’importe quel champ d’une entité, le contrôle du NuméroAuto
génère un nombre, qui est récupéré par le contrôle de l’identifiant de l’entité après avoir écrit
les deux lettres caractérisant l’entité.
71
Figure 40: Identifiant automatique de l’entité après mise à jour des autres champs de l’enregistrement
(Ici le contrôle de fond violet « Encombre_ID » [lié au champ de type NuméroAuto] a été
rendu visible pour la schématisation de l’automatisation de l’identifiant de l’entité.)
72
II.3.2.G – ETIQUETAGE DES CONTROLES DE REMPLISSAGE DES OBSERVATIONS PONCTUELLES
Pour pouvoir utiliser de manière optimale les sous-formulaires des entités en mode continu, il
fallait que chaque enregistrement tienne sur deux lignes.
Pour y arriver, il fallait supprimer les étiquettes de ces contrôles. Cela entraînait le problème
de savoir ce qu’il fallait alors renseigner dans chaque contrôle. Les info-bulles permettent
justement de pallier cette difficulté. Néanmoins cette solution n’est pas très pratique puisqu’il
faut que l’utilisateur place la souris sur chacun des contrôles, et attendre quelques instants,
pour avoir cette information.
Une des solutions envisagées était de mettre les étiquettes de chaque contrôle en en-tête de
formulaire, disposées de la même manière que les contrôles. Ainsi nous aurions su à quoi
correspondait chaque contrôle. Cependant, là aussi la solution aurait obligé l’utilisateur à
regarder pour chaque contrôle l’en-tête avant de pouvoir remplir le contrôle.
La solution la plus adaptée était donc de mettre l’étiquette de chaque contrôle dans la zone de
remplissage de ces derniers lorsque celui-ci est vide. Après un certain nombre de recherches
et d’essais, j’ai pu trouver comment réaliser cette astuce. Il suffit tout simplement de mettre
dans la propriété Format de chaque contrôle le texte suivant :
@;[Nom_de_la_couleur]"Texte_de_l’étiquetage"
Seul défaut de cette astuce (simple mais méconnue), on ne peut pas spécifier une police ou
une taille différente des informations à remplir. De plus les couleurs d’étiquetage sont assez
limitées (Noir, Blanc, Rouge, Vert, Bleu). Toutefois, cette solution reste la meilleure
disponible.
Afin de distinguer les contrôles vides, rempli avec l’étiquette, des contrôles renseignés, j’ai
joué sur les couleurs de texte afin que l’utilisateur puisse les discerner sans ambigüité et
instantanément. On peut observer le résultat sur la figure précédente.
Figure 41: Code d'étiquetage du contrôle Embacle_Rq
73
II.3.3 – LA PROGRAMMATION DE CODES PLUS SPECIFIQUES SUR LES FORMULAIRES
II.3.3.A – SAISIR/MODIFIER DEUX ENREGISTREMENTS SIMULTANEMENT SUR UN FORMULAIRE UNIQUE
Un des impératifs que devait respecter l’outil était de pouvoir saisir sur un même formulaire,
les paramètres des entités Lit majeur, Berge et Ripisylve en rive gauche et en rive droite
simultanément, paramètre par paramètre. Afin de pouvoir saisir les entités sur les deux rives
en même temps, il aurait fallu que le formulaire soit en mode d’affichage Feuille de données,
de manière à pouvoir naviguer d’une ligne à l’autre. Néanmoins cette solution n’était ni
ergonomique, ni esthétique. De plus ce mode d’affichage aurait rendu difficile le remplissage
de sous-formulaires. J’ai donc opté pour une saisie sur formulaire unique. Or ces formulaires
ne peuvent correspondre qu’à un enregistrement, mais je voulais qu’ils en contiennent deux :
celui de la rive gauche et celui de la rive droite.
Pour ce faire il fallait créer sur le formulaire autant de contrôles que de paramètres à
renseigner, soit deux contrôles par paramètre (un pour la rive gauche et un pour la rive droite).
Mais contrairement aux autres sous-formulaires que peuvent contenir les formulaires de
saisie, ceux-ci ne sont pas liés aux champs d’une table par Access : ils sont indépendants.
En effet chaque contrôle indépendant que contiennent ces formulaires est codé pour afficher,
enregistrer et supprimer la valeur d’un champ donné, pour un enregistrement donné, dans une
table donnée. Une telle programmation a été possible du fait que les éléments Lit majeur,
Berge et Ripisylve contiennent un nombre fixe d’enregistrement : un pour chacune des rives,
soit deux au total.
Ainsi, une fois les différents contrôles renseignés pour chacune des rives, le bouton
Enregistrer du formulaire devait sauvegarder les valeurs des paramètres de la rive gauche
dans le premier enregistrement et les informations de la rive droite dans le deuxième
enregistrement en spécifiant la correspondance de chaque contrôle avec le bon champ dans la
table.
Cependant bien qu’étant enregistrés dans la table, à la réouverture de ce même formulaire, les
contrôles n’afficheraient aucune des valeurs saisies, puisque ces derniers sont indépendants. Il
fallait donc rajouter un code spécifique sur la procédure évènementielle d’activation du
formulaire. L’affichage de chacune des valeurs des différents contrôles des paramètres rive
74
gauche et rive droite devait être programmée en appelant les valeurs des champs des deux
enregistrements sauvegardés dans la table.
Quant à la suppression des données, le code nécessaire était plus simple. Il suffisait de
supprimer les enregistrements de la table relatifs au secteur sur lequel on effectuait la saisie et
de forcer l’affichage des contrôles indépendants sur une valeur nulle.
La programmation de ces éléments n’a pas été aisée, du fait qu’il est survenu très rapidement
dans la phase de programmation et que mes compétences en Visual Basic for Applications
étaient alors encore assez sommaires. Mais après quelques jours de recherche, de consultation
de base et d’essais, je suis enfin parvenu à un résultat satisfaisant qui répondait aux besoins
des utilisateurs.
L’outil étant une application interne du bureau d’étude Asconit, qui pourrait de plus être
externalisée par la suite, le code de ces trois procédures n’a pas été mis à la disposition des
lecteurs de ce rapport. Néanmoins les possesseurs de la base de données et des droits
administrateurs pourront le visualiser dans le code VBA des formulaires f_Lmineur,
f_Lmajeur, f_Berge et f_Ripisylve.
Figure 42: Liens des paramètres des deux rives avec les deux enregistrements dans la table associée
75
II.3.3.B –SOURCE ET ENREGISTREMENTS DU FORMULAIRE ACTIONS DEFINIS SUIVANT SON OUVERTURE
Au début du projet, le formulaire des actions était l’un des onglets du formulaire Secteur et du
formulaire Observations. Les utilisateurs devaient donc saisir l’identifiant de l’objet puis
renseigner les différents paramètres de l’enregistrement relatif à une action. Bien entendu un
objet peut avoir plusieurs actions, auquel cas il y a autant d’enregistrements que d’actions.
Toutefois cette méthode a été abandonnée début Août car elle était trop lourde à saisir, pas
assez pratique et ne retranscrivait pas le rendu attendu. Après plusieurs heures de discussions
avec Sylvain WILLIG sur ce sujet, nous sommes parvenus à une solution plus adaptée,
détaillée ci-dessous :
Les actions de chaque objet devaient être saisies depuis les enregistrements de ces derniers et
ne devaient afficher que les actions de l’objet en question, et de façon à ce que l’utilisateur
n’ait pas à renseigner l’identifiant de l’objet. Il fallait que cela soit automatique. Toutefois
dans le module de consultation de l’outil, l’utilisateur devait pouvoir voir la liste de toutes les
actions à réaliser, classées par secteur, puis par entité, de manière à avoir une vision organisée
des interventions suggérées.
Or les formulaires des différentes entités étaient déjà « bien remplis » et ne pouvaient
accueillir un nouveau sous-formulaire. Il fallait donc placer un bouton, dans chacun des
onglets représentant une entité, qui ouvrirait le formulaire des actions. De ce fait, chaque
entité, soit plus d’une vingtaine en englobant les deux formulaires de saisie, devait ouvrir un
formulaire Actions à laquelle elle serait liée. Malheureusement, lier chaque entité à un unique
formulaire Actions s’est avéré problématique. Le champ Entite_ID du formulaire des actions
devait pouvoir correspondre à tous les autres identifiants des objets des diverses entités, mais
ce ne fût pas le cas, sans qu’une raison évidente puisse être identifiée. Pour pallier à ce
problème, je pouvais donc créer un formulaire Actions par entité, soit une vingtaine.
Néanmoins je ne trouvais pas que cette façon de procéder était la plus adaptée. Elle multipliait
les formulaires et rendait la base moins « professionnelle », moins « propre » selon moi. Je
devais donc trouver un moyen d’optimiser cette pseudo-solution.
C’est pourquoi je voulais créer un formulaire Actions indépendant à l’origine, mais qui
lorsqu’il serait ouvert depuis l’enregistrement d’un objet d’une entité, n’afficherait et
n’enregistrerait les futures actions à saisir que pour cet objet.
76
Ainsi, il fallait que la source du formulaire des actions évolue en fonction du bouton
d’ouverture, selon que ce dernier se trouvait sur le formulaire d’une entité ou sur celui d’une
autre. De plus, la source devait être une requête, de façon à pouvoir sélectionner juste
l’enregistrement actif de l’objet. Les identifiants de l’objet et du secteur devraient ensuite être
récupérés dans l’enregistrement en question et saisis automatiquement dans les contrôles
appropriés du formulaire Actions lorsque l’utilisateur voudra suggérer de nouvelles
interventions sur cet objet.
Pour les mêmes raisons que dans la partie précédente, il m’est impossible de dévoiler le code
qui permet d’afficher et de renseigner le formulaire des actions. Cependant la démarche pour
aboutir au résultat est énoncée ci-dessous.
Comme nous l’avons précisé plus haut dans cette partie, l’ouverture du formulaire des actions
devait être déclenchée sur le clic d’un bouton, placé dans chacun des formulaires d’entités.
Suivant l’entité, on attribuait de façon automatique la source du formulaire des actions à son
ouverture.
Pour réaliser ceci, j’ai donc créé une variable publique, utilisable dans tous les formulaires de
la base, afin de lui attribuer une valeur unique à chacune des entités des deux formulaires de
saisie. Ainsi, lorsque l’utilisateur clique sur le bouton pour déclencher l’ouverture du
formulaire des actions, le bouton attribue d’abord à cette variable publique une valeur propre
à l’entité à partir de laquelle il appelle le-dit-formulaire.
Ensuite, au moment de l’ouverture du formulaire Actions, le programme choisit le code
attribuant la source des enregistrements de ce formulaire qu’il faut déclencher suivant la
valeur qu’a prise la variable publique ; qui indique quelle entité est à l’origine de l’ouverture.
Cette source d’enregistrement correspond à un objet Access de type « Requête ». Il en existe
une pour chaque entité des formulaires de saisie. Arrivé à cette étape, le formulaire des
actions affiche maintenant les enregistrements des actions liés à l’objet actif du sousformulaire de l’entité du formulaire de saisie.
Il faut maintenant renseigner, s’ils sont vides, les contrôles des identifiants Entite_ID et
Secteur_ID du formulaire après renseignement des autres contrôles du formulaire. Ainsi,
77
après la mise à jour d’un contrôle, le programme exécute une requête SQL (dépendante de la
variable publique) qui sélectionne l’enregistrement du sous-formulaire de l’entité à partir de
laquelle le formulaire des actions a été ouvert. Il est à noter que cette opération est
complètement transparente pour l’utilisateur. L’enregistrement sélectionné, le programme
récupère alors les identifiants de l’objet et celui du secteur pour remplir les contrôles
(invisible pour l’utilisateur) qui requièrent ces informations.
Figure 43: Processus du codage des actions d'un objet d'une entité
Pour résumer, à chaque entité (soit chaque onglet) des deux formulaires de saisie est associée
une valeur pour la variable publique. Chaque valeur de cette variable permet :
-
d’attribuer ensuite la requête Access correspondante qui devient la source du
formulaire des actions.
-
de récupérer les identifiants de l’objet et du secteur pour remplir les contrôles du
formulaire Actions qui les demandent.
78
Toutefois, le codage n’était pas fini. Il fallait également prévoir le cas d’éventuelles mises à
jour des objets. Par exemple l’attribution d’un nouveau secteur pour un objet ou la
suppression des actions lorsque l’objet auquel il est lié doit être supprimé.
L’idée de n’avoir qu’un formulaire dont les éléments sont dépendants de cas (méthode Select
Case) avait d’abord été développée pour le module d’Edition des listes déroulantes, module
indispensable pour que les utilisateurs puissent mettre à jour eux même plus de 90% des listes
déroulantes que contiennent les formulaires de saisie. Comme son utilisation était très
pratique et que son administration était plutôt simple, j’en ai repris le concept pour l’adapter
au niveau du formulaire des actions, plus compliqué.
II.3.3.C – MISE EN PLACE D’UN SPLASH SCREEN
Tout d’abord qu’est ce qu’un splash screen ? Il s’agit dans le langage informatique de la toute
première fenêtre affichée au démarrage d’un logiciel, généralement pendant le chargement de
ce dernier, d’où son nom (splash screen signifiant fenêtre d’attente).
Cette fenêtre, que beaucoup de logiciels professionnels utilisent, montre généralement une
image d’ouverture ou un logo qui caractérise celui-ci avec le nom de l’outil et parfois le
numéro de la version. Les noms des principaux acteurs du projet (concepteurs, coordinateurs,
analystes, testeurs…) peuvent également s’y trouver. Bien que la mise en place d’un
formulaire de ce type n’apporte aucune fonctionnalité, elle permet d’apporter un plus
esthétique à l’outil et le rend plus professionnel.
Dans le cadre de cet outil, j’ai proposé plusieurs acronymes décrivant l’outil dont les lettres
donnent un nom en rapport avec la thématique concernée ; les cours d’eau.
79
Les polices de caractères utilisées pour le texte sont entièrement gratuites et téléchargeables
sur internet.
Du fait que le splash screen soit une image, le numéro de version a délibérément été omis
pour ne pas avoir à modifier l’image à chaque amélioration majeure de l’outil
Figure 44: Images réalisées pour le Splash screen de l'outil
80
La deuxième image a été retenue pour la fenêtre d’ouverture, C’est autour de cette illustration
que l’on crée le splash screen. Pour cela, il faut créer un nouveau formulaire dans lequel on
met un contrôle Image, de manière à lui associer l’image réalisée, que nous intégrons au
SGBD.
Au niveau de la programmation, nous nous appuyons sur l’une des fonctions les moins
utilisées d’Access. Il s’agit de l’une des fonctions les plus méconnues, à savoir la minuterie.
En effet c’est à partir de cette propriété qu’il est possible de réaliser cette fenêtre particulière.
On définit tout d’abord la propriété du formulaire Intervalle minuterie. Néanmoins, il faut
faire attention : cette propriété est à renseigner en millisecondes. Ainsi pour définir le temps
d’affichage de la fenêtre à 5s, il faut mettre la valeur 5000.
Ensuite sur la procédure évènementielle Sur minuterie, On programme l’arrêt de la minuterie,
l’ouverture du formulaire d’accueil et la fermeture du splash screen.
Figure 45: Arrêt et fermeture du Splash screen
81
II.3.4 – LA PROGRAMMATION SUR LES ETATS : L’AFFICHAGE DES PHOTOGRAPHIES
Les états s’administrent de la même manière que les formulaires, que ce soit au niveau du
rendu graphique avec la mise en place de différents éléments (contrôles, sous-états…), ou au
niveau de la programmation en Visual Basic for Applications. Néanmoins l’utilisation des
états est différente de celle des formulaires. Alors qu’un formulaire est plutôt créé pour agir
(ajouter, modifier, supprimer) sur les données des enregistrements des différentes tables de la
base, l’état sert plutôt à visualiser ces données (en lecture seule), les imprimer ou encore les
exporter sous d’autres formats (Microsoft Office Word, Microsoft Office Excel, PDF…).
Il y a très peu de code qui concerne les états du fait qu’ils ne font qu’afficher les données. Le
code qui concerne ce type d’objet Access est celui réalisé pour afficher les photos.
Les photographies d’une étude étant nombreuses et très gourmandes en termes de taille, il
était primordial de ne pas les intégrer dans la base de données. Cela aurait considérablement
alourdi la base pouvant aller jusqu’à entraver son bon fonctionnement. De ce fait il fallait les
placer dans un dossier spécifique, que nous avons appelé « Photos de l’étude » de façon à ce
que la base puisse lier les photos à associer aux valeurs des contrôles des états correspondants.
Toutefois, bien que des emplacements pour les photos aient été réservés sur les états, nous ne
pouvons pas les associer à un fichier image en particulier, puisque les photographies à afficher
sont dépendantes des enregistrements. À chaque enregistrement, soit un objet d’une entité, de
nos différents états (fiches Secteur, fiches Ouvrage, fiche Plan d’eau et fiche Zone humide)
sont associés les deux photographies les plus représentatives de l’objet. C’est pourquoi une
source fixe à la propriété Image des contrôles de type Image n’était pas envisageable. Pour
chacun des deux contrôles Image, cette propriété devait affecter l’image correspondante au
cas par cas.
C’est pourquoi j’ai programmé l’affichage d’une photo selon un autre contrôle, à remplir dans
les formulaires de saisies, qui doit contenir le nom exact du fichier photo à afficher, extension
comprise (exemple DSN0034.jpg).
Pour faciliter la programmation du chemin d’accès aux photographies, le dossier photo doit
être placé au même endroit que la base de données pour pouvoir utiliser la méthode
CurrentProject.Path. Cette méthode, très pratique, permet de déterminer l'emplacement de
l’outil. À celui-ci on ajoute alors le nom du dossier « Photos de l’étude », qui a un nom fixe et
82
non modifiable, et enfin le nom complet du fichier photo pour avoir le chemin de la photo à
afficher. De cette manière, l’outil sait quelle photo il doit afficher dans quel enregistrement.
Dans le cas où l’utilisateur aurait laissé des emplacements vides, une image de remplacement
sera affichée dans ces contrôles pour manifester l’attention de l’utilisateur de manière à ce
qu’il puisse mettre à jour ou non les renseignements pour placer de nouvelles photos.
De plus, j’ai optimisé ce code en l’affectant à la procédure évènementielle de formatage de la
section Détail des états, sur laquelle sont situés les emplacements prévus pour les photos.
Ainsi, seules les photos de l’enregistrement en visualisation sont chargées afin d’alléger au
maximum la base de données.
Figure 46: Etat d'une Fiche Secteur (recto)
83
84
85
III – LES OUTILS DE PRODUCTION AUTOMATIQUE DE CARTES
Comme précisé en INTRODUCTION de ce rapport, cette partie, prévue dans le stage à
l’origine, n’a malheureusement pas pu être finalisée. Cet abandon forcé a été le résultat d’un
retard sur le planning de départ qui s’est accumulé avec le temps pour diverses raisons :
problèmes de communication, temps de réponse et de validation, difficultés techniques
rencontrées...
III.1 – LES BESOINS
Suite aux levés de terrain réalisés pour récolter des informations sur les cours d’eau, et aux
différents post-traitements qui s’en suivent, les géomaticiens doivent ensuite réaliser les atlas
cartographiques basés sur ces données. Un maximum de paramètres, au moins les principaux
et les plus discriminants, doivent être représentés dans cet atlas qui sert d’aide à la décision.
Cependant le travail est long et répétitif. Le temps passé à réaliser ces cartes pourrait donc être
optimisé si des outils étaient mis en place pour automatiser certaines opérations de la
procédure de création de ces dernières.
III.1.1 – LE PROCESSUS DE CREATION ACTUEL
Afin de pouvoir répondre aux besoins exprimés par les cartographes, je devais savoir
exactement comment ils procédaient pour réaliser les atlas cartographiques, une fois les
informations levées grâce aux outils terrain récupérées.
Après un entretien avec Céline THYRIOT et Olivier PETOT, les deux sigistes chargés de la
production cartographique, j’ai pu avoir une idée plus précise des traitements réalisés.
86
Ainsi la création d’atlas cartographiques débute avec la récupération de :
-
la couche de cours d’eau de l’étude, issue de la BD CARTHAGE,
-
du fichier de points GPS levés sur le terrain, matérialisant les limites de secteurs ou de
tronçons des cours d’eau en fonction de l’échelle de travail des utilisateurs,
-
la base de données contenant les informations des différents paramètres levés sur le
terrain.
La réalisation peut alors commencer.
-
Les couches cartographiques sont tout d’abord placées dans un nouveau document
ArcGIS
-
Les points GPS sont alors projetés orthogonalement sur le cours d’eau le plus proche
-
Le cartographe réalise ensuite le découpage des cours d’eau en secteurs à partir des
points qu’il vient de projeter.
-
Suite à cette opération, on ajoute un nouveau champ à la couche des secteurs de cours
d’eau : il s’agit de l’identifiant du Secteur, correspondant au champ Secteur_ID dans
la base de données réalisée durant ces 6 derniers mois.
-
Après avoir vérifié que le sens des polylignes des cours d’eau soit le même que le sens
d’écoulement, les secteurs sont dupliqués par Copie parallèle en rive gauche et en
rive droite à une distance de 50m à l’échelle du 10 000°. Ces polylignes serviront à
représenter différents paramètres suivant le thème que doit aborder la carte (exemple :
la ripisylve). Chaque ligne peut représenter jusqu’à trois paramètres différents en
fonction de son épaisseur, de son type de trait et de sa couleur.
-
Une couche de buffers (zones tampon) d’une largeur de 100m est ensuite créée à partir
de la fonction appropriée dans l’outil ArcToolBox sur la ligne centrale les secteurs de
cours d’eau.
-
Ces buffers sont alors découpés de manière à obtenir un buffer de 50 m de chaque côté
de la ligne de secteur pour représenter l’occupation des sols de chaque rive.
-
Toutes ces couches sont caractérisées par le champ Secteur_ID qui permet grâce à la
création de jointure de faire le lien avec les différentes tables de la base de données
permettant ainsi de paramétrer les entités géographiques.
-
Enfin les typographies peuvent être définies par la propriété Symbologie de chaque
couche.
87
III.1.2 – MON OBJECTIF
Je devais rechercher des modules existants ou en développer de nouveaux qui auraient permis
d’automatiser les traitements des productions cartographiques, toujours dans l’optique
d’améliorer la productivité et d’éviter un travail pénible et répétitif aux cartographes. Il est à
noter que ce travail devait être réalisé sur le logiciel ArcGIS 9.3.
III.2 – LA PARTIE DEVELOPPEMENT
III.2.1 – CHOIX DU LANGAGE DE PROGRAMMATION
Pour essayer d’automatiser les étapes de la production cartographique deux langages pouvait
être utilisé : Python et/ou Visual Basic for Applications, bien qu’à programmer les deux se
ressemblent fortement. Néanmoins, bien qu’ayant une certaine connaissance de la
programmation sous VBA, il m’était difficile de l’appliquer sous ArcGIS, en n’ayant aucune
connaissance du codage d’éléments cartographiques géoréférencés. La programmation des
instructions, pour en avoir trouvé des exemples, n’avait que peu de points communs avec
celles que j’ai eues à réaliser jusque là durant le stage.
Or je n’avais pas assez de temps pour pouvoir me plonger dans l’apprentissage de ce nouveau
niveau de programmation. J’ai donc opté pour une troisième solution : l’automatisation de la
production cartographique par la réalisation d’un Model Builder via l’outil ArcToolBox.
Cependant si certaines étapes pouvaient être simplifiées par des outils déjà existants, je me
devais de les trouver et de les proposer.
88
III.2.2 – LES OUTILS
C’est ainsi que je suis allé sur les sites américain et européen du support ESRI, éditeur du
logiciel ArcGIS, pour tenter de trouver des scripts existants qui répondraient aux besoins
d’automatisation de certaines étapes.
Des outils ont pu être trouvés pour réaliser la projection orthogonale des points GPS sur les
polylignes de cours d’eau, dont la description et le téléchargement sont disponibles sur ce
lien1, et pour les découper d’après les nouveaux points créés, comme le montre la
démonstration2.
1
(http://support.esrifrance.fr/outilsscripts/arcgis/arcmap/Vecteur/AccrochagePointLigne/Accr
ocher.html)
2
(http://support.esrifrance.fr/outilsscripts/arcgis/arcmap/geometrie/decouperlignesparpoints/de
couperlignesparpoints.html)
D’autres scripts peuvent même être développés pour permettre d’automatiser un certains
nombres de traitements, plus ou moins difficiles. C’est le cas de ET Geotools et ET
Geowizards , développés par ET SpatialTechniques, qui sont des extensions ArcGIS sous la
forme de barres d’outils.
Dans notre projet, c’est surtout ET GEowizards qui nous intéresse. Outre le fait qu’il peut
réaliser les deux premiers traitements, il peut aussi afficher le sens des lignes et créer des
couches sans avoir à ouvrir ArcCatalog.
Malheureusement je n’ai pas eu le temps d’approfondir les possibilités de cet outil.
Cependant, ce procédé me semblait être assez lourd et toujours aussi répétitif, bien que déjà
plus rapide. C’est pourquoi la mise en place d’un Model Builder aurait pu réaliser en un clic
un grand nombre d’étapes, si ce n’est toutes, pour réaliser une carte thématique. Ce modèle
aurait combiné des outils déjà existant, et d’autres qu’il aurait fallu créer. Par conséquent une
programmation en Visual Basic aurait surement été inévitable.
Toutefois, même sans aller jusqu’à réaliser le modèle, les couches et les jointures auraient pu
être créées à l’avance, tout comme la typographie des différentes cartes à produire et leur mise
en page, en prévoyant tous les cas de figure des différents paramètres qui pourraient
apparaître en légende.
89
90
91
CONCLUSION
Ce projet réalisé pour les Départements Biodiversité et Gestion des milieux et Système
d’Information Géographique du bureau d’étude ASCONIT Consultants fût très intéressant et
formateur. J’ai pu aborder un sujet particulièrement intéressant et important dans les SIG,
puisqu’il s’agit de la mise en place d’un système de gestion de base de données. Toutefois, la
réalisation de cet outil ne s’est pas faite sans difficulté. En effet, mes connaissances en
programmation Visual Basic for Applications étaient d’un niveau assez rudimentaire : je
savais réaliser des procédures privées avec des instructions simples qui pouvaient
éventuellement faire appel à des variables, mais guère plus. Ce stage m’a permis une autoformation beaucoup plus avancée au fur et à mesure des besoins utilisateurs à combler. Je
regrette toutefois de ne pas avoir pu réaliser la partie concernant la production automatique
des atlas sous ArcGIS. Le retard accumulé, relatif à certaines démarches essentielles qui ont
duré plus longtemps que prévu ou souhaité (problème de communication liée à la disponibilité
de chacun, étapes de validation, codage particulièrement difficile de certaines instructions…),
ne m’ont pas permis d’aller au bout de ce projet dans le temps imparti malgré ma motivation.
Toutefois dans l’ensemble, ce projet restera une bonne et belle expérience, me permettant de
me familiariser beaucoup plus avec les bases de données, leur conception et leur gestion, mais
aussi de gagner d’avantage en compétences de programmation, et notamment en langage
Visual Basic for Applications.
J’espère que mon travail durant ces six mois au sein de cette structure a été apprécié de tous.
Je souhaite également que l’outil réalisé soit largement diffusé et utilisé dans le Département
Biodiversité et Gestion des milieux et qu’il continue d’être mis à jour et amélioré par le biais
du Département Système d’Information Géographique. ASCONIT envisageait d’externaliser
cet outil auprès de ses clients ou autres. Cette pensée est alors devenue mon « ambition »
pendant ce stage et je pense avoir conçu une base assez solide pour permettre à l’outil
d’atteindre cet objectif dans un futur proche.
92
93
LEXIQUE
Abstraction (informatique) : concept identifiant et regroupant des caractéristiques et
traitements communs applicables à des entités ou concepts variés permettant la simplification
de leurs manipulations. [www.wikipedia.fr]
BD CARTHAGE : base de données complète du réseau hydrographique français.
[www.IGN.fr]
Étiage : niveau moyen le plus bas d'un cours d'eau. [www.larousse.fr]
Hélophytes : plante des marais enracinée et bourgeonnant dans la vase du fond de l'eau, mais
dont le sommet émerge à l'air libre, telle que la sagittaire, la massette, divers roseaux, etc.
[www.larousse.fr]
Hydrophytes : désignation scientifique des plantes des eaux douces. [www.larousse.fr]
Splash screen : première fenêtre affichée au démarrage d’un logiciel, généralement pendant
le chargement de ce dernier, d’où son nom (splash screen signifiant fenêtre d’attente). Cette
fenêtre, que beaucoup de logiciels professionnels utilisent, montre généralement une image
d’ouverture ou un logo qui caractérise celui-ci avec le nom de l’outil et parfois le numéro de
la version. Les noms des principaux acteurs du projet (concepteurs, coordinateurs, analystes,
testeurs…) peuvent également s’y trouver. [www.developpez.com]
94
95
REFERENCES
Les sites internet suivant ont été largement mis à contribution dans la réalisation de ce projet
que ce soit au niveau de tutoriels ou des morceaux de codes/scripts qu’ils proposent, sans
oublier les forum qui m’ont permis de progresser en programmation et de résoudre certains
problèmes rencontrés.
http://arcscripts.esri.com/
http://www.codes-sources.com/
http://www.commentcamarche.net/
http://www.developpez.com/
http://www.forumsig.org/
http://www.generation-nt.com/
http://www.self-access.com/cms/
http://support.esrifrance.fr/
http://support.microsoft.com/
Le dernier accès à ces sites remonte au 02 Septembre 2011. Ces liens étaient alors toujours
valides.
96
97
TABLE DES ILLUSTRATIONS
Figure 1: Carte de situation [Plaquette ASCONIT Consultants –Mieux nous connaître,
Décembre 2008] ....................................................................................................................... 10
Figure 2: Planning de stage ...................................................................................................... 20
Figure 3: Exemple de données et de leurs relations à travers trois bases de données existantes
[ASCONIT] .............................................................................................................................. 24
Figure 4: Schéma de rivière type [site internet de la campagne "La Rivière m’a dit…"] ........ 25
Figure 5: Extrait du dictionnaire de données créé .................................................................... 27
Figure 6: Filtres textuels dans Microsoft Office Excel 2007 ................................................... 29
Figure 7: Résultat du filtre textuel visible en Figure 4 ............................................................. 29
Figure 8: Fichier de synthèse des informations contenues dans le dictionnaire des données
existantes .................................................................................................................................. 30
Figure 9: Extrait du dictionnaire de données de l'outil mis en place........................................ 33
Figure 10: Lien existant entre le champ d'une table et son homologue dans une table de listes
.................................................................................................................................................. 34
Figure 11: Mode de saisie sur formulaire unique ..................................................................... 37
Figure 12: Mode de saisie sur formulaire à onglets ................................................................. 38
Figure 13: Questionnaire définissant les besoins utilisateurs ................................................... 39
Figure 14: Interface générale et modules qui en découlent ...................................................... 42
Figure 15: Formulaire de saisie (onglet Lit majeur) ................................................................ 42
Figure 16: Formulaire de saisie (onglet Ripisylve) .................................................................. 43
Figure 17:Première version de la saisie d'objets ponctuels et zonaux...................................... 44
Figure 18: Deuxième version de la saisie d'objets ponctuels et zonaux................................... 45
Figure 19: Troisième version de la saisie d'objets ponctuels et zonaux ................................... 46
Figure 20: Cycle d'abstraction de conception des systèmes d'information .............................. 47
98
Figure 21:Interface utilisateur du logiciel DBDesigner 4 ........................................................ 51
Figure 22: Barre d'édition sous DBDesigner 4......................................................................... 52
Figure 23: Volet Navigateur & infos sous DBDesigner 4 ....................................................... 52
Figure 24: Volet Modèle de BD sous DBDesigner 4 ............................................................... 53
Figure 25: Volet Type de données sous DBDesigner 4 ............................................................ 53
Figure 26: Edition de la table t_Secteur et t_Lmajeur sous DBDesigner 4 ............................. 54
Figure 27: Edition de la relation entre les tables t_Secteur et t_Lmajeur sous DBDesigner 4
.................................................................................................................................................. 55
Figure 28: Module d'exportation du modèle en script SQL ..................................................... 56
Figure 29: Extrait du fichier d'exportation du modèle en SQL créé sous DBDesigner 4 ........ 57
Figure 30: Importations des tables sous Access ....................................................................... 58
Figure 31: Relations entre les tables dans Microsoft Office Access ........................................ 60
Figure 32: Définition de tables listing pour les listes déroulantes des champs des tables
d'entités ..................................................................................................................................... 62
Figure 33: Interface graphique du formulaire de saisie et de modification.............................. 64
Figure 34: Programmation du gestionnaire d'erreurs ............................................................... 66
Figure 35: Exemple de l'instruction d'ouverture d'un formulaire en Visual Basic ................... 67
Figure 36: Les différentes options d'ouverture d'un formulaire sur un enregistrement ........... 67
Figure 37: Code planifiant la fermeture d'un formulaire, la sauvegarde ou la suppression d'un
enregistrement .......................................................................................................................... 67
Figure 38: Visibilité ou non des entités du secteur à l'ouverture du formulaire secteur .......... 69
Figure 39: Instruction de déroulement automatique de liste déroulante .................................. 70
Figure 40: Identifiant automatique de l’entité après mise à jour des autres champs de
l’enregistrement ........................................................................................................................ 72
Figure 41: Code d'étiquetage du contrôle Embacle_Rq ........................................................... 73
Figure 42: Liens des paramètres des deux rives avec les deux enregistrements dans la table
associée..................................................................................................................................... 75
Figure 43: Processus du codage des actions d'un objet d'une entité ........................................ 78
99
Figure 44: Images réalisées pour le Splash screen de l'outil .................................................... 80
Figure 45: Arrêt et fermeture du Splash screen ........................................................................ 81
Figure 46: Etat d'une Fiche Secteur (recto) .............................................................................. 83
100
101
ANNEXES
102
ANNEXE 1 : PLANNING DE STAGE
103
ANNEXE 2 : MODELE CONCEPTUEL ET PHYSIQUE DE DONNEES
104
105
ANNEXE 3 : GUIDE D’UTILISATION
Sommaire
Préambule ............................................................................................................................... 107
I – Pré-requis et informations générales ................................................................................. 107
I.1 – Les logiciels ............................................................................................................... 107
I.2 – La résolution .............................................................................................................. 108
I.3 – L’administration de l’outil ......................................................................................... 108
I.4 – Le découpage d’un cours d’eau ................................................................................. 109
II – Les formulaires ................................................................................................................ 110
II.1 – Exécution de l’outil .................................................................................................. 110
II.2 – Le menu principal ..................................................................................................... 111
II.2.1 – Le bandeau ......................................................................................................... 111
II.2.2 – Le corps du menu .............................................................................................. 112
II.3 – Le module de saisie des données .............................................................................. 113
II.3.1 – Saisir un nouveau secteur de cours d’eau .......................................................... 114
II.3.2 – Saisir de nouvelles observations ponctuelles ..................................................... 114
II.4 – Les formulaires de saisie des données ...................................................................... 115
II.4.1 – Le formulaire secteur ......................................................................................... 115
II.4.2 – Le formulaire des observations ponctuelles ...................................................... 119
II.5 – Le module de modification des données .................................................................. 119
II.5.1 – Modification des informations levées ................................................................ 120
II.5.2 – Modifications autres .......................................................................................... 122
II.6 – Le formulaire Editer les listes déroulantes ............................................................... 122
II.7 – Le module de consultation des données ................................................................... 123
II.8 – Le module des requêtes de synthèse ......................................................................... 126
Table des illustrations............................................................................................................. 128
Annexe ................................................................................................................................... 129
Page 106
PREAMBULE
Cet outil est un Système de Gestion de Base de Données (SGBD) développé sous Microsoft
Office Access. Il permet d’automatiser les opérations de saisie, de traitements et de restitutions
de données sur des études spécifiques à la gestion de milieux naturels, principalement les
cours d’eau.
La vocation de l’outil est de permettre l’élaboration de l’état des lieux, du diagnostic et du
programme d’actions relatifs aux différents compartiments de l’hydrosystème, en tenant
compte des spécificités de chacun des compartiments le composant et des aménagements qui
ont pu y être réalisés.
I – PRE-REQUIS ET INFORMATIONS GENERALES
I.1 – LES LOGICIELS
Pour fonctionner normalement, cette application métier nécessite que soit installé le logiciel
Microsoft Office Access, à partir de la version 2003. Toutefois, cet outil n’a besoin que du
moteur d’exécution d’Access appelé Runtime pour être entièrement exploité. Pour les
utilisateurs qui ne disposeraient pas de la licence du logiciel, le Runtime est d’office fourni
avec l’outil afin de leur permettre une utilisation immédiate après installation.
Toutefois, les différentes versions du Runtime Access, disponibles librement et gratuitement,
peuvent être téléchargé à partir l’adresse internet suivante :
http://www.microsoft.com/downloads/fr-fr/details.aspx?FamilyID=57a350cd-5250-4df6bfd1-6ced700a6715
(lien toujours valide au 02/09/2011)
Un module nécessite également de posséder Microsoft Office Outlook, à partir de la version
2003, pour pouvoir contacter l’administrateur de l’outil pour toute demande de son ressort.
Page 107
I.2 – LA RESOLUTION
Cet outil a été développé pour être manié en temps réel lors des levés d’informations sur le
terrain et être utilisé ensuite en bureau pour les opérations de post-traitement. Il a donc été
conçu pour être exploité sur de petits écrans, comme ceux des mini-PC (netbooks) ou des
tablettes tactiles, ainsi que sur des plus grands, à l’image de ceux des laptops (PC portables) et
des PC fixes.
C’est pourquoi l’outil a été élaboré pour s’adapter à une résolution optimale de 1024x600
pixels quand il est manipulé sur de petits supports et de 1680x1050 pixels pour les plus
grands. En dehors de ces résolutions, l’affichage de certains éléments peut être tronqué, et la
visualisation rendue plus difficile.
I.3 – L’ADMINISTRATION DE L’OUTIL
L’outil étant complexe, l’ajout et/ou la modification de champs dans les tables doi(ven)t être
réalisé(s) par un administrateur et non un utilisateur en raison du codage, souvent important
qui se trouve derrière ces éléments.
Il en va de même pour la modification des interfaces et des formulaires qui le composent.
Néanmoins certaines modifications peuvent être effectuées par l’utilisateur à l’intérieur de
l’outil pour modifier certaines données (informations saisies et contenu de certaines listes
déroulantes). Mis à part ce cas précis, l’utilisateur devra passer par l’administrateur.
Quant à la programmation de procédures évènementielles sous Visual Basic, elle est du
ressort exclusif de l’administrateur. Ce code est protégé par mot de passe et n’est visible et
accessible que par l’administrateur, afin d’éviter toute dégradation de l’outil.
Afin de lui faciliter le travail, un module sur la page d’accueil permet à l’utilisateur d’écrire et
d’envoyer un mail à l’administrateur de l’outil. Il devra être équipé de Microsoft Office
Outlook (à partir de la version 2003) et d’une connexion internet.
Page 108
I.4 – LE DECOUPAGE D’UN COURS D’EAU
Afin de bien comprendre la logique dans laquelle s’inscrivent ce programme et la façon dont
il doit être exploité, il convient de rappeler comment sont structurés les cours d’eau dans cet
outil.
Dans le cadre de cette application, les cours d’eau sont caractérisés par plusieurs
compartiments : lit mineur, lit majeur, berges et ripisylves, sans oublier les observations
ponctuelles et zonales (encombre, plan d’eau, zone humide…), où chacun de ces composants
est décrit par plusieurs paramètres. Les cours d’eau ne sont pas homogènes sur l’ensemble de
leur linéaire ; dans le cadre d’études diagnostiques, ils sont découpés en tronçons homogènes
du point de vue des grands paramètres physiques (pente, sinuosité, confluences…), puis
subdivisés en secteur homogènes du point de vue du fonctionnement morphodynamique, du
gabarit, de l’occupation du sol….
Au sein de l’outil, vous travaillerez à l’échelle la plus précise : le secteur homogène. Dans le
cas où les tronçons ne sont pas subdivisés en secteur, il y aura correspondance systématique
entre les deux entités.
Page 109
II – LES FORMULAIRES
Cette application est composée de quatre modules principaux, accessibles à partir de l’écran
d’accueil :
-
Un module de saisie des données, pour lever les informations d’un cours d’eau lors
des prospections sur le terrain.
-
Un module de modification, pour rectifier des données déjà saisies ou remanier le
contenu des listes déroulantes qui servent à renseigner les informations de cours d’eau.
-
Un module de consultation, permettant de consulter les principaux éléments de
l’étude.
-
Un module de requêtes statistiques pour fournir au diagnostic des chiffres concrets
pour différents niveaux de regroupement.
Figure 47: Schéma organisationnel des principaux liens entre les formulaires
(Ce schéma est également visible en version agrandie en Annexe)
II.1 – EXECUTION DE L’OUTIL
Au lancement de l’outil, une première image apparaît avec quelques informations propres à
l’outil (nom, concepteur, coordinateurs…). Après un délai de 5 secondes, ou par un simple
clic sur cet objet, il disparaît pour laisser place au formulaire d’accueil de l’outil, menu
principal de l’application.
Page 110
II.2 – LE MENU PRINCIPAL
Ce menu est composé d’un bandeau, contenant 3 boutons et de 4 boutons dans le corps de la
fenêtre :
Figure 48: Formulaire d'accueil
II.2.1 – LE BANDEAU
Concernant les éléments du ruban, il s’agit de modules additionnels pour les deux premiers,
mais qui apportent une plus-value à l’outil :
Ce bouton permet à l’utilisateur de contacter directement par mail l’administrateur
de données. Pour toute intervention sur l’outil (bug, amélioration…).
L’icône ci-contre, si elle est cliquée, permet d’accéder au site internet d’ASCONIT
Consultants, qui a développé cet outil en interne.
Reconnaissable par son symbole, ce bouton active le processus de fermeture de
l’application et quitte ensuite Microsoft Office Access ou son runtime.
Page 111
II.2.2 – LE CORPS DU MENU
Les éléments du corps de la fenêtre en revanche permettent d’accéder aux 4 modules que
comporte cet outil. Ils peuvent être classés en deux catégories :
-
La première, qui se compose des boutons de gauche, représente la partie des
manipulations de données. Via les interfaces de ces modules, les données peuvent être
créées et traitées en vue de leur exploitation dans la deuxième catégorie.
-
La deuxième, qui comprend les boutons de droite, s’apparente à la partie de
consultation et d’analyse des données.
II.2.2.A – LA PARTIE DES MANIPULATIONS DE DONNEES
Comme l’indique le texte de ce bouton, il permet d’accéder à l’« Interface de saisie des
données » à partir de laquelle est choisi le mode de saisie des informations terrain à lever.
Utilisé pour le post-traitement des données saisies à partir de l’interface précédemment citée,
ce bouton ouvrira le formulaire de l’« Interface relative à l’édition des données existantes »,
soit les données qui ont déjà été saisies par l’utilisateur et qui ont besoin d’être modifiées.
II.2.2.B – LA PARTIE CONSULTATION ET ANALYSE DES DONNEES
Ce bouton donne accès à l’« Interface de consultation des données existantes », qui permet de
visualiser et d’imprimer les « fiches » utilisées dans les rendus.
Page 112
Ce dernier bouton permet d’accéder à la synthèse des différents paramètres relevés par secteur
de cours d’eau, de manière à pouvoir établir le diagnostic sur la base de données chiffrées et
parlantes.
II.3 – LE MODULE DE SAISIE DES DONNEES
Accessible à partir de n’importe quelle interface du programme via le bouton cicontre, ce module propose de lever les informations d’un cours d’eau suivant les
compartiments qui le composent et les entités qui s’y trouvent. Ainsi le renseignement de la
base de données se fait par entité.
Figure 49:Formulaire de l'Interface de saisie des données
Deux choix s’offrent alors à vous pour saisir les données :
Page 113
II.3.1 – SAISIR UN NOUVEAU SECTEUR DE COURS D’EAU
Ce bouton permet d’accéder au formulaire Secteur qui permet de lever toutes observations
liées au secteur de cours d’eau que l’on compte renseigner. On y trouve donc les éléments
propres au secteur (lit mineur, lit majeur, berge et ripisylve) mais aussi les observations
ponctuelles et zonales que l’on veut affecter à ce secteur.
Toutes ces entités ont leur propre onglet de renseignement, afin d’organiser au mieux la
saisie.
II.3.2 – SAISIR DE NOUVELLES OBSERVATIONS PONCTUELLES
Ce bouton permet d’ouvrir le formulaire des observations. Contrairement au mode de saisie
précédent, les informations relatives au secteur ont disparu, seules demeurent les onglets
relatifs aux observations ponctuelles du cours d’eau. La grosse différence, est que les
observations restantes qui sont levées ici ne sont pas affectées par défaut à un secteur précis.
C’est à l’utilisateur d’attribuer ou non l’entité à un secteur déjà saisi dans le contrôle de
chaque onglet, ou de ne conserver comme référence spatiale que l’identifiant du point GPS.
Page 114
II.4 – LES FORMULAIRES DE SAISIE DES DONNEES
II.4.1 – LE FORMULAIRE SECTEUR
Figure 50: Formulaire Secteur
Le formulaire se présente, comme défini sur la figure ci-dessus.
Lorsque l’on arrive sur le formulaire depuis le bouton de nouvelle saisie, les onglets et leur
contenu sont masqués. Il est impossible de saisir les informations des différentes entités sans
avoir renseigné au préalable l’identifiant du secteur (1).
II.4.1.A – L’IDENTIFIANT SECTEUR
Le contrôle dans lequel cet identifiant doit être saisi n’accepte que les lettres, minuscules ou
majuscules, les tirets ( - , _ ) et les chiffres. Toute autre saisie de caractères a été interdite pour
le bon fonctionnement de la base.
Page 115
Dans le cas général, exception faite des contraintes extérieures, l’identifiant du secteur doit
être composé de 7 caractères : 3 lettres en majuscule, suivies de 4 chiffres.
-
Les 3 lettres correspondent à l’acronyme du cours d’eau auquel le secteur appartient.
-
Les 2 chiffres qui suivent (de 01 à 99) correspondent au numéro de tronçon auquel il
est rattaché.
-
Les 2 derniers chiffres (de 01 à 99) représentent le numéro du secteur à l’intérieur du
tronçon.
Lorsque les données ne sont renseignées qu’au niveau du tronçon, sans subdivision en secteur,
il n’est pas utile de renseigner les deux derniers chiffres : il y a ainsi identité entre secteur et
tronçon.
Ainsi, si l’on reprend la figure précédente, l’identifiant secteur correspond à « ARO0309 ».
Suite à la saisie de l’identifiant, les deux premières cellules verrouillées (fonds gris et contour
rouge) (2), correspondant à l’acronyme du cours d’eau et à l’identifiant du tronçon, se
remplissent automatiquement et les formulaires des entités deviennent alors visibles (3).
II.4.1.B – LES INFORMATIONS DE POST-TRAITEMENT
Certaines informations du bandeau correspondant aux informations générales du secteur ne
sont pas à renseigner directement sur le terrain. C’est le cas pour la Longeur du secteur et les
Communes qui peuvent être renseignées de façon semi-automatique suite au traitement SIG
qui nous révèlera ces données.
II.4.1.C – LA SAISIE EN GENERAL
Dans un premier temps, il est à noter que les contrôles de fonds gris et de contour rouge (2)
sont des contrôles verrouillés. Aucune valeur ne peut être remplie par l’utilisateur. Ces valeurs
sont renseignées de manière automatique suite à certaines actions.
Le renseignement des différentes informations est très simple. Les valeurs de chaque
paramètre que contient la base sont soit saisies au clavier s’il s’agit d’une zone de texte (4),
soit choisies parmi une liste de choix s’il s’agit d’une liste déroulante (5).
Page 116
En fonction des valeurs que vous attribuerez à certains paramètres, d’autres se renseigneront
automatiquement, ou deviendront visibles sur le formulaire, à l’exemple du sous-formulaire
Facteur(s) limitant la qualité des habitats qui n’apparaît que si une valeur est renseignée dans
le contrôle Qualité piscicole des habitats aquatiques (6).
Tous les éléments présents sur le formulaire sont légendés :
-
Soit grâce à une étiquette placée à gauche d’un contrôle,
-
Soit à l’intérieur du contrôle lui-même lorsqu’aucune valeur n’a encore été renseignée
dans celui-ci,
-
Soit par le biais d’une info-bulle (placer le curseur de la souris dessus et attendre
quelques secondes pour la voir apparaître).
Chacun des formulaires d’entité possède également trois boutons :
Le bouton Action, qui permet d’ouvrir le formulaire de saisie des actions liées à l’objet
en cours de renseignement
Figure 51: Formulaire Action
Page 117
Le bouton Sauvegarder, qui permet de sauver l’enregistrement en train d’être saisi. Bien
qu’il ne soit pas indispensable pour les observations ponctuelles des formulaires Secteurs et
Observations,
IL
EST
OBLIGATOIRE
SUR
CHACUN
DES
ELEMENTS
CARACTERISTIQUES D’UN SECTEUR (Onglet Lit mineur, Lit majeur, Berge et
Ripisylve).
Le bouton Supprimer, sert à effacer toutes les informations relatives à un objet d’une
entité. Un message d’information apparaîtra pour vous permettre de confirmer ou d’annuler la
suppression avant d’effectuer cette opération définitive.
Figure 52: Message d'information sur clic du bouton Supprimer
II.4.1.D – LE RENSEIGNEMENT DES PHOTOS
Lorsqu’une photo est affectée à l’objet d’une entité, il faut renseigner le nom réel du fichier
photo avec son extension. On peut le voir notamment sur la Figure 4, où les deux photos qui
caractérisent le secteur sont renseignées « DSN0001.jpg » et « DSN0002.jpg ».
Ces photos devront être placées ensuite dans le dossier Photos de l’étude, qui devra être
situé dans le même dossier que le fichier .mdb de l’outil.
II.4.1.E – LE MODE RIPISYLVE MULTIPLE DE L’ONGLET RIPISYLVE
Ce mode est spécifique à certaines études. Le bouton apparaît une
fois le formulaire ripisylve renseigné.
Le formulaire Ripisylve permet de renseigner les paramètres de la ripisylve en rive gauche et
de ceux en rive droite d’un secteur. S’il est nécessaire de saisir plus d’un linéaire de ripisylve
par rive pour un même secteur le Mode ripisylves multiples le permet.
Page 118
II.4.2 – LE FORMULAIRE DES OBSERVATIONS PONCTUELLES
Ce formulaire étant quasiment une réplique du formulaire Secteur, se référer à la partie II.4.1
– LE FORMULAIRE SECTEUR pour toutes informations relatives à la saisie des données
sur ce formulaire.
Rappelons que ce formulaire est mis à disposition des utilisateurs qui souhaitent pouvoir lever
les objets des différentes entités sans les associer préalablement à un secteur, l’information du
numéro de secteur reste toutefois possible à renseigner dès la saisie de l’entité.
II.5 – LE MODULE DE MODIFICATION DES DONNEES
Accessible à partir de n’importe quelle interface du programme via le bouton cicontre, ce module autorise la correction des paramètres levés sur le terrain et le
remaniement de la plupart des listes déroulantes présentes dans les formulaires de saisie.
Figure 53: Formulaire de l'Interface relative à l'édition des données existantes
Page 119
Quatre options sont disponibles dans ce menu :
-
Les trois premières touchent directement les paramètres (des entités) levés lors de la
prospection terrain des cours d’eau.
o Les deux premières concernent les informations liées au secteur :

L’une permet d’ouvrir les formulaires des secteurs existants pour
permettre la modification des paramètres, ajouter ou supprimer certains
objets des onglets d’entités du secteur,

L’autre permet de supprimer un secteur, voire tout un tronçon
préalablement renseigné.
o La troisième ouvre le formulaire des observations ponctuelles.
-
La dernière option ouvre un formulaire qui permet de modifier les listes déroulantes
utilisées dans les formulaires de saisie pour définir les paramètres à renseigner.
II.5.1 – MODIFICATION DES INFORMATIONS LEVEES
II.5.1.A – MODIFICATION DE SECTEURS EXISTANTS
Il y a trois manières différentes de faire des modifications de secteurs :
-
Clic direct sur le bouton Modifications de secteurs existants
Il s’agit ici de faire des modifications de secteurs « à la chaîne ». Le bouton
ouvre un premier secteur. Une fois les modifications sur celui-ci effectuées,
vous pouvez passer au secteur suivant grâce à la barre de navigation située sous
le formulaire. Cela permet ainsi d’éviter de revenir au menu pour choisir un
autre secteur. Les secteurs sont classés par ordre alphabétique.
Figure 54: Barre de navigation
Page 120
-
Sélection d’un tronçon dans la première liste déroulante puis clic sur le bouton
Ici seuls les secteurs du tronçon sélectionné seront disponibles à la
modification, la navigation entre les secteurs étant toujours assurée par la barre
inférieure.
-
Sélection d’un tronçon dans la première liste déroulante puis d’un secteur de ce
tronçon dans la deuxième liste avant clic sur le bouton
Lorsqu’il s’agit d’une modification mineure ne touchant qu’un secteur
particulier, c’est par ce module qu’il est préférable d’accéder au formulaire à
traiter. Ici seul le secteur du tronçon sélectionné sera sujet à modifications.
II.5.1.B – SUPPRESSION DE SECTEURS EXISTANTS
Il est possible de supprimer les données de tous les secteurs en cliquant directement sur le
bouton de suppression. Toutefois, cette manipulation n’est conseillée que lorsque le fichier
de l’outil a été dupliqué et que la suppression des données est nécessaire pour
commencer un nouveau projet.
Les deux autres manières de sélectionner certains secteurs, vues dans la partie ci-dessus,
fonctionnent de la même manière pour la suppression :
-
La sélection d’un tronçon suivi d’un clic sur le bouton entraînera la suppression de
tous les secteurs situés sur ce tronçon, après validation d’un message d’alerte pour
confirmation de la perte définitive des données sélectionnées.
-
La sélection d’un tronçon, puis d’un secteur, suivi d’un clic sur le bouton entraînera la
suppression du secteur, après validation d’un message d’alerte pour confirmation de
la perte définitive des données sélectionnées.
II.5.1.C – MODIFICATION DES OBSERVATIONS
Le bouton ouvre le formulaire des observations ponctuelles pour modifications ou
suppressions des données existantes et ajouts de nouvelles.
Page 121
II.5.2 – MODIFICATIONS AUTRES
Seul le module de modification des listes déroulantes existe dans cette catégorie. Il a été créé
pour répondre aux besoins évolutifs des utilisateurs concernant les valeurs des listes de choix
proposées : la quasi-totalité des listes déroulantes de l’outil peuvent être modifiée.
II.6 – LE FORMULAIRE EDITER LES LISTES DEROULANTES
Ce formulaire se présente sous la forme suivante :
Figure 55: Formulaire Editer les listes déroulantes
Page 122
Un premier contrôle permet de choisir dans quel onglet se situe la liste déroulante à modifier.
En fonction du choix de celui-ci, le contrôle suivant vous proposera les différents paramètres
modifiables pour l’onglet choisi.
Après avoir pointé ces deux sélections, la feuille de données au centre du formulaire affichera
les différentes valeurs que contient la liste déroulante. Vous pourrez alors ajouter ou modifier
les valeurs existantes. Aucune ligne ne peut être supprimée dans ce module pour des raisons
de sécurité des tables dans lesquelles sont placées ces valeurs. Pour supprimer une valeur il
faut donc mettre une valeur nulle à la place de la valeur existante.
L’ajout d’une valeur doit se faire logiquement sur la ligne qui suit la dernière valeur non nulle
de la liste affichée par la feuille de données ou combler les éventuels trous de la liste laissés
par la suppression de valeurs.
II.7 – LE MODULE DE CONSULTATION DES DONNEES
Accessible à partir de n’importe quelle interface du programme via le bouton cicontre, ce module propose de visualiser et d’imprimer des fiches récapitulatives des
paramètres de certaines entités d’un cours d’eau suivant les objets qui le composent.
Figure 56: Formulaire de l'Interface de consultation des données existantes
Page 123
Plusieurs fiches peuvent être visualisées sur ce module : les fiches Secteur, avec les reportages
photos associés, les fiches ouvrage, plan d’eau et zone humide, que ces entités soient ou non
rattachées à un secteur.
La sélection de la visualisation des fiches se fait exactement de la même manière que la
modification d’un secteur existant dans le module de modification des données existantes (vu
dans la partie II.5.1.A – MODIFICATION D’UN SECTEUR EXISTANT).
Il est à noter toutefois que la visualisation des fiches secteur et des reportages photos (boutons
de la première ligne de ce formulaire) dépend des listes déroulantes situées à leur gauche.
RAPPEL
C’est dans ces fiches de rendu que les photos prises sur le terrain et renseignées dans la base
sont exploitées. Pour le bon fonctionnement de l’outil, vous devez avoir placé les photos
renseignées dans le dossier Photos de l’étude situé au même emplacement que l’outil luimême. Nous rappelons également que le nom des photos saisies est celui du fichier de la
photo avec son extension (ex : DSCF8263.JPG).
Page 124
Figure 57: Recto d'une fiche Secteur
La dernière ligne contient deux boutons permettant de visualiser les actions prévues sur les
objets des différentes entités rattachées ou non au secteur.
Figure 58: Actions triées par secteur et par objet d’entité
Page 125
II.8 – LE MODULE DES REQUETES DE SYNTHESE
Accessible à partir de n’importe quelle interface du programme via le bouton ci-contre,
ce module propose de visualiser des requêtes de synthèse relatives aux différents
paramètres, caractérisant les entités constituant les cours d’eau, à différentes échelles.
Figure 59: Formulaire de l'Interface de réalisation des requêtes de synthèse
Page 126
Figure 60: Requête sur la Densité arborée de l'entité Ripisylve à l'échelle de l'étude, du cours d'eau et du tronçon
Page 127
TABLE DES ILLUSTRATIONS
Figure 47: Schéma organisationnel des principaux liens entre les formulaires ..................... 110
Figure 48: Formulaire d'accueil.............................................................................................. 111
Figure 49:Formulaire de l'Interface de saisie des données .................................................... 113
Figure 50: Formulaire Secteur ................................................................................................ 115
Figure 51: Formulaire Action ................................................................................................. 117
Figure 52: Message d'information sur clic du bouton Supprimer .......................................... 118
Figure 53: Formulaire de l'Interface relative à l'édition des données existantes ................... 119
Figure 54: Barre de navigation ............................................................................................... 120
Figure 55: Formulaire Editer les listes déroulantes ............................................................... 122
Figure 56: Formulaire de l'Interface de consultation des données existantes ........................ 123
Figure 57: Recto d'une fiche Secteur...................................................................................... 125
Figure 58: Actions triées par secteur et par objet d’entité ...................................................... 125
Figure 59: Formulaire de l'Interface de réalisation des requêtes de synthèse ....................... 126
Figure 60: Requête sur la Densité arborée de l'entité Ripisylve à l'échelle de l'étude, du cours
d'eau et du tronçon.................................................................................................................. 127
Page 128
ANNEXE
Schéma organisationnel des principaux liens entre les formulaires
Page 129
ANNEXE 4 : GUIDE D’ADMINISTRATION
Sommaire
Préambule ............................................................................................................................... 131
Introduction ............................................................................................................................ 131
I – Les données de la base ...................................................................................................... 132
I.1 – Tableau récapitulatif des tables .................................................................................. 132
I.2 – Le dictionnaire de données ........................................................................................ 133
I.2.1 – Les tables de données .......................................................................................... 133
I.2.2 – Les tables Listing ................................................................................................ 141
I.2.3 – La liaison entre les tables de données et les tables listing .................................. 145
I.3 – Le modèle conceptuel de données ............................................................................. 145
II – Les formulaires ................................................................................................................ 148
II.1 – Hiérarchisation des formulaires ................................................................................ 148
II.2 – Liens existant entre les formulaires .......................................................................... 150
II.3 – La programmation des formulaires ........................................................................... 151
II.3.1 – Saisir/modifier deux enregistrements simultanément sur un formulaire unique .....
........................................................................................................................................ 152
II.3.2 –Source et Enregistrements du formulaire des actions définis suivant son ouverture
........................................................................................................................................ 154
III – Les états .......................................................................................................................... 157
Tables des illustrations ........................................................................................................... 158
130
PREAMBULE
Cet outil est une application, développée sous Microsoft Office Access, permettant
d’automatiser les opérations de saisie, de traitements et de restitution de données sur des
études spécifiques à la gestion de milieux naturels, principalement les cours d’eau.
La vocation de cet outil est de permettre l’élaboration de l’état des lieux, du diagnostic et du
programme d’actions relatif au milieu, en tenant compte de ces spécificités. Cette application
a aussi pour objectif d’homogénéiser le travail des chargés d’étude. Il doit remplacer les outils
déjà existants et permettre de répondre à un maximum de besoins des utilisateurs.
INTRODUCTION
L’objectif de ce document est de préciser les particularités techniques de l’outil dans le but de
poursuivre le travail entrepris, de le mettre à jour et de l’améliorer en fonction des besoins
évolutifs des utilisateurs de cet outil. Ce document s’adresse essentiellement à
l’administrateur de ce système de gestion de base de données et aux géomaticiens.
La première partie présente les données de la base à travers le dictionnaire de données,
suivant les différentes tables et les champs qui la caractérisent, et le MCD sur lequel est
construit l’outil.
La deuxième partie se penchera sur les relations qui existent entre les formulaires entre eux et
avec les éléments associés aux tables.
IL EST TRÈS IMPORTANT DE NOTER QUE LES OBJETS
ACCESS (tables, requêtes, formulaires et états) NE DOIVENT EN
AUCUN CAS ÊTRE RENOMMÉS, MODIFIÉS OU SUPPRIMÉS
SOUS PEINE D’ENTRAINER UN CERTAIN NOMBRE DE BUGS
DES PROGRAMMES LES UTILISANT.
131
I – LES DONNEES DE LA BASE
I.1 – TABLEAU RECAPITULATIF DES TABLES
Cet outil s’articule autour d’un certain nombre de tables. Elles peuvent être rangées en deux
catégories :
-
Les tables de données, dans lesquelles sont sauvegardées les données levées.
-
Les tables listing, dans lesquelles les valeurs des champs sont celles utilisées comme
suggestions pour le contenu des champs de type liste déroulante des tables de données.
Ainsi à la date du 02 Septembre 2011, la base de données se composait des tables suivantes :
Figure 61: Liste des tables de la base de données
132
I.2 – LE DICTIONNAIRE DE DONNEES
I.2.1 – LES TABLES DE DONNEES
133
134
135
136
137
138
139
Concernant la légende ce ces tables nous avons :
140
I.2.2 – LES TABLES LISTING
Afin que l’administration soit simple les champs des différentes tables listing portent le même
nom que leurs champs homologues dans les tables de données et les mêmes caractéristiques
(même type de données, même nombre de caractères autorisés…). De ce fait, les
caractéristiques ne seront pas détaillées dans cette partie.
141
142
143
Cette dernière table est un peu particulière car elle n’est pas associée à une table de données
mais directement aux deux contrôles (de type liste déroulante) présents sur le formulaire
f_EDTION_LISTING pour afficher certaines données. Les valeurs non nulles des
enregistrements de ces champs servent directement de valeurs dans les listes déroulantes de ce
formulaire.
144
I.2.3 – LA LIAISON ENTRE LES TABLES DE DONNEES ET LES TABLES LISTING
Pour lier les champs d’une table listing aux champs d’une table de données, il faut renseigner
les trois premières lignes de l’onglet Liste de choix de chacun des champs de la table de
données qui doit avoir une liste, sous Microsoft Office Access.
Figure 62: Exemple de liaison entre la table de données et le contenu de son contrôle de type liste déroulante
I.3 – LE MODELE CONCEPTUEL DE DONNEES
Le MCD est utilisé pour décrire de façon formelle, standardisée et schématique les données de
la base (tables, champs et relations) nécessaire à la résolution du problème de départ, sans
tenir compte du SGBD et du langage de programmation qui se grefferont autour par la suite
(aspect technique).
145
Figure 63: Modèle conceptuel de données
146
Ce modèle conceptuel de données se traduit sous Microsoft Access par les Relations,
accessibles dans l’onglet Outils de base de données.
Figure 64: Relations entre les tables de la base de données dans Microsoft Office Access
147
II – LES FORMULAIRES
II.1 – HIERARCHISATION DES FORMULAIRES
Cet outil comprend un certain nombre de formulaires : certains créés pour servir d’interface
aux différents modules proposés par l’outil, d’autres permettant de les réaliser.
Les formulaires reprennent les objets sur lesquelles ils prennent leur source. Seul le préfixe
change (t_ pour les tables, r_ pour les requêtes, f_ pour les formulaires et enfin e_ pour états).
Ainsi, par exemple, le formulaire f_Berge permet de renseigner les champs des objets à
enregistrer dans la table t_Berge.
Pour les formulaires dont le nom est inscrit en lettres majuscules, ils correspondent aux
principales fenêtres que comprend l’outil, soit celles que l’utilisateur pourra atteindre en
naviguant à travers l’application, soit les différents menus d’interface ou les formulaires de
saisie. Les formulaires portant un nom en lettres minuscules sont pour la plupart des sousformulaires utilisés pour les formulaires de saisie et de modifications (f_GENERAL et
f_OBSERVATIONS) ou sont des formulaires de moindre importance.
En plus de cette hiérarchisation des formulaires, ces derniers portent des noms explicites de
façon à être identifiés directement. On saura ainsi que les formulaires f_PE_obs et
f_Lmaj_requetes_synthese sont des sous-formulaires portant respectivement sur l’entité Plan
d’eau et Lit majeur dans les formulaires f_OBSERVATIONS et f_REQUETES_SYNTHESE.
148
Vous trouverez ci-dessous la liste des différents formulaires utilisés et présents dans l’outil en
date du 02 Septembre 2011 :
Figure 65: Formulaires présents dans le Système de gestion de base de données
Du fait du caractère explicite des noms donnés à ces formulaires, une description de ces
derniers n’a pas été jugée nécessaire.
149
II.2 – LIENS EXISTANT ENTRE LES FORMULAIRES
Ces différents formulaires sont liés entre eux dans la navigation par le biais de boutons, comme c’est le cas pour passer d’une interface à l’autre, ou par le fait qu’il existe une relation père-fils entre un formulaire et son
sous-formulaire à travers un champ commun.
Ainsi les principaux formulaires sont organisés et structurés de la façon suivante :
Figure 66: Schéma organisationnel des principaux liens entre les formulaires
Pour plus de détails sur l’utilisation de ces formulaires, je vous invite à lire le guide d’utilisation
150
II.3 – LA PROGRAMMATION DES FORMULAIRES
Sous Microsoft Office Access, la programmation des éléments d’un formulaire, ou d’un état,
se code dans un environnement de développement intégré au logiciel, dans une fenêtre
spécifique, en langage Visual Basic.
Il est l’un des langages de programmation les plus utilisés pour le développement rapide, car
il ne nécessite pas de performances critiques pour pouvoir faire fonctionner un programme.
Ce langage de programmation événementielle permet ainsi de configurer les actions des
composants d’un formulaire mais aussi d’en définir les propriétés. Elles ont l’avantage ici de
pouvoir changer en fonction de certains évènements. Ainsi les propriétés statiques mise en
place dans les propriétés du formulaire peuvent devenir dynamiques grâce à la programmation
en Visual Basic.
Afin d’aider l’administrateur de données à comprendre les diverse instructions réalisées, la
grande majorité du code a été commentée de façon à les « traduire » mais aussi à comprendre
les différentes lignes qu’elles contiennent et pourquoi elles sont utilisées.
Les parties qui suivent sont tirées du rapport de stage associé à la réalisation de cet outil et
permettent de comprendre les processus de création des codes les plus spécifiques créés pour
la bonne utilisation et administration de certaines données.
151
II.3.1 – SAISIR/MODIFIER
DEUX ENREGISTREMENTS SIMULTANEMENT SUR UN FORMULAIRE
UNIQUE
Un des objectifs que devait atteindre l’outil était de pouvoir saisir sur un même formulaire, les
paramètres des entités Lit majeur, Berge et Ripisylve en rive gauche et en rive droite
simultanément, paramètre par paramètre. Afin de pouvoir saisir les entités sur les deux rives
en même temps, il aurait fallu que le formulaire soit en mode d’affichage Feuille de données,
de manière à pouvoir naviguer d’une ligne à l’autre. Néanmoins cette solution n’était ni
pratique, ni esthétique. De plus ce mode d’affichage aurait rendu difficile le remplissage de
sous-formulaires. Une saisie sur formulaire unique a donc été choisie. Or ces formulaires ne
peuvent correspondre qu’à un enregistrement, mais il était nécessaire qu’ils en contiennent
deux : celui de la rive gauche et celui de la rive droite.
Pour ce faire il fallait créer sur le formulaire autant de contrôles que de paramètres à
renseigner, soit deux contrôles par paramètre (un pour la rive gauche et un pour la rive droite).
Mais contrairement aux autres sous-formulaires que peuvent contenir les formulaires de
saisie, ceux-ci ne sont pas liés aux champs d’une table par Access : ils sont indépendants.
En effet chaque contrôle indépendant que contiennent ces formulaires est codé pour afficher,
enregistrer et supprimer tel champ de tel enregistrement de telle table. Une programmation
pareille a été possible du fait que les éléments Lit majeur, Berge et Ripisylve contiennent un
nombre fixe d’enregistrements : un pour chacune des rives, soit deux.
Ainsi, une fois les différents contrôles des deux rives renseignées, le bouton Enregistrer du
formulaire devait sauvegarder les valeurs des paramètres de la rive gauche dans le premier
enregistrement et les informations de la rive droite dans le deuxième enregistrement en
spécifiant la correspondance de chaque contrôle avec le bon champ dans la table.
Cependant bien qu’étant enregistrées dans la table, à la réouverture de ce même formulaire,
les contrôles n’afficheraient aucune des valeurs saisies, puisque ces derniers sont
indépendants. Il fallait donc rajouter du code sur la procédure évènementielle d’activation du
formulaire. L’affichage de chacune des valeurs des différents contrôle des paramètres rive
gauche et rive droite devait être programmés en appelant les valeurs des champs des deux
enregistrements sauvegardés dans la table.
152
Quant à la suppression des données, le code était plus simple à rédiger. Il suffisait de
supprimer les enregistrements de la table relatifs au secteur sur lequel on saisit et de forcer
l’affichage des contrôles indépendants sur une valeur nulle.
Les possesseurs de la base de données et des droits administrateurs pourront visualiser ces
instructions dans le code Visual Basic des formulaires f_Lmineur, f_Lmajeur, f_Berge et
f_Ripisylve.
Figure 67: Liens des paramètres des deux rives avec les deux enregistrements dans la table associée
153
II.3.2 –SOURCE ET ENREGISTREMENTS DU FORMULAIRE DES ACTIONS DEFINIS SUIVANT SON
OUVERTURE
Les actions de chaque objet devaient être saisies depuis les enregistrements de ces derniers et
ne devaient afficher que les actions de l’objet en question, et de façon à ce que l’utilisateur
n’ait pas à renseigner l’identifiant de l’objet. Il fallait que cela soit automatique. Toutefois
dans le module de consultation de l’outil, l’utilisateur devait pouvoir voir la liste de toutes les
actions à réaliser, classées par secteur, puis par entité, de manière à avoir une vision organisée
des interventions suggérées.
Or les formulaires des différentes entités étaient déjà bien remplis et ne pouvaient accueillir
un nouveau sous-formulaire. Il fallait donc placer un bouton, dans chacun des onglets
représentant une entité, qui ouvrirait le formulaire des actions.
C’est pourquoi je voulais créer un formulaire Actions indépendant à l’origine, mais qui
lorsqu’il serait ouvert depuis l’enregistrement d’un objet d’une entité, n’afficherait et
n’enregistrerait les futures actions à saisir que de cet objet.
Ainsi il fallait donc que la source du formulaire des actions évolue en fonction du bouton
d’ouverture, selon que ce dernier soit sur le formulaire d’une entité ou sur une autre. De plus,
la source devait être une requête, de façon à pouvoir sélectionner juste l’enregistrement actif
de l’objet. Ces requêtes correspondent aux requêtes Access dont le nom commence par
« Action_RecordSource_ ». Les identifiants de l’objet et du secteur devraient ensuite être
récupérés dans l’enregistrement en question et saisis automatiquement dans les contrôles
appropriés du formulaire Actions lorsque l’utilisateur devra suggérer de nouvelles
interventions sur cet objet.
Le code source est disponible sur l’évènement « Sur clic » des boutons Action
des
formulaires et se poursuit sur le formulaire f_Action (évènement « Sur Ouverture », fonction
privée Action_Infos_Secteur_et_Entite et évènement « Après mise à jour » des contrôles).
154
L’ouverture du formulaire des actions devait être déclenchée sur le clic d’un bouton, placé
dans chacun des formulaires d’entités. Suivant l’entité, on attribuait de façon automatique la
source du formulaire des actions à son ouverture.
Pour réaliser ceci, j’ai donc créé une variable publique Bouton_Ouverture_f_Action (module
variables_publiques), utilisable dans tous les formulaires de la base, afin de lui attribuer une
valeur unique à chacune des entités des deux formulaires de saisie. Ainsi, lorsque l’utilisateur
clique sur le bouton pour déclencher l’ouverture du formulaire des actions, le bouton attribue
d’abord à cette variable publique une valeur propre à l’entité à partir de laquelle il appelle le
dit-formulaire.
Bouton Action du formulaire
Valeur de la variable publique associée
f_Lmineur
f_Lmajeur
f_Berge
f_Ripisylve
f_Ouvrage
f_Travaux_hydro
f_Embacle
f_Dechet
f_Pompage
f_Rejet
f_Pietinement
f_PE
f_ZH
f_Obs_autre
Lmineur_Secteur_Action
Lmajeur_Secteur_Action
Berge_Secteur_Action
Ripisylve_Secteur_Action
Ouvrage_Secteur_Action
TH_Secteur_Action
Embacle_Secteur_Action
Dechet_Secteur_Action
Pompage_Secteur_Action
Rejet_Secteur_Action
Pietinement_Secteur_Action
PE_Secteur_Action
ZH_Secteur_Action
Autre_Secteur_Action
f_Ouvrage_obs
f_Travaux_hydro_obs
f_Embacle_obs
f_Dechet_obs
f_Pompage_obs
f_Rejet_obs
f_Pietinement_obs
f_PE_obs
f_ZH_obs
f_Obs_autre_obs
Ouvrage_Observation_Action
TH_Observation_Action
Embacle_Observation_Action
Dechet_Observation_Action
Pompage_Observation_Action
Rejet_Observation_Action
Pietinement_Observation_Action
PE_Observation_Action
ZH_Observation_Action
Autre_Observation_Action
Ensuite, au moment de l’ouverture du formulaire Actions, le programme choisit le code
attribuant la source des enregistrements de ce formulaire qu’il faut déclencher suivant la
155
valeur qu’a prise la variable publique ; qui indique quelle entité est à l’origine de l’ouverture.
Cette source d’enregistrement correspond à un objet Access de type « Requête ». Il en existe
une pour chaque entité des formulaires de saisie. Arrivé à cette étape, le formulaire des
actions affiche maintenant les enregistrements des actions liés à l’objet actif du sousformulaire de l’entité du formulaire de saisie.
Il faut maintenant renseigner, s’ils sont vides, les contrôles des identifiants Entite_ID et
Secteur_ID du formulaire après tout renseignement des autres contrôles du formulaire. Ainsi,
après la mise à jour d’un contrôle, le programme exécute une requête SQL (dépendante de la
variable publique) qui sélectionne l’enregistrement du sous-formulaire de l’entité à partir de
laquelle le formulaire des actions a été ouvert. Il est à noter que cette opération est
complètement transparente pour l’utilisateur. L’enregistrement sélectionné, le programme
récupère alors les identifiants de l’objet et celui du secteur pour remplir les contrôles
(invisible pour l’utilisateur) qui requièrent ces informations.
Figure 68: Processus du codage des actions d'un objet d'une entité
156
Pour résumer, à chaque entité des deux formulaires de saisie est associée une valeur pour la
variable publique. Chaque valeur de cette variable permet :
-
d’attribuer ensuite la requête Access correspondante qui devient la source du
formulaire des actions.
-
de récupérer les identifiants de l’objet et du secteur pour remplir les contrôles du
formulaire Actions qui les demandent.
Toutefois, le codage n’était pas fini. Il fallait également prévoir le cas d’éventuelles mises à
jour des objets. Par exemple l’attribution d’un nouveau secteur pour un objet ou la
suppression des actions lorsque l’objet auquel il est lié doit être supprimé.
L’idée de n’avoir qu’un formulaire dont les éléments sont dépendants de cas (méthode Select
Case) avait d’abord été développée pour le module d’Edition des listes déroulantes, module
indispensable pour que les utilisateurs puissent mettre à jour eux même plus de 90% des listes
déroulantes que contiennent les formulaires de saisie. Comme son utilisation était très
pratique et que son administration était plutôt simple, le concept en a été repris pour l’adapter
au niveau du formulaire des actions, plus compliqué.
III – LES ETATS
La hiérarchisation des états a été réalisée sur le même principe que celle mise en place pour
les formulaires. L’outil comprend les états suivants en date du 02 Septembre 2011 :
Figure 69: Formulaires présents dans le Système de gestion de base de données
157
TABLES DES ILLUSTRATIONS
Figure 61: Liste des tables de la base de données .................................................................. 132
Figure 62: Exemple de liaison entre la table de données et le contenu de son contrôle de type
liste déroulante ....................................................................................................................... 145
Figure 63: Modèle conceptuel de données ............................................................................. 146
Figure 64: Relations entre les tables de la base de données dans Microsoft Office Access .. 147
Figure 65: Formulaires présents dans le Système de gestion de base de données ................. 149
Figure 66: Schéma organisationnel des principaux liens entre les formulaires ..................... 150
Figure 67: Liens des paramètres des deux rives avec les deux enregistrements dans la table
associée................................................................................................................................... 153
Figure 68: Processus du codage des actions d'un objet d'une entité ...................................... 156
Figure 69: Formulaires présents dans le Système de gestion de base de données ................. 157
158