IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Alimentation Discussion :

[Data Warehouse] Datamart, cube : différence


Sujet :

Alimentation

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut [Data Warehouse] Datamart, cube : différence
    Bonjour à tous

    Je me lance dans le domaine de la Business Intelligence et veux mettre au point un petit datawarehouse pour analyser les ventes d'un petit magasin (donc à titre purement didactique pour moi)

    Seulement, après quelques lectures, recherches sur le sujet je me pose des questions.

    Quelles sont les différence entre un datawarehouse, un datamart et un cube?

    Voici ma vision, corrigez moi si je me trompe :

    • Un cube OLAP est une base de données multidimensionnelle. Or une base de données multidimensionnelle est modélisée selon une table des faits et des dimensions s'y rapportant.


    • Un datamart est un petit datawarehouse qui concerne un seul thème. Mais si je veux créer un datawarehouse autour du thème des ventes, est-ce que le datamart est considéré comme datawarehouse? Le datamart est donc aussi une base multidimensionnelle donc une structure en cube?


    • Le datawarehouse se compose d'un ensemble de datamart ou se décompose en un ensemble de datamarts mais est également une structure en cube



    En conclusion pour le moment, ma perception des choses est la suivante

    -> Datawarehouse = ensemble de cubes thématiques (datamart)
    -> datamart = cube OLAP
    -> cube = structure multidimensionnel stockant des données à des fin d'analyse


    Merci pour vos éclaircissements qui me seront indispensables pour continuer ce projet.

    Pmatt

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 115
    Points : 28 479
    Points
    28 479
    Par défaut
    Citation Envoyé par Pmatt
    Un cube OLAP est une base de données multidimensionnelle. Or une base de données multidimensionnelle est modélisée selon une table des faits et des dimensions s'y rapportant.
    Dans le cube OLAP, les cellules son précalculées.

    Citation Envoyé par Pmatt
    Un datamart est un petit datawarehouse qui concerne un seul thème. Mais si je veux créer un datawarehouse autour du thème des ventes, est-ce que le datamart est considéré comme datawarehouse? Le datamart est donc aussi une base multidimensionnelle donc une structure en cube?
    Au niveau de l'entrepôt de données, les faits détaillés sont conservés. Dans le datamart, un certain niveau d'agrégation a déjà été effectué et on perd le détail des faits.

    Citation Envoyé par Pmatt
    Le datawarehouse se compose d'un ensemble de datamart ou se décompose en un ensemble de datamarts mais est également une structure en cube
    A strictement parler, l'entrepôt de données ne comporte que les faits détaillés et les hériarchies dimensionnelles. Les cubes sont préparés à partir des données de l'entrepôt.

  3. #3
    Membre habitué Avatar de GGGGG
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    149
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 149
    Points : 150
    Points
    150
    Par défaut
    Citation Envoyé par Pmatt
    -> Datawarehouse = ensemble de cubes thématiques (datamart)
    -> datamart = cube OLAP
    -> cube = structure multidimensionnel stockant des données à des fin d'analyse
    Je me permets malgré mon manque d'expérience de vous répondre.
    Je pense que le cube est complémentaire au Data warehouse et au Datamart.
    C'est pourquoi, je ne pense pas qu'un datamart soit un cube olap mais juste une base relationelle (la meme chose pour l'entrepot de données d'ailleurs).

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Merci al1_24 et GGGGG pour vos réponses .

    Donc si j'ai bien compris :

    -> Le datawarehouse possède le niveau d'information le plus détaillé
    -> Le datamart possèdes des données agrégées, moins détaillées

    Par contre, que voulez vous dire par cellules précalculées?

    Je vais construire une petite solution décisionnelle avec Analysis Services 2005, de Microsoft.

    GGGGG, lorsque tu dis qu'un datamart et datawarehouse sont des bases relationelles, je suppose que tu veux parler de ROLAP ?

    Donc dans mon projet en fait il serait plus approprié de parler de Cube créé par Analysis Services qui se baserait sur des vues construites par l'utilisateur mais au fond, l'information du cube serait directement tirée de la base de données relationnelle OLTP.

    Bref comme vous le voyez, tout n'est pas encore clair.

    Avez vous de bons liens ou livres à me conseiller sur le sujet?

    Merci pour votre patience et la pertinence de vos réponses

  5. #5
    Membre habitué Avatar de GGGGG
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    149
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 149
    Points : 150
    Points
    150
    Par défaut
    Alors, il semble que les bases multidimensionnelles impliquent un nombre limité de ligne contrairement au base relationnelle qui peuvent en avoir une infinité ce qui justifirait que les DW sont relationels

    Tu trouveras quelques infos sur ce site je pense : http://www.nodesway.com/business-int...telligence.htm

  6. #6
    Membre confirmé

    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    Juillet 2006
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2006
    Messages : 224
    Points : 467
    Points
    467
    Par défaut
    houlala ... ça part un peu dans tous les sens ...


    Un datawarehouse, ou entrepôt de données :

    Voir wikipedia

    Un datamart :

    Re-voir Wikipedia

    Un cube Olap ou Hypercube :

    Encore un coup sur Wikipedia


    Désolé de te renvoyer vers ces articles, mais ils me semblent très clair et je pense, répondent à tes questions.

    Pour préciser un peu sur les cube, le concept d'OLAP est un concept "générique" qui peut être décliné différement selon les éditeurs de solutions décisionnelles.

    Pour Analysis Services de microsoft, on est dans le R-OLAP : Les données sont stockées dans une base de données relationnelle.

    Chez cognos, ils font plus dans le M-OLAP (je ne sais plus ce que veux dire le M)... le principe est que les données sont extraites de la base pour générer un fichier (le cube)

    L'avantage du R-OLAP, c'est qu'une fois que la base est à jour, le cube est à jour ... L'avantage du M Olap, c'est une navigation plus rapide car les données sont précalculées lors de la génération du cube.

  7. #7
    Membre habitué Avatar de GGGGG
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    149
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 149
    Points : 150
    Points
    150
    Par défaut
    Oula, j'ai raconté des conneries ^^

    Merci brunolf /me est un peu moins con

    Il y a aussi le H-OLAP pour Hybride entre le R de Relationnel et le M de Multidimensionnel. Le reste de l'explication sur le wiki

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 42
    Points : 47
    Points
    47
    Par défaut
    Le M de M-OLAP veut dire multidimensionnelle
    Le M-OLAP est un OLAP optimisé pour l'analyse multidimensionnelle.
    C'est une forme d'hypercube multidimensionnel qui permet de représenter les données sous la forme d'un croisement de n dimensions, ces dimensions pouvant être plus ou moins denses, caractérisant ainsi la densité ou sparsité du cube.

    Il existe également le H-OLAP, qui est un Hybride entre le M-OLAP et le R-OLAP.
    La structure multidimensionnelle d'un hypercube est utilisée pour les données agrégées. Lorsque l'accès à un niveau de détail élémentaire plus fin est nécessaire, des tables relationnelles classiques sont utilisées : c'est le mécanisme du drill through.

    Sinon, effectivement le DataWareHouse contient les données de détail mais aussi l'historique des données (le versionning en quelque sorte).
    Le DataMart est lui, une sorte de vue sur un métier, une période, .... à un niveau soit de détail ou/et soit aggrégé. On utilisera un DM au niveau détail pour faire tourner des requêtes ou des cubes plus rapidement. En règle général, on profite du DM pour faire les 2 (vue métier avec données aggrégées par exemple).

    Penser aussi au passage de vos données opérationnelles vers votre DWH, en utilisant pe-être un ODS (Operational Data Store).
    C'est une base de données conçue pour centraliser les données issues de sources hétérogènes afin de faciliter leur intégration dans un DataWareHouse. L'intégration de ces données implique souvent une purge des informations redondantes. Un ODS est généralement destiné à contenir des données quotidiennes (type évènements du jour) de niveau fin.

    Bon courage
    Thierry Babulle
    tbabulle@objectif-informatique.fr

  9. #9
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Merci à tous pour vos réponses constructives

    Bon je vais me pencher en détail ce soir sur ce que vous m'avez dit, et la voila comment je vois la fil conducteur du projet, donnez moi votre avis, si vous voulez bien

    je suis dans un modèle ROLAP.

    J'ai ma base de production OLTP, pour faire du décisionnel c'est pas une bonne structure, je vais donc créer une base dont la strucuture est un schéma en etoile ou en flocon (ces structures sont relationnelles si je ne me trompe).

    Pour remplir cette dernière, je dois d'abord extraire l'information de la base OLTP et la transférer dans une base temporaire (data Staging) avant d'effectuer des transformation sur mon information (assignation des clés de substitution, ...)

    Ensuite je charge tout cela dans ma base décisionnelle d'Analysis Services.

    Pour effectuer des interrogations, j'utilise le langage MDX qui est proche du langage SQL.


    Voila, vous en pensez quoi?

    L'interrogation c'est de savoir s'il faut vraiment faire du data Staging avec du ROLAP et si le langage MDX est adéquat avec ce type de modèle.

    Cordialement,

    Matt qui vous remercie pour votre aide et qui essaie de comprendre tous ces concepts !

  10. #10
    Membre confirmé

    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    Juillet 2006
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Juillet 2006
    Messages : 224
    Points : 467
    Points
    467
    Par défaut
    J'en pense que tu t'approche de la vérité (sur le principe de fonctionnement en tout cas)

    Je ne connais pas analysis services, donc je ne peut pas te dire s'il "cause" en mdx, en sql ou en tout autre langage ... de toute façon, ça n'a guère d'importance.

    L'essentiel dans un projet décisionnel est de bien définir le besoin fonctionnel, puis de bien modèliser ton datawarehouse.

    Dans le cas de l'analyse de tes ventes, si c'est un petit projet, juste pour essayer, ne t'embarque pas dans un modèle en flocon : fait au plus simple.

    un bon vieux modèle en étoile sera parfait pour ton analyse :
    Axe Temps
    |
    Axe Client - Faits (ventes) - Axe Article


    Pour le reste de tes questions, je vais te faire une réponse de normand ... ça dépend : sur un petit projet, la partie "Staging" n'est pas forcément nécessaire ... a condition que tes données soient "propres"

    Si tu intègre des données issues de plusieurs sources ... cette étape deviens vite nécessaire pour éviter les incohérences : tout dépend donc de tes systèmes sources.

    C'est la même chose pour les clés de substitution : si tous tes référentiels sont gérés dans ton systèmes sources avec des ID numériques bien propres ... l'intéret de les substituer par d'autres clés n'a de sens que si tu veux historiser tes référentiels (par l'utilisation de surrogate keys), Sinon, ne te casse pas la tête.

    Bien sûr, ces remarques sont valables pour un petit projet perso pour lequel on veut avoir un résultat rapide, si tes objectifs sont plus ambitieux ... il faut adapter ...

  11. #11
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 057
    Points
    1 057
    Par défaut
    Je ne suis pas expert, mais à mon sens un/des datamarts n'ont d'intérêt que si la table correspondante dans le data warehouse a une granularité trop fine ce qui impllique que la requête sera trop lente.

    Je pense qu'il faut à chaque fois voir si ajouter de la complexité est nécessaire (synchroniser le datamart, faire en sorte que le client accède au datamart pour les requêtes qui peuvent y être faites, ...).

    Pour certains cas simples (une seule base OLTP petite), il n'y a pas besoin de data warehouse du tout.

  12. #12
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Salut, merci pour vos réponses je commence à y voir plus clair et j'éspère que ce post servira à d'autres personnes.

    J'ai réalisé un petit schéma sous visio, illustrant mon plan d'attaque. Vous en pensez quoi?

    • Mes sources peuvent être des fichiers plats, des bdd, ...
    • Il est judicieux de noter la date de dernière modification de chaque champ pour savoir lesquels ont été modifié et donc ce qu'il faut insérer dans le DW
    • J'extrait les champs nécessaires de chaque source que je place dans une bdd temporaire
    • J'effectue des transformation dessus, tels l'ajout de clé de substitution, la consolidation etc
    • j'envoie tout ca dans mon Data Warehouse (ROLAP) qui n'est rien d'autres qu'une base relationnelle comme une autre mais modélisée différemment (flocon ou étoile)
    • Ensuite, Analysis Services Intervient. Il va créér un cube selon la même architecture que le datawarehouse
    • Ce cube à pour but de donner un sens multidimensionnel à la structure relationnelle du datawarehouse.
    • Comme on est en ROLAP, ce cube ne contient aucune données physiques, il les puise dans la bdd relationnelle. Ce cube est mis à jour en temps réel donc.
    • On peut comparer ce cube à une vue multidimensionnelle, créée par Analysis Services. Le client peut effectuer des requêtes MDX, le moteur Analysis Services les convertira en langage SQL et ira interroger le datawarehouse relationnel



    Voila, je commence à être dans le bon ou je suis parti dans le mauvais chemin?

    Merci pour tout !!!!

    Bonne soirées les développeurs

    PMatt ! -=)
    Images attachées Images attachées  

  13. #13
    Membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 42
    Points : 47
    Points
    47
    Par défaut
    Oui, oui, tu es bien parti.

    Pense également que durant les étapes de transformation et de chargement, tu as besoin de controler l'intégrité de tes données, ainsi que leur qualité.
    Sans doute, as tu quelques règles de gestion, que tu peux valider à ce moment-là ?

    Malheureusement, l'expérience montre que les systèmes opérationnels sont souvent source de petits bugs sur les données, d'où une qualité approximative.
    Je te donne un exemple :
    - dans un système opérationnel, il est très possible que tu n'ais pas tous les prix d'achat (PA) de tes produits, mais par contre que tu ais tous les prix de vente(PV), sinon tu ne vends pas !
    - lorsque tu vas vouloir faire la marge par produit, tu vas avoir des produits sans marge, puisque pas de PA, et cela va se voir tout de suite
    - par contre si tu fais la somme des PA et la somme des PV, pour avoir la marge consolidée, bonjour les dégats, et ce n'est pas forcément évident de s'en rendre compte.

    Pense donc aux règles de contrôle et d'intégrité.
    Cela peut également se gérer au niveau de l'historique de tes données dans ton DWH.

    A suivre ...
    Bon courage

    Thierry Babulle
    tbabulle@objectif-informatique.fr

  14. #14
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    je prend bonne note de tes conseils, tbabulle !!

    Quand on y pense, c'est tout un casse tête ce projet de datawarehouse, mais il y a moyen d'y arriver.

    Pour la prochaine étape, je vais créer mon modèle dimensionnel, l'implémenter sous SQL Server et ensuite créer mon cube Analysis services basé sur ce modèle.

    Par contre, pour les étapes de chargement j'ai un peu peur... je vous tient au courant.

    Merci

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Salut à tous

    J'ai un peu avancé dans mon travail et je voudrais avoir votre avis sur ma modélisation en flocon (j'aurais pu faire en étoile, mais c'est dans l'optique d'un exercice pour me familiariser avec tout)

    Voici deux images :

    - Le schéma relationnel simple
    - Le schéma en flocon adapté

    Par rapport à ca, je me pose quelques questions :

    -Est-ce que j'ai correctement transformé le relationnel en dimensionnel??

    Si vous avez des suggestions ou des critiques à faire, n'éhistez pas !

    -Est ce que j'ai bien fait de mettre des clés de substitution partout? En ce qui concerne les dimensions principales ca je pense que c'est bon, mais les hiérarchies c'est pas un peu absurde de leur attribuer des clés de substitution alors que elles n'ont pas d'identifiant dans le système opérationnel (ce sont des dates)... Même question pour les hiérarchies Ville, Région, Pays.. la table localisation dans la bdd à un ID donc on lui attribue une clé de substitution dans le DW, mais les hiérarchies comment leur attribue-t-on un ID dans le DW?

    Et avec le modèle que j'ai designé, pourrons-nous faire des requetes du style " Dans quel région avons nous réalisé le meilleur bénéfice pour les clients agés de 35 ans sur les produits de type velo" ??


    Voila, j'ai encore d'autres questions mais qui viendront par la suite du développement du projet.


    Voila, j'éspère que ca vous plait de suivre ce travail.

    Merci beaucoup pour les commentaires que vous apporterez !!!

    Matt
    Images attachées Images attachées   

  16. #16
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Salut

    Vous n'avez pas une petite idée sur la situation? J'ai en effet peur d'aller plus loin sans une confirmation ou des recommandations sur la justesse des schémas.

    malgré tout je me rend compte qu'on s'éloigne un peu du sujet initial, désolé

    A bientot

  17. #17
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 057
    Points
    1 057
    Par défaut
    Moi je trouve que cela convient. Juste sur la dimension produit, les prix d'achat et de vente vont forcément varier avec le temps. Donc création d'un nouveau produit?

    Personnellement, je le mettrais dans la table de fait.

    Peut-être aussi ajouter des informations dans la dimension temps, par exemple si c'est une veille de jour férié et si c'est un jour férié. Peut-être rajouter des données orientées sur tes données, comme "période avant noel", si ça peut jouer.

  18. #18
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 69
    Points : 53
    Points
    53
    Par défaut
    Salut Jester

    Merci pour ton appréciation concernant mon schéma.

    Pour la dimension Produit comme tu le sais c'est ce qu'on appelle une Slowly Changing Dimension, elle peut varier au cours du temps.
    Dans ce cas-là, Kimball nous donne 3 possibilités
    - Ecraser l'enregistrement
    - Créer un nouvel enregistrement avec une nouvelle clé de substitution
    - Créer un champ "ancien" et y insérer l'ancienne valeur, mais cela n'autorise qu'a avoir 2 versions.

    Ou alors le mieux serait encore comme j'ai pu le lire sur un PDF de développez.com, de mettre un champ version pour chaque produit et indiquer le numéro de version selon les mises-à-jour que l'on a effectué.

    Concernant ma dimension temps, j'ai enlevé 4 champs (Annees, Semaines, Trimestres, Mois) et n'ai laissé que leur clé étrangère vu que le modèle en flocon est normalisé, on évite donc les redondances.

    Je vais voir ce que je peux modifier selon tes conseils.

    Encore merci et à bientot

    Matt

  19. #19
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 057
    Points
    1 057
    Par défaut
    En fait, il n'y a que la solution de créer une nouvelle ligne produit, les autres ne fonctionneront pas (tu finira avec un DWH trop incohérent car tu ne pourra plus calculer le même chiffre d'affaire et bénéfice que celui des faits). Et créer une nouvelle ligne produit risque de compliquer l'analyse (enfin ralentir la requête).

    Ça dépend des produits, mais ils auront au moins de nouveaux prix une fois par an (pour prendre en compte l'inflation), si tu vends du pétrole ce sera quotidien. Si tu autorise à faire des rabais, promotions, ... tu aura aussi une dimension très changeante.

    Moi je le mettrais dans la table de fait. Mais je n'ai plus ton contexte en tête.

    le modèle en flocon est normalisé, on évite donc les redondances.
    Et tu augmentes les jointures.

  20. #20
    Membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 42
    Points : 47
    Points
    47
    Par défaut
    Bonjour,
    Personnellement, je suis partisan de ne JAMAIS rien perdre.
    Donc, malgré les bons conseils de ce cher Ralph, je n'écraserais pas les anciens prix.
    Je pense qu'il est préférable de gérer des versions de données avec des dates de validité.
    Cela permettra par exemple à une direction marketing de pouvoir revenir sur les anciens prix, et de pouvoir anticiper les inflations, d'en tirer les tendances sur les ventes, ect ect ...
    De faire ce pour quoi la BI est faite à savoir de l'aide à la décision, voir de la prospective, voir (allez laissons nous aller) du datamining ....
    Et puis pour une direction financière, cela permettra également de faire des comparatifs sur les CA, en pouvant isoler par exemple les réductions, car celles-ci n'apparaissent pas forcément dans les données, et ce n'est qu'en comparant prix de vente unitaire et prix moyen de vente que l'on peut les constater.
    Tous ces exemples pour dire juste : GARDE TOUTES LES VERSIONS
    A ton service,
    Thierry
    tbabulle@objectif-informatique.fr

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. différence entre BD et data warehouse
    Par pmyriam dans le forum Décisions SGBD
    Réponses: 6
    Dernier message: 17/04/2010, 15h36
  2. Réponses: 7
    Dernier message: 11/04/2006, 20h09
  3. data warehouse builder
    Par elmounia dans le forum Oracle
    Réponses: 1
    Dernier message: 23/10/2005, 19h04
  4. [data warehouse]des liens utiles?
    Par PSYcoZZ dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 19/06/2005, 09h53
  5. Data warehouse?
    Par donny dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 16/03/2005, 18h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo