présentation de business objects

BUSINESS OBJECTS

Présentation du produit
Business Objects, conçu et distribué par la société Business Objects, est un pionnier sur le marché de l’infocentre relationnel Client/Serveur. Comme nous le verrons par la suite, le concept de base de ce produit est son interface basée sur les "objets d’interrogation". Le concept de couche sémantique a d’ailleurs été déposé par l’éditeur et breveté.

L’environnement (société, évolutions)

Précurseur des outils basés sur un catalogue.

Business Objects SA, concepteur du produit, est une société d’origine française fondée par d’anciens managers de la société Oracle, dont l’activité est totalement dédiée aux problèmes d’infocentre relationnel. Créée en Août 1990, Business Objects commercialise l’ancêtre du produit actuel, alors sous DOS, sous le nom de Skipper SQL. En 1991, Skipper SQL est sélectionné par Oracle, à la recherche d’une offre infocentre pour son SGBD. Le produit reste alors très lié à Oracle, qui participe à la distribution du produit.

En Février 1992, Skipper SQL change de nom et devient Business Objects. Puis, il s’ouvre à d’autres sources de données et passe des accords avec BULL, pour intégrer l’outil à l’offre DDA (Distributed Data Architecture) du constructeur.

Depuis la version 3, véritable version graphique laissant résolument de côté le passé " mode caractère " de l’outil, Business Objects s’engage de manière significative dans la voie du Data Warehouse, comme l’illustre son rôle moteur au sein de la Metadata Coalition.

Business Objects a très longtemps été en quasi monopole dans le domaine de l’infocentre relationnel, terme que l’éditeur s’est d’ailleurs approprié avec succès et ce particulièrement en France. Il est aujourd’hui concurrencé sur son créneau par des produits comme Impromptu, GQL ou Esperant.

Capacités d’analyse multidimensionnelle.

Rattrapée, voire dépassée par ses concurrents, Business Objects incorpore dans la version 4 de son produit des fonctionnalités d’analyse multidimensionnelle. L’éditeur fait d’ailleurs partie de l’OLAP Council, ayant pour mission de normaliser les serveurs de données multidimensionnels, et dans un premier temps, l’accès aux données.

En 1995, Business Objects recense 130000 utilisateurs dans le monde, dans tous les secteurs économiques. 1200 références actives sont recensées en France, 3600 dans le monde. Les chiffres d’affaires successifs de la société étaient de 1,6 Millions de dollars en 1991, de 5,7 en 1992, 14,1 en 1993, de 30,2 Millions de dollars en 1994 et de 60,6 millions de dollars en 1995.

Evolution du chiffre d’affaires

Business Objects est par ailleurs un des très rares éditeurs de logiciel français d’envergure internationale. La société dispose d’agences en France (Paris, Lyon, Toulouse), en Europe, en Asie Pacifique et aux Etats-Unis. 29% de son chiffre d’affaires est réalisé en France et Europe du Sud, 14 % en Europe du Nord, 17 % en Grande Bretagne et en Europe de l’est, 37% aux Etats-Unis et 3% en Asie. Business Objects emploie 225 personnes en France.

Projets d’envergure	Business Objects peut aujourd’hui mettre en avant des projets d’envergure, supportant un nombre important d’utilisateurs, se comptant en milliers. Par exemple, Shell a plus de 10000 utilisateurs et EDF-GDF plus de 7000.
Partenariats nombreux	Actuellement, Business Objects multiplie les partenariats, ce qui renforce sa stabilité et sa crédibilité sur le marché. Parmi ceux-ci, notons :

les éditeurs de bases de données

les éditeurs de middleware ou spécialisés dans les solutions de Data Warehouse

les constructeurs

les éditeurs d’AGL

les éditeurs d’outils de Data Mining

Les plates-formes supportées

