IVP1 Année 2007-2008

Promotion 49

Département d’Enseignement et de Recherche en Informatique & Technologies Urbaines

Projet de développement
d’une base de donnée

Le ramassage des ordures

ménagères à Paris

Aurélien LAMPE
Julien BRASSELET

Professeur responsable : M.CHACHOUA

 Sommaire :

1) Formation de la base de données

1)Description du domaine étudié

2)Données à entrer

3)Construction du schéma relationnel

2)Mise en pratique sur Access

1)Tables de données

2)Schéma du MLD

3)Mise en pratique (requêtes)

1) Formation de la base de données
1)Description du domaine étudié

Notre base de données aura pour objet l’étude du système de ramassage des ordures
ménagères à Paris. La mise en place de ce service aux citoyen repose sur les agents de
proximité (éboueurs) qui collectent les déchets dans des camions-benne afin de les transmettre
à la déchetterie la plus proche. Notre étude concernera les moyens, en terme de bases de
données permettant l’efficacité du service. Cela prend en compte les moyens matériels (mise a
disposition de camions), l’identification des besoins des citoyens ( densité de population,
fréquence de ramassage plus ou moins grande) et le modèle organisationnel du système
(regroupement du personnel au sein d’ « ateliers », pouvoir de décision du « chef d’équipe » à
l’intérieur de cette structure).

2)Données à entrer

Pour chacun des aspects de problème, nous entrerons des données (numérique ou
texte) à l’intérieurs de tables prévues à cet effet en vue de créer une des liens de type entité-
association.
Pour ce qui est des entités, nous considérons :
- Le « chef d’équipe », en tant que manager des opération au sein d’un atelier.
- Les ateliers qui comportent chacun une partie des effectifs en éboueurs dédiés au ramassage
des ordures.
- Les éboueurs, agents de ramassage sur le terrain, sont quant à eux répertoriés par
l’administration et sont chargés au quotidien d’une mission au service de la propreté.
- Les camions de ramassage, qui demande une importante quantité de main d’œuvre à leur
mise en fonctionnement sue le secteur de Paris.
- Les rues concernées par notre étude.

Chef d’équipe

Nom Type-donnée
Num chef d’équipe Numérique
Nom Texte
Prénom Texte
Téléphone Texte
Num atelier Numérique
Atelier

Nom Type-donnée
Num atelier Numérique
Effectif Numérique
Nombre de véhicules Numérique
Num chef d’équipe Numérique

Eboueurs

Nom Type-donnée
Nom Texte
Prénom Texte
Ancienneté Numérique
Rémunération Numérique
Matricule Numérique

Camion

Nom Type-donnée
Num camion Numérique
Volume Numérique
Immatriculation Texte

Rue

Nom Type-donnée
Nom de rue Texte
Nombre d’habitants Numérique
Fréquence Numérique
 3)Construction du schéma relationnel
Par le biais de l’analyse du sujet, nous allons désormais mettre en évidence les
dépendances entre attributs (déterminés dans la liste précédente) et ainsi mettre en place le
graphe des dépendances fonctionnelles suivant :

Nom

Num chef
Prénom
d’équipe

Téléphone effectif

Num atelier
Nombre de véhicules

Nombre
d’habitants Num chef d’équipe
Nom de rue

Fréquence

Nom
matricule
Prénom

ancienneté

rémunération

volume

Num camion
Immatriculation

Num camion Horaire

Nom rue
 Lors de cette étape nous allons identifier les différents types entités qui vont intervenir
dans notre base de données. Ici, nous avons :

 Chef d’équipe
 Atelier
 Eboueurs
 Camion
 Rue

Ensuite, on détermine pour chaque type entité la clé primaire, qui n’est autre que
l’attribut source de dépendances fonctionnelles vers tous les autres attributs du type entité
considéré. Les attributs de chaque type entité sont ceux qui dépendent de la clé primaire sans
être eux-mêmes des clés primaires.

On obtient donc les 5 types entité suivants :

CHEF
ATELIER EBOUEUR CAMION RUE
D’EQUIPE
Num chef
Num atelier Matricule Num_camion Nom de rue
d’équipe
Volume
Effectif Nombre
Nom Nom
d’habitants
Immatriculation
Nombre de
Prénom véhicules Prénom Fréquence

Num chef
Téléphone Ancienneté
d’équipe
Num atelier Num atelier Rémunération
Effectif
Matricule
 On détermine enfin les types associations reliant les différents types entités et ceux grâce
aux données du problème et aux dépendances fonctionnelles.
Les associations sont les suivantes :

 Appartient à : entre ATELIER et EBOUEUR. Les cardinalités sont

respectivement (1,n) et (1,1) car un atelier a au moins un éboueur mais peut en
avoir plusieurs, et parce qu’un éboueur travaille dans un unique atelier.

 Utilise: entre EBOUEUR et CAMION. Les cardinalités sont respectivement

(1,1) et (1,n), puisque un éboueur utilise un et un seul camion, et dans un
camion il y a forcément n éboueurs ( ici n = 2 )

 Possède : entre ATELIER et CAMION. Les cardinalités sont respectivement

(1,n) et (1,1). En effet, dans un atelier il y a plusieurs camion ( au moins un ) et
un camion appartient a un et un seul atelier.

 Passe part: entre RUE et CAMION. Les cardinalités sont respectivement (1,n)
et (1,1) . En effet on a considéré que dans une rue il passe plusieurs camions
(au moins un ) et que un camion passe dans une et une seule rue.

