Le reporting et la BI
Principes de spécifications[modifier | modifier le wikicode]
En l'état de la découverte que nous avons pu faire des outils de reporting et de BI, nous observons qu'il y a toujours des queries en SQL à gérer pour faire le reporting.
Les sujets d'architecture du sous-système de reporting dans un SI ne sont pas abordés ici. Que les queries que l'on a besoin d'écrire s'exécutent ici ou là dans l'architecture, il faudra de toutes façons les écrire.
L'idée sous-jacente à une bonne approche de l'organisation de queries est que (audéaprt) le schéma de la base de données de production obéit aux contraintes de la production et non aux besoins de reporting. Dans la vie du système, lorsque le besoin de faire du reproting se sera imposé il est possible que des évolutions sur le schéma aient été faite pour faciliter le reporting ou tout simplement le rendre possible. Noter que cela n'est pas toujours possible pour des raisons techniques, organisationnelles ou contractuelles.
Quoiqu'il en soit, une base de données ne peut donner de l'information que ce que sur ce qu'elle contient, il est inutile de lui poser des questions sur ce qu'elle ne sait pas. N'importe qeulle quesiotn n'a pas nécesairement de sens sur n'importe quelle base de données.
La bonne démarche consiste donc en parallèle à faire dire à la base tout ce qu'elle sait et à analyser les besoins de connaissances des utilisateurs.
Concrètement celà se traduit dans une organisation de requêtes en couches, des couches vont être construites dans une démarche bottom up depuis les tables vers le sutilisaeurs et dans une démarche top down depuis les questions que se posent les utilisateurs.
Bottom - Up[modifier | modifier le wikicode]
On part des tables de la base et l'on construit d'abord une couche sémantique uniquement destinées à se mettre dans le vocabulaire de l'application. On parlera ici d'objets. Il s'agit de la démarche inverse de la démarche de spécification lorsqu'on identifie les objets du domaine et que dans une démarche descendante on en déduit le schéma de la base de données. Ici on remaonte vers les objets du domaine. A priori à ce stade, il n'y a pas de restriction sur les sélections, tous les contenu est affiché.
Top - down[modifier | modifier le wikicode]
A partir d'une analyse de besoins, des requêtes sont décrites dans le langage des utilisateurs.
Synthèse - jonction : la bas du haut et le haut du bas.[modifier | modifier le wikicode]
Naturellement les deux démarches se rencontrent et le bas de la couche du haut vient s'encastrer naturellement dans le haut de la couche du bas.
Si ce n'est pas le cas, la démarche revèle automaitiquement une difficulté de compréhension entre les acteurs du processus et il y a lieu d'entrer dans un processus de résolution de problème plutôt que de s'acharner à faire dire à la base ce qu'elle ne sait pas.
La clé sera trouvée soit ou en partie dans une meilleure formation des utilisateurs pour recadrer leur connaissance du système et éviter qu'ils en attendent ce pourquoi il n'est pas fait.
Mais ce peut être aussi un défaut du système et il faut pour résoudre le problème réaliser des modifications sur le système s'il s'évère qu'il ne répond psa correctement au xbeosins des utilisateurs. Cela pourra se faire dans le cadre d'une gesiton de versions, on planifiera dans la plus prochaine version des améliorations pour répondre aux besoins de reporting.
Les principaux défauts que l'on rencontre ici sont :
* L'absence de clé de jointure entre deux informations ( sous-systèmes étrangers) * Le non enregistrement d'une information dans la base, en général des traces insuffisantes sur les événeemnts qui se produisent dans le système.
