Mise œuvre de PRD

1. Objectif

Comme la majorité des générateurs de rapports, Pentaho Report Designer permet la conception selon deux modes :

Dans le cadre d’un premier rapport, l’assistant sera utilisé. Cela permettra de découvrir les différentes étapes de conception d’un rapport. Quelques retouches concernant principalement l’ergonomie seront ensuite effectuées.

Les données manipulées dans ce rapport sont issues de la base de données classic_models très utilisée dans les exemples livrés avec les suites logicielles en Informatique Décisionnelle.

Cette base de données est utilisable librement et téléchargeable sur le site du projet BIRT (http://www.eclipse.org/birt/phoenix/db/).

2. Présentation de la base de données classic_models

Dans le téléchargement précité, des versions Microsoft Access et MySQL de cette base de données sont incluses.

Pour la majorité des rapports commentés dans ce chapitre, la base de données MySQL est privilégiée.

Seules quelques tables de cette base de données sont utilisées (Customers, Offices...). À titre indicatif le Modèle Physique de Données (MPD) partiel de cette base est le suivant :

3. Construction du rapport via l’assistant

Dès le lancement de PRD effectué, la page de bienvenue propose de générer un nouveau rapport soit en mode assisté soit en mode manuel :

L’option retenue ici est le recours à l’assistant.

L’étape n°1 (en réalité cette numérotation n’existe pas) présente le choix d’un template (thème graphique). Le template Pentaho, plutôt...

1. Mise en place de la sélection statique

Une sélection statique des enregistrements est un filtrage via la requête SQL du Query sans qu’il soit prévu que l’utilisateur final du rapport puisse intervenir sur la sélection (pas de liste déroulante ou de zone de texte).

Ce rapport, basé comme les précédents sur les données de la table customers, va regrouper dans des sous-tableaux les données correspondant aux clients d’une même ville et ceci uniquement pour les clients français.

Les champs à présenter en colonne sont :

Au niveau de la construction du Query, celui-ci peut encore être appelé Clients et la requête SQL est :

select distinct customerNumber, customerName, city, country, phone
from customers
where country="France"
order by city, customerNumber 

Au niveau de la sélection des champs à afficher (et du regroupement), on procède comme indiqué au paragraphe "Regroupement des données" (le regroupement sur le pays est remplacé par un regroupement sur la ville).

2. Compte-rendu d’exécution...

1. Mise en place de la sélection dynamique

Dans le rapport suivant, une sélection dynamique des enregistrements est prévue et ceci sous la forme d’un paramètre zone de texte.

Ce rapport, basé sur les données de la table customers, va présenter en colonne les champs suivants :

On utilise comme habituellement l’assistant en veillant à ne pas effectuer ni regroupement, ni filtrage.

La requête SQL est :

select customerNumber, customerName, city, country
from customers
order by customerNumber 

Le rapport après les retouches de mise en forme donne ceci à l’exécution :

Il faut maintenant intégrer un paramètre de type zone de texte dans le rapport et ensuite modifier la requête SQL pour tenir compte de ce paramètre.

Sur l’onglet Data de la fenêtre Report Explorer (à afficher par la commande de menu Window - Report Explorer si nécessaire), on crée le paramètre en bas d’arborescence dans le dossier Parameters par un clic droit de souris.

Le paramètre doit avoir les caractéristiques suivantes :

Ensuite, la requête SQL est modifiée...

1. Objectif

Dans le paragraphe "Un premier rapport basé sur des données MySQL" de ce chapitre, un premier rapport avec des données issues de la base de données classic_models gérée par l’intermédiaire du SGBD MySQL a été construit. Le but est ici de réaliser le même rapport par l’intermédiaire de l’assistant à partir de données hébergées par un SGBD Microsoft SQL Server. Il n’est pas nécessaire d’utiliser une version payante de cet outil (Microsoft SQL Server 2008), on peut se contenter d’avoir recours à la version Express de ce même produit.

La procédure d’installation du SGBD Microsoft SQL Server 2008 Express n’est pas décrite ici. Elle est complètement assistée et ne pose donc pas de difficultés majeures.

La création de la base de données classic_models et le chargement des tables ne sont pas non plus décrits. Il est à noter que dans la version Microsoft SQL Server 2008 un assistant d’import de données externes est inclus. La base de données au format Microsoft Access 2003 est récupérable sur le site des Editions ENI. Elle servira à constituer la base de données classic_models au format Microsoft SQL Server.

Dans la suite...

1. Objectif

Dans le compte-rendu d’exécution du rapport précédent, les dates étaient présentées avec la mention de l’heure et les montants sans décimales. Il est relativement aisé de remédier à cela.

Une nouvelle version de ce rapport va être développée, en utilisant cette fois des données extraites de la version MySQL de la base de données classic_models.

2. Définition du Query

Pour le Query qui peut être nommé Règlements des clients, la requête SQL est :

select customerNumber, checkNumber, paymentDate, amount
from payments
order by customerNumber, paymentDate 

3. Alignement des éléments

L’alignement des éléments ne pose pas de difficultés, l’assistant par ailleurs positionne par défaut les champs alphanumériques à gauche, les champs numériques à droite...

Pour remettre en cause les alignements par défaut, on peut :

La seconde solution offre nettement plus de possibilités (police de caractères, alignement du paragraphe, bordures, couleurs...) :...

1. Objectif

Sur la base du rapport développé dans le cadre du paragraphe précédent, réalisons quelques modifications complémentaires :

Bien qu’il soit techniquement envisageable de repartir du rapport précédent, il est fortement conseillé d’utiliser une fois de plus l’assistant de bout en bout. Seules les étapes non vues auparavant dans ce chapitre seront commentées.

2. Définition de la Data Source et du Query

La source de données est inchangée par rapport au paragraphe précédent.

Pour le Query qui peut être nommé Règlements des clients, la requête SQL est :

select customerNumber, checkNumber, paymentDate, amount
from payments
order by customerNumber, paymentDate 

3. Choix des champs et du regroupement

Contrairement à ce que l’on peut envisager intuitivement, il ne faut surtout pas de clause group by dans la requête SQL, le regroupement est à prévoir au niveau de l’assistant lui-même.

4. Choix des champs et du regroupement

La structure du rapport est très simple avec en colonne :

1. Objectif

Il est fréquent que l’on souhaite afficher une valeur non présente dans la base de données. Dans ce cas, cette valeur doit être déterminée soit par un calcul simple soit par un algorithme plus complexe à partir d’un ou de plusieurs champs issus du Query.

Construisons à l’aide de l’assistant toujours, un rapport avec les colonnes suivantes :

Les enregistrements vont être triés en ordre sur le champ employeeNumber, aucun regroupement n’est à prévoir.

La requête SQL associée au Query est :

select employeeNumber, lastName, firstName, jobTitle
from employees
order by employeeNumber 

2. Mise en place d’un champ calculé

Imaginons que l’on souhaite afficher en cinquième colonne une mention traduisant le champ jobTitle selon la règle suivante : Patron si le champ jobTitle a pour valeur President et Employé dans tous les autres cas.

L’élément text-field est sélectionné dans la palette d’icônes à gauche de l’écran et positionné en dernière position dans le bandeau Details. Il faut ensuite intervenir...

1. Objectif

Oublions dans le présent rapport la base de données classic_models en environnement MySQL pour nous consacrer à un type de source de données moins fréquemment utilisé, les classeurs Microsoft Excel.

Le classeur Microsoft Excel Clients.xls contient cinq enregistrements concernant des clients. Ils sont caractérisés par quatre propriétés :

La feuille de calcul unique de ce classeur est également nommée Clients.

Il s’agit d’obtenir une présentation similaire, dans un rapport Pentaho Report Designer, à celle du classeur Excel d’origine.

2. Définition de la Data Source et du Query

Passons une fois de plus par le mode assisté. Au niveau du choix du type de connexion, sélectionnons Table :

Il faut ensuite créer un Query par un clic sur le bouton + dans le cadre Available Queries sur l’écran suivant. On note aussi la présence, en bas d’écran à gauche, d’une icône représentant une feuille de calcul. Cette icône permet la sélection du classeur à retenir comme source de données. La case à cocher Use First Row as Header sert à indiquer si la feuille de calcul contient ou non des titres en première...

1. Objectif

Il est fréquent que l’on souhaite afficher dans un même rapport des données provenant d’une table principale (en-têtes de commandes ou de factures par exemple) et d’une seconde table fournissant les éléments de détail (lignes de détail des commandes ou de factures par exemple). Chaque enregistrement de la seconde table est relié par une clé étrangère à la clé primaire identifiant en général de manière unique chaque enregistrement de la table principale.

Trois approches sont envisageables au niveau de l’élaboration du rapport :

1. Objectif

Il est recommandé d’avoir lu le sous-paragraphe "Objectif" du paragraphe "Utilisation d’une jointure SQL dans le Query" de ce chapitre.

Le rapport qui va être développé pour expliciter la notion de sous-rapports va être basé sur les données suivantes (issues de la version MySQL de la base de données classic_models) :

L’assistant va être une fois de plus utilisé et seules les étapes présentant des spécificités nouvelles vont être décrites.

2. Définition du Query du rapport principal

La requête SQL, nommée Points de vente par exemple, sélectionne uniquement des champs de la table principale offices :

select officeCode, city, phone
from offices
order by officeCode 

3. Sélection des champs et regroupement pour le rapport principal

Les champs à positionner en colonne sont consécutivement :

Aucun regroupement n’est prévu.

4. Compte-rendu d’exécution intermédiaire du rapport principal

Après les retouches ergonomiques habituelles, le rapport principal s’affiche à l’exécution comme suit :...

1. Objectif

Jusqu’à présent dans ce chapitre, les rapports ont été élaborés sous Pentaho Report Designer et exécutés à partir du même environnement :

Pour une exploitation centralisée, ordonnée et sécurisée des rapports, ils doivent être publiés dans le serveur Web Pentaho. Le sous-répertoire dans lequel les rapports sont habituellement placés s’appelle pentaho-solutions, ce sous-répertoire se trouvant dans l’arborescence du répertoire d’installation de la suite BI de Pentaho (C:\Pentaho_CE\Pentaho_BI_Server_CE-3.6.0\biserver-ce par exemple).

On peut, depuis l’explorateur de fichiers du système d’exploitation, créer des sous-répertoires pour ranger les rapports par thématiques et même déposer les documents (rapports, cubes OLAP...) dans ces sous-répertoires sans passer par la fonction publication incluse dans les différents outils Pentaho (Pentaho Report Designer, Pentaho Analysis...).

2. Mot de passe de publication et authentification de l’utilisateur

Pour réaliser une publication depuis Pentaho Report Designer, un mot de passe doit être prévu dans le fichier de configuration...

1. Objectif

Dans le cadre du paragraphe "Utilisation d’une jointure SQL dans le Query" de ce chapitre, il a été évoqué la possibilité pour des données issues à la fois d’une table principale (en-têtes de commandes ou de factures par exemple) et d’une seconde table fournissant les éléments de détail (lignes de détail des commandes ou de factures par exemple) d’élaborer un rapport principal qui permettrait via des liens hypertextes d’appeler un sous-rapport.

Cette technique est connue en Informatique Décisionnelle sous l’appellation Drilling ou Drill Down.

2. Structure du rapport principal

Le rapport principal est basé sur les données suivantes de la table offices de la version MySQL de la base de données classic_models :

Aucun regroupement n’est demandé.

3. Définition du Query du rapport principal

La requête SQL, nommée Points de vente par exemple, est :

select officeCode, city, phone
from offices
order by officeCode 

4. Compte-rendu d’exécution intermédiaire du rapport principal

Après les retouches ergonomiques habituelles, le rapport principal s’affiche à l’exécution comme suit :

Il est important de noter que pour l’instant le sous-rapport n’a pas encore été défini et rattaché...

1. Objectif

En Informatique Décisionnelle, et notamment dans les tableaux de bord de gestion, les décideurs réclament très souvent des résultats sous forme de graphiques (présentations en histogramme, en secteur, en courbe...). Avec Pentaho Report Designer, il est aisé de produire des rapports basés sur de tels graphiques. Pour illustrer la démarche, construisons trois rapports consécutivement.

2. Structure du rapport n°1

Le rapport numéro 1 (PRD_17-1.prpt) est basé sur les données des tables orders, orderdetails et customers de la version MySQL de la base de données classic_models :

Table orders :

Table orderdetails :

Table customers :

3. Définition du Query du rapport n°1

La requête SQL, nommée Commandes par pays par exemple, est définie comme suit  :

select

orders.orderNumber,
orders.orderDate,
orders.customerNumber,

orderdetails.orderNumber,
orderdetails.productCode,
orderdetails.quantityOrdered,
orderdetails.priceEach,
orderdetails.orderLineNumber,
orderdetails.quantityOrdered*orderdetails.priceEach
as prix_ligne,

customers.customerNumber,
customers.customerName,
customers.city,
customers.country

from orders, orderdetails, customers
where orders.orderNumber=orderdetails.orderNumber
and orders.customerNumber=customers.customerNumber

order by customers.country, customers.customerNumber, orders.orderNumber,
orderdetails.orderLineNumber 

4. Sélection...