• Aucun résultat trouvé

PARTIE II : METHODOLOGIE 32

4.1 Modélisation de l’entrepôt de données

4.1.2 Modélisation multidimensionnelle de l’entrepôt de

com-mence d’abord par la définition des différentes dimensions ou diffé-rents axes d’analyse, des différentes mesures à estimer. Ensuite, suit le modèle logique formé par ces dimensions et ces différentes me-sures regroupées dans une ou plusieurs tables de faits.

Les indicateurs constituent le lien commun entre les besoins d’ana-lyse des acteurs de la ville et les sources de données. Ces différents acteurs ont besoin d’évaluer les différentes valeurs prises par ces in-dicateurs afin de pouvoir prendre différentes décisions.

La mesure principale à évaluer par notre système constitue la va-leur exacte de chacun des indicateurs au niveau de la ville. Cette me-sure est, soit un nombre (ex : 100000 d’habitants pour l’indicateur « Nombre d’habitants ») ou une proportion (exemple : 15.8% pour

l’indi-cateur « Taux de scolarisation »). Cette valeur est relative à un temps donné et à une région. Ainsi à un instant t et à une région r correspond une valeur d’un indicateur.

A partir de là, nous dégageons deux principales dimensions : la dimension « indicateur » dont chaque membre équivaut à chacun de nos indicateurs, la dimension « temps » dont chaque membre cor-respond à une période donnée (année) et une dimension « muette

» : la dimension « region » ; elle est dite « muette » ici parce qu’elle ne possède qu’un seul niveau à un membre (la ville) ; et un fait « fait_indicateur » qui a pour mesure la valeur de l’indicateur.

A ce stade, nous pouvons déjà établir un premier modèle dimen-sionnel potentiel de données basé sur un modèle en étoile de l’ap-proche ROLAP (figure 4.1).

Figure4.1 – Modèle en étoile potentiel de l’entrepôt

La définition de la granularité de notre entrepôt est une phase très importante de la modélisation. En effet avec le modèle de la figure 4.1, la granularité de la mesure est arrêtée au niveau "année" pour la dimension « temps » et au niveau "ville" pour la dimension « région

». De plus, il est intéressant pour une bonne précision d’analyse de s’intéresser aux différentes valeurs de ces indicateurs au sein des différentes entités de la ville. Cela nous amène à décomposer la ville entière en ses différents arrondissements et ceux-ci en quartiers. Pour certains indicateurs il faut aller encore plus en profondeur, c’est-à-dire

Système d’Aide à la Décision pour la gestion urbaine : application à la ville de Porto-Novo, Bénin

passer du quartier aux différentes structures du quartier (école, centre de santé, point d’approvisionnement d’eau, marché, etc.) qui ont un rapport avec l’indicateur. Par exemple, le « Taux de scolarisation » peut est évalué pour une école d’un quartier, la « Mortalité infantile » peut est évaluée pour un centre de santé situé dans un quartier, etc..

La figure 4.2 présente la granularité de l’entrepôt. L’entrepôt est de granularité 4.

Figure4.2 – Différents niveaux de granularité des indicateurs suivant la dimension

« region »

Aussi, chaque indicateur appartient à un secteur ou une catégo-rie donnée (exemple : « Taux de scolarisation » appartient au secteur

« Éducation » , « Mortalité infantile » appartient au secteur « Santé

»). Certains indicateurs peuvent être définis par des valeurs journa-lières (« Quantité de déchets produits », « Taux de déchets éliminés

», « Consommation en eau potable », etc.), d’autres par valeurs men-suelles (« Croissance démographique », « Nombre d’habitants par tranche d’âge », « Lits d’hôpital disponibles », etc.) et d’autres par an (« Mortalité infantile », « Taux d’alphabétisation » par exemple). Ces choix dépendent du degré de précision d’analyse défini par ces diffé-rents indicateurs. L’entrepôt de données doit répondre à ces attentes, et stocker la valeur de tous ces indicateurs, peu importe le type (jour-nalier, hebdomadaire, mensuel, annuel, etc.). Cette valeur doit pouvoir être affichée à l’utilisateur lors d’une analyse avec les détails de la pé-riode correspondante.

Vu tout cela, tout d’abord la dimension « region » doit être décom-posée en sous-hiérarchies « arrondissement », « quartier » et «

struc-ture ». Chacune de ces sous-hiérarchies devient une nouvelle dimen-sion. De plus, une autre nouvelle dimension apparait dans le modèle, la dimension « domaine ». Cette dimension permettra de parcourir les indicateurs de manière descendante c’est-à-dire du domaine de l’indicateur à l’indicateur lui-même. Par exemple, le choix du domaine Ecole permet de ressortir tous les indicateurs de ce domaine (« Taux d’alphabétisation », « Taux de scolarité brut », etc.). Il est donc im-portant dans le modèle que « domaine » soit une dimension à part au lieu d’être un niveau de la dimension « indicateur ». Enfin, la dé-finition de certains indicateurs amène à conserver les données selon diverses fréquences. Par rapport à la dimension temporelle, il contient 3 différents niveaux : « jour », « mois » « an » . Pour les données jour-nalières, ces niveaux doivent définir le jour (jour/mois/année), quant aux données mensuelles seuls les niveaux mois et an doivent être renseignés, ainsi de suite. Notre modèle ne permet pas de stocker di-rectement les valeurs des indicateurs de fréquence différentes de ces 3 fréquences (jour, mois et an). Un indicateur qui possède une fré-quence de mesure autre que ces 3 fréfré-quences doit subir d’abord au niveau du processus d’ETL une agrégation (somme ou moyenne) de données jusqu’à sa véritable fréquence de mesure (exemple : agré-gation des jours pour former une valeur hebdomadaire) et vice versa avant d’être stocké dans l’entrepôt . Nous reviendrons plus en détail sur ces cas dans la section consacrée à l’intégration des données dans l’entrepôt (section 4.2).

Ainsi, nous obtenons un nouveau modèle multidimensionnel des données de notre entrepôt. Ce modèle mixte de données est présenté à la figure 4.3.

Une fois le modèle de notre entrepôt sur pied, il est nécessaire de définir le modèle logique relationnel correspondant. Ce modèle per-met de passer des concepts de « dimensions », de « mesures » et

Système d’Aide à la Décision pour la gestion urbaine : application à la ville de Porto-Novo, Bénin

Figure4.3 – Modèle mixte de l’entrepôt de données du système

d’« hiérarchies », aux notions des bases de données relationnelles : tables, attributs, relations et contraintes d’intégrité. L’approche ROLAP permet de réaliser cette correspondance. En appliquant les différentes correspondances établies par ROLAP, on obtient à la figure 4.4 le mo-dèle logique relationnel de notre entrepôt.

Figure4.4 – Diagramme de classe de l’entrepôt de données du système

4.1.3 Architecture physique de stockage des données dans