Elaboration D'un Systeme D'inf - ABBADI Hanae - 1022
Elaboration D'un Systeme D'inf - ABBADI Hanae - 1022
Elaboration D'un Systeme D'inf - ABBADI Hanae - 1022
Présenté par:
ABBADI Hanae
Encadré par:
Mots clés: ABH de Sebou, Base de données spatiale, conception de BD, modélisation des données,
.open source, SIG WEB.
RESUME
SOMMAIRE
CHAPITRE I
INTRODUCTION GENERALE
I. INTRODUCTION ....................................................................................................
CHAPITRE II
DELIMITATION ET CARACTERISATION DU BASSIN VERSANT DE SEBOU
I- INTRODUCTION ...................................................................................
CHAPITRE III
CONCEPTION D'UNE BASE DE DONNEES HYDRIQUE
I. INTRODUCTION...................................................................................
CHAPITRE IV
CONCEPTION D'UN SIG WEB
I. INTRODUCTION ........................................................................................................................................ 68
II. IMPORTATION DE LA BASE DE DONNEES SEBOU DANS GEOSERVER ....................................... 68
1. Définition de la suite OpenGeo ................................................................................................................ 68
2. Présentation de GeoServer ....................................................................................................................... 70
3. Configuration et mise en place du GeoServer ..................................................Erreur ! Signet non défini.
4. L’ajout d’une base de données spatiale de postgis ...........................................Erreur ! Signet non défini.
III. CONCLUSION ................................................................................................Erreur ! Signet non défini.
CONCLUSION GENERALE
REFERENCES BIBLIOGRAPHIQUE
CHAPITRE I
INTRODUCTION GENERALE
I. INTRODUCTION
Au Maroc, la connaissance hydrogéologique est le fruit d’une grande diversité de travaux, qui résultent
de l’observation de terrains ou de mesures piézométriques et hydrodynamiques accumulés depuis près de 40 ans.
C’est pour tenir ces informations à jour et les rendre publiques qu’ont été créées des Agences de Bassin
Hydraulique (ABH). Depuis l’avènement des Systèmes d’Information Géographique (SIG), la plupart des ABH
ont investi dans la numérisation et la valorisation de l’information hydrogéologique collectée au cours d’études,
d’inventaires et de travaux divers. Cette évolution du support papier vers le support numérique a permi aux
sciences hydrogéologiques de s’appuyer sur les SIG pour l’interprétation et la mise à disposition des données
hydrogéologiques. Pour pouvoir utiliser efficacement ces informations, elles doivent à tout moment être
actualisées, compatibles entre elles et accessibles à un large public. Dans ce sens, les systèmes de gestion de
bases de données ont pour objectifs d’assurer un accès simple, permanent et avantageux de l’information à
caractère spatial.
C’est dans cette perspective que l’objectif de ce projet à été établi. Il vise la réalisation, la conception, la
modélisation et l’implémentation d’une base de données relationnelle spatiale, basée surtout sur la capacité
d’intégrer les solutions Open Source (OS). Ces capacités ne sont pas communément connues ou utilisées par les
chercheurs et les ingénieurs qui opèrent dans le domaine de la gestion des ressources en eaux au Maroc. C’est
dans cette optique que nous voulons mettre en exergue cette technologie très avancée.
II. PLAN DU TRAVAIL
Après cette courte introduction (chapitre I), nous présenterons dans le chapitre II la situation
géographique de notre zone d’étude qui est le bassin versant de Sebou, ainsi que ses caractéristiques socio-
économiques, géologique, hydrologique, hydrogéologique, et climatologique.
Le chapitre III, est consacré d’une part à la définition des systèmes de gestion de base de données
relationnelle qui constitue le cœur du système d’information, et pour la conception de ces bases de données qui
est la tâche la plus ardue du processus de développement du système d’information. La conception se réalise en
trois étapes principales qui correspondent à trois niveaux d’abstraction différents niveau conceptuel, niveau
logique relationnelle et le niveau physique ainsi que le passage du modèle conceptuel au modèle relationnel et
enfin du modèle relationnel au modèle physique et d’autre part pour:
La création d’une base de données spatiale vide « sebou » à l’aide du logiciel
PostgreSQL/PostGis
La conception de la base de données du bassin versant du Sebou par DBDesigner 4. Les
modèles créés par DBDesigner 4 sont stockés en XML. Pour importer ces modèles a notre
base de données « sebou » il faut convertir l’extension XML à SQL pour que PostgreSQL
puisse le compulser.
L’implémentation des données (.Shp) du bassin versant du Sebou dans la base de données
« Sebou » à l’aide de QGIS.
Visualisation de la base de données spatiale « Sebou » par un logiciel SIG tel que QGIS.
Le chapitre IV, est dédié à la conception d’un SIG WEB à partir d’une connexion entre la base de
données « sebou » et GeoServer qui permet la diffusion et modification et la visualisation des données
GeoSpatiales sur le web.
CHAPITRE II
DELIMITATION ET CARACTERISATION DU BASSIN VERSANT DE SEBOU
I- INTRODUCTION
Au Maroc, les eaux de surface représentent les trois quarts des ressources en eau, dont près de 25% sont
drainées par l’oued Sebou.
L’importance du réseau hydrographique du bassin de Sebou ainsi que les autres données de l’ABH de
Sebou ont emmené à réaliser une base de données relationnelle spatiale pour préserver ses informations.
II- DELIMITATION DU BASSIN VERSANT DE SEBOU
1- Situation géographique du bassin de Sebou
Le bassin de Sebou est l’un des plus grands bassins hydrauliques du Royaume. S’étendant sur une
superficie de 40.000km². Ce bassin se présente sous forme d’une cuvette limitée par le Rif au Nord, le Moyen
Atlas et la Meseta au Sud, le Couloir Fès-Taza à l’Est et par l’Océan Atlantique à l’Ouest (Fig.II-1).
Population rurale
1000000
900000 Population urbaine
800000
700000
habitants
600000
500000
400000
300000
200000
100000
0
El Hajeb
Meknès
Boulemane
Sidi Kacem
Taounate
Taza
Al Hoceima
Khemisset
Fès
Chefchaouen
Ifrane
Kénitra
My Yacoub
Khénifra
Sefrou
provinces
nationale), 184 500 tonnes de sucre produit (50% de la production nationale), 3.300 tonnes/jour de
pétrole raffiné (2004), etc. ;
• Le tourisme développé dans les villes impériales de Fès et Meknès en plus du potentiel des zones
montagneuses et celui offert par les sources thermales, les plages, etc. ;
• La forêt repartie sur une superficie de près de 1.200.000 ha constituée de chênes, de cèdres de thuya et
de matorral. En plus de son rôle parcours de pâturage et de gisement de bois de feu pour les populations
riveraines, la forêt participe de manière significative à la stabilisation des terres et par conséquent à la
réduction de l’érosion et de l’envasement des retenues de barrages.
3- Aspect géologique du bassin de Sebou
Le bassin de Sebou s’étend entre deux grandes unités géologiques :
- Le domaine rifain au Nord, représenté par une chaîne de collision alpine édifiée entre le Crétacé supérieur
et le Miocène supérieur ;
- Le domaine atlasique ou méséto-atlasique au Sud, représenté par la partie subtabulaire (causse) du Moyen
Atlas. Il s’agit dans l’ensemble d’une chaîne alpine de type intracontinentale.
3.1- Le Domaine rifain
Cette chaîne qui appartient au système des chaînes alpines de la méditerranée occidentale constitue la
branche méridionale de l’arc bético-rifain.
De forme arquée, la chaîne rifaine s’aligne parallèlement à la côte méditerranéenne et elle se prolonge
vers l’Est dans le Tell algérien avec lequel elle forme les Maghrébides (Frizon et al, 1991).
La chaîne est formée d'une pile de nappes charriées au Miocène vers le Sud et le Sud-Ouest dans le Rif
oriental, le Sud et l'Ouest dans le Rif occidental.
Classiquement, elle est subdivisée en trois unités structurales : Les zones internes, la zone des flyschs et
les zones externes.
3.2- Le Domaine méséto-atlasique (Causse Moyen Atlasique)
Le Causse moyen atlasique représente la zone subtabulaire de la chaîne du Moyen Atlas. Il est
essentiellement constitué d’un paysage classique de hauts plateaux calcaires, d’où l’appellation de causse, ce qui
implique tout un ensemble de conditions lithologiques, hydrologiques et morphologiques.
Il est constitué par des formations du Lias essentiellement de nature calcaire avec intercalations des
niveaux dolomitiques ou marneux (marnes de Boulemane du Lias supérieur) (ABHS, 2004). Ces formations
marno-calcaires du Lias reposent sur des dépôts triasiques constitués d’argiles rouges salifères et gypsifères avec
intercalations de basaltes doléritiques surmontant le socle paléozoïque schisto-gréseux qui affleure dans la partie
occidentale du causse.
Les formations du Mio-pliocène sont essentiellement de nature marneuse et/ou sableuse. Enfin, les
formations superficielles d’âge quaternaire sont composées de couches argileuses issues de la décomposition des
calcaires et des dolomies.
3.3- Le couloir sud rifain
C’est une zone de subsidence continue qui s’est installée suite à l’effondrement d’un socle primaire
mésétien recouvert par des formations triasico-liasiques. Le couloir sud rifain est allongé suivant une direction
Est-Ouest, de l’Atlantique jusqu’à la plaine d’Oujda. La mer tortonienne a déposé d’épaisses séries de marnes
(épaisseur de 2000 m environ) sur des formations de faciès transgressifs du Miocène moyen-supérieur. Ces
faciès sont surmontés par des dépôts fluvio-lacustres du Pliocène supérieur (Ahmamou, 1987) contenant des
lumachelles et des conglomérats au Nord, des sables jaunes à l’Est et des sables et grès coquilliers au Sud-est et
des dépôts de nature variée (conglomérats, travertins, etc.) du Quaternaire.
4- Aspect hydrologique du bassin de Sebou
Le bassin du Sebou est marqué par un contexte géomorphologique et climatique très diversifié et
renferme près du tiers des eaux de surface du royaume. Ce bassin se caractérise par un réseau hydrographique
représenté principalement par l’oued Sebou et ses affluents.
L’oued Sebou prend sa source, sous l’appellation d’oued Guigou, dans le Moyen Atlas à 2100 m
d’altitude. Il sillonne une longueur d’environ 500 km avant d’atteindre son exutoire dans l’océan atlantique à
Mehdia prés de Kénitra drainant ainsi une superficie voisine de 40 000 km2. Le long de son parcours, l’oued
Sebou intercepte plusieurs affluents venus de régions contrastées dont les plus importants sont l’oued Ouergha
dans le Rif, l’oued Inaouene deuxième affluent principal du Sebou après l'Ouergha, qui coule suivant une
direction est-ouest, le long du couloir sud-rifain et l’oued Lebene dans le couloir de Taza au contact du Rif et du
Moyen Atlas ainsi que les oueds Beht et Rdom issus du plateau central.
Le bassin du Sebou produit prés du tiers des eaux de surface du Maroc. Il peut être
subdivisé, du point de vue hydrologique, en quatre ensembles (Fig.II-5) :
• Le haut et le moyen Sebou : ces deux affluents drainent respectivement des superficies voisines de 6000
2 2
km et 5400 km .
• L’oued Ouergha contrôle un bassin versant d’une superficie de l’ordre de 7300 km2.
• Le Beht rejoint le Sebou dans la plaine du Gharb. Ce cours d’eau draine un bassin versant d’environ 9000
km². Parmi les affluents les plus importants du Beht figure l’oued R’dom.
• l’Inaouène et l'oued Lebene viennent de la région de Taza, au contact des domaines moyen-atlasique et
prérifain. Ces affluents contrôlent des superficies respectives de 3400 km2 et 1200 km2 environ.
ta
ou
OUER
INAOUE OUER
INAOUE
r
u
ha
er
Haut
OUERGHA
INAOUENE
et Moyen Sebou
bL
z
lo
Ouergha Inaouene - Lben
de
as
ua
fa
Ba
GHA
NE GHA
NE
M
As
Ma
To
Lah Guigou
dar
PMH
Mdez
Touahar Bab Louta
Asfalou
u
bo
Taza
dA
AEP
Si
Mikkes
Zlo
PMH Inaouene Amont PMH ul
Sra Bouhouda
es
ikk
Sidi Abou Saiss
M
Asfalou - Bouhouda PMH AEP PMH
AEP Haut Ouergha
Sa Sahla PMH Matmata
hla
Vallée ouergha Sidi Chahed
Lben
Idriss 1er Allal Fassi
A
m
AEP
za ou
Inaouene
z
A
PMH
Ao
la
ud PMH
i
GH
MIKKES
Beht
ht
Gharb Canal G PMH Moyen Sebou Aval
Be
Moyen Sebou
AEP
Irrigation - Transfert PMH
AEP
INAOUE
Bas Sebou
NE Al Kansra
R
'd
at
AEP
(Khémisset-Tiflet)
GH (Sidi Slimane)
Liaison Sebou-Beht
GH (Gharb)
Plus de 40 stations de
um
do
R'
Irrigation - Transfert
AEP
4.1- Le Débit
Le débit de la rivière Sebou est influencé par plusieurs barrages : 10 grands barrages
(y compris le barrage de garde) et 45 petits ou moyens (lacs collinaires). Ces barrages ont été
érigés pour des raisons diverses : irrigation (périmètres du Gharb et du Beht), alimentation en
eau potable, production d’énergie électrique, protection contre les inondations, contrôle des
intrusions salines, prélèvements au fil de l’eau etc.
Spatialement, les débits spécifiques (débits moyen inter–annuels par unité de surface du bassin versant)
et les coefficients de ruissellement (rapport entre les écoulements annuels moyens, mesurés en mm, et les
précipitations annuelles moyennes) sont très variables.
Ainsi, le débit spécifique est de 1l/s/km2 d'environ au niveau du Haut Sebou, oued Mikkès et du Bas
Sebou, de 3 à 4 l/s/km2 au niveau du bassin des oueds Inaouène-Lebene et de 10 à 15 l/s/km2 dans le bassin de
l'oued Ouergha. Quant aux coefficients de ruissellement, les valeurs calculées sont de 10 % environ en Haut et
Moyen Sebou, de l'ordre de 20 % sur les oueds Inaouène, Lebene, Beth et Bas Sebou, et de 40 % environ au
niveau de l'oued Ouergha.
Toutefois, on souligne que les déficits d'écoulements sont beaucoup plus stables spatialement et se
situent entre 450 et 600 mm environ alors que les coefficients d'écoulements sont compris entre 1 à 4 (10 % à 40
%) pour des écoulements (exprimés en mm) de 40 à 400 mm.
Les apports saisonniers s’opèrent entre juin et novembre et représentent (selon les sous bassins) 10 et 20
% du total des apports annuels.
Les apports interannuels varient considérablement dans le bassin de Sebou. Le tableau I-1 donne, sur les
périodes de référence 1939/2002 et 1973/2002, les débits et apports moyens interannuels pour chacun des grands
sous bassins de la zone d’étude.
Une diminution de près de 2,3 milliards de mètres cubes des apports moyens annuels (soit 39% environ)
est constatée entre les deux périodes de référence 1939-1973 et 1973-2002. A ces valeurs, il faut ajouter les
apports moyens de 126.5 Mm3/an environ pour la série d’année 1939-1973 et de 70 Mm3/an pour la période
1973-2002 qui correspondent aux apports des affluents de la rive gauche du Sebou qui descendent de la région
de Tiflet. Ces apports englobent les écoulements péri-urbains de la ville de Kénitra et débouchent dans l’oued
Sebou ou l’oued Beth. Les apports des oueds M'Da (mesuré au niveau de la station de Moulay Ali Cherif) et
Dradère (mesuré au niveau de la station de Lalla Mimouna) sont respectivement de 0,70 m3/s et 1,26 m3/s sur la
période 1973-2002 contre 1.26 et 1.52 m3/s pour la période 1939-1973 ; soient des taux de réduction respectifs
de 44% et 17%.
4.2- La Qualité
Les cours d'eau situés à l'aval immédiat des villes et centres du bassin de Sebou constituent les
collecteurs des rejets des eaux domestiques et industrielles et présentent des eaux de mauvaise à très mauvaise
qualité. La dégradation par la pollution domestique et industrielle de la qualité des eaux de surface est mise en
évidence dans :
• L’oued Sebou notamment à l'aval de la ville de Fès ;
• L’Oued Rdom à l'aval des villes de Meknès et de Sidi Kacem ;
• L’Oued Beht à l'aval de Sidi Slimane jusqu’à l’embouchure.
Dans l’ensemble, et dans l’état actuel de connaissance, 25% des points de contrôle de la qualité des
eaux de surface relevant du réseau de l’ABHS sont de très mauvaise qualité, 22% de mauvaise qualité, 16% de
moyenne qualité, 31% de bonne qualité et seulement 6% d’excellente qualité (ABHS, 2006a). La figure II-6
illustre le degré de contamination et de dégradation de la qualité des eaux de surface dans le bassin de Sebou et
met en évidence la qualité moyenne à bonne des eaux dans le haut Sebou. Par opposition, les eaux du moyen et
bas Sebou sont dans l’ensemble de moyenne à très mauvaise qualité. Par conséquence, et pour améliorer la
qualité de l’eau de l'oued Sebou, des lâchers d'eau à partir des barrages Al Wahda, Idriss Ier et Allal El Fassi sont
effectués. A titre d'exemple, le volume d'eau lâché en 2003 est estimé à 22,5 Mm3 environ.
Fig.II-6- Carte de la qualité des eaux de surface dans le bassin de Sebou (ABHS, 2004)
Fig.II-7– Carte de la répartition des nappes aquifères dans le bassin hydraulique du Sebou (ABHS, 2007)
5.1- Les nappes du domaine prérifain
Le domaine prérifain est dépourvu de système aquifère d’importance régionale en raison de la nature
géologique des formations essentiellement marneuses. En effet, la plupart des formations géologiques de ce
domaine se comportent globalement comme un imperméable ou semi-perméable. D’autre part, les effets cumulés
de la tectonique n’ont pas favorisé la conservation et la structuration de terrains perméables en unités de grandes
extensions permettant l’accumulation des eaux pluviales.
Ce domaine correspond géologiquement au domaine des nappes de charriage d’Ouazzane et des nappes
prérifaines. La nappe d’Ouazzane est formée par des terrains allant du Crétacé terminal au Tortonien inférieur
tandis que la nappe prérifaine proprement dite est constituée d’une masse plastique constituée de formations
d’âge Triasico-Crétacé.
Les formations crétacées sont souvent à intercalations de bancs calcaires diaclasés dans lesquelles se
font la circulation des eaux souterraines et leur accumulation au contact des séries marneuses. L’aquifère crétacé
constitue un aquifère d’importance hydraulique très locale.
Les séries post de nappes gréseuses, marno-grèseuses et conglomératiques du Mio-pliocène constituent
une unité hydrogéologique dont l’importance est limitée par sa faible extension latérale.
Dans le complexe aquifère de Gharb on distingue deux niveaux aquifères distincts : aquifère profond et
aquifère supérieur.
L’aquifère supérieur est constitué par des formations plio-quaternaires essentiellement limono-sableuses
avec quelques intercalations argileuses. Ce sont ces dernières qui séparent l’aquifère supérieur de l’aquifère
profond.
L’aquifère profond, captif vers le centre du bassin, est constitué de formations détritiques plio-
villafranchiennes. Ces formations affleurent en bordure du bassin d’où l’aquifère reçoit son alimentation.
Le substratum général de ce complexe aquifère est constitué par le toit de l’épaisse série marneuse mio-
pliocène dite communément des « marnes bleues ».
L’alimentation de la nappe se fait essentiellement par l’infiltration des eaux des précipitations, le retour
des eaux d’irrigation, le déversement de la nappe de la Maâmora et les apports des oueds.
5.2.2- Le complexe des nappes de Maâmora
L’étude géologique de la nappe de Maâmora à travers les analyses des coupes des forages montre une
succession de marnes du Mio-pliocène communément appelées marnes bleues surmontées par des sables et grès
avec une intercalation de calcaire marin du pliocène, le tout d’une épaisseur de 30m environ. L’ensemble est
coiffé par des cailloutis à ciment sablo-argileux du villafranchien supérieur avec une profondeur allant jusqu’à
100 m et des sables de la Maâmora datant du Quaternaire récent avec une épaisseur variant entre 2 et 7m.
L’épaisseur de la nappe est variable cependant elle peut être évaluée à 50 m sur une extension d’environ
2
1000 km .
Les profondeurs de la nappe peuvent être subdivisées en deux tranches, une tranche avec des
profondeurs variant entre 0 et 40 m qui représente la grande majorité de la nappe.
L’autre tranche, avec des profondeurs supérieures à 40 m se situe de manière générale dans la partie
Sud-Ouest de la Maâmora où on note une protubérance avec des profondeurs atteignant 100 m.
Elle est constituée d’un niveau aquifère plus varié que celui de la plaine de Meknès, on peut y distinguer
:
Une épaisse couche de calcaire lacustre du Pliocène à l’Ouest, qui passe latéralement à l’Est et au Nord
à des conglomérats qui reposent directement sur les marnes miocènes à l’Est de la ville de Fès.
Au Nord, s’étend sur une épaisseur de 120 m au niveau de Douyet, un aquifère constitué par une série
de calcaires lacustres reposants sur les sables fauves et les conglomérats. Ces calcaires lacustres se présentent en
deux niveaux, calcaires beiges inférieurs (Saïs inférieur) et calcaires gris supérieurs (Saïs supérieur), séparés par
un horizon d’argiles noires de faible épaisseur.
Cependant la nappe peut s’écouler localement dans les fissures de basaltes quaternaires (Oued Bitit) ou
dans les massifs de travertin (ancienne Médina).
6.1- Pluviométrie
D’une manière générale, l’évolution des précipitations dans le bassin de Sebou se caractérise par une
forte variabilité spatio-temporelle. Dans l’objectif est de caractériser le régime pluviométrique de la zone
d’étude, on a fait appel aux données disponibles au niveau de 6 stations météorologiques situées dans la zone
d’action de l’ABHS dont deux se situent sur le causse moyen atlasique (stations de Sefrou et Ifrane), alors que
d’autres stations appartenant au Haut Sebou vont être étudiées dans la partie climatologique du bassin versant du
Haut Sebou.
1000,0 903,1
900,0
précipitations (mm)
800,0
700,0
550,0
600,0 473,0
455,2 475,4
500,0 407,1
400,0
300,0
200,0
100,0
0,0
Aïn Bitit
Aéroport
Sefrou
Ifrane
Meknès
Fès DRH
Fès Saïs
stations
L’examen des données du graphique ci-dessus montre que les valeurs annuelles des précipitations se
situent entre 400 et 900 mm/an et met en évidence l’influence manifeste de l’altitude qui se traduit par la valeur
de 900 mm/an enregistrée au niveau de la station d’Ifrane située dans le causse moyen atlasique. Cette influence
se fait sentir, aussi, au niveau du nombre de jours de pluies par année : 100 jours en montagne contre 60-70 jours
en plaine.
L’examen de l’évolution spatiale de la carte des pluies établie par l’ABHS (2006b) pour la période de
1973-2002 a permis d’identifier 4 zones de pluviométries homogènes (Fig.II-10) :
• 1000 à 1500 mm/an sur les reliefs du Rif ;
• 700 à 900 mm/an sur le Moyen Atlas ;
• 500 à 600 mm/an sur la zone côtière ;
• 400 à 550 mm/an sur le Haut et Moyen Sebou.
Fig.II-10- Carte de répartition spatiale des pluies dans le bassin de Sebou période
1973-2002 (ABHS, 2006b).
L’examen de l’évolution interannuelle des pluies montre que les précipitations annuelles enregistrées
sur la période de 1973-2002 dans les six stations du bassin fluctuent entre 300 et 600 mm/an autour d’une
moyenne de 450 mm/an (Fig.II-11). Cette moyenne est beaucoup plus grande dans la station d’Ifrane où les
pluies enregistrées durant la période 1978-2003 fluctuent entre 1691 et 550mm/an autour d’une moyenne de 900
mm/an.
Cependant, les deux dernières décennies ont connu une réduction très importante des précipitations sur
le bassin du Sebou comme par ailleurs dans le reste du territoire marocain avec la succession de séries d’années
sèches interrompues par de courtes séries d’années pluvieuses.
A l’instar de ces résultats comme partout dans le Maroc, l’irrégularité des précipitations dans le bassin
de Sebou est marquée par une nette diminution des apports d’eau au cours des deux dernières décennies. La
variation des apports en eau des pluies entre 1963-1994 et qui en 1963 étaient de 13000 Mm3/an pour se réduire
à 514mm3/an en 1994 avec une moyenne de 4800 Mm3/an (ABHS, 2006b).
précipitations en mm
Meknès Aéroport
120,0
Fès Saïs
100,0 Sefrou
80,0 Ifrane
60,0
40,0
20,0
0,0
Sept Oct. Nov Déc Jan Fév Mars Avr Mai Juin Juil Août
mois
A l’échelle intra-annuelle, deux saisons caractéristiques marquent la répartition des précipitations : une
saison humide qui s’étend entre octobre-mai et une saison sèche qui s’étale entre juin-septembre. Les apports en
pluies enregistrés durant la saison humide constituent 90 % environ des apports annuels.
Dans les 6 Stations, les tendances évolutives intra-annuelles des pluies entre 1978 et 2003 sont presque
similaires (Fig.II-12). Pendant la saison humide, les précipitations sont comprises entre 40 et 84 mm/mois et
particulièrement de 74 à 119 mm/mois dans la station d’Ifrane. Par opposition, les pluies enregistrées durant la
saison sèche tournent généralement aux alentours de 1mm/mois en août et de 9 à36 mm/mois en mois de
septembre.
6.2- Température
Dans le bassin du Sebou, l’évolution de la température présente de très importantes variations
saisonnières. En hiver, les moyennes mensuelles des températures peuvent enregistrer des valeurs de 11°C tandis
que les moyennes estivales sont souvent de l’ordre de 26°C (ABHS, 2006).
L’examen détaillé de la variation des moyennes des températures mensuelles, fournies par l’ABHS,
révèle que les températures s’élèvent graduellement à partir du mois de Janvier pour prendre au mois de juin un
caractère franchement estival. Les températures atteignent leur maximum aux mois de juillet et août avec des
températures diurnes très souvent élevées.
A partir de mi-septembre, les températures s’abaissent nettement jusqu’aux minima de décembre-
janvier. En revanche, les températures sont peu variables d’une année à l’autre.
Spatialement, les données de température moyenne relatives à 22 stations ont servi pour l’élaboration
d’une carte de température moyenne du bassin de Sebou (Fig.II-13) et mettent en évidence l’existence d’un
gradient thermique légèrement croissant du Nord vers le Sud. Cette tendance évolutive est influencée par la
topographie de la zone d’étude. Toutefois, il importe de souligner que les stations utilisées ne couvrent pas
certaines zones, particulièrement les régions montagneuses.
L’analyse de la variation des températures moyennes annuelles par sous bassin versant élémentaire de
Sebou montre que la plus grande valeur de température moyenne est enregistrée au niveau de Inaouene-Lebene,
soit 19,25°C, et qui passe à 18,81°C au niveau du bassin de Ouergha et enregistre la plus faible valeur de 13°C
environ au niveau du bassin de Beth
6.3- Evapotranspiration
L’évapotranspiration est un phénomène très important dans toute étude de ressource en eau à cause de
son implication dans les processus de cycle de l’eau. C’est le phénomène de montée de vapeur d’eau du sol vers
l’atmosphère par évaporation directe et par transpiration des plantes.
Pour estimer l’évapotranspiration dans le bassin de Sebou on a pris le cas de la station de Fès-Saïs. Les
valeurs de l’évapotranspiration potentielle mensuelle estimée par la méthode de Thornthwaite dans cette station
pour la période 1974-2003 sont données par la figure II-14.
L’ETP calculée varie très considérablement selon les mois et se situe entre 21,6 et 128 mm/mois
respectivement pour les mois de janvier et de juillet-août avec une moyenne de 65 mm/mois.
CHAPITRE III
CONCEPTION D'UNE BASE DE DONNEES HYDRIQUE
I. INTRODUCTION
Le monde réel est trop complexe pour notre compréhension immédiate et directe. C'est
pourquoi nous créons des «modèles» de la réalité qui sont destinés à avoir une certaine similitude
avec certains aspects du monde réel. Les bases de données sont créées à partir de ces «modèles»
comme une étape fondamentale pour arriver à connaître la nature et le statut de cette réalité.
Une base de données est un modèle de la réalité au sens où la base de données représente
un ensemble sélectionné ou se rapprochant des phénomènes. Ces phénomènes sélectionnés sont
réputés suffisamment important pour être représenté sous forme numérique. La représentation
numérique pourrait être pour certaines périodes passé, actuelle ou future (ou contiennent une
combinaison de plusieurs périodes d'une manière organisée).
II. CONCEPT DE BASE DE DONNEES
1. Notions des bases de données
Une base de données (BD), ou en anglais, database DB est une entité dans laquelle il est possible de
stocker des données de façon structurée et avec le moins de redondance possible. Ces données doivent pouvoir
être utilisées par des programmes, par des utilisateurs différents. Ainsi, la notion de base de données est
généralement couplée à celle de réseau, afin de pouvoir mettre en commun ces informations, d'où le nom de
base. On parle généralement de système d'information pour désigner toute la structure regroupant les moyens
mis en place pour pouvoir partager des données (BRASSEUR, 2008).
ces derniers. Cela est d'autant plus utile que les données informatiques sont de plus en plus
nombreuses (CALOZ, 1993).
Une base de données peut être locale, c'est-à-dire utilisable sur une machine par un
utilisateur, ou bien répartie, c'est-à-dire que les informations sont stockées sur des machines
distantes et accessibles par réseau.
Exhaustivité : implique que l'on dispose de toutes les informations relatives au sujet
donné.
La non redondance : implique l'unicité des informations dans la base de données .En
général on essaie d'éviter la duplication des données car cela pose des problèmes de
cohérence lors des mises à jour de ces donnes.
manipuler les données présentes dans la base de données (insertion, suppression, modification)
Plus précisément, les systèmes de gestion de bases de données (SGBD) sont des programmes permettant
à l’utilisateur de créer et de gérer des bases de données. Les SGBD sont des logiciels à usage général qui
assurent les processus de définition, de construction, de manipulation et de partage des bases de données par et
entre les différents utilisateurs et applications (CORNUEJOLS, 2010).
Le SGBD peut se décomposer en trois sous-systèmes:
système de gestion de fichiers : permet le stockage des informations sur un support physique
le SGBD interne : gère l'ordonnancement des informations
Fig.III-2-Composition de SGBD
D'une manière générale un SGBD doit avoir les caractéristiques suivantes (Olivier, 2009):
Indépendance physique : le niveau physique peut être modifié indépendamment du
niveau conceptuel. Cela signifie que tous les aspects matériels de la base de données
n'apparaissent pas pour l'utilisateur, il s'agit simplement d'une structure transparente de
représentation des informations
Indépendance logique : le niveau conceptuel doit pouvoir être modifié sans remettre en
cause le niveau physique, c'est-à-dire que l'administrateur de la base doit pouvoir la
faire évoluer sans que cela gêne les utilisateurs
A la fin des années 90 les bases relationnelles sont les bases de données les plus
répandues (environ trois quarts des bases de données), car le SGBDR (Système de gestion de
bases de données relationnelles) est simple ce qui le rend attractif pour les utilisateurs
puisqu’il est facile a comprendre et a manipuler.
Cardinalité 1-n: un produit peut être stocké dans plusieurs dépôts mais où chaque dépôt ne
contient qu’un type de produit, ou inversement.
Cardinalité m-n: un type de produit peut être stocké en plusieurs dépôts et un dépôt donné peut
contenir plusieurs types de produits.
Pour les relations ternaires, les cardinalités possibles sont : 1-1-1, 1-1-n, 1-m-n, et m-n-p.
Les cardinalités ci-dessus traduisent les contraintes propres aux entités et relations.
Elles sont appelées cardinalités maximales dans la mesure où elles représentent le nombre
maximum de participations d’une entité à une relation, En revanche, la cardinalité
minimale est le nombre minimal de participations d’une entité à une relation. La cardinalité
minimale peut être 0 ou 1.
Les cardinalités maximales et minimales traduisent les contraintes propres aux entités
et relations.
Il y a deux différentes notions de cardinalité :
l’approche anglo-saxonne met l’accent sur le nombre de correspondant d’une entité au sein d’une
relation ;
l’approche française (Merise) définit la cardinalité comme le nombre de participations de l’entité à la
relation.
Pour les relations binaires, cette différence de vision n’a pas de conséquence sur le modèle conceptuel
obtenu, elle modifie simplement la convention de représentation de ces cardinalités. En revanche, pour les
relations ternaires ou plus, il existe une réelle différence entre les approches.
Contrainte de clé : définit un sous-ensemble minimal des colonnes tel que la table ne puisse
contenir deux lignes ayant mêmes valeurs pour ces colonnes.
Il existe trois types de clés:
Clé primaire : Ensemble minimum d'attributs qui permet de distinguer chaque n-uplet de la table par
rapport à tous les autres. Chaque table doit avoir une clé primaire.
Clé candidate : Ensemble minimum d'attributs susceptibles de jouer le rôle de la clé primaire.
Clé étrangère : fait référence à la clé primaire d'une autre table.
Contrainte obligatoire : précise qu’un attribut ou plusieurs attributs doivent toujours avoir une
valeur.
Contrainte d’intégrité référentielle ou d’inclusion: lie deux colonnes ou deux ensembles de
colonnes de deux tables différentes.
3.2.2 Dépendance fonctionnelle
Introduite par Codd en 1970, la notion de dépendance fonctionnelle (DF) permet de caractériser des
relations qui peuvent être décomposée sans perte d'information. Sa formalisation mathématique découle de
l'observation des rôles de cardinalité simple (au plus égale à 1). Intuitivement, une DF traduit le fait que les
valeurs de certains attributs sont nécessairement déterminées (fixées) lorsque le sont celles d'autres attributs
(GRUAU, 2006).
Une propriété remarquable des clés d'identification est que, justement, tout attribut non-clé dépend
fonctionnellement de la clé, puisque celle-ci identifie chaque tuple de manière unique.
3.2.3 La théorie de la normalisation
La théorie de la normalisation est l’un des points forts du modèle relationnel. Elle permet de définir
formellement la qualité des tables au regard du problème posé par la redondance des données. En effet, une
mauvaise conception d’un schéma relationnel peut entraîner une redondance des données, voir une perte
d’information. Cette redondance peut entraîner des anomalies lors d’opération de mise à jour des données.
Afin d'éliminer les divers types de dépendances, et donc éviter les anomalies de mutation, on applique
un processus de normalisation (GRUAU, 2006) sur les différentes relations de la base.
Codd et Boyce en 1970 ont défini un ensemble de formes normales caractérisant les tables
relationnelles :
Première forme normale (notée 1FN) : si elle ne contient que des attributs atomiques (et non
des ensembles, types énumérés ou listes). Tout attribut d'une relation 1FN doit donc être
monovalué.
La 1FN permet d'éliminer les domaines composés.
Pour normaliser une table à la 1FN, il suffit de créer un tuple distinct pour chaque valeur de
l'attribut multivalué. Cela introduit des redondances, mais la deuxième forme normale permet d'y
remédier.
Deuxième forme normale (2FN) : si elle est en 1FN et, si de plus, il n’existe pas de dépendance
fonctionnelle entre une partie d’une clé et une colonne non clé de la table.
La 2FN garantit qu'aucun attribut n'est déterminé seulement par une partie de la clé. Pour
normaliser à la 2FN une table possédant une clé composée, il faut décomposer celle-ci en :
- une table formée des attributs dépendants d'une partie de la clé, et de cette partie même.
Troisième forme normale (3FN) : si elle est en 2FN et si, de plus, tout attribut non-clé ne
dépend pas transitivement de la clé (ou, autrement dit, si tout attribut non-clé ne dépend pas
fonctionnellement d'un attribut non-clé).
La 3FN permet d'éliminer les redondances dues aux dépendances transitives.
Pour normaliser à la 3FN une table possédant une dépendance transitive, il faut décomposer
celle-ci en :
- une table formée de l'attribut redondant et de l'attribut dont il dépend (nommé ici X); ce
dernier devient la clé de la nouvelle table
- une seconde table formée de la clé, de l'attribut X comme clé étrangère, et des autres attributs
Les formes normales 2FN et 3FN assurent l'élimination des redondances parmi les attributs non-clé,
mais pas les redondances potentielles au sein d'attributs formant une clé composite. C'est pourquoi Boyce et
Codd ont proposé une extension de la 3FN.
Ainsi, plus une table est normalisée moins elle comporte de redondances et donc de risques
d’incohérence sémantiques dans les schémas relationnels.
3.2.4 Règles de passage au modèle relationnel
Les règles principales de transformation d’un schéma conceptuel entité-relation en un schéma
relationnel (GRUAU, 2006) sont :
Règle I : Chaque entité est traduite en une table distincte, dont la clé primaire peut être soit celle de l'entité, soit
une autre clé candidate. Les autres attributs de l'entité sont reportés comme attributs de la nouvelle table.
Règle II : une association binaire de type n : m devient une table supplémentaire (parfois appelée table de
jonction, table de jointure ou table d'association) dont la clé primaire est composée de deux clés étrangères (qui
référencent les deux clés primaires des deux tables en association). Les attributs de l'association deviennent des
colonnes de cette nouvelle table.
Une contrainte d’intégrité référentielle est générée entre chaque colonne clé de la nouvelle table et la table
d’origine de cette clé.
Règle III : Toute relation binaire 1 : n est traduite :
1. Soit par un report de clé : l’identifiant de l’entité participant à la relation côté N est ajoutée comme
colonne supplémentaire à la table représentant l’autre entité. Cette colonne est parfois appelée clé
étrangère. Le cas échéant, les attributs spécifiques à la relation sont eux aussi ajoutés à la même table ;
2. soit par une table spécifique dont les caractéristiques sont les suivantes :
• le nom de la table est le nom de la relation ;
• la clé de la table est l’identifiant de l’entité participent à la relation côté 1 ;
• les attributs spécifiques de la relation forment les autres colonnes de la table.
Règle IV : Toute relation binaire de type 1 : 1 est traduite, au choix, par l’une des trois solutions suivantes :
Fusion des tables des entités qu’elle relie (choix1) ;
Report de clé d’une table dans l’autre (choix2) ;
Création d’une table spécifique reliant les clés des deux entités (choix3).
Les attributs spécifiques de cette relation sont ajoutés à la table résultant de la fusion (choix1), reportés avec la
clé (choix2), ou insérés dans la table spécifique (choix3).
Règle V : une association non binaire est traduite par une table supplémentaire dont la clé primaire est composée
d'autant de clés étrangères que d'entités en association. Les attributs de l'association deviennent des colonnes de
cette nouvelle table.
3.3 Modèle physique de données MPD (troisième niveau du processus d’abstraction)
Un modèle physique de données est l'implémentation particulière du modèle logique de données par un
logiciel.
La traduction d'un MLD conduit à un MPD qui précise notamment le stockage de chaque donnée à
travers son type et sa taille (en octets ou en bits). Cette traduction est également l'occasion d'un certain nombre
de libertés prises par rapport aux règles de normalisation afin d'optimiser les performances du système
d'information.
La traduction d'un MLD relationnel en un modèle physique est la création (par des requêtes SQL de
type CREATE TABLE et ADD CONSTRAINT) d'une base de données hébergée par un SGBD relationnel
particulier. Il peut s'agir d'une base Oracle, d'une base SQL Server, d'une base Access ou d'une base PostgreSQL,
par exemple. Le fait que tous les SGBDR reposent sur le même modèle logique (le schéma relationnel) permet à
la fois la communication entre des bases hétérogènes et la conversion d'une base de données d'une SGBDR à
l'autre.
4. Le langage SQL (Structured Query Language)
Le langage SQL peut être considéré comme le langage d’accès standard et normalisé, destiné à
interroger ou à manipuler une base de données relationnelle
Le modèle relationnel a été inventé par E.F. Codd en 1970, suite à quoi de nombreux langages ont fait leur
apparition :
• IBM Sequel (Structured English Query Language) en 1977
• IBM Sequel/2
• IBM System/R
• IBM DB2
Ce sont ces langages qui ont donné naissance au standard SQL, normalisé en 1986 par l'ANSI pour
donner SQL/86. Puis en 1989 la version SQL/89 a été approuvée. La norme SQL/92 a désormais pour nom SQL
2 qui est la plus répandue aujourd’hui.
Le succès du langage SQL est dû essentiellement à sa simplicité et au fait qu’il s’appuie sur le schéma
conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie d’exécution. Le langage
SQL propose un langage de requêtes ensembliste et assertionnel.
Néanmoins, le langage SQL ne possède pas la puissance d’un langage de programmation :
entrées/sorties, instructions conditionnelles, boucles et affectations. Pour certains traitements, il est donc
nécessaire de coupler le langage SQL avec un langage de programmation plus complet.
De manière synthétique, on peut dire que SQL est un langage relationnel, il manipule donc des tables
(i.e. des relations, c’est-à-dire des ensembles) par l’intermédiaire de requêtes qui produisent également des
tables.
Les instructions SQL sont regroupées en catégories en fonction de leur utilité et des entités manipulées.
Nous pouvons distinguer cinq catégories (SICOT, 2008) :
un langage de définition de données (LDD)
un langage de manipulation de données (LMD)
un langage de contrôle de données (LCD),
un langage de contrôle des transactions (LCT)
et d'autres modules destinés notamment à écrire des routines (procédures, fonctions ou déclencheurs) et
interagir avec des langages externes.
4.1 langage de définition de données (LDD)
Le langage de définition de données (LDD, ou Data Definition Language, soit DDL en anglais) est un langage
orienté au niveau de la structure de la base de données. Le LDD permet de créer, modifier, supprimer des objets.
Il permet également de définir le domaine des données (nombre, chaîne de caractères, date, booléen, . . .) et
d’ajouter des contraintes de valeur sur les données. Il permet enfin d’autoriser ou d’interdire l’accès aux données
et d’activer ou de désactiver l’audit pour un utilisateur donné.
4.2 langage de manipulation de données (LMD)
Le langage de manipulation de données (LMD, ou Data Manipulation Language, soit DML en anglais) est
l’ensemble des commandes concernant la manipulation des données dans une base de données. Le LMD permet
l’ajout, la suppression et la modification de lignes, la visualisation du contenu des tables et leur verrouillage.
4.3 langage de contrôle d’accès (LCD)
Le langage de contrôle d’accès (ou Data Control Language, soit DCL en anglais) s’occupe de gérer les droits
d’accès aux tables.
4.4 langage de contrôle des transactions (LCT)
Le langage de contrôle de transaction (ou Transaction Control Language, soit TCL en anglais) gère les
modifications faites par le LMD, c’est-à-dire les caractéristiques des transactions et la validation et l’annulation
des modifications.
4.5 SQL intégré
Le SQL intégré (Embedded SQL) permet d’utiliser SQL dans un langage de troisième génération (C,
Java, Cobol, etc.) :
déclaration d’objets ou d’instructions ;
exécution d’instructions ;
gestion des variables et des curseurs ;
traitement des erreurs.
5. Création d’une base de données spatiale à l’aide de postgreSQL
Les systèmes traditionnels de gestion de bases de données relationnelles (SGBDR) offrent un modèle de
données composé d’une collection de relations contenant des attributs relevant chacun d’un type spécifique.
PostgreSQL apporte une puissance additionnelle substantielle en incorporant les quatre concepts de
base suivants afin que les utilisateurs puissent facilement étendre le système : classes, héritage, types, fonctions.
D’autres fonctionnalités accroissent la puissance et la souplesse: contraintes, déclencheurs, règles,
intégrité des transactions. Ces fonctionnalités placent PostgreSQL dans la catégorie des bases de données
relationnelles objet mais bien que PostgreSQL possède certaines fonctionnalités orientées objet, il appartient
avant tout au monde des SGBDR. C’est essentiellement l’aspect SGBDR-spatiale de PostgreSQL qui nous
concerne
Avant de commencer la création de notre base de données il faut données quelques généralités sur le
logiciel utilisé
5.1 Présentation du PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO)
(LEPINARD, 2008). Ce dernier a été développé à l'université de Californie au département des sciences
informatiques de Berkeley. L’une des principales qualités de PostgreSQL est d’être un logiciel libre, c’est-à-dire
gratuit et dont les sources sont disponibles. Il est possible de l’installer sur les systèmes Unix/Linux et Win32.
Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils soient libres (comme
MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2 et Microsoft SQL Server). Comme les
projets libres Apache et Linux, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé sur une
communauté mondiale de développeurs et d'entreprises.
PostgreSQL fonctionne selon une architecture client/serveur, il est ainsi constitué (Picavet et all, 2009) :
d’une partie serveur, c’est-à-dire une application fonctionnant sur la machine hébergeant la base de
données (le serveur de bas et de données) capable de traiter les requêtes des clients ;
d’une partie client (psql) devant être installée sur toutes les machines nécessitant d’accéder au serveur
de base de données (un client peut éventuellement fonctionner sur le serveur lui même). Les
applications clientes peuvent être de natures très différentes : un client peut être un outil texte, une
application graphique, un serveur web qui accède à la base de données pour afficher des pages web ou
un outil spécialisé dans la maintenance de bases de données.
PostgreSQL support une grande partie du standard SQL et comporte de nombreuses fonctionnalités
intéressantes et modernes (YUAN, 2009). Parmi celles-ci, on peut citer par exemple :
moteur transactionnel
respect des normes SQL
MVCC (mécanisme permettant une concurrence efficace sans verrouiller les enregistrements
pour assurer l'isolation des transactions)
procédures stockées dans de nombreux langages
triggers
réplication maître-esclaves en continu par application des journaux binaires (archives WAL),
esclaves accessibles en lecture.
PostgreSQL est conçu d’une part pour être robuste (aucune version ne sort sans avoir
subi une suite extensive de tests) et pour supporter des volumes importants de données et
d’autre part pour pouvoir supporter des extensions affin de compléter le moteur comme par
exemple :
PostGis : moteur de données spatiales.
Slony : réplication maître-esclaves.
Et de nombreux autres.
Postgis est l’extension la plus important qui nous intéresse
Pour la conception de la base de données du bassin versant du Sebou, le choix est tombé sur l’outil
DBDesigner4.
DBDesigner 4 est un système open source de base de données visuelle de conception qui intègre tout
les niveaux de modélisation (conceptuelle, logique et physique) de bases de données, la modification, la création
et la maintenance dans un environnement unique et homogène (GIRARD, 2009). Il combine une interface très
conviviale avec des outils puissants qui permettent de générer rapidement des scripts SQL ou XML pour créer
les bases conçues ou bien permet le rétro-ingénierie « reverse engineering » sur des bases existantes pour en
extraire la structure et en donner une interprétation graphique. Il existe en version Windows ou Linux. Il est
multilingue, gratuit et distribué sous la licence GPL (General Public License). A ses débuts, DBDesigner a été
développé et optimisé pour être utilisé avec le SGBDR MySQL, mais il est depuis compatible avec d’autres
SGBD relationnels comme postgreSQL lui aussi disponible gratuitement, pour permettre à tous de développer de
puissantes bases de données avec des outils performants.
DBDesigner 4 prend en charge deux commutable des interfaces d’utilisateur. Le mode de conception
est utilisé pour créer et maintenir le modèle visuel de bases de données. Le mode de requête est utilisée pour
travailler avec des données de table et de construire des requêtes SQL complexes déclarations pour l'utilisation
en PHP, Kylix ou d’un autre langage de programmation.
1.1 l’interface du DBDesigner
DBDesigner présente une interface graphique (Figure III-6) avec de nombreux boutons et palettes
permettant de manipuler les différentes entités, propriétés, associations, cardinalité, etc. Ces divers éléments
peuvent être déplacés facilement en utilisant la souris.
Fig.III-12- Représentation par DBDesigner d'une entité, de son identifiant et de ses attributs
La Figure III-13, montre une association binaire, et ses cardinalités, entre les entités
« ville » et «provinces ». Cette relation est représentée sous la forme d’un trait discontinue ayant en son centre
un petit losange. Il s’agit d’une des représentations possibles d’une association dans le modèle entité/association,
que reprend DBDesigner. Par exemple une province a au moins une ou plusieurs villes alors que son cardinalité
est de type 1 :n
Fig.III-13- Représentation par DBDesigner d'une association binaire avec ses cardinalités
Le nom des associations est basé sur un verbe. Par exemple « est_compose_de » pour « a un ». Comme
le montre la Figure III-13.
Différentes vues du même schéma sont possibles. On peut ne voir que les entités, ou les entités et leur
identifiant, ou encore les entités, leur identifiant et leurs propriétés. Dans ces trois cas de figures, nous sommes
toujours à un niveau conceptuel. Le schéma affiché correspond au modèle conceptuel de données (Figure III-14).
Fig.III-14- Représentation d'une association dans le contexte d’un modèle conceptuel de données
DBDesigner permet, en cochant l’option en question, d’afficher les clés étrangères. Une clé étrangère
(foreign key) est l’identifiant d’une entité qui se retrouve éventuellement dans une autre entité si ces deux entités
sont liées. Une clé étrangère est représentée par son libellé, précédé d’un losange rouge et suivi des lettres FK
(Foreign Key) entre pararenthèses. Par exemple sur la Figure III-15 la propriété « ville_id_ville » est une clé
étrangère.
Fig.III-16- Représentation d'une association avec une clé étrangère et les types des attributs
Sachant qu’au final, notre modèle conceptuel de données est destiné à être physiquement représenté par le
SGBDR PostgreSQL, et que l’affichage des clés étrangères apporte une représentation plus riche visuellement,
en concrétisant les cardinalités, nous avons fait le choix de présenter notre MCD avec les clés étrangères même
si ces dernières ne devraient pas se trouver à ce niveau de modélisation.
La conception de la base de données s’est faite à l’aide de l’outil mentionné au paravant en utilisant la
méthode relationnel. Le résultat est montré dans Fig.III-17
Les modèles créés par DBDesigner 4 sont stockés en XML. Pour importer ces modèles a notre base de
données « sebou » il faut convertir l’extension XML à SQL pour que PostgreSQL peut le compulser.
2. Conversion de l’extension XML à SQL
Pour faire convertir l’extension XML à SQL il est possible d’utiliser l’une des deux méthodes suivantes
(FOUGUIG et all, 2012):
Méthode 1
Avant de commencer, on doit installer Java, si vous avez le dossier JDK ou JRE on
pout configurer manuellement JAVA_HOME à partir de la fenêtre des paramètres
avancées dans le panneau de configuration. 7
On télécharge l’outil SAXON 9 HOME EDITION à partir de ce lien :
http://saxon.sourceforge.net/#F9.3HE
On Créer un nouveau dossier « SpatialDB ». (C’est préférable de le placer dans la racine C :\ )
Copier le fichier .zip déjà téléchargé dans « SpatialDB » et décompresser-le
Renommer ce dossier « saxon ».
Créer un nouveau dossier dans “SpatialDB” et nommer-le « Model ».
Copier votre schéma XML du modèle dans C:\SpatialDB\Model
Accéder au site suivant et télécharger les deux fichiers xml2postgresql.xslt et
xml2html.xsl http://www.tv.com.pl/stepbystep/dbdesigner/
Copier ces deux fichiers dans le répertoire C:\SpatialDB\Model
Ouvrir la fenêtre de la ligne des commandes.
Accéder au chemin de dossier contenant le schéma XML du modèle : …> cd
c:\spatialDB\Model
Écrire:
…> Java -cp C:\spatialDB\saxon\saxon9he.jar net.sf.saxon.Transform -s:MyModel.xml -
xsl:xml2postgresql.xslt -o:MyModel.sql
Si tout est bien, vous devez avoir ce résultat, et la génération d’un fichier .sql dans le
répertoire C:\SpatialDB\Model.
Lors de l’application de cette méthode, le résultat a été un fichier .sql qui sera utilisé par la suite dans la création
de la base de données sur PostgreSQL / PostGIS.
Méthode 2
Télécharger l’outil Ant à partir de ce lien :
http://ant.apache.org/bindownload.cgi
Créer un nouveau dossier « SpatialDB ». (C’est préférable de le placer dans la racine
C :\ )
Copier le fichier .zip déjà téléchargé dans « SpatialDB » et décompresser-le
4. Importation des données spatiales du bassin versant du Sebou dans la base de données « sebou »
Pour faciliter l’importation des données spatiales du bassin versant du Sebou dans notre base de
données « sebou » il est indispensable d’utiliser un logiciel intermédiaire tel que QGIS qui fournit de nombreux
outils pour charger des données de formes shapefiles (.shp).
• des lignes
• des polygones
Son extension est classiquement SHP, et il est toujours accompagné de deux autres fichiers de même
nom, et d'extensions :
• DBF, qui contient les données attributaires relatives aux objets contenus dans le shapefile
• SHX, qui stocke l'index de la géométrie
D'autres fichiers peuvent être également fournis :
• .sbn et .sbx - index spatial des formes.
• .fbn et .fbx - index spatial des formes pour les shapefile en lecture seule
• .ain et .aih - index des attibuts des champs actifs dans une table ou dans une table d'attributs du theme.
• .prj - la projection ; le système de coordonnées et l’information de projection, un fichier texte décrivant la
projection utilisant le format texte bien connu WKT (Well Known Text).
• .shp.xml - métadonnées du shapefile.
• .atx - fichier d'index des attributs pour le fichier dbf, sous la forme
<shapefile>.<nom_de_la_colonne>.atx (ArcGIS 8 et suivants)
Afin d’utiliser un fichier Shapefile dans PostGIS, vous devez le convertir en une série de requêtes SQL.
En utilisant pgShapeLoader, un Shapefile est converti en une table que PostgreSQL peut comprendre.
4.2 Présentation de Quantum GIS (QGIS)
Le Quantum GIS (QGIS) est un système d'information géographique (SIG) multi-plateforme (Linux,
Unix, Mac OSX et Windows) publié sous licence libre GPL (GNU Public License) qui signifie qu’on peux
étudier et modifier le code source, tout en ayant la garantie d’avoir accès à un programme SIG non onéreux et
librement modifiable (ROMAINVILLE, 2011). QGIS est basé sur la plateforme Qt développée par Nokia.
QGIS offre beaucoup d’outils SIG standards par défaut et via les extensions de multiples contributeurs.
QGIS permet de (selon le Quantum GIS Guide d’utilisation) :
Visualiser des données
Parcourir les données et créer des cartes
Créer, éditer, gérer et exporter des données
Analyser les données
Publier une carte sur Internet
Étendre les fonctionnalités grâce à des extensions
Fig.III-19-l’interface de QGIS
4.2.1 Visualisation des données
QGIS permet d’afficher et de superposer des couches de données rasters et vecteurs dans différents
formats et projections sans avoir à faire de conversion dans un format commun. Les formats supportés incluent :
les tables spatiales de PostgreSQL/PostGIS et SpatiaLite, les formats vecteurs gérés par la bibliothèque
OGR installée, ce qui inclut les fichiers de format ESRI (shapefiles), MapInfo, STDS, GML et
beaucoup d’autres,
les formats raster supportés par la bibliothèque GDAL (Geospatial Data Abstraction Library) tels que
GeoTiff, Tiff Erdas img., ArcInfo ascii grid, JPEG, PNG, Jpeg et beaucoup d’autres,
les bases de données SpatiaLite
les formats raster et vecteur provenant des bases de données GRASS,
les données spatiales provenant des services réseaux compatibles OGC comme le Web Map Service
(WMS) ou le Web Feature Service (WFS)
les données OpenStreetMap
4.2.2 parcourir les données et créer des cartes
QGIS permet de créer des cartes et les parcourir de manière interactive avec une interface intuitive. Les
outils disponibles dans l’interface sont :
projection à la volée (adapte les unités de mesure et reprojete automatiquement les données
vectorielles)
composition de carte
panneau de navigation
signet géospatial
identification et sélection des entités
affichage, édition et recherche des attributs
On Clique sur Nouveau pour ouvrir la fenêtre de paramétrage de la connexion vers la base « sebou
», renseigner les différentes informations, on teste la connexion et on valide
On vérifie l’importation des données vers la base « sebou » pour cela on ouvre PG Admin et on
sélectionne la base de données «sebou». En suit on vérifie la présence des tables dans sebou =>
Schémas => public => tables
QGIS, comme mentionné dans la partie précédente, est un SIG libre multiplateforme publié sous licence
GPL. QGIS peut interagir avec le SGBDR PostgreSQL/PostGis et permet de visualiser les tables spatiales telle-
que la base de données de « sebou ».
V. CONCLUSION
Nous avons présenté un aperçu général de l'architecture de notre solution qui se base essentiellement sur
la création et la conception d’une base de données relationnelle spatiale. Cette application permettra aux
chercheurs marocains et aux hydrogéologues en particulier d'accéder aux données géospatiales et de l’utiliser
dans différentes domaines. Notre solution a été développée à l’aide d’outils Open Source.
CHAPITRE IV
CONCEPTION D'UN SIG WEB
I. INTRODUCTION
Les SIG ont acquis une importance considérable ces dernières années et leur utilisation touche à divers
domaines. La mise en ligne des SIG en utilisant les technologies Web et Internet a renforcé cela. D’autre part,
des logiciels open source ont été utilisés pour aider au développement des SIG en ligne car ils permettent la
malléabilité et la standardisation voulue pour une interopérabilité nécessaire entre les systèmes (DE CREST,
2007)
La technologie « open source » en général, et pour les SIG WEB en particulier, présente plusieurs
avantages :
• La diffusion des données à coût réduit (licences gratuites)
• La publication des formats de données des principaux éditeurs de SIG (ESRI Shapfile, MapInfo, etc…)
ainsi les données issus de SGBD comme postgreSQL/postgis
• L’implémentation sur la majorité des serveurs web du marché
• L’interopérabilité permettant ainsi de réaliser une carte unique à partir de données issus de différents
serveurs
• Disponibilité des fonctionnalités SIG standards : navigation, consultation, impressions,…
Ils existent plusieurs serveurs « open source » ayant l’avantage d’être peu onéreux, très malléables
parmi eux GeoServer.
II. IMPORTATION DE LA BASE DE DONNEES SEBOU DANS GEOSERVER
Il y a des installations similaire et obligatoire alors en utilisant l’OpenGeo suite comme application
d’installation car celle-ci contient GeoServer dans un seul outil d’installation pour Windows. La suite contient
aussi PostGis/PostgreSQL, open layer et autres
1. Définition de la suite OpenGeo
OpenGeo suite combine la puissance de l'open source ainsi que la fiabilité et le support d'un seul,
fournisseur stable derrière une pile complète de logiciels. Il offre des fonctionnalités et la flexibilité pour les
entreprises, grandes et petites (selon le manuel d’utilisation d’OpenGeo suite, 2011).
OpenGeo suite rassemble l'architecture OpenGeo en un seul, logiciel facile à installer intégrée. Il
développe chaque composant individuel de la Suite OpenGeo individuellement, la Suite peut s'intègre aux
systèmes existants source exclusive ou ouverte. Il est le moyen le plus rapide pour obtenir l’information
géospatiale sur le Web, en s'appuyant sur la puissance de best-of-breed de logiciels géospatiaux open source.
La suite contient :
PostGIS ajoute le support des objets géographiques au SGBDR PostgreSQL. En
pratique, PostGIS rend le serveur PostgreSQL « géo-capable », lui permettant d’être
utilisé comme la base de données spatiale principale pour les systèmes d’information
géographique (SIG).
2. Présentation de GeoServer
GeoServer est un logiciel open-source serveur distribué sous la licence GNU General Public qui permet
de diffuser et modifier des données GeoSpatiales sur le web. Il est écrit en langage Java et fonctionne côté
serveur en tant que « servlet » c'est-à-dire comme une application gérée par un serveur d’applications java (le
plus utilisé d’entre eux étant Tomcat, un projet de la fondation Apache) (LAURENT, 2011).
GeoServer est devenue l'implémentation de référence de l'Open Geospatial Consortium (OGC) pour la
diffusion de données selon les normes Web Feature Service (WFS) et Service de couverture Web (WCS) , ainsi
que d'une haute performance certifiée conforme Web Map Service (WMS).
Pour simplifier, on peux dire que c’est un serveur de données pouvant se connecter à des bases de
données comme PostgreSQL/PostGIS, des fichiers (Shapefile),...et qu’il supporte beaucoup de format de sortie
comme PNG, SVG, KML, PDF
3. Configuration et mise en place du GeoServer
Par défaut, le serveur web est lancé sur le port 8080, on obtient donc l’interface d’administration web de
GeoServer à l’adresse suivante : http:/localhost :8080/geoserver ou bien on crée une adresse fixe et personnel à
l’aide de DUC 3 telle que abbadihanae.no-ip.org:8080/geoserver.
L’interface de gestion de GeoServer se présente sous la forme suivante :
Fig.IV-2-l’interface de GeoServer
Le menu d’administration apparaît:
On y trouve une page d’affichage de l’état du serveur, des web services actifs, ainsi que les liens vers
l’administration des données servies.
Dans GeoServer les données sont structurées de la manière suivante :
Espace de travail : sortes de répertoires qui ne servent que de moyens pour regrouper des entrepôts.
Entrepôts : zone de stockage de données de même format (vecteur ou raster). Les entrepôts
définissent une source de données et la décrivent (texte de description et page de codes de la source
de données, utile pour les dbf des shapefile par exemple).
Couche : les couches sont un moyen de présenter les informations des entrepôts, en précisant la
boîte d’encadrement, et en affectant un style d’affichage de ces données (en attribuant l’un des
style d’affichage de ces données( en attribuant l’un des styles gérés par GeoServer par ailleurs)
Les styles sont donc la définition de l’apparence d’affichage d’une couche, selon un format
standardisé très utilisé, le format SLD (styled Layer Descriptor). On peut prévisualiser la couche,
avec son style défini ou un style par défaut selon le type des données), grâce au client OpenLayers
inclus dans l’installation de GeoServer.
Option Description
Nom de la source de Nom de la base de données. Cela peut être différent du nom connu de PostgreSQL /
données PostGIS.
Type de connexion Type de base de données.on laisse cette valeur par défaut.
Nom de la base de données telle qu'elle est connue sur l'hôte. « sebou » et dans
Base de données postgreSQL
Lorsqu'elles sont correctement chargées, toutes les tables dans la base de données « sebou » seront
visible sur GeoServer.
Le SIG Web, fait partie des points principaux de note axe de recherche. Dans ce sens, nous avons implémenté
notre base de données dans un serveur WEB tel que GeoServer qui nous permet de partager notre base de données
spatiale dans un réseau informatique pour que les chercheurs et les ingénieurs hydrogéologues ayant une autorisation et
une communication internet d’accéder à notre base de données à n’importe quelle endroits du monde
-----------------------------------------------------------------------------------------------------------
Faculté des Sciences et Techniques - Fès
B.P. 2202 – Route d’Imouzzer – FES
212 (0) 535 60 29 53 Fax : 212 (0) 535 60 82 14
Université Sidi Mohammed Ben Abdellah
Faculté des Sciences et Techniques
www.fst-usmba.ac.ma
-----------------------------------------------------------------------------------------------------------
CONCLUSION GENERALE
La vitesse avec la quelle évolue la science et les différents projets, exige l’utilisation de nouvelles techniques
de gestion des données pour répondre aux besoins des chercheurs et des ingénieurs.
Parmi les systèmes de gestion de données figure les SIG dont les SIG WEB font partie. Les systèmes de
gestions de base de données garantissent la facilité de l’accessibilité à l’information fiable, précise et complète en
assurant le gain du temps et de l’énergie. En tenant compte les relations et les interactions entres les différentes données.
Comme notre projet qui se base essentiellement sur la création et la conception des bases de données
relationnelle spatiale par PostgreSQL/PostGis et leur visualisation par le logiciel SIG tel que QGIS et aussi par une
application WEB tel que GeoServer qui sont développées surtout par les outils Open Source, on peut être appliquée
également cette solution dans plusieurs domaines tel que le tourisme, l’industrie et bien d’autres.
-----------------------------------------------------------------------------------------------------------
Faculté des Sciences et Techniques - Fès
B.P. 2202 – Route d’Imouzzer – FES
212 (0) 535 60 29 53 Fax : 212 (0) 535 60 82 14
Université Sidi Mohammed Ben Abdellah
Faculté des Sciences et Techniques
www.fst-usmba.ac.ma
-----------------------------------------------------------------------------------------------------------
REFERENCES BIBLIOGRAPHIQUES
.
♦ ABHS, 2004: Etude du schéma directeur d’alimentation en eau potable des villes de Fès et Meknès et les centres de
la plaine de Fès-Meknès. Mission I : Analyse et synthèse de la situation actuelle de l’AEP.
Vol 3 M.1.
♦ ABHS, 2006a: Plan Directeur d’Aménagement Intègre des Ressources en eaux (PDAIRE). Mission I : Etudes des
eaux de surface ; 79p ; Septembre 2006.
♦ ABHS, 2006b: Débat national sur l’eau ; Novembre 2006.
♦ ABHS, 2007 : Etat des lieux du bassin du Sebou dans le cadre de la mise en place pilote des outils de la DCE ;
Octobre 2007.
♦ AHMAMOU M., 1987: Etude sédimentologique des calcaires lacustres saissiens (Plio-quaternaire) du bassin de
Fès-Meknès. Thèse, univ. Aix-Marseille FST St Jérome, 178p.
♦ BRASSEUR E., 2008 : Gestionnaire de bases de données relationnelles. Cours à I.E.P.S.C.F. Marche en Famenne.
P : 10-12
♦ CALOZ R., 1993 : Système d.information géographique. Cours, Ecole Polythechnique de Lausanne, département
du Génie Rural. P : 52
♦ CHAABANE R., 2009 : Conception des bases de données : Modèle Entité-Association.cours Informatique Paris 8.
P : 5-8
♦ CORNUEJOLS A., 2009 : BASES DE DONNÉES CONCEPTS ET PROGRAMMATION. cours à
AgroParisTech, Spécialité Informatique
♦ DE CREST M., 2007 : Développement d'une application de Webmapping - pour la Mairie de Crest (26). Rapport
de stage pour l’obtention du master professionnel
♦ DE MARCHI F., 2009 : Conception des bases de données relationnelles. Cours à la Faculté des Sciences et
Technologies - Laboratoire LIRIS Université Lyon 1. P : 11-16
♦ FOUGUIG M. et BAH B., 2012 : conception de base de données : bases de données spatiales. P : 8-13
♦ GENDRE P., 2008 : Requêtes sur Base de Données Géographique Voirie et Transports Collectifs. Rapport Phase 1.
p : 13-20
♦ GIRARD P., 2009 : Conception d’une base de données en neuro-imagerie en lien avec une ontologie du domaine.
Mémoire, pour l’obtention D'INGENIEUR C.N.A.M. en INFORMATIQUE. P : 59-61
♦ GRUAU C., 2006 : Conception d’une base de données p : 4-27
♦ Guide d’utilisation de DBDesigner 4, 2003 : documentation Version 1.0.42. p : 7-9
♦ Guide d’utilisation d’OpenGeo suite, version 2.3.5, modifié en mars 2012
♦ Guide d’utilisateur de PostgreSQL/PostGIS. P : 20-41
♦ Guide d’utilisation de PostgreSQL 8.1.22: The PostgreSQL Global Development Group. P: 15-23
♦ Guide d’utilisation de Quantum GIS Version 1.3.0
-----------------------------------------------------------------------------------------------------------
Faculté des Sciences et Techniques - Fès
B.P. 2202 – Route d’Imouzzer – FES
212 (0) 535 60 29 53 Fax : 212 (0) 535 60 82 14
Université Sidi Mohammed Ben Abdellah
Faculté des Sciences et Techniques
www.fst-usmba.ac.ma
-----------------------------------------------------------------------------------------------------------
♦ HALFELD M., 2010 : Bases de données - Modèle relationnel. P : 26
♦ LAURENT J., 2011 : GeoServer, un diffuseur de WEB Services GéoSpatiaux. Cours de l’université de Toulouse-
Le Mirail ; département de géographie- Aménagement- Environnement.
♦ LEPINARD P., 2008 : PREMIERS PAS AVEC LE TRIPTYQUE POSGRESQL/POSTGIS/QGIS. P : 3-14
♦ MARK L., et RAMSEY P., 2011: Introduction to PostGIS Version 1.0. P: 17-23
♦ Modélisation MERISE Essentiel, 2008 : Comprendre le fonctionnement d’un SGBD Comprendre le principe de la
modélisation MERISE et savoir l’appliquer Adapter le principe aux bases de données. P :
46-54
♦ OLIVIER L., 2009 : Introduction aux Systèmes de Gestion de Bases de Données Relationnelles. Cours du Master
Sciences et Technologies à Université Lille1, 2-6p
♦ PICAVET V. et OLIVIER C., 2009 : PostGIS, un module de PostgreSQL pour les données spatiales. Cours
Licence GNU FDL. P : 13
♦ Rigaux P., 2001 : Cours de bases de données
♦ ROMAINVILLE A., 2011 : QGIS: petit guide technique de l'utilisateur Version septembre 2011. P : 1-11
♦ SICOT J., 2008 : Introduction au Système de Gestion de Base de Données et aux Base de Données. Formation «
Gestion des données scientifiques : stockage et consultation en utilisant des bases de
données » 6-8 ; 17p
♦ TORRES D. et all, 2011 : CONCEPTION DES BASES DE DONNEES RELATIONNELLES
♦ YUAN R., 2009: Adaptation, développement et évaluation d’un système d’information destiné à administrer les
données provenant d’un réseau de capteurs hydrologiques communiquant. P : 17-20
-----------------------------------------------------------------------------------------------------------
Faculté des Sciences et Techniques - Fès
B.P. 2202 – Route d’Imouzzer – FES
212 (0) 535 60 29 53 Fax : 212 (0) 535 60 82 14