Architecture 32 bits	La version 4 de Business Objects est bâtie sur une architecture 32 bits. Elle fonctionne sous Windows 3.1, Windows 95 et Windows NT. Le support de plates-formes Unix est annoncé pour le courant de l’année 1997.
Accès à des bases de données relationnelles.	Business Objects s’interface directement à Oracle, RDB, Ingres, Microsoft SQLServer, Sybase, Informix, Teradata, EDA/SQL, DRDA MicroDecisionware de Sybase (passerelles d’accès à DB2). Depuis la version 3, Business Objects est compatible ODBC. Pour être certain de la totale compatibilité entre le driver et Business Objects, l’éditeur certifie des drivers ODBC et notamment ceux d’Intersolv pour Dbase et SQLBase ainsi que ceux de Rochester Software pour AS400.
Accès à des serveurs de données multidimensionnels.	Des accords ont également été passés avec des éditeurs d’outils OLAP. Ainsi, les données stockées sur le serveur Express sont directement accessibles à partir de l’outil. Les supports d’Essbase d’Arbor Software, de METAcube d’Informix et de Panorama de Microsoft sont également annoncés.
Accès à des données de progiciels.	Business Objects permet également d’accéder aux données de certains progiciels, aujourd’hui SAP R/3, PeopleSoft et Oracle Applications. Pour cela, il propose des RDT (Rapid Deployment Template), des kits de déploiement rapide. Ils apportent une représentation métier adaptée aux données du logiciel. Ainsi, 15 univers sont fournis pour accéder aux données du module LIS de SAP R/3, permettant de gérer les ventes, les commandes et le contrôle de qualité.

La version complète de Business Objects, inclut

Designer

Supervisor

Reporter

Explorer

Document Agent

Un produit, Business Query pour Excel, permet, à partir du produit de Microsoft, d’utiliser les méta-données de Business Objects pour accéder au Data Warehouse.

Architecture de l’offre Business Objects

Le petit dernier édité par Business Objects est BusinessMiner, un outil de Data Mining permettant de créer des arbres de décision.

Accès aux données
Business Objects dispose d’une interface de définition de requêtes de haut niveau. Il permet en effet de masquer la structure de la base de données.

L’outil s’appuie sur deux notions importantes : les univers et les objetsdumétier.

L’utilisateur manipule des objets qui lui sont familiers, les " objets du métier ", regroupés dans des univers.

Ces objets sont des informations élémentaires, calculées ou agrégées.

Un univers est une représentation totale ou partielle de la base de données, correspondant à des besoins particuliers d’un utilisateur et constitué d’un ensemble d’objets du métier. Ces objets sont des informations élémentaires, calculées ou agrégées, issues de la base de données. Des exemples d’objets du métier sont le client, le produit (objets issus de la base de données), le mois, l’année, le prix T.T.C. (objets calculés) ou le chiffre d’affaires (objets agrégés). L’utilisateur qui travaille sur un univers choisit les objets qu’il souhaite sélectionner, spécifie les restrictions ou les tris.

L’originalité du langage tient à plusieurs points :

L’utilisateur ne manipule pas des noms de tables ou de colonnes, mais des noms d’objets correspondant à sa vision du système. C’est pour cette raison que l’interface de Business Objects s’appelle Business Intelligent Querying. Il n’a pas à définir les liens à établir entre les différentes relations (jointures), ni les critères de groupement.

Objets sémantiquement dynamiques

Les objets agrégés sont sémantiquement dynamiques : par exemple, le chiffre d’affaires, objet préalablement défini par un administrateur, prendra un sens par rapport au contexte de l’utilisateur qui définira des requêtes en associant les "objets du métier" (chiffre d’affaires par client, par produit).

Analyse multidimensionnelle

A chacun des indicateurs est associée une fonction d’agrégation (somme, minimum, maximum, nombre, moyenne) ;

Afin de permettre d’effectuer de l’analyse multidimensionnelle, les objets numériques peuvent être définis comme étant des indicateurs, une fonction d’agrégation leur est alors assignée. On peut cependant regretter qu’aujourd’hui les fonctions disponibles soient sommaires (somme, minimum, maximum, moyenne, compte).

Définition d’un indicateur

