Discussion :

[Florent_45]

Bonjour, je travail actuellement sur le développement d'un data warehouse qui contiendra des données géolocalisées ainsi que plusieurs types d'entités (grilles, polygones, points). Je travail sur PostgreSQL/PostGIS.

Dans mon modèle dimensionnel j'ai créé une dimension "localisation" qui devra contenir l'ensemble des entités administratives de France métropolitaine :
- communes,
- cantons,
- départements,
- régions.

La majorité des mesures que contiendront les tables de fait seront des analyses chimiques/physiques de sols (cuivre total, cadmium total, granulométrie, etc.). Il y aura donc plusieurs tables de faits qui contiendront différents types d'analyses, certaines tables auront leurs analyses localisées à la commune tandis que d'autres auront leurs analyses localisées seulement au canton.

Ma question est la suivante :
il est bien nécessaire que je sépare l'ensemble des hiérarchies de la dimension "localisation" dans différentes tables si je souhaite utiliser cette dimension en tant que dimension conforme (pouvoir réutiliser cette dimension pour plusieurs tables de fait) ?

Au final, en floconnant j'aurai donc 4 tables représentant les 4 hierachies de zone administrative, liées à l'aide de clef étrangères :

- table commune : id_commune (PK), id_cant (FK), insee_com, nom_commune srid, the_geom_commune.
- table canton : id_cant (PK), id_dept (FK), code_cant, nom_cant, srid, the_geom_cant.
- table departement : id_dept(PK), id_reg (FK), code_dept, nom_dept, srid, the_geom_dept
- table region : id_reg (PK), code_reg, nom_reg, srid, the_geom_reg.

Que me conseillez vous ?
Merci d'avance pour vos réponses.

[Jester]

4 tables dans un système source (ça peut être stocké dans un schema du DWH, mais pas en accès par l'utilisateur) qui sera utilisé pour générer :

1 seule dans le modèle en étoile. Le volume me semble faible (à vérifier avec la géométrie), ce sera plus rapide et plus simple à requêter de tout avoir dans la même table.

Les 4 première table servent juste à gérer les évolutions, si un nom doit changer, des départements fusionner ... ce sera plus simple de repartir de tables normalisées.

[Florent_45]

Merci de ta réponse Jester, je m’interroge encore mais cette fois pour la dimension temporelle. J'ai encore deux choix, soit d'avoir une dimension temporelle normalisée avec 3 tables (date, mois, année) ou bien une table seule contenant l'ensemble des hiérarchies temporelles

- table dimensionnelle temporelle unique : id_date (PK), date, num_jour, nom_jour, num_mois, nom_mois, num_annee, nom_annee

- tables dimensionnelles normalisées :
- table date : id_date (PK), id_mois (FK), date, num_jour, nom_jour.
- table mois : id_mois (PK), id_annee (FK), num_mois, nom_mois
- table annee : id_annee (PK), num_annee

Toutefois si j'ai deux tables de faits:
- table de fait A contenant des analyses avec une dimension temporelle annuelle.
- table de fait B contenant des analyses avec une dimension temporelle plus précise (date complète JJ/MM/AAAA).

Si j'utilise une seule table de dimension temporelle, comment puis-je gérer le fait que pour la table A seule la hiérarchie année est valide (on a pas de date plus précise que l'année pour l'analyse) tandis que pour la table de fait B toutes les hiérarchies sont valides (année, mois, date) ?

En fait ma question principale est : comment gérer les différentes plages de validités de hiérarchie dans une dimension ?

Merci d'avance, et désolé pour ces questions qui peuvent paraître simple, je débute en data warehouse.

[Jester]

D'un point de vue performance et simplicité d'utilisation, la dim date doit être en une seule table.

Pour la question des granularités, il est possible d'y avoir des dates définies qu'au mois (par exemple une colonne granularité). Perso, je prend une date arbitrairement (la première ou la dernière date de la période). Étrangement ça ne choque pas trop les utilisateurs et ça simplifie la vie de tout le monde.

[beeenj]

Pour ma part ce sont des problématiques dėjà rencontrées.

Et nous avons statué autrement. La granularité des tables de faits changer entre jour mois et année.

On a statué sur deux dimensions jour et mois avec pas mal de libellés différents. Du style pour le mois: 201304, avril 2013, avr 13, 04/13

En tant que pk on a prit le jour en nombre au format yyyymmdd et yyyymm pour le mois

Pour ce qui est de l'année, pas de dimension. La pk est l'année elle même. La donnée se suffit alors à elle-même dans la table de fait.

[Jester]

Vous avez la même colonne de la table de fait qui référence la dimension mois ou jour selon la valeur (ex 201304 -> mois, 20130401 -> jour) ou bien une colonne qui référence la dim mois et une la dim jour?

[beeenj]

ni l'un ni l'autre , on a deux tables de faits avec chacun sa colonne et son grain mois ou jour.

il me semble que c'était ca la question:

Toutefois si j'ai deux tables de faits:
- table de fait A contenant des analyses avec une dimension temporelle annuelle.
- table de fait B contenant des analyses avec une dimension temporelle plus précise (date complète JJ/MM/AAAA).

[Jester]

Au temps pour moi. J'ai l'habitude de devoir mélanger des granularités différentes dans les mêmes tables de faits (budget vs réalisé par exemple).

[doc malkovich]

Pour ce qui est de l'année, pas de dimension. La pk est l'année elle même. La donnée se suffit alors à elle-même dans la table de fait.

A relativiser. Il est toujours bon d'avoir dans une table de dimension spécifique les valeurs possibles, que ce soit pour des requêtes ne ramenant aucune donnée (mais il faut bien afficher l'année), ou pour proposer les années rapidement à l'utilisateur (cas de l'invite dans BO).
En général, une bonne pratique est d'avoir toutes les dimensions en tables (sauf les dégénérées).

Il y aura donc plusieurs tables de faits qui contiendront différents types d'analyses, certaines tables auront leurs analyses localisées à la commune tandis que d'autres auront leurs analyses localisées seulement au canton.

Attention, tu auras le même souci de doublonnage des données que pour les dates avec une seule table en dimensions ... Il y a la solution de la colonne granularité comme le propose jester, ou de faire des vues.
Je pense que tu l'avais compris mais au cas où

[Florent_45]

Merci pour ces réponses, mais je ne suis pas sûr de bien comprendre comment utiliser la colonne de granularité. Ce champ doit être rajouté à la table de dimension, c'est bien ça ?

Du coup, quand je doit décrire un fait dont la hiérarchie temporelle est annuelle je doit indiquer "annuelle" dans le champ granularité? Mais si par la suite je me retrouve avec un autre fait dont la date est la même que précédemment mais dont la granularité est "journalière" comment faire pour avoir ces deux hiérarchies pour un même enregistrement de la table de dimension?

Je sais pas si je suis très clair dans mes propos :s.

[doc malkovich]

Normalement tu as une colonne qui indique le grain de l'enreg.

Mais si par la suite je me retrouve avec un autre fait dont la date est la même que précédemment mais dont la granularité est "journalière" comment faire pour avoir ces deux hiérarchies pour un même enregistrement de la table de dimension?

Non, tu as 2 lignes.

Tu peux aussi avoir la granularité portée dans l'id, sur le format.
Par exemple pour les dates :
2013 --> grain=année
201304 --> grain=mois
20130412 --> grain=jour
Sauf si tu voulais dire autre chose Jester

[Jester]

Oui c'est ce que je pensais avec une colonne granularité dans la dimension temps pour que les interfaces graphiques puissent s'adapter.

Je suis passé dessus dans adventure works (la base de démo de Microsoft), et les données mensuelles sont stockées sur le premier du mois. Donc pas de gestion réelle de la granularité dans le modèle. Solution classique j'ai l'impression.

[doc malkovich]

Dans un univers BO je fais ça généralement pour la dimension "mois" quand j'ai une table temps au jour ; je mets un filtre sur le 1er du mois ...
Ca marche mais ce n'est pas forcément très propre
Et j'ai remarqué que mes congénères ne faisaient pas pareil ... Généralement ils ne mettent rien du tout
Il vaut donc mieux avoir plusieurs tables pour éviter ce genre de dérive (c'est mon avis).

[Florent_45]

Bonjour,

Donc au final vous me conseillez deux solutions :

- Ajouter une colonne "granularité" à ma table de dimension temps, ce qui implique une multiplication du nombre d'enregistrements de la table par autant de granularité différentes. Dans le cas d'une granularité "mois" je récupérerai l'enregistrement du premier jour du mois. Cette méthode étant fonctionnelle mais pas très propre. Cette solution sera moins claire pour l'utilisateur mais les performances seront meilleures (car moins de jointures).

- Ou alors adopter le modèle en flocon, c'est à dire en créant autant de tables qu'il y a de granularités, dans mon cas : une table jour, une table mois et une table année. Ces tables seront liées, et la table de fait sera liée à la table de dimension dont la granularité correspond à celle des faits. Cette solution sera plus claire pour l'utilisateur, mais les performances seront moins bonnes (car plus de jointures).

Au final, je suppose que c'est à moi de faire mon choix ^^.

Je pense m'orienter vers la solution du floconnage pour les dimensions temps et localisation, car j'ai deux types d'utilisations/utilisateurs de prévues pour mon entrepôt :

- Une utilisation plus en amont, de type traitement. Les membres de mon unité souhaitent pouvoir se connecter directement sur l'entrepôt via PGAdmin pour y faire des requêtes et extraire de la données afin de faire des traitements statistiques/géostatistiques (sous le logiciel R). Dans ce cas d'utilisation l'entrepôt est plus utilisé comme une base de données simplifiant l'accès à l'ensemble des données disponibles (centralisation de données de différentes bases opérationnelles), et comme base de données de sauvegarde des résultats des traitements réalisés. On aura donc deux types de données dans l'entrepôt, les données brutes provenant des bases opérationnelles (analyses de terrain), les données élaborées résultants du traitements des données brutes.

- Une utilisation plus en aval, de type décisionnelle. Avec la diffusion des données de l'entrepôt au travers de WebServices, rapports. On pourra alors proposer aux utilisateurs des outils tel que OLAP et/ou SOLAP (car j'ai des composantes géographiques dans mes données), et Geoserver.

Qu'en pensez vous ?

[doc malkovich]

+ les vues ...

Cette solution sera moins claire pour l'utilisateur mais les performances seront meilleures (car moins de jointures).

Pas forcément car tu as plus de données dans la table
Sauf si tu joues avec les partitions.

Au final, je suppose que c'est à moi de faire mon choix ^^.

Tu bosses dans le décisionnel ? On te laisse prendre les décisions

Qu'en pensez vous ?

Ca a l'air classique, un entrepot pour traiter et analyser les données (même si je ne connais pas pgaadmin), et des cubes OLAP pour le reporting.
Ca va pour moi
Je dirais juste que les cubes OLAP ne sont pas indispensables, tu peux faire du reporting simple sur l'entrepot.

[Florent_45]

Merci pour toutes ces réponses, pour les cubes OLAP je verrais en fonction des besoins, pour le moment l'objectif est de créer la structure de l'entrepôt/des datamarts et d'y charger les données des systèmes sources afin que les utilisateurs puissent s'y connecter pour y récupérer/charger de la donnée.

Le sujet est donc résolu.