Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:journal22052019 [2019/05/27 08:37] – florence
+++ boardz:journal22052019 [2026/01/13 08:03] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
 |
-===== JOURNAL DE BORD au 12 Mai 2019 =====
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
+===== JOURNAL DE BORD au 22 Mai 2019 =====
 ===== BoardZ Version 2 =====
@@ Ligne 18: / Ligne 19: @@
 ====Confirmation du fonctionnement des HtmlPanel====
-Le HtmlPanel assemble des Widgets et des Panels en une structure de panneaux imbriqués pour assembler les différentes vues d'indicateurs ensemble
+Le HtmlPanel assemble des Widgets et des Panels en une structure de panneaux imbriqués pour assembler les différentes vues d'indicateurs ensemble.
 ====Structure d'enregistrement des indicateurs====
@@ Ligne 27: / Ligne 28: @@
    *  1/ Un grand datawarehouse unique : les mesures (données individuelles) sont stockées dans une immense table avec plein d'index dessus. Les extractions d'indicateurs doivent effectuer des SELECTs dans cette table avec une combinaison de règles qui focalisent les données intéressantes.
-Problème : si les indicateurs font appel à des "agrégats" ou des fonctions statistiques, la performance sur des centaines de millions d'échantillons peut être catastrophique, en tout cas avec des technologies open-source courantes.
+Contrainte : si les indicateurs font appel à des "agrégats" ou des fonctions statistiques, la performance sur des centaines de millions d'échantillons peut être catastrophique, en tout cas avec des technologies open-source courantes.
-   * 2/ Des stockages localisés ultra spécialisés par donnée et par indicateur (ce que ferait naturellement un développement "pratique" dans architecture préalable) à partir d'objets simples
+   * 2/ Des stockages localisés ultra spécialisés par donnée et par indicateur (ce que ferait naturellement un développement "pratique" dans architecture préalable) à partir d'objets simples.
-Problème : la multiplication de centaines de milliers d'indicateurs simples génère une consommation et un gaspillage mémoire ts important, et il faut administrer une très grande quantité de paramètres pour obtenir un tableau de bord utilisable au niveau métier.
+Contrainte : la multiplication de centaines de milliers d'indicateurs simples génère une consommation et un gaspillage mémoire tous important, et il faut administrer une très grande quantité de paramètres pour obtenir un tableau de bord utilisable au niveau métier.
 Ces deux approches théoriques sont donc fausses toutes les deux dans la réalité opérationnelle.
@@ Ligne 41: / Ligne 43: @@
 Plus concrètement :
-Un indicateur global par exemple, suivre le nombre instantané de connectés sur une plate forme est un indicateur simple. Il peut être monté dans une chaîne d'objets génériques de type "indicateur scalaire". suivre simultanément quelques variantes de cet indicateur (par exemple, les connectés depuis 2 heures) peut être pensé en montant un panneau avec les deux widgets simples sur les deux valeurs.
+Un indicateur global par exemple, suivre le nombre instantané de connectés sur une plate forme est un indicateur simple. Il peut être monté dans une chaîne d'objets génériques de type "indicateur scalaire".
+Suivre simultanément quelques variantes de cet indicateur (par exemple, les connectés depuis 2 heures) peut être pensé en montant un panneau avec les deux widgets simples sur les deux valeurs.
 Maintenant, prenons un indicateur plus complexe qui admet des modalités de paramétrage : je veux savoir le positionnement de chaque utilisateur par rapport aux participants, et ce dans chacun de ses cours. L'indicateur est de type simple, un "ratio", donc un entier. Mais son arité n'est plus simple (scalaire).