Pas de variable d’état	Il n’est de plus pas possible de créer des variables d’état, pas agrégées mais prenant leur valeur à un instant donné. Par exemple, pour calculer le stock du mois de janvier, faire la somme du stock présent les différents jours du mois n’a pas de sens. Il faut récupérer la valeur du stock à une date donnée, par exemple le 1^er du mois.
Tout objet qui n’est pas défini comme indicateur peut être utilisé comme dimension.	En fait, tout objet qui n’est pas défini comme étant un indicateur peut par défaut tenir lieu de dimension. Un autre type d’objet, " information ", est relié à cette notion de dimension. Il s’agit d’objets associés à une dimension, apportant des informations complémentaires. Il peut par exemple s’agir d’un numéro de téléphone. La définition d’information permet d’éviter que certains objets ne soient pas manipulés en tant que dimension, ce qui peut notamment influencer sur les performances. Ainsi, prendre le numéro de téléphone n’a d’une part pas de sens et d’autre part engendrerait des temps de réponse médiocres car la base de données n’a pas été créée pour cela et ne contient certainement pas d’index sur le numéro de téléphone.
Les dimensions peuvent être organisées de manière hiérarchique.	Les dimensions peuvent être divisées en hiérarchies. Par exemple la dimension temps contient la hiérarchie " année trimestre mois semaine jour ". Ce travail peut être fait par l’administrateur lors de la définition de l’univers ou par l’utilisateur lors de son exploration des données. Une dimension temps peut être automatiquement créée à partir d’une donnée de type date, les objets année, trimestre, mois sont ainsi créés. Cette dimension est très élémentaire. Il n’est par exemple pas possible de créer des objets du type mois courant, mois précédent.

Définition des univers
Pour mieux comprendre le mécanisme de Business Objects, il semble important de décrire le travail de l’administrateur qui doit précéder toute utilisation de l’outil par l’utilisateur final. L’univers est une collection d’objets manipulés par l’utilisateur, qui doivent préalablement être définis par l’administrateur.

Un univers est en général destiné à un secteur particulier (finances, ressources humaines..)

Un univers est en général destiné à un groupe de travail (exemple : univers marketing, univers commercial, gestion du personnel) et nous verrons par la suite que les univers sont associés à des utilisateurs habilités.

Les objets

Faire correspondre une vue logique et une vue technique.

Définir un objet du métier consiste à faire correspondre une vue logique et une vue technique, sous la forme d’une correspondance SQL, pouvant contenir à la fois les noms de colonnes et les fonctions du SGBD accédé.

Par exemple, l’administrateur définit l’objet "CLIENT" et lui associe la chaîne SQL "client.nom, client.prénom, client.adresse". L’objet "chiffre d’affaires" est associé à la chaîne "sum(lignes_com.quant*articles.prix)" et sera associé à des fonctions de groupement à chaque exécution de requête qui l’utilise. Un objet peut être défini à partir de l’ensemble des colonnes de la base de données et des fonctions fournies par le SGBD. De plus, une hiérarchie temps est automatiquement créée à partir d’une donnée de type date. Elle se décompose en année, trimestre, mois, jour.

Définition d’un objet

Définition d’objets et de filtres

Il est également possible d’associer un critère de sélection aux objets (pour créer un objet "clients de l’agence de Nice" par exemple). La version 4 permet de créer directement des filtres, contenant simplement des critères de restriction.

Définition d’un filtre

les objets et les filtres peuvent être organisés de manière hiérarchique, en classe et sous-classes

Les objets peuvent être organisés en classes et sous-classes afin d’en faciliter l’accès pour les utilisateurs, de leur permettre de retrouver rapidement l’information qu’ils veulent récupérer. Plusieurs niveaux de sous-classes peuvent être créés.

Structure d’un univers : les objets et les filtres

