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

Outils de restitution et d'analyse Discussion :

Reporting à temps réel


Sujet :

Outils de restitution et d'analyse

  1. #1
    Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    mars 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Maroc

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

    Informations forums :
    Inscription : mars 2016
    Messages : 5
    Points : 3
    Points
    3
    Par défaut Reporting à temps réel
    Bonjour,

    J'ai comme projet un système de reporting à temps réel, je suis vraiment perdue, je n'ai aucune idée sur les étapes de ce type de reporting.

    S'agit-il des mêmes étapes du reporting périodique? ou y a-t-il une différence?

    Merci d'avance de votre aide.

  2. #2
    Membre émérite Avatar de nuke_y
    Profil pro
    Indépendant en analyse de données
    Inscrit en
    mai 2004
    Messages
    2 076
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Indépendant en analyse de données

    Informations forums :
    Inscription : mai 2004
    Messages : 2 076
    Points : 2 329
    Points
    2 329
    Par défaut
    Bonjour, ce qui serait bien ce serait d'avoir plus de 3 lignes pour décrire le contexte, le besoin, les contraintes. J'ai l'impression que plus le sujet est complexe, moins les gens donnent d'information.

    Sinon, le temps réel implique, normalement, une latence extrêmement faible. L'idée c'est que quand le reporting est réalisé, les données ramenées soient représentatives de ce qu'il y avait dans la BDD à l'instant exact du lancement du rapport. Donc si un utilisateur vient de saisir une facture dans le système, il s'attend à la voir apparaître tout de suite dans son rapport. Par contre si par "temps réel" vous entendez "une latence de l'ordre du 1/4h", vous pouvez oublier tout le contenu de ce post.

    Donc qui dit temps réel dit (en principe)
    - pas d'ETL, éventuellement un EAI par contre
    - pas de modélisation en étoile
    - pas de technologie in memory (du moins pas que je connaisse) ou de cube (à cause de la latence induite par la montée en RAM du modèle commun, mais on peut trouver des solutions avancées)

    On va plutôt être sur de la génération de requête, du BO, du Cognos ou simplement une application web. C'est à dire qu'une action utilisateur va déclencher une requête SQL, exécutée immédiatement, et qui va ramener les données présentes dans la BDD à ce moment-là. La solution consiste donc à préparer des requêtes SQL (ou un modèle de données pour BO/Cognos) et à permettre à l'utilisateur de choisir des filtres à appliquer puis de cliquer sur un bouton. Le clic va générer une requête SQL à la volée, incluant les filtres choisis par l'utilisateur, qui va être exécutée sur le champ dans la BDD et renvoyer les résultats. Charge à vous de les afficher à l'utilisateur.

    Une autre solution consiste à faire du Complex Event Processing (CEP): un outil va recevoir des messages au fur et à mesure de l'activité sur la source (base de données, site web) et va accumuler ces messages pour une utilisation ultérieure. Exemple: on veut détecter si plus de 3 connexions ratées ont eu lieu en 15mn, et envoyer un mail d'alerte si c'est le cas.
    A la 1ere connexion ratée, un message "connexion ratée" est envoyé au CEP (je simplifie) qui déclenche un chronomètre.
    A la 2e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 2e ratée d'affilé".
    A la 3e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 3e ratée d'affilé", il regarde son chronomètre et constate que c'est la 3e en moins de 15mn, donc il déclenche une alerte.
    Pour faire la même chose sans CEP il faudrait faire des requêtes en boucle toutes les 15 mn qui vérifient si 3 connexions ont raté dans les 15 dernières minutes. C'est très lourd.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  3. #3
    Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    mars 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Maroc

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

    Informations forums :
    Inscription : mars 2016
    Messages : 5
    Points : 3
    Points
    3
    Par défaut
    Bonjour,

    Merci beaucoup pour cette explication.

    Il s'agit d'un reporting à temps réel (pas vraiment temps réel), où on va créer des vues (SQL) qui vont nous permettre de générer des KPIs, le problème est comment transformer les "tables" générées par ces vues en modèles graphiques?

    Vaut-il mieux d'utiliser un outil de reporting (Reporting services...) ou créer une application Web (VS...) pour gérer ça?

    Merci beaucoup!!




    Citation Envoyé par nuke_y Voir le message
    Bonjour, ce qui serait bien ce serait d'avoir plus de 3 lignes pour décrire le contexte, le besoin, les contraintes. J'ai l'impression que plus le sujet est complexe, moins les gens donnent d'information.

    Sinon, le temps réel implique, normalement, une latence extrêmement faible. L'idée c'est que quand le reporting est réalisé, les données ramenées soient représentatives de ce qu'il y avait dans la BDD à l'instant exact du lancement du rapport. Donc si un utilisateur vient de saisir une facture dans le système, il s'attend à la voir apparaître tout de suite dans son rapport. Par contre si par "temps réel" vous entendez "une latence de l'ordre du 1/4h", vous pouvez oublier tout le contenu de ce post.

    Donc qui dit temps réel dit (en principe)
    - pas d'ETL, éventuellement un EAI par contre
    - pas de modélisation en étoile
    - pas de technologie in memory (du moins pas que je connaisse) ou de cube (à cause de la latence induite par la montée en RAM du modèle commun, mais on peut trouver des solutions avancées)

    On va plutôt être sur de la génération de requête, du BO, du Cognos ou simplement une application web. C'est à dire qu'une action utilisateur va déclencher une requête SQL, exécutée immédiatement, et qui va ramener les données présentes dans la BDD à ce moment-là. La solution consiste donc à préparer des requêtes SQL (ou un modèle de données pour BO/Cognos) et à permettre à l'utilisateur de choisir des filtres à appliquer puis de cliquer sur un bouton. Le clic va générer une requête SQL à la volée, incluant les filtres choisis par l'utilisateur, qui va être exécutée sur le champ dans la BDD et renvoyer les résultats. Charge à vous de les afficher à l'utilisateur.

    Une autre solution consiste à faire du Complex Event Processing (CEP): un outil va recevoir des messages au fur et à mesure de l'activité sur la source (base de données, site web) et va accumuler ces messages pour une utilisation ultérieure. Exemple: on veut détecter si plus de 3 connexions ratées ont eu lieu en 15mn, et envoyer un mail d'alerte si c'est le cas.
    A la 1ere connexion ratée, un message "connexion ratée" est envoyé au CEP (je simplifie) qui déclenche un chronomètre.
    A la 2e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 2e ratée d'affilé".
    A la 3e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 3e ratée d'affilé", il regarde son chronomètre et constate que c'est la 3e en moins de 15mn, donc il déclenche une alerte.
    Pour faire la même chose sans CEP il faudrait faire des requêtes en boucle toutes les 15 mn qui vérifient si 3 connexions ont raté dans les 15 dernières minutes. C'est très lourd.

  4. #4
    Membre émérite Avatar de nuke_y
    Profil pro
    Indépendant en analyse de données
    Inscrit en
    mai 2004
    Messages
    2 076
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Indépendant en analyse de données

    Informations forums :
    Inscription : mai 2004
    Messages : 2 076
    Points : 2 329
    Points
    2 329
    Par défaut
    Donc ce n'est pas du temps réel, mais en plus vous avez déjà une partie de la solution.

    Alors si la base de données est SQLServer, l'idéal est sûrement de partir sur du Reporting Services (SSRS) effectivement. Le seul intérêt de faire du Web serait d'avoir une meilleure intégration web : responsive design, mobile, intégration dans un portail, ce genre de choses.

    Mais s'il s'agit de produire un petit tableau, un graphique camembert, un graphique en bâtons à partir de données dans une table (ou via une vue, aucune différence), SSRS sera très bien.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  5. #5
    Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    mars 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Maroc

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

    Informations forums :
    Inscription : mars 2016
    Messages : 5
    Points : 3
    Points
    3
    Par défaut
    Je devrais avoir à la fin des vues graphiques très élégantes et très significatives, autrement dit, pour certains KPIs, je devrais avoir des jauges, pour d'autres, des bâtons..., en plus, j'ai la contrainte du coût...

    Je ne sais pas quoi faire?





    Citation Envoyé par nuke_y Voir le message
    Donc ce n'est pas du temps réel, mais en plus vous avez déjà une partie de la solution.

    Alors si la base de données est SQLServer, l'idéal est sûrement de partir sur du Reporting Services (SSRS) effectivement. Le seul intérêt de faire du Web serait d'avoir une meilleure intégration web : responsive design, mobile, intégration dans un portail, ce genre de choses.

    Mais s'il s'agit de produire un petit tableau, un graphique camembert, un graphique en bâtons à partir de données dans une table (ou via une vue, aucune différence), SSRS sera très bien.

  6. #6
    Membre émérite Avatar de nuke_y
    Profil pro
    Indépendant en analyse de données
    Inscrit en
    mai 2004
    Messages
    2 076
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Indépendant en analyse de données

    Informations forums :
    Inscription : mai 2004
    Messages : 2 076
    Points : 2 329
    Points
    2 329
    Par défaut
    Citation Envoyé par nuke_y Voir le message
    [...]SSRS sera très bien.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  7. #7
    Membre averti
    Homme Profil pro
    Chef de projet décisionnel
    Inscrit en
    mai 2012
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations professionnelles :
    Activité : Chef de projet décisionnel
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 224
    Points : 369
    Points
    369
    Par défaut
    SSRS comme l'a dit Nuke_y, ou PowerBI.
    https://powerbi.microsoft.com

  8. #8
    Candidat au Club
    Femme Profil pro
    Étudiant
    Inscrit en
    mars 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Maroc

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

    Informations forums :
    Inscription : mars 2016
    Messages : 5
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par thibault974 Voir le message
    SSRS comme l'a dit Nuke_y, ou PowerBI.
    https://powerbi.microsoft.com
    Merci pour l'idée.
    Pour résoudre à mon problème, je suis actuellement entrain de faire une étude comparative entre SSRS et d'autres alternatives en prenant en considération
    le coût et d'autres critères.
    Veuillez me donner des idées sur les alternatives que je peux prendre en considération (Open source ou coût faible).

    Merci d'avance.

  9. #9
    Membre régulier
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    août 2014
    Messages
    103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2014
    Messages : 103
    Points : 118
    Points
    118
    Par défaut
    Bonjour,

    Tu as différents logiciels de reporting.
    Comme dit au dessus SSRS et PowerBI sont des solutions viables si tu utilise SQL Server.

    Après il faut voir ce que tu entends derrière faible coût, mais il existe beaucoup de solutions de reporting et de construction de tableau de bords.
    - Qlik View
    - Tableau
    - Penthao (open source et... gratuit si je ne m'abuse)
    - Bi Board
    - Dig Dash
    etc...

    Mais un outils gratuit et non lié à un système de base de données... bon courage pour trouver.

    Cordialement,

    Slaveak

Discussions similaires

  1. Mise à jour en temps réel de la base de données
    Par Clotilde dans le forum Bases de données
    Réponses: 2
    Dernier message: 11/06/2004, 22h09
  2. [MFC] graphique temps réel
    Par _Thomas_ dans le forum MFC
    Réponses: 10
    Dernier message: 01/06/2004, 11h56
  3. Voir requête éxécuté en temps réel ?
    Par [DreaMs] dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 08/01/2004, 14h52
  4. cubes temps réel en ROLAP
    Par Guizz dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 09/07/2003, 16h36
  5. Durée d'un traitement temps réel
    Par Almex dans le forum C
    Réponses: 5
    Dernier message: 29/03/2003, 14h15

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