Discussion :

[Wazzouille]

Bonjour !

Je travaille actuellement à la conception d'un data warehouse et étant novice en la matière, je me retrouve face à une difficulté pour laquelle je ne trouve pas d'informations sur le net.

J'ai une table de fait (Computers) qui est relié à plusieurs dimensions (States, Manufacturer, Location, ...) mais j'ai aussi d'autres tables comme la table Monitor ou encore Printer entre autres. Ces différentes tables de fait (Computers, Printer, Monitor, ...) ont cependant la caractéristique d'être relié aux mêmes dimensions (ou du moins en partie - mais elles ont une bonne base commune de lien). Seules les dimensions de Type et de Modèle sont susceptible de changer par rapport à la table de fait. Dois-je donc les regrouper dans une seule table qui regroupe tout les types et tout les modèles ?

La question que je me pose est :

- Est-ce que je dois créer une table mère qui va reprendre les liens communs aux différentes tables de faits ?
- Est-ce que je dois relier chaque table à chaque dimensions indépendamment des autres ?
- Est-ce que je dois réaliser plusieurs data marts pour chaque table de fait ?

Je préfère éviter la dernière solution dans un soucis de stockage, mais peut-être est-ce la bonne solution ? (J'en doute)

Pouvez-vous me conseiller ? D'avance merci !

Wazzouille

[nuke_y]

Bonjour,

alors avant toute chose, il existe plusieurs écoles pour la modélisation de DWH. Chacune a ses avantages et ses inconvénients. Il est donc impossible de donner LA bonne solution et toute solution, même valable, vous vaudra la mort si votre chef est attaché à une autre école. Donc 1er point: suivez la méthode que conseille votre chef / expert / architecte / mentor / maître de stage.

2e point: on ne voit pas trop le fonctionnel se dégager des informations que vous donnez. Computer, Manufacturer, Printer, tout ça ressemble à des dimensions, pas des faits. Un fait c'est, en général, quelque chose qu'on mesure (ou qu'on trace) et une dimension c'est ce par quoi on le mesure.

Donc si "Computers" est un inventaire des "Computer" présents dans l'organisation, ça veut dire que "Computers" est le fait "Présence dans l'organisation lors de l'inventaire" et "Computer" est la dimension à laquelle on la rattache.

Outre la masturbation intellectuelle si on dit que
"Printers" = est le fait "Présence dans l'organisation lors de l'inventaire" de la dimension "Printer"
"Monitors" = est le fait "Présence dans l'organisation lors de l'inventaire" de la dimension "Monitor"
etc.

On se rend compte que tous les faits sont en fait les mêmes : une présence dans l'organisation lors de l'inventaire.

Dans ce cas on pourrait fusionner tous les faits dans la même table qui reste "Présence dans l'organisation lors de l'inventaire" et fusionner les dimensions "Printer", "Monitor", "Computer" dans une même dimension générique nommée "Objects" par exemple, avec généralisation des attributs communs ("Name", "Manufacturer", etc.). "Location" par contre je le laisserais dans la table de faits, car c'est un attribut qui peut changer dans le temps. Si lors du prochain inventaire la localisation a changé, on sera bien content de ne pas avoir mis "Location" dans la dimension.


Mais on peut aussi faire plus simple en ne voulant pas adopter une modélisation générique et donc en gardant chaque inventaire dans une table de faits séparée. Dans ce cas il deviendra très simple de faire du reporting sur chaque inventaire indépendamment mais beaucoup plus lourd d'avoir une vision unifiée au travers des n inventaires.

La question qui doit donc mener la réflexion c'est : au fait ça sert à quoi ?

[Wazzouille]

Bonjour,

Tout d'abord, merci pour vos 2 réponses ! (Je vais me permettre de répondre aux deux postes en une réponse)

alors avant toute chose, il existe plusieurs écoles pour la modélisation de DWH. Chacune a ses avantages et ses inconvénients. Il est donc impossible de donner LA bonne solution et toute solution, même valable, vous vaudra la mort si votre chef est attaché à une autre école. Donc 1er point: suivez la méthode que conseille votre chef / expert / architecte / mentor / maître de stage.

Effectivement, j'adorerais pouvoir compter sur une personne compétente dans le service informatique où je me trouve, malheureusement, personne ne travaille dans le domaine de la BI, ce qui me laisse plutôt seul au monde

2e point: on ne voit pas trop le fonctionnel se dégager des informations que vous donnez. Computer, Manufacturer, Printer, tout ça ressemble à des dimensions, pas des faits. Un fait c'est, en général, quelque chose qu'on mesure (ou qu'on trace) et une dimension c'est ce par quoi on le mesure.

Donc si "Computers" est un inventaire des "Computer" présents dans l'organisation, ça veut dire que "Computers" est le fait "Présence dans l'organisation lors de l'inventaire" et "Computer" est la dimension à laquelle on la rattache.

Outre la masturbation intellectuelle si on dit que
"Printers" = est le fait "Présence dans l'organisation lors de l'inventaire" de la dimension "Printer"
"Monitors" = est le fait "Présence dans l'organisation lors de l'inventaire" de la dimension "Monitor"
etc.

On se rend compte que tous les faits sont en fait les mêmes : une présence dans l'organisation lors de l'inventaire.

Dans ce cas on pourrait fusionner tous les faits dans la même table qui reste "Présence dans l'organisation lors de l'inventaire" et fusionner les dimensions "Printer", "Monitor", "Computer" dans une même dimension générique nommée "Objects" par exemple, avec généralisation des attributs communs ("Name", "Manufacturer", etc.). "Location" par contre je le laisserais dans la table de faits, car c'est un attribut qui peut changer dans le temps. Si lors du prochain inventaire la localisation a changé, on sera bien content de ne pas avoir mis "Location" dans la dimension.

Effectivement, ce qui intéresse mon directeur est un inventaire des machines présentent dans l'entreprise :

- Combien d'imprimante en état "en service" à l'étage 5 de l'aile A
- Combien de pc en état "déclassé"
- Combien de machine provenant d'un fabricant X
- ...

(En outre d'autres informations mais qui ne me pose pas vraiment de soucis)

Si je comprend bien votre réflexion quant au problème, vous me conseilleriez un schéma de ce type :



La table "Dim Object" étant un répertoire des différentes machines (PC, Serveur, Imprimante) répertoriées.
(Je doute sur la partie droite du schéma et de sa viabilité, je vais travailler sur ce point si vous me confirmez une erreur à ce niveau là)

Dans un tel schéma, je me pose la question de : Que va-t-on trouver dans la table de fait ? Un simple champ contenant le chiffre 1 pour chaque machine présente dans la base de données en plus des foreign key ? Ou peut-on faire quelque chose qui ressemble à un row_count ? C'est sur ce point que ma réflexion ce porte depuis plusieurs jours, sans vraiment rien trouver de très concret... (je m'y prend surement mal), avez-vous une idée ? Encore une fois je me retrouve sans repère dans l'entreprise où je suis actuellement en stage, sans expérience profonde dans le domaine, en plus du fait que je ne connais absolument pas les outils que je vais utiliser, ce pourquoi je me permet d'être aussi prudent dans la conception de ce projet...

Je vous remercie encore une fois pour le temps que vous avez pris à me répondre !

Bien à vous,
Wazzouille

[nuke_y]

Je suis passé par là, moi aussi j'ai découvert la BI sur le tas en stage

Votre modèle, tel que présenté sur l'image, est très bien ne touchez à rien. Le flocon n'est pas une mauvaise chose en soit, surtout que vous n'aurez aucun problème de performance lié au volume de données.

Dans l'idéal une table de faits ne contient rien que:
- des mesures
- des clés vers les dimensions

Dans votre cas il n'y a pas de mesure, car ce n'est qu'un inventaire, l'inventaire est un cas particulier de la BI qui simplifie les choses, donc qui peut rendre la théorie difficile à appliquer car ça parait "trop simple". Par exemple la table "Computers" est, à la fois, la Dimension "Computer" et le fait "Inventaire des objets de type Computer", donc c'est difficile d'accepter que ça soit aussi simple quand on cherche absolument à séparer les dimensions et les faits.

Pour comprendre l'intérêt du modèle, il faut extrapoler un peu : imaginons que vous vouliez mesurer aussi le nombre de pannes. Donc vous avez un fichier qui donne les pannes de chaque machine, avec la date, etc. Dans ce cas vous pouvez avoir plusieurs panne pour 1 machine, voire même 2 pannes pour la même machine le même jour. Donc votre fait deviendra "Pannes des équipements" et dans ce cas, réutiliser les différentes dimensions "Manufacturer", "Object", "Date" va devenir TRES intéressant. Il suffit de remplacer votre table de faits "Inventaire" par le fait "Panne" et votre modèle global reste utilisable. D'un point de vue fonctionnel, avec ces données il devient même possible de calculer des KPI parlants du genre "Taux de panne par ..." avec "..." qui peut être "Manufacturer", "Location", "Type", etc. C'est quand même plus intéressant que de faire du Excel. Bon ça dépend aussi de l'outil de restitution, moi j'utiliserais QlikSense à votre place


Mettre dans le fait un champ qui contient 1 pour chaque ligne est une solution possible, ce n'est pas interdit, la question c'est : à quoi ça sert ? Un simple count(*) fera exactement la même chose. Dans Qlikview/QlikSense c'est intéressant de faire ce champ à valeur unique mais en BDD ce n'est pas nécessaire. Si ça vous parle mieux, faites-le, ça ne casse rien.

[Wazzouille]

Rebonjour !

Merci pour cette réponse rapide et précise !

Je pense comprendre de mieux en mieux ce qu'il m'attend, et ce grâce à vous !

Cependant une dernière question taraude mon esprit, n'y aura-t-il pas de soucis si une FK de la table de fait vaut NULL ?
En effet, les ordinateurs ont un lien vers une dimension "Système d'exploitation" que les périphériques n'ont pas par exemple.
Je ne pense pas que cela pourrait poser un réel problème dans les requêtes, mais sait-on jamais ?

Merci pour le conseille (QlikView/QlikSense), je vais y regarder attentivement ! Je me dirigeais vers SpagoBI mais la plate-forme semble lourde à mettre en place... si je pouvais me l'éviter en faisant la combinaison de Talend et de QlikView, ça n'en serait que meilleur !

Encore un grand merci pour votre aide et votre partage de connaissances !

Bien à vous
Wazzouille

[nuke_y]

Il n'y a pas de table "OS" dans votre modèle donc il n'y avait pas de raison d'en parler. Par contre si vous en ajoutez une, ça aura un impact effectivement. Un null n'est pas problématique du moment qu'on en tient compte lors de l'écriture de la requête et qu'on fait une jointure ouverte. De manière générale, mis à part les problèmes de performances, il vaut mieux commencer en faisant toujours des jointures ouvertes des faits vers les dimensions : il faut essayer de ne JAMAIS perdre de fait, alors qu'une dimension mal jointe ça se repère rapidement.

Il y a plusieurs solutions pour résoudre ce problème de la dimension applicable à seulement une partie des faits:
- ne pas créer une dimension "OS" et stocker tous les attributs dans la table Objet. A quoi servirait la dimension OS ? Juste à faire "propre" ou y a t-il une utilisation réelle ?
- ajouter 3 lignes dans la table "OS":

- "Non Applicable" avec un id particulier connu à l'avance (disons 1 par exemple)
- "Non Renseigné" avec un id particulier connu à l'avance (disons 2 par exemple)
- "Non Reconnu" avec un id particulier connu à l'avance (disons 3 par exemple)

Quand une ligne venant de "Computers" a l'information "OS" vide, on va la mapper sur l'id 2
Quand une ligne venant de "Computers" a l'information "OS" renseignée mais qui ne correspond pas à la liste des OS connus, on va la mapper sur l'id 3
Une ligne venant d'un équipement sans OS va être mappée sur l'id 1
Ainsi le modèle est cohérent, utilisable avec des jointures fermées, etc. Tenter de faire des statistiques sur le nombre d'équipement par OS quand on a des micro-ondes donnera un chiffre sans utilité (puisque l'OS sera "Non Applicable") mais qui ne sera pas faux.

A noter que c'est la raison pour laquelle il n'est pas forcément facile de modéliser un DWH, il faut la connaissance de tout le fonctionnel, les dimensions, les mesures, les références, le Master Data Management, l'historique de l'entreprise, etc. Ou alors on se trompe, et puis on adapte au fur et à mesure, ça marche aussi.

Pour la plateforme, ça depend le but: si c'est de faire des trucs sympas "pour voir" sans forcément le diffuser massivement dans l'entreprise, QlikView ou QlikSense sont très bien, sinon il faut effectivement se pencher sur une plateforme complète et là... ça me parait un peu ambitieux pour un stage.

[Wazzouille]

Le but finale en soit serait de pouvoir dire :

- J'ai 100 machines qui tourne sous w7 pro
- J'ai 200 machines qui tourne sous w8 pro
- J'ai 5 serveurs qui tournent sous CentOS
- ...

Si je reprend votre raisonnement qui est fortement intéressant et au quel je n'aurais sans doute jamais pensé,

1) Je garde ma dimension OS
2) Les faits qui correspondent à un computer seront relié à une ligne de la dimension OS, ceux qui n'ont pas de liens avec un OS sont reliés à l'un des 3 champs que nous avons rajoutés manuellement
3) Si je fais une recherche sur le champ "Non applicable" de la dimension OS, j'obtiendrais une valeur (qui n'est autre que les objects qui n'ont pas de lien avec un OS), qui sera donc inutile mais "pas faux"

Je pense avoir saisi le principe et c'est une merveilleuse idée !

Encore une fois un tout grand merci !

Bien à vous,
Wazzouille

[nuke_y]

Attention ce ne sont pas des champs, ce sont des lignes de la table OS

Si la table OS a 1 clé et 4 attributs, OS_ID, OS_NAME, OS_VERSION, OS_FAMILY, OS_PROCESSOR avec par exemple:
10;Windows XP 32bits;XP;Windows;32
11;Windows Seven 32bits;Seven;Windows;32
12;Windows Seven 64bits;Seven;Windows;64
13;Mac OS X 32;10.7;Mac OS;32
14;Mac OS X 64;10.9;Mac OS;64
15;Ubuntu 9;9;Linux;64
...

on va y ajouter de force 3 lignes:
1;Non Applicable;Non Applicable;Non Applicable;Non Applicable
2;Non Renseigné;Non Renseigné;Non Renseigné;Non Renseigné
3;Non Reconnu;Non Reconnu;Non Reconnu;Non Reconnu

A noter que où se trouve le problème ? Le champ OS_PROCESSOR. Par réflexe on voudrait sûrement le typer comme un Int et pourtant là on veut mettre du texte dedans. Des solutions:
- mettre null (au risque de se retrouver avec le même gag des valeurs null dont il faut tenir compter lors de l'écriture de la requête)
- mettre une valeur 0 pour ne pas mettre null
- mettre une valeur autre pour différencier les 3 cas : 1,2 ou 3 par exemple : dans ce cas on va créer de l'information "fausse" juste pour une histoire de typage de champ
- mettre le champ OS_PROCESSOR en varchar et pas en Int. Quoi ?! Sacrilège, hérésie, meurs païen ! Comment oses-tu "dé-typer" un champ dans un DWH? Et que se passera-t-il si un jour on veut faire des sommes ou des moyennes. Dans ce cas je réponds: "Le gars qui veut faire des sommes ou des moyennes sur un attribut comme celui-là je lui sors les tripes à la petite cuillère, imaginons qu'il survive, il pourra toujours faire un cast à la volée, ça marchera quand même et quand tu vois le peu de cas que les gars du Big Data font du typage, tu ferais mieux te ranger ton bûcher".

Disons que c'est un débat d'expert

[Wazzouille]

Bonjour !

Effectivement j'ai un petit peu mélanger mes mots, mais l'idée était là ! (C'est les puristes qui vont me mettre au bûcher )

Je vous remercie encore une fois pour l'aide que vous m'avez procuré et j'espère un jour pouvoir vous aider à mon tour (c'est beau de rêver )

Bien à vous,
Wazzouille