Business Objects permet la définition d’objets prenant leur sens en fonction du contexte dans lequel ils sont employés. Par exemple, le chiffre d’affaires ne sera plus calculé de la même manière si on veut le chiffre d’affaires lié à un produit ou le chiffre d’affaires lié à un client. L’administrateur doit être le garant de la validité des objets quel que soit le contexte d’utilisation, assurant ainsi à l’utilisateur des résultats corrects. Cette définition d’objets sémantiquement corrects peut complexifier le travail de l’administrateur.

Par exemple, la définition d’un agrégat sécurisé donnant le total des quantités vendues ne sera plus simplement SUM(Qte_Vendue) mais

SUM(distinct Qte_Vendue + (Num_Vente/valeur élevée))

(Num vente étant la clé primaire de la table vente.)

afin de s’assurer que chacune des ventes n’est comptée qu’une seule fois. Ceci est notamment important dans le cas de requêtes faisant intervenir des liens (n,n), pouvant ramener plusieurs lignes pour une même vente, avec le même identifiant. Dans le cas où il n’y a pas de clé primaire simple, la définition pourra être plus compliquée.

Les liens

Une fois ces notions définies, il reste à spécifier les informations dont Business Objects aura besoin pour lier entre eux les objets que l’utilisateur souhaite interroger (nommées stratégies dans la terminologie utilisée par Business Objects). Il s’agit alors de définir les différentes tables que l’univers peut utiliser et les liens possibles entre ces différentes tables. Typiquement, l’administrateur définira un lien entre "client" et "commandes", un lien entre "articles" et "lignes de commandes" et un lien entre "commande" et "ligne de commandes". La définition des liens se fait dans une fenêtre montrant tous les liens déjà créés de manière de manière graphique.

Cette définition peut d’ailleurs se faire automatiquement, en s’appuyant sur des stratégies (par exemple, homonymie des noms de colonnes, clés primaires clés étrangères...). L’outil peut également rechercher automatiquement les cardinalités.

Structure de la base de données

Génération automatique des jointures et des critères de regroupement utiles pour répondre à la demande de l’utilisateur.

Lorsque l’utilisateur désignera les objets qu’il souhaite voir, Business Objects se chargera d’exploiter le travail de l’administrateur de manière à générer automatiquement les jointures et les critères de groupement utiles. Par exemple, si l’utilisateur demande l’article et la quantité commandée, Business Objects utilisera uniquement le lien défini entre la ligne de commande et l’article et générera un groupement sur l’article puisque l’objet "quantité commandée" est une donnée agrégée.

Business Objects dispose de mécanismes permettant de travailler sur des schémas relationnels d’envergure. Supposons que le schéma de l’univers soit tel qu’il y ait plusieurs chemins possibles pour lier deux relations : c’est le cas par exemple si le schéma inclut les notions de prêts et de commandes. Dans ce cas, il est possible d’aller d’un client à un article via le prêt ou via la commande.

Génération automatique de plusieurs requêtes SQL pour résoudre les problèmes du aux chemins multiples.	Depuis la version 4, l’outil est capable de gérer automatiquement les problèmes de chemins multiples en associant, de manière transparente, un ensemble de requêtes SQL à la demande de l’utilisateur. Ainsi, une requête demandant à la fois le nombre de produits commandés et le nombre de produits prêtés par un client engendrera l’exécution de deux requêtes, une allant chercher les quantités commandées dans la table commande et l’autre les quantités prêtées dans la table prêts.
Création de contextes, chaque contexte désignant le chemin à choisir. L’utilisateur peut sélectionner plusieurs contextes et donc entraîner la génération de plusieurs requêtes.	D’autre part, comme dans la version 3.1, il est toujours possible de créer des contextes afin de permettre à l’utilisateur de choisir lui même le chemin à emprunter. Un contexte englobe un ensemble de jointures. L’administrateur devra alors définir un contexte "prêts" et un contexte "commande" en définissant les jointures associées à l’intérieur des contextes. Si l’utilisateur pose une requête ambiguë, c’est à dire qui ne permet pas à Business Objects de choisir l’un ou l’autre des contextes, le logiciel lui demandera alors le contexte associé. Cette notion de contexte permet donc d’empêcher l’utilisateur d’utiliser des jointures incohérentes en réponse à ses interrogations. Ces contextes peuvent être proposés et définis automatiquement par l’outil. Lors de l’exécution de sa requête, l’utilisateur peut choisir un ou plusieurs contextes et donc entraîner la génération d’une ou plusieurs requêtes SQL.
Définition d’alias de tables	Depuis la version 3.1, la notion d’alias permet également de créer des univers autour d’une base de données au schéma physique complexe. Elle permet par exemple de faire apparaître des liens " Dirigeant/membre de l’équipe " dans une même table " Ressources humaines". L’administrateur peut ainsi créer un objet différent selon l’intérêt de l’utilisateur. Si nous reprenons notre exemple ci-dessus, l’administrateur créera deux objets :

alias

Cette notion de " couche sémantique ", d’accès aux données à travers des objets du métier et de moteur de génération de requêtes SQL est encore aujourd’hui une grande force de l’outil Business Objects. D’autant plus que Business Objects 4 est capable de générer des requêtes complexes, contenant des opérateurs ensemblistes, des sous-requêtes ou plusieurs requêtes SQL.

Interface de requêtes
De la même manière que pour la création d’univers, l’interface d’interrogation a été totalement remodelée dans Business Objects. Elle se décompose toujours en trois parties avec d’un côté les objets et les filtres disponibles, de l’autre les objets sélectionnés et les conditions à appliquer.

Définition d’une requête

Les conditions peuvent être constituées de filtres existants ou être créé par l’utilisateur au moment de la définition de la requête. L’utilisateur est alors assisté dans la spécification de ses critères.

Définition d’un critère de sélection

Définition de requêtes paramétrées.

Choix dans une liste de la valeur du paramètre.

Le critère de sélection peut être paramétré. A chaque nouvelle exécution, l’utilisateur renseigne les paramètres, ceux-ci pouvant être choisis au travers d’une liste des valeurs possibles. Cette liste est créée par défaut dans Business Objects, mais peut être modifiée par l’administrateur afin de l’adapter à des besoins spécifiques et conservée sur le serveur de données relationnel, dans les méta-données. La possibilité d’accéder à cette liste de valeurs peut être désactivée par l’administrateur.

Des boutons situés dans la barre d’icônes permettent de visualiser le SQL, d’associer des ordres de tri, de combiner plusieurs requêtes avec des opérateurs ensemblistes.

Dès la définition de la requête, l’utilisateur peut spécifier le périmètre d’analyse dont il aura besoin afin de ramener l’ensemble des informations utiles en une seule fois.

En vue d’une analyse multidimensionnelle, l’utilisateur peut déterminer au moment de la requête quel sera son périmètre d’analyse, de combien de niveaux il est susceptible de descendre dans les hiérarchies. L’outil ramène ainsi l’ensemble des informations nécessaires à la construction du cube englobant le périmètre défini par l’utilisateur.

Définition du périmètre d’analyse

Dans ce chapitre, nous avons montré comment l’utilisateur peut utiliser les objets prédéfinis par un administrateur. L’utilisateur peut également créer ses propres objets, dérivés des objets prédéfinis. L’objet propre à l’utilisateur pourra ensuite être intégré à la définition de l’univers partageable. Cette fonctionnalité permet à un utilisateur averti d’enrichir la bibliothèque d’objets du métier. Les fonctions disponibles sont les mêmes que celles proposées lors de la définition des univers. Elles sont cependant traduites en français afin d’être compréhensibles pour les utilisateurs non avertis.

Nous verrons cependant que la composante d’analyse de données du produit permet d’aller au delà des fonctions du SGBD. Dans ce cas, les traitements sont alors effectués au niveau local et non dans le contexte d’une requête SQL.

Etude de l’Institut EDS Prometheus

source: http://phortail.org/webntic/Presentation-de-Business-Objects.html

Accueil

management et technologie

Pages

Rechercher un article dans bouhajm