Entre CHEF D’EQUIPE et ATELIER, les cardinalités sont (1,1) et (1,1) , car un chef
d’équipe est affecté a un et un seul atelier, et dans un atelier il y a un unique chef d’équipe.
C’est pourquoi le type association « dirige » entre ces deux types entités n’est pas représenté
sur Access.

On obtient alors le MCD suivant :

 Nous avons alors obtenu les relations suivantes :

 CHEF D’EQUIPE (Num chef d’équipe, Nom, Prénom, Num téléphone, Num
atelier)
 ATELIER (Num atelier, effectif, nombre de véhicules, Num chef d’équipe)
 EBOUEUR(Matricule, Nom, Prénom, Ancienneté, Rémunération)
 CAMION (Num camion, Volume, Immatriculation)
 RUE (Nom de rue, Nombre d’habitants, fréquence)
 APPARTIENT A (Num atelier, Matricule)
 POSSEDE (Num atelier, Num camion)
 UTILISE (Matricule, Num camion)
 PASSE PAR (Num camion, Nom de rue, horaire)

Une fois ces relations établies, il nous semblait intéressant d’étudier les formes
normalisées des relations, qui se basent sur certaines « règles » ou notions :

 1ère forme normale : Clé + attributs atomiques

 2ème forme normale : 1FN + Dépendances Fonctionnelles clé  attributs non-
clé sont élémentaires
 3ème forme normale : 2FN + Dépendances Fonctionnelles clé  attributs non-
clé sont directes
 Forme normale de Boyce-Codd : 3FN + la clé est la source de toutes les
Dépendances Fonctionnelles

Etudions les relations EBOUEURS, CAMION, RUE: elle sont bien composées d’une clé
et d’attributs atomiques, la clé étant composée d’un seul attribut les dépendances
fonctionnelles de la clé vers les attributs non-clé sont élémentaires, il n’existe aucune
dépendance fonctionnelle entre attributs non clés, ce qui signifie que les dépendances
fonctionnelles de la clé vers les attributs non clé sont directes. Enfin, il n’existe pas de
dépendances fonctionnelles d’un attribut non clé vers la clé, soit encore la clé est source de
toutes les dépendances fonctionnelles. La forme normale de la relation 1 est donc la forme
normale de Boyce-Codd.
Les autres relations présentent quand à elles des attributs non clefs source de dépendance
fonctionnelle.
2)Mise en pratique sur Access

1)Tables de données

Voici un extrait de la table de données EBOUEUR

2)Schéma du MLD

Suite à la création des tables nous devons réaliser le MLD. Après avoir crée les relations
entre les tables (par le biais des clés primaires et étrangères) on obtient le schéma suivant :
 3)Mise en pratique (requêtes)

Les requêtes nous permettent, en tant qu’utilisateur de consulter les données d’une ou
plusieurs tables en les triant selon différents critères. Il est possible de créer une infinité de
requêtes, nous nous sommes limités à celles réalisable par le biais de nos connaissances en
langage SQL.

Afin de créer une requête il faut commencer par définir les tables et les attributs
concernés par la requête. Ensuite, on peut mettre en forme le résultat demandé, en choisissant
par exemple d’éliminer les résultats redondants grâce au choix « regroupement », ou
d’ordonner les résultats en rangeant les données d’une colonne par ordre croissant ou
décroissant. Enfin, on peut imposer un critère de tri. Les requêtes que nous avons créées
dépendent de critères de natures différentes selon le résultat voulu.

Détaillons les différents critères :

 Le critère peut être une information fournie par l’utilisateur, le logiciel Access
pose alors une question. La question est définie entre crochets dans le mode
création et la réponse donnée sera le critère de recherche.

Par exemple : pour la requête suivante (requête 1) on souhaite obtenir les coordonnées
des éboueurs et des camions responsable du non ramassage des poubelles dans la rue
Wagram, le matin . On demande a afficher aussi son ancienneté afin de prendre les sanctions
en conséquences. Les tables RUE, PASSE PAR, CAMION et EBOUEURS ont ici été
nécessaires.

Et le résultat de la requête :
 La requête numéro 2 consiste à déterminer les coordonnées ( nom, prénom, numéro de
téléphone) du chef d’équipe en charge d’un camion tombé en panne qui est repéré par sa
plaque d’immatriculation.
On a pour cela utilisé les tables CAMION, ATELIER, CHEF D’EQUIPE

D’où le résultat :

La requête numéro 3 vise a requalifier les salaires des éboueurs dont la fréquence de
travail est élevée et cela en fonction de leur ancienneté et de son niveau de rémunération
actuel. ( cf Access )

Enfin, la requête numéro 4 détermine les caractéristiques des services de nettoyage dans
les rues de Wagram et Malesherbe. On cherche a connaitre le volume moyen des camions qui
parcourent ces rues ainsi que la fréquence moyenne de passage dans ces rues et enfin le
nombre d’éboueurs mobilisés.

Ici, les tables nécessaires sont RUE, CAMION et EBOUEUR ; sur lesquelles la requête
effectue des opérations ( moyenne et dénombrement )

D’où le résultat :
 BIBLIOGRAPHIE

Supports de cours :

Cours de Base de données et Cours Access : Mohamed CHACHOUA

Ouvrage :

Access 2007 le guide complet, Micro Application

Autres documents :

Documents de la mairie de Paris obtenus lors du stage ouvrier de